Slashdot Mirror
FreeBSD 4.3 Released
jesseraf was one of the first to write, and now that the release is official we can post this. Release notes are available, or find the nearest mirror.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
We have to things to thank for for the Release Notes.
First, we use a source management tool (namely CVS), so all changes made to the source code are documented at the time they are made. This makes it much easier to keep track of what they are.
Second, Bruce A. Mah, who volunteered for the generally tedious but very important job of actually reading the commit logs and then keeping the Release Notes up to date for both -current and -stable branches.
Let me take this opportunity to thank him for it.
(8-DCS)
Er, does anyone else notice that every time a new release of BSD, Linux, or Mozilla comes out, someone says this exact same thing? And their post usually is numbered less than #20 or so?
Hmm....
I never could figure out how the whole "ports" thing worked though... maybe I was a little too impatient to spend the five minutes required to figure it out. *shrugs*
/usr/ports/path/to/port/
/usr/ports/irc/bitchx/)
# cd
(say
# make && make install
(then you wait: code is donloaded, compiled, installed)
That's it. Dependent packages are installed automatically. There are commands to remove packages, etc. Until 4.3 there wasn't a pkg_update command, but all you had to do was delete the old version (1 command) and re-install.
To use the ports tree in this way you need to devote some disk space (70MB or so?) to the makefiles, so the system knows what to go fetch and compile. Typically you keep the ports tree updated on your system via cvs.
I prefer the FreeBSD method to Debian (which I tinker with) for 2 reasons.
1. There is a while direcory tree of software for me to browse. I don't have to hit the web looking for the magic string to apt-get.
2. I learned it first.
Well, it's simple. If you support the running-dog capitalist lackeys by using a BSD licensed product, you are contributing to the problem of corporatism. BSD users are causing children to be buried in shallow graves. They are allowing the "IP cartels" to control all of our access to information. The BSD license will date your sister, and then it will make calls to 900 numbers with your mom's credit card number.
The BSD license seems to allow "freedom," but that's only if your idea of "freedom" is being free to get STDs from the taxi-load of cheap hookers that your FreeBSD box will have delivered to your home.
You may think that it's OK to use the "right tool for the job," but if you use BSD, you are Bill Gates' tool, and don't you forget it.
(For the sarcasm impaired: this has been a sarcastic post making fun of the license war between BSD and GPL. Thank you.)
I've noticed a recent trend towards trashing FreeBSD's SMP because of "the giant spinlock." What people don't realize is that one large spinlock can be a viable method of locking for the purposes of threading (that is, multiprocessing). It would seem that someone who has a moderate clue about threading and writing SMP-capable operating systems has commented on this, and feels it's bogus, and one or more of the general breed of "BSD is ubersux" trolls has gotten a hold of this and thinks it's the ultimate death knell for FreeBSD/smp. Obviously, you don't really know much about locking at all. It should at least be pointed out that no matter how many locks you have, it is more important to keep the system OUT of a locked state as much as possible, and FreeBSD does this well enough. It's not as if the system is constantly locked and able to use only one CPU. Most processing occurs in userland, far away from kernel locks, so it doesn't tend to matter all that much.
Now, granted, using one spinlock isn't necessarily the best way to do things, at least not in an OS. However, it's not the worst either. Combined with the fact that it allowed fairly rapid updating and deployment of FreeBSD/SMP, I think the choice to use that 'giant spinlock' was valid. It allowed SMP code that by all accounts worked better at least than the 2.0 Linux kernel's (if not 2.2 as well) to be deployed until a better solution could be created. A better solution will be deployed in FreeBSD 5.0 with the introduction of SMPng. I do not doubt that the 2.4 Linux kernel does a better job at SMP than FreeBSD (release/stable) does, but I think it's worth noting that Linux's SMP has been now five or six years in the making to get to this point, and that the Linux and FreeBSD development and advancement models are significantly different. Where Linux takes gradual steps, FreeBSD (and BSDs in general) tend to take large leaps. That's just a difference in implementation timing.
Furthermore, it's perfectly reasonable to expect two open-source systems to leapfrog each other in terms of capability as ideas and code move from one to the other, and it's really not something to gloat over. What one does better today, the other will do better tomorrow. It doesn't really matter.
To those of you babbling on and on about 'the giant spinlock', you might want to go do some research into the theory, and practice, of implementing locks in threaded systems. Until then, shut up, please.
-wd
--
chip norkus(rl); white_dragon('net'); wd@routing.org
mercenary albino programmer for hire
"question = (to) ? be : !be;" --Shakespeare
...that I _REALLY_ hate slashdot...
Crusing along at several hundred k a second.. all of a sudden it starts slowly dropping.. down to double digits.. then single digits.. After trying to reconnect a few times I give up and check slashdot.. only to realize.. grumble.. I guess I won't be getting FBSD anytime tonight!
The funny thing is, I was upgrading an old compute from 4.1.1 to what I thought would be 4.3-RC, but ended up getting the -RELEASE instead. They must've just switched it on the server!
In any event, this is sufficiently hidden from the moderators that nobody will ever read this, so I don't know why I bothered to type all this. In fact, I think I'm going to stop typing right n....
Why anyone would need to read the manual for this is beyond me.
Umm, because there's a bit more to it. More than likely you'll want to get your source tree all up to date, tweak in your kernel config, and get all your user land stuff in sync. A great site for a to the point summary on all this is the FreeBSD Cheat Sheets. This site also includes specific instructions on how to make world.
Personally, my "make buildworld" is running now in the background as I type this. Just cvsup'd the latest source changes, and away she goes! Couldn't care less about getting an ISO for a CD burn. By keeping the tree up to date every week or so it only takes about 5 minutes per update across a dial-up connection. Every couple of months I run through the make world process and everything is up to date.
Oh sure, this here build takes a while on this K6-450. It's running in the background, so it can take as long as it wants.
The line must be drawn here. This far. No further.
whoa dude...you have to get a faster CD-ROM drive or something...6 years is a hell of a long time for a Slackware install. i have an old quad-speed lying around here somewhere...i'll send it to you if you want. even off floppies, Slackware shouldn't take more than an hour or two.