121–130 of 180 posts
Unix has a long tradition of doing a `rm -rf /` before reinstalling a system. I don't agree with the people saying "don't do that". It worked safely before, it should still be safe to do. (yes I know about --no-preserve-root)
It certainly doesn't remove any file contents and to get a clean state, surely reformatting would be both easier and quicker?
Earlier quoted context omitted.
Is there some response besides the one linked here? Because all I see here is basically saying, "We're not going to change anything, this is not a problem, remount it yourself if you don't like it."
He says "The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root." That looks like agreement that it needs something done to me. I took the followup comment to be a useful to on how to mitigate the problem until then.
Earlier quoted context omitted.
Nobody is saying root shouldn't be able to access such functionality but rather it just shouldn't be mounted rw by default. This is actually fairly uncomplicated.
But then whatever app that runs as root that actually needs to update it is going to remount it rw, at which point the original problem stands. My personal opinion is that, for the use case of a single-user machine (i.e., "Linux on the desktop"), the traditional UNIX root isn't a useful concept. What's actually sensitive is your files, your saved passwords, your browser cookies, your emails, etc.; the ability to reco…
There's a difference between a system which, at all times, is one mistyped command from being bricked, and a system which allows you to brick it if you're explicitly doing something dangerous in the first place.
> let's take all the stuff that users should be able to do and make it accessible by nonroot, and take all the stuff they shouldn't be able to do and put it in the realm of automation
While theoretically reasonable, this is also a huge project, and while this project is slowly implemented users are still vulnerable to this bug. Additionally, there's always going to be Linux users who find the idea abhorrent, and thus it remains a bug for those users. Choosing to have more control should not generally mean that you can brick your machine so easily as accidentally deleting a few files.
Earlier quoted context omitted.
> Systemd hate is en vogue these days To be fair, Lennart Poettering could probably end war and famine forever in a single day, and some people would still find something wrong with that. On the other hand a certain amount of skepticism and criticism is very much in order. (I am saddened, though, by the way online discussions so easily deteriorate into name-calling and bitter ranting.) Just to be clear, I was highly…
On the other hand I was happy and welcoming of systemd then I started to experience way too many breakage due to attitude of the devs. When you have to spend 2 days to get to a remote server room and back because suddenly systemd decided that a device in fstab not present at boot would halt boot with error and at the same time the emergency shell was broken and going into a loop of asking for credentials, on a debian…
Apart from the two-item sample of personal experience I am kind of torn about systemd - some of the problems it attempts to address are real, and addressing these in general seems like a good idea. The way it does so, however, sometimes (I am being deliberately vague here) brings along some problems of its own.[1]
And the further systemd adoption and systemd's mission creep go along, the harder it becomes to backtrack and replace it in case somebody comes up with a better solution.
[1] Like I said, I have not experienced any of these problems myself, but I have read a couple of reports from people that had problems with systemd that were definitely not just aesthetic.
Earlier quoted context omitted.
So in a similar vein, why bother with alias rm='rm -i' at all?
Sane distributions don't include that alias by default. Because otherwise people will always use `rm -f` and lose the feature that `rm` asks before removing files marked as read-only.
So, the short read here is, one (arguably poorly thought out) complex system interacts with another (again, arguably poorly thought out) complex system in unthought about ways... Why is anyone surprised? I'm no fan of systemd or Poettering, but this behavior is consistent for unix, root can do anything, including break peripherals or hardware thru poorly advised actions - why is this a big to do?
see also: https://bbs.archlinux.org/viewtopic.php?id=207549 https://bbs.archlinux.org/viewtopic.php?id=208102
[1]: https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
Unix has a long tradition of doing a `rm -rf /` before reinstalling a system. I don't agree with the people saying "don't do that". It worked safely before, it should still be safe to do. (yes I know about --no-preserve-root)
What's that supposed to be good for? It certainly doesn't remove any file contents and to get a clean state, surely reformatting would be both easier and quicker?
Earlier quoted context omitted.
Linux is just source for a kernel that the userland for the various distributions are built on though. It's already largely on people's phones with Android. In fact, Chrome OS is based on Linux.
That appears to validate my belief that only Google can competitively take the Linux kernel and build atop it a software stack known as a desktop/mobile/user operating system. And if my assertion that intention prediction and voice search will be competitive features for users, features that rely on mass data collection and expensive top talent, then I think organizations like Canonical or RedHat will fall behind in…
Apple's no M$, but they are certainly competitive.
These threads are never productive. Running rm -rf / is going to offer multiple interesting ways to make your life miserable, eg: a mounted FUSE filesystem, an NFS folder pointed somewhere important, Samba mounts from your network automatically connected from your desktop, etc. I wouldn't be surprised if you could nuke firmware off a device by deleting the appropriate file in /sys/. Systemd hate is en vogue these day…
Earlier quoted context omitted.
What's that supposed to be good for? It certainly doesn't remove any file contents and to get a clean state, surely reformatting would be both easier and quicker?
Experimentation, learning, having fun, curiosity, and all the thing that make for a proficient sysadmin.