The maturity threshhold is not put forward in terms of the computer science field, but in terms of human intellectual limits. Mature fields have the characteristic that 90% of all progress comes from people who are highly specialized within their niche with completely unexpected connections popping up between subjects that were thought to be unrelated.
A field is mature when much of the work concerns the relationships of things already known. CS isn't there yet.
The xor concept applied with bit masks leads to a very efficient method of performing an 8x8 bit block transpose in 3 passes over a pair of 32 bit integers (with shifting).
Hey, you should have cross posted that comment in the "biggest lie" thread instead. How can I count the ways?
- the bloated 286 era CISC instructions waste about 1% of the die in useless firmware (it hurts so bad) - the irregular encoding of the core instuctions makes the L1 i-cache vastly more space efficient than rigid encodings - the read modify write instructions (which RISC eschews) go a long way toward offsetting integer register pressure (check out the internals of the Athlon design you might learn something) - the small register file makes for faster context switches - orthogonality is a violation of Zipf's law which dictates the common operations should be idiomatic - 15 years and a factor of 1000 can't be wrong
Where x86 really does suck:
- the floating point stack is beyond redemption - irregularity in flag register update patterns - the thermal cost of all those parallel pipeline stages which turn all those supposed design liabilities into performance assets (50% more performance than the Power architecture at four times the power budget)
I'd guess that the nasty flag bits have more impact on scalability than the wonky instruction set encoding. Either update all the arithmetic flag bits or none at all. The OOO logic must absolutely pull its hair our trying to keep all those flag bit dependencies straight.
This post isn't as far off topic as it might seem on the surface.
I was there circa 1986 when the Apple camp was drinking the coolade about how RISC was going to bury CISC, while promising a real man's virtual memory system RSN (which they didn't deliver under OS X), while slagging the Wintel camp for not having a proper GUI, while sticking with their ridiculous "one size fits all" proposition that gradma's Mac was state of the art for the needs of a software developer. The biggest suck and blow of all time.
I remember reading a long time ago about how Apple put so much work into deciding which position on the drop down menus were quickest and most intuitive. But did they put the same amount of thought into the problem of having too many windows on a screen that was way too small? Not a chance.
Great, all the controls are on the window corners. If a window gets pushed off to the side, I can't access the controls that allow me to manipulate what portion of the window I need to see. So I drag it back into the middle, burying something else which I'll soon be digging out again.
Take a look at the scroll bars on the left side of any window (which MS faithfully copied). The little triangle that points up is how far away from the little triangle that points down? If I overshoot my target (which you tend to do when the scrolling accelerates) I'll just whip my mouse pointer down to the nether regions and scroll it back down a line. Oh wait, that triangle isn't on the screen because I moved the window down to get at the title bar for another window that wasn't where it needed to be a moment ago (and which will be hidden again as soon as I move this window up where I can get at the scroll arrow again).
I know, I'll skip all those steps by right clicking and selecting the menu item "size window to visible" which will return the control regions of the window frame to places my mouse can scratch. It's got to be there somewhere after all those studies of GUI efficiency.
This has been the problem with Apple all along: they always go after the straw man while leaving the real problems unsolved. 95% of my GUI interaction concerns positioning the portions of windows needing my attention to the right place and size. Half of that time is spent digging up the right controls because they are on the edges that keep getting pushed off the sides.
A friend was telling me today about the "magic button" on his favorite oscilloscope. Connect your probes, push the button, and it frames what it figures is the most important part of the signal for your attention all by itself. He figures his scope was right 90% of the time.
Why can't Apple accomplish the same thing? A magic button (if you can only have one) that makes exactly what I need to see visible in the most legible font size available for the task and the screen estate available.
Here's an example from just this morning. I had a horrible vendor web page to digest. The technical information window, which defined the product codes, had 1/3 of the left side of the window filled with menu crap that disgusted me. The other window had the price list in many columns depending on volume, but I was only interested in the single unit volumes in the left column.
What did I do? I pushed the technical window halfway off the screen to the left and the price list window halfway off the screen to the right. I could now see the part numbers, the definitions of those parts, and the prices all at the same time. (I can see why Apple might not rush to provide that feature.) But the all important "file" and "edit" menus (and back button) from the left window was now off the screen entirely, as were all the scrolling controls for the price window. Brilliant. Parts of this horror story were invented by MS (they can indeed innovate), but the bulk of it was borrowed from you-know-whom.
I'll buy a Mac when they invent a gesture where I can indicate what portion of each window needs my attention and the Mac automatically finds a way to make exactly those portions visible (while concealing everything that flashes) without crippling my ability to quickly flick my vantage point (in both directions) for each selected region of interest.
I'll buy a Mac when I can politely inform it not to bother displaying important text using a 3x5 font just because some stupid PDF file demands a full gestalt. Either make the text big enough for me to read, or don't display it at all. I'm not judging anything on artistic impression. My definition of ugliness is anything that gets between me and what I'm trying to understand. Is that such an odd thing to expect from the use of a computer?
After telling me about the magic button my friend laughed at me. "That magic button wouldn't appeal to you, you'd know every button on the entire oscilloscope". He's right, but he's wrong. I would know every button (it's my nature), but I'd love the magic button just the same. The magic button that says "show me exactly what I need to see scaled to the best size for my eyes to scrape out the information content so efficiently that I can't remember how it was presented two seconds later".
If the Mac could only have one button, and that was the button, I just might buy another Mac.
Close enough that estimating the magnitude mentally doesn't help. Using the rule of 70 you can estimate x^12 = 2 * 1844^12 as 1844 * 1.06, giving an x in the range of 1950 which as an upper bound gives very little. The lower bound by this method is around 1885. The mean of these two bounds is 1917. I guess that comes out so close because the two inputs are of similar magnitude. If you know the rule of 70 that whole process takes about 5 seconds mentally.
I run squid with an ad filter. I know I'm lucky that this works so well. Eventually the content people will invent a protocol which makes it a lot more difficult to scratch out the crap.
But not impossible. When marketting people talk about ads, they don't mean the message. They mean blinking, scrolling, flashing, and all other forms of obnoxious behaviour that make it difficult to attend to anything else on the page.
This kind of content I will always be able to eliminate. Simple rule: if it blinks, flashes, or scrolls, trash it.
I'm so vehemently opposed to obnoxious inputs that I'm more likely to make a mental note to refuse to buy the product than to to be swayed that the product behind the irritation is going to solve all of my problems. One could argue that I'm doing them a favor by scraping out the ads: someone is no longer paying to have those bytes delivered, and none of those bytes are making a dime off of me.
Here's where it has to end up: the advertiser who wants to push their blinking piece of crap under my nose is going to have to pay a very high price. My attention doesn't come cheap. If I'm such a desirable demographic, pay me for it.
This guy isn't talking about technology. He's talking about a sales mentality. It's not like the computer profession is any more immune to talking up big projects than any other profession. The physicists have their superconducting supercoliders. Engineers have their dams and scrapers (not necessarily a great idea after all).
Every industry sells sizzle. This guy managed to fall for it. He started to think the sizzle was the steak and now he's disenchanted when he discovers that sizzle has no nutrients.
This is one of those guys who wants to turn life into an appliance. These people say "you're not supposed to understand how a car works, it's just supposed to get you there". Would any other person nominate automotive dashboards as the pinnacle of UI design?
Here's a new idea. Where is the idiot light that comes on when you exit a highway at full speed onto a wet cloverleaf, dial in a tight turn, and then ride the brakes because you misjudged your speed?
Surprise, there's no little light on the dashboard that tells the customer how badly they drive. Why design a feedback mechanism that modifies behaviour when we can build airbags instead? Nice UI pal.
It's not computer science that sucks, it's people that suck. It always comes back to people getting what they really want, and what people really want, for the most part, is to look as good as possible while behaving like idiots.
This is the kind of stupid drivel that comes out of academia in between successful funding grants. Evolution is not a ladder of progress. Gould has devoted most of his life to debunking this myth and you still find educated people who can't figure this out.
Given the explosive changes in homonid culture over the last million, hundred thousand, ten thousand years, we're due for about a million years of breathing space while the rest of the planet adapts to new and extreme selective pressures created by the explosive growth in human population.
If we manage to extinguish 90% of the existing ecology, we'll enjoy some exciting new selective pressures to help drive our next catastrophic genetic change forward. Stay tuned for the next million years, it should be a doozy.
Just this morning I upgraded two of my OpenBSD machines to 3.0, along with the machine I built over the weekend from scratch.
I've used IPF since 2.6 and IMHO it wasn't nearly easy enough to use. Each line of the file is simple, but managing conceptual changes to your firewall is a royal pain in the Perl script. So far I've just read some of the new PF documentation and skimmed the PF list from time to time. I have no doubts that PF will mature rapidly, if it isn't already. I can't believe some of the new changes to the syntax weren't made years ago.
I've been working on the IP protocol stack for a couple of years, mainly looking at some of the latency problems with TCP/IP in signal contention networks (aka cell phones). TCP was designed to handle path contention networks and it doesn't handle signal contention at all well. The packet structure of IP is not rocket science. The TCP/IP stack is a much worse beast than what PF requires, especially if you add in all the IPv6 changes (substantial). I was reading this code yesterday. It's written clearly enough, yet hard to analyse case by case.
What matters for the new PF implementation is making correct syscalls and handling all the error returns correctly. The OpenBSD people know all the pitfalls from years of fixing other's mistakes. If you get the syscalls right, the remaining stability issue is largely semantic. The semantics are easily demonstrated by building rulesets that work.
The third area of concern are the efficiency tricks. I think will take another iteration at least to perfect. This area was probably neglected while the effort focussed on functionality, stability, and correctness. Try not to forget that the OpenBSD people have complete access to the IPF source code to guide them through the tricky spots.
Theo doesn't control OpenBSD, he just controls one tree. I wasn't at all unhappy that OpenBSD chose to write PF from scratch. They've done a good job on OpenSSH, which I regard as a more challenging problem. I also regard IPv6 integration as more challenging the PF. IPv6 and IPsec are a scary beast.
My next task is to start playing with new PF on all the new 3.0 boxes I've just configured. I'm not expecting any anguish. If my expectations are off base, I'll post again eating humble pie. I'm not saving my appetite, I don't think I'll need it.
That much said, Lessig is very reluctant to make open code a law. In The Future of Ideas, Lessig states that the government should "encourage" the development of open code. Such "encouragement" should not be coercive. According to Lessig there is no reason to ban or punish proprietary providers. But this view is hardly consistent with Lessig's view on the future of software copyright law. In Lessig's future system, proprietary providers are severely punished. They lose about 100 years of protection, the current copyright protection of life of author plus 70 year,s compared to five plus five years and then full disclosure.
An accountant is called onto the carpet by the owner of a major league baseball team. He storms "I lost six million dollars last year!" The accountant is stunned. "But I just filed the statements, and you made five million dollars last year." "Yes," retorts the owner, "and the year before that I made eleven million dollars. I lost six million dollars last year!!!"
Indeed, losing an entitlement you never deserved in the first place is a big step backwards. That's hardly what Lessig means by punative.
I've been playing around with the bitkeeper source control system for the last week. After reading this article I suddenly recalled that bitkeeper treats 2-way merge and 3-way merge as entirely separate features. N-way is not even discussed.
In some ways N-ways is merely a simple generalization of 2-way. The algorithmic complexity is not much different. The problem here is human scale. Humans cope well with two-way merge as a daily activity, cope with 3-way merge at the level of focus required by air-traffic control, and don't cope with 4-way merge under any sane circumstance.
Bitkeeper solves the problem by designing the architecture so that merges can be performed hierarchically. This is a feature that CVS sorely lacks.
Everyone knows that the success of projects is to a large measure determined by whether the architecture obviates the need to delve into N-way hell.
I also recall a project where a database supported two processes which concurrently updated the same dataset. During the design process we found a way to define the system so that each process was permitted to update a distinct set of columns, with maybe a column or two where one process was allowed to set a value and the process allowed to clear the value. Months of potential development effort slashed at the stoke of a pen. The first design dealt with the concurrency problem in a different way. Getting everyone to respect everywhere the subtle rules required by that design just doesn't happen on most projects.
What people tend to forget is that nuances of a software design create affordances with respect to the coding effort. When the pressure is on, people tend to grab onto the nearest handle. The handles hidden in the design have a momentous impact.
The C++ language is often criticized for having a model of class protection which is easily violated. Yes, that's true as a first order criticism. However, the C++ makes it fairly easy to figure out a way to manipulate the source code to find all the violations if you decide to look. These manipulations might be a temporary modification for the sole purpose of determining whether a certain kind of integrity exists. The C++ community doesn't lose any sleep over the first order weakness of the class protection model. We all know that violaters are playing a dangerous game.
On the other hand, there are certain kinds of abuse in the C language where it's practically impossible to turn up the smoking gun short of a complete source code audit.
The difference is not that C++ prevents programmers from abusing abstractions, but that it provides the necessary affordances to catch the people who do. The importance of these second order effects is vastly underestimated by those who plan.
You can see the extent of the problem wherever mouthy mights thrive. You know the people who always shout "it might happen" when the downside of anything they oppose is mentioned, as if might was an adverb of quantity. The implicit logic is that only a first order guarantee is sufficient, yet the recent study shows what everyone already knows, second order affordances generally suffice.
My experience is that projects are a morass of non-quantifiable psychology, experience, and intuition. The second order effects are never discussed on paper. It's left up to the cohesion of the team to impose the second order effects that make the first order effects possible.
It would be far more useful for the estimation people to spend their time figuring out the conditions under which a project becomes non-viable. Offer the programmers some kind of handle for coming back to management with their concerns about faulty second order effects, in language a whole lot less vague than what I'm using.
Wouldn't it be a fine start just to be able to limit ourselves to projects where the outcome is somewhat proportional to the effort expended. If we had proportionality already, the kind of estimation we have now would be a second order concern in its own right, rather than a masturbatory mission impossible.
In a different era, the freedom to study, change, copy, and redistribute a person's wetware used to be known as the Spanish Inquisition. I can never read RMS seriously past his first use of the word freedom. Only the borg use the word freedom in the RMS sense.
Imagine I create a program that successfully predicts the stock market. No doubt RMS would want the source code for that application too. There's a large category of software which exists as the encoding of human expertise. Not since the Spanish Inquisition has society believed it had the right to extract human expertise from its native form of embodiment. How is it any different to demand the freedom of "inspection" when the same expertise is encoded as a program?
On the other hand, it has always been an MS strategy to drive in the thin edge of the wedge until they accumulate so much market and mind share that resistance is futile.
What this article fails to point out is that the wedge is a moving target. By the time the world organizes in opposition to Word documents, the only streaming format left on the internet (and universally embedded into all consumer devices) will be Windows Media.
As fast as you yank one testicle out of the noose, the other testicle is snagged. 50% of the internet is porn. Several of the people I know who still run Windows would be very upset not to be able to watch Don Cherry from the CBC website. There's a sizable audience out there who really don't how hard you squeeze the Word testicle.
Here's an idea for the next killer application: the Maya of home generated porno stills. In the 10GHz billion transistor era, this will become entirely feasible. What programmer from the open source community is going to brag on their resume that they authored the sticky liquid plug-in? I won't feel deprived if I never get to see the source code for this sordid venture.
As far as the guy who "couldn't" apply for a job because they demanded his resume in Word format, he should be seeing the glass half full: he was spared the agony of applying for a job he was only going to hate anyway.
Economics is the science of modeling non-linear phenomena with linear systems. The entire economic context of this question is debious to begin with, but we're all intimately familiar with those distortions (cf. Dilbert). The purpose of estimating is to fit the activity of developing software into an economic context. If we weren't doing that we just go ahead an implement the software without the tea leaves.
What the estimation business needs to justify their existence is a formula that tells people before the fact that the linear assumptions have broken down. Otherwise it's just the science of dividing by zero.
It's the age old question: would you rather have someone who always insists that hse's right, but are only right most of the time, or someone who rarely insists that hse's right but always is right on those occasions?
There's subtlety here in the invocation of Komolgorov complexity. KC is measured with respect to an assumed universal computer. That can be as simple as a Turing machine with a handful of states. Or you can define the machine as including all the software already written that you have available for use. In other words the shortest string is the string that maximizes software reuse.
Estimation is never going to produce satifying results until we have a better foundation of code built for maximal reuse.
Given that the majority of programmers view the coding structures that promote reuse as cluttter (templates anyone?), it'll be a long time yet before KC has any bearing on this subject matter.
Please apply for your Ark B boarding pass. With the newly installed compression algorithm, the transporters now operate with 100 times greater efficiency. Signal your consent by flapping your gums and we will promptly beam you aboard.
And, no, "Open Source" is not an accurate characterization of this faction,
since their focus has been making Free Software compatible with business
people's thinking. A more correct name would have been "Free Software for
Business" - or something like that.
(Some dumb parser in/. whacked off the part I quoted in triple angle brockets. I didn't realize that preview was a debugging feature.)
I had to stop reading at this point. Appart from the GPL, the "non free" project most militant about its license is OpenBSD. Security requires transparency about your methods, yet obscurity about your deployment. Nobody in the security business goes around advertising the location of their sensitive parts.
OpenBSD was not created for business.
Let's look at OpenSSH. There are compilation options which allow you to defeat, at compile time, features you don't wish to deploy. There options are in a header file. If you change this header file, you have changed the source. Haven't you? If OpenBSD were under the GPL, I guess you'd have to publish those changes. Wouldn't you?
It's quite possible to embed in source code all kinds of information which other people have no need or right to know. OpenBSD does a great job of keeping the rights parts of the source code free to inspection. That hardly makes OpenBSD the "running dog" of corporate perversity as this interview seems to imply.
Moore's law is shaped by economic forces. Silicon chips don't "wear out" like metals and plastics. If the industry fails to obsolete the previous generation, what do they have to sell?
At any stage along the way, there are dozens of potential avenues for reaching the next cost/performance milestone. They simply "do what it takes" to get there.
3D could have been pursued long ago, but there was no real need. The advantage of making transistors smaller is that the speed increases while the voltage and heat decreases. If you can make a transistor smaller, you aren't going to pursue any other course.
Moore's law has not "drooped". There has always been something right around the corner to rescue Moore's law, and this article just adds to the evidence that nothing much has changed.
The significant event at the present time is that leakage current has become sizeable relative to peak operating current. Shrinking transistors is no longer a free lunch.
I think 3D will succeed in applications where wire latency is a bigger problem than heat dissipation. The biggest advantage of 3D is that it lets you cram more stuff closer together.
A couple of years ago I was researching acids and that lead to a web page devoted to the tremendous safety hazards involved in handling hydrofluoric acid. A few links later I found a web page that stated that most common cat-5 cable sheathing contains fluorine because they haven't found any good alternatives.
Plenum rated cable either doesn't contain fluorine or the extra shielding is designed to prevent the emission of fluorine compounds in the event of fire.
The list of compounds detected during the combustion of cat-5 sheathing looked like something from a chemicals weapons manual. Can't find the link right now. Maybe the Department of the Interior had this information exterminated.
I've been into computers since before MSDOS. I skipped 3.1/95 and jumped straight into NT which served me well enough as a platform for experimenting with C++. Eventually viruses and DLL-hell really began to bother me. My first experience with a free OS was my OpenBSD firewall system. Then I set up a FreeBSD desktop (no X), and then a Redhat box with X.
By this point I figured I had mastered enough to convert my primary desktop system into a Debian box.
I have a couple of geeky friends, much younger than me, who had been Debian as their primary systems for several years. I figured they could help me over a few hurdles.
First advice: run Debian stable. What about my Matrox G450 dual head? Second advice: for dual-head you need to run Debian testing. Fanfsckingtastic. Nothing like diving in at the deep end. It's easy, he promised me.
To make a long story short, I would have needed a Chinese alphabet to enumerate all the adventures that took place during step #1. Fonts didn't work, dual head didn't work (properly), the window manager didn't work (the first several times),.xinitrc still doesn't work (hangs X during startup if I put anything in there).
Then when I converted my NTS box to Debian (this time with Debian stable), we must have been at step 1zz by the time we had software RAID working on my Adaptec 3985 SCSI controller. At two different points in the process we "rectified" patches we downloaded by randomly commenting out blocks of code which were causing errors.
Both sides of the argument are wrong. Linux is easy to install if you get a good impedance match between the exact hardware you have in your box and the exact distribution you choose.
My best install ever was an OpenBSD box. I built if for a friend on a generic Celeron. Once through the install process it worked perfectly. Fifteen minutes from disklable to rock solid. The he "upgraded" the memory with a bad memory stick and fried every partition.
What people constantly overlook is that there is no "defining experience" with something like Linux. The phrase "for the user" ought to banned from our vocabulary. There is no "the user". There are millions of variations on a few common themes.
One machine I built with a DLink 530TX network adaptor. The next machine I built with a 530TX+ network adaptor. Surprise, surprise. The 530TX is a Via Rhine card, the 530TX+ is a Realtec card. After I noticed that detail, I was able to get in working again.
Then I built another machine, this time again with a DLink 530TX+ network card. On that machine every TCP connection experienced spiralling death syndrome: 100KB/s would soon become 5 bytes/s (on a local 100mb segment). Guess what? The two 530TX+ cards were different revisions (A versus C). One revision worked normally, the other didn't.
There is no such thing as universal hardware and no such thing as a universal "user".
A better analogy would be shock absorbers. You need to get the tension and damping correct on both ends of the bike. It depends on the terrain, the weight of the rider, and how much gas you have in the tank. Soft will soak up an uneven road surface, but it will also cause the bike to "lift" aggressively coming out of a hard turn (your stomach lifts at twice the speed, and your lunch twice as fast as that).
A bad bike is one where the wrong settings kill you. A good bike is one where the wrong settings scare you. An average bike is where you really can't tell, most of the time, whether the settings are good or bad. Windows aims for the average experience. Linux is poised on the knife edge between being bad and good. Sometimes it kills you, sometimes it saves your life. I've been on both sides of that experience and I really can't say what it is that Linux "needs".
I think the GPL/LGPL makes the most sense for systems, the least sense for libraries which support programming activities, where the BSD license is just fine.
In a similar context, I decided to create a GPL conformance suite for a protocol implementation under the BSD license.
I'm strongly against monomaniacal unitarianism. My bible is the book "In Praise of Diversity" by Freeman Dyson.
A conformance suite is useless unless everyone contributes back their extensions / additions. A protocol is useless unless it is widely adopted. I license is useless if it makes a political statement without making the world a better place. In situations like this, a little common sense goes a long way.
There is precious little difference between source code and any other kind of machine readable file format. If I encode my sexual preferences in XSLT (deviant, I admit), would that make it source code? (I could even invent a new transformation language: SLXT. Small, large, or extra large.)
Stallman is not particularly good at discerning shades of grey, so I'd have to fear that my SLXT data is source code as far as Stallman is concerned. I might have a bug in there somewhere that Stallman desperately wants to fix. The columns don't line up right or something.
Everything is source code. This isn't about source code, this is about everything. Stallman wants everything. We're past ideals here.
There are things in life which are better shared, and there are things in life which are better kept private. It has nothing to do with whether you call one piece of information source code, or give it an entirely different name.
Drooling? The kind of drooling you do when someone hits you on the head with a basebat and you can't see straight and everything seems smudged together.
I think I just missed the peak. Drove my MGA out of town (no top) and saw three bright ones right between the street lamps. When I finally did find the perfect place to park, I had spotted twenty before I found a comfortable way to slouch. Four or five per minute for the next hour or so. Three times I spotted several at once. One really bright on that went zap, dim, pow. Bright little red dot at the end. One left a trail that hung for about four seconds. All in all, worth having a car that likes 94 octane.
Kent's comments about arbitrary parentheses stuck in the back of my mind all day until suddenly the bubble burst.
r = (a/b)/(c/d);
How does Kent think I _should_ paren that?
r = a/b/(c/d); ???
Even if that's still correct, only a supreme wanker would write it that way.
Now lets get more technical. All variables are floats.
r = a+b+c;
In C/C++ the compiler gets to choose the evaluation order. Results might not be the same in the low precision
r = (a+b)+c;
Think you were clever? Wrong. In C/C++ the compiler is still free to reorder evaluation. Who thinks up these crazy rules?
temp = a+b;
r = temp+c;
Finally the compiler takes your word for it.
In Lisp, if I write (* (/ x 42.0) 42.0) I guess the runtime environment is not allowed to remove the costly division.
Personally I think we need to get with the program and start using symbol sets with about twice as many grouping sets. One set of parens for phrasing, another to mandate a fixed evaluation order.
People often complain that overloading is one of the worst features of C++. I agree. But not the operator overloading. The worst feature of C++ is the syntactic overloading of () to define function argument lists as well as to supply arguments for a function call. Not to mention the use of >> as an operator when the angle brackets are sorely needed to denote template parameters.
The subject of delimiter sets runs far deeper than just making it easy for emacs to hop forward and backward when the human eye is jangled.
Slashdot Mirror
xor r4, r4, r5
This is supposed to be sane? I know of many human languages with the grammatical structure:
verb subject object indirect-object
Not.
The maturity threshhold is not put forward in terms of the computer science field, but in terms of human intellectual limits. Mature fields have the characteristic that 90% of all progress comes from people who are highly specialized within their niche with completely unexpected connections popping up between subjects that were thought to be unrelated.
A field is mature when much of the work concerns the relationships of things already known. CS isn't there yet.
Bubble sort gets a bad rap being the butt of every joke. Bubble sort was invented as the optimal sorting algorithm for a Turing machine.
The xor concept applied with bit masks leads to a very efficient method of performing an 8x8 bit block transpose in 3 passes over a pair of 32 bit integers (with shifting).
Hey, you should have cross posted that comment in the "biggest lie" thread instead. How can I count the ways?
- the bloated 286 era CISC instructions waste about 1% of the die in useless firmware (it hurts so bad)
- the irregular encoding of the core instuctions makes the L1 i-cache vastly more space efficient than rigid encodings
- the read modify write instructions (which RISC eschews) go a long way toward offsetting integer register pressure (check out the internals of the Athlon design you might learn something)
- the small register file makes for faster context switches
- orthogonality is a violation of Zipf's law which dictates the common operations should be idiomatic
- 15 years and a factor of 1000 can't be wrong
Where x86 really does suck:
- the floating point stack is beyond redemption
- irregularity in flag register update patterns
- the thermal cost of all those parallel pipeline stages which turn all those supposed design liabilities into performance assets (50% more performance than the Power architecture at four times the power budget)
I'd guess that the nasty flag bits have more impact on scalability than the wonky instruction set encoding. Either update all the arithmetic flag bits or none at all. The OOO logic must absolutely pull its hair our trying to keep all those flag bit dependencies straight.
This post isn't as far off topic as it might seem on the surface.
I was there circa 1986 when the Apple camp was drinking the coolade about how RISC was going to bury CISC, while promising a real man's virtual memory system RSN (which they didn't deliver under OS X), while slagging the Wintel camp for not having a proper GUI, while sticking with their ridiculous "one size fits all" proposition that gradma's Mac was state of the art for the needs of a software developer. The biggest suck and blow of all time.
I remember reading a long time ago about how Apple put so much work into deciding which position on the drop down menus were quickest and most intuitive. But did they put the same amount of thought into the problem of having too many windows on a screen that was way too small? Not a chance.
Great, all the controls are on the window corners. If a window gets pushed off to the side, I can't access the controls that allow me to manipulate what portion of the window I need to see. So I drag it back into the middle, burying something else which I'll soon be digging out again.
Take a look at the scroll bars on the left side of any window (which MS faithfully copied). The little triangle that points up is how far away from the little triangle that points down? If I overshoot my target (which you tend to do when the scrolling accelerates) I'll just whip my mouse pointer down to the nether regions and scroll it back down a line. Oh wait, that triangle isn't on the screen because I moved the window down to get at the title bar for another window that wasn't where it needed to be a moment ago (and which will be hidden again as soon as I move this window up where I can get at the scroll arrow again).
I know, I'll skip all those steps by right clicking and selecting the menu item "size window to visible" which will return the control regions of the window frame to places my mouse can scratch. It's got to be there somewhere after all those studies of GUI efficiency.
This has been the problem with Apple all along: they always go after the straw man while leaving the real problems unsolved. 95% of my GUI interaction concerns positioning the portions of windows needing my attention to the right place and size. Half of that time is spent digging up the right controls because they are on the edges that keep getting pushed off the sides.
A friend was telling me today about the "magic button" on his favorite oscilloscope. Connect your probes, push the button, and it frames what it figures is the most important part of the signal for your attention all by itself. He figures his scope was right 90% of the time.
Why can't Apple accomplish the same thing? A magic button (if you can only have one) that makes exactly what I need to see visible in the most legible font size available for the task and the screen estate available.
Here's an example from just this morning. I had a horrible vendor web page to digest. The technical information window, which defined the product codes, had 1/3 of the left side of the window filled with menu crap that disgusted me. The other window had the price list in many columns depending on volume, but I was only interested in the single unit volumes in the left column.
What did I do? I pushed the technical window halfway off the screen to the left and the price list window halfway off the screen to the right. I could now see the part numbers, the definitions of those parts, and the prices all at the same time. (I can see why Apple might not rush to provide that feature.) But the all important "file" and "edit" menus (and back button) from the left window was now off the screen entirely, as were all the scrolling controls for the price window. Brilliant. Parts of this horror story were invented by MS (they can indeed innovate), but the bulk of it was borrowed from you-know-whom.
I'll buy a Mac when they invent a gesture where I can indicate what portion of each window needs my attention and the Mac automatically finds a way to make exactly those portions visible (while concealing everything that flashes) without crippling my ability to quickly flick my vantage point (in both directions) for each selected region of interest.
I'll buy a Mac when I can politely inform it not to bother displaying important text using a 3x5 font just because some stupid PDF file demands a full gestalt. Either make the text big enough for me to read, or don't display it at all. I'm not judging anything on artistic impression. My definition of ugliness is anything that gets between me and what I'm trying to understand. Is that such an odd thing to expect from the use of a computer?
After telling me about the magic button my friend laughed at me. "That magic button wouldn't appeal to you, you'd know every button on the entire oscilloscope". He's right, but he's wrong. I would know every button (it's my nature), but I'd love the magic button just the same. The magic button that says "show me exactly what I need to see scaled to the best size for my eyes to scrape out the information content so efficiently that I can't remember how it was presented two seconds later".
If the Mac could only have one button, and that was the button, I just might buy another Mac.
Close enough that estimating the magnitude mentally doesn't help. Using the rule of 70 you can estimate x^12 = 2 * 1844^12 as 1844 * 1.06, giving an x in the range of 1950 which as an upper bound gives very little. The lower bound by this method is around 1885. The mean of these two bounds is 1917. I guess that comes out so close because the two inputs are of similar magnitude. If you know the rule of 70 that whole process takes about 5 seconds mentally.
I run squid with an ad filter. I know I'm lucky that this works so well. Eventually the content people will invent a protocol which makes it a lot more difficult to scratch out the crap.
But not impossible. When marketting people talk about ads, they don't mean the message. They mean blinking, scrolling, flashing, and all other forms of obnoxious behaviour that make it difficult to attend to anything else on the page.
This kind of content I will always be able to eliminate. Simple rule: if it blinks, flashes, or scrolls, trash it.
I'm so vehemently opposed to obnoxious inputs that I'm more likely to make a mental note to refuse to buy the product than to to be swayed that the product behind the irritation is going to solve all of my problems. One could argue that I'm doing them a favor by scraping out the ads: someone is no longer paying to have those bytes delivered, and none of those bytes are making a dime off of me.
Here's where it has to end up: the advertiser who wants to push their blinking piece of crap under my nose is going to have to pay a very high price. My attention doesn't come cheap. If I'm such a desirable demographic, pay me for it.
This guy isn't talking about technology. He's talking about a sales mentality. It's not like the computer profession is any more immune to talking up big projects than any other profession. The physicists have their superconducting supercoliders. Engineers have their dams and scrapers (not necessarily a great idea after all).
Every industry sells sizzle. This guy managed to fall for it. He started to think the sizzle was the steak and now he's disenchanted when he discovers that sizzle has no nutrients.
This is one of those guys who wants to turn life into an appliance. These people say "you're not supposed to understand how a car works, it's just supposed to get you there". Would any other person nominate automotive dashboards as the pinnacle of UI design?
Here's a new idea. Where is the idiot light that comes on when you exit a highway at full speed onto a wet cloverleaf, dial in a tight turn, and then ride the brakes because you misjudged your speed?
Surprise, there's no little light on the dashboard that tells the customer how badly they drive. Why design a feedback mechanism that modifies behaviour when we can build airbags instead? Nice UI pal.
It's not computer science that sucks, it's people that suck. It always comes back to people getting what they really want, and what people really want, for the most part, is to look as good as possible while behaving like idiots.
This is the kind of stupid drivel that comes out of academia in between successful funding grants. Evolution is not a ladder of progress. Gould has devoted most of his life to debunking this myth and you still find educated people who can't figure this out.
Given the explosive changes in homonid culture over the last million, hundred thousand, ten thousand years, we're due for about a million years of breathing space while the rest of the planet adapts to new and extreme selective pressures created by the explosive growth in human population.
If we manage to extinguish 90% of the existing ecology, we'll enjoy some exciting new selective pressures to help drive our next catastrophic genetic change forward. Stay tuned for the next million years, it should be a doozy.
Just this morning I upgraded two of my OpenBSD machines to 3.0, along with the machine I built over the weekend from scratch.
I've used IPF since 2.6 and IMHO it wasn't nearly easy enough to use. Each line of the file is simple, but managing conceptual changes to your firewall is a royal pain in the Perl script. So far I've just read some of the new PF documentation and skimmed the PF list from time to time. I have no doubts that PF will mature rapidly, if it isn't already. I can't believe some of the new changes to the syntax weren't made years ago.
I've been working on the IP protocol stack for a couple of years, mainly looking at some of the latency problems with TCP/IP in signal contention networks (aka cell phones). TCP was designed to handle path contention networks and it doesn't handle signal contention at all well. The packet structure of IP is not rocket science. The TCP/IP stack is a much worse beast than what PF requires, especially if you add in all the IPv6 changes (substantial). I was reading this code yesterday. It's written clearly enough, yet hard to analyse case by case.
What matters for the new PF implementation is making correct syscalls and handling all the error returns correctly. The OpenBSD people know all the pitfalls from years of fixing other's mistakes. If you get the syscalls right, the remaining stability issue is largely semantic. The semantics are easily demonstrated by building rulesets that work.
The third area of concern are the efficiency tricks. I think will take another iteration at least to perfect. This area was probably neglected while the effort focussed on functionality, stability, and correctness. Try not to forget that the OpenBSD people have complete access to the IPF source code to guide them through the tricky spots.
Theo doesn't control OpenBSD, he just controls one tree. I wasn't at all unhappy that OpenBSD chose to write PF from scratch. They've done a good job on OpenSSH, which I regard as a more challenging problem. I also regard IPv6 integration as more challenging the PF. IPv6 and IPsec are a scary beast.
My next task is to start playing with new PF on all the new 3.0 boxes I've just configured. I'm not expecting any anguish. If my expectations are off base, I'll post again eating humble pie. I'm not saving my appetite, I don't think I'll need it.
An accountant is called onto the carpet by the owner of a major league baseball team. He storms "I lost six million dollars last year!" The accountant is stunned. "But I just filed the statements, and you made five million dollars last year." "Yes," retorts the owner, "and the year before that I made eleven million dollars. I lost six million dollars last year!!!"
Indeed, losing an entitlement you never deserved in the first place is a big step backwards. That's hardly what Lessig means by punative.
I've been playing around with the bitkeeper source control system for the last week. After reading this article I suddenly recalled that bitkeeper treats 2-way merge and 3-way merge as entirely separate features. N-way is not even discussed.
In some ways N-ways is merely a simple generalization of 2-way. The algorithmic complexity is not much different. The problem here is human scale. Humans cope well with two-way merge as a daily activity, cope with 3-way merge at the level of focus required by air-traffic control, and don't cope with 4-way merge under any sane circumstance.
Bitkeeper solves the problem by designing the architecture so that merges can be performed hierarchically. This is a feature that CVS sorely lacks.
Everyone knows that the success of projects is to a large measure determined by whether the architecture obviates the need to delve into N-way hell.
I also recall a project where a database supported two processes which concurrently updated the same dataset. During the design process we found a way to define the system so that each process was permitted to update a distinct set of columns, with maybe a column or two where one process was allowed to set a value and the process allowed to clear the value. Months of potential development effort slashed at the stoke of a pen. The first design dealt with the concurrency problem in a different way. Getting everyone to respect everywhere the subtle rules required by that design just doesn't happen on most projects.
The best book on the subject is the psychology of everyday things
What people tend to forget is that nuances of a software design create affordances with respect to the coding effort. When the pressure is on, people tend to grab onto the nearest handle. The handles hidden in the design have a momentous impact.
Some of the most important affordances are second order effects.
The C++ language is often criticized for having a model of class protection which is easily violated. Yes, that's true as a first order criticism. However, the C++ makes it fairly easy to figure out a way to manipulate the source code to find all the violations if you decide to look. These manipulations might be a temporary modification for the sole purpose of determining whether a certain kind of integrity exists. The C++ community doesn't lose any sleep over the first order weakness of the class protection model. We all know that violaters are playing a dangerous game.
On the other hand, there are certain kinds of abuse in the C language where it's practically impossible to turn up the smoking gun short of a complete source code audit.
The difference is not that C++ prevents programmers from abusing abstractions, but that it provides the necessary affordances to catch the people who do. The importance of these second order effects is vastly underestimated by those who plan.
You can see the extent of the problem wherever mouthy mights thrive. You know the people who always shout "it might happen" when the downside of anything they oppose is mentioned, as if might was an adverb of quantity. The implicit logic is that only a first order guarantee is sufficient, yet the recent study shows what everyone already knows, second order affordances generally suffice.
My experience is that projects are a morass of non-quantifiable psychology, experience, and intuition. The second order effects are never discussed on paper. It's left up to the cohesion of the team to impose the second order effects that make the first order effects possible.
It would be far more useful for the estimation people to spend their time figuring out the conditions under which a project becomes non-viable. Offer the programmers some kind of handle for coming back to management with their concerns about faulty second order effects, in language a whole lot less vague than what I'm using.
Wouldn't it be a fine start just to be able to limit ourselves to projects where the outcome is somewhat proportional to the effort expended. If we had proportionality already, the kind of estimation we have now would be a second order concern in its own right, rather than a masturbatory mission impossible.
In a different era, the freedom to study, change, copy, and redistribute a person's wetware used to be known as the Spanish Inquisition. I can never read RMS seriously past his first use of the word freedom. Only the borg use the word freedom in the RMS sense.
Imagine I create a program that successfully predicts the stock market. No doubt RMS would want the source code for that application too. There's a large category of software which exists as the encoding of human expertise. Not since the Spanish Inquisition has society believed it had the right to extract human expertise from its native form of embodiment. How is it any different to demand the freedom of "inspection" when the same expertise is encoded as a program?
On the other hand, it has always been an MS strategy to drive in the thin edge of the wedge until they accumulate so much market and mind share that resistance is futile.
What this article fails to point out is that the wedge is a moving target. By the time the world organizes in opposition to Word documents, the only streaming format left on the internet (and universally embedded into all consumer devices) will be Windows Media.
As fast as you yank one testicle out of the noose, the other testicle is snagged. 50% of the internet is porn. Several of the people I know who still run Windows would be very upset not to be able to watch Don Cherry from the CBC website. There's a sizable audience out there who really don't how hard you squeeze the Word testicle.
Here's an idea for the next killer application: the Maya of home generated porno stills. In the 10GHz billion transistor era, this will become entirely feasible. What programmer from the open source community is going to brag on their resume that they authored the sticky liquid plug-in? I won't feel deprived if I never get to see the source code for this sordid venture.
As far as the guy who "couldn't" apply for a job because they demanded his resume in Word format, he should be seeing the glass half full: he was spared the agony of applying for a job he was only going to hate anyway.
Economics is the science of modeling non-linear phenomena with linear systems. The entire economic context of this question is debious to begin with, but we're all intimately familiar with those distortions (cf. Dilbert). The purpose of estimating is to fit the activity of developing software into an economic context. If we weren't doing that we just go ahead an implement the software without the tea leaves.
What the estimation business needs to justify their existence is a formula that tells people before the fact that the linear assumptions have broken down. Otherwise it's just the science of dividing by zero.
It's the age old question: would you rather have someone who always insists that hse's right, but are only right most of the time, or someone who rarely insists that hse's right but always is right on those occasions?
There's subtlety here in the invocation of Komolgorov complexity. KC is measured with respect to an assumed universal computer. That can be as simple as a Turing machine with a handful of states. Or you can define the machine as including all the software already written that you have available for use. In other words the shortest string is the string that maximizes software reuse.
Estimation is never going to produce satifying results until we have a better foundation of code built for maximal reuse.
Given that the majority of programmers view the coding structures that promote reuse as cluttter (templates anyone?), it'll be a long time yet before KC has any bearing on this subject matter.
Please apply for your Ark B boarding pass. With the newly installed compression algorithm, the transporters now operate with 100 times greater efficiency. Signal your consent by flapping your gums and we will promptly beam you aboard.
And, no, "Open Source" is not an accurate characterization of this faction, since their focus has been making Free Software compatible with business people's thinking. A more correct name would have been "Free Software for Business" - or something like that.
(Some dumb parser in
>>
I had to stop reading at this point. Appart from the GPL, the "non free" project most militant about its license is OpenBSD. Security requires transparency about your methods, yet obscurity about your deployment. Nobody in the security business goes around advertising the location of their sensitive parts.
OpenBSD was not created for business.
Let's look at OpenSSH. There are compilation options which allow you to defeat, at compile time, features you don't wish to deploy. There options are in a header file. If you change this header file, you have changed the source. Haven't you? If OpenBSD were under the GPL, I guess you'd have to publish those changes. Wouldn't you?
It's quite possible to embed in source code all kinds of information which other people have no need or right to know. OpenBSD does a great job of keeping the rights parts of the source code free to inspection. That hardly makes OpenBSD the "running dog" of corporate perversity as this interview seems to imply.
The guy does not understand Moore's law.
Moore's law is shaped by economic forces. Silicon chips don't "wear out" like metals and plastics. If the industry fails to obsolete the previous generation, what do they have to sell?
At any stage along the way, there are dozens of potential avenues for reaching the next cost/performance milestone. They simply "do what it takes" to get there.
3D could have been pursued long ago, but there was no real need. The advantage of making transistors smaller is that the speed increases while the voltage and heat decreases. If you can make a transistor smaller, you aren't going to pursue any other course.
Moore's law has not "drooped". There has always been something right around the corner to rescue Moore's law, and this article just adds to the evidence that nothing much has changed.
The significant event at the present time is that leakage current has become sizeable relative to peak operating current. Shrinking transistors is no longer a free lunch.
I think 3D will succeed in applications where wire latency is a bigger problem than heat dissipation. The biggest advantage of 3D is that it lets you cram more stuff closer together.
A couple of years ago I was researching acids and that lead to a web page devoted to the tremendous safety hazards involved in handling hydrofluoric acid. A few links later I found a web page that stated that most common cat-5 cable sheathing contains fluorine because they haven't found any good alternatives.
Plenum rated cable either doesn't contain fluorine or the extra shielding is designed to prevent the emission of fluorine compounds in the event of fire.
The list of compounds detected during the combustion of cat-5 sheathing looked like something from a chemicals weapons manual. Can't find the link right now. Maybe the Department of the Interior had this information exterminated.
I've been into computers since before MSDOS. I skipped 3.1/95 and jumped straight into NT which served me well enough as a platform for experimenting with C++. Eventually viruses and DLL-hell really began to bother me. My first experience with a free OS was my OpenBSD firewall system. Then I set up a FreeBSD desktop (no X), and then a Redhat box with X.
By this point I figured I had mastered enough to convert my primary desktop system into a Debian box.
I have a couple of geeky friends, much younger than me, who had been Debian as their primary systems for several years. I figured they could help me over a few hurdles.
First advice: run Debian stable. What about my Matrox G450 dual head? Second advice: for dual-head you need to run Debian testing. Fanfsckingtastic. Nothing like diving in at the deep end. It's easy, he promised me.
To make a long story short, I would have needed a Chinese alphabet to enumerate all the adventures that took place during step #1. Fonts didn't work, dual head didn't work (properly), the window manager didn't work (the first several times),
Then when I converted my NTS box to Debian (this time with Debian stable), we must have been at step 1zz by the time we had software RAID working on my Adaptec 3985 SCSI controller. At two different points in the process we "rectified" patches we downloaded by randomly commenting out blocks of code which were causing errors.
Both sides of the argument are wrong. Linux is easy to install if you get a good impedance match between the exact hardware you have in your box and the exact distribution you choose.
My best install ever was an OpenBSD box. I built if for a friend on a generic Celeron. Once through the install process it worked perfectly. Fifteen minutes from disklable to rock solid. The he "upgraded" the memory with a bad memory stick and fried every partition.
What people constantly overlook is that there is no "defining experience" with something like Linux. The phrase "for the user" ought to banned from our vocabulary. There is no "the user". There are millions of variations on a few common themes.
One machine I built with a DLink 530TX network adaptor. The next machine I built with a 530TX+ network adaptor. Surprise, surprise. The 530TX is a Via Rhine card, the 530TX+ is a Realtec card. After I noticed that detail, I was able to get in working again.
Then I built another machine, this time again with a DLink 530TX+ network card. On that machine every TCP connection experienced spiralling death syndrome: 100KB/s would soon become 5 bytes/s (on a local 100mb segment). Guess what? The two 530TX+ cards were different revisions (A versus C). One revision worked normally, the other didn't.
There is no such thing as universal hardware and no such thing as a universal "user".
A better analogy would be shock absorbers. You need to get the tension and damping correct on both ends of the bike. It depends on the terrain, the weight of the rider, and how much gas you have in the tank. Soft will soak up an uneven road surface, but it will also cause the bike to "lift" aggressively coming out of a hard turn (your stomach lifts at twice the speed, and your lunch twice as fast as that).
A bad bike is one where the wrong settings kill you. A good bike is one where the wrong settings scare you. An average bike is where you really can't tell, most of the time, whether the settings are good or bad. Windows aims for the average experience. Linux is poised on the knife edge between being bad and good. Sometimes it kills you, sometimes it saves your life. I've been on both sides of that experience and I really can't say what it is that Linux "needs".
I think the GPL/LGPL makes the most sense for systems, the least sense for libraries which support programming activities, where the BSD license is just fine.
In a similar context, I decided to create a GPL conformance suite for a protocol implementation under the BSD license.
I'm strongly against monomaniacal unitarianism. My bible is the book "In Praise of Diversity" by Freeman Dyson.
A conformance suite is useless unless everyone contributes back their extensions / additions. A protocol is useless unless it is widely adopted. I license is useless if it makes a political statement without making the world a better place. In situations like this, a little common sense goes a long way.
There is precious little difference between source code and any other kind of machine readable file format. If I encode my sexual preferences in XSLT (deviant, I admit), would that make it source code? (I could even invent a new transformation language: SLXT. Small, large, or extra large.)
Stallman is not particularly good at discerning shades of grey, so I'd have to fear that my SLXT data is source code as far as Stallman is concerned. I might have a bug in there somewhere that Stallman desperately wants to fix. The columns don't line up right or something.
Everything is source code. This isn't about source code, this is about everything. Stallman wants everything. We're past ideals here.
There are things in life which are better shared, and there are things in life which are better kept private. It has nothing to do with whether you call one piece of information source code, or give it an entirely different name.
Drooling? The kind of drooling you do when someone hits you on the head with a basebat and you can't see straight and everything seems smudged together.
I think I just missed the peak. Drove my MGA out of town (no top) and saw three bright ones right between the street lamps. When I finally did find the perfect place to park, I had spotted twenty before I found a comfortable way to slouch. Four or five per minute for the next hour or so. Three times I spotted several at once. One really bright on that went zap, dim, pow. Bright little red dot at the end. One left a trail that hung for about four seconds. All in all, worth having a car that likes 94 octane.
Kent's comments about arbitrary parentheses stuck in the back of my mind all day until suddenly the bubble burst.
r = (a/b)/(c/d);
How does Kent think I _should_ paren that?
r = a/b/(c/d); ???
Even if that's still correct, only a supreme wanker would write it that way.
Now lets get more technical. All variables are floats.
r = a+b+c;
In C/C++ the compiler gets to choose the evaluation order. Results might not be the same in the low precision
r = (a+b)+c;
Think you were clever? Wrong. In C/C++ the compiler is still free to reorder evaluation. Who thinks up these crazy rules?
temp = a+b;
r = temp+c;
Finally the compiler takes your word for it.
In Lisp, if I write (* (/ x 42.0) 42.0) I guess the runtime environment is not allowed to remove the costly division.
Personally I think we need to get with the program and start using symbol sets with about twice as many grouping sets. One set of parens for phrasing, another to mandate a fixed evaluation order.
People often complain that overloading is one of the worst features of C++. I agree. But not the operator overloading. The worst feature of C++ is the syntactic overloading of () to define function argument lists as well as to supply arguments for a function call. Not to mention the use of >> as an operator when the angle brackets are sorely needed to denote template parameters.
The subject of delimiter sets runs far deeper than just making it easy for emacs to hop forward and backward when the human eye is jangled.