> Not the same -- Debian _requires_ you to start > up dselect. For a new user, dselect is certainly > intimidating -- I'm experienced, and I always am > hitting the wrong keys.
As I said, in potato, the lists of delected packages will be passed directly to apt, so you should not have to run dselect.
Anyway, the only confusing part of dselect is the [S]elect stage. The rest is a simple menu. Debian currently doesn't require you to go into [S]elect at all if you elect to choose from the groups of packages.
> I asked Libranet what this distro was about, and > they said that the main thing they changed was > to take dselect out of the install and instead > give apt-get a list of things to install. > > IMO, this is WONDERFUL.
It sounds like a dubious modification, since when you install debian, you are offered a choice to pick from groups of packages to install. If you do this, you do not have to use dselect to pick what to install, and in debian potato, these lists are indeed passed directly to apt.
So if this is libranet's value-add, it will be in Debian proper quite soon anyway. (And as usual, we talked it out and did it *right*.)
Interesting post, but one thing you don't mention is that is has been Debian's intention from the beginning to serve as a base for other distributions. For example, Bruce Perens for years wanted to base a "linux for Hams" off of debian.
I don't look at what's been happening lately as a fragementation of Debian, but as the acheivement of a long term goal. (I just hope all these debian derivatives are of types 1,2, or 3!)
Here's another set of graphs tracking a free software project -- I've been tracking the number of packages in Debian, as well as how many packages are built with different tools, especially my debhelper tool that most debian packages build with these days.
I'm also seeing linear growth, though the angle is steeper.
I'm the maintainer of cxhextris for debian and this seems to have slipped through by accident. It'll probably be moved to non-free RSN and I'll then contact the author and see if the license can't be fixed.
Well you start with a simple, clean little program and use every trick you know to compress the hell out of it.
BTW, I have no idea why my posting ate part of the one it is a reply to. Odd. Also, I have set up a mailing list for discussion of these things, go to http://kitenet.net/~sigprog/ to subscribe.
> VA buys stocks components that any of you can > buy and slaps them together in a steel box.
You'd prefer to buy a system from some big name like IBM or Compaq or Pacard Bell that uses special non-standard components and locks you into using their proprietory hardware? I think most people here have already decided buying from a small vendor is a better idea.
But those small vendors often skimp on quailty hardware, and they certianly don't select the components that work well with linux.
VA is a very happy mean between the two, you get standard hardware that's high quaility and has been chosen to work well with linux. Of course the linux stickers on the VA systems are a nice extra.
What really wowed me about my VA system, though, were two things. It came with spare mounting rails, and a screws that must be replacements for every single screw in the whole box. Best of all, it came with a manual - a big 2 inch thick monster that mist be 600 pages long, and that contained excellent linux-specific information tailored to my machine, and complete documentation of every board in it.
Frankly, the manual made me happily nostalgic to the days when all computers came with a Real Manual and programming information. Bravo VA!
> I dislike the complicated debian source build > procedure, and I also would like to see DEB > more on par with RPM on optional packaging for > software
I have to take issue with this. I maintained about 30 rpm packages long ago, and currently maintain about 90 packages for debian, so I'm very familiar with both source formats.
Rpm's format looks easier on the surface, but the fact is if you maintain rpm packages over a long period of time, especially lots of packages, you start discovering that you're wasting a lot of time diddling around with patch files, messy spec file hacks, and so on.
Debian's format looks harder on the surface, but once I got over the learning curve with it I found that it let me be much more productive, which is mainly why I maintain 90 packages today as opposed to only 30-some rpm packages before. It's also conceptually much cleaner - it's just a makefile after all. And more powerful - it's a makefile after all and you can do amazing things with a makefile.
> but I understand that it's more > difficult to maintain a DEB package than it is > to write a RPM.spec file.
Ah, there's the rub. You _write_ a rpm spec file. You _maintain_ a debian package. Of course it's more work to do the latter, since maintaining a package is a continuing process. This is of course why.deb packages tend to be of superior quality.
And of course tools like debhelper have considerably lowered the bar for newcomers to debian source packages.
I can't dispute that there are certian parties in the debian community who want to require maintainers to agree with the DFSG. However, this group is not currently anywhere near a majority of the debian developers. When this thread appeared on the debian lists, I summarized it as follows for Debian Weekly News:
Should all Debian developers be required to agree with the DFSG? A thread about this started in debian-private and later escaped to the debian-devel mailing list. Everyone agrees developers must understand and abide by the DFSG when working on Debian, but there is no consensus that they must also agree with it. One commonly held opinion is that developers should at least believe in the spirit of the DFSG, but may disagree with specific points of it. Another common opinion is that it doesn't matter what developer's private opinions of the document are.
These people who think everyone in the Debian project must agree with the DFSG are a subgroup of the project as a whole. As you yourself say, Debian has always had an "enormous number of dissenting opinions" -- well the opinion of this group is just such a dissenting opinion.
Joey Hess, debian developer and editor of Debian Weekly News.
Slashdot Mirror
> Not the same -- Debian _requires_ you to start
> up dselect. For a new user, dselect is certainly > intimidating -- I'm experienced, and I always am > hitting the wrong keys.
As I said, in potato, the lists of delected packages will be passed directly to apt, so you should not have to run dselect.
Anyway, the only confusing part of dselect is the [S]elect stage. The rest is a simple menu. Debian currently doesn't require you to go into [S]elect at all if you elect to choose from the groups of packages.
> I asked Libranet what this distro was about, and > they said that the main thing they changed was
> to take dselect out of the install and instead
> give apt-get a list of things to install.
>
> IMO, this is WONDERFUL.
It sounds like a dubious modification, since
when you install debian, you are offered a choice to pick from groups of packages to install. If you do this, you do not have to use dselect to pick what to install, and in debian potato, these lists are indeed passed directly to apt.
So if this is libranet's value-add, it will be in Debian proper quite soon anyway. (And as usual, we talked it out and did it *right*.)
Interesting post, but one thing you don't
mention is that is has been Debian's intention from the beginning to serve as a base for other distributions. For example, Bruce Perens for years wanted to base a "linux for Hams" off of debian.
I don't look at what's been happening lately as a fragementation of Debian, but as the acheivement of a long term goal. (I just hope all these debian derivatives are of types 1,2, or 3!)
Perl isn't an interpreted language.
Contrary to what you'll read in the comments after the linuxtoday article, the red hat rpm version is also fixed, though they did break a symlink.
.deb package for realplayer, and it will appear in debian unstable this afternoon.
It also appears to have some new features, like playing a little sound clip on startup. And a new "presents" menu.
FWIW, I've uploaded the updated debian
Here's another set of graphs tracking a free software project -- I've been tracking the number of packages in Debian, as well as how many packages are built with different tools, especially my debhelper tool that most debian packages build with these days.
I'm also seeing linear growth, though the angle is steeper.
I'm the maintainer of cxhextris for debian and this seems to have slipped through by accident. It'll probably be moved to non-free RSN and I'll then contact the author and see if the license can't be fixed.
The logos are under the licenses here:
http://www.debian.org/vote/1999/vote_0002
> How the hell do you write those things anyway?
Well you start with a simple, clean little program and use every trick you know to compress the hell out of it.
BTW, I have no idea why my posting ate part of the one it is a reply to. Odd. Also, I have set up a mailing list for discussion of these things, go
to http://kitenet.net/~sigprog/ to subscribe.
--
#!/usr/bin/perl -lisubstr($_,39+38*sin++$y/9,2)=$s joey@kitenet.net
for($s=' '||McQ;$_='JOEY HESS 'x8;print){eval$^I} # Joey Hess
Hi, would you mind reposting that sig in legible form? You're lacking at least a close ` character.
n _the_wall:99 i $a$b,-$i$a,-Tak$t".--$i."$a$b
I keep meaning to get a mailing list together for us sick people who enjoy writing these.
And yes, this is offtopic. Moderate away
--
#!/usr/bin/perl -ie_one_down_pass_it_around,-:_bottles_of_beer:_o
for(($t,$a,$b,$i)=split/:/,$^I;$i;print){$_="-$
";s/(-1_.*?e)s/$1/g;y/_-/ \n/}
> VA buys stocks components that any of you can
> buy and slaps them together in a steel box.
You'd prefer to buy a system from some big name like IBM or Compaq or Pacard Bell that uses special non-standard components and locks you into using their proprietory hardware? I think most people here have already decided buying from a small vendor is a better idea.
But those small vendors often skimp on quailty hardware, and they certianly don't select the components that work well with linux.
VA is a very happy mean between the two, you get standard hardware that's high quaility and has been chosen to work well with linux. Of course the linux stickers on the VA systems are a nice extra.
What really wowed me about my VA system, though, were two things. It came with spare mounting rails, and a screws that must be replacements for every single screw in the whole box. Best of all, it came with a manual - a big 2 inch thick monster that mist be 600 pages long, and that contained excellent linux-specific information tailored to my machine, and complete documentation of every board in it.
Frankly, the manual made me happily nostalgic to the days when all computers came with a Real Manual and programming information. Bravo VA!
> I dislike the complicated debian source build
.spec file.
.deb packages tend to be of superior quality.
> procedure, and I also would like to see DEB
> more on par with RPM on optional packaging for
> software
I have to take issue with this. I maintained about 30 rpm packages long ago, and currently maintain about 90 packages for debian, so I'm very familiar with both source formats.
Rpm's format looks easier on the surface, but the fact is if you maintain rpm packages over a long period of time, especially lots of packages, you start discovering that you're wasting a lot of time diddling around with patch files, messy spec file hacks, and so on.
Debian's format looks harder on the surface, but once I got over the learning curve with it I found that it let me be much more productive, which is mainly why I maintain 90 packages today as opposed to only 30-some rpm packages before. It's also conceptually much cleaner - it's just a makefile after all. And more powerful - it's a makefile after all and you can do amazing things with a makefile.
> but I understand that it's more
> difficult to maintain a DEB package than it is
> to write a RPM
Ah, there's the rub. You _write_ a rpm spec file. You _maintain_ a debian package. Of course it's more work to do the latter, since maintaining a package is a continuing process. This is of course why
And of course tools like debhelper have considerably lowered the bar for newcomers to debian source packages.
Just a hint for you. Debian is not a company. Therefore debian does not have employees. Sheesh.
Not speaking for debian, or employed by it, although I am a debian developer.
Here's a hint. Just because one is a debian developer does not mean their every private action should be taken as reflecting on debian as a whole.
These people who think everyone in the Debian project must agree with the DFSG are a subgroup of the project as a whole. As you yourself say, Debian has always had an "enormous number of dissenting opinions" -- well the opinion of this group is just such a dissenting opinion.
Joey Hess, debian developer and editor of Debian Weekly News.