> The gh stack CLI handles the local workflow […]

That's not "how it works", that's "how you['re supposed to] use it"… for "how it works" I would've expected something like "the git branches are named foo1 foo2 and foo3 and we recognize that lorem ipsum dolor sit amet…"

…which, if you click the overview link, it says "The CLI is not required to use Stacked PRs — the underlying git operations are standard. But it makes the workflow simpler, and you can create Stacked PRs from the CLI instead of the UI." … erm … how about actually explaining what the git ops are? A link, maybe? Is it just the PRs having common history?

…ffs…

(In case it's not obvious: I couldn't care less for using a GH specific CLI tool.)

You or your subordinates target an elementary school: that's a war crime.

Your "battlefield AI" targets an elementary school: software bug, it happens, can't be helped.

That's absolutely not what happened in this case though; neither posts on Medium nor random preprints are reputed sources.

Which is exactly the problem here; it "used to be" that reasonable people would disbelieve random things they find on the internet at least to some degree. "Media literacy". LLMs don't seem to have that capability, and a good number of people are using LLMs in blissful ignorance of that fact. They very confidently exclaim things that make them sound like experts in the field at question.

Would it have made a difference for the AI data center heat island thing you're quoting? maybe not. But for medical matters? Most people wouldn't even have caught wind of this odd fake disease. LLMs just amplify it and serve it to everyone.

Meanwhile, LLMs are essentially internet regurgitation machines, because of course they are, that's what they do. Which makes them useless for getting "hard truth" answers especially in contested or specialized fields.

I'm honestly afraid of the impact of this. The internet has enough herd bullshit on it as it is. (e.g. antivaxxers, flat earthers, electrosensitivity, vitamin/supplement junk, etc.) We don't need that amplified.

it certainly has scale issues when you need to support larger deployments.

[P.S.: the way I understand the words, "shipping" means "passing it off to someone else, likely across org boundaries" whereas what you're doing I'd call "deploying"]

Other than that, both "python layer" and "over the ninja builder" are technically wrong. "python layer" is off since there is now a second implementation, Muon [https://muon.build/], in C. "over the ninja builder" is off since it can also use Visual Studio's build capabilities on Windows.

Interestingly, I'm unaware of other build-related systems that have multiple implementations, except Make (which is in fact part of the POSIX.1 standard.) Curious to know if there are any others.

e.g. from their docs:

  project('sdldemo', 'c',
          default_options: 'default_library=static')
  
  sdl2_dep = dependency('sdl2')
  sdl2_main_dep = dependency('sdl2main')
  
  executable('sdlprog', 'sdlprog.c',
             win_subsystem: 'windows',
             dependencies: [sdl2_dep, sdl2_main_dep])

Shipping anything built with -march=native is a horrible idea. Even on homogeneous targets like one of the clouds, you never know if they'll e.g. switch CPU vendors.

The correct thing to do is use microarch levels (e.g. x86-64-v2) or build fully generic if the target architecture doesn't have MA levels.

…now that I think about it, don't architects predominantly work in smaller companies?

/eot

It's a factor of RF bandwidth, time and space. With some non-obvious parts:

- setting your TX power too high makes you consume spectrum in a larger area, harming your neighbors. Don't yank the TX power to maximum just because it "feels" like that should be better; there is no difference between MCS (= speed/rate) 11 with 10 dBm headroom and MCS 11 with no headroom, you get ≈120Mbit either way.

- conversely, using old APs, devices, or stretching the wifi connection too far consumes excessive spectrum since you'll get a bad data rate and use much more time to convey the same data. Due to this, a repeater can in fact improve performance for devices not even using it, by getting rid of low-MCS traffic.

- don't use wide channels when you don't need the performance. A 160MHz channel means 160MHz width of picking up interference. While chipsets are somewhat intelligent about this, if you're fine with ≈200 Mbit (single MIMO stream) there's no point in going wider than 40 MHz.

- multicast is death. It's a very common wrong belief that wifi requires you to send multicast traffic at the lowest possible rate. It doesn't, but almost all low-end implementations are lazy and do just that. "Lowest possible" in this case means the lowest rate the BSS configured to support. If you have 802.11b enabled, that's generally 1 Mbit/s. Disable that, and you get the lowest 802.11n rate, which is ≈6.5 Mbit/s. If you need to deal with a lot of multicast, disabling some low MCS might also be worth it to raise that even further, but then those MCSes are not available to cover far-away devices anymore. But then again you may not want that to begin with (see above).

- it's highly dependent on building characteristics; thick stone/steel walls block much more RF energy than drywall or wood.

- if you can, just use cables. If it doesn't help you, it might still help your neighbors.

So… yeah, a lot of people consume media in the evening, and that does make it much worse.

P.S.: MCS indices: https://mcsindex.com/