Deprecating base system ftpd

If the OpenSSH upstream deprecates scp and our guys deprecate ftpd then I will be a little annoyed. I don't like http and I especially despise https.

I vote keep. It is tiny. If it really troubles them, rip it out from the rest of the system and keep it as a single binary that an unprivileged user can just run on a port above 1000 temporarily to transfer files.

Whats left?

cat somefile.txt | nc -l 1987
and
nc host1 1987 > somefile.txt

I know I would probably end up using that more than I want rather than install an additional port. ;)
 
I'm surprised something like that is still there. IMVHO, base should (well, simplified) contain anything absolutely necessary for a self-contained "Unix" system. But that doesn't mean to keep ancient stuff around. A means to access files on a remote machine definitely belongs into a Unix system, but even Unix changes over time, and ftp isn't what you normally use any more. Most people probably use scp or sftp instead, and both are present in base.

So, IMHO, yes, time to get rid of old cruft. Anyone who wants to operate an ftp service will find a matching port/package.
 
There is no reason to keep ftpd in the base system. You can install it from ports / packages without problems.

Basically, the long-time goal should be to remove everything from the base system that is not required for installing or booting FreeBSD. ftpd certainly isn’t.
Everything that can be a package should be one, IMHO.
 
Everything that can be a package should be one, IMHO.
I think that might be a bit too "radical". To give an example: I'd be pretty annoyed if cu(1) would vanish from base, although it would work perfectly as a package. The reason is, you need such a tool for administration of headless machines (well, short of a real-life serial terminal in hardware, I guess they are extinct, hehe).

So, my opinion is: keep "base" a self-contained, fully functional Unix system. It will always cause some debates whether tool x or tool y is required for that. As a rule of thumb, I'd say keep everything directly needed for administration and disaster recovery.

But, in general, I agree with "keep base small" :)
 
OpenSSH is not planning to remove the existing scp until they have a replacement; they're working on one that has the same command line format for common (simple) use cases.

Personally, I use scp a lot (but only in very simple fashions), rsync a lot (but usually also in a simple fashion, for whole directory trees with attributes). I never use ftp. Given that both ftp and the traditional scp are too easily abused (either intentionally or innocently), I'm in favor of removing them, as long as a simple and safe replacement is available.

As to Olli's opinion that nearly everything that's not vital to get booted should be in a package: For larger stuff, that makes a lot of sense. But there are a lot of small utilities that are highly useful, and that I don't want to go hunting for a package for. Zirias already suggested cu, and I agree. I would add both bc and dc, which I use regularly. And these utilities are so small (a single dozens of kB executable), it's not worth creating a separate package for each. Having several hundred commands in /usr/bin is not a big problem in my mind.
 
No SSH in base would be kind of a bummer.
Incidentally, I build mine with WITHOUT_OPENSSH=yes ;)

But I agree, nowadays, SSH is another perfect example for a functionality expected from a self-contained Unix system. My only reason is that I'm installing it from ports anyways. Perhaps, some time in the future, pkg-base will cover such "special needs". But nevertheless, it should stay in base.
 
No SSH in base would be kind of a bummer.
Don’t worry, ssh will stay in base (at least the client, but not necessarily the sshd daemon) because it may be required for certain ways of installing FreeBSD, e.g. to set up a tunnel for downloading the distribution sets and packages.

The same was once true for cu(1), by the way.
 
Most of my Freebsd machines are headless, many are remote. It would be a pain to have to install a port or package as part of the install.
I’m not sure I understand. What is the problem with adding packages during installation? I do that all the time, including on remote servers. It doesn’t matter if they’re headless or not.
 
I’m not sure I understand. What is the problem with adding packages during installation? I do that all the time, including on remote servers. It doesn’t matter if they’re headless or not.
I guess it wouldn't matter if whatever install media you used had some packages on it. I often don't enable public networking while installing because I want to vet my firewall rules first. Maybe I'm scarred by the bad old days when the mean time to compromise of a fresh install of Windows was minutes even on some (large) private networks.

Going along this path, which packages would you provide in the install media? Clearly not all of them, that would be too much, so some small subset of essential packages. But haven't you just redefined what "base" means?
 
I think the discussion about what belongs into base and what not will stay forever ;)

I personally think it's outright weird to still have sendmail in base, and it's somewhat questionable to have tcsh (cause, all that's needed is a POSIX shell, and for something comfortable for interactive use, you pick whatever you like from ports/packages).

But then, going the "radical" way and removing everything not strictly needed during installation has other drawbacks.

If pkg-base is finally there and enabled by default, the discussion might shift a bit, towards only "what makes sense to maintain in base". Let's see where this leads :)
 
Going along this path, which packages would you provide in the install media? Clearly not all of them, that would be too much, so some small subset of essential packages. But haven't you just redefined what "base" means?
Yes, that’s right – that’s what the pkg-base project is all about.

Actually the desire to “package the base system” is rather old. The current way of installing FreeBSD with so-called “distribution sets” is old-fashioned and has some disadvantages. It makes a lot of sense to convert it to the package format used by pkg, and make it more fine-grained. This will make the installation procedure simpler and more robust, and it will also make it easier to tailor it for your own needs, e.g. when you do scripted installs for a computing center or similar things. For example, if you don’t need tftp, then just drop the tftp package from the installation. There will probably be a “default base package set” that basically covers much of what is in the base system today.

Regarding installation media: Yes, SSH (both client and server) should certainly be available from standard installation media.
 
There will probably be a “default base package set” that basically covers much of what is in the base system today.
I personally don't like this "DIY Linux" approach. The base is there so that programs can be managed and maintained in a monolithic and unified way. Splitting it up achieves very little and just makes it a modular mess reducing consistency. I think it is a bad move. I don't believe it has worked particularly well with Xorg at all.

We will end up with a fairly useless initial install. Great for car set-top boxes probably but not UNIX-like and I am not sure it will even conform with POSIX / SUS etc.

But I do feel this is an approach that interests the developers and so will probably be taken. I strongly believe they would be wrong here though.

Of course providing installation .img/.iso with 40G+ of packages will solve this. A nice "modern" solution ;)
 
I think the discussion about what belongs into base and what not will stay forever ;)

I personally think it's outright weird to still have sendmail in base, and it's somewhat questionable to have tcsh (cause, all that's needed is a POSIX shell, and for something comfortable for interactive use, you pick whatever you like from ports/packages).

But then, going the "radical" way and removing everything not strictly needed during installation has other drawbacks.

If pkg-base is finally there and enabled by default, the discussion might shift a bit, towards only "what makes sense to maintain in base". Let's see where this leads :)
I think sendmail & tcsh are there for historical reasons. And freebsd does not like to give up it's history even if it's became obsolete.
If you have sendmail in base you can as well have postgresql in base :)
Personally I think any server does not belong in base, including time-server ntpd or dns-server local_unbound , mailserver sendmail.
 
I personally don't like this "DIY Linux" approach. The base is there so that programs can be managed and maintained in a monolithic and unified way. Splitting it up achieves very little and just makes it a modular mess reducing consistency. I think it is a bad move. I don't believe it has worked particularly well with Xorg at all.

We will end up with a fairly useless initial install. Great for car set-top boxes probably but not UNIX-like and I am not sure it will even conform with POSIX / SUS etc.
No, the initial install will not be much different by default. You will get the same things that you get today when you select “default install” in the installer.
 
Yes, that’s right – that’s what the pkg-base project is all about.

Actually the desire to “package the base system” is rather old. The current way of installing FreeBSD with so-called “distribution sets” is old-fashioned and has some disadvantages.
I personally really like the approach Openbsd takes, which is installation = unpack some tarballs. Super simple and not error-prone.
It makes a lot of sense to convert it to the package format used by pkg, and make it more fine-grained. This will make the installation procedure simpler and more robust...
I dunno. I believe Gentoo Linux pioneered this everything-is-a-package approach and their install was (is?) a hot mess. They still wound up with a package called "baselayout", BTW.
...and it will also make it easier to tailor it for your own needs, e.g. when you do scripted installs for a computing center or similar things. For example, if you don’t need tftp, then just drop the tftp package from the installation. There will probably be a “default base package set” that basically covers much of what is in the base system today.
Do you need this crutch if you're sophisticated enough to be doing scripted installs on a large fleet of machines? Also, I find that Mfsbsd suits these needs quite nicely.
 
Would be interesting to enumerate all the programs capable of network file transfer in base and figure out which ones are plain redundant...

Sendmail is in base to presumably provide some MTA.
 
No, the initial install will not be much different by default. You will get the same things that you get today when you select “default install” in the installer.
But for how long until people start pecking at things.

"Oh, I don't think users would find it shocking if ed was removed from the default install" (semi-quote from Debian mailing list)

"Oh, we don't really need two shells. Lets remove one"

"Do we really need a C/C++ compiler in base in 2021? Rust is so modern"

And it could also work the other way.

"Lets just tuck in a Python interpreter to the base meta-package. It is so convenient to have"

"Actually, lets just grab a Python 2.7 and 3.x package in the base meta-package to cover all angles"

I personally really like the approach Openbsd takes, which is installation = unpack some tarballs. Super simple and not error-prone.
I agree. I actually find it strange that so many other operating systems aren't seeing the elegance of that. I would also suggest that OpenBSD is the last remaining free operating system that is suitable for an entirely offline lab (No online-centric repo infrastructure, no 300+ packages just for a single package (Xorg). Site specific firmware clearly isolated, a responsible collection of default packages and servers like httpd, sshd).

It provides all of this and yet still ends up smaller than most Linux distros and FreeBSD oddly enough. This must be because they are less relaxed on optional extras being dragged in via packages.
 
Back
Top