The guy's opinion was very obviously true to most of us. Is there any way that @Stake is not a joke now? There are two sides to everything. Someone, please explain the other side of this one. I don't get it.
This guy is using JSP for a simple database access app. OF COURSE it's overkill. OF COURSE people using scripting languages are having an easier time.
Maybe you could say that JSP is like an SUV, compared to scripting languages when you're trying to do a simple web app that accesses a database. That's taking a Hummer to 7-11.
For example, couldn't my ISP return its web page instead of a broken link (since my nameserver is assigned to theirs via DHCP)?
Maybe this is good --- maybe we will choose our nameserver based on who does the most useful thing with mistypes. For example, I'll bet Google could do something very useful with a mistype, and figure out a way to make money without pissing me off.
Of course, if Verisign is returning bogus entries, a nameserver has an additional, but mostly trivial (probably as simple as IP address filtering), job of filtering BS Verisign links to identify mistyped urls.
When you write internet software now, you have to supply port 80 tunnelling so that people behind firewalls can use them. If you close all ports except 80, it does nothing except add a trivial layer of complexity to writing networking code, whether the code is malicious or not.
This is like arguing that instead of locking all doors and windows, all we should brick them all up except for the front door, but leave that one open because we're too lazy/foolish to operate the lock (or, we can't figure out how to make a lock that's easy enough to use).
Bits don't care what port they travel over, and software/viruses can be configured to send/receive them over any open port. What we need are simple locks.
Code Generation is for people who don't understand or are too lazy for abstraction
The article that timothy suggested as background reading (here) points out that code generation is most useful when you're forced to use a framework that requires lots of simple-minded "scaffolding-style" code. EJB is the prime example.
In other words, I agree with you --- if code generation is useful, it's probably because the infrastructure you're using was poorly designed. But that doesn't mean you don't have to use it. Managers who have no idea what J2EE is require you to use J2EE. So you use code generation.
As an employer, I don't filter or spy, and I probably won't do this either. But, for employers that are tempted, isn't this a great alternative? If you're married, a report of your web activities will be mailed to your spouse. No filters that will screw up and keep out legitimate sites; no employer spyware.
The only problem (as identified by my wife): "What if you wanted to buy me a present online?"
You're showing a very common misconception about the point of the Thompson article. The problem is much, much deeper than your post suggests. And it's a problem that hits open source and closed source.
Let's say that you don't trust ANYBODY, so you decide to write your own compiler. And from now on, you're only going to run code that you've personally examined and compiled in your own personal compiler.
So, you write your own compiler. What language did you use? C? Well, you'll need to compile it then, won't you. What compiler are you going to use? Do you trust it?
The point of the article isn't just that you can't trust code you (and the open source community) haven't personally examined. You can't trust code unless you've personally built the entire compilation and execution environment using trusted code, from the ground up.
So think about the OS you're running right now. Is it Linux that you compiled from source? How can you trust gcc? If you do trust it, how do you trust the compiler that was used to compile gcc, etc? [See the gcc web site for info on how gcc is actually built using multi-stage bootstrapping]
An understanding of this concept will make you see computer security in the jaded way that true security experts see it: there is no such thing. Chances are that we all got our systems up and running from some public Linux distro. If the maker of that distro wanted into your box, they'd be there.
The question is, where did you get your software? Do you trust them? If getting your software from a bunch of hackers makes you nervous, getting it from Microsoft should, in my opinion, terrify you. At least we have forums like this (and folks like the Houston Linux team) to catch and fix the problems.
Slashdot Mirror
The guy's opinion was very obviously true to most of us. Is there any way that @Stake is not a joke now? There are two sides to everything. Someone, please explain the other side of this one. I don't get it.
Here may be the reason why they're doing it:
When I was at Dartmouth (Class of '94), everybody on campus knew that if you did the following:
1. Dial 1 and the area code
2. Click the receiver once
3. Dial the rest of the number
you got free long distance calls. I had a roommate with a girlfriend in Spain, and he figured out how to do it for long distance.
If that still works, I bet nobody at Dartmouth will be using VoIP.
This guy is using JSP for a simple database access app. OF COURSE it's overkill. OF COURSE people using scripting languages are having an easier time.
Maybe you could say that JSP is like an SUV, compared to scripting languages when you're trying to do a simple web app that accesses a database. That's taking a Hummer to 7-11.
But when I code, I'm going into battle. I need a military humvee with this frigging thing mounted on it.
Can't any name server do this?
For example, couldn't my ISP return its web page instead of a broken link (since my nameserver is assigned to theirs via DHCP)?
Maybe this is good --- maybe we will choose our nameserver based on who does the most useful thing with mistypes. For example, I'll bet Google could do something very useful with a mistype, and figure out a way to make money without pissing me off.
Of course, if Verisign is returning bogus entries, a nameserver has an additional, but mostly trivial (probably as simple as IP address filtering), job of filtering BS Verisign links to identify mistyped urls.
When you write internet software now, you have to supply port 80 tunnelling so that people behind firewalls can use them. If you close all ports except 80, it does nothing except add a trivial layer of complexity to writing networking code, whether the code is malicious or not.
This is like arguing that instead of locking all doors and windows, all we should brick them all up except for the front door, but leave that one open because we're too lazy/foolish to operate the lock (or, we can't figure out how to make a lock that's easy enough to use).
Bits don't care what port they travel over, and software/viruses can be configured to send/receive them over any open port. What we need are simple locks.
Code Generation is for people who don't understand or are too lazy for abstraction
The article that timothy suggested as background reading (here) points out that code generation is most useful when you're forced to use a framework that requires lots of simple-minded "scaffolding-style" code. EJB is the prime example.
In other words, I agree with you --- if code generation is useful, it's probably because the infrastructure you're using was poorly designed. But that doesn't mean you don't have to use it. Managers who have no idea what J2EE is require you to use J2EE. So you use code generation.
As an employer, I don't filter or spy, and I probably won't do this either. But, for employers that are tempted, isn't this a great alternative? If you're married, a report of your web activities will be mailed to your spouse. No filters that will screw up and keep out legitimate sites; no employer spyware.
The only problem (as identified by my wife): "What if you wanted to buy me a present online?"
You're showing a very common misconception about the point of the Thompson article. The problem is much, much deeper than your post suggests. And it's a problem that hits open source and closed source.
Let's say that you don't trust ANYBODY, so you decide to write your own compiler. And from now on, you're only going to run code that you've personally examined and compiled in your own personal compiler.
So, you write your own compiler. What language did you use? C? Well, you'll need to compile it then, won't you. What compiler are you going to use? Do you trust it?
The point of the article isn't just that you can't trust code you (and the open source community) haven't personally examined. You can't trust code unless you've personally built the entire compilation and execution environment using trusted code, from the ground up.
So think about the OS you're running right now. Is it Linux that you compiled from source? How can you trust gcc? If you do trust it, how do you trust the compiler that was used to compile gcc, etc? [See the gcc web site for info on how gcc is actually built using multi-stage bootstrapping]
An understanding of this concept will make you see computer security in the jaded way that true security experts see it: there is no such thing. Chances are that we all got our systems up and running from some public Linux distro. If the maker of that distro wanted into your box, they'd be there.
The question is, where did you get your software? Do you trust them? If getting your software from a bunch of hackers makes you nervous, getting it from Microsoft should, in my opinion, terrify you. At least we have forums like this (and folks like the Houston Linux team) to catch and fix the problems.