There is much wisdom in the saying that "Money is the root of all evil"
Dunno about "wisdom", but there is some humor in the use of this misquotation of a Biblical verse to justify a position not supported at all by the verse itself:
1Ti 6:10: For the love of money is the root of all evil:...
(Emphasis added.)
After all, doesn't it seem unlikely that any credible "wisdom" would claim as the root of all evil something that was invented only a few thousand years ago? But the love of what it represents...well....
If there is a god, I wonder if he ever worried about this.
Worried???
Heck, it's probably why he created the universe in the first place!
That, and, until we get our act together and build the One Eternal Desktop GC (God Computer) for Him, He can amuse Himself playing the ultimate game of Asteroids!
That is my problem with religion. All those people who think they're so important that they NEED to win me over.
That's funny...that is my problem with people who are anti-religion. All those people who think they're so important, smart, possessed with an "infinitely-meta"-understanding of the human condition, that they need to win me over to their position of rejecting religion.
As someone with a strong scientific bent, I understand many of their concerns about blindly adopting any set of religious beliefs.
But as someone with a strong moral bent, I also understand many of the concerns of the religious about the likely realities of any government or society that officially eschews religious beliefs of any kind.
After all, the most effective, concentrated killings of millions of peoples in this century alone have generally been perpetrated by those professing atheist beliefs against those they perceived to hold dangerously religious beliefs. "Religion is poison", and all. (Yes, I know that was -- presumably -- a fictional quote, from "Seven Years in Tibet", but it certainly sums up -- along with the corresponding actions of the Chinese government -- the attitude I see many atheist/non-religious people in the "free world" demonstrate.)
So, please, the next time an obnoxious, clueless "know-it-all" tries to ridicule your beliefs, impose his belief system on you, etc., and happens to be using religion to do it...
...please consider that the problem there might not be the "religion" aspect. In such a context, "religion" may well be just a tool, just as "atheism", "science", or "non-religious" is in the hands of another person who is equally obnoxious, clueless, etc.
But I don't know of any widely known languages before Perl which were predominantly thought of as interpreted languages and were compiled. The overhead of compiling was just thought to be too large for an interactive program...
I do: Beginner's All-purpose Symbolic Instruction Code, otherwise known as BASIC.
Since around 1980 at least, it seems most people thought of it as an interpreted language, or, more properly, of its implementations as interpreters.
For early PC's that may well have been true (with keywords and such converted to byte codes internally, to save space versus storing the whole program in ASCII).
But the original and many subsequent BASICs were environments that looked interpreted but actually compiled when the "RUN" command was issued.
(Which, for a large program, would mean a noticeable wait before anything useful happened within the program.)
That goes back to the mid-60s, and through my own personal close encounter with TOPS-10 BASIC around the mid-70s, when I first learned how compilers worked (and what PDP-10 assembly code really looked like) by typing in the whole thing from a listing! (Took about three months or so on my beat-up KSR-33 Teletype.)
But is there any foolproof way to validate your code...?
Not that I'm aware of. HTML and C code are two different things, in the sense that both have static semantics, but C has dynamic semantics as well. (HTML does, presumably, when you expand it to include Java, Perl, other Turing-complete CGI stuff...but I'm getting out of my element here, maybe HTML these days is dynamic too. I use it only statically.)
So, a static analysis tool can catch "b += b += 2;", and tools like lint and GCC (with its various warning options) try to be good static analysis tools.
But to really be foolproof, one needs static, dynamic, and some other sort of analysis.
Dynamic analysis would catch "b->foo += c->foo += 2;" when (b == c), but only at run time, unless of course static analysis can prove that it'll always be true. (Remember, run-time analysis is better than nothing, but isn't "foolproof" -- you want to find all bugs in your code before it's deployed, not when it goes to drop the oxygen masks during an emergency decompression or something.;-)
The other sort of analysis boils down to the halting problem, but can in practice be quite useful, just not entirely foolproof. Here the statement is analyzed statically, but in a complete context so logical relations can be asserted in boiled-down form for the program as a whole. (E.g. "If the input file contains a zero byte, the program is undefined because it'll perform a divide by zero in line 1234.")
Anyway, yeah, a web site that validates C (etc.) code against prevailing standards would be pretty cool! Maybe few would use it, but they'd be pretty grateful, and it could settle all sorts of tedious arguments more quickly. Feel free to send me URLs to such things....;-)
Well I don't have a copy of the standard, but my fragment compiles without warnings on gcc 2.95.2 using the -pedantic option.
Trusting GCC to reliably catch all violations of the standard is unwise. -pedantic is not really about catching coding errors, anyway. You really want some kind of -W option to catch this and, yes, it should ideally be on by default.
Since that's meant to make gcc complain about non-ANSI (i.e. ISO) extensions, does that mean this is a bug in gcc?
It means GCC doesn't catch this sort of bug for you by default. Maybe it would if you specified -Wall -W -O2 or something.
Are you sure it hasn't been added to the standard since the version you've seen?
No, because I don't track the standardization efforts (not even of C) closely. We're not talking about a "feature" so much as a detailed rule of behavior, designed to allow certain optimizations to take place. C is not Java; it does not mandate many sorts of ordering of things like side effects, the result being various things are left undefined. "Undefined" means not valid C code.
Would you care to provide a reference saying where in the ISO standard I should look to see what you're saying?
I believe I gave the basics of a good reference -- section 3.3 "Expressions", which might be numbered or even titled differently since 1988-12-07.
But = also does not define a sequence point, so by that argument "a=b=c=d=2" is also undefined. What am I missing here?
Nothing, if any of a, b, c, d refer to the same storage. Assuming they don't, though, which is likely what you mean to do, then what you're missing is that the sample statement does not violate this wording: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression."
And, from an anoncwrd:
Burley, you know lots about fortran but your wrong, the operators cant be evaluated in the wrong order, they use the return value of the next operator in.
First, I really know only FORTRAN 77 well, and that as an implementor, not a user. I know far more about ISO C than I do the present Fortran standard (95). (Which doesn't say much, I'll admit.)
Second, I wasn't objecting to evaluation order, but to the assumption of modification order in the original code.
A statement like "b += b += 2;" has only two pertinent sequence points, the one prior to the beginning of the execution of the statement, and the one at the end. There are no sequence points within the expression itself.
Now, y'all are right that "b += 2" must be evaluated before the rest of the expression.
But you're wrong in assuming the result of this evaluation is anything more than as if "b + 2" had been written instead.
Since there's another (outer) b +=... in the same expression, the C standard (draft copy I have anyway) says the expression is undefined. (I.e. it specifies conditions for the expression such that it is defined, and the statement in question violates those conditions, therefore it is not defined according to the standard.)
From a technical, practical-implementation point of view, the expression could be implemented (compiled as) "tmp2 = b + (tmp1 = b + 2);" with the following side-effects specified:
b = tmp1; b = tmp2;
Specifically, the order in which those two assignments, vis-a-vis the evaluation of the expression, happen is unspecified, and an implementation could choose any order at any time, assuming it meets the obvious def-use ordering (i.e. tmpN must be defined before it can be referenced). You can't assume the b = tmp1; modification happens before the tmp2 = b +... evaluation, for example.
So, you can't rely on the inner assignment to b being completed (i.e. the modification of b itself as a side effect) before the subsequent reference to it as part of the outer "b +=..." operation. So it might have the old value or, strictly speaking, any other value, or start World War III, or whatever.
a=a++ is not undefined. The a++ has to be evaluated first because the a is assigned the return value of the a++.
It is undefined, according to my draft copy, because a gets modified twice, not once, between the two sequence points. a=(a++,a) fixes that, I think, since there's now a sequence point between the two modifications.
You might say "but the same value gets written to a regardless of whether the a= or a++ modification happens first", and I'd agree with that, but the wording in the standard does not make a distinction between multiple modifications of an object with the same value versus with different values.
So, you might get away with it on more implementations (compilers, machines, etc.), and that's all nice and well, but it isn't any more "defined" than the clever XOR-hack.sig.
BTW, read also the wording under "Assignment operators". In my draft copy it says "The side effect of updating the stored value of the left operand shall occur between the previous and the next sequence point." Y'all are assuming it occurs between the evaluation of the assignment operator and the evaluation of any lower-precedence (outer) operator -- but it doesn't, it might occur later than that.
Finally, hey, couldn't y'all just read the comp.lang.c FAQ? I just pulled it up in no time, and questions around 3.3 seem to pretty succinctly say what I've been saying more long-windedly.
P.S. I'm clicking "No Score +1 Bonus" again on my post. It seems like canonical/. practice to do so in cases like this (off-topic posts).
If a and b are two non-zero integers, it replaces a with the highest common factor of a and b (clobbering b in the process).
while(b^=a^=b^=a-=(a/b)*b);
Not in ISO (Standard) C it doesn't; it's undefined. In "pidgin C" it does, if the reader assumes sequence points within the expression as if you'd written:
while(b^=(a^=(b^=(a-=(a/b)*b), b), a));
Specifically, operators like ^= do not define sequence points, so there's no assurance that the inner assignment to b will happen before the outer one. In my oldish draft copy of ANSI C, the second paragraph of 3.3 "Expressions" makes it clear the two modifications of b in your no-sequence-point-containing expression renders it undefined.
(Of course, my version hasn't been tested or carefully analyzed, but I wouldn't make it my.sig.;-)
1989-09-12 Page 8 Software Makers Row Over Patents
1989-07-12 Page 9 Developing Software Is No Picnic
Sometime around 1988 A large article I can't lay my hands on, in which he describes Project GNU. This was one of the articles that inspired me to contribute to GNU by 1989, which led to the development of GNU Fortran (g77). At least, I'm pretty sure it was authored by SLG!
Article in Technology Review:
1991-02/03 Pages 53 Programs to the People "Computer whiz Richard Stallman is determined to make software free -- even if he has to transform the industry singlehandedly."
SLG may be wrong in his predictions, but he's not writing as a newcomer to Linux, Unix, GNU, or free software in general.
I think the bombing of the factory in Sudan ranks up there, as abuse of power, as the stuff done during Watergate and Iran/Contra.
Perhaps, but, in my view, what distinguishes Iran/Contra from those other episodes is that the raison d'etre for the "sins" included the attempted return of American hostages and the defense of the American hemisphere against the encroachment of Soviet-supported communists.
Disagree with the effectiveness or desirability of either of these motives all you, dear reader, might want, but you're unlikely to convince me that they in any way approach the seething selfishness of the motives for Watergate or, even worse (since Nixon was covering up for others at first), the various Clinton scandals.
(More and more, I'm amazed this country managed to elect someone as comparatively uninterested in obtaining and wielding personal power as Ronald Reagan to President. As we all do -- something we're always reminded of when discussing Clinton but somehow by people who inevitably chime in contrariwise vis-a-vis Reagan -- he had his faults, but constantly representing himself as everyone's personal source of happiness wasn't even close to one of them. And that seems to explain, more and more, the confusion of so many historians/biographers, who are thoroughly accustomed to the sort of egos that typically seek high office, as well as the seething hatred directed towards him by those on the Left, who resent his "demonstration" that, indeed, it is the sincere efforts of each and every free citizen, rather than a comparatively small ruling intellectual elite designated as infallible, that is needed for our species to survive and prosper.)
What they want to do is prove that Life is the result of an incredibly unlikely, yet unintentional, accident. Because if Life had been created by God, then we could wipe it out entirely with no bigger consequence: He could simply create Life again.
Not clear. What is clear is that humanity (at least US society) is largely willing to overlook the sanctity of life, vis-a-vis abortion (visited upon the only form of human life that is defined as 100% innocent of any crime of thought or deed).
But while theoretically God could create Life again, the Judeo-Christian God is widely represented as having made Himself quite clear that we're a "one-shot deal".
Though, other religions view creation as ever-occurring, or at least repeating, and some of those "other religions" include Christ-based (and perhaps Judaism-based) ones.
Personally, what I believe is that it is our valuing of human life that strengthens both our willingness and our ability to preserve all life, throughout the universe, regardless of size or "intelligence", in the long run, if that is indeed an aspect of our "destiny". If we don't value each human life as unique and special, the slope from there to not valuing any form of life at all is steep, short, and slippery.
The fact that we are the result of an extremely improbable accident is what makes us, living beings, truly precious, because when we are gone there is no chance of Life ever happening again.
Indeed, if that ever becomes widely accepted as "fact", we should then become a better species.
But that isn't quite what is being promoted by much of today's scientific/educational system, which generally depicts life as nearly inevitable given a (comparatively) small amount of the right elements, input energy (solar or geothermal), and a modest amount of time (a billion or so years).
Note that I agree strongly with the sentiments you express, just not so much with your belief that "they" wish to prove them as true! So thanks for your beautiful post!
Ditto for object files, executable files, etc., though not quite as much generally.
But, in theory, a Linux i386 executable can be created that, aside from some initialization code, looks as much like plaintext in expressing the program's logic (e.g. it could be Java code) as can similar PostScript code with similar initialization code.
If you're looking for a 100% reliable way to automatically determine whether a particular form is "opaque" vs. "transparent", you'll no more find it than you'll find one that distinguishes between "source code" a la the GPL and the alternatives.
That sort of thing is left up to humans to assess, in courts of law, for legal issues like this.
Another poster explained that this is necessary to disallow a recipient simply changing the GDL (FDL?) in a redistribution of someone else's work. Kinda like making it explicitly invariant.
Keep in mind the GPL isn't GPL'ed either. And, yes, people have occasionally wondered why not over the years. The answers are basically the same: both licenses are designed to grant blanket permission to change both the style and the substance of the works distributed under those licenses, but, to do that, the licenses themselves must not be allowed to be substantively changed. Disallowing any changes is the surest way to achieve that.
This is kinda like the concept of "human rights". No matter how much anyone talks about them, there's one incontrovertible fact as long as more than one human exists: almost every such right requires the ability to suspend that right in specific instances to assure them generally.
As an example: the right to not be physically assaulted must be suspendable in instances where person A physically assaults person B, and will not stop until person B is long dead or person C (for "Cop";-) physically assaults person A in order to stop it. Otherwise that "right" is unenforceable; or, if there's no such thing as such assault, there's no need to state or even discuss it in the first place.
(Of course, if someone can come up with a way for C to stop A in a way that'd be considered perfectly legit under any other circumstances -- i.e. not prohibited by virtue of claiming A's "rights" -- that's great. I can't think of a way offhand, and tend to suspect that's because such things are well-neigh impossible, as is, by applying suitable logic, the notion that any human government or system can secure for the people rights, liberties, or happiness they cannot secure for themselves.)
It also needs to define "compilation copyright" - what is it?
It's a copyright on a particular arrangement, or set, of things, as distinct from the copyrights on those things. I don't know offhand how supported this concept is by actual legislation, but it's apparently considered effectively supported by that and/or by precedent set as the result of litigation.
So, in theory at least, someone can copyright a particular combination of Open Source packages as they distribute them on their CD, even if they own none of the copyrights on those underlying packages.
Think of the list of those packages as itself a copyrightable plaintext file, so anyone reproducing that list -- whether as an identical text file, or as the "translation" of it represented by "ls -1" on a directory containing the packages -- could be considered in violation of that copyright, unless they could show independent creation.
Does anyone see any true sense to this clause? We still have to refer back to the original document in order to stick to the license, so I would imagine this would just make things more complicated for such projects as the LDP when they start moving towards more sophisticated language support.
Yes, I see plenty of sense to that clause.
Since there's not yet such a thing as a 100% correct translation automaton, and in fact human language (those in practical use anyway) is full of ambiguities, the author of a text is ultimately the best resource for determining the accuracy of a translation.
(Being a legal document, the GDL focuses on the copyright owner of a text, rather than the original author, which allows the author to confer authority for determining accuracy of translations, among other things, to others.)
With that in mind, the clause appears designed to allow contribution of a translation to a document by anyone in a modified redistribution, but not replacement of the original text as authorized by the copyright holder of sections of the work considered important ("invariant sections").
(Of course, if the copyright holders give specific permission to provide such a replacement, that's allowed by the license -- though the GDL itself needn't specify that, it's a convenient way to express the idea that a copyright holder doing such a thing isn't considered to be violating the "spirit" of the GDL, I suppose.)
As translations are contributed that are judged by the copyright holders to be correct, permissions can be given to provide them as replacements for, not just contributions in addition to, the original versions of invariant sections.
Ditto the GDL itself. Until the copyright holder (the FSF) approves a given translation, someone may contribute their own, but (I would hope) the GDL does not permit that translation to represent itself as the authorized version, and requires it to point to the original English version as such. (I haven't looked at this version of the GDL yet; it's been months since I've reviewed an earlier version.)
Re:[OT] Aliasing bugs and solving the insolveable.
on
Multics Scheduler
·
· Score: 2
Thanks for your post! It makes basically most, or all, of the points I, and a few others, made on the GCC list last year when this issue was raised (yet again).
Yes, catching all such bugs is believed impossible, but I used the phrase "high-quality" to avoid a longish explanation.
GCC currently tries to catch 'em, but fails (from what I understand) for the reasons you cite.
More specifically, what I objected to last year was the assumption that, first, GCC should accommodate such broken code by defaulting to assuming all code is broken (therefore defaulting to lower performance for correct code). I lost that argument; GCC now (as of 2.95.2, perhaps.1) defaults to assuming all code has the aliasing bug.
Second, I objected to the proposal (by RMS, IIRC) that the internals of GCC be (partially) redesigned to make the detection of these bugs (the warnings) of higher quality.
Note, it wasn't the "higher quality" part of that to which I objected -- it was the "change GCC" part.
Even then, it wasn't changing GCC to make it do its job -- generating correct code -- better to which I objected.
So I made the point that, if you really want to provide a tool that does a high-quality job of catching such errors, go write it -- as a tool separate and distinct from GCC. That way, users of GCC won't have to wait for some distant, upcoming release to quickly install and use the tool (this works for users who don't want to download snapshots of GCC in development, but would try just a smallish tool).
More importantly, GCC won't be destabilized just to provide a new warning. Warnings printed "casually" in the normal course of a program's business are, for the most part, fine and dandy, but when you start talking about reworking the internals of a large program like GCC just to accommodate a new warning, you're losing sight of what that program is really for.
Of course, I lost that argument too, since it basically boiled down to saying "people should run lint on questionable code, and leave the compiler to do the compiling" -- which I believe now, much moreso than I did 10 years ago.
That thinking goes in the opposite direction of much of today's high-profile software development, from Microsoft's macroapps to (as another poster correctly pointed out) the FSF's macrowares.
As to your point that C/C++ might not be the best language, I -- and one or two other prominent GCC developers -- made that very point to Linus Torvalds himself, in response to his complaints that GCC's huge set of extensions to standard C still wasn't quite exactly what Linux needed.
Needless to say, I got a few pieces of hate mail for that suggestion (especially to my inappropriate claim that he didn't know anything about good language design in the same post/thread). (There's more I could say about this, but it's best for readers to review the threads at gcc.gnu.org.)
The symptoms here are all related to the same desire to take something that's good because it's simple and make it ubiquitous by making it complicated (by which I don't necessarily mean making the code more complicated -- deciding that GCC assumes bug-laden code makes the spec for code that conforms to GCC more complicated, compared to, e.g., "ISO C"). I.e. it's easier to say "GCC is your one source for all things compiler-related" and get stuck in the mindset that implies a single executable to make it happen, than to realize that a bunch of separate, but cooperatively and thoughtfully designed, applications would be better. Call the collection something like "Hurd"...well, oops....;-)
Anyway, the pointer-aliasing episode culminated, after tons of heated discussion, in a compiler that assumes code is broken, that doesn't do a good job pointing out how and where it's broken (and, unless they don't think it's important enough to put news of it "coming" on the top-level GCC web page that I occasionally check out, won't for some time to come), and in at least myself leaving the GCC project.
After all, what that discussion made clear to me should have been obvious by reading the mission statement for the project: generating correct code is not the #1 goal, and it's unclear from the wording whether it's even the #2, #3, or #4 goal. (One could argue that the word "work" means generating correct code, but, in practice, it doesn't -- it means, to GCC developers, generate correct enough code to accommodate the bulk of the code being targeted by GCC at the time. And testing, which is also mentioned, does not mean generating correct code, merely detecting certain forms of incorrect code.)
Personally, I've decided it's more interesting to explore how to write software that is correct, than software that is feature-rich, since, in my experience, doing the former has always paid off in all sorts of ways (e.g. few-to-no callbacks after writing code that others deploy).
That being said, I'm certainly grateful for GCC, Linux, and all those other products being out there, being useful, and working in so many more circumstances than much of their so-called "competition" (how much Microsoft software runs on SPARC chips, for example?).
So it's not a matter of rejecting products outright because they don't embody KISS. It's a matter of encouraging everyone -- not just the developers (like Linus developing Linux) but the users (like Linus using GCC) to respect that principle more, assuming they really believe it had something significant to do with why Unix won out over Multics, VMS, MVS, and so on. That's why I jumped in here: I saw people celebrating the Unix "win" as a "simplicity is better" victory, and wanted to serve notice that many of the people currently prominent in directing the future of Unix haven't gotten the "simplicity is better" memo, or don't believe it, or simply forget to put it into practice too often. Either they're wrong that Unix won because it embodied KISS, or they're going to be wrong that Unix "won" down the road, because what knocks it off is likely to be built out of simpler, not more complicated, components.
(BTW, I happen to think Open Source distribution embodies the KISS principle as well. The alternative includes many activities, such as working hard to obscure your IP, adding license-checking code or dongle support to your software, etc. that contribute complexity to the product that is not needed by users, except to the extent it lowers their up-front acquisition costs.)
It's interesting to see several comments here (can't read the article right now, it's slashdotted) suggesting that Unix is successful today while Multics isn't due to the former's complexity.
I think there's a fair amount of legitimacy to that argument. But, having come from an environment (Pr1me) that is to Multics sorta like Linux is to Unix, I'd like to make some observations.
First, surely some of Multics' complexity was overblown, perhaps because of attempts to have it do more than strictly necessary. I.e. it wasn't sufficiently simplified. We're committing the same "sins" throughout the GNU/Linux universe ourselves, e.g. piling feature after feature onto what should be simple, robust components (such as GCC) rather than providing separate tools. (Compare qmail's design to sendmail's, and then try and figure out why, after tons of discussion on the GCC mailing list last year, there's still no high-quality Open Source way to find pointer-alias bugs in C code.)
Second, much of what we take for granted in Unices of today was inspired, and to some extent proven in the field, by Multics and its descendants, like PRIMOS. Though not an expert on Linux-style dynamic linking, I've found it, and other things like signaling/exceptions, to be, in at least some crucial ways, poor second cousins compared to the technologies (in which I had substantial expertise) available in PRIMOS -- essentially a cheap sorta-clone of Multics -- back around 1984.
Third, hardware and networking improvements have probably significantly changed the "balance" of factors affecting design decisions that went into Multics. Back in those days, processors weren't cheap, therefore processes weren't cheap, nor were the process-creation and process-exchange activities we take for granted today. (Compare how many processes get exchanged and/or created just to handle an email or, heck, even a mouse click on a typical modern Unix system to contemporary equivalent activities back in the early 1970s, for example.)
Yet it seems today's "cutting-edge" Unix applications are designed with a similarly limited mind-set. Applications that truly and (IMO) properly take advantage of the "balance" of a modern Unix system, such as qmail, are few and far between. How many of today's new applications have what amounts to a scheduler inside of a single process, rather than relying on the Unix kernel (Linux, *BSD, whatever), for example? How many could change from using asynch or non-blocking I/O to the more easily understandable, maintainable, and verifiable (security-wise) traditional blocking I/O by breaking out the various functions into distinct processes/executables?
The "Keep It Simple, Stupid" (KISS) principle indeed may have been violated by the early Multics design sufficiently to doom it in the long run vs. Unix, but that doesn't mean we've entirely honored it in Unix-land either. Especially now that we've "won", in the sense that we're competing primarily against an OS that makes Multics look comparatively simple and straightforward (Windows 2000), it's tempting to just "pile on the code" without further regard to KISS, thinking the goal is to further the position of (some variant of) Unix, rather than the widespread deployment of KISS-based software.
Let's strive to avoid that temptation, assuming it's not already too late.
Today, President Clinton announced a new policy to handle the longstanding issue of closet Linux users throughout the military.
The policy, dubbed "Don't Ask, Don't Shell", promises that as long as Linux users don't make their preferences known, they won't be disciplined.
Bill Gates called the policy "...a poor compromise compared to the proper response of interrogation and dismissal of anyone with Open Source tendencies, given the importance of secrecy in military organizations."
Nor was Linus Torvalds happy with the outcome. "It is ridiculous to think that, in the year 2000 -- or, in Microsoft terms, 1980 2.0 -- soldiers have to worry about being open and honest about using Linux. It's not bash users, but Linux-using bashers who should be targeted as insufficiently American for the military", said the famous Finn.
Richard M. Stallman claims the policy is a strained attempt to solve a problem with military personnel using Linux. "GNU/Linux users in the military might make better soldiers in the long run, which should TCL the generals. But soldiers using proprietary software shouldn't be allowed to benefit from working arm-in-arm with GNU/Linux users. That'd be an unfair Scheme since the GNU/Linux software can be shared but the proprietary software cannot."
Military personnel asked about this new policy had a wide range of reactions:
"I don't want to find myself stuck in a foxhole with some Linux nut, but I guess as long as he keeps it to himself, I can live with it."
"Linux or Microsoft, who cares, as long as the job gets done."
"How am I supposed to keep my using Linux a secret -- reboot my machine twice a day for no apparent reason?"
The Linux and BSD Alliance, formed to combat source-bashing worldwide, claims the policy is a small first step towards widespread acceptance of consenting adults exchanging source code as they see fit. Spokesdeity Eric Raymond explains, "we've long felt that if every closet user of an Open Source(TM) product in the military suddenly turned blue, they'd look butt-ugly in those uniforms." (Raymond is a well-known supporter of the Second Amendment right to keep and bear source.)
On a more humorous note, the editor of Soldier of Fortune Magazine announced they were responding to the new policy by making a small change to their name. They'll now be known as "Soldier of fortune Magazine".
Sorry, I was hoping it'd be seen as funny/sarcastic. That's partly why I didn't put a +1 on it myself.
My point was that, as far as today's American law-enforcement system is concerned, someone saying "you'll have to step over my dead body before you get your hands on my [whatever]" is just a hail of bullets short of no longer being an obstacle to obtaining that [whatever].
Well, that's overstating it somewhat, but there are quite a few people dead at the hands of law enforcement because they wouldn't give up their property, etc. See the usual list of suspects, such as Ruby Ridge, Waco, etc.
In essence, the phrase "over my dead body" normally indicates significant stubbornness. In cases like this, however, such stubbornness is irrelevant, except to the extent to which paramedics and/or morticians will end up helping law-enforcement out in a given attempt to enforce a court order to retrieve computers.
It would be wise for all so-called "hacker dudes" to remember this, and think carefully about what is truly worth dying for.
Now, Mr. Coward, did you really need such a verbose explanation? Were you really confused as to why I said "what's your point" in response to someone saying "they'll get it over my dead body"? Or did you think the original poster really meant to indicate that, in the event some suit gets a court order to retrieve his computer, he's willing to literally die to resist that court order? I sure as heck didn't. For myself, I'd rather live and fight the legality of such a thing to that bitter end, not my own life's.
(After all, if one is willing to die to protect one's computer, then, having died, that computer is no longer protected. Hardly worth dying for, compared to, say, giving up the computer and deciding on a course of action that could make future occurrences less likely.)
Gosling might have been the original author of a particular variant of Emacs, but he did not write the original Emacs.
Richard M. Stallman wrote the original Emacs, in MIT TECO, for use on MIT's ITS operating system. I know, because I was probably one of the first few people to try it out. (Happened to be hacking in the AI building one night when I saw his "post" about this new set of Editor MACroS. Tried it, thought it was cute, but stuck with TECO.)
He turned the code over to a software publisher called Unipress Software way back in the UUCP-only era (circa 1985). They sold distributions and full source distributions to tons of companies, gov orgs, and universities. They made flenty of feature enhancements, re-writes, etc. They paid Gosling a nice royalty for every sale.
At some point Stallman picked up one of the source distributions and made some modifications. They were good modifications, IMHO. Some of them were lame (e.g.- simply removing the Copyright tags). And then he started giving it away for free.
It's possible, from a historical point of view, that you're right. But I'd like to see a more definitive account from someone I trust -- someone who doesn't think Gosling wrote the original Emacs, for example.
This is the founder of the Free Software Foundation. I believe at some point he did in-fact completely re-write the code. But this was far more recent than you'd expect.
I recall hearing about some important rewriting of a disputed module (or set thereof) back in the late '80s or early '90s. The dispute might have been over whether RMS had actually copied from UniPress Emacs vs. an earlier (free?) Gosling Emacs version, the latter having been claimed to be "free" by some. (Perhaps Gosling once told, or was believed to have told, RMS or someone that it was okay for RMS to copy from his Emacs, since RMS invented it, after all, and this "tale" didn't get properly communicated through the UniPress aquisition. I'm really just speculating here, based on some probably-shaky memories of third-plus-hand info. I don't recall ever actually discussing these issues with RMS myself, because it's never seemed important enough to do so.)
So I disagree entirely with your implicit assertion that RMS and Project GNU got started by illegally copying a proprietary product and then rewriting it to avoid legal hassles, even though some aspects of your story might have elements of truth to it.
I've found RMS to be many things, but unprincipled about copying other peoples' software without permission is not one of them. And the sort of dispute I think occurred vis-a-vis Gosling's Emacs is exactly the sort of thing that one could reasonably agree could occur without either Gosling or RMS having knowingly done anything wrong, given the ad-hoc nature of communications over such matters (like copying software) back in those days.
One thing for sure: without RMS, there'd have been no Gosling Emacs and no UniPress Emacs. But without Gosling Emacs and without UniPress Emacs, there'd have still been a GNU Emacs, for the same reason GNU CC was created: because it was so important to have one, it had to be done ASAP, one way or the other.
(FWIW, ISTR that UniPress Emacs was pretty decent, in terms of speed on a VAX/VMS system, back when I demoed it circa 1986, compared to some other commercial variant -- CCA Emacs? -- and I think we chose UniPress as a result, despite what I recall was a non-full-featured extension facility. It was the second Emacs environment with which I became fairly familiar, the first being Pr1me's Emacs. I haven't yet gotten familiar with GNU Emacs to the same degree, despite having used it for some 10 years now.)
If members of the Open Source community have patents that are being used against closed source companies, it will be hard not to look disingenuous when we argue that they shouldn't use their patents against us. It will be pointed out that we stand by our convictions only when it is convenient to us, and we will look worse than the 800 pound gorilla. Because the patent situation is one of the few Achilles' heels that Open Source really has, I think this is a potentially dangerous development.
I agree, and, IIRC, I made the same point (using significantly different language) when this issue was being discussed among RMS and others on, again IIRC, the Free-Software Business mailing list (I think it's at fsb@crynwr.com, but have long since unsubscribed).
The results of those discussions, which took place well over a year ago, I haven't tracked, but there looked to be significant effort directed towards creating some sort of Open Patent Pool.
All in all it's a reasonable, and fairly direct, strategy.
So while I share your concerns that once "we" (free-software enthusiasts) head down the path of taking up the same weapons being used against us, we won't have nearly the public support we'd have if we remained unarmed, I'll point out a few things:
It's probably already too late -- there might already be enough defensive-patenting going on in the free-software community to make this a non-issue.
It is probably better to prepare to defend oneself against a known enemy than to count on public support for having purposely avoided doing so.
Down the road, I'd like to think free software (or Open Source if you like) will be so successful it won't be seen as an underdog -- at which point, public sentiment might be less reliable than possessing suitable weaponry (i.e. defensive patents).
Given that, it's probably best for us to, having registered our concerns with this approach, move on to supporting the other one being chosen.
So, personally, I support aggressive patenting of software (even business and genetic) "inventions" for the purpose of using them defensively in support of free software (and free exchange of information overall), even though I don't support the patentability of inventions in those areas generally.
(FWIW, I also agree that the GPL probably disallows distributing a version of the Linux kernel containing a patented technique that is licensed for use by only, say, Linux, as compared to any GPL'ed software. I suspect the fine points of this are yet to be worked out in this particular case, and expect the owner of this shiny new patent will appreciate the feedback provided here at/.)
If you're really against multibillion dollar corporations, then you should be buying all your music CDs from local indie bands. You should be running Linux (though I have no idea on what CPU). And you shouldn't be watching Hollywood movies or TV *at all*.
I, for one, am seriously considering not paying to see movies anymore. (Haven't gone to see one for quite awhile anyway, and have decided not to go see some I was hoping to see shortly, like "American Beauty", "Galaxy Quest", and "Stuart Little". Yeah, quite a range of "taste" there, I realize.)
But my main interest is no longer "contributing" my $$ to the MPAA or any organization that pays it $$.
I'm not sure whether there might be movies I could pay to see that aren't MPAA-related, but doubt it.
More to the point, I don't think my watching TV helps the MPAA at all. But paying my cable bill might. In the meantime, when I can see those movies for "free", i.e. no cash changes hand because of my personally viewing them, I don't have a problem with watching them. E.g. when/if "Galaxy Quest" shows up on NBC, broadcast over the airwaves, I'm not going to purposely avoid watching it. I am going to avoid paying to watch it, which means I'll happily wait months/years to see it, if ever.
Is there a site where I can find out how to best avoid rewarding the MPAA for its vicious, immoral assault on individual rights (e.g. by having an innocent 16-year-old Norwegian student arrested)?
The velocity of light in a vacuum is constant. Most of the time, the speed of light in an object is usually only fractionally smaller than the speed of light in a vacuum, and as a reuslt the difference is usually ignored to simplify things for the person doing the mathematical calculations (physics classes, for instance).
However, there are certain exotic materials and methods that can be used to slow the speed of light down drastically. This would be one application of those materials/methods.
Then it sounds like this experiment, modified, could result in the instantaneous destruction of the universe:
First, get the light within the artificial vortex to slow down.
Then, place the device containing the experiment within a good-quality vaccuum, like an Electrolux (or an old VAX).
At that point, the light within the experimental device has a problem -- it's supposed to go the speed of light 'cause it's in a vaccuum, but it's supposed to go slower because it's going through some other materials.
The result of this contradiction might be the immediate destruction of the entire universe, followed by some quick behind-the-scenes fixing of microcode bugs and a reboot. (This sort of crash is known by the heavenly hackers as a "BSOD", or "Black Suck of Death".)
(Or, we might just learn which if these "laws" is wrong!)
So! Have you started blocking 1-800-Collect yet? Oh wait, I suppose that might actually be illegal...
My wife and I stayed in a hotel some 10+ years ago in downtown Dallas (well, in Reunion Plaza anyway).
It's phone-usage card said that 1-800 calls were free, except those to long-distance services.
It was obvious to me then what a ludicruous scam this was, so I called the front desk, asked to speak to management, and explained in no uncertain terms that we were not to be charged for any 1-800 calls -- no singling out, e.g. of numbers that happen to "compete" with their services -- unless they would accept that we'd leave the hotel immediately and never do business with that chain again.
Though they agreed to this after some discussion, the charges (to our Sprint number, I believe) showed up on the bill anyway.
Another phone call or two was all it took to have those charges removed, but I doubt we'll ever stay in that hotel again. (Since I was born in Dallas, and have relatives and family friends there, that represents a non-zero loss of revenue for that hotel.)
Somewhere there are schools of business management that are teaching this kind of garbage, and they must be stopped.
IMO the most effective way to stop them is to expose the people who perpetrate this nonsense, and use your power to make it difficult for them to exercise their power ever again.
E.g. make an example out of people like this Mr. Duckenfield character. Refuse to hire them if you're in upper management of any firm doing IT-related business. Refuse to work for any firm that employs him in any role with similar powers. For the time being, make it clear to Clemson that if he's employed there beyond, say, the end of next week, you won't attend that school or work for it ever again.
Nothing personal, of course -- all you're doing here is exercising your rights to block access by Mr. Duckenfield to the communications facilities you use to reach your fellow students, employees, customers, friends, and family.
Maybe if this happened, and became more effective, throughout the industry, the message would go out among all those MBAs (and, yes, my wife's a Stanford MBA, but, no, this kind of lunacy would never occur to her) that to even contemplate such insidious micromanaging of peoples' lives for reasons such as increasing profits had better offer huge payoffs, because it risks one's entire career in IT and related management fields.
If you don't fight it now, it'll only get far worse, more difficult to detect, and harder to fight as more and more of the populace is convinced its "normal". (As many others have already pointed out in their own words.)
Speaking from a legal perspective, though, it seems to me this should be actionable as fraud or breach of contract, on the basis that the implication of a phrase such as "Internet access" or "Web access" includes no such micromanagement, except in cases required by law (e.g. restricting access to pr0n, sites violating the law, etc.).
But, of course, the USA gave up the notion of holding lawyers and police to such a modest standard long ago, culminating in the "not guilty" finding against Clinton by the Senate, so there's little likelihood of making inroads using this argument.
So, for now, rather than making the rational case that this sort of behavior might constitute actionable fraud, one must consider resorting to simpler and more direct remedies: "you promise me access to the Internet, then block me from calling my grandma using its facilities so you can earn more $$, fine, I'll make sure you pay for that for years to come".
Sad that the situation seems to require such behavior, but that's the inevitable result of systematically dispensing with the rule of law to obtain short-term conveniences: revenge becomes more prominent as an enforcer of the peoples' morality.
(Not that I'm advocating revenge per se, just a very mild form of it, just as if a particular brand of router often gave you trouble and the manufacturer laughed in your face when you complained, you'd avoid that brand for years to come, even if the manufacturer had promised it was fixed after realizing it needed your business afte r all.)
Slashdot Mirror
Dunno about "wisdom", but there is some humor in the use of this misquotation of a Biblical verse to justify a position not supported at all by the verse itself:
(Emphasis added.)
After all, doesn't it seem unlikely that any credible "wisdom" would claim as the root of all evil something that was invented only a few thousand years ago? But the love of what it represents...well....
Worried???
Heck, it's probably why he created the universe in the first place!
That, and, until we get our act together and build the One Eternal Desktop GC (God Computer) for Him, He can amuse Himself playing the ultimate game of Asteroids!
That's funny...that is my problem with people who are anti-religion. All those people who think they're so important, smart, possessed with an "infinitely-meta"-understanding of the human condition, that they need to win me over to their position of rejecting religion.
As someone with a strong scientific bent, I understand many of their concerns about blindly adopting any set of religious beliefs.
But as someone with a strong moral bent, I also understand many of the concerns of the religious about the likely realities of any government or society that officially eschews religious beliefs of any kind.
After all, the most effective, concentrated killings of millions of peoples in this century alone have generally been perpetrated by those professing atheist beliefs against those they perceived to hold dangerously religious beliefs. "Religion is poison", and all. (Yes, I know that was -- presumably -- a fictional quote, from "Seven Years in Tibet", but it certainly sums up -- along with the corresponding actions of the Chinese government -- the attitude I see many atheist/non-religious people in the "free world" demonstrate.)
So, please, the next time an obnoxious, clueless "know-it-all" tries to ridicule your beliefs, impose his belief system on you, etc., and happens to be using religion to do it...
I do: Beginner's All-purpose Symbolic Instruction Code, otherwise known as BASIC.
Since around 1980 at least, it seems most people thought of it as an interpreted language, or, more properly, of its implementations as interpreters.
For early PC's that may well have been true (with keywords and such converted to byte codes internally, to save space versus storing the whole program in ASCII).
But the original and many subsequent BASICs were environments that looked interpreted but actually compiled when the " RUN " command was issued.
(Which, for a large program, would mean a noticeable wait before anything useful happened within the program.)
That goes back to the mid-60s, and through my own personal close encounter with TOPS-10 BASIC around the mid-70s, when I first learned how compilers worked (and what PDP-10 assembly code really looked like) by typing in the whole thing from a listing! (Took about three months or so on my beat-up KSR-33 Teletype.)
Not that I'm aware of. HTML and C code are two different things, in the sense that both have static semantics, but C has dynamic semantics as well. (HTML does, presumably, when you expand it to include Java, Perl, other Turing-complete CGI stuff...but I'm getting out of my element here, maybe HTML these days is dynamic too. I use it only statically.)
So, a static analysis tool can catch "b += b += 2;", and tools like lint and GCC (with its various warning options) try to be good static analysis tools.
But to really be foolproof, one needs static, dynamic, and some other sort of analysis.
Dynamic analysis would catch "b->foo += c->foo += 2;" when (b == c), but only at run time, unless of course static analysis can prove that it'll always be true. (Remember, run-time analysis is better than nothing, but isn't "foolproof" -- you want to find all bugs in your code before it's deployed, not when it goes to drop the oxygen masks during an emergency decompression or something. ;-)
The other sort of analysis boils down to the halting problem, but can in practice be quite useful, just not entirely foolproof. Here the statement is analyzed statically, but in a complete context so logical relations can be asserted in boiled-down form for the program as a whole. (E.g. "If the input file contains a zero byte, the program is undefined because it'll perform a divide by zero in line 1234.")
Anyway, yeah, a web site that validates C (etc.) code against prevailing standards would be pretty cool! Maybe few would use it, but they'd be pretty grateful, and it could settle all sorts of tedious arguments more quickly. Feel free to send me URLs to such things.... ;-)
Trusting GCC to reliably catch all violations of the standard is unwise. -pedantic is not really about catching coding errors, anyway. You really want some kind of -W option to catch this and, yes, it should ideally be on by default.
It means GCC doesn't catch this sort of bug for you by default. Maybe it would if you specified -Wall -W -O2 or something.
No, because I don't track the standardization efforts (not even of C) closely. We're not talking about a "feature" so much as a detailed rule of behavior, designed to allow certain optimizations to take place. C is not Java; it does not mandate many sorts of ordering of things like side effects, the result being various things are left undefined. "Undefined" means not valid C code.
I believe I gave the basics of a good reference -- section 3.3 "Expressions", which might be numbered or even titled differently since 1988-12-07.
Nothing, if any of a, b, c, d refer to the same storage. Assuming they don't, though, which is likely what you mean to do, then what you're missing is that the sample statement does not violate this wording: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression."
And, from an anoncwrd:
First, I really know only FORTRAN 77 well, and that as an implementor, not a user. I know far more about ISO C than I do the present Fortran standard (95). (Which doesn't say much, I'll admit.)
Second, I wasn't objecting to evaluation order, but to the assumption of modification order in the original code.
A statement like "b += b += 2;" has only two pertinent sequence points, the one prior to the beginning of the execution of the statement, and the one at the end. There are no sequence points within the expression itself.
Now, y'all are right that "b += 2" must be evaluated before the rest of the expression.
But you're wrong in assuming the result of this evaluation is anything more than as if "b + 2" had been written instead.
Since there's another (outer) b += ... in the same expression, the C standard (draft copy I have anyway) says the expression is undefined. (I.e. it specifies conditions for the expression such that it is defined, and the statement in question violates those conditions, therefore it is not defined according to the standard.)
From a technical, practical-implementation point of view, the expression could be implemented (compiled as) "tmp2 = b + (tmp1 = b + 2);" with the following side-effects specified:
Specifically, the order in which those two assignments, vis-a-vis the evaluation of the expression, happen is unspecified, and an implementation could choose any order at any time, assuming it meets the obvious def-use ordering (i.e. tmp N must be defined before it can be referenced). You can't assume the b = tmp1; modification happens before the tmp2 = b + ... evaluation, for example.
So, you can't rely on the inner assignment to b being completed (i.e. the modification of b itself as a side effect) before the subsequent reference to it as part of the outer "b += ..." operation. So it might have the old value or, strictly speaking, any other value, or start World War III, or whatever.
It is undefined, according to my draft copy, because a gets modified twice, not once, between the two sequence points. a=(a++,a) fixes that, I think, since there's now a sequence point between the two modifications.
You might say "but the same value gets written to a regardless of whether the a= or a++ modification happens first", and I'd agree with that, but the wording in the standard does not make a distinction between multiple modifications of an object with the same value versus with different values.
So, you might get away with it on more implementations (compilers, machines, etc.), and that's all nice and well, but it isn't any more "defined" than the clever XOR-hack .sig.
BTW, read also the wording under "Assignment operators". In my draft copy it says "The side effect of updating the stored value of the left operand shall occur between the previous and the next sequence point." Y'all are assuming it occurs between the evaluation of the assignment operator and the evaluation of any lower-precedence (outer) operator -- but it doesn't, it might occur later than that.
Finally, hey, couldn't y'all just read the comp.lang.c FAQ? I just pulled it up in no time, and questions around 3.3 seem to pretty succinctly say what I've been saying more long-windedly.
P.S. I'm clicking "No Score +1 Bonus" again on my post. It seems like canonical /. practice to do so in cases like this (off-topic posts).
Not in ISO (Standard) C it doesn't; it's undefined. In "pidgin C" it does, if the reader assumes sequence points within the expression as if you'd written:
Specifically, operators like ^= do not define sequence points, so there's no assurance that the inner assignment to b will happen before the outer one. In my oldish draft copy of ANSI C, the second paragraph of 3.3 "Expressions" makes it clear the two modifications of b in your no-sequence-point-containing expression renders it undefined.
(Of course, my version hasn't been tested or carefully analyzed, but I wouldn't make it my .sig. ;-)
1989-09-12 Page 8
Software Makers Row Over Patents
1989-07-12 Page 9
Developing Software Is No Picnic
Sometime around 1988
A large article I can't lay my hands on, in which he describes Project GNU. This was one of the articles that inspired me to contribute to GNU by 1989, which led to the development of GNU Fortran (g77). At least, I'm pretty sure it was authored by SLG!
Article in Technology Review:
1991-02/03 Pages 53
Programs to the People "Computer whiz Richard Stallman is determined to make software free -- even if he has to transform the industry singlehandedly."
SLG may be wrong in his predictions, but he's not writing as a newcomer to Linux, Unix, GNU, or free software in general.
Perhaps, but, in my view, what distinguishes Iran/Contra from those other episodes is that the raison d'etre for the "sins" included the attempted return of American hostages and the defense of the American hemisphere against the encroachment of Soviet-supported communists.
Disagree with the effectiveness or desirability of either of these motives all you, dear reader, might want, but you're unlikely to convince me that they in any way approach the seething selfishness of the motives for Watergate or, even worse (since Nixon was covering up for others at first), the various Clinton scandals.
(More and more, I'm amazed this country managed to elect someone as comparatively uninterested in obtaining and wielding personal power as Ronald Reagan to President. As we all do -- something we're always reminded of when discussing Clinton but somehow by people who inevitably chime in contrariwise vis-a-vis Reagan -- he had his faults, but constantly representing himself as everyone's personal source of happiness wasn't even close to one of them. And that seems to explain, more and more, the confusion of so many historians/biographers, who are thoroughly accustomed to the sort of egos that typically seek high office, as well as the seething hatred directed towards him by those on the Left, who resent his "demonstration" that, indeed, it is the sincere efforts of each and every free citizen, rather than a comparatively small ruling intellectual elite designated as infallible, that is needed for our species to survive and prosper.)
Not clear. What is clear is that humanity (at least US society) is largely willing to overlook the sanctity of life, vis-a-vis abortion (visited upon the only form of human life that is defined as 100% innocent of any crime of thought or deed).
But while theoretically God could create Life again, the Judeo-Christian God is widely represented as having made Himself quite clear that we're a "one-shot deal".
Though, other religions view creation as ever-occurring, or at least repeating, and some of those "other religions" include Christ-based (and perhaps Judaism-based) ones.
Personally, what I believe is that it is our valuing of human life that strengthens both our willingness and our ability to preserve all life, throughout the universe, regardless of size or "intelligence", in the long run, if that is indeed an aspect of our "destiny". If we don't value each human life as unique and special, the slope from there to not valuing any form of life at all is steep, short, and slippery.
Indeed, if that ever becomes widely accepted as "fact", we should then become a better species.
But that isn't quite what is being promoted by much of today's scientific/educational system, which generally depicts life as nearly inevitable given a (comparatively) small amount of the right elements, input energy (solar or geothermal), and a modest amount of time (a billion or so years).
Note that I agree strongly with the sentiments you express, just not so much with your belief that "they" wish to prove them as true! So thanks for your beautiful post!
Ditto for object files, executable files, etc., though not quite as much generally.
But, in theory, a Linux i386 executable can be created that, aside from some initialization code, looks as much like plaintext in expressing the program's logic (e.g. it could be Java code) as can similar PostScript code with similar initialization code.
If you're looking for a 100% reliable way to automatically determine whether a particular form is "opaque" vs. "transparent", you'll no more find it than you'll find one that distinguishes between "source code" a la the GPL and the alternatives.
That sort of thing is left up to humans to assess, in courts of law, for legal issues like this.
Another poster explained that this is necessary to disallow a recipient simply changing the GDL (FDL?) in a redistribution of someone else's work. Kinda like making it explicitly invariant.
Keep in mind the GPL isn't GPL'ed either. And, yes, people have occasionally wondered why not over the years. The answers are basically the same: both licenses are designed to grant blanket permission to change both the style and the substance of the works distributed under those licenses, but, to do that, the licenses themselves must not be allowed to be substantively changed. Disallowing any changes is the surest way to achieve that.
This is kinda like the concept of "human rights". No matter how much anyone talks about them, there's one incontrovertible fact as long as more than one human exists: almost every such right requires the ability to suspend that right in specific instances to assure them generally.
As an example: the right to not be physically assaulted must be suspendable in instances where person A physically assaults person B, and will not stop until person B is long dead or person C (for "Cop" ;-) physically assaults person A in order to stop it. Otherwise that "right" is unenforceable; or, if there's no such thing as such assault, there's no need to state or even discuss it in the first place.
(Of course, if someone can come up with a way for C to stop A in a way that'd be considered perfectly legit under any other circumstances -- i.e. not prohibited by virtue of claiming A's "rights" -- that's great. I can't think of a way offhand, and tend to suspect that's because such things are well-neigh impossible, as is, by applying suitable logic, the notion that any human government or system can secure for the people rights, liberties, or happiness they cannot secure for themselves.)
It's a copyright on a particular arrangement, or set, of things, as distinct from the copyrights on those things. I don't know offhand how supported this concept is by actual legislation, but it's apparently considered effectively supported by that and/or by precedent set as the result of litigation.
So, in theory at least, someone can copyright a particular combination of Open Source packages as they distribute them on their CD, even if they own none of the copyrights on those underlying packages.
Think of the list of those packages as itself a copyrightable plaintext file, so anyone reproducing that list -- whether as an identical text file, or as the "translation" of it represented by "ls -1" on a directory containing the packages -- could be considered in violation of that copyright, unless they could show independent creation.
Yes, I see plenty of sense to that clause.
Since there's not yet such a thing as a 100% correct translation automaton, and in fact human language (those in practical use anyway) is full of ambiguities, the author of a text is ultimately the best resource for determining the accuracy of a translation.
(Being a legal document, the GDL focuses on the copyright owner of a text, rather than the original author, which allows the author to confer authority for determining accuracy of translations, among other things, to others.)
With that in mind, the clause appears designed to allow contribution of a translation to a document by anyone in a modified redistribution, but not replacement of the original text as authorized by the copyright holder of sections of the work considered important ("invariant sections").
(Of course, if the copyright holders give specific permission to provide such a replacement, that's allowed by the license -- though the GDL itself needn't specify that, it's a convenient way to express the idea that a copyright holder doing such a thing isn't considered to be violating the "spirit" of the GDL, I suppose.)
As translations are contributed that are judged by the copyright holders to be correct, permissions can be given to provide them as replacements for, not just contributions in addition to, the original versions of invariant sections.
Ditto the GDL itself. Until the copyright holder (the FSF) approves a given translation, someone may contribute their own, but (I would hope) the GDL does not permit that translation to represent itself as the authorized version, and requires it to point to the original English version as such. (I haven't looked at this version of the GDL yet; it's been months since I've reviewed an earlier version.)
Yes, catching all such bugs is believed impossible, but I used the phrase "high-quality" to avoid a longish explanation.
GCC currently tries to catch 'em, but fails (from what I understand) for the reasons you cite.
More specifically, what I objected to last year was the assumption that, first, GCC should accommodate such broken code by defaulting to assuming all code is broken (therefore defaulting to lower performance for correct code). I lost that argument; GCC now (as of 2.95.2, perhaps .1) defaults to assuming all code has the aliasing bug.
Second, I objected to the proposal (by RMS, IIRC) that the internals of GCC be (partially) redesigned to make the detection of these bugs (the warnings) of higher quality.
Note, it wasn't the "higher quality" part of that to which I objected -- it was the "change GCC" part.
Even then, it wasn't changing GCC to make it do its job -- generating correct code -- better to which I objected.
So I made the point that, if you really want to provide a tool that does a high-quality job of catching such errors, go write it -- as a tool separate and distinct from GCC. That way, users of GCC won't have to wait for some distant, upcoming release to quickly install and use the tool (this works for users who don't want to download snapshots of GCC in development, but would try just a smallish tool).
More importantly, GCC won't be destabilized just to provide a new warning. Warnings printed "casually" in the normal course of a program's business are, for the most part, fine and dandy, but when you start talking about reworking the internals of a large program like GCC just to accommodate a new warning, you're losing sight of what that program is really for.
Of course, I lost that argument too, since it basically boiled down to saying "people should run lint on questionable code, and leave the compiler to do the compiling" -- which I believe now, much moreso than I did 10 years ago.
That thinking goes in the opposite direction of much of today's high-profile software development, from Microsoft's macroapps to (as another poster correctly pointed out) the FSF's macrowares.
As to your point that C/C++ might not be the best language, I -- and one or two other prominent GCC developers -- made that very point to Linus Torvalds himself, in response to his complaints that GCC's huge set of extensions to standard C still wasn't quite exactly what Linux needed.
Needless to say, I got a few pieces of hate mail for that suggestion (especially to my inappropriate claim that he didn't know anything about good language design in the same post/thread). (There's more I could say about this, but it's best for readers to review the threads at gcc.gnu.org.)
The symptoms here are all related to the same desire to take something that's good because it's simple and make it ubiquitous by making it complicated (by which I don't necessarily mean making the code more complicated -- deciding that GCC assumes bug-laden code makes the spec for code that conforms to GCC more complicated, compared to, e.g., "ISO C"). I.e. it's easier to say "GCC is your one source for all things compiler-related" and get stuck in the mindset that implies a single executable to make it happen, than to realize that a bunch of separate, but cooperatively and thoughtfully designed, applications would be better. Call the collection something like "Hurd"...well, oops.... ;-)
Anyway, the pointer-aliasing episode culminated, after tons of heated discussion, in a compiler that assumes code is broken, that doesn't do a good job pointing out how and where it's broken (and, unless they don't think it's important enough to put news of it "coming" on the top-level GCC web page that I occasionally check out, won't for some time to come), and in at least myself leaving the GCC project.
After all, what that discussion made clear to me should have been obvious by reading the mission statement for the project: generating correct code is not the #1 goal, and it's unclear from the wording whether it's even the #2, #3, or #4 goal. (One could argue that the word "work" means generating correct code, but, in practice, it doesn't -- it means, to GCC developers, generate correct enough code to accommodate the bulk of the code being targeted by GCC at the time. And testing, which is also mentioned, does not mean generating correct code, merely detecting certain forms of incorrect code.)
Personally, I've decided it's more interesting to explore how to write software that is correct, than software that is feature-rich, since, in my experience, doing the former has always paid off in all sorts of ways (e.g. few-to-no callbacks after writing code that others deploy).
That being said, I'm certainly grateful for GCC, Linux, and all those other products being out there, being useful, and working in so many more circumstances than much of their so-called "competition" (how much Microsoft software runs on SPARC chips, for example?).
So it's not a matter of rejecting products outright because they don't embody KISS. It's a matter of encouraging everyone -- not just the developers (like Linus developing Linux) but the users (like Linus using GCC) to respect that principle more, assuming they really believe it had something significant to do with why Unix won out over Multics, VMS, MVS, and so on. That's why I jumped in here: I saw people celebrating the Unix "win" as a "simplicity is better" victory, and wanted to serve notice that many of the people currently prominent in directing the future of Unix haven't gotten the "simplicity is better" memo, or don't believe it, or simply forget to put it into practice too often. Either they're wrong that Unix won because it embodied KISS, or they're going to be wrong that Unix "won" down the road, because what knocks it off is likely to be built out of simpler, not more complicated, components.
(BTW, I happen to think Open Source distribution embodies the KISS principle as well. The alternative includes many activities, such as working hard to obscure your IP, adding license-checking code or dongle support to your software, etc. that contribute complexity to the product that is not needed by users, except to the extent it lowers their up-front acquisition costs.)
I think there's a fair amount of legitimacy to that argument. But, having come from an environment (Pr1me) that is to Multics sorta like Linux is to Unix, I'd like to make some observations.
First, surely some of Multics' complexity was overblown, perhaps because of attempts to have it do more than strictly necessary. I.e. it wasn't sufficiently simplified. We're committing the same "sins" throughout the GNU/Linux universe ourselves, e.g. piling feature after feature onto what should be simple, robust components (such as GCC) rather than providing separate tools. (Compare qmail's design to sendmail's, and then try and figure out why, after tons of discussion on the GCC mailing list last year, there's still no high-quality Open Source way to find pointer-alias bugs in C code.)
Second, much of what we take for granted in Unices of today was inspired, and to some extent proven in the field, by Multics and its descendants, like PRIMOS. Though not an expert on Linux-style dynamic linking, I've found it, and other things like signaling/exceptions, to be, in at least some crucial ways, poor second cousins compared to the technologies (in which I had substantial expertise) available in PRIMOS -- essentially a cheap sorta-clone of Multics -- back around 1984.
Third, hardware and networking improvements have probably significantly changed the "balance" of factors affecting design decisions that went into Multics. Back in those days, processors weren't cheap, therefore processes weren't cheap, nor were the process-creation and process-exchange activities we take for granted today. (Compare how many processes get exchanged and/or created just to handle an email or, heck, even a mouse click on a typical modern Unix system to contemporary equivalent activities back in the early 1970s, for example.)
Yet it seems today's "cutting-edge" Unix applications are designed with a similarly limited mind-set. Applications that truly and (IMO) properly take advantage of the "balance" of a modern Unix system, such as qmail, are few and far between. How many of today's new applications have what amounts to a scheduler inside of a single process, rather than relying on the Unix kernel (Linux, *BSD, whatever), for example? How many could change from using asynch or non-blocking I/O to the more easily understandable, maintainable, and verifiable (security-wise) traditional blocking I/O by breaking out the various functions into distinct processes/executables?
The "Keep It Simple, Stupid" (KISS) principle indeed may have been violated by the early Multics design sufficiently to doom it in the long run vs. Unix, but that doesn't mean we've entirely honored it in Unix-land either. Especially now that we've "won", in the sense that we're competing primarily against an OS that makes Multics look comparatively simple and straightforward (Windows 2000), it's tempting to just "pile on the code" without further regard to KISS, thinking the goal is to further the position of (some variant of) Unix, rather than the widespread deployment of KISS-based software.
Let's strive to avoid that temptation, assuming it's not already too late.
The policy, dubbed "Don't Ask, Don't Shell", promises that as long as Linux users don't make their preferences known, they won't be disciplined.
Bill Gates called the policy "...a poor compromise compared to the proper response of interrogation and dismissal of anyone with Open Source tendencies, given the importance of secrecy in military organizations."
Nor was Linus Torvalds happy with the outcome. "It is ridiculous to think that, in the year 2000 -- or, in Microsoft terms, 1980 2.0 -- soldiers have to worry about being open and honest about using Linux. It's not bash users, but Linux-using bashers who should be targeted as insufficiently American for the military", said the famous Finn.
Richard M. Stallman claims the policy is a strained attempt to solve a problem with military personnel using Linux. "GNU/Linux users in the military might make better soldiers in the long run, which should TCL the generals. But soldiers using proprietary software shouldn't be allowed to benefit from working arm-in-arm with GNU/Linux users. That'd be an unfair Scheme since the GNU/Linux software can be shared but the proprietary software cannot."
Military personnel asked about this new policy had a wide range of reactions:
The Linux and BSD Alliance, formed to combat source-bashing worldwide, claims the policy is a small first step towards widespread acceptance of consenting adults exchanging source code as they see fit. Spokesdeity Eric Raymond explains, "we've long felt that if every closet user of an Open Source(TM) product in the military suddenly turned blue, they'd look butt-ugly in those uniforms." (Raymond is a well-known supporter of the Second Amendment right to keep and bear source.)
On a more humorous note, the editor of Soldier of Fortune Magazine announced they were responding to the new policy by making a small change to their name. They'll now be known as "Soldier of fortune Magazine".
My point was that, as far as today's American law-enforcement system is concerned, someone saying "you'll have to step over my dead body before you get your hands on my [whatever]" is just a hail of bullets short of no longer being an obstacle to obtaining that [whatever].
Well, that's overstating it somewhat, but there are quite a few people dead at the hands of law enforcement because they wouldn't give up their property, etc. See the usual list of suspects, such as Ruby Ridge, Waco, etc.
In essence, the phrase "over my dead body" normally indicates significant stubbornness. In cases like this, however, such stubbornness is irrelevant, except to the extent to which paramedics and/or morticians will end up helping law-enforcement out in a given attempt to enforce a court order to retrieve computers.
It would be wise for all so-called "hacker dudes" to remember this, and think carefully about what is truly worth dying for.
Now, Mr. Coward, did you really need such a verbose explanation? Were you really confused as to why I said "what's your point" in response to someone saying "they'll get it over my dead body"? Or did you think the original poster really meant to indicate that, in the event some suit gets a court order to retrieve his computer, he's willing to literally die to resist that court order? I sure as heck didn't. For myself, I'd rather live and fight the legality of such a thing to that bitter end, not my own life's.
(After all, if one is willing to die to protect one's computer, then, having died, that computer is no longer protected. Hardly worth dying for, compared to, say, giving up the computer and deciding on a course of action that could make future occurrences less likely.)
Gosling might have been the original author of a particular variant of Emacs, but he did not write the original Emacs.
Richard M. Stallman wrote the original Emacs, in MIT TECO, for use on MIT's ITS operating system. I know, because I was probably one of the first few people to try it out. (Happened to be hacking in the AI building one night when I saw his "post" about this new set of Editor MACroS. Tried it, thought it was cute, but stuck with TECO.)
It's possible, from a historical point of view, that you're right. But I'd like to see a more definitive account from someone I trust -- someone who doesn't think Gosling wrote the original Emacs, for example.
I recall hearing about some important rewriting of a disputed module (or set thereof) back in the late '80s or early '90s. The dispute might have been over whether RMS had actually copied from UniPress Emacs vs. an earlier (free?) Gosling Emacs version, the latter having been claimed to be "free" by some. (Perhaps Gosling once told, or was believed to have told, RMS or someone that it was okay for RMS to copy from his Emacs, since RMS invented it, after all, and this "tale" didn't get properly communicated through the UniPress aquisition. I'm really just speculating here, based on some probably-shaky memories of third-plus-hand info. I don't recall ever actually discussing these issues with RMS myself, because it's never seemed important enough to do so.)
So I disagree entirely with your implicit assertion that RMS and Project GNU got started by illegally copying a proprietary product and then rewriting it to avoid legal hassles, even though some aspects of your story might have elements of truth to it.
I've found RMS to be many things, but unprincipled about copying other peoples' software without permission is not one of them. And the sort of dispute I think occurred vis-a-vis Gosling's Emacs is exactly the sort of thing that one could reasonably agree could occur without either Gosling or RMS having knowingly done anything wrong, given the ad-hoc nature of communications over such matters (like copying software) back in those days.
One thing for sure: without RMS, there'd have been no Gosling Emacs and no UniPress Emacs. But without Gosling Emacs and without UniPress Emacs, there'd have still been a GNU Emacs, for the same reason GNU CC was created: because it was so important to have one, it had to be done ASAP, one way or the other.
(FWIW, ISTR that UniPress Emacs was pretty decent, in terms of speed on a VAX/VMS system, back when I demoed it circa 1986, compared to some other commercial variant -- CCA Emacs? -- and I think we chose UniPress as a result, despite what I recall was a non-full-featured extension facility. It was the second Emacs environment with which I became fairly familiar, the first being Pr1me's Emacs. I haven't yet gotten familiar with GNU Emacs to the same degree, despite having used it for some 10 years now.)
I agree, and, IIRC, I made the same point (using significantly different language) when this issue was being discussed among RMS and others on, again IIRC, the Free-Software Business mailing list (I think it's at fsb@crynwr.com, but have long since unsubscribed).
The results of those discussions, which took place well over a year ago, I haven't tracked, but there looked to be significant effort directed towards creating some sort of Open Patent Pool.
All in all it's a reasonable, and fairly direct, strategy.
So while I share your concerns that once "we" (free-software enthusiasts) head down the path of taking up the same weapons being used against us, we won't have nearly the public support we'd have if we remained unarmed, I'll point out a few things:
- It's probably already too late -- there might already be enough defensive-patenting going on in the free-software community to make this a non-issue.
- It is probably better to prepare to defend oneself against a known enemy than to count on public support for having purposely avoided doing so.
- Down the road, I'd like to think free software (or Open Source if you like) will be so successful it won't be seen as an underdog -- at which point, public sentiment might be less reliable than possessing suitable weaponry (i.e. defensive patents).
Given that, it's probably best for us to, having registered our concerns with this approach, move on to supporting the other one being chosen.So, personally, I support aggressive patenting of software (even business and genetic) "inventions" for the purpose of using them defensively in support of free software (and free exchange of information overall), even though I don't support the patentability of inventions in those areas generally.
(FWIW, I also agree that the GPL probably disallows distributing a version of the Linux kernel containing a patented technique that is licensed for use by only, say, Linux, as compared to any GPL'ed software. I suspect the fine points of this are yet to be worked out in this particular case, and expect the owner of this shiny new patent will appreciate the feedback provided here at /.)
What's your point?
I, for one, am seriously considering not paying to see movies anymore. (Haven't gone to see one for quite awhile anyway, and have decided not to go see some I was hoping to see shortly, like "American Beauty", "Galaxy Quest", and "Stuart Little". Yeah, quite a range of "taste" there, I realize.)
But my main interest is no longer "contributing" my $$ to the MPAA or any organization that pays it $$.
I'm not sure whether there might be movies I could pay to see that aren't MPAA-related, but doubt it.
More to the point, I don't think my watching TV helps the MPAA at all. But paying my cable bill might. In the meantime, when I can see those movies for "free", i.e. no cash changes hand because of my personally viewing them, I don't have a problem with watching them. E.g. when/if "Galaxy Quest" shows up on NBC, broadcast over the airwaves, I'm not going to purposely avoid watching it. I am going to avoid paying to watch it, which means I'll happily wait months/years to see it, if ever.
Is there a site where I can find out how to best avoid rewarding the MPAA for its vicious, immoral assault on individual rights (e.g. by having an innocent 16-year-old Norwegian student arrested)?
Of course, users of modern universes will gleefully point out that, in theirs, light rarely actually swaps -- it pages using an LRU algorithm.
Then it sounds like this experiment, modified, could result in the instantaneous destruction of the universe:
First, get the light within the artificial vortex to slow down.
Then, place the device containing the experiment within a good-quality vaccuum, like an Electrolux (or an old VAX).
At that point, the light within the experimental device has a problem -- it's supposed to go the speed of light 'cause it's in a vaccuum, but it's supposed to go slower because it's going through some other materials.
The result of this contradiction might be the immediate destruction of the entire universe, followed by some quick behind-the-scenes fixing of microcode bugs and a reboot. (This sort of crash is known by the heavenly hackers as a "BSOD", or "Black Suck of Death".)
(Or, we might just learn which if these "laws" is wrong!)
My wife and I stayed in a hotel some 10+ years ago in downtown Dallas (well, in Reunion Plaza anyway).
It's phone-usage card said that 1-800 calls were free, except those to long-distance services.
It was obvious to me then what a ludicruous scam this was, so I called the front desk, asked to speak to management, and explained in no uncertain terms that we were not to be charged for any 1-800 calls -- no singling out, e.g. of numbers that happen to "compete" with their services -- unless they would accept that we'd leave the hotel immediately and never do business with that chain again.
Though they agreed to this after some discussion, the charges (to our Sprint number, I believe) showed up on the bill anyway.
Another phone call or two was all it took to have those charges removed, but I doubt we'll ever stay in that hotel again. (Since I was born in Dallas, and have relatives and family friends there, that represents a non-zero loss of revenue for that hotel.)
Somewhere there are schools of business management that are teaching this kind of garbage, and they must be stopped.
IMO the most effective way to stop them is to expose the people who perpetrate this nonsense, and use your power to make it difficult for them to exercise their power ever again.
E.g. make an example out of people like this Mr. Duckenfield character. Refuse to hire them if you're in upper management of any firm doing IT-related business. Refuse to work for any firm that employs him in any role with similar powers. For the time being, make it clear to Clemson that if he's employed there beyond, say, the end of next week, you won't attend that school or work for it ever again.
Nothing personal, of course -- all you're doing here is exercising your rights to block access by Mr. Duckenfield to the communications facilities you use to reach your fellow students, employees, customers, friends, and family.
Maybe if this happened, and became more effective, throughout the industry, the message would go out among all those MBAs (and, yes, my wife's a Stanford MBA, but, no, this kind of lunacy would never occur to her) that to even contemplate such insidious micromanaging of peoples' lives for reasons such as increasing profits had better offer huge payoffs, because it risks one's entire career in IT and related management fields.
If you don't fight it now, it'll only get far worse, more difficult to detect, and harder to fight as more and more of the populace is convinced its "normal". (As many others have already pointed out in their own words.)
Speaking from a legal perspective, though, it seems to me this should be actionable as fraud or breach of contract, on the basis that the implication of a phrase such as "Internet access" or "Web access" includes no such micromanagement, except in cases required by law (e.g. restricting access to pr0n, sites violating the law, etc.).
But, of course, the USA gave up the notion of holding lawyers and police to such a modest standard long ago, culminating in the "not guilty" finding against Clinton by the Senate, so there's little likelihood of making inroads using this argument.
So, for now, rather than making the rational case that this sort of behavior might constitute actionable fraud, one must consider resorting to simpler and more direct remedies: "you promise me access to the Internet, then block me from calling my grandma using its facilities so you can earn more $$, fine, I'll make sure you pay for that for years to come".
Sad that the situation seems to require such behavior, but that's the inevitable result of systematically dispensing with the rule of law to obtain short-term conveniences: revenge becomes more prominent as an enforcer of the peoples' morality.
(Not that I'm advocating revenge per se, just a very mild form of it, just as if a particular brand of router often gave you trouble and the manufacturer laughed in your face when you complained, you'd avoid that brand for years to come, even if the manufacturer had promised it was fixed after realizing it needed your business afte r all.)