Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Upgrades Linux

Linux 3.8 Released 120

Posted by Unknown Lamer from the busy-kernel-hackers dept.
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."
This discussion has been archived. No new comments can be posted.

Linux 3.8 Released More

Linux 3.8 Released

Comments Filter:

  • First Linux 3.8 Post (Score:3, Funny)

    by Anonymous Coward on Tuesday February 19, 2013 @08:06AM (#42943517)

    First post running Linux 3.8 Kernel!

  • I'm confused (Score:5, Funny)

    by SimonTheSoundMan ( 1012395 ) on Tuesday February 19, 2013 @08:10AM (#42943539)

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

    • Re:I'm confused (Score:5, Funny)

      by neonsignal ( 890658 ) on Tuesday February 19, 2013 @08:19AM (#42943587)

      let me guess, you're running Debian stable?

    • Re:I'm confused (Score:5, Informative)

      by SJHillman ( 1966756 ) on Tuesday February 19, 2013 @08:19AM (#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 (Score:5, Funny)

        by SJHillman ( 1966756 ) on Tuesday February 19, 2013 @08:22AM (#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 (Score:5, Funny)

          by Anonymous Coward on Tuesday February 19, 2013 @08:54AM (#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: (Score:1)

        by Anonymous Coward

        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: (Score:1)

          by Anonymous Coward

          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.

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

    • 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: (Score:3)

      by JustOK ( 667959 )

      I'm waiting for the service pack

    • Re: (Score:3)

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

      • Re: (Score:1)

        by Anonymous Coward

        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: (Score:2)

          by BenJury ( 977929 )
          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'.

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

    • Just trying to catch up to FireFox...

  • still supports 32-bit Intel binaries (Score:1)

    by Anonymous Coward

    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 (Score:5, Interesting)

      by SimonTheSoundMan ( 1012395 ) on Tuesday February 19, 2013 @08:21AM (#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: (Score:2, Informative)

      by Anonymous Coward

      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.

  • Just a worry (Score:5, Interesting)

    by hcs_$reboot ( 1536101 ) on Tuesday February 19, 2013 @08:30AM (#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...

  • question remains... (Score:3)

    by Razgorov Prikazka ( 1699498 ) on Tuesday February 19, 2013 @08:40AM (#42943775)
    ...Does it run linux?

  • Pffft (Score:1, Funny)

    by Anonymous Coward

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

    • Re: (Score:1)

      by jonadab ( 583620 )
      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? (Score:2, Interesting)

    by Anonymous Coward

    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: (Score:2)

      by ssam ( 2723487 )

      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 fir

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

      by crow ( 16139 ) on Tuesday February 19, 2013 @11:24AM (#42945519) Homepage Journal

      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.

    • There are plenty of disk-sensitive applications that deliberately do block-aligned accesses into a file; and I imagine a lot of those would be very put out by such a change.

      • The obvious solution to my own argument would be to instead duplicate the data into any space left in the inode

        Very interesting... continue.

  • Well, I guess I'm switching to OpenBSD then (Score:4, Funny)

    by thomasdz ( 178114 ) on Tuesday February 19, 2013 @10:17AM (#42944773)

    OpenBSD still supports '386 processors

  • 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 syst

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

      • OK. The bug in question specifically relates to the Cirrus Logic EP93xx architecture. In 3.0.13, there was a change to the kernel having to do with timing that caused usleep and similar timing calls to become pretty wildly inconsistent. If my kernel HZ was set to 1000 hertz, and I checked timing with commonly available code snippets, I used to get values that were usually within 3 or 4 hertz and one microsecond usleeps had about the same deviation. In 3.0.13, however, the measured kernel frequency varie

      • Oh, and the vendor supported kernel didn't have things like JFFS or Ext3 or mdev so I had to roll my own.

    • Re: (Score:1)

      by jonadab ( 583620 )
      > 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 t
    • Stick with the stable kernel which come with your distro, unless you run a rolling-release distro in which case you always udpate to the latest kernel.
  • 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 (Score:3)

    by sootman ( 158191 ) on Tuesday February 19, 2013 @12:54PM (#42946539) Homepage Journal

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

  • 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: (Score:3, Informative)

      by ssimmons ( 22842 )
      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 wa
  • 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.

    • It helps to provide context to what you're talking about.

      PDF [rice.edu] from mid last year on performance tools, page 26 documents the LWP issues with the kernel.

      It looks like integration with the kernel and getting upstream is a task for AMD. So it is unfortunate, but entirely AMD's problem as an Intel variant is already in kernel apparently.

Slashdot Top Deals

"If the code and the comments disagree, then both are probably wrong." -- Norm Schryer

Close