nirvdrum

As luck would have it, you can just pay the provider and use their service. Others may want to run locally for privacy reasons or just for the fun of it. I think at-home AI is incredibly awesome and I applaud the enthusiasts pushing it forward. Just because that's where it's at today doesn't mean it's the best we can do.

Plus, you know, this thread was about running AI on "lame consumer hardware". There are more power efficient options available.

I don’t disagree, but to me web components solve a different problem. I want rich widgets without being bound to any particular JS framework and without having to ad hoc it everywhere.

As an example, I still like the simplicity of Rails for basic apps. I also enjoy the numerous component libraries, such as Antd, available for React. I don’t want to have to pull in React just so I can get a reasonable way to work with a Tree widget.

I’m not trying to only use the platform. The components are free to be built with whatever lightweight lib they need (Lit, UI5 Core, etc.). But that’s contained in the component. I’m free to use my framework or web technology of choice for building my app.

The very next sentence after the one you posted is "We expect normal porting activities to eventually add support for all major architectures." Goals and non-goals inform the scope of the proposal. Given this is effectively an "add-on", I don't think it's unreasonable to prioritize the most popular platforms. Others will continue to execute Java perfectly fine in JVM mode.

While not great, the virtual cards are an improvement, unless your kid and you never play the same games. One Switch gets to be the home console and doesn't need checks. The other would have to be logged in as you, which requires a license check every time you play. But, save files are tied to the account and you can't move them between accounts. If you use cloud save files, you and your kid are going to be bumping into each other all the time. Then, if you introduced a 3rd Switch, only one of the non-home Switches could play a game under your account at a time, even if they're different games.

I know 3+ Switches sound like a lot, but Nintendo was pushing the Switch Lite like the latest Gameboy. Maybe you concede and decide to buy the same game multiple times to avoid all of this. Well, there's no gifting. You need to enter your billing details into your kid's Switch and buy it there. Assuming you don't want to leave your credit card setup in their Switch, you get to go through this whole dance every time you buy something.

Virtual cards let you avoid a lot of this nonsense for two weeks. You'll rapidly get annoyed having to keep the original Switch and the new one in close proximity to do the exchange, but it'll work. But, it's nowhere near as nice as Steam Family or the iOS Family Sharing.

The limit is per-user, not per-editor. Every process under your UID shares the same max_user_watches pool. So the editor's "prioritize open files" behavior can't help when a resident daemon like Watchman has already consumed the budget. Zed doesn't error out when it hits the watch limit. It logs a warning and periodically retries to establish the watch. Until it can do so, external file changes aren't reflected in the editor.

I just checked my workstation and found Watchman alone holds ~556K watches across 34 roots. It keeps those watches even after the tool that spawned it disconnects. Notably, I've never invoked Watchman manually -- other tools do. And the 8k floor isn't much of a floor. My nixpkgs checkout alone is 37,686 directories, 4.6x that.

Truthfully, I had no idea Watchman stays resident and accumulates watched roots. But, that's kind of the point. It's a very easy thing to miss.

Have you checked your fs.inotify.max_user_watches value? Maybe your value is too low and Zed can't watch the files that are changing. I know the JetBrains IDEs need the default to be increased on Linux because they detected it and prompted me to increase it.

Nintendo Switch cartridges don't have this problem, mostly. It's the reason I buy physical for the family library. Nintendo's digital licensing is terrible (slightly less so with Virtual Cartridges, but miles away from Steam Family) and doesn't really work for a multi-Switch household.

But, I was traveling for work and brought the non-"home" Switch with me along with a copy of Breath of the Wild on cartridge. I fired it up on the airplane, ready to go. And then discovered that because I had bought the DLC and the DLC license check couldn't pass, I was locked out of playing at all. It's given me pause on buying any other DLC on a Nintendo platform.

If you click the “favorite” link it’ll be saved to your list of favorites. But, it doesn’t actually have to be your favorite —- it’s just a user-defined collection of HN posts.

I usually just amend commits as I go and don’t find it all that onerous. Sometimes it gets tricky, particularly if a rebase effectively changes what the code would have looked like. But, with LLMs even that’s gotten much easier.

Thanks for mentioning this. It seemed odd to me, too, so I spent some time trying to work it out. As a reviewer, I'm not sure how I'm supposed to assess database or API changes without knowing how they're intended to be used. And deploying them independently seems odd, too, especially if you need to roll it all back.

I think in my ideal world there would be a clean history and I could review a PR commit-by-commit. But, you can't just approve a single commit, so there's a tooling problem there. And most CI runs on an entire push rather than individual commits. And increasingly I see devs using git as an offsite backup for whatever change they just made, rather than breaking commits up into logical chunks. In that workflow, squashed merges make the most sense.

It's probably flawed, but the mental model I came up with is each stacked PR collapses into what would have been an individual commit in a clean PR, with the advantage of being able to be reviewed separately from the other changes and forced to clear CI. And then the whole stack becomes what would have been a clean PR in the old model. That, I can kinda see the benefit of. But, merging only part of the stack into trunk is the mental hurdle I can't clear; it'd be like merging only some commits from a PR. It kinda reminds me of when projects used CVS.

I've really only seen stacked PRs used on projects where history is little more than an audit log. I'm keen to see how this gets employed by open source projects. I think there's a disconnect and it's likely I'm not going to really get it until I see it.

I mean an application that does more than what I can do in a mobile web browser. If it's just a web page I'd rather just do responsive web design. Presumably you've developed this to build native apps with rich functionality.

Thanks for answering. Is there an example project you can share? I'd love to see this in action.

I bootstrapped two companies in my 20s. While living off savings to get going, $20k in medical would have been the end of that venture. I'm glad it's working out for you. I don't have hard data, but I suspect being so healthy you don't need a doctor favors younger adults without dependents. And being able to afford up to $20k without losing your business implies a certain amount of wealth before getting started. That matches the profile of most tech founders I know -- certainly all of the ones that bootstrap. I only managed to make it work because for the first one I was on my parents' health insurance and for the second I had COBRA and a funded HSA.

If we want to encourage people to start new businesses, some form of universal healthcare would be a massive catalyst. Starting a business is never going to be risk-free, but there's a big difference between risking your retirement or even your house and risking the health of your child.