It's a different way of releasing software, but it still has very strong and significant restrictions on it's use.
Name one such use -- one that does not derive from licensing restrictions placed by someone else on non-GPL'ed code.
Here is the GPL, point out where it discriminates against corporations, individuals, governments, or anyone else, in terms of their right to use the software, as source code or binaries.
It definatley provides some advantages to both the general puplic and the govenrment. I don't think the NSA should ignore Linux, but I don't think they should give it significant pereferential treatment either.
What part of "Linux is not an individual or corporation" do you not understand?
They aren't giving Linux preferential treatment -- they're giving the public preferential treatment! (Or, they were.)
If Linux happens to be, for whatever combination of reasons, the best public product for the job they have at hand, then there's nothing wrong with them enhancing it instead of, say, OpenBSD -- and vice versa, should they wish to enhance that.
Again, Linux is a free public product, like the C language, or the Ada language, or the FORTRAN language -- in some cases, products that, via trademark especially, have some "onerous restrictions" beyond those of the GPL (like, you can't call something X unless your implementation passes a rigorous test suite).
It's obviously throwing your brain a curve because, unlike standards, it's an actual free implementation, which post-1980s software kiddies generally can't conceive of in a "Free As In GNU" sense.
But the government has long been in the "business" of freely enhancing free public implementations of software as well -- implementations that have almost always been competitive with proprietary offerings in their day.
Linux is just another case of this.
And if it wasn't for Microsoft wetting its pants over Linux as a competitor, we wouldn't be having this discussion -- it'd be assumed a reasonable thing for government to do. (There might be some mumbling resentment over not picking a *BSD, of course, which gets into technical issues I'm not prepared to address.)
So, the question is this: why are you working as a shill for Microsoft's business interests?
It's not a lie. For example, any employee of any corporation cannot legally include a GPL product in any of their own work without explicit permission of a signatory executive officer of the company.
So a corporation can legally include a GPL product in any of their own work.
Which means saying that GPL'ed source code cannot be used commercially IS A LIE, your attempts at deflecting the issue notwithstanding.
Your position that GPL software is "specifically available to everyone" applies more to the LGPL, which doesn't have a poison pill clause like the full GPL. This position of yours is really misrepresentative.
Here is the GPL. Search it for the text "commerc", and you'll find only one occurrence, in a trivial and unrelated place.
The GPL has no poison-pill clause against corporations or commerce.
You, sir, clearly know that, given your detailed and willfully-misdirected rebuttal to my explanation, so you are intentionally lying.
Oh really? Let's see if you can spot which of these does not belong:
Linux shouldn't get a free ride (due to government improving it on taxpayer monies).
Federal law shouldn't get a free ride (due to government "improving" it on taxpayer monies).
MS Windows shouldn't get a free ride (due to government writing improvements for it on taxpayer monies).
The FORTRAN language shouldn't get a free ride (due to government proposing new extensions for it on taxpayer monies).
Give up? The answer is #3. Why? Because it's the only one that isn't a free public entity -- the others all are, and that's why there are all legitimate "targets" for improvement by a government (assuming it's going to spend taxpayer monies in such efforts anyway). (In fact, all three have been improved by government -- for FORTRAN, it was MIL-STD 1753, I believe, ages ago.)
Your use of "Linux", on the other hand, suggests you cannot distinguish a free, public operating system from a single-sourced, proprietary operating system (or, more precisely, from the company that produces it).
Put another way: what individual or organizations benefits from the taxpayer-funded improvements to the software in question?
For #s 1, 2, and 4 above, the answer is: the public (in fact, the entire planet); for #3, the answer is: Microsoft only -- everyone else has to pay them to realize the improvements, so they aren't direct beneficiaries of the improvements.
I realize you aren't necessarily advocating that the government spend $$ to improve Windows for free, but thinking that Linux shouldn't be improved for free is, frankly, seriously misguided.
(And what people arguing against GPL'ed government software are saying, in essence, is: let's make sure Microsoft can resell taxpayer-funded code at a profit, with severe license restrictions, to people who'll generally have no idea to what extent the software they're buying is made up of their own taxpayer-funded software.)
So proprietary software vendors (like Microsoft) DON'T get to use the improvements - at least not verbatim. The improvements carry the Gnu
Public Virus and can't be integrated into the vendor's code base without risking a suit from the FSF for GPL violation.
Microsoft already does release GPL'ed code it did not write (nor explicitly ask permission to release -- e.g. of me) and yet does not risk such a suit.
And, as another comment points out, that they can't simply fold NSA's changes into Windows and distribute it under the licensing MS finds convenient is Microsoft's choice -- a choice they can undo in an instant.
Here's another thing Microsoft can't do with any government code put out in the public domain: it can't monopolize access to that code the way it does to Windows code it writes itself.
That means anything the government writes, or modifies, cannot be used by Microsoft to further its monopoly, since the public can always choose to get at the free, PD versions of the enhancements instead of having to buy MS's formulations (involving those enhancements intertwined with proprietary MS code).
So, just as with the case you complain about, the fact that the government releases code to the public, instead of simply handing it directly over to Microsoft for monopoly control (and I mean this in the copyright/patent, not desktop-PC, sense), means that Microsoft cannot benefit from this expenditure of taxpayer money in the ways to which it has chosen to become accustomed.
Will you therefore argue that government is to never distribute software except to Microsoft?
Else, please explain why the US government, or any other people-funded agency, should be expected to avoid public-minded licenses like the GPL and BSD simply to conform to the business models certain corporations happen to find convenient under current market conditions.
(These licenses are public-minded in the sense that they are specifically authored to ensure long-term free public access to the code -- the source [GPL] or the binaries derived therefrom [BSD], put simply -- and they do not discriminate against any individual or organization, nor do they restrict freedoms such as of speech once any such entity accepts the terms of these licenses. It is precisely this sort of public-minded, freedom-oriented licensing that Microsoft finds frightening, because it cannot conceive of a future in which its business model, of selling closed software under licenses that stifle speech to people who think Software Is Magical And Thus Requires Great Expenditures By Huge Corporations, has been eroded by the public discovering, on its own, that software isn't so magical after all. But MS has specifically targeted the GPL and not BSD license, because with the BSD license it can at least "keep up" with the arms/feature race in theory.)
Microsoft simply can't use code that's under the GPL (they'd have to release all their code)
Sheesh, where do you people pick up such BS?
Microsoft is both using and releasing GPL'ed code right now, including my own GPL'ed code, GNU Fortran (g77). (I think they call it "Unix for Windows", it comes from Interix, a company they bought?)
The only issue is whether Microsoft feels comfortable competing with a security-enhanced version of Linux that it can't take and cannibalize to suit the license restrictions they choose to impose.
The GPL, like BSD, both require copyright as an underlying protection, but they both serve the public interest -- one buy ensuring access to source code for anyone possessing a derived copy of the product, the other by not doing so.
That there might be legislation requiring "public-domaining" any government-written code is a legal hindrance to the government writing GPL'ed or BSD'ed code, but the spirit is preserved by changing the statutes to permit licenses that assure anyone access to the product, such as the GPL and BSD licenses.
As long as the "restrictions" placed by the licenses on copying and distribution avoid preventing people from making straight copies and distributing to whomever they please, for example, it hardly makes a difference, in terms of the purposes of government authorship, whether such licenses are used versus simply placing works in the public domain.
But one advantage the GPL will always have over BSD and PD distributions: when the government, or even a state or local government, ends up with software (e.g binaries) derived from government-written software, that government will be assured access to the complete source code for the product only if the original code was distributed under the terms of the GPL.
Such assurances go a long way towards protecting the public good in terms of safety, security, openness, and even more mundane things such honesty in procurement (since it's harder to hide the fact that they're buying, from a vendor, 100 lines of vendor-specific code buried in 100,000 lines of "public" source code, when the complete source code is "vended").
An e-mail with links to the WWW is, essentially, an e-mail that was never completely delivered.
Generally, yes.
Of course, when the sender knows the recipient reads email in a fully-connected environment, he can take advantage of that. I do all the time with my wife, sister, and her husband (at least I assume he's fully-connected when reading email), e.g. by emailing them a link with a very short description, leaving it to them to click on the link.
I wouldn't do this to someone who might read email offline. Though the kind of audience that does that is probably changing; I'm "trailing-edge", so I've only recently gone from offline reading to online-via-Broadband reading, whereas my wife is "leading-edge" -- she had five computers on her desk at home the other day, from an old Mac SE to one of them Blackberry thingies -- so she's probably going beyond always-connected to sometimes-offline-reading, due to her frequent travels and increased reliance on wireless communication (which must cope with being unconnected while still allowing reading and composing of email).
Another practical distinction between email and web pages is that people have historically chosen whether to keep or trash their mail. Email too.
This is distinct from shopping/browsing in that one expects to be able to locate useful nuggets of info in years-old mails -- something that is impossible if mails/emails contain, primarily, pointers to external data that might have been "live" near the time of delivery but has since died, or at least changed substantially.
I guess it's important, yet sometimes difficult for techies like us, to distinguish between the concept of email and the technical utility. When I email links to my family and friends, I'm not really mailing them so much as using email (SMTP, you could say) as a delivery mechanism, one that's somewhat different -- more "laid-back", queued, formal, etc. -- than instant messaging, which I've yet to use.
In that context -- using email as simply a data-delivery mechanism -- it doesn't really matter much what's in the email, because both the sender and recipient are more "tightly bound together" in terms of what kinds of communications are expected and tolerated.
But non-techies, such as newcomers to the field of computing-enabled communication, are, IMO, best served by software that helps them use the technologies in ways that are most consistent with their target audience (other newcomers). In this case, that'd be software that helps them avoid delivering email in the form of web pages (HTML), among other things.
I agree with him, because while he gives physical-universe explanations for his expectations, the fact is that email is conceptually different, in the sense that it is mail that is received, from web sites, in the sense that they're places that are visited.
He highlights these differences using real-world examples. That doesn't mean flaws in his analogy indicate flaws in his reasoning.
(For example, you ask "If I read my real mail out at the mall - do I have privacy rights to it?" -- yes, you still do, except to the extent it is obvious to anyone that you are reading mail, that you are reading N pieces of mail, that some of them might have big bold print readable from a distance...but the fact that you aren't at home does not automatically grant someone permission to "borrow" your mail and read it, or even read it over your shoulder, on the grounds that you've "given up privacy" by doing it in a public place. That's true regardless of whether it's mail or email. None of this means the rest of your argument is invalid, of course.)
Some of your arguments are just trivial technological twists, though, and do little to illuminate the issues.
So let me try this out on you. The main difference between reading mail/email and going shopping/browsing is that the former is assumed to be capable of being done by the client in his own home, on his own schedule, without necessarily being "connected" to the rest of the world. The latter is assumed to require all those things -- to leave the home (physically, or to leave the home computer virtually by reaching out to an external web site and giving it some degree of control over your computer); to do so on a schedule convenient to the provider of services; and to do so while some kind of connection (Internet, roads, walkways, etc.) to the provider via outside world is maintained.
Therefore, given that HTML is specifically designed as a hypertext markup language -- a language making the browsing activity easier and broader for the client -- it is reasonable to conclude that it is not automatically suitable for a communications medium, email/mail, that one must assume will be read when hypertext links (and similar paraphernalia) might not be operative, or welcome, by the client.
(How would you feel if you fetched all your email onto your computer, disconnected, walked to a park to read it, and found that every single message was simply a link to someplace on the 'net -- to which you were no longer connected -- containing the full text of the message? That's certainly something HTML supports, so I would conclude from your support of HTML as a natural technology for email that you wouldn't mind. I certainly would mind, since I think it should be clear to everyone that, extreme cases aside, emails, like regular mails, should be readable "offline", whatever that means.)
That's not to say HTML as a technology cannot be embedded in email, since, obviously, it can. But what email readers should default to is what would amount to a subset of HTML that allows only browsing within the email itself (plus, in certain cases such as corporate LANs, within the known-safe LAN, or network), disallows arbitrary code being run on behalf of the provider (since the client must be assumed to wish to control the entire experience), and so on. And email authoring software, in recognition of this general convention, would help the user writing an email to either obey the conventions or understand that, in not doing so, the reader might choose to ignore part of the message (perhaps by default -- not even seeing that there's a choice to be made in an individual case).
In short, HTML email is, as practiced today by email-sending software, closer to sending raw executables and expecting email clients to simply run them to "serve" the user who wishes to read them, than it is to sending plain text and other markup that obeys the concept that the client is in complete control of the mail-reading experience, including where, when, and with what degree of connecitivity to the outside world he is reading his mail.
(And, yes, I've bitten the heads off a few friends who insist on sending snail-mail with chunks of glitter that "explode" on you when you open it. If I wanted glitter all over my clothes, I'd go party with some 12-year-old girls or something.)
Remember, the question isn't under what circumstances might someone read mail, shop, or browse -- it's under what circumstances must someone designing an infrastructure supporting these activities take into account as the most pertinent, in terms of what users of that infrastructure expect, how their rights are best protected, and so on.
So, no, it doesn't matter that you go to a web site to read your email. That doesn't change the nature of email, until the day when everyone (pretty much) does the same thing -- not likely anytime soon, I think. Ditto for reading regular mail in a public place -- that doesn't change the nature of mail until it's very rare to read it anyplace that is not quite public (at which point things like credit cards can no longer be sent via mail).
If IE is a consumer of a service provided by the OS then IE is not part of the OS.
Microsofts ascertion to the contrary is hereby refuted.
Not necessarily.
I've seen this kind of claim made re IE on Macs -- that if IE can be ported to any other OS, it can't be said to be part of Windows.
From a purely theoretical point of view -- since I don't know the internals of MS products at all, and generally avoid using them -- these arguments don't hold water.
IE is not necessarily a single, monolithic piece of software that either does, or does not, depend entirely on being hosted by an OS.
It's much more likely that substantial portions of it do not depend on Windows -- portions substantial enough to form a complete, independent browser on other OSes.
In fact, what MS claims about "the browser is integral to the OS" strikes me as more along the lines of claiming Windows (the pertinent versions anyway) can't cope without IE, not the other way 'round.
The situation is perhaps not unlike that of Linux and GCC. One cannot really "use" Linux, in the way that it's popularly perceived (including rebuilding the kernel from source, to add, delete, and modify its capabilities), without GCC.
Now, if Linus Torvalds stated, under oath, "GCC cannot presently be separated from the Linux operating system", one could interpret his statement in either or both of these ways:
GCC cannot "survive" in an environment other than Linux
Linux cannot "survive" without GCC
(I use "survive" in the sense that it won't work as expected.)
The former interpretation is clearly false, in that GCC survives quite well in all sorts of environments.
Claiming Linus lied because it's false would be, however, incorrect, since the latter interpretation is, in fact, correct: the Linux kernel can't be rebuilt without GCC, a lot of work would be needed to change that fact, and such rebuilding is considered an important capability of the Linux operating system (which is sometimes called "GNU/Linux" for various reasons, including this latter interpretation).
So, the fact that IE can, in various forms, survive outside of Windows, or that portions of it do indeed "treat" the Windows kernel as a client would a server, or a customer would a vendor, does not address the issue of whether Windows can "survive" without IE being installed.
If the pertinent versions of Windows could not work without IE being installed, without lots of work on the internals of course, then I would say that MS's claims, as presented in forums I read (since I'm not exactly reading court transcripts), have not been disproven by the fact that IE works outside of Windows or that portions of it access Windows through a well-documented API.
(Note that I generally don't post anything rebutting anti-MS arguments, since MS has, what, some $4B cash to do the same thing. But in this case I felt the opportunity to perhaps educate some people about the issues might make for more-informed debates over issues such as Open Source use by governments, whether GNU/Linux is the proper name for the OS, and so on.)
You might want to check for yourself whether you really have this bug fixed on your machine, since there seems to be some disagreement as to whether MS has actually provided one already.
In order to make sure we compare apples to apples and oranges to oranges, I suppose it would be fair to ask the question of when the Konqueror fix will be available to the normal and possibly rather non-sophisticated public consumer crowd?
Okay, you took care of the apples-to-apples case, now here's the oranges-to-oranges case:
Given that Konqueror was fixed in about 90 minutes, such that users willing to try out such fixes for themselves could freely download the fixed source code without having to accept any new licensing restrictions, when will Microsoft's internal source-code changes fixing its version of the bug be available for users to try out by downloading, under the licensing they've already accepted?
I love it when ads use a song that really means the exact opposite thing.
One of my recent favs is the car ad that shows a nice sedan driving through a small village, with everyone in the village so interested in it that a whole crowd forms, following the car, disappointed as it drives off in the distance.
The music? An instrumental version of the main theme from Jethro Tull's "Thick as a Brick".
If only we could get a million geeks away from their machines.
Someone could try convincing Natalie Portman to show up as a featured attraction...I hear she has a pretty big fan-base among geeks.
Re:The compiler who cried wolf?
on
GCC 3.2 Released
·
· Score: 1
The problem is not that they changed the ABI, it's that they keep saying "It will never change again!".
Ah, well, that's a separate issue.;-)
Re:The compiler who cried wolf?
on
GCC 3.2 Released
·
· Score: 2, Insightful
How many times is the C++ ABI going to be declared stable before it actually is?
That's just like the "viewer response" I saw CNN airing sometime around 2001-09-13:
When will I feel safe again?
It's a nonsensical question, although you can take personal action to resolve your concerns, if you choose. (You can simply decide to feel safe, or to never feel safe again; you can decide to undertake the kind of in-depth study of C++ ABI issues and GCC's code base to determine whether it's stable, or to accept that it'll never be stable. These are all coping mechanisms. Nobody else can answer the questions for you.)
In the meantime, if you want to "stick with 3.1's slightly-broken ABI", then what's preventing you from doing that?
Re:Finally, ABI stabilization. Now about optimizat
on
GCC 3.2 Released
·
· Score: 3, Insightful
Ever heard of Occam's Razor?
If you have no insight whatsoever into the internals of a system -- such as is the case when viewing the inner workings of the universe from a pre-Einstein perspective -- then Occam's Razor can indeed prove useful.
But when you are told by people who understand what's going on inside what are the implications of failures appearing when compiling with certain optimizations enabled, then Occam's Razor no longer applies in the way that you think.
In fact, it applies in the exact opposite way, to wit:
A compiler represents, compared to the vast amount of code it compiles, maybe.01% of the total code involved (compiler plus code compiled by that compiler).
(The GCC compiler probably represents much less than that.)
Testing the compiler includes making sure it "correctly" compiles a substantial portion of the target software.
If the compiler offers an optimization that end users can turn on, one which is carefully documented and at least moderately well-tested, but that is known to expose bugs in the code it is compiling, yet has not been found to itself have a bug when enabled while compiling a substantial portion of the code...
...then Occam's Razor actually suggests the source of a bug in a specific application that fails when compiled with that optimization enabled is the application itself, not the compiler.
Otherwise, one would presume a much larger body of software would fail in ways that are easy to track down to a compiler bug (especially in GCC's case, where the compilation phases are so transparent via RTL dumps and the like) when that optimization was enabled.
Especially in this case, where the kind of application bug is of a type that was widely deployed due to a combination of factors, even though I know the internals of GCC argue pretty strongly for the ability of a bug in the optimization being discussed to hide most of the time and still bite a few applications, I'd tend to lean, based on what you've said, towards a 75-25% likelihood of application bug versus GCC bug in this particular case.
In short: general rules are very useful, but they cease to apply to the extent specific information is available.
Software distributed under the GPL is [...] encumbered with it's anti-commercial clauses and may only be used in non-commercial applications such as research.
All lies. Read the GPL -- you'll see nothing in it remotely like an "anti-commercial clause" or a clause that forbids use in commercial applications.
I know this for a fact, since I've developed GPL code for commercial use, I've developed it both as a volunteer and as a contractor, i.e. as a commercial activity, and I've been told many times by various people how helpful my GPL'ed code has been in improving the profitability of their commercial enterprises.
(BTW when I say used, I mean the source code, not the compiled binary and please don't confuse the issue any further than you have already done so)
I'm not lying: you are. The only way I can be said to have "confused the issue" is in the sense that I'm disputing your lies.
Now, if you're trying to claim a distinction between using the source code and the program, you're still lying, because the GPL does not make a distinction vis-a-vis commercial and noncommercial use between source code and binaries.
Further, you're comparing apples to oranges when you compare the GPL to BSD, since people who end up with proprietary versions of BSD-laden products have no access to the source code at all -- something you seem to view as an advantage on the one hand, yet as a disadvantage when the GPL offers it, albeit under the restricted terms you falsely impute to it.
In other words, you are either acknowledging the consistent, continued availability of source code with the GPL model, but at the same time claiming that, somehow, its availability is restricted to non-commercial distribution and use (which is a lie, since no such restriction exists), or you're claiming that source-code availability is unimportant (or at least of insufficient value to offset the market advantages of proprietary software), which is the pink elephant in the room where someone is trying to say that the GPL is not as good for the economy, for capitalism, whatever, as BSD or proprietary software.
Or, put another way: if you reject the GPL in favor of PD/BSD/proprietary, on the grounds that businesses are allowed, by the latter, to withhold the source code when distributing software based on the latter models, then you cannot possibly claim the "flaw" in the GPL is that it restricts use of source code to non-commercial activities even if that claim was true (which it isn't), since at least under the GPL everyone who gets the program also gets access to the source code, which is something you are trying to claim is a negative for the GPL in the first place!
So, which is it: is the GPL to be rejected because it assures end users of GPL-laden software access to the source code? If so, then it shouldn't matter whether the access might be limited to non-commercial activity -- yet you raise that as an objection to the GPL (falsely).
On the other hand, if you genuinely believe the GPL is bad because it does limit access to the source code to only non-commercial applications, then you implicitly acknowledge the superiority of the GPL over PD/BSD/proprietary distributions that withhold source code entirely.
Then, once it becomes clear that even the GPL's assurance of source-code availability is not restricted to non-commercial use, that advantage increases further.
When a company uses software licensed under the BSD in a commercial product, they are not taking anything away from you. What they are selling to you is the value that they added to the software. You are still free to use the original software all you want, you are still free to modify the original software all you want. Nothing has been taken away from you. If you do not see value in the changes that this company is selling, then you do not need to buy from them.
All of that is true of the GPL as well, plus you are free to modify the commercially produced software and redistribute that. More freedom, as far as end users are concerned, when it comes to the ability to decide for themselves who to hire to maintain and improve the code.
And note that all that you say is true of the ability of commercial software developers to use GPL'ed software however they choose, except insofar as they're unable to release proprietary variants of that kind of software.
If any of your lies about the GPL were true, how could Microsoft be legally distributing a commercial product like its Interix-derived GPL software -- which includes the GPL'ed software I myself developed -- and make a profit off the result?
No, they're making money for me because the industry hires software developers to improve upon these innovations and commercialize them. I really like having a job, don't you?
[...]
But when you try to get the government to forcibly seize assets from citizens(what we like to call taxes) so as to fund your software experiments,
then I'm afraid we're going to have a public policy debate and you may not like what you hear.
Interesting how you describe proprietary distributions of taxpayer-funded software modified by you, off of which you profit, as "commercializations" of "innovations", yet you describe free distributions of taxpayer-funded software modified by others, off of which they profit if they choose, but not via restricting the rights of taxpayers to access their own original software as modified by the end product, as "software experiments".
At least we know you're in favor of getting "the government to forcibly seize assets from citizens(what we like to call taxes) so as to fund" only proprietary vendors like yourself with income, a job, etc.
By the way, your understanding of economics is abysmal -- you believe government can collect taxes only under a system of artificial scarcity in the realm of computer software. That's false, and any economist should be able to explain to you that, even if all computer software was legally placed into the public domain tomorrow morning by the government, it would still be able to collect taxes. (Let's see if you can figure out from whom on your own.)
In any case, it's really sad to me, as someone who so deeply appreciates the free market, the importance of a truly liquid monetary system, the need for respect for property rights, etc., to see someone so uninformed about these issues that they stoop to calling GPL advocacy "anti-capitalist".
You are just the sort of person that makes the kind of let's-shut-off-the-free-air scenario in a story like "Total Recall" feasible: someone who believes that creating artificial scarcity is the best thing for humanity, or, at least, for yourself.
Then why are MS, IBM, et al selling the stuff, I wonder?
Could it be that they don't care about what's "good for the economy"??
Or perhaps they're just doing what is in their own best interest, which is what some of us believe that, when more people are permitted to do that as they see fit, makes for a better economy?
(It is really funny to read and hear about how terrible open source, especially GPL, software is for the world, the economy, the American capitalist system, etc., especially from Microsoft, while they sell the stuff -- including GPL'ed software I wrote!! -- out of the other side of their mouth! MS: "This GPL stuff is dangerous, but we can't stop selling it! Somebody stop us please!" LOL.)
It became microsoft fortran powerstation then was sold to digital and rebranded visual fortran. digital was bought by compaq. So now it is compaq visual fortran.
A long rant on language design, highlighting the distinctions between Fortran, C, and C++. This post applies some of those concepts to specific concerns I had with the way Fortran 90 was extended over FORTRAN 77, as does this post. This post talks about the concepts vis-a-vis IF statements in FORTRAN, and this one talks about them with regards to GOTO, among other things. This one goes over lots of the same ground as the others, with the added advantage of a reference to the movie Jurassic Park.
More to the point, I don't believe C is a great language even though it's a great tool and it's a language.
One of many complaints I made about the unfortunate disagreements among Fortran vendors regarding how to interpret numbers in Fortran programs. (You'd think "the best scientific/numeric programming language" would have a community that agreed on how to interpret constants in code, but no.) Another post on the same topic.
More about Fortran functions versus subroutines, including an aside about how C programmers trying to design interfaces to Fortran sometimes confuse themselves over what is really an inappropriate use of the term "function" in the C world. (I.e. it only looks like a function in terms of syntax; it's really a subroutine, that is, an imperative sequence of operations that must be performed as written.) See also this short post, unusual for me in that it's short!
Fortran actually has more intelligent character concatenation than C, at least from the linguistic point of view. The compiler actually has to understand, in some cases, that the destination can hold only so much of the source in an assignment; in C, you have to string together tons of imperative calls to library functions, which can, at least theoretically, take much longer and more memory to perform at run time.
(Though, in my experience, so few people use Fortran for "character" or string work that compiler authors don't work hard at such optimizations. But the language comes oh-so-close to providing a pretty decent character-manipulation environment in which pretty decent optimizations -- the sort C programmers must often resort to hand-coding to achieve -- can be straightforwardly implemented by the compiler.)
A theoretical rant, of sorts, regarding Fortran 90's "RESULT()", and Fortran's weird, sometimes inscrutable, means of distinguish a reference to a function itself from an invocation of that function -- a probably C doesn't quite have in that specific case, though it has its own grody areas when it comes to types, declarations, casts, and such. Another such rant.
Fortran has logical operators that C doesn't. Seriously, it's true: C doesn't have "AND" or "OR", for example. It has only a straightforward bitwise form of AND/OR and an IF/THEN/ELSE form of AND/OR, but not a more-general, compiler-can-do-what-it-wants-like-normal-people, AND/OR, which even "bare-metal" FORTRAN 77 has. The linked-to post contains one of my classic, old-style flames designed to bring this out, and is probably not the best way to understand the distinction, but, like people ruined by learning BASIC, C programmers often seem to have been ruined by thinking that "&" and "&&" contain, among them, all you ever need to express the concept "AND". (Of course, you can express C's and/or "operators" in FORTRAN, though it usually takes a bunch of extra typing. I take another crack at explaining this here, here, here, and here.)
Jim Giles and Paul Havlak try to clue me in back around 1990 when I was still trying to understand how, in practice, Fortran was easier to optimize than C for its target "audience" of numerical codes.
Stuff about named COMMON, which reminds me that while strict FORTRAN 77 doesn't offer dynamic memory allocation, that doesn't prevent a compiler from employing it under the hood, and a smart one from doing it in a way that reduces the working set (memory footprint) of the hot spots of the code -- something that is much harder for C compilers, given that the C coders have already "figured this stuff out" (perhaps for an older, differently-memory-architected machine) and hand-coded in their assumptions.
I/O built in to the language has its advantages for portability, but unless designed with all sorts of "hooks", which FORTRAN isn't, it has disadvantages when it comes to redirecting old code's I/O through new filters without having to rewrite it substantially.
The indivisible unit of a file from Fortran's vs. C's point of view, and the assumptions made by C programmers as a result of their worldview.
Slashdot Mirror
Name one such use -- one that does not derive from licensing restrictions placed by someone else on non-GPL'ed code.
Here is the GPL, point out where it discriminates against corporations, individuals, governments, or anyone else, in terms of their right to use the software, as source code or binaries.
What part of "Linux is not an individual or corporation" do you not understand?
They aren't giving Linux preferential treatment -- they're giving the public preferential treatment! (Or, they were.)
If Linux happens to be, for whatever combination of reasons, the best public product for the job they have at hand, then there's nothing wrong with them enhancing it instead of, say, OpenBSD -- and vice versa, should they wish to enhance that.
Again, Linux is a free public product, like the C language, or the Ada language, or the FORTRAN language -- in some cases, products that, via trademark especially, have some "onerous restrictions" beyond those of the GPL (like, you can't call something X unless your implementation passes a rigorous test suite).
It's obviously throwing your brain a curve because, unlike standards, it's an actual free implementation, which post-1980s software kiddies generally can't conceive of in a "Free As In GNU" sense.
But the government has long been in the "business" of freely enhancing free public implementations of software as well -- implementations that have almost always been competitive with proprietary offerings in their day.
Linux is just another case of this.
And if it wasn't for Microsoft wetting its pants over Linux as a competitor, we wouldn't be having this discussion -- it'd be assumed a reasonable thing for government to do. (There might be some mumbling resentment over not picking a *BSD, of course, which gets into technical issues I'm not prepared to address.)
So, the question is this: why are you working as a shill for Microsoft's business interests?
So a corporation can legally include a GPL product in any of their own work.
Which means saying that GPL'ed source code cannot be used commercially IS A LIE, your attempts at deflecting the issue notwithstanding.
Here is the GPL. Search it for the text "commerc", and you'll find only one occurrence, in a trivial and unrelated place.
The GPL has no poison-pill clause against corporations or commerce.
You, sir, clearly know that, given your detailed and willfully-misdirected rebuttal to my explanation, so you are intentionally lying.
Therefore you, sir, are a liar.
This is, what, the third time I've pointed out that you are lying with this "GPL source code cannot be used by commercial companies" crap?
Microsoft is a commercial company, yes?
Microsoft is distributing the source code to GNU Fortran (g77), yes?
Microsoft is therefore distributing GPL'ed source code for commercial benefit, yes?
Why then do you keep telling lies about how GPL'ed source code can't be used commercially?
(Hey, ever hear of Red Hat?)
Please stop spreading lies: GPL results in software which is specifically available to everyone.
(How else is Microsoft getting away with distributing my own GPL'ed software, g77?)
Oh really? Let's see if you can spot which of these does not belong:
-
-
-
-
Give up? The answer is #3. Why? Because it's the only one that isn't a free public entity -- the others all are, and that's why there are all legitimate "targets" for improvement by a government (assuming it's going to spend taxpayer monies in such efforts anyway). (In fact, all three have been improved by government -- for FORTRAN, it was MIL-STD 1753, I believe, ages ago.)Linux shouldn't get a free ride (due to government improving it on taxpayer monies).
Federal law shouldn't get a free ride (due to government "improving" it on taxpayer monies).
MS Windows shouldn't get a free ride (due to government writing improvements for it on taxpayer monies).
The FORTRAN language shouldn't get a free ride (due to government proposing new extensions for it on taxpayer monies).
Your use of "Linux", on the other hand, suggests you cannot distinguish a free, public operating system from a single-sourced, proprietary operating system (or, more precisely, from the company that produces it).
Put another way: what individual or organizations benefits from the taxpayer-funded improvements to the software in question?
For #s 1, 2, and 4 above, the answer is: the public (in fact, the entire planet); for #3, the answer is: Microsoft only -- everyone else has to pay them to realize the improvements, so they aren't direct beneficiaries of the improvements.
I realize you aren't necessarily advocating that the government spend $$ to improve Windows for free, but thinking that Linux shouldn't be improved for free is, frankly, seriously misguided.
(And what people arguing against GPL'ed government software are saying, in essence, is: let's make sure Microsoft can resell taxpayer-funded code at a profit, with severe license restrictions, to people who'll generally have no idea to what extent the software they're buying is made up of their own taxpayer-funded software.)
Microsoft already does release GPL'ed code it did not write (nor explicitly ask permission to release -- e.g. of me) and yet does not risk such a suit.
And, as another comment points out, that they can't simply fold NSA's changes into Windows and distribute it under the licensing MS finds convenient is Microsoft's choice -- a choice they can undo in an instant.
Here's another thing Microsoft can't do with any government code put out in the public domain: it can't monopolize access to that code the way it does to Windows code it writes itself.
That means anything the government writes, or modifies, cannot be used by Microsoft to further its monopoly, since the public can always choose to get at the free, PD versions of the enhancements instead of having to buy MS's formulations (involving those enhancements intertwined with proprietary MS code).
So, just as with the case you complain about, the fact that the government releases code to the public, instead of simply handing it directly over to Microsoft for monopoly control (and I mean this in the copyright/patent, not desktop-PC, sense), means that Microsoft cannot benefit from this expenditure of taxpayer money in the ways to which it has chosen to become accustomed.
Will you therefore argue that government is to never distribute software except to Microsoft?
Else, please explain why the US government, or any other people-funded agency, should be expected to avoid public-minded licenses like the GPL and BSD simply to conform to the business models certain corporations happen to find convenient under current market conditions.
(These licenses are public-minded in the sense that they are specifically authored to ensure long-term free public access to the code -- the source [GPL] or the binaries derived therefrom [BSD], put simply -- and they do not discriminate against any individual or organization, nor do they restrict freedoms such as of speech once any such entity accepts the terms of these licenses. It is precisely this sort of public-minded, freedom-oriented licensing that Microsoft finds frightening, because it cannot conceive of a future in which its business model, of selling closed software under licenses that stifle speech to people who think Software Is Magical And Thus Requires Great Expenditures By Huge Corporations, has been eroded by the public discovering, on its own, that software isn't so magical after all. But MS has specifically targeted the GPL and not BSD license, because with the BSD license it can at least "keep up" with the arms/feature race in theory.)
Disclaimer: my sister works for Microsoft.
Sheesh, where do you people pick up such BS?
Microsoft is both using and releasing GPL'ed code right now, including my own GPL'ed code, GNU Fortran (g77). (I think they call it "Unix for Windows", it comes from Interix, a company they bought?)
The only issue is whether Microsoft feels comfortable competing with a security-enhanced version of Linux that it can't take and cannibalize to suit the license restrictions they choose to impose.
The GPL, like BSD, both require copyright as an underlying protection, but they both serve the public interest -- one buy ensuring access to source code for anyone possessing a derived copy of the product, the other by not doing so.
That there might be legislation requiring "public-domaining" any government-written code is a legal hindrance to the government writing GPL'ed or BSD'ed code, but the spirit is preserved by changing the statutes to permit licenses that assure anyone access to the product, such as the GPL and BSD licenses.
As long as the "restrictions" placed by the licenses on copying and distribution avoid preventing people from making straight copies and distributing to whomever they please, for example, it hardly makes a difference, in terms of the purposes of government authorship, whether such licenses are used versus simply placing works in the public domain.
But one advantage the GPL will always have over BSD and PD distributions: when the government, or even a state or local government, ends up with software (e.g binaries) derived from government-written software, that government will be assured access to the complete source code for the product only if the original code was distributed under the terms of the GPL.
Such assurances go a long way towards protecting the public good in terms of safety, security, openness, and even more mundane things such honesty in procurement (since it's harder to hide the fact that they're buying, from a vendor, 100 lines of vendor-specific code buried in 100,000 lines of "public" source code, when the complete source code is "vended").
Generally, yes.
Of course, when the sender knows the recipient reads email in a fully-connected environment, he can take advantage of that. I do all the time with my wife, sister, and her husband (at least I assume he's fully-connected when reading email), e.g. by emailing them a link with a very short description, leaving it to them to click on the link.
I wouldn't do this to someone who might read email offline. Though the kind of audience that does that is probably changing; I'm "trailing-edge", so I've only recently gone from offline reading to online-via-Broadband reading, whereas my wife is "leading-edge" -- she had five computers on her desk at home the other day, from an old Mac SE to one of them Blackberry thingies -- so she's probably going beyond always-connected to sometimes-offline-reading, due to her frequent travels and increased reliance on wireless communication (which must cope with being unconnected while still allowing reading and composing of email).
Another practical distinction between email and web pages is that people have historically chosen whether to keep or trash their mail. Email too.
This is distinct from shopping/browsing in that one expects to be able to locate useful nuggets of info in years-old mails -- something that is impossible if mails/emails contain, primarily, pointers to external data that might have been "live" near the time of delivery but has since died, or at least changed substantially.
I guess it's important, yet sometimes difficult for techies like us, to distinguish between the concept of email and the technical utility. When I email links to my family and friends, I'm not really mailing them so much as using email (SMTP, you could say) as a delivery mechanism, one that's somewhat different -- more "laid-back", queued, formal, etc. -- than instant messaging, which I've yet to use.
In that context -- using email as simply a data-delivery mechanism -- it doesn't really matter much what's in the email, because both the sender and recipient are more "tightly bound together" in terms of what kinds of communications are expected and tolerated.
But non-techies, such as newcomers to the field of computing-enabled communication, are, IMO, best served by software that helps them use the technologies in ways that are most consistent with their target audience (other newcomers). In this case, that'd be software that helps them avoid delivering email in the form of web pages (HTML), among other things.
I want a "rewrite-in-FORTRAN" button on LKML.
He highlights these differences using real-world examples. That doesn't mean flaws in his analogy indicate flaws in his reasoning.
(For example, you ask "If I read my real mail out at the mall - do I have privacy rights to it?" -- yes, you still do, except to the extent it is obvious to anyone that you are reading mail, that you are reading N pieces of mail, that some of them might have big bold print readable from a distance...but the fact that you aren't at home does not automatically grant someone permission to "borrow" your mail and read it, or even read it over your shoulder, on the grounds that you've "given up privacy" by doing it in a public place. That's true regardless of whether it's mail or email. None of this means the rest of your argument is invalid, of course.)
Some of your arguments are just trivial technological twists, though, and do little to illuminate the issues.
So let me try this out on you. The main difference between reading mail/email and going shopping/browsing is that the former is assumed to be capable of being done by the client in his own home, on his own schedule, without necessarily being "connected" to the rest of the world. The latter is assumed to require all those things -- to leave the home (physically, or to leave the home computer virtually by reaching out to an external web site and giving it some degree of control over your computer); to do so on a schedule convenient to the provider of services; and to do so while some kind of connection (Internet, roads, walkways, etc.) to the provider via outside world is maintained.
Therefore, given that HTML is specifically designed as a hypertext markup language -- a language making the browsing activity easier and broader for the client -- it is reasonable to conclude that it is not automatically suitable for a communications medium, email/mail, that one must assume will be read when hypertext links (and similar paraphernalia) might not be operative, or welcome, by the client.
(How would you feel if you fetched all your email onto your computer, disconnected, walked to a park to read it, and found that every single message was simply a link to someplace on the 'net -- to which you were no longer connected -- containing the full text of the message? That's certainly something HTML supports, so I would conclude from your support of HTML as a natural technology for email that you wouldn't mind. I certainly would mind, since I think it should be clear to everyone that, extreme cases aside, emails, like regular mails, should be readable "offline", whatever that means.)
That's not to say HTML as a technology cannot be embedded in email, since, obviously, it can. But what email readers should default to is what would amount to a subset of HTML that allows only browsing within the email itself (plus, in certain cases such as corporate LANs, within the known-safe LAN, or network), disallows arbitrary code being run on behalf of the provider (since the client must be assumed to wish to control the entire experience), and so on. And email authoring software, in recognition of this general convention, would help the user writing an email to either obey the conventions or understand that, in not doing so, the reader might choose to ignore part of the message (perhaps by default -- not even seeing that there's a choice to be made in an individual case).
In short, HTML email is, as practiced today by email-sending software, closer to sending raw executables and expecting email clients to simply run them to "serve" the user who wishes to read them, than it is to sending plain text and other markup that obeys the concept that the client is in complete control of the mail-reading experience, including where, when, and with what degree of connecitivity to the outside world he is reading his mail.
(And, yes, I've bitten the heads off a few friends who insist on sending snail-mail with chunks of glitter that "explode" on you when you open it. If I wanted glitter all over my clothes, I'd go party with some 12-year-old girls or something.)
Remember, the question isn't under what circumstances might someone read mail, shop, or browse -- it's under what circumstances must someone designing an infrastructure supporting these activities take into account as the most pertinent, in terms of what users of that infrastructure expect, how their rights are best protected, and so on.
So, no, it doesn't matter that you go to a web site to read your email. That doesn't change the nature of email, until the day when everyone (pretty much) does the same thing -- not likely anytime soon, I think. Ditto for reading regular mail in a public place -- that doesn't change the nature of mail until it's very rare to read it anyplace that is not quite public (at which point things like credit cards can no longer be sent via mail).
Not necessarily.
I've seen this kind of claim made re IE on Macs -- that if IE can be ported to any other OS, it can't be said to be part of Windows.
From a purely theoretical point of view -- since I don't know the internals of MS products at all, and generally avoid using them -- these arguments don't hold water.
IE is not necessarily a single, monolithic piece of software that either does, or does not, depend entirely on being hosted by an OS.
It's much more likely that substantial portions of it do not depend on Windows -- portions substantial enough to form a complete, independent browser on other OSes.
In fact, what MS claims about "the browser is integral to the OS" strikes me as more along the lines of claiming Windows (the pertinent versions anyway) can't cope without IE, not the other way 'round.
The situation is perhaps not unlike that of Linux and GCC. One cannot really "use" Linux, in the way that it's popularly perceived (including rebuilding the kernel from source, to add, delete, and modify its capabilities), without GCC.
Now, if Linus Torvalds stated, under oath, "GCC cannot presently be separated from the Linux operating system", one could interpret his statement in either or both of these ways:
-
-
(I use "survive" in the sense that it won't work as expected.)GCC cannot "survive" in an environment other than Linux
Linux cannot "survive" without GCC
The former interpretation is clearly false, in that GCC survives quite well in all sorts of environments.
Claiming Linus lied because it's false would be, however, incorrect, since the latter interpretation is, in fact, correct: the Linux kernel can't be rebuilt without GCC, a lot of work would be needed to change that fact, and such rebuilding is considered an important capability of the Linux operating system (which is sometimes called "GNU/Linux" for various reasons, including this latter interpretation).
So, the fact that IE can, in various forms, survive outside of Windows, or that portions of it do indeed "treat" the Windows kernel as a client would a server, or a customer would a vendor, does not address the issue of whether Windows can "survive" without IE being installed.
If the pertinent versions of Windows could not work without IE being installed, without lots of work on the internals of course, then I would say that MS's claims, as presented in forums I read (since I'm not exactly reading court transcripts), have not been disproven by the fact that IE works outside of Windows or that portions of it access Windows through a well-documented API.
(Note that I generally don't post anything rebutting anti-MS arguments, since MS has, what, some $4B cash to do the same thing. But in this case I felt the opportunity to perhaps educate some people about the issues might make for more-informed debates over issues such as Open Source use by governments, whether GNU/Linux is the proper name for the OS, and so on.)
Not according to this comment.
You might want to check for yourself whether you really have this bug fixed on your machine, since there seems to be some disagreement as to whether MS has actually provided one already.
Okay, you took care of the apples-to-apples case, now here's the oranges-to-oranges case:
I'm not sure, but I think the answer is: Never.
One of my recent favs is the car ad that shows a nice sedan driving through a small village, with everyone in the village so interested in it that a whole crowd forms, following the car, disappointed as it drives off in the distance.
The music? An instrumental version of the main theme from Jethro Tull's "Thick as a Brick".
Someone could try convincing Natalie Portman to show up as a featured attraction...I hear she has a pretty big fan-base among geeks.
Ah, well, that's a separate issue. ;-)
That's just like the "viewer response" I saw CNN airing sometime around 2001-09-13:
It's a nonsensical question, although you can take personal action to resolve your concerns, if you choose. (You can simply decide to feel safe, or to never feel safe again; you can decide to undertake the kind of in-depth study of C++ ABI issues and GCC's code base to determine whether it's stable, or to accept that it'll never be stable. These are all coping mechanisms. Nobody else can answer the questions for you.)
In the meantime, if you want to "stick with 3.1's slightly-broken ABI", then what's preventing you from doing that?
If you have no insight whatsoever into the internals of a system -- such as is the case when viewing the inner workings of the universe from a pre-Einstein perspective -- then Occam's Razor can indeed prove useful.
But when you are told by people who understand what's going on inside what are the implications of failures appearing when compiling with certain optimizations enabled, then Occam's Razor no longer applies in the way that you think.
In fact, it applies in the exact opposite way, to wit:
A compiler represents, compared to the vast amount of code it compiles, maybe .01% of the total code involved (compiler plus code compiled by that compiler).
(The GCC compiler probably represents much less than that.)
Testing the compiler includes making sure it "correctly" compiles a substantial portion of the target software.
If the compiler offers an optimization that end users can turn on, one which is carefully documented and at least moderately well-tested, but that is known to expose bugs in the code it is compiling, yet has not been found to itself have a bug when enabled while compiling a substantial portion of the code...
Otherwise, one would presume a much larger body of software would fail in ways that are easy to track down to a compiler bug (especially in GCC's case, where the compilation phases are so transparent via RTL dumps and the like) when that optimization was enabled.
Especially in this case, where the kind of application bug is of a type that was widely deployed due to a combination of factors, even though I know the internals of GCC argue pretty strongly for the ability of a bug in the optimization being discussed to hide most of the time and still bite a few applications, I'd tend to lean, based on what you've said, towards a 75-25% likelihood of application bug versus GCC bug in this particular case.
In short: general rules are very useful, but they cease to apply to the extent specific information is available.
In other words, you'll lie.
All lies. Read the GPL -- you'll see nothing in it remotely like an "anti-commercial clause" or a clause that forbids use in commercial applications.
I know this for a fact, since I've developed GPL code for commercial use, I've developed it both as a volunteer and as a contractor, i.e. as a commercial activity, and I've been told many times by various people how helpful my GPL'ed code has been in improving the profitability of their commercial enterprises.
I'm not lying: you are. The only way I can be said to have "confused the issue" is in the sense that I'm disputing your lies.
Now, if you're trying to claim a distinction between using the source code and the program, you're still lying, because the GPL does not make a distinction vis-a-vis commercial and noncommercial use between source code and binaries.
Further, you're comparing apples to oranges when you compare the GPL to BSD, since people who end up with proprietary versions of BSD-laden products have no access to the source code at all -- something you seem to view as an advantage on the one hand, yet as a disadvantage when the GPL offers it, albeit under the restricted terms you falsely impute to it.
In other words, you are either acknowledging the consistent, continued availability of source code with the GPL model, but at the same time claiming that, somehow, its availability is restricted to non-commercial distribution and use (which is a lie, since no such restriction exists), or you're claiming that source-code availability is unimportant (or at least of insufficient value to offset the market advantages of proprietary software), which is the pink elephant in the room where someone is trying to say that the GPL is not as good for the economy, for capitalism, whatever, as BSD or proprietary software.
Or, put another way: if you reject the GPL in favor of PD/BSD/proprietary, on the grounds that businesses are allowed, by the latter, to withhold the source code when distributing software based on the latter models, then you cannot possibly claim the "flaw" in the GPL is that it restricts use of source code to non-commercial activities even if that claim was true (which it isn't), since at least under the GPL everyone who gets the program also gets access to the source code, which is something you are trying to claim is a negative for the GPL in the first place!
So, which is it: is the GPL to be rejected because it assures end users of GPL-laden software access to the source code? If so, then it shouldn't matter whether the access might be limited to non-commercial activity -- yet you raise that as an objection to the GPL (falsely).
On the other hand, if you genuinely believe the GPL is bad because it does limit access to the source code to only non-commercial applications, then you implicitly acknowledge the superiority of the GPL over PD/BSD/proprietary distributions that withhold source code entirely.
Then, once it becomes clear that even the GPL's assurance of source-code availability is not restricted to non-commercial use, that advantage increases further.
All of that is true of the GPL as well, plus you are free to modify the commercially produced software and redistribute that. More freedom, as far as end users are concerned, when it comes to the ability to decide for themselves who to hire to maintain and improve the code.
And note that all that you say is true of the ability of commercial software developers to use GPL'ed software however they choose, except insofar as they're unable to release proprietary variants of that kind of software.
If any of your lies about the GPL were true, how could Microsoft be legally distributing a commercial product like its Interix-derived GPL software -- which includes the GPL'ed software I myself developed -- and make a profit off the result?
Are you saying Microsoft is violating the GPL?
Please stop lying.
Interesting how you describe proprietary distributions of taxpayer-funded software modified by you, off of which you profit, as "commercializations" of "innovations", yet you describe free distributions of taxpayer-funded software modified by others, off of which they profit if they choose, but not via restricting the rights of taxpayers to access their own original software as modified by the end product, as "software experiments".
At least we know you're in favor of getting "the government to forcibly seize assets from citizens(what we like to call taxes) so as to fund" only proprietary vendors like yourself with income, a job, etc.
By the way, your understanding of economics is abysmal -- you believe government can collect taxes only under a system of artificial scarcity in the realm of computer software. That's false, and any economist should be able to explain to you that, even if all computer software was legally placed into the public domain tomorrow morning by the government, it would still be able to collect taxes. (Let's see if you can figure out from whom on your own.)
In any case, it's really sad to me, as someone who so deeply appreciates the free market, the importance of a truly liquid monetary system, the need for respect for property rights, etc., to see someone so uninformed about these issues that they stoop to calling GPL advocacy "anti-capitalist".
You are just the sort of person that makes the kind of let's-shut-off-the-free-air scenario in a story like "Total Recall" feasible: someone who believes that creating artificial scarcity is the best thing for humanity, or, at least, for yourself.
Then why are MS, IBM, et al selling the stuff, I wonder?
Could it be that they don't care about what's "good for the economy"??
Or perhaps they're just doing what is in their own best interest, which is what some of us believe that, when more people are permitted to do that as they see fit, makes for a better economy?
(It is really funny to read and hear about how terrible open source, especially GPL, software is for the world, the economy, the American capitalist system, etc., especially from Microsoft, while they sell the stuff -- including GPL'ed software I wrote!! -- out of the other side of their mouth! MS: "This GPL stuff is dangerous, but we can't stop selling it! Somebody stop us please!" LOL.)
Uh, what does one have to do with the other? Other than the generally-observed fact that tax cuts stimulate economic growth?
You might also, in case you actually care one whit about the truth, take a look at this article, which might as well have been titled Corporate Profits Misstated by Clinton Administration?".
No, that's not true, but it was a common misconception back in the day.
More to the point, I don't believe C is a great language even though it's a great tool and it's a language.
My shot, circa 1990, at the well-known-by-now aliasing issues between FORTRAN and C.
One of many complaints I made about the unfortunate disagreements among Fortran vendors regarding how to interpret numbers in Fortran programs. (You'd think "the best scientific/numeric programming language" would have a community that agreed on how to interpret constants in code, but no.) Another post on the same topic.
An example of Fortran's distinction between subroutines and functions, a distinction not available in C (or, to my knowledge, C++).
Fortran has a strange way for functions to return their value compared to C and PL/1, illustrated by this post.
More about Fortran functions versus subroutines, including an aside about how C programmers trying to design interfaces to Fortran sometimes confuse themselves over what is really an inappropriate use of the term "function" in the C world. (I.e. it only looks like a function in terms of syntax; it's really a subroutine, that is, an imperative sequence of operations that must be performed as written.) See also this short post, unusual for me in that it's short!
Fortran actually has more intelligent character concatenation than C, at least from the linguistic point of view. The compiler actually has to understand, in some cases, that the destination can hold only so much of the source in an assignment; in C, you have to string together tons of imperative calls to library functions, which can, at least theoretically, take much longer and more memory to perform at run time.
(Though, in my experience, so few people use Fortran for "character" or string work that compiler authors don't work hard at such optimizations. But the language comes oh-so-close to providing a pretty decent character-manipulation environment in which pretty decent optimizations -- the sort C programmers must often resort to hand-coding to achieve -- can be straightforwardly implemented by the compiler.)
A theoretical rant, of sorts, regarding Fortran 90's "RESULT()", and Fortran's weird, sometimes inscrutable, means of distinguish a reference to a function itself from an invocation of that function -- a probably C doesn't quite have in that specific case, though it has its own grody areas when it comes to types, declarations, casts, and such. Another such rant.
Fortran has logical operators that C doesn't. Seriously, it's true: C doesn't have "AND" or "OR", for example. It has only a straightforward bitwise form of AND/OR and an IF/THEN/ELSE form of AND/OR, but not a more-general, compiler-can-do-what-it-wants-like-normal-people, AND/OR, which even "bare-metal" FORTRAN 77 has. The linked-to post contains one of my classic, old-style flames designed to bring this out, and is probably not the best way to understand the distinction, but, like people ruined by learning BASIC, C programmers often seem to have been ruined by thinking that "&" and "&&" contain, among them, all you ever need to express the concept "AND". (Of course, you can express C's and/or "operators" in FORTRAN, though it usually takes a bunch of extra typing. I take another crack at explaining this here, here, here, and here.)
Jim Giles and Paul Havlak try to clue me in back around 1990 when I was still trying to understand how, in practice, Fortran was easier to optimize than C for its target "audience" of numerical codes.
Stuff about named COMMON, which reminds me that while strict FORTRAN 77 doesn't offer dynamic memory allocation, that doesn't prevent a compiler from employing it under the hood, and a smart one from doing it in a way that reduces the working set (memory footprint) of the hot spots of the code -- something that is much harder for C compilers, given that the C coders have already "figured this stuff out" (perhaps for an older, differently-memory-architected machine) and hand-coded in their assumptions.
I muse over the general issue of names reserved to language libraries vis-a-vis Fortran and C.
I/O built in to the language has its advantages for portability, but unless designed with all sorts of "hooks", which FORTRAN isn't, it has disadvantages when it comes to redirecting old code's I/O through new filters without having to rewrite it substantially.
The indivisible unit of a file from Fortran's vs. C's point of view, and the assumptions made by C programmers as a result of their worldview.
On alternate ENTRY points, which FORTRAN 77 has, C doesn't, but....
A VOLATILE issue I wrote about, regarding new features in Fortran 2000.
How FORTRAN might have helped work around the lack of a universal end-of-file indicator on mainframe systems using punched cards. C programmers never had to deal with this legacy! ;-)
The subtleties of FORTRAN DO versus C "for" loops are hinted at here.
Why we should all be programming in BASIC instead (just kidding ;-).