HaraldvonBlauzahn @ HaraldvonBlauzahn @feddit.org

Posts

30

Comments

139

Joined

3 mo. ago

Could somebody draw an advice flowchart - for a pinned post - which branches on the different common requirements?

On a more serious note... yes, nation-state attacks on infrastructure like xz-utils do exist, and as Stuxnet has shown, they are also being used against high-profile targets like Iranian nuclear faculities..

Such attacks against infrastructure are to be taken serious. But the xz-utils case and Stuxnet also have shown a few things:

• Such attacks are incredibly time-consuming and expensive to mount.
• Once sn attacker hits such a target, they have blown their powder - they can't continue to use it.
• The xz-utils case shows that open source's many-eyed principle works astoundingly well.
• xz-utils also confirms that in open source software, you can close a detected backdoor within hours - even if the maintainer of the software does not want that, since you can fork it in seconds. (And using Rust only makes this easier).

So, this topic of foreign state-actor backdoors is less a thing for individuals to worry about. (I agree that lawmakers of democratic states should absolutely worry about this, here a good article be Bert Hubert on the topic.)

However what is actually dangerous is the erosion of privacy and the rising amount of mandated surveillance. But if one is worried about that, one should not use closed-source software in the first place.

That's a very good and important point. Especially since reliable communication is really important in our case.

• There was some concerns about where it was being developed, I think it's entirely Chinese devs.

Ha, I am thinking since a while that for preventing one's internet access being hacked by a foreign power, it's probably best to chain an American-made router with a Chinese one so that they can firewall each other 😉

I was talking with my brother who was supporting our mother on her Windows laptop. He was using TeamViewer for years but that company now requires to subscribe to an expensive license on top of this is a really security- and privacy-sensitive kind of access.

His main requirements are that the new solution are:

• safe
• very easy to use for the supported person
• better works without VPN, public ports etc though this isn't mandatory.

So, it needs to be easy. I was first thinking in VNC but while I have been using TigerVNC for years in Home Office, this looks not exactly as easy as TeamViewer.

Last week was talking with our stand-in admin at work who turns out to know Linux well. He said he has very good experiences with RustDesk, uses it for home office and also for remotely accessing Windows machines.

What are your experiences?

In any complex system or "wicked problem" involving positive and negative feedback cycles, a combination of factors that push into the same direction can cause the system to flip over - sometimes in dramatic ways.

This one:

https://www.baldurbjarnason.com/2025/trusting-your-own-judgement-on-ai/

https://feddit.org/post/13930838

https://lemmy.world/post/31121462

I guess that someday, somebody will find out and report that in nontrivial projects involving more than one person, it does not help to go faster if documentation is skipped altogether. 😂

I don't think this would help:

https://thispersondoesnotexist.com/

Just one thought: jujutsu enhances on the cases where there are several people collaborating which do not only need to store, transfer, and distribute source code, but which also need to read and understand changes because they are working collaboratively on complex stuff. It makes it easier and much quicker to bring the change history into a logical and concise form. For some people/orgs, this improvement might not be relevant.

Literate programming tackles exactly that: You write the documentation in explanation order, and the code gets assembled in the order of a well-structured program. Have a look at the examples how this works.

You are probably thinking in this haha.

Just two nitpicks:

1. On the blog article

I gave the tutorial a quick look, but it didn't showcase any real benefits for my workflow. It confirmed my bias: this was for people who were afraid of Git's power, not for those who had already mastered it.

Well, it is the tutorial by Steve Klabnik, one of the co-authors of one of the two best and most comprehensive books on Rust. And as I anticipated because of that, it is a concise and lucid write-up and probably for everyone who enjoys good technical writing a refreshing read.

2. On jujutsu

I have been trying it both at home, and at work, for some months and it worked very well for me (for work I was using 'stealth mode', nobody was knowing I was using jujutsu).

It is in fact simpler and at the same time more powerful. The only area where I had hickups is pushing to a git repo:

• When the repo has more complex access modes, like ssh + vpn + git://..., it is better to use git directly. In new versions of jujutsu, this is built-in.
• When one works on several machines in parallel (my typical use case here is couch-testing something on my laptop after the day), the git repo does not contain the on-going jujutsu changes. This leads to either conflicted changes or one has to do regular git force pushes. When I think about it, it is possibly better to just rsync the jujutsu repo (jujutsu does support that because it version-controls the metadata, one however has to be careful not to create backup copies of git metadata).
• Also, jujutsu will readily change private history. As a counterbalance it has some configuration settings which protect public history from changing - the defaults are good but the settings still might be worth to have a look at.

Of course, Torvalds' essential rules on public and private history still apply. (see also this article by Jonathan Corbet on rebase/ merge flows which is, I think, really good advice for larger orgs).

For files that are large and not mergeable SVN works better and that is fine.

This. I have worked for a large research organization where a single SVN checkout took more than 24 hours. And they knew what they were doing.

BTW jujutsu, being created by an engineer who happens to work at Google, supports alternative backends which are meant for very large repos. But as said, I think that these do not align with the needs of the FOSS community.

Because I've worked in at least 3 companies who want to do this. Nobody had a good solution

There are good solutions: Use proper package managers with automated build support like dpkg, pacman, pip or perhaps uv, or even better Guix. Companies not doing that are just cutting corners here.

Only because it is bad at binary artefacts. There's no fundamental reason you shouldn't be able to put them in version control.

There is a fundamental reason: You can't merge them.

ed is the standard editor ;-)

• Storing large files. LFS is a shitty hack that barely works.

Well, git is for source control, not binary artefacts. There are indeed projects whose size is not a good match to git, but not everyone is Google or CERN.

• Integrating other repos. Git submodules are a buggy hack, and Git subtree is.. better... but still a hack that adds its own flaws.

What are your requirements? What do you need this for? And why do you think everyone else needs the same?

It's quite possible you are doing it wrong. What you want as a FOSS project are probably libraries which are build, versioned, and packaged separately. Perhaps using Debian packaging tools or Guix. Splitting it into real libraries with a concise API ensures that the API surface does not becomes too large, that the components stay relatively compact and maintainable, and that other parts of the FOSS community can re-use that library.

Companies - especially large companies - sometimes promote vendoring instead. But this promotes their interests, not those of the FOSS community on which creations they are building on.

Yes, git is designed to match the needs of the Open Source community! If you have a deeply intertwined multi-billion code base for a commercial product, a smartphone with closed firmware, or yet another TV , it might not be the best match. But who cares? Is the open source community obliged to meet such needs?

OS statcounter seems to get to similar numbers, with significant regional differences. Which data source would be more repräsentative and reliable ?