A bit on the performance of lexers in Python
This all starts with Eli Bendersky's Hand-written lexer inJavascript compared to the regex-based ones ( via )where he writes in part:
I was expecting the runtime [of the hand written lexer] to be muchcloser to the single-regex version; in fact I was expecting it to be abit slower (because most of the regex engine work is done at a lowerlevel). But it turned out to be much faster, more than 2.5x.
In the comments Caleb
Thinking about the security issues in HTTP 403 versus 404 errors
In the Unix world, the classical view of error responses for loginattempts is that you should behave exactly the same for invalid loginsas for valid logins; you should prompt for a password, you should spendjust as long 'verifying' the password, and then you should tell whateverit is making the login attempt simply 'you didn't succeed'. To dootherwise is to leak information to an attacker about what logins areactually valid, which is potentially useful in all sorts of contexts.
Fedora 19 and the search for volume management
Every so often I am unhappily reminded of one of the hidden problems ofmodern Linux systems. Today's direct problem is that when I upgraded myoffice machine to Fedora 19, automatic mounting of USB memory keys andso on stopped working because gnome-fallback-mount-helper ( whichis what I've used since Fedora 16 ) has nowdisappeared, just like every one of its predecessors. The real coreproblem is that a great deal of modern Linux is essentially opaque.
After all, I
Do specific HTTP error codes actually matter?
There are a few HTTP 4xx and 5xx responses that provoke specificbrowser reactions; the classic case is a 401 response to provoke anauthentication challenge for HTTP level authentication. But apart fromthose specific responses, does it actually matter what error code youreturn for a failed or rejected HTTP request?
If it's a human making the request, the HTML of the error page they seedoes matter; it's what they'll read to understand what went wrong. Butthat error text is
Systemd needs sensible, non-truncated output
If you run ' Yeah. What Perhaps the most common thing for me to do with people's source code isto add my own purely local changes . When the sourcecode is in a source repo, the simplest way of doing this is to just pulla copy of the source repo and then make my own changes on top. Thensooner or later I want to update my local repo by pulling in the latestcentral changes. With CVS, SVN, and even Mercurial this more or less just works, howevertheoretically unclean and evil it is Yesterday I wrote in passing that it wouldprobably be very hard to persuade us to go for a single vendor solutionfor our fileserver needs instead of one built onopen standards with replaceable components. Today I feel like justifyingthat casual aside, even though some people will consider it obvious. The simple version is that a (single) vendor solution requires moretrust. Everything is in the hands of the vendor, it is generally veryhard to inspect and verify the solution from the outside, and you arecompletely at the A few weeks ago, a commentator on one of my fileserver entries asked if we'd considered using Cephinstead of our ZFS plus iSCSI setup .My initial reaction was strongly and more less reflexively negative,but for various reasons I've been thinking about the general issuesinvolved off and on since then (partly because the timing for itis singularly good, since we have to migrate our data anyways ). One of the first steps of anysort of semi-objective evaluation of options is to come up with I've just been digging around in the depths of the ZIL and of ZFStransaction groups, so before I forget everything I've figured out I'mgoing to write it down (partly because when I went looking I couldn'tfind any really detailed information on this stuff). The necessarydisclaimer is that all of this is as far as I can tell from my ownresearch and code reading and thus I could be wrong about some of it. Let's start with transaction groups. All In yesterday's entry on the ZIL I mentioned that theZIL has some clever optimizations for large A simple, straightforward filesystem journal simply includes a full copyof each operation or transaction that it's recording. Many of these fullcopies will be small (for metadata operations like file renames), butfor data writes you need to include the data being written. Now supposethat systemctl status Jul 15 17:18:20 mumble123.cs.toronto.edu unbound[31622]: [31622:0] notice: in...
Git's petty little irritation for me
Why single vendor solutions are a hard sell
What we need in our fileservers (in the abstract)
ZFS transaction groups and the ZFS Intent Log
The ZFS ZIL's optimizations for data writes
write() s. To understandthese (and some related ZFS filesystem properties), let's start with thefundamental problem. Menu