Disclaimer: I’ve only been looking into this for a few days, so I may say something incorrect.
My understanding is that there is a single Mastodon implementation, but there are a number of similar projects which can interoperate by sharing data via ActivityPub to become federated. Some of these other projects implement all/most/some of the Mastodon REST API so that GUI clients (phone apps, etc) can be used for reading and posting. There was an article on LWN recently which listed several of these with some commentary [1].
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 this article was mostly a summary of the engineer’s personal blog post: http://amosdudley.com/weblog/SLO-Camera - linked from the post with example photos in another comment.
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.
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.
Probably not worth it to add dedicated cores for web processing, but iPhone already takes advantage of special ARM instructions for faster JavaScript execution [0]. That will almost certain be used on the new ARM Macs.
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).
It’s “available” but hasn’t been adopted yet by most motherboard manufacturers. Maybe we’ll see laptops with TB3 when the 4000-series mobile chips come out.
My understanding is that there is a single Mastodon implementation, but there are a number of similar projects which can interoperate by sharing data via ActivityPub to become federated. Some of these other projects implement all/most/some of the Mastodon REST API so that GUI clients (phone apps, etc) can be used for reading and posting. There was an article on LWN recently which listed several of these with some commentary [1].
[1] https://lwn.net/Articles/916154/