Oh good! I am glad that Ingsoc is finally instituting rewards for goodthink. How else are we going to protect our precious culture from such harmful influences as freedom of expression, creativity, and uncensored foreign broadcasts?
Why the sarcasm? Lossless, DRM free, CD-quality seems a very reasonable thing to ask for. It's what you would get if you bought a CD, after all.
The difference is that, with online distribution, there is no medium: no physical CD needs to be pressed, no case need be manufactured, no cover art printed, the package doesn't have to be distributed, it doesn't have to be stored, and so on. So this ought to be cheaper for the distributor.
As for CD-quality being the least one would expect: in this day and age, with movies being distributed with surround sound and many people having hardware capable of rendering it, yes, CDs are starting to get long in the tooth. Stereo? 44.1 KHz? That is indeed the least you would expect.
As for lossless... Yes, of course. MP3 was all the rage in the 1990s when a gigabyte was a lot of storage. Today, harddisks are easily 1000 times as large. I think we can afford for our music files to be a factor 50 larger. And if you still want lossy compression, you can always do it yourself... and make your own trade-off between quality and size.
All in all, I think the grandparent's asking for lossless CD-quality music is entirely reasonable. The only reason why it might not seem that way is because the incumbent players in the music industry want to fight it every step of the way. Yes, lossless, DRM-free, CD-quality music is probably a pipe dream. But it's not because it's asking too much.
In the 1990s, we had HTML elements to embed arbitrary multimedia elements into webpages. Browsers generally supported those through plugins.
I don't understand all this noise about Theora vs. H.264 support in the browser, nor do I understand why you would want to wrap your video in Flash, adding another dependency on a proprietary technology.
What's wrong with just using and object-element and a well-supported video format?
``This isn't progress, this is a punishment to each and every one of us.''
If we choose to support Windows, that is.
I stopped doing that years ago, because I saw it as a sort of punishment in and of itself. The thing is, ideological arguments aside, I use Debian because it requires very little time for maintenance. Supporting any sort of other operating system besides is going to increase the maintenance burden, and that is particularly true if maintenance requires a lot of manual actions or even physical access (which I have needed only once with Debian - and even that was once too often for my taste).
Nowadays, I just tell people "Sorry, I don't know how to deal with Windows and I have no desire to learn." They turn to somebody who actually likes supporting Windows, and everybody is happy.
On the other hand, while talking about the 1990s and things Linux had first (compared to Windows):
- Linux actually existed before Windows 95 (1991 and 1995, respectively - if you want to include NT, that was 1993 IIRC)
- Thus, features that are shared among early Linux and early Windows (32-bit, long file names, multitasking,...) were actually first in Linux
- Multi-user
- Filesystem with permissions (ok, Windows had "read only"...)
- A useful degree of POSIX-compatibility (OTOH, Windows had useful win16-compatibility - I don't think Linux's was very good)
- Lots of GNU utilities (familiar to those familiar with Unix, and often preferred over their proprietary Unix counterparts)
- Remote acccess (telnet, X11)
- Multiple desktop environments to choose from
- Virtual desktops
- Development tools either included with the system or available for free (or did Windows have that, too?)
- Source code either included or available for free
- Support for multiple machine architectures
I'm sure the list isn't even exhaustive, but it serves to show that Linux having something before Windows is not exactly rare. Of course, there are tons of things that Windows has gotten before Linux... widespread consumer acceptance being one obvious and important item.
While on the subject, I would like to ask what other open formats there are for vector graphics. I'm especially interested in efficient formats (avoiding the overhead of XML) and in formats that do more than just represent images (e.g. that allow animation and/or scripting).
Thanks a lot. It looks like 3D support for any AMD card currently on the market (Radeon HDxxxx) is still a ways off, but I think I can survive the wait.
While on the subject, I would like to ask a question. Obviously, I could do the research myself, but someone probably knows the answer from the top of their heads. So here is the question:
- Is there any current graphics card that sells for under 100 USD, and has open source drivers that allow decent gaming? Preferably passively cooled.
I have a GeForce 6600 (passively cooled) now, which I am happy with in terms of performance. But that's using the closed source driver. With Intel, VIA, and AMD having open source accelerated 3D, is there a video card I can buy now that has the same or better performance, but using open source drivers?
TeX and LaTeX don't crash and don't eat your document. Even in the event that they would somehow become unable to process your document, you can still extract pretty much everything you want from the document with another program, because it's all human-readable.
MS Word does not go berserk on your document as much as it used to, but it still does happen. Even if it doesn't FUBAR your document completely, it still tends to mess up the formatting.
Of all people who I know who asked me if they should write their thesis in Word or in LaTeX, only one has written it in Word (against my advice) and not regretted it. Most took my advice and found out that learning LaTeX actually doesn't take that long, and that they got so many appreciative comments on their documents that they would use LaTeX again. The rest went with Word and lost lots and lots of time, usually towards the end of the project when stress was highest. And that they had to learn LaTeX anyway for the next step in their life, because it's what journals want you to use.
The lesson: if you do use Word, please please please, make backups all the time. That means multiple times a day. But first, think hard about whether not learning LaTeX now is actually going to save you any time at all.
``In my opinion, one of the biggest hurdles keeping Linux our of the domestic desktop market is the developers apparently can't put themselves in the shoes of the average user. In my personal experience they tend to hold the end user in contempt, but I realize that this is a fairly small sample of the community...''
If your point is "a lot of what goes into Linux isn't meant for the average Jane", you have that absolutely right.
However, you are wrong if you generalize from that to "the developers are not end users". The great strength of Linux and a lot of open source software is that many of the developers _are_ end users. They write the software for themselves, and then share their work with the world to use, distribute, improve, or ignore as they wish.
Think about that for a second. "Hold the end user in contempt"? That sounds like a very asocial thing to do. Sharing your work doesn't sound so asocial. Could it be that they are just saying "I made this for me. If you want to use it, fine. If you don't want to use it, also fine. But you don't get to tell me how I should have done my job."
Sure, that's no way to conquer the hearts of the average Janes, but who said that was the goal?
``Like it or not, Windows and OSX have set standards for interface and functional transparency. It may not sit well with developers that they can't micromanage what the OS is doing, but the average user just doesn't give a shit and is unwilling if not incapable of tweaking the OS to accomplish otherwise simple tasks.''
I think you're spot on there.
``It needs to "just work." If you need to use the command line, it's broken for desktop use. If you need to manually edit a file, it's broken for desktop use. If an essential component for some software is not included and must be installed and configured separately, it's broken for desktop use. (That last one is a big, big problem for Linux!)''
The funny thing is this is the exact reason I use Debian, and cringe when I have to use Windows. For me, Debian comes closest to "Just Works" from among all the things I've tried. Windows, for me, is a time sink: a lot of tweaking before I get anywhere near productive on it, and then a lot of time goes into maintenance. Hey, that sounds like the same thing many people have coming from Windows to some Linux distribution.
``For all the faults Microsoft has with their software, at least they did the research and learned how Joe Shmoe uses a computer and designed to the lowest common denominator. That's how they ended up on top.''
Nope. They were on top, and that's how they got to shape user expectations. When Microsoft pushed DOS, DOS was how average Joes used computers. Macintoshes and Amigas and all those were for weirdos.
Now that Microsoft pushes Windows, the command line is for weirdos.
And don't start about how GUIs are so much more intuitive than the command line. I lived through the age when command line interfaces were the norm, and I can tell you that, at the time, everybody knew how to use the keyboard, but only "computer freaks" knew how to use the mouse. Getting to understand how the pointer moved when you moved the mouse (note that they are in different planes!) was hard enough, but that was only the start...next you needed to learn about clicking, double-clicking, right-clicking and control-clicking. Intuitive? Not to the average computer users of that time!
``Windows XP? Put it in and the sound comes out.''
Exactly the same as with any decent desktop Linux distro.
Provided, of course, the system comes with a driver for your sound card. To point out the obvious: Windows XP and your favorite Linux-based OS are no different here.
The difference is that, in your care, Windows XP came with a working driver for your sound card, and your Linux distro didn't. Conversely, one of my brothers has a computer with a SATA controller that Windows XP doesn't include a driver for, but some version of Ubuntu does.
Complaining about your Linux distro of choice not shipping with drivers for every piece of hardware is fine and dandy, but it isn't a shortcoming of Linux. It's a valid reason for not wanting to use it, and it will take time and effort before that reason goes away. But it doesn't mean anything is wrong with Linux, just as the fact that not all houses come with Ethernet sockets doesn't mean that there is anything wrong with Ethernet.
The only thing worse than the article is the summary. "Technical reasons"? My behind.
To the author, and to the rest of the world:
``0. Premise: proprietary software will stay indefinitely. Full stop. You may argue eternally, but complicated software like games, 3D applications, databases, CADs(Computer-aided Design), etc. which cost millions of dollars and years of man-hours to develop will never be open sourced. Software patents are about to stay forever.''
Even if true, so what? This has nothing to do with Linux being ready for the desktop.
``1. No reliable sound system, no reliable unified software audio mixing, many (old or/and proprietary) applications still open audio output exclusively causing major user problems and headache. ''
How do you mean "no reliable sound system"? As for applications FUBARing it, I don't know if that is still true, but even if it is, that is not a problem with Linux so much as a problem with those applications. If you use those applications, your experience may be suboptimal. But you can also choose not to use these applications.
``1.1 Insanely difficult to set up volume levels, audio recording... and in some situations even audio output. ''
Eh? I don't find alsamixer "insanely difficult". Even if you do, there are plenty of others that may suit you better.
``1.2 Highly confusing, not self-explanatory mixer settings.''
I have a lot of settings that I don't understand. But I understand "master" and "PCM", and those are all I ever use. The rest is just stuff I ignore... and that many mixers don't actually display at all. I guess none of it is especially self-explanatory, but a bit of fiddling with the sliders and you will know soon enough. Is this a big issue? Even if so, it's not a technical issues - more a user interface issue.
``1.3 By default many distros do not set volume levels properly (no audio output/no sound recording).''
I don't know if that is true, but I'll take your word for it. It's not a technical issue, though.
``2. X system:''
Ah, everybody's favorite scapegoat.
``2.1 No good stable standardized API for developing GUI applications (like Win32 API). Both GTK and Qt are very unstable and often break backwards compatibility. ''
Nonsense. XLib is a stable API and has backward compatibility until... 1985 or thereabouts? GTK and Qt unstable? Go fool somebody else. What you're saying here just isn't true.
``2.2 Very slow GUI (except when being run with composite window managers on top of OpenGL). ''
Maybe. Interestingly, it wasn't slow in 1997. So maybe X isn't ready for the desktop _anymore_?
``2.3 Many GUI operations are not accelerated. No analogue of GDI or GDI+. Text antialiasing and other GUI operations are software rendered by GUI libraries (GTK->Cairo/QT->Xft).''
I don't know what you mean here. There certainly is support for hardware acceleration.
``2.4 Font rendering is implemented via high level GUI libraries, thus:''
You would rather do it yourself? If so, you can! So what's the complaint?
``2.4.1 fontconfig fonts antialiasing settings cannot be applied on-the-fly. ''
This does not follow from "high level GUI libraries". If anything, high level libraries should help here. Also, such settings cannot be applied on the fly on various other systems that have been very successful on the desktop, so this argument does not support your case.
``2.4.2 Fonts antialiasing only works for certain GUI toolkits (see 2.1). ''
True. But then, so what? If you code your app so that it doesn't use a certain feature, then, indeed, it's not going to use this feature. That doesn't mean the operating system isn't ready for the desktop.
``2.4.3 Default fonts (often) look ugly. ''
Agreed. But that is not a technical issue, that's a matter of which fonts you use as defaults. If some or most or even all distros use ugly fonts by default, that doesn't mean Linux isn't rea
Re:GPL'd code available only by request?
on
Phoenix BIOSOS?
·
· Score: 1
``they could also charge you for the physical source distribution.
yea, GPL, not so well-thought-out''
What, because it allows you to charge for the source code? Many licenses don't even require you to make source code available at all, let alone for free.
Also, I can understand if there are things in the GPL that you don't like, but saying it is not well thought out seems just plain wrong to me.
``Windows' solution is pretty nice. You can pass a pre-created socket handle to accept_ex, which automatically accepts an incoming connection using that socket handle, so that you don't have to use two system calls (select and accept). You can also pre-accept multiple sockets, instead of having to make the system calls under load. Sockets can also be closed with a "re-use" flag, which leaves the handle valid and saves making a system call to create another.
You then associate the sockets with an "IO completion port", which as best as I can tell is a multithreaded-safe linked list for really fast kernel to user program communication.''
I don't know. To me, it all just sounds like kludges to work around the facts that system calls are slow and that the implementation of the Berkeley API causes many system calls. You are adapting the structure of your program to code around the problems, instead of fixing the problems that cause the natural style of your program to lead to slowness.
There is nothing in the Berkeley socket API that mandates system calls or context switches. At worst, some copying is necessary (because the API lets the caller specify where data are to be stored, instead of letting the callee return a pointer to where data are actually stored).
The reason we have system calls and context switches, I claim, is that we are using unsafe languages. Because of this, applications could contain code that overwrites other programs' memory. We don't want that, and we have taken to separate address spaces to avoid it. The separate address spaces are enforced by the hardware, but this has a price, especially on x86. Perhaps it is time to rethink the whole "C is fast" credo. As the number of work instructions that can be executed in the time it takes to do a context switch increases, so does the relative performance of systems that do not need context switches, but of course we can only do away with context switches if we can provide safety guarantees in another way. One way would be to have the compiler enforce them. But that is outside the scope of Berkeley sockets, of course.
I couldn't get to the article, but if they think Berkeley sockets are obsolete, I'd like to see what alternative they offer, why they think these alternatives are better, and what the pitfalls of the alternatives are.
``and yet Microsoft currently faces no significant market pressure from liabilities associated with having broken their own product.''
I think the problem here is lack of competition. If people actually chose from among different products to fulfill the same need, they could choose the best product for them.
Erecting barriers to entry (e.g. need to have insurance, good lawyers, and/or deep pockets, or you're going to get sued into oblivion) is not what is going to solve this issue.
I think the key here is interoperability. And the key to interoperability is open standards. Open standards allow multiple products to support the same protocols and file formats, allowing users to use the product they prefer to actually work with thes protocols and formats.
So, if anything must be mandatory, it's open standards. Require government agencies to use open standards for communication with the outside world. Break vendor lock-in. Enable competition on features other than support for proprietary formats. Then, when quality becomes a way to distinguish yourself from the competition, perhaps you will find that quality will improve, without having to enter the morass of coding liabilities into the law.
And then, if, as a customer, you feel your vendor has seriously let you down, you can sue them even in the absence of a law that holds them liable. Even without a law, there are some things you can reasonably expect and some things you can't reasonably expect. If you can make a good case, you will win - especially in the absence of a law that prescribes a specific outcome.
The summary makes it sound like it was all one person's fault. This can't possibly stand up to reason.
First of all, if the code was so important, it should have been reviewed, tested, etc. Bugs happen, everybody knows it. Finding and fixing the bugs before entering production is the responsibility of everyone involved in the whole process from specification to acceptance.
Secondly, even if there was an undiscovered bug in the code, that doesn't excuse those who relied on the faulty outcomes. The whole game in a free market is that the same thing has different values to different people. You must do your own calculations, based on your own inputs, using your own methods. If someone else messes up their calculations, that's your opportunity to win. Relying on someone else's numbers is a risk, and relying on them blindly is a recipe for failure.
All in all, yes, of course, if you wrote buggy software, you get the blame for that... but it's not your fault that the bugs slip through the cracks and everybody ends up relying on your buggy software. That is their own choice.
Exactly. It makes me wonder what they were even doing in the debugger in the first place. Clearly not debugging an actual problem with the hash tables...
``My mother, who was programming before a fair few of us (including me) were born, once told me this: If you think you've found a bug in a compiler, or an operating system, or a programming language, or a well-known commonly used library... you're wrong. ''
Sadly, I've wasted a lot of time because that is what I used to think.
``Of course, this doesn't hold true 100% of the time, especially when you're pushing the limits of new versions of large 3rd party libraries, but when one is just starting to program (and hence using very well known, well tested libraries and code) it's true 99.99% of the time. ''
That's the key. I'm used to GNU/Linux and the free BSDs, and those actually work well. Then I had to use various fashionable Java frameworks, Sun's Java, and MySQL, and I ran into bugs with most of them. And, of course, being unfamiliar with the technology, I assumed that I was doing something wrong, until lots of time spent reading documentation and testing things convinced me that, really, the bugs were not in my code but, indeed, in the code it was built on.
I wonder how much it would cost to just save everything I download. I mean not just the occassional song or movie, but also web pages I look at, emails I get. Everything that enters my computer that is destined for me. I honestly think it is no more than a few hundred megabytes a month. That wouldn't be too expensive.
The problem would be how to make it accessible. Hmm, this is interesting.:-)
Slashdot Mirror
Oh good! I am glad that Ingsoc is finally instituting rewards for goodthink. How else are we going to protect our precious culture from such harmful influences as freedom of expression, creativity, and uncensored foreign broadcasts?
Why the sarcasm? Lossless, DRM free, CD-quality seems a very reasonable thing to ask for. It's what you would get if you bought a CD, after all.
The difference is that, with online distribution, there is no medium: no physical CD needs to be pressed, no case need be manufactured, no cover art printed, the package doesn't have to be distributed, it doesn't have to be stored, and so on. So this ought to be cheaper for the distributor.
As for CD-quality being the least one would expect: in this day and age, with movies being distributed with surround sound and many people having hardware capable of rendering it, yes, CDs are starting to get long in the tooth. Stereo? 44.1 KHz? That is indeed the least you would expect.
As for lossless... Yes, of course. MP3 was all the rage in the 1990s when a gigabyte was a lot of storage. Today, harddisks are easily 1000 times as large. I think we can afford for our music files to be a factor 50 larger. And if you still want lossy compression, you can always do it yourself ... and make your own trade-off between quality and size.
All in all, I think the grandparent's asking for lossless CD-quality music is entirely reasonable. The only reason why it might not seem that way is because the incumbent players in the music industry want to fight it every step of the way. Yes, lossless, DRM-free, CD-quality music is probably a pipe dream. But it's not because it's asking too much.
In the 1990s, we had HTML elements to embed arbitrary multimedia elements into webpages. Browsers generally supported those through plugins.
I don't understand all this noise about Theora vs. H.264 support in the browser, nor do I understand why you would want to wrap your video in Flash, adding another dependency on a proprietary technology.
What's wrong with just using and object-element and a well-supported video format?
``This isn't progress, this is a punishment to each and every one of us.''
If we choose to support Windows, that is.
I stopped doing that years ago, because I saw it as a sort of punishment in and of itself. The thing is, ideological arguments aside, I use Debian because it requires very little time for maintenance. Supporting any sort of other operating system besides is going to increase the maintenance burden, and that is particularly true if maintenance requires a lot of manual actions or even physical access (which I have needed only once with Debian - and even that was once too often for my taste).
Nowadays, I just tell people "Sorry, I don't know how to deal with Windows and I have no desire to learn." They turn to somebody who actually likes supporting Windows, and everybody is happy.
On the other hand, while talking about the 1990s and things Linux had first (compared to Windows):
- Linux actually existed before Windows 95 (1991 and 1995, respectively - if you want to include NT, that was 1993 IIRC) ...) were actually first in Linux ...)
- Thus, features that are shared among early Linux and early Windows (32-bit, long file names, multitasking,
- Multi-user
- Filesystem with permissions (ok, Windows had "read only"
- A useful degree of POSIX-compatibility (OTOH, Windows had useful win16-compatibility - I don't think Linux's was very good)
- Lots of GNU utilities (familiar to those familiar with Unix, and often preferred over their proprietary Unix counterparts)
- Remote acccess (telnet, X11)
- Multiple desktop environments to choose from
- Virtual desktops
- Development tools either included with the system or available for free (or did Windows have that, too?)
- Source code either included or available for free
- Support for multiple machine architectures
I'm sure the list isn't even exhaustive, but it serves to show that Linux having something before Windows is not exactly rare. Of course, there are tons of things that Windows has gotten before Linux ... widespread consumer acceptance being one obvious and important item.
``While what he says is factually correct''
No. A virtualization layer can and should be much simpler than a full operating system. You _can_ have one without bugs.
How would you say AGG compares to Cairo?
While on the subject, I would like to ask what other open formats there are for vector graphics. I'm especially interested in efficient formats (avoiding the overhead of XML) and in formats that do more than just represent images (e.g. that allow animation and/or scripting).
Thanks a lot. It looks like 3D support for any AMD card currently on the market (Radeon HDxxxx) is still a ways off, but I think I can survive the wait.
While on the subject, I would like to ask a question. Obviously, I could do the research myself, but someone probably knows the answer from the top of their heads. So here is the question:
- Is there any current graphics card that sells for under 100 USD, and has open source drivers that allow decent gaming? Preferably passively cooled.
I have a GeForce 6600 (passively cooled) now, which I am happy with in terms of performance. But that's using the closed source driver. With Intel, VIA, and AMD having open source accelerated 3D, is there a video card I can buy now that has the same or better performance, but using open source drivers?
And one other important point:
TeX and LaTeX don't crash and don't eat your document. Even in the event that they would somehow become unable to process your document, you can still extract pretty much everything you want from the document with another program, because it's all human-readable.
MS Word does not go berserk on your document as much as it used to, but it still does happen. Even if it doesn't FUBAR your document completely, it still tends to mess up the formatting.
Of all people who I know who asked me if they should write their thesis in Word or in LaTeX, only one has written it in Word (against my advice) and not regretted it. Most took my advice and found out that learning LaTeX actually doesn't take that long, and that they got so many appreciative comments on their documents that they would use LaTeX again. The rest went with Word and lost lots and lots of time, usually towards the end of the project when stress was highest. And that they had to learn LaTeX anyway for the next step in their life, because it's what journals want you to use.
The lesson: if you do use Word, please please please, make backups all the time. That means multiple times a day. But first, think hard about whether not learning LaTeX now is actually going to save you any time at all.
``In my opinion, one of the biggest hurdles keeping Linux our of the domestic desktop market is the developers apparently can't put themselves in the shoes of the average user. In my personal experience they tend to hold the end user in contempt, but I realize that this is a fairly small sample of the community...''
If your point is "a lot of what goes into Linux isn't meant for the average Jane", you have that absolutely right.
However, you are wrong if you generalize from that to "the developers are not end users". The great strength of Linux and a lot of open source software is that many of the developers _are_ end users. They write the software for themselves, and then share their work with the world to use, distribute, improve, or ignore as they wish.
Think about that for a second. "Hold the end user in contempt"? That sounds like a very asocial thing to do. Sharing your work doesn't sound so asocial. Could it be that they are just saying "I made this for me. If you want to use it, fine. If you don't want to use it, also fine. But you don't get to tell me how I should have done my job."
Sure, that's no way to conquer the hearts of the average Janes, but who said that was the goal?
``Like it or not, Windows and OSX have set standards for interface and functional transparency. It may not sit well with developers that they can't micromanage what the OS is doing, but the average user just doesn't give a shit and is unwilling if not incapable of tweaking the OS to accomplish otherwise simple tasks.''
I think you're spot on there.
``It needs to "just work." If you need to use the command line, it's broken for desktop use. If you need to manually edit a file, it's broken for desktop use. If an essential component for some software is not included and must be installed and configured separately, it's broken for desktop use. (That last one is a big, big problem for Linux!)''
The funny thing is this is the exact reason I use Debian, and cringe when I have to use Windows. For me, Debian comes closest to "Just Works" from among all the things I've tried. Windows, for me, is a time sink: a lot of tweaking before I get anywhere near productive on it, and then a lot of time goes into maintenance. Hey, that sounds like the same thing many people have coming from Windows to some Linux distribution.
``For all the faults Microsoft has with their software, at least they did the research and learned how Joe Shmoe uses a computer and designed to the lowest common denominator. That's how they ended up on top.''
Nope. They were on top, and that's how they got to shape user expectations. When Microsoft pushed DOS, DOS was how average Joes used computers. Macintoshes and Amigas and all those were for weirdos.
Now that Microsoft pushes Windows, the command line is for weirdos.
And don't start about how GUIs are so much more intuitive than the command line. I lived through the age when command line interfaces were the norm, and I can tell you that, at the time, everybody knew how to use the keyboard, but only "computer freaks" knew how to use the mouse. Getting to understand how the pointer moved when you moved the mouse (note that they are in different planes!) was hard enough, but that was only the start...next you needed to learn about clicking, double-clicking, right-clicking and control-clicking. Intuitive? Not to the average computer users of that time!
``Windows XP? Put it in and the sound comes out.''
Exactly the same as with any decent desktop Linux distro.
Provided, of course, the system comes with a driver for your sound card. To point out the obvious: Windows XP and your favorite Linux-based OS are no different here.
The difference is that, in your care, Windows XP came with a working driver for your sound card, and your Linux distro didn't. Conversely, one of my brothers has a computer with a SATA controller that Windows XP doesn't include a driver for, but some version of Ubuntu does.
Complaining about your Linux distro of choice not shipping with drivers for every piece of hardware is fine and dandy, but it isn't a shortcoming of Linux. It's a valid reason for not wanting to use it, and it will take time and effort before that reason goes away. But it doesn't mean anything is wrong with Linux, just as the fact that not all houses come with Ethernet sockets doesn't mean that there is anything wrong with Ethernet.
The only thing worse than the article is the summary. "Technical reasons"? My behind.
To the author, and to the rest of the world:
``0. Premise: proprietary software will stay indefinitely. Full stop. You may argue eternally, but complicated software like games, 3D applications, databases, CADs(Computer-aided Design), etc. which cost millions of dollars and years of man-hours to develop will never be open sourced. Software patents are about to stay forever.''
Even if true, so what? This has nothing to do with Linux being ready for the desktop.
``1. No reliable sound system, no reliable unified software audio mixing, many (old or/and proprietary) applications still open audio output exclusively causing major user problems and headache. ''
How do you mean "no reliable sound system"? As for applications FUBARing it, I don't know if that is still true, but even if it is, that is not a problem with Linux so much as a problem with those applications. If you use those applications, your experience may be suboptimal. But you can also choose not to use these applications.
``1.1 Insanely difficult to set up volume levels, audio recording ... and in some situations even audio output. ''
Eh? I don't find alsamixer "insanely difficult". Even if you do, there are plenty of others that may suit you better.
``1.2 Highly confusing, not self-explanatory mixer settings.''
I have a lot of settings that I don't understand. But I understand "master" and "PCM", and those are all I ever use. The rest is just stuff I ignore ... and that many mixers don't actually display at all. I guess none of it is especially self-explanatory, but a bit of fiddling with the sliders and you will know soon enough. Is this a big issue? Even if so, it's not a technical issues - more a user interface issue.
``1.3 By default many distros do not set volume levels properly (no audio output/no sound recording).''
I don't know if that is true, but I'll take your word for it. It's not a technical issue, though.
``2. X system:''
Ah, everybody's favorite scapegoat.
``2.1 No good stable standardized API for developing GUI applications (like Win32 API). Both GTK and Qt are very unstable and often break backwards compatibility. ''
Nonsense. XLib is a stable API and has backward compatibility until ... 1985 or thereabouts? GTK and Qt unstable? Go fool somebody else. What you're saying here just isn't true.
``2.2 Very slow GUI (except when being run with composite window managers on top of OpenGL). ''
Maybe. Interestingly, it wasn't slow in 1997. So maybe X isn't ready for the desktop _anymore_?
``2.3 Many GUI operations are not accelerated. No analogue of GDI or GDI+. Text antialiasing and other GUI operations are software rendered by GUI libraries (GTK->Cairo/QT->Xft).''
I don't know what you mean here. There certainly is support for hardware acceleration.
``2.4 Font rendering is implemented via high level GUI libraries, thus:''
You would rather do it yourself? If so, you can! So what's the complaint?
``2.4.1 fontconfig fonts antialiasing settings cannot be applied on-the-fly. ''
This does not follow from "high level GUI libraries". If anything, high level libraries should help here. Also, such settings cannot be applied on the fly on various other systems that have been very successful on the desktop, so this argument does not support your case.
``2.4.2 Fonts antialiasing only works for certain GUI toolkits (see 2.1). ''
True. But then, so what? If you code your app so that it doesn't use a certain feature, then, indeed, it's not going to use this feature. That doesn't mean the operating system isn't ready for the desktop.
``2.4.3 Default fonts (often) look ugly. ''
Agreed. But that is not a technical issue, that's a matter of which fonts you use as defaults. If some or most or even all distros use ugly fonts by default, that doesn't mean Linux isn't rea
``they could also charge you for the physical source distribution.
yea, GPL, not so well-thought-out''
What, because it allows you to charge for the source code? Many licenses don't even require you to make source code available at all, let alone for free.
Also, I can understand if there are things in the GPL that you don't like, but saying it is not well thought out seems just plain wrong to me.
``Windows' solution is pretty nice. You can pass a pre-created socket handle to accept_ex, which automatically accepts an incoming connection using that socket handle, so that you don't have to use two system calls (select and accept). You can also pre-accept multiple sockets, instead of having to make the system calls under load.
Sockets can also be closed with a "re-use" flag, which leaves the handle valid and saves making a system call to create another.
You then associate the sockets with an "IO completion port", which as best as I can tell is a multithreaded-safe linked list for really fast kernel to user program communication.''
I don't know. To me, it all just sounds like kludges to work around the facts that system calls are slow and that the implementation of the Berkeley API causes many system calls. You are adapting the structure of your program to code around the problems, instead of fixing the problems that cause the natural style of your program to lead to slowness.
There is nothing in the Berkeley socket API that mandates system calls or context switches. At worst, some copying is necessary (because the API lets the caller specify where data are to be stored, instead of letting the callee return a pointer to where data are actually stored).
The reason we have system calls and context switches, I claim, is that we are using unsafe languages. Because of this, applications could contain code that overwrites other programs' memory. We don't want that, and we have taken to separate address spaces to avoid it. The separate address spaces are enforced by the hardware, but this has a price, especially on x86. Perhaps it is time to rethink the whole "C is fast" credo. As the number of work instructions that can be executed in the time it takes to do a context switch increases, so does the relative performance of systems that do not need context switches, but of course we can only do away with context switches if we can provide safety guarantees in another way. One way would be to have the compiler enforce them. But that is outside the scope of Berkeley sockets, of course.
I couldn't get to the article, but if they think Berkeley sockets are obsolete, I'd like to see what alternative they offer, why they think these alternatives are better, and what the pitfalls of the alternatives are.
``and yet Microsoft currently faces no significant market pressure from liabilities associated with having broken their own product.''
I think the problem here is lack of competition. If people actually chose from among different products to fulfill the same need, they could choose the best product for them.
Erecting barriers to entry (e.g. need to have insurance, good lawyers, and/or deep pockets, or you're going to get sued into oblivion) is not what is going to solve this issue.
I think the key here is interoperability. And the key to interoperability is open standards. Open standards allow multiple products to support the same protocols and file formats, allowing users to use the product they prefer to actually work with thes protocols and formats.
So, if anything must be mandatory, it's open standards. Require government agencies to use open standards for communication with the outside world. Break vendor lock-in. Enable competition on features other than support for proprietary formats. Then, when quality becomes a way to distinguish yourself from the competition, perhaps you will find that quality will improve, without having to enter the morass of coding liabilities into the law.
And then, if, as a customer, you feel your vendor has seriously let you down, you can sue them even in the absence of a law that holds them liable. Even without a law, there are some things you can reasonably expect and some things you can't reasonably expect. If you can make a good case, you will win - especially in the absence of a law that prescribes a specific outcome.
Let's not forget to archive the materials they have published (mostly as Caldera). There is some useful information there.
The summary makes it sound like it was all one person's fault. This can't possibly stand up to reason.
First of all, if the code was so important, it should have been reviewed, tested, etc. Bugs happen, everybody knows it. Finding and fixing the bugs before entering production is the responsibility of everyone involved in the whole process from specification to acceptance.
Secondly, even if there was an undiscovered bug in the code, that doesn't excuse those who relied on the faulty outcomes. The whole game in a free market is that the same thing has different values to different people. You must do your own calculations, based on your own inputs, using your own methods. If someone else messes up their calculations, that's your opportunity to win. Relying on someone else's numbers is a risk, and relying on them blindly is a recipe for failure.
All in all, yes, of course, if you wrote buggy software, you get the blame for that ... but it's not your fault that the bugs slip through the cracks and everybody ends up relying on your buggy software. That is their own choice.
``Mebbe Microsoft will finally take a tumble for aiding terrorists.''
Unlikely. Now, maybe if it had been Bittorrent. Or tor.
``You don't want the government randomly breaking into e-mail accounts that are "suspect" do you?''
Actually, I rather assume they do that. And that they are not the only ones.
Exactly. It makes me wonder what they were even doing in the debugger in the first place. Clearly not debugging an actual problem with the hash tables...
``My mother, who was programming before a fair few of us (including me) were born, once told me this: If you think you've found a bug in a compiler, or an operating system, or a programming language, or a well-known commonly used library... you're wrong. ''
Sadly, I've wasted a lot of time because that is what I used to think.
``Of course, this doesn't hold true 100% of the time, especially when you're pushing the limits of new versions of large 3rd party libraries, but when one is just starting to program (and hence using very well known, well tested libraries and code) it's true 99.99% of the time. ''
That's the key. I'm used to GNU/Linux and the free BSDs, and those actually work well. Then I had to use various fashionable Java frameworks, Sun's Java, and MySQL, and I ran into bugs with most of them. And, of course, being unfamiliar with the technology, I assumed that I was doing something wrong, until lots of time spent reading documentation and testing things convinced me that, really, the bugs were not in my code but, indeed, in the code it was built on.
I wonder how much it would cost to just save everything I download. I mean not just the occassional song or movie, but also web pages I look at, emails I get. Everything that enters my computer that is destined for me. I honestly think it is no more than a few hundred megabytes a month. That wouldn't be too expensive.
The problem would be how to make it accessible. Hmm, this is interesting. :-)