In physics the abstractions leak. Newton's laws leak like crazy. Einstein's theories leak. Presently there are no fundamental theories in physics which don't leak like crazy when quantum mechanics and gravity interact.
In sports the abstractions leak. That's how we get players like Gretzky and pay a lot of money to watch what they do.
And how about the reason why didn't C++ didn't define a native string type. Because there isn't any way to implement a string class that serves all possible applications. The premise of C++ is not being stuck with someone else's choice on what part of the abstraction should leak. Because C++ doesn't define a native string type, the user is free to replace the default standard string implementation with any other string implementation and have it integrate with the language on an equal footing with the standard string type.
If a language is imposes standard abstractions it only takes one abstraction you can't live with to make that choice of language untenable. Which is how C++ has been so successful despite being the worst of all possible languages (except for all the others).
Please, somebody post the link to the story about the lawsuit between Fujitsu and the supplier who added phosporous to the molding compound. I've bought a fair number of Fujitsu disk drives mostly they worked great. Of the four drives I bought affected with the recent problem, 2.5 have failed. I don't think it was Fujitsu's fault. That said, Fujitsu has done a miserable job of owning up to the problem once they realized what had happened. The other day I heard that a local school had to return 40% of all drives ordered from this drive series.
Just to keep myself honest, I force myself to do sysadmin tasks in vi. Generally I use emacs for source code. Tonight I used vi to write a small Perl program to change a bunch of URLs in a bunch of web pages to a different layout system. I've been writing a lot of PHP lately and I haven't used Perl for a couple of years. The entire project is a refresher course.
Editing Perl with vi! Talk about a cruft implosion. To make things worse, I was using a very bad version of vi that came standard with Debian potato. It doesn't indicate on the screen that you are in insert mode. Certain kinds of cursor motion break insert mode when you least expect it. It doesn't even have a line number indicator on the status bar.
Aside from all the obvious reasons I've been trying to figure out why I hate vi as much as I do. I've put up with worse and complained less. Yet somehow as much as I try to accept vi for what it is I fail miserably.
I was paying special attention to my vi misery as I permuted Perl's line noise. Here's what it comes down to. If you have N characters on a line, there are N+1 positions where you might wish to insert a new character. Yet in vi you can't actually reach all these positions without first entering insert mode: the position that appends to the end of the line is not available. This leads to the ludicrous effect that whenever you cancel insert mode, your cursor moves one character to the left (unless you are already at the beginning of the line). Oh, and you can place yourself at the end of a line when you are not in insert mode--if the line happens to be completely empty.
So there I am getting slap happy with vi (banging escape whenever I forget what mode I'm in, which is almost always) and every time I bang escape I have to watch carefully to see if my cursor skids left.
It's bad enough having two modes. But did the concept of current position also have to be different between the modes? Incredible. Just for this one reason vi constantly gives me the feeling I'm babysitting a naughty child.
On the other hand, emacs might be barroque, but I rarely spend much time thinking about my hands unless I'm trying to do something that isn't habitual. I rarely use a feature in emacs I didn't learn in the first two days. "feature freeze" in emacs is modal in its own way. One moment you are working productively, the next moment (or hour, or day) you are whittling away at one billion options you don't want. But there's the difference: emacs is modal once an hour, vi changes modes faster than you can blink, or think.
There's a general rule (apparently unknown to the anticruft crusader who launched this topic) that cruft is eliminated only when something new comes along that's ten times better. Only ten times. And vi still exists. Amazing.
With great dilligence I avoided allowing Flash to install itself on my primary Windows machine. Then one day my brother came over with a friend, and five minutes later his friend had installed Flash so he could see the cheesy entry page to some mountain bike vendor charging $200 to the negative gram. Good work Dale, you made my virus of the month club. Actually, I'm not sure whether Dale is a virus or a trojan or a worm.
I figure there's no hope for Flash ever becoming as useful to the end user after installation as it is before installation. Flash uninstalled is the easiest method of all for eliminating tons of obnoxious anti content.
Four desktops, each two monitors in size. First desktop: journal, several tabbed browser windows for general research. Second desktop: on the left three emacs windows, one for front end PHP code, one for back end PHP code, one for CSS stylesheets; on the right, four console windows open to various points in the source tree where I can do source code control manipulations and run commands to publish the new code to various test servers. Third desktop: left side, various SSH consoles open to web servers and capturing web server log outputs; right side, three different types of browsers to view the test pages. Four window: left side, free for hire; right side, SSH sessions to the embedded devices that capture our data and to the company's corporate web server where functions as a bulletin board for the development team. And then there are two more desktops I keep for stuff I'm only working on casually. Use some instances of Dia for making diagrams to post into the corporate workweb, image processing tools, etc. And the left monitor itself is special: I press the input button it switches to display the output of a W2K machine which I also use to test web pages and for browsing web sites that suck in Mozilla.
But that's just me, right? Not "definitive". Use your brain, guy. I used to buy shelfloads of C++ books. My desktop was my second monitor. You know, that chunk of wood that supports your mouse and keyboard. I used to look down there to learn things I needed to know while I was working. It has been two years since I bought a book to prop on my desktop. Any book I buy now sends me to the big leather chair. What else has changed? Could it be that my work is smattered across seven different embedded systems and web servers? That never happened back when I was running a Pentium system. And let's not forget you can almost fit the list of all XML standards on a single 19" monitor if you use small fonts (and you never actually click into them). And it's not possible that I could need to reference materials on Perl, Python, JavaScript, and PHP all in the same hour. Or that I might be running tail -f | grep on six different files under/var/log while also running daemons in console mode to locate the source of a problem.
My suggestion is give up. The definitive study that having one hand tied behind your back impedes your work flow probably doesn't exist.
Undergraduate hang wringing and so much Bailey's you can't tell whether the alcohol or the sugar is having the worst effect. It seems to me that writing great programs has a lot to do with creating good namespaces and chosing your names well.
class this {
pre this ();// constructor
post this ();// destructor };
At least that partially makes sense, unlike anything else named "modernism" by people who are already dead.
Yesterday at 6:00p.m. I had a box of parts. By 9:00p.m. I had a working system with the Debian base install and OpenSSH configured with my public key installed. By 10:00p.m. the machine was installed and working fine in our server closet in our small office downtown and I could access the machine remotely via SSH to complete the configuration.
Most painful step: it took a full hour to install the giant PAL 8045 heatsink with exactly the right amount of thermal paste. Second most painful step: discovering that the 18" IDE cables wouldn't read from the hotswap IDE controllers to the right IDE connector, having to pull the whole thing out and lowering it one slot. Pain caused by Debian? One of the two floppies I used to boot the machine failed to format on the first attempt.
Both my network interfaces came up automatically, my hot swap IDE RAID was detected automatically, my network install worked automatically. I created all my partitions and mount points without ever leaving the installation script. The average table or chair from IKEA take longer to assemble.
I think the real complaint in that review is that Debian comes as unfinished pine and he was expecting a dark walnut stain and then he makes it sound like Debian amounts to chopping your own trees.
I've heard for years that SCSI drives have some mythical additional quality as compared to IDE drives, even though everyone knows the drives have 90% of their components in common.
I welcome this change in the IDE drive industry. What the drive companies are trying to capture is the "I don't know the difference" consumer "so I won't a dime more than the store across the street".
Among those of us who do know the difference and who do care about their data there will be a backlash against the new state of affairs. What we will see is a new niche for premium IDE hard drives that are mechanically and electrically as reliable as reputable SCSI drives. Those of us who care will pay an extra $30 per drive and we'll be glad we did.
The philosophy you are expressing is known as extremism. Works just fine in the Middle East.
If you start with a group of ten people who are managing to cooperate just fine, and then you add Richard Stallman to the group, how many trouble makers do you now have? Ten. Everyone _except_ RMS. Why can't they all cooperate? It's such a terrible puzzle.
This is the most peculiar post I've ever read bonused for insight: "It's all up to whoever chooses." Would that includes the choices of the slaves or not? I thought that issue had something to do with the fact that the slaves were, correct me if I'm wrong, also humans. If "free software" means the same thing as "free humans" we're all in big trouble.
I'm typing on one of those stiff IBM keyboards today. Whenever I switch to a stiff keyboard, entire word fragments go missing. I think it's a trick my hands play when running up hill. I'd send them down to the minors, but they're on a one-way contract with a no-trade clause.
"is" from the first sentence should have been "isn't"
I'm convinced my hands are living evidence for Chomsky's theory of traces. The word fragments that go missing are the ones which don't resolve until word order is set. It's disturbing that my typing errors come out as correctly spelled words I didn't intend to use. It's like waking up one day and discovering your own mental processes work much like the MS Office grammar checker which allows you to make a complete ass out of yourself if your word forms are plausible.
This is a hierarchy of smarterness. It's a battle of Smaug against riddling hobbits and the arrow of destiny. Be careful where you stand when DRM falls, it will make a big ugly splash.
Eventually the dragons *will* win if they learn hard lessons from every mistake. The only question is whether the dragon, once perfectly armoured, will still be able to fly, or whether it will be so encrusted with layer upon layer of protective armour it can't really hurt anyone who doesn't stumble into its path. Copy protection died in the late eighties when people discovered it was more onerous than advantageous. When copy protection actually works, it drives your legitimate customers crazy. That's my hope for DRM, that it becomes so good no one can stand it.
What intellectual creation in this world doesn't have a fistful of lousy ties in the bottom drawer of the dresser? The existence of the BCD instruction, which is probably trapped in microcode by all modern implementations, is evidence of what exactly? If you squeezed out the vast majority of all the dubious instructions which remain in the formal x86 instruction set, I have serious doubts you would gain 5% on any significant metric (thermal loss, die size, clock frequency, etc.) The practical core of the x86 instruction set was firmly established by the 486. The majority of useful integer instructions on a 486 take exactly one clock cycle. In many programs 99% of all generated instructions come from this core group.
Complaining about crufty ties in the bottom drawer is a serious misdirection of mental resources.
I guess most people don't comprehend the "red queen" nature of processor scaling. You have to as fast as you can to stay right where you are.
Increasing clock speed is not a linear gain. Let's imagine we scale the 66MHz 486 to several GHz without making any significant changes to the core. How fast would it run? It would be stalled three clock cycles out of every four, or worse. It wouldn't run 10% of the speed of a modern core at the same clock speed. That order ten magnitude constitutes a long series of "paltry gains" paying the price for maintaining linearity while clock frequency takes all the credit. And I'm not even being fair to the paltry gains, because IPC has indeed increased greatly while latency hazards have scaled by several orders of magnitude.
There are no end of tight loops out there where the x86 averages nearly three u-ops per clock cycle, the theoretic limit for Pentium III / Athlon cores. (I don't know the Pentium IV very well, it's too irregular and undocumented to bother studying.) The Athlon's u-ops are somewhat more powerful than the Pentium III u-ops which accounts for its superior peak performance. Counting instructions on x86 is pretty dumb. The internal u-ops are much closer to the conventional notion of a RISC instruction. Think of x86 as an ARM processor permanently stuck in Thumb decoding mode, supposing that Thumb has instructions which corresponded to one to four regular instructions (which are called u-ops in the x86 world). P6 u-ops are slightly less powerful than conventional RISC instructions (two u-ops are required for a single memory load). Athlon u-ops are roughly equal to conventional RISC instructions. They lack the three operand mode, but make up for it by handling read/modify/write as a unitary form. The P6 core rarely executes less than two u-ops per clock unless stalled by branch misprediction or memory latency. Of course, it's possible to write bad code or bad compilers. However, I would state categorically that execution rates less than two u-ops per clock have nothing to do with limitations of the x86 instruction set design or the P6/Athlon core implementations. Deep OOO architectures excel at squashing resource conflicts and pipeline bubbles.
Oh yes, the cost and complexity of recompiling all existing binary code for the x86 has no complexity at all. Rather than having two companies with thousands of highly trained design engineers work out the kinks they are paid to master, let's get the whole world involved in a massive change-over to honour a false god which hasn't yet produced compelling practical evidence of its innate superiority.
The reason why this proposal won't be taken seriously is because it does expose extra complexity to the world at large (need for new compilers, optimization modes, validation, etc.) Complexities that can be handled behind the scenes are tackled aggressively no matter how great the complexity.
But if we are going to recompile the entire existing x86 code base, why don't we add a simple extension to the compiler to eliminate all buffer overflows made possible by sloppy programming? Surely that can't greatly complicate this marvellous proposal. In the next iteration of recompile world, how about we design a compiler than identifies and corrects bad software design and program architecture? No, let's just settle for making all of the x86 binaries 40% larger for no real benefit.
If there was any sense to this comment, the x86 would have proved such a disaster it was abandoned ten years ago. Many people think it should have been, that its continued existence is some bizarre aberration of rational forces.
In actual fact, the ugliness of the duckling was less of an impediment than advertised.
There are several consequences of large, flat register sets. First of all, if your register set greatly exceeds the number of in flight instructions, you have a lot of extra transistors in your register set sitting there, on average, doing nothing. Well, not nothing. They are sitting there adding extra capacitance and leakage to your register file, increasing path length, cycle times, power dissipationm, and routing complexity.
Second effect: large registers sets increase average instruction length. Larger average instruction lengths translates into a larger L1 instruction cache to achieve the same hit ratio. PPC requires a 40% larger I-cache to achieve the same effectiveness as the x86 I-cache.
Third effect: context switches take longer. If you want to actually use all those registers, your process has to save and restore them on every context switch.
Finally, there is the register set mirage. Modern implementations of x86 have approximately 40 general purpose registers. Only you can't see most of them. Six of these can be named to the instruction set at any given time. The others are in-flight copies of values previous named with the same names. This all happens transparently within an OOO processor model.
If x86 only had six GP registers in practice, it really would have died ten years ago. What it actually has is six GP registers you can name at any one time, which means only six GP registers you have to load and store on context switches, etc.
What did die ten years ago was the notion that convenience to the human assembly language programmer was worth a hill of beans. Good architectures are convenient to the silicon and the compiler.
Other aspects of x86 have proved more serious than the shortage of namable GP registers. To many instructions change the flag register affecting too many patterns of flag bits. That's hell for an OOO processor to patch back together. The floating stack was an abomination. Lack of a three operand instruction format is another significant liability.
On the other hand, the ill reputed RMW (read/modify/write) instruction mode is 90% of the reason the Athlon performs as well as it does. You get two memory transactions for the price of one address generation, translation, and cache contention analysis. It amounts to having the entire L1 cache available as a register set extension every other clock cycle (leaving half of you L1 cache cycles for other forms of work).
Having someone comment on the x86 is an excellent litmus test of the capacity for someone to dig deeper than their shallow preconceptions of elegance. If it were anything other than the despised x86, it's ability to scale from 4.77MHz to 10GHz would have been considered a marvel of engineering soundness. Sometimes ugliness has lessons to teach us. Who among us is prepared to listen?
I was there. The 6502 was hell on wheels. Scaling up a processor design which doesn't have a single GP register long enough to hold a memory address? Drugs man. I will say, however, that I quite liked the 6809. It was kind of fun to program the 6502, but when you look at code generation issues it was a complete disaster. The whole point is that the design of the 6502 can't scale up. There was a sweet spot for writing moderately complex video games by hand, but compilers aren't interested in sweet spots. Well, I knew compiler that was. If you put too many parens in an expression, it ran out of temporary registers because it was storing temporary values within a fixed resource that looked an awful lot like zero page on the 6502.
You're making this way to complicated. Very few devices need negative voltage sources (mostly RS-232 which is being phased out by USB). I'd say you could go a long, long way on 3.3 5 and 12. Voltages below 3.3 are better for welding than distributing power (I squared R). I've seen solid state converters which kick out respectable current at several voltage taps about the size of a standard network hub. I don't see cost savings as the primary motivation. Products could continue to sell the cheap vampires. But they could also be made compatible with a UPB plug. Vampires cost the world billions in wasted power since they give off heat even with no current draw. The solid state converters are more expensive, but also vastly more efficient. The main engineering problem I foresee is putting safety limits on aggregate current consumption. That probably adds more cost to the system than you would think. I think it's entirely a bootstrap problem. This is the kind of thing where government can step in for a few years and change the landscape. The oil industry would have never eliminated leaded gas on their own accord (not until they were sued blind). There must be a few billion walwarts in America alone. The environmental aspect of that leaves a lot to be desired.
People who argue points of the form "sends a message" are generally describing their particular set of emotional filters which are not nearly as widespread as they might imagine. Fortunately, arguments that fail to distinguish pragmatism from compromise are quickly discarded by those who do.
If BitMover so thinks, it should be written into the EULA where the word "reasonable" now presides. The point of my previous post was that people should evaluate the EULA exactly as written, as a lawyer would do. There's exactly as much rope coiled underneath that harpoon as the legal system defines that term legally.
As a user of the free BitKeeper license I've had a direct experience with Mr McVoy's "reasonable opinion". I will say first of all that I'm extremely pleased with the technical capabilities of the BitKeeper software. It's a superb fit for the distributed mode of development we practice here. I would extremely distressed to lose the use of this tool over petty licensing conditions.
That said, I see two traits in Larry McVoy as the person behind the terminology. One is the hard nosed "we're here to make a living" side where he steps up to the plate and makes unpleasant decisions when he feels he needs to protect his team and his company. The other trait is his feisty, confrontation rhetorical style where "my way or the highway" takes a front seat to "reasonable opinion". I'm not even sure that "reasonable opinion" was granted a rumble seat in my encounter.
Reasonable opinion means different things to different people. Perhaps it is a flaw in my own nature that I tend to be far too forgiving, but nevertheless that factors into my own standard of reasonable opinion. I was unable to detect a shread of commonality between my own standard and Larry's standard, whatever it might be.
I find this development to put me in an extremely awkward position. I have a fetish for good tools, and BitKeeper is an excellent tool. I banned the use of CVS in this shop (for our own source code) because I believe the use of CVS sends the message that compromise is acceptable. By far my strongest reason for adopting BitKeeper was to reinforce the message among my own team that sloppiness around the edges is not tolerated.
Soon we will be making additional hires and I have to ask myself "am I willing to subject the people we hire to the constraints of the BitKeeper license, now and in the future?" We are looking for the kinds of people who contribute to open source projects wherever they feel they have the skills to do so. I despise non-linearity in my own professional life, I certainly can't imagine becoming a conduit of non-linearity in the lives of the people I hire.
I admire Larry for standing up and doing what he feels is right to protect his team and his company. Where Larry crosses the line IMHO is conveying the message with pitchfork included. He carries a pitchfork in one hand, and writes "resonable" into his EULA with the other. That certainly has me looking over my shoulder. If I find myself shafted on Larry's pitchfork I'll be drinking alone.
My first move will be to establish an internal line of development on one of the open source alternatives.
I may yet choose BitKeeper for its technical superiority and commercial support, but certainly not without a backup parachute strapped on my back.
I thought about this again while carefully scraping away a week's worth of stubble from around a small crater at the corner of my mouth where an infected wisker is no more.
First of all, you need to spend some quality time with the right caliber of inspiration. Start with this web site
Edge, then read some Marshall McLuhan, then some of those crazy deconstructionists and that nutbar Japanese guy who terminated history, Fukiwawa.
If it were me, I'd be inclined toward something snide such as "Cyber Hermeneutics" or plainly evasive, such as "Neo Post Modernism".
Slashdot Mirror
In physics the abstractions leak. Newton's laws leak like crazy. Einstein's theories leak. Presently there are no fundamental theories in physics which don't leak like crazy when quantum mechanics and gravity interact.
In sports the abstractions leak. That's how we get players like Gretzky and pay a lot of money to watch what they do.
And how about the reason why didn't C++ didn't define a native string type. Because there isn't any way to implement a string class that serves all possible applications. The premise of C++ is not being stuck with someone else's choice on what part of the abstraction should leak. Because C++ doesn't define a native string type, the user is free to replace the default standard string implementation with any other string implementation and have it integrate with the language on an equal footing with the standard string type.
If a language is imposes standard abstractions it only takes one abstraction you can't live with to make that choice of language untenable. Which is how C++ has been so successful despite being the worst of all possible languages (except for all the others).
Please, somebody post the link to the story about the lawsuit between Fujitsu and the supplier who added phosporous to the molding compound. I've bought a fair number of Fujitsu disk drives mostly they worked great. Of the four drives I bought affected with the recent problem, 2.5 have failed. I don't think it was Fujitsu's fault. That said, Fujitsu has done a miserable job of owning up to the problem once they realized what had happened. The other day I heard that a local school had to return 40% of all drives ordered from this drive series.
Just to keep myself honest, I force myself to do sysadmin tasks in vi. Generally I use emacs for source code. Tonight I used vi to write a small Perl program to change a bunch of URLs in a bunch of web pages to a different layout system. I've been writing a lot of PHP lately and I haven't used Perl for a couple of years. The entire project is a refresher course.
Editing Perl with vi! Talk about a cruft implosion. To make things worse, I was using a very bad version of vi that came standard with Debian potato. It doesn't indicate on the screen that you are in insert mode. Certain kinds of cursor motion break insert mode when you least expect it. It doesn't even have a line number indicator on the status bar.
Aside from all the obvious reasons I've been trying to figure out why I hate vi as much as I do. I've put up with worse and complained less. Yet somehow as much as I try to accept vi for what it is I fail miserably.
I was paying special attention to my vi misery as I permuted Perl's line noise. Here's what it comes down to. If you have N characters on a line, there are N+1 positions where you might wish to insert a new character. Yet in vi you can't actually reach all these positions without first entering insert mode: the position that appends to the end of the line is not available. This leads to the ludicrous effect that whenever you cancel insert mode, your cursor moves one character to the left (unless you are already at the beginning of the line). Oh, and you can place yourself at the end of a line when you are not in insert mode--if the line happens to be completely empty.
So there I am getting slap happy with vi (banging escape whenever I forget what mode I'm in, which is almost always) and every time I bang escape I have to watch carefully to see if my cursor skids left.
It's bad enough having two modes. But did the concept of current position also have to be different between the modes? Incredible. Just for this one reason vi constantly gives me the feeling I'm babysitting a naughty child.
On the other hand, emacs might be barroque, but I rarely spend much time thinking about my hands unless I'm trying to do something that isn't habitual. I rarely use a feature in emacs I didn't learn in the first two days. "feature freeze" in emacs is modal in its own way. One moment you are working productively, the next moment (or hour, or day) you are whittling away at one billion options you don't want. But there's the difference: emacs is modal once an hour, vi changes modes faster than you can blink, or think.
There's a general rule (apparently unknown to the anticruft crusader who launched this topic) that cruft is eliminated only when something new comes along that's ten times better. Only ten times. And vi still exists. Amazing.
With great dilligence I avoided allowing Flash to install itself on my primary Windows machine. Then one day my brother came over with a friend, and five minutes later his friend had installed Flash so he could see the cheesy entry page to some mountain bike vendor charging $200 to the negative gram. Good work Dale, you made my virus of the month club. Actually, I'm not sure whether Dale is a virus or a trojan or a worm.
I figure there's no hope for Flash ever becoming as useful to the end user after installation as it is before installation. Flash uninstalled is the easiest method of all for eliminating tons of obnoxious anti content.
Four desktops, each two monitors in size. First desktop: journal, several tabbed browser windows for general research. Second desktop: on the left three emacs windows, one for front end PHP code, one for back end PHP code, one for CSS stylesheets; on the right, four console windows open to various points in the source tree where I can do source code control manipulations and run commands to publish the new code to various test servers. Third desktop: left side, various SSH consoles open to web servers and capturing web server log outputs; right side, three different types of browsers to view the test pages. Four window: left side, free for hire; right side, SSH sessions to the embedded devices that capture our data and to the company's corporate web server where functions as a bulletin board for the development team. And then there are two more desktops I keep for stuff I'm only working on casually. Use some instances of Dia for making diagrams to post into the corporate workweb, image processing tools, etc. And the left monitor itself is special: I press the input button it switches to display the output of a W2K machine which I also use to test web pages and for browsing web sites that suck in Mozilla.
But that's just me, right? Not "definitive". Use your brain, guy. I used to buy shelfloads of C++ books. My desktop was my second monitor. You know, that chunk of wood that supports your mouse and keyboard. I used to look down there to learn things I needed to know while I was working. It has been two years since I bought a book to prop on my desktop. Any book I buy now sends me to the big leather chair. What else has changed? Could it be that my work is smattered across seven different embedded systems and web servers? That never happened back when I was running a Pentium system. And let's not forget you can almost fit the list of all XML standards on a single 19" monitor if you use small fonts (and you never actually click into them). And it's not possible that I could need to reference materials on Perl, Python, JavaScript, and PHP all in the same hour. Or that I might be running tail -f | grep on six different files under
My suggestion is give up. The definitive study that having one hand tied behind your back impedes your work flow probably doesn't exist.
Undergraduate hang wringing and so much Bailey's you can't tell whether the alcohol or the sugar is having the worst effect. It seems to me that writing great programs has a lot to do with creating good namespaces and chosing your names well.
// constructor // destructor
class this {
pre this ();
post this ();
};
At least that partially makes sense, unlike anything else named "modernism" by people who are already dead.
Yesterday at 6:00p.m. I had a box of parts. By 9:00p.m. I had a working system with the Debian base install and OpenSSH configured with my public key installed. By 10:00p.m. the machine was installed and working fine in our server closet in our small office downtown and I could access the machine remotely via SSH to complete the configuration.
Most painful step: it took a full hour to install the giant PAL 8045 heatsink with exactly the right amount of thermal paste. Second most painful step: discovering that the 18" IDE cables wouldn't read from the hotswap IDE controllers to the right IDE connector, having to pull the whole thing out and lowering it one slot. Pain caused by Debian? One of the two floppies I used to boot the machine failed to format on the first attempt.
Both my network interfaces came up automatically, my hot swap IDE RAID was detected automatically, my network install worked automatically. I created all my partitions and mount points without ever leaving the installation script. The average table or chair from IKEA take longer to assemble.
I think the real complaint in that review is that Debian comes as unfinished pine and he was expecting a dark walnut stain and then he makes it sound like Debian amounts to chopping your own trees.
I've heard for years that SCSI drives have some mythical additional quality as compared to IDE drives, even though everyone knows the drives have 90% of their components in common.
I welcome this change in the IDE drive industry. What the drive companies are trying to capture is the "I don't know the difference" consumer "so I won't a dime more than the store across the street".
Among those of us who do know the difference and who do care about their data there will be a backlash against the new state of affairs. What we will see is a new niche for premium IDE hard drives that are mechanically and electrically as reliable as reputable SCSI drives. Those of us who care will pay an extra $30 per drive and we'll be glad we did.
The philosophy you are expressing is known as extremism. Works just fine in the Middle East.
If you start with a group of ten people who are managing to cooperate just fine, and then you add Richard Stallman to the group, how many trouble makers do you now have? Ten. Everyone _except_ RMS. Why can't they all cooperate? It's such a terrible puzzle.
This is the most peculiar post I've ever read bonused for insight: "It's all up to whoever chooses." Would that includes the choices of the slaves or not? I thought that issue had something to do with the fact that the slaves were, correct me if I'm wrong, also humans. If "free software" means the same thing as "free humans" we're all in big trouble.
I'm typing on one of those stiff IBM keyboards today. Whenever I switch to a stiff keyboard, entire word fragments go missing. I think it's a trick my hands play when running up hill. I'd send them down to the minors, but they're on a one-way contract with a no-trade clause.
"is" from the first sentence should have been "isn't"
I'm convinced my hands are living evidence for Chomsky's theory of traces. The word fragments that go missing are the ones which don't resolve until word order is set. It's disturbing that my typing errors come out as correctly spelled words I didn't intend to use. It's like waking up one day and discovering your own mental processes work much like the MS Office grammar checker which allows you to make a complete ass out of yourself if your word forms are plausible.
This is a hierarchy of smarterness. It's a battle of Smaug against riddling hobbits and the arrow of destiny. Be careful where you stand when DRM falls, it will make a big ugly splash.
Eventually the dragons *will* win if they learn hard lessons from every mistake. The only question is whether the dragon, once perfectly armoured, will still be able to fly, or whether it will be so encrusted with layer upon layer of protective armour it can't really hurt anyone who doesn't stumble into its path. Copy protection died in the late eighties when people discovered it was more onerous than advantageous. When copy protection actually works, it drives your legitimate customers crazy. That's my hope for DRM, that it becomes so good no one can stand it.
Hey Levi, what's Latin for "I came, I saw, I pissed on my own face". Show some respect for the complexity of language.
What intellectual creation in this world doesn't have a fistful of lousy ties in the bottom drawer of the dresser? The existence of the BCD instruction, which is probably trapped in microcode by all modern implementations, is evidence of what exactly? If you squeezed out the vast majority of all the dubious instructions which remain in the formal x86 instruction set, I have serious doubts you would gain 5% on any significant metric (thermal loss, die size, clock frequency, etc.) The practical core of the x86 instruction set was firmly established by the 486. The majority of useful integer instructions on a 486 take exactly one clock cycle. In many programs 99% of all generated instructions come from this core group.
Complaining about crufty ties in the bottom drawer is a serious misdirection of mental resources.
I guess most people don't comprehend the "red queen" nature of processor scaling. You have to as fast as you can to stay right where you are.
Increasing clock speed is not a linear gain. Let's imagine we scale the 66MHz 486 to several GHz without making any significant changes to the core. How fast would it run? It would be stalled three clock cycles out of every four, or worse. It wouldn't run 10% of the speed of a modern core at the same clock speed. That order ten magnitude constitutes a long series of "paltry gains" paying the price for maintaining linearity while clock frequency takes all the credit. And I'm not even being fair to the paltry gains, because IPC has indeed increased greatly while latency hazards have scaled by several orders of magnitude.
There are no end of tight loops out there where the x86 averages nearly three u-ops per clock cycle, the theoretic limit for Pentium III / Athlon cores. (I don't know the Pentium IV very well, it's too irregular and undocumented to bother studying.) The Athlon's u-ops are somewhat more powerful than the Pentium III u-ops which accounts for its superior peak performance. Counting instructions on x86 is pretty dumb. The internal u-ops are much closer to the conventional notion of a RISC instruction. Think of x86 as an ARM processor permanently stuck in Thumb decoding mode, supposing that Thumb has instructions which corresponded to one to four regular instructions (which are called u-ops in the x86 world). P6 u-ops are slightly less powerful than conventional RISC instructions (two u-ops are required for a single memory load). Athlon u-ops are roughly equal to conventional RISC instructions. They lack the three operand mode, but make up for it by handling read/modify/write as a unitary form. The P6 core rarely executes less than two u-ops per clock unless stalled by branch misprediction or memory latency. Of course, it's possible to write bad code or bad compilers. However, I would state categorically that execution rates less than two u-ops per clock have nothing to do with limitations of the x86 instruction set design or the P6/Athlon core implementations. Deep OOO architectures excel at squashing resource conflicts and pipeline bubbles.
Oh yes, the cost and complexity of recompiling all existing binary code for the x86 has no complexity at all. Rather than having two companies with thousands of highly trained design engineers work out the kinks they are paid to master, let's get the whole world involved in a massive change-over to honour a false god which hasn't yet produced compelling practical evidence of its innate superiority.
The reason why this proposal won't be taken seriously is because it does expose extra complexity to the world at large (need for new compilers, optimization modes, validation, etc.) Complexities that can be handled behind the scenes are tackled aggressively no matter how great the complexity.
But if we are going to recompile the entire existing x86 code base, why don't we add a simple extension to the compiler to eliminate all buffer overflows made possible by sloppy programming? Surely that can't greatly complicate this marvellous proposal. In the next iteration of recompile world, how about we design a compiler than identifies and corrects bad software design and program architecture? No, let's just settle for making all of the x86 binaries 40% larger for no real benefit.
If there was any sense to this comment, the x86 would have proved such a disaster it was abandoned ten years ago. Many people think it should have been, that its continued existence is some bizarre aberration of rational forces.
In actual fact, the ugliness of the duckling was less of an impediment than advertised.
There are several consequences of large, flat register sets. First of all, if your register set greatly exceeds the number of in flight instructions, you have a lot of extra transistors in your register set sitting there, on average, doing nothing. Well, not nothing. They are sitting there adding extra capacitance and leakage to your register file, increasing path length, cycle times, power dissipationm, and routing complexity.
Second effect: large registers sets increase average instruction length. Larger average instruction lengths translates into a larger L1 instruction cache to achieve the same hit ratio. PPC requires a 40% larger I-cache to achieve the same effectiveness as the x86 I-cache.
Third effect: context switches take longer. If you want to actually use all those registers, your process has to save and restore them on every context switch.
Finally, there is the register set mirage. Modern implementations of x86 have approximately 40 general purpose registers. Only you can't see most of them. Six of these can be named to the instruction set at any given time. The others are in-flight copies of values previous named with the same names. This all happens transparently within an OOO processor model.
If x86 only had six GP registers in practice, it really would have died ten years ago. What it actually has is six GP registers you can name at any one time, which means only six GP registers you have to load and store on context switches, etc.
What did die ten years ago was the notion that convenience to the human assembly language programmer was worth a hill of beans. Good architectures are convenient to the silicon and the compiler.
Other aspects of x86 have proved more serious than the shortage of namable GP registers. To many instructions change the flag register affecting too many patterns of flag bits. That's hell for an OOO processor to patch back together. The floating stack was an abomination. Lack of a three operand instruction format is another significant liability.
On the other hand, the ill reputed RMW (read/modify/write) instruction mode is 90% of the reason the Athlon performs as well as it does. You get two memory transactions for the price of one address generation, translation, and cache contention analysis. It amounts to having the entire L1 cache available as a register set extension every other clock cycle (leaving half of you L1 cache cycles for other forms of work).
Having someone comment on the x86 is an excellent litmus test of the capacity for someone to dig deeper than their shallow preconceptions of elegance. If it were anything other than the despised x86, it's ability to scale from 4.77MHz to 10GHz would have been considered a marvel of engineering soundness. Sometimes ugliness has lessons to teach us. Who among us is prepared to listen?
I was there. The 6502 was hell on wheels. Scaling up a processor design which doesn't have a single GP register long enough to hold a memory address? Drugs man. I will say, however, that I quite liked the 6809. It was kind of fun to program the 6502, but when you look at code generation issues it was a complete disaster. The whole point is that the design of the 6502 can't scale up. There was a sweet spot for writing moderately complex video games by hand, but compilers aren't interested in sweet spots. Well, I knew compiler that was. If you put too many parens in an expression, it ran out of temporary registers because it was storing temporary values within a fixed resource that looked an awful lot like zero page on the 6502.
You're making this way to complicated. Very few devices need negative voltage sources (mostly RS-232 which is being phased out by USB). I'd say you could go a long, long way on 3.3 5 and 12. Voltages below 3.3 are better for welding than distributing power (I squared R). I've seen solid state converters which kick out respectable current at several voltage taps about the size of a standard network hub. I don't see cost savings as the primary motivation. Products could continue to sell the cheap vampires. But they could also be made compatible with a UPB plug. Vampires cost the world billions in wasted power since they give off heat even with no current draw. The solid state converters are more expensive, but also vastly more efficient. The main engineering problem I foresee is putting safety limits on aggregate current consumption. That probably adds more cost to the system than you would think. I think it's entirely a bootstrap problem. This is the kind of thing where government can step in for a few years and change the landscape. The oil industry would have never eliminated leaded gas on their own accord (not until they were sued blind). There must be a few billion walwarts in America alone. The environmental aspect of that leaves a lot to be desired.
People who argue points of the form "sends a message" are generally describing their particular set of emotional filters which are not nearly as widespread as they might imagine. Fortunately, arguments that fail to distinguish pragmatism from compromise are quickly discarded by those who do.
If BitMover so thinks, it should be written into the EULA where the word "reasonable" now presides. The point of my previous post was that people should evaluate the EULA exactly as written, as a lawyer would do. There's exactly as much rope coiled underneath that harpoon as the legal system defines that term legally.
As a user of the free BitKeeper license I've had a direct experience with Mr McVoy's "reasonable opinion". I will say first of all that I'm extremely pleased with the technical capabilities of the BitKeeper software. It's a superb fit for the distributed mode of development we practice here. I would extremely distressed to lose the use of this tool over petty licensing conditions.
That said, I see two traits in Larry McVoy as the person behind the terminology. One is the hard nosed "we're here to make a living" side where he steps up to the plate and makes unpleasant decisions when he feels he needs to protect his team and his company. The other trait is his feisty, confrontation rhetorical style where "my way or the highway" takes a front seat to "reasonable opinion". I'm not even sure that "reasonable opinion" was granted a rumble seat in my encounter.
Reasonable opinion means different things to different people. Perhaps it is a flaw in my own nature that I tend to be far too forgiving, but nevertheless that factors into my own standard of reasonable opinion. I was unable to detect a shread of commonality between my own standard and Larry's standard, whatever it might be.
I find this development to put me in an extremely awkward position. I have a fetish for good tools, and BitKeeper is an excellent tool. I banned the use of CVS in this shop (for our own source code) because I believe the use of CVS sends the message that compromise is acceptable. By far my strongest reason for adopting BitKeeper was to reinforce the message among my own team that sloppiness around the edges is not tolerated.
Soon we will be making additional hires and I have to ask myself "am I willing to subject the people we hire to the constraints of the BitKeeper license, now and in the future?" We are looking for the kinds of people who contribute to open source projects wherever they feel they have the skills to do so. I despise non-linearity in my own professional life, I certainly can't imagine becoming a conduit of non-linearity in the lives of the people I hire.
I admire Larry for standing up and doing what he feels is right to protect his team and his company. Where Larry crosses the line IMHO is conveying the message with pitchfork included. He carries a pitchfork in one hand, and writes "resonable" into his EULA with the other. That certainly has me looking over my shoulder. If I find myself shafted on Larry's pitchfork I'll be drinking alone.
My first move will be to establish an internal line of development on one of the open source alternatives.
I may yet choose BitKeeper for its technical superiority and commercial support, but certainly not without a backup parachute strapped on my back.
Caveat Emptor.
I thought about this again while carefully scraping away a week's worth of stubble from around a small crater at the corner of my mouth where an infected wisker is no more.
First of all, you need to spend some quality time with the right caliber of inspiration. Start with this web site Edge, then read some Marshall McLuhan, then some of those crazy deconstructionists and that nutbar Japanese guy who terminated history, Fukiwawa.
If it were me, I'd be inclined toward something snide such as "Cyber Hermeneutics" or plainly evasive, such as "Neo Post Modernism".
Dry, wet, and vapour.