They're already taking off. Do a google search on "dvd rental percentage" and read some of the stories. While DVD rentals are still only a fraction of the movie-rental market, it's a fraction that's growing by leaps and bounds.
Now, if the movie industry wasn't so lame, what they'd do is send the movies to the rental places over the net, and each individual store would burn their own discs. But I somehow don't see that happening.
We've been a netflix survivor for half a year or so, and I really like it. It's especially great for watching things like The Sopranos, where there are four one-hour episodes on each disc, and you don't necessarily want to watch them all in the same night -- you can keep it as long as you want.
Unlike the reviewer, we're all the way in Boston, so turnaround time is much higher -- sometimes more than a week round-trip. This means that unlike the 45 movies he mentions, we can only fit seven or eight in a month, and that only if we watch right when they come, so I'm highly looking forward to the rumored east-coast distribution center. (This article was the first I'd heard of that.)
Still, it works out to a pretty decent deal for us, and the convenience is unbeatable, especially in these sad and dark post-Kozmo days. We've got a queue of about 45 movies stacked up (and like the reviewer, pretty much always get the first thing on our list -- I don't know if they do this, but I can imagine crunching everyone's upcoming queues for optimal dispersal of inventory...). It's basically like TV-on-demand, with really high latency.
They'll win the patent suit appeal eventually -- Graffitti was available as software for the Newton long before the Xerox patent was even conceived of.
I can't connect to WinInformant, but if you look at the numbers available at SecurityFocus, you'll see that they did not simply add up the numbers. Linux is listet with 96 aggregated vulnerabilities for 2001, while e.g. Red Hat has 54, Debian got 28, and Mandrake got 36. There are more Linux distributions listed, but these numbers allone show that your claim is wrong (unless WinInformant has different numbers).
I thought that too after looking at the SecurityFocus numbers, but then I figured it out. Scroll down the page a bit to the "Top Vulnerable Packages 2001 Packages", and there you'll see the numbers that the article references -- "MandrakeSoft Linux Mandrake 7.2: 33", "RedHat Linux 7.0: 28", etc.
You can install IE quite easily and legally on the oldest versions of Windows 95, which didn't come with IE in any form. You don't have to pay anything for it == free.
Even then, it requires a Microsoft product to run. At best, it's "free with purchase". I don't take issue with a browser being bundled with the OS -- I just don't like to foster the misconception that this is some sort of gift.
Of course, it's always amusing watching free software advocates (who think software should be free/beer) whine about Microsoft giving away software for free.
The only version of IE that is "free" (in the beer sense) is the one for MacOS. (I'm not counting the laughable Solaris version.) All the others are part of your *purchase* of Microsoft Windows -- not free at all.
Ok, this is off-topic a bit, but you might be interested to know, if you don't already, that Allegro is still alive and well, and reached version 4.0 just last month. Runs in DOS, Linux, FreeBSD, Irix, Solaris, Win32, and BeOS, with MacOS and QNX in the works.
...Alan Cox's own fork which is steadily separating from Linus' core...
Well, Alan isn't really in the business of doing this anymore. But even when he did, that's not the way things worked -- the Alan and Linus trees stayed fairly in sync with each other in many ways.
Aren't you taking a good developer (who can maintain every part of the kernel) away from the newer versions of the kernel?
Stability and code maintenance are just as important (or more important, in some cases) as new and exciting features. Work on older kernels isn't wasted -- any relevant fixes can be ported up to the devel version.
The reason we all have PCs is that they're commodity hardware -- the similarities far far outweigh the differences. Even for most niche markets -- handhelds, embedded systems, mainframes, whatever -- it's almost always worth it to build a distribution for the general case.
Realistically speaking, general-purpose options hit all but one in a hundred installations. Actually, I'd be willing to bet that i386 optimization is perfectly good for that amount of people. Throw in i686/athlon optimization, and add a high-stability/high-performance split, and you've down to something like one in a thousand.
For the rest, including the cases you mention -- the Mars explorer team, and those who are just "not satisified with second-best" can certainly compile their own apps without the overhead and potential extra problems -- not to mention expense -- of the server farm idea. The return on investment (in many senses) just isn't worth it.
There are about 2^(# of the config choice options) possible variants of kernel.
Yes, this is why modules were invented. It's basically a problem that's been solved, modulo a few issues. Precompiling a million different types of kernels isn't really the answer.
What's the point? There's only so many different kind of processors. In fact, these days there's *basically* two options. Why not just build i686 and Athlon optimized versions and be done with it? If you want to hit more fringe groups, build PowerPC (yeah, sorry), (Ultra)Sparc, and Alpha packages too.
All of the other things you mention are matters of choosing which binary package to install, or how to configure them. There's nothing to be gained by automatically recompiling.
Well, obviously they won't be telling whole stories -- they'll be individual gags. To save you the bother of actually reading the story: the idea is that each one is a demonstration (by Gromit) of one of Wallace's inventions.
One thing I love about the Wallace and Gromit shorts is their attention to detail. Every scene has interesting little bits in the background -- stuff going on that you might catch on the fourth or fifth viewing. I'm afraid that in stretching things to a full-length feature, some of this will be lost. Chicken Run, while fun enough, disappointed me for exactly this reason. It was kinda funny, and had some amusing references to other movies -- and certainly they put a lot of work into it -- but it just doesn't have the *depth* that Wallace and Gromit do. I hope Nick Park will prove my fears unfounded.
For example you could say that, once you start dipping into the overcommit pool, fork() will start failing but existing processes can continue.
Why make this a special pool? I mean, isn't this effectively like saying "once 80% (or whatever) of swap is full, don't allow any more forks"? I'm not convinced that's any improvement over the OOM killer. (Or at least not over turning off overcommit, if that's the way you want to go.)
Palm wasn't the first such device on the market, though. They were just the first to have a decent price and a good interface *designed to work as a PDA*, not attempting to be a desktop replacement in your pocket. They still win on both counts.
I don't think the "Red Hat is a company" argument applies in this case. It's certainly a factor in adaptation of the distro itself, I don't think the decisions re: starting derived distros are made by people at that level of thinking.
/usr/src/redhat/SOURCES is just a default location, and I agree, it's kind of ugly. It's a trivial change in your.rpmrc to make it put source files in a different location (for example, on a per-package basis) and that's what most RPM builders do.
It would be nice if there were a "patch up to patch #N" command line option", but I don't see that as a big hurdle -- it's not something I find myself wanting to do very often.
I'm not even sure.deb is technically better. There's some things RPM does nicely that dpkg doesn't. (For example, the "one big patch" idea in dpkg means that if you're going to add patches of your own to an upstream package, you need to invent your own structure for keeping your changes distinct, and reinvent it for each package, as far as I can tell. RPM deals with lots of patches nicely, and I think it's one of the reasons that there are so many Red Hat-derived distributions.)
Hmmm, I'm a little skeptical of this theory. The first Red Hat "Mother's Day" release was in 1995. It didn't include RPM, but did include its ancestor rpp. The first releases of Debian which included the primative version of dpkg were around the same time. I don't think one was significantly before the other -- they were basically in infancy together. dpkg certainly didn't seem more "baked" than rpm at the time.
Slashdot Mirror
They're already taking off. Do a google search on "dvd rental percentage" and read some of the stories. While DVD rentals are still only a fraction of the movie-rental market, it's a fraction that's growing by leaps and bounds.
Now, if the movie industry wasn't so lame, what they'd do is send the movies to the rental places over the net, and each individual store would burn their own discs. But I somehow don't see that happening.
We've been a netflix survivor for half a year or so, and I really like it. It's especially great for watching things like The Sopranos, where there are four one-hour episodes on each disc, and you don't necessarily want to watch them all in the same night -- you can keep it as long as you want.
Unlike the reviewer, we're all the way in Boston, so turnaround time is much higher -- sometimes more than a week round-trip. This means that unlike the 45 movies he mentions, we can only fit seven or eight in a month, and that only if we watch right when they come, so I'm highly looking forward to the rumored east-coast distribution center. (This article was the first I'd heard of that.)
Still, it works out to a pretty decent deal for us, and the convenience is unbeatable, especially in these sad and dark post-Kozmo days. We've got a queue of about 45 movies stacked up (and like the reviewer, pretty much always get the first thing on our list -- I don't know if they do this, but I can imagine crunching everyone's upcoming queues for optimal dispersal of inventory...). It's basically like TV-on-demand, with really high latency.
Then you're an unamerican freak and not wanted anyway.
I guess.
They'll win the patent suit appeal eventually -- Graffitti was available as software for the Newton long before the Xerox patent was even conceived of.
Or at least a key part of it. See Bug #56301.
I can't connect to WinInformant, but if you look at the numbers available at SecurityFocus, you'll see that they did not simply add up the numbers. Linux is listet with 96 aggregated vulnerabilities for 2001, while e.g. Red Hat has 54, Debian got 28, and Mandrake got 36. There are more Linux distributions listed, but these numbers allone show that your claim is wrong (unless WinInformant has different numbers).
I thought that too after looking at the SecurityFocus numbers, but then I figured it out. Scroll down the page a bit to the "Top Vulnerable Packages 2001 Packages", and there you'll see the numbers that the article references -- "MandrakeSoft Linux Mandrake 7.2: 33", "RedHat Linux 7.0: 28", etc.
You can install IE quite easily and legally on the oldest versions of Windows 95, which didn't come with IE in any form. You don't have to pay anything for it == free.
Even then, it requires a Microsoft product to run. At best, it's "free with purchase". I don't take issue with a browser being bundled with the OS -- I just don't like to foster the misconception that this is some sort of gift.
Of course, it's always amusing watching free software advocates (who think software should be free/beer) whine about Microsoft giving away software for free.
The only version of IE that is "free" (in the beer sense) is the one for MacOS. (I'm not counting the laughable Solaris version.) All the others are part of your *purchase* of Microsoft Windows -- not free at all.
Ok, this is off-topic a bit, but you might be interested to know, if you don't already, that Allegro is still alive and well, and reached version 4.0 just last month. Runs in DOS, Linux, FreeBSD, Irix, Solaris, Win32, and BeOS, with MacOS and QNX in the works.
http://www.talula.demon.co.uk/allegro/
...Alan Cox's own fork which is steadily separating from Linus' core...
Well, Alan isn't really in the business of doing this anymore. But even when he did, that's not the way things worked -- the Alan and Linus trees stayed fairly in sync with each other in many ways.
Aren't you taking a good developer (who can maintain every part of the kernel) away from the newer versions of the kernel?
Stability and code maintenance are just as important (or more important, in some cases) as new and exciting features. Work on older kernels isn't wasted -- any relevant fixes can be ported up to the devel version.
The reason we all have PCs is that they're commodity hardware -- the similarities far far outweigh the differences. Even for most niche markets -- handhelds, embedded systems, mainframes, whatever -- it's almost always worth it to build a distribution for the general case.
Realistically speaking, general-purpose options hit all but one in a hundred installations. Actually, I'd be willing to bet that i386 optimization is perfectly good for that amount of people. Throw in i686/athlon optimization, and add a high-stability/high-performance split, and you've down to something like one in a thousand.
For the rest, including the cases you mention -- the Mars explorer team, and those who are just "not satisified with second-best" can certainly compile their own apps without the overhead and potential extra problems -- not to mention expense -- of the server farm idea. The return on investment (in many senses) just isn't worth it.
There are about 2^(# of the config choice options) possible variants of kernel.
Yes, this is why modules were invented. It's basically a problem that's been solved, modulo a few issues. Precompiling a million different types of kernels isn't really the answer.
What's the point? There's only so many different kind of processors. In fact, these days there's *basically* two options. Why not just build i686 and Athlon optimized versions and be done with it? If you want to hit more fringe groups, build PowerPC (yeah, sorry), (Ultra)Sparc, and Alpha packages too.
All of the other things you mention are matters of choosing which binary package to install, or how to configure them. There's nothing to be gained by automatically recompiling.
The test on me: I only read it as "scheme", totally missing the pun until you pointed it out. American, or just a tad slow? You decide. :)
Well, obviously they won't be telling whole stories -- they'll be individual gags. To save you the bother of actually reading the story: the idea is that each one is a demonstration (by Gromit) of one of Wallace's inventions.
One thing I love about the Wallace and Gromit shorts is their attention to detail. Every scene has interesting little bits in the background -- stuff going on that you might catch on the fourth or fifth viewing. I'm afraid that in stretching things to a full-length feature, some of this will be lost. Chicken Run, while fun enough, disappointed me for exactly this reason. It was kinda funny, and had some amusing references to other movies -- and certainly they put a lot of work into it -- but it just doesn't have the *depth* that Wallace and Gromit do. I hope Nick Park will prove my fears unfounded.
For example you could say that, once you start dipping into the overcommit pool, fork() will start failing but existing processes can continue.
Why make this a special pool? I mean, isn't this effectively like saying "once 80% (or whatever) of swap is full, don't allow any more forks"? I'm not convinced that's any improvement over the OOM killer. (Or at least not over turning off overcommit, if that's the way you want to go.)
Palm wasn't the first such device on the market, though. They were just the first to have a decent price and a good interface *designed to work as a PDA*, not attempting to be a desktop replacement in your pocket. They still win on both counts.
or maybe you meant not to put commas around "or DSTN". which turns this into a punctuation nitpick. which i'm sorry about. :)
not to nitpick... okay, to nitpick a little bit.... but DSTN is a passive-matrix LCD technology. Active matrix is TFT.
I don't think the "Red Hat is a company" argument applies in this case. It's certainly a factor in adaptation of the distro itself, I don't think the decisions re: starting derived distros are made by people at that level of thinking.
.rpmrc to make it put source files in a different location (for example, on a per-package basis) and that's what most RPM builders do.
/usr/src/redhat/SOURCES is just a default location, and I agree, it's kind of ugly. It's a trivial change in your
It would be nice if there were a "patch up to patch #N" command line option", but I don't see that as a big hurdle -- it's not something I find myself wanting to do very often.
You are comparing *release* dates, which are totally irrelevant, and so is the initial release state of dpkg and rpp.
No I'm not. Why should Red Hat necessarily go with one unfinished unreleased project over another?
As for the initial state of dpkg and rpm, the point is that dpkg has the future built in, while rpm was and will always be badly crafted.
In what way?
I'm not even sure .deb is technically better. There's some things RPM does nicely that dpkg doesn't. (For example, the "one big patch" idea in dpkg means that if you're going to add patches of your own to an upstream package, you need to invent your own structure for keeping your changes distinct, and reinvent it for each package, as far as I can tell. RPM deals with lots of patches nicely, and I think it's one of the reasons that there are so many Red Hat-derived distributions.)
Hmmm, I'm a little skeptical of this theory. The first Red Hat "Mother's Day" release was in 1995. It didn't include RPM, but did include its ancestor rpp. The first releases of Debian which included the primative version of dpkg were around the same time. I don't think one was significantly before the other -- they were basically in infancy together. dpkg certainly didn't seem more "baked" than rpm at the time.