theothershoe
Joined 13 years ago
Karma
238
Submissions
21
Member since
Nov 12
Recent submissions
Comment · 3 days ago
I've been setting up my own self-hosted knot, with excitement - this is the kind of forge I've been wishing for! There's an architecture document, but I'll leave some notes on how I've come to understand things so far. https://tangled.org/permadeath.com/atgc/blob/main/docs/archi...
You have options for self-hosting one or all of three pieces: a headless git host (the knot) which you get direct ssh access to through a limited ssh interface like other forges use, a CI service (the spindle), and the service that provides your user identity and metadata (the PDS). Account metadata such as which repos are in your account, and public SSH keys are recorded in the PDS, while repo data such as pull requests are recorded in the knot (I think. There might be some cross-over for publishing user activity via the PDS, I'm not sure).
Tangled owns the frontend, which everyone accesses through tangled.org. That's the web interface for both git features, and for CI. The frontend is an "AppView" which is difficult to self-host because it requires ingesting and aggregating a lot of network data. That's what assembles the network-wide activity feed you see on tangled.org, and that's where "Bobbin" comes in. But you _could_ access everything through a different AppView because your identity, data, and metadata are all owned by your PDS and knot.
The AppView concept is a point where Atmosphere differs from the Fediverse. In all my Fediverse experiences the service that I log into is the same service that runs the app frontend. With Atmosphere an AppView uses OAuth to authenticate you with your PDS. So I can log in to both Bluesky and Tangled with the same identity, compared to Fediverse where I need different Mastodon and Lemmy accounts to use both "apps". (Bluesky is also an AppView btw.) Instead of many federated frontend+backend instances, Atmosphere tends toward many federated, headless backends, with a small number of centralized frontends.
The PDS provides your DID which is your unique identifier in the atmosphere. It seems like the knot, in addition to hosting git repos and providing SSH access, does some PDS-like things. The knot provides DIDs for your repos, and holds metadata. But again, the metadata in the knot applies to the repo - metadata that applies to you as a person lives in your PDS.
I'm self-hosting a knot, and I'm planning to self-host a spindle. But for the moment I'm using a PDS provided by Bluesky.
Comment · 3 years ago
Oh, interesting! I'm not the most up-to-date on this, but I don't think I was all wrong about what I said. My understanding is that cars with CCS adapters currently cannot use Tesla chargers (except the Magic Dock ones), but Tesla now says they will change the signaling so that soon CCS cars will be able to use Tesla chargers with an adapter.
One of my sources is, https://www.cnet.com/home/tesla-superchargers-will-soon-work...
AFAICT "NACS" is a new thing as of November 2022. Maybe it's basically a renaming of Tesla's existing thing. But the shift to NACS includes important details around published specs and interoperability.
Comment · 3 years ago
Tesla's charger was proprietary so other manufacturers couldn't use it. Meanwhile CCS is an open standard that anyone can use.
What's changed is that last year Tesla decided to publish an open standard. Now that other manufacturers can use the plug, they gave agreed to use Tesla's physical plug design, but with the CCS signaling protocol.
So NACS going forward is more of a new hybrid of the two rather than a switch to Tesla's existing charger. One of the outcomes is that cars equipped with CCS will be able to use NACS with a simple adapter.
Why not use Tesla's signaling protocol? I don't know the details. Maybe Tesla isn't ready or able to create an open standard for that part. Or maybe other manufacturers want to keep the signalling they have to keep adapters simple. In any case only one vehicle and charging station manufacturer (Tesla) will have to make updates on the software side, and to people who don't know the difference between the plug and the software it'll look like Tesla won the charger war.
Comment · 3 years ago
Just in case you're not aware, Soros conspiracy theories are a dog whistle for the less-publicly-acceptable "jews control the world" conspiracy theory. Of course it's not racist to criticize a specific person for specific actions. But that's not what the vast conspiracy theories around Soros are. Whether or not you are acting in good faith, you are repeating antisemitism (maybe unknowingly) when you bring this stuff up.
Comment · 3 years ago
As someone who is not listening in on the flake stabilization process, and who just wants to use Nix my thinking is, what's the alternative? To me it looks like people can either build on the feature that exists now, or put plans on hold for who knows how long while getting by with some lesser solution, passing up public enthusiasm that could be directed to growing the Nix ecosystem in the meantime.
I'm getting the hint that some people aren't happy with the current state of flakes. But right now it's the best solution for a certain large class of problems so it's what people are going to go with. Again, as a relative outsider I see flakes as The Way Nix Works with the requirement of enabling experimental features just being a part of the Nix process. Nix is rapidly growing in popularity with a lot of people drawing the same conclusion as me. Maybe there is a better alternative to flakes in the horizon, and when it's ready I'll consider switching. But I'm not going to wait to use Nix in the meantime, and for me the best way to use Nix currently is flakes.
Comment · 8 years ago
On the positive side hooks provide a lot of options for declarative abstractions. I expect that to a large extent the built-in hooks will be used as building blocks for new libraries. I think it is likely that this will outweigh the negatives.
On the other hand, hooks rely on hidden side effects so that each hook invocation returns something different depending on which component instance in the component tree is being rendered when the hook is called, and the number of times the hook has already been called while rendering that instance. This introduces semantics that are unlike anything I know of in the language. A redditor, u/hardwaregeek, pointed out that hooks behave kinda like a state monad, albeit emulated with imperative side-effects.
Comment · 8 years ago
Thank you for these points! I think that parallel execution is especially appealing. I edited the article to mention that.
Comment · 8 years ago
I'm happy to see this kind of detailed criticism. I would be happy to use a new tool if it is similarly general, and has a declarative style. Other commenters brought up Bazel, which I am looking forward to learning about.
Comment · 8 years ago
I have been meaning to spend some time with redo!
Comment · 8 years ago
Good point - cross platform issues are a concern. I've noticed in the past that OS X machines tend to run older versions of Make (unless the owner has installed a newer version with Homebrew). It is a good idea to pay attention to the Make features that you use, understand which features were added in recent versions, and be aware of which features are specific to GNU Make. In my projects I recommend that users make sure that they are in fact using GNU Make.
Some systems might not support the `-p` flag in `mkdir -p`, or the `-rf` flags in `rm -rf`. There are scripts distributed on NPM called `mkdirp` and `rimraf` to work around such issues.
Comment · 8 years ago
Noted! I wanted to provide concrete examples, and I did not want the post to become too long. So I focused on one kind of project.
Comment · 9 years ago
I know that "Go vs Rust" has been written about before. The perspective I wanted to take with this post was to examine specific ways I think Go could be improved.
[ my public key: https://keybase.io/hallettj; my proof: https://keybase.io/hallettj/sigs/idxnXm_V2fCQqybSF_0W3XA1sfa1JirYBFMaOiJotrg ]