"So instead of having private firms that you could trust because they would be competing for your trust in food safety"
Who the hell tells you they would be competing for my trust?
In first instance those firms would be competing for MONEY; not even my money, but money. If they get more money by covering the irregularities of [big producer] than by getting my trust, so be it. That's not a supposition; that's a fact (tobacco companies, anyone?).
If that wasn't enough, private firms wouldn't even be competing for money, because firms have no will. Their CEOs would be trying to get money -for them, not the firms. So if a given CEO thinks it can get more of it by not only fucking me but even fucking their own companies in the while, so be it. That's not a supposition; that's a fact (Enron, anyone?).
And if you think "oh, no, that wouldn't happen", please go out the cavern you have been into for the last two centuries and get in touch with reality.
"Lets imagine a scenario with no public schools at all."
There's no need to imagine. That *was* the case in the whole world not so many ages ago.
And you know what? Alphabetization levels were horrible.
"People would have a greater deal of specialization which would allow them to better perform in the workplace."
Of course yes. Everybody knows people are not human beings with a soul to be enlighted but ants or replaceable machines.
"Lets face it, why should Joe Sixpack who is really great at, say, diesel mechanics have to read Shakespeare [...] Most people should not go to college"
"If they say no during both, and the consolidation attempts with the council fails, the proposal is dead and the commission will not bring it up again, unless the EP wants it."
But once the ACTA is rejected twice, the comission can bring back the ACTB, the ACTC, the ACTD and so till it's passed. Don't you remember the (still not dead) issue about software patents?
"And I already explained why it is possible. Ill-defined statements often don't have a defined truth value."
That's not a counter-argument: he already knows that ill-defined statements often don't have a defined truth value. What he holds is that no matter what, your mind tubes are forced to choose one anyway.
For really ill-defined statements, like "number seven is either green or red" you will choose the question to be false because you declare the attribute to be unholdable for the subject. With regards of existance (or more strictly, being) there's no way to get off the question: things either are or are not. Since it's a proper question the one about "do god exists or it doesn't?" there's no way for a human mind to not answer to itself either "yes, it does exist" or "no, it doesn't exist", even if the question really wouldn't hold a defined value of truth.
"Does nature give to human beings a monopoly over their ideas? No."
But of course yes!!! Proof: What am I thinking now? You don't know, uh? You don't know because I hold an absolut monopoly on my ideas.
What natura doesn't allow is for a monopoly on *public* knowledge -and that's because everyone holds a monopoly on his own mind: once it's made public and so I gain knowledge of it, you can't take it from me.
"Because Linux software automatically runs executables downloaded from the Internet, right?"
Interesting question. Is there anything really impending Linux to automatically run executables downloaded from the Internet? I bet not.
So, on one hand we have that "the year of Linux on desktops" haven't reached yet because "cumbersome" limitations that make it "dificult for average joe" to use it, so "Linux isn't attacked by so many threats because it's more profitable to attack the wider Windows base"; in the other hand, as per current "analysis" from "experts" in order for Linux to take the desktop it should implement the same Windows easiness that allows for both "average joe" and the worms to take advantage of the platform.
Of course, the idea that successfully operating a (basically) complete turing machine requires some kind of training is out of question.
"Let companies keep more of what they earn and they'll feel more comfortable hiring people, it's that simple."
Maybe. But the only you can insure that way is that if companies keep more of what they earn, well, they'll keep more of what they earn, not that they'll expend that on hiring you.
Maybe they'll use that to pay better bonuses to the CEO. Maybe they'll use that to pay dividends to their shareholders. Maybe they'll use that to hire more cheap off-shored or HB1 labour.
So, why do you think that if companies keep more of what they earn they are going to gladly expend that on you?
"Using a source control system is orthogonal to keeping a copy of the source code with the data."
Yes, in that one thing doesn't disturb the other. No in that you make a copy of your source code as a means to manage your source code history. Obviously that's a thing for your source code management tool.
"Keeping the source code in a complete copy means we can change source control systems"
You always can either keep along your older SCM or migrate from the old to the new. Or at least you can do it if you use open source tools.
"and not have to worry about whether we'll still be able to track the code and data."
Not because of that but because now you have a "backdoor" to access your code history. Given sources are about 5% of overall data it seems a reasonable decision.
"The problem is that you are then dependent on the uncompressing algorithm being available, and if you don't have complete specs on the compression algorithm (who actually does?), the data are lost."
That, and your mention about "windows-like ini files", makes me think you are a bit "fooled" by proprietary software vendors. Compress/uncompress algorithms are published along with its current implementation. It's just a matter or choicing the proper tools (I don't expect gzip going anywhere in the next decades and even if it went away, both the algorithm and sources are published). Given what you say I wouldn't be surprised if your daily data sets came from 1GB to 100MB (a tenfold reduction) by using tar/gzip/bzip2.
"Uncompressed ASCII is universal."
Big endian or little endian? It's not as universal as you may think.
"And don't think that data files from that long ago aren't important"
I'd never make such a mistake: I was in that bussiness in a past life. But that's another strong reason to strictly stay with open source tools.
"And then checking all the constraints again in the application so that the user gets told that they need to select a thingamabobber, not DATA ERROR E0152 NON-NULL CONSTRAINT VIOLATED"
Then again, an encapsulation problem: an app shouldn't allow for low tier errors to arise but should cope with them.
"Yes, yes, yes. This is why when I collect data (I'm an experimentalist), I save a COMPLETE copy of the code used to run the experiment along with each day's data."
Do yourself a favour: use any SCM tool (Subversion, Git, heck even CVS) to manage your source code and make your program put its release version (and other interesting data, like parameters used, date, etc.) within the data files. It will not only save you space but will easy management and will bring to you the ability to easily find why the heck data from release 127 doesn't look like data from release 128.
"I'd go one farther: unless space is a serious constraint, store your data files in ASCII."
What's the problem with ASCII output and then compressing the files?
"I have also, over the course of some four decades of programming, come up with my own libraries to do the things I've needed to do.
The benefits: I know exactly how and why everything works. [...] The downside: It took me decades to get where I am."
It is not the only downside. The biggest downside is that even if you know in and out how your libraries work, you are the only one.
"if you are writing software to distribute to the public, you can generally assume your customer has commodity hardware unless your software costs at least 1000 USD a seat."
Well, the biggest commodity software vendor, Microsoft, seems to disagree with you. Remember Vista?
"What's wrong with stored procedures? 1) It means we need to support two languages instead of one, with all that that entails (a proper debugger, expert knowledge, etc)"
Wrong! *you*, not we. Repeat again: data is company's property, not the application's. You can bet your company data *will* be accessed by more than one application at more than one age if it's of any use (if it isn't the app shouldn't be programmed to start with). It will be the applications' side the one that will add supporting needs for more than one language, debugging, expert knowledge while the data will still use the same SQL language, the same tools and the same domain experts.
"2) Stored procedures cannot do ALL business logic"
True. Neither it's expected to do so. Data-bounded logic should be retained at the data engine level if only to be sure every accessor will comply to it. Your specific app logic can and should be developed within the application. Sometimes it takes some cleverness to find the boundaries, usually not.
"3) Because you don't want to have to deal with Oracle's horrid error messages anymore than absolutely necessary"
This is an argument *against* your position, not supporting it. The way you are free from Oracle's whatever is insuring that data managing functionality is as bound as possible to the data management engine (encapsulation, you know the concept). This way it will be the DBA's problem not yours.
"Sometimes it's easier and faster to code from scratch"
Sure. But they are about ten-fold less common than programers tend to think. They want to start from scratch because they think they'll do it better than their ancestors and they don't want to deep into other's code. Of course they'll fail into many of the same mistakes of the previous implementation and it will be as hard to read for a third party as the one they blamed. Oh! and will push forward time-to-market about twice as expected by the very programmer (with luck) which already is twice as long as if they start working now instead of whinning about how ugly is the inherited codebase.
"than it is to use off-the shelf software"
But we are not talking here about "off-the shelf" software. We are talking here about good in-the-unix-philosophy tools that are designed towards that very end: to be used in collaboration.
"My advice, in all honesty, is to build two. One that actually works, and one that is a star trek mock up."
That's not even your advice but one I remember seriously pushed within the Rainbow Series (you know, the Orange Book et al). It was not for a NOC but for a datacenter, but it makes no difference: no matter your security policies, your boss is your boss and he will want to show his power to some important visitors. So use your decomissioned equipment to build a mock up; incidentally since computers are nothing but going smaller and more powerful all the time, ancient equipment has more of a cool factor for the unsavvy than new one (don't forget tape reels and the machine that goes ping!).
"Personally I want to add that I somewhat doubt the taste of the actual color is 100% out of the equation."
That would be quite easy to test: you just blind-test (both in the sense that they don't get to know which wine is which and in that they don't get to see its color) against a slightly different one and you see if they can significantly tell appart the colored/uncolored as being the same against the third one.
"Actually they're the result of incompetence and/or apathy."
I know my trade and I know that it will cost more time/money than throwed at it. The fact that it breaks is therefor neither lack of knowledge nor apathy, at least, not at the technical level.
"The purpose of an audit is to reveal that incompetence and/or apathy has taken place so that it may be corrected in the future."
Ha! So many times that's the *declared* purpose. The real purpose is to cover managerial asses. Since that can be done with less time/money than the real thing, that's what you get.
"Good auditing may mitigate this issue"
For some definitions of "good". If your manager happens to have a different definition for "good", well, tough luck.
"So instead of having private firms that you could trust because they would be competing for your trust in food safety"
Who the hell tells you they would be competing for my trust?
In first instance those firms would be competing for MONEY; not even my money, but money. If they get more money by covering the irregularities of [big producer] than by getting my trust, so be it. That's not a supposition; that's a fact (tobacco companies, anyone?).
If that wasn't enough, private firms wouldn't even be competing for money, because firms have no will. Their CEOs would be trying to get money -for them, not the firms. So if a given CEO thinks it can get more of it by not only fucking me but even fucking their own companies in the while, so be it. That's not a supposition; that's a fact (Enron, anyone?).
And if you think "oh, no, that wouldn't happen", please go out the cavern you have been into for the last two centuries and get in touch with reality.
"Lets imagine a scenario with no public schools at all."
There's no need to imagine. That *was* the case in the whole world not so many ages ago.
And you know what? Alphabetization levels were horrible.
"People would have a greater deal of specialization which would allow them to better perform in the workplace."
Of course yes. Everybody knows people are not human beings with a soul to be enlighted but ants or replaceable machines.
"Lets face it, why should Joe Sixpack who is really great at, say, diesel mechanics have to read Shakespeare [...] Most people should not go to college"
Ok, ok, I resign.
"If they say no during both, and the consolidation attempts with the council fails, the proposal is dead and the commission will not bring it up again, unless the EP wants it."
But once the ACTA is rejected twice, the comission can bring back the ACTB, the ACTC, the ACTD and so till it's passed. Don't you remember the (still not dead) issue about software patents?
"And I already explained why it is possible. Ill-defined statements often don't have a defined truth value."
That's not a counter-argument: he already knows that ill-defined statements often don't have a defined truth value. What he holds is that no matter what, your mind tubes are forced to choose one anyway.
For really ill-defined statements, like "number seven is either green or red" you will choose the question to be false because you declare the attribute to be unholdable for the subject. With regards of existance (or more strictly, being) there's no way to get off the question: things either are or are not. Since it's a proper question the one about "do god exists or it doesn't?" there's no way for a human mind to not answer to itself either "yes, it does exist" or "no, it doesn't exist", even if the question really wouldn't hold a defined value of truth.
"Does nature give to human beings a monopoly over their ideas? No."
But of course yes!!!
Proof: What am I thinking now?
You don't know, uh? You don't know because I hold an absolut monopoly on my ideas.
What natura doesn't allow is for a monopoly on *public* knowledge -and that's because everyone holds a monopoly on his own mind: once it's made public and so I gain knowledge of it, you can't take it from me.
Food for mind.
"Because Linux software automatically runs executables downloaded from the Internet, right?"
Interesting question. Is there anything really impending Linux to automatically run executables downloaded from the Internet? I bet not.
So, on one hand we have that "the year of Linux on desktops" haven't reached yet because "cumbersome" limitations that make it "dificult for average joe" to use it, so "Linux isn't attacked by so many threats because it's more profitable to attack the wider Windows base"; in the other hand, as per current "analysis" from "experts" in order for Linux to take the desktop it should implement the same Windows easiness that allows for both "average joe" and the worms to take advantage of the platform.
Of course, the idea that successfully operating a (basically) complete turing machine requires some kind of training is out of question.
"Let companies keep more of what they earn and they'll feel more comfortable hiring people, it's that simple."
Maybe. But the only you can insure that way is that if companies keep more of what they earn, well, they'll keep more of what they earn, not that they'll expend that on hiring you.
Maybe they'll use that to pay better bonuses to the CEO.
Maybe they'll use that to pay dividends to their shareholders.
Maybe they'll use that to hire more cheap off-shored or HB1 labour.
So, why do you think that if companies keep more of what they earn they are going to gladly expend that on you?
"Learn to write better job postings"
But... why!? He *did* fill the post, didn't he? And he did it at a fraction of the cost, didn't he?
"If you really had no mystery requirement, I bet you could have found a qualified candidate at 5x the salary."
Probably, but I'll bet you -since it's right there, in the message you answer to, that they can find it off-shore for 1x the salary.
Free market, remember? I can get the same for x or for 5x... humm, what should I take?
"There are a lot of well-qualified americans ready to take those jobs, but companies don't want to pay what it would cost to hire those americans."
Why should we pay american costs when we can get the same results only cheaper?
Welcome to free market, sir.
Oh! and thank you for thinking sindicates to be communist and antipatriotic: that only makes our work, for us corporations, quite more easier.
"Using a source control system is orthogonal to keeping a copy of the source code with the data."
Yes, in that one thing doesn't disturb the other. No in that you make a copy of your source code as a means to manage your source code history. Obviously that's a thing for your source code management tool.
"Keeping the source code in a complete copy means we can change source control systems"
You always can either keep along your older SCM or migrate from the old to the new. Or at least you can do it if you use open source tools.
"and not have to worry about whether we'll still be able to track the code and data."
Not because of that but because now you have a "backdoor" to access your code history. Given sources are about 5% of overall data it seems a reasonable decision.
"The problem is that you are then dependent on the uncompressing algorithm being available, and if you don't have complete specs on the compression algorithm (who actually does?), the data are lost."
That, and your mention about "windows-like ini files", makes me think you are a bit "fooled" by proprietary software vendors. Compress/uncompress algorithms are published along with its current implementation. It's just a matter or choicing the proper tools (I don't expect gzip going anywhere in the next decades and even if it went away, both the algorithm and sources are published). Given what you say I wouldn't be surprised if your daily data sets came from 1GB to 100MB (a tenfold reduction) by using tar/gzip/bzip2.
"Uncompressed ASCII is universal."
Big endian or little endian? It's not as universal as you may think.
"And don't think that data files from that long ago aren't important"
I'd never make such a mistake: I was in that bussiness in a past life. But that's another strong reason to strictly stay with open source tools.
"And then checking all the constraints again in the application so that the user gets told that they need to select a thingamabobber, not DATA ERROR E0152 NON-NULL CONSTRAINT VIOLATED"
Then again, an encapsulation problem: an app shouldn't allow for low tier errors to arise but should cope with them.
"Yes, yes, yes. This is why when I collect data (I'm an experimentalist), I save a COMPLETE copy of the code used to run the experiment along with each day's data."
Do yourself a favour: use any SCM tool (Subversion, Git, heck even CVS) to manage your source code and make your program put its release version (and other interesting data, like parameters used, date, etc.) within the data files. It will not only save you space but will easy management and will bring to you the ability to easily find why the heck data from release 127 doesn't look like data from release 128.
"I'd go one farther: unless space is a serious constraint, store your data files in ASCII."
What's the problem with ASCII output and then compressing the files?
"I have also, over the course of some four decades of programming, come up with my own libraries to do the things I've needed to do.
The benefits: I know exactly how and why everything works.
[...]
The downside: It took me decades to get where I am."
It is not the only downside. The biggest downside is that even if you know in and out how your libraries work, you are the only one.
"if you are writing software to distribute to the public, you can generally assume your customer has commodity hardware unless your software costs at least 1000 USD a seat."
Well, the biggest commodity software vendor, Microsoft, seems to disagree with you. Remember Vista?
"What's wrong with stored procedures?
1) It means we need to support two languages instead of one, with all that that entails (a proper debugger, expert knowledge, etc)"
Wrong! *you*, not we. Repeat again: data is company's property, not the application's. You can bet your company data *will* be accessed by more than one application at more than one age if it's of any use (if it isn't the app shouldn't be programmed to start with). It will be the applications' side the one that will add supporting needs for more than one language, debugging, expert knowledge while the data will still use the same SQL language, the same tools and the same domain experts.
"2) Stored procedures cannot do ALL business logic"
True. Neither it's expected to do so. Data-bounded logic should be retained at the data engine level if only to be sure every accessor will comply to it. Your specific app logic can and should be developed within the application. Sometimes it takes some cleverness to find the boundaries, usually not.
"3) Because you don't want to have to deal with Oracle's horrid error messages anymore than absolutely necessary"
This is an argument *against* your position, not supporting it. The way you are free from Oracle's whatever is insuring that data managing functionality is as bound as possible to the data management engine (encapsulation, you know the concept). This way it will be the DBA's problem not yours.
"Sometimes it's easier and faster to code from scratch"
Sure. But they are about ten-fold less common than programers tend to think. They want to start from scratch because they think they'll do it better than their ancestors and they don't want to deep into other's code. Of course they'll fail into many of the same mistakes of the previous implementation and it will be as hard to read for a third party as the one they blamed. Oh! and will push forward time-to-market about twice as expected by the very programmer (with luck) which already is twice as long as if they start working now instead of whinning about how ugly is the inherited codebase.
"than it is to use off-the shelf software"
But we are not talking here about "off-the shelf" software. We are talking here about good in-the-unix-philosophy tools that are designed towards that very end: to be used in collaboration.
"My advice, in all honesty, is to build two. One that actually works, and one that is a star trek mock up."
That's not even your advice but one I remember seriously pushed within the Rainbow Series (you know, the Orange Book et al). It was not for a NOC but for a datacenter, but it makes no difference: no matter your security policies, your boss is your boss and he will want to show his power to some important visitors. So use your decomissioned equipment to build a mock up; incidentally since computers are nothing but going smaller and more powerful all the time, ancient equipment has more of a cool factor for the unsavvy than new one (don't forget tape reels and the machine that goes ping!).
"Otherwise, how can you tell the real leaders from those claiming to be leaders?"
But that's obvious, my friend! If someone tells you he is a leader and you believe him, he *is* a leader.
"here's my complaint: they keep putting in effort in places that really don't seem important"
Correction: ...that don't seem important... TO YOU.
"while neglecting those that do matter."
Correction: ...while neglecting those that do matter... TO YOU.
Now: Do you really think those people are putting efforts on things that don't matter to THEM while neglecting things that do matter TO THEM?
So, what are you doing in order to align THEIR insterests to YOURS? Are you throwing money at it or something?
Because surely you don't expect they will neglect THEIR INTERESTS in order to support YOUR INTERESTS just out of thin air, do you?
The generic name for Port-like wines is "fortified wine" and not "Port".
That's untrue. Port is a fortified wine, but not the only one by far. Amontillado, vermouth, madeira... are fortified wines too.
"Personally I want to add that I somewhat doubt the taste of the actual color is 100% out of the equation."
That would be quite easy to test: you just blind-test (both in the sense that they don't get to know which wine is which and in that they don't get to see its color) against a slightly different one and you see if they can significantly tell appart the colored/uncolored as being the same against the third one.
"in the US at least, we need to limit how long senators and represenatives get to stay in office. Give them all 12 years, and no retirement."
Oh! do they need their retirement? I thought Blackwater et al took care of that.
"Kind of like dogmatic faith in atheism is a religion?"
Atheism is a religion as much as not collecting stamps is a hobby.
"Actually they're the result of incompetence and/or apathy."
I know my trade and I know that it will cost more time/money than throwed at it. The fact that it breaks is therefor neither lack of knowledge nor apathy, at least, not at the technical level.
"The purpose of an audit is to reveal that incompetence and/or apathy has taken place so that it may be corrected in the future."
Ha! So many times that's the *declared* purpose. The real purpose is to cover managerial asses. Since that can be done with less time/money than the real thing, that's what you get.
"Good auditing may mitigate this issue"
For some definitions of "good". If your manager happens to have a different definition for "good", well, tough luck.