mik3y

Yes! In fact..

The first version of Google TV, an internal demo, was based on MythTV. We had MythTV running against some HDHomeRun tuners, then a transparent webview (a fork of Petit Four-era Android builds since it had great d-pad nav support) running on top of it.

"Apps" were pure JavaScript gadgets, inspired by iGoogle, with custom DOM methods for anything TV-specific: channel changes, tuning info, and so on. With the MythTV demo, we managed to make some pretty fun hybrid apps that did things like pull up related stories about the TV show you were watching (maybe sounds lame now but was kinda cool seeing it for the first time: an iframe over my TV show, holy shit what can't I do with this). Adware was never discussed; we wanted to be a free and hackable OS for the living room.

After heading in this "widgets" direction for about a year, Android had been released and we strongly believed in a strategy based on it, so made the pivot. It was pretty tough, and educational, trying to build consumer products at Google in this era and without any singular unifying vision across the company. I longed for a top-down dictator like Steve Jobs who could cut the crap.. (even if we were judged to be the crap!)

I'm guessing the ad-infested OS from OP has some lineage back to the original Google TV, but of course I'm sure it's barely recognizable now.

I strongly agree with this take. And in particular, I've been wondering about this:

    > Individuals work with agents to produce changes independently, 
    > each operating a small software factory.
    >
    > [...] together they start to resemble Frankenstein’s monster
    > rather than a carefully shaped sculpture.

Do solo developers consequently have a bit of an advantage today when it comes to producing tasteful, opinionated software?

I had a very similar single experience with Om: I was introduced completely randomly while he was at True Ventures; he couldn't have been nicer, more curious, or more genuine despite me almost certainly reading like a total waste of time.

It's both heartwarming, and bitterly sad, to see so many other posters confirm he was one of the good ones.

Layoff announcements are this kinda tricky class of corporate comms where you need to speak to at least 3 different constituents, with 3 different messages, which are often in conflict.

It's something like:

(A) To the public (e.g. prospects, customers, investors): "This is a good thing and we're going to be an even better bet!"

(B) To the remaining team: "This is tough and I feel your pain and will do better."

(C) To the laid off: "It's not you, it's me, thank you and good luck."

It's hard if not impossible to handle all three of these authentically, concisely, and in the same message. Which is why you can almost immediately find something not to like..

Sure: I think you're essentially missing a whole set of concerns - ones that are not purely technical - behind why this method is popular; and so your arguments wouldn't convince someone actually responsible for one of these scripts to change or cease the practice.

Nobody would argue that it's categorically safe/good/smart to blindly pipe a script into your shell; and for the record, I agree. I would also readily agree that habituating users to doing this probably creates new, more general risks especially among how less-technical users interact with their CLI.

However, the realities of the "real world" make it popular for a reason, in light of those negatives; tons of scaled projects continue to offer a 1-liner. So we have to ask, why? They'd probably say that's because it (a) improves project adoption, and (b) reduces "install broken" tickets.

You have to address the non-technical merits and goals to get behavior to change here, and sadly, I don't think anyone has done that.

But who cares about me? I'm not currently maintaining one of these (though I did once). My suggestion to bring your argument to an active project was genuine: try it! I'd be delighted to see you bring about the change you want.

[PS: The commenter I replied to originally used the term "bad faith", which they've since edited]

Bad faith, or perhaps just ignorance. It reminds me of purist junior engineers - and I have been one - refusing to understand or tradeoff in the world beyond their own.

Rather than argue with those of us who are pointing out messy realities, this commenter might be better served filing a bug against any number of the projects that offer installation this way, asking them to remove it, and see if it lands any better.

Technical purity/superiority isn’t the only factor, or even the most important one, driving projects to offer quick installers like this.

The ideas aren't mutually exclusive, and I've never seen an open source project support "curl | sh" without also supporting those methods.

Indeed, plenty of these scripts often act as a "what OS and packager do we have" mux. Just look at the source of this one, for example.

When you support an open source project at scale and/or with less savvy users, you come to see the benefit of "here, just f'ing slam this into your shell and we'll figure it out" installers. I know I have.

I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world. Homebrew, to name just one example, advertises a similar method.

(pi.sh also documents other install methods, like `npm`, on their homepage)

If trust and security is the issue, unfortunately "better" ideas like hashpipe [1] never achieved critical mass

    [1] https://news.ycombinator.com/item?id=9318286

I really wanted to dislike the anonymous operator for the careless project (and the hilarious pomposity of the IRC subagent it spawned).

Then I imagined the real-but-unknowable chance it was all set up by some kid just getting into computers, just seeing what’s possible, getting excited by a much bigger world at reach — and remembered my own expensive mistakes with long-distance BBSes & the like.

I sorta hope for that, anyway. Curiosity is a beautiful thing.

    > How could it be better?

On a purely language basis, I'd start with the things the BrighterScript [1] folks have done to clean up the warts and inconveniences of the language.

Personally I'd rather it not exist. Roku would be more pleasant to develop on had they chosen a more popular, existing language as the basis (e.g. Python). Then the task of developing for the platform ~mostly reduces from "learn a new language and a new framework" to just the latter.

I suppose it hasn't inhibited their success, of course.

    [1] https://github.com/rokucommunity/brighterscript