Here's some information that may help you.
I gladly take donations. The easy way is to use Paypal to send a donation dwheeler @ dwheeler.com. Thanks so much for your generousity!
If you find any of my material interesting, please link to it and recommend that material to others. I'd appreciate it! You don't need to ask permission to link to the material on a website, including mine; just link to it. There's no legal requirement to ask for permission to link (at least in the U.S.). In April 2000, Federal Judge Harry L. Hupp in his ruling on deep linking Ticketmaster vs. Tickets.com, Inc, 2000 U.S. Dist LEXIS 12987 (D. Cal. 2000), stated that, "hyperlinking does not itself involve a violation of the Copyright Act... since no copying is involved". This is confirmed by the "Frequently Asked Questions About Copyright", from the CENDI Copyright Working Group, January 2, 2002 (updated August 2007), question 2.4.6 "Is it copyright infringement to link from your website to copyrighted material on another". It is a real hardship on authors when millions of people send link permission requests.
If you have to get written permission to create a link to my site, I will provide it. But that is extra work for me, so I charge $50 per request to cover my time. Please contact me for details. Alternatively, just admit that the law already gives you free speech rights, including permission to use citations such as links.
In a few cases I know that some URLs will change; in those cases, I try to post recommendations on what to link to instead, and I highly recommend that you follow my recommendations (for your own sanity's sake!). The notion of asking for permission to link is just silly; the whole point of the World Wide Web is to enable links. If you don't want people linking to specific material, keep it off the Web.
And yes, that includes well-known sites like Slashdot and Groklaw (when Groklaw was running). Feel free to recommend my stuff even to sites that may pound me with lots of simultaneous readers. Which brings me to my next point...
Please do refer to this website from other sites, even popular ones. I'd be delighted, since that usually means that more people will read and use my material.
Some of my work has featured on the top-30 of Y Combinator's Hacker News.
Fixing Unix/Linux/Posix Filenames (2009) was posted in 2019.
On 2016-09 my page on 6502s was highlighted.
On 2016-10-08 my dissertation on trusting trust was highlighted. This same topic was previously highlighted earlier.
Yes, I've been Slashdotted, 13 times so far. On 2015-08-21 Slashdot noted Linux Foundation Project Will Evaluate Security of Open Source Software (that didn't point to this website, but it pointed directly to the work I did). On 2014-05-04 the Slashdot article How to Prevent the Next Heartbleed discussed my paper, also titled How to Prevent the next Heartbleed. A version of my Why OSS/FS? Look at the Numbers! paper was a feature Slashdot article on July 9, 2001, April 20, 2002, and September 30, 2004 (as I revise it, hopefully a future revision will be Slashdotted again). My source lines of code (SLOC) work was a major Slashdot feature on both June 21, 2001 and July 5, 2002, and both it and my paper analyzing Red Hat Linux's SLOC were key features in a July 30, 2004, article that CPAN has $677M of Perl code. My short article computing redevelopment costs of Linux kernel 2.6 was featured in an October 13, 2004 Slashdot article, and it was featured again as part of a February 24, 2010 Slashdot article. On December 30, 2003, my article #3 on writing secure programs was Slashdotted (that was my article, though not this site). The Slashdot article about the 2009 DoD memo on open source software specifically pointed to my blog article about it (I helped develop the memo). Although I'm not counting it, I guess I should mention that on February 24, 2004, Slashdot posted my review of David J. Agan's excellent book Debugging (you can see the Slashdot version and my slightly updated review). I'm also not counting the August 13, 2004, Slashdot article on "Open Source in California Government"; the 2004 California report recommends exploring open source software and it prominently references some of my work. On July 16, 2011, the Slashdot article "Microsoft Developer Made the Most Changes To Linux 3.0 Code" referred to my blog post Microsoft, co-author of the Linux kernel.
Some of the URL links on my site are dead. It's impossible to prevent it, because things change all the time. If someone provides me with a replacement link for a dead link, I will generally fix it. However, just saying "this link is dead" isn't helpful; I'd rather include a dead link, helping people find the information, than remove a link entirely. No one pays me to maintain this site, so I just can't spend the time researching new places for every dead link (that would be a full-time job!). If you find a dead link, the Internet archive (especially its Wayback Machine) is probably a good place to start.
This site supports HTTPS. This has three advantages: (1) privacy for users (others will not know which pages are being viewed on this site), (2) authentication that they're really seeing my site (and not someone else's), and (3) integrity for the pages (e.g., others such as ISPs will not be able to hijack these pages en route). People who request non-HTTPS are automatically rerouted to HTTPS, told it's a permanent reroute, and are also told to use HTTPS for future connections to this site (using HTTP Strict Transport Security, aka HSTS).
I previously planned to do this when Let’s encrypt became operational, but various challenges interfered with using them in my case, so I bought a separate TLS certificate. It's still a win for Let’s encrypt, because separately-purchased TLS certificates have generally gotten cheaper due to competition.
The TLS setup isn't ideal, in particular, it does not support some of the latest protocols protocols and crypto algorithms, and in some cases allows older ones. I can't fix that without changing my hosting service (at a significantly higher price). Many attacks don't really work directly against this site, because it's a bunch of static pages, so it's not as bad as it might appear.
Similarly, I don't have a CAA record (yet), because namecheap (my DNS provider) doesn't support them yet.
The real issue is that I'm not made of money, and this is what's available on the inexpensive hosting service I use. Even paying for a separate cert is cheaper than some alternatives I've seen, especially since the site isn't squelched or charged extra when it's busy. If someone wants to pay for my hosting costs, I would like to hear from them.
I have enabled many HTTP security headings, I'm intentionally avoiding HTTP Public Key Pinning (HPKP), because that makes it harder to switch CAs and honest mistakes can sometimes render your site useless.
For many years the primary name of the site was www.dwheeler.com. Historically the standard recommended practice was that website domains use the "www." subdomain, and this website dates back to that time. Thus, the canonical URLs for this site started with "www." in the domain name. I was fine with that setup, but then Chrome started falsifying URLs by omitting the www. Since many people use Chrome, I decided to drop the www so that Chrome users would see the correct domain name. I forward the older www.dwheeler.com URLs to the new canonical name. I have changed many links so that they use dwheeler.com instead of www.dwheeler.com, but I have not spent the effort to be thorough about it. No doubt you'll see lots of references to the older domain name both here and elsewhere; since forwarding works fine, I don't think it's a big deal.
This site began September 12, 1999; some content predates the site. It was originally hosted by LinuxAvenue, but on November 5, 2001 (after about 2 years) I switched to Webframe.org in the Netherlands, which worked well for nearly four years. At that time the website ran on OpenBSD, an operating system with a deservedly excellent reputation for its security. Webframe then got bought out and changed business directions; after some discussions, there was an amicable agreement that I should transition to a new hosting site. So on June 9, 2005, I switched hosts to planet.perens.com, a Debian GNU/Linux system run by Bruce Perens. In 2009 I moved to a commercial hosting service, WebhostGIANT, using CentOS (this is based on Red Hat Enterprise Linux). It appears that WebHostGIANT is now part of WebIntellects, and that the www.webhostGIANT.com domain is basically dead (it is now a link farm). There is a Russian WebHostGiant.ru and a web-host-giant.com; to my knowledge they are unrelated, but they have miseadingly confusing names. Web intellects appears to be owned by Jumpline. Who knows, I may need to move again in the future.
I was able to easily switch between these different locations in a way that most people didn't even notice, because I made sure I owned my domain name (and trademark), dwheeler.com, right from the beginning. I strongly recommend that website owners directly own their own name! I also made sure that I didn't depend on software proprietary to a particular hosting environment, making it easy to switch. In short, own your own site.
This website is fundamentally a simple static set of files, served as web pages.
I maintain the content on a separate protected GNU/Linux "test" system, where I run various programs to maintain changes. Those include document processing programs (like a Docbook toolchain) and little scripts I've written (using XSLT, sed, shell, and so on). When writing text, I usually use the excellent text editor vim (yes, vim rules, though I do use emacs once in a while). I then use rsync and openssh to send the updates from my test system to the main website. The tool rsync does an amazing job at sending only what needs to be updated, so my updates can happen quickly, and openssh protects my communications from attackers. I've posted a little about using rsync to maintain web content. Using this approach, attackers will find it difficult to take over the update process, and even if an attacker takes over the main website, I always have a master protected copy (at my test system); I can simply re-upload my website and whatever they've changed is gone.
I've intentionally decided to serve only static pages from my website; this makes my site much harder to attack and gives excellent performance too. Not every website can decide to use only static content, with a separate site used for actual changes — but if you can, I suggest it. Nothing makes a system immune to attack, but I've tried to make it less susceptible.
My blog presents my own personal views, just like the rest of my site. I try to obey the law, of course, but please remember that bloggers have legal rights, including freedom of speech and freedom of the press. I could support user-written comments on my blog, but then I would feel obligated to police those comments from spammers and other lowlife. I just don't have time to do that, so I've disabled comments on my blog.
Much of the material is written using simple HTML. One wonderful thing about HTML is that it's a fully open standard: the specification is publicly available, not controlled by any one vendor, implementable by anyone without restrictions (such as software patent licensing), and supported by multiple products. Open standards are a good way to avoid the Pottersville anti-pattern.
I make sure that the HTML placed here is adaptable, and in particular that the HTML reflows (e.g., that it is "liquid" or "elastic"). I think fixed-width web pages are a terrible idea. I intentionally avoid specifying specific fonts, absolute font sizes, fixed table widths, and so on. Instead, I insist that every page on this site flows. The world wide web can be accessed on a variety of devices (handhelds, big screens, cheap systems usings old televisions, printed to printers) by people with a variety of needs (acute vision, poor vision, the blind, and so on), so it's important to let users determine how the information is displayed to them. When you let it flow as "liquid" then the material always works, no matter what the size. The claimed "problem" with liquid is that the reading lines are "too long". Guess what, some us like the long lines, especially when we're skimming material, and most reading on the web is skimming. If a user wants to limit the width, just drag the edge to the size they want. Again, users are different, by using flowing HTML the user can choose what best meets their needs.
I try to use the W3C HTML validator to make sure that the HTML is correct. More recently I've started using Pagespeed to detect problems (especially mobility / smartphone related issues).
I know how to use cascading style sheets (CSS), and I do use CSS, but I try to rig my HTML and CSS (especially on the front page) so that browsers that don't understand CSS can still display it reasonably. On many pages I don't bother to use CSS, or use it sparingly. In fact, in general I try to be conservative in my use of HTML - not everyone has the latest software, and keeping things simple lets me concentrate on content instead of on useless fluff. Keeping things simple also means relatively fast download times for people with slow connections. If you want dancing bears, sorry, none here. Here, content is king.
I write most of my dates in ISO 8601 (YYYY-MM-DD) format, in fact, I recommend that everyone use ISO date format in most cases. Different regions historically write dates differently, resulting in lots of confusion. Is "01-02-03" January 2, 2003? February 1, 2003? February 3, 2001? By organizing dates and times to from most to least significant, and always using the full year number, dates sort correctly, avoid the upcoming "2100" problem, and are clear to all. (If you use natural sorting, you even avoid sort problems with the year 10000.)
I am a security expert, but I also have limited time and little money. Remember, this is my personal site; since no one pays me to maintain it, I can't spend much time or money doing so. Like most small sites, this site can be easily taken down by significant distributed denial of service (DDoS) attack. I pay others to maintain my infrastructure (because I have limited time) and that infrastructure is shared with many others (because I have little money). A sophisticated attacker should be able to break in, unfortunately. I do apply various defensive measures, but since I can't spend a lot of time and money on them, I focus on recovery (e.g., by having many backups). That way, I can concentrate on releasing new goodies.
I try to be quite generous with how I license material on my website; my goal is generally to make information available for others! But please respect the limits I've placed on them. I often choose a "copylefting" license for stuff I post on my site; I don't make any money directly from the material, and by licensing it that way I hope to receive back improvements as payment instead. Most of the material here has licensing information attached with it.
Please do not mirror my paper Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! without permission. I often update that, and others haven't kept up, so I've decided to simply prevent certain kinds of mirroring for now. Its license is at the end of the paper. I hereby announce that on my death or permanent mental incapacitation, my paper Why (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! is automatically relicensed to the world under all of the following licenses; the user gets to pick which one(s): GNU Free Documentation License version 1.1 or later, the GNU General Public License (GPL) version 2 or later, or the Creative Commons Attribution-ShareAlike License. I may decide to revoke or change those terms before my death or permanent mental incapacitation; whatever terms are posted here upon that unfortunate event (for me) will be the release terms.
My front page doesn't obey the "rules" by some website "experts" and I this it's useful to explain why. There are many books that explain how to create website front pages, intended for use by large corporations with huge staffs whose sole job is maintaining the website, and trying to make the information easily findable and usable by users. I can't match that effort, and what's more, I don't think I should try. Instead, I'm inspired by the excellent paper "Government Data and the Invisible Hand", which explained why it is a mistake for governments to try to create one true way to access data. In their paper, they proposed that government should "specify that the federal government’s primary objective as an online publisher is to provide data that is easy for others to reuse, rather than to help citizens use the data in one particular way or another." I'm not the government, but I can take the same step — I can make the data easy to get and reuse, instead of being all things to all people. In particular, I can make it easy for people to search for what they need. Thus, the website front page is easily searchable for main topics, and every page on my site is easily traversed by web search engines. I work to choose clear titles, and add metadata to most HTML pages explaining what the page is about and what keywords would apply. I also work hard to NEVER change URLs, and to use URLs that hint at their content before people follow them (e.g., the URLs usually have a keyword or two, so people can determine if they want to read it or not). In short, I try to make it easy for people to find my material by using a search engine (such as the amazing Google). If a user gets to my front page, then they must be looking for a basic map of the whole site and so that's what I show. (Perhaps they're not sure what to look for!) This approach may not follow the "rules" of some books, but it makes it easy for me to maintain this site (necessary, because I need to spend time creating content), and I think it makes it easy for people to use (because they can use arbitrary search engines to find specific material, and the front page to see what's available).
Trademark notice: "dwheeler.com" (TM), "www.dwheeler.com" (TM), "drdavidawheeler" (TM), "dwheeler.xxx" (TM), "Provided by the Management" (TM) (as applied to a musical group), and "Provided by the Management for your Protection" (TM) (as applied to a musical group) are trademarks identifying products and services developed by David A. Wheeler. Obviously, you can use that phrase when referring to my site and materials - please do, that's what trademarks are for, to identify someone's material! But if you think it'd be fun to write something and fradulently claim I did it, write a book without my permission and use one of my marks in the title, or in some other way misuse these marks in a way that might mislead the public, think again. In particular, I've owned the domain name for years, and domain names have worldwide recognition, so don't try to steal it. (The problems of Katie Jones, owner of the katie.com domain, caused me to add this notice to clarify things.) In the past I asserted trademark status for "OpenFormula" so that whatever vendor-neutral standards body would have a clear, unencumbered right to it, and to make sure everyone can implement it. At this point that seems to have been accomplished, so I no longer assert a trademark status for "OpenFormula" (I'll let OASIS deal with that if they want to).
If you want to search my site using Google, without Google Adsense, you can do that here:
You can find out who links to this web site using Alta Vista.
Although I write a lot of my site's material, some of my site's material is provided to me by others. It is my policy and intent that anything posted on the site is 100% legal. (There may be a copyright, but as long as the use is authorized it is still legal.) If you believe that anything on my site is infringing, then please notify me as you would with any other service provider. (I am providing a network service, specifically a storage service.) As described in the Digital Millenium Copyright Act (DMCA) safe harbor laws, please notify me (David A. Wheeler) immediately if you are the copyright owner and believe that my site includes infringing materials. I am my own agent for copyright complaints. You must provide the usual DMCA information required for proper takedown. Since a takedown request must come from a copyright owner, you need to provide good evidence that you are the copyright owner or speak for the owner. (This counters the risk of a non-copyright owner sending a takedown for material they do not like, but have no authority to take down.) This is the proper notification and takedown procedure. Please remember that I am not a lawyer, and I am an individual not a company; I do not have the time or resources that a thousand-person company would have.
Feel free to go back to the home page.