Slashdot Mirror
Linux 2.6.26 Out
diegocgteleline.es writes "After three months, Linux 2.6.26 has been released. It adds support for read-only bind mounts, x86 PAT (Page Attribute Tables), PCI Express ASPM (Active State Power Management), ports of KVM to IA64, S390 and PPC, other KVM improvements including basic paravirtualization support, preliminary support of the future 802.11s wireless mesh standard, much improved webcam support thanks to a driver for UVC devices, a built-in memory tester, a kernel debugger, BDI statistics and parameters exposure in /sys/class/bdi, a new /proc/PID/mountinfo file for more accurate information about mounts, per-process securebits, device white-list for containers users, support for the OLPC, some new drivers and many small improvements. Here is the full list of changes."
Does it disturb anyone else how many words the bsdm & linux kernel community have in common? (this is not a troll).
Frankly, I blame IBM.
I found this article on Wikipedia but it doesn't say much except "A kernel debugger is a debugger present in some kernels to ease debugging and kernel development by the kernel developers". Can someone whip out a cluebat please?
Yes it does, and I can even imagine a beowulf cluster of them!
They have still not enabled mode switching in the intelfb driver on laptops, meaning that I am forced to use ugly, unaccelerated VESA instead of the right driver for this sytem. This bug has been reported on kernel dev mailing lists and forums for at least three years, but no one with the skills seems to want to fix it.
What I would like to see more emphasis on in future kernels is a discussion of possible clever new tools and methods for configuring the thousands of kernel config options. None of the existing in-kernel-tree or out-of-tree config tools seems ideal.
Why oil price increase equals economic trouble (Score: Interesti
Ugh, still no token ring support. And it's distributed under the GPL License. I think I'll recommend all my fortune 500 clients stick with windows server 2003.
If I'm understanding correctly, I believe they're talking about a mode in which you can debug kernel level events. You have a client PC (the debuggee) and the server PC (the debugger). They're usually connected over a serial cable.
OK, 2.6.26 is out, and kudos for all the good work. But where is a truly writeable NTFS? Many larger USB drives are shipping with this pre-installed, so true write support is needed in the kernel.
AFAIK, current kernel "write" support does not including creating files or directors (presumably just modifying/appending to existing files).
I've tried ntfsprogs, but not got it to compile x86_64.
Have a look into DD-WRT: http://www.dd-wrt.com/wiki/index.php/Mesh_Networking_with_OLSR
These changes will now make 2008, THE year for the linux desktop!
...and it should be known by now
I wish every kernel release announcement included a highlevel featurelist like that. Not just a ChangeLog, as each bug is fixed or small feature is added. But rather a fairly highlevel list of new and improved (and fixed) features like the one in this Slashdot story. Best if in the announcement itself, but at the very least always in the release package.
That way most of us can decide whether to upgrade, or to wait (perhaps for the x.1 version, which is typically a higher quality bugfixed delivery). Since kernel upgrades require rebooting (and again to downgrade after test), knowing whether to ignore a release based on its highlevel upgraded features itemization is a very effective announcement feature, which makes all of us using the releases more productive.
--
make install -not war
Ugh, still no token ring support.
It had token ring support circa 2000 and you can probably resurrect the drivers if you need it.
OTOH if you're still using Token Ring you probably have Madge or Olicom cards whereas the best Linux support was for chipsets like the IBM Olympic.
Click the link in the story: http://kernelnewbies.org/Linux_2_6_26
and it explains it all there
Reading on it, it seems that Linus never has been a great fan of kernel debuggers. From a famous post,
I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. [...]
I agree that stepping with a debugger instead of thinking real hard about the code (and using abundant log statements) is generally a waste of time, and that expecting to catch rare occurrences of weird race conditions with a debugger is not worth the effort. Sloppy programmers don't take the time to think, and rely too much on fixing what they could have not broken. Unit tests, although more expensive to code, can be reused many times - debugging sessions are one-shot.
On the other hand, even good programmers can get stuck and benefit from a debugger every once and then. I guess this argument finally won the day.
A kernel debugger is a program you can run from one computer, generally via a serial patch cable or some such, that lets you step through the kernel code running on another computer. It's like a normal debugger, but remote.
Linux has had kernel debuggers for years, but Linus never wanted it in mainline, so it was always a patch, and sometimes didn't work on the latest kernel. Now, it's part of the kernel (I don't see any links to why Linus changed his mind, but you might be able to find something on LKML if you look).
Anyway, I think this is good news. I understand why Linus never wanted a debugger in the kernel, but I disagree with him on two points. First, even developers who have a good understanding of the code can get work done faster if they use a debugger. Using a debugger does not automatically relegate you to someone who doesn't have a good understanding of things, as Linus would have you believe (i.e. there's a difference between needing a debugger and being more productive with a debugger).
Second, there are a lot of people these days who just fix bugs, or just want to debug their own tiny kernel patch. I.e. people who don't have a full understanding of the system but who need to get something done. It's good that these people are now first-class citizens. They likely will never write a new kernel subsystem, but maybe they'll fix a few bugs and make life better for the rest of us.
Technically, "Linux" is the kernel, and there is no "Linux" OS. Of course, the various distros are generally referred to as "Linux" distros, which really doesn't help matters any. I believe your FreeBSD/NetBSD/etc are vaguely equivalent to Debian/Fedora/etc.
Is Linux kernel 2.6.26 == Linux 2.6.26 ?
Yes. When people refer to entire distributions as "linux" they are being technically incorrect, as the GNU folks are kind to point out at the drop of a hat. The entire operating system is GNU/Linux - Linux is just the kernel.
...if your friend/colleague/whatever wants to use an NTFS-formatted drive on your computer, he might be a little unhappy if you reformat it.
I put NTFS support on my Linux computers and Ext2/Ext3 support (and a proper formatting tool) on my Windows computers. It's called interoperability.
"When information is power, privacy is freedom" - Jah-Wren Ryel
The entire operating system is GNU/Linux - [...]
Because libc+shellutils+gcc is so much more relevant than X, KDE/e17/etc, the package manager, ...
The entire operating system is GNU/Linux -
No, I think the entire operating system is GNU/Linux/X/Mozilla/QT/GTK/*insert favorite WM*/whatever else. If you refer to the entire OS as GNU/Linux, you are neglecting other key parts of the OS. If you call Windows NT, just NT there is no problems with it, the various divisions of MS don't call it Windows/DOS/NT do they? Linux is the name of the kernel, NT is the name of another kernel, yet I see both being referred to as Linux or NT, the difference is MS isn't always correcting you.
Taxation is legalized theft, no more, no less.
Sure, just install Xen, and then you can indeed make it run Linux.
If you're feeling really masochistic, you could even create a beowulf cluster of Linux boxes, running Linux, with Linux running on them. /me watches his head explode.
802.11s != OLSRv2 . 802.11s seems to work at the MAC layer, whereas OLSRv2 works at the IP layer. They are not the same. There are quite a few mesh networking protocols out there and in development, but I haven't seen a clear winner yet.
It only takes one man to change the Wisdom of the Crowd to Tyranny of the Masses.
Did you file a bug report? Did they mark it fixed? If you answered no to either of these questions, you may be a whiner. You also may not know what you're talking about as you said "20+k interrupts" without actually specifying an amount of time or what type of interrupts they were, and you came and posted here rather than checking the change logs for things like, "dual core", "interrupt storm" or any other keywords.
I believe your FreeBSD/NetBSD/etc are vaguely equivalent to Debian/Fedora/etc.
I'm not sure where exactly you're going with that
What he(?) means is that just as {Free,Net,Open}BSD are complete operating systems, so are Linux distros like Debian, Fedora, etc.
"I don't know, therefore Aliens" Wafflebox1
fixed? it eatz up my battery like you know who ...
who? ceiling cat?
Caesar si viveret, ad remum dareris.
It's part of the mac80211 layer, so it in theory supports any mac80211 driver, that is a 'soft MAC' WiFi chipset. There are minor driver changes required to support mesh (basically adding mesh beacons) and right now the zd1211rw and B43 drivers work. We have more details here:
http://o11s.org/trac
B43 is your best bet at the moment, if you have a few of those, give the HOWTO on the o11s website a try and you can have your own mesh network.
Eventually other soft-MAC chipsets can work, such as Intel's iwlwifi, Ralink, etc. At the moment beaconing is broken in rt2x000 so Ralink won't work, but that will probably be fixed soon.
The entire operating system is called Ubuntu, Fedora, Debian, Suse, whatever. They all happen to have a Linux kernel, GNU tools and are very compatible, but that's all there is to it. All these operating systems are often refered to as Linux, as that's what makes them all so very compatible (If an app runs in Ubuntu, it very probably also runs in Suse). There's no such thing as GNU/Linux, because I've never ever seen an .iso labeled like that. gNewSense is afaik the endorsed operating system by the GNU project, let's leave it at that.
And this is why common usage trumps technicality. At this point, the GNU folks need to accept that they've lost. The OS is called "Linux" now, and no amount of them correcting people is going to change it... it just makes them look like pedantic whiners.
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
It never will be. Linux is just the kernel, which is a very important piece of software that make everything else work. X (and MPX) is part of that "everything else", and when it's available will depend on which distro you use.
Can someone whip out a cluebat please?
<WHACK />
There. Did that help?
You're looking for the next version of X.org, not Linux.
factor 966971: 966971
Yes, you're going to get flamed, and for good reason. Just how easy do you think it is to support chipsets from manufacturers who supply no documentation, who load their firmware from their drivers, and who threaten to sue anyone who tries to do it on their own?
And so, yeah, maybe YOU should BECOME a developer.
...Steve
XML tags are lowercase.
Just because it CAN be done, doesn't mean it should!
This would not build a "perfect" kernel, but it should produce something damn close, especially if the user is asked to supply information on anything that is uncertain or which cannot be deduced from the information that's discoverable or collectible.
There are also kernel patches, such as WEB100, which can tune some elements of kernel operation when a system is in use. If you add that into the mix, then you end up with something that is highly customized for the user without the user having to do more than the minimum of customization.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I actually do this. As part of the networking lab for my school I set up a load balanced cluster of physical boxes to run virtual machines in arbitrary network configurations. It was harder than it needed to be.
Wrong. XML is case-sensitive, not lowercase. XHTML uses lowercase XML elements, but in general XML elements are not lowercase only.
++Insightful.
I've lost count of the number of times I've explained some esoteric bug to my wife, and shouted "AHA!" in the middle. The success rate is high, so long as you have a patient partner, and can ignore the glazed look.
Do as you would be done to.
Actually, let's try a more constructive approach.
``How about getting b,g,a working for standard (intel, broadcom, atheros) chipsets first.''
I'm sure it's being worked on. As for that happening _first_, I don't think that's a really good idea. To you, support for these chipsets may be very important, so important that it makes you feel bad if any features have been added, without adding supports for said chipsets, first. To others, these chipsets may not be so important. Those people would rather have other features added first. With the large number of people who are working on Linux, a lot of things can be worked on at the same time - but we can't hope to please everyone.
As for support for your chipsets - experience shows they will probably be supported someday, but it can take a long time. Exactly how long usually depends how cooperative the manufacturer of the chipset is, and how similar the chipset is to chipsets already supported. Both of these are under control of the manufacturer, so we are largely dependent on them.
``The same reason I get trolled and flamed, is the same reason that LINUX is never going to be more than a "hobby OS"''
I agree with you that flaming you isn't an appropriate response to your original post, which is clearly rooted in frustration. On the other hand, your attitude isn't exactly helpful, either. You complain about developers not supporting your favorite features - features that are probably hard for them to implement, because they are dependent on others who aren't cooperating - and tell them they should have supported your features instead of the many great features they did implement. Then you go on to claim - insultingly - that "LINUX is never going to be more than a \"hobby OS\"", which is clearly disingenious. Linux is being used professionally in many places. People are selling operating systems based on it, and devices with Linux on them. Clearly, it's already more than a hobby OS.
All in all, your complaint about lack of support for common network hardware is well-taken, and probably being worked on. It will take time, of course. Would you really have all other development on Linux halt while the drivers for your chipsets are developed? I don't think that would be wise. I understand (and share) your frustration, but I think the best course of action is:
1. Leave the developers to work on what they want to work on (possibly guided by suggestions from users)
2. For WLAN, choose chipsets that _are_ supported, and preferably with specifications available from the manufacturer. Support the manufacturers that support freedom of choice, not those that would lock you into proprietary software.
3. Express your frustration with the situation, but refrain from insulting people and using strong language. There's just no call for that.
Please correct me if I got my facts wrong.