I don't feel like spending my money on some horrible corpo pulling out stuff like this, even if I've been using linux since 2006. Who can tell if they will do this to other OS in the future?
My understanding is that the monitor doesn't do anything by itself - it's just Windows detecting the device and automatically downloading and installing LG:s proprietary add-on software. The monitor itself isn't attacking the machine by exploiting vulnerabilities or spoofing user input or anything like that.
So you won't have this problem if you're running Linux and other Free Software under your own control. The problem in this case is just another example of why proprietary software can't be trusted.
> My understanding is that the monitor doesn't do anything by itself
The understanding should also included that unless LG actually asked Microsoft to implement this autoinstalling malware, it wouldn't have been installed by itself.
I think parent commentator is making the argument that they don't want to financially support companies who engage in these sort of things, regardless if this particular scenario applies to their environment or not.
Sure, but I was addressing the question that was asked (although perhaps it was asked rhetorically): LG cannot do this to you if you don't install their proprietary software, so Linux users are safe (assuming they use a trustworthy distro).
You could choose to buy from another vendor, but other vendors have the same incentives to abuse your trust in the same way once they manage to persuade you into running their proprietary software on your machine.
I wouldn't be so categorical. This isn't really a kernel concern, and I could completely believe that there are some distros out there that pull in random packages based on hardware detection.
The saving grace of linux currently is that volunteers package most of the software, and they don't generally package malware. There is no structural guarantee there, and if we invite corporate interests to package at some point (like flatpack and snap wants to) this is 100% going to happen eventually.
Arch Linux's AUR was recently hit by an actual malware supply-chain attack[1], which I would claim is arguably worse than adware. NPM is regularly in the news for supply-chain attacks. And then there was the XZ utils debacle in 2024. I concede that Microsoft is in part responsible for facilitating something like this, but just because something is free and open-source or based on Linux doesn't make it a universal panacea for malware or supply-chain pwnage.
ImHex is amazing! It’s actively maintained, sponsored by FUTO, and is very hackable (both without recompiling, as well as modifying the grammars for others to take advantage of)
Post Mendeley shutdown, zotero has been an awesome replacement (while not being controlled by Elsevier). Given the amount of PDF's that I see during researchy times in my life, it's been an absolute godsend. Highly reccommend!
Zotero is the best. However, if your brain is highly tuned to use Mendeley Desktop, note that they backed down on killing it, they just won't add new features (where that leaves security updates I'm not sure).
I love this kind of research since it correctly identifies some issues with the way the public interacts with LLM’s. Thank you for the evening reading!
I’d love to see future work investigating
- how does this compare to expert users (doctors/llm magicians using LLM’s to self diagnose)
- LLM’s often provide answers faster than doctors, and often with less hassle (what’s your insurance?), to what extent does latency impact healthcare outcomes
- do study participants exhibit similar follow on behavior (upcoding, seeking a second opinion, doctors) to others in the same professional discipline
You’re conflating a person trained in a craft (medicine) with a person good at asking a next-token-generator (anybody) and sussing it off as if it is a given. Its not.
I love the vibe of squishing formats together — like APE.
I’ve had this problem in the past (shudders in Bazel’s WORKSPACE file) and what eventually ended up saving my bacon was org-babel.
Yes, it does mean that emacs is a build-dependency, but honestly literate programming pretty excellent for untangling the complexities of a large build.
fantastic — I’m sure folks who have poked binaries or written patches have all had the desire for something like this. Glad to see that it exists!
I’m definitely going to use this for solving some problems that i’m currently facing.
For anyone curious about what hare-brained scheme that one could hatch with this, i’d like the ability to do something like a PGO’d shared library —- watch the process run and exit, tracing all dlopen’s to create a new shared library with only the right functions from all the referenced libraries.
Hopefully this works, and if not, i’ll at least fail at something interesting :)
One of the cited references is Guillermo Webster — and while the article lists uncmin as the desired artifact, the project that uncmin was developed for takes the concept beyond layout to back solving for desired program outputs.
Carbide [0] is the project that encapsulated some of this in a workable demo. It’s really cool!
My favorite illustrations for the concepts discussed here (in an accessible form, not the processor optimization manuals) has long been [0].
For me, this really makes working with a modern microprocessor a science, as anyone who has written benchmarks knows -- it's difficult to reason about the complex behaviour and performance cliffs without testing.
Another excellent example of the weirdness has to be JVM anatomy quarks [1]
It was very good, I learned a lot. Actually more high-quality info than I can absorb in one sitting, but I bookmarked it to come back to.
I'd love to see an updated version. The article talks about how out-of-order execution has a high power overhead and produces relatively small performance gains, but the M-series chips from Apple have deep OOO and low power consumption; I'm curious to learn what they did differently.
