Ogg is certainly a good alternative. I suggested AAC in case you wanted to have both an open format for all your files and an iPod. As far as quality goes, it depends on the encoder. I do recall though that the test did not use variable bitrate AAC files, whilst ogg vorbis is a variable bit rate format. Such a comparison is not really fair -- variable bitrate AAC should yield comparable results. There's also the fact that only 41% of those surveys chose the uncompressed version as their preferred format, which indicates perhaps a flaw in the testing equipment, lack of a sophisticated group of listeners, or any number of other things.
Assuming you already have an iPod (else you couldn't buy another as you say), what's wrong with AAC audio? It's an open standard, unlike mp3, and is quite a bit more versatile than ogg (not that it makes much different for a simple audio player).
It isn't nearly that simple. Oftentimes, in audio production, you work with audio that's much higher than 16-bit... maybe 24-bit, or often internally in software, 32-bit. Can I hear the difference between 16-bit and 24-bit? No. However, if you're going to be processing it heavily, you can hear the difference after it's finished. This is especially true when doing dynamics processing. The more bits an audio encoder has to work with, the better (within reason).
Even if you turn off Javascript for all sites except those on some whitelist, there's no reason one of those sites can't be hacked and have malicious javascript inserted. There are only two ways to be safe from Javascript vulnerabilities:
1. Turn off Javascript completely for all sites. 2. Use a browser with a rock-solid Javascript implementation.
One is easy, but breaks functionality, as people rely on Javascript for everything nowadays -- Mostly for things that don't need it. As for two, Firefox will never be this browser unless it is fundamentally re-architected, as others have mentioned here. It seems like the only option currently is to pick the safest browser you can find (I run Safari, which has far less vulnerabilities reported than Firefox, although I realize that means little in an absolute sense), sandbox it as best you can, be wary of any site you go to, keep your data backed up, have good password policies (don't use the same password for Slashdot and your back account), and cross your fingers.
This sucks -- We're still paying for the browser feature race that Microsoft and Netscape had years ago. This is not to say that passing code to a client and having it run it to render something is a bad thing. No one is up in arms about Postscript. What we do need is some technology that is limited to certain very specific things, and is not depended on to interact with the browser itself in any major ways (as it currently is in Firefox). Saying "draw this line 10 times" is fine. Saying "open these tabs and turn off your bookmark bar" is not. Once you go past Postscript-level rendering and into client UI or system interaction, you're just asking for it.
I wonder why I cnnot rename a file in GNOME's file selector.
Maybe because this is stupid, useless behaviour? What if you want to undo the last rename? Should the open/save dialogs all have undo capabilities too? What if I want to show the last modified dates? What if I want to duplicate a bunch of files? What if I want to do any of the things you normally do in a file manager in my open/save dialog?
The open/save dialog is for opening and saving. Having one less place to duplicate functionally and one less place to shoot yourself in the foot is a *good* thing. In either case, it certainly isn't a valid gripe: It is a matter of preference at the very best. The Mac OS has never had this, despite being famously easy to use.
As for pasting a URL into a file selector, I have no idea how that makes any sense -- how about just opening your browser and pasting it in there?
This is what irks me about anyone voicing outrage over GPLv3 because no one is forcing anyone to use it
Eh? The whole point of the GPL v3 is that if you modify software under the license (or link to it in certain ways or touch it oddly), you have to use the GPL v3 for your software as well.
OS X widgets seem like great idea, but I find that the need to pop up or drop into the widget level, and then wait for the actual widgets to load up and begin functioning is a pain in the butt. I'd rather have things like calculators or weather or currency converters right on the desktop and immediately available.
Just for the record, this is already possible in OS X. You just need to enable "developer" mode with an app like Tinkertool (or using the 'defaults' command). You can then place as many on the desktop as you like.
For one, I'm not sure unicode should be mandatory. I believe it should be described as a recommended component, but not necessary to call your language R6RS-compliant. Would I use a Scheme without unicode support? No, but for some applications and on some systems it isn't necessary. It is great to standardize on an interface, so all that do implement it (and most will) will do it compatibly, but it shouldn't be mandatory. Other things that should probably be recommended by not required are exceptions and the hygienic macro system (although R5RS was no better on this point). I'm less sure about the macro system being recommended instead of required actually. Section 7 should be strictly optional. It already is in a way, but this should be more explicit. The I/O portion of the library is huge -- It does a lot, and is quite flexible. That's great, but it is a rather onerous implementation requirement, and should be recommended, not required... and maybe even broken up into two pieces. Finally, I'm not sure I agree with keeping mutable pairs (set-car!, set-cdr!), but again this is no different from R5RS. The rest of my things are trivial... 'when' and 'unless' aren't needed. Ultimately, anything that makes R6RS significantly harder to implement should be moved from "required" to "recommended". R6RS-compatible scheme can then clearly say which of the five or so "recommended" groups of functionality they suppose; In reality, probably most will support all five, but for some Schemes it just doesn't make sense to do so.
The number of people using Scheme is small, but it is there. Yes, PHP is more popular; It is also total garbage.
I guess the problem is that I don't understand how "a good language to communicate ideas in" is different than "a good teaching language" or "a language that's good to program in".:-)
First of all, that's not exactly a fair comparison -- You're using an xrange, and scheme does not have a similar thing out of the box (although there are certainly SRFIs that cover this). You're also omitting the function declaration -- You'd need this in Python (or similar), but not for the example. You do need it for the Scheme example though, which makes it look artificially long. Below is much nire fair way to compare a python-like language compared to scheme.
def numprint:
for i = 1 while i = 10:
print i
i = i + 1 numprint
(define (loop i)
(cond ((= i 10)
(display i)
(loop (+ i 1))))) (loop 1)
Not really much of a difference, is there? It is still unbalanced because the Scheme function takes an argument, so it could count from 2, 3, 4, etc. Really, the python-like example should be this to match:
def numprint(n):
for i = n while i = 10:
print i
i = i + 1 numprint
In short, yes, the python version is much smaller... when you use high level constructions not available in R5RS. Big deal.
I wasn't agreeing with you. As for what "Scheme is defined by", it doesn't matter: You program with implementations, not standards. R6RS is also not much different from R5RS at all -- It is mostly library additions. This should make teaching easier, as one can show off hash tables to students without first requiring they import some module or use some specific implementation. Furthermore, Scheme, as it is now, can be a very good "grown-up" language (whatever that means). See Chicken Scheme and its large number of bindings for networking, graphics, sound, et cetera.
but its really not the lanuage that you would want to use for your daily work, for that it simply lacks a lot of convenience features (++a becomes (set! a (+ a 1))
This just shows a lack of fundamental understanding of how one typically writes Scheme programs. If you're incrementing variables to the point where that becomes a concern, you're completely misusing the language.
even trivial tasks like a for-loop you have to either code yourself or rely on non-portable extensions.
Again, this shows you have no experience with the language, or you've been using it horribly wrong. There's no reason you should ever need a for loop in Scheme. If you're going to use Scheme as mostly imperative language, you're better off with Python or similar.
, I've never mastered programming and I keep an eye out for easy to learn language, allowing me to focus on the programming instead of on keeping straining my brain with the grammar side of it.
Just the number of parentheses rules out Scheme for me
You're missing out then on the language with perhaps the easiest grammar in existence.
Slashdot Mirror
FAAC and FAAD exist. There's a bit of a dance to be done, but it works.
*watches Erwos on his unicycle, flipping the bird, whilst backpedalling into a tree*
Ah, the one thing I forgot.... open source AAC codecs:
http://www.audiocoding.com/
Ogg is certainly a good alternative. I suggested AAC in case you wanted to have both an open format for all your files and an iPod. As far as quality goes, it depends on the encoder. I do recall though that the test did not use variable bitrate AAC files, whilst ogg vorbis is a variable bit rate format. Such a comparison is not really fair -- variable bitrate AAC should yield comparable results. There's also the fact that only 41% of those surveys chose the uncompressed version as their preferred format, which indicates perhaps a flaw in the testing equipment, lack of a sophisticated group of listeners, or any number of other things.
Assuming you already have an iPod (else you couldn't buy another as you say), what's wrong with AAC audio? It's an open standard, unlike mp3, and is quite a bit more versatile than ogg (not that it makes much different for a simple audio player).
It isn't nearly that simple. Oftentimes, in audio production, you work with audio that's much higher than 16-bit... maybe 24-bit, or often internally in software, 32-bit. Can I hear the difference between 16-bit and 24-bit? No. However, if you're going to be processing it heavily, you can hear the difference after it's finished. This is especially true when doing dynamics processing. The more bits an audio encoder has to work with, the better (within reason).
The law doesn't work that way -- I can't just hide some child porn in your pocket and then sic the police on you. Wait, actually I can...
Yeah yeah... 20-30 years ago, theft didn't even have an 'i' in it!
http://www.johnnowak.com/
Even if you turn off Javascript for all sites except those on some whitelist, there's no reason one of those sites can't be hacked and have malicious javascript inserted. There are only two ways to be safe from Javascript vulnerabilities:
1. Turn off Javascript completely for all sites.
2. Use a browser with a rock-solid Javascript implementation.
One is easy, but breaks functionality, as people rely on Javascript for everything nowadays -- Mostly for things that don't need it. As for two, Firefox will never be this browser unless it is fundamentally re-architected, as others have mentioned here. It seems like the only option currently is to pick the safest browser you can find (I run Safari, which has far less vulnerabilities reported than Firefox, although I realize that means little in an absolute sense), sandbox it as best you can, be wary of any site you go to, keep your data backed up, have good password policies (don't use the same password for Slashdot and your back account), and cross your fingers.
This sucks -- We're still paying for the browser feature race that Microsoft and Netscape had years ago. This is not to say that passing code to a client and having it run it to render something is a bad thing. No one is up in arms about Postscript. What we do need is some technology that is limited to certain very specific things, and is not depended on to interact with the browser itself in any major ways (as it currently is in Firefox). Saying "draw this line 10 times" is fine. Saying "open these tabs and turn off your bookmark bar" is not. Once you go past Postscript-level rendering and into client UI or system interaction, you're just asking for it.
The G5 iMacs do have an excellent internal layout. Open yours up and check.
You can't do it on the Mac. You never could.
I wonder why I cnnot rename a file in GNOME's file selector.
Maybe because this is stupid, useless behaviour? What if you want to undo the last rename? Should the open/save dialogs all have undo capabilities too? What if I want to show the last modified dates? What if I want to duplicate a bunch of files? What if I want to do any of the things you normally do in a file manager in my open/save dialog?
The open/save dialog is for opening and saving. Having one less place to duplicate functionally and one less place to shoot yourself in the foot is a *good* thing. In either case, it certainly isn't a valid gripe: It is a matter of preference at the very best. The Mac OS has never had this, despite being famously easy to use.
As for pasting a URL into a file selector, I have no idea how that makes any sense -- how about just opening your browser and pasting it in there?
This is what irks me about anyone voicing outrage over GPLv3 because no one is forcing anyone to use it
Eh? The whole point of the GPL v3 is that if you modify software under the license (or link to it in certain ways or touch it oddly), you have to use the GPL v3 for your software as well.
Certainly true in large part. I think much of this comes down to an issue of aesthetics for users.
Scheme, as a pedagogical language, should keep the implementors' convenience in mind.
OS X widgets seem like great idea, but I find that the need to pop up or drop into the widget level, and then wait for the actual widgets to load up and begin functioning is a pain in the butt. I'd rather have things like calculators or weather or currency converters right on the desktop and immediately available.
Just for the record, this is already possible in OS X. You just need to enable "developer" mode with an app like Tinkertool (or using the 'defaults' command). You can then place as many on the desktop as you like.
For one, I'm not sure unicode should be mandatory. I believe it should be described as a recommended component, but not necessary to call your language R6RS-compliant. Would I use a Scheme without unicode support? No, but for some applications and on some systems it isn't necessary. It is great to standardize on an interface, so all that do implement it (and most will) will do it compatibly, but it shouldn't be mandatory. Other things that should probably be recommended by not required are exceptions and the hygienic macro system (although R5RS was no better on this point). I'm less sure about the macro system being recommended instead of required actually. Section 7 should be strictly optional. It already is in a way, but this should be more explicit. The I/O portion of the library is huge -- It does a lot, and is quite flexible. That's great, but it is a rather onerous implementation requirement, and should be recommended, not required... and maybe even broken up into two pieces. Finally, I'm not sure I agree with keeping mutable pairs (set-car!, set-cdr!), but again this is no different from R5RS. The rest of my things are trivial... 'when' and 'unless' aren't needed. Ultimately, anything that makes R6RS significantly harder to implement should be moved from "required" to "recommended". R6RS-compatible scheme can then clearly say which of the five or so "recommended" groups of functionality they suppose; In reality, probably most will support all five, but for some Schemes it just doesn't make sense to do so.
The number of people using Scheme is small, but it is there. Yes, PHP is more popular; It is also total garbage.
:-)
I guess the problem is that I don't understand how "a good language to communicate ideas in" is different than "a good teaching language" or "a language that's good to program in".
Ah well... can I buy you coffee?
What? That's a long-running joke? I think you need a new social circle.
Sorry... those = things should be =. My key is rather stuck today.
First of all, that's not exactly a fair comparison -- You're using an xrange, and scheme does not have a similar thing out of the box (although there are certainly SRFIs that cover this). You're also omitting the function declaration -- You'd need this in Python (or similar), but not for the example. You do need it for the Scheme example though, which makes it look artificially long. Below is much nire fair way to compare a python-like language compared to scheme.
def numprint:
for i = 1 while i = 10:
print i
i = i + 1
numprint
(define (loop i)
(cond ((= i 10)
(display i)
(loop (+ i 1)))))
(loop 1)
Not really much of a difference, is there? It is still unbalanced because the Scheme function takes an argument, so it could count from 2, 3, 4, etc. Really, the python-like example should be this to match:
def numprint(n):
for i = n while i = 10:
print i
i = i + 1
numprint
In short, yes, the python version is much smaller... when you use high level constructions not available in R5RS. Big deal.
I wasn't agreeing with you. As for what "Scheme is defined by", it doesn't matter: You program with implementations, not standards. R6RS is also not much different from R5RS at all -- It is mostly library additions. This should make teaching easier, as one can show off hash tables to students without first requiring they import some module or use some specific implementation. Furthermore, Scheme, as it is now, can be a very good "grown-up" language (whatever that means). See Chicken Scheme and its large number of bindings for networking, graphics, sound, et cetera.
but its really not the lanuage that you would want to use for your daily work, for that it simply lacks a lot of convenience features (++a becomes (set! a (+ a 1))
This just shows a lack of fundamental understanding of how one typically writes Scheme programs. If you're incrementing variables to the point where that becomes a concern, you're completely misusing the language.
even trivial tasks like a for-loop you have to either code yourself or rely on non-portable extensions.
Again, this shows you have no experience with the language, or you've been using it horribly wrong. There's no reason you should ever need a for loop in Scheme. If you're going to use Scheme as mostly imperative language, you're better off with Python or similar.
, I've never mastered programming and I keep an eye out for easy to learn language, allowing me to focus on the programming instead of on keeping straining my brain with the grammar side of it.
Just the number of parentheses rules out Scheme for me
You're missing out then on the language with perhaps the easiest grammar in existence.