The two stories of RISC

I said this implicitly in my entry on ARM versus other RISCs but I've realized that I want to say it explicitly: thereare (or were) effectively two stories of RISC development. You could seeRISC as a way of designing simple chips, or you could see RISC as away of designing fast chips.

In the story of simple chips, designing a RISC instruction setarchitecture with its simple and regular set of operations and registersand so on is a great way of designing a simple chip. You


My practical problem with preconfigured virtual machine templates

In comments on my entry on some VM mistakes I made ,people suggested setting up template VM images that I would clone orcopy to create live images. With that, every time I wanted a new VM I'dat least have a chance to think about its settings and if cloning waseasy enough I'd avoid the temptation to reuse an existing VM for sometheoretically quick (and not very important) test.

As it happens I've sort of started to toy with this idea but I thinkthere


Intel

My view of ARM versus other RISCs

Way back in my second entry on x86 winning against RISC a commentator asked:

And now you need to write who how ARM up-ending thisorderly structure of the universe.

Writing about this is hampered by my lack of knowledge of the detailsof ARM history, but after some reading I have my theory: ARM has beensuccessful where other RISCs weren't because from the first it wastargeted differently.

(This is not a matter of architecture, as I initially thought before Istarted reading. The


My sysadmin view of Python virtualenvs

It all started with a tweet from Matt Simmons :

Dear #Python devs: I'm reading this: (link) -How are virtualenvs not a security nightmare?

There are certainly many things that can go wrong with virtualenvs,but there are also many things that can go wrong with servers andOS packages ( as I tweeted , you canhave an obscure one-off server just as easily as you can have anobscure one-off virtualenv). My views on this are that there areboth drawbacks and


Some theories on why DNSBLs may be dwindling away

In yesterday's entry I mentioned that I hadsome theories about why anti-spam DNS blocklists might be diminishing(beyond the obvious one that running a good DNSBL is a pain in therear and people get tired of those after a while). I don't claim tohave the answer and I'm not sure that any of these theories are right,just possibly interesting.First off I think we can rule out the idea that DNSBLs are going awaybecause email spam itself is diminishing. Put simply


Are there less anti-spam DNS blocklists than there used to be?

Once upon a time, back when I paid a fair amount of attention toanti-spam stuff, there were quite a lot of DNS blocklists. Some hadgood reputations and some were more colourful, some were conservativeand slow-moving while others were much more aggressive and fast toblock, but there were any number of them that many people lookedat. I did enough in this area that I wrote a script to look up IP(s)in all of the worthwhile DNSBLs that I knew about.

Over


How SuS probably requires the 'run at least once' xargs behavior

A commentator left a long comment on my entry about how xargs behaves with no input arguing that theSingle Unix Specification for xargs actually requires it to not run if standard input is empty. I thinkit's more likely to be the other way around, so today I want to rundown why I think the SuS probably requires this annoying behavior.

There are two important sections of the SuS xargs specificationhere and I'm going to quote both, bolding important bits:

The xargs utility shall construct a command line


Two mistakes I made with VMs today

For reasons that kind of boil down to 'laziness', I only rarely deleteor create VMs in my use of virtualization . InsteadI mostly recycle or re-purpose already created VMs by reinstallingOSes on them, or sometimes not even reinstalling but just slappingsome additional packages on to the existing VM image. When I'm in muchdoubt about the state of a VM or need it to be in a different one, Ireinstall. Usually this works well, but today I discovered that I'dwound


Goodbye, djb dnscache

I've been using djb's dnscache for what is now a very long time;the dates on some old scripts suggest that I started using it onboth my home and office machines no later than some time in thesummer of 2004. At the time I switched to using it as my localrecursive DNS server it was for the same reason that I imagine anynumber of other people have; to put it simply I was tired of Bindbeing a pig. Dnscache promised (and delivered)


RCS should not be your first choice for version control

A while back I wrote that sysadmins should version controleverything and kind of advocated usingRCS for it. Based on one link to the entry Ithink that I may have confused people here about the merits of RCS,so let me clarify a bit.

RCS is a very old and rather primitive single-file version controlsystem. Today it only has two real virtues: it works on single files andit's trivial to start using it on text files. It's not your best choicefor a version