For that matter, none of my computers have a Blu-Ray drive, or an HD-DVD drive. An h.264 rip, 720p, at around 4 gigs, still looks much better than the DVD.
it seems the easy way to make sure keys are legit would be to go back to the old USB dongle trick.
Won't work. USB dongles have pretty much the same flaws as any other kind of DRM. That is, find this code:
if (dongleExists()) {
playGame(); } else {
lectureUserAboutPiracy(); }
And replace it with this:
if (true) {
playGame(); ...
So many other places to do the same thing.
Worst case, it does some sort of crypto inside the key -- which means it's still decrypted in RAM, and you can always convince the key you're legit and get it to decrypt the game for you.
The only solutions involve Trusted Computing, which is a rather large step towards simply being another console.
LOWER YOUR DAMN PRICES YOU GREEDY BASTARDS!!!!
SecuROM is insecure at any price.
I've got plenty of cash to spend on games. I don't, because I like playing the games, not playing the Windows admin cleaning up after a bunch of spyware^Wdrm.
The second iteration was actually probably the better, branding-wise.
They were all set -- Firebird for web, Thunderbird for email, Sunbird for calendar -- even things like Songbird for music. I think there were even logos.
Some properties are just much harder to make efficient, because it's hard to give guaranties on behaviour, while it perhaps wouldn't be so hard if the specification would be slightly different.
While true, I think that sometimes the changes aren't too bad.
And you don't need guarantees to optimize -- just educated guesses. You always keep enough around so that if your guess is wrong, you can drop the optimization and start over.
eval is never going to be fast, in any language, and you can make a lot of assumptions by ignoring it. But being able to eval when you really want to, even if it's a performance hit, is a beautiful thing.
I know eval is generally bad practice outside of an interpreter shell. It's a good example, though, because the things we really care about (define_method, method_missing, etc) are all somewhat less dynamic (and less troublesome) than eval. And if eval works, you can probably add any of those that are missing.
'maybe faster than C' is just wild speculation on your part. Lots of high-level languages try to be faster than C. It ain't easy.
Enough of them get close that I start to think the main factor is the amount more research that goes into improving C speed, both by compiler experts and by actual hardware manufacturers.
And I must say I just love your stab at Lisp.
I can't take credit, that's an old one. Probably as old as Pathologically Eclectic Rubbage Lister, which is actually official.
Surely that's the thing God used to create the universe.
Bringing forward syntax as an argument is extremely silly in my view.
Actually, I've discovered this is a central point, and sometimes more important than actual power.
Code is communication. With your peers, perhaps with you a month from now, even with the machine itself. It is a way to translate your intent into actual instructions so unambiguous a machine can follow them.
This has implications for all three of those parties. Speaking to others is important, because there's only so much you can do by yourself. Speaking to yourself a month from now is important, because there's only so much you can do while keeping the whole program in your head -- I would argue that readability is almost more important than how easily you can write code.
And it even matters for the machine -- because if you've managed to write a program which codifies only your intent, and nothing more -- which says much more about what you want done than how you want it done -- then that "how" can change, based on whatever is more efficient for the circumstance at hand.
It's true that a powerful-but-ugly language can do all of the above, provided everyone can read it well. What's important is how well it maps onto how you think, and how you actually communicate. Ruby, to me, is very readable and very natural -- I can express myself well in it, and when I read a chunk of Ruby, I actually understand what it does, even if I don't quite understand how.
The same cannot be said of most Lisp. I read a block of incredibly beautiful lisp, but it's only beautiful once I get it. And that takes awhile. It's like a Koan -- it certainly expands my mind, probably makes me a better programmer. But not for everyday use -- I don't want to try to use a Koan to order dinner. ("May I take your order?", "Give me the taste of a sugarless marshmallow.")
That, and... c'mon. Take a lesson from python and make at least some of those parens implicit.
Or do you complain that you shouldn't NEED a key to drive away in the car you just purchased?
A key, yes. A key is a minor inconvenience, and doesn't restrict me from anything, so long as I don't lose it. Moreover, a key provides added value, in that it prevents someone from stealing my car -- note that this would, in fact, deprive me of my car, and not the manufacturer of some imaginary amount of money.
Irrelvent; I never asked anyone to build a breadbox either, but there's still lots of them around.
And no one calls me a thief for not paying for them. I simply don't take them.
I suspect that no one would call me a thief, either, for taking a photograph of one, going out and buying the wood, and assembling my own.
There are a suprising number of people that wouldn't pay for the game. No, I'm not claiming DRM will stop people.. it may stop some though.
Unlikely that it will stop a significant number. It might be interesting to compare it to the number of people who have stopped buying PC games altogether because of DRM.
Of course, no one would bother with DRM if games actually weren't being pirated to begin with. This is a case where a (hopefully) minority of people ruined it for everyone.
It's a case study where no one is right. Considering how little effect DRM actually has on piracy (possibly a net negative effect, as I am an example of)... What is the excuse for a publisher to do this?
It's a bit like trying to counter shoplifting with severe penalties for wearing trenchcoats or carrying any unauthorized bags. The shoplifters will find another way, and in the meantime, you've managed to inconvenience a large portion of the population.
Consider that shoplifting is actually stealing, and I still don't consider ridiculous security measures to be justified.
Sure it is; by pirating, you re-enforce the idea that people would rather steal their work than buy it.
Maybe.
Or maybe I reinforce the idea that people don't want to deal with DRM.
How many actual studies have been done on this issue? How many hard statistics do we have? At this point, it's all speculation, which means I have to lean in favor of not treating your paying customers like criminals.
Oh wait, you're talking about secureROM. In that case, you bought a car and don't like the anti-lock brake system it came with.
Except that SecuROM doesn't just cause problems for itself. It causes problems for the rest of the system, too, and has for quite awhile. People's CD writers stop working, or their drives disappear entirely. The game insists that they uninstall certain other software, which is a bit unreasonable -- like your car refusing to be in the same garage with a truck.
And regardless, it is not uninstalled when the game is, even if said game was only a demo.
So as long as we're playing with analogies, this is a bit more like trying to test-drive a car, and it (painfully) brands a permanent barcode on your arm (which stings in the winter, and is possibly carcinogenic), refuses to start within a hundred feet of your SUV, and every now and then, when you're wearing the wrong clothes, it decides you're a thief and refuses to start, even if you have the key.
And on top of all that, the manufacturer didn't give you a key. They gave you most of a key. You had to carve the last notch yourself.
You're rationalizing, and you know it.
You don't have any more actual arguments, so you're appealing to emotion. You're good at that, but I'm not biting.
The product was designed a certain way, and part of that design includes relying on SecureRom.
Perhaps garbage collection is better when someone doesn't get memory management... But it is not possible for garbage collection to perform better than a competent engineer.
There are other ways as well -- every malloc and free that you write inline with your code is, well, more code. Which means more cache misses. A garbage collector should fit into cache for the duration of its run, and then be swapped out.
Certainly, it won't always win. And by definition, a human can always do at least as well because a human can at the very least write that garbage collector, and possibly other things on top of it. But if you care about performance, it is something to consider.
That's because C deals with how computers actually think.
It actually really doesn't. Assembly is closer, but still not what's actually going on.
For example yes, pointers are confusing and you can get in to trouble with them. However, that is actually how a processor handles things.
Yes, registers are confusing and you can get in trouble with them. However, that is actually how a processor handles things.
There's a reason you use C, and not assembly. It's the same reason I use Ruby, and not C.
you need to be able to write a program based on how the computer thinks, not on how you do.
When performance is critical, yes.
When it's not -- and it's usually not -- it's infinitely more important to have a program structured well enough that you can work on it a month, a year, five years from now.
Consider Doom. Since the source was released, a lot of the efforts to improve it -- other than the obvious, like porting it to OpenGL -- have been to remove all the clever optimization hacks, and rewrite all the assembly in C, so that it's portable. And this had to be done in order to port it to architectures other than x86 -- all of which are so ridiculously fast that Doom's performance really doesn't matter.
Doom was released in 1993. In 15 years, which of your optimization hacks -- in assembly or in C -- are going to make it difficult to work with your software? What platforms are you not going to be able to target because you wrote it so low-level? (Think: Doom could probably run as a Java applet in a web browser, but it wasn't written in Java, or in any high-level language that can now target the JVM.) What obscure bugs do you still have because you didn't quite manage your memory as well as you thought?
No, bytecode is not used for compiled code. Wrong again. When java is run on a machine it gets translated into bytecode by the jvm then the jvm executes that instruction set.
Google "Just In Time compilation". Then Google for gcj.
The short answer is: From the application developer's perspective, yes, you are writing for the Java virtual machine. But that's got nothing to do with what actually happens. Sun's JVM dynamically compiles bytecode to native code. GCJ can even statically compile Java bytecode into a native executable, just like C.
And just because I can: No, you're not even right about the JVM translating to bytecode. That's done by the Java compiler.
such as advanced memory managment
Another fallacy -- turns out, for the most part, modern garbage collectors actually outperform manual memory management, and certainly simple reference counting. There are some circumstances where you want to write custom memory management, for performance reasons -- but to choose a language ahead of time for that reason is premature optimization. You can always rewrite that one part of your app in C.
Go look at PHP vs Python benchmarks for hashing and then tell me it dosn't matter when you need a server side script to hash 3k video files.
It doesn't matter. CPU time is cheaper than developer time.
If you need to hash 3k video files, and you happen to have a PHP script ready -- yes, it's going to be slower. So you go to Amazon EC2 and you fire up a bunch of instances -- much cheaper than hiring someone to rewrite it all in Python, and certainly not C.
But the thing is, I can't get paid to use Haskell or Lisp at my job or at any other publicly listed software development job within a hundred miles of my house.
I work with Ruby and Javascript all day -- both more LISP-ish than they get credit for -- and I live within walking distance of work.
Python is very dynamic in a way that's gonna be quite hard to compile.
But not impossible.
Look at LLVM. It runs C. It can statically or dynamically compile bytecode, and the generated executable is comparable to one straight out of gcc -- sometimes faster, because of optimizations which can really only be done at runtime.
I don't know about Python, but I know that a fork of Ruby (Rubinius) has been looking at it. So I absolutely think a dynamic language like Python can be made to run much faster, maybe faster than C.
Oh, and the other languages you mention -- cool, but also quite weird. Given the choice, how many people would really rather write LISP syntax than Python syntax? I like a lot of the ideas of LISP, and I realize that these scripting languages are just catching up, but there's a reason it stands for Lots of Insidious Silly Parentheses.
The ruby-talk list is a mailing list, a newsgroup, and a forum, all at once. I use the mailing list, but there's no reason you have to, and the forum is a much lower barrier of entry.
Analogies are really overused, and one isn't needed. No one is unclear on the original topic,
Apparently, you are, or I wouldn't have used it.
Using the product without paying for it is very similar to having someone build a breadbox for you when you supplied the wood.
Now who's using analogies?
The flaw here is that I didn't ask for them to build the game. They built it on their own, and now they want to be paid for it.
The only difference they need to be concerned about is whether I buy it or not. My point here is to demonstrate that DRM has the opposite effect that they'd like -- DRM is based on the assumption that if the game wasn't DRM'd, I wouldn't pay for it, while if the game was DRM'd, I would.
If that's not the assumption, then we can stop right now, because DRM clearly isn't about piracy.
The real effect here is that if the game is too heavily DRM'd, I will never pay for it, while if the game is less DRM'd, or not DRM'd at all, I might pay for it.
Whether or not I pirate it is really irrelevant to that equation. It's not about what I get, it's about what they get for their effort.
If you want a no-cd crack (for example) on a game you bought, I see no problem in that.
I see two.
First, I shouldn't have to. It's akin to have to break into a car I just bought.
Second, it's illegal, thanks to the DMCA.
you've stolen someone's time and skill which they intended to sell.
I've done nothing to their time, since they have no relationship with me.
If I hired them personally, claimed I'd write them a paycheck, and then didn't, that would be theft of work.
Whether I can take the CD out or not is irrelevent. Shall I now complain that my computer "doesn't work" if I take out the RAM?... Or that my car "doesn't work" if I don't put gas in the tank?
Also irrelevant.
I have owned laptops without builtin optical drives. I can plug it into one and install directly from the CD, no problem. But when I remove the drive -- either unplug the USB, or swap a builtin drive for a battery -- the game absolutely should work.
The game is designed to work with the CD in the drive;
Which is why it's called "defective by design".
That's the same as complaining that you can't drive your car because you don't want to pay the price for filling the tank.
Filling the tank is a physical necessity, not a restriction imposed by the manufacturer.
I hope you can tell the difference.
To extend the analogy, how would you feel if you bought a car which refused to let a woman drive? Or refused to let a man drive? That's not a physical restriction of the car -- in fact, it would take quite a lot of extra effort to impose such a bizarre restriction, and it would take less effort to build a car without such restriction.
And I am sure I would not buy such a car. (Is it "theft" because I left the car sitting there on the lot?)
They're down the money you should have paid.
Or, in short, they're down an imaginary amount of money they assume I would have paid.
If I would never have bought the game, they are effectively down $0.
If wood were free, and someone built two breadboxes, is it ok for you to take one because I've paid for it?
Still missing the point -- it costs double the effort to build two breadboxes out of free wood. It costs significantly less effort to build a second copy of a piece of data.
If they make only half of what they could have, it's entirely plassuable that they are not able to make the amount they want (or need, to recover their costs), and cease to make RA4.
Tragic.
And entirely their problem, not mine.
Again: The effect is exactly the same as if they buil
thus the format they should make a label for is not FLAC.
Correct and irrelevant, yet again.
You're laboring under the assumption that I want FLAC to be the default format for that label. That is incorrect.
I am rejecting the notion that anything should be a default format for that label.
I already pointed out why the label needs to talk about a specific format.
I'll address that, then:
They want to distinguish their offering from that of others by not using DRM.
MP3s can be DRM-encumbered. DRM is not limited to a single format -- nor is there a single codec out there which cannot be made DRM-free.
It may be a good PR scheme, but it is based on a fundamental misunderstanding. It seems very likely that if the focus is on "mp3" and not on, say, "unencumbered", or "compatible", this campaign could easily be hijacked by something which is indeed mp3, but is also heavily DRM-encrusted.
As the point is do become an immensely popular DRM-free digital music format and nothing else: No.
That is not, however, the point of FLAC.
The only other free formats
MP3 isn't free. In either sense of the word, if you're encoding.
And your list is a bit short, if we're including MP3 -- because then we should also include AC3, AAC, WMA, etc.
And this isn't an entirely unheard of proposition. There are at least a few online stores that I buy from which have both MP3 and FLAC. Some also have Vorbis. And they can charge more for FLAC, anyway.
Except we're not talking about a no-cd crack, so this entire thing is irrelevent.
It's called an analogy.
You're rationalizing theft.
1: Not theft. 2: Not my preferred choice.
But when piracy has a better user experience, in every way, than the legitimate problem, something is fucked up. And it's got nothing to do with price.
I don't need to rationalize against spending $50. I subscribe to an MMO, and buy indie games on the side. I've got money to burn. If there was a good, free game I was enjoying, I'd donate to it.
But I refuse to support this kind of asshatry. I will not pay to be screwed.
It doesn't matter, EA only "lost" the sale of $300 worth of product.
They are obviously losing a fair amount more than that, or they wouldn't be issuing press releases about how "relaxed" their "new" DRM is.
Well, I have the game, and it works.
Can you take out the CD and play the game?
If not, then no, it doesn't work. It's missing a crucial feature -- and it's very likely installing dangerous software, like SecuROM.
you've taken someone else's time and effort
So they don't still have their time and effort? They aren't still profiting from said time and effort with you?
but did not pay, when they expected to be paid. That's theft.
First, go look up the definition of "theft". It has nothing to do with "expected to be paid".
And they can expect what they want, doesn't make it so. If you've ever traveled, especially to a third-world country, you'll find plenty of people offering to show you around, or do something for you -- or even doing it without permission (picking up your bags and carrying them into the hotel) -- and then expecting to be paid for it.
Is it "theft" if I refuse, claiming I thought they were just being nice?
Taking your words at face value, no, gaining from someone's time and effort, when they expected to be paid, is not stealing, according to a quick glance in the dictionary. It's not even always dishonest.
Keep in mind, we're doing this for free, and we're each doing what we're doing for our own reasons.
Personally, I have no desire to work with Windows any more than I have to, or to strive to improve the Windows platform. If I had the time and skills to do driver development, I would much rather do it on Linux.
If there was no more driver development work to be done on Linux, or I had a particular need for Windows to work with a particular piece of hardware, I'd consider it.
Think of it from that side -- it's not as though I would oppose the development of Windows drivers. I'm just not willing to put any time into it.
Did you get the appropriate firmware? Broadcom drivers won't work unless you rip the firmware out of the Windows driver and install it in the appropriate places.
apt-get install b43-fwcutter
If that fails, what about ndiswrapper?
For the record, Broadcom is about the only wireless I have problems with on Linux, if the above qualifies as "problems". Most other things work out of the box, better than they do on Windows.
Take away IE and Active X and half the reason to use Windows goes away.
Legacy apps. DirectX. DRM'd-but-still-interesting things, like NetFlix.
And the absurdly huge vicious cycle of user base -> developer base -> application base -> user base.
If IE and ActiveX were the only reasons to use Linux, well, they work under Wine, and they usually aren't demanding enough for a virtual machine to be a problem either.
At least the raw device is slightly protected from Windows by the standard.
That's one of the things that bothers me most about how this is done right now.
I'm using a solid state drive that seems to be SATA, which means I get simple linear blocks and hardware wear-leveling -- extra cost in the device, and I can't use JFFS2.
Slashdot Mirror
Well, there's a whole new set of things you'd have to check to make sure they don't already exist.
And I don't think they all have the same kick, either.
The other strange part is the *monkey names -- I know of seamonkey, spidermonkey, and tracemonkey. I have no idea where "monkey" came from.
Which has what to do with "faster" and "easier"?
For that matter, none of my computers have a Blu-Ray drive, or an HD-DVD drive. An h.264 rip, 720p, at around 4 gigs, still looks much better than the DVD.
it seems the easy way to make sure keys are legit would be to go back to the old USB dongle trick.
Won't work. USB dongles have pretty much the same flaws as any other kind of DRM. That is, find this code:
And replace it with this:
So many other places to do the same thing.
Worst case, it does some sort of crypto inside the key -- which means it's still decrypted in RAM, and you can always convince the key you're legit and get it to decrypt the game for you.
The only solutions involve Trusted Computing, which is a rather large step towards simply being another console.
LOWER YOUR DAMN PRICES YOU GREEDY BASTARDS!!!!
SecuROM is insecure at any price.
I've got plenty of cash to spend on games. I don't, because I like playing the games, not playing the Windows admin cleaning up after a bunch of spyware^Wdrm.
The second iteration was actually probably the better, branding-wise.
They were all set -- Firebird for web, Thunderbird for email, Sunbird for calendar -- even things like Songbird for music. I think there were even logos.
Some properties are just much harder to make efficient, because it's hard to give guaranties on behaviour, while it perhaps wouldn't be so hard if the specification would be slightly different.
While true, I think that sometimes the changes aren't too bad.
And you don't need guarantees to optimize -- just educated guesses. You always keep enough around so that if your guess is wrong, you can drop the optimization and start over.
eval is never going to be fast, in any language, and you can make a lot of assumptions by ignoring it. But being able to eval when you really want to, even if it's a performance hit, is a beautiful thing.
I know eval is generally bad practice outside of an interpreter shell. It's a good example, though, because the things we really care about (define_method, method_missing, etc) are all somewhat less dynamic (and less troublesome) than eval. And if eval works, you can probably add any of those that are missing.
'maybe faster than C' is just wild speculation on your part. Lots of high-level languages try to be faster than C. It ain't easy.
Enough of them get close that I start to think the main factor is the amount more research that goes into improving C speed, both by compiler experts and by actual hardware manufacturers.
And I must say I just love your stab at Lisp.
I can't take credit, that's an old one. Probably as old as Pathologically Eclectic Rubbage Lister, which is actually official.
Surely that's the thing God used to create the universe.
You'd think so...
Bringing forward syntax as an argument is extremely silly in my view.
Actually, I've discovered this is a central point, and sometimes more important than actual power.
Code is communication. With your peers, perhaps with you a month from now, even with the machine itself. It is a way to translate your intent into actual instructions so unambiguous a machine can follow them.
This has implications for all three of those parties. Speaking to others is important, because there's only so much you can do by yourself. Speaking to yourself a month from now is important, because there's only so much you can do while keeping the whole program in your head -- I would argue that readability is almost more important than how easily you can write code.
And it even matters for the machine -- because if you've managed to write a program which codifies only your intent, and nothing more -- which says much more about what you want done than how you want it done -- then that "how" can change, based on whatever is more efficient for the circumstance at hand.
It's true that a powerful-but-ugly language can do all of the above, provided everyone can read it well. What's important is how well it maps onto how you think, and how you actually communicate. Ruby, to me, is very readable and very natural -- I can express myself well in it, and when I read a chunk of Ruby, I actually understand what it does, even if I don't quite understand how.
The same cannot be said of most Lisp. I read a block of incredibly beautiful lisp, but it's only beautiful once I get it. And that takes awhile. It's like a Koan -- it certainly expands my mind, probably makes me a better programmer. But not for everyday use -- I don't want to try to use a Koan to order dinner. ("May I take your order?", "Give me the taste of a sugarless marshmallow.")
That, and... c'mon. Take a lesson from python and make at least some of those parens implicit.
No, you're just throwing up a strawman argument.
And you didn't address the actual argument there.
Or do you complain that you shouldn't NEED a key to drive away in the car you just purchased?
A key, yes. A key is a minor inconvenience, and doesn't restrict me from anything, so long as I don't lose it. Moreover, a key provides added value, in that it prevents someone from stealing my car -- note that this would, in fact, deprive me of my car, and not the manufacturer of some imaginary amount of money.
Irrelvent; I never asked anyone to build a breadbox either, but there's still lots of them around.
And no one calls me a thief for not paying for them. I simply don't take them.
I suspect that no one would call me a thief, either, for taking a photograph of one, going out and buying the wood, and assembling my own.
There are a suprising number of people that wouldn't pay for the game. No, I'm not claiming DRM will stop people.. it may stop some though.
Unlikely that it will stop a significant number. It might be interesting to compare it to the number of people who have stopped buying PC games altogether because of DRM.
Of course, no one would bother with DRM if games actually weren't being pirated to begin with. This is a case where a (hopefully) minority of people ruined it for everyone.
It's a case study where no one is right. Considering how little effect DRM actually has on piracy (possibly a net negative effect, as I am an example of)... What is the excuse for a publisher to do this?
It's a bit like trying to counter shoplifting with severe penalties for wearing trenchcoats or carrying any unauthorized bags. The shoplifters will find another way, and in the meantime, you've managed to inconvenience a large portion of the population.
Consider that shoplifting is actually stealing, and I still don't consider ridiculous security measures to be justified.
Sure it is; by pirating, you re-enforce the idea that people would rather steal their work than buy it.
Maybe.
Or maybe I reinforce the idea that people don't want to deal with DRM.
How many actual studies have been done on this issue? How many hard statistics do we have? At this point, it's all speculation, which means I have to lean in favor of not treating your paying customers like criminals.
Oh wait, you're talking about secureROM. In that case, you bought a car and don't like the anti-lock brake system it came with.
Except that SecuROM doesn't just cause problems for itself. It causes problems for the rest of the system, too, and has for quite awhile. People's CD writers stop working, or their drives disappear entirely. The game insists that they uninstall certain other software, which is a bit unreasonable -- like your car refusing to be in the same garage with a truck.
And regardless, it is not uninstalled when the game is, even if said game was only a demo.
So as long as we're playing with analogies, this is a bit more like trying to test-drive a car, and it (painfully) brands a permanent barcode on your arm (which stings in the winter, and is possibly carcinogenic), refuses to start within a hundred feet of your SUV, and every now and then, when you're wearing the wrong clothes, it decides you're a thief and refuses to start, even if you have the key.
And on top of all that, the manufacturer didn't give you a key. They gave you most of a key. You had to carve the last notch yourself.
You're rationalizing, and you know it.
You don't have any more actual arguments, so you're appealing to emotion. You're good at that, but I'm not biting.
The product was designed a certain way, and part of that design includes relying on SecureRom.
Perhaps garbage collection is better when someone doesn't get memory management... But it is not possible for garbage collection to perform better than a competent engineer.
You'd think so, wouldn't you? But it's not always true.
There are other ways as well -- every malloc and free that you write inline with your code is, well, more code. Which means more cache misses. A garbage collector should fit into cache for the duration of its run, and then be swapped out.
Certainly, it won't always win. And by definition, a human can always do at least as well because a human can at the very least write that garbage collector, and possibly other things on top of it. But if you care about performance, it is something to consider.
That's because C deals with how computers actually think.
It actually really doesn't. Assembly is closer, but still not what's actually going on.
For example yes, pointers are confusing and you can get in to trouble with them. However, that is actually how a processor handles things.
Yes, registers are confusing and you can get in trouble with them. However, that is actually how a processor handles things.
There's a reason you use C, and not assembly. It's the same reason I use Ruby, and not C.
you need to be able to write a program based on how the computer thinks, not on how you do.
When performance is critical, yes.
When it's not -- and it's usually not -- it's infinitely more important to have a program structured well enough that you can work on it a month, a year, five years from now.
Consider Doom. Since the source was released, a lot of the efforts to improve it -- other than the obvious, like porting it to OpenGL -- have been to remove all the clever optimization hacks, and rewrite all the assembly in C, so that it's portable. And this had to be done in order to port it to architectures other than x86 -- all of which are so ridiculously fast that Doom's performance really doesn't matter.
Doom was released in 1993. In 15 years, which of your optimization hacks -- in assembly or in C -- are going to make it difficult to work with your software? What platforms are you not going to be able to target because you wrote it so low-level? (Think: Doom could probably run as a Java applet in a web browser, but it wasn't written in Java, or in any high-level language that can now target the JVM.) What obscure bugs do you still have because you didn't quite manage your memory as well as you thought?
No, bytecode is not used for compiled code. Wrong again. When java is run on a machine it gets translated into bytecode by the jvm then the jvm executes that instruction set.
Google "Just In Time compilation". Then Google for gcj.
The short answer is: From the application developer's perspective, yes, you are writing for the Java virtual machine. But that's got nothing to do with what actually happens. Sun's JVM dynamically compiles bytecode to native code. GCJ can even statically compile Java bytecode into a native executable, just like C.
And just because I can: No, you're not even right about the JVM translating to bytecode. That's done by the Java compiler.
such as advanced memory managment
Another fallacy -- turns out, for the most part, modern garbage collectors actually outperform manual memory management, and certainly simple reference counting. There are some circumstances where you want to write custom memory management, for performance reasons -- but to choose a language ahead of time for that reason is premature optimization. You can always rewrite that one part of your app in C.
Go look at PHP vs Python benchmarks for hashing and then tell me it dosn't matter when you need a server side script to hash 3k video files.
It doesn't matter. CPU time is cheaper than developer time.
If you need to hash 3k video files, and you happen to have a PHP script ready -- yes, it's going to be slower. So you go to Amazon EC2 and you fire up a bunch of instances -- much cheaper than hiring someone to rewrite it all in Python, and certainly not C.
But the thing is, I can't get paid to use Haskell or Lisp at my job or at any other publicly listed software development job within a hundred miles of my house.
I work with Ruby and Javascript all day -- both more LISP-ish than they get credit for -- and I live within walking distance of work.
Python is very dynamic in a way that's gonna be quite hard to compile.
But not impossible.
Look at LLVM. It runs C. It can statically or dynamically compile bytecode, and the generated executable is comparable to one straight out of gcc -- sometimes faster, because of optimizations which can really only be done at runtime.
I don't know about Python, but I know that a fork of Ruby (Rubinius) has been looking at it. So I absolutely think a dynamic language like Python can be made to run much faster, maybe faster than C.
Oh, and the other languages you mention -- cool, but also quite weird. Given the choice, how many people would really rather write LISP syntax than Python syntax? I like a lot of the ideas of LISP, and I realize that these scripting languages are just catching up, but there's a reason it stands for Lots of Insidious Silly Parentheses.
Why limit yourself, though?
The ruby-talk list is a mailing list, a newsgroup, and a forum, all at once. I use the mailing list, but there's no reason you have to, and the forum is a much lower barrier of entry.
Analogies are really overused, and one isn't needed. No one is unclear on the original topic,
Apparently, you are, or I wouldn't have used it.
Using the product without paying for it is very similar to having someone build a breadbox for you when you supplied the wood.
Now who's using analogies?
The flaw here is that I didn't ask for them to build the game. They built it on their own, and now they want to be paid for it.
The only difference they need to be concerned about is whether I buy it or not. My point here is to demonstrate that DRM has the opposite effect that they'd like -- DRM is based on the assumption that if the game wasn't DRM'd, I wouldn't pay for it, while if the game was DRM'd, I would.
If that's not the assumption, then we can stop right now, because DRM clearly isn't about piracy.
The real effect here is that if the game is too heavily DRM'd, I will never pay for it, while if the game is less DRM'd, or not DRM'd at all, I might pay for it.
Whether or not I pirate it is really irrelevant to that equation. It's not about what I get, it's about what they get for their effort.
If you want a no-cd crack (for example) on a game you bought, I see no problem in that.
I see two.
First, I shouldn't have to. It's akin to have to break into a car I just bought.
Second, it's illegal, thanks to the DMCA.
you've stolen someone's time and skill which they intended to sell.
I've done nothing to their time, since they have no relationship with me.
If I hired them personally, claimed I'd write them a paycheck, and then didn't, that would be theft of work.
Whether I can take the CD out or not is irrelevent. Shall I now complain that my computer "doesn't work" if I take out the RAM?... Or that my car "doesn't work" if I don't put gas in the tank?
Also irrelevant.
I have owned laptops without builtin optical drives. I can plug it into one and install directly from the CD, no problem. But when I remove the drive -- either unplug the USB, or swap a builtin drive for a battery -- the game absolutely should work.
The game is designed to work with the CD in the drive;
Which is why it's called "defective by design".
That's the same as complaining that you can't drive your car because you don't want to pay the price for filling the tank.
Filling the tank is a physical necessity, not a restriction imposed by the manufacturer.
I hope you can tell the difference.
To extend the analogy, how would you feel if you bought a car which refused to let a woman drive? Or refused to let a man drive? That's not a physical restriction of the car -- in fact, it would take quite a lot of extra effort to impose such a bizarre restriction, and it would take less effort to build a car without such restriction.
And I am sure I would not buy such a car. (Is it "theft" because I left the car sitting there on the lot?)
They're down the money you should have paid.
Or, in short, they're down an imaginary amount of money they assume I would have paid.
If I would never have bought the game, they are effectively down $0.
If wood were free, and someone built two breadboxes, is it ok for you to take one because I've paid for it?
Still missing the point -- it costs double the effort to build two breadboxes out of free wood. It costs significantly less effort to build a second copy of a piece of data.
If they make only half of what they could have, it's entirely plassuable that they are not able to make the amount they want (or need, to recover their costs), and cease to make RA4.
Tragic.
And entirely their problem, not mine.
Again: The effect is exactly the same as if they buil
To pretend that you do not copy is to adopt the twisted hypocrisy of the Victorians who swore that they never, ever masturbated.
He's earned that cape.
thus the format they should make a label for is not FLAC.
Correct and irrelevant, yet again.
You're laboring under the assumption that I want FLAC to be the default format for that label. That is incorrect.
I am rejecting the notion that anything should be a default format for that label.
I already pointed out why the label needs to talk about a specific format.
I'll address that, then:
They want to distinguish their offering from that of others by not using DRM.
MP3s can be DRM-encumbered. DRM is not limited to a single format -- nor is there a single codec out there which cannot be made DRM-free.
It may be a good PR scheme, but it is based on a fundamental misunderstanding. It seems very likely that if the focus is on "mp3" and not on, say, "unencumbered", or "compatible", this campaign could easily be hijacked by something which is indeed mp3, but is also heavily DRM-encrusted.
Fine if you only have one or two, but if you have hundreds then it's far too long a wait.
Hmm. Do these players not also support syncing? As in, only convert/transfer new music?
How often do you have hundreds of new tracks to transfer all at once?
As the point is do become an immensely popular DRM-free digital music format and nothing else: No.
That is not, however, the point of FLAC.
The only other free formats
MP3 isn't free. In either sense of the word, if you're encoding.
And your list is a bit short, if we're including MP3 -- because then we should also include AC3, AAC, WMA, etc.
And this isn't an entirely unheard of proposition. There are at least a few online stores that I buy from which have both MP3 and FLAC. Some also have Vorbis. And they can charge more for FLAC, anyway.
Except we're not talking about a no-cd crack, so this entire thing is irrelevent.
It's called an analogy.
You're rationalizing theft.
1: Not theft.
2: Not my preferred choice.
But when piracy has a better user experience, in every way, than the legitimate problem, something is fucked up. And it's got nothing to do with price.
I don't need to rationalize against spending $50. I subscribe to an MMO, and buy indie games on the side. I've got money to burn. If there was a good, free game I was enjoying, I'd donate to it.
But I refuse to support this kind of asshatry. I will not pay to be screwed.
It doesn't matter, EA only "lost" the sale of $300 worth of product.
They are obviously losing a fair amount more than that, or they wouldn't be issuing press releases about how "relaxed" their "new" DRM is.
Well, I have the game, and it works.
Can you take out the CD and play the game?
If not, then no, it doesn't work. It's missing a crucial feature -- and it's very likely installing dangerous software, like SecuROM.
you've taken someone else's time and effort
So they don't still have their time and effort? They aren't still profiting from said time and effort with you?
but did not pay, when they expected to be paid. That's theft.
First, go look up the definition of "theft". It has nothing to do with "expected to be paid".
And they can expect what they want, doesn't make it so. If you've ever traveled, especially to a third-world country, you'll find plenty of people offering to show you around, or do something for you -- or even doing it without permission (picking up your bags and carrying them into the hotel) -- and then expecting to be paid for it.
Is it "theft" if I refuse, claiming I thought they were just being nice?
Taking your words at face value, no, gaining from someone's time and effort, when they expected to be paid, is not stealing, according to a quick glance in the dictionary. It's not even always dishonest.
Pretty much both.
Keep in mind, we're doing this for free, and we're each doing what we're doing for our own reasons.
Personally, I have no desire to work with Windows any more than I have to, or to strive to improve the Windows platform. If I had the time and skills to do driver development, I would much rather do it on Linux.
If there was no more driver development work to be done on Linux, or I had a particular need for Windows to work with a particular piece of hardware, I'd consider it.
Think of it from that side -- it's not as though I would oppose the development of Windows drivers. I'm just not willing to put any time into it.
Did you get the appropriate firmware? Broadcom drivers won't work unless you rip the firmware out of the Windows driver and install it in the appropriate places.
apt-get install b43-fwcutter
If that fails, what about ndiswrapper?
For the record, Broadcom is about the only wireless I have problems with on Linux, if the above qualifies as "problems". Most other things work out of the box, better than they do on Windows.
...GAH!
If IE and ActiveX were the only reasons to use Windows...
Take away IE and Active X and half the reason to use Windows goes away.
Legacy apps. DirectX. DRM'd-but-still-interesting things, like NetFlix.
And the absurdly huge vicious cycle of user base -> developer base -> application base -> user base.
If IE and ActiveX were the only reasons to use Linux, well, they work under Wine, and they usually aren't demanding enough for a virtual machine to be a problem either.
The problem is how.
Open source makes this much more difficult.
It's happened in the past -- in certain benchmarks, OS X was pitifully slow on a G4 vs Linux on the same machine.
At least the raw device is slightly protected from Windows by the standard.
That's one of the things that bothers me most about how this is done right now.
I'm using a solid state drive that seems to be SATA, which means I get simple linear blocks and hardware wear-leveling -- extra cost in the device, and I can't use JFFS2.
All so Windows doesn't have to adapt.