Why not remove old stuff.

Afterthought. When you change the root shell to something else then csh the answer is probably we think nothing much will be broken.
Would it not be a good idea to include another shell in the tests ? Then I am certain i can change it without breaking "something".
Or the question refrased otherwise, what would be the rational not to include another root shell in the tests ?
 
Or the question refrased otherwise, what would be the rational not to include another root shell in the tests ?
Simple:
> ll /bin/*sh*
-r-xr-xr-x 2 root wheel 419K Jan 14 13:50 /bin/csh
-r-xr-xr-x 1 root wheel 165K Jan 14 13:50 /bin/sh
-r-xr-xr-x 2 root wheel 419K Jan 14 13:50 /bin/tcsh


Anything else is a really bad idea. What if your /usr/ partition/disk/gizmo is inconsistent, broken, disconnected or otherwise damaged?
 
For this reason I keep /bin ; /usr/bin ; /usr/local/bin on the same partition. A full fsck of it just take a few seconds.
 
Or the question refrased otherwise, what would be the rational not to include another root shell in the tests ?
Wouldn't be trivial. Different shells have different syntax and semantics. A lot of the tests for the root shell would have to be to be rewritten. It would nearly double that part of the testing effort. Or given that FreeBSD is a volunteer-run effort, it would probably mean each test would get half the effort. That sounds like a bad idea. This kind of flexibility is just not needed (because a competent admin can work with either shell, and because for emergency operations any shell will do), and costs something.

For this reason I keep /bin ; /usr/bin ; /usr/local/bin on the same partition.
That's nice that it works for you. Matter-of-fact, I no longer separate /usr/local into a different partition (used to do that), but still separate /var and /var/log. I'm sure there are other people who do separate /usr/local from /usr, probably for good reasons (I can think of a few potential reasons right off the bat). So you can't rely on /usr/local being on the same file system as /usr, therefore basic operation of the system can't rely on anything in /usr/local.

The other reason you don't want root's shell to be in /usr/local is one of having a hermetically built basic environment. Everything in /usr/local is outside the control of the base install. It could come from a port/package, or it could come from random software installed from source, or it come from some local modification. For example, I have dozens (perhaps hundreds) of things in /usr/local/bin and /usr/local/sbin that are created from source that I've written. So for testing the base install, you can not trust anything in /usr/local, because you can't control where it is from.

Underlying this is a philosophical statement. FreeBSD is distributed as a base install, which is the thing that is most strictly tested, and that developers and testers have the most confidence in. Everything else is a port or a package or something else. This in particular includes the GUI, which is definitely not part of the base OS (and you can have different ones). Testing for packages, and therefore confidence, is obviously lighter than for the base OS. Fact of life.

Furthermore, in its file system hierarchy FreeBSD does not distinguish between ports/packages (which go into /usr/local), and everything else that's not base (which also goes into /usr/local). There are other ways that could be handled. For example, in my experience most Linux distributions I use put optional packages into /usr, not into /usr/local. Commercial operating systems sometimes use /usr/lpp (which stands for "licensed program product") for packages that you buy from the vendor. Other OSes (I think Solaris) likes to use /opt for optional but vendor-distributed software, and keeps /usr/local just for site-specific stuff. Many different ways to do it. FreeBSD has chosen one way, and there is many decades of experience behind it.
 
I think there's a general idea in software development that old=broken. I've just never found that to be true. If something works without issue is there so much that's changed it should be thrown out and replaced?

Keyboard and mouse haven't changed, we still use them just the same as we did decades ago. Now when talking embedded devices utilizing a touch screen interface that's not true, but for the vast majority of FreeBSD usage command line and gui are still utilized the same way they've always been. Utilities that worked fine then can still work fine now, no need to discard them just because they are old.

There may come a time where command line and gui become obsolete, maybe far into the future with new types of interfaces, but that's going to be a while. In that case old will be broken.
 
1. Why are we changing root's login shell?
Because it's more convenient. For interactive use, I used to be a (t)csh person, from about late 80s or early 90s, to early 2000s. Then I switched to using sh, first ksh, then bash. Why? Because shell scripts (things that are stored on disk and executed) pretty much have to be written in (k,ba)sh; csh is not a very good scripting language for programming. And I have the habit of executing rather long sequences of commands right from the command prompt, I frequently type in 10-line scripts and run them. Having two different shell dialects, one for programming and one for "interactive" use (which is often quite similar to programming) was driving me nuts. So I decided to standardize. I still use old-fashioned sh for programming only (keep it clean and portable), but use bash interactively, mostly because of the better history search features.

On my FreeBSD at home, I have two root accounts, one with the default csh, the other with bash. I de-facto only use the bash one. It actually has the same RC files as all my user accounts (on all machines, home and work, all architectures, I use exactly the same RC file, with if statements)

2. Why are we logging in as root at all?
Again, convenience. If I'm doing a system administration task that I know ahead of time will take only one line, I will do that with sudo. Otherwise, I switch to running as shell as root. Now, I hardly every actually "log in" as root, in the sense of starting a new ssh session or a physical terminal as root. Matter-of-fact, ssh access to root is disabled. Rarely I have to do sys admin tasks from the console (when the network is completely broken), and that's pretty much the only time I actually log in as root. Instead I just switch from my regular user account to root.

sudo <your favorite shell>
That works. I prefer "su -". Honestly, don't know why I prefer that, probably just tradition. After many years, it's sort of hard-wired into my fingers. Anyone know a strong reason to do one or the other?
 
Because it's more convenient. For interactive use, I used to be a (t)csh person, from about late 80s or early 90s, to early 2000s. Then I switched to using sh, first ksh, then bash. Why? Because shell scripts (things that are stored on disk and executed) pretty much have to be written in (k,ba)sh; csh is not a very good scripting language for programming. And I have the habit of executing rather long sequences of commands right from the command prompt, I frequently type in 10-line scripts and run them. Having two different shell dialects, one for programming and one for "interactive" use (which is often quite similar to programming) was driving me nuts. So I decided to standardize. I still use old-fashioned sh for programming only (keep it clean and portable), but use bash interactively, mostly because of the better history search features.

On my FreeBSD at home, I have two root accounts, one with the default csh, the other with bash. I de-facto only use the bash one. It actually has the same RC files as all my user accounts (on all machines, home and work, all architectures, I use exactly the same RC file, with if statements)


Again, convenience. If I'm doing a system administration task that I know ahead of time will take only one line, I will do that with sudo. Otherwise, I switch to running as shell as root. Now, I hardly every actually "log in" as root, in the sense of starting a new ssh session or a physical terminal as root. Matter-of-fact, ssh access to root is disabled. Rarely I have to do sys admin tasks from the console (when the network is completely broken), and that's pretty much the only time I actually log in as root. Instead I just switch from my regular user account to root.


That works. I prefer "su -". Honestly, don't know why I prefer that, probably just tradition. After many years, it's sort of hard-wired into my fingers. Anyone know a strong reason to do one or the other?
Thank you for your message.

I still don't know why you do use sudo.
It's been long time, I haven't used this command. I havent installed it.

Besides having old stuffs, means that it works fast ! It uses console and free software.
Using non free stuffs means that you'll loose time. ...

example: outdated ;)
6630
 
I think he said he actually uses su, and of course nobody allows root access to servers anyway. But yeah, I don't get the sudo thing either. Actually I find it irritating how people always write "sudo vi" all the time instead of using normal English and just tell us to edit the file. Oh well, whatever irritates me is of no consequence to anybody else - though I must admit that this is at least a small part of why I switched to FreeBSD. I just couldn't stand one more page with every single command starting with "sudo vi"
 
Afterthought. When you change the root shell to something else then csh the answer is probably we think nothing much will be broken.
Would it not be a good idea to include another shell in the tests ? Then I am certain i can change it without breaking "something".
Or the question refrased otherwise, what would be the rational not to include another root shell in the tests ?

The problem is if you change the root shell to something from ports and something happens with the package, like get removed or broken for some reason, you will not have shell access to root.
 
I think he said he actually uses su, and of course nobody allows root access to servers anyway. But yeah, I don't get the sudo thing either. Actually I find it irritating how people always write "sudo vi" all the time instead of using normal English and just tell us to edit the file. Oh well, whatever irritates me is of no consequence to anybody else - though I must admit that this is at least a small part of why I switched to FreeBSD. I just couldn't stand one more page with every single command starting with "sudo vi"

This modern sudo is kinda awful... it is also quite dangerous

Code:
 sudo rm -rf /

that's why old BSD stuffs, are good.
 
Anyone know a strong reason to do one or the other?

I'm sure you know this, but as a reminder to others: the key difference is that su requires knowing the password for the user you want to switch to (e.g. root password), while sudo relies instead on a config file for deciding whether you are allowed to log in as someone, requiring only retyping your own password to use it. It's not difficult to see which approach makes it more annoying to revoke root access or invalidate passwords in a multi-user system.
 
Sendmail might be removed in FreeBSD 13.
At least it's a goal of the DevSummit 2018.

That might make sense. There was a time when it was mandatory for a multiuser system to have a functioning and connective mailer. That's no longer the case.
Furthermore, the installworld routine does a few strange things concerning /etc/mail, which need to be cared for in automatic deployment, and which, from my impression, just don't belong there.

This is more intellegible than the removal of named, which imo does belong to a functional system (and is needed much earlier than the mailer).
 
This is more intellegible than the removal of named, which imo does belong to a functional system (and is needed much earlier than the mailer).

I'm going to make a broad assumption that the sendmail removal will be accompanied by the addition of another default MTA. For better, for worse. On the other hand, there's absolutely no need for a system to have named or any other daemon of the sort on it unless that server is going to be a name server.
 
Back
Top