> Nobody wants to work on hobby projects that have no chance of ever running on real hardware.
I never said hobbyist OS projects won't run on real hardware; I said running on real hardware is a "1.0 feature." Which is to say, around the 0.9, you start taking some real test machines, disabling their boot protections, and putting your OS on them. You get it polished.
And then, only after that, you go and apply for a boot-signing certificate from the hardware makers. Which, because you now have a real, polished OS instead of a hobbyist project, they will give you. It's sensible enough: if they gave a cert to every hobbyist developer, one of them might just be a virus-writer; but there are only so many groups who actually end up with real, working, polished Operating Systems that Users will want to run. And it's easy enough to tell when a group has made one of those, and to sign their bootloader.
This is, if you'll note, pretty much the same logic behind the iOS development workflow. First, you deploy to test devices that are specifically configured with an "I am an Administrator, obey me" flag. Then, once you've proven out your software on those devices, you get it signed with a "this is allowed to run on regular User PCs" cert.
---
Also: if a "toy shell in Javascript" can both connect to the network, and use the browser's Javascript data-storage APIs to store data, then what makes it incapable of getting Real Work done? It's basically a (really slow) VM.
So what happens if the people in charge of giving certificates, approving marketplace apps, etc. decide they don't like me and give me the boot even if my product is perfectly fine? They're human, and humans screw each other for petty reasons and out of self interest all the time.
If someone buys a computer, why do there have to be barriers from getting and using software directly from the developer? This has everything to do with milking money from developers and making users' alternative choices as difficult and unpractical as possible. It's discouraging choice and diversity.
--
> Also: if a "toy shell in Javascript" can both connect to the network, and use the browser's Javascript data-storage APIs to store data, then what makes it incapable of getting Real Work done? It's basically a (really slow) VM.
So who wants to play with "basically a (really slow) VM"? Why should hobbyist developers be content with only having access to second rate capabilities? No thank you.
> So what happens if the people in charge of giving certificates ... decide they don't like me
Then the developers get angry and throw out the people in charge. Imagine, for example, what would happen if IANA arbitrarily stopped just a few people from getting domain names. We'd get a new IANA. (We can't do this with the "apps marketplace" vendors, though, and that is a problem. It's probably something that should be solved with an anti-trust suit or two.)
> If someone buys a computer, why do there have to be barriers from getting and using software directly from the developer?
Because--and this is the whole point of the Users/Administrators distinction--Users don't know enough about computers to distrust malicious software.
We put barriers between people and phishing sites, so they can't be tricked into giving their money away. We put barriers between children and in-app purchases, because they don't understand the consequences.
This is the same idea. Most people would go through whatever series of scary dialog boxes it took to run "cat_videos.exe". If you, an Administrator, were standing right there beside them, you'd grab the mouse from their hand and stop them, for their own good. We can't be there all the time. We want the OS to grab the mouse from their hand for their own good.
> Users don't know enough about computers to distrust malicious software.
Then the solution is to educate them, not mollycoddle them and keep them locked up. But knowledge is power, and educated users are difficult to control and deceive, so the "developers", the ones who want to remain in control, don't want that happening.
> We put barriers between people and phishing sites, so they can't be tricked into giving their money away.
The same people who would then fall for a different scam, before even more barriers are erected, and would think "security software X doesn't think this is a phishing site, so it must be safe."
> We put barriers between children and in-app purchases, because they don't understand the consequences.
A "think of the children" argument? I agree a lot of young ones haven't developed to that point yet, but if you make it so they never experience any bad consequences, they'll never learn from them too.
> If you, an Administrator, were standing right there beside them, you'd grab the mouse from their hand and stop them, for their own good.
No, I'd just tell them "you're very likely not going to like the outcome, but the ultimate choice is yours."
"We do not truly have freedom if we do not have the freedom to make the wrong choices."
> We want the OS to grab the mouse from their hand for their own good.
Solutions which protect the user from cat_videos.exe can also "protect" them from subversive_essay.pdf (or competitor.com). It's maybe not that practical a vector, at least where there's democracy and competition, but still something to consider.
> Then the developers get angry and throw out the people in charge.
The developers aren't the ones giving these companies money. The users are. The developers aren't their customers. The users are. The developers have little power to "throw out the people in charge" as long as the users keep giving the companies money.
I never said hobbyist OS projects won't run on real hardware; I said running on real hardware is a "1.0 feature." Which is to say, around the 0.9, you start taking some real test machines, disabling their boot protections, and putting your OS on them. You get it polished.
And then, only after that, you go and apply for a boot-signing certificate from the hardware makers. Which, because you now have a real, polished OS instead of a hobbyist project, they will give you. It's sensible enough: if they gave a cert to every hobbyist developer, one of them might just be a virus-writer; but there are only so many groups who actually end up with real, working, polished Operating Systems that Users will want to run. And it's easy enough to tell when a group has made one of those, and to sign their bootloader.
This is, if you'll note, pretty much the same logic behind the iOS development workflow. First, you deploy to test devices that are specifically configured with an "I am an Administrator, obey me" flag. Then, once you've proven out your software on those devices, you get it signed with a "this is allowed to run on regular User PCs" cert.
---
Also: if a "toy shell in Javascript" can both connect to the network, and use the browser's Javascript data-storage APIs to store data, then what makes it incapable of getting Real Work done? It's basically a (really slow) VM.