Their CISO literally acknowledged it and then they all continued ignoring it again. This isn't just bad process, this is a broken security organization.
Most automated analysis isn't dependent on just behavior, but rather suspicious things in the code itself. You have a popular open source package with files that exist on pypi but not github then that's a big flag, or if a similar package suddenly has some base64encoded garbage that runs through an obfuscated exec call. In other words the simple fact that the project has obfuscated code is enough to flag for further attention.
That said if the only issue is time, researchers will just run their automated analysis through machines with dates in the future alongside their normal tests.
Cat and mouse like the sibling says ;) Like if you start changing system time, I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this. Of course I'll run the code that does this through "my obfuscator".
The thing with cat and mouse based on time is that this now became a default. I rather liked my odds when malware authors assumed that the defaults were that dependabot updates right away. If the general consensus online seems to be 7 days, then I'll set my dependabot to wait 10 days, so on average I'll catch even things people report over a weekend. Now that the default is a longer time period, I have to change my time period to be even longer, which actually increases my risk in another way: I'll stay vulnerable to _actual_ vulnerabilities vs. supply chain attacks for longer.
> I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this.
This makes no sense, the system clock would be set before the suspect package is even pulled down. There isn't a "jump" just a reboot and system start at a "totally real" point in time.
And the premise is that this package can evade detection of its suspect code by using an ever-increasing amount of odd code? Yeah, that's a hard strategy.
A cat and mouse game at least raises the bar for the exploit. The status quo requires no attempt at obfuscation at all. It also makes it harder for such an exploit to turn into a worm, since developers have time to notice their credentials have been stolen and pull any malicious packages pushed using them. (and such worms hitting popular packages have so far been how most people have been exposed to this risk).
Yup, this is one of the many reasons why I prefer OpenCode as my agentic harness of choice. If I'm confused about something I can just read the source code.
I found it really eye opening to understand the flow of how the harness instructs the model and then consumes the crafted JSON response that comes back so you can better understand the split and where a fix may need to go; such as better harness logic, different prompt or perhaps another model.
The courts have never said piracy, which is how the training sets were originally built, is legal. There are several court cases still ongoing over this.
I have a Linux box with two 3090s and it's been great for running Qwen3.6 27b. I lowered the power on each card down to 250w, and then built a small ducting/fan system to vent the waste heat outside. The machine is pretty much silent, and I'm still getting 110 tokens per second out of it for coding tasks.
How useful is the second 3090 in this setup? I run the 5-bit quantized model on a single 3090. Does the second 3090 allow you to use the full precision model instead or a less aggressive quantization by splitting the layers? What about running the 35B model instead?
More memory means less aggressive quantization, more concurrent requests, and larger context windows. I also get a boost in tokens per second (not double, about 1.5x compared to a single GPU).
The 35B model is an MoE (mixture of experts), which uses only a subset of parameters at a time. The 27b one is slower but has way better performance.
This is just not true. There have been leaks due to micrometers in just about every section of the ship at one point or another. A quick search pulls up examples of US modules having issues, especially around interfaces and seals. NASA had a whole investigation between 2018 and 2021 about the recurring issue.
This is just wrong. All serious issues that turned out to be safety concerns were in Russian modules. The 2018 leak you refer to here was in a Soyuz capsule and the 2021 leaks were in the Zvezda module (same place they are this time). In between there were also minor leaks in the Zvezda connection tunnel.
If you count the Soyuz leak, then the Boeing counts too! That was far more serious than anything you listed.
Two astronauts stranded for nine months taking the ISIS supplies intended for others. This is after they safely docked, which was considered risky at the time.
I think you're confusing me with the OP, which in fairness I didn't read.
Nothing in the Russian space program in the last few decades have been as dangerous as Boeings little fiasco. Yes, the modules have long term problems, but they're built by the Russians because they have the most experience in space living quarters.
Look at space mission fatalities, the least Soviet/Russian one was in 1971 and that includes the 90s.
Thats 55 years
The US since then has had two shuttle disintegrations, the latest in 2003 when the US gave up launching astronauts for a few decades.
Why are you commenting then if you don't even know what the topic of the conversation is? Just to distract from the issue with unrelated facts to defend mother Russia's image? Do you even realize how much like a propaganda troll account you sound?
You spewed BS about the Soyuz, which isn't part of the ISS.
Well if minor Soyuz problems are in play, I raise you two Shuttle disintegrations and a Boeing craft since the last fatal Soyuz accident in 1971.
You know instead of throwing "Russian troll darts" try practicing "strategic empathy", instead of letting your emotions blind you about engineering principles. Sone pointers:
- Space is hard.
- The Russians are good at it.
- So are we.
- The Russians are better at keeping people alive in space.
- We're better at sensors and materials.
- Historically Russian launches are cheaper (thats changed)
- Historically we've had money to launch more (that's changed)
Kindest Regards,
American materials engineer (guess who I work for)
Frankly the non-profit has failed. OpenAI is one of the least open of the AI companies (Anthropic is a bit worse). If it wasn't for the labs in China the dream of an actual open ai system would be dead.
I feel like people don’t give OpenAI enough credit for the early papers they did publish. Those are what showed the way that everyone else has built on.
They literally threw out every line of code that existed before and rewrote it in a completely different language, seemingly on a whim. That's how it was trashed, in the very literal sense that all of the existing project was tossed in the trash in favor of a completely brand new code base. That's a big deal even if you ignore the coding agent aspects.
The worst part is that they basically didn't review the new code at all other than making sure it passes tests. We have no idea what could be lurking in the codebase now, and it's even all completely un-idiomatic, Zig-ish Rust.
I swear they did this as a marketing ploy. To set the precedent that these large refactors are okay to do, and ingrain it in the engineering zeitgeist.
Kind of reminds me how Google starting putting on automatic AI processing of YouTube videos and shorts around the time of AI generated video and images. Their processing gave the videos artifacts that made them look more AI generated, making it harder to discern AI generated images, maybe to make demand for their watermark products.
