These days, Java is quite fast and efficient, and there are even a lot of different alternative VMs you can try. Sure, startup time isn't the best, and Swing is still a lumbering, over-engineered, ill-fitting albatross: but these problems don't matter for server applications.
IMHO, the best part is that you can write programs that run on the JVM in a dialect of Lisp and interact seamlessly with other code on the JVM.
But since most developers model their domains Object Oriented, why is MySql the default choice for any small application? Why not a document database or a native oo one?
The relational model is consistent and easy to work with. It's easy to specify constraints that describe what the data should look like, and to allow several applications to interact with the data. It's also easier to optimize a database when you can describe discrete queries instead of directly following links from program code as you would in a navigational/object/document/etc. database.
Furthermore, application data models aren't all that object-oriented. Most of the time, the manipulated data types (say, "story", "post", and "user") fall into well-defined categories that correspond well to rows in a table. The few mismatches are easily dealt with in application code.
Sure, using an object database might be "easier" for the first 15 minutes, but you'll kick yourself when you have to manipulate it in any kind of sophisticated fashion.
No. It was made by schmoozing investors. None of companies you list has ever turned a profit.
This is the kind of reckless behavior that leads to financial bubbles. Pay should be much lower initially. I doubt Zuckerberg would have worked any less hard (or hacked any fewer email accounts) if he had been paid the mere subsidence wage of $1 million per year.
The page you cited, on column-oriented databases, describes an implementation strategy that's applicable to many types of databases. There are database engines that present a perfectly normal SQL interface to a column store, and there's actually a direct link to LucidDB from the article. Likewise, there's nothing stopping a Cassandra-like database from serializing its on-disk bits the other way around.
Column-orientation has nothing to do with the "NoSQL" databases that are in vogue. It's completely orthogonal. You're talking about using vectors or linked lists when everyone else is arguing over whether to serialize data with XML or JSON.
These slides present a balanced and comprehensive overview of the current state of free databases. Whether you're in the NoSQL camp or not, they're worth reading.
That said, here's my take:
It's currently fashionable to replace MySQL with some "NoSQL" database or other. This trend is driven by two factors:
MySQL's community is fragmenting into several forks as Oracle purchases the rights, which created the impression that MySQL's development is entering a riskier, unstable period.
"NoSQL" is the technology buzzword du jour in the Bay Area. It's difficult to overstate the impact of social forces on technology choice: most technology selections are governed more by what our friends say than by an impartial and disinterested weighing of merits.
I haven't seen any consideration from potential "NoSQL" adopters of the benefits of using a good relational database like PostgreSQL. There's a world of difference between it and MySQL, and condemning all relational database systems because of bad experiences with MySQL is like condemning all sandwiches because McDonalds once made you sick. In giving up RDBMSes entirely, these developers lose quite a bit of safety, flexibility, an convenience. It's a huge over-reaction.
This field should not be about following trends, though unfortunately, that's how most people choose which technologies to use: it should be about choosing the best tool for the job. And I believe that in the vast majority of cases, the advantages conferred by a relational system --- enforced integrity, interoperability based on SQL, query flexibility, storage flexibility --- make an RDBMs the best choice for almost any job. If you need sloppier semantics for some cases (for example, "eventual consistency"), you can layer that on top of a robust RDBMs.
Sure, you can flash the BIOS with garbage. But you can restore it with the right equipment -- the hardware itself lives on. You can't physically destroy the computer that way.
Of course it is. But since when are companies socially responsible?
If companies were people, we'd call them sociopaths. No, the law must force companies to abide by acceptable standards of behavior. A company will do everything it can, ethical or not, to maximize profit while staying in the bounds of the law. Therefore, to change behavior, the law must change.
Software should not be able to destroy hardware, period. The GPU's cooling system should be designed to safety operate for sustained periods at peak load --- anything less is artificially crippling the hardware and leads to both security and reliability problems.
Great job, NVIDIA: now, malware can not only destroy your files, but destroy your expensive graphics card as well.
As for you, bitZtream: you come into every Slashdot discussion carrying the most ignorant, vitriolic, hateful chip on your shoulder that man has ever conceived. In every conceivable circumstance, you come down in favor of money, power, influence, and the elite instead of social justice and basic fairness. You would rather live in the world of medieval crusades than in the one of Locke and Rousseau.
You're either an excellent troll or a miserable human being. I'll give you the benefit of the doubt and assume the former.
The response will probably be eventually be, "deal".
At that point, you simply tell the designers, "I am implementing policy as directed. Please address all future complaints regarding this matter directly to the owner."
Remember, you are expendable, the twit isn't.
That's a harmful attitude. I refuse to live in fear. I am a professional and will act like one, not cower at the thought of being the bearer of bad news.
Look: the owner is most likely rational. Irrational people don't run companies, at least not for very long. The owner will listen to reason.
On the off chance that he doesn't, just act as directed above. Note all your actions, and make sure you act professionally. If the owner decides to terminate you, he will be doing so without cause, and you will be able to collect unemployment benefits. Furthermore, your professional behavior will behoove you in the eyes of your next employer.
The problem has nothing to do with mutexes or any other process synchronization issue.
Instead, the problem is that the disk in the machine only spins so fast, and can only suck so many bits off the platter at once. Graphic design files are huge, and the disk is probably only barely adequate to handle working with one at a time. If you try to double the demands on the disk, the disk will say "I quit" and make everything wait.
No clever algorithmic improvement can get around that fundamental bottleneck.
Process priorities also effect IO prioritization on OS X.
Even if that were true (and I can't find any evidence in favor of it), concurrent access would wreck the page cache. That would cause more disk seeks and actual physical IO than the baseline scenario of one user accessing the drive, which would result in a slowdown even with perfect IO prioritization.
This twit isn't your problem. Throttling him on your own initiative is both passive-aggressive and might overstep what the owner expects, which could land you in hot water. Don't do that. Here's what you do instead. Go to the owner's office and say the following:
I've been receiving complaints from some of the design staff about their computers slowing down and interfering with their work. The cause of the problem is the Production Director accessing files on designers' computers instead of copying them to his own. The hard drives on designer computers are not designed to accommodate two users accessing the files at once.
These slowdowns will persist unless we take action to correct the problem. If these remote accesses continue, we will need to increase the capacity of each designer's workstation at a cost of $A per machine for a total of $B. Another option would be to limit these remote accesses by implementing an automatic throttling system. That will take C hours of my time [optionally: at cost $D]." The last, which I recommend, is to create a new workflow for the Production Manager that ensures that designer computers are not overloaded.
Back when I was in charge of hiring new programmers for a web development shop, the very first thing I'd do when I got a resume would be to load up the applicant's personal website, if he had one.
No, I didn't look at the aesthetics of the site. I didn't care about the cleanliness of the HTML. The implementation language and web framework didn't matter. I had more important things on my mind: I would find a form, and type hello world' -- ; SHOW TABLES. If the site misbehaved, I'd toss the resume in the trash and adamantly refuse to reconsider it.
Management thought I was nuts --- these were guys with degrees! They came with great recommendations! And they're cheap! What does one bug matter? But with SQL injection being the now #2 security vulnerability, who's whining now?
Attention to correctness is the bedrock trait of a good developer. Everything else comes second; security is just one property of correct code.
You people keep advocating that people solve problems by voting with their dollars.
That doesn't work. You know it doesn't work. That you would like it to work is irrelevant: it doesn't work. There are plenty of things I'd like that aren't part of reality either.
Slashdot Mirror
This isn't your grandfather's JVM.
These days, Java is quite fast and efficient, and there are even a lot of different alternative VMs you can try. Sure, startup time isn't the best, and Swing is still a lumbering, over-engineered, ill-fitting albatross: but these problems don't matter for server applications.
IMHO, the best part is that you can write programs that run on the JVM in a dialect of Lisp and interact seamlessly with other code on the JVM.
The relational model is consistent and easy to work with. It's easy to specify constraints that describe what the data should look like, and to allow several applications to interact with the data. It's also easier to optimize a database when you can describe discrete queries instead of directly following links from program code as you would in a navigational/object/document/etc. database.
Furthermore, application data models aren't all that object-oriented. Most of the time, the manipulated data types (say, "story", "post", and "user") fall into well-defined categories that correspond well to rows in a table. The few mismatches are easily dealt with in application code.
Sure, using an object database might be "easier" for the first 15 minutes, but you'll kick yourself when you have to manipulate it in any kind of sophisticated fashion.
No. It was made by schmoozing investors. None of companies you list has ever turned a profit.
This is the kind of reckless behavior that leads to financial bubbles. Pay should be much lower initially. I doubt Zuckerberg would have worked any less hard (or hacked any fewer email accounts) if he had been paid the mere subsidence wage of $1 million per year.
The page you cited, on column-oriented databases, describes an implementation strategy that's applicable to many types of databases. There are database engines that present a perfectly normal SQL interface to a column store, and there's actually a direct link to LucidDB from the article. Likewise, there's nothing stopping a Cassandra-like database from serializing its on-disk bits the other way around.
Column-orientation has nothing to do with the "NoSQL" databases that are in vogue. It's completely orthogonal. You're talking about using vectors or linked lists when everyone else is arguing over whether to serialize data with XML or JSON.
These slides present a balanced and comprehensive overview of the current state of free databases. Whether you're in the NoSQL camp or not, they're worth reading.
That said, here's my take:
It's currently fashionable to replace MySQL with some "NoSQL" database or other. This trend is driven by two factors:
I haven't seen any consideration from potential "NoSQL" adopters of the benefits of using a good relational database like PostgreSQL. There's a world of difference between it and MySQL, and condemning all relational database systems because of bad experiences with MySQL is like condemning all sandwiches because McDonalds once made you sick. In giving up RDBMSes entirely, these developers lose quite a bit of safety, flexibility, an convenience. It's a huge over-reaction.
This field should not be about following trends, though unfortunately, that's how most people choose which technologies to use: it should be about choosing the best tool for the job. And I believe that in the vast majority of cases, the advantages conferred by a relational system --- enforced integrity, interoperability based on SQL, query flexibility, storage flexibility --- make an RDBMs the best choice for almost any job. If you need sloppier semantics for some cases (for example, "eventual consistency"), you can layer that on top of a robust RDBMs.
Specifics?
The things that made Windows intrinsically insecure have been gone for a decade.
Err, so anything that people do buy, by definition, is good? I don't think so. Try joining the real world.
Congratulations! You've won the "Stupidest Thing Dan Has Read In The Last 24 Hours" award.
Sure, you can flash the BIOS with garbage. But you can restore it with the right equipment -- the hardware itself lives on. You can't physically destroy the computer that way.
Of course it is. But since when are companies socially responsible?
If companies were people, we'd call them sociopaths. No, the law must force companies to abide by acceptable standards of behavior. A company will do everything it can, ethical or not, to maximize profit while staying in the bounds of the law. Therefore, to change behavior, the law must change.
Software should not be able to destroy hardware, period. The GPU's cooling system should be designed to safety operate for sustained periods at peak load --- anything less is artificially crippling the hardware and leads to both security and reliability problems.
Great job, NVIDIA: now, malware can not only destroy your files, but destroy your expensive graphics card as well.
You can't buy one, but if you wink just right, one might follow you home from the bar.
There are technical measures Apple can take to prevent applications from using private frameworks. But Apple doesn't use that approach.
This whole issue smells like selective enforcement of Kafkaesque ever-shifting, secret rules against applications Apple needs an excuse to remove.
Guilt is never absolute.
As for you, bitZtream: you come into every Slashdot discussion carrying the most ignorant, vitriolic, hateful chip on your shoulder that man has ever conceived. In every conceivable circumstance, you come down in favor of money, power, influence, and the elite instead of social justice and basic fairness. You would rather live in the world of medieval crusades than in the one of Locke and Rousseau.
You're either an excellent troll or a miserable human being. I'll give you the benefit of the doubt and assume the former.
At that point, you simply tell the designers, "I am implementing policy as directed. Please address all future complaints regarding this matter directly to the owner."
That's a harmful attitude. I refuse to live in fear. I am a professional and will act like one, not cower at the thought of being the bearer of bad news.
Look: the owner is most likely rational. Irrational people don't run companies, at least not for very long. The owner will listen to reason.
On the off chance that he doesn't, just act as directed above. Note all your actions, and make sure you act professionally. If the owner decides to terminate you, he will be doing so without cause, and you will be able to collect unemployment benefits. Furthermore, your professional behavior will behoove you in the eyes of your next employer.
Passive-aggressiveness is not the right path.
The problem has nothing to do with mutexes or any other process synchronization issue.
Instead, the problem is that the disk in the machine only spins so fast, and can only suck so many bits off the platter at once. Graphic design files are huge, and the disk is probably only barely adequate to handle working with one at a time. If you try to double the demands on the disk, the disk will say "I quit" and make everything wait.
No clever algorithmic improvement can get around that fundamental bottleneck.
Even if that were true (and I can't find any evidence in favor of it), concurrent access would wreck the page cache. That would cause more disk seeks and actual physical IO than the baseline scenario of one user accessing the drive, which would result in a slowdown even with perfect IO prioritization.
/**
* Small program to run a program under OS X with low IO priority
*/
#include <sys/resource.h>
#include <string.h>
#include <stdio.h>
#include <errno.h>
#include <libgen.h>
#include <unistd.h>
int main(int argc, char** argv) {
if(argc < 2 || !strcmp(argv[1], "-h")) {
fprintf(stderr,
"%s command args...: run COMMAND with low IO priority\n",
basename(argv[0]));
return 1;
}
if(setiopolicy_np(IOPOL_TYPE_DISK, IOPOL_SCOPE_PROCESS, IOPOL_THROTTLE)) {
fprintf(stderr, "%s: setiopolicy_np: %s\n",
basename(argv[0]), strerror(errno));
return 1;
}
execvp(argv[1], argv+1);
fprintf(stderr, "%s: %s: %s\n",
basename(argv[0]), argv[1], strerror(errno));
return 1;
}
There's an old saying:
I'm also reminded of the serenity prayer (which doesn't demand a theological interpretation, even):
This twit isn't your problem. Throttling him on your own initiative is both passive-aggressive and might overstep what the owner expects, which could land you in hot water. Don't do that. Here's what you do instead. Go to the owner's office and say the following:
PPTP? People should know better. PPTP is very weak. OpenVPN and IPSec are much better all around.
If he fucking wants a yes man, he can pay for one.
Back when I was in charge of hiring new programmers for a web development shop, the very first thing I'd do when I got a resume would be to load up the applicant's personal website, if he had one.
No, I didn't look at the aesthetics of the site. I didn't care about the cleanliness of the HTML. The implementation language and web framework didn't matter. I had more important things on my mind: I would find a form, and type hello world' -- ; SHOW TABLES. If the site misbehaved, I'd toss the resume in the trash and adamantly refuse to reconsider it.
Management thought I was nuts --- these were guys with degrees! They came with great recommendations! And they're cheap! What does one bug matter? But with SQL injection being the now #2 security vulnerability, who's whining now?
Attention to correctness is the bedrock trait of a good developer. Everything else comes second; security is just one property of correct code.
You don't need a full SQL parser: you just need to keep track of quoted strings, and you can do that with a four-state DFA.
You people keep advocating that people solve problems by voting with their dollars.
That doesn't work. You know it doesn't work. That you would like it to work is irrelevant: it doesn't work. There are plenty of things I'd like that aren't part of reality either.