saying "just don't compile the options you don't want."
Problem is, that doesn't affect the main problem, which is that 3 million lines of options code is a LOT harder to keep bug free among all the different combinations than 1 million loc.
All bugs may be shallow given enough eyeballs, but the difficulty of debugging the linux codebase may well be increasing faster than the number of eyeballs.
I have 25k files in my repository and no sign of any slowdown. I'm sure repositories like Mono's are much much larger.
It's true that svn is slower to compute "blame." The developers are working on this. But it's much faster at other operations. Overall, the edge is with svn already.
"people who would have worked on the kernel"
on
No More BitKeeper Linux
·
· Score: 2, Interesting
well, that cuts both ways... how many people worked on the kernel, that wouldn't have if Linus had listened to the people who wanted to keep using something as broken as CVS until some hypothetical distributed open-source version control system got ready for use?
Zope is a reason there are so many python web frameworks today: people try Zope, think, "there has GOT to be a better way" and create a new framework.:)
"Microsoft technically still owes them royalties on every XP disk sold, but Novell isn't forcing it anymore"
If you're running a company looking wildly around for new revenue to replace the dying Netware, I'm skeptical that you'd overlook royalties on one of the most-used pieces of software on the planet.
That reply makes it clear you have no idea what I'm talking about. That's okay; you'll figure it out once you have a co-worker make an addition to your "wrapper" that leaves out the common code and you spend a few hours figuring out why your data is inconsistent.
I've been using postgresql since 7.0 in 2000. I admit that I never experienced what are largely characterized as the Bad Old Days of 6.x, but I doubt most people calling postgresql hard to setup haven't, either.
If we talk about 7.x and if "./configure; make install; initdb; set up cron job to run vacuum" makes postgresql hard to install I guess I was wrong, but if it does your threshold of "hard" is going to cause you a lot of pain.:)
There are so many problems with FOREIGN KEYs that we don't
know where to start:
Foreign keys make life very complicated, because the foreign key definitions
must be stored in a database and implementing them would destroy the whole
``nice approach'' of using files that can be moved, copied and removed.
The speed impact is terrible for INSERT and UPDATE statements,
and in this case almost all FOREIGN KEY checks are useless because you
usually insert records in the right tables in the right order, anyway.
There is also a need to hold locks on many more tables when updating one
table, because the side effects can cascade through the entire database. It's
MUCH faster to delete records from one table first and subsequently delete
them from the other tables.
You can no longer restore a table by doing a full delete from
the table and then restoring all records (from a new source or from a backup).
If you have foreign keys you can't dump and restore tables unless you do so
in a very specific order.
It's very easy to do ``allowed'' circular definitions that make the
tables impossible to recreate each table with a single create statement,
even if the definition works and is usable.
The only nice aspect of FOREIGN KEY is that it gives ODBC and some
other client programs the ability to see how a table is connected and to use
this to show connection diagrams and to help in building applicatons.
"the PostgreSQL philosophy is to throw in everything and the kitchen sink and then make it work right, whereas the MySQL approach is to add things one at a time, making sure that everything works right from the beginning"
I guess that's one way to make MySQL's "foreign keys are for wimps" documentation look good: anyone who implements more than MySQL does is just throwing stuff together and worrying about debugging later! Never mind that just about anyone else is more standards compliant; the MySQL team are heroes of stability and everyone else is just trying to add features for marketing.
Nobody really needs that ACID crap anyway, and if you say you do, you're just a poseur...
I hope to heaven I never have to maintain anything you write.
Ever heard of the "Don't repeat yourself" principle? Putting logic in the application that belongs in the database means that if just one place that touches the data forgets to do what your trigger should have done, you're screwed.
Maybe your applications are small enough that this is an acceptable risk for you. The ones I have worked on haven't been.
if I read "well enough for most purposes" by a mysql fanboy one more time I will have to start drinking before noon.
popularity isn't proof of clue, guys. How many people run windows, right?
with postgresql and firebird there have long been available real open-source databases that are just as easy to get up and running as MySQL, but won't hamstring you when you start to learn more.
I'm glad to see MySQL joining the club, but it must be shocking for the "we don't need no steenkeeng logic in the database" fanboys to adjust... Parent is case in point, I guess.
How useful is it to be able to scale to large numbers of servers if your database doesn't even support the features your application developers need?
The number of companies who NEED clustering is much, much smaller than the number who need triggers, views, etc. No database professional would touch a product that doesn't support those with a ten foot pole, which is why people who actually know databases (as opposed to your average 50-pages-of-PHP newbie) have disdained MySQL for so long.
"Novell has the resources and expertise to make Linux a truly viable desktop OS for Joe Corporate User."
Uh... what desktop OS expertise does Novell bring to the table that SuSE didn't already have? The last _desktop_ OS Novell produced was Novel DOS 7. (Or was it 8?)
having adminned variously HP-UX, AIX, Irix, and Solaris boxes, one of the first things I did on a machine was install the gnu toolset. The proprietary stuff was years behind (Solaris was probably the worst) and getting almost anything modern to compile with them was a real bitch.
Slashdot Mirror
saying "just don't compile the options you don't want."
Problem is, that doesn't affect the main problem, which is that 3 million lines of options code is a LOT harder to keep bug free among all the different combinations than 1 million loc.
All bugs may be shallow given enough eyeballs, but the difficulty of debugging the linux codebase may well be increasing faster than the number of eyeballs.
"The state of Linux on my Toshiba, 2005"
Come on, even for slashdot generalizing from a single datapoint is a little underwhelming.
it's an open (as opposed to several commercial debian derivatives) debian-based distro that isn't 3 years out of date.
:)
lots of people love debian but wish stable weren't so old and testing were more... stable.
I have 25k files in my repository and no sign of any slowdown. I'm sure repositories like Mono's are much much larger.
It's true that svn is slower to compute "blame." The developers are working on this. But it's much faster at other operations. Overall, the edge is with svn already.
well, that cuts both ways... how many people worked on the kernel, that wouldn't have if Linus had listened to the people who wanted to keep using something as broken as CVS until some hypothetical distributed open-source version control system got ready for use?
no, not because of TFA, but because a /. editor actually did some of that new-fangled, whadayacallit, editing. I think I need to lie down.
you're welcome
large, monolithic, and inelegant.
:)
Zope is a reason there are so many python web frameworks today: people try Zope, think, "there has GOT to be a better way" and create a new framework.
Apple didn't acquire NeXT/Jobs until after Be's founder got greedy and priced himself out of a future.
"Microsoft technically still owes them royalties on every XP disk sold, but Novell isn't forcing it anymore"
If you're running a company looking wildly around for new revenue to replace the dying Netware, I'm skeptical that you'd overlook royalties on one of the most-used pieces of software on the planet.
but from the information on that page there's no way to say.
you would shortly have SEDO (search engine de-optimizer) specialists who charge you to sic their botnets on your competition... no thanks.
That reply makes it clear you have no idea what I'm talking about. That's okay; you'll figure it out once you have a co-worker make an addition to your "wrapper" that leaves out the common code and you spend a few hours figuring out why your data is inconsistent.
I've been using postgresql since 7.0 in 2000. I admit that I never experienced what are largely characterized as the Bad Old Days of 6.x, but I doubt most people calling postgresql hard to setup haven't, either.
:)
If we talk about 7.x and if "./configure; make install; initdb; set up cron job to run vacuum" makes postgresql hard to install I guess I was wrong, but if it does your threshold of "hard" is going to cause you a lot of pain.
Here's what the MySQL docs (source: http://web.archive.org/web/20000619203550/http://w eb.mysql.com/Manual_chapter/manual_Compatibility.h tml) used to say about foreign keys, for instance:
"the PostgreSQL philosophy is to throw in everything and the kitchen sink and then make it work right, whereas the MySQL approach is to add things one at a time, making sure that everything works right from the beginning"
I guess that's one way to make MySQL's "foreign keys are for wimps" documentation look good: anyone who implements more than MySQL does is just throwing stuff together and worrying about debugging later! Never mind that just about anyone else is more standards compliant; the MySQL team are heroes of stability and everyone else is just trying to add features for marketing.
Nobody really needs that ACID crap anyway, and if you say you do, you're just a poseur...
I hope to heaven I never have to maintain anything you write.
Ever heard of the "Don't repeat yourself" principle? Putting logic in the application that belongs in the database means that if just one place that touches the data forgets to do what your trigger should have done, you're screwed.
Maybe your applications are small enough that this is an acceptable risk for you. The ones I have worked on haven't been.
if I read "well enough for most purposes" by a mysql fanboy one more time I will have to start drinking before noon.
popularity isn't proof of clue, guys. How many people run windows, right?
with postgresql and firebird there have long been available real open-source databases that are just as easy to get up and running as MySQL, but won't hamstring you when you start to learn more.
I'm glad to see MySQL joining the club, but it must be shocking for the "we don't need no steenkeeng logic in the database" fanboys to adjust... Parent is case in point, I guess.
How useful is it to be able to scale to large numbers of servers if your database doesn't even support the features your application developers need?
The number of companies who NEED clustering is much, much smaller than the number who need triggers, views, etc. No database professional would touch a product that doesn't support those with a ten foot pole, which is why people who actually know databases (as opposed to your average 50-pages-of-PHP newbie) have disdained MySQL for so long.
"Novell has the resources and expertise to make Linux a truly viable desktop OS for Joe Corporate User."
Uh... what desktop OS expertise does Novell bring to the table that SuSE didn't already have? The last _desktop_ OS Novell produced was Novel DOS 7. (Or was it 8?)
having adminned variously HP-UX, AIX, Irix, and Solaris boxes, one of the first things I did on a machine was install the gnu toolset. The proprietary stuff was years behind (Solaris was probably the worst) and getting almost anything modern to compile with them was a real bitch.
"if you ever suffer from insomnia, try reading the technical literature about databases"
:)
Having read a fair amount, he's far from wrong on this point.
"I'm going to start making it very clear to my customers now that MS has no intention of playing nice on the web"
Wow. Welcome to 1998.
LLVM is written in C++, and RMS has dictated "Only C shalt thou write for gcc."
Damn... still waiting to be able to stream from launchcast.