Alky Postmortem | Hacker News Reader

Alky Postmortem

daeken.com

31 pointsdaeken18 comments

What makes this story even cooler is that Cody was probably 19 when it happened. Thanks for sharing!

It's certainly an interesting read although it's hard to see what is 'cool' about the outright unethical bits and the author's curious belief that if you don't personally gain (much) from taking someone's money for things you don't deliver, you're not actually ripping them off. Perhaps a framing more towards apology rather than 'useful advice for you!' might have been better, in places.

Perhaps I could've phrased things better, but I hope I made it clear that I do feel that we ripped people off. We hoped to make it clear that the Sapling Program was intended to support the project and that it was entirely possible that nothing at all would come of it, but even so it really sucked to see things go down the way they did.

We made a lot of mistakes, but if nothing else, I've learned from them and done what I can to not hit them again. I feel bad for the people who supported us and ended up not getting their money's worth, and I never want to do that to a customer again.

were you working for the Michael Robertson that started mp3.com, linspire, et al? if so, he already had his own shady past to worry about. here's one of his many enemies:

http://kevincarmony.blogspot.com/2009/11/gizmo5-sipphone-sha...

I was there near the beginning of the MP3tunes days, which has its own insanely shady past (much of which I can't talk about, sadly). I can say that there are few people in the world I trust less than MR, having seen how much he's done to hurt people, especially his employees and business partners.

Edit: Misread your question. Yes, it's the same Michael Robertson.

Maybe someone should create a group for hackers who formerly worked for an MR-started company.

I wonder what the reasoning was behind closing down the open-source project the way he did.

To be quite honest, I don't recall why we closed it the way we did. In retrospect, I can come up with few poorer ways of going about it, so I really don't see how it ever made sense. It's one of the biggest mistakes we made, IMO, even though I don't believe it directly related to the project's failure.

why not just link with libwine? it may be ugly, but there's a lot of people moving it forward, and leveraging that seems like a huge win.

> libwine

Slow and opaque.

having not used wine, i'll take your word for the 'slow' part. but what about it is 'opaque'?

Doesn't play well with others.

As noted in Daeken's post the source can be found on github here:

http://github.com/callen/Alky-Reborn

I am currently keeping that up there for two reasons:

1. Safe-keeping

2. So that I could read over the code from my friend's house on Christmas.

I would like to be able to begin development by New Year's, if anyone would like to discuss/collab on the code I welcome all comers.

i'm intrigued by this project. input a windows game, output a macosx executable. i have to admit that i'd love to have such a thing.

but i'm skeptical. what's to keep this from turning into a huge ungainly decades-long slog? given the history of the WINE project, that's what i'd assume is looming on the horizon.

There's really little to keep it from turning into that. In fact, I don't see any way it couldn't be decades long, if the plan is real windows compatibility. However, I think that the points I detailed under the potential new Alky design would keep things considerably simpler (though I think it's unlikely anyone would pick up the design).

As I said, I think the absolute key is a focus on maintainability. Everything comes from there.

>what's to keep this from turning into a huge ungainly decades-long slog?

Aggressive willingness to rebuild based on new knowledge.

I don't really think it's going to be practical to try to make Alky encompass compatibility with all windows applications.

I don't think it's practical to even attempt 80% of the apps out there. Wine already works for most of the basic windows applications.

The issue is various, in particular performance sensitive, software (games, CAD) that are windows-only and a pain to get working in Wine (let alone performant).

The wine approach is fine if you're satisfied with neglecting niche software + games, but a lot of what's holding people back is the fact that their computer is an entertainment box and cannot migrate said entertainment to OS X / Linux.

That's the essential problem I want to solve. How much surface area, compatibility-wise, that'll force us to cover is at present unknown to me. I'll just have to see what happens.

I'm really glad you put that up. Not only does it make it easier for people to access it (as you saw, it's difficult to get it from me personally), but it's been interesting to walk over it myself. It's been some years since I've so much as looked at it, so it's been interesting to look over things like NuContext, the COM class infrastructure, etc. I've forgotten most of the deep details of the codebase, so it's been like reading it for the first time. Really very cool.

I'm going to try and grab the Philosopher (compiler infrastructure used for the shader hacking) source off my backup drive in a few days and throw it up on Github.

Yeah I'd love to see the shader hacking stuff you've got.

I'm mulling over the Mono vs. blah question, let alone how to take the design from here. I'm going to be mulling over it until at least New Year's.

Reply on news.ycombinator.com