14:03 / 16:50 The Rise of Unix. The Seeds of its Fall.

[lowen]

I do *nix both professionally and as a hobbyist, and an old K6-2 500 system ran the longest of any I had the pleasure to admin, with the 6GB WD Caviar drive spinning nearly continually from 1998 to 2018, 20 years, with a short break for a motherboard upgrade, from the dual PPro to the K6-2.

 

[Caluser2000]

I do *nix both professionally and as a hobbyist, and an old K6-2 500 system ran the longest of any I had the pleasure to admin, with the 6GB WD Caviar drive spinning continually from 1998 to 2018, 20 years.

WOW! That is damn impressive alright.

 

[Chuck(G)]

I did switch from Ubuntu some years back to Debian, mostly because I didn't enjoy living on the bleeding edge. There's a lot to be said for long-term stability.

 

[Zare]

Seeing systemd as "just an init" is not correct because it's much more. It also handles network.
Not only with systemd but with ip-tools, the basic part of the networking mgmt. has been completely replaced in last ~15 years to the point that none of the classic Unix or BSD commands work.

 

[Caluser2000]

Seeing systemd as "just an init" is not correct because it's much more. It also handles network.
Not only with systemd but with ip-tools, the basic part of the networking mgmt. has been completely replaced in last ~15 years to the point that none of the classic Unix or BSD commands work.

It just works on all my system old to new. So do all the init systems so I don't really care as long as a system works the way I want it to......

 

[Zare]

Of course it works, if it didn't work it wouldn't be in the system.
I'm speaking about commands like ifconfig and packages like systemd-networkd which replaced a number of stuff that BSD and Linux used to share in terms of networking. From some time ago, you need to know specific Linux networking commands like ip. The system got no new general network functionality, they just reshuffled responsibilities around components and replaced console management tools.

 

[Eudimorphodon]

Not only with systemd but with ip-tools, the basic part of the networking mgmt. has been completely replaced in last ~15 years to the point that none of the classic Unix or BSD commands work.

For a long time the ‘classic’ network commands stuck around as aliased implementations of the new system; it did pretty badly irk me when they stopped installing them by default and I’ll admit I *still* haven’t really fully internalized the new system, but… eh. Linux’s implementation of the old way was always “quirky” compared to BSD’s implementations, which themselves have always had flavor-specific quirks. Considering just how much the Linux kernel is capable of in terms of virtual interfaces/routing tables/bridging/etc it was probably well past time to throw the baby out with the bathwater. I don’t *love* the new system, but from a headspace perspective it‘s at least reasonably consistent and logical.

 

[lowen]

Seeing systemd as "just an init" is not correct because it's much more. It also handles network.
Not only with systemd but with ip-tools, the basic part of the networking mgmt. has been completely replaced in last ~15 years to the point that none of the classic Unix or BSD commands work.

Yeah, I'm pretty familiar with all of what systems does or tries to do; again, to my mind the exact mechanism by which the various daemons, including wpa-supplicant or other networking, gets started is pretty much immaterial. If the Unix wars taught me anything it was to be 'specific-command-agnostic' when it comes to admin tasks. Apollo Domain/OS took it a step farther with its triple- personality setup where you could run a system that used Aegis commands and configuration or 4.2BSD commands and configuration or SVR3 commands and configuration, selected by startup environment variables.

I have run Tandy Xenix, AT&T/Convergent SVR2, SunOS, Solaris, IRIX, Coherent, Apollo Domain/OS, and multiple iterations of Linux, from SLS on up. Change in the admin interface happens and is expected; I tend to just roll with it, get my work done, and go on. The Unix Rosetta Stone is helpful.

The Linux distro CLI differences are nothing compared to Cisco IOS CLI differences over the years and over the platforms; for instance, one IOS for one Catalyst switch wants show mac-address-table but another Catalyst switch wants show mac address-table. And then there are the cisco wannabes that come close but not quite to duplicating the syntax, like Dell's 8132s that turn the Cisco show cdp neighbor into show isdp neighbor, and requires a different privilege level to do it. But hey, that's what I get paid to do, so I don't let it bother me.

So, systemd doesn't bother me, it's just a different way to get the system startup done that meets needs that sysvinit, Upstart, and other init systems either don't meet or meet differently.

Does it sometimes feel like things change just for the sake of change? Of course it does; for that matter, it's felt that way ever since Red Hat migrated from a.out to ELF, or from sysvinit to Upstart, or libc5 to glibc, or Kernel 2.0 to 2.2; change is going to happen so I need to deal with it. But systemd does not do the same things sysvinit+inetd+ifconfig+etc do; it does do different things differently, and due to its widespread adoption is worth learning whether I like it or whether I don't. (And, no, I didn't particularly like it, but I've learned it).

 

[Chuck(G)]

It's perhaps worth noting that Debian doesn't install net-tools (e.g. ifconfig) by default any longer. You have to install it as a separate package. Maybe it's the thinking that "nobody uses CLI any more. " I don't know--I'm mostly locked into a CLI mindset myself.

 

[lowen]

Yeah, net-tools has been deprecated.....the intent to deprecate was announced pretty recently, in March of 2009, so not very long ago. The iproute tools are also relatively recent, being introduced in kernel 2.2 days.

Yes, I'm being facetious there; ifconfig going away has been a very long deprecation cycle due to the very core nature of the tool. I still find myself typing netstat when I want to see what processes are listening on what ports.....

But, really, the iproute tools are much more robust even if they are different, especially when non-static networking architecture is needed.

But if all you need is static networking, at least on Debian the same old /etc/network/interfaces text file is still there, and for a minimal cli-only install it's all you need. Still used by even the most recent Proxmox. Once you do a GUI NetworkManager will get pulled in, but the text mode nmtui is available to do network configuration.

 

[Eudimorphodon]

Yes, I'm being facetious there; ifconfig going away has been a very long deprecation cycle due to the very core nature of the tool. I still find myself typing netstat when I want to see what processes are listening on what ports.....

The thing that gets me every, single, time, is needing to do "ip neighbor" instead of "arp". Although netstat is probably a close second.

 

[Chuck(G)]

but the text mode nmtui is available to do network configuration.

Which is what I use, having only recently moved from /etc/network/interfaces text edit mode for configuration. Even though I have DHCP, my systems are all configured fro static IP, including explicit DNS selection. Call me hopelessly old-fashioned. On the various bits of kit, there's a sticker identify the system name and the IP address. Good old Dymo labelmaker stuff.
But heck, my text editor of choice is joe... Even for system installation, I'm leery of the GUI installers.

 

[Zare]

I like TUIs, I think arrows, tab, space and alt+shortcut are good enough to make menu driven anything and perfect for installers.

Funny thing about network on both BSD and Linux and many other Unices is that their modular monolithic kernel and design legacy really make it hard to run the network in Unix way, as a filesystem resource.
A hybrid or microkernel OS that runs userspace protocol stacks can expose ports as /dev(ices). Standard unix permissions apply - easily enable limited users to manage interface(s) for their desktop use without a middleware daemon. However our usual Unix runs the entire OSI stack in kernel thus the configuration is supposed to happen only by superuser.

In this case an admin could easily configure a system that has fixed network port and users can still change wireless networking or other ports. It would be a matter of just chowning that port to root and configuring it from init.

I've professional dealt with Intel DPDK a lot and it's a toolkit designed to remove the kernel from network I/O. The port driver in kernel is mapped to a region of memory that's accessible from userspace. While this is used for dataplanes that need zero-copy packet I/O and not for desktop users, it clearly shows both BSD and Linux stacks are not universally great, there are fringe cases where avoiding them is the way to go.

Having an option to run TCP/IP stacks in userspace, as who cares about memory today (I'm not joking), you could have flexibility in easily sandboxing and a ton of very valuable options like different IP per process.

P.S I think Plan9/Inferno were going in this direction.

 

[Zare]

Considering just how much the Linux kernel is capable of in terms of virtual interfaces/routing tables/bridging/etc it was probably well past time to throw the baby out with the bathwater. I don’t *love* the new system, but from a headspace perspective it‘s at least reasonably consistent and logical.

Yeah the new system isn't bad, it's just "new".
But FreeBSD is equally as capable in terms of kernel networking, if not more, and it relies on a few commands. All interfaces, physical or virtual are configured by ifconfig. And system configuration is performed by entering the same ifconfig line in rc.d.

The FreeBSD manual page for ifconfig starts with "ifconfig -- configure network interface parameters" and proceeds into a 38 A4 pages long help.

But this is FreeBSD vs Linux in a nutshell, cathedral vs bazaar.