If you want to learn how to write secure programs for Linux or Unix systems, read my freely-available book, Secure Programming for Linux and Unix HOWTO. You can get it from
http://www.dwheeler.com/secure-programs.
What this shows is that if laws were passed that made spam illegal, we'd get a lot less spam. You don't have to enforce every spam case to make an effect; just putting a few spammers in jail or fining them will change the behavior of many others.
If not illegal (the best solution), at least require all spam to be marked so that it can be easily filtered. And include all spam,
not just commercial spam.
It IS a good thing that the Flash viewer specification is publicly available. Good job! However, it's not publicly controlled - it's solely controlled by the (single) vendor, so it's not an open standard according to most usual definitions. However, that's still a great step forward; many may find that sufficient. PDF has a similar situation; Adobe owns the specification, but anyone can implement it.
It's worth noting, though, that there is no open source software implementation of the viewer. That's different than PDF, because there are open source implementations of PDF readers and writers (which is why PDF has become so popular - implementations are available literally everywhere, and no one feels that locked in). I think most people don't believe that an open source implementation is a requirement for an open standard, but it does mean that the viewer is not included in many distributions (e.g., Red Hat Linux and Debian have policies specifically discouraging such things). It also means that the viewers sometimes don't work when you upgrade your operating system.
Yes - please, tell the W3C you support their new
royalty-free policy for W3C standards.
Send email with your "attaboy" message to:
www-patentpolicy-comment@w3.org
It's not done, this is still a draft.
The biggest issue is, in my mind, use common sense. Make sure you have a better understanding of your current situation (systems and how people use them). In most cases, don't make all the changes at once - plan to do things in stages, test things out before you depend on them, then deploy - and examine how that stage went so you can adjust your plan for the next stage. Maybe you start by replacing a few servers, for example. If you're replacing desktops, maybe you start with just a few systems, or you replace Microsoft Office while keeping Microsoft Windows on a few systems.There's much to be said for incremental changes.
This is an absurdly one-sided piece, that seems to try to paint one spammer in the absolutely most positive light possible. I'm sure that there are many bank robbers and drug lords that use their money to support their families. The problem is not that they have families. The problem is that spammers are intentionally stealing resources from other people. See my essay at
http://www.dwheeler.com/essays/stopspam.html.
Fundamentally, her process is to make other people pay for her business. That is unacceptable.
The notion that people can "opt-out" is absurd; trying to opt-out of many lists will add you to the "sucker" list, and there's no way for a recipient to know if they'll be opted out or in fact added more.
If you're trying to write secure applications, I suggest taking a look at my book Secure Programming for Linux and Unix HOWTO at
http://www.dwheeler.com/secure-programs -
it's free, just download and print.
I just released the 29 October 2002 (version 3.000) edition.
FORTH is truly a fabulous language when you need to be able to interactively develop a program, where both the programming and execution must run on a very tiny machine (e.g., 2-48K RAM and 1-10MHz),
and you still need the program to run quickly.
Not only can you write code quickly, and get lots of interaction, but many Forth implementations are extraordinarily small, so you can actually read _every_ line of machine/assemly code that's executed on your equipment if you need to.
I remember some absolutely magical programs being written on Apple II and Atari 800 computers (32-64K RAM, 1MHz 6502 chips).
The problem is, the situation that FORTH is great in is becoming increasingly rare. Most FORTHs still require programmers to constantly think about how to juggle the stack if they receive a number of parameters (yes, there are some extensions). FORTH has essentially no type-checking, and the combination of these two factors means that it's extremely easy to (1) make a mistake and (2) for that mistake to have nasty consequences.
Many program language implementations generate intermediate stack-based code (think Java class files, Python, Perl, etc.); in FORTH, you're writing the stack-based code yourself, so you are essentially writing in an assembly language for a simulated stack-based system.
FORTH thus has some of the similar properties as assembler: fewer development system resources are required, but it's more work for the programmer.
This isn't completely true; FORTH is definitely much higher-level than the typical assembly language program, but many programs take more work to implement in FORTH than, say, Python (which is also interactive, and it executes a stack-based program, but lets people express code in a more Algol-like way and then TRANSLATES that code into a stack-based approach).
I do think Forth is a good language to learn, because many systems are built on stack-based intermediate languages (Java, C#, Perl, Python), and being able to directly interact with a stack-based language helps to learn how they really work.
Wake up: the web is about communication.
If you conform to open standards, you aid communication, because it means that anyone can reach you. HTML, PNG, etc., all conform to standards (such as those produced by the W3C and IETF).
Gratuitous use of non-standard formats is worth complaining about, because when enough complaints get made, the websites either stop using the nonstandard format, or convince enough people to create a standard for it.
Slashdot: Don't bother linking to Flash-only sites
on
Beautiful Case Modding
·
· Score: 2, Insightful
Hmm, a gray box with no content.
It appears that a LOT of readers either don't have or have disabled Flash, and I'm one of them. It might be worth waiting until the website repairs their site into something standards-conforming. HTML + PNG preferred.
There are no font specifications other
than a few tables, and the legal mumbo-jumbo
at the bottom. If the fonts aren't readable,
that's a problem with your browser settings.
In Mozilla, select
Edit/ Preferences/ Appearances/ Fonts
to modify them.
MITRE is well-respected. Technically, it is a Federally Funded Research and Development Center (FFRDC). FFRDCs are non-profit organizations chartered to give unbiased technical advice to the U.S. government.
Hrmph. Spam (unsolicited bulk email)
is still theft, and the DMA is
going to do all it can to ensure that the
theft can continue (as long the thieves are
THEIR members).
Still, this might help in spite of them.
A U.S.-wide law against forged "from" messages
from commercial spam would at least
dissuade some, especially if it had a stiff penalty.
This would make it easier to set up my
mailbox so that I raise the priority for
people I've talked with before; with stiff
penalties, they're less likely to forge
friends' addresses.
This would be REALLY good if the federal
law also required the "ADV" convention,
and nailed down EXACTLY what it means.
It's already in some state laws.
If I could automatically reject the messages
without having to read them all, that would
steal my bandwidth and storage, but at least
it wouldn't steal my time.
Yeah, not everyone obeys the law, there are offsite systems, etc. But it would be a first step, and some legal tools would make it a lot easier to employ technical ones. For example, there's no point in tracking down offenders if they've broken no law. Also, the evasion techniques make it much clearer that they ARE breaking the law. Finally, if nearly all email from some asian countries are spam, then entire continents can blacklist them... and that would be a real wake-up call that would reduce spam.
So, a few basic laws can really enable
technological solutions, so even a feeble law
might help.
I've written down a few comments and
anti-spam techniques at
http://www.dwheeler.com/esssays/stopspam.html;
some of you may find them interesting.
I know many others are interested in stemming
this outrageous flood of spam that is
threatening to steal the ability to
receive email.
Mentioning something in a public conference doesn't
make it unpatentable; it just starts the clock (I believe you have 1 year) and means that no one else can patent the idea. Besides, as far as I can tell, no one at the conference described the specifics, and it's the specifics that would be covered by patents.
I believe patent law does have some statements about turning it into practice; hopefully someone with more legal knowledge can clarify that. However, I'm sure Mr. Green can implement the technique and sell the product in limited editions (e.g., 3 copies total worldwide), which would probably satisfy any such requirement.
First, an explanation for those who
wonder what this means:
this addition
is a method for gaining finer control over
exactly what privileges a trusted program has.
If the method is actually used by the system,
the system could be more resistant to attack.
That's because
even if an attacker took control over a
privileged (trusted) program, the privileges
of that program would be more limited.
Somewhat similar capabilities also
exist for Linux.
The Linux Security Module (LSM) effort adds
the ability to insert an additional
access control mechanism into a Linux
kernel (without a recompile).
You can then at run-time insert
a modules to add finer control over
privileges.
Several modules exist, such as SELinux.
This approach
makes it easier to experiment or create
your own access control policy.
There are various LSM modules already
available; none of them are exactly
like this, but most provide finer-grain control.
There are definitely technical differences, too,
but describing those differences
would take up WAY too much space here.
There are definitely situations where finer
control over privileges is very desirable.
Which way is the best way is very much in doubt.
The good thing about finer control is that you
can give a program only the privileges it needs.
The bad thing about finer control is that it
takes more work to set up. "Learning" from
program runs helps, but it doesn't fully
solve the problem - there are usually many
conditions that aren't triggered by simple
runs yet can happen in real life.
Anyway, this kind of capability is a good thing.
It will be interesting to see what happens over the years as people try out various ways to add finer control - the trick will be to add finer control while still keeping the system easy to administrate. It's not even clear that there is a single solution.
What a waste. This thing has no backlight (so you can't use it in the dark) and only 2 Mb (so you can't store
many documents or programs on it).
It's cheaper, but only by a few dollars, so
the lower price isn't much of a differentiator.
My PRIMARY utility for a PDA is
for electronic books, so this thing is worthless for me. I've found that the calendar/ phone book / to-do applications are fun but really aren't better than paper. I suspect that many others will come to the same conclusion.
They will need to drop the price significantly (say, to $5-$10) for this to be worthwhile.
What about "normal" users? Is grandma going to be shocked that the latest system doesn't look like stock KDE? No. Grandma is going to have trouble because the various applications don't work the "same way" - the GNOME apps and KDE apps look too darn different.
Personally, I think trying to make it so users DON'T KNOW NOR CARE what the underlying libraries are makes sense, the resulting system will become much easier to use. If the KDE apps are crippled, then that's a problem, but I'd expect that to be fixed in future releases. More importantly, it's likely that this process will encourage more reuse between the groups, and that's a good thing.
For another book on writing secure programs,
see my "Secure Programming for Linux and Unix HOWTO" at
http://www.dwheeler.com/secure-programs.
It's free, and it covers both web applications and non-web applications.
This isn't a chicken-and-egg problem.
If EVERYONE had broadband at current
prices, and all music and movies were available
under the current RIAA (RICO) policies and prices,
I suspect
most people would immediately switch BACK to
phone lines and modems.
People buy CDs, DVDs, tapes, and videocassettes
because they want the freedom to do a lot
of things with that material.
They want watch/listen to the material as many
times as they want to, whenever they want to.
They want to use whatever media they have
to watch/listen to it themselves
(e.g., be able to copy CDs to their personal
tapes so they can hear the CD on a tape deck,
create their own CD mix, create an MP3 so they
can hear music on their laptop while leaving
the CD-ROM drive free for something else).
They want to avoid the risk of extra
fees and possible loss (assuming their
houses aren't physically damaged).
They want to do many other things
with it, too, and as long as it's only for
their personal use, they need to have the
freedom to do so.
Instead, many of the current electronic
distribution techniques for music and videos
have extremely consumer-hostile policies.
For example, many of the current RICO approaches
want you to pay monthly subscriptions, with
no additional services and no guarantee of a
stable price (I think we can safely assume
that if these approaches caught on, the
cost would ramp up steeply).
Since the legal online distribution
system is WORSE for the consumer than the
alternatives, few consumers want it.
Of course, if the music/video overlords
will not provide their content reasonably
over the Internet, what's left for the
Internet to legitimately do?
There are lots of other useful services
on the Internet:
email, web surfing, and so on. It would be
NICE to have higher bandwidth for that,
but clearly most people believe it's not worth
the extra money and trouble.
Obviously, things vary, but it IS more
money in many places - not everyone pays
AOL price$ for an ISP, and broadband is
outrageously expensive in many places.
Now I'm sure others here will disagree with me,
but Napster-like systems of mass sharing
are wrong.
RIAA vs. Napster was simply the case of
two evils pitted against each other.
RIAA is very hostile to artists, really
(the represent music publishers, not artists),
but Napster was even worse.
However, the growth of Napster and P2P systems
is really an evidence that the current publishers
"don't get it," and that is the real
problem.
The fundamental problem is that the
music and video industry, instead of
embracing a technology that could make them
a ton of money, are sticking their heads in
the sand and trying to uninvent technology
instead. Trying to invent totally
"non-copying" systems results in
incredibly invasive and privacy-destroying
systems which don't really work.
Trying to make digital media uncopying is,
as Bruce S. notes, like trying to make water
not wet, and someone with a videocamera aimed
at a screen can undo lots of fancy mechanisms.
But even worse, such systems fundamentally
subvert "fair use":
copyright law is a grant to authors, under the
condition that they permit fair use; if
fair use is taken away, then clearly
those organizations should forfeit
copyright protection as well.
A simple watermarking scheme that deals
with the casual pirate would be better;
it would permit fair use, and deal with
piracy as under current law.
The non-casual pirates are already creating
copies, and will continue to do so regardless
of the Digital Restrictions Management (DRM)
techniques used. It would be
better to use the technology available to
make it impossible for the pirates to compete,
by providing a legitimate service that
customers actually want to use. That means
charging less for the material (you'll still
make more money, since many overheads disappear
and people can impulse buy more quickly),
and making it trivial to obtain the material.
Of course, since the publishers essentially
own the souls of most artists, if publishers
will not release their material under
consumer-friendly terms, they obviously can do so.
But that will just mean what's already
happening: consumers will not use their
elecronic distribution mechanisms.
Unsigned artists are already making their
material available in other ways; it's
conceivable that eventually most material
will be released by artists instead of the
current publishers, at which points the
publishers suddenly discover they're irrelevant.
It's unclear that this will happen, but it's
a possibility.
I rather hope it does; it would serve these
companies right for ignoring their customers.
Actually, I think this is a GOOD thing, as long as
other distributions can also pick up the defaults.
Currently working with some programs is jarring -
and thus painful to users.
However, I think just having a generic
function description in the menus is a
mistake. It's important to modify the
menus so that they show not just the function
("Web Browser"), but also the name of the program
("Mozilla"). Yes, it's longer, but it is MORE
confusing to users when the programs change
or when they update to a different program.
When I see "Mozilla Web Browser" and
"Galeon Web Browser", I can understand both
(a) they do the same basic thing, but
(b) will do it somewhat differently.
You could swap the order if necessary
"Web Browser (Mozilla)" if you'd prefer, as
long as it was done consistently throughout
the system.
This is already a requirement in the
GNOME User Interface Guidelines; you can see
the whole document at:
http://developer.gnome.org/projects/gup/hig/1.0/
And this specific guidance at:
http://developer.gnome.org/projects/gup/hig/1.0/de sktop-integration.html#menu-item-names
No. It's true that government employees, if they write code, cannot acquire a copyright. But most code is written by contractors (this is true for SELinux), and they CAN have a copyright. And, they can assign their copyrights to the government (the government CAN own copyright).
There's already such a convention, the "ADV" (advertizing) convention. It's supposed to be affixed in the subject line (I think it should be the FIRST thing, as in "ADV:").
Surprise, surprise! Most spam doesn't follow the convention. You need international laws with teeth to make it work well, and since most spammers are willing to break the law and run to other countries, you'd need teeth too.
There is a potential problem with spam and authentication, but it's not what you think.
There are lots of ways to authenticate, but they tend to not be very automatic and require too much work by users. An alternative approach is described in:
http://www.dwheeler.com/essays/easy-email-sec.html
Here's the quote: "Sadly, you probably don't want to automatically authenticate every message.
That's because spammers would set up bogus servers waiting for your
program to authenticate the message
(using a used-only-once sending email address),
and add you to a ``valid email address'' list if you tried to authenticate it
(and once on, you'll never come off the list no matter what they say)."
Another idea is to start putting lists of legislators' email addresses (as well as email addresses of their major supporters) on web pages so that spammers start spamming them, too. Legislators hire others to read their emails, and they surely have filters (false positives aren't a problem here!), but it could eventually become obvious even to legislators. Especially if you get the personal email addresses (according to many legislatures, it's legal to share the email address with spammers - if they don't want it to be, they'll need to pass a law to make it illegal!).
Another idea: a non-profit organization creates and maintains a database of HASHES of email addresses that do NOT want spam (say MD5 and SHA-1 of canonicalized email addresses, e.g., all lower case; an entire site could be represented by "@mycompany.com"). Anyone can download the database, for a small fee. Anyone can add or remove their email address from the list for FREE (and it must always be free); they just need to subscribe/unsubscribe, with a separate email to confirm (to show that they really did add their email address to the list; entire sites could require "root" or "postmaster" to represent them). Then legislation can be enacted that gives serious $$ penalties to any spam to the "no-spam" list. Capturing the database wouldn't do any good; it would only provide hashes and date/time stamps.
Slashdot Mirror
If you want to learn how to write secure programs for Linux or Unix systems, read my freely-available book, Secure Programming for Linux and Unix HOWTO. You can get it from http://www.dwheeler.com/secure-programs.
What this shows is that if laws were passed that made spam illegal, we'd get a lot less spam. You don't have to enforce every spam case to make an effect; just putting a few spammers in jail or fining them will change the behavior of many others. If not illegal (the best solution), at least require all spam to be marked so that it can be easily filtered. And include all spam, not just commercial spam.
It's worth noting, though, that there is no open source software implementation of the viewer. That's different than PDF, because there are open source implementations of PDF readers and writers (which is why PDF has become so popular - implementations are available literally everywhere, and no one feels that locked in). I think most people don't believe that an open source implementation is a requirement for an open standard, but it does mean that the viewer is not included in many distributions (e.g., Red Hat Linux and Debian have policies specifically discouraging such things). It also means that the viewers sometimes don't work when you upgrade your operating system.
Yes - please, tell the W3C you support their new royalty-free policy for W3C standards. Send email with your "attaboy" message to: www-patentpolicy-comment@w3.org It's not done, this is still a draft.
The biggest issue is, in my mind, use common sense. Make sure you have a better understanding of your current situation (systems and how people use them). In most cases, don't make all the changes at once - plan to do things in stages, test things out before you depend on them, then deploy - and examine how that stage went so you can adjust your plan for the next stage. Maybe you start by replacing a few servers, for example. If you're replacing desktops, maybe you start with just a few systems, or you replace Microsoft Office while keeping Microsoft Windows on a few systems.There's much to be said for incremental changes.
Fundamentally, her process is to make other people pay for her business. That is unacceptable.
The notion that people can "opt-out" is absurd; trying to opt-out of many lists will add you to the "sucker" list, and there's no way for a recipient to know if they'll be opted out or in fact added more.
If you're trying to write secure applications, I suggest taking a look at my book Secure Programming for Linux and Unix HOWTO at http://www.dwheeler.com/secure-programs - it's free, just download and print. I just released the 29 October 2002 (version 3.000) edition.
The problem is, the situation that FORTH is great in is becoming increasingly rare. Most FORTHs still require programmers to constantly think about how to juggle the stack if they receive a number of parameters (yes, there are some extensions). FORTH has essentially no type-checking, and the combination of these two factors means that it's extremely easy to (1) make a mistake and (2) for that mistake to have nasty consequences.
Many program language implementations generate intermediate stack-based code (think Java class files, Python, Perl, etc.); in FORTH, you're writing the stack-based code yourself, so you are essentially writing in an assembly language for a simulated stack-based system. FORTH thus has some of the similar properties as assembler: fewer development system resources are required, but it's more work for the programmer. This isn't completely true; FORTH is definitely much higher-level than the typical assembly language program, but many programs take more work to implement in FORTH than, say, Python (which is also interactive, and it executes a stack-based program, but lets people express code in a more Algol-like way and then TRANSLATES that code into a stack-based approach).
I do think Forth is a good language to learn, because many systems are built on stack-based intermediate languages (Java, C#, Perl, Python), and being able to directly interact with a stack-based language helps to learn how they really work.
An implementation of Forth for 6502 is freely available.
Wake up: the web is about communication. If you conform to open standards, you aid communication, because it means that anyone can reach you. HTML, PNG, etc., all conform to standards (such as those produced by the W3C and IETF). Gratuitous use of non-standard formats is worth complaining about, because when enough complaints get made, the websites either stop using the nonstandard format, or convince enough people to create a standard for it.
It appears that a LOT of readers either don't have or have disabled Flash, and I'm one of them. It might be worth waiting until the website repairs their site into something standards-conforming. HTML + PNG preferred.
There are no font specifications other than a few tables, and the legal mumbo-jumbo at the bottom. If the fonts aren't readable, that's a problem with your browser settings. In Mozilla, select Edit/ Preferences/ Appearances/ Fonts to modify them.
MITRE is well-respected. Technically, it is a Federally Funded Research and Development Center (FFRDC). FFRDCs are non-profit organizations chartered to give unbiased technical advice to the U.S. government.
Qmail is not really an open source software/ free software program. See my paper at http://www.dwheeler.com/oss_fs_why.html for an explanation.
Still, this might help in spite of them. A U.S.-wide law against forged "from" messages from commercial spam would at least dissuade some, especially if it had a stiff penalty. This would make it easier to set up my mailbox so that I raise the priority for people I've talked with before; with stiff penalties, they're less likely to forge friends' addresses.
This would be REALLY good if the federal law also required the "ADV" convention, and nailed down EXACTLY what it means. It's already in some state laws. If I could automatically reject the messages without having to read them all, that would steal my bandwidth and storage, but at least it wouldn't steal my time.
Yeah, not everyone obeys the law, there are offsite systems, etc. But it would be a first step, and some legal tools would make it a lot easier to employ technical ones. For example, there's no point in tracking down offenders if they've broken no law. Also, the evasion techniques make it much clearer that they ARE breaking the law. Finally, if nearly all email from some asian countries are spam, then entire continents can blacklist them... and that would be a real wake-up call that would reduce spam. So, a few basic laws can really enable technological solutions, so even a feeble law might help.
I've written down a few comments and anti-spam techniques at http://www.dwheeler.com/esssays/stopspam.html; some of you may find them interesting. I know many others are interested in stemming this outrageous flood of spam that is threatening to steal the ability to receive email.
I believe patent law does have some statements about turning it into practice; hopefully someone with more legal knowledge can clarify that. However, I'm sure Mr. Green can implement the technique and sell the product in limited editions (e.g., 3 copies total worldwide), which would probably satisfy any such requirement.
Somewhat similar capabilities also exist for Linux. The Linux Security Module (LSM) effort adds the ability to insert an additional access control mechanism into a Linux kernel (without a recompile). You can then at run-time insert a modules to add finer control over privileges. Several modules exist, such as SELinux. This approach makes it easier to experiment or create your own access control policy. There are various LSM modules already available; none of them are exactly like this, but most provide finer-grain control. There are definitely technical differences, too, but describing those differences would take up WAY too much space here.
There are definitely situations where finer control over privileges is very desirable. Which way is the best way is very much in doubt. The good thing about finer control is that you can give a program only the privileges it needs. The bad thing about finer control is that it takes more work to set up. "Learning" from program runs helps, but it doesn't fully solve the problem - there are usually many conditions that aren't triggered by simple runs yet can happen in real life.
Anyway, this kind of capability is a good thing. It will be interesting to see what happens over the years as people try out various ways to add finer control - the trick will be to add finer control while still keeping the system easy to administrate. It's not even clear that there is a single solution.
My PRIMARY utility for a PDA is for electronic books, so this thing is worthless for me. I've found that the calendar/ phone book / to-do applications are fun but really aren't better than paper. I suspect that many others will come to the same conclusion.
They will need to drop the price significantly (say, to $5-$10) for this to be worthwhile.
Personally, I think trying to make it so users DON'T KNOW NOR CARE what the underlying libraries are makes sense, the resulting system will become much easier to use. If the KDE apps are crippled, then that's a problem, but I'd expect that to be fixed in future releases. More importantly, it's likely that this process will encourage more reuse between the groups, and that's a good thing.
For another book on writing secure programs, see my "Secure Programming for Linux and Unix HOWTO" at http://www.dwheeler.com/secure-programs. It's free, and it covers both web applications and non-web applications.
People buy CDs, DVDs, tapes, and videocassettes because they want the freedom to do a lot of things with that material. They want watch/listen to the material as many times as they want to, whenever they want to. They want to use whatever media they have to watch/listen to it themselves (e.g., be able to copy CDs to their personal tapes so they can hear the CD on a tape deck, create their own CD mix, create an MP3 so they can hear music on their laptop while leaving the CD-ROM drive free for something else). They want to avoid the risk of extra fees and possible loss (assuming their houses aren't physically damaged). They want to do many other things with it, too, and as long as it's only for their personal use, they need to have the freedom to do so.
Instead, many of the current electronic distribution techniques for music and videos have extremely consumer-hostile policies. For example, many of the current RICO approaches want you to pay monthly subscriptions, with no additional services and no guarantee of a stable price (I think we can safely assume that if these approaches caught on, the cost would ramp up steeply). Since the legal online distribution system is WORSE for the consumer than the alternatives, few consumers want it.
Of course, if the music/video overlords will not provide their content reasonably over the Internet, what's left for the Internet to legitimately do? There are lots of other useful services on the Internet: email, web surfing, and so on. It would be NICE to have higher bandwidth for that, but clearly most people believe it's not worth the extra money and trouble. Obviously, things vary, but it IS more money in many places - not everyone pays AOL price$ for an ISP, and broadband is outrageously expensive in many places.
Now I'm sure others here will disagree with me, but Napster-like systems of mass sharing are wrong. RIAA vs. Napster was simply the case of two evils pitted against each other. RIAA is very hostile to artists, really (the represent music publishers, not artists), but Napster was even worse. However, the growth of Napster and P2P systems is really an evidence that the current publishers "don't get it," and that is the real problem.
The fundamental problem is that the music and video industry, instead of embracing a technology that could make them a ton of money, are sticking their heads in the sand and trying to uninvent technology instead. Trying to invent totally "non-copying" systems results in incredibly invasive and privacy-destroying systems which don't really work. Trying to make digital media uncopying is, as Bruce S. notes, like trying to make water not wet, and someone with a videocamera aimed at a screen can undo lots of fancy mechanisms. But even worse, such systems fundamentally subvert "fair use": copyright law is a grant to authors, under the condition that they permit fair use; if fair use is taken away, then clearly those organizations should forfeit copyright protection as well.
A simple watermarking scheme that deals with the casual pirate would be better; it would permit fair use, and deal with piracy as under current law. The non-casual pirates are already creating copies, and will continue to do so regardless of the Digital Restrictions Management (DRM) techniques used. It would be better to use the technology available to make it impossible for the pirates to compete, by providing a legitimate service that customers actually want to use. That means charging less for the material (you'll still make more money, since many overheads disappear and people can impulse buy more quickly), and making it trivial to obtain the material.
Of course, since the publishers essentially own the souls of most artists, if publishers will not release their material under consumer-friendly terms, they obviously can do so. But that will just mean what's already happening: consumers will not use their elecronic distribution mechanisms. Unsigned artists are already making their material available in other ways; it's conceivable that eventually most material will be released by artists instead of the current publishers, at which points the publishers suddenly discover they're irrelevant. It's unclear that this will happen, but it's a possibility. I rather hope it does; it would serve these companies right for ignoring their customers.
My two cents.
Actually, I think this is a GOOD thing, as long as other distributions can also pick up the defaults. Currently working with some programs is jarring - and thus painful to users. However, I think just having a generic function description in the menus is a mistake. It's important to modify the menus so that they show not just the function ("Web Browser"), but also the name of the program ("Mozilla"). Yes, it's longer, but it is MORE confusing to users when the programs change or when they update to a different program. When I see "Mozilla Web Browser" and "Galeon Web Browser", I can understand both (a) they do the same basic thing, but (b) will do it somewhat differently. You could swap the order if necessary "Web Browser (Mozilla)" if you'd prefer, as long as it was done consistently throughout the system. This is already a requirement in the GNOME User Interface Guidelines; you can see the whole document at: http://developer.gnome.org/projects/gup/hig/1.0/ And this specific guidance at: http://developer.gnome.org/projects/gup/hig/1.0/de sktop-integration.html#menu-item-names
No. It's true that government employees, if they write code, cannot acquire a copyright. But most code is written by contractors (this is true for SELinux), and they CAN have a copyright. And, they can assign their copyrights to the government (the government CAN own copyright).
Surprise, surprise! Most spam doesn't follow the convention. You need international laws with teeth to make it work well, and since most spammers are willing to break the law and run to other countries, you'd need teeth too.
There are lots of ways to authenticate, but they tend to not be very automatic and require too much work by users. An alternative approach is described in: http://www.dwheeler.com/essays/easy-email-sec.html
Here's the quote: "Sadly, you probably don't want to automatically authenticate every message. That's because spammers would set up bogus servers waiting for your program to authenticate the message (using a used-only-once sending email address), and add you to a ``valid email address'' list if you tried to authenticate it (and once on, you'll never come off the list no matter what they say)."
Another idea is to start putting lists of legislators' email addresses (as well as email addresses of their major supporters) on web pages so that spammers start spamming them, too. Legislators hire others to read their emails, and they surely have filters (false positives aren't a problem here!), but it could eventually become obvious even to legislators. Especially if you get the personal email addresses (according to many legislatures, it's legal to share the email address with spammers - if they don't want it to be, they'll need to pass a law to make it illegal!).
Another idea: a non-profit organization creates and maintains a database of HASHES of email addresses that do NOT want spam (say MD5 and SHA-1 of canonicalized email addresses, e.g., all lower case; an entire site could be represented by "@mycompany.com"). Anyone can download the database, for a small fee. Anyone can add or remove their email address from the list for FREE (and it must always be free); they just need to subscribe/unsubscribe, with a separate email to confirm (to show that they really did add their email address to the list; entire sites could require "root" or "postmaster" to represent them). Then legislation can be enacted that gives serious $$ penalties to any spam to the "no-spam" list. Capturing the database wouldn't do any good; it would only provide hashes and date/time stamps.
Anyway, just an idea.