quells

It’s incredibly difficult to form conventional ceramics into “the correct shape to begin with” with even millimeter tolerances because it shrinks twice during production. First when the liquid from the slurry/clay evaporates, and again when the particles sinter together during firing in the kiln. Both of these are non-linear and can cause warping with complex geometries.

EDIT: binders also typically burn off during firing, which further complicates changing shape during firing.

I think you just described Rust (although you have to deal with / get to take advantage of the borrow checker).

Usually these directories are owned by another group (www or www-data) so that your web server program (nginx, apache, etc) can access them without running as root. If you add your user to that group, you should be able to manage files in your web root without sudo. Be careful with permissions, though - you may need to chown to set the group after copying so that the files are readable by your web server.

> Biggest tip for fish switchers: set fish as your terminal's shell instead of changing your login shell.

That's an interesting idea - I will try that. This bit me recently when I used Migration Assistant to move from a Mac with Catalina to one with Big Sur; my login shell was still set to the path for fish installed via Homebrew, but none of those packages were copied over. I managed to hack around it by copying bash into that location so that I could reinstall Homebrew and fish to finish repairing things.

doh, thanks

I think the closest you can get is 3:2 on the Microsoft Surface line for modern laptops, which is even more vertical real estate.

Is there any documentation on how to run multiple instances of Micro which can communicate and share config/secrets? What is the horizontal scaling story?

Besides the fact that this would limit access to those projects for those unable to pay, there are the issues of multiple contributors and transient dependencies.

Say a project is started by one person, made open source, and becomes popular. They start accepting contributions from the public, including substantial features and bug fixes. They later move on and someone else becomes the lead maintainer. Who would receive the money in your scheme? The original author? The current maintainer? Divvied up among anyone who has ever touched the code? If the Digital Ocean tshirt giveaway is anything to go by, popular paid projects would be overwhelmed by "contributors" hoping to snag a slice for changing around a few words. It gets really complicated pretty quickly.

Say a project depends on one or more of these paid projects - does it now require payment of at least as much as the sum of its dependencies, and their dependencies, etc? That could add up quickly unless there's some scaling factor and you hope those projects make it up in volume. Surely there will be typosquatting projects which are (at best) wrappers for real ones and siphon off some of the fees.

And so on. All this is just to say that it's complicated and the details matter.

Ah, thanks for the correction. I had not seen the follow up since that was originally posted.

Many projects have long term support (LTS) releases which will receive security updates for 2-5 years without gaining new features. Security updates are generally not backported to other older versions, though it depends on the project/community.

You would need at least a bridging layer (of Objective-C) to so that your app code could use the system frameworks and respond to events (user input, network, sensors, etc).