Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Open Source Operating Systems Upgrades Linux

Linux 3.5 Released 277

diegocg writes "Linux 3.5 has been released. New features include support for metadata checksums in Ext4, userspace probes for performance profiling with systemtap/perf, a simple sandboxing mechanism that can filter syscalls, a new network queue management algorithm designed to fight bufferbloat, support for checkpointing and restoring TCP connections, support for TCP Early Retransmit (RFC 5827), support for android-style opportunistic suspend, btrfs I/O failure statistics, and SCSI over Firewire and USB. Here's the full changelog."
This discussion has been archived. No new comments can be posted.

Linux 3.5 Released

Comments Filter:
  • by macemoneta ( 154740 ) on Saturday July 21, 2012 @08:29PM (#40726697) Homepage

    I accidentally replied to the wrong thread. Repost:

    Btrfs is stable enough for real data, if you run current releases (latest 3.4 or 3.5 kernel and btrfs-progs-19 current). I use it in both single drive systems and raid1 configurations with Fedora 17. Prior to converting the systems, I ran extensive failure testing (e.g., pulling power / data connection during active writes, system crashes, using a failing drive with media errors as part of a raid1, etc.) for about a month. I never lost a single byte of data in any test, confirmed by checksum scans on all data (against a backup) after each test cycle.

    I actually trust btrfs now more than ext4 due to the ability to scrub the data and confirm integrity, which I do daily or weekly depending on the system.

  • by macemoneta ( 154740 ) on Saturday July 21, 2012 @08:53PM (#40726827) Homepage

    With the current implementation and just the 'autodefrag' option added to default, there is no perceptable difference in performance compared to ext4 for any of our machines, with any application. Recent testing at Phoronix (with 3.4) has btrfs getting closer to ext4 (running without lvm2 and md raid); I'm curious to see how its numbers look in 3.5. However, because btrfs integrates the functionality of lvm2 and md raid in a much more usable manner, as well as providing much more functionality, a small performance tradeoff would be acceptable (to me).

  • Re:Ha ha he he (Score:5, Informative)

    by El_Oscuro ( 1022477 ) on Saturday July 21, 2012 @09:23PM (#40726955) Homepage
    Also on ereaders. According to Wikipedia [], almost all of the major brands run Linux.
  • Re:Ha ha he he (Score:3, Informative)

    by Anonymous Coward on Saturday July 21, 2012 @09:45PM (#40727053)

    iOS (which is BSD based) runs the majority of phones and tablets in use, while Android has the majority of the rest.

    Citation? I smell an Apple fanboy. []

    Android continues to lead the smartphone market in the U.S., with a majority of smartphone owners (51.8%) using an Android OS handset. []

    For tablets, Apple has a lead, but the numbers are quite low for total number of devices. []

    So overall, Android is king in marketshare. Not sure how you got "apple runs majority of phones and tablets". Maybe "only tablets, for now, because of headstart".

  • by Anonymous Coward on Saturday July 21, 2012 @10:54PM (#40727305)

    It's a way of transferring TCP connections to another server (along with transferring the IP address). That way, you could do hardware maintenance on the physical machine without losing anything because you've migrated it seamlessly to another machine. Of course, you have to transfer and restore everything else over too (running processes, memory, etc).

  • by sjames ( 1099 ) on Saturday July 21, 2012 @11:10PM (#40727383) Homepage Journal

    It's part of the larger project for process/system checkpointing in general.

    That is, saving the entire state of a process to storage such that it can start up again where it left off and not know the difference.

  • Re:Ha ha he he (Score:2, Informative)

    by cheesybagel ( 670288 ) on Saturday July 21, 2012 @11:14PM (#40727405)
    Android not only supports different resolutions but also different aspect ratios. There is a reason why Apple keeps selecting the same aspect ratio over and over again...
  • What do you mean? (Score:5, Informative)

    by billstewart ( 78916 ) on Saturday July 21, 2012 @11:36PM (#40727507) Journal

    Back when I was running X Windows versions 10.x and early 11s, there was no requirement that I use TWM. And while the Sun 2 came with SunView, the Sun 3 could run either SunView or X, and you could get Grasshopper Group's implementation of NeWS if you preferred, which drove your screen in Postscript. Among other things, that meant that if you wanted to change the font size to match the size of your monitor and your eyesight, you just did it, and What You Saw Was What You Wanted. None of this "need a third-party developer's hack to use the full resolution of the expensive Retina Display you just bought" nonsense. But even if you were running X, you weren't limited to Motif or OpenLook; you could run whatever window manager you liked with it.

    As far as "Ubuntu [does] not [have an SDK]" goes, you can use the Gnome SDK or KDE or LXDE or several other fairly full-featured SDKs.

  • Re:BTRFS (Score:3, Informative)

    by jarfil ( 1341877 ) on Sunday July 22, 2012 @02:35AM (#40728137) Homepage

    I've been using BTRFS in production since 3.3.1 with zero problems.

    Before that, I did experience a partial fs meltdown on 3.2.x while stress testing a high number of snapshots with several million files/dirs and intense db activity. Then, the same test on 3.3.1 went flawlessly.

    So I wouldn't recommend using BTRFS with anything below 3.3.1, but 3.4 or 3.5 should be fine.

  • Re:Ha ha he he (Score:3, Informative)

    by Anonymous Coward on Sunday July 22, 2012 @05:39AM (#40728713)

    How the fuck did this get modded "insightful"? iPads and iPhones already have different aspect ratios (1.33 vs. 1.5).

  • by macemoneta ( 154740 ) on Sunday July 22, 2012 @06:29AM (#40728863) Homepage

    This was a bug that was corrected (it was a problem in cache flushing []). All my testing occured after the bug was addressed, and pulling drive data cables while actively writing, as well as pulling drive power cables, was part of my testing. No data loss occurred in any test. The btrfsck and btrfs scrub/balance were able to correct all errors that resulted following the drive recovery.

Time to take stock. Go home with some office supplies.