Only if it is approved in the Windows Store apparently. I wonder if browsers will be allowed by the Store submission terms.

In Steve's post, he is more concerned about the poor performance of Flash on mobile devices than how "free" it is vs. H.264. Granted he brings up both points, but it's the first one that's the real focus.

This is true only if not everyone is required to have insurance. If everyone must have insurance, than the healthy will pay for the unhealthy and the average rate charged will be lower (since more people will be paying).

There's also WiMAX providers such as Clear.

...there's a difference.

The median income of a software enginner is $85,430 as of May 2008. Programmers make less, with $69,620 as the median as of May 2008.

Software engineers have design and architectural skills that programmers may lack. This is why they are paid more.

Source: http://www.bls.gov/oco/ocos303.htm

Based on all the comments that I've read so far, it sounds like the Slashdot community thinks this shifting in prefix meaning is a good idea.

In the long term I also agree that shifting away from writing binary-prefixes as if they were decimal-prefixes is a good idea. In the short term though, there are a lot of programs (especially downloaders) that still use the prefixes in the old informal way, which may confuse users initially.

I call bullshit on this.

I've been running Macs for 19 years now and have never caught a virus. After running various AV software for about 10 years I decided that it was a waste of CPU cycles and uninstalled them all. I cannot see Apple providing first-party support for a class of products that currently makes little sense for Macs at the moment.

Agreed. If you intend to archive the actual digital objects (and not transcribe them to some other medium like paper), you need to include the hardware/software to decode them. A netbook is a cheap way to do this.

For some additional reading on the digital dark age problem:
* http://www.smh.com.au/news/technology/the-digital-dark-age/2005/09/22/1126982184206.html
* http://www.jisc.ac.uk/uploaded_documents/FileFormatsreport.pdf

The aim when getting a job is to pick one that you'll like doing the rest of your life, not to pick one were just "all ships are rising" at a particular time.

I would prefer to work where I'm happy, which may not necessarily be where I can make the easy buck.

I would bet that even though you (and I) don't have much expectation of privacy on the internet, that an awful lot of other internet users do, in fact, have such an expectation. My parents (and most of the other people whose computers I've fixed over the years) certainly do.

True.

Implementing video capabilities in-application is a tradeoff in general:
* (+) app developer has full control over fixing security vulnerabilities, since no external libraries are involved
* (-) each application's multimedia implementation has its own set of bugs and vulnerabilities that need to be fixed
** (-) more work for the application developer to fix --- and some developers do not have the time, motivation, or knowledge to fix such security bugs
** (-) less universal gain through fixes (as only the individual app can benefit from the fixes)
** (+) since these are app-specific bugs, they cannot be exploited across the board on the level that bugs in highly-used system-level multimedia frameworks can

Whereas with system-level frameworks:
* (+) applications get multimedia functionality basically for free
* (+) any fixes or improvements to the system-level library can reflected in all client applications
* (-) any flaws in the system-level library are a lot more attractive for exploitation, since they are used by many programs
* (-) your program usually cannot do anything about exploited flaws in the system-level library

MPEG-1 video.

To my knowledge, Linux does not consistently ship with any multimedia framework common to all (or even most) distributions. Due to the fragmentation of the Linux platform, this is unlikely to change any time soon.

MPEG (.mpg, .mpeg) has been around for eons, so it certainly should be supported everywhere by now. Not the best compression when compared with the latest codecs, but definitely has wide support.

h264 is also a good candidate. Excellent compression. Definitely supported in QuickTime on the Mac and probably in DirectShow in Windows (I haven't tested this). Should be decodable on Linux via ffmpeg. Has hardware decoding support in some chipsets as well.