Your argument is sophomoric, having only the appearance of a logical basis when in fact it is completely fallacious.
Believing that the ability to download a piece of software for "free" makes the "market value" zero shows a complete lacking of understanding of the words "free" (as in beer) and "market value." Moron may have been a strong word; ignorant would have been more accurate.
The supply is never infinite, and the price is never zero. There is no single "market value."
As for boasting, it's wholly unnecessary. You could make the same general statement and be 100% correct. The fact that you do not understand that is due to your limited understanding of "market value."
Your understanding of market economies is a bit thin. You hint at the actual situation when you say that it is "roughly zero," recognizing that it is neither zero, nor actually quantifiable. This is because a unique market exists for every two people at every geographic location at every moment in time. Specifically, you're post fails to account for a number of very important factors including:
1. information costs
2. transportation costs
3. any number of utility functions that may apply, not the least of which is perceived value and trust that the code is what it claims.
A glass of water is free, by law, in some U.S. states and yet you can still find it in bottles for a dollar at the corner convenience store. Ask a guy dying of thirst in a remote desert about the value of water, monetarily or otherwise. Why, it's $0, of course.
Two copies of the same code will have different values to different people in different circumstances. That basic principle is why market economies exist.
That's the most sophmoronic logic I've ever heard.
The fact that something can be obtained for free does NOT mean that the value is zero. Poor Understanding of Economics Mistake Number One.
Different people value things differently and for different reasons. This is why arbitration conditions exist. The value of GPL'd code is not zero. It's "whatever the market will bear," just like everything else. You and I could sell the same GPL'd code, and I guarantee that I could fetch a higher price. Explain that.
Then you chose the wrong license. GPL does not bar anyone from "taking [your] program, modifying it, and selling it for a profit." The only restriction is that they must provide the source, if requested, and retain the original license. Redhat, Mandrake, Suse, and every other Linux distribution that you can purchase, do exactly this.
When I release GPL code, I don't care who does what with it so long as it remains available to everyone. The money is secondary. The code that I release on a subscription model is not GPL for obvious reasons. That money pays my bills. Not every project needs the GPL; use it where it makes sense.
The terms "conservative" and "liberal" are often misapplied. In hard-line China, the ruling government is conservative and the dissidants are liberals. In the U.S., the term "liberal" implies something of a social democrat. I would be at the opposite end of that scale.
Yet, being at opposite ends of the political spectrum does not negate anyone's responsibility to act ethically. The distinction is largely one of how to realize a better world. That problems exist are not in dispute, and hence, we would naturally agree on many things. The degree to which these problems become our problem is neither conservatism nor liberalism. It is a matter of personal choice.
Liberals can be devoid of empathy as easily as conservatives. Unfortunately, in capitalist nations, people use "conservativism" as an excuse to rationalize their own personal failings. Many social democrats have their own problems which by my perception stem from an infatiguable sense of worldy guilt. Somewhere between the two, things seem to get done, albeit slowly.
So in a sense, from an uncharitable and rather cynical vantage point, I could be said to reside between unethical apathetics and guilt-stricken manics. Stated that way, you'd probably prefer to be in the middle, too. Conservativism could be summarized as being cautious; it does not have to mean callous.
I do want to state my opinion on one thing though. I hate to sound overly dramatic or inflammitory, but if we don't demand adequate living and working conditions in the places we get our goods we in the first world could probably expect revolution, terrorism, and other such unpleasantness in and from our third world sweatshop countries (colonies?).
Destablizing a region is not in the best interest of a capitalist. What Nike and similar companies are doing is plundering, largely because they can. This is not a conservative action, nor is it a capitalist action; it is simply an unethical one. The excuse that the region is already in turmoil is insufficient for my standards. The goal of an ethical capitalist is to develop the region, not exploit it.
The proper wage issue is where our political differences will show. From my viewpoint, doubling their wages will not necessarily improve their situation because money cannot readily be converted into what the people actually need to achieve long-term growth. Were they starting from scratch in a virgin forest on an undeveloped peninsula, they would have a better time of it. Instead they're starting in a resource-stripped, morally-destitute, cesspool. It will take more than doubling their income to solve these problems.
More to the point, the amount of money is not the issue, it's the security, both perceived and actual. If someone gets sick, will they work anyway, even at risk of serious injury, in order to avoid losing the job? Absolutely. There is no security, and that's half the problem.
A social democrat might then say that increasing the wages allows the person to save, and this savings is their security. The pragmatist would acknowledge that most will not, and I would stipulate that it discourages people from seeking better work. A position in a factory (or at Bob's Burger Bar for that matter) should be a transitory position, not a final one.
Nike would be providing a better service by investing in infrastructure like housing, education, water treatment, agriculture, and local markets so that over time, there would actually be a demand for skilled labor.
But before that, they need to fix the immediate problems- like not running sweatshops.
Corporations don't exist to "serve the public good"-- that's communism. Literally.
Actually, no. Try reading Marx for a better understanding of communism.
Corporations exist because it serves the public good.
The entity we describe as a "corporation" is a legal fiction used to facilitate trade. Nothing more. This capacity is provided by the States in order to "serve the public good" as was the original poster's statement.
Being conservative myself, I will be first person to say that this guy is either a troll or an idiot.
It never ceases to amaze me how few liberals respect the Bill of Rights, or basic human rights.
I find it amazing how many people, both conservative and liberal, have no appreciable grasp of the Bill of Rights. As for human rights though, the "liberals" clearly care more about it than you, or we wouldn't be hearing from them all the time. Whether their proposed ideas on the matter would be effective in remedying the situation is a different matter entirely.
Since "sweatshop" is a completely meaningless, derogatory term, Nike is being honest when they say they don't have any-- even if liberals say they do.
This is crap. You know, I know it, Nike knows it, and obviously the "liberals" know it. The term "sweatshop" is defined in Websters as "a shop or factory in which workers are employed for long hours at low wages and under unhealthy conditions." Date: 1892. If you prefer a friendlier sounding word then fine, but you are only deluding yourself.
And on the sweatshop thing-- the liberals hate sweatshops because they hate the poor.
Now this is just silly. Clearly the "liberals" would prefer that the workers made a reasonable wage, under reasonable conditions, on a reasonable schedule. They aren't talking about firing these people. They are talking about improving the conditions under which they work.
Of course, liberals think that somehow Nike is responsible for there not being lots of better jobs for them to go to. Because Liberals apparently never took economics.
Neither did you apparently. Nor civics, ethics, or philosophy. They are calling for Nike to improve the situation rather than profit off the backs of the unfortunate. Economically, that is very reasonable. We are not talking about the margins on tennis shoes. We are talking about the economic viability of these people. Their health is an integral part of that. Even conservatives like myself can see the difference. Where have you been?
I've been involved in theoretical and applied economics for nearly ten years. This is not a healthy free market. The supply-demand curve is skewed completely in favor of the wage providers. It is skewed so much so, that people are exchanging their health for wages. The "liberals" would say that price is too high, and I would tend to agree. I believe that it is unethical for Nike to perpetuate this situation when they have the opportunity to improve it. The historical fact that companies do not do this of their own accord is one of the many reasons why we have labor laws in the first place. From a conservative point of view, maintaining markets translates into long-term growth. And without that, we can expect nothing but tennis shoes from these people now or in the future.
And when you mod me down, realize you're trying to shut me up, just like liberals always do, because you disagree with what I say. I've brought up cogent points here- but I suspect you guys would rather I be denied that speech.
No, Voltaire had it right. It's just sad that I have to get lumped in with people like you.
There are a number of problems with the parent post.
1. Keeping hundreds, or even ten separate files as described, each half the size of the previous, is not plausible. I'd assume the author was a troll, but since no one else has mentioned it, perhaps the obvious fallacy with that idea is slipping past even the sharper readers. A 10MB file can be split in half at most 23 times before it is only 1 byte long, far fewer before the quality level is unacceptable. Secondly, the idea described in the article, provides for dynamic bitrates, not simply half the original bitrate. To provide even similar functionality, one would need files in ranges from 1MB to 10MB in relatively small increments, totaling well in excess the "twice the size of the largest file" as suggested. Even so, this would be deficient in that the bandwidth could not be throttled mid-stream.
2. Second, decoding and re-encoding the same file with a different bit rate will almost certainly result in poorer quality than the technique described. The safer, more straightforward solution, is to perform reduction operations on the transformed data, rather than the decompressed waveform. Otherwise, amplified artifacts from the original compression will be present in the new file.
3. Third, the strength of the poster's argument lies entirely in the choice of ratios. Downloading a 5MB file rather than a 10MB file leaves only 5MB remaining. To paraphrase, are you really going to opt to download the 10MB complete version when your software can download the remaining 5MB in half the time?
There are a number of problems which bitrate peeling address, not the least of which are 1) reduction of storage space as described previously, 2) dynamic bandwidth regulation of audio streams for streaming radio, future cellular phones, VOIP, and network appliances running on congested networks, 3) file size reduction without transcoding, 4) user-specified bandwidth on demand, 5) automatic preview generation from source without any extra administrative overhead.
I'll even add my own... the ability to download a very high quality file and start listening to it immediately at lower quality without interruption. By the time the file has played through, the download may be only 50% complete. If I decide not to continue with the download, I have wasted no more time than that necessary to listen to the file. If I want the file, I have only 50% remaining.
In some ways, this is similar to the rationale behind interleaved images, except that it is unlikely that you will need to listen to the same file repeatedly at progressively higher bitrates. Nothing prevents this of course.
Teenagers looking into subjects like homosexuality, sexually transmitted diseases, spouse/child-abuse, drug addiction, co-dependency, alcoholism, and date rape might have a difficult time if Mom and Dad are required to be present.
There is ample debate, thank God. Please read what the district court had to say on the matter. The requirement to ask for permission constitutes a sufficient barrier to access to be ruled unconstitutional. From their preliminary statement:
The evidence reflects that libraries can and do unblock the filters when a patron so requests. But it also reflects that requiring library patrons to ask for a Web site to be unblocked will deter many patrons because they are embarrassed, or desire to protect their privacy or remain anonymous. Moreover, the unblocking may take days, and may be unavailable, especially in branch libraries, which are often less well staffed than main libraries. Accordingly, CIPA's disabling provisions do not cure the constitutional deficiencies in public libraries' use of Internet filters.
Their reasoning is sound and the following example further illustrates this fact.
If you request that the filter be disabled, you are in effect stating that you will access material that may be deemed inappropriate by the library staff and the community in general. The only way to exonerate yourself is to divulge your purpose and the subject matter for which you are searching. If you do not, then it is reasonable to assume that your good name will be put in jeopardy. Since you may not wish to suggest to the library staff that you could potentially be gay, have testicular cancer, or be interested in providing homeschooling for your daughter, you are effectively blocked from accessing the material. All three topics have been blocked by filters in the past.
As for leaving explicit images on public computers, a change to library policy would be a more appropriate solution. CIPA was not designed to impede teenage pranksters. It was designed to block US citizens from accessing material deemed inappropriate from public libraries in direct violation of the First Amendment right to Free Speech.
IANAL, but in my experience, this is just proper use of time in the legal profession. Discussing what might happen in the future is of less value than what has already happened and what is before the court today. If people are unhappy with what comes tomorrow, and it appears that Microsoft is in violation of the agreement, then the judge can make further changes or even penalize them.
It is certainly not a free-ride for OSS folks. If anything, it may have leveled the playing field, but if you want to win, you'll still need to show up with the better team. I think that's doable.
Your point is quite valid. The distinction lies in how the software came to be in their possession. If one purchases Windows XP from a software retailer and installs it on his computer, first sale applies regardless of what the EULA says. If he calls Microsoft and negotiates a deal, the terms could be entirely different. Under contract law, the license agreement would prevail because the arrangement was negotiated prior to the transaction. EULA's have no such power since they follow after the transaction.
-Hope.
The numbers do not support your statement.
on
Yahoo Moving to PHP
·
· Score: 2
jonbrewer asserted:
There's no way you can back that statement up. Corporations generally have a few outward-facing web servers, and yes, these are most likely running apache,
but the vast majority of Intranet web servers are still IIS. After that you'll see Lotus Domino and iPlanet, and then Apache.
Emphasis mine. I think it is very clear from these figures, that Apache surpass IIS in deployment. In active servers alone, Apache has 66% to IIS' 24%.
This does not lend much credibility to the rest of your argument.
More importantly, it is a capital expense, similar to the purchase of computer equipment, automobiles, and other property necessary to run the business. Unlike coffee filters, light bulbs, and rent which are merely expenses, the software and the computer equipment on which it runs may be liquidated. This makes computers and software assets, albeit the quickly depreciating sort.
If KMart purchased the software under restrictions that prohibit resale, then yes, they are stuffed. Otherwise, the First Sale rules, and they can sell it as easily as any other capital they have on hand.
The release date of GTK 1.0 is immaterial. The author suggests that the design and framework for GTK was initiated from scratch as a response to KDE. This is simply incorrect. The people tasked with developing GNOME looked for a basis to begin their work. As the core design of the GIMP graphic library met their needs, they used it.
To suggest that GTK was a ground-up rewrite discounts all the original work done in the Gimp library. Even glib, the foundation for GTK shows a copyright of 1995-1997. Certaintly, they don't contend that glib was written in response to KDE as well.
Lastly, GTK is not a motif replacement library. Less-tif is a motif replacement library. GTK is an event-based object model that evolved out of the GIMP GUI library. And it is this object model that became the basis of Gnome; hence, the discussion.
On re-reading the parent posts, the issue of GTK and KDE's use of OOP is not wholly pertinent. The real issue is the GNOME designers' decision to base the underlying object layer on C rather than provide C bindings for applications that cannot use C++. This was a design decision, and one that I agree with entirely. Creating C wrappers for C++ objects is one thing. Creating extensible wrappers while preserving object inheritance and polymorphism is a major undertaking. Recognizing this, they naturally looked elsewhere.
A bit of KDE History
* KDE was founded in October 1996
From the front page of www.gtk.org we have:
GTK+ was initially developed for and used by the GIMP, the GNU Image Manipulation Program. Therefore, it is named "The GIMP Toolkit", so that the origins of the project are remembered. Today GTK+ is used by a large number of applications, and is the toolkit used by the GNU project's GNOME desktop.
From the gimp source code (libgimpbase.h) we have:
/* LIBGIMP - The GIMP Library
* Copyright (C) 1995-1997 Peter Mattis and Spencer Kimball
*/
So you are wrong. But that's not all. The date which KDE was started is immaterial. The date that GNOME was started is the only date relevent to the discussion since that was the point at which the decision not to use Harmony was made. Your speculation on the GNOME programmers unwillingness to learn OOP is unfounded. GTK is based on OOP design principles. It's merely implemented in C per the previously stated design criteria.
In the original code, only the multiplier was a double. The settlement and resultant prices where both mere floats, and the loss of precision was a non-issue since the resultant could have no more significant figures than the settlment price input. In terms of code, the choices were:
price = (float)mult * settlement_price;
or
price = (float)(mult * settlement_price);
The programmer choose the latter since the precision loss would take place at the end of the calculation rather than in the middle. This was the correct decision based on my experience and subsequent testing. The promotion of the settlement price to a double came later, the suite was regression tested, and finally, the price was promoted last.
As far as "red flags" go, you are absolutely correct. The programmer had manually overridden a compiler warning. Fortunately, he also left two additional bits of information in the code: 1. the cast itself, the purpose of which is not self-evident as described above, and 2. the hungarian notation used below, which resolves the question of why the cast was made in the first place.
fPrice = (float)(dMult * fSettlePrice);
The auditing programmer can plainly see that a cast is necessary from the HN prefixes. (This company uses "f" for float which departs from classic HN; every company has its standards.)
In answer to your questions though: a double times a double is a double. A double times a float is a double (the float is promoted). Casting from a double to float results in a loss of precision in the mantissa (from approximately 15 decimal digits to 6) and a possible overflow condition in the exponent. The application and its libraries run solely on hardware that supports IEEE floating point numbers. FLOAT_MAX is not a valid value for any of the numbers specified.
Further, from a design point of view, the multiplier can at most be 1000.0, but ordinarily will be around 1.0. The need to use a double for the multiplier was caused by the need to generate the value 1.0 + 1/1024. At minimum, you need 11 digits of precision to store the value with any accuracy (conveniently, it stores exact). This particular value would be equivalent to 1.00098 in the code above which was decided to be adequate.
The settlement price comes from another system, so the value can be no more accurate than we receive it. The resultant price can have no more digits of precision than the settlement price, so truncating was considered reasonable.
Ultimately, it was decided to promote everything to doubles after bit errors creeped in with the larger values occurring in some foreign currencies. Internationalization can be taxing on legacy code.
Lastly, all these price values are theoretical, meaning that they do not represent actual sums of money for transactions. Those values are stored in fixed point format to eliminate the fractional cents issue.
So in all, I applaud your skeptical eye towards software design. The questions you asked are questions that normally come up at our design meetings.
It was implied earlier that if the compiler can read it, the code is done. This is incorrect. The code must satisfy three agents- the compiler, the next developer, and the code auditor. HN is about declaring intent. If the code violates the stated intent as written, then there is a high likelihood of an error in implementation.
// bad code
++children;
if (index < 0) foo();
if (current == target) bar();
// Greatly illucidated by HN
++bChildren;
if (uIndex < 0) Foo();
if (dCurrent == dTarget) Bar();
All three lines are wrong- boolean values should never by incremented, even if the underlying type is an integer. Comparing an unsigned integer less than zero makes no sense; a corner case has changed, and the code probably no longer works correctly. Equality comparison between two doubles is usually a bad idea. But of course, we all know that. The question is whether these problems can be gleaned immediately from the code as written, because all three cases will compile. A smart compiler might warn on the second condition, but there's no guarantee.
QT had more than license issues. One of the GNOME design goals was an all C implementation. KDE did not meet that criteria and therefore a new implementation was started. It was not however started from scratch. GNOME is built on GTK which is built on GLib. Whether this was a wise decision or not only time will tell. I personally use C for libraries and C++ for applications. It gives me more leverage later on if I want to incorporate that functionality into PHP, Perl, Python, Java, or whatever.
Well, I would not lose sleep over it since it does not sound like you would be considered here. That said however, to respond to your question about programming practices, the issue is not whether the code is understandable on paper, but rather whether the "fundamental pragmatic programming tools" will help you resolve problems with code such as this:
price = (float)(mult * settle_price);
The original programmer cast the result to a float to avoid a precision warning. This was the correct decision at the time since price was in fact a low-precision float. Now however, price has been changed from a float to a double, this code will continue to operate with the lower precision, and the compiler will fail to flag it with a warning. By comparison, the following code can be easily diagnosed as incorrect, by eye, without the need for an IDE.
dPrice = (float)(dMult * dSettlePrice);
Plainly, casting a double to a float is unnecessary when the resultant is a double. Of course, you would only know that the multipler and settlement prices were doubles by using HN, a spiffy IDE with a code browser, or the rest of the code, but as you can see HN is the most efficient of the three since it requires the least amount of overhead. Additionally, programmers from other projects can quickly validate this code without the need to hunt down the type declarations of mult and settle_price, or build the browse info for the project which could easily take hours.
In the end, we are responsible for writing and validating the code; IDE's and code browsers are merely tools for analyzing and debugging. You cannot relegate the whole of type safety to the compiler, as is apparent from the example above.
The GPL explicitly states that it cannot be released in this fashion. It further states that if the distribution cannot be released such that it complies with the GPL terms, it cannot be released at all. Hence, the addition of an NDA violates the GPL, and would prevent you from legally distributing.
From the GPL FAQ:
Does the GPL allow me to distribute a modified or beta version under a nondisclosure agreement?
No. The GPL says that anyone who receives a copy of your version from you has the right to redistribute copies (modified or not) of that version. It does not give you permission to distribute the work on any more restrictive basis.
And again from the GPL itself:
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein...
Seems fairly clear to me.
Also, claiming that the individuals under NDA are thereby employees of your company will not stand up in court. The copyright holders would naturally subpoena your payroll and invalidate that argument. If you don't pay them wages, not to mention maintain and submit all the associated tax records, you do not employ them. Period.
Hungarian Notation saves our ass. My group maintains several million lines of code, and we change variable types all the time. By changing both the type of the variable and the prefix on its name, we effectively cause all code that referenced that variable to fail to compile. This is the desired result.
The task of progogating a change of variable type includes visiting the affected code and verifying that the change will not have unwanted consequences. It almost always does. Hungarian notation allows you to do this quickly, effectively, and in a single pass. Waiting for the regression test to come back negative is reckless and unprofessional.
We don't allow code to be checked in if it is not in HN. If it can't be visually audited for type correctness by an independent team, without the use of an IDE or some type of code browser, it's a liability and therefore has no business in our code base.
Funny that you should mention Quickbooks because the current service pack for IE6 thoroughly break the Quickbook extensions. The rumor that I heard coming from Intuit is that the development team is quietly looking into using a different browser. Something that comes with source code that they can control...
Slashdot Mirror
Your argument is sophomoric, having only the appearance of a logical basis when in fact it is completely fallacious.
Believing that the ability to download a piece of software for "free" makes the "market value" zero shows a complete lacking of understanding of the words "free" (as in beer) and "market value." Moron may have been a strong word; ignorant would have been more accurate.
The supply is never infinite, and the price is never zero. There is no single "market value."
As for boasting, it's wholly unnecessary. You could make the same general statement and be 100% correct. The fact that you do not understand that is due to your limited understanding of "market value."
-Hope
Your understanding of market economies is a bit thin. You hint at the actual situation when you say that it is "roughly zero," recognizing that it is neither zero, nor actually quantifiable. This is because a unique market exists for every two people at every geographic location at every moment in time. Specifically, you're post fails to account for a number of very important factors including:
1. information costs
2. transportation costs
3. any number of utility functions that may apply, not the least of which is perceived value and trust that the code is what it claims.
A glass of water is free, by law, in some U.S. states and yet you can still find it in bottles for a dollar at the corner convenience store. Ask a guy dying of thirst in a remote desert about the value of water, monetarily or otherwise. Why, it's $0, of course.
Two copies of the same code will have different values to different people in different circumstances. That basic principle is why market economies exist.
-Hope
That's the most sophmoronic logic I've ever heard.
The fact that something can be obtained for free does NOT mean that the value is zero. Poor Understanding of Economics Mistake Number One.
Different people value things differently and for different reasons. This is why arbitration conditions exist. The value of GPL'd code is not zero. It's "whatever the market will bear," just like everything else. You and I could sell the same GPL'd code, and I guarantee that I could fetch a higher price. Explain that.
-Hope
Then you chose the wrong license. GPL does not bar anyone from "taking [your] program, modifying it, and selling it for a profit." The only restriction is that they must provide the source, if requested, and retain the original license. Redhat, Mandrake, Suse, and every other Linux distribution that you can purchase, do exactly this.
When I release GPL code, I don't care who does what with it so long as it remains available to everyone. The money is secondary. The code that I release on a subscription model is not GPL for obvious reasons. That money pays my bills. Not every project needs the GPL; use it where it makes sense.
-Hope
"I'm sorry, but your spaceship is operating outside of your home galaxy. Please contact sales for a service upgrade."
-Hope
The terms "conservative" and "liberal" are often misapplied. In hard-line China, the ruling government is conservative and the dissidants are liberals. In the U.S., the term "liberal" implies something of a social democrat. I would be at the opposite end of that scale.
Yet, being at opposite ends of the political spectrum does not negate anyone's responsibility to act ethically. The distinction is largely one of how to realize a better world. That problems exist are not in dispute, and hence, we would naturally agree on many things. The degree to which these problems become our problem is neither conservatism nor liberalism. It is a matter of personal choice.
Liberals can be devoid of empathy as easily as conservatives. Unfortunately, in capitalist nations, people use "conservativism" as an excuse to rationalize their own personal failings. Many social democrats have their own problems which by my perception stem from an infatiguable sense of worldy guilt. Somewhere between the two, things seem to get done, albeit slowly.
So in a sense, from an uncharitable and rather cynical vantage point, I could be said to reside between unethical apathetics and guilt-stricken manics. Stated that way, you'd probably prefer to be in the middle, too. Conservativism could be summarized as being cautious; it does not have to mean callous.
Destablizing a region is not in the best interest of a capitalist. What Nike and similar companies are doing is plundering, largely because they can. This is not a conservative action, nor is it a capitalist action; it is simply an unethical one. The excuse that the region is already in turmoil is insufficient for my standards. The goal of an ethical capitalist is to develop the region, not exploit it.The proper wage issue is where our political differences will show. From my viewpoint, doubling their wages will not necessarily improve their situation because money cannot readily be converted into what the people actually need to achieve long-term growth. Were they starting from scratch in a virgin forest on an undeveloped peninsula, they would have a better time of it. Instead they're starting in a resource-stripped, morally-destitute, cesspool. It will take more than doubling their income to solve these problems.
More to the point, the amount of money is not the issue, it's the security, both perceived and actual. If someone gets sick, will they work anyway, even at risk of serious injury, in order to avoid losing the job? Absolutely. There is no security, and that's half the problem.
A social democrat might then say that increasing the wages allows the person to save, and this savings is their security. The pragmatist would acknowledge that most will not, and I would stipulate that it discourages people from seeking better work. A position in a factory (or at Bob's Burger Bar for that matter) should be a transitory position, not a final one.
Nike would be providing a better service by investing in infrastructure like housing, education, water treatment, agriculture, and local markets so that over time, there would actually be a demand for skilled labor.
But before that, they need to fix the immediate problems- like not running sweatshops.
-Hope
Actually, no. Try reading Marx for a better understanding of communism.
Corporations exist because it serves the public good.
The entity we describe as a "corporation" is a legal fiction used to facilitate trade. Nothing more. This capacity is provided by the States in order to "serve the public good" as was the original poster's statement.
-Hope
I find it amazing how many people, both conservative and liberal, have no appreciable grasp of the Bill of Rights. As for human rights though, the "liberals" clearly care more about it than you, or we wouldn't be hearing from them all the time. Whether their proposed ideas on the matter would be effective in remedying the situation is a different matter entirely.
This is crap. You know, I know it, Nike knows it, and obviously the "liberals" know it. The term "sweatshop" is defined in Websters as "a shop or factory in which workers are employed for long hours at low wages and under unhealthy conditions." Date: 1892. If you prefer a friendlier sounding word then fine, but you are only deluding yourself. Now this is just silly. Clearly the "liberals" would prefer that the workers made a reasonable wage, under reasonable conditions, on a reasonable schedule. They aren't talking about firing these people. They are talking about improving the conditions under which they work.Neither did you apparently. Nor civics, ethics, or philosophy. They are calling for Nike to improve the situation rather than profit off the backs of the unfortunate. Economically, that is very reasonable. We are not talking about the margins on tennis shoes. We are talking about the economic viability of these people. Their health is an integral part of that. Even conservatives like myself can see the difference. Where have you been?
I've been involved in theoretical and applied economics for nearly ten years. This is not a healthy free market. The supply-demand curve is skewed completely in favor of the wage providers. It is skewed so much so, that people are exchanging their health for wages. The "liberals" would say that price is too high, and I would tend to agree. I believe that it is unethical for Nike to perpetuate this situation when they have the opportunity to improve it. The historical fact that companies do not do this of their own accord is one of the many reasons why we have labor laws in the first place. From a conservative point of view, maintaining markets translates into long-term growth. And without that, we can expect nothing but tennis shoes from these people now or in the future.
No, Voltaire had it right. It's just sad that I have to get lumped in with people like you.
-Hope
There are a number of problems with the parent post.
1. Keeping hundreds, or even ten separate files as described, each half the size of the previous, is not plausible. I'd assume the author was a troll, but since no one else has mentioned it, perhaps the obvious fallacy with that idea is slipping past even the sharper readers. A 10MB file can be split in half at most 23 times before it is only 1 byte long, far fewer before the quality level is unacceptable. Secondly, the idea described in the article, provides for dynamic bitrates, not simply half the original bitrate. To provide even similar functionality, one would need files in ranges from 1MB to 10MB in relatively small increments, totaling well in excess the "twice the size of the largest file" as suggested. Even so, this would be deficient in that the bandwidth could not be throttled mid-stream.
2. Second, decoding and re-encoding the same file with a different bit rate will almost certainly result in poorer quality than the technique described. The safer, more straightforward solution, is to perform reduction operations on the transformed data, rather than the decompressed waveform. Otherwise, amplified artifacts from the original compression will be present in the new file.
3. Third, the strength of the poster's argument lies entirely in the choice of ratios. Downloading a 5MB file rather than a 10MB file leaves only 5MB remaining. To paraphrase, are you really going to opt to download the 10MB complete version when your software can download the remaining 5MB in half the time?
There are a number of problems which bitrate peeling address, not the least of which are 1) reduction of storage space as described previously, 2) dynamic bandwidth regulation of audio streams for streaming radio, future cellular phones, VOIP, and network appliances running on congested networks, 3) file size reduction without transcoding, 4) user-specified bandwidth on demand, 5) automatic preview generation from source without any extra administrative overhead.
I'll even add my own... the ability to download a very high quality file and start listening to it immediately at lower quality without interruption. By the time the file has played through, the download may be only 50% complete. If I decide not to continue with the download, I have wasted no more time than that necessary to listen to the file. If I want the file, I have only 50% remaining.
In some ways, this is similar to the rationale behind interleaved images, except that it is unlikely that you will need to listen to the same file repeatedly at progressively higher bitrates. Nothing prevents this of course.
-Hope
Teenagers looking into subjects like homosexuality, sexually transmitted diseases, spouse/child-abuse, drug addiction, co-dependency, alcoholism, and date rape might have a difficult time if Mom and Dad are required to be present.
-Hope
If you request that the filter be disabled, you are in effect stating that you will access material that may be deemed inappropriate by the library staff and the community in general. The only way to exonerate yourself is to divulge your purpose and the subject matter for which you are searching. If you do not, then it is reasonable to assume that your good name will be put in jeopardy. Since you may not wish to suggest to the library staff that you could potentially be gay, have testicular cancer, or be interested in providing homeschooling for your daughter, you are effectively blocked from accessing the material. All three topics have been blocked by filters in the past.
As for leaving explicit images on public computers, a change to library policy would be a more appropriate solution. CIPA was not designed to impede teenage pranksters. It was designed to block US citizens from accessing material deemed inappropriate from public libraries in direct violation of the First Amendment right to Free Speech.
-HopeOS
IANAL, but in my experience, this is just proper use of time in the legal profession. Discussing what might happen in the future is of less value than what has already happened and what is before the court today. If people are unhappy with what comes tomorrow, and it appears that Microsoft is in violation of the agreement, then the judge can make further changes or even penalize them.
It is certainly not a free-ride for OSS folks. If anything, it may have leveled the playing field, but if you want to win, you'll still need to show up with the better team. I think that's doable.
-Hope
Your point is quite valid. The distinction lies in how the software came to be in their possession. If one purchases Windows XP from a software retailer and installs it on his computer, first sale applies regardless of what the EULA says. If he calls Microsoft and negotiates a deal, the terms could be entirely different. Under contract law, the license agreement would prevail because the arrangement was negotiated prior to the transaction. EULA's have no such power since they follow after the transaction.
-Hope.
This does not lend much credibility to the rest of your argument.
-Hope
More importantly, it is a capital expense, similar to the purchase of computer equipment, automobiles, and other property necessary to run the business. Unlike coffee filters, light bulbs, and rent which are merely expenses, the software and the computer equipment on which it runs may be liquidated. This makes computers and software assets, albeit the quickly depreciating sort.
If KMart purchased the software under restrictions that prohibit resale, then yes, they are stuffed. Otherwise, the First Sale rules, and they can sell it as easily as any other capital they have on hand.
-Hope
The release date of GTK 1.0 is immaterial. The author suggests that the design and framework for GTK was initiated from scratch as a response to KDE. This is simply incorrect. The people tasked with developing GNOME looked for a basis to begin their work. As the core design of the GIMP graphic library met their needs, they used it.
To suggest that GTK was a ground-up rewrite discounts all the original work done in the Gimp library. Even glib, the foundation for GTK shows a copyright of 1995-1997. Certaintly, they don't contend that glib was written in response to KDE as well.
Lastly, GTK is not a motif replacement library. Less-tif is a motif replacement library. GTK is an event-based object model that evolved out of the GIMP GUI library. And it is this object model that became the basis of Gnome; hence, the discussion.
-Hope
On re-reading the parent posts, the issue of GTK and KDE's use of OOP is not wholly pertinent. The real issue is the GNOME designers' decision to base the underlying object layer on C rather than provide C bindings for applications that cannot use C++. This was a design decision, and one that I agree with entirely. Creating C wrappers for C++ objects is one thing. Creating extensible wrappers while preserving object inheritance and polymorphism is a major undertaking. Recognizing this, they naturally looked elsewhere.
-Hope
From the gimp source code (libgimpbase.h) we have:
So you are wrong. But that's not all. The date which KDE was started is immaterial. The date that GNOME was started is the only date relevent to the discussion since that was the point at which the decision not to use Harmony was made. Your speculation on the GNOME programmers unwillingness to learn OOP is unfounded. GTK is based on OOP design principles. It's merely implemented in C per the previously stated design criteria.
Thanks for playing.
-Hope
In the original code, only the multiplier was a double. The settlement and resultant prices where both mere floats, and the loss of precision was a non-issue since the resultant could have no more significant figures than the settlment price input. In terms of code, the choices were:
price = (float)mult * settlement_price;
or
price = (float)(mult * settlement_price);
The programmer choose the latter since the precision loss would take place at the end of the calculation rather than in the middle. This was the correct decision based on my experience and subsequent testing. The promotion of the settlement price to a double came later, the suite was regression tested, and finally, the price was promoted last.
As far as "red flags" go, you are absolutely correct. The programmer had manually overridden a compiler warning. Fortunately, he also left two additional bits of information in the code: 1. the cast itself, the purpose of which is not self-evident as described above, and 2. the hungarian notation used below, which resolves the question of why the cast was made in the first place.
fPrice = (float)(dMult * fSettlePrice);
The auditing programmer can plainly see that a cast is necessary from the HN prefixes. (This company uses "f" for float which departs from classic HN; every company has its standards.)
In answer to your questions though: a double times a double is a double. A double times a float is a double (the float is promoted). Casting from a double to float results in a loss of precision in the mantissa (from approximately 15 decimal digits to 6) and a possible overflow condition in the exponent. The application and its libraries run solely on hardware that supports IEEE floating point numbers. FLOAT_MAX is not a valid value for any of the numbers specified.
Further, from a design point of view, the multiplier can at most be 1000.0, but ordinarily will be around 1.0. The need to use a double for the multiplier was caused by the need to generate the value 1.0 + 1/1024. At minimum, you need 11 digits of precision to store the value with any accuracy (conveniently, it stores exact). This particular value would be equivalent to 1.00098 in the code above which was decided to be adequate.
The settlement price comes from another system, so the value can be no more accurate than we receive it. The resultant price can have no more digits of precision than the settlement price, so truncating was considered reasonable.
Ultimately, it was decided to promote everything to doubles after bit errors creeped in with the larger values occurring in some foreign currencies. Internationalization can be taxing on legacy code.
Lastly, all these price values are theoretical, meaning that they do not represent actual sums of money for transactions. Those values are stored in fixed point format to eliminate the fractional cents issue.
So in all, I applaud your skeptical eye towards software design. The questions you asked are questions that normally come up at our design meetings.
It was implied earlier that if the compiler can read it, the code is done. This is incorrect. The code must satisfy three agents- the compiler, the next developer, and the code auditor. HN is about declaring intent. If the code violates the stated intent as written, then there is a high likelihood of an error in implementation.
All three lines are wrong- boolean values should never by incremented, even if the underlying type is an integer. Comparing an unsigned integer less than zero makes no sense; a corner case has changed, and the code probably no longer works correctly. Equality comparison between two doubles is usually a bad idea. But of course, we all know that. The question is whether these problems can be gleaned immediately from the code as written, because all three cases will compile. A smart compiler might warn on the second condition, but there's no guarantee.
It's been fun.
-Hope
QT had more than license issues. One of the GNOME design goals was an all C implementation. KDE did not meet that criteria and therefore a new implementation was started. It was not however started from scratch. GNOME is built on GTK which is built on GLib. Whether this was a wise decision or not only time will tell. I personally use C for libraries and C++ for applications. It gives me more leverage later on if I want to incorporate that functionality into PHP, Perl, Python, Java, or whatever.
-Hope
The original programmer cast the result to a float to avoid a precision warning. This was the correct decision at the time since price was in fact a low-precision float. Now however, price has been changed from a float to a double, this code will continue to operate with the lower precision, and the compiler will fail to flag it with a warning. By comparison, the following code can be easily diagnosed as incorrect, by eye, without the need for an IDE. Plainly, casting a double to a float is unnecessary when the resultant is a double. Of course, you would only know that the multipler and settlement prices were doubles by using HN, a spiffy IDE with a code browser, or the rest of the code, but as you can see HN is the most efficient of the three since it requires the least amount of overhead. Additionally, programmers from other projects can quickly validate this code without the need to hunt down the type declarations of mult and settle_price, or build the browse info for the project which could easily take hours.
In the end, we are responsible for writing and validating the code; IDE's and code browsers are merely tools for analyzing and debugging. You cannot relegate the whole of type safety to the compiler, as is apparent from the example above.
-Hope
The comment was in response to HN being an impediment to changing variable types. I believe the argument stands on that merit.
-Hope
From the GPL FAQ: And again from the GPL itself:
Seems fairly clear to me.
Also, claiming that the individuals under NDA are thereby employees of your company will not stand up in court. The copyright holders would naturally subpoena your payroll and invalidate that argument. If you don't pay them wages, not to mention maintain and submit all the associated tax records, you do not employ them. Period.
-Hope
Hungarian Notation saves our ass. My group maintains several million lines of code, and we change variable types all the time. By changing both the type of the variable and the prefix on its name, we effectively cause all code that referenced that variable to fail to compile. This is the desired result.
The task of progogating a change of variable type includes visiting the affected code and verifying that the change will not have unwanted consequences. It almost always does. Hungarian notation allows you to do this quickly, effectively, and in a single pass. Waiting for the regression test to come back negative is reckless and unprofessional.
We don't allow code to be checked in if it is not in HN. If it can't be visually audited for type correctness by an independent team, without the use of an IDE or some type of code browser, it's a liability and therefore has no business in our code base.
-Hope
Funny that you should mention Quickbooks because the current service pack for IE6 thoroughly break the Quickbook extensions. The rumor that I heard coming from Intuit is that the development team is quietly looking into using a different browser. Something that comes with source code that they can control...
-Hope