It's clearly a PR stunt, but let's face it: it's a massive one. Coordinating ANYTHING in 70 countries is damn hard, and doing so in such a way that, regardless of time zone, 70 countries are all doing it on the same hour is quite stunning.
Hell, just getting 70 theaters in the US to do anything on the same hour is like hearding cats!
What you suggest is quite possible with the current setup. For example, you could simply background many processes while coming up. No need to wait to see how sshd fared, you just keep coming up. Things like named might be touchier so you wait for them.
This is all doable with the current system. Adding hooks for such "backgrounding" to be controled and reported on as normal would be nice, but is clearly not REQUIRED. But, even if you did do that, it would be far lighter weight than replacing the whole thing with python!
Ok, so I'm not the best person to say this because anyone who looks for my publishing credits will immediately realize that I'm a "Perl guy" and thus, I must hate Python (I'm not really a Perl guy, and I don't hate Python, but that's beside the point). I'll go on anyway because this is important, and folks who don't do sysadmin for a living may not have had to think about this.
init itself is so lightweight and small that it rarely, if ever, fails. This is a good thing, since it's init's job to start a ton of very heavy-weight services.
That said, I see the logic in bloating init with some of the features that are almost always implemented in a distribution built around it. For example, it would be nice to see init perform some service tracking such that it could be told directly to kill a service, and it could do so.
Keep in mind that every time you increase the size of init, you remove a class of systems that can now no longer use it because of it's footprint. This matters a lot for some kinds of embeded systems that have just enough brains (that is, RAM and installed libraries/software) that it makes sense to have init today.
You certainly could not achieve this minimal-growth by re-coding init in Python, Java, Perl, Lisp or any other high-level language. That's not a slam against high-level languages, it's a simple fact of life that their flexibility comes with costs.
As for the shell-script init-scripts, I certainly feel that all of that should be moved out of init's domain. Each application should have a control program (like apachectl) which knows how to start it, stop it, get status, reload configs, etc. That program can be written in C for speed; a high-level, general purpose language for ease of maintenance; or even in shell. But, the point is that that should not be a constraint of init.
init, might well provide a library and/or command-line tools to make writing those controlers easier and more modular, but I don't think there should be any REQUIREMENT that your program know anything more than the calling conventions of an "init controler". The more constraints you heap on, the less software is going to ship ready to integrate with your init system, and that way lies far too much integration work to create a workable OS (and thus MORE variants between distributions, not less).
Once you've done all of that, THEN you can think about the high-level glue so that things like a desktop integrate better.
You've taken that one sentence about footprint (which I will grant should have been the clue) out of context.
I think I would have respected this as art more if he'd just taken the guts of the computer out, and made a spider out of non-functional computer parts. But, to make a case out of computer parts that doesn't even do what you wanted it to (he's not getting the CD performace he wanted, for example) seems like a failure to be brushed aside and tried again....
As for the Slashdot article, it included the comment "one of the more impressive case mods I've seen", which tells me to expect a cool, modified case on a functional machine, not a crippled PC-as-art.
Again, he's free to go to it and have fun, but I just don't get why it's "impressive" when it failed in its own stated goals.
I'm neither contradicting myself nor trolling
on
The "Spider Case"
·
· Score: 1
How so? I said: "Making art out of a computer is all well and good"
I think that's a fair statement. Then I said:
"but this case is uninteresting for anything other than artistic reasons"
And that too is true. It's not that I begrudge the guy making art, but making art out of a computer (or a home, or anything which starts off functional) is generally judged on the basis of its form AND its function. In terms of form, I'm not terribly impressed with this, but perhaps some are, and that's cool.
In terms of function, it lacks even the original functionality of the parts he started with (he had to throw out the USB2 card, for example).
I don't understand why so few people get that you can appreciate something for its artistic value while, at the same time, critiquing its functionality. I would not do this with a painting, but then a painting doesn't start off with any sort of useful functionality. If, on the other hand, you painted a picture on a canvas sail, and that made the boat go slower, I'd say you failed to manage your medium and balance form with function.
This isn't about him, it's about Slashdot. If you read the blurb that showed up on the front page, it certianly made this sound like a functional case-mod, not a piece of art that slows down a machine. I find elegance in combining form and function, and when someone sacrifices function for form, I have to ask... why? Were they just unable to figure out a way to combine the two?
Architects and engineers learn this lesson early on. Apple's computers are a wonderful example. They tend to have lovely cases (if you agree with the their aesthetics) and yet they are universally more functional than the case that this article is about. I'm also impressed with Alienware's cases, and they too are functional.
Why should we laud someone who can't blend form and function when there are many who can?
That said, if this guy likes his case, then more power to him. I hope it gets him some attention, or at least makes him happy with his environment. But is it worth a Slashdot article, or should we look for someone who has spent more time on a more functional piece of computer-case-art?
Making art out of a computer is all well and good, but this case is uninteresting for anything other than artistic reasons. He had to sacrifice quite a bit of performance and flexibility to get this the shape he wanted.
What's more it's not very workable footprint wise.
As far as I'm concerned the ultimate case-mod would be getting a sufficiently cooled, shoebox-sized system that had room for at least 1 AGP and 3 PCI cards. Then I'd be happy. If you want to paint flames on the side, more power to you, but I don't care what color my GHz are, I just want a lot of 'em;-)
Agreed, and what's more it's the job of the FBI to enforce the law, which is exactly what they are doing. Hopefully the courts will find that the PATRIOT act is unconstitutional as a result of this, but I refuse to blame the FBI for enforcing the law, when the point on which it is unreasonable is constitutional, not moral.
If the law said, "kill people who don't agree with the President," then I would say that it is the duty of individual agents of the FBI to refuse to implement that law, but that is a moral decision that is called for only by the extreme results of enforcement. In this case, I would be loath to enforce the law, but if my supervisor insisted that I do so, I would comply and let the courts sort it out.
That's not to say that Congress should be testing the limits of the constitution at every turn, and trying to get away with anything that goes unchallenged in the courts. Congress and the President need to be held accountable for the abuses that they used tragedy to implement. I would have bought into the idea that these were extreme measures, required to deal with extreme situations, but if that were the case, then no one would have been arguing to remove the (originally proposed) expiration date on PATRIOT.
What if you just want perl to run fast on Apache? That's what I'm using it for.
Then mod_perl is the wrong choice.
However, I suspect you have other constraints that you're not stating that make it more ideal, but still leave other tools (layered on top of mod_perl) as better choices.
First off, if you just need to add two numbers really fast and return the result via HTTP, you should be writing a C module for apache that does what you want. No need to invoke Perl there.
If you wanted to write something more complex that could take advantage of Perl's goodies, then great, but you probably want to look into something like HTML::Mason or perhaps one of the lighter weight tools that are layered on top of mod_perl, and make your code MUCH more maintainable, and allow you to avoid inventing wheels all over again.
mod_perl's CGI handling is a nice patch for people who already had a base of CGI code and needed to make it persistant, but I think it's usually worth it to just take that code-base and re-implement it on top of something that already does some of the work for you.
What you suggest (a poll for allowing NYT links) is interesting, but I'd find a "Cowboy Neal option" quite useful, and rather than your suggestion that it not be included, I'd like to suggest that it should ALWAYS be included.
Why?
I see that option as statistically equivalent to "don't care" and that's useful data. I always used to look at the CN option first to guage the margin of error for a poll. If the CN was high, then the poll probably wasn't taken very seriously. If it was low, the results were generally fairly representitive of what people thought.
In general I consider any poll to be accurate only + or - the CowboyNeal result. I just wish CowboyNeal (or at least a "don't care") were an option on national elections, and no one was allowed to take an office if they received a count less than the the CN count.
Re:general note: what is it
on
Practical mod_perl
·
· Score: 5, Informative
This is the common view of mod_perl, but it's also rather limited.
A more general view of mod_perl is that it's the Perl interface to the apache API. This means a lot of things to a lot of different kinds of developers, since the Apache API is so rich. It can be used for any of the following things:
Writing one-shot programs that run "close to the server" (this is the primary, and rather limited use of mod_perl).
Handling error conditions (e.g. file not found or failed execution)
Writing your own page-generation caching system.
Writing a content management system (e.g. bricolage)
Redirecting requests. One example would be taking a request, examining the cookies, and redirecting based on "user".
Proxying. You might, for example, like to proxy part of a request to one back-end and another part to another back-end with a minimum of overhead. That's easy with mod_perl and doesn't require as much work as you might think.
SSL certificate integration with database of users.
You can go on and on with this. The bottom line is that mod_perl isn't really an application builder's toolkit, so much as it's the toolkit-builder's toolkit.
So many times, I've heard people try to compare mod_perl to full-fledged content management systems, and that's just not what mod_perl is. In fact, it's not even a templating system like PHP. It's just the Apache API mocked up into Perl. Granted, there's more than that. There are some utility features, but if you want templating, look at HTML::Mason. If you want content management, look at bricolage. These are systems build on top of mod_perl, and they will reduce (vastly) the number of wheels you need to re-invent.
"Address-harvesting software must not be supplied, acquired or used"
Making a class of software illegal regardless of its use or usefullness is wrong. Period.
As to address-harvesting, I've written my share of address-harvesting software that was for perfectly legitimate reasons (statistics usually, though for anti-spam reasons in one case).
There is good in the bill though. It seeks to regulate a few things oddly (e.g. requiring "unsubscribe" facilities is pointless when almost all mailings are one-time events) but does avoid trying to regulate the way mail is formed and does leave legitimate forgery available to the average mail sender. There is one common form of forgery that this makes illegal, and I might have to have a talk with our legal counsul about it (since the law covers mail originating in Australia, not just mail recieved there). Our anti-virus software may be violating this law...
Still, it's less draconian and less spam-industry-friendly than many ill-conceived laws I've seen.
I'd still rather that governments stay out of it, or just fund the open source development of reputation-based anti-spam mail server software, but I guess that's a lost battle and everyone is too spooked by spam to see the long-term anymore.
I wasn't talking about DAO, I was talking about the database that the article refered to. I consider it a shoestring memory manager, which is interesting in so far as it goes. I'm not dissing their hard work, just the bozo who thought he'd get the project noticed by casting it as a mysql-killer in a Slashdot article submission.
What's more, I was pointing out that any abstraction layer will come with a cost (not bad per se). So, I'd rather get a giant abstraction layer (Oracle) get those costs out of the way early and THEN worry about my app.
If I find that I'm constrained by the database's throughput, I might well choose to use something like this as a cache store and perhaps as a caching proxy for writes. But, that happens after you get the application working. Anything else is premature optimization, and is thus the enemy of efficient development.
Now, in general, I'll ACTUALLY choose MySQL because I don't care about database performance enough to buy a giant machine that I can stuff the entire DB into RAM on (which is the only way Oracle outperforms anything). MySQL is fast in the normal case, far easier to admin, flexible in terms of which features I want to suffer performance penalties for or not and in my 5 years or so experience with it, rock-solid in every case except total media failure (Oracle has burned me several times just because the machine it was on crashed, which is not supposed to be possible, but there it is).
You're choosing how to read misquotes quite carefully.
Also, please don't argue with me over what I'm trying to argue... for the time being, the state still considers me competent enough to let me have a keyboard, so let's assume that I do, in fact, know what I'm arguing.
If you feel that someone's public service should be considered a locked door, then please be prepared to be thrown in jail the next time you come into my place of business.
Meanwhile, back in the real world, you need to defend yourself against those forms of noise in the signal that you don't like. Making a law out of a fourier transform is sort of stupid.
If you use Oracle and your database fits in-core you can tune it so that Oracle only writes to disk to commit the logs (which is a linear append) and to occasionaly synchronize the in-core version of the database (which is a block memory-to-disk transfer that the OS can optimize very nicely). This gives you much of the performance benefit of the in-memory only database, preserves scalability, is language neutral and doesn't require heavy indirection in order to move to another database later.
I'm not a big fan of Oracle, but if I needed it, I'd use it, not a shoestring memory-manager.
"anyone so concerned about future-proofing their code would insure their business logic is using a nice polymorphic OO design"
First off, I just asked about scalability to data-sizes greater than core. I don't even see that as ADEQUATE concern over "future-proofing", much less going out of my way.
Second, just because I have a "nice polymorphic OO design" doesn't mean my application is simple or that re-writing that layer will be painless. Unless this database design has significant wins OTHER than being memory-resident only (which is IMHO a drawback, but a survivable one), then I don't see what it has going for it other than being the new kid on the block.
Well, those numbers are a tad misleading. A lot of area codes are worthless. If, for example, you want every area code for the greater Boston area (including suburbs and surrounding cities), it will cost you $75 (508, 781, 617). Nice haul for $75...
Your system might be fine for my project TODAY, but what happens when I've tied my project to ITS funky interface and TOMORROW, I find that my data-set has grown to a size that is not managable in-core?
Do I have an easy out, or do I re-write my whole application?
Bravo! I'm glad someone is paying attention to this. Just because we happen to have a community that expects the patch to be available 20 seconds before the first person finds it is no reason to measure Linux and Windows on different yard-sticks. If the OpenSSH team can get a patch to vendors and vendors release a fix within a day or two, then that's what we should expect from Windows. And when Windows doesn't keep to that standard, we should all wonder why.
I don't understand why people want to make spammers into criminals. They're no more criminals than people who send me junk fliers at home. What I want is a toold for electronic circumvention of spam, not a set of laws that I might some day run afoul of by accident. In fact, I'd much rather that it be legal to send ANY bits from ANY node on the Internet to ANY other node. Why should some particular bit-pattern or rate do any more than get you in trouble with your ISP (if it utilizes too much bandwidth or tarnishes their reputation) or cause your bits to not be recieved (if someone filters your spam into the bit-bucket).
We can solve the spam problem tomorrow if all of the ISPs in the world just stop waiting for someone else to do it, and start requiring signed TLS sessions that are tracked and assigned a reputation. Then it's easy for software to determine how "reasonable" a given identity is, and filter appropriately. Done. No more spam.
I'd have to read the decision to be sure on that (e.g. how limited is that decision/precident), but the laws remain on the books in Mass. (so either you would not be convicted, or could appeal) and it doesn't change the value of the analogy.
First off, I wasn't talking about locks and breaking/entering. I was talking about providing a public space and/or service.
By putting up a port on the Internet that speaks a publicly defined protocol for open exchange of messages (e.g. SMTP) you have done the same thing as opening your front door and putting out a sign saying "Hello, welcome to my front door version 2.8, please follow the 'walk in and leave any package you like' protool". That's hardly the same as "leaving your door unlocked".
I dislike spam, but I'm not going to say that it's WRONG. I just want to stop it coming to me and anyone else who doesn't want it by establishing a technical means of determining who we do and do not want to let through the door, NOT by saying "it's illegal for you to come through my door if you're carrying a 'bad' package" because 'bad' is too vague and subject to abusive enforcement.
His spam filtering, BTW, had nothing to do with it, because no reasonable person can be expected to know that he has spam-filtering or how it works. If you put a dog in the house who chases out "bad package holders" and it fails to chase out someone that you wanted it to chase out, you don't get to blame the package-bearer. You need a dog that will learn to recognize what kinds of packages and what kind of delivery persons you want... such is possible, and not even very hard. We just need to get a critical mass of mail systems to stop accepting unsigned SMTP (e.g. non-TLS) connections.
Slashdot Mirror
It's clearly a PR stunt, but let's face it: it's a massive one. Coordinating ANYTHING in 70 countries is damn hard, and doing so in such a way that, regardless of time zone, 70 countries are all doing it on the same hour is quite stunning.
Hell, just getting 70 theaters in the US to do anything on the same hour is like hearding cats!
What you suggest is quite possible with the current setup. For example, you could simply background many processes while coming up. No need to wait to see how sshd fared, you just keep coming up. Things like named might be touchier so you wait for them.
This is all doable with the current system. Adding hooks for such "backgrounding" to be controled and reported on as normal would be nice, but is clearly not REQUIRED. But, even if you did do that, it would be far lighter weight than replacing the whole thing with python!
Ok, so I'm not the best person to say this because anyone who looks for my publishing credits will immediately realize that I'm a "Perl guy" and thus, I must hate Python (I'm not really a Perl guy, and I don't hate Python, but that's beside the point). I'll go on anyway because this is important, and folks who don't do sysadmin for a living may not have had to think about this.
init itself is so lightweight and small that it rarely, if ever, fails. This is a good thing, since it's init's job to start a ton of very heavy-weight services.
That said, I see the logic in bloating init with some of the features that are almost always implemented in a distribution built around it. For example, it would be nice to see init perform some service tracking such that it could be told directly to kill a service, and it could do so.
Keep in mind that every time you increase the size of init, you remove a class of systems that can now no longer use it because of it's footprint. This matters a lot for some kinds of embeded systems that have just enough brains (that is, RAM and installed libraries/software) that it makes sense to have init today.
You certainly could not achieve this minimal-growth by re-coding init in Python, Java, Perl, Lisp or any other high-level language. That's not a slam against high-level languages, it's a simple fact of life that their flexibility comes with costs.
As for the shell-script init-scripts, I certainly feel that all of that should be moved out of init's domain. Each application should have a control program (like apachectl) which knows how to start it, stop it, get status, reload configs, etc. That program can be written in C for speed; a high-level, general purpose language for ease of maintenance; or even in shell. But, the point is that that should not be a constraint of init.
init, might well provide a library and/or command-line tools to make writing those controlers easier and more modular, but I don't think there should be any REQUIREMENT that your program know anything more than the calling conventions of an "init controler". The more constraints you heap on, the less software is going to ship ready to integrate with your init system, and that way lies far too much integration work to create a workable OS (and thus MORE variants between distributions, not less).
Once you've done all of that, THEN you can think about the high-level glue so that things like a desktop integrate better.
You've taken that one sentence about footprint (which I will grant should have been the clue) out of context.
I think I would have respected this as art more if he'd just taken the guts of the computer out, and made a spider out of non-functional computer parts. But, to make a case out of computer parts that doesn't even do what you wanted it to (he's not getting the CD performace he wanted, for example) seems like a failure to be brushed aside and tried again....
As for the Slashdot article, it included the comment "one of the more impressive case mods I've seen", which tells me to expect a cool, modified case on a functional machine, not a crippled PC-as-art.
Again, he's free to go to it and have fun, but I just don't get why it's "impressive" when it failed in its own stated goals.
How so? I said: "Making art out of a computer is all well and good"
I think that's a fair statement. Then I said:
"but this case is uninteresting for anything other than artistic reasons"
And that too is true. It's not that I begrudge the guy making art, but making art out of a computer (or a home, or anything which starts off functional) is generally judged on the basis of its form AND its function. In terms of form, I'm not terribly impressed with this, but perhaps some are, and that's cool.
In terms of function, it lacks even the original functionality of the parts he started with (he had to throw out the USB2 card, for example).
I don't understand why so few people get that you can appreciate something for its artistic value while, at the same time, critiquing its functionality. I would not do this with a painting, but then a painting doesn't start off with any sort of useful functionality. If, on the other hand, you painted a picture on a canvas sail, and that made the boat go slower, I'd say you failed to manage your medium and balance form with function.
This isn't about him, it's about Slashdot. If you read the blurb that showed up on the front page, it certianly made this sound like a functional case-mod, not a piece of art that slows down a machine. I find elegance in combining form and function, and when someone sacrifices function for form, I have to ask... why? Were they just unable to figure out a way to combine the two?
Architects and engineers learn this lesson early on. Apple's computers are a wonderful example. They tend to have lovely cases (if you agree with the their aesthetics) and yet they are universally more functional than the case that this article is about. I'm also impressed with Alienware's cases, and they too are functional.
Why should we laud someone who can't blend form and function when there are many who can?
That said, if this guy likes his case, then more power to him. I hope it gets him some attention, or at least makes him happy with his environment. But is it worth a Slashdot article, or should we look for someone who has spent more time on a more functional piece of computer-case-art?
Making art out of a computer is all well and good, but this case is uninteresting for anything other than artistic reasons. He had to sacrifice quite a bit of performance and flexibility to get this the shape he wanted.
;-)
What's more it's not very workable footprint wise.
As far as I'm concerned the ultimate case-mod would be getting a sufficiently cooled, shoebox-sized system that had room for at least 1 AGP and 3 PCI cards. Then I'd be happy. If you want to paint flames on the side, more power to you, but I don't care what color my GHz are, I just want a lot of 'em
Agreed, and what's more it's the job of the FBI to enforce the law, which is exactly what they are doing. Hopefully the courts will find that the PATRIOT act is unconstitutional as a result of this, but I refuse to blame the FBI for enforcing the law, when the point on which it is unreasonable is constitutional, not moral.
If the law said, "kill people who don't agree with the President," then I would say that it is the duty of individual agents of the FBI to refuse to implement that law, but that is a moral decision that is called for only by the extreme results of enforcement. In this case, I would be loath to enforce the law, but if my supervisor insisted that I do so, I would comply and let the courts sort it out.
That's not to say that Congress should be testing the limits of the constitution at every turn, and trying to get away with anything that goes unchallenged in the courts. Congress and the President need to be held accountable for the abuses that they used tragedy to implement. I would have bought into the idea that these were extreme measures, required to deal with extreme situations, but if that were the case, then no one would have been arguing to remove the (originally proposed) expiration date on PATRIOT.
What if you just want perl to run fast on Apache? That's what I'm using it for.
Then mod_perl is the wrong choice.
However, I suspect you have other constraints that you're not stating that make it more ideal, but still leave other tools (layered on top of mod_perl) as better choices.
First off, if you just need to add two numbers really fast and return the result via HTTP, you should be writing a C module for apache that does what you want. No need to invoke Perl there.
If you wanted to write something more complex that could take advantage of Perl's goodies, then great, but you probably want to look into something like HTML::Mason or perhaps one of the lighter weight tools that are layered on top of mod_perl, and make your code MUCH more maintainable, and allow you to avoid inventing wheels all over again.
mod_perl's CGI handling is a nice patch for people who already had a base of CGI code and needed to make it persistant, but I think it's usually worth it to just take that code-base and re-implement it on top of something that already does some of the work for you.
What you suggest (a poll for allowing NYT links) is interesting, but I'd find a "Cowboy Neal option" quite useful, and rather than your suggestion that it not be included, I'd like to suggest that it should ALWAYS be included.
Why?
I see that option as statistically equivalent to "don't care" and that's useful data. I always used to look at the CN option first to guage the margin of error for a poll. If the CN was high, then the poll probably wasn't taken very seriously. If it was low, the results were generally fairly representitive of what people thought.
In general I consider any poll to be accurate only + or - the CowboyNeal result. I just wish CowboyNeal (or at least a "don't care") were an option on national elections, and no one was allowed to take an office if they received a count less than the the CN count.
A more general view of mod_perl is that it's the Perl interface to the apache API. This means a lot of things to a lot of different kinds of developers, since the Apache API is so rich. It can be used for any of the following things:
You can go on and on with this. The bottom line is that mod_perl isn't really an application builder's toolkit, so much as it's the toolkit-builder's toolkit.
So many times, I've heard people try to compare mod_perl to full-fledged content management systems, and that's just not what mod_perl is. In fact, it's not even a templating system like PHP. It's just the Apache API mocked up into Perl. Granted, there's more than that. There are some utility features, but if you want templating, look at HTML::Mason. If you want content management, look at bricolage. These are systems build on top of mod_perl, and they will reduce (vastly) the number of wheels you need to re-invent.
Start of?!
Take a look at the lawsuits of the last 80 years in US business.
Ok, so this bill has some bad:
"Address-harvesting software must not be supplied, acquired or used"
Making a class of software illegal regardless of its use or usefullness is wrong. Period.
As to address-harvesting, I've written my share of address-harvesting software that was for perfectly legitimate reasons (statistics usually, though for anti-spam reasons in one case).
There is good in the bill though. It seeks to regulate a few things oddly (e.g. requiring "unsubscribe" facilities is pointless when almost all mailings are one-time events) but does avoid trying to regulate the way mail is formed and does leave legitimate forgery available to the average mail sender. There is one common form of forgery that this makes illegal, and I might have to have a talk with our legal counsul about it (since the law covers mail originating in Australia, not just mail recieved there). Our anti-virus software may be violating this law...
Still, it's less draconian and less spam-industry-friendly than many ill-conceived laws I've seen.
I'd still rather that governments stay out of it, or just fund the open source development of reputation-based anti-spam mail server software, but I guess that's a lost battle and everyone is too spooked by spam to see the long-term anymore.
I wasn't talking about DAO, I was talking about the database that the article refered to. I consider it a shoestring memory manager, which is interesting in so far as it goes. I'm not dissing their hard work, just the bozo who thought he'd get the project noticed by casting it as a mysql-killer in a Slashdot article submission.
What's more, I was pointing out that any abstraction layer will come with a cost (not bad per se). So, I'd rather get a giant abstraction layer (Oracle) get those costs out of the way early and THEN worry about my app.
If I find that I'm constrained by the database's throughput, I might well choose to use something like this as a cache store and perhaps as a caching proxy for writes. But, that happens after you get the application working. Anything else is premature optimization, and is thus the enemy of efficient development.
Now, in general, I'll ACTUALLY choose MySQL because I don't care about database performance enough to buy a giant machine that I can stuff the entire DB into RAM on (which is the only way Oracle outperforms anything). MySQL is fast in the normal case, far easier to admin, flexible in terms of which features I want to suffer performance penalties for or not and in my 5 years or so experience with it, rock-solid in every case except total media failure (Oracle has burned me several times just because the machine it was on crashed, which is not supposed to be possible, but there it is).
You're choosing how to read misquotes quite carefully.
Also, please don't argue with me over what I'm trying to argue... for the time being, the state still considers me competent enough to let me have a keyboard, so let's assume that I do, in fact, know what I'm arguing.
If you feel that someone's public service should be considered a locked door, then please be prepared to be thrown in jail the next time you come into my place of business.
Meanwhile, back in the real world, you need to defend yourself against those forms of noise in the signal that you don't like. Making a law out of a fourier transform is sort of stupid.
Such indirection comes at a cost.
If you use Oracle and your database fits in-core you can tune it so that Oracle only writes to disk to commit the logs (which is a linear append) and to occasionaly synchronize the in-core version of the database (which is a block memory-to-disk transfer that the OS can optimize very nicely). This gives you much of the performance benefit of the in-memory only database, preserves scalability, is language neutral and doesn't require heavy indirection in order to move to another database later.
I'm not a big fan of Oracle, but if I needed it, I'd use it, not a shoestring memory-manager.
"anyone so concerned about future-proofing their code would insure their business logic is using a nice polymorphic OO design"
First off, I just asked about scalability to data-sizes greater than core. I don't even see that as ADEQUATE concern over "future-proofing", much less going out of my way.
Second, just because I have a "nice polymorphic OO design" doesn't mean my application is simple or that re-writing that layer will be painless. Unless this database design has significant wins OTHER than being memory-resident only (which is IMHO a drawback, but a survivable one), then I don't see what it has going for it other than being the new kid on the block.
Sounds like you're saying that I shoudl take a leap of faith that my application which fits in core today won't have to scale... no thanks.
Well, those numbers are a tad misleading. A lot of area codes are worthless. If, for example, you want every area code for the greater Boston area (including suburbs and surrounding cities), it will cost you $75 (508, 781, 617). Nice haul for $75...
You're missing the point.
Your system might be fine for my project TODAY, but what happens when I've tied my project to ITS funky interface and TOMORROW, I find that my data-set has grown to a size that is not managable in-core?
Do I have an easy out, or do I re-write my whole application?
Bravo! I'm glad someone is paying attention to this. Just because we happen to have a community that expects the patch to be available 20 seconds before the first person finds it is no reason to measure Linux and Windows on different yard-sticks. If the OpenSSH team can get a patch to vendors and vendors release a fix within a day or two, then that's what we should expect from Windows. And when Windows doesn't keep to that standard, we should all wonder why.
I don't understand why people want to make spammers into criminals. They're no more criminals than people who send me junk fliers at home. What I want is a toold for electronic circumvention of spam, not a set of laws that I might some day run afoul of by accident. In fact, I'd much rather that it be legal to send ANY bits from ANY node on the Internet to ANY other node. Why should some particular bit-pattern or rate do any more than get you in trouble with your ISP (if it utilizes too much bandwidth or tarnishes their reputation) or cause your bits to not be recieved (if someone filters your spam into the bit-bucket).
We can solve the spam problem tomorrow if all of the ISPs in the world just stop waiting for someone else to do it, and start requiring signed TLS sessions that are tracked and assigned a reputation. Then it's easy for software to determine how "reasonable" a given identity is, and filter appropriately. Done. No more spam.
I'd have to read the decision to be sure on that (e.g. how limited is that decision/precident), but the laws remain on the books in Mass. (so either you would not be convicted, or could appeal) and it doesn't change the value of the analogy.
Nope, your annalogy is broken.
First off, I wasn't talking about locks and breaking/entering. I was talking about providing a public space and/or service.
By putting up a port on the Internet that speaks a publicly defined protocol for open exchange of messages (e.g. SMTP) you have done the same thing as opening your front door and putting out a sign saying "Hello, welcome to my front door version 2.8, please follow the 'walk in and leave any package you like' protool". That's hardly the same as "leaving your door unlocked".
I dislike spam, but I'm not going to say that it's WRONG. I just want to stop it coming to me and anyone else who doesn't want it by establishing a technical means of determining who we do and do not want to let through the door, NOT by saying "it's illegal for you to come through my door if you're carrying a 'bad' package" because 'bad' is too vague and subject to abusive enforcement.
His spam filtering, BTW, had nothing to do with it, because no reasonable person can be expected to know that he has spam-filtering or how it works. If you put a dog in the house who chases out "bad package holders" and it fails to chase out someone that you wanted it to chase out, you don't get to blame the package-bearer. You need a dog that will learn to recognize what kinds of packages and what kind of delivery persons you want... such is possible, and not even very hard. We just need to get a critical mass of mail systems to stop accepting unsigned SMTP (e.g. non-TLS) connections.
Ahem! That should read "Joss Whedon" not "Jess Whedon". Hopefully the /. editors will fix the typo if the question is sent to Neil....