Slashdot Mirror

I'm a heavy Linux user. Why don't I use BSD?

I have a better question, as I don't care why you don't use FreeBSD: why do you feel obligated to tell us why you don't use it? If Linux works for you, great. Quite honestly all of your points are moot from my point for view for the following reasons:

1) This depends on your definition of a "desktop." To me, a Laptop is not a Desktop. If they were the same thing, why would they have different prefixes, Desk- and Lap-? I've used Fedora Core and I think it makes a Lousy Desktop. It has too many things I don't use installed in the default Desktop install. FreeBSD makes a much better desktop, with a much tighter install, while keeping all the bells and whistles *I* like. My opinion though. Since this is a subjective thing, I would say this point is moot and completely relative to the user.

2) Why would you need SMP for a standard desktop? And while I would Agree that FreeBSD doesn't do SMP Gracefully, it still does it basically the same way as Linux does from a theorhetical standpoint. I would argue the same thing that Matt Dillon argues - the basic underlying ideas behind both Linux and FreeBSD's SMP model are flawed and ungraceful. Check out the DFly site for more details. Technically, this is a moot point and is only a matter of time before FreeBSD is at the same level as Linux...i would argue they're so close right now the difference is insignificant.

3) While you might be correct with mindshare, there is not correlation between quantity of mindshare and quality of the final product. While the linux kernel is generally good, due to the decentalized nature of the linux community in general you end up with literally thousands of different distributions for different purposes, most of which are redundant and virtually useless. With BSD you have four to five different "distributions" with generalized goals - FreeBSD (server/workstation performance), OpenBSD (security), NetBSD (portability/stability), DragonFly BSD (cutting edge research/kernel-level innovations), and Darwin/OS X (general desktop optimization). While most interesting packages are indeed developed on linux, the majority run fine on all BSD's, with FreeBSD being compatible with the majority of the so-called cool linux-developed apps, including binary commercial linux games. FreeBSD also has binary 3D acceleration on x86 if you use an nVidia card, just like Linux. Moot point.

4) You mention the learning curve. Trust me, when i moved from linux to FreeBSD, there was virtually no learning curve. The RC system is much more sensical than the init.d system in my opinion. /etc/rc.conf controls base-system-level startup scripts with a simple binary switch (i.e. sshd_enable="YES"). User-installed programs with startup scripts are controled by their own files in /usr/local/etc/rc.d. To activate these, generally you just move prog_name.sh.sample to prog_name.sh. The system will then start it up the next time you reboot. The scripts are also startable from the commandline by root, without need for a reboot. Package management is as easy as pkg_add -r [progname] for binary packages, or simply installing something from the ports directory. The program is then patched and compiled from source. Simple. It would take you, if you're an advanced linux user, probably a weekend to get up to speed on how to admin a FreeBSD machine, and maybe a week to master it.

5) As for patches, you'll probably notice by checking out the FreeBSD website there hasn't been a security advisory in the base system since December 1st, 2004...more than a month ago. When they tag a source tree as stable, you better fucking believe it's stable. Ports, however, may introduce security vulnerabilities as they're programs not directly controled by the freebsd project, perse. If there's a program that the ports team feels isn't secure, they won

But gag still needs to be reconfigured when you add a new OS. boot0 on the other hand, requires no configuration, and therefore is vastly superior, especially when coupled with something like boot2.

Bigger caches will only worsen this problem; but the drive makers "need" to keep up these lies to win benchmarks. Aargh.

Basically, the BSD licence is similar to PHK's (another FreeBSD developer) Beer-Ware Licence

* "THE BEER-WARE LICENSE" (Revision 42):
* <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you
* can do whatever you want with this stuff. If we meet some day, and you think
* this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp

ps. Now this" is really funny! :)))))

The Freebsdhas the best explanation of this, but it should work for all Unix-ish sydtems. It's at

http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/serialcomms.html

I might have missed something here but I really don't understand all the fuzz about Linux nowadays. I thought I did back in the days when I had no first hand experience about any Unix variants. After I got familiar with GNU/Linux I realized how messy it was, having to be all the time ready to build a new kernel and reboot. Repeat for every single machine. Shame on the admin that dared to go for a vacation. Anyone who has heard about Murphy must realize those are the most likely days for a brand new vulnerability to be released.

As I sought for alternative I heard that BSDs can do the same things as GNU/Linuxes but without all the hassle. Since no media had ever mentioned a word about them, I though they were only for 24 / 7 hackers and not have the least bit of user-friendliness. But as soon as I heard that FreeBSD is easier to install than Gentoo I gave it a try.

Now, a year later, security hasn't been a reason for even a single boot for the server I set up. This is the first BSD server I've installed and I succeeded in first try. Meanwhile I hear all the time my fellow Linux admins having to suppress their normal use while compiling a new kernel and swearing a lot when having to do this at short notice, which does happen many times a year. Quite a lot of them have now switched to some BSD or are looking forward to switching.

For what I've heard from NetBSD admins, it's quite about the same as FreeBSD but without a menu-based installer and a better alternative for ports, pkgsrc. Luckily pkgsrc is a multi-platform software, being available as source but also as pre-built binaries for many BSD and GNU/Linux distros, including FreeBSD, Debian, OpenBSD, Slackware, Solaris, Darwin and so on.

Since I've found ports being sometimes a bit clumsy and I don't like its principle of "all software being updated as soon as possible" as much as pkgsrc's "software being updated after testing giving updates for many programs at a time", my next Unix variant of choice could be NetBSD or FreeBSD with pkgsrc installed instead of ports.

The big question is, what better do GNU/Linuxes really offer than BSDs? And which of these things could have already been achieved with a larger user and developer base, ie. if all the hype wasn't just about Linux?

I might have missed something here but I really don't understand all the fuzz about Linux nowadays. I thought I did back in the days when I had no first hand experience about any Unix variants. After I got familiar with GNU/Linux I realized how messy it was, having to be all the time ready to build a new kernel and reboot. Repeat for every single machine. Shame on the admin that dared to go for a vacation. Anyone who has heard about Murphy must realize those are the most likely days for a brand new vulnerability to be released.

As I sought for alternative I heard that BSDs can do the same things as GNU/Linuxes but without all the hassle. Since no media had ever mentioned a word about them, I though they were only for 24 / 7 hackers and not have the least bit of user-friendliness. But as soon as I heard that FreeBSD is easier to install than Gentoo I gave it a try.

Now, a year later, security hasn't been a reason for even a single boot for the server I set up. This is the first BSD server I've installed and I succeeded in first try. Meanwhile I hear all the time my fellow Linux admins having to suppress their normal use while compiling a new kernel and swearing a lot when having to do this at short notice, which does happen many times a year. Quite a lot of them have now switched to some BSD or are looking forward to switching.

For what I've heard from NetBSD admins, it's quite about the same as FreeBSD but without a menu-based installer and a better alternative for ports, pkgsrc. Luckily pkgsrc is a multi-platform software, being available as source but also as pre-built binaries for many BSD and GNU/Linux distros, including FreeBSD, Debian, OpenBSD, Slackware, Solaris, Darwin and so on.

Since I've found ports being sometimes a bit clumsy and I don't like its principle of "all software being updated as soon as possible" as much as pkgsrc's "software being updated after testing giving updates for many programs at a time", my next Unix variant of choice could be NetBSD or FreeBSD with pkgsrc installed instead of ports.

The big question is, what better do GNU/Linuxes really offer than BSDs? And which of these things could have already been achieved with a larger user and developer base, ie. if all the hype wasn't just about Linux?

At the risk of burning my karma, I don't think this is acceptable.

The parent (modded at +4 right now!) made its first appearance on the FreeBSD mailing lists, with the false signature "Maxim Hermion", in order to imitate the name (and the email address) of the FreeBSD committer Maxime Henrion.
Here's what Maxime Henrion (the real FreeBSD committer) writes about it, in a reply to this troll message.

This being said, one can suppose that nobody who is intellectually honest would call this anything other than a defaming piece of crap, authored by a worthless troll.

Still, on this forum, a piece of crap like this has mysteriously managed to reach the +4 level, by doing nothing else than gratuitously defaming FreeBSD.

To the people that modded this up: nice job indeed... Maybe, according to your agenda, it really *is* a nice job. :-/

--
Being able to read *other people's* source code is a nice thing, not a 'fundamental freedom'.

At the risk of burning my karma, I don't think this is acceptable.

The parent (modded at +4 right now!) made its first appearance on the FreeBSD mailing lists, with the false signature "Maxim Hermion", in order to imitate the name (and the email address) of the FreeBSD committer Maxime Henrion.
Here's what Maxime Henrion (the real FreeBSD committer) writes about it, in a reply to this troll message.

This being said, one can suppose that nobody who is intellectually honest would call this anything other than a defaming piece of crap, authored by a worthless troll.

Still, on this forum, a piece of crap like this has mysteriously managed to reach the +4 level, by doing nothing else than gratuitously defaming FreeBSD.

To the people that modded this up: nice job indeed... Maybe, according to your agenda, it really *is* a nice job. :-/

--
Being able to read *other people's* source code is a nice thing, not a 'fundamental freedom'.

I just want to inform whoever modded this crap up (at +3!) that this is an old troll. It first appeared on the FreeBSD mailing lists in january 2004 with the false signature "Maxim Hermion", in order to imitate the name (and the email address) of the FreeBSD committer Maxime Henrion.

This is what the real Maxime Henrion says about it, in a reply to that troll message.

Please check the sources before modding things up...

I just want to inform whoever modded this crap up (at +3!) that this is an old troll. It first appeared on the FreeBSD mailing lists in january 2004 with the false signature "Maxim Hermion", in order to imitate the name (and the email address) of the FreeBSD committer Maxime Henrion.

This is what the real Maxime Henrion says about it, in a reply to that troll message.

Please check the sources before modding things up...

Ouch.

If you don't own a SCO licence your users may be running a local root exploit ilegally. Upgrade your OS! www.freebsd.org

It's not like BSD is immune from kernel exploits.

I use both linux and BSD. They both have problems from time to time....kernel-level problems. Admittedly, user-space programs are easier to fix, but there's problems everywhere. I also kind of laugh when I go to netcraft and see a FreeBSD box with a gazillion-day uptime. It would probably be pretty damn easy to root one of those boxes.

It's not like BSD is immune from kernel exploits.

I use both linux and BSD. They both have problems from time to time....kernel-level problems. Admittedly, user-space programs are easier to fix, but there's problems everywhere. I also kind of laugh when I go to netcraft and see a FreeBSD box with a gazillion-day uptime. It would probably be pretty damn easy to root one of those boxes.

It's not like BSD is immune from kernel exploits.

I use both linux and BSD. They both have problems from time to time....kernel-level problems. Admittedly, user-space programs are easier to fix, but there's problems everywhere. I also kind of laugh when I go to netcraft and see a FreeBSD box with a gazillion-day uptime. It would probably be pretty damn easy to root one of those boxes.

You can get your kernel update now!!! :)

www.freebsd.org

it also includes a whole OS!!!

... www.freebsd.org
apply it ASAP!!!

Options are still there, see /usr/src/sys/conf/NOTES:

# SMP OPTIONS:
#
# SMP enables building of a Symmetric MultiProcessor Kernel.

# Mandatory:
options SMP # Symmetric MultiProcessor Kernel

# SMP OPTIONS:
#
# The apic device enables the use of the I/O APIC for interrupt delivery.
# The apic device can be used in both UP and SMP kernels, but is required
# for SMP kernels. Thus, the apic device is not strictly an SMP option,
# but it is a prerequisite for SMP.
#
-------------snip--------------
# Mandatory:
device apic # I/O apic

(3 Nov 2004) For FreeBSD/i386 and FreeBSD/amd64, SMP support in the GENERIC kernel has been disabled by default because the SMP kernel can degrade the performance on UP machines. A kernel configuration file SMP, which can be used to enable SMP support, has been added. More details on building the custom kernel can be found at http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/h andbook/kernelconfig.html.

Hi Robert Ryan!

Since the performance optimization on FreeBSD for the last few years, with features like SMPng, libpthread, and UMA, has been focussed on macro performance not micro performance, it's not surprising the micro performance requires tuning. However, there is lots of on-going work on this front so I'd expect to see continued improvement in the immediate (5.4) life time. There are a number of optimizations in 6.x that are on the merge path for 5.x that will directly impact the results in these measurements -- in particular, what is clearly a bug in the way mutexes are released on UP kernels that adds almost a hundred cycles to every mutex release operation. This was identified in my micro-benchmarking shortly after the release of 5.3, and may play a substantial part in the posted results, especially for the very micro benchmarks that involve kernel memory allocation.

It is also unfortunate, that the otherwise excellent benchmark, when mentioning the barrage of criticism leveled at freebsd (of which 90% is posted by random and anonymous trolls on both ./ and osnews I might add) he refers to the "article" of this guy. This was my reply - and his adequate asnwers seems to be putting me on his foe list (lol.)

Anyway, I don't want' to downplay the importance of this benchmark (nor does rwatson, if you read the whole of his post) - in fact, I'd like to see more of these coming. And overall, it was a good reading :)

On the other hand: nice (micro)benchmarks! Thanks :) It appears that FreeBSD developers know of these issues:

Since the performance optimization on FreeBSD for the last few years, with features like SMPng, libpthread, and UMA, has been focussed on macro performance not micro performance, it's not surprising the micro performance requires tuning. However, there is lots of on-going work on this front so I'd expect to see continued improvement in the immediate (5.4) life time. There are a number of optimizations in 6.x that are on the merge path for 5.x that will directly impact the results in these measurements -- in particular, what is clearly a bug in the way mutexes are released on UP kernels that adds almost a hundred cycles to every mutex release operation. This was identified in my micro-benchmarking shortly after the release of 5.3, and may play a substantial part in the posted results, especially for the very micro benchmarks that involve kernel memory allocation.

But not for FreeBSD/sparc64 anymore. It has 64-bit time_t's now.

Well, this is a difficult question. You see, almost all ports have built knobs, but not all of them save config in /var/db/ports/. Why? Because some of them, (like mplayer - and that answers your other question) autodetects whether a library is present or not. If you want explicitly to tell mplayer to bring in a new dependency, for instance, LiveMedia, you'll have to tell by passing WITH_LIVE=true to make. Since we are talking about new dependency, we don't have to worry about not saving this config, for after mplayer installs it because our WITH_LIVE=true flag, next time it will autedect it on our system, so support will be built in automatically.

Now it is possible to define a use flag for multiple ports. The first port most users install is portinstall/portupgrade. (It's not part of the base system b/c of its ruby dependency). You can install all your ports with portinstall. Let's say you want to install 30 ports on your weekend, and don't want any of them to use arts. What you do is: portinstall xmms mplayer totem audacity bla blah -x WITHOUT_XINE=true. The WITHOUT_XINE flag will be passed to all ports (it just won't be honored by those that don't know about xine).

But essentially, you will never have to do such configuration. QT will never be built unless you want it to, simply because if it's there,those apps that can support it optionally will support it automatically. If it's not there, its support won't be built. If you want support for it, than you define it (once). arts is a good example. (1) You don't want mplayer to build arts, because you'll never have arts on your puter. You don't have to do anything to achieve that. (2) You know you'll build kde later, and arts is part of kde, but you want to build mplayer now, and with arts support: you portinstall mplayer -x WITH_ARTS=true. This is a lot more easier than it sounds. Basically you don't have to configure anything to have a lean and mean system. There are only a few apps you want special tweaks for, but ports tell you about them. For instance, when you install mplayer, you are notified that there are a lot of options in the Makefile, and if you want to you can disrupt build now and check them. Snippet from makefile:

CONFIGURE_ARGS+= --disable-win32 \
--disable-qtx-codecs
.endif
.endif # ARCH == i386

pre-everything::
@${ECHO_MSG} "N - O - T - E"
@${ECHO_MSG} ""
@${ECHO_MSG} "Take a careful look into the Makefile in order"
@${ECHO_MSG} "to learn how to tune mplayer towards you personal preferences!"
@${ECHO_MSG} "For example,"
@${ECHO_MSG} "make WITH_GTK1"
@${ECHO_MSG} "builds MPlayer with GTK1-GUI support."

Now as you see (pre-everything), this will displayed before sources are downloaded and ./configure begins. And if you check the makefile, you'll see that additional options are there right at the top and are very well commented. Why I think this is better is that (and that ansers your other question) for instance, for OpenOffice, there were only a few flags, one of which was WITH_TTF_BYTECODE_ENABLE=true - which you have to define manually because of apple patents. The reason for no options screen is that ncurses is really a simple interface. You can't have more there than a few checkboxes and a short description, not a detailed explanation of patent issues. But you know of this option just as you do in case of mplayer, because a message is displayed "pre-everything". Out of my 361 installed ports, there are only these two I had to hand-tweak. Now in gentoo land, you would have to have yet another use-flag you can put in your config file

He displayed a genuine interest in linux, and I encouraged him to try gentoo (myself already using a ports based "distro"). And later seeing his frustrations, I realized my mistake. I think one of the most important things if you want to get someone on the linux/unix train is documentation. Which is almost there in gentoo, but not quite. The other is: a clear system layout. Debian comes close to it (I might try sarge when it comes out, just to keep my linux skills honed - not long ago I couldn't make usb flash drive work in SuSE, and I felt really embarrassed), but I still didn't know what mplayer.conf does in /etc (or .operarc for that matter).

So my recent method of getting people trying out linux (or freebsd) is to give them a book. I would say: don't touch anything on your computer. Read this or that, and if you are still interested, and enjoyed your reading (because you'll have to do a lot of reading later as well), than you can go on following installation instruction. One important note: never give docs in electronic format. It is easier to grasp the basic concepts if in book form, and (strange as it may sound) without sitting in the front of a puter. And then I would recommend a kind of distro you mentioned: it might be gentoo or debian or slackware, it doesn't really matter (as long as it's not rh or mandrake)

Anyway, for nostalgia's sake, I dug up some of my friend's posts on gentooforums. Note the growing use-flag paranoia (and I refer back to the above post in a post below, just for recursivity's sake. :)

The difference has to do with the types of changes that can be committed. Basically, it is harder to get a change approved after the RC stage.

Check out the FreeBSD Release Engineering page for more info.

> FreeBSD will possibly not give your boss what he wants
> or give you the breadth of readily installable packages.

I call FUD. You've never run FreeBSD have you?

If you had, you'd know that there are over 11000 ports, 97%+ of which will work with RELEASE (equivalent of Debian Stable). What's more important is that this is up to date software with the latest security fixes. That applies for IA32, Sparc & AMD64. You can check out what currently builds and how up to date it is here.

When Debian Stable can match that, give me a call. ATM, it's just not worth using, not as a server and certainly not for a desktop because: the administrative overhead is too much.

I'm afraid the Debian project has lost it's way, and I for one prefer to use a dead OS than a totally irrelevant one.

AC as I've already modded.

Could you provide some evidence? I believe Oppermann knows what he's talking about.

I dunno, maybe you're just trolling (and a number of replies that follow would qualify you as a good troll), but I'd say that installing FreeBSD is not any more difficult than, say, Slackware or Debian. It is more challenging than your Mandrake or RH install, I think (have not had a chance in the last 3-4 years to try either).

That said, with enough preparation and a chapter from the Handbook printed out and within a reach installing stock FreeBSD should not be a problem at all.

The question you should, however, ask yourself is Why do I want to try FreeBSD? If it is just because you've heard it's cool -- you may be much better off trying a http://www.freesbie.org/ instead. It's a live FreeBSD ssytem, sort of like Knoppix.

If you want to give FreeBSD a spin because you want to understand UNIX-land better or have needs for the stability of the platform, then rough starts should not be anything to discourage you.

In either case -- all the best and have fun!

Merely my brief experience with Gentoo, when they first upgraded glibc (from 2.2 to 2.3 iirc) and broke half the packages, then downgraded it again and broke everything else. This is really a pet peeve: aren't minor versions supposed to be compatible? And a zillion similar but smaller-scale annoyances, well expressed by Bill Paul many years ago [freebsd.org] and the years haven't eased the pain all that much.

And BSDs are more likely to introduce binary incompatibilities

Clearly you haven't used the BSDs. You may have library incompatibilities between major versions, but just install the earlier "compat libraries" and you're set. I upgraded from FreeBSD 4 to FreeBSD 5 -- a huge upgrade, over 2 years in the making -- and all my software just worked, even complex stuff like KDE and Mozilla that had been compiled under 4.x. vn

Merely my brief experience with Gentoo, when they first upgraded glibc (from 2.2 to 2.3 iirc) and broke half the packages, then downgraded it again and broke everything else. This is really a pet peeve: aren't minor versions supposed to be compatible? And a zillion similar but smaller-scale annoyances, well expressed by Bill Paul many years ago [freebsd.org] and the years haven't eased the pain all that much.

And BSDs are more likely to introduce binary incompatibilities

Clearly you haven't used the BSDs. You may have library incompatibilities between major versions, but just install the earlier "compat libraries" and you're set. I upgraded from FreeBSD 4 to FreeBSD 5 -- a huge upgrade, over 2 years in the making -- and all my software just worked, even complex stuff like KDE and Mozilla that had been compiled under 4.x. eg

My insider information tells me FreeBSD and PostgreSQL.

Merely my brief experience with Gentoo, when they first upgraded glibc (from 2.2 to 2.3 iirc) and broke half the packages, then downgraded it again and broke everything else. This is really a pet peeve: aren't minor versions supposed to be compatible? And a zillion similar but smaller-scale annoyances, well expressed by Bill Paul many years ago [freebsd.org] and the years haven't eased the pain all that much.

And BSDs are more likely to introduce binary incompatibilities

Clearly you haven't used the BSDs. You may have library incompatibilities between major versions, but just install the earlier "compat libraries" and you're set. I upgraded from FreeBSD 4 to FreeBSD 5 -- a huge upgrade, over 2 years in the making -- and all my software just worked, even complex stuff like KDE and Mozilla that had been compiled under 4.x. vr

Merely my brief experience with Gentoo, when they first upgraded glibc (from 2.2 to 2.3 iirc) and broke half the packages, then downgraded it again and broke everything else. This is really a pet peeve: aren't minor versions supposed to be compatible? And a zillion similar but smaller-scale annoyances, well expressed by Bill Paul many years ago [freebsd.org] and the years haven't eased the pain all that much.

And BSDs are more likely to introduce binary incompatibilities

Clearly you haven't used the BSDs. You may have library incompatibilities between major versions, but just install the earlier "compat libraries" and you're set. I upgraded from FreeBSD 4 to FreeBSD 5 -- a huge upgrade, over 2 years in the making -- and all my software just worked, even complex stuff like KDE and Mozilla that had been compiled under 4.x. rh

The bottom line is - I salute Sun open sourcing Solaris, but they still need to work on improving the attitude towards other open source OS's, particularly Linux and FreeBSD. The strategy of insisting that Solaris is just better, isn't going to get Sun very far, simply because it isn't true in many respects.

FreeBSD is a complete Unix-like operating system entirely developed by a single large team of programmers. This is in stark contrast to GNU/Linux which, as a complete operating system, has no central, cohesive developer base and is packaged in myriad different ways by myriad different distribution projects and companies; and proprietary Unixes, which are closed-source, restrictively licensed, and work on a comparatively small number of usually proprietary hardware architectures. FreeBSD has historically been clean, fast, reliable, and scalable. It's easy to use, learn, set up, and navigate from the command line, has more than 10,000 software programs in the Ports system, runs on a wide variety of hardware, and can easily be used for either a desktop or a server.

The transition to 5.x

Until the release of 5.3, the most recent "production release" was the FreeBSD-4 series, which is presently at version 4.10 and has been deemed the "Legacy" release in the wake of the 5.x branch going to STABLE. FreeBSD-5 was supposed to be a grand introduction of new technology -- a revolutionary improvement to the tried and true 4.x branch -- but soon after it left the gate, it got caught up in developer politics and failed implementations of too-ambitious theories among other questionable design decisions, causing some developers to fork the FreeBSD-4 project into a separate and more focused operating system.

The ULE (which is not an acronym; its full name is SCHED_ULE as opposed to the older SCHED_4BSD) scheduler continues to have stability and performance problems and was totally disabled instead of being made the default process scheduler in 5.3 as planned. The mix of threading subsystems still yields problems with efficiency and stability. Also, the networking subsystem may now be multithreaded and therefore faster on SMP systems, but users with some implementations of the 3Com (SysKonnect/Yukon) gigabit LAN chip are now unable to access their network at all because of new bugs that have popped up in the driver; other SysKonnect/Yukon users have problems under heavy network traffic, along with those using Intel Pro/1000 chips. Unfortunately all of our test systems use these network chips for onboard LAN; coincidentally they are two of the most popular gigabit LAN chipsets used on modern motherboards from major manufacturers. We also experienced lockups during boot if a custom-compiled kernel did not have SMP enabled on a Hyper-Threaded computer. A list of these and other errata can be found here.

Considering the long list of significant problems in FreeBSD 5.3-RELEASE, it would seem irrational to recommend that anyone switch a production server from 4.x or any previous known-working 5.x release to 5.3. Just the same, the FreeBSD project maintains a migration guide for this purpose.

A lost lead

FreeBSD 5.x enjoyed an excellent head start in the fully 64-bit AMD64 operating system arena, but now trails

FreeBSD is a complete Unix-like operating system entirely developed by a single large team of programmers. This is in stark contrast to GNU/Linux which, as a complete operating system, has no central, cohesive developer base and is packaged in myriad different ways by myriad different distribution projects and companies; and proprietary Unixes, which are closed-source, restrictively licensed, and work on a comparatively small number of usually proprietary hardware architectures. FreeBSD has historically been clean, fast, reliable, and scalable. It's easy to use, learn, set up, and navigate from the command line, has more than 10,000 software programs in the Ports system, runs on a wide variety of hardware, and can easily be used for either a desktop or a server.

The transition to 5.x

Until the release of 5.3, the most recent "production release" was the FreeBSD-4 series, which is presently at version 4.10 and has been deemed the "Legacy" release in the wake of the 5.x branch going to STABLE. FreeBSD-5 was supposed to be a grand introduction of new technology -- a revolutionary improvement to the tried and true 4.x branch -- but soon after it left the gate, it got caught up in developer politics and failed implementations of too-ambitious theories among other questionable design decisions, causing some developers to fork the FreeBSD-4 project into a separate and more focused operating system.

The ULE (which is not an acronym; its full name is SCHED_ULE as opposed to the older SCHED_4BSD) scheduler continues to have stability and performance problems and was totally disabled instead of being made the default process scheduler in 5.3 as planned. The mix of threading subsystems still yields problems with efficiency and stability. Also, the networking subsystem may now be multithreaded and therefore faster on SMP systems, but users with some implementations of the 3Com (SysKonnect/Yukon) gigabit LAN chip are now unable to access their network at all because of new bugs that have popped up in the driver; other SysKonnect/Yukon users have problems under heavy network traffic, along with those using Intel Pro/1000 chips. Unfortunately all of our test systems use these network chips for onboard LAN; coincidentally they are two of the most popular gigabit LAN chipsets used on modern motherboards from major manufacturers. We also experienced lockups during boot if a custom-compiled kernel did not have SMP enabled on a Hyper-Threaded computer. A list of these and other errata can be found here.

Considering the long list of significant problems in FreeBSD 5.3-RELEASE, it would seem irrational to recommend that anyone switch a production server from 4.x or any previous known-working 5.x release to 5.3. Just the same, the FreeBSD project maintains a migration guide for this purpose.

A lost lead

FreeBSD 5.x enjoyed an excellent head start in the fully 64-bit AMD64 operating system arena, but now trails

FreeBSD is a complete Unix-like operating system entirely developed by a single large team of programmers. This is in stark contrast to GNU/Linux which, as a complete operating system, has no central, cohesive developer base and is packaged in myriad different ways by myriad different distribution projects and companies; and proprietary Unixes, which are closed-source, restrictively licensed, and work on a comparatively small number of usually proprietary hardware architectures. FreeBSD has historically been clean, fast, reliable, and scalable. It's easy to use, learn, set up, and navigate from the command line, has more than 10,000 software programs in the Ports system, runs on a wide variety of hardware, and can easily be used for either a desktop or a server.

The transition to 5.x

Until the release of 5.3, the most recent "production release" was the FreeBSD-4 series, which is presently at version 4.10 and has been deemed the "Legacy" release in the wake of the 5.x branch going to STABLE. FreeBSD-5 was supposed to be a grand introduction of new technology -- a revolutionary improvement to the tried and true 4.x branch -- but soon after it left the gate, it got caught up in developer politics and failed implementations of too-ambitious theories among other questionable design decisions, causing some developers to fork the FreeBSD-4 project into a separate and more focused operating system.

The ULE (which is not an acronym; its full name is SCHED_ULE as opposed to the older SCHED_4BSD) scheduler continues to have stability and performance problems and was totally disabled instead of being made the default process scheduler in 5.3 as planned. The mix of threading subsystems still yields problems with efficiency and stability. Also, the networking subsystem may now be multithreaded and therefore faster on SMP systems, but users with some implementations of the 3Com (SysKonnect/Yukon) gigabit LAN chip are now unable to access their network at all because of new bugs that have popped up in the driver; other SysKonnect/Yukon users have problems under heavy network traffic, along with those using Intel Pro/1000 chips. Unfortunately all of our test systems use these network chips for onboard LAN; coincidentally they are two of the most popular gigabit LAN chipsets used on modern motherboards from major manufacturers. We also experienced lockups during boot if a custom-compiled kernel did not have SMP enabled on a Hyper-Threaded computer. A list of these and other errata can be found here.

Considering the long list of significant problems in FreeBSD 5.3-RELEASE, it would seem irrational to recommend that anyone switch a production server from 4.x or any previous known-working 5.x release to 5.3. Just the same, the FreeBSD project maintains a migration guide for this purpose.

A lost lead

FreeBSD 5.x enjoyed an excellent head start in the fully 64-bit AMD64 operating system arena, but now trails

FreeBSD is a complete Unix-like operating system entirely developed by a single large team of programmers. This is in stark contrast to GNU/Linux which, as a complete operating system, has no central, cohesive developer base and is packaged in myriad different ways by myriad different distribution projects and companies; and proprietary Unixes, which are closed-source, restrictively licensed, and work on a comparatively small number of usually proprietary hardware architectures. FreeBSD has historically been clean, fast, reliable, and scalable. It's easy to use, learn, set up, and navigate from the command line, has more than 10,000 software programs in the Ports system, runs on a wide variety of hardware, and can easily be used for either a desktop or a server.

The transition to 5.x

Until the release of 5.3, the most recent "production release" was the FreeBSD-4 series, which is presently at version 4.10 and has been deemed the "Legacy" release in the wake of the 5.x branch going to STABLE. FreeBSD-5 was supposed to be a grand introduction of new technology -- a revolutionary improvement to the tried and true 4.x branch -- but soon after it left the gate, it got caught up in developer politics and failed implementations of too-ambitious theories among other questionable design decisions, causing some developers to fork the FreeBSD-4 project into a separate and more focused operating system.

The ULE (which is not an acronym; its full name is SCHED_ULE as opposed to the older SCHED_4BSD) scheduler continues to have stability and performance problems and was totally disabled instead of being made the default process scheduler in 5.3 as planned. The mix of threading subsystems still yields problems with efficiency and stability. Also, the networking subsystem may now be multithreaded and therefore faster on SMP systems, but users with some implementations of the 3Com (SysKonnect/Yukon) gigabit LAN chip are now unable to access their network at all because of new bugs that have popped up in the driver; other SysKonnect/Yukon users have problems under heavy network traffic, along with those using Intel Pro/1000 chips. Unfortunately all of our test systems use these network chips for onboard LAN; coincidentally they are two of the most popular gigabit LAN chipsets used on modern motherboards from major manufacturers. We also experienced lockups during boot if a custom-compiled kernel did not have SMP enabled on a Hyper-Threaded computer. A list of these and other errata can be found here.

Considering the long list of significant problems in FreeBSD 5.3-RELEASE, it would seem irrational to recommend that anyone switch a production server from 4.x or any previous known-working 5.x release to 5.3. Just the same, the FreeBSD project maintains a migration guide for this purpose.

A lost lead

FreeBSD 5.x enjoyed an excellent head start in the fully 64-bit AMD64 operating system arena, but now trails

Last I checked, Apple indeed employs Jordan Hubbard, who was a major figure in the FreeBSD community (project lead, IIRC).

That said, Darwin, the OS underlying OS X is need basically FreeBSD with a Mach kernel (some of the man pages still say FreeBSD on them), and I've read comment from JKH that much code makes it's way back to FreeBSD.

How that helps Linux, is of course, circular, in that code may eventually make it's way back to Linux.

In other words, you can have an 5.3-STABLE (warning, that is still a development branch, but as the name suggests, it's pretty stable) system or 5.3-RELEASE, or even 6-CURRENT if you want - depending how you set your standard-supfile.In short, you'll have a fully functional FreeBSD system, you can even decide which version you want.

Cvsup, ports/src tree ... these might sound alien if you never used FreeBSD, but the concepts are really easy to pick up (me came to FreeBSD from a mandrake background, and their documentation is so excellent, that I picked up the basics in a few days). In fact, I believe that FreeBSD is the easiest unix system a non-techie person can learn! Also, the community is very newbie friendly and helpful (on bsdforums.org). You can read the Handbook on their homepage.

I second this. Taking experiences I've had...

To install and use FreeBSD without knowing anything was not a big problem. If I didn't know how to do something, I had the handbook (like the the other poster said, excellent) and many other well-written documents. Here is one example of the sort of document which is common:

http://www.schlacter.net/public/FreeBSD-STABLE_and _IPFILTER.html

When I installed Gentoo and tried to use it, it was not nearly as obvious what to do when I wanted. Again, compare these two:

http://www.gentoo.org/doc/en/index.xml
http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/

One is an excellent, structured document.

The first link under Gentoo's "other documentation" is "check out our source code using CVS!" - why the hell would anyone want to look at source code if real documentation existed?

Anyway, yes, there are other linux distributions than Gentoo. That actually intensifies the problem, since (for example) setting up NFS is a different procedure on Fedora Core, Gentoo, etc. etc., with different defaults, .....

The "chaos" development model isn't totally bad. It allows Linux to evolve extremely quickly. But at the end of the day, I want a computer which is easy to use. Figuring out how to use it is part of that.

And don't even get me started on binary compatibility. Under BSD you can run binaries compiled years ago, unmodified, using compatibility libraries. Why no linux distributions do this is beyond me, but it's another example of programmers saying "It's not that hard to work around, so it's not broken. We only change core libraries every couple years anyway, you shouldn't use two-year old software that you can't recompile"

End rant.

IMPORTANT UPDATE: Please show your support for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. Don't you wish the guy in this pic was you? Are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

IMPORTANT UPDATE: Please show your support for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. Don't you wish the guy in this pic was you? Are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

I too have an Indy (two of them picked up on the cheap from eBay) and I have a similar problem. Although I don't even have a set of disks to speak of, but it's what I really want as I wanted to try IRIX.

I need the disks because the boxes where supplied as-is, I was not supplied with either the bios or administrator password. The bios password is easy enough, if you open up the Indy there's a jumper available on the motherboard that will disable the bios password when removed. Once the jumper is removed I'm then stuck with needing (I think) Disk 2 of the installation disks which has a utility to reset the root password, as I have no disks I can't do this. From what I've read previously the IRIX license is per machine and not per user/set of disks so I think I should be perfectlly legal running both boxes with IRIX, just I need the disks, I too would be happy to pay for them with a no strings attached policy from SGI.

I've been considering putting either Debian MIPS or FreeBSD MIPS, but am reluctant to do so because I really wanted the Indys for the IRIX. As far as the status of those projects, I beleive Debian MIPS is good to go once I've setup a DHCP net booting system to bootstrap the install on the Indy and FreeBSD is still in development. Come to think of it, I bet my favourite flavor, NetBSD, has got a MIPS port (go 2.0!).

Really, I thought windows was the number one killer of these.

IMPORTANT UPDATE: Please show your support for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. Don't you wish the guy in this pic was you? Are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

The idea behind Virtuozzo, VServer and the like is the introduction of yet another id in addition to the process id. VServer calls it "context id", FreeBSD calls it "jail id", don't know what Virtuozzo calls theirs, but the concept is the same. So now a process belongs to a context, and processes in one context cannot see processes in another context. Additionally, networking (specific ip) and other (CPU scheduling policy, filesystem, ...) restrictions can be applied to a context.

The concept is much better described than I can do it at this hour here and here.

There's another guy collecting suggestions too - I saw it someone's .sig - slashdotemail@gmail.com I think. I have no idea what he's going to do with them but I sent him a few and he thanked me for the list. I think I suggested 'Smartdot'.

I think the Darwin thing is coming on and making advancements. I had a skim of an O'Reilly book 'OSX for Unix Geeks' and it had a chapter on getting X up and running... using Fink(?) which I think maybe be similar to Gentoo emerge (back on topic!). Looks like they might have KDE working as well.

As for the *BSDs Free, Open, Net etc. if you liked DOS then you should get on just fine. It can take a while to get to know the *nix alernatives to DOS commands and where things are kept but I found it soon becomes comfortable. And the best thing is that you're soon able to weild the power and then you don't want to go back! I don't know if this works for you - but I've found keeping a notebook can be really handy for esoteric command switches, useful sequences of piped commands, temporary changes I'm not sure about etc. Just a thought - it's saved me a lot of time.

If you do decide to give FreeBSD a whirl I recommend going through the handbook as it covers a lot of Unix basics as well. FreeBSDDiary is well worth a look too. If it wasn't for a few big commercial programs I could happily switch from XP to FreeBSD and KDE. These days it's that good.

No beer, no foul? Think yourself lucky emerge tried to hump my leg :(

Posters being able to mod' down their own comments: great idea! That's a good suggestion for that guy who's asking for ideas on how to remake Slashdot.

Gentoo emerge: yeah I like their Portage thing. I've never really used Gentoo but I've had it recommended to me several times - which is when I heard about their ports thing. If I ever get round to it, Gentoo would be something I'd like to try (along with maybe LFS and Slack).

However, FreeBSD makes me very happy - it has the excellent ports collection (similar to Gentoo's Portage) and it's typically a real pleasure to use. Once you get into it, the syntax isn't really a problem. Occasionally I pull up a man page or two (another good thing on FreeBSD) but that's it. The only thing I find is that if I haven't installed anything for a while I get out of the habit of updating things and running checks (but that's just me being lazy really.)

I honestly wouldn't prefer a GUI for ports (even though I use Windows XP on a daily basis too). FreeBSD is just so well laid out in /usr/ports that it's quicker to type. Sometimes I reference the ports page or the relevant section of the handbook. It might look a bit daunting at first but for typical usage it's just cvsup to update the ports skeleton on the local box and then portupgrade (or cd'ing to the directory in the skeleton ports tree) to install your stuff and then a bit of housekeeping. Or there's sysinstall. I'd imagine emerge would be similar fare (the quality of either ports system depends on the port maintainers who keep the ports up-to-date and do any necessary customization).

But hey - if emerge this-is-cool delivered a cold one to my desk I'd have Gentoo up and running by tomorrow(!) and looping that line in a little script!

And with that, off I go; I've still got to rely on sneakernet to fetch my beer :)