I'd like to see mail browsers add a nice big "SPAM" button that will can do a number of configurable actions, and has a useful default. I suggest as the default that it forge and send back a "no such user" message, save the message in a "past spam" folder, and occasionally invokes a naive Bayesian statistical analysis program (as Graham describes) to create a filter for the future (then filter out email with a high probability of being spam). Perhaps it could optionally do other things, such as forward a copy to a list of email addresses (e.g., your local "abuse" account, the newsgroup news.admin.net-abuse.sightings, and email addresses of well-known spam killers), or calling on other spam killers to check it like SpamAssassin.
Perhaps there could be checkbox beside each action like "don't do it when you press SPAM", "do it when you press SPAM", or "confirm before doing it when you press SPAM" - that way, you could get rid of chain letters without sending them to net-abuse.
By building easily-invoked SPAM-handling capabilities right into the mail browsers, people will be able to fight back more easily.
I know the Mozilla folks are considering anti-SPAM measures; I hope they're willing to build in this kind of functionality, so that it's enabled by default.
Yes! There are lots of things that 3.5" floppies are still good for.
First, it's a great transfer mechanism for "small"
files (e.g., most documents), because it IS so widely available. Most other media don't interchange well BECAUSE not everyone else has one. Not every machine has a working Internet connection - they don't have a connector, it's broken, you can't plug in right now, or they're forbidden (!). I often use 3.5" floppies to exchange files with a laptop... there are other ways, but this one's quick. And if someone says they'll email or post the file, I'm at their mercy... but if they hand me the data on a floppy, I now really have it. Many machines ONLY provide data on 3.5" floppies (e.g., some synthesizers and lab data recorders); if you want to get their data, you need a floppy.
Backup for critical files, esp. from laptops. If you're using a borrowed laptop, perhaps you don't care about anything except 1-3 documents - a floppy backs them up very nicely.
They're wonderful for keys (e.g., PGP keyrings). Yeah, smartcards could be nice, but not every machine has a smartcard connector or its software... but the 3.5" disk is ubiquitous.
Floppies are cheap, and one of the very few ubiquitous standard ways of exchanging data. They're quite cheap, too. It sounds like customers have already decided they don't want to give them up; why should manufacturers force them to?
It'd be easier if there were a nonproprietary standard alternative, but there really isn't one. Iomega isn't even compatible with itself, and it's quite proprietary. Physical media has some advantages over the internet as a media, and both will continue. Before scrapping the floppy, let's see a nonproprietary alternative!
The so-called "doctrine of laches" is supposed to counter "submarine patents" like this. See http://tinyurl.com/pzt
and related documents.
Of course, all of this requires large stacks of money to go to court. This is yet another example of why allowing software patents was such a big mistake in the U.S.
If you're recommending the use of [GNU/]Linux to decision-makers, then you should use real data as part of your rationale. Take a look at my (long!) article, Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!, which has a collection of useful facts and figures (including market share, reliability studies, etc.).
I'm sorry, you're right. I meant arch, not subversion in my previous post.
I took a short look at the
arch home page. Support for sftp still isn't built-in (so it's still dreadfully insecure), but there is a separate patch available to support sftp. I suspect that eventually arch will support sftp and/or other things to replace the absurd "password in the clear" approach it's currently using.
However, it still isn't clear to me that a developer can't modify other files in supposedly "frozen" copies in arch. arch takes a very unusual approach to repositories - which is interesting! - but it appears that Joe Programmer might be able to modify other files than the one Joe is supposed to be modifying. Or perhaps Joe changes "older" versions that he's submitted, screwing up configuration management. Perhaps arch counters this, but I haven't seen any analysis of it that way (please let me know if there are any!!). The fact that arch still requires passwords in the clear doesn't exactly give me warm fuzzies about its security; writing secure programs isn't trivial and requires a commitment to do so.
Arch is actually quite interesting in many ways... but the security issues do concern me.
Subversion has some very interesting ideas, e.g., using an ftp server as a central code repository (making it REALLY EASY to set up a code repository), and "worldwide" names.
However, the last time I looked at subversion, it had some security shortcomings too. One which looked simple to overcome was that, since it used ftp, it sent passwords in the clear over the Internet to change data. This is a crazy thing to do, but is easily fixed (e.g., by using sftp instead of ftp).
More serious is the notion in subversion that all developers are totally trustworthy. It appears that any developer could modify the files on the code server and make it appear that someone ELSE made a given change. Now clearly developers with passwords have to be trusted to some extent, and certainly SOMEBODY has to be trustworthy (e.g., the server administrator or the person who validates keys), but this kind of total trust of ALL developers isn't warranted in many cases. Even if you expect others to find a security flaw, you'd like some mechanism to backtrack to who made the changes. I didn't do a serious security analysis to see if subdomain countered this, though, and I haven't followed it since. I'd be curious if others have examined the issue more closely.
If you're writing software for Linux/Unix systems, go see my book, the Secure Programming for Linux and Unix HOWTO available at http://www.dwheeler.com/secure-programs. It's freely available and redistributable (GFDL license), and it's got lots of information on how to write secure programs. There's lots of information on the Internet on how to write secure programs, but this book gives a lot of information in one place. Enjoy!
Actually, this happens in many cities too. In the Washington, DC area, if you ask how far something is, you'll get an answer in time. The reason is simple: rarely do you really care about how far away something is when you're driving; it's more likely you want to know how long it takes to get there. Some roads are horrendously overcrowded, and natural barriers like large rivers (which few bridges cross) make strict measurement by distance worthless.
Thus, you'll hear: "How far is it to Crystal City from here?" Answer: "When? Now?"
Since I'm the author of this paper (More than a Gigabuck: Estimating GNU/Linux's Size), I suppose I should respond to some of the comments made here:
How did I arrive at the estimate of $1 billion? The short answer is "see the paper". I wrote a tool to compute the number of physical source lines of code (SLOC), used Boehm's well-repected COCOMO model to determine the effort (in person-years) from the SLOC, and then converted that effort into an estimated development cost using programmer salary averages and wrap rates. See the paper for the details.
It's true that there's no necessary relationship between cost and value. I don't see how that contradicts the paper; the paper never claims that there is one. Clearly, you can spend $1 million to develop a program that is worthless; it happens all too often. Proprietary vendors make money by making more money from sales than it cost to develop the software, so proprietary software vendors are very aware of the difference betwen value and cost. Look carefully at the phrasing. All the paper says is that "Had this Linux distribution been developed by conventional proprietary means, it would have cost over $1.08 billion (1,000 million) to develop in the U.S. (in year 2000 dollars)." The paper does not claim that Red Hat actually spent $1 billion, or that their distributions' sale value is related to this development cost figure. Indeed, what the paper shows is that by using OSS/FS approaches, it's possible to build large systems that would cost over $1 billion to develop using conventional proprietary means.
Several have complained about the use of COCOMO for estimating effort from lines of code. COCOMO is certainly not perfect, but it's a well-tested, widely accepted, and widely used model. It's also very clearly documented, so there are no "hidden assumptions". In particular, the model and constants used in COCOMO are based on a wide variety of real projects. It's rediculous to believe that its results are accurate to the nearest hour; as noted throughout the paper, this is only an estimate. A few people have noted that their software took less time to develop, but there are many factors at work. One is that highly experienced people can develop code more quickly; however, not everyone is equally skilled, so with large systems and many developers this effect should even out. Another is that COCOMO includes design time, documentation time, and testing time. Also, this includes not only an average U.S. programmers' salary, but also the wrap rate for overhead (building costs, insurance, and so on) - which programmers don't see in their paychecks, but are certainly paid for by traditional businesses. Don't like COCOMO? That's fine - use your own model, preferably one that's been widely tested in the industry. This paper shows you exactly how to do this sort of analysis.
I do not claim that every line of code is a "complete rebuild". I'm simply trying to estimate how much it would be take to build the system if it was rebuilt.
The problems with physical SLOC's sensitivity to formatting is well-documented, and I note that in the paper. It's not as bad as you'd think when analyzing larger systems, due to averaging. But if you would rather use logical SLOC, feel free to write code to do that and contribute it to sloccount. In short, instead of complaining, contribute.
As documented in the paper, I only used Basic COCOMO. I don't have enough information about each project to really use the more detailed COCOMO models effectively. However, the paper has all you need if you want to do more detailed analysis using other effort and cost estimation models, including the versions of COCOMO that require more input (e.g., Intermediate COCOMO).
SLOC isn't a very good measure of productivity, but it's generally a very good way to estimate effort. This distinction is important. If programmer A can do something in 100 SLOC, and programmer B needs 10,000 SLOC to do the same thing, it's crazy to think that programmer B is more productive. But it is reasonable to believe that it will take more effort for programmer B to do the same thing (and thus more money). It's possible to game this (e.g., creating separate print commands for each letter to be output as a string), but the resulting code is pretty ugly and programmers generally only intentionally game things if they believe having higher SLOC values will improve their salaries (an unlikely claim for the software in the Red Hat Linux distribution). The paper only measures effort to develop Red Hat Linux 7.1. You'll have to determine if that's a comparable level of functionality to other systems.
This doesn't count "the operating system". It counts "Red Hat Linux 7.1". Thus, it includes the word processors, spread sheets, and so on. It's not as easy to determine what to leave out; you could compute just the minimal "base", but few people would want to use such a system. Again, I think that's extremely clearly stated in the paper.
Others have been inspired by my paper to
do an analysis of the Debian GNU/Linux distribution, using my tool
sloccount.
You can see their very interesting paper
Counting Potatoes: The size of Debian 2.2 at
http://people.debian.org/~jgb/debian-counting.
They found that Debian 2.2 includes more than 55 million physical SLOC, and
would have cost nearly $1.9 billion USD using over 14,000 person-years
to develop using traditional proprietary techniques.
Yeah, I need a better picture. I just haven't gotten around to it.
A very nice tool for converting HTML to PDF is "HTMLDoc". It's GPL'ed. The HTMLDOC home page is located at http://www.easysw.com/htmldoc. It's not clear to me that it will really meet your needs, but if not, it may be possible to modify it to do what you want.
As others have noted, how you approach learning math partly depends on what you plan to do with it. But if part of your purpose is to have fun, then I suggest having fun as part of the process!
There are lots of "mathematical recreations" and "math puzzles" that are fun to try solving, in the same way that it can be fun solving other puzzles. And sometimes you may see a variation on that puzzle that's fun (and truly new). Not all of them are truly critical from the point of view of furthering the advancement of mathematics, but they help develop the mind, and if your purpose is to have fun, start now!
For example, I learned about the ``four fours'' problem as a kid (using exactly 4 fours, create legal mathematical expressions to compute 0, 1, 2, 3, etc.). Recently I created a definitive list of answers for the four fours problem. I also played with various really weird bases. Will these change the universe? No. But in the process I learned more than I knew before, and I enjoyed the process.
If nothing else, if you enjoy the process, you're more likely to continue doing it.
If you want to get rid of defects, you need to review your software. There are a lot of quantitative studies that show that software inspections (a particular way to do a peer review of software) are very effective at finding defects.
Here are some experience reports showing software inspections to be effective: (1) G.W. Russell's "Experience with Inspection in Ultralarge-Scale Developments" (IEEE Software, Jan. 1991), (2) E.F. Weller's "Lessons from Three Years of Inspection Data" (IEEE Software, Sept. 1993), and (3) Grady and Van Slack's "Key Lessons in Achieving Widespread Inspection Use" (IEEE Software, July 1994).
There are many other such articles; I'm highlighting the IEEE Software articles because they're easy to get. Full disclosure: I co-edited a book on software inspections, titled "Software Inspection: An Industry Best Practice" (IEEE Computer Science Press, 1996; edited by David A. Wheeler, Bill Brykczynski, and Reginald N. Meeson, Jr.). That book reprints the most interesting articles on software inspection of the time, many of which are quite hard to get hold of, as well as additional material not found elsewhere that gives you the "big picture." Unfortunately, that book is now out of print and getting increasingly hard to get, but you might be able to get a used copy (or convince IEEE to reprint it).
When Netscape started up, the "world wide web" was NOTHING like its current size or influence. When Netscape started, Mosaic was showing people that the web had great POTENTIAL, but for many non-technical people there weren't enough services to make it worth using. Netscape wanted to sell servers; if it wanted to sell other people servers, there needed to be a lot of potential users of those servers. Netscape "gave away" the browsers so that there would be a market. Although it didn't work, this actually made sense at the time. After all, when you sell one server, you can (in theory) charge a big initial fee, plus lots of support fees, and each sale brings in lots of money. Client sales are a pain; each one only makes a little money, and supporting each user can cost more than the sale. A business strategy of selling where the profit margin would be largest seemed like a good idea. I suspect Netscape thought that once they owned the browser market, they could create proprietary extensions to their server so that users of other browsers would have a poorer experience (if it worked at all).
However, the big picture intervened here, in many ways. First, I think Joel is right, companies want to commoditize complementary products, because it leads to more sales for them. But different organizations will want to commoditize different things, because it's in their interest. As a result, sometimes the interaction of different players can result in the commoditization of many product categories. This can have a very beneficial result to the consumer, because commodity products are often in the consumer's best interests.
Looking at the Netscape case, Netscape had an interest in a commodity browser to support a proprietary server. But server administrators, using open source software approaches, managed to commoditize the server (Apache), ruining that approach. And Microsoft exploited its monopoly hold on Windows and OEM licensing agreements to prevent Netscape from getting their product on many PCs (as well as eliminating any possibility of selling Netscape for a profit). (In this case, some of these actions have been found illegal, but I believe similar things can happen even without illegal activity). As a result, Netscape ended up open-sourcing Mozilla. Now both the client and server sides can be viewed as commodity products: the server certainly is a commodity product, and Mozilla certainly limits what Microsoft could charge for a web client. This is a result neither Microsoft nor Netscape would have wanted, but it's better for the consumer.
In one place, ADTI claimed I said something I didn't say, and in others ADTI intentionally carefully quotes only part of what I said.
Re:Strange U.S. station names
on
Homogenized Music
·
· Score: 3, Informative
For more info on U.S. call letters, see http://www.fcc.gov/cgb/statid.html.
If you loathe what's available on radio now, start your own station. The FCC Media burea has some information on how to do that, see http://www.fcc.gov/mb. Yes, that's nontrivial.
It's already been revealed that some attacker got into Microsoft's network. Also, CD's with Microsoft's source have been released for various reasons over time. I have no trouble believing that some "bad guys" already have the source code. So, how do the rest of us protect ourselves from these bad guys with the source code? And from the bad guys to come who don't have it yet... but will?
It's been argued that a system without source code is more secure because, since there's less information available for an attacker, it should be harder for an attacker to find the vulnerabilities. This argument has a number of weaknesses, however, because although source code is extremely important when trying to add new capabilities to a program, attackers generally don't need source code to find a vulnerability.
First, it's important to distinguish between ``destructive'' acts and ``constructive'' acts. In the real world, it is much easier to destroy a car than to build one. In the software world, it is much easier to find and exploit a vulnerability than to add new significant new functionality to that software. Attackers have many advantages against defenders because of this difference. Software developers must try to have no security-relevant mistakes anywhere in their code, while attackers only need to find one. Developers are primarily paid to get their programs to work... attackers don't need to make the program work, they only need to find a single weakness. And as I'll describe in a moment, it takes less information to attack a program than to modify one.
Generally attackers (against both open and closed programs) start by knowing about the general kinds of security problems programs have. There's no point in hiding this information; it's already out, and in any case, defenders need that kind of information to defend themselves. Attackers then use techniques to try to find those problems; I'll group the techniques into ``dynamic'' techniques (where you run the program) and ``static'' techniques (where you examine the program's code - be it source code or machine code).
In ``dynamic'' approaches, an attacker runs the program, sending it data (often problematic data), and sees if the programs' response indicates a common vulnerability. Open and closed programs have no difference here, since the attacker isn't looking at code. Attackers may also look at the code, the ``static'' approach. For open source software, they'll probably look at the source code and search it for patterns. For closed source software, they might search the machine code (usually presented in assembly language format to simplify the task) for essentially the same patterns. They might also use tools called ``decompilers'' that turn the machine code back into source code and then search the source code for the vulnerable patterns (the same way they would search for vulnerabilities in open source software). See Flake [2001] for one discussion of how closed code can still be examined for security vulnerabilities (e.g., using disassemblers). This point is important: even if an attacker wanted to use source code to find a vulnerability, a closed source program has no advantage, because the attacker can use a disassembler to re-create the source code of the product.
Non-developers might ask ``if decompilers can create source code from machine code, then why do developers say they need source code instead of just machine code?'' The problem is that although developers don't need source code to find security problems, developers do need source code to make substantial improvements to the program. Although decompilers can turn machine code back into a ``source code'' of sorts, the resulting source code is extremely hard to modify. Typically most understandable names are lost, so instead of variables like ``grand_total'' you get ``x123123'', instead of methods like ``display_warning'' you get ``f123124'', and the code itself may have spatterings of assembly in it. Also, _ALL_ comments and design information are lost. This isn't a serious problem for finding security problems, because generally you're searching for patterns indicating vulnerabilities, not for internal variable or method names. Thus, decompilers can be useful for finding ways to attack programs, but aren't helpful for updating programs.
Thus, developers will say ``source code is vital'' (when they intend to add functionality), but the fact that the source code for closed source programs is hidden doesn't protect the program very much.
National Cryptologic Museum has an Enigma
on
Enigma
·
· Score: 3, Informative
If you're interested in cryptography, and you can get to Maryland (USA), visit the National Cryptologic Museum. Among other things, they have an Enigma there. If you can't go and visit yourself, here's their picture and a short description of the Enigma. They have lots of other exhibits too, and there's no entrance fee. Last time I visited, they even let you play with an Enigma, so you could encrypt and decrypt messages with it.
Copy protection? Nah. Ordinary license change.
on
Two Helpings of WINE
·
· Score: 2
Hiding the source code really doesn't help a copy protection scheme. Copy protection schemes based on typical software-only techniques are fundamentally flawed, whether they're open source or proprietary. It's true that it'd be easy to get the algorithm if they're in the source code... but it really isn't much harder for a knowledgeable person to extract the necessary information from the machine code. And once one person, anywhere, figures it out, it's broadcast to the world, ending the pseudo-secrecy. Before the IBM PC, one of the most popular computers was the Apple// line, where disk copy protection mechanisms became increasingly sophisticated... and each were broken immediately. The whole purpose of a computer is to process data, including copying it.
Look, it's clear that some organizations take the Wine work, add stuff, and don't give back to the Wine community. The current license allows this, but it looks like many Wine developers don't like what's happening. Thus, the majority of the Wine developers have agreed to switch the license of future versions to the LGPL, which will thus _require_ other developers to work with them if their LGPL code is used. In other words, the license will now require what before was a request and a courtesy. This isn't "theft", this is simply "you can use my Wine code if I can use your Wine code". The LGPL is a common compromise library if a group wants to allow proprietary programs to use it, but wants to create a "consortium" for maintaining the library. The LGPL is used for lots of projects, including GTK+ (the basis of GNOME).
Presumably many readers know a little about nanotechnology, but in case you're looking for beginning information about it, here are a few places to look:
So the latest movies are already on the Internet before they're in the theaters? This shows that the DMCA and SSSCA are counter-productive; they're harmful to society and will not solve the problems they're purported to solve.
In the U.S. the DMCA is already stifling free speech, and possibly putting the country at risk because academics can't work in many areas to improve security (becasue they can't publish their results). The proposed SSSCA (recently renamed) is also awful; it tries to turn PCs into TVs that have no ability to process information. And all of this is worthless.
It's worthless because anyone can just use a camera and record a movie straight from the audiovisual output, and then distribute the results. That bypasses the "don't describe how to decrypt" provisions in the DMCA, and it bypasses the "require untamperable decryption" clauses in the SSSCA. As long as humans use ears and eyes for observing audio and video, movies have to come out of the machines sometime.
Many technology-based solutions are worse than the current problem. You could make cameras or distribution of videos illegal - but they have many legitimate uses, including recording family scenes, recording illegal/terrorist acts for later prosecution, and so on. The DVD cabal would like to make sure that only they can create video information, but that's also clearly not in society's best interest. We make sure that anyone can write a book; there is too much danger in trying to prevent that. Even if DVDs could only play them, someone can always write another program to display video data, and we WANT such programs to view material we create. Even if you could insert digital brain implants to watch movies, someone will just record the electrical signals from the brain implants. Besides, the risks of mandating brain implants if you want to watch movies (even if we HAD the technology) exceed any societal benefits for "unbreakable" security.
The act of distributing this copyrighted material is already illegal; there's no need for new laws. Just work to find and prosecute those who perform illegal acts. Perhaps watermarking would be appropriate, since that would aid in finding perpetrators without stomping on legitimate use. We already have forces that search for illegal material and go prosecute them; it doesn't stop it completely, but neither do the other laws, and at least that doesn't fundamentally interfere with the right to create and distribute other audiovisual material.
Yes, it's understandable why the movie industry is worried about digital technology. But so far, it looks like they're learning the wrong lesson. RIAA wants to turn back the clock on technology, and try to force users to accept absurd conditions ("you must pay whatever monthly fee we choose, forever, to hear music"). We can hope that the movie industry will start working on how to work with, not against, digital technology.
If hiding all the protocols and APIs is necessary to make software more secure, how come there are so many evidences that open source software/free software (OSS/FS) is, at least in some cases, more secure that proprietary programs? A list of quantitative measures, showing that (at least in many cases) OSS/FS is more secure than proprietary software, is at
http://www.dwheeler.com/oss_fs_why.html#security.
That's NOT to say that OSS/FS is automatically more secure. But even proprietary vendors often describe their APIs and protocols, without claiming that this information will cause security problems.
Hiding the APIs and protocols has little hope in making a program secure if the program is widely available to attackers anyway. Attackers will just examine the software directly. What secures programs is diligence by the developers, combined with serious security review by independent people who know how to review software. Trying to hide the APIs and protocols is just begging for trouble, because then you won't get much help from the "good guys".
The cryptographic community learned this years ago; look at the process that was used to develop the Advanced Encryption Standard (AES). Clearly an encryption standard is critical for security, yet the standard was publicly analyzed for quite some time.
If you're curious about the "amount of code" provided by the GNU project to a typical (GNU/)Linux distribution, take a look here: http://www.dwheeler.com/sloc.
In particular, look at section 3.2 of the version
that looked at Red Hat Linux 7.1. Here's the gist:
The data here can be used to justify calling the system either ``Linux'' or ``GNU/Linux.'' It's clear that the largest single component in the operating system is the Linux kernel, so it's at least understandable how so many people have chosen to name the entire system after its largest single component (``Linux''). It's also clear that there are many contributors, not just the GNU project itself, and some of those contributors do not agree with the GNU project's philosophy. On the other hand, many of the largest components of the system are essentially GNU projects: gcc, gdb, emacs, binutils (a set of commands for binary files), and glibc (the C library). Other GNU projects in the system include binutils, bash, gawk, make, textutils, sh-utils, gettext, readline, automake, tar, less, findutils, diffutils, and grep... In short, the total of the GNU project's code is much larger than the Linux kernel's size.
The paper has the details to back it up. At that time, the Linux kernel was 2,437 KSLOC (thousands of physical lines of code). But gcc had 984 KSLOC, gdb 967 KSLOC, binutils 691 KSLOC, glibc 647 KSLOC, emacs 628 KSLOC, and so on. See the paper for details. GNU's contribution in terms of effort is, in aggregate, much larger.
Of course, it's a separate question as to whether or not the term ``GNU/Linux'' is a good term. It is clearly awkward to write and speak, and that's a very serious problem. Other postings have already hashed that to death here.
Linux in general, and the specific combination of Linux plus GNOME together, allow web browsers to be completely replaced. Thus, it's easily shown that there's no technical reason for Microsoft's commingling.
First, let's define the requirements... a web browser is "replaceable" if you can remove its on-screen icon, eliminate its memory use, eliminate its disk space use, add a different web browsing program, and then have all the requests for web viewing from other programs (particularly operating system components) go to the other (new) web browser. What's more, it MUST be possible for PC vendors and users to make this change without special dispensation by anyone else.
This is possible on Linux, in a number of different ways. First, you could choose to use solely a textual (not graphical) environment... you can use text browsers like links, lynx, etc. These browsers can be added or removed at will. Many of today's users will want a graphical environment, of course, so let's concentrate on that. If you want to use a graphical environment, there are several available, from ``small'' environments (e.g., simply window managers like E or WindowMaker without environment components) to full-scale desktop graphical environments (mainly GNOME and KDE). Even if a web browser was embedded into a particular graphical environment, the fact that resellers and users can choose which environment to install (and not install a different one) is sufficient to meet every one of those requirements.
Even if you assumed that if only GNOME existed, GNOME still meets all these criteria. You can add or remove programs using the normal installation programs (e.g., rpm or apt); removing a program eliminates the disk and memory usage of the program, and usually if a program is added or removed the panel is adjusted automatically. You can also modify the on-screen panel and desktop to add or remove arbitrary programs, including the web browser, so clearly you can add or remove a web browser's icons. You can change what web browser is invoked by other GNOME programs; in Red Hat Linux 7.2 and GNOME, select "Programs / Settings / Doc Handlers / URL Handlers", which lets you choose by URL scheme. You can even choose what web browser is used based on the filetype, by selecting "Programs / Settings / File Types and Programs". Thus, you can install or uninstall any web browser, and have it invoked by the GNOME calls for invoking URLs. And all of this can be done by both resellers and users; you don't need dispensation by anyone.
Even if you thought it was impossible to change web browsers in KDE, you can still remove KDE and use GNOME instead. GNOME certainly shows that supporting arbitrary web browsers is quite simple. Clearly there's no technical reason that web browsers have to be so intermingled with the other components.
Unlicensed copying of proprietary software is wrong. Asking companies to show that they're complying in some way, while onerous, isn't completely insane. But it appears that the BSA is acting as the police (when doing a raid), prosecutor, judge, and jury. And as others have noticed, often the software is legal, it's just that the license papers have been lost. Penalizing someone for millions of dollars, even though they did buy it legally, is not right; one could imagine that the BSA should have to bring its evidence to a jury to adjudicate.
Also... in about two months' time, Microsoft's new license terms will kick in - and in spite of their claims, it appears that these new licenses will be much more expensive than the old ones for many.
So, let's combine steep new licensing fees with a quasi-police force that has the power to both presume guilt unless proven innocence (when certain programs are in use) and levy heavy fines. Suddenly you have offered people a powerful incentive to move away from the software products of the BSA's sponsors. Remember when it was dangerous to use free software? Stuff like "who do I sue?" The answer is now clear: if you use proprietary software, the vendors get to sue you. Now it's more dangerous to use proprietary software - if you lose a few licenses, you might have to pay millions.
Simultaneously with the increased risks of using proprietary software, an alternative has become available! Free software is finally becoming mature enough to use seriously at the desktop. Yes, it would have been better if it was ready earlier. But KDE3 is out, GNOME2 is almost out, Open Office is usable and its few burrs will be off soon, Abiword 1.0 is out (without tables, but that shouldn't take that long to add), KOffice is out (with weak MS Office interoperability, but that will be improved quickly I'm sure), Mozilla 1.0 RC1 is out (with 1.0 soon to come out). Evolution is quite impressive (or use Mozilla's email reader). The programs can be used now, they'll have more polish before the end of 2002, and they'll be quite nice by mid-2003. I particularly like the cross-platform applications, because they make it easier for organizations to "phase in" the replacements. Someone using Mozilla and Open Office on Windows will find it much easier to switch to GNU/Linux or FreeBSD.
No, this is NOT enough to replace proprietary systems everywhere; there are many specialized applications that will require Windows, etc. But it will be much easier to show compliance when there are fewer of those machines.
Of course, this could all be a last gasp. Perhaps Microsoft expects everyone to switch from their products soon, and wants to try to extract as much money as possible while their competitors complete their maturing. Perhaps they expect that in mid-2003 organizations will begin switching quickly, and they want to sell (or re-sell) as much as they can before the alternatives are ready. I doubt they expect to really lose the market, but they certainly want to saturate the market to make it harder for anyone else to enter it.
I would say that "site-wide" licenses for Microsoft's products by companies (as they're usually written), and similar licenses effectively preventing Linux pre-installs by PC manufacturers, should be summarily ruled as illegal. These licenses fundamentally discriminate against competitors, because Microsoft gets money even when a customer chooses to use a competitor in a particular circumstance. IBM originally only leased their computers, instead of selling them, as a way of preventing customers from practically switching to a competitor, and that was ruled illegal. The same should be true for any contract that, when widely applied, prevents competition. Without these competition-preventing contracts, Free Software would probably spread much faster. But if customers continue to be treated as the enemy, they may consider alternatives far more seriously.
Slashdot Mirror
I'd like to see mail browsers add a nice big "SPAM" button that will can do a number of configurable actions, and has a useful default. I suggest as the default that it forge and send back a "no such user" message, save the message in a "past spam" folder, and occasionally invokes a naive Bayesian statistical analysis program (as Graham describes) to create a filter for the future (then filter out email with a high probability of being spam). Perhaps it could optionally do other things, such as forward a copy to a list of email addresses (e.g., your local "abuse" account, the newsgroup news.admin.net-abuse.sightings, and email addresses of well-known spam killers), or calling on other spam killers to check it like SpamAssassin.
Perhaps there could be checkbox beside each action like "don't do it when you press SPAM", "do it when you press SPAM", or "confirm before doing it when you press SPAM" - that way, you could get rid of chain letters without sending them to net-abuse.
By building easily-invoked SPAM-handling capabilities right into the mail browsers, people will be able to fight back more easily.
I know the Mozilla folks are considering anti-SPAM measures; I hope they're willing to build in this kind of functionality, so that it's enabled by default.
First, it's a great transfer mechanism for "small" files (e.g., most documents), because it IS so widely available. Most other media don't interchange well BECAUSE not everyone else has one. Not every machine has a working Internet connection - they don't have a connector, it's broken, you can't plug in right now, or they're forbidden (!). I often use 3.5" floppies to exchange files with a laptop... there are other ways, but this one's quick. And if someone says they'll email or post the file, I'm at their mercy... but if they hand me the data on a floppy, I now really have it. Many machines ONLY provide data on 3.5" floppies (e.g., some synthesizers and lab data recorders); if you want to get their data, you need a floppy.
Backup for critical files, esp. from laptops. If you're using a borrowed laptop, perhaps you don't care about anything except 1-3 documents - a floppy backs them up very nicely.
They're wonderful for keys (e.g., PGP keyrings). Yeah, smartcards could be nice, but not every machine has a smartcard connector or its software... but the 3.5" disk is ubiquitous.
Floppies are cheap, and one of the very few ubiquitous standard ways of exchanging data. They're quite cheap, too. It sounds like customers have already decided they don't want to give them up; why should manufacturers force them to?
It'd be easier if there were a nonproprietary standard alternative, but there really isn't one. Iomega isn't even compatible with itself, and it's quite proprietary. Physical media has some advantages over the internet as a media, and both will continue. Before scrapping the floppy, let's see a nonproprietary alternative!
Of course, all of this requires large stacks of money to go to court. This is yet another example of why allowing software patents was such a big mistake in the U.S.
If you're recommending the use of [GNU/]Linux to decision-makers, then you should use real data as part of your rationale. Take a look at my (long!) article, Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers! , which has a collection of useful facts and figures (including market share, reliability studies, etc.).
I took a short look at the arch home page. Support for sftp still isn't built-in (so it's still dreadfully insecure), but there is a separate patch available to support sftp. I suspect that eventually arch will support sftp and/or other things to replace the absurd "password in the clear" approach it's currently using.
However, it still isn't clear to me that a developer can't modify other files in supposedly "frozen" copies in arch. arch takes a very unusual approach to repositories - which is interesting! - but it appears that Joe Programmer might be able to modify other files than the one Joe is supposed to be modifying. Or perhaps Joe changes "older" versions that he's submitted, screwing up configuration management. Perhaps arch counters this, but I haven't seen any analysis of it that way (please let me know if there are any!!). The fact that arch still requires passwords in the clear doesn't exactly give me warm fuzzies about its security; writing secure programs isn't trivial and requires a commitment to do so.
Arch is actually quite interesting in many ways... but the security issues do concern me.
However, the last time I looked at subversion, it had some security shortcomings too. One which looked simple to overcome was that, since it used ftp, it sent passwords in the clear over the Internet to change data. This is a crazy thing to do, but is easily fixed (e.g., by using sftp instead of ftp).
More serious is the notion in subversion that all developers are totally trustworthy. It appears that any developer could modify the files on the code server and make it appear that someone ELSE made a given change. Now clearly developers with passwords have to be trusted to some extent, and certainly SOMEBODY has to be trustworthy (e.g., the server administrator or the person who validates keys), but this kind of total trust of ALL developers isn't warranted in many cases. Even if you expect others to find a security flaw, you'd like some mechanism to backtrack to who made the changes. I didn't do a serious security analysis to see if subdomain countered this, though, and I haven't followed it since. I'd be curious if others have examined the issue more closely.
If you're writing software for Linux/Unix systems, go see my book, the Secure Programming for Linux and Unix HOWTO available at http://www.dwheeler.com/secure-programs. It's freely available and redistributable (GFDL license), and it's got lots of information on how to write secure programs. There's lots of information on the Internet on how to write secure programs, but this book gives a lot of information in one place. Enjoy!
Thus, you'll hear: "How far is it to Crystal City from here?" Answer: "When? Now?"
A very nice tool for converting HTML to PDF is "HTMLDoc". It's GPL'ed. The HTMLDOC home page is located at http://www.easysw.com/htmldoc. It's not clear to me that it will really meet your needs, but if not, it may be possible to modify it to do what you want.
There are lots of "mathematical recreations" and "math puzzles" that are fun to try solving, in the same way that it can be fun solving other puzzles. And sometimes you may see a variation on that puzzle that's fun (and truly new). Not all of them are truly critical from the point of view of furthering the advancement of mathematics, but they help develop the mind, and if your purpose is to have fun, start now!
For example, I learned about the ``four fours'' problem as a kid (using exactly 4 fours, create legal mathematical expressions to compute 0, 1, 2, 3, etc.). Recently I created a definitive list of answers for the four fours problem. I also played with various really weird bases. Will these change the universe? No. But in the process I learned more than I knew before, and I enjoyed the process.
If nothing else, if you enjoy the process, you're more likely to continue doing it.
Here are some experience reports showing software inspections to be effective: (1) G.W. Russell's "Experience with Inspection in Ultralarge-Scale Developments" (IEEE Software, Jan. 1991), (2) E.F. Weller's "Lessons from Three Years of Inspection Data" (IEEE Software, Sept. 1993), and (3) Grady and Van Slack's "Key Lessons in Achieving Widespread Inspection Use" (IEEE Software, July 1994).
There are many other such articles; I'm highlighting the IEEE Software articles because they're easy to get. Full disclosure: I co-edited a book on software inspections, titled "Software Inspection: An Industry Best Practice" (IEEE Computer Science Press, 1996; edited by David A. Wheeler, Bill Brykczynski, and Reginald N. Meeson, Jr.). That book reprints the most interesting articles on software inspection of the time, many of which are quite hard to get hold of, as well as additional material not found elsewhere that gives you the "big picture." Unfortunately, that book is now out of print and getting increasingly hard to get, but you might be able to get a used copy (or convince IEEE to reprint it).
However, the big picture intervened here, in many ways. First, I think Joel is right, companies want to commoditize complementary products, because it leads to more sales for them. But different organizations will want to commoditize different things, because it's in their interest. As a result, sometimes the interaction of different players can result in the commoditization of many product categories. This can have a very beneficial result to the consumer, because commodity products are often in the consumer's best interests.
Looking at the Netscape case, Netscape had an interest in a commodity browser to support a proprietary server. But server administrators, using open source software approaches, managed to commoditize the server (Apache), ruining that approach. And Microsoft exploited its monopoly hold on Windows and OEM licensing agreements to prevent Netscape from getting their product on many PCs (as well as eliminating any possibility of selling Netscape for a profit). (In this case, some of these actions have been found illegal, but I believe similar things can happen even without illegal activity). As a result, Netscape ended up open-sourcing Mozilla. Now both the client and server sides can be viewed as commodity products: the server certainly is a commodity product, and Mozilla certainly limits what Microsoft could charge for a web client. This is a result neither Microsoft nor Netscape would have wanted, but it's better for the consumer.
In one place, ADTI claimed I said something I didn't say, and in others ADTI intentionally carefully quotes only part of what I said.
For more info on U.S. call letters, see http://www.fcc.gov/cgb/statid.html. If you loathe what's available on radio now, start your own station. The FCC Media burea has some information on how to do that, see http://www.fcc.gov/mb. Yes, that's nontrivial.
This issue was also discussed in my book Secure Programming for Linux and Unix HOWTO. Look at the section on semantic attacks.
It's already been revealed that some attacker got into Microsoft's network. Also, CD's with Microsoft's source have been released for various reasons over time. I have no trouble believing that some "bad guys" already have the source code. So, how do the rest of us protect ourselves from these bad guys with the source code? And from the bad guys to come who don't have it yet... but will?
As noted in Secure Programming for Linux and Unix HOWTO, section 2.4.2, closing off source code doesn't actually halt attacks anyway. Here's the quote:
If you're interested in cryptography, and you can get to Maryland (USA), visit the National Cryptologic Museum. Among other things, they have an Enigma there. If you can't go and visit yourself, here's their picture and a short description of the Enigma. They have lots of other exhibits too, and there's no entrance fee. Last time I visited, they even let you play with an Enigma, so you could encrypt and decrypt messages with it.
Look, it's clear that some organizations take the Wine work, add stuff, and don't give back to the Wine community. The current license allows this, but it looks like many Wine developers don't like what's happening. Thus, the majority of the Wine developers have agreed to switch the license of future versions to the LGPL, which will thus _require_ other developers to work with them if their LGPL code is used. In other words, the license will now require what before was a request and a courtesy. This isn't "theft", this is simply "you can use my Wine code if I can use your Wine code". The LGPL is a common compromise library if a group wants to allow proprietary programs to use it, but wants to create a "consortium" for maintaining the library. The LGPL is used for lots of projects, including GTK+ (the basis of GNOME).
In the U.S. the DMCA is already stifling free speech, and possibly putting the country at risk because academics can't work in many areas to improve security (becasue they can't publish their results). The proposed SSSCA (recently renamed) is also awful; it tries to turn PCs into TVs that have no ability to process information. And all of this is worthless.
It's worthless because anyone can just use a camera and record a movie straight from the audiovisual output, and then distribute the results. That bypasses the "don't describe how to decrypt" provisions in the DMCA, and it bypasses the "require untamperable decryption" clauses in the SSSCA. As long as humans use ears and eyes for observing audio and video, movies have to come out of the machines sometime.
Many technology-based solutions are worse than the current problem. You could make cameras or distribution of videos illegal - but they have many legitimate uses, including recording family scenes, recording illegal/terrorist acts for later prosecution, and so on. The DVD cabal would like to make sure that only they can create video information, but that's also clearly not in society's best interest. We make sure that anyone can write a book; there is too much danger in trying to prevent that. Even if DVDs could only play them, someone can always write another program to display video data, and we WANT such programs to view material we create. Even if you could insert digital brain implants to watch movies, someone will just record the electrical signals from the brain implants. Besides, the risks of mandating brain implants if you want to watch movies (even if we HAD the technology) exceed any societal benefits for "unbreakable" security.
The act of distributing this copyrighted material is already illegal; there's no need for new laws. Just work to find and prosecute those who perform illegal acts. Perhaps watermarking would be appropriate, since that would aid in finding perpetrators without stomping on legitimate use. We already have forces that search for illegal material and go prosecute them; it doesn't stop it completely, but neither do the other laws, and at least that doesn't fundamentally interfere with the right to create and distribute other audiovisual material.
Yes, it's understandable why the movie industry is worried about digital technology. But so far, it looks like they're learning the wrong lesson. RIAA wants to turn back the clock on technology, and try to force users to accept absurd conditions ("you must pay whatever monthly fee we choose, forever, to hear music"). We can hope that the movie industry will start working on how to work with, not against, digital technology.
That's NOT to say that OSS/FS is automatically more secure. But even proprietary vendors often describe their APIs and protocols, without claiming that this information will cause security problems.
Hiding the APIs and protocols has little hope in making a program secure if the program is widely available to attackers anyway. Attackers will just examine the software directly. What secures programs is diligence by the developers, combined with serious security review by independent people who know how to review software. Trying to hide the APIs and protocols is just begging for trouble, because then you won't get much help from the "good guys".
The cryptographic community learned this years ago; look at the process that was used to develop the Advanced Encryption Standard (AES). Clearly an encryption standard is critical for security, yet the standard was publicly analyzed for quite some time.
The paper has the details to back it up. At that time, the Linux kernel was 2,437 KSLOC (thousands of physical lines of code). But gcc had 984 KSLOC, gdb 967 KSLOC, binutils 691 KSLOC, glibc 647 KSLOC, emacs 628 KSLOC, and so on. See the paper for details. GNU's contribution in terms of effort is, in aggregate, much larger.
Of course, it's a separate question as to whether or not the term ``GNU/Linux'' is a good term. It is clearly awkward to write and speak, and that's a very serious problem. Other postings have already hashed that to death here.
First, let's define the requirements... a web browser is "replaceable" if you can remove its on-screen icon, eliminate its memory use, eliminate its disk space use, add a different web browsing program, and then have all the requests for web viewing from other programs (particularly operating system components) go to the other (new) web browser. What's more, it MUST be possible for PC vendors and users to make this change without special dispensation by anyone else.
This is possible on Linux, in a number of different ways. First, you could choose to use solely a textual (not graphical) environment... you can use text browsers like links, lynx, etc. These browsers can be added or removed at will. Many of today's users will want a graphical environment, of course, so let's concentrate on that. If you want to use a graphical environment, there are several available, from ``small'' environments (e.g., simply window managers like E or WindowMaker without environment components) to full-scale desktop graphical environments (mainly GNOME and KDE). Even if a web browser was embedded into a particular graphical environment, the fact that resellers and users can choose which environment to install (and not install a different one) is sufficient to meet every one of those requirements.
Even if you assumed that if only GNOME existed, GNOME still meets all these criteria. You can add or remove programs using the normal installation programs (e.g., rpm or apt); removing a program eliminates the disk and memory usage of the program, and usually if a program is added or removed the panel is adjusted automatically. You can also modify the on-screen panel and desktop to add or remove arbitrary programs, including the web browser, so clearly you can add or remove a web browser's icons. You can change what web browser is invoked by other GNOME programs; in Red Hat Linux 7.2 and GNOME, select "Programs / Settings / Doc Handlers / URL Handlers", which lets you choose by URL scheme. You can even choose what web browser is used based on the filetype, by selecting "Programs / Settings / File Types and Programs". Thus, you can install or uninstall any web browser, and have it invoked by the GNOME calls for invoking URLs. And all of this can be done by both resellers and users; you don't need dispensation by anyone.
Even if you thought it was impossible to change web browsers in KDE, you can still remove KDE and use GNOME instead. GNOME certainly shows that supporting arbitrary web browsers is quite simple. Clearly there's no technical reason that web browsers have to be so intermingled with the other components.
Also... in about two months' time, Microsoft's new license terms will kick in - and in spite of their claims, it appears that these new licenses will be much more expensive than the old ones for many.
So, let's combine steep new licensing fees with a quasi-police force that has the power to both presume guilt unless proven innocence (when certain programs are in use) and levy heavy fines. Suddenly you have offered people a powerful incentive to move away from the software products of the BSA's sponsors. Remember when it was dangerous to use free software? Stuff like "who do I sue?" The answer is now clear: if you use proprietary software, the vendors get to sue you . Now it's more dangerous to use proprietary software - if you lose a few licenses, you might have to pay millions.
Simultaneously with the increased risks of using proprietary software, an alternative has become available! Free software is finally becoming mature enough to use seriously at the desktop. Yes, it would have been better if it was ready earlier. But KDE3 is out, GNOME2 is almost out, Open Office is usable and its few burrs will be off soon, Abiword 1.0 is out (without tables, but that shouldn't take that long to add), KOffice is out (with weak MS Office interoperability, but that will be improved quickly I'm sure), Mozilla 1.0 RC1 is out (with 1.0 soon to come out). Evolution is quite impressive (or use Mozilla's email reader). The programs can be used now, they'll have more polish before the end of 2002, and they'll be quite nice by mid-2003. I particularly like the cross-platform applications, because they make it easier for organizations to "phase in" the replacements. Someone using Mozilla and Open Office on Windows will find it much easier to switch to GNU/Linux or FreeBSD.
No, this is NOT enough to replace proprietary systems everywhere; there are many specialized applications that will require Windows, etc. But it will be much easier to show compliance when there are fewer of those machines.
Of course, this could all be a last gasp. Perhaps Microsoft expects everyone to switch from their products soon, and wants to try to extract as much money as possible while their competitors complete their maturing. Perhaps they expect that in mid-2003 organizations will begin switching quickly, and they want to sell (or re-sell) as much as they can before the alternatives are ready. I doubt they expect to really lose the market, but they certainly want to saturate the market to make it harder for anyone else to enter it.
I would say that "site-wide" licenses for Microsoft's products by companies (as they're usually written), and similar licenses effectively preventing Linux pre-installs by PC manufacturers, should be summarily ruled as illegal. These licenses fundamentally discriminate against competitors, because Microsoft gets money even when a customer chooses to use a competitor in a particular circumstance. IBM originally only leased their computers, instead of selling them, as a way of preventing customers from practically switching to a competitor, and that was ruled illegal. The same should be true for any contract that, when widely applied, prevents competition. Without these competition-preventing contracts, Free Software would probably spread much faster. But if customers continue to be treated as the enemy, they may consider alternatives far more seriously.