Heads-Up: Deprecation of mergemaster

Terry_Kennedy said:
And some developers dig through the PRs and other stuff that nobody really wants to look at, because it needs to be done. That last one is a thankless job, but may very well be the most important of the bunch
Click to expand...
I completely agree with that... shiny new stuff works best when you have a solid foundation underneath, and not a house of cards... Sometimes, nobody wants to look at the foundational stuff because nobody can understand it that well, and the only dev who does have a decent handle on the foundational stuff is no longer involved.
 
astyle said:
Sometimes, nobody wants to look at the foundational stuff because nobody can understand it that well, and the only dev who does have a decent handle on the foundational stuff is no longer involved.
Click to expand...
I'm reminded of my departed friend dmr's famous "You are not expected to understand this" comment in Sixth Edition. Similar arcane magic still lives in the lower levels of the code, I'm sure.

Side anecdote: The linked article by dmr also contains the explanation for the [in]famous "values of β will give rise to dom!" mv error message. dmr actually collected those sorts of "strange messages found on output devices" things. When I was doing the output driver for the Linotron 202 phototypesetter, lots of gibberish would come out because the software that ran on the "Naked Mini" that ran the 202 was buggy, and my code had all sorts of workarounds for "don't give this command because it will crash the 202" things. Despite all of that, the 202 would occasionally go b*tsh!t crazy (that's a technical term) and typeset gibberish on a whole film cassette. This would consist of random pieces of user commands, contents of the 202's memory, and whatever else was within reach. One day the 202 generated (in the middle of the gibberish) around 2 inches of leading, "font le oops", and another 2 inches of leading. "font" was was rendered in normal Times Roman, but "le oops" was one character from each of many different fonts, in a variety of font sizes, like a ransom note. I gave it to dmr for his collection.

Side anecdote to a side anecdote: I'm the person that came up with the 4-character hexadecimal display on top of the 202. On the original units, if the 202 hit an error it would display an error on 16 LEDs on a card in the processor chassis. But you had to open the door to look at the code, then convert the 16 LEDs to hex and look it up in the book. And of course, to open the door you had to remove the film cartridge - a total PITA. So I scavenged 4 of the HP 5082 hex decoder / display units and stuck them in a Radio Shack 270-285 project case, normally used for clocks. The whole thing sat on top of the 202, above the operator control panel. Since the LED signals weren't brought out anywhere useful like the backplane, I ran a white wire-wrap wire from each LED and a ground wire to a DB-25 connector that dangled from the front of the card. A regular round multi-conductor cable brought those signals up to the display. I was quite surprised to see a 202 some years later, after I'd left the typesetiing industry, with one of those boxes. But not built by me! Apparently someone thought it was a good idea and started selling them. I just did them for our in-house 202s.

We now return you to your regularly scheduled programming (discussion) :cool:

Edited to fix broken link
 
There is something with sendmail I don't know what. Historicly it's part of base, but when upgrading creates problems one should look to put it in ports. Where it belong according to my personal opinion.
 
Alain De Vos said:
There is something with sendmail I don't know what. Historicly it's part of base, but when upgrading creates problems one should look to put it in ports. Where it belong according to my personal opinion.
Click to expand...
It has been discussed for quite some time now. Moving things out of base has been going on for a while. One big example is BIND (which, IMHO, is another one of those "THAT could have gone better" things - the port didn't support chrooted BIND for quite a while after it got kicked out of base).

The issue is figuring out a lightweight replacement MTA/MUA that is acceptable to just about everybody. I think that is where it has hit snags in the past.

Having said all that, I can't remember a time I've had a problem with sendmail during an upgrade. But I do specify a site-specific configuration file in /etc/make.conf:
Code: 
SENDMAIL_MC=/usr/local/src/sendmail/freebsd-with-ciphers.mc
If you run into issues when upgrading, you should file a PR on it. After all, it is in base. :D
 
You don't need a replacement for sendmail in base. Let the installer give you a few package options , not in base, as MTU. That is according to me the way to go.
It means you break a historical link, but the world moves forward.
Sendmail is certainly not dead, but newer, better alternatives exist for smaller system, like the ones for a home PC or a desktop.

In run opensmtpd thanks to openbsd.
Here i post my configuration file,
Code: 
pki mail.ala cert "/etc/ssl/opensmtpd_public.pem"
pki mail.ala key  "/etc/ssl/opensmtpd_private.pem"
table aliases file:/etc/mail/aliases
listen on mail.ala
action "local" maildir "~/Maildir" alias <aliases>
action "relay" relay
match for local action "local"
match from local for any action "relay"
That's it. Nothing more.
There is more opensmtpd compiles in less then one minute.
This is 60*24 times faster then chromium-browser
 
Alain De Vos said:
You don't need a replacement for sendmail in base. Let the installer give you a few package options , not in base, as MTU. That is according to me the way to go.
It means you break a historical link, but the world moves forward.
Sendmail is certainly not dead, but newer, better alternatives exist for smaller system, like the ones for a home PC or a desktop.
Click to expand...
Well, this is something that could be handled by PkgBase. Which is hopefully something that won't introduce changes for the "always build world + kernel from source" users like me.
 
Alain De Vos said:
You don't need a replacement for sendmail in base. Let the installer give you a few package options , not in base, as MTU. That is according to me the way to go.
It means you break a historical link, but the world moves forward.
Sendmail is certainly not dead, but newer, better alternatives exist for smaller system, like the ones for a home PC or a desktop.

In run opensmtpd thanks to openbsd.
Here i post my configuration file,
Code: 
pki mail.ala cert "/etc/ssl/opensmtpd_public.pem"
pki mail.ala key  "/etc/ssl/opensmtpd_private.pem"
table aliases file:/etc/mail/aliases
listen on mail.ala
action "local" maildir "~/Maildir" alias <aliases>
action "relay" relay
match for local action "local"
match from local for any action "relay"
That's it. Nothing more.
There is more opensmtpd compiles in less then one minute.
This is 60*24 times faster then chromium-browser
Click to expand...
Sorry, but sendmail is different than SMTPd... I would know, I set both up on FreeBSD 6.0 for a small shop when I was fresh out of college. /bin/sendmail is the thing that sends and receives IP packets out on port 25. SMTPd is the service that tells sendmail to receive and send those packets. IMAPd is what sits between sendmail and a user's email client, be it Outlook, Thunderbird, or a web interface like gmail. I had to line everything up, and work out a way to switch things back if that didn't work. All that prep had to be complete before spending about half an hour flipping the switch.

Unfortunately, we're getting off topic...
 
grahamperrin said:
GhostBSD :cool: <https://github.com/ghostbsd/ghostbsd-ports/tree/main/os>
Click to expand...
The subdirectories of /usr/src are,
Code: 
bin/
cddl/
contrib/
crypto/
etc/
gnu/
include/
kerberos5/
lib/
libexec/
release/
rescue/
sbin/
secure/
share/
stand/
sys/
targets/
tests/
tools/
usr.bin/
usr.sbin/
According to me , with even my little C-language knowledge there is room for improvement.
But that is for the commiters. And i don't think they spend time on fora.
Maybe there is so much code people do not dare to touch.
And if you touch you convince other persons which is everything except simple.
 
Terry_Kennedy said:
I specifically checked the official master FreeBSD copy of the Handbook from: https://download.freebsd.org/ftp/doc/en/books/handbook/book.pdf (no hotlink title so the URL is visible in the post). Word search in Acrobat: etcupdate, 0 matches; mergemaster, 25 matches.
Click to expand...
I just re-checked that URL and it still has the old version of the Handbook. In fact, that seems to be the case for every format of every language of the Handbook. So I attempted to send the attached to freebsd-doc@, as recommended in the Handbook itself:
Code: 
  In https://tinyurl.com/45wtwnby (and surrounding replies) I noted that
the official PDF version of the FreeBSD Handbook from:
https://download.freebsd.org/ftp/doc/en/books/handbook/book.pdf
is the version from January 23, 2001. Of relevance to that particular
forum discussion, the PDF version of the Handbook still refers to using
mergemaster, while the HTML version of the Handbook uses etcupdate.

  Looking at other various languages (I checked DE, ES and FR) they all
have dates from late January. It appears that whatever system is used to 
re-generate the downloadable Handbook variants has been broken since
late January.

  In addition, while researching this I have discovered 2 other issues
which the Documentation Project might want to address:

  1) The tree that is apparently the "definitive version" of the Handbook
     at https://docs.freebsd.org/en/books/handbook/ does not include any
     date or version information other than a copyright date. That makes
     it impossible to tell what version is being viewed. I suggest that
     the same text that appears in the hardcopy edition, namely:

        FreeBSD Handbook
        Revision: 0d4371e5cc
        2021-01-18 18:33:37 +0100 by Fernando Apesteguma.

     (auto-updated as appropriate) appear in the online edition as well.

  2) Any downloadable / printable versions of the handbook should contain
     something like the following text:

        The FreeBSD Handbook is a living document. By definition, down-
        loaded or printed editions will soon be out-of-date. Please refer
        to https://docs.freebsd.org/en/books/handbook/ (for the online
        edition) or https://download.freebsd.org/ftp/doc/ (for download-
        able editions) to obtain the latest version.

        Thanks for your time,
        Terry Kennedy     http://www.glaver.org      New York, NY USA
However, since the migration of lists.freebsd.org from Mailman to Mlmmj, it seems to no longer be possible to send to mailing lists one isn't subscribed to. In the past it used to be possible to "throw a note over the wall" to a list one wasn't subscribed to, after manual moderator review. That no longer seems to be possible (probably an attempt to reduce spam, although I note that the most recent message in the freebsd-doc archive is spam from "Sponsored Ads").

So, if anyone posting here is a member of freebsd-doc@, feel free to pass this along.

In any event, these are things that someone with admin privileges on the web server needs to fix (the lack of updates to the downloadable versions) and that someone with doc commit privileges would need to do (my suggested changes to the online and downloadable versions). So all I can do is mention it here.
 
Just typed freebsd handbook into startpage, and got a link to https://download.freebsd.org/ftp/doc/handbook/book.pdf

Under abstract, it says,
Code: 
Welcome to FreeBSD! This handbook covers the installation and day to day use of FreeBSD 12.2-RELEASE, FreeBSD 12.1-RELEASE, and FreeBSD 11.4-RELEASE.
So, not quite up to date but better than 2001.

However, one of the main annoyances of the handbook is that if you search online, it's usually not dated. It's worse for 3rd party stuff which changes more, and now, there is the FreeBSD wiki, making it so that you don't always know whether to search the handbook or the wiki, and if you find both, which one is more current, etc.

I'd disagree with Alain De Vos about it all being thrown out. Just clearly date it, and note which version is being documented. Some people keep old versions and may still have use for old documentation. (Or have a cut off, e.g., throw out 9.x
when 13.x gets released, or something like that.) I still find old stuff from say, freebsddiary.org quite useful.
 
Yes backup old stuff, but only for archeological purposes.
And somehow prevent that it lists up in google searches. Only when you do explicit search.
E.g. zip it.
And move it from place so obsolete or forgotten links become dead links.
This reminds that relative links can be usefull instead of full path links.
 
Alain De Vos said:
Yes backup old stuff, but only for archeological purposes.
And somehow prevent that it lists up in google searches. Only when you do explicit search.
E.g. zip it.
And move it from place so obsolete or forgotten links become dead links.
This reminds that relative links can be usefull instead of full path links.
Click to expand...
Once Google picks it up, the algorithm will prioritize serving up a cached copy. That is because otherwise, you'd have to go through something like CloudFlare EVERY SINGLE TIME just to make sure the host with the document is still up, and serving that very document. Sorry, just the way Internet is designed... there's only so many trans-oceanic cables that can be laid and maintained.
 
scottro said:
… not quite up to date but better than 2001. …
Click to expand...

It's a 2021-01-18 edition (PDF property: 2021-01-24). The Abstract page refers to <https://cgit.freebsd.org/doc/commit/?id=0d4371e5cc>.

Subsequent editions to the corresponding page online: <https://cgit.freebsd.org/doc/log/documentation/content/en/books/handbook/_index.adoc>

From <https://docs-dev.freebsd.org/en/books/handbook/#preamble>:

… Some sections might be outdated. Those interested in helping to update and expand this document should send email to the FreeBSD documentation project mailing list.
… Previous versions can be obtained from …
Click to expand...
 
Alain De Vos said:
Yes backup old stuff, but only for archeological purposes.
And somehow prevent that it lists up in google searches. Only when you do explicit search.
E.g. zip it.
Click to expand...
Including the those directories in robots.txt to prevent them from being indexed by search engines (preferably without excluding the Internet Archive) might work.

Another idea is that when old versions are archived, either an additional page or a text overlay could be added that says that this is a historical version, with info on where to find the current version. Those are quite easy to accomplish for PDF files, but I'm not sure about other files. OTOH, if my suggestions here are followed, new versions will automatically have that info included going forward and will eventually be archived.

I don't think there's anything that can be done about individual files that are out-of-date being mirrored elsewhere. If the complete documentation tree is mirrored somewhere else, a polite note from the doc team to that webmaster might fix things. Of course, we have to get our own house in order first.
 
I followed the link at the top of this forum to read the instructions for upgrading from 11.4 to 13.0 in the handbook.

Under 15.6.4 I read:
"15.6.4.1. Updating the Operating System" which includes:
After updating the basejail, mergemaster(8) must be run to update each jail’s configuration files....
Click to expand...
Instructions follow on how to do that, and hit an error, leaving me perplexed how to complete the upgrade on my jails. It's only adding a line to 3 files in each jail, so far as I can see, but it's still unnecessarily complicated for the user to do that using vi.
 
You must log in or register to reply here.
Back
Top