Blogging for RWU Law

I'm gunna be blogging for my law school. The blog will be targeted at prospective students, so it might be interesting to some of you out there in blogger land.

I'll put up a link to the blog once I know the URL. Here's what _should_ be the starting-content on the new blog.

Bio
---
I'm not an honour student. I'm not on Law Review. I'm a regular joe schmoe. Well, I'm a regular law student, at least. I didn't graduate from high school. I spent five years at a community college. When I transferred to the University of California for undergrad, I majored in Philosophy, with a co-major in Law and Society. Now, I'm a 2L.

Three Weeks In
--------------
I'm sitting here contemplating my position on the first day of the fourth week of my 2nd year; the day after labour day.

Although one semester seems like a long time, and two is twice as long, law school goes by _fast_. I already need to be planning for summer internships and it's barely even September! I didn't internet last summer since I went on the London Study Abroad trip and needed at least _some_ time for my wife (i.e., to travel to visit the in-laws). So, I'm feeling a bit pressured as to what to do with my 2nd (and last) summer of law school.

The coursework itself, however, is much more manageable this time around. Only one of my professors seems to want to "make sure" that a student never comes unprepared twice. (First year, _all_ my professors seemed to go out of their way to impress upon us the importance of being prepared.) Combined with the fact that we're mostly all still smarting from last year's emphasis on preparedness and it means for a more fluid lecture. The professors seem to sense this, and so when a student _isn't_ prepared, they're much more willing to give him/her the benefit of the doubt and move on to another victimstudent.

Don't be confused, though: I have _hundreds_ of pages to read _every single day_. That's not really as scary as it sounds, but it's nothing to sneeze at. Speaking of reading, I've got some to go do.

White Rose: Three Branches of Government

I've just been thinking about the conceptual background to the modern fetish with dividing government into several (usually three) branches. The material I studied while studying abroad this summer, particularly the look at the English non-formal divisions, has led me to an interesting formulation:

The "executive" is the government. It is his job to govern the state. The courts are a check on his power. They make sure that his actions are fair, where fair is usually defined in reference to precedent and tradition. That is, the courts expect the executive to act predictably. The key element here is that the courts are retrospective; they look rearwards. A court has almost no power to affect future events, except to set precedent which will be available to a later court. They look at past events. They acquired this role due to their power of looking at past disputes between private individuals, expecting those individuals to act predictably: meet expectations explicitly set by contract, general societal expectations in torts, &c. The legislature is very similar to a court, except for that one key element. The legislature looks forward, not rearwards. The legislature's job is to _set_ those expectations in advance. The legislature has almost no power to affect past events.

I'm really not sure how well this describes the actual state of things, or how well it maps to history, or really whether its a good formulation at all. I like it, though.

What do you think?

Bash's init files

I finally understood the shell init files for Bash. I think my block might have been due to a left-over confusion from tcsh.

1. When bash is interactive it runs profile _or_ bashrc, not both.

1. If its interactive and login, it runs profile.
2. If its interactive and not login, it runs bashrc.

2. If its not interactive, it runs neither (unless you tell it to).


Easy, right?

My problem was that I was always thinking that a login shell might not be interactive, and so profile might run when not interactive.

There is an environment variable to set to get some init done in non-interactive shells, but normally nothing is done for non-interactive shells. ($ENV or $BASH_ENV.)

The only remaining problem is the "unless you tell it to" from above. This problem, however, is much easier to work with conceptually. In the simple sense, only profile can be easily told to load for non-interactive shells by passing --login. So, bashrc is exclusively interactive and profile is presumptively interactive. Sadly, because of this minor difference, it's not as simple as it sounds to separate.

I'm still not quite sure how to deal with this. The easy solution is just to source one from the other. That is, source bashrc from within profile. This is the solution that is adopted by almost every GNU/Linux distribution that I've ever seen. I believe this to be slightly suboptimal. It defeats the entire purpose of the separation.

Really, though, my problem is that I don't know what should be in one file and what should be in the other. What, exactly, should I make sure is loaded in login shells that is not as important in non-login shells?

Dropbox

I tried [Dropbox]. The promise of _working_ cross device file sync sounded really intriguing, but the final straw was [Elements]. Elements is a great app. I purchased, downloaded, and launched it. I signed up for Dropbox right there, then downloaded Dropbox onto both my laptop and my desktop.

Installation was drag-and-drop. From what I've heard, the sync works wonderfully. However, when I first launched the app on my laptop, it asked for my administrative user name and associated password. That's a bit odd for any app, especially one which does not modify the system in any way, so I investigated a little. Dropbox installs three pieces into one's system when it first runs.

The first one is the app itself, but when launched it marks two files within the app bundle as set-user-id-root (suid). This is extremely strange and extremely dangerous, from both a stability and a security perspective.

The second is a Contextual Menu Item, which is a plugin which adds an item to the right-click menu. However, in addition to the extra feature added to the context menu, this plugin also injects an additional "plugin" when it loads. This is extremely strange and extremely dangerous, from both a stability and a security perspective. (This plugin was for finder.)

Third, it installs a file named ".dropbox" (w/o quotes) in one's home folder. The placement of this file is strange (the appropriate places would be ~/Library/Application Support/Dropbox and ~/Library/Caches/Drbox), but not at all dangerous.

Some of these mistakes come from Dropbox's recent addition of Mac support. That is, they just don't know any better. On windows, significant stability damage through the use of novel and unexpected code injection is the norm. A carefully designed "plugin" would put no more strain on the system than what comes on the system from the original manufacturer. (I'm not saying that windows is more stable with "plugins," but that nobody would notice the instability introduced by these "plugins.") On Linux, suid binaries are entirely normal. In fact, significant parts of the user land live entirely in root space, e.g. the X window system itself. There, the security implications are dealt with through over engineering and careful disclosure, while the stability implications are expected to be dealt with by the system administrator (read: end user).

On Mac, however, stability and security are two of the platform's primary draws. Those two reasons are exactly why I, myself, use a Mac. Furthermore, as a software developer, I can clearly see solutions to the problems that Dropbox appears to have been attempting to solve. For example, the contextual menu could be provided by a "service", thereby bypassing the need for _that_ plugin. The code-injected Finder "plugin" could be scrapped entirely and replaced with careful use of custom folder icons, supported by the very same folder-change-monitoring system used to watch for actual content changes. Actual content changes could be provided by the system that Apple built into the platform for that very purpose: FSEvents. This is part of the system that Spotlight and Time Machine use.

I uninstalled Dropbox shortly after my investigation. Perhaps I'll try it again once they've had a change to fix up their Mac support.

[Dropbox]: http://www.dropbox.com/referrals/NTEwMzMwNTEwOQ

Back from London, Back to School

This summer I spent five weeks in London with RWU Law's very own Professor Robert Webster. Around thirty other students and I explored the history of the common law, and where it has led to, right where it began. That, and we explored London and the surrounding area... and Dublin.

The focus of the program was Comparative Trial Advocacy. Now, I have never intended to be a litigator, but not only did I enjoy the adventure and learn a great deal about what it takes to tango in the High Court, but I also learned that litigation isn't exactly what I had thought. I can see myself as a litigator (although it's still not on the top of my list).

The last two weeks, an optional extension for an additional 3 units, really tickled my fancy. This second part was entitled Comparative Constitutional Perspectives. The focus was privacy. I've come away with a whole new appreciation for both perspectives on privacy, new vocabulary for describing those perspectives, and a whole new theory all my own. (You'll have to wait for me to publish _that_ one later.)

Finally, two weeks to relax with my wife and now school is back on. My favourite class this semester? You guessed it: constitutional law. Well, that or Professor Santoro's Business Organisations.

Shared Hosting

So, I signed up for a shared hosting account with [Bluehost].

So far, so good. There are a few things that bug me about shared hosting, but generally it seems to be a good buy. I've manually installed [Drupal] (I didn't want to use simple scripts or whatever) and [git]. I'm using drupal's multiple-site support to host two sites across three domains. I'm planning on using [Flashbake], but haven't yet imported my [RCS] repositories. (Yes, I use RCS.)

There are two big problems with shared hosting. First, configuring [HTTPd]. All configuration has to go through [.htaccess]. This means that [mod_alias] is generally unusable, along with a smattering of other configurables. Modules like [mod_rewrite] are not fully functional, either. Although mod_rewrite can cover for most of mod_alias's lost functionality, it still can't map to a folder outside of public_html.

The second big problem is debugging. I don't have root, I can only see my own home folder, I can't reboot, I can't even look at httpd.conf. Worse, someone else's misconfigured .htaccess is spewing multiple warnings per second into the shared httpd error_log, so I can't even see my own warnings and errors. The RewriteLog option in mod_rewrite can't appear in .htaccess. Debugging boils down to experience and trial and error.

Since the system is both pre-configured and configured for shared use, there are a vast array of variables which are unexpectedly set. For example, my Drupal installation couldn't send e-mail until I figured out that the shared host had assumed that it would be my DNS host and so had masked my MX and A records, thereby making my own web server unable to see it's own domain configuration. I had to debug _this_ before I could change it.

That said, that's not too bad. I have shell access. I have full control over the on-the-shared-host DNS settings (so I just deleted everything). I even have enough control over the mail configuration to tell the MTA to require _authoritative_ DNS, not just local, thereby bypassing the MX problem altogether. I can use mod_rewrite to set a number of options which mod_alias would normally be used for, or which would otherwise require additional folders/settings outside of public_html, such as cgi-scripts. (I can use mod_rewrite to match, but not rewrite, a URL and then force a particular "handler" for it, thereby allowing cgi-scripts at convenient URLs while simultaneously allowing the _data_ for those scripts to be outside public_html. In fact, I've actually installed drupal outside of public_html and use four tiny php scripts and two symlinks to make it usable. (The idea is to keep as much as possible outside of the dump-raw-by-default HTTPd folder.)

Stay tuned for my posts on Drupal and mod_rewrite specifics.


[Bluehost]: http://bluehost.com
[Drupal]: http://drupal.org
[git]: http://git-scm.org
[Flashbake]: http://wiki.github.com/commandline/flashbake
[RCS]: http://www.cs.purdue.edu/homes/trinkle/RCS/
[HTTPd]: http://httpd.apache.org/
[.htaccess]: http://httpd.apache.org/docs/current/howto/htaccess.html
[mod_alias]: http://httpd.apache.org/docs/current/mod/mod_alias.html
[mod_rewrite]: http://httpd.apache.org/docs/current/mod/mod_rewrite.html

purge(8)

## Warning ##

__IMPORTANT__: DOING THIS TOO OFTEN WILL SIGNIFICANTLY REDUCE PERFORMANCE. Furthermore, the equivalent happens _automatically_. __THIS IS A TOY ONLY.__

## Fun With Debugging Tools ##

Do you like it when Activity Monitor reports large amounts of free memory, regardless of actual performance? Try this: open Terminal and just type "purge" (without quotes).

OMG WTF BBQ

Pretty neat, eh?

## Details ##

The purge(8) utility is a debugging tool which interacts with the Unified Disk Cache. Basically, Mac OS X (and all modern OSes) keeps recently (or frequently) used files in RAM, since it is fairly likely that they'll be used again very shortly. This does, in fact, happen more often than not.

Most files are tiny and read once and "never" again. (We're talking about seconds here, so re-opening the same file tomorrow or after lunch is like talking about how your house will look in the year 2256. Its just as good to say "never.") These files drop out of the disk cache quickly enough, since they're closed (programatically) as soon as they're opened. Other files are enormous (many megabytes) and are rarely merely loaded and closed. Instead, these files are frequently read partially, again and again, and often modified in-place. Often, these files aren't ever read start-to-finish, and certainly aren't closed once read. Examples include databases, any sort of for-editing media (audio, video, images, animation, &c.), and even not-for-editing consumer-targetted media files (like a 1.4GB movie downloaded from iTunes).

Most applications interact with files in ways that lets Mac OS X know which category they fall into: open and "discard", or frequent access. Even when they don't, Mac OS X is fairly good at guessing.

When an application behaves as though it is _clearly_ within the frequent access category (i.e., working with enormous files that simply couldn't fit into RAM at all), an app may nevertheless explicitly tell the system that it is really in the other category. Creating a new ZIP or TAR archive, or exporting from source material to ProRes, are some examples of this sort of exception.

The problem comes in when an application is working with those aforementioned enormous files, but neglects to tell the system that it really should be in the other category. The purge(8) utility exists so that a developer or system administrator can debug this situation.

### [Purge(8)](man:purge.8) ###

The purge(8) utility merely empties the aforementioned disk cache. That's all.

Just like all caches, the purpose of the cache is to increase performance. And, just like all caches, emptying the cache is usually pointless and generally unnecessary. Just like all caches, it will clean itself over time. Unlike the cache in a web browser, though, "over time" is minutes not days or weeks. However, just like the cache in a web browser, it is extremely unlikely that you will get any performance improvement by manually emptying it.

In rare situations, however, a developer or system administrator may know _specifically_ of a situation where the built-in heuristics will guess wrong, or at least not guess quickly enough.