Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Linuxports

By simmons75 in Technology
Wed Jan 10, 2001 at 08:39:34 AM EST
Tags: Software (all tags)
Software

One of the main criticisms the Linux world gets from the FreeBSD world is a complete lack of standardization among variants (distributions.) One project seems to want to change that.


A while back, I got the wild idea to port the basic BSD command-line utils to Linux. It was mainly a "for-fun" project, but I decided to set up a home for the project on Sourceforge. While I've let the project die a quiet death, I got one response to the project that intrigues me. It's about a project called Linuxports.

What is Linuxports?

Linuxports is a set of utilities and Makefiles designed to mimic the build process of FreeBSD. The name is meant to be reminiscent of the FreeBSD Ports section, mostly software ported from Linux and put into a build tree. While I'm not a FreeBSD user, I grew intrigued with the BSD build process when doing my own hacking. Linuxports is too early in development to be very useful to anyone yet, but ideally, you should be able to build a complete system just by doing the following:

cd /usr/ports
make setup
make download-world
make world
And if anything fails, and you just want to try to build what didn't build OK the first time:
make do-world

Why would you want this?

I really don't think this is the system for everyone. However, there are some of us who like to have loads of control over their systems, but wouldn't mind an easier way of doing it. To someone like me, this has a strange appeal.

Provided this project follows the FreeBSD model, you could periodically download patches to your local source using cvsup or whatever tool the Linuxports team chooses to use (I see reference to cvs patching in one of the Makefiles.)

Also, provided they follow the BSD model to the letter, the system shouldn't need to use configure scripts. For those who don't know what a configure script is, it's a program that can check to see if you have everything installed on your system that's necessary to compile a given program.

Whereas configure (the GNU preferred method) assumes you could be randomly installing on any random, nonstandard UNIX variant, the BSD Makefile hierarchy assumes you have a system that conforms to standards. It looks like the Linuxports team wants to create a more robust build system than BSD's (for instance, you could go into a particular program's directory and issue a 'make install'.

What are the potential advantages?

There's the potential, if Linux distributions were to adopt this as a standard, of Linux distributions becoming more standardized. More standardization is good, in my eyes. It's getting difficult for me (and others) to help someone set up a Linux box, because distributions are starting to diverge rapidly. If distributions were to adopt a standard based on this work (once it's further along) it would hopefully bring distributions closer in step, and help strengthen the Linux community.

What are the potential disadvantages?

There's the potential of not being able to choose what software, and what versions, you want to choose without doing some hardcore editing of the Makcfiles. It seems to be possible, but not very easy. People who come from a Red Hat or Debian background probably won't find that very appealing. Certainly, someone who comes from a non-developer Macintosh backgound will hate the idea. Hopefully, there will be some sort of mechanism to include/exclude software other than hardcore Makefile editing.

Some people may also be turned off by the potential of a rigidly-controlled filesystem layout. To those people, I would suggest looking elsewhere.

And, of course, there are the naysayers who will state that this is definitely not the way to convert people over from Windows and Macintosh. Oh well. It's not really for the converts.

How far along is it?

I'm still waiting for download_world to finish downloading. :-) I'm not sure, but I did happen to catch a line that said, "You managed to make it this far?" That, and the author states in the README, "If you want everything to fail for sure, try running make download-world." Not a good sign. However, every project has to have an early, rocky beginning.

So, fellow reader, what do you think? Is this something worthwile? Earthshaking? Bad idea?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
World-buildable source trees for Linux
o good idea 65%
o bad idea 7%
o not sure 15%
o You Linux people sure don't know how to beat Microsoft 12%

Votes: 40
Results | Other Polls

Related Links
o BSD command-line utils to Linux.
o Sourceforge.
o Linuxports
o FreeBSD
o Also by simmons75


Display: Sort:
Linuxports | 54 comments (53 topical, 1 editorial, 0 hidden)
History of Linux (1.96 / 27) (#1)
by Signal 11 on Tue Jan 09, 2001 at 11:22:58 PM EST

The history of every function in the kernel follows approximately this history:

version 1.0: Sucks, slow, bloated, memory leaks up the wazzoo, but we're better than Microsoft.

version 1.0.1 to 1.2.0: Many patches, all incompatible, sucks less now, fast, but still leaks memory everywhere. We're about the same as Microsoft.

version 1.2.1 - 1.6: Megamaid has gone from SUCK to BLOW.

version 1.6.1 - 1.9.9: Actually useful, no memory leaks, slow again.

version 2.0: Hey, I found this thing called "BSD", and their code doesn't suck.

Version 2.0.x-2.3.x: Steal BSD code, GPL it.

Version 2.4: Stable, fast, few memory leaks, Microsoft is better now for some twisted reason.


--
Society needs therapy. It's having
trouble accepting itself.

Oh, the irony (3.25 / 4) (#3)
by simmons75 on Tue Jan 09, 2001 at 11:31:09 PM EST

The upcoming MacOS X is based on BSD, and Microsoft has been known to use BSD code, too (most notably, the TCP/IP stack.)

There's nothing particularly wrong with using BSD code; take a look at their licensing agreement sometime. The license screams, "Use me!" And to be perfectly honest, the *BSD world uses Linux stuff too (FreeBSD even has a binary compatibility layer to take advantage of binaries compiled for Linux.) Some BSD advocates take offense, but I take it about as seriously as people who take offense at the FreeBSD Linux compatibility.
poot!
So there.

[ Parent ]
Re: Oh, the irony (3.00 / 2) (#7)
by UrLord on Tue Jan 09, 2001 at 11:36:23 PM EST

But changing the license from a BSD license to a GPL license is not ok. The BSD license allows for commercial entities to take the code and used it in a closed source application. You cannot change the license to the GPL. As far as I know (and no I have not looked at the source but I should...) the linux emulation is not taken from GPL'd code, just based on it.
Do linux people really take offence at the linux emulation in the BSD's? Wouldnt that be similar to Windows people taking offence at Linux for the WINE project?

We can't change society in a day, we have to change ourselves first from the inside out.
[ Parent ]

Nothing says you can't change the license. (4.00 / 3) (#9)
by pope nihil on Tue Jan 09, 2001 at 11:48:41 PM EST

There is nothing in the BSDL to say you can't change part of it and release under a different license. Look at what Apple is doing with their Darwin OS. The source code was originally from FreeBSD under the BSDL. Now the modified source code is under Apple's proprietary license. IIRC, much the Linux TCP/IP stack was taken from BSD and GPL'd.


I voted.

[ Parent ]
ok but... (3.00 / 1) (#33)
by UrLord on Wed Jan 10, 2001 at 03:41:22 AM EST

Well I just re-read your post and then re-read my reply and decided that you were saying about the same thing I was going to reply with (its late, Im tired ;)). Yes, I believe you can modify part of the BSD code and GPL your modification. Since I dont code and I believe the philosophy of whatever works, this argument doesnt really affect me... Dont ask why I posted, I dont know, probably the depression I get each week when battlebots is over :(

We can't change society in a day, we have to change ourselves first from the inside out.
[ Parent ]

Actually.... (none / 0) (#53)
by Matrix on Thu Jan 11, 2001 at 08:29:56 AM EST

The "Linux stole the BSD TCP/IP stack" thing is little more than a rumor. Here's a link to a Linux kernel mailing list message that seems to confirm this: http://boudicca.tux.org/hypermail/linux-kernel/1999/1999week34/0564.html

http://boudicca.tux.org/hypermail/linux-kernel/1999/1999week34/0699.html and others in the same thread seem to provide more information.


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Well... (3.25 / 4) (#15)
by simmons75 on Wed Jan 10, 2001 at 12:30:21 AM EST

>Do linux people really take offence at the
>linux emulation in the BSD's?

Well, I've heard a few zealots that have a fit about it. Personally, I think it's pretty cool. There are probably less people mad about that than people who get mad about Linux using BSD code. Both camps get ideas/code from each other. I personally don't see what the big deal is.
poot!
So there.

[ Parent ]
uhmm ok (3.00 / 1) (#34)
by UrLord on Wed Jan 10, 2001 at 03:43:34 AM EST

I havent really heard any bad comments about linux... Well about them stealing code. I dont see what the big deal is either, but since I dont code I dont really have a stake in it. Oh well, let the coders fight it out ;)

We can't change society in a day, we have to change ourselves first from the inside out.
[ Parent ]

Laughing loud and long (4.50 / 2) (#36)
by Paul Crowley on Wed Jan 10, 2001 at 08:15:51 AM EST

Those damn GPLites! They *steal* our BSD code, and even have the temerity to change the license! How dare they! Our license gives freedom, which as everyone knows theirs doesn't. We should put a special condition in the license that forbids people redistributing our software under a license that takes away the freedom we give!

...oh, wait, that would make our license the GPL. Well, anyway, moral people would appreciate the freedom we've given them by *not using it*! We'll explicitly prefer licenses that grant that extra freedom, but call using it immoral!

Seriously, what the hell is the point on insisting on the BSD license over the GPL, if it isn't that you want people to have the freedom to use your code in projects with more restrictive licenses?
--
Paul Crowley aka ciphergoth. Crypto and sex politics. Diary.
[ Parent ]
Not using (none / 0) (#47)
by yonderboy on Wed Jan 10, 2001 at 05:37:21 PM EST

The only thing GNU in FreeBSD is the tools, and these are found under /usr/src/contrib. The Linux binary compatibility is simply a loader extension. They do some syscall translation, and since they're using ELF binaries, there isn't a need to include Linux code.

By saying "it runs it's binaries! it must have it's code!" logic, FreeBSD has BSDi, Solaris, and SCO code in it too... *shudder*

[ Parent ]
YUO = TROLL (2.84 / 13) (#11)
by fluffy grue on Wed Jan 10, 2001 at 12:00:43 AM EST

YUO, SIR, AR NOT EVNE FUNNY. YUO R NOT LEET LIEK SIGNAL11, U R JUST DUM. EVRYONE KNOWES THAT THEIR IS NO LUNIX VERSIONS 1.4-1.9 AND THAT BSD IS ONLY UESD BY STUPED LONGHAIR HIPPYS IN BERKLEY, BECUS THATS WHERE ITS FROM, BERKLEY! YUO KNOW, BERKLEY SYSTEMS DIVISION! SO YUO AR OBVIOSULY A STUPED TROLL.

AND NEWAY, LUNIX HAS ALLWAYES HAD BSDS CODES IN ITS TCP/IP STACK BECAUSE EVEN THOUGH THEIR STUPED POT SMOKING HIPPYS LIKE MY FRIEND JERRY THEY SOMEHOW PUT THERE MAJIC PIXY DUST ONTO THEIR HARDDRIVES AND GOT SOME WORKING TCP/IP STACK LEET CODES.

YUO = IDIOT!
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

yay! (1.33 / 3) (#18)
by Delirium on Wed Jan 10, 2001 at 12:45:39 AM EST

cool, jeff k has a k5 account now!

[ Parent ]
And? (1.50 / 2) (#27)
by fluffy grue on Wed Jan 10, 2001 at 02:01:20 AM EST

Yes, he does, as does Lowtax, but neither of them are me. Sorry to burst your bubble. (I haven't even read Something Awful since November when I realized that Lowtax was pissing way too much on many people who didn't deserve it, calling transsexuals -- which is a medical condition -- "sick bastards" for simply existing, and the like.)

Though this wouldn't be the first time that people have started to accuse others of being Lowtax simply because they were doing a bad impersonation of his "humor." Do you think any of Lowtax's personalities would openly admit to being a transgendered casual furry fan without falling into some horrible caricature of both? Not to mention that Lowtax's "personalities" are usually pretty one-dimensional, whereas I've (hopefully) expressed a hell of a lot more depth than that. ;)
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Oh yeah (1.00 / 2) (#28)
by fluffy grue on Wed Jan 10, 2001 at 02:09:38 AM EST

Not to mention that my UID (306) kind of precludes the possibility that this account is anything "new." Oh well, I guess nobody likes to do any sort of research, especially when trying to "prove" that I am someone else (UID=7616) or one of his alter egos (UID=10820).
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

yes i know (2.00 / 1) (#30)
by Delirium on Wed Jan 10, 2001 at 02:19:12 AM EST

FWIW I knew it was you imitating jeff k, I've seen your name around here long enough to know that you're not new. =P

[ Parent ]
BSD ports (3.75 / 4) (#4)
by UrLord on Tue Jan 09, 2001 at 11:31:46 PM EST

It looks like the Linuxports team wants to create a more robust build system than BSD's (for instance, you could go into a particular program's directory and issue a 'make install'.

The BSD port tree allows for you to build one program, or a set of programs. I can cd to /usr/ports/user.bin and download/compile anything that sits in /usr/bin on my system.
Well good luck, linux needs the help ;)

We can't change society in a day, we have to change ourselves first from the inside out.

usr.bin? (3.00 / 2) (#13)
by winthrop on Wed Jan 10, 2001 at 12:19:16 AM EST

I can cd to /usr/ports/user.bin and download/compile anything that sits in /usr/bin on my system.

What BSD do you use? I use FreeBSD and I don't have any experience with any other. But on FreeBSD, the source to /usr/bin lives in /usr/src/usr.bin. You could go into /usr/src/usr.bin and make everything or even make install everything, but generally I would make the entire world if I were going to remake usr.bin (though not necessarily if I were going to remake something small).

The ports tree (on FreeBSD at least) is something entirely different. You can go into /usr/ports/category/program and make install and it will build the download/compile the program and all dependencies recursively.

[ Parent ]

doh! (3.00 / 1) (#32)
by UrLord on Wed Jan 10, 2001 at 03:33:15 AM EST

Damn, no more posting right before I leave work.... Yeah I goofed that one. *bows head in shame*

Ive used FreeBSD a little (not much since 3.2) and I use OpenBSD (who pretty much stole the FreeBSD ports tree ;)) now. Dont get to use it at work though, and havent had a modem on my system at home lately so I havent touched it in a little while. I bow to your superior knowledge. Thank you for correcting me ;)

We can't change society in a day, we have to change ourselves first from the inside out.
[ Parent ]

we all mess up (3.00 / 1) (#41)
by winthrop on Wed Jan 10, 2001 at 10:35:14 AM EST

Not a problem. I just rebuilt my entire world over the weekend so I had it fresh on my mind. Thank god for cable modems :)

[ Parent ]
cable modems (none / 0) (#50)
by UrLord on Thu Jan 11, 2001 at 12:29:37 AM EST

I have bandwidth envy :(
56k if Im lucky

We can't change society in a day, we have to change ourselves first from the inside out.
[ Parent ]

www.openpackages.org (3.66 / 6) (#5)
by kraant on Tue Jan 09, 2001 at 11:32:25 PM EST

It seems to have ground to a slow halt but you might want to look into helping http://www.openpackages.org/ .

This is the conversation that started it all and people already use netbsd packages in solaris...

I do have to say I find it interesting that you want to port a system developed on BSD primarily because of the lack of portability for most programs written on linux, to linux.

hrrrm
--
"kraant, open source guru" -- tumeric
Never In Our Names...

RPM too (3.00 / 2) (#26)
by G Neric on Wed Jan 10, 2001 at 01:35:43 AM EST

people already use netbsd packages in solaris...

and people use RPM with Solaris, too, and on a bunch of platforms.

I don't expect this will make any new converts, but if you are used to rpm it's painless, and I even like the fact that it's "different" from sun's package manager. Build up the basic box as per Sun's instructions, and then everything after that you add with rpm and you have a handy little database of your easily repeatable customizations.

[ Parent ]

Why this may be not necessary (4.50 / 6) (#6)
by tftp on Tue Jan 09, 2001 at 11:36:05 PM EST

First of all, you already can do that:

# rpm -Uvh /mnt/cdrom/RedHat/SRPMS/*.rpm
# cd /usr/src/redhat
# for i in SPECS/*.spec; do rpm -bb $i; done

But more important question is: why exactly this is needed? What is the problem you are trying to solve? The section "Why would you want this?" of the article does not answer why questions; instead it jumps directly to how.

You are trying to merge different (and competing!) distributions into "one size fits all" conglomerate. This is hardly an advantage. I can precisely control what versions of what packages I run, and quite often I upgrade some packages and hold onto older versions of other packages.

distributions are starting to diverge rapidly

That's probably people want to do things better than it is being currently done. I, as a user, would want them to continue - and then I will use whatever version I like more. Your proposal, however, tries to slow that process down.

you could periodically download patches to your local source

Users don't recompile programs! They rarely even upgrade binary packages! This system may work for developers, but then developers have no problems with existing setup either. Everyone else would be very frustrated to check out few GB of sources over 56K modem and then spend days compiling that! Bad advice.

Good points, but... (4.00 / 2) (#12)
by CanSpice on Wed Jan 10, 2001 at 12:16:46 AM EST

You make some good points. In order to have a ports tree for Linux there'd have to be some generalization of programs across the varying distributions. This is either an advantage or a disadvantage, depending on your point of view. You've spoken of the disadvantages, here are some of the advantages:

Developers wouldn't have to make RPMs, DEBs, and tar files, they'd only have to introduce their program to a ports tree (even though I'm an OpenBSD user, I have no idea how that process works). Actually, because Linux is so diversified already they'd probably have to continue making packages for each type of package manager -and- this new ports tree. Alright, a disadvantage, although it could turn into an advantage, depending on if it catches on or not.

Upgrading is way easier. As was mentioned in the article, updating something in the ports tree assumes that you're coming from some sort of ground zero with regards to dependencies. I've had so many problems trying to upgrade something seemingly simple on a Redhat install that I often don't even bother. When I upgrade on OpenBSD it's quick and painless.
--- I don't have a sig.
[ Parent ]
Good or bad? This is a question... (4.00 / 4) (#24)
by tftp on Wed Jan 10, 2001 at 01:20:24 AM EST

Developers [...] only have to introduce their program to a ports tree (even though I'm an OpenBSD user, I have no idea how that process works)

I think it could be done in the same way everywhere. You have to have a central CVS server, and then any developer can just say something like

$ cvs import newprogram firstImport foo

There is a catch: you don't want to have all eggs on one server. You can use several servers and rsync them as needed, but that's more complicated. Generally, the whole idea is better suited to centrally controlled OSes, like *BSD. Linux is a product of the crowd.

The bigger problem is what is the point of the exercise? I doubt that differences between, let's say, Debian and RedHat lay in how bzcat is invoked or how bash interprets something. Differences are mostly in how the system is organized, started up, controlled, maintained etc. The proposed solution won't work there. To achieve uniform structure and identical behavior you'd need to make all systems identical. You'd need one distribution.

To make all systems identical? That is a good approach, sometimes. MS has no headaches with odd SPARC issues, and Apple does not worry about F0 0F bug. Windows and Mac are all very predictable, and once you learned it you'll find yourself comfortably using another instance of that OS.

Will such standard help Linux? Sure it will. That's why businesses choose one distribution (RH). They don't want to worry about differences, other benefits of arguable value etc. etc. - they have work to do.

But how would you force everyone, anyone who wants to make a distribution to conform to strictest set of rules? All your startup scripts shall be in /etc/rc.d/init.d/ - what if I don't like that? Debians decided to change that (and other things too). Are they non-compliant?

I already said that the proposed solution can not solve the problem. Building of tar, gzip and other goodies will not magically change your telnetd into sshd, but that's what matters. Upgrading of RH distributions (and Debian) is very, very easy - as long as you don't jump between releases, then dependencies may haunt you (I hear you, simmons75, but that's barely avoidable, and newest apt-get will do the job for you).

So this proposal will not directly help. You still are stuck with 10,000 applications (though now of known versions). There are so many ways of running them! However the question itself - how would you want your ideal box to work - is quite interesting. Should it converge into one Windows-like blob that generally fits all, or should it stay rebelliously independent? Something in between maybe? I voted for this story, it is very appropriate and allows us as users to understand our computers better.

[ Parent ]

Not for everyone (3.00 / 2) (#14)
by simmons75 on Wed Jan 10, 2001 at 12:22:01 AM EST

And I really don't think anyone is trying to throw every distribution together. I'm sorry I wasn't clear in the story, though I did imply that this wasn't for everyone.

>You are trying to merge different (and competing!)
>distributions into "one size fits all" conglomerate. This is
>hardly an advantage.

As a current Mandrake Cooker user, I find it to be nearly impossible to help a newbie with, say, Debian. There are quite a few differences. It was a blue-sky dream on my part; the notion that a base system like this could be used to base different distributions upon. The base systems of different Linux systems can (and are!) vastly different.

>quite often I upgrade some packages and hold onto older
>versions of other packages.

That's another disadvantage of this approach, and why you wouldn't want this (as I said, this isn't for everybody.)

>Users don't recompile programs!

I really don't count myself as a developer. I guess I'm nothing because I'm not a developer, yet I recompile programs on my own. Hm...

I really don't think this software is for everybody. I really didn't intend to implly that it was. I'm sorry you misunderstood.


poot!
So there.

[ Parent ]
Re: Not for everyone (3.33 / 3) (#25)
by tftp on Wed Jan 10, 2001 at 01:34:00 AM EST

>Users don't recompile programs!

I really don't count myself as a developer. I guess I'm nothing because I'm not a developer, yet I recompile programs on my own. Hm...

You are not nothing, you are just not user :-)

The base systems of different Linux systems can (and are!) vastly different.

Exactly my point! I wrote more about it here. Debian people want to be different, how can we stop them? What right do we have to stop them? Differences between RH and Debian are not in versions of packages (all are fairly recent.) Differences are in the base system, and we can't put that into the proposed port tree.

[ Parent ]

Debian people want to do it *right* (3.33 / 3) (#35)
by goonie on Wed Jan 10, 2001 at 08:05:53 AM EST

Debian doesn't do things differently just for the sake of it. Debian does things differently because, in the judgement of the developers concerned, their way is better. On the occasions where I've personally had to deal with divergences between the Debian way, and the Rest Of The Linux World way, 9 times out of ten the Debian way IMHO better.

Disclosure: I am a (very minor) Debian developer.

[ Parent ]

Heh, that's funny... (3.66 / 3) (#39)
by simmons75 on Wed Jan 10, 2001 at 08:52:29 AM EST

...I've heard the same thing from FreeBSD developers.

*ducks*

I'm slowly coming around to the point where I might have to try Debian. If it weren't for the extreme zealots, I'd have tried it much sooner. You know the type; despite the fact the social contract forbids them from preventing it, they seem to think that corporations shouldn't profit from Debian. Or, if you ask for help with, say, Red Hat, make "witty" comments like "Oh, just apt-get install....oh, wait, I forgot, your distribution sucks."

Of course, these same types exist in the *BSD world, as well as the Red Hat world, Slackware, even Windows and, I'm sure, BeOS and MacOS, to name a few. Oh well.
poot!
So there.

[ Parent ]
Standing up for Debian... (none / 0) (#42)
by ramses0 on Wed Jan 10, 2001 at 12:59:57 PM EST

...usually I stay far away from distro wars, but I feel the need to comment on your apt-get distro-sucks comment.

Yes, your distro does suck. Debian has package management boiled down to a consistent system. If you can't do "foo --install-now apache", then yes, your distro sucks. I don't care if you use "apt-get", "wget packages.redhat.com/apache.rpm; rpm --install apache.rpm", or "wget apache.org/latest-apache.tar.gz; tar -zxvvf latest-apache.tar.gz; make; make install;"

It's all the same to me, but IMHO the reason Debian users are so snooty about package management is that Debian users don't have to worry about it anymore. You won't get much help about installing from non-apt sources, because that's not the point of Debian. You can get lots of help from Debian users with regards to configuring installed software, because that is something that's in Debian's problem domain. Configuration is something that Debian doesn't have all figured out like they have package management.

A comparison would be the linuxconf utility for RedHat. Ask a RH user how to configure networking, and they'll say "linuxconf networking" or something. When you say "I don't have linuxconf", they'll say "hah, your distro sucks" ... and they'd be right. It's just a matter of which distro doesn't suck where it's important to you.

--Robert
[ rate all comments , for great justice | sell.com ]
[ Parent ]

Suckage? (none / 0) (#46)
by itsbruce on Wed Jan 10, 2001 at 04:25:01 PM EST

Yes, your distro does suck. Debian has package management boiled down to a consistent system. If you can't do "foo --install-now apache", then yes, your distro sucks. I don't care if you use "apt-get", "wget packages.redhat.com/apache.rpm; rpm --install apache.rpm", or "wget apache.org/latest-apache.tar.gz; tar -zxvvf latest-apache.tar.gz; make; make install;"

Back when I was reading /., there was a debate about packaging. Someone marked me down as a troll for saying that rpm + rpmfind didn't come close to apt. I don't think people who haven't used apt realise what a different league it's in.

Of course, Connectiva have patched apt to work with rpm (only logical, since apt was designed to be able to be packaging-tool neutral). So non-deb distributions will be able make use of it. Not that Red Hat will, I think, since it would compete with their fee-charging RHN.

The fact that apt was designed to be packaging-tool neutral is a reason why Debian doesn't suck much. And the fact that Red Hat created RHN instead of something apt-like is why Red Hat suck more than they could.

A comparison would be the linuxconf utility for RedHat. Ask a RH user how to configure networking, and they'll say "linuxconf networking" or something. When you say "I don't have linuxconf", they'll say "hah, your distro sucks" ... and they'd be right.

Linuxconf is available for Debian - any other distro that cares to use it. Try apt-get install linuxconf. Or rather, don't. IMO, linuxconf sucks bigtime. It's a disorganised mess and often mindlessly file-orientated. Back when I was using Red Hat I removed Sendmail and replaced it with Postfix. Linuxconf repeatedly reset the permissions on Postfix's sendmail binary to the insecure Sendmail settings, even though I told Linuxconf what permissions I wanted. Eventually I just removed Linuxconf and my Red Hat box behaved much better after that. I would never install it on Debian or anything else.

Even then, though, I found Red Hat's config scripts and configuration decisions to be clunky and over-complex in a way that actually made them less flexible. It was apt that made me look at Debian (and then move to it) but the clean configuration was what made me feel as if I was coming home.

It's just a matter of which distro doesn't suck where it's important to you.

Very true.


--

It is impolite to tell a man who is carrying you on his shoulders that his head smells.
[ Parent ]
We're not all mad (none / 0) (#45)
by itsbruce on Wed Jan 10, 2001 at 03:51:09 PM EST

I'm slowly coming around to the point where I might have to try Debian. If it weren't for the extreme zealots , I'd have tried it much sooner.

Don't let the zealots put you off from a good product. Most Debian users aren't fanatics but those that are are extreme (as with Slackware zealots). I think it's because you have to be extreme to stand out when Linux in general already has so many zealots.

But the difference between Debian and Red Hat is one of excellence compared to competence. Truly. (Does that make me a zealot?)


--

It is impolite to tell a man who is carrying you on his shoulders that his head smells.
[ Parent ]
Don't worry about the zealots (none / 0) (#49)
by goonie on Wed Jan 10, 2001 at 08:31:00 PM EST

Just try the distribution. Make your own opinion. Try the user community (which are usually very helpful). Try the bug tracking system (excellent). Try apt. If you can get over the hurdle of the install (which is hard for newbies, but an improved install *is* being worked on), I'd be surprised if you weren't impressed.

[ Parent ]
A bit over the top (none / 0) (#44)
by itsbruce on Wed Jan 10, 2001 at 03:44:24 PM EST

I use Debian myself but I have to take issue with some of that:

Debian doesn't do things differently just for the sake of it. Debian does things differently because, in the judgement of the developers concerned, their way is better.

Wouldn't the Red Hat or Slackware developers say the same? How many developers do things differently so that they can fuck up, do you think?

On the occasions where I've personally had to deal with divergences between the Debian way, and the Rest Of The Linux World way, 9 times out of ten the Debian way IMHO better.

Could it not be that, for at least some of those 9 times, it was doing it the way that suited you best? Mandrake, for example, is simply not trying to do the same thing as Debian. Debian concentrates on the core system, on the essentials, on making sure that the underlying configuration is flexible and non-prescriptive (unlike, for example, the RH startx scripts that practically force you to use Gnome if it's installed) and on getting the tools right so that you can build what you like. It's very austere and expects you to know what you're doing. I like that - but others want and need what Mandrake has to offer.


--

It is impolite to tell a man who is carrying you on his shoulders that his head smells.
[ Parent ]
I don't really think you're disagreeing with me (3.00 / 1) (#48)
by goonie on Wed Jan 10, 2001 at 08:23:54 PM EST

Yes, the comment about Debian doing things differently than the consensus becuase of belief in technical merit probably does apply equally to RedHat, Slackware, and most other distributions. It's a general reason for divergence in distributions. However, Debian's preference for "get it right" to "get it out the door now before it's obsolete", while annoying if you want the latest GNOME/KDE or have brand-new hardware, generally means fewer bits of sub-optimal design and packaging that are there because there's weren't time to fix them.

However, if having the latest GNOME and automatic hardware setup is important to you, Mandrake is a better choice than Debian. You're absolutely right - different strokes for different folks.

[ Parent ]

One other point (4.00 / 2) (#19)
by simmons75 on Wed Jan 10, 2001 at 12:48:18 AM EST

I currently have an RPM-based system (development Mandrake--the Cooker) and I don't find that comment about controlling what goes on your system to be true at all. The closest I got to that was with Slackware. I find that I have to install whatever RPMs a particular RPM maintainter felt was necessary to satisfy dependencies...the move from Mandrake 7.1 to 7.2 to Cooker was particularly painful this time, requiring nearly every package to be replaced.
poot!
So there.

[ Parent ]
No need... (4.00 / 5) (#8)
by iCEBaLM on Tue Jan 09, 2001 at 11:48:37 PM EST

apt-get install <package>

-- iCEBaLM

pkg_add (4.00 / 3) (#40)
by shrub34 on Wed Jan 10, 2001 at 09:00:26 AM EST

FreeBSD has pkg_* commands.
Just pkg_add <package>

The packages are built from the ports collection and are in tarballs so you don't need to use pkg_add either.

=====
It's good to see the BSD community forking and execing so many child processes.

  • Comment about editor of Daemon News not attending BSDcon 2000

  • [ Parent ]
    ports (3.00 / 2) (#10)
    by pope nihil on Tue Jan 09, 2001 at 11:58:04 PM EST

    I know this is how it works on OpenBSD, and I can't think of any reason it would work differently on FreeBSD (since that's where Open got the original ports thing), but it's quite a bit simpler than the procedure described above.

    # cd /usr/ports/loosely_related_program_type/program_i_want_to_install
    # make
    # make install



    I voted.

    too much typing (3.00 / 1) (#38)
    by coolvibe on Wed Jan 10, 2001 at 08:42:35 AM EST

    # cd /usr/ports/loosely_related_program_type/program_i_want_to_install
    # make
    # make install
    Uhm, just make install will do fine. Saves another 5 keystrokes (yes, I count <enter> too)


    --
    Yet another community site: hackerheaven.org. Now in juicy Scoop flavour!
    [ Parent ]

    Heh (none / 0) (#43)
    by simmons75 on Wed Jan 10, 2001 at 02:26:36 PM EST

    I don't know; I guess I'll just have to read through the BSD Makefiles. I guess I'd personally be to paranoid to do this. It depends on how the Makefile is written whether or not this works. I guess I'm just paranoid :-)
    poot!
    So there.

    [ Parent ]
    The BSD make process (none / 0) (#51)
    by Ixokai on Thu Jan 11, 2001 at 05:45:23 AM EST

    Except.. no.. it doesn't depend on how the Makefile is written whether or not this works. When you type just 'make install' in say, /usr/ports/editors/glimmer, it is actually doing multiple steps in the process. I don't remember them all, because I don't use them, but for instances it does: make fetch (may not be the name, but the step to download the files) make extract make configure make patch (may come before configure; don't recall) make make install Each of those steps first executes some global code. The fetching one looks in the port make file for the package, and downloads it. The extract target .. extracts it.. into a working directory. Then you have configure, which will if nessecary run GNU configure, patch, actual building, and finally, 'installing'. This has nothing to do with individual program makefiles. They are irrelevent. This works for all ports. The make file that you are using here, the '/usr/ports/editors/glimmer/Makefile' is not a program makefile, it is a series of variables and an included global makefile that handles the ports process. The actual program's makefile which is only called in the building portion of the process is in '/usr/ports/editors/glimmer/work/glimmer-(version)/Makefile' (or something like that). No offense, but being afraid to just run 'make install' in the ports tree is not paranoia, but a lack of understanding of what's going on and what's automated.

    [ Parent ]
    Duh me. (none / 0) (#52)
    by Ixokai on Thu Jan 11, 2001 at 05:46:20 AM EST

    And, i'm dumb.. Forgot to put some line-breaks in there like I intended, and stupidly didn't preview. Oops. :)

    [ Parent ]
    Now, wait a minute :-) (none / 0) (#54)
    by simmons75 on Thu Jan 11, 2001 at 01:32:00 PM EST

    I was thinking of special cases when an individual writes a stupid Makefile rule, like this:

    install:
    cp dumbprogram /usr/bin

    I'm not an expert on Makefiles (when I write them, I have an O'Reily book in hand) but I guess that could even be automagically handled...

    poot!
    So there.

    [ Parent ]
    What? (4.00 / 2) (#16)
    by pb on Wed Jan 10, 2001 at 12:34:14 AM EST

    I've never seen a Linux distribution that didn't use the GNU Tools by default and gcc for the compiler. As a user, I've never been confused by the default tools in a distribution. It's more standardized than Solaris, and it comes with a compiler; what more standardization could you want?

    Some of the admin tools are different, but we don't need a 'ports' tree for that. And I definitely don't want the BSD binutils! Once I went GNU, there was no going back; I can't stand the old limited options to ls, ps, du...

    Of course, this is just my experience, and I'm sure other people love their classic commands; forgive me my addiction to "ls -arlS" and "ps -uxw"; you can continue to use "ls -arls | sort -n" and "ps -ef", and suffer their inferior output. ;)
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall

    heh (3.00 / 1) (#17)
    by simmons75 on Wed Jan 10, 2001 at 12:36:12 AM EST

    afaik this uses all GNU stuff. At least, it looks like it uses GNU binutils.

    Calm down. We're just talking about a BSD-alike build process.
    poot!
    So there.

    [ Parent ]
    Oh, ok. (3.00 / 1) (#21)
    by pb on Wed Jan 10, 2001 at 01:07:35 AM EST

    Sorry about that; whenever I hear BSD people talking about ports, they're generally bragging that they can recompile all their system utils at once, (god that must take forever) and of course they're all native BSD utils, which bug me to no end...

    So I don't care how you build it all, and I thought there were packaging systems like that, as well. Whatever happened to Encaps? I never used it, but it always sounded like a good idea.
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]

    My view on encap (4.00 / 1) (#23)
    by simmons75 on Wed Jan 10, 2001 at 01:20:19 AM EST

    I haven't used it lately. I've heard that it's gotten raftloads better than when I used it, and when I used it, it was good. The only thing is that you need to know how to relocate packages when you build them (with GNU-type stuff, you can do that when you configure: ./configure --prefix=/usr/local/encap/[packagename]. Then, after you make install, just run encap. Ditto for when you remove a directory from the /usr/local/encap dir. All encap did back then was make symlinks to the /usr/local/encap/[packagename] dir, then remove them if you ever removed the package dir from the /usr/local/encap dir. Pretty neat, pretty slick.
    poot!
    So there.

    [ Parent ]
    Linux vs BSD (2.57 / 7) (#20)
    by enterfornone on Wed Jan 10, 2001 at 01:03:28 AM EST

    This is crap, there are at least 4 distributions of BSD and they are are hardly standardised across the line. Saying FreeBSD is standardised is like saying Redhat is standardised. Linux is a lot more standardised across distributions than the various distributions of BSD.

    --
    efn 26/m/syd
    Will sponsor new accounts for porn.
    Yep (2.60 / 5) (#22)
    by simmons75 on Wed Jan 10, 2001 at 01:12:17 AM EST

    Actually, I was aware of that. There's FreeBSD, OpenBSD, NetBSD, and if you count Darwin... :-)

    I just didn't want to start the flamewar by including the "which is a crock of shit" that I thought to myself when I was writing this.
    poot!
    So there.

    [ Parent ]
    The BSDs are not "distributions" (4.16 / 6) (#29)
    by Nat Lanza on Wed Jan 10, 2001 at 02:13:17 AM EST

    No. FreeBSD, NetBSD, and OpenBSD are not "distributions". They are separate, independently developed operating systems that share a common heritage. They look a lot alike and often share code, but they are not distributions of the same operating system in the way that, say, Debian and Slackware are.

    And yes, the BSDs are somewhat different from each other. Since they're developed separately and have different goals, this is to be expected. However, there are efforts to make sure that the differences don't grow too great.

    For example, people are working on unifying the package systems -- FreeBSD and OpenBSD's /usr/ports, NetBSD's /usr/pkgsrc, and so forth -- into a single unified tree that all of the BSDs can use. The project is called OpenPackages, and looks promising.

    [ Parent ]

    You seem to be a bit confused... (4.50 / 4) (#31)
    by Nat Lanza on Wed Jan 10, 2001 at 02:23:50 AM EST

    It looks like the Linuxports team wants to create a more robust build system than BSD's (for instance, you could go into a particular program's directory and issue a 'make install'.
    Er, what? You might want to look into the ports systems that the BSDs use. As far as I know, they can all do this already. Since there are thousands of applications in FreeBSD's /usr/ports, it wouldn't be very useful if you couldn't do this and instead had to install them all at once.

    Also, you seem to be a bit confused about what exactly /usr/ports is. It's not the FreeBSD build system; instead, it's a collection of third-party packages packaged up so that they will build and install cleanly and automatically in a FreeBSD-friendly way. Sometimes this involves patches to the package's source, and sometimes it's just specific build instructions.

    The FreeBSD build system lives in /usr/src, and builds the base system (kernel and userland) completely from scratch from sources. It's what uses 'make world', not /usr/ports.

    Another nitpick:

    The name is meant to be reminiscent of the FreeBSD Ports section, mostly software ported from Linux and put into a build tree.
    Descriptions like this irk me. Linux != Unix. The packages in the FreeBSD ports system come from all sorts of different sources, and many predate Linux. It is certainly not a collection of ported Linux applications.

    eh, hehe (3.50 / 2) (#37)
    by simmons75 on Wed Jan 10, 2001 at 08:27:53 AM EST

    /*
    Also, you seem to be a bit confused about what exactly /usr/ports is. It's not the FreeBSD build system; instead, it's a collection of third-party packages packaged up so that they will build and install cleanly and automatically in a FreeBSD-friendly way.
    */

    I'll have to read through what I'd written again. I hadn't meant to leave that impression. :-} I'm actually quite aware of what the ports section is. The Linuxports project, though, seems to have morphed into something more than simply a Ports-like project into an acutal world build system. That's what I found exciting about it.

    >The FreeBSD build system lives in /usr/src, and builds the base system
    >(kernel and userland) completely from scratch from sources. It's what
    >uses 'make world', not /usr/ports.

    Believe it or not, I have a nearly-complete set of NetBSD sources on my Linux box, from when I was trying to get some of the *BSD sources to build on a Linux box. I was actually aware of this. Talk to the person running the project; I see no reason to move it, since /usr/src usually gets used for other things (on my system, only the kernel and RPM use /usr/src.)

    >Descriptions like this irk me. Linux != Unix. The packages in the
    >FreeBSD ports system come from all sorts of different sources,
    >and many predate Linux.

    I guess I'm tainted by the Linux crowd; that, and I've read through the mailing lists about the many complaints people had about adding software to the Ports tree that had been written by Linux people. I suppose it depends on your definition of "many." ;-)
    poot!
    So there.

    [ Parent ]
    Linuxports | 54 comments (53 topical, 1 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!