Exploited? This is what the license is made for. You can take freebsd and do what you like - it’s free as in air, no strings attached other than the licence text.
You might not understand why the authors use MIT-like licensing
Insightful comment! This is what we need to build a good community!!
If you don’t like MIT/BSD licensing it’s fine with me, but to claim those that use it is stupid or exploited because of their choices. These are people far smarter than you and capable of making their own choices.
My understanding is that FreeBSD has no issues with Apple basing their OS on FreeBSD. But you guys probably know better
At work, I have to run a command in an AWS instance. In that particular instance only exists the root user. The command should not be executed with root privileges (it executes mpirun, which is not recommended to run as sudo or the machine might break), so I was wondering if there is a way to block or disable the sudo privileges while the command is running. As mentioned, the only user existing there is root, so I suppose "sudo -u" is not an option.
Linux privilege only understands user id’s and group id’s. These are mapped through /etc/passwd and /etc/groups. You will see in passwd that the root user has UID 0. Any account you create with UID 0 will have root privileges. So running the command specifying any user with UID!=0 will run without those privileges.
It’s also possible to set user on execution with setuid - but that won’t work on scripts only binary executables.
Laziness sparks innovation, and there could possibly be some other way to drop privileges. There’s loads of stuff I learn about Linux still - and my first install was summer 94
Read your other post and it seems to me that a rebuild of the system to accommodate non-root users would be my preferred solution. Trying to “work around“ issues like this are prone to break as the system is updated/changed. And you’re back to trying to figure out what’s changed and makes your script break.
In Norwegian they are called Klypedyr. Literal translation is pinching-animal (although we call it an insect). I always though that was scary as a kid, but I see now my trauma is tiny compared to ear-infesting-wig-wearing thingy. I still don’t like them, but I tolerate them
Like with most technology, init should be based on use-case.
Some setups are not made for quick reboots and that’s ok. When all your container does is run ddclient you might find that even cron can work just as well as systemd.timers
What solutions out there can package software in the native package format? I only found fpm (effing package management) and OBS (Open Build Service) so far....
The normal way I believe is to provide dpkg, and rpm to cover a few distros and to make sure your software is good enough for someone to pick up and maintain packages for other/their distros. ;)
The options you already mentioned seems a good fit - with OBS being a bit rpm centric.
deleted_by_author
As God is my witness, I didn't know earwigs could fly. (lemmy.world)
A distribution for the systemd haters around here. (sh.itjust.works)
Frig off (lemmy.ml)
How to package software for many distributions in their native package format?
What solutions out there can package software in the native package format? I only found fpm (effing package management) and OBS (Open Build Service) so far....