qjz

DNS blacklisting is useful and has its place, but I would expect a secure-by-default browser to not load any resources from domains outside the one in the requested URL (like lynx) and to provide a simple way to selectively whitelist external resources for that domain only (like the RequestPolicy Firefox extension). That's one important omission from your otherwise impressive list of features that will probably make me stick with Firefox + Vimperator + RequestPolicy.

Since switching to dwm, I can't even remember what I used a desktop environment for (I went from KDE to Gnome to XFCE to (black|flux)box to dwm). Based on your usage, I'm surprised you'd consider leaving xmonad for something as alien as KDE4. Give me the speed and screen real estate of a tiling window manager any day.

It's a very bad habit to use -p for every invocation of mkdir, and it's not appropriate in any of the examples where it's used. For one thing, it will never complain if you get the path wrong (provided you have the necessary permissions) which is particularly undesirable when doing remote work.

Darcs merits a nod, as well.

File and directory names can contain spaces and require special treatment. This should be addressed up front, before introducing commands with side effects.

Not necessarily. It only takes one bureaucrat to reject code that doesn't pass tests or follow required conventions. For example, a good rule of thumb is that no new code will be accepted without documentation.

Now I understand the reason for the existence of those annoying special-purpose CDN domains that I'm always forced to allow in RequestPolicy. Thanks for the explanation!

Well, then why not just use 1e100.google.com for this purpose? There's a reason it's called a domain, and it seems kind of silly to create and maintain unrelated hierarchies.

A great font is one that fit’s it’s purpose.

Sentences like that burn my eyes in any font.

"Controversial work of art skyrockets in value."

Starting out with a calculation based on retail price is pretty shrewd and helps fuel the conversation.

Our project focuses on advanced and experienced computer users. In contrast with the usual proprietary software world or many mainstream open source projects that focus more on average and non-technical end users, we think that experienced users are mostly ignored. - from Suck Less Philosophy at http://suckless.org/manifest/.

I don't feel this translates to "no noobs" as much as it means "don't stop with the noobs." I'm pretty sure inexperienced users are welcome, but there's no interest in adding hand-holding features that conflict with the philosophy of "keeping things simple, minimal and usable." I use dwm & dmenu all the time, and have developed a real appreciation for the Suck Less approach (but I'm not a newbie, so I guess I'm safely in their target audience).

Isn't that a false dichotomy? You left out completely free content, which is still abundant and could hold your attention each and every day. It seems most ad-driven sites are fueled by screen scraping or opining on external content without adding much value.

In practice, it seems that advertiser dollars always trump subscriber fees.

I wonder if there will be many winners from these music wars? I've been seeking out music released under Creative Commons licenses via Jamendo and the Internet Archive for a while now, and the quality and selection continues to improve (not just click hop, noise or tracker-based techno anymore). Most artists don't benefit from their relationships with labels, so anything that reduces their exposure can hurt their main sources of income (performances, merchandise, etc.). It will be interesting to see if new artists start ignoring labels because they simply aren't worth the trouble.

I dislike the trend towards light grey text on a white background. Unfortunately, the article itself is guilty of this. It's fine for timestamps and other page noise, but why dim a blockquote?

Only 52 precent of American adults support punishment at all

It seems the real story is that 48 percent support no penalty at all. Why the misleading (and inaccurate) headline?

They’re addressing other users, asking “Is anyone else having this problem?” What’s that about? How is finding other with the same problem going to help you?

Sounds like the user hasn't ruled out a configuration error or buggy device and is simply looking for a solution. This is due diligence before reporting a bug (along with reading the documentation, of course).

That strategy isn't as cost-effective as sending the principal to Cancun for a "conference."

You can also boot live ISOs, which don't maintain state between boots.

Space on a hard drive is finite, no matter how much it costs, and the size requirement makes it particularly unattractive for running in a VM, compared to a leaner OS.

I also wonder if it can tell the difference between a teenager and the person who actually pays the energy bill.

I have a love/hate relationship with my smartphone, but I'm still amazed at some of the things I can do with it. Adding to your list:

When my car's GPS took me miles down a road that was washed out on a trip hundreds of miles from my home, Google Navigation on my smartphone suggested a different route that got me safely to my destination.

It's a flexible and reliable alarm and kitchen timer.

I can read novels comfortably in bed on my smartphone (none of my several laptops are very ergonomic for this purpose).

I can map my bike rides and get stats on min/max/average speed, elevation, etc. (all the while using it as a music player).

It lets me easily maintain multiple shopping lists.

I can tune my guitar with it.

It functions as a real flashlight (my phone has a very bright LED).

My smartphone is no replacement for a computer, but it's better at these tasks than any computer I own.

Apple - iCloud - Your content. On all your devices.

That is the title of Apple's main iCloud page at http://www.apple.com/icloud/.

iCloud is seamlessly integrated into your apps, so you can access your content on all your devices.

This is Apple's definition for the iCloud service. It doesn't matter what the data is, it's your data and Apple is promising to sync it between your devices, to preserve your experience.

In the case of Instapaper, the solution is obvious: Put the files in Documents. That is Instapaper's content and part of the experience that users want synced between devices.

If Apple penalizes developers and undermines the promise it is making to users because it decides to be miserly about bandwidth, then it has to admit it launched iCloud before it was ready.

FWIW, I was once like you and resisted getting a smartphone for quite a while. Now I'm no longer chained to my desk. I can go on an epic bike ride, chart it with GPS, and never miss an important email. If anything, the smartphone has given me more freedom, improved my health, and increased my awareness of my surroundings (never get lost, locate nearby businesses/attractions, leave the house more often). The nice thing about a smartphone is that it spends most of the time in your pocket. You only pull it out when you need it.

Ideally, we would write everything in plaintext, but it doesn't support even the most basic features offered by typesetting (bold, italics, etc.) or hypertext (embedded links), so we turn to markup languages at the expense of readability.

Markup syntax like markdown, asciidoc, reStructuredText, etc. strive primarily to preserve readability with the least obtrusive syntax, and with a smaller learning curve (at least for the most basic usage).

So why use it instead of HTML? Like you, I typically write HTML in HTML, but often use asciidoc for other purposes (documentation, recipes, quick notes, etc.), because:

- One source document can output to multiple formats, like XHTML, LaTeX, PDF, DocBook, EPUB, Man page, etc. It's even trivial to output to a specific HTML DOCTYPE. That's pretty neat!

- Diffs are far more readable when not swimming in markup soup.

- HTML is overkill for many purposes. In fact, lightweight markup has its roots in email/newsgroup markup. HTML email is still a compatibility nightmare. Wouldn't it be great if a new standard for rich text email was developed, based on something as simple as markdown? It would be trivial to support it in webmail interfaces and the source would still be readable in plaintext email clients or if the sender went overboard with style choices.

- Archivability. Many old HTML documents render poorly in modern browsers, mainly due to style choices that seemed sensible at the time. Lightweight markup focuses more on the content and discourages going off on a stylistic tangent you may regret later. In other words, it does a good job of separating content from presentation, so your source documents will always remain readable and transform to something readable with relatively few tweaks in external stylesheets or configuration files.

Because it's easy to learn without getting lost in the arcane details of validation and compatibility, it's understandable why it's gaining popularity.

On a related note, one of the web sites I frequently use stripped all spaces from my password without notice before storing it on the server. So when I registered with a password like 'I am Sam', I found I could only log in using 'IamSam'. Any attempt to use the original password caused an error. I reported this to the site admin, and the solution they came up with was to silently strip the spaces from the password as it is typed into the form. Now I can type in 'I am Sam', but 'IamSam' is the actual password sent to the server. File this under '2 wrongs don't make a right'.

All good points, but allowing 8 characters still allows '12345678' and 'password', two of the most egregious examples of weak passwords. Granted, weak passwords will always scale to the next minimum ('123456789' or 'passwords' for 9 characters), but 8 character passwords are already among the lowest hanging fruit, so including them in the minimum is misguided.

Passwords must be 8 characters or greater

Half of the top 50 cracked Gawker passwords were 8 characters (and longer passwords were not exposed, due to the nature of the vulnerability). Since 8 character passwords are vulnerable to a known common weakness (in DES), this should be revised to:

Passwords must be 9 characters or greater

This will prevent your users from using passwords that are vulnerable to the DES attack if they reuse them on other sites.

This reminds me of Vonnegut's Ice-nine, but in the inverse. Drop one in the ocean and watch it disappear in a puff of gas.

"Science is magic that works." -- obligatory quote from Cat's Cradle

Not only that, but what's to prevent them from caching content after the first client makes a successful direct connection? After that, they can serve the cached content quickly to other Silk users. Circumnavigating such blocks may even be one of the driving forces behind developing Silk in the first place, since it allows Amazon to access content they can't easily reach otherwise.