Linux Kernel v2.6.23 Released
diegocgteleline.es writes "After 3 months, Linus has released Linux 2.6.23. This version includes the new and shiny CFS process scheduler, a simpler read-ahead mechanism, the lguest 'Linux-on-Linux' paravirtualization hypervisor, XEN guest support, KVM smp guest support, and variable process argument length. SLUB is now the default slab allocator, there's SELinux protection for exploiting null dereferences using mmap, XFS and ext4 improvements, PPP over L2TP support. Also the 'lumpy' reclaim algorithm, a userspace driver framework, the O_CLOEXEC file descriptor flag, splice improvements, a new fallocate() syscall, lock statistics, support for multiqueue network devices, various new drivers, and many other minor features and fixes. See the changelog for details."
overlord. welcome. yay.
On a more serious note, are these improvements dramatic, or is story featured just because it's the newest Lolnus kernel?
I'm so excited, I wish I could have stayed up until midnight in a huge line for it! HOW AM I SUPPOSED TO SLEEP NOW?!
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
I think I'll take the opportunity to upgrade to 2.2.26; I don't waste my time with unproven technology.
After 3 months, Linus has released Linux 2.6.23. This version includes the new and shiny CFS process scheduler, a simpler read-ahead mechanism, the lguest 'Linux-on-Linux' paravirtualization hypervisor, XEN guest support
Yes, what they don't mention is that the XEN "guest support" is in the form of a crowbar.
The theory of relativity doesn't work right in Arkansas.
I RTFA and it didn't mention whether or not it was released under GPL v2 or v3. Does anyone know?
Using openSUSE instead of Windows since 9th of October, 2007 and liking it.
Unless Solaris is released under the GPLv3 and Linus sees some stuff he wants.
Really, he said that.
How we know is more important than what we know.
...the extra flavor that makes this release a little bit more headline-worthy than usual is probably the whole controversy involving the Completely Fair Scheduler. Between Con Kolivas leaving kernel development, the Really Fair Scheduler flamewar and almost ten release candidates, the whole 2.6.23 development was some kind of geek soap opera.
You can't just relicense code that was GPL2 only. It would all have to be rewritten, from scratch. Linux will NEVER be GPLv3.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Yes, this is a good thing. However, they seem to have missed some: sockets and pipes. Sockets are not close-on-exec by default, so you may pass a sensitive socket to a child.
Windows NT has the same problem: sockets are inheritable by default until you call SetHandleInformation to disable inheritance. Other handles' inheritability is selected at open/create time.
Luckily, there is a workaround for it, if not pretty: use a reader/writer lock with opening handles as writers and forks as readers.
By the way, the linked changelog on kernelnewbies.org has a bad link for the "recommended LWN article".
For the SELinux thing against null pointer attacks, won't that break DOSemu?
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Hello everybody out there using Linux -
:-)
:-(.
I'm doing a (free) operating system based on GPL3 (just a hobby, won't be big and professional like Linux) for x86. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in Linux, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).
I've currently ported bash(3.2) and gcc(4.2.2), and things seem to work. This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them
PS. Yes - it's free of any Linux code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have
No, the problem is finding *all* the copyright holders and getting them to agree to GPLv3.
The copyright holder can license the code however he damn well pleases.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
fallocate() is a new system call which will allow applications to preallocate space to any file(s) in a file system. Applications can get a guarantee of space for particular file(s) - even if later the system becomes full
I was about to go and make fun of Linux for creating a feature that's been around in Windows for quite a while - take your pick of SetFilePointer or sparse files. Yes, yes, I understand that reserving space for a file is not the same as growing it and not using that space. Twas meant to be a troll....But, it turns out that a bit of googling reveals that sparse files under Windows are not all that they are cracked up to be:
http://www.flexhex.com/docs/articles/sparse-files.phtml
This is my sig.
What Linus said was "I was impressed in the sense that it was a hell of a lot better than the disaster that were the earlier drafts. I still think GPLv2 is simply the better license."
A couple days later, he expresses more angst with the GPLv3 and the FSF.
The bottom line is I consider dual-licensing unlikely (and technically quite hard), but at least _possible_ in theory. I have yet to see any actual *reasons* for licensing under the GPLv3, though. All I've heard are shrill voices about "tivoization" (which I expressly think is ok) and panicked worries about Novell-MS (which seems way overblown, and quite frankly, the argument seems to not so much be about the Novell deal, as about an excuse to push the GPLv3). So... I'd hardly say, as you did, that he doesn't mind the GPLv3. In fact, the FSF shills really ticked off a lot of kernel devs by trying to berate them into switching to the GPLv3 back in June/July.
Don't leave your mind so open that your brain falls out. Don't close it so much that you cut off the blood.
personally, i think, that the height of computing was 'cron'. you needed a report every morning, put it in cron. you needed to analyze data every week, put it in cron.
;) i mean, heavily under the influence.
computing was supposed to automate. supposed to make everyones lives easier by helping the person. now look at it. walk into any corporate office and you'll see countless people (myself included) clicking on this and that to satisfy what the computer wants out of you. it feels like you are there to help the computer achieve uptimes, or defragged disks, getting rid of viruses, blocking ports, unblocking ports...
am i there to help the computer do it's job? or is the computer there to help me do mine?
why does the computer occupy the center of my desk? why isn't it tucked away in the utility closet?
but that's a more philosophical discussion to be had - under the influence
Slashdot is a technical community so my comment may not be well received.
No, your comment won't be well received because it has nothing at all to do with the article or the Linux kernel.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
Dude, if you actually read the kernel mailing list you would know that Linus has said that he can change the license whenever he wants. All he has to do is post a notice to the list, and add the same notice to the license file specifying a date when the license will switch over. Anyone who doesn't agree will have an opportunity to opt-out, at which point their code will be pulled out and rewritten, or opt-in. The ones that don't do either can be assumed to opt-in until such time as they complain.
This has been done before.. with the syscall interface exception.
Stop repeating myths and do some research.
How we know is more important than what we know.
You forgot the hardcoded support for Swedish keyboard layout, only.
I just think in order to get Linux adopted by the populous, it's going to take more than kernel enhancements to see that through.
But see, the problem is that nobody's arguing that kernel enhancements alone *are* going to result in the rise of desktop-Linux-for-the-masses. What you're doing is akin to walking into a university campus that's just expanded a bit and proclaiming how they're not doing enough to save the baby whales. Yes, some of the facilities and information dispersed therein may be getting used by people looking to save the baby whales, and some of the staff may even be interested in saving the baby whales themselves, but the university is not in fact there to save the baby whales, but instead serve as general resource that can be utilized in a number of different and often drastically divergent ways.
"But graphic UI's are the future of computing and I think it's high time for a distribution to make it HARD to find the shell in an OS."
You can have my shell when you pry it from my cold dead hands - same as my keyboard!
Most distros come with multiple GUIs, and those GUIs are superior to anything Redmond can put out. Add that to the ability to run Windows in a window (where it belongs, if it belongs at all on your box), and mp3 and dvd installers a click away in the newest distros, 21 gigs of software free for the downloading, faster release/bugfix/update cycles ... if you want a GUI, you can have your pick.
But do NOT take away my terminals. There are a lot of things that are quicker to do in a term than with a clicky interface. Have you not heard of "the right tool for the job"?
Just take OpenBSD and re-release it under the GPLv3!
Linux is a kernel. A kernel's definition of usability involves well documented programming API's.
Usability is a problem for the desktop maintainers ( the KDE or GNOME guys ), not the kernel hackers.
Added bonus, the desktop maintainers can be OS agnostic if they like, so the usability gains that linux sees can easily transfer to BSD or OpenSolaris, should they turn out to be better kernels overall
"It takes a specific type of person to get Linux running and to a point where it can be productive even for nontechnical users (which is the majority of users that use computers)"
WTF???
Linux installation for dummies, PHBs and Windows sysadmins (but I repeat myself)
If you can't follow that, print it out and pay some PFY* in grade 9 $20.00 to help you.
(if you don't recognize the reference, you're obviously new here and deserve to be beaten with a clue-by-four, both ways, in the snow, etc...)
An exploit with feature-complete proof of concept was released for x86_64 linux kernel ia32syscall emulation by cliph at isec in Poland. Exploit code was wildly popular on milw0rm, indicating that this local exploit has lots of potential.
http://tinyurl.com/4ny52
Short answer: no.
Long answer: if NVIDIA ever makes open source drivers, they will almost definitely be kernel space drivers. Apparently this is in the works, same with ATI, but I'll believe it when it happens. It would be possible for some bored hacker to take the NVIDIA binary blobs and make a userspace driver from them. This driver could be legally distributed with the NVIDIA binary blobs (probably). And yes, this would mean that recompiling the drivers for a new kernel would not be necessary.. and it would also mean that the kernel wouldn't be "tainted" by using this driver (maybe).
I, personally, think the stability and security advantages of running binary blobs in userspace drivers outweighs the possible performance hit (no-one has measured the performance hit, yet), so it's a good idea. But, ya know, I've got some other stuff to do...
How we know is more important than what we know.
Linus has outlined a number of possibilities, a lot more favorable than you are suggesting, but yes, there is no motivation at the current time to change the license.
But that wasn't the point of my post.. the point of my post was to stop the meme that the license can't be changed. It can. Or, at least, Linus has said it can, and that should be good enough, cause if he thinks it can be changed and there is a reason to change it, then he will, and we'll be having a different discussion.
How we know is more important than what we know.
the lguest 'Linux-on-Linux' paravirtualization hypervisor
Linux on linux, that's so hot!
Of course you realize that no project which launches with that kind of announcement could ever expect to succeed.
I mean, really. What are the chances?
It's called a network effect. Linux improves, and gets more users, some of whom are developers, who improve Linux. It just keeps growing with every cycle.
Proprietary operating systems can't compete because they're closed. The best an innovative user/developer can do is fire off feedback asking for a feature, and it'll be implemented wrong anyway, and then released 3 years later in the next major version.
Even more impressive is that this is the *stable* kernel branch that's growing so fast. The -mm experimental branch has gone right off the hook, to the point Andrew is complaining the development doesn't scale any more with only him at the helm.
For those who want a more conservative choice for servers, there's always something like FreeBSD. It's nice to have choice and interoperability. FreeBSD is more compatible with Linux than Windows XP is compatible with Windows Vista. If you don't believe me, consider that at least FreeBSD and Linux have a lot of standards (APIs, file formats, layouts, etc) in common.
Sam ty sig.
Richard, is that you?
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
As with any other tool this means that it has to be somewhere you can get at it(on your desk) and that you need to know how to use it(ask anyone who has never used a hammer before to pound in a nail and see how many times they stuff it up).
Now you might argue that a computer is a lot harder to use than a hammer, but that's mostly because it's metaphorically a bit more like a toolbox. It has tools within it to perform specific tasks as opposed to doing only one task(historically this has had to do with cost, but as we see comodotized hardware prices this may change). When you have a toolbox full of tools, you not only need to know how to use the individual tools, you also need to know how to find them in the toolbox, how to properly and safely remove them from and return them to the toolbox, as well as how to perform any required maintainence to your toolbox.
In the same way in order to use your finance application(the tool), you need to know how to find it and run it as well as how to actually use it. Someone(not necessarily you) also needs to know how to put the tool where you can get it in the first place(install the software), clean the gunk out of the toolbox(maintain the PC) and to transfer all your tools from an old toolbox to a new toolbox when your old one falls apart, or you need one which can hold more tools.
Not to nitpick, but the milw0rm main page says '2007-09-27' beside that exploit. I'd hardly call that today's Linux news.
Would it surprise you to find out that most of the community agrees with that statement? .. With one caveat, however: You're confusing Linux, the opreating system kernel, with the rest of a complete system. If we were discussing one of the *BSDs, I'd not balk, but there is a huge difference between Linux and what you're talking about. Linux runs behind the scenes and has nothing whatsoever to do with usability or even UIs.
The last thing you want to do is hide functionality - especially necessary functionality - from users. All Apple did was wrap a Mach kernel under a NeXT-ish facade and hide the majority of the more "advanced" features. IMO, there's no reason to make the shell go away, but rather to set it aside in a non-intrusive and logical place - exactly how most current distributions set it up. You can still get to a terminal emulator in OS X - it's harder, sure, but it's still trivial to make it readily accessible - and it uses BASH, a powerful and quite useful shell. By contrast, on Windows, it's not obvious where the shell is right away, and once you know where it is, you quickly find it's limiting and hard to use - if you're an advanced user, it's useless.
It's quite unified. There's surprisingly little fragmentation in the community (save for Vim/Emacs and KDE/Gnome zealots), and a lot is accomplished daily. We have, right now, not one but ten (more?) advanced, powerful, and very usable desktop environments (including Gnome and KDE); a constantly improving graphical server that now supports advanced 3D effects, render acceleration, compositing, and multiple pointers (new! for multi-touch displays and the like a la iPhone); powerful multimedia features that audiophiles and videophiles are turning to in droves; multiple complete suites of office-targetted applications (KOffice, AbiWord, OpenOffice.org, and others); and many, many other programs that most users will always find that meet their immediate needs. And that's just in the stable repositories.
My question for you is this: What do you think is missing? We'll get somebody on it.
grey wolf
LET FORTRAN DIE!
Upgrade to 2.6.23 right now? Are you out of your mind? Everyone knows you're supposed to wait for the SP1 release before upgrading to a new operating system!
You do realize that many of the options in the kernel are mutually exclusive? You use the slab or slub allocator...only one of them gets included when the kernel is built.
The CFS scheduler actually *simplifies* the code as compared to the old one, as does the new readahead code.
Sure, the size of the kernel source code is continually increasing, but most of the increase is for hardware drivers. Also, the running binary doesn't increase in size nearly as fast as the source does...and as others have mentioned, you can always turn off the stuff you're not using to shrink it back down.