fwiw, FreeBSD 5.x was the "learning experience" where SMP was completely rewritten. No one mourned when we retired that branch.
6.x was far more stable than 5.x, and 7.0 built on that by adding more scalability. (7.0 was much better than any.0 release of anything I've ever seen). 8.0, which was just announced, contains even more scability work in the network stack and USB.
So, FreeBSD has come a long way since the 5.x times.
> You have a 0% chance of finding a bug in the compiler in anything you're coding.
Nonsense.
Across the 4 architectures and 3 OS branches that FreeBSD currently supports, there are a total of 29 ports that cause GCC internal compiler errors. (In fairness, this is out of total of 17661 ports.) 29 is much greater than zero.
URL on request. (I would rather not subject the Ports Monitoring server to an immense load).
> It's a massively unprofessional attitude of you, you are cutting off your project's nose to spite your users' faces, and it gives me cause to doubt whether the "skills" you claim would really be such a great loss to the open source movement
It's really amazing what people think it's fair to say to someone that they disagree with. I'd be interested to hear what software the poster of this rant has written.
To me, it sounds like the author is a fan of Open Source, not Free Software. The distinction, at least to me, has never been clearer.
Re:Linux with zfs would be an instant hit.
on
GCC 4.2.1 Released
·
· Score: 0
While you're waiting for that to happen, you can get FreeBSD-current (which will, before the end of the year, become release 7.0), and get ZFS now.
but ZFS on FreeBSD isn't. (It was imported to the FreeBSD kernel on Fri Apr 6 2007 by pjd).
We are currently working on tuning and memory usage issues so that it will be as solid as possible for the 7.0 release this fall. It is already being used by some users, who are reporting good results.
It wasn't even mentioned in the Slashdot "bsd" section. Someone will have to tell me why.
IMHO the benevolent dictator is not a necessary requirement. The real requirement is that some kind of process (e.g. peer review) can result in a ruling of "no, we aren't going to include that" (for reasons such as architectural integrity, clarity, and/or not violating the "Principle Of Least Astonishment" or POLA as FreeBSD terms it.)
I would agree that there does need to be some kind of "the buck stops here" decision-making process; I merely think that it doesn't necessarily have to be one or two people.
mcl
msmith's last commit was 20020504. This posting probably predates that.
Since his last commit, FreeBSD has released, in order: 4.6, 4.7, 5.0, 4.8, 5.1, 4.9, 5.2, 4.10, 5.3, 4.11, 5.4, 6.0, 6.1, and 5.5. That's 14 releases from 3 different release branches.
The current codebase bears only a vague resemblance to what was in 4.6. After 4.6, 4.X was made far more stable; then 5.X incorporated major new features including rewritten SMP support and added support for laptops and wifi; and now 6.X is consolidating those changes and concentrating on performance and bugfixing as well as adding features.
We probably have far more developers now than we ever have had in the past. People have come and go but development has continued, if not accelerated.
Four years is an eternity in Open Source. Our troll needs to get over it.
The i386, amd64, and sparc64 ports are the ones in the best shape (in that order). The alpha port is showing its age due to a lack of enough people hacking on it.
The ia64 port is next, then the powerpc and arm ports. None of the three of those is completely suited for widespread use yet.
fwiw, "terminated support on the 386" means the 80386 chips themselves. You can still build a custom kernel for them if you must, but the support was simply in the way for modern systems.
The easy answer: the FreeBSD developers learned from the mistakes made in the 5.X timeframe. Further major releases will be far more regular (at approximately 18 month intervals) and have less sweeping new features.
Holding off declaring a 5-STABLE until every possible fix was made to SMP and the resulting synchronization rework was finished was clearly too ambitious. This mistake won't be repeated in the future. (Granted that such a thorough rework probably won't ever happen again). There will be more frequest releases of -STABLE branches with smaller feature sets.
As for 6.0 vs. 5.4 or the scheduled 5.5, there is a great deal of work in 6.0 (such as rework of the wireless APIs) that would not have been suitable for backmerging into 5.X. The goal of each FreeBSD major release, once declared -STABLE, is not to touch the APIs again during the life of that branch. 5.5 will mainly incorporate bugfixes to 5.4.
Hmm, perhaps you're right. I know that the default settings were ripped out some time back. I don't have time to check at the moment.
In any case, it's correct to say that 6.0 is not suitable for 80386 machines for any number of reasons. Even with the kernel stuff in place you'd still most likely be unable to run the system installer due to the memory limitations of those old machines.
FreeBSD's primary emphasis is to run well on modern hardware. For older systems with limited CPU cycles and/or memory, NetBSD is probably a better choice. This doesn't make one or the other better or worse -- that's one of NetBSD's goals, that's all.
The FreeBSD developers learned a lot from the mistakes made early in the 5.X line. The only thing you can probably get them in unanimous agreement about is that "we'll never do it that way again".
6.0 -- and all *.0 releases in the future -- will be a much smaller jump than 4.X to 5.0; probably even smaller than the jump from 5.2.1 to 5.3, which had a huge number of new features itself. We learned that the previous jumps were far too disruptive.
Now, granted that 5.0 _did_ introduce a rewritten SMP, changes to the way kernel sychronization was done, the latest gcc (which penalized more uses of sloppy code), and many other things, some disruption was going to be inevitable. But, going forward, there will be more frequent releases with a smaller feature set in each release.
So far the mailing lists seem to support that the 5.4->6.0 upgrade path is relatively painless. OTOH a reinstall and then bringing your files over may be a safer path.
ULE is not enabled by default. For certain workloads it does better than the 4BSD scheduler, for others it is worse. More testing and characterization needs to go into it before the switch.
The _default_ support for 80386 processors has been removed. Having it on by default was a pessimization of every other later processor in that family -- which is probably 95+% of the install base.
You can still cross-build it if you wish; some of the embedded systems manufacturers that base off of FreeBSD do so. But these days even finding an embedded processor based on that old a core is becoming very hard to do.
In any case with an 80386 you'll probably have far more trouble coming up against the memory limits than you will with performance.
Please don't try upgrading your ports with a 4.4 system without upgrading to 4.10 or 4.11 first. I severely doubt anything that old will work with the current ports framework; if it fails, you'll be completely on your own.
It's been several years and time has moved on and we can't support every possible combination.
> Ports and Portage will leave "package cruft" on your system. "Package cruft" can be anything from stale config files to build-time dependecy packages.
As for the former, a major QA effort has been going on this year in Ports to automatically identify non-conforming ports and flag them to be fixed. If they can't be fixed, they are marked "broken" and the maintainers are notified. We have so far fixed dozens; a few remain.
This is one of the advantages of our automated ports building cluster, which is capable of detecting many different types of errors on each combination of port, OS release, and machine architecture.
As for the latter, an application called pkg_cutleaves(1) can be used to identify unused (leaf) packages, e.g. those left behind as build dependencies.
The point is that there is a lot more functionality in our various ports toolkits than is commonly supposed, even though the various tools need to be more clearly documented in one single place.
This posting is now slightly over 2 years old. Yes, Michael Smith left; no, the project didn't die. Other people have come and gone since. The politics flare up, and then they die down again. In general, only when the politics flare up does anyone mention it here -- much like newspapers generally do not report that "things seem to be working well".
Two years in an open-source project is a very long time -- unless, like AC, you've got a very particular axe to grind, in which case it seems but like an instant.
In the meantime, the vast majority of the FreeBSD committers just work on the codebase and documentation, and ignore the politics. There are dozens who have probably never heard of Michael Smith and whatever crisis caused him to depart -- because they've all arrived in the past two years.
Please cite a case where SCO has sued either a FreeBSD user, or the FreeBSD Foundation itself. I have seen no such mention anywhere. There has been some FUD from SCO but no legal action.
It is likely that SCO is enjoined from taking any such action as a result of the BSDI/AT&T settlement.
Unless you cite some kind of source for your "information", it's just going to be clear that you are intentionally spreading lies.
Re:My personal experience in the FreeBSD world
on
FreeBSD 5.2 Released
·
· Score: 0
Hey, Harv, how's it goin' today? Not so good, huh? So upset by a new FreeBSD release that you had to repost this by-now-serveral-years-old email *twelve* times?
Harv, I really wish we could get you a better hobby. I mean, it's got to take a lot of time to post these things over and over again. Wouldn't that time be better spent on something else? Anything else?
Because the more you post this stuff, the more you begin to stand out as being just one single individual with this extreme opinion. Frankly, stating something repeatedly doesn't make it any more or less true, and doesn't even mean any more people will listen to it. Labeling your opinions as "facts" doesn't help your case very much either. IIRC the last time I challenged some of your "facts" with actual metrics about e.g. the broken port count, you not only failed to respond with any kind of counter-argument, you just merely called me an epithet. This doesn't support your case either. Why should people pay any attention to your postings if you're just a broken record, and unwilling to even consider any information that runs contrary to your own apparently fixed opinions?
But I feel like I'm just wasting my time here. I think I'll go back to fixing actual problems in actual software, rather than trying to change the direction that the wind blows.
Now Harv, you know that's because most people have better sense than to reply to your incessant trolling, reposting the same N postings over and over and over again. There's just not much point trying to discuss anything BSDish on Slashdot, because of that.
But I guess it's really safe for you to do this, for whatever bitter reasons you have, as long as you can be Anonymous Coward. Never was the default username more appropriate than in your posts...
Of course, you could prove me wrong by telling us all who you are, and how it was exactly that you came to be kicked out of the project -- or am I assuming too much, here? Am I wrong to also assume you're the person who subscribes FreeBSD mailing lists to other mailing lists to waste people's time? And files false Problem Report after false Problem Report to help gum up the works?
So, Harv, tell us who you are, and what exactly it is that you've done to *create* something --anywhere -- rather than just posting venom, and prove me wrong here. I'll be man enough to admit it.
Slashdot Mirror
fwiw, FreeBSD 5.x was the "learning experience" where SMP was completely rewritten. No one mourned when we retired that branch. 6.x was far more stable than 5.x, and 7.0 built on that by adding more scalability. (7.0 was much better than any .0 release of anything I've ever seen). 8.0, which was just announced, contains even more scability work in the network stack and USB.
So, FreeBSD has come a long way since the 5.x times.
The fall of the Soviet Union proves you wrong.
I'm talking purely errors that are found in building the ports -- e.g. applications found on the Internet, written by random people.
> You have a 0% chance of finding a bug in the compiler in anything you're coding.
Nonsense.
Across the 4 architectures and 3 OS branches that FreeBSD currently supports, there are a total of 29 ports that cause GCC internal compiler errors. (In fairness, this is out of total of 17661 ports.) 29 is much greater than zero.
URL on request. (I would rather not subject the Ports Monitoring server to an immense load).
Mark Linimon
linimon@FreeBSD.org
> It's a massively unprofessional attitude of you, you are cutting off your project's nose to spite your users' faces, and it gives me cause to doubt whether the "skills" you claim would really be such a great loss to the open source movement It's really amazing what people think it's fair to say to someone that they disagree with. I'd be interested to hear what software the poster of this rant has written. To me, it sounds like the author is a fan of Open Source, not Free Software. The distinction, at least to me, has never been clearer.
While you're waiting for that to happen, you can get FreeBSD-current (which will, before the end of the year, become release 7.0), and get ZFS now.
but ZFS on FreeBSD isn't. (It was imported to the FreeBSD kernel on Fri Apr 6 2007 by pjd).
We are currently working on tuning and memory usage issues so that it will be as solid as possible for the 7.0 release this fall. It is already being used by some users, who are reporting good results.
It wasn't even mentioned in the Slashdot "bsd" section. Someone will have to tell me why.
mcl
IMHO the benevolent dictator is not a necessary requirement. The real requirement is that some kind of process (e.g. peer review) can result in a ruling of "no, we aren't going to include that" (for reasons such as architectural integrity, clarity, and/or not violating the "Principle Of Least Astonishment" or POLA as FreeBSD terms it.) I would agree that there does need to be some kind of "the buck stops here" decision-making process; I merely think that it doesn't necessarily have to be one or two people. mcl
msmith's last commit was 20020504. This posting probably predates that.
Since his last commit, FreeBSD has released, in order: 4.6, 4.7, 5.0, 4.8, 5.1, 4.9, 5.2, 4.10, 5.3, 4.11, 5.4, 6.0, 6.1, and 5.5. That's 14 releases from 3 different release branches.
The current codebase bears only a vague resemblance to what was in 4.6. After 4.6, 4.X was made far more stable; then 5.X incorporated major new features including rewritten SMP support and added support for laptops and wifi; and now 6.X is consolidating those changes and concentrating on performance and bugfixing as well as adding features.
We probably have far more developers now than we ever have had in the past. People have come and go but development has continued, if not accelerated.
Four years is an eternity in Open Source. Our troll needs to get over it.
The i386, amd64, and sparc64 ports are the ones in the best shape (in that order). The alpha port is showing its age due to a lack of enough people hacking on it.
The ia64 port is next, then the powerpc and arm ports. None of the three of those is completely suited for widespread use yet.
fwiw, "terminated support on the 386" means the 80386 chips themselves. You can still build a custom kernel for them if you must, but the support was simply in the way for modern systems.
The easy answer: the FreeBSD developers learned from the mistakes made in the 5.X timeframe. Further major releases will be far more regular (at approximately 18 month intervals) and have less sweeping new features.
Holding off declaring a 5-STABLE until every possible fix was made to SMP and the resulting synchronization rework was finished was clearly too ambitious. This mistake won't be repeated in the future. (Granted that such a thorough rework probably won't ever happen again). There will be more frequest releases of -STABLE branches with smaller feature sets.
As for 6.0 vs. 5.4 or the scheduled 5.5, there is a great deal of work in 6.0 (such as rework of the wireless APIs) that would not have been suitable for backmerging into 5.X. The goal of each FreeBSD major release, once declared -STABLE, is not to touch the APIs again during the life of that branch. 5.5 will mainly incorporate bugfixes to 5.4.
Hmm, perhaps you're right. I know that the default settings were ripped out some time back. I don't have time to check at the moment.
In any case, it's correct to say that 6.0 is not suitable for 80386 machines for any number of reasons. Even with the kernel stuff in place you'd still most likely be unable to run the system installer due to the memory limitations of those old machines. FreeBSD's primary emphasis is to run well on modern hardware. For older systems with limited CPU cycles and/or memory, NetBSD is probably a better choice. This doesn't make one or the other better or worse -- that's one of NetBSD's goals, that's all.
The FreeBSD developers learned a lot from the mistakes made early in the 5.X line. The only thing you can probably get them in unanimous agreement about is that "we'll never do it that way again".
6.0 -- and all *.0 releases in the future -- will be a much smaller jump than 4.X to 5.0; probably even smaller than the jump from 5.2.1 to 5.3, which had a huge number of new features itself. We learned that the previous jumps were far too disruptive.
Now, granted that 5.0 _did_ introduce a rewritten SMP, changes to the way kernel sychronization was done, the latest gcc (which penalized more uses of sloppy code), and many other things, some disruption was going to be inevitable. But, going forward, there will be more frequent releases with a smaller feature set in each release.
So far the mailing lists seem to support that the 5.4->6.0 upgrade path is relatively painless. OTOH a reinstall and then bringing your files over may be a safer path.
ULE is not enabled by default. For certain workloads it does better than the 4BSD scheduler, for others it is worse. More testing and characterization needs to go into it before the switch.
6.0 has the old installer. The new installer is not yet finished and fully integrated even on the -CURRENT branch.
The _default_ support for 80386 processors has been removed. Having it on by default was a pessimization of every other later processor in that family -- which is probably 95+% of the install base. You can still cross-build it if you wish; some of the embedded systems manufacturers that base off of FreeBSD do so. But these days even finding an embedded processor based on that old a core is becoming very hard to do. In any case with an 80386 you'll probably have far more trouble coming up against the memory limits than you will with performance.
Please don't try upgrading your ports with a 4.4 system without upgrading to 4.10 or 4.11 first. I severely doubt anything that old will work with the current ports framework; if it fails, you'll be completely on your own. It's been several years and time has moved on and we can't support every possible combination.
> Ports and Portage will leave "package cruft" on your system. "Package cruft" can be anything from stale config files to build-time dependecy packages.
As for the former, a major QA effort has been going on this year in Ports to automatically identify non-conforming ports and flag them to be fixed. If they can't be fixed, they are marked "broken" and the maintainers are notified. We have so far fixed dozens; a few remain.
This is one of the advantages of our automated ports building cluster, which is capable of detecting many different types of errors on each combination of port, OS release, and machine architecture.
As for the latter, an application called pkg_cutleaves(1) can be used to identify unused (leaf) packages, e.g. those left behind as build dependencies.
The point is that there is a lot more functionality in our various ports toolkits than is commonly supposed, even though the various tools need to be more clearly documented in one single place.
This posting is now slightly over 2 years old. Yes, Michael Smith left; no, the project didn't die. Other people have come and gone since. The politics flare up, and then they die down again. In general, only when the politics flare up does anyone mention it here -- much like newspapers generally do not report that "things seem to be working well".
Two years in an open-source project is a very long time -- unless, like AC, you've got a very particular axe to grind, in which case it seems but like an instant.
In the meantime, the vast majority of the FreeBSD committers just work on the codebase and documentation, and ignore the politics. There are dozens who have probably never heard of Michael Smith and whatever crisis caused him to depart -- because they've all arrived in the past two years.
Summary: this is very old news indeed.
Please cite a case where SCO has sued either a FreeBSD user, or the FreeBSD Foundation itself. I have seen no such mention anywhere. There has been some FUD from SCO but no legal action.
It is likely that SCO is enjoined from taking any such action as a result of the BSDI/AT&T settlement. Unless you cite some kind of source for your "information", it's just going to be clear that you are intentionally spreading lies.
Hey, Harv, how's it goin' today? Not so good, huh? So upset by a new FreeBSD release that you had to repost this by-now-serveral-years-old email *twelve* times?
Harv, I really wish we could get you a better hobby. I mean, it's got to take a lot of time to post these things over and over again. Wouldn't that time be better spent on something else? Anything else?
Because the more you post this stuff, the more you begin to stand out as being just one single individual with this extreme opinion. Frankly, stating something repeatedly doesn't make it any more or less true, and doesn't even mean any more people will listen to it. Labeling your opinions as "facts" doesn't help your case very much either. IIRC the last time I challenged some of your "facts" with actual metrics about e.g. the broken port count, you not only failed to respond with any kind of counter-argument, you just merely called me an epithet. This doesn't support your case either. Why should people pay any attention to your postings if you're just a broken record, and unwilling to even consider any information that runs contrary to your own apparently fixed opinions?
But I feel like I'm just wasting my time here. I think I'll go back to fixing actual problems in actual software, rather than trying to change the direction that the wind blows.
Now Harv, you know that's because most people have better sense than to reply to your incessant trolling, reposting the same N postings over and over and over again. There's just not much point trying to discuss anything BSDish on Slashdot, because of that. But I guess it's really safe for you to do this, for whatever bitter reasons you have, as long as you can be Anonymous Coward. Never was the default username more appropriate than in your posts ...
Of course, you could prove me wrong by telling us all who you are, and how it was exactly that you came to be kicked out of the project -- or am I assuming too much, here? Am I wrong to also assume you're the person who subscribes FreeBSD mailing lists to other mailing lists to waste people's time? And files false Problem Report after false Problem Report to help gum up the works?
So, Harv, tell us who you are, and what exactly it is that you've done to *create* something --anywhere -- rather than just posting venom, and prove me wrong here. I'll be man enough to admit it.
You might also want to check out portsman.
barry. I don't know if it's really current, or just a nice start.
Harv, this is factually incorrect as per my last reply to one of your threads. There are 237 broken on i386-current, about half due to gcc3.3 issues.