Skip to main content
Reading the replies to this comment (and the ones around it) in Slashdot, it is somewhat shocking to realize how short sighted  most posters are - considering these are Linux users, which we should assume means something. These people are content to reinstall their OS every six months and couldn't possibly imagine why one wouldn't want to, or why not all software in existence can be in their favorite distro's repository.

The problem is not that these people exist, but that apparently they are the target audience of popular Linux desktop distributions. This worries me. At least with Windows you know that there is a "design committee" somewhere in Redmond, trying to do the right thing; they don't end up doing it, but they at least try to approach it intelligently. What am I saying - apparently they do succeed, and the proof is in the pudding - 98% of the desktop market share.

Recently there were discussions in Slashdot about PulseAudio. The latest attempt to "fix Linux sound". Apparently OSS was not good enough, so it was replaced with Alsa, which wasn't good enough, so Arts, Esound, etc, were created, and now finally PulseAudio to rule them all. In the meantime Windows 2000 (and perhaps even Windows 95 and Win 3.1??) had better sound than Linux today. But I digress.

What really made an impression on me is the admission by Pulse Audio's creator that its mixer controls can't possibly handle all different sound cards, but that at least it was an improvement over the existing Alsa mixer control. To this I say, if you aim low you land low. Let's think for a second. Why isn't this a problem in Windows? How are all possible sound cards handled there?

BTW, here is a hint: it is not only the sound.  Exactly the same limitation exists in Linux printing. While printers might have tons of special functionality (cleaning, adjustments, manual double-sided printing, etc) available in Windows, this is never available from CUPS in Linux.

The answer is, in Windows the manufacturer can ship a custom applet, designed specifically for the capabilities of their hardware, together with the driver. Who knew that instead of trying to handle all possible cases in the OS, it is possible to push the burden to the manufacturers and let them take care of it.

Homework question: why doesn't this obvious solution work in Linux, and why does this mean that Linux is destined forever to fail as a desktop.

Comments

Popular posts from this blog

You Don't Like Google's Go Because You Are Small

When you look at Google's presentations about Go, they are not shy about it. Go is about very smart people at Google solving very BIG problems. They know best. If you don't like Go, then you are small and are solving small problems. If you were big (or smart), you would surely like it. For example, you might naively think that printing the greater of two numbers should be as simple as std::cout << max(b(),c()) That is because you think small. What you really should want is: t1 := b() if t2 := c(); t1 < t2 { t1 = t2 } fmt.Print( t1 ) Isn't it much better? We didn't have to type all those extra semicolons that were killing productivity before. If you don't like it, you are small. If you wanted to extract an attribute of an optional parameter, you may be used to typing something like: a = p ? p->a : 0; or even: a = p && p->a You just make me sad because obviously what you really want is: a = 0 if p != nil { a = p->

Apple2TC: an Apple II Binary to C Decompiler - Part 7, Using The IR

 This is part 7 in a series of posts describing Apple2TC.  The start is in  Part 1 . Part 6 introduced our SSA-based Intermediate Representation. In this part we look at a running IR example and how it is transformed by our decompiler pipeline. Introducing The Example To demonstrate the utility of our IR, we have devised a slightly contrived example that nevertheless illustrates challenges encountered in real code.  The source of the example can be seen here:  https://github.com/tmikov/apple2tc/blob/master/blog/part6/ex.s . We assembled it with a6502: a6502 ex.s ex.b33 and disassembled it: apple2tc ex.b33 --asm > ex.lst Producing the following listing: /*0300*/ TSX /*0301*/ INX /*0302*/ INX /*0303*/ LDY M_0101,X ; $0101 /*0306*/ INY /*0307*/ STY M_90 ; $0090 /*0309*/ LDA M_91 ; $0091 /*030B*/ STA M_92 ; $0092 /*030D*/ L

Apple2TC: an Apple II Binary to C Decompiler - Part 1

This is a series of blog posts to serve as a log documenting my work on Apple2TC - an open source hobby project developed on GitHub:  https://github.com/tmikov/apple2tc . There are various interesting things that come up all the time and I thought it might be useful to record them for posterity. Part 2  describes the different components of the project Part 3 shows how we validate our disassembly by generating a working C representation of it. Part 4 shows the Apple II tricks we had to deal with to get to correct running code. Part 5 describes decompiling and running Robotron 2084 and Snake Byte. Part 6 introduces our SSA-based intermediate representation . Part 7 shows how to transform the IR to discover the original intent of the code.   What is Apple2TC? Apple2TC is an open source project to decompile original Apple II binaries, mostly games, into understandable and working modern C code,  completely automatically  by analyzing the runtime behavior of the code via custom softw