The idea of having mail stored on the sender's system rather than the recipient's is important.
Another thing I'd really like to see is a mechanism for MTAs and MUAs (and their users) to negotiate policy agreemeents for the content that they carry. It would work a little bit like content negotiation on the web. For instance, if I'm sending a piece of personal non-anonymous noncommercial email to a single individual I already know, that message would meet a very large number of policy agreements. (Some of them might be agreements I or the recipient had written, but most of them would be standard agreements written by third parties.) So my mail software could present the recipient's mail software with (at least) four pieces of information: sender, recipient, the location (on my server) of the message, and a list of the locations of a bunch of the agreements that I promise the message is certified to meet, probably with checksums so it can be proved that I'm talking about the same set of agreements the recipient is reading.
The recipient's software (and the distinction between MTA and MUA might be fuzzier than it is now) would similarly have a list of policy agreements that it was configured to accept. If any of the list of policy agreements the recipient was willing to accept matched any of the list of policy agreements the sender certified the message against, the message would be "accepted" -- presented to the recipient by the MUA. Presumably the recipient would have a choice of copying the message to local storage or leaving it on the sender's server (where it might expire if the sender decided not to keep hosting it, although some policy agreements might promise to keep messages for a certain amount of time). If none of the policy agreements intersected, the message would not be presented to the user (and probably the sender would be so informed).
This mechanism would allow recipients to choose what kind of mail they accept, and therefore it would not (in and of itself) prevent important things like anonymous mail, or mail sent from unreplyable addresses, or mailing lists, or mail from unknown persons. It would just be a mechanism for recipients to say what kind of mail they're willing to accept, and senders to describe (in the form of an agreement or "contract") the characteristics of their mail. And that needn't be limited to just spam prevention -- if I don't want any mail longer than 40k, or I don't want any mail with images or animation, or I don't want any mail with more quoted text than original text, I can express that.
Now, that's still infrastructure that depends on some degree of honesty on the part of the sender, so it's not a complete solution by itself. The people who forge mail headers so their spam appears to come from real (innocent) people wouldn't be deterred by this; they'd just lie as they do now. But a large amount of spam is ultimately traceable if the victim cares enough, and those spam senders probably would just let their spam fall into the bit-bucket. It would actually make spam *cheaper* for them, because they weren't transmitting as much data (the meta-information for everybody, but the message itself only to people who choose to read it), and that might give them less incentive to force their spam on people who didn't want to read it. And as a recipient, I might choose only to accept mail that certifies compliance with policy agreements that have enforcement clauses ("...and if this message shall not originate from the Authenticated Sender, Actual Sender shall be liable for damages of..."), and then anybody who successfully sends me spam had to agree to that contract and is liable for breaking it, if I can track them down. The fact that lots of spam actually does get sent out with "ADV:" or the Korean or Chinese equivalent in the subject line suggests that at least a noticeable fraction of spammers would just not list agreements fraudulently and live with the smaller market.
I wrote an invitation in PostScript once that drew a random starfield and receding text along the lines of the StarWars intro. It was done in a completely stupid, brute-force way. It took at least a couple minutes to render on a NeXT. My hapless co-worker printed it on a LaserWriter II, and it took half an hour to print.
PostScript is a full-fledged programming language, so it can be arbitrarily slow if you want it to.:-)
Germans no longer use Fraktur (the blackletter-ish form of the Roman alphabet that was used up until the end of WWII, when it was abandoned because the Nazis had been fond of it, and because it was hard to read), but that doesn't mean that they've lost access to the works of Goethe. They just read Goethe printed in a modern script. Just like we read Chaucer in a modern script; few of us would be able to read Chaucer's original handwriting. For that matter, modern editions of Shakespeare silently expand abbreviations and use round s for long s (the one that looks like an f with part of the bar missing).
Very few of us read literature in manuscript form anyway; we read Saki and Shakespeare and the Shellys in printed editions, so the original manuscripts could have been written in some dead shorthand that's no longer in use and it wouldn't make any difference to anybody except those very few people who examine the original manuscripts. (And they would probably just learn that dead shorthand, the same way that people who consult Anglo-Saxon manuscripts learn the [half-uncial?] letterforms, or people who consult prewar German manuscripts learn that style of handwriting.)
The nominative singular (subject of a sentence) is "Venus", but all the other cases (other grammatical uses) start in "Vener-". I'm pretty sure the genitive case "Venus' clamshell, the clamshell of Venus" is "Veneris".
When Russian speakers borrow foreign words, they usually keep the original gender (feminine in this case, despite the fact that the Latin nominative plural ends in -us which usually means masculine), and they usually take the root form of other cases rather than just the nominative singular ("Vener-" rather than "Venus"). In Russian, feminine nouns usually end in "-a" (or "-ya", which is a different letter). So to borrow the word Venus from Latin, Russian took the base form "Vener-" and tacked an "-a" on the end of it because it was feminine to make "Venera".
I believe genus/generis (pl. genera) is declined (has grammatical endings tacked on) in the same way as "Venus", so yes, if she were cloned there would be two Venera. (But in Russian Venera is the singular.) Penis is declined in a different way; the Latin plural would be penes.
Not that anybody's life is really improved by knowing this, of course.:-)
I don't listen to much popular music, but once in a while I'd be in the car or at a restaurant where they had the radio on or something like that, and I'd hear a snippet of something I really liked. Used to be, I'd do an AltaVista search (this is a few years ago) and find out the name of the song and the artist and the album, and go buy it. (And I bought some clunkers that way, 'cause often the song I heard was the only one on the album I liked, but at least I had that song, and legally.)
I basically assumed at the time that while the lyrics were copyrighted, no sane music publisher would object to having them redistributed, since that was basically free advertising.
Then the music industry started going after lyric sites. I know some of them are still out there, but (1) they're a bit harder to find/search, and (2) I'd feel weird about participating in something that was technically illegal for no better reason than just to be able to give my money to a stupid industry that's trying to deprive me of my constitutional right to free expression [and not just by self-destructively vigorous enforcement of copyright, but that's a different diatribe]. So now when I hear a little snippet of a song on the radio that I like (unless it's NPR, in which case they usually make it easy for me to find all the information I need and often make it easy for me to hear the whole program again on the web), I just say "oh, well" and go download something (legally) from BeSonic.com or some other musician-supported site. I still buy CDs, but I spend less on them than I used to, and they're much more classical and folk (the sort of thing I hear about on NPR) and much less pop and rock (the sort of thing I'd hear in businesses or randomly spinning the dial in the car) than they used to be.
Oh, well, I guess the music publishers don't want my business, since they're making it harder for me to buy their product.
I bet 90% of commercial software products don't succeed either. It's the 10% that do that everybody's familiar with, though. The cool thing about open source is that the work done on the 90% of projects that fail is not necessarily wasted; the (perhaps limited) expertise that those projects developed can be borrowed by more successful projects. (I guess some of the same thing happens in the proprietary-software world when Microsoft buys upstart competitors and raids their IP pantries, but the cross-fertilization is a lot easier with Open Source projects.)
There's some advantage to being able to pay a team of developers salaries they can live on, and provide them with offices to work in and testbed platforms and that sort of thing. But there's also some advantage to working in an environment where you can see exactly what your "competitors" are doing and vice versa -- where your competitors essentially become colleagues. I'm not really on top of it, for instance, but I gather there's some degree of open collaboration (in terms of sharing expertise/approaches and supporting interoperability) between KDE and GNOME these days, and a lot of that spills over and makes things easier for smaller projects as well.
On the other hand, relying on a proprietary product means that features you want or require depend upon the developer. If it doesn't meet your needs today, you have no way to ensure it ever will.
Sometimes, even if it does meet your needs today, you have no way to ensure it will in the future. The product could be licensed annually, and the company could take out the feature you depend on in a future release ("most of our customers thought it was too confusing"), or stop supporting your platform, or go under, or get bought out by a competitor who wants to kill the product. Even if the product comes with a permanent license, you might end up forced to upgrade (for instance, if you need to upgrade the hardware platform for other reasons), and still be stuck if the vendor doesn't support the old version. Open Source isn't a panacea for end users, but it does insulate you to some extent from those sorts of risks.
We do this at home and at work, but it's hugely resource-intensive. I have no hard numbers, but it seems like it increases the amount of processing time for an incoming email message by something like an order of magnitude. (That's tweakable, of course, at the expense of less accuracy.) At work, after we installed SpamAssassin and before we upgraded to a new mail server, there were increasingly-frequent periods of an hour or so when mail was coming in faster than it could be delivered.
SpamAssassin is great at what it does, but there's a huge cost to using it. If you're only using 5% of your mail server's capacity, then you don't have to shell out Actual Bucks (or drachmata, or whatever) in order to use SpamAssassin, but I'm sure that a huge ISP like AOL would actually have to deploy large amounts of additional hardware. Maybe it's worth it to them and their customers, but there's definitely a trade-off involved.
(Feel free to use this argument to those people who say "but can't you just press delete?".:-)
That's a relief. I run a half dozen mailing lists, and I'd be surprised if less than 5% of my subscribers were on AOL. (Just checked; it's 6.4%, or 116 users. The lists are fairly small.) They'd be kind of unhappy if all of a sudden they couldn't get their list mail.:-)
(Another happy Speakeasy customer.)
America is supposed to be the Home of the Free and Land of the Brave. At least it was until the last few years.
To be fair, the "home of the free" had legal slavery until the mid-19th century, had systematic government (never mind private) discrimination on the basis of race well into the 20th, and did not allow women to vote until the 20th century. Yes, things are bad now and it's pretty scary, but things were bad in the 50s, too. I'm not saying we shouldn't speak out against these sorts of apalling abuses of power, but it's not accurate to say that the US was a bastion of civil liberties until the last few years, and now everything is going downhill. Overall, over the history of the US, civil liberties seem to have improved over time on average. (I'm sure Thomas Jefferson would have been shocked if somebody told him he couldn't smoke opium if he wanted to, but I'm talking about general overall trends. I imagine he'd also have been shocked at the notion that women should be able to vote. Since he considered slavery a "necessary evil", he probably wouldn't have been shocked at the freeing of the slaves.)
I'm as incensed as anybody about what's being done to my country and its constitution by its current rulers, so it feels a bit weird to be saying "things aren't so bad", but if you think about the lives and rights of all but white male landowners whose ancestors came from the right European countries for much of US history, well, things aren't so bad.
(The "spreading disease" thing is definitely a concern, though, and the huge and growing ability of the US to dictate policy outside its borders is part of why I wonder at the wisdom of Québec considering secession. The real enemies of la société distincte are not Ottawa and Edmonton, but Wall Street and Washington and Hollywood.)
The "Familiar" Linux distribution for the iPAQ supports gtk2. Relevant links include http://www.handhelds.org, http://familiar.handhelds.org, and http://gpe.handhelds.org. (Familiar is the base Linux distribution, and GPE is the X-and-Gtk-based GUI on top of that. There's also a Qt-Embedded-based GUI called OPIE; I don't know if that supports Unicode as well, but I would guess it probably does.)
You'd probably need to install your own fonts. Not all models are supported, but the 3800 and 3900 series are, along with older models (the 3900 with some limitations).
All that said, if all you care about is whether it has Unicode support, as other posts have pointed out, Pocket PC has Unicode support, so you could get an iPAQ and skip putting Linux on it. Whether it's easy to find/install the fonts and input methods you'd need for Pocket PC, I don't know.
Re:Easy...
on
BSA IDC FUD
·
· Score: 2, Insightful
can your dad configure a unix mail reader ?
My dad (hypothetical, since my actual dad is dead) could install RedHat or Mandrake or SuSE or some such distribution that comes with an adequate mail configuration for "typical" cases, and use it, same as an unskilled Windows user could with a comparable product. No, my dad couldn't configure a Unix MTA to properly handle several virtual domains on an intermittently-connected net, and I bet the typical nontechnical Windows user couldn't without consulting a Windows guru either.
Oh, wait. You said a mail reader. Sure, my (hypothetical) dad can configure a Unix mail reader adequately for his purposes, just as nontechnical Windows users can. Maybe not UCB Mail or MH, but then I'm sure there are high-learning-curve Windows mail readers out there too.
If the contention is that MCSE's are idiots and unix admins are smart,
I have the impression the quality of MCSEs isn't as high as the quality of Unix admins overall, because I have the impression that lots of MCSEs study or are taught to the test. So I'd rather compare Unix admins who get a reasonable amount of respect to working Windows admins who get a reasonable amount of respect. And no, I certainly wouldn't claim that Windows admins are dumb and Unix admins are smart. I'm a Unix admin; my officemate is a Windows admin. He definitely deals with problems that are just as challenging and just as interesting (to him, anyway) as the problems I deal with.
There are some cultural differences in general between experienced Unix admins and experienced Windows admins, though. Because Unix got its first mass-market footholds in science, engineering, and higher education, and Windows got its first mass-market footholds in more general-purpose uses, a disproportionate number of Unix admins come from research and academia (and the engineering industry). Doesn't mean they're smarter, just means they tend to have a different background and different expectations. (Actually, that could help explain some of the rep Unix admins have for being elitist, come to think of it.) And I have a feeling that people tend to drift into Unix administration from programming, whereas Windows admins are less likely to have a programming background. And Windows used to have much poorer support for scripting/automating administration (I gather from my officemate that it's getting a lot better), which would mean that programming ability wasn't as helpful or rewarded in a Windows environment than in a Unix environment.
But my sense is that a good Windows admin has just as deep troubleshooting skills, just as sophisticated a mental model of the machine and the network, and just as much discipline as a good Unix admin.
It sounds like your brother's Darwinian approach to laundry is similar to mine. I buy all sorts of clothes. That which survives a couple washings (hot, mixed in with all my other laundry, with bleach if I feel like it and I can find any) is fit and lasts to be worn. The jeans that do not survive are not passed on.
Every time its suckiness comes up, someone always tries to defend it by claiming that the network transparancy is a great feature. Dudes, hardly anyone uses that...
That's utterly silly. I use X11's network transparency all the time, every day. Probably more than half the windows I type and click at are local, but not much more than half. And lots of the users I support use network transparency as well. Of course, the ones I actually hear from are disproportionately likely to be power-users, so maybe they're not a representative sample, but still, A lot of people use this feature a lot, and some people really depend on it.
There's certainly some cruft in X11. Hardware has progressed to the point that forcing applications to notice details of the graphics card's colour model no longer really makes sense. And I'll be happy when TrueType is ubiquitous in X apps (it's getting there). But you can have my network transparency when you pry it out of my cold, dead fingers.
Texon? Don't people spell-check articles any more? The correct spelling is Texxon, of course. (And remember, what's good for the Michigoose is good for the Michigander.)
No, copyrighted software that was sold for individual use with no further restrictions other than those that come from copyright law - the same restrictions you have on a book or a magazine or a piece of artwork you buy - could be sold with such a sticker. You'd be free to use that one copy however you like (except in public performance), modify it if you could, destroy it, disassemble it and browse the code. You'd even be able (I think) to sell it, which many EULAs prohibit now. What you wouldn't be able to do is make copies of it, but that's prohibited by copyright law, so it doesn't need to be prohibited by a special EULA unless the seller wants you to agree to give up rights you would otherwise have under the law. (In many jurisdictions, it might leave you with an implied warranty on the software that the EULA tries to take away, for instance.)
I'm not particularly happy living under our current operating system monopoly, but this article only bolsters my concern that we're on the brink of creating a new one.
I don't have much to contribute about your other points, but I wanted to point out that a "monopoly" based on a GPL'ed operating system would be a very different thing that a monopoly based on a closed-source operating system, because no one entity would have a monopoly on the code itself.
Microsoft has a huge amount of leverage they can use by being the people who implement de-facto standards, and not disclosing them to their competitors. While Microsoft encourages other vendors to develop for Windows, and to some extent cooperates with hardware vendors in setting standards, it's not a level playing field. If you have an interesting widget you want to sell, and Microsoft doesn't like you, they can just guarantee that your widget doesn't work under windows (or more likely, subtly break things so that your widget doesn't work well). I can't easily figure out what they've done without their cooperation (and depending how they've done it, I might need extremely well-paid lawyers just to feel safe trying).
If a GPL'ed operating system were in the same position of market domination and $linux_vendor tried to prevent my widget working with their OS, and assuming they were complying with the GPL, I could say, "Why would you want to buy a Linux from $linux_vendor, when I'll ship you a Linux for free with my $59.95 widget that is completely compatible with $linux_vendor's version, except that it works with my widget and I've folded in these hundred and fifty bug fixes and it runs a little faster?" (The latter two advantages being just because I was releasing my version a few weeks after $linux_vendor released their version.)
(In theory, the same sort of hidden de-facto-standard torpedo could happen with a fork of a BSD-licensed OS as does with Windows, but I think it would be considerably less likely as long as no one proprietary fork got a huge market advantage.)
Actually, I believe the EFF's proposals would accomplish that. CSS is used for region-coding; if there's an exemption for playing region-coded DVDs, that would amount to making it unambiguously legal to reverse-engineer CSS and the DVD-player codes it uses. (That sentence would be clearer if I said "making it unambiguously legal to use DeCSS", but I'm not sure about the copyright/software-patent status of DeCSS itself.)
That's correct - in the US, the appearance of a font can not be copyrighted, and it follows that a bitmapped font can't be copyrighted, but a PostScript or a TrueType font is normally a collection of procedures that draw the glyphs, and that collection of procedures can be copyrighted.
Some fonts can be granted a design patent (not the same kind of thing as a software patent), but I think a font has to look fairly unusual or distinctive for that. A collection of decorative initials, for instance, might be a good candidate for a design patent; yet another font that looks kinda like Gill Sans wouldn't be.
In Europe, I believe the appearance of a font can be copyrighted, but I'm not 100% sure about that.
This is why you can buy (in the US) a CD of licensed original fonts from Bitstream for a few hundred dollars, or you can buy a CD of not very good imitations of the same fonts for $20.00. Personally, I think this is a good thing, in that it means that somebody who can't afford a real Gill Sans can still afford an approximation that's good enough for their high-school newsletter.
(Hmmm, maybe professional type foundries could make some of their fonts available at regular rates for commercial use, and at drastically reduced rates for non-profit or small-scale use, perhaps also requiring an acknowledgement in the publication.)
If you think of it, the idea of copyrighting the appearance of a font is a bit odd, since the purpose of buying a font is to be able to copy all the little pictures over and over. But then, who ever said law was supposed to make sense.:-)
Sure, there have been some spectacular failures. But there have been spectacular successes as well. There's an awful lot we know about the Universe we live in, and about our own planet, that we would not know if it were not for those missions. For that matter, the Apollo project, expensive as it was, and despite the fact that it was not focussed on science, told us a huge amount about the past, present, and future of Earth.
(I have to admit, much though I emotionally like the idea of humans in space, that the uncrewed missions are a lot less expensive per quantum of discovery than the crewed ones.)
last time I worked with it Tcl/Tk 4.2 the only way to scope variables was by file based scoping. Everything was global.
No version of Tcl/Tk has had anything like file-based scoping. In Tcl 7.6/Tk 4.2 (Tcl and Tk didn't start sharing version numbers until 8.0), there were only two scopes: variables inside a procedure were local by default, and could be global if you said so. (Global variables were shared by the entire interpreter, no matter what file they were defined in. I think Tcl 7.6 already allowed you to have multiple "interpreters" for this purpose running within the same process, but that might not have been introduced until 8.0.)
Is that what you meant - that different procedures couldn't share variables without them being global? I'll grant you, that's an inconvenience unless you're either very disciplined or willing to pass around all the state you care about as procedure arguments.
More recent versions of Tcl/Tk support arbitrary hierarchical namespaces so different procedures can share variables without them being global.
It's actually really good for doing certain specific kinds of large things, too - large things where the distinction between code and data is a little fuzzy, and much of the code is generated or manipulated by the script itself. I may be wrong, because I'm not too plugged into the Perl community, but I believe people tend not to do much of that sort of thing in Perl, but in Tcl it's easy to have a procedure modify itself, or create a modified copy of itself, or modify other running procedures. That makes it good for really high-availability applications, by the way, because you can patch the running code without having to restart it. I bet that's part of why it's used at NBC, and part of why it was used in the Mars Pathfinder mission. Oh, and in the recent Ariane launch that was in the news. (Just kidding.:-)
Honestly, is there any poor soul out there who codes new projects in Tcl?
Well, my big project was started before Tcl/Tk had a text widget, and I think before NCSA Mosaic was written, but yes, Tcl is what I use for anything new that needs a GUI or is otherwise beyond the capabilities of a short Bourne-shell script.
(The main thing I've written is an editor, which you can find along with a bunch of other stuff here. Please don't judge Tcl based on what I do with it in my spare time, though; there are loads of better-maintained and more ambitious Tcl projects out there.)
Has anybody fixed the whitespace/quoting bogosity in that language? Can you say x++ instead of [incr x] yet?
Well, the thing I like about Tcl is it's utterly fanatical self-consistency and simplicity. It's about the diametric opposite of Perl (especially pre-Perl5 Perl. Larry Wall wrote "I wanted Perl to work smoothly in the way that natural languages work smoothly, not in the way that mathematics works smoothly." Tcl works smoothly in the way that mathematics works smoothly. It's a very small, very consistent language, and that means you can keep all of it in your head even as a casual user. It's learning curve comes mainly from being simpler than other languages a new Tcl programmer may be familiar with. Yes, that means you can't write DeCSS in half a line of punctuation characters the way you can with some languages:-), but it means that when you understand the syntax you really understand it.
Honestly, asking why you can't increment a variable by appending ++ to it in Tcl is like asking why you can't indicate the object of a verb by changing a final -us to -um in English instead of having to put the words in a particular order, or why you can't "use Getopt::Std;" in Lisp, or why you can't just push the button for the right floor in a car the way you can in an elevator.
Tcl and Perl are both excellent languages, but they appeal to very different kinds of people. (I haven't used it much, but from what I've seen Python is somewhere in the middle - a lot of Tcl's consistency, but also a lot of syntax compared to Tcl, which lets you express things somewhat more tersely.)
Tcl is also great at introspection, which makes it easy to write code that manipulates code.
Tcl was originally designed as an embedded extension language, to be added on to applications in $COMPILED_LANGUAGE to provide scriptability - it was originally targetted to replace things like sendmail.cf,.fvwmrc, crontab, and that sort of thing. That particular target market drove some of the early design goals - simplicity, very minimal syntax, and small code footprint. A lot of people (somewhat to Ousterhout's surprise) started using it for serious, large apps, and (in many people's opinion) it worked really well for that, but I think a lot of the characteristics that make Tcl different from other languages stem from that origin.
I actually wish that Tcl had had more success in its original intended niche; since it's a pain to have to learn a new incomplete and clunky mini-language with every new application you want to configure or script - and then not have them be able to talk to each other. If Guile or whatever becomes a bit more ubiquitous for that purpose I'll learn it and be content, I suppose, but I guess everybody who writes a new app wants to write a new language to go along with it rather than steal somebody else's.:-)
Slashdot Mirror
Another thing I'd really like to see is a mechanism for MTAs and MUAs (and their users) to negotiate policy agreemeents for the content that they carry. It would work a little bit like content negotiation on the web. For instance, if I'm sending a piece of personal non-anonymous noncommercial email to a single individual I already know, that message would meet a very large number of policy agreements. (Some of them might be agreements I or the recipient had written, but most of them would be standard agreements written by third parties.) So my mail software could present the recipient's mail software with (at least) four pieces of information: sender, recipient, the location (on my server) of the message, and a list of the locations of a bunch of the agreements that I promise the message is certified to meet, probably with checksums so it can be proved that I'm talking about the same set of agreements the recipient is reading.
The recipient's software (and the distinction between MTA and MUA might be fuzzier than it is now) would similarly have a list of policy agreements that it was configured to accept. If any of the list of policy agreements the recipient was willing to accept matched any of the list of policy agreements the sender certified the message against, the message would be "accepted" -- presented to the recipient by the MUA. Presumably the recipient would have a choice of copying the message to local storage or leaving it on the sender's server (where it might expire if the sender decided not to keep hosting it, although some policy agreements might promise to keep messages for a certain amount of time). If none of the policy agreements intersected, the message would not be presented to the user (and probably the sender would be so informed).
This mechanism would allow recipients to choose what kind of mail they accept, and therefore it would not (in and of itself) prevent important things like anonymous mail, or mail sent from unreplyable addresses, or mailing lists, or mail from unknown persons. It would just be a mechanism for recipients to say what kind of mail they're willing to accept, and senders to describe (in the form of an agreement or "contract") the characteristics of their mail. And that needn't be limited to just spam prevention -- if I don't want any mail longer than 40k, or I don't want any mail with images or animation, or I don't want any mail with more quoted text than original text, I can express that.
Now, that's still infrastructure that depends on some degree of honesty on the part of the sender, so it's not a complete solution by itself. The people who forge mail headers so their spam appears to come from real (innocent) people wouldn't be deterred by this; they'd just lie as they do now. But a large amount of spam is ultimately traceable if the victim cares enough, and those spam senders probably would just let their spam fall into the bit-bucket. It would actually make spam *cheaper* for them, because they weren't transmitting as much data (the meta-information for everybody, but the message itself only to people who choose to read it), and that might give them less incentive to force their spam on people who didn't want to read it. And as a recipient, I might choose only to accept mail that certifies compliance with policy agreements that have enforcement clauses ("...and if this message shall not originate from the Authenticated Sender, Actual Sender shall be liable for damages of..."), and then anybody who successfully sends me spam had to agree to that contract and is liable for breaking it, if I can track them down. The fact that lots of spam actually does get sent out with "ADV:" or the Korean or Chinese equivalent in the subject line suggests that at least a noticeable fraction of spammers would just not list agreements fraudulently and live with the smaller market.
Well, it's half-baked, but it's an idea.
I wrote an invitation in PostScript once that drew a random starfield and receding text along the lines of the StarWars intro. It was done in a completely stupid, brute-force way. It took at least a couple minutes to render on a NeXT. My hapless co-worker printed it on a LaserWriter II, and it took half an hour to print. PostScript is a full-fledged programming language, so it can be arbitrarily slow if you want it to. :-)
Very few of us read literature in manuscript form anyway; we read Saki and Shakespeare and the Shellys in printed editions, so the original manuscripts could have been written in some dead shorthand that's no longer in use and it wouldn't make any difference to anybody except those very few people who examine the original manuscripts. (And they would probably just learn that dead shorthand, the same way that people who consult Anglo-Saxon manuscripts learn the [half-uncial?] letterforms, or people who consult prewar German manuscripts learn that style of handwriting.)
Also a solution to John Howard, although the collateral damage might be a bit severe.
When Russian speakers borrow foreign words, they usually keep the original gender (feminine in this case, despite the fact that the Latin nominative plural ends in -us which usually means masculine), and they usually take the root form of other cases rather than just the nominative singular ("Vener-" rather than "Venus"). In Russian, feminine nouns usually end in "-a" (or "-ya", which is a different letter). So to borrow the word Venus from Latin, Russian took the base form "Vener-" and tacked an "-a" on the end of it because it was feminine to make "Venera".
I believe genus/generis (pl. genera) is declined (has grammatical endings tacked on) in the same way as "Venus", so yes, if she were cloned there would be two Venera. (But in Russian Venera is the singular.) Penis is declined in a different way; the Latin plural would be penes.
Not that anybody's life is really improved by knowing this, of course. :-)
But don't the people who the MPA represent get royalties on the CDs?
I don't listen to much popular music, but once in a while I'd be in the car or at a restaurant where they had the radio on or something like that, and I'd hear a snippet of something I really liked. Used to be, I'd do an AltaVista search (this is a few years ago) and find out the name of the song and the artist and the album, and go buy it. (And I bought some clunkers that way, 'cause often the song I heard was the only one on the album I liked, but at least I had that song, and legally.)
I basically assumed at the time that while the lyrics were copyrighted, no sane music publisher would object to having them redistributed, since that was basically free advertising.
Then the music industry started going after lyric sites. I know some of them are still out there, but (1) they're a bit harder to find/search, and (2) I'd feel weird about participating in something that was technically illegal for no better reason than just to be able to give my money to a stupid industry that's trying to deprive me of my constitutional right to free expression [and not just by self-destructively vigorous enforcement of copyright, but that's a different diatribe]. So now when I hear a little snippet of a song on the radio that I like (unless it's NPR, in which case they usually make it easy for me to find all the information I need and often make it easy for me to hear the whole program again on the web), I just say "oh, well" and go download something (legally) from BeSonic.com or some other musician-supported site. I still buy CDs, but I spend less on them than I used to, and they're much more classical and folk (the sort of thing I hear about on NPR) and much less pop and rock (the sort of thing I'd hear in businesses or randomly spinning the dial in the car) than they used to be.
Oh, well, I guess the music publishers don't want my business, since they're making it harder for me to buy their product.
I bet 90% of commercial software products don't succeed either. It's the 10% that do that everybody's familiar with, though. The cool thing about open source is that the work done on the 90% of projects that fail is not necessarily wasted; the (perhaps limited) expertise that those projects developed can be borrowed by more successful projects. (I guess some of the same thing happens in the proprietary-software world when Microsoft buys upstart competitors and raids their IP pantries, but the cross-fertilization is a lot easier with Open Source projects.)
There's some advantage to being able to pay a team of developers salaries they can live on, and provide them with offices to work in and testbed platforms and that sort of thing. But there's also some advantage to working in an environment where you can see exactly what your "competitors" are doing and vice versa -- where your competitors essentially become colleagues. I'm not really on top of it, for instance, but I gather there's some degree of open collaboration (in terms of sharing expertise/approaches and supporting interoperability) between KDE and GNOME these days, and a lot of that spills over and makes things easier for smaller projects as well.
We do this at home and at work, but it's hugely resource-intensive. I have no hard numbers, but it seems like it increases the amount of processing time for an incoming email message by something like an order of magnitude. (That's tweakable, of course, at the expense of less accuracy.) At work, after we installed SpamAssassin and before we upgraded to a new mail server, there were increasingly-frequent periods of an hour or so when mail was coming in faster than it could be delivered.
SpamAssassin is great at what it does, but there's a huge cost to using it. If you're only using 5% of your mail server's capacity, then you don't have to shell out Actual Bucks (or drachmata, or whatever) in order to use SpamAssassin, but I'm sure that a huge ISP like AOL would actually have to deploy large amounts of additional hardware. Maybe it's worth it to them and their customers, but there's definitely a trade-off involved.
(Feel free to use this argument to those people who say "but can't you just press delete?". :-)
That's a relief. I run a half dozen mailing lists, and I'd be surprised if less than 5% of my subscribers were on AOL. (Just checked; it's 6.4%, or 116 users. The lists are fairly small.) They'd be kind of unhappy if all of a sudden they couldn't get their list mail. :-)
(Another happy Speakeasy customer.)
To be fair, the "home of the free" had legal slavery until the mid-19th century, had systematic government (never mind private) discrimination on the basis of race well into the 20th, and did not allow women to vote until the 20th century. Yes, things are bad now and it's pretty scary, but things were bad in the 50s, too. I'm not saying we shouldn't speak out against these sorts of apalling abuses of power, but it's not accurate to say that the US was a bastion of civil liberties until the last few years, and now everything is going downhill. Overall, over the history of the US, civil liberties seem to have improved over time on average. (I'm sure Thomas Jefferson would have been shocked if somebody told him he couldn't smoke opium if he wanted to, but I'm talking about general overall trends. I imagine he'd also have been shocked at the notion that women should be able to vote. Since he considered slavery a "necessary evil", he probably wouldn't have been shocked at the freeing of the slaves.)
I'm as incensed as anybody about what's being done to my country and its constitution by its current rulers, so it feels a bit weird to be saying "things aren't so bad", but if you think about the lives and rights of all but white male landowners whose ancestors came from the right European countries for much of US history, well, things aren't so bad.
(The "spreading disease" thing is definitely a concern, though, and the huge and growing ability of the US to dictate policy outside its borders is part of why I wonder at the wisdom of Québec considering secession. The real enemies of la société distincte are not Ottawa and Edmonton, but Wall Street and Washington and Hollywood.)
The "Familiar" Linux distribution for the iPAQ supports gtk2. Relevant links include http://www.handhelds.org, http://familiar.handhelds.org, and http://gpe.handhelds.org. (Familiar is the base Linux distribution, and GPE is the X-and-Gtk-based GUI on top of that. There's also a Qt-Embedded-based GUI called OPIE; I don't know if that supports Unicode as well, but I would guess it probably does.)
You'd probably need to install your own fonts. Not all models are supported, but the 3800 and 3900 series are, along with older models (the 3900 with some limitations).
All that said, if all you care about is whether it has Unicode support, as other posts have pointed out, Pocket PC has Unicode support, so you could get an iPAQ and skip putting Linux on it. Whether it's easy to find/install the fonts and input methods you'd need for Pocket PC, I don't know.
My dad (hypothetical, since my actual dad is dead) could install RedHat or Mandrake or SuSE or some such distribution that comes with an adequate mail configuration for "typical" cases, and use it, same as an unskilled Windows user could with a comparable product. No, my dad couldn't configure a Unix MTA to properly handle several virtual domains on an intermittently-connected net, and I bet the typical nontechnical Windows user couldn't without consulting a Windows guru either.
Oh, wait. You said a mail reader. Sure, my (hypothetical) dad can configure a Unix mail reader adequately for his purposes, just as nontechnical Windows users can. Maybe not UCB Mail or MH, but then I'm sure there are high-learning-curve Windows mail readers out there too.
I have the impression the quality of MCSEs isn't as high as the quality of Unix admins overall, because I have the impression that lots of MCSEs study or are taught to the test. So I'd rather compare Unix admins who get a reasonable amount of respect to working Windows admins who get a reasonable amount of respect. And no, I certainly wouldn't claim that Windows admins are dumb and Unix admins are smart. I'm a Unix admin; my officemate is a Windows admin. He definitely deals with problems that are just as challenging and just as interesting (to him, anyway) as the problems I deal with.
There are some cultural differences in general between experienced Unix admins and experienced Windows admins, though. Because Unix got its first mass-market footholds in science, engineering, and higher education, and Windows got its first mass-market footholds in more general-purpose uses, a disproportionate number of Unix admins come from research and academia (and the engineering industry). Doesn't mean they're smarter, just means they tend to have a different background and different expectations. (Actually, that could help explain some of the rep Unix admins have for being elitist, come to think of it.) And I have a feeling that people tend to drift into Unix administration from programming, whereas Windows admins are less likely to have a programming background. And Windows used to have much poorer support for scripting/automating administration (I gather from my officemate that it's getting a lot better), which would mean that programming ability wasn't as helpful or rewarded in a Windows environment than in a Unix environment.
But my sense is that a good Windows admin has just as deep troubleshooting skills, just as sophisticated a mental model of the machine and the network, and just as much discipline as a good Unix admin.
It sounds like your brother's Darwinian approach to laundry is similar to mine. I buy all sorts of clothes. That which survives a couple washings (hot, mixed in with all my other laundry, with bleach if I feel like it and I can find any) is fit and lasts to be worn. The jeans that do not survive are not passed on.
XFCE is another nice very lightweight X environment.
There's certainly some cruft in X11. Hardware has progressed to the point that forcing applications to notice details of the graphics card's colour model no longer really makes sense. And I'll be happy when TrueType is ubiquitous in X apps (it's getting there). But you can have my network transparency when you pry it out of my cold, dead fingers.
Texon? Don't people spell-check articles any more? The correct spelling is Texxon, of course. (And remember, what's good for the Michigoose is good for the Michigander.)
No, copyrighted software that was sold for individual use with no further restrictions other than those that come from copyright law - the same restrictions you have on a book or a magazine or a piece of artwork you buy - could be sold with such a sticker. You'd be free to use that one copy however you like (except in public performance), modify it if you could, destroy it, disassemble it and browse the code. You'd even be able (I think) to sell it, which many EULAs prohibit now. What you wouldn't be able to do is make copies of it, but that's prohibited by copyright law, so it doesn't need to be prohibited by a special EULA unless the seller wants you to agree to give up rights you would otherwise have under the law. (In many jurisdictions, it might leave you with an implied warranty on the software that the EULA tries to take away, for instance.)
I don't have much to contribute about your other points, but I wanted to point out that a "monopoly" based on a GPL'ed operating system would be a very different thing that a monopoly based on a closed-source operating system, because no one entity would have a monopoly on the code itself.
Microsoft has a huge amount of leverage they can use by being the people who implement de-facto standards, and not disclosing them to their competitors. While Microsoft encourages other vendors to develop for Windows, and to some extent cooperates with hardware vendors in setting standards, it's not a level playing field. If you have an interesting widget you want to sell, and Microsoft doesn't like you, they can just guarantee that your widget doesn't work under windows (or more likely, subtly break things so that your widget doesn't work well). I can't easily figure out what they've done without their cooperation (and depending how they've done it, I might need extremely well-paid lawyers just to feel safe trying).
If a GPL'ed operating system were in the same position of market domination and $linux_vendor tried to prevent my widget working with their OS, and assuming they were complying with the GPL, I could say, "Why would you want to buy a Linux from $linux_vendor, when I'll ship you a Linux for free with my $59.95 widget that is completely compatible with $linux_vendor's version, except that it works with my widget and I've folded in these hundred and fifty bug fixes and it runs a little faster?" (The latter two advantages being just because I was releasing my version a few weeks after $linux_vendor released their version.)
(In theory, the same sort of hidden de-facto-standard torpedo could happen with a fork of a BSD-licensed OS as does with Windows, but I think it would be considerably less likely as long as no one proprietary fork got a huge market advantage.)
Actually, I believe the EFF's proposals would accomplish that. CSS is used for region-coding; if there's an exemption for playing region-coded DVDs, that would amount to making it unambiguously legal to reverse-engineer CSS and the DVD-player codes it uses. (That sentence would be clearer if I said "making it unambiguously legal to use DeCSS", but I'm not sure about the copyright/software-patent status of DeCSS itself.)
That's correct - in the US, the appearance of a font can not be copyrighted, and it follows that a bitmapped font can't be copyrighted, but a PostScript or a TrueType font is normally a collection of procedures that draw the glyphs, and that collection of procedures can be copyrighted.
:-)
Some fonts can be granted a design patent (not the same kind of thing as a software patent), but I think a font has to look fairly unusual or distinctive for that. A collection of decorative initials, for instance, might be a good candidate for a design patent; yet another font that looks kinda like Gill Sans wouldn't be.
In Europe, I believe the appearance of a font can be copyrighted, but I'm not 100% sure about that.
This is why you can buy (in the US) a CD of licensed original fonts from Bitstream for a few hundred dollars, or you can buy a CD of not very good imitations of the same fonts for $20.00. Personally, I think this is a good thing, in that it means that somebody who can't afford a real Gill Sans can still afford an approximation that's good enough for their high-school newsletter.
(Hmmm, maybe professional type foundries could make some of their fonts available at regular rates for commercial use, and at drastically reduced rates for non-profit or small-scale use, perhaps also requiring an acknowledgement in the publication.)
If you think of it, the idea of copyrighting the appearance of a font is a bit odd, since the purpose of buying a font is to be able to copy all the little pictures over and over. But then, who ever said law was supposed to make sense.
Sure, there have been some spectacular failures. But there have been spectacular successes as well. There's an awful lot we know about the Universe we live in, and about our own planet, that we would not know if it were not for those missions. For that matter, the Apollo project, expensive as it was, and despite the fact that it was not focussed on science, told us a huge amount about the past, present, and future of Earth.
(I have to admit, much though I emotionally like the idea of humans in space, that the uncrewed missions are a lot less expensive per quantum of discovery than the crewed ones.)
No version of Tcl/Tk has had anything like file-based scoping. In Tcl 7.6/Tk 4.2 (Tcl and Tk didn't start sharing version numbers until 8.0), there were only two scopes: variables inside a procedure were local by default, and could be global if you said so. (Global variables were shared by the entire interpreter, no matter what file they were defined in. I think Tcl 7.6 already allowed you to have multiple "interpreters" for this purpose running within the same process, but that might not have been introduced until 8.0.)
Is that what you meant - that different procedures couldn't share variables without them being global? I'll grant you, that's an inconvenience unless you're either very disciplined or willing to pass around all the state you care about as procedure arguments.
More recent versions of Tcl/Tk support arbitrary hierarchical namespaces so different procedures can share variables without them being global.
It's actually really good for doing certain specific kinds of large things, too - large things where the distinction between code and data is a little fuzzy, and much of the code is generated or manipulated by the script itself. I may be wrong, because I'm not too plugged into the Perl community, but I believe people tend not to do much of that sort of thing in Perl, but in Tcl it's easy to have a procedure modify itself, or create a modified copy of itself, or modify other running procedures. That makes it good for really high-availability applications, by the way, because you can patch the running code without having to restart it. I bet that's part of why it's used at NBC, and part of why it was used in the Mars Pathfinder mission. Oh, and in the recent Ariane launch that was in the news. (Just kidding.
Well, my big project was started before Tcl/Tk had a text widget, and I think before NCSA Mosaic was written, but yes, Tcl is what I use for anything new that needs a GUI or is otherwise beyond the capabilities of a short Bourne-shell script.
(The main thing I've written is an editor, which you can find along with a bunch of other stuff here. Please don't judge Tcl based on what I do with it in my spare time, though; there are loads of better-maintained and more ambitious Tcl projects out there.)
Well, the thing I like about Tcl is it's utterly fanatical self-consistency and simplicity. It's about the diametric opposite of Perl (especially pre-Perl5 Perl. Larry Wall wrote "I wanted Perl to work smoothly in the way that natural languages work smoothly, not in the way that mathematics works smoothly." Tcl works smoothly in the way that mathematics works smoothly. It's a very small, very consistent language, and that means you can keep all of it in your head even as a casual user. It's learning curve comes mainly from being simpler than other languages a new Tcl programmer may be familiar with. Yes, that means you can't write DeCSS in half a line of punctuation characters the way you can with some languages
Honestly, asking why you can't increment a variable by appending ++ to it in Tcl is like asking why you can't indicate the object of a verb by changing a final -us to -um in English instead of having to put the words in a particular order, or why you can't "use Getopt::Std;" in Lisp, or why you can't just push the button for the right floor in a car the way you can in an elevator.
Tcl and Perl are both excellent languages, but they appeal to very different kinds of people. (I haven't used it much, but from what I've seen Python is somewhere in the middle - a lot of Tcl's consistency, but also a lot of syntax compared to Tcl, which lets you express things somewhat more tersely.)
Tcl is also great at introspection, which makes it easy to write code that manipulates code.
Tcl was originally designed as an embedded extension language, to be added on to applications in $COMPILED_LANGUAGE to provide scriptability - it was originally targetted to replace things like sendmail.cf,
I actually wish that Tcl had had more success in its original intended niche; since it's a pain to have to learn a new incomplete and clunky mini-language with every new application you want to configure or script - and then not have them be able to talk to each other. If Guile or whatever becomes a bit more ubiquitous for that purpose I'll learn it and be content, I suppose, but I guess everybody who writes a new app wants to write a new language to go along with it rather than steal somebody else's.