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.systems
    link
    fedilink
    English
    arrow-up
    14
    Ā·
    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.systems
      link
      fedilink
      English
      arrow-up
      17
      Ā·
      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.systems
          link
          fedilink
          English
          arrow-up
          8
          Ā·
          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?

          • self@awful.systems
            link
            fedilink
            English
            arrow-up
            5
            Ā·
            3 months ago

            what if my vision for the future is zeppelin data centers constantly hovering over the ocean? theyā€™ll have to be modular, of course, and we can scale our deployment by just parallel parking a new zeppelin next to our existing one and using grappling hooks and cargo straps to attach the zeppelins to each other. as you can clearly see, this will allow for exponential growth! and networking is as simple as Ethernet between the zeppelins and dropping an ocean-grade fiber cable off the first zeppelin and splicing that into an intercontinental backbone link. so much more practical than that orbiting data centers idea!

      • V0ldek@awful.systems
        link
        fedilink
        English
        arrow-up
        4
        Ā·
        3 months ago

        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

        ez

      • corbin@awful.systems
        link
        fedilink
        English
        arrow-up
        3
        Ā·
        3 months ago

        Youā€™re entirely right. Any sort of computation in space needs to be fluid-cooled or very sedate. Like, inside the ISS, think of the laptops as actively cooled by the central air system, with the local fan and heatsink merely connecting the laptop to air. Also, theyā€™re shielded by the ā€œskinā€ of the station, which youā€™d think is a given, but many spacebros think about unshielded electronics hanging out in the aether like itā€™s a nude beach or something.

        Iā€™d imagine that a serious datacenter in space would need to concentrate heat into some sort of battery rather than trying to radiate it off into space. Keep it in one spot, compress it with heat pumps, and extract another round of work from the heat differential. Maybe do it all again until the differential is small enough to safely radiate.

        • skillissuer@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          5
          Ā·
          3 months ago

          while radiating out waste heat at higher temp would be easier itā€™ll also take up valuable power, and either i donā€™t get something or youā€™re trying to break laws of thermodynamics

          • corbin@awful.systems
            link
            fedilink
            English
            arrow-up
            3
            Ā·
            3 months ago

            Iā€™m saying that we shouldnā€™t radiate if it would be expensive. Itā€™s not easy to force the heat out to the radiators; normally radiation only works because the radiator is more conductive than the rest of the system, and so it tends to pull heat from other components.

            We can set up massive convection currents in datacenters on Earth, using air as a fluid. I live in Oregon, where we have a high desert region which enables the following pattern: pull in cold dry air, add water to cool it further and make it more conductive, let it fall into cold rows and rise out of hot rows, condition again to recover water and energy, and exhaust back out to the desert. Apple and Meta have these in Prineville and Google has a campus in The Dalles. If you do the same thing in space, then you end up with a section of looped pipe that has fairly hot convective fluid inside. What to do with it?

            Iā€™m merely suggesting that we can reuse that concentrated heat, at reduced efficiency (not breaking thermodynamics), rather than spending extra effort pumping it outside. NASA mentions fluid loops in this catalogue of cooling options for cubesats and I can explain exactly what I mean with Figure 7.13. Note the blue-green transition from ā€œheatā€ to ā€œheat exchangerā€; thatā€™s a differential, and at the sorts of power requirements that a datacenter has, it may well be a significant amount of usable entropy.

            • skillissuer@discuss.tchncs.de
              link
              fedilink
              English
              arrow-up
              4
              Ā·
              edit-2
              3 months ago

              okay so you want to put bottoming cycle thermal powerplant on waste heat? am i getting that right?

              so now some of that heat is downgraded to lower temperature waste heat, which means you need bigger radiator. you get some extra power, but itā€™d be a miracle if itā€™s anything over 20%. also you need to carry big heat engine up there, and all the time you still have to disperse the same power because it gets put back into the same server racks. this is all conditional on how cold can you keep condenser, but itā€™s pointless for a different reason

              youā€™re not limited by input power (that much), youā€™re more limited by launch mass and for kilogram more solar panels will get you more power than heat engine + extra radiators. also this introduces lots of moving parts because itā€™d be stirling engine or something like that. also all that expensive silicon runs hot because otherwise you get dogshit efficiency, and thatā€™s probably not extra optimal for reliability. also you can probably get away with moving heat around with heat pipes, no moving parts involved

              also you lost me there:

              pull in cold dry air, add water to cool it further

              okay this works because water evaporates, cooling down air. this is what every cooling tower does

              make it more conductive

              no it doesnā€™t (but it doesnā€™t actually matter)

              condition again to recover water and energy

              and here you lost me. i donā€™t think you can recover water from there at all, and i donā€™t understand where temperature difference comes from. even if thereā€™s any, itā€™d be tiny and amount of energy recoverable would be purely ornamental. if i get it right, itā€™s just hot wet air being dumped outside, unless somehow server room runs at temperatures below ambient

              normally radiation only works because the radiator is more conductive than the rest of the system, and so it tends to pull heat from other components.

              also iā€™m pretty sure thatā€™s not how it works at all, where did you get it from

              • self@awful.systems
                link
                fedilink
                English
                arrow-up
                5
                Ā·
                3 months ago

                and Iā€™m over here like ā€œwhat if we just included a peltier elementā€¦ but biggerā€ and then the satellite comes out covered in noctua fans and RGB light strips

        • froztbyte@awful.systems
          link
          fedilink
          English
          arrow-up
          4
          Ā·
          3 months ago

          I was also momentarily nerdsniped earlier by looking up the capacity of space power tech[0] (panel yields, battery technology, power density references), but bailed early because itā€™ll actually need some proper spelunking. doubly so because Iā€™m not even nearly an expert on space shit

          in case anyone else wants to go dig through that, the idea: for compute you need power (duh). to have power you need to have a source of energy (duh). and for orbitals, youā€™re either going to be doing loops around the planetoid of your choice, or geostationery. given that youā€™re playing balancing jenga between at minimum weight, compute capacity, and solar yield, youā€™re probably going to end up with a design that preferences high-velocity orbitals that have a minimal amount of time in planetoid shadow, which to me implies high chargerate, extremely high cycle count ceiling (supercaps over batteries?), and whatever compute you can make fit and fly on that. combined with whatever the hell you need to do to fit your supposed computational models/delivery in that

          this is probably worth a really long essay, because which type of computing your supposed flying spacerack handles is going to be extremely selected by the above constraints. if you could even make your magical spacechip fucking exist in the first place, which is a whole other goddamn problem

          [0] - https://www.nasa.gov/smallsat-institute/sst-soa/power-subsystems/ (warning: this can make hours of your day disappear)

          • skillissuer@discuss.tchncs.de
            link
            fedilink
            English
            arrow-up
            5
            Ā·
            edit-2
            3 months ago

            dusk-dawn orbit is a thing if you donā€™t care too hard about where exactly to put it

            but itā€™s gonna be so fucking expensive, what theyā€™re trading off so itā€™s even remotely worth it? do they think itā€™s outside of any jurisdiction?

            • froztbyte@awful.systems
              link
              fedilink
              English
              arrow-up
              5
              Ā·
              3 months ago

              dusk-dawn orbit is a thing if you donā€™t care too hard about where exactly to put it

              yeah I thought about that but I took it in light of ā€œdata centerā€, i.e. presuming that youā€™d want continuous availability of that. part of what I mean with it being worth a long essay - thereā€™s a couple of ways to configure the hypothetical way this would operate, and each has significant impacts on the shape of the thing

              but itā€™s gonna be so fucking expensive

              yep. thatā€™s the thing thatā€™s so wild about this fairy picture. option 1) make your entire compute infra earthside[0], launch it all, and get ā€¦ the node compute equivalent of 3 stacked raspberry and a 2017 gpu, at a costpoint in the high 4 digits or moreā€¦ or option 2, where you just shove a dc full of equipment for the price of like 20 such nodes, and have the compute equivalent of a significant number of mid-range hosters

              even if (and this is extreme wand waving) you could crack non-planetbound production for the entire process and fab all this shit in space (incl. the mining and refining and ā€¦) as a way to reduce costs, you still have all these other problems too. and itā€™s not like this is likely to happen any time soon

              guess they better hope 'ole ray has another vision soon, to get a fixed date for the singularity. canā€™t see how you do your scrum planning for this fantasy without a target date provided by the singularitian prophet

                • froztbyte@awful.systems
                  link
                  fedilink
                  English
                  arrow-up
                  5
                  Ā·
                  3 months ago

                  dunno if the aforementioned jazz is (I didnā€™t check), but rayboi is the easiest ā€œand then compute things just become magically solvedā€ touchstone for me to remember

                  too many of the fucking nutjobs to properly track whoā€™s the steering committee for each insane idea

    • zogwarg@awful.systems
      link
      fedilink
      English
      arrow-up
      14
      Ā·
      3 months ago

      BasicStepsā„¢ for making cake:

      1. Shape: You should chose one of the shapes that a cake can be, it may not always be the same shape, depending on future taste and ease of eating.
      2. Freshness: You should use fresh ingredients, bar that you should choose ingredients that can keep a long time. You should aim for a cake you can eat in 24h, or a cake that you can keep at least 10 years.
      3. Busyness: Donā€™t add 100 ingredients to your cake thatā€™s too complicated, ideally you should have only 1 ingredient providing sweetness/saltyness/moisture.
      4. Mistakes: Donā€™t make mistakes that results in you cake tasting bad, thatā€™s a bad idea, if you MUST make mistakes make sure itā€™s the kind where you cake still tastes good.
      5. Scales: Make sure to measure how much ingredients your add to your cake, too much is a waste!

      Any further details are self-evident really.

      • Steve@awful.systems
        link
        fedilink
        English
        arrow-up
        11
        Ā·
        3 months ago

        if you MUST make mistakes make sure itā€™s the kind where you cake still tastes good

        every flat, sad looking chocolate cake Iā€™ve made

    • bitofhope@awful.systems
      link
      fedilink
      English
      arrow-up
      12
      Ā·
      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.
      • Steve@awful.systems
        link
        fedilink
        English
        arrow-up
        9
        Ā·
        3 months ago
        1. Safety: we need to make sure a fly isnā€™t inside, or canā€™t enter(!), the time machine while a human is inside during operation
        • self@awful.systems
          link
          fedilink
          English
          arrow-up
          8
          Ā·
          3 months ago
          1. Comfort: regardless of how big it is on the inside, shaping our time machine like a public telephone box introduces risk factors such as: someone will pee in there. according to my research, ideal ergonomics are achieved when the time machine is hot tub shaped.
      • Soyweiser@awful.systems
        link
        fedilink
        English
        arrow-up
        6
        Ā·
        edit-2
        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.

    • swlabr@awful.systems
      link
      fedilink
      English
      arrow-up
      11
      Ā·
      3 months ago

      Who knew that the VC industry and AI would produce the most boring science fiction worldbuilding we will ever see