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.
It’s kind of amazing that you can get a ceramic container where the lid fits snuggly. Some of that comes from modifying the greenware (dried but unfired clay) but I think most of it is exacting tolerances for inputs and processing. Clay from this one quarry. This much water. These building temperatures and humidity. This exact furnace temperature and time.
One can fire a pot with the lid on it in the kiln. They tend to deform together. Of course, this requires that the mating surfaces not fuse together and may also produce a non-rotationally-symmetric interface.
I feel like I've watched videos where people make Japanese and/or Korean ceramic cook pots and I can't for the life of me remember how they kept them from warping, just that they do.
The only trick I do remember is don't glaze the contact point between the two pieces. That not only adds thickness variability, but if glaze touches the bottom of the kiln you fuse to the bricks, so you have to elevate anything glazed, and elevating increases warping.
How do they create things like ceramic turbo turbines and ceramic exhaust manifolds? Seems like the shrinkage problem would prevent these close tolerances.
The same shrinkage problem exists for the ceramic tooth crowns.
The vendor of the dental ceramic provides a program that uses a mathematical model of the shrinkage to compute the form required for the ceramic crown before sintering.
Of course the mathematical model is not perfect so the dentist may still have to do some small adjustments to the sintered crown.
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.
Also, if we extended this idea of paying for all the software people use, the whole thing would fall over very quickly. I don't think most developers here have ever sent Jean-loup Gailly and Mark Adler any money for zlib/gzip? And how many have sent checks to the people who've been contributing to the linux kernel? And gnu file utils and bin utils and compilers? And the openssl project? And OpenBSD for openssh? And any of the other hundreds of bits of code that they rely on on a daily basis to get their work done.
At the end of the day if you want to get paid for your work, don't give it away under a free license. This is the second major story -- that I've seen anyway -- in the last couple of weeks about people wanting to be paid for the software that they freely give away. It reminds me of the time I went to Rome and a man came up to me and slipped a string bracelet around my wrist. When I told him I didn't want it, he said "no, no, it's free. just a friendly gift." and when I said thanks and turned to walk away he got mad that I didn't give him any money. Apparently it's a typical scam. "Give a gift" but then demand a return donation of money.
> They start accepting contributions from the public, including substantial features and bug fixes.
I spent a considerable amount of weekends helping out with a FS2020 mod. The maintainer now accepts donations and makes a considerable sum. I got none of that. Personally, it left a bad taste in my mouth. I maintain a private fork now, because I don't like the idea of someone profiting off my rare nights and weekend work. It would be one thing if he recognized the work and/or gave back to the contributors in some way, but they don't... so I stopped contributing publically.
Let the maintainer monetize release versions. If new releases have major contributions from others, charge for the new release and dole out funds to the contributors.
Certainly some thought needs to be put into how to monetize this, but we haven’t ever even tried. I’d say something like NPM is sort of like how Uber/Lyft built and validated the ride sharing infrastructure - it works, it’s normalized. Now how do you manage the money between the drivers and riders.
It’s not like software devs and companies are broke and are unwilling to pay modest amounts, and we will always support free for non-commercial.
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.
That is not true. As it turns out, Safari didn't use that instruction [1] at the time and even when it did. 99% of those performance gain in Speedometer had nothing to do what that instruction .
I guess not really your fault. We have KOLs that put out information on their site and channels ( in this case DaringFireball and Twitter ) and they, for whatever reason never really correct themselves. ( Even when they knew they were wrong )
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/