When MS patches a security hole that's good. When 3rd party apps take advantage of known holes, that's bad. When the MS patch happens to close the hole the app use, that's a bug in the 3rd party app, NOT the OS.
MS isn't introducing the bugs, they are just exposing the bugs in the 3rd party software.
So let's see. What if Microsoft had an employee who was say breaking the GPL license by releasing a product that he had based on GPL code (CherryOS-like).
And MS said that's ok, because really, the employee is doing... "other" work for us, and only doing the Cherry-OS-thing on his "own-time".
Do you really expect the GPL folks who's code it was based on to buy that, and think MS might not have had some bit in it? And don't you think they'd quickly deny MS all rights to use the GPL code for any reason based on their employees breaking their license?
I think it's a demonstration that when you break a license agreement, you lose your rights in the agreement. OSDL agreed to the license, then employed a guy who was breaking it, and said 'not my problem' when that was pointed out.
Now the ODSL isn't allowed to use the software, however BitMover said they'd be glad to comp Linus and Andrew copies if they worked for anyone but ODSL (who broke the license agreement). Sounds pretty damn reasonable to me.
Yes, and that would be just a brilliant move. Then every developer in the EU can worry that the precedent has been set, and that the government might take away all their lifetimes of work with the stroke of a pen. All software developers (except for the OSS fringe) would flee the EU and move to sensible countries. That would do just wonders for the EU economies and tech base.
The fact that it died had more to do with the MS monopoly than it being 'inflexible'. Hitachi and other manufacturers actaully wanted to install it on some of their machines as a dual-boot option with windows. MS threatened to dramatically raise the price they paid for windows if they did that. So no manufacturers loaded it, so the OS died. Its death had nothing to do with scalability.
Apple actually made an offer for Be. It just wasn't as much money as the Be folks wanted. They didn't buy NeXT because of superior technology, but because they liked the total package (with Jobs) at that pricepoint better.
As far as JLG not having charisma, he had it, it was just that it was french charisma. How many American CEOs say that their product 'makes their nipples hard'?:)
And how environmentally friendly are those new batteries to dispose of compared to the old ones? That's something else that needs to be thought about when you are thinking 'green'. Some batteries are really really nasty for the environment at disposl time.
Yeah, maybe you should have said you don't like the included firewall rather than saying it doesn't exist. See, the difference is one is true, and one isn't.
I run a number of OpenBSD machines. I prefer PF myself. That doesn't mean I'm going to claim IP Chains doesn't exist just because I don't like it. Stop spreading FUD.
So first you say the firewall doesn't exist. And then you admit it exists, but it doesn't work well. When asked why, you say it's a 'hack'. You can filter by IP and by port. You can do that per port filtering on as many individual IPs as you care to give the box. That's a how lots of basic firewalls are. Personally I always have OpenBSD boxes up front protecting all my servers, be they MS, Apple or *BSD/nix, and the servers built-in firewall is only a 2nd line of defense.
Ok, it's a fairly simple firewall, and it isn't designed the way you want. That does NOT mean it doesn't exist, as you claim in your first post. That doesn't mean it doesnt' work with multiple IPs as you seem to claim in your second post. It just doesn't do it as easily as you'd like. FYI, there is a difference between existance and meeting your personal ease-of-use requirments.
MS software has PLENTY of faults with it. They do LOTS of stuff wrong. There is no need to make up shit that isn't true. When you claim something doesn't exist that does, your just spreading FUD and casting doubt on other valid criticisms of their software. FUD is bad, no matter which side of the OS wars you sit on.
Great, now you've discoverd the firewall exists. Whats the problem with multiple IPs? You can easily set the access to specific ports by specific IP. Where's the problem?
If you were a 2003 admin, you would know that the default vanilla 2003 server does indeed include a software firewall. Anyone who says it doesn't either has never used it, or is one of those paper MCSE types that has no actual working knowledge of how to admin a windows box, and never discovered the setup for it because it wasn't included in his cram course.
So, are you just a linux user who has never touched 2003 server and like to bash MS, or are you an incompetent MS admin that gives the rest of them a bad name?
Vanilla 2003 server. Control Panel --> Network Connections--> Local Area Connections --> Properties-->Advanced--> "INTERNET CONNECTION FIREWALL"
Hmm, what do you know, a software firewall built into it.
You know, I think the record says otherwise. He started working on the original Star Trek in 1966. I remember seeing him in LOTS of old TV shows before then.
Check out his resume on imdb...
He appeared in TV shows like SeaHunt, Dragnet, The Rough Riders, Bonanza, Wagon Train, Perry Mason, Dr Kildere, Combat, The Virginian, The Lieutenant, The Outer Limits, The man from U.N.C.L.E., etc, etc, etc, as well as bit parts in a number of movies.
All that before Star Trek made him famous. He sure got a ton of work on for someone who 'isn't that good of an actor'.
First: Transaction isolation and innodb can NOT solve these integrity problems.
The integrity problems are specifically because of poor implementation of foreign key and other constraints. Read up at http://sql-info.de or a million other sites on the net. There are fundamental problems in their implementation. It doesn't matter if you are using transaction isolation or innodb tables, MySQL silently changes data in many many circumstances. This is bad.
My 'users' aren't touching the database design. The database developers are. Multiple developers. When one makes a change and goes off shift, the next guy working on the table should immediately know if something changes made by the previous developer have invalidated some new data/scheme he's implementing. A database should never silently accept errors. It should always flag someone and refuse to make (or appear to make) a bad change.
I don't know about your background, but a lot of MySQL users haven't a clue how a real database should be designed or what real data integrity is.
I'm not bitching about MySQL not having features, I'm bitching about it's shoddy implementation of the features it already has. Foreign keys (in innodb) do not work right! Constraints do not work right! Many other basic features that MySQL claims to have do not work right!
I'll say it again: A database should protect your data. It should not silently change data it doesn't like, instead of aborting the transaction and throwing proper error message.
Postgres is also available for free. And it's designers appear to care about data integrity.
1) Yes, as soon as you try to make the constraint it should throw an error telling you that you are trying to disallow NULLS on a column that already contains NULLS.
A database should NEVER simply change data to what it 'thinks' should be there. It should always throw an error and let you either decide what the value should be changed to, or abort the modification all togeather.
2) This is not necessary with a full featured RDBMS. ALL the mature RDBMS's will tell you if you are trying to do such a thing. That saves a ton of time running checks by hand. The database should just do it for you.
3) I'm not sure what you mean. The linked table exmp15 already has NOT NULL set for ID if that is what you are talking about.
I don't know much about cars, but I don't need that silly pedal on the left in my car. When I want to slow down, I just pull on the handle of the emergency brake.
(Just because you are uninformed and don't know what other things are, doesn't make what you are doing 'right' and that they shouldn't be done better.)
Well, unlike the database for your personal blog on navel lint, many databases are used by multiple people.
If one person makes changes an important table, and another person tries inserting data into the table that are no longer valid because of those changes..., real databases throw up a big error saying something is seriously wrong. MySQL just sits there and pretends everything is fine. This is a "Bad Thing" (TM).
You've never had data corruption THAT YOU KNOW OF. The problem with it is that MySQL rarely throws an error, so the bad data going in goes in silently.
This isn't data corruption that throws up a big flag, 'your database file is corrupted and you can no longer access it', it's sometime subtle anomylies in the data. Some of which can be very very bad if you are relying on the data to be good (such as dealing with money, or used in calcuations that you rely on, etc).
I've often had MySQL folks told me they have never had data corruption. Until looking in detail at the real data. Then we've sometimes found it. All it takes is leaving out one tiny constraint check in your application you are writing.
Just because you haven't spotted the bad data, doesn't mean it's not in there. That's why I don't trust MySQL. I want to know the database is keeping the data safe. I want real foreign key and other constraints. Really enforced, with errors thrown up when someone tries inserting bad data. Not just guessing that since I haven't spotted any bad data, there's none in there.
If it's just for use in a blog, sure, who cares. But I generally work with databases where I actually care about the data. Postgres, Oracle, etc is the way to go if you really care about the data.
Yea, they have foreign keys! WhooHoo! Unfortunately, they didn't bother implementing them correctly.
The same way that MySQL has the constraints feature on columns. But it also isn't implemented correctly. If you insert out-of-bounds data, MySQL silently changes it to a number that it likes. Features implemented half-assed like that aren't really good features.
If they implement views, triggers, and stored procedures in the same crappy way, MySQL is still going to be a crappy DBMS. It will have lots of broken features which will still make it an unsafe place to store data that you care about.
3. Foreign Keys and Referential Integrity
Foreign keys are an essential part of any relational database. In MySQL's foreign key support has been added on through the InnoDB extension and is continually being improved. However some aspects of the foreign key implementation, especially in combination with other areas of functionality, may cause unexpected problems.
3.1. ALTER TABLE... SET NOT NULL
If a NOT NULL constraint is applied to a column, MySQL will set any rows containing NULL in that column to 0 (in integer or numeric columns) or '' ( empty string, in character columns). No warning is given.
In certain circumstances - particularly if the column contains character data - this may be quite practical, saving you an entire UPDATE tbl SET col = '' WHERE col IS NULL.
But - imagine the column is an integer foreign key. And the column it references does not contain a zero. Hmmm...
mysql> CREATE TABLE exmpl5 (
id INT NOT NULL,
val TEXT,
UNIQUE (id)
) TYPE=InnoDB;
Query OK, 0 rows affected (0.07 sec)
mysql> CREATE TABLE exmpl6 (
id INT,
blah TEXT,
INDEX(id),
CONSTRAINT id_fkey FOREIGN KEY (id)
REFERENCES exmpl5(id) ON DELETE NO ACTION
) TYPE=InnoDB;
Query OK, 0 rows affected (0.04 sec)
INSERT INTO exmpl5 VALUES(1, 'test');
INSERT INTO exmpl6 VALUES(1, 'foo');
INSERT INTO exmpl6 VALUES(NULL, 'bar');
INSERT INTO exmpl6 VALUES(0, 'oops');
ERROR 1216: Cannot add a child row: a foreign key constraint fails
SELECT * FROM exmpl6;
| id | blah |
| 1 | foo |
| NULL | bar |
2 rows in set (0.00 sec)
So far so good - this proves the foreign key constraint is being taken seriously. Now the fun starts:
ALTER TABLE exmpl6 CHANGE id id INT NOT NULL
Query OK, 2 rows affected (0.12 sec)
Records: 2 Duplicates: 0 Warnings: 1
INSERT INTO exmpl6 VALUES(NULL, 'bar');
ERROR 1048: Column 'id' cannot be null
INSERT INTO exmpl6 VALUES(0, 'oops');
ERROR 1216: Cannot add a child row: a foreign key constraint fails
This is perfectly normal behaviour for a well-adjusted database. Now let's have another look at what the table contains:
select * from exmpl6;
| id | blah |
| 1 | foo |
| 0 | bar |
2 rows in set (0.00 sec)
I don't recall successfully inserting the zero in that second row - do you? Perhaps I secretly inserted a row into exmpl5 with 'id' set to 0?
SELECT * FROM exmpl6 e6 LEFT JOIN exmpl5 e5 ON e5.id=e6.id;
| id | blah | id | val |
| 1 | foo | 1 | test |
| 0 | bar | NULL | NULL |
Err, no. All I can think of is that the foreign key was arrested as a potential terrorist suspect while I was seeing what other databases did given the same set of queries.
(Note: MySQL 4.1.7 raises a warning after the ALTER TABLE statement above with the cryptic message Data truncated for column 'id' at row 2.)
And did they fix it so that you input out of bounds data in a field that has constraints on it, it throws an error rather than just silently changing your input to a value it likes? Silent data corruption kinda sucks... That's why I use Postgres.
Slashdot Mirror
MS isn't introducing the bugs, they are just exposing the bugs in the 3rd party software.
And MS said that's ok, because really, the employee is doing... "other" work for us, and only doing the Cherry-OS-thing on his "own-time".
Do you really expect the GPL folks who's code it was based on to buy that, and think MS might not have had some bit in it? And don't you think they'd quickly deny MS all rights to use the GPL code for any reason based on their employees breaking their license?
Now the ODSL isn't allowed to use the software, however BitMover said they'd be glad to comp Linus and Andrew copies if they worked for anyone but ODSL (who broke the license agreement). Sounds pretty damn reasonable to me.
Yes, and that would be just a brilliant move. Then every developer in the EU can worry that the precedent has been set, and that the government might take away all their lifetimes of work with the stroke of a pen. All software developers (except for the OSS fringe) would flee the EU and move to sensible countries. That would do just wonders for the EU economies and tech base.
Every BeOS developer I've ever talked to described working with their API as a 'joy'. Things were easy, and made sense.
The fact that it died had more to do with the MS monopoly than it being 'inflexible'. Hitachi and other manufacturers actaully wanted to install it on some of their machines as a dual-boot option with windows. MS threatened to dramatically raise the price they paid for windows if they did that. So no manufacturers loaded it, so the OS died. Its death had nothing to do with scalability.
Apple actually made an offer for Be. It just wasn't as much money as the Be folks wanted. They didn't buy NeXT because of superior technology, but because they liked the total package (with Jobs) at that pricepoint better.
As far as JLG not having charisma, he had it, it was just that it was french charisma. How many American CEOs say that their product 'makes their nipples hard'? :)
And how environmentally friendly are those new batteries to dispose of compared to the old ones? That's something else that needs to be thought about when you are thinking 'green'. Some batteries are really really nasty for the environment at disposl time.
If they only put this much energy into checking for dupes on normal days...
Puddytat
Respect is a bit much to ask. Fear is enough. :)
I run a number of OpenBSD machines. I prefer PF myself. That doesn't mean I'm going to claim IP Chains doesn't exist just because I don't like it. Stop spreading FUD.
Ok, it's a fairly simple firewall, and it isn't designed the way you want. That does NOT mean it doesn't exist, as you claim in your first post. That doesn't mean it doesnt' work with multiple IPs as you seem to claim in your second post. It just doesn't do it as easily as you'd like. FYI, there is a difference between existance and meeting your personal ease-of-use requirments.
MS software has PLENTY of faults with it. They do LOTS of stuff wrong. There is no need to make up shit that isn't true. When you claim something doesn't exist that does, your just spreading FUD and casting doubt on other valid criticisms of their software. FUD is bad, no matter which side of the OS wars you sit on.
Great, now you've discoverd the firewall exists. Whats the problem with multiple IPs? You can easily set the access to specific ports by specific IP. Where's the problem?
If you were a 2003 admin, you would know that the default vanilla 2003 server does indeed include a software firewall. Anyone who says it doesn't either has never used it, or is one of those paper MCSE types that has no actual working knowledge of how to admin a windows box, and never discovered the setup for it because it wasn't included in his cram course.
Vanilla 2003 server. Control Panel --> Network Connections--> Local Area Connections --> Properties-->Advanced--> "INTERNET CONNECTION FIREWALL"
Hmm, what do you know, a software firewall built into it.
</sarcasm>
Check out his resume on imdb... He appeared in TV shows like SeaHunt, Dragnet, The Rough Riders, Bonanza, Wagon Train, Perry Mason, Dr Kildere, Combat, The Virginian, The Lieutenant, The Outer Limits, The man from U.N.C.L.E., etc, etc, etc, as well as bit parts in a number of movies.
All that before Star Trek made him famous. He sure got a ton of work on for someone who 'isn't that good of an actor'.
The integrity problems are specifically because of poor implementation of foreign key and other constraints. Read up at http://sql-info.de or a million other sites on the net. There are fundamental problems in their implementation. It doesn't matter if you are using transaction isolation or innodb tables, MySQL silently changes data in many many circumstances. This is bad.
My 'users' aren't touching the database design. The database developers are. Multiple developers. When one makes a change and goes off shift, the next guy working on the table should immediately know if something changes made by the previous developer have invalidated some new data/scheme he's implementing. A database should never silently accept errors. It should always flag someone and refuse to make (or appear to make) a bad change.
I don't know about your background, but a lot of MySQL users haven't a clue how a real database should be designed or what real data integrity is. I'm not bitching about MySQL not having features, I'm bitching about it's shoddy implementation of the features it already has. Foreign keys (in innodb) do not work right! Constraints do not work right! Many other basic features that MySQL claims to have do not work right!
I'll say it again: A database should protect your data. It should not silently change data it doesn't like, instead of aborting the transaction and throwing proper error message.
Postgres is also available for free. And it's designers appear to care about data integrity.
A database should NEVER simply change data to what it 'thinks' should be there. It should always throw an error and let you either decide what the value should be changed to, or abort the modification all togeather.
2) This is not necessary with a full featured RDBMS. ALL the mature RDBMS's will tell you if you are trying to do such a thing. That saves a ton of time running checks by hand. The database should just do it for you.
3) I'm not sure what you mean. The linked table exmp15 already has NOT NULL set for ID if that is what you are talking about.
(Just because you are uninformed and don't know what other things are, doesn't make what you are doing 'right' and that they shouldn't be done better.)
If one person makes changes an important table, and another person tries inserting data into the table that are no longer valid because of those changes..., real databases throw up a big error saying something is seriously wrong. MySQL just sits there and pretends everything is fine. This is a "Bad Thing" (TM).
This isn't data corruption that throws up a big flag, 'your database file is corrupted and you can no longer access it', it's sometime subtle anomylies in the data. Some of which can be very very bad if you are relying on the data to be good (such as dealing with money, or used in calcuations that you rely on, etc).
I've often had MySQL folks told me they have never had data corruption. Until looking in detail at the real data. Then we've sometimes found it. All it takes is leaving out one tiny constraint check in your application you are writing.
Just because you haven't spotted the bad data, doesn't mean it's not in there. That's why I don't trust MySQL. I want to know the database is keeping the data safe. I want real foreign key and other constraints. Really enforced, with errors thrown up when someone tries inserting bad data. Not just guessing that since I haven't spotted any bad data, there's none in there.
If it's just for use in a blog, sure, who cares. But I generally work with databases where I actually care about the data. Postgres, Oracle, etc is the way to go if you really care about the data.
The same way that MySQL has the constraints feature on columns. But it also isn't implemented correctly. If you insert out-of-bounds data, MySQL silently changes it to a number that it likes. Features implemented half-assed like that aren't really good features.
If they implement views, triggers, and stored procedures in the same crappy way, MySQL is still going to be a crappy DBMS. It will have lots of broken features which will still make it an unsafe place to store data that you care about.
As far as a reference for just some of the problems with their foreign key implementation, and as pointed out elsewhere in the thread, and found here...: http://sql-info.de/mysql/referential-integrity.htm l%233_5
3. Foreign Keys and Referential Integrity Foreign keys are an essential part of any relational database. In MySQL's foreign key support has been added on through the InnoDB extension and is continually being improved. However some aspects of the foreign key implementation, especially in combination with other areas of functionality, may cause unexpected problems.
3.1. ALTER TABLE ... SET NOT NULL
If a NOT NULL constraint is applied to a column, MySQL will set any rows containing NULL in that column to 0 (in integer or numeric columns) or '' ( empty string, in character columns). No warning is given.
In certain circumstances - particularly if the column contains character data - this may be quite practical, saving you an entire UPDATE tbl SET col = '' WHERE col IS NULL.
But - imagine the column is an integer foreign key. And the column it references does not contain a zero. Hmmm...
mysql> CREATE TABLE exmpl5 (
id INT NOT NULL,
val TEXT,
UNIQUE (id) ) TYPE=InnoDB;
Query OK, 0 rows affected (0.07 sec)
mysql> CREATE TABLE exmpl6 (
id INT,
blah TEXT,
INDEX(id),
CONSTRAINT id_fkey FOREIGN KEY (id) REFERENCES exmpl5(id) ON DELETE NO ACTION ) TYPE=InnoDB;
Query OK, 0 rows affected (0.04 sec)
INSERT INTO exmpl5 VALUES(1, 'test');
INSERT INTO exmpl6 VALUES(1, 'foo');
INSERT INTO exmpl6 VALUES(NULL, 'bar');
INSERT INTO exmpl6 VALUES(0, 'oops'); ERROR 1216: Cannot add a child row: a foreign key constraint fails
SELECT * FROM exmpl6;
| id | blah |
| 1 | foo |
| NULL | bar |
2 rows in set (0.00 sec)
So far so good - this proves the foreign key constraint is being taken seriously. Now the fun starts:
ALTER TABLE exmpl6 CHANGE id id INT NOT NULL
Query OK, 2 rows affected (0.12 sec)
Records: 2 Duplicates: 0 Warnings: 1
INSERT INTO exmpl6 VALUES(NULL, 'bar');
ERROR 1048: Column 'id' cannot be null
INSERT INTO exmpl6 VALUES(0, 'oops');
ERROR 1216: Cannot add a child row: a foreign key constraint fails
This is perfectly normal behaviour for a well-adjusted database. Now let's have another look at what the table contains:
select * from exmpl6;
| id | blah |
| 1 | foo |
| 0 | bar |
2 rows in set (0.00 sec)
I don't recall successfully inserting the zero in that second row - do you? Perhaps I secretly inserted a row into exmpl5 with 'id' set to 0?
SELECT * FROM exmpl6 e6 LEFT JOIN exmpl5 e5 ON e5.id=e6.id;
| id | blah | id | val |
| 1 | foo | 1 | test |
| 0 | bar | NULL | NULL |
Err, no. All I can think of is that the foreign key was arrested as a potential terrorist suspect while I was seeing what other databases did given the same set of queries.
(Note: MySQL 4.1.7 raises a warning after the ALTER TABLE statement above with the cryptic message Data truncated for column 'id' at row 2.)
And did they fix it so that you input out of bounds data in a field that has constraints on it, it throws an error rather than just silently changing your input to a value it likes? Silent data corruption kinda sucks... That's why I use Postgres.