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.

I've been enjoying Moat [1]. Proxies credentials, networking, etc; uses MacOS containers if available; and setup worked without much fuss. I haven't tried others, though.

[1] https://majorcontext.com/moat/

    > 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

Because the repo includes the tool authored for, and discussed in, the "blog"?

Could a supply chain attacker simulate an advisory-remediating release somehow, i.e., abuse this feature to bypass cooldowns?

Yes, seeing periodic 5xx errors (though eventually succeeds).

Interestingly `bun upgrade` catches "GitHubIsDown" as a specific case:

    $ bun upgrade
    Bun v1.2.20 is out! You're on v1.2.18
    Downloading [38003/21788202] Bun upgrade failed with error: GitHubIsDown
    
    Please upgrade manually:
      curl -fsSL https://bun.sh/install | bash

(Appears to have been triggered by a 503 for https://github.com/oven-sh/bun/releases/download/bun-v1.2.20...)

Right, but, they never owned it, and would never attempt to assert that. So in hindsight (and similar to GP) compliance was a worse and more frustrating option than simply never mentioning things.

Ugh, you gave me bad flashbacks of the same committee.

I tried to re-license a previously-released project (like from GPL to MIT or similar) and they wouldn't budge. I had written all the code.

In the end, I decided that them suing (or firing) me to assert their ownership of $VALUELESS_PROJECT, so they could then license it back, was ridiculously unlikely, said fuck it, and did it. And I was right.

A very well-written and persuasive critique, thank you for it.

(And god I hope you’re not a state-of-the-art summarization LLM.)

Thought this was going to be an mmWave sensor with an "AirBnB host friendly" UI of some sort.. turns out it's just a network sniffer? Seems.. defeatable.

    > How it Works
    > 
    > Party Squasher uses the presence of mobile phones
    > as a proxy for the presence of people.  You start by
    > connecting our small sensor to your property’s internet
    > router. [...]

I've been interested in doing this as a side project too, ever since "unwiring" my jeep in a similar fashion (rip out modem).

My quick-and-dirty idea was to stand up a Discourse forum with categories for each make, threads for each model (or possibly model + model year range pairs).

If anyone wants to collaborate / provide some extra motivation, hit me up..

I refer back to your exact blog post every 6 months or so to see how (or if) its various issues have been smoothed out, and whether I should recommend it in a new build. Thanks much for keeping your post up-to-date!

0.5% -> 0.7% = 40% increase in fees, for affected customers.

(edit: 0.7% not 0.8%)

In case you're interested, there's a fascinating recent book about the effects roads & road development have on their surroundings (and the planet at large): _Crossings_ by Ben Goldfarb [1]

[1] https://www.bengoldfarb.com/crossings

Lovely read, and great to see a happy ending - I remember your previous blogs here.

As a sometime-bootstrapper and having failed at a previous hardware startup, I can relate to many of the emotions you narrated through. It may be too early, but my biggest curiosity is whether you think you will bootstrap something again?

(In my case, after the hardware business and some time off, I found that taking a swing at a “pure software” idea was the right balance for me, after the considerable challenges and occasional joys of building physical things..)

Nice list, found a couple projects I hadn't seen before.

My addition for your consideration: https://github.com/mik3y/django-spicy-id

I just made up `blogger.com` as an example. I probably could have picked a better one. `blogspot.com` & its many TLD variations are on the list.

It looks like the repo where the list is maintained [1] is pretty active. YMMV, I'm not a maintainer or anything..

[1] https://github.com/publicsuffix/list