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 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 @fay too add an anecdote around this as well: the way I've seen a lot of local shops operate is closely similar (with "rent/lease-buy bunch of boxes" and "single pass refresh of bulk dells/similar" as other models)
at software level, disks with a CoW-style revert-changes-at-reboot operating style is somewhat-often seen. "a minion with more time than anything" is another common support approach. the latter is very much because of our fucked labour market
@glyph I don’t mean it as competition but you should go read about what some ZA schools deal with
It’s pretty grim :|
(and ofc there are places worse off; I’m just making this reference because it’s the one I know best)