That's not an insider dev comment, you fucktard. That's a direct copy-and-paste from 3Drealms' website. Not to mention, if the game _was_ going to be released, they would probably have agreements with the stores in place long before it's announced on their website.
I've had lots of random problems. The drivers are shitty. The devices are shitty. The spec sucks. I have a computer which absolutely refuses to work with my iPod, at least at USB2 speeds. I have another computer which refuses to work with the iPod at USB1 speeds, but works OK at USB2. I've had constant, random USB flakiness. My guess is that Apple and the mobo manufacturers cut some corners with things like trace impedances and connectors. Definitely not an example of good interoperability, and USB has a _very_ big specification.
Probably just as well, if not better. If there isn't a spec, you might actually have to _test_ a variety of devices with a variety of operating systems. If there is a spec, you make a chip "to spec" and tweak it until it works with WinXP. I bet that's the design process most of those USB devices go through.
Why would you run any general-purpose operating system on a point-of-sale terminal?
It's much cheaper to use an existing OS than developing a custom OS. There isn't even any reason to develop a custom OS, considering both Windows and Linux work quite well for such applications. Not to mention, you can use cheap off-the-shelf hardware and drivers instead of having to develop your own.
For that matter, why would you use an x86 CPU in a cash register?
Maybe because it's cheap and easy to develop for?
The new Windows ATMs are 3 times slower and 100 times less reliable.
They also don't look fugly, are easier to use, and probably cost less to maintain.
One wonders why the rush to abandon the old software that worked perfectly well.
Legacy custom-developed software is typically a money pit. What if all that crap is coded in Assembler for some obsolete CPU? What if you need support for modern networking protocols?
Betamax is not used for anything anymore. The professional format has a similar name, but has absolutely nothing to do with Betamax -- it's a completely different format.
Betamax had better audio and video fidelity, and by almost all accounts was the better technology... apart from the fact that Beta tapes only came in 1 hour lengths (for quite a long time) and the video quality difference was not huge (the audio quality was actually worse on Betamax). Not to mention that Beta tapes were always much shorter than VHS tapes, and tape rewinding was much slower and put more wear on the machine. I really doubt that porn had much to do with it -- you don't need anyone's permission to record porn on a videotape.
Their GUI configurators are slow and tedious compared to editing a couple of files in/etc
Well, I think that pretty much describes why most people hate Gentoo. Everything is typically set up with crazy defaults and requires tons of confuguration to make into an acceptable system. Compared to Fedora or Mandrake, where most things (like ntpdate) work out of the box and don't require any configuration.
I put a deep gouge in my iPod's screen (4th gen unit) simply by dragging my fingernail across it LIGHTLY. The plastic they use is horribly susceptible to scratching -- much more so than my cellphone, for instance. I had to stick a piece of clear packing tape over the screen to keep it from getting unreadable. And yes, it will get unreadable if it has a lot of small scratches (which are caused by denim rubbing against it).
Is your complaint that it was slow serialzing objects across the network?
No. Mainly things like the user interface being less than responsive, graph rendering being fairly slow, things like that. The speed was acceptable, and overall Java was a great choice for the application. It was certainly much slower than native code.
Java hasn't done that since the stone age. JVMs use a process known as "Just In Time" (JIT) compilation that compiles the code prior to execution.
An interpreter translates instructions into machine code at runtime, one way or another. Dynamic recompilation is one way to do it. This is what causes the overhead of interpreted languages. Of course, some implementations have more overhead than others.
It calculates which one is faster for a given piece of code (yes, interpreted can be faster in certain circumstances) and then makes a decision on how to proceed. Pretty much all code that gets run more than once is fully compiled.
Compilation takes an awful lot of time. Something like Firefox would take a couple of hours to compile on my system, especially with optimization turned on. Therefore, I _really_ doubt that even the majority of the code gets compiled. This causes lack of responsiveness, since it has to do the compilation/interpretation when you open a window or press a button or do anything.
A virtual machine has nothing to do with interpreted code.
All interpreters are virtual machines. Not all virtual machines are interpreters.
VMWare is a virtual machine. It doesn't interpret jack.
It doesn't have to execute bytecode, either.
If you want an app that can get incredibly slow, try Open Office (especially when you load a 50 meg Writer document).
How the hell do you come up with a 50 meg Writer document? That's like 20 good-sized books concatenated together. I dare you to find a Java word processor that can parse a 50 meg XML document as fast.
You're picking a highly advanced development environment with more features than Carter has little pills as an example of why a language is slow?
So, I should be using "Hello, world" as a benchmark?
The BitTorrent client is distributed as precompiled python code.
Speaking of ignorance... There is no such thing as native python code. The "compilation" step simply translates the python file into bytecode so that the interpreter does not have to do parsing. It's still interpreted. You can't run the app standalone, and it most certainly does not have ELF headers (look at it with a hex editor, Mr. Smartass).
Uh huh. So, did you run ICEBrowser? What did you learn?
Just a suggestion, but if you want low-maintenance, Gentoo is probably the worst choice you could have made. Try Fedora or Mandrake or Suse or something. Gentoo is inherently high-maintenance.
The only thing that stops hobbyists from producing these units is the low volume. I doubt Apple has their own manufacturing facilities. It's subcontracted out to China, where everything is fairly cheap as long as your order is a few hundred thousand units. Cost of assembly should not be much more than 10% of the BOM, probably much less.
More like a 5000 line network app that used RMI and other stuff. Nothing major, but I think I know it pretty well.
Java is not interpreted, nor has it been for a VERY long time. If you seriously programmed in it, then you would know this.
I don't know what your definition of "interpreted" is, but Java is most certainly interpreted. As in, your program is not machine code. Yeah, it compiles it into bytecode and does some neat dynamic recompilation tricks, but it runs it through a virtual machine. That's one way to implement an interpreted language.
Do I have to yank out the benchmarks that prove that this is nonsense?
Benchmarks don't mean much with Java. If you do some fairly repetitive test, the recompiler will probably optimize the hell out of it and it will be fairly fast. It doesn't work that way in large real-world apps. If you want an app that can get incredibly slow, try Eclipse (especially their visual editor component).
Now you're just being disingenous.
Well, BitTorrent is very fast even when written in Python, and python is many times slower than native code by anyone's yardstick. Maybe it's just not a demanding application.
No, no I haven't. Not since the bad old days of applets. And up until recently I used a PIII 733.
I use a 700MHz Duron, so maybe I notice more than you do. Please note, however, that a native GUI is fairly responsive even on a 200MHz processor. Java isn't that great even on a 700MHz one.
Simple. Just put in a huge bid in the last few minutes and win the auction. Then you pretty much have the guy's name and address. Most of these people think they are invincible because they are on the internet.
I've programmed quite a bit in Java. It's surprisingly fast -- for an interpreted language. Which basically means it runs 5x slower than native code instead of 30x slower. Of course, this might not be very noticeable for something like Azureus which is basically a GUI bolted on to some network code (most of which is native code that is part of the JVM or the OS). However, you will notice that the GUI is fairly sluggish compared to a native application, especially if your processor is not very fast. If you wrote firefox in Java, it would be a major memory hog and also very slow.
Fine. The cost of cracking DirecTV is a million bucks. That makes it expensive and unlikely that someone would go to the expense, but not impossible.
Nobody will ever spend a million bucks to crack DirecTV, because the goal would not be worth the expense. This effectively makes such a proposition impossible.
That's nice and all, but Java code runs slow enough to make it impractical for desktop apps. After all, security is nice, but it always comes AFTER usability. I'd say the real problem is sloppy programming.
We know that any form of DRM is breakable, not just through brute force, but by reverse engineering.
Not quite. You can't easily break a hardware protection scheme unless you are willing to spend millions of dollars on hacking the hardware. If you use strong encryption that is well-implemented and uses hardware, it will not be possible to crack. Nobody has yet cracked DirecTV encryption, for instance. The new initiatives like TCPA should make DRM extremely secure.
How much text can this LCD display? One line? Two lines if you have a magnifying glass? You will still have to hit NEXT about 100 times to get to another song.
Not to mention, these players are targeted at the sports users -- i.e. something that is used while running. You aren't going to stop and look at the display to change the song, it's much easier to just hit NEXT. Not to mention, with iTunes, how hard is it to select the songs you want to listen to and put THEM on the player instead of crap you do not want to listen to?
You can't run laser printers off of normal UPSs because laser printers consume huge amounts of power (thousands of watts) when they are printing. It would probably overload the UPS and trip its breaker or at least drain the battery quite a bit.
Well... It COULD destroy the card, but it may not -- the recording method is quite robust. It would be more likely to erase 2-year-old, worn-out credit cards than new hotel keys. Besides, modern systems do not store anything on the card other than an authorization code, so this is a moot point.
The problem is, it's impossible to do a GUI without programming. You can't separate "design" and programming, unless by "design" you mean "laying out the buttons". Sorry, this is not design, and is something a programmer is perfectly capable of doing. Design goes much deeper than that, and often requires programming-intensive things like custom widgets/controls and other fairly complicated stuff.
It would be very easy to defeat. They sell IR filters for cameras, actually. Just put something that doesn't reflect IR that much in front of the camera. A piece of acrylic in front of the lens would probably do it.
The RIAA is doing exactly what it should be doing: protecting its members' interests. The real problem is the US legal system, which was designed precisely to give large corporations and wealthy individuals an unfair advantage.
Slashdot Mirror
That's not an insider dev comment, you fucktard. That's a direct copy-and-paste from 3Drealms' website. Not to mention, if the game _was_ going to be released, they would probably have agreements with the stores in place long before it's announced on their website.
I've had lots of random problems. The drivers are shitty. The devices are shitty. The spec sucks. I have a computer which absolutely refuses to work with my iPod, at least at USB2 speeds. I have another computer which refuses to work with the iPod at USB1 speeds, but works OK at USB2. I've had constant, random USB flakiness. My guess is that Apple and the mobo manufacturers cut some corners with things like trace impedances and connectors. Definitely not an example of good interoperability, and USB has a _very_ big specification.
Probably just as well, if not better. If there isn't a spec, you might actually have to _test_ a variety of devices with a variety of operating systems. If there is a spec, you make a chip "to spec" and tweak it until it works with WinXP. I bet that's the design process most of those USB devices go through.
Why would you run any general-purpose operating system on a point-of-sale terminal?
It's much cheaper to use an existing OS than developing a custom OS. There isn't even any reason to develop a custom OS, considering both Windows and Linux work quite well for such applications. Not to mention, you can use cheap off-the-shelf hardware and drivers instead of having to develop your own.
For that matter, why would you use an x86 CPU in a cash register?
Maybe because it's cheap and easy to develop for?
The new Windows ATMs are 3 times slower and 100 times less reliable.
They also don't look fugly, are easier to use, and probably cost less to maintain.
One wonders why the rush to abandon the old software that worked perfectly well.
Legacy custom-developed software is typically a money pit. What if all that crap is coded in Assembler for some obsolete CPU? What if you need support for modern networking protocols?
Betamax is not used for anything anymore. The professional format has a similar name, but has absolutely nothing to do with Betamax -- it's a completely different format.
Betamax had better audio and video fidelity, and by almost all accounts was the better technology ... apart from the fact that Beta tapes only came in 1 hour lengths (for quite a long time) and the video quality difference was not huge (the audio quality was actually worse on Betamax). Not to mention that Beta tapes were always much shorter than VHS tapes, and tape rewinding was much slower and put more wear on the machine. I really doubt that porn had much to do with it -- you don't need anyone's permission to record porn on a videotape.
Their GUI configurators are slow and tedious compared to editing a couple of files in /etc
Well, I think that pretty much describes why most people hate Gentoo. Everything is typically set up with crazy defaults and requires tons of confuguration to make into an acceptable system. Compared to Fedora or Mandrake, where most things (like ntpdate) work out of the box and don't require any configuration.
I put a deep gouge in my iPod's screen (4th gen unit) simply by dragging my fingernail across it LIGHTLY. The plastic they use is horribly susceptible to scratching -- much more so than my cellphone, for instance. I had to stick a piece of clear packing tape over the screen to keep it from getting unreadable. And yes, it will get unreadable if it has a lot of small scratches (which are caused by denim rubbing against it).
Is your complaint that it was slow serialzing objects across the network?
No. Mainly things like the user interface being less than responsive, graph rendering being fairly slow, things like that. The speed was acceptable, and overall Java was a great choice for the application. It was certainly much slower than native code.
Java hasn't done that since the stone age. JVMs use a process known as "Just In Time" (JIT) compilation that compiles the code prior to execution.
An interpreter translates instructions into machine code at runtime, one way or another. Dynamic recompilation is one way to do it. This is what causes the overhead of interpreted languages. Of course, some implementations have more overhead than others.
It calculates which one is faster for a given piece of code (yes, interpreted can be faster in certain circumstances) and then makes a decision on how to proceed. Pretty much all code that gets run more than once is fully compiled.
Compilation takes an awful lot of time. Something like Firefox would take a couple of hours to compile on my system, especially with optimization turned on. Therefore, I _really_ doubt that even the majority of the code gets compiled. This causes lack of responsiveness, since it has to do the compilation/interpretation when you open a window or press a button or do anything.
A virtual machine has nothing to do with interpreted code.
All interpreters are virtual machines. Not all virtual machines are interpreters.
VMWare is a virtual machine. It doesn't interpret jack.
It doesn't have to execute bytecode, either.
If you want an app that can get incredibly slow, try Open Office (especially when you load a 50 meg Writer document).
How the hell do you come up with a 50 meg Writer document? That's like 20 good-sized books concatenated together. I dare you to find a Java word processor that can parse a 50 meg XML document as fast.
You're picking a highly advanced development environment with more features than Carter has little pills as an example of why a language is slow?
So, I should be using "Hello, world" as a benchmark?
The BitTorrent client is distributed as precompiled python code.
Speaking of ignorance... There is no such thing as native python code. The "compilation" step simply translates the python file into bytecode so that the interpreter does not have to do parsing. It's still interpreted. You can't run the app standalone, and it most certainly does not have ELF headers (look at it with a hex editor, Mr. Smartass).
Uh huh. So, did you run ICEBrowser? What did you learn?
That it doesn't work on Linux.
Just a suggestion, but if you want low-maintenance, Gentoo is probably the worst choice you could have made. Try Fedora or Mandrake or Suse or something. Gentoo is inherently high-maintenance.
The only thing that stops hobbyists from producing these units is the low volume. I doubt Apple has their own manufacturing facilities. It's subcontracted out to China, where everything is fairly cheap as long as your order is a few hundred thousand units. Cost of assembly should not be much more than 10% of the BOM, probably much less.
So you did a few applets back in the day?
More like a 5000 line network app that used RMI and other stuff. Nothing major, but I think I know it pretty well.
Java is not interpreted, nor has it been for a VERY long time. If you seriously programmed in it, then you would know this.
I don't know what your definition of "interpreted" is, but Java is most certainly interpreted. As in, your program is not machine code. Yeah, it compiles it into bytecode and does some neat dynamic recompilation tricks, but it runs it through a virtual machine. That's one way to implement an interpreted language.
Do I have to yank out the benchmarks that prove that this is nonsense?
Benchmarks don't mean much with Java. If you do some fairly repetitive test, the recompiler will probably optimize the hell out of it and it will be fairly fast. It doesn't work that way in large real-world apps. If you want an app that can get incredibly slow, try Eclipse (especially their visual editor component).
Now you're just being disingenous.
Well, BitTorrent is very fast even when written in Python, and python is many times slower than native code by anyone's yardstick. Maybe it's just not a demanding application.
No, no I haven't. Not since the bad old days of applets. And up until recently I used a PIII 733.
I use a 700MHz Duron, so maybe I notice more than you do. Please note, however, that a native GUI is fairly responsive even on a 200MHz processor. Java isn't that great even on a 700MHz one.
Simple. Just put in a huge bid in the last few minutes and win the auction. Then you pretty much have the guy's name and address. Most of these people think they are invincible because they are on the internet.
I've programmed quite a bit in Java. It's surprisingly fast -- for an interpreted language. Which basically means it runs 5x slower than native code instead of 30x slower. Of course, this might not be very noticeable for something like Azureus which is basically a GUI bolted on to some network code (most of which is native code that is part of the JVM or the OS). However, you will notice that the GUI is fairly sluggish compared to a native application, especially if your processor is not very fast. If you wrote firefox in Java, it would be a major memory hog and also very slow.
Fine. The cost of cracking DirecTV is a million bucks. That makes it expensive and unlikely that someone would go to the expense, but not impossible.
Nobody will ever spend a million bucks to crack DirecTV, because the goal would not be worth the expense. This effectively makes such a proposition impossible.
That's nice and all, but Java code runs slow enough to make it impractical for desktop apps. After all, security is nice, but it always comes AFTER usability. I'd say the real problem is sloppy programming.
We know that any form of DRM is breakable, not just through brute force, but by reverse engineering.
Not quite. You can't easily break a hardware protection scheme unless you are willing to spend millions of dollars on hacking the hardware. If you use strong encryption that is well-implemented and uses hardware, it will not be possible to crack. Nobody has yet cracked DirecTV encryption, for instance. The new initiatives like TCPA should make DRM extremely secure.
How much text can this LCD display? One line? Two lines if you have a magnifying glass? You will still have to hit NEXT about 100 times to get to another song.
Not to mention, these players are targeted at the sports users -- i.e. something that is used while running. You aren't going to stop and look at the display to change the song, it's much easier to just hit NEXT. Not to mention, with iTunes, how hard is it to select the songs you want to listen to and put THEM on the player instead of crap you do not want to listen to?
You can't run laser printers off of normal UPSs because laser printers consume huge amounts of power (thousands of watts) when they are printing. It would probably overload the UPS and trip its breaker or at least drain the battery quite a bit.
It's only worth it in California, really. Few other states have the incentives or the climate to make this worthwhile.
Well... It COULD destroy the card, but it may not -- the recording method is quite robust. It would be more likely to erase 2-year-old, worn-out credit cards than new hotel keys. Besides, modern systems do not store anything on the card other than an authorization code, so this is a moot point.
The problem is, it's impossible to do a GUI without programming. You can't separate "design" and programming, unless by "design" you mean "laying out the buttons". Sorry, this is not design, and is something a programmer is perfectly capable of doing. Design goes much deeper than that, and often requires programming-intensive things like custom widgets/controls and other fairly complicated stuff.
It would be very easy to defeat. They sell IR filters for cameras, actually. Just put something that doesn't reflect IR that much in front of the camera. A piece of acrylic in front of the lens would probably do it.
The RIAA is doing exactly what it should be doing: protecting its members' interests. The real problem is the US legal system, which was designed precisely to give large corporations and wealthy individuals an unfair advantage.
but give them ready and ordinary access to it for utility and they *will* drink it.
I'm not sure that's a bad thing. The world already has too many stupid people. Besides, it's already used in things like windshield fluid.