Boy, are you in virtual hot water! Your position on deep-linking to parts of your web-site that bypasses your main page has made you the subject of debate (and anger) on the nerd site slashdot.org. That can't be good for PR.
Before you called out your lawyers, you should have talked to the people who run your web-site: what you wish to accomplish is quite possible and relatively easy, technically.
The World Wide Web was designed to make deep--linking possible and painless. That said, there are circumstances, such as yours, where doing so can lead to misunderstanding and confusion regarding copyright ownership, and avoidance of banner ads. Understandibly, this is not in your best interest.
Technically, it is possible for a web server to check the referring link to one of your pages, and if not another of your pages, to refuse to provide the requested data, or otherwise wrap it in an appropriate page (which might include a copyright notice, banner ad, etc.) Even if your web server can't be configured to do this, read-only CGI-BIN scripts can be used to accomplish the same effect.
Hope this helps. Remember, if there is a need to restict access, there is likely a technical solution available, or easy to implement, without having to resort to what amounts to using a legal sledge-hammer to swat a fly.
Yup. Too many kids are in it "for the money". Of course, that was true when I got my first degree in 1982 as well, but it seams to be more of a problem today.
Of course, when the going gets tough, such people are the first ones to get going, and I don't mean it in the "let's get to work" sense.
Trouble is, they're now pegged as the mythical interchangable coder, that managers love to load balance. Development practices have shifted toward avoiding the "hard" problems at all costs, and days and days of overhead doing design and code inspections.
While this is a good idea, from my experience, seasoned designers just don't make the kind of mistakes that these techniques are designed to catch. And when a defects slips into integration or even system testing, the seasoned designer can usually track it down quickly. This requires good analytical skills, the ability to get down and dirty with the code (debuggers and logic analyzers). Today, these are rare qualities.
Unfortunately, most inexperienced kids just spin their wheels at such tasks, can't judge when it is worth learning how to use a strange tool so that it can be brought to bear, and so we have processes to avoid them at all costs.
Of course, this doesn't work: the odd defect slips through and then everyone is left scratching their heads. The "process" is followed for a week to track it down. And, nothing. It is such crisis that separate the "men" from the "boys", as it were (substitute women and girls as appropriate). The seasoned hacker grumbles "outta my way", turns off the source-code listing, and looks at the code generated by the compiler. Not being expert with the native instruction set, he sees something funny and checks the instruction manual. Sure enough, the compiler cached the result of reading some hardware. A bug in the compiler? Surely, that was declared volatile. "What's volatile," askes the confused kid. 'Nuff said. An edict is issued: "Code inspections will, henceforth, include checks for things that should be decalred 'volatile'". And the madness continues until the next bug: a linked-list insertion boundary bug. This time, it's in third party code, and no one can understand it. After all, it isn't indented to the coding standard....
When I started out, most could handle such things, and contrary to popular belief, bugs detected at integration time weren't all that costly, because they were found fast. They're costly today because the skill base to bring to bear against them is shrinking and the likelihood of them happening is increasing.
While early inspections help novice programmers, they hurt the seasoned designer, because he or she just doesn't make the kind of mistakes that this is designed to catch. Spreading the code out with liberal blank lines hurts because you can't see the whole function in an editor window at once.
The trouble here is two-fold: most kids can't code, don't exhale designs, and the crutches that help them hurt the seasoned hacker. He or she does not fit into the modern team profile.
I suspect the problem is more than just keeping one's skill set up to date ("Used Perl? Never... give me 30 minutes and some sample code: what you want doesn't sound difficult), though not doing that certainly IS suicide.
... actually, if open source development leads to faster production of "bad things", then clearly it must be regulated, in the same way hand guns, drugs, booze, and auto licenses are. Only the "responsible" few should be allowed to code openly.
Anything that adds to your strength is always desirable.
Not always - depends on the price you have to pay. Anytime you devolve responsibility to a group, you are at the mercy of the groupthink, which as we know, can be subject to manipulation (propaganda) by the corrupt few.
When associations place people as equals with shared interests and goals, dialog can result in a proposed course of action that many will chose willingly. It's not the easiest course, but it's relatively risk free since a lot of unbiased thought went into it, as opposed to following some agenda dreamed up by a "first above all others" elected by a mob with an average I.Q. of 100 (by definition).
The difference between the "haves" and the "have nots" is growing. It always has and it always will. Progress creates opportinities as much as it destroys ways of life (Consider that today, a physically weak information worker is a much greater asset than a strong brute. 1000 years ago the reverse would have been true).
Frankly, I'm getting tired of the "wanna-bees" who want to share in the growing wealth pie but aren't willing to expend any effort (you think it's EASY hacking 80-100 hours a week?). While I'm not about to suggest "getting rid" of them in any active sense, I do start to think that people who can't manage to keep themselves fed would make pretty good fertilizer for the food we grow once they expire.
On the one hand, I support the idea that those who want to make their software free should be able to restrict what those who don't can do with the fruits of their labour.
Producing a non-GPL readline(), unless done without any knowledge of GPL readline(), is likely to be a cheap stunt of takeing GPL code non-GPL. I presume you did not do this, and you have every right to reimplement that particular function and license it as you wish (as opposed to some free software zealots who would like non-free code to be illegal).
However, if the ONLY reason you produced a non-GPL readline() was to impede efforts to encourage freeing up code (by those who wanted to use readline() but had non-free code), then that's simply spiteful.
I would like to see more code freed up, and I do think that in some cases, the "all or nothing" approach of the GPL hurts. The LGPL, on the other hand "gives away too much" to benefit producers of non-free code. I wouldn't mind an LGPL interpreter from being used in some application, for example, but I WOULD mind someone creatively extendeding the interpreter, and closing off the extentions.
Unlike RMS, who believes that free software licenses should not only keep existing code free, but prevent it from being used with non-free code in redistributed derived works, I do think that in some instances offering a "carrot" under certain conditions to purveyers of non-free code wouldn't hurt the free software community. However, sometimes the LGPL is more of a carrot than I want to offer
I also think that integrators of code should be able to have free code take advantage of (but not necessarily the reverse in most circumstances) non-free code. Hell, that's how most free code was bootstrapped into being anyway. While relying on Qt (under the old license) might not be wise, forbidding the combination of free code with a non-free library until a free one was available isn't wise either -- even if it encourages development of a free alternative sooner.
RMS might argue that one can always structure the non-free part as a library, so simply giving carte blanche to linking from free to non-free code isn't a good idea in general, but doing so makes the interface to the library open, and makes production of free alternatives easier.
Yes - RMS once took offence at my use of the adjective "infective" when describing the GPL, despite the fact that I meant it in a descriptive, not pejorative sense. I quickly s/infective/inoculative/. We should chose our adjective wisely -- even if WE know what we mean, the great unwashed do not, and it is best to avoid getting sloppy in our words when our audience might get the wrong idea.
One thing the Linux community forgets is just how STOOOPID the average person is. And, no I won't tone down the arrogance. Here's why:
These tests suggest the equaivalent of "my car will beat your car in a drag race". Pitty, since many of us thought it wouldn't, but facts is facts.
The problem is that we have an analogous situation where those that need to find a reliable car to get to and from work daily decide which car to by on the basis of which one would likely win a drag race. Hence, STOOOPID.
Certainly, the problems identified can, and should, be fixed. They don't strike me as biggies, actually. Unfortunately, M$ will leverage this for all it's worth, and the idiots out there will believe them. Let us not get caught up trying to perform damage control. Our response should be, "Yeah, yeah, whatever -- if you want M$, then buy M$. Me, I still wouldn't touch it with a ten foot pole."
Smart money already knows that the better deal is, or will very shortly will be.
GNU and Linux have always shone when it came to helping the little guy, and the big guy will continue to throw money away. Money can buy a lot of ignorance.
I'd have to agree with this reversal of the characteristics of Geeks and Nerds.
Geeks also tend to be better at solving meta-problems whereas Nerds usually just know and understand the "latest cool thing" (and twits understand the thing that they THINK is "latest and cool".
Twits fester, Nerds solve, and Geeks adapt.
For example, as a self-proclaimed Geek, I'd say that I understand TCP/IP fairly well -- not knowing by rote the exact encoding of all the fields in an IP frame, or the rtt estimation algorithm, but knowing damn well where to look (including the fact that TCP and IP header parsing is a job for a machine, not a person), and why rtt estimation is important, and the general filtering technique used. This carries from and to other protocols. After all, at the meta-level, an ack is an ack is an ack, and piggybacking is a common technique.
A Nerd, OTOH, might be able to stare at hex dumps and parse out IP and TCP headers with ease. The fact that X.25 receiver readys occur at frame and packet layers might be beyond his comprehension.
Finally, a twit would go on and on about his recent ZMODEM implementation.
You need to have TWO nameservers, on separate nets, to resolve to your IP address.
Since small organizations (like you) are unlikely to have the resources to do this, there are outfits that will do it for you -- generally for $50 to $100 a year. Some allow you to change your own DNS records.
Check out http://www.dyndns.org and http://www.granitecanyon.org (free). Search the Net -- the above sites are by no means an exhaustive list.
I'm still waiting.... Ameritech offers the lines, and ISP but, no, I can't get it and they can't tell me when I can. Grrrrr...
It's ironic in a way: they've been trying to find ways to get an extra $10 a month out of me by flogging some service I don't need, and here I am practically screaming at them that I'd happily give them $50 to $75 a month for a damn ADSL line.
Now, I'm not a GNU/Linux vs. Linux zealot, though I do think that recognition of the standard-bearer of free software ideals is warranted when it comes to Linux.
That said, when someone, like Debian, chooses the GNU/Linux name over just plain Linux, I think that choice should be respected.
Yup... the gummint knew not the potential of the genie it let out of the bottle.
While it's true that TCP/IP and not Fidonet forms the foundation of the modern 'net (and thus state funding and not hacking was the initial seed), I suggest that this is an accident of history -- TCP/IP would have evolved without a shred of state funding soon enough.
Why is it, that when the state contributes a miniscule fraction toward something useful, it is deemed "non-existant, were it not for the benevolent government?"
More than any other single group, with the possible exception of engineers and programmers, hackers have built the Web and the Net.
I'd suggest that the engineers and programmers that "built" "the Net" are hackers: the evidence is the clear tendency toward decentralization as much as possible, for political as much as technical reasons.
It should be up to/.ers to decide what's "exceptional". Do we really want/. to filter the news to us like the major media players do?
Perhaps some sort of per-article tag, relating to kind of content, restrictions, etc. could be used so that indivudual/.ers could select appropriate filters for themselves.
As for copyright violation, I don't see that as Rob's problem.
Re:GNU/Linux is a misnomer
on
GNU Inside?
·
· Score: 3
This is interesting because it reflects my views quite closely: GNU/Linux would be a proper name to give to a GNU distribution released under the auspiscies of The GNU Project. However it is not so simple: Not only is GNU the name of a free "not Unix" operating system, but it also embodies the idea of such a thing.
ANY free operating system that is compatible with Unix could be called GNU. All "Linux" distributions meet this requirement to a large extent (though some, like Suse have an uncomfortable amount of non-free code), and calling them GNU/Linux is not incorrect. Of course, neither is calling them "foo", but if the idea of software freedom is important to the distribution bundler, the GNU moniker should be adopted because it came first.
Futhermore, there are other reasons why the name GNU/Linux should be adopted:
1) Much of the core O/S code is GNU code (that is produced under the auspiscies of the GNU project). Without it nothing runs but the kernel. the same is not true of, say, X: lots of systems do not use a GUI.
2) Technically, if we separate the core O/S code into kernel and non-kernel parts, adopting a / convention makes a certain amount of sense: certainly we can envision GNU/Hurd, or BSD/Linux.
3) RMS deserves credit. This is not a rational reason, but an emotional one. Still, if we wish to credit the man for his work, and are producing a free O/S distribution, calling it GNU/Linux is the right thing to do. I suppose this is Debian's reasoning.
In my discussions with RMS, I pointed out that trying to encourage the use of a proper noun that others don't like, in the face of an already popular moniker is difficult, and encouraging the use of GNU as an adjective instead might meet with greater acceptance. However, this flies in the face of the valid technical argument above (as RMS gently pointed out to me).
To his credit, in "Open Sources", RMS does appear to take this approach, when talking about "GNU/Linux systems". He as also reminded me that GNU, as an adjective already has a specific meaning: software produced under the auspiscies of the GNU project. (I suppose that their release of a GNU system on a Linux kernel would then be called "GNU GNU/Linux"). "GNU Linux" without the slash isn't acceptable: it would mean a Linux kernel release produced by the GNU project.
To those that say that GNU/Linux is too much of a mouthful, the response could be "Well, just call it GNU, then." It all comes down to what you want to convey: a particular distribution, or an instance of a free operating system. The latter really does deserve the GNU moniker. It should not be a surprise that RMS appears to care more about conveying the idea of software freedom than market branding.
As for RMS being a stubborn crank, supposedly insulted by use of the Linux momiker when talking about a GNU/Linux system in his presense: I have to strongly disagree. I made the honest mistake of calling Debian's distribution "Debian Linux" when it is clearly called "Debian GNU/Linux" (in email), and he simply asked me to use the correct name, please. He did not insist that I call Red hat's distribution "Red hat GNU/Linux", though I'm sure he'd like me to (I made clear why I do not, and he did not seam miffed in any way -- disappointed perhaps, but that did not come across.). Methinks stories of his arrogance are just plain FUD.
RMS and I are not in perfect agreement about what should be called GNU/Linux. He has convinced me to encourage others to consider calling their Linux distributions GNU/Linux to reflect the technical nature of the system as well as stress it's free nature as well (and this I do). It is possible to engage the man in debate without having to be in perfect agreement.
Bottom line: If RMS, the father of the modern renaissance of free software, says that he named a free Unix-like operating system "GNU", and wants others to use that name, I am not about to argue that he is wrong, only that people aren't required to heed this particular wish. I suspect that some people want to call some free operating systems something else and get RMS blessing to do so. This ain't gonna happen. RMS has stated his position and is standing by it. It's funny that others seam to be uncomfortable disagreeing with him. Perhaps they are not as sure of their convictions as he is?
RMS is not an 'off the wall' type of person, at least my communications with him have not given me that impression.
He is thoughtful, precise, and very stubborn in sticking to his beliefs, but I, for one, consider that a good quality: he is the standard bearer for what free software represents.
If anyone is off the wall it's those who fail to embrace any kind of consistency in their beliefs.
Re:Who are you to tell me what license I should us
on
BSD vs GPL
·
· Score: 1
Actually, a lot of the extentions made to GPL code by a commercial entity might not be in the are of code that they consider a strategic asset.
I work for a company that produces automated test equipment. One of our big "intellectual" assets is how we make electrical measurements. Still, our systems need an RTOS, networking, code, etc., and porting a GPL OS would require the writing of device drivers, among other things.
Such code would NOT be a strategic asset for us, and cost little to give away: it would be of no value to a competitor unless we both used the same (commodity) hardware (in which case it would be a strategic asset). Typically, we design our own hardware, and the drivers are useless to competitors unless they steal the design for that hardware. They would however, be useful to our customers, who might find and fix bugs, improve performance, etc. (which benetits us, as well).
Er, an operating system is more than just a kernel. It is a set of cooperating processes to get a task done.
And RMS is certainly not a fool. Stubborn, perhaps, but not a fool. Personally, I find that stubborn people are generally the best at finding and killing bugs.
1) GNU is much more than a set of tools. As a proper noun it is the name that Richard Stallman gave to a free operating system, and as an adjective it describes software produced under the auspicies of the GNU Project, who's primary goal the is realization of a free operating system.
A strong case can be made that anyone who has used the GNU tools to put together a free operating system should pay homage to the GNU Project by adopting the GNU name for the operating system.
Now this does not mean that one has to do this, but it is a nice way to honour Richard Stallman's vision of free software. I encourage those who take position, but am not particularly upset if someone doesn't.
The GPL doesn't require it, though RMS may regret this.
2) Linux properly refers to the O/S/ kernel. Calling the entire operating system "Linux" is somewhat of a mis-nomer. Qualifying Linux by the name of the dustributor is still less than satisfactory. This will become more of a problem as the Hurd matures.
Now, personally I think that the only thing that should be called GNU/Linux, without any chance for argument, would be a "Linux" distribution released by the GNU Project, or released with their blessing. Debian GNU/Linux fits this bill.
Furthermore, if the GNU Project does not retain sufficient control over the GNU moniker, it may be used to describe operating systems that are not completely free. This would be a bad thing (and an insult to RMS).
That's the funny thing about virtual worlds: their bounderies are determined by design and not by physical constraints.
Wherever there is scarcity, there will be value placed on ownership, which leads to the development of fungible currency and laws to protect ownership.
As a Libertarian, I firmly believe that resources are best developed when there is a cost to owning them: it behooves the owner to exploit them to the best of his or her ability. There is no reason to believe that a virtual world will be any different.
However the thing about virtual worlds is that they can be designed with softer or non-existant resource limits, thus muting the need to "own" things. If you don't like a particular virtual world, design a different one.
It would be very interesting to see how three different virtual worlds evolve: two with limited resources, one of which forbids trading except in virtual terms, and one which doesn't; and a third where resources are essentially limitless.
The libertarian in me says that of the two worlds with limited resources, the one where non-virtual trade is permitted is likely to evolve faster than the other. Enforcement in the non-trading world can take the form of a "virtual tax" on virtual property levied by the game server owners and used to purchase virtual property which can then be sold by the game server owners ("the state") for real $$$. These real $$$ can then be used to investigate people who trade virtual property in the real world and ban them from the game.
Re:for the love of god, rob, stop the moderation
on
Practical Beowulf
·
· Score: 1
I don't think that moderation should be stopped, but it does need some tweaking.
I too have seen some articles moderated down not because they were trolls, flamebait, or not informative, but because they were unpopular.
OTOH, I have seen articles moderated WAY up (like to +5) without justification (like some of mine). Now, it looked to me that the subject just happened to strike an emphatic response with the moderator, and not be of pulitzer writing quality.
I think that if an article is moderated up as well as down, then at least one of the modertators is judging content as opposed to writing quality and subject relevence. This should be investigated since that isn't what a moderator should do.
...But - would that mean if you were working on such an important project, would you need to be licensed to ensure quality?
No, though if the client did not seek to take care (either by checking the code quality himself, or relying on a reputable certification company), he might be setting himself up for a big negligence lawsuit.
Now, when I know that people's lives depend on the code I write, I make damn sure that if it is going to fail, it fails gracefully, or I don't release the code at all. IOW, I WILL NOT compromise quality in exchange for delivery time to satisfy an employer or client if I know lives might hang in the balance.
I just don't think that forcing that ethic on others is right, nor do I think that licensing ensures it anyway.
Er, I have worked on software where peoples lives depended on it not being buggy. It's one hell of a responsibility and about the only time you can justifiably tell a PHB to "fsck off, it isn't ready yet - or do you want people to die?"
If, in a free market, there is a demand for quality in software development, then surely organizations will arise that offer various certification programs.
Netware and Microsoft have been doing this for years.
So, certification would be inevitable: it's just a question of whether it matters to a particular customer.
Licensing, on the other hand is a beast of a different colour. Licensing means that you can't work without a license. This has no place in a free market, and is usually advocated by those that have a vested interest in controlling the size of the market: unions, doctors, and lawyers do this, with the necessary government 'help'.
The argument usually goes something like this: "With licensing, we can ensure the level of quality you're gonna get from someone in this profession". Of course, this is bogus, since all it guarantees is that a licensed programmer is, well, licensed. The enticement is that a potential employer or contractor does not have to evaluate skills for themselves. Who controls the licensing board, and what is in its best interest?
As with all things that depend on government force for enforcement, such a scheme is not likely to work well: good programmers that can't afford to pay the licensing fees won't get licensed, and bad programmers can lobby to keep good ones unlicensed. The production of free software might even be outlawed (much as practicing medicine without a license is).
With certification, the certifying board has to compete with other certifying boards and remove any possible question of inpropriety, lest it's reputation suffer.
Traditionally, certification has come from Universities (originally for philosophers and medical doctors), trade schools and apprentice programs, and more recently, equipment manufacturers (the guy who works on my car is "certified" by the auto maker to know what he's doing).
Slashdot Mirror
To Whom It may Concern:
Boy, are you in virtual hot water! Your position on deep-linking to parts of your web-site that bypasses your main page has made you the subject of debate (and anger) on the nerd site slashdot.org. That can't be good for PR.
Before you called out your lawyers, you should have talked to the people who run your web-site: what you wish to accomplish is quite possible and relatively easy, technically.
The World Wide Web was designed to make deep--linking possible and painless. That said, there are circumstances, such as yours, where doing so can lead to misunderstanding and confusion regarding copyright ownership, and avoidance of banner ads. Understandibly, this is not in your best interest.
Technically, it is possible for a web server to check the referring link to one of your pages, and if not another of your pages, to refuse to provide the requested data, or otherwise wrap it in an appropriate page (which might include a copyright notice, banner ad, etc.) Even if your web server can't be configured to do this, read-only CGI-BIN scripts can be used to accomplish the same effect.
Hope this helps. Remember, if there is a need to restict access, there is likely a technical solution available, or easy to implement, without having to resort to what amounts to using a legal sledge-hammer to swat a fly.
Regards,
Rene S. Hollan
[address omitted]
Yup. Too many kids are in it "for the money". Of course, that was true when I got my first degree in 1982 as well, but it seams to be more of a problem today.
Of course, when the going gets tough, such people are the first ones to get going, and I don't mean it in the "let's get to work" sense.
Trouble is, they're now pegged as the mythical interchangable coder, that managers love to load balance. Development practices have shifted toward avoiding the "hard" problems at all costs, and days and days of overhead doing design and code inspections.
While this is a good idea, from my experience, seasoned designers just don't make the kind of mistakes that these techniques are designed to catch. And when a defects slips into integration or even system testing, the seasoned designer can usually track it down quickly. This requires good analytical skills, the ability to get down and dirty with the code (debuggers and logic analyzers). Today, these are rare qualities.
Unfortunately, most inexperienced kids just spin their wheels at such tasks, can't judge when it is worth learning how to use a strange tool so that it can be brought to bear, and so we have processes to avoid them at all costs.
Of course, this doesn't work: the odd defect slips through and then everyone is left scratching their heads. The "process" is followed for a week to track it down. And, nothing. It is such crisis that separate the "men" from the "boys", as it were (substitute women and girls as appropriate). The seasoned hacker grumbles "outta my way", turns off the source-code listing, and looks at the code generated by the compiler. Not being expert with the native instruction set, he sees something funny and checks the instruction manual. Sure enough, the compiler cached the result of reading some hardware. A bug in the compiler? Surely, that was declared volatile. "What's volatile," askes the confused kid. 'Nuff said. An edict is issued: "Code inspections will, henceforth, include checks for things that should be decalred 'volatile'". And the madness continues until the next bug: a linked-list insertion boundary bug. This time, it's in third party code, and no one can understand it. After all, it isn't indented to the coding standard....
When I started out, most could handle such things, and contrary to popular belief, bugs detected at integration time weren't all that costly, because they were found fast. They're costly today because the skill base to bring to bear against them is shrinking and the likelihood of them happening is increasing.
While early inspections help novice programmers, they hurt the seasoned designer, because he or she just doesn't make the kind of mistakes that this is designed to catch. Spreading the code out with liberal blank lines hurts because you can't see the whole function in an editor window at once.
The trouble here is two-fold: most kids can't code, don't exhale designs, and the crutches that help them hurt the seasoned hacker. He or she does not fit into the modern team profile.
I suspect the problem is more than just keeping one's skill set up to date ("Used Perl? Never... give me 30 minutes and some sample code: what you want doesn't sound difficult), though not doing that certainly IS suicide.
... actually, if open source development leads to faster production of "bad things", then clearly it must be regulated, in the same way hand guns, drugs, booze, and auto licenses are. Only the "responsible" few should be allowed to code openly.
Think it can't happen?
desirable.
Not always - depends on the price you have to pay. Anytime you devolve responsibility to a group, you are at the mercy of the groupthink, which as we know, can be subject to manipulation (propaganda) by the corrupt few.
When associations place people as equals with shared interests and goals, dialog can result in a proposed course of action that many will chose willingly. It's not the easiest course, but it's relatively risk free since a lot of unbiased thought went into it, as opposed to following some agenda dreamed up by a "first above all others" elected by a mob with an average I.Q. of 100 (by definition).
The difference between the "haves" and the "have nots" is growing. It always has and it always will. Progress creates opportinities as much as it destroys ways of life (Consider that today, a physically weak information worker is a much greater asset than a strong brute. 1000 years ago the reverse would have been true).
Frankly, I'm getting tired of the "wanna-bees" who want to share in the growing wealth pie but aren't willing to expend any effort (you think it's EASY hacking 80-100 hours a week?). While I'm not about to suggest "getting rid" of them in any active sense, I do start to think that people who can't manage to keep themselves fed would make pretty good fertilizer for the food we grow once they expire.
I'm not sure that I like that.
On the one hand, I support the idea that those who want to make their software free should be able to restrict what those who don't can do with the fruits of their labour.
Producing a non-GPL readline(), unless done without any knowledge of GPL readline(), is likely to be a cheap stunt of takeing GPL code non-GPL. I presume you did not do this, and you have every right to reimplement that particular function and license it as you wish (as opposed to some free software zealots who would like non-free code to be illegal).
However, if the ONLY reason you produced a non-GPL readline() was to impede efforts to encourage freeing up code (by those who wanted to use readline() but had non-free code), then that's simply spiteful.
I would like to see more code freed up, and I do think that in some cases, the "all or nothing" approach of the GPL hurts. The LGPL, on the other
hand "gives away too much" to benefit producers of non-free code. I wouldn't mind an LGPL interpreter from being used in some application, for example, but I WOULD mind someone creatively extendeding the interpreter, and closing off the extentions.
Unlike RMS, who believes that free software licenses should not only keep existing code free, but prevent it from being used with non-free code in redistributed derived works, I do think that in some instances offering a "carrot" under certain conditions to purveyers of non-free code wouldn't hurt the free software community. However, sometimes the LGPL is more of a carrot than I want to offer
I also think that integrators of code should be able to have free code take advantage of (but not necessarily the reverse in most circumstances) non-free code. Hell, that's how most free code was bootstrapped into being anyway. While relying on Qt (under the old license) might not be wise, forbidding the combination of free code with a non-free library until a free one was available isn't wise either -- even if it encourages development of a free alternative sooner.
RMS might argue that one can always structure the non-free part as a library, so simply giving carte blanche to linking from free to non-free code isn't a good idea in general, but doing so makes the interface to the library open, and makes production of free alternatives easier.
Yes - RMS once took offence at my use of the adjective "infective" when describing the GPL, despite the fact that I meant it in a descriptive, not pejorative sense. I quickly s/infective/inoculative/. We should chose our adjective wisely -- even if WE know what we mean, the great unwashed do not, and it is best to avoid getting sloppy in our words when our audience might get the wrong idea.
One thing the Linux community forgets is just how STOOOPID the average person is. And, no I won't tone down the arrogance. Here's why:
These tests suggest the equaivalent of "my car will beat your car in a drag race". Pitty, since many of us thought it wouldn't, but facts is facts.
The problem is that we have an analogous situation where those that need to find a reliable car to get to and from work daily decide which car to by on the basis of which one would likely win a drag race. Hence, STOOOPID.
Certainly, the problems identified can, and should, be fixed. They don't strike me as biggies, actually. Unfortunately, M$ will leverage this for all it's worth, and the idiots out there will believe them. Let us not get caught up trying to perform damage control. Our response should be, "Yeah, yeah, whatever -- if you want M$, then buy M$. Me, I still wouldn't touch it with a ten foot pole."
Smart money already knows that the better deal is, or will very shortly will be.
GNU and Linux have always shone when it came to helping the little guy, and the big guy will continue to throw money away. Money can buy a lot of ignorance.
I'd have to agree with this reversal of the characteristics of Geeks and Nerds.
Geeks also tend to be better at solving meta-problems whereas Nerds usually just know and understand the "latest cool thing" (and twits understand the thing that they THINK is "latest and cool".
Twits fester, Nerds solve, and Geeks adapt.
For example, as a self-proclaimed Geek, I'd say that I understand TCP/IP fairly well -- not knowing by rote the exact encoding of all the fields in an IP frame, or the rtt estimation algorithm, but knowing damn well where to look (including the fact that TCP and IP header parsing is a job for a machine, not a person), and why rtt estimation is important, and the general filtering technique used. This carries from and to other protocols. After all, at the meta-level, an ack is an ack is an ack, and piggybacking is a common technique.
A Nerd, OTOH, might be able to stare at hex dumps and parse out IP and TCP headers with ease. The fact that X.25 receiver readys occur at frame and packet layers might be beyond his comprehension.
Finally, a twit would go on and on about his recent ZMODEM implementation.
You need to have TWO nameservers, on separate nets, to resolve to your IP address.
Since small organizations (like you) are unlikely to have the resources to do this, there are outfits that will do it for you -- generally for $50 to $100 a year. Some allow you to change your own DNS records.
Check out http://www.dyndns.org and http://www.granitecanyon.org (free). Search the Net -- the above sites are by no means an exhaustive list.
Hope this helps.
I'm still waiting.... Ameritech offers the lines, and ISP but, no, I can't get it and they can't tell me when I can. Grrrrr...
It's ironic in a way: they've been trying to find ways to get an extra $10 a month out of me by flogging some service I don't need, and here I am practically screaming at them that I'd happily give them $50 to $75 a month for a damn ADSL line.
Now, I'm not a GNU/Linux vs. Linux zealot, though I do think that recognition of the standard-bearer of free software ideals is warranted when it comes to Linux.
That said, when someone, like Debian, chooses the GNU/Linux name over just plain Linux, I think that choice should be respected.
Yup... the gummint knew not the potential of the genie it let out of the bottle.
While it's true that TCP/IP and not Fidonet forms the foundation of the modern 'net (and thus state funding and not hacking was the initial seed), I suggest that this is an accident of history -- TCP/IP would have evolved without a shred of state funding soon enough.
Why is it, that when the state contributes a miniscule fraction toward something useful, it is deemed "non-existant, were it not for the benevolent government?"
More than any other single group, with the possible exception of engineers and programmers, hackers have built the Web and the Net.
I'd suggest that the engineers and programmers that "built" "the Net" are hackers: the evidence is the clear tendency toward decentralization as much as possible, for political as much as technical reasons.
I disagree.
/.ers to decide what's "exceptional". Do we really want /. to filter the news to us like the major media players do?
/.ers could select appropriate filters for themselves.
It should be up to
Perhaps some sort of per-article tag, relating to kind of content, restrictions, etc. could be used so that indivudual
As for copyright violation, I don't see that as Rob's problem.
This is interesting because it reflects my views quite closely: GNU/Linux would be a proper name to give to a GNU distribution released under the auspiscies of The GNU Project. However it is not so simple: Not only is GNU the name of a free "not Unix" operating system, but it also embodies the idea of such a thing.
ANY free operating system that is compatible with Unix could be called GNU. All "Linux" distributions meet this requirement to a large extent (though some, like Suse have an uncomfortable amount of non-free code), and calling them GNU/Linux is not incorrect. Of course, neither is calling them "foo", but if the idea of software freedom is important to the distribution bundler, the GNU moniker should be adopted because it came first.
Futhermore, there are other reasons why the name GNU/Linux should be adopted:
1) Much of the core O/S code is GNU code (that is produced under the auspiscies of the GNU project). Without it nothing runs but the kernel. the same is not true of, say, X: lots of systems do not use a GUI.
2) Technically, if we separate the core O/S code into kernel and non-kernel parts, adopting a / convention makes a certain amount of sense: certainly we can envision GNU/Hurd, or BSD/Linux.
3) RMS deserves credit. This is not a rational reason, but an emotional one. Still, if we wish to credit the man for his work, and are producing a free O/S distribution, calling it GNU/Linux is the right thing to do. I suppose this is Debian's reasoning.
In my discussions with RMS, I pointed out that trying to encourage the use of a proper noun that others don't like, in the face of an already popular moniker is difficult, and encouraging the use of GNU as an adjective instead might meet with greater acceptance. However, this flies in the face of the valid technical argument above (as RMS gently pointed out to me).
To his credit, in "Open Sources", RMS does appear to take this approach, when talking about "GNU/Linux systems". He as also reminded me that GNU, as an adjective already has a specific meaning: software produced under the auspiscies of the GNU project. (I suppose that their release of a GNU system on a Linux kernel would then be called "GNU GNU/Linux"). "GNU Linux" without the slash isn't acceptable: it would mean a Linux kernel release produced by the GNU project.
To those that say that GNU/Linux is too much of a mouthful, the response could be "Well, just call it GNU, then." It all comes down to what you want to convey: a particular distribution, or an instance of a free operating system. The latter really does deserve the GNU moniker. It should not be a surprise that RMS appears to care more about conveying the idea of software freedom than market branding.
As for RMS being a stubborn crank, supposedly insulted by use of the Linux momiker when talking about a GNU/Linux system in his presense: I have to strongly disagree. I made the honest mistake of calling Debian's distribution "Debian Linux" when it is clearly called "Debian GNU/Linux" (in email), and he simply asked me to use the correct name, please. He did not insist that I call Red hat's distribution "Red hat GNU/Linux", though I'm sure he'd like me to (I made clear why I do not, and he did not seam miffed in any way -- disappointed perhaps, but that did not come across.). Methinks stories of his arrogance are just plain FUD.
RMS and I are not in perfect agreement about what should be called GNU/Linux. He has convinced me to encourage others to consider calling their Linux distributions GNU/Linux to reflect the technical nature of the system as well as stress it's free nature as well (and this I do). It is possible to engage the man in debate without having to be in perfect agreement.
Bottom line: If RMS, the father of the modern renaissance of free software, says that he named a free Unix-like operating system "GNU", and wants others to use that name, I am not about to argue that he is wrong, only that people aren't required to heed this particular wish. I suspect that some people want to call some free operating systems something else and get RMS blessing to do so. This ain't gonna happen. RMS has stated his position and is standing by it. It's funny that others seam to be uncomfortable disagreeing with him. Perhaps they are not as sure of their convictions as he is?
RMS is not an 'off the wall' type of person, at least my communications with him have not given me that impression.
He is thoughtful, precise, and very stubborn in sticking to his beliefs, but I, for one, consider that a good quality: he is the standard bearer for what free software represents.
If anyone is off the wall it's those who fail to embrace any kind of consistency in their beliefs.
Actually, a lot of the extentions made to GPL code by a commercial entity might not be in the are of code that they consider a strategic asset.
I work for a company that produces automated test equipment. One of our big "intellectual" assets is how we make electrical measurements. Still, our systems need an RTOS, networking, code, etc., and porting a GPL OS would require the writing of device drivers, among other things.
Such code would NOT be a strategic asset for us, and cost little to give away: it would be of no value to a competitor unless we both used the same (commodity) hardware (in which case it would be a strategic asset). Typically, we design our own hardware, and the drivers are useless to competitors unless they steal the design for that hardware. They would however, be useful to our customers, who might find and fix bugs, improve performance, etc. (which benetits us, as well).
Er, an operating system is more than just a kernel. It is a set of cooperating processes to get a task done.
And RMS is certainly not a fool. Stubborn, perhaps, but not a fool. Personally, I find that stubborn people are generally the best at finding and killing bugs.
Some points are overlooked here:
1) GNU is much more than a set of tools. As a proper noun it is the name that Richard Stallman gave to a free operating system, and as an adjective it describes software produced under the auspicies of the GNU Project, who's primary goal the is realization of a free operating system.
A strong case can be made that anyone who has used the GNU tools to put together a free operating system should pay homage to the GNU Project by adopting the GNU name for the operating system.
Now this does not mean that one has to do this, but it is a nice way to honour Richard Stallman's vision of free software. I encourage those who take position, but am not particularly upset if someone doesn't.
The GPL doesn't require it, though RMS may regret this.
2) Linux properly refers to the O/S/ kernel. Calling the entire operating system "Linux" is somewhat of a mis-nomer. Qualifying Linux by the name of the dustributor is still less than satisfactory. This will become more of a problem as the Hurd matures.
Now, personally I think that the only thing that should be called GNU/Linux, without any chance for argument, would be a "Linux" distribution released by the GNU Project, or released with their blessing. Debian GNU/Linux fits this bill.
Furthermore, if the GNU Project does not retain sufficient control over the GNU moniker, it may be used to describe operating systems that are not completely free. This would be a bad thing (and an insult to RMS).
That's the funny thing about virtual worlds: their bounderies are determined by design and not by physical constraints.
Wherever there is scarcity, there will be value placed on ownership, which leads to the development of fungible currency and laws to protect ownership.
As a Libertarian, I firmly believe that resources are best developed when there is a cost to owning them: it behooves the owner to exploit them to the best of his or her ability. There is no reason to believe that a virtual world will be any different.
However the thing about virtual worlds is that they can be designed with softer or non-existant resource limits, thus muting the need to "own" things. If you don't like a particular virtual world, design a different one.
It would be very interesting to see how three different virtual worlds evolve: two with limited resources, one of which forbids trading except in virtual terms, and one which doesn't; and a third where resources are essentially limitless.
The libertarian in me says that of the two worlds with limited resources, the one where non-virtual trade is permitted is likely to evolve faster than the other. Enforcement in the non-trading world can take the form of a "virtual tax" on virtual property levied by the game server owners and used to purchase virtual property which can then be sold by the game server owners ("the state") for real $$$. These real $$$ can then be used to investigate people who trade virtual property in the real world and ban them from the game.
I don't think that moderation should be stopped, but it does need some tweaking.
I too have seen some articles moderated down not because they were trolls, flamebait, or not informative, but because they were unpopular.
OTOH, I have seen articles moderated WAY up (like to +5) without justification (like some of mine). Now, it looked to me that the subject just happened to strike an emphatic response with the moderator, and not be of pulitzer writing quality.
I think that if an article is moderated up as well as down, then at least one of the modertators is judging content as opposed to writing quality and subject relevence. This should be investigated since that isn't what a moderator should do.
...But - would that mean if you were working on such an important project, would you need to be licensed to ensure quality?
No, though if the client did not seek to take care (either by checking the code quality himself, or relying on a reputable certification company), he might be setting himself up for a big negligence lawsuit.
Now, when I know that people's lives depend on the code I write, I make damn sure that if it is going to fail, it fails gracefully, or I don't release the code at all. IOW, I WILL NOT compromise quality in exchange for delivery time to satisfy an employer or client if I know lives might hang in the balance.
I just don't think that forcing that ethic on others is right, nor do I think that licensing ensures it anyway.
Er, I have worked on software where peoples lives depended on it not being buggy. It's one hell of a responsibility and about the only time you can justifiably tell a PHB to "fsck off, it isn't ready yet - or do you want people to die?"
If, in a free market, there is a demand for quality in software development, then surely organizations will arise that offer various certification programs.
Netware and Microsoft have been doing this for years.
So, certification would be inevitable: it's just a question of whether it matters to a particular customer.
Licensing, on the other hand is a beast of a different colour. Licensing means that you can't work without a license. This has no place in a free market, and is usually advocated by those that have a vested interest in controlling the size of the market: unions, doctors, and lawyers do this, with the necessary government 'help'.
The argument usually goes something like this: "With licensing, we can ensure the level of quality you're gonna get from someone in this profession". Of course, this is bogus, since all it guarantees is that a licensed programmer is, well, licensed. The enticement is that a potential employer or contractor does not have to evaluate skills for themselves. Who controls the licensing board, and what is in its best interest?
As with all things that depend on government force for enforcement, such a scheme is not likely to work well: good programmers that can't afford to pay the licensing fees won't get licensed, and bad programmers can lobby to keep good ones unlicensed. The production of free software might even be outlawed (much as practicing medicine without a license is).
With certification, the certifying board has to compete with other certifying boards and remove any possible question of inpropriety, lest it's reputation suffer.
Traditionally, certification has come from Universities (originally for philosophers and medical doctors), trade schools and apprentice programs, and more recently, equipment manufacturers (the guy who works on my car is "certified" by the auto maker to know what he's doing).
We have no need for licensing in this business.
Except it is "normal" (as in like most other people) to be born heterosexual. Therefore it is natural to question why someone is not "normal".
Of course, if they aren't harming you, why not leave them alone?