We were talking about installation/maintenance of a large (>100) number of hosts. You are free to use whatever at home - so be it ubuntu, I heard it's good. I don't think FAI would work with ubuntu, though.
Actually, I gather it does work. There have been some posts to the FAI mailing lists detailing the steps needed to make it install, and they seemed rather straightforward. Hell, if you can install Solaris with FAI, I'm sure you can install Ubuntu!
The beef of many people is that rather than soliciting the community for proposals on how to improve the release cycle, a number of influential people got together to draft a plan, threw it out into the open, and let the discussions begin -- but not discussions on how to best solve the problem, but rather on discussions whether to drop architectures or not.
But suggestions for improving the release cycle are posted to -devel all the time.
A lot of times, getting together for a high-bandwidth discussion really is the only way to get something done. Most of the other suggestions or proposals posted to the mailing list are not nearly as well thought out as this one, and the discussions quickly degenerate into flamewars because the people offering the proposal didn't think through all the various ways that their proposal would be interpreted. The current proposal was made by people who have been involved in Debian for many years and who understand the release process better than anybody else in the world.
I think it's unfortunate that there are so many people in Debian who feel that every decision must involve everybody all the time. Debian is just too big for that to work. Given that the entire community feels that Debian's release cycle is too long, I believe it is up to the release team to fix the problem as they see fit. The fix may need to be drastic, and it's the release team that knows best. Let them get together and come up with a "Here's what the release team wants to change" document, and go from there.
You may want to take a look at FAI (Fully Automatic Installation - google will find it). We've been using it quite successfully for that kind of maintenance.
We already use FAI. It has installed over 200 hosts for us. It's a nice system, and makes enterprise deployment possible (doing several hundred stand-alone installs is simply unreasonable, IMHO), but it doesn't eliminate any of the problems with Debian releases. Maintaining local snapshots of sarge is somewhat helpful, but then you're awfully close to running your own distribution. You have to be very aware of what's going to change when you update the snapshot. Unless you plan on updating the entire snapshot periodically, you are going to have to worry about dependencies and various package relationship problems. But if you update the whole snapshot, then you've got to be sure that the new packages aren't going to hose your existing machines, or otherwise interfere with the general user experience.
As an active Debian developer, I simply want to state: this is anything but final and not at all decided. I am only one of many developers against the proposed scheme, and especially against the way in which the scheme was devised -- in a closed meeting with only a few select members, and completely without soliciting any input from the community.
Dude, input from the community is exactly what's happening on -devel right now. What's wrong with some developers (who have official duties delegated by the DPL) getting together to hash out a proposal for a change to the system? If an individual had come up with this proposal on his own and posted it to -devel-announce, would that make it better?
Working together to solve a major problem like the Debian release policy is something that can often be performed much much better when done face to face. I applaud the initiative and dedication shown by these guys, and think the proposal is a damn fine start. I have no doubt that whatever change finally does happen post sarge will be different (perhaps dramatically so) from what was proposed today. There will absolutely be community involvement in determining the final course of action.
Interesting, I run Debian, with kde 3.4 over kernel 2.6.10 and my distro does not feel 5 years out of date.
Sure, you run sid. You know what that means? It means that this proposal won't affect you at all. (additionally, I'm sure you run x86, along with what, 98% of all other debian users?)
The thing is, you're the type of user who doesn't need predictable release cycles. You can get by on the bleeding edge and run software for which a new package release may be uploaded on any given day.
A lot of Debian users are in very different positions. I, for example, run Debian in an enterprise environment, with literally hundreds of servers and workstations. woody is simply not an option in this environment. Hardware support (both kernel and user space) is dreadfully lacking, and we'd have to backport most of the software we use every day anyway. We'd end up running something so bastardized that we'd no longer see many of the benefits of running Debian at all. So we were forced to go with something more current. We chose sarge, with the understanding that we'd have to be responsible for the security of our systems, with little help from Debian. But of course, there are problems there, too. Sarge changes every day. A machine installed today may look nothing like a machine installed tomorrow. Additionally, we simply have no way of knowing when sarge will be released. The saying within Debian has always been "we'll release when it's ready", but of course, there's never a published metric for readiness, so there's simply no way of knowing when that will be.
Basically, right now, Debian really doesn't have a good release for enterprise users. That really sucks, since IMHO Debian provides a software infrastructure that makes it really appealing for large scale deployments. I really hope this new proposal is a step toward a shorter and more predictable release cycle!
Going back in time 5 years ago, one also notes another event that took place on the same day: Microsoft unveiled the Xbox. It's been all down hill since. Coincidence? I think not! My theory is that everybody took so long to get used to those wretched controllers that they forgot to actual pay attention to their companies. By the time they got back, things were too far out of control.
mod parent up, that's exactly what happened to him. Just be patient the wave will subside in about a week. Most mail servers are set to bounce mail after 7 days for domains that don't exist. IT will slow down some over the next days with the last bounce happening in a few days.
Sadly, it may not subside so quickly. A couple of years ago I was really strict about reporting open relays and proxies and other spam-resenders to the ISPs responsible for the netblock on which they reside. Unfortunately, I think I sent a report to the abuse contact for some netblock that was actually controlled directly by spammers, or something like that. Ever since then, I've been under an almost constant joe-job. I don't have my mailer configured to copy postmaster on every bounce, but I see all sorts of bounce delivery attempts every day to accounts that have never existed.
All I can think of is that it's an ongoing attempt to discredit my domain. I'm sure they're not targetting me specifically at this point, but have simply added my domain to a list of domains from which they send their forged mail.
I didn't say Sun had to leave - just that they will.
Maybe. Then again, I used to work for a company that produced interactive GUI builders for Motif that somehow manages to still exist, despite being horribly managed and selling products that target an ever shrinking market share. If they can survive, so can Sun, even if they continue to dwindle in significance. (Honestly at this point I think my old company's most valuable asset is its domain name.)
I wouldn't mind having them around to do R&D either - as long as the results benefited other people as well as Sun.
Which is certainly the case now. They're very active in the IETF and other standards bodies. And even the R&D that they keep in house benefits society as a whole on some level. At the very least, it's another source of ideas that are available to the greater community. Even if the code they write is restricted, the ideas they come up with will be available to us (unless they go down the patent road, which would be everybody's loss)
As for software monocultures, I doubt that Linux will ever be entirely a monoculture, even allowing for the LSB, certainly not to the degree that Windows is (if you don't count the fact that down-versions of Windows can't even interoperate well with current versions, as I discovered last night trying to get Windows 98 to talk to Windows Xp).
The thing is, that's basically the same argument that Microsoft uses when they claim that there isn't a Windows monoculture. They say that there are enough versions of Windows out there that are different enough to provide enough variety to be safe from the effects that Geer described in his document. I don't think the various distributions protect Linux from the monoculture problem any better than the different versions of Windows protect it from monoculture. Certainly there are attacks that target a particular distribution or a particular version of Windows, but then there are others that target the fundamental design of the OS. For example, due to the design of its malloc() function, FreeBSD (presumably other BSDs) is completely immune to the class of double-free vulnerabilities that have shown up in widespread packages under Linux. Distributions don't protect against that kind of vulnerability, but lower level implementation and design differences do. It would be a shame to lose this diversity if Linux ends up owning the entire market for Unix-like systems.
If they had been smart five years ago, they (and HP and IBM) would have ditched their proprietary Unix platforms and handed over the enterprise features to Linux (like SGI did with their file system) and concentrate on adding value with system management tools. They would have had a prayer of competing with Microsoft then.
Yeah, look where that got SGI.
In ten years, the only people running any other Unix OS except Linux will be the same sort of people who still run IBM System/3 minicomputers.
Funny, I thought software monocultures were a bad thing.
Personally, while a run a decent-sized enterprise on Linux, I'm a fan of Solaris and hope it sticks around. I believe that Sun's R&D contributions benefit the Internet community as a whole, and I think they're products are some pretty damn good stuff. We're better of with Sun around than without them.
For another, what does Solaris have that Linux doesn't? Large scale SMP? That monstrously large ZFS filesystem? dtrace? Okay, so that stuff gets ported. Other than that, why Solaris?
With that in mind, do you honestly think that Sun will release Solaris under a GPL compatible license? Of course they won't. They see Linux as a competitor. They see those technologies that you just mentioned as their big competitive advantage. They're not going to let those technologies be ported to Linux. They may be Sun, but that doesn't mean they're completely stupid.
Actual "Internet2" access is still restricted to researchers (so Joe DormLover is not "logging into" internet2, his packets are going through a tunnel, invisible to him).
That's really not true. Traffic flows over I2 based on the BGP routing tables on the site border. Thus, it's really only the destination IP address that determines whether or not a packet goes over I2 or over a commercial link. If you're sitting at, say, umich.edu and you want to send a packet to mit.edu, it's going over I2, because that's what the routing tables say to do with it. No tunnels are involved. There's no special "other" I2 that is off-limits to your average I2 user.
Would it be under heavy load if we didn't slashdot the poor thing?
Re:Oh Debian, I don't know what to think
on
Updates From Debian
·
· Score: 2, Insightful
I don't agree. I've been using Debian unstable for years, and I can't remember the last time something broke. YMMV etc of course. I've gotten so bored that I've started installing experimental packages in hopes to finally get something to break.
Sure, unstable is fine if you only have one machine, but what about those of us who want to deploy Debian enterprise-wide? Debian provides a wonderful framework for us, but no suitable distribution. Stable is at this point too old even for our servers (we run it, but with several backports and locally packaged addons) and is completely out of the question for client workstations. Testing and unstable are no better, because they're constantly moving targets. A machine installed today might look very different from a machine installed yesterday.
it sounds like you're referring to reiserfs as not compatible with programs? The only types of programs that wouldn't be compatible with reiser4 would be things like fsck that are designed for a file system.
Well, the Reiser4 plugin infrastructure allows for more functionality to be added to the filesystem. Depending on the plugins created, the processes accessing this filesystem may need to know about them. E.g. GNU tar is incapable of preserving extended attributes and ACLs when copying data. Or look at the NTFS streams feature. This kind of thing needs at least some support in userspace, or else it can't be accessed.
It will very much be possible for people to write code that needs to run on Reiser4 in order to work properly. It will be interesting to see if this happens, and if so, how widely adopted it becomes. I think there's a lot of potential here, but I understand how people might be reluctant...
In other words: When people find collisions (two different datasets that result in the exact same digest), then that is the first step towards being able to "reverse" the digest process, and extract the original data from the digest, thus rendering the encryption useless.
No. Completely and utterly wrong. The consequence here is not to "decrypt" a hash. It's a hash, not an encryption. Hashes are used to verify the integrity of the input. That's why you see your favorite Linux distributer release MD5 hashes of the official.iso images of their distribution. The hashes allow you to verify that the ISO image you're downloading is identical to the one they intended to distribute, and has not been secretly replaced by some malicious party. Nothing is encrypted; you have the original data and don't need to decrypt anything to get at it. You don't even need to verify the checksum if you don't want to.
The consequence here is that if SHA-n or MD5 is broken, then somebody could conceivably release an ISO image that contained different data (e.g. a trojan) but still matched the MD5 sum of the original image.
The reason I don't think this will be of huge consequence to most users is that it's normal to have either multiple hashes of a single file or other traits that you can look at that will tell you if the data is what you expected. So in theory, yes, maybe it is possible for you to find some data that results in the same MD5 checksum as the Debian woody CD1 ISO image, but the likelihood that that data will consist of a valid ISO9660 filesystem that bears any resemblance to the original is very, very, very slim.
AFAIK, TurboLinux is/was one of the bigger PPC Linux distros.
I think you know wrong, then. Dig around a bit on TurboLinux.com. They support x86, and that's about it. There were some mentions of amd64, but certainly no powerpc either under the "supported hardware" or "download" sections of their site.
TurboLinux's claim to fame has always been good Asian language support, which is evident on their site.
The fact that backports.org exists is a clear example of why debian is still relevant, despite the unpopular release phylosophy.
I use backports.org myself in some situations. I still think that needs to exist only because Debian has failed to meet the needs of a large portion of its user community.
I think what backports.org really shows is that people want to use Debian. The Debian system infrastructure is very flexible and powerful. But the users of backports.org can't use Debian because the software doesn't meet their needs (lacks functionality, is buggy, or doesn't interoperate with the newer versions that everybody else in the known universe upgraded to last year), so instead they must use software that is packaged to use the same infrastructure as Debian software, but is not Debian.
I agree, for the most part, but I personally haven't had any trouble mixing a small handful of packages from sarge with a mostly woody-based distro.
Try maintaining that in an enterprise setting. It almost reaches the point where you're maintaining a whole distribution yourself.
For those who claim that woody is still OK on a server, here's small list of the server packages that I've found that argue against that:
Exim
Apache
OpenSSL (obscure bugs present in 0.9.6 are fixed in 0.9.7, but that won't ship with a stable Debian release for another year or more, according to AJ's announcement.)
Cyrus IMAP
net-snmp
OpenAFS
Horde/IMP, etc
Those are the packages that have annoyed me on the server side of things. Note that those are just about all the reasons we run servers at this site. I don't doubt that we'd run in to yet more painfully outdated software if we tried to run more services.
And have you recently looked at the list of backported server related packages on backports.org? The fact that such a site even exists speaks to Debian's failure to produce a release that is both stable and functional (by stable I mean "not changing daily", not "not crashing").
I use Debian. I use it everywhere. Most of the infrastructure (both server and workstation) at my workplace runs on it. I use Debian at home. I am a Debian developer and work to improve it where possible. I use it and develop for it because I want a system that doesn't suck. For a long time, Debian sucked less than anything else out there. It's sucking harder and harder, though, and I'm honestly starting to wonder how long it's going to be before it starts surpassing the other options available to me.
Debian needs a change in its release philosophy, or it will stop being useful on production systems at my site and undoubtedly at others.
It still seems a bit too much of a coincidence, gnu going down exactly on the day on which (for example) debian.lcs.mit.edu was also unreachable, and the admins warned us about machines moving. Perhaps gnu.org was being hosted at LCS, but was transferred to a hosting company to coincide with the Stata move-in? Anybody know its hosting status from a few weeks ago?
gnu.org hasn't been hosted at MIT in years. Seriously.
Debian.lcs.mit.edu was moved on Sunday, 3/14. It was down for maybe between 4 and 6 hours. If you saw any other downtime, it was coincidental (perhaps related to the upstream ISP issues I mentioned previously.)
noah
(one of the sysadmins responsible for moving all these machines)
Sorry, let me clarify, for those who don't know how to use whois. 199.232.76.164 is not owned by MIT. It is owned by cent.net, the Cambridge Entrepreneurial Network.
I posted a link to gnu.org in one of last week's stories...but it was down - for atleast 2-3 days. A reply to my comment explained that it was because gnu.org is down because the MIT CSAIL (Comp Sci and AI Lab), was moving to The Stata Center.
Nope. gnu.org is not hosted at MIT at all:
$ host gnu.org<br> gnu.org has address 199.232.76.164
Dunno why gnu.org was down, but it didn't have anything to do with MIT. The outtages here were very short during the move. Only slightly longer last night due to some peering hosage, but certainly not on the order of 2-3 days.
Slashdot Mirror
Actually, I gather it does work. There have been some posts to the FAI mailing lists detailing the steps needed to make it install, and they seemed rather straightforward. Hell, if you can install Solaris with FAI, I'm sure you can install Ubuntu!
noah
But suggestions for improving the release cycle are posted to -devel all the time.
A lot of times, getting together for a high-bandwidth discussion really is the only way to get something done. Most of the other suggestions or proposals posted to the mailing list are not nearly as well thought out as this one, and the discussions quickly degenerate into flamewars because the people offering the proposal didn't think through all the various ways that their proposal would be interpreted. The current proposal was made by people who have been involved in Debian for many years and who understand the release process better than anybody else in the world.
I think it's unfortunate that there are so many people in Debian who feel that every decision must involve everybody all the time. Debian is just too big for that to work. Given that the entire community feels that Debian's release cycle is too long, I believe it is up to the release team to fix the problem as they see fit. The fix may need to be drastic, and it's the release team that knows best. Let them get together and come up with a "Here's what the release team wants to change" document, and go from there.
noah
We already use FAI. It has installed over 200 hosts for us. It's a nice system, and makes enterprise deployment possible (doing several hundred stand-alone installs is simply unreasonable, IMHO), but it doesn't eliminate any of the problems with Debian releases. Maintaining local snapshots of sarge is somewhat helpful, but then you're awfully close to running your own distribution. You have to be very aware of what's going to change when you update the snapshot. Unless you plan on updating the entire snapshot periodically, you are going to have to worry about dependencies and various package relationship problems. But if you update the whole snapshot, then you've got to be sure that the new packages aren't going to hose your existing machines, or otherwise interfere with the general user experience.
noah
Dude, input from the community is exactly what's happening on -devel right now. What's wrong with some developers (who have official duties delegated by the DPL) getting together to hash out a proposal for a change to the system? If an individual had come up with this proposal on his own and posted it to -devel-announce, would that make it better?
Working together to solve a major problem like the Debian release policy is something that can often be performed much much better when done face to face. I applaud the initiative and dedication shown by these guys, and think the proposal is a damn fine start. I have no doubt that whatever change finally does happen post sarge will be different (perhaps dramatically so) from what was proposed today. There will absolutely be community involvement in determining the final course of action.
noah
Sure, you run sid. You know what that means? It means that this proposal won't affect you at all. (additionally, I'm sure you run x86, along with what, 98% of all other debian users?)
The thing is, you're the type of user who doesn't need predictable release cycles. You can get by on the bleeding edge and run software for which a new package release may be uploaded on any given day.
A lot of Debian users are in very different positions. I, for example, run Debian in an enterprise environment, with literally hundreds of servers and workstations. woody is simply not an option in this environment. Hardware support (both kernel and user space) is dreadfully lacking, and we'd have to backport most of the software we use every day anyway. We'd end up running something so bastardized that we'd no longer see many of the benefits of running Debian at all. So we were forced to go with something more current. We chose sarge, with the understanding that we'd have to be responsible for the security of our systems, with little help from Debian. But of course, there are problems there, too. Sarge changes every day. A machine installed today may look nothing like a machine installed tomorrow. Additionally, we simply have no way of knowing when sarge will be released. The saying within Debian has always been "we'll release when it's ready", but of course, there's never a published metric for readiness, so there's simply no way of knowing when that will be.
Basically, right now, Debian really doesn't have a good release for enterprise users. That really sucks, since IMHO Debian provides a software infrastructure that makes it really appealing for large scale deployments. I really hope this new proposal is a step toward a shorter and more predictable release cycle!
noah
(Debian developer, sysadmin, and user since 1997)
noah
Sadly, it may not subside so quickly. A couple of years ago I was really strict about reporting open relays and proxies and other spam-resenders to the ISPs responsible for the netblock on which they reside. Unfortunately, I think I sent a report to the abuse contact for some netblock that was actually controlled directly by spammers, or something like that. Ever since then, I've been under an almost constant joe-job. I don't have my mailer configured to copy postmaster on every bounce, but I see all sorts of bounce delivery attempts every day to accounts that have never existed.
All I can think of is that it's an ongoing attempt to discredit my domain. I'm sure they're not targetting me specifically at this point, but have simply added my domain to a list of domains from which they send their forged mail.
noah
Maybe. Then again, I used to work for a company that produced interactive GUI builders for Motif that somehow manages to still exist, despite being horribly managed and selling products that target an ever shrinking market share. If they can survive, so can Sun, even if they continue to dwindle in significance. (Honestly at this point I think my old company's most valuable asset is its domain name.)
I wouldn't mind having them around to do R&D either - as long as the results benefited other people as well as Sun.
Which is certainly the case now. They're very active in the IETF and other standards bodies. And even the R&D that they keep in house benefits society as a whole on some level. At the very least, it's another source of ideas that are available to the greater community. Even if the code they write is restricted, the ideas they come up with will be available to us (unless they go down the patent road, which would be everybody's loss)
As for software monocultures, I doubt that Linux will ever be entirely a monoculture, even allowing for the LSB, certainly not to the degree that Windows is (if you don't count the fact that down-versions of Windows can't even interoperate well with current versions, as I discovered last night trying to get Windows 98 to talk to Windows Xp).
The thing is, that's basically the same argument that Microsoft uses when they claim that there isn't a Windows monoculture. They say that there are enough versions of Windows out there that are different enough to provide enough variety to be safe from the effects that Geer described in his document. I don't think the various distributions protect Linux from the monoculture problem any better than the different versions of Windows protect it from monoculture. Certainly there are attacks that target a particular distribution or a particular version of Windows, but then there are others that target the fundamental design of the OS. For example, due to the design of its malloc() function, FreeBSD (presumably other BSDs) is completely immune to the class of double-free vulnerabilities that have shown up in widespread packages under Linux. Distributions don't protect against that kind of vulnerability, but lower level implementation and design differences do. It would be a shame to lose this diversity if Linux ends up owning the entire market for Unix-like systems.
noah
Yeah, look where that got SGI.
In ten years, the only people running any other Unix OS except Linux will be the same sort of people who still run IBM System/3 minicomputers.
Funny, I thought software monocultures were a bad thing.
Personally, while a run a decent-sized enterprise on Linux, I'm a fan of Solaris and hope it sticks around. I believe that Sun's R&D contributions benefit the Internet community as a whole, and I think they're products are some pretty damn good stuff. We're better of with Sun around than without them.
noah
You do realize that one can write drivers for a closed-source OS, don't you? See http://developers.sun.com/solaris/articles/writing dev.html for some intro Solaris driver writing docs.
Drivers are no more likely to "appear" for an open source OS as they are for a closed source OS.
noah
With that in mind, do you honestly think that Sun will release Solaris under a GPL compatible license? Of course they won't. They see Linux as a competitor. They see those technologies that you just mentioned as their big competitive advantage. They're not going to let those technologies be ported to Linux. They may be Sun, but that doesn't mean they're completely stupid.
noah
Please install Debian 3.0 next!
noah
Yup. See Ars Technica's article on the Pentium M for more details: http://arstechnica.com/articles/paedia/cpu/pentium -m.ars
noah
That's really not true. Traffic flows over I2 based on the BGP routing tables on the site border. Thus, it's really only the destination IP address that determines whether or not a packet goes over I2 or over a commercial link. If you're sitting at, say, umich.edu and you want to send a packet to mit.edu, it's going over I2, because that's what the routing tables say to do with it. No tunnels are involved. There's no special "other" I2 that is off-limits to your average I2 user.
noah
Would it be under heavy load if we didn't slashdot the poor thing?
Sure, unstable is fine if you only have one machine, but what about those of us who want to deploy Debian enterprise-wide? Debian provides a wonderful framework for us, but no suitable distribution. Stable is at this point too old even for our servers (we run it, but with several backports and locally packaged addons) and is completely out of the question for client workstations. Testing and unstable are no better, because they're constantly moving targets. A machine installed today might look very different from a machine installed yesterday.
noah
Well, the Reiser4 plugin infrastructure allows for more functionality to be added to the filesystem. Depending on the plugins created, the processes accessing this filesystem may need to know about them. E.g. GNU tar is incapable of preserving extended attributes and ACLs when copying data. Or look at the NTFS streams feature. This kind of thing needs at least some support in userspace, or else it can't be accessed.
It will very much be possible for people to write code that needs to run on Reiser4 in order to work properly. It will be interesting to see if this happens, and if so, how widely adopted it becomes. I think there's a lot of potential here, but I understand how people might be reluctant...
noah
No. Completely and utterly wrong. The consequence here is not to "decrypt" a hash. It's a hash, not an encryption. Hashes are used to verify the integrity of the input. That's why you see your favorite Linux distributer release MD5 hashes of the official .iso images of their distribution. The hashes allow you to verify that the ISO image you're downloading is identical to the one they intended to distribute, and has not been secretly replaced by some malicious party. Nothing is encrypted; you have the original data and don't need to decrypt anything to get at it. You don't even need to verify the checksum if you don't want to.
The consequence here is that if SHA-n or MD5 is broken, then somebody could conceivably release an ISO image that contained different data (e.g. a trojan) but still matched the MD5 sum of the original image.
The reason I don't think this will be of huge consequence to most users is that it's normal to have either multiple hashes of a single file or other traits that you can look at that will tell you if the data is what you expected. So in theory, yes, maybe it is possible for you to find some data that results in the same MD5 checksum as the Debian woody CD1 ISO image, but the likelihood that that data will consist of a valid ISO9660 filesystem that bears any resemblance to the original is very, very, very slim.
noah
I think you know wrong, then. Dig around a bit on TurboLinux.com. They support x86, and that's about it. There were some mentions of amd64, but certainly no powerpc either under the "supported hardware" or "download" sections of their site.
TurboLinux's claim to fame has always been good Asian language support, which is evident on their site.
noah
I use backports.org myself in some situations. I still think that needs to exist only because Debian has failed to meet the needs of a large portion of its user community.
I think what backports.org really shows is that people want to use Debian. The Debian system infrastructure is very flexible and powerful. But the users of backports.org can't use Debian because the software doesn't meet their needs (lacks functionality, is buggy, or doesn't interoperate with the newer versions that everybody else in the known universe upgraded to last year), so instead they must use software that is packaged to use the same infrastructure as Debian software, but is not Debian.
noah
Try maintaining that in an enterprise setting. It almost reaches the point where you're maintaining a whole distribution yourself.
For those who claim that woody is still OK on a server, here's small list of the server packages that I've found that argue against that:
Those are the packages that have annoyed me on the server side of things. Note that those are just about all the reasons we run servers at this site. I don't doubt that we'd run in to yet more painfully outdated software if we tried to run more services.
And have you recently looked at the list of backported server related packages on backports.org? The fact that such a site even exists speaks to Debian's failure to produce a release that is both stable and functional (by stable I mean "not changing daily", not "not crashing").
I use Debian. I use it everywhere. Most of the infrastructure (both server and workstation) at my workplace runs on it. I use Debian at home. I am a Debian developer and work to improve it where possible. I use it and develop for it because I want a system that doesn't suck. For a long time, Debian sucked less than anything else out there. It's sucking harder and harder, though, and I'm honestly starting to wonder how long it's going to be before it starts surpassing the other options available to me.
Debian needs a change in its release philosophy, or it will stop being useful on production systems at my site and undoubtedly at others.
noah
Ohh, and I can prove it, thanks to the magic of netcraft! See http://uptime.netcraft.com/up/graph/?host=gnu.org Gnu.org hasn't been on an MIT-owned IP address since Nov. 1 2000, at the latest.
I should be lest hasty in my posts so I don't have to keep replying to myself...
noah
gnu.org hasn't been hosted at MIT in years. Seriously.
Debian.lcs.mit.edu was moved on Sunday, 3/14. It was down for maybe between 4 and 6 hours. If you saw any other downtime, it was coincidental (perhaps related to the upstream ISP issues I mentioned previously.)
noah
(one of the sysadmins responsible for moving all these machines)
noah
Nope. gnu.org is not hosted at MIT at all:
Dunno why gnu.org was down, but it didn't have anything to do with MIT. The outtages here were very short during the move. Only slightly longer last night due to some peering hosage, but certainly not on the order of 2-3 days.
noah