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.
You do realize that if insurance companies do not discriminate against pre-existing conditions, they cannot possibly stay in business.
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).
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'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.
16 years isn't such a long time, but just to be sure, put a netbook inside the capsule. Make sure it can run on external power alone, and remove the battery.
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.
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.
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
That's a container format, not a codec. Which codec are we talking, specifically?
MPEG-1 video.
> Should be decodable on Linux via ffmpeg
Which isn't included by default with Linux distributions, last I checked. Which means you can't actually rely on it being there, have to ship ffmpeg yourself, and then might as well use it on all your platforms...
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.
I completely agree. These preexisting native libraries already have support for a ton of codecs. Reimplementing common codecs is a waste of programmer effort leads to unnecessary program bloat.
If I were a developer for one of these browsers that was implementing support for the HTML 5 video element, I would treat the specification as merely a requirement for what the native multimedia libraries should support.
Of course if the native multimedia library doesn't support what the HTML spec says then (but only then) should the browser try to do its own implementation.
If you want standardization, you don't bitch about it - you make your platform of choice far superior to the other options.
An an individual (of the normal or the corporate variety) it is difficult to muster the effort needed to make a superior platform when you have to do it without compensation (i.e. for free).
This is especially the case for near OS-level services such as GUI toolkits and global sound APIs, which require an incredible amount of effort to develop and maintain.
Keep in mind that in this case we are extrapolating features from an MS job posting, not from an official press release. Therefore this isn't exactly hype we're looking at here - but rather internal plans which may change as time progresses.
From what I've read, the reason that Apple didn't allow Flash on the iPhone was because Adobe couldn't produce a version of it that didn't consume a lot of power. Apple very much values the battery life of the iPhone, and putting an inefficient Flash port on the iPhone would threaten this.
I agree that the online documentation and examples for GWT are rather lacking, but there are some good books on GWT. My favorite is "Google Web Toolkit Applications" by Ryan Dewsbury. (Ryan is the same person who made the games mentioned in the original posting.)
GWT was originally marketed to web developers as a way to make developing web applications easier, since the underlying language is Java, which has better tool support (especially for debugging) when compared to plain old JavaScript.
A number of web developers interpreted this marketing spin to mean "convenient to program in but slow". This is not, however, the case. The GWT team has consistently favored the user experience (which includes performance as a large component) over developer convenience when the two goals were at odds. In general, the JavaScript generated by the GWT compiler is as efficient (and sometimes faster) than the code I write by hand.
So, in summary, I suspect GWT hasn't seen wider adoption by web developers because they think that it does not generate performant code.
Slashdot Mirror
Will you even be able to swap out the browser in the metro shell?
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.
You do realize that if insurance companies do not discriminate against pre-existing conditions, they cannot possibly stay in business.
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.
16 years isn't such a long time, but just to be sure, put a netbook inside the capsule. Make sure it can run on external power alone, and remove the battery.
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 (.mpg, .mpeg) has been around for eons
That's a container format, not a codec. Which codec are we talking, specifically?
MPEG-1 video.
> Should be decodable on Linux via ffmpeg
Which isn't included by default with Linux distributions, last I checked. Which means you can't actually rely on it being there, have to ship ffmpeg yourself, and then might as well use it on all your platforms...
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.
I completely agree. These preexisting native libraries already have support for a ton of codecs. Reimplementing common codecs is a waste of programmer effort leads to unnecessary program bloat.
If I were a developer for one of these browsers that was implementing support for the HTML 5 video element, I would treat the specification as merely a requirement for what the native multimedia libraries should support.
Of course if the native multimedia library doesn't support what the HTML spec says then (but only then) should the browser try to do its own implementation.
If you want standardization, you don't bitch about it - you make your platform of choice far superior to the other options.
An an individual (of the normal or the corporate variety) it is difficult to muster the effort needed to make a superior platform when you have to do it without compensation (i.e. for free).
This is especially the case for near OS-level services such as GUI toolkits and global sound APIs, which require an incredible amount of effort to develop and maintain.
What about Windows 1.0, 2.0, 2.1, 3.0, 3.1 and 3.11?
Didn't even think of those. They were before my time I'm afraid. :-)
Keep in mind that in this case we are extrapolating features from an MS job posting, not from an official press release. Therefore this isn't exactly hype we're looking at here - but rather internal plans which may change as time progresses.
Maybe we're seeing a new trend in the way Microsoft will be naming their OSes in the near future.
First it was by year:
* Windows 95
* Windows 98
* Windows 2000
Then it was by special name:
* Windows ME
* Windows NT
* Windows XP
* Windows Vista
Now maybe we'll be seeing names based on internal version numbers:
* Windows 7
* Windows 8
* Windows 9 (maybe?)
Oddly, this reminds me of the game Uplink - in which the player is hired to do various attacks on computer systems for a fee.
http://www.introversion.co.uk/uplink/
From what I've read, the reason that Apple didn't allow Flash on the iPhone was because Adobe couldn't produce a version of it that didn't consume a lot of power. Apple very much values the battery life of the iPhone, and putting an inefficient Flash port on the iPhone would threaten this.
Look here for a proper discussion:
> http://www.appleinsider.com/articles/09/01/31/adobe_apple_working_together_on_flash_for_iphone.html
GWT and Eclipse actually work very well together.
I agree that the online documentation and examples for GWT are rather lacking, but there are some good books on GWT. My favorite is "Google Web Toolkit Applications" by Ryan Dewsbury. (Ryan is the same person who made the games mentioned in the original posting.)
http://www.amazon.com/Google-Toolkit-Applications-Ryan-Dewsbury/dp/0321501969/ref=wl_it_dp?ie=UTF8&coliid=IBGT0TU3E4AB2&colid=1C5O2JP17MKXW
GWT was originally marketed to web developers as a way to make developing web applications easier, since the underlying language is Java, which has better tool support (especially for debugging) when compared to plain old JavaScript.
A number of web developers interpreted this marketing spin to mean "convenient to program in but slow". This is not, however, the case. The GWT team has consistently favored the user experience (which includes performance as a large component) over developer convenience when the two goals were at odds. In general, the JavaScript generated by the GWT compiler is as efficient (and sometimes faster) than the code I write by hand.
So, in summary, I suspect GWT hasn't seen wider adoption by web developers because they think that it does not generate performant code.