hunger

hunger, 4 days ago

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.

hunger, 4 days ago

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 :-(

hunger, 11 days ago

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.

hunger, 16 days ago

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

hunger, 5 months ago

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.

hunger, 5 months ago

To be fair: snaps can work for all kinds of things all over the stack from the kernel to individual applications, while flatpak just does applications. Canonical is building a lot around those abilities to handle lower level things, so I guess it makes sense for them.

IMHO flatpak does the applications better and more reliably and those are what I personally care for, so I personally stay away from snaps.

hunger, 6 months ago

I am looking forward to follow up articles like “woodworking as a career isent right for me”, “bookkeeping as a career isent right for me” and the really enlightening “any job sucks when your boss is shit”.

hunger, 6 months ago

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.

hunger, 6 months ago

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.

hunger, 6 months ago

Systemd-networkd (not systemd the init system) defaulted to the google DNS servers when:

• the admin did not change the configuration
• the user did not configure anything
• the network did not announce anything
• the packagers had not changed it as they were asked to do
• the distribution actually decided to switch to networkd. Few have done somtomthis day.

That is indeed a serious issue worth bringing up decades later.

hunger, 7 months ago

Works for me on arch linux. No hickups or anything and I am using it since it was first announced.

hunger, 8 months ago

The problem is that you lose out on dev attention when moving away from github.

I moved my projects into github when placeholder projects literally containing a README with a link to the real repo only got way more interaction on github than in the real repository: More stars, more views, more issue reports and even more PRs (where the devs have obviously Cloned the repo from the actual repository but could not be arsed to push there as well).

If you want your project to be visible, it needs to be on github at this point in time:-(

hunger, 8 months ago

Watch out: That mindset is what got me into Rust in the first place!

I was so fed up with everybody drowning on about Rust that I thought I need to read up on it a bit so that I can argue against the hype. I am a seasoned C++ dev after all, I use a language that I picked because it allowed for robust and fast code. What could Rust add on top of that?

Well, I have a job working almost exclusively with rust now and do not plan to ever go back.

hunger, 8 months ago

SystemD replaced a variety of Linux init systems across different distros almost 10 years ago now but it is still resented by a significant and vocal section of the Linux community.

No, it is not. It is always the same few people that repeat the same slogans that failed to convince anyone ten years ago. But that does not really matter: In open source the system that can captures developer mind share wins. Systemd did, nothing else came even close.

hunger, 8 months ago

That comparison is bad on several levels:

First off, systemd-the-repo does contain way more than an init system. But yes, I am pretty sure systemd-the-init is slightly bigger than runit.

Secondly: Systemd-init does set up some useful linux kernel features for the processes it manages in an easy and consistent way. That’s why other services started to depend on systemd-the-init by the way: Systemd does linux-specific things developers find so useful that they prefer adding a dependency on systemd over not having the functionality.

Runit does not support any linux kernel specific features at all to stay portable to other unixes. Other alternative inits made the same design choice.

Thirdly: The overall attack surface of the system without systemd is bigger than a typical systemd system. That’s because so much code run by the init system is way more locked down as systemd provides easy ways to lock down services in a cross-distribution way. Note that the lockdown functionality is 100% linux kernel features, so it involves little code in the init itself. Users of other inits can of course add the same lockdown features as service-specific startup code into the init scripts. We saw how well that works across distributions with sysv-init…

Finally lots of security features implemented outside systemd-the-init require a systemd system as they need the lockdown features offered by the systemd-init. One example is systemd-logind: That depends on systemd-init to be secure where the pre-systemd attempts all failed to archive that goal. Logind makes sure only the user sitting at a screen/keyboard can actually interact with the device interfaces of the kernel device files managing that hardware, so no other user but you can see ehat you type and take screenshots of your screen. Contrast that to devuans approach: Add all users allowed to start the UI to a group and make the devices controllable by that group. Much simpler, KISS and the Unix way… but it also allowes all users on the system that ssh into the machine somebody sits on can log what other users can type. Apparently that is not a problem, since no system ever will have more than one user in the age of personal laptops and desktops. That seriously isvtheir answer… and they even rejected to maintain the ubuntu-before-systemd logind replacement when canonical asked them, because such functionality is not needed im Devuan.

hunger, 9 months ago

docs.rs/document-features/…/document_features/ helps to document features.

But yes, features are under-documented.

hunger, 9 months ago

Same reason as for all those years these old people are holding a grudge for…

It is not Unix philosophy (nothing is these days), it does not solve any problem they ever had (it does), it is no improvement over what we had before (it is) and even makes some broken and moronic things harder (it does), it is insecure (it improves overall system security), and it is one monolithic blob (it is not). Before systemd nothing depended on the init system (true, but then it did nothing useful that made having such a dependency worthwhile), and before systemd we were all free to use other init systems and distributions did not pick one for their users (they always did, offering additional inits only as unsupported iption just likenthey do now).

That’s the typical list you get.

Oh, and it was shoved down all our throats by the mighty Lennart himself, backed by several multi billion dollar companies that brided thousands of distribution developers to destroy Linux (it was not).

Funnily enough it is pretty much the same BS we had when that monster of complexity called sysv init was introduced into distributions, replacing a simple script with a forest of symlinks. Of course the community was much smaller then and so we had a loser number of idiots to shout at everybody else.

hunger, 9 months ago

How is that different to when every distribution shoved their implementation of sysv-init into your face? You were never free to choose your init, it always came from the distribution. You could (and still can) replace the init system, if you are willing to do the work involved.

That’s the whole point: Nobody is willing to do the work for one distribution, if they can just improve systemd and fix a whole bunch of distributions at once. That’s why developers flock to the systemd umbrella project to implement their ideas there, which is why systemd keeps getting cool be features for the plumbing layer of Linux – which is far more than just the init system.

hunger, 9 months ago

No need to drag that BS from the archives. It was never correct nor convincing.

hunger, 9 months ago

Where are those alternatives? I have not seen anything that is Baustoff convincing yet…

It is not a project owned by redhat… the lead guy not even works there anymore. So the more interesting question is: What happens if Microsoft closes down the project? The answer: It will be forked.