RedHat (current owner of Cygnus) has made a successful business providing high quality support for FOSS software, and I think that's great! However, the $1T estimate seems like it might just be a tad biased and perhaps ignoring some hidden costs, but I can't tell from the FA because it just references the figure without any details for the estimate.
It does provide a link to the paper that is the source of the estimate, but I suppose clicking the link would be too much to ask.
Range Voting seems to alleviate the problem of strategic voting.
No, it doesn't. "Range voting" (aka "Average Rating Voting") is subject to strategic voting (for the strategies that apply, see here.) Further, the Gibbard-Satterthwaite Theorem proves that the only way any single-winner system could eliminate strategic voting would either be to be dictatorial or to up-front prohibit certain candidates from winning regardless of the votes.
Range voting has the additional problem (compared either to choose-one systems like majority-runoff or plurality or to ranked ballots systems in general) that the meaning of the same marking on different voters ballots isn't the same (What does a 50 out of 100 maximum ranking mean?) Approval voting, a somewhat more popular, "weaker" form of range voting in which there are only two ratings ("acceptable" and "not acceptable", in essence) available, has the same problem, though somewhat weaker.
If the vote is to reflect public opinion, people should vote their own opinion. They don't need to try to help the system by guessing the most popular option.
Sure, in an unattainably perfect world with perfect election systems, this would be true. However, one most note that its impossible to have a single-winner voting system where more than two candidates stand for election where strategic voting is not rewarded if voting actually matters at all.
In the real world, strategic voting which takes into account the preferences and likely behavior of other voters, assuming it is based on accurate information, produces better results than blindly voting your own true preferences.
Even ignoring the incentives for strategic voting, though, there is a cost benefit analysis in pre-voting activities which effect the success of candidates and ballot propositions -- even if a person believes something is a good idea and plans to vote for it, they are far less likely to expend resources (whether by donations of money or of time and effort) if they feel that those resources are unlikely to make a difference in the outcome.
So, ultimately, there are good reasons why people's understanding of the popularity of a political idea or candidate affects their behavior regarding that idea or candidate.
Yeah, I thought a lot of these were of questionable "greater good," and seemed more like things that organized govt should be doing on its own anyhow.
All concepts of the "good" are subjective and, consequently, "questionable", and most philanthropy is something that the people doing it would agree that organized government should be doing, but is not.
According to this website (in the bar on the right), $49 in 1979 is the same as $143.90 in today's dollars or $49 is $16.69 in 1979 dollars. The price has actually come down in terms of real dollars. But, that's what the economists say. They're also saying the economy is getting better and we should be happy.
Some economists are saying that there are high-level leading indicators that the economy is pulling out of a recession.
And even most of those that are saying that aren't saying "we should be happy"; quite a lot of economists (though far less of the people that report on the economy in the media) know that aggregate improvements in the economy don't necessarily mean most people are experiencing better conditions (I suspect that economists are the profession most likely to be aware that even during an economic expansion, its quite likely to see the conditions for most people get worse while the benefits all go to a very small elite; indeed, they are also probably the group most likely to be aware that there is evidence that that is what occurred in the expansion preceding the current recession.)
Then the Puppy came to my team. As the lead, I encouraged him to write unit tests. Those soon grew to epic proportions. I was buried in a sea of special one off requests from upper management for a period of two-three weeks and kept my eye off of him. When I finally could take a breather and get back into the swing of thing, I discovered mountains of tests - it was all he had written. No implementations!
Then requirements change as they often do. About a third of the tests were rendered useless do to the changes. Now, I still run my unit tests from time to time, but I am a little leery of putting that much time in to testing when the situation can be so volatile. And I have to keep a closer eye on the Puppy.
This is why there is, in agile methodologies (or at least the descriptions I've seen of them, there's a whole lot that passes under that name) the usual recommendation is write a unit test, write the code to make it pass, rinse, repeat./b
Shipping is easy. Any idiot can whip something together that solves a problem, ships on time etc.
Given the number of times I've seen major pieces of software that neither shipped on time nor solved the problems the customer really wanted solved, I would contend that, in fact, "any idiot" cannot do that, and that, furthermore, it is often the case groups of individually talented people fail to do that.
I've always viewed multiple inheritance as the hallmark of duct-tape programming. Being (correctly) forced to do single inheritance forces you to do proper architecture (but not architecture for architecture's sake), abstraction (within reason), and seriously think about the structure of your program.
Its quite possible to do duct-tape programming in languages that force single inheritance, and its quite possible to architect things well in languages that feature multiple inheritance. (Even resulting in designs that use multiple inheritance.)
Its also possible to do both in languages that don't feature inheritance at all (because, e.g., they don't use class-based OOP as a their main paradigm.)
If there was a focus on engineering & integration instead of copying the Windows 95 desktop, I wonder where we would be today.
I imagine we'd be using things like Gnome and KDE, neither of which has focussed on copying the Windows 95 desktop (though each has taken some elements inspired by the Windows UI, more in KDE than Gnome, as well as plenty that were inspired elsewhere or that are original), and which have focussed internally on integration, and even between eachother on interoperability, for some time.
We -need- RMS though. Without RMS we just have a bunch of people wanting to get stuff for free. Heck, without RMS and the GPL, Linux would not exist, Linux as in the kernel itself.
The ability to license it under the GPL once it was written had no bearing on Linus Torvald's ability (and, AFAICT, wasn't really relevant to his motivation) in writing the Linux kernel initially. Without the GPL available, it could have been released under another open source license or as public domain software, and as long as there was an active project to continue improving it that was releasing updates and providing value, it would have survived as a project (see the BSDs for how that works under other open source licenses without the GPL, and see SQLite for an example with public domain software.)
Its true that its possible that if it was released under a bad license, the initial license problems of BSD Unix would have been resolved before Linux took off, and that that might have resulted in BSD the preferred open source unix implementation/clone rather than Linux taking the main role there. But that wouldn't stop Linux from existing, and probably wouldn't have prevented it from continuing as an active project.
Its just that Ubuntu BSD would be a popular open-source OS distribution, and Netcraft would be confirming the "death" of Linux as it continued alive in its niche. Oh, and without Linux being popular and GPL-licensed and using the GPL-licensed GNU tools, GNU and the GPL would have a lot lower profile.
So, in other words, the State of California has never altered wages?
No, the existing state system is very good at handling altered wages, it handles them every day without extended reprogramming.
Its bad at temporarily at doing temporary mass changes that affect the basis of pay (many of the people who would have been paid at the federal hourly minimum wage were salaried employees that weren't normally paid based on hours worked, many of the rest are paid on a quasi-salary basis with a monthly based pay but dock or overtime calculated hourly, and some were actual hourly employees) that also involve all-kinds of non-standard treatment of the way various things that are normally calculated from or along with wages are treated.
Actually the ribbon style is not built for eye candy but rather for usability.
This is actually a point of contention among usability engineers.
I would think that it is more often a point of contention, at least one within the scope of expertise of usability engineers, whether it works for usability, not whether it was built for that purpose.
The fact that some of it was modified by altering DNA is pretty much irrelevant to the discussion; the supposed dangers of GM come from unbalancing the environment by introducing a foreign organism, something that we've done and then dealt with many times throughout human history.
No, actually, the supposed dangers of GM food do not mainly come from "unbalancing the environment by introducing a foreign organism". The supposed dangers from GM food mainly are about the danger of changes that are far greater than would happen in a similar time with evolution through natural selection or selective breeding, where the detailed effects on the biochemistry of the foodstuff and the potential effects on humans are not adequately understood before putting the product on the market. Its much the same as the concern would be with pharmaceuticals if we didn't have a regime of clinical trials before putting new drugs on the market.
Those dangers are magnified by the ability of GM foodstuffs, without very extensive isolation precautions, to spread in the environment, and to transfer genes to non-GM organisms of similar (and sometimes dissimilar) types, which makes them much harder to eradicate if problems are found after they are in the wild than would be the case with commercial drugs, which can fairly easily be pulled from the market. A bad heart attack drug isn't going to spread its formula into other pharmaceutical lines so that they produce the same dangerous ingredient.
IBut the solution isn't to ban genetically engineered crops it's to change the law so a farmer can only be sued if he or she can be proved to have known (or had the information to know if they'd cared to think about it) that their seed was actually carrying the trait, and also benefited from the trait (ie it's not like the farmer benefits at all from having beets resistant to a sepecific herbicide if they don't actually spay that herbicide, which would have killed their beets if they didn't contain the trait.)
Even if the farmer knows after the fact about the contamination, why should he be liable when any "infringement" was directly caused by the failure of the patent holder or their licensee to keep the patented organism's genetic material from being spread in the environment?
Unless the cross-pollination is the result of a deliberate act by the farmers whose crops were pollinated aimed at securing the patented genes, I don't see why they should be liable at all, even if they do become aware after the event and benefit from it. Allowing patent holders to sue even in the case you present just encourages irresponsible actions by the makers and growers of GMOs.
For example, California's problem of six months to lower wages, then nine months to restore them, probably means the change won't happen.
Since it took less time than that for the underlying issue to be resolved that prompted the order, sure.
I'd argue that if you can afford to rewrite it such that it takes ten minutes (or a few days, maybe a month, counting all the administrative BS), it really doesn't take that many changes for it to pay off, and you'll probably find yourself making more changes -- that is, things that previously would've been "nice to have, but we can't afford to change it" now become reasonably possible.
Sure, but it would take much longer than the combined time for the changes on both ends to the existing system to rewrite the system so that that one need could be accomplished in a quick switch-flip style change whenever desired in the future, and since the change was a major business process change not a simple parameter change, the changes that would be needed to make that an instant would -- no matter the language -- have at best only tangential relevance to any other change that might be needed in the future.
Granted, sometimes, there's not going to be a lot of justification. But when a change wages requires six months of work, it's worth seriously considering how long a rewrite would take.
Um, the six months wasn't six months of pure coding, and the wages weren't just being changed, the basic premises of how other things were calculated from the wages (and how wages -- which often weren't hourly in the first place -- were identified from other information in the system) were also to be changed, as well as the information that was gathered and other business processes that were external to the code itself. The six months was the entire time it would take to implement the change, including requirements gathering (a high-level policy directive is not the same as a complete set of requirements), designing, coding, and testing the system and the associated business process, and not just for the facility to make the initial change, but to be able to do the new things that would be required when the minimum wage period ended.
Six months for what should be a ten minute change (generously), no matter what the language, demands a rewrite.
I don't think you understand the problem if you think it would be anything like a 10 minute change in any case.
Security -- what can a language do to help that, other than avoid encouraging blatantly insecure constructs? But then, Erlang doesn't ever allow non-Erlang code inside the Erlang process, save for the VM itself
That's either not true or at least misleading. Non-Erlang code that's not part of the distributed VM can run inside Erlang processes as a "linked-in driver" (whether such a driver is essentially a new part of the VM is, I suppose, debatable), which may sometimes be desirable for performance reasons though it is generally discouraged because of the fact that errors in the driver can potentially crash the system.
Erlang is one of the few platforms on which you can comfortably spawn a few hundred thousand processes, and let the language itself manage scheduling -- so it scales to many cores.
While both the first and second halves are true, the "so" linking them isn't really. The fact that the VM handles scheduling doesn't make it scale to many cores (originally, the Erlang environment was optimized to run separate VMs per core communicating as separate Erlang nodes.) But the fact that it is designed that way means that once the heavy lifting was done to convert from a non-threaded, single-OS-process set of VM-managed "processes" (Erlang processes aren't OS processes, they are more like green threads with very limited shared state with restricted means for accessing that state to avoid conflicts) to a backend which had SMP support and distributed the work of the VM "processes" across different OS threads that this change was completely transparent to Erlang code. But SMP support in Erlang is comparatively new (from about 2006).
And is also utterly impossible while there is a single line of GPLv2-only code in it that the author doesn't give permission for, or whom is dead.
If the author is dead, they aren't the copyright owner anymore, and whoever is can give permission. The real issue is where the copyright owner doesn't give permission, or can't be certainly identified (which may be the case in some cases where the original author has died.)
Say what you will about nuclear weapons but they are probably the only reason that humanity hasn't fought World War III yet.
Semantic games wherein a continuous state of armed conflict between two competing alliances involving clashes in North America, South America, Southeast Asia, Central Asia, Southwest Asia, and Africa still doesn't constitute a "world war" is the only reason that the humanity hasn't fought "World War III" yet. Of course, nuclear weapons played a role in that game, as they were no doubt a big part of the reason no one wanted to call the situation a real and active war between the two blocs, since a statement that a war existed (despite the unmistakable fact that it did) might be perceived as a policy shift toward unrestricted (and particularly nuclear) prosecution of the war, which would make it more likely that the other side would attempt to pre-empt such use with its own strike.
But nuclear weapons certainly did not prevent global conventional conflict between the major power blocs.
Great post describing QNX. But you forgot the part where you actually make some kind of point.
What's your point?
I took GPs point to be: 1) Microkernels, by limiting the role of the kernel, are easier to get to the state of being error-free to any given degree. 2) Microkernels, while perhaps having serious performance problems in the fast, can be very efficient on modern hardware which provides means of dealing with the things which used to make them slow.
And, implicitly, as a consequence, that it might be reasonable to take a new look at microkernels now.
I can tell you this: Vista (!!!) appears to run smoother and with a more-responsive UI on my laptop than when I try a default ubuntu install on the thing (for example, flash just crawls when I am viewing it thru firefox in ubuntu).
Flash has a notably bad reputation for perfomance on Linux, though my Core 2 Duo VAIO laptop has better performance on just about everything but Flash with 64-bit Ubuntu 9.04 (WUBI, so its filesystem is hosted within the Windows NTFS filesystem, which I would imagine probably doesn't help performance) than with the stock 32-bit WinXP-MCE. And Flash is only a little bit slower (using the Adobe player, none of the open source alternatives are compatible enough to use.)
Also, Firefox seems a bit slower on it than on Windows, but the Google Chrome dev build on Linux (the only build available) seems a bit quicker than Chrome on Windows (I use the Chrome beta channel on Windows.)
It has been my experience in the past that every time I install linux, it runs slower (or at least appears to run slower) than the windows install on the same machine.
My experience has been the opposite for most use, but it varies from app-to-app, and there are probably a lot of hardware and configuration issues that can have significant effects on which turns out faster.
Slashdot Mirror
It does provide a link to the paper that is the source of the estimate, but I suppose clicking the link would be too much to ask.
No, it doesn't. "Range voting" (aka "Average Rating Voting") is subject to strategic voting (for the strategies that apply, see here.) Further, the Gibbard-Satterthwaite Theorem proves that the only way any single-winner system could eliminate strategic voting would either be to be dictatorial or to up-front prohibit certain candidates from winning regardless of the votes.
Range voting has the additional problem (compared either to choose-one systems like majority-runoff or plurality or to ranked ballots systems in general) that the meaning of the same marking on different voters ballots isn't the same (What does a 50 out of 100 maximum ranking mean?) Approval voting, a somewhat more popular, "weaker" form of range voting in which there are only two ratings ("acceptable" and "not acceptable", in essence) available, has the same problem, though somewhat weaker.
Sure, in an unattainably perfect world with perfect election systems, this would be true. However, one most note that its impossible to have a single-winner voting system where more than two candidates stand for election where strategic voting is not rewarded if voting actually matters at all.
In the real world, strategic voting which takes into account the preferences and likely behavior of other voters, assuming it is based on accurate information, produces better results than blindly voting your own true preferences.
Even ignoring the incentives for strategic voting, though, there is a cost benefit analysis in pre-voting activities which effect the success of candidates and ballot propositions -- even if a person believes something is a good idea and plans to vote for it, they are far less likely to expend resources (whether by donations of money or of time and effort) if they feel that those resources are unlikely to make a difference in the outcome.
So, ultimately, there are good reasons why people's understanding of the popularity of a political idea or candidate affects their behavior regarding that idea or candidate.
All concepts of the "good" are subjective and, consequently, "questionable", and most philanthropy is something that the people doing it would agree that organized government should be doing, but is not.
Some economists are saying that there are high-level leading indicators that the economy is pulling out of a recession.
And even most of those that are saying that aren't saying "we should be happy"; quite a lot of economists (though far less of the people that report on the economy in the media) know that aggregate improvements in the economy don't necessarily mean most people are experiencing better conditions (I suspect that economists are the profession most likely to be aware that even during an economic expansion, its quite likely to see the conditions for most people get worse while the benefits all go to a very small elite; indeed, they are also probably the group most likely to be aware that there is evidence that that is what occurred in the expansion preceding the current recession.)
This is why there is, in agile methodologies (or at least the descriptions I've seen of them, there's a whole lot that passes under that name) the usual recommendation is write a unit test, write the code to make it pass, rinse, repeat. /b
Given the number of times I've seen major pieces of software that neither shipped on time nor solved the problems the customer really wanted solved, I would contend that, in fact, "any idiot" cannot do that, and that, furthermore, it is often the case groups of individually talented people fail to do that.
Its quite possible to do duct-tape programming in languages that force single inheritance, and its quite possible to architect things well in languages that feature multiple inheritance. (Even resulting in designs that use multiple inheritance.)
Its also possible to do both in languages that don't feature inheritance at all (because, e.g., they don't use class-based OOP as a their main paradigm.)
I imagine we'd be using things like Gnome and KDE, neither of which has focussed on copying the Windows 95 desktop (though each has taken some elements inspired by the Windows UI, more in KDE than Gnome, as well as plenty that were inspired elsewhere or that are original), and which have focussed internally on integration, and even between eachother on interoperability, for some time.
The ability to license it under the GPL once it was written had no bearing on Linus Torvald's ability (and, AFAICT, wasn't really relevant to his motivation) in writing the Linux kernel initially. Without the GPL available, it could have been released under another open source license or as public domain software, and as long as there was an active project to continue improving it that was releasing updates and providing value, it would have survived as a project (see the BSDs for how that works under other open source licenses without the GPL, and see SQLite for an example with public domain software.)
Its true that its possible that if it was released under a bad license, the initial license problems of BSD Unix would have been resolved before Linux took off, and that that might have resulted in BSD the preferred open source unix implementation/clone rather than Linux taking the main role there. But that wouldn't stop Linux from existing, and probably wouldn't have prevented it from continuing as an active project.
Its just that Ubuntu BSD would be a popular open-source OS distribution, and Netcraft would be confirming the "death" of Linux as it continued alive in its niche. Oh, and without Linux being popular and GPL-licensed and using the GPL-licensed GNU tools, GNU and the GPL would have a lot lower profile.
No, the existing state system is very good at handling altered wages, it handles them every day without extended reprogramming.
Its bad at temporarily at doing temporary mass changes that affect the basis of pay (many of the people who would have been paid at the federal hourly minimum wage were salaried employees that weren't normally paid based on hours worked, many of the rest are paid on a quasi-salary basis with a monthly based pay but dock or overtime calculated hourly, and some were actual hourly employees) that also involve all-kinds of non-standard treatment of the way various things that are normally calculated from or along with wages are treated.
I would think that it is more often a point of contention, at least one within the scope of expertise of usability engineers, whether it works for usability, not whether it was built for that purpose.
The two issues are largely orthogonal.
So, you'd only need four times the length of the current history of the State of California to reach your expected break even point?
No, actually, the supposed dangers of GM food do not mainly come from "unbalancing the environment by introducing a foreign organism". The supposed dangers from GM food mainly are about the danger of changes that are far greater than would happen in a similar time with evolution through natural selection or selective breeding, where the detailed effects on the biochemistry of the foodstuff and the potential effects on humans are not adequately understood before putting the product on the market. Its much the same as the concern would be with pharmaceuticals if we didn't have a regime of clinical trials before putting new drugs on the market.
Those dangers are magnified by the ability of GM foodstuffs, without very extensive isolation precautions, to spread in the environment, and to transfer genes to non-GM organisms of similar (and sometimes dissimilar) types, which makes them much harder to eradicate if problems are found after they are in the wild than would be the case with commercial drugs, which can fairly easily be pulled from the market. A bad heart attack drug isn't going to spread its formula into other pharmaceutical lines so that they produce the same dangerous ingredient.
Even if the farmer knows after the fact about the contamination, why should he be liable when any "infringement" was directly caused by the failure of the patent holder or their licensee to keep the patented organism's genetic material from being spread in the environment?
Unless the cross-pollination is the result of a deliberate act by the farmers whose crops were pollinated aimed at securing the patented genes, I don't see why they should be liable at all, even if they do become aware after the event and benefit from it. Allowing patent holders to sue even in the case you present just encourages irresponsible actions by the makers and growers of GMOs.
I suggest you read your own link. "Organic" labelling does not just mean "without pesticides", it also usually includes "not genetically modified".
Since it took less time than that for the underlying issue to be resolved that prompted the order, sure.
Sure, but it would take much longer than the combined time for the changes on both ends to the existing system to rewrite the system so that that one need could be accomplished in a quick switch-flip style change whenever desired in the future, and since the change was a major business process change not a simple parameter change, the changes that would be needed to make that an instant would -- no matter the language -- have at best only tangential relevance to any other change that might be needed in the future.
Um, the six months wasn't six months of pure coding, and the wages weren't just being changed, the basic premises of how other things were calculated from the wages (and how wages -- which often weren't hourly in the first place -- were identified from other information in the system) were also to be changed, as well as the information that was gathered and other business processes that were external to the code itself. The six months was the entire time it would take to implement the change, including requirements gathering (a high-level policy directive is not the same as a complete set of requirements), designing, coding, and testing the system and the associated business process, and not just for the facility to make the initial change, but to be able to do the new things that would be required when the minimum wage period ended.
I don't think you understand the problem if you think it would be anything like a 10 minute change in any case.
That's either not true or at least misleading. Non-Erlang code that's not part of the distributed VM can run inside Erlang processes as a "linked-in driver" (whether such a driver is essentially a new part of the VM is, I suppose, debatable), which may sometimes be desirable for performance reasons though it is generally discouraged because of the fact that errors in the driver can potentially crash the system.
While both the first and second halves are true, the "so" linking them isn't really. The fact that the VM handles scheduling doesn't make it scale to many cores (originally, the Erlang environment was optimized to run separate VMs per core communicating as separate Erlang nodes.) But the fact that it is designed that way means that once the heavy lifting was done to convert from a non-threaded, single-OS-process set of VM-managed "processes" (Erlang processes aren't OS processes, they are more like green threads with very limited shared state with restricted means for accessing that state to avoid conflicts) to a backend which had SMP support and distributed the work of the VM "processes" across different OS threads that this change was completely transparent to Erlang code. But SMP support in Erlang is comparatively new (from about 2006).
If the author is dead, they aren't the copyright owner anymore, and whoever is can give permission. The real issue is where the copyright owner doesn't give permission, or can't be certainly identified (which may be the case in some cases where the original author has died.)
Because every time they get one close to being ready for general use, they decide to throw it away and start from scratch on a new one?
Solarix?
Semantic games wherein a continuous state of armed conflict between two competing alliances involving clashes in North America, South America, Southeast Asia, Central Asia, Southwest Asia, and Africa still doesn't constitute a "world war" is the only reason that the humanity hasn't fought "World War III" yet. Of course, nuclear weapons played a role in that game, as they were no doubt a big part of the reason no one wanted to call the situation a real and active war between the two blocs, since a statement that a war existed (despite the unmistakable fact that it did) might be perceived as a policy shift toward unrestricted (and particularly nuclear) prosecution of the war, which would make it more likely that the other side would attempt to pre-empt such use with its own strike.
But nuclear weapons certainly did not prevent global conventional conflict between the major power blocs.
I took GPs point to be:
1) Microkernels, by limiting the role of the kernel, are easier to get to the state of being error-free to any given degree.
2) Microkernels, while perhaps having serious performance problems in the fast, can be very efficient on modern hardware which provides means of dealing with the things which used to make them slow.
And, implicitly, as a consequence, that it might be reasonable to take a new look at microkernels now.
Flash has a notably bad reputation for perfomance on Linux, though my Core 2 Duo VAIO laptop has better performance on just about everything but Flash with 64-bit Ubuntu 9.04 (WUBI, so its filesystem is hosted within the Windows NTFS filesystem, which I would imagine probably doesn't help performance) than with the stock 32-bit WinXP-MCE. And Flash is only a little bit slower (using the Adobe player, none of the open source alternatives are compatible enough to use.)
Also, Firefox seems a bit slower on it than on Windows, but the Google Chrome dev build on Linux (the only build available) seems a bit quicker than Chrome on Windows (I use the Chrome beta channel on Windows.)
My experience has been the opposite for most use, but it varies from app-to-app, and there are probably a lot of hardware and configuration issues that can have significant effects on which turns out faster.