The old Logitech Mouseman Cordless (shaped like an inverted, rounded triangle). They stopped making them some years ago (replaced them with those supposedly ergonomic slanted lumps) and I've had no luck finding them on the used equipment market, which suggests that noone is willing to part with them (I sure wouldn't). It fits the hand very nicely and has good 'button feel'.
The cordless business is achieved via radio, not infra-red like many of the cordless devices these days. The only problem I've had is when the batteries get low, which happens about once a year under heavy use, then it starts dropping mouse clicks and forgetting that you're holding down the mouse button in the middle of drags. Otherwise, it's a solid beastie.
Three buttons, no cord, with versions for both PC's and Macs (and LinuxPPC recognizes the Mac version and uses all three buttons).
but it's not a proper Haiku (it has 18 sylables. A Haiku is supposed to have 17 in the arrangement of 5, 7, and 5.) Try this: On slashdot it says: They do not trust in Linux! The shame, oh the shame.
What would make anyone think that geeks have a common set of political interests or agendas? We have seen, over the past century and a half, that other supposedly unified subsets of the electorate (e.g. women) end up having nearly as diverse political opinions as the electorate as a whole: what would make us think that geeks are any different.
Just because I'm a geek, what does this tell you about my opinions on:
abortion
welfare
homosexuality
civil rights
church-state separation
taxation
defense spending
market freedom
monetary policy
foreign policy
immigration
economic theory
judicial activism
gun control
freedom of expression
or any other important political issue by which I might choose a candidate for high office?
Political opinions among the geeks who are my friends and coworkers ranges from radical leftism, to centrist liberalism, to free market libertarianism, to fiscal conservatism, to right wing religious radicalism, all the way to outright apathy. While we may usually agree on what is a good or bad technical issue, it is rare indeed for us to agree about the broader issues that govern our lives and how we cast our votes.
I would as soon vote for a geek-centered candidate as I would vote for a candidate running on a platform emphasizing only their stand on abortion or foreign policy. These may be important issues in an election but they are not the only issues. The same goes for geek/technology issues.
no individual code ownership: this seems to suggest that the design would either be imposed from the top, which implies that coders would be treated as unspecialized labor, or that the entire team would be involved in the design of every piece of the code.
Treating coders as unspecialized labor tends not to work because coders are not like factory workers but more like artisans or craftsmen. When you treat programmers like cattle they tend to resent it and deliver substandard code, at best.
While getting the entire programming team involved with the design of every piece of the code might sound good, it results in design by committee, which doesn't tend to work in practice. The best designs come from inspired individuals or from very small teams of people.
Finally, individual code ownership minimizes the need for communication accross the entire group (the N^2 communication problem noted by Brooks in The Mythical Man Month). By requiring a very high degreen of communication between all coders in the group, this technique is almost certain to fail for any group larger than a half dozen or so.
new team members: the review asserts that "New programmers can also be brought in and up to speed much more quickly." but doesn't specify how. This is a similar problem to N^2 communication problem and was shown by Brooks to be one of the primary factors in killing large projects. The fact that the reviewer brushes this off so lightly, and that the table of contents doesn't show a chapter specifically dealing with it, suggests to me that it is not addressed.
Ignoring N^2 communication issues is inexcusable in any methodology postdating The Mythical Man Month.
debugging in pairs: debugging in pairs is a good idea, and should be used by any programming team that has the personnel to spare, however, it does not address the central problem of debugging. The problem with debugging is that it tends to take up a huge amount of the project time, and XP seems to want to add even more debugging to the mix (through the use of automated debugging tools). Just pairing your coders during debugging sessions won't reduce the total debugging time very much since it can't increase the number of cases covered or the range of debugging skills present by a significant amount.
design to throw one away: The early release schedule seems to imply that the first coded design would be used as the production system. This is not a flaw solely in XP, but is rife in the current programming market. Many systems are built, essentailly, from the initial prototype, with no redesign. Brooks identified this as a problem back in the early seventies, but it doesn't seem to have made much difference to actual practice.
A methodology that doesn't address the need to redesign the production system, however, will suffer from cost overruns and reliability problems (both of which XP is explicitly trying to avoid) due to the need to work around mistakes and compromises made when designing the prototype.
unwarrented assumptions: the review seems full of unreasonable assumptions. Most programming projects don't have the latitude to set prices for each feature, or even to pick and choose which features to implement (at least not after the proposal has been made and the contract accepted). Even if you can set prices for individual features or components of the design, most features will not fall into the easy choice presented in the review. Any feature worth worrying about is likely to have effects across a large part of the design and leaving it out early one will pretty much exclude it later on as well.
If XP is really dependant on some of these assumptions then it seems unlikely that it is a generally applicable methodology.
So, it sounds a good piece, but I don't see anything that sets it apart from standard practice or from design methodologies that have already been elaborated elsewhere. Some of the ideas are good, but others just seem to be naieve or illconceived: some even seem to smack of outright voodoo software engineering.
For some things the speed is usefull, but most of the things done by non-programmers won't be much improved by a faster CPU. I am a programmer, however, and big projects take a long time to compile, even on the fastest CPUs avaialable today (most of which are not from Intel and can't run a Microsoft operating system) but nothing else I do with a computer requires anything more than about 200MHz. Give me a good accelerated graphics card, fast hard drives and enough memory to keep me out of swap, and I'll be perfectly happy with 200MHz.
Of course, when the VIA motherboards for the Athalon come out, I'll be sorely tempted to upgrade to somewhere in the 800MHz range.
As V.Mole said, you can't expect a compiler to convert bubble sorts to quick sorts for you, so you certainly want to use appropriate algorithms, but you should not worry about things like precomputing common expressions or specifying what variables should be placed in registers: the compiler is, invariably, going to do a better job of sorting out these minor optimizations than you will, and it will be more portable. (the kind of optimizations that work well on a PowerPC or Alpha won't be so good on an x86 and vice versa)
As for some of the more esoteric optimizations, like loop unrolling, you may or may not get a compiler that can do good loop unrolling, so it may pay to unroll loops manually. Still, for the first attempt, you should probably write the loops without unrolling them so that you can think about the rest of the program, rather than getting caught up in minutia.
I routinely perform some small optimizations that rely on very large scale knowledge of what the code does and how it will be used. For example, I have an AVL tree library that caches the result of the last search and checks the cache variable before each lookup. That kind of optimization couldn't easily be done by the compiler (since it optimizes accross calls to different functions and it relies on what the code is being used for by the caller) but could have a big impact on code that might perform multiple lookups on the same key in sequence. (of course I would be better served by a splay tree in this circumstance, but that's beside the point here)
The kind of optimizations that it really pays to do are more along the lines of smart coding and good design than they are like traditional code optimization. In general, if you make your code readable and don't use stupid algorithms you can rely on the compiler to fix the small stuff.
I haven't read paper computer magazines ever since I got a web connection. I have no use for dead paper periodicals, especially when the information in them is consistently more than a month older than what I'm reading online.
In fact, when the telemarketers from assorted magazines and newpapers bug me I just tell them that I don't read paper printed materials these days: I get all my periodicals online. I'd like to say that Slashdot is responsible for my change of habit, but it was the Macintosh rumor sites that really broke my addiction.
The orriginal statement was correct. Due to the way that C implements array indexing, you can write either array[index] or index[array] and it will work just fine. Your conversion is confused on several points:
array and index will almost never be of the same size since one is a pointer type and the other is an integer type.
The expression array/sizeof(array)+array%sizeof(index) is undefined because division (and possibly modulo remainder) is not defined for pointer types.
Of course the less maintainable version of array indexing is the pointer arithmetic form: array[index] goes to (array+index) or even (((char*)array)+(index*sizeof(array_type))) While you're at it, you may want to throw in an extra array_type pointer to act as a temporary pointing to the currently indexed element. Then it will look as if the pointer arithmetic is really doing some usefull work!
BTW, this equivalence between pointer arithmetic and array indexing is the reason that you can transpose the array and the index above.
I like my laptops small (think the old HP Omnibooks or the new Sony VIAO subnotebooks) and I don't demand that my laptop do the same kind of stuff my desktop does. As long as the keyboard and pointing device are reasonable, I'm happy.
You can fit a good keyboard into about 10", and t he pointing device doesn't have to take up any space at all if you use that eraserhead thingy everyone seems so fond of these days. (I know some people hate it, but I'm willing to make sacrifices for portability) Leave a little room for the bezel around the LCD and you get a 9"x6" display at some reasonable resolution (800x600 is good for me, in a pinch at least).
With the current trends in I/O ports and removable storage, I'd be willing to forego an internal floppy and CD-ROM, and have only modem, ethernet and USB ports. (maybe throw in IrDA, though I have yet to use it for anything. I'm sure some other folks have found it usefull)
While postscript printers may be expensive when you buy them new, they can be had at very reasonable prices when bought used.
I can find Laserwriter II series printers on the net for between $100 and $250 (Nostromo Enterprises is one source, but there are others) and simlar deal on older Deskjets are fairly easy to find.
The only reason that it is reasonable to buy and use used printers is that most older printers are built very sturdily and don't degrade much with age. Also, the general task of putting computer output on paper hasn't changed very much in the last ten years, with the exception of the ready availability of color output these days.
If you want color, however, and you are on a budget, you are pretty much restricted to inkjet printers, which eat int carts quite rapidly. (but produce very nice output)
I use a couple of old Apple Laserwriter IIs at home. They can be had pretty cheaply these days, most versions have a serial port that will work with PCs, and one version (IIg) even has an ethernet port and allows you to connect using lpr protocol.
Otherwise, you should be able to find some HP laserprinters at reasonable prices, though network support will probably cost you extra. In the linux world PCL is about as well supported as postscript, so you won't be losing too much.
The really good thing about these older laser printers is that they are built like tanks, turn out pages at fairly high rates (8ppm is common) and under normal home or student use they run forever on a single toner cartridge.
As others have noted, at about the time Linux first appeared, there were several other 'free' or low-cost unix clones making the rounds. In the payware field there were Coherent and Minix (where, at least in their early versions, could run on 8086/8088's which were common at the time). In the freeware field there were a couple of BSD variants that were fairly mature.
It has also been noted that sufficiently powerfull computing hardware became commonly available in the early ninties. I might also note that the RAM shortage of the late eighties tailed off just a few years before the emergence of Linux, which played a part in reducing the price and availability of powerfull computers for the masses.
I would add that a fair amount of publicly available technical literature (Douglas Comer's XINU books, Tennanbaum's book, etc.) were just becomming available in the late eighties, which may also account for some of the impetus (I spent several years, in the early ninties, considering how to write my own OS, reading lots of books and talking with hacker friends. I wanted to design something new, from the ground up, but they suggested that I mimic unix. I was unable to see the wisdom of their words: a year later, most of them were playing around with 0.9x versions of Linux)
Finally, I think the various attempts to unify UNIX in the late eighties/early ninties may have had something to do with Linus' success. Linus himself talked about making the earliest versions of the Linux kernel POSIX compliant, so I think it is safe to say that the ferment of unix standardization had some part in the success of Linux.
All of this said, without the open source aspect I seriously doubt that Linux would have succeeded. Consider the fate of Coherent, which was priced quite reasonably ($99 for a v.7 clone running on comodity hardware with very small resource needs) but was unable to sustain itself. The main strength of Linux is its ability to rapidly address new or unusual hardware and to assimilate new features almost as quickly as they are proposed. Without this adaptability Linux would be hardly worth looking at, and this ability stems directly from the open source.
- Jeff Dutky
Re:Probabillity waveforms and dimentions
on
Time Doesn't Exist
·
· Score: 1
I think it is your understanding of the authors points that is fuzy, rather than his ideas themselvs. Let me clarify your clarification:
The author posits that any system of N particles (classical or otherwise) can be represented by a K dimensional space (K=N(N-1)/2), where each dimension represents the distance between a pair of particles in the system. He refers to the set of all such K dimensional spaces as 'Platonia'. Each point in a Platonic space (one of the Platonia) represents a unique arrangement of all the particles in the represented system.
NOTE: The author asserts that the only important property of the particles in the system is their relative distances from one another. This may not be true, for instance: the potential energy of the particle pairs may be important. However, the model still works, only the Platonia would have more dimensions. (e.g. K=N(N-1) rather than K=N(N-1)/2)
In a classical Platonic space (a Platonic space representing a system of classical, or Newtonian, particles) the author says that you can find a way of ordering the points in the space that resembles the ordering of time. He further says that if the system is not classical, but rather quantum mechanical, the time-ordering disappears. (and since the universe we live in is governed by quantum mechanics rather than Newtonian mechanics, the Platonic space reperesenting our universe does not have an intrisnic time ordering)
In the quantum mechanical Platonic space, each point (arrangement of all particles in the system) has a probability associated with it. The high probability points are far more likely to be observed (or experienced, since we are not looking in on the point from outside, but rather exist within one of the points) than the low probability points. His thesis is that many (or maybe all?) of the high probability points in the Platonic space representing the collection of particles that is our observable universe, are structured in such a way as to give the illusion of a past, hence the illusion of time.
He is not talking about collapsing probability wave functions, because he posits that every point in the Platonic space exists independantly of the other points. The reason that we happen to perceive a time-ordered point in the Platonic space is that the likelihood of existing in an appearantly time-ordered point is far greater than of existing in some of the other, non-time-ordered points. No wave functions have collapsed, all of the points (both time-ordered and non-time-ordered) in the Platonic space still exist, but you don't perceive the low probability, non-time-ordered, ones. (in fact, you probably only percieve a single point that just happens to be time-ordered)
He also mentions that it is far more likely for you to exist in a point deep within the interior of the Platonic space than near one of the corners, simply because there are far more interior points than corner points. This is why we don't exist at the beginning or end of the universe, which are represented in the Platonic space by corners, because there are more interior points to choose from than corner points. (note also that in a K dimensional space there are K corners. For our observable universe, therefore, there are a vast number of beginnings or endings possible)
The interesting part, for me at least, is that the quantum probability functions that assign probabilities to the points of the Platonic space may greatly favor points with structure that simulates a past, over the points that don't have such a structure. That would seem to say, contrary to the title of the paper, that time is an inherant property of quantum mechanics, rather than something that we impose upon the random, timeless, universe.
If all they needed to do was avoid a 500MHz clock on the top end configuration, they could simply have tweaked the bus speed and clock multiplier on that machine. They could have offered the top configuration with a 99MHz bus and a 5x multiplier, or a 110MHz bus and 4.5x multiplier, which would have resulted a 495MHz machine in either case. A 111MHz bus and 4.5x multiplier would give a 499.5MHz machine. The faster bus clocks could even have been a supprise marketing coup. The extra time needed for engineering and testing could easily have been excused by reference to the Motorola screw-up. (besides, the 500MHz models weren't scheduled to ship for a while yet)
I'm normally an Apple booster, but it really looks like some folks out in Cupertino panicked this week, and I'd be suprised if they didn't lose some customers over this gaff. It makes me very sad.
First, it would take a long time to slow the earth's rotation any appreciable amount. You probably have more to worry about from the tidal drag of the moon than from this.
Second, the environmental effect of rocket exhaust is minimal, since most rockets used for orbital launch are liquid fueld (Oxy-Hydrogen or Oxy-Hydrozene) and the result of the reaction is almost entirely water vapor.
Finally, you would likely use the linear accelerator in a west to east direction, in order to get a little extra push from the earth's rotation. On the flip side, returning payloads probably want to land in the east to west direction so that the earth's rotation silghtly reduces their touchdown velocity. Some of what you would loose in takeoff you could get back on landing. (similar problems are addressed by A.C. Clarke when he talks about rotating 'sky-hooks', which would stand to loose sizable fractions of their rorational energy to the accelerated and decelerated payloads)
(The 'little extra push' is actually equal to about 1000 mph in either direction at the equator, so it is far from negligible. It would put your actual takeoff velocity at about 10% of LEO velocity)
Has anyone bothered to do the required math for this before posting about how you couldn't launch people with this thing without turning them into raspberry jam? A little bit of calculation shows that a 1km long track, accelerating the payload at 4g for a little over six and a half seconds will get the payload up to the maximum stated velocity at the end of the track (actually about 100 meters short of the end, but what's a hundred meters between friends?) A human can easily withstand a force of 4g for six or seven seconds.
The track could run essentially parallel to the surface of the earth for most of its length, since it doesn't matter too much what direction your velocity is in, so long as your path doesn't intersect the ground or a mountain or somesuch.
As for how much this would help you: you would be getting about 5% of your required velocity for low earth orbit without the need for onboard reaction mass. The amount of reaction mass you consume during takeoff is something like inverse exponentail (or maybe inverse log. In either case, there are a bunch of constant factors thrown in) so that most of the fuel is used early on. A 5% savings in reaction mass during the first part of takeoff may be worth a lot more (like 20%) in the total amount of fuel needed.
What I'd like to know is where this maximum velocity comes from. I assume that it has to do with wind resistance at sea level, or somesuch, but I'd like to know for certain.
Though I suspect that the reason for fetchmail's linear growth has to do with it's approach to fetchmail nirvana, there is another factor at work in the open source community en masse: If the community is growing exponentially, and, at the same time, the number of open source projects is growing exponentially, then we would expect to see only a linear increase in the number of programmers on any given project.
The proof is fairly simple: suppose that the number of ideas for new projects is roughly proportional to the number of people in the community (this seems like a reasonable assumption to me) then the number of project ideas grows proportionally to the growth of the community, possibly with some constant factor involved. To phrase this mathematically:
P=Number of Projects
C=Size of Community N=unspecified exponential factor (N>1) K=unspecified constant factor (K>0) Gc=Growth of the Community Gp=Growth in number of Projects S=Average Project Size Gs=Growth in Average Project Size
P = C/K (only a fraction of the community creates new projects) Gc = C^N Gp = C^N/K S = C/P = KC/C = K Gs = Gc/Gp = KC^N/C^N = K
Therefore we see that growth in project size is linear while groth in community size is exponential.
As I said, I don't think that this is what is at work, directly, in the fetchmail project, but it is a limiting factor on the growth of oss projects in agragate.
We should also consider that the gowth in the oss community may not be exponential, even if the growth in networked households or Linux use is exponential. The technically savy population was networked before the rest of the folks, and was probably using Linux before now as well. I think it is possible that the growth of the oss community may be close to linear (or at least logarithmic).
First I'd like to comment on the remark concerning double linking of.COM files: this is both wastefull (it makes your resultant program twice as large as it otherwise needs to be) and unnecessary (.COM files are already relocatable, since the code fits entirely within a single segment. In order to relocate a.COM just modify the CS register when you load the program).
Second, as for shared ELF libraries: you will notice that the poster specified that he is using a 80186 clone (AMD186ED) which is simply an 8086 with some extra peripheral hardware (timers, parrallel I/O, etc.) on chip and a couple extra instructions. It does not implement any of the 80386 extensions that ELF shared most likely relies on. In 80386 protected mode you can have full 32-bit offsets for NEAR jumps, which gives you true position-independant code without having to resort to load-time kludgery. The 8086 and it's real-mode/16-bit bretheren don't have such niceties. Shared ELF stuff is probably not applicable here.
The real answer to your question (instead of the balsphemous tripe I already posted) is that you can't do relocatable code on an x86 in real mode. If you want to write position independant code, get yourself a real computer, not some piece of Intel inspired trash. I would suggest either a 68K based MCU, or a RISC MCU (MIPS, ARM, or PowerPC) any one of which can be had cheaply from a wide range of sources.
This is, of course, an absurdly flippant and condescending answer, given that you already have the hardware in hand and it would be rediculous to go out and spend more money on extra hardware when you can just code around the brokeness of what you have.
However, if it takes you an extra several weeks to code up the relocating linker-loader, and you are paid the average for a good programmer, you will end up spending more on the relocation software that you would have on a real computer. But your boss (or the bookkeepers, at least) probably won't see it that way.
You are pretty well screwed if you want to do position independant code on iAPx86 processors prior to the 80386, because of the glorious fun we call Segmented Memory.
On the 8088/8086/80186/80286 and compatibles, you have essentially two kinds of jump instructions: short jumps that add a 8-bot or 16-bit offset to the IP register but do not affect the CS register (remember, your full instruction counter is the 20-bit sum IP+16*CS), and far jumps that replace both the IP and the CS with new values, but do not allow relative addressing.
So you see, you can either have position independant code (jumps addressed from the current IP) or you can have more than 64k of code, but not both. The way around this is to use far jumps in your executable files and modify the target addresses when you load the code into memory at runtime.
I rather doubt that there is a BIOS call to relocate the executable file. I've written a multitasking OS for 8086's, and I don't remember there being such a BIOS call. In fact, I had to write a relocating linking loader myself, so I feel pretty comfortable saying there is no such beast in the motherboard BIOS. You are probably confusing the MS-DOS BIOS (loaded from the file BIOS.SYS on the boot disk) with the motherboard BIOS (contained in ROM). The basics of an.EXE relocating linking loader are, however, pretty simple:
In their header,.EXE files have a table of the offsets of all absolute addresses in the program that are in need of relocation. All you do is, once you have loaded the.EXE into it's new home in RAM, go through the table and add the new base address of the program in RAM to each indicated address in the program image in memory.
There is a reasonable explaination of the.EXE file format and the relocation process on pages 83-85 of the Microsoft MS-DOS Programmer's Reference (Microsoft Press, ISBN 1-55615-546-8, US$27.95) and on page 307 of Disecting DOS (Michael Podanoffsky, Addison Wesley, ISBN 0-201-62687-X, US$39.95)
The Podanoffsky book will provide you with real code to perform this bit of sorcery, but I will quote from the M$ book, since it should be considered more authoritative:
The relocation table is an array of relocation pointers, each of which points to a relocatable-segment address in the program image. The exRelocItems field in the file header specifies the number of pointers in the array, and the exRelocTable field specifies the file offset at which the relocation table starts. Each relocation pointer consists of two 16-bit values and a segment number.
To load an.EXE program, MS-DOS first reads the file header to determine the.EXE signature and calculate the size of the program image. It then attempts to allocate memory.... [if there isn't enough memory for the program + any extra memory the.EXE file specifies + the OS's bookkeeping data structures (in MS-DOS called the Program Segment Prefix, or PSP) then MS-DOS returns an error, otherwise it allocates the memory -- JSD]
After allocating memory, MS-DOS determines the segment address, called the start-segment address, at which to load the program image. If the value in both the exMinAlloc and exMaxAlloc fields is zero, MS-DOS loads the image as high as possible in memory. Otherwise, it loads the image immediately above the area reserved for the PSP.
Next, MS-DOS reads the items in the relocation table and adjusts all segment addresses specified by the relocation pointers. For each pointer in the relocation table, MS-DOS findes the corresponding relocatable-segment address in the program image and adds the start-segment address to it. Once adjusted, the segment address points to the segments in memory where the program's code and data are loaded.
The preceeding excerpt refers to a memory structure that contains the contents of the.EXE header file. In C structure notation the header looks like this: (in this case, int is 16-bits)
struct EXEHEADER { int exSignature;/*.EXE signature = 0x5a4d */ int exEstraBytes;/* number of unused bytes in last page of file */ int exPages;/* size of file in 512-byte pages */ int exRelocItems;/* number of pointers in relocation table */ int exHeaderSize;/* header size in paragraphs (16-bytes/paragraph) */ int exMinAlloc;/* minimum extra memory required (paragraphs) */ int exMacAlloc;/* extra memory requested (paragraphs) */ int exInitSS;/* initial stack segment value */ int exInitSP;/* initial stack pointer value */ int exCheckSum;/* checksum, unused, usually zero */ int exInitIP;/* initial instruction pointer value: entry point offset */ int exInitCS;/* initial code segment value: entry point's segment */ int exRelocTable;/* byte offset to relocation table */ int exOverlay;/* overlay number, 0 for resident part */ }
DISCLAIMER: If the OS you are using uses a different executable file format, all of the above is inaccurate, but may be helpfull for purely theoretic purposes, since anything running in x86 real mode needs to be able to solve this bit of kludgery.
"The new G4's... draw something like 5.0w typical/11.5 peak. And consider how power consumption varies with the SQUARE of wattage"
Get your facts straight before posting: Power varies as the square of the voltage, not the wattage. Cast your mind back to freshman physics: V=IR -> I=V/R, P=IIR -> P=(V/R)(V/R)R -> P=VV/R. Watts are a unit of power, and power can't vary as the square of itself. This is why you should drop the core voltage on your overclocked Celeries by 3% when upping the clock by 10%.
And what do you mean "Apple doesn't have real competitioin with powerpc laptops?" With the exception of the blasted one button trackpad, the current crop of Powerbooks is a match for anything on the market, IMHO. You can even run Linux on the damn things, what more could you want?
Bugs are unobvious by definition (all of the obvious bugs will have been squashed early). The real problem with STO is that, in all likelyhood, the bugs will be easier to find in the binary than in the source, because more sophisticated tools and greater effort is required to examine the binary than to examine the source.
A programmer examining the original source for a program is likely to fall into the same traps as the author of the program due to reliance on comments in order to understand the code. When you are searching through a decompile or tracing the execution of a binary for which you don't have the source, you are likely to examine the program far more closely than you would if you had source available. Hence you will be more likely to notice odd program behavior that my be obscured otherwise.
Finally, the idea that examination of the source is required in order to discover or exploit a bug in a piece of software is likely to be sadly mistaken. Normal users trigger bugs in closed source software every day without even trying. A diligent user can often pinpoint both the causes and the results of a given bug with only a few hours of experimentation. It is only a short step from a diligent user to a 'script kiddie' who can figure a way to use the bug as an exploit.
The ability to 'examine' millions of line of code per second makes the compiled binary a far more powerfull tool for discovering the properties and behavior of any given program than all the open sources in the world. (there is a reason that people prefer to use on-line debugging tools than to hand debug with a trace-table)
This shouldn't be too hard, so long as you can set the cards to use different IRQs and I/O ports. It might be easier to have each sound card using a different chipset (and hence different drivers) but, otherwise, it shouldn't be much different from having multiple network interface cards.
The main reason I see to have multiple sound cards (with each sound card driving speakers in a different room) is to be able to play different MP3s in different rooms. This use, however, doesn't require the sound output streams to be synchronized in any way. If you just want to have multiple speakers playing the same stuff, a single sound card with a splitter/amplifier and multiple speakers should do the trick.
While I am very fond of the revitalized Apple in general and of the new Macs in particular, I have to say that the choice of Tangerine as one of the two introductory colors astonishes me. Tangerine is one of the worst selling colors for the multi-color iMacs: why would Apple think that it was a good choice for a model only available in two colors initially?
I would have thought that they would releast the consumer portable in either all five "flavors" at once, or in just the most popular (Blueberry, Grape and Cherry).
I think the machine is pretty compelling, but I'm not about to buy one until I can get it in purple.
Slashdot Mirror
The old Logitech Mouseman Cordless (shaped like an inverted, rounded triangle). They stopped making them some years ago (replaced them with those supposedly ergonomic slanted lumps) and I've had no luck finding them on the used equipment market, which suggests that noone is willing to part with them (I sure wouldn't). It fits the hand very nicely and has good 'button feel'.
The cordless business is achieved via radio, not infra-red like many of the cordless devices these days. The only problem I've had is when the batteries get low, which happens about once a year under heavy use, then it starts dropping mouse clicks and forgetting that you're holding down the mouse button in the middle of drags. Otherwise, it's a solid beastie.
Three buttons, no cord, with versions for both PC's and Macs (and LinuxPPC recognizes the Mac version and uses all three buttons).
but it's not a proper Haiku (it has 18 sylables. A Haiku is supposed to have 17 in the arrangement of 5, 7, and 5.) Try this:
On slashdot it says:
They do not trust in Linux!
The shame, oh the shame.
Just because I'm a geek, what does this tell you about my opinions on:
- abortion
- welfare
- homosexuality
- civil rights
- church-state separation
- taxation
- defense spending
- market freedom
- monetary policy
- foreign policy
- immigration
- economic theory
- judicial activism
- gun control
- freedom of expression
or any other important political issue by which I might choose a candidate for high office?Political opinions among the geeks who are my friends and coworkers ranges from radical leftism, to centrist liberalism, to free market libertarianism, to fiscal conservatism, to right wing religious radicalism, all the way to outright apathy. While we may usually agree on what is a good or bad technical issue, it is rare indeed for us to agree about the broader issues that govern our lives and how we cast our votes.
I would as soon vote for a geek-centered candidate as I would vote for a candidate running on a platform emphasizing only their stand on abortion or foreign policy. These may be important issues in an election but they are not the only issues. The same goes for geek/technology issues.
Treating coders as unspecialized labor tends not to work because coders are not like factory workers but more like artisans or craftsmen. When you treat programmers like cattle they tend to resent it and deliver substandard code, at best.
While getting the entire programming team involved with the design of every piece of the code might sound good, it results in design by committee, which doesn't tend to work in practice. The best designs come from inspired individuals or from very small teams of people.
Finally, individual code ownership minimizes the need for communication accross the entire group (the N^2 communication problem noted by Brooks in The Mythical Man Month). By requiring a very high degreen of communication between all coders in the group, this technique is almost certain to fail for any group larger than a half dozen or so.
Ignoring N^2 communication issues is inexcusable in any methodology postdating The Mythical Man Month.
A methodology that doesn't address the need to redesign the production system, however, will suffer from cost overruns and reliability problems (both of which XP is explicitly trying to avoid) due to the need to work around mistakes and compromises made when designing the prototype.
If XP is really dependant on some of these assumptions then it seems unlikely that it is a generally applicable methodology.
So, it sounds a good piece, but I don't see anything that sets it apart from standard practice or from design methodologies that have already been elaborated elsewhere. Some of the ideas are good, but others just seem to be naieve or illconceived: some even seem to smack of outright voodoo software engineering.
For some things the speed is usefull, but most of the things done by non-programmers won't be much improved by a faster CPU. I am a programmer, however, and big projects take a long time to compile, even on the fastest CPUs avaialable today (most of which are not from Intel and can't run a Microsoft operating system) but nothing else I do with a computer requires anything more than about 200MHz. Give me a good accelerated graphics card, fast hard drives and enough memory to keep me out of swap, and I'll be perfectly happy with 200MHz.
Of course, when the VIA motherboards for the Athalon come out, I'll be sorely tempted to upgrade to somewhere in the 800MHz range.
Ok, how's this:
. ............... B b...III...gGg.. . .B...I...G...G. . .B...I...G..... B b....I...G..GG. . .B...I...G...G. . .B...I...G...G. B B...III...GGG.. . ............... O o...sSs..TTTTT. . .O.S...S...T... . .O.S.......T... . .O..SSs....T... . .O.....S...T... . .O.S...S...T... O O...SSS....T... . ...............
/. text box.
...............................................
.RRRr..EEEEE....A....L.....L.....Y...Y.......BB
.R...R.E.......A.A...L.....L.....Y...Y.......B.
.R...R.E......A...A..L.....L.....Y...Y.......B.
.RRRR..EEE....A...A..L.....L......Y.Y........BB
.R.R...E......AAAAA..L.....L.......Y.........B.
.R..R..E.....A.....A.L.....L.......Y.........B.
.R...R.EEEEE.A.....A.LLLLL.LLLLL...Y.........BB
...............................................
.FFFFF..III...RRRr...sSs...TTTTT.......PPPp...o
.F.......I....R...R.S...S....T.........P...P.O.
.F.......I....R...R.S........T.........P...P.O.
.FFF.....I....RRRR...SSs.....T.........PPPP..O.
.F.......I....R.R.......S....T.........P.....O.
.F.......I....R..R..S...S....T.........P.....O.
.F......III...R...R..SSS.....T.........P......O
...............................................
Of course, it's not so easy if you try to enter something wider than the
As V.Mole said, you can't expect a compiler to convert bubble sorts to quick sorts for you, so you certainly want to use appropriate algorithms, but you should not worry about things like precomputing common expressions or specifying what variables should be placed in registers: the compiler is, invariably, going to do a better job of sorting out these minor optimizations than you will, and it will be more portable. (the kind of optimizations that work well on a PowerPC or Alpha won't be so good on an x86 and vice versa)
As for some of the more esoteric optimizations, like loop unrolling, you may or may not get a compiler that can do good loop unrolling, so it may pay to unroll loops manually. Still, for the first attempt, you should probably write the loops without unrolling them so that you can think about the rest of the program, rather than getting caught up in minutia.
I routinely perform some small optimizations that rely on very large scale knowledge of what the code does and how it will be used. For example, I have an AVL tree library that caches the result of the last search and checks the cache variable before each lookup. That kind of optimization couldn't easily be done by the compiler (since it optimizes accross calls to different functions and it relies on what the code is being used for by the caller) but could have a big impact on code that might perform multiple lookups on the same key in sequence. (of course I would be better served by a splay tree in this circumstance, but that's beside the point here)
The kind of optimizations that it really pays to do are more along the lines of smart coding and good design than they are like traditional code optimization. In general, if you make your code readable and don't use stupid algorithms you can rely on the compiler to fix the small stuff.
I haven't read paper computer magazines ever since I got a web connection. I have no use for dead paper periodicals, especially when the information in them is consistently more than a month older than what I'm reading online.
In fact, when the telemarketers from assorted magazines and newpapers bug me I just tell them that I don't read paper printed materials these days: I get all my periodicals online. I'd like to say that Slashdot is responsible for my change of habit, but it was the Macintosh rumor sites that really broke my addiction.
The orriginal statement was correct. Due to the way that C implements array indexing, you can write either array[index] or index[array] and it will work just fine. Your conversion is confused on several points:
Of course the less maintainable version of array indexing is the pointer arithmetic form:
array[index] goes to
(array+index) or even
(((char*)array)+(index*sizeof(array_type)))
While you're at it, you may want to throw in an extra array_type pointer to act as a temporary pointing to the currently indexed element. Then it will look as if the pointer arithmetic is really doing some usefull work!
BTW, this equivalence between pointer arithmetic and array indexing is the reason that you can transpose the array and the index above.
I like my laptops small (think the old HP Omnibooks or the new Sony VIAO subnotebooks) and I don't demand that my laptop do the same kind of stuff my desktop does. As long as the keyboard and pointing device are reasonable, I'm happy.
You can fit a good keyboard into about 10", and t he pointing device doesn't have to take up any space at all if you use that eraserhead thingy everyone seems so fond of these days. (I know some people hate it, but I'm willing to make sacrifices for portability) Leave a little room for the bezel around the LCD and you get a 9"x6" display at some reasonable resolution (800x600 is good for me, in a pinch at least).
With the current trends in I/O ports and removable storage, I'd be willing to forego an internal floppy and CD-ROM, and have only modem, ethernet and USB ports. (maybe throw in IrDA, though I have yet to use it for anything. I'm sure some other folks have found it usefull)
While postscript printers may be expensive when you buy them new, they can be had at very reasonable prices when bought used.
I can find Laserwriter II series printers on the net for between $100 and $250 (Nostromo Enterprises is one source, but there are others) and simlar deal on older Deskjets are fairly easy to find.
The only reason that it is reasonable to buy and use used printers is that most older printers are built very sturdily and don't degrade much with age. Also, the general task of putting computer output on paper hasn't changed very much in the last ten years, with the exception of the ready availability of color output these days.
If you want color, however, and you are on a budget, you are pretty much restricted to inkjet printers, which eat int carts quite rapidly. (but produce very nice output)
I use a couple of old Apple Laserwriter IIs at home. They can be had pretty cheaply these days, most versions have a serial port that will work with PCs, and one version (IIg) even has an ethernet port and allows you to connect using lpr protocol.
Otherwise, you should be able to find some HP laserprinters at reasonable prices, though network support will probably cost you extra. In the linux world PCL is about as well supported as postscript, so you won't be losing too much.
The really good thing about these older laser printers is that they are built like tanks, turn out pages at fairly high rates (8ppm is common) and under normal home or student use they run forever on a single toner cartridge.
As others have noted, at about the time Linux first appeared, there were several other 'free' or low-cost unix clones making the rounds. In the payware field there were Coherent and Minix (where, at least in their early versions, could run on 8086/8088's which were common at the time). In the freeware field there were a couple of BSD variants that were fairly mature.
It has also been noted that sufficiently powerfull computing hardware became commonly available in the early ninties. I might also note that the RAM shortage of the late eighties tailed off just a few years before the emergence of Linux, which played a part in reducing the price and availability of powerfull computers for the masses.
I would add that a fair amount of publicly available technical literature (Douglas Comer's XINU books, Tennanbaum's book, etc.) were just becomming available in the late eighties, which may also account for some of the impetus (I spent several years, in the early ninties, considering how to write my own OS, reading lots of books and talking with hacker friends. I wanted to design something new, from the ground up, but they suggested that I mimic unix. I was unable to see the wisdom of their words: a year later, most of them were playing around with 0.9x versions of Linux)
Finally, I think the various attempts to unify UNIX in the late eighties/early ninties may have had something to do with Linus' success. Linus himself talked about making the earliest versions of the Linux kernel POSIX compliant, so I think it is safe to say that the ferment of unix standardization had some part in the success of Linux.
All of this said, without the open source aspect I seriously doubt that Linux would have succeeded. Consider the fate of Coherent, which was priced quite reasonably ($99 for a v.7 clone running on comodity hardware with very small resource needs) but was unable to sustain itself. The main strength of Linux is its ability to rapidly address new or unusual hardware and to assimilate new features almost as quickly as they are proposed. Without this adaptability Linux would be hardly worth looking at, and this ability stems directly from the open source.
- Jeff Dutky
The author posits that any system of N particles (classical or otherwise) can be represented by a K dimensional space (K=N(N-1)/2), where each dimension represents the distance between a pair of particles in the system. He refers to the set of all such K dimensional spaces as 'Platonia'. Each point in a Platonic space (one of the Platonia) represents a unique arrangement of all the particles in the represented system.
In a classical Platonic space (a Platonic space representing a system of classical, or Newtonian, particles) the author says that you can find a way of ordering the points in the space that resembles the ordering of time. He further says that if the system is not classical, but rather quantum mechanical, the time-ordering disappears. (and since the universe we live in is governed by quantum mechanics rather than Newtonian mechanics, the Platonic space reperesenting our universe does not have an intrisnic time ordering)
In the quantum mechanical Platonic space, each point (arrangement of all particles in the system) has a probability associated with it. The high probability points are far more likely to be observed (or experienced, since we are not looking in on the point from outside, but rather exist within one of the points) than the low probability points. His thesis is that many (or maybe all?) of the high probability points in the Platonic space representing the collection of particles that is our observable universe, are structured in such a way as to give the illusion of a past, hence the illusion of time.
He is not talking about collapsing probability wave functions, because he posits that every point in the Platonic space exists independantly of the other points. The reason that we happen to perceive a time-ordered point in the Platonic space is that the likelihood of existing in an appearantly time-ordered point is far greater than of existing in some of the other, non-time-ordered points. No wave functions have collapsed, all of the points (both time-ordered and non-time-ordered) in the Platonic space still exist, but you don't perceive the low probability, non-time-ordered, ones. (in fact, you probably only percieve a single point that just happens to be time-ordered)
He also mentions that it is far more likely for you to exist in a point deep within the interior of the Platonic space than near one of the corners, simply because there are far more interior points than corner points. This is why we don't exist at the beginning or end of the universe, which are represented in the Platonic space by corners, because there are more interior points to choose from than corner points. (note also that in a K dimensional space there are K corners. For our observable universe, therefore, there are a vast number of beginnings or endings possible)
The interesting part, for me at least, is that the quantum probability functions that assign probabilities to the points of the Platonic space may greatly favor points with structure that simulates a past, over the points that don't have such a structure. That would seem to say, contrary to the title of the paper, that time is an inherant property of quantum mechanics, rather than something that we impose upon the random, timeless, universe.
- Jeff Dutky
If all they needed to do was avoid a 500MHz clock on the top end configuration, they could simply have tweaked the bus speed and clock multiplier on that machine. They could have offered the top configuration with a 99MHz bus and a 5x multiplier, or a 110MHz bus and 4.5x multiplier, which would have resulted a 495MHz machine in either case. A 111MHz bus and 4.5x multiplier would give a 499.5MHz machine. The faster bus clocks could even have been a supprise marketing coup. The extra time needed for engineering and testing could easily have been excused by reference to the Motorola screw-up. (besides, the 500MHz models weren't scheduled to ship for a while yet)
I'm normally an Apple booster, but it really looks like some folks out in Cupertino panicked this week, and I'd be suprised if they didn't lose some customers over this gaff. It makes me very sad.
- Jeff Dutky
First, it would take a long time to slow the earth's rotation any appreciable amount. You probably have more to worry about from the tidal drag of the moon than from this.
Second, the environmental effect of rocket exhaust is minimal, since most rockets used for orbital launch are liquid fueld (Oxy-Hydrogen or Oxy-Hydrozene) and the result of the reaction is almost entirely water vapor.
Finally, you would likely use the linear accelerator in a west to east direction, in order to get a little extra push from the earth's rotation. On the flip side, returning payloads probably want to land in the east to west direction so that the earth's rotation silghtly reduces their touchdown velocity. Some of what you would loose in takeoff you could get back on landing. (similar problems are addressed by A.C. Clarke when he talks about rotating 'sky-hooks', which would stand to loose sizable fractions of their rorational energy to the accelerated and decelerated payloads)
(The 'little extra push' is actually equal to about 1000 mph in either direction at the equator, so it is far from negligible. It would put your actual takeoff velocity at about 10% of LEO velocity)
- Jeff Dutky
Has anyone bothered to do the required math for this before posting about how you couldn't launch people with this thing without turning them into raspberry jam? A little bit of calculation shows that a 1km long track, accelerating the payload at 4g for a little over six and a half seconds will get the payload up to the maximum stated velocity at the end of the track (actually about 100 meters short of the end, but what's a hundred meters between friends?) A human can easily withstand a force of 4g for six or seven seconds.
The track could run essentially parallel to the surface of the earth for most of its length, since it doesn't matter too much what direction your velocity is in, so long as your path doesn't intersect the ground or a mountain or somesuch.
As for how much this would help you: you would be getting about 5% of your required velocity for low earth orbit without the need for onboard reaction mass. The amount of reaction mass you consume during takeoff is something like inverse exponentail (or maybe inverse log. In either case, there are a bunch of constant factors thrown in) so that most of the fuel is used early on. A 5% savings in reaction mass during the first part of takeoff may be worth a lot more (like 20%) in the total amount of fuel needed.
What I'd like to know is where this maximum velocity comes from. I assume that it has to do with wind resistance at sea level, or somesuch, but I'd like to know for certain.
- Jeff Dutky
The proof is fairly simple: suppose that the number of ideas for new projects is roughly proportional to the number of people in the community (this seems like a reasonable assumption to me) then the number of project ideas grows proportionally to the growth of the community, possibly with some constant factor involved. To phrase this mathematically:
As I said, I don't think that this is what is at work, directly, in the fetchmail project, but it is a limiting factor on the growth of oss projects in agragate.
We should also consider that the gowth in the oss community may not be exponential, even if the growth in networked households or Linux use is exponential. The technically savy population was networked before the rest of the folks, and was probably using Linux before now as well. I think it is possible that the growth of the oss community may be close to linear (or at least logarithmic).
-- Jeff Dutky
First I'd like to comment on the remark concerning double linking of .COM files: this is both wastefull (it makes your resultant program twice as large as it otherwise needs to be) and unnecessary (.COM files are already relocatable, since the code fits entirely within a single segment. In order to relocate a .COM just modify the CS register when you load the program).
Second, as for shared ELF libraries: you will notice that the poster specified that he is using a 80186 clone (AMD186ED) which is simply an 8086 with some extra peripheral hardware (timers, parrallel I/O, etc.) on chip and a couple extra instructions. It does not implement any of the 80386 extensions that ELF shared most likely relies on. In 80386 protected mode you can have full 32-bit offsets for NEAR jumps, which gives you true position-independant code without having to resort to load-time kludgery. The 8086 and it's real-mode/16-bit bretheren don't have such niceties. Shared ELF stuff is probably not applicable here.
-- Jeff Dutky
The real answer to your question (instead of the balsphemous tripe I already posted) is that you can't do relocatable code on an x86 in real mode. If you want to write position independant code, get yourself a real computer, not some piece of Intel inspired trash. I would suggest either a 68K based MCU, or a RISC MCU (MIPS, ARM, or PowerPC) any one of which can be had cheaply from a wide range of sources.
This is, of course, an absurdly flippant and condescending answer, given that you already have the hardware in hand and it would be rediculous to go out and spend more money on extra hardware when you can just code around the brokeness of what you have.
However, if it takes you an extra several weeks to code up the relocating linker-loader, and you are paid the average for a good programmer, you will end up spending more on the relocation software that you would have on a real computer. But your boss (or the bookkeepers, at least) probably won't see it that way.
Cheers!
-- Jeff Dutky
You are pretty well screwed if you want to do position independant code on iAPx86 processors prior to the 80386, because of the glorious fun we call Segmented Memory.
On the 8088/8086/80186/80286 and compatibles, you have essentially two kinds of jump instructions: short jumps that add a 8-bot or 16-bit offset to the IP register but do not affect the CS register (remember, your full instruction counter is the 20-bit sum IP+16*CS), and far jumps that replace both the IP and the CS with new values, but do not allow relative addressing.
So you see, you can either have position independant code (jumps addressed from the current IP) or you can have more than 64k of code, but not both. The way around this is to use far jumps in your executable files and modify the target addresses when you load the code into memory at runtime.
I rather doubt that there is a BIOS call to relocate the executable file. I've written a multitasking OS for 8086's, and I don't remember there being such a BIOS call. In fact, I had to write a relocating linking loader myself, so I feel pretty comfortable saying there is no such beast in the motherboard BIOS. You are probably confusing the MS-DOS BIOS (loaded from the file BIOS.SYS on the boot disk) with the motherboard BIOS (contained in ROM). The basics of an .EXE relocating linking loader are, however, pretty simple:
In their header, .EXE files have a table of the offsets of all absolute addresses in the program that are in need of relocation. All you do is, once you have loaded the .EXE into it's new home in RAM, go through the table and add the new base address of the program in RAM to each indicated address in the program image in memory.
There is a reasonable explaination of the .EXE file format and the relocation process on pages 83-85 of the Microsoft MS-DOS Programmer's Reference (Microsoft Press, ISBN 1-55615-546-8, US$27.95) and on page 307 of Disecting DOS (Michael Podanoffsky, Addison Wesley, ISBN 0-201-62687-X, US$39.95)
The Podanoffsky book will provide you with real code to perform this bit of sorcery, but I will quote from the M$ book, since it should be considered more authoritative:
The preceeding excerpt refers to a memory structure that contains the contents of the .EXE header file. In C structure notation the header looks like this: (in this case, int is 16-bits)
struct EXEHEADER {int exSignature;
int exEstraBytes;
int exPages;
int exRelocItems;
int exHeaderSize;
int exMinAlloc;
int exMacAlloc;
int exInitSS;
int exInitSP;
int exCheckSum;
int exInitIP;
int exInitCS;
int exRelocTable;
int exOverlay;
}
DISCLAIMER: If the OS you are using uses a different executable file format, all of the above is inaccurate, but may be helpfull for purely theoretic purposes, since anything running in x86 real mode needs to be able to solve this bit of kludgery.
-- Jeff Dutky
"The new G4's... draw something like 5.0w typical/11.5 peak. And consider how power consumption varies with the SQUARE of wattage"
Get your facts straight before posting: Power varies as the square of the voltage, not the wattage. Cast your mind back to freshman physics: V=IR -> I=V/R, P=IIR -> P=(V/R)(V/R)R -> P=VV/R. Watts are a unit of power, and power can't vary as the square of itself. This is why you should drop the core voltage on your overclocked Celeries by 3% when upping the clock by 10%.
And what do you mean "Apple doesn't have real competitioin with powerpc laptops?" With the exception of the blasted one button trackpad, the current crop of Powerbooks is a match for anything on the market, IMHO. You can even run Linux on the damn things, what more could you want?
Bugs are unobvious by definition (all of the obvious bugs will have been squashed early). The real problem with STO is that, in all likelyhood, the bugs will be easier to find in the binary than in the source, because more sophisticated tools and greater effort is required to examine the binary than to examine the source.
A programmer examining the original source for a program is likely to fall into the same traps as the author of the program due to reliance on comments in order to understand the code. When you are searching through a decompile or tracing the execution of a binary for which you don't have the source, you are likely to examine the program far more closely than you would if you had source available. Hence you will be more likely to notice odd program behavior that my be obscured otherwise.
Finally, the idea that examination of the source is required in order to discover or exploit a bug in a piece of software is likely to be sadly mistaken. Normal users trigger bugs in closed source software every day without even trying. A diligent user can often pinpoint both the causes and the results of a given bug with only a few hours of experimentation. It is only a short step from a diligent user to a 'script kiddie' who can figure a way to use the bug as an exploit.
The ability to 'examine' millions of line of code per second makes the compiled binary a far more powerfull tool for discovering the properties and behavior of any given program than all the open sources in the world. (there is a reason that people prefer to use on-line debugging tools than to hand debug with a trace-table)
This shouldn't be too hard, so long as you can set the cards to use different IRQs and I/O ports. It might be easier to have each sound card using a different chipset (and hence different drivers) but, otherwise, it shouldn't be much different from having multiple network interface cards.
The main reason I see to have multiple sound cards (with each sound card driving speakers in a different room) is to be able to play different MP3s in different rooms. This use, however, doesn't require the sound output streams to be synchronized in any way. If you just want to have multiple speakers playing the same stuff, a single sound card with a splitter/amplifier and multiple speakers should do the trick.
While I am very fond of the revitalized Apple in general and of the new Macs in particular, I have to say that the choice of Tangerine as one of the two introductory colors astonishes me. Tangerine is one of the worst selling colors for the multi-color iMacs: why would Apple think that it was a good choice for a model only available in two colors initially?
I would have thought that they would releast the consumer portable in either all five "flavors" at once, or in just the most popular (Blueberry, Grape and Cherry).
I think the machine is pretty compelling, but I'm not about to buy one until I can get it in purple.