I do have to agree there. Unfortunately, one of the big problems is that some of the porters simply weren't building 4.3 pre- packages on their arches for a while. They really dropped the ball, and x86 seemed to hurt for it. Unfortunately, I don't think all the work for x86 was really done, even though the packages worked for most people. Hopefull now that the big reorganization is over with, and 4.4 packaging has already begun, things will move quicker in the future. If get time, I'm going to help out with the 4.4 testing/packaging effort, but that probably won't happen until post-sarge. FWIW, Branden does want people to help him, hence the move to svn.
Huh? What's wrong with "apt-get source foo"; cd foo-version; dpkg-buildpackage -rfakeroot"? You've got your freshly compiled package all right there for you, and you can play with it all you like. It's not as easy as gentoo, but it's really not much harder either.
And, of course, compiling normal tarballs works fine. I never have any troubles getting dependencies for compiling those, because when they show up I just grab missinglib-dev and all is well. I never understand why people think it's so hard.
Yes, the X packages are well behind in Debian, but it's for a number of good reasons. One being that the packages underwent a massive reorganization for 4.3. This was, in part, to prepare to accomodate the oncoming packages of the freedesktop.org stuff. The libraries have been split in to individual packages, rather than massive bundles. Once the freedesktop packages go in, the infrastructure should be there for you to mix and match X libraries from both XFree and f.d.o as you need them.
Another reason is that, simply put, XFree86 produces unportable code. Tons of the porting work must be done by the Debian team itself, and that isn't easy. The fact that a lot of the code itself is crappy is an issue too.
Have you tried the new installer? The old boot-floppies has been totally replaced for sarge, and the new installer is shaping up pretty well. It's still not pretty (yet, although people want a gtk frontend, no one has really stepped up to do the work on it) but it's got hardware autodetection, a lot less questions to ask, grub as the default bootloader, and a whole bunch of other goodies that are on the way. We've gotten tons of positive feedback on it so far, so please give it a go!
Maybe, but he is, quite literally the guy who defined Free Software in concrete terms, and in addition codified the way in which we as a community are bound to each other. He's obviously thought long and hard about the issues surrounding this community, and he was doing it before the vast majority of us. That means his voice rightfully carries a lot of weight.
I don't get it. Isn't this what the FHS already solves? I know Debian follows the FHS as part of policy, and so everything basically has a set place where it goes. The basics work like this:
Binaries meant for normal users go in to/usr/bin, unless they're part of the base system, in which case they go in to/bin. If they're part of XFree86's special playground, then they go in to/usr/X11R6/bin, but that's really an ugly holdover more than anything.
Binaries for administrators go in to/sbin or/usr/sbin
Shared libraries go in to/usr/lib or/lib, depending on how close to the base system it is. Sometimes they put their own subfolder in/usr/lib, but not as often.
Executables meant just for the app and not the user, as well as images, sounds, etc go in to/usr/share/appname
Documents go in to/usr/share/doc/
System-wide config files go in to/etc
This is all really well established, and I'd be surprised if all the major dists didn't follow it. It's not really that complex, especially when normal users really only have to know about/bin and/usr/bin. It's also not very complex ultimately, since once you start working with it things are exactly where you expect them to be, and besides, the packager package manager (or port-type manager, does emerge's type of soft have a general term?) should be managing these things for you. Next time you're on a Debian system, try checking out/usr/share/doc/packagename for whatever program you're interested in. You'll find tons of good info.
Then you obviously know that Debian Woody included not only 2.2, but 2.4.18 as well in the standard install. Woody is definitely really damn dated, but there's no need to play dumb. Also, nothing at all is stopping you from installing your own, up to date kernel in woody (2.6 runs fine with a modtools update), and make-kpkg will even make it easier on you.
Got any concrete examples? I have never had a problem with a driver being a module rather than compiled in. And, as in the case of network cards, my old network card didn't work at all when it was compiled in to the kernel, but worked great when I used it as a module. This was true not only for 2.4, but 2.2 as well.
These days I just use the kernel provided by my distro (the Debian kernel maintainer knows a hell of a lot more about them than I ever will) and things work perfectly. Plus I don't have to go and recompile my modules (or the whole damn kernel) if I forgot something or buy new hardware.
SCO employee (assuming they still have people there who can code)?
Well, they're definitely not working on UNIXware. I mean, geez, all they managed to show off at their Road Show was that they hand bundled in gimp-print and Samba. So if they do have programmers, they have to be doing something. Right?
But the interesting thing about Justin is that he's pushing the boundaries of what's going on far more than the guy who contributes 2 lines of code to apache. A bug fix is a bug fix is a bug fix, but he's actually trying to do new things. To be quite frank, the fact that he's managing to do a lot of this stuff before anyone else (or often better than anyone else) shows that he really is a force to be reckoned with. Remember, while the software may be more important than the creator, the software wouldn't be without the creator. Give the guy some credit.
I'm always interested to hear what he's doing, since he's usually coding in the unheard of places that the rest of us will be talking about as having been totally obvious next year.
Isn't native CMYK going to be in 2.0? I thought that was the big underlying switch for 2.0, was that the fundamental color model scheme for the whole app would be changed to allow for CMYK, not just export.
To me, the strong emphasis on free software / GPL / alternatives to "big corporate entities" that seems to be a part of the Debian community seems antithetical to the idea of naming their product after DISNEY CHARACTERS. Isn't Disney _exactly_ the big evil company the oppose? Isn't Disney the one working to extend copyright indefinately, put all sorts of protections and technical blocks on DVS, &c &c?
I'm surprised that you think of the GPL in this way. I don't like to think of it as anti-corporate, so much as pro-freedom, and that includes the freedoms of corporations. This includes corporations such as Redhat and IBM, who have both done quite a bit to help the whole of Linux, including Debian. The GPL is meant to provide a level playing field, where the corporations have the same rights as individuals, so why not take names from something that was birthed from a corporation? Or do you not think that Debian Developers run hardware or buy 'net access from corporations?
Yes, Disney is one of many working to extend copyright indefinitely, and that's a problem, but as others have said, there are historical reasons for the naming scheme (hi Bruce!), plus it's a fun naming system. But beyond that, Debian developers are too busy worrying about real issues, such as the validity of the GNU Free Documentation License (hint: it's not Free by Debian standards) and how to fix it, or *gasp* getting the next release out the door (yes, it's coming soon, the installer was frozen for beta2 today, which may be the actual release version). In comparison to these issues, the codename for Debian Unstable suddenly seems a lot less of an issue.
If you'd really like to press forward with the problem, I suggest fixing some bugs so the focus can be shifted to such things.
EV is the thing I miss most from my Mac days. If they ported it to linux I'd be ecstatic. It's a top-notch piece of work. If I had the time, I'd work on hacking up a clone version. You know a game is awesome if it's shareware and you want to clone it more than commercial games.
I took this (the Fung-Wah bus) over Thanksgiving to go from Boston to NYC. Other than having to wait a while because it was so crowded to get a ticket, I had no troubles. The trip was quick and comfy. On the way back, they sold out of tickets while I was in line, so I had to go Greyhound. Greyhound was three times the cost and ten times the hassle, all for a slower ride on a worse bus. The Fung-Wah rules!
You obviously weren't really using Debian, or at least you weren't paying attention when you were. 2.2 is the standard install kernel for woody, but 2.4 is readily available for the install as well (a simple command line option at boot gets it for you), and I can guarantee you that the admins are capable of using it.
If you look at linux as opposed to OSX, where OSX developed a brand new somewhat consistent desktop in far less time then KDE/GNU existed
OSX had a very very strong NeXTStep framework to build off of. Gnome and KDE had to reinvent those somewhat with things like bonobo and kparts.
Plus everyone who talks about these things seems to forget OSX Server (the original one). It bears no resemblance to the current OSX, and that's what was the only thing out for a while before OSX. OSX didn't appear overnight, it was the product of a long gestation.
This aside, if you use KDE apps exclusively in KDE or Gnome apps exclusively in Gnome, it's gotten to be pretty consistent throughout. The problem comes when you start to mix and match, but that's entirely up to you.
Joey says in a comment below the article that these days he keeps most of his home directory in Subversion rather than CVS, and that he hasn't gotten around to writing an updated version of the article.
The first link is just a load-time test (which they explicitly state) and the second url isn't found on the site. Both the links I gave relate to actual runtime performance. No one has demonstrated a real benefit to custom compilation Gentoo-style. Unless all you do all day is close and reopen your browser window.
I'll fully agree with you on testing, since not getting security updates in there is a really major problem, which is why I don't use testing myself and don't generally recommend it. How does gentoo stable compare to Debian unstable? Does it have all the newest stuff or is it held back a little, more like testing? And I've rarely had a problem with unstable for many years, but different people have different skill levels and results. Gentoo's techincal merits are pretty slim, in my opinion. If you want to custom compile your stuff, once again, is apt-get source foo; dpkg-buildpackage -rfakeroot really so hard? If you want backports, apt-get.org is more than useful. What technical merits does Gentoo really have over Debian? I've yet to hear any that stand up, although I'd honestly love to hear some.
Because Debian's foundation is arguably farther ahead of Redhat's. While dpkg vs rpm isn't so much of an issue any more, there are still some smaller areas where dpkg appears to outshine rpm (see here for details). apt is better than up2date, and Debian has the majority of stuff codified in policy or the developer's reference, both of which are very practical documents brought about by years of experience in cooperatively dealing with the problems of assembling a coherent distribution in a cooperative setting, which is something the Fedora project is brand new at. They could have leveraged this sort of experience, but chose to redo it themselves.
This ignores the social contract which is a practical set of recommendations for the overarching ideas of a distro. Gentoo basically lifted this for their own when they started their work. Debian also has a very mature and powerful (if a bit arcane at first) bug tracking system, mailing list setup, and mirror system, all of which provide the extensive ifrastructure needed to run a massive project that is completely independant of any one corporate entity. This stuff was built from the ground up for its purpose, and it provides an extremely solid foundation that keeps the project moving along. Fedora might have some newer packages, but the foundation of Debian down to the social and technical infrastructure is even more solid because it's been hardened over many years of experience.
Ok, installation. If you've got the bandwidth (and you're going to need it if you're running unstable) to download full ISO's, you should simply download the netinstall CD image and go from there. There's a couple of them around and I think you can get to them from the Debian page. You should be able to avoid jigdo too, which I'm not fond of either. If you don't have the bandwidth then I recommend simply buying a CD set from a vendor. There are 11 CD's because Debian is huge. It has everything and more. That includes the source code (I think without source it's 7 CD's). Buying a cheap CD set will save you lots of time and headache The install process right now isn't that great (although I'm pretty comfy with it) but the new installer will be included in the next Debian release that's due in a few weeks, so you may want to wait for that, as it'll have hardware autodetection and a friendlier GUI. Either way, be sure to read the Debian Installation Guide, which really lays things out for most people. The majority of installation problems are solved in there, if you're willing to read it.
As for stable vs. unstable, I really don't recommend that newbies start with unstable. Yes, the software in stable might be old but if you don't know what you're doing yet don't worry about it. Spend a little bit of time learning the system and when you're comfortable enough with it so that you don't have to ask someone else how to move from stable to unstable then try going over. I've run unstable straight for years with minimal problems and it's really not bad when you know the system well enough to fix things as they happen. If you're a total newbie though, it'll just frustrate you to no end. Once you feel comfortable and brave, then maybe give unstable a spin. As it is though, with the new release pending you'll be able to get pretty new software in a very stable and tested state and you can learn on that for a while.
t's possible to run serious production servers that need recent-version daemons using Gentoo defaults for compile options and with a nicely-rationalized/etc/*/ tree for the configuration options. If you want to accomplish the same with Debian you're going to have to custom-compile your major daemons, and deal with much more of a mish-mash of init and conf stuff.
I don't get this. In gentoo you custom compile, in debian you custom compile. Is that so hard? Is apt-get source foo; dpkg-buildpackage -rchroot really that much harder than emerge foo? Oh, and for Debian you can also run unstable or testing for newer versions, you do have that option if custom compilation is so odious for you (which I assume it's not, if you like gentoo). As for the mishmash of init and conf stuff, I don't know much about that, but I've never had much trouble working my way around Debian's/etc directory.
Mind you, Debian is good if you want a server that's not cutting-edge, that's real stable, and that doesn't do much that's fancy. But Gentoo is less trouble and performs better if you have clients who you've sold on using today's technology, rather than that of several years ago.
I wouldn't recommend Debian unstable on the server myself, but then again I wouldn't recommend Gentoo on the server for the same reasons. You certaintly can run unstable on the server and get the same quality of packaging and whatnot as you'd get from gentoo, but you pay the price for bleeding edge software either way. Once again, you can have the newest stuff in Debian if you want. It's not really that hard. Hell, even if you don't want unstable, backports are often available, quite often from Debian developers themselves.
Oh, and desktops in particular run much better when the stuff is compiled for your specific hardware
and the feel of responsiveness is a major factor in making power desktop users feel comfortable and happy
Placebo effect in action. I guess anyone who waits to compile their whole system from scratch will probably justify it however they can. "Power users" who ignore benchmarks are just putting on airs though.
The new installer was just announced to be in beta. It's coming along, just be patient. If you want, you can even help test and contribute to it. Details here.
Slashdot Mirror
I do have to agree there. Unfortunately, one of the big problems is that some of the porters simply weren't building 4.3 pre- packages on their arches for a while. They really dropped the ball, and x86 seemed to hurt for it. Unfortunately, I don't think all the work for x86 was really done, even though the packages worked for most people. Hopefull now that the big reorganization is over with, and 4.4 packaging has already begun, things will move quicker in the future. If get time, I'm going to help out with the 4.4 testing/packaging effort, but that probably won't happen until post-sarge. FWIW, Branden does want people to help him, hence the move to svn.
Huh? What's wrong with "apt-get source foo"; cd foo-version; dpkg-buildpackage -rfakeroot"? You've got your freshly compiled package all right there for you, and you can play with it all you like. It's not as easy as gentoo, but it's really not much harder either.
And, of course, compiling normal tarballs works fine. I never have any troubles getting dependencies for compiling those, because when they show up I just grab missinglib-dev and all is well. I never understand why people think it's so hard.
Yes, the X packages are well behind in Debian, but it's for a number of good reasons. One being that the packages underwent a massive reorganization for 4.3. This was, in part, to prepare to accomodate the oncoming packages of the freedesktop.org stuff. The libraries have been split in to individual packages, rather than massive bundles. Once the freedesktop packages go in, the infrastructure should be there for you to mix and match X libraries from both XFree and f.d.o as you need them.
Another reason is that, simply put, XFree86 produces unportable code. Tons of the porting work must be done by the Debian team itself, and that isn't easy. The fact that a lot of the code itself is crappy is an issue too.
Have you tried the new installer? The old boot-floppies has been totally replaced for sarge, and the new installer is shaping up pretty well. It's still not pretty (yet, although people want a gtk frontend, no one has really stepped up to do the work on it) but it's got hardware autodetection, a lot less questions to ask, grub as the default bootloader, and a whole bunch of other goodies that are on the way. We've gotten tons of positive feedback on it so far, so please give it a go!
Maybe, but he is, quite literally the guy who defined Free Software in concrete terms, and in addition codified the way in which we as a community are bound to each other. He's obviously thought long and hard about the issues surrounding this community, and he was doing it before the vast majority of us. That means his voice rightfully carries a lot of weight.
- Binaries meant for normal users go in to
/usr/bin, unless they're part of the base system, in which case they go in to /bin. If they're part of XFree86's special playground, then they go in to /usr/X11R6/bin, but that's really an ugly holdover more than anything.
- Binaries for administrators go in to
/sbin or /usr/sbin
- Shared libraries go in to
/usr/lib or /lib, depending on how close to the base system it is. Sometimes they put their own subfolder in /usr/lib, but not as often.
- Executables meant just for the app and not the user, as well as images, sounds, etc go in to
/usr/share/appname
- Documents go in to
/usr/share/doc/
- System-wide config files go in to
/etc
This is all really well established, and I'd be surprised if all the major dists didn't follow it. It's not really that complex, especially when normal users really only have to know aboutThen you obviously know that Debian Woody included not only 2.2, but 2.4.18 as well in the standard install. Woody is definitely really damn dated, but there's no need to play dumb. Also, nothing at all is stopping you from installing your own, up to date kernel in woody (2.6 runs fine with a modtools update), and make-kpkg will even make it easier on you.
SELinux has been included in 2.6. In case you don't know, this is the set of security extensions developed by the NSA itself. Check it out here .
Got any concrete examples? I have never had a problem with a driver being a module rather than compiled in. And, as in the case of network cards, my old network card didn't work at all when it was compiled in to the kernel, but worked great when I used it as a module. This was true not only for 2.4, but 2.2 as well.
These days I just use the kernel provided by my distro (the Debian kernel maintainer knows a hell of a lot more about them than I ever will) and things work perfectly. Plus I don't have to go and recompile my modules (or the whole damn kernel) if I forgot something or buy new hardware.
But the interesting thing about Justin is that he's pushing the boundaries of what's going on far more than the guy who contributes 2 lines of code to apache. A bug fix is a bug fix is a bug fix, but he's actually trying to do new things. To be quite frank, the fact that he's managing to do a lot of this stuff before anyone else (or often better than anyone else) shows that he really is a force to be reckoned with. Remember, while the software may be more important than the creator, the software wouldn't be without the creator. Give the guy some credit.
I'm always interested to hear what he's doing, since he's usually coding in the unheard of places that the rest of us will be talking about as having been totally obvious next year.
Isn't native CMYK going to be in 2.0? I thought that was the big underlying switch for 2.0, was that the fundamental color model scheme for the whole app would be changed to allow for CMYK, not just export.
Yes, Disney is one of many working to extend copyright indefinitely, and that's a problem, but as others have said, there are historical reasons for the naming scheme (hi Bruce!), plus it's a fun naming system. But beyond that, Debian developers are too busy worrying about real issues, such as the validity of the GNU Free Documentation License (hint: it's not Free by Debian standards) and how to fix it, or *gasp* getting the next release out the door (yes, it's coming soon, the installer was frozen for beta2 today, which may be the actual release version). In comparison to these issues, the codename for Debian Unstable suddenly seems a lot less of an issue.
If you'd really like to press forward with the problem, I suggest fixing some bugs so the focus can be shifted to such things.
EV is the thing I miss most from my Mac days. If they ported it to linux I'd be ecstatic. It's a top-notch piece of work. If I had the time, I'd work on hacking up a clone version. You know a game is awesome if it's shareware and you want to clone it more than commercial games.
I took this (the Fung-Wah bus) over Thanksgiving to go from Boston to NYC. Other than having to wait a while because it was so crowded to get a ticket, I had no troubles. The trip was quick and comfy. On the way back, they sold out of tickets while I was in line, so I had to go Greyhound. Greyhound was three times the cost and ten times the hassle, all for a slower ride on a worse bus. The Fung-Wah rules!
You obviously weren't really using Debian, or at least you weren't paying attention when you were. 2.2 is the standard install kernel for woody, but 2.4 is readily available for the install as well (a simple command line option at boot gets it for you), and I can guarantee you that the admins are capable of using it.
Plus everyone who talks about these things seems to forget OSX Server (the original one). It bears no resemblance to the current OSX, and that's what was the only thing out for a while before OSX. OSX didn't appear overnight, it was the product of a long gestation.
This aside, if you use KDE apps exclusively in KDE or Gnome apps exclusively in Gnome, it's gotten to be pretty consistent throughout. The problem comes when you start to mix and match, but that's entirely up to you.
Joey says in a comment below the article that these days he keeps most of his home directory in Subversion rather than CVS, and that he hasn't gotten around to writing an updated version of the article.
As does Debian, with .conf files.
The first link is just a load-time test (which they explicitly state) and the second url isn't found on the site. Both the links I gave relate to actual runtime performance. No one has demonstrated a real benefit to custom compilation Gentoo-style. Unless all you do all day is close and reopen your browser window.
I'll fully agree with you on testing, since not getting security updates in there is a really major problem, which is why I don't use testing myself and don't generally recommend it. How does gentoo stable compare to Debian unstable? Does it have all the newest stuff or is it held back a little, more like testing? And I've rarely had a problem with unstable for many years, but different people have different skill levels and results. Gentoo's techincal merits are pretty slim, in my opinion. If you want to custom compile your stuff, once again, is apt-get source foo; dpkg-buildpackage -rfakeroot really so hard? If you want backports, apt-get.org is more than useful. What technical merits does Gentoo really have over Debian? I've yet to hear any that stand up, although I'd honestly love to hear some.
Because Debian's foundation is arguably farther ahead of Redhat's. While dpkg vs rpm isn't so much of an issue any more, there are still some smaller areas where dpkg appears to outshine rpm (see here for details). apt is better than up2date, and Debian has the majority of stuff codified in policy or the developer's reference, both of which are very practical documents brought about by years of experience in cooperatively dealing with the problems of assembling a coherent distribution in a cooperative setting, which is something the Fedora project is brand new at. They could have leveraged this sort of experience, but chose to redo it themselves.
This ignores the social contract which is a practical set of recommendations for the overarching ideas of a distro. Gentoo basically lifted this for their own when they started their work. Debian also has a very mature and powerful (if a bit arcane at first) bug tracking system, mailing list setup, and mirror system, all of which provide the extensive ifrastructure needed to run a massive project that is completely independant of any one corporate entity. This stuff was built from the ground up for its purpose, and it provides an extremely solid foundation that keeps the project moving along. Fedora might have some newer packages, but the foundation of Debian down to the social and technical infrastructure is even more solid because it's been hardened over many years of experience.
Ok, installation. If you've got the bandwidth (and you're going to need it if you're running unstable) to download full ISO's, you should simply download the netinstall CD image and go from there. There's a couple of them around and I think you can get to them from the Debian page. You should be able to avoid jigdo too, which I'm not fond of either. If you don't have the bandwidth then I recommend simply buying a CD set from a vendor. There are 11 CD's because Debian is huge. It has everything and more. That includes the source code (I think without source it's 7 CD's). Buying a cheap CD set will save you lots of time and headache The install process right now isn't that great (although I'm pretty comfy with it) but the new installer will be included in the next Debian release that's due in a few weeks, so you may want to wait for that, as it'll have hardware autodetection and a friendlier GUI. Either way, be sure to read the Debian Installation Guide, which really lays things out for most people. The majority of installation problems are solved in there, if you're willing to read it.
As for stable vs. unstable, I really don't recommend that newbies start with unstable. Yes, the software in stable might be old but if you don't know what you're doing yet don't worry about it. Spend a little bit of time learning the system and when you're comfortable enough with it so that you don't have to ask someone else how to move from stable to unstable then try going over. I've run unstable straight for years with minimal problems and it's really not bad when you know the system well enough to fix things as they happen. If you're a total newbie though, it'll just frustrate you to no end. Once you feel comfortable and brave, then maybe give unstable a spin. As it is though, with the new release pending you'll be able to get pretty new software in a very stable and tested state and you can learn on that for a while.
I wouldn't recommend Debian unstable on the server myself, but then again I wouldn't recommend Gentoo on the server for the same reasons. You certaintly can run unstable on the server and get the same quality of packaging and whatnot as you'd get from gentoo, but you pay the price for bleeding edge software either way. Once again, you can have the newest stuff in Debian if you want. It's not really that hard. Hell, even if you don't want unstable, backports are often available, quite often from Debian developers themselves.
Right. Sure.
Placebo effect in action. I guess anyone who waits to compile their whole system from scratch will probably justify it however they can. "Power users" who ignore benchmarks are just putting on airs though.
The new installer was just announced to be in beta. It's coming along, just be patient. If you want, you can even help test and contribute to it. Details here.