Posting that level of knowledge regarding an obscure fictional linguistic mythos should trigger some sort of Carnivore alarm which causes the NSA to arrest that guy before he starts shooting people from a clock tower.
Heh. And I'm not even a conlanger. You ain't seen obsessive.
(Honestly, I don't see how knowing facts about something "historical" or literary can qualify as obsessive. Old facts don't change, so they don't require constant pursuit to keep up one's knowledge. Following things which change, such as technology or fashion, requires a great deal more active engagement -- obsession, as you put it -- than knowing dead facts does.)
For a little bit more "obsessive" information on the Ring inscription and Dr. Tolkien's languages: Tolkien used over a dozen invented languages in his works, of which the most well-developed are the Elvish languages Quenya and Sindarin. Less developed were, for instance, the languages of the Rohirrim, the Adûnaic language of Nûmenor, and the Black Speech of Mordor (the language of the Ring inscription).
The Tengwar, the Elvish script used on the Ring, was Tolkien's attempt at a logical system of writing. The majority of the consonants fall into a simple arrangement which describes the relation of their sounds. For instance, the pairs of sounds ("T", "D"), ("P", "B"), and ("K", "G") all have similar relationships -- in each pair, the latter sound is merely the "voiced" form of the former. So, in the Tengwar, the symbols for these sounds are closely related. A few sounds, such as "L" and the rolled "R" do not fit the system, and have unrelated letterforms.
Historically, very few real-world alphabets have been based on the relationships of sounds. Most "natural" alphabets derive from ancient hieroglyphic or pictographic systems. The Latin letters A, B, C and the Hebrew aleph, beth, gimel both derive from Middle Eastern pictograms meaning "ox", "house", and "camel" -- hence Joyce's "Semper as oxhousehumper." Most "invented" alphabets are derivatives or composites of natural ones. For instance, Cyrillic (created by Sts. Cyril and Methodius and now used to write most of the Slavic languages) is a fusion of Latin, Greek, and Hebrew alphabets. Cherokee is worse. By comparison, Tolkien's alphabets are radically simple.
However, unlike Prof. Zamenhof (the creator of Esperanto), Tolkien did not intend or even imagine that his languages or scripts might be adopted by real-world populations. He invented them as an intellectual or linguistic game, and later as historical and cultural background to his stories. It is in that sense, not in the evangelical Esperantist's sense, that Tolkien fans pursue them.
The script on the ring was in Sindarin, one of the Elvish languages.
Actually, the script -- or "character set", as you put it, is the Tengwar. Tengwar and Cirth are the common character sets throughout Middle-Earth. Cirth (runes) is used for carving in stone or clay; Tengwar for writing with pen or brush and for ornamentation.
However, the Tengwar can be used in several different ways, or "modes". Each mode is a mapping of the sounds of a language onto the character set. Quenya uses one mapping; Sindarin another; and so forth. The most distinction between modes is whether they place vowel signs atop the consonant preceding or following the vowel sound. However, the consonant sounds attributed to the characters also vary. For instance, the character for "n" in one language may represent "ng" in another.
But this means that we must also reject Alan Cox's attempt to protest the DMCA by withholding discussion of security holes in Linux, under his false belief that the DMCA somehow forbids such discussion.
It is thoroughly possible that Alan's interpretation of the DMCA is wrong, and that yours is right. However, it is Alan and not you who is at risk if he is right. It is unseemly to chide him for refusing to take what he deems to be a serious legal risk, when you yourself are at no such risk.
I'm pretty sure that Alan's point is not that "discussion of bugs" in general is prohibited by the DMCA. It is that a bug in the permissions functions of a kernel could serve as a method of evading access controls -- and that dissemination of methods to evade access controls is prohibited.
Don't forget that Alan is not the only party at risk, either. Since he is employed by Red Hat in developing the kernel, Red Hat might also find itself liable. Indeed, Alan probably has the advice of Red Hat's lawyers in the matter. He isn't in a position to go against that.
Even if you are right and Alan is wrong, the matter serves as an able example of what the lawyers call a "chilling effect" upon speech. The DMCA is vague! The matter of whether Alan is at risk is unclear and contentious -- that's why we're having this discussion. In such an environment, people such as Alan and companies such as Red Hat are going to err on the side of excessive caution. Their speech will be "chilled", even if the risk is imaginary. That's part of why restraints upon speech are so dangerous.
It seems that Red Hat has quietly dropped support for the Compaq Alpha architecture. There are no ISOs or RPMs for Alpha on ftp.redhat.com, and Red Hat's online store still lists 7.1 as the latest system built for Alpha.
This is somewhat unfortunate for several of my scientist clients, some of whom prefer the Alpha's superior floating-point capabilities for their workstations. They aren't about to run out and drop $12,000 on an Itanium development box from Dell.
Of course, if Red Hat's actually dropped the Alpha, maybe I can get those users onto Debian....
Some readers may recall that when Microsoft announced Windows 95, Apple ran ads congratulating them on finally releasing something resembling a usable desktop, yet at the same time mocking the deceit which claimed that Windows 95 was not based on clunky old DOS:
C:\ONGRTLNS.W95
Similarly, perhaps a coalition of vendors -- Sun, IBM, Compaq, Apple and the gurus of the 64-bit Linux kernel ports -- should run a congratulatory ad for this momentous event: Microsoft finally goes 64-bit.
Just to clarify the headline: Intel is not "warning" people that using the VIA chipset is dangerous -- that it might harm their Pentium 4 processors -- but rather that they wish it were illegal. A quote from the article:
"They are not licensed to sell products that are compatible with the Pentium 4," Intel spokesman Chuck Mulloy said.
Mr. Malloy and his superiors apparently believe that they have "intellectual property" not only in their patents, but also in devices they may have never seen which interoperate with their patents. I believe that this idea was settled in Nintendo v. Galoob, the "Game Genie" case, in which Galoob's right to create a device that interoperated with the NES game console (and which modified the behavior of the latter, no less!) was upheld.
Microsoft fixed the problem before there was a problem. I don't see how Open Source would be any better in this regard.
When my favorite open-source project discovers a security hole, it releases the patch in such a way that you can install it with a single command. Microsoft has an equivalent to this -- it's the "Critical Updates" section of the "Windows Update" facility. They frequently put important security and bug-fix patches in this section, so that Windows users can easily access them. This also makes it easy for site IT staff to encourage users to keep their systems up to date.
The default.ida patch, a fix for a root-level compromise, was not placed in Critical Updates. Without either searching the site or being told of the correct URL to download the patch, users could not find it. People who used Windows Update religiously in the expectation of keeping their systems up to date were screwed. Sites which instructed their users that setting Windows Update to perform automatic updates would help keep them secure were screwed.
Once again, Microsoft created an expectation and failed to live up to it.
A system, method, and computer program product for delivery and automatic execution of security, management, or optimization software over an Internet connection to a user computer responsive to a user request entered via a web browser on the user computer.
Depending on how a "Web browser" is defined, Debian's dselect may qualify as a "Web browser" (an interactive program that accesses files via HTTP) which allows the delivery and automatic execution of security, management, and optimization software. It can also install software for "database management, word processing, spread sheet, games, or other tasks".
If you already know Perl fairly well, you shouldn't have too much trouble learning Perl 6. Besides, how can you expect to just learn just one programming and language and end there? The nature of this profession is that you are constantly learning new things.
Already knowing Perl 4/5, Scheme, C, shell, AppleScript, and C-64 BASIC "fairly well", I don't imagine I would have all that much trouble picking up Python, OCaml, Ruby, Emacs LISP, or Fortran 90, either. I might have some trouble with Intercal, Befunge, or Object COBOL, though. *chuckle* My point is that by gratuitously abandoning large swaths of Perl 5 syntax, Perl 6 would thereby abandon Perl users' existing Perl expertise. That makes it less attractive, not more, to Perl users who are already considering taking up another language.
It seems to me that people don't like being abandoned -- or, more precisely, won't like hitting themselves on the forehead every once in a while and saying "D'oh! Can't do that in this new Perl!"
Also, Perl is in need of some major changes ie the OO portion of it. I really like Perl, but the current OO implementation feels more like a hack than anything. Not near as elegant as say Python's OO feature.
That's for sure. I've been taking a close look at Python the past week or two, and it seems to handle object-orientation (and libraries in general) rather more pleasantly than Perl 5 does. I've still got some reservations regarding its string and regexp operations, but I'm seriously considering doing my next few minor projects in Python.
(Pythoneers: My chief reservations have to do with immutable strings; and with the greater number of hoops one must jump through to use a regexp, as compared with Perl's =~ operator. It also strikes me as weird that a deliberately "clean" language overloads the % operator to implement what everyone else calls sprintf(). Oh, and while I'm gritching, how about a lambda operator without the limitations?)
I would really hate to see Python overtake Perl as the interpreted language of choice; therefore, I support any changes that need to be done.
See, I don't really understand that sentiment. Why is the popularity of Python (or Ruby, or OCaml, or Emacs LISP) something to fear or "hate to see"? If the development of Perl goes a way I don't think is conducive to my use, then of course I'm going to find new tools. If you like Perl 6, by all means use it; I'm just saying that the weirder it is compared to Perl 5, the fewer folks will go along for the ride.
I've been using Perl for about six years now, mostly for system-administration tasks and CGI. In reading the various documents pertaining to Perl 6 -- the RFCs, the Apocalypses, and now this -- I'm starting to worry that a great deal of what I've learned in Perl 4 and 5 will not be useful in Perl 6.
By making that big a move, it seems to me that Perl risks losing a lot of users. Existing users' Perl-fu represents an investment of effort in learning the language, and the more of this investment that Perl 6 invalidates, the less affinity they'll retain for Perl. Perl isn't the only fast, flexible interpreted language out there any more -- Python's been around for a while, and Ruby just might take off one of these years.
If I'll have to learn a whole 'nother language either way, why learn Perl 6 rather than Python?
It is in a for-profit organisation's interest to create Open Source software
That depends on the organization. It would probably not be in Microsoft's immediate interest to release Office 2000 as open source software, because Microsoft depends on monopoly revenues to survive.
On the other hand, it is clearly in Red Hat's interest to continue to contribute to the development of the Linux kernel, because anything that improves Linux as a platform is likely to increase Red Hat's consulting revenue. (Red Hat's chief competition isn't other Linux consulting firms anyway -- it's Microsoft and its servitor firms.)
It is in a for-profit organisation's interest to use Open Source software
Frequently, yes. IS/IT is a cost center, and anything that can minimize its cost to a business is in that business's interest. Insofar as open-source software can do so -- for instance, by avoiding lock-in and monopoly-priced license and service fees; guaranteeing platform stability; and increasing reliability -- it is in a business's interest to use it.
Closed-source software frequently invites the manufacturer to attempt to lock in customers and impose monopoly pricing. In many cases, closed-source vendors alter the platform out from under their customers' feet in order to spur upgrade revenues. (Take Microsoft Office, for instance.) These costs can be avoided with open-source software.
There are certainly particular business needs for which there does not (yet) exist open source software. There are also businesses with such large investments in closed software that it would not (at the moment) be in their interest to migrate.
It is not in a for-profit organisation's interest to create Open Source software, but it is in the public interest
Certainly there exist cases where particular for-profit organizations have offered closed software for which public, collaborative efforts have created open alternatives. However, if the claim being made is that for-profit organizations should be required to create open-source software so as to serve the public interest, I disagree. This would be an infringement upon their property rights.
It is not in anyone's interest to create Open Source software
I doubt anyone would assert that to begin with....
No offense, but isn't that true? Hasn't the idea that open source generates major profit potential been pretty well refuted by the bursting of last year's Linux bubble and the collapse of companies like Eazel and VA Linux? Was there ever a quantitative business model as opposed to a religious manifesto behind any of those claims? Hasn't the idea of making money by giving away software and charging for services failed for almost every company that's tried it?
Yes, the loss-leader business model has some serious risks involved. What does that have to do with open source?
Open source software is not a business model; it's a development model. It's a way to get software that you want or need -- by collaborating with others in developing that software. Open source's success or failure is not predicted or represented by Red Hat's success or Eazel's failure, but by the ability of open-source participants to get and to build the software they need and want.
Is there any open-source software you use? Does it do what you need it to? Is it in active development? Well then, the open-source model has succeeded in producing value for you. Some notable ways in which open source has succeeded for me include the Postfix mail server, the Konqueror browser, and the mutt email client. These are successes not because anyone is or isn't making money on them, but because they are good and useful software, valuable to their users.
It is true that a few companies built around a loss-leader business model have used open-source software as their loss leader, and have failed to recoup their losses and thus gone out of business. However, this is a consequence of the risks of a loss-leader business, and of the drying-up of capital for risky high-tech ventures. Hardware loss-leaders -- the:CueCat and the iOpener come to mind -- have also tended to fail recently. Yet nobody suspects that a "hardware business model" is to blame, and that non-loss-leader hardware companies such as Dell or AMD are threatened.
Moreover, it is interesting to note that when a loss-leader open-source company disappears, the value (if any) of its open-source software tends to be preserved: take Nautilus, for example, which is still being developed after the demise of Eazel. The open-source development model has as one of its strengths that it is not vulnerable to the failure of anyone's business model.
I can buy dual boot Solaris/Linux boxes, or dual-boot Be/Redhat boxes, or other combinations thereof.
The last time I checked, none of the first-tier PC OEMs offered dual-boot Windows/Linux systems. I'm talking about companies like Dell, Compaq, and IBM -- not Joe's PC Clone Shop & Bait Store. The article refers to OEM licensing, which makes Microsoft software available at a deep discount to the majors in exchange for arrangements such as exclusivity and advertising.
The availability of dual-boot and other customized systems is not an issue. Microsoft can't stop clone shops from doing customization. However, clone shops can't offer Dell's or IBM's level of support, either; many purchasers require that level of support before they will consider a system.
Actually, through the use of
Loadlin or a similar mechanism, this seems to give OEM licensees the right to sell dual-boot systems of a sort. Currently, one can buy Windows systems and GNU/Linux systems from OEMs such as Dell, but not dual-boots. This may offer an out. Many of the folks I work with would quite like to be able to get first-tier vendor support for dual-boot systems.
(Yah, following-up to one's own posts is perverted....)
The iCab folks keep a list of "10 features you don't find in other browsers", which would make an excellent checklist for other alternative browsers looking to add user-empowering features. Besides its abuse-blocking abilities, other iCab features that stand out include its built-in HTML validator; its recursive download manager (something like a GUIfied wget); and its "Link Manager", which summarizes all the links on a page and is quite useful when using any of the spammier search engines.
Of all the Web browsers I've seen, the experimental Macintosh browser iCab seems to have the most features for restricting pop-ups and other abusive JavaScript[?].
iCab permits one to enable or disable several different JavaScript/ECMAscript functions (as well as other "features") on a per-site basis. It also offers excellent image filtering -- to the point that I don't feel the need to use my Junkbuster proxy when I'm using iCab.
Sadly, the iCab folks have said they're not interested in porting to GNU/Linux. Among the GNU/Linux browsers, my favorite by far is Konqueror. Like iCab on the Macintosh, Konq is small, fast, and customizable. However, it still lags a bit behind in the way of filtering. Site-specific, function-specific JavaScript filtering would be an excellent addition to what's already easily the best browser in the Free world.
The way the license[gpl] is written, if you use any open-source software, you have to make the rest of your software open source
That's pretty much what Mundie said. Seems that that's the Company Line. And I think RMS, O'Reilly, et. al. addressed that pretty well.
Let's see...
Craig Mundie has made a false statement. GPL does not require you to "make the rest of your software open source"; only software that is derived from copyrighted, GPLed software.
Craig Mundie knows it's a false statement. He has responded to refutations of his statements; therefore, he has read said refutations, and knows that he's wrong.
Craig Mundie is making this false statement maliciously. He's doing it in order to hurt his open-source and free-software competitors.
I believe the lawyers have a word for what happens when someone knowingly makes a maliciously false statement in print. I believe that word is libel.
Hence, you might be asking for legal problems if you have a developer contributes to GPL code at home, and writes closed source during the day, since he might have taken derived ideas to the work code.
I'm pretty sure the sorts of lawsuits you're probably thinking of -- suits filed by one company against another which has hired away some of the former's programmers or engineers -- are rarely over copyright, which is what the GPL covers. They're over trade secrets. If they were over copyright, they would be easily settled: see if there is substantial code in common; if not, no problem. As for trade secrets, a project that releases its code to the public under the GPL cannot be said to hold any trade secrets. Thus, I'm not sure the threat you're discussing actually exists.
Furthermore, it is interesting to note, as you do, that "GPL hasn't been tested in court." Isn't that just another way of saying that nobody has ever been sued over GPLed code? Considering that the GPL has been around since 1984, that's some sort of track record. How many closed-source software companies are there which have been around for sixteen years and have never sued or been sued?
Hmm. The GPL requires that derived works of a licensed work must also be released under the GPL. It does not require that unrelated work written by GPL software users be released.
Is this viral? It seems to me that if we're looking for biological metaphors, it would be more accurate to call it hereditary or heritable. GPLed code doesn't go out and infect your work. Rather, if you choose to "breed" new software from GPLed code, that software inherits the licensing traits of its parent.
Re: Mailing list subscription confirmation
on
RFC for Spammers
·
· Score: 3
FWIW, I emailed my concerns (as described in the above comment) to Ted Gavin, the principal author of RFC 3098. His response was that he and the other authors are in the process of amending this RFC to bring it into closer alignment with the MAPS guidelines and with RFC 2635. (The latter is an earlier RFC discussing mailing lists and spam.
Just goes to show -- people do listen.
Mailing list subscription confirmation
on
RFC for Spammers
·
· Score: 5
RFC3098 describes a procedure for "confirming" mailing list subscriptions which does not in fact require confirmation of subscriptions, and thus leaves open a wide avenue for abuse.
The RFC gives an example of a "confirmation message" which informs the recipient that s/he has been subscribed to a mailing list, and gives instructions for unsubscribing. This is not what modern mailing-list management packages (such as GNU Mailman or ezmlm/idx mean by a "confirmation message". These packages require that a user confirm by email that s/he wants to be on the list before adding the user to the list proper. The RFC allows that the user be subscribed first, and have to take action in order to unsubscribe.
The problem should be obvious: If you have to take action to unsubscribe from a list you never asked to be on, then your mailbox can still be flooded with list email before you have a chance to get off the list. You can be subscribed without your consent by a hostile party who wants to mailbomb you. (This is more common on badly-managed mailing lists than you might think.)
Spammers today already send out (fraudulent) "how to unsubscribe" messages, whereas well-managed mailing lists require active confirmation. An RFC on how to avoid being, or looking like, a spammer should recommend that one follow the methods of the best-managed legitimate mailing lists, not those of the spammers.
It's been said many times before, but here goes...
When your telemarketer calls me, you pay the long-distance fees.
When you send me bulk postal mail, you pay for the printing and the postage. (Indeed, bulk postal mail ends up subsidizing non-bulk mail, since it comes pre-sorted and thus costs the Postal Service much less.)
When you send a messenger around town who hangs a leaflet on my doorknob, you pay for the printing and the messenger.
When you send me spam email, I pay. I pay in ISP fees, which go to defray the costs of bandwidth consumed and disk space taken up. When you spam my work account, my employer pays. When you spam a public university or government account, the taxpayer pays.
You have every right to put your message out to the world at your own expense. You have no right to put it out at my expense, my employer's expense, or the taxpayer's expense. Spam is theft -- or, more accurately, spam is piecewise mailbombing; and mailbombing is a computer crime.
The GPL grants you certain rights in return for you giving up certain rights.
Specifically you can copy, modify, and distribute the code. But if you do happen to modify it you are forced to release the source to your changes.
Sorry, but that is not accurate -- you should consider reading the GPL itself again. The powers of the GPL stem from the software author's holding of copyright over the software. The author grants you the right to copy and distribute under certain circumstances -- and not under other circumstances. You give up nothing. The GPL's restrictions on copying do not limit any right to copy you had before the author GPLed the software: because, at that time, you did not have any right to copy the software. Can't restrict what ain't there!
To address some specific problems:
The GPL does not require you to release anything, ever. You may modify GPL-covered source code to your heart's content for your own personal (or, arguably, in-house) use and never even tell anyone. Since you aren't distributing the software, the author's copyright has no hold over you. As a parallel: Writing in the margin of a book -- or tearing out the ending and replacing it with a version you like better -- cannot be restricted by the book's author's copyright. Copying and distributing your modified version -- or the author's version, intact -- requires the author's permission.
What the GPL does say is that if you do distribute the covered software (or modified versions), then you must distribute the source under the GPL. Again, this is not a restriction of your rights; it is a delineation of the permission to copy, which the author has granted you. The author has not granted you permission to distribute his/her software under your own terms; to do so would violate not some contract, but rather the author's copyright.
Consider: If you walk on my lawn without my permission, that's trespassing. If I permit you to walk on the north side, but not the south side, that grants you rights you didn't have; you don't give up any rights. The provision that you may not walk on the south is not something that you "give up" in order to obtain my permission to walk on the north; it's just the limit of the permission which I grant you.
The GPL does not speak to your "right to use" the software. Term zero of the GPL states that "[a]ctivities other than copying, distribution and modification are not covered by this License; they are outside its scope." The GPL neither grants a "right to use" nor limits a "right to use"; it doesn't deal with such a right at all.
If you believe that you need the author to grant you a "right to use" his/her software, in addition to the fact of your having legally obtained a copy, then it seems to me that you must therefore conclude that you don't have a "right to use" any GPLed software! (Unless, of course, the authors have specifically granted you a "right to use" in addition to the GPL-granted rights to distribute and modify.)
Those shrink-wrapped licenses stand on the same legal ground as the GPL!
Actually, that's not quite the case. Shrink-wrap "license agreements" are constructs of contract law, whereas the GPL is a grant of limited rights under copyright law.
EULAs and the like are framed as contracts: you give up certain rights (such as the right to publicly criticize the software) in exchange for the "right to use" the software. The fact that you already had the right to use it, since you legally bought a copy, sets them on shaky ground under common law. (After all, you have the right to use what you've bought, whether or not you have the right to copy it!) That's what UCITA and its ilk give to Microsoft and its ilk -- the right to restrict use of legally purchased software.
The GPL, on the other hand, is not a contract: it does not ask you to give away any rights, or anything else for that matter. All it does is grant you new rights you did not formerly have -- specifically, the right to copy, modify, and distribute the software under certain circumstances.
You may perceive the GPL's restrictions as limits placed upon your rights -- but they aren't. Outside of a grant of rights by the author (of which the GPL is only one example) you never had the right to copy that software. The GPL grants you a limited right; unlike EULAs, it doesn't ask you to waive any rights you already had.
(In addition, the GPL does not grant a "right to use" the covered software, since it takes it as read that you already have that right by virtue of having legally obtained a copy of the software. The GPL explicitly states that it does not deal with "rights to use".)
Contrary to the article's implications, ECN is not enabled by default in the 2.4.x kernels as Linus shipped them. In order to enable ECN, you must reconfigure and recompile the kernel. The configuration documentation for the ECN option explicitly states that turning it on will cause some routers and firewalls to drop your connections, and suggests that you leave it off unless you know you need ECN.
If you find ECN enabled in your distributor's 2.4.x kernel package by default, please consider this a severe mistake on your distributor's part. Please do not consider it a bug in "the 2.4.x kernel". The author of the Enterprise Linux Today article owes Linus and the kernel developers a retraction and correction.
Slashdot Mirror
Heh. And I'm not even a conlanger. You ain't seen obsessive.
(Honestly, I don't see how knowing facts about something "historical" or literary can qualify as obsessive. Old facts don't change, so they don't require constant pursuit to keep up one's knowledge. Following things which change, such as technology or fashion, requires a great deal more active engagement -- obsession, as you put it -- than knowing dead facts does.)
For a little bit more "obsessive" information on the Ring inscription and Dr. Tolkien's languages: Tolkien used over a dozen invented languages in his works, of which the most well-developed are the Elvish languages Quenya and Sindarin. Less developed were, for instance, the languages of the Rohirrim, the Adûnaic language of Nûmenor, and the Black Speech of Mordor (the language of the Ring inscription).
The Tengwar, the Elvish script used on the Ring, was Tolkien's attempt at a logical system of writing. The majority of the consonants fall into a simple arrangement which describes the relation of their sounds. For instance, the pairs of sounds ("T", "D"), ("P", "B"), and ("K", "G") all have similar relationships -- in each pair, the latter sound is merely the "voiced" form of the former. So, in the Tengwar, the symbols for these sounds are closely related. A few sounds, such as "L" and the rolled "R" do not fit the system, and have unrelated letterforms.
Historically, very few real-world alphabets have been based on the relationships of sounds. Most "natural" alphabets derive from ancient hieroglyphic or pictographic systems. The Latin letters A, B, C and the Hebrew aleph, beth, gimel both derive from Middle Eastern pictograms meaning "ox", "house", and "camel" -- hence Joyce's "Semper as oxhousehumper." Most "invented" alphabets are derivatives or composites of natural ones. For instance, Cyrillic (created by Sts. Cyril and Methodius and now used to write most of the Slavic languages) is a fusion of Latin, Greek, and Hebrew alphabets. Cherokee is worse. By comparison, Tolkien's alphabets are radically simple.
However, unlike Prof. Zamenhof (the creator of Esperanto), Tolkien did not intend or even imagine that his languages or scripts might be adopted by real-world populations. He invented them as an intellectual or linguistic game, and later as historical and cultural background to his stories. It is in that sense, not in the evangelical Esperantist's sense, that Tolkien fans pursue them.
Actually, the script -- or "character set", as you put it, is the Tengwar. Tengwar and Cirth are the common character sets throughout Middle-Earth. Cirth (runes) is used for carving in stone or clay; Tengwar for writing with pen or brush and for ornamentation.
However, the Tengwar can be used in several different ways, or "modes". Each mode is a mapping of the sounds of a language onto the character set. Quenya uses one mapping; Sindarin another; and so forth. The most distinction between modes is whether they place vowel signs atop the consonant preceding or following the vowel sound. However, the consonant sounds attributed to the characters also vary. For instance, the character for "n" in one language may represent "ng" in another.
It is thoroughly possible that Alan's interpretation of the DMCA is wrong, and that yours is right. However, it is Alan and not you who is at risk if he is right. It is unseemly to chide him for refusing to take what he deems to be a serious legal risk, when you yourself are at no such risk.
I'm pretty sure that Alan's point is not that "discussion of bugs" in general is prohibited by the DMCA. It is that a bug in the permissions functions of a kernel could serve as a method of evading access controls -- and that dissemination of methods to evade access controls is prohibited.
Don't forget that Alan is not the only party at risk, either. Since he is employed by Red Hat in developing the kernel, Red Hat might also find itself liable. Indeed, Alan probably has the advice of Red Hat's lawyers in the matter. He isn't in a position to go against that.
Even if you are right and Alan is wrong, the matter serves as an able example of what the lawyers call a "chilling effect" upon speech. The DMCA is vague! The matter of whether Alan is at risk is unclear and contentious -- that's why we're having this discussion. In such an environment, people such as Alan and companies such as Red Hat are going to err on the side of excessive caution. Their speech will be "chilled", even if the risk is imaginary. That's part of why restraints upon speech are so dangerous.
This is somewhat unfortunate for several of my scientist clients, some of whom prefer the Alpha's superior floating-point capabilities for their workstations. They aren't about to run out and drop $12,000 on an Itanium development box from Dell.
Of course, if Red Hat's actually dropped the Alpha, maybe I can get those users onto Debian ....
C:\ONGRTLNS.W95
Similarly, perhaps a coalition of vendors -- Sun, IBM, Compaq, Apple and the gurus of the 64-bit Linux kernel ports -- should run a congratulatory ad for this momentous event: Microsoft finally goes 64-bit.
Just to clarify the headline: Intel is not "warning" people that using the VIA chipset is dangerous -- that it might harm their Pentium 4 processors -- but rather that they wish it were illegal. A quote from the article:
Mr. Malloy and his superiors apparently believe that they have "intellectual property" not only in their patents, but also in devices they may have never seen which interoperate with their patents. I believe that this idea was settled in Nintendo v. Galoob, the "Game Genie" case, in which Galoob's right to create a device that interoperated with the NES game console (and which modified the behavior of the latter, no less!) was upheld.
The default.ida patch, a fix for a root-level compromise, was not placed in Critical Updates. Without either searching the site or being told of the correct URL to download the patch, users could not find it. People who used Windows Update religiously in the expectation of keeping their systems up to date were screwed. Sites which instructed their users that setting Windows Update to perform automatic updates would help keep them secure were screwed.
Once again, Microsoft created an expectation and failed to live up to it.
Depending on how a "Web browser" is defined, Debian's dselect may qualify as a "Web browser" (an interactive program that accesses files via HTTP) which allows the delivery and automatic execution of security, management, and optimization software. It can also install software for "database management, word processing, spread sheet, games, or other tasks".
Already knowing Perl 4/5, Scheme, C, shell, AppleScript, and C-64 BASIC "fairly well", I don't imagine I would have all that much trouble picking up Python, OCaml, Ruby, Emacs LISP, or Fortran 90, either. I might have some trouble with Intercal, Befunge, or Object COBOL, though. *chuckle* My point is that by gratuitously abandoning large swaths of Perl 5 syntax, Perl 6 would thereby abandon Perl users' existing Perl expertise. That makes it less attractive, not more, to Perl users who are already considering taking up another language.
It seems to me that people don't like being abandoned -- or, more precisely, won't like hitting themselves on the forehead every once in a while and saying "D'oh! Can't do that in this new Perl!"
That's for sure. I've been taking a close look at Python the past week or two, and it seems to handle object-orientation (and libraries in general) rather more pleasantly than Perl 5 does. I've still got some reservations regarding its string and regexp operations, but I'm seriously considering doing my next few minor projects in Python.
(Pythoneers: My chief reservations have to do with immutable strings; and with the greater number of hoops one must jump through to use a regexp, as compared with Perl's =~ operator. It also strikes me as weird that a deliberately "clean" language overloads the % operator to implement what everyone else calls sprintf(). Oh, and while I'm gritching, how about a lambda operator without the limitations?)
See, I don't really understand that sentiment. Why is the popularity of Python (or Ruby, or OCaml, or Emacs LISP) something to fear or "hate to see"? If the development of Perl goes a way I don't think is conducive to my use, then of course I'm going to find new tools. If you like Perl 6, by all means use it; I'm just saying that the weirder it is compared to Perl 5, the fewer folks will go along for the ride.
By making that big a move, it seems to me that Perl risks losing a lot of users. Existing users' Perl-fu represents an investment of effort in learning the language, and the more of this investment that Perl 6 invalidates, the less affinity they'll retain for Perl. Perl isn't the only fast, flexible interpreted language out there any more -- Python's been around for a while, and Ruby just might take off one of these years.
If I'll have to learn a whole 'nother language either way, why learn Perl 6 rather than Python?
That depends on the organization. It would probably not be in Microsoft's immediate interest to release Office 2000 as open source software, because Microsoft depends on monopoly revenues to survive.
On the other hand, it is clearly in Red Hat's interest to continue to contribute to the development of the Linux kernel, because anything that improves Linux as a platform is likely to increase Red Hat's consulting revenue. (Red Hat's chief competition isn't other Linux consulting firms anyway -- it's Microsoft and its servitor firms.)
Frequently, yes. IS/IT is a cost center, and anything that can minimize its cost to a business is in that business's interest. Insofar as open-source software can do so -- for instance, by avoiding lock-in and monopoly-priced license and service fees; guaranteeing platform stability; and increasing reliability -- it is in a business's interest to use it.
Closed-source software frequently invites the manufacturer to attempt to lock in customers and impose monopoly pricing. In many cases, closed-source vendors alter the platform out from under their customers' feet in order to spur upgrade revenues. (Take Microsoft Office, for instance.) These costs can be avoided with open-source software.
There are certainly particular business needs for which there does not (yet) exist open source software. There are also businesses with such large investments in closed software that it would not (at the moment) be in their interest to migrate.
Certainly there exist cases where particular for-profit organizations have offered closed software for which public, collaborative efforts have created open alternatives. However, if the claim being made is that for-profit organizations should be required to create open-source software so as to serve the public interest, I disagree. This would be an infringement upon their property rights.
I doubt anyone would assert that to begin with ....
Yes, the loss-leader business model has some serious risks involved. What does that have to do with open source?
Open source software is not a business model; it's a development model. It's a way to get software that you want or need -- by collaborating with others in developing that software. Open source's success or failure is not predicted or represented by Red Hat's success or Eazel's failure, but by the ability of open-source participants to get and to build the software they need and want.
Is there any open-source software you use? Does it do what you need it to? Is it in active development? Well then, the open-source model has succeeded in producing value for you. Some notable ways in which open source has succeeded for me include the Postfix mail server, the Konqueror browser, and the mutt email client. These are successes not because anyone is or isn't making money on them, but because they are good and useful software, valuable to their users.
It is true that a few companies built around a loss-leader business model have used open-source software as their loss leader, and have failed to recoup their losses and thus gone out of business. However, this is a consequence of the risks of a loss-leader business, and of the drying-up of capital for risky high-tech ventures. Hardware loss-leaders -- the :CueCat and the iOpener come to mind -- have also tended to fail recently. Yet nobody suspects that a "hardware business model" is to blame, and that non-loss-leader hardware companies such as Dell or AMD are threatened.
Moreover, it is interesting to note that when a loss-leader open-source company disappears, the value (if any) of its open-source software tends to be preserved: take Nautilus, for example, which is still being developed after the demise of Eazel. The open-source development model has as one of its strengths that it is not vulnerable to the failure of anyone's business model.
The last time I checked, none of the first-tier PC OEMs offered dual-boot Windows/Linux systems. I'm talking about companies like Dell, Compaq, and IBM -- not Joe's PC Clone Shop & Bait Store. The article refers to OEM licensing, which makes Microsoft software available at a deep discount to the majors in exchange for arrangements such as exclusivity and advertising.
The availability of dual-boot and other customized systems is not an issue. Microsoft can't stop clone shops from doing customization. However, clone shops can't offer Dell's or IBM's level of support, either; many purchasers require that level of support before they will consider a system.
How about it, Mr. Dell?
The iCab folks keep a list of "10 features you don't find in other browsers", which would make an excellent checklist for other alternative browsers looking to add user-empowering features. Besides its abuse-blocking abilities, other iCab features that stand out include its built-in HTML validator; its recursive download manager (something like a GUIfied wget); and its "Link Manager", which summarizes all the links on a page and is quite useful when using any of the spammier search engines.
Sadly, the iCab folks have said they're not interested in porting to GNU/Linux. Among the GNU/Linux browsers, my favorite by far is Konqueror. Like iCab on the Macintosh, Konq is small, fast, and customizable. However, it still lags a bit behind in the way of filtering. Site-specific, function-specific JavaScript filtering would be an excellent addition to what's already easily the best browser in the Free world.
Let's see ...
I believe the lawyers have a word for what happens when someone knowingly makes a maliciously false statement in print. I believe that word is libel.
Furthermore, it is interesting to note, as you do, that "GPL hasn't been tested in court." Isn't that just another way of saying that nobody has ever been sued over GPLed code? Considering that the GPL has been around since 1984, that's some sort of track record. How many closed-source software companies are there which have been around for sixteen years and have never sued or been sued?
Is this viral? It seems to me that if we're looking for biological metaphors, it would be more accurate to call it hereditary or heritable. GPLed code doesn't go out and infect your work. Rather, if you choose to "breed" new software from GPLed code, that software inherits the licensing traits of its parent.
Just goes to show -- people do listen.
The RFC gives an example of a "confirmation message" which informs the recipient that s/he has been subscribed to a mailing list, and gives instructions for unsubscribing. This is not what modern mailing-list management packages (such as GNU Mailman or ezmlm/idx mean by a "confirmation message". These packages require that a user confirm by email that s/he wants to be on the list before adding the user to the list proper. The RFC allows that the user be subscribed first, and have to take action in order to unsubscribe.
The problem should be obvious: If you have to take action to unsubscribe from a list you never asked to be on, then your mailbox can still be flooded with list email before you have a chance to get off the list. You can be subscribed without your consent by a hostile party who wants to mailbomb you. (This is more common on badly-managed mailing lists than you might think.)
Spammers today already send out (fraudulent) "how to unsubscribe" messages, whereas well-managed mailing lists require active confirmation. An RFC on how to avoid being, or looking like, a spammer should recommend that one follow the methods of the best-managed legitimate mailing lists, not those of the spammers.
I would suggest that anyone interested in responsible mailing-list operation check out the MAPS Basic Mailing List Management Principles for Preventing Abuse. A mailing list which follows these rules will be much more resistant to abuse than one which strictly follows RFC3098. Moreover, a list which strictly follows RFC3098 and which is abused will qualify its site for the MAPS RBL.
When your telemarketer calls me, you pay the long-distance fees.
When you send me bulk postal mail, you pay for the printing and the postage. (Indeed, bulk postal mail ends up subsidizing non-bulk mail, since it comes pre-sorted and thus costs the Postal Service much less.)
When you send a messenger around town who hangs a leaflet on my doorknob, you pay for the printing and the messenger.
When you send me spam email, I pay. I pay in ISP fees, which go to defray the costs of bandwidth consumed and disk space taken up. When you spam my work account, my employer pays. When you spam a public university or government account, the taxpayer pays.
You have every right to put your message out to the world at your own expense. You have no right to put it out at my expense, my employer's expense, or the taxpayer's expense. Spam is theft -- or, more accurately, spam is piecewise mailbombing; and mailbombing is a computer crime.
To address some specific problems:
Consider: If you walk on my lawn without my permission, that's trespassing. If I permit you to walk on the north side, but not the south side, that grants you rights you didn't have; you don't give up any rights. The provision that you may not walk on the south is not something that you "give up" in order to obtain my permission to walk on the north; it's just the limit of the permission which I grant you.
If you believe that you need the author to grant you a "right to use" his/her software, in addition to the fact of your having legally obtained a copy, then it seems to me that you must therefore conclude that you don't have a "right to use" any GPLed software! (Unless, of course, the authors have specifically granted you a "right to use" in addition to the GPL-granted rights to distribute and modify.)
EULAs and the like are framed as contracts: you give up certain rights (such as the right to publicly criticize the software) in exchange for the "right to use" the software. The fact that you already had the right to use it, since you legally bought a copy, sets them on shaky ground under common law. (After all, you have the right to use what you've bought, whether or not you have the right to copy it!) That's what UCITA and its ilk give to Microsoft and its ilk -- the right to restrict use of legally purchased software.
The GPL, on the other hand, is not a contract: it does not ask you to give away any rights, or anything else for that matter. All it does is grant you new rights you did not formerly have -- specifically, the right to copy, modify, and distribute the software under certain circumstances.
You may perceive the GPL's restrictions as limits placed upon your rights -- but they aren't. Outside of a grant of rights by the author (of which the GPL is only one example) you never had the right to copy that software. The GPL grants you a limited right; unlike EULAs, it doesn't ask you to waive any rights you already had.
(In addition, the GPL does not grant a "right to use" the covered software, since it takes it as read that you already have that right by virtue of having legally obtained a copy of the software. The GPL explicitly states that it does not deal with "rights to use".)
If you find ECN enabled in your distributor's 2.4.x kernel package by default, please consider this a severe mistake on your distributor's part. Please do not consider it a bug in "the 2.4.x kernel". The author of the Enterprise Linux Today article owes Linus and the kernel developers a retraction and correction.