Slashdot Mirror

Not true. You've got the triad all wrong:

A Geek is an engineer, or, barring that, one who obsessed with obtaining skill in something that really has no real world relevance, but sucks up time from interesting problems as a means of illusionary social superiority. These skills are mainly trivial, done by countless others, and are done in a way that collaboration is almost completely shunned. Examples are D&D, pseudo-religious flame wars (kind of like this), system administration, obtaining an MCSE, gaming, running debian, etc. This goes back to the Geeks of olde, circus geeks, who did horrifying and sometimes amazing acts that really had no utility outside of grossing people out and taking their money. As society has progressed the Geek personality has had to adapt, and now simply is the loner in his mom's basement who chats on IRC about how many bots he has running on his sid server while playing countless command-line MUDs, groaning about trolls and dice logistics. Help me out here dictionary:

geek geek (g=ek), n.
1. A performer in a carnival, often presented as a wild man, who performs grotesquely disgusting acts, such as biting the head off a live chicken or snake. PJCM
2. Hence: Any eccentric or strange person; an oddball; an eccentric.

The Dork is a more of a fun individual. He or She enjoys making people laugh and being the butt of many-a-jokes. They're fun to be around and generally amiable. When they're on, they're funny, when they're off, they're reserved.

The Nerd, on the other hand, is your average scientist. They are reserved, hard-minded, generally nice, think-a-holics. They're open minded and realize all of the basic fundamental human truths instinctively. They find average pursuits boring and tedious, feel that they are generally socially inferior, but know it doesn't matter.

Everyone has some combination of nerd/dork/geek in them. The main theme here, though, is social identity. Geeks think their "skills" make them socially superior to others. Dorks feel they are on the same level as everyone else. Nerds feel they are inferior, but realize it's all a crock of shit anyway. Your classic geek would be a Sports hero or a D&D player. Your classic Dork would be a comedian. Your classic Nerd would be a scientist. None of them are inherhently evil.

During the 90's you computer people decided to take back the term Geek and adopt it in a way that it had never been used before. Now "hackers" are considered Geeks. Well, they're not, though their followers certainly are. Hackers are nerds. They love thinking about interesting problems, solving them, and sharing them. The entire hacker and open source culture is built on top of Nerdom. However, most of slashdot is awash in geeks. Followers who feel the need to tout their skills, chime in with some so-called insightful statement that is really just a rehash of things said over and over again in the community:

"Competition is a Good Thing (tm)"
"Free as in Freedom not free as in Beer"
"Monopolies are Bad."
Etc, etc etc...

Infact, slashdot is built on the Geek model. That is, it's based on social advancement through subjective ratings, rather than pure openness and exchange of thoughts - be they flames or otherwise. It's trolls tend to be more insightful and commentative than it's serious posters, especially those post 600000 UID's. In other words - slashdot is designed, be it intentional or not, to bring out the worst element of the open source world - the Geek. The engineer that works in back rooms on a widget that his boss will then claim for his own. Owned by a company, building and toiling, giving shit back to society other than another magical product to pump to the masses, sold for more than it's really worth. But they're an engineer. That title makes them better than the rest of us! Or, they're a sys-admin or a dungeon master. All labels, titles that are created to make the individual feel superior in some meaningless way.

I think they just scarfed all the FreeBSD 3.x man pages as a starting point.

http://www.FreeBSD.org/cgi/man.cgi?query=bad144&ap ropos=0&sektion=0&manpath=FreeBSD+3.5.1-RELEASE&fo rmat=html

Couple things:

1) Active/inactive window effects are not the Finder's job but Aqua's.

2) The performance issue you've mentioned is actually due to polling. One can only hope that Apple is adopting the kqueue mechanism from FreeBSD or something like it in 10.4 to eliminate those delays.

I fully agree that the Finder is a disappointment in both capability and usability, though.

Mac OS X has a BSD core, but it isn't generally used like a BSD.

Some operating systems are more stable than others.

Seriously, a BSD machine being up for years is really not unusual. Having said that, windows has gotten a lot better over the years. I probably only have a crash or lockup about once a month as opposed to several times a day.

Who the devil are you?..

luckily I have the power of jail(8) with md(4) and some other "tricks"..

Who the devil are you?..

luckily I have the power of jail(8) with md(4) and some other "tricks"..

Or FreeBSD -- the killer OS?.. Good for Apple.

"Scott's driver" is actually my driver, albeit with considerable input from Scott after I moved on.

http://people.freebsd.org/~msmith/RAID#adaptec

Likewise, the OpenBSD aac(4) driver is based on the FreeBSD aac(4) driver (check the copyrights if you care).

= Mike

Just a note; the "former Adaptec employee" is Scott Long of the FreeBSD project.

I have not been using OpenBSD sice 1999, but hardware support was never its strong point... though what it supported was,like all the BSD's, supported extremely well.

It's a good call, in spirit of BSD. Scott's drivers are exellent and they just need to port those.

The question is what happens when you want to mix in some FreeBSD, or perhaps you have a PowerPC Linux box.

Using hard coded spaces consumes more bytes and requires reformatting to change the indent. Use of Tabs is a no-brainer, but judging from the comments here and elsewhere people still don't understand the issue.

I always use TABS because I figure an editor can be configured to translated X TABS into Y spaces as prefered by the user. In other words, I agree.

However, every style guide I have seen tries to impress upon you the importance of using spaces and never TABS (including the open-source ones?). Why is this? Why is this encouraged as the best practice?

And this is even worse: the FreeBSD style guide prescribes a MIXTURE of tabs and spaces! The tabs are also twice as long as the spaces visually (8 vs. 4 characters). The NetBSD style guide has similar requirements.

FreeBSD ;-)

If I have decided that I'll give away some code I've written, I going to give it away, period, none of this "unless it is worth a million to somebody" rubbish.

FreeBSD maintains the same kind of stability WITH a more current release schedule. 5-stable (unlike 5-release) will give you a very stable system. 5-release will give you a pretty rock solid system, though unbreakability is not guaranteed. Use 6-current and you better expect breakage, though it's not guaranteed. The last -stable FreeBSD milestone? Nov. 6 2004.

Before there's a shitload of replies about 5 sucking - yes it did suck when it was strictly a new technology release. Now bugs have been patched and more things have come out from under the giant lock. Speed has increased, as has stability, and it has earned the -stable tag. The point of this post is just to say stable != extremely out of date. stability is just well-tested, well-written code.

If you're willing to switch to a different OS altogether, try FreeBSD. FreeBSD has a Package and Ports system. Packages are pre-compiled binaries that can be fetched and installed, and Ports is a way of installing software through source.

To install Firefox, for example, you can type pkg_add -r firefox, and it would fetch a Firefox binary from the FreeBSD servers and install it from your system. If you prefer to compile Firefox, just cd to /usr/ports/www/firefox and type make install clean. It would automatically fetch the latest Firefox sources and compile them. Ports also resolves dependencies too; if GTK 2.4 or later isn't installed on the system (which Firefox requires), it will also fetch and compile the latest GTK if it isn't installed on the system.

It is also pretty easy to upgrade all of your packages and ports, too.

There are three ways that you can get FreeBSD. Every 5-6 months there is a FreeBSD release (FreeBSD-RELEASE). For example, FreeBSD 5.3 came out last November, and a FreeBSD 5.4 release is slated for April. However, if you want a more upgraded version and track development, there are two directions you can go: FreeBSD-CURRENT and FreeBSD-STABLE. CURRENT is the development branch that adds and tests new features, while STABLE includes the finished features, ready for one of the RELEASES.

You can find out more about FreeBSD here. It has many of the features that you like in Debian, except updated much more often. Only thing to tell you is that FreeBSD isn't Linux; there are some key differences between the two operating systems that you should be aware of.

Yeah, Windows is all alone too.

Now maybe companies will realize that using GPL code is stupid, and start using free software instead.

They are devels working on it & they have their own opinions.

Never!

You choose to put a foot in your mouth and you just have to learn to like it!

They are devels working on it & they have their own opinions.

Never!

You choose to put a foot in your mouth and you just have to learn to like it!

It's no real surprize that people want to get rid of it. If not for Linux we'd have a choice of two OS (Windows or OSX)

Really? What happened to all the other free alternatives?

I'm getting a bit tired of Linux fanatics who think the OS world is limited to Windows, OS X and Linux.

--
Glass, t0tal pwnag3

>Where do you get the idea that a fact isn't FUD?

From the dictionary.
"the term FUD [...] has become generalized to refer to any kind of disinformation used as a competitive weapon."
Don't worry, it's never too late to get some actual education.

>Factual FUD is the best kind, because it can't be simply proven wrong.

"Factual FUD" is actually a very creative expression, if it weren't complete bullsh*t of course.
Everybody with a brain knows very well there's a very sharp line separating facts from FUD - and, just as a bonus, one can also consider the number of people that used the expression "factual FUD" before (0, of course).

>>It's true that FreeBSD can route 1Mpps on a 2.8GHz Xeon
>>while Linux, *on the same hardware*, can't do much more than 100kpps
>>(200kpps? 300kpps? Still quite far from 1Mpps).
>No. This is *wrong*.
>The FreeBSD guys never tried Linux on that hardware.

Nope. That was *right*. And yes, they did.

>>It's true that, even if Linux is the current record holder,
>>last year NetBSD broke the Internet2 Land Speed World Record twice.
>Yes, and it is true that by selectively choosing facts,
>you can paint your position in a better light than it is.

Every time - *every time* - anybody says anything that's true, he selectively chooses facts somehow.
Nonetheless, facts are facts.

It takes much more than a dishonest slashdot moderator to turn a pathetic troll's crap into truth.

A little Googleing gives us a) the Freescale (nee Motorola) AltiVec Libraries (Login required), which includes (among others) strlen and b) this code fragment and c) a more general description.

A framework/runtime that doesn't run on Linux? OMG, that might affect as much as 2% of the market!!!

Perhaps you should switch to a supported Operating System. After all, once an implementation exists for FreeBSD, it's only the asm parts that have to be rewritten to get it to run on the next biggest platform.

Kobolds?! Eeek!
Mine got taken over by hordes of daemons
(the kind with sneakers, pitchforks and stuff...)

Hmm... typical Sun employee.

Sun would get my respect with they were using an standard license.

Until then... no thanks, I rather use the real free alternatives than to help Sun minimize development costs using the FOSS community.

According to the mount_unionfs manpage in FreeBSD and OpenBSD this same functionality was introduced by March 27, 1994...

http://www.freebsd.org/cgi/man.cgi?query=mount_uni onfs&sektion=8&apropos=0&manpath=FreeBSD+5.3-RELEA SE+and+Ports/

I Slighly disagree, Big companies usually turn evil.. Wal-mart in it's quest for 'always low prices' has but a number of discount retailers into the lurch the smaller chains are dying (pamida's etc) They also are known for low salaries but, they get the low prices, so it's evil in a way that benifits some at the cost of others ^^;
And consider gogole's biggest competitor, yahoo! they've been proping up the FreeBSD project for eons, BSD would be dead if it's core developeres weren't all on yahoo!s payroll making Yahoo BSD...
Yahoo still hasn't turned evil, (although they do allow people to pay to be ranked higher in searches)
Right now FreeBSD has a lot of things implemented better in the kernel Because Yahoo!'s version of FreeBSD needed those improvements for it's loads and loads of rack mounted servers.. I've noticed the actually distro is much less friendly than modern day linux distros but certain aspects of the kernel are better than even the latest linux kernel. (not to mention the actual manpages with information about the background of various unix apps, with all the conventional unix functionality of it's unix-alike commands...) compare a man date* from linux vs FreeBSD for a little insight on how 'barebones' some of the unixalike apps in linux are... GNU's Not Unix indeed.

*= Yes this is a personal pet peeve of mine, I use 'date -v +1280d'** all the time to figure out what day of the week it's going to be in an odd number of days/hours/minute/seconds all the time!

**= Just an example, you never know when you need to know if someone's 'days until bush is out of the white house'(another example) counter clock is accurate or not.

No need for the petition, Beastie's gonna stay. :)

Read the Q&A --> http://logo-contest.freebsd.org/

Smorgreff

Nice. If you're going to try to look smart at DES' expense, at least get his name right. It's Smørgrav. I suppose you're going to start on PHK next? How about the completely mindless sport of picking on Søren?

These three are amongst the most productive developers on the project. Arguments are inevitable, especially on group projects like the BSDs. The real trick, which these have mastered, is not to let them get in the way of high quality code. Your comments are typical of the way this style of "advocacy" damages reputations in fairly short order, usually the reputations of those engaging in it.

<a href="ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386 /packages-stable/All/lynx-2.8.5.tgz">Lynx</a>

<URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/ packages-stable/All/lynx-2.8.5.tgz>

<a href="ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386 /packages-stable/All/lynx-2.8.5.tgz">Lynx</a>

<URL:ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/ packages-stable/All/lynx-2.8.5.tgz>

But consider FreeBSD, which uses Perforce internally, before the changes hit the CURRENT CVS branch!

FreeBSD's primary source control system is CVS.

Some (but not all) developers use Perforce to manage their experimental FreeBSD-related project -- work that is either too intrusive or too experimental to bring into the main tree directly.

Please see: http://www.freebsd.org/internal/.

In my experience, ports doesn't lag too far behind portage - it's somewhere between the portage stable branch and current. As the complexity of a package (and it's impact on other ports) grows, so does the time port maintainers spend testing them. Just to give a good idea of how much ports is up to date (or not):

If we take the GIMP for example, usually it is in ports the day it is announced. That speaks volumes of it's portability/cleanness of the code base. On the other hand, as important as it may be, it doesn't affect much other ports.

Then let's see KDE. KDE becomes part of ports (and the package repository) usually a few weeks after the announcment. If I remember correctly, one of the 3.2 releases was in ports some 3-4 days after release. On the other hand, 3.3.2 took 2 week to get there. That isn't much of a lag, now is it?

And finally: Xorg. Xorg affects many many ports, so there is usually a lot more time spent in testing then with the packages I just mentioned. We are still at 6.8.1, although 6.8.2 is coming as you can see from this mailing list post.

Generally, ports is quite up to date. There are weekly updates to OpenOffice.org 2.0 - probably because it is independent from other ports. Also, the most important package are updated pretty fast (I had PHP 5.0.3 running before the announcment of the security fix release hit slashdot). Others, however, lag behind somewhat. We don't have KDE 3.4beta in ports for example, while I guess it is already in portage.

As I said, I don't disagree with what you wrote, I just wanted to give a general impression about the freshness of ports for other readers (check out freshports to learn more.

I think the other messages in the thread on FreeBSD-current are also worth a glance, especially this one by Robert Watson, which stresses the strong cooperation and code sharing that is actually connecting the BSD projects.
--
Being able to read *other people's* source code is a nice thing, not a 'fundamental freedom'.

And the short version of the same thing, but using a recovery CD instead of a live system http://dannyman.toldme.com/2005/01/24/freebsd-howt o-gmirror-system/

Kind of a coincidence that this gets posted today on /., as I've spent most of the morning setting up geom on a new 5.3 box, had used Vinum in the past on 4.x, and have loved FreeBSD for servers since 2.2.5

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

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 right 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

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

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 right 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

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

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 right 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

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

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 right 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

Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?4205F382.8020 404>
www@FreeBSD.org

Where are all the geom HOWTOs?

The linked man page is "tasty" n'all, but details on implementing such magical wonders, until recently, have been rather scarce.

This man page is better than the one linked to in the original post. There's also some information from committer (read: major contributor to ggate ) Pawel Jakub Dawidek in Poland.

Not that the info isn't there now, right under man, but for a while it was all very vague.

When searching about all that is BSD, don't forget Google's special google.com/bsd section.

You can also search the freebsd-geom mail list archives to learn more.

geom-gate sure looks nifty! It's akin to block-level NFS (though that's most likely an extremely oversimplified view). All the fun things you can do with geom you can do over your network. Need worldwide distributed, encrypted, multi-level RAID? Go right ahead!

Pretty slick. We'll be hearing more about this.....

Where are all the geom HOWTOs?

The linked man page is "tasty" n'all, but details on implementing such magical wonders, until recently, have been rather scarce.

This man page is better than the one linked to in the original post. There's also some information from committer (read: major contributor to ggate ) Pawel Jakub Dawidek in Poland.

Not that the info isn't there now, right under man, but for a while it was all very vague.

When searching about all that is BSD, don't forget Google's special google.com/bsd section.

You can also search the freebsd-geom mail list archives to learn more.

geom-gate sure looks nifty! It's akin to block-level NFS (though that's most likely an extremely oversimplified view). All the fun things you can do with geom you can do over your network. Need worldwide distributed, encrypted, multi-level RAID? Go right ahead!

Pretty slick. We'll be hearing more about this.....

Where are all the geom HOWTOs?

The linked man page is "tasty" n'all, but details on implementing such magical wonders, until recently, have been rather scarce.

This man page is better than the one linked to in the original post. There's also some information from committer (read: major contributor to ggate ) Pawel Jakub Dawidek in Poland.

Not that the info isn't there now, right under man, but for a while it was all very vague.

When searching about all that is BSD, don't forget Google's special google.com/bsd section.

You can also search the freebsd-geom mail list archives to learn more.

geom-gate sure looks nifty! It's akin to block-level NFS (though that's most likely an extremely oversimplified view). All the fun things you can do with geom you can do over your network. Need worldwide distributed, encrypted, multi-level RAID? Go right ahead!

Pretty slick. We'll be hearing more about this.....

Where are all the geom HOWTOs?

The linked man page is "tasty" n'all, but details on implementing such magical wonders, until recently, have been rather scarce.

This man page is better than the one linked to in the original post. There's also some information from committer (read: major contributor to ggate ) Pawel Jakub Dawidek in Poland.

Not that the info isn't there now, right under man, but for a while it was all very vague.

When searching about all that is BSD, don't forget Google's special google.com/bsd section.

You can also search the freebsd-geom mail list archives to learn more.

geom-gate sure looks nifty! It's akin to block-level NFS (though that's most likely an extremely oversimplified view). All the fun things you can do with geom you can do over your network. Need worldwide distributed, encrypted, multi-level RAID? Go right ahead!

Pretty slick. We'll be hearing more about this.....

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

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 right 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.

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

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 right 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.

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

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 right 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.

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

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 right 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.

Since the introduction of the FreeBSD-5 branch, FreeBSD enthusiasts have been eagerly awaiting the day when the new codebase would stabilize. After much development and four previous releases, FreeBSD-5 has finally gone stable with version 5.3. But don't mistake a stable codebase with stable software. While the development team will no longer accept major changes to the base system, FreeBSD 5.3 still has bugs and problems.

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 right 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 l