:breaking things
creating, breaking, taking apart, and rebuilding. we have the technology.
:vision
do not step out
:breaking things
twitter.com/mikeysan
speedbump
20/Sep/2009 | 23:12

Here's a list of the most popular issues in the current release of Sandbox:

- The dsrunner tool (internal Sandbox support tool) may crash in some Open Directory environments. This prevents Sandbox from populating its users and groups list, and results in a user-visible crash notification dialog. Sandbox will still function, but you will have to know the name or UID of the user or group you need. This problem is understood and will be fixed in the next update. It is not specific to Snow Leopard.

- Under Snow Leopard, the first time you click "Inspect Folder...", you may encounter an error dialog. This sucks, but it's harmless. Retrying the button should work on the second try, but this isn't guaranteed, unfortunately. I have a good idea of what's happening here, and will be fixed in the next update.

- Under Snow Leopard, scrolling in the file system browser may also generate error dialogs and erroneous browser items. There is no workaround for these problems. They're also benign, if you consider really fucking annoying benign. I have a good idea of what's happening here, and will be fixed in the next update.

- Under Snow Leopard, you cannot enable or disable ACLs on volumes via Sandbox. The fsaclctl tool has been removed from Mac OS X as of 10.6, so either I disable this functionality or come up with a different solution. I haven't decided how best to handle this.

Where does that leave us? What's the roadmap here?

THINGS I DON'T LIKE:

1. Maintaining shitty code bases.
2. Announcing release dates before things are done.
3. Disabling existing functionality.

I'm going to do the first two right now, and try not to do the third. It shouldn't be a lot of work to fix the three "definitely fixable" bugs, so even though I've sworn to myself I won't touch the 2.x code base anymore, I'll be doing that in the next two weeks. And with that, I've done #2.

3.0 is still on the table, but my work schedule really cuts into my time and energy for personal software endeavors. It'll be a ton of new code and some pretty serious interface changes, so you probably won't hear a peep about it until it's pretty far along and I'm sure I can finish it.

See you soon. Thanks for your patience.

Update (25 Oct 2009):

Okay, pulling a release date out of my ass was a bad idea, as I expected it would be. It's more work that I thought, and I haven't had any time to work on it because of my day job. Stay tuned.

link to: speedbump

file under: breaking things | comments (0)

sandbox 2.2
04/Jun/2008 | 14:05

After four months of starting work on it, Sandbox 2.2 is now available. People have been (very patiently) waiting for a Leopard-compatible release for way too long, but I needed to do a lot of things behind the scenes that simply took longer than expected. That whole "spare time" thing also got in the way a bit. For these reasons, I'm glad I made the decision to release betas early and often. In this sense, Sandbox has been available for Leopard users since March.

I didn't get as much feedback on the betas as I'd hoped, but you never do. People are busy, and it's difficult to take the time to stop what you're in the middle of, document an issue or enhancement idea, and then submit it. That's an entirely separate article. I'm happy people did use the betas, however, and that no one e-mailed me in a frenzy about their RAID being turned into charcoal or something else equally oh fuck.

It's fitting, I suppose, that this (rather major, though it isn't obvious) update coincides pretty closely with Sandbox's third birthday. What can I say, I stick with what I choose to do. Thanks for being my users for the last three years.

The official changes list for 2.2 is below (and in the update feed for the app itself, if you use the built-in software update in 2.0 and later).

Tear it up, kids.

Sandbox 2.2 icon

Sandbox 2.2 is an important update for all users. It contains many bug fixes, performance enhancements, and brings full Mac OS X 10.5 Leopard compatibility. Additional features include:


link to: sandbox 2.2

file under: breaking things | comments (0)

bee three
17/Apr/2008 | 02:14

Dear Mac OS X administrators,

Sandbox 2.2 beta 3 is now available for download. It brings Leopard compatibility, speed improvements, and fun stuff under the hood you'll never care about. The beta will expire at the end of May, 2008.

Here are some general release notes.

Questions and bugs can be sent to the e-mail address in the readme.


xoxo,
mikey-san

link to: bee three

file under: breaking things | comments (0)

browsed
18/Mar/2008 | 05:09

I thought it would be neat to give people an update on Sandbox in screenshot form. Click for big:

sandbox file browser

I wish I had the time to rewrite the entire thing Cocoa-style right now, but it's a pretty big job. I've moved the rewrite to the 3.0 roadmap, which will allow me to sit down and really think about it. For today, Sandbox 2.2 is a chimera, internally, of several languages and environments.

Roads? Where we're going, we don't need roads.

link to: browsed

file under: breaking things | comments (0)

sandbox beta
11/Mar/2008 | 00:51

http://www.mikey-san.net/sandbox/

As you can see by the SCARY RED TEXT, this doesn't work in Leopard. Yet.

I'm getting very close to beta with Sandbox 2.2, the next update to the access control list editor for Tiger Client and (soon) Leopard Client. (You can use it on Server, and some prefer it to Workgroup Manager. But we won't get into that.)

I need beta testers! If you have ACL experience and want to risk life and limb, send me an e-mail and I'll send out the info when the beta is ready to rock. The e-mail should include your REAL NAME so I can give you testing credit, detailed specs of the machines on which you expect to test Sandbox, and whether or not you've used Sandbox in the past.

Sandbox 2.2 is slated to include the following changes:

- Leopard compatibility
- Rewritten software update mechanism*
- Discovery of users and groups outside of the local node
- Integrated authenticated file system browser, no longer launches a helper
- Rewritten NetInfo/Directory Services support*
- Other stuff rewritten under the hood*
- Other minor bug fixes and performance enhancements

* Denotes stuff you won't notice but looks great in release notes.

Who wants to party?

link to: sandbox beta

file under: breaking things | comments (0)

talk to me
14/Dec/2007 | 06:54

It's time for a Sandbox update.

I know of several problems with Sandbox under Leopard, but have not been able to get to ironing them out. They're not major, but I've been without the time to devote to fixing them. Until now, that is.

I left my day job earlier this week and now have spare time to devote to projects like Sandbox. (That is, until I decide it's time to be a day slaver again.)

Here's where you come in.

When I started Sandbox, I used it as an experiment to learn AppleScript Studio. Sandbox 2.0 was an extension of that knowledge, eventually including a light sprinkling of C and Objective-C for version 2.1. As I look at Sandbox, I realize something:

While I believe Sandbox 2.x is one of the best AppleScript Studio applications out there, all eras come to an end eventually.

See, I'm dying to take the existing interface, refine it further, and rewrite the internals from scratch in C + Objective-C. The current code isn't unmaintainable, but I've come to realize that every time I look at it, I want to go read Something Awful instead. Sometimes, you see, languages are barriers to wanting to work. AppleScript, for me, is a barrier to work these days.

I want to add one or two things, and I want to change how parts of the interface work. The prospect of implementing these changes in AppleScript just isn't appealing to me—and in fact, is a deterrent. Not only would I like to add a thing or two, I'd like to prep the project to make it easier to add more unknown things in the future.

Now.

First, let's make it clear: I'm never going to require payment for Sandbox. Ever. Don't misread what I'm about to say.

There are two roads we can go down. I can fix the few bugs I know about in Leopard and put this thing away until something breaks—and some very smart people would say this is what I should do, and they wouldn't necessarily be wrong—or I can begin Sandbox 3.0 and make the architectural changes I want to make. The latter is not a two-week process, and Sandbox may then turn into donationware, but I think this route would to be the better choice for the future of Sandbox.

My question to my users, then, is:

What do you want the future of Sandbox to be?

E-mail me. I want to know what Sandbox has done for you, what it hasn't done, and any opinions you might have on the possible existence of a Sandbox 3.0. Including free vs donationware. (SAME THING.)

org dot bungie at mikey-san

Hope to hear from you.

link to: talk to me

file under: breaking things | comments (0)

two point zero
21/Apr/2006 | 09:07

Sandbox 2, the GUI access control list editor for Mac OS X 10.4, is out. Go get it.

We're sporting a completely redesigned interface and several new features.

http://www.mikey-san.net/sandbox/

The Sandbox 2 icon

The beautiful spade in that icon is courtesy of Steven Tzé.

link to: two point zero

file under: breaking things | comments (0)

contrasts
21/Oct/2005 | 21:36

A valid complaint I've heard more of as my traffic has increased is the severe lack of contrast on some areas of this page.

My ColourSync profile is very dark and a little warmer than most people's; well-saturated. During the original construction of the design, I forgot to take this into account and didn't adjust my colour management workflow to accomodate. Oops. I'd like to apologize for this in public since you're taking the time to read the site.

I should know better than this.

A high-contrast version is planned. I'd love it if readers could post well-written criticisms and ideas in the comments. I'll read over them and give take them into consideration as /damage gets tweaked.

Thanks.

link to: contrasts

file under: breaking things | comments (4)

more sodium
17/Jul/2005 | 08:16

Sandbox has hit version 1.2. Big update! Cool new shit! It's a very important update for you Fink users out there, but really, everyone should update. And no, the disk image itself no longer requires Tiger. (For all of you varied deployment mofos out there. Just remember Sandbox requires Tiger to work!)

To mark the occasion, I've given Sandbox its own happy place on the Interwebs:

CLICKY CLICKY.

link to: more sodium

file under: breaking things | comments (1)

sandboxing
12/Jul/2005 | 15:47

Hello, World.

There's no official page for it yet, but Sandbox is at the above location.

S-so, what is Sandbox?

From the documentation:

For years, standard POSIX permissions did a good job of defining access to our files and folders. But as our needs have become more complex, operating systems have begun implementing access control lists to help handle things. When Apple shipped Mac OS X 10.4, they brought their ACL implementation to the table, along with a GUI to deal with the mess.

That is, if you're running Mac OS X Server, which comes with Workgroup Manager. Otherwise, it's /bin/sh for you, buddy boy.

Enter Sandbox, stage left.

That's right, Tiger Client now has a GUI-based access control list editor.

Please note: Sandbox requires Mac OS X 10.4 or later, as ACL functionality does not exist in prior versions. The disk image won't even mount on pre-10.4 systems.

If there's something it's missing (and isn't mentioned in the documentation), drop me a line and I'll see what I can do!

link to: sandboxing

file under: breaking things | comments (6)

no soup for you
03/Jul/2005 | 08:48

AppleScript Studio vs DirectoryService: Round One

This morning, my system log has a story to tell:

Jul 3 07:34:06 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:10 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:12 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:14 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:16 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:18 mikeys-computer authexec: executing /bin/sh Jul 3 07:34:22 mikeys-computer DirectoryService[41]: Failed Authentication return is being delayed due to over five recent auth failures for username: mikey.

I've been developing a big AppleScript Studio application for the past week, and I'm getting close to an initial release. The script passes several commands to the shell via do shell script while obtaining privilege by utilizing with administrator privileges. Think of it as sudo for AppleScript:

do shell script "/usr/bin/true" with administrator privileges

This is analagous to sudo /usr/bin/true, except that you get a nice, standard Mac OS X authorization request dialog to go along with it.

Now, In Mac OS X 10.4, with administrator privileges doesn't use sudo, it uses SecurityServer. Specifically, it calls AuthorizationExecuteWithPrivileges() to gain privilege for executing commands with /bin/sh. It would appear as though SecurityServer isn't pissed off (as I find nothing but successful authorizations by SecurityServer in secure.log), but DirectoryService is definitely throwing a hissy fit. The question is, though, just what's going on here?

(If anyone has corrections to the above, please hit me in the comments.)

At any rate.

The app, which I'm going to release despite the problem I'm about to describe, makes extensive use of this authorization feature [of AppleScript], partially because the nature of the app calls for (CALLS FOR, GET IT, IT'S A PUN) several of its authorization-hungry functions to be performed multiple times. Where things get ugly is after several successful authorizations, when the system throws an error (Failed Authentication) and begins delaying return. This means that after a few successful commands, the system starts increasing the delay between executed privileged commands. What's throwing me for a loop (MORE PROGRAMMING HUMOUR) is that nothing's actually being denied; I'm still successfully executing the commands that are being issued via do shell script with administrator privileges.

Here's a test program (Xcode 2.1 required to build), source code included.

So is this a bug in Tiger? If so, whose fault is it? AppleScript? SecurityServer? DirectoryService? If it's not a bug in Mac OS X, but a problem with how the script is written, how can it be solved?

Anyone willing to help dig into this one?

Update: Plot Thickens

I've continued to experiment with this issue, and I've found that this form of the command does not trigger it [the issue]:

do shell script "true" user name theUser password thePass with administrator privileges

Unfortunately, this method requires that you get and set the user name and password without the standard Mac OS X authentication dialog. I find this unacceptable from a security standpoint, since this would require declaring the password—in plain text or weakly obfuscated—as a global or a property in the script. You could pass it like(this) from handler to handler, but I'm still weary of this method.

Before I digress terribly, /var/log/asl.log tells a slightly more verbose story than system.log does:

[Time 2005.07.03 20:01:24 UTC] [Facility auth] [Sender authexec] [PID -1] [Message executing /bin/sh] [Level 5] [UID -2] [GID -2] [Host mikeys-computer] [Time 2005.07.03 20:01:26 UTC] [Facility daemon] [Sender DirectoryService] [PID 41] [Message Failed Authentication return is being delayed due to over five recent auth failures for username: mikey.] [Level 1] [UID -2] [GID -2] [Host mikeys-computer]

At least that second line isn't showing up anymore, even if that means I can't use standard system dialogs. For now.

link to: no soup for you

file under: breaking things | comments (2)

rwxomgwtf
29/Jun/2005 | 14:31

I've been working with Tiger Server's access control lists lately, in various file tweaking flurries. Server Admin's interface for manipulating them is decent, but chmod is also really usable, if you know the modes you can set. Here's an example:

$ chmod +a "mikey allow delete" file.txt

Wait a second. I forgot something.

Can you spot what it is?

. . . Where's the group name? ACLs set permissions for both users and groups. Here's the problem, though: chmod doesn't have a way to distinguish between user names and group names when editing ACLs. I can't seem to find information on which takes precedence, user or group, but honestly, I still see this as an oversight that requires correction.

$ chmod +a "pants deny read" file.txt
$ chmod +a "socks allow write" file.txt

Which one is a user, and which one is a group?

Now, realistically, it shouldn't crop up as much of an issue. I can't think of a scenario where I would be named "mikey" and not belong to the "mikey" group, but I've seen stranger setups in corporate offices before. I'm a "future sight" kind of person, and since, as they say, you don't know what you don't know, there's no telling what kinds of problems this sort of ambiguity could present.

Here's hoping Apple takes note of the issue.

link to: rwxomgwtf

file under: breaking things | comments (1)

position: duh;
18/Apr/2005 | 11:05

So it looks like Safari 1.3 might have bit of a problem positioning elements with "position: absolute;" inside certain inline elements. I discovered this after seeing my footnotes getting seemingly random vertical positioning values assigned to them. Safari 1.2 didn't do that, and Gecko/Mozilla doesn't do it, so it caught me off-guard. Coupled with the randomness, I can't help but call this a bug in Safari 1.3 itself.

Check out the entry on the spammer's sentence and look at footnote #2. Hover over it once and the footnote revealed is positioned over the sentence. Remove the cursor from the footnote area and hover over footnote #3, which renders correctly. Now go back to footnote #2. It's fine now.

Bug? Pretty sure. Here's a vanilla test suite:

Position testing in Safari 1.3

If it's my code, I simply have to concede that it's something I'm not doing properly, but I'm not convinced it is just yet. Any deity-level coders out there with inside, hit me in the comments.

Update: Looks like this is busted, too. Am I just having a bad morning, or are the Safari bugs starting to flow?

Update 2: It just got more baffling. It seems that the second example in the test suite appears identical to the first example . . . when using a serif-based font (like Times New Roman). Using a sans-serif font (Lucida Grande), the second example's revealed element is positioned correctly. Weeeird.

Update THREE: Whiskey tango foxtrot. With the help of Foo from #css, I've discovered that by setting the hidden element's parent span to "display: inline-block;", it appears directly below its parent (the footnote number). This also seems to solve the serif-vs-sans-serif problem I noted earlier.

The question now becomes: Is this a Safari 1.3 bug, since other non-sucky browsers are rendering how I expect things to be rendered, or am I incorrectly interpreting the CSS2 spec? What does Dave Hyatt know that I don't? (Among many, many things, that is.)

I've adjusted my main style sheet to reflect Safari 1.3's difference(s), but I'm leaving the test page up as it was originally constructed, so that people with deeper CSS knowledge might be able to provide insight.

link to: position: duh;

file under: breaking things | comments (1)

<MTIfComplete>
10/Apr/2005 | 05:48

There. Done.

I just finished converting the individual post and category archive pages to the new look. Since I'm still awake, I thought I'd drop a few ideas I'm spinning for upcoming articles, taken straight from my to-do list file:

> write something about using macjournal. explain why you use it instead of the stuff rands and quaint suggested.

> explain who the hell all these codenamed people are.

> go over m-s.net's redesign, why it took so long, what you've learned from it, and how it triggers those two safari bugs.

> demonstrate the new footnotes[1][1] Consider this one done, I suppose. Check out the 100% dynamic, no-trickery transparency! OOOH SHINY.. they're awesome.

> searching for elegance

> tiger review

> that other tiger article

So there you go. There are more, but those stood out when I went to copy and paste. I have ideas for interviews I'd like to do in the future, though I'm not sure I'll ever do anything like that. I don't know if this site is really the kind of format that supports interviews. With the exception of chat snippets I posted to the old site, it's always been just a single voice on the site.

All that having been said about the site being a single voice, I implemented comments in the new version, so I guess anything's possible.

Let me know what you think.

link to: <MTIfComplete>

file under: breaking things | comments (0)

!standards
08/Apr/2005 | 09:46

A while back, I decided that my days of designing for the Interweb were over. One last bad experience with a client, I thought, was all the excuse I really needed to drop making pretty lines and graphics. At the most, I'd do things for myself and myself only.

Something funny happened on the way to the hermit cave. Early this year, I was given the opportunity to move to a different department in the company for which I work [1][1] If a corporation is considered a person, should it be "company for whom I work"? WE MAY NEVER KNOW.. The catch—if you could really call it a "catch"—was that I'd be doing what I swore I'd never do again. If you're wondering what I'm talking about, go back and start this article over.

There were three reasons I stopped writing markup:

1. Writing for multiple browsers is a pain in the ass.

2. Clients are all "idiots" who "never know what they want". This is simply a rule you have to accept; if you can't wrap your head around it, go ask ten people what they'd like to see in a single Web site, of whatever kind you choose. When you come back with more ideas than people, you'll know what I mean. In reality, the clients aren't "idiots", but they definitely don't understand what you're doing, because they—and get this—don't do what you do for a living. This makes communication difficult, sometimes borderline impossible.

3. HTML is ridiculously limited. Tables are horribly rigid for anything other than spreadsheet-style data, as well as being terribly unmanageable. Building a design with tables is like making a rug with a Connect Four set. Cascading Style Sheets were introduced to get rid of design rigidity and open up markup to removing layout code from actual content. In separating as much as you can, you gain design flexibility as well as a more manageable code base. Wow, I only have to specify that image tags have no border once, and they all behave that way? I can automatically have all paragraph tags inside my news posts indented for me?! HOLY SHIT.

So CSS was going to be this BIG REVOLUTION, and for the most part, it's lived up to the hype. But what about things it can't do? The W3C is drafting the CSS3 spec at the moment, and that adds plenty of really nifty things like curved borders, more typesetting options for you typewhores out there, and even a robust speech module. We're all good to continue heading into the future, right?

Right?

With the exeption of security patches, development on Internet Explorer was seemingly halted ages ago. So long ago, in fact, that Mozilla had a chance to hit 1.0, Apple had a chance to develop and mature Safari, and Amazon turned a profit.

Good enough for highway work, though, right? It renders my Yahoo! page, it lets me do my on-line banking, and I can surf all the good pr0n sites all day long in my once-a-month-washed bathrobe. If it ain't broke, don't fix it!

What Microsoft have seemingly forgotten is that while your users determine your user base, if you don't have developers on your side, it doesn't make a lot of difference.

Silencing the protestors

No one ever really sleeps in Redmond. Microsoft is a company of bureaucracy and complacency, surely, but that's like saying your laziest, but meanest, pit bull never keeps an eye on the yard. If a cat comes behind the fence, Mr Pit Bull will do something about it. In Microsoft's case, it was a Mozilla's Firefox.

Internet Explorer 7 was announced a few months ago, with the beta being available sometime this summer, and it's going to have features other browsers have had for many years: tabbed browsing, robust pop-up blocking, full PNG support, and increased security, among other things. While, honestly, I'm skeptical about that last security bit, it would appear the the pit bull in Redmond is going to get its browser act together and come into the year 1999.

But take note of one very relevant thing I didn't mention:

Standards support.

I've been looking through the IE7 buzz that's been floating around the Web, and I've yet to find any sort of solid, significant confirmation of standards support that it's lacked since 1996. It would seem as though, per typical Microsoft behaviour, no one in Redmond is interested in not pissing off every serious designer in the world with broken standards support. Internet Explorer's standards support is second only to its busted security model.

All this having been said, it's not out yet, there hasn't been much (if any, honestly) official word on the matter, and the version that's being released this summer is only a beta. For all anyone knows, IE7 will come out of the gate with all of the Mozilla organization bleeding and crushed in its jaws and show the world what standards support really means.

But I don't care.

It's not that I'm lazy or some open source nutball; I dealt with sucky browsers for years before giving up and caring only about the browsers that care about me. There was a time when all the major browsers were fairly pathetic in one way or another, but around the time Mozilla 1.0 and Firefox were released and Safari began to surface, browser developers got over the "let's implement our own special tags and handle tables and shit our own way" movement of the 1990s. The new attitude gave even more indie browsers like Opera and OmniWeb a fighting chance, not that they always took it. I mean, if the big dogs are shooting for standards, and the standards are published and open, we're playing on a level field.

But Internet Explorer didn't move. It got bug fixes for security holes and patches for crashes. It had and still has been years since a real upgrade to the browser, and at one point Microsoft even stated that IE7 wouldn't exist until Longhorn. If the only reason IE is going to change is because of an organization that moves to improve itself because that's the only place to go (Mozilla, of course), what reason is there to continue IE's progress after you've quashed the competition?

Internet Explorer, at one point, wasn't substandard. Right now, it's the worst of the bunch. With a laughably incomplete CSS1 and CSS2 model alone, it's worthless to me and anyone who takes their skills—as well as the time it has taken to develop them—seriously. No browser is perfect, but if someone has to be the broken-down Pinto in the parking lot, it's Explorer.

And if the past holds up, it always will be. If anything ever changes, it'll be that another browser will outclass it [Explorer] in every corner but marketshare, and Microsoft will update it a little bit to compensate before going back to doing nothing with it.

The standards will move on, and designers will slowly get fed up with being held back by Explorer's lack of support.

A real-world anecdote

If you're not reading this in Explorer in Windows, there's something you don't see. Cracking the source, we find:


<div id="ie_greeting">

<p><a href="../exploder.html" title="Sad panda . . .">Why does this page look so terrible?</a></p>

</div>

Feel free to read the page that's being linked to, but in summary: This site does not render properly in any version of Internet Explorer for Windows, and there's no reason it shouldn't. In fact, the reason Explorer users see that message and no one else does is because Explorer will ignore a rule flagged as !important when there's another instance of the rule after it. Example:


.class { display: none !important; display: block; }

In this demo case, IE renders the element as a block element, and everything else renders nothing at all. IE gets it entirely wrong, the warning message appears for IE users, and I have effectively used a bug to display a message to a subset of users. Because this bug has existed for so long, I don't expect version 7 to fix it or any of the other issues that have been part of the IE "feature set" for so long.

So what if it does, then? What if the earlier scenario occurs, and IE7 is released to be a shining example of compliance? Well, we won't have to worry about our code breaking, and no extra work will be required on my part. I still win. That's the point of standards. But how long until the W3C ratifies the CSS3 spec and IE is again left in the dust when everyone else updates their product?

My site is standards-compliant from top to bottom: DOM structure according to DTD, XHTML, CSS. I went out of my way to write very good, very clean code, and IE tosses it out of the window entirely. This is the problem that frustrates so many designers. Hard work means nothing when 95% of the Web population is using a product that ignores it all. We have to resort to hacks, workarounds, and what's worst of all, limiting our own designs in the face of the unwitting masses who use IE.

Making the best product may not be at the heart of capitalism, but if developers are at the heart of Microsoft, continuing to push them toward hating you isn't how you win them over.

For now, I'll be ignoring Internet Explorer[2][2] Disclaimer: For the purposes of remaining employed should anyone above me read this, I only disregard Explorer for my personal site; I do consider IE in my daily work.
, and I'm forced to encourage everyone else to do the same.

link to: !standards

file under: analysis, breaking things | comments (0)

rfc #0001
28/Mar/2005 | 10:22

Okay, comments have now been enabled for certain posts. Gesture over the footer of a post to leave your own notes.

Let's see how long I can last before requiring authentication. GIVE ME YOUR BEST SHOT, RUSSIA.

Archive and individual post templates are still being tweaked, so you're stuck with the default look on those pages for now.

link to: rfc #0001

file under: breaking things | comments (5)

scratch
24/Mar/2005 | 11:02

We've got a lot of catching up to do.

First post of a new era. Like the new look? Yes, I know /worlds is empty.

We'll be back after these messages.

link to: scratch

file under: breaking things