I was going to say that I have never downloaded a song or movie I was not entitled to --- but I am 35, so I don't count:P
(I never buy music anymore, as I think I have enough, and the movies I buy are usually priced at 25-50dkr~4-7€ --- I don't really care for the bother of being a pirate for so small amounts. Yes, the movies are old, but I am not in any hurry).
Actually, what will have happened in 5 years is that the code will have changed, but the original comment remains, so that the code now does something slightly different. And it will be hours of debugging fun to find out which is right, if any.
And the co-pilot can help with all kinds of situations that an autopilot can't handle, such as the pilot being drunk, has a medical problem such as stroke or heart attack, wants to bang the stewardess in 1st class, or wants to crash the plane because his wife left him and took the dog as well.
Ah, but what if they are drinking together, banging each other or the wife *is* the copilot? There is only one viable option. Democracy control! Every seat will get one meter, dial and handle.
There are lots of endpoints where I need to identify myself, but which I don't necessarily trust. Slashdot is one example. My bank is another, the people adminstering this countries registry of citizens a third. This is done by different means today (preshared passwordhash, certificate+password and OTP respectively, but practically assymetric id+encryption would be able to solve this annoying problem once and for all. Only, it isn't happening.
One-time passwords are a variation off the pre-shared key methods, where the sender and receiver have agreed on a set of keys on some presumed secure channel. Used as a method of identification, this method is exactly as secure as the pad (and its copies) are. However, the system does not have the advantages of asymetric encryption, in that whoever has the other copy of the preshared key (the bank, e.g.) can impersonate you, while with asymetric keys nobody can impersonate you (provided the channel where the public key is distributed is secured, like in the OTP example).
I think you will find that pulseaudio is able to quite a lot more than just play sounds. E.g, you can have one program play in your speakers and another in your usb headphones. The mainstay of the discussion is whether anyone needs this, and whether pulseaudio is bugfree enough for everyday use. The bit you mention has been solved by ALSA for a long time now.
But I would bet you a pretty eurocent that *some* of those who did pirate the game would in fact, had they not been able to pirate, have bought the thing. Personally, if I were a game developer, or would make the game a client-server thing, even if it was purely single player.
Dependent on your view, that doesn't matter. If you are wondering: "What platform should I develop for?", I'm sure you could care less why X outsells Y, as long as it does. As a customer, I'd also prefer the most popular smartphone OS (all else being equal) since that probably means the most support from various app developers. Again, the "why" wouldn't matter. Indeed, this is Win32/64's real selling point.
Well, if they wanted to hear how well a human group could play said music, then they were deceived, and cheated of their money. There is really no other reasonable way to view that. You might think them irrational for desiring a human performance, but then entertainment is really not very rational in the first place.
Yeah, but the IDEA of using a hash is that it is inreversible, so getting the hash out gives you nothing. Notes that this only works if it is salted.
The attack could still be valid, though, if the hashing occurs client side. I'm guessing that this is what the attack requires (it sound quite plausible that openid involves some kind of cryptographic hash that needs to match something).
No, since A) the hash will be salted and B) changing one character gives a completely different hash result (just try running md5sum on some strings). E.g:
password 286755fad04869ca523320acce0dc6a4
passwore 530bbcd6551386c86cbc0ebc6b007cc4
since they have proper resource management (something Java only have for memory).
What resource mgmt are you referring to?
Window handles, files, pipes, sockets. You know, resources: stuff that needs to be released at the right time.
And frankly, I find the value of not having to recompile very small. I mean, it is a matter of a build environment, since you need the actual test environment anyway.
I have about 80 desktops. Installing a build environment on each would be a royal PIA, and, for each update, going to each machine and rebuilding?
I assume that these 80 desktops are not running 80 different OS's? As I wrote, you need a build environment for each of the different test environments you already (presumably) have.
C++, which is oh-so-much better suited to desktop applications than Java is.
Not sure you noticed, but C++ itself does not provide a desktop environment. You could use GTK but Windows compatibility is not always given. You could use Qt, but it's not a pervasive as GTk, though it would work. Still, for every update, I'd have to rebuild for each platform and each platform would have to have it's own update procedures.
GTK would be C; I haven't used it. Mostly I use QT, and I just include it on windows --- everywhere else, it will be installed by the local package management (perhaps including Mac OS, we don't have customers on that platform at the moment). Compared to the other libraries I usually need, QT is quite benign.
Really, you need to read less marketing and more reality.
My application of 1.1 million lines of code runs on 80 boxes, currently mostly linux with some windows with updates happening multiple times a day. I also had tried Gtk with C++ and the main application used to be in Gtk/C++ so I know what's involved. Java is much much easier on multiplatform for those who have actually used both in real world environments. I guess this might be the "reality" you were referring to.
What sort of masochism had you use a C toolkit for C++? No wonder you have a bad experience. Multiple updates per day sounds like a nightmare for customer relations if nothing else. Thankfully, I don't have to use anything with that many updates.
I tried to make something with Swing once. And SWK another time. I'm still traumatised by the (bad!) experience. Too hard to do even simple things.
Let me give you a few then: Ruby, Python, Perl. Plus, all of these are not the fantastical pain in the behind to write in, since they have proper resource management (something Java only have for memory).
And frankly, I find the value of not having to recompile very small. I mean, it is a matter of a build environment, since you need the actual test environment anyway. If that artificial requirement is dropped, we can add C++, which is oh-so-much better suited to desktop applications than Java is.
Really, you need to read less marketing and more reality.
Sometimes the gnome-power-manager is consuming 200 MB of ram all on its own.
I'm all for bashing Gnome, but I think in that case you're not reading the numbers right. Probably, most of those 200MB are links to shared libs loaded anyway as part of the Gnome system. If you divide that bit up equally among all the users of those libraries, you'll probably end up with 4-6M or so. If you only take the bit that is used *extra* for having gnome-power-manager, you'll probably get less than a megabyte, a likely less than.1.
All numbers are wild guesses since I don't actually have a Gnome system:)
The myth is that it is especially so. Most languages are crossplatform to the same degree, including C, Python, Haskell and ECMAscript.
The other languages, sure, but not C. Sure, the standard library is cross platform, but the moment you go beyond the standard C library, you're stuck with platform specific tools.
No. You are free to use cross platform tools, same as Java. There is no difference in class, only in the details. That is, in both languages it is possible to write cross platform (I have done so in both, the effort is really not that great), and in either it is possible to break a platform. For example, some platforms does not support files starting with a number in some cases. Sure, Java comes with a huge cross platform library, but that has little to do with the language.
Do you understand what it means to work in a corporation with distributed clients? It means that every update to a fat app that needs to be pushed through is a new installation. This is just not the case with web applets. An update is transparent to the user and is immediate across all clients from administration perspective.
I think you don't understand the use case.
Oh, point taken. My company is linux through and through, so we just update the repository and all apps are upgraded automatically. Naively, I thought windows could do the same. Even so, that usecase could be handled more generally by simply using self-updating apps, like e.g. online games do, without being restricted to Java.
Python, yes. C, no. Not unless you include the source code, and recompile for the new platform.
You are confusing the language with the runtime environment. Nothing prevents a C program to be translated to Java bytecode (or python ditto), which can then be run in a JVM. Likewise, there is no rule that a Java program has to be translated into intermediate bytecode, to be interpreted or compiled at invocation.
Sun's claim was that Java class files wouldn't need to be recompiled to run. I found that reasonably true. (Of course, you had to be running on a compatible JVM which had been compiled for the appropriate local platform.)
Note, by the way, that Python achieves cross-platform capability by an exactly comparable means. Ruby and ECMAscript basically don't HAVE a compiled form, but if they did it would be the same argument. (Don't know about the others.)
My point exactly. It's hardly unique, even at the time.
Well, substitute your "java applet" with "normal fat application", and you will get all the same advantages, except the fantasy about "1 click and it works":) Sorry, 1 click will not even get you past the "please download the appropriate plugin" screen. Then the start is horrible slow --- I know, since I use one applet from my bank. We are talking 20-30 seconds, and the applet is very, very small (and probably cached, as you say). That is just not acceptable for a modern web application.
Personally, I prefer fat apps. Dependable, quickly developed and the open source nature makes them less of a security issue. Such an app can then use a (restful?) web service to get all the advantages of being in a browser. The only price I get is that I have to install it. Last I checked I was not lacking for HD space.
By that argument, you might just as well write the entire thing in python/C++/ZoopedUpZuperLanguage++ and provide a download link. The *point* of webbased apps is that there is no download involved and that the application integrates well with the browser. Neither is very true for Java webapps. Besides, even the Java people tell me that applets are a deadend.
Slashdot Mirror
DB2, the only database I've encountered so far that is more inconsistent than Mysql. (Note that I have never used access)
US is not the world.. I can use DeCSS perfectly legally. Or at least, that's what our ministry of culture said when asked.
I was going to say that I have never downloaded a song or movie I was not entitled to --- but I am 35, so I don't count :P
(I never buy music anymore, as I think I have enough, and the movies I buy are usually priced at 25-50dkr~4-7€ --- I don't really care for the bother of being a pirate for so small amounts. Yes, the movies are old, but I am not in any hurry).
You need to learn to use libraries :P
Actually, what will have happened in 5 years is that the code will have changed, but the original comment remains, so that the code now does something slightly different. And it will be hours of debugging fun to find out which is right, if any.
And the co-pilot can help with all kinds of situations that an autopilot can't handle, such as the pilot being drunk, has a medical problem such as stroke or heart attack, wants to bang the stewardess in 1st class, or wants to crash the plane because his wife left him and took the dog as well.
Ah, but what if they are drinking together, banging each other or the wife *is* the copilot? There is only one viable option. Democracy control! Every seat will get one meter, dial and handle.
20 cents for one SMS? Around here (DK) it would be 1-3 cent, and I think that is pretty steep.
There are lots of endpoints where I need to identify myself, but which I don't necessarily trust. Slashdot is one example. My bank is another, the people adminstering this countries registry of citizens a third. This is done by different means today (preshared passwordhash, certificate+password and OTP respectively, but practically assymetric id+encryption would be able to solve this annoying problem once and for all. Only, it isn't happening.
One-time passwords are a variation off the pre-shared key methods, where the sender and receiver have agreed on a set of keys on some presumed secure channel. Used as a method of identification, this method is exactly as secure as the pad (and its copies) are. However, the system does not have the advantages of asymetric encryption, in that whoever has the other copy of the preshared key (the bank, e.g.) can impersonate you, while with asymetric keys nobody can impersonate you (provided the channel where the public key is distributed is secured, like in the OTP example).
I think you will find that pulseaudio is able to quite a lot more than just play sounds. E.g, you can have one program play in your speakers and another in your usb headphones. The mainstay of the discussion is whether anyone needs this, and whether pulseaudio is bugfree enough for everyday use. The bit you mention has been solved by ALSA for a long time now.
But I would bet you a pretty eurocent that *some* of those who did pirate the game would in fact, had they not been able to pirate, have bought the thing. Personally, if I were a game developer, or would make the game a client-server thing, even if it was purely single player.
Global warming is unlikely to kill humanity.
Dependent on your view, that doesn't matter. If you are wondering: "What platform should I develop for?", I'm sure you could care less why X outsells Y, as long as it does. As a customer, I'd also prefer the most popular smartphone OS (all else being equal) since that probably means the most support from various app developers. Again, the "why" wouldn't matter. Indeed, this is Win32/64's real selling point.
Well, if they wanted to hear how well a human group could play said music, then they were deceived, and cheated of their money. There is really no other reasonable way to view that. You might think them irrational for desiring a human performance, but then entertainment is really not very rational in the first place.
Yeah, but the IDEA of using a hash is that it is inreversible, so getting the hash out gives you nothing. Notes that this only works if it is salted.
The attack could still be valid, though, if the hashing occurs client side. I'm guessing that this is what the attack requires (it sound quite plausible that openid involves some kind of cryptographic hash that needs to match something).
No, since A) the hash will be salted and B) changing one character gives a completely different hash result (just try running md5sum on some strings). E.g:
password 286755fad04869ca523320acce0dc6a4
passwore 530bbcd6551386c86cbc0ebc6b007cc4
Yeah. It really makes me worry about Java's future. Is there any other comparable cross-platform language that runs in a managed environment?
C#^H Mono? Really, you have to be more specific. What are you requirements?
since they have proper resource management (something Java only have for memory).
What resource mgmt are you referring to?
Window handles, files, pipes, sockets. You know, resources: stuff that needs to be released at the right time.
And frankly, I find the value of not having to recompile very small. I mean, it is a matter of a build environment, since you need the actual test environment anyway.
I have about 80 desktops. Installing a build environment on each would be a royal PIA, and, for each update, going to each machine and rebuilding?
I assume that these 80 desktops are not running 80 different OS's? As I wrote, you need a build environment for each of the different test environments you already (presumably) have.
C++, which is oh-so-much better suited to desktop applications than Java is.
Not sure you noticed, but C++ itself does not provide a desktop environment. You could use GTK but Windows compatibility is not always given. You could use Qt, but it's not a pervasive as GTk, though it would work. Still, for every update, I'd have to rebuild for each platform and each platform would have to have it's own update procedures.
GTK would be C; I haven't used it. Mostly I use QT, and I just include it on windows --- everywhere else, it will be installed by the local package management (perhaps including Mac OS, we don't have customers on that platform at the moment). Compared to the other libraries I usually need, QT is quite benign.
Really, you need to read less marketing and more reality.
My application of 1.1 million lines of code runs on 80 boxes, currently mostly linux with some windows with updates happening multiple times a day. I also had tried Gtk with C++ and the main application used to be in Gtk/C++ so I know what's involved. Java is much much easier on multiplatform for those who have actually used both in real world environments. I guess this might be the "reality" you were referring to.
What sort of masochism had you use a C toolkit for C++? No wonder you have a bad experience. Multiple updates per day sounds like a nightmare for customer relations if nothing else. Thankfully, I don't have to use anything with that many updates.
I tried to make something with Swing once. And SWK another time. I'm still traumatised by the (bad!) experience. Too hard to do even simple things.
Let me give you a few then: Ruby, Python, Perl. Plus, all of these are not the fantastical pain in the behind to write in, since they have proper resource management (something Java only have for memory).
And frankly, I find the value of not having to recompile very small. I mean, it is a matter of a build environment, since you need the actual test environment anyway. If that artificial requirement is dropped, we can add C++, which is oh-so-much better suited to desktop applications than Java is.
Really, you need to read less marketing and more reality.
Sometimes the gnome-power-manager is consuming 200 MB of ram all on its own.
I'm all for bashing Gnome, but I think in that case you're not reading the numbers right. Probably, most of those 200MB are links to shared libs loaded anyway as part of the Gnome system. If you divide that bit up equally among all the users of those libraries, you'll probably end up with 4-6M or so. If you only take the bit that is used *extra* for having gnome-power-manager, you'll probably get less than a megabyte, a likely less than .1.
All numbers are wild guesses since I don't actually have a Gnome system :)
The myth is that it is especially so. Most languages are crossplatform to the same degree, including C, Python, Haskell and ECMAscript.
The other languages, sure, but not C. Sure, the standard library is cross platform, but the moment you go beyond the standard C library, you're stuck with platform specific tools.
No. You are free to use cross platform tools, same as Java. There is no difference in class, only in the details. That is, in both languages it is possible to write cross platform (I have done so in both, the effort is really not that great), and in either it is possible to break a platform. For example, some platforms does not support files starting with a number in some cases. Sure, Java comes with a huge cross platform library, but that has little to do with the language.
Do you understand what it means to work in a corporation with distributed clients? It means that every update to a fat app that needs to be pushed through is a new installation. This is just not the case with web applets. An update is transparent to the user and is immediate across all clients from administration perspective.
I think you don't understand the use case.
Oh, point taken. My company is linux through and through, so we just update the repository and all apps are upgraded automatically. Naively, I thought windows could do the same. Even so, that usecase could be handled more generally by simply using self-updating apps, like e.g. online games do, without being restricted to Java.
Python, yes. C, no. Not unless you include the source code, and recompile for the new platform.
You are confusing the language with the runtime environment. Nothing prevents a C program to be translated to Java bytecode (or python ditto), which can then be run in a JVM. Likewise, there is no rule that a Java program has to be translated into intermediate bytecode, to be interpreted or compiled at invocation.
Sun's claim was that Java class files wouldn't need to be recompiled to run. I found that reasonably true. (Of course, you had to be running on a compatible JVM which had been compiled for the appropriate local platform.)
Note, by the way, that Python achieves cross-platform capability by an exactly comparable means. Ruby and ECMAscript basically don't HAVE a compiled form, but if they did it would be the same argument. (Don't know about the others.)
My point exactly. It's hardly unique, even at the time.
Well, substitute your "java applet" with "normal fat application", and you will get all the same advantages, except the fantasy about "1 click and it works" :) Sorry, 1 click will not even get you past the "please download the appropriate plugin" screen. Then the start is horrible slow --- I know, since I use one applet from my bank. We are talking 20-30 seconds, and the applet is very, very small (and probably cached, as you say). That is just not acceptable for a modern web application.
Personally, I prefer fat apps. Dependable, quickly developed and the open source nature makes them less of a security issue. Such an app can then use a (restful?) web service to get all the advantages of being in a browser. The only price I get is that I have to install it. Last I checked I was not lacking for HD space.
By that argument, you might just as well write the entire thing in python/C++/ZoopedUpZuperLanguage++ and provide a download link. The *point* of webbased apps is that there is no download involved and that the application integrates well with the browser. Neither is very true for Java webapps. Besides, even the Java people tell me that applets are a deadend.