Linux 3.4 Released

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

Comments

Wow.

[Anonymous Coward]

I must be getting old.

Re:Wow.

[tqk]

I must be getting old.

You and me, both. I remember 0.96, or sumfin.

Re:Wow.

[Anonymous Coward]

I must be getting old.

We all are.

How RedHat's Linux Can Defeat Micr$oft's Windoze

[Anonymous Coward]

Hi,

I've always used Windowz and I consider myself an exceptional Visual Basic programmer, so I know computers pretty good. In fact I got an A- in my programming class last term. But I'm a little wary of how much power Microsoft has in the computer field. Many of my friends use RedHat and I've recently installed it on my machine at home. Although I haven't had as much chance to play with it as I'd like, I've been greatly impressed.

This weekend I gave some thoughts to the things that are wrong with Linux. I hope no one minds having some flaws pointed out. I'd like to help make RedHat stronger so it can conquer MS. Hopefully RedHat will hear this (crossing fingers) and address these. I think with a little effort, RedHat's Linux can defeat Microsoft's Windows! :)

To begin with, there are too many different flavors of RedHat. Browsing a list on Amazon, I saw they made varients under the codenames of Mandrake, Debian and Slackware, just to name a few. I know that I'm very new to RedHat so maybe this is obvious but it seems like RedHat should just sell a few different flavors of its operating system. Perhaps one for the desktop and one for a server? Could someone explain why RedHat produces dozens of different versions of Linux?

Secondly did you know that anyone can view the source code to Linux! I think that RedHat shouldn't make its code available. After all, what keeps Microsoft from stealing RedHat's ideas and putting it into Windows? My friend says that FreeBSD stole the TCP/IP stack from DOS a long time ago and Microsoft is always looking for revenge for that. Plus it seems to me like RedHat is just giving away its ideas for free. And what keeps hackers or terrorists from tampering with the code and putting a virus in every computer?

On a related note, why doesn't RedHat write Linux in assembly? My friend says that's what Microsoft does for Windows, and that's why Windows is faster and more stable than Linux.

Next RedHat definitely should kill -9 (ha, ha!) the command line. Microsoft finally gave up DOS when Windows 2000 came out. I'm suprised that RedHat hasn't migrated away from...whatever its version of DOS is called (Bash, I think?) But maybe this is planned for a future release?

Finally Linux needs games! RedHat will never be successful in the home without games. They should also tell M$ to release a version of Office for Linux too. And Internet Explorer!

Have a nice day! Go Linux!!

btrfs needed the work

[bzipitidoo]

I tried btrfs, and ended up going back to ext4. Hoped btrfs might be a good choice for a small hard drive, and it is-- it uses space more efficiently. But it's not a good choice for a slow hard drive or the obsolete computer that the small size goes with.

Firefox ran especially poorly on btrfs. I was told this is because Firefox does lots of syncs, and btrfs had very poor performance on syncs. Maybe this improvement in performance on metadata is just the thing to fix that?

Re:btrfs needed the work

[Anonymous Coward]

Forgive me for asking but what is the advantage of using btrfs over something simple like lvm?

Re:btrfs needed the work

[TheGoodNamesWereGone]

I'm not as up to speed on filesystems as I probably should be, but I agree. I tried it and the speed difference is noticeable. Like, you, I went back to ext4.

Re:btrfs needed the work

[Baloroth]

Checksumming, built-in RAID support, snapshotting, transparent compression, online volume resizing, et alia. Basically, a lot of stuff that is very interesting at the enterprise level and to serious nerds who like to do strange things with their volume management, but nothing particularly important to the average user. It's basically a non-Oracle-owned version of ZFS, if you know what that is.

Re:btrfs needed the work

[Tacticus.v1]

well comparing it to lvm ignores a significant amount of what btrfs is
you would compare it with the entire stack
mdadm + lvm +ext 3/4

btrfs gets you:
Checksums on data
mirrored metadata on a single disk
lots of flexibility (online resizing and reshaping(single disk to raid 1 to 0 to single disk (or some variant of it) ( additionally raid5/6 like systems are coming)
easy striping and mirroring across different sized disks
snapshots
and probably more go check https://btrfs.wiki.kernel.org/

Re:btrfs needed the work

[Gothmolly]

Fix Firefox? Why does it "need" to do a lot of syncs?

Re:btrfs needed the work

[isopropanol]

Also, put your firefox browser.cache.disk.parent_directory on tmpfs on single user systems.

Re:btrfs needed the work

[Anonymous Coward]

Actually, ironically Oracle "owns" btrfs! But it is Open Source.

Re:btrfs needed the work

[tqk]

I tried btrfs, and ended up going back to ext4.

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.

Firefox ran especially poorly on btrfs. I was told this is because Firefox does lots of syncs, and btrfs had very poor performance on syncs.

Firefox runs poorly because the web's driven by Flash and essentially unusable without Ad Block Plus. Or, maybe you ought to try going back to ext2. Newer's not always better, or maybe newer's for hardware that you don't own.

I am such a dinosaur.

Re:btrfs needed the work

[Anonymous Coward]

Mod parent up

Re:btrfs needed the work

[oakgrove]

One really nice thing about ext4 vs. previous versions is the dreaded 20 minute fsck every 40th or so boot only takes about 10-20 seconds now.

Re:btrfs needed the work

[ArchieBunker]

Let me know when its out of beta status ok? Nothing like trusting data to beta linux fundie code.

Re:btrfs needed the work

[Anonymous Coward]

There is always going to be a trade-off no matter what software you use. I've lost data on practically every file system I've ever used including ext, hfs, ntfs, fat32, xfs and so on. If you need the features btrfs offers then use it and make sure you keep backups (you're doing that anyway, right?). Otherwise, use something else. For me, btrfs is pretty compelling and it is actually one file system I have never lost one byte using.

Re:btrfs needed the work

[smellotron]

Fix Firefox? Why does it "need" to do a lot of syncs?

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

[arth1]

Checksumming, built-in RAID support, snapshotting, transparent compression, online volume resizing, et alia. Basically, a lot of stuff that is very interesting at the enterprise level and to serious nerds who like to do strange things with their volume management, but nothing particularly important to the average user.

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.
In my opinion, it's not interesting for enterprise because you get mediocre features, like RAID support that doesn't cover RAID5, no online file system check, not all operations being atomic, and xattrs stored separate from the inode, making it sloooow with SELinux (and presumably Samba with windows per-file security support).

It's basically a non-Oracle-owned version of ZFS, if you know what that is.

Er. While some might consider Btrfs a poor man's version of ZFS, both are Oracle owned.
The main difference is that ZFS was designed from the ground up, while Btrfs builds largely on ext2, with a few reiserfs ideas and the kitchen sink thrown in.

But it will be interesting to see which COW file system will become most popular. My money is on NILFS, if nothing else because Oracle gives people a bad taste in their mouths, but ICBW.

For non-COW enterprise, I'll stick with XFS and JFS for now.

Re:btrfs needed the work

[timeOday]

Are snapshots on a raid 0 volume (across two disks) a workable backup strategy?

Re:btrfs needed the work

[smash]

This sort of application thinking is retarded. If the OS crashes, it is an OS problem. Firefox (which being a browser stores SFA that needs to be permanent) should not be forcing sync in the fear that the OS crashes. Let the cache work as intended, don't cripple it because the user is retarded or the underlying OS is crap.

If the underlying OS is crap and causing data corruption due to crashing with outstanding cached writes, then the OS is broken and needs to be fixed. NOT the browser.

Re:btrfs needed the work

[unixisc]

What license will it be under?

Re:btrfs needed the work

[Tacticus.v1]

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

[Tacticus.v1]

GPL for ever.

early in the development of BTRFS commits were sourced from vocal and stubborn devs that would protect it from being re-licensed source: http://www.youtube.com/watch?v=hxWuaozpe2I

Re:btrfs needed the work

[tqk]

One really nice thing about ext4 vs. previous versions is the dreaded 20 minute fsck every 40th or so boot only takes about 10-20 seconds now.

I composed a *brilliant* reply to your post, including fdisk -l output and lots of other thoughtful commentary, then /.'s lameness filter kicked in.

Sorry. Complain to the management.

Censorship? "We are helping!" # a la "Reboot"

tl;dr: My boxes boot in less than a minute, but they don't contain TB size drives.

Re:btrfs needed the work

[Jonner]

Checksumming, built-in RAID support, snapshotting, transparent compression, online volume resizing, et alia. Basically, a lot of stuff that is very interesting at the enterprise level and to serious nerds who like to do strange things with their volume management, but nothing particularly important to the average user. It's basically a non-Oracle-owned version of ZFS, if you know what that is.

Checksumming is useful to anyone who doesn't like corrupt data. Transparent compression is useful to anyone who likes to fit more stuff on their drives and access it faster. Btrfs is technically superior to ZFS though currently less mature. For better or worse, Btrfs is largely developed by Oracle employees so they do own part of it. Oracle could simply stop paying people to develop it but they can't take it away from Linux. Both ZFS and and Btrfs are available under Free and Open Source licenses though the licenses are are not compatible which is the primary reason ZFS cannot be included as part of Linux.

Re:btrfs needed the work

[Anonymous Coward]

Btrfs builds largely on ext2

[citation needed]

Re:btrfs needed the work

[Tacticus.v1]

>like RAID support that doesn't cover RAID5
Is on the way targeted for 3.5 (was held for the fast offline check code)
>no online file system check
btrfs scrub start /blah

Re:btrfs needed the work

[shaitand]

"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

[Anonymous Coward]

Plus, btrfs sounds like it could be short for 'bitrot filesystem'.

Re:btrfs needed the work

[Jonner]

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

[shutdown -p now]

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:btrfs needed the work

[unixisc]

2 or 3?

Re:btrfs needed the work

[Anonymous Coward]

You can't. He doesn't know what he's talking about.

Re:btrfs needed the work

[Tacticus.v1]

2 i would think as it's going into the kernel but you should probably check that

Re:btrfs needed the work

[linhux]

This doesn't sound right. OS crashes should be very uncommon and thus you shouldn't design your software around them. Much more common is that Firefox itself crashes, or X11, in which case the data will be there even if the process didn't sync. If your computer crashes, you usually have bigger problems than a bit of lost browser history (not that I've ever seen *hours* of uncommitted data being lost due to a computer crash).

Re:btrfs needed the work

[waveclaw]

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.

All btrfs does is manage a B-tree filesystem. All grep does is apply a regular expression to a string.

However, the UNIX way is not always even a good thing.

It is also the UNIX way to duplicate a single thing a hundred times for each little feature variation (grep, egrep, fgrep, most of Perl.) That can also be unpleasant for the end user (xterm, gnome-terminal, kterm, gterm, LXterm, terminator, editing Perl.) Great for a system administrator who is expert at their particular tool and only that tool but horrible for everyone else.

That's without getting into the UNIX Way for (lack of) documentation. Or how that one thing is so often the wrong thing so it doesn't matter how well that one tool does it.

btrfs is famously called a rampant layering violation. The roll-up of filesystem-management features in one place actually lets the developers avoid duplicating code (which may actually be about as non-UNIXy as you can get in some ways.) Code that now knows about certain information normally hidden from it can do things differently. This is sometimes better (rapid mkfs) or worse (fsck tool was apparently hard to write.)

In my opinion, it's not interesting for enterprise because you get mediocre features, like RAID support that doesn't cover RAID5, no online file system check

In my opinion, if your enterprise system depends on fsck and not good backups then you don't have an enterprise system. Yes, xfs_repair can do amazing things to mostly trashed disks. But one day your data will take a good fscking where only surviving copy will be the backup copy.

RAID5 implementation from Intel is in the tree, but waiting until after the fsck is done. And btrfsck has been around since, oh, February? And the btrfs-progs you should be using with the 3.4 kernel have btrfsctl included?

I was hoping the RAID5 code was going to land in 3.4, actually. Reading the pull request says that RAID5/6 should be in 3.5. Oh, well.

Of course, if you have enough money to buy an "enterprise" solution, your SAN/NAS should do the thing doing RAID for you anyway.

My major criticism of btrfs is the horrid sync performance. Hosting virtual machines tends to require lots of small writes to disk that make btrfs incredibly non-performant.

btrfs has many sexy, sexy features for a world of enterprise SAN storage and virtual machine hosting. It has thin disks, balanced meta-data, flexible storage, SSD optimized modes, multiple snapshot layers, checksummed data on disk. All of this just because it does one thing and does it well: manage a B-Tree database.

Today it's is just not there in the I/O department, sadly. Probably good for inside the virtual machine guests, though. Only testing will tell.

My money is on NILFS, if nothing else because Oracle gives people a bad taste in their mouths, but ICBW.

Wow, speaking of niche file systems. Log file systems have quite a long history. Of horrible performance and fragmentation. But if we all end up on SSDs, that won't matter. Underlying any file system you put on it, an SSD implements storage as a circular log and performance is fast enough to not depend on huge uncommitted disk caches.

Re:btrfs needed the work

[TheGoodNamesWereGone]

I have an old (2004-era) laptop that I still use for a testbed. It's a 1GHz Athlon-M with 1GB of RAM. I formatted it asext2 to save some CPU cycles, so yes, the old ways can come in handy.

Re:btrfs needed the work

[Nutria]

OS crashes should be very uncommon and thus you shouldn't design your software around them.

By far, the predominate OS that FF runs on is Windows. Thus, the developers are concerned about frequent OS crashes.

Re:btrfs needed the work

[Anonymous Coward]

It scares me to think that someone as ignorant as yourself might write software.

Re:btrfs needed the work

[mrmeval]

Online volume resizing rocks!. For some reason Fedora had sized my root partition too small. After adding a physical volume and resizing the volume group I easily resized the ext4 root partition without rebooting. This was for my desktop.

Re:btrfs needed the work

[MrHanky]

Right. Since Mozilla design their browser with Windows 98 and ME in mind, and then drops support for them only at compile time. Windows hasn't been crash prone for more than 10 years.

Re:btrfs needed the work

[nadaou]

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.

For kernels tweaked into "laptop mode" this may be different, but for stock modern Linux the maximum time delay for disk cache writes is 30+5=35 seconds, not hours.

$ cat /proc/sys/vm/dirty_expire_centisecs
$ cat /proc/sys/vm/dirty_writeback_centisecs
$ cat /proc/sys/vm/laptop_mode

Re:btrfs needed the work

[Anonymous Coward]

or "2 or later" or "3 or later"?

Re:btrfs needed the work

[Viol8]

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

Where do you live, up a mountain? Anyway , you never heard of UPS's?

"because ext2 is the most destructible filesystem on earth."

Ah rubbish. All PC OS's from the 90s when linux started had filesystems you wouldn't trust a business with - thats why serious businesses used serious operating systems such as Solaris or HP-UX or AS/400. Try killing a Windows NT box using early NTFS or a Mac using HFS while its writing data and see how much of it is recovered on reboot.

Re:btrfs needed the work

[Anonymous Coward]

Yeah, there is a way - firstly, accept a loss of (say) five seconds against the rare chance of a castatrophic system failure. (loss of power, kernel panic.) Then you can just do the syncs in the background; ideally with some kind of kernel call that 'flushes everything written before this call out' - but do it in the background.

And you're forgetting one key thing: If the process dies, writes to a file need only be in a buffer cache. They don't have to be on disc - because any other process or newly launched firefox will see these modifications even if they're only in buffer cache. Sync(..) is all the way out to disc - which is not necessary to defend against process crashes.

Re:btrfs needed the work

[Anonymous Coward]

From the little you have posted, I doubt it would have been brilliant. Your boxes boot in less than a minute, but do they do so when it's time for an fsck?

Re:btrfs needed the work

[paulatz]

Windows hasn't been crash prone for more than 10 years.

This is especially true as long as you do not install any third party driver or software on it

Re:btrfs needed the work

[AaronW]

I too will wait for BTRFS to mature. I tried BTRFS on a decent SSD and found the performance to be terrible compared to XFS, which is my current filesystem of choice. I found that the performance was especially bad when I tried to move my Cyrus IMAP server over to it. The other thing that bothered me is that I could find little information on what happens when space runs low. While writes are supposed to be extremely fast, I found that not to be the case when restoring the 100K plus email files onto the partition. This was with a fairly decent Intel SSD. Granted, this was with the OpenSUSE 3.1.10 kernel but I think I'll wait a while longer before trying it again.

The tools for BTRFS look interesting, but then again I think I'll wait until they mature some more. At this point the best filesystem tools I have found are the ones for XFS, especially tools like xfs_dump, xfs_restore, xfs_fsr and xfs_db. Also, out of all of the filesysems I have tried, XFS seems to be the fastest in most cases, especially with the recent changes to reduce meta-data writes. I have also found it to be quite fault tolerant with fast recovery.

Re:btrfs needed the work

[Anonymous Coward]

Depends - A few years ago I tested the available Linux filesystems.

And (On lvm) ext2 even with the longer fsck's was far less likely to trash itself than xfs (Could have been due to lack of support for barriers) or ricerfs.

It was a fair while ago but significantly more recently than 11 years ago.

If you are using something like slackware where you are doing most of your work in ./usr/local (That is on a seperate partition) ext2 for / is just fine. (Softupdates in BSD is not used by default for / because it is unnecessary).

(Testing by deliberately pulling the power amongst other things.

ext2 + softupdates should be able to work at least as well as ext3

(ext4 has the featurers of a modern FS such as extents that are definately worth having however.)

Re:btrfs needed the work

[ArsenneLupin]

By far, the predominate OS that FF runs on is Windows. Thus, the developers are concerned about frequent OS crashes.

Then, the sync should be conditional on the OS it is running on, and disabled on Linux.

And even on Windows, it should be configurable. Some users might care more about appropriate battery life than about their browser history in the rare event of a crash. Even Windows crashes much less nowadays than it used to...

Re:btrfs needed the work

[swilver]

Checksumming... will happily checksum that bit-error in cache if you donot have ECC memory -- fact is, data on disk is already heavily checksummed by the drive itself and on the busses its transmitted (otherwise we wouldn't have modern computers). Data going corrupt (unnoticed) happens mostly in main memory these days.

Transparent compression... magically makes your drive bigger so you can fit more text files on it! It won't do you any good for any of the REAL storage consumers though: music, video, games, pictures... as ALL of those are in compressed formats already.

Re:btrfs needed the work

[ArsenneLupin]

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.

Good point. And as a user, I don't want firefox to waste battery power and to expose my harddisk to unneeded risk due to access during physical motion. So how can I, as a user, disable these excessive sync()s in firefox?

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

It's more infuriating to lose all the data on my hard disk because the car I'm riding in shook a little during one of those many unneeded syncs.

Why o why do firefox developers think that they have to second-guess both the users and the OS developers? Guys, if you're that concerned about preserving the precious browsing history, start by not tossing it away deliberately just because the site happened to use SSL.

Re:btrfs needed the work

[ArsenneLupin]

but it still happens a couple times over the course of a month for various reasons (power flickers and the like)

If "power flickers" happen that often to you, maybe you should have the electrical wiring in you home examined. Or maybe, with your grid, you need an UPS?

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.

What a load of rubbish! Linux was perfectly usable and stable even before ext3 came around, and perfectly fit to be used as a mission critical server! (which many companies actually did!)

The reason why ext3 was eventually needed is because disks became big enough that fsck was starting to take unreasonably long times (in the rare event of a crash), and so something more efficient was needed.

Re:btrfs needed the work

[petermgreen]

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.

The problem with conventional raid is it has no way of knowing which redundant copy of the information is correct and indeed it may well end up overwriting the correct copy with the bad copy during a resync. So it protects against drives that fail but it doesn't protect against drives that quietly return bad data.

In theory you could implement a raid layer with strong checksums so it knew which copy was bad, but the problem then becomes where to put those checksums (without creating a load of extra seeks).

By implementing raid techniques as part of the filesystem the checksums can be stored with the existing metadata. Implementing raid as part of the filesystem also allows different redundancy policies to be applied to different data.

Re:btrfs needed the work

[del_diablo]

What scares me is that we need more people who do not accept bug workaorunds as a natural solution. Pentium has bugs with math,? Workaround! Entire OS API is undocumented? Use it anyway! Etc.
Somebody robbing me? The police won't help me! While its a problem, for something like GNU/Linux and Windows, they are proper OSes, stop assuming they are running on "OS Alpha, the unstable".

Re:btrfs needed the work

[Anonymous Coward]

It would have to be 2. Significant parts of the kernel are GPL2 only which is incompatible with 3, which was the problem with ZFS which is GPL3 only, though it could be under a dual license which includes GPL2.

Re:btrfs needed the work

[Anonymous Coward]

Well, I haven't had a power outage long enough to reset any dumb clocks in about 8 years (in Germany).
Before they were more frequent (when the wires were not in the ground), but only during heavy thinderstorms where switch off the computer isn't a bad idea anyway.
Of course there's (parts of) southern France where you have one about daily, but I can't see how one can operate a computer there without a battery at all.

Re:btrfs needed the work

[Anonymous Coward]

All of you guys are far too stupid to be running linux desktops

Re:btrfs needed the work

[arth1]

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?

You provide a low-level API and hooks.
In the case of XFS, for example, you do snapshots by quickly freezing the volume while a volume manager or other software makes a shadow copy.

Re:btrfs needed the work

[VortexCortex]

For better or worse, Btrfs is largely developed by Oracle employees so they do own part of it. Oracle could simply stop paying people to develop it but they can't take it away from Linux. Both ZFS and and Btrfs are available under Free and Open Source licenses...

You fail to realise, FOSS licensing means nothing to Oracle and lawsuits are expensive. Let's test your logic with this real world example:
For better or worse, Java was largely developed by Sun (now owned by Oracle), so they do own part of it. Oracle could simply stop paying people to develop Java but they can't take it away from Anyone. Java is available under Free and Open Source licenses.

Oracle is suing Google over the Java APIs they're using in Android, as well as a few bogus patents (that never should have been granted) on compile and linking optimisations -- Not the implementation. Despite the previous promises that Java would always be free and competing implementations were welcomed (Only stipulation: To call it "Java" you have to pay for a license and pass their test suit).

Harmony, Bouncy Castle, GNU classpath, my own experimental VM w/ optional Java Compiler -- All of those could face the same exact situation that Google is in over Android with Oracle. Many people, myself included, would have NEVER learned and contributed to the Java language if we thought Java's owners would act in such ways. I'll die in a fire before I use Java, BTRFS, or anything Oracle makes for anything mission critical.

Now, if your viewpoint is to remain valid, then burden is on you to prove that Oracle won't do the same crap over any of the other FOSS projects that it owns, like BTRFS.

Re:btrfs needed the work

[unixisc]

ZFS was licensed under Sun's CDDL, and BSD had no problems accepting that. Since the GPL is incompatible w/ CDDL, Linux can't include ZFS. Although there is a port of native ZFS to Linux by LLNL for the DoE. Wonder why the latter can't just use FreeBSD?

Re:btrfs needed the work

[KiloByte]

Yes, there is a massive speed difference. Unpacking a particular tarball takes 10 seconds on btrfs, 124 seconds on ext4.

The problem is with certain broken programs that fsync after every single write. But that's a problem with those programs, not btrfs. The words "fsync" and "performance" don't belong in the same sentence. fsync may be legitimately uses when durability is actually needed, but in almost all use cases the programs want only consistency.

An example: there's a file where a transaction consists of appending a few bytes to the file then updating something in the header. Let's say it's four bytes in both writes. The program can handle power loss between transactions or if it happens between the first write and a header update, but not any other reordering. The disk in question has 100MB linear speed and 10ms seek time. Even with some kind of a barrier syscall, ext4 would need to alternate writes anyway, plus it needs to write to the journal and inode. This gives you a whooping 25 transaction per second. btrfs and log-structured filesystems with atomic flushes get 25M instead (assuming infinitely fast CPU).

The primary offender here is Firefox which fsyncs all the time. This not only slows down writes but also causes insane fragmentation. The data it protects is not vital in the first place (mostly browsing history), and if it used sqlite in WAL mode on relevant platforms instead it wouldn't have to fsync for consistency almost at all.

Re:btrfs needed the work

[Anonymous Coward]

Awesome, great to know what's required to use a web browser on Linux

Re:btrfs needed the work

[silentcoder]

>This is especially true as long as you do not install any third party driver or software on it

And considering almost every network card in the known universe is unsupported under Windows XP without third-party drivers (dunno if this got better with newer versions, never used them) - it's probably a very good way to avoid viruses as well.

Re:btrfs needed the work

[RulerOf]

Btrfs builds largely on ext2

[citation needed]

Nope, he's quite right. I built btrfs just fine previously, but now after I upgraded to ext4, look what happens:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
$ cd btrfs-progs
$ make
System going down for HALT now!

Re:btrfs needed the work

[Anonymous Coward]

40 boots...so whats that, about 20min every 120yr or so? :ducks:

Re:btrfs needed the work

[smellotron]

Then, the sync should be conditional on the OS it is running on, and disabled on Linux.

I'm not sure if this is still relevant, but at one point it was the major culprit for excess syncs and it is indeed configurable. It's probably more informative to read the bug comments and see the diff than for me to paraphrase.

Re:btrfs needed the work

[jbolden]

and competing implementations were welcomed

If Google can prove such promises were made publicly they win both parts. You can't waive you rights publicly and then enforce them.

Re:btrfs needed the work

[Anonymous Coward]

ext4 gets the data to disk safely and with reasonable performance. Perhaps btrfs needs a two-phase write mode to handle this common performance case. Even ZFS does much better.

Re:btrfs needed the work

[smellotron]

For kernels tweaked into "laptop mode" this may be different, but for stock modern Linux the maximum time delay for disk cache writes is 30+5=35 seconds, not hours.

Yes, laptop_mode is exactly the scenario to which I refer when I say "hours". That's of course where the syncs are the most expensive, as well. I ran into this don't fear the fsync discussion on the topic years ago, but it seems that the original site is dead.

Re:btrfs needed the work

[jbolden]

Databases handle this problem all the time by using log files which keep a mini version of the call. Then on crash the engine just reruns the logfiles. You don't need to sync everything to maintain a reliable recovery.

Re:btrfs needed the work

[Hatta]

The solution to this is the same as it's been in every app. If you're doing something important, save your work frequently. I have never(literally, not once) used Firefox's restore feature. If I find something I want to keep, I save it or bookmark it. Session restore is a resource wasting nuisance.

Re:btrfs needed the work

[Anonymous Coward]

Yes, the moderators are. Your post is interesting that that almost nothing you said is accurate and interestlying enough, they still moderated it up.

Re:btrfs needed the work

[ArsenneLupin]

I'm not sure if this is still relevant, but at one point it was the major culprit for excess syncs [mozilla.org] and it is indeed configurable. It's probably more informative to read the bug comments and see the diff than for me to paraphrase.

According to some of the comments on this bug, the relevant setting is toolkit.storage.synchronous
On recent firefoxen (tested on 12.0), this is 0 by default, however firefox still performs the occasional fsync, especially when opening or closing a new tab, and when following links.

Re:btrfs needed the work

[jez9999]

Btrfs also doesn't support ext4's new file creation time tag 'crtime' which is a big turnoff for me. It's about time Unix filesystems started doing something Microsoft was doing years ago.

Re:btrfs needed the work

[Anonymous Coward]

^^^Get a load of this douche.

Re:btrfs needed the work

[KlomDark]

Dude, they call it btrfs because it's the BitTorrent File System. How can you not see that is the perfect answer?

Now you don't have to download all those pesky torrent files, they are just part of your file system.

And you can auto-store your confidential files in THE CLOUD!!!!!!!!!

Re:btrfs needed the work

[Courageous]

My major criticism of btrfs is the horrid sync performance. Hosting virtual machines tends to require lots of small writes to disk that make btrfs incredibly non-performant.

ZFS has similar problems, FYI. If you run VM's on it, you have two choices. Buy SSD's for the ZIL, or disable the ZIL.

C//

Re:btrfs needed the work

[Simon Brooke]

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

When you really don't know what you're talking about it's best to shut up. I've been running (many) production servers on Linux since 1995; I recall only one instance of a failed fsck. I do remember a number of occasions when a little bit of manual intervention was needed to help fsck along, but if you're competent that intervention was pretty easy. Actually, with e2fsck the intervention was always pretty easy because the defaults rarely failed..

And if you think Linux was a toy, what the hell operating system did you think most of the Internet was running on in those days? It certainly wasn't anything out of Microsoft!

Re:btrfs needed the work

[Anonymous Coward]

Checksumming... will happily checksum that bit-error in cache if you donot have ECC memory --

Uh, no. That's kind of the point of an end-to-end checksum.

fact is, data on disk is already heavily checksummed by the drive itself and on the busses its transmitted (otherwise we wouldn't have modern computers). Data going corrupt (unnoticed) happens mostly in main memory these days.

These checksums aren't end-to-end and corruption easily set in in each layer. There's also other forms of corruption, for example disk blocks not being written to the correct location -- block checksumming isn't going to detect that, but a scrub will.

That's what's different about the ZFS/Btrfs checksumming.

Re:btrfs needed the work

[Anonymous Coward]

Are you suggesting putting a disk cache in RAM? Doesn't that defeat the point of it?

Re:btrfs needed the work

[Anonymous Coward]

The point is that a lot of these features were done in layers that aren't the FS. Snapshotting was traditionally done at the LVM layer (on Linux, or the volume management level in other Unix operating systems). Volume resizing was similarly done at the LVM layer, traditionally. RAID was done at a different layer.

As someone who's used ZFS for the past couple of years, I have to say ZFS does this things way nicer than FS+LVM+RAID as separate layers does. That doesn't mean I'm not sympathetic to the ideology that they should be in separate layers :P

Re:btrfs needed the work

[TheDarkMaster]

I also noticed this terrible behavior of Firefox when using the disc... He causes a LOT of fragmentation on Windows too.

Re:btrfs needed the work

[jones_supa]

I have an old (2004-era) laptop that I still use for a testbed. It's a 1GHz Athlon-M with 1GB of RAM. I formatted it asext2 to save some CPU cycles, so yes, the old ways can come in handy.

I suspect you are not getting any meaningful savings. A FS driver is mostly just copying some buffers around, not much CPU needed.

Re:btrfs needed the work

[Anonymous Coward]

Yes, it rocks! Windows Vista had it in 2007.

Re:btrfs needed the work

[Anonymous Coward]

Transparent compression is useful to anyone who likes to fit more stuff on their drives and access it faster.

Having the computer have to compress or uncompress a file every time it's accessed makes the access time faster?

Re:btrfs needed the work

[Anonymous Coward]

In which case they were years late to the table. That's about when linux distros started including LVM as a default install option. Troll harder.

Re:btrfs needed the work

[shutdown -p now]

Sure. So, at the minimum, the FS still needs to know how to freeze itself (while still allowing writes etc, if you want live snapshots).

Re:btrfs needed the work

[tqk]

Journaling makes sense for servers; not so much for personal boxes.

I'm sorry my friend but you must be insane.

Possibly. The jury's still out on that.

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

Yeah, and it boots into "fix me!" state, and you fsck the ptns. And it works. Every time. Every friggin time! :-) I've never had it fail to fix a confused ptn. I'm reminded of a job/contract I did with City of Calgary, where the first thing I was asked to do was to sort out a confused AIX box. Same thing. It worked. ext2 works just as well.

It may be that ext2 doesn't *spin* as fast as new tech (Android, iBaubles, ...) needs it to, but for me, on my hardware, for what I do with them, it spins way fast enough.

Then again, I may be insane. :-) No apologies. Linus, may you live forever, and may your grandchildren have many grandchildren! :-) I'll kiss your feet if you ever show up in my neighbourhood (fair warning).

Re:btrfs needed the work

[shaitand]

Sure I've got UPS's. They aren't for my desktops and old laptops though.

"Ah rubbish. All PC OS's from the 90s when linux started had filesystems you wouldn't trust a business with"

Nonsense the only other PC OS worth mentioning was Windows and it had FAT32. Granted FAT didn't have any fancy features and you'd have to wait for a scandisk but you could power the system off unsafely every day for a year without doing any significant damage.

EXT2 was faster than FAT32 but forget my business. I couldn't trust my disposable personal system to it. Even I can't afford to waste time reloading an OS every few days. Especially one that required as much tinkering as 90's desktop linux.

Re:btrfs needed the work

[icebraining]

It's not only about OS crashes. How do you expect the OS to prevent a power outage or the Off button being hold by mistake?

Sure, people should have UPSs, not touch the button, etc, but that stuff will happen and accounting for it is part of "being liberal in what you accept".

Re:btrfs needed the work

[Anonymous Coward]

It is an experimental filesystem at this point, nothing else.

We tried it up through 3.4rc7 with the latest user-land tools as a potential high capacity backup system due to its inclusion of transparent compression.

The idea being we offload any compression from the database boxes dumping data (they wouldn't need to compress) and push that work to the boxes receiving the backup.

We tried this over nfs and using Gluster w/ BTRFS (yes unsupported, but 'works' with distributed non-replicated bricks.)

We found this:

- Writes start fast on a new filesystem, IO drops through the floor quickly over time (these were 20TB volumes)
- Once it hits the floor it stays there, scrub it, balance it, space_cache/no spache_cache nothing made a difference.
- Bottleneck appeared to be delayed allocation, eventually one proc will deadlock and be a bottleneck for everything else.

We would effectively need to mkfs.btrfs the filesystem after every run to make it workable... Which obviously isn't practical.

Should be interesting to see what it looks like in a couple years, right now I see no good case for deploying it.

Re:btrfs needed the work

[shaitand]

"If "power flickers" happen that often to you, maybe you should have the electrical wiring in you home examined. Or maybe, with your grid, you need an UPS?"

You genuinely don't have personal systems get improper shutdowns a couple times a month? It really isn't that often. And I definitely don't need to buy a UPS to make up for an unstable fs. FAT was hardly indestructable and it wasn't as fast as ext2 imho but it could still handle a few improper shutdowns a week for a year or two without issue. Longer than windows could go before bitrotting in any case.

"What a load of rubbish! Linux was perfectly usable and stable even before ext3 came around, and perfectly fit to be used as a mission critical server! (which many companies actually did!)"

A mission critical server is a completely different scenerio and I deployed no shortage of them during the ext2 period. A mission critical server has redundant power supplies, each plugged to a different circuit and UPS buffered and backed with at least one of those circuits backed by a diesel generator. If you had four or five improper shutdowns during the life of a server something was wrong.

"The reason why ext3 was eventually needed is because disks became big enough that fsck was starting to take unreasonably long times (in the rare event of a crash), and so something more efficient was needed."

And because fsck failed to recover the ext2 filesystem about 20% of the time.

Re:btrfs needed the work

[Emacs.Cmode]

It's not only about OS crashes. How do you expect the OS to prevent a power outage or the Off button being hold by mistake?

Sure, people should have UPSs, not touch the button, etc, but that stuff will happen and accounting for it is part of "being liberal in what you accept".

Making firefox session recovery reliable even in the face of power outage or Off button is noble if it can be done without crippling the performance in normal operation. Once both cannot be achieved, one has to weigh the acceptable performance against making it rock-solid but unpleasant to use. The question is, what is the purpose of the system we are building? What is the general expectation of users?

In this case treating the power-outage as a truly exceptional condition and not crippling the performance to accommodate it might be justified.

Re:btrfs needed the work

[shaitand]

"When you really don't know what you're talking about it's best to shut up."

Agreed. Feel free at any time. Or perhaps you want to come back with some more of your anecdotal evidence.

"I've been running (many) production servers on Linux since 1995"

I can't imagine what could be a more clear indication of not knowing what you are talking about than bringing servers into a discussion of personal system usage conditions. My linux servers have 400+ day uptimes. You aren't exactly fscking them every time you turn around. Solid as a server means not going down in the first place. Solid as a personal system means recovering from the inevitable constant downs. Windows was and is a joke as a server. But the simple fat fs was more durable than ext2 hands down, it was/is slower and there is no feature comparison even with ext2 but it is definitely more stable.

"what the hell operating system did you think most of the Internet was running on in those days?"

Again. That is a discussion about servers. Off topic.

Re:btrfs needed the work

[ultranova]

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.

It is for me. The only time I want synchronization is when I add a bookmark. So, how do I stop Firefox from syncing except when I hit CTRL-D?

Re:btrfs needed the work

[tqk]

... or ricerfs.

Was that a joke? :-) I laughed.

Re:btrfs needed the work

[ultranova]

By far, the predominate OS that FF runs on is Windows. Thus, the developers are concerned about frequent OS crashes.

I dunno, Windows 7 64-bit hasn't actually crashed on me even once in 2 years, and doesn't seem to require restarts (Firefox does) or reinstalls. Sure, Linux is far better - good command line + multiple desktops + an unified software update architecture - but I have to admit, Microsoft finally got their shit together in the minimum acceptable standards department. Even if it took them a quarter of a century.

Re:btrfs needed the work

[shaitand]

Here in the US we have brown outs. They aren't from storms but from power shortages when everyone runs their climate control systems (heat and a/c) during the peak times in summer and winter. Usually the power doesn't even go completely out, it just hiccups with a visible flicker in the lights.

In any case, it isn't ALL power outages. During the course of working on a system I might power it off in a half booted state a dozen times. If I'm trying to boot a dvd and miss the window I don't wait for the OS to come all the way up and properly power down I'll just hit the switch and start over. EXT3/4 and NTFS are all pretty solid and I've never lost a system because of improper shutdown on those fs. Scratch that, I have had to chkdsk and fixboot the ntfs stuff though I haven't lost one and EXT3+ hasn't needed even that. Well okay, I did lose a system once but that was only because a laptop chose to overheat during a full disk encryption process!

"Of course there's (parts of) southern France where you have one about daily, but I can't see how one can operate a computer there without a battery at all."

I have absolute confidence you could run a personal system with ext3 in those conditions and it would be fine. You could power it off multiple times every day and have no issues.

Re:btrfs needed the work

[Anonymous Coward]

Yes, but only in a limited sense. With raid 0, if one of your drives fails you lose everything including the snapshots.

However, you can have a cronjob take a snapshot daily using the name of the weekday as the snapshot name. Then you'll have seven daily snapshots available. If you accidentally delete a file, you can mount yesteday's snapshot and retrieve it.

I use zfs-fuse on my home file server and use said cronjob. But I still run raid 5 and have offsite backups.

Re:btrfs needed the work

[Nutria]

Except that the FF source code is older than that, and had to run on W98 for quite a while, and going into source code and removing obsolete code is pretty low on most programmers' priority lists.

Re:btrfs needed the work

[Compaqt]

Does that solve the problem? I mean, what if the database writes the data to disk, but the OS doesn't because sync wasn't called.

So now, you're back to calling sync again.

Re:btrfs needed the work

[isopropanol]

No, I'm suggesting putting it in swappable memory. It will happily move back and forth between RAM and swap until the next reboot. And it will live in a filesystem that does not care about trying to survive power loss or syncing changes to disk on any particular schedule. It will be cleared out on the next reboot (but don't rely on it being unrecoverable), so it's not good if you use 3g or other small-quota or slow connection. For me it makes a significant improvement to browsing speed except on the first page load of a site after a reboot. Also a rediculous amount of web sites serve most assets without reesponding to the "if-modified-since" header properly anyways.

Re:btrfs needed the work

[isopropanol]

Not required, just a useful tweak. Like re-formatting a windows box with the MS (not OEM) windows disk as soon as you get it home to clear out all the cruft the OEM installed. You don't have to, but it'll be a noticeable improvement in most cases.

Re:btrfs needed the work

[jbolden]

Yes. The logfile is synced not the entire write. That way the database knows enough to recreate the lost data but hasn't had to call all those updates across the disk.

Re:btrfs needed the work

[Anonymous Coward]

The GPL was here way, way, way, way, WAY before the CDDL. Thus it's impossible for it to be incompatible with CDDL. The CDDL was deliberately designed to be incompatible with the GPL. Saying different is not only intellectually dishonest, but also a slight to the people who wrote the CDDL with this very aim. I guess that never crossed your mind though - along with all that other "too hard" stuff.

Re:btrfs needed the work

[Anonymous Coward]

I guess I'll have a play with the settings to see the effects, but I get the feeling you'd be better off just turning off the disk cache and increasing the RAM cache to compensate.

Re:btrfs needed the work

[Anpheus]

This is a fine idea but you end up with spaghetti code, with many layers of these hooks. To support all the various features of ZFS would require a great deal of modules all hooking the API at various levels. You have to remember, a hook is essentially an INTERCAL "COME FROM" statement. It's a goto on adderall.

Re:btrfs needed the work

[Compaqt]

Actually, the reason Oracle is suing Google is because cheated Sun out of a few million in licensing fees.

Sun's model was a highly generous 'free on the desktop, pay on mobile' model.

Google was too niggardly to pay even a few million to nice Sun. So now they're facing mean Oracle.

I'm not talking about what Google was "required" legally to do. I'm talking about "the right thing", as in you or me chipping in a few dollars to an open source project that I might have benefited from professionally. A few million was nothing for Google.

And, yeah, now Oracle's lawyers have come up with dumb arguments, but don't forget how Google's cheapness led to the demise of Sun.

Re:btrfs needed the work

[icebraining]

It only cripples performance in Btrfs, which for now almost nobody uses.

Re:btrfs needed the work

[Anonymous Coward]

That's the stupidest statement I've heard in quite a while. Since when does "incompatible" involve a direction? Very simply, the two licenses are incompatible with each other.

Re:btrfs needed the work

[batkiwi]

The number one place you get bit errors is from loose/dodgy sata cables.

There's an interesting article on ZFS finding systematic corruption on one of the developer's home computers that he didn't know was occuring. He thought he'd found a ZFS bug!

In the end he replugged sata cables and was good to go again.

Re:btrfs needed the work

[smellotron]

So, how do I stop Firefox from syncing except when I hit CTRL-D?

For starters, you should disable Session Restore and the Awesome Bar. Both of these features are 'auto-saving' and probably require I/O. I would then start experimenting with something like strace -e trace=sync,fsync,fdatasync and looking at stack traces to find further configuration options which can be disabled. Disclaimer: I have not tried this, as I don't have a Linux desktop at the moment. You may need to use ltrace for fsync/fdatasync.

Re:btrfs needed the work

[Anonymous Coward]

duplicate a single thing a hundred times for each little feature variation (grep, egrep, fgrep, most of Perl.)

They're the same program, silly. egrep is grep -E, fgrep is grep -F:

-r-xr-xr-x 9 root wheel 87304 17 Feb 2011 /usr/bin/egrep
-r-xr-xr-x 9 root wheel 87304 17 Feb 2011 /usr/bin/fgrep
-r-xr-xr-x 9 root wheel 87304 17 Feb 2011 /usr/bin/grep

And I don't know what you mean with "most of Perl" unless you're thinking that it may have originally been an improved awk or sed. It ended up being a whole programming language.

Re:btrfs needed the work

[Viol8]

"EXT2 was faster than FAT32 but forget my business. I couldn't trust my disposable personal system to it. Even I can't afford to waste time reloading an OS every few days."

You're blowing smoke out your backside. Clearly you've never even used an ext2 system so back under your bridge. I never once lost any data in the decade I used it. Not so Windows.

"Granted FAT didn't have any fancy features and you'd have to wait for a scandisk but you could power the system off unsafely every day for a year without doing any significant damage."

BS. It was/is the most unreliable PC filesystem around.

Re:btrfs needed the work

[Anonymous Coward]

Since when does "incompatible" involve a direction?

Since North fought South over the treatment of black people.

Re:btrfs needed the work

[unixisc]

Precisely - that relationship is reflective. If A is incompatible w/ B, B is incompatible w/ A.

Re:btrfs needed the work

[WuphonsReach]

The older ext3 FS with lots of files (think "millions of files") takes a long time to fsck every N days or M boot cycles. The ext4 file system is definitely a step forward in that regard. Ext4 is also a lot faster at deletion of multi-gigabyte files when compared to ext3.

Ext4 is definitely a step up for most use cases over ext3. We now only use ext3 on things like /boot and / and other small file systems. All of the bigger file systems over a few GB (such as the mail files, or file shares, etc) are now all on ext4.

Re:btrfs needed the work

[Anonymous Coward]

Very simply, the two licenses are incompatible with each other.

Yes, simply. And not quite as simply, the two licenses are incompatible with each other by design, with the culprit being CDDL.

I agree that it's stupid, but not in the way you think.

Re:btrfs needed the work

[Rich0]

The problem is with certain broken programs that fsync after every single write.

It doesn't help that some of the ext3/4 folks were claiming that this was the only proper way to write applications, because apparently filesystems are supposed to lose data if you don't do that. I think Linus basically overrode them and committed a patch against the maintainer's wishes since filesystems are apparently not supposed to lose data (go figure).

MythTV does this all the time - in fact it caused me to actually lose video since the drives were perfectly capable of sustaining the write load, except for the fact that all those fsyncs caused them to spend all their time seeking and very little time reading/writing. When you have stuff like striped RAID and plenty of cache it is best to let the OS manage the write order so that the drives can leverage their extremely high bandwidth and minimize the seek penalties. For the 95% of users who don't run databases serving networked clients it probably would be nice to have a kernel option that turns non-root sync calls into a no-op.

95% of the time, whether the data actually makes it to disk or not should be none of the application's business.

Re:btrfs needed the work

[Rich0]

If your system doesn't have a UPS and a very reliable OS, and you care about data loss more than performance, then it shouldn't be caching data for a long period of time. Complain to whoever configured the OS (whether using defaults or otherwise).

If I tell the OS I don't mind living dangerously, then I don't want some app pretending I don't know what I'm doing.

I just wish linux had the ability to ignore unprivileged fsyncs. It would save me lots of patching. I've actually had such applications CAUSE data-loss (if data is coming in at a particular rate, and you force your disks to write data at a lower rate because you insist they seek for every 10kb of data to be written, then you will have problems).

Re:btrfs needed the work

[Rich0]

Yup, and just as well because that article is as wrong today as the day it was written.

POSIX might very well be as broken as using fsync, but the solution is to fix POSIX, and not abandon write caching by having every application calling fsync.

If you start with file A, and write some data to the end of it, and power fails in the middle of this operation, then the only acceptable outcomes in my mind are:
1. After cleanup the filesystem contains an unmodified A.
2. After cleanup the filesystem contains the full A+n modified contents.
3. While not ideal, many would accept that the file system might contain A+(n-m) modified contents - that is only some of the additional data was written.

If overwriting just a part of the file then the file should be some combination of the original and some number of modified sections (ideally zero or all of them).

A situation where after cleanup you've lost the original A entirely, or any part of it is completely unacceptable. Some seem to argue otherwise, and fortunately Linus felt otherwise and committed a patch over the objections of the people who originally wrote the code (a rarity in FOSS).

And one of the big reasons I'm looking forward to btrfs is that being COW it should generally end up with either the untouched or final versions of the file.

As far as laptop mode goes - if a user doesn't mind taking on the risk, I see no reason that apps should override that preference, unless the user has explicitly set that preference. I think a big failing in modern security design is failing to distinguish between a user's preferences, and an app running under their credentials. Android is a big example of this where users can't even modify the permissions of an app - they can only accept or reject them.

Re:btrfs needed the work

[Rich0]

Ah, the classic must-protect-the-user-from-themselves point of view.

Rarely is one option ALWAYS better than another. Maybe the data on a drive isn't as useful as the battery lifetime of the system? We're talking about a browser here too - potentially the system it is running on contains absolutely no data of any importance at all.

Re:btrfs needed the work

[Rich0]

There are also some potential performance/security improvements by closing the write hole. If the filesystem knows that all the space in a stripe is unused, then it can just overwrite part of it blindly without having to read+merge+write. If the filesystem and raid are in separate layers then no layer has visibility into all of that info.

Sure, layering makes sense much of the time, but if there are genuine benefits from breaking layers then I don't see why we can't claim them.

I suspect that some of the features like instant snapshots would also be difficult with layering. In many ways btrfs does for files what git did for scm - it makes more complex manipulations of data very easy.

Re:btrfs needed the work

[KiloByte]

The issue was, POSIX does not guarantee any ordering of writes unless you call fsync(). A lot of folks wrongly thought that writing a new version of a file, closing it then renaming over the old name is perfectly safe and atomic, guaranteeing there's either the old version or the new one. The rename call indeed guarantees that the directory has either both the old and temp file, or only the new one, but does not say anything about the new file's contents -- you need to at least fdatasync() it.

So unless a new barrier call is added, there is no way around fsync() - and the ext3 slowness that was after big flamewars ported to ext4 is the kernel fsyncing stuff behind your back even if you don't request it, to pander to buggy code.

I don't know what MythTV keeps fsycing for, but I guess they had something that requires consistency, which currently can't be done without fsync. All you can do are clever tricks like WAL in sqlite, or filesystem specific calls like btrfs' features.

It's long overdue for POSIX to get a call that says: "all writes to descriptor A which happened before must be no less durable than all future writes to descriptor B (possibly A == B)". This way, it's possible that after a crash neither A nor B hits the platters, A but not B, or both -- but it's impossible to get B but not A. Such a call has been proposed a few times, but never actually got added.

Re:btrfs needed the work

[Rich0]

Yup, couldn't agree more that fixing the standard makes the most sense. Something similar was done with reflinks in support of btrfs, so you'd think that something like this would be easy to get support for at least by the kernel.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

As much as Linux is doing rather well despite the plethora of different versions and security risk from the open code base, using it is rather risky for legal reasons as well. Red Hat stole much of Linux from SCO's Caldera, and are distributing it without paying royalties, meaning users could be on the hook for several hundred dollars a license and casting the future of Red Hat's offerings in jeopardy.. Litigation is ongoing now, and experts expect SCO to win a crushing verdict any day now. Linux has some neat features, but there's a lot of fear, uncertainty, and doubt in the community about its legal future.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

Nice troll.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[PixetaledPikachu]

Yeah.. No

yes but...

[Anonymous Coward]

When will the nightmare that is Linux audio be comprehensively solved?

Re:yes but...

[oakgrove]

What issue are you having? Audio has always worked flawlessly on my Lenovo G560 running Debian 6, Ubuntu 11.10 and 12.04. The last legitimate issue I recall having was a conflict between pulse audio and Skype a couple of years ago on an Acer laptop but Skype was the only application that exhibited any issue so I assume the app itself was the guilty party. I can't remember the last time I've had any problems since then with either flash, windows games running through wine, mplayer or anything else.

Re:yes but...

[Anonymous Coward]

Several years ago.

Re:yes but...

[walshy007]

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)

Re:yes but...

[Clarious]

It's a common FUD. Nowaday Linux audio works just fine, PulseAudio as a sound server (mixer) and ALSA to talk to the hardware, the rest (OpenAL, gstreamer, OSS, ESD) are either obsolete or totally different stuff unessential to audio playback. Earlier problems related to closed source softwares (Flash, Skype) or badly written HW drivers are mostly fixed.

Re:yes but...

[Clarious]

Why do you need low latency for typical music playback on desktop? It is only for audio professional doing mixing from multiple sources. For laptop users like me, saving 1 W means 5~10% more battery life.

Re:yes but...

[Anonymous Coward]

Sound is still screwed up from Java, unfortunately. I've all but given up trying to get Java to work with PulseAudio properly. Ubuntu 12.04 and (pick one) OpenJDK or Oracle Sun JDK, 6 or 7, I've tried them all singly or in holy and unholy combinations. I'd blame the application (Subsonic), but I can't get it to work using the Java APIs directly from my own code, either, so I'm fairly sure it's in the interaction between PulseAudio and Java. Sound does work OK from non-Java apps. I'm to the point where I'm just about to hold my nose and run Subsonic in a Windows XP VirtualBox VM.

Posting anonymously due to the shame of suggesting XP.
CAPTCHA: repent (!)

Re:yes but...

[Anonymous Coward]

Sounds like you might have a hardware issue because I've been running Subsonic since Ubuntu 11.04 on multiple different devices and have never had a problem with audio playing. As a matter of fact, I find it works better in Linux than it does on Windows Vista which is the last version of Windows I've used on the bare metal.

Re:yes but...

[tqk]

When will the nightmare that is Linux audio be comprehensively solved?

You're kidding, right? It was a decade ago when I last had any difficulty with audio (because I didn't know what I was doing). What, are you trying to get umpteen thousand sound using apps to play together nicely?

Re:yes but...

[datavirtue]

Boy are you lucky. The train-wreck audio problem was ONE of the reasons I had to dump Ubu11 and all of its variants. I tried to get off of Windows, but alas, it was not to be. Are you running the 64bit (Not Recommended) distro?
 

Re:yes but...

[datavirtue]

yeah......mostly.

Re:yes but...

[Anonymous Coward]

Hmm...I'm sorry you're having problems but I have to say that I haven't had a single audio problem in Linux for years and years now. With Ubuntu everything just works flawlessly and this is on several different hardware systems including laptops and desktops. As a matter of fact, with the real time kernel and JACK, I've had a much better experience doing pro audio work using ardour on my linux box than I did with Protools on my windows computer.

Re:yes but...

[Anonymous Coward]

PulseAudio is unessential to audio playback, too. All I've seen it do is provide another level of indirection and a configuration problem (actual, not FUD). OSS will probably live forever as an API because at least its cross platform for unix and is actually sane to write code for.

Re:yes but...

[Anonymous Coward]

If you have more than one audio card, be prepared for it to be a huge pain in the ass to get it running. Double that if your secondary card has more features than your primary but was manufactured more than 8 years ago.

Re:yes but...

[Anonymous Coward]

I don't know. Prior to the advent of pulse audio on my distros of choice, I had audio issues from time to time. Usually small stuff like audio randomly stopping working or not being able to play certain applications simultaneously. But when pulse audio was released and stabilized, my Linux audio problems came to an abrupt halt. Hopefully, it will just keep getting better and better.

Re:yes but...

[Anonymous Coward]

One of the fantastic features I've been using as a direct result of pulseaudio is being able to use all of my sound cards simultaneously. It forms the basis of my multi-room audio system at home and also comes in very handy when I set up security systems and need to pipe audio around to different listening stations. I'm not sure what problem you're having but I couldn't live without pulseaudio.

Re:yes but...

[maugle]

You don't need it for music playback, but it can become noticeable when playing games.

...that is, it will become noticeable when playing games in the distant future, when Linux actually has games.

Re:yes but...

[Anonymous Coward]

Er, well, tablets /are/ the future.

Linux is never going to get significantly more share of the desktop. There was a brief chance of catching-on during the Vista debacle, but MS has reestablished its grip on that hardware market.

Meanwhile we've got a generation growing up with palm computers called cell phones. This has kicked open the OS market and significantly kicked open the app market - we've got a generation that is a lot less locked in to MS as vendor, and a lot more in tune with portability of data format.

Tablets are just big cell phones. MS is too late to the game on cell phones to lock down that hardware market. It's relatively wide open, and it will be feeding a generation that isn't nearly as xenophobic about whateverinhell brand they're running, as long as it interfaces with everyone else. Linux can be a major normal player here, rather than something a handful of self-styled renegade / hobbyists switch Windows boxes to do.

Roughly speaking of course. And putting myself in the latter category of old-people who aren't leaving the desktop any time soon.

Just tablets /are/ the future, not a sort of speedbump like netbooks were. People will skip desktops the same way a significant number of us have skipped having a land-line telephone; we didn't need one in college, so we never bothered afterwards.

(but yeah, agree about audio. gimmie jack.)

Re:yes but...

[Anonymous Coward]

Last time I checked, "Linux" had plenty of games.

Re:yes but...

[smash]

Try FreeBSD instead. Or PC-BSD, which is essentially FreeBSD with a fancy installer.

Re:yes but...

[smash]

Why do you need audio playback on a typical desktop? For laptop users like me, saving all audio related watts by using my portable music player means better battery life.

Re:yes but...

[shaitand]

Actually if I have any complaint about Linux its the fact that most of your assistance comes from google (the same with any os/complex hardware) and there is so much outdated documentation out there.

Someone whose card wasn't detected might well find information telling them how to play with those obsolete technologies. You might even still be able to install some of the stuff it tells you to. Actually with old documentation it likely tells you download some tarball onto your binary distro and ./configure, make, make install it! I know far too many people who turn perfectly good systems into nasty unworkable crap that way. The sad thing is they are usually older *nix hackers who learned things this way before repos existed and were fairly complete.

Seriously kids install binaries for your distro. Failing that, alter distro source rpms to build rpms that are as you need them. Failing that use an rpm explicitly marked as arch independent and alter it and any dependencies to match their labels on your distro (yum localinstall NOT rpm -i). Failing that, build an rpm that does so yourself. Replace all that with debs where appropriate in deb land. If you have a guide that starts by telling you to download a tarball and install it then try getting the rpm and following from there if you can't find one specific to your distro.

Re:yes but...

[Anonymous Coward]

I use Linux daily. Fine system except for pulseaudio. Are there any full-featured desktop distros that don't depend on that terrible sound server? Can someone with weak linux fu (me) recompile gnome and all the apps to go back to ALSA?

Re:yes but...

[shaitand]

I could see Linux making inroads into the business desktop world if it ever got a decent exchange replacement.

Re:yes but...

[shutdown -p now]

It's a common FUD. Nowaday Linux audio works just fine

My desktop still can't auto-switch between speakers and headphones when the latter are plugged in and out, on any distro (it just plays sound through both of them). The relevant bugs have been in Ubuntu database for years now.

Re:yes but...

[adolf]

But that costs space, weight, money, and perhaps time, plus almost certainly complexity when it comes to charge the thing(s) at the end of the day.

If I'm out and about ("traveling,") and my laptop is open, I prefer to play music from it because it has the best interface. Both my phone and my laptop can access the same music (thanks to Subsonic), but I like having a real keyboard and pointer for selecting things and it's fewer physical boxes to fuck with. (And, no, I'm not -also- going to carry a dedicated music player -- even with cargo pants, I'll always prefer to have a pocket knife and a backup pocket knife over any other redundant gear on my person, and that's already getting silly: I don't also need three music players. FFS, I'm traveling, and my gear is already heavy enough.)

YMMV, but if I've already got a particular bit of kit out and in front of me and it can do the thing that I myself want to be doing, I generally prefer to use it for that rather than an additional box. (And playing music should not be a stressful operation for a normal laptop, as long as the screen is already on because I'm actively using it -- stuffing a few milliWatts out through the headphone jack is not a big deal.)

Back to the topic: The discussion sounds a whole lot like Windows, to me. There's the usual way of doing audio (which might be efficient and is never low-latency), and then there's ASIO (which might not be power-efficient but is low-latency as a design parameter). It's damn near exactly like this discussion between PulseAudio and JACK, respectively: Both have different design goals.

And more to the point: Use them both, as needed. *shrug* Use them at the same time, for all I care. (Last I looked, all of the *nix audio kits could be integrated together on a single machine in any fashion the heart desires.)

Re:yes but...

[Anonymous Coward]

Just because YOU don't need, you don't have to poo-poo the whole low-latency thing. I find audio latency *very* annoying. Yes, I mix and master (or, I try to - it takes Gentoo-level attention to detail and configuration to get something half reasonable going).

But even when "just playing" music, I find it a much more satisfying and pleasant experience when I click on something in the GUI, that the change is heard immediately. To the point that a normal desktop I find stultifying to try to play music on when I'm browsing, listening to this and that, to pick out a playlist.

Have you ever tried a good low-latency setup? You might not know what you're missing.

Re:yes but...

[adolf]

Prior to the advent of pulse audio on my distros of choice, I had audio issues from time to time. Usually small stuff like audio randomly stopping working or not being able to play certain applications simultaneously.

[Old Man mode]: I remember a time before PulseAudio, and before JACK, and before ALSA: The Linux kernel had some built-in drivers ("OSS-Free"?) which supported adequate functionality for every sound card/chip on the list, and if you wanted more features or support you could just pay 4front for a better driver (and they were always worth the minimal price).

And: Everything. Just. Worked. Always. Hardware settings (back when sound cards still had configurable analog sections(!)) were deterministic and reliable, and getting excellent sound from *random_app* was a foregone conclusion.

Much fun was had, for instance, with "cat /dev/audio > /dev/st0" to dump a radio show (reliably! without problems! in the plain-and-simple way that Unix is supposed to be!) to DDS tape.

Now, this was 17 (or so) years ago. Anything involving further difficulty, at any stage of the game on a user level, on the Linux sound front is a step backward.

Now, get the fuck off my lawn.

[/Old Man mode]

Re:yes but...

[adolf]

That's a bummer.

As a counterpoint: Can you tell me how to turn off that same feature under Windows? I *don't* want it to auto-switch, but it insists upon it.

Re:yes but...

[impaledsunset]

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

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:yes but...

[gagol]

Actually if I have any complaint about Linux its the fact that most of your assistance comes from google (the same with any os/complex hardware) and there is so much outdated documentation out there.

I agree, that is why I include my distro name and version in my search, plus you can limit results in time (pages update in the las 24 hours, month, year, etc...).

Re:yes but...

[Anonymous Coward]

Lip sync for video, skipping through video, video audio sync in general.

Am I the only one playing movies in linux? Guess so. Weird the XBMC guys make that linux software just me for, though.

Re:yes but...

[semi-extrinsic]

This sounds like a driver bug, in which case you shold file a bug upstream. Both my wife's laptop (Ubuntu 12.04) and my laptop (Archlinux) do this without problems, plus you can turn this feature on/off in alsamixer.

Re:yes but...

[shutdown -p now]

Like I said, bugs have already been there in Launchpad when I first hit this, three years ago or thereabouts. It seems to be a hardware-specific problem with telling the outputs apart (basically, it doesn't distinguish front/back jacks). but it affects one of the more common Realtek chipsets that were used in the motherboards at that time.

Re:yes but...

[Anonymous Coward]

Why do you need audio playback on a typical desktop? For laptop users like me, saving all audio related watts by using my portable music player means better battery life.

I agree completely, it's much easier to buy an Apple product to playback audio than attempting to make Linux do so.

Re:yes but...

[Sigg3.net]

Yeah, they mostly come at night... mostly...

Re:yes but...

[semi-extrinsic]

I assumed from your nick that you knew what upstream means. What I meant is that the bug should not be filed with Ubuntu (Launchpad), it should be filed with the audio subsystem of the kernel. Also, Ubuntu updates the kernel infrequently, especially if you're still on 10.04 or some other old version, so it could be that the bug is fixed in a newer kernel than yours.

Re:yes but...

[Sosarian Avatar]

Could be wrong, but I believe that the Trinity Desktop (it's continued development of KDE 3) relies solely on ALSA regardless of what distro you're running.

Re:yes but...

[Anonymous Coward]

That's a bummer.

As a counterpoint: Can you tell me how to turn off that same feature under Windows? I *don't* want it to auto-switch, but it insists upon it.

Depends on the audio hardware and driver, but for many it should be under advanced sound settings, like this Realtek example: http://www.sevenforums.com/attachments/sound-audio/132788d1295356338-switch-between-headphones-speakers-capture5.jpg

Re:yes but...

[shutdown -p now]

I know what upstream means, I just missed it in your reply. IIRC, there was one as well - in any case, that's the job of the distro folk to do as needed. It's not crucial for me because Linux is not my primary OS, and I don't do anything there where this makes a big difference; it's just a mild annoyance.

As also noted earlier, this isn't Ubuntu specific - it repros just as well in a fully up-to-date Arch, for example.

Re:yes but...

[pr0nbot]

I use Linux mainly to play SW:TOR under Wine. It all works reasonably well, with the exception of sound. I either get full glorious sound, or no sound at all. At first I thought it might relate to me alt-tabbing to something else while the game is loading, but after trying to reproduce it, it seems entirely unpredictable. So for me at least, Linux audio doesn't work just fine.

Re:yes but...

[cyxxon]

That might be because of HD Audio instead of AC97. I recently built a new desktop PC with a new case, and installed the latest Realtek drivers from their website (instead of the version from the Asus mainboard cd). I then experienced the behaviour you described - whenever I plug in my headphones, the sound from the speakers stops. Infuriating. I want to turn the speakers on and off when I do not want to use them, but now I manually have to unplug the headphones as well? Yeah, I twiddled with older Realtek drivers etc., until I found out that it is a "feature" of the HD Audio extension boards. Great, I thought, just install the AC97 board for the case... except I cannot find it anymore, a month after building the machine. I know I saw it somewhere in the boxes... ;) But seriously, check that out.

Re:yes but...

[rdnetto]

Flash still seems to use ALSA directly instead of PulseAudio. It was a lot easier to simply replace it with Gnash than to change the config.

Re:yes but...

[Clarious]

Jack detection can be done in many ways, and different vendor have their own way of doing so, unless somebody get a hardware specification set for your sound card, I don't think it will be easy to fix.
And yeah, it is a driver problem.

Re:yes but...

[Clarious]

alsamixer -c0 should let you config the first sound card of your computer, not PulseAudio switches. Note that sometimes you might have two hardware sound cards or more, in that case choose the correct one in alsamixer.

Regarding to system wide daemon, I have never used PulseAudio that way so I can't say anything, but running a sound server as root doesn't seem like a good idea to me.

Re:yes but...

[Anonymous Coward]

There is no need for low-latency at all for lip sync, you only need precise knowledge of the latency.
Of course pulseaudio regularly has bugs that cause it to be off more than 10 ms, so it doesn't work for that really. But that's just a bug, precise latency measurements don't even need to cost you anything in power usage (trivially if the audio hardware is somewhat sane, if not it gets more difficult but is still possible).

Re:yes but...

[Anonymous Coward]

I am willing to downgrade to 11.04 to try it. Spent an entire day putting 12.04 on it because it's an old laptop without PAE. Then spent a weekend fighting with Subsonic/Java/PulseAudio, which was the whole point of the effort. Disgusted, have been ignoring it for weeks.

Re:yes but...

[hey!]

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:yes but...

[marsu_k]

And: Everything. Just. Worked. Always. Hardware settings (back when sound cards still had configurable analog sections(!)) were deterministic and reliable, and getting excellent sound from *random_app* was a foregone conclusion.

Oh yeah, the OSS driver just worked. That is, unless you had more than a single program that wanted to output audio. There was a reason why we had ESD / aRts / etc at the time being. I'm glad we have ALSA now (PulseAudio I loathe, JACK is useful if you really need low latency, most users will not).

Re:yes but...

[Anonymous Coward]

OSS is nowhere near defunct and is still under active development. It is superior in every way to the complete and utter crap known as Pulseaudio. Ever taken a look at how PA is designed? It is layer upon complicated layer upon another complicated layer. It's design is completely insane. I *still* in 2012 get kernel oops'es because of PA (looking at /var/log/syslog right now on my Ubuntu 12.04 box and I see tons of entries relating to PA failures).

Re:yes but...

[Anonymous Coward]

I agree. Pulseaudio is the biggest scam pulled on Linux users in the last decade. It is incompetently written and horridly designed. We are stuck with it, though, because the distro maintainers, in their infinite wisdom, have become convinced it is the answer.

For some reason they have totally failed to look at OSSv4 and how superior it is. Indeed, OSSv4 can directly replace BOTH Alsa and PA. It is much more sanely written, has better audio quality, and has never crashed my audio. PA crashes my audio daily. the problem is most distros are making it near impossible to remove PA. In the past I could remove it and just compile and install OSS. My audio problems were always solved. Now if I try to remove PA, I have to take most of the OS with it.

Re:yes but...

[Hatta]

So OSS4 has been available under GPL terms for some time now. Why don't the kernel folks give it another look?

Re:yes but...

[Anonymous Coward]

Let's just say it mostly works...

Pulseaudio is just a workaround to many problems that still plague linux audio. Not trying to belittle the development effort, but I do believe that in some ways the effort has been to work around the problems instead of addressing them.

And OSS (at least v4) is not obsolete, it is indeed in many ways superior to ALSA. For example it has per-application volume control, something ALSA relies on Pulseaudio to provide. This article - http://insanecoding.blogspot.pt/2009/06/state-of-sound-in-linux-not-so-sorry.html - although somewhat dated explains it very well. OSS v4 just lacks (mainly) a broad distro support... :(

Re:yes but...

[isorox]

Much fun was had, for instance, with "cat /dev/audio > /dev/st0" to dump a radio show (reliably! without problems! in the plain-and-simple way that Unix is supposed to be!) to DDS tape.

Well I don't remember having a tape drive plugged in, but I also recall the late 90s. cat /dev/urandom > /dev/dsp to check my headphones were working etc.

However sound was an issue. If I recall correctly, you couldn't have two applications opening the sound at the same time for instance.

Sound went through a ropey couple of years with different programs all attempting to use the hardware in different ways, but I haven't personally had any problems for over 5 years.

Re:yes but...

[Bengie]

Just an interesting note, but not meant to be read as "Windows is better".

Starting with Vista's new audio stack, Microsoft created a new standard for audio devices to work with the OS. Effectively lets the OS just work with buffers. Jack-detection and lots of other fun features automatically work with the generic Windows audio drivers. It's like AHCI, but for sound devices.

I wonder if this is documented anywhere and if opensource can tap into this for OS devel.

I haven't had to use 3rd party audio drivers on any Vista/Win7 badged computer. The only time you really need 3rd party drivers is for cards like the Asus Xonar that have an integrated amp, for which the generic audio drivers have no interface to manage. Technically, that like of stuff can be manged side-channel and still use the generic audio drivers.

Re:yes but...

[Bengie]

This is not a negative post, just curiosity.

What do you classify as "Low latency" for audio(in milliseconds)? I know Window's audio stack has a "normal" and "low latency" mode, where the low latency mode application gets exclusive access to the sound device. Even "normal mode", which is higher latency, seems instantaneous for my perception, but I could easily understand how millisecond difference can alter wave interaction from sound inputs.

From what I can find, Vista/7 have a normal mode of ~10ms latency and an exclusive mode of 1-5ms(depending on hardware and CPU load) latency. Human perception has a max threshold of ~4-6ms before two audio-streams sound synced with no tone coloring, and an action is considered synced with a sound around 30-50ms(depending on the person).

10ms is well below the 30-50ms required for desktop use.

Re:yes but...

[Anonymous Coward]

FUD, fear uncertainty and doubt. You sure you really want to label a problem that many of us experienced as FUD? We've always been at war with eastasia! The zealotry is strong with this one folks.

Re:yes but...

[Anonymous Coward]

and OSS is still going on strong, has all the features that pulse audio adds such as per program sound levels etc.. http://www.opensound.com/

Re:yes but...

[Anpheus]

Perhaps I read this wrong, but the complaint sounds a lot like Linux developers are treating the DSDT like Microsoft developers treated HTML circa IE6. i.e.: It was coming from broken sources and the best option is to throw your hands up in the air and forego any attempt at sanely handling the results in a way consistent with expectations.

Well, that's wrong. I mean, yes, it's bad that Microsoft might have gotten everyone into the situation and we should shame them, and it would be nice if a standards body came along to force them and OEMs to be consistent here... But that is an ought, not an is.

So why is it so totally impossible to implement quirks parsing in the DSDT to emulate Windows behavior? What makes it so difficult that I have read only posts complaining about ACPI DSDTs produced by bad Microsoft software, and no posts about simply dealing with the situation for the benefit of end users?

Re:yes but...

[mister_playboy]

Arch Linux uses ALSA as a default if you follow the basic install docs. :)

I don't think I had any PulseAudio problems since Ubuntu 10.04, but I just want sound to work and that is what ALSA is giving me right now.

Re:yes but...

[Compaqt]

Wait, gstreamer is obsolete?

I thought just yesterday it was the new hotness.

It was supposed to be the new a/v system that Ubuntu was building itself around.

Re:yes but...

[smash]

Sarcasm detection FAIL

Re:yes but...

[adolf]

Meh. That was a failure of sarcasm-insertion. :)

Re:yes but...

[ratboy666]

Shaitand

First, what does Exchange have to do with audio?

Secondly, what are you looking for? A replacement for the Exchange Server? Sorry, probably not happening. If you HAVE a need for Exchange, you buy Exchange, right?

But, you mentioned "business desktop". Why not go with Evolution, then? Talks with Exchange, does mail, calendar, notes and contacts. What more would you need? The only thing "missing" is the ability to change your Windows Domain Password. So, just use an RDP client (Remmina would be one choice) to log in to a Windows Server in that Domain. For instance, try to log in to the Exchange Server. Of course you (probably) because you would have to be an administrator, but the ATTEMPT will allow you to update your password.

Mail - check
Notes - check
Calendar - check
Contacts - check
Password Change - check
RDP - check

Now, Evolution is (in my opinion), far better than the Windows Exchange client. Talks to more server types, allows a choice of spam control, better signatures, threads both Microsoft and Unix emails, and more.

So try it -- if it works for you, problem solved, right?

(I was forced to use Windows Exchange client a few years ago. I was shocked that emails weren't threaded! But, I think this has been sorted recently -- just not compatibly).

Re:yes but...

[Anonymous Coward]

Booya! AC troll done got trolled the fuck out by the masta! Trooooleeegrove!

His dick doesn't work anymore, but Linux always works for Trollgrove. So, while you're pounding da pussy, he's cranking out the most powerful FUD-busting posts that troll so hard you will wish you had stayed on dial-up.

Trollgrove, represent!

Trollin' Trollin' Trollin'
Keep postin', postin', postin',

Though they're disapprovin',
Keep them zealots fapin' Trollgrove!
Don't try to understand 'em,
Just grab and bend and fuck 'em,

YEAHahaha!

Troll em' long and troll em' hard, Trollgrove! Suck that FOSS dick and swallow the sweet taste of freedom, yeah!!!!

Re:yes but...

[walshy007]

What do you classify as "Low latency" for audio(in milliseconds)?

I tend to run about 4 or 8 msec with jack, this is with a multitude of programs being able to use it unlike windows. Some people run lower (you can set it as low as you want.. if your hardware can take it is another matter) but there isn't much need and I think pcie bus latency + other factors might start to kick in.

The best windows setups I've seen still tend to hit around 10-12msec with it more typically being 20-30. Although here seems to say 3 might be possible with asio, with 11-12 being more typical minimum. Mac systems I've seen never tend to go below 6, which is fine.

Re:yes but...

[Bengie]

Sounds like....hehehe... pun... Sounds like your *nix setups have a more consistent latency. Thanks for the response. It's hard to find info on the topic without delving into pro discussions that go over my head or make certain assumptions about their audience.

Re:yes but...

[KugelKurt]

I use Linux daily. Fine system except for pulseaudio. Are there any full-featured desktop distros that don't depend on that terrible sound server? Can someone with weak linux fu (me) recompile gnome and all the apps to go back to ALSA?

GNOME and GNOME apps depend on PulseAudio.
In KDE land PulseAudio is optional thanks to the Phonon playback stack and multiple possible back-ends. I use Plasma Desktop, Phonon-VLC, and pure ALSA. I have no sound problems at all.

They fix the sound bullshit yet?

[ArchieBunker]

Did anyone finally agree on a standard for sound cards or is someone else going to have a hissy fit and write yet another audio subsystem? Fucking agree on something already.

Re:They fix the sound bullshit yet?

[Anonymous Coward]

Yep its called "YASS" -Yet Another Sound System

Of course that will be forked for "YABSS" - Yet Another Better Sound System" which will then cease development due to lack of interest (or perhaps the dev finally "got some"), and require a mainter to take over it.

Re:They fix the sound bullshit yet?

[Anonymous Coward]

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:They fix the sound bullshit yet?

[Anonymous Coward]

I believe you are misinformed. As far as the kernel goes, there has only been one standard for sound cards for over a decade now: ALSA

Re:They fix the sound bullshit yet?

[walshy007]

They have, pulse for end users and Jack for people who care about their audio.

Why not one interface? Because the low latency goals of jack conflict with the low power goals of pulseaudio (designed for use on netbooks and tablets etc) why desktop users had to suffer so much into the pulse transition just to cater to that crowd I have no idea.

Re:They fix the sound bullshit yet?

[ArchieBunker]

Was looking for a "stereo mix" option to record some audio being played. Doesn't seem to be an option in linux. Works great in windows though.

Re:They fix the sound bullshit yet?

[Clarious]

"Another" audio subsytem? Today standard is PulseAudio on ALSA, and that it has been like that for at least 4 years. Before ALSA there was OSS but Linux developers disagree with how OSS do the sound mixing and resampling in kernel space (for better latency, they said) and OSS went closed source for awhile. PulseAudio is an effort to unite all the sound server/mixer (ESD from GNOME, aRTs from KDE or ALSA's own dmix) plus some nifty features like better battery life (less wake ups per second).
Update your FUD once in awhile, please.

Re:They fix the sound bullshit yet?

[Anonymous Coward]

The Pulse/Jack difference isn't power consumption, it's intended use.

Pulse provides a simple API for just making noise.
Jack provides a low-latency API (like you said) for the purposes for music creation and other things that require true low latency audio (and no, that doesn't include games) with a significant trade-off in complexity.

Re:They fix the sound bullshit yet?

[Anonymous Coward]

Wait, whut?
Start Pulseaudio, start an audio recorder. Pavucontrol can let you record "monitor", which basically means your stereomix option. Does that help?

Re:They fix the sound bullshit yet?

[tqk]

Would you two please just go get a room? We adults have important things to talk about.

Re:They fix the sound bullshit yet?

[ArchieBunker]

Start Pulseaudio? Never even heard of that. On windows I just chose the recording source Stereo Mix. Why does linux make it difficult?

Re:They fix the sound bullshit yet?

[Anonymous Coward]

On Ubuntu you just have to start and audio recorder........

Pulse Audio is built right-in the Ubuntu. So no, "linux" doesn't make it "difficult".

Re:They fix the sound bullshit yet?

[Anonymous Coward]

Pulseaudio works as a system service out of the box on linux. The whole thing is completely transparent. If you don't have a clue what you are talking about maybe you should just be polite and keep your mouth closed. Mmmkay?

Re:They fix the sound bullshit yet?

[Jonner]

The problems with Pulseaudio were partly caused by buggy drivers, partly by buggy programs and partly by distributions switching to Pulseaudio before the other problems were sufficiently addressed. There were plenty of audio problems before it came along and neither keeping things as they were nor using jack for everyone would have been trouble-free. Jack developers have never advocated it for ordinary desktop users. My experience on both desktop and laptop has been that after a couple of problematic releases of Ubuntu, audio became much less painful overall. Now, dealing with audio is generally much easier than before Pulseaudio came along.

Re:They fix the sound bullshit yet?

[smash]

FreeBSD already did. OSS. One day Linux will dump the pulse related crap and things will come full circle.

Re:They fix the sound bullshit yet?

[Anonymous Coward]

Start Pulseaudio? Never even heard of that. On windows I just chose the recording source Stereo Mix. Why does linux make it difficult?

Starting from Windows 7 Microsoft has hidden the Stereo Mix option (due to pressure from Big Media?), so it's not that easy anymore.

Re:They fix the sound bullshit yet?

[Anonymous Coward]

The fact is pulseaudio still doesn't work well.

(I have tried it relatively recently in fedora).

I use envy24 it works absolutely flawlessly in both FreeBSD and Windows without any silly layers of abstraction.
(This is just for Music Listening). The card has crystals for all the sample rates so it shouldn't need any resampling ever.

If you can find a version of Alsa where they haven't broken it (Seems to happen all the time) and it works correct at 44.1khz
then you can use jackd and it will work fine.

The Alsa / Pulseaudio people might be good at hacking / getting devices to just about work but they know nothing about audio.
(The jackd people do).

Re:They fix the sound bullshit yet?

[Anonymous Coward]

OSSv4 is not closed source, is still under active development and is superior in *every* way to ALSA/PA. Try it sometime. All of your sound issues will magically disappear.

Re:They fix the sound bullshit yet?

[rubycodez]

pfft, your sound will magically disappear, yes

Re:They fix the sound bullshit yet?

[walshy007]

For things that don't require low latency, and have issue with a callback interface that wants specific numbers of samples etc, what is stopping them just making a small fifo buffer to emulate the behaviour they are doing now with pulse? Just feed jack from the buffer.

The developer of pulseaudio admitted it was made for low power consumption, a few ease of use things were mentioned, but they were for the user not developers (and all of which weren't really a problem with jack by then anyway, like hot plugging etc)

aside from the extra resource consumption (there is no need to run low latency if you don't want to) Jack handles any case pulse can, and then some.

Re:They fix the sound bullshit yet?

[Anonymous Coward]

Pulse is just yet another sound server in a long line of failed sound servers. It'll be just another failure to the list later on once people get bored with this sound system too.

Re:They fix the sound bullshit yet?

[Anonymous Coward]

Start Pulseaudio? Never even heard of that. On windows I just chose the recording source Stereo Mix. Why does linux make it difficult?

You're a dumb nigger. You do know that right?

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

My thoughts exactly. Obvious troll is obvious. I especially like the overt mention of FUD.

Yes, 3.4 BUT...

[Anonymous Coward]

Have they fucking fixed that regression with the USB option driver yet? Fucking option_instat_callback: 108 errors every-fucking-where.

Re:Yes, 3.4 BUT...

[Anonymous Coward]

Yes! In the last RC! I'm not having that problem any more at all and 3.4 is rock solid on my systems.

Re:Yes, 3.4 BUT...

[deek]

Achievement Unlocked

Most gratuitous use of the word "fuck" in a serious Slashdot post.

Re:Yes, 3.4 BUT...

[Anonymous Coward]

That's fucking fantastic.

Re:Yes, 3.4 BUT...

[Anonymous Coward]

Shouldn't you be bellowing incoherently at the evening cleaning staff right now?

Re:Yes, 3.4 BUT...

[Khyber]

You must be new here and not have seen many of my posts.

I think one of them not only used fuck a ton, but also got me a visit from the Secret Service.

Re:Yes, 3.4 BUT...

[smash]

I don't think you can call it "rock solid" just yet, it hasn't even been out a week, let alone the few months to be considered even "stable"... Rock solid = years of uptime.

Re:Yes, 3.4 BUT...

[shutdown -p now]

I think one of them not only used fuck a ton, but also got me a visit from the Secret Service.

Inquiring minds want to know. I always fancied inviting the guys in black suits to tea myself.

Re:Yes, 3.4 BUT...

[zaphod777]

Achievement Unlocked

Most gratuitous use of the word "fuck" in a serious Slashdot post.

I wish I had points to give you

Re:Yes, 3.4 BUT...

[Anonymous Coward]

Yeah! the poor fucker...

Re:Yes, 3.4 BUT...

[deek]

I've been around here longer than you have, sonny jim.

Nice work on the SS visit, although they were probably visiting because of your hydroponic setup, rather than being expletive police. Care to link to the post? You've been pretty tame over the last month.

Re:Yes, 3.4 BUT...

[Khyber]

SS wouldn't investigate my hydro setup (despite it having enough new tech to seriously upset the horticultural market and cause serious nat'l sec issues)

The post was years and YEARS ago. Look back some, roughly 2004?

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

Except the courts ruled that SCO owns nothing (SCO v Novell), and thus SCO will lose SCO vs IBM and RedHat v SCO because they no longer have any legs to stand on.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[deek]

Amusing troll. It would have been more subtle if you didn't reveal your knowledge of kill signals and shell names. You should have tried to call "bash" something like "clash" or "smash".

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[bubkus_jones]

Damn, I had mod points yesterday. Consider this my unofficial +1 Funny

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

Don't feed the trolls...by which I mean me.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

It's not even a nice troll actually. It's outright sad that someone even bothered to write that. It isnt offensive or even remotely believable, it's just dumb uninteresting garbage.

That there is some good old fashioned /. trolling.

[sidragon.net]

Thanks for the laughs. Keep it up!

Most programs don't need a 64-bit address space

[Myria]

The new x86-64 ABI with 32-bit pointers is cool because it allows you to get the architecture improvements of x86-64, such as extra registers and RIP-relative addressing, without increasing memory usage substantially due to larger data structures. Also, 64-bit operations will just use the 64-bit registers. The vast majority of programs simply do not need the extra address space.

One reason that this ABI works so well is that the majority of the x86-64 instruction set uses 32-bit operations. Some operations involving pointers can be done in one instruction without using a temporary register to load a 64-bit constant.

Windows actually also can support this, in theory, but you're on your own in trying to communicate with the Win32 API. The linker option /LARGEADRESSAWARE:NO causes the NT kernel to limit your program's address space to 2^31 bytes.

Re:Most programs don't need a 64-bit address space

[Clarious]

But it will reduce the address space available for ASLR, am I right?

Re:Most programs don't need a 64-bit address space

[Mr Z]

Yes, but so what? A system that supports x32 should also support x86-64. So, if you're relying on ASLR for security purposes, compile those sensitive apps as x86-64.

Granted, the potential attack surface grows as you consider larger and larger threats. For example, a GCC compiled as x32 makes a fair bit of sense. What about Open/Libre Office? Well, that depends on if you open untrusted documents that might try to exploit OOo / LO. (Odds seem pretty low, though.) And what about Firefox? Far less to trust on the web...

So, at some point, you have to make a tradeoff between the marginal benefit of increased performance/better memory footprint in x32 mode vs. increased security against certain overflow attacks that ASLR offers. For most people in most situations, the former likely wins for anything with a decent memory footprint. For people building hardened Internet-facing servers, the latter probably wins.

Re:Most programs don't need a 64-bit address space

[Anonymous Coward]

Yeah, "x86-64 ABI with 32-bit pointers" is da bomb! It fucking rocks, man! "x86-64 ABI with 32-bit pointers" will change the world!

Re:Most programs don't need a 64-bit address space

[smash]

You've seen the prices of 16+ GB of ram recently, right? Shaving a few bytes here and there in your CODE (not in your data, which is far and away larger) by writing for 32 bit pointer use in the days where 16GB of ram is under a hundred bucks is retarded.

Re:Most programs don't need a 64-bit address space

[smash]

I very much doubt the former "wins" at all. Code is far, far smaller than data it operates on, which has nothing to do with pointer size or register size causing increased footprint. 2 systems is ambiguous and enables applications to be written for the wrong security model. Just compile everything for x64 and be done with it.

Re:Most programs don't need a 64-bit address space

[Mr Z]

There are those much more famous than I who would disagree with you. (Scroll down to "A Flame...") Of course, appeal-to-authority is not a great way to argue a point that should be settled by data.

Some workloads are amazingly pointer heavy. Compilers and interpreters are very pointer heavy, for example. At least one SPEC benchmark sped up by over 30% in early testing. Then again, a couple others slowed down, which seems odd. I imagine we'll just have to see what happens as the compilers get tuned and so forth.

If you don't like x32, don't enable it on your system. I don't think it should be written off so easily, though.

Re:Most programs don't need a 64-bit address space

[Narishma]

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:Most programs don't need a 64-bit address space

[Anonymous Coward]

Not really, most OO systems use a shit ton of pointers (to the point that the java VM has pointer compression mechanisms), which adds up a lot of space. Also, it's a matter of speed too, having big code causes a lot of cache thrashing. Pay a look at this: http://www-cs-faculty.stanford.edu/~uno/news08.html "A Flame About 64-bit Pointers"

Re:Most programs don't need a 64-bit address space

[Nutria]

For a guy with such a low UID, you sure know crap little about CPU cache and.

Re:Most programs don't need a 64-bit address space

[Anonymous Coward]

I very much doubt the former "wins" at all. Code is far, far smaller than data it operates on, which has nothing to do with pointer size or register size causing increased footprint.

I was talking about data memory usage to begin with; the code size like you say is mostly irrelevant. The problem is that many data structures have embedded pointers. A doubly-linked list goes from 8 bytes of overhead per node to 16 bytes. This is where your memory losses are. There are other places where you consume more data memory, such as size_t and alignment requirements.

Re:Most programs don't need a 64-bit address space

[unixisc]

That's for now. After a while, your on-chip caches may grow to 8GB and beyond, at which point, you will need pointers more than 32-bit. So why not break the 32-bit habit now, so that you don't have any transition issues when that time arrives?

Re:Most programs don't need a 64-bit address space

[Anonymous Coward]

You must be one of those wizard sysadmins I hear so much about. Quick, wipe the cheetos from your beard, a woman is coming by!

Re:Most programs don't need a 64-bit address space

[Anonymous Coward]

obviously modded up for low uid, completely ignorant about the way computers work

have you looked at the size of l1/l2 cpu cache recently? not exactly 16GB now is it.

herpa derp

Re:Most programs don't need a 64-bit address space

[petermgreen]

You've seen the prices of 16+ GB of ram recently, right?

16GB is pretty cheap, beyond that it starts to get expensive because you either need either expensive 8GB modules or a high end CPU platform (intel LGA2011 or amd G34) with more ram channels.

If you plan for all your ram to be used by one big process thaen x32 won't be of interest to you. OTOH if you are serving webapps (lots of processes but each individual process not using much ram) written in languages that make heavy use of pointers then x32 starts to look attractive.

not in your data, which is far and away larger

All depends on what form your data is in, if it's just one big lump of processor-independent data then you probablly won't gain much from x32.

OTOH if it's complex structures with lots of pointers then using a system with 32-bit pointers will reduce it's size considerablly.

Re:Most programs don't need a 64-bit address space

[Anonymous Coward]

That's for now. After a while, your on-chip caches may grow to 8GB and beyond, at which point, you will need pointers more than 32-bit. So why not break the 32-bit habit now, so that you don't have any transition issues when that time arrives?

What is the latency of this 8GB cache you propose? :)

I used to write spice-like simulators. A chip is obsolete nine months after launch, and circuit simulations take several months of CPU time. Parallelizing across a cluster helps, but giving designers feedback as they make changes means you get a working chip to market on time. For this application, cache hit rate matters. We don't choose processors with huge caches. Larger caches are slower, because it takes longer to access a larger memory.

If you don't work on systems where performance matters, do what you want. Don't tell those of us who do that we need to shoot ourselves in the foot to satisfy some silly rule you make up.

Re:Most programs don't need a 64-bit address space

[Chemisor]

When you talk about space savings due to use of 32 bit pointers, you forget that a 32 bit program running on a 64 bit system will need to load all 32 bit libraries, the size of which greatly exceeds the amount of whatever savings you may or may not achieve. I'd say that most programs don't need to be 32 bit, and should only be compiled for 32 bit only if there is a substantial measurable performance gain. Otherwise, it's nothing but premature optimization, which usually does more harm than good.

Re:Most programs don't need a 64-bit address space

[Narishma]

Because most applications don't need to address more than 4GB of RAM, not now and not in the future. For the few applications that need to, they can be compiled for x86-64 and used on the same system, just like you can already use x86 and x86-64 apps at the same time.

Re:Most programs don't need a 64-bit address space

[Anonymous Coward]

Because we currently don't have 4GB caches. If you look at actual hardware, you'll see that they still use bitwidths that are appropriate for the current state of technology. E.g. none of the x86-64 CPUs actually has 64 bit physical address spaces, but 53 bits. That would be mightily inconvenient in software, but using 32 bits instead of 64 bits isn't.

Re:Most programs don't need a 64-bit address space

[Anonymous Coward]

so a laptop that i want to play with large numbers on should burn through the battery faster even if i have small data sets, because the RAM is "cheap"? isn't *that* retarded?

Re:Most programs don't need a 64-bit address space

[DarkOx]

Its not going to save any bytes in your code and depending on the implementation may or may not save bytes where data at rest is concerned. Its going to save bytes in your live data which in most cases is bigger than your code larger than the corresponding number of records at rest.

Think about a the basic linked list. At a minimum ( for a single linked list ) you have a pointer on every record, that pointer could either be four or eight bytes. Even something like an office document or a web page of moderate complexity might have millions of elements the rendering software needs to track. That could be 4MB of working storage saved right there.

Yes 16GB of RAM for your desktop is cheap. It will cost more for ECC server memory though. Lots of server apps need to handle thousands of clients. That memory savings might mean a great deal there.

Re:Most programs don't need a 64-bit address space

[Bengie]

L1 cache will more than likely not grow that much as the larger the cache, the higher the latency and there is a benefit of having 1-2 cycle latency for modern x86 chips.

If you want to throw a ton of registers and some barrel thread processing at a chip, you can have much larger higher latency L1 cache that is hidden by massive amounts of registers that require few memory accesses and your memory loads are mostly hidden by the thread-shifting. Don't expect great multi-threaded intra-process scalability though as the higher latency cache will hurt data passing. Really great peak throughput though.

Re:Most programs don't need a 64-bit address space

[Bengie]

16GB is pretty cheap, beyond that it starts to get expensive

Depends on what you mean by "expensive". I remember 16MB of ram going for $800. Now I can get 32GB(4x8GB) ECC 1333(1600 is about $100 more) 1.35v namebrand for $290. DDR4 will drop those prices down a lot with newer die-shrinks.

Re:Most programs don't need a 64-bit address space

[unixisc]

With the trend towards multi-core CPUs, I doubt that they will have tons of registers. But now that you mention it, I do agree w/ you that due to increases in the latency, L1 cache is unlikely to grow much, and if anything, CPU makers might prefer either larger L2 caches or L3 caches even. Although what might happen is that such multi-core CPUs would have caches for each core, but they might be treated as a unified memory.

Re:Most programs don't need a 64-bit address space

[Anonymous Coward]

CPU caches are transparent to execution ... programs don't explicitly reference them. How did this get modded so high without getting called out?

Re:Most programs don't need a 64-bit address space

[Blaskowicz]

actually, it's a recent thing but 8GB dimm prices have crashed as well. I can get 32GB for 200 euros, if that, and it can go in a regular motherboard with a low end CPU. lga 2011 will net you 64GB, with an i7 3820 and keeping everything cheap you almost build a complete PC with 64GB for 1000 euros.

Re:Most programs don't need a 64-bit address space

[smash]

History has shown that CPU speed scales much faster than programmer speed. History has also shown that people can't write secure code, thus giving up ASLR is a bad thing.

Re:Most programs don't need a 64-bit address space

[rubycodez]

nonsense, 64 bit programs also have to load bigger 64 bit libraries. there is no issue.

Re:Most programs don't need a 64-bit address space

[Chemisor]

Although 64 bit programs also have to load libraries, those are shared among all the other programs. Since your 32 bit program is alone, all its libraries are not shared. xterm, for example, loads 6M worth of libraries, all of which will be shared with any other X application. Only 1.6M is used for runtime data. If you were to compile a 32 bit xterm and run it on the same machine, it will load an additional 6M of 32 bit libraries, increasing the amount of unshareable memory from 1.6M to 6M+1.6M, a fivefold increase.

Re:Most programs don't need a 64-bit address space

[Anonymous Coward]

Actually, most CPUs operate using binary signals, so they wouldn't ever have 53 bits. FYI, the only CPUs I've seen with smaller physical than virtual address space are Intel CPUs (48-bit physical, 64-bit virtual). Every x64 AMD chip I've used has 64-bit physical space.

Re:Most programs don't need a 64-bit address space

[Vegemeister]

Unless your data structures have pointers in them.

Trees, linked lists, pretty much every object-oriented language ever...

Who cares why it needs it?

[Sycraft-fu]

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:Who cares why it needs it?

[Anonymous Coward]

I'm not sure what issue people are having but on my system with a run of the mill 1 TB harddrive running Ubuntu 11.10 with btrfs on the root partition, I have had no discernable performance difference between ext4 and btrfs other than the expected slight performance hits that you get with this type of file system and I also have seen on Solaris with ZFS. Also bear in mind that btrfs is still in an experimental state so it is quite likely that it will be improved before it is officially released.

Re:Who cares why it needs it?

[Anonymous Coward]

No. fsync() and fdatasync() have significant costs and should not be abused. You can ruin flash with these APIs. Performance has always been a problem with non-direct attached storage (NFS et. al) Sync calls are difficult to accommodate when real time activity is occurring (media playback.)

A web browser should not need to make lots of sync calls. There is no expectation of precise ACID persistence of a web browser. Even when such expectations exist the use of sync calls needs to be minimized.

Should btrfs perform sync calls efficiently? Yes. Should Firefox be corrected to stop excessive use of sync calls? Yes, so that when sync is a problem, Firefox is not.

Re:Who cares why it needs it?

[Stewie241]

I both agree and disagree. Obviously if you are writing low level systems you want to make them as efficient as possible. One can't forget though that there are sometimes inherent limits that an application should respect. It isn't unreasonable, for example, to suggest that an application shouldn't try to use an SD card as its display buffer. Sometimes there are good reasons to tell an app "you can't do that".

Re:Who cares why it needs it?

[hcs_$reboot]

Yes, "It is something the FS should handle", but if the OS itself does not sync all the time, there is a reason. This is the applications responsibility to use and not abuse the sync feature. So the question is relevant, why would Firefox need to sync all the time?? What kind of critical data has to be written to the disk and not kept only in buffers in case of a crash? No, sounds like more a sync abuse imo.

Re:Who cares why it needs it?

[batkiwi]

What options does the FS have though?

The app is calling sync, which is used to flush disk buffers and ensure a change is physically written to disk. btrfs does this safely, with barriers, as it should.

Should it simply ignore repeated sync() calls and NOOP? If not, what should it do?

If I write a program that tries to allocate 20GB of ram on startup and never uses it, then complain that "linux" is making this huge swap file and making my app slow, should they change the malloc/etc APIs to cater for my using them wrong?

Re:Who cares why it needs it?

[L4t3r4lu5]

So "the hardware can handle it" is an excuse for writing shitty, poorly optimised, lazy and bloated code? Were you on the Windows ME / Vista dev team, buy any chance? If anything fixing the badly coded program will free up resources other applications could make use of, especially if you happen to run both Firefox and $Program WhichCan'tBeChanged.

Yes, I live in an ideal world. Then again, Firefox is on version 12 now. I know Chrome made is "cool" to make every patch a major version change, but there's still no excuse for sloppy code. This isn't "for profit" with penalties for missing deadlines; They can afford to fix this kind of stuff.

I do agree, however, that low level systems should be able to cope with badly written apps. If they didn't, how would anybody be able to release on time?

Re:Who cares why it needs it?

[jbolden]

In real life their are trade offs in design. Things that were cheap before, on different systems can become expensive. That's one of the primary issues with porting. Nothing unique to Linux there.

Re:Who cares why it needs it?

[Anonymous Coward]

It doesn't tell the app "you can't do that"; it tells the app "ok, you asked for this, you moron." Firefox was written to be slow and the filesystem accommodates it. What's happening is the user asks Firefox to be faster and the app tells the user, "You can't do that."

Re:Who cares why it needs it?

[Anonymous Coward]

so your position is that if 1 program misuses an interface and
relies on a particular fs (ext4) that doesn't do a good job of
keeping the fs crash-proof anyway, and thus can go fast.
(it's easy to go fast with no constraints!), then this 1 bad
program can put all subsequent fs writers in a box, and they
must support this misuse? that makes no sense.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

Why is the parent modded down? He is excellent!

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

No it isnt, it's a retarded pointless waste of time troll. Sure it would have been decent ten years ago, but now that sort of lame crap shouldnt even be considered trolling. That sort of garbage should simply result in an IP ban.

priorities

[PopeRatzo]

How can you all calmly discuss a new version of Linux when one of the towering figures of modern music has just passed away?

Show a little respect, you pig-ignorant philistines.

Goodnight, sweet prince/and flights of angels sing thee to thy rest,

Now everyone, right now, go listen to "Holiday" or "Spicks and Specks" or "Massachusetts". Leave everything post-'74 alone. The album "Bee Gees First" is a classic of the drawing-room psychedelic era, and holds up very well to "Sgt Peppers" or any of the Nuggets. I love idiosyncratic voices and Robin Gibbs had one of the most.

Re:priorities

[Anonymous Coward]

How can you calmly discuss his death when thousands are dying in Africa in horrible ways every single day? You're not grieving and having moments of silence every two seconds! Fucking disrespectful sociopath!

Re:priorities

[Anonymous Coward]

Those people in africa chose to keep living in a shithole. They are superstitious backwards savages who are too stupid to move to where there is food. But hey who cares that have XO laptops running linux!

Re:priorities

[TheLink]

And what are you doing here reading Slashdot?

When I go to a funeral, I go there to visit the living. Not the dead. If you really cared that much about the person you'd visit or communicate with him while he was alive. Otherwise what sort of caring is that?

Re:priorities

[PopeRatzo]

How can you calmly discuss his death when thousands are dying in Africa in horrible ways every single day?

How many hit records do they have?

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

And you fell for it by replying. He doesn't give two shits what you think about it, he is just reading this thread and laughing at you for being unable to control your emotions.

Way to go, dumbass.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[datavirtue]

I'm going with dumb uninteresting garbage as well.

Why is battery life an issue?

[Anonymous Coward]

Are you telling me that linux audio is so bad it can have a detrimental effect on battery life? How many linux users run laptops straight from the battery? I've never seen anyone using a laptop thats not plugged in somewhere.

kernel 3.2 was released only 5 months ago

[Anonymous Coward]

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:kernel 3.2 was released only 5 months ago

[unixisc]

I'd say too conservative, if they were only updating the third digit every few months. Just do it the OpenBSD way - make every update rev incremented by 0.1, so that #.0 versions are just as stable as every other, and not bug ridden.

Re:kernel 3.2 was released only 5 months ago

[Anonymous Coward]

The current model is fine.

Re:kernel 3.2 was released only 5 months ago

[shaitand]

"I'd say too conservative, if they were only updating the third digit every few months."

I beg to differ. This is the kernel not some userland app or even a daemon. Stable releases are supposed to be reliable enough to trust with billions of dollars in data flow and human life support systems on the day of release.

Re:kernel 3.2 was released only 5 months ago

[Anonymous Coward]

No they are not Linus himself even said the current model relies on the distro producers to deal with stability. If you need to trust something involving billions of $ - use 2.6.32.x (Or whatever newer version replaced it).

Re:kernel 3.2 was released only 5 months ago

[amorsen]

I beg to differ. This is the kernel not some userland app or even a daemon. Stable releases are supposed to be reliable enough to trust with billions of dollars in data flow and human life support systems on the day of release.

In Linux, that level of QA has been moved to the distributors. The only QA done on the official release is that volunteers have tried the release candidates. Some volunteers run compile/test farms, at least sometimes.

People who run life critical systems can generally afford to pay for the kind of testing they need. It is certainly difficult to find volunteers willing to do it.

Re:kernel 3.2 was released only 5 months ago

[unixisc]

Actually, unlike in the case of Windows, where SP2 of Vista wouldn't be the same as Windows 7, or where FreeBSD 8.3 is not the same as FreeBSD 9, Linux did a jump from 2.6.32 straight to 3.0. So it's not like 3.0 was a brand new, untested OS - it's as mature as 2.6 and prior, and only has some newer architecture support, and so on.

Re:kernel 3.2 was released only 5 months ago

[Anonymous Coward]

There have released a new version every few months since 2.6.0. The only new thing is Linus updated the version to 3.0 last year and decided that he might as well change to incrementing the second digit rather than the third. What does it matter anyway, unlike Firefox there isn't usually reason for a user to know which kernel version they are running.

Re:kernel 3.2 was released only 5 months ago

[petermgreen]

Versioning schemes should suit the software being versioned.

Linux, used to use a three part versionin number. The first part was a 2 that basically never changed. The second part indicated which series it was (odd numbered were development series even numbered were stable series) The third part indicated releases within a series.

AIUI that worked for a while but during the 2.4/2.5 era it became clear it was no longer working well. The linux kernel different features were maturing at different times and distro kernels were based on 2.4 but redhat kernels at least shipped with a massive number of backported features/fixes such that they were very different from stock 2.4.

So with 2.6 linux decided to add features in when the individual feature was considered ready and no 2.7 series was started. Each 2.6 kernel was not too different from the last but 2.6.0 and 2.6.39 were more different than 2.4.0 and 2.6.0

At some point during the 2.6 a fourth part (only given when nonzero) was added to the version number for bugfix releases.

So linux ended up using a four part versioning scheme where the first two parts were basically fixed. Now they have moved to a three part scheme where the first part is basically fixed. That seems like a reasonable rationalising of the numbering scheme to me.

Re:kernel 3.2 was released only 5 months ago

[Kjella]

They've been on a dot release every 3 months for many years now. But since they were never going to get off the 2.6 series they renamed 2.6.40 to 3.0, moving everything up one level so 2.6.41 => 3.1, 2.6.42 => 3.2 etc. You can call this one 2.6.44 if it makes you more comfortable, it's the same thing.

Re:kernel 3.2 was released only 5 months ago

[Microlith]

Linux did a jump from 2.6.32 straight to 3.0

Rather, it did a jump from 2.6.39 to 3.0. </pedantic>

Re:kernel 3.2 was released only 5 months ago

[shaitand]

I was exaggerating a bit. But people are still expecting a stable release number to mean the system is stable and has been in the beta unstable stage for quite a while getting beaten up by the bold and bug fixes applied. It's the kernel, the stable releases have always been solid and people trust that they always will be.

My point remains. The release cycle is about as fast as it can be and still live up to that expectation.

32 bit ABI?

[unixisc]

It's true that most programs won't need 64-bit address space - right now - but that's only as long as their memory requirements are within 2GB. If Linux itself is 64-bit, then is there any compelling reason that the ABIs were made 32-bit? In fact, what exactly are the x86 targets for Linux - is it both 32-bit and 64-bit PCs? If that's the case, wouldn't there exist 2 versions of Linux in the tree, and wouldn't it make sense for the 32-bit Linux to have a 32-bit ABI, and the 64-bit Linux to have a 64-bit ABI?

Having said that, I welcome Linux adding an ABI to the kernel, and hope that that forms the basis of device drivers going forward, so that drivers can be work seamlessly from one Linux version to another going forward, even if it hasn't so far.

Re:32 bit ABI?

[EvanED]

It's true that most programs won't need 64-bit address space - right now - but that's only as long as their memory requirements are within 2GB.

And a lot of programs this is true, and will "always" be true. Will Emacs ever need more than 2GB for most people?

(And actually it's 4GB on Linux, or at least close to it.)

If that's the case, wouldn't there exist 2 versions of Linux in the tree

It's more like 99% of the code is shared, and changes depending on how you compile it.

wouldn't it make sense for the 32-bit Linux to have a 32-bit ABI, and the 64-bit Linux to have a 64-bit ABI?

That's how it has been, and those configurations will, of course, continue to be supported (in addition to supporting 32-bit apps on 64-bit Linux). They've just added the new x32 option.

Re:32 bit ABI?

[unixisc]

I thought that Linux didn't have an ABI - at least not one for device drivers

Re:32 bit ABI?

[shutdown -p now]

Linux kernel does not have a standard ABI, in a sense that the way modules communicate with the kernel and each other is not fixed on binary level. Linux as an OS most certainly does have a standard ABI - how else would you be able to take a binary that was compiled 10 years ago (say, a proprietary game), and run it today?

ABI can also mean a more lower-level and generalized stuff - things like function calling convention or how the stack is arranged.

In this case, it's both - it's an generalized ABI for 64-bit code that wants to deal with 32-bit pointers, and it's the OS that exposes its API via that ABI.

Re:32 bit ABI?

[Anonymous Coward]

True story: Linux copied its x86 userspace ABI from here:
http://www.sco.com/developers/devspecs/abi386-4.pdf

Now pay your $699 license you cocksmoking teabaggers.

Re:32 bit ABI?

[Blaskowicz]

Linux kernel does not have a standard ABI, in a sense that the way modules communicate with the kernel and each other is not fixed on binary level. Linux as an OS most certainly does have a standard ABI - how else would you be able to take a binary that was compiled 10 years ago (say, a proprietary game), and run it today?

I would love to be able to do that, but you can't anyway. every library under the hood will have changed several times over and you won't be able to run anything except a text adventure or some card game in raw X11 maybe. also if the source code is available, it doesn't compile. I could never play tty quake :P but maybe you can use a 10 year old distro in a VM.

Re:32 bit ABI?

[shutdown -p now]

I would love to be able to do that, but you can't anyway. every library under the hood will have changed several times over and you won't be able to run anything except a text adventure or some card game in raw X11 maybe.

Last I checked, games like Unreal Tournament (the original one, as well as UT2004) and Majesty were all running quite well on Linux.

Portability

[unixisc]

From what I understand, Microsoft did write portions of NT in x86 assembly in the old days to make it not crawl, and that was one of the things that caused less portability b/w the different NTs. But these days, w/ CPU power being what it is, they don't have to, and neither does Linux. In fact, if I understand right, from Vista onwards, they've done everything in C/C++ only, and not bothered about assembly. That's also what makes Windows 8 so portable to ARM.

Re:Portability

[tqk]

From what I understand, Microsoft did write portions of NT in x86 assembly in the old days to make it not crawl, and that was one of the things that caused less portability b/w the different NTs.

Who fsckin' cares? Zzzzzzz ... Boring.

Re:Portability

[Anonymous Coward]

Except in the old days Microsoft had a version of NT for DEC Alphas.. so I doubt too much was in x86 Assembly as all that code would have to be completely re-written (well not just re-written in the sense of modifying C code for the new platform, but the whole dang thing).

I can't remember if they had any other variants than the Alpha versions though.. it's been too long :)

Re:Portability

[Sulphur]

Except in the old days Microsoft had a version of NT for DEC Alphas.. so I doubt too much was in x86 Assembly as all that code would have to be completely re-written (well not just re-written in the sense of modifying C code for the new platform, but the whole dang thing).

I can't remember if they had any other variants than the Alpha versions though.. it's been too long :)

There were five variants as of NT 4.0 : x86, Alpha, Mips, Sparc, and (I think) PPC.

DEC Alpha was usually served up with ISA slots, and it could execute x86 code to use those.

Re:Portability

[unixisc]

Sparc was never there, although Intergraph mulled over the idea for a bit before settling for Wintel. PPC was there very briefly. The only RISC platforms that lasted a while was MIPS and Alpha. OTOH, NT was developed on both an i860 as well as a DECStation 3000 (using MIPS) but never actually supported either of those platforms.

Also, the first DEC Alpha PCs had EISA slots, not ISA, while the OVMS workstations used TurboChannel. Later, w/ the AlphaStations and AlphaServers, DEC switched completely to PCI. As far as the Alpha went, they had something called a Privileged Architecture Layer (PAL) which was the the layer in the OS that interacted w/ the CPU. It was there in all 3 - NT, OVMS and Unix (a.k.a. OSF/1 a.k.a. Digital Unix a.k.a. Tru64). I'm guessing that the AXP versions of Linux and BSD have that as well.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[dankasak]

Usually trolls are funny, witty, and somewhat related to reality. Usually.

Linux 3.4 Released...

[Anonymous Coward]

And it's still total fucking garbage.

Re:Linux 3.4 Released...

[Anonymous Coward]

What's so bad about it? Care to elaborate?

You are the garbage.

Re:Linux 3.4 Released...

[Anonymous Coward]

[citation needed]

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[G3ckoG33k]

No it isnt, it's a retarded pointless waste of time troll.

Hey! :)

Touché?

GNU?

[Anonymous Coward]

Why the heck a GNU icon and not a penguin? GNU is not Linux, and this is about the kernel not an OS.

Re:GNU?

[Anonymous Coward]

[quote]Why is the GNU logo the one that marks this story, when it's specifically about the Linux kernel, and not GNU userland? Among the keywords, GNU shouldn't even be there for this story, and the logo for this story should have just been the penguin logo.[/quote]

Penguin logo? Linux doesn't have a logo. Tux ('the penguin' has a name, you know) is the mascot, not logo.

Re:GNU?

[unixisc]

Mascot, logo... my point remains - Tux should have been the pic to show above, not the GNU animal.

Re:GNU?

[PwnzerDragoon]

the GNU animal

You mean, a gnu?

Re:GNU?

[unixisc]

I always knew of it as a Wildebeest

Re:GNU?

[SteveFoerster]

A wild e-beast?

Re:GNU?

[unixisc]

No, that would be rms

Re:GNU?

[dbIII]

I think it's either a deliberate troll, some loser that really thinks RMS has written a line of linux instead of his own projects, or a very embarrassing mistake.

Re:GNU?

[DV]

Mod the above up (who worded that in a nicer way than I would).
And put the penguin back please !!! This has nothing to do with the FSF,
"give back to Caesar ..."

Re:GNU?

[Anonymous Coward]

GNL!

Re:GNU?

[Anonymous Coward]

Actually, some of the Emacs chained buffer code (written by RMS) was used in early versions of the Linux kernel. I'm sure it's long since been replaced, though.

Re:GNU?

[spaike]

Maybe people think that GNU and Linux matches a lot so that they sometimes can use the logo of GNU to stand for Linux.Maybe.

Re:GNU?

[spaike]

Yeah...You are right

Re:GNU?

[icebraining]

Yes, the GNU GPL licensed kernel doesn't have anything to do with GNU.

Re:GNU?

[unixisc]

Yeah, but the license notwithstanding, Linux has its own identity independent of GNU. RMS definitely thinks so, or else, he'd not be insisting that Linux be called GNU/Linux at every possible opportunity.

Re:GNU?

[Anonymous Coward]

GNU's Not UNIX, not Linux.

Re:GNU?

[timothy]

Actually, this is a glitch / weakness in the backend system.

"Linux" is actually the primary topic that it's marked with, but some of our topics and section names interact with each other in ways that are ... let's call it "interesting." It's a bit frustrating sometimes, and I'm sorry for the glitch.

timothy

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[tqk]

I've always used Windowz and I consider myself an exceptional Visual Basic programmer ...

Ick.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[tqk]

As much as Linux is doing rather well despite the plethora of different versions and security risk from the open code base ...

You're an idiot. Those are features, dummy. Educate yourself. You're seriously lacking $clue.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[tqk]

Nice troll.

You need to raise your standards. That was pathetic.

GNU?

[unixisc]

Why is the GNU logo the one that marks this story, when it's specifically about the Linux kernel, and not GNU userland? Among the keywords, GNU shouldn't even be there for this story, and the logo for this story should have just been the penguin logo.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

Usually trolls are funny, witty, and somewhat related to reality. Usually.

I thought it was supposed to be satire and less funny. This list seems like things a novice or normal everyday user would think. Just reading the summary I thought that the list seems useful and good upgrades, but the average user wouldn't give two shits about it. You think the average user will say "Shit! Linux now has X86 autoprobing! Goodbye Windows!" No way in hell. This post is satire. Basically, a list this techno-specific is for CS geeks not for casual users or even everyday enthusiasts who like computers and maybe even know a decent amount about them (but don't know what things like autoprobing or cryptographic hashes are). The satire here is that this person knows *some* about computers but is still pointing out the basic things an average user would ask.

Every response, so far, is a perfect example of the problem. Why does RedHat have so many flavors of Linux? I know that you'll say that's not correct, but the point here is that the branding of Linux doesn't make that clear. And the answers, so far, have taken the tact that the question was stupid instead of saying "damn, we've given a list of great CS features but the average user is still wondering why RedHat has so many flavors of Linux?" The responses have ignored the fact that most people don't understand that Linux is a kernel and not an OS proper. That's the satire. The basic questions don't get answered in lieu of "wow what a great CS feature you should just know it" type answers.

And, no, I didn't write the original. Just when I read it and the responses I immediately thought satire. Now, perhaps the OP will say he was trying to be funny. Well, then it was a terrible attempt because it's not. But great satire.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

Except the courts ruled that SCO owns nothing (SCO v Novell), and thus SCO will lose SCO vs IBM and RedHat v SCO because they no longer have any legs to stand on.

Yes, that was the joke.

They will NEVER catch up to Windows!

[Anonymous Coward]

I swear it was 12 years ago Windows had reached version 2000!!! Who knows where they are now! Give it up, Lunix.

fsync?

[Anonymous Coward]

Has the newer btrfs finally fixed the sync problems? Hours long dist-upgrade of Ubuntu is NOT fun.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

You can talk

Oct, 1991, comp.os.minix

[Taco Cowboy]

I still remember that message, on Oct 1991, from a guy by the name of Linus Benedict Torvalds on comp.os.minix

"Do you pine for the nice days of minix-1.1, when men were men and wrote
their own device drivers? Are you without a nice project and just dying
to cut your teeth on a OS you can try to modify for your needs? Are you
finding it frustrating when everything works on minix? No more all-
nighters to get a nifty program working? Then this post might be just
for you :-) "

Re:Oct, 1991, comp.os.minix

[mozumder]

Kids in college these days weren't even alive when the original Linux was announced.

MIND. BLOWN.

Re:Oct, 1991, comp.os.minix

[jo_ham]

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:Oct, 1991, comp.os.minix

[tqk]

Nobody does !@#$ like that these days. Why is that?

Because miracles don't happen very often. Thanks Linus.

Re:Oct, 1991, comp.os.minix

[tqk]

MIND. BLOWN.

ACK. And is it any less fun than it was when you discovered it?

NO. :-)

ext4 can run without journal

[Anonymous Coward]

I have an old (2004-era) laptop that I still use for a testbed. It's a 1GHz Athlon-M with 1GB of RAM. I formatted it asext2 to save some CPU cycles, so yes, the old ways can come in handy.

What do you need ext2 for? Practically you can use ext4 for all use cases that call for ext2. Try formatting the drive with mke2fs -t ext4 -O ^has_journal. (Caveat: Google for the exact command.) The ^ in ^has_journal means "no" journal.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[ch0knuti]

I know this is a funny troll but you are right about the games. The only reason I still use windows as my primary OS is that lack of big titles on Linux.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[oiron]

If the measure of a troll is how seriously people take it, GP's doing very well...

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[VMaN]

It took about 4 reads before your post didn't say "titties".

What does security have to do with death ?

[siri_kan]

Yama is the Hindu god of death. I see a BSoD joke here somewhere :)

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[yahwotqa]

This troll is still relevant, since it provoked kneejerk replies from people taking it seriously and trying to refute its arguments, even though it is painfully obvious it's just a troll. Good work, thanks for the laughs. :)

SCO

[unixisc]

Honestly, at this stage, UnXiS should stop pretending that any of its SCO Unixes - OSE, ODT, UnixWare, Monterrey, et al have any value, and just open them up under GPLv3.

Power management

[Anonymous Coward]

Hopefully they fix suspend and hibernation (doesn't work on my core2). Goes into PM just fine, just won't ever come out.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[kikito]

"Linux has some neat features, but there's a lot of fear, uncertainty, and doubt in the community about its legal future."

Gee. How much do you make by CTRL-c CTRL-v ing Microsoft's propaganda? At least take the time to change the text a little bit.

http://coretan-fauzi.blogspot.com

[Anonymous Coward]

nice posting..

go go LINUX..

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[amiga3D]

Steve....is that you Steve Ballmer?

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

What is it with McBride and his companies having shitty websites. The SCO site had long looked like it was designed by time travelers from the late 90s, and his new company Me Inc. has a site so amateurish one would assume it's some kind in mom's basement, busy churning out fart apps for smartphones. As well as broken images, they can't even scale images so they don't appear freakish. It's full of vague sounding claims and figures pointing out who the mobile market is booming.

http://www.meinc.biz/MeIncDepot/consumers.aspx

I look forward to SCO's eventual victory and the glorious reinstatement of McBride as CEO. A man of McBride's talents would surely not be pissing around with this pointless little company if he were not planning something. McBride, pull yourself up by the magical underpants and get back in the fight!

Re:__beest

[TaoPhoenix]

If Apple wants to get into farming, they can make a wild iBeest!

What they "need" is irrelevant

[Chemisor]

One huge benefit of using x86_64 for everything is that it is now the only desktop platform you need to support. Mobile apps are on ARM, but desktops are all x86_64. Having a common binary format that works on every machine saves a lot of work for developers and should allow Linux finally get some good commercial software.

Using x32 is simply not worthwhile. Maybe there are a few programs out there that will benefit, but I have not seen a single one mentioned or any benchmarks listed. People just assume that using larger pointers will make a program slower, even though today's programs are so bloated, any increase in size would be an insignificant drop in an ocean. Put up benchmarks, or use x86_64!

Pulseaudio 2.0 has improved jack sensing

[Sits]

The recently released (11th May 2011) Pulseaudio 2.0 lists improved jack detection as one of its features so you will probably be waiting longer for a fix to show up in a non-rolling distro...

fsync() is necessary

[Chirs]

If you're trying to write portable code, fsync() is absolutely necessary. If you don't fsync(), there is no way to enforce that the data *ever* gets written to the disk platter--it could be sitting in a cache somewhere.

Sure, most implementations will flush it out to disk in a reasonable amount of time, but that behaviour isn't guaranteed anywhere.

The reason firefox calls fsync() a lot is so that if you have a power outage on a desktop machine you can boot back up and it'll open up with the same set of tabs you had at the time of the outage.

Re:fsync() is necessary

[Compaqt]

True.

Except for the part about Firefox. It never boots back up with the previous tabs. Instead, it's always "Well, this is embarrassing", and it's an error message excuse about why it can't open the previous tabs.

Never happens with Chrome. This is a brand new Ubuntu Precise installation.

Re:fsync() is necessary

[olau]

Sure, most implementations will flush it out to disk in a reasonable amount of time, but that behaviour isn't guaranteed anywhere.

I think I know what you mean, but really, on what systems do writing data to a file not cause it to end up on the disk at same point? That's sort of the point of writing it to the file and having disks in the first place, isn't it?

As I understand it, the problem is that the POSIX API doesn't really contain a fine-grained way of indicating what should happen to the data, so essentially you only have the big hammer known as fsync.

Re:fsync() is necessary

[Rich0]

If you're trying to write portable code, fsync() is absolutely necessary. If you don't fsync(), there is no way to enforce that the data *ever* gets written to the disk platter--it could be sitting in a cache somewhere.

And why should a typical application care whether the data ever ends up on disk? That is an implementation-level detail. If the underlying OS doesn't ever actually sync the cache to disk then it had better have some strategy for ensuring the cache is never lost, and maybe it actually has such a strategy, and therefore the syncs just ruin performance...

I'm a big believer in letting applications do the application stuff, and letting the OS figure out when it is best to write something to disk. That gives both the best performance, and the best overall data security as well. Maybe while firefox was busying tying up the disk something more important was stuck in the cache when the power failed?

Now if somebody can get that across to the MythTV team maybe I can stop patching it every time I build it... My system is a bit faster now, but for the longest time I'd LOSE video because mythtv insisted on fsyncing it so often that the disk throughput suffered and frames actually got dropped (because all kinds of other stuff just accumulated in the cache while the heads were busying seeking just to write a few hundred kb until the OS just had to flush it all and then the fsyncs blocked). And why even fsync a DVR at all? If the power fails, then while the system reboots (and the cable box I have no control over) I'm going to lose several minutes of recording time, so do I really care about the three seconds of video flushed between each of the 47 bazillion calls to fsync?

are you kidding?

[Chirs]

Currently the biggest cpu caches are something like 32MB. On-die memory is *expensive*, so 8GB will take a while.

Re:are you kidding?

[unixisc]

On-die memory is expensive. However, if they keep adding extra cores and do somethng like was done w/ Pentium Pro, they'd have the option of putting discrete memory there, which would enable them to put cheaper and larger amounts of memory. If the CPU uses a unified meory architecture, then a lot more memory could be used. I do agree, though, that it will be a while before it's anything near 4GB.

linux has portions in assembly

[Chirs]

While most of the kernel is written in C, there are portions of each architecture that are written in assembly. Generally it's the very low-level stuff dealing with system startup, exception vectors, etc. It's also used in creating the low level synchronization primitives (locks, barriers, etc.) that are used by the C code to ensure that access to data is synchronized by the various parts of the system. Lastly, it's used in certain performance-sensitive code.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[tqk]

Yes I can.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[tqk]

If the measure of a troll is how seriously people take it, GP's doing very well...

"First, they fight you, ..." :-)

Linux has become like MS Windows was

[Anonymous Coward]

I have been using Linux since 1.13.XX. I started with it because MS Windows forced me into it with their lax security and it's proprietary regime.

But I'm telling you what no one wants to say. Linux, using a GUI is as bad as Windows 3.0 ever was. The software for it has become bloated and as for saying you have a choice, it is now choose between bloated, unfriendly, all desktop managers look the same (unless you have the ka-ho-nas to rum WM/ with very limited acceptability) and why in the world are there so many Debian off-shoots, that are all the same in that they fall short of something new, usable in the real world, and throw in the trashcan the current KDE/Gnome crap?

I am just so disappointed with the state of Linux and have actually found MS Windows98 (can you believe it) to be a better choice.

So there is a new Linux? I really don't care. Do you?

Re:Linux has become like MS Windows was

[spike hay]

Just use LXDE or XFCE with Arch or something, mang.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Rainbowdash]

I re-read it five times after reading your reply. I wanted to see titties :(

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[DaVince21]

Why should he be banned for making a joke? Should you be banned for not laughing at it, then?

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[oiron]

And then they send you goatse, if Slashdot's any indication...

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

Sorry, but there's only one version of redHat, and that's RedHat Linux. the other names you mention, are completely different versions of Linux, and have nothing to do with eachother nor redHat apart from using the same(ish) kernel (Same as in major variable being the version number)

Anyone can view the sourcecode of Linux. That's the whole point of "OPEN source"

RedHat doesn't make Linux. Linus Torvalds makes Linux, He decides what goes into Linux and what doesn't, officially.

The Command Line should never be killed. It's part of the reason why Linux is so good, because people who wants to KNOW their computer and their OS, can get down and dirty with the commandline. Besides, BASH isn't a dirty $5 hooker, BASH is a $100.000 glamour escort.

Of course Linux needs games. "We" have been saying that for years. But that's not RedHats' fault, that's the producers of the games' fault (Blizzard, EA, Atari, etc) And we don't need microcrap office. We've got LibreOffice. Does the job just fine.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[tqk]

If the measure of a troll is how seriously people take it, GP's doing very well...

"First, they fight you, ..." :-)

And then they send you goatse, if Slashdot's any indication...

Beats 4chan. /.'s an aquired taste. There's no requirement to take any of it seriously. Where else can you find this many nutbars all in the same place? Computer !@#$, then philosophy, then history, then Aussies (or Russians or Chinese or Latvians, ...), then particle physics, then DHS/ICE/TSA crap, then MafiAA, ... My worst nightmares aren't as entertaining as you people are (and I have great nightmares :-).

yes but

[Anonymous Coward]

yes but it still doesn't offer anything to speed up productivity....

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Stuarticus]

Ah, a proper troll. It's been so long since I saw one I have tears in my eyes beholding the beauty of it. They're nearly extinct you know, rarely see them in the wild. I personally think this one should be entered into a breeding program, look at it's beautiful plumage!

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

Please read more on Linux. You are one of the newbies who imagines that Red Hat IS Linux. It is only one distro of many. They do not control Debian or Ubuntu nor Mandriva nor much of anything but Redhat.

Also, Bash is not DOS. And, Linux experts use the command line to great advantage, though it is not mandatory for newbies.

You can run Office on Linux, using WINE or Crossover. Ditto for Internet Explorer. Not sure why anyone would want to run IE, but if you want, you can do it.

There is so much wrong with your posting, I must wonder if it is satirical. If you are serious you need to learn a lot fast.

Re:How RedHat's Linux Can Defeat Micr$oft's Windoz

[Anonymous Coward]

So far after years of litigation, those statements about Red Hat stealing much of Linux from SCO have been ruled untrue. I know of no expert who expects SCO to win a crushing defeat any day now. The only FUD in Linux is in your posting, dude.