A lot of people have asked me what happened to the Alky project. The short answer is that we made a lot of bad business moves, but that answer glances over a lot of the fun little details. Having gained considerable knowledge from other stories of failed startups, I figure I'll throw one of my own into the ring.

History

The Alky project's history can be split into a few phases:

Conception

Alky began as an experiment to see how easily I could convert Windows PE files to run natively on Mac OS X (x86). I started by writing a converter that ripped the segments out of the original file and throw them into a Mach-O binary, then linking it against 'libalky'.

LibAlky was a reimplementation of the Win32 API. At first, I tested with files that just called a few simple things, like user32:MessageBoxA, and it worked spectacularly. It was at this point that I realized the basic concept was not only sound, it made a whole lot of sense.

Actual project creation

Once the initial prototype worked, it was time to get people interested. I went to Michael Robertson (who was my employer at the time) and gave him a rundown. He offered to buy the domain, host the project, and get some resources behind it, primarily PR-wise. Within a few days, the project started actually feeling real. We got the site up, wrote some copy to explain what we were doing, and then put it out on Slashdot.

Unsurprisingly, we received three types of responses:

1. This is impossible, it simply can't work from a technical point of view. (This was especially hilarious coming from a Transitive engineer, considering that what they did is considerably more complicated.)
2. This is possible, but it won't happen due to the immense amount of work involved. (Half right -- more on this later.)
3. Wine sucks, I hope you guys can do it better. (We couldn't -- more on this later.)

But more importantly than anything else, we got some developers involved. However, they ended up being driven away.

Mismanagement of the open source project

Alky was the first open source project I'd ever managed that consisted of more than myself and a few friends, and as a result it was mismanaged at every possible turn. It was unclear what people should've been working on, no effort was made to document the project, and no real effort was made to include the developers that were so interested in working on the project.

This was compounded by a rewrite and redesign, which I decided (foolishly) to take on entirely by myself. Some of the design was done as a group, but none of it ever left my hard drive, so work stalled on the existing codebase and the project started to wither.

Shortly thereafter, Falling Leaf Systems was incorporated to back the development of Alky. This further increased the rift between the open source developers and the "core" group (consisting of myself and one of the cofounders of the company). Originally, we planned to dual-license the codebase, but as we got more into discussions of the goals of the business, it became clear that closing the source was the right move. However, we couldn't have picked a poorer way to do it.

Rather than be upfront about the move to closing the source, we simply killed the IRC channel and took down the site. The open source developers were left wondering what happened, while we moved on the rewrite.

Prey and the Sapling Program

Alky was completely rewritten with the new design, and work quickly moved forward on getting the first game running. We released a converter for the demo of Prey (Mac OS X only at first), as part of our new Sapling Program. The Sapling Program was created as a way to get some upfront money for the company, so we could get needed hardware, go to the GDC (which was a horrendous waste of money, for the record), etc. We sold memberships for $50, which gained access to the Prey converter and all future converters. Of course, after we finished Prey for Linux, there were no more converters.

Loss of focus

After Prey was done, we'd planned on implementing DirectX 9 with hopes of running Oblivion, but we lost sight of this goal. Instead, we decided to go after DirectX 10. Along with this shift in focus came an even bigger one: we were no longer targeting Mac OS X and Linux primarily, but Windows XP. We saw that Vista was tanking, and DirectX 10 was only available there, so we decided that we only had a limited window to make money off of that.

Shortly after we made the change, we released a library to allow a few of the DX10 SDK demos to run on Windows XP via OpenGL, albeit with serious missing features (e.g. no shaders). It got some attention, but few people were able to actually get it working. After this was out, I started work on reverse-engineering the shader format and writing a recompiler that would allow Direct3D 10 shaders to work with OpenGL, and even more importantly, without DX10-class hardware. Geometry shaders were planned to run on the CPU if the hardware wasn't available to handle it, and work progressed quickly.

Alky for Applications

We discovered a project known as VAIO to allow Vista applications (non-DX10) to run on Windows XP, and after some talks with the developers, they (or more specifically, one of them -- we'll call him Joe) were sucked into Falling Leaf. We rebranded VAIO and it was released as Alky for Applications. After this, Joe was tasked with making Halo 2 and Shadowrun -- Vista-exclusive but non-DX10 games -- run on Windows XP. We were so confident in our ability to do this, we set up an Amazon referral system and made it such that anyone who purchased either game through us would get a copy of the converter for free.

At this point, I was working heavily on DX10 stuff, and was under tight deadlines to show things off to a company that was interested in our technology, but the clock was ticking. About a week before the planned release of the Halo 2 and Shadowrun compatibility system, Joe came to us and told us that he'd not been able to get anything working, and had very little to show for the time spent. In retrospect, it was my fault for not checking up on him (my job as his manager), but at that point it just made me realize there was no way it was going to be done in time.

I picked it up -- dropping DX10 in the process -- and attempted, feebly, to get it done. Of course, I picked the most difficult way to approach it; reverse-engineering the Windows application compatibility system. By the time I got anything remotely close to working, we'd already missed our deadlines for both the DX10 work and the Halo 2/Shadowrun converter.

The death of Falling Leaf

After all this went down, I fell into a bit of a depression. I became demoralized to the point of just not wanting to go on anymore, in the face of repeated failures, very much in public. Despite us not walking away with a dime -- we made approximately $7000 in total, none of which went to any of the founders of the company -- I felt that we'd ripped people off, despite the best of intentions. It wasn't long after this that Brian (one of my co-founders) stepped down as CEO, and I closed the doors on the company. The source to Alky and Philosopher (the compiler framework used in the shader work) were released at the same time.

Lessons Learned

1. If you're going to run an open source project, make it easy for people to contribute. Not only that, make it worthwhile for them to contribute and make them a part of the project, not just free workers.
2. If you're going to kill an open source project, be up front with the people involved. It's not only dishonest not to do so, you lose people who may well go to bat for you even if you are commercial. This is especially important for a project like Alky, where we faced nearly universal negativity.
3. If you're going to change focus, be clear with your users as to what's going on, and make sure you make it clear that the old stuff is dead and gone. If you don't, you come off looking terrible in the press, and it just makes you look like amateurs (which we were).
4. Make sure your employees are actually doing what they're supposed to be doing, especially if they're working remotely. This was really the final nail in the coffin for Falling Leaf.

Alky Reborn

Now, with all of that said, there's a light at the end of the tunnel perhaps. The source for Alky has been pulled into Github and it seems that development is picking up again. Perhaps I can shed some light into what design decisions were made, how it was implemented, and how I'd do it now if I were so inclined. I don't plan on working on Alky again (that time has passed), but I'd still love to see it succeed.

The old Alky design

Alky's original prototype had a very simple design, library-wise. There was one big LibAlky which contained all of the Win32 API implementations, each talking directly to native APIs. This design very quickly became unworkable, as we had tons of duplicated, unmaintainable code.

The new Alky design

Alky was redesigned such that we had the Nucleus and the Win32 APIs. The Nucleus was intended to abstract away the platform-specific details and expose a universal API that the Win32 APIs could sit on cleanly. While a good idea, it quickly broke down in implementation. I ended up writing code that straddled the Nucleus and the Linux/OS X APIs, rather than abstracting everything away. This led to slower development and an even more complicated code base.

Potential new design

Having done two implementations of Alky and quite a few other projects that relate to it in concept (IronBabel, Renraku (OS design plays a factor here), etc), I think I'm at a place where I can perhaps come up with a workable design.

The key point where both Alky implementations (and Wine, IMHO) failed is in maintainability. The codebase was a rats nest, much like the real Win32 APIs, and neither implementation managed to help this at all. I think this needs to be the absolute top priority, above performance, compatibility, and all else. If your code is maintainable, all the rest can happen.

With that focus in mind, here are the things I'd do with a new design.

• Implement the APIs on top of Mono, taking advantage of the flexible marshalling that P/Invoke gives you. This will allow you to simplify things greatly, and will only have a marginal performance hit in most cases.
• In cases where performance is critical, drop down and implement things in C, C++, or assembly. If this chunk of the project is greater than 10% of the codebase, you've got bigger problems.
• Abstract, abstract, abstract. Break things into the smallest chunks possible and reuse them. This is what we tried to do with the Nucleus idea, but it was easy to just ignore it for complex pieces.
• Write thorough unit tests for every API that's implemented (public and internal). Regression testing would also make things really nice.
• Rather than trying to get real games/applications running immediately, write your own simple applications that test specific chunks. This would've cut down considerably on the development time in the old revisions of Alky.
• Write a great debugger to be able to step through applications cleanly. In the old days, I'd break out IDA Pro and step through a game on Windows, then compare the behavior to the Alkified version, but this was just downright painful.
• Make it work on Windows, to allow easy side-by-side comparisons.

The suggestion that this should be built on top of Mono/.NET sounds ridiculous, I'm sure, but I do think it'd give the project a shot.

In Closing

I hope this has given you some insight into what went down with Falling Leaf, some ideas of what not to do (obviously, it's easy to completely overlook these things when you're down in the trenches, as we did), and where Alky could one day go. I wish the Alky Reborn folks the best of luck, and I hope some of my advice helps.

Happy Hacking,
- Cody Brocious (Daeken)

Posted via web from I, Hacker

<p>This is the current Renraku OS FAQ.  If you have a question that's not answered here, feel free to join us in #renraku on irc.freenode.net.</p>

 

<h2>What is Renraku OS?</h2>

 

<p>Renraku is a pure managed code operating system, written in Boo from the ground up.  The goal is to produce a high-quality operating system without the traditional security, performance, and flexibility issues.</p>

 

<h2>Is Renraku open source?</h2>

 

<p>Yes, Renraku is distributed under the CDDL (Common Development and Distribution License).</p>

 

<h2>Why not use X in place of .NET?</h2>

 

<p>The .NET infrastructure is fairly simple, powerful, (very) easy to compile, and flexible enough for our purposes.  Another tool may be better suited to the task, but we've found it to be a good match.</p>

 

<h2>Why use Boo instead of C#?</h2>

 

<p>Although C# is the more traditional choice for .NET work, it lacks macros and is simply much more verbose.  Boo is very easy to pick up and significantly more powerful.  However, our choice of Boo doesn't mean that the rest of the OS has to be written in Boo.  Services, Capsules, and drivers can all be written in any .NET language.</p>

 

<h2>Is it POSIX compatible?</h2>

 

<p>No, by design.  POSIX was great in 1989, but times have changed and we need to move forward.</p>

 

<h2>What about legacy applications?</h2>

 

<p>Virtualization is the only planned route for legacy code at the moment, as it's the most efficient and lowest cost.  Perhaps we'll support running certain types of legacy applications in a more direct route in the future, but it's doubtful.</p>

 

<h2>Won't this be slow?</h2>

 

<p>For a while, yes.  However, compilers are rapidly getting considerably better and compilers like Microsoft's Bartok are paving the way toward faster code.  In addition, our lack of separate address spaces and privilege levels make system calls and task switches dramatically cheaper than on existing OSes.</p>

 

<h2>No separate address spaces?  What keeps applications apart?</h2>

 

<p>Because we use pure managed code, we're guaranteed that applications cannot touch memory they aren't directly given.  This means that the compiler has the last word on all memory access in the code, reducing the attack surface of the OS considerably.</p>

 

<h2>Does it run X?</h2>

 

<p>Unless the application you have in mind is playing with our shell, looking at our logo, or acquiring an IP address via DHCP, probably not.  Renraku is still in its infancy, but we hope it'll be useful someday.</p>

 

Posted via web from I, Hacker

Developing Renraku has led me to some interesting thoughts, not the least of which is the feasibility of a .NET computer.

Concept

Existing computers know only a few core things:

• Move to/from memory and registers
• Branch
• Perform arithmetic

All the other smarts are built on top of that, leaving us with layer upon layer of complexity. What if we were to add some logic to the hardware and introduce a thin software layer on top of that?

Design

CPU

The CPU will execute raw CIL blobs and exposes hardware interfaces and interrupts. The most likely route is to keep the stack in a large on-die cache, doing a small lookahead in decoding to prevent multiple stack hits in arithmetic.

Since the CPU is going to be executing CIL directly, it's going to have to deal with object initialization, virtual method lookups, array allocation, memory manager, and many other tasks that existing systems handle purely in software. This is achieved by splitting the task between the CPU and a hypervisor.

Hypervisor

The hypervisor, like everything else, will be built completely in managed code. However, it will be a raw blob of CIL, instead of the normal PE container. The hypervisor will handle most of the high-level tasks in general, but it's up to the specific hardware manufacturer to determine what goes in the CPU and what goes in the hypervisor. The hypervisor will come up when the machine is booted, much like a BIOS. After performing hardware initialization, it will look for the bootloader.

The hypervisor provides a standardized interface to talk to drivers and memory, which are verified. In this interface, it will also provide hooks for the memory manager, allowing the OS to handle it in a nice way. Interrupts will also be hooked via this interface. The hypervisor instance will be passed to the bootloader, which then passes it on to the OS.

Bootloader

The bootloader is a standard .NET binary, and its job is simply to hand control off to the OS. Its function is effectively identical to that of a bootloader on an existing system.

OS

The OS will look very similar to existing managed OSes, with a few exceptions. Obviously, there's no need to write your own .NET implementation, and no need to write a compiler.

Because it exclusively talks through the hypervisor interface, it's possible to nest OSes as deep as you want, you simply have to expose your own mock hypervisor. You can handle resource arbitration here and run them very efficiently.

Unlike most OSes, it won't get free reign over the system. To access devices, it'll have to use verified channels with the hypervisor, to ensure that consistency is upheld. This is similar to the way that Singularity functions.

Is it a good idea?

Maybe, maybe not. I don't know how efficient a CIL chip would be or how much of the .NET framework can really be pushed onto a chip, but the core idea is really an extension of Renraku. A pure-managed system would be very powerful if done properly, but it's a pretty drastic change.

A nice middle ground would be utilizing an existing processor and using the hypervisor in place of the existing BIOS/EFI. With some code caching magic, the CIL->X compilation could be done at this level and be completely transparent to the OS. This may well be a better route than a CIL CPU, but it's tough without having more information on the hardware challenges involved with such a thing.

Happy hacking,
- Cody Brocious (Daeken)

Posted via web from I, Hacker

There hasn't been any news on Renraku in a while, so I figured I'd throw up an update on what's going on.

Where we are

Not a whole lot has changed since the last post. We have a clear direction on where we're moving and we're making progress, albeit more slowly than in the first few months.

The biggest new thing is networking. We have Ethernet, IP, UDP, DHCP, and ARP, although the IP and UDP implementations still need some love. We also have a driver for the AMD PCnet card used in VMware, so testing is fairly easy.

Outside of this, most of the work has been in design, where we're solidifying the way the system works.

Where we're going

Hosted mode

Renraku is soon going to be able to run on top of any existing .NET implementation, allowing considerably simpler development and debugging. The primary goal with hosted mode is to allow developers to tackle higher-level tasks (GUI work, filesystems, etc) while our .NET implementation, kernel, and drivers are built.

When you have a hosted Renraku kernel, you'll run the kernel like any other application, then all of Renraku's services will start up just like on the bare metal. At that point, you'll be able to run other applications inside it, with the benefit of the drivers being dealt with by the underlying OS. This should significantly lower the barrier to entry to hacking on Renraku, while making our code considerably better.

To achieve this, we're splitting Renraku into several pieces:

• Compiler
• Kernel
• .NET Base Class Library
• Services
• Applications

When we do this, we need to split platform-specific details away from the rest of the code. Hosted mode will just be another platform to the OS, so this also gives us much-needed platform independence. (This will make it possible to write targets for ARM, x64, etc in the near future -- more on this soon.)

In hosted mode, certain services will run as-is, but others will talk to the host OS. For networking, a driver will be implemented that uses raw sockets, utilizing our stack above it. For storage, we can create a virtual disk in a file. For video and input (and sound, eventually), we'll likely backend to SDL.

Whenever possible, we'll use more Renraku services (e.g. not just implementing the 'tcp' service as a wrapper around the .NET TCP classes), which will keep the code from fragmenting too much.

Utilizing Mono's BCL

In the early days of Renraku, I pushed hard against the idea of using Mono's BCL, preferring that we write our own. While I'd like to go with our own BCL that's tightly tied to the Renraku kernel, cracks are quickly appearing in that idea. With us launching our hosted mode initiative, it's clear that the BCL needs to be separated as much as possible. At this point, it's starting to look like going with a modified Mono BCL may be the best route; at the very least, it's worth investigating.

This is simpler than writing our own BCL of course, but it's no trivial task itself. Integrating it with the Renraku kernel is going to be tough; most likely, the right way to do it is to strip the BCL down to the core components that we use and implement now, then move up from there. The other big challenge is compiler support; we currently don't support exceptions and several other things that the BCL uses heavily.

Regardless of the difficulty, this may well prove to be the right way for us to go. Hopefully it will work out, as it'll accelerate Renraku's development significantly.

Capsules

Capsules are our answer to the application and process concept in most OSes. A Capsule holds running tasks, connected events, and the service context. When a Capsule starts, its main class is initialized, which will set up services, throw up a GUI, or whatever. Unlike a process on most OSes, a Capsule does not have to have a thread (task) running at all times, acting much like TSRs did in the old days. Once initialization is completed, the main task can die off, leaving all its delegates and services up. Because of the design of the system, most Capsules will not have a main task, leading to a more nimble system.

The strength of Capsules is most apparant with a GUI or networking app. In a GUI, the main task will put up the GUI and connect events, then die off. When an event occurs, the GUI service calls the Capsule's delegate, which spawns a task inside the Capsule to deal with it.

A network service will work similarly, dying off after it registers itself, waking up only to accept a new client, then it'll wake up when communication happens. This makes writing network applications very, very simple and efficient.

One outstanding problem is how to handle a Capsule being force killed. We need to handle this in a way that guarantees that the system remains consistent, which is tough. Anyone have a proof debunking the halting problem?

Formal design documents

Currently the Renraku documentation is, to put it nicely, sparse. Code isn't commented at all and there's no documentation on how anything works. I've started writing real design docs, which will go live on this blog over the coming weeks. Here are the primary documents that are being worked on:

• Capsule architecture
• Input chain of command (how input gets from the hardware to the right place)
• Storage architecture
• Networking
• Graphics
• Compiler
• Security

Capsules will definitely be the first to go out, as it's the most important (it blocks the most other elements of the system); the order on the rest is up in the air.

Closing notes

The work I've done on Renraku OS so far has been some of my best and certainly some of the most rewarding. I'd like to thank everyone who's contributed or just cheered on the team. Even if this never takes off (the likelihood is quite small), Renraku will be an OS we can all be proud of, because of you guys.

Happy hacking,
- Cody Brocious (Daeken)

Posted via web from I, Hacker

You know, I'm not a picky customer. When I find a company that does
the job well and without causing problems, I tend to stick with them
for a long time. I also tend to advocate for good companies, because
they're becoming less and less common. Today, a company just lost my
business forever, and I doubt anyone else who sees this will ever deal
with them either.

I ordered some Adrafinil from Nubrain.com yesterday. The ordered
was marked as completed in their site and I wasn't given a tracking
number (didn't think about it at the time, but first class USPS was
used, so there was no way to track it). As I was curious to see how
long it'd take to arrive, I looked up where it was shipping from and
found that they're located in Lawrenceville, GA, where I reside.
Since the site didn't say it had shipped yet, I decided to send them
an email to see if it was possible to pick up the order:

 
Hello, 
 I was looking at your site to figure out where my order 
(redacted) was going to ship from, to get some idea of the 
time it'd take to ship, when I found that you're located in 
Lawrenceville as well. If my order hasn't shipped yet, would it be 
possible to pick it up instead? 
 Thanks, 
- Cody Brocious 

Not a terribly difficult request. If the answer was no, or it had
already shipped, I would've thought nothing of it and moved on.
Instead, I got this:

 
WE ONLY SEND BY US MAIL 
IF YOU WANT PICK UP CALL PAPA JOHNS PIZZA 

Is it really that much of an inconvenience to send back "Sorry, but
our store only delivers"? When you're in a market like shipping
pharmaceuticals, a certain amount of trust is required, not that this
would be appropriate in any market.

If you want to keep your customers, you have to treat them well, not
like you're being inconvenienced by them. If you don't want to do the
job, don't do it; don't act like the customer is doing you a
disservice by giving you money.

- Cody Brocious

Posted via email from I, Hacker

Texas Instruments has decided to C&D the UnitedTI forum for distributing the TI83+ signing key (as reported here).  This makes another beautiful illegal number.  Distribute it far and wide -- no number should be illegal to distribute.

 

Gentlemen,

A mathematical morsel for your entertainment and edification.

The number
6,857,599,914,349,403,977,654,744,967,
172,758,179,904,114,264,612,947,326,
127,169,976,133,296,980,951,450,542,
789,808,884,504,301,075,550,786,464,
802,304,019,795,402,754,670,660,318,
614,966,266,413,770,127

is the product of
5,174,413,344,875,007,990,519,123,187,
618,500,139,954,995,264,909,695,897,
020,209,972,309,881,454,541

and
1,325,290,319,363,741,258,636,842,042,
448,323,483,211,759,628,292,406,959,
481,461,131,759,210,884,908,747.

Posted via web from I, Hacker

Yesterday I read about a comment from RMS at Software Freedom Day in Boston. He referred to Miguel
de Icaza as "basically a traitor to the Free Software community".
Sorry, but this is too much, even for him.

RMS was a driving force early on and is responsible in large part for
the open source movement. Since then, I believe he's done far more to
harm the community than he's done to help it. From silliness like the
famegrab that is the term GNU/Linux, to the attempts to fight
Tivoization of Linux with the GPLv3 (notice that the Linux kernel is
still GPLv2? This isn't an accident.), he's shown himself to be out
of touch with the needs and desires of the community as a whole.

At a time when open source is bigger than ever and becoming more and
more important in the commercial space, the last thing we need is a
'leader' who actively fights against anything that doesn't fit his
exact model of freedom. At some point, you have to take a step back
and realize that blind idealism does nothing but stop forward
movement.

Miguel: Keep up the great work. From Gnome to Mono, you've shown an
active interest in improving the Free Software desktop and haven't
hesitated to make change where you thought it was necessary.
RMS: Start thinking objectively about the effect your words have on
the community. I respect you for sticking to your guns, but your
position requires you to see the big picture too.

- Cody Brocious (Daeken)

Posted via email from I, Hacker

(Some quick notes before the article. My Pokerstars reversing series
is still in the works, but I've been on vacation for a few weeks and
haven't given it the attention it deserves. There'll be a new post
shortly. Also, I'm currently looking for contract work, and you can
see some info here: http://daeken.com/open-for-contracts )

I finally broke down and installed EVE Online and registered for a
trial, since quite a few of my friends have been talking about it
nonstop. Being the dork I am, I looked through the binaries that were
installed, and I immediately noticed that they shipped Stackless
Python 2.5 as a separate binary (python25.dll). Of course, this led
me to an investigation of what I could accomplish with respect to
modifying the client without actually patching any code. A few hours
later, I was able to run any Python code inside of EVE.

All of the code is available from the Github repository here:
http://github.com/daeken/EveInject

Injector

First, you have to get some sort of code into the game process. My
favorite tool for this stuff is EasyHook, as it lets you
inject .NET code into processes.

EasyHook, as the name implies, is very easy. You don't even need to
hook anything here, just get some code running in the process. With a
simple boilerplate NAnt build file and the source of an earlier
hooking project, it only takes a few minutes to strip it down to what
we need. EveInjector.cs finds the 'exefile' process for EVE and reads
the given Python file into a string. It then uses RemoteHooking to
inject EIInject.dll into the process.

In EIInject.boo, you can see what exactly is going on. In the Run
method, the following are called: Py_Initialize, PyRun_SimpleString,
and RemoteHooking.WakeUpProcess. The Initialize call should've
already happened, but this prevents the client from crashing if the
injection happens very early in the load process. The PyRun call runs
the code you gave, and the WakeUpProcess call causes the EVE process
to come back to life, although it never seems to actually go to sleep.

We now have control over the EVE process.

Logging

If you notice, there's a LogServer.exe binary in the EVE directory.
This will display all sorts of interesting information from the EVE
client. We need to be able to write to this.

In my early experimentation, I noticed that traceback.print_exc()
would go to the log server, so it was clear that stderr was tied to
the log. By doing the following, you can print to the log directly:

import sys
sys.stdout = sys.stderr


Modules from compiled.code

All Python code in the client is Stackless Python bytecode and split
up into a few files: lib/corelib.ccp, lib/corestdlib.ccp,
lib/evelib.ccp, script/compiled.code. You can read about the details
of these files on the http://wiki.evemu-project.co.cc/eveFileFormats if you want
to play with them. Anyway, the compiled.code file holds the bulk of
the game code, but if you inspect sys.modules, you won't see anything
from there. That's because it's handled by the 'nasty' module in
libccp.

To expose these modules to sys.modules (and thus make it easy to import them):

import sys
import nasty
for key, value in nasty.nasty.mods.items():
sys.modules[key] = value


Services

In the 'svc' module, you can see all the service classes available on
the client, but you can't directly instantiate any of them. Instead,
you have to use the 'eve' instance. The 'eve' instance is the center
of everything, client-wise. To get to services:

from eve import eve
gameui = eve.LocalSvc('gameui')


You can see the methods available in the gameui instance via the svc module:

from svc import gameui
print dir(gameui)


Future

From here, getting to the bytecode of the functions is fairly easy, so
it'd be nice to have an in-process decompiler that dumps the code of
all modules, without having to mess around with the files directly.
There are also a large number of bugs in the current injector, which I
think stem from this code running in another thread from the normal
Python interpreter. I'm fairly sure there's some way to acquire the
GIL for the duration of the injected code running, which should fix
it.

All that said, I think there's some fun stuff that can be done with
this. From here, it wouldn't take a huge amount of work to build
something akin to Macroquest, where you can extend the UI, automate
tasks, and generally make life better inside the client. With some
tweaking, it's possible to make this fairly difficult to detect, but
I'd be careful using this on an account you really care about early
on.

Happy Hacking,
- Cody Brocious (Daeken)

Posted via email from I, Hacker

I've decided to open up for contracts for a little while. My
interests are generally in reverse-engineering and
kernel/compiler/emulator development, but I've extensive experience in
all sorts of development and design. If it piques my interest and I
know what I need to do, it'll be done.

 Key skills:

• Extensive software reverse-engineering experience with a specialty in file formats and network protocols
• Compiler development skills with a specialty in high-level->high-level compilers and bytecode->machine code ahead-of-time/just-in-time compilers
• Kernel development with a focus on pure-managed kernels, microkernels, and general embedded kernels
• Game protocol reverse-engineering and client/server reimplementation

 Languages:

• Use: Python, Boo, C, Nemerle, x86 assembly, ARM assembly, Power/PowerPC assembly, Ruby
• Use occasionally: C#, C++, Perl
• Will not use: Java, PHP

 If you have a project at any stage of development, shoot me an email
(cody DOT brocious AT gmail DOT com) and we'll discuss it.

 - Cody Brocious (Daeken)

Posted via email from I, Hacker

Let me start with a little background. I got into poker botting after
reading James Devlin's great series on Coding The Wheel. I tried a
few different attempts at the IO layer (hooking the poker client
directly, screenscraping (wrote a cool little library), etc) before
settling on hacking the protocol directly. However, I also started
getting into actually playing poker heavily, and I realized a little
while ago that there's no way this bot will be profitable (including
my time) unless I throw years of work at it, so I've decided to
release my knowledge publicly. I've not seen anyone reversing the
PStars (or any other service, in fact) protocol publicly, so I'm
hoping to help out there.

 The likelihood of things staying the same after this is released is
very slim, so for reference my work is being done on the latest client
as of today, 8/19/09, version 3.1.5.8. All code is available on the
Github repo, and I'll be doing code releases to correspond with the parts
of this guide. This stuff will only work on Windows with Python 2.6+.

 First things first, we have to go into this with a game plan. We need
to end up with a client, but what's the best way to get there, since
we need to be able to adapt quickly to changes? I cut my teeth on
server emulators for MMOs, and I've found that building a server can
allow you to find changes quickly. However, we also need to be able
to see traffic, so we need a way of sniffing and displaying traffic.
Therefore, I think the best route is to build the following: an MITM
proxy with a web interface for viewing packets, a server emulator, and
a client library.

 Now that we have a plan, we can to dive right in. I made the
assumption that everything was done over SSL, and quickly confirmed
this with Wireshark. There's a lot of traffic and it indeed uses SSL.

 I decided to implement everything for Python 2.6, to take advantage of
the ssl library. With this, I built a simple MITM to display
traffic both ways. But here's the first snag: the PokerStars client
checks the server's certificate. However, this was an easy fix. I
generated a keypair for the MITM (can also be used for the server
emulator) and found that they stored the normal server cert in
plaintext in the client binary. A quick patch script later and the
MITM works like a charm, dumping raw data. A quick look over, and it
became clear that there's a static initialization field (42 bytes) at
the beginning of both the server and client transmissions, and then
packets sent with a 16-bit (big endian) size in front of them.

 Time to start looking at the client to figure out what it is.
Breaking out my handy dandy IDA Pro and loading PokerStars into it, I
started searching through the strings list for compression- and
crypto-related strings. I stumbled upon a few interesting strings,
the clearest of which was: "_CommCompressedCommunicator: LZHL frame is
too long". Googling around a bit, I found that LZHL is a lightweight
compression algorithm intended for high-performance network
situations.

 Next stumbling block: the original implementation of LZHL has fallen
off the Internet, and the only remaining implementation I can find is
buried in a big, unmaintained library. Cue 2 days of attempting to
reimplement the algorithm in Python with no actual verification that
it is the only thing in play. For those of you playing the home game,
this is a Bad Idea. After a day of debugging, I gave up and
simply beat the C++ code into submission, utilizing the ctypes library
in Python to wrap it into a usable form.

 Tying this into the MITM, I can now see the decompressed frames coming
across the wire, complete with nice clean plaintext. However, there
is a clear header on the packets, so that has to be reversed next.

 Here are some choice packets from the beginning of a connection:

 
-> 106 bytes: 
0000 00 6a c1 06 00 00 38 33 60 10 02 69 70 3a 36 36| .j....83 `..ip:66 
0010 2e 32 31 32 2e 32 32 35 2e 31 37 3a 32 36 30 30| .212.225 .17:2600 
0020 32 00 41 6c 74 31 4c 6f 62 62 79 53 65 72 76 65| 2.Alt1Lo bbyServe 
0030 72 49 6e 73 74 61 6e 63 65 00 53 68 61 64 6f 77| rInstanc e.Shadow 
0040 54 6f 75 72 6e 61 6d 65 6e 74 73 50 75 62 6c 69| Tourname ntsPubli 
0050 73 68 65 72 30 00 00 00 00 00 00 00 00 00 00 00| sher0... ........ 
0060 00 00 00 00 00 00 00 00 00 00 | ........ .. 
 <- 2048 bytes: 
0000 08 00 81 00 0d 6a 54 06 00 00 39 33 60 10 02 d7| .....jT. ..93`... 
0010 4e 7c e2 06 00 00 00 00 02 95 f3 10 30 00 00 1b| N|...... ....0... 
0020 18 4a 72 d0 48 eb 65 b3 2d 00 00 00 00 00 02 00| .Jr.H.e. -....... 
0030 00 00 00 01 02 95 f3 10 11 5b 00 00 e3 61 43 02| ........ .[...aC. 
0040 8f fd 1b 00 02 ff 00 e3 61 44 00 e3 61 44 ff 00| ........ aD..aD.. 
0050 00 00 85 0b 0b 60 df 69 70 3a 36 36 2e 32 31 32| .....`.i p:66.212 
0060 2e 32 32 35 2e 31 37 3a 32 36 30 30 32 00 00 00| .225.17: 26002... 
0070 00 00 00 00 00 00 00 00 00 00 06 e0 00 00 00 f0| ........ ........ 
0080 00 00 00 00 00 00 80 32 30 20 50 4c 20 42 61 64| .......2 0.PL.Bad 
0090 75 67 69 00 00 00 00 00 00 00 00 00 00 08 44 60| ugi..... ......D` 
00a0 02 d0 01 00 02 00 00 00 03 00 00 00 10 ff ff ff| ........ ........ 
00b0 ff 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00| ..@..... ........ 
00c0 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 09| ........ ........ 
00d0 45 55 52 00 00 00 00 00 ff 00 e3 61 45 02 8f fd| EUR..... ...aE... 
00e0 1b ff 00 00 00 08 00 00 01 80 00 00 00 01 00 00| ........ ........ 
00f0 e3 61 46 02 71 f0 93 00 02 ff 00 e3 61 47 00 e3| .aF.q... ....aG.. 
0100 61 47 ff 00 00 00 85 0b 0b 60 e0 69 70 3a 36 36| aG...... .`.ip:66 
0110 2e 32 31 32 2e 32 32 35 2e 31 37 3a 32 36 30 30| .212.225 .17:2600 
0120 32 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 6e| 2....... .......n 
0130 00 00 01 4a 00 00 00 00 00 00 80 33 30 20 50 4c| ...J.... ...30.PL 
0140 20 42 61 64 75 67 69 00 00 00 00 00 00 00 00 00| .Badugi. ........ 
0150 00 08 44 60 02 d0 01 00 02 00 00 00 03 00 00 00| ..D`.... ........ 
--snip-- 
 <- 2048 bytes: 
0000 08 00 01 06 44 00 02 d7 02 00 03 00 00 00 09 00| ....D... ........ 
0010 00 00 10 ff ff ff ff 80 00 00 00 00 00 00 00 00| ........ ........ 
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00| ........ ........ 
0030 00 00 00 00 00 09 45 55 52 00 00 00 00 04 ff 00| ......EU R....... 
0040 e3 61 9f 02 7e 31 23 ff 00 00 00 08 00 00 01 80| .a..~1#. ........ 
0050 00 00 00 00 00 00 e3 61 a3 02 8d 14 01 00 02 ff| .......a ........ 
0060 00 e3 61 a4 00 e3 61 a4 ff 00 00 00 b5 0b 0b 61| ..a...a. .......a 
0070 05 69 70 3a 36 36 2e 32 31 32 2e 32 32 35 2e 31| .ip:66.2 12.225.1 
0080 37 3a 32 36 30 30 32 00 00 00 00 00 00 00 00 00| 7:26002. ........ 
0090 00 00 00 00 24 40 00 00 02 d0 00 00 00 00 00 00| ....$@.. ........ 
00a0 80 31 30 30 20 4e 4c 20 48 6f 6c 64 27 65 6d 20| .100.NL. Hold'em. 
00b0 5b 48 65 61 64 73 2d 55 70 20 3c 62 3e 54 75 72| [Heads-U p.Tur 
00c0 62 6f 3c 2f 62 3e 20 31 36 20 50 6c 61 79 65 72| bo.1 6.Player 
00d0 73 5d 00 80 31 30 30 20 54 69 63 6b 65 74 00 00| s]..100. Ticket.. 
--snip-- 

 I've truncated two of these, because the actual data doesn't much
matter here. First and foremost, look at the first two bytes of each
packet. It's a 16-bit value corresponding to the packet size. At
first, I believed they had the compressed size (outside) and
decompressed size (inside) for verification purposes, but a little
later I discovered that they'd combine packets where possible. A
single compressed packet can contain multiple packets, and they'll
push it up to the 65536 bytes before compression (no logic for
combining more intelligently).

 Next up comes a flags byte. This I determined by guess and check
largely. The breakdown is:

• Flags & 0xC0 == 0x80: Beginning of a message chain. If the next byte is 0, there are 4 unknown bytes following.
• Flags & 0x40 == 0x40: End of a message chain.

 If the flags byte is anything else, it's a message in the chain (if
it's placed in a chain) or a self-standing message. From here, we'll
refer to 'message' as the raw data inside the transport stream. That
is, everything from the flags byte+1 (or +5, in the case of it being
the start of a message chain and the flags+1 byte being 0 as indicated
above) onward, including additional messages in the chain.

 Looking at the messages, we'll see some repetition in byte 2. I
guessed that this was the opcode field indicating the type of message,
and some quick verification shows this is most likely the case. One
other interesting thing is that there's an incrementing ID that is
shared by the client and server. With a little detective work, you
can see that if byte 1 is 0, the ID is from 3-7 (exclusive), otherwise
it's 1-5. By looking at the plaintext that's sent, you can see that
the ID is incremented by the client when creating a new request chain,
and is used by both sides for the duration of that chain. For
instance, you can see that the ID in the packets above is 0x33601002.
You can also see that the second packet is a new chain and the third
packet is a continuation (it's not the final packet).

 Now that we have all this, a clear picture of the transport itself is
beginning to form, but here's something unusual: most packets have the
same opcodes. Lots of 0x38s, 0x11s, etc. This baffled me for a
little while, before I went back and looked at the initial packets,
where it was requesting 'server instances' and such. After this, a
light clicked on in my head, and I realized that the entire PokerStars
protocol is a series of client-server connections funneled through one
of a long line of frontend load-balancing servers.

 A little bit more digging around told me the following about these
connections: (note the --> and -<- conventions for
client->server and vice versa)

• -> 0x10: A sort of async method call, only used initially.
• -> 0x38: Establish a connection to a service provider, from which streaming lobby, tournament, table, etc data is received.
• <- 0x39: Response to a connection. Seems to have some sort of header with connection info before the data starts streaming in.

 From this, I began to piece together the protocol and how the
client/server could be implemented. I wrote a web-based protocol
viewer and started pouring over logs.

 In the Github repo you'll find the following:

• LZHL: VC++ source tree, compiled dll, and Python wrapper.
• PSHooker and runpstars.bat: This is an application using my Nethooker library to redirect the PokerStars connection to the MITM/emulator. You'll likely need to edit the binary path in runpstars.bat, and you need to add a HOSTS entry pointing 'pshack.com' to 127.0.0.1 to make it work.
• pmitm.py: This is the meat of the codebase. It writes out log.txt containing the raw packet data for consumption by the web interface and gives hex dumps of the packets over stdout.
• patchCerts.py: This patches the PokerStars binary to use the unofficial certs. Run with: python26 patchCerts.py path/to/PokerStars.exe path/to/newpokerstars.exe officialcert.pub mitmcert.pub
• WebPoker: Pylons project to view the packets. Edit WebPoker/webpoker/lib/Protocol.py to point it at the location of logs.txt from pmitm.

 I hope this was clear and that you got something out of it. There's a
lot more to rip apart, and I hope to give more (and better) examples
in the future.

 Thanks for reading, and happy hacking,
- Cody Brocious (Daeken)

Posted via email from I, Hacker

 It's now been just over a month since this iteration of the Renraku
project began. In that time, we've made monumental progress in
effectively every way. We're up to 4 developers and a designer (see
the pretty logo?), we've started to solidify the actual design of the
codebase and how it's going to function in the future, and we're
steadily pushing toward being a usable OS. We have a very long path
ahead of us, but we're iterating quickly.

 Today, we're proud to announce the release of Renraku OS version 0.2
alpha, codenamed "The Way Up".

 What's new:

• Services – allow the interface to be decoupled from the implementation and provide a model for drivers, filesystems, network servers, etc.
• Contexts – allow applications (Capsules, in Renraku terminology) to access services, and allows nesting such that you can run a Capsule in a sandbox where you provide filtered services, e.g. transparent proxying, nested windows, etc.
• Mouse support – Renraku now supports PS/2 mice via a simple service interface.
• VGA and general video interface – We can now use the latest in video technology (320x200 VGA, of course) in Renraku applications, even features double buffering. Progress is underway by one of our developers to build a basic GUI, but we have a few example apps.
• BCL improvements – We've been gradually implementing various collections (ArrayList, Queue), text helpers (StringBuilder), and other pieces of the BCL, as we make the development process higher and higher level.
• Compiler improvements – Inheritance, enums, interface implementation, method overloading, and many other things now work perfectly. There are now only a few key components (reflection and generics being the two big ones) missing before the compiler is effectively functionally complete.
• Bootable ISO building – You can now build bootable ISOs along with the kernel image.
• New apps to test out our new functionality:
  • 'exclaim' – Example nested Context application, turning your '1's into '!'s by hooking the keyboard service. Screenshot
  • 'draw' – Simple bouncing box VGA demo. Screenshot
  • 'mouse' – Control a box cursor with your mouse, changing the colors with the click of a button. Screenshot 1 Screenshot 2
  • 'logo' – Renders our logo in beautifully dithered 256 color VGA. Screenshot

 You can get a bootable ISO or check out the tree at Github. We'd love to hear what you think; drop by our IRC
channel, irc://irc.freenode.net/renraku. If you run into
any bugs, feel free to throw them on our issue tracker.

 You can also see the complete screenshot gallery as well as a few shots of Renraku running on real hardware.

 We've had fun building it, I hope you have fun playing around with it.

 Happy Hacking,
- Cody Brocious (Daeken)

Posted via email from I, Hacker

 
The Renraku OS team is proud to announce the first release, 0.1alpha.
Major strides have been made in the two weeks since the new codebase
was started, and we're very happy with where things are.
 
We now have:

• Initial compiler with support for vtables, a good chunk of the CIL instruction set, string object constants, etc.
• Initial memory manager (real memory manager is in progress).
• Basic object manager.
• The start of System.Array/String/Console.
• Keyboard driver and US English keymap.
• Basic shell that can execute applications.
• Basic HAL and interfaces for timer, keyboard, and network drivers.
• Initial PCI base class.
• A few simple applications:
  • 'echo' – Echo terminal
  • 'reverse' – Reverses the arguments passed to it
  • 'halstatus' – Prints the status of loaded drivers
  • 'pci' – Scans for PCI devices and dumps the vendor and device IDs
  • 'shell' – Creates a subshell

 
We've also created an IRC channel, #renraku on Freenode where
the developers are generally available. If you want to give it a
spin, grab the kernel image and boot it with GRUB. If you run into any problems, drop
us a line on the channel.
 
For the curious, you can check out this gallery of screenshots of the various commands. And as always, the
codebase is on Github.
 
Give it a shot and let us know what you think.
 
Happy hacking,
- Cody Brocious

Posted via email from I, Hacker

This is a follow-up to my previous post, Renraku: Future OS.
 
I got the latest incarnation of Renraku booting yesterday, based on
the code base I started the same day I wrote the previous article.
There's not much to it, but development is progressing very, very
quickly since I have plenty of knowledge of what not to do from
previous attempts. What's there (in the GitHub repo)
now supports very basic functionality: multiple function compilation,
a good number of "Base instructions" (from the ECMA CIL spec), static
fields, pointer intrinsics, and string intrinsics (get_Chars for now).
 
The test kernel is available here (GitHub) and this boots as expected. Obviously, it doesn't do
much, but that's coming. What needs to be done in the short term:

• Struct support
• Struct pointers
• Basic object manager

 
That's it. Once those are done, there's a primitive object model
which means actual functionality can be written. A few more days of
work, and we should be able to see a simple shell come up.
 
Happy Hacking,
- Cody Brocious (Daeken)

Posted via email from I, Hacker

Renraku is a family of managed research kernels I've been working on
for around 4 years. Though the goals and implementations have changed
over the years, they're all designed to be highly reliable, fast,
portable, and flexible enough to keep up with the changing needs of
today's technology.
 

Background

 
Initially, Renraku (known as Colorblind at the time) was simply an
experiment. Inspired by Unununium in its Python era, I saw the value
in kernels being very high level. Ease of development, in the hands
of the right hacker, could mean vast improvements in a short period of
time. With this in mind, I set out to build a prototype. I built a
number of revisions on top of existing OSes, but in the end I couldn't
get the design I wanted. I shelved the project, but never forgot
about it.
 
Shortly thereafter, I started playing around with the development of
Talk, an L4-inspired microkernel. It was very simple, written in
straight x86 assembly, and was intended to see how small such a
microkernel could be without sacrificing critical functionality. It
didn't get far due to not having enough time, but while designing the
set of base services and their interactions, it made me think back to
Renraku.
 
It sat on the back burner for about a year and a half, until I saw
MSR's Singularity project, some time around 2006. At this point, I
started seriously thinking about what I want in a future OS and how I
can go about implementing it. I've since written a few prototypes in
a mix of C# and Nemerle, and the goals have largely solidified.
 

Goals

 
High level:

• Pure managed code. No C, no assembly not generated by the compiler, no pointer access outside of the object manager and certain parts of the kernel.
• Everything is an object. Turtles all the way down.
• Single address space and no userland. Everything is ring 0.
• Completely network-transparent objects.
• Object store instead of a traditional filesystem.
• System-wide orthogonal persistence.

 
Implementation:

• Pure .NET. Currently playing around with Boo for it, due to their new macro syntax and functionality.
• Ahead of time compilation for the base services.
• Object model implemented on top of itself. That is, the object model is implemented in terms of value types and pointers, and the compiler has intrinsics for object model instructions to auto-call the implementation.
• While designing/implementing any feature, now is always better than later. Always, always, always go for the practical, simple route before considering a more complex one.

 

Roadmap

 
This is a rough roadmap of the implementation of Renraku. How far
this ends up going is really up in the air; it could go to the end,
it could be abandoned half way and rewritten again. Eventually, I'd
love to see these ideas come to fruition, though.
 

• Initial CIL->x86 compiler. Uses the actual stack to execute code, as optimizations can be added later.
• Initial memory/object manager. Nothing fancy, just enough to get things up and running.
• Begin implementing the .NET BCL. Get basic string manipulation and collections working.
• Implement keyboard support.
• Implement a basic shell. Allow object inspection/manipulation.
• Implement initial object store.
• Implement basic networking and network transparent objects.
• Build framebuffer support and a basic GUI library.
• Implement the dependencies of the Boo, C#, and Renraku compilers.
• Implement a basic terminal and REPL.

 
Once these things are implemented, development should be able to
progress very rapidly. There's just a lot of work to do to get there.
 
What would you want to see in a future OS? What would you like to see
go away? What new UI paradigms ought to be used? I'd love to hear
feedback on this, as there's simply a lot to think about.
 
Happy Hacking,
- Cody Brocious (Daeken)

Posted via email from I, Hacker

While laying in bed and trying to sleep last night, I had an idea I'd
like some feedback on. The idea is partially destructive garbage
collection, which allows the runtime to handle caching, instead of the
programmer. With PDGC, the runtime is allowed to destroy an object
and keep only the relevant data for recreation around. If you're
running a photo management application, for instance, you may want to
keep JPEGs and thumbnail bitmaps in memory, while not keeping the full
bitmap around. In theory, this is a problem that PDGC can solve for
you.
 
At compile-time, the compiler can look at your class and determine
whether or not your object's creation has side-effects, or depends on
factors outside of its control (e.g. IO), and make a determination if
it's partially destroyable. If it is, then the compiler embeds code
into the constructor (and other relevant methods*) to save the data
needed to recreate the object. At run-time, the frequency of access,
object creation time, etc will be tracked, and the PDGC can make the
decision to destroy the object or keep it around. If the object is
destroyed, it doesn't entirely go away; rather, it's replaced with a
stand-in object that stores the relevant data for recreation.
 
Further ideas:

• You could allow the PDGC to only destroy certain object properties, rather than the full object
• A more general approach to language-level caching would allow the objects to be saved to disk and loaded lazily. This is something I plan to explore as part of my Renraku research kernel, the details of which I'll be posting on soon.

 
General open questions:

• What research has been done on this previously? What were the findings?
• How much of this belongs in the compiler and how much in the runtime? This obviously comes down to the implementation, but I believe there needs to be research into good, general approaches.

 
Implementation questions:

• Should this be involved with the GC at all? In my mind, they're related, but in a specific implementation they may well be completely separated.
• What factors are used in determining whether or not an object persists? Factors I can think of are: frequency of access, cost of object recreation, size, amount of free memory, amount of free swap space.
• Should this be behind-the-scenes compiler magic, or should it be more user controllable? E.g. should the user be able to decide if an object is destroyable at a given point? Should the user be able to override the object recreation portion, rather than letting the constructor do its thing?

 
I'd love to hear your take on it.
 
Happy Hacking,
- Cody Brocious (Daeken)

Posted via email from I, Hacker

I've finally decided to take the plunge and move to Posterous.  If all goes according to plan, my posts from here should automagickly be crossposted to my Livejournal, but that's going to primarily become my personal blog; this blog will be used for all things tech/business.

To get things started, I'd like to introduce my new programming language, Ultilang.  The name is horrid, so please, add suggestions for a new one here: http://ultilang.wikia.com/wiki/NameIdeas.

Ultilang is a strange mix of Nemerle, Python, and Lisp.  A curly brace-based syntax, heavy metaprogramming, and multiple backends (.NET, JVM, Python, and JavaScript planned) come together into what I intend to be the most flexible, powerful language out there.  By leveraging features typically reserved for heavy-duty functional languages and blending them with the ease of use we've come to expect with languages like Python, I hope to create a language suitable for near every task.

The compiler, available at http://github.com/daeken/Ultilang/tree/master, is written in Python and builds/runs a Python AST.  It's currently in the early stages, having just been started yesterday; the first test, a simple recursive fibonacci sequence printer, runs perfectly.  There's a decent bit of work to do before the compiler can bootstrap up to Ultilang itself, but it's coming along nicely.

There's a list of planned/requested features at http://ultilang.wikia.com/wiki/Features; feel free to add your own.  Even if they don't end up in the language itself, they may well become a macro in one of the libraries.

Stay tuned for more information as the language progresses.

Posted via web from I, Hacker

So, I've been doing the WSOP Freerolls on Pokerstars, in an attempt to make it to the weekly final and possibly score a seat at the WSOP.  I've been gradually getting better and better, since yesterday was my first real tournament.  This last one, I placed 298 out of 10,000 players, having made it past the first round.  Not bad, but I need to step my game up a lot.

I slipped up and went in on some hands that weren't up to scratch.  Overall, I did damn well, but I'm really the only reason I lost, in the end.  I got shitty hands the whole first round (I got big slick once, but no one even bit at my tiny bet), but I played the hell out of them... second round, not so much.  I got several decent hands, but I misplayed them, and at one point I ended up down to the felt, which meant I had to play even smarter and get back in the game; that did not happen.

I'm going to go over my hand history and revise my strategy and, you know, actually stick to it next time around.

This is part three of my series on Belize.  You can read part one here: Belize, the next Silicon Valley? and part two here: Bootstrapping an economy into the 21st century.  As before, all figures are in USD.  One thing I've not yet mentioned explicitly in my posts is that everything I'm going to talk about requires the government to do absolutely nothing.  I may mention action the government can take, but in no case will it be required, and I believe the private sector solutions I'm suggesting will be far more benefitial to all parties involved.

In my previous post, I discussed the importance of building higher learning establishments.  However, I missed a very important fact: if you're attempting to boost the economy of a poor country, the people are generally going to be too poor to afford such education.

I really see two major routes for getting people educated:  student loans and subsidation by potential employers.  These are really quite similar, with the primary difference being who the debt is on.  With student loans, the debt is on the student and it's possible to charge interest; with employer-subsidized education, the debt is on the employer and they hope to pay it off with the fruits of the employee's labor.  Regardless, the employer wins out, as neither route would work if the employee becoming educated was a net negative for the lender.

All of this said, I think student loans are a bad solution.  Imagine the following scenario.  Ten established tech companies in Belize found a higher learning institute together, so they can train Belizeans to work in the industry rather than shipping in workers.  If they were to give student loans (let's assume these are interest-free for simplicity), the student is contractually bound to pay it back and even if the schooling costs $100k/yr, they will eventually get it back.  It doesn't really matter to the companies that it will take the student 20 years to pay it off, because they will eventually get it back, generally.

Now assume the companies pay for the education themselves, with the intention of paying it off with the money the worker makes them.  They have a vested interest in making the education as inexpensive and as high quality as possible.  The higher the quality of education, the easier it's going to be for the worker to make them money, and the less expensive it is, the sooner they're going to profit off the deal.  At the surface, they're 'loaning' money to the student, but the difference is that they only get paid if the terms of the deal are favorable to both parties.

It seems clear to me after consideration that the only way to successfully educate the masses of Belize is for the tech industry itself to subsidize the education.  What isn't clear to me is why this isn't the way things work elsewhere.

This is part two of my series on Belize. You can read part one here: Belize, the next Silicon Valley? As in the previous post, all figures are in USD.

As I detailed in my previous entry, Belize has a multitude of benefits to those looking for a tech start-up location. Little to no taxes, low cost of living, and cheap real estate. However, I deliberately neglected to touch on the negatives, as I think they're worthy of their own post.

The first big negative is expensive and outdated telecom infrastructure. BTL (Belize Telemedia Limited) has a monopoly on all things telecom and it shows.  It's difficult to pin down the exact figures as they stand now (BTL's pricing on their site was last updated in 2003), but it looks like about $100/mo for 1.5Mbit DSL.  That is simply abysmal, but it makes sense.  You have one big telecom company with no competition, mostly poor residents, and tourists with cash.

The second big problem is a severe lack of higher education.  I'm no fan of it in general (hard to be one when you never finished high school), but the effects are abundantly clear in Belize.  Skilled workers in the tech industry are effectively non-existent.  Of course, this makes sense, because Belize has no tech industry.  Why teach something that students will generally have to leave the country to practice?

I'm certain there are many other big problems I'm missing, but I'll start with these.  How do we solve them?

I think they can both be solved by one thing: start a tech industry.  The benefits to startups are such that I'm most certainly going to be moving there myself, soon.  If even a few startups spring up in Belize and succeed, the impact on the nation would be massive.

For the first problem, telecom infrastructure, it's a direct effect.  Companies spring up requiring better telecom infrastructure, and either BTL adapts or someone else sweeps in and provides it.  One thing is clear: there's no way these startups will be left in the dark.  There's simply too much money to be made, and the telecoms damn sure aren't getting it from the masons and fisherman as it stands.

The problem of education would be solved more slowly, but it seems like it'd happen.   If a decent number of medium-large tech companies pop up, they're going to need phone/email support staff, IT workers, programmers, electricians, salespeople, etc.  In the early days of this bootstrapping process, they'll come from the US and other countries where it's easy to immigrate to Belize, but that's a highly inefficient way of expanding.  Instead, I believe that higher learning establishments will either spring up anew or expand their existing programs.  More and more often, these jobs will be filled by Belizeans.

If you sustain this process for long enough, eventually you'll hit a tipping point.  Belizeans will start to build startups, staffed by other Belizeans, and the chain reaction will sustain itself.  Of course, where there's money in one industry, other industries will follow.  The quality of medical care will likely increase, you'll get better options for travel and lodging, etc.  All of this adds up to the cost of living, the GDP (which was a mere $2.5B in 2008), and the average wage will increase.  This is a Good Thing (TM).

I'm obviously biased towards the tech industry in general, but I really believe that the building of a tech industry in Belize could have a substantial positive impact on the country as a whole, over a short span of time, perhaps even as little as 10 or 15 years.

I've been a proponent of Belize as a corporate tax haven for a while, due to the fact that you pay no taxes on foreign income, but it wasn't until recently that I started looking at it for residence.  What I found was the following (all figures are in USD):

• Personal income tax is capped at 25% and doesn't apply to dividends from companies (meaning you can pay nothing if you start an IBC (international business company) and funnel your money through that), and there's no capital gains tax.
• Property taxes are approx 1% of the value of the undeveloped land, when outside cities, and extraordinarily low even in cities.
• Land, developed and not, is incredibly cheap.  You can pick up a nice house inland for US$20k, and you can buy undeveloped industrial land for $1-5k/acre, depending on location.
• 3-4 bedroom houses can be rented for $250-500/mo, depending on location.
• Immigrating to Belize is as simple as flying down there, getting a tourist visa, and then applying for residency after 6 months.  Citizenship can be applied for after 5 years.  It really comes down to this: if you want to move there, you simply have to pay for it, and you don't have to pay much.

All of this has me thinking, this all adds up to making it very cheap to build a startup.  Low taxes, cheap property, ease of immigration.  All of this is condusive to start-ups.

Imagine this, you and 2 other people want to start a tech company.  In any of the big tech hubs in the US, you're looking at spending at least $30k/yr per person (I'm being very conservative here), and you'll generally be living in at tiny apartment and eating ramen.  In addition, you'll be taxed out the ass.

Now imagine the same thing in Belize.  You can get a 2br house in most areas for $250/mo at most, you'll spend between $100-200/mo on food (really depends on how much you eat and how good you are at shopping around), you'll spend about $100/mo for a decent DSL connection, and you'll spend approximately $1500 on tourist visas, a work permit, and getting residency.  All of this adds up to living comfortably for $7500/yr (assuming about $150/mo on food) per person.

Now, if these same 3 founders were to get a nice sized 4br house together for $550/mo (which is easily doable) and upgrade the DSL a bit to compensate ($150/mo), you're looking at $6100/yr per person.

Regardless of which option you were to go with, one thing is abundantly clear:  a group of founders with $50k in the bank can easily live comfortably for 2 years in Belize with no outside income.  This combined with the complete lack of taxes on foreign income makes it a perfect location for tech companies.