Slashdot Mirror

And for a BSD take on this, see http://people.freebsd.org/~jasone/jemalloc/, including benchmarks of memory fragmentation, discussion on thread access locality etc.

FreeBSD has ZFS, DTrace, and Jails (similar to Zones). It may have more of the features you mentioned, but my only direct experience is using it as a desktop OS for a while and as a home server.

FreeBSD has ZFS, DTrace, and Jails (similar to Zones). It may have more of the features you mentioned, but my only direct experience is using it as a desktop OS for a while and as a home server.

FreeBSD has ZFS, DTrace, and Jails (similar to Zones). It may have more of the features you mentioned, but my only direct experience is using it as a desktop OS for a while and as a home server.

This is unusual. I just downloaded the FreeBSD ISO from Chrome on Windows 7, Athlon 2400+ (don't ask). Result: 500kB/s, avg CPU time for process: 2-3%.

I haven't noticed this on my 64bit Windows 7 PC either, and my BSD machine uses Firefox, so I can't test it there. Maybe you can start a bug report?

What kind of bucket?

Linux and the BSDs have pretty much made UNIX obsolete.

I don't know about Linux, but BSD definitely contained Unix code from USL, and vice-versa. They settled out of court. Should ever SCO decided to go after BSD, it would open a big can of worms. More details can be found in The Unix Heritage Society and Bitsavers Archives.

L3 cache existed long before the average consumer could afford a multi cpu system.

http://en.wikipedia.org/wiki/AMD_K6-III

Your cpu vs core explanation is so distilled and poor it's no wonder you chose to post anonymously. There are all kinds of exceptions to the general points you make, and they occur so frequently across different designs there isn't much point in trying to come up with blanket statements. Unless you know the the specific hardware you're targeting, you have to assume multi-cpu, and let the hardware handle the rest.

$sarcasm = "
It's also interesting to hear these ingenious ideas about the os being a delegator of system resources instead of what is doing now. Also it great to see all these truly revolutionary ideas come from MS. The article also clears up any confusion about these proposed abstraction layers -- no other OS is doing it now. It's quite a feat for MS to propose yet another parallelism technique, perhaps next they'll be announcing a new web framework cause we're running dangerously low on them as well."

http://www.freebsd.org/cgi/man.cgi?query=cpuset&apropos=0&sektion=0&manpath=FreeBSD+8.0-RELEASE+and+Ports&format=html
http://wiki.freebsd.org/Hierarchical_Resource_Limits

L3 cache existed long before the average consumer could afford a multi cpu system.

http://en.wikipedia.org/wiki/AMD_K6-III

Your cpu vs core explanation is so distilled and poor it's no wonder you chose to post anonymously. There are all kinds of exceptions to the general points you make, and they occur so frequently across different designs there isn't much point in trying to come up with blanket statements. Unless you know the the specific hardware you're targeting, you have to assume multi-cpu, and let the hardware handle the rest.

$sarcasm = "
It's also interesting to hear these ingenious ideas about the os being a delegator of system resources instead of what is doing now. Also it great to see all these truly revolutionary ideas come from MS. The article also clears up any confusion about these proposed abstraction layers -- no other OS is doing it now. It's quite a feat for MS to propose yet another parallelism technique, perhaps next they'll be announcing a new web framework cause we're running dangerously low on them as well."

http://www.freebsd.org/cgi/man.cgi?query=cpuset&apropos=0&sektion=0&manpath=FreeBSD+8.0-RELEASE+and+Ports&format=html
http://wiki.freebsd.org/Hierarchical_Resource_Limits

Sorry those torrents seem to be infected with GPLv3. How about these torrents.

How much RAM? ZFS loves RAM. I was locking up until I upgraded to 4GB. (I was hoping to go to 8GB but RAM prices shot up).

It makes a rock solid home server. NFS, SMB, CCXstream (XBMC), AFS (It's my time machine disk).

Congrats on the installer. Now you just need to Root on ZFS into the installer. (If you have any experience and can follow instructions, it's not hard at all, just long.)

Version specific handbooks: http://docs.freebsd.org/doc/

I believe this Wikipedia summary is as good as an update as anyone has of the progress and likelihood of future progress. An alternative is FreeBSD 8 (released Nov. 2009), which includes ZFS as an officially supported feature for the first time.

The point is testing this on smaller TLD. We have been working with .ORG and other TLDs to test DNSSEC for a while now. When the time comes for a signed root and .COM and .NET signed, we will be ready.

Less vague (from http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html):

While there are many early adopters of DNSSEC today, including many Top Level Domains (TLDs) the linchpin event that most people are waiting for in order to get really excited about DNSSEC deployment is the signing of the root zone. The plans for this have been laid, and the first stages of the deployment of the signed zone are already under way. You can read all about these plans, and the projected timetable at http://www.root-dnssec.org/. The key elements of the timetable are that by the end of May all root name servers will be serving a zone that contains DNSSEC signatures, although they will be unvalidatable (for a variety of complicated reasons outside the scope of this document). Assuming that there are no show-stopping problems in the initial deployment phases by July 1st the real root zone keys will have been published, and the real zone will be signed on the root name servers.

If you follow the link for that announcement, you can read more about Bind-specific issues, and Bind issues as they relate to FreeBSD.

You can also repair the computers by installing software that's free, technically superior and reasonably more secure than Windows.

You can download yours from: http://www.ubuntu.com/ http://www.debian.org/ http://freebsd.org/ and so on.

It's not like there are any other OSs that they could have used.

They used Linux because it was easy. Changing the GPL is just going to make companies like Tivo stop using FOSS, they'll just move to a project that has licensing that fits their needs better.

You've been able to use the linux adobe flash plugin with a native browser for quite some time now. Works just as well as it does in Linux (not necessarily saying much). The FreeBSD handbook is your friend:

http://www.freebsd.org/doc/handbook/desktop-browsers.html

This is wrong. the Ports system is based on CVS, so in essence, you can go back version by version, back to the beginning, and select version numbers of the software to install at will, without having to depend on precompile binaries. You use the supfile to select the port version you need http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html Gives you all the branch tags that you can check out via historical cvs. But Alter Relationship obviously didn't read the handbook, and started complaining without even reading the man pages.

100% incompetence.

I would bet all the money I have that 99.99% of these problems are caused by people not taking the time to learn the standard library of whatever programming language they're using. For some reason there's a gut instinct among programmers that they have to write all date processing code themselves. I can think of 4 separate occasions, off the top of my head, where I've replaced dozens of lines of sketchy, hand roled, date formatting code with a single call to strftime.

Just as a point of information, this information is available fairly clearly and obviously in the errno reference pages for various independent or widely diverged OSs/C libraries.

GNU/Linux (GNU C library)
FreeBSD (BSD libc)
Solaris (SYSV-derived)

Yeah. Dang Apple for preventing GrandCentral use anywhere else. Imagine how cool it would be if another OS were to pick up the technology and Implement it.

Blast Apple and all their closed source stuff.

I'm surprised that someone hasn't written something like BusyBox starting from FreeBSD's utilities.

They have. Go to a FreeBSD console and run ls -i /rescue. There are 133 binaries in that directory on my desktop, each being a hardlink to the same statically linked file, with behavior depending on the value of argv[0] when the program is run. The idea is to include all the programs you might need to repair a FreeBSD system in single-user without having even /usr mounted. See the man page for crunchgen(1) for more details.

Yes, because there are no open source, non-GPL'd, kernels around. They'd obviously have to start completely from scratch.

You must be new here. For your make-up assignment you are to familiarize yourself with our /. culture. CowboyNeal would approve it, and Netcraft would confirm it.

I, for one, welcome our FreeBSD 8.0 overlords. Long live FreeBSD!

That's my experience in testing active/active.

You may be interesting in this though.

http://lists.freebsd.org/pipermail/freebsd-announce/2009-October/001279.html

If you're really curious, it's on line 328 of FreeBSD's sbin/init/shutdown.c file. Here's a link.

Obviously, nobody wants to spend thousands of hours creating something then letting someone else (a corporation) sell it without royalties. Or letting people download it for free off the internet.

Linux.
Firefox.
MySQL.
Apache.
Gnome.
KDE.

And if you're going to redefine your original statement so that GPL counts as payment, I give you:

Chromium (browser and OS)
Open BSD
Free BSD

Hey Pirates, you think you aren't stealing?

Do we HAVE to go over this again?

Although I always enjoy the opportunity to recommend FreeBSD to somebody, I didn't really get an explanation of your needs. Are you going to be running servers? Desktop? Or just having fun? I imagine that you're just going to have some fun since you just want to learn something new. In that case I'd definitely go with FreeBSD. It is a great "learning" OS and is well documented thanks to the Handbook. The /usr/ports collection has the source code for just about any piece of software you'd ever need, and the dependencies are all taken care of for you. You get some pretty awesome hardware support, server daemons are incredibly easy to configure, it is robust as all hell, doesn't use a lot of resources, can also make a great desktop OS, lots of smart people on IRC you can get help from, and countless amounts of other things. Additionally I'd go with FreeBSD because there are a large percentage of servers on the internet use this OS. If IT is your profession, it definitely won't hurt to learn FreeBSD. All you need to know is, /etc/rc.conf and /usr/ports. Then you just move on from there :-) Good luck!

FreeBSD 8.0 and a couple of Intel Pro100B nics or Gigabyte NICS installed on any x86 system
built in the last 10 years should do just fine as a router.

http://www.freebsd.org/

Encrypted swap is easy: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/swap-encrypting.html sim

Linux emulation is broken and has been broken for ages.

Works for me.

It doesn't work with l4d2 dedicated server (segfaults), it doesn't work with rosetta (signal 4). Reproducible failure > "works for me."

Live UFS dump is broken.

Works for me.

Bullshit. UFS snapshots have been broken for a long time; read the thread. Core developers acknowledge it. Dump -L relies on UFS snapshots, and is therefore broken.

USB mass storage support is broken.

Still broken.

Wine is not supported on AMD64

And this is FreeBSD's fault why?

It works on Gentoo AMD64. Why can't FreeBSD support it?

ZFS in double parity mode is broken

Haven't move to zfs yet, but given your pattern I'm guessing you're wrong again.

That's right, you are guessing. You clearly haven't tried any of the things I described. So far, you're 0/6.

MTRR for older ATI cards is broken

If you're referring to bug I think you are, it was fixed awhile ago and was non-serious in first place. As with the rest of you're statements it's hard to know what you're talking about without referencing a bug report.

Feel free to actually reference a bug report. You're full of it. "works for me!" How informative... it doesn't, and if you'd tried it, you'd know. Come back when you've actually tried any of the things I mentioned, dipshit.

One is that Apple has done a good job of setting themselves up as the anti-MS underdog. Well, you get lots of geeks who hate MS. Thus if Apple is anti-MS, they like Apple. They never bother to examine if Apple's tactics are any better than MS's.

I don't purchase computers or operating systems based upon ideology. I choose the best tool for the job, as do most consumers.

Microsoft has historically made a crappy product, while Apple's products over the past decade or so have been technically, ergonomically, and aesthetically superior (and even price-competitive, provided that you fit into the right "niche")

Sometimes I just can't bring myself to be worked up about copyright law. Apple's done some bad things; Microsoft have done some bad things; RMS has done plenty that I disagree with. I suppose that BSD can claim the greatest ideological "purity" as the license can be summarized as:

"Here's some code. Do whatever the hell you want with it. Just don't sue us, and include a copy of this message if you decide to redistribute"

In truth, the actual license isn't much longer.

Most Linux distributions just can't provide the high level of quality that the FreeBSD project manages to offer.

Wow - your impeccable logic has convinced me! Where do I sign up?

Right here!

Personally I was rather disappointed to find out the installer doesn't support ZFS. For a ZFS-only system, you need to do some manual partitioning. I found it a bit hard-ish, even with their instructions.

Do you seriously believe firefox will test the 4GB limit?

Of course... Here is from my home system — the two instances belong to my (very) significant other and myself:
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
4954 i 10 47 0 1798M 637M ucond 2 0:00 9.47% firefox-bi
48498 mi 11 45 0 1150M 810M ucond 3 0:00 13.09% firefox-bi
...

Three times more windows/tabs — or simply more visits to something "heavy" (like Google Maps), and she is done... And that's without Flash, which is not available for our platform...

Now, the actual memory consumption is smaller, than the total size, but on a 32-bit system, that does not matter — you are limited by 4Gb per process, because 2^32 is 4Gb... My system is, actually, a 64-bit one (FreeBSD/amd64), so I am "prepared" for Firefox to exceed 4Gb. My Firefox at work (RHEL-5.4, 32-bit) is currently under 1Gb, but that's because it crashes about daily (probably, due to Flash — or because some of the bugs that the FreeBSD ports fix, that are present in the "official" builds, don't know), and thus has less time to leak...

Another note, of course, is that simply by building in 64-bit mode, you significantly increase the sizes of many internal data structures (which hold pointers to other structs — each pointer is now twice bigger). Still, I don't think, that overhead is more than 10-15% of the total memory consumption...

So, yes, the 4Gb ceiling is within reach, even if most people don't yet hit it often...

To quote Richard Prior, none of the above. ;)
Here's my own choice.

There's practicing African hospitality, and then there's becoming a daemoniac. ;)

FreeBSD is about to release 8.0, with ZFS, and ZFS has officially been labeled production-ready:

http://www.freebsd.org/news/status/report-2009-04-2009-09.html#FreeBSD/ZFS

Myself, it works good for me on a storage server. There are some edge cases left, for example I could provoke a panic by combining ZFS on a 3-disk array with automatically parking the disks on timeout. Accessing the filesystem with power down disks didn't go so well. This was in 9-current, though.

ZFS is still the only thing out there providing all of:
- snapshots
- compression
- attributes such as compression can be turned on and off by directory tree
- a "filesystem-aware raid", aka something that avoids the RAID hole
- and as mentioned optional extra redundancy (more than one disk can die) and the checksumming. That means, for example, you can have your filesystem like raid-5 but some directories as redundant as raid-6

Until Linux gets BTRFS (and I'm not sure how complete it is with regards to all those features) it's the best thing for a storage server out there.

%%

Apple's diversion either means they do their own thing (ZFS seems excessively hard to integrate) or is based on patent concerns, or the former because of the latter.

But if you look at the core of it, NetApp tries to claim patents on everything that does filesystem-integrated snapshots (as opposed to the lame LVM raw device layer snapshots in Linux). Reimplementing a filesystem with snapshots, whether you call it ZFS or not, won't help here.

The FreeBSD people still haven't been able to run and integrate it reliably.

It's now marked as production quality in FreeBSD, and it's now entirely possible to have ZFS-only systems. My home server boots directly into a ZFS root filesystem without any UFS filesystems to help it. Given those two facts, I'd say they've been able to run and integrate it quite nicely.

I'm quite disappointed to see that Andy discussed absolutely *nothing* about the state of nVidia drivers on FreeBSD.

There has been a long-standing battle between FreeBSD kernel developers and nVidia regarding their drivers, dating back to at least 2006. nVidia claims their driver has to go jump through hoops to deal with a shortcoming of the FreeBSD kernel, while kernel developers claimed nVidia's developers simply lacked the knowledge/understanding of the existing (stable) kernel API to use to gain what nVidia needs.

The discussion in question is here -- multiple links because it spans multiple months, and some mail clients don't seem to honour Reference-ID headers.

http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017062.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017077.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017078.html

The thread gets heated (as most crap on freebsd-hackers does), but then dies off without a trace of resolution. Literally nothing in the years to come. There are some indications in July of discussions going private between members of FreeBSD Core (also kernel developers) and nVidia, which is shocking, given FreeBSD developers insisting on public release of GPU documentation. Pot kettle black...

I'm quite disappointed to see that Andy discussed absolutely *nothing* about the state of nVidia drivers on FreeBSD.

There has been a long-standing battle between FreeBSD kernel developers and nVidia regarding their drivers, dating back to at least 2006. nVidia claims their driver has to go jump through hoops to deal with a shortcoming of the FreeBSD kernel, while kernel developers claimed nVidia's developers simply lacked the knowledge/understanding of the existing (stable) kernel API to use to gain what nVidia needs.

The discussion in question is here -- multiple links because it spans multiple months, and some mail clients don't seem to honour Reference-ID headers.

http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017062.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017077.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017078.html

The thread gets heated (as most crap on freebsd-hackers does), but then dies off without a trace of resolution. Literally nothing in the years to come. There are some indications in July of discussions going private between members of FreeBSD Core (also kernel developers) and nVidia, which is shocking, given FreeBSD developers insisting on public release of GPU documentation. Pot kettle black...

I'm quite disappointed to see that Andy discussed absolutely *nothing* about the state of nVidia drivers on FreeBSD.

There has been a long-standing battle between FreeBSD kernel developers and nVidia regarding their drivers, dating back to at least 2006. nVidia claims their driver has to go jump through hoops to deal with a shortcoming of the FreeBSD kernel, while kernel developers claimed nVidia's developers simply lacked the knowledge/understanding of the existing (stable) kernel API to use to gain what nVidia needs.

The discussion in question is here -- multiple links because it spans multiple months, and some mail clients don't seem to honour Reference-ID headers.

http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017062.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017077.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017078.html

The thread gets heated (as most crap on freebsd-hackers does), but then dies off without a trace of resolution. Literally nothing in the years to come. There are some indications in July of discussions going private between members of FreeBSD Core (also kernel developers) and nVidia, which is shocking, given FreeBSD developers insisting on public release of GPU documentation. Pot kettle black...

I'm quite disappointed to see that Andy discussed absolutely *nothing* about the state of nVidia drivers on FreeBSD.

There has been a long-standing battle between FreeBSD kernel developers and nVidia regarding their drivers, dating back to at least 2006. nVidia claims their driver has to go jump through hoops to deal with a shortcoming of the FreeBSD kernel, while kernel developers claimed nVidia's developers simply lacked the knowledge/understanding of the existing (stable) kernel API to use to gain what nVidia needs.

The discussion in question is here -- multiple links because it spans multiple months, and some mail clients don't seem to honour Reference-ID headers.

http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017062.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017077.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017078.html

The thread gets heated (as most crap on freebsd-hackers does), but then dies off without a trace of resolution. Literally nothing in the years to come. There are some indications in July of discussions going private between members of FreeBSD Core (also kernel developers) and nVidia, which is shocking, given FreeBSD developers insisting on public release of GPU documentation. Pot kettle black...

It's an interesting gimmick, but not sure what purpose it'd have for anyone other than XML monkeys.

There are automated ways to generate HTML, PDF, PostScript, and Plain Text from the XML-resume (this, for example, is how I do it), that I use to generated mine). Yes, recruiters ask me about the Word-version once in a while, and I tell them, no, I don't use Word.

The result looks pretty good to me (although it does not attempt to cram everything into a single page the way TFA's author does). One can even comment stuff out or make inclusion of certain items conditional. You may be looking for a sysadmin or a developer position, for example. With this you can produce different flavors of your resume from the same source...

It can also make your resume easier to search some day — when the search engines recognize this particular XML-template...

There is certainly nothing "gimmicky" about it — this sort of thing is, what XML is best suited for...

Do you have any clue who is responsible for developing Common Address Redundancy Protocol?

You have other options too,

http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/heartbeat/

or for a DRBD eqiv, try ggated + gmirror

http://serverbbs.ccw.com.cn/thread-14564-1-1.html

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/nutshell.html#INTRODUCTION-NUTSHELL-USERS

Many, many not listed, one example is php.net.

Come on! FreeBSD has been releasing via bittorrent for a while now. Get with it OpenBSD!

Maybe the way it was written is why FOSS is where it's at? Might not be such a bad idea to keep it around?

Then again, maybe the GPL is not responsible for great free software and open source software being written.

Don't get me wrong, I think developers should be allowed to pick their license of choice, including GPL. But there are plenty of examples of free software and open source software being highly successful and widely used that are not GPL'd.

The assumption that the GPL is responsible for the success of FOSS reminds me of a Simpsons episode where Homer is carrying a rock around that supposedly repels lions (or something). Lisa says, "That's ridiculous! What makes you think that repels lions?" and Homer replies, "You don't see any lions around, do you?"

I believe that the publicity surrounding GPL and the way it forces developers who use code licensed under it was a major factor in the expansion and acceptance of open source software. That doesn't mean that those other licenses aren't just as valuable to the ongoing health of and expansion of open source software. It just means that GPL created the mindspace to allow non-geeks to view open source as something more than a fringe element.

Maybe the way it was written is why FOSS is where it's at? Might not be such a bad idea to keep it around?

Then again, maybe the GPL is not responsible for great free software and open source software being written.

Don't get me wrong, I think developers should be allowed to pick their license of choice, including GPL. But there are plenty of examples of free software and open source software being highly successful and widely used that are not GPL'd.

The assumption that the GPL is responsible for the success of FOSS reminds me of a Simpsons episode where Homer is carrying a rock around that supposedly repels lions (or something). Lisa says, "That's ridiculous! What makes you think that repels lions?" and Homer replies, "You don't see any lions around, do you?"

> BSD lacks any sort of inter process security, so BSD is not secure for the desktop (granted nobody makes use of these tools for the linux desktop (i plan
> on fixing this and becoming your god when i get round to it), but BSD doesn't even have them).

What exactly is "inter-process security?" Please define this. I want to know exactly what you're talking about.

> AFAIK it is also a lot harder to find signed BSD images where as almost all linux iso come with a sig to verify them against.

Wrong -- MD5 and SHA-256 checksums of all the FreeBSD ISOs are provided. Look at CHECKSUM.MD5 and CHECKSUM.SHA256. This has been in place since *at least* the 4.x days.

Next time, take a little time out of your Linux-centric day to educate yourself before making yourself look like a complete git.

Is the open source solution close enough to the needs of the Ontario government that, as the article alleges, all you need to do is buy some servers and set it up and there are negligible other costs? I seriously doubt it. I would be willing to bet heavily against it. Anyone who thinks otherwise probably hasn't spent much time developing software for government.

I haven't, no...but what are said needs?

I'm assuming that the main component of a record system is going to be a database. You'll also need a usable system and interface for entering and retrieving said records into the DB. You're also going to want to do SQL dumps and periodic offsite backups, so that if anything goes wrong, you can get the data back.

Of course, it will also be very important to ensure that the operating system the database is hosted on, is as robust as possible, to minimise the possibility of crashes; as well as a strong filesystem for times when you need to make a lot of queries at once. Even though that system is meant for servers, you can still make it user friendly for your administrative staff as well, if you need to.

If you're going to want the records accessible from outside the hospital, you'll probably also want to make sure that they are protected by a couple of very secure firewalls, as well, since it could potentially mean the loss of someone's life if they get cracked.

Finally, they will need to make sure that whoever puts the network together does so according to sound administration principles, as well.