Notices by niconiconi (niconiconi@mk.absturztau.be), page 3

问：为何企业用户的网络流量不大，也要安装两条宽带？

答：就怕 WAN1 出问题了，全公司就彻底摆 LAN 了。

Since the last upgrade, now my QubesOS's Xen crashes once per hour. Can't do anything about it right now because I can't find that damn RS-232 null modem cable. :blobcatknife:

@chjara@akko.wtf syscall over UDP

@chjara@akko.wtf Unix processes may stall forever in Uninterruptible Sleep when using hard drives or NFS? You won't need to worry about unreliable hardware and network any longer, if you make all syscalls unreliable!

"W3.org used to have up to 130M (!) requests per day for HTML DTDs, probably mostly from poorly written spiders traversing all the links they managed to find":blobcatlul:

Of course it's not that simple, I missed at least one line of code. man osmtpd-run:char *username: The username with which the session was successfully authenticated. osmtpd_need needs to be initialized with OSMTPD_NEED_USERNAME. If not available or authentication failed is set to NULL.

Far from that simple! It didn't work because libopensmtpd is buggy. osmtpd_link_auth() should split the string "status|user", but the author thought it was "user|status", and it becomes a comparison between a username and pass/fail. :woozy_baa:

Just wrote a patch, untested. Is it really that simple?

OpenBSD's filter-dkimsign signs everything for a domain. If someone sends a mail and claims it's from root@example.com, a real RSA signature would be attached onto it. The official way is running the filter only on the Unix socket, not on TCP, but there will be no signature from users logged in from the Internet. Worse, smtpd's filter chain can theoretically stop it via rejecting "!auth", but mixing internal and external filters are not supported, so it doesn't work... Time to patch filter-dkimsign.

@puniko :pudding_cat:

nf_conntrack has several timeout setting, each for entries of different TCP states [...] default timeout for established state conntrack entries is 423000 s (5 days!). Possible reason for so large a value may be: TCP/IP specification allows established connection stays idle for infinite long time (but still alive)TIL :woozy_baa:

@puniko home network: German mode enabled.

"There is a router (specifically a Linksys WRT-54G) sitting between my computer and the other endpoint -- is there anything I should look for in the router settings?"
"Here's another: Comcast"LMAO :blobcatlul:

@raven667@hachyderm.io @lispi314@udongein.xyz @chris__martin@functional.cafe @dalias@hachyderm.io There's a difference between what's theoretically possible and what is the normalized practice. Sure, theoretically, for source-level compatibility, your POSIX-compliant C89 code from the year 2000 will still run in 2024 in theory. For binary compatibility, it has even been demoed it's NOT that bad at all on GNU/Linux, you can still run the original GIMP 1 binary, if everything's packaged carefully with the correct tricks.

It misses the point, which is the cultural preference that I was talking about, I don't even care about binary or source compatibility as they're simply technical means on an end. If you really want a "maintenance mode" project, you don't even need that - you can just write a self-contained C89 project with strict standard comformance and use a small sets of carefully selected stable dependencies (ncurses or Tcl/Tk will work until the end of time). As long as you treat it as a "finish" project, and don't keep adding features to it, the maintenance required is likely minimum, you probably only need to update it once a year with a small patch to keep it running.

But this is not what's going on. The reality of FOSS is that a project's devteam and goals will probably change several times over its lifetime, and the people, driven by technical challenges and the norm of expanding a project to fit your own need, will keep throwing dozens of extra features into the codebase, rewriting the business logic many times over, for for an increasing number of niche uses. Within some year it will be a completely different project, and another few years later there will be 3 competing forks, and 1 year later all will be obsolete as someone wrote something else.

Unless it's a low-level or niche tool, it will be extremely rare for the devs to declare that "The project is officially complete and is in maintenance mode, only security and fixes will be added after this point, all feature requests and patches will be rejected!" If someone does it, it will immediately seen as dead and be forked by the community. In this grand scheme of things, few care about compatibility.

The free software community culture expects a project to constantly in development, because people know they have the power to change it for the (subjective) "better". The mode of thinking is much different in the proprietary Win32 software world - those users have a different set of expectations - which is frozen upon release. Thus I said perhaps "minimum maintenance" projects is something the community should explore.

@lispi314@udongein.xyz @chris__martin@functional.cafe @dalias@hachyderm.io Free and open source software by its very definition encourages people to make frequent changes to every part of the system, world-breaking changes that are otherwise unthinkble elsewhere are welcomed on a daily basis, and the community members in general are proud that they're so innovative (e.g. one can port an entire OS to a new CPU within a year). The consequence of this system is that most software projects are not a product, there's no such a thing called "the software", but a human process: reporting issues, creating breakages, writing patches, doing CI/CD, packaging for distro, that are in constant motion. If the motion stops, the software will stop working very soon.

If you look at a Win32 app, it's exactly the opposite - it's a product, not a process, once it's completed it's "set in stone", and some people will still use the same binary 20 years later, sometimes they spend great effort to keep the mysterious binary running, even when very little is known about it. The later "minimum maintenance" approach is historically rarely used by the free software community. Perhaps some projects should try it seriously.

@4censord@sk.foopool.de Believe or not, I got the news in 2022 from LinusTechTips. I immediately jumped up to try it, and indeed, even a Windows VM running in QubesOS (with Xen that nobody uses anymore) that had previously resisted many cracks I tried, could run Nvidia driver at that point and I could finally open reference designs in Altium Designer (it was before KiCad had Altium import). It's the one and only real tech tip I got from LTT, and I was absolutely shocked that they actually had real tech tips other than ads and unboxings.

@dysfun@social.treehouse.systems @gsuberland@chaos.social For offline games, nobody cares. But developing SW/HW cheats in online games is legally an act of computer invasion or software cracking. If you made big money selling cheats, you can be in trouble. Arrests of high-profile cheat developers as requested by game companies happen from time to time. Technically it's similar to how the dystopian CFAA works in the US. But speaking of the gaming industry specifically, I guess the level of protectionism is only second to Korea (in which you can be legally charged for playing someone else's account).

@4censord@sk.foopool.de The counterargument from game developers is that their future in-kernel anticheat will simply refuse to run the game until both hypervisor and IOMMU are enabled...

Electronics in Shenzhen, China be like: Ready-made FPGA development boards that plug straight into a PCIe slot to access host memory via DMA. What do they do? Stealing crypto keys for espionage, as featured on Black Hat? No, it's for the kids to cheat in video games like PUBG. #electronics

@lanodan@queer.hacktivis.me If I recall correctly, one Level 6 tool was a custom kernel module in the netfilter chain...