Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux 3.8 Released

Unknown Lamer posted about a year and a half ago | from the busy-kernel-hackers dept.

Operating Systems 120

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."

cancel ×

120 comments

Sorry! There are no comments related to the filter you selected.

First Linux 3.8 Post (3, Funny)

Anonymous Coward | about a year and a half ago | (#42943517)

First post running Linux 3.8 Kernel!

Why should I care? (-1)

Anonymous Coward | about a year and a half ago | (#42944971)

The best kernel out there is WinNT 6.2. Everything else is a joke.

Re:First Linux 3.8 Post (1)

non-e-moose (994576) | about a year and a half ago | (#42949447)

Liar and/or Troll.

I'm confused (4, Funny)

SimonTheSoundMan (1012395) | about a year and a half ago | (#42943539)

I thought we were on 2.6 for eternity. Where did 3.8 come from all of a sudden?

Re:I'm confused (0)

Anonymous Coward | about a year and a half ago | (#42943565)

WAKE UP sweet heart.
Its being version 3 for ages now.

Re:I'm confused (0)

Anonymous Coward | about a year and a half ago | (#42943581)

wat

Re:I'm confused (5, Funny)

neonsignal (890658) | about a year and a half ago | (#42943587)

let me guess, you're running Debian stable?

Re:I'm confused (1)

ravenswood1000 (543817) | about a year and a half ago | (#42943701)

Yep, great stuff

Re:I'm confused (0)

Anonymous Coward | about a year and a half ago | (#42943717)

2.6.32 forever!

(Or, y'know, until Wheezy goes stable later this year and we get upgraded all the way to 3.2.)

Re:I'm confused (2)

kthreadd (1558445) | about a year and a half ago | (#42943805)

Hey I'm still on 2.6.18!

Re:I'm confused (0)

Anonymous Coward | about a year and a half ago | (#42944145)

our firewall (based on slackware), is still running 2.4.something.

Re:I'm confused (0)

Anonymous Coward | about a year and a half ago | (#42945107)

RHEL 5, much?

Re:I'm confused (1)

Forty Two Tenfold (1134125) | about a year and a half ago | (#42944215)

Wheezy goes stable when it's ready

FTFY.

Re:I'm confused (1)

jonadab (583620) | about a year and a half ago | (#42948873)

I'm running Debian stable, and yeah:
nathan@donalbain:~$ uname -a
Linux donalbain 2.6.32-5-486 #1 Mon Oct 3 03:34:28 UTC 2011 i686 GNU/Linux

Though, doesn't wheezy also still have Linux 2.6? I could've sworn.

Re:I'm confused (4, Informative)

SJHillman (1966756) | about a year and a half ago | (#42943595)

0.01 - 1991
1.0 - 1994
1.2 - 1955
1.3 - 1995
2.0 - 1996
2.1 - 1996
2.2 - 1999
2.3 - 1999
2.4 - 2001
2.5 - 2001
2.6 - 2003
3.0 - 2011
3.2 - 2012

Of course, there were many smaller version numbers released in the meantime - 2.4.37.11 was released in 2011, ten years after 2.4.0.

Re:I'm confused (5, Funny)

SJHillman (1966756) | about a year and a half ago | (#42943625)

You'll notice version 1.2 included the short-lived Typo Flux Capacitor, causing it to go back in time to prevent the birth of Bill Gates (Oct 28, 1955) but was ultimately unsuccessful.

Re:I'm confused (5, Funny)

Anonymous Coward | about a year and a half ago | (#42943887)

Transtemporal Agent Gates has done sterling work preventing the monolithic IBM from utterly dominating the computing world with VT52 terminals connected to reel-to-reel storage mainframes. Whilst he has failed to facilitate the development of the desired Quantum Hurd Desktop the situation could have been much, much worse. Unfortunately the Balminator droid appears to be defective - it should be running Symbian, not something simian.

Re:I'm confused (0)

Anonymous Coward | about a year and a half ago | (#42944067)

2.2 - 1999
2.3 - 1999
2.4 - 2001
2.5 - 2001
2.6 - 2003
3.0 - 2011

So it took eight years for Linux kernel to overcome the latent heat of Web 2.0?

Re:I'm confused (1)

Anonymous Coward | about a year and a half ago | (#42944167)

Well, you left off the important part: That as of Linus deciding not to do a 2.6.* kernel for eternity, he also decided not to have said little number releases. Hence the greatly increased speed with which the version numbers are rising. The next number after 3.8 will not be 3.8.1, or 3.8.1932737 as in days of old, but rather, 3.9 (for testing), and 4.0 for main release.

Re:I'm confused (1)

Anonymous Coward | about a year and a half ago | (#42944199)

No, you're confused, too. Odd numbered releases are not "testing" and haven't been for a while. 3.7 was a stable release, and 3.9 will be as well.

And I'm pretty sure it will go to 3.10, not 4.0.

Re:I'm confused (1)

They'reComingToTakeM (1091657) | about a year and a half ago | (#42946209)

It's Gnome who use odd numbers for testing & even for release, not Linus.

Re:I'm confused (0)

Anonymous Coward | about a year and a half ago | (#42947441)

No, Linux was in fact doing that even a couple of years before Gnome existed. Linux 2.1, 2.3 and 2.5 were unstable/testing versions. That practice ended with Linux 2.6, I believe.

Re:I'm confused (1)

Alwin Henseler (640539) | about a year and a half ago | (#42943597)

After 3.0, 3.2, 3.4, 3.5, 3.6, and 3.7 series? (and some more development versions in between)

Glad to see you crawled out from under that rock, though.

Re:I'm confused (2)

JustOK (667959) | about a year and a half ago | (#42943829)

I'm waiting for the service pack

Re:I'm confused (1)

DiamondGeezer (872237) | about a year and a half ago | (#42944605)

This IS the service pack you insensitive clod!

Re:I'm confused (2)

BenJury (977929) | about a year and a half ago | (#42944029)

Confused by an incrementing number? May I suggest this site isn't for you.

Re:I'm confused (1)

Anonymous Coward | about a year and a half ago | (#42944327)

That's strange, every time there's an article about Firefox, the vast majority of the commenters are confused and upset about version numbers incrementing.

Re:I'm confused (1)

BenJury (977929) | about a year and a half ago | (#42944953)

I don't understand that either. Just from a developers point of view, I've always said its easier to check the version of the browser using an int rather than having to parse something like '2.33.23.rc8'.

Re:I'm confused (0)

Anonymous Coward | about a year and a half ago | (#42944347)

For 3 versions the 3rd digit was dropped. So 3.X increments as quickly as 2.6.X, of which there were many.

Re:I'm confused (1)

K. S. Kyosuke (729550) | about a year and a half ago | (#42945015)

I thought we were on 2.6 for eternity. Where did 3.8 come from all of a sudden?

That's the inflation, all the "stable numbers" had to be adjusted.

Re:I'm confused (1)

davester666 (731373) | about a year and a half ago | (#42947699)

Just trying to catch up to FireFox...

Is this the version... (-1)

Anonymous Coward | about a year and a half ago | (#42943547)

That makes Linux ready for the mainstream desktop? Or is it still as user friendly as a penile self amputation kit?

Re:Is this the version... (0)

kthreadd (1558445) | about a year and a half ago | (#42944645)

It depends, we haven't seen the outcome of the GNOME 3.8 release yet.

Re:Is this the version... (1)

Runaway1956 (1322357) | about a year and a half ago | (#42945283)

Mate for me. Self flagellation is just not my thing.

http://mate-desktop.org/ [mate-desktop.org]

Re:Is this the version... (0)

Anonymous Coward | about a year and a half ago | (#42944821)

Don't confuse the Linux kernel with the user space abominations that are the current popular window managers/GUIs.

still supports 32-bit Intel binaries (1)

Anonymous Coward | about a year and a half ago | (#42943561)

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? [intel.com] ) were dropped. Anyone who still has one of those should call Steve at Dell.... oops, I guess he's been dropped too. Sorry.

Re:still supports 32-bit Intel binaries (5, Interesting)

SimonTheSoundMan (1012395) | about a year and a half ago | (#42943607)

Intel's latest generation of desktop i5/i7 CPUs appear to be buggy. People I know working in CFD are finding all sorts of quirks so have gone back to older and slower Xeons. Nothing for the desktop series is documented for bugs as far as I'm aware, I don't think Intel test them as much in design as workstation grade CPUs, and published bugs for Xeons you're not allowed to talk about them.

Re:still supports 32-bit Intel binaries (0)

Anonymous Coward | about a year and a half ago | (#42943683)

What do you mean, you're not allowed to talk about Intel bugs? That would be a front page story there.

Re:still supports 32-bit Intel binaries (0)

Anonymous Coward | about a year and a half ago | (#42944465)

If you want the documentation of what the bugs are you are restricted to a NDA.

Re:still supports 32-bit Intel binaries (0)

Anonymous Coward | about a year and a half ago | (#42943697)

Can you provide some kind of information on this? I would really like to know what CPUs to avoid.

Re:still supports 32-bit Intel binaries (4, Insightful)

Pharmboy (216950) | about a year and a half ago | (#42944783)

Can you provide some kind of information on this? I would really like to know what CPUs to avoid.

If you are looking to avoid all errata, then buy an abacus. All CPUs have bugs.

Re:still supports 32-bit Intel binaries (1)

Runaway1956 (1322357) | about a year and a half ago | (#42945337)

An abacus? Come on, man, some of us are all thumbs and incapable of operating a mechanical device like an abacus!

http://www.esl-resources.com/lit/html/04_allthumbs.jpg [esl-resources.com]

Re:still supports 32-bit Intel binaries (0)

Anonymous Coward | about a year and a half ago | (#42946683)

Missing your thumbs?! Well then, base 8 is for you!

Re:still supports 32-bit Intel binaries (1)

Anonymous Coward | about a year and a half ago | (#42943713)

Intel's latest generation of desktop i5/i7 CPUs appear to be buggy.

Is this why your website is serving gzipped binary :P

People I know working in CFD are finding all sorts of quirks

Such as?

and published bugs for Xeons you're not allowed to talk about them.

???

Re:still supports 32-bit Intel binaries (1)

vbraga (228124) | about a year and a half ago | (#42943813)

Funny, we do a lot of HPC and had some problems with Ivy Bridge. But I think it's just some hand optimizations for previous architectures gone wrong.

Anyone else had similar experiences?

Re:still supports 32-bit Intel binaries (4, Interesting)

serviscope_minor (664417) | about a year and a half ago | (#42943901)

Intel's latest generation of desktop i5/i7 CPUs appear to be buggy. People I know working in CFD are finding all sorts of quirks so have gone back to older and slower Xeons.

One difference is that the intel desktop CPUs generally don't have ECC whereas the Xeon ones do.

Do the new i7s produce consistent results each time? If so, then lack ECC isn't the problem.

There could also be some subtle difference in IEEE modes.

You could try dumping everything from every stage of the algorithm out and seeing when two runs start to differ.

Re:still supports 32-bit Intel binaries (1)

NJRoadfan (1254248) | about a year and a half ago | (#42944325)

I currently have a Xeon E3110 in my main desktop. It is nothing more then a re-branded Core2Duo E8400 and does not have ECC.

Re:still supports 32-bit Intel binaries (0)

Anonymous Coward | about a year and a half ago | (#42945185)

You have a 5 year old part: back then they didn't put the memory controller in the CPU, the ECC support was dependent on the chipset.
Things have changed in the last few years, and now it's dependent on the CPU to support ECC; the Sandy and Ivy Bridge Xeons do, the non-Xeons don't.

Re:still supports 32-bit Intel binaries (4, Informative)

peppepz (1311345) | about a year and a half ago | (#42944187)

Isn't it normal for any processor to have errata? There are currently 95 bugs listed for Ivy Bridge on Intel's site [intel.com] . There are 120 for Sandy Bridge [intel.com] .

Re:still supports 32-bit Intel binaries (2)

jbdigriz (8030) | about a year and a half ago | (#42944513)

Links?

Re:still supports 32-bit Intel binaries (1)

jbdigriz (8030) | about a year and a half ago | (#42946507)

Never mind, found 'em.

Re:still supports 32-bit Intel binaries (2, Informative)

Anonymous Coward | about a year and a half ago | (#42943667)

Specifically the actual i386 family is no longer supported. The i486 family, including the 486SX (which doesn't even have floating point) are still technically supported by the Linux kernel, you just won't find very much software to run on them. So we're not just talking "before the Pentium" but further back in history. There are i486 PCs dating back to 1989, think Dead Poets Society. So Linux still runs on hardware that's older than Linux, just not hardware that was already /cheap/ when Linux began.

Re:still supports 32-bit Intel binaries (1)

muckracer (1204794) | about a year and a half ago | (#42944813)

Hey...my PC is a 386, you insensitive Captain!! :-o

Removal of support for 386? (0)

Anonymous Coward | about a year and a half ago | (#42943601)

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.

Re:Removal of support for 386? (0)

Anonymous Coward | about a year and a half ago | (#42946701)

Greenhorn.

I remember chatting with him at the bar about his intention to make a post to comp.os.minix.

Just a worry (5, Interesting)

hcs_$reboot (1536101) | about a year and a half ago | (#42943677)

ext4 has been altered with added functionalities - I will wait some time before applying the upgrade, just to be sure ext4 is stable again...

Re:Just a worry (1)

DiamondGeezer (872237) | about a year and a half ago | (#42943741)

Ssssshhhhhhh Linux is rock solid. Pass it on

Re:Just a worry (5, Funny)

msauve (701917) | about a year and a half ago | (#42943785)

Linux is a crock of salad. Pass it on.

Re:Just a worry (4, Funny)

Anonymous Coward | about a year and a half ago | (#42943833)

Linus got a rock and sold it. Passion on.

Re:Just a worry (1)

Anonymous Coward | about a year and a half ago | (#42943981)

Lupus got Spock and ole' Nick. Passed on...

Re:Just a worry (1)

Anonymous Coward | about a year and a half ago | (#42944087)

Locust hot Frog an oiled sick. Phased on...

Re:Just a worry (2, Funny)

Anonymous Coward | about a year and a half ago | (#42944309)

Oiled Frog on a stick. Got pissed on..

Re:Just a worry (0)

Anonymous Coward | about a year and a half ago | (#42944751)

Old frags got sick. Got a piston.

Re:Just a worry (1)

djlemma (1053860) | about a year and a half ago | (#42946527)

Cold bags, hot pick. Go tap Stan.

Re:Just a worry (0)

Anonymous Coward | about a year and a half ago | (#42944011)

Rhinos got a rocket soldier. Brass onion.

Re:Just a worry (4, Funny)

wonkey_monkey (2592601) | about a year and a half ago | (#42944101)

My hovercraft is full of eels. Purple monkey dishwasher.

Re:Just a worry (1)

Zordak (123132) | about a year and a half ago | (#42944235)

I hereby Godwin this thread on your comparison of Natalie Portman to Adolf Hitler. And what you do in your spare time is your own business. Please just keep it to yourself.

Re:Just a worry (0)

Anonymous Coward | about a year and a half ago | (#42948547)

Microsoft on rack server. Bad option.

Re:Just a worry (0)

Anonymous Coward | about a year and a half ago | (#42943969)

If you want stability you wouldn't be using ext.

XFS

Re:Just a worry (0)

Anonymous Coward | about a year and a half ago | (#42946843)

Is that the one that consistently wipes out all your open files on a hard reboot?

question remains... (2)

Razgorov Prikazka (1699498) | about a year and a half ago | (#42943775)

...Does it run linux?

Re:question remains... (2)

Kinwolf (945345) | about a year and a half ago | (#42944149)

In emulation mode only

Re:question remains... (1)

DiamondGeezer (872237) | about a year and a half ago | (#42944653)

But it exists to run Wine better. I wonder if there's a better way...

Re:question remains... (1)

Bigby (659157) | about a year and a half ago | (#42945597)

Or in Soviet Russia; does Linux run it?

Re:question remains... (0)

Anonymous Coward | about a year and a half ago | (#42949849)

Of course [wikipedia.org]

That's it! (-1)

Anonymous Coward | about a year and a half ago | (#42943779)

Ubuntu destroys my privacy! I'm moving to Mi...oh...we're not stroking that phallos yet?

fir5T (-1)

Anonymous Coward | about a year and a half ago | (#42943831)

So that you don't continues toChew sling, return it to Writing is on the confirmed that *BSD states that there used to. SHIT ON antibacterial soap. If *BSD is to BSD machines and as BSD sinks = 36640 FreeBSD engineering project well-known legitimise doing fear the reaper and that the floor study. [rice.edu] bring your own Visions going needs OS. Now BSDI Slashdot 'BSD is fear the reaper Fucking percent of we all know, Anyone that thinks turd-suckingly dead. It is a dead Than make a sincere comprehensive guys are usually While the project shitheads. *BSD they started to and coders world's Gay Nigger design approach. As to have regular users', BigAzz, Are you GAY area. It is the

Pffft (1, Funny)

Anonymous Coward | about a year and a half ago | (#42944033)

Big deal. Windows 8 is 2.105 times better than Linux 3.8

Re:Pffft (1)

jonadab (583620) | about a year and a half ago | (#42948857)

That's why I use Emacs. Currently I have version 23.2, but I'm thinking about upgrading to version 24.

Use inode space for 1st part of large files? (2, Interesting)

Anonymous Coward | about a year and a half ago | (#42944391)

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..

Re:Use inode space for 1st part of large files? (0)

Anonymous Coward | about a year and a half ago | (#42944831)

That initial part of the file will also contain enough information for the OS to get useful metadata about the file without having to read the rest of the file, which may be useful for file listings, etc.

Re:Use inode space for 1st part of large files? (1)

ssam (2723487) | about a year and a half ago | (#42944905)

thats quite an interesting idea. I imagine it lots of cases the first few bytes of the file have header information. In some cases the header might be all you need to read. in other cases you might read the header to find out how much memory you need to allocate, then do the allocation, then read the rest of the file. so the little speed boost might be quite significant in many common cases.

on the other hand, there must be good reasons that the actual file data is not all stored with the metadata in the first place. so collapsing it back in there may not be a good idea.

Re:Use inode space for 1st part of large files? (5, Interesting)

crow (16139) | about a year and a half ago | (#42945519)

They probably store the file data in the same part of the inode that is otherwise used for the block list or extent list. So larger files must use that same space to tell the file system where the rest of the data is on the disk, which makes it difficult to also store data in the same location.

Also, putting a small amount of data into the inode would then mean that the rest of the file would no longer be neatly aligned on block boundaries, which makes doing a memmap of the file painful.

Re:Use inode space for 1st part of large files? (0)

Anonymous Coward | about a year and a half ago | (#42947371)

Once the data no longer fits in the inode, it gets copied to a normal block. See ext4_convert_inline_data_to_extent.

underwhelmed (0, Interesting)

Anonymous Coward | about a year and a half ago | (#42944453)

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?

Re:underwhelmed (1)

Anonymous Coward | about a year and a half ago | (#42946277)

You are very welcome to FreeBSD. :-)

Re:underwhelmed (1)

jonadab (583620) | about a year and a half ago | (#42949221)

I used FreeBSD for a couple of years, and I really only had one major complaint about it.

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 /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.

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.

F2FS (0)

Anonymous Coward | about a year and a half ago | (#42944555)

Why not choose UBIFS ?

Well, I guess I'm switching to OpenBSD then (3, Funny)

thomasdz (178114) | about a year and a half ago | (#42944773)

OpenBSD still supports '386 processors

Re:Well, I guess I'm switching to OpenBSD then (0)

Anonymous Coward | about a year and a half ago | (#42944895)

Or you could simply stay away from the bleeding edge

Re:Well, I guess I'm switching to OpenBSD then (0)

Anonymous Coward | about a year and a half ago | (#42946431)

Why? Do you have many 386 running? GLibC hasn't supported 386 processors for many years (a 486 is the minimum).

How do you choose a version? (1)

RogueWarrior65 (678876) | about a year and a half ago | (#42945051)

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?

that's what vendors are for (2)

Chirs (87576) | about a year and a half ago | (#42945523)

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.

Re:How do you choose a version? (1)

jonadab (583620) | about a year and a half ago | (#42949021)

> How do you go about choosing a kernel version?

I generally use the version that comes with my distribution. I think this is what most people do.

> at what point do you say "Yeah, that's good enough, let's ship it?"

Wait, are you asking from the perspective of a distributor?

In that case, I think the usual model is, when you fork/freeze each version of your distribution, you take the kernel version that's current at that time -- in fact, you take the version of every upstream package that's current at that time -- and from that point forward you generally only take newer versions for the trunk (i.e., for what will eventually be your _next_ version) unless there is an extremely compelling reason to import the newer version of a particular upstream package (e.g., major fundamental security or stability issues with fixes that can't be easily backported). For the most part at this point you just backport important bug fixes and continue testing internally until you are reasonably comfortable with the stability of the system, at which point you put out a beta release to get some wider testing. When the flow of incoming beta bug reports slows down and you've got the bugs all triaged and have fixed the ones you're going to fix, you put out a release candidate. Further bug reports that come in afterward can sometimes lead to point releases, but for the most part, once you release, your dev team should switch their focus over to the next version.

A 386 can't run the 3.8.6 kernel (1)

bzipitidoo (647217) | about a year and a half ago | (#42945959)

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.

Wow (2)

sootman (158191) | about a year and a half ago | (#42946539)

"... 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? ;-)

Re:Wow (1)

mister_playboy (1474163) | about a year and a half ago | (#42946747)

It could have been worse... they could have dropped support for 80386 processors.

F2FS is not for SSDs (0)

blitzkrieg3 (995849) | about a year and a half ago | (#42946965)

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.

Re:F2FS is not for SSDs (3, Informative)

ssimmons (22842) | about a year and a half ago | (#42948145)

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.

What about modern processors? (2)

non-e-moose (994576) | about a year and a half ago | (#42949029)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>