Thats the thing, i noticed it almost instantly when trying to install a package that depended on it, as soon as it started, it hard locked my laptop, didn't get to infect it.. but if they had slowed down that fork bomb.. it would have done more damage.
Yeah, and this is a pattern I saw in the Fancy Bear Goes Fishing book, a lot of discovery of malware is either pure luck, or blunders from the malware developers. https://en.wikipedia.org/wiki/Fancy_Bear_Goes_Phishing
I just installed Harbor, and it instantly pegged my cpu.. i was lucky to see my processes before the system hard locked.
Basically it forkbombed `grep -r rpcuser\rpcpassword` processes trying to find cryptowallets or something. I saw that they spawned from harness, and killed it.
Got lucky, no backdoor installed here from what i could make out of the binary
Same experience with browser-use, it installs litellm as a dependency. Rebooted mac as nothing was responding; luckily only github and huggingface tokens were saved in .git-credentials and have invalidated them. This was inside a conda env, should I reinstall my os for any potential backdoors?
After having gone all-in on LLM agents for a while, I'm not so sure anymore. An LLM with lots of context can sometimes generate more accurate code, but it can also hide decision-making from you, the person who actually has to maintain that code. If the LLM pulls in 1000 files to make a decision, that's no longer a decision that you can understand.
Personally kitty is the only one I keep coming back too. Mostly because it's very customisable, fast, lean, ligatures, separate font for italics, great macro support, and supports automatic tiling panes.
No you're not wrong, if you're comparing ARM CPUs on Linux to one specific Intel CPU, the Lunar Lake V ones. Then yeah you're not wrong, it's very much a case of optimisation for CPUs like the Snapdragon X Elite CPUs in comparison.
But if you widened the scope a bit more, then I think there's plenty of more energy hungry x86_64 CPUs compared to ARM.
Watching all these open source, federated versions of social media platforms is like if you found out your favourite drug was actually manufactured by some really bad people and made people around the world suffer. So you make an open source version of the drug. Similar formula, just this time the people can own it.
Sure you cut out the bad people, but is the situation improved now?
There are projects where long term addicts are given pure medical heroin (Diamorphin) in a controlled environment, and they do considerably better than their control group who does not receive their drugs like that.
Their drug is rage, thirst and cute trap videos generated by AI and selected for maximum engagement.
If it's not harmful it's not the same drug. Unlike diamorphine, a medical grade supply does not reduce harm; it's more like sniffing glue, inhaling poison to escape reality.
The harm from social media is at least in part caused by the feed suggestion algorithm being optimized for screen time (aka addiction). Potentially open social media where the suggestion algorithm is not that could be a big improvement.
No, sorry, but it is unreasonable.. Why should I need an apple device to compile my code for an apple device?
You can build Android apps on an Apple device, no problem. You can build Linux apps on an Apple device, no problem. etc... But the reverse isn't true. Its just more of Apple financially gate keeping their ecosystem so they make more money in as many channels as they possibly can.
Testing on real hardware is the ONLY time I would say that owning, or at least having access to the hardware has real tangible benefits, and I would argue that that you NEED or SHOULD do this.. But to block compiling to that ecosystem? Sorry but I fundamentally disagree.
Blocking compiling, means requiring xcode, which requires a mac, which requires you to give more money to Apple, and is no different IMHO than giving Apple $100 a year, because now you're giving them a lot more of that every X years (where x is how many years that laptop gets updates)
For decades, Microsoft only made Visual C++ for Windows, and alternatives like DJGPP weren't very good. This isn't unreasonable, it's just how programming works when you target a platform. Visual C++ relies on Windows because it's a Windows program, and Xcode is written for MacOS, not for Java or Electron.
What is stopping you from writing an open source alternative to Xcode that runs on Linux?
you can code-sign with open-source tools. That's not the hard part. Signing with a certificate trusted by macOS , that's where there's no avoiding having to go to Apple.
reply