Not to go all Ian Malcolm, but half this comment section is spending so much time wondering if we could build a space data center, without stopping to ask if it made any goddamn sense whatsoever to do so.
Heat travels when there is a thermal gradient. What thermally superconducting material are you going to make your cube out of that the surface temperature is exactly the same as the core temperature? If you don't have one, then to keep the h100 at 70c, the radiators have to be colder. How much more radiator area do you need then?
Have you considered the effects of insolation? Sunlight heats things too.
How efficient is your power supply and how much waste heat is generated delivering 1kW you your h100?
How do you move data between the ground and your satellite? How much power does that take?
If it's in LEO, how many thermal cycles can your h100 survive? If it's not in LEO, go back to the previous question and add an order of magnitude.
I could go on, but honestly those details - while individually solvable - don't matter because there is no world where you would not be better off taking the exact same h100 and installing it somewhere on the ground instead
Some of us are old enough to remember the last time Intel was definitely, 100%, for-sure committed to offering foundry services, and then changed their mind and canceled the whole thing (it was in 2018) and want to see (a) someone else have success with 18A first and (b) intel show an actual long-term commitment to using their foundry for outside customers before we risk our companies' future on them.
There are risks with TSMC, but "TSMC just decides it's not interested in making chips for other people, and cancels the whole business" isn't one of them. The same cannot be said for Intel.
If Intel decides they're not going to continue foundry services after 14A - you can just shift back to TSMC like everyone did between Samsung and TSMC?
"Just shift back" is really underestimating how much effort it takes to port a design to a different foundry. Sure, you can target a new stdcell library and recompile your RTL (and re-floorplan, and re-do a bunch of other stuff) but you also have to swap out all your memories and interfaces, not all of which may have exact equivalents... it can easily take 1+ years of work for a competent team, and if you have to shift back all that time and effort was wasted.
Seems most major players are not only fabless but also fab-agnostic - as I noted they switch from one supplier to another even for the same product line. I'm sure it is work but it doesn't seem to be an existential crisis for a huge provider to send some volume to a new fab - certainly if it's derisking supply capacity, tariffs or other geopolitical risks.
Big-endian matches the way we commonly write numbers, but if you have to deal with multiple word widths or greater than word-width math I find little-endian much more straightforward because LE has the invariant that bit value = 2^bit_index and byte value = 2^(8byte_index).
E.g. a 1 in bit 7 on a LE system always represnts 2^7 for 8/16/32/64/ whatever bit word widths.
This is emphatically not true in BE systems and as evidence I offer that IBM (natively BE), MIPS natively BE) and ARM (natively LE but with a BE mode) all have different mappings of bit and byte indices/lanes in larger word widths* while all LE systems assign the bit/byte lanes the same way.
Using the bit 7 example
- IBM 8-bit: bit 7 is in byte 0 and equal to 2^0
- IBM 16-bit: bit 7 is in byte o and equal to 2^8
- IBM 32-bit: bit 7 is in byte 0 and equal to 2^25
‐ MIPS 16-bit: bit 7 is in byte 1 and equal to 2^7
- MIPS 32-bit: bit 7 is in byte 3 and is equal to 2^7
- ARM 32-bit BE: bit 7 is in byte 0 and is equal to 2^31
Vs. every single LE system, regardless of word width
- bit N is in byte (N//8) and is equal to 2^N
(And of course none of these match how ethernet orders bits/bytes, but that's a different topic)
Not that it typically matters in a practical sense* (Unless you're writing to a register for a device)...
However I've always viewed Little Endian as 'bit 0' being on the left most / lowest part of the string of bits, but Big Endian 'bit 0' is all the way to the right / highest address of bits (but smallest order of power).
If encoding or decoding an analog value it makes sense to begin with the biggest bit first - but that mostly matters in a serial / output sense, not for machine word transfers which are (at least in that era were) parallel (today, of course, we have multiple high speed serial links between most chips, sometimes in parallel for wide paths).
Aside from the reduced complexity of aligned only access, forcing the bus to a machine word naturally also aligns / packs fractions of that word on RISC systems, which tended to be the big endian systems.
From that logical perspective it might even make sense to think of the RAM not in units of bytes but rather in units of whole machine words, which might be partly accessed by a fractional value.
That's correct, the Romans had March as the first month of the year, so leap day was the last day of the year and September, October, November and December were the 7th (sept), 8th (oct), ninth (nov) and 10th (dec) months.
I'd expect the loss coefficient (tan d) to be terrible. Cellulosics hold onto water quite well. You will not have a good time pushing anything high-speed through this kind of board.
I would say the only practical application would be disposable things like PCBs in single-use vape pens. (Which are pretty environmentally offensive on other levels anyway.)
cable companies require poe filters. if they find that there is some "noise" leaking from your house, they may put a big filter of their own outside, that can degrade speed of modem
reply