The migration to Xorg was no debacle but the usual hiccup you will see in any operating system after changes as big as Xorg.

7.0 is a stable release with big changes like the new scheduler (disabled by default) etc. pp. I'm using FBSD 7 stable and I have nothing to complain, but you should test it first. In the end it depends on your needs.

In 7.1, I believe the newer scheduler will be defaulted on in i386/amd64; I've been using it as shipped in 7.0-release and as it currently is in 7-stable, without any problems, and don't think there will be any major hicups in 7.1R from it. The FreeBSD has been rock solid stable on my machine, since the days of 6.0-Release, but as always YMMV.

I moved away from FreeBSD after the major debacle with a new xorg and I'm thinking about setting up a new system. Still trying to decide between Free and Net.

Thanks.

Well it is kind a funny that you are deliberating between FreeBSD and NetBSD bearing in mind your experience with FreeBSD transition from
XOrg 6.9 to XOrg 7.0 modular. What do you expect will happen with NetBSD 5.0 when they move from XFree86 to XOrg 7.4 modular? You choice should be clear FreeBSD.

I wonder why didn't you consider OpenBSD? If you are as conservative user as you claim OpenBSD would be the perfect choice. I might be little bit bias since I used it but based on my heuristic experience OpenBSD is the most stable of all BSDs following closely by NetBSD. FreeBSD is by far the list stable of big three.

On the another hand real question you should be asking yourself is what will be the primary use for your system and what kind a hardware you will be dealing with.

Unlike many major Linux distros and Windows alike which claim that
are all-in-one solutions for all human computing needs each of four
BSD flavors has its own notch as you know.

FreeBSD is ultra optimized for multiprocessors i386 or amd64 machines (almost no support for anything else) and great solution for large data bases. Bleeding edge software.

DragonFly with kernel support for clustering.

NetBSD portability on old crappy hardware (very little support for
non i386 and amd64 on modern hardware), best virtualization in BSD world and fantastic solution for embedded devices.

OpenBSD most secure of all, most conservative and in practical terms most portable (sparc64 outstanding) great for embedded devices and
small servers.

Speaking of BSD on the desktop it is what you make out of them. I have used all of the above as my primary desktop OS. If you just want things
to work on the desktop probably should try PCBSD to see if it works for you. It is probably couple years behind Linux in usability but might work for you. On another hand you can just get a Mac if you want BSD on the desktop and you will be light years ahead of Linux users.

In 7.1, I believe the newer scheduler will be defaulted on in i386/amd64; I've been using it as shipped in 7.0-release and as it currently is in 7-stable, without any problems, and don't think there will be any major hicups in 7.1R from it. The FreeBSD has been rock solid stable on my machine, since the days of 6.0-Release, but as always YMMV.

Personally, I'd wait for 7.1 unless time is of the essence.

FBSD 5 was stable too, maybe not the fastest but it was in a transition to lay the foundation for 6.x, 7.x and 8.x. You have to think big in FreeBSD development.

I was hoping (but not holding my breath) that I would wake up this morning and read that 7.1-Release was out since it is so close. I deleted my 7.0 iso's to make room for 7.1 for a fresh install on this hd.

Side note: still have my 4.x cd pack, along with 3.x and 2.2.1-Release cd's

In 7.1, I believe the newer scheduler will be defaulted on in i386/amd64; I've been using it as shipped in 7.0-release and as it currently is in 7-stable, without any problems, and don't think there will be any major hicups in 7.1R from it. The FreeBSD has been rock solid stable on my machine, since the days of 6.0-Release, but as always YMMV.

Personally, I'd wait for 7.1 unless time is of the essence.

Hi Terry, are you running i386 or AMD64?

I have a nice Core 2 DUO box with 4G of RAM waiting for a nice 64 bit OS. I am reading some mixed reviews on the stability of the AMD64 version.

Well it is kind a funny that you are deliberating between FreeBSD and NetBSD bearing in mind your experience with FreeBSD transition from
XOrg 6.9 to XOrg 7.0 modular. What do you expect will happen with NetBSD 5.0 when they move from XFree86 to XOrg 7.4 modular? You choice should be clear FreeBSD.

I don't have any issue with an OS going to a big change in XOrg etc. What I did object to was the *way* they did it. All of a sudden the ports tree required a whole new XOrg. That is not smart and it broke a lot of stuff. It should have been handled as a major version and not just thrown in in the middle of a release.

Right now the most important criteria for me in choosing an OS are stability, AMD64 support/exploitation, and how simple it is to run winbloze in a VM.

Quote:

Originally Posted by Oko

I wonder why didn't you consider OpenBSD? If you are as conservative user as you claim OpenBSD would be the perfect choice. I might be little bit bias since I used it but based on my heuristic experience OpenBSD is the most stable of all BSDs following closely by NetBSD. FreeBSD is by far the list stable of big three.

I like OpenBSD very much especially for the cleanliness and simplicity. But not having an easy way to run winbloze in a VM may be a show stopper if I can't get enough performance out of bloze under K/Qemu.

Quote:

Originally Posted by Oko

On the another hand real question you should be asking yourself is what will be the primary use for your system and what kind a hardware you will be dealing with.

I know all that already

Quote:

Originally Posted by Oko

DragonFly with kernel support for clustering.

Bummer, I just burned a CD of 2.0 and as usual it doesn't come up on any of my machines. 1.8.0 was fine but 1.6 was also a problem. I will have to wait until the dragon fly guys get more hardware support going.

Quote:

Originally Posted by Oko

NetBSD portability on old crappy hardware (very little support for non i386 and amd64 on modern hardware), best virtualization in BSD world and fantastic solution for embedded devices.

I read the NetBSD doc on Xen and it was confusing. I get the feeling it's a work in progress and not very refined. Unless I'm wrong, I'm not sure if it's worth pursuing until they get a turnkey virtualization setup going. I don't want to be a NetBSD developer, I just need a stable, high-performance platform and virtual host. I love pkgsrc though, and would like to run a NetBSD box. Unfortunately, the latest AMD64 port only boots on one of my boxes. I will have to do some juggling to get this going if I choose it.

I don't have any issue with an OS going to a big change in XOrg etc. What I did object to was the *way* they did it. All of a sudden the ports tree required a whole new XOrg. That is not smart and it broke a lot of stuff. It should have been handled as a major version and not just thrown in in the middle of a release.

FreeBSD doesn't have a branched ports tree. There is only the one ports tree, that works on all versions of FreeBSD. As such, there is no concept of "major release" or "mid-release" or anything like that. There's just "the ports tree".

FreeBSD doesn't have a branched ports tree. There is only the one ports tree, that works on all versions of FreeBSD. As such, there is no concept of "major release" or "mid-release" or anything like that. There's just "the ports tree".

That's fine, there should still be an option to use the old Xorg or new, in the middle of a release. That kind of a major change needs a new version (they should have waited for version 7) and the users should be shielded from that magnitude of changes until they opt for the new version.

There's no excuse for tearing my system up when I try to build one new package.

It was a sloppy, ill-conceived way to operate, and there's no excuse for it.

That's fine, there should still be an option to use the old Xorg or new, in the middle of a release. That kind of a major change needs a new version (they should have waited for version 7) and the users should be shielded from that magnitude of changes until they opt for the new version.

There's no excuse for tearing my system up when I try to build one new package.

At the time, one could set a make.conf variable that chose which X server to use. As such, it was a simple 1 line "fix" to keep XFree86 as the default X server that everything would depend on.

Not sure how much simpler they could have made it.

New installs g[o|e]t Xorg, existing XFree86 installs could continue to use XFree86, and those that wanted to upgrade from XFree86 to Xorg could do so.

I remember a lot of traffic on the ports@ mailing list around that time with the procedures to use, and I thought there was an entry in /usr/ports/UPDATING, but now I can't find it.

The big thing that caught people was the simultaneous transition from X11BASE=/usr/X11 to X11BASE=$LOCALBASE (/usr/local), which required a re-install of all X-related ports, or a symlink setup. And I believe it's on FreeBSD 6.x that you have to add a line to /etc/make.conf since the ports tree when running on 6.x can't redefine X11BASE on it's own.

So, all that being said, I'm not really sure how they could have made it any easier.

Just when I finished installing NetBSD-4.0.1, FreeBSD-7.0-RELEASE, and OpenBSD-4.4 they bring out FreeBSD 7.1!

OpenBSD is going well, as usual. NetBSD locked up too many times, and FreeBSD 7.1 didn't recognize my monitor. If I can OpenBSD to run a winbloze guest I've found my OS for this box. I have another drive, I guess it's time to download 7.1 and try again

Just when I finished installing NetBSD-4.0.1, FreeBSD-7.0-RELEASE, and OpenBSD-4.4 they bring out FreeBSD 7.1!

OpenBSD is going well, as usual. NetBSD locked up too many times, and FreeBSD 7.1 didn't recognize my monitor. If I can OpenBSD to run a winbloze guest I've found my OS for this box. I have another drive, I guess it's time to download 7.1 and try again

You can try Qemu but YMMV. Qemu is up to date on OpenBSD but it is slowwwww and definitely didn't work for me. Good luck.