Unfortunately, this is only sort of true. The basic syntax is easily learnable and readable -- certainly easier than mentally parsing most regular expressions.

But, oh god, does CSS have a ton of implicit modes. Are your sizes content box or border box? Is this div we're positioning being displayed as a block, inline, or inline-block element? Is there a float active? Has it been cleared? Did we duplicate the appropriate styles with -webkit- and -ms-? Why is it working in Firefox but not Chrome? ...

Layouts that would be a simple command in Tk (button .foo; pack .foo -expand both -fill 1) end up being head scratchers.

The purists then snootily point out, "Well, your problem is you're trying to build a GUI from a markup language." Fine, then: Give me a freaking proper GUI toolkit already. I'm reminded of Jamie Zawinski's quote (though he was referring to XWindows): Using these toolkits is like trying to make a bookshelf out of mashed potatoes.

I have a few cables which violate this spec (despite the USB spec being quite clear on this point). I'm not sure if it's a manufacturing error (cable assemblies sent to the molding process upside-down) or the manufacturer just being egotistical ("We want our logo to be visible to the user"). Western Digital, I'm looking at you...

I really ought to toss them (along with my collection of USB 1.1 cables and hubs).

I have a FTA system which is half setup, cobbled together from some spare parts plus a new receiver and LNBF.

The terrain near my house has proven to be unfriendly. I live on the west side of Puget Sound, so the satellites are already fairly close to the horizon. We're in a old-growth forest area; most of the trees around my house are around the 100' mark. We're just on the other side of a few hills which block antenna reception from any of the local networks, hence my tinkering with FTA equipment.

Even so, Satellite AR shows that I should just be able to pick up AMC 6 which has the NBC feeds. Alas, despite a few hours of trying, I haven't been able to get a signal.

Actual link to the source appears to be http://www.computerhistory.org/atchm/microsoft-ms-dos-early-source-code, but it's throwing 503s at me right now.

Distributing the source code to a proprietary product has a number of potential legal hurdles. If there are parts of the source which were licensed from another company (as would be the case with MS-DOS and SCP, IBM, Stac, and possibly others), those agreements need to be revisited and you may need to get permission from that company (or its successors) to do so. (I include IBM because, I believe, they took over much of the development for the 4.x series.)

MS-DOS 2.x might be the latest version they (currently) feel confident in being able to release free of these restrictions.

But PARC was so successful! Oh, wait... ;-)

Your point is well taken. I believe it's a problem they already have, though: the Mir slip, shipping Unity before it was really ready, etc. Reorganizing -- even if it's done purely in Shuttleworth's mind and not on paper -- would bring these issues to the forefront.

I've found (as a rule of thumb) that, when asking a grad student "How much time do you think you have left before you can write up your thesis?", if the answer is two or more years out then it really means "I don't know." The student honestly believes this answer, but in reality he/she doesn't know how much he/she doesn't know.

I'm starting to feel about the same with Mir and Canonical here. Shuttleworth is the tenured but aloof professor who casually coaxes his students (employees) toward completing milestones but without too much urgency. Money's not plentiful, but the professor has enough contacts and contracts to keep his lab going and give a stipend to his students. They put out a few papers (releases) each year, and each time the students think this grand project is "almost done"... only to discover that there's still more left to do.

There's tremendous value in this kind of exploratory research. I'm just not sure it makes sense to package it up for end users.

If I were Mark Shuttleworth's technical advisor, I'd suggest examining RedHat's Fedora model. Create a small group called Canonical Labs where stuff like Mir and Unity can flourish, with continuous releases and without the artificial constraint of a set release date. (If this makes the environment too lackadaisical and development isn't progressing fast enough, find some other way to instill discipline and/or motivation; don't make it the threat of moving alpha code to end-users.) When it's stabilized (no longer shuffling menus and window icons around, for example), then integrate it with the main Ubuntu branch. Something a bit more edgy and up-to-date than Debian Stable or RHEL, but not so much that it constantly upends your users.

Obviously you meant "good" here, but it made me pause: is there a correlation between food and good managers? I've been reading more than a handful of materials (e.g. Peopleware ) which have mentioned eating together as a helping to build strong teams (arguably the most important job of a manager). A number of companies have caught on, from the big (like Google) to startups (one of my favorites, The Omni Group here in Seattle even has a full-time kitchen staff who are listed by name on their about us page).

Obviously, it's not a catch-all solution; heck, I suspect it's more correlation (that is, the managers who get their teams to eat together are more likely to care about their teams) than causation. But still gave me a pause.

Their website actually bears this out. The good use of this technology will map out how well teams are communicating (which can sometimes make or break a project). We say that inter-team communication is good, and sometimes have meetings to this effect; but this can show whether the company is practicing what it preaches.

Alas, I share the same concerns as the naysayers. I highly doubt this would be used by any American company in a way other than to penalize individual workers for brief moments of inactivity.

It's trivial with the right equipment and materials. Figuring out that you need to p-dope IGN to make an LED, on the other hand...

Reminds me of the story about the fancy car which, no matter what the shop mechanics tried, wouldn't start. So they call in an old mechanic buddy who had retired a few years ago to come take a look. He studies the engine carefully, making a note of the various fluid levels and temperatures as well as the sounds made by the engine. After going at it for a few minutes, he takes a bit of chalk, marks a spot on the engine, and then hits it with his hammer. With that, the engine roared to life.

He then handed the customer a bill for $100. Aghast, the customer replies, "I'm not paying you $100 for hitting the engine with a hammer!"

The old mechanic replies, "Hitting the engine was free. Knowing where to hit it is $100."

This guy managed to get it into 145 bytes (142 on his website, but he printed "Hi World" instead of "Hello world") with no external dependencies.

The smallest ELF executable I've seen is this 45 byte example. It doesn't print anything and it violates the ELF standard, but Linux (or at least his version) is still willing to execute it.

That said, there isn't much point in optimizing away libc except as an academic exercise. Yes, it's a few megabytes in size, but it's shared across every running userspace program (likely including init). Sluggish and bloated programs, in my experience, are almost always the result of poorly thought out algorithms, data structures, and use cases. (That said, the analysis on how to achieve the 45 byte ELF program is very interesting and educational.)

At many companies, not giving two weeks notice will make you ineligible to be rehired. While you might not care, future employers might. It's a legal gray area, but one of the questions sometimes asked of former employers is, "Is X eligible for rehire?" as a way to skirt the we-can't-give-references issue. A "no" answer raises questions -- the impression it gives ranges from "Well, that company is just a bunch of jerks to their employees" to "He's has a bad attitude and makes it uncomfortable for everyone else" to "He was walking out the door with cash and half of their servers; they just couldn't catch him." If you're up for a position with multiple applicants, this could sink you.

While it might provide fleeting catharsis, not giving notice can't help you. At best it will do nothing; at worst, block you from a job you really want later on. Don't do it.

It's not a hoax -- it's an actual study being performed at 25 hospitals. No results yet; this article quotes September or October of this year for the release of preliminary results.

The lead for this is Sam Parnia, a critical care physician who just happens to be into this kind of near-death stuff.