AMD has seen the writing on the wall: there is very little incentive to spend the money required to further the state of the art in x86. Intel is slowing down its development pace on x86 and AMD is as well; there simply isn't much money in making faster x86 processors because they have already achieved sufficient speed for 95% of what 95% of consumers do with x86 CPUs 95% of the time.
What would be the point of sinking huge funds into becoming more competitive in a market that is going to become increasingly irrelevant going forward? Mobile devices are the trend and x86 does not compete there. Aside from Intel, which has momentum built up that will take a little while to wind down, x86 development is in the process of stagnating. It's quite clear when major x86 CPU announcements are now years apart instead of less than a year like they used to be. This trend will continue.
Hope you are satisfied with the current crop of i7 processors because x86 is not going to get significantly faster, at least not at the consumer level.
AMD will instead focus on trying to compete in a segment of the x86 market that may remain relevant over the long term: SoCs for embedded applications. I think it's a smart move because it's the market that AMD has the best chance of being competive in.
I predict that the fastest x86 CPU will ever be made will be no more than 50% faster than the current fastest Core i7. Intel's development dollar momentum will carry us through to that but nobody, including Intel, is going to be willing to invest significantly more in x86.
> First, why not use the obvious countermeasure here. When you > create an encrypted volume, you should enter 2 keys, not > justone. One will unlock your drive, another will appear to unlock > your drive, but in fact deletes the contents of the disk entirely.
That would have to be built into the device. I can't take a normal device and make the above happen. For any normal hard drive or other storage mechanism, I would expect that the forensics people already know to read the raw data off of the device onto their own device (backing it up at the same time), and then they can operate on it using whatever program they want. There would be no way to force their program to delete the data or modify it in any way regardless of the decryption key you gave them. The program would produce exactly one of two results given any decryption key: successful decryption (you gave them the correct key), or unsuccessful decytpion (you gave them the wrong key).
The best you could do would be to have a form of ecryption that could somehow produce two different, meaningful sets of decrypted results given two different decryption keys. AFAIK there is no such cryptographic system in existence. It would be an incredible feat to be able to encrypt two sets of plaintext to the same ciphertext for which the original independent plaintexts could be recovered using two different decryption keys.
That being said, it would be a pretty awesome cryptography scheme that could do this from the perspective of allowing a user perfect secrecy with their data.
It sounds like you are trying to convince everyone, including yourself, that you were better off to choose a G2 over a G3.
There is no merit to your argument. The G3 bug you mentioned was real but it was fixed by Intel's firmware update, which is why you haven't heard anything about it.
There is nothing wrong with the G3 that would suggest that the G2 is a more reliable option. There is little to recommend the G3 over the G2 either, except price and availability.
I personally own two G2's, one G3, a real old skool PATA 32 GB SLC SSD from Mtron (perhaps the very first performant SSD), a cheap-o Kinston value series SSD, and a super duper cheap-o "SSDFactory" 32 GB PATA SSD direct from China that I bought because it was the only thing that would work in my ancient Panasonic Y2 laptop.
Not one of these drives has experienced any problem of any kind, and I've had some of them upwards of 2 years.
I would never buy an OCZ drive though. They are terrible.
You really should read something, anything before bothering to spend the time to post.
The 520 is faster at every metric (random read/write and sequential read/write) than the Intel controller based drives.
It also had a full year of vetting by Intel before being released, and they are putting the same 5 year warranty as their other drives; there is no reason to believe that it will not be as reliable as Intel controller based drives.
The only thing that doesn't compare favorably with this drive is the price.
Too bad. I really liked that place. Haven't lived in NYC for years but in the mid-2000's I like going to the Mott St. arcade. It was the last true arcade experience I ever had, and probably ever will have.
I was in Japan in 2001 and really enjoyed the great selection of really good arcades.
I looked forward to repeating this experience when I went back to Japan at the end of 2010 and unfortunately, it seemed that the arcades were all gone. Yes there were the pachinko machines and win-a-prize machines but the good arcades were all gone.
I disagreew with the poster's assertion that home consoles caught up to arcades in the late 80's and early 90's. In fact it wasn't until the PS2 in 2001-ish that home consoles became consistently as good as or better than arcade games.
R.I.P. arcades. They were a major part of my young life but they are gone now; nothing lasts forever.
I agree with you on the terrorism point. I really enjoyed the high speed rail in Japan the two times I visited there, and it would be awesome if we could have such a thing in the USA. I personally would rather spend 16 hours getting from coast to coast on a comfortable, clean, safe train than 6 on an airplane, but only if it really is safe. Japan has managed to run their high speed service for over 40 years without a single crash fatality (OK one unfortunate soul was killed after getting stuck in the doors once, but that was not due to a crash).
However, as I rode on the bullet train in Japan I just couldn't help think that if it were in the USA, it wouldn't take long for some mentally imbalanced person to spend a night welding some scrap metal to the tracks and then the first train of the new day would fly off the tracks in a spectacular and deadly crash. I honestly don't know why nobody has ever sabotaged the tracks in Japan (the group that released Sarin in the Tokyo subway surely would have had produced more devastating results if they'd sabotaged a Shinkansen line), but I feel pretty confident that it will happen in the USA if we ever get high speed trains.
If you think that all medical costs in the USA are not already being shared out among the whole population, then you are missing the most important point of the issue and should stop now and revisit your premises and redraw your conclusions.
The government *requires* that health care be provided to everybody - at least, a form of health care: emergency care; and since all health care, if left long enough, *becomes* emergency care eventually, just about everyone ends up costing *something* under this system.
This requirement is imposted on hospitals in a few ways:
1) They must accept all patients for emergency care where the patient's needs are serious or life threatening, until the patient is stabilized (and some never are, ending up in expensive intensive care), and which point they can ostensibly be transferred to a government-funded hospital, but even that can be very difficult as these hospitals push back very hard as their funding is very limited.
2) They must exercise every option, no matter how expensive, to save a patient's life, regardless of the circumstances, unless the patient has signed a document saying that they want to be allowed to die, and even then it can be difficult for the doctors to know if they can allow this to happen for fear of being sued. Patient's families are given the authority to decide whether to continue care for terminal patients, and since the cost to the families is nothing, they always ask for everything to be done. These costs are borne by everyone.
We're already paying for everything, just in the least efficient and least fair way possible.
"the reason why the medical system is broken in the USA is because of the terribly unhealthy advice we give for diet from the USDA"
False. I lived in New Zealand, where the obesity rates are comparable (maybe slightly less but not much so) than in the USA. Their national health care system worked just fine in these circumstances. It's true that the average cost to everyone was certainly higher because of people's poor personal health choices; but the costs were still reasonable.
Let me tell you the few things that were markedly different between the way things worked there and the way they work here (in the USA):
1. In New Zealand, the doctors focus on patient needs rather than on fights with insurance companies. My wife is a doctor and while working in New Zealand she spent 100% of her day with patients (well, as close as 100% as is possible in any job). Here in the USA she spends a *considerable* chunk of her time every day fighting with insurance companies (directly on the phone, or by proxy via stupid policies that she has to adhere to). This is a *cost* to the system because doctors are being paid a certain percentage of their very expensive time in the USA to deal with stuff that shouldn't even be a question, or at least wouldn't be in a national health care system.
2. Doctors are respected in New Zealand and are treated with respect, much more so than in the USA. There are probably lots of reasons for this, but I think that part of it is expectation that people in the USA have that doctors should do whatever they want them to because they (the patient) are *paying* for the services (via their insurance costs). Doctors are happier and more effective when there is some respect for their knowledge and skill; it's easier to treat patients correctly when they *listen* to the doctor because the doctor has some authority, than when the patients potentially ignore doctor advice - or are even downright hostile to it.
3. The hospital sytem in New Zealand is set up to effectively and efficiently care for patients of different needs because it's all managed and costs and needs can be anticipated ahead of time. Here in the USA my wife is constantly complaining about all of the stupid and time-(and MONEY-)wasting patient shuffling they have to do. She works at a private hospital and thus they have to (by law) accept any patient that walks in the emergency room, even if that patient can't pay. The government supposedly provides county hospitals that will take these patients once they are in stable condition for transfer, but in practice the county hospitals are not funded well enough and so they fight to take as few patients as possible. So you end up with all of this fighting between hospitals to try to offload 'deadbeat' patients to each other. All of this is overhead for the system and is just totally a waste. The private hospital ends up having to milk as much as it can from paying patients to make up for the deadbeats. So you end up with even more inefficiency because they have to have policies in place that make them the most money - for example, routinely running tests that may not actually be called for in all cases - just to balance out non-payers. So they end up doing 'busywork' (unnecessary tests) just so that they can get paid for something, which once again sucks a certain percentage of their productivity away.
4. Doctors in New Zealand actually have authority over end-of-life decisions. Which means that when a 90 year old patient with severe dementia, no contact with reality, living only in the pain of end stage cancer and with no hope of survival, starts bleeding uncontrollably, the doctor in New Zealand can actually make the decision to allow the patient to die. In the USA this decision can *only* be made by the patient's family, who will, of course, ask for no expense to be spared in saving the life of their loved one. This easy for them because there is no actual expense *to them*, just to 'the system'. So in the USA you have a system where the people m
I lived in New Zealand for two years and my wife was a doctor in a hospital there (my son was born there - Waikato Hospital in Hamilton). I can say without any reservation that the sytem there was far and away better than the health care system of the USA. It's true that it wasn't quite as 'polished', but as you point out, this polish is paid for by users and exists only because polish helps sell the product. What it was, was more humane and more reasonable. My wife, as a doctor, was able to focus on patient needs instead of fighting insurance companies and she LOVED IT. She literally hates working here in the USA, and I feel really badly about that, and sometimes think that we should have stayed in New Zealand (however, you'll find if you ever live there that it's REALLY FAR from your friends and family in the USA; which for some people maybe is a benefit, but wasn't for us).
I thought it was really interesting that all medical accidents, whatever the reason, and for all people, regardless of whether they are a citizen or visitor, are completely covered by their health care system. So if you are travelling in New Zealand and fall and break your arm - no problem, it's covered by the government. Which really means, it's covered by the people of New Zealand who realize that it is the most civilized way to treat themselves and those visiting them from overseas.
What my wife and I concluded after living in their system for 2+ years was that, while it is not perfect, it is just tremendously better in just about every way than the USA health care system. It's true that NZ pay slightly higher taxes than the USA does (although when you add up the various taxes in the USA at the local, state, and federal level, there really isn't a tremendous difference with the NZ single national tax), but what they GET for their money is so much more worthwhile, such as: a working national health care system; free child development services (Plunket); and reasonable and fair retirement, among other things. Oh and when tax time comes around, they'll call you on the phone to see if you need help doing your taxes (which you won't, because their tax forms are ridiculously simple compared to those in the USA).
Unfortunately, political discussion in the USA is so ruled by hysteria and partisanship that no good public policy will ever occur here; it is simply impossible for the system of government that we have in the USA to effectively and fairly govern its citizenship anymore. The USA is on its way down, and it will not recover. Mark my words. I wish it weren't true, but it is.
Actually, I don't really like rolling releases, but I tolerate it because it's what Arch Linux uses. I prefer Arch Linux's extreme simplicity over Debian's incredible complexity which is why I use it. Just having to keep track of the 10 programs you need to just manage packages on Debian gives me migraines, not to mention the convoluted system configuration setup on Debian. Arch Linux is *dead* simple which is why I use it. The shortfalls of Arch Linux are:
- Rolling releases with little support for choosing package versions - As a result of the previous, if you want to install software that you don't happen to have, you often have to upgrade a whole bunch of stuff because the only version available from the servers will be the newest version which probably has dependencies on half your system - Packages that break/have bugs *much* more frequently than on other systems - It's x86/x86_64 only, which is the biggest shortcoming for me
But the positives of Arch Linux far outweigh the negatives so I choose it whenever I can.
I use SSDs exclusively (will never buy a spinner platter drive again) and I would prefer if the old packages were hosted on a server somewhere instead of having to be cached on my drive. Seems more efficient to me for 12 GB on a server to serve hundreds of thousands of users than for each of those users to have to spend 12 GB to cache their own packages.
That being said, I have never deleted anything from my pacman package cache so I could probably use the technique that you described. There are cases where even that is not sufficient (for example, if I want to install on a new computer and want to use an older package version because I know that I have a problem with a newer version) but those are less frequent problems. To be honest, I never even realized that using pacman to downgrade via the local package cache was an encouraged, or reliable, option, but if you're saying it is, then I believe you.
My distribution of choice, Arch Linux, uses a rolling release schedule, which has its good and bad points. I suppose the worst part of it is that with Arch Linux, old versions of software are not retained in the repositories and the package management tools don't make it easy to go back to a prior version of the software in the event of a problem. As a result, upgrading is a bit of a 'cross your fingers' endeavor and more often than not, I've regretted a full system upgrade.
I think that rolling release can work well but only if the package management system is designed to, and the repositories are set up to, allow easy rolling forward and backward on software versions as necessary. It's my number one wish for Arch Linux, which otherwise is the best distribution I've used.
Knowing what files a program will open without running the program is impossible, and since a program can dynamically change what files it opens from run to run, it would be impossible to predict every file that a program would require in all situations. The best that a tool like this could do would be to record the files that were used during a given run of the program and assuming that the program when run later with the same inputs would use the same files, support running the program with exactly those inputs.
I don't think you could reliably package up many programs in this way for general use, but maybe you could package up a program for a specific task like producing a reproducible bug report. But that is of little utility as most distributions that you would run a program on and need to submit a bug report are fairly easily reproduced anyway and the developer probably would have an easier time just reproducing the bug on their own system without fussing with some packaged up binary that the bug submitter sent in.
This honestly seems like a wrapper around "strace | grep ^open". If this is what it takes to be a researcher at Stanford these days then sign me up!
Well I think the entire thing is bullshit but... if you buy what this guy is saying then you could theoretically transfer huge amounts of energy with no losses except those experienced by the very small radio signal that encodes the information necessary to make the measurements. Assuming that you don't require "as much" radio signal as you do "transmitted energy", then this is a much more efficient way to transmit energy than if the entire process was done just by radio signals (or other non-spooky means).
If your entire point revolves around a semantic quibble about the meanings of the word 'need' versus 'want', then I've got nothing left to say, as this sort of argument is worthless.
Give it up man. Your points are inherently biased by your own cost:performance:size relationship values. Saying that SSDs have no value to anyone because they don't fit your own usage models is just RETARDED. I'm not even going to explain to you my usage models, or the other usage models like mine, for which an SSD has proven to be a very nice, and well worthwhile, upgrade, worth every penny. I'm not going to explain it because it's not necessary for me to use examples to make the very simple point that I am making: not everybody wants the same thing you do, so stop with the ridiculous generalizations and RETARDED references to "e-peen", which is just about the most juvenile phrase I have read in quite a long time.
I agree with you; however, I watched the whole thing, and I am glad that I did. It was quite insightful and interesting. It had some amount of stupid psycho killer stuff in there too, and much of the time, I wished I could read it instead of listen to it (or at least hear it narrated by someone not so painful to listen to), but nonetheless, the content was so excellent, that it was worth it.
OK, so I *almost* gave up after about 5 minutes, because the dude's voice was so terrible to listen to. And the interjections of the creepy "the narrator is a psycho killer" stuff turned me off; they were funny in a few spots but overall, I would definitely have cut them. However, the content was *incredible*. I am glad I continued to watch because in the end it was really excellent, and so spot on.
I think it would have been better though if it was voiced by someone who spoke more intelligently and understandably, with a much wittier delivery. I just started watching the MMO report recently, I can't remember the name of that guy, but he would be the perfect guy to do that video.
My conclusion: excellent video, would have been over the top with a better narrator and without the mostly stupid psycho killer interludes.
True, but as with everything legal (in my very limited understanding), it's all about what leverage you feel you have as a result of your actions. The larger the value of the code base in question, the more significant the risk of "taking ideas instead of code", because you are risking more should you end up losing a lawsuit from someone whose ideas you used. Correspondingly, how much time and effort is a person who has contributed a very small amount of time to sending a patch going to invest in suing you for the $50 you *might* owe them, depending on whether or not you actually are obligated to give them anything at all? When it comes to legal matters, the more money involved, the sharper the distinctions become, because people are more motivated to slice things as finely as they can to get the maximum allowed under law. When the sums are so meager, the legal truth is pretty much whatever you want it to be, because nobody will bother to challenge you.
All that being said, I truly believe that I haven't done anything legally or morally wrong by taking ideas instead of code, so I'm not worried about it, even given that nobody would bother to sue me over this because the amount of money involved is so small. However, I'm a reasonably generous person, and I probably ought to look up the old emails of those people who contributed a fix, and paypal them $20 each...
Yeah sorry, obviously I overgeneralized because not everyone wants the same things; I was assuming that a developer would want to get back what they could when and if they could, but if you truly don't care, then you could use BSD. Although, in that situation, you might want to just release into the public domain, which makes it even easier for others to use your code.
That being said, I don't understand what logical reason someone would have for wanting to give away the fruits of their efforts without at least requiring that those who take them give back if they make improvements or additions. The GPL is a way to share only with people who will either share back with you, or will pay you (for another license). Why do you want to share with people who are going to take your code and incorporate it in their own product which they sell for a profit that they won't share with you? Seriously, what is the upside for you?
I can think of only two reasons: 1) too lazy to want to deal with licensing issues, especially if it ever came to actually having to enforce a license, so just wanting to release under a license that pretty much guarantees that you'd never have anything to dispute anyway, or 2) the ego stroke of thinking that you're such a great person for giving your stuff away for free to anyone who wants it, under the belief that releasing it without restriction is so much more manganamous that it makes the act of giving it away that much more generous? Something along the lines of "I'm such a great person, look, I'm giving my stuff away for free to anyone who wants it, and I'm not even going to worry about someone making a profit off of my work! I'm just so generous, *yay me*!!!"?
That is a good point. In practice, however, I find that most people will send you their improvements/fixes; it is not hard to do so and most people enjoy contributing back. If it was a company producing a product based on your project, however, there is probably a higher likelihood that they wouldn't bother, and that you might have to even buy one of their products (assuming you even knew they were selling them) to get the source.
I was the sole author, so that wasn't an issue. This is why I tried to preface my statements by saying that they applied to individual developers; if you are part of a group, then you will have to get agreement from everyone for this kind of licensing, and that is alot harder.
You bring up a good point though. I have had the odd bug fix submitted back to me. But I have not taken patches directly. I have instead examined them to understand the bug and then did my own fix. This is so that I can retain sole copyright on the code, so that I don't have to worry about the issue you mentioned. Now if someone ever made significant contributions to the library, I'd have to consider whether to take them and share copyright, or refuse to take them and instead require that other someone to fork the project to include their modifications.
It is a pragmatic matter; I estimated that I spent about 120 hours of my own time to produce the library (actually it took somewhat longer, but I tried to condense it down to the minimum number of hours that it would have taken had I been perfectly focused, perfectly productive, and made little or no mistakes for the entire time), and that is the value that I use when negotiating licensing fees for the library. If someone else comes along and spends 30 minutes to find and fix a bug, should I give up my ability to freely license my 120 hours of effort for that fix? Thus far I have decided no. That being said, I have often thought that I ought to send some money to those few individuals who have discovered bugs and reported them to me, since I did benefit financially from their efforts...
Have you correlated the responses of specific posters here who are in support of copyright enforcement for GPL with their responses to other topics where the copyrights were held by the MPAA/RIAA/whatever? And have you then determined how many of these posters have differing opinions on copyright infringement depending on who the copyright holder is?
If not, you're just lumping everyone together and making a generalization that fits your own personal gripe, with no basis whatsoever.
If you have, then you should be talking to those people specifically, rather than trying to criticize the "slashdot crowd", which is a pretty pathetic windmill to tilt at really...
Slashdot Mirror
AMD has seen the writing on the wall: there is very little incentive to spend the money required to further the state of the art in x86. Intel is slowing down its development pace on x86 and AMD is as well; there simply isn't much money in making faster x86 processors because they have already achieved sufficient speed for 95% of what 95% of consumers do with x86 CPUs 95% of the time.
What would be the point of sinking huge funds into becoming more competitive in a market that is going to become increasingly irrelevant going forward? Mobile devices are the trend and x86 does not compete there. Aside from Intel, which has momentum built up that will take a little while to wind down, x86 development is in the process of stagnating. It's quite clear when major x86 CPU announcements are now years apart instead of less than a year like they used to be. This trend will continue.
Hope you are satisfied with the current crop of i7 processors because x86 is not going to get significantly faster, at least not at the consumer level.
AMD will instead focus on trying to compete in a segment of the x86 market that may remain relevant over the long term: SoCs for embedded applications. I think it's a smart move because it's the market that AMD has the best chance of being competive in.
I predict that the fastest x86 CPU will ever be made will be no more than 50% faster than the current fastest Core i7. Intel's development dollar momentum will carry us through to that but nobody, including Intel, is going to be willing to invest significantly more in x86.
> First, why not use the obvious countermeasure here. When you
> create an encrypted volume, you should enter 2 keys, not
> justone. One will unlock your drive, another will appear to unlock
> your drive, but in fact deletes the contents of the disk entirely.
That would have to be built into the device. I can't take a normal device and make the above happen. For any normal hard drive or other storage mechanism, I would expect that the forensics people already know to read the raw data off of the device onto their own device (backing it up at the same time), and then they can operate on it using whatever program they want. There would be no way to force their program to delete the data or modify it in any way regardless of the decryption key you gave them. The program would produce exactly one of two results given any decryption key: successful decryption (you gave them the correct key), or unsuccessful decytpion (you gave them the wrong key).
The best you could do would be to have a form of ecryption that could somehow produce two different, meaningful sets of decrypted results given two different decryption keys. AFAIK there is no such cryptographic system in existence. It would be an incredible feat to be able to encrypt two sets of plaintext to the same ciphertext for which the original independent plaintexts could be recovered using two different decryption keys.
That being said, it would be a pretty awesome cryptography scheme that could do this from the perspective of allowing a user perfect secrecy with their data.
It sounds like you are trying to convince everyone, including yourself, that you were better off to choose a G2 over a G3.
There is no merit to your argument. The G3 bug you mentioned was real but it was fixed by Intel's firmware update, which is why you haven't heard anything about it.
There is nothing wrong with the G3 that would suggest that the G2 is a more reliable option. There is little to recommend the G3 over the G2 either, except price and availability.
I personally own two G2's, one G3, a real old skool PATA 32 GB SLC SSD from Mtron (perhaps the very first performant SSD), a cheap-o Kinston value series SSD, and a super duper cheap-o "SSDFactory" 32 GB PATA SSD direct from China that I bought because it was the only thing that would work in my ancient Panasonic Y2 laptop.
Not one of these drives has experienced any problem of any kind, and I've had some of them upwards of 2 years.
I would never buy an OCZ drive though. They are terrible.
You really should read something, anything before bothering to spend the time to post.
The 520 is faster at every metric (random read/write and sequential read/write) than the Intel controller based drives.
It also had a full year of vetting by Intel before being released, and they are putting the same 5 year warranty as their other drives; there is no reason to believe that it will not be as reliable as Intel controller based drives.
The only thing that doesn't compare favorably with this drive is the price.
Wrong. It is consoles that killed the arcade, PERIOD. You do not need to look any further than that.
Is this really true?
Too bad. I really liked that place. Haven't lived in NYC for years but in the mid-2000's I like going to the Mott St. arcade. It was the last true arcade experience I ever had, and probably ever will have.
I was in Japan in 2001 and really enjoyed the great selection of really good arcades.
I looked forward to repeating this experience when I went back to Japan at the end of 2010 and unfortunately, it seemed that the arcades were all gone. Yes there were the pachinko machines and win-a-prize machines but the good arcades were all gone.
I disagreew with the poster's assertion that home consoles caught up to arcades in the late 80's and early 90's. In fact it wasn't until the PS2 in 2001-ish that home consoles became consistently as good as or better than arcade games.
R.I.P. arcades. They were a major part of my young life but they are gone now; nothing lasts forever.
I agree with you on the terrorism point. I really enjoyed the high speed rail in Japan the two times I visited there, and it would be awesome if we could have such a thing in the USA. I personally would rather spend 16 hours getting from coast to coast on a comfortable, clean, safe train than 6 on an airplane, but only if it really is safe. Japan has managed to run their high speed service for over 40 years without a single crash fatality (OK one unfortunate soul was killed after getting stuck in the doors once, but that was not due to a crash).
However, as I rode on the bullet train in Japan I just couldn't help think that if it were in the USA, it wouldn't take long for some mentally imbalanced person to spend a night welding some scrap metal to the tracks and then the first train of the new day would fly off the tracks in a spectacular and deadly crash. I honestly don't know why nobody has ever sabotaged the tracks in Japan (the group that released Sarin in the Tokyo subway surely would have had produced more devastating results if they'd sabotaged a Shinkansen line), but I feel pretty confident that it will happen in the USA if we ever get high speed trains.
Sad but true.
If you think that all medical costs in the USA are not already being shared out among the whole population, then you are missing the most important point of the issue and should stop now and revisit your premises and redraw your conclusions.
The government *requires* that health care be provided to everybody - at least, a form of health care: emergency care; and since all health care, if left long enough, *becomes* emergency care eventually, just about everyone ends up costing *something* under this system.
This requirement is imposted on hospitals in a few ways:
1) They must accept all patients for emergency care where the patient's needs are serious or life threatening, until the patient is stabilized (and some never are, ending up in expensive intensive care), and which point they can ostensibly be transferred to a government-funded hospital, but even that can be very difficult as these hospitals push back very hard as their funding is very limited.
2) They must exercise every option, no matter how expensive, to save a patient's life, regardless of the circumstances, unless the patient has signed a document saying that they want to be allowed to die, and even then it can be difficult for the doctors to know if they can allow this to happen for fear of being sued. Patient's families are given the authority to decide whether to continue care for terminal patients, and since the cost to the families is nothing, they always ask for everything to be done. These costs are borne by everyone.
We're already paying for everything, just in the least efficient and least fair way possible.
"the reason why the medical system is broken in the USA is because of the terribly unhealthy advice we give for diet from the USDA"
False. I lived in New Zealand, where the obesity rates are comparable (maybe slightly less but not much so) than in the USA. Their national health care system worked just fine in these circumstances. It's true that the average cost to everyone was certainly higher because of people's poor personal health choices; but the costs were still reasonable.
Let me tell you the few things that were markedly different between the way things worked there and the way they work here (in the USA):
1. In New Zealand, the doctors focus on patient needs rather than on fights with insurance companies. My wife is a doctor and while working in New Zealand she spent 100% of her day with patients (well, as close as 100% as is possible in any job). Here in the USA she spends a *considerable* chunk of her time every day fighting with insurance companies (directly on the phone, or by proxy via stupid policies that she has to adhere to). This is a *cost* to the system because doctors are being paid a certain percentage of their very expensive time in the USA to deal with stuff that shouldn't even be a question, or at least wouldn't be in a national health care system.
2. Doctors are respected in New Zealand and are treated with respect, much more so than in the USA. There are probably lots of reasons for this, but I think that part of it is expectation that people in the USA have that doctors should do whatever they want them to because they (the patient) are *paying* for the services (via their insurance costs). Doctors are happier and more effective when there is some respect for their knowledge and skill; it's easier to treat patients correctly when they *listen* to the doctor because the doctor has some authority, than when the patients potentially ignore doctor advice - or are even downright hostile to it.
3. The hospital sytem in New Zealand is set up to effectively and efficiently care for patients of different needs because it's all managed and costs and needs can be anticipated ahead of time. Here in the USA my wife is constantly complaining about all of the stupid and time-(and MONEY-)wasting patient shuffling they have to do. She works at a private hospital and thus they have to (by law) accept any patient that walks in the emergency room, even if that patient can't pay. The government supposedly provides county hospitals that will take these patients once they are in stable condition for transfer, but in practice the county hospitals are not funded well enough and so they fight to take as few patients as possible. So you end up with all of this fighting between hospitals to try to offload 'deadbeat' patients to each other. All of this is overhead for the system and is just totally a waste. The private hospital ends up having to milk as much as it can from paying patients to make up for the deadbeats. So you end up with even more inefficiency because they have to have policies in place that make them the most money - for example, routinely running tests that may not actually be called for in all cases - just to balance out non-payers. So they end up doing 'busywork' (unnecessary tests) just so that they can get paid for something, which once again sucks a certain percentage of their productivity away.
4. Doctors in New Zealand actually have authority over end-of-life decisions. Which means that when a 90 year old patient with severe dementia, no contact with reality, living only in the pain of end stage cancer and with no hope of survival, starts bleeding uncontrollably, the doctor in New Zealand can actually make the decision to allow the patient to die. In the USA this decision can *only* be made by the patient's family, who will, of course, ask for no expense to be spared in saving the life of their loved one. This easy for them because there is no actual expense *to them*, just to 'the system'. So in the USA you have a system where the people m
I lived in New Zealand for two years and my wife was a doctor in a hospital there (my son was born there - Waikato Hospital in Hamilton). I can say without any reservation that the sytem there was far and away better than the health care system of the USA. It's true that it wasn't quite as 'polished', but as you point out, this polish is paid for by users and exists only because polish helps sell the product. What it was, was more humane and more reasonable. My wife, as a doctor, was able to focus on patient needs instead of fighting insurance companies and she LOVED IT. She literally hates working here in the USA, and I feel really badly about that, and sometimes think that we should have stayed in New Zealand (however, you'll find if you ever live there that it's REALLY FAR from your friends and family in the USA; which for some people maybe is a benefit, but wasn't for us).
I thought it was really interesting that all medical accidents, whatever the reason, and for all people, regardless of whether they are a citizen or visitor, are completely covered by their health care system. So if you are travelling in New Zealand and fall and break your arm - no problem, it's covered by the government. Which really means, it's covered by the people of New Zealand who realize that it is the most civilized way to treat themselves and those visiting them from overseas.
What my wife and I concluded after living in their system for 2+ years was that, while it is not perfect, it is just tremendously better in just about every way than the USA health care system. It's true that NZ pay slightly higher taxes than the USA does (although when you add up the various taxes in the USA at the local, state, and federal level, there really isn't a tremendous difference with the NZ single national tax), but what they GET for their money is so much more worthwhile, such as: a working national health care system; free child development services (Plunket); and reasonable and fair retirement, among other things. Oh and when tax time comes around, they'll call you on the phone to see if you need help doing your taxes (which you won't, because their tax forms are ridiculously simple compared to those in the USA).
Unfortunately, political discussion in the USA is so ruled by hysteria and partisanship that no good public policy will ever occur here; it is simply impossible for the system of government that we have in the USA to effectively and fairly govern its citizenship anymore. The USA is on its way down, and it will not recover. Mark my words. I wish it weren't true, but it is.
Actually, I don't really like rolling releases, but I tolerate it because it's what Arch Linux uses. I prefer Arch Linux's extreme simplicity over Debian's incredible complexity which is why I use it. Just having to keep track of the 10 programs you need to just manage packages on Debian gives me migraines, not to mention the convoluted system configuration setup on Debian. Arch Linux is *dead* simple which is why I use it. The shortfalls of Arch Linux are:
- Rolling releases with little support for choosing package versions
- As a result of the previous, if you want to install software that you don't happen to have, you often have to upgrade a whole bunch of stuff because the only version available from the servers will be the newest version which probably has dependencies on half your system
- Packages that break/have bugs *much* more frequently than on other systems
- It's x86/x86_64 only, which is the biggest shortcoming for me
But the positives of Arch Linux far outweigh the negatives so I choose it whenever I can.
I use SSDs exclusively (will never buy a spinner platter drive again) and I would prefer if the old packages were hosted on a server somewhere instead of having to be cached on my drive. Seems more efficient to me for 12 GB on a server to serve hundreds of thousands of users than for each of those users to have to spend 12 GB to cache their own packages.
That being said, I have never deleted anything from my pacman package cache so I could probably use the technique that you described. There are cases where even that is not sufficient (for example, if I want to install on a new computer and want to use an older package version because I know that I have a problem with a newer version) but those are less frequent problems. To be honest, I never even realized that using pacman to downgrade via the local package cache was an encouraged, or reliable, option, but if you're saying it is, then I believe you.
My distribution of choice, Arch Linux, uses a rolling release schedule, which has its good and bad points. I suppose the worst part of it is that with Arch Linux, old versions of software are not retained in the repositories and the package management tools don't make it easy to go back to a prior version of the software in the event of a problem. As a result, upgrading is a bit of a 'cross your fingers' endeavor and more often than not, I've regretted a full system upgrade.
I think that rolling release can work well but only if the package management system is designed to, and the repositories are set up to, allow easy rolling forward and backward on software versions as necessary. It's my number one wish for Arch Linux, which otherwise is the best distribution I've used.
Knowing what files a program will open without running the program is impossible, and since a program can dynamically change what files it opens from run to run, it would be impossible to predict every file that a program would require in all situations. The best that a tool like this could do would be to record the files that were used during a given run of the program and assuming that the program when run later with the same inputs would use the same files, support running the program with exactly those inputs.
I don't think you could reliably package up many programs in this way for general use, but maybe you could package up a program for a specific task like producing a reproducible bug report. But that is of little utility as most distributions that you would run a program on and need to submit a bug report are fairly easily reproduced anyway and the developer probably would have an easier time just reproducing the bug on their own system without fussing with some packaged up binary that the bug submitter sent in.
This honestly seems like a wrapper around "strace | grep ^open". If this is what it takes to be a researcher at Stanford these days then sign me up!
Well I think the entire thing is bullshit but ... if you buy what this guy is saying then you could theoretically transfer huge amounts of energy with no losses except those experienced by the very small radio signal that encodes the information necessary to make the measurements. Assuming that you don't require "as much" radio signal as you do "transmitted energy", then this is a much more efficient way to transmit energy than if the entire process was done just by radio signals (or other non-spooky means).
If your entire point revolves around a semantic quibble about the meanings of the word 'need' versus 'want', then I've got nothing left to say, as this sort of argument is worthless.
Give it up man. Your points are inherently biased by your own cost:performance:size relationship values. Saying that SSDs have no value to anyone because they don't fit your own usage models is just RETARDED. I'm not even going to explain to you my usage models, or the other usage models like mine, for which an SSD has proven to be a very nice, and well worthwhile, upgrade, worth every penny. I'm not going to explain it because it's not necessary for me to use examples to make the very simple point that I am making: not everybody wants the same thing you do, so stop with the ridiculous generalizations and RETARDED references to "e-peen", which is just about the most juvenile phrase I have read in quite a long time.
I agree with you; however, I watched the whole thing, and I am glad that I did. It was quite insightful and interesting. It had some amount of stupid psycho killer stuff in there too, and much of the time, I wished I could read it instead of listen to it (or at least hear it narrated by someone not so painful to listen to), but nonetheless, the content was so excellent, that it was worth it.
OK, so I *almost* gave up after about 5 minutes, because the dude's voice was so terrible to listen to. And the interjections of the creepy "the narrator is a psycho killer" stuff turned me off; they were funny in a few spots but overall, I would definitely have cut them. However, the content was *incredible*. I am glad I continued to watch because in the end it was really excellent, and so spot on.
I think it would have been better though if it was voiced by someone who spoke more intelligently and understandably, with a much wittier delivery. I just started watching the MMO report recently, I can't remember the name of that guy, but he would be the perfect guy to do that video.
My conclusion: excellent video, would have been over the top with a better narrator and without the mostly stupid psycho killer interludes.
True, but as with everything legal (in my very limited understanding), it's all about what leverage you feel you have as a result of your actions. The larger the value of the code base in question, the more significant the risk of "taking ideas instead of code", because you are risking more should you end up losing a lawsuit from someone whose ideas you used. Correspondingly, how much time and effort is a person who has contributed a very small amount of time to sending a patch going to invest in suing you for the $50 you *might* owe them, depending on whether or not you actually are obligated to give them anything at all? When it comes to legal matters, the more money involved, the sharper the distinctions become, because people are more motivated to slice things as finely as they can to get the maximum allowed under law. When the sums are so meager, the legal truth is pretty much whatever you want it to be, because nobody will bother to challenge you.
All that being said, I truly believe that I haven't done anything legally or morally wrong by taking ideas instead of code, so I'm not worried about it, even given that nobody would bother to sue me over this because the amount of money involved is so small. However, I'm a reasonably generous person, and I probably ought to look up the old emails of those people who contributed a fix, and paypal them $20 each ...
Yeah sorry, obviously I overgeneralized because not everyone wants the same things; I was assuming that a developer would want to get back what they could when and if they could, but if you truly don't care, then you could use BSD. Although, in that situation, you might want to just release into the public domain, which makes it even easier for others to use your code.
That being said, I don't understand what logical reason someone would have for wanting to give away the fruits of their efforts without at least requiring that those who take them give back if they make improvements or additions. The GPL is a way to share only with people who will either share back with you, or will pay you (for another license). Why do you want to share with people who are going to take your code and incorporate it in their own product which they sell for a profit that they won't share with you? Seriously, what is the upside for you?
I can think of only two reasons: 1) too lazy to want to deal with licensing issues, especially if it ever came to actually having to enforce a license, so just wanting to release under a license that pretty much guarantees that you'd never have anything to dispute anyway, or 2) the ego stroke of thinking that you're such a great person for giving your stuff away for free to anyone who wants it, under the belief that releasing it without restriction is so much more manganamous that it makes the act of giving it away that much more generous? Something along the lines of "I'm such a great person, look, I'm giving my stuff away for free to anyone who wants it, and I'm not even going to worry about someone making a profit off of my work! I'm just so generous, *yay me*!!!"?
That is a good point. In practice, however, I find that most people will send you their improvements/fixes; it is not hard to do so and most people enjoy contributing back. If it was a company producing a product based on your project, however, there is probably a higher likelihood that they wouldn't bother, and that you might have to even buy one of their products (assuming you even knew they were selling them) to get the source.
I was the sole author, so that wasn't an issue. This is why I tried to preface my statements by saying that they applied to individual developers; if you are part of a group, then you will have to get agreement from everyone for this kind of licensing, and that is alot harder.
You bring up a good point though. I have had the odd bug fix submitted back to me. But I have not taken patches directly. I have instead examined them to understand the bug and then did my own fix. This is so that I can retain sole copyright on the code, so that I don't have to worry about the issue you mentioned. Now if someone ever made significant contributions to the library, I'd have to consider whether to take them and share copyright, or refuse to take them and instead require that other someone to fork the project to include their modifications.
It is a pragmatic matter; I estimated that I spent about 120 hours of my own time to produce the library (actually it took somewhat longer, but I tried to condense it down to the minimum number of hours that it would have taken had I been perfectly focused, perfectly productive, and made little or no mistakes for the entire time), and that is the value that I use when negotiating licensing fees for the library. If someone else comes along and spends 30 minutes to find and fix a bug, should I give up my ability to freely license my 120 hours of effort for that fix? Thus far I have decided no. That being said, I have often thought that I ought to send some money to those few individuals who have discovered bugs and reported them to me, since I did benefit financially from their efforts ...
Have you correlated the responses of specific posters here who are in support of copyright enforcement for GPL with their responses to other topics where the copyrights were held by the MPAA/RIAA/whatever? And have you then determined how many of these posters have differing opinions on copyright infringement depending on who the copyright holder is?
If not, you're just lumping everyone together and making a generalization that fits your own personal gripe, with no basis whatsoever.
If you have, then you should be talking to those people specifically, rather than trying to criticize the "slashdot crowd", which is a pretty pathetic windmill to tilt at really ...