Slashdot did answer your question, if you'd take enough care to read the blurb that's there. This is the revised license, not the original.
From reading it, it appears to be Debian Free Software Guidelines compliant also, or at least that's my interpretation. I'm pretty sure that the old license required you to either assign copyright of your work to Lucent, or send them changes (or both), but it's been years since I read the original Plan9 license.
If you read the thread, and I do mean read it, you might notice that Reiser doesn't actually tell anyone what the problem is. Is it the accidental removal of credits from a file? Or is it the deliberate disabling of the long credits list during a program execution? Reiser doesn't tell anyone, because he'd rather throw a tantrum than actually solve whatever problem he's having. There's nothing direct and to the point about what he wrote at all.
Oh... and no one changed his license. It's the GPL, you can change it how you like. Since Reiser decided to implement ReiserFS in Linux, he was bound by the GPL and all it enatils. If he doesn't like its terms, he can write his own kernel or use another. The Debian people were fully within their rights to change the program however they wanted. It might not have been perfectly civil, but then again, it's tough to correct your mistakes when you aren't being told what they are. Besides, the credits list generally belongs in the README or copyright files, not at the launch of the fucking program. Would you like ls or cp to display a credit list every time they're run?
And finally, Reiser decided to come out and bash the whole of the Debian project for something the maintainer himself did. Reiser never directly contacted the maintainer about the issue, but rather chose to vent on debian-devel, calling everyone in the project plagiarists. He can throw out Stallman's name all he wants, but that doesn't make him any more correct. His little tantrum certaintly doesn't represent the people he claims to be standing up for very well.
Ok, I didn't know that it was required to set up all your USE variables. I figured that you could just set up the ones you wanted and leave the rest as default (./configure works well enough by itself usually). I'd bet you're right about the aggressive compiler flags over the USE variables, but since you always hear about how much faster gentoo is, I'd be surprised if all the aggressive compilation didn't cause unreproducible bugs.
The Debian Fundamentals Are Changing
on
Gentoo Reviewed
·
· Score: 1
The incredible explosion of unnoficial apt sources lately has been nothing short of amazing to me. I've been a Debian user for years, and I've always run unstable, and this is the kind of developement is incredibly underplayed outside of Debian, and even within it to a large degree. Debian is a community-based distro, and the users are finally waking up and really seeing this fact and going and doing their own backports based on the work of the official developers. Everyone can be a part of Debian, even if they aren't a developer, and backports are a fantastic way of doing your part while helping yourself.
Debian evolves because it has to. The last paragraph in the review hit me hard because it's true, but I think in a year or two it won't be quite so bad, simply because Debian will have changed. It'll be fundamentally the same, but with small changes that often don't go announced, like unofficial apt sources or a new project on alioth, the thought process of using and creating the distro will change.
Gentoo vs. Debian
on
Gentoo Reviewed
·
· Score: 3, Insightful
I see gentoo as being very fast moving right now, and still small compared to Debian. Once they reach the peak of their growth curve as Debian seems to have, they're going to run in to the same sorts of problems that Debian has had to face.
Debian spends a lot of time making incremental improvements to the distro. Find bugs and fix them, move on. Find more bugs and fix them. Rewrite the installer because it's buggy. Rework the package classification system because it's gotten unwieldy. These are exciting things that are going on in Debian that might not be innovative or exciting enough for Larry the Cow, but then again, real innovation requires a lot of unglamorous grunt work.
It'll also be interesting to see if the userbase for gentoo remains as friendly as they are reputed to be. Most small projects are friendly because everyone is of like mind, but once it grows beyond a certain bounds, things can get tense. Debian has, unfortunately, suffered from this, although it varies. The debian-user mailing list tends to be very friendly and useful, and the IRC channel can be as well, depending on who is in it at the time. I honestly hope having gentoo get some of the spotlight from Debian will cause some positive change in Debian. Gentoo obviously was heavily inspired by Debian (Social Contract) and it'll be interesting to see how both distros influence each other as they develop.
I'm hoping we wind up with plenty of killer geek distros personally, and I hope I'm not the only one.
Around Christmas, there was a big thread on the Debian-devel mailing list titled "Are we losing users to Gentoo?". I went back and re-read it last night, and I came across an interesting point. Debian developers were toying with the idea of officially supporting custom compilation options in the various package building tools out there (apt-src, apt-build). One point that came up was that when you're trying to build a stable software platform, you've got to be able to debug. In order to do so, you've got to have reproducible bugs. With all the custom compilation options, how can you hope to reproduce the bugs if everyone is customizing the hell out of their binaries? I see a lot of posts about how great emerge is, but my question to the gentoo users out there is how often do you actually use custom options on your compilations? Do you really pass a lot of specific flags to different compilations, or do you just do a ton of generic emerge's? I can't help but wonder if a lot of the people who say gentoo is really stable just aren't using that much of the real customization options that it offers over apt.
I actually tried to scan the bugzilla database for gentoo last night too, to see if this kind of effect would be prevelant, but I don't know bugzilla well enough to really look through it. Do bugs like this pop up, and if so, do they usually get resolved?
Standardization of what? This project doesn't really have much to do with that, although that will hopefully be a side benefit. The main thing is that it's a resource for Debian developers to use in collaboratively working on their apps, which will be nice. I think this'll be really outstanding for documentation, which is pretty much always done collaboratively.
The other thing is that it should help people who aren't official developers contribute to projects. Currently about the only thing you can do is submit a patch through the Debian Bug Tracking System and hope that the maintainer adds it. This will encourage collaborative maintainership, which is something that the project as a whole is advocating a lot these days. It'll also help a lot of people who are new contribute without packaging every little program on the net.
The other benefit, and this is where standardization can come in, is that it will provide a potential central repository for all Debian-specific items. This is a good thing, because it lets people from other projects take them and reuse them, thereby standardizing on a solution rather than reinventing the wheel. Of course, that's not guaranteed, but hopefully it'll wind up being useful.
Well, in this case, if you don't like it, you can always just use "apt-get source packagename" and grab all the source as is. You can also use the standard Debian Bug Tracking System, Mailing Lists, IRC channels, and the like.
What the hell does this have to do with Gentoo? This is meant to ease collaborative development among developers, most notably on Debian-specific programs (of which there are many), and to provide a place for people outside of Debian to go when looking for information on Debian-specific programs so that they can potentially be adopted in to other systems.
Personally, I'm really excited about this. Debian doesn't really need the former reason as much, as within itself Debian is pretty good about using Debian-specific stuff. It's the latter item that I think is good. Debian has solved a lot of problems already that could do well to be adopted in to other systems. Apt is the most notable example (and not as prevalent a one these days), but also the menu system, the debconf specification, and a massive amount of behind the scenes infrastructure that most people (even Debian users) don't acknowledge. Putting these in a place like Alioth allows more sharing. Debian states very explicitly in the Social Contract that it is about giving back to the community, and having an easy to access place helps with that very much.
So, in that sense, Alioth isn't so much about competing with Gentoo but with fulfilling the Social Contract, which has been the same old goal of Debian for many years. Nothing new there, if you've been paying attention at least.
I don't use an RPM-based distro, but don't up2date, apt4rpm, and urpmi handle just that for you? The dependency handling issue has long since been solved, and Gentoo is not the only solution. Thankfully, the whole distro landscape has been moving on to new problems as of late.
Did anyone (including the person who posted this story) actually read the article?
Because, as you know, it is of critical importance that this article be read, for all our fates rest upon the knowledge that it imparts. It's not really just something to amuse us.
The site linked is up fine right now, but the IP they give at the top as being the actual server on the fly isn't responding. Is it slashdotted? I'm picturing a smoking fly in the middle of the plastic cube. I'm just glad I don't have to smell it.
Fly Server Admin: Damn you slashdot! Damn you! You killed my baby!
And what license would this be under? I can't find it in the source files (grep -i "license" *java"), nor can I find it on the website or the message board. It'd be nice to have this in Debian, but without a license it can't be done.
How can you prove this? All you've shown from the data is that Microsoft has a lot of market share, Mac has very little, and Linux has even less as determined by this company.
How in the world can you claim that it's because we haven't standardized on Gnome or KDE? Hell, you can't because Mac has a far more standard (and superior) UI than Windows, and it's stil way below on those figures. There's far more to this than you could even think to touch on with just the Gnome and KDE split. Correlation is not causation. Come back when you've got something better.
What I would like to see, and this is off-topic, is XML menu specification. So you can download, install a program, and then install a menu item for it with whatever Window Manager you are using. It just needs a few fields. If someone wants to go with this idea and wants me to help(put my money where my mouth is) just e-mail me and I've got no problem.
Check out the debian menu system. It's not an XML spec, but the idea is that you have one program and it installs a menu using the debian system. The system then installs the menu item in every window manager on the system. It's here now and it works great. It's also user configurable.
Seriously, how much is Linux really like Windows when you get down to it? A highly user-configurable kernel? Not in Windows. A strong UNIX-like set of userland apps? Not in Windows. A powerful and flexible network-transparent windowing system? Not in windows. Exceptional package handling for every piece of software on a system a la' apt-get? Not in windows.
There are plenty of things that Windows has that Linux doesn't as well. There's a full-featured API for just about everything, and it's all standardized. There's a consistent UI. And there's things like market share and a single dominating power behind it.
If you look at this list, about the only thing on it that most people are interested in is more market share, and the folks in Debian (as one example) don't particularly seem to care a whole lot about that. They, along with the likes of Slack and Gentoo, aren't trying for a single unifying API or UI. Some people want to unify the UI but most of us wouldn't actually want to see it happen, and for good reason. I'd be pissed if someone took away my pwm in the name of everyone else.
And as for innovation, well that's a tired argument. John, like everyone else who brings it up, can sit around and whine whine whine that they don't have their new vague super UI right now, but it's a load of crap. Innovation is constantly happening on the linux side, it's just not so apparent. John can bitch about wanting a new paradigm, but unless he's willing to put up some code then it's just not going to happen. You want a MacOSX type UI? Go contribute to GNUStep and get the fundamental groundwork down. You think X sucks? Go contribute to Fresco. Ultimately, if you're going to do something in free software, in order to attract attention these days of a million and one sourceforge projects you're going to have to do something good. You can moan about how windows-like KDE is, but if that's what people want then that's what is going to get the lion's share of coder and media attention. If you want something better then no one, including the KDE team, is stopping you from making it.
Ultimately, linux innovation happens in slow stages over many years, rather than in quick bursts. It's just the nature of the beast. Gnome and KDE are racing to outdo one another in every possible area, and the users are all the beneficiaries. You can't say that these projects haven't done well for themselves. They might not have come up with the most innovative stuff, but they do each have unique ideas that aren't found in Windows, Mac, or anywhere else. Innovation also happens under the hood. I'm a Debian user, and other Debian users probably know what I'm talking about. There's things like porting all of Debian to different kernels (the HURD, NetBSD, etc.) There's incremental improvements to dpkg and apt-get, including new frontends and the like. There's the debconf system which makes a good interface for dealing with package configuration. There's things like the alternatives system and apt-src. There's other examples, but you get the picture. I know other distros also have plenty of innovations that I'm not familiar with as well and this is the entire point. Projects compete because they can coexist (as can not happen in windows) so innovation comes from the ground up rather than descending from on high every two years as Windows releases anew. Innovation does happen, but just like watching a tree grow, it's not as impressive to see in real time.
I don't really understand why it's so hard to support multiple distros. What sort of stuff are you using in your app? Well, standard library routines, so you're going to be using libstdc or libstdc++, both of which will be on any linux system. If you're creating a command line app, then you can use libreadline or libcurses, both of which will be on any linux system. If you're writing a GUI based app, you can use Gtk or Qt (or even Motif/Lesstif or Xt) and have it run on any Linux desktop. And of course you can install any custom libs you want. There's also the distinct possibility of static linking, which is frowned upon generally but doable (you could create two versions of your app, one dynamically linked for a popular distro and another static for everyone else). You can use an installer like Loki's in order to handle the placement of things and making sure that it's all there for you.
I really don't understand why everyone says it's hard to get software to run on alternate distributions. The basics are all standardized. There's standard libraries and standard routines. There's standard packaging formats that one can use, or a powerful installer. Whether you decide to use Gtk or Qt and whether you decide to put your custom apps in/usr/share/lib or/usr/local/lib is irrelevant really. Include the libs you need and the whole of it should work fine. And really, if your only concern is directory layouts, why not simply have a default install location (/usr/local/whatever is a good choice, as it's the default in auto* tarballs) and let people override them as they will. After writing a big and complex app, supporting configurable directory heirarchies (hint: one line in a.rc file and an extra string variable in your code will do it) should be the least of your worries.
That's interesting. I've rarely found the texinfo pages to be of any real use to me when a manpage fails.
I don't know how it is for other distros, but every debian package puts its documentation in/usr/share/doc/packagename. If the manpage fails me at all, this is where I go first. The documentation that came with a program is often the most useful documentation you're going to find, especially because the Readme's and the like often have a lot of quick notes in them. The changelogs have tons of good info too. Of course, to be able to use these docs requires knowing what program you're looking for in the first place, which requires some experience, but it's by far the most useful documentation that's physically on my system.
Debian is using outdated software (KDE 2.2, Gnome 1.2), an outdated kernel (2.2).
For stable, yes, but that's stable. If you're running stable, you probably want the most rock-solid software you can get. KDE3 and Gnome2 aren't rock-solid yet and kernel 2.2 is very well proven (and still maintained). Kernel 2.4 is an install option for stable as well, by the way. Plus, nothing is stopping you from installing your own up to date kernel on Debian.
It has NO compelling features, whats the point of apt-get if you cant get good software for it.
It has the largest number of supported platforms of any Linux distro, which is great if you've got a Sparc or an old Power Mac lying around.
It has three branches (stable, testing, unstable) so you can choose your ratio of features to stability.
It has a large community of users to give support.
Each software package acts as a personal liason to upstream authors of software so you can get wishlist requests in and solid bugreports dealt with in a reasonable manner.
It has a completely open development process so you can see everything and even participate if you want.
It has a clearly defined and actively updated policy that provides standardization throughout the system (any package that violates policy is buggy by the way, and is treated as such).
It has an army of developers over a thousand strong who maintain "more than 8710 packages" to make this distribution the largest (what was that about no good software?)
Theres gentoo for the geeks
There was a long and drawn out discussion about this on the debian-devel mailing list. If you want to sit around compiling your entire system from scratch, you're welcome to, but note that you can do this in Debian too, and keep things packaged. There's the apt-src package that will do this and keep all the debian stuff you love. This program hasn't had the most active development in the past (the author is one of Debian's best developers and contributes all over the place) but you can be sure it'll be improved soon. Plus, say what you will about Debian's install, it's way easier than gentoo's manual bootstrap method.
Besides, the majority of apps won't benefit from custom compilation enough to make it worth the time.
lycoris/lindows for people who think the internets aol
This traditionally hasn't been Debian's focus at all, but hopefully the desktop subproject will change that once it really gets going. And as for Lindows, it's based on Debian itself. Debian does serve as a fantastic platform for other people to build systems on.
theres red hat for server stuff
I'm sorry, but if you put Debian stable vs. Redhat on the server you'll find Debian wins out everywhere that it needs to including upgrades and stability. Redhat gives you corporate support if you pay for it, which is a definite advantage when you need to cover your ass or you're ignorant. There's something to be said for a name brand, that's for sure.
suse for destkop work, and mandrake for multimedia and fun
The desktop project will hopefully work on this. I personally do just fine having fun and using multimedia on my Debian desktop system, but maybe that's just me and the thousands of other users like me.
Why dosent the team just fuckget about linux and concetrate on the turd
Well, there's the HURD subproject in the works, as well as a NetBSD port. None of the other distros you mentioned have that. The reason for that is that Debian is far more than a Linux distribution, it's a whole project devoted to making a great system. This system can be ported to other kernels and other architectures. It's flexible and has the underlying infrastructure (like autobuilders and debbugs database) to handle this task. It's got the large quantity of manpower and the policies in place for managing it. Debian isn't a corporation, so it doesn't work the same way as Redhat, Mandrake, SuSE, and the rest. The closest one to it is Gentoo, and it's no mistake that Gentoo modeled its social contract on that of Debian.
Debian isn't the be all end all by any means. But it's an amazing project that moves at its own pace. While everyone else is worried about pretty installers, Debian is working on supporting computers that no one else supports. While everyone else is worried about grabbing the largest userbase, Debian is working on making the best system that the developers can put together. It just works differently than other distros. This doesn't make it obsolete, it makes it impressive.
What most people are going to think of when they see this is that this will make Debian's install more friendly. While this is very likely to happen, there are going to be other major benefits to this project.
The main one is that this will completely replace the old boot-floppies software that previous releases were based on. boot-floppies was, by all accounts, a major pain to deal with. For the release of woody, the installer was supposed to be re-written, but people complained and it was decided to "just" update boot-floppies once again for woody so that the release could get out the door quickly. This update took an extremely long time, so woody took a lot longer to release.
Sarge is largely waiting on debian-installer to be in good shape to release. No one, and I do mean no one, is willing to work on boot-floppies any more. I've never personally looked at the code, but I know it's just not worth it. debian-installer is modular and will provide the ability to have multiple frontends. The only one in place right now is the text-based frontend, so it's even uglier than the boot-floppies UI right now, but GTK and S-Lang frontends are in the works. Either way, the modularity of the new system will hopefully make it easier to update for new stable releases. boot-floppies was really holding things back there, much to everyone's dismay.
The other thing of note is that the entire installer is based on the debconf system (well, a rewritten C version of it actually), which is Debian's standard configuration backend. There are multiple frontends, like Gnome, Dialog (curses), and text-based for it, and it's in heavy use in Debian right now. It's a good system that's worked well, and using it in the installer will encourage even more standardization in an already fairly coherent distro.
As for this alpha, it only supports i386 right now. I don't know how far along the porting efforts are to other arch's, but a new Debian release won't happen until it's been ported everywhere that it needs to be. Still, the installer team has done a great job, and this is a project that the Debian community really should be paying close attention to.
Progeny's installer (known as PGI) doesn't work on non-x86 archs (it may work on PPC, but not on the majority of the arch's that Debian supports). From what I understand, there's no movement towards porting it to other arch's, either because it's difficult or people aren't interested in doing so. Anthony Towns (the Release Manager for Debian) basically just wants a working installer, and debian-installer is what people are actually working on.
Slashdot Mirror
Slashdot did answer your question, if you'd take enough care to read the blurb that's there. This is the revised license, not the original.
From reading it, it appears to be Debian Free Software Guidelines compliant also, or at least that's my interpretation. I'm pretty sure that the old license required you to either assign copyright of your work to Lucent, or send them changes (or both), but it's been years since I read the original Plan9 license.
If you read the thread, and I do mean read it, you might notice that Reiser doesn't actually tell anyone what the problem is. Is it the accidental removal of credits from a file? Or is it the deliberate disabling of the long credits list during a program execution? Reiser doesn't tell anyone, because he'd rather throw a tantrum than actually solve whatever problem he's having. There's nothing direct and to the point about what he wrote at all.
Oh... and no one changed his license. It's the GPL, you can change it how you like. Since Reiser decided to implement ReiserFS in Linux, he was bound by the GPL and all it enatils. If he doesn't like its terms, he can write his own kernel or use another. The Debian people were fully within their rights to change the program however they wanted. It might not have been perfectly civil, but then again, it's tough to correct your mistakes when you aren't being told what they are. Besides, the credits list generally belongs in the README or copyright files, not at the launch of the fucking program. Would you like ls or cp to display a credit list every time they're run?
And finally, Reiser decided to come out and bash the whole of the Debian project for something the maintainer himself did. Reiser never directly contacted the maintainer about the issue, but rather chose to vent on debian-devel, calling everyone in the project plagiarists. He can throw out Stallman's name all he wants, but that doesn't make him any more correct. His little tantrum certaintly doesn't represent the people he claims to be standing up for very well.
Ok, I didn't know that it was required to set up all your USE variables. I figured that you could just set up the ones you wanted and leave the rest as default (./configure works well enough by itself usually). I'd bet you're right about the aggressive compiler flags over the USE variables, but since you always hear about how much faster gentoo is, I'd be surprised if all the aggressive compilation didn't cause unreproducible bugs.
The incredible explosion of unnoficial apt sources lately has been nothing short of amazing to me. I've been a Debian user for years, and I've always run unstable, and this is the kind of developement is incredibly underplayed outside of Debian, and even within it to a large degree. Debian is a community-based distro, and the users are finally waking up and really seeing this fact and going and doing their own backports based on the work of the official developers. Everyone can be a part of Debian, even if they aren't a developer, and backports are a fantastic way of doing your part while helping yourself.
Debian evolves because it has to. The last paragraph in the review hit me hard because it's true, but I think in a year or two it won't be quite so bad, simply because Debian will have changed. It'll be fundamentally the same, but with small changes that often don't go announced, like unofficial apt sources or a new project on alioth, the thought process of using and creating the distro will change.
I see gentoo as being very fast moving right now, and still small compared to Debian. Once they reach the peak of their growth curve as Debian seems to have, they're going to run in to the same sorts of problems that Debian has had to face.
Debian spends a lot of time making incremental improvements to the distro. Find bugs and fix them, move on. Find more bugs and fix them. Rewrite the installer because it's buggy. Rework the package classification system because it's gotten unwieldy. These are exciting things that are going on in Debian that might not be innovative or exciting enough for Larry the Cow, but then again, real innovation requires a lot of unglamorous grunt work.
It'll also be interesting to see if the userbase for gentoo remains as friendly as they are reputed to be. Most small projects are friendly because everyone is of like mind, but once it grows beyond a certain bounds, things can get tense. Debian has, unfortunately, suffered from this, although it varies. The debian-user mailing list tends to be very friendly and useful, and the IRC channel can be as well, depending on who is in it at the time. I honestly hope having gentoo get some of the spotlight from Debian will cause some positive change in Debian. Gentoo obviously was heavily inspired by Debian (Social Contract) and it'll be interesting to see how both distros influence each other as they develop.
I'm hoping we wind up with plenty of killer geek distros personally, and I hope I'm not the only one.
Around Christmas, there was a big thread on the Debian-devel mailing list titled "Are we losing users to Gentoo?". I went back and re-read it last night, and I came across an interesting point. Debian developers were toying with the idea of officially supporting custom compilation options in the various package building tools out there (apt-src, apt-build). One point that came up was that when you're trying to build a stable software platform, you've got to be able to debug. In order to do so, you've got to have reproducible bugs. With all the custom compilation options, how can you hope to reproduce the bugs if everyone is customizing the hell out of their binaries? I see a lot of posts about how great emerge is, but my question to the gentoo users out there is how often do you actually use custom options on your compilations? Do you really pass a lot of specific flags to different compilations, or do you just do a ton of generic emerge's? I can't help but wonder if a lot of the people who say gentoo is really stable just aren't using that much of the real customization options that it offers over apt.
I actually tried to scan the bugzilla database for gentoo last night too, to see if this kind of effect would be prevelant, but I don't know bugzilla well enough to really look through it. Do bugs like this pop up, and if so, do they usually get resolved?
Standardization of what? This project doesn't really have much to do with that, although that will hopefully be a side benefit. The main thing is that it's a resource for Debian developers to use in collaboratively working on their apps, which will be nice. I think this'll be really outstanding for documentation, which is pretty much always done collaboratively.
The other thing is that it should help people who aren't official developers contribute to projects. Currently about the only thing you can do is submit a patch through the Debian Bug Tracking System and hope that the maintainer adds it. This will encourage collaborative maintainership, which is something that the project as a whole is advocating a lot these days. It'll also help a lot of people who are new contribute without packaging every little program on the net.
The other benefit, and this is where standardization can come in, is that it will provide a potential central repository for all Debian-specific items. This is a good thing, because it lets people from other projects take them and reuse them, thereby standardizing on a solution rather than reinventing the wheel. Of course, that's not guaranteed, but hopefully it'll wind up being useful.
Well, in this case, if you don't like it, you can always just use "apt-get source packagename" and grab all the source as is. You can also use the standard Debian Bug Tracking System, Mailing Lists, IRC channels, and the like.
I'll bite.
What the hell does this have to do with Gentoo? This is meant to ease collaborative development among developers, most notably on Debian-specific programs (of which there are many), and to provide a place for people outside of Debian to go when looking for information on Debian-specific programs so that they can potentially be adopted in to other systems.
Personally, I'm really excited about this. Debian doesn't really need the former reason as much, as within itself Debian is pretty good about using Debian-specific stuff. It's the latter item that I think is good. Debian has solved a lot of problems already that could do well to be adopted in to other systems. Apt is the most notable example (and not as prevalent a one these days), but also the menu system, the debconf specification, and a massive amount of behind the scenes infrastructure that most people (even Debian users) don't acknowledge. Putting these in a place like Alioth allows more sharing. Debian states very explicitly in the Social Contract that it is about giving back to the community, and having an easy to access place helps with that very much.
So, in that sense, Alioth isn't so much about competing with Gentoo but with fulfilling the Social Contract, which has been the same old goal of Debian for many years. Nothing new there, if you've been paying attention at least.
I don't use an RPM-based distro, but don't up2date, apt4rpm, and urpmi handle just that for you? The dependency handling issue has long since been solved, and Gentoo is not the only solution. Thankfully, the whole distro landscape has been moving on to new problems as of late.
The site linked is up fine right now, but the IP they give at the top as being the actual server on the fly isn't responding. Is it slashdotted? I'm picturing a smoking fly in the middle of the plastic cube. I'm just glad I don't have to smell it.
Fly Server Admin: Damn you slashdot! Damn you! You killed my baby!
And what license would this be under? I can't find it in the source files (grep -i "license" *java"), nor can I find it on the website or the message board. It'd be nice to have this in Debian, but without a license it can't be done.
How can you prove this? All you've shown from the data is that Microsoft has a lot of market share, Mac has very little, and Linux has even less as determined by this company.
How in the world can you claim that it's because we haven't standardized on Gnome or KDE? Hell, you can't because Mac has a far more standard (and superior) UI than Windows, and it's stil way below on those figures. There's far more to this than you could even think to touch on with just the Gnome and KDE split. Correlation is not causation. Come back when you've got something better.
Seriously, how much is Linux really like Windows when you get down to it? A highly user-configurable kernel? Not in Windows. A strong UNIX-like set of userland apps? Not in Windows. A powerful and flexible network-transparent windowing system? Not in windows. Exceptional package handling for every piece of software on a system a la' apt-get? Not in windows.
There are plenty of things that Windows has that Linux doesn't as well. There's a full-featured API for just about everything, and it's all standardized. There's a consistent UI. And there's things like market share and a single dominating power behind it.
If you look at this list, about the only thing on it that most people are interested in is more market share, and the folks in Debian (as one example) don't particularly seem to care a whole lot about that. They, along with the likes of Slack and Gentoo, aren't trying for a single unifying API or UI. Some people want to unify the UI but most of us wouldn't actually want to see it happen, and for good reason. I'd be pissed if someone took away my pwm in the name of everyone else.
And as for innovation, well that's a tired argument. John, like everyone else who brings it up, can sit around and whine whine whine that they don't have their new vague super UI right now, but it's a load of crap. Innovation is constantly happening on the linux side, it's just not so apparent. John can bitch about wanting a new paradigm, but unless he's willing to put up some code then it's just not going to happen. You want a MacOSX type UI? Go contribute to GNUStep and get the fundamental groundwork down. You think X sucks? Go contribute to Fresco. Ultimately, if you're going to do something in free software, in order to attract attention these days of a million and one sourceforge projects you're going to have to do something good. You can moan about how windows-like KDE is, but if that's what people want then that's what is going to get the lion's share of coder and media attention. If you want something better then no one, including the KDE team, is stopping you from making it.
Ultimately, linux innovation happens in slow stages over many years, rather than in quick bursts. It's just the nature of the beast. Gnome and KDE are racing to outdo one another in every possible area, and the users are all the beneficiaries. You can't say that these projects haven't done well for themselves. They might not have come up with the most innovative stuff, but they do each have unique ideas that aren't found in Windows, Mac, or anywhere else. Innovation also happens under the hood. I'm a Debian user, and other Debian users probably know what I'm talking about. There's things like porting all of Debian to different kernels (the HURD, NetBSD, etc.) There's incremental improvements to dpkg and apt-get, including new frontends and the like. There's the debconf system which makes a good interface for dealing with package configuration. There's things like the alternatives system and apt-src. There's other examples, but you get the picture. I know other distros also have plenty of innovations that I'm not familiar with as well and this is the entire point. Projects compete because they can coexist (as can not happen in windows) so innovation comes from the ground up rather than descending from on high every two years as Windows releases anew. Innovation does happen, but just like watching a tree grow, it's not as impressive to see in real time.
I don't really understand why it's so hard to support multiple distros. What sort of stuff are you using in your app? Well, standard library routines, so you're going to be using libstdc or libstdc++, both of which will be on any linux system. If you're creating a command line app, then you can use libreadline or libcurses, both of which will be on any linux system. If you're writing a GUI based app, you can use Gtk or Qt (or even Motif/Lesstif or Xt) and have it run on any Linux desktop. And of course you can install any custom libs you want. There's also the distinct possibility of static linking, which is frowned upon generally but doable (you could create two versions of your app, one dynamically linked for a popular distro and another static for everyone else). You can use an installer like Loki's in order to handle the placement of things and making sure that it's all there for you.
/usr/share/lib or /usr/local/lib is irrelevant really. Include the libs you need and the whole of it should work fine. And really, if your only concern is directory layouts, why not simply have a default install location (/usr/local/whatever is a good choice, as it's the default in auto* tarballs) and let people override them as they will. After writing a big and complex app, supporting configurable directory heirarchies (hint: one line in a .rc file and an extra string variable in your code will do it) should be the least of your worries.
I really don't understand why everyone says it's hard to get software to run on alternate distributions. The basics are all standardized. There's standard libraries and standard routines. There's standard packaging formats that one can use, or a powerful installer. Whether you decide to use Gtk or Qt and whether you decide to put your custom apps in
That's interesting. I've rarely found the texinfo pages to be of any real use to me when a manpage fails.
/usr/share/doc/packagename. If the manpage fails me at all, this is where I go first. The documentation that came with a program is often the most useful documentation you're going to find, especially because the Readme's and the like often have a lot of quick notes in them. The changelogs have tons of good info too. Of course, to be able to use these docs requires knowing what program you're looking for in the first place, which requires some experience, but it's by far the most useful documentation that's physically on my system.
I don't know how it is for other distros, but every debian package puts its documentation in
It has three branches (stable, testing, unstable) so you can choose your ratio of features to stability.
It has a large community of users to give support.
Each software package acts as a personal liason to upstream authors of software so you can get wishlist requests in and solid bugreports dealt with in a reasonable manner.
It has a completely open development process so you can see everything and even participate if you want.
It has a clearly defined and actively updated policy that provides standardization throughout the system (any package that violates policy is buggy by the way, and is treated as such).
It has an army of developers over a thousand strong who maintain "more than 8710 packages" to make this distribution the largest (what was that about no good software?)
There was a long and drawn out discussion about this on the debian-devel mailing list. If you want to sit around compiling your entire system from scratch, you're welcome to, but note that you can do this in Debian too, and keep things packaged. There's the apt-src package that will do this and keep all the debian stuff you love. This program hasn't had the most active development in the past (the author is one of Debian's best developers and contributes all over the place) but you can be sure it'll be improved soon. Plus, say what you will about Debian's install, it's way easier than gentoo's manual bootstrap method.
Besides, the majority of apps won't benefit from custom compilation enough to make it worth the time.
This traditionally hasn't been Debian's focus at all, but hopefully the desktop subproject will change that once it really gets going. And as for Lindows, it's based on Debian itself. Debian does serve as a fantastic platform for other people to build systems on.
I'm sorry, but if you put Debian stable vs. Redhat on the server you'll find Debian wins out everywhere that it needs to including upgrades and stability. Redhat gives you corporate support if you pay for it, which is a definite advantage when you need to cover your ass or you're ignorant. There's something to be said for a name brand, that's for sure.
The desktop project will hopefully work on this. I personally do just fine having fun and using multimedia on my Debian desktop system, but maybe that's just me and the thousands of other users like me.
Well, there's the HURD subproject in the works, as well as a NetBSD port. None of the other distros you mentioned have that. The reason for that is that Debian is far more than a Linux distribution, it's a whole project devoted to making a great system. This system can be ported to other kernels and other architectures. It's flexible and has the underlying infrastructure (like autobuilders and debbugs database) to handle this task. It's got the large quantity of manpower and the policies in place for managing it. Debian isn't a corporation, so it doesn't work the same way as Redhat, Mandrake, SuSE, and the rest. The closest one to it is Gentoo, and it's no mistake that Gentoo modeled its social contract on that of Debian.
Debian isn't the be all end all by any means. But it's an amazing project that moves at its own pace. While everyone else is worried about pretty installers, Debian is working on supporting computers that no one else supports. While everyone else is worried about grabbing the largest userbase, Debian is working on making the best system that the developers can put together. It just works differently than other distros. This doesn't make it obsolete, it makes it impressive.
There's not much to see yet, it's only a text-based install right now. S-Lang and GTK frontends are in the works though.
What most people are going to think of when they see this is that this will make Debian's install more friendly. While this is very likely to happen, there are going to be other major benefits to this project.
The main one is that this will completely replace the old boot-floppies software that previous releases were based on. boot-floppies was, by all accounts, a major pain to deal with. For the release of woody, the installer was supposed to be re-written, but people complained and it was decided to "just" update boot-floppies once again for woody so that the release could get out the door quickly. This update took an extremely long time, so woody took a lot longer to release.
Sarge is largely waiting on debian-installer to be in good shape to release. No one, and I do mean no one, is willing to work on boot-floppies any more. I've never personally looked at the code, but I know it's just not worth it. debian-installer is modular and will provide the ability to have multiple frontends. The only one in place right now is the text-based frontend, so it's even uglier than the boot-floppies UI right now, but GTK and S-Lang frontends are in the works. Either way, the modularity of the new system will hopefully make it easier to update for new stable releases. boot-floppies was really holding things back there, much to everyone's dismay.
The other thing of note is that the entire installer is based on the debconf system (well, a rewritten C version of it actually), which is Debian's standard configuration backend. There are multiple frontends, like Gnome, Dialog (curses), and text-based for it, and it's in heavy use in Debian right now. It's a good system that's worked well, and using it in the installer will encourage even more standardization in an already fairly coherent distro.
As for this alpha, it only supports i386 right now. I don't know how far along the porting efforts are to other arch's, but a new Debian release won't happen until it's been ported everywhere that it needs to be. Still, the installer team has done a great job, and this is a project that the Debian community really should be paying close attention to.
Progeny's installer (known as PGI) doesn't work on non-x86 archs (it may work on PPC, but not on the majority of the arch's that Debian supports). From what I understand, there's no movement towards porting it to other arch's, either because it's difficult or people aren't interested in doing so. Anthony Towns (the Release Manager for Debian) basically just wants a working installer, and debian-installer is what people are actually working on.
Yeah right, like that's going to stop the military from using me if I get drafted. No matter how many licenses I tape to my body I'm screwed.
Fantastic post on all counts. You've given me a lot to think about, thanks.
So how about Lesszilla?