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.
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..
OpenBSD still supports '386 processors
Karma: Excellent. 15 moderator points expire sometime.
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"
You are very welcome to FreeBSD. :-)
"... 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.
No, F2FS is not meant for bare NAND and doesn't do wear-levelling. It is meant for cheap flash media such as USB flash drives, SD cards, eMMC and such. Those devices have controllers that perform wear-levelling and other flash-translation layer functions. They present as block devices just like SSDs and regular hard drives. Conventional filesystems such as ext4 are optimized for spinning-rust and have to manage things like the fact that random access takes a significant amount of time while it has to wait for the next sector to come underneath the read/write head. With flash media, the seek time is zero but erasing a block takes a long time. There are of course many other differences. F2FS is designed to exploit the advantages of flash media and cope with the disadvantages. That said, I don't think I'd want to run F2FS on an SSD. SSDs have sophisticated controllers that try to compensate for the advantages and disadvantages of flash media with respect to conventional filesystems. I think you'd wind up with F2FS fighting it out with the SSD controller and I think perform would suffer as a consequence.
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.
I used FreeBSD for a couple of years, and I really only had one major complaint about it.
/usr/local. (Note for Linux users: this is a lot more stuff than you think. For example, bash is in /usr/local and would probably have to be recompiled. The base system is extremely limited. It includes the boot loader, the kernel, a handful of core libraries such as libc, some essential low-level things like init, and a few of the very oldest and most basic Unix commands, such as ls and cat.) I was on dialup at the time, so downloading fresh versions of every single thing, just to upgrade one thing, got old. (Gentoo has the same problem.) So once sarge came out I switched back to Debian.
My one complaint was, you have to recompile about 95% of the software on your computer from source every single time you want to upgrade anything at all. So, for example, if you want to upgrade your web browser, you'll be recompiling everything it depends on right down to the widget set plus everything that depends on any of that plus anything that depends on those things, and so on, recursively. Basically, you end up recompiling pretty much the entire ports tree every single time you upgrade anything. The only stuff you *don't* have to compile is the "base system" i.e., the stuff that's not in
But that's really my only major complaint about FreeBSD, after using it as the only OS on my home computer for about two years.
Cut that out, or I will ship you to Norilsk in a box.
Exactly, its meant to deal with a Flash Translation Layer
... you'll be recompiling everything it depends on right down to the widget set plus everything that depends on any of that plus anything that depends on those things, and so on, recursively.
I always saw it as a feature than when a library maintainer fixed a bug, it'd get fixed in all the software that was using said library; or a any libraries that was wrapping that library, or any software that was using that wrapper...
So has Linux dropped support for the Motorola/Freescale 68k series of CPUs? I thought that Linux is determined to support everything that exists in electronics
They seem to have changed that now w/ EasyPBI and pkgng. Might be worth trying again.
> when a library maintainer fixed a bug, it'd get fixed
> in all the software that was using said library
That's the argument in favor of dynamic linking. If everything were statically linked, instead of dynamically linked, when the developers of libpng (or whatever) fixed a bug, you'd have to recompile every package that uses libpng *if* you want them all to have the fix.
That's irrelevant to the ports tree, though, because it *does* use dynamic linking. The reason you have to recompile everything both up and down the dependency chain in the ports tree is... actually, I'm not sure exactly why. Maybe it was just designed wrong, I don't know.
They were working on a system that was supposed to at least partly fix this, called "packages", wherein you could download pre-compiled versions of things, but at the time when I was using FreeBSD (back before Debian sarge was released -- FreeBSD was version 5.something IIRC) the packages system was not entirely ready for prime time. A lot of the ports didn't have corresponding packages, and using both ports and packages at the same time was problematic, and to make a long story short it didn't solve the problem.
It is likely that the packages system has improved since then. Whether it entirely solves the problem of needing to recompile eighty bazillion things every time you just want to upgrade one application, I don't know.
I will probably experiment with BSD of one flavor or another again at some point in the future, but I'm not in a big hurry about it. There's no fire. BSD isn't going anywhere. It'll still be around the next time I'm in the mood to do a fresh OS install, or the time after that. Right now my system is running Debian stable, and I'm comfortable with that.
Cut that out, or I will ship you to Norilsk in a box.
I have always intended at some point to try out BSD again -- although I may go for one of the other distributions next time (OpenBSD, perhaps), in order to broaden my experience base. However, with the level of customization that I'm accustomed to, I don't go for clean OS installs without a very solid reason. Installing a new OS from scratch means several weeks of annoyance that gradually tapers off as I find and fix thing after thing after thing after thing that wasn't quite the way I wanted it to be. Right now my system is very nearly perfect -- to the point where, when wheezy comes out, I'm probably going to procrastinate the upgrade for a few months, even though in-place upgrades (particularly with a halfway decent package system like apt) are nowhere near as painful as clean installs.
But yeah, eventually I'll try out BSD again.
Cut that out, or I will ship you to Norilsk in a box.