Sorry, as much as it would be fun to bash Apple about this, and they do deserve more than a bit of bashing, the fundimental problem is that Windows has the security of a screen door. If Windows was 1/10 as secure as Mac OS/X, FreeBSD, and yes, even Linux, this sort of mischief would go unnoticed.
For years they guy has been openly claiming to be working on a bomb. The fact that he does not unambiguously have one yet is astounding.
With all the information that is public, it *is* trivial to create a bomb. Access to plutonium, which he has, is the hard part.
I hate to introduce politics, but it has to be said, Saddam maybe, could have, possibly, been working on something, if you look at the intelligence "just so." North Korea, has been openly saying they are working on these bombs. North Korea sells arms to our enemies. I blame Bush on all counts. The guy is all about acquiring power, but without the wisdom or honor to use it well.
I am remeinded if Bill Maher, Usually you have an administration that is corrupt or one that is inept. The Bush administration is both.
It has not been proved that he did anything. When a wife goes missing, they always suspect the husband first.
I have no idea about the facts of the case, but the way the police work is scientifically incorrect. They come up with a theory and build a case to support it. It is an adversarial system in which the proof of "real" guilt is secondary to winning the case. The CSI nonsense of evidence indicating the killer is fiction. Real police have no idea about scientific method or clear thinking.
I know a lot of police, and the more police I know, the more I dislike police.
so, unless and until I hear some real evidence against the guy, I think the police are wrong.
The analogy, was just an example of how it worked, not a design spec. I also said "for lack of a better analogy." Often in engineering, one must explain concepts in general terms, and leave the specifics to further study.
PostgreSQL's MVCC is analogus to Java's memory management, but not like it.
There is an amount of work/time required to update a record. One must block writers during this time, or use some sort MVCC. If you have MVCC, there little or no blocking, but you have to clean up. If you don't have MVCC you have to block for writes and scale like crap. The work/time has to be done at some point, PostgreSQL uses MVCC and requires VACUUM to clean up periodically.
If I understood the parent post, the temporary copies of the records are never deleted. That's a coding error to me.
He didn't mean about never using them, rather that at some moment, after the queries have run to completion, and all related transactions have finished the commit, and the temporary records are not needed anymore, then have those records deleted.
No it is not that they are "never" deleted, it is that, for lack of a better analogy, they become unused, sort of like Java when objects go out of scope. The VACUUM process acts like a garbage collector for the system.
VACUUM has a few modes, in itss most useful modes, it goes through a table and marks space as free to be reused as needed without blocking queries.
Imediately removing rows, or "tuples," requires additional overhead at query time. All MVCC systems have to cope with removing rows that are no longer used. Just like Java has to run garbage collection.
The benefit of MVCC is that [N] queries can be run at any one time and never block on contention unless a lock is explicitly needed.
In the long run, MVCC can actually reduce the amount of work and/or latency in an active database where reading and writing concurrently occur.
For the 37000th time. I never said a word about emulating any PostgreSQL features in PHP. The emulation comment was completely MySQL-related to get around a limitation that when you use prepared statements MySQL doesn't use the query cache. If you application can benefit from the query cache, then PHP has an option to emulate prepare/execute in PDO. You are reading a half-baked second-hand account of a talk I gave.
Well, I appologize if I took too litterally a bad report of what you said. In my defense, I responded, I believe, before you clarified.
I really would, however, like to see less MySQL focus in PHP. I believe that more openness and a more "political" push to be more balanced would make for better quality applications built upon PHP.
Thing is for many types of applications transactions are rarely needed,
This is fundimentally in error. The only reason why you may think you don't need transactions is because you don't understand them. In addition, it isn't just "transactions" per se' but MVCC, or multi-version concurrency. You NEED this to keep other processes from blocking in high volume.
For me, the reason I've never spent much time on Postgres is that I know MySQL well enough and haven't needed to look for alternatives and the perceived potential gain from what I have seen is too small to be worth the investment.
Sorry, this is going to sound like an insult, it may be, however it is not meant as one, but it is very often true. MySQL proponents always seem to argue that ignorance is better than knowledge. If you don't know the benefits, you can't really guage the worth of the investment.
No one who really knows databases chose MySQL, everyone that argues *for* MySQL admit that they don't know databases. Why do you think that is?
The knowledge that MySQL craps out when you hit it with too much traffic has nothing to do with computer science, it is a quirk of one very specific piece of software.
And how would one properly evaluate the software, or anything for that matter, if they did not understand the basic principles of what they were supposed to accomplish. Calling scalability and lock contention "quirks" is rediculous.
Having only dealt a tiny bit with MySQL, I did not know up until reading the comments on this article that it handled this stuff so badly - I understand the nature of the problems involved, but I assumed that they were dealt with.
That is a poor excuse and if you were caught with your pants down like that in a mission critical environment, you'd be fired.
When all you've got is a hammer all your problems start looking like nails. When you're a DBA you think all data should be stored in a database.
I'm not a DBA, I'm a software developer and consultant.
So you've never seen a.html file before? What do you think those contain? What about a.php file?.css?.jpg? These are all files that contain data. The contents of all of these files could easily be placed in a database. So why don't we? Because it's much easier to use files for these things. And then there's performance reasons.
Nice strawman, but program files and programatic content are fundimentally different than data.
And these are the same reasons to use MySQL. Easier to maintain. Better performance.
I have seen no evidence that MySQL is easier to maintain, nor is it faster on anything but the simplest queries.
In many ways, *all* data should be in a database. Any data that is not in a database seeks the functionality of a database. Think about searching for email contacts, or words in a word document. Have you ever realized that a spreadsheet is just a database?
Sure, it is impractical for the world to expect everyone to use a uniform data store, but it would make using, moving, interpreting, searching, etc. data easier.
In a web environment, you would almost NEVER use a flat file. Certainly not without serious locking considerations. In PHP for instance, sessions have to use flock to keep things like frames from causing phantom writes and lost data,
MySQL has no technical merrits over somethig like PostgreSQL or Oracle, while Oracle does cost money, PostgreSQL is also free.
For the tables you need constraints and transactions you use Innodb. For the tables you need performance you use MyISAM
What happens when you've discovered that your first estimate was wrong?
What happens when you update a couple tables and one or more of them are ISAM?
What is it about databases that turns people into snobs?
What is it about databases that make people disregard all the knowledge, experience, and expertise gained in the field over 40 years of study and implementation.
But maybe we don't need a "real" database. Maybe we need an easy-to-use replacement for flat files with some database features. Not everyone is running a bank, or handling a billion emails a day, or tracking inventory for Wal-Mart. Lots of users just want something that can handle their small little application.
If you have a choice between a motecarlo and a mercedies, both were free, which would you choose? Oh, yea, I'll take the chevy. NOT!
Spoken like a true CS major...
I am not, as it turns out, a CS major. I studied CS in the 70s when it was still math.
Perhaps you should stop using MyISAM and start using InnoDB:
If you are going to do, you flush any of the so-called benefits of MySQL down the drain.
Face it, there is no serious technical advantage to MySQL while PostgreSQL has.
Sorry to break it to that PostgreSQL fan, but MySQL has had ACID transactions for years now, and it's still faster than PostgreSQL for average web app queries. Time to stop making excuses based on half-truths about ancient versions of MySQL and just acknowledge that MySQL is fast.
I get a kick out of this. Yes MySQL has had "ACID" with innodb, but innodb table are much slower than PostgreSQL. When you see benchmarks that show MySQL faster than other real databases, you can be pretty sure they are not using innodb tables.
With all due respect, Rasmus needs schooling when it comes to databases, and a few other things for that matter. If he is interested in a serious debate/discussion, I have his email address and he should let me know, I'll contact him. It's only ignorance if you "ignore" what you don't know.
The problem with MySQL is exactly what he said, that if MySQL doesn't do it, you can do it in PHP. Well, that is just flat out stupid. Dumb. Moronic. A database's job is to deal with data. How many times have I done something easy on PostgreSQL, that MySQL would require a query, PHP work, second query, PHP work, third query, I can't count.
PostgreSQL is not perfect, and it does have its issues, but it has been my experience that, when used correctly, it out performs the likes of MySQL. Yea, sure, when there is little web traffic, MySQL will do better than PostgreSQL with simple queries, but when you have any traffic and/or any non-simplistic queries, PostgreSQL moves in front quickly.
The feature you are talking about is vital to the proper operation of a real database. The "transactional reasons" you refer too are the difference between a "real" database and a toy like "mysql" (which is neither yours nor very good SQL)
Imagine two operations concurrently operating on a database, one in the process of modifying the data, the other simply reading it. The first process starts a transaction and makes a lot of changes, then commits the changes. The second query just wants to execute a quick query. The second query gets its data and is done. When the first operation finishes, its changes become available. No one had to wait for anything. In MySQL, the second query would have to wait. As we see in so many MySQL web sites, as the waiters pile up, sooner or later you run out of MySQL connections and start to get error messages.
IMHO, one of the reasons why the web is broken is that it is so easy to create content that no one takes the time to learn the basic computer science involved. When things break or perform poorly, they blame everyone but themselves. There is REAL science in computers, if if you ignore it, you'll never do anything worth while.
Both Jamie and Adam, and the whole crew for that matter, do have a lot of fun. You can tell, also, that Adam and Jamie, if not hate, don't like each other. I think it is that tension that makes it interesting.
Their "science" however, certainly ther techniques, are kind of hit or miss. Sometimes they do something and you say, "Wow, I wouldn't have thought of that," sadly, most of the time they miss some fundimental points. Like the propeller driven jet pack thing, watching it "work" it was obvious the thing was losing power in loose belts, and they never addressed increasing the gear ratio to the props to generate more thrust and seeing how much the motor could drive the system.
Grant Imahara is probably the smartest guy there, but Jamie has boat loads more practical experience.
Kari, well, lets be honest, she's cute, smart, artistic, like to blow sh*&^%t up, and has a nice laugh, what's not to love?
The more I read about DNA the more I have come to think of it in terms of software. Specific genes may be individual instructions and or subroutines. The order in which genes occur probably has as much to do with the whole thing as the pieces of the DNA itself.
That's what worries me about genetic experimentation, of course it is nessisary, but I think we don't quite fully understand it yet and our experiments are like a nube cracker changing code with a debugger. Hopefully, what they experiment on just dies, because, you know, you never really know!
You can call my article a troll, but I disagree (obviously)
I think it is fairly accepted in the industry that the "free" versions of *BSD are losing market share. Most people would call this dying.
I would even say that NetBSD *is* dead as I don't think anyone can make a truely viable argument for using it.
Say what you want, your definition of dying is different than mine, but that does not make the post a troll.
Re:Whoever modded parent 'flamebait' is full of it
on
The Future of NetBSD
·
· Score: 1
The irony is that BSD people are militantly opposed to reason. The ship is sinking and they are debating the color it should be and which part of the ship is more important.
The original article shows that they guy is starting to realize that something is wrong, but he is so steeped in the BSD environment that he can't see it for what it is. A fish can't tell its wet.
Its a shame, BSD is awesome, in its time it was head and shoulders above everything.
What I'd love to see is a UnifiedBSD project that takes NetBSD, FreeBSD, OpenBSD, etc. and creates one cutting edge BSD project to keep Linux in check. They'd probably need to make it GPL.
At least we can see the grade level of argument that follows
Were OpenSSH GPL'd instead of BSD'd, OpenBSD would still be in financial trouble. In the embedded world, NetBSDs biggest supporter is Wasabi Systems, who've donated tons of code back to the project. Apple has donated plenty of code back to FreeBSD.
It is hard to say if OpenSSH were GPL instead of BSD, they would still be in financial trouble. There would certainly, however, be less duplicated effort in keeping OpenSSH up to date with the commercial versions
Apple may have "donated plenty" but you can't download the code, remove trademarks, and release your own OS/JOE now can you? Take a good look at CentOS and what this represents in terms of real freedom and compare it to the BSD world.
The BSD folk are so used to getting almost nothing, that "almost nothing" looks like "plenty."
Linux survives because it is anarchy, not the the BSD world. The Linux kernel takes whatever is there for the taking. They disregard correctness and completeness in order to have something that works. The BSD world, on the other hand, design then implement. This takes longer and is seen by those who've never maintained something as 'dying'.
Where to start? Not only is there incorrectness in this paragraph, but actual FUD.
"Linux survives because it is anarchy" Please explain this to me as the Linux kernel is well managed, so this is false.
"kernel takes whatever is there for the taking" what does this mean? There is a code submission process and not all patches and submissions get accepted, so this is false.
"They disregard correctness and completeness in order to have something that works" This is my personal favorite, umm, isn't something that "works" by definition "correct." Or are you saying that *BSD code has no bugs? Or that nothing in *BSD is incomplete? or that nothing in *BSD is suboptimal?(Threading anyone?)
"The BSD world, on the other hand, design then implement." So, here is the biggest piece of FUD, you are insinuating that the Linux crowd does not "design" features? You are ranting and participating in worst sort of argument. You are using hyperbole and FUD to impugn Linux in support of BSD
You're ignoring reality in order to support your argument. Go troll somewhere else.
It was not a troll. It was an observation, and I think it is a SERIOUS issue with the BSDs. If you want to have a serious debate about it that is fine, but FUD is not debate
Slashdot Mirror
AFAIK, We are not talking about an install procedure, but the disasterous "autorun" with the ever so common "Administrator" privilages.
Sorry, as much as it would be fun to bash Apple about this, and they do deserve more than a bit of bashing, the fundimental problem is that Windows has the security of a screen door. If Windows was 1/10 as secure as Mac OS/X, FreeBSD, and yes, even Linux, this sort of mischief would go unnoticed.
For years they guy has been openly claiming to be working on a bomb. The fact that he does not unambiguously have one yet is astounding.
With all the information that is public, it *is* trivial to create a bomb. Access to plutonium, which he has, is the hard part.
I hate to introduce politics, but it has to be said, Saddam maybe, could have, possibly, been working on something, if you look at the intelligence "just so." North Korea, has been openly saying they are working on these bombs. North Korea sells arms to our enemies. I blame Bush on all counts. The guy is all about acquiring power, but without the wisdom or honor to use it well.
I am remeinded if Bill Maher, Usually you have an administration that is corrupt or one that is inept. The Bush administration is both.
Sorry for interrupting here....
It has not been proved that he did anything.
When a wife goes missing, they always suspect the husband first.
I have no idea about the facts of the case, but the way the police work is scientifically incorrect. They come up with a theory and build a case to support it. It is an adversarial system in which the proof of "real" guilt is secondary to winning the case. The CSI nonsense of evidence indicating the killer is fiction. Real police have no idea about scientific method or clear thinking.
I know a lot of police, and the more police I know, the more I dislike police.
so, unless and until I hear some real evidence against the guy, I think the police are wrong.
The analogy, was just an example of how it worked, not a design spec. I also said "for lack of a better analogy." Often in engineering, one must explain concepts in general terms, and leave the specifics to further study.
PostgreSQL's MVCC is analogus to Java's memory management, but not like it.
There is an amount of work/time required to update a record. One must block writers during this time, or use some sort MVCC. If you have MVCC, there little or no blocking, but you have to clean up. If you don't have MVCC you have to block for writes and scale like crap. The work/time has to be done at some point, PostgreSQL uses MVCC and requires VACUUM to clean up periodically.
If I understood the parent post, the temporary copies of the records are never deleted. That's a coding error to me.
He didn't mean about never using them, rather that at some moment, after the queries have run to completion, and all related transactions have finished the commit, and the temporary records are not needed anymore, then have those records deleted.
No it is not that they are "never" deleted, it is that, for lack of a better analogy, they become unused, sort of like Java when objects go out of scope. The VACUUM process acts like a garbage collector for the system.
VACUUM has a few modes, in itss most useful modes, it goes through a table and marks space as free to be reused as needed without blocking queries.
Imediately removing rows, or "tuples," requires additional overhead at query time. All MVCC systems have to cope with removing rows that are no longer used. Just like Java has to run garbage collection.
The benefit of MVCC is that [N] queries can be run at any one time and never block on contention unless a lock is explicitly needed.
In the long run, MVCC can actually reduce the amount of work and/or latency in an active database where reading and writing concurrently occur.
For the 37000th time. I never said a word about emulating any PostgreSQL features in PHP. The emulation comment was completely MySQL-related to get around a limitation that when you use prepared statements MySQL doesn't use the query cache. If you application can benefit from the query cache, then PHP has an option to emulate prepare/execute in PDO. You are reading a half-baked second-hand account of a talk I gave.
Well, I appologize if I took too litterally a bad report of what you said. In my defense, I responded, I believe, before you clarified.
I really would, however, like to see less MySQL focus in PHP. I believe that more openness and a more "political" push to be more balanced would make for better quality applications built upon PHP.
ALTER TABLE foo ENGINE=InnoDB;
Fine, and how long does that take? 60M+ records?
Thing is for many types of applications transactions are rarely needed,
This is fundimentally in error. The only reason why you may think you don't need transactions is because you don't understand them. In addition, it isn't just "transactions" per se' but MVCC, or multi-version concurrency. You NEED this to keep other processes from blocking in high volume.
For me, the reason I've never spent much time on Postgres is that I know MySQL well enough and haven't needed to look for alternatives and the perceived potential gain from what I have seen is too small to be worth the investment.
Sorry, this is going to sound like an insult, it may be, however it is not meant as one, but it is very often true. MySQL proponents always seem to argue that ignorance is better than knowledge. If you don't know the benefits, you can't really guage the worth of the investment.
No one who really knows databases chose MySQL, everyone that argues *for* MySQL admit that they don't know databases. Why do you think that is?
The knowledge that MySQL craps out when you hit it with too much traffic has nothing to do with computer science, it is a quirk of one very specific piece of software.
And how would one properly evaluate the software, or anything for that matter, if they did not understand the basic principles of what they were supposed to accomplish. Calling scalability and lock contention "quirks" is rediculous.
Having only dealt a tiny bit with MySQL, I did not know up until reading the comments on this article that it handled this stuff so badly - I understand the nature of the problems involved, but I assumed that they were dealt with.
That is a poor excuse and if you were caught with your pants down like that in a mission critical environment, you'd be fired.
When all you've got is a hammer all your problems start looking like nails. When you're a DBA you think all data should be stored in a database.
.html file before? What do you think those contain? What about a .php file? .css? .jpg? These are all files that contain data. The contents of all of these files could easily be placed in a database. So why don't we? Because it's much easier to use files for these things. And then there's performance reasons.
I'm not a DBA, I'm a software developer and consultant.
So you've never seen a
Nice strawman, but program files and programatic content are fundimentally different than data.
And these are the same reasons to use MySQL. Easier to maintain. Better performance.
I have seen no evidence that MySQL is easier to maintain, nor is it faster on anything but the simplest queries.
This is such a false argument.
In many ways, *all* data should be in a database. Any data that is not in a database seeks the functionality of a database. Think about searching for email contacts, or words in a word document. Have you ever realized that a spreadsheet is just a database?
Sure, it is impractical for the world to expect everyone to use a uniform data store, but it would make using, moving, interpreting, searching, etc. data easier.
In a web environment, you would almost NEVER use a flat file. Certainly not without serious locking considerations. In PHP for instance, sessions have to use flock to keep things like frames from causing phantom writes and lost data,
MySQL has no technical merrits over somethig like PostgreSQL or Oracle, while Oracle does cost money, PostgreSQL is also free.
For the tables you need constraints and transactions you use Innodb. For the tables you need performance you use MyISAM
What happens when you've discovered that your first estimate was wrong?
What happens when you update a couple tables and one or more of them are ISAM?
What is it about databases that turns people into snobs?
What is it about databases that make people disregard all the knowledge, experience, and expertise gained in the field over 40 years of study and implementation.
Nope. InnoDB tables are faster than PostgreSQL for simple queries.
Got any supporting benchmarks? URL?
What's a "simple query?"
But maybe we don't need a "real" database. Maybe we need an easy-to-use replacement for flat files with some database features. Not everyone is running a bank, or handling a billion emails a day, or tracking inventory for Wal-Mart. Lots of users just want something that can handle their small little application.
...
If you have a choice between a motecarlo and a mercedies, both were free, which would you choose? Oh, yea, I'll take the chevy. NOT!
Spoken like a true CS major
I am not, as it turns out, a CS major. I studied CS in the 70s when it was still math.
Perhaps you should stop using MyISAM and start using InnoDB:
If you are going to do, you flush any of the so-called benefits of MySQL down the drain.
Face it, there is no serious technical advantage to MySQL while PostgreSQL has.
That's just the thing. MySQL loses on all technical merits, yet the pro-mysql mob refuse to be reasonable. :-)
And yet none of that explains why it is necessary for the original record to persist indefinitely.
It isn't "indefinitely," it is until vacuum is run, and yes, queries run while vaccum is operating.
Every database that has "multi-versioning" needs some sort of "purge" operation. It is all how and when it is executed.
Sorry to break it to that PostgreSQL fan, but MySQL has had ACID transactions for years now, and it's still faster than PostgreSQL for average web app queries. Time to stop making excuses based on half-truths about ancient versions of MySQL and just acknowledge that MySQL is fast. I get a kick out of this. Yes MySQL has had "ACID" with innodb, but innodb table are much slower than PostgreSQL. When you see benchmarks that show MySQL faster than other real databases, you can be pretty sure they are not using innodb tables.
With all due respect, Rasmus needs schooling when it comes to databases, and a few other things for that matter. If he is interested in a serious debate/discussion, I have his email address and he should let me know, I'll contact him. It's only ignorance if you "ignore" what you don't know.
The problem with MySQL is exactly what he said, that if MySQL doesn't do it, you can do it in PHP. Well, that is just flat out stupid. Dumb. Moronic. A database's job is to deal with data. How many times have I done something easy on PostgreSQL, that MySQL would require a query, PHP work, second query, PHP work, third query, I can't count.
PostgreSQL is not perfect, and it does have its issues, but it has been my experience that, when used correctly, it out performs the likes of MySQL. Yea, sure, when there is little web traffic, MySQL will do better than PostgreSQL with simple queries, but when you have any traffic and/or any non-simplistic queries, PostgreSQL moves in front quickly.
The feature you are talking about is vital to the proper operation of a real database. The "transactional reasons" you refer too are the difference between a "real" database and a toy like "mysql" (which is neither yours nor very good SQL) Imagine two operations concurrently operating on a database, one in the process of modifying the data, the other simply reading it. The first process starts a transaction and makes a lot of changes, then commits the changes. The second query just wants to execute a quick query. The second query gets its data and is done. When the first operation finishes, its changes become available. No one had to wait for anything. In MySQL, the second query would have to wait. As we see in so many MySQL web sites, as the waiters pile up, sooner or later you run out of MySQL connections and start to get error messages. IMHO, one of the reasons why the web is broken is that it is so easy to create content that no one takes the time to learn the basic computer science involved. When things break or perform poorly, they blame everyone but themselves. There is REAL science in computers, if if you ignore it, you'll never do anything worth while.
Both Jamie and Adam, and the whole crew for that matter, do have a lot of fun. You can tell, also, that Adam and Jamie, if not hate, don't like each other. I think it is that tension that makes it interesting.
Their "science" however, certainly ther techniques, are kind of hit or miss. Sometimes they do something and you say, "Wow, I wouldn't have thought of that," sadly, most of the time they miss some fundimental points. Like the propeller driven jet pack thing, watching it "work" it was obvious the thing was losing power in loose belts, and they never addressed increasing the gear ratio to the props to generate more thrust and seeing how much the motor could drive the system.
Grant Imahara is probably the smartest guy there, but Jamie has boat loads more practical experience.
Kari, well, lets be honest, she's cute, smart, artistic, like to blow sh*&^%t up, and has a nice laugh, what's not to love?
The more I read about DNA the more I have come to think of it in terms of software. Specific genes may be individual instructions and or subroutines. The order in which genes occur probably has as much to do with the whole thing as the pieces of the DNA itself.
That's what worries me about genetic experimentation, of course it is nessisary, but I think we don't quite fully understand it yet and our experiments are like a nube cracker changing code with a debugger. Hopefully, what they experiment on just dies, because, you know, you never really know!
My only problem with this position is that it is not based on merit.
You can call my article a troll, but I disagree (obviously)
I think it is fairly accepted in the industry that the "free" versions of *BSD are losing market share. Most people would call this dying.
I would even say that NetBSD *is* dead as I don't think anyone can make a truely viable argument for using it.
Say what you want, your definition of dying is different than mine, but that does not make the post a troll.
The irony is that BSD people are militantly opposed to reason. The ship is sinking and they are debating the color it should be and which part of the ship is more important.
The original article shows that they guy is starting to realize that something is wrong, but he is so steeped in the BSD environment that he can't see it for what it is. A fish can't tell its wet.
Its a shame, BSD is awesome, in its time it was head and shoulders above everything.
What I'd love to see is a UnifiedBSD project that takes NetBSD, FreeBSD, OpenBSD, etc. and creates one cutting edge BSD project to keep Linux in check. They'd probably need to make it GPL.
At least we can see the grade level of argument that follows
Were OpenSSH GPL'd instead of BSD'd, OpenBSD would still be in financial trouble. In the embedded world, NetBSDs biggest supporter is Wasabi Systems, who've donated tons of code back to the project. Apple has donated plenty of code back to FreeBSD.It is hard to say if OpenSSH were GPL instead of BSD, they would still be in financial trouble. There would certainly, however, be less duplicated effort in keeping OpenSSH up to date with the commercial versions
Apple may have "donated plenty" but you can't download the code, remove trademarks, and release your own OS/JOE now can you? Take a good look at CentOS and what this represents in terms of real freedom and compare it to the BSD world.
The BSD folk are so used to getting almost nothing, that "almost nothing" looks like "plenty."
Linux survives because it is anarchy, not the the BSD world. The Linux kernel takes whatever is there for the taking. They disregard correctness and completeness in order to have something that works. The BSD world, on the other hand, design then implement. This takes longer and is seen by those who've never maintained something as 'dying'.Where to start? Not only is there incorrectness in this paragraph, but actual FUD.
"Linux survives because it is anarchy" Please explain this to me as the Linux kernel is well managed, so this is false.
"kernel takes whatever is there for the taking" what does this mean? There is a code submission process and not all patches and submissions get accepted, so this is false.
"They disregard correctness and completeness in order to have something that works" This is my personal favorite, umm, isn't something that "works" by definition "correct." Or are you saying that *BSD code has no bugs? Or that nothing in *BSD is incomplete? or that nothing in *BSD is suboptimal?(Threading anyone?)
"The BSD world, on the other hand, design then implement." So, here is the biggest piece of FUD, you are insinuating that the Linux crowd does not "design" features? You are ranting and participating in worst sort of argument. You are using hyperbole and FUD to impugn Linux in support of BSD
You're ignoring reality in order to support your argument. Go troll somewhere else.It was not a troll. It was an observation, and I think it is a SERIOUS issue with the BSDs. If you want to have a serious debate about it that is fine, but FUD is not debate