Can someone post a link to a simple "What's New" doc? I'm not gonna go combing through the code to see if they've fixed my bug.

The mounting hardware for a removeable battery does not need to take significantly more room than a non-removable battery, and certainly nowhere near 10%.

I'm no apple fan boy, never even owned anything they make aside from an old II/E and an ipod, but I say that you really don't know what you are talking about if you can't see how the space required for a removable battery can't be more than 10% the volume of the battery itself. A removable battery includes a casing, a connector, latches, etc. and these are also present on the laptop too to accept the removable battery. I think that the video on their own site does a pretty decent job of showing the difference, but I suppose you have too big a chip on your shoulder about Apple "trying to be cool" to bother trusting that the simple line drawing explaining the design is clearly both feasible and likely.

Personally I'd like to see Apple give the option of trackpad with some real physical buttons (more than one and certainly more than none); but in the end it doesn't matter since I think their gear is a bit too finicky and pricey for my taste.

I've had a yahoo mail account since the mid 90s and pop3 has never been a free feature as far as I can remember. I did at one point pay for their premium services so that I could do a pop3 dump/archive before setting an auto-responder letting people know that I don't actively check the address any longer. Which brings up another problem cause by not providing free account redirection or pop3/imap, it encourages autoresponders which effectively amplify the congestion caused by spam...

Those are all cogent points I hadn't considered :)

This is a chicken egg argument. x86 won't be made irrelevant by other chips until/unless software developers support other target architectures. Software developers won't target something unless they feel that it will have wide enough acceptance as to make it worth their development time/effort/cost. If a chip maker has to sacrifice some percentage of their die/power to graft a translayer that allows people to continue to use legacy software then the trans layer provides a sufficient value for most applications as to negate nearly all the performance/efficiency cost of that layer. But don't take my word for it... Go right ahead and prove me wrong, point at a commercially successful x86 replacement that is making sufficient headway as to be considered a truly viable alternative to x86 chips. Atom is eating ARM's lunch right now in the consumer space and any penetration that atom sees into embedded platforms can just be considered frosting.

Thats one of my favorite references works, but the second you try and use one of those clever bashisms you've gone right off the deep-end of portability. Arrays and substring variable references are good and powerful things to use, but good luck making a script that depends on them run under a regular posix bourne shell... try this on bourne for instance:

x="blah"
y=0
function moo(){
while [[ ${y} -le ${#1} ]]; do
output=${1:$(( y++ )):1}
echo ${output}
done
}

foo=( "`moo ${x}`" )
count=0
if [[ ${#foo[*]} ]];then
echo 'it worked'
fi

What a ridiculous claim, there are no "maintenance issues" with ancient idioms... The very fact that those techniques are ancient shows how incredibly flexible and useful they are. I'd much rather use conventions which are widely accepted and in many cases are required by Posix/SUS/XPG4 than find myself having to hack up my stuff to accommodate broad and pervasive changes such those experienced when moving from python 2.x to python 3.x...

People who are constantly advocating against shell scripts tend to be those who see system administration as something it isn't; namely a low level development job. When in reality a sys admin uses shell scripts to glue together existing products of developers in order to manage administrative tasks. If I were an auto mechanic no one would propose that I learn to master a casting foundry and a milling machine in order to work on cars, those are clearly manufacturing/development tools AND certainly no good mechanic would suggest that using a wrench to fasten a nut to a bolt is "a hodge podge of ancient idioms" which should be replaced with whatever flavour of the week fastening system and power tool happens to be popular at the moment.

Sure there are some arcane aspects to shell scripting, but when I learned Unix in college they taught a thing called "the unix philosophy" which basically said that you should always use the smallest tools for the job, leverage the pipes/redirection, and build to a usable script which doesn't replicate existing functionality of ubiquitous tools. Seems like these days every python/perl wizard around fancies themselves an administrator and yet they waste a large portion of their time rewriting tried and true unixisms; sort, wc, cut, paste, tee, etc...

Also, get off my lawn!

escalator:elevator::preview:submit

I believe that they still have a slide rule as standard issue equipment on NASA space missions. It's hard to argue with the cost associated with adding an additional layer of fault tolerance... If it could, in a pinch, be used to plot a survivable reentry or a similarly life saving task when they sent the first rockets to space it can still serve the same function today. Sort of like the saying, "an elevator can't break, it can only become stairs."

That is a gnu'ism. It isn't "standard unix".

1500 MB/s is because it is constrained by the disks. Point being that I agree that IB is awesome.

How do you figure? Infiniband is the absolute final word in minimizing cost per port/density and provides rdma and ultra low latency on crazy high bandwidth connections. There is a reason that companies like NetApp use infiniband for their clustering solutions ;good luck maintaining cache coherency between two or more nodes over something else. Check out how scalable informatics is using IB links on storage boxes that can do over 5k iops at 1500 MB/s