Look, c has "real strings." They're trivially easy to deal with; if such management is actually beyond a programmer's skills, they're working in the wrong field. Starting with the basic 0-terminated model, you can create any kind of string management / data structure you want. That's the beauty of c. You can do anything you think you need to.
As far as "easy" memory management goes, my goal as a programmer is to produce something that is as system-friendly, fast, compact, and as functional as possible. Easy is fine, until it conflicts with any of those goals, unless it has to (writing in assembler isn't practical when dealing with many architectures, for instance) So as soon as someone says "auto memory management is easy!", I respond with, "does it impact system-friendliness, speed, code size, or function?" If they can honestly answer "no", then I'm good with it.
Often, though, auto memory management can lead to program stalls, general slowdowns, and these inherently interfere with the intended function. Ay which point I prefer to do it myself, using my knowledge of the actual scopes involved and various arrangements of pools and reserved areas to keep performance up.
For me, it's not just about getting "done." I want to get done and know that the result was the best I knew how to do.
What's wrong with pgdb (PyGreSQL)? I use that as the basis for my postgreSQL interactions, seems to work fine.
I did write a nice layer on top of it that does things a little differently, but that was the work of a few hours at most, and really just because I like things to work a certain way.
I wouldn't go back to writing my CGI with C unless there was a no-lawsuits clause.
Write a small module that provides error checking. Always use it. No I/o, including DB, I mean literally NO I/o, except through it. Parameter length checking, character scrubbing, quote imbalance checking, credit card number validation, date validation, range checking, throttling, email validation, URL controls... whatever you need, and you can write it as you need it. If you find you need to make a call to something and you don't have it covered -- then you need it.
Not only is this relatively easy to do, it's instructive and enjoyable work. And you get a heck of a lot of bang for your efforts.
Here, free speech is constitutionally based, whereas the general attitude towards atheists is a social problem brought on by a population steeped in superstition. The latter doesn't invalidate the former. In fact, it's notable that in such an environment, as an atheist, I can still speak freely: in person, online, in print, etc.
WRT state legislation restricting atheists from holding office, I would not expect that to stand if constitutionally challenged in court. But it's irrelevant at this point, because an atheist is unelectable in those states anyway -- they have strongly superstitious populations.
We are many years from reality-based thinking in this country. As I said previously, we are not perfect. I am simply saying that WRT free speech, we're just about the best there is. Can we keep it in the face of recent government constitutional over-reach? I don't know.
On the other hand, it might be the beginning of problems for people who show disrespect to religion. There are some really poorly reasoned attitudes and legislation towards free speech outside the USA. I'm not saying we're perfect, but we are better, at least in that regard.
See, the difference is that rivers never used to flow uphill, so yes, there's your myth. Privacy did, in fact, have a significant role in our society -- that is not a myth. This was before folks like you grew up and got into the system. The 4th amendment used to mean something. But what it meant (primarily) was that the federal, and pretty much the state, governments had hard limits on them. They no longer do, as SCOTUS has made perfectly clear. So you're right, when you characterize it as "putting the genie back in the bottle" in terms of difficulty. However, you're very wrong when you characterize it as a myth. Vestiges still remain. As they go, there will be some uproar from those who understand the value of what is being lost, and yes, I know, you don't have to tell me -- that won't include you or people like you.
Mike Hunt is the poster child for a career of being shafted. From his start with the Toronto Blue Balls, to his career-ending finale when he ill-advisedly swung at a pitch from Wrong-Hole-Harriet, Hunt moved deeper and deeper until the truth finally penetrated: All this time, they'd treated him like a dick. He knew it was time to pull out, and pull out he did. Some analysts think it's pushing it to say so, but those in the know speak of the collapse of walls of the sport, giving Hunt the nod for stretching it out as long as possible. Now Hunt seeks a private life, trying to avoid the press and the associated innuendo.
He said they reduce their activity. Ever hear of a siesta?
...and so this is a threat... how? Ignoring for the moment that we have multiple varieties of air conditioning tech if we want to use it, and that complementary tech (insulation, air treatment, even clothing and body state analysis) is getting better all the time, and that the earth has been a lot warmer than it is now (and was very lively at those times, ecologically speaking), and that the rates of global warming seem to be even slower than the word "glacial" implies... and that shore erosion and infrastructure rebuilding is normal over the course of decades and centuries... and that migration occurs on a much shorter time scale than any of the supposed "threats"... so, ignoring all that, what level of concern do you suggest we assign to the possibility of an... afternoon nap?
So, a jump in global temperature, i.e. one that is faster than evolution can keep pace with, would pose a serious threat to animals in areas where the gap between their core temperature and the environment is reduced.
Yes, that's why every human and every other animal at or near the equator is dead today.
Depends on the size of the spacecraft, the number of air filtering systems, power supplies, zones, etc. You're not really considering a properly engineered system there, just a naive design. As for climate change, think about what the impact of a good sized asteroid or comet would do. A spacecraft can simply dodge.
Also, spacecraft can easily dodge big rocks and comets. Planets can't dodge those at all, and so far, we don't have any other solutions, either. Spacecraft can also hide behind other objects during solar storms. Planets, and those on them, just have to deal.
There's also a fair bit of science you can do better on a (or many) spacecraft; astronomy, for one.
Once manufacturing gets a proper foothold in space, assembly of (just about anything) will be a great deal easier as well. Gravity is really annoying when you want to build something large. Many structures only obtain anything near their final strength when they're nearly or completely built. Space is ideal for anything like that. Materials delivery in 0g is also significantly enhanced: Aim, push, and wait. Talk about cheap!
You're describing an embarrassingly parallel application [clippage]...Easy threading is easy, but deriding it as something less than "serious" programming belies a degree of ignorance.
What part of "some problem spaces lend themselves very well to multiple core approaches" did you not understand?
The problem with generalised parallel programming is that the possible interactions between all threads are on the order of O(n!).
Only when the threads share data; and that's what mutexes, etc., are for. If you share data without mutexes, it had better be 100% invariant (table of constants, etc.) Or actually not shared: different regions of an image where the process at hand doesn't have inter-region dependencies. So really, it's not O(n!) in any practical sense.
Take a complex mathematical expression, which can be transformed into a syntax tree [rest of very well presented stuff clipped]
Also, you need to take account of (and make the end user aware of) the difference between a real core and hyper-threading. Because while you may have run it on a quad core, they may run it on a "hyperthreaded dual core", and this is not the same thing at all, unless you can arrange for those stalls (in your hypothetical slow transcendent ops) to go do something else useful in your overall context.
Sometimes the right answer to the type of problem you present is to move the goalposts. Sometimes you can use fixed point, tables of sin/cos, etc. 16-bit audio data is a good example of where this is easily done for certain types of operations. Generate the table(s) once on startup, thereafter it's no slower than any other memory access, yet it's still as transcendent as it needs to be.
A concrete example: If you're going to rotate pixels in an image, then, you could use "nx = (x * sin(theta)) - (y * cos(theta))" as part of the job, if you wanted to do it that way. But you can observe that theta is invariant, so you only need two constants: sin(theta) and cos(theta); you don't have to run sin() and cos() for every pixel. So now your potentially stalling transcendents are of no consequence; your execution is "nx = x*StoredSinConst - y*StoredCosConst." (and of course, if you process the image Y by X, then you don't have to calculate ny except once per line, either, and you can substitute addition for multiplication if you process the cartesian space sequentially, but that's a different issue. Sorry.:)
however when you want to write an application that essentially puts everything asynchronously into the background (not just for speed, but also interactive responsiveness) then things get really complicated really fast, doubly so when programming in a language with no build in support for parallel programming.
Perhaps you and I simply have different appreciations for the word "complicated." The only "support" I require for parallel programming are concurrency controls such as mutexes and a means to (hopefully, efficiently) launch a thread. I've written multi-threaded image processing, SDR code (and believe me, that's the poster child for requiring responsiveness... it's pure realtime), AL/evolutionary code, ray tracers, and so on. Me, a c compiler, and a lot of pizza.:)
The core problem with parallel programming is that it bloats your code a lot, things that were trivial in sequential code turn into code that is five times the size and a nightmare of callback chaining.
Sounds to me like that's a consequence of your approach, or perhaps your tools, because "a nightmare of callback chaining" is nothing that's ever happened to me. Quite the contrary, in fact. So it goes from your "core problem" to no problem at all in my case. I would go so far as to venture the suggestion that you may be doing it wrong, or poorly, or with a really problematic language. Or perhaps you just need more pizza. As I said above, it takes study.
It's a skill set that's very similar to that required to learn assembly optimization. What I mean by that... where you move invariants outside loops, where they only get computed once; while the stuff that actually needs to change constantly is in the inner loop. You have to be able to look at an algorithm and see what needs to be computed within the current context, what comes from outside, what is interdependent, and so on. Without that insight, you can't code this stuff at all. But like learning to optimize assembler, once you learn that this is what you need to know about things, you begin to perceive it, and eventually, you'll get good at perceiving it.
I've always felt that the best programmers (in the sense of creating the most efficient code in both space and execution time) are those who understand assembly programming extremely well, can look at the assembly code a c compiler produces and read it like it was this morning's news, and have a broad familiarity with a pretty good set of HLLs. For me, c is the ideal tool -- it is at precisely the right level to let me do what I need to do, no matter what it is; if I need OO, I can implement objects of my own design. If I need a thread manager, I can write it. If I need some specific type of control over memory allocation, or list management, associative arrays, etc., I can write it. Or lift it from a large collection of stuff I've already written. The higher up you go from c, and the more you depend upon other people's code and libraries / objects, the more control you lose. If that's ok, fine. But for parallel programming, I've never found that it was ok. Your milage, of course, may differ. I would only point out that I am very comfy with threaded programming, and you do not seem to be. There may be some useful information in that for you.
Do you really want to bet that you understand a modern CPU, the related hardware architecture, and a production quality compiler for that platform, all well enough to predict reliably when it's worth running a few instructions in parallel and when it isn't,
Yes, of course. Do you think a "modern CPU" is suddenly going to borrow your local stack from one core to another without having switched the rest of the relevant context as well? Do you think it will be able to tell who's on first without a mutex or similar mechanism? Do you think it won't be able to tell with one if you use it properly? Seriously, come on. The day they design a "modern (multicore) CPU" that doesn't provide for the basic mechanisms that make multi-core algorithms practical, is the day that CPU is a complete flop. Likewise, the day you use a multicore CPU without using those mechanisms properly is the day your program is a complete flop. You have to learn them. It's the bedrock that underlies the task.
As for your question about how much code to switch, first of all, benchmarking in both unloaded and loaded systems is part of the ground work. At some point it becomes obvious: if you're going to be executing just a few lines of mundane memory-tossing, then the overhead of the threading isn't worth the time. You need to understand the basics: do all your cores get equal access to FPUs? How does the OS allocate cores? How many can you get? How many are there? Do you have control? Does the OS have control? Do you want to give the user control? These things aren't "hard", they're just part of the problem space.
Can you really analyse(sic) the global structure of a 1,000,000+ line project and reliably identify algorithms that are expressed sequentially but in fact could be transformed losslessly into parallelised equivalents?
Wait a minute. Now you're talking about trying to re-factor someone else's code. That's a whole nuther ball game than designing a system involving some degree of parallism and implementing it. OPC is an endless nightmare -- there's no limit to how bad it can get. If you ask me if I can design such a system, and implement it, then the answer is yes, almost certainly, as long as I can comprehend the problem space. If you're asking me if I can take someone else's single threaded, unknown quality code and turn it into a parallel version of itself, even given that I do understand the problem space, the answer is most likely "you can't afford me", but if you can, then the answer is a question: "do you have time for me to design it and re-implement it?" At this point, your answer is my answer.
I look forward to reading your papers, because you just outsmarted a lot of researchers who have been investigating this problem for years.
I didn't offer a "paper" -- I am not an academic -- nor did I contend that this knowledge is something that can be described in a few paragraphs from some ivory tower. I said that in order to succeed at it, you need to study until you get it. If you're a decent programmer, you can do it. That's not to say that I'm claiming any specific individual a decent programmer. Just that if you are, this is something you can do.
any law which makes everyone a criminal is a broken law.
Only in a democracy. And I'd remind you, the US is not a democracy. It was supposed to be a constitutional republic, but turned into a corporate oligarchy instead. The one thing it is not is a democracy.
The mistake you make is in thinking these laws were (or should have been) passed for your benefit. They were not. They were passed to benefit the largest copyright holders, those that can afford to litigate. They do that very well.
The only way to get this to change is to change the system. Attacking the laws themselves involves a complete mis-focus, and will be roundly ignored by any representative in the system until or unless you can put more money and/or power in their hands than the large copyright holders can. Can you do that?
Honestly, you know what this says? This just says some programmers still need to go practice in the threading space.
Threading is not that hard at all for a VERY large class of problems. There are issues -- like, the memory bandwidth will eventually choke the ability of processors to get at nearby memory regions -- and you need some kind of sane plan to deal with cacheing in one core as compared to the next core when you share flags or data coming in during execution from elsewhere -- and you need to figure out when thread overhead starts to chew into your efficiencies -- but really, it's entirely doable, and isn't that difficult a problem space as compared to the actual problems *serious* programmers have to solve. It may just be that your "thing" isn't really all that threadable. Some things aren't. But it should also be very obvious when they aren't.
Then again, some problem spaces lend themselves very well to multiple core approaches -- I just finished a library that slices up images and then applies various separable algorithms to the slices in a variable number of threads (the user of the library can specify.) I wrote it in pure C, used posix threads, no sweat at all, in my 8-core machine, you get just about exactly the gains you'd think (x the number of cores) when the process is CPU cycle intensive, less as the ops are simpler and memory I/O rates rise.
Seriously. If threading seems that hard, you need to go do some studying. It's not the threading. It's you. You really should get on this bus.
Well, perhaps, but not on this basis -- I can afford, and in fact own, lots of Apple gear. I think OSX 10.6 and earlier, before they hosed the multi-monitor support, is a great OS.
The original contention was that if one could not afford something, this would be disturbing. I don't find that to be the case at all, beyond a certain basic level. I was happy living with my cat and bookshelves made of planks, back in the day. I got my books from the used bookstore and I really felt like things were just fine.:)
Now I can afford more, and I in fact buy more, but it doesn't define my happiness, I assure you.
Slashdot Mirror
Look, c has "real strings." They're trivially easy to deal with; if such management is actually beyond a programmer's skills, they're working in the wrong field. Starting with the basic 0-terminated model, you can create any kind of string management / data structure you want. That's the beauty of c. You can do anything you think you need to.
As far as "easy" memory management goes, my goal as a programmer is to produce something that is as system-friendly, fast, compact, and as functional as possible. Easy is fine, until it conflicts with any of those goals, unless it has to (writing in assembler isn't practical when dealing with many architectures, for instance) So as soon as someone says "auto memory management is easy!", I respond with, "does it impact system-friendliness, speed, code size, or function?" If they can honestly answer "no", then I'm good with it.
Often, though, auto memory management can lead to program stalls, general slowdowns, and these inherently interfere with the intended function. Ay which point I prefer to do it myself, using my knowledge of the actual scopes involved and various arrangements of pools and reserved areas to keep performance up.
For me, it's not just about getting "done." I want to get done and know that the result was the best I knew how to do.
No, no. He just misheard. It's about chicken. It's a project for Colonel level development...
What's wrong with pgdb (PyGreSQL)? I use that as the basis for my postgreSQL interactions, seems to work fine.
I did write a nice layer on top of it that does things a little differently, but that was the work of a few hours at most, and really just because I like things to work a certain way.
Write a small module that provides error checking. Always use it. No I/o, including DB, I mean literally NO I/o, except through it. Parameter length checking, character scrubbing, quote imbalance checking, credit card number validation, date validation, range checking, throttling, email validation, URL controls... whatever you need, and you can write it as you need it. If you find you need to make a call to something and you don't have it covered -- then you need it.
Not only is this relatively easy to do, it's instructive and enjoyable work. And you get a heck of a lot of bang for your efforts.
You are responsible for your own actions and choices, including paying attention to the pap the media spews.
Here, free speech is constitutionally based, whereas the general attitude towards atheists is a social problem brought on by a population steeped in superstition. The latter doesn't invalidate the former. In fact, it's notable that in such an environment, as an atheist, I can still speak freely: in person, online, in print, etc.
WRT state legislation restricting atheists from holding office, I would not expect that to stand if constitutionally challenged in court. But it's irrelevant at this point, because an atheist is unelectable in those states anyway -- they have strongly superstitious populations.
We are many years from reality-based thinking in this country. As I said previously, we are not perfect. I am simply saying that WRT free speech, we're just about the best there is. Can we keep it in the face of recent government constitutional over-reach? I don't know.
Dear Sir:
I represent the national association of Cod. Speaking for my fellow swimmers, we deplore your plan.
Fishily yours,
The Codwhale
On the other hand, it might be the beginning of problems for people who show disrespect to religion. There are some really poorly reasoned attitudes and legislation towards free speech outside the USA. I'm not saying we're perfect, but we are better, at least in that regard.
See, the difference is that rivers never used to flow uphill, so yes, there's your myth. Privacy did, in fact, have a significant role in our society -- that is not a myth. This was before folks like you grew up and got into the system. The 4th amendment used to mean something. But what it meant (primarily) was that the federal, and pretty much the state, governments had hard limits on them. They no longer do, as SCOTUS has made perfectly clear. So you're right, when you characterize it as "putting the genie back in the bottle" in terms of difficulty. However, you're very wrong when you characterize it as a myth. Vestiges still remain. As they go, there will be some uproar from those who understand the value of what is being lost, and yes, I know, you don't have to tell me -- that won't include you or people like you.
Mike Hunt is the poster child for a career of being shafted. From his start with the Toronto Blue Balls, to his career-ending finale when he ill-advisedly swung at a pitch from Wrong-Hole-Harriet, Hunt moved deeper and deeper until the truth finally penetrated: All this time, they'd treated him like a dick. He knew it was time to pull out, and pull out he did. Some analysts think it's pushing it to say so, but those in the know speak of the collapse of walls of the sport, giving Hunt the nod for stretching it out as long as possible. Now Hunt seeks a private life, trying to avoid the press and the associated innuendo.
Yes, that's why every human and every other animal at or near the equator is dead today.
Oh. Wait.
Well, slashdot's a start, isn't it?
Depends on the size of the spacecraft, the number of air filtering systems, power supplies, zones, etc. You're not really considering a properly engineered system there, just a naive design. As for climate change, think about what the impact of a good sized asteroid or comet would do. A spacecraft can simply dodge.
Also, spacecraft can easily dodge big rocks and comets. Planets can't dodge those at all, and so far, we don't have any other solutions, either. Spacecraft can also hide behind other objects during solar storms. Planets, and those on them, just have to deal.
There's also a fair bit of science you can do better on a (or many) spacecraft; astronomy, for one.
Once manufacturing gets a proper foothold in space, assembly of (just about anything) will be a great deal easier as well. Gravity is really annoying when you want to build something large. Many structures only obtain anything near their final strength when they're nearly or completely built. Space is ideal for anything like that. Materials delivery in 0g is also significantly enhanced: Aim, push, and wait. Talk about cheap!
See this post.
What part of "some problem spaces lend themselves very well to multiple core approaches" did you not understand?
Only when the threads share data; and that's what mutexes, etc., are for. If you share data without mutexes, it had better be 100% invariant (table of constants, etc.) Or actually not shared: different regions of an image where the process at hand doesn't have inter-region dependencies. So really, it's not O(n!) in any practical sense.
Also, you need to take account of (and make the end user aware of) the difference between a real core and hyper-threading. Because while you may have run it on a quad core, they may run it on a "hyperthreaded dual core", and this is not the same thing at all, unless you can arrange for those stalls (in your hypothetical slow transcendent ops) to go do something else useful in your overall context.
Sometimes the right answer to the type of problem you present is to move the goalposts. Sometimes you can use fixed point, tables of sin/cos, etc. 16-bit audio data is a good example of where this is easily done for certain types of operations. Generate the table(s) once on startup, thereafter it's no slower than any other memory access, yet it's still as transcendent as it needs to be.
A concrete example: If you're going to rotate pixels in an image, then, you could use "nx = (x * sin(theta)) - (y * cos(theta))" as part of the job, if you wanted to do it that way. But you can observe that theta is invariant, so you only need two constants: sin(theta) and cos(theta); you don't have to run sin() and cos() for every pixel. So now your potentially stalling transcendents are of no consequence; your execution is "nx = x*StoredSinConst - y*StoredCosConst." (and of course, if you process the image Y by X, then you don't have to calculate ny except once per line, either, and you can substitute addition for multiplication if you process the cartesian space sequentially, but that's a different issue. Sorry. :)
Fine. But that doesn't make it so.
Perhaps you and I simply have different appreciations for the word "complicated." The only "support" I require for parallel programming are concurrency controls such as mutexes and a means to (hopefully, efficiently) launch a thread. I've written multi-threaded image processing, SDR code (and believe me, that's the poster child for requiring responsiveness... it's pure realtime), AL/evolutionary code, ray tracers, and so on. Me, a c compiler, and a lot of pizza. :)
Sounds to me like that's a consequence of your approach, or perhaps your tools, because "a nightmare of callback chaining" is nothing that's ever happened to me. Quite the contrary, in fact. So it goes from your "core problem" to no problem at all in my case. I would go so far as to venture the suggestion that you may be doing it wrong, or poorly, or with a really problematic language. Or perhaps you just need more pizza. As I said above, it takes study.
It's a skill set that's very similar to that required to learn assembly optimization. What I mean by that... where you move invariants outside loops, where they only get computed once; while the stuff that actually needs to change constantly is in the inner loop. You have to be able to look at an algorithm and see what needs to be computed within the current context, what comes from outside, what is interdependent, and so on. Without that insight, you can't code this stuff at all. But like learning to optimize assembler, once you learn that this is what you need to know about things, you begin to perceive it, and eventually, you'll get good at perceiving it.
I've always felt that the best programmers (in the sense of creating the most efficient code in both space and execution time) are those who understand assembly programming extremely well, can look at the assembly code a c compiler produces and read it like it was this morning's news, and have a broad familiarity with a pretty good set of HLLs. For me, c is the ideal tool -- it is at precisely the right level to let me do what I need to do, no matter what it is; if I need OO, I can implement objects of my own design. If I need a thread manager, I can write it. If I need some specific type of control over memory allocation, or list management, associative arrays, etc., I can write it. Or lift it from a large collection of stuff I've already written. The higher up you go from c, and the more you depend upon other people's code and libraries / objects, the more control you lose. If that's ok, fine. But for parallel programming, I've never found that it was ok. Your milage, of course, may differ. I would only point out that I am very comfy with threaded programming, and you do not seem to be. There may be some useful information in that for you.
Yes. That's our job.
Yes, of course. Do you think a "modern CPU" is suddenly going to borrow your local stack from one core to another without having switched the rest of the relevant context as well? Do you think it will be able to tell who's on first without a mutex or similar mechanism? Do you think it won't be able to tell with one if you use it properly? Seriously, come on. The day they design a "modern (multicore) CPU" that doesn't provide for the basic mechanisms that make multi-core algorithms practical, is the day that CPU is a complete flop. Likewise, the day you use a multicore CPU without using those mechanisms properly is the day your program is a complete flop. You have to learn them. It's the bedrock that underlies the task.
As for your question about how much code to switch, first of all, benchmarking in both unloaded and loaded systems is part of the ground work. At some point it becomes obvious: if you're going to be executing just a few lines of mundane memory-tossing, then the overhead of the threading isn't worth the time. You need to understand the basics: do all your cores get equal access to FPUs? How does the OS allocate cores? How many can you get? How many are there? Do you have control? Does the OS have control? Do you want to give the user control? These things aren't "hard", they're just part of the problem space.
Wait a minute. Now you're talking about trying to re-factor someone else's code. That's a whole nuther ball game than designing a system involving some degree of parallism and implementing it. OPC is an endless nightmare -- there's no limit to how bad it can get. If you ask me if I can design such a system, and implement it, then the answer is yes, almost certainly, as long as I can comprehend the problem space. If you're asking me if I can take someone else's single threaded, unknown quality code and turn it into a parallel version of itself, even given that I do understand the problem space, the answer is most likely "you can't afford me", but if you can, then the answer is a question: "do you have time for me to design it and re-implement it?" At this point, your answer is my answer.
I didn't offer a "paper" -- I am not an academic -- nor did I contend that this knowledge is something that can be described in a few paragraphs from some ivory tower. I said that in order to succeed at it, you need to study until you get it. If you're a decent programmer, you can do it. That's not to say that I'm claiming any specific individual a decent programmer. Just that if you are, this is something you can do.
I wasn't sharing data. So execution order is irrelevant. :)
Only in a democracy. And I'd remind you, the US is not a democracy. It was supposed to be a constitutional republic, but turned into a corporate oligarchy instead. The one thing it is not is a democracy.
The mistake you make is in thinking these laws were (or should have been) passed for your benefit. They were not. They were passed to benefit the largest copyright holders, those that can afford to litigate. They do that very well.
The only way to get this to change is to change the system. Attacking the laws themselves involves a complete mis-focus, and will be roundly ignored by any representative in the system until or unless you can put more money and/or power in their hands than the large copyright holders can. Can you do that?
Honestly, you know what this says? This just says some programmers still need to go practice in the threading space.
Threading is not that hard at all for a VERY large class of problems. There are issues -- like, the memory bandwidth will eventually choke the ability of processors to get at nearby memory regions -- and you need some kind of sane plan to deal with cacheing in one core as compared to the next core when you share flags or data coming in during execution from elsewhere -- and you need to figure out when thread overhead starts to chew into your efficiencies -- but really, it's entirely doable, and isn't that difficult a problem space as compared to the actual problems *serious* programmers have to solve. It may just be that your "thing" isn't really all that threadable. Some things aren't. But it should also be very obvious when they aren't.
Then again, some problem spaces lend themselves very well to multiple core approaches -- I just finished a library that slices up images and then applies various separable algorithms to the slices in a variable number of threads (the user of the library can specify.) I wrote it in pure C, used posix threads, no sweat at all, in my 8-core machine, you get just about exactly the gains you'd think (x the number of cores) when the process is CPU cycle intensive, less as the ops are simpler and memory I/O rates rise.
Seriously. If threading seems that hard, you need to go do some studying. It's not the threading. It's you. You really should get on this bus.
Hah. I wish. :)
Well, perhaps, but not on this basis -- I can afford, and in fact own, lots of Apple gear. I think OSX 10.6 and earlier, before they hosed the multi-monitor support, is a great OS.
The original contention was that if one could not afford something, this would be disturbing. I don't find that to be the case at all, beyond a certain basic level. I was happy living with my cat and bookshelves made of planks, back in the day. I got my books from the used bookstore and I really felt like things were just fine. :)
Now I can afford more, and I in fact buy more, but it doesn't define my happiness, I assure you.