I think we've arrived at something like agreement on the DBMS point. FYI SQL query optimizers are very different from JIT compilers. The basic reason is the 3-6 orders of magnitude difference between the speed of the CPU and that of the I/O. Index creation is too expensive and slow to be done dynamically to answer queries.

I agree that for all its faults COBOL makes screen handling easy. I don't remember the syntax anymore, but it's stupifyingly easy to read/write the fields by name on a form. I've never seen anything so, um, simple in GUI programming or web programming. And I wish the folks who developed HTTP/HTML had heard of a Communication Area and pseudo-converstational connections.

You actually can't do in COBOL everything you can do in C because it lacks explicit pointers. Without pointers you can't reference arbitrary locations in memory. That's why the only CICS system I ever designed had an assembler module for the non-standard stuff.

As for ditching TCP/IP, while I don't doubt Infiniband has its place, your reasoning has a few problems.

1. Security-through-obscurity is thoroughly discredited. At least, Whitfield Diffie thinks so. David Wheeler's book is online and not a bad place to start if you want to update yourself on security.
2. If you think "most IP stacks today are about 99.9995% secure" and you (implicitly) agree with my argument that bug counts decrease as code is used, why do you think your infiniband stack will be better?
3. Using IP doesn't automatically mean the webserver is connected to "the network". That's a design descision. Nothing prevents segregating the networks.

Widely used, well tested software such as your IP stack is bound to be more secure than whatever you would replace it with, despite the fact that the attacker knows what you're using and may even have the source code to it.

That's a big if. I don't know what "99.9995% secure" means (what the denominator?) but I don't believe there's ever been an exploit via the TCP stack. It's one of those highly improbable events that, if it ever did happen, would suddenly subject millions of machines to attack. Your database server would be the least of your worries.

Nearly infinitely more likely, I'm sure you agree, is something much more pedestrian: social engineering, MD5 leaks, etc. Whatever it is, it doesn't follow that the same vehicle will exist on the DBMS host, nor should it.

Finally, since we're both fans of simplicity in programming, I leave you with this:

You didn't hurt my feelings. I haven't written a line of COBOL since the summer of 1988. Rather, I was objecting to arrant nonsense masquerading as authoritative-sounding statements. That kind of thing can harm the reputation of Slashdot, you know.

Any defense you attempt of that proposition will only land you deeper in the tall grass. ISAM can't be "used as" a relational database because it lacks the fundamental facilities.

The most widely accepted informed definition of the relational model is the three-part test Codd described in 1978: structure, operations, and constraints. ISAM includes no algebra and very little in the way of constraint enforcement. It also fails most of Codd's 12 rules.

I think you might mean that ISAM files have keys, and that ISAM files can be arranged in ways that mimic normal forms. The comparison is superficially appealing and logically vacant. Sorry.

Do please tell. I'd especially like to know what "as such" means in that sentence. Googling "isam db2 site:ibm.com" fails to turn up anything relevant. Searching DB2 Documentation for "isam"s turned up nothing.

No, that's unnecessary for purposes of security. Again, one of the three legs of the relational model is constraints. The DBMS is perfectly capable — more capable than the stored procedure, more than the application — of preventing inconsistent data from entering the database. It can't ensure correctness; no mere machine can. But only the DBMS can enforce referential integrity and declared constraints versus other contemporaneous processes.

But you're right that if the webserver can only execute stored procedures and has no other rights in the DBMS, then the data are absolutely safe from arbitrary manipulation through SQL injection. (Yes, I understand the procedure could be written to execute its parameters as code. But anyone letting data in any form be executed in a web environment might as well start looking for other work now. Why wait until the fan gets dirty?)

By contrast, no file system offers any such protection. If the webserver can access any part of the file, it can access the whole file. Own the server and you own the data.

I don't know what that means. I can't even venture a guess. I guess Lisp is too generic too for a secure system. That explains why Paul Graham is sleeping under bridges instead of funding startups.

I'm not defending COBOL. I can think of a dozen problems with it. I'm ridiculing the crippled/generic taxonomy you proposed. C has no I/O capability and no memory management save static storage and the stack. What can anyone do with such a toy? Exactly the same is true for Java. COBOL on the other hand, like Pascal, at least defines I/O in the language. Even with the stdio library, can you do in C what COBOL does in 64 lines?

Your basic assertion seems to be that a simple system is less vulnerable than a complicated one. While that's partly true, I have to remind you of Einstein's dictum to make things as simple as possible but no simpler. When you recommend eschewing tcp/ip as "too complex", I see an invitation to reinvent it badly. It's not easy to improve on the socket model, and the course of the development of TCP/IP is evidence enough that it is easy to go wrong. After all, by the time the attacker has sufficient control to put the Ethernet interface into promiscuous mode and listen to arbitrary traffic, he's already better ways to get at the data than sniffing the wire.

I'm sure you've found that the more any code is used, the more dependable it is. I suggest that's because bugs are found asymptotically, meaning that bugs are halved by doubling the use, meaning that only very old code is anywhere near bug-free. An exploit in the TCP/IP stack is therefore going to be orders of magnitude less likely than one in your MPI-over-Infiniband proposal.

So, while I agree that systems are easier to understand and harder to exploit the simpler they are, I don't agree that that's a good yardstick. The advances in security we've seen over the last 10 years don't rely on crippled languages. The focus has instead been on capability: a process either can or cannot do something. The system is broken into parts such that most parts are incapable of affecting much, and those that require power are severely constrained in what they can do. That was the approach successfully taken by Postfix, for example, which is about as Internet-facing an application as there is.

The DBMS can similarly curtail privilege using stored procedures. If implemented correctly by the DBA — and everything always depends on something being done right — the DBMS is invulnerable to any sloppiness or oversight on the part of the application.

The very fact that SQL injection is both widespread and easily prevented suggests that it's people, not technologies, that are the security hole. I assert that if COBOL and MVS had given rise to the Web instead of C and Unix, we'd be seeing MVS exploits instead. Unless in that alternate universe knowledge and quality were valued over time-to-market and reinvented wheels.

Why is this noise modded up? The only true parts of that statement are equally true for C, depending on what "crippled" and "retarded" mean. The rest is best ignored. For example, I'm sure I've heard of C being used for processing things.

DB/2 sprang from System R, IBM's prototype RDBMS. It competed (indeed, competes) with the mother of all "large scale ISAM" systems, IMS. Last I checked, it represented about 20% of the SQL DBMS market in annual sales.

It's too bad more web programmers (and framework designers) don't know more about database security. I have yet to read about a SQL injection exploit that couldn't have been prevented through fairly basic security measures within the DBMS.

Hello? People who earn their pay from ad revenue make up the vast majority of journalists. Where else do you suppose the money to pay salaries at CBS and Time comes from?

I don't see how having an editorial staff standing between the writer and the ad buyer affects whether or not the writer is a journalist.

Do NOT threaten to leave. Don't hint at it. Your options are your options, unless you back yourself into a corner.

It's extremely aggressive. Put the shoe on the other foot: when was the last time your boss told you "Do it or you're fired"? How would you react? How would you react if it would't affect your income?

Remember, your job is much more important to you than to your boss. Treat it with respect, not like a poker chip.

In other words, whether hard or electronic copy, when you "buy" a book, you're really just licensing it, to put it in the words you used. There is no "bought."

Not true, else there would be no used book market. That battle was fought with publishers at the turn of the century. (The tune never changes, only the technology.) Publishers were including license agreements in books, setting terms of use that excluded, among other things, resale. The supreme court said if if looks like a sale, it is a sale, "license" notwithstanding.

(The OP asks What Happens When Corporations Become Publishers. I would think we already know, because most books are published and sold by corporations, and have been for a long time.)

First of all, FAT is patent encumbered and Microsoft's willing to go to court to protect it; so that's out.

If you honor the patent, you reinforce it. If you ignore it, you weaken it. Millions of Lilliputian cuts make it irrelevant. Why not join in?

Someone needs to make a good file system that matches FAT, but is more extensible.

Well, the thing about FAT is it's recognized by just about every computer on the planet and a lot of non-computers. How are you going to make your post-FAT filesystem accessible to hundreds of millions of Windows computers? If you don't do that, what data exchange problem have you solved?

If you don't care about nonfree OSes, a simple convention would suffice. If the kernel understood that, say, uid==0 && gid=-1 meant the same thing as chmod 777 and that all files created in such a directory got the directory's uid and gid, you'd have everything you want without even touching the fs code.