Archaic software in FreeBSD base

[ldgc]

Hello

I searched about this and some results were: ATM, IPFILTER,
NIS and SENDMAIL.

I would love your share of knowledge on this

 

[ralphbsz]

• Don't know what you mean by ATM.
• Ipfilter is relatively recent, I think from the late 90s or early 2000s.
• NIS itself is fairly old (it used to be called YP or yellow pages), and it came out of Sun in the mid-80s. The second version (which changed the name to NIS, to avoid a trademark conflict with the people who made yellow pages, the phone books) is from the mid-90s, and was probably a complete rewrite. I don't know where the current FreeBSD NIS implementation comes from, and whether it still contains Sun's code from the mid-90s.
• Sendmail is seriously old. Eric wrote it for some of the first Berkeley Unix versions (which started at the CSRG in 1977), at the same time that Kirk was working on the BSD kernel. And there is a continuous line of development there, so the shipping version today probably contains source code from the late 70s or the early 80s.

That brings up an interesting question: What is the oldest code that is still in shipping FreeBSD (say in the base) today? My hunch would be that's in the kernel, and is from the early days of the Berkeley CSRG, which would date it at about 1977 or shortly after, roughly 40 years old. Other Unixes are older, and go back to the work that Dennis and Ken did in the early 1970s. Legally, there can't be any Bell Labs / AT&T code in *BSD any longer: the USL lawsuit ended in 1994 or 1995, and at that point all AT&T-licensed source code had already been removed from the Berkeley distributions (somewhere between Tahoe and 4.4-Lite). So today's *BSD probably contains code that is about 40 years old, while the still AT&T-licensed commercial distributions (I think only AIX and HP-UX remain today) may contain code that is about 45 years old.

The other fun thing is: While the oldest code in *BSD is pretty old, you can still meet the folks (Eric and Kirk) who wrote it. One runs into them regularly at Usenix events.

But 40-45 years is nothing. IBM's zOS (the mainframe operating system) is still somewhat compatible with DOS, the operating system for the first 360 machines, from the early 1960s (which has nothing to do with MS-DOS and Intel machines, which came decades later). There are stories that some commercial customers continue running compiled programs that are 20 or 30 years old, and for which the source code has been lost, so they need to continue using the same object code. And some of you may remember the uproar when IBM removed 1401 compatibility: Until the early 2000s, the mainframes were still capable of executing 1401 programs (from the late 1950s!), and people actually did complain when that feature was removed: they insisted on running 60-year old code. To my knowledge, that was the oldest example of retro-computing still on commercial production systems.

 

[sidetone]

Many FreeBSD users have suggested dropping sendmail and ipfilter, then putting them in ports.

Sendmail doesn't have a complete replacement with a license compatible with FreeBSD's base. There are, however, two partial substitutes: mail/dma from DragonFlyBSD, and mail/opensmtpd from OpenBSD. It is reasonable to simply use dma, because not everyone needs a full email server, and those who do can choose one from ports. Opensmtpd is as its name suggests, email on the smtpd protocol.

As for ipfilter, they've said a reason a few times. but that reason is becoming more irrelevant IMO

 

[balanga]

It would be interesting to know how much IBM has earned from IEFBR14 over scores of years from 1000's of customers

 

[ralphbsz]

About as much as the various Unixes have earned from selling true() and false(): Meaning zero. People don't buy an operating system to run a tiny utility; they buy operating systems (and spend LOTS of money on those, RedHat is a significant company) to get work done. On the other hand, IEFBR14 has caused support costs to IBM: There is the (very funny) story of that tiny program actually having a bug (namely that the return code wasn't always cleared), which needed to be fixed. Selling tiny utilities seems to be a sure-fire way to lose money.

This is part of a set of two jokes about software quality I like to make. First one: Only IBM is incompetent enough to have a bug in a program that is only a single instruction long. Second one: Only Digital Equipment is incompetent enough to have so many bugs in a piece of cardboard that they need to re-release it at least twice. Somewhere in my collection of artifacts in the dungeon is a small cardboard box, made by Digital (in the 1980s), which has printed on it "Revision B-2"

For fun, I just looked it up: While IEFBR14 is actually tiny (I think the executable is a few bytes long, since it only contains two instructions, first clear R15, then branch to R14), the FreeBSD versions of true and false are both about 3.5 kilobytes. That's a lot of baggage to do nothing.

P.S. The jokes above are not meant as insults; I love Digital to death (unfortunately, it has died), and I spent many happy years working at IBM.

 

[ldgc]

Don't know what you mean by ATM.

ralphbsz, ATM is Asynchronous Transfer Mode

 

[balanga]

About as much as the various Unixes have earned from selling true() and false(): Meaning zero. People don't buy an operating system to run a tiny utility; they buy operating systems

Actually people don't buy operating systems from IBM to run on their mainframe, they lease them, and even programs like IEFBR14 have an annual rental cost.

 

[ralphbsz]

Actually people don't buy operating systems from IBM to run on their mainframe, they lease them, and even programs like IEFBR14 have an annual rental cost.

Sorry, but your statement is so abbreviated to be simply wrong. While it is true that enterprise-grade software (on mainframes, on large Unix machines, and on supercomputing clusters) is licensed: meaning "sold", although the actual cost of the license may be difficult to characterize, and may be indistinguishable from zero. There is no an annual rental cost, in particular not for basic utilities in an OS distribution: RedHat doesn't charge extra for "cp", and IBM doesn't charge extra for "IEHMOVE". Charging extra for IEFBR14 would be ridiculous, since any user can generate that program in 30 seconds (the source code is on the web, it's two lines in assembly). There is often an annual (or monthly/quarterly/5-year/...) support fee though. For the details, you need to talk to your friendly Sun/IBM/HP sales person.

 

[ralphbsz]

ralphbsz, ATM is Asynchronous Transfer Mode

Interesting. I bet there is still lots of ATM hardware out there (at least within the phone companies), so it makes sense that FreeBSD continues to have software for it.

 

[Oko]

Hello

I searched about this and some results were: ATM, IPFILTER,
NIS and SENDMAIL.

I would love your share of knowledge on this

Not familiar with ATM.

IPFilter was scheduled to be removed from the base but vetoed by Juniper networks one of the largest consumers of FreeBSD (JunoOS is customized 4.xxx IIRC)

Of course, one could use various directory services on FreeBSD but IIRC YP is the only one that can be accessed directly using standard C-library functions like getpwent(), getgrent(), gethostbyname() and so on. What pisses me off is the fact that in order to use LDAP for example FreeBSD recommends Linux PAM in spite of the fact that OpenBSD's ypldapd (modeled after commercial UNIXes like HP) is available in the base.

SENDMAIL is there for political reasons. Namely the egos of old guard prevents them from enabling DragonFly DMA (which is in the base) by default of importing full flagged OpenBSD's OpenSMTPd mail server.

Note that FreeBSD is notorious not just for obsolete software in the base but semi-finished software (native sensoring framework, BSNMPD, syslogd), as well for not trimming obsolete software from ports (probably 35% of the ports should be removed as they are obsoleted/abandonware by upstream).

 

[sidetone]

IPFilter was scheduled to be removed from the base but vetoed by Juniper networks one of the largest consumers of FreeBSD (JunoOS is customized 4.xxx IIRC)

I sympathize with them, but nothing prevents them from installing it on FreeBSD without it in the base. I guess putting it in base gives them more name recognition, in return for what they provide.

There is no reason to have Sendmail in the base. I keep reading over the past 7 years, how it's insecure, and difficult to configure. That's like having a 1970's untuned rusty clunker on the road. I may get criticism for this, but It may be even better to have nothing in the base for mail than that.

 

[ralphbsz]

There is no reason to have Sendmail in the base. I keep reading over the past 7 years, how it's insecure, and difficult to configure. That's like having a 1970's untuned rusty clunker on the road. I may get criticism for this, but It may be even better to have nothing in the base for mail than that.

I have been configuring sendmail for about 20 years now, I think I started in the mid- to late-90s. It is a massive pain. It has been getting more painful with TLS/SSL. But it is still doable (if you are willing to invest a few quiet days into it). I quit using sendmail about 4 or 5 years ago though; for my home server, there simply wasn't a need any more, since nobody sends mail while logged into the server (everybody in the household now uses a laptop with a local e-mail client), and a super-simple MTA that just shoves all mail off-host is sufficient now.

But you have to consider the following: sendmail is still more powerful than any other MTA, and can be configured to do the most bizarre things. And for every bizarre thing, there is a person who happens to need just that bizarre thing for their unusual situation, and has invested a lot of work into making it work.

So the reason to keep sendmail is to protect the large investment people have into special configurations, and the accumulated knowledge of how to configure it. I agree that for 99% of all users, simpler MTAs are a much better solution.

 

[balanga]

Sorry, but your statement is so abbreviated to be simply wrong. While it is true that enterprise-grade software (on mainframes, on large Unix machines, and on supercomputing clusters) is licensed: meaning "sold", although the actual cost of the license may be difficult to characterize, and may be indistinguishable from zero. There is no an annual rental cost, in particular not for basic utilities in an OS distribution: RedHat doesn't charge extra for "cp", and IBM doesn't charge extra for "IEHMOVE". Charging extra for IEFBR14 would be ridiculous, since any user can generate that program in 30 seconds (the source code is on the web, it's two lines in assembly). There is often an annual (or monthly/quarterly/5-year/...) support fee though. For the details, you need to talk to your friendly Sun/IBM/HP sales person.

As I understood it ( I may well be wrong of course) your IBM licence agreement lists all the programs you are licensing and the cost of each of those programs, and I suspect that if you wrote your own IEFBR14 you would be in breach of your licence agreement. I've never seen an IBM license agreement for MVS so am just going by what someone told me.

 

[SirDice]

I searched about this and some results were: ATM, IPFILTER,NIS and SENDMAIL.

How about pretty much everything else in FreeBSD? The FreeBSD code is a direct descendant of the original AT&T UNIX code[*]. As such a lot of tools we still use today originated there. Commands like ifconfig(8) for example predate FreeBSD by about 10 years. Heck, even the whole TCP/IP stack predates FreeBSD.

HISTORY
     The ifconfig utility appeared in 4.2BSD.

And there's nothing archaic about ATM, technology like ADSL, VDSL, xDSL actually run on top of ATM in most cases. So it's still very much in use today.

[*] https://github.com/freebsd/freebsd/blob/master/share/misc/bsd-family-tree

 

[SirDice]

That brings up an interesting question: What is the oldest code that is still in shipping FreeBSD (say in the base) today? My hunch would be that's in the kernel, and is from the early days of the Berkeley CSRG, which would date it at about 1977 or shortly after, roughly 40 years old.

A lot of userland tools also originated there, not just the kernel. Nice example is sed(1):

HISTORY
     A sed command, written by L. E. McMahon, appeared in Version 7 AT&T UNIX.

Old bugs.
https://it.slashdot.org/story/08/05/11/1339228/the-25-year-old-bsd-bug
http://cvsweb.openbsd.org/cgi-bin/c....c?rev=1.18&content-type=text/x-cvsweb-markup

I'm sure there's code lingering around that's even older.

 

[mrclksr]

From the source code of indent(1):

/*
 * Copyright (c) 1985 Sun Microsystems, Inc.
 * Copyright (c) 1976 Board of Trustees of the University of Illinois.
 * Copyright (c) 1980, 1993
 *      The Regents of the University of California.  All rights reserved.

 

[sidetone]

I've wondered what Asynchronous Transfer Mode (ATM) was for, so a few answers helped me understand more.

So the reason to keep sendmail is to protect the large investment people have into special configurations, and the accumulated knowledge of how to configure it. I agree that for 99% of all users, simpler MTAs are a much better solution.

Sendmail is worth protecting then. However, there has to be a better way for them to secure that investment in FreeBSD, involving having it in ports. Aside from the security risks I hear about, it's not a big deal. I compile my base system anyway, and without it.

 

[MarcoB]

In the arch@ mailing list landed a proposal today for deprecating sendmail in base. FreeBSD 12 will be built WITHOUT_SENDMAIL by default, and sendmail will be removed in FreeBSD 13.

 

[sko]

Also a nice source for nostalgia (and IMHO a nice read) is roff(7):

HISTORY
The roff text processing system has a very long history, dating back to
the 1960s. The roff system itself is intimately connected to the Unix
operating system, but its roots go back to the earlier operating sys‐
tems CTSS and Multics.

A lot of ancient UNIX code, including the early 386 BSD variants, Bell Labs release and the various Research UNIX releases back to the PDP-7 version can be found in the UNIX history repo at github.
This repository also includes all FreeBSD releases, so it might be possible to use git blame to find out when some lines of code have been introduced.


As for sendmail: I'm using it primarily for local delivery or forwarding to the networks MX/relay nowadays - only because it is available on every system. I can't think of any sendmail instance directly facing the internet though.... Having configured two OpenSMTPD servers recently, I'd really love to see that landing in base. Configuration is absolute child's play compared to sendmail and yet it is still very powerful. But I agree that sendmail can be abused to do "very unusual things" to say the least, so it might still be used/useful for such weird configurations - although this might (should?) not justify keeping it in base for the 95% of users who would benefit from a more modern (and easier to grasp) MTA.

Regarding NIS: We're still using it here. In trusted networks this is still superior to much more complicated solutions that e.g. incorporate LDAP, kerberos or others depending on actual use case.

 

[ralphbsz]

"early 386 BSD variants" ??? I would use the term "early" for code written by Dennis and Ken. Bill and Lynne Jolitz are my age; Unix had been running for years when they were still in high school.

And that's the problem with using "git blame": The checkin history of whatever source code control system was used 40 years ago has probably not been transferred into git. Looking at github will probably not tell me when Eric Schmidt (!) fixed which bug in lex, nor how A, W and K partitioned the work on awk.

(Obvious name dropping: Bill and Lynne live nearby, and I occasionally see them walking near their house. Haven't talked to them in many years, and then only about local school politics, not about computers.)

 

[sko]

And that's the problem with using "git blame": The checkin history of whatever source code control system was used 40 years ago has probably not been transferred into git. Looking at github will probably not tell me when Eric Schmidt (!) fixed which bug in lex, nor how A, W and K partitioned the work on awk.

Of course it won't tell you the author unless this information has been reconstructed in the archive, but at least one could find out when some code was introduced.

 

[_martin]

RedHat doesn't charge extra for "cp", and IBM doesn't charge extra for "IEHMOVE".

HP-UX actually does this, at least something very similar. For example in its lowest operating environment (OE) - basic OE (BOE) - HP-UX doesn't allow lvols in LVM to have mirror copies. For that one has to buy higher OE that includes the product MirrorDisk/UX which allows you to do so.

But from user perspective there's only one lvextend command, one that has this functionality and one that doesn't.

 

[ralphbsz]

Absolutely. And when I was a HP-UX user, I noticed these things (but didn't have to care, since I was inside HP and had ways to get around all licensing roadblocks, having the kernel source on my machine made certain things easier). I know that the same happens in products of my other former employer (no need to discuss the details here): The inexpensive basic product has limited functionality; the expensive version then adds goodies which are more appropriate for larger users with more complex setups (and more money and more need for vendor assistance and product support). This makes sense and isn't nefarious at all: many customers don't need things like "asynchronous remote copy" in their OS, but some do. It's like cars: You can get inexpensive basic transportation for 4 people with a little luggage (a Honda Civic), and if you pay more, you can go very fast (Porsche), carry a large family or a youth soccer team (minivan), travel in great luxury for large distances (Mercedes), haul a ton of lumber or gravel (pickup truck).

What I was objecting to is the idea that a vendor would charge extra for basic parts of an OS, like IEFBR14 (or cp or /bin/true or IEHMOVE).

 

[_martin]

since I was inside HP and had ways to get around all licensing roadblocks, having the kernel source on my machine made certain things easier

Very nice! I got to see only very few bits of HP-UX code, during critical issues only. I'm inside HP too (well, was .. HP->HPE->DXC ) so licenses were not an issue (though billed to customers for sure).
I'm one of the fewer lucky ones who still do manage HP-UX, though amount of servers is decreasing every year.

I really don't like these kind of license limitations. Few others came to my mind; e.g. when HP shipped the board with all CPUs in the board but required to have a license to enable them (GiCAP) or when brocade required license to enable ports on switch (that are already there). Using car analogy -- it's like when you buy a car but you need special family license to open back doors, business license to open trunk, etc..

 

[ralphbsz]

Nobody likes these kinds of licenses. It's frustrating for a customer to know that all the hardware and software parts are there, but they aren't allowed to use them. It's also frustrating for the vendor staff to have to deal with that (and deal with the invariably upset customer).

But the same happens with cars. Example: In California, pickup trucks pay much higher car registration fees: the assumption is that they will be used to carry loads in the back, so they have a weight tax added to the car registration. It is possible to eliminate the weight tax by permanently installing a camper shell (also have to change the license plate), but then if you get caught without camper shell and with a load big trouble will happen. The next step is: it's possible to take a van or pickup truck and get it registered as a commercial vehicle (much higher registration fee), but that allows parking in commercial loading zones. I have friends who live in San Francisco, and others who have to often deliver big musical instruments downtown, and they are willing to pay extra for the convenience of being able to load and unload conveniently.

Getting back to computers: Those tiered different licenses unfortunately make sense. Because a customer who uses only the simplest possible configuration on a small system is also on average (not always, only typically) going to cause much lower support costs. Large customers with very complex systems tend to require much work from the vendor to install, configure, train, and support. For large installations (multi-million $ systems that pay hundreds of thousands of $ of software license fees per year) it is not unusual for the supplier to have to fly a person out to the site multiple times a year, sometimes whole teams, sometimes a person for many weeks. That is exactly the meaning of the word "support": the vendor will get the system to work and keep it working, even if that costs time and money; and that's why support contracts aren't free. There has to be a way to differentiate between customers that require very little help, and those that use lots of resources.

Extreme example: I know that one of my previous employers has a dedicated support team for one particular customer with several dozen people on it. And about 30 years ago, CERN (the bit european particle physics research lab) had a dedicated office and storage room for IBM field service people, which was staffed with 3-5 people during the daytime and one person at all times. They also had a dozen big mainframes, so those field service staff was kept busy.