Potential customers for this fall into a few categories, including:
1. Parents who don't know a lot about tech, but whose kids need "a laptop" for school.
2. Kids & young adults who want a macbook to run something like GarageBand but have a very limited budget *and* also don't otherwise know much about tech.
3. Schools.
4. School-like programs, like software dev clubs & summer camps.
These customer types need a low price, but they also need A LOT of *support*. The support is the product here.
Yes, you could personally get a more powerful computer by getting a refurb 16GB M1 MacBook Air somewhere by bargain hunting. But you will need to hunt; right now on the official refurb store the cheapest MacBook Air is $929. If you're shopping on eBay, now you've got a machine with a ton of wear cycles on the SSD, and dubious amounts of damage.
If you, personally, have the time & energy for that, it *IS* a better choice.
So, back to the MacBook Neo and why it is interesting.
If you're reading this, you probably shouldn't buy it. But you should be aware that so many people *are* going to buy it, that it's going to set a consistent new minimum standard for software. For one thing, lots of apps are going to want to start targeting "fits into a MacBook Neo's memory envelope", which is to say, 8GB minus macOS overhead. Cheap hardware exists now, but not enough of it deployed consistently enough for app devs to care.
@glyph @thomasdorr 😂 same! That’s why I only pasted a screenshot. 😂
I guess I am old enough to have attempted to administer machines running this software that shall not be named 😭
The bigger risk is that some school districts may buy these for kids, and then lock them down in the name of child safety, eliminating the possibility of discovery and curiosity.
@glyph In both cases, something like these:
They were provisioned with DeployStudio (RIP), and later Munki with a ton of custom packages. Student logins were provisioned as needed. No Active Directory or anything.
@glyph It very depends. You need a lot of things in place to make this work. First and foremost, a faculty willing to give it a go. If the machines can't easily do what students and teachers need, that's the ballgame. Forget your principles for a second. If the damned things can't print or run the necessary apps, you're donezo with the experiment (and probably looking for a new job).
But if there is an appetite, then you want to lean into it as much as possible. I never got to go as far as Charlie Reisinger did, but that was always the goal.
But yeah everything must proceed first from curriculum. What the students need should drive tech decisions, not whatever flights of fancy the IT department might have. And that gets complicated, because you'll have some folks claim that proprietary applications are necessary for "preparation." And of course there are some testing regimes that require specific OSes to function. Chromebooks have obviated that somewhat, but it's still true to some degree.
But if all that comes together, I would first explore identity management, followed by provisioning by Ansible or Puppet, followed by Wireguard-enabled networking for always-available resources and support.

@glyph There's a potential future after the AI bubble pop that leads to some RETVRN action and a focus on fundamentals. It's by no means guaranteed.
I'm kind of thinking of my role as keeping the fires of knowledge lit while we endure an age in which people would rather not know how things work.
@mttaggart that's probably a good way to think about weathering the current storm, yeah, on multiple axes.
but speaking of 2014, man, being under 40 was also cool. wonder if we could bring that back too
@theorangetheme @glyph It was very popular in my Catholic all boys prep school.
I tend to reach for "Foundation" for this metaphor, but I getcha.
@glyph I read through this thread and I do want to highlight that it is _extremely_ US/affluence-coded, even as I suspect that may not have been your intention
while I follow the majority of your argument, I think it would fall apart quite rapidly outside of some specific locales simply on economic terms. I don’t see it flying in e.g. ZA, much less any number of other countries (KE/NG/ID/IN/etc)
@glyph Also I pick up a trace of geologist-xkcd here? I’m not coming swinging: I think your theses about fleet management are directionally accurate (certainly as a thing to want), but I don’t know if it holds up in as many places. I have seen maaaaaaaaaaaany places that trade human labour for MDM, and don’t think that’s about to stop any time soon
Also, idly: I had *absolutely* no idea about those free training supports. And I’ve looked into this before! Quite surprised
@glyph They’d have to sell it at 40~50% of (indicated US) price[0] to even get any takers, I think. And unless they could do critical mass in low weeks, I suspect may also run into major theft problems
Over and above that, connectivity and software demands also stand a strong chance to just completely exclude it as a contender, from early in eval
[0] apple shit is much more expensive here, because of Core Group (importer with weird rights; we don’t have Apple here Officially)
RE: https://mastodon.social/@glyph/116234465610992425
@froztbyte the subthread that ends here covers the "devs need to use these to optimize" thing, which I think is just straightforwardly false
@glyph I agree on the former, but disagree on the latter (although perhaps in a matter of quibbling on details)
To pick an obvious and easy example: js-world stuff, which is an ocean of waste. If they actually had to care about download time (or even better, *cost*), you’d see some bundle optimisation and improvements within days!
Dev culture is steered from the top, but also afforded shape by environmental pressures. I argue you need to account for both
@glyph A secondary part to my argument is perhaps a bit reductionist: _why_ would it make them less productive? If it’s because they can’t run their 24GB stack with 3 replicas locally all at once, I’m actually gonna say “tooling failure” tbh
In a world with people drooling about k8s & hyperscaler instances everywhere, scratch space is easy. Don’t want to incur costs (I often don’t, and rage against their prices), k3s et al exist too. Ergonomics suck? Tooling failure!
Also to blame: monoculture
@glyph the 24GB value specifically was said partly in jest, but please remember that I _do_ in fact know this space about as well as you do :)
in recent years I've gone down the rabbithole of android and some webshit: it *can* be slimmed down quite a bit, I *have* done this on a number of toolchains/builds
I still don't think there's a strong argument for "local GUI VM" that isn't as easily answered by "remote GUI VM", especially for web-class shit. doubly so on other resource use
@glyph yes I've seen this before, and I know a bit about your workflow (ito what you've posted about it before, as well as what you've debugged with it)
(one of those differences is that my style is very explicitly almost the direct and quite possibly extreme opposite of that - I make disposable VMs so heavily they're like mayflies)
@glyph I have really wanted to, but time-wise it simply hasn't been a good reality the last couple of years (for life reasons)
a co-hack session of some stuff might one day be an interesting experiment, because I think we come at similar targets from workstyles that differ in some interestingly notable ways
@glyph true, but I think the iOS precedence does make it more likely.
If I were working at Apple in a leadership position and involved in this project, this would be the first step in a 20 year plan to take large market share from Windows. So it'd be pointless to kneecap the Neo; you'd want it work as well as it can so as people need more power they're happy to pay more b/c of the trust established