Slashdot Mirror

Got any evidence for that claim? here are some benchmarks that suggest gaming performance is the same (which is what you would expect since the OS isn't participating much, except through the graphics drivers).

Does AMD support VDPAU these days? Because VA-API support is mighty poor in my experience.

Yes, actually! A month or two ago, AMD released VDPAU support for their open source driver.

Bizarrely, the closed source driver is still XvBA only.

Broke down and bought a card when I had a perfectly find integrated one for my TV box because I can't get VA-API to work with mplayer.

I did actually get VA-API / XvBA working on my AMD system, but it could only do h264 and MPEG2. You could forget xvid, forget advanced GPU deinterlacing, etc. Since it was a weak E-350 box, that left it able to play the highest bitrate bluray rips, but not broadcast TV (MPEG2, 1080i). Replaced it with an Intel Atom / Nvidia ION2 box.

For all you integrated GPU haters and Intel haters... the Intel Linux drivers are straight up excellent. I do not believe there are better Xorg drivers available in Linux, including NVidia. Intel has really been diligently working to make their Xorg drivers work well and they deserve credit. For desktop work, HD video and other non-first person shooter use cases both the hardware and the drivers are a godsend and I thank Intel.

Honest question, is that sarcasm? In particular, the comment about HD video. I've been using MythTV as an open source DVR/media center for many years. When Sandy Bridge came out, it was in theory the perfect HTPC chip:

• - Super-low idle power consumption. With a little attention paid to the components, it's not hard to build a system that uses less than 20 Watts of power when idle. Low power means low heat, and low heat means you don't need a lot of fans, and can use a small, stylish case (that looks more like AV equipment rather than a PC)
• - Hardware decoding of common video formats. So I can watch my Blu-Ray rips without using a lot of CPU power, thus keeping energy usage and heat to a minimum.
• - Still a "real" CPU for when you need to fallback on software decoding. The nVidia ION based systems share the above two criteria; but with a wimpy Atom CPU, if you ever need a real generic computation ability you're out of luck. The SNB chips give you the best of both worlds.

And I watched in envy as, just after the SNB launch people on forums (AVSForum for example) built Windows-based media PCs that were delightfully capable, small, cool, quiet, and used very little power. When was the SNB launch, like two years ago? And I still can't get vaapi working reliably on my HTPC. My situation is just like this "anyone have vaapi working reliably on sandy bridge" post on Phoronix. Basically, it seems to work for a brief amount of time, but it's not deterministic. Maybe five minutes, maybe a couple days, but ultimately, X will hard lock and the screen will go black. Fixed only by logging in remotely and rebooting. So maybe it works for some. But it certainly doesn't "just work" --- if it does in fact work, there is clearly some magical alchemy of proper versions of all the different software components, and possibly the phase of the moon.

This might not affect Portal in any way, but as an interesting sidenote they recently added OpenGL 2 support to the i915 hardware under Linux. :)

The Gimp is software that I am now happily familiar with, and want to improve my knowledge of.

I buy books to learn more about how to do things I want to do with the Gimp.

My hope is that money will become available to pay Gimp developers to more rapidly produce such wonderful things as the GEKL support and make the Gimp more useful to professionals as well as people like me.

OpenCL is coming (not that there's much point, even their Windows version seems slower than just running OpenCL on the CPU from what I've read), and they're catching up with OpenGL version support. What apps do you use on Linux that actually require the newer versions of OpenGL?

Tell that to Poulsbo chipset buyers...

The promised Gallium3D driver was never delivered, even if it apparently was nearly ready to release, and Intel only kicked users around between their desktop and automotive teams, releasing some crappy binary drivers to keep them quiet.

Not according to Wikipedia and Phoronix.

Phoronix says that "the OpenCL/Clover state tracker amounts to a little less than 15,000 lines of new code for Mesa", and that it "is now living on a branch of the mainline Mesa repository."

And Wikipedia says that "Mesa is a software library for 3D computer graphics that provides a generic Khronos-compliant OpenGL implementation for rendering three-dimensional graphics on multiple platforms." And Wikipedia also says that "Gallium3D is a free software library for 3D graphics device drivers."

So unless things have changed, all this OpenCL work done the Clover way is entirely wrapped up in graphics-related code. It may work without a graphics card being present, but it seems that it's entirely dependent on the Mesa graphics code being present..

Or are all those references out of date? I hope so, because otherwise that's a dreadful and totally unnecessary code dependency.

You should revisit those tests. There are new ones where KDE pretty much got its ass kicked by Unity: http://www.phoronix.com/scan.php?page=news_item&px=MTMxNDk

A comment on their discussion page is more insightful and likely to be right:

So it looks like that comment is right: everything's hidden in a binary blob and there is no source code released at all at this time.

You're confused. It wasn't the $199 Wing Wang Wong China Special that had problems working with Linux. It was the Retina Macbook.

http://www.phoronix.com/scan.php?page=article&item=apple_mbpr_linux&num=1

I think you have that backwards. It was the Linux devs. that had the onus of providing compatibility; not Apple.

That is difficult if Apple does not release what is needed to write drivers. In this case though it's an NVidia graphics system that isn't working right, and NVidia will not release the code it uses for Linux developers to write drivers. It has only been lately that NVidia has started releasing it's own binary blobs for Linux. And those don't work well.

Falcon

Ever thought that Apple may only receive Binaries from NVidia as well? And I thought that Linux devs. were GOOD at reverse-engineering. Now you want the datasheet handed to you along with an SDK! ;-)

You're confused. It wasn't the $199 Wing Wang Wong China Special that had problems working with Linux. It was the Retina Macbook.

http://www.phoronix.com/scan.php?page=article&item=apple_mbpr_linux&num=1

I think you have that backwards. It was the Linux devs. that had the onus of providing compatibility; not Apple.

That is difficult if Apple does not release what is needed to write drivers. In this case though it's an NVidia graphics system that isn't working right, and NVidia will not release the code it uses for Linux developers to write drivers. It has only been lately that NVidia has started releasing it's own binary blobs for Linux. And those don't work well.

Falcon

You're confused. It wasn't the $199 Wing Wang Wong China Special that had problems working with Linux. It was the Retina Macbook.

http://www.phoronix.com/scan.php?page=article&item=apple_mbpr_linux&num=1

I think you have that backwards. It was the Linux devs. that had the onus of providing compatibility; not Apple.

http://www.phoronix.com/scan.php?page=article&item=apple_mbpr_linux&num=1

Theres tons of these out there, but from phoronix, comparing an ARM cluster to an Ivy Bridge:

LU.A on the i7-3770K came in at 9514 Mop/s, which was more than ten times faster than the six-board PandaBoard ES cluster.
The average power consumption of the Intel system was 111 Watts.
The efficiency was at 85 Mop/s per Watt compared to the Effimaß cluster at 30.79 Mop/s per Watt.

Or from here, where an ARM manufacturer shows 15x performance / watt compared to the intel part-- until you realize they chose a lower-end, higher consumption part (100w E3 1240, instead of a 100w 1270 or a 45w 1270l or a 20 watt 1220L), and that the E3 was constrained by IO rather than CPU (it was only at 15% usage); and that the benchmark only measured TDP (and that for other, higher end parts like 12GB extra RAM), not actual usage (which would have been substantially lower); and worse, that this is for 2-years' ago product (32nm Sandy Bridge) rather than 22nm Ivy Bridge. Actually do the math and Intel comes out on top, by the ARM vendor's own benchmarks.

I would be utterly amazed if you could show benchmarks with ARM beating Intel in real-world scenarios, performance-per-watt.

Is Wayland somehow being encumbered by a problem they won't have (i.e. closed-source hardware driver support).

Yep.

That's why they're using CyanogenMod as the base with libhybris.
The idea is that they only need working Android drivers. They can get those.

does not have editing capabilities

Quickoffice has editing capabilities. The free product does not, but the paid version, which was free my Symbian phone before purchased by Google, does.

Chromebook with Secure Boot

Chromebook Pixel uses Coreboot with U-Boot payload. It doesn't use UEFI.

install Open/LibreOffice like you can do on any Windows PC

Not being a Windows PC is a feature, just ask an iPad user.

crippled with low storage to encourage you to put valuable files on Google servers

Google doesn't have a monopoly on online storage; preventing you from putting valuable files on something that isn't going to be lifted from your car is a feature.

Why is Slashdot cheering this again?

Maybe you're wrong on a few points.

For myth 1, I don't know how the cpu cores have evolved over time, but the older atoms had a hard time keeping up with the A9's, despite having a larger die and clockspeed advantage: http://www.phoronix.com/scan.php?page=article&item=pandaboard_es&num=1.

Uh, that article shows single-core Atoms generally beating the ARM by 50+%. The ARM did well to match or beat it in a couple of cases, but I don't see any evidence that the Atom 'hard a hard time keeping up' with an ARM CPU that it soundly beat in most of those benchmarks.

For myth 2, the A15 design is significantly faster than A9, which was a big step up from the A8's. In four years we've gone from A8 to A15. It's quite impressive to consider how fast the phones in our pockets have gotten is such a short time, and I think it's a little early to forecast the trend. For myth 3, the Qualcomm Krait design is pretty equal to the A15 reference platform, and it's using a very power-efficient asynchronous design. Big-little isn't necessary, it's a less-elegant design solution that ARM chose. I think by the holiday season, the market will be flooded with A15-based phones. I believe the Apple A6 is also an A15 reference CPU, since they don't have an architectural license like Qualcomm and Marvell.

According to Phoronix, Windows 7 graphics "destroys the Linux and OS X drivers", and "Only in a few workloads was the Windows 7 driver not the distant frontrunner".

IF you use an intel onboard for 3D.

According to them the proprietary system's drivers also originate from Apple and Microsoft. At least the text on the first page hints to that. Another point is: Nobody who is seriously interested in 3D will use the intel chip as graphics processor.

Then there is this increase in performance when you switch from directX to openGL as more stuff moves to GPU. Using openGL and making it easier to port might be a good idea for any gaming company.

I really don't know why they did this test. Ok. You get better subpar 3D on Windows 7, but who cares.

According to Phoronix, Windows 7 graphics "destroys the Linux and OS X drivers", and "Only in a few workloads was the Windows 7 driver not the distant frontrunner".

Why would they need protection from Linux when they're "Looking At Office For Linux In 2014"?

Hey man, I don't go looking for this this shit. It just keeps popping up in my feeds and I go with it because it's fun.

For the same hardware which has not been released, I dunno :)
You should head to phoronix which has comparisons between open and closed drivers.
In my experience, with an obsolete hd2400 that I run with debian wheezy and the experimental fglrx-legacy driver, gamers should opt for the closed source one, while desktop effects, simpler games etc are handled perfectly by the open source drivers. Both closed and open drivers seem not to have problems with kernel updates thanks to dkms, and are stable. Of course free software is easier to deploy-distribute-use in business.

Suck it up shillboy.

Your employer's days are numbered, they'll be irrelevant in a few years. All those legacy apps will be sandboxed on Android machines.

http://www.phoronix.com/scan.php?page=news_item&px=MTI5MjA

Well there was an implementation of Direct3D 11 on Linux but it died due to lack of interest in maintaining it.

They switched back to GNOME.

As the name clearly states, this is a FUSE implementation of exFAT, i.e. userspace. In which case DKMS is as useful as a fork for soup.

So not only we get the news two days after Phoronix [1], but the poster has no idea on what he's talking about.

[1] http://www.phoronix.com/scan.php?page=news_item&px=MTI3OTQ

Even despite a conversion layer, performance improves.

Even despite a conversion layer, performance improves.

He's referring to a point made recently to some kernel-internal DMA interfaces that are marked as GPL only and Nvidia wanted them to be something else so they could use them with their proprietary module.

Alan Cox resisted, and as a result a small performance boost can't be had by proprietary graphics drivers.

http://www.phoronix.com/scan.php?page=news_item&px=MTA0ODE

There are patches for Linux kernel to similar effect in the works and devs claim nice results

As for programmability, which is what actually matters, Mali 400 has no open source driver except some reverse-engineered garbage. The GPU on the Pi does, and it's code from the manufacturer.

No it doesn't, they just made the source of a message passing interface available, i.e. it's just a shim, not an actual driver. See here: http://www.raspberrypi.org/archives/2221 and http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDk

A comment on the 4. : Nouveau can do OpenCL. You may be thinking about CUDA maybe? The situation seems less clear on this one.

I am curious about what you mean by "feature complete 2d and 3d rendering", obviously the main problem with the nouveau driver is that all the features are not available yet. I feel I am missing a point.

No, no it doesn't.

Yes it does!

It gets beaten by the i3 3220

No it doesn't!

Oh waid, you've compared a fusion processor to an i3 rather than the non fusion ones I was talking about.

Firstly, let's try here, for some multithreaded benchmarks:

http://www.phoronix.com/scan.php?page=article&item=amd_fx8350_visherabdver2&num=4

If you look the reports are generally exactly what I said with the addition that the A10 is much flower than the 8350. Generally, the 8350 is between the i5 and i7, occasionally a bit slower than the i5 sometimes much faster than the i7. That's a 100% multithreaded benchmark. It includes things like compiling, rendering, compression, image manipulation, media transcoding and some scientific work. Scientific codes are actually used inside modern games and modern filters in things like photoshop aso you can't dismiss them as "not for normal people".

In fact, the conclusion of that benchmark is that the 8350 is competetive with the 3770k which is much more expensive.

For a nice extreme example look at the CRay benchmark, where the FX8350 runs in under 2/3 of the time of the i7 3770K. There are extremes in the opposite direction, too.

There actually really aren't that many tasks where multithreading makes up the difference,

Apart from all the cases I listed. Running 200 single threaded benchmarks and 10 multithreaded ones doesn't imply single threaded tasks are more common.

And if you want a more mixed benchmark, go here:

http://www.tomshardware.com/reviews/fx-8350-vishera-review,3328-12.html

Where for a lot of tasks, like single threaded media encoding, the AMD processors are about 75% as fast.

And... back to your benchmarks.

So, I looked at the benchmarks, and the results were pretty mixed. Sometimes one processor wins by a large margin, other times the other one does. No graphics intensive or OpenCL benchmarkes are included for fusion versus i3 I note. There would be a no contest win to the fusion for those.

According to Phoronix, the Intel DZ77GA-70K and the ECS Golden Board Z77H2-A2X are fine for Linux. It is implied that almost any motherboard with the Intel Z77 chip set should be OK for linux. They did a longer follow-up review on the ECS Z77H2-A2X Ultimate Golden Edition Extreme with linux.

According to Phoronix, the Intel DZ77GA-70K and the ECS Golden Board Z77H2-A2X are fine for Linux. It is implied that almost any motherboard with the Intel Z77 chip set should be OK for linux. They did a longer follow-up review on the ECS Z77H2-A2X Ultimate Golden Edition Extreme with linux.

Intel don't use their own graphics tech in these Atoms. Instead they license it from ImgTec (PowerVR).

Not for long

They have recently dropped support for anything up to the Radeon HD 4xxx. Which is not that old.

On the other hand, according to various articles on http://www.phoronix.com/ the open source Radeon drivers are making great progress. One drawback is that you may have to tinker with your Linux installation to get all of that:
You will need the very latest source code, which probably means recompiling mesa and maybe the kernel ;-)

I absolutely agree, it is not for the faint of heart or new users. I am sure as soon as the popular distros like Ubuntu, Mint and Arch shift into faster development cycles to keep up with the kernels new pace we will see things get easier for everyone.

I personally use Gentoo on my workstation since I built it and keep it current. Just upgraded my kernel to 3.7.1 with Gentoo patchset last night.

I am no stranger to compiling software and kernels.

They have recently dropped support for anything up to the Radeon HD 4xxx. Which is not that old.

On the other hand, according to various articles on http://www.phoronix.com/ the open source Radeon drivers are making great progress. One drawback is that you may have to tinker with your Linux installation to get all of that:
You will need the very latest source code, which probably means recompiling mesa and maybe the kernel ;-)

Some people are working on that: Helen OS is an effort to get Linux drivers running in a microkernel. They already have the entire Linux OS as a user process there, but breaking it into pieces allows more.

People touching the source code of ANYTHING are rarer than unicorns.

Does that include furry unicorns? They're everywhere!

Seriously, I read code all the time. A good coder will do a lot more reading than writing, which is especially true of C and other non-obvious lower-level programming... OpenBSD code is a great epic read (skip the perl).

The majority of computer end-users are illiterates regarding anything related to computer stuff.

They still benefit from using open source components in various ways.

Even if only 0.1% of users will review the code, in most cases that's enough people to blow the whistle if there's a backdoor, etc. Of course proprietary software can be disassembled / virtualized / memory-dumped / and analyzed in a variety of ways, and I'm sure that most Microsoft software has had more eyeballs on it than most FLOSS software, but with equal popularity open source has the advantage.

Non-devs also benefit from being able to rent a coder from a freelancer site (usually in Outsourcistan, India) to conduct a security audit or make a change for them. Again, modding proprietary software is possible, and in many cases is easier than most people think (and even than its developers would have wanted), but still a bit more ugly and expensive.

With a "time-limited hybrid source" arrangement, you get the best of both worlds. The proprietary developer would hand over the code to a reputable third party, which would build the binaries for distribution while keeping the code safe till its due date. The dev would be able to sell it like any other piece of proprietary software and possibly profit from his innovations while they're fresh, but with the added advantage that the users would eventually get the code. The dev wouldn't be able to hide any surprises (excluding in BLOBs or brilliant feats of obfuscation), and the users would know that they would eventually be unencumbered in making any modifications they wanted.

Perhaps this is how intellectual monopolies should be phased out...

--libman

The Linux kernel is great, it actually has good engineering and design.

I acknowledge that the Linux kernel has many virtues, but I wouldn't go as far as to call it a masterpiece. It must be remembered that most of it is merely a knockoff of numerous ideas that came from proprietary UNIX. True innovation is a very rare thing, and it is far more likely to happen in proprietary software first. Smart people who devote their lives to learning and then improving something full-time usually like to get paid...

This is why we need a more symbiotic relationship between proprietary and free software - and, if Linux has achieved this to some degree, then it has done so while swimming against the current due to GPL! If, instead of Linux, there was an agreement that the top UNIX vendors would release their code as copyFREE say 4 years after each release, this would result in an ecosystem of code-sharing forks the best of which would be considerably better than Linux, with all the effort that has gone to reinventing the wheel (proprietary / copyLEFT / copyFREE) going toward more innovative ends instead.

The problem with GPL is the kind of crap user-mode code that is out there. It seem more like a culture of programmers trying to designs systems. [...]

I agree, and this is exactly why the quantity of the various GPL-licensed "gnome4-scratch-my-back" packages is irrelevant. CopyFREE software just needs to win the "commanding heights" of the new client stack, and it is well on its way thanks to Chromium and HTML5.

Again, this isn't a FreeBSD vs Linux, but a BSD culture vs GPL culture.

I'd prefer to frame the debate as copyLEFT vs copyFREE. FreeBSD (or any BSD) isn't my favorite copyFREE project by far, but it is the most competent source of lower-level system components that we have for now. True innovation is happening elsewhere: HTML5, Node.JS, Redis, PostgreSQL / SQLite, NaCl, Go, Haskell, etc, etc, etc.

--libman

I just don't see the problem with the GPL license.

It is a deeply-rooted disagreement between the more libertarian (i.e. free market capitalist) approach to software philosophy vs the more socialist approach of Richard Stallman. Politics (and, to a lesser degree, other philosophical issues, like design aesthetics) have been crucial to Stallman and other founders of the GNU movement, and the (mostly accidental) popularity of their license has legitimized and empowered their ideas. There are some things we'd agree on, but the differences between our visions can neither be reconciled nor ignored.

The philosophical core behind copyLEFT believes that "money is the root of all evil", that corporations need to be destroyed, and that government force is OK just as long as it serves their desired aims. I believe in individual self-ownership, free markets, voluntary cooperation, and owning the fruits of your labor. My epistemology is grounded in rationalism, empiricism, and logical deduction of a Theory of Natural Rights; theirs is based on existentialism / emotionalism, demagoguery, and the thirst for political power. They believe that government force is legitimate when it suits them (copyLEFT enforcement, "net neutrality", funding of their pet projects, etc) and evil when it doesn't (patents, SOPA, vice prohibitionism, etc); I believe that violations of (individual, negative) Rights are always wrong.

CopyFREE and proprietary software exist in a natural symbiotic relationship. People can innovate and are free to decide how they release their innovations, including in a way that profits them the most, but free market competition eventually drives prices to zero and recognizes openness / source availability / copyFREE-ness as a competitive advantage. You eventually get the best of both worlds - the developer's rent gets paid through the next cycle of innovation, and the source is eventually released. There's no definite need for state-sponsored "intellectual property" monopolies in this process, because development can be funded through explicit contracts, SaaS (which, BTW, is the direction that Microsoft is moving in), hardware bundling (which Apple did from day one), support bundling, education / certification-bundled contractual agreements, an open reputation-based donation system, etc, etc, etc.

CopyLEFT software, on the other hand, exists in a perpetual state of uncertainty and antagonism with everything around it. The Linux kernel has avoided some of this uncertainty by pledging to stay with GPL v2, but many of Linux distros' essential components will follow the latest version, and there's no telling whether (A)GPL v4 or v9 will begin to include quotations from Chairman Mao... Businesses embracing copyLEFT as a PR-friendly add-on to copyright is not what RMS had originally intended, and fear of losing more market share is the only thing that's limiting their push for ever-more-restrictive licenses. They ultimately believe that businesses are evil and should be taxed into non-existence, and government monopolies should fund all software development and control everything - with them in charge.

The BSD license permits people to take free source code and lock it way and not share back [... below ...]. The way I see it, GPL is an immunization for the user community against the jerks who want to take source code and not share back their changes.

Copying is not a crime, and it is wrong do deal with "jerks" (who have not initiated physical aggression) through violence - lest you forgot that the power of GPL enforcement ultimately derives from the guns of state!

The BSD and other

Who's talking about static image? When you minimize/maximize you get tearing around the title bar - in my case that is. Here's a description of the issue from Phoronix: http://www.phoronix.com/scan.php?page=news_item&px=MTIxMTM Hasn't been fixed still.

what the hell's wrong with this place, today???

Phoronix Filesystem Benchmarks 1

Phoronix Filesystem Benchmarks 2

Google search site:phoronix.com ext4 xfs benchmark

And I'd heard, repeatedly, that if you scramble an XFS filesystem, say goodbye forever to your data:
that recovering anything from it in scrambled-state is like brain-surgery on a trauma patient.

Anyways, to the poster whose post I placed this under,
thank you for the tips about PostgreSQL-compatible stuff!

Namaste, eh?

  ( :

what the hell's wrong with this place, today???

Phoronix Filesystem Benchmarks 1

Phoronix Filesystem Benchmarks 2

Google search site:phoronix.com ext4 xfs benchmark

And I'd heard, repeatedly, that if you scramble an XFS filesystem, say goodbye forever to your data:
that recovering anything from it in scrambled-state is like brain-surgery on a trauma patient.

Anyways, to the poster whose post I placed this under,
thank you for the tips about PostgreSQL-compatible stuff!

Namaste, eh?

  ( :

The biggest source for early XFS corruption issues was that at the time the filesystem was introduced, most drives on the market lied about write caching. XFS was the first Linux filesystem that depended on write barriers working properly. If something was declared written but not really on disk, filesystem corruption could easily result after a crash. But when XFS was released in 2001, all the cheap ATA disks in PC hardware lied about writes being complete, Linux didn't know how to work around that, and as such barriers were not reliable on them. SGI didn't realize how big of a problem this was because their own hardware, the IRIX systems XFS was developed for, used better quality drivers where this didn't happen. But take that same filesystem and run it on random PC hardware of the era, and it usually doesn't work.

ext4 will fail in the same way XFS used to, if you run it on old hardware. That bug was only fixed in kernel 2.6.32, with an associated performance loss on software like PostgreSQL that depends on write barriers for its own reliable operation too. Nowadays write barriers on Linux are handled by flushing the drive's cache out, all SATA drives support that cache flushing call, and the filesystems built on barriers work fine.

Many of the other obscure XFS bugs were flushed out when RedHat did QA for RHEL6. In fact, XFS is the only good way to support volumes over 16TB in size, as part of their Scalable File System package, a fairly expensive add-on the RHEL6. All of the largest Linux installs I deal with are on XFS, period.

I wouldn't use XFS on a kernel before RHEL6 / Debian Squeeze though. I know the software side of the write barrier implementation, the cache flushing code, works in the 2.6.32 derived kernels they run. The bug I pointed to as fixed in 2.6.32 was specific to ext4, but there were lots of other fixes to that kernel in this area. I don't trust any of the earlier kernels for ext4 or xfs.

It didn't help that Linux didn't address the DM device bug where write barriers were basically ignored until a couple years ago.

The biggest source for early XFS corruption issues was that at the time the filesystem was introduced, most drives on the market lied about write caching. XFS was the first Linux filesystem that depended on write barriers working properly. If something was declared written but not really on disk, filesystem corruption could easily result after a crash. But when XFS was released in 2001, all the cheap ATA disks in PC hardware lied about writes being complete, Linux didn't know how to work around that, and as such barriers were not reliable on them. SGI didn't realize how big of a problem this was because their own hardware, the IRIX systems XFS was developed for, used better quality drivers where this didn't happen. But take that same filesystem and run it on random PC hardware of the era, and it usually doesn't work.

ext4 will fail in the same way XFS used to, if you run it on old hardware. That bug was only fixed in kernel 2.6.32, with an associated performance loss on software like PostgreSQL that depends on write barriers for its own reliable operation too. Nowadays write barriers on Linux are handled by flushing the drive's cache out, all SATA drives support that cache flushing call, and the filesystems built on barriers work fine.

Many of the other obscure XFS bugs were flushed out when RedHat did QA for RHEL6. In fact, XFS is the only good way to support volumes over 16TB in size, as part of their Scalable File System package, a fairly expensive add-on the RHEL6. All of the largest Linux installs I deal with are on XFS, period.

I wouldn't use XFS on a kernel before RHEL6 / Debian Squeeze though. I know the software side of the write barrier implementation, the cache flushing code, works in the 2.6.32 derived kernels they run. The bug I pointed to as fixed in 2.6.32 was specific to ext4, but there were lots of other fixes to that kernel in this area. I don't trust any of the earlier kernels for ext4 or xfs.

What sound system fragmentation? There's ALSA and there's ... ALSA

Yes, for Ubuntu users, there's only ALSA. But for those of us that require a real low latency sound system to do some work, we need to use the OSSv4 Audio Subsystem. But because this FRAGMENTATION in Linux it's poorly supported, so we have to use OS X or Windows.

And where do you get off thinking PA is some solution to this nightmare? It only makes matters worse. And, It's not just end users that have issues with PulseAudio subsystems. Read about the nightmare the WINE dev's are having with PulseAudio's massive latency:
http://www.phoronix.com/scan.php?page=news_item&px=MTEyODM

According to this old benchmark by Phoronix (which was even linked by Slashdot), the i7 is more power-efficient than the ARM Cortex A9 in PandaBoard. The i7 got 85 Mop/s per Watt, while the ARM managed only 38.

The advantage of low-power processors like ARM's is low power consumption when idle, which admittedly is where most computers (and tablets, phones, etc) spend most of their time.