I am live.

  • 0 Posts
  • 230 Comments
Joined 3 years ago
cake
Cake day: July 7th, 2023

help-circle

  • You’re invoking contributions to the Linux kernel, CPython, and Perl as if that settles the matter, but you have been conspicuously vague about what that actually means. Those projects accept everything from typo fixes to deep subsystem work. If you want that credential to carry argumentative weight, specify what you worked on. Kernel networking stack? Filesystems? A CPython PEP? Core interpreter changes? Because right now it reads like résumé seasoning, not authority.

    More importantly, your statutory interpretation is maximalist to the point of implausibility.

    You are asserting that Sections 1798.501(b) and 1798.502(a)-(b) require every application binary, including local utilities like ls, to request an age bracket at download and at launch. That is an extraordinary claim. If true, it would not just affect “platforms.” It would upend global software distribution infrastructure including mirrors, package repositories, container registries, and academic hosts.

    Where in the definitions does the statute eliminate business thresholds? Where does it explicitly define a standalone executable with no network component as a regulated “online service”?

    Where does it impose a per-launch runtime obligation on locally executed software?

    Statutory scope hinges on defined terms. If you are correct, quote the operative definitions that extend coverage to every distributed binary and every individual developer who merely visits California. Because that is not a narrow reading. That is a reading that would trigger immediate Commerce Clause litigation.

    You may very well have contributed to major opens source projects. That does not make your legal interpretation automatically sound. Right now you are asserting universal coverage without walking through the definitional cross-references that would be required to sustain that position.

    If the text truly says what you claim, show the definitional chain. Otherwise this looks less like careful statutory analysis and more like an overextended reading fueled by frustration.


  • Linux is not a company. There is no CEO of Linux sitting in Sacramento waiting for instructions. It is a decentralized, global, open source ecosystem. If one U.S.-based distro tried to bolt on age verification, someone would fork it almost immediately and strip it out. You cannot age gate software that people can freely download, modify, compile, and redistribute.

    From a technical standpoint, what would this even look like? Government ID verification at the kernel level? A biometric scan before you can run apt update? A centralized identity server for Arch users? That runs directly against how Linux is designed. The ecosystem prioritizes privacy, user control, and minimal centralized telemetry. Age verification requires centralized identity services, persistent user binding, and logging. Those models do not align. Even if someone tried, it would be trivial to bypass. VPN, foreign mirror, alternative distro. Done. You cannot meaningfully regulate something that is globally mirrored and open source.

    And this law is aimed at online services and platforms anyway. The harms legislators are worried about do not originate in your bootloader. They happen on social media platforms and content services. The operating system is simply the wrong choke point.

    The only places where age verification is realistically enforceable are platforms, app stores, and tightly controlled commercial device ecosystems. Not a globally distributed kernel maintained by volunteers across multiple jurisdictions. The idea that Linux is going to meaningfully comply in a way that changes outcomes is technologically naive. At best you get some compliance language from U.S. commercial vendors. At worst you get symbolic features that any moderately technical user can remove in minutes.

    That is not how open systems work. Pretending otherwise just advertises a lack of understanding of the architecture being regulated.








  • The idea of putting data centers in low Earth orbit sounds cool at first. It feels futuristic. It feels like something that should be efficient. It is not.

    Yes, space is cold. Yes, you get a lot of solar power. Those are the two points everyone repeats. What they leave out is basic physics and cost.

    Cooling in space is not free. There is no convection. Heat only leaves through radiation. That means giant radiator panels. AI racks throw off massive heat loads. The more compute you add, the more radiator surface area you need. That adds mass. Mass costs money to launch.

    Even with companies like SpaceX driving launch prices down, it is still extremely expensive per kilogram. And servers are not permanent infrastructure. They get replaced every three to five years. You cannot economically upgrade racks in orbit the way you do in a building on Earth.

    Then you have radiation. Either you harden the electronics, which makes them slower and more expensive, or you accept higher failure rates and build in heavy redundancy. Maintenance becomes a logistical nightmare. A failed power supply on Earth is a service call. In orbit it is a robotics problem.

    Meanwhile hyperscalers like Amazon Web Services, Microsoft, and Google put data centers next to cheap power, fiber backbones, and cold climates. It is boring. It is practical. It works. Orbital data centers only make sense if we already have large scale industry in space. We do not.

    And what really makes these threads irritating is the obvious rage bait framing. Throw up a clickbait title about AI destroying the planet or Big Tech trying to escape Earth and you attract people who already hate AI. The discussion stops being about engineering and economics and turns into ideological noise.

    If someone wants to seriously debate energy efficiency or scaling limits, fine. But pretending near Earth orbit is some obvious solution is not serious analysis. It is a cool sci fi concept. It is not a rational infrastructure strategy.


  • No, they’re not.

    The reason vinyl is vinyl is because the format requires very careful mastering of the source audio. The medium is physically sensitive to dynamic range, frequency response, and groove spacing. That is why people argue that vinyl can sound better than a compressed digital file like an MP3 or a mass-produced CD.

    Nothing about a DVD inherently requires special mastering of the video. If anything, DVDs are simply inexpensive to buy on the secondhand market, whether from local sellers or platforms like eBay.

    Given the current state of digital licensing and streaming volatility, I understand why people want physical media like discs in order to truly own their movies. That could explain a modest resurgence in DVD sales. But DVDs are not the next vinyl. Vinyl never went away; it remained in production.

    And no one is putting HD video on DVD discs.