smspf

7 ms·

1.
by smspf 4y ago
Nice read, I wonder how this was detected though. Did it trigger any alarms on the infected machine? Was a firewall or specialized traffic inspection involved?
2.
by smspf 4y ago
I couldn't finish reading the article. The first iPhone made connectors and electronic components easier to get to? Sure, it indirectly helped, as any other new, recent electronic device did. But please don't try to rewrite histo
3.
by smspf 6y ago
This is nice and makes Red Hat look like an amazing OSS contributor, which I think they are. But truth be told, things were not that easy when it comes to RHEL and derivates on aarch64. As contractors working on getting stuff working on aar
4.
by smspf 6y ago
By investing in these ports I was thinking about any contribution that enables/improves arm64 support. So yes, PRs for python itself definitely qualify. However, the python ecosystem is not only python, there are lots of python package
5.
by smspf 6y ago
To be honest, I don't blame Apple for this. I blame the ARM ecosystem which is very fragmented, each company working with ARM is contributing to the stuff they are interested in and that's it. Lots of contractors and always shuffl
6.
by smspf 6y ago
A couple of years ago we reached out to the python community about wheels and arm64 - how it should be handled and whether they plan on embedding non-x86 blobs. We received the standard "we'll think about it and let you know"
7.
by smspf 6y ago
In my experience, for tasks like everyday operation, kernel building etc.: Thunderx < ThunderX2 < eMAG (Ampere's platform before N1). I wouldn't say it's the same order of magnitude for the 2 comparisons, but it's
8.
by smspf 6y ago
>In an interesting turn of events, the investigation of the whole SolarWinds compromise led to the discovery of an additional malware that also affects the SolarWinds Orion product but has been determined to be likely unrelated to this c
9.
by smspf 6y ago
ThunderX was a huge disappointment. ThunderX2 (which one may think is the successor of ThunderX, but is actually a completely different system that Cavium obtained by acquiring a different company that was also working on ARMv8 hardware) wa
10.
by smspf 6y ago
My bad, I didn't do proper research when writing that comment. Thank you for the correction. And that's too bad, UEFI would have been easier to deal with imo.
11.
by smspf 6y ago
I submitted arm64 patches to OSS ranging from the kernel to the most obscure userspace applications. All my contributions required some support or at least confirmation from the hardware vendor that my assumptions were correct - e.g. I subm
12.
by smspf 6y ago
No. Because (in no particular order): - it shouldn't be the community's (or a crowd-funded dev's) responsibility to provide software support for hardware produced by one of the largest companies out there (bonus: with zero ha
13.
by smspf 6y ago
Afaik, UEFI (at least on ARM hardware I worked with) embeds the DeviceTree for non-ACPI boot usecases, so the user is no longer responsible for providing the proper DTB for that board, although the user can still override it if needed. Last
14.
by smspf 6y ago
I'm surprised it's only a 3x slowdown. But the single-thread performance of native execution (without emulation) is worse on aarch64, which was expected. Imo, a better benchmark would take into account the multithread performance
15.
by smspf 6y ago
Not sure about the socket used (it might be soldered down), but aarch64-based workstations are already available for the general public, e.g. [1]. [1] https://www.anandtech.com/show/15737/arm-development-for-the...
16.
by smspf 6y ago
I agree on the performance loss. Just for kicks, I ran the same commands on some real aarch64 (32 cores, 3.0GHz, ARMv8.? - can't remember and already logged off the machine, but I can double check tomorrow). Without further context, nu
17.
by smspf 6y ago
I've been using postgres, cassandra, redis and mysql/mariadb on aarch64. Only ran into issues with MySQL, which we rootcaused to some weird atomic locks not working as expected on the first generation of ARMv8(.0) a couple years b
18.
by smspf 6y ago
That's a fair point. Emulation implies other limitations too - code compiled on your machine might leverage only the CPU features emulated, which would lead to sub-optimal binaries, not to mention much slower builds.
19.
by smspf 6y ago
So many wrong assumptions ... 1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse