Ah, but I have been exposed to alternatives. Back in the ol' CS college days, I had to write stuff for Suns and SysV machines--and I learned pretty quickly that I could do the SysV stuff at home on my own machine if I had a Linux box.
Mind you, I didn't jump in feet first half-cocked. I asked around. I debated with myself. Ultimately, I talked to a genius of a man who had used both FreeBSD and a Linux box, and he described some of the differences, and why he couldn't use FreeBSD in the class.
After that, I haven't looked back since.
Really, your comment doesn't make sense. I understand that one might want to consider FreeBSD (it has it's cool points--hell, I'd cream my jeans if I could "make world" my Linux box:^) but, quite frankly, the question pertained to Linux. I seriously doubt you'll win any *BSD users just due to the fact that it has dynamically-resizable ramdisks.
What the original poster wanted is kinda irrelevant, anyway. There are far better ways of speeding up a Linux box than this, and I'm sure the tricks are identical or at least similar to the FreeBSD comment. So the original post was trolling.
PS FreeBSD isn't UNIX for the same reason Linux isn't UNIX. UNIX is a brand. Neither are branded UNIX. I remember at one point Caldera was working on getting their distro branded as a SysV UNIX, but I don't know what's happened since.
>How many linux developers right(sic) truly
>portable apps?
How many *BSD developers write truly portable apps?
Probably the same answer for both Linux and *BSD camps--not nearly enough.:^(
My example is the standard utils like ls, chown, etc., that ship with FreeBSD. It's not because of that "it ain't GNU/Linux" argument, although it was due to that argument that I got the ambition to try this. It was just because I wanted to be able to say that, when I use "ls", it's The Real Thing(TM).:^) The build process kicks ass, but I'm not anywhere close to getting it to work under Linux. I was happy to see, tho, that someone wrote a really simple little Makefile in the "make" dir so I could build the BSD make without writing my own makefile.:^) The build process, tho, is *totally* specific to FreeBSD. OTOH, apparently the GNU utils compile with little prob on other platforms. I've never done it, though, so I really can't comment on that.
As far as platform-independence of Linux-specific apps, it depends on who wrote it and how they wrote it.
One argument I've heard is that "gee, Linux is just a kernel; FreeBSD is a whole system, and there's only one FreeBSD." Yeah, but there's more than one BSD. If a Linux distro conforms to the filesystem standard, and sticks to what has become fairly standard on other distros, and doesn't contain, say, assembly language code, a proggy will compile (and run) on a good number of distros (and will compile on different platforms.)
This statement pertains only to Linux. For those distros that don't stick to convention, well, they're not very popular so we don't care.:^)
If the proggy comes with a decent "configure" script, there shouldn't be that many problems. If someone goes off half-cocked and writes their own Makefile (believe it or not, that can be a problem:^( ) then you might have to do some rewriting.
>One shouldn't pretend portability where none
>really exists.
Ooh, I'm impressed; a brash statement without a single example. Thank you, I'm so informed.:^(
It sounds like we're making the same point--you have trouble compiling Linux apps, I have trouble compiling BSD apps.
>The number of times I've had to fix a linux app
>so i could run on Solaris or BSD is very high.
Funny; back when I was taking a system programming course in college, we did our programming projects on Sparc Stations and a SMP SysV machine. When we did the stuff on the Sparc, I had to do everything on one of their stations--my stuff from home wouldn't compile nicely on the Suns.
When it came time to do SysV stuff, though, I had to stop using the Suns and was actually able to do everything at home on a Slackware box--with no code modification whatsoever. This was pretty simple stuff, though, so the argument may not be relevant. Your mileage may vary.:^)
>it costs at least $20,000 to record even a >lamely-produced album
Nirvana's Nevermind album comes to mind. Much less than $20,000 (I think it was aroun $8,000)
Your original post had some extremely useful and thought provoking points--but seemed a bit biased. You seem to imply that cost is the *only* reason free software is popular, and that the only people producing free software are naive college students being supported entirely by Mommy & Daddy.
That is so damn offensive...okay, I won't let you bait me into flaming. Linus Torvalds works for Transmeta. ESR, well, hell, I don't know what he does, but he makes money by speaking. Ditto for RMS. Other people like Alan Cox have found (*gasp*) jobs that pay *and* allow them to muck around in free software.
Personally, I respect free software *much* more than commercial software. Yeah, it's kinda cool when I realize that when I'm using, say, Photoshop that I may be using code that was developed to do things like, say, re-work the original Star Wars trilogy.:^) But, really, even though Gimp isn't as powerful, it's damn good at what it can do. Ditto for Sketch, an alternative to using Illustrator. It isn't nearly as full-featured as Illustrator, but doesn't cost a week or so's wages and if I need some feature, I can spend a rainy Saturday or so hacking something together.:^)
Valid point, even though you only have the 0. This may explain, also, why RAM disks aren't really any faster on a Linux box than just reading from disk.
Yeah, I'd love to know WTF some idiot was thinking when this was moderated as a troll. It's a valid point. God, I hate it when some moron gets moderator status. (this from the guy with permanently-stuck 5 karma...which is why I tear new holes all the time...cause it has no effect...)
My suspicion is that an examination of the disk cache code might be beneficial for the RAM disk cache. Although I don't know for sure, I'd bet that there's some RAM disk "thrashing" and there's no benefit from having RAM cache. I'd bet that the code for ramfs is totally FUBAR. Someone else here claimed that ramfs allows dynamic resizing; this could be a slowdown factor too, perhaps. I'm just guessing here, brainstorming. But I haven't looked at it (the code) and don't intend to until at least later today...if ever.
Why not? I really don't have any interest in doing this. I used to do this sort of thing on my old Tandy 1000; copy over a few oft-used DOS utils at boot time into memory. It was only useful if I didn't need to do any work with any apps (the machine only had 640k) and because the thing only had a 5 1/4" 360k disk. The RAM disk wasn't resizable except to edit CONFIG.SYS and change the parameters for VDISK, then reboot (funny how some things don't change:^). Worked like a dream if you needed it.
You can thank the same guy who brought you Eterm for rxvt having cool features (tho I don't think he did the "transparency" crap.) Rasterman gave rxvt pixmap support. (He did that around the time E was still known as FVWM-XPM or something like that.)
>Yes, but the question is, WHY are we talking
>about Linux here.
The answer, from the original post.
>Does Linux support dynamically reseizing Ram
>Disks? Surely they would be vital in remote >booting, diskless thin clients."
If you think that it's a viable option, why not help draw up some sort of plan for porting the solution? Or did you *really* think that you could persuade someone to use FreeBSD? If your plan was the latter, you're just another troll.
I'm not sure what SMP capability has to do with portability or RAM disks, but I'd have to agree. Linux machines seem to be built to work with tools like the GNU tools; FreeBSD is BSD (as close as a *BSD can come to being exactly like another) and therefore works with FreeBSD and...well...FreeBSD.
Try to compile FreeBSD's "chmod" on a Linux box sometime. Ugh. (Yeah, I know; that's irrelevant too.:^)
True, and also remember that polls are only as good as:
1.) What questions are asked
2.) How they are asked
I recently helped conduct a survey for a book store. It included information such as, say, rating a person's favorite radio station and what newsapers they read.
The problem? The survey left out *frequency.* The poll was designed to help us determine what media we wanted to advertise on, and the people responsible for putting together the survey blew it.
That being said, I really don't think that MSNBC would willingly throw the results toward Windows...they've been known to run stories that paint a fairly unflattering picture of Microsoft. Maybe they just do this once in a while to try to maintain an illusion of credibility, but it's a point in their favor.:^)
Amen. And, besides, XML is essentially an over-glorified style guide. Yeah, it's great that so many folks are working toward a single style for writing files. But not everything has to be XML. XML can't walk my dog, either, even if I write a definition for .:^)
>While I know I'll be burned at the stake for
>saying good things about FreeBSD on slashdot
Some brilliant person decided to flame you for apparently being a karma whore. This strikes me as a statement of truth.:^) In truth, the *BSD and Linux worlds share more than the average 13-year-old-mentality Slashdot reader realizes. I honestly wish we had learned some more FreeBSD lessons by now.:^) I don't envy them, though, since their system seems to go at the Deb...er, snail's pace at adopting new features. Ah, well. Perhaps we can find a happy medium someday.:^)
You've got it all wrong. Yeah, I know you're trolling. Ya got me. You got the bastard who's karma is permanently stuck at 5. So bite me.
How have you got it wrong? Well, I've watched people make comments about, say, *BSD in a discussion like this and get a (0, Offtopic) or a (-1, Troll) or something like that. Most of the time they're not. Why were they marked trolls? Because people like to rant enthusiastic with such witty comments like "Fuck you; we're talking about Linux not *BSD" and so on.
What's wrong with the attitude? THEY'RE NOT THINKING!!! It never occurs to them that they might learn something. Ever, say, taken a look at the FreeBSD build tree? BRILLIANT! It's so simple a trained monkey could build it from source. Will we learn from it? Heck no; it's FreeBSD. (NOTE: smarter people will.)
Putting the "I know I'll get modded down for this" usually ensures that the person reading the comment will stop and think before they start ranting, or, worse, the karma whores with new moderator status start knocking them down for thinking. (Bad person. Double plus ungood think!)
I don't know; maybe it's just me, but I think that packaging systems are just a workaround for the fact that UN*X-like filesystems weren't really meant for folks installing/uninstalling a bunch of crap all the time. UN*X machines seem to be designed to be kinda like a telephone: you use it, you occasionally have to make moderate changes to change with the times, but not much happens in the way of change.
I rather like FreeBSD's way of doing things; the fact that you can rebuild a system by issuing a single "make" just gives me goosebumps.:^) It'd be kinda nice if the *Linux community were that organized. Unfortunately, there's not that kind of organization; we're not as bad as *BSD but not as good as FreeBSD, if you know what I mean.
Still not sure? What I mean is that there's not one standard distro, like, say, call it FreeLinux. Have a standard committee (yeah, I know; people will be screaming "Debian!" and they can scream all they want.) and build *one* source tree.
The only thing I would change about the FreeBSD-style build is to allow for changes to the base without upsetting the main build. Perhaps have standard stuff like the kernel, libc, gcc, X11, etc. as part of the standard build and maintain things like KDE, GNOME, specific graphic support like Glide drivers, etc. separate. These should be separate in the sense that one could pull them out easily. How could that be done? Well, I'm partial to Encap, but that's just me.:^)
Yeah, I think that's sad that only one comment was made on the new BSD packaging system, and an abusive one than that. Yeah, the folks that read Slashdot are kinda biased.:^) The only reason I've been aware of the *BSD world lately is that I've been trying to build a set of standard BSD utils for Linux, mainly for shits & giggles.:^) (BTW if anyone is working on this and has any clues for me, let me know.)
Encap supplies that kind of functionality. The following example implies that you have a more-or-less properly packaged source tree (i.e. autoconf & buddies)
./configure --prefix=/usr/local/encap/[packagename]
make; make install
encap
and encap makes symlinks to/usr/local/bin,/usr/local/lib, etc. When it comes time to uninstall the package, you simply remove the directory and run "encap", which removes the symlinks associated with the package.
It saves an incredible number of headackes and (you'll appreciate this, drsoran) a lot of *time.* Especially if you don't have a lot of itme to burn. (Sorry; couldn't resist a Dr. Soran joke:^)
>One of the problems with RPM is that they arean't >always relocatable. The packager has to give you
>the option for that to work. Now I don't
>know whether or not that works with quake, but if
>you take enlightenment as an example, it isn't
>relocatable.
Sorry, I thought it was important to quote the whole thing.:^)
This is exactly true. The thing is, RPM's powerful feature set is dependent upon the packager to implement features like this.
You've stumbled upon a debate that's been raging a while: how do you make a package manager that can put files in the filesystem in a relocatable way and still not break anything and everything? I personally vote for a re-work of Encap, but that's just me.:^)
And you've stated the problem right there. All you need to do this with a *Debian* system.
Linux is a kernel, and most distros call themselves [Blah] Linux. So many variations, all known as [Blah] Linux. I'd like to see something more generic, meself. NE1 care to help build a tree so I can do a "make world" on a Linux box?:^)
Or, for that matter, NE1 care to tell me what includes I'm going to need to complete my build of *BSD standard utils on a Linux box? I've got the install subdir, and I've grabbed some stuff from the kernel, but I don't have everything. Any *BSD porters care to help me out here? TIA.:^)
I was just looking at FreeBSD's source because I'm working on porting their/bin/usr/bin &/usr/sbin (for starters) just for the hell of it. What I've noted (although this will be obvious to most readers:)
1.) The whole system can be rebuilt by issuing a make.
2.) there's a possibility of merely patching an existing system.
3.) there's only one code base.
It might be nice of the LSBP to keep a list of "current" projects and to help maintain a FreeBSD-like set of buildable dirs, allowing an entire system to be built.
Alternatively, it'd be fun to put together a distro that does this--I talked to a guy around 4 years ago who was working on this at one time, the main problem being that Linux is merely a kernel and doesn't have a centralized authority as strong as other OSs. It would be nice to be able to, say, download a gzip'ed patch file, apply it to my source tree, and issue a 'make world' and have the whole system rebuilt before my eyes.
True...but one doesn't have to use NoMad to use Encap. I actually use Encap on a Linux-Mandrake box(!) to keep track of what packages I've installed by source, rather than making my own RPMs.
Yes, this tends to break RPM, but hey, the article *is* about problems with RPM.:^)
>I'd like to thank... The *BSD crew, for >constantly being the research arm for anyone who >can't do their own research.
I see...you say that as though you don't appreciate that happening. I see.
So, if I am to understand you correctly, every time someone goes to build a new OS, they should start anew. I see! We could extend this to other industries as well! I can see the fun now. Ford, for example, hiring large teams to determine how:
1.) A good, cheap way to propel a vehicle
2.) A good, cheap way for a vehicle to "roll"
3.) A way for the locomotion source to deliver energy to the devices that allow the vehicle to "roll"
The research position possibilities are endless! Wow, Larry Wall won't have time to write Perl anymore, because he'll be too busy inventing a written language every time he needs to commit his thoughts to something other than verbal language...as soon as someone invents a way of recording a written language...and something to put that written language on...
User: Hello? I spoofed a post on Slashdot because I didn't think it was funny, and thought if I did it in a funny way, that people would see how stupid the original post was.
Hotline: *clears throat* And?
User: Everyone's calling me a lame-ass son of a bitch because some people thought it was funny. WTF is wrong with people?
True, but if you can explain to me how, say, RCA and/or Universal are infringing on basic inaliable human rights, clue me in.
It seems the Revolution has failed anyway; the name of the government has changed, the department names have changed; but the big supposed problem, namely extreme taxation, is back.
The American Revolution was nothing but a carefully-orchestrated coup to protect business interests.
Slashdot Mirror
Ah, but I have been exposed to alternatives. Back in the ol' CS college days, I had to write stuff for Suns and SysV machines--and I learned pretty quickly that I could do the SysV stuff at home on my own machine if I had a Linux box.
:^) but, quite frankly, the question pertained to Linux. I seriously doubt you'll win any *BSD users just due to the fact that it has dynamically-resizable ramdisks.
Mind you, I didn't jump in feet first half-cocked. I asked around. I debated with myself. Ultimately, I talked to a genius of a man who had used both FreeBSD and a Linux box, and he described some of the differences, and why he couldn't use FreeBSD in the class.
After that, I haven't looked back since.
Really, your comment doesn't make sense. I understand that one might want to consider FreeBSD (it has it's cool points--hell, I'd cream my jeans if I could "make world" my Linux box
What the original poster wanted is kinda irrelevant, anyway. There are far better ways of speeding up a Linux box than this, and I'm sure the tricks are identical or at least similar to the FreeBSD comment. So the original post was trolling.
PS FreeBSD isn't UNIX for the same reason Linux isn't UNIX. UNIX is a brand. Neither are branded UNIX. I remember at one point Caldera was working on getting their distro branded as a SysV UNIX, but I don't know what's happened since.
>How many linux developers right(sic) truly
:^(
:^) The build process kicks ass, but I'm not anywhere close to getting it to work under Linux. I was happy to see, tho, that someone wrote a really simple little Makefile in the "make" dir so I could build the BSD make without writing my own makefile. :^) The build process, tho, is *totally* specific to FreeBSD. OTOH, apparently the GNU utils compile with little prob on other platforms. I've never done it, though, so I really can't comment on that.
:^)
:^( ) then you might have to do some rewriting.
:^(
:^)
>portable apps?
How many *BSD developers write truly portable apps?
Probably the same answer for both Linux and *BSD camps--not nearly enough.
My example is the standard utils like ls, chown, etc., that ship with FreeBSD. It's not because of that "it ain't GNU/Linux" argument, although it was due to that argument that I got the ambition to try this. It was just because I wanted to be able to say that, when I use "ls", it's The Real Thing(TM).
As far as platform-independence of Linux-specific apps, it depends on who wrote it and how they wrote it.
One argument I've heard is that "gee, Linux is just a kernel; FreeBSD is a whole system, and there's only one FreeBSD." Yeah, but there's more than one BSD. If a Linux distro conforms to the filesystem standard, and sticks to what has become fairly standard on other distros, and doesn't contain, say, assembly language code, a proggy will compile (and run) on a good number of distros (and will compile on different platforms.)
This statement pertains only to Linux. For those distros that don't stick to convention, well, they're not very popular so we don't care.
If the proggy comes with a decent "configure" script, there shouldn't be that many problems. If someone goes off half-cocked and writes their own Makefile (believe it or not, that can be a problem
>One shouldn't pretend portability where none
>really exists.
Ooh, I'm impressed; a brash statement without a single example. Thank you, I'm so informed.
It sounds like we're making the same point--you have trouble compiling Linux apps, I have trouble compiling BSD apps.
>The number of times I've had to fix a linux app
>so i could run on Solaris or BSD is very high.
Funny; back when I was taking a system programming course in college, we did our programming projects on Sparc Stations and a SMP SysV machine. When we did the stuff on the Sparc, I had to do everything on one of their stations--my stuff from home wouldn't compile nicely on the Suns.
When it came time to do SysV stuff, though, I had to stop using the Suns and was actually able to do everything at home on a Slackware box--with no code modification whatsoever. This was pretty simple stuff, though, so the argument may not be relevant. Your mileage may vary.
>it costs at least $20,000 to record even a >lamely-produced album
:^) But, really, even though Gimp isn't as powerful, it's damn good at what it can do. Ditto for Sketch, an alternative to using Illustrator. It isn't nearly as full-featured as Illustrator, but doesn't cost a week or so's wages and if I need some feature, I can spend a rainy Saturday or so hacking something together. :^)
Nirvana's Nevermind album comes to mind. Much less than $20,000 (I think it was aroun $8,000)
Your original post had some extremely useful and thought provoking points--but seemed a bit biased. You seem to imply that cost is the *only* reason free software is popular, and that the only people producing free software are naive college students being supported entirely by Mommy & Daddy.
That is so damn offensive...okay, I won't let you bait me into flaming. Linus Torvalds works for Transmeta. ESR, well, hell, I don't know what he does, but he makes money by speaking. Ditto for RMS. Other people like Alan Cox have found (*gasp*) jobs that pay *and* allow them to muck around in free software.
Personally, I respect free software *much* more than commercial software. Yeah, it's kinda cool when I realize that when I'm using, say, Photoshop that I may be using code that was developed to do things like, say, re-work the original Star Wars trilogy.
Valid point, even though you only have the 0. This may explain, also, why RAM disks aren't really any faster on a Linux box than just reading from disk.
Yeah, I'd love to know WTF some idiot was thinking when this was moderated as a troll. It's a valid point. God, I hate it when some moron gets moderator status. (this from the guy with permanently-stuck 5 karma...which is why I tear new holes all the time...cause it has no effect...)
:^). Worked like a dream if you needed it.
My suspicion is that an examination of the disk cache code might be beneficial for the RAM disk cache. Although I don't know for sure, I'd bet that there's some RAM disk "thrashing" and there's no benefit from having RAM cache. I'd bet that the code for ramfs is totally FUBAR. Someone else here claimed that ramfs allows dynamic resizing; this could be a slowdown factor too, perhaps. I'm just guessing here, brainstorming. But I haven't looked at it (the code) and don't intend to until at least later today...if ever.
Why not? I really don't have any interest in doing this. I used to do this sort of thing on my old Tandy 1000; copy over a few oft-used DOS utils at boot time into memory. It was only useful if I didn't need to do any work with any apps (the machine only had 640k) and because the thing only had a 5 1/4" 360k disk. The RAM disk wasn't resizable except to edit CONFIG.SYS and change the parameters for VDISK, then reboot (funny how some things don't change
You can thank the same guy who brought you Eterm for rxvt having cool features (tho I don't think he did the "transparency" crap.) Rasterman gave rxvt pixmap support. (He did that around the time E was still known as FVWM-XPM or something like that.)
>Yes, but the question is, WHY are we talking
>about Linux here.
The answer, from the original post.
>Does Linux support dynamically reseizing Ram
>Disks? Surely they would be vital in remote >booting, diskless thin clients."
If you think that it's a viable option, why not help draw up some sort of plan for porting the solution? Or did you *really* think that you could persuade someone to use FreeBSD? If your plan was the latter, you're just another troll.
I'm not sure what SMP capability has to do with portability or RAM disks, but I'd have to agree. Linux machines seem to be built to work with tools like the GNU tools; FreeBSD is BSD (as close as a *BSD can come to being exactly like another) and therefore works with FreeBSD and...well...FreeBSD.
:^)
Try to compile FreeBSD's "chmod" on a Linux box sometime. Ugh. (Yeah, I know; that's irrelevant too.
True, and also remember that polls are only as good as:
:^)
1.) What questions are asked
2.) How they are asked
I recently helped conduct a survey for a book store. It included information such as, say, rating a person's favorite radio station and what newsapers they read.
The problem? The survey left out *frequency.* The poll was designed to help us determine what media we wanted to advertise on, and the people responsible for putting together the survey blew it.
That being said, I really don't think that MSNBC would willingly throw the results toward Windows...they've been known to run stories that paint a fairly unflattering picture of Microsoft. Maybe they just do this once in a while to try to maintain an illusion of credibility, but it's a point in their favor.
>but why does everything have to be XML based?
:^)
:^) In truth, the *BSD and Linux worlds share more than the average 13-year-old-mentality Slashdot reader realizes. I honestly wish we had learned some more FreeBSD lessons by now. :^) I don't envy them, though, since their system seems to go at the Deb...er, snail's pace at adopting new features. Ah, well. Perhaps we can find a happy medium someday. :^)
Amen. And, besides, XML is essentially an over-glorified style guide. Yeah, it's great that so many folks are working toward a single style for writing files. But not everything has to be XML. XML can't walk my dog, either, even if I write a definition for .
>While I know I'll be burned at the stake for
>saying good things about FreeBSD on slashdot
Some brilliant person decided to flame you for apparently being a karma whore. This strikes me as a statement of truth.
No, no, no.
You've got it all wrong. Yeah, I know you're trolling. Ya got me. You got the bastard who's karma is permanently stuck at 5. So bite me.
How have you got it wrong? Well, I've watched people make comments about, say, *BSD in a discussion like this and get a (0, Offtopic) or a (-1, Troll) or something like that. Most of the time they're not. Why were they marked trolls? Because people like to rant enthusiastic with such witty comments like "Fuck you; we're talking about Linux not *BSD" and so on.
What's wrong with the attitude? THEY'RE NOT THINKING!!! It never occurs to them that they might learn something. Ever, say, taken a look at the FreeBSD build tree? BRILLIANT! It's so simple a trained monkey could build it from source. Will we learn from it? Heck no; it's FreeBSD. (NOTE: smarter people will.)
Putting the "I know I'll get modded down for this" usually ensures that the person reading the comment will stop and think before they start ranting, or, worse, the karma whores with new moderator status start knocking them down for thinking. (Bad person. Double plus ungood think!)
I don't know; maybe it's just me, but I think that packaging systems are just a workaround for the fact that UN*X-like filesystems weren't really meant for folks installing/uninstalling a bunch of crap all the time. UN*X machines seem to be designed to be kinda like a telephone: you use it, you occasionally have to make moderate changes to change with the times, but not much happens in the way of change.
:^) It'd be kinda nice if the *Linux community were that organized. Unfortunately, there's not that kind of organization; we're not as bad as *BSD but not as good as FreeBSD, if you know what I mean.
:^)
:^) The only reason I've been aware of the *BSD world lately is that I've been trying to build a set of standard BSD utils for Linux, mainly for shits & giggles. :^) (BTW if anyone is working on this and has any clues for me, let me know.)
I rather like FreeBSD's way of doing things; the fact that you can rebuild a system by issuing a single "make" just gives me goosebumps.
Still not sure? What I mean is that there's not one standard distro, like, say, call it FreeLinux. Have a standard committee (yeah, I know; people will be screaming "Debian!" and they can scream all they want.) and build *one* source tree.
The only thing I would change about the FreeBSD-style build is to allow for changes to the base without upsetting the main build. Perhaps have standard stuff like the kernel, libc, gcc, X11, etc. as part of the standard build and maintain things like KDE, GNOME, specific graphic support like Glide drivers, etc. separate. These should be separate in the sense that one could pull them out easily. How could that be done? Well, I'm partial to Encap, but that's just me.
Yeah, I think that's sad that only one comment was made on the new BSD packaging system, and an abusive one than that. Yeah, the folks that read Slashdot are kinda biased.
Encap supplies that kind of functionality. The following example implies that you have a more-or-less properly packaged source tree (i.e. autoconf & buddies)
/usr/local/bin, /usr/local/lib, etc. When it comes time to uninstall the package, you simply remove the directory and run "encap", which removes the symlinks associated with the package.
:^)
./configure --prefix=/usr/local/encap/[packagename]
make; make install
encap
and encap makes symlinks to
It saves an incredible number of headackes and (you'll appreciate this, drsoran) a lot of *time.* Especially if you don't have a lot of itme to burn. (Sorry; couldn't resist a Dr. Soran joke
>One of the problems with RPM is that they arean't >always relocatable. The packager has to give you
:^)
:^)
>the option for that to work. Now I don't
>know whether or not that works with quake, but if
>you take enlightenment as an example, it isn't
>relocatable.
Sorry, I thought it was important to quote the whole thing.
This is exactly true. The thing is, RPM's powerful feature set is dependent upon the packager to implement features like this.
You've stumbled upon a debate that's been raging a while: how do you make a package manager that can put files in the filesystem in a relocatable way and still not break anything and everything? I personally vote for a re-work of Encap, but that's just me.
>All you need to do this with a Debian system
:^)
:^)
And you've stated the problem right there. All you need to do this with a *Debian* system.
Linux is a kernel, and most distros call themselves [Blah] Linux. So many variations, all known as [Blah] Linux. I'd like to see something more generic, meself. NE1 care to help build a tree so I can do a "make world" on a Linux box?
Or, for that matter, NE1 care to tell me what includes I'm going to need to complete my build of *BSD standard utils on a Linux box? I've got the install subdir, and I've grabbed some stuff from the kernel, but I don't have everything. Any *BSD porters care to help me out here? TIA.
I was just looking at FreeBSD's source because I'm working on porting their /bin /usr/bin & /usr/sbin (for starters) just for the hell of it. What I've noted (although this will be obvious to most readers:)
1.) The whole system can be rebuilt by issuing a make.
2.) there's a possibility of merely patching an existing system.
3.) there's only one code base.
It might be nice of the LSBP to keep a list of "current" projects and to help maintain a FreeBSD-like set of buildable dirs, allowing an entire system to be built.
Alternatively, it'd be fun to put together a distro that does this--I talked to a guy around 4 years ago who was working on this at one time, the main problem being that Linux is merely a kernel and doesn't have a centralized authority as strong as other OSs. It would be nice to be able to, say, download a gzip'ed patch file, apply it to my source tree, and issue a 'make world' and have the whole system rebuilt before my eyes.
*Sigh* I can dream, can't I.
Yeah...and it shouldn't be a place for whiny bastards either...oh, well.
True...but one doesn't have to use NoMad to use Encap. I actually use Encap on a Linux-Mandrake box(!) to keep track of what packages I've installed by source, rather than making my own RPMs.
:^)
Yes, this tends to break RPM, but hey, the article *is* about problems with RPM.
>I'd like to thank... The *BSD crew, for >constantly being the research arm for anyone who >can't do their own research.
I see...you say that as though you don't appreciate that happening. I see.
So, if I am to understand you correctly, every time someone goes to build a new OS, they should start anew. I see! We could extend this to other industries as well! I can see the fun now. Ford, for example, hiring large teams to determine how:
1.) A good, cheap way to propel a vehicle
2.) A good, cheap way for a vehicle to "roll"
3.) A way for the locomotion source to deliver energy to the devices that allow the vehicle to "roll"
The research position possibilities are endless! Wow, Larry Wall won't have time to write Perl anymore, because he'll be too busy inventing a written language every time he needs to commit his thoughts to something other than verbal language...as soon as someone invents a way of recording a written language...and something to put that written language on...
OK, it's Saturday. Save the logic humor for the week. :^)
Hotline: Hello, Humor-Impaired Support.
User: Hello? I spoofed a post on Slashdot because I didn't think it was funny, and thought if I did it in a funny way, that people would see how stupid the original post was.
Hotline: *clears throat* And?
User: Everyone's calling me a lame-ass son of a bitch because some people thought it was funny. WTF is wrong with people?
Hotline: You're a lame-ass son of a bitch.
User: *hangs up*
You actually think we give a fuck whether or not *you* think it's funny.
Now that's funny.
And to think, I thought that the Maximum Linux crew was too lame to even know what a compiler was.
Oh mah Gawd!!! Paw!!! We kin git sum barls made right special just ta shoot badgers!!!
God, that's funny. I wonder what RMS would say to this...God, what a riot.
True, but if you can explain to me how, say, RCA and/or Universal are infringing on basic inaliable human rights, clue me in.
It seems the Revolution has failed anyway; the name of the government has changed, the department names have changed; but the big supposed problem, namely extreme taxation, is back.
The American Revolution was nothing but a carefully-orchestrated coup to protect business interests.