The same reason that the police can't arrest you until you commit a crime. You can't take legal action against X until X breaks the law, violates a contract, etc. The expectation or suspicion or threat of such an action isn't the same thing. (Good thing, too.)
> > But fortunately, little kids won't know how to circumvent firewalls > Have to differ with you on this one.
Yeah, I knew even when I wrote that I'd get called on it. I had in mind the kinds of immature/young kids who are still working on how to getting the hang of opening a cereal box, and whose parents, if they are clueful, should be able to stay ahead of their kids' technical abilities -- partly because they're spending enough time together that the parents can learn the same things that the kids learn.
If a ten-year-old is already hacking routers, then he/she is probably also bright enough to learn plenty of OTHER things about the world, with parental help or on their own -- like why you shouldn't kick the cat, where babies come from, why it's bad to shoplift, and what a bad idea it would be to meet a chatroom acquaintance at the zoo.
And again, it isn't that I view GTA/VC as intrinsically an evil influence on kids. As with so many things, it depends on the particular kids and on their families. I have a neighbor who was complaining -- COMPLAINING -- that her son didn't like TV, because it meant that he needed more time and effort from her during the day. TV is not a babysitter, nitwit!
I still think that, if you have to take a test to get a driver's license, you ought to have to take a test before raising children. Well, not really, but damn.
By the time your kids are in or approaching highschool, the groundwork has been laid. Either you have a strong, nurturing relationship, and your kids have learned to think responsibly for themselves; or they're snotty brats who distrust their overbearing and indifferent parents, who will lie to you at every opportunity, and who will bend with the winds of peer pressure. Either way, they have already been faced with every temptation you wish they didn't know about.
You need to give them the tools to make good choices: self-respect, self knowledge, curiosity, empathy, fairness, and the other strengths of responsible adulthood. And if they have a healthy amount of curiosity and are not malformed, OF COURSE they'll be fascinated by porn. Weren't you? Like the other poster said, isn't that what the Internet is for?
Little kids are another story, of course. They are still assembling their tool kits. You need to guide them through the discovery of life's seamier chapters. But fortunately, little kids won't know how to circumvent firewalls, and they don't need computers in their rooms. You have a few years to get them ready. And what they need from you has nothing to do with technology.
So I laugh at the folks who are aghast at their 16 year old kids running Grand Theft Auto Vice City. But I shudder at my friends who bought it for their ten-year-old son. WTF?
To restate more concisely a theme that appears frequently here: In RedHat's past rise to prominence, how large a role in your success was played by individual employees, consultants, and maverick development groups using free RedHat distros as a basis for RedHat Linux evangelism? -- and assuming that this has been an important factor, how can RedHat make up for the loss of this no-barriers entry path? Has RedHat adopted a plan to get better margins from a declining market share?
Nearly all states impose 'use tax' which is an analogue to their state's sales tax. If you buy something from out of state, regardless of how you buy it (including an Internet purchase), you owe the use tax. Many people don't pay use tax and fly below the radar; but states have become more aggressive at enforcement and have nailed plenty of violators.
The issue at hand here is about whether states can require COLLECTION of such taxes on Internet purchases. They already impose the tax. To date, there has been a moratorium on collecting it, as we all know. However, YOU STILL OWE YOUR STATE THE USE TAX, and not paying it is a form of evasion.
I hate this too, but that's just the way it is. By the way, most businesses cannot escape this -- enforcement of use (and other) tax collection is more aggressive with businesses -- and so they generally DO pay taxes on their out-of-state Internet purchases. It's a big part of my company's accounting process.
...you should have included your address within the text of your slashdot message. That would have worked. Clearly, from the various cited studies on/. and elsewhere, the most certain source of spam is getting your email address displayed in the clear on a public site that bots crawl over.
That's how all the bastards got me (my past email got unexpectedly included in archives that subsequently were hosted on web servers).
Totally agree. Too many words, even when correct, lose their power to convince.
You praise this letter's "lack of smug sarcasm"; that may be true, compared to the common exchanges by these combatants, but from the perspective of a CIO/CTO desk the letter is still pretty smarmy and superior.
It's like '80's Apple users talking about the PC world: "We know we're right and everybody else does too, but we'll do you a favor and take you through this argument once more...because you're such a dope." Success will come when the open source position is seen as mainstream, rather than the nerdy fringe. (Which is tough, as long as 80% of the market is focused on the latest Windows bug.)
> A NAT is the simplest...protection.... I'd rather use a NAT and do without the P2P software. As would most users...[just as] Ham and CB radios never replaced the telephone system -- fm6
I understand the mentality that says "everybody should be a peer to everybody" on the Internet. That's the architectural model. It's a good one.
But when you need to get Nicky Naperville's little office up and running and connected, you don't want to a) make him hire a net tech to worry about a firewall and proper security, or b) sign up to do it yourself (unless you get paid for this service). For a large segment of the Internet, clueless administration is the norm -- and this won't get any better. We might as well expect them to understand two's complement arithmetic or write their own parsers. Anything that (optionally) protects these folks from themselves a little is good. They have become the dominant Internet clients.
Like it or not, we've had an enormous 'dumming down' of the 'net, and no amount of wishing will make it back into a hacker's paradise. Trying to do that is incredibly elitist -- even more than the admittedly elitist step of dividing the world into clients and non-clients.
The legit fear is that, once the client/non-client distinction is made, that the big boys will chase out all the hackers, and force us to become castrated clients. "You can't have your own IP address. You can only send approved protocols. You can't use IP tunneling. So there." Lots of ISP's force their customers into highly restricted interfaces and protocol sets. This is a dangerous trend.
But we can't put the djini back in the bottle. NAT and private intranets are just too damn convenient. I won't consider getting rid of any of mine. We need a different way to protect our informational rights (a formless concept).
This is how IBM conquered the last generation, and Microsoft conquered the current one. There's no substitute for cubic inches. One of the good things about the Linux world is that we CAN get into pissing contests. But in the long run it means we can't win on the desktop. We can barely buy tickets to WATCH the fight. We can't even figure out which channel the fight is on.
Re:The problem is: that's not the problem
on
Does C# Measure Up?
·
· Score: 1
> You say it's crap, but it looks fine to me, so I sold it already. > You're not a good programmer because we're getting all these complaints
ROFL. We've all heard it. Of course, sometimes when they say "It looks fine to me" they're right. And sometimes getting complaints has nothing to do with the programming, but with training, sales expectations, or what some jerk in Redmonds sticks into a service pack.
> We could have had a modern Multics. Instead we have VMS (AKA WinNT) and Unix, all over again.
Exactly. I've said the same thing in the same words. In those days, the pace of hardware advance was largely managed (and shrouded) by IBM. Their hegemony, like Microsoft's, shaped the development of the industry. We pay the price today.
Though I'm not sure that the practitioners 'missed the ramifications' of the advances, as you say. We saw that new, faster CPU models came out every year; that memory footprints expanded rapidly; that DASD got bigger and faster. We saw small computers come onto the scene, first with 4K, then 8K, then 32K. We saw bitslice microprocessors arrive and said "Damn, with some AMD 2901's I could build a perfect instruction set." We realized that the little machines would proliferate.
But being able to glimpse the future doesn't mean you can change it or profit by it. Suppose you and I and a few pals had sat down and BUILT that 'modern Multics' you mention. It would probably have been squashed by market forces, the same fate of many promising systems. Our investment would probably have gone down the tubes. We would have been better spending our time and money on a BASIC interpreter.
For example, in 1979-82, two partners and I built what today would be called an object-oriented message-passing microkernel multiprocessor operating system. This was not an academic project but a commercial venture. It totally kicked butt. And it totally died as a business venture. Oh well. The Ellisons and Gates of the world always triumph. <sigh>
Re:The problem is: that's not the problem
on
Does C# Measure Up?
·
· Score: 1
Eeep. This is all too far back in my memory. (Obviously, I wasn't talking about 'nowadays,' but about back in the misty past, when worrying about relative instruction timings on a 360/67 or a 370/158 really made a (miniscule) difference. It was good practice to know and use the more efficient forms as a matter of course, particularly in compiler design.) My recollection was that SLR, ALR, etc. explicitly did not set the CC at all. But perhaps it was just that some bits were masked. My green cards, POO, instruction timings, etc. are all either packed away or thrown away. But I'm certain that, with the machines in use at the time (including both discrete logic and microcoded CPU's), there was a tiny savings. Anyway, it's all moot today, as you point out.
> I think the non-DAT 370's may have been the last
I definitely remember going over these issues in 1975-78 with timings from DAT 370's (also Amdahls), as well as more significant timings on page faults, segment faults, SVC, and DIAG. We were using IBM pubs, IBM internal docs, and field research. But who cares, I guess?
Re:The problem is: that's not the problem
on
Does C# Measure Up?
·
· Score: 1
> the field of Software Architecture wasn't around 10-15 years ago. Software Engineering is 20-25 years old.
WTF?
> I do think there is progress in software still, only maybe you're not at a site where it's happening anymore
Of course there's been progress. But we wasted a lot of really good ideas. For example, think of how many years our cheesy x86 C compilers forced programmers to worry about choosing a memory model. We knew better. The compiler could and should have taken care of such issues seamlessly, the way lots of 'real' compilers did for other CPU's. And I still can't believe the horrible virtual memory architecture that we use today. Cleaner, faster, better designs were in use in the '60's.
Much of my complaint relates to a dumming-down of computer science, prompted by the PC. "It's not a real computer, so we can cut corners." There's no reason a great operating system couldn't have been delivered on early PC hardware. Instead, we got something that might have been written in 1965.
It should be obvious, by the way, that most of my rants in this thread are related to the mainstream Wintel computing world. Plenty of developers are exempt from this complaint, including lots of slashdot folks. But they're in the minority, and more's the pity.
Re:The problem is: that's not the problem
on
Does C# Measure Up?
·
· Score: 1
I didn't mean to imply that these issues weren't important today. Just that, because of today's economics, relatively few of us worry about them. The examples you cite are spot-on.
System/application load times are a great instance of what I'm talking about. There's no good reason that today's boot cycles and app launch cycles are so slow and painful. We know how to do a better job at these things. No good reason except -- who's going to pay to fix a problem that is just seen as a minor inconvenience? Loaders and linkers have rarely received the attention they deserve. (If you want to test how much a developer knows, ask for a discussion of the terms 'scope,' 'discovery,' 'binding,' and 'marshalling.')
Re:The problem is: that's not the problem
on
Does C# Measure Up?
·
· Score: 1
We do build intelligent software that optimizes itself, such as the very techniques he's talking about. -- 2short
We do indeed. But not enough of us. See my reply above. I agree that good compilers can help a good deal. But a great compiler won't fix a bad design. And too many systems today seem to have NO design. We know a lot, as an industry, about how to design and build good systems. We just don't all practice what we preach, or know how to.
A couple of these replies suggest that my original point was that good programming is sitting around writing hand-optimized assembler. Not at all. I totally agree that a great choice of priorities is to focus on excellent compiler design. I totally agree that no developer should have to worry about which instruction is faster -- other than the compiler writer, or somebody working very close to the hardware. No arguments. I always liked the famous comment by (I think) Alan Kay: "An operating system is what the language designers left out of the compiler. There shouldn't be one." Or words to that effect.
My point was that we spend too little time on high-quality software. Some individuals do, but as a field we sadly do not. Well, actually 'sadly' isn't right. Your comment about moving targets, priorities, and where to spend your budgets is quite correct -- it's not wrong to rely on faster hardware to fix our software problems. If we have the cubic inches, we should use them, for sure. But the price we pay for poor quality is in the thousands of security holes, endless Windows service packs, nonorthogonal languages, cheesy user interfaces, missing features, poorly-thought-out feature sets. No time to do it right, must get it out the door.
Back to compilers -- there are indeed some decent compilers being written today, but I think most of the interesting strides in compiler algorithms were made 30 years ago. I think that our whole approach to language and compiler design stagnated, and perhaps regressed, for a couple of decades. Or how about data management! How many applications are built today by folks with no clue about how to normalize relational tables, nor any understanding of the mechanics of a database? Most of the data structures I see in production use today are crying out for help -- for skills that used to be much more common among practitioners. We've dummed-down our methods to a lower common denominator.
My feeling is that the overall direction of software practice has been coopted by a quick-and-dirty mindset that discourages us from investing in good architectures, good designs, good documentation, good test plans...good engineering.
There are plenty of exceptions, of course. But back to my original point: when hardware stops being so cheap (i.e. when the rate of improvement drops) we'll again have a reason to focus on building smarter software. And we will.
Re:The problem is: that's not the problem
on
Does C# Measure Up?
·
· Score: 1
D'oh! mistyped it. I meant SR R1,R1. SL R1,R1 is an error. SLR is faster because there's no condition code to set.
The problem is: that's not the problem
on
Does C# Measure Up?
·
· Score: 4, Insightful
You're right. But with ever-increasing CPU horsepower, memory bandwidth, memory size, etc., there simply is no incentive for optimizing the things you're talking about. Moore's 'Law' has attenuated the advancement of software technology, by eliminating the need for efficient software.
There are plenty of dinosaurian programmers like myself who remember hacking away on small machines. Save a byte by referencing a constant stored as an opcode in the instruction stream? Excellent! SLR R1,R1 is 60ns faster than SL R1,R1? Excellent! Decrease the size of the PDP-8 bootstrap loader by one word? Excellent! (Flipping those toggle switches took a lot of time.)
In 'the old days' hardware was expensive and programmers were cheap. Hard problems were solved by incredible brainpower from great engineers. As a result, by the early 70's software had made huge advances over the punchcard/paper-tape era, and we had learned a lot about how to build quality systems.
But there was a magic moment when the curves crossed between the cost of programming time versus the cost of hardware. Suddenly, it became easier to solve a problem by adding iron rather than by thinking harder. And so we slid backwards down the slope.
As far as I'm concerned, hardly anything significant has happened in software architecture or praxis for a few decades. Sure, we have a bunch of fancy new widgets, and the common man's programming paradigm has changed. And the Open Source movement finally has given substance and a PHB-understandable framework to what Unix, LISP, Smalltalk, and other hacker communities used to do behind the scenes.
But most of today's 'new' language, compiler, data management, operating system, and other computer science paradigms had their fundamental elements invented back in the 60's and 70's. We're finally RE-discovering many great concepts of the past. But it seems we've totally forgotten the importance of efficient, defect-free code, and the methods that might be used to create it.
This is not to say that only great systems were built in 'the good old days' -- those days weren't that good, and there was plenty of crap. But the really bright folks figured out how to do things RIGHT; and yet they wound up being ignored, because 'doing it right' became less important than 'letting Bruce the part-time lifeguard do it over the weekend in Visual Basic.'
So while I totally agree with your rant, and I've made a hundred similar rants of my own, the fact is we probably won't see fundamental improvements in software platforms until subatomic physics finally provides a wall against which hardware advances can bounce. As long as the answer to every performance/capacity complaint is "wait six months" there's no incentive to invest the man-centuries it will take to revamp our software environments. We probably need to build intelligent software that can optimize itself, because WE NEVER WILL.
I don't think it requires a careful reading to realize that a book in which the forward refers to the authors as a "rock throwing rabble" is not meant to be taken at face value. -- miu
So you would think. But the evidence seems to be to the contrary. The first thing a zealot seems to lose is a sense of humor -- and any sense of proportion. Wait...I mean, the first two things lost are a sense of humor, a sense of proportion, and a sense of justice. Wait....
I find it interesting that so many people here apparently think this book slams UNIX to praise MSWindows. More careful readers noticed that this collection of rants arose from people who came to UNIX from other, less familiar, more robust platforms, and who were frustrated by what struck them in comparison as obvious omissions and limitations. Most were not DOS/Windows users, but experienced Multics, LISP, Mesa/Cedar, etc. hackers. They knew enough to realize a) that UNIX wasn't perfect, b) that they lost some capabilities and clarity when they changed platforms, and c) that many of the problems they encountered were technicaly solvable...so why the hell did they still exist?
Naturally, this book is dated, and the mailing list that fed it more dated still. But the most important thing is this: the book is a collection of self-declared rants. They're supposed to be narrow-minded flames. The result is supposed to be funny. And from my perspective, it is funny.
There are plenty of reasons that UNIX has its warts, most of which stem from its long, strange legacy of benign neglect under AT&T's care. If its original purpose and vision could have been sustained with an adequate development budget through the years, who knows what we'd have today? But it didn't happen that way. Oh well, we have what we have. We get plenty of value by putting up with UNIX headaches -- absolutely. But it's not surprising that somebody would feel pain after leaving a conceptually clean platform like Smalltalk, Cedar, or a LISP Machine.
And again, they're not saying that DOS/Windows was the answer, fer chrissakes. They're not actually saying that anything is the answer; they're just using their right to gripe and be funny about it. It strikes me about the same as most of our normal anti-MS rants (including my own). In other words, it's possible to say "I hate UNIX" and still hate Bill Gates.
Welcome to the post-literate society. Better get used to it. Of course, consider the alternatives. How much 'news' is there in today's 'news broadcasts'? It's all cheesy infotainment, produced to the lowest common denominator, just like our sitcoms, reality shows, and mock-science documentataries. Naturally, SciFi channel must follow the ratings, and produce to the same standards. (Of course, the fact of your participation in this discussion does not bode well for you, either.) Better just sit back and smile at the humans.
This comment is right on the money. ISP's like most other businesses need to plan for a certain level of load. They don't have infinite resources or margins. They provide 'enough' headroom to accommodate reasonable loads, but they can't afford 'too much' headroom -- if they did, they'd be wasting capital that could be used for other things. (Obviously what 'enough' and 'too much' represent are a function of their SLA's, service quality, size, etc.; a good provider won't run into trouble often.)
When they run out of gas, everything goes into panic mode. People work overtime. Unexpected capital expenditures are made (new routers, new servers, new DASD, etc.). Surcharges are tacked on from upstream vendors.
All those costs add up, and because they're unexpected, they're painful. So to an extent, the surcharge that WE receive is to discourage us from whacking the pipes too often; or, if we need it, to arrange for the capacity in advance. So if the higher costs seem disproportionate, it's because they're supposed to be. Enough of these events can drive a smaller provider out of business.
Slashdot Mirror
The same reason that the police can't arrest you until you commit a crime. You can't take legal action against X until X breaks the law, violates a contract, etc. The expectation or suspicion or threat of such an action isn't the same thing. (Good thing, too.)
And how else does something become 'what's hot lately'?
Your choice of papers and your implied priorities are illuminating. You can work on my projects any time. :)
> > But fortunately, little kids won't know how to circumvent firewalls
> Have to differ with you on this one.
Yeah, I knew even when I wrote that I'd get called on it. I had in mind the kinds of immature/young kids who are still working on how to getting the hang of opening a cereal box, and whose parents, if they are clueful, should be able to stay ahead of their kids' technical abilities -- partly because they're spending enough time together that the parents can learn the same things that the kids learn.
If a ten-year-old is already hacking routers, then he/she is probably also bright enough to learn plenty of OTHER things about the world, with parental help or on their own -- like why you shouldn't kick the cat, where babies come from, why it's bad to shoplift, and what a bad idea it would be to meet a chatroom acquaintance at the zoo.
And again, it isn't that I view GTA/VC as intrinsically an evil influence on kids. As with so many things, it depends on the particular kids and on their families. I have a neighbor who was complaining -- COMPLAINING -- that her son didn't like TV, because it meant that he needed more time and effort from her during the day. TV is not a babysitter, nitwit!
I still think that, if you have to take a test to get a driver's license, you ought to have to take a test before raising children. Well, not really, but damn.
By the time your kids are in or approaching highschool, the groundwork has been laid. Either you have a strong, nurturing relationship, and your kids have learned to think responsibly for themselves; or they're snotty brats who distrust their overbearing and indifferent parents, who will lie to you at every opportunity, and who will bend with the winds of peer pressure. Either way, they have already been faced with every temptation you wish they didn't know about.
You need to give them the tools to make good choices: self-respect, self knowledge, curiosity, empathy, fairness, and the other strengths of responsible adulthood. And if they have a healthy amount of curiosity and are not malformed, OF COURSE they'll be fascinated by porn. Weren't you? Like the other poster said, isn't that what the Internet is for?
Little kids are another story, of course. They are still assembling their tool kits. You need to guide them through the discovery of life's seamier chapters. But fortunately, little kids won't know how to circumvent firewalls, and they don't need computers in their rooms. You have a few years to get them ready. And what they need from you has nothing to do with technology.
So I laugh at the folks who are aghast at their 16 year old kids running Grand Theft Auto Vice City. But I shudder at my friends who bought it for their ten-year-old son. WTF?
To restate more concisely a theme that appears frequently here: In RedHat's past rise to prominence, how large a role in your success was played by individual employees, consultants, and maverick development groups using free RedHat distros as a basis for RedHat Linux evangelism? -- and assuming that this has been an important factor, how can RedHat make up for the loss of this no-barriers entry path? Has RedHat adopted a plan to get better margins from a declining market share?
Obviously it's all due to the fact that men are object-oriented. :P
Nearly all states impose 'use tax' which is an analogue to their state's sales tax. If you buy something from out of state, regardless of how you buy it (including an Internet purchase), you owe the use tax. Many people don't pay use tax and fly below the radar; but states have become more aggressive at enforcement and have nailed plenty of violators.
Some links: this, this, and this for example.
The issue at hand here is about whether states can require COLLECTION of such taxes on Internet purchases. They already impose the tax. To date, there has been a moratorium on collecting it, as we all know. However, YOU STILL OWE YOUR STATE THE USE TAX, and not paying it is a form of evasion.
I hate this too, but that's just the way it is. By the way, most businesses cannot escape this -- enforcement of use (and other) tax collection is more aggressive with businesses -- and so they generally DO pay taxes on their out-of-state Internet purchases. It's a big part of my company's accounting process.
...you should have included your address within the text of your slashdot message. That would have worked. Clearly, from the various cited studies on /. and elsewhere, the most certain source of spam is getting your email address displayed in the clear on a public site that bots crawl over.
That's how all the bastards got me (my past email got unexpectedly included in archives that subsequently were hosted on web servers).
Totally agree. Too many words, even when correct, lose their power to convince.
You praise this letter's "lack of smug sarcasm"; that may be true, compared to the common exchanges by these combatants, but from the perspective of a CIO/CTO desk the letter is still pretty smarmy and superior.
It's like '80's Apple users talking about the PC world: "We know we're right and everybody else does too, but we'll do you a favor and take you through this argument once more...because you're such a dope." Success will come when the open source position is seen as mainstream, rather than the nerdy fringe. (Which is tough, as long as 80% of the market is focused on the latest Windows bug.)
> A NAT is the simplest...protection.... I'd rather use a NAT and do without the P2P software.
As would most users...[just as] Ham and CB radios never replaced the telephone system -- fm6
I understand the mentality that says "everybody should be a peer to everybody" on the Internet. That's the architectural model. It's a good one.
But when you need to get Nicky Naperville's little office up and running and connected, you don't want to a) make him hire a net tech to worry about a firewall and proper security, or b) sign up to do it yourself (unless you get paid for this service). For a large segment of the Internet, clueless administration is the norm -- and this won't get any better. We might as well expect them to understand two's complement arithmetic or write their own parsers. Anything that (optionally) protects these folks from themselves a little is good. They have become the dominant Internet clients.
Like it or not, we've had an enormous 'dumming down' of the 'net, and no amount of wishing will make it back into a hacker's paradise. Trying to do that is incredibly elitist -- even more than the admittedly elitist step of dividing the world into clients and non-clients.
The legit fear is that, once the client/non-client distinction is made, that the big boys will chase out all the hackers, and force us to become castrated clients. "You can't have your own IP address. You can only send approved protocols. You can't use IP tunneling. So there." Lots of ISP's force their customers into highly restricted interfaces and protocol sets. This is a dangerous trend.
But we can't put the djini back in the bottle. NAT and private intranets are just too damn convenient. I won't consider getting rid of any of mine. We need a different way to protect our informational rights (a formless concept).
This is how IBM conquered the last generation, and Microsoft conquered the current one. There's no substitute for cubic inches. One of the good things about the Linux world is that we CAN get into pissing contests. But in the long run it means we can't win on the desktop. We can barely buy tickets to WATCH the fight. We can't even figure out which channel the fight is on.
> You say it's crap, but it looks fine to me, so I sold it already.
> You're not a good programmer because we're getting all these complaints
ROFL. We've all heard it. Of course, sometimes when they say "It looks fine to me" they're right. And sometimes getting complaints has nothing to do with the programming, but with training, sales expectations, or what some jerk in Redmonds sticks into a service pack.
> We could have had a modern Multics. Instead we have VMS (AKA WinNT) and Unix, all over again.
Exactly. I've said the same thing in the same words. In those days, the pace of hardware advance was largely managed (and shrouded) by IBM. Their hegemony, like Microsoft's, shaped the development of the industry. We pay the price today.
Though I'm not sure that the practitioners 'missed the ramifications' of the advances, as you say. We saw that new, faster CPU models came out every year; that memory footprints expanded rapidly; that DASD got bigger and faster. We saw small computers come onto the scene, first with 4K, then 8K, then 32K. We saw bitslice microprocessors arrive and said "Damn, with some AMD 2901's I could build a perfect instruction set." We realized that the little machines would proliferate.
But being able to glimpse the future doesn't mean you can change it or profit by it. Suppose you and I and a few pals had sat down and BUILT that 'modern Multics' you mention. It would probably have been squashed by market forces, the same fate of many promising systems. Our investment would probably have gone down the tubes. We would have been better spending our time and money on a BASIC interpreter.
For example, in 1979-82, two partners and I built what today would be called an object-oriented message-passing microkernel multiprocessor operating system. This was not an academic project but a commercial venture. It totally kicked butt. And it totally died as a business venture. Oh well. The Ellisons and Gates of the world always triumph. <sigh>
Eeep. This is all too far back in my memory. (Obviously, I wasn't talking about 'nowadays,' but about back in the misty past, when worrying about relative instruction timings on a 360/67 or a 370/158 really made a (miniscule) difference. It was good practice to know and use the more efficient forms as a matter of course, particularly in compiler design.) My recollection was that SLR, ALR, etc. explicitly did not set the CC at all. But perhaps it was just that some bits were masked. My green cards, POO, instruction timings, etc. are all either packed away or thrown away. But I'm certain that, with the machines in use at the time (including both discrete logic and microcoded CPU's), there was a tiny savings. Anyway, it's all moot today, as you point out.
> I think the non-DAT 370's may have been the last
I definitely remember going over these issues in 1975-78 with timings from DAT 370's (also Amdahls), as well as more significant timings on page faults, segment faults, SVC, and DIAG. We were using IBM pubs, IBM internal docs, and field research. But who cares, I guess?
> the field of Software Architecture wasn't around 10-15 years ago. Software Engineering is 20-25 years old.
WTF?
> I do think there is progress in software still, only maybe you're not at a site where it's happening anymore
Of course there's been progress. But we wasted a lot of really good ideas. For example, think of how many years our cheesy x86 C compilers forced programmers to worry about choosing a memory model. We knew better. The compiler could and should have taken care of such issues seamlessly, the way lots of 'real' compilers did for other CPU's. And I still can't believe the horrible virtual memory architecture that we use today. Cleaner, faster, better designs were in use in the '60's.
Much of my complaint relates to a dumming-down of computer science, prompted by the PC. "It's not a real computer, so we can cut corners." There's no reason a great operating system couldn't have been delivered on early PC hardware. Instead, we got something that might have been written in 1965.
It should be obvious, by the way, that most of my rants in this thread are related to the mainstream Wintel computing world. Plenty of developers are exempt from this complaint, including lots of slashdot folks. But they're in the minority, and more's the pity.
I didn't mean to imply that these issues weren't important today. Just that, because of today's economics, relatively few of us worry about them. The examples you cite are spot-on.
System/application load times are a great instance of what I'm talking about. There's no good reason that today's boot cycles and app launch cycles are so slow and painful. We know how to do a better job at these things. No good reason except -- who's going to pay to fix a problem that is just seen as a minor inconvenience? Loaders and linkers have rarely received the attention they deserve. (If you want to test how much a developer knows, ask for a discussion of the terms 'scope,' 'discovery,' 'binding,' and 'marshalling.')
We do build intelligent software that optimizes itself, such as the very techniques he's talking about. -- 2short
We do indeed. But not enough of us. See my reply above. I agree that good compilers can help a good deal. But a great compiler won't fix a bad design. And too many systems today seem to have NO design. We know a lot, as an industry, about how to design and build good systems. We just don't all practice what we preach, or know how to.
A couple of these replies suggest that my original point was that good programming is sitting around writing hand-optimized assembler. Not at all. I totally agree that a great choice of priorities is to focus on excellent compiler design. I totally agree that no developer should have to worry about which instruction is faster -- other than the compiler writer, or somebody working very close to the hardware. No arguments. I always liked the famous comment by (I think) Alan Kay: "An operating system is what the language designers left out of the compiler. There shouldn't be one." Or words to that effect.
My point was that we spend too little time on high-quality software. Some individuals do, but as a field we sadly do not. Well, actually 'sadly' isn't right. Your comment about moving targets, priorities, and where to spend your budgets is quite correct -- it's not wrong to rely on faster hardware to fix our software problems. If we have the cubic inches, we should use them, for sure. But the price we pay for poor quality is in the thousands of security holes, endless Windows service packs, nonorthogonal languages, cheesy user interfaces, missing features, poorly-thought-out feature sets. No time to do it right, must get it out the door.
Back to compilers -- there are indeed some decent compilers being written today, but I think most of the interesting strides in compiler algorithms were made 30 years ago. I think that our whole approach to language and compiler design stagnated, and perhaps regressed, for a couple of decades. Or how about data management! How many applications are built today by folks with no clue about how to normalize relational tables, nor any understanding of the mechanics of a database? Most of the data structures I see in production use today are crying out for help -- for skills that used to be much more common among practitioners. We've dummed-down our methods to a lower common denominator.
My feeling is that the overall direction of software practice has been coopted by a quick-and-dirty mindset that discourages us from investing in good architectures, good designs, good documentation, good test plans...good engineering.
There are plenty of exceptions, of course. But back to my original point: when hardware stops being so cheap (i.e. when the rate of improvement drops) we'll again have a reason to focus on building smarter software. And we will.
D'oh! mistyped it. I meant SR R1,R1. SL R1,R1 is an error. SLR is faster because there's no condition code to set.
You're right. But with ever-increasing CPU horsepower, memory bandwidth, memory size, etc., there simply is no incentive for optimizing the things you're talking about. Moore's 'Law' has attenuated the advancement of software technology, by eliminating the need for efficient software.
There are plenty of dinosaurian programmers like myself who remember hacking away on small machines. Save a byte by referencing a constant stored as an opcode in the instruction stream? Excellent! SLR R1,R1 is 60ns faster than SL R1,R1? Excellent! Decrease the size of the PDP-8 bootstrap loader by one word? Excellent! (Flipping those toggle switches took a lot of time.)
In 'the old days' hardware was expensive and programmers were cheap. Hard problems were solved by incredible brainpower from great engineers. As a result, by the early 70's software had made huge advances over the punchcard/paper-tape era, and we had learned a lot about how to build quality systems.
But there was a magic moment when the curves crossed between the cost of programming time versus the cost of hardware. Suddenly, it became easier to solve a problem by adding iron rather than by thinking harder. And so we slid backwards down the slope.
As far as I'm concerned, hardly anything significant has happened in software architecture or praxis for a few decades. Sure, we have a bunch of fancy new widgets, and the common man's programming paradigm has changed. And the Open Source movement finally has given substance and a PHB-understandable framework to what Unix, LISP, Smalltalk, and other hacker communities used to do behind the scenes.
But most of today's 'new' language, compiler, data management, operating system, and other computer science paradigms had their fundamental elements invented back in the 60's and 70's. We're finally RE-discovering many great concepts of the past. But it seems we've totally forgotten the importance of efficient, defect-free code, and the methods that might be used to create it.
This is not to say that only great systems were built in 'the good old days' -- those days weren't that good, and there was plenty of crap. But the really bright folks figured out how to do things RIGHT; and yet they wound up being ignored, because 'doing it right' became less important than 'letting Bruce the part-time lifeguard do it over the weekend in Visual Basic.'
So while I totally agree with your rant, and I've made a hundred similar rants of my own, the fact is we probably won't see fundamental improvements in software platforms until subatomic physics finally provides a wall against which hardware advances can bounce. As long as the answer to every performance/capacity complaint is "wait six months" there's no incentive to invest the man-centuries it will take to revamp our software environments. We probably need to build intelligent software that can optimize itself, because WE NEVER WILL.
</rant>
I don't think it requires a careful reading to realize that a book in which the forward refers to the authors as a "rock throwing rabble" is not meant to be taken at face value. -- miu
So you would think. But the evidence seems to be to the contrary. The first thing a zealot seems to lose is a sense of humor -- and any sense of proportion. Wait...I mean, the first two things lost are a sense of humor, a sense of proportion, and a sense of justice. Wait....
I find it interesting that so many people here apparently think this book slams UNIX to praise MSWindows. More careful readers noticed that this collection of rants arose from people who came to UNIX from other, less familiar, more robust platforms, and who were frustrated by what struck them in comparison as obvious omissions and limitations. Most were not DOS/Windows users, but experienced Multics, LISP, Mesa/Cedar, etc. hackers. They knew enough to realize a) that UNIX wasn't perfect, b) that they lost some capabilities and clarity when they changed platforms, and c) that many of the problems they encountered were technicaly solvable...so why the hell did they still exist?
Naturally, this book is dated, and the mailing list that fed it more dated still. But the most important thing is this: the book is a collection of self-declared rants. They're supposed to be narrow-minded flames. The result is supposed to be funny. And from my perspective, it is funny.
There are plenty of reasons that UNIX has its warts, most of which stem from its long, strange legacy of benign neglect under AT&T's care. If its original purpose and vision could have been sustained with an adequate development budget through the years, who knows what we'd have today? But it didn't happen that way. Oh well, we have what we have. We get plenty of value by putting up with UNIX headaches -- absolutely. But it's not surprising that somebody would feel pain after leaving a conceptually clean platform like Smalltalk, Cedar, or a LISP Machine.
And again, they're not saying that DOS/Windows was the answer, fer chrissakes. They're not actually saying that anything is the answer; they're just using their right to gripe and be funny about it. It strikes me about the same as most of our normal anti-MS rants (including my own). In other words, it's possible to say "I hate UNIX" and still hate Bill Gates.
Welcome to the post-literate society. Better get used to it. Of course, consider the alternatives. How much 'news' is there in today's 'news broadcasts'? It's all cheesy infotainment, produced to the lowest common denominator, just like our sitcoms, reality shows, and mock-science documentataries. Naturally, SciFi channel must follow the ratings, and produce to the same standards. (Of course, the fact of your participation in this discussion does not bode well for you, either.) Better just sit back and smile at the humans.
This comment is right on the money. ISP's like most other businesses need to plan for a certain level of load. They don't have infinite resources or margins. They provide 'enough' headroom to accommodate reasonable loads, but they can't afford 'too much' headroom -- if they did, they'd be wasting capital that could be used for other things. (Obviously what 'enough' and 'too much' represent are a function of their SLA's, service quality, size, etc.; a good provider won't run into trouble often.)
When they run out of gas, everything goes into panic mode. People work overtime. Unexpected capital expenditures are made (new routers, new servers, new DASD, etc.). Surcharges are tacked on from upstream vendors.
All those costs add up, and because they're unexpected, they're painful. So to an extent, the surcharge that WE receive is to discourage us from whacking the pipes too often; or, if we need it, to arrange for the capacity in advance. So if the higher costs seem disproportionate, it's because they're supposed to be. Enough of these events can drive a smaller provider out of business.
JMO