The same way as, for instance, iOS. Using some proprietary developer toolkit that requires registering a developer account (which may cost money) in order to grant sideloading capability.

That's what I'm hoping will not be the case with the steam machines and I'm trying to find some empirical evidence of that. All I'm seeing so far is just a bunch of optimistic speculation.

People aren't outraged because all the rhetoric criticizing the surveillance programs was overblown. There are certainly plenty of things to be concerned about, sure. But just go read some news coverage from the time of the leaks and have a look at all the hyperbole and fear mongering. It was ridiculous.

If we want people to have a serious discussion about surveillance, then we need less fear mongering and more actionable activism. We need to get more organized and make specific proposals detailing what laws we would change and why it's so important to do so.

Instead of doing that, we just went on rants about how right we were the whole time and how evil it all is. We vomited vague, nonspecific emotion over the issue instead of proposing tangible solutions people could actually act on.

So yeah, no wonder everyone's suffering from "surveillance fatigue." I am too. And I actually care about the issue.

That's not proof. It's marketing. To my knowledge they haven't explicitly stated that sideloading will be permitted. You could make a (very good) argument that it's implied, but I'm seeking hard evidence.

We didn't get lucky. The vast majority of the surface of the Earth is either not populated or extremely sparsely populated. The odds are strongly against such a large airburst happening to burst over any reasonably densely populated area.

I hope you're right, but what you wrote is still just speculation. Not proof.

What worries me is that when this thing goes live, a whole lot of people who just assumed it's going to be a totally open platform are going to be disappointed when Steam imitates every other console gaming platform by disabling sideloading or making it prohibitively difficult for ordinary users.

Then cite a source proving it.

It's going to be a game console style user experience on top of PC hardware. There's no guarantee they won't do what literally every other game console does and disable sideloading. I'm trying to find real evidence that sideloading will be permitted. Otherwise I think the sensible if yes pessimistic assumption is to assume installing apps from outside of Steam will be disabled or at least prohibitively difficult for ordinary users.

Do you have hard evidence that stock Ubuntu with Steam installed is architecturally identical to SteamOS and that SteamOS will permit sideloading the same Ubuntu does, or are you just guessing based on their vague marketing pages?

Do you have hard information that SteamOS will permit sideloading or are you just assuming it will based on their vague marketing rhetoric?

You replied with a post that consisted of:

1. An insult.

2. No actual answer to my question about sideloading.

And someone modded you up.

Yep, that's Slashdot.

Is there any real evidence that steamOS will actually be truly open?

I know they advertised that the OS will be open source to some degree, but I haven't been able to dig up the details.

What worries me is this: if I can't sideload apps, install separate app stores, or root the system, then it's not truly open.

I'm worried steamOS will be as locked down to Steam as iOS is locked down to the iOS app store.

Is there evidence that steamOS will be more open than that?

Progressive enhancement has not at all been abandoned. The majority of frontend developers are constantly thinking about accessibility, usability, writing semantic markup and making simple enhancements with JS, that's the standard these days, you build sites that work on any device, at any resolution with and without javascript.

The majority? Where do you work? Can I get a job there? Most of the developers I've met in Silicon Valley either A. don't have those priorities or B. pay lip service to those priorities but don't implement them competently.

But the time where the web was just web pages is gone. You just cannot build an advanced web app without javascript, it's simply not feasible.

Not everybody wants the rich experience. In the vast majority of cases, providing a non-JS experience is not extra work if you're using best practices to begin with.

When I see things like this, I shake my head: http://dev.sencha.com/deploy/touch/examples/production/kitchensink/

Turn off JS on Sencha Touch's kitchen sink, see a blank screen.

And what for? None of that UI fundamentally requires JS to function. If they'd built it with progressive enhancement instead, the links would still work, just without the animations. The forms would still work, just without the fancy enhancements. But most importantly, the page would still fucking render.

You can differentiate the JS and non-JS experiences using the same URL endpoints by sending a special HTTP header to indicate that it's an AJAX request.

That can allow the server to send back a response without the header and footer if it's an AJAX request, or send a fully composed page if it's not.

Saying that the JS and non-JS experiences are "so totally different" is just an excuse people use to ignore the non-JS scenario.

I will concede that some webapps (particularly games) cannot be reasonably hybridized in this fashion, but I think most developers jump the gun in assuming too quickly that their app is too rich for progressive enhancement.

In my experience, the vast majority of webapp projects out there could be done with progressive enhancement without creating extra work, but as time goes on developers are less and less willing to even consider the idea.

The unstated premise in your comment assumes the web's current obsession with JSON. There's no reason your AJAX service can't respond with HTML instead. HTML is a data format just like JSON. If your HTML is semantic, then you can write it once and use it in both contexts. I do this all the time and I feel like some special enlightened snowflake who does twice the work for half the effort of most developers.

I miss the days when web developers still gave a shit about progressive enhancement.

I miss the days when you couldn't be considered a real web developer unless you could make a CSS Zen Garden (http://www.csszengarden.com) skin without cheating by changing the markup or using JS.

I miss the days when you were only considered a good web web developer if your site was usable with both JS and CSS disabled because you used semantic HTML.

I miss the days when accessibility still mattered.

I miss the days when writing semantic HTML, enhancing it with CSS, and enhancing it further with JS was considered the best practice, rather than starting with just JS and an empty body tag as is so common today.

I miss the days before the now popular false dichotomy of thinking that progressive enhancement is extra work was popular among web developers.

I love that the web can do more now and compete with native apps better. But I hate that web developers are so quick to unnecessarily abandon progressive enhancement in the process when that's what made the web great to begin with.