Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


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 twistedcubic ( 577194 ) on Saturday July 21, 2012 @08:00PM (#40726549)
    Now this looks interesting. Hopefully it works as described on the net (http://lwn.net/Articles/479841/). Automatic suspend would be wonderful.
  • by Peter H.S. ( 38077 ) on Saturday July 21, 2012 @08:04PM (#40726575) Homepage

    Ext4 metadata checksums. I like that. Note that it isn't data CRC checksums, just metadata. Still, I like the way Ext4 keeps evolving and getting tuned. Btrfs sounds really great, but it may still be some time before it is stable enough for my data storage needs.

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

    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.

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

    by ZosX ( 517789 ) <zosxavius@NOSpam.gmail.com> on Saturday July 21, 2012 @10:57PM (#40727317) Homepage

    Android scales graphis just fine IMO. if you run something like an older game that was designed for a lower dpi device, it just scales it. Generally you have the option to allow it to run smaller in its native resolution as well. Many of the android games use vectors for sprites, so asides from backgrounds looking pixelated, the sprites generally look pretty decent. I dunno, I went from a phone with an 800x480 display to a tablet with a 1280x800 display. If you ask me, android, at least ICS and beyond, handles high resolutions very well. It will scale the UI to match the dpi of the phone. I don't think apple has any real advantage here.

  • Kinda off subject here, but ...

    Your standard app was not written for silly-high DPR. You could show this on linux too: take your desktop, and crank the DPI to 300 or so, so that the X server thinks your screen is only 5" across. Now move far enough away from it that a 12 point font looks reasonable, and then look at how stupid apps look. Icons are microscopic (because they're defined in fixed pixel sizes). Layouts between menubars and borders look stupid (natural spacing was defined in fixed pixel sizes).

    So Apple's approach here is to tell the application that the screen is 1440x900. Any primitives that can be scaled ("place the string 'pants' in font 'Helvitica', size 12pt, at X,Y". "Draw this 2kx2k pixmap in this 500px x 500px space") are then rendered to the screen's native resolution. Things that can't be scaled aren't ("draw this 96x96 pixmap here, in this 96x96 space"). Some apps then look horrible, some look great.

    I personally would have rather they just let apps look like crap, and told people to fix their darn apps, but I can understand why they didn't.

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

    by sonamchauhan ( 587356 ) <sonamc@gmail.3.14159com minus pi> on Sunday July 22, 2012 @03:49AM (#40728385) Journal

    The Linux desktops of old got transformed into Linux server, were gratefully used by Google for their server infrastructure.

    Then, as mobile phone hardware began to resemble the desktops of yesteryear, Google went "hmmmm..."

    And so it flows.

  • by Anonymous Coward on Sunday July 22, 2012 @06:40AM (#40728897)

    Here's a tip, though... if you hide everything from the user (a 'la original MacOS and returning to that I might add)

    They're not really hiding anything these days. They're mainly locking everything down, which is much worse. And fwiw, the original Mac OS didn't hide that much. You had to use ResEdit rather than emacs or vim to look at the internals of most stuff, but it's not like the average user knows what the /etc directory is, let alone what to change there (or even how to get sudo rights to do so, if the editor doesn't contain built-in functionality for that)

    One big problem with classic Mac OS was that everything was way too accessible, resulting in people installing tons of extensions and control panels that changed the behaviour of the system, often resulting in instability. That was of course compounded by the lack of memory protection and pre-emptive multi-tasking, since every change to system behaviour affected everything, all the time. But a lack of use-accessible system customisation is definitely not how I'd ever describe the classic Mac OS.

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

    by gbjbaanb ( 229885 ) on Sunday July 22, 2012 @10:14AM (#40729541)

    Linux always succeeded - only not anywhere you can see it.

    Linux still runs 80%+ of the world's internet, Linux runs a vast majority of embedded devices. This is the reason Google got into it - it already was there when Google appeared and started to think "what web OS do we use for our HPC system" - it was pretty obvious to them to use the market leader in those arenas - Linux - and when they decided to go for an embedded phone device, they again chose the market leader in that area - Linux.

    Linux made Google big, not the other way round.

  • by shutdown -p now ( 807394 ) on Sunday July 22, 2012 @08:20PM (#40732573) Journal

    I personally would have rather they just let apps look like crap, and told people to fix their darn apps

    Microsoft has had 20 years of track record with this approach, and the results are meh. Eventually Vista had to change the rules by requiring the apps to tell the system whether they are DPI-aware, and if they don't do that (e.g. all old apps), do bitmap scaling on them. Even so there are still quite a few apps written after Vista which do tell the system that they are DPI-aware, but then don't properly handle anything but the default 96 DPI.

  • by exomondo ( 1725132 ) on Sunday July 22, 2012 @11:25PM (#40733457)

    But still, SRSLY? You'd think Apple could get font scaling correct, especially since they've been selling big desktop displays for years.

    That still annoys me about OSX, you can't set the system font size.

  • Re:Ha ha he he (Score:4, Interesting)

    by makomk ( 752139 ) on Monday July 23, 2012 @07:15AM (#40734933) Journal

    The iPad has a different apect ratio from the iPhone, but that means that every existing application needed to have iPad support added explicitly in order to work well. Apple managed to get away with that since phone app UIs don't tend to scale too well on a 10-inch tablet anyway.

    Every iPhone still has the same aspect ratio as the original iPhone and every iPad the same as the original iPad, though. Not only that but Apple had to delay increasing the resolution of their devices until they could get displays with double the pixel density, whereas Android manufacturers could use intermediate screen resolutions, and apparently driving all those pixels has been killing battery life and GPU performance.

Executive ability is deciding quickly and getting somebody else to do the work. -- John G. Pollard