What is Digg?57 Comments
- Darkhacker, on 08/14/2008, -0/+77For those who are unaware, kernel development is a little different than other projects. In the past they used a 2.x release scheme where if x was odd, it was a development release and if it was even it was stable. This is similar to how Gnome operates today. The problem with this cycle is that it it took a lot longer for the kernel to stabilize and distributions began using development kernels instead of the stable one because the stable kernel became outdated too quickly.
After the release of 2.6.0 they decided to change the the cycle and make one release right after another. We now have 2.6.x.y releases where x is a major release made every three months while the y is a minor update to that kernel.
Now, after a major release there is a two week window for developers to submit the stuff they had been working on in there own experimental kernels (since branching in git is easy -- see: http://www.youtube.com/watch?v=4XpnKHJAok8 for Linus Torvalds on git) while the previous release had stabilized. After the two weeks are over and Linus merges changes into his own kernel, he releases them are release candidates (RC) instead of an alpha/beta thing. Typically there are seven or eight release candidates so RC3 is still early in the run. People submit patches and bugfixes for this kernel while others are developing new features in their own branches.
I highly recommend anyone interested in revision control systems or programming to watch that youtube video on git. He makes some very compelling arguments as to why CVS and SVN suck and I have to agree with him. And no, I'm not agreeing with him, just because he's Linus Torvalds, but because he's actually right (as he usually is). - Diabolus, on 08/14/2008, -0/+22The kernel is modular.
When you build it you usually just include the modules you need for the hardware you use. The rest is not compiled within the kernel. - directrix13, on 08/14/2008, -0/+20Drivers are updated directly in the kernel tree and submitted. Nothing special about it really. It just means all your drivers are there by default instead of having to hunt for them.
- Diabolus, on 08/14/2008, -1/+19Linux runs on more hardware than any OS ever...
- CATSCEO2, on 08/14/2008, -0/+12You don't work.
- agentlame, on 08/14/2008, -1/+12Things you just failed at:
Coherency
Memes
"FIRST!!!!" - alperea, on 08/14/2008, -2/+13silly noobish question but why do they put the drivers inside the kernel? shouldn't they be kept separate in case of updates to the driver or whether or not u need it?
- inactive, on 08/14/2008, -0/+9Agreed - A lot of Linux users disagree with him for his arguments against Gnome being too involved in usability as opposed to how users want it now, and I think he's right. (Case in point my ever typical 'GtkFileDialog' argument)
- stmiller, on 08/14/2008, -4/+11I agree with others who say it is time to consider a new naming/numbering scheme. Kernel 2.6.27.xx is nothing like 2.6.0.... yet seem to be similar by name designation. When the scheduler in the kernel changed, etc I think that was a good time to have gone to 2.7. What do you think?
- inactive, on 08/14/2008, -0/+7what anoying me slightly with the numbering scheme is that the API changed for modules around 2.6.24 or so. Normally the API changes only when a more major portion of the version number changes, ie for all of 2.6 it should stay the same. This is not the case with the kernel, which provides a more moving target. And for those that do not believe that the API did change, try to compile the ipw3945 module without my now submitted patch information on any of the last few kernel releases in the 2.6 series.
- DrPh0bius, on 08/14/2008, -0/+7The three responses above me are representative of the hope for the future of Linux. When I first started using Linux, it was a very, very "1337," hateful, intolerant community for the most part.
Everyone wanted to yell about how everyone should be using Linux, and how it was going to take over desktops everywhere (a topic for another time), but if you needed help, you were called a noob, told that if you cant compile a kernel you shouldnt be using a computer, etc, etc.
I dont know if it is a maturing of the community, or a result of all of the new distros that are always being released, but it has become a much more open community, and I am glad to see it. When I first installed, I didnt even ask any questions, because the mean responses I found in searching for answers pretty much pushed me towards windows.
Later, I found it easier to get help from the community and ended up running Slackware on a laptop, and numerous distros on a desktop.
I dont really have a point other than to say Im glad to see that more and more people understand that a helping hand is the best chance of growing Linux. - Acglaphotis, on 08/14/2008, -1/+8Ignorance feels better when you don't show it.
- Phocion55, on 08/14/2008, -3/+9No. When I plug in my scanner, I don't get a kernel panic.
- one7, on 08/14/2008, -0/+6In my experience Linux at least equals, if not surpasses, Windows in this area. I'm not a Microsoft hater nor Linux fanboy type--both have advantages and disadvantages, and I prefer to run Windows day-to-day.
But I've run into more problems with Vista than I have with Ubuntu on new, modern hardware. And Linux will give new life to older PCs without the horsepower to run XP at an acceptable level--I've salvaged some pretty old machines that way. You'd be surprised how fast and usable even an old 600mHz Pentium III can be after replacing Windows with Linux... - Arghblarg, on 08/14/2008, -3/+9Dugg down. The Linux kernel is NOT modular. If you've ever used (get ready for it..) micro-kernels, THOSE are modular. Linux, or any system that tries to fake modularity with a dynamic linker, is only going halfway to what modular really means. Linus' opinion on micro-kernels is well-known so I'm not going to open that debate.
The linux 'module' system merely delays link-time symbol errors to runtime. Barf.
Can Linux load a device driver that didn't even exist when your version of the kernel was compiled? No. Why is that? Because the 'module' system in Linux is really a runtime linker; the kernel has to have, literally, unresolved symbols in its symbol table for each device 'module' that the user might load at runtime. The kernel source code has to have some detailed, previous knowledge of your device's existence in its Kconfig files.
A truly modular device driver system uses a pre-defined set-in-stone API for all operations; driver attach, detach, new device instance, device interrupt, read, write, ioctl() (the catch-all escape hatch) etc. No symbols specific to each driver, rather a well thought-out generic call table that ANY device driver written now or in the future can adhere to. Basically the OS equivalent of an interface, in OO-terms.
The OS-9 (RTOS, not MAC OS9) operating system is a specific example I can think of here. The set-in-stone interfaces between kernel, I/O manager, device driver and device descriptors allow the kernel to use a device while knowing absolutely NOTHING about the driver's actual implementation. A device driver can be loaded into the kernel regardless of its revision.
I got a bit rant-ful here but it's an important distinction. - mazza558, on 08/14/2008, -0/+5Adding to this, typically the only drivers people have to hunt for are those which do not have support built into the kernel for non-technical/legal reasons, such as some Wireless drivers, Nvidia video drivers, etc.
- cesclaveria, on 08/14/2008, -0/+4after using svn and cvs for some time it is kind of weird to start using git, but it definitely is a better source control system. It makes easier to manage big projects with lots of branches.
- JohnFlux, on 08/14/2008, -0/+4Having all the driver source in one place makes it very easy to update an API.
For example the USB driver interface has been updated 3 times over the history of the kernel, and every usb driver is updated when it happens. As a result pretty much every USB driver runs at close to the maximum theoretical speed.
It also makes it easy to fix security bugs. Several times an API has had to be changed to fix a security bug. All the device drivers can be fixed and updated at the same time, ensuring that the bug won't come back and allowing a very fast turn around. - mrsteveman1, on 08/14/2008, -0/+3I like how ignorant statements always start with "all i know is", setting things up so you can ignore reality and focus on your flawed point.
Your Tivo probably crashes because the hard drive is bad, or its too hot. - inactive, on 08/14/2008, -0/+3It's more my argument than anything. People don't generally hype up about it, it's annoying as hell though - I know because all of my Linux using friends despise it. (I only have like 3-4 though)
It's like how Vista's Paint Save dialog looks /exactly/ like GIMPs save dialog. Nobody ever talks about it.
Linus, however, has made arguments several times about GNOME and GTK applications in general. For those you may have to look deeper.
The arguments are made usually by users and not programmers. I refer to it as GtkFileDialog as a programmer whos used GTK's native interface before - most will refer to it as The Gtk File Dialog with spaces, for example, results for "Gtk File Dialog Sucks":
http://arunprasannan.jaiku.com/presence/33109208
http://thefilechooserdialogingtk2.*****.info/
A lot of problems have been resolved but there is still room for improvement - mainly, a lot of 'innovation' in it is really just annoying as hell. - mrsteveman1, on 08/14/2008, -0/+3"Kernel 2.6.27.xx is nothing like 2.6.0....yet seem to be similar by name designation."
You mean, other than the 27 major releases in between the 2?
I agree with the date thing though, that would help. And of course major releases should get a version bump to signify it. It's almost like they think they are too cool to rev the version number when something significant happens, because thats what those evil commercial guys do as a marketing trick.
People want to know when major changes happen, version jumps do that well. - FolkTheory, on 08/14/2008, -1/+4how about dates? that's simpler and clearer it'll be kernel-2008-8-14-RC3
- drjones78, on 08/14/2008, -0/+3git is awesome.
Use it for all my projects now, even though my needs arent anywhere as nearly complex as something like the linux kernel.
It makes the basic stuff stupid easy, and the hard stuff doable. I don't have to fight with my revision control system anymore... I hope subversion dies a painful death. - DrPh0bius, on 08/14/2008, -0/+2He works, he just crashes a lot.
- hobophobe, on 08/14/2008, -0/+2"[...] if there is something so fundamental that everything will break, we will start at 2.7 at that point." - Linus Torvalds
Here: http://www.zdnet.com.au/news/software/soa/Torvalds ... - weiran, on 08/14/2008, -0/+2Care you summerise the arguments about GtkFileDialog? I had a quick search on Google but didn't find anything.
- koan, on 08/15/2008, -0/+2While the drivers are "in the kernel" the kernel is highly configurable.
Configuring and compiling your own kernel is not has horrific as it sounds, there are tools that help (make menuconfig), and the help is surprisingly helpful. The whole process is easier on some distros than others. With gentoo, when you download the kernel source, it is automatically patched with the latest fixes. With Redhat based distros, it is seemingly more complex (I never did get to the bottom of it) as you download the source and get a million patches without a guide as to which ones should be applied and for what.
"Make menuconfig" kicks off the menu based kernel configuration , and within the device drivers section, you can turn off or on any of the drivers. This means that you can build a very "tight" kernel that only has built in support for the drivers you need. Drivers can also be set to "module" which builds them as a separate kernel module which you can load and unload as required (this is why many distributions can support so much hardware out of the box like ubuntu - most common hardware is built as a kernel module, and is automatically loaded if required at bootup. It means you can have a not-too-heavy kernel but still support a wide range of hardware).
Once you have configured your kernel as you want it, you "make" it, then "make modules_install" to make sure any drivers you chose to create as modules are installed in the correct place. Then copy the kernel into your boot directory, update grub to add it as a menu option, and test it out. - JohnFlux, on 08/14/2008, -0/+2> The quality of patches seem to be moving people more and more towards the Sun methodology of just running 4-5 (or more) revisions behind
Okay, so what's particularly wrong with that? You are arguing for a much longer release cycle, so what's the difference between releasing every year (or whatever) compared to running a release that is one year old, and then stabilising that with bug fixes that have been found? - Breepee, on 08/14/2008, -2/+4Basically, the 2.6 means nothing anymore, and with the current way development goes, it appears we'll never 'get out of' 2.6. Why not move up to 3, where this new kernel is 3.27-rc3 for example?
- mrsteveman1, on 08/14/2008, -0/+2That seems to happen often. There are some drivers recently that required patches for every single kernel release, and that's just compiling from source.
Binaries break with every release as well. - mrsteveman1, on 08/14/2008, -0/+2Actually the problem is disorganization to a degree.
Most distros don't upgrade their kernels when new ones come out (Cept arch i think). Ubuntu is using 2.6.24 and we are talking about 2.6.27 already. They might not even use 2.6.27 for 8.10 when it comes out if 2.6.27 isn't released yet.
If the ubuntu devs have the source for everything and they have control over what goes on users systems from repos, they can and should upgrade the kernel when new ones come out. Quick backporting stuff and just use the new kernel, which should already have all those fixes, plus new drivers which are very important right now. - NTolerance, on 08/14/2008, -1/+2I'm not sure exactly what the GtkFileDialog argument is, but it sure sucks when you hit "open" in a GNOME program and that worthless dialog pops up. Can't do ***** Cap'n!
- qwuinc, on 08/14/2008, -0/+1@Arghblarg
Andy Tanenbaum? Is that you? - directrix13, on 08/14/2008, -0/+1It does make the source fairly large, but not unmanageably so. Drivers are based on common chipsets more than what specific pieces of hardware which use the chipset. And you (or someone) specify which components are built directly into the kernel (always loaded at startup), built as a dynamically linking module (loads only when hardware is detected or when forced), or just not building it at all.
- maelfius42, on 08/14/2008, -0/+1I fully agree, major changes should be major releases.
but I'm not a kernel dev -- obviously *sigh* - JohnFlux, on 08/15/2008, -0/+1> Quick backporting stuff and just use the new kernel, which should already have all those fixes, plus new drivers which are very important right now.
And new bugs. It is very important for distros to perform long quality assurance on the kernel. - JohnFlux, on 08/14/2008, -0/+1I guess I just don't see the point. The more bureaucracy that you introduce, the slower you make development. Linux users aren't affected by this because they are shielded by the distributions. The distributions can pick and choose what changes they want to allow, doubly so since it's all based on git.
If an internal API/ABI changes, well.. so what? It doesn't affect anyone if all the drivers are updated at the same time. I can see the frustration if there a bugs in a release, but it seems like a very optimal way of development - do frequent releases and leave the full blown quality assurance up to the distributions. - mrsteveman1, on 08/14/2008, -0/+1Rants are important when something is truly stupid. The linux module situation just avoids some problems where the entire kernel would have to be recompiled to add a driver as is (or was) common with some BSDs and other systems.
And of course it avoids loading code into kernel space that isn't necessary, you can leave things out at runtime if the hardware isn't even present.
However, drivers are still very much inseparable from the kernel once compiled. A binary driver like truecrypt 4 for instance, had to be compiled for every single version of every distros kernel if you wanted to use it on all of them or any of them.
This discussion then usually turns into 'if your drivers is GPL and in the mainline tree you don't have problems'. Bleh. - MadHarvey, on 08/15/2008, -0/+1That was a really good video. Has that been submitted to Digg yet?
- maelfius42, on 08/14/2008, -0/+0No I'm arguing for a long release cycle on major changes. I might not have been clear about that.
The issue is that the bug fixes and other changes tend to get rolled into a (what is now) full kernel release. There is no differentiation between bug fixes and releases. I'm sorry but API changes, scheduler changes, etc should all be in their own release that increments the major number so that you can maintain a stable line of kernel without backporting patches into the tree. If one of the APIs change and a bug fix is written for a part of the kernel and is written with this new API change in mind (where it wouldn't be required to use the new API -- again hypothetical situation)....we run into a situation where it becomes a hassle to backport OR you end up with the need to upgrade the kernel. As stated earlier 2.6 means NOTHING anymore except a convention on name...we almost might as well drop the 2.6 or even the 2 from the kernel version (not appropriate but stated because it's true) since we no longer increment the major version, just release a ton of new code into the minor rev.
So yes, I think the development should be done in it's own tree and be on a regular cycle. This gives specific major revisions a life cycle where you expect support (bug fixes) for the kernel via mainstream sources for the next months.
I know I'm in the minority, and I know I'll be dugg down for this in all cases. - alperea, on 08/14/2008, -1/+1makes sense. but that raises another question, if you want to download and compile a new kernel from source, wouldn't having to deal with all of the drivers for hardware you don't own/use and hardware from ancient history make the kernel source pretty huge? Or does it not really affect it too much and the pros outweigh the cons?
- smhTheory, on 08/15/2008, -0/+0after spending several hours trying get my wireless card working in ubuntu this week, i feel its okay to giggle and not bury the hell out of poor leladax.
ndiswrapper for the RAGE!!!!! - inactive, on 08/16/2008, -3/+0But can it run crysis??????!!!111
- wunksta, on 08/14/2008, -4/+1feels good man
- RealHyperX, on 08/14/2008, -5/+1No, it crashes because it runs Linux. I am sure of that. Now go fix it PLEASE and stop wasting time of Digg.
- maelfius42, on 08/14/2008, -7/+2Frankly...I'm sick and tired of the amount of changes per revision of the linux kernel. Unfortunately, it is becoming more and more difficult to maintain a kernel in production that has all relevant bug fixes (without back-porting) and/or minor patches without hitting a massively unstable or unusable version.
There also seems to be a lot of arbitrary BS that is making it's way into the Kernel minor-rev-to-minor-rev (look at the nosharecache nfs "fix"/"regression" flame war). -- broken in 2.6.18(i think) and then fixed in 2.6.23 -- THIS WOULD HAVE NEVER MADE IT INTO THE KERNEL IN THE OLD SCHEME, vs. just slipped in.
The linux kernel is suffering from the "release early, release often" methodology, and it should be backed off a bit. Releases should be tested and stable, especially for projects as important as the Kernel. There was a reason I liked the even major revs being stable and odd being development. The quality of patches seem to be moving people more and more towards the Sun methodology of just running 4-5 (or more) revisions behind (Solaris was typically run 2 Releases behind: when Solaris 10 was released, most people were running/upgrading to Solaris 8).
/RANT - expert01, on 08/14/2008, -6/+1How about a 3.0?
- tomd123, on 08/14/2008, -7/+1I'll forget reading about this in 3.. 2.. 1...
- inactive, on 08/14/2008, -7/+0ctrl+alt+del!!!!! ctrl+alt+del!!!!!!!!!!!!11111111111
-
Show 51 - 58 of 58 discussions
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is