2,847 karma · joined November 10, 2007
This “mostly idle” assumption is gonna break the moment you hit a load spike and wake up most of those “idle” threads.
The success of async is often (mis)attributed to eliminating unnecessary resources, but in practice it's actually because async model implicitly enforces an invisible job queue, where usually only a single process/thread per core is heavy lifting the actual work, and async I/O will feed processing pressure back to the load source via network (e.g. TCP ACK).
I had the MBL Duo. It ran on an 800MHz Applied Micro APM821XX PowerPC processor with 256MB RAM. The stock firmware was a customized version of Debian. I couldn't remember exactly which version of Debian but it's definitely older than Debian 9. Maybe 6 or 7? Anyway, you can enable SSH access via web UI and directly login to the device and see everything running there.
IIRC WD used OpenVPN to establish a connection to their servers to allow remote access to these devices behind NAT and firewalls. I had always been wondering what if their servers were hacked and then hackers could theoretically access the NAS via that VPN connection and by extension my LAN behind firewalls so I disabled the remote access feature.
A couple of years back I finally got tired of the ancient Debian, and since WD had already deprecated the device without further updates/patches, I was looking for alternatives. There were people on WD forums trying to compile and install newer versions of Debian. But since the device does not have video out or console port, it was very easy to mess up and got bricked.
Eventually I found OpenWRT (yes, the linux-based router OS) had official support for both MBL models (https://openwrt.org/toh/western_digital/mybooklive) and the installation seems pretty safe (especially for the Duo with replaceable disks). So I went with OpenWRT and never looked back.
My MBL Duo now sits at my parents-in-law's place running OpenWRT. I had setup WireGuard to connect it to my LAN in another city and used it as a remote backup destination in case of either place catching fire or whatever other disasters.
And now I feel pretty lucky for my decision to ditch the original firmware. Good riddance!
> A drive can be over-provisioned simply by formatting it to a logical partition capacity smaller than the maximum physical capacity. The remaining space, invisible to the user, will still be visible and used by the SSD controller.
Does the controller read the partition table to decide that the space beyond logic partition is safe to use as scrap?
The project later merged with Intel Clear Container to become what's now called Kata Containers (https://katacontainers.io/) and is now widely used by several Internet giants like Alibaba and Baidu.
The startup was acquired by Ant Finance a couple of years ago.
(I recorded a podcast with one of hyper.sh engineer if you can listen to Mandarin https://pan.icu/25)
The use case is usually about append-only logs: MacOS constantly generates tiny log lines and those must go somewhere? Does Write Amplification make logging a bad use case on SSD?
Coz there's no standard M.2 form factor NVMe SSDs without a controller chip, and even if you can find one, there's no standard protocol to talk to it.
Recall that 3rd-party drive manufacturers are really bad at properly making Self-Encrypting Drives (lots of HN stories previously, just search for SED). It's very likely a factor for Apple to decide to implement its own SSD controller inside the T1/T2 chip on recent Intel Macs, and directly on die on Apple Silicon, so that Apple can fully control the data written to raw flash and be confident in its own implementation of encryption.
Charging a premium for more capacity is a standard Apple practice anyway, and the fact that such security-focused approach makes it unavoidable is a side-effect.
The dev said it's basically because Swift Crypto API does not support chacha20-poly1305@openssh.com, which is a non-standard construction (compared to chacha20-ietf-poly1305).
> A top level takeaway from this data is that for things that rely on pure Go the M1 machine is, in general, a good bit faster than the Intel machine. For code that relies on highly optimized assembly, like a good chunk of the crypto/ code, the Intel machine wins (although I wouldn’t be surprised to see significant gains for the M1 as arm64 assembly implementations get more attention and are further polished).
Basically Go lacks lots of optimized assembly code for ARM64.
Could it be from the ISP-side devices?
If anyone knows how the poem ended up in my modem, or even just what's ethertype 0x8300 all about, please comment!
Is this feasible now?