Sure. Look at modern games console DRM (PlayStation 3, for example).
Of course, "perfect" DRM is only theoretically possible for things where the experience is unique for each user, like software. For books the best you're gonna get is making it as annoying to pirate as a real paper book. That's probably good enough - short of special cases like student textbooks, I rarely see somebody reading a pirated book. Go down to the beach and I don't see photocopies in use.
Whether anybody has succeeded in making such a DRM I don't know. Is the newest Kindle DRM broken?
It's just playing with words. Saying the goal of copyright is to promote creativity and prodution of useful content is exactly equivalent to saying that the goal of the free market is to encourage the betterment of society and creation of wealth we can all share. I happen to agree with both statements but you'll find significant numbers of people who don't, especially the last one.
The problem isn't that copyright length is too long or too short - any reasonable person can debate this. The problem is that there's a significant group of people who reject the very notion and system of copyright itself, all whilst expecting to benefit from its fruits.
For instance Bigjeff5 trots out tired old canards like "people are happy to pay if it's priced reasonably", although such a statement is useless for a content creator (what is reasonable?) and wrong anyway as seen by the huge amount of iPhone app piracy.
I don't know what the solution is, but it doesn't surprise me that the WIPO considers all angles. It also won't surprise me if they don't make big changes - the "anti copyright" lobby makes a lot of noise about how the current system sucks but their suggestions for alternatives are usually weak and poorly thought out.
I think you are proving the OPs point. Japan has the same sort of IP enforcement as the rest of the world. China does not. I'm sure China can go the same route. Your suggestion of "public access to information" won't work though - being informed about the relative merits of FooCorp vs BarCorps products only works if both Foo and BarCorp label their products correctly, ie are based in places where trademarks are enforced.
Re:Open source is the coat tails that Google rides
on
How Google Uses Linux
·
· Score: 5, Insightful
Hmm, you realize that Android alone is over 10 million lines of code right? That's a pretty big open source contribution right there. But then there's also over a million lines of code across 100+ smaller projects too. So I am not sure what your definition of "table scraps" is but it's significantly more lines of code than most companies do.
Well, most programs are not OOM safe. It turns out to be really hard to write programs that behave gracefully in OOM scenarios. Killing a sacrificial process when the system is out of memory works OK if you have a pretty good idea of priority ordering of the processes, which Google systems do.
The Swiss design is OK. it's compatible with European sockets which is nice. I still prefer the British design though.
The main problem is that for some reason plugs often fail to easily go into sockets. I don't know why. This is a problem I had exactly never in the UK but I frequently have to wiggle the plug around to make it go in.
Americans are somehow able to resist the temptation that apparently so often overcomes their British counterparts to stick things in the socket other than a plug.
So, firstly, x86_64 was designed by AMD not Intel.
Secondly, the whole point of x86_64 was to simplify and improve the x86 architecture by removing stuff that nobody used at the same time as adding 64 bit support. And by your own admission basically nobody used kernels with separate address spaces for various reasons, performance on Intel amongst them.
I don't think having kernels run in the same address space as applications can be blamed on Intel no matter how hard one might try. For many years any kernel developer could produce a kernel which used separate address spaces and such things were just curiosities.
Believe it or not, my brother is a professional music producer who works on (amongst other things) Hollywood movies. So you're belief that I don't "hang around" with musicians isn't correct.
Amateurs can and do make games for the Xbox 360, so that argument doesn't really hold. The trouble is they're often extremely basic. The most popular games being played as measured by Microsoft are consistently the big budget franchise hits.
I read an interview with a guy from a studio, and he defended the high price of CDs: the price is fair because it's really hard to be a studio; you have to try to find new acts, and when you guess wrong, a whole bunch of CDs go into a landfill. Well, guess what: on the Internet, you can just provide the music, and if nobody likes it, it will just sit there; and if people do like it, you make pure profit. No CDs need be produced and then landfilled.
No offense intended but you completely misunderstood the guys point. Pressing CDs is cheap. "Throwing them in the landfill" was a metaphor for "losing the money invested" not for actually throwing away pieces of metal and plastic. The cost of producing a CD is mostly in the production, studio time, paying the people to sit around and compose all day, then the marketing costs needed to tell the world about this new act they might like. If the guess is wrong, that money is lost.
The future of music is: everything available on the Internet, at lower prices than if you buy CDs. Most artists will not bother to sign their fortunes over to big record studios; they will retain control of their music, and deal more directly with the customers.
Well we'd like to think that wouldn't we. But it doesn't actually seem to be going that way. What's the first thing all these bands that got big on MySpace did? Ah right, sign with a label. I listen to a lot of net radio, especially BassDrive. I heard a great track there the other day. Once I finally tracked it down, it turned out that it's unsigned. That means you can't buy it anywhere. I asked the producer why he doesn't sell it direct through CDbaby or on his own website, answer:
if you can give me 250 euro. yeah sure xD
no bro.. i only sell my tracks to recordlabels sorry
Huh. So much for the internet revolutionising music. Here is an obscure DnB producer that I found through internet radio, whos website is on MySpace and.... guess what. He only uses the "legacy business model". So though I'd love to see this frustrating and archaic system disappear, I do realize that it fulfills a purpose - musicians don't want to fuck about with distribution. They want to make music and have some semblance of financial stability, with other people absorbing the losses from failures and making it back on the hits.
Of course. But the solution to that is to sell to people who want to buy it, either to support the author, or to have a physical copy.
If you're going to make this argument, please use words precisely. What you mean when you say "buy" is actually "donate". Almost by the definition of capitalism, if you are "selling" to somebody who doesn't have to pay you (in fact, probably won't) then you're actually operating a charity and relying on donations to survive.
This isn't necessarily a bad model - as you point out, it has worked before. But it resulted in a stifling and uninnovative musical environment (good for religious folks though). If we're going down that road, society should be entirely clear about it to the musicians of the future. If a child ever says, "when I grow up I'm going to be a musician", we need to tell them - no you're not. Being a musician is a hobby that you do in your spare time.
And if we're going to do that for music, then really we should be consistent and say that for every job that is based on people getting paid for copyrighted works. For instance, if that child says "oh well. in that case I want to make video games!" - same thing. No you're not. You will get a job where you are paid per hour of your labor like the rest of the world.
Ditto for movies, books.... who knows what else in future.
But in reality, nobody wants to take that position. You claim you do, because "people have made music without being paid before", but that logic doesn't really generalize to other things like movies or video games. Music might well survive through the power of the amateur, but the rest probably won't. The popularity of big budget movies and games strongly suggests that most people are not willing to let it go just yet.
I used to work on Wine. The "secret APIs" don't exist. There are undocumented APIs yes, but only used by other parts of Windows (like IE) and most are extremely trivial or boring. Nothing that a competitor would care about.
Hm, that's not good. Is Microsoft going to re-patch the plugin to make it obvious that it's been fixed, so you can apply a version block instead of a name block?
Actually it's useful because threads on all platforms have overhead, which is why the reuse of them by GCD to run these lightweight blocks matters. It's why it's being integrated into BSD.
Well a GCD queue also has overhead, right? The OP is correct - on systems that get threading right (ie not OS X) if you have 200 tasks that can run in parallel, the easiest way forward is to create 200 threads.
When might you not want to do this? One is if each task has a large associated memory overhead so you don't want the data for every task to be in memory at once. In that case maybe you want fewer threads, and a controller thread that loads data and keeps the thread pool queue long enough that it never stalls but short enough that you use minimal memory.
Another situation is when a thread is very expensive. This is not true on Linux (at least if you're careful with stack size) and used to be true on Windows but I believe has been improved over time.
Another situation is where the tasks aren't available all at once. This is just a variant of the first scenario.
The final one is when a task blocks, eg, reading from disk. In that case you might want a very large number of threads in order to keep the CPUs busy and not waiting around on disk.
Let's be clear, GCD provides Objective-C with the features Java has had for over a decade now. The only difference is that thread pool sizes are globally co-ordinated, but as I mentioned in a different post further up, I think this is a gimmick and of all the problems I've had writing multi-threaded code, global co-ordination of thread pool size would have solved none of them.
There's absolutely nothing new or cool about thread pools and closures. Java developers, in fact anybody working in a modern high level language, have taken this for granted for a long time. If you want to see the successor of the BeOS API take a look at the Android API some time, which provides the same closure/invoke systems that GCD does along with a lot more. Android was designed in part by a bunch of former BeOS folks and can be seen as a simplification of that API whilst retaining its power for those who are able/willing to use threads.
No, Linux does not need that, nor does MacOS X (I'd hope).
Look. GCD is classic Apple - a cleverly hyped yet pedestrian technology. It's a thread pool. There's also some odd extension to C to allow for closures, but Java has been doing that since 1995. Anyway. The gimmick is, this thread pool is globally co-ordinated and chooses its own size based on instructions from some global co-ordinator instead of having the programmer specify the size. I anticipate this will make nearly no difference to actual end-user perceived performance because the cost of having many threads in the runqueue just isn't that high. This is certainly true on Linux and I'd imagine it should also be true on other platforms, although it's definitely the case that Linux threads are unusually cheap.
Let's take an example of a program I recently wrote that happens to fit this very specific model of parallelism. I have a program that downloads and "installs" a sample library called Cinematic Strings. This program is written in Java for time and portability reasons - it had to run on MacOS and Windows, and it was being written quickly for my brother. The samples come in an encrypted and losslessly compressed form, so the program needs to download, decrypt, decompress and watermark the samples as quickly as possible.
This is a classic example of "easy" parallelism - lots of small tasks that are entirely independent. It's very easy to make such a programs performance scale linearly in the number of CPU cores. It uses a thread pool sized to the number of CPU cores, with a "controller" thread that unpacks samples from a downloaded ZIP file and sends them to the pool in order to keep it fed. The pool is statically sized and does not change. The threads are marked as low/non-interactive priority. When this program is running then, it is capable of saturating every CPU core on the system.
So what happens when the system gets additional load put on it, for instance, if you start a program whilst the decompression is running? Well, the kernel (which is already aware of global system load) can decide to prioritize the interactive GUI threads ahead of the explicitly low priority decompression threads. These threads are kicked off the CPU whenever something more important needs them and placed into a queue, waiting to be let back in. However their state is preserved exactly, so as a programmer I don't need to be aware of this.
What happens if my installer is running, and somebody else tries to also saturate the CPU, perhaps somebody runs a game or simulation for instance? Then the kernel will ensure my program is effectively paused (or only runs in the gaps where no other thread from the higher priority task can run). It won't be completely paused but the impact on the other app should be minimal. In a GCD world, my app would receive a message to resize the pool downwards. This would have the advantage of freeing up a bit of memory used to holds the threads state, but if the kernel wanted to get REALLY aggressive it could already just pause the threads entirely and swap out their state to disk. I don't know of any kernels that actually are that aggressive with respect to low priority threads, but it's theoretically possible.
Anyway, I am rambling. The Ars Technica article says
Perhaps surprisingly, one of the most difficult parts of extracting maximum performance using traditional, manually managed threads is figuring out exactly how many threads to create. Too few, and you risk leaving hardware idle. Too many, and you start to spend a significant amount of time simply shuffling threads in and out of the available processor cores.
But I've done a fair bit of multi-threaded programming and frankly this question has never even come up. I've never seen a multi-threaded program bottleneck on context switch speed - you will blow your RSS limits and start paging due to all the stacks far before reaching that point, unless you're programming s
Given that the 2 year gestation period was supposedly to focus on bug fixing and internal cleanups, one wonders why Snow Leopard is apparently so buggy. It actually shipped with some serious regressions around VPNs that make it nearly unusable for corporate work - now how does something like that get through?
A few years ago before the iPhone came out, there were rumors that Apple had pulled their best people from MacOS X and put them on the iPhone. The state of Snow Leopard strongly implies that they don't have sufficient manpower to develop two operating systems simultaneously - and given that they are successful and rich, that leads to the question of why not?
Because the nuclear industry has been, uh, "less than perfect" over the years. You think catastrophic stupidity is restricted to Russia? Think again. There have been a series of low level accidents and releases of dangerous materials over time. And that's just the accidental stuff. Don't forget deliberate malice.
It's fair to say that some people dislike nuclear power because they don't understand the science, but it's also fair to say others dislike it because they feel humanity isn't clueful enough to deal with it. The lack of a good solution to the waste issue is one example that backs them up, the fact that the nuclear industry needs massive subsidies is another.
Slashdot Mirror
Sure. Look at modern games console DRM (PlayStation 3, for example).
Of course, "perfect" DRM is only theoretically possible for things where the experience is unique for each user, like software. For books the best you're gonna get is making it as annoying to pirate as a real paper book. That's probably good enough - short of special cases like student textbooks, I rarely see somebody reading a pirated book. Go down to the beach and I don't see photocopies in use.
Whether anybody has succeeded in making such a DRM I don't know. Is the newest Kindle DRM broken?
It's just playing with words. Saying the goal of copyright is to promote creativity and prodution of useful content is exactly equivalent to saying that the goal of the free market is to encourage the betterment of society and creation of wealth we can all share. I happen to agree with both statements but you'll find significant numbers of people who don't, especially the last one.
The problem isn't that copyright length is too long or too short - any reasonable person can debate this. The problem is that there's a significant group of people who reject the very notion and system of copyright itself, all whilst expecting to benefit from its fruits.
For instance Bigjeff5 trots out tired old canards like "people are happy to pay if it's priced reasonably", although such a statement is useless for a content creator (what is reasonable?) and wrong anyway as seen by the huge amount of iPhone app piracy.
I don't know what the solution is, but it doesn't surprise me that the WIPO considers all angles. It also won't surprise me if they don't make big changes - the "anti copyright" lobby makes a lot of noise about how the current system sucks but their suggestions for alternatives are usually weak and poorly thought out.
I think you are proving the OPs point. Japan has the same sort of IP enforcement as the rest of the world. China does not. I'm sure China can go the same route. Your suggestion of "public access to information" won't work though - being informed about the relative merits of FooCorp vs BarCorps products only works if both Foo and BarCorp label their products correctly, ie are based in places where trademarks are enforced.
Hmm, you realize that Android alone is over 10 million lines of code right? That's a pretty big open source contribution right there. But then there's also over a million lines of code across 100+ smaller projects too. So I am not sure what your definition of "table scraps" is but it's significantly more lines of code than most companies do.
Well, most programs are not OOM safe. It turns out to be really hard to write programs that behave gracefully in OOM scenarios. Killing a sacrificial process when the system is out of memory works OK if you have a pretty good idea of priority ordering of the processes, which Google systems do.
You don't have to buy laws if you choose not to respect them in the first place.
Or, you know, the number of people searching for a thing is only weakly related to the number of results that search returns?
The Swiss design is OK. it's compatible with European sockets which is nice. I still prefer the British design though.
The main problem is that for some reason plugs often fail to easily go into sockets. I don't know why. This is a problem I had exactly never in the UK but I frequently have to wiggle the plug around to make it go in.
Children.
So, firstly, x86_64 was designed by AMD not Intel.
Secondly, the whole point of x86_64 was to simplify and improve the x86 architecture by removing stuff that nobody used at the same time as adding 64 bit support. And by your own admission basically nobody used kernels with separate address spaces for various reasons, performance on Intel amongst them.
I don't think having kernels run in the same address space as applications can be blamed on Intel no matter how hard one might try. For many years any kernel developer could produce a kernel which used separate address spaces and such things were just curiosities.
No offense AC, but given that the post starts with "My ex-wife" your powers of observation are yet more evidence for the articles theory.
Believe it or not, my brother is a professional music producer who works on (amongst other things) Hollywood movies. So you're belief that I don't "hang around" with musicians isn't correct.
Amateurs can and do make games for the Xbox 360, so that argument doesn't really hold. The trouble is they're often extremely basic. The most popular games being played as measured by Microsoft are consistently the big budget franchise hits.
No offense intended but you completely misunderstood the guys point. Pressing CDs is cheap. "Throwing them in the landfill" was a metaphor for "losing the money invested" not for actually throwing away pieces of metal and plastic. The cost of producing a CD is mostly in the production, studio time, paying the people to sit around and compose all day, then the marketing costs needed to tell the world about this new act they might like. If the guess is wrong, that money is lost.
Well we'd like to think that wouldn't we. But it doesn't actually seem to be going that way. What's the first thing all these bands that got big on MySpace did? Ah right, sign with a label. I listen to a lot of net radio, especially BassDrive. I heard a great track there the other day. Once I finally tracked it down, it turned out that it's unsigned. That means you can't buy it anywhere. I asked the producer why he doesn't sell it direct through CDbaby or on his own website, answer:
Huh. So much for the internet revolutionising music. Here is an obscure DnB producer that I found through internet radio, whos website is on MySpace and .... guess what. He only uses the "legacy business model". So though I'd love to see this frustrating and archaic system disappear, I do realize that it fulfills a purpose - musicians don't want to fuck about with distribution. They want to make music and have some semblance of financial stability, with other people absorbing the losses from failures and making it back on the hits.
If you're going to make this argument, please use words precisely. What you mean when you say "buy" is actually "donate". Almost by the definition of capitalism, if you are "selling" to somebody who doesn't have to pay you (in fact, probably won't) then you're actually operating a charity and relying on donations to survive.
This isn't necessarily a bad model - as you point out, it has worked before. But it resulted in a stifling and uninnovative musical environment (good for religious folks though). If we're going down that road, society should be entirely clear about it to the musicians of the future. If a child ever says, "when I grow up I'm going to be a musician", we need to tell them - no you're not. Being a musician is a hobby that you do in your spare time.
And if we're going to do that for music, then really we should be consistent and say that for every job that is based on people getting paid for copyrighted works. For instance, if that child says "oh well. in that case I want to make video games!" - same thing. No you're not. You will get a job where you are paid per hour of your labor like the rest of the world.
Ditto for movies, books .... who knows what else in future.
But in reality, nobody wants to take that position. You claim you do, because "people have made music without being paid before", but that logic doesn't really generalize to other things like movies or video games. Music might well survive through the power of the amateur, but the rest probably won't. The popularity of big budget movies and games strongly suggests that most people are not willing to let it go just yet.
And that is why I think you are wrong.
.com stands for commercial and Slashdot is in fact a commercial site.
I used to work on Wine. The "secret APIs" don't exist. There are undocumented APIs yes, but only used by other parts of Windows (like IE) and most are extremely trivial or boring. Nothing that a competitor would care about.
Symbian Signed + lack of good distribution mechanism.
Hm, that's not good. Is Microsoft going to re-patch the plugin to make it obvious that it's been fixed, so you can apply a version block instead of a name block?
Well a GCD queue also has overhead, right? The OP is correct - on systems that get threading right (ie not OS X) if you have 200 tasks that can run in parallel, the easiest way forward is to create 200 threads.
When might you not want to do this? One is if each task has a large associated memory overhead so you don't want the data for every task to be in memory at once. In that case maybe you want fewer threads, and a controller thread that loads data and keeps the thread pool queue long enough that it never stalls but short enough that you use minimal memory.
Another situation is when a thread is very expensive. This is not true on Linux (at least if you're careful with stack size) and used to be true on Windows but I believe has been improved over time.
Another situation is where the tasks aren't available all at once. This is just a variant of the first scenario.
The final one is when a task blocks, eg, reading from disk. In that case you might want a very large number of threads in order to keep the CPUs busy and not waiting around on disk.
Let's be clear, GCD provides Objective-C with the features Java has had for over a decade now. The only difference is that thread pool sizes are globally co-ordinated, but as I mentioned in a different post further up, I think this is a gimmick and of all the problems I've had writing multi-threaded code, global co-ordination of thread pool size would have solved none of them.
There's absolutely nothing new or cool about thread pools and closures. Java developers, in fact anybody working in a modern high level language, have taken this for granted for a long time. If you want to see the successor of the BeOS API take a look at the Android API some time, which provides the same closure/invoke systems that GCD does along with a lot more. Android was designed in part by a bunch of former BeOS folks and can be seen as a simplification of that API whilst retaining its power for those who are able/willing to use threads.
No, Linux does not need that, nor does MacOS X (I'd hope).
Look. GCD is classic Apple - a cleverly hyped yet pedestrian technology. It's a thread pool. There's also some odd extension to C to allow for closures, but Java has been doing that since 1995. Anyway. The gimmick is, this thread pool is globally co-ordinated and chooses its own size based on instructions from some global co-ordinator instead of having the programmer specify the size. I anticipate this will make nearly no difference to actual end-user perceived performance because the cost of having many threads in the runqueue just isn't that high. This is certainly true on Linux and I'd imagine it should also be true on other platforms, although it's definitely the case that Linux threads are unusually cheap.
Let's take an example of a program I recently wrote that happens to fit this very specific model of parallelism. I have a program that downloads and "installs" a sample library called Cinematic Strings. This program is written in Java for time and portability reasons - it had to run on MacOS and Windows, and it was being written quickly for my brother. The samples come in an encrypted and losslessly compressed form, so the program needs to download, decrypt, decompress and watermark the samples as quickly as possible.
This is a classic example of "easy" parallelism - lots of small tasks that are entirely independent. It's very easy to make such a programs performance scale linearly in the number of CPU cores. It uses a thread pool sized to the number of CPU cores, with a "controller" thread that unpacks samples from a downloaded ZIP file and sends them to the pool in order to keep it fed. The pool is statically sized and does not change. The threads are marked as low/non-interactive priority. When this program is running then, it is capable of saturating every CPU core on the system.
So what happens when the system gets additional load put on it, for instance, if you start a program whilst the decompression is running? Well, the kernel (which is already aware of global system load) can decide to prioritize the interactive GUI threads ahead of the explicitly low priority decompression threads. These threads are kicked off the CPU whenever something more important needs them and placed into a queue, waiting to be let back in. However their state is preserved exactly, so as a programmer I don't need to be aware of this.
What happens if my installer is running, and somebody else tries to also saturate the CPU, perhaps somebody runs a game or simulation for instance? Then the kernel will ensure my program is effectively paused (or only runs in the gaps where no other thread from the higher priority task can run). It won't be completely paused but the impact on the other app should be minimal. In a GCD world, my app would receive a message to resize the pool downwards. This would have the advantage of freeing up a bit of memory used to holds the threads state, but if the kernel wanted to get REALLY aggressive it could already just pause the threads entirely and swap out their state to disk. I don't know of any kernels that actually are that aggressive with respect to low priority threads, but it's theoretically possible.
Anyway, I am rambling. The Ars Technica article says
But I've done a fair bit of multi-threaded programming and frankly this question has never even come up. I've never seen a multi-threaded program bottleneck on context switch speed - you will blow your RSS limits and start paging due to all the stacks far before reaching that point, unless you're programming s
Given that the 2 year gestation period was supposedly to focus on bug fixing and internal cleanups, one wonders why Snow Leopard is apparently so buggy. It actually shipped with some serious regressions around VPNs that make it nearly unusable for corporate work - now how does something like that get through?
A few years ago before the iPhone came out, there were rumors that Apple had pulled their best people from MacOS X and put them on the iPhone. The state of Snow Leopard strongly implies that they don't have sufficient manpower to develop two operating systems simultaneously - and given that they are successful and rich, that leads to the question of why not?
I'm not sure what you mean by "cloud provider" as such but Google App Engine has always been replicated across datacenters.
Because the nuclear industry has been, uh, "less than perfect" over the years. You think catastrophic stupidity is restricted to Russia? Think again. There have been a series of low level accidents and releases of dangerous materials over time. And that's just the accidental stuff. Don't forget deliberate malice.
It's fair to say that some people dislike nuclear power because they don't understand the science, but it's also fair to say others dislike it because they feel humanity isn't clueful enough to deal with it. The lack of a good solution to the waste issue is one example that backs them up, the fact that the nuclear industry needs massive subsidies is another.