Slashdot Mirror
Linux 3.8 Released
diegocg writes "Linux kernel 3.8 has been released. This release includes support in Ext4 for embedding very small files in the inode, which greatly improves the performance for these files and saves some disk space. There is also a new Btrfs feature that allows for quick disk replacement, a new filesystem F2FS optimized for SSDs; support for filesystem mount, UTS, IPC, PID, and network namespaces for unprivileged users; accounting of kernel memory in the memory resource controller; journal checksums in XFS; an improved NUMA policy redesign; and, of course, the removal of support for 386 processors. Many small features and new drivers and fixes are also available. Here's the full list of changes."
First post running Linux 3.8 Kernel!
I thought we were on 2.6 for eternity. Where did 3.8 come from all of a sudden?
Confusingly, 32-bit x86 binaries are often packaged with a "i386" suffix. These should still be supported. Only support for the ancient 32-bit Intel CPUs before the Pentium era of the mid-90's (remember the floating point bug?) were dropped. Anyone who still has one of those should call Steve at Dell.... oops, I guess he's been dropped too. Sorry.
I still remember Linus' first post on comp.os.minix, he was writing the OS specifically to support the 386 MMU. Time marches on, I guess.
ext4 has been altered with added functionalities - I will wait some time before applying the upgrade, just to be sure ext4 is stable again...
Slashdot, fix the reply notifications... You won't get away with it...
...Does it run linux?
rm -rf --no-preserve-root /
Big deal. Windows 8 is 2.105 times better than Linux 3.8
From TFA it seems that large files won't benefit from the change in ext4. This seems an odd strategy.
Wouldn't it have made more sense to put the first part of the file data into the inode regardless of the size of the file ? That way every file would get an initial access speed boost by omitting seek latency, and large inodes would get used very effectively..
this release broke my machine. looks like i'll be on 3.7 until my hardware dies. i have been really disappointed with the flaky quality of the past 4 or 5 kernel releases. i get the feeling that pulling in android introduced some weird instabilities with the power management. i have enjoyed using linux for almost a decade now but sadly it looks like i will be moving to a different OS the next time i purchase a new system. if anyone here is involved with kernel development can you explain why things have been going downhill so fast lately?
Why not choose UBIFS ?
It depends, we haven't seen the outcome of the GNOME 3.8 release yet.
OpenBSD still supports '386 processors
Karma: Excellent. 15 moderator points expire sometime.
Don't confuse the Linux kernel with the user space abominations that are the current popular window managers/GUIs.
Here's a general kernel question: How do you go about choosing a kernel version? With new second-digit releases coming out every few months and with third-digit releases for older second-digit versions coming out even faster and continuing to be maintained long after a new second-digit release, at what point do you say "Yeah, that's good enough, let's ship it?" The change logs are so extensive that I find myself unable to determine if going through the work to tweak and build a kernel for an embedded system is worth it. In one case, I found that a serious bug was introduced in the arch files for the 3.0.x kernel series which is still being maintained. It's up to 3.0.65 as of 2/17. I had to build about a dozen kernels before I figured out in which version the bug was introduced. Ultimately, it's a huge time suck to deal with but I'm concerned that I may be missing some useful change or bug fix that is lurking in the shadows. Thoughts? Anyone? Anyone? Bueller?
Mate for me. Self flagellation is just not my thing.
http://mate-desktop.org/
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
but if you don't want to pick a vendor-supported one, then at least pick one of the "long-term-support" kernels. These are ones that the kernel developers have committed to backporting fixes to for longer than usual. The most recent "long-term-support" kernel is 3.4 (will be supported for at least 2 yrs), the previous (and still-supported) one was 3.0.
In the case of an bug introduced in 3.0.x, definitely that should be reported. Normally that sort of thing doesn't happen in stable kernels.
And we'll likely have version 3.8.6. Should've bumped the version to 4.0. Aside from the cute version/processor name match, dropping support for the 386 seems a major enough change to warrant the change in version numbering.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
"... the removal of support for 386 processors..."
Wow, that's a lot of CPUs to deprecate in one release. Does anyone have a list of the three hundred and eight-six processors that are no longer supported? ;-)
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
It's actually a new filesystem for flash storage, which is cheap storage that does not have a controller to do wear leveling and other things. SSDs have firmware that are optimized for traditional filesystems such as ext4.
It is unfortunate that the Linux kernel still does not support a number of key features available in currently available hardware. Such as some features that Windows8 supports out-of-the box. Here's one example: AMD's LWP feature set. It requires XSAVE/XRSTOR, but has been rejected by the Linux kernel developers. No, I'm NOT an AMD employee. Yes I do own a couple of desktops based upon AMD cpus. Motivation: COST, COST, COST.