In the words of one of the other replies I got to that post, "have you tried LSD?":)
In seriousness, I'm sure some electronica sounds good live. Closest thing I recall seeing to electronica was Squarepusher, and he sounded great (although admittedly he plays a bass so that comes through differently).
Well, yes, that was my point. For archiving, FLAC is great. But on a mobile device? Unless you're transporting your archive somewhere via the device, what possible use is taking up all of that space on imperceptible change?
Not everyone is interested in holding a lossless music archive on their system. For many, there's simply no benefit.
I remember one time my friend's band had a guy on mushrooms taking pictures, and he somehow managed to triple-expose a picture on a digital camera. Took us a good long while to figure out how that had worked.
Those people in the blind test must have all had something wrong with their hearing or were as old as my parents, but I know better, those results lie. Take a music track and encode it in MP3, then encode another in OGG. To make the test fair, the OGG file should be slightly smaller in size than the MP3. If you listen to the OGG file, you will hear more of the upper frequencies, where MP3 eliminates them completely. That is the main reason why I think OGG is better and if you have decent hearing, you'll be able to hear that difference.
That's what the parent post was trying to say, I think you should read the post that they were replying to to get the context here. There was nothing wrong with the people's hearing because they found much the same as you.
Vorbis had trouble from the beginning, largely because there wasn't originally a non-floating point decoder for the format (and even the one that now exists is pretty resource-consuming compared to those for other formats). I'm always hoping for more widespread acceptance of Vorbis, but it seems that many companies have decided there just isn't a demand. Even most of iRiver's newer players don't play them.
Well, one can quite easily prove that beyond a certain level differences just aren't perceptible. Blind listening tests and all that.
On the other hand, there is a world of difference between a recording and a live performance. I try to make as many live band performances as possible (I've been to 3 since Friday, one of which I was playing) — with many types of music, there's just no better way to experience it.:)
The problem with flac (in particular on devices) is that it uses lossless compression. While it's a fantastic format for archiving data, if storage space is a factor it's just not efficient use of space. Nobody can hear the difference between a sufficiently-high-bitrate lossy file and a lossless one, although there is obviously data loss there.
Using flac (or some other lossless format) for a storage format on a main computer system (where storage space is typically effectively unlimited) then transcoding to a lossy format to put on a mobile device would be fine. But when space is a concern, lossless isn't the way to go.
I'm not sure what post you're replying to, but somewhere in here I was complaining that I hated C. It's the fact that JS has C-like (by which I mean Java-like, C#-like, C++-like, etc.) syntax. I just feel there's implications of semantics (or lack of semantics) that just don't hold from using a similar syntax.
My personal preferred languages are ML, Python, or C#/Java (yeah, sorry about that last "double trouble" pair, but I got used to them and they're very good for large-scale stuff). I'm not sure I consider C (or in particular C++) suitable for many tasks these days, beyond systems programming (and even then, things like the Singularity project have shown that they're not even required to a huge degree there). They're certainly overused.
I'm not so convinced. I realise that one needs to learn any language to be able to use it, but looking like one while acting like another is just plain misleading.
The major problem with JavaScript is that it's basically a Lisp/Scheme-like language with C-like syntax, making it prone to human misunderstanding. Add the fact that it was developed in what could only be described as "a rush", stopping only briefly to be quickly standardised (probably the only large step forward in the language's history), and you can see what's wrong with it. It was an admirable attempt, and it can be made to work in great, but the fact is that was just thrown together too hastily, and not enough thought was put into it first.
By contrast, the other languages you list are generally a bit better in that department. I'm not a fan of all of them (in particular C and Perl, the former because I believe it's only really useful for systems programming and I don't enjoy that, and the latter because it looks untidy and overly-random to me and I just never found the time to learn it), but they are all better examples of languages in general.
In particular the complaint of your post's parent — about closures — is fairly valid. The language has C-like syntax and no particular "hints" at having such an unusual and (in particular for those used to C-like languages) potentially-confusing feature. It's something that can have detrimental effects if you don't know what you're doing with it, and (more seriously), it's something that you can create accidentally if you have no knowledge of its presence. The semantics don't match very well with the languages it looks like, and the syntax doesn't match very well with the languages it acts like. Although once one is used to it it can be used very well, it's immensely confusing to people because of things like that.
It's already easy to embed things into a single file with Gecko-based browsers (e.g. SeaMonkey, Firefox, etc) - all you'd have to do is grab the data that makes up the various files in the page (images, swfs, etc) and use "data:" URLs.
If you read the FAQ, that's exactly what this does. It's a handy little tool for using that sort of encapsulation, and little else, it seems.
This has nothing that I can tell to do with PDF, either. Completely different target audience, completely different requirements, completely different format. If this format was "enough" to "beat" PDF, it'd already be beaten by Microsoft's MHTML format. But it's not. Because they're not the same.
This basically looks like a small tool to do something which is not entirely complicated, and the article is blowing it out of proportion to look like something it's not.
Not to mention, do you really want scripting support in a portable document format? Isn't the whole point that you're able to view the same document, on screen and printed out, across a wide range of platforms, and they'll all look identical? Dynamic content is throwing a wrench in those works.
I don't see why, if the semantics of the dynamic content are clearly defined. So long as the dynamic content works the same on all those different platforms, that's fine.
As for the "on-screen and printed out" issue, it's fairly clear that the "dynamic" part will not print out. Of course, a static view of the dynamic content should always print out fine, and look the same as the live version.
That's the problem though — computers are a very small proportion of players. If the makers of players of the media were to argue, then fair enough, but the makers of operating systems will have little sway, I expect. It's diabolical though, I agree.
I often feel that someone should do something, but the only satisfactory "someone" I can find is the media consumer, and they've (in the large) proven time and again that they either don't know enough or — extremely worryingly — don't care about this erosion of their rights.
Of course, the other option is to just not offer to play the videos at all. Agreed that it's a pretty horrid thing to have to do, but MS's support or otherwise for the format would be unlikely to change its design.
Being accountable in court and being accountable are completely different though — if a company (like Microsoft) consistently fail to fix problems, the company will up and move to another vendor.
Coming "direct from the maker" is the interesting part. I guess a lot of places don't trust 3rd-party support to be able to fix problems in all of the disparate components that make up a Linux (or whatever) distribution, when they had little hand in making those components. But regardless of the EULA, what both sides are offering is support, and it's just difficult for 3rd-party support to be able to offer the types of support that MS can. Novell and Red Hat can do this, but it takes a lot of manpower.
The rest of your post is good, but I'd just like to point out here that although *science* does not aim to disprove religion, *evolution does*. If you think I'm wrong, please, go read biographies on all of the early promoters of evolution.
Regardless of the original promoters' motives, I like to think that it wouldn't become widely-accepted within science unless it had solid backing.
So, is that a reason in itself to disbelieve evolution? Not necessarily, but I think it's a good reason to look critically at evolution in order to decide whether you/we/Them/whoever think it's a good theory because it's a good theory, or because those early promoters did a good job of promoting it as if it was a good theory, when all it realy was was an excuse to get rid of this whole "God" idea?
I agree — everything in science should be looked at critically, that's the point. The fact that evolution has been looked at critically for so long (and, as a result, has been modified many times as parts of it were found to be deficient) should at least give it a little credence. And the fact that no theory has been brought forward which comes even close to it acts quite well in its favour also.
Of course, if something better should come along down the line, science is basically bound to accept it, by the basis of what it is. I really doubt that it'll be a revolution, though, rather than an evolution (sorry for the pun) of the existing evolutionary theories.
Actually, yes. We schould teach our children to doubt and question absolutely everything.
Agreed — the thing is, though, that arguing against science with religion doesn't work on a rational level. Religion is a belief, the questions that can be asked of it are distinct to those of science — this debate gets messy because people are pitting two disparate systems against one another. Science does not aim to disprove religion, so arguing against religion with science doesn't work (except with extremely anal literal interpretations, where the parts that are decided are fairly mundane). Religion does not aim to prove itself, being based on faith, so arguing against science with it leads to problems from their contrasting bases.
We received reports this morning that a security researcher had found a bug in the IE7 Beta 2 Preview release. This issue reportedly crashes IE and is exploitable to execute arbitrary code on the user's computer. Naturally, we take the security of IE and our users' safety very seriously, so we investigated immediately. We did confirm that the bug crashes IE. However, we did not find that the bug was exploitable by default to elevate privilege and run arbitrary code.
This bug had already been found during our code review and analysis that is a mandatory part of our development process; it was scheduled to be fixed before our next public release. We do not believe this bug is easily exploitable, and as an extra defense, the/GS flag also catches the overrun. This is a compiler flag that tells Windows to watch for some classes of buffer overflows. If Windows sees a problem, it kills the application, in this case IE, instead of running the exploit code. While this is certainly not our primary line of protection, it does offer defense-in-depth to help keep our customers secure.
So it appears that Microsoft's new development practices caught this bug internally before it was caught in the public beta, to find bugs like this. It also seems that the overrun is caught and dealt with (causing a crash as overruns should, but not allowing any degree of "control") by the system they are using for development anyway. Apparently the original article has not proven that the bug could be exploited at all yet anyway, so a response from his end will be required before this can really be seen as anything other than the sort of thing that's to be expected from a beta release.
This is largely true. But Linux/BSD aren't particularly great on the desktop yet (I use them on all but my main system), and I can't afford a Mac, so having bad features I can turn off is unforunately my preference to not doing what I want them to.
I'm fairly sure I could get Linux to do what I want, though, but there's a lack of perseverance on my part. Lack of character, I'm afraid.:(
Vista bogged down to the eyeballs with the latest microsoft drm is likely to be a pretty bad release as they again use their customers to bug test this new "er" feature.
I sincerely hope you're wrong about that, but I fear you're probably right. My hope is the fact that they're calling the feature "optional" will allow me to get away (since I don't intend on using DRMed media), but it might lead to more widespread adoption of such nonsense technology.
You misunderstand, sorry my wording was ambiguous. OpenBSD and OSX have the same roots, XP and Vista have the same roots, was my point. The point that the article was trying to get across is that these two systems with the same roots have different characteristics in terms of security, which is also the case with OSX and OpenBSD. Of course, I'm not saying that OSX is as insecure as XP, however.
Wasn't the biggest problem with the SCO thing the fact that SCO wouldn't provide evidence due to the source code being their trade secret or something? If the source is available to the legal process, or whatever, code theft and the lack of would be obvious.
Always possible I have the wrong end of the stick here, though...
Slashdot Mirror
In the words of one of the other replies I got to that post, "have you tried LSD?" :)
In seriousness, I'm sure some electronica sounds good live. Closest thing I recall seeing to electronica was Squarepusher, and he sounded great (although admittedly he plays a bass so that comes through differently).
Well, yes, that was my point. For archiving, FLAC is great. But on a mobile device? Unless you're transporting your archive somewhere via the device, what possible use is taking up all of that space on imperceptible change?
Not everyone is interested in holding a lossless music archive on their system. For many, there's simply no benefit.
I remember one time my friend's band had a guy on mushrooms taking pictures, and he somehow managed to triple-expose a picture on a digital camera. Took us a good long while to figure out how that had worked.
That's what the parent post was trying to say, I think you should read the post that they were replying to to get the context here. There was nothing wrong with the people's hearing because they found much the same as you.
Vorbis had trouble from the beginning, largely because there wasn't originally a non-floating point decoder for the format (and even the one that now exists is pretty resource-consuming compared to those for other formats). I'm always hoping for more widespread acceptance of Vorbis, but it seems that many companies have decided there just isn't a demand. Even most of iRiver's newer players don't play them.
Well, one can quite easily prove that beyond a certain level differences just aren't perceptible. Blind listening tests and all that.
On the other hand, there is a world of difference between a recording and a live performance. I try to make as many live band performances as possible (I've been to 3 since Friday, one of which I was playing) — with many types of music, there's just no better way to experience it. :)
The problem with flac (in particular on devices) is that it uses lossless compression. While it's a fantastic format for archiving data, if storage space is a factor it's just not efficient use of space. Nobody can hear the difference between a sufficiently-high-bitrate lossy file and a lossless one, although there is obviously data loss there.
Using flac (or some other lossless format) for a storage format on a main computer system (where storage space is typically effectively unlimited) then transcoding to a lossy format to put on a mobile device would be fine. But when space is a concern, lossless isn't the way to go.
I'm not sure what post you're replying to, but somewhere in here I was complaining that I hated C. It's the fact that JS has C-like (by which I mean Java-like, C#-like, C++-like, etc.) syntax. I just feel there's implications of semantics (or lack of semantics) that just don't hold from using a similar syntax.
My personal preferred languages are ML, Python, or C#/Java (yeah, sorry about that last "double trouble" pair, but I got used to them and they're very good for large-scale stuff). I'm not sure I consider C (or in particular C++) suitable for many tasks these days, beyond systems programming (and even then, things like the Singularity project have shown that they're not even required to a huge degree there). They're certainly overused.
I'm not so convinced. I realise that one needs to learn any language to be able to use it, but looking like one while acting like another is just plain misleading.
The major problem with JavaScript is that it's basically a Lisp/Scheme-like language with C-like syntax, making it prone to human misunderstanding. Add the fact that it was developed in what could only be described as "a rush", stopping only briefly to be quickly standardised (probably the only large step forward in the language's history), and you can see what's wrong with it. It was an admirable attempt, and it can be made to work in great, but the fact is that was just thrown together too hastily, and not enough thought was put into it first.
By contrast, the other languages you list are generally a bit better in that department. I'm not a fan of all of them (in particular C and Perl, the former because I believe it's only really useful for systems programming and I don't enjoy that, and the latter because it looks untidy and overly-random to me and I just never found the time to learn it), but they are all better examples of languages in general.
In particular the complaint of your post's parent — about closures — is fairly valid. The language has C-like syntax and no particular "hints" at having such an unusual and (in particular for those used to C-like languages) potentially-confusing feature. It's something that can have detrimental effects if you don't know what you're doing with it, and (more seriously), it's something that you can create accidentally if you have no knowledge of its presence. The semantics don't match very well with the languages it looks like, and the syntax doesn't match very well with the languages it acts like. Although once one is used to it it can be used very well, it's immensely confusing to people because of things like that.
If you read the FAQ, that's exactly what this does. It's a handy little tool for using that sort of encapsulation, and little else, it seems.
This has nothing that I can tell to do with PDF, either. Completely different target audience, completely different requirements, completely different format. If this format was "enough" to "beat" PDF, it'd already be beaten by Microsoft's MHTML format. But it's not. Because they're not the same.
This basically looks like a small tool to do something which is not entirely complicated, and the article is blowing it out of proportion to look like something it's not.
I don't see why, if the semantics of the dynamic content are clearly defined. So long as the dynamic content works the same on all those different platforms, that's fine.
As for the "on-screen and printed out" issue, it's fairly clear that the "dynamic" part will not print out. Of course, a static view of the dynamic content should always print out fine, and look the same as the live version.
That's the problem though — computers are a very small proportion of players. If the makers of players of the media were to argue, then fair enough, but the makers of operating systems will have little sway, I expect. It's diabolical though, I agree.
I often feel that someone should do something, but the only satisfactory "someone" I can find is the media consumer, and they've (in the large) proven time and again that they either don't know enough or — extremely worryingly — don't care about this erosion of their rights.
Of course, the other option is to just not offer to play the videos at all. Agreed that it's a pretty horrid thing to have to do, but MS's support or otherwise for the format would be unlikely to change its design.
Congratulations, you were the first respondant with the answer I was waiting for ;)
And yeah, I'm speaking in the way that things should work, rather than how they do. I expect that MS haven't been terrible in this aspect, however.
Being accountable in court and being accountable are completely different though — if a company (like Microsoft) consistently fail to fix problems, the company will up and move to another vendor.
Coming "direct from the maker" is the interesting part. I guess a lot of places don't trust 3rd-party support to be able to fix problems in all of the disparate components that make up a Linux (or whatever) distribution, when they had little hand in making those components. But regardless of the EULA, what both sides are offering is support, and it's just difficult for 3rd-party support to be able to offer the types of support that MS can. Novell and Red Hat can do this, but it takes a lot of manpower.
Nice quotation, thanks for that. :)
Regardless of the original promoters' motives, I like to think that it wouldn't become widely-accepted within science unless it had solid backing.
I agree — everything in science should be looked at critically, that's the point. The fact that evolution has been looked at critically for so long (and, as a result, has been modified many times as parts of it were found to be deficient) should at least give it a little credence. And the fact that no theory has been brought forward which comes even close to it acts quite well in its favour also.
Of course, if something better should come along down the line, science is basically bound to accept it, by the basis of what it is. I really doubt that it'll be a revolution, though, rather than an evolution (sorry for the pun) of the existing evolutionary theories.
Agreed — the thing is, though, that arguing against science with religion doesn't work on a rational level. Religion is a belief, the questions that can be asked of it are distinct to those of science — this debate gets messy because people are pitting two disparate systems against one another. Science does not aim to disprove religion, so arguing against religion with science doesn't work (except with extremely anal literal interpretations, where the parts that are decided are fairly mundane). Religion does not aim to prove itself, being based on faith, so arguing against science with it leads to problems from their contrasting bases.
Fairly official response (taken from another comment).
So it appears that Microsoft's new development practices caught this bug internally before it was caught in the public beta, to find bugs like this. It also seems that the overrun is caught and dealt with (causing a crash as overruns should, but not allowing any degree of "control") by the system they are using for development anyway. Apparently the original article has not proven that the bug could be exploited at all yet anyway, so a response from his end will be required before this can really be seen as anything other than the sort of thing that's to be expected from a beta release.
This is largely true. But Linux/BSD aren't particularly great on the desktop yet (I use them on all but my main system), and I can't afford a Mac, so having bad features I can turn off is unforunately my preference to not doing what I want them to.
I'm fairly sure I could get Linux to do what I want, though, but there's a lack of perseverance on my part. Lack of character, I'm afraid. :(
I sincerely hope you're wrong about that, but I fear you're probably right. My hope is the fact that they're calling the feature "optional" will allow me to get away (since I don't intend on using DRMed media), but it might lead to more widespread adoption of such nonsense technology.
You misunderstand, sorry my wording was ambiguous. OpenBSD and OSX have the same roots, XP and Vista have the same roots, was my point. The point that the article was trying to get across is that these two systems with the same roots have different characteristics in terms of security, which is also the case with OSX and OpenBSD. Of course, I'm not saying that OSX is as insecure as XP, however.
It's based on BSD, yes. So's OpenBSD. Vista and XP, similarly, are based on the same thing. The basis is not the point here.
Wasn't the biggest problem with the SCO thing the fact that SCO wouldn't provide evidence due to the source code being their trade secret or something? If the source is available to the legal process, or whatever, code theft and the lack of would be obvious.
Always possible I have the wrong end of the stick here, though...