Re:Self-inflicted piracy, or Why I would use Chips
on
Sony vs Modchips
·
· Score: 1
They have every right to charge whatever they want in whatever region they want.
Well, no, they are not. More importantly, however, they are not free to limit arbitrarily how you trade in their products. I suspect you'll sooner or later see practices like Sony's be challenged under free trade agreements.
Seems more like nerd complaining than an actual rights issue.
You are quite right: it's not a "rights" issue. So why do you bring up the issue of "rights"?
If you go to the NanoBusiness web site and look at what they promise, it has nothing to do with "nanotechnology". Sensors, carbon nanotubes, microscopes, etc. belong to the established disciplines of material science, chemistry, biology, polymer science, molecular biology, micromechanical systems, and many other established areas of research and technology.
Nanotechnology is distinguished from these existing fields by promising molecular assemblers, self-replicating machines, and all that. Making carbon "nano"-tubes or buckyballs from soot and getting them to stick together in particular ways in bulk is not nanotechnology, it's still (bulk) chemistry. Nanotechnology has failed completely to deliver on those promises so far, and it doesn't look like it will deliver any time soon.
Rebranding the successes of other disciplines as successes of "nanotechnology" seems rather dishonest to me. Given that these people are now going to Capitol Hill with outstretched hands, it seems like the same thing we had with "e-this" and "i-that" over the last few years. Since this silliness cannot be stopped, let's hope the traditional disciplines will wise up quickly and put a "nano" into their names temporarily so that there is a level playing field.
No, [nanotechnology is] materials, electronics, and biochemistry, all of which have started to be affected by nanotechnology now.
They haven't "started to be affected by nanotechnology" at all. What has happened is that these areas that have traditionally been working on an atomic scale have simply been claimed by nanotechnology after nanotechnology failed to deliver what it promised. It's a smart but cynical publicity move.
Nanotechnology continues to be vaporware, failing to deliver on any of the promises that Drexler and other people made for it. The harm that these people will do to established disciplines remains to be seen, as less qualified, buzz-word spewing people get new funding and investments.
At $500 in Japan, Sony was probably making a reasonable profit. So, even all things being equal, it's quite likely that selling at $299 in the US after the fall of the yen was still not selling at a loss. More importantly, component costs had likely come down significantly between the Japanese and US releases, giving Sony even more room to adjust prices for the US market.
The development costs of the PS2 may have been high, but in terms of actual cost of putting the thing together, I doubt it's a lot more than a good consumer DVD player at this point. I would bet that Sony is now making a reasonable profit on every unit sold, although one can't prove it either way.
profit or loss on the console doesn't matter
on
Sony vs Modchips
·
· Score: 2
Let me add to that: people debate at length whether Sony makes a profit or loss on the units. It doesn't matter: unit sales of the console are what Sony is after to attract both more real buyers and more game authors.
If you don't like it or if you don't like the company, don't buy it. That goes for PS2 as much as Xbox. Technically and financially, I think you are better off with a PC anyway: better picture, more expandability, upgradability, etc.
Re:Not about Region coding or 'personal backups'
on
Sony vs Modchips
·
· Score: 3, Interesting
How do you know? And what does it matter? It's copyrighted material, and under fair use provisions, people used to have the right to copy the CD/DVD for personal use. Copyright implies rights not only for the author but also for the public.
Re:Self-inflicted piracy, or Why I would use Chips
on
Sony vs Modchips
·
· Score: 2
That was technial incompatibility between competing companies. DVD region coding and restrictions on games are deliberate incompatibilities created by a single vendor to permit charging different prices in different regions.
This is exactly the sort of thing that shouldn't happen in a free globalized market. Let's hope the WTO has some teeth to it and charges Sony and other companies with illegal trade practices.
This just keeps happening--the Vogon interstellar starliners keep illegally flushing their toilets into space in the vicinity of solar systems. I think we should file a complaint with the local authorities on Alpha Centauri.
First of all, upper bounds like O(n^5) don't tell you at all whether a problem is hard or an algorithm is slow--it might still run in linear time in all cases.
If you mean a worst case lower bound o(n^5), that still only tells you that some problem instances may be harder. But finding such problem instances may itself be hard, so it doesn't necessarily help you with cryptography. And worst-case lower bounds still tell you little about the existence of good practical algorithms, like randomized algorithms.
Worst case upper bounds are good only for one thing: to prove that a problem is easy. They are useless for proving that a problem is hard.
Far from it. You yourself gave an example: chess. P=NP is irrelevant to chess. Chess is played on an 8x8 board with 32 pieces. The problem isn't going to get any bigger. If P=NP, that doesn't mean that it would result in an algorithm that is of any interest to chess because current exponential time methods may still be faster in practice. And even if P!=NP, there can still be algorithms that solve chess games fast.
Even for optimization problems that (unlike chess) can scale arbitrarily, P!=NP doesn't mean that there are no good algorithms to solve them fast in any interesting practical sense. Only a positive result, P=NP, would establish that there are algorithms that scale "well" (in the sense of "polynomially") in all cases.
That seems like a simple support call to resolve. Start off by "log in as 'administrator' and...". If they say "I can't do that", you point them at your configuration web page, tell them to tell their administrator to fix it, and end the support call. Takes less than a minute and would cost you almost nothing. That's no reason to impose draconian contractual terms.
It used to be very common to patch "vectors" in the BIOS and other parts of the operating system in order to replace system-supplied functions with user-supplied ones. A patent claim on this is, of course, ridiculous--it's a standard technique, widely used for just these kinds purposes. However, that might not keep the patent from causing lots of problems.
It may be easier to work around this claim. You may be able to implement roughly the same thing using the analogue of LD_PRELOAD--instead of patching the existing DLL, arrange for the linker to preload a DLL that overrides some functions. That may work even on Windows.
(The link you gave isn't working. Did the company give you the patent number?)
Instead of spending billions of dollars on some "loony" scheme like that, you are better off putting solar generators into deserts and storing and transporting the resulting energy as hydrogen (or feed it directly into the grid if you like). That can be done with today's technology, and it can be done incrementally. And you are much better off making sure that our energy needs don't "rocket".
It's kind of interesting to see how solar energy is considered some oddball tree-hugging thing when proposed on earth, but if it involves huge industrial and technological expenses and high-energy space lasers/masers, it is all of a sudden acceptable to a crowd of people that would otherwise don't give it a second look.
Re:This is a weapon of massless destruction
on
Lunar Lasers
·
· Score: 2
Is this some kind of new math? You still need the solar collectors on the moon, and while they may operate a little more efficiently there, they also cost a lot more on the moon.
O(n^d), where d is a constant integer. If d > 3, the solution would be practically infeasible anyway.
As is common, you are overestimating the significance of worst-case complexity, and you are assuming that "n" can get arbitrarily large. In the real world, "n" is often bounded by constraints in the real-world, and algorithms have much better average case complexities than their worst case complexities. I routinely solve problems whose worst-case complexity is O(n^8).
If you can get a good asymptotic bound for an algorithm, that tells you something useful: the algorithm will have a good asymptotic complexity also for the problems you encounter in practice. A bad asymptotic worst-case upper bound tells you almost nothing: the algorithm may still run fast on almost all cases, or it may run fast on those cases you encounter in practice. Not even a bad asymptotic worst-case lower bound tells you much, for the same reason.
Furthermore, for real problems, "N" often corresponds to real-world objects and doesn't get arbitrarily large, so the relevance of asymptotic results breaks down at some point: algorithms with worse asymptotic complexity may perform better in practice on all problems you would be interested in. This is probably rather the norm than the exception, although people often don't realize it.
So, if P=NP, that would tell you that a large number of problems don't necessarily require exponential time to solve in the worst case. But that doesn't make such problems easy. Conversely, many problems that are NP-hard have, in fact, good, practical solutions in many cases no matter whether P=NP or not (as some cryptographers had to discover to their dismay).
We only care about the large cases for the most part.
That's wrong on several counts. First, the worst case performance of an algorithm may not matter at all because the worst case is rare or because good randomized versions are available. Second, the constants on the asymptotically more efficient algorithm may be so much worse that it doesn't matter for problem sizes that occur in practice. You see, "N" isn't usually some kind of bragging factor, it corresponds to real-world entities, like people, components, cars, etc., of which there is a bounded number.
While occasionally theoretically interesting, many recently developed algorithms for solving common problems with slightly better asymptotic worst-case complexity are completely useless in practice.
C# is in no way more efficient then C++ compiled to machine code
Neither C# nor Java are usually more efficient for "inner loops" than carefully crafted C++, but they are also not significantly slower. In some areas, C# and Java actually offer compilers significant opportunities for optimization that don't exist in C/C++ (method inlining from dynamically loaded code, aliasing, a few others).
Where C# and Java are a lot more efficient is component based software: C and C++ lack support for component based software, and that's why people use inefficient and cumbersome workarounds like COM, DCOM, CORBA, RPC, etc. In C# and Java, software components can be just objects, they life safely side-by-side in the same process, and they can call each other and access each other very efficiently. That's the efficiency that matters for desktop applications.
However one of the underlying principles of this is that it should free you from the constraints of programming languages - if one part of your system is written in C, another in Perl, and yet another in java, so what? As long as they can all communicate it makes no difference.
While RPC and object brokers are all the rage, they impose very high overhead compared to a direct method call, and they require a lot of effort on the behalf of programmers to use. And they also limit functionality in what data you can pass and how you can pass it.
With a runtime like the JVM or CLR, you can safely run many software components within the same runtime, and they can pass data structures to each other very efficiently and without any constraints. This doesn't have to be all in one language (both the JVM and the CLR support multiple languages). However, it can't be in C or C++ because C or C++ just cannot guarantee runtime safety efficiently. And Java and C#, using the full, native object models of their runtimes, still have a slight edge even over high-quality implementations of other languages on top of the same runtime. So, that's the degree to which languages matter.
I'm glad to see that there are open source projects based on a language and runtime that supports a component architecture and runtime safety from the ground up. I think a Linux desktop environment and services platform based on C#/CLR will be so much better, more efficient, and more robust than the current systems based on plain C or C++. This has long been overdue.
What I am disappointed about is that the Linux community could have started on this several years ago. While there are some cosmetic differences between C#/CLR and Java/JVM, the object models and performance of the two languages and runtimes are essentially the same. And there actually are already several open source, high performance Java implementations already.
Even today, I think it still makes more sense to use something like GNU gcj or Intel's Open Runtime and maybe the existing native Gnome widgets (for which there are already Java bindings). But Mono is obviously not going to go that route. Too bad.
Many people say that, but unless you included your full name in the 'From' field and you have a remarkably uncommon name, those 20 year old posts will never be seen by any HR guys.
I have a remarkably uncommon name. In fact, if you search for my last name on USENET, almost all the posts you see will be by me or will quote something by me. So, what do I do now? I participated in those discussions in good faith with the understanding that these were temporary discussion groups. Even though I have never posted a flame, I don't think Google has the right to drag them up 20 years later.
None of which compares to its Windows counterpart in stability, functionality or ease of use.
Actually, a lot of the music software for platforms like Linux is more powerful than what you get on Windows. It simply caters to a completely different crowed.
Many of these projects were started to provide a *Nix replacement for an existing product (whether Mac or Windows).
Not at all. Much of the non-commercial music software comes out of research projects.
Again, the time and effort required to migrate to a new platform outweighs the advantages gained (especially if the new tools i have to look forward to are just one offs of the ones I currently use)
As I was saying: open source neither aims nor functions to maximize the number of random users on open source platforms. In different words, if you won't contribute, nobody really cares whether you use open source or not.
would not know where to begin to create his own solution. Just because a person uses a software solution in his/her work does not mean that they have the means or skills to write their own software. Because the Linux/OSS community is generally comprised of people whose job it is to write software/know computers inside and out, they forget that not all of us have the skills to do the same.
I don't forget that at all. I'm just saying that free software doesn't fall from the sky. If you don't get the free software you like on Linux, it's not because Linux developers are too nerdy to recognize your needs, it's because they have no interest in fulfilling everybody's needs for free. When you get free software, it's because someone is developing something for their own needs and sharing the results freely.
Until someone with the proper skill set (music/software) creates the OSS, users like myself must rely on Windows audio software which is normally not cheap but usually is good enough and extensible.
Yes, that's the way the real world works, and open source or free software doesn't change that.
You do have lots of options, however. You could get together with other musicians and pay someone to develop the software for you. That might be expensive in the short term, but in the long run, it's cheaper because you get the features you want and don't pay for every upgrade.
You could learn programming yourself like lots of other professionals have done. It's not hard. Really.
Or you could figure out how the existing music software on Linux works (of which there is actually quite a bit).
Apparently, the concept of writing a device driver without patching the kernel is still impossible even though Windows/Mac have been doing it for many years.
Linux has had dynamically loadable kernel modules since before MacOS even had a kernel. Your standard distribution comes with lots of them; use "modprobe" to insert them. Even third party device drivers almost never require "patching" the kernel, but merely are compiled separately and then dynamically loaded. Device drivers can be compiled and loaded/unloaded on a running system.
I'm a developer, so I'm thinking of writing support for some of these things (such as an easy VPN installer). Or, maybe a universal driver installer that would automagically patch the kernel and say 'You must reboot now', ala Windows.
Please don't. It's pretty clear that you don't know all that much about Linux. You can bet that most of the "problems" you think are there already have perfectly good solutions. Like any other system, it takes a while to figure them out.
Alot of the problems in Windows can be attributed to Microsoft trying to be backwards-compatible. But with Linux, the kernel and major libraries (ie. glibc) are always changing underneath your feet.
You've got to be kidding. Linux has had a stable, fully documented system API since its beginning, an API that is compatible with numerous other UNIX implementations. I can run code from 10 or 20 years ago on my Linux machine with no problems, taking full advantage of the more powerful processors and memory.
Long-term stability of APIs is one of the big advantages of Linux over Windows.
I work in an electronic music studio. I'd love to use Linux, but the apps just aren't there. The fact that there's almost no development community addressing this potentially enormous market amazes me to no end.
Well, ask yourself: why aren't you developing the open source software you want? That will probably tell you why others in your community aren't working on it either. Most open source software comes about because end users with a specific problem can't find a good/affordable commercial solution and write their own. Then, they share the results with the community.
If the Windows software you are using is cheap enough, good enough, and extensible enough, then there is no need for open source software and you'd be foolish to switch. If, on the other hand, it leaves something to be desired, well, get going and write something better yourself and share it.
Slashdot Mirror
Well, no, they are not. More importantly, however, they are not free to limit arbitrarily how you trade in their products. I suspect you'll sooner or later see practices like Sony's be challenged under free trade agreements.
Seems more like nerd complaining than an actual rights issue.
You are quite right: it's not a "rights" issue. So why do you bring up the issue of "rights"?
Nanotechnology is distinguished from these existing fields by promising molecular assemblers, self-replicating machines, and all that. Making carbon "nano"-tubes or buckyballs from soot and getting them to stick together in particular ways in bulk is not nanotechnology, it's still (bulk) chemistry. Nanotechnology has failed completely to deliver on those promises so far, and it doesn't look like it will deliver any time soon.
Rebranding the successes of other disciplines as successes of "nanotechnology" seems rather dishonest to me. Given that these people are now going to Capitol Hill with outstretched hands, it seems like the same thing we had with "e-this" and "i-that" over the last few years. Since this silliness cannot be stopped, let's hope the traditional disciplines will wise up quickly and put a "nano" into their names temporarily so that there is a level playing field.
They haven't "started to be affected by nanotechnology" at all. What has happened is that these areas that have traditionally been working on an atomic scale have simply been claimed by nanotechnology after nanotechnology failed to deliver what it promised. It's a smart but cynical publicity move.
Nanotechnology continues to be vaporware, failing to deliver on any of the promises that Drexler and other people made for it. The harm that these people will do to established disciplines remains to be seen, as less qualified, buzz-word spewing people get new funding and investments.
The development costs of the PS2 may have been high, but in terms of actual cost of putting the thing together, I doubt it's a lot more than a good consumer DVD player at this point. I would bet that Sony is now making a reasonable profit on every unit sold, although one can't prove it either way.
If you don't like it or if you don't like the company, don't buy it. That goes for PS2 as much as Xbox. Technically and financially, I think you are better off with a PC anyway: better picture, more expandability, upgradability, etc.
How do you know? And what does it matter? It's copyrighted material, and under fair use provisions, people used to have the right to copy the CD/DVD for personal use. Copyright implies rights not only for the author but also for the public.
This is exactly the sort of thing that shouldn't happen in a free globalized market. Let's hope the WTO has some teeth to it and charges Sony and other companies with illegal trade practices.
This just keeps happening--the Vogon interstellar starliners keep illegally flushing their toilets into space in the vicinity of solar systems. I think we should file a complaint with the local authorities on Alpha Centauri.
Worst case upper bounds are good only for one thing: to prove that a problem is easy. They are useless for proving that a problem is hard.
Even for optimization problems that (unlike chess) can scale arbitrarily, P!=NP doesn't mean that there are no good algorithms to solve them fast in any interesting practical sense. Only a positive result, P=NP, would establish that there are algorithms that scale "well" (in the sense of "polynomially") in all cases.
That seems like a simple support call to resolve. Start off by "log in as 'administrator' and ...". If they say "I can't do that", you point them at your configuration web page, tell them to tell their administrator to fix it, and end the support call. Takes less than a minute and would cost you almost nothing. That's no reason to impose draconian contractual terms.
It may be easier to work around this claim. You may be able to implement roughly the same thing using the analogue of LD_PRELOAD--instead of patching the existing DLL, arrange for the linker to preload a DLL that overrides some functions. That may work even on Windows.
(The link you gave isn't working. Did the company give you the patent number?)
It's kind of interesting to see how solar energy is considered some oddball tree-hugging thing when proposed on earth, but if it involves huge industrial and technological expenses and high-energy space lasers/masers, it is all of a sudden acceptable to a crowd of people that would otherwise don't give it a second look.
Is this some kind of new math? You still need the solar collectors on the moon, and while they may operate a little more efficiently there, they also cost a lot more on the moon.
As is common, you are overestimating the significance of worst-case complexity, and you are assuming that "n" can get arbitrarily large. In the real world, "n" is often bounded by constraints in the real-world, and algorithms have much better average case complexities than their worst case complexities. I routinely solve problems whose worst-case complexity is O(n^8).
Furthermore, for real problems, "N" often corresponds to real-world objects and doesn't get arbitrarily large, so the relevance of asymptotic results breaks down at some point: algorithms with worse asymptotic complexity may perform better in practice on all problems you would be interested in. This is probably rather the norm than the exception, although people often don't realize it.
So, if P=NP, that would tell you that a large number of problems don't necessarily require exponential time to solve in the worst case. But that doesn't make such problems easy. Conversely, many problems that are NP-hard have, in fact, good, practical solutions in many cases no matter whether P=NP or not (as some cryptographers had to discover to their dismay).
That's wrong on several counts. First, the worst case performance of an algorithm may not matter at all because the worst case is rare or because good randomized versions are available. Second, the constants on the asymptotically more efficient algorithm may be so much worse that it doesn't matter for problem sizes that occur in practice. You see, "N" isn't usually some kind of bragging factor, it corresponds to real-world entities, like people, components, cars, etc., of which there is a bounded number.
While occasionally theoretically interesting, many recently developed algorithms for solving common problems with slightly better asymptotic worst-case complexity are completely useless in practice.
Neither C# nor Java are usually more efficient for "inner loops" than carefully crafted C++, but they are also not significantly slower. In some areas, C# and Java actually offer compilers significant opportunities for optimization that don't exist in C/C++ (method inlining from dynamically loaded code, aliasing, a few others).
Where C# and Java are a lot more efficient is component based software: C and C++ lack support for component based software, and that's why people use inefficient and cumbersome workarounds like COM, DCOM, CORBA, RPC, etc. In C# and Java, software components can be just objects, they life safely side-by-side in the same process, and they can call each other and access each other very efficiently. That's the efficiency that matters for desktop applications.
While RPC and object brokers are all the rage, they impose very high overhead compared to a direct method call, and they require a lot of effort on the behalf of programmers to use. And they also limit functionality in what data you can pass and how you can pass it.
With a runtime like the JVM or CLR, you can safely run many software components within the same runtime, and they can pass data structures to each other very efficiently and without any constraints. This doesn't have to be all in one language (both the JVM and the CLR support multiple languages). However, it can't be in C or C++ because C or C++ just cannot guarantee runtime safety efficiently. And Java and C#, using the full, native object models of their runtimes, still have a slight edge even over high-quality implementations of other languages on top of the same runtime. So, that's the degree to which languages matter.
What I am disappointed about is that the Linux community could have started on this several years ago. While there are some cosmetic differences between C#/CLR and Java/JVM, the object models and performance of the two languages and runtimes are essentially the same. And there actually are already several open source, high performance Java implementations already.
Even today, I think it still makes more sense to use something like GNU gcj or Intel's Open Runtime and maybe the existing native Gnome widgets (for which there are already Java bindings). But Mono is obviously not going to go that route. Too bad.
I have a remarkably uncommon name. In fact, if you search for my last name on USENET, almost all the posts you see will be by me or will quote something by me. So, what do I do now? I participated in those discussions in good faith with the understanding that these were temporary discussion groups. Even though I have never posted a flame, I don't think Google has the right to drag them up 20 years later.
Actually, a lot of the music software for platforms like Linux is more powerful than what you get on Windows. It simply caters to a completely different crowed.
Many of these projects were started to provide a *Nix replacement for an existing product (whether Mac or Windows).
Not at all. Much of the non-commercial music software comes out of research projects.
Again, the time and effort required to migrate to a new platform outweighs the advantages gained (especially if the new tools i have to look forward to are just one offs of the ones I currently use)
As I was saying: open source neither aims nor functions to maximize the number of random users on open source platforms. In different words, if you won't contribute, nobody really cares whether you use open source or not.
I don't forget that at all. I'm just saying that free software doesn't fall from the sky. If you don't get the free software you like on Linux, it's not because Linux developers are too nerdy to recognize your needs, it's because they have no interest in fulfilling everybody's needs for free. When you get free software, it's because someone is developing something for their own needs and sharing the results freely.
Until someone with the proper skill set (music/software) creates the OSS, users like myself must rely on Windows audio software which is normally not cheap but usually is good enough and extensible.
Yes, that's the way the real world works, and open source or free software doesn't change that.
You do have lots of options, however. You could get together with other musicians and pay someone to develop the software for you. That might be expensive in the short term, but in the long run, it's cheaper because you get the features you want and don't pay for every upgrade.
You could learn programming yourself like lots of other professionals have done. It's not hard. Really.
Or you could figure out how the existing music software on Linux works (of which there is actually quite a bit).
Linux has had dynamically loadable kernel modules since before MacOS even had a kernel. Your standard distribution comes with lots of them; use "modprobe" to insert them. Even third party device drivers almost never require "patching" the kernel, but merely are compiled separately and then dynamically loaded. Device drivers can be compiled and loaded/unloaded on a running system.
I'm a developer, so I'm thinking of writing support for some of these things (such as an easy VPN installer). Or, maybe a universal driver installer that would automagically patch the kernel and say 'You must reboot now', ala Windows.
Please don't. It's pretty clear that you don't know all that much about Linux. You can bet that most of the "problems" you think are there already have perfectly good solutions. Like any other system, it takes a while to figure them out.
Alot of the problems in Windows can be attributed to Microsoft trying to be backwards-compatible. But with Linux, the kernel and major libraries (ie. glibc) are always changing underneath your feet.
You've got to be kidding. Linux has had a stable, fully documented system API since its beginning, an API that is compatible with numerous other UNIX implementations. I can run code from 10 or 20 years ago on my Linux machine with no problems, taking full advantage of the more powerful processors and memory.
Long-term stability of APIs is one of the big advantages of Linux over Windows.
Well, ask yourself: why aren't you developing the open source software you want? That will probably tell you why others in your community aren't working on it either. Most open source software comes about because end users with a specific problem can't find a good/affordable commercial solution and write their own. Then, they share the results with the community.
If the Windows software you are using is cheap enough, good enough, and extensible enough, then there is no need for open source software and you'd be foolish to switch. If, on the other hand, it leaves something to be desired, well, get going and write something better yourself and share it.