Dran_Arcana

When you're the size of LMG you don't hire investigative law firms for PR; you do it for liability. The goal is to limit corporate liability by removing individuals likely to get you sued, and most importantly to distance leadership from it with plausible deniability. The firm also has its own reputation to consider, and wouldn't let a client get away with materially misrepresenting their results.

I don't think its unreasonable to suggest that a positive finding from an investigative firm is evidence to support their position that they, materially, did nothing wrong. The fact that no one was fired as a result of that investigation is a good sign externally, as it would open them up to more liability if they knew about it and did nothing.

The source to this compat library is in their sources last I checked, but because it's not part of their standard repos it doesn't technically have to be. I suspect this is eventually the end-goal.

A lot of industries are semi-forced into it. Let me give you an example I know of first-hand. Modern SAP stacks support 3 operating systems. Windows Server, RHEL, and SuSE.

You're probably thinking to yourself: "but rhel is just regular linux, surely you can install it on anything if you have the appropriate dependencies, I'll bet it even just works on rhel-compatibles like rocky, alma, or centos stream!"

And you would be ~sort of~ right, but wrong in the most dystopian way possible. The installer itself does hardcoded checks for "compatible" operating systems, using /etc/os-release and a few other common system files. Spoofing those to rhel 8.5 or whatever is easy enough, but the one that really gets you is a dependency for compat-glibc-X.Y-ZZZZ.x86_64. This "glibc compatibility library" is conveniently only accessible via a super special redhat repository granted by a super special sap license (which is like ~$2,000/year/cpu). Looking at the redhat sources it is actually just a bog-standard semi-modern glibc compile with nothing special. The only other thing you get with this license as far as I can tell is another metapackage that installs dependencies, and makes a few kernel tweaks recommended by SAP.

So you can install it on alma/rocky by impersonating rhel in /etc/os-release, and then compiling a version of glibc and linking it in a special hardcoded location, but SAP/Redhat put as many roadblocks in your way as possible to do this. It took me weeks of reverse-engineering the installer to get our farm off of the ~100k/yr that redhat wanted to charge us for essentially:

./configure --enable-bootstrap --enable-languages=c,c++,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --disable-libquadmath --disable-libsanitizer --disable-libvtv --disable-libgomp --disable-libitm --disable-libssp --disable-libatomic --disable-libcilkrts --without-isl --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 9.1.1 20190605 (Red Hat 9.1.1-2) (GCC)

definitely worth $100,000/yr... much capitalism, many line go up

Why?

The difference is I (the contributor of content) have the same access as anyone else to the data, and could use it for my own purposes if I wanted to.

On a platform like reddit, access to the raw data is controlled and cannot be format shifted / used in any way I wanted to.

There's nothing preventing you from forking a Lemmy client or server to prototype this. Depending on how you implement the activitypub backend, you might be able to make it transparent to a user if you present an algorithm as an array of cross posts via a /c/ of a server.

Anything more might require forking a client, which might be easier to implement but may be harder to convince a large userbase to migrate to.

I use ansible on one of my side projects; I use puppet at work. It's the same reason I use raw docker and not rancher+rke2... it's not about learning the abstractions; it's about learning the fundamentals. If I wanted a simple abstraction I'd have deployed truenas and Linuxsserver containers instead of Taco Bell programming everything myself.

Sure. I have an r630 that is configured as an NFS server and a docker host called vacuum. There is a script called install_vacuum.sh that with a single command, can build the server to my spec from a base install of Ubuntu 24.04. it has functions to install base packages from repositories, add new repositories, set up users, create config files for NFS, smb, fstab, crontab, etc... once an NFS server exists on my network, any other server could be my docker host. My docker host is set up from a script install_containers.sh. as with before, it does all the things to get me a basic docker host, firewalled, and configured for persistence via my NFS server. It also has functions to create and start docker containers for all of my workflows (Plex, webserver, CA, etc), and if those containers don't exist, it will build a docker image for said workflow based on a standardized format (you guessed it) bash build script for the containers. There is automation via cron on whatever host runs docker to build and update the containers once a week, bare-metal servers update themselves nightly, rebooting when necessary via unattended-upgrades.

Basically, you break everything down into the simplest function possible, have everything defined via variables in shared configurations that everything sources before running, and you have higher and higher level functions call other functions until you have a single function that cascades into a functioning system. Does that make sense?

Have you started collecting your notes into scripts?

Not sure if many people do what I do, but instead of taking notes I make commented functions in bash. My philosophy is: If I can't automate it; I don't understand it. After a while you build enough automation to build your workstations, your servers, all of your vms and containers, your workflows, etc, and can automate duplicating / redeploying them whenever required. One tarball and like 6 commands and I can build my entire home + homelab.

I feel the sentiment though, my daily driver is built off of ubuntu-server headless. I find it's just the right amount of "has searchable solutions for near everything" and "is properly minimal" to base my workstation off of. I run X11, pulse, awesomewm, firefox, lxterm... fairly standard stuff but without gdm, gnome/kde even installed it's pretty lightweight. The entire os uses ~780mb of ram (+23gb for firefox tabs lmao). It gets the job done, keeps my skills relevant maintaining the automation that builds it, is dead simple to troubleshoot, and has very few black boxes.

For the average user you're definitely right, but I will say for the sysadmin of headless systems, having a powerful cli editor is a godsend. While it may seem arcane and unnecessary, learning vim is easier than managing remote x or sshfs or copying files to and from a system.

I didn't learn vim to be a contrarian; I learned it because it seemed (and still seems to be) the path of least resistance for many workflows.