• 0 Posts
  • 23 Comments
Joined 1 year ago
cake
Cake day: August 20th, 2023

help-circle

  • There’s a Pareto effect when it comes to them, in that you can cover a large proportion of use cases with a small amount of work, but the more special cases consume proportionately more effort. For a MVP, you could restrict support to standard USB and SATA devices, and get a device you can run headless, tethered to the network through a USB Ethernet adapter. For desktop support, you’d need to add video display support, and support for the wired/wireless networking capabilities of common chipsets would be useful. And assuming that you’re aiming only for current hardware (i.e. Intel/AMD boards and ARM/RISC-V SOCs), there are a lot of legacy drivers in Linux that you don’t need to bring along, from floppy drives to the framebuffers of old UNIX workstations. (I mean, if a hobbyist wants to get the kernel running on their vintage Sun SPARCstation, they can do so, but it won’t be a mainstream feature. A new Linux-compatible kernel can leave a lot of legacy devices behind and still be useful.)



  • Drew DeVault recently wrote a simple but functional UNIX kernel in a new systems programming language named Hare in about a month, which suggests that doing something similar in Rust would be equally feasible. One or two motivated individuals could get something up which is semi-useful (runs on a common x86 PC, has a console, a filesystem, functional if not necessarily high-performance scheduling and enough of the POSIX API to compile userspace programs for), upon which, what remained would be a lot of finishing work (device drivers, networking, and such), though not all of it necessary for all users. Doing this and keeping the goal of making it a drop-in replacement for the Linux kernel (as in, you can have both and select the one you boot into in your GRUB menu; eventually the new one will do enough well enough to replace Linux) sounds entirely feasible, and a new kernel codebase, implemented in a more structured, safer language sounds like it could deliver a good value proposition over the incumbent.






  • Not if the discs are mass manufactured. To manufacture them, they produce a master image containing the content, make a glass master from that, and use that to press large numbers of identical copies. To have individually watermarked streams would require making a unique master for each copy.

    The best they could theoretically do is to have a write-once area on each disc that has a serial number inscribed onto it in the factory, and have the Blu-Ray spec require that all players read this and then add a watermark to the video they just decrypted from the mass-manufactured disc before passing it on to be displayed, though that would be more fragile, and soon enough noncompliant players would appear, and it would be common knowledge that this exists.

    As for why they don’t write the whole disc the way they could write a serial number, that’s much like why they don’t make the whole airplane out of black-box flight recorder material: it would take a lot more time (both in writing and in creating a unique image for each copy) and be a lot more expensive. I understand that they do this for screeners sent out to Academy Awards jury members (which would be just on artisanally burned BD-R discs), though it wouldn’t scale to the mass market.




  • Not necessarily. The language itself is implemented on LLVM and compiles to a variety of backends, and can interoperate with C and C++ (including presenting C++ classes and STL types in its type system). Toolchains exist for Windows and Linux, as well as Apple platforms, and porting them to other POSIX-like OSes shouldn’t be too hard. The core of the language and its Foundation runtime library are open-source and cross-platform; it’s only macOS/iOS APIs and higher-level frameworks built on them like SwiftUI which are proprietary. Swift is in use on non-Apple platforms: there’s the Kitura web framework, which gets deployed mostly on Linux, and someone has recently used it to write games for the PlayDate handheld console.

    In general, I can’t fault his rationale there. Swift has more modern language features (such as an expressive type system) than Go, is not quite as fiddly as Rust, isn’t a trainwreck of incompatible levels of abstraction like C++, and has developer momentum behind it unlike Dart.


  • “Hand-written assembly” is not more powerful than any other Turing-complete language (including Perl and Python), just more painfully slow and prone to human error to write. (Perhaps if you have a special case requiring speed (such as the processing being done in a tight loop in a financial trading app and the results needing to beat rival trading systems by milliseconds or something equally esoteric), it’d make sense, but in that case, a modern compiler (for, say, C/C++/Rust or similar) would yield comparable results, and if a lot is riding on those milliseconds, you’d eschew code and build a FPGA that pulls the data out of memory buffers in hardware or similar.)

    So these days, the only use case for hand-writing assembly language (other than low-level OS/firmware programming or compiler development) is performative Feats Of Strength, where the challenge is the point. And in that case, you’d be trying to do something heroically challenging, like writing an Atari 2600 demake of Baldur’s Gate or something.