Don't be silly. The only reason not to call your USS-compliant OS "UNIX" is to avoid receiving a C&D letter from The Open Group, which currently owns the trademark. It's technically accurate to call such an OS Unix, because it does everything Unix does, and does it the same way.
So in your official literature you say "Unix-like", and everywhere else you just say "Unix", 'cause the Open Group has no hope of hassling every Slashdot or Usenet poster. The "*nix" thing is dumb-looking and redundant.
The whole thing is just a trademark issue. Comparable to the common habit of saying "Xerox" when you mean "photocopy" and "Kleenex" when you mean "facial tissue". If a lawyer tells you to stop doing it, you stop doing it until he goes away. Otherwise, you just don't worry about it.
Hey, anybody ever notice that American doctors say "epinephrine" to refer to a hormone that everybody else (including doctors in other countries) calls "adrenaline"? That's because in the U.S., and nowhere else, "Adrenaline" a trademark.
I used to be on Kylix project. Early on, "Kylix is VB for Linux" became the marketing mantra. I was enthusiastic about the product, so I tried very hard to believe that this was an honest statement.
But now that I no longer work for Borland, I have to admit to myself that this is just not true. Yeah, you can point to a lot of IDE features that are similar in the two products. But there are differences as well, And, more importantly, Object Pascal is a completely different language from any Basic dialect. There's the way variables are declared. There's language semantics (VB has one kind of string data type; OP has a lot more). There's a lot of other things.
Which is not to say that Kylix isn't a reasonable migration path for VB programmers. Indeed, a lot of Delphi/Kylix enthusiasts seem to consider themselves "reformed" VBers. But that's simply because Delphi and Kylix are better designed than VB. If you want to abandon VB for something more powerful, you'll probably find that Delphi and/or Kylix is worth the effort it takes to re-educate yourself. But that effort is not minimal.
You're basically advocating a "pick your battles" strategy. I can't argue with that. If showing up at a specific time is all you need to do to make your boss happy, then it makes no sense no to do so. No matter how silly and unfair a rule or policy is, you might as well live with it if you can do so without too much inconvenience.
Problem is, it is not that easy to satisfy such a boss. There's never just one simple rule you can obey and forget. There are always dozens of strange little policies that interfere with your job, and even each other. People who obsess over that kind of trivia do so because they're out of their depth. Their rules aren't an expression of any actual management policy -- they're symptoms of performance anxiety.
Now, if that kind of nervous management is something you can cope with, fine. Some people, particularly those in the project management profession, make a study of handling manager neurosis. I have a lot of respect for people who can deal with shit like that. But I'm not one of them.
Yeah, I guess the "watcha doin?" thing is a issue even in well-run organizations. It's the one justification I can think of for the pseudo-privacy of cubicals (as opposed to the anti-privacy of bullpens): they allow people to avoid looking over your shoulder if they don't really want to. Then again, simple good manners goes a long way in any workspace -- even one with private offices.
A certain well-known software company gives all its engineers (and various lesser mortals, as space allows) private offices. Not that unusual, except these offices (designed by the founder of the company) do not have any eye-level windows facing the corridor. So if you don't want anybody looking over your shoulder, all you have to do is close the door and lower the blinds.
When I had one of these (I'm not an engineer, but the building was underutilized when I was hired; later I was exiled to a cube) I found it extremely pleasant. Closed the door, cranked up the Hilary Hahn, and cranked out the prose. But after a while I came to realize that the company had a lot of organization and collaboration issues. I don't think "pathologically extreme individualism" would be an exagerated description. The offices weren't the primary cause of this problem, of course, but they did make it hard to stamp out.
... then the employer is screwed anyway. Only a totally mismanaged outfit would judge an employee by how busy they look. If management actually cares about whether employees are earning their pay, they're keeping close track of what they're working on and whether they're delivering on time. They're not going to be fooled by Ferris Bueller tricks.
My mistake. I assumed somebody who knew so much about MySQL's shortcomings had to be a MySQL hater.
On the other hand, you seem to be reading a lot into my use of the word "benchmark". Perhaps you're assuming I'm like all those marketroid drones who use bogus benchmarks to "prove" that a particular product is "superior". In real life, benchmarks only prove that a product does one particular thing in one particular circumstance better. Benchmarks have their legitimate uses, but only if you bear in mind their limitations.
And I still think benchmarking MySQL against other DBMSs makes sense. You simply have to be careful understanding what the benchmarks mean. For example, you seem to be saying that MySQL will always beat a fancier DBMS when you use it as a simple data repository, where you only retrieve data one record at a time, using a single-field unique index. OK, let's take that as a given. That still leaves me with some unanswered questions:
If this is all just a matter of feature overhead, wouldn't Berkeley DB be even faster?
I know for a fact that MySQL takes a performance hit when you use multi-field indexes or if the indexed field is a string. (That's why Slashdot comments now have unique ID numbers.) Can this cost enough to justify using a "real" DBMS? And are there real-world web applications where this matters?
This kind of argument always seems to end up comparing MySQL with Oracle or PostgreSQL. Now, these are big (I won't say "bloated", though some would) systems optimized for high-end applications. Users of Interbase and its open-source branch Firebird claim that these products eliminate a lot of the performance issues associated with other databases, while retaining all the features of a "real" DBMS. Has anybody made a serious effort to compare the performance of MySQL with these engines?
My parting comment is offtopic, but I have to respond to this:
There are plenty of people using Oracle in a situation that probably should be using MySQL. I can think of at least three examples in my own company where I've told the folks doing the work that they'd be better off with MySQL, because they're basically batch processing in Oracle, not using any constraints, foreign keys, or transactions.
There's more at stake here than performance. Having multiple database engines at hand costs you in terms of maintenance. In two different companies where I worked, the IS people and the web monkeys insisted that people not build applications around MySQL. They weren't just being narrow minded. Once the developer handed off the application, somebody had to look after it for years into the future -- and nothing raises your maintenance costs more than unnecessary multiplicity of technologies.
Then again, both companies sold, and used, high-end servers, so the performance hit was never an issue anyway! People actually just used MySQL because it was easier to install, or because it was what they knew.
As I said, in the older models you have to let it power-off by itself for this to work.
That's amusing. I used to have a Phillips Rush 107 (stolen, and after fighting its design flaws and driver bugs, I can't bring myself to replace it) with exactly the opposite problem: it remembered where you were when you pressed STOP, even if it powered down. But if it powered down while PAUSEd, it'd forget where it was.
Anyway, thanks for the info. Too bad Apple doesn't think to provide this info -- they almost missed a sale!
MySQL is a data store with a minimal SQL front end written by people who DO NOT UNDERSTAND the issues of database design in a high load / high transaction environment.
True. Unfortunately, most people who design database applications don't understand them either.
How do you benchmark a ferrari and a freight train?
You compare cargo capacity and speed, of course. This would then help you choose based on the relative importance of these factors for your application. Though I suspect most people would choose some kind of comprimise, such as a semi truck.
MySQL is missing so many key features that benchmarking MySQL against Postgresql is useless.
What's "key" to you is not "key" to everybody. Thousands of webmasters claim that MySQL has the features they need. Maybe they're wrong, but you're not going to convince them by throwing out generalizations.
How fast is MySQL when it has check constraints on data? No one knows, since it doesn't have them.
How fast is MySQL when you use a complex sub select? No one knows, it can't do more than a few common cases yet.
How fast is MySQL when you use stored procedures? Triggers? custom data types? Unions?
Come on guy, you're preaching to the choir. I know MySQL is missing key features, or implements them badly. If I were a MySQL partisan (isn't obvious that I'm not?) I'd respond with two statements: (1) MySQL has enough features for most web applications; (2) Leaving out all those features makes MySQL faster than other engines.
Now, I happen to suspect that both those statements are false, at least for larger web applications. But I'm not enough of a database expert to make a good argument. And even if I were, throwing CS theories at people doesn't seem to accomplish much. What would accomplish much is a real-world demonstration. Like, suppose you design some simple content mangement schema, and you want to use it to implement a web site that serves 10,000 pages to 100,000 users per day. (Insert additional assumptions here.) How will your choice of back-end affect performance? Will MySQL really be faster than PostgreSQL or Firebird? And if so, would Berkeley DB be even faster? How about complex queries (a particularly nasty MySQL shortcoming)? Answering these questions would accomplish more than any amount of theorizing and flaming.
None of those things are there. WHEN MySQL gets around to having most of the features a REAL database has, then you can benchmark it,
Somehow, I get the impression that you don't like MySQL!;) Correct me if I'm wrong, but if somebody told you you had to use it for your next project, you'd be just a little unhappy, right? Well then, you need to respond to the fact that MySQL is what everybody uses, You have a vested interest in demonstrating its shortcomings. You can't just ignore it and hope it will go away. Not gonna happen.
You're making a joke, of course, but there's an important truth here. It's my opinion that you can't talk about a programming language without talking about the community of programmers that uses it. Programmers gravitate towards one language or another because it suits their way of thinking and working. This results in a two-way influence, as the language influences the work and thought habits of the programmer, and the programmers agitates for "obvious" changes to the language.
Compare some of the big languages around: Perl, Java, C++, Visual Basic. Each has its own community, and each community has its own set of goals and priorities. Each community is wont to criticize the technical shortcomings of the others' languages. These criticisms often have some technical validity, but are usually beside the point -- each language "just works" for its own community.
So be quiet with your anti-MySQL comments,.. I can never understand why some people flame it so badly...
Uhm, I'm bored with the MySQL flame wars (even though I helped start them), so no noise from me. But I do want to point out that the attitude in your first sentence kind of answers the question implicit in your second sentence!
Actually, a lot of Slashdot content is, for all practical purposes, static html. Notice the message that appears when you post?
You neglected to mention what DBMS you use. Or is it a given nowadays that everybody uses MySQL?
Which is my cue for my usual anti-MySQL flame. Except that it's old, I'm tired of doing it, you've all heard it. Still, I'd like to see some serious benchmarks comparing MySQL with PostgreSQL, Firebird, and Berkeley DB. With attention to realistic web-style queries, scalability and (except for Berkeley DB, of course) complex queries.
The first thing I want to know when anybody talks about BSD is this: why precisely should I learn yet another OS? What do I get that I don't already get from Linux or Windows or QNX or Inferno or...
I'm not suggesting that nobody needs to know BSD. But any review of a BSD book -- and the ensuing discussion -- should touch on the question of who should be interested in the topic.
Enough about Herb Schildt.
The review is painfully padded. All JSG seems to have to say is, "Looked for factual errors, couldn't find any. Liked the book, even though I disagreed with some of the advice." Throwing in a lengthy outline and a lot of useless trivia (imaginary domain names, forsooth!) to bring it up to a proper length is just lame.
Linking to Barnes & Noble's web site hurts your credibility. I assume people do it because they give better referral rates than Amazon, and/or you're pissed about Jeff's patent hunger. Well, forget it -- I don't want to deal with B&N's cruddy web site, abysmal customer service, and absurd inventory problems.
Well OK, Steve is a bad person. But even if he Saw The Light and reformed, what would happen? They'd fire him, and replace him with somebody who was With the Program.
That's the real problem: the intentions of the individual don't matter, the system just selects people who are Right For The Job. That's why we have CEOs who talk like they're from an alternate universe where human logic does apply, and legislators who are as corrupt as year-old milk, and presidents who have the moral stature of Mafia Alluminum Siding salesmen. And worst of all, we have TV execs who can't program anything except reality shows and cop shows.
So if you wanna hate something, hate the system. Hating its scions may make you feel all warm and righteous, but it's not very productive.
I'm not sure I agree. But I do share your enthusiasm for the Wiki concept. And the best way to understand that enthusiasm is to read (or rather use) the authoritative book on the concept.
(Warning! A lot of remainders vendors have cheap copies of this book, even though it's still in print. The CDs on these copies are screwed up, but are usable if you know to convert the Perl scripts from Macintosh format!)
You think CEOs write their own mumbo-jumbo? That takes specialized training!
But what you're really saying is that we should hold a CEO responsible for all the vagueness and dissimulation a company engages in. I guess you're right, but I also think that the modern CEO doesn't have that much free will, being dictated to by the insane requirement of 21st century capitalism.
For that matter, Ikvm isn't a proper project -- their home page is just a blog. And Mono itself is a long way from being something people would actually use. So perhaps I was too enthusiastic. But if things keep moving, Mono could become an alternative for both Java and C# programmers.
One thing that always irritated me when they revived the TV version of Star Trek: Picard always addressed Klingons with a boistrous "Qapla'!" ("Success!"), as if it were the equivalent of "goodbye". I'm not one of those people who makes a hobby out of studying Klingon (excuse me, "tlhIngan Hol"), but I do remember an interview with Marc Okrand on NPR. In the usual NPR manner, they asked him to say goodbye in Klingon. He responded that Klingons had no use for human-style politeness -- when a Klingon is done talking, he just leaves.
But perhaps it makes sense. Given Picard's officious know-it-allness, he's probably not the great expert on Klingon culture that he pretends to be! Rather like that guy in Len Deighton's novels who thinks knowing a smattering of Cantonese gives him license to torture Chinese waiters.
And of course, rather than correct Picard, the Klingons would just say "Qapla'" back at him. Easier than ripping his throat out, as he deserves. Silly humans!
WTF is the point of all this MONO.NET bullshit? If we wanted to run java apps there are excellent complete, crossplatform, enterprise grade JVMs from IBM, sun, oracle, BEA Jrockit......
You mean IKVM, right? Mono is the open source version of.Net. IKVM is the project to run Java apps under.Net; presumably it will work either under Microsoft.Net or Mono.
Two reasons to want a JVM under.Net. First, although there are a lot of Java VMs out there, production grade VMs are not free. If, for some reason, you already have a good.NET setup, it makes perfect sense to leverage it for the odd Java application, rather than spring for an extra Java VM license.
Second, not all Java apps are 100% Java. That's why we have the Java Native Interface, which lets you call native APIs from Java, and also lets you embed Java modules in native-code applications. (A lot of the programming tools in Sun's Java SDK are JNI apps, for obvious reasons.) Now, unless you're going to get all religious and insist that Java and.NET must never contaminate each other. it makes perfect sense for Java and.NET to interoperate using Ikvm, or something like it. Suppose, for example, your boss says that your next project must run under.NET, but won't give you time to port all your Java classes. Or more generally, suppose you're just open minded enough to take the best of both platforms.
Slashdot Mirror
So in your official literature you say "Unix-like", and everywhere else you just say "Unix", 'cause the Open Group has no hope of hassling every Slashdot or Usenet poster. The "*nix" thing is dumb-looking and redundant.
For further details, see my previous rant.
The whole thing is just a trademark issue. Comparable to the common habit of saying "Xerox" when you mean "photocopy" and "Kleenex" when you mean "facial tissue". If a lawyer tells you to stop doing it, you stop doing it until he goes away. Otherwise, you just don't worry about it.
Hey, anybody ever notice that American doctors say "epinephrine" to refer to a hormone that everybody else (including doctors in other countries) calls "adrenaline"? That's because in the U.S., and nowhere else, "Adrenaline" a trademark.
But now that I no longer work for Borland, I have to admit to myself that this is just not true. Yeah, you can point to a lot of IDE features that are similar in the two products. But there are differences as well, And, more importantly, Object Pascal is a completely different language from any Basic dialect. There's the way variables are declared. There's language semantics (VB has one kind of string data type; OP has a lot more). There's a lot of other things.
Which is not to say that Kylix isn't a reasonable migration path for VB programmers. Indeed, a lot of Delphi/Kylix enthusiasts seem to consider themselves "reformed" VBers. But that's simply because Delphi and Kylix are better designed than VB. If you want to abandon VB for something more powerful, you'll probably find that Delphi and/or Kylix is worth the effort it takes to re-educate yourself. But that effort is not minimal.
Problem is, it is not that easy to satisfy such a boss. There's never just one simple rule you can obey and forget. There are always dozens of strange little policies that interfere with your job, and even each other. People who obsess over that kind of trivia do so because they're out of their depth. Their rules aren't an expression of any actual management policy -- they're symptoms of performance anxiety.
Now, if that kind of nervous management is something you can cope with, fine. Some people, particularly those in the project management profession, make a study of handling manager neurosis. I have a lot of respect for people who can deal with shit like that. But I'm not one of them.
A certain well-known software company gives all its engineers (and various lesser mortals, as space allows) private offices. Not that unusual, except these offices (designed by the founder of the company) do not have any eye-level windows facing the corridor. So if you don't want anybody looking over your shoulder, all you have to do is close the door and lower the blinds.
When I had one of these (I'm not an engineer, but the building was underutilized when I was hired; later I was exiled to a cube) I found it extremely pleasant. Closed the door, cranked up the Hilary Hahn, and cranked out the prose. But after a while I came to realize that the company had a lot of organization and collaboration issues. I don't think "pathologically extreme individualism" would be an exagerated description. The offices weren't the primary cause of this problem, of course, but they did make it hard to stamp out.
... then the employer is screwed anyway. Only a totally mismanaged outfit would judge an employee by how busy they look. If management actually cares about whether employees are earning their pay, they're keeping close track of what they're working on and whether they're delivering on time. They're not going to be fooled by Ferris Bueller tricks.
On the other hand, you seem to be reading a lot into my use of the word "benchmark". Perhaps you're assuming I'm like all those marketroid drones who use bogus benchmarks to "prove" that a particular product is "superior". In real life, benchmarks only prove that a product does one particular thing in one particular circumstance better. Benchmarks have their legitimate uses, but only if you bear in mind their limitations.
And I still think benchmarking MySQL against other DBMSs makes sense. You simply have to be careful understanding what the benchmarks mean. For example, you seem to be saying that MySQL will always beat a fancier DBMS when you use it as a simple data repository, where you only retrieve data one record at a time, using a single-field unique index. OK, let's take that as a given. That still leaves me with some unanswered questions:
- If this is all just a matter of feature overhead, wouldn't Berkeley DB be even faster?
- I know for a fact that MySQL takes a performance hit when you use multi-field indexes or if the indexed field is a string. (That's why Slashdot comments now have unique ID numbers.) Can this cost enough to justify using a "real" DBMS? And are there real-world web applications where this matters?
- This kind of argument always seems to end up comparing MySQL with Oracle or PostgreSQL. Now, these are big (I won't say "bloated", though some would) systems optimized for high-end applications. Users of Interbase and its open-source branch Firebird claim that these products eliminate a lot of the performance issues associated with other databases, while retaining all the features of a "real" DBMS. Has anybody made a serious effort to compare the performance of MySQL with these engines?
My parting comment is offtopic, but I have to respond to this: There's more at stake here than performance. Having multiple database engines at hand costs you in terms of maintenance. In two different companies where I worked, the IS people and the web monkeys insisted that people not build applications around MySQL. They weren't just being narrow minded. Once the developer handed off the application, somebody had to look after it for years into the future -- and nothing raises your maintenance costs more than unnecessary multiplicity of technologies.Then again, both companies sold, and used, high-end servers, so the performance hit was never an issue anyway! People actually just used MySQL because it was easier to install, or because it was what they knew.
Anyway, thanks for the info. Too bad Apple doesn't think to provide this info -- they almost missed a sale!
This one. (Ducks)
Now, I happen to suspect that both those statements are false, at least for larger web applications. But I'm not enough of a database expert to make a good argument. And even if I were, throwing CS theories at people doesn't seem to accomplish much. What would accomplish much is a real-world demonstration. Like, suppose you design some simple content mangement schema, and you want to use it to implement a web site that serves 10,000 pages to 100,000 users per day. (Insert additional assumptions here.) How will your choice of back-end affect performance? Will MySQL really be faster than PostgreSQL or Firebird? And if so, would Berkeley DB be even faster? How about complex queries (a particularly nasty MySQL shortcoming)? Answering these questions would accomplish more than any amount of theorizing and flaming.
Somehow, I get the impression that you don't like MySQL!Compare some of the big languages around: Perl, Java, C++, Visual Basic. Each has its own community, and each community has its own set of goals and priorities. Each community is wont to criticize the technical shortcomings of the others' languages. These criticisms often have some technical validity, but are usually beside the point -- each language "just works" for its own community.
So you've looked at other Open Source DBMSs? I'd be very interested in hearing specifics as to their blowhardedness.
You neglected to mention what DBMS you use. Or is it a given nowadays that everybody uses MySQL?
Which is my cue for my usual anti-MySQL flame. Except that it's old, I'm tired of doing it, you've all heard it. Still, I'd like to see some serious benchmarks comparing MySQL with PostgreSQL, Firebird, and Berkeley DB. With attention to realistic web-style queries, scalability and (except for Berkeley DB, of course) complex queries.
The first thing I want to know when anybody talks about BSD is this: why precisely should I learn yet another OS? What do I get that I don't already get from Linux or Windows or QNX or Inferno or... I'm not suggesting that nobody needs to know BSD. But any review of a BSD book -- and the ensuing discussion -- should touch on the question of who should be interested in the topic.
Enough about Herb Schildt.
The review is painfully padded. All JSG seems to have to say is, "Looked for factual errors, couldn't find any. Liked the book, even though I disagreed with some of the advice." Throwing in a lengthy outline and a lot of useless trivia (imaginary domain names, forsooth!) to bring it up to a proper length is just lame.
Linking to Barnes & Noble's web site hurts your credibility. I assume people do it because they give better referral rates than Amazon, and/or you're pissed about Jeff's patent hunger. Well, forget it -- I don't want to deal with B&N's cruddy web site, abysmal customer service, and absurd inventory problems.
FPs must be content-free!
That's the real problem: the intentions of the individual don't matter, the system just selects people who are Right For The Job. That's why we have CEOs who talk like they're from an alternate universe where human logic does apply, and legislators who are as corrupt as year-old milk, and presidents who have the moral stature of Mafia Alluminum Siding salesmen. And worst of all, we have TV execs who can't program anything except reality shows and cop shows.
So if you wanna hate something, hate the system. Hating its scions may make you feel all warm and righteous, but it's not very productive.
(Warning! A lot of remainders vendors have cheap copies of this book, even though it's still in print. The CDs on these copies are screwed up, but are usable if you know to convert the Perl scripts from Macintosh format!)
I have an old IBM 770 I'd like to fix. But those replacement LCDs sell for more than the machine is worth!
But what you're really saying is that we should hold a CEO responsible for all the vagueness and dissimulation a company engages in. I guess you're right, but I also think that the modern CEO doesn't have that much free will, being dictated to by the insane requirement of 21st century capitalism.
For that matter, Ikvm isn't a proper project -- their home page is just a blog. And Mono itself is a long way from being something people would actually use. So perhaps I was too enthusiastic. But if things keep moving, Mono could become an alternative for both Java and C# programmers.
It's not true! And besides, he's cut way back!
But perhaps it makes sense. Given Picard's officious know-it-allness, he's probably not the great expert on Klingon culture that he pretends to be! Rather like that guy in Len Deighton's novels who thinks knowing a smattering of Cantonese gives him license to torture Chinese waiters.
And of course, rather than correct Picard, the Klingons would just say "Qapla'" back at him. Easier than ripping his throat out, as he deserves. Silly humans!
Two reasons to want a JVM under .Net. First, although there are a lot of Java VMs out there, production grade VMs are not free. If, for some reason, you already have a good .NET setup, it makes perfect sense to leverage it for the odd Java application, rather than spring for an extra Java VM license.
Second, not all Java apps are 100% Java. That's why we have the Java Native Interface, which lets you call native APIs from Java, and also lets you embed Java modules in native-code applications. (A lot of the programming tools in Sun's Java SDK are JNI apps, for obvious reasons.) Now, unless you're going to get all religious and insist that Java and .NET must never contaminate each other. it makes perfect sense for Java and .NET to interoperate using Ikvm, or something like it. Suppose, for example, your boss says that your next project must run under .NET, but won't give you time to port all your Java classes. Or more generally, suppose you're just open minded enough to take the best of both platforms.