This really emphasises a difference between MS and Google, in my mind. MS announces months or years in advance that "soon we'll have this great thing that will blow everybody away". They spend the intervening time inflating everybody's expectations, and when the product is finally unveiled, a lot of people are underwhelmed. Google, on the other hand, doesn't say much at all about what they're going to release, and when it finally comes out, everybody is blown away.
I think Google's approach is working. OTOH, I know that MS Research has been focusing a lot of effort on search technologies (they gave a talk about their work at my workplace, the MIT CS & AI Lab, recently) so it will be interesting to see if their new search engine raises the bar.
Can you concoct a similar scenario whereby, through the discovery of evidence, it can be proved that an Intelligent Designer was not responsible for life on earth? Or even a scenario which can disprove the involvement of a supreme being in geologically recent speciation?
No. And that is why ID is not science and has no place in science classrooms.
OK. I give. What is so amazing about Ubuntu? Do they compile thier stuff with special options or have some whiz-bang installation program?
The thing I love about Ubuntu (actually Kubuntu; I much prefer KDE) is that it takes this great framework provided by Debian and actually uses it. That is, for example, when you plug in a USB storage device, you don't worry about where it's going to show up in/dev or where to mount it or what groups you need to be in in order to access it. It Just Works, with the file manager opening up a window on you desktop showing the contents of the drive. Debian has all the necessary bits to do things like this, too, but none if it Just Works by default.
It's just a really really well integrated system that works well. Somebody (Tim O'Reilley?) said that MacOS X made computing fun again. To me, (K)Ubuntu makes computing fun again.
70-80% of my spam used to come from this guy. It seems every time one of these weasels gets hauled in there's a dip in spam. In the past two days my spammage has dropped to a trickle. The past three nights total spam: 173, 43, 17
While that's nice, it's not related to this. From TFA: "In May, a federal judge shut down Xpress Pharmacy and appointed a receiver to take control of the business' assets." This guy's been out of business for months. He was indicted today, but shutdown months ago.
Repeat after me - when you buy Windows or OS X, you don't OWN it. It is quite difference with Linux, where you really own it. (Just to point out differences between EULA and GPL).
No, you most definitely do not own Linux just because you install it or downloaded it. If you contribute source code to it, you own that particular little bit of source code, but that would have been the case anyway (i.e. you automatically own the copyright on anything you produce, unless you sign away the ownership of it to somebody else). Just like with OSX, you are licensed to use Linux. It's just the the Linux license grants you lots more freedoms that the OSX license. You cannot violate the terms of the Linux license any more than you can violate the terms of the OSX license without breaking the law.
Because their work is usually noticed only when things go wrong. I guess it goes with the idea of infrastructure that when it's running well, it's not supposed to be noticed.
Or, as a former supervisor once put it, we're the people who, when we're doing our job, you wonder what the hell you're paying us for. And when we're not doing our job, you wonder what the hell you're paying us for. So please, show a little appreciation, even if just once a year.
I can't remember which episode but I disctinctly remember the Enterprise having this and hiding in the corona of the sun. I remember someone in command (actually I think it was Beverly, what episodes did she get command in, can't be many?) asking about the status of "the metaphasic shielding". So it did make a reappearance at least once.
The title of the episode was "Descent". It was actually a two part episode that spanned two seasons (5 and 6, maybe?) It was the episode in which the crew encountered the Borg after they had "corrupted" it by giving Hugh the notion of individuality in the episode "I, Borg" and Lore came in and took over. It's one of my favorite episodes, in part because you've got Dr. Crusher running a ship full of junior officers and having to do something crazy like hide out in a star, and in part because it involves both Lore and the Borg.
For individuals who don't have anything major to loose or anything special to worry about, sure. But not for large organizations with a support structure (help desk, local docs, procedures, etc.) that needs to be ramped up to support new changes. And not for anyone doing anything special or mission-critical that needs to test things before deployment. The rule in any production environment is "Test, test, test, and then test some more". You simply cannot just type "apt-get dist-upgrade" (or "yum upgrade" or any other variation on the theme) in the Real World, I'm afraid.
Yay, another believer! I've been using Debian for ~8 years now, and have been combating the idea that 'apt-get dist-upgrade' between versions is transparent and that backports or mixed stable/unstable systems are a good idea for much of that time.
As a sysadmin at a large Debian site, I need to know, for example, that postgresql is going to come up and serve the right data to the right people after an upgrade (and not do it an order of magnitude slower, as was the case on one system we upgraded recently). I also need to know that the commercial software that the users depend on, such as Matlab, Sun's JDK, and Allegro Common Lisp will all still work after an upgrade. I need to make sure that an upgrade of the mail server is going to continue routing all the mail to the right places, store it as expected, and allow the users to access it via the supported mechanisms. I need to be sure that the NFS and AFS file servers are going to continue serving their 10s of terabytes of mission-critical data to the users. These are all Debian systems, but none of them will get an 'apt-get dist-upgrade' without thorough testing.
In preparation for the sarge release, I've been using user-mode linux to test the upgrades of our critical servers. It's pretty easy to build a system that looks just like an existing system and then test the upgrade. When I'm done, I can simply delete or archive the filesystem image and move on to the next server. Thus far things are mostly going well, but there have definitely been some situations that made me really glad I wasn't working on a production machine at the time!
I totally agree. Phrack used to be THE e-zine when it came to anything related to computer security and the like. As you mentioned, their buffer overflow in issue 49 is hands-down one of the best explanations of how stack overflows work, and is usually referenced in any current article dealing with the subject.
I think a big part of the problem is that computer security research has gone mainstream. It's now very common to see Usenix's;login: or the ACM's Communications packed full of new research. Between that and the fact that the blackhats have moved a bit further underground, it's not surprising that Phrack is filled with content that would only appeal to a script kiddie.
noah
Re:Good news, even for Sid users.
on
Sarge is Now Frozen
·
· Score: 2, Informative
It doesn't seem to be a problem to all of the people happily using Debian. I really wonder why people get so emotionally involved in things that personally make no difference to them. If you tried Debian, didn't like it, and moved on to something else that you do like better, what difference does it make to you if others keep on using it because they do like it. On the other hand, if you haven't tried Debian, and never intend to, why comment on it at all? Do you like to waste your own time?
Just so you know, I've been a Debian user since '96 and a developer since '01. I run a large Debian site with several hundred servers and workstations. I am very happy with Debian's technology and believe it really helps for running a large infrastructure. However, the stable distribution is painfully outdated, even for servers. We've been running it on our servers, but have had to build custom kernels to support modern hardware and have had to back port most of the server packages we use. We have been running sarge on our workstations for almost two years at this point, because woody is just not acceptable in such an environment. Running an unreleased OS on hundreds of machines, especially when they're not all installed at the same time and thus have different versions of many key packages, is really quite difficult.
A lot of people have called for Debian to simply do away with the stable release all together, since "everybody just runs testing or unstable anyway", but that really wouldn't work in an environment such as mine. Too many people run Debian on just a couple of machines and really don't see what the problem is. You get a very different perspective on it when you have hundreds. All we need is predictable release cycles. 12-18 months for major releases is attainable and perfectly reasonable for me as a user.
I don't think you understand the market for debian stable. When I need a server, it's Debian stable. I don't care if it's still running apache 1.whatever, because it's STABLE. I don't care if it's got KDE 2.2 because I'll never use X on it. I don't care if a lot of the stuff isn't the latest and/or greatest, because I don't -need- it. I need stability and prompt security updates, which Debian stable delivers in spades.
Show me where Debian claims that stable is aimed at the server market. They do not make such a claim! Not only that, but they don't claim that it's a good idea for anybody other than developers to run unstable or for anybody at all to run testing. Stable is the only supported version of Debian, period. That's a major problem.
noah
Re:How Debian (really) works...
on
Sarge is Now Frozen
·
· Score: 5, Interesting
Debian Stable seems to be doing just fine. It's a bit old, so hardware support is dated, but no one who needs a "stable" distro ever complains that Debian Stable isn't "stable" enough. Those using Stable are the same people who like to assume that Debian is a server-only distro, and wonder what all the fuss is about "new releases". Unless you're one of the new users who clicks on debian.org and mistakenly downloads and installs Stable, expecting a modern desktop with modern hardware support, Stable is great.
I disagree. At this point, I find woody too old to even be usable on servers. What's outdated? Well, let's see: the MTA, whichever it may be; the web server, whichever web server you may prefer; the SNMP packages; the various FTP servers; OpenSSH; Kerberos; OpenAFS; PHP; perl; gcc; MySQL; Postgres. The list could go on. Not only are these packages out of date, but they're horribly out of date, in some cases multiple upstream stable releases behind. I run a number of services on woody boxes, and for most of these services I've had to backport packages or use something like backports.org for the important packages, often including their dependencies. Having to do this kind of thing sort of defeats the purpose of a "stable" release, IMO. Just because a machine is a "server" doesn't mean it doesn't need modern hardware support or up to date software. Maybe it's OK if it's just a simple little shell/static HTML server sitting in your closet for you and a few friends to use, but when you start trying to run an enterprise on Debian stable, you find it rather limiting.
Yahoo Store (previously Viamall) was a LISP application. That was something of a secret at the time; the developers didn't want to give up their competitive advantage.
ITA Software, the company whose back-end powers sites like Orbitz.com, uses a significant amount of Lisp code in their applications.
Scheme is a block-structured language modeled on Algol. Common Lisp is a natural evolution of LISP 1.5. As part of the evolution, sure, some features from Scheme have been sneaked back into Common Lisp, but they are really very different languages.
You better tell that to the guys who wrote the scheme spec (R5RS). They certainly seem to think that Scheme is a dialect of Lisp. To quote from R5RS:
Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman.
Scheme and Common Lisp are both dialects of Lisp. They're not the same language, but if you grok one, you can pretty easily figure out the other.
noah
Re:An ideal world would run on LISP...
on
Practical Common Lisp
·
· Score: 3, Informative
Two years ago, I saw a practical demonstration of a Symbolics LISP Machine from 1987
The frightening thing is, lispms from the 80's enjoy quite some popularity among certain people where I work. They really are amazing machines, and those who use them regularly feel strongly that there hasn't been a more usable environment in all the time since they were created.
Let me tell you, though, as a sysadmin, these things can be a royal PITA. Not because there's anything wrong with them (well, except maybe for their complete lack of security) but they're just so different.
There are still many copies of The Lisp Machine Manual lying around, including an early rant by RMS against the recent trend of software hoarding. It makes for an interesting read...
Debian has no operating costs! Developer time, hardware, bandwidth, etc is all donated. $40k will last as long as it needs to. Debian could operate on a fraction of that with no impact.
I don't get this attitude. I just don't see where you are coming from. If you want current stuff, run testing or unstable. No big deal. Or run mostly stable, and just upgrade select items to testing, and other select items to unstable. Hell, if you really want to be on the bleeding edge, CVS and compile and help with testing. I couldn't imagine anyone running debian stable unless it was critical to be *rock-solid* stable. Which means heavy load servers, in my mind.
Sure, that works just fine if you have only about 1 or 2 machines and only a couple of users. But not everybody is in that position! I run a large enterprise with hundreds of Debian workstations and servers. It's not so simple to just "run testing or unstable". I need a machine installed today to behave the same as a machine installed yesterday. That makes testing/unstable very difficult for me to use.
I can't believe how freqently I hear people spouting the "just run unstable" bit. It's just not that simple.
Over double that, it's 7 years from release. Which means that box you don't want to have to care about can tick over serving DNS for about 6 years all the while getting errata, but you can also have the latest postgresql on another box.
OK, I thought it was longer than 3, but 3 was what came to mind. I don't think it's reasonable to expect Debian to support a stable release that long, but maybe an 18 month release cycle with a 36 month support cycle would be nice. Maybe bug fix/errata releases even more freqently, similar to what Debian already does with the periodic stable revisions.
Then again, as has already been mentioned, it may be too much to ask this of a purely volunteer organization. Most developers, after all, aren't going to bother keeping installations of older releases around just to prepare security updates.
How does it decide? Well, at my uni it's just a matter of the destination. So if I am trying to access www.mit.edu, my packets will fly fast over internet2, and if I want to access www.yahoo.fr, I'll be going over the (slightly slower) internet1 (aka "Commodity Internet").
Additionally, most I2 sites prefer to use I2 where possible because it generally doesn't cost them anything to send bits over it. Whereas commodity bandwidth costs money.
"This has been a subversion of the research purposes for which Internet2 was developed."
Let me know if you disagree, but actually, this is true.
The thing is, though, the way most sites do their routing, if you're at an I2 site (most major US univerities) and communicating with some other I2 site you're using I2 whether you're doing research or not. All internet traffic between e.g. MIT and Cal Tech goes over I2 whether it's research or P2P. So you really can't get on anybody's case for treating I2 any differently than the "normal" internet.
Personally, I think Debian needs to articulate a strategy that distinguishes the server room from the desktop. The release cycle requirements are different. The application requirements are different. There is just too much going on in the desktop applications arena right now for Debian to stand a chance of keeping up. They should focus on the server room. If Debian doesn't focus it's efforts in this way, they stand the very real chance of overextending themselves into obsolescence.
I don't think that the "server" release cycle should be any different than the "desktop" release cycle. As an enterprise Debian admin, let me tell you that stable is just as outdated on servers as it is on workstations. Users are particularly unhappy about MySQL and PHP versions. As postmaster, I'm saddened by Mailman, Exim, Horde, and Cyrus. In all cases, those server apps are so horribly outdated in stable.
I think the big difference is that enterprise users need longer support cycles, not longer release cycles. That is, a stable release needs to be supported for a long time. That does not preclude the release of another, newer stable release. The problem with Debian is that, except for a short transition period (one year, when woody was released) there's only one supported "stable" release. You're forced to upgrade to the new stable when it comes out, or else you're stuck running something unsupported.
As an example, Redhat announced a while back that they'd support a given version of RHEL for, what, 3 years after its release? That's what enterprise/server users need. RHEL will release newer versions, and we as users can upgrade when we see fit to another supported version. With Debian, that's really not possible.
Unfortunately, Debian is having a hard enough time getting people to work on the security team supporting just one release. Trying to support something like 3 releases at once is not likely to happen given the volunteer nature of the organization.
2. Debian has changed its release architectures after Sarge so that Etch is not slowed down by unknown, exotic and/or obsolete architectures.
That is most definitely not the case. There was considerable discussion on the debian-devel list following the release team's proposal to limit the etch release to 4 architectures. While the proposal may still be implemented, it also may still undergo significant changes. People have been suggesting all sorts of counter proposals to try and keep all the architectures in sync.
Personally, even though I've run Debian on MIPS, MIPSel, Alpha, and Sparc (all of which would be dropped under the Release Team's proposal) I still support the proposal and would like to see architecture support scaled back a bit. There are those, however, who feel that Debian would be giving up too much if they were to drop some platforms.
Damn, that's a good read. Regardless if you think Nuclear Winter is huey - it's takes the wind out of some of the more recent whishfull thinking that's passing itself as hard science.
You really ought to read David Brin's thoughts on Crichton's lecture. Or, if one novelist berating another isn't good enough for you, go read up on what Jared Diamond has to say about him.
Personally, I don't have a whole lot of respect for Crichton's "science", and would give more credibility to anything I read in SciAm than anything he ever said.
Guess what! Does your average joe-six pack run an Apache server? No! If they did, I'm sure Apache would be riddled with problems.
How do you figure? Just because more people are running something, it suddenly has a buggier code base with more unchecked buffers, format string bugs, or other security issues? Yes, Apache can be configured poorly, and sloppy configurations often result in security problems, but that's not a bug in the software. If a sysadmin configured their Apache server to accept unauthenticated file uploads and execute uploaded file, is that Apache's fault?
Windows software, particularly their desktop stuff, has security issues out of the box. I'd argue that MacOS and some Linux distros are more secure simply because they have more secure default settings, and they would remain more secure even if they had the desktop market share that Windows has.
It's interesting that the article mentions the use of the JFS filesystem:
During ingestion, the RaveHD wrote sequential DPX files for each shot to a standard Linux JFS filesystem on a fiber-channel disk array, Howard says. When all required shots had been ingested, the entire JFS filesystem was made available via Samba and gigabit Ethernet to the studio's production workers.
JFS isn't one of the high profile filesystems on Linux; People usually talk about Reiser, EXT3, or XFS. I wonder what lead the developers to choose JFS.
Slashdot Mirror
I think Google's approach is working. OTOH, I know that MS Research has been focusing a lot of effort on search technologies (they gave a talk about their work at my workplace, the MIT CS & AI Lab, recently) so it will be interesting to see if their new search engine raises the bar.
noah
No. And that is why ID is not science and has no place in science classrooms.
noah
The thing I love about Ubuntu (actually Kubuntu; I much prefer KDE) is that it takes this great framework provided by Debian and actually uses it. That is, for example, when you plug in a USB storage device, you don't worry about where it's going to show up in /dev or where to mount it or what groups you need to be in in order to access it. It Just Works, with the file manager opening up a window on you desktop showing the contents of the drive. Debian has all the necessary bits to do things like this, too, but none if it Just Works by default.
It's just a really really well integrated system that works well. Somebody (Tim O'Reilley?) said that MacOS X made computing fun again. To me, (K)Ubuntu makes computing fun again.
noah
While that's nice, it's not related to this. From TFA: "In May, a federal judge shut down Xpress Pharmacy and appointed a receiver to take control of the business' assets." This guy's been out of business for months. He was indicted today, but shutdown months ago.
noah
No, you most definitely do not own Linux just because you install it or downloaded it. If you contribute source code to it, you own that particular little bit of source code, but that would have been the case anyway (i.e. you automatically own the copyright on anything you produce, unless you sign away the ownership of it to somebody else). Just like with OSX, you are licensed to use Linux. It's just the the Linux license grants you lots more freedoms that the OSX license. You cannot violate the terms of the Linux license any more than you can violate the terms of the OSX license without breaking the law.
noah
Or, as a former supervisor once put it, we're the people who, when we're doing our job, you wonder what the hell you're paying us for. And when we're not doing our job, you wonder what the hell you're paying us for. So please, show a little appreciation, even if just once a year.
noah
The title of the episode was "Descent". It was actually a two part episode that spanned two seasons (5 and 6, maybe?) It was the episode in which the crew encountered the Borg after they had "corrupted" it by giving Hugh the notion of individuality in the episode "I, Borg" and Lore came in and took over. It's one of my favorite episodes, in part because you've got Dr. Crusher running a ship full of junior officers and having to do something crazy like hide out in a star, and in part because it involves both Lore and the Borg.
noah
Yay, another believer! I've been using Debian for ~8 years now, and have been combating the idea that 'apt-get dist-upgrade' between versions is transparent and that backports or mixed stable/unstable systems are a good idea for much of that time.
As a sysadmin at a large Debian site, I need to know, for example, that postgresql is going to come up and serve the right data to the right people after an upgrade (and not do it an order of magnitude slower, as was the case on one system we upgraded recently). I also need to know that the commercial software that the users depend on, such as Matlab, Sun's JDK, and Allegro Common Lisp will all still work after an upgrade. I need to make sure that an upgrade of the mail server is going to continue routing all the mail to the right places, store it as expected, and allow the users to access it via the supported mechanisms. I need to be sure that the NFS and AFS file servers are going to continue serving their 10s of terabytes of mission-critical data to the users. These are all Debian systems, but none of them will get an 'apt-get dist-upgrade' without thorough testing.
In preparation for the sarge release, I've been using user-mode linux to test the upgrades of our critical servers. It's pretty easy to build a system that looks just like an existing system and then test the upgrade. When I'm done, I can simply delete or archive the filesystem image and move on to the next server. Thus far things are mostly going well, but there have definitely been some situations that made me really glad I wasn't working on a production machine at the time!
noah
I think a big part of the problem is that computer security research has gone mainstream. It's now very common to see Usenix's ;login: or the ACM's Communications packed full of new research. Between that and the fact that the blackhats have moved a bit further underground, it's not surprising that Phrack is filled with content that would only appeal to a script kiddie.
noah
Just so you know, I've been a Debian user since '96 and a developer since '01. I run a large Debian site with several hundred servers and workstations. I am very happy with Debian's technology and believe it really helps for running a large infrastructure. However, the stable distribution is painfully outdated, even for servers. We've been running it on our servers, but have had to build custom kernels to support modern hardware and have had to back port most of the server packages we use. We have been running sarge on our workstations for almost two years at this point, because woody is just not acceptable in such an environment. Running an unreleased OS on hundreds of machines, especially when they're not all installed at the same time and thus have different versions of many key packages, is really quite difficult.
A lot of people have called for Debian to simply do away with the stable release all together, since "everybody just runs testing or unstable anyway", but that really wouldn't work in an environment such as mine. Too many people run Debian on just a couple of machines and really don't see what the problem is. You get a very different perspective on it when you have hundreds. All we need is predictable release cycles. 12-18 months for major releases is attainable and perfectly reasonable for me as a user.
noah
Show me where Debian claims that stable is aimed at the server market. They do not make such a claim! Not only that, but they don't claim that it's a good idea for anybody other than developers to run unstable or for anybody at all to run testing. Stable is the only supported version of Debian, period. That's a major problem.
noah
I disagree. At this point, I find woody too old to even be usable on servers. What's outdated? Well, let's see: the MTA, whichever it may be; the web server, whichever web server you may prefer; the SNMP packages; the various FTP servers; OpenSSH; Kerberos; OpenAFS; PHP; perl; gcc; MySQL; Postgres. The list could go on. Not only are these packages out of date, but they're horribly out of date, in some cases multiple upstream stable releases behind. I run a number of services on woody boxes, and for most of these services I've had to backport packages or use something like backports.org for the important packages, often including their dependencies. Having to do this kind of thing sort of defeats the purpose of a "stable" release, IMO. Just because a machine is a "server" doesn't mean it doesn't need modern hardware support or up to date software. Maybe it's OK if it's just a simple little shell/static HTML server sitting in your closet for you and a few friends to use, but when you start trying to run an enterprise on Debian stable, you find it rather limiting.
noah
ITA Software, the company whose back-end powers sites like Orbitz.com, uses a significant amount of Lisp code in their applications.
noah
You better tell that to the guys who wrote the scheme spec (R5RS). They certainly seem to think that Scheme is a dialect of Lisp. To quote from R5RS:
Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman.
Scheme and Common Lisp are both dialects of Lisp. They're not the same language, but if you grok one, you can pretty easily figure out the other.
noah
The frightening thing is, lispms from the 80's enjoy quite some popularity among certain people where I work. They really are amazing machines, and those who use them regularly feel strongly that there hasn't been a more usable environment in all the time since they were created.
Let me tell you, though, as a sysadmin, these things can be a royal PITA. Not because there's anything wrong with them (well, except maybe for their complete lack of security) but they're just so different.
There are still many copies of The Lisp Machine Manual lying around, including an early rant by RMS against the recent trend of software hoarding. It makes for an interesting read...
noah
noah
Sure, that works just fine if you have only about 1 or 2 machines and only a couple of users. But not everybody is in that position! I run a large enterprise with hundreds of Debian workstations and servers. It's not so simple to just "run testing or unstable". I need a machine installed today to behave the same as a machine installed yesterday. That makes testing/unstable very difficult for me to use.
I can't believe how freqently I hear people spouting the "just run unstable" bit. It's just not that simple.
noah
OK, I thought it was longer than 3, but 3 was what came to mind. I don't think it's reasonable to expect Debian to support a stable release that long, but maybe an 18 month release cycle with a 36 month support cycle would be nice. Maybe bug fix/errata releases even more freqently, similar to what Debian already does with the periodic stable revisions.
Then again, as has already been mentioned, it may be too much to ask this of a purely volunteer organization. Most developers, after all, aren't going to bother keeping installations of older releases around just to prepare security updates.
noah
Additionally, most I2 sites prefer to use I2 where possible because it generally doesn't cost them anything to send bits over it. Whereas commodity bandwidth costs money.
noah
Let me know if you disagree, but actually, this is true.
The thing is, though, the way most sites do their routing, if you're at an I2 site (most major US univerities) and communicating with some other I2 site you're using I2 whether you're doing research or not. All internet traffic between e.g. MIT and Cal Tech goes over I2 whether it's research or P2P. So you really can't get on anybody's case for treating I2 any differently than the "normal" internet.
noah
I don't think that the "server" release cycle should be any different than the "desktop" release cycle. As an enterprise Debian admin, let me tell you that stable is just as outdated on servers as it is on workstations. Users are particularly unhappy about MySQL and PHP versions. As postmaster, I'm saddened by Mailman, Exim, Horde, and Cyrus. In all cases, those server apps are so horribly outdated in stable.
I think the big difference is that enterprise users need longer support cycles, not longer release cycles. That is, a stable release needs to be supported for a long time. That does not preclude the release of another, newer stable release. The problem with Debian is that, except for a short transition period (one year, when woody was released) there's only one supported "stable" release. You're forced to upgrade to the new stable when it comes out, or else you're stuck running something unsupported.
As an example, Redhat announced a while back that they'd support a given version of RHEL for, what, 3 years after its release? That's what enterprise/server users need. RHEL will release newer versions, and we as users can upgrade when we see fit to another supported version. With Debian, that's really not possible.
Unfortunately, Debian is having a hard enough time getting people to work on the security team supporting just one release. Trying to support something like 3 releases at once is not likely to happen given the volunteer nature of the organization.
noah
That is most definitely not the case. There was considerable discussion on the debian-devel list following the release team's proposal to limit the etch release to 4 architectures. While the proposal may still be implemented, it also may still undergo significant changes. People have been suggesting all sorts of counter proposals to try and keep all the architectures in sync.
Personally, even though I've run Debian on MIPS, MIPSel, Alpha, and Sparc (all of which would be dropped under the Release Team's proposal) I still support the proposal and would like to see architecture support scaled back a bit. There are those, however, who feel that Debian would be giving up too much if they were to drop some platforms.
noah
You really ought to read David Brin's thoughts on Crichton's lecture. Or, if one novelist berating another isn't good enough for you, go read up on what Jared Diamond has to say about him.
Personally, I don't have a whole lot of respect for Crichton's "science", and would give more credibility to anything I read in SciAm than anything he ever said.
noah
How do you figure? Just because more people are running something, it suddenly has a buggier code base with more unchecked buffers, format string bugs, or other security issues? Yes, Apache can be configured poorly, and sloppy configurations often result in security problems, but that's not a bug in the software. If a sysadmin configured their Apache server to accept unauthenticated file uploads and execute uploaded file, is that Apache's fault?
Windows software, particularly their desktop stuff, has security issues out of the box. I'd argue that MacOS and some Linux distros are more secure simply because they have more secure default settings, and they would remain more secure even if they had the desktop market share that Windows has.
noah
During ingestion, the RaveHD wrote sequential DPX files for each shot to a standard Linux JFS filesystem on a fiber-channel disk array, Howard says. When all required shots had been ingested, the entire JFS filesystem was made available via Samba and gigabit Ethernet to the studio's production workers.
JFS isn't one of the high profile filesystems on Linux; People usually talk about Reiser, EXT3, or XFS. I wonder what lead the developers to choose JFS.
noah