In particular, learning why Debian has a system of marking some packages as "essential"; and learning why tools like aptitude, when told to resolve an intended change set up in the UI into specific package actions, will start doing that by switching off attempts to remove "essential" packages.
Note from the thread that there is an idea of marking packages as "vital", but it is not a concrete one yet.
# pkg delete -af
> What the same "pkg delete -af" command does on a PKGBASE FreeBSD system?
> It kills/destroys almost all of the FreeBSD Base System [...]
> POLA is the principle that made FreeBSD such predictable system. Where is the POLA now?
IMO if you convert the base system to be installed via packages and then force delete all packages, then the principle of least astonishment says that you'll delete most of the base system too.
rm having --preserve-root on by default is I think a simple mitigation that protects against the most common potential accidents than any of the above would protect from, and if something more than that is wanted then things like the immutable flag already exist and would cover far more than just rm.
While that case may be simple to catch the writers of gnu rm also recognize that scripts tend to not be well tested and decided "better than it currently is" is better than "we didn't do any mitigations to a common problem cause the solution wasn't perfect".
The fact that you can accidentally nuke the system seems a remnant from the olden days which we should have corrected a long time ago.
(I think GNU did a valid mitigation with preserve-root, just musing philosophically.)
There is nothing fundamental with rm for it to work like that.
> Being special to just / doesn't make sense to me.
and explaining why being special to / can make sense. I too often feel like people see comments like that and decide to let perfect get in the way of better in their own work.
I'm slightly disoriented, who's the other GP?
(I'm a GP.)
Obviously rm -rf / will only "destroy the operating system" if the user is root and we're in the root namespace. There is nothing stopping you from building a sandboxed OS that never gives your users real root (Android).
But what'd be the point of that? Users care about their data, not about their OS internals. If the OS blows, that's just an OS reinstall. But if a non-backed-up /home blows, that could be months of work. And any program that can delete a file in /home (as they need to be able to do to allow the user to do everyday work) can also delete all of them.
Yes, they do. Users definitely care about their system being able to properly boot and work correctly. It's unnaceptable how Linux distros make you use a live usb to go in and fix them instead of having a built in way to the OS for it to recover from bad things happening.
It doesn't. You must su to root to "achieve" that.
I could see that making sense. Maybe a "really important core OS" attribute? (I wouldn't want `rm /bin/sh` to run without forcing either.)
However,
> If a program can break the operating system that is a failure in the operating system's sandboxing or permissions.
Not necessarily. I have on multiple occasions logged into a machine, gotten a root shell, and then told it to wipe its own disks (either by block discard, or just dding over with /dev/null). That is a legitimate use that should work.
This can be done via a dedicated factory reset or wipe feature. It doesn't need to be the responsibility of rm.
A few years the POSIX folks declared that the behaviour of `rm -rf /` nuking the entire file system is a bug.
IIRC, one of the Sun Solaris folks (Cantrill? Gregg? Other?) thought the behaviour was dumb and argued successfully that it should not be work that way. Any implementation that does it is not POSIX-compliant.
Yes. PEBKAC bug. /s
Removal is forcibly requested.
The force means, remove more than what's normal. An abnormal removal.
I wrote:
"2414 intrigues me, however there's not enough for me to tell whether it's a pkg issue.
"I do know that the big picture includes things being suitably prioritised; for this reason, and others, I have felt no need to bump 2414.
"If additional info is required, they'll ask me in due course."
– <https://www.reddit.com/r/freebsd/comments/1mct33f/comment/n6...>
With regard to pkgbase,
> … Graham Perrin … not a finished mechanism. Very clearly not. (-:
My experience with pkgbase is clearly very different from your perspective. <https://lobste.rs/s/ikhfqq/pkgbase_removes_freebsd_base_syst...>:
"… I should describe the pkgbase caboodle as ninety-eight percent production-ready. The official packages for FreeBSD-RELEASE have always been _one hundred percent_ production quality. Very few aspects of pkgbase are experimental."
For the system the program "pkgs" ("s" for system) can write to /bin /sbin etc, and can only install/remove .pkgs (system packages)
For port's (can only write to /usr/local) pkg and
.pkgWith that we can have the same separation as we have now, for me that's a big plus on the BSD side of things. BTW Windows, Android and MACOS have some kind of that separation too.
pkg delete -af removes all "port" pkg's
pkgs delete (has no option -a but options like IDS from freebsd-update where every installable file IN the package (a *.pkgs) has a checksum instead just the pkg itself)
Drivers/Firmware will then have to move to pkgs, also we can have different groups for maintaining the system and port (root/wheel for pkgs and operator for pkg)
Also packaging error's in port packages cannot damage your system.
I remember in the 8x days, there was talk of moving parts or all of base installable via pkg. That server had a heat death and I have yet to replace it, so I have been out of the FreeBSD world for a while. At the time it was just being proposed.
I wonder if that has been completed or is this a first step to doing that ?
o11c•6mo ago
Notably it is explicitly marked as experimental; teething problems are to be expected.