Configure agents for consumers at scale to report violations to regulators. Wait time not accurate or communicated? Complaint filed. Human agent not available within time limit? Complaint filed.
Think about all the time and effort for all of the consumers in the aggregate that would be needed to hold corporate counter parties accountable, with the cost being code and some compute time on device. This is where AI agents shine. They can do the mundane work of capturing evidence of compliance violations, time stamping, packaging the violation event, and shipping to an endpoint for reporting them.
Every consumer’s phone becomes a regulator watchdog node. We can even use LLMs to rapidly ship the app(s) needed to do this.
The provider for Chase credit card claims (insurance, price match, etc.) went through a company, EClaimsLine, that had nearly that exact phrase bold and red on their website for many, many years. I'm honestly shocked that their new website after the rebrand to Chase Card Services doesn't say it too.
I use `lima` and `llvm` every day with brew. It works great there's no reason to use distro specific tooling when you can use what everyone else is using.
Don't bother with the motherboard, the new BIOS is worse. I have two that just randomly shut off whenever they feel like it. I just bought a thinkpad instead, shrug.
Imho its not necessary for the average user, adding too much complexity.
For example, I tried to config gpsd to use another port, nothing would work; systemd quietly overrides gpsd's configfile and required additional systemd incantations to change what should have been easy. And the man pages are a mess
And journalctl makes me want to pull my hair out; just let me grep a regular file - discovering namespaces is a nightmare
Personally I think moving away from the hodgepodge of scripts, giving a consistent interface for people to use, extend, etc, is kinda necessary for the average user to have a decent system. It can often be complex to make things simple.
I'm also not sure how systemd could override a config file, because systemd does not write the unit files on a system. Wouldn't that be on the maintainer, distro, or other methods of getting the unit file?
It sets up the network for services, but it's been a minute since so I don't remember the specifics, just that I needed to make a new file in some deep folder to tell it to use a non-standard port.
To me its just more complexity, and not super consistent, which is fine for enterprise, or automation. I'm used to openbsd, regular shell init scripts go in /etc/rc.d, and my logs are in /var/log. Can't get much simpler than that, but i understand its limitations, and Linux is certainly more of a hodgepodge
Edit: found my notes, first was discovering the "gpsd" & "gpsd.socket" namespaces existence, then needing to do "systemd edit --full gpsd.socket" because without "--full" it makes an override file that didn't actually override anything...my note quality declined rapidly after that due to anger
It’s at odds with the philosophy of do one thing and do it well. Its monolithic feature set pushes out smaller contributors and leads to increased reliance on a singular package. This tends to self reinforce. I also use systemd in my current distro so not sure where I stand on this but it’s a fair concern.
Before systemd I had Redhat machines with 3 to 4 years of uptime, and now you need to restart Linux after updates....while Windows people rarely and they laugh at you...
If you use the command line to do the update there is no need to reboot, however, the issues that the offline update is trying to solve still stands.
Some programs can crash when all their files are suddenly swapped for new ones. I've seen multiple linux systems bork themselves during an update because the update itself caused the desktop session to crash, which caused the update process to be interrupted just as it was modifying some crucial files, thus rendering the system unbootable.
>> If you use the command line to do the update there is no need to reboot
Completely untrue.
And before systemd, updating sshd or cron usually meant restarting that one daemon. With systemd, core updates can affect PID 1, logind, journald, udev, user managers, socket activation and cgroup state as one dependency graph.
Before, its was replace a library and restart the few daemons using it. Now the same library may be loaded by system services, user services and systemd components, making a clean partial restart harder to verify.
"We're sorry, we're receiving more calls than usual, stand by..."
24/7 for over 30 years!