Differences in URL and site layout between static and dynamic websites
One of the big but subtle differences between a statically renderedsite and a dynamically rendered one is simply how you design the URLstructure for both of them. One example here is dynamically renderedversus statically rendered blogs.
Broadly speaking, in a statically rendered site you want to have aminimum number of URLs and for each chunk of core content to appear ina relatively minimal number of places, because you have to pre-generateevery URL. The more you let content and URLs propagate, the more pagesyou have to
Avoiding reboots should not become a fetish
Unix is designed so that you shouldn't normally need to reboot it tofix problems and in most environments it's considered good practice tostick with this and not reboot Unix machines casually, or even very muchat all. People have rightfully mocked the approach in other systemsof rebooting as a routine troubleshooting step (often an early one,sometimes the first one). Unfortunately it's quite possible and in factnot uncommon to take this attitude too far and make not rebooting into afetish. The symptoms
Thinking about when rsync's incremental mode doesn't help
I mentioned recently that I hadseen cases where rsync 's incremental mode didn't speed it up to anysignificant degree. Of course there's an obvious way to create such asituation, namely erasing and replacing all of the files involved, butthat wasn't it for us. Our case was more subtle and it's taken me awhile to understand why it happened. Ultimately it comes down to havinga subtly wrong mental model of what takes time in rsync .
Our specific situation was replicating
Killing (almost) all processes on Linux is not recoverable
Suppose that you have at least a semi-hung system that you're takingdrastic measures to get at least semi-alive again; for example, youmight use Magic Sysrq 's option to send a SIGTERM or SIGKILL to all processes except init ('e' or 'i', per here ). If you do this,it's quite possible that your system will stagger dazedly around for abit and then seem to come back to life. Oh, sure, maybe you need torestart
Why I like ZFS's zfs send and zfs receive
Our new fileserver environment to be has reached the point where itneeds real testing, so on Monday I took the big leap and moved my homedirectory filesystem to our first new fileserver in order to give itsome real world usage. Actually that's a bit of a misnomer. I'd copiedmy home directory filesystem over to the new fileserver several weeksago simply to put some real data into the system; what I did on Mondaywas re-synchronize the copy with the live version and then switch all
Simple versus complex marshalling in Python (and benchmarks)
If you have an external caching layer in your Python application,any caching layer, one of the important things that dictates itsspeed is how fast you can turn Python data structures into byteblobs, stuff them into the cache, and then get byte blobs back fromthe cache and turn them back into data structures. Many caches willstore arbitrary blobs for you so your choice of marshalling protocols(and code) can make a meaningful difference. And there are a lotof potential options; marshal , cPickle , JSON,
Rebooting the system if init dies is a hack
I feel like I should say this explicitly: rebooting the system ifinit dies is a hack . It's the easy thing to do but not the rightthing. V7 Unix more or less ignored the possibility of init failing;when BSD started considering this situation they took the easy way outof 'handling' it by just rebooting the system. Everyone since then hascopied BSD (probably partly out of compatibility, since 'everyone knows'that if init dies the system reboots, and partly because it'
You don't have to reboot the system if init dies
One of the thing that makes PID 1 special on many systems is thatif it ever exits or dies for any reason, the system will reboot. This behavior was introduced by BSD Unix (V7 ignored the possibility) and makes a certain amount of sense;init is crucial both for reaping orphan processes and restartingserial port logins. If it goes away, rebooting the system is aneasy way to hopefully fix the situation.
However, this behavior is not set in stone. There are severalalternatives. The first
Guessing whether people will unsubscribe from your mailing lists
Suppose that you have an administrative mailing list ( or mailinglists ), you understand that peoplecan always unsubscribe one way or another ,and you want to have some idea if people are going to do so. Here ismy modest suggestion on a simple question to ask yourself about themessages going to the mailing list: are the mailing list messages actionable ?
(Alternately you've been forced to run some mailing lists that peoplecan't officially unsubscribe from and you'd like some guess at how manypeople
Logins and related things really do change, and for good reasons
Every so often it's popular to say that you will never, everchange a (Unix) login, an assigned email address, or whatever. Nodirect renamings, no new account to replace the old account , no nothing. Generally this attitude comeswith a certain mixture of 'you should have got it right the firsttime' and 'if your login is less than ideal it doesn't really matter'.
This is wrong (and arrogantly blind). People periodically haveexcellent, compelling reasons to