I’m attracted to purism. I need innovation plus an application to keep reading. I need something that’s thoroughly thought through to really like it. [..] For an example Pijul satisfies almost all. But git is kinda “good enough” (for me at least). The benefits don’t seem to really justify replacing a whole ecosystem of how we manage code. So there isn’t really an application for me to start using it. I’d definitely use it if others did, but I wouldn’t push it.
I followed the same train of thought and decided to go with Jujutsu (jj). Like pijul, it also has new, strong design ideas – but it is less radical. Unlike pijul, it is compatible with git repositories and forges, which means that it has a much easier path to adoption. (My application is “much better experience than git when rewriting histories in preparation for one or several github PRs”.)
Yes true! I have it in my backlog to take another look (didn’t get it last time i tried it, I didn’t realize I should change the workflow :)).
I wonder if the longterm goal of Jujutsu is to introduce an alternative backend which is more “native” to Jujutsu. In that case it would be taking “the long road” very similarly to Oils. Reimplement, then improve.
I have the feeling this is a currently very liked approach. E.g. coreutils is one other example (thought this is more about the language/development ergonomics than features/usage economics).
My coworker used to use radical. Then he switched computers and was not able to reconnect to his repo from there. So he went back to traditional hosters
It’s a great solution - provided all goes well and you do not loose your key or nothing bad happens.
The default shell on every major Unix, Linux, BDS and even MacOS hasn’t had a single meaningful new feature for over 25 years!
Good. GOOD.
I’m seriously considering trying Oils, but purely for the footgun-elimination aspect. Having a feature-complete, stable, default shell is most definitely a feature as far as I’m concerned.
Very underappreciated argument, thanks for bringing it up!
I think it’s a question of how much convenience (features) you’d want on a modern shell.
IMO the “feature-complete” POSIX Standard is not enough. And the Bash features make everything only confusing/are not really “complete”.
Simplex sounds interesting. Giving up on having any kind of identifier that a human can read remember and type makes for interesting UX challenges but if this can be handled by address book management it may provide a much better way of exchanging encryption keys.
I am interested in review of the crypto and privacy properties. There doesn’t seem to be anything on the IACR eprint server. Has nobody looked at this yet?
Not sure. The question is who is the attacker. If it’s state agency, then definitely not.
If a state agency is targeting you, you probably don’t stand a chance. But given how state leaders are shifting more and more to the fascist extremes (left and right…), complete citizen observation isn’t just a topic for china anymore.
So not wanting any data on the server is IMO a very valid concern, because that makes “observe everyone” much harder.
If only GitLab introduced seamless Pijul support! That is, make sure that both Pijul and Git clients can interact with repos in a sensible way. Then I could learn the ins and outs of Pijul with an easy fallback in case of catastrophic usability failure.
Yeah I guess as long as there is no open hosting solution the gate is kinda closed for wide adoption :/
tbh I haven’t looked into it’s ecosystem for a long time now. I wonder how pijul vs jujutsu would compare/if a pijul “backend” could be supported by jujutsu.
I followed the same train of thought and decided to go with Jujutsu (jj). Like pijul, it also has new, strong design ideas – but it is less radical. Unlike pijul, it is compatible with git repositories and forges, which means that it has a much easier path to adoption. (My application is “much better experience than git when rewriting histories in preparation for one or several github PRs”.)
Yes true! I have it in my backlog to take another look (didn’t get it last time i tried it, I didn’t realize I should change the workflow :)). I wonder if the longterm goal of Jujutsu is to introduce an alternative backend which is more “native” to Jujutsu. In that case it would be taking “the long road” very similarly to Oils. Reimplement, then improve.
I have the feeling this is a currently very liked approach. E.g. coreutils is one other example (thought this is more about the language/development ergonomics than features/usage economics).
jj already has it’s own background but from the beginning it has had git compatible storage as well as sync protocol.
I also bounced of half a year ago or so, but things have come a long way now and it’s really much better now and usable as a daily driver.
Yes, see our roadmap.
My coworker used to use radical. Then he switched computers and was not able to reconnect to his repo from there. So he went back to traditional hosters
It’s a great solution - provided all goes well and you do not loose your key or nothing bad happens.
seems like a great excuse to level up on key management practices! I agree that storing private keys as files on localhost is not great.
That or use a proper forge where admins can help you get back access:-)
Good. GOOD.
I’m seriously considering trying Oils, but purely for the footgun-elimination aspect. Having a feature-complete, stable, default shell is most definitely a feature as far as I’m concerned.
Very underappreciated argument, thanks for bringing it up! I think it’s a question of how much convenience (features) you’d want on a modern shell. IMO the “feature-complete” POSIX Standard is not enough. And the Bash features make everything only confusing/are not really “complete”.
Does Radicle do any kind of CI? I couldn’t find anything about that in their FAQ.
Uh good point. I know there was some dicussion in the zulip when I looked into it, but it seems like there’s currently only a poc.
Simplex sounds interesting. Giving up on having any kind of identifier that a human can read remember and type makes for interesting UX challenges but if this can be handled by address book management it may provide a much better way of exchanging encryption keys.
I am interested in review of the crypto and privacy properties. There doesn’t seem to be anything on the IACR eprint server. Has nobody looked at this yet?
There was a review by trail of bytes in 2024, if that’s what you mean: https://simplex.chat/blog/20241014-simplex-network-v6-1-security-review-better-calls-user-experience.html
SimpleX seems cool but:
Surely this is how almost every chat app is getting pwned though?
Not sure. The question is who is the attacker. If it’s state agency, then definitely not. If a state agency is targeting you, you probably don’t stand a chance. But given how state leaders are shifting more and more to the fascist extremes (left and right…), complete citizen observation isn’t just a topic for china anymore. So not wanting any data on the server is IMO a very valid concern, because that makes “observe everyone” much harder.
If only GitLab introduced seamless Pijul support! That is, make sure that both Pijul and Git clients can interact with repos in a sensible way. Then I could learn the ins and outs of Pijul with an easy fallback in case of catastrophic usability failure.
(I just learned that Nest (the Pijul hosting solution) is not yet source-available, which means self-hosting is not feasible for the foreseeable. 😢)
Yeah I guess as long as there is no open hosting solution the gate is kinda closed for wide adoption :/ tbh I haven’t looked into it’s ecosystem for a long time now. I wonder how pijul vs jujutsu would compare/if a pijul “backend” could be supported by jujutsu.