2,569 karma · joined August 1, 2007
Ex-Stripe, Ex-Rdio, Ex-Palm, RIP-Startups I founded in between
Downside is all the buttons are on a screen. But I’ve grudgingly decided it’s worth it for software upgrades.
We’re staring down the barrel of two missed paychecks though. If you're living paycheck to paycheck you’re getting desperate. If you’re living with about 1 month of emergency buffer… that buffer is one paycheck away from gone. It’s a cash flow issue
The out of power party gets a little veto power here. The republicans know the day will come they want that, so they won’t change the rules even though they have the power to do so (theoretically… there are republicans that will never compromise on this). Unfortunately they can’t get on the same page with their lame duck leader
Edit: environment setup was also buggy when the product launched and still is from time to time. So, now that I have it set up I use it constantly, but they do need to make getting up and running a more delightful experience.
Personally I’ve found that where AI agents aren’t up to the task, I better just write the code. For everything else, more parallelism is good. I can keep myself fully productive if many tasks are being worked on in parallel, and it’s very cheap to throw out the failures. Far preferable imo to watching an agent mess with my own machine.
The thickness should be from the front to the back of the camera lens, not to the thinnest point they can find.
The former CTO of stripe, for one.
They show you the code they produce. Why wouldn’t you trust it after reading it?
Perhaps there are more qualifying statements that you meant to include? The certification and type rating requirements certainly differ between agencies, but in terms of raw number of flight hours it’s easy to find that this statement is false.
- Kernel talent was never a problem at Palm. The ex-Palm folks lead or are technical leaders at many mainstream unix-ish OSes today, plus Fuschia (Android, Apple, Chrome, Fuschia)
- Boot times weren't the highest priority (though we did spend time on it since they were _so bad_). Battery life was. We didn't even do that well by launch date, but if Android hadn't mainlined their power-management framework before the Pre launched it would have been a joke. It was all hands on deck to get that stuff integrated in time for launch.
- The webOS platform was actually a thin UI layer on top of an Android-like Java-based platform that never launched. The Java-based OS wasn't derivative of Android (it predated Android), but it had no differentiating features with Android already live. Booting the Java runtime _and_ the JS engine and webkit was a lot.
- We knew we couldn't have Java running on this phone long-term, so tons of effort was going into nascent node services instead of Java ones. So all those were launching too.
- Your memory is incorrect on the JS jit, or mine is. My memory is that we were adopting the latest v8 engines as fast as they would come out (although not as fast as chrome) because they were the only ones that could keep the thing performant.
- Webkit was a mess, I'll give you that, but I'm surprised you noticed. Were you at palm too? Did you build apps? We generally provided UI components that were the way to build apps that, hopefully, allowed you to ignore the intricacies of exactly which webkit version you were on (at least to build an app).
I think this is a bad take because I don’t think the core issue of the platform was that it was based on web tech. The web tech basically worked fine. However the bugginess and challenging user interface (which is actually standard today) was a huge issue. The leadership decision that was needed wasn’t to kill the touchpad 49 days after launch, it was to kill it before launch.
Palm was a raccoon backed into a corner and it was using all its cleverness to get out. But it was willing to ship stuff that wasn’t ready and couldn’t be ready with the resources we had. HP had the resources. They could have taken a good start and given it the space to become great. Maybe.
By default, the build relies on web workers which need to load their code from somewhere (and usually it has to be the same origin as the code making the request)
Through much mastery of JS build systems that I would not wish on my enemies, I bet you could get it working on localhost, but you’ll have a much better time of it if you set up vite or something for a local build. You can still easily do a “serverless” deploy with GitHub pages or similar but you do need an http server correctly configured for asset requests.
Peter Thiel and the people that did his fellowship don’t represent the majority of career paths people take in SV, but they do make for good (or too close to home) fodder.