Many things were listed before, but the biggest ones were not:

1. You can't install Debian Sid, since there is no installer for it. You need to install normall Debian, and then add the sid repos and dist-upgrade. Can be painful and very error-prone (see #2).

2. As much as people like to say that Aptosid (formerly Sidux) is pure Sid, it is not. The Aptosid maintainers/Debian developers try to hold off known to be broken version of packages.

I can't recall the year/etc, but your fancy chart is missing literally the whole Win NT 3.x branch. I can remember seeing the Win NT 3.1 box (I had also impression at the time that there was also NT 3.0). And the NT 3.50. And the best of them all - the NT 3.51.

Strangely enough I can't recall any mention of the 3.46.

I do not hate the blink tag. I hate the web developers.

Otherwise, I think the blink tag spurred the whole generation of web developers. Just look at all the so-called "Web 2.0" crap. Whether it is <blink> or jQuery's animations for every however tiny P.O.S., the end result is the same: unusable mess.

You should check both MKVMerge and MEncoder.

MEncoder definitely capable of extracting part of the movie(*) and combining several ones together. (*)Though IIRC at least in the past MEncoder insisted on frame numbers and wasn't accepting simple times. (I had very little luck with the MEncoder since it often screwed up the A/V sync. But apparently it works for many, since literally all video reencoders for iPhone/PSP/PS3/etc are based on it.)

MKVMerge can't reencode and as such is more limited. But often is sufficient and produces very good results. It definitely can extract part of input. Joining several movies together I have never tried, but googling says it is also possible. (Nice thing about MKVMerge is that it has GUI and CLI. GUI, after clicking all desired options and whatnot, provides you with the command line to be used to start the actual CLI mkvmerge. You can take the command and tweak it to your heart content. I have used that to remux batch of movies with different sound and subtitles, by simply replacing input/output file names in the command line.)

Overall, what you ask is literally impractical: extracting creates a copy of a movie (large input = large output), combining/appending is potentially reencoding (output must be encoded homogeneously, while input is not guaranteed to be homogeneous) and thus very slow. You might wait an hour for the command to finish, only to find that you have cut too much or too little. That is why the video editors are GUI: you select the inputs, you tell it what to you want from it and then you can preview the end result, without waiting hours for the actual rendering.

P.S. Long in the past I have also used the Transcode. Worked pretty well, though is limited to AVI and MPEG2. But it does seem to be abandoned now.

Pretty lame of Google to joke like that.

Because one never knows what motivates the "masterminds" up in the HQ - and they might really close the YouTube if they feel like it. Especially after they would 100% integrate it with the G+ and drive users off.

The word "java" is all over the place in the name of the methods (e.g. java.lang.Number). Thus the "Java all over the place" doesn't play any role.

I haven't followed the suit very closely, but in previous legal cases, Sun/Oracle not once tried to blur the line between "Java as implementation" (aka JVM and Java runtime library) and "Java as API or language."

Do not buy into it: there are two different things commonly referred to as Java: Java as language and APIs and Java as implementation of the language and APIs.

Implementation is copyrightable - language and APIs are not.

You of course meant the /dev/zero.

/dev/null is only good for writing into.

8MB L3 cache for 16 cores?!

Are they kidding??

IMO: DOA.

Could be. All I remember clear that Google - at least among techies - gained traction because they were using by default AND and not OR to join the search terms. Some search engines weren't even allowing ANDing. If you knew several fitting keywords, then the Google results were spot on, without all the rubbish other engines tended to add.

(*) Anybody remember the Google Directory?

Initially, Google search wasn't indexing as much of the Web as Yahoo or AllNet(?) or even aging Altavista.

Google has caught up in about a year, but initially, their only advantage was that the Google was very fast, had strict word matching, was very light-weight (aka modem-friendly) and had less limits on the number of results.

The "page rank" appeared much later, when they have vastly out-indexed the rest of the search engines.

That what my initial skepticism of Google services was based on. Yahoo includes (often annoying) ads in its services - but not Google. I can trust more Yahoo services because they at least try to profit of it. Not so with the Google services: they are "free" and nice, but in the end, unfortunately short-lived.

IMO, the time is ripe to start creating of P2P, decentralized, server-less web - staring with the (mostly) static content like Wikipedia and YouTube and numerous other predominantly publish-only website. In the beginning, a way to push updates, a newer version of content, would suffice for the dynamism.

Models and implementation for decentralized directories (with search function) are available (Kademlia, BitTorrent's DHT). Ditto distributed naming services. But there nothing I'm aware of about how to, in decentralized, in highly redundant fashion, partition and store data on user computers.

YouTube is probably very remote target, but decentralized, server-less Wikipedia I think could be accomplished.

Serial number user needs anyway - for support and such. (Or you provide no support?)

Allow users to run it in "demo" mode, until the serial is entered. Demo means:
- Couple of weeks of interrupted work with the program. (Best of all of you would actually count the time the program is actually used.)
- After the time has passed, once per day (or once per N uses per day) a polite reminder that the user should buy it, since well, develop has to feed his family. Politeness is important!
- If you are really really against the freeloaders, as time goes increase number of reminders.

Do encrypted/compressed binaries, if you can do it on the cheap/for free. Not really a deterrent to a pro, but just to prevent trivial tinkering. I have had cracked (and debugged) some programs (in the MSDOS/Win95 past) with a plain hex editor. :)

Overall, treat potential customers with respect and politeness. Do not annoy or eliminate - but remind to pay money.