[my-boot]

Unfortunately, Apple seems to be alone in having a good implementation. Using the old PXE, you expect to see some dos-like screens and slow loading but with HTTP the experience is not much better. Any decently sized bootloader is downloaded at a snails-pace and the user is presented with a very technical screen. Fine for rescue-boot like purposes but not fine when your daily driver is expected to be booted from network. I had especially expected better from Dell but the experience is... lacking.

[mschuster91]

> Unfortunately, Apple seems to be alone in having a good implementation.

Well, Apple is in full control over their entire stack, down to the firmware on the embedded parts.

In the non-Apple world, no way, simply due to the sheer insane amount of different ethernet and wireless chipsets, with many of them shipping binary blobs. The mediatek blobs alone expand to 64MB [1], Intel clocks in a further 24 MB [2], and then there's all the other firmware stuff.

Unfortunately, there is nothing in the "physical world" that comes even close to USB-CDC in its versatility.

[1] https://packages.debian.org/forky/firmware-mediatek

[2] https://packages.debian.org/forky/firmware-intel-misc

[xxpor]

I'd guess that the mediatek blobs are exactly 64k, and mostly 0s?

[naikrovek]

> slow loading

Not necessarily. When I worked at Yahoo, in Australia (what a glorious time that was) 25 years ago, I built servers in the datacenter using PXE. It was anything but slow.

Unbox a server, plug it into the PXE network, boot it. It boots to a miniscule FreeBSD distribution and you use a common user/pass to log in. Then, you type clone -h <fqdn> and it mounted an NFS share and installed packages and config files for that hostname. In three minutes or so your server shut down and you racked it up, plugged it into the production network and it started accepting work, or it notified the engineers in the US that it was ready for use and they’d add it to a pool, then it would start handling work.

It was extremely slick.

The build network was secure because you could only access it in secure areas which had the build network and a build server deployed to it. So security was not a problem.

Why can’t I set up Windows or MacOS like that? I know the answer I just find the answer annoying.

[RulerOf]

> Why can’t I set up Windows or MacOS like that? I know the answer I just find the answer annoying.

I wish I still cared about this. I had intended to build an iPXE boot menu via a small web service that would act as a windows install XML template editor/selector, but I never got around to doing it after learning enough web dev to pull it off.

I built a few similar things that worked inside of WinPE, but the slowness of waiting for it to boot was always what drove me to do as much config as possible in the PXE boot menu—you can get into that in seconds versus minutes for the PE.

I used to install Windows a lot, and found a lot of tech around it to be a little too opinionated. SMS/WDS were just too legacy-leaning and Microsoft Enterprise-flavored. FOG was a little too heavy-handed (though very good). Glazier excited me but I never actually used it to determine if it has the flexibility I wanted...

But I digress. OS installs should be a lot easier and faster to accept your configuration preferences and get to work when the goal is "erase this machine and reinstall" than they are even today.

[marysol5]

Built out a (i)PXE build system for Windows at an /old job/

It would chain load the iPXE binary from the network, then call out to a HTTP end-point with "?mac={macaddress}" so we could identify it. Then it would auto-pull from git, or generate (and push into git) a config, which would load the WinPE image over the network, and launch a powershell script. All of which would talk back to the HTTP endpoint throughout.

Because we tracked it all with a Slackbot on every execution.

Fun hack, certutil.exe has the ability to do HTTP/S requests, so we would leverage that to "live off the land", even though we could integrate any binary into the image outselves.