The best spam filters will eventually be AI's that understand human language. That means that the ultime spam filter will require enough processing power to model human cognitive abilities.
That may not be true, and it goes to the same issue of definition of spam that makes this not an example of the halting problem. Since the final definition of spam is in the eye of the beholder, only a perfect model of a particular person's cognitive processes will be able to definitively distinguish spam from non-spam.
OTOH, some relatively dumb processes, such as Bayesian analysis, have already proved reasonably effective in identifying spam. The kinds of analyses these programs do is actually slow and difficult for humans to do. This leads me to the conclusion that "the best spam filters will eventually be" (and already are) programs that pre-filter email using analyses that humans would find tedious and inefficient. But the final analysis is likely to have to remain up to the human recipient, even given strong AI.
If you doubt that, ask yourself if another person could be 100% reliable at filtering spam for you. The answer is no - I can give counterexamples if you think it's yes. Another person represents about the strongest AI we can hope for, but even if we had stronger (more intelligent?) AI, that doesn't mean it would be able to perfectly predict our thought processes.
Yeah, I though Titan would solve my cooling problems, for sure. So I signed up for web server hosting with minorplanethosting.com, but I'm having a bit of a problem establishing an SSH connection to my server now. To try to diagnose this, I did a ping, and here's what I got back, after waiting 3 hours:
64 bytes from 192.168.44.12: icmp_seq=0 ttl=52 time=10803411.277 msec
I really think the software industry needs to step back and take a breath.
I think it needs more than that. Where my perspective is coming from, though, is getting work done within the confines of the current software industry.
Has this actually occurred in practice? I have yet to see it.
I've seen it in some systems, and I try to develop systems like that. However, it doesn't happen automatically, by any means. A big aspect is being sensible about choice of tools. E.g., the obvious one that most people know: avoid EJBs.
Similarly, most (insert API name) users are seriously tied to their (insert API name).
Yes, but there's a difference. If you imagine an ideal system, it would involve an application written in code which relies on an abstraction boundary that's very close to the needs of the application. Put simply, SQL does not provide such an abstraction - too low-level - whereas writing code that uses objects that are transparently persisted, can.
But using an object persistence mechanism, your code is going to be dependent on that mechanism, as you say. Given that, it's important to make sure that the API you depend on is at least to some extent, under your control. One way to do that is by using an open source framework. Yes, your code will become dependent on that framework, but you have more control over the code you're dependent on, and you won't be writing large amounts of code in a poorly-designed proprietary language over which you have no control whatsoever.
But they add literally millions of lines of code that is opaque to its users, tens of thousands of nuances, and hundreds of new things to learn. How can this be called progress, when complexity is actually going up rather than down?
That's where choice of tools comes in. Avoid overly complex systems, and use open source frameworks. Two systems that I've been working with are Resin (as the application server) and Hibernate, for transparent persistence. The codebases of both don't add up to a million lines, and both are well-conceived and well-written. Code doesn't have to be dependent on Resin unless you particularly want it to, because it's a standards-compliant Java application server - a commodity item, essentially. Code will certainly become dependent on a tool like Hibernate, though. So let's examine that.
Before I began using Hibernate, I worked on and used a number of home-grown persistence frameworks (developed by clients of mine, in some cases with my assistance) of varying degrees of sophistication. Why do companies develop such frameworks, since they're only going to suffer from the issues you mention, of complexity etc? The answer is that the need arises from the kind of code you end up writing without them - for example, you get repetition, which creates maintenance problems, and you want to factor that repetition out. So it's pretty natural for even many naive projects to end up with something that qualifies as a persistence framework, even if only an unsophisticated, simple one. These libraries tend to make life easier for the projects that rely on them, but they tended to be one-off efforts which had many shortcomings.
For companies using such frameworks, switching to a comprehensive open source solution is a no-brainer - it provides better functionality all around, has a larger developer base, and the source is still available for customization, tuning etc. if neccessary.
In this area, a big reason the problems you're concerned about exist is because we rely on databases which impose severe restrictions on the kind of code that can be run "within" the database, but running "outside" the database entails a huge semantic gap between the client language and the database. Middleware such as persistence mechanisms are a fix designed to bridge this gap. Do they add to total complexity? Sure. But they also reduce complexity in some important areas.
But all i made was a general comment. Why did you read so far into it?
There was a progression, remember? Your initial comment was general - and I didn't think it applied in this situation, and I pointed that out. You replied to that with more detail, disagreeing, and I responded to that.
Anyway, the bit that I assume you didn't like was what I said about your logic being like that of salespeople selling systems. I apologize for that comment. I believe the comment is true, in the sense that salespeople do that; but I either shouldn't have mentioned it, or should not have made it seem directed at you.
Logic and a concept of God are not mutually exclusive things. Ask Einstein.
I didn't say that. I said that Descartes' Meditations don't qualify as a logical argument - which is because they violate rules of logic that even Aristotle, Plato etc. would have recognized.
So by your recogning. Aristotle, Plato, Socrates, Zeno, and the whole classical gang has nothing to do with "modern logic"?
No. The issue is the content of the piece in question. However, if you were to raise Zeno's Paradox as an example of a logical argument against the possibility of movement, I would say that it is an incorrect one. However, it is much more subtly incorrect than Descartes.
Just because modern scientific/relativistic/atheist views don't support God, doesn't mean that logic doesn't, or can't. Just look at Aquinas argument for the existance of god, and you see a perfect, beautiful logical constrution.
No-one, including Aquinas, can argue logically for the existence of god - you need to have faith, to believe in things that cannot be proved. If you think otherwise, you don't understand logic, and you don't understand religion.
Aquinas argument for the existance of god, and you see a perfect, beautiful logical constrution.
Aquinas is another example of abuse of the term "logic". For example, although he makes many unsupported assumptions, he argues somewhat logically for the requirement for a first mover, and then jumps to "and this everyone understands to be God". That's not a logical argument, by any definition of the term. All he's doing is observing something that everyone believes. He doesn't connect the argument to the conclusion.
We must have different definitions of "logical". Descartes' Meditations doesn't conform to anything recognized as logic in the modern world. You can call it philosophy, but not logic.
It's full of unsupported statements like "For there can be no doubt that God possesses the power of producing all the objects I am able distinctly to conceive", and early on, he admits that "the belief that there is a God who is all powerful, and who created me, such as I am, has, for a long time, obtained steady possession of my mind". IOW, it is a profession of faith, and at best, a philosophical justification thereof.
So no, Descartes Meditations cannot, by any stretch of the imagination, be described as a "fiercely logical structured argument for the existence of God and reality". A fiercely logical argument would tear that work to shreds, as important as it might be in the history of existential thought.
Re:There's certainly more to it
on
Inside SAIC
·
· Score: 1
Typical definitions of ROT13 talk about its use for obscuring text, to require readers to take some action before they can see the text, e.g. for spoilers or something that not everyone will want to read. That was an old Usenet convention, but even Microsoft programs like Outlook Express support this - it has a menu option which reads something like "Unscramble (ROT13)".
But, to explain the obvious, the usage here on Slashdot tends to be much more as a joke, such as this one, which usually involves pretending that one of the weakest forms of encryption in existence could actually be considered secure, or implying that someone else thinks that (and is therefore a moron), etc.
Now, having told you the secret, I'm afraid I have to kill you...
Whatever it is, I don't think it's really "stock", it's some sort of limited collective ownership and profit sharing.
It's no different from stock in any private company. In fact, in many small private companies, the value of stock is arrived at far more arbitrarily than it is at SAIC - often, by individual negotiation with whoever's buying or selling stock, e.g. when a new top exec is hired.
The size of SAIC's internal market (40K stockholders) makes their stock infinitely more liquid than stock in most private companies. This gives it some of the characteristics of public stock, but not all of them. I think that's what's misleading some people.
I don't understand your point. The U.S. has hundreds of thousands of private companies whose shares cannot be owned by the public. These private companies are considered one of the cornerstones of capitalism - private ownership of the "means of production". What are you saying is the problem with SAIC's approach? The only difference I see is that with 40K employees, they have a larger market for their shares than most private companies.
Re:There's certainly more to it
on
Inside SAIC
·
· Score: 1
ROT13 is so useless and obsolete that I actually never heard of it in the first place.
No offense, but ROT13 is so famous that if you haven't heard of it, you Slashdot-cred just dropped to a negative integer value exceeded only by the karma of the worst and longest-lived trolls. The only way to recover from this abject humiliation is to reformat your hard disk right now and install Linux From Scratch.
Thanks for the details. It seems to me the increased memory bandwidth plus CPU bandwidth would pretty much account for the difference. I don't know anything about that ServerWorks 4-way architecture, but no matter how you slice it on the Xeon side, your Athlons would have 2133MB/s between them, or 1066MB/s each. That can certainly compensate for a system with lower bandwidth but bigger cache. The cache can be thought of as simulating higher memory bandwidth (imperfectly), but at some point, the lower memory bandwidth just can't compete.
I agree the Athlons are impressive, though. AMD provides a nice antidote to the Intel approach of making the CPU ever more complex to achieve performance, whereas AMD seems to take a more straightforward (but smart) approach, and still performs better MHz for MHz.
We took a $13,000 quad P3-Xeon machine, replaced it with a $3,000 dual AthlonMP, and guess what - the loads dropped in *half*.
I'm a big Athlon fan myself, but the above claim doesn't give enough info: what CPU speed and memory bandwidths did the Xeons have? There are some old slow Xeons out there, e.g. down to 500 MHz or so. If you're saying a dual 2GHz outperformed a quad 500MHz, that's not much of a surprise. Also, the ratios of CPU bandwidth to memory bandwidth has improved in recent generations from both manufacturers, which has made a big difference.
Haven't some of these problems already been solved in the RDBMS systems themselves? Are databases really so slow (meaning misapplied, misdesigned, and misconfigured) that all these layers upon layers upon layers of APIs and abstractions are necessary to get the job done?
The goal is to make life easier and more productive for developers, and to handle more complex systems with less code, less repetition, and just generally better-engineered solutions.
Database languages, i.e. the vendor-specific varieties of SQL such as Oracle's PL/SQL, suffer from a number of problems. For a start, they're proprietary, non-standard, vendor-specific languages. Most database users are seriously tied to their database - in most cases, it would be easier to switch server OS than switch databases.
In addition, database languages are not very good programming languages. They've evolved from SQL to become poor, legacy-ridden general-purpose languages which suffer from most of the spaghetti-code problems which languages like Java were designed to alleviate. Not that Java is the most wonderful language ever, but it's a lot better than PL/SQL or TSQL for many tasks.
So, one major goal for these mapping and abstraction layers is to allow a more robust programming language to be used, to provide better functionality and reduce or eliminate dependency on specific databases.
Why not just two racks of computers: one rack with a database cluster, whose database vendor has solved all the data integrity issues, and one rack of apache webservers with gool ol' fashioned CGI programs? Wouldn't the raw simplicity of this configuration pay for itself?
This can work fine for some applications, when the database design requirements are fairly straightforward. It doesn't scale well to more complex applications. Also, even if you're not writing incredibly complex applications, a good mapping layer can still simplify things, reduce the amount of code you have to write, and give you greater flexibility.
Re:Java Data Objects nice but Hibernate Better
on
Java Data Objects
·
· Score: 1
I agree - anyone looking for a Java solution for database access that makes sense, instead of just following the latest corporate craze for cookie-cutter coding, should check out Hibernate.
Does the sawed-off shotgun in the Souyz capsule to fight off wolves violate the provisions that demiliterize space?
[...]
If they can launch a shotgun hundreds of times, then why can't the US launch some lasers?
Simple practical reasons, really - anti-missile lasers are just no good for defending your crew against wolves!
It will be interesting to see the reaction the first time a system like this actually does go wrong. The U.S. could end up killing more of its own citizens than any terrorists ever did... Do you trust the DoD to have automatically controlled missiles flying around in U.S. airspace??
Easy: you made a glib statement that happened, in this case, to no longer be true (perhaps you weren't aware of that). When I pointed this out, you contradicted me and repeated your assertion with a bogus justification, to which I responded.
You're right though, that should have been a clue that I wasn't going to be getting through to you with facts...
The cheap ones are not the fastest nor are they the biggest nor are they the most realiable. the most reliable ones are not the fastest nor are they the cheapest.
No-one said anything about choosing between biggest/fastest/most reliable/cheapest. The words used were "Space/Speed/Reliability/Cheap". IDE RAID offers all of these things.
For most applications, including many very demanding ones, standard 7200rpm IDE drives in a redundant RAID configuration provides excellent speed, reliability, and size, at a very inexpensive price, i.e. meeting all the criteria under discussion.
Most users who setup small cheap IDE Raid systems only tackle the basics of the system.
Two responses here: first, if users setting up their own systems make mistakes, that doesn't say anything about whether IDE RAID is capable of delivering the qualities in question. Second, most users may actually have a better sense of priorities than you're exhibiting - see next point.
In order for it to be reliable you will need 99.999 uptime.
And how did you determine that, exactly? Perhaps you're extrapolating some specific requirement you have in mind, to all possible users? The submitter in this case wants a SOHO solution for video editing. I suspect hotswap power and hotplug drives are irrelevant to him. If a drive fails, he can shut down his system and replace it.
However, as it happens, such redundancy solutions for IDE RAID are not that expensive either, so if you need them, an IDE RAID system still allows you to do it more cheaply than equivalent alternatives.
You're demonstrating a kind of logic I often see in salespeople whose goal is to extract maximum dollars from customers: i.e. you should always purchase the absolute best available, for reasons that tend to be rather vague and emotionally driven such as "you deserve the best", "just in case you need it" or perhaps "it'll impress your friends/colleagues/competitors/golfing buddies". If, instead, you look carefully at the requirements of the application, and specify an appropriate solution, you can save a lot of money without sacrificing any of the required qualities.
An appropriately configured IDE RAID solution provides high capacity, high performance, high reliability, and is inexpensive compared to competing solutions, no matter which way you slice it.
Sorry to have to tell you this, but the ribwich has been discontinued. The animal from which it was made is now extinct. No, not pigs or cows - think something with more legs...
That's not really true any more. IDE RAID solutions tend to be all four of those things. In fact, IDE RAID has finally allowed RAID to live up to its acronym, specifically the "I" for Inexpensive.
On the reliability side, you might have more drive failures than with SCSI, but given that it's RAID, your data isn't at significantly greater risk. And the drives are so cheap, keeping a few extras around is no big deal.
Zero Configuration implies no work done by user.
You contradict that in the rest of your post.
Not quite - the key words in the original post are "After installation". The point is that after initial installation, no additional configuration is required to securely connect to a previously unknown host. That's a big improvement from pre-OE.
Fortunately, a sudden widespread deployment of encryption can get us "over the hump" - going past the point where it is rare enough that security agencies can target people who use it, to the point where wiretapping is pointless and searches on only suspicion-plus-encryption are too expensive.
As you say, with VPNs, SSH, SSL, IPSec etc., don't you think this has already happened? Plenty of pretty ordinary people are engaging in encrypted sessions all the time.
You're right, they've effectively increased the bus width, but they're folding this into the MHz number. I think there's some logic to that, though. It makes some sense to stick to talking about the memory bus width as 64 bits, because that's true even with QDR, it's just that there are two 64-bit ports (read and write). You could describe the situation as:
200 MHz clock x 2 accesses per port per clock cycle x 2 ports
...but if you multiply that out, taking the above units into account, you get 800M accesses/sec, i.e. a "memory access frequency" of 800MHz. The point being that once you've made the choice to stick to talking about a 64-bit bus, and to quote a single figure for the effective memory bus frequency, MHz is a valid unit in that case.
I'm not saying it's ideal, but I think there are both technical and marketing reasons for the choice - it's not totally off-base.
Actually, Caldera has approximately tripled since announcing this lawsuit.
What is the likelihood of Caldera/SCO bosses having dumped their shares en masse while the IP FUD iron was/is still hot?
In other words:
When you can't make money from selling products, because your product is worthless, try to make money from lawsuits.
When you don't have any valid claims to make money from lawsuits - because your product has been irrelevant for years - make a bogus but vaguely plausible claim to temporarily boost your stock price. Immediately sell your shares.
Profit!
Caldera have worked out step 2, people! Incredible!!
Slashdot Mirror
That may not be true, and it goes to the same issue of definition of spam that makes this not an example of the halting problem. Since the final definition of spam is in the eye of the beholder, only a perfect model of a particular person's cognitive processes will be able to definitively distinguish spam from non-spam.
OTOH, some relatively dumb processes, such as Bayesian analysis, have already proved reasonably effective in identifying spam. The kinds of analyses these programs do is actually slow and difficult for humans to do. This leads me to the conclusion that "the best spam filters will eventually be" (and already are) programs that pre-filter email using analyses that humans would find tedious and inefficient. But the final analysis is likely to have to remain up to the human recipient, even given strong AI.
If you doubt that, ask yourself if another person could be 100% reliable at filtering spam for you. The answer is no - I can give counterexamples if you think it's yes. Another person represents about the strongest AI we can hope for, but even if we had stronger (more intelligent?) AI, that doesn't mean it would be able to perfectly predict our thought processes.
64 bytes from 192.168.44.12: icmp_seq=0 ttl=52 time=10803411.277 msec
What do you think could be wrong??
Here's the manufacturer's page for these recorders. They seem pretty expensive, though.
I think it needs more than that. Where my perspective is coming from, though, is getting work done within the confines of the current software industry.
Has this actually occurred in practice? I have yet to see it.
I've seen it in some systems, and I try to develop systems like that. However, it doesn't happen automatically, by any means. A big aspect is being sensible about choice of tools. E.g., the obvious one that most people know: avoid EJBs.
Similarly, most (insert API name) users are seriously tied to their (insert API name).
Yes, but there's a difference. If you imagine an ideal system, it would involve an application written in code which relies on an abstraction boundary that's very close to the needs of the application. Put simply, SQL does not provide such an abstraction - too low-level - whereas writing code that uses objects that are transparently persisted, can.
But using an object persistence mechanism, your code is going to be dependent on that mechanism, as you say. Given that, it's important to make sure that the API you depend on is at least to some extent, under your control. One way to do that is by using an open source framework. Yes, your code will become dependent on that framework, but you have more control over the code you're dependent on, and you won't be writing large amounts of code in a poorly-designed proprietary language over which you have no control whatsoever.
But they add literally millions of lines of code that is opaque to its users, tens of thousands of nuances, and hundreds of new things to learn. How can this be called progress, when complexity is actually going up rather than down?
That's where choice of tools comes in. Avoid overly complex systems, and use open source frameworks. Two systems that I've been working with are Resin (as the application server) and Hibernate, for transparent persistence. The codebases of both don't add up to a million lines, and both are well-conceived and well-written. Code doesn't have to be dependent on Resin unless you particularly want it to, because it's a standards-compliant Java application server - a commodity item, essentially. Code will certainly become dependent on a tool like Hibernate, though. So let's examine that.
Before I began using Hibernate, I worked on and used a number of home-grown persistence frameworks (developed by clients of mine, in some cases with my assistance) of varying degrees of sophistication. Why do companies develop such frameworks, since they're only going to suffer from the issues you mention, of complexity etc? The answer is that the need arises from the kind of code you end up writing without them - for example, you get repetition, which creates maintenance problems, and you want to factor that repetition out. So it's pretty natural for even many naive projects to end up with something that qualifies as a persistence framework, even if only an unsophisticated, simple one. These libraries tend to make life easier for the projects that rely on them, but they tended to be one-off efforts which had many shortcomings.
For companies using such frameworks, switching to a comprehensive open source solution is a no-brainer - it provides better functionality all around, has a larger developer base, and the source is still available for customization, tuning etc. if neccessary.
In this area, a big reason the problems you're concerned about exist is because we rely on databases which impose severe restrictions on the kind of code that can be run "within" the database, but running "outside" the database entails a huge semantic gap between the client language and the database. Middleware such as persistence mechanisms are a fix designed to bridge this gap. Do they add to total complexity? Sure. But they also reduce complexity in some important areas.
Besides, what's th
There was a progression, remember? Your initial comment was general - and I didn't think it applied in this situation, and I pointed that out. You replied to that with more detail, disagreeing, and I responded to that.
Anyway, the bit that I assume you didn't like was what I said about your logic being like that of salespeople selling systems. I apologize for that comment. I believe the comment is true, in the sense that salespeople do that; but I either shouldn't have mentioned it, or should not have made it seem directed at you.
I didn't say that. I said that Descartes' Meditations don't qualify as a logical argument - which is because they violate rules of logic that even Aristotle, Plato etc. would have recognized.
So by your recogning. Aristotle, Plato, Socrates, Zeno, and the whole classical gang has nothing to do with "modern logic"?
No. The issue is the content of the piece in question. However, if you were to raise Zeno's Paradox as an example of a logical argument against the possibility of movement, I would say that it is an incorrect one. However, it is much more subtly incorrect than Descartes.
Just because modern scientific/relativistic/atheist views don't support God, doesn't mean that logic doesn't, or can't. Just look at Aquinas argument for the existance of god, and you see a perfect, beautiful logical constrution.
No-one, including Aquinas, can argue logically for the existence of god - you need to have faith, to believe in things that cannot be proved. If you think otherwise, you don't understand logic, and you don't understand religion.
Aquinas argument for the existance of god, and you see a perfect, beautiful logical constrution.
Aquinas is another example of abuse of the term "logic". For example, although he makes many unsupported assumptions, he argues somewhat logically for the requirement for a first mover, and then jumps to "and this everyone understands to be God". That's not a logical argument, by any definition of the term. All he's doing is observing something that everyone believes. He doesn't connect the argument to the conclusion.
It's full of unsupported statements like "For there can be no doubt that God possesses the power of producing all the objects I am able distinctly to conceive", and early on, he admits that "the belief that there is a God who is all powerful, and who created me, such as I am, has, for a long time, obtained steady possession of my mind". IOW, it is a profession of faith, and at best, a philosophical justification thereof.
So no, Descartes Meditations cannot, by any stretch of the imagination, be described as a "fiercely logical structured argument for the existence of God and reality". A fiercely logical argument would tear that work to shreds, as important as it might be in the history of existential thought.
But, to explain the obvious, the usage here on Slashdot tends to be much more as a joke, such as this one, which usually involves pretending that one of the weakest forms of encryption in existence could actually be considered secure, or implying that someone else thinks that (and is therefore a moron), etc.
Now, having told you the secret, I'm afraid I have to kill you...
It's no different from stock in any private company. In fact, in many small private companies, the value of stock is arrived at far more arbitrarily than it is at SAIC - often, by individual negotiation with whoever's buying or selling stock, e.g. when a new top exec is hired.
The size of SAIC's internal market (40K stockholders) makes their stock infinitely more liquid than stock in most private companies. This gives it some of the characteristics of public stock, but not all of them. I think that's what's misleading some people.
I don't understand your point. The U.S. has hundreds of thousands of private companies whose shares cannot be owned by the public. These private companies are considered one of the cornerstones of capitalism - private ownership of the "means of production". What are you saying is the problem with SAIC's approach? The only difference I see is that with 40K employees, they have a larger market for their shares than most private companies.
No offense, but ROT13 is so famous that if you haven't heard of it, you Slashdot-cred just dropped to a negative integer value exceeded only by the karma of the worst and longest-lived trolls. The only way to recover from this abject humiliation is to reformat your hard disk right now and install Linux From Scratch.
I agree the Athlons are impressive, though. AMD provides a nice antidote to the Intel approach of making the CPU ever more complex to achieve performance, whereas AMD seems to take a more straightforward (but smart) approach, and still performs better MHz for MHz.
I'm a big Athlon fan myself, but the above claim doesn't give enough info: what CPU speed and memory bandwidths did the Xeons have? There are some old slow Xeons out there, e.g. down to 500 MHz or so. If you're saying a dual 2GHz outperformed a quad 500MHz, that's not much of a surprise. Also, the ratios of CPU bandwidth to memory bandwidth has improved in recent generations from both manufacturers, which has made a big difference.
The goal is to make life easier and more productive for developers, and to handle more complex systems with less code, less repetition, and just generally better-engineered solutions.
Database languages, i.e. the vendor-specific varieties of SQL such as Oracle's PL/SQL, suffer from a number of problems. For a start, they're proprietary, non-standard, vendor-specific languages. Most database users are seriously tied to their database - in most cases, it would be easier to switch server OS than switch databases.
In addition, database languages are not very good programming languages. They've evolved from SQL to become poor, legacy-ridden general-purpose languages which suffer from most of the spaghetti-code problems which languages like Java were designed to alleviate. Not that Java is the most wonderful language ever, but it's a lot better than PL/SQL or TSQL for many tasks.
So, one major goal for these mapping and abstraction layers is to allow a more robust programming language to be used, to provide better functionality and reduce or eliminate dependency on specific databases.
Why not just two racks of computers: one rack with a database cluster, whose database vendor has solved all the data integrity issues, and one rack of apache webservers with gool ol' fashioned CGI programs? Wouldn't the raw simplicity of this configuration pay for itself?
This can work fine for some applications, when the database design requirements are fairly straightforward. It doesn't scale well to more complex applications. Also, even if you're not writing incredibly complex applications, a good mapping layer can still simplify things, reduce the amount of code you have to write, and give you greater flexibility.
I agree - anyone looking for a Java solution for database access that makes sense, instead of just following the latest corporate craze for cookie-cutter coding, should check out Hibernate.
It will be interesting to see the reaction the first time a system like this actually does go wrong. The U.S. could end up killing more of its own citizens than any terrorists ever did... Do you trust the DoD to have automatically controlled missiles flying around in U.S. airspace??
Easy: you made a glib statement that happened, in this case, to no longer be true (perhaps you weren't aware of that). When I pointed this out, you contradicted me and repeated your assertion with a bogus justification, to which I responded.
You're right though, that should have been a clue that I wasn't going to be getting through to you with facts...
No-one said anything about choosing between biggest/fastest/most reliable/cheapest. The words used were "Space/Speed/Reliability/Cheap". IDE RAID offers all of these things.
For most applications, including many very demanding ones, standard 7200rpm IDE drives in a redundant RAID configuration provides excellent speed, reliability, and size, at a very inexpensive price, i.e. meeting all the criteria under discussion.
Most users who setup small cheap IDE Raid systems only tackle the basics of the system.
Two responses here: first, if users setting up their own systems make mistakes, that doesn't say anything about whether IDE RAID is capable of delivering the qualities in question. Second, most users may actually have a better sense of priorities than you're exhibiting - see next point.
In order for it to be reliable you will need 99.999 uptime.
And how did you determine that, exactly? Perhaps you're extrapolating some specific requirement you have in mind, to all possible users? The submitter in this case wants a SOHO solution for video editing. I suspect hotswap power and hotplug drives are irrelevant to him. If a drive fails, he can shut down his system and replace it.
However, as it happens, such redundancy solutions for IDE RAID are not that expensive either, so if you need them, an IDE RAID system still allows you to do it more cheaply than equivalent alternatives.
You're demonstrating a kind of logic I often see in salespeople whose goal is to extract maximum dollars from customers: i.e. you should always purchase the absolute best available, for reasons that tend to be rather vague and emotionally driven such as "you deserve the best", "just in case you need it" or perhaps "it'll impress your friends/colleagues/competitors/golfing buddies". If, instead, you look carefully at the requirements of the application, and specify an appropriate solution, you can save a lot of money without sacrificing any of the required qualities.
An appropriately configured IDE RAID solution provides high capacity, high performance, high reliability, and is inexpensive compared to competing solutions, no matter which way you slice it.
Sorry to have to tell you this, but the ribwich has been discontinued. The animal from which it was made is now extinct. No, not pigs or cows - think something with more legs...
That's not really true any more. IDE RAID solutions tend to be all four of those things. In fact, IDE RAID has finally allowed RAID to live up to its acronym, specifically the "I" for Inexpensive.
On the reliability side, you might have more drive failures than with SCSI, but given that it's RAID, your data isn't at significantly greater risk. And the drives are so cheap, keeping a few extras around is no big deal.
Not quite - the key words in the original post are "After installation". The point is that after initial installation, no additional configuration is required to securely connect to a previously unknown host. That's a big improvement from pre-OE.
As you say, with VPNs, SSH, SSL, IPSec etc., don't you think this has already happened? Plenty of pretty ordinary people are engaging in encrypted sessions all the time.
I'm not saying it's ideal, but I think there are both technical and marketing reasons for the choice - it's not totally off-base.
What is the likelihood of Caldera/SCO bosses having dumped their shares en masse while the IP FUD iron was/is still hot?
In other words:
- When you can't make money from selling products, because your product is worthless, try to make money from lawsuits.
- When you don't have any valid claims to make money from lawsuits - because your product has been irrelevant for years - make a bogus but vaguely plausible claim to temporarily boost your stock price. Immediately sell your shares.
- Profit!
Caldera have worked out step 2, people! Incredible!!