PyTCP VS freebsd-src

Corrected link

GitHub project page

I have recently included multiple improvements to the PyTCP project (TCP/IP stack written in Python). Please feel free to check it out if you are interested in Python network programming.

https://github.com/ccie18643/PyTCP

#networkengineer #ccie18643 #python #network #programming #tcpip #ipv6 #tcpipstack #linux

> For this reason, it's a good idea to encourage users to use /tmp for all files they need only a short while.

skulker is not in the old comp.unix.aix Usenet FAQ document, but given the number of times "That's what skulker does, and you should be running it daily." seems to have been the answer over the years, it probably should have been. (-:

To old hands, this is not a systemd novelty at all. The novelty, to old hands, is the idea of doing this not using a script. I remember the war stories from the 1990s and turn of the 21st century when users did things like include LF in the names of temporary files, and administrators suddenly learned the utility of find -print0 and xargs -0 or find -exec rm {} +. Stéphane Chazelas for one has had a lot to say on the subject over the years.

That said, mtree (from 1989) already existed at the point that systemd-tmpfiles was invented, and already had the idea of working from a specification file with names and owners and permissions and whatnot. It is surprising that no-one ever apparently tried mtree for completely wiping /tmp. The BSDs are using find to this day in the several places with they auto-delete stuff in /tmp including the daily periodic, although they did spot that their own find had a -delete option in 1999. (-: Hell, even I am still using find.

https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/pe...

> OpenBSD doesn't have to care about compatibility as much

FreeBSD did it in 2012 (for the 2014 release of 10.0?):

* https://github.com/freebsd/freebsd-src/commit/8f77be2b4ce5e3...

And has compat layers going back many releases:

* https://www.freshports.org/misc/compat4x/

* https://wiki.freebsd.org/BinaryCompatibility

So newly (re-)compiled programs can take advantage of newer features, but old binaries continue to work.

They might think that they don't need metaprograming, but like everyone else, they eventually do.

That's how we get monstrosities like https://github.com/freebsd/freebsd-src/blob/master/sys/sys/q... (plenty of Linux equivalents --- e.g. the tracepoint stuff)

Better to use a language with thoughtful metaprogramming than tack it on badly later.

Bootloader developers used to be particularly fond of Forth.

For many years, FreeBSD's 3rd-stage loader used FICL (Forth Inspired Command Language) for scripting [1]. It's still supported, although in the recent years it was deprecated in favor of Lua [2].

[1] https://github.com/freebsd/freebsd-src/tree/main/stand/forth

One of the problems with suspend/resume is simply: nobody is looking at it or trying to improve it. There is no progress because nobody has tried.

Until recently, rc scripts (think initd on Linux) had functionality that could be executed on system resume, but not on system suspend - like stopping a service on suspend. Why? Simply because nobody added that functionality for ages [0].

Similarly, drivers often have suspension but not resume capabilities (why?) which means they need to be added by someone who actually tries to use suspend/resume. [1] is an example of this (around midway through the section).

I recently took the time to get FreeBSD set up on my MacBook Pro from 2015, and it took quite a few kernel patches to get it working - many of which I don't think should have been missing already [2].

Webcam support is another issue; at the moment, webcamd is unmaintained because the developer passed away. Even then, it is just an emulator for Linux's USB subsystem and relies on some random person's GitHub for v4l2-loopback support using a branch called "my-build"[3].

Wifi is also an issue, with the best option for fast wifi support being the usage of a nano Alpine Linux VM, and using Linux's drivers [4]. If your wifi device is even supported, it's probably quite slow.

If all three of these things ever progress, I can see FreeBSD being more accepted by the masses. It is a great OS, but for personal computing, there are clear issues.

0: https://github.com/freebsd/freebsd-src/commit/2cf8ef5910fd37...

1: