Today I spent a considerable amount of time trying to install git on my Terastation.

First I discover that all the git-core ppc debian and rpm packages are compiled against a different version of libc. So I get the source for git, and attempt to compile it myself. I find that the Terastation doesn’t have a compiler. So, I go online and find that there’s a ppc development environment for the Linkstation. Once I unpack that, and setup my PATH, I try to compile git again, but run into problem with libraries and missing core-utils programs. Eventually I get that sorted out, and find problems with Perl. Finally, I was able to grab some perl packages that correspond to the version already on my Terastation, and unpack those, and compile git. Lastly I wrote up, and installed a script to run git-daemon. I’ve yet to set up a project that needs hosting, because I ran out of time yak shaving. The plan is to host my home directory, so I can manage stuff across several computers.

In the future I might one day setup a cross-compile environment, or (better yet) install a package manager on the thing. Either solution would make maintenance much, much easier.

Like many other things in life, a comedy show had things absolutely spot on. In this case Futurama has in it a fictitious product called Bachelor Chow, which functions as a pet food, but for humans; specifically middle-aged men that don’t cook. I’m a college grad student, and I don’t cook. What I want is a meal, that’s both cheap and something that I can survive on. If we can scientifically formulate food for our pets, why don’t we do it for ourselves? The fact is that our society doesn’t make healthy living very easy; this is especially so for those without the inclination to cook.

Of course, since this idea is not new I’ve gathered some links to others that have actually made some meager (and not so meager) attempts:

• evsh.net speculates that we should make such a food reality. In his first post he makes good points about nutritional balance, and sets some ground rules:
  

  1. Nutritional needs shift as you age.
  2. Meals should cost no more than an average restaurant lunch.
  3. Preparation time should not exceed 15 mins

  In his second post he actually lays out an eating schedule that is nearly perfect in all major vitamin and mineral categories. Due to his engineering approach, he actually achieves his goals on cost, and doesn’t do too badly on flavor or variety (fruits and vegetables can always be swapped and rotated around).

• Scott Adams (of Dilbert fame) had once tried and marketed the DILBERITO, which had very high nutritional value. It was created because Adams himself figured that someone could make a ton of money if they created a healthy, easy to prepare meal. Unfortunately, it didn’t stay.
• The Strategic retreat comments on basic nutrition in America and the dietary habits of our indigent welfare, concluding that
  

  all U.S. citizens should have the option of eating cheap but nutritious Bachelor Chow. If you’re a U.S. citizen you should be entitled to a daily gallon of water, a bowl of bachelor chow, a tube to sleep in and library access. If you want a hostess cup cake, that’s fine; but it’s not food so you’ll have to work for it.

• Of course I must mention that our own armed forces have faced this problem before, and came up with the popular (among campers anyway) MRE. (I think they’re delicious).

I’d like to add some suggestions of my own:

1. One of the biggest difficulties with making Bachelor Chow a real product is variety. Humans really like to have variety in their diet. I think that this is a fairly easy to solve problem: make a series of main courses and side dishes, letting the customer mix and match according to their preference. This also helps to solve the problem of changing nutrition needs with age and gender. (IKEA does this with some of their furniture lines, it works well)
2. Keep amount of packaging to a minimum. Favor production of bulk amounts in resealable containers over individually wrapped packages. The amount of packaging involved in an MRE is appalling.
3. Make vegetarian and vegan options. MRE and the Dilberito were really good about this.
4. Cut way down on salt and sugar. When making processed foods, it’s really easy to slip these in for flavor. I’d have thought that canned soups would make a good bachelor chow, but they have far too much salt. Besides, ordinary Americans will get enough of these elsewhere without even trying.
5. Marketing is gonna be a really big challenge. I don’t think piggy backing on something else’s fame will work. It’ll probably work best if targeted as a healthy living, weight loss, design your own meal program sold through ordinary supermarkets (next to the microwave meals and/or breakfast cereals).

I should also note that the movie Supersize Me was worth watching for the commentary on our school cafeteria menus, and the fact that Micky D’s ruined his sex life.

My moleskine has been holding on to a rather provocative idea for quite some time. On 7^th Aug. of 2006 I wrote about a television system with no moving parts. The idea is that you use an LED laser together with a couple of prisms made out of a material that changes refractive index based on an applied voltage. One prism does the horizontal scan, the other does the vertical scan. This may not work for room-sized projectors because the power output of an LED laser would be too small, but it would work well for near-field projectors; including glasses. The primary advantage of no moving parts isn’t that they can be manufactured cheaply, but that it can be made small enough to mount one on each lens of your glasses.

Though I’ve been sitting on this idea for quite some time, it was only last night that I asked myself an interesting question: What would you do with a different picture being fed to each eye? It then dawned on me: Holography, of course. Virtual objects could be painted into the real world!

I’m used to C’s version of unions and structs. In C a union is simply a spot of memory into which various types of things can be stored. C doesn’t do all that much checking on the data types though. For example, if you construct a union of an 4-byte int and a 4-byte double. C will allow you to assign to the int and then later read from the double. Because these values share the same memory space, you will very likely get back garbage (the bytes of the int will be interpreted as if they were actually a double). C essentially allows you to subvert the type system in this fashion, leaving it up to the (unreliable) programmer to keep track of the type which is stored in that location, so that those bits are not ever used as if they represented a different type. C++ inherits this feature, making it especially dangerous, because the programmer might accidentally pull out the wrong class, and thus use those bits for a nonsensical dynamic method resolution.

What would be really nice is to have a union type, which the compiler is able to check for you. According to section 7.3 Records (Structures) and Variants (Unions) of Programming Language Pragmatics, Ada requires the use of a discriminant in its variants. Essentially, this means that the compiler is able to keep track of what type of value that part of memory represents. It also disallows converting of types. Once a value of type A is stored in that location, it will always be treated as type A, and never as a type B. This tag uses up extra memory, but does help provide type safety.

Also, in C, there is the array. Essentially a packed section of memory that contains many of the same type of object. It’s homogeneous. Only one type can be stored in it. Since I started using some of the more dynamic scripting languages, I’ve always found homogeneous data structures to be quite constraining. It’s just so inflexible to store a list of only one kind of thing. Many times I like to store a list (preserves order) of different kinds of things. I like heterogeneous lists. But how to implement them?

In C we can easily create a union of all the different types we might want to put in the list, and then just put them in like that. But wait! When we pull them out, we’ve now forgotten what type we used when we put them in. So we could create a struct with a tag (to tell us the type) and a union to store the data. Then every time we pull a value out of the array, we first look and the tag, and then use the appropriate data type. The compiler will be in the dark about most of this, and won’t catch certain mistakes (namely, pulling a value out as the wrong type, or omitting a type^*)

In my dream language, I definitely want the compiler to type check my unions, such that I don’t accidentally try to pull out data with a different type than was used when I put it in. In this way I would be able to safely and easily create a heterogeneous list by simply creating a homogeneous list of unions. There will probably be a large run-time type-checking or tag-verifying code that would be unavoidable, but I’d like to make the analysis as static as possible for performance and safety reasons. I’m hoping that a typing system with powerful enough type-inference could help me out with that a bit.

---

^* Actually, if the tag is an enum then C++ will verify that any switch-case exhaustively checks the enum. So omitting a type should raise a compiler warning.

Cloud computing, remote virtual machines, web mash-ups, and anything that executes on someone else’s machine with data you (or your customers) provide is really insecure. Sure you can encrypt the traffic, but in the end that remote machine is forced to decrypt that data before it’s operated on. For example, suppose I have two numbers, which I want added together. Now, if you can add, then I can send you the numbers, and you can send me back the sum. But what if I’d really rather not reveal these numbers, and I’m incapable of adding them myself?

It should be theoretically possible for me to encrypt the numbers and send them you, and let you directly perform the addition operation in the encrypted domain, sending me back the encrypted sum. It would be really difficult, however, to find an encryption operation that would allow this for addition, multiplication, and division. Yet, even if we could, it still doesn’t solve problems related to pointer arithmetic or memory addressing. It’s entirely possible that I might have computed, and therefore not want to reveal, a memory offset that the underlying processor would need for indexing an array.

Still directly processing in the encrypted domain might be useful for certain, more limited, applications.

So today, I flew to San Jose and back. I went to the Mozilla office (which is right next to the infamous Googleplex) and met Brendan Eich. This, for me, was an altogether surreal experience. I’ve never traveled that far in a single day, I never been through such nice airports (I’m used to the hell that is LAX), and I was able to meet the creator of JavaScript.

I also had to discuss a little of what I’ve been up to since arriving at UCI, to the rest of my adviser’s group. It looks like I’ll be working on information flow in SpiderMonkey. More on that topic will have to wait until I’ve assembled my thoughts. For now I’m hesitating about which of the two most prominent approaches: (1)Make extensions to the language, like JFlow, or (2) deal with generic security policies at the bytecode level. Alternatively, I could try to generalize data tainting to a full fledged type system, orthogonal to the existing type system. I’d kinda like to see if allowing the programmer to extend the type system in this way would have any benefits for software engineering, or if the added complexity would be too burdensome.