Journal of Omnifarious

17:18 - Business plan

I have a business idea that I strongly suspect is viable. I'm looking for someone who knows how to write business plans who's willing to help me write one up.

It is both product and service based. I suspect the time from getting the money to buy some hardware and tinker to having a viable product is about 2-3 months. I can see several different avenues the business could grow from the first product.

Current Mood: contemplative

13:54 - Another geeky pick-up line

I think of these periodically. I should collect them together someplace... :-)

This one is: "Oh, baby, you make me wanna collapse your state vector.".

It's quite possible that someone has thought of this before.

Current Mood: creative

02:54 - Different neurochemistry

I was talking to someone about an upcoming flight that was going to be a very long flight. She was telling me that she had tranquilizers and was quite anxious about the whole thing, partly because it was going to be for so long.

I was quietly stunned. It was like being in an alternate reality. I can sort of see how being in that situation would cause so much anxiety for someone that they would want tranquilizers to deal with it. But in reality it's a totally foreign mental concept for me. It would never even occur to me in thinking about the flight that I would get anxious from the inactivity. I went on a trip to Australia once, and it was a 23 hour flight. I was totally unconcerned with this fact, and it wasn't a problem for me.

OTOH, thinking about going through the security checkpoints makes me feel nearly physically ill. I have a negative amount of trust for the authority involved in that kind of thing, and I have a really hard time placing myself in a position where it can be so easily exercised over me.

And that's really interesting to me. It's yet another data point on why some people who are using illegal drugs of various kinds are self-medicating for mental states they don't know how to do anything about that are not appropriate or comfortable for the situations they're in. Not that my friend was using illegal tranquilizers, it's just that her situation reminded me of that.

People are the same, except when they're different. And some of the differences are really fascinating.

Current Mood: contemplative

09:20 - LJ got rid of basic accounts with no ads

I've thought about the demise of LJ for awhile. It's quite clear now from how the news wasn't mentioned in a news post, how it's being spun as 'making it easier for users to sign up' and various other things that LJ really doesn't care about it's users at all anymore. This was really quite predictable from the moment they started accepting advertising at all.

Brad Fitz, the person who started it all has a nice post in which he makes the most excellent observation that it's the users that create the whole reason people want to visit the site in the first place. This observation and a discussion of LJs legal status made me realize something.

The modern corporate structure is a wholly inadequate means of expressing the values and desires of the stakeholders in an organization where most of the value of that organization is created by what a corporation would think of as "its customers". Basically this legal framework has been shoehorned into serving a purpose it is wholly unsuited for because a corporation has only a very weak incentive to take the interests of all the people who create the stuff that enables its existence into account. Those users have made a huge investment into the site and that investment is almost completely ignored by the modern corporate structure and repeatedly leads to disaster when the corporation makes decisions at odds with its most important investors, the users of the site that it is a caretaker of.

User content sites need something other than a corporation, something where the organization is legally obligated to take the interests of those users into consideration as the most important factor in decisions made by the organization. I'm going to have to think for awhile to see if I can think of a structure that would work. It's tempting to think of some sort of trust or something quasi-governmental. I prefer structures that naturally and with very little oversight or intervention align the interests of all the participants.

Current Mood: contemplative

20:30 - Thoughts on Thrift and D-BUS

I've been thinking about Thrift and D-BUS ever since I made this post: Java and XML, bad tastes that are worse together. And then I followed up with a reference to my paper: why CORBA and other forms of RPC are a bad idea.

Those, of course, sparked a lot of discussion. Questioning Java and XML, the darlings of 'Enterprise' computing, would hardly pass without comment. It provoked even more of a strong reaction than I'd expect I'd get from questioning AGILE methodologies.

One person though ask me a really good question. Why did I think D-BUS and Thrift were better?

I had to think carefully about my enthusiasm for these two things, and I've reached some conclusions...

First, I like D-BUS a lot better. The problem domain involves communications between processes on a single computer. Context switch overhead is a big deal here, but latency isn't. Also, many encoding issues are greatly simplified in this sort of environment, though D-BUS handles those well regardless.

There are several things I like about D-BUS. There is a consistent naming scheme for referring to D-BUS objects and interfaces. Interfaces are generally expected to support an interface for describing the interface. So they're self-describing. There is a heavy emphasis on notifications and events. So much so that frequently the return you get from a function call is not the real return and you're supposed to expect a notification later that whatever you asked for has finished. Very asynchronous. And the format of messages is a self-describing binary format designed to support a reasonable set of datatypes and user-defined compositions (aka structs). There is a reasonably heavy emphasis on data. Notifications are all about getting the right data to the right thing so it can do whatever it needs to do with it. Very few imperative 'you must do X in such and such a way or I will be very upset' sort of messages are passed.

D-BUS is RPCish, but many of the things I really dislike about RPC are either non-issues in D-BUS' environment, things D-BUS handles better than most RPC systems or both.

Thrift is not nearly so well designed. The main positive thing it has is a nice language agnostic method of describing a data structure in a way that allows for clever upgrades of that data structure later without breaking old servers or clients.

Thrift is not inherently self-describing. There isn't even a standard for asking an object implementing Thrift to send you its IDML, whereas D-BUS actively encourages objects to implement a standard interface for this.

Thrift has the concept of async methods that return as soon as they've made it to the transport. But the methods are still very function-call like, and they encourage thinking of imperative 'do this, change your state in this way' sort of messages. I asked on the Thrift channel about an 'idempotent' method modifier for a method that could be implemented via HTTP GET and people were puzzled as to why I'd even want such a thing. The idea of using RPC to implement REST were met with general puzzlement.

Lastly there is no standard way of naming objects in Thrift. And the HTTP transport that comes by default just assumes it will be sending data via POST requests to http://something:port/, not much of a standard for naming the thing you're talking to at all.

So, Thrift as it stands is very poor for implementing random publicly accessible services.

But providing a language independent way to describe data structures is pretty darned nifty. The closest things I know of that are widely deployed on the wild Internet are JSON, ASN.1 and XDR. JSON is ugly and designed for Javascript Ajax clients. ASN.1 is just plain horribly ugly, overdesigned and a bear to parse. Given that ASN.1 comes out of OSI-land and they gave us such glorious gems as X.500, this is really no surprise. (Strangely, it's used for SNMP. What does that tell you about the S in SNMP?) XDR is not very self-describing in the data stream (from what I remember) has a bad name in other ways because it was associated with an awful RPC implementation from Sun, and is missing a map type.

I've been thinking that having web pages for interacting with data that will return a Thrift encoding of the data if passed an application/x-thrift Accept header might be interesting. They could even accept application/x-thrift data in HTTP POST or PUT requests. This would allow you to use URLs to name objects and a fairly efficient, easily parsed protocol encoding for sending the data needed to manipulate them.

Current Mood: contemplative

10:19 - Slastdot post I'm proud of

It is best understood in context. This is a response to an article about Richard Feynman, the Challenger, and engineering. And it is specifically in response to a post in which someone blames capitalism for the problem's Richard Feynman outlines in Feynman's Appendix to the Rogers Commission Report on the Space Shuttle Challenger Accident.

Blaming the shuttle disaster on capitalism is erroneous. I do not necessarily disagree with your assessment in general, but capitalism was not at fault in that particular instance. What was at fault was bureaucrats trying to look good to their superiors and present a positive public image at the cost of real engineering.

I would say that in general is the meta-problem, not capitalism. In its current form in the US capitalism has caused the existence of many large entities that use hierarchical systems of command and control. These hierarchical systems frequently make sub-optimal decisions because individual actors within the system act for their own benefit but against the benefit of the larger system they are a part of. Particularly egregious examples of this can be found, and they tend to be highlighted as aberrations, but they aren't. They are merely extrema of a problem that is widespread.

Bureaucracy in general serves to insulate actors from responsibility for the results of their actions. As I recall we didn't see any of the middle management of NASA held accountable for the disaster they caused by attempting to look good for their superiors and the public. And this failure of accountability is endemic to the kinds of hierarchical systems you see in most bureaucracies.

Current Mood: pleased

16:54 - Thoughts on tasers

I think that the police or security officers should on no account be allowed to use tasers, but the general public should be allowed to. I've come to this conclusion after a fair amount of thought, and it is a somewhat surprising one.

The reason is that use of a taser has way too few physical consequences. It's very hard to hold the police appropriately accountable for using them. It's hard enough to hold them accountable for shooting people or beating them up. But at least there you have physical evidence. With tasers the subject looks fine afterwards. Sure they may have just been tortured, but they don't have any scars or bruises to show for it.

In multiple videos I've seen over the past year I've seen instances of the police or security officer using a taser not because of any real immediate threat of any kind to anybody's safety, but because the person they tased wasn't doing what the security officer wanted them to do. It was used as a tool to silence and punish, a tool of torture, not a tool to make people safe or defuse a dangerous situation. In fact, in a couple of those situations the security officers came close to causing a riot. IMHO, they deserved to have the whole room of people surround them, put them in cuffs and call someone cart them off to jail. I hope the next time an incident like that happens in a crowd situation that someone has the presence of mind and ability to quickly get a group to do what they want to make that happen.

OTOH, ordinary citizens are not insulated from the consequences of indiscriminate taser use. And they don't have the position of authority to use to avoid being held accountable. For them, a taser is just fine. There are situations in which it's extremely useful for defusing a situation without costing someone their life or causing permanent injury.

Current Mood: contemplative

14:18 - Question...

People have been recommending "Soon, I will be Invincible!" to me. And this has brought to mind an important question. Why is it that only comic book villains are interested in being invincible? Why don't heroes ever seem interested in that? I mean, if you're a hero it seems to me that it would just be generally all around good for everybody (not just your) to be invincible and not rely on the machinations of plot writers and such to make it sort of happen via the invisible hand of the narrative.

If you have an idea, please consider posting it as a reply before reading the comments. I'm sort of interested in as much variety as possible as well as sort of an informal poll. :-)

Current Mood: curious

11:02 - Random epiphany

I was discussing the fact that the default Junit report is singularly unhelpful in that it basically provides you with this really nice interface in which you can drill down to a particular unit test result. But this, of course, is not what you care about. What you really want is a list of the unit tests that failed with links to a detailed log of the failure.

She observed that the practice of making very pretty and complete but functionally useless software and reports was something she expected from the business side of engineering, not the engineering people themselves. I asked her what drove Java development and she conceded that was, Java is all about 'solving business problems', not engineering problems.

This led me to think about an idea I've had for awhile. I've long felt that chasing money was a fools errand in business. What you ought to do is chase down problems that need solving and figure out how to make money from them. The value you're creating should come first, and translating that value to money should come second. Money is the incidental reward for doing something that helps people, not the object.

In this context then I evaluate Java. Java initially received a lot of attention by geeks because many things about it were kind of new and interesting. It was a really innovative way to deliver client-side stuff. Platform independent with a built in security model that could be enforced relatively easily by the runtime environment. I saw a lot of interesting and innovative applets written.

But that was all trashed by three factors. First Netscape had a horrible implementation that didn't get any better. Secondly Microsoft tried to sabotage things and lastly Sun didn't go open fast enough to short-circuit Microsoft's attempts at sabotage. The client side was left in disarray and little attention was paid to it.

OTOH, a whole bunch of businessy types saw Java as the solution to a number of problems they were observing. It was hard to hire good programmers and the available languages made it very easy for bad programmers to make horrible mistakes that completely ruined applications. It seemed like Java made things safe enough that you could let bad programmers write code and at worst it would work poorly instead of completely trashing your system. This seemed like a business godsend and Java gained a lot of traction on the server side of things as a way to let armies of no-talent developers write decent server side software.

The developers with talent mostly felt that Java was a poor re-implementation of Smalltalk and only grudgingly went along with the whole thing.

Fast forward to now, and you're left with a technology who's development has been driven largely by business concerns and only a smattering of geeky enthusiasm. The interesting things that people do with it seem like solutions to problems created by other 'solutions' instead of like any real solution to a problem the universe outside of Java has.

The only really interesting stuff in Java anymore is mobile code. But using it involves dealing with dependency issues that have solutions designed to allow some stupid business to use some incredibly old version of something forever instead of taking the time to do even the minimal maintenance necessary to keep current.

It's all very depressing. Java seemed so promising in the 90s.

But I think, as a general recipe, solutions designed to solve 'business problems' are doomed to failure, or at least doomed to being stupid and badly designed. Don't solve 'business problems'. Solve your own problems, or your friend's problems or something you're excited and interested in. The market for it can take care of itself later.

Current Mood: contemplative

15:56 - Filk

Surely someone among you can expand on this verse of filk:

Hypoxia! Hypoxia!
This meeting will not end,
and makes my day so very dull
from hours eight until five.

Current Mood: amused

16:50 - The weird and difficult intersection of marketing and design

Simplicity is highly overrated according to the author of one of my favorite books on user interface design " The Design of Everyday Things".

Basically, the gist of the article is that apparent complexity is how people judge how powerful a device is. If you want people to believe that you have a spectacular newfangled appliance that does all kinds of neat, useful stuff it had better have tons of knobs and displays to prove it.

Of course, when people get the thing home they are then baffled by it all and complain bitterly about how hard the thing is to use. So one strategy would be to make the apparent complexity an illusion so that people will perceive your product in a positive light while still finding it reasonably simple to use once they get it home.

That's a really hard set of factors to balance though, and it makes me wonder about how the disconnect between appearance and reality will be handled. Will people see through a product that falsely advertises complexity while actually being a poor, low-quality product that doesn't really do anything fancy?

Current Mood: confused

09:51 - No 5th amendment protection for corporations

Not that I think there should be. But it just occurred to me that there isn't. Corporations are required to keep detailed records and produce them on demand. There are consequences if they aren't produced or if they're destroyed.

It's interesting that 1st amendment rights for corporations appear to be upheld by the courts, but not 5th.

Current Mood: contemplative

01:19 - Random thought

Hierarchy is humanity's worst disease.

Octavia Butler has said this in a more wordy way in her Xenogenesis series.

Current Mood: stressed

00:23 - Accelerando

I've been reading Accelerando, though I bought my copy from Amazon instead of reading the online version. :-) Partly this is because this book is an important part of corporate culture at the small startup I'm now working at.

It is a very strange book. I've read bits and pieces of it before as short stories. It's very disconnected and random in some ways, but the whole book definitely does hold together as a recognizable whole. Sort of like The Martian Chronicles by Ray Bradbury.

The thing that really drives you to read the book is the number of new ideas per page. This book is about the densest ride through current thoughts about the idea of The Singularity that I've ever encountered. Additionally there are many clever plot points that work because of some idea based on information technology that doesn't yet exist but is a completely believable extrapolation.

My favorite plot point is when Manfred Macx helps his post-human daughter escape the clutches of her controlling and traditionalist mother by helping her sell herself into slavery to a corporation held in a trust fund that has her as the beneficiary. A feat made possible by the ability to rapidly search and analyze the laws of many jurisdictions looking for ones that have both slavery and corporations.

One interesting feature of this novel is how the various characters (many of whom are sophisticated sentient idea constructs of various sorts) use the laws and the legal system as weapons in favor of swords and shields.

I haven't finished it yet, but I can see where it's going. It's going to be an interesting read.

Current Mood: contemplative

09:05 - DJB on writing secure code

Dan J. Bernstein of qmail fame, as well as being the author of djbdns has written a very interesting paper on writing secure code.

Nobody has found any security holes in qmail since it was created. It's a widely used piece of software, and DJB himself has offered prizes. I do not know if djbdns sports a similarly stellar record, but I suspect it does. So anything DJB has to say on the subject of writing secure code is well worth reading.

I read it, and it confirmed my feelings on the subject already. The best way to write secure software is to write bug-free software. And the second best way to write secure software is to reduce the amount of software that must be trusted. He outlines a number of techniques, illustrated with examples from qmail, on how to do this. It is an excellent paper, and one of the best treatments of the subject I've ever seen.

Unfortunately, DJB is an incredibly arrogant person. He comes by his arrogance by being spectacularly good at what he does, but it doesn't make it any more pleasant.

One of the more visible manifestation if his arrogance is that qmail is not Free Software. In particular nobody is allowed to distributed modified versions. The reason he gives for this is that he doesn't think anybody else can write code that's as good and they will eventually ruin it and make it insecure and then his name will somehow be associated with it. He has this opinion of all the software he writes.

He may be right, to an extent. I think there are other people capable of writing software as secure as his is. But I do not know that they would be the only contributors to the qmail project if it were Free Software.

But recently I've heard hints that DJB may be putting qmail in the public domain. This and the fact he wrote this paper are indications that he either thinks that other people are capable of writing good software, or that he realizes he can't write all the software in the world himself, or perhaps some combination of the two.

I just hope that anybody who modifies qmail maintains the same incredibly (though they shouldn't be, all software should be written to such standards) high standards of quality that DJB did.

Current Mood: contemplative

15:40 - More on threads...

In the post entitled Threads, a neccessary evil or just a bad idea in search of a problem? I go off on a few related tangents and don't really tie it all together well. So I'm going to summarize in this post now that I've had a chance to think about it longer.

My basic idea is that most concurrency issues have the implicit assumption of locality. Basically it's less expensive to access data that's close to you. This means that in many environments having multiple threads of execution communication is resolved by explicit message passing because 'directly' modifying the data would be way too slow and it would all be implemented underneath with message passing anyway.

I do not think there is a magic threshold below which it becomes a good idea to abandon this strategy in favor of a model in which multiple entities work on a shared piece of data and keep this data from ending up in a jumbled and confused state by explicitly locking each other out of the portions they're working on.

I think that message passing is the appropriate model to use for all situations in which you have multiple threads of execution.

procyon112 was kind enough to point me at pi calculus, which is a formal mathematical model that extends lambda calculus with message passing to create a form of lambda calculus that embraces concurrency. On further research, it looks like most Process calculi are based on message passing, which makes sense. It's very hard to mathematically model a system in any other way.

Current Mood: contemplative

18:04 - Threads, a neccessary evil or just a bad idea in search of a problem?

• Python 3K or Python 2.9? - Bruce Eckel
• A Response to Bruce Eckel - Guido van Rossum
• Reply to Guido's Reply - Bruce Eckel

and this unrelated post by krow:

• Thoughts while traveling, feeding the rat....

and a bunch of ideas that have been banging around in my head for awhile.

I have always been very leery of multithreaded programming. I understand the concepts well enough. And sometimes that's really and truly the only thing you can do. This is particularly true at the OS level where you really only have one ethernet card and you need to mediate access between several different things running at the same time that all share the same underlying OS.

But it seems to me that having several threads of execution share memory in user-space processes is a mixed bag, and possibly not really worth it. I have several different reasons for thinking this. And a few of those reasons arise directly out of experience with modern multiprocessor system design.

Current Mood: contemplative

23:15 - New approach to CVS changesets

I am quite pleased with a new approach I've started working on for converting a CVS repository to a set of changesets. I believe it is somewhat novel, and I think it will yield better results than most others. I'm calling my project cvs2cg (CVS to Change Graph) and this is a link to the repository for cvs2cg.

Current Mood: accomplished

14:34 - Linux scheduling

I was reading this article on Slashdot about Linux scheduling and I had some interesting thoughts after reading the LKML thread in which people complain about the new scheduler's impact on games.

It was clear to me after reading that thread that the kernel developers were inappropriately obsessed with throughput measures like game framerates and such. The real measure you want is latency. And even latency isn't enough, you want to know both the average latency between user input and the user interface (or game) reacting, and you want to know the standard deviation of the latency between input and reaction. I posted these two bits of text about this:

First, this one complaining about throughput:

FPS is a poor measure of the feel of a game. I know it's what all the graphics card benchmarks use, and it does do a good job of measuring the total processor and video card throughput, but that's not the most important thing.

The most important thing is the time between you pressing a key and the changed game state being reflected on your screen and how consistent that delay is.

One of the arguments that CK has made about kernel development is that kernel developers have become obsessed with throughput to the exclusion of all else and that this leads to very poor desktop performance because throughput is a poor measure of 'interactivity'. Someone posting 3D game framerates as evidence of one scheduler being better than another is exhibiting exactly this bias.

IMHO latency is a better measure, but still not perfect and it can be hard to measure in some cases.

I don't know enough about the scheduler to know which one is better or which one exhibits particular properties. But I can see that the throughput bias is evidenced in force in the thread the article points to.

And CK is also right that big iron shops care more about overall throughput than any measure of 'interactivity'. IMHO there ought to be some kind of pluggable scheduler system that allows you to completely change the algorithm to reflect the preferred behavior of the computer you're using.

And then this post in which I outline why even average latency is inadequate:

It's also good if the delay is of a consistent length. You can adapt to a fixed delay if it's small, but it's really hard to adapt to a delay that's jumping all over the place even if on average it's pretty small. Additionally an inconsistent delay length leads to things looking choppy even when the delays are all fairly small.

If you moved a window across a screen and at a particular speed and its position was updated at a fairly consistent once every 2 pixels it would still look pretty darn smooth, but if it sometimes updated every pixel and sometimes every 3 or 4 it would look pretty choppy even if on average it only moved 2 pixels per update.

Having the delay be inconsistent also messes with the feedback between what you see on the screen and how fast you move your mouse.

In short measures like throughput or even just average latency are pretty poor. What you want is a measure of real feedback latency and look at both the average, standard distribution and outliers in various load situations. I suspect what you want a very tight cluster around an average latency and as load goes up you want that average to degrade gracefully while the cluster remains relatively tight.

Current Mood: contemplative

21:55 - Some interesting test results

I found this in naohai's journal in this post and it seemed interesting. These tests can be found at a website about Simon Baron-Cohen's book The Essential Difference: Men, Women and the Extreme Male Brain.

I suspect I would find the book irritating as it posits some hard differences between how males and females think. And while I think there might be some, I suspect the line is a lot blurrier than the book would make it sound.

Here are my test results.

Mind in the Eyes
Your score: 24
A typical score is in the range 22-30. If you scored over 30, you are very accurate at decoding a person's facial expressions around their eyes. A score under 22 indicates you find this quite difficult.

Systemizing quotient
Your score: 37
0 - 19 = low
20 - 39 = average (most women score about 24 and most men score about 30)
40 - 50 = above average (most people with Asperger Syndrome or high-functioning autism score in this range)
51 - 80 is very high (three times as many people with Asperger Syndrome score in this range, compared to typical men, and almost no women score in this range)
80 is maximum

Empathy quotient
Your score: 21
0 - 32 = low (most people with Asperger Syndrome or high-functioning autism score about 20)
33 - 52 = average (most women score about 47 and most men score about 42)
53 - 63 is above average
64 - 80 is very high
80 is maximum

Autism Spectrum quotient
Your score: 30
0 - 10 = low
11 - 22 = average (most women score about 15 and most men score about 17)
23 - 31 = above average
32 - 50 is very high (most people with Asperger Syndrome or high-functioning autism score about 35)
50 is maximum

Current Mood: curious