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)
I just finished installing 4.2 and was testing it by logging into Slashdot. Pardon me while I start downloading again.
No it doesn't. Go to MacNN and see how many Mac users find it quite different. Not all of them dislike it. Many like the changes. Many do not. Look at the threads on making the Finder more "Mac like", or even for running the old OS9 Finder. Look at Apple's own movies of how different OSX is. Or head back to MacNN and watch them bitch about how much worse the Dock is then the application bar.
Now I like OSX, but I'm not a Mac user. I'm a Unix geek. I bought a Mac to run OSX, and I can tell you it feels totally different, to the point that OS9 apps that run under Classic "emulation" are jarring.
I'll admit they mostly don't. A few complain about not being able to change all the files and stuff. Many complain about the slowness, which I assume has something to do with it being run on top of Unix and not retuned enough. Well that, and Objective C's late binding :-)
Most just don't care for the new finder and look n' feel, and yeah that has nothing to do with Unix.
In case you wish to do a Binary upgrade instead of a "by source" upgrade as explained elsewhere in this thread (and in the handbook) ... what You basically do is:
... and select the Upgrade option
- grab the boot-disks (kern.flp and mfsroot.flp)
- boot from those
FYI, 2.4 extended file sizes to 64 bits on intel arch with ext2. Now there is no 2GB limit. Also, 2.4 stopped doing a block/inode check on boot when mounting fses, 2.2 and below would do an inode/block check on an fs even if it was marked clean. For very large fses, it boots MUCH faster now.
I'm happy about the > 2GB support and LVM stuff, because I run DB servers on Linux.
Changes since 4.2 are at:
http://www.freebsd.org/releases/4.3R/notes.html
Dave
I write a blog now, you should be afraid.
If this is your first build world, Read the handbook on building your world.. It's actually easier than a linux kernel build.
If that's the case, why can't you just tell us?
I never had to read a handbook on building linux.
Who knows why this guy suggested the handbook.. But anyway, here it is:
make buildworld compiles everything
make installworld installs the results of make buildworld
make world compliles and installs everything.
Why anyone would need to read the manual for this is beyond me.
ISP problems to be exact. They had to get a whole new server anddrop it somewhere else and update the DNS. This timed with the release of 4.3 has made things hairy. From what I can tell everything is back up now though.
this space for rent
That isn't really a troll. Solaris on x86 is an afterthought by Sun. Hardware support is light, and ide is horrible. Plus it expects SMP all the time. Solaris x86 was created to get peopleto use solaris and work into their hardware which is what they really want to sell. Another nice thing, when many vendors say they support solaris they mean only SPARC.
this space for rent
Not at all. It's you that are being pig-headed. I was clear enough: the kerberos problem with Microsoft was a result of a problem with the protocol, not a problem with the license.
Microsoft embraced and extended the protocol,
Correct. More to the point, they used a loophole in the protocol so what they wrote is technically Kerberos but as a matter of fact result in incompatibilities between computers running their implementation and computers running others.
and almost definitely the code (why not, when it's there for the taking?).
So you think they used the code, eh? Well, FYI, they didn't.
Thanks to their proprietary business model,
Well, a true sentence. You are improving.
aided and abetted by freely available code licensed under BSD-like licenses,
Huh? In what way? Explain. And, more to the point, explain exactly what would have happened differently if Kerberos had only been available as GPL code. Remember: they wrote their own implementation.
free software currently has no easy legal way to be to compatible.
Protocol design. Either you forbid any extensions, or people can screw up. And they can screw up even if extensions are forbidden. As a matter of fact, they can screw up even without extending anything (hello 3Com Home Connect Dual Speed!).
On the other hand, they could use a proprietary, non-documented protocol, which they could extend to keep things incompatible as they see fit (hello AOL!), or even patent the whole protocol. See real world examples.
You must understand that I am taking a long term view. In the long term, producing code under a BSD-style license may encourage vendors to adopt 'standards' but it allows them to extend and appropriate them too.
Corporations can extend any standard, no matter the license of existing source code implementing it. The license is utterly irrelevant.
In other words, it encourages the Microsoft business model.
Yeah, you are right. If they simply did not adopt the standard at all, they wouldn't extend/appropriate it.
Of course, unless the standard became popular. In which case they would simply write their own version of whatever it is and extend/appropriate it the same way, and then kill off the competition with marketing and market share. Just like they do nowadays.
Code released under viral Free-software licenses is different. True, traditional software houses won't base products upon it initially.
s/initially/ever/
Unless it's a stand-alone product, in which case the virus is irrelevant.
But if enough good viral-free software is produced and used, then businesses lose the option. They either compete against the software head on, or build upon it and release more viral-free software.
Go on...
If they compete against it, they are at a disadvantage compared to those who work with it, because they can't build on the freely available work.
Yeah, right, like anyone does.
Code reusability is a myth. Libraries, yes. Simple-minded routines here and there, skeletons for things like drivers. Beyond that, which is no real advantage, code isn't reused.
But the real problem with this line of thought is pretty simple: it assumes the best code wins. When did that ever happen? Get real.
If they work with it, they can't appropriate it, and the user wins. Code released under BSD-style licenses just slows this process down.
Excellent analysis. Of course, the premises are flawed, but if they were true, then you would be right.
The prevalence of TCP/IP has less to do with no-strings free implementations and more to do with a large pre-existing infrastructure developed by the defence and research communities, and that it works very well, if we ignore security.
Suuuuuuuuuuuuuure. I wonder how did we run Bitnet, the research community network, so long without a TCP/IP stack. And I look at all the other very extensive networks and wonder what happened to them. I look at the world-wide X.25 and wonder where did it go.
And I look back and all I can recall is how the only wan protocol I could run on my PC/XT was TCP/IP.
(8-DCS)
You seem misinformed. The Kerberos thing was a problem with the protocol specification, and had absolutely nothing to do with any software license whatsoever.
On the other hand, BSD code promotes standards because vendors actually use them. You _won't_ see Microsoft use GPL code in their mainstream products. Ever. Period.
That's why TPC/IP is everywhere, for example. There were many networking protocols in the 80s, but only one which had a free implementation available without strings so every OS maker under the sun added it to their operating systems.
(8-DCS)
Check this man page, and the links from it.
On the other hand, both Linux and FreeBSD have been able to deal with the problem you describe like forever. Just set limits on login.conf for FreeBSD, and probably something similar on Debian.
(8-DCS)
Funny that while you criticize FreeBSD's NFS, you seem to have forgotten that Linux NFS is broken beyond hope.
(8-DCS)
>Meanwhile, FreeBSD suffers from old, stodgy code written by core Unix developers with >1980's-style development practices. Sorry, but the art and science of software >engineering have improved vastly, and Linux developers are *NOT* afraid of saying, >"Okay, our implementation of xyz is flawed, let's throw it away and do it again". So >Linuxleapfrogs FreeBSD and will continue to do so.
Uh, ok, let me see if I can feed the troll here. I can count some of the things that have experienced major retrofits in the recent past:
3.0 series - implementation of SMP (not so good)
port to the Alpha architecture
complete overhaul of SCSI layer to move to cam (ftp.freesoftware.com would be nowhere near as good without this)
introduction of vinum software/hardware RAID
4.0 series - major rewrite of virtual memory by Matt Dillon (not the movie star, and I believe his work was helpful to reworking linux vm as well)
IPV6 support - all new code written by the
USB support, stable a few months before linux
move to pcm audio drivers as the default drivers for sound cards, replacing the old OSS code (which still is available for compatibility)
integration of IPfilter as an alternative to ipfw
implementation of pthreads - licq and friends wouldn't even compile in the pre 3.4 era
DRI kernel modules - can be tough to get working (voodoo 3+ w/ xf 4), but it's there if you've got the time
5.0 series - SMPng in progress (should put FreeBSD back in competitive smp territory on a par with linux 2.4 hopefully)
libh project to modularize the install process (allow X and text installers) and break the system into smaller packages
openpackages - use the same build scripts for all BSDs (not really 5.0 but still a work in progress)
ongoing work on porting FreeBSD to sparc, powerpc, and arm
kqueues - which look like a good alternative to poll() and select(), though I have no experience with them
So I don't know what the heck you're talking about. Sure, Linux tends to move things into the stable branch more quickly than BSD and there are a lot more releases, but we get along just fine. From what I've heard, the FreeBSD kernel is a bit more elegant than the Linux kernel because code is less likely to be included unless it meets the committers' standards.
Linux development moves at a breakneck pace, FreeBSD is more conservative. What does that tell us? Absolutely nothing.
This is a bit of a flame, but some of the reasons that there haven't been as drastic of changes in BSD as Linux is that some systems have been high quality from the get-go. They drew on well-tested mature code (BSD Lite) that had already had a lot of the bugs worked out.
How many times has the Linux TCP/IP stack been reworked, like 4? The only place where I can see a halfway coherent argument is in the filesystem. It would be nice to see a journaling filesystem that would give better metadata performance than FFS + softupdates, but all the implementations are under the GPL. As it is FFS does fairly well and is more reboot tolerant than ext2 and until recently had Linux beat for large (> 2gig) files.
FreeBSD puts out a quality, coherent system that is stable and performs quite well on uniprocessor systems (and soon SMP). So long as they keep doing that, I'll be a devoted FreeBSD (and Debian) user.
I had the same problem with the mouse and got around it by not using moused. Instead, just use the raw device in X and set your device to /dev/psm0 (or whatever) and Protocol to Auto.
AFAIK, this was fixed by 4.2 anyway. I don't use moused as I find little need the mouse in the console. Terminals in X or straight keyboard for the servers suits me just fine.
Hmmm...
/etc/exports:
/mnt
contents of
# This is the NFS server at home
/usr/local/export (ro)
/home (rw)
#end contents
killall -HUP rpc.nfsd rpc.mountd
From another Linux machine:
mount server:/usr/local/export
works fine. How is that broken beyond hope?
(No, I wouldn't expect to use it in a data center. I'm perfectly happy using it at home to share files and serve up my home directories. But it's not "broken beyond hope" IMHO.)
Aside from all that Stormix, Easel, Slackware, Indera (linux based) all gone... Bye bye...
Aside from the fact that I think you meant Indrema, not Indera (because I've never heard of Indera, but I could just be stupid), you're horribly horribly wrong about Slackware. It's still doing quite fine and the 7.2 release should be coming along soon. Just because Wind River didn't decide to hire the Slack team does NOT mean that it's a dead distribution.
And if it gets interrupted, that doesn't matter either, because it'll just pick up where it left off as its changes are bound by softupdates as well. Isn't that neat?
-bugg
Oh, great!
4.3BSD has been out for over 14 years now and you finished upgrading today...
I found the nearest mirror, but all I see is myself!
It was a good thing. MIT wrote code to support their infrastructure. Because of the MIT License, corporations were able to expand and adapt that system to build systems for their network. As a result, we have other Kerberos networks, and Kerberos is used.
Had MIT put it under the GPL, there would be no Kerberos. Without the ability to get machines supporting Kerberos, MIT would have scrapped the project. If they couldn't run Athena off Kerberos, no reason to have developers there.
Their is the theoretical notion that Sun would have GPL'd Solaris to support Kerberos. Fat chance. The companies will ignore GPL'd code, while BSD code creates standards and growth that benefits real users.
The GPL theoretically benefits users. The BSD actually does.
Alex
Kerberos is under the MIT License. It was developed as part of a research project. It was released for a good reason, they let the OS Vendors port it to their systems.
MIT WAS NOT going to handle the Solaris, Ultrix, HP-UX, and Irix (all Athena systems in time) ports, and they needed it to all play nicely. As MIT had a HUGE Unix system, vendors played nice to get the sales, which both got a large Unix installation and their system in front of MIT students.
Kerberos was developed to provide a secure environment for MIT Computing. Lots of University research is government funded. Tax-payer research financed should be available for EVERYBODY, not just those that you consider "worthy." Sorry, Microsoft and its investors pay their share of taxes (and probably more than most of us do), and they should be able to reap the rewards of the tax-payer research, just as the Free Software/Open Source crowd do.
MIT Released Kerberos because they built it for their needs, MIT IS and MIT LCS are not business trying to maximize profits, releasing it furthered their needs, and releasing it bettered mankind.
MS extended Kerberos using a portion designed for vendor extensions. They did this for backwards compatibility for their systems.
Their older domain system was proprietary, this one is too. So what that they used Kerberos code. None of YOU wrote Kerberos, why should you have a say how it was used. MIT's research project turned platform is benefiting Microsoft customers, who happen to be people. MIT's licensing choice benefitted a class of people that all of you trolls would like hung out to dry.
Know your history, TCP/IP did get chosen because of the BSD availability and as a result, it ran on all the machines of the era. DARPA used it because Berkeley wrote it, released it, and Berkeley's version of the OS ran on the prevalent machines, so the Unix OS and TCP/IP became big.
Alex
You never know, he could be doing a network install ... from Pluto.
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX
Woah, dude. That's not bad security, that's bad system administration. Try looking, for example, at resource limits on shells. ulimit and the like.
Vintage computer games and RPG books available. Email me if you're interested.
The release announcement didn't go out until the iso was available at: ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/IS O-IMAGES/4.3-install.iso
.
--
--
We have fought the AC's, and they have won.
FreeBSD is also available via anonymous FTP from mirror sites in the following countries: Argentina, Australia, Austria, ... Thailand, Elbonia, the Ukraine and the United Kingdom, among others.
Makes it easier for Dilbert to get his FreeBSD when he's working on site.
You must be new to slashdot. Here we don't just make things up... Perhaps you'd like to try again... Don't worry, you'll get the hang of clicking the pretty buttons before too long.
All lies!
1. DSL sucks and is unstable/unusable at any promised speed
2. Who gives a flying rats ass about how pretty the installer is? (Maybe winblows users...)
3. SMP is working great.
At the risk of being immodest, I thought my response was a clever and funny parody of the original post. As to the moderation of "informative", the moderator was replying in kind -- with humor. If you can't chuckle, turn off your computer, go outside, get some fresh air, and don't come back in until your sphinctor contractions stop.
Let's keep to the facts and look at the numbers.
Slashdot readers stated that there are 7000 nearly identical posts of your anti-BSD spam. How many people actually believe it? Let's see. The number of intelligent Slashdot posts versus your anti-BSD spam is roughly in ratio of 500 to 1. Therefore there are about 7000*500 = 3,500,000 Slashdot users who are annoyed by your idiotic spam. A recent article put your spam at about 80 percent on the nonsense scale. Therefore there are many thousands of Slashdot readers who know that you are full of crap. This is consistent with the number of Slashdot posts stating so.
Due to the trouble you have thinking, abysmal IQ test scores and so on, you will be lucky to go out into the business world and land a job at McDonalds.
All major surveys show that your anti-BSD spam has steadily gotten more annoying. You are very sick and your long term survival prospects are very dim -- especially if your identity becomes known. If you are to survive at all it will be among other idiots, trolls, and the mentally ill. Interest in your anti-BSD spam continues to decay. Nothing short of a miracle could revive it at this point in time. For all practical purposes, you are completely brain dead.
Let's keep to the facts and look at the numbers.
Slashdot readers stated that there are 7000 nearly identical posts of your anti-BSD spam. How many people actually believe it? Let's see. The number of intelligent Slashdot posts versus your anti-BSD spam is roughly in ratio of 500 to 1. Therefore there are about 7000*500 = 3,500,000 Slashdot users who are annoyed by your idiotic spam. A recent article put your spam at about 80 percent on the nonsense scale. Therefore there are many thousands of Slashdot readers who know that you are full of crap. This is consistent with the number of Slashdot posts stating so.
Due to the trouble you have thinking, abysmal IQ test scores and so on, you will be lucky to go out into the business world and land a job at McDonalds.
All major surveys show that your anti-BSD spam has steadily gotten more annoying. You are very sick and your long term survival prospects are very dim -- especially if your identity becomes known. If you are to survive at all it will be among other idiots, trolls, and the mentally ill. Interest in your anti-BSD spam continues to decay. Nothing short of a miracle could revive it at this point in time. For all practical purposes, you are completely brain dead.
On March 24th, BSD accomplished what Linux has been promising for years now. They put the power of Unix into a desktop system and made it available to the masses.
The launch of Mac OS X is turning Apple into the largest distributor of Unix, and more specifically BSD Unix. Now anyone with a desire to run Unix can purchase it for about the same cost as a Microsoft operating system. For the regular user, it looks and acts just like a MacOS user would expect. However, all the features that make it Unix are easily tapped into by the developers and power users who want to take the OS to its limits.
Now, BSD is poised to take over another segment the Linux crowd has been vying for -- the embedded market. Embedded Linux has been a hot topic of late, as new companies are trying to get into the market space.
However, the business-unfriendly GPL has played a key role in keeping Linux from being adopted by major players in the embedded arena. Especially in embedded systems, retailers don't want to be forced to make their code changes available. When you have to heavily adapt the software to work with your hardware and internal systems, the viral GPL can make keeping your code safe impossible. Instead they have chosen the more intellectual-property-friendly BSD license to protect their business interests, while leveraging the Open Source community.
Wind River, already an international player in the embedded systems market, announced today the purchase of BSD/OS from BSDi (not the company, just the rights to the software). The remainder of what was BSDi will be spun off into a hardware company called iXsystems. Inc. The new company will sell high-end server machines pre-loaded with BSD/OS and FreeBSD.
As part of the deal, Wind River has hired Jordan Hubbard to become their principal technologist for FreeBSD. Jordan is one of founders of FreeBSD and has been the chief PR representative for the project. According to Jordan, FreeBSD will remain unchanged; however, Wind River promises expanded funding for the project -- the primary thing that has been holding it back.
However, the license isn't the only reason BSD was chosen. Wind River executives said there were three reasons. First, that BSD has unparalleled technology. Second, that they love the way the open source BSD is organized compared to the disarray of the multitude of Linux Distributions. And third, the BSD license is very business friendly. It allows customers to build applications without losing intellectual property.
It also allows Wind River to build a seamless solution, combining all of its internal software properties to meet customer needs. When asked why it chose BSD over the other options, the company replied, "Frankly there was no contest."
Wind River will continue to market BSD/OS and leverage FreeBSD as a means of accelerating development and innovation. With Jordan Hubbard on board, they will be able to utilize the 2.5 million users and developers of FreeBSD.
With Wind River targeting the embedded market, and Apple putting BSD on Desktop, BSD's future looks really bright.
Linus who? That cartoon character from Charlie Brown?
360 degrees of Karma
FreeBSD ritalin 4.1-RELEASE FreeBSD 4.1-RELEASE #0: root@ritalin.deficiency.org:/usr/src/sys/compile/L UCIFER i386
/kernel: psmintr: out of sync (0040 != 0000). /kernel: psmintr: out of sync (00c0 != 0000). /kernel: psmintr: out of sync (0080 != 0000).
Good to know its out, however I hoped they fixed their moused issues
Apr 20 10:56:20
Apr 20 17:25:30
Apr 21 23:45:42
Aside from the nitpicking, why isn't this section updated a bit more, there are some good articles regarding the BSD's being posted at sites like DaemonNews, Deadly.org, etc.
p.s. to the moron who always post those moronic "BSD is dying... I think you should take a look at how many Linux distros, and Linux based customers went under these past few months before you troll
MTV's True Life (unabashed)
360 degrees of Karma
Its always a Cisco
Thank you for reading this comment.
I'll acknowledge the different licensing models, but as I'm not a developer, my main concern is having access to a free (beer) *nix OS that can run on pc hardware. I've used FreeBSD, Redhat, and Debian. Correct me if I'm I'm wrong, but has anybody else noticed they are all *nix based, and therefore *similar*? Why the hell do people have this urge to seperate themselves into distict camps and fight over who is more 1337? It's a frickin computer, people! Not a religious war.
I use windows for some things, linux for others, *BSD for another, and if I have the time, inclination, or disk space, some other *fringe* OS that grabs my fancy.
I like to geek out with different OSes. If someone can provide me a flame-free explanation of why it is that geeks have to whip out their dicks over what OS they use, I'd love to hear it.
This post coming to you from MSIE on Win2k, routed through RH Linux, my other box is FreeBSD, and if I had another box, it would probably run on hamsters. Cheers
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)
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.
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.