> In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates.
I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
> so that you can backtrack to which pubkey(s) was active at the moment
I think GitHub solves this by simply checking at the time of the push and then never again (which is why you can change the keys without de-verifying older commits. Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
> I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
There is different pieces that solve part of the problem (name/email from the git config, key servers for *some* users), but everything is disconnected, unstable, incomplete. Git-bug needs a stable identifier, the full self-certified pubkey log ... Those solutions are not good enough.
> Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
It's not specific to git, but yes you get a chain of data blocks, content-addressed with signature support. That's what you want to build on, to have identities, roles, rules to enforce in a p2p system.
> Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
Agree! Note that if git-bug bring a solid identity primitive and publish pubkeys ... it can also carry the pubkeys that are *already* used to sign commits, publish them in the same public registry and verify code commits transparently, without relying on a third party to do so. Imho that's something missing in the current git model: if there is identities, there are segregated in third party systems like github. DIDs brings a lot to the table.
It's a lot of different parts, the workflow itself is pretty straightforward. It is also all archlinux oriented because that's what I use everywhere. I'll try and clean it up over the weekend and make it available somehow. Where can I reach you once that's done?
> "What happens when requirements change inside the launch window?"
> "The alert fired but..."
In the running example I think it is clear that you could stop at any point and address the problem from that point rather than continuing. Questions such as "Why do we permit last minute changes at all?" are given no space.
In a complex system sometimes there is no root cause (cf. aviation crash investigations and the Swiss Cheese nature of risk). By allowing one person to shoulder the entire context of the incident and for that person be the one to suggest lasting corrective actions it leaves little need for the VP to even be involved. How would they know if the proposed corrections are worth the time and money to implement? I don't see any leadership in the example described in the article - I just see a knee-jerk reaction rather than any kind of proactive reflection.
> "I thought we fixed this last time!?"
> "This time was different in a way that our corrective actions didn't address."
I tried to make the GH Wiki work and managed to address 6 of the 7 concerns brought up in the article using a GH Action to mirror a directory of docs. It was my first GH Action and proved to be trickier than I thought. For those who just need to expose some markdown and don't want to bother with gh-pages you might find it useful:
The generic-ness of the wiki wasn't an issue for me as I only intended on using it as a temporary measure to build up the bulk of the content and coordinate with the main dev on finding a balance between the flashy website with its guides and the less flashy docs. gh-pages is the obvious next step of course.
I took the same approach. Every merge into main triggers the GH Action to sync /docs with the wiki.
The advantages of a wiki over /docs are tiny but the single click, navigation sidebar with all headings was enough for me to deal with the GH Actions hassle. GH Pages was no option because we are not on Enterprise and parts need to remain private.
Can you explain a bit more about the boundary between the environment and my system? Is it just giving read-only access to /usr/lib?
I use an alias to launch a Podman container with opencode in $PWD. It is fully ephemeral aside from the directories I map to it (usually a couple configs). XDG_HOME is local to that working dir. My only frustration is that my image is too minimal but that can be resolved.
* /usr is from your host, so you don't need to maintain a separate image to have programs that you already have installed.
* username, hostname, your current directory and home dir paths are preserved in the sandbox (within a Podman container a home dir is /root)
* environment variables are easy to carry into the sandbox.
* environments are explicit (`drop ls` lists them) and can be removed with `drop rm`, so you don't need to track in which dirs you have started Podman if you want to cleanup XDG_HOME files.
It is likely that your Podman wrapper also solves some of these or they are non-issues for your. If your setup works well, I wouldn't switch to something different.
I was unpleasantly surprised that those default mounts weren't just included in the base toml config like the ones from the home dir. What's the purpose of having two different kinds of "defaults"?
The problems begin with taking 5-10 minutes to locate a file on the network. That's right, when you ask for a file it takes 5-10 minutes. Also if the file isn't in the network at all then it never terminates.
Nobody noticed because everyone just used the central web gateway that cached every file anyone ever accessed.
> Distros are a bad use case for P2P anyway since you depend on upstream as soon as you start upgrading and installing packages.
This is true for any distribution method not just p2p. You can even download a nightly through torrents so what does it matter how the data is transferred if it’s always going to require `apt update`?
Yeah, I just use the "netinstaller" ISOs since it's much smaller and never needs to be updated. If I had a need for air-gapped/offline installs I'd either download a larger ISO or just manually install packages from .deb as needed.
You can trivially have storage deduplication for the files served via torrent, transparent to the protocol. The most trivial version of this that you can do today with pretty much any client is having a single directory containing files serving multiple overlapping torrents.
I don't see why it would be. It's transparent to other clients just like it is to the protocol. It cannot be more complex than alternatives by construction.
Yes, models are a good use for P2P especially if everyone agrees to share the same torrent and someone (or a cohort) commit to seeding for the long haul.
I have three identical Lenovo SFF PCs with a U.2 SSD in each. I'm currently running them in a Ceph cluster but I'll be tearing that down soon. I could run some benchmarks with three in one box and report back? Would be a one-time thing rather than an on-going commitment though.
Disregard, I just saw you have some RAID10 tests in there so three SSDs won't be enough.
I've been trying to find a solution for this too! I was considering using Rclone but too many things are using SQLite for me to trust rsync. I was also going to go with CoreOS but I'm leaning towards Fedora Cloud now in case I need to manage things a bit more (and "auto updating" is not something I want as that suggests auto rebooting).
Your secrets.yaml makes me nervous though - too easy to miss a key and leave something exposed. Why not just add the whole file to the vault?
I like CoreOS because of the fact that all config, etc files, sysctls are in one place.
Previously, I was using artix and had this “etc” directory[1] checked in to keep track of system configuration, but there was no good way to keep track of config drift (other than remembering to update this dir).
Haven’t gone through a CoreOS update yet (been using for ~2 months), but doubtful it would break anything. I’ve tested to make sure all my containers shutdown gracefully etc.
The SOPS (secrets.yaml) pattern is more common in NixOS configs, and I found it works nicely here too. In the artix setup, I had a bunch of .example files strewn around [2], which I had to remember to sync with the real versions.
Encrypting a key is just prefixing it with “enc_priv_”, SOPS will encrypt and decrypt it automatically. I keep “public” values plaintext to maybe help someone setting this up for themselves. Just have to double-check git diff before committing.
I have an old and loud 16-bay server that boots every 7 days or so if no one is home, `syncoid there here`, and shuts off. I'll get pinged by uptimerobot once in a while if it's overdue and I'll get a notification if a pool is unhealthy or reaching capacity (`sanoid --health` I think). Otherwise I forget I even have it set up.
Exactly! My offsite Backup box boots using a Shelly Plug S set on timer; it doesn't need to unlock the enrypted ZFS datasets because I use zfs sync snapshots in raw mode (-R). After the zfs scrupt, the box sends an email to me and shuts down. Next week: Repeat.
I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
> so that you can backtrack to which pubkey(s) was active at the moment
I think GitHub solves this by simply checking at the time of the push and then never again (which is why you can change the keys without de-verifying older commits. Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
---
https://web.plc.directory/ looks interesting, never heard of it.
Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
reply