Once there was something called a "phone book". The "Yellow pages" let you do geographic searches based on keywords; the "White pages" let you do geographic searches based on name. You could do this by hand, or dial an operator to do this search for you.
I like the GPLv3 in its "final draft" form. I expect to switch my GPL'ed projects to it (which will be easy, since they already say "GPLv2 or later"; just change "2" to "3"). Obviously others like GPLv3 too. So many people will use GPLv3, and thus GPLv3 will be a success. For those who wanted a different outcome: Sorry.
Clearly people who don't like GPLv2 won't like GPLv3, but why would you expect anything different? And those who have been most outspoken against earlier drafts of GPLv3, like Linus Torvalds, seem to be much happier with the latest version (they might not use it, but it's hard to claim they're alienated). And kernel developers are certainly not uniform (in anything!); Torvalds didn't like earlier drafts, but Alan Cox has spoken very positively about the GPLv3. The Apache License 2.0 compatibility and internationalization are enough reasons all by themselves to upgrade. And I don't have any trouble with the new "must be able to change the software" rules; if I start a project, I want to be able to use arbitrary later versions extended by others, and I can't without these new GPLv3 clauses for anti-Tivoization and anti-DRM. Yes, in some cases there are other conditions I want more instead, but in those cases I'd use a different license.
I don't license everything under the GPL, because I have different motives for different projects. Indeed, over my lifetime I've licensed stuff under the GPL, LGPL, MIT, and proprietary licenses, depending on my circumstances. But if you're trying to make sure that you get to use future versions of a project you start or contribute to, the GPLv3 is a pretty good way to get there. It certainly isn't "alienating" me. Instead, I now have a new choice, one that better reflects my goals when I choose to release code under the GPL.
"Newsflash"! A vendor of proprietary software (BMC) and the Apache foundation (who sponsor a BSD-style license, instead of the GPL) don't plan to use the GPL version 3. Um, sure. And the sun rises in the east, too.
This really doesn't have much to do with anything, because both groups wouldn't use any revision of the GPL. Their "survey" seems to be simply discussions with other people just like themselves; they simply found that people who wouldn't use GPLv2 wouldn't use GPLv3 either. Big deal. The question is, will many developers who currently use or strongly consider the GPLv2 be willing to use GPLv3? If so, it's a success. If no one uses it, it isn't. Not everyone has to like it.
Since the FSF is the copyright holder of a lot of important projects, they can switch to GPLv3. All by itself that will mean that the GPLv3 will be used in many projects, and so the GPLv3 will be lots more successful than the vast majority of licenses. So this "death" is silly; it's a foregone conclusion that GPLv3 will be more successful than most licenses. In practice, I expect most GPLv2 projects to move to GPLv3; the internationalization and Apache 2.0 license compatibility are great, and the threats from patent deals and Tivoization mean that many who liked GPLv2 will like GPLv3 even more.
Wow, a lot of text to paper over the obvious problem: ATI is still failing to release OSS drivers for Linux. The paper describes all the ways that ATI tries to avoid releasing the drivers, and how they all fail to solve the problem. ATI has testing processes, etc., sure - but later on, when X.org and the Linux kernel change, there's no way for me to update the driver - so I have to hope that they will EVENTUALLY do so (leaving me vulnerable to any security problems) OR throw away the ATI card.
Dell has solved this problem by including the Intel stuff instead for their Linux offering. It's time for ATI to release their drivers as OSS.
Here's the LGPLv3 work
on
GPLv2 Vs. GPLv3
·
· Score: 3, Informative
Check your facts. Here's more info about the LGPLv3. The LGPL has gotten less discussion; it's based on the GPL, so once the GPL is changed the LGPL basically follows suit.
No. DRM says that when you leave your house, someone ELSE controls the key and locks your door, and decides under what conditions you're allowed to have your key back to enter your own house. This ruling just says that if the key to your house is widely available on the Internet, you're allowed to use that widely-available key to enter your own house.
I can easily see this argument as a pretty strong argument in U.S. courts. Not even good lawyers can predict what U.S. courts will do in situations like this, but I'd expect judges to listen to that argument with a lot of sympathy. It makes a lot of sense: "if everyone knows how to break it, it ain't effective".
IANAL, and what happens in Finland does NOT automatically get accepted in the U.S. But what Finland did is exactly what U.S. courts often have to do: when there's a term in the law that is unclear, they end up having to try to figure out what it means, and then write down a definition to clarify it for others. This isn't a bad definition of when something is NOT effective.
The fundamental problem is that a WORKING DNSSEC specification hasn't been available. We really DO need what DNSSEC was intended to provide - i.e., if you type in a DNS name, your browser should be able to automatically get its data (IP address, etc.) and use crypto to ensure that it really is the authentic, unmodified data. The problems in DNS have been publicly known since at least 1995.
But a USEFUL spec hasn't been available until perhaps this year. The real story of DNSSEC is a painful story of attempt after attempt, all of them failing to meet the need.
In 1997 they released RFC 2065, which really didn't work, and in 1999 they released RFC 2535 and thought they were done.
But RFC 2535 was completely impractical; it had an absurdly complicated siz-message protocol to do key exchanges for a child, and changes in a parent required all child keys to be re-signed (if the ".com" zone changed its public key, it would have to send 22 million records (because it would need to update all of the signatures in all of its children)). RFC 2535 was fine for a toy local network, but completely useless for the Internet. This should have been obvious, but the DNS group didn't accept that this was a problem until 2001 or so.
They then made a big change to DNSSEC, to use "delegation signer (DS) resource records" to provide an additional level of indirection at delegation points between a parent and child zone. In the new approach, when a child's master public key changes, instead of having to have six messages for every record in the child, there is one simple message: the child sends the new public key to its parent (signed, of course). Parents simply store one master public key for each child; this is much more practical. This means that a little data is pushed to the parent, instead of massive amounts of data being exchanged between the parent and children. This does mean that clients have to do a little more work when verifying keys. More specifically, verifying a DNS zone's KEY RRset requires two signature verification operations instead of the one required by RFC 2535 (there is no impact on the number of signatures verified for other types of RRsets). Most view this as a small price to pay, since it changes DNSSEC so it is more practical to deploy.
But the DNSSEC developers were STILL under the illusion that all DNS data, transitively, is public data.
Any peek at a book on how to configure DNS systems clearly states that it's best practice to hide as much data about your
organization's internals as you can.
But the DNSSEC members didn't understand that, and explicitly permitted zone walking... making it impossible to hide
private data. As far as most users were concerned, DNSSEC got rid of one security problem by creating a new one: loss of confidentiality.
Even worse, when early adopters tried out DNSSEC and told the EITF group that they would NOT use DNSSEC until this was fixed, their comments were ignored.
Finally, DENIC had to explain to the IETF explaining that DNSSEC's zone enumeration issue violates Germany's Federal Data Protection Act, and that other European countries have similar privacy laws forbidding the public release of certain kinds of information.
In other words, it is ILLEGAL to deploy DNSSEC in many countries, because it forces private information to become
public information.
So they finally decided to create NSEC3, an extension to DNSSEC that should reduce the zone walking problem and hopefully make DNSSEC reasonable (and legal!) to deploy. But NSEC3 is wet behind the ears.
Is there really any shock that a specification wasn't widely deployed when (1) technical problems made it impossible to deploy on the internet, and (2) fundamental security problems (like zone enumeration) made it illegal to deploy while creating new security problems?
More info on DNSSEC is on Wikipedia.
Improving Lisp readability: sweet-expressions
on
Lisp and Ruby
·
· Score: 1
Lisp has some nice properties, but it's traditionally had a BIG downside: Lisp code is painfully hard to read. Even Paul Graham admits that Lisp's inability to handle infix operators out-of-the-box is a problem, and thinks that syntactically-important indentation could help make Lisp easier to read.
I've created a variant of Lisp's native s-expression format called "sweet-expressions". A sweet-expression reader can read typical s-expressions as-is, but it also lets you use indentation, infix, and more traditional function notation. Yet you can still use all of Lisp's macro power, including quasiquotes and so on. Programs are still lists, it's just that the lists are now readable.
There's a standard way to eliminate the rewrite: get the module into the kernel, where others will help maintain it. The kernel _HAS_ a stable API - it's the interface to userland. The kernel also has a standard way for drivers to interface with other drivers - it's submitting source code. In other words, there _IS_ a standard internal API for kernel modules; it's called "C".
Clearly, you want to have a proprietary driver. Thus, you want to do something that the developers have ACTIVELY and CLEARLY stated that they are working against, and give no quarter for. You obviously don't like that, and that's your right. But you didn't write their code, nor pay for it, so they are not responsible for your desires... and that is their right.
This is very different from the Windows situation. Microsoft has kept some APIs quiet, and even the very existance of some APIs. In contrast, this Linux kernel policy has been clear for over a decade. You may not like it, but you have no right to complain; this policy was certainly there before you decided to write a line of code. As long as an organization makes clear what the rules are, then you try to work against them at your peril.
Yes, a stable internal API of the kernel would be a possibility. Windows, for example, has one. But most Windows crashes are from BAD DRIVERS; the drivers cannot be fixed, and the Windows interface can't be fixed either. That's not good evidence that this would be a GOOD thing for users. The reliability of Linux is actually pretty good evidence that their process actually works better for end-users.
If the bank requires you to use Internet Explorer, then yes, the bank should pay you if you've been taken in by a scam. Why? Because the bank did not make it possible to take reasonable care.
If you've ever been awake in the last several years, you'll notice that one of the primary ways that people get exploited is through Internet Explorer (IE, aka Internet Exploiter).
Scanit's Browser Security Test group found that in 2004, 98% of time Internet Explorer was vulnerable to dangerous known remote attacks, with no patch available to prevent it, compared to 17% for Opera and 15% for Mozilla/Firefox. There were only 7 days in 2004 where Internet Explorer could be safely used (where patches were available for all publicly-known worst-case vulnerabilities).
That's just one study; study after study shows that Internet Explorer should not be used for normal browsing.
Papers like my
Securing Microsoft Windows (for Home and Small Business Users) note that one of the most important
ways to improve the security of Windows (while still using it) is to replace IE and Outlook (the most insecure programs around) with something else (such as Firefox and Thunderbird). Nothing's perfect, but when you junk the programs with the worst security, your security gets better - isn't that obvious?
Many banks are starting to wake up to the fact that people are using other browsers. But while most other sites now work fine, banks are some of the last people to support Internet standards, and instead some still insist on vendor-specific codes... using the browser most dangerous to use.
So, let's hit 'em in the pocketbook. If banks won't let you take reasonable care by allowing you to select a secure browser, then they should be held responsible for forbidding customers from taking reasonable care.
Python, Javascript. Less common: Logo, Squeek...
on
Why Johnny Can't Code
·
· Score: 2, Insightful
This is bogus. There are many languages that are "easy to learn and give you a response quickly".
For example, Python is a very good language for teaching the basics of programming, and it's really simple to learn. Javascript also works.
The old BASIC that he probably remembers (e.g., what ran on Apple IIs, etc.) was actually pretty nasty; functions didn't have parameters, loops were primitive, you couldn't create your own datatypes.
You had to UNLEARN a lot of stuff. Yes, modern BASICs are better, but they're now competing with many other also-good languages.
A "perfect" solution isn't really needed. Indeed, given Wikipedia's stellar success, you could argue that the current situation is already good enough. People already use Wikipedia, and make improvements to it... and since it has many readers and writers, it's a success by any mreasure.
But I think that discussing ways to improve Wikipedia is very valuable; only by proposing ideas and trying them out can things get better.
This is not a user reputation scheme; it simply colors text based on how many edits the text has survived unchanged. If the text is part of an edit war, then it'll stay "recent" (e.g., red in his scheme). As it survives more and more edits, it will become different colors until finally it's black.
Actually, I like this idea. There are refinements possible too (maybe after many reads, by many different people, should SLIGHTLY increase its rank).
Maybe it'll work, maybe it won't. But it seems worth trying out.
The twist in this story that really makes this newsworthy is that Dunn's investigators snooped on reporter's records, too.
That is potentially a huge problem. Reporters can only get accurate, good stories if they can get accurate and confirmable information. By getting their private data, you potentially subvert journalism itself, because if that's permitted, no one who knows anything will be willing to talk to reporters.
It's also amazingly stupid. Mark Twain said something like, "Never argue with a man who buys ink by the barrel." I think reporters are (rightly!) feeling threatened by this turn of events, and so it's not surprising at all that it's gotten so much press. The press work hard to take of themselves. Often that's scary, but in this case I think it's at least partly justified.
Parent is correct - this license is not an open source software license, because it descriminates against use. It's also not a Free Software license, because Freedom 0 in the Free Software Definition is "The freedom to run the program, for any purpose".
Also, I hope that they don't use TCP/IP or the Internet, because the basic idea of packet-switching, the TCP/IP protocol, and the basic Internet architecture were all funded by the military (through DARPA/ARPA). Using TCP/IP to distribute or implement this thing would be hypocritical, so I'm glad they aren't doing that:-).
There's a technique for completely countering the "Trusting Trust" attack,
called "Diverse double-compiling". See
my web page on
countering trusting trust through diverse double-compiling, which includes
a link to a paper describing how to do it, and an example where it's been done.
I agree that many of those who use Win98 will simply stay put.
The Win98 system still does the job they bought it for, so
there's no reason to toss it. And these old machines would
require significant money to upgrade components (memory, disk)
to run something newer... at which point, you may as well
buy a new machine.
Sooner or later many of them will replace their systems
for a newer one, often because they want to run some software not
available for Win98, or because some component breaks.
What then? They'll toss their machines, and then an interesting
thing happens...
Stats vary, but at least 20% of
all PCs run Win98, if not more, so that's a LOT of machines
that are getting tossed - free computers!!
Who would want a bunch of old Win98 machines?
I suspect the people most interested would be
(1) the poor, and (2) the computer-savvy.
Many of the computer-savvy will WANT to put Linux on them,
to do various odd jobs, and since Win98
is unsupported, some of the poor might be willing to go
this way too.
It's true that Fedora Core,
SuSE, and Ubuntu don't work well on old systems, but there
are other distros that work well on old/tiny systems.
And I expect Red Hat's work on "One Laptop per Child" to
result in the ability of Fedora Core to skinny down, too.
I can easily see something like "rise of the zombies"...
hordes of big, loud, and obsolete machines spreading
around the world, running distros designed for them.
No guarantee it'll happen, but it might happen...
This article starts with the same false premise that other articles make, except in this case the author should know better. The article tries to paint a difference between "commercial" and "open source" software - yet later on admits that there are major commercial companies developing open source software! No one that clear thinking cannot occur, they can't even admit in their terminology that there are commercial companies doing this. The usual terms are "proprietary" (or closed source) vs. "open source software" (or FLOSS).
That world disappered around 1998. Many major FLOSS projects are almost entirely developed by commercial entities, including the Linux kernel, Apache, and so on.
In general, using "commercial" as an antonym for "open source" is a good tip-off that (1) the author is clueless, or (2) the author has an anti-open-source agenda.
Alloy is a cool tool, if it does something you want done. But nobody should be fooled into thinking that you can just run Alloy and suddenly your code is perfect. Alloy just helps you check out a model based on set theory, etc... it's a long distance from models like that to the actual code.
If you like this, you might also like my definitive four fours answer key.
The goal of the four fours problem is to find a mathematical expression for every integer from 0 to some maximum positive integer, using only common mathematical symbols and exactly four fours (no other digits are allowed). For example, zero is 44-44, one is 44/44, 2 is 4/4+4/4, 3 is (4+4+4)/4, and so on.
The Internet, as a practical matter, was developed as OSS. TCP, UDP, IP, and DNS were essentially OSS efforts. The World Wide Web was as well -- in particular, most servers have been OSS since its data's been available. "Rsync" is a clever way to keep files synchronized, widely used, and is OSS. Tcl, Perl, Python, and PHP essentially created the web "scripting languages" domain, all OSS.
As with any story, it's all complicated; some of the early efforts were BSD-licensed, so proprietary versions started appearing later (obscuring the OSS origins).
But anyone who thinks that OSS only copies pre-existing work is ignoring the evidence.
The primary goal of Wikipedia is to capture human knowledge. So Wales found an error and fixed it, big deal, that's the whole point of Wikipedia -- to allow multiple people to review it, and fix it until it's correct. He's told other people to go fix errors, even if it's in their own biography, so he's just sticking to his principles. And as the parent poster notes, the "don't write your own" is merely a guideline; there's a larger principle of "there are no rules" if they interfere with the larger goals of Wikipedia. And the edits sound like factual repair, not wholesale writing by himself.
Frankly, I don't have a problem with someone contributing to their biography. Talk about authoritative sources! Sure, they're biased, like everyone else, but others then have a chance to edit what's done later.
If Wales wanted to do this secretly, he could have logged in anonymously. Heck, it's his site; he could have forged an entry from ANYONE to edit it. Instead, he made it clear that HE did it. Sounds like someone honest, not someone who is dishonest.
Before you criticize, make sure you understand it.
Problem is, few sites take advantage of kids.us; nearly all kid sites are NOT in kids.us. One problem may be that it appears there's a single monopolist in control of the domain registration; that means higher domain prices, and more importantly, any kid site in kids.us would put their entire business under the control of that monopolist.
There may be other problems, too.
Which is too bad. I think the basic idea of kids.us is actually sound. We need to find a way to eliminate risks to the organizations signing up to kids.us, and and then encourage them to use it.
If there were a "safe for the kids" area on the Internet, perhaps some of the other concerns would be reduced.
Slashdot Mirror
Say it again: "No software patents".
Clearly people who don't like GPLv2 won't like GPLv3, but why would you expect anything different? And those who have been most outspoken against earlier drafts of GPLv3, like Linus Torvalds, seem to be much happier with the latest version (they might not use it, but it's hard to claim they're alienated). And kernel developers are certainly not uniform (in anything!); Torvalds didn't like earlier drafts, but Alan Cox has spoken very positively about the GPLv3. The Apache License 2.0 compatibility and internationalization are enough reasons all by themselves to upgrade. And I don't have any trouble with the new "must be able to change the software" rules; if I start a project, I want to be able to use arbitrary later versions extended by others, and I can't without these new GPLv3 clauses for anti-Tivoization and anti-DRM. Yes, in some cases there are other conditions I want more instead, but in those cases I'd use a different license.
I don't license everything under the GPL, because I have different motives for different projects. Indeed, over my lifetime I've licensed stuff under the GPL, LGPL, MIT, and proprietary licenses, depending on my circumstances. But if you're trying to make sure that you get to use future versions of a project you start or contribute to, the GPLv3 is a pretty good way to get there. It certainly isn't "alienating" me. Instead, I now have a new choice, one that better reflects my goals when I choose to release code under the GPL.
This really doesn't have much to do with anything, because both groups wouldn't use any revision of the GPL. Their "survey" seems to be simply discussions with other people just like themselves; they simply found that people who wouldn't use GPLv2 wouldn't use GPLv3 either. Big deal. The question is, will many developers who currently use or strongly consider the GPLv2 be willing to use GPLv3? If so, it's a success. If no one uses it, it isn't. Not everyone has to like it.
Since the FSF is the copyright holder of a lot of important projects, they can switch to GPLv3. All by itself that will mean that the GPLv3 will be used in many projects, and so the GPLv3 will be lots more successful than the vast majority of licenses. So this "death" is silly; it's a foregone conclusion that GPLv3 will be more successful than most licenses. In practice, I expect most GPLv2 projects to move to GPLv3; the internationalization and Apache 2.0 license compatibility are great, and the threats from patent deals and Tivoization mean that many who liked GPLv2 will like GPLv3 even more.
The GPL is the world's most popular OSS/FS license, by far, and it's critically important to use a GPL-compatible license (even if you don't use the GPL yourself). The GPL is popular for a reason. Note, for example, that when the Wine project switched from a BSD-style license to the LGPL, development began to pick up at a greater pace (more patches began to appear, the leader Alexandre made more CVS commits, and more applications were reported to work). A lot of code producers prefer copylefting licenses like the GPL (not all, but many do).
The GPL is not a license for all possible circumstances. Sure. But no license is.
Dell has solved this problem by including the Intel stuff instead for their Linux offering. It's time for ATI to release their drivers as OSS.
Check your facts. Here's more info about the LGPLv3. The LGPL has gotten less discussion; it's based on the GPL, so once the GPL is changed the LGPL basically follows suit.
No. DRM says that when you leave your house, someone ELSE controls the key and locks your door, and decides under what conditions you're allowed to have your key back to enter your own house. This ruling just says that if the key to your house is widely available on the Internet, you're allowed to use that widely-available key to enter your own house.
I can easily see this argument as a pretty strong argument in U.S. courts. Not even good lawyers can predict what U.S. courts will do in situations like this, but I'd expect judges to listen to that argument with a lot of sympathy. It makes a lot of sense: "if everyone knows how to break it, it ain't effective". IANAL, and what happens in Finland does NOT automatically get accepted in the U.S. But what Finland did is exactly what U.S. courts often have to do: when there's a term in the law that is unclear, they end up having to try to figure out what it means, and then write down a definition to clarify it for others. This isn't a bad definition of when something is NOT effective.
But a USEFUL spec hasn't been available until perhaps this year. The real story of DNSSEC is a painful story of attempt after attempt, all of them failing to meet the need.
In 1997 they released RFC 2065, which really didn't work, and in 1999 they released RFC 2535 and thought they were done. But RFC 2535 was completely impractical; it had an absurdly complicated siz-message protocol to do key exchanges for a child, and changes in a parent required all child keys to be re-signed (if the ".com" zone changed its public key, it would have to send 22 million records (because it would need to update all of the signatures in all of its children)). RFC 2535 was fine for a toy local network, but completely useless for the Internet. This should have been obvious, but the DNS group didn't accept that this was a problem until 2001 or so.
They then made a big change to DNSSEC, to use "delegation signer (DS) resource records" to provide an additional level of indirection at delegation points between a parent and child zone. In the new approach, when a child's master public key changes, instead of having to have six messages for every record in the child, there is one simple message: the child sends the new public key to its parent (signed, of course). Parents simply store one master public key for each child; this is much more practical. This means that a little data is pushed to the parent, instead of massive amounts of data being exchanged between the parent and children. This does mean that clients have to do a little more work when verifying keys. More specifically, verifying a DNS zone's KEY RRset requires two signature verification operations instead of the one required by RFC 2535 (there is no impact on the number of signatures verified for other types of RRsets). Most view this as a small price to pay, since it changes DNSSEC so it is more practical to deploy.
But the DNSSEC developers were STILL under the illusion that all DNS data, transitively, is public data. Any peek at a book on how to configure DNS systems clearly states that it's best practice to hide as much data about your organization's internals as you can. But the DNSSEC members didn't understand that, and explicitly permitted zone walking... making it impossible to hide private data. As far as most users were concerned, DNSSEC got rid of one security problem by creating a new one: loss of confidentiality. Even worse, when early adopters tried out DNSSEC and told the EITF group that they would NOT use DNSSEC until this was fixed, their comments were ignored. Finally, DENIC had to explain to the IETF explaining that DNSSEC's zone enumeration issue violates Germany's Federal Data Protection Act, and that other European countries have similar privacy laws forbidding the public release of certain kinds of information. In other words, it is ILLEGAL to deploy DNSSEC in many countries, because it forces private information to become public information.
So they finally decided to create NSEC3, an extension to DNSSEC that should reduce the zone walking problem and hopefully make DNSSEC reasonable (and legal!) to deploy. But NSEC3 is wet behind the ears.
Is there really any shock that a specification wasn't widely deployed when (1) technical problems made it impossible to deploy on the internet, and (2) fundamental security problems (like zone enumeration) made it illegal to deploy while creating new security problems? More info on DNSSEC is on Wikipedia.
If you subscribe to Linux Weekly News (LWN), LWN has an analysis article about the GPL3.
I'd add a computer algebra system, like Maxima (with its wxMaxima front-end) or Yacas. Very cool capabilities. Wikipedia's list of computer algebra systems gives lots of links to more info.
I've created a variant of Lisp's native s-expression format called "sweet-expressions". A sweet-expression reader can read typical s-expressions as-is, but it also lets you use indentation, infix, and more traditional function notation. Yet you can still use all of Lisp's macro power, including quasiquotes and so on. Programs are still lists, it's just that the lists are now readable.
See http://www.dwheeler.com/readable/ for more info.
Clearly, you want to have a proprietary driver. Thus, you want to do something that the developers have ACTIVELY and CLEARLY stated that they are working against, and give no quarter for. You obviously don't like that, and that's your right. But you didn't write their code, nor pay for it, so they are not responsible for your desires... and that is their right.
This is very different from the Windows situation. Microsoft has kept some APIs quiet, and even the very existance of some APIs. In contrast, this Linux kernel policy has been clear for over a decade. You may not like it, but you have no right to complain; this policy was certainly there before you decided to write a line of code. As long as an organization makes clear what the rules are, then you try to work against them at your peril.
Yes, a stable internal API of the kernel would be a possibility. Windows, for example, has one. But most Windows crashes are from BAD DRIVERS; the drivers cannot be fixed, and the Windows interface can't be fixed either. That's not good evidence that this would be a GOOD thing for users. The reliability of Linux is actually pretty good evidence that their process actually works better for end-users.
If you've ever been awake in the last several years, you'll notice that one of the primary ways that people get exploited is through Internet Explorer (IE, aka Internet Exploiter). Scanit's Browser Security Test group found that in 2004, 98% of time Internet Explorer was vulnerable to dangerous known remote attacks, with no patch available to prevent it, compared to 17% for Opera and 15% for Mozilla/Firefox. There were only 7 days in 2004 where Internet Explorer could be safely used (where patches were available for all publicly-known worst-case vulnerabilities). That's just one study; study after study shows that Internet Explorer should not be used for normal browsing.
Papers like my Securing Microsoft Windows (for Home and Small Business Users) note that one of the most important ways to improve the security of Windows (while still using it) is to replace IE and Outlook (the most insecure programs around) with something else (such as Firefox and Thunderbird). Nothing's perfect, but when you junk the programs with the worst security, your security gets better - isn't that obvious?
Many banks are starting to wake up to the fact that people are using other browsers. But while most other sites now work fine, banks are some of the last people to support Internet standards, and instead some still insist on vendor-specific codes... using the browser most dangerous to use.
So, let's hit 'em in the pocketbook. If banks won't let you take reasonable care by allowing you to select a secure browser, then they should be held responsible for forbidding customers from taking reasonable care.
This is bogus. There are many languages that are "easy to learn and give you a response quickly".
For example, Python is a very good language for teaching the basics of programming, and it's really simple to learn. Javascript also works.
The old BASIC that he probably remembers (e.g., what ran on Apple IIs, etc.) was actually pretty nasty; functions didn't have parameters, loops were primitive, you couldn't create your own datatypes. You had to UNLEARN a lot of stuff. Yes, modern BASICs are better, but they're now competing with many other also-good languages.
But I think that discussing ways to improve Wikipedia is very valuable; only by proposing ideas and trying them out can things get better.
This is not a user reputation scheme; it simply colors text based on how many edits the text has survived unchanged. If the text is part of an edit war, then it'll stay "recent" (e.g., red in his scheme). As it survives more and more edits, it will become different colors until finally it's black.
Actually, I like this idea. There are refinements possible too (maybe after many reads, by many different people, should SLIGHTLY increase its rank). Maybe it'll work, maybe it won't. But it seems worth trying out.
The twist in this story that really makes this newsworthy is that Dunn's investigators snooped on reporter's records, too. That is potentially a huge problem. Reporters can only get accurate, good stories if they can get accurate and confirmable information. By getting their private data, you potentially subvert journalism itself, because if that's permitted, no one who knows anything will be willing to talk to reporters.
It's also amazingly stupid. Mark Twain said something like, "Never argue with a man who buys ink by the barrel." I think reporters are (rightly!) feeling threatened by this turn of events, and so it's not surprising at all that it's gotten so much press. The press work hard to take of themselves. Often that's scary, but in this case I think it's at least partly justified.
Also, I hope that they don't use TCP/IP or the Internet, because the basic idea of packet-switching, the TCP/IP protocol, and the basic Internet architecture were all funded by the military (through DARPA/ARPA). Using TCP/IP to distribute or implement this thing would be hypocritical, so I'm glad they aren't doing that :-).
There's a technique for completely countering the "Trusting Trust" attack, called "Diverse double-compiling". See my web page on countering trusting trust through diverse double-compiling, which includes a link to a paper describing how to do it, and an example where it's been done.
Stats vary, but at least 20% of all PCs run Win98, if not more, so that's a LOT of machines that are getting tossed - free computers!! Who would want a bunch of old Win98 machines? I suspect the people most interested would be (1) the poor, and (2) the computer-savvy. Many of the computer-savvy will WANT to put Linux on them, to do various odd jobs, and since Win98 is unsupported, some of the poor might be willing to go this way too. It's true that Fedora Core, SuSE, and Ubuntu don't work well on old systems, but there are other distros that work well on old/tiny systems. And I expect Red Hat's work on "One Laptop per Child" to result in the ability of Fedora Core to skinny down, too. I can easily see something like "rise of the zombies"... hordes of big, loud, and obsolete machines spreading around the world, running distros designed for them. No guarantee it'll happen, but it might happen...
That world disappered around 1998. Many major FLOSS projects are almost entirely developed by commercial entities, including the Linux kernel, Apache, and so on.
In general, using "commercial" as an antonym for "open source" is a good tip-off that (1) the author is clueless, or (2) the author has an anti-open-source agenda.
Alloy is a cool tool, if it does something you want done. But nobody should be fooled into thinking that you can just run Alloy and suddenly your code is perfect. Alloy just helps you check out a model based on set theory, etc... it's a long distance from models like that to the actual code.
If you like this, you might also like my definitive four fours answer key. The goal of the four fours problem is to find a mathematical expression for every integer from 0 to some maximum positive integer, using only common mathematical symbols and exactly four fours (no other digits are allowed). For example, zero is 44-44, one is 44/44, 2 is 4/4+4/4, 3 is (4+4+4)/4, and so on.
The Internet, as a practical matter, was developed as OSS. TCP, UDP, IP, and DNS were essentially OSS efforts. The World Wide Web was as well -- in particular, most servers have been OSS since its data's been available. "Rsync" is a clever way to keep files synchronized, widely used, and is OSS. Tcl, Perl, Python, and PHP essentially created the web "scripting languages" domain, all OSS. As with any story, it's all complicated; some of the early efforts were BSD-licensed, so proprietary versions started appearing later (obscuring the OSS origins). But anyone who thinks that OSS only copies pre-existing work is ignoring the evidence.
Frankly, I don't have a problem with someone contributing to their biography. Talk about authoritative sources! Sure, they're biased, like everyone else, but others then have a chance to edit what's done later.
If Wales wanted to do this secretly, he could have logged in anonymously. Heck, it's his site; he could have forged an entry from ANYONE to edit it. Instead, he made it clear that HE did it. Sounds like someone honest, not someone who is dishonest.
Before you criticize, make sure you understand it.
Problem is, few sites take advantage of kids.us; nearly all kid sites are NOT in kids.us. One problem may be that it appears there's a single monopolist in control of the domain registration; that means higher domain prices, and more importantly, any kid site in kids.us would put their entire business under the control of that monopolist. There may be other problems, too.
Which is too bad. I think the basic idea of kids.us is actually sound. We need to find a way to eliminate risks to the organizations signing up to kids.us, and and then encourage them to use it. If there were a "safe for the kids" area on the Internet, perhaps some of the other concerns would be reduced.