Need to let loose a primal scream without collecting footnotes first? Have a sneer percolating in your system but not enough time/energy to make a whole post about it? Go forth and be mid: Welcome to the Stubsack, your first port of call for learning fresh Awful you’ll near-instantly regret.

Any awful.systems sub may be subsneered in this subthread, techtakes or no.

If your sneer seems higher quality than you thought, feel free to cut’n’paste it into its own post — there’s no quota for posting and the bar really isn’t that high.

The post Xitter web has spawned soo many “esoteric” right wing freaks, but there’s no appropriate sneer-space for them. I’m talking redscare-ish, reality challenged “culture critics” who write about everything but understand nothing. I’m talking about reply-guys who make the same 6 tweets about the same 3 subjects. They’re inescapable at this point, yet I don’t see them mocked (as much as they should be)

Like, there was one dude a while back who insisted that women couldn’t be surgeons because they didn’t believe in the moon or in stars? I think each and every one of these guys is uniquely fucked up and if I can’t escape them, I would love to sneer at them.

(Semi-obligatory thanks to @dgerard for starting this)

  • Steve@awful.systemsEnglish
    0·
    3 months ago

    I read the white paper for this data centers in orbit shit https://archive.ph/BS2Xy and the only mentions of maintenance seem to be “we’re gonna make 'em more reliable” and “they should be easy to replace because we gonna make 'em modular”

    This isn’t a white paper, it’s scribbles on a napkin

    Design principles for orbital data centers. The basic design principles below were adhered to when creating the concept design for GW scale orbital data centers. These are all in service of creating a low-cost, high-value, future-proofed data center. 1. Modularity: Multiple modules should be able to be docked/undocked independently. The requirements for each design element may evolve independently as needed. Containers may have different compute abilities over time. 2. Maintainability: Old parts and containers should be easy to replace without impacting large parts of the data center. The data center should not need retiring for at least 10 years. 3. Minimize moving parts and critical failure points: Reducing as much as reasonably possible connectors, mechanical actuators, latches, and other moving parts. Ideally each container should have one single universal port combining power/network/cooling. 4. Design resiliency: Single points of failure should be minimized, and any failures should result in graceful degradation of performance. 5. Incremental scalability: Able to scale the number of containers from one to N, maintaining profitability from the very first container and not requiring large CapEx jumps at any one point. Maintenance Despite advanced shielding designs, ionizing radiation, thermal stress, and other aging factors are likely to shorten the lifespan of certain electronic devices. However, cooler operating temperatures, mechanical and thermal stability, and the absence of a corrosive atmosphere (except for atomic oxygen, which can be readily mitigated with shielding and coatings) may prolong the lifespan of other devices. These positive effects were observed during Microsoft’s Project Natick, which operated sealed data center containers under the sea for years.25 Before scaling up, the balance between these opposing effects must be thoroughly evaluated through multiple in-orbit demonstrations. The data center architecture has been designed such that compute containers and other modules can be swapped out in a modular fashion. This allows for the replacement of old or faulty equipment, keeping the data center hardware current and fresh. The old containers may be re-entered in the payload bay of the launcher or are designed to be fully demisable (completely burn up) upon re-entry. As with modern hyperscale data centers, redundancy will be designed-in at a system level, such that the overall system performance degrades gracefully as components fail. This ensures the data center will continue to operate even while waiting for some containers to be replaced. The true end-of-life of the data center is likely to be driven by the underlying cooling infrastructure and the power delivery subsystems. These systems on the International Space Station have a design lifetime of 15 years26, and we expect a similar lifetime for orbital data centers. At end of life, the orbital data center may be salvaged27 to recover significant value of the hardware and raw materials, or all of the modules undocked and demised in the upper atmosphere by design.

    • self@awful.systemsEnglish
      0·
      3 months ago

      there’s so much wrong with this entire concept, but for some reason my brain keeps getting stuck on (and I might be showing my entire physics ass here so correct me if I’m wrong): isn’t it surprisingly hard to sink heat in space because convection doesn’t work like it does in an atmosphere and sometimes half of your orbital object will be exposed to incredibly intense sunlight? the whitepaper keeps acting like cooling all this computing shit will be easier in orbit and I feel like that’s very much not the case

      also, returning to a topic I can speak more confidently on: the fuck are they gonna do for a network backbone for these orbital hyperscale data centers? mesh networking with the implicit Kessler syndrome constellation of 1000 starlink-like satellites that’ll come with every deployment? two way laser comms with a ground station? both those things seem way too unreliable, low-bandwidth, and latency-prone to make a network backbone worth a damn. maybe they’ll just run fiber up there? you know, just run some fiber between your satellites in orbit and then drop a run onto the earth.

        • Soyweiser@awful.systemsEnglish
          1·
          3 months ago

          Easy, the cables go into the space elevator. Why do you all have to be so negative, don’t you have any vision for the future?

    • bitofhope@awful.systemsEnglish
      0·
      3 months ago

      Design principles for a time machine

      Yes, a real, proper time machine like in sci-fi movies. Yea I know how to build it, as this design principles document will demonstrate. Remember to credit me for my pioneering ideas when you build it, ok?

      1. Feasibility: if you want to build a time machine, you will have to build a time machine. Ideally, the design should break as few laws of physics as possible.
      2. Goodness: the machine should be functional, robust, and work correctly as much as necessary. Care should be taken to avoid defects in design and manufacturing. A good time machine is better than a bad time machine in some key aspects.
      3. Minimize downsides: the machine should not cause exessive harm to an unacceptable degree. Mainly, the costs should be kept low.
      4. Cool factor: is the RGB lighting craze still going? I dunno, flame decals or woodgrain finish would be pretty fun in a funny retro way.
      5. Incremental improvement: we might wanna start with a smaller and more limited time machine and then make them gradually bigger and better. I may or may not have gotten a college degree allowing me to make this mindblowing observation, but if I didn’t, I’ll make sure to spin it as me being just too damn smart and innovative for Harvard Business School.
      • Soyweiser@awful.systemsEnglish
        1·
        3 months ago

        You joke, but my startup is actually moving forward on this concept. We already made a prototype time travel machine which while only being able to travel forward does so at a promising stable speed (1). The advances we made have been described by the people on our team with theoretical degrees in physics as simply astonishing, and awe-inspiring. We are now in an attempt to raise money in a series B financing round, and our IPO is looking to be record breaking. Leave the past behind and look forward to the future, invest in our timetravel company xButterfly.