Linux 3.4 Released 385
jrepin writes with news of today's release (here's Linus's announcement) of Linux 3.4: "This release includes several Btrfs updates: metadata blocks bigger than 4KB, much better metadata performance, better error handling and better recovery tools. There are other features: a new X32 ABI which allows to run in 64 bit mode with 32 bit pointers; several updates to the GPU drivers: early modesetting of Nvidia Geforce 600 'Kepler', support of AMD RadeonHD 7xxx and AMD Trinity APU series, and support of Intel Medfield graphics; support of x86 cpu driver autoprobing, a device-mapper target that stores cryptographic hashes of blocks to check for intrusions, another target to use external read-only devices as origin source of a thin provisioned LVM volume, several perf improvements such as GTK2 report GUI and a new 'Yama' security module."
Re:They fix the sound bullshit yet? (Score:0, Insightful)
Pulse Audio has been working flawlessly for me for years now on all of my laptops and desktops. I'm especially happy with the ability to send audio to my media center over the network from any of my devices. It's changed how I listen to audio in my home and I could never go back to not having pulse audio. Also being able to combine multiple soundcards on my audio recording rig has saved me a mint on M-Audio hardware.
Re:yes but... (Score:3, Insightful)
At present there are two systems people use for audio, pulseaudio comes with most distributions these days standard (for end users, rather limited and full of latency) and JACK (for professional audio usage, uses a callback interface though)
low latency and low power tend to be at odds with each other, what with low latency frequently waking up the cpu etc. The only reason pulseaudio was went with on the desktop is for some reason they seem to think we care about a fraction of a percent more cpu usage on my plugged in desktop machine over a more useful audio subsystem. (Their reasoning being TABLETS ARE THE FUTURE!, or something along those lines)
Who cares why it needs it? (Score:5, Insightful)
It is something the FS should handle. The "Just fix the program," is a bad answer because while maybe one could change Firefox, you'll find another program that can't be changed because the nature of what it does requires many syncs.
The low level systems should be robustly written to do what apps need, they shouldn't be telling apps "You can't do that."
Re:btrfs needed the work (Score:5, Insightful)
kernel 3.2 was released only 5 months ago (Score:4, Insightful)
What is the rationale for moving up to 3.4 so soon?
Obviously big tech companies, as well as the Mozilla Foundation play the versioning game aggressively, but the Linux kernel always had a reputation of being conservative.
Re:btrfs needed the work (Score:5, Insightful)
Sync (or fsync) is the way to ensure that files are committed to disk and not just cached somewhere. This is a precondition for reliable "restore session" and similar functionality. However, application developers cannot rely on the OS to sync data in the background, because e.g. on a laptop where frequent disk access is both expensive (battery life) and risky (physical motion), the OS will cache as much as possible. If FF did not sync, the OS might delay writes for hours, which means a computer crash leads to lost hours of browsing history for the user. It doesn't sound like a big deal, but I can tell you that it is infuriating as a user to see a browser say, "whoops, I lost your tabbed windows, hope you weren't using the WWW for anything important!". Not having looked at the source myself, I don't know if it's possible to optimize FF's sync behavior; but I do know that it's impossible to eliminate it.
Re:btrfs needed the work (Score:5, Insightful)
no because if you lose a disk in a striped array you lose everything. (perhaps you are thinking raid1 in which case it protects you from disk failure but does not provide backups)
but soon they will be working on a btrfs send\receive system so you would be able to take snapshots and push to another disk
IMO there are a number of different failure states that you must cater for.
1. Human failures (the oh shit I deleted something): a snap shot capable file system helps protect you from these (not perfect but fairly good)
2. Hardware failures (disks are dead): traditional backup systems work here (or btrfs\zfs send\receive) disk failures can have reduced impact due to mirroring your data (or strip plus parity) checksums and COW help defend against silent failure
3. Software failures (the OS is hosed, partition table is dead): traditional backup systems work here (or btrfs\zfs send\receive) (though COW file systems and marking shit read-only helps)
4. oh shit the building burnt down: Hope you do offsite backups
BTRFS helps in the first 3 by bringing awesome features to the table (snapshots, COW(so you can walk back up the tree to recover) and mirroring your data on multiple disks) but is only something that can supplement a backup system not replace it at all
only a good backup system helps in the 4th situation.
Re:btrfs needed the work (Score:5, Insightful)
"Journaling makes sense for servers; not so much for personal boxes."
I'm sorry my friend but you must be insane. I don't go uncleanly powering off my boxes intentionally but it still happens a couple times over the course of a month for various reasons (power flickers and the like). In my experience ext2 will fsck its way back to functionality 4 or 5 times tops before it won't fix or the data lost in the fixing is something critical.
Linux was a fun toy and nothing more before ext3 because ext2 is the most destructible filesystem on earth. Don't get me wrong, I played with that toy but that is all it was.
Re:btrfs needed the work (Score:5, Insightful)
Wow. Am I out of the loop, or what? We're up to ext*4* now? I'm still using (happily) ext2. Yeah, I've heard of btrfs, but why change if what you're using works? Journaling makes sense for servers; not so much for personal boxes.
Yes, you are way behind. Ext3 became part of Linux eleven years ago and added journaling to ext2. Some of us have been using superior journaling file systems like Reiserfs3, XFS, JFS and Reiserfs4 for many years. Journaling is a good idea for all file systems because it allows much stronger metadata and sometimes data consistency guarantees. In other words, though hardware failures and unexpected shutdowns can cause data loss on any file system, journaled ones are more likely to know which data are corrupt and which aren't. Btrfs improves on that by also checksumming everything so no corruption can ever go unnoticed. This is increasingly important as disks get bigger and errors become more likely. Another thing that's perhaps especially nice for desktop and laptop systems is that journeled filesystems can generally be checked for consistency very quickly, meaning you much less oftend need to do a lengthy fsck.
Re:btrfs needed the work (Score:5, Insightful)
This is known as featuritis, and is anathema to the Unix way, where each part should do just one thing, and do it extremely well.
How do you make a file system out of parts, though? e.g. how do you tackle, say, snapshotting, or online volume resizing, efficiently onto an existing FS that was not designed with those features in mind?
Re:Who cares why it needs it? (Score:4, Insightful)
Re:yes but... (Score:4, Insightful)
Right, Linux audio works nowadays. Almost. Except when PulseAudio starts corrupting audio. Or stops outputting audio. Or hangs. Or forcibly mutes my headphones, requiring me to call amixer after PulseAudio has started. Or requires me to re-learn something that I learnt to do with ALSA, and now I need to start over. And except when GUI tools decide to hide ALSA devices when PulseAudio is running, ruining my ability to unmute my inputs or fine tune my volume control in many other ways.
And I can't "stop using PulseAudio", because: /etc/apt/preferences.d. I learnt how to use APT pinning solely for getting rid of PulseAudio. That should speak volumes for how broken it is.
1. When somebody asks me for help with their audio, I can't simply go and uninstall it every time.
2. Certain distributions, such as Ubuntu, make it extremely difficult to remove PulseAudio.
3. Even distributions like Debian do install it automatically, so you need to ban it in
Funny enough, I was using PulseAudio long before it became popular, because it was arguably the best network audio server for casual use. I had to stop doing that because it started breaking the sound in many applications, playing with my volume, etc. It was also funny when the authors decided that the mode in which I was using PulseAudio (as a system-wide daemon) was "unsupported", and asked distros to get rid of their init scripts, thereby breaking my dedicated sound server. Not that it isn't trivial to fix, but why would anyone remove a feature in that manner? It was probably the distros fault, since Debian are still keeping the init script, but I wasn't using Debian at the time. One day I had my sound server working, and the other day I was greeted with a message telling me what I was doing is a bad idea and I should stop doing it ASAP.
Re:Most programs don't need a 64-bit address space (Score:5, Insightful)
The problem is not the memory but the CPU cache. No reason to clog it with bloated 64 bits pointers when 32 bits pointers will do.
Re:btrfs needed the work (Score:2, Insightful)
It scares me to think that someone as ignorant as yourself might write software.
Re:yes but... (Score:5, Insightful)
It's a common FUD. Nowaday Linux audio works just fine
Well, sometimes getting audio to work is beyond the control of the Linux kernel. If the system has integrated audio on the motherboard (e.g. a laptop) the ACPI DSDT (Differentiated System Description Table) supplied by the manufacturer in the ROM can instruct the hardware to behave differently under different operating systems, or provide different descriptions of the hardware (e.g. audio inputs and outputs) to different operating systems. That's why it's common to have little glitches in Linux audio, like not having the right mixer controls.
The DSDT is written in a language called ACPI Source Language (ASL). Intel and Microsoft both provide compilers for ASL, but the MS compiler accepts buggy, non-compliant DSDTs. Since for some vendors (Toshiba) the job is considered done when stuff works under the current version of windows, they ship their laptops with DSDTs that won't work under anything but Windows and might not work in future versions of Windows.
Since the kernel writers have no way of knowing what specific hardware is in your machine except what your machine tells the kernel, they can't fix this. It's entirely the manufacturer's fault, although users blame Linux because everything works in Windows. Getting stuff working isn't exactly a nightmare, but it's beyond most users' capability. You extract the DSDT from ROM, decompile it, fix the bugy ASL, compile it, then put the fixed DSDT in your initramfs (remembering to do this again every time you install a new kernel). Sometimes using a linux boot parameter to masquerade as Windows to the hardware works.
So to recap: the Linux audio system may be fine, the hardware drivers may be fine, but if the manufacturer fails to supply a correct description of what the hardware contains to the Linux kernel, audio might not work.
Disclaimer -- this information is a few years out of date, as I've stopped using Toshiba laptops and use Asus instead. However I'm fairly sure it still exists with certain manufacturer's laptops, which have worked flawlessly for me under Linux.
Re:Oct, 1991, comp.os.minix (Score:4, Insightful)
I went back to college in 2008 and casually turned to one of my peers and said "do you remember when Back To The Future came out?" and he said "no, because I was born in 1990".
I felt old.
Re:GNU? (Score:4, Insightful)
Yes, the GNU GPL licensed kernel doesn't have anything to do with GNU.