From reading that article it's easy to see that business types care 100 times more about money/law issues than technical issues, even when the technical issues are important to making money. You can give them all the technical evidence in the world that SCO's case is utter and complete bullshit, just as the Linux community has been doing ever since this case started, and they'll still send SCO's stock sky-high at the mere mention of the word "lawsuit". But start a legal indemnity program, and set up a 10 million dollar defense fund, and suddenly they realize the hot water SCO is in. I can hear them now: "$10 million you say? Wow, now I know they're serious. Call my broker and put a hold on that SCO buy order!" In the business world, money talks. It's a good thing we have IBM/Novell/etc and their $$$ on our side, because otherwise the Linux community would never get heard.
Right now the only mixing done in the ALSA/OSS drivers is done by the sound card hardware itself. All cards can mix together at least one channel of sound output from programs plus MIDI, CD Audio, Mic input, and sometimes other things. Some cards can mix together two or three channels of sound output from programs. But many can't, so the result is that only one program can output sound at a time (which is mixed together with the MIDI/CD/MIC channels on the card, not by the kernel). It is part of the kernel's job to virtualize hardware for access by multiple programs, so IMHO the kernel should provide an infinite number of virtual chanels and use software mixing to mix them together. There is an ALSA plugin that allows software mixing in the kernel, but last time I tried it it didn't work, and I don't think there's a way to add more channels on the fly when requested by programs. If ALSA provided only this one benefit over OSS, people would switch to it in droves. I can't understand why it hasn't been added yet.
It has problems with some linux sound drivers causing it to skip or play brief loud screeching sounds randomly, even when no sounds are playing
High CPU usage by other programs causes sound to skip
It keeps the sound device open, meaning non-aRts programs display cryptic error messages or freeze
It uses a non-trivial percentage of the CPU even when idle
Video support was tacked on and sucks
It adds a large, very noticable delay to all sounds
aRts is a synthesizer. KDE shouldn't have adopted it as a general-purpose sound system. Some of its problems have been partially addressed in newer versions, but it is still a bad choice. The way it SHOULD work is the kernel should provide unlimited virtual sound channels and let an unlimited number of programs open the sound device at once. It should use hardware mixing if possible and software mixing if it must, but it should keep latencies absolutely as low as possible. Then apps can choose whatever sound framework they want: aRts, gstreamer, jack, or plain old alsa, and everything would Just Work.
Oh, I know about fuse_kio, and I'm a big fan of it. I'm just explaining why KDE chose to do the ioslave virtual file system layer instead of just using the Unix filesystem directly.
Because mounting things is inconvenient and not user-friendly, and URLs are an extremely nice, compact way to represent a file's location. Much easier to just be able to use a URL at any time in any application and not worry about where you're going to mount stuff or if it's still mounted or whatever. The Unix filesystem model hasn't changed in years and years, and is not capable enough to handle all the things a modern desktop environment needs. For things like http, it doesn't even make sense; how would you mount a web server? Even if you could, you wouldn't be able to use standard Unix tools because you can't get a directory listing using HTTP (well sometimes you can, but not often). A new system based around URLs is the way to go, and that's the way KDE has gone.
The ability for every application to handle every possible protocol using URLs is so nice that it outweighs any disadvantage. Using the fish protocol, you can use KWord or KEdit or any KDE app to edit any file stored on any server where you have a simple ssh account. You don't have to worry about whether the server has ftp access, or down/uploading the file, or mounting any remote directories, or junk like that. You just type the URL into the save dialog, and it works. Every KDE program gets support for this protocol along with FTP, HTTP, SMB, and webdav support, plus expandability for future protocols, for free. It's a big part of what makes KDE so great.
There are open-source apps in various stages of development to do everything that iLife can do. Consistency and the ease-of-use is where iLife shines. Historically, open-source software hasn't been good with either of those. I think that what KDE is doing has the best chance of bringing a consistent and easy-to-use set of applications to the Linux desktop, but it isn't there yet.
I think you communicated your point, but I don't believe it. I don't believe people will buy PCs with that kind of lock-in capability. (note: I'm talking about PCs specifically, not mainframes or supercomputers or even big servers.) Especially big business IT departments. They're not stupid, and Linux is really coming up on their radar now. If Intel tried right now to bring out a scheme that required a license to run an OS, the backlash would knock them straight on their collective asses. They would have to try and sneak it in without anyone noticing, but the Slashdot watchdogs aren't going to let that happen. If Intel does try something like that, the world will know about it. The rush to AMD or Apple would be immediate. I believe that there will always be a market for commodity PCs that run any OS freely.
Running Linux on a commodity PC might not be a problem, but I could see a scheme where "optional" DRM hardware was added in such a way that Linux wouldn't be able to access it freely. This would render Linux unable to use DRMed music/video/software even though it would run just fine for other purposes. I'm not sure how I feel about this kind of scheme. On one hand, the capitalist system we have now for music/video/software distribution is good in some ways. We probably wouldn't have things like big-budget movies (LOTR) or video games (Halo, GTA, etc) without a system of restricted copying. Without DRM, our current distribution system for music/video/software is headed for collapse as copying continues to get easier. Without it, artists/coders would basically cease to be professionals. They would all have to get day jobs doing something else and do their art/coding on the side. OTOH, strict DRM means that sharing of information becomes restricted, and there are numerous bad effects to society from that. Also, there's the crackability of DRM schemes to consider. What happens if a huge sector of the economy relies totally on a single DRM scheme, and it is suddenly cracked? Instant economic carnage. It's a real problem, and I don't see a good middle ground.
As for IBM making free Linux undesirable in comparison to "enhanced IBM Linux", I don't think that's realistic. There are license issues with the GPL that would make it hard for IBM to improve Linux without GPLing the result. Even if it was possible, IBM would be in a constant race against open-source programmers who would be reimplementing every improvement IBM made. So far IBM has not acted this way at all. Their improvements to Linux have been open source all the way. IBM's money-making scheme is purely hardware focused, and I see nothing wrong with that. If IBM wants to charge big business license fees for using their big hardware, let them. I'm not worried because I don't see the commodity PC going away.
So what if businesses have to pay per-CPU for their IBM mainframes in "serious production environments"? The PC still exists. Linux still exists. In fact, Linux is better off because its development is being subsidized by all the money IBM is getting from its big business customers. Sounds like everybody wins (except the Wintel monopoly). What was the problem again?
Well, Slashdot is number 867 so Wikipedia still has a ways to go. Also consider that Alexa only counts alexa toolbar users, and the alexa toolbar is only available for English-speaking Internet Explorer users, which may skew the results. (I imagine Wikipedia gets more non-English traffic while Slashdot gets more non-Internet Explorer traffic)
Saying "the algorithm is O(n*log(n)) in the average case" is questionable. If you rigorously specify the conditions that an "average case" must satisfy, then you can say "the algorithm is O(n*log(n)) under these conditions." But if you don't define what an average case is, then saying something is O(n*log(n)) in the average case is just talking nonsense, because you can't talk about the "worst" average case. It's not well-defined because the concept of an average case is fuzzy. You can say that "on average, the algorithm takes time proportional to n*log(n)," but that's not the same thing as saying it is O(n*log(n)).
If your algorithms class didn't say that Big-O notation specifically indicated the worst possible case, it was a bad algorithms class. Big-O notation is *all about* the worst case. It definitely specifies absolute worst-case behavior.
Understanding isn't all that matters either. You can be understood by someone but give a bad impression at the same time. If you misuse math notation, that might give a bad impression to someone who really knows how it works (although Big-O notation is so widely abused that most likely nobody would care in this case). Also, if you're actually trying to do formal proofs of things using Big-O notation, all this stuff really does matter.
Well, even if an algorithm such as quicksort takes time proportional to N*log(N) in the average case, and N^2 in the worst case, it is still incorrect to say it is O(n*log(n)). Big-O notation literally means "in the worst case" (though people often seem to forget this). So if the worst case of quicksort takes time proportional to N^2, then no matter how unlikely that worst case is, quicksort is still O(n^2). Actually the completely correct thing to say is "quicksort is a member of the set O(n^2)" because O(n^2) really denotes the set of algorithms whose worst case execution times are no worse than n^2. (As an aside, this set also includes algorithms whose worst-case execution times are *better* than n^2. So it is correct to say that merge sort is a member of the set O(n^2) or even O(n^99), even though it is also a member of the set O(n*log(n)).)
Therefore, if Ingo's scheduler really takes time proportional to the number of processes in the worst case, no matter how unlikely that case is, it is incorrect to say that it is O(1).
can you name another one-second sound clip that's used in nearly a hundred movies and TV shows?
That "red alert" type alarm sound. There are like 2 or 3 really popular ones that are used over and over in every movie or TV show that needs an ominous "alert" sound. Next time you're watching a movie and an alarm goes off, see if you recognize the sound. Odds are you've heard it before.
Trolltech is an independent company, not controlled by Canopy. Canopy group owns 5.7% of TrollTech's shares, while Trolltech's employees and founders own 69.7%. This myth of Canopy controlling Trolltech is entirely untrue (but remarkably persistent, thanks to anti-KDE trolls). Read kdemyths.urbanlizard.com and be enlightened.
Wow, that site is awesome. That's the best explanation I've ever seen of why one side of the moon is always facing us. I also like the explanation of why the moon's orbit is spiraling outward and (as a result) Earth's day is getting longer. Thanks for the link!
Just because you haven't heard of it doesn't mean it doesn't exist. There are several linux filesystems suitable for embedded work, and they are designed for flash-card environments. There's cramfs which is a read-only compressed filesystem so you can cram as much stuff as possible into limited Flash space (to upgrade you just re-flash the entire filesystem with a new cramfs disk image, good for simple devices that can be upgraded with new ROMs). There's ramdisks or RAMFS to complement cramfs and make a usable Linux system where nothing at all is ever written to Flash. There's also JFFS which is a journaled filesystem made explicitly for Flash devices, which does try to adapt to Flash's weaknesses. It is used on iPAQs and other handhelds as the main filesystem.
Just because ext3 is journaled doesn't make it a bad choice for flash cards. If it really writes something to the filesystem every five seconds regardless of whether anything has actually changed, then that is cause for concern, but that is not because it is a journaled filesystem per se, that's just because it's badly designed.
It prints a Sierpinski triangle in ASCII. Compiling it is rediculously easy, especially if you're running Linux. Try this: copy and paste the following into a terminal window:
That monster command will make a file named foo.cpp containing the code, compile it, and run the result. (actually the core code there is the C++ version which is shorter by several characters but involves too many < signs to fit in the Slashdot sig box)
I think concerns about flash memory wearing out are usually overblown. I see flash cards advertised as having a minimum lifetime of 1,000,000 rewrite cycles. Suppose you formatted the card as ext3. Even if you wrote to the card once every minute around the clock, and it wrote to the same sectors each time, it would take more than two years to get up to a million writes. And who writes to their flash card every minute? Maybe you wouldn't want to use it as your permanent home directory for a knoppix install you used every day, but for any other use, I'd say that it's unlikely you'll get up to 1,000,000 writes anytime soon.
The kind of person who is an AOL customer doesn't know what the Netscape brand really used to stand for, becuase they don't know what a browser is. So AOL's marketing department has seen fit to apply Netscape as an all-purpose brand for whatever their scheme is today. It really has nothing to do with anything in particular anymore, especially the company Netscape used to be. If you need proof, just consider that the browser for the new Netscape ISP is a Netscape-branded Internet Explorer.
As more failed schemes using the Netscape brand pile up, it will eventually become worthless. Once AOL has squeezed every last bit of brand recognition out of Netscape they will drop it by the side of the road. Personally, I could care less. The browser is Mozilla now, and it's developed by the open-source community. Netscape is dead.
Well, I would say that photon mapping is more than just an "extension to raytracing." It does trace rays, I suppose, but what it does with those rays is quite different from what regular raytracers do. It does look like it could be *the* solution. Neat stuff. I want a hardware photon mapping accelerator:-)
Slashdot Mirror
From reading that article it's easy to see that business types care 100 times more about money/law issues than technical issues, even when the technical issues are important to making money. You can give them all the technical evidence in the world that SCO's case is utter and complete bullshit, just as the Linux community has been doing ever since this case started, and they'll still send SCO's stock sky-high at the mere mention of the word "lawsuit". But start a legal indemnity program, and set up a 10 million dollar defense fund, and suddenly they realize the hot water SCO is in. I can hear them now: "$10 million you say? Wow, now I know they're serious. Call my broker and put a hold on that SCO buy order!" In the business world, money talks. It's a good thing we have IBM/Novell/etc and their $$$ on our side, because otherwise the Linux community would never get heard.
Right now the only mixing done in the ALSA/OSS drivers is done by the sound card hardware itself. All cards can mix together at least one channel of sound output from programs plus MIDI, CD Audio, Mic input, and sometimes other things. Some cards can mix together two or three channels of sound output from programs. But many can't, so the result is that only one program can output sound at a time (which is mixed together with the MIDI/CD/MIC channels on the card, not by the kernel). It is part of the kernel's job to virtualize hardware for access by multiple programs, so IMHO the kernel should provide an infinite number of virtual chanels and use software mixing to mix them together. There is an ALSA plugin that allows software mixing in the kernel, but last time I tried it it didn't work, and I don't think there's a way to add more channels on the fly when requested by programs. If ALSA provided only this one benefit over OSS, people would switch to it in droves. I can't understand why it hasn't been added yet.
aRts is a synthesizer. KDE shouldn't have adopted it as a general-purpose sound system. Some of its problems have been partially addressed in newer versions, but it is still a bad choice. The way it SHOULD work is the kernel should provide unlimited virtual sound channels and let an unlimited number of programs open the sound device at once. It should use hardware mixing if possible and software mixing if it must, but it should keep latencies absolutely as low as possible. Then apps can choose whatever sound framework they want: aRts, gstreamer, jack, or plain old alsa, and everything would Just Work.
Oh, I know about fuse_kio, and I'm a big fan of it. I'm just explaining why KDE chose to do the ioslave virtual file system layer instead of just using the Unix filesystem directly.
The ability for every application to handle every possible protocol using URLs is so nice that it outweighs any disadvantage. Using the fish protocol, you can use KWord or KEdit or any KDE app to edit any file stored on any server where you have a simple ssh account. You don't have to worry about whether the server has ftp access, or down/uploading the file, or mounting any remote directories, or junk like that. You just type the URL into the save dialog, and it works. Every KDE program gets support for this protocol along with FTP, HTTP, SMB, and webdav support, plus expandability for future protocols, for free. It's a big part of what makes KDE so great.
There are open-source apps in various stages of development to do everything that iLife can do. Consistency and the ease-of-use is where iLife shines. Historically, open-source software hasn't been good with either of those. I think that what KDE is doing has the best chance of bringing a consistent and easy-to-use set of applications to the Linux desktop, but it isn't there yet.
Running Linux on a commodity PC might not be a problem, but I could see a scheme where "optional" DRM hardware was added in such a way that Linux wouldn't be able to access it freely. This would render Linux unable to use DRMed music/video/software even though it would run just fine for other purposes. I'm not sure how I feel about this kind of scheme. On one hand, the capitalist system we have now for music/video/software distribution is good in some ways. We probably wouldn't have things like big-budget movies (LOTR) or video games (Halo, GTA, etc) without a system of restricted copying. Without DRM, our current distribution system for music/video/software is headed for collapse as copying continues to get easier. Without it, artists/coders would basically cease to be professionals. They would all have to get day jobs doing something else and do their art/coding on the side. OTOH, strict DRM means that sharing of information becomes restricted, and there are numerous bad effects to society from that. Also, there's the crackability of DRM schemes to consider. What happens if a huge sector of the economy relies totally on a single DRM scheme, and it is suddenly cracked? Instant economic carnage. It's a real problem, and I don't see a good middle ground.
As for IBM making free Linux undesirable in comparison to "enhanced IBM Linux", I don't think that's realistic. There are license issues with the GPL that would make it hard for IBM to improve Linux without GPLing the result. Even if it was possible, IBM would be in a constant race against open-source programmers who would be reimplementing every improvement IBM made. So far IBM has not acted this way at all. Their improvements to Linux have been open source all the way. IBM's money-making scheme is purely hardware focused, and I see nothing wrong with that. If IBM wants to charge big business license fees for using their big hardware, let them. I'm not worried because I don't see the commodity PC going away.
So what if businesses have to pay per-CPU for their IBM mainframes in "serious production environments"? The PC still exists. Linux still exists. In fact, Linux is better off because its development is being subsidized by all the money IBM is getting from its big business customers. Sounds like everybody wins (except the Wintel monopoly). What was the problem again?
Well, Slashdot is number 867 so Wikipedia still has a ways to go. Also consider that Alexa only counts alexa toolbar users, and the alexa toolbar is only available for English-speaking Internet Explorer users, which may skew the results. (I imagine Wikipedia gets more non-English traffic while Slashdot gets more non-Internet Explorer traffic)
If your algorithms class didn't say that Big-O notation specifically indicated the worst possible case, it was a bad algorithms class. Big-O notation is *all about* the worst case. It definitely specifies absolute worst-case behavior.
Understanding isn't all that matters either. You can be understood by someone but give a bad impression at the same time. If you misuse math notation, that might give a bad impression to someone who really knows how it works (although Big-O notation is so widely abused that most likely nobody would care in this case). Also, if you're actually trying to do formal proofs of things using Big-O notation, all this stuff really does matter.
Therefore, if Ingo's scheduler really takes time proportional to the number of processes in the worst case, no matter how unlikely that case is, it is incorrect to say that it is O(1).
That "red alert" type alarm sound. There are like 2 or 3 really popular ones that are used over and over in every movie or TV show that needs an ominous "alert" sound. Next time you're watching a movie and an alarm goes off, see if you recognize the sound. Odds are you've heard it before.
Trolltech is an independent company, not controlled by Canopy. Canopy group owns 5.7% of TrollTech's shares, while Trolltech's employees and founders own 69.7%. This myth of Canopy controlling Trolltech is entirely untrue (but remarkably persistent, thanks to anti-KDE trolls). Read kdemyths.urbanlizard.com and be enlightened.
Oh my god. I just downloaded Linux 2.6 in 26 seconds. Bittorrent certainly lives up to its name.
Wow, that site is awesome. That's the best explanation I've ever seen of why one side of the moon is always facing us. I also like the explanation of why the moon's orbit is spiraling outward and (as a result) Earth's day is getting longer. Thanks for the link!
I've never heard of a read limit on Flash memory. I assume you can just read from it as many times as you want and it won't wear out.
Just because you haven't heard of it doesn't mean it doesn't exist. There are several linux filesystems suitable for embedded work, and they are designed for flash-card environments. There's cramfs which is a read-only compressed filesystem so you can cram as much stuff as possible into limited Flash space (to upgrade you just re-flash the entire filesystem with a new cramfs disk image, good for simple devices that can be upgraded with new ROMs). There's ramdisks or RAMFS to complement cramfs and make a usable Linux system where nothing at all is ever written to Flash. There's also JFFS which is a journaled filesystem made explicitly for Flash devices, which does try to adapt to Flash's weaknesses. It is used on iPAQs and other handhelds as the main filesystem.
Well, that was the number I saw during my google search for flash cards. You can certainly buy ones rated at 1,000,000 cycles.
Just because ext3 is journaled doesn't make it a bad choice for flash cards. If it really writes something to the filesystem every five seconds regardless of whether anything has actually changed, then that is cause for concern, but that is not because it is a journaled filesystem per se, that's just because it's badly designed.
Oops. Did I say "more than two years"? I meant "almost two years". 22.8159105 months to be exact.
I think concerns about flash memory wearing out are usually overblown. I see flash cards advertised as having a minimum lifetime of 1,000,000 rewrite cycles. Suppose you formatted the card as ext3. Even if you wrote to the card once every minute around the clock, and it wrote to the same sectors each time, it would take more than two years to get up to a million writes. And who writes to their flash card every minute? Maybe you wouldn't want to use it as your permanent home directory for a knoppix install you used every day, but for any other use, I'd say that it's unlikely you'll get up to 1,000,000 writes anytime soon.
As more failed schemes using the Netscape brand pile up, it will eventually become worthless. Once AOL has squeezed every last bit of brand recognition out of Netscape they will drop it by the side of the road. Personally, I could care less. The browser is Mozilla now, and it's developed by the open-source community. Netscape is dead.
Wow. Whoever did that was very, very smart.
Well, I would say that photon mapping is more than just an "extension to raytracing." It does trace rays, I suppose, but what it does with those rays is quite different from what regular raytracers do. It does look like it could be *the* solution. Neat stuff. I want a hardware photon mapping accelerator :-)