Tobias Hunger

Github login does not help much… devs are on github, not on random forgjo instances. That’s where they see your project. Github is also where they put their fork of your project when they play with it. They will write comments using github markdown and won’t care whether that renders correctly or not in your forge.

And it is where they will report issues and open a PR. It is annoying, but it is how it is. When you ask them to open the PR elsewhere they complain sinde they need to set up an account there and copy ssh key and similar things. You need a very dedicated contributor to go through with all that… especially if it is just a few lines of drive-by fixes.

I never said that you can not run a project elsewhere, my point is that you will get way more interaction on github.

Try pushing your project to github and compare the interactions you get from both forges.

That unfortunately requires setting up email… I have not bothered doing so on my boxes in a very long time.

The biggest factor to me is developer attention. I had a project on gitlab and pushed a README.md with a link to the gitlab instance into github. I got about 10 times more reactions from github, incl. PRs (where the person had grabbed the code from gitlab and did a PR on github anyway) – even in this setup. Mirroring a project to github tilts that even further.

Not being present on github means a lot less users and contributors. As long as that stays this way there is no way around github.

I hope federated forges can move some attention away from github, making other forges more visible… but I am not too optimistic :-(

The blocking certain countries is a US legal thing. It effects any forge in the US and probably in more areas close to the US. As soon as a forge gets big enough to show up on the radar of government orge they will need to do similar blocking.

You can not really blame github for that part.

Rustfmt is not very configurable. That is a wonderful thing: People don’t waste time on discussing different formatting options and every bit of rust code looks pretty identical.

Why would they need to share ssh keys? Ssh will happily accept dozens of allowed keys.

When I last checked (and that is a long time ago!) it ran everywhere, but did only sandbox the application on ubuntu – while the website claimed cross distribution and secure.

That burned all the trust I had into snaps, I have not looked at them again. Flatpaks work great for me, there is no need to switch to a wannabe walled garden which may or may not work as advertised.

Why don’t you download the latest release/nightly from github and unpack it somewhere?

Ansible must examine the state of a system, detect that it is not in the desired state and then modify the current state to get it to the desired state. That is inheritently more complex than building a immutable system that is in the desired state by construction and can not get out of the desired state.

It’s fine as ,one as you use other people’s rules for ansible and just configure those, but it gets tricky fast when you start to write your own. Reliably discovering the state of a running system is surprisingly tricky.

That interface is let any random app take screenshots of anything running on the same server without any way for the user to know it happens.

I am so glad that interface is gone, especially when running proprietary apps.

Plugins are a code execution vulnerability by design;-) Especially with binary plugins you can call/access/inspect everything the program itself can. All UI toolkits make heavy use of plugins, so you can not avoid those with almost all UI applications.

There are non-UI applications with similar problems though.

Running anything with network access as root is an extra risk that effects UI and non-UI applications in the same way.

Usig anything as root is a security risk.

Using any UI application as root is a bigger risk. That’s because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.

So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.

Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.

Ideally you run the UI as a normal user and then use sudo to run individual commands as root.

The one thing you can learn from sysv init isnthat asking devs to pitncode into their programs or into starter scripts does not work. They will not bother: Those will notmworkmcross platform.

So you need to cebtralize that task. You can either write a wrapper program that sandboxes starts applications in a sandbox or do that whereever the programs as are started anyway.

A separate sandboxing app that starts services complicates configuration: You basically need to configure two things the starter and the service. On the up-side you have the sandboxing code separate. Merging the sandboxing into the program starting the service makes configuration simple but adds moremcode into the the starter program.

So it is basically a decision on what you value more. Systemd decided to favor simpler configuration. The cost for adding the sandboxing is small anyway: It’s all Linux kernel functionality that does need a bit of configuration to get rolling, with much of that code being in the systemd-init anyway: It uses similar functionality to actually separate the processes it starts from each other to avoid getting confused by programs restarted and thusnchanging PIDs – something still a thing in many other inits.

I am convinced that making sandboxing easy does a lot formits adoption. No admin will change the entire startup configuration to add a sandboxing wrapper around the actual service. It is way more likely for them to drop in a override file with a couple of lines and without any problems when upstream changes command line options.

It is the same as with all logins: It goes through the Pluggable Authentication Modules. So you need a service that uses PAM (they basically all do for a long time now) and the configuration of that service needs to include homed as an option to authenticate users. Check /etc/pam.d for the config files.

I use toolbox: Distrobox is a pretty horrible shell script and deleted parts of my home directory when I tried that.

In the end I just pointed toolbox to a script named podman that just adjusts the setup to what I need, implementing the missing features I wanted that way.

Censorship is about you being limited in the actions you can take to express yourself. It is not about cushioning you from the consequences of those actions from the people around you.

You obviously were allowed to take action: The contents was apparent upon on a forum and here as well. People reacted to your actions: Admins removed your contents and blocked you and I am telling you that your understanding of wayland as well as politics is limited.

Deal with it.

Small communities have a hard time staying up to date. X11 was ported decades ago, when non Linux OSes had more mind share and commercial backing. I doubt anyone could port X11 if that was the new thing mainly developed on Linux today.

Yes, wayland by design does not let random applications grab events intended for other applications nor does it let random applications take screenshots at any point in time showing other applications screens. This requires applications to do screen sharing differently, and it indeed breaks random applications sending events to random other applications. That is basically all you wail about and an absolutely necessary property of any sensible system and it is very embarrassing that it took so long to get this.

Removing dump stuff to keep a community relevant, on topic and with a good signal to noise ratio is not censorship. Claiming so is just dumb.