When I moved into computer science, the only software model that I would work with was open source. Again there is nothing gained from hiding problems with code, and it's much easier to identify issues. I discovered remarkable similarities with my old nursing practices and the Open Source method.
First off, having access to a GPL app as a developer is *always* going to be at least as good for you as having access to a similar closed-source app. With a closed-source app, you tyically can't even *look* at the code. You can't reuse the code in your code, you can't redistribute the result.
With a GPL app, you can *always* look at the code, and you can *always* reuse the code. Its true that you can only redistribute the result as long as you are willing to allow your users the same freedom, but that's better than nothing, which is what you get from the closed-source app.
Ultra ironic, then, that it was written by a girl.
It was also, back in the day, pretty much the only game I ever saw girls playing in the arcades. That right there ought to point out something about the true level of violence in it.
I used *love* Centipede for just that reason. It provided my only chance to talk to girls back when I was wasting all day in the arcade.
To say it again: You have to wipe the complete drive. You have to sacrifice your installation. Only then will no evidence be left and no evidence that can tell when the drive was wiped.
Actually, that's not enough either. Its actually possible to recover *overwritten* data with the right equipment. That's why government classified electronics go through a zeroizing procedure where a pattern of 1s and 0's are written repeatedly through everything when classified data needs to be erased.
More like; they have fewer accidents because they drive less. This is the same reason that women get lower rates; they drive less than men. Probably this is because a lot of us men insist on doing the driving when we are together. Check out the gender makeup of the cars in traffic that have passengers some time and you'll see what I mean.
An insurance company gets paid per year (or per month), not per mile that you drive, so people who drive less are a deal for them.
These days, it's fairly rare to find someone that believes the entire bible should be taken literally
Well, no. That's actually the official position of the Southern Baptist Convention. I belive they are the third largest denomination in the USA. A short blurb about their beliefs here states about the scripture:
The Holy Bible was written by men divinely inspired and is God's revelation of Himself to man. It is a perfect treasure of divine instruction. It has God for its author, salvation for its end, and truth, without any mixture of error, for its matter.
Note the phrases "perfect" and "without any mixture of error".
That being said, the second largest denomination (mine) believes nothing of the sort. I actually had several flat out contradictions in the bible pointed out to me in Sunday School by a minister as proof against this concept. (For the curious, there are actually *3* different creation stories in the bible, and the two in Genesis give contradicting timelines).
Interestingly we are also officially pro-choice, and the denomination to which the Bushes belong. Go figure.
Oh, I'm sure they must have done something "innovative", but whatever it was doesn't seem to be related to their bottom line or have had much of an impact on their products.
You couldn't be more wrong. Microsoft pioneered the use of copyright law to restrict copying of software. They also pioneered the shrink-wrapped EULA.
They've also come up with some pretty innovative contractual innovations with their vendors, although they may have borrowed many of the concepts from what Standard Oil used to do back in the early 1900s.
None of this had benifitted anyone but their stockholers, mind you. But they were indeed innovations for which Microsoft should recieve all the credit they are due.
While you are right the summary is completly wrong, you should blame the person that got it wrong. Mac of Macistan, the article submitter and summary writer, is the person that got it wrong.
For this to be a valid point, we'd first have to come to the conclusion that slashdot has no editors whatsoever.
That's assuming they choose to land in the USA off course. Considering that the USA covers only a minor piece of the worlds landmass, it's statisticly more likely they will land somewhere else entirely.. like Red China or India. Not sure if it would be any better thought, politicans are generaly crocks no matter where they are from.
First off, the USA is not the largest country in area, but it is in the top 4. The only larger ones are Russia, China, and Canada. India is smaller. It should also be pointed out that Canada is contiguous with the US along a very long border, creating in effect one very large block.
Secondly, anyone smart enough to travel that distance despite the physics problems involved would probably also be smart enough to land in the place putting out the most energy (assuming they want to find "our leader"). That would be the US, hands down.
Just a simple look at artificial lighting at night would lead one to conclude that "leaders" would most likely be found on the NE corridor in the US, or in the Belium-Netherlands area in europe. Japan's an outside possibility. But Russia, China, and India are about the last places you'd go.
I wouldn't draw much from his conclusions, as his assumptions are rather suspect. For instance:
What programmers in a hundred years will be looking for, most of all, is a language where you can throw together an unbelievably inefficient version 1 of a program with the least possible effort. At least, that's how we'd describe it in present-day terms. What they'll say is that they want a language that's easy to program in.
This is just flat out wrong. Mind, you there are uses for a good "prototype language". But the main problem software developers are dealing with today (as in Fredrick Brook's day), is that computer capabilities (and thus the complexity of the programs we want to run on them) are growing exponentially, while the human capacity to understand and deal with complexity is pretty much set, and the complexity-reducing capabilities of our tools are growing at best linearly. You may be able to slap something impressive together rather quickly today, but getting it working correctly and error-free is getting harder and harder. Any new language since machine language is just a reaction to this fact.
What we need is most decidedly not languages that help us slap together some buggy, jerry-rigged jalopy of a program together quickly. What we need are languages that help us design and build working, maintainable systems, in the face of their exponentially increasing complexity.
Anyone can tell you that most of the efort put into a successful program happens after the initial build. So the goal should not be languages that are easy to program in, but rather languages that are easy to understand the sources of. Often this will jibe with being easy to program in, but quite often it will not. In such conflicts, the reader should always take priority over the writer.
Given this, frankly Java (which he dismissed) and Ada (which he didn't even mention) are about the only languages around with their priorities straight.
Sony has LONG since tackled the issue of harrasing customer phone calls with their customer service program, "Operation: Go Fuck Yourself". Sony believed that if you truly just stopped giving a shit, eventually your customers would pick up on this and quit asking for help. It's a beautiful, horrifying behemoth of a program that paid off big time in their favor. Grats to them.
Unfortunately, high levels are relatively easy to attain. I played for 1 month, a few hours a night, and I'm currently at level 32, right where the content stops. But there are people who were level 50 only 3 weeks after the game was launched. What do they do now?
Roughly same thing bored gangs of kids do in real life. They hang out and greif innocent passers-by.
I know I'm a day late (and probably a dollar short) on this, but I thought a note from someone who is familiar with the subject matter in the report might be of value.
Personally, I think its a rather shoddy bit of work.
First off, and most importantly to the Slashdot crowd, last I checked MODSAF was not OpenSource, by the OSI defintion. See section 5: "No Discrimination Against Persons or Groups". MODSAF is freely available to anyone working on a DoD job, but so is just about any other DoD-bankrolled software ever written.
Secondly, he actually did a study and found that using translators to automaticly turn Fortran into C, is a bad idea (created unmaintainable crap that ran slower). I suppose there may be some PHBs out there who need to hear this, but for the rest of us...DUH!
Thirdly, he kept talking about C++ like its the paragon of OO-ness, and implicitly calling Ada a non-OO language. Both horribly wrong. The only bright spot I saw here was the use of Java for a new IOS. Java's actually a really good fit for an IOS (Instructor/Operator Station), as they are all about GUIs and network communications. I just hope the component library they used isn't "disappeared" by Sun on them. These Sims need to be maintained for decades.
I think the subject of OSS in the military is a really good topic. But MODSAF is not an example. Instead, look at Gnat (GPL), CLIPS (public domain), and RTEMS (Modified GPL). All were originally sponsored by the DoD, but now have lots of users outside the military and commercial companies supporting them. The DoD should be doing more such projects.
The last time an actual deserving movie that the movie going public actually enjoyed, got nominated for anything was the orignal "Star Wars"
...which was beaten out for best picture by "Annie Hall". What a wonderful movie that was. I know everyone would just love to watch that movie over and over. I wonder when its theatrical re-release will be?
1977: The year I lost all faith in the Academy Awards.
it's now illegal to provide any false information while using oral communication. specifically related to, but not limited to, false information regarding the name of the communicator.
How's that help in this instance, where the victim (not counting the spamees) was from the US but (quoting the story):
The email came from a mail server in the Philippines, and pointed to a website hosted in China, owned by a company in London. Tracking down the actual spammer would likely be close to impossible.
I think its pretty clear that laws are not going to be the answer here.
Can't agree with that one. I don't have my Fred Brooks handy, but I recall he says something like "No. Focus on quality and productivity will follow". He's dead right too.
I do have my Fred Brooks handy, and its not in there.
There is something along those lines in Peopleware. "Quality is free", if I remember. Although I don't have my copy of Peopleware handy, so perhaps its not in there either.:-) However, he was quite careful to point out that this doesn't mean "we can have all the free quality we want".
I actually agree with this (and you). That is certianly the way things should be done. My point is that its not typically the way things are done, because quality is typically an afterthought at best.
The thing we have to remember is that productivity is not the same thing as schedule. In fact, to meet a schedule crunch, developers often are forced to do very unproductive things. Not all of these things will show up in the product as a lack of quality, but many of them will. Ideally we'd never work this way, if for no other reason than its a criminal waste good and expensive labor. But often that's what's expected.
So I think we are actually in violent agreement here.
Last I checked, the vast majority of "programmers" were essentially self-taught. Certianly where I work, there are hundreds of software developers, and perhaps 5 people with CS degrees. So I think before we start flogging CS programs for the failings of the industry, perhaps that same industry should try hiring more of their programmers from CS programs.
As for a real culprit for our persistent software security and safety woes, try the following:
A lack of faith in professional training (see above)
A pervasive culture of valuing youth over experience
The primacy of schedule and cost over quality. Its an old management addage that you only get to pick 2.
The pervasive use of unsafe languages like C and C++, and the "hacking" mindset they engender, in preference to safer alternatives like Java and Ada
As a manager, probably not what you wanted to hear, though.
If they ask for a urine sample (which many companies do these days), there there's nothing stopping them from doing that with it.
I've actually had one company ask for that at the interviews. They drove me over to a lab and everything. They were trying to lure me from another company, too. Baaaaad start.
Slashdot Mirror
Care to try moving into government next? Please?
This is really confused.
First off, having access to a GPL app as a developer is *always* going to be at least as good for you as having access to a similar closed-source app. With a closed-source app, you tyically can't even *look* at the code. You can't reuse the code in your code, you can't redistribute the result.
With a GPL app, you can *always* look at the code, and you can *always* reuse the code. Its true that you can only redistribute the result as long as you are willing to allow your users the same freedom, but that's better than nothing, which is what you get from the closed-source app.
It was also, back in the day, pretty much the only game I ever saw girls playing in the arcades. That right there ought to point out something about the true level of violence in it.
I used *love* Centipede for just that reason. It provided my only chance to talk to girls back when I was wasting all day in the arcade.
Actually, that's not enough either. Its actually possible to recover *overwritten* data with the right equipment. That's why government classified electronics go through a zeroizing procedure where a pattern of 1s and 0's are written repeatedly through everything when classified data needs to be erased.
Perhaps we can make it up to him by naming the new "dwarf planets" after the Seven Dwarves.
Considering its recent demotion, Pluto should probably get to be "Grumpy".
More like; they have fewer accidents because they drive less. This is the same reason that women get lower rates; they drive less than men. Probably this is because a lot of us men insist on doing the driving when we are together. Check out the gender makeup of the cars in traffic that have passengers some time and you'll see what I mean.
An insurance company gets paid per year (or per month), not per mile that you drive, so people who drive less are a deal for them.
Does anyone else find it interested that this story was posted on the same day as the story about radio controlled humans?
Well, no. That's actually the official position of the Southern Baptist Convention. I belive they are the third largest denomination in the USA. A short blurb about their beliefs here states about the scripture:
Note the phrases "perfect" and "without any mixture of error".
That being said, the second largest denomination (mine) believes nothing of the sort. I actually had several flat out contradictions in the bible pointed out to me in Sunday School by a minister as proof against this concept. (For the curious, there are actually *3* different creation stories in the bible, and the two in Genesis give contradicting timelines).
Interestingly we are also officially pro-choice, and the denomination to which the Bushes belong. Go figure.
You couldn't be more wrong. Microsoft pioneered the use of copyright law to restrict copying of software. They also pioneered the shrink-wrapped EULA.
They've also come up with some pretty innovative contractual innovations with their vendors, although they may have borrowed many of the concepts from what Standard Oil used to do back in the early 1900s.
None of this had benifitted anyone but their stockholers, mind you. But they were indeed innovations for which Microsoft should recieve all the credit they are due.
For this to be a valid point, we'd first have to come to the conclusion that slashdot has no editors whatsoever.
...er...OK. Valid point.
...unless they want to install themselves as our new "leaders". In that case, they'd head straight for that place. :-)
First off, the USA is not the largest country in area, but it is in the top 4. The only larger ones are Russia, China, and Canada. India is smaller. It should also be pointed out that Canada is contiguous with the US along a very long border, creating in effect one very large block.
Secondly, anyone smart enough to travel that distance despite the physics problems involved would probably also be smart enough to land in the place putting out the most energy (assuming they want to find "our leader"). That would be the US, hands down.
Just a simple look at artificial lighting at night would lead one to conclude that "leaders" would most likely be found on the NE corridor in the US, or in the Belium-Netherlands area in europe. Japan's an outside possibility. But Russia, China, and India are about the last places you'd go.
This is just flat out wrong. Mind, you there are uses for a good "prototype language". But the main problem software developers are dealing with today (as in Fredrick Brook's day), is that computer capabilities (and thus the complexity of the programs we want to run on them) are growing exponentially, while the human capacity to understand and deal with complexity is pretty much set, and the complexity-reducing capabilities of our tools are growing at best linearly. You may be able to slap something impressive together rather quickly today, but getting it working correctly and error-free is getting harder and harder. Any new language since machine language is just a reaction to this fact.
What we need is most decidedly not languages that help us slap together some buggy, jerry-rigged jalopy of a program together quickly. What we need are languages that help us design and build working, maintainable systems, in the face of their exponentially increasing complexity.
Anyone can tell you that most of the efort put into a successful program happens after the initial build. So the goal should not be languages that are easy to program in, but rather languages that are easy to understand the sources of. Often this will jibe with being easy to program in, but quite often it will not. In such conflicts, the reader should always take priority over the writer.
Given this, frankly Java (which he dismissed) and Ada (which he didn't even mention) are about the only languages around with their priorities straight.
Badgers? Badgers?!
We don't need no stinking badgers!!
That's true. They even made a motivational poster for the program.
Roughly same thing bored gangs of kids do in real life. They hang out and greif innocent passers-by.
Redundant too. This is C and C++ code we're talking about.
I know I'm a day late (and probably a dollar short) on this, but I thought a note from someone who is familiar with the subject matter in the report might be of value.
Personally, I think its a rather shoddy bit of work.
First off, and most importantly to the Slashdot crowd, last I checked MODSAF was not OpenSource, by the OSI defintion. See section 5: "No Discrimination Against Persons or Groups". MODSAF is freely available to anyone working on a DoD job, but so is just about any other DoD-bankrolled software ever written.
Secondly, he actually did a study and found that using translators to automaticly turn Fortran into C, is a bad idea (created unmaintainable crap that ran slower). I suppose there may be some PHBs out there who need to hear this, but for the rest of us...DUH!
Thirdly, he kept talking about C++ like its the paragon of OO-ness, and implicitly calling Ada a non-OO language. Both horribly wrong. The only bright spot I saw here was the use of Java for a new IOS. Java's actually a really good fit for an IOS (Instructor/Operator Station), as they are all about GUIs and network communications. I just hope the component library they used isn't "disappeared" by Sun on them. These Sims need to be maintained for decades.
I think the subject of OSS in the military is a really good topic. But MODSAF is not an example. Instead, look at Gnat (GPL), CLIPS (public domain), and RTEMS (Modified GPL). All were originally sponsored by the DoD, but now have lots of users outside the military and commercial companies supporting them. The DoD should be doing more such projects.
Does that mean they are all nuclear powered?
1977: The year I lost all faith in the Academy Awards.
That was a damn impressively quick slashdotting.
How's that help in this instance, where the victim (not counting the spamees) was from the US but (quoting the story):
I think its pretty clear that laws are not going to be the answer here.
I do have my Fred Brooks handy, and its not in there.
There is something along those lines in Peopleware. "Quality is free", if I remember. Although I don't have my copy of Peopleware handy, so perhaps its not in there either.
I actually agree with this (and you). That is certianly the way things should be done. My point is that its not typically the way things are done, because quality is typically an afterthought at best.
The thing we have to remember is that productivity is not the same thing as schedule. In fact, to meet a schedule crunch, developers often are forced to do very unproductive things. Not all of these things will show up in the product as a lack of quality, but many of them will. Ideally we'd never work this way, if for no other reason than its a criminal waste good and expensive labor. But often that's what's expected.
So I think we are actually in violent agreement here.
As for a real culprit for our persistent software security and safety woes, try the following:
As a manager, probably not what you wanted to hear, though.
I've actually had one company ask for that at the interviews. They drove me over to a lab and everything. They were trying to lure me from another company, too. Baaaaad start.
No, they did not get the employee.