Actually, there are things you can do with Java/C# that you can't do with C period.
Really?
C (and even assembly) can't realize that the same inputs to a routine always cause the same output
I think the volatile keyword means an external agent can modify the contents of a variable, and if you don't specify volatile, no such agent can. So for all the non-volatile stuff, the compiler can perform the same static analysis that a Java/C# compiler does to decide whether a function has your specified behavior or not.
And if you're not happy with it, in GCC you can annotate your functions. Wrap the annotation in a portable macro (that does, say, nothing on non-gcc compilers) and Bob's your uncle.
when Java 7, 8 or 9 comes out, ALL java code will run faster
And what's to stop people from writing a linker which does some "post-production" optimizations on the object code? If the compiled C code stores as much symbolic information as the Java code, I'd guess you could do a lot of stuff that's typically done in the compiler to the object code (dead write elimination if they're not done yet).
Also, note that traversing data structures representing byte code isn't free. If later JVMs do more work to optimize code before running it, I predict they will take longer to start up.
From a theoretical standpoint, your C compiler could be cat(1) if you have a sufficiently sophisticated runtime. Then you can do all sorts of crazy stuff at runtime.
I think the best kind of argument which is similar to yours is "let's look at practical achievements".
Are people shipping fancy linkers that speed up C code? No, they're not. Are JVMs employing fancy optimization techniques at run-time? Yes, they are. Is C substantially faster than Java at run-time? Yes, it is.
The real issue is, when Java 7, 8 or 9 comes out, ALL java code ever produced will run faster [...].
It'll still be slower than all the C code out there.
Here's a car analogy: once $BRAND1 finds a more efficient combustion process, all their cars go from 50 to 60 miles per fuel cell that same day. Let's compare to $BRAND2, whose cars run 100 miles per fuel cell today. Which do you want? 60 or 100? Remember: the biggest number is the best here.
Based on my theoretical understanding of how computers work, I though HTTP daemon performance depended mostly on
I/O performance, much of which is controlled by the kernel (in particular the file system).
A good caching strategy (to minimize I/O), again done by the kernel.
Good networking performance, controlled by the networking stack in the kernel.
Database performance, controlled by the RMS-DB, BDSM(R) or whatever it is.
Process spawing speed (for CGI), again controlled by the kernel.
Would someone care to correct me?
Note that TFA (well, the slideshow) measures performance in requests per second. That's a very useful measure, but it's compared to Ruby (Mongrel?) and PHP (Apache?). I'm not sure what that comparison means. Does Apache not support lisp, or only as CGI?
Is there something stopping Apache from being sped up? Is he measuring the performance of LISP, or the performance of a HTTP daemon?
No. It's celebrating Douglas Adams and his writings.
The towel is an item used to celebrate DA, in much the same way that you don't celebrate a flag but use a flag in celebration of your (sadly fallen) compatriots.
It's all about the symbolic value. Just as a flag is a symbol for national pride (which is a Great Thing when not done in excess), the towel is a symbol for (and manifestation of) Douglas Adams' witty humor.
Also, on slashdot, what percentage is American? What percentage has read Douglas Adams?
Just come up with an RSA keypair and store it on all your machines. Encrypt and sign all data you want to store "in the cloud", and find someone who will store it for you.
* Slashdot might object to this and delete your post. I recommend using Reed-Solomon coding (or some other error-correcting code) and storing your data redundantly on several sites.
You could also do mirrored RAIF (Redudant Array of Indepedent Forums), though it might be rife for puns. And RAIP, where P=Posts, would be ripe for them. (Someone's gonna RAIP my karma for that, but the puns and anagrams form such a FAIR PAIR...)
a) Defrag the disk. b) Stop the users typing so fast.
ZOMFG! Please find some code and put it on The Daily WTF.
Unless the coders are doing it horribly wrong, the observable effect of defragging the disk should only be to speed up disk access. Okay, so things can't be too slow.
Stopping the users from typing too fast---unless you're doing it horribly wrong, this can only be a performance issue.
So things can't be too fast, and can't be too slow, it has to be Just Right?...
An explanation is that the developers are morons^W incompet^W morons.
Why not just fork it and see, if the project takes off?
If you're going to invest time and effort into something, it'll be nice to know what the chances of your investment paying off are.
Asking the community "Hey, I'm doing a $PROJECT fork. Whadda' ya' all think?" is one way of getting a feel for how likely people are to get behind you.
Why not use XTest? Yes, it's an extension. Who has an X server which doesn't have it?
Step forward and tell us about you system, please. Do you run wine?
In the worst case: have the code query for the XTest extension; if it's there, use it. If not, don't. File a bug instantly when that code is committed, saying "This is code we don't want, but it's useful for now. Reimplement what it does once there's a better way."
In some situations, being Open Source is a merit in itself.
Giving preference to Open Source is one way to let that merit influence your decision.
Exactly how much preference Open Source will have (and should have) is open to debate. Is it "all else equals", or is it "unless there's a strong compelling reason not to", or somewhere between?
No. For one, as my sibling has noted, that couldn't be it at the time. As a poster further down has eloquently noted, "button Fail! button button Succed! ENDORPHINS!!!"
I hold that over the last twenty years, computer games haven't been getting more fun to play. They've gotten better looking, better sounding and more imersive (it's cool how the B button on the wiimote feels kinda' like a trigger...).
But I think there's a limit to how far you can push the endorphin high. (Isn't it dopamine?)
If that's correct, I predict that over the next twenty years, computer games will not become substantially more fun to play. (yes, that's vague. I don't study media science, so do not sue me.)
Another poster has claimed it was the lack of alternatives. I think there's a bit of truth to that: I think people will be unhappy when they get a good deal if they know they could have gotten a better deal. So once newer, better alternatives to our current games come up, we will (broadly speaking) want the better games rather than the perfectly fine but not-quite-as-good games. This desire may not be strong enough to overpower nostalgia, though.
On my Wii, I have Metroid Prime 3: Corruption (a made-for-the-Wii first-person shooter) and the shareware versions of Wolfenstein 3D, Doom and Quake.
Sure, MP3:C has some neato cutscenes and the environment has more polygons. But all three ID shooters are quite viable competitors to MP3:C, because they're great fun (and I really suck at Wolfenstein...).
Now, it should be said that MP3:C have few and quite easy monsters. In a sense it feels more like a first person action adventure than a shooter (but maybe I should play at the Veteran difficulty level?), whereas the ID games have lots of moving stuff that should be shot at (with progressively more powerful weapons), and that's about it.
(I'm slightly disappointed by MP3:C because I expected it to be something it's not: a frag fest. It's quite good, and it isn't worse for being what it is rather than what I expected, just a step sideways. There's my bias).
It's not just that there wasn't anything better at the time. It's that they are actually quite good games. Modern games look nicer, sound nicer, and some even have a story;) but I hold that games, through time, haven't actually become more fun to play.
The real question one wants to ask: what maximizes the security of security measures?
For passwords, we want something that's easy to remember and hard to guess. Hard to guess means it has to appear random: it has to be chosen with a large amount of entropy from the set of valid passwords. In other words, it needs to have a high amount of information content.
"Easy to remember" is at odds with "high information content": the more you have to remember (generally speaking) the harder it is. However, there are mitigating factors.
One is the rehearsal effect: by training something (repeatedly retrieving your password from memory), you become better at it. This can somewhat mitigate the problem of long, hard-to-remember passwords.
Another trick is to exploit the way human memory works. It doesn't just store a big array of bytes like a disk does. I conjecture that the more connected a piece of information is to other pieces of information, the easier it is to remember. (the ocw.mit.edu psych 101 tells that this is certainly true for short-term/working memory.)
A neat trick (recommended by root@myuni) is to come up with a list of words which mean something (say, they're part of a nonsense phrase you made up*), picking the first letters**, adding some punctuation, and using that.
** Maybe I'd recommend picking the i'th mod n of word i where len(word i) == n, due to language statistics issues.
* Say you can remember "Ash nazg durbatuluk, Ash nazg gimbatul, Ash nazg thrakatuluk, Agh burzum-ishi krimpatul" (one ring to {rule,find,bring,bind} them all). Pick as your password AnrAntAglAbi.
If you don't remember geek poetry, pick a list of people you've had crushes on, ordered chronologically, and capitalize every one you've actually been with.
Note that your password must contain at least one upper-case letter. If it doesn't, you have bigger things to worry about than the security of your slashdot account:p
The sticky issue, from a theoretical standpoint, is that you want a password that's very random, but randomness (i.e. entropy) is an attribute of the distribution, not the sample. That means you can't really say that choosing "password" isn't random.
The practical upshot is that you want to choose passwords that evil people are unlikely to guess, which is dependent on what typical people use as passwords. So, by enforcing "nasty" rules, you force users to select something with at least a little entropy (_which_ upper/digit/punct and where it is). Sadly, it'll be Passwo!1, Passwo!2, Passwo!3, etc.
An interesting rule: no three consecutive members of the same character class.
Even iPods [...] have been shipped with malware pre-installed.
As the iPod marketing campaign leader*, I have to take offense.
The iPod doesn't ship with "mal"ware. It ships with a friendly software agent which makes sure the musicians and artists get paid what they deserve. You love art, don't you? You don't want the artists to starve, do you?
You call it malware. we call it Delivering Revenue to Musicians, or "DRM" for short.
(* statistics and benchmarks were in short supply, so I lied a little instead.)
This is used to make sure your project is 100% legal.
Isn't it strictly speaking used to make sure that you 100% avoid a particular way of being illegal?
Say I write a program which prints "Niggers are evil" and exits. You can create a clean room implementation of the same program and avoid copyright problems. Depending on your local laws regarding hate speech or similar, what the program does might still be illegal.
(I don't think anything bad of people of any particular skin color or ethnicity.)
Slashdot Mirror
Don't forget your towel. :D
Is that for lunch or for when the airports close up all the toilets? :p
Actually, there are things you can do with Java/C# that you can't do with C period.
Really?
C (and even assembly) can't realize that the same inputs to a routine always cause the same output
I think the volatile keyword means an external agent can modify the contents of a variable, and if you don't specify volatile, no such agent can. So for all the non-volatile stuff, the compiler can perform the same static analysis that a Java/C# compiler does to decide whether a function has your specified behavior or not.
And if you're not happy with it, in GCC you can annotate your functions. Wrap the annotation in a portable macro (that does, say, nothing on non-gcc compilers) and Bob's your uncle.
when Java 7, 8 or 9 comes out, ALL java code will run faster
And what's to stop people from writing a linker which does some "post-production" optimizations on the object code? If the compiled C code stores as much symbolic information as the Java code, I'd guess you could do a lot of stuff that's typically done in the compiler to the object code (dead write elimination if they're not done yet).
Also, note that traversing data structures representing byte code isn't free. If later JVMs do more work to optimize code before running it, I predict they will take longer to start up.
From a theoretical standpoint, your C compiler could be cat(1) if you have a sufficiently sophisticated runtime. Then you can do all sorts of crazy stuff at runtime.
I think the best kind of argument which is similar to yours is "let's look at practical achievements".
Are people shipping fancy linkers that speed up C code? No, they're not. Are JVMs employing fancy optimization techniques at run-time? Yes, they are. Is C substantially faster than Java at run-time? Yes, it is.
The real issue is, when Java 7, 8 or 9 comes out, ALL java code ever produced will run faster [...].
It'll still be slower than all the C code out there.
Here's a car analogy: once $BRAND1 finds a more efficient combustion process, all their cars go from 50 to 60 miles per fuel cell that same day. Let's compare to $BRAND2, whose cars run 100 miles per fuel cell today. Which do you want? 60 or 100? Remember: the biggest number is the best here.
Try running, say, SBCL [...] Paul B.
Hi Paul. Is the B short for "Braham"? ;-)
Based on my theoretical understanding of how computers work, I though HTTP daemon performance depended mostly on
Would someone care to correct me?
Note that TFA (well, the slideshow) measures performance in requests per second. That's a very useful measure, but it's compared to Ruby (Mongrel?) and PHP (Apache?). I'm not sure what that comparison means. Does Apache not support lisp, or only as CGI?
Is there something stopping Apache from being sped up? Is he measuring the performance of LISP, or the performance of a HTTP daemon?
I'm a bit confused...
[after installing XP] I lost the will to live after 35 reboots to install the OS
Try doing that and watching it get Sasser'd twenty seconds after you plugged in the network cable :(
You need to use an obscure Linux distro or else you'll still be a mindless sheep that other Linux users will laugh at.
I use DARKSTAR Linux, you insen... wait, I'm the insensitive clod, you sheep!
"Oh, you know, it is now 50 years since this author died [...]"
Douglas Adams died in 2001.
So sayeth http://en.wikipedia.org/wiki/Douglas_Adams and the Google search results cached snippet from douglasadams.com, http://www.google.com/search?q=douglas+adams
I'm sure you can find other sources if you want.
HHGTTG is from 1979; that is, it's thirty years old.
(No particular point. Just trying to add food for thought.)
celebrating the fucking towel?
No. It's celebrating Douglas Adams and his writings.
The towel is an item used to celebrate DA, in much the same way that you don't celebrate a flag but use a flag in celebration of your (sadly fallen) compatriots.
It's all about the symbolic value. Just as a flag is a symbol for national pride (which is a Great Thing when not done in excess), the towel is a symbol for (and manifestation of) Douglas Adams' witty humor.
Also, on slashdot, what percentage is American? What percentage has read Douglas Adams?
But wait... I thought the 42nd day was Towel Day?
Surrendering privacy or security is NEVER a valid option in a distributed application.
If you have more than one computer, have your stolen laptop talk to your home server via an encrypted channel. Then you get both.
Actually, it wouldn't be such a horrible idea*.
Just come up with an RSA keypair and store it on all your machines. Encrypt and sign all data you want to store "in the cloud", and find someone who will store it for you.
* Slashdot might object to this and delete your post. I recommend using Reed-Solomon coding (or some other error-correcting code) and storing your data redundantly on several sites.
You could also do mirrored RAIF (Redudant Array of Indepedent Forums), though it might be rife for puns. And RAIP, where P=Posts, would be ripe for them. (Someone's gonna RAIP my karma for that, but the puns and anagrams form such a FAIR PAIR...)
a) Defrag the disk.
b) Stop the users typing so fast.
ZOMFG! Please find some code and put it on The Daily WTF.
Unless the coders are doing it horribly wrong, the observable effect of defragging the disk should only be to speed up disk access. Okay, so things can't be too slow.
Stopping the users from typing too fast---unless you're doing it horribly wrong, this can only be a performance issue.
So things can't be too fast, and can't be too slow, it has to be Just Right? ...
An explanation is that the developers are morons^W incompet^W morons.
Microsoft recommends increasing your system stability by leaving your scanners not plugged in.
http://www.youtube.com/watch?v=vzFUcDKC64E
prostitution hasn't been legalised, it's been decriminalised.
So it's not legal, but it's not a crime either?
Is it a civil matter, then? Who's supposed to sue the prostitutes? Their customers?
Isn't it easier and far more just for craigslist to take a neutural stance and let the justice system do it's job on a neutural basis.
I don't know, that takes some serious balls, and might leave craigslist a fertile ground for lawsuits. The courts are quite potent, you know...
Why not just fork it and see, if the project takes off?
If you're going to invest time and effort into something, it'll be nice to know what the chances of your investment paying off are.
Asking the community "Hey, I'm doing a $PROJECT fork. Whadda' ya' all think?" is one way of getting a feel for how likely people are to get behind you.
Why not use XTest? Yes, it's an extension. Who has an X server which doesn't have it?
Step forward and tell us about you system, please. Do you run wine?
In the worst case: have the code query for the XTest extension; if it's there, use it. If not, don't. File a bug instantly when that code is committed, saying "This is code we don't want, but it's useful for now. Reimplement what it does once there's a better way."
A project with as many contributers as Wine should have room for more than one programming styles than one.
A post with as many contributors as yours should have room for more than one "than one" than one.
In some situations, being Open Source is a merit in itself.
Giving preference to Open Source is one way to let that merit influence your decision.
Exactly how much preference Open Source will have (and should have) is open to debate. Is it "all else equals", or is it "unless there's a strong compelling reason not to", or somewhere between?
nostalgia
No. For one, as my sibling has noted, that couldn't be it at the time. As a poster further down has eloquently noted, "button Fail! button button Succed! ENDORPHINS!!!"
I hold that over the last twenty years, computer games haven't been getting more fun to play. They've gotten better looking, better sounding and more imersive (it's cool how the B button on the wiimote feels kinda' like a trigger...).
But I think there's a limit to how far you can push the endorphin high. (Isn't it dopamine?)
If that's correct, I predict that over the next twenty years, computer games will not become substantially more fun to play. (yes, that's vague. I don't study media science, so do not sue me.)
Another poster has claimed it was the lack of alternatives. I think there's a bit of truth to that: I think people will be unhappy when they get a good deal if they know they could have gotten a better deal. So once newer, better alternatives to our current games come up, we will (broadly speaking) want the better games rather than the perfectly fine but not-quite-as-good games. This desire may not be strong enough to overpower nostalgia, though.
There just wasn't anything better at the time.
On my Wii, I have Metroid Prime 3: Corruption (a made-for-the-Wii first-person shooter) and the shareware versions of Wolfenstein 3D, Doom and Quake.
Sure, MP3:C has some neato cutscenes and the environment has more polygons. But all three ID shooters are quite viable competitors to MP3:C, because they're great fun (and I really suck at Wolfenstein...).
Now, it should be said that MP3:C have few and quite easy monsters. In a sense it feels more like a first person action adventure than a shooter (but maybe I should play at the Veteran difficulty level?), whereas the ID games have lots of moving stuff that should be shot at (with progressively more powerful weapons), and that's about it.
(I'm slightly disappointed by MP3:C because I expected it to be something it's not: a frag fest. It's quite good, and it isn't worse for being what it is rather than what I expected, just a step sideways. There's my bias).
It's not just that there wasn't anything better at the time. It's that they are actually quite good games. Modern games look nicer, sound nicer, and some even have a story ;) but I hold that games, through time, haven't actually become more fun to play.
You're right on target.
The real question one wants to ask: what maximizes the security of security measures?
For passwords, we want something that's easy to remember and hard to guess. Hard to guess means it has to appear random: it has to be chosen with a large amount of entropy from the set of valid passwords. In other words, it needs to have a high amount of information content.
"Easy to remember" is at odds with "high information content": the more you have to remember (generally speaking) the harder it is. However, there are mitigating factors.
One is the rehearsal effect: by training something (repeatedly retrieving your password from memory), you become better at it. This can somewhat mitigate the problem of long, hard-to-remember passwords.
Another trick is to exploit the way human memory works. It doesn't just store a big array of bytes like a disk does. I conjecture that the more connected a piece of information is to other pieces of information, the easier it is to remember. (the ocw.mit.edu psych 101 tells that this is certainly true for short-term/working memory.)
A neat trick (recommended by root@myuni) is to come up with a list of words which mean something (say, they're part of a nonsense phrase you made up*), picking the first letters**, adding some punctuation, and using that.
** Maybe I'd recommend picking the i'th mod n of word i where len(word i) == n, due to language statistics issues.
* Say you can remember "Ash nazg durbatuluk, Ash nazg gimbatul, Ash nazg thrakatuluk, Agh burzum-ishi krimpatul" (one ring to {rule,find,bring,bind} them all). Pick as your password AnrAntAglAbi.
If you don't remember geek poetry, pick a list of people you've had crushes on, ordered chronologically, and capitalize every one you've actually been with.
Note that your password must contain at least one upper-case letter. If it doesn't, you have bigger things to worry about than the security of your slashdot account :p
The sticky issue, from a theoretical standpoint, is that you want a password that's very random, but randomness (i.e. entropy) is an attribute of the distribution, not the sample. That means you can't really say that choosing "password" isn't random.
The practical upshot is that you want to choose passwords that evil people are unlikely to guess, which is dependent on what typical people use as passwords. So, by enforcing "nasty" rules, you force users to select something with at least a little entropy (_which_ upper/digit/punct and where it is). Sadly, it'll be Passwo!1, Passwo!2, Passwo!3, etc.
An interesting rule: no three consecutive members of the same character class.
Is it...
Nah, it couldn't be...
Is it "hunter2"?
Even iPods [...] have been shipped with malware pre-installed.
As the iPod marketing campaign leader*, I have to take offense.
The iPod doesn't ship with "mal"ware. It ships with a friendly software agent which makes sure the musicians and artists get paid what they deserve. You love art, don't you? You don't want the artists to starve, do you?
You call it malware. we call it Delivering Revenue to Musicians, or "DRM" for short.
(* statistics and benchmarks were in short supply, so I lied a little instead.)
This is used to make sure your project is 100% legal.
Isn't it strictly speaking used to make sure that you 100% avoid a particular way of being illegal?
Say I write a program which prints "Niggers are evil" and exits. You can create a clean room implementation of the same program and avoid copyright problems. Depending on your local laws regarding hate speech or similar, what the program does might still be illegal.
(I don't think anything bad of people of any particular skin color or ethnicity.)
So in other words,
Right?