FreeBSD 7.0 Release Now Available

cperciva writes "The first release from the new 7-STABLE branch of FreeBSD development, has been released. FreeBSD 7.0 brings with it many new features including support for ZFS, journaled filesystems, and SCTP, as well as dramatic improvements in performance and SMP scalability. In addition to being available from many FTP sites, ISO images can be downloaded via the BitTorrent tracker, or for users of earlier FreeBSD releases, FreeBSD Update can be used to perform a binary upgrade."

Comments

Netcraft

[Anonymous Coward]

Netcraft confirms it, first post.

Re:Netcraft

[Anonymous Coward]

I've never understood the point of wasting a mod point modding down an AC comment that most people won't see anyway.

Re:Netcraft

[professional_troll]

Yeah, you should be giving your mod points to me BITCHES!

Fuck Islam

Re:Netcraft

[Anonymous Coward]

slashdot moderators are generally douchebags and take out their frustrations (shitty job, no sex life, etc) by downmodding on slashdot.

Re:Netcraft

[gr8scot]

slashdot moderators are generally douchebags and blah, blah, blah Then, why don't you just go away?

I thought FreeBSD was dead...

[Anonymous Coward]

nt

Still hard to install?

[Nigel_Powers]

I don't want to have to figure out disk geometry to install an OS...have they made it as easy as Ubuntu?

I'd gladly give it a go.

Re:Still hard to install?

[Creepy Crawler]

It reminds me of an old joke.. It's not BSD until its BSDm.

Mmmm masochism.

I guess it couldn't get much worse...

Re:Still hard to install?

[nurb432]

Its been easy for the last several releases if you are willing to accept defaults.

Re:Still hard to install?

[piojo]

Hmm. The time I tried to install FreeBSD, the installer choked on my hardware. I tried two different dell desktops. Part of the problem was an inability to deal with a USB keyboard. I hope that has been fixed, and I plan to try FreeBSD again, some day. I'll stick with a more common OS, for now.

Re:Still hard to install?

[nsayer]

Slated for 7.1 is support for booting GPT partitioned disks. This will make the whole partitioning thing even easier, since it will make BSD labels and the MBR go away entirely, and partitioning will be done entirely using LBA addressing.

Re:Still hard to install?

[ceroklis]

You don't need to specify the geometry. However you need to know:

- the IRQs and port numbers used by your cards
- the video clock rate
- the number of stop bits for the terminal
- the hard drive PIO mode
- the memclock index value
- the hard drive encoding method
- the ROW precharge time
- the typematic delay

newbie-ready as you can see.

Re:Still hard to install?

[Anonymous Coward]

er... how is that flamebait? moderation isn't supposed to be a way of saying "i don't agree with that"... read the mod guidelines sometime.

Re:Still hard to install?

[Anonymous Coward]

I've never needed to know any of those things to install FreeBSD. We run a number of FreeBSD virtual machines and physical servers. I installed them all myself. The most complicated part was entering network information, since all of these systems had static IPs and weren't using DHCP. Unless you're doing something out of the ordinary, you can just use all the defaults and have a fully working system in 15-20 minutes on an average machine.

I've been using FreeBSD since version 2.2.7. I've been using Linux and other OSs even longer. Operating systems that have been around as long as these weren't just created from the start to be a breeze to install. Linux used to require a lot more manual configuration than it does now... just because something like Ubuntu makes it easy doesn't mean it always was. Linux has progressed in this area, and so has FreeBSD, and so have most other mature operating systems.

Also, FreeBSD is not targeted at the same audience as something like Ubuntu. A better comparison would be PC-BSD and Ubuntu, as they are targeted at desktop users. I guess maybe FreeBSD could be compared to the server or alternate editions of Ubuntu, in which case the install process (using text screens) is fairly similar.

Re:Still hard to install?

[Anonymous Coward]

Why the hell are you ranting about Ubuntu and Linux? Is it a required trait of the BSD user to randomly start trolling Linux and GPL?

Re:Still hard to install?

[hcmtnbiker]

I don't want to have to figure out disk geometry to install an OS...have they made it as easy as Ubuntu?

You don't need to figure out the disk geometry if you use the guided installer. I usually like to set that myself anyways, I find it funny you want it compared to Ubuntu, Ubuntu almost wants to hold me back from setting up my disk exactly how i want it. As far as how easy the installer is, if you can install a Slackware system its pretty similar, same solid color menus and package selection(if you don;t chose the install everything).

Re:Still hard to install?

[halber_mensch]

I don't want to have to figure out disk geometry to install an OS...have they made it as easy as Ubuntu?

I'd gladly give it a go. Let me fix that for you.

I don't want to have to figure out something worthwhile to say...it's not my favoritest Linux so I'll just discredit it.

I refuse to willingly evaluate it without preconceived prejudice.

Re:Still hard to install?

[halber_mensch]

Hmm. The time I tried to install FreeBSD, the installer choked on my hardware. I tried two different dell desktops. Part of the problem was an inability to deal with a USB keyboard. I hope that has been fixed, and I plan to try FreeBSD again, some day. I'll stick with a more common OS, for now. FWIW, there's something about Dells and USB keyboards and the FreeBSD single user mode. I'm not sure exactly what the problem is (or I'd contribute my own fix), but a workaround is to go to the loader prompt on boot (option 6 I think) and enter 'set hint.atkbd.0.disabled="1"'m then 'boot'. This will bump the AT keyboard out of the way and allow the USB keyboard to function. You'll either need to set this in your /boot/device.hints after installation or remember to do it whenever you boot into single user mode.

Re:Still hard to install?

[Anonymous Coward]

LBA adressing -- brought to you by the RAD Redundant Acronym Department.

Re:Still hard to install?

[smash]

Its easier.

Press "A" for auto partitioning and then "A" in the disk layout section for auto-defaults.

As it has been since at least FreeBSD 4.0.

Re:Still hard to install?

[parc]

I haven't run FreeBSD since 6.0, but the problem with Dells, IIRC, is that the AT controller acts like there's a keyboard there even if there isn't one.

I had no problem using the clearly labeled "boot with USB keyboard" menu option.

It's a moot point -- with the at mux that came in I believe halfway through the 6-series, you can have as many keyboards as you feel like.

Re:Still hard to install?

[Anonymous Coward]

They're just jealous because BSD is dying. You don't even have to point to Netcraft, Slashdot no longer provides a link to the BSD section. It was a nice run, but it's time to let go and move on.

Re:Still hard to install?

[hedwards]

For people that are looking for the more typical mainstream Linux install experience, FreeBSD still isn't there. But it isn't that hard, and there's always DesktopBSD which is pretty much identical apart from the install program and desktop integration.

Whether FreeBSD is too hard to install or not comes down far more to tolerance for ncurses style programs. I personally grew up on them with dos and early windows versions.

Which reminds me that I've got to download a copy of DesktopBSD to try out.

Re:Still hard to install?

[xeoron]

Yes, or at least close to it PC-BSD.

Re:Still hard to install?

[Anonymous Coward]

Please look at PC-BSD or DesktopBSD; they would be the equivalent to Ubuntu.

http://www.pcbsd.org/
http://www.desktopbsd.net/

Disk Geometry trolling isn't funny or have you confused this with partitioning. So, are you trolling or are you stating that you don't like to partition drives. If it is partitioning then you may want to check out the above links; if you're trolling, then continue with what you're doing

Re:Still hard to install?

[LM741N]

Ubuntu easy to install? Perhaps. But does it meet the quality standards of FreeBSD and esp OpenBSD? I dumped Ubuntu and over wrote the partitition with OpenBSD because everytime I tried to manually enter in my network encryption parameters manually, the next time Ubuntu booted it just ignored it and locked onto the strongest unencrypted signal.

Re:Still hard to install?

[PReDiToR]

LBA adressing -- brought to you by the RAD Redundant Acronym Department. Are they a subsidiary of the Department of Redundancy Department?

Reminds me of a .SIG here - They repeated themselves over and over again incessantly without end - or however it goes.

Re:Still hard to install?

[PReDiToR]

While I believe you quite rightly attained your +Insightful mod, I couldn't even start to tell you what my disk geometry is, and I'm running openSUSE, XP and (sorry) Vista on the same HDD, partitioned through Linux fdisk after XP had the whole disk, and Vista was the last thing on there. Messing around with partitions is not hard, but never have I been asked to delve into things that the BIOS presents and are ignored only to be faced with a utility querying the HDD itself and be asked if the returned information is true.

I'm not ignorant, stupid, unable to find out how to do things (except work out why this 2.6.22-17 kernel that I rolled myself with all the right things in refuses to accept my high quality 80 wire cables) when they need doing, but for serious, how is it that I have never been asked things like that under Linux?
Why is the BSD automatic detection routine so unsure of itself that it asks if you want to override it?

I'm downloading the .ISO right now to give it a fair try, so I'm not baiting anyone. I have a shell account on a server that uses FreeBSD and I find the different layout and commands interesting. Can't wait to give it a try.

Re:Still hard to install?

[snl2587]

everytime I tried to manually enter in my network encryption parameters manually, the next time Ubuntu booted it just ignored it and locked onto the strongest unencrypted signal.

Were you using nm-applet and the keyring? I've never had a problem doing it like that.

Re:Still hard to install?

[Anonymous Coward]

No, it's not required, but I sure do see a lot of it. What I find amusing is the Linux zealots ragging on BSD because it doesn't have a lickable install environment like most distros do nowadays. Face it: the overwhelming number of self-proclaimed linux users here on Slashdot are using Ubuntu or some other one-button install CD. They don't know how to install, the installer knows how to install. The old days of partitioning and setting IRQs and memory addresses are gone. So fine. FreeBSD's installer is easy. It's even easier if you know what you're doing, which a lot of people here don't. That's OK too; that's why there's Ubuntu or Mint or whatever. So cut the sanctimonious crap. Linux isn't going to change the world, no matter how cool the installer is. Got it?

Re:Still hard to install?

[Anonymous Coward]

have they made it as easy as Ubuntu? Oh fuck off, faggot. Stop spreading the cancer. The Linux community is already suffering with the *buntu mongoloids who have no idea of what a man page is, please leave the BSD community alone.

Re:Still hard to install?

[MattBurke]

There's something about Dells, USB keyboards and any non-windows installer... Tried about 5 os boot disks on a vostro before I discovered you need the keyboard in just the right socket - and then it screwed up after you chose the kbd type in the installer, necessitating a different machine to install on. Once installed it's worked well.

Re:Still hard to install?

[MattBurke]

I forgot to add - this was a mix of linux (debian, ubuntu, rhel, centos) and FreeBSD

Re:Still hard to install?

[filipl]

hmm. last time i tried to install debian (about two years ago), the installer choked on my hardware: it couldn't install on sata disks. this was of course fixed afterwards...

i have been using usb keyboards for years on my bsd...

anyway, what i'm trying to say: it all depends on your mindset: change is always difficult, if you aren't really interested. everyone is free to use whatever he wants. however don't criticize based on some reservations one might already have.

btw 'common' depends. to me bsd is common. to you linux (perhaps even only one distribution) is common. to others windows is common.

have fun!

Re:Still hard to install?

[mitashki]

Come on guys... This is not over OS superiority right?

Re:Still hard to install?

[larry bagina]

Kathleen Fent choked on my cock.

Re:Still hard to install?

[L4t3r4lu5]

Oh fuck off, faggot. Stop spreading the cancer. The Linux community is already suffering with the *buntu mongoloids who have no idea of what a man page is, please leave the BSD community alone. Why not tell these folk what a man page is instead of hurling abuse at them? Seriously, stop acting like a 14 year old on MySpace and mature a little.

Better yet, help make BSD more user-friendly so people don't need to know what a man page is. You know, like Microsoft let you set up wireless connections without messing with shell commands for half an hour.

Part of the problem, not the solution.

Re:Still hard to install?

[Anonymous Coward]

That's why I use Microsoft. It just works. I find, in the end, FOSS is more expensive. To much productivity is lost because I have to spend so much time figuring out how to get something so stupid as a fucking keyboard to work on my computer. Then you have to set up your network hardware, configure programs (hopefully you can get 85% functionality out of them), and so on, and so on, and so on . . .

Calgon^H^H^H^H^H^H Microsoft . . . take me away!!

Beside the fact that when everything is working properly, and I'm not constantly trying to jury-rig some crippled functionality out of a program, it builds my employers confidence in me.

There are two ways you can look like a hero to your employer
    1) Saving them a little bit of money
    2) Keeping your system up and running smoothly, which has the added benefit of also keeping your customers happy.

Don't get me wrong, I love the idea of open source, but instead of FreeBSD/Linux/Unix/Solaris and all of the variants within, why don't we pool our resources and get one (1) fucking open source system that can actually compete with Microsoft? Only then will the Chinese be forced to recognize "The Year of Linux" on their calendar.

Oh yeah, this is Slashdot. I'm forgetting about that whole anit-Micros^H$oft sentiment thingy. In other words, I guess you can mod me a troll now.

Re:Still hard to install?

[geminidomino]

Unless you actually want to install from CD and use any of the packages.

As of 6.2-R, it still required no fewer than four CD-swaps (between 2 cds) since the installer can't handle "dependencies coming in the future"[0]

[0] Package A(Disc 2) depends on Package B(Disc 1) which depends on Package C(disc 2). Instead of installing Package B on the first run through, knowing the other two will be coming, it will ask you to swap back and forth.

I love my freeBSD, but installing it has gotten really painful.

Re:Still hard to install?

[chanda3199]

We run a number of FreeBSD virtual machines... Please, if anyone knows how this is done, reply to let me know. We use Xen for VM's here, but can't get it to work with FreeBSD. Can anyone link me to a VM package that will run FreeBSD? Tutorial anyone?

Re:Still hard to install?

[nurb432]

To be honest, i have never tried the package CDs. I either do it via the net if im in a hurry so i get the most current version, or via ports if im not in a rush ( ports are the preferred way anyway ).

The only exception is if im building a base server, i have my favorite set of packages that i keep on a separate cd and install them after a minimal install.

Re:Still hard to install?

[Icy]

Hmm, I have been installing FreeBSD for around 10 years and I don't think I have never had to know anything about the disk geometry of any of the installs. Are you sure you are not thinking about one of the other BSDs, they are different you know?

You can use the defaults or put in how many MB you want for each slice, simple. The installer works great, even from a serial console. I do wish they would add ZFS support to the installer... It is not as easy as Ubuntu, but then again, they are not targeting that group of users.

Re:Still hard to install?

[geminidomino]

Some things I like to have from the get-go. bash, for example... I'm perfectly capable of using tcsh or even *shudder* /bin/sh, but it adds steps. Add non-root admin user -> install bash -> change user's shell

Kind of obnoxious. As I said, I still use it, I just really wish they'd consider this the problem that it is.

Re:Still hard to install?

[tehBoris]

Wow, this is actually an original comment, instead of some copy+paste from somewhere else.

Well, let me be the first to say it: if MS-everything is actually cheaper for your bussiness in the long run, then by all means use their stuff like that. But bear in mind that they can always force an 'upgrade' upon you just by making their new stuff incompatible with your version, just like they make it incompatible with all other software.

And no, FOSS developers (and users!) will never join all to make a single product, as Open Source is about choice and freedom, it is inevitable that someone will make an alternative to some program simply because he or she doesn't like the way it works, or the way it is developed. And it is likely that many will agree with the 'dissident' and use and develop the program, thus 'wasting effort'.

And now I will shut up because this is way off-topic ;)

Re:Still hard to install?

[empaler]

Debian still won't play nice with my RAIDs unless I'm ready to play contortionist. Same goes for Ubuntu. Fedora FTW! :)

Re:Still hard to install?

[ByOhTek]

I've never had a USB Keyboard problem with FreeBSD

From 5.4 to 7.0, K6-III + Tyan/VIA mobo -> Athlon + Abit/nForce -> Athlon64 + ASUS/nForce -> Core Solo + Toshiba/Intel.

I've used USB keyboards on all of them. The only time I don't use an PS2 Keyboard is with the Athlon, and then only when I need to edit the bios settings (no USB support for the BIOS menus? WTF?)

*shrug* milage and varying and all that.

Re:Still hard to install?

[Anonymous Coward]

Let me fix that for you.

Let me fix your fix for you.

I am a typical condescending FreeBSD advocate, and I am going to flame you for not being smart enough to figure out all the quirks of my niche operating system.

Re:Still hard to install?

[Sancho]

The main thing is that the packages on the ISO are frozen at -RELEASE. They're almost always out of date by the time you install them, which means that you need to go upgrade them, which makes one wonder what the point of installing it in the first place was. Unless it's a machine with limited or no network capabilities, installing the packages from the CD itself is going to be wasted time.

Besides, once the package is installed, it's easy enough to change the shell

When I install a new system, I just run the following as a matter of course:
pkg_add -r zsh && pkg_add -r vim-lite && pkg_add -r mutt && pkg_add -r sudo && chsh -s /usr/local/bin/zsh sancho

Of course, adding screen is harder, allegedly due to a bug in screen. Gotta go to the ports for that:
portsnap fetch extract && cd /usr/ports/sysutils/screen && make install clean

Re:Still hard to install?

[Anonymous Coward]

Why not tell these folk what a man page is instead of hurling abuse at them? Why should I? It only takes a couple of seconds in Google to find out what a man page is. But I suppose it's easier to ask someone else to do it and get the answer spoonfed and the drool wiped off your chin. I'm all for helping newcomers, but they have to do their homework first.

Seriously, stop acting like a 14 year old on MySpace and mature a little. BAWWWWWWWWWWWWWWWWWWWWWWW

Better yet, help make BSD more user-friendly so people don't need to know what a man page is. You know, like Microsoft let you set up wireless connections without messing with shell commands for half an hour. You gotta be kidding me. Everyone should know what a man page is when dealing with a *nix environment. Why not take all manual transmission cars off the road so people don't have to learn stickshift? They could just put it in Drive and go! (lol car analogy) If you need a GUI, use a Microsoft product. There are some of us who are comfortable with a CLI and don't need to have it bastardized down because it's too scary for some people.

Part of the problem, not the solution. NO U

Re:Still hard to install?

[Sancho]

You have to use a third-party patch to get domU support for FreeBSD. Unfortunately, there is no dom0 support, and while there are people supposedly working on it, there aren't many status reports.

The Xen information is available here: http://www.fsmware.com/xenofreebsd/7.0/ linked from http://wiki.freebsd.org/FreeBSD/Xen.

That said, VMWare seems to run FreeBSD just fine. VirtualBox, sadly, doesn't play nicely with newer versions of FreeBSD.

Re:Still hard to install?

[nsayer]

Touché

Re:Still hard to install?

[halber_mensch]

While I believe you quite rightly attained your +Insightful mod, I couldn't even start to tell you what my disk geometry is, and I'm running openSUSE, XP and (sorry) Vista on the same HDD, partitioned through Linux fdisk after XP had the whole disk, and Vista was the last thing on there. Messing around with partitions is not hard, but never have I been asked to delve into things that the BIOS presents and are ignored only to be faced with a utility querying the HDD itself and be asked if the returned information is true.

I'm not ignorant, stupid, unable to find out how to do things (except work out why this 2.6.22-17 kernel that I rolled myself with all the right things in refuses to accept my high quality 80 wire cables) when they need doing, but for serious, how is it that I have never been asked things like that under Linux?
Why is the BSD automatic detection routine so unsure of itself that it asks if you want to override it? Read this: http://myfreebsd.homeunix.net/freebsd/disk_geometry.html

It may hold the answers that you seek.

I don't know the current state of this issue, but I suspect it has been resolved. Suffice it to say that my FreeBSD 6.3-STABLE system is happily chugging along on a 160G disk and has never complained about geometry.

# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1a 989M 212M 698M 23% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/ad0s1e 45G 15G 26G 36% /usr
/dev/ad0s1d 97G 60G 29G 67% /var
/dev/da0a 1.9G 1.7M 1.7G 0% /repos
linprocfs 4.0K 4.0K 0B 100% /usr/compat/linux/proc

Re:Still hard to install?

[bsd_usr]

Hah! I have you beat! I have been using FreeBSD since 2.2.2!

I would say that ever since FreeBSD 2.2.5 the install for me has gotten easier. Why? Because it supported my ATAPI CDROM. I have to say that sysinstall is a breeze. It's simple and to the point.

Those cry babies that complain that it's too hard to install have probably never had to install it from a DOS partition. Now that was a bitch! It also took forever.

I think I'll keep my 6-STABLE for awhile. I'll play around with 7.0 until 7.1 comes out, then I'll make the switch on my production boxes. I'm interested in giving ZFS a try. I have heard much about it, but I haven't had enough time to try it out.

Well, it's not that I don't have the time, it's just that all this shit doesn't seem to excite me as much as it used to. I'm getting tired of I.T. *sigh*

Re:Still hard to install?

[Anonymous Coward]

FreeBSDag.

Re:Still hard to install?

[Brandybuck]

Sounds cool.

The rule of thumb is to give each OS its own primary partition, and each can divide that up as they please. FreeBSD chose to use the BSD scheme (duh) while Linux used the Microsoft scheme of extended/virtual partitions. This definitely made it easier for Linux to coexist with DOS/Windows. But it does make it frustrating trying to squeeze in room for FreeBSD (or Solaris).

Just remember, save a primary partition for FreeBSD when you format your new harddrive. You can always use it as a backup partition in the meantime.

Just use the default geometry

[Anonymous Coward]

You don't need to set the disk geometry unless you have weird-ass old disk hardware. Just accept the defaults.

Re:Just use the default geometry

[djupedal]

Leave my old weird ass out of this...

Re:Just use the default geometry

[Brian Gordon]

Hold on, if you partition with a different utility like gparted/qtparted, will BSD take the space it's given or insist on partitioning something itself?

Re:Just use the default geometry

[Anonymous Coward]

If you have pre-existing partitions that you want to use, it will be perfectly happy with that arrangement.

Re:Just use the default geometry

[Anonymous Coward]

But be aware that it's still not fond of booting from extended partitions. They work fine for everything else, but keeping / and /boot on a primary partition is a good idea.

Of course, the easiest is to give FreeBSD one large primary partition and then use the BSD labels to split that up.

Re:Just use the default geometry

[Anonymous Coward]

I'll leave *this* out of your weird old ass.

(bonus! captcha is dismount)

Re:Just use the default geometry

[eosp]

We xkcd readers would likely refer to "weird ass-old disk hardware." CAPTCHA: probed.

Re:Just use the default geometry

[Anonymous Coward]

They're talking about geometry, you're talking about partitioning.

Regardless, yes, if you tell it to use a partition it will use that partition. What else would you expect?

Performance is really lacking

[Anonymous Coward]

I was installing the pre-releases as they were coming and now FreeBSD makes Linux look like the IO king. Nothing I could do would give back my old FreeBSD performance other than downgrading. I tried linux on the same machine and for linear reads and writes it finished minutes ahead of the FreeBSD tests.

Re:Performance is really lacking

[Anonymous Coward]

you have something configured incorrectly or non-equivalently.

Re:Performance is really lacking

[eht]

Actually, the usual answer is the pre release have extra stuff turned on to help enable debugging. That's why it's not a release where they turn that extra stuff off, or you can recompile the pre release kernels and such.

ZFS?

[Anonymous Coward]

What level of ZFS support does this have? Is it well tested yet?

Re:ZFS?

[Anonymous Coward]

It's quite good. Where I work, we've been using the release candidates to store upwards of 15 TB of data, spread over about 50 hard drives. We haven't had any problems, and the performance has been fantastic.

Solaris still offers better support, but the ZFS support offered by FreeBSD is production quality.

Re:ZFS?

[Neo-Rio-101]

It's actually pretty stable. Having said that, there are some issues surrounding it. For starters, FreeBSD 7.0 uses ZFS ported from version 6, whereas Solaris now has ZFS pegged at version 10. There have been numerous enhancements made to ZFS in v10 which aren't in v6. It remains to be seen how the FreeBSD implementation catches up to the Solaris implementation. There is an upgrade command in ZFS that can upgrade the file system to the new version - but no idea how this will work in future FreeBSD versions yet. Secondly, ZFS runs better on 64bit - so using the 32-bit i386 release is not recommended. Thirdly, you need quite a large clump of memory - over 1GB and preferably 2GB or more. It is recommended to tune some kernel memory parameters to ensure that ZFS doesn't cause your system to panic. ZFS seems to like munching on memory in an attempt to scale. Otherwise ZFS is really good and very stable - perfect for use in a file server. Just don't build your file server on old 32-bit hardware, and make sure you have plenty of RAM.

Re:ZFS?

[T-Bone-T]

Does ZFS really require that much memory? I don't know how to not make this sound trollish, but that should shut people up about Vista being bloated. Imagine their complaints if Vista's file system required that much memory and then you had to load everything else, on top of that!

Re:ZFS?

[Anonymous Coward]

Uh, I don't think the Vista file system can come close to the flexibility/power of ZFS.

Re:ZFS?

[EvanED]

Secondly, ZFS runs better on 64bit - so using the 32-bit i386 release is not recommended.

This is quite disappointing to me, as I was going to run FreeBSD on my old box as a file server, and have been anxiously awaiting its release. (I want ZFS's snapshots.)

Is the caution against 32-bit of the form "it's slow and can't handle dozens, hundreds, or thousands of users", or of the form "it's poorly tested, unstable, and may eat your data"?

Re:ZFS?

[rmm4pi8]

I can't answer your original question, but for a basic file server, why not just use Linux and lvm2? It handles both snapshots and disk-redundancy without needing hardware RAID. Manifestly production stable, and scales to many terabytes of storage.

Re:ZFS?

[Neo-Rio-101]

You can still run ZFS on i386, but it's not recommended. There will be a performance hit.
I think the lowest you can go in the memory department is 512MB.

Either way if you're not going to use recommended hardware, you will HAVE to tune ZFS in the system to cope.

I seriously doubt ZFS will destroy your data - but running it on sub-optimal hardware could potentially cause the system to kernel panic.
During BETA testing, even with 2GB of RAM and a core-2 duo, I managed to get a panic without tuning anything. I think there was a last-minute patch in FreeBSD 7 to prevent this. Either way, I'd feel a bit uncomfortable running ZFS on i386 without tuning.

Re:ZFS?

[cblack]

I use linux lvm fairly heavily to manage storage across a handful of FC arrays, it is quite nice. But I have to say zfs is far nicer for many reasons (better admin interface, much nicer sw raid management and capabilities, etc).

Re:ZFS?

[tonyr60]

"Does ZFS really require that much memory?"
No, but if it is available it will certainly use it. The upside of ZFS using more memory is that disk IO will be lower so better overall performance.

Re:ZFS?

[tonyr60]

So you have not used ZFS yet? If so, you would know "why not just use Linux and lvm2?" It is just so easy and fast to add extra storage and provide data security across many different devices. For one thing, newfs is redundant.

Re:ZFS?

[zsau]

You seem to know a lot about ZFS. Is it a file system suitable for use on home computers or small file servers that just let us access movies and music from any computer in the house? Or is it complete overkill in that situation and I should just stay with whatever filesystem I have at the moment.

Re:ZFS?

[Anonymous Coward]

Man that pisses me off. I was looking forward to running ZFS on an x86 box which is a couple of years old. Only now do I find out it's recommended for 64-bit hardware which only 7 or 8 people have.

Is one able to recover from ZFS panics? What kind of tuning is required? (I've barely used BSD, switching from Linux)

Re:ZFS?

[Just Some Guy]

Only now do I find out it's recommended for 64-bit hardware which only 7 or 8 people have.

Well, 7 or 8 people plus the few million people who have bought generic Dell boxes (or anything nicer) in the last year or so.

Re:ZFS?

[Anonymous Coward]

No, it's not production quality. Not when there's bugs which can deadlock the entire system when copying large sums of data between UFS and ZFS filesystems:

http://wiki.freebsd.org/ZFSKnownProblems

The "this is experimental" tag should remain until all of the issues on the ZFSKnownProblems page are addressed.

Re:ZFS?

[Hatta]

Last I checked, you couldn't just add a device to ZFS. Instead you have to create a whole new vdev to add to the pool. So if I had a ZFS on 2 500GB drives, one data one parity, and I wanted to add another 500 gb drive so I'd have 2 data and 1 parity, I can't do that. I'd have to buy two whole 500gb drives and have 2 data and 2 parity drives. And even then, those 2 parity drives are kind of wasted being split among vdevs like that, since it would be possible for me to lose both drives in one vdev and lose data. Whereas if I started with 2 parity drives for the whole thing, I could lose 2 drives with no data loss.

Re:ZFS?

[EvanED]

Well, I do have 1.5 GB of RAM, so I think I'll be set there. (The processor is an Athlon XP 2000+.)

How difficult is it to tune? Is this something that will take me 30 minutes, or something that will require lots of experimentation over days? (I don't know much about ZFS, and essentially nothing about the utilities that you use to interface with it.)

Thanks for your answers BTW.

Re:ZFS?

[fe105]

Hi,

I did quite some testing on ZFS using FreeBSD and Solaris and am not so impressed with ZFS anymore. Sure it is a lot faster than vinum raid, but it is not very flexible. On both Linux and Solaris, Veritas was a lot faster.

Note: this was with FreeBSD7 rc2, not the release version.

Some results; not made into a nice page yet http://www.crystalconsulting.eu/bench/

Hardware: AMD X2 3600, 3GB ram, 1 OS disk, 8 sata/pata 250G disks.

iozone -R -r16M -s 16g -i 0 -i 1 -i 2 -f /mnt/foo
dd is with 8GB file, using conv=fsync where available.

Note on linux write performance: I suspect that it does something nasty with write-caching..

DD MB/s| IOzone-16M-8GB random random
write read| write rewr read rerd read write
raidz: 73 144 | 74 63 144 144 43 59 Freebsd (unstable)
vin5: 20 43 | ? ? ? ? ? ? FreeBSD vinum (unstable)
raidz: 92 150 | 95 91 143 141 57 108 Solaris10 ZFS raidz
SVMr5: 14 87 | 13 15 63 66 74 13 Solaris10 SVM raid5 (1.5 hours to initialize)
vrts5: 35 163 | 38 39 178 178 152 39 Solaris veritas4, raid5 8G, log on data-disk
vrts5: 35 163 | 38 39 178 178 152 39 Solaris veritas4, raid5 8G, no log
vrts5-7d: 37 169 | 41 42 162 162 151 40 Solaris veritas4, raid5 8G 7 disks, log on disk 8
lxmd5: 133 165 | 144 119 154 158 151 106 Fedora7 MD raid5 (4 hours to initialize)
lxmd-16G 130 164 | 141 115 156 156 129 98 Fedora7 MD raid5, with 16GB file instead of 8GB
vrts5: 32 120 | 38 38 150 149 120 36 CentOS4.6, veritas 4, raid5

zfs0: 155 236 | 183 175 225 226 60 162 FreeBSD7rc1 zfs (16G)
vin0: 177 61 | 193 186 61 61 71 181 FreeBSD vinum stripe, no softupdates.
vrtstr: 263 172 | 305 310 185 183 162 307 Solaris10, veritas 4, stripe 8 disks. (8G and 16G, identical results)
zfs0: 132 169 | 139 141 175 202 57 139 Solaris10 ZFS raid0
SVMr0: 148 112 | 136 161 86 83 73 164 Solaris10 SVM raid0
lxmd0: 188 259 | 202 135 246 248 197 142 Fedora7 MD raid0
lxlvmi8: 183 137 | 192 175 85 85 114 167 Fedora7 lvm -i "raid0"
vrtstr: 270 236 | 301 304 187 182 169 303 CentOS4.6, veritas 4, 8 disk stripe

zfs10: 100 201 | 107 110 199 201 56 102 Freebsd7rc1 (8G)
vin10: 131 31 | 137 136 31 31 42 129 Freebsd7rc1 (8G) with 2 stripes of 4 200g partitions, as per handbook
zfs10: 72 163 | 108 100 175 218 57 104 Solaris10 ZFS raid10
vrts10: 259 171 | 304 308 183 183 163 305 Solaris veritas4, striped mirror 8G
lxmd10: 159 91 | 172 103 96 97 111 100 Fedora7 MD

No need to comment

[RiotingPacifist]

with the announcement of the features last night the following topics were beaten to death already:
Why use FreeBSD? (why not?)
FreeBSD is dead! (clearly its not)
FreeBSD is not dead!
yahoo use freeBSD (nobody cares)
FreeBSD vs Linux (ooh flame ware, but then everybody realized that it doesnt matter some people prefer FreeBSD for stability & the fact its all integrated, some people prefer linux because it has lots of flashy features & there are loads of projects to add extra features to it ( but they're not integrated and don't always play well together)!)

please go about your business there's nothing to spam about here!

Re:No need to comment

[LingNoi]

You just made Slashdot boring. : /

Re:No need to comment

[BasharTeg]

How about the benchmarks that show that FreeBSD just took the performance crown from Linux?

Re:No need to comment

[Anonymous Coward]

By the way, Yahoo predominantly uses Linux now, not FreeBSD. They still have FreeBSD stuff in use, but their predominant platform is Linux now. And yes, they still have FreeBSD boxes available for testing/development by the FreeBSD Project/Foundation hosted at Yahoo.

Re:No need to comment

[Kent Recal]

Ehm, *which* crown?
Last time I checked most performance crowns were worn by solaris.

Re:No need to comment

[Anonymous Coward]

Did you just give your opinion on every topic you think people should stop giving opinions on?

Oh no you didunttt

Re:No need to comment

[BasharTeg]

Yeah, I know, I run Solaris 10 x64 for my MySQL boxes. The crown I'm referring to is umm... the Linux fanboi vs FreeBSD fanboi crown...

Besides, administrating Solaris is *not* fun. I know they're getting better, but they need to add the word intuitive to their vocabulary. When I don't have to edit 5 files to change one boot-time IP address and/or hostname, we can talk up how great Solaris is. Nevermind comparing Blastwave to FreeBSD's ports tree. Much respect for their fine grained locking and MP performance, but if I could have their kernel with a FreeBSD userland and FreeBSD ports tree, I'd take it in a second.

Re:No need to comment

[Kent Recal]

Yes, solaris is a bitch. Has been that way forever and will probably stay that way for a while.
But the argument was about performance and that is the precise and primary reason why so many
people still bother with the "ugly bully".

BSD and linux fanboys arguing about "performance crowns" sounds like kart-racers
arguing about "who has the fastest car in the world" to me.

It's cute to watch but sometimes I just can't resist...

STABLE

[webword]

I love how STABLE just sticks out, like BSD wasn't stable before. Ha!

It was damn stable and it'll be stable again, and again...

Re:STABLE

[cperciva]

*I love how STABLE just sticks out, like BSD wasn't stable before. Ha!*

"7-STABLE" is FreeBSD-speak for "this implements the FreeBSD 7 API/ABI, and any program you write or compile for an earlier release will work just fine on a later release". In other words, the Application Programming/Binary Interfaces won't change in incompatible ways.

This is in contrast to Linux, where updating to a new kernel (belonging to the same "stable" kernel branch, or even applying security patches) can make programs break until you recompile them.

Re:STABLE

[morgan_greywolf]

Yeah, but OTOH --

Linux has had journaling file systems for years. In fact, it has excellent support for multiple journalled file systems -- XFS, ReiserFS, ext3, and JFS. FreeBSD is just now getting around to supporting journalled file systems. ZFS support has been available in FUSE for quite a while now and I believe is more fully featured than what is found in FreeBSD 7. Linux has also had support for SCTP for quite a while as well. Linux has support for lots more hardware, too.

So, you take your tradeoffs -- do you want cutting edge desktop features or are you more concerned with stability? If stability is the name of the game, then of course you want something as stodgy as FreeBSD. Otherwise, if you're willing to live with the occasional odd program that needs to be recompiled with the new kernel or the occasional kernel bug that pops up, then use Linux.

It's also about your requirements. That's why we have freedom of choice.

Re:STABLE

[Just Some Guy]

Linux has had journaling file systems for years.

FreeBSD hasn't wanted journaling filesystems for years, since we've had softupdates which solve many of the same problems but with half the writes. The recent gjournal plugin to the GEOM system is a block-level journal. In other words, it handles all writes to a device, whether or not the overlying filesystem supports journaling. Journaled FAT anyone?

I just said journal a lot, didn't I?

Re:STABLE

[ruinevil]

Explain to me the advantages of journaling over soft updates, which UFS2 supports? I also want to know what the new gjournal FreeBSD utility actually does, especially when used with UFS2. Does it keep a log of changes, along with the metadata updates of the UFS2 soft updates?

Re:STABLE

[Just Some Guy]

I also want to know what the new gjournal FreeBSD utility actually does, especially when used with UFS2.

From gjournal(8):

This is block level journaling, not file system level journaling, which means gjournal everything gets logged, e.g.: for file systems, it journals both data and metadata.

Re:STABLE

[Anonymous Coward]

You couldn't be more wrong.

FreeBSD hasn't wanted journaling filesystems for years, since we've had softupdates which solve many of the same problems

Softupdates don't solve the important unclean shutdown fsck problem very well. Background fsck is a nightmare for any production system with non-trivial amount of spinning rust.

but with half the writes.

Wrong. Half the writes as compared to the naive gjournal journalling. Real modern journalling filesystems usually have the option to journal just metadata. What's more, journalling is far more flexible than softupdates. You can journal to a small battery backed RAM device for example.

The recent gjournal plugin to the GEOM system is a block-level journal. In other words, it handles all writes to a device, whether or not the overlying filesystem supports journaling. Journaled FAT anyone?

Wrong. There has to be some filesystem support work done.

I just said journal a lot, didn't I?

No. You did not say it "journal" once.

Re:STABLE

[Just Some Guy]

You couldn't be more wrong.

You underestimate my capacity for wrongness.

Softupdates don't solve the important unclean shutdown fsck problem very well. Background fsck is a nightmare for any production system with non-trivial amount of spinning rust.

How's that? I mean, I'd rather not have to fsck my terabyte RAIDs, but if I have to, at least the system can be running live and undegraded while the loose ends get cleaned up.

Wrong. Half the writes as compared to the naive gjournal journalling. Real modern journalling filesystems usually have the option to journal just metadata. What's more, journalling is far more flexible than softupdates. You can journal to a small battery backed RAM device for example.

If you're just journaling metadata, then you're not getting the full benefit of journaling (and definitely not anything more than softupdates offers, as it's basically an in-memory ordered journal of metadata transactions to be committed). As far as the battery-backed RAM: that's like saying cats are better than dogs because you can give them medicine if they get ringworm. BTW, with FreeBSD's GEOM system, you could journal to an encrypted RAID on a remote host if you wanted to. You might have already known that; others might not.

Wrong. There has to be some filesystem support work done.

Wrong. gjournal is a generic journaling provider. You can use it to wrap any other GEOM component. From it's own man page:

When gjournal is configured on top of gmirror or graid3 providers, it also keeps them in a consistent state, thus automatic synchronization on power failure or system crash may be disabled on those providers.

Pretty neat, huh? You can wrap it around your RAID to make it crashproof. If you think background fscks are bad, then you've probably never watched a few terabytes of mirror resync itself. Anyway, what you misunderstood is that filesystems have to be altered to interact meaningfully with the underlying journal. UFS has been so modified. That doesn't mean that other filesystems won't work on top of it (which would be silly because a gjournal looks just like any other block device), but that they're not optimized for it.

Re:STABLE

[Anonymous Coward]

Ya, good thing BSD doesn't use that wild crazy linux kernel.

Re:STABLE

[herve_masson]

No offence, but I found your answer somehow single sided. My experience is quite different (so is, probably, the way I'm using bsd)

I am using BSD in production environments for years; almost everything I'm installing IS bsd based. I was wanting journaled filesystem since forever, just because I'm sick of fsck, and yes, linux has been a lot better on this for many many years (I also work a lot with linux). Softupdates are truly great, but they don't cover the check part.

The block level journal with GEOM works fine and certainly has a lot of technical vertues, granted. However, it sucks, alot, in some case such as mine. It has tons of side effects I had to fight against, not mentioning the enormous amount of disk it takes which prevent journaled filesystems under ~4Gb (I'm working with embeded small sized systems). As someone who had to write automatic installers/cloner for bsd and linux, I spent an enormous amount of time to make it working reliably on journaled geom while it barely took a few mn to turn ext2 into ext3.
As for its usefulness, I'm not totally certain that journaled FAT is something I should care about, but it's just me.

Re:STABLE

[Anonymous Coward]

Hasn't wanted? That's a lie, as anyone who has followed the freebsd-fs list knows. But that's always how the world looks to FreeBSD advocates. If it's not there, it's because it's not needed.

Also, it's funny to see that the 1:1 threading library has now become the default. Back when FreeBSD decided to go with a MxN implementation, Solaris and Linux had already realized that MxN just wasn't worth it and would only perform better in theory, and now FreeBSD has finally learned the same lesson.

Re:STABLE

[ceeam]

UFS+SU is still much, much faster than any Linux filesystem in real world usage. Plus moving a huge amount of data does not lock other disk-accessing processes, doing "chmod -R .." on a huge tree IME is incomparably quicker on FreeBSD (like 5-10 seconds on FreeBSD whereas on the very similar tree it virtually died for 15+ minutes on RHEL/Ext3), etc.

Re:STABLE

[Just Some Guy]

No offence, but I found your answer somehow single sided. My experience is quite different (so is, probably, the way I'm using bsd)

None taken! Yes, our usage is probably different. I use it almost exclusively our our multipurpose servers (like a machine loaded out with a bunch of jails, each running services that use different resources so that we can max out the hardware). These tend to stay up until I reboot them for upgrades, so I don't really deal with fscks too much. That said, I'm running 7-PRERELEASE on my ancient, flaky home server that hardware-crashes at least once or twice a month. With the background fsck, I'm never offline for more than a couple of minutes. Is it worse for you?

It has tons of side effects I had to fight against, not mentioning the enormous amount of disk it takes which prevent journaled filesystems under ~4Gb (I'm working with embeded small sized systems).

I'm not a BSD dev, just a very happy user, so I might not have the breadth of experience to really appreciate this. What is it about background fscks that would be a problem on filesystems under 4GB? I'd think they would finish in record time.

As for its usefulness, I'm not totally certain that journaled FAT is something I should care about, but it's just me.

That was meant more as an example of silly things you can do, not anything you'd actually want to do. :-)

Re:STABLE

[Mr.Ned]

"FreeBSD hasn't wanted journaling filesystems for years, since we've had softupdates which solve many of the same problems but with half the writes."

It doesn't solve the "wait hours for fsck after unclean unmount", which has made it a dead-end for a number of years now. FreeBSD may not have wanted a solution to this problem, but lots of people have; it was a recurring topic on the FreeBSD mailing lists until ZFS support was added.

Re:STABLE

[dAzED1]

hasn't wanted journaling filesystems for years? Methinks you speak for a community you don't know as well as you think.

That's like saying they didn't wantsmp support for all that time they didn't have it...

Re:STABLE

[morgan_greywolf]

UFS+SU is still much, much faster than any Linux filesystem in real world usage. Plus moving a huge amount of data does not lock other disk-accessing processes, doing "chmod -R .." on a huge tree IME is incomparably quicker on FreeBSD (like 5-10 seconds on FreeBSD whereas on the very similar tree it virtually died for 15+ minutes on RHEL/Ext3), etc. Then you haven't tried all Linux filesystems in real world usage. ext3 sucks ass in terms of performance, but is compatible with a wider variety of tools. ReiserFS or XFS are much, much quicker. IBM JFS performance is pretty good, too, and is rock-solid stable. For absolutely fast performance, use ext2, which IME is comparable to UFS in terms of performance.

I don't have much experience with the performance aspects of UFS on BSD, but, presumably UFS on Solaris or HP-UX is pretty much the same, and I have to say that IME, XFS is quicker.

Re:STABLE

[Anonymous Coward]

This is in contrast to Linux, where updating to a new kernel (belonging to the same "stable" kernel branch, or even applying security patches) can make programs break until you recompile them.

I don't think you're allowed to admit that on the slashdot internets.

Are you sure you didn't mean Windows?

Re:STABLE

[nuzak]

> ReiserFS or XFS are much, much quicker.

XFS is pretty decent (but only recommendable for 64 bit systems). ReiserFS is nice until it actually does need a fsck (it happens). If by some chance your partition actually survives its awesomely broken fsck process, it may still be faster to simply copy back all the data on the drive from backups. By hand. With tiny magnets.

Re:STABLE

[evilviper]

It doesn't solve the "wait hours for fsck after unclean unmount",

Yes, it did. UFS2 added background fsck, so you boot-up immediately (faster than with journaled filesystems), and can use the system indefinitely. Meanwhile, fsck runs at a low priority, in the background, to do the basic cleanup needed.

Re:STABLE

[evilviper]

UFS2 added background greysck,

God-damn privoxy... Let's try that again... background fsck...

Re: STABLE

[Dolda2000]

This is in contrast to Linux, where updating to a new kernel (belonging to the same "stable" kernel branch, or even applying security patches) can make programs break until you recompile them. Huh? Not that I wouldn't like to argue that FreeBSD has many advantages over Linux, but that has to be one of those disadvantages of Linux that I haven't noticed so far. I would like to ask you to quote at least one example of Linux ABI breaking, because I sure haven't noticed any (at least not over the last couple of years). Of course, I shan't swear that that is thanks to the kernel as much as it is thanks to glibc, but I don't think that would change my point very much, since not many programs should be talking directly with the kernel anyway.

Re:STABLE

[Brandybuck]

It doesn't solve the "wait hours for fsck after unclean unmount"

et me be blunt: The reason journaling is so popular under Linux, is because it is so damned necessary! Waiting for fsck isn't a huge problem if you never have to fsck. But I have found with Linux 2.6.x, regardless of distro, that I get kernel panics and hangs at least once a week. Maybe it's just my laptop, and maybe it's the fault of third party drivers and not Linux itself. But no matter, without journaling I would have long ago thrown my laptop through the window.

But with the high popularity of journaling, I suspect that I'm not the only one who would otherwise have to sit through frequent fscks.

p.s. FreeBSD has background fsck, do you don't have to "wait hours". Your system is usable in just a few minutes, albeit at a temporary performance penalty.

Re:STABLE

[Anonymous Coward]

>> Softupdates don't solve the important unclean shutdown fsck problem very well. Background fsck is a nightmare for any production system with non-trivial amount of spinning rust.

>How's that? I mean, I'd rather not have to fsck my terabyte RAIDs, but if I have to, at least the system can be running live and undegraded while the loose ends get cleaned up.

How is that? What do you mean how is that? It doesn't solve the unclean shutdown problem *very well*. Yes, it is better than nothing, but it is still not great. Undegraded is wrong, it consumes disk / controller / memory bandwidth and IOPS, and CPU time. This is often bad if you're running real workloads at the same time.

>> Wrong. Half the writes as compared to the naive gjournal journalling. Real modern journalling filesystems usually have the option to journal just metadata. What's more, journalling is far more flexible than softupdates. You can journal to a small battery backed RAM device for example.

> If you're just journaling metadata, then you're not getting the full benefit of journaling (and definitely not anything more than softupdates offers,

Yes you do, because you solve everything that softupdates does, and the unclean shutdown problem, and also have the option to far reduce the constraints on writeout if you use an NVRAM device for the journal.

Also, you really are getting the "full benefit of journalling" with metadata journalling. Or at least, a very large part of it. Checkpointing and crash recovery etc. have to still be done at the application level because UNIX's filesystem API is not transactional so it is often the case that the manipulations that are required span multiple filesystem calls anyway. So it isn't as if by using data journalling you can suddenly just do away with logging on your DBMS or anything like that.

> as it's basically an in-memory ordered journal of metadata transactions to be committed). As far as the battery-backed RAM: that's like saying cats are better than dogs because you can give them medicine if they get ringworm.

Now you're just confusing the issue because you've got nothing argue against it. Nice.

>> Wrong. There has to be some filesystem support work done.

>> Wrong. gjournal is a generic journaling provider. You can use it to wrap any other GEOM component. From it's own man page:

        "When gjournal is configured on top of gmirror or graid3 providers, it also keeps them in a consistent state, thus automatic synchronization on power failure or system crash may be disabled on those providers."

Presumably this is referring to journalling for the gmirror and graid3 metadata. Not filesystems.

> Pretty neat, huh? You can wrap it around your RAID to make it crashproof. If you think background fscks are bad, then you've probably never watched a few terabytes of mirror resync itself.

Mirror resync is bad sure, but it increases linearly with the size of the disk, and is generally easy
to turn into big sequential IOPs. fsck is a completely different beast for most contemporary filesystems.

> Anyway, what you misunderstood is that filesystems have to be altered to interact meaningfully with the underlying journal. UFS has been so modified. That doesn't mean that other filesystems won't work on top of it (which would be silly because a gjournal looks just like any other block device), but that they're not optimized for it.

I think you misunderstood.

From http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=3

You can use gjournal without any file system on top of it and with a really small *amount of work* you can use it with any file system FreeBSD has. Currently *only UFS support is implemented*.

So I think you are the one who overestimates your capacity for being right. Especially about things where you obviously know a little bit, but not really the full story.

Re:STABLE

[Anonymous Coward]

Anyway, what you misunderstood is that filesystems have to be altered to interact meaningfully with the underlying journal. UFS has been so modified. That doesn't mean that other filesystems won't work on top of it (which would be silly because a gjournal looks just like any other block device), but that they're not optimized for it.

In case it is still not clear to you, I'll try to explain further.

Journalling is not just about ensuring the IO from the filesystem hits the disk. That is what the block layer is for (if your block layer is lossy, then your filesystem is the least of your worries). It is not even about ensuring IOs reach the disk in the order which they were submitted from the filesystem, although softupdates uses something like this (with careful modifications of the filesystem to ensure that the order in which it submits IOs is going to result in a consistent state)...

No, journaling is about transactions. Having a transaction of IOs commit atomically or not at all. And the reason why you have to update your filesystem is because you have to know what bundles of IOs should be put into which transactions.

For example, suppose you want to append a block to the end of a file. Given a UFS like filesystem, you have to 1) update the size of the file; 2) find a free block and allocate it (mark it as no longer free); 3) link that block into your inode's block structure 3a) potentially create an indirect block, doubly indirect block, etc. each of which also requires step 2. Now if any of these things happens while others do not, then you end up with a corrupted filesystem. If you enclose all this in a transaction, then the journalling layer will ensure it all happens or none of it happens.

If you understood this, it should be obvious why you can't just magically use journalling on a filesystem that doesn't know anything about transactions or journalling itself.

Re:STABLE

[Anonymous Coward]

Ah fuck off you arse licking freebsd homo cunts modding me down. Can't hack it when you're wrong, eh?

Re:STABLE

[Anonymous Coward]

XFS works fine on 32-bit systems.

Re:STABLE

[Anonymous Coward]

How does this bullshit get modded up? You cock sucking FreeBSD fuckers just sit here sucking each other's cocks all day while telling each other how great you all are?

If a freebsd distro hangs or crashes once a week it is because of bad hardware or user error.

p.s. FreeBSD has background fsck, do you don't have to "wait hours". Your system is usable in just a few minutes, albeit at a temporary performance penalty.

Hey, fucker, there are systems running Linux with filesystems hundreds of TB large. Guess how long your background fsck takes on even a 1TB filesystem with several million inodes? Now how long does it take when it is fighting the regular workload for IOPs?

Thank you, fuck off.

But BSD is dead.

[Anonymous Coward]

A new release? I thought BSD was dead.

Re:But BSD is dead.

[slack_prad]

It has re spawned.

Re:But BSD is dead.

[Anonymous Coward]

FreeBSD suffers from a couple of serious process flaws -- it is an operating system which is truly at home neither in the open-source nor the proprietary markets primarily because, although the source is open, the development team is not. Furthermore the license allows proprietary software to "steal" source code and use it. The combination of these problems leads to a somewhat inferior OS.

Now, Apache uses a BSD style license but they have an open development model which allows them to take advantage of a very large developer pool in order to stay ahead of their competition. In fact although proprietary versions of Apache exist which perform better than the official releases, SGI has put out some open source patches which generate even larger performance boosts. This is the reason why they have such a strong showing in terms of market share.

BSD once had potential but the procedural problems they are experiencing hurt it when it comes to the market. I suspect that this is probably in part because the BSD teams are not interested in such things, and that is a shame... In fact, although I labeled it as an inferior OS, this is not due to lack of progress within BSD -- it has been progressing somewhat, but rather because all the improvements they make tend to be quickly copied by their competitors AND they lack the developer pool to stay ahead of this game (a problem which does not exist in the Linux or Apache communities, though for somewhat different reasons).

I don't think that there is enough widespread support for BSD to save the operating system. What must be done is an opening up of the development process OR a GPL-style restriction on redistribution. In many ways I favor the former.

Even in a worst case scenario, I don't see BSD completely dying. I think the developers are less into competition and more into a sort of idealized cooperation. As a result, even if BSD becomes more marginalized, I don't think that it will die outright. It will most likely outlive Netware, for example.

Re:But BSD is dead.

[Macka]

It may not be YOUR idea of open source, but it's still open source none the less. And providing it retains relevance on new hardware, it will never die.

Personally I've never used it, but after reading this thread I think I'll fire up VMware and give it a try. I come from an Ultrix & Tru64 background which were/are heavily influenced by BSD, so many of the concepts are familiar to me.

It should be fun. And isn't that what much of Open Source is all about.

Oooh

[Anonymous Coward]

Pretty red section, I've never seen the BSD section before. Slashdot needs more sections with nice colors.

ZFS Support

[T-Bone-T]

The summary says it has ZFS support but the website says experimental ZFS support. That seems like a pretty important distiction.

Re:ZFS Support

[Cokeisbomb]

I'd download it, but Comcast would probably think im doing something illegal and cut off the rest of my internet access. Also - how is the downside to being first post and getting a thousand replies to your nonsense "first post NT" message not mentioned more. I'd never go for first post for fear of email.

Re:ZFS Support

[dewarrn1]

ZFS is indeed labeled experimental, and it's an important distinction. That said, I believe that Pawel Dawidek, who ported the file system from Solaris, is using it in production. The chief caveat at the moment is that ZFS should only be used on the amd64 architecture. Other issues are not specific to FreeBSD's implementation of ZFS, e.g., the large memory footprint, but are instead inherent to the current release of ZFS and would be the same under any OS. More about the project at http://wiki.freebsd.org/ZFS/.

Re:ZFS Support

[voisine]

This is not intended as a troll... really... but it's good to keep in mind that this is the FreeBSD team's definition of "experimental". You may be more accustomed to the meaning that the Linux community attaches to that term. When Linux says it's experimental, that generally means it won't work for most people. When FreeBSD says it's experimental, that means you can probably use it in production but you might want to keep an eye on it.

Re:ZFS Support

[zulux]

Seconded!

We're using FreeBSD 7.2 RC2 ZFS in a production environment on Amd64. It's getting hammered, and holding up fine.

1) ZFS has *solved* our storage problems.
2) ZFS needs 2GB of RAM
3) You should run it on a dual core processor if you're going to use compression.
4) Research glabel so you can move drives around from cable to cable and still use the same device name.*

*more info: http://www.freebsd.org/cgi/man.cgi?query=glabel&sektion=8

Re:ZFS Support

[T-Bone-T]

I understand what you mean. I figured that if it was included with the stable version, ZFS support is probably very good and just has a couple minor issues.

Re:ZFS Support

[setagllib]

Your company may have access to some sweet technology, but I doubt a time machine is one of them. Perhaps you're really running 7.0RC2, not 7.2RC2.

If you *do* have a time machine, do CPU topology detection and EFI+GPT work in 7.2? Does 8.0 have a new installer yet? Inquiring minds want to know.

Re:ZFS Support

[Tuzanor]

The same is also true for ZFS on solaris. It's not QUITE there, yet.

Re:ZFS Support

[PReDiToR]

When Linux says it's experimental, that generally means it won't work for most people. Define "work".
As I posted up in the thread, pata_via incorrectly detects my 80 wire cables as 40 wires, but the whole switch over from /dev/hda to /dev/sda (and sdb, hpt366 still puts my 4 RAID chip devices as hda b c and d) went very smoothly and two kernels ago was labelled EXPERIMENTAL.

Turning off all EXPERIMENTAL kernel options leaves you with a system that really is only good for i386, not the i686 and better.

Funnily enough, the devices connected to the HighPoint chip are using the same cables, so it is just a detection routine, and dropping from ATA133 to ATA33 is a PITA, but not a killer when you're using that damned XP for playing games. Linux is still limited by the 2Mbps internet when torrenting so its not really a killer when you don't expect uber-speed from your desktop. I would trade speed for security any day of the week, but I know a fix is right around the corner (/me prays).

Re:ZFS Support

[tonyr60]

Yep, about the same status as NTFS....

Re:ZFS Support

[Anonymous Coward]

No FreeBSD developer of any repute would advise *anyone* to use ZFS for anything remotely important. It is broken for real work. If you want to experiment with it, it is advised to have at least 2 gigs of memory *minimum*. The more memory you have, the more time you will have to play with ZFS before it locks up or crashes.

Re:ZFS Support

[Anonymous Coward]

ZFS support is very experimental, and also very broken -- in ways which are unsettling (especially the deadlock issue happening during heavy I/O between UFS and ZFS):

http://wiki.freebsd.org/ZFSKnownProblems

I'm not posting this URL to try and put ripples in the water, but those problems have been mentioned for months now, and those responsible for the ZFS port to FreeBSD have not responded to any of the reports; they're MIA.

I can post freebsd-stable mailing list threads if people want additional proof of these problems, and how they manifest themselves.

Re:ZFS Support

[Just Some Guy]

When FreeBSD says it's experimental, that means you can probably use it in production but you might want to keep an eye on it.

Does that hold true for such things as tmpfs? I've been using that on a devel server without incident, but would like to roll it out elsewhere if it was widely thought to be stable.

Re:ZFS Support

[Anonymous Coward]

AFAIK tmpfs passed all regression and filesystem tests, has good performance and is now included as experimental to make sure it gets wider attention. The only caveat I know about is that fsck pass# in fstab needs to be 0, or you'll experience hangs at boot. There have been some reports on the lists about tmpfs panicking in very specific scenarios, but none so far have been reproducible.

Judging your skill by your comments on this story, please roll out to production :-)

Re:ZFS Support

[bhima]

for #1 yes, for #2 NO.

Have a nice day.

Re:ZFS Support

[Anonymous Coward]

"When FreeBSD says it's experimental, that means you can probably use it in production but you might want to keep an eye on it."

I beg to differ. I have tried several times to get release versions of BSD to run on my computers.
It NEVER has worked, sometimes not even willing to boot into the installer.
Linux, any of several varieties, just works. Even in beta, most things work.

Re:ZFS Support

[Hatta]

Or you could buy a SATA drive.

Re:ZFS Support

[PReDiToR]

I would need to buy a sATA PCI card or a new computer to go with it, but right now I'd prefer to have the detection routine fixed so that it works ...

Woohoo!

[Thornae]

And it's payday!
2.5 TB ZFS NFS, here I come!

no cutesy animal name?

[Anonymous Coward]

do not want!

Re:no cutesy animal name?

[morgan_greywolf]

How about Dusty Daemon?

Nahh....

PC-BSD or DesktopBSD updates coming soon?

[Zott and Brock]

Anyone know anything?

Re:PC-BSD or DesktopBSD updates coming soon?

[tim_mcc]

Don't know about DesktopBSD, but PC-BSD is about to release version 1.5 which will still use the 6.3 base for the system since we know 6.x is reliable, and our stuff works on it properly.

PC-BSD 2.0 will be the next version, and we'll be using FreeBSD 7, and KDE 4 on it. Expect to see that in around six months.

how's the wifi support for proprietary cards?

[Anonymous Coward]

I got a laptop with a Broadcom 4318. Is this well supported, or something you have to try & pray?
And speaking of laptops, does FBSD have a straightforward/easy-to-use disk encryption mechanism (say, on the order of TrueCrypt)?

Re:how's the wifi support for proprietary cards?

[stox]

If FreeBSD doesn't have a driver, you can use the Windows driver. Geom will allow disk encryption, to an even greater degree than TrueCrypt.

Re:how's the wifi support for proprietary cards?

[Anonymous Coward]

FreeBSD is fading out. It is not in the mainstream. It is like the Amiga. When you use FreeBSD you are not choosing a tool. You are getting saddled with a hobby that you may not want.

Marginalized operating systems like FreeBSD require you to jump through more hoops to get things accomplished. Not only do you have to track changes in your operating system, but you have to track changes in unsupported software and emulation libraries. You always have to tweak and use "work-arounds" because your hardware is probably not supported by any vendor.

Things only get more hairy day by day as FreeBSD becomes increasingly marginalized.

Even though it has been said before, nonetheless it is true: BSD is dying.

Good developer interview at onlamp

[Jeff-]

There is a good interview with many key FreeBSD contributers about new technologies and improvements in 7.0. It is quite technical.

http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=1

Any luck with HT1000 DMA yet?

[Just Some Guy]

I have a dual-Opteron rackmount Dell with a ServerWorks HT1000 chipset, running 7.0-PRELEASE from January 15, that was having DMA-related fits. Does anyone know if they've got that problem under control yet? I had seen it discussed a lot on the mailing lists but lately haven't had the time to follow closely. Either way that server's staying on the 7-STABLE line because it's so much faster that I can live with running the drives in PIO4 (and with 4GB of RAM those drives don't get touched a lot).

Re:Any luck with HT1000 DMA yet?

[mike_sucks]

You're probably better off asking the -stable or -current mailing lists.

/mike

Re:Any luck with HT1000 DMA yet?

[Just Some Guy]

The point of asking here was that, as I mentioned in the OP, I haven't had time to read them lately. :-)

Re:Any luck with HT1000 DMA yet?

[mike_sucks]

Fair enough, but given most people here are Linux or Windows kids, you're still better off asking the lists - even if you get a "read the archives!" response you'll know more than you'll get here. >:)

/Mike

Re:Any luck with HT1000 DMA yet?

[Anonymous Coward]

The point of asking here was that, as I mentioned in the OP, I haven't had time to read them lately. :-)

But clearly you do have time to ask a question about it on Slashdot and then follow the responses to your question. Why not spend that same amount of time asking on the mailing list and then following the responses there?

Wait....

[Anonymous Coward]

        Mod parent up.... ...I'm lost...what is this about?

      dfp_ord=Math.random()*12100000000000000;
      dfp_tile = 1.3;

Won't compile.

[BossMC]

/usr/src7/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c: In function 'padlock_xcrypt_ecb': /usr/src7/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/src7/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: error: 'asm' operand has impossible constraints
*** Error code 1

Stop in /usr/src7/src/secure/lib/libcrypto.
*** Error code 1

Stop in /usr/src7/src.
*** Error code 1

Looks like I will have to wait.

Re:Won't compile.

[urbanriot]

Did you use custom CFLAGS?

Re:Won't compile.

[BossMC]

CFLAGS were just "-pipe", I changed it to "-O -pipe", and I have myself a fresh, and I must say awesome, FreeBSD 7.0 install running. This is the smoothest upgrade of FreeBSD (or any OS) that I have ever done.

glabel

[dewarrn1]

Good tip, hadn't tripped over that utility. Thanks!

Considering switching.

[B5_geek]

I run debian on my main workstation (have for a long time).

These are my requirements before I switch:

fluxbox as wm.
various KDE apps, esp. Amarok.
NFS support
Nvidia binary video drivers. so that I can play: Never Winter nights & Enemy Territory.

Can/Will FreeBSD work for me?
(I run dual Opteron 270's with 2GB of ram so SMP is important but AMD64 is not).

Re:Considering switching.

[outZider]

You'll have everything you need. You may want to consider PC-BSD, a.. friendlier edition of FreeBSD. It uses KDE by default, and as you're a Fluxbox user, you'll know how to swap that out as needed.

The only gotcha is that nVidia's binary drivers are just as finicky as in Linux, and you're SOL if you want to use the amd64 version of FreeBSD, unless I'm out of touch. You can find their binary driver here.

Re:Considering switching.

[BossMC]

If your current setup is working, don't bother switching. FreeBSD is great (I use it on 3 computers), but there is nothing that will blow your mind.

Re:Considering switching.

[excelblue]

I happen to have a very similar setup on my FreeBSD 7-STABLE system right now, and it works great.

You should have no problems at all. It'll work perfectly.

However, is there a compelling reason for you to switch? Debian is a great operating system, and unless it's not working out too well for you, you should not just switch for no good reason. You risk being unproductive for a few days, running into issues you don't know about, etc.

Re:Considering switching.

[B5_geek]

After a few crappy/corrupt (non apt-get) installs + a full HD + a new bigger/faster HD my system needs to be nuked and reinstalled.

I LOVE apt. I love the breadth of software that is available for it. But I'm a geek and I want to try something new.

How does one install new software on BSD? (do you compile everything from source?)
Or are there repos available?

Re:Considering switching.

[Hatta]

You're probably spoiled by the package manager. Ports are neat, but apt is a dream. At the very least you'll have to get used to a different way of doing things. If you use a lot of custom repositories (e.g. rarewares) you might encounter a few headaches getting all the software you want. There are some things, like 'apt-cache search' that it's not immediately obvious how to do on ports. I think you're just supposed to string together 'find' and 'grep' commands, since ports is just a tree full of text files.

It's definately worth a shot if that kind of thing interests you. But I'd install it on a router or something first, so you can get used to it. Personally, I got tired of wondering "Now, how do I do THIS with ports?!", and went back to debian. Which isn't to say apt is more capable, I just know it better.

There's also the issue of getting used to the BSD userland; the GNU tools have a few more features, the BSD tools are a bit more minimalistic. Which again comes down to a matter of preference.

Re:Considering switching.

[dadragon]

How does one install new software on BSD? (do you compile everything from source?)

I upgraded from 6.2 to 7.0-PRERELEASE by doing the following:

It's a convolouted process, but I wanted to follow FreeBSD 7 development. It's easier when you do it from a binary CD. Basically you restart from the CD and upgrade and it's automated.

Start by updating my system source:
$ sed -e 's/RELENG_6/RELENG_7/' /usr/share/examples/cvsup/stable-supfile > /root/7-supfile
$ csup -h cvsup6.freebsd.org /root/7-supfile

Now the source is updated. So we build:

$ cd /usr/src
$ make buildworld buildkernel

Now the system is built from source, ready to go into my temporary directory. Back up /etc and other config files:

$ mergemaster -p

Now my /etc is backed up ready to merge later. Install new kernel

$ make installkernel
$ reboot

Now I start up in single user mode. Install new system just build from source.

$ mount -a
$ cd /usr/src
$ make installworld

The binaries are all installed. Merge new /etc files with old ones:

$ mergemaster

Now the machine is up to date.

As for installing packages, you have several choices. I prefer to build from source, but you can use packages. Packages are usually a little behind the ports tree. So for example, to install KDE the way I would do it:

$ cd /usr/ports/x11/kde3
$ make install

And several hours later you have KDE 3, Xorg, and a host of other apps that aren't included with the base install that KDE3 needs.

Take a look here for more info about FreeBSD's package management. The main repository of FreeBSD packages is at ftp://ftp.freebsd.org/pub/FreeBSD/packages.

Installing from CD is easy, but it's all text based so don't be shocked. I recommend installing the "X-Developer" package and the ports tree. That should include all the base system and developer tools.

Re:Considering switching.

[phoenix_rizzen]

You're probably spoiled by the package manager. Ports are neat, but apt is a dream. At the very least you'll have to get used to a different way of doing things. If you use a lot of custom repositories (e.g. rarewares) you might encounter a few headaches getting all the software you want. There are some things, like 'apt-cache search' that it's not immediately obvious how to do on ports. I think you're just supposed to string together 'find' and 'grep' commands, since ports is just a tree full of text files. # cd /usr/ports
# make quicksearch name=whatever

Re:Considering switching.

[TheRaven64]

How does one install new software on BSD? (do you compile everything from source?)
Or are there repos available? Package management on FreeBSD is done via the ports system. Each port is basically a makefile containing instructions on how to build it, a short description, and maybe some patches. If you do 'make package' you get a binary package. The ports team usually has packages available from the ftp site (and always does for the version with a release). I tend to compile everything from source because most ports have a few configuration options and I tend to pick different ones to the default. Some things (OpenOffice.org springs to mind) I wouldn't even think of compiling from source.

The first thing you install should be the portupgrade utility. This lets you install from source, from binary, or from binary if available (otherwise from source) automatically.

Re:Considering switching.

[dadragon]

The main repository of FreeBSD packages is at ftp://ftp.freebsd.org/pub/FreeBSD/packages.

I turned out to be mistaken about this. The real address is: ftp.freebsd.org/pub/FreeBSD/ports/ARCH/packages-VERSION.

For example: ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7.0-release

An important remaining question

[damn_registrars]

Is when FreeBSD and wine will start to care about each other.

Re:An important remaining question

[excelblue]

They actually do care about each other. It's just that wine gets more leverage on Linux due to a significantly higher proportion of Linux users.

I'm running FreeBSD, and the latest release of wine works just fine for most things.

Re:An important remaining question

[ruinevil]

They usually work well together, but the FreeBSD developers approached threading differently than Linux developers. This happened several years ago, when FreeBSD released version 5. So in certain circumstances WINE will have errors which you do not see in Linux. In my experience Blizzard games do not run on FreeBSD's WINE. I have read that WoW ran on FreeBSD.

Re:An important remaining question

[damn_registrars]

I'm running FreeBSD, and the latest release of wine works just fine for most things.
Then I guess we have had markedly different wine / FreeBSD experiences. I haven't found a working combination of the two since FBSD 5.4 with a version of wine that was still numbered by its release date. Since then each successive version of wine has run fewer windows applications for me.

And as for games, I have yet to find a windows game that I can run in wine on FreeBSD at all. But obviously that's not the focus of FreeBSD anyways, so I don't hold it against either. It would certainly be nice to be able to at least run some of my most needed windows applications in wine, though.

Not that I completely blame either party - they each are focusing on their core markets. The core market for wine is Linux, with BSD being gravy. Similarly, the core market for FreeBSD is file / database / web server, with workstation stuff primarily being gravy.

So I realize that I really have no right to complain that wine runs so poorly on my laptop running FreeBSD, but it still leaves me wondering if the two will ever care whole-heartedly about each other.

Re:An important remaining question

[notamisfit]

From personal experience, WoW runs on FreeBSD, but the installer won't work (or didn't on 6.2 & whatever version of wine I was using a year or so ago).

And the obligatory kudos to the FreeBSD guys for this one. I'm seriously contemplating a switch back (I'm running Ubuntu now, and am a little skittish after all the hand-wringing it took to get it to work on my laptop). There's some things I don't like about FreeBSD as far as desktop stuff goes, but the more centralized nature seems to give it more stability and transparency, and the documentation is head and shoulders above what I've seen for most Linux distributions.

Re:An important remaining question

[Anonymous Coward]

The recent versions of FreeBSD 7 and 6 do seem to grok wine much better than before. I can run Windows programs, including games, just fine on FreeBSD 7.

Re:An important remaining question

[excelblue]

Of course, there has been a few kinks here and there, but the problems eventually get resolved over time.

They do truly wholeheartedly care, but the logistics of wine development make it extremely difficult to live up to a standard that shows that. It's like tapping into a market where you have little experience in. Even if you try really hard, chances are, there will be kinks that you have to work out.

FreeBSD has shown its part with a wine port and some FreeBSD users contributing to wine. Wine has shown its part by coding itself to be as portable as possible.

Re:An important remaining question

[Klaus_1250]

And as for games, I have yet to find a windows game that I can run in wine on FreeBSD at all.

Space Rangers 2: Rise of the Dominators (installed through Stardock Central) for one. One of the most fun games I ever played.

Re:An important remaining question

[Anonymous Coward]

Why not try out PC-BSD then, since its has a FreeBSD core?

Re:An important remaining question

[notamisfit]

Hardware issues, mainly. My current laptop has a Broadcom 4311 wireless chip. Hardware support is doable in Linux with a ganked firmware, but the chip isn't usable in FreeBSD without ndis (and they call it "Project Evil" for a reason). As far as the rest, there's nothing in PC-BSD or DesktopBSD that I really want or care about. Anything I want, I can get done in regular FreeBSD.

Fir5t

[Anonymous Coward]

it a break, if [amazingkreskin.com] where it belongs, 800 w/512 Megs of Turd-suckingly transfer, Netscape Community at represents the chaanel #GNAA on create, manufacture

More good summaries of kernel development

[Steve Hamlin]

GREAT article - it is interesting for a non-programmer to read this type of technical detail, presented in an understandable way. For me, right at the edge of my theoretical-only knowledge. A detailed summary, I guess. (oxymoron)

Similar article on NetBSD: Waving the flag: NetBSD developers speak about version 4.0 (1/30/2008)

Linux focused links:

Current discussion:
LWN: Kernel
KernelTrap
KernelNewbies: Summary of Linux Changes
---
The Wonderful World of Linux series are excellent history - in-depth for outsiders:
WWOL 2.2
WWOL 2.4
WWOL 2.6
---
Towards Linux 2.6 - A look into the workings of the next new kernel(2003)
Kernel Comparison: Linux (2.6.22) versus Windows (Vista)(2007)

SCTP

[deek]

To quote from the article ...

I believe we are actually "first" to make it part of the shipping kernel. In Linux you can enable it as a module, but there are extra steps you must take. For FreeBSD its just there, like TCP.

  There's extra steps you must take? What steps are these? I haven't had experience with SCTP on any OS, but I would have thought that once the Linux module is loaded, the protocol is "just there" as well.

  Maybe he's talking about kernel defaults? It's a curious statement that he makes.

Re:SCTP

[TheRaven64]

Apparently they don't count Solaris as an operating system - it's had SCTP support since Solaris 10, and I'm fairly sure it's in OpenSolaris too.

Jealous of ZFS

[cblack]

I've been reading about zfs for awhile and recently started implementing it on some Solaris servers and really getting into it. It's nice. Really nice. I am anxiously awaiting being able to run it on linux (not via FUSE) in production. Has anyone heard anything on the objections over license compatibility and stepping beyond traditional filesystem areas of the kernel?

Re:Jealous of ZFS

[JFitzsimmons]

Won't happen due to incompatibility with the GPL.

Re:Jealous of ZFS

[Anonymous Coward]

Fucking bureaucrats. Can't someone hack something together?

The last thing I care about is whether I'm running Linux legally or not.

Re:Jealous of ZFS

[dotwaffle]

You can run it - nothing illegal about that.

So many people misunderstand the GPL...

You can do whatever the hell you like with GPLd software, you just can't distribute it as part of a non-GPL project.

ie/ Unless it's LGPL, you can't put the CDDL (ZFS) software in the same download as Linux (GPL). You can, however, download them separately and use them like that. That's what the ZFS-FUSE project is trying to do.

Re:Jealous of ZFS

[m50d]

The hacking it together is called FUSE.

Seriously, I could write the code to do it, but I couldn't distribute it legally, so there seems little point. I'll bet someone has already written it and is using it themselves.

Re:Jealous of ZFS

[Anonymous Coward]

Do not want FUSE.

Someone should write a kernel module or something and put it on the bittorrents. I want a proper implementation of ZFS.

Then we can enjoy the /. articles of Linus Torvalds talking about wanking again when everyone's violating the GPL.

Yes, there's little point. No real gain for the author - but you could put your name in the source and have everyone stroking your e-peen.

One of many benchmarks to back up the announcement

[bconway]

Dramatic improvements in performance and SMP scalability shown by various database and other benchmarks, in some cases showing peak performance improvements as high as 350% over FreeBSD 6.X under normal loads and 1500% at high loads. When compared with the best performing Linux kernel (2.6.22 or 2.6.24) performance is 15% better.

http://people.freebsd.org/~kris/scaling/bind-pt.png

Summary:

* FreeBSD 7.0-R with 4BSD scheduler has close to ideal scaling on this test.

* The drop above 6 threads is due to limitations within BIND.

* Linux 2.6.24 has about 35% lower performance than FreeBSD, which is significantly at variance with the ISC results. It also doesn't scale above 3 CPUs.

* 7.0 with ULE has a bug on this workload (actually to do with workloads involving high interrupt rates). It is fixed in 8.0.

* Changes in progress to improve UDP performance do not help much with this particular workload (only about 5%), but with more scalable applications we see 30-40% improvement. e.g. NSD (ports/dns/nsd) is a much faster and more scalable DNS server than BIND (because it is better optimized for the smaller set of features it supports).

Upgrading HOWTO?

[ewhac]

So: How do you upgrade an existing system from FreeBSD 6.0 without wiping the entire system and installing from scratch?

And before anyone asks:

• Yes, I know about the ports collection.
• Yes, I know about the binary packages.
• Yes, I know how to configure and compile the kernel.
• No, I've never really tried to compile userspace.

All the docs I've read on the subject tend to suggest that the Real Way to keep a FreeBSD system current is to download the kernel and userspace core every so often and recompile them. And that's fine, sorta, except that it doesn't address how to deal with the "leftovers", such as config files that have been moved or eliminated. (I mean, honestly, compiling the world is not a realistic way to keep current on X.org.)

Who has practical experience doing this? How do you keep your machines current, particularly with security patches?

Schwab

Re:Upgrading HOWTO?

[notamisfit]

As far as security and other within-branch updates go, I've had no problems in the past keeping the base system up to date using the steps outlined in the Handbook (cvsup, make kernel/world/etc, reboot, install, etc). Config files are usually handled with mergemaster, which isn't half-bad when it comes to keeping configurations in check. X is a third-party package, so it gets handled with the port/package tools (the jump to modular X was a pain in the dick IIRC, but it all got smoothed out). I'm not sure whether additional steps are required for 7.0, but there might be something in /usr/src/UPDATING or on the webpage.

Re:Upgrading HOWTO?

[wiz_80]

I just use freebsd-update. That does mean that custom kernels are a pain, but OTOH I have never had any problems. Well, there was the one time that it took two reboots to get the release to update for whatever reason, but that was just an annoyance.

Re:Upgrading HOWTO?

[Anonymous Coward]

Read the end of /usr/src/UPDATING. It will explain you how to upgrade and handle "config files that have been moved or eliminated" with mergemaster.
Of course, "world" is not "ports". X.org is a port (well, a lot of ports in fact). You don't *have to* update your ports if you upgrade your system.
If you upgrade with COMPAT6X in your kernel (default in GENERIC) you will be able to upgrade from 6 branch to 7.0 (kernel and world) and use the ports you installed under 6 branch, as long as you don't "make delete-old-libs" in /usr/src. The ports you will (re)install will be linked againt 7.0 libs.

Re:Upgrading HOWTO?

[drew]

(Re)Building world just keeps the base system up to date. The currently recommended procedure includes a script for updating etc, which can be somewhat daunting if you've made significant local changes to the files there, but works well overall.

If you're only worried about security patches, I generally configure cvsup to follow a specific release, e.g. RELENG_6_2, as opposed to following the -STABLE branch, e.g. RELENG_6. That gets me all of the security and errata updates for that specific release, but I don't have to worry about any significant underlying system changes catching me by surprise, and it keeps the /etc pain in check. (And if you want to jump to a later version to get certain new features, that is still an option too.)

For keeping ports/packages (including X, perl, gnome, etc.) up to date, update your /usr/ports tree, and check out the portupgrade package. Granted, my last experience with FreeBSD is a little dated at this point. Perhaps they've replaced portupgrade with something newer, but that should at least give you a starting point.

Also, as another user pointed out, you can generally update 'world' independently of your installed ports/packages, although I've never personally attempted to update my world across a major version jump.

Re:Upgrading HOWTO?

[Neil]

If you are going to do an upgrade by compiling sources, fetch the RELENG_7_0 sources via cvsup or similar, then have a look at /usr/src/UPDATING. Towards the end of the file, under the heading "COMMON ITEMS:", there are instructions on how to do upgrades along a branch or from one major version to the next.

Regarding "leftovers": the "make delete-old" and "mergemaster" steps in the upgrading recipe should take care of those.

Note that the "world" in "compiling world" is *just* the FreeBSD base system, and doesn't include ports (such as X.org). As noted in the release announcement, you *also* need to recompile all your ports (or replace them with 7.0 binary packages from the 7.0 CDs). If you are currently running FreeBSD 6.0 then I think that you also face an X.org 6.9 -> X.org 7.2 transition? It is possible to do that by recompiling from source, but I'm not sure I'd recommend it if you aren't familiar with all the various processes.

I think that I would recommend a full backup, followed by a from scratch installation of 7.0-RELEASE. If you want to do source updates from then, you could get your security fixes by tracking the RELENG_7 ("7-STABLE") or RELENG_7_0 (7.0 + essential fixes only) source trees using cvsup and rebuilding world and kernel. You can track updates and security fixes to ports tree using cvsup too, and recompile your ports with portupgrade or similar. If you practice on-going source based upgrades this way through the life of FreeBSD 7 then perhaps you'll feel more confident about tacking a source based upgrade to FreeBSD 8.0 when it comes out in a couple of years time.

Or you could just do a binary install of 7.0 and then use the new freebsd-update mechanism patch and update your system from now on. Unfortunately it seems as though one can't binary upgrade from 6.0 to 7.0 (the release notes only mention binary upgrades from 6.3 to 7).

Re:Upgrading HOWTO?

[ruinevil]

freebsd-update come out in 6.2 iirc.

Journaled filesystems?

[glwtta]

I've come to think of journaled filesystems as pretty much ubiquitous at this point, is FreeBSD really only now getting them? Or do they mean something else?

(Not trolling, I know next to nothing about *BSD)

Re:Journaled filesystems?

[Anonymous Coward]

FreeBSD has gjournal(8) to provide journalling. There are occasional problem reports with it, though.

Re:Journaled filesystems?

[Just Some Guy]

No, you read that right. The reason is mainly that FreeBSD users have been enjoying something called "softupdates" for the last decade or so, which is sort of like an in-memory journaling. Rather than writing metadata directly to disk, it's queued in memory, grouped into an efficient order, then transactionally committed to the underlying drive. The disk is never in an inconsistent state, even without a journal to fall back on. If the system crashes, a special fsck that can run while a filesystem is mounted read-write comes along and deallocates any space that's no longer used but hasn't yet been marked as empty.

Because of that, there hasn't been much need or real drive to get journaling into FreeBSD. The solution they're going with is actually nicely abstracted, in that you configure a journal for a whole device through GEOM (which is kind of like a Lego set for building drive setups). Although you'd probably never want this, you could theoretically have two "drives" that reside on remote machines (via ggate) bound together with RAID1 (via gmirror), encrypted (via geli), and with a local journal (via gjournal).

Re:Journaled filesystems?

[mindsuck]

They mean something else. FreeBSD implemented journaling at the block-device level. On top of it you can put any filesystem you want and both the metadata and data will be journaled.

UFS2+S implements soft updates which give pretty much the same benefits at the filesystem layer as journaling.

*BSD is Dying

[Anonymous Coward]

It is now official. Netcraft confirms: *BSD is dying

One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be the Amazing Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

Fact: *BSD is dying

Developer Laments: What Killed FreeBSD

[Anonymous Coward]

The End of FreeBSD

[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]

When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.

Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.

FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.

It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.

So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.

Discussion

I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.

From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.

There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.

Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.

Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?

Shouts

To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.

To the bulk of the FreeBSD committerbase and the developer community at large - ke

Current /usr/src/UPDATING

[dewarrn1]

What the parent post describes should be sufficient, but the current /usr/src/UPDATING is available online at http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING?rev=1.520;content-type=text%2Fplain; previous versions are at http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING. The mergemaster process can be a bit daunting when crossing major versions as so many files are likely to have changed, but apart from that upgrading is usually straightforward.

Do it!

[DarkEmpath]

Seriously, jump! I switched from Debian (2.something, I think) to FreeBSD 4.5 *years* ago. I haven't been happier.

I'm still running FreeBSD 6.3 on my server, and I will upgrade to 7 soon, but I found PC-BSD to be the better desktop system (DesktopBSD had strange quirks, and wasn't as polished).

PC-BSD uses the "stable" FreeBSD as it's base, so although it's currently FreeBSD 6.3 based, that'll no doubt change to 7.0 soon. PC-BSD also uses KDE as it's desktop environment, so you'll have no trouble with your apps.

Good luck! :-)

Re:Do it!

[smash]

I too switched from being a debian server person to FreeBSD back in the days when FreeBSD 4.0 was new. In fact, I still have a bunch of FreeBSD 4 servers that I installed, left the company for 2 years, came back, and they're still running fine :D

They will be upgraded/hardware replaced with 7.0 machines soon (have been waiting on 7.0 release for a few months now).

Now, why did I switch?

For me, several factors, these are the main ones...

• Clear seperation of the supported "base system" and additional apps. The base freebsd system is pretty small and self contained, and tightly integrated. Upgrading to new versions of apps via ports does not incur breakage in the base system when core libraries are upgraded - the port is simply autoconf'd to compile using the libraries you have installed - unless it *really* requires features in a specific gnu add-on library.
• The general feel and documentation on FreeBSD has so far given me the impression that although certain features may take longer to arrive on BSD, once implemented, the API does not generally change much. So, you learn how to do task X with FreeBSD 4.x for example - the same sort of configuration tasks still apply on later versions. Yes, there are changes but to a much lesser extent than say, moving from ipfwadm->ipchains->ipfilter-> etc with Linux.
• Because there's one base system for "FreeBSD" all the "FreeBSD" instructions you typically find apply. Unlike with Linux where variant x, y, and z may all have slight idiosyncracies specific to their particular filesystem layout, etc.
• Error messages, logs, etc were (back in the day) a lot more orderly and professional/polished. A minor niggle, and Linux has improved lots in the past 5 years, but it was yet another "hmm neat, its easy to read my syslog" type nicety.

Plus, at the time, I'd been building Linux machines for 5 years and wanted to check out BSD. As it was, I preferred it and haven't really gone back. I'll still install Linux occasionally and as far as desktop use goes, there's easier support for more apps, but if it's a machine that I'll have to maintain as a server, long term - FreeBSD all the way thanks.

Does it work with MySQL yet?

[Local Loop]

I had to abandon FreeBSD a few years ago with performance
with MySQL got so abysmal -- apparently the MySQL folks
and the FreeBSD folks got into pissing match about
threads.

Anyone know how this turned out?

Re:Does it work with MySQL yet?

[Anonymous Coward]

I don't know the results of the "pissing match", but I can attest to the re-written ULE scheduler (NOT the same ULE that was in 5.x and 6.x! This scheduler is referred to as ULE/SMP2.0) being both stable and greatly improved. The scheduler was tested *specifically* against MySQL, and the benchmarks exceed that of Linux. Here's the details you want:

http://people.freebsd.org/~kris/scaling/mysql.html

Re:Does it work with MySQL yet?

[Anonymous Coward]

Anyone know how this turned out?

One moves to PostgreSQL.

BTW, do you pay your MySQL licensing fees?

Re:Does it work with MySQL yet?

[urbanriot]

Yes, the performance is excellent now... it was fine since that 'pissing match', however you had to go through a few hoops to get it that way.

Here's a few links that might help you with performance in newer incarnations of FreeBSD:
FreeBSD 6 - http://wiki.freebsd.org/MySQL
FreeBSD 7 - http://people.freebsd.org/~kris/scaling/mysql.html

Re:Does it work with MySQL yet?

[Local Loop]

THANK YOU!

those links were very helpful. I have a chance this weekend
to benchmark it myself while our main server is swapped out,
and maybe switch back to FreeBSD for the database servers.

Thanks to the AC above, too.

Re:One of many benchmarks to back up the announcem

[Kent Recal]

bind?
ugh. is that piece of crap *still* not dead?
i thought everybody and their dog had switched to tinydns & co by now...

Just finished installing RC2

[hmallett]

You sometimes wonder whether those people who post "I've only just finished installing 7.0 RC2" are posting for comedic effect.

However, as I installed RC2 last night, what I want to know is how did they know I'd just installed it, and to release 7.0-STABLE?

Performance is astounding compared to Linux

[Anonymous Coward]

I have compared FreeBSD 7.0-STABLE with similar config Linux-based desktop (kernel 2.6.11), the FreeBSD is very obviously faster than Linux. I'm not sure with the latest Linux kernel. Please update if you compare with latest Linux kernel.

Mods on crack (again)

[morgan_greywolf]

Hey mods: "Redundant", "Offtopic", or "Overrated" do not mean "-1, I don't agree with you." If you disagree with me, then POST and SAY SO. More importantly, state your reasons why. This is how ADULTS converse. Don't mod me down because it helps you deal with your miserable little existance in your mom's basement and your anger issues towards everyone who disagrees with you.

I'm more interested in posts that DISAGREE with me than I am in posts that agree with me. Sometimes a different viewpoint will offer fresh insights.

Re:Mods on crack (again)

[Just Some Guy]

Yeah, that sucked. I was trying to answer you directly; I'm not sure why others felt the need to silence you. Sorry about how that turned out.

FreeBSD wants you... to make a new installer

[ruinevil]

http://en.wikipedia.org/wiki/Sysinstall

As usual...

[petrus4]

...the first 5-10 comments on any BSD related post always consist of trolls, FUD, and other rubbish.

Fuck you, Linux "community."

Re:As usual...

[Anonymous Coward]

...the first 5-10 comments on any BSD related post always consist of trolls, FUD, and other rubbish.

Fuck you, Linux "community." the first 5-10 posts are always crap for *any* article ... and quite a lot of times the whole discussion is so ... u must be new here :)

You can update existing systems

[Anonymous Coward]

By using the following command:

# portupgrade -faP

HAHAHA, FAP. Oh man, right now I'm laughing so hard and I think I'm getting a boner.

What *I* found in Freebsd 7.0

[esbee]

My feedback as an user of "current" Linux distros.

- I found the same sysinstall that I saw 4+years ago when I last tried installing Freebsd.
- I found that the official way to configure is to generate the config file template using 'Xorg -configure' and then hand editing the xorg.conf config file!!!!
- I found that the standard install still installs TWM and doesn't even ask for KDE/GNOME (I know you need to install the packages *after* the install, and yes I know I can use sysinstall) and you are dropped to a text login after install.
- I found that my amd64 cpu with the nvidia integrated card doesn't have an nvidia driver. And the default nv driver can't make use out of DDC to configure my brand new widescreen LCD monitor.
- I found that my mouse pointer is invisible in X.

Now, before other start, please understand why I am saying this - I know Freebsd has a different approach to building a distro. I also know that reasons like prop. drivers are not its fault. I also accept that I probably am facing some system specific issue inherent in any .0 release of distros.

My point here is simply to let how a typical user who thought of migrating to Freebsd thinks. I for one, value using my relatively new hardware to the fullest, so I am going back to Ubuntu.

I still have tremendous regards for Freebsd as a server. I have found them to be much more stable than any current Linux distro, and capable of much more punishment too.

Re:What *I* found in Freebsd 7.0

[ruinevil]

FreeBSD devs want to get something better than sysinstall too, but it would need to include all the same feature and be able to read the same commands thconfig at some users use in scripts. Also, most FreeBSD users will tell you to install minimal, and then pkg_add -r kde/gnome, which will get dependencies that include Xorg. I dunno about your cursor problem sorry.
 
If you want something like Ubuntu/Suse/Fedora, there is DesktopBSD, which is FreeBSD with a pretty GUI. It is totally compatible with FreeBSD. However, I have never gotten the DesktopBSD CD to boot on my laptop. The livecd/bootcd is not as compatible as the FreeBSD boot cd. PC-BSD is a slightly different animal due to its PBI package management.

Re:What *I* found in Freebsd 7.0

[socz]

oh, ubuntu? hmmm for a minute there i thought you were a windows user :P~

Having learned pretty much bsd by myself, i never had a problem installing nor getting x86 up and going. Even adding different WM was always easy. Back in the day you HAD to specify either through editing or using a crappy conf generator that never quite had the options i needed. Since then it's pretty much all automatic. It helps i don't have all that crappy "built in hardware" since that's what gives the most problems. But i really don't understand why everyone complains to be honest. If you want ez go windows. If you want to be trendy go ubuntu. If you want to be bad ass go bsd :P

But then again i guess i'm biased! I don't quite remember when i last installed fbsd. I know it's a 6.x stable. But i'm pretty sure i was able to set kde as my default wm before install was finished as i booted to it after a console login. suse is alright i guess because it looks like windows. But why do i want to boot to windows every time? Console suits me just fine and is a good power saver on my POS vaio note book.

I've actually always found linux hard to use. Slackware wasn't so user friendly to me and mandrake was horrible, but easy to install. red hat and debian were pretty bad ass, but then debian died??? what happened there. I gave up and ended up runnning suse on my laptop as a test linux os. I do like tux racer though, it's pretty fun!

Re:What *I* found in Freebsd 7.0

[Anonymous Coward]

Assuming you haven't already purged and gone back to Ubuntu, try using Option "HWCursor" "off" in your xorg.conf and see if that fixes the invisible mouse cursor problem.

Sysinstall is pretty primitive compared to modern Linux installers but I've used it often enough in the past that I can have it installing in under 30 seconds so that isn't a huge problem for me. The real showstopper for me from using FreeBSD though is the broken nxserver/freenx port. Unfortunately, I can't see any activity on it since September 2007. :(

Re:What *I* found in Freebsd 7.0

[Billly Gates]

I was just going to ask if FreeBSD 7 improved since FBSD 4.12 in terms of ease of use.

Ubuntu spoiled me and I now have everything wifi since those days. I wondered if sysinstall was still being used and if wifi would work out of the box. I think the obvious answer is no. Its silly to configure X that way and running moused just to run the mouse on it is silly as well.

I am glad performance is finally better. FBSD 5.x and 6.x were bad and I decided not to run it anymore.

Re:What *I* found in Freebsd 7.0

[Brandybuck]

- I found the same sysinstall that I saw 4+years ago when I last tried installing Freebsd.

What's the problem, does sysinstall not work for you? I've never had a problem with it. If you fear the sight of plain text, then FreeBSD will not be for you. While FreeBSD makes a damned awesome desktop system, that is not its goal. It is not designed for Aunt Tillie.

- I found that the official way to configure is to generate the config file template using 'Xorg -configure' and then hand editing the xorg.conf config file!!!!

That is because that's how X.org comes. Talk to the X.org developers about a better configuration tool. It's not FreeBSD's job to fix their shortcomings. I agree with you that this is a pain, but from FreeBSD's perspective, X.org is just another third party software project.

- I found that the standard install still installs TWM and doesn't even ask for KDE/GNOME (I know you need to install the packages *after* the install, and yes I know I can use sysinstall) and you are dropped to a text login after install.

You DO have an option to install KDE/GNOME during installation, if you continue on to the post-install configuration page of sysinstall.

p.s. It's about this time in your complaint list when most people start telling you about PC-BSD...

- I found that my amd64 cpu with the nvidia integrated card doesn't have an nvidia driver. And the default nv driver can't make use out of DDC to configure my brand new widescreen LCD monitor.

Talk to NVidia. They're the ones who insist on a proprietary binary blob and top secret chip specs. I can't run FreeBSD on my laptop because of an ATI driver with no (workable) Open Source driver available(*). If we ever get together, we can have a beer and curse the bastard proprietary video card manufacturers.

- I found that my mouse pointer is invisible in X.

Got no clue. Never seen that one before. Even when I had an NVidia card (curse them!), I still had a mouse pointer. I bet there's some weird ass hardware mouse option in your xorg.conf file.

(*) Actually, I can use the VESA driver, and it's damned fast and snappy. But it without multi-head support, it is a major pain doing presentations on the laptop.

mod down, "i don't agree with that"

[gr8scot]

:D