I mean, even if just installing a different OS were an option, you’d need to install and setup that OS on a few hundred computers or more. I used to work for a place that would essentially do the enterprise enrollment in bulk before shipping off the computers to schools. I could only setup a bit under 100 over an 8 hour workday, assuming no major issues (like captchas on the login step, or the wifi going out). Keep in mind that we also had specialized little microcontroller* USBs specifically for doing all the enrollment keypresses, and enough of those for someone to setup multiple computers at once.
I am actually curious as to how you would make a locked down managed linux OS akin to ChromeOS. Maybe there would be a way to do something like that that’s also faster to setup, but idk.
That’s exactly the problem. The standard GNU/Linux distro isn’t suitable to allow carrying the responsibility that an innumerable number of users with physical access won’t be able to pwn those machines. Machines that are used by others too. You absolutely can make an OS like that out of Debian or Ubuntu, or what have you. Google has - Chrome OS - but it’ll take a significant development effort. You’d have to basically redo at least some of the work they’ve done. And let’s say you did all of that. Then you end up deploying it on an ARM-based fleet. And there’s a wild vulnerability in the WiFi firmware blob, and the SoC vendor no longer supports it. Every student has root and we’re back to the original problem. 👨🚀🔫
And that’s why instead of getting hardware from a vendor and hoping for the best, you might want to get it in writing that they’ll support their crap till a date. Then you stamp that as the EOL date for that laptop and you present it as part of the spec to whoever might want to buy this laptop. There’s no escaping this problem unless there are no proprietary blobs on the system, which is unlikely for ARM, or you have a solid development team and you’re large enough to have a source sharing contract with the vendor that lets your team fix the vulnerabilities and support the hardware for as long as you like. It’s probably much easier to achieve on x86, which costs more per unit up front.
Yeah, bulk imaging computers is really only limited to how many you can hook up to the network. I used to have to image hundreds of computers a day at times, and really the longest part was walking around and restarting them all so they’d PXE boot. The actual process maybe took 2 hours since all the computers were on 100Mb/s connections.
I mean, even if just installing a different OS were an option, you’d need to install and setup that OS on a few hundred computers or more. I used to work for a place that would essentially do the enterprise enrollment in bulk before shipping off the computers to schools. I could only setup a bit under 100 over an 8 hour workday, assuming no major issues (like captchas on the login step, or the wifi going out). Keep in mind that we also had specialized little microcontroller* USBs specifically for doing all the enrollment keypresses, and enough of those for someone to setup multiple computers at once.
I am actually curious as to how you would make a locked down managed linux OS akin to ChromeOS. Maybe there would be a way to do something like that that’s also faster to setup, but idk.
*centipedes are the name for the ones we used.
That’s exactly the problem. The standard GNU/Linux distro isn’t suitable to allow carrying the responsibility that an innumerable number of users with physical access won’t be able to pwn those machines. Machines that are used by others too. You absolutely can make an OS like that out of Debian or Ubuntu, or what have you. Google has - Chrome OS - but it’ll take a significant development effort. You’d have to basically redo at least some of the work they’ve done. And let’s say you did all of that. Then you end up deploying it on an ARM-based fleet. And there’s a wild vulnerability in the WiFi firmware blob, and the SoC vendor no longer supports it. Every student has root and we’re back to the original problem. 👨🚀🔫
And that’s why instead of getting hardware from a vendor and hoping for the best, you might want to get it in writing that they’ll support their crap till a date. Then you stamp that as the EOL date for that laptop and you present it as part of the spec to whoever might want to buy this laptop. There’s no escaping this problem unless there are no proprietary blobs on the system, which is unlikely for ARM, or you have a solid development team and you’re large enough to have a source sharing contract with the vendor that lets your team fix the vulnerabilities and support the hardware for as long as you like. It’s probably much easier to achieve on x86, which costs more per unit up front.
Thank you for sharing your experience along with that link.
Because Linus Torvalds stupidly refused to change the Linux license to GPL3.
What difference would the kernel licence make in this context?
Yeah, bulk imaging computers is really only limited to how many you can hook up to the network. I used to have to image hundreds of computers a day at times, and really the longest part was walking around and restarting them all so they’d PXE boot. The actual process maybe took 2 hours since all the computers were on 100Mb/s connections.