And yet people constantly claim that the GPL is not anti-business.
Then what you're saying is that competition is anti-business. You don't have to use GPL'd software. It's just one alternative in the marketplace. If you feel like you have no choice, it's because GPL'd products are better, in which case you're seeing the results of a superior business model.
The thing that all the "free-market" sloganeering overlooks is that a truly free marketplace allows competition not only between products, but modes of organization. And whaddya know, sometimes cooperative modes work better. Unless you believe that capitalism can only work when everyone is required to charge money for every good or service.
These firmware manufacturers aren't competing in the marketplace either, they're just free-riding. They seem to believe that someone else owes them a living, and want to make a buck selling stolen software in violation of the terms of its licensing agreements.
"Hey, if everyone wasn't a criminal none of these laws would be passed"
Yeah, you've got it. That's totalitarianism in a nutshell: the criminalization of everyday behavior. Then, when you attract the attention of the authorities for whatever reason (say, by expressing a dissenting view that gets in the way of some lucrative piece of business), they have a pretext for lock you up.
I think you're onto something. It helps if you understand the cultural context. Here's how most Americans define freedom: you can express whatever opinions you like, as long as they're in conformity with popular prejudice. It's regarded as bad form if you use your freedom to state a view that makes the majority uncomfortable. That's why, in this nation that talks so much about individualism, there's more widespread and stultifying conformity than you find in most European countries.
As for indymedia: their policy is to exercise the minimum of editorial control. If you really want an alternative source of news, it's inconsistent to have someone in charge deciding what's newsworthy. So (to use a well-worn metaphor) the window's wide open, but flies come in.
Standard bean-counter trick: take something with a long lifecycle (say, time from bug detection to availability of fix to end-user), then salami-slice out a small part of that process (say, time to fix and check in code once the bug is diagnosed) and take credit for how fast turnaround time is on that salami-slice.
You see it all the time in SLA's when someone thinks you're not reading the fine print.
Compulsory licensing schemes are monopolies by another name. They use public resources to collect revenues and distribute them to a private entity.
This forces all providers to use the statutorily-recognized middleman if they expect equal treatment under the law. It's not unusual for the distribution schemes to be rigged to penalize independents.
It is not the role of government to be the collection agency for the RIAA or any other producers' union. In fact, any law that recognizes a specific private commercial entity and gives it special treatment is a corrupt law that should be repealed.
If you live in the UK you already do. This is why there isn't an outcry over the introduction of Oystercard.
Up to a point, milord. I'd say that you're recognized as a stakeholder, but you don't have ownership rights in the same strong sense as, say, copyright holders do.
But the Data Protection Act, for all its technical absurdities, is definitely a step in the right direction. Pity about the Blair/Blunkett policies on government snooping on innocent citizens though. I had hoped for better based on their promises while in opposition.
The problem I have with CCAGW is not just that they're wrong about OSS, but they're wrong about the relationship of procurement policy to enterprise architecture if their real objective is indeed cost savings.
To minimize TCO, not just for one app but globally across all of state government, procurement policy MUST favor solutions with open, standard interfaces. This practice lowers the cost of maintaining interoperability, and it also minimizes the number of different skill sets you need in order to maintain all that different software. So for each application domain, it makes sense to favor one solution over a multitude of solutions. This means that case-by-case competitive procurement without reference to standards doesn't work. The Massachusetts state government has mandated some of those standards. One is excluding proprietary interfaces.
CCAGW's rhetoric uses all the standard free-market buzzwords. But competitive procurement of pieces that, at the end of the day, don't fit together will not save the taxpayer any money. It's far more likely it will lead to more of the costly system-integration fiascos that have plagued government IT for the past several decades, not to mention security lapses and potential loss of critical data.
Based on this, I'm inclined to be cynical and assume that CCAGW are one of the many pseudo-grassroots groups who make their living by being mouthpieces for commercial interests, in this case those whose snouts have been forced out of the trough. Or perhaps they really have such poor access to engineering expertise that they believe that local optimization with inappropriate constraints will inevitably lead to global optimization. That beancounter's fallacy may still get an audience in Washington, but not many other places.
Meanwhile I'm sure CCAGW will also be as outspoken about the open-ended sole-source contracts recently let out by the Feds to Halliburton and Bechtel for Iraqi reconstruction. Or is it their view that such practices are only anti-competitive and socialistic when they are less flagrant and serve the public interest?
Note that I think it may have been a tactical error to have adopted an "OSS-only" procurement policy, since it opens you up to the kind of sniping we've seen here (however weak its technical or fiscal rationale). But a policy limiting the diversity of solutions and requiring compliance with open standards will probably lead to the same results, since OSS has had a better track record in this regard than proprietary software.
The number you cited is basically one cell in a square matrix (minus diagonal) of all possible types/versions of server software. Rows are "from", columns are "to." In isolation, a single cell doesn't tell you much about trends in market share.
In order for you to be able to draw useful conclusions about the impact on Linux server use, you'd need to know, at least:
Percentage of Linux server users switching to Windows Server 2003
Percentage of Windows Server 2003 users switching to Linux
Percentage of other server users (or new server users) adopting Linux
Percentage of other server users (or new server users) adopting Windows 2003
One number to watch is the comparison of those who drop Linux for Windows versus those who drop Windows for Linux. Anecdotally at least, the latter is by far the bigger group. Anyway, it would be misleading to show those who dropped the new release of Windows Server for Linux, since there hasn't been time for recent WS2003 adopters to have gained enough hands-on experience to decide not to use it, or to have planned and budgeted a cutover. For a meaningful comparison, it would be necessary either to show recruitment/defection statistics for all Windows server releases together relative to Linux, or to segregate Linux servers by (say) kernel dot release (2.2. 2.4, 2.6).
Even then, you're measuring deltas, so you wouldn't have a good handle on overall market size or relative market share. I think that those numbers might be of greater interest. They'd have to be measured in some other way.
The real problem is this: your everyday actions generate a (continually growing) stream of data. But, under the present system, you don't have ownership rights to that data. There has been some recognition that you're a stakeholder who can demand corrections to some categories of data (for instance, credit reports), but it still belongs to someone else.
The law should be changed to explicitly state that you have an ownership interest in data that is derived from your transactions and movements. It may not be 100% ownership, but for the sake of argument, let's say it's 50/50. The only exception should be for journalism, since journalists are already constrained by libel laws. Then unauthorized dissemination of your personal information can fall under the increasingly draconian IP laws, and furthermore you will be entitled to a share of the revenues derived from sale of your data.
This still doesn't help with governments, but will put an economic constraint on the privatization of totalitarian control that's been progressing unchecked in developed countries.
I think you miss one crucial element of the "persistent, write-once artifact" -- it should be verifiable by the voter, ideally without any kind of tamperable equipment.
Yeah, that might be a requirement too. However, I was also assuming the "can't walk away with a persistent record" requirement, so there might be no need for a separate viewer and vote-capture interface. Once the vote is committed, my understanding is that it's gone as far as the voter is concerned.
It seems that a lot of the debate boils down to the inability to distinguish electronic voting software from the broader (possibly electronic) voting system. The system consists of the software, the hardware, and the (possibly manual) procedures and processes that go with it. THIS is what needs to be resistant to hacking.
I fully agree that, in order for this to be possible, individual components must also be transparent and auditable, and in the case of software, that means either open-source or (second-best) independently verified as compliant with well-defined standards. Even better, both open and verified to be compliant with standards.
For end-to-end resistance to tampering, creation of a persistent, write-once artifact seems essential. Further, it should be possible to verify each of these artifacts to confirm that it was the product of a voting event (this way, you can find out if someone stuffed the ballot box.) Conversely, it should be possible to cross-check the voting machine against the persistent record to confirm that there are the same number of artifacts as voting events. Paper is one form that such artifacts could take-- but certainly not the only one. I could envision incrementally written CD-R as another possibility, even ROM.
Regardless, I would never trust any system in which the critical records are retained on media that can be edited. This alone would disqualify the current Diebold implementation.
I think that your posting contains the crux of the whole debate. Not that I agree with your conclusion, mind you...
In the meatworld, in many circumstances, you can see (and maybe handle) the fruit before you buy it. Similarly, you can leaf through a book or magazine. There's an intermediate stage in the transaction between locating the product and purchase.
Micropayment schemes that don't include a limited element of try-before-you-buy can never emulate the elements of serendipity and of shopping that are essential features of "real" consumer markets. That means that the only product information that can be made use of is that which was acquired from other sources. Therefore, at best, micropayment schemes can be a supplement to other distribution channels, but are unlikely to generate new relationships between buyers and sellers. I would, therefore, expect micropayments to be adopted only as a-la-carte alternatives to existing online fixed-payment schemes for information providers with a high level of brand awareness and proven consistency.
The only way I envision micropayment schemes getting adopted widely is if some form of collusion takes place among information providers, backed by legislation-by-hire, that artificially restricts alternatives.
The purpose of the amnesty is just like the purpose of reply-to addresses on spam: those who respond provide the RIAA with a free list of valid names. These can be used in a later round of the witch-hunt.
It's easier to think of this as patents being grazing territory that you are staking out for your own source of food. In many cases, patents extend over more territory than the residents will ever be able to feed upon in their lifetime.
Know about the Highland Clearances? A hardening of the interpretation of absolute property rights as a means of theft, depriving thousands of their livelihood to benefit a rich few? That's what's happening now with patent law.
There is no law in the US that you are required to present a government-issued ID when opening a bank account. But then, there's no law that says that you're required to show a government-issued ID in order to board a domestic airline flight. The US does not have an internal passport system on its law books like the old USSR did or China does.
In neither case would I expect success if I didn't show the ID, though. This is yet another instance of the way the US system privatizes the mechanics of repression. We don't need the government to exercise totalitarian control over every aspect of our lives; our employers, credit agencies, banks, insurance companies, HMOs and creditors do that far more completely, and with virtually no accountability. "Partnerships" between the public and private sector ensure that the government can snoop on us whenever they please anyway.
I render the same loyalty to my employer as I expect from them. I'm aware that they are in business to make money, not to provide for my welfare.
"Lifer" colleagues of mine who thought that there was more in the relationship than mutual exploitation (with most of the power on the employer's side of the equation) had shocked looks on their faces when they were unceremoniously booted out the door.
Me, I work hard, do a good job, but monitor the warning signs and am ready to jump before I'm pushed. I've only had to do it once in a very long career. But if you don't have a "fsck you fund" built up that allows you to walk out when they start taking advantage, you are unprepared. If you do have it, and they know it, you'll find that you get more respect. If you show signs of weakness or dependency, they'll use that leverage.
Monopolies always like government regulation, since it imposes barriers to entry. High barriers to entry protect big players and disproportionately penalize small players. A few megabucks to qualify a product come out of the petty cash drawer at Redmond, but are a big deal to small firms and free software providers.
Since the purpose of the US government is to transfer money from taxpayers to large campaign contributors without undue public scrutiny, there will often be policy documents that are published that make no sense if you assume that they are meant to achieve their stated purpose. But they make perfect sense if you consider what they're really optimized for.
The real meaning is that some members of the profession got together to protect their gravy train by raising regulatory barriers to new people entering their profession. The long, difficult tests (typically having nothing to do with the demands of a real engineering job), the exploitative apprenticeship requirements, and the dire warnings of liability are all ways of limiting the supply of engineers and preventing rapid change in the field without the approval of the self-appointed gatekeepers, who now have subverted the legistlature into protecting their positions. And of course they make money teaching irrelevant courses and make good money screwing the apprentices out of what would otherwise be market wages (it's not just Texan engineers: CPA's run a similar racket, as do branches of the medical profession). Oh, but it's "professional certification"-- "closed shop" sounds too... umm... blue-collar.
The day that this kind of crap becomes the norm for software in the rest of the US will be the day that innovation has been completely killed and the academic and big-corporation technical bureaucrats have taken over.
Once they get the lock nationwide, their next step will be to buy legislation to prosecute you for daring to write software without a license.
I suspect that the original article was a troll, but still...
The whole basis of this proposal is the idea that the price of imported software should be adjusted to compensate for differences in the cost of labor. This is based on the fallacious notion that the value of an item is related to the amount of labor that went into it. It's a good old theory, but since Ricardo and Marx, not one that has been taken all that seriously (though it kind of made sense for agricultural and unskilled factory labor). The value of software is what someone will pay for it, not what it cost you (or what some self-interested bureaucrat says it cost someone else) to make it. You could burn $50M in labor costs and still produce software with a value of zero. I've seen it done. On the other hand, uncompensated labor can produce software that someone's willing to pay good money for (look at any Linux distro).
Your whole approach is one that appeals most to the software people who are the most likely to be laid off in favor of third-world commodity coders. In other words, the ones who least belong in the business in the first place. The only reliable survival strategy in a globalized business like this is to provide more value than the competition. Firms will pay top dollar for good talent. Even though rates have eroded in the past year, I'm still doing fine, as are those of my peers who are really good at what they do. If you're just another bozo slinging SQL or VB, don't be surprised if someone in Sri Lanka has figured out how easy your job is. And frankly, if they do a better job than you, I'll outsource to them.
And based on the labor theory of value that you implicitly endorse, you'll still be adding the same value when you move on to Burger King anyway.
So which of the criteria you cite applies to Padilla? Which foreign state did he declare allegiance to? Which foreign military did he enlist in?
Anyway, the State Department guidelines you cite are not the law: they're policy. Law is enacted by Congress and interpreted by the court. And the law is actually more nuanced: the criteria cited above are evidence of intent, but the case needs to be made in court. There are instances where several of these criteria were met, yet the courts still decided that citizenship could not be revoked. I recall that the case that made it to the Supremes involved an American who also had Israeli nationality and served in their military. He's still a US citizen.
And that day in court is the central point in the Padilla case as well. Ashcroft and the rest of the Bush junta claim that they can hold him because they say so, and deny him counsel because they say so, and that the courts have no authority to interfere. All the semantic games about him being an "unlawful combatant" are really just subterfuges to assign him to a fictitious category of person with no rights so they can exercise arbitrary power to detain without charge and punish without judicial oversight.
One well-understood goal of terrorism is to cause a government to adopt repressive measures that undermine its legitimacy and popular support. The present administration is brutal, power-mad and ignorant enough to have fallen into this trap both domestically and internationally. Furthermore, I have little doubt that they intend to use these same arbitrary powers to harass domestic critics of their authoritarian and un-American policies if they think they can get away with it. So the more judicial smackdowns they receive, the better. Bush's real argument is that he knows better than the Constitution (perhaps because of his frequent conversations with Jesus). But just because you bought the office doesn't mean you're fit to hold it, and self-confidence is not the same as being right. Anyway, unchecked executive power is a feature of banana republics and medieval despotisms, not of civilized society. Allowing our government to be hijacked by the executive branch will not solve our problems with terrorists. More likely it will exacerbate them.
The immunologist Miroslav Holub is a poet of great depth and subtlety. His poetry sometimes includes scientific concepts, and there's very definitely no boundary between his science and the rest of his worldview.
There really is a difference between scripting and programming. Scripting languages tend to be heavily dependent on compiled code. Where would perl be today if all the modules had to be written in perl? Instead, getting a module from CPAN, there's a good chance you are actually getting C code and a perl wrapper.
As opposed to C or C++, where you are dependent on lib functions to do anything non-trivial in reasonable time. In short, there's not much difference after all.
Anyway, I don't see how it matters which language my compiler (or interpreter) or libs are written in. Programmer productivity matters more. Sometimes that can only be achieved close to the metal, sometimes the effort is better spent elsewhere. The real standard should be "horses for courses." Minimize the number of languages used in order to keep complexity down, but do it in the easiest, most concise way, keeping in mind the skill set of the people who are going to maintain it. And remember the tradeoff between having them do it the hard way over and over again and having them learn something new. Equally important is that the languages chosen (if more than one) have to have well-documented interfaces (for instance, the Python-to-C extension APIs).
The thing to watch for is that the scripters don't think that the shorter development cycle is a reason to give up testing entirely. This happened with lots of web scripting that I've seen, and may have contributed to the shoddy reputation for scripted code in some quarters. But anyone who thinks that a stricter compiler will save the world is also mistaken, and I've seen C and C++ programmers blow off testing too. What you win with so-called type safety you lose through inflexible semantics and the proliferation of special cases. And remember that the type-checking hoops you have to jump through are imposed by your choice of tool, not by the problem you're trying to solve, so there's little assurance that the bugs you're finding actually make the final software better. My experience is that you get to the bugs more quickly and can fix them more quickly in Python or Perl than in C or Java-- though in some regards Java is halfway a scripting language anyway, so I'd place it midway between C and scipting in terms of ease of use (as well as doing things behind the curtains that you might not always approve of).
Anyone that compares a scripting languate (python) to a full programming language that also as a VM has no clue. a scripting language has minimal overhead memory requirements because it does not have much of a memory management job to do.
Your remarks about Python, and scripting languages in general, are not borne out by my own first-hand experience as a designer and developer.
First, you make it sound like, in some sense, scripting languages are not as complete as "real" programming languages. And your comments about memory management make even less sense-- any language with OO features (and many without) are going to have to do dynamic allocation-- how else are object references going to be dealt with?-- and that means that they're going to have to deal with memory-management issues. And if you think that all scripts are like little baby shellscripts, you haven't been around much.
I've developed medium-sized apps in Python and in Perl (on the order of 50K lines of executable code), and much bigger apps in Java. Python is semantically rich enough, and in most instances fast enough, to do anything that Java can do, and almost always with shorter, more readable code. The same can be said for Perl (though it requires more discipline to achieve the readability), and probably also Ruby and Scheme. From a software engineering point of view, I'd be happiest coding the whole app in Jython (the Python variant that compiles down to Java bytecodes), then recoding the hotspots in Java, or in some even lower-level language. Developers, even smart ones, usually guess wrong about what to optimize, so deferring tuning until you observe the working system is usually a good idea. Exceptions would be embedded and hard-realtime systems. Almost every business app I've seen is neither of these.
This in no way eliminates the need to design your app before coding it, BTW, contrary to what some bozos who once read the blurb on the back of an XP how-to book might have you believe.
When I did a demo of one Python-based app that I developed, my client was willing to accept a performance hit for the sake of better maintainability. When I benched its performance on one content-mangement task, it clocked in at 100 times faster than its C++ predecessor. Now obviously, a very clever C++ crew could have done a lot better than that. But in the real world, everyone's in a hurry and don't always choose the cleanest implementation. And when language features are too low-level, developers waste a lot of time reinventing "infrastructure." In this instance, they not only reinvented, but did it much more poorly than the developers of Python did.
The potential for abuse of such fine-grained information on your consumer puchases is not just restricted to the government. One goal is for merchants to be able to develop custom pricing structures for each consumer. That is, the current "club member discount" scam (really charging a higher price to those who don't want to be tracked), only more tailored to their estimate of the depth of your pockets. And of course this information will find its way to direct marketers, other merchants, and (if Poindexter isn't put back in his cage) to the Feds.
Look at www.nocards.org for more detail. Even when you discount the advocacy-hysteria that sometimes erupts on that site, there remain serious grounds for concern. The ability to conduct anonymous exchanges is one foundation of a free society.
Whether the means of tracking your identity is based on biometrics such as fingerprints, on RFID tags, or some other technique is irrelevant. It's the level of detail and intrusiveness, as well as the increasing difficulty in opting-out, that's the real problem. This kind of privatized totalitarianism needs to be shut down. Once the data stream is out there, it will be abused.
One could also argue that over the past 5 years there were substantial additional costs of NT/W2K adoption as a result of the MS learning curve.
Hmm, I thought I covered that when mentioning the forced-upgrade treadmill. Even when things change (for example, you decide to update your apps' UI to use Gnome2), the change is driven by your needs, not the vendor's marketing timetable.
But the point you make is an excellent one and should certainly be elaborated. M$ software is not very backward-compatible, and there's no real ability to freeze your system configuration and still have anything that's supported. The point I was trying to make was that there's a big one-time learning-curve hit when changing from Windows to Linux, but once that one-time hit has been incurred, you have control over the timing of subsequent changes. And I agree that these disruptions, broken apps, and screwed-up dependencies and endless workarounds add to system complexity, detract from usability, and drive costs way up.
Slashdot Mirror
The thing that all the "free-market" sloganeering overlooks is that a truly free marketplace allows competition not only between products, but modes of organization. And whaddya know, sometimes cooperative modes work better. Unless you believe that capitalism can only work when everyone is required to charge money for every good or service.
These firmware manufacturers aren't competing in the marketplace either, they're just free-riding. They seem to believe that someone else owes them a living, and want to make a buck selling stolen software in violation of the terms of its licensing agreements.
Yeah, you've got it. That's totalitarianism in a nutshell: the criminalization of everyday behavior. Then, when you attract the attention of the authorities for whatever reason (say, by expressing a dissenting view that gets in the way of some lucrative piece of business), they have a pretext for lock you up.
I think you're onto something. It helps if you understand the cultural context. Here's how most Americans define freedom: you can express whatever opinions you like, as long as they're in conformity with popular prejudice. It's regarded as bad form if you use your freedom to state a view that makes the majority uncomfortable. That's why, in this nation that talks so much about individualism, there's more widespread and stultifying conformity than you find in most European countries.
As for indymedia: their policy is to exercise the minimum of editorial control. If you really want an alternative source of news, it's inconsistent to have someone in charge deciding what's newsworthy. So (to use a well-worn metaphor) the window's wide open, but flies come in.
Standard bean-counter trick: take something with a long lifecycle (say, time from bug detection to availability of fix to end-user), then salami-slice out a small part of that process (say, time to fix and check in code once the bug is diagnosed) and take credit for how fast turnaround time is on that salami-slice.
You see it all the time in SLA's when someone thinks you're not reading the fine print.
Compulsory licensing schemes are monopolies by another name. They use public resources to collect revenues and distribute them to a private entity.
This forces all providers to use the statutorily-recognized middleman if they expect equal treatment under the law. It's not unusual for the distribution schemes to be rigged to penalize independents.
It is not the role of government to be the collection agency for the RIAA or any other producers' union. In fact, any law that recognizes a specific private commercial entity and gives it special treatment is a corrupt law that should be repealed.
But the Data Protection Act, for all its technical absurdities, is definitely a step in the right direction. Pity about the Blair/Blunkett policies on government snooping on innocent citizens though. I had hoped for better based on their promises while in opposition.
The problem I have with CCAGW is not just that they're wrong about OSS, but they're wrong about the relationship of procurement policy to enterprise architecture if their real objective is indeed cost savings.
To minimize TCO, not just for one app but globally across all of state government, procurement policy MUST favor solutions with open, standard interfaces. This practice lowers the cost of maintaining interoperability, and it also minimizes the number of different skill sets you need in order to maintain all that different software. So for each application domain, it makes sense to favor one solution over a multitude of solutions. This means that case-by-case competitive procurement without reference to standards doesn't work. The Massachusetts state government has mandated some of those standards. One is excluding proprietary interfaces.
CCAGW's rhetoric uses all the standard free-market buzzwords. But competitive procurement of pieces that, at the end of the day, don't fit together will not save the taxpayer any money. It's far more likely it will lead to more of the costly system-integration fiascos that have plagued government IT for the past several decades, not to mention security lapses and potential loss of critical data.
Based on this, I'm inclined to be cynical and assume that CCAGW are one of the many pseudo-grassroots groups who make their living by being mouthpieces for commercial interests, in this case those whose snouts have been forced out of the trough. Or perhaps they really have such poor access to engineering expertise that they believe that local optimization with inappropriate constraints will inevitably lead to global optimization. That beancounter's fallacy may still get an audience in Washington, but not many other places.
Meanwhile I'm sure CCAGW will also be as outspoken about the open-ended sole-source contracts recently let out by the Feds to Halliburton and Bechtel for Iraqi reconstruction. Or is it their view that such practices are only anti-competitive and socialistic when they are less flagrant and serve the public interest?
Note that I think it may have been a tactical error to have adopted an "OSS-only" procurement policy, since it opens you up to the kind of sniping we've seen here (however weak its technical or fiscal rationale). But a policy limiting the diversity of solutions and requiring compliance with open standards will probably lead to the same results, since OSS has had a better track record in this regard than proprietary software.
In order for you to be able to draw useful conclusions about the impact on Linux server use, you'd need to know, at least:
Percentage of Linux server users switching to Windows Server 2003
Percentage of Windows Server 2003 users switching to Linux
Percentage of other server users (or new server users) adopting Linux
Percentage of other server users (or new server users) adopting Windows 2003
One number to watch is the comparison of those who drop Linux for Windows versus those who drop Windows for Linux. Anecdotally at least, the latter is by far the bigger group. Anyway, it would be misleading to show those who dropped the new release of Windows Server for Linux, since there hasn't been time for recent WS2003 adopters to have gained enough hands-on experience to decide not to use it, or to have planned and budgeted a cutover. For a meaningful comparison, it would be necessary either to show recruitment/defection statistics for all Windows server releases together relative to Linux, or to segregate Linux servers by (say) kernel dot release (2.2. 2.4, 2.6).
Even then, you're measuring deltas, so you wouldn't have a good handle on overall market size or relative market share. I think that those numbers might be of greater interest. They'd have to be measured in some other way.
The real problem is this: your everyday actions generate a (continually growing) stream of data. But, under the present system, you don't have ownership rights to that data. There has been some recognition that you're a stakeholder who can demand corrections to some categories of data (for instance, credit reports), but it still belongs to someone else.
The law should be changed to explicitly state that you have an ownership interest in data that is derived from your transactions and movements. It may not be 100% ownership, but for the sake of argument, let's say it's 50/50. The only exception should be for journalism, since journalists are already constrained by libel laws. Then unauthorized dissemination of your personal information can fall under the increasingly draconian IP laws, and furthermore you will be entitled to a share of the revenues derived from sale of your data.
This still doesn't help with governments, but will put an economic constraint on the privatization of totalitarian control that's been progressing unchecked in developed countries.
It seems that a lot of the debate boils down to the inability to distinguish electronic voting software from the broader (possibly electronic) voting system. The system consists of the software, the hardware, and the (possibly manual) procedures and processes that go with it. THIS is what needs to be resistant to hacking.
I fully agree that, in order for this to be possible, individual components must also be transparent and auditable, and in the case of software, that means either open-source or (second-best) independently verified as compliant with well-defined standards. Even better, both open and verified to be compliant with standards.
For end-to-end resistance to tampering, creation of a persistent, write-once artifact seems essential. Further, it should be possible to verify each of these artifacts to confirm that it was the product of a voting event (this way, you can find out if someone stuffed the ballot box.) Conversely, it should be possible to cross-check the voting machine against the persistent record to confirm that there are the same number of artifacts as voting events. Paper is one form that such artifacts could take-- but certainly not the only one. I could envision incrementally written CD-R as another possibility, even ROM.
Regardless, I would never trust any system in which the critical records are retained on media that can be edited. This alone would disqualify the current Diebold implementation.
I think that your posting contains the crux of the whole debate. Not that I agree with your conclusion, mind you...
In the meatworld, in many circumstances, you can see (and maybe handle) the fruit before you buy it. Similarly, you can leaf through a book or magazine. There's an intermediate stage in the transaction between locating the product and purchase.
Micropayment schemes that don't include a limited element of try-before-you-buy can never emulate the elements of serendipity and of shopping that are essential features of "real" consumer markets. That means that the only product information that can be made use of is that which was acquired from other sources. Therefore, at best, micropayment schemes can be a supplement to other distribution channels, but are unlikely to generate new relationships between buyers and sellers. I would, therefore, expect micropayments to be adopted only as a-la-carte alternatives to existing online fixed-payment schemes for information providers with a high level of brand awareness and proven consistency.
The only way I envision micropayment schemes getting adopted widely is if some form of collusion takes place among information providers, backed by legislation-by-hire, that artificially restricts alternatives.
The purpose of the amnesty is just like the purpose of reply-to addresses on spam: those who respond provide the RIAA with a free list of valid names. These can be used in a later round of the witch-hunt.
Know about the Highland Clearances? A hardening of the interpretation of absolute property rights as a means of theft, depriving thousands of their livelihood to benefit a rich few? That's what's happening now with patent law.
There is no law in the US that you are required to present a government-issued ID when opening a bank account. But then, there's no law that says that you're required to show a government-issued ID in order to board a domestic airline flight. The US does not have an internal passport system on its law books like the old USSR did or China does.
In neither case would I expect success if I didn't show the ID, though. This is yet another instance of the way the US system privatizes the mechanics of repression. We don't need the government to exercise totalitarian control over every aspect of our lives; our employers, credit agencies, banks, insurance companies, HMOs and creditors do that far more completely, and with virtually no accountability. "Partnerships" between the public and private sector ensure that the government can snoop on us whenever they please anyway.
"Lifer" colleagues of mine who thought that there was more in the relationship than mutual exploitation (with most of the power on the employer's side of the equation) had shocked looks on their faces when they were unceremoniously booted out the door.
Me, I work hard, do a good job, but monitor the warning signs and am ready to jump before I'm pushed. I've only had to do it once in a very long career. But if you don't have a "fsck you fund" built up that allows you to walk out when they start taking advantage, you are unprepared. If you do have it, and they know it, you'll find that you get more respect. If you show signs of weakness or dependency, they'll use that leverage.
Monopolies always like government regulation, since it imposes barriers to entry. High barriers to entry protect big players and disproportionately penalize small players. A few megabucks to qualify a product come out of the petty cash drawer at Redmond, but are a big deal to small firms and free software providers.
Since the purpose of the US government is to transfer money from taxpayers to large campaign contributors without undue public scrutiny, there will often be policy documents that are published that make no sense if you assume that they are meant to achieve their stated purpose. But they make perfect sense if you consider what they're really optimized for.
The real meaning is that some members of the profession got together to protect their gravy train by raising regulatory barriers to new people entering their profession. The long, difficult tests (typically having nothing to do with the demands of a real engineering job), the exploitative apprenticeship requirements, and the dire warnings of liability are all ways of limiting the supply of engineers and preventing rapid change in the field without the approval of the self-appointed gatekeepers, who now have subverted the legistlature into protecting their positions. And of course they make money teaching irrelevant courses and make good money screwing the apprentices out of what would otherwise be market wages (it's not just Texan engineers: CPA's run a similar racket, as do branches of the medical profession). Oh, but it's "professional certification"-- "closed shop" sounds too... umm... blue-collar.
The day that this kind of crap becomes the norm for software in the rest of the US will be the day that innovation has been completely killed and the academic and big-corporation technical bureaucrats have taken over.
Once they get the lock nationwide, their next step will be to buy legislation to prosecute you for daring to write software without a license.
I suspect that the original article was a troll, but still...
The whole basis of this proposal is the idea that the price of imported software should be adjusted to compensate for differences in the cost of labor. This is based on the fallacious notion that the value of an item is related to the amount of labor that went into it. It's a good old theory, but since Ricardo and Marx, not one that has been taken all that seriously (though it kind of made sense for agricultural and unskilled factory labor). The value of software is what someone will pay for it, not what it cost you (or what some self-interested bureaucrat says it cost someone else) to make it. You could burn $50M in labor costs and still produce software with a value of zero. I've seen it done. On the other hand, uncompensated labor can produce software that someone's willing to pay good money for (look at any Linux distro).
Your whole approach is one that appeals most to the software people who are the most likely to be laid off in favor of third-world commodity coders. In other words, the ones who least belong in the business in the first place. The only reliable survival strategy in a globalized business like this is to provide more value than the competition. Firms will pay top dollar for good talent. Even though rates have eroded in the past year, I'm still doing fine, as are those of my peers who are really good at what they do. If you're just another bozo slinging SQL or VB, don't be surprised if someone in Sri Lanka has figured out how easy your job is. And frankly, if they do a better job than you, I'll outsource to them.
And based on the labor theory of value that you implicitly endorse, you'll still be adding the same value when you move on to Burger King anyway.
So which of the criteria you cite applies to Padilla? Which foreign state did he declare allegiance to? Which foreign military did he enlist in?
Anyway, the State Department guidelines you cite are not the law: they're policy. Law is enacted by Congress and interpreted by the court. And the law is actually more nuanced: the criteria cited above are evidence of intent, but the case needs to be made in court. There are instances where several of these criteria were met, yet the courts still decided that citizenship could not be revoked. I recall that the case that made it to the Supremes involved an American who also had Israeli nationality and served in their military. He's still a US citizen.
And that day in court is the central point in the Padilla case as well. Ashcroft and the rest of the Bush junta claim that they can hold him because they say so, and deny him counsel because they say so, and that the courts have no authority to interfere. All the semantic games about him being an "unlawful combatant" are really just subterfuges to assign him to a fictitious category of person with no rights so they can exercise arbitrary power to detain without charge and punish without judicial oversight.
One well-understood goal of terrorism is to cause a government to adopt repressive measures that undermine its legitimacy and popular support. The present administration is brutal, power-mad and ignorant enough to have fallen into this trap both domestically and internationally. Furthermore, I have little doubt that they intend to use these same arbitrary powers to harass domestic critics of their authoritarian and un-American policies if they think they can get away with it. So the more judicial smackdowns they receive, the better. Bush's real argument is that he knows better than the Constitution (perhaps because of his frequent conversations with Jesus). But just because you bought the office doesn't mean you're fit to hold it, and self-confidence is not the same as being right. Anyway, unchecked executive power is a feature of banana republics and medieval despotisms, not of civilized society. Allowing our government to be hijacked by the executive branch will not solve our problems with terrorists. More likely it will exacerbate them.
The immunologist Miroslav Holub is a poet of great depth and subtlety. His poetry sometimes includes scientific concepts, and there's very definitely no boundary between his science and the rest of his worldview.
Anyway, I don't see how it matters which language my compiler (or interpreter) or libs are written in. Programmer productivity matters more. Sometimes that can only be achieved close to the metal, sometimes the effort is better spent elsewhere. The real standard should be "horses for courses." Minimize the number of languages used in order to keep complexity down, but do it in the easiest, most concise way, keeping in mind the skill set of the people who are going to maintain it. And remember the tradeoff between having them do it the hard way over and over again and having them learn something new. Equally important is that the languages chosen (if more than one) have to have well-documented interfaces (for instance, the Python-to-C extension APIs).
The thing to watch for is that the scripters don't think that the shorter development cycle is a reason to give up testing entirely. This happened with lots of web scripting that I've seen, and may have contributed to the shoddy reputation for scripted code in some quarters. But anyone who thinks that a stricter compiler will save the world is also mistaken, and I've seen C and C++ programmers blow off testing too. What you win with so-called type safety you lose through inflexible semantics and the proliferation of special cases. And remember that the type-checking hoops you have to jump through are imposed by your choice of tool, not by the problem you're trying to solve, so there's little assurance that the bugs you're finding actually make the final software better. My experience is that you get to the bugs more quickly and can fix them more quickly in Python or Perl than in C or Java-- though in some regards Java is halfway a scripting language anyway, so I'd place it midway between C and scipting in terms of ease of use (as well as doing things behind the curtains that you might not always approve of).
First, you make it sound like, in some sense, scripting languages are not as complete as "real" programming languages. And your comments about memory management make even less sense-- any language with OO features (and many without) are going to have to do dynamic allocation-- how else are object references going to be dealt with?-- and that means that they're going to have to deal with memory-management issues. And if you think that all scripts are like little baby shellscripts, you haven't been around much.
I've developed medium-sized apps in Python and in Perl (on the order of 50K lines of executable code), and much bigger apps in Java. Python is semantically rich enough, and in most instances fast enough, to do anything that Java can do, and almost always with shorter, more readable code. The same can be said for Perl (though it requires more discipline to achieve the readability), and probably also Ruby and Scheme. From a software engineering point of view, I'd be happiest coding the whole app in Jython (the Python variant that compiles down to Java bytecodes), then recoding the hotspots in Java, or in some even lower-level language. Developers, even smart ones, usually guess wrong about what to optimize, so deferring tuning until you observe the working system is usually a good idea. Exceptions would be embedded and hard-realtime systems. Almost every business app I've seen is neither of these.
This in no way eliminates the need to design your app before coding it, BTW, contrary to what some bozos who once read the blurb on the back of an XP how-to book might have you believe.
When I did a demo of one Python-based app that I developed, my client was willing to accept a performance hit for the sake of better maintainability. When I benched its performance on one content-mangement task, it clocked in at 100 times faster than its C++ predecessor. Now obviously, a very clever C++ crew could have done a lot better than that. But in the real world, everyone's in a hurry and don't always choose the cleanest implementation. And when language features are too low-level, developers waste a lot of time reinventing "infrastructure." In this instance, they not only reinvented, but did it much more poorly than the developers of Python did.
The potential for abuse of such fine-grained information on your consumer puchases is not just restricted to the government. One goal is for merchants to be able to develop custom pricing structures for each consumer. That is, the current "club member discount" scam (really charging a higher price to those who don't want to be tracked), only more tailored to their estimate of the depth of your pockets. And of course this information will find its way to direct marketers, other merchants, and (if Poindexter isn't put back in his cage) to the Feds.
Look at www.nocards.org for more detail. Even when you discount the advocacy-hysteria that sometimes erupts on that site, there remain serious grounds for concern. The ability to conduct anonymous exchanges is one foundation of a free society.
Whether the means of tracking your identity is based on biometrics such as fingerprints, on RFID tags, or some other technique is irrelevant. It's the level of detail and intrusiveness, as well as the increasing difficulty in opting-out, that's the real problem. This kind of privatized totalitarianism needs to be shut down. Once the data stream is out there, it will be abused.
But the point you make is an excellent one and should certainly be elaborated. M$ software is not very backward-compatible, and there's no real ability to freeze your system configuration and still have anything that's supported. The point I was trying to make was that there's a big one-time learning-curve hit when changing from Windows to Linux, but once that one-time hit has been incurred, you have control over the timing of subsequent changes. And I agree that these disruptions, broken apps, and screwed-up dependencies and endless workarounds add to system complexity, detract from usability, and drive costs way up.