FreeBSD technology cemetery: states and stages of decomposition.

USerID

USerID

I can't keep up with everything... everything changes very quickly from version to version. I often, out of inertia, use technologies, commands, and methods that are already in various stages of decay and decomposition. Sometimes it happens that a particular configuration, program setting, or utility is no longer used and is headed straight to the crematorium.
For example, I read about /proc: Wikipedia says it's a dying technology, gradually dying and aiming to leave the FreeBSD world in the future. The /usr/local/sbin/ntpdate technology is also a zombie, as is CVS/CVSup, etc.
What resources/commands/technologies do you know that:
1. are completely dead in FreeBSD and in which version?
2. are not dead yet, but will soon be?
3. have died and been resurrected?
4. if they died, have these new alternatives taken their place?
The purpose of this thread is to collect all the dead bodies, zombie ghosts, and conduct an inventory of the FreeBSD cemetery.
Thank you.
 
As far as I understand, this is still alive in version 15:
Code: 
4.4BSD and derivatives
4.4BSD cloned its implementation of /proc from Plan 9.[citation needed]
As of February 2011, procfs is gradually becoming phased out in FreeBSD,
[3] and it has turned to use the sysctl interface instead for process-
related information. To provide binary compatibility with Linux user space
programs, the FreeBSD kernel also provides linprocfs that is similar to the
Linux procfs.[4] It was removed from OpenBSD in version 5.7, which was released
in May 2015, because it "always suffered from race conditions and is now
unused".[5] macOS did not implement procfs and user space programs have to
use the sysctl interface for retrieving process data.[2]
 
I don't understand the comment about ntpdate. Are you saying that syncing local time to a network clock is going away or are you saying the functionality of ntpdate to basically do an initial time set is going away or the fact that the functionality is available in base ntpd?

what if someone does not run or want to run the base ntpd because of "reasons". Openntpd is a viable alternative easier to use as a client (my opinion), use of ntpdate at boot time to do a quck set is still valid.
A small embedded system may not have strict time sync requirements so may run ntpdate with a designated server once every 5 minutes, once a day.
 
mer said:
I don't understand the comment about ntpdate. Are you saying that syncing local time to a network clock is going away or are you saying the functionality of ntpdate to basically do an initial time set is going away or the fact that the functionality is available in base ntpd?
Click to expand...
ntpdate(8)
DESCRIPTION
Note: The functionality of this program is now available in the ntpd(8)
program. See the -q command line option in the ntpd(8) page.
ntpd(8)
-q, --quit
Set the time and quit.
ntpd will not daemonize and will exit after the clock is first
synchronized. This behavior mimics that of the ntpdate program,
which will soon be replaced with a shell script.
Edit: rc.conf(5)
ntpd_flags (str) If ntpd_enable is set to "YES", these are the flags to pass to the ntpd(8) daemon. ntpd_sync_on_start (bool) If set to "YES", ntpd(8) is run with the -g flag, which syncs the system's clock on startup. See ntpd(8) for more information regarding the -g option. This is a preferred alternative to using ntpdate(8) or specifying the ntpdate_enable variable.
 
In general vision....

One thing is what you read,and some people say

Another thing is the reality

Judge and test things for yourself,is easy
 
USerID said:
The purpose of this thread is to collect all the dead bodies, zombie ghosts, and conduct an inventory of the FreeBSD cemetery.
Click to expand...

Well that is a very ambitious task as FreeBSD is 33 years old and a lot of stuff has been deprecated.
There were some major and some minor changes along the way.

Some stuff can be changed painlessly - remember we used bzip2 for packages and not lzma. But that migration is seamless.
Now we are changing binary freebsd-update and fixed system installation to pkgbase. It is a major change, not seamless.

For example, CVS/CVSup is an old story.
FreeBSD has historically used several version control systems and allowed end user usage (/usr/src) for all of them.
See here -> https://web.archive.org/web/20120224054241/https://wiki.freebsd.org/VCSWhy
 
CCD (the raid framework) also went away. Mostly replaced by GEOM modules, but not e.g. to read Linux md RAID.
 
Thanks Charlie_ I saw all that on the man pages, and figured that eventually ntpupdate winds up just being /bin/sh with "ntpd -q $1"

The second bits of the ntpd manpage about rc.conf, that's kind of what I was alluding to. Base ntpd is great it works as a client, but also default behavior is as timeserver. Yes one can muck with ntpd.conf and make it act only like a client and/or server to internal systems but that is not the default config.
Openntpd config is clean/trivial if all you want is a client.

The OP about "ntpdate technology is a zombie" implies something else to me.
 
ntpdate / ntpd -q is only good for stepping the time once at boot. a lot of people think they can replace "running ntpd" with "calling ntpdate once every 5 minutes" and they're wrong (the daemon does a lot of other work besides stepping the time)
 
there are cases, mostly embedded systems where sync at boot then periodically afterward (sometimes every 5 mins, sometimes 24hours) is acceptable. Why? For some systems accurate time sync to wall clock is irrelevant. But logging across multiple systems? Yeah you kind of need to all to be close to debug.

So time sync requirements need to be locked down early in a design phase.
 
that periodic stepping with ntpdate is contrary to the design of NTP and unix time synchronization in general; applications do not expect this, and ones that don't use a monotonic clock can get severely confused by it. just run ntpd pointed at the pool. otherwise you defeat the PLL compensation for the inherent crystal drift, and the multiple-server algorithm, and the long-running daemon will be more efficient with network traffic because it automatically lengthens the polling interval as necessary.
 
USerID said:
everything changes very quickly from version to version.
Click to expand...
Very quickly? That's a bit of an exaggeration, especially for such a relatively conservative project as FreeBSD. These things take years to change. When features are set as "deprecated", they are phased out through multiple major releases before being removed for good.

Personally I haven't used /proc in maybe 15 years.
ntpdate has been deprecated for many years since the ntpd daemon has practically the same functionality.

Think how long we had the pkg_* utilities before they were replaced with pkg.
Or how many years it took to implement pkgbase and it still won't be the default until 16.0 maybe? Considering freebsd-update was introduced like 20 years ago...
 
You must log in or register to reply here.
Back
Top