One of the fun parts of being a #Linux mirror operator is that you get to deal with China Mobile using ISO download mirrors to fix their traffic ratios with other ISPs at peering points.
Looks like they've moved to using Slackware now...
@kwf Wait, do you have more documentation on this? I saw tons of China Mobile IPs downloading a bunch of Linux ISOs once upon a time from my servers but could never figure out why!!
@kwf I saw random user agent strings on BitTorrent, and no blocks were ever reported as completed by any of the clients, so it looked super intentional. I could never figure out why it was happening though, there were some guesses from folks on Twitter but nobody pointed to peering at the time. Is there a benefit to padding out traffic during low periods or achieving a specific ratio of in/outbound traffic? I'm super unfamiliar with this space, apologies if these are dumb questions 😅
@detective Hi! If you have a moment I have an odd question, I've searched around to no avail: what folder was the DB stored in on your system? I see snapshots are saved in C:\Users[username]\AppData\Local\Temp but looking for where the Administrators-and-SYSTEM-only permanent copy is. I see D:\Analysis... in your SQLite browser but I'm not sure if that's a copy or its location on your system 😅
If your company or marketing team or whatever sends me spam emails, I'm "that guy" that jumps through all the spam report/abuse report/etc. hoops to get you booted off whatever email service you're using. Fuck spam and fuck you. 😘
Now that my class is wrapping up, time to try out some Seagate MACH.2 (read: dual actuator!) HDDs. The performance from these has been crazy - over 500 MB/s sustained sequential reads per drive. Comes with more power consumption, heat, and I assume failure rate... But looking forward to seeing how these perform in the real world.
@lucas If you're careful about how you're partitioning & know your access patterns, you "can" get 2x the IOPS. But I suspect that's easier said than done. I have the SATA version which presents as a single device, and you have to partition it into two halves (one for each actuator), then organize your data on each half. When each acutator is being accessed independently, you're golden! Anything requesting access from the same actuator is going to have the usual contention issues though.
In case any of yin see the "AI programmer Devyn!!!" hype, here's how I popped that hype balloon ...
The same marketing site that claims "Devyn can not just solve coding problems, but create entire applications on its own from prompts" lists its most impressive performance on SWE bench - the ability to solve code problems from a GitHub issue - at 13%.
And that's super impressive compared to other LLMs.
But if I couldn't solve 87% of documented bugs, I'd be out of a fucking job, y'all.
@jerry Howdy! I'm refreshing my media cache on cybersecurity.theater as I didn't realize lowering the media cache settings has no exception for favorites (ugh. aaand now I'm subscribed to https://github.com/mastodon/mastodon/discussions/19260) - during, I noticed that infosec.exchange links are 403ing when my server tries to re-cache them.
"Error processing 110231093662385392: https://media.infosec[.]exchange/infosecmedia/media_attachments/files/110/231/093/070/987/876/original/2d5fca99ebc73c20.jpeg returned code 403"
@jerry When I go to infosec.exchange directly it seems like the new media storage URLs are "https://media.infosec[.]exchange/infosec.exchange/media_attachments/..." - I can go into my server's database and update 'em with ~relative confidence, but I wonder if it'd be useful for other federated servers if infosec.exchange had a rewrite rule that 302s to the correct directory for old posts?
About the vibrator that allegedly had malware on it 2wks ago... I found a seller and bought one. Say hi!
The people on the thread who pointed out that there wasn't any evidence tying the vibrator to the Redditor's malware download were - of course - downvoted.
And ... so far there are no signs of malware. It doesn't register as a HID or present any storage (therefore it has no autorun.inf). I'll be doing some more setup so I can plug it in and monitor it for an extended period of time.
It's possible, though IMHO unlikely, that only some batches of this device had an implant. That'd be a manufacturing change, which gets expensive fast. Also I think you wouldn't do something so obvious if you're running an operation that's going to burn your factory/supplier/etc. reputation.
As funny as it would have been, it's another drop in the POC or GTFO bucket.
Probably not necessary to do anything further to test. I pulled the casing off and the data pins aren't even soldered (hard to get a good angle for this and all I have is my phone camera, sorry - but it is visible).
I'm not a hardware implant expert but from what I can tell, the PCB is not suspicious in any way either. Looks like exactly what kind of complexity and layout I'd expect from a button, battery, and vibration settings controls.
If there's anything else I can do to test or look at please let me know! I won't toss it for a bit - unfortunately even if there's no malware on it, nobody in my house is going to use it as I am not trusting this to be body-safe, so if there's a destructive test you're interested in don't be shy!