[-] hunger@programming.dev 2 points 7 months ago

My coworker used it till his HDD broke, taking his key into data heaven. The repository is still online thanks to radicale, but he has no way to ever get push access to it again.

So it is useless as any misstep can potentially kill your access to the repo.

[-] hunger@programming.dev 1 points 8 months ago

Yes, I should not have said "impossible": nothing is ever impossible to breach. All you can donis to make a breach more expensive to accomplish.

Those separate tpm chips are getting rare... most of the time they are build into the CPU (or firmware) nowadays. That makes sniffing harder, but probably opens other attack vectors.

Anyway: Using a TPM chip makes it more expensive to extract your keys than not using such a chip. So yoj win by using one.

[-] hunger@programming.dev 1 points 8 months ago

"They" did not go anywhere yet. This is a proposal, nothing more. It will take serious discussions over years to get this into C++.

Prominent figures already said they prefer safety profiles as a less intrusive and more C++ approach at conferences It will be fun to watch this and the other safety proposals going forward.

[-] hunger@programming.dev 1 points 8 months ago

Well, its a brand new standard library. A fresh start.

[-] hunger@programming.dev 2 points 1 year ago* (last edited 1 year ago)

It's just a git repo, so it does not replace a forge. A forge provides a lot of services around the repo and makes the project discoverable for potential users. None of that is covered by this thing.

I frankly see little value wrapping a decentralized version control system into layers of cryptography that hides where the data is actually stored (and how long it is going to be stored). Just mirror the repo a couple of times and you have pretty good protection against the code going offline again and you are done. No cryptography needed, and you get a lot of extras, too.

If you do not like github: Use other forges. Self-host something, go to Codeberg or sourcehut, use something other than git like pijul or fossil, or whatever tickles your fancy. Unfortunately you will miss out on a lot of potential contributors and users there :-(

[-] hunger@programming.dev 2 points 1 year ago* (last edited 1 year ago)

Then how do you not see the point of a distributed sourceforge?

But this is no forge, it is just a git repo.

Again, have you even opened the webpage?

Yeap, I even put a repo into it. That's why I am so certain that it is useless.

Hosting a git repo is not a problem. Having an discoverable forge is. And this does not help with that in any way.

So github is not a problem?

Something can not be a solution independent of whether or not something else is another problem or not.

And regarding crypto, show me where in the code it forces you to use crypto. Show me the rad command that inhibits you from doing a normal git operation by bringing up crypto.

There is lots of needless crypto(graphy) going on all over the place. It is entirely useless for code hosting in a git repo.

[-] hunger@programming.dev 2 points 1 year ago* (last edited 1 year ago)

No, I would prefer a world where not everything is concentrated on github, but that is the world we have to work with:-)

But how does this address any of the problems you brought up?

Do you think a project will be more discoverable when you say: "Clone foo/bar from github" or when you say "install this strange crypto-BS, then clone rad:xyhdhsjsjshhhfuejthhh just like you normally would"?

Apart from discoverability you get a known workflow for contributors, a CI and a bug tracker. Coincidently those make it hard for projects to switch away from github... how does this address any of that? "Use this workflow, which is even wierder than any of the other github alternatives!" and "just set up a server yourself"?

Sorry, this is just yet another crypto-bro solution in search of a problem. Technically interesting, I'm give you that, but useless.

[-] hunger@programming.dev 1 points 2 years ago

I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.

Oh, most companies will pay someone to maintain an internal fork, but hardly any will contribute back. Sometimes that's due to lazyness, sometimes it is the idea that nobody will care for the company internal stuff, but most of the time it is outright forbidden to share internal IP even when that comes in the form of patches to open source code.

In my experience it is safe to just ignore that case and not care about corporate convenience when starting any open source project.

[-] hunger@programming.dev 1 points 2 years ago

Oh, the repository are easy to move.

The bug reports, PRs, wikis, CI/CD are stuck in github though. There is a huge lock in.

[-] hunger@programming.dev 1 points 2 years ago

Maybe the Mac uses full disk encryption? Clonezilla will clone everything incl. the empty areas as the entire drive contains data indistinguishable from random bits in that case. Encrypted data also does not compress.

[-] hunger@programming.dev 1 points 2 years ago

Check out the devuan mailing lists then:-)

[-] hunger@programming.dev 1 points 2 years ago

What is actually meassured there? "Line goes down" is not necessary a bad thing:-)

view more: ‹ prev next ›

hunger

joined 2 years ago