6 ms·

This isn't a web development concept. It's the unix philosophy of "write programs that do one thing and do it well" and interconnect them, being taken to the ex

by lijok 6mo ago

This isn't a web development concept. It's the unix philosophy of "write programs that do one thing and do it well" and interconnect them, being taken to the extremes that were never intended. We need a different hosting model.

slopinthebag 6mo ago
In my mind the unix philosophy leads to running your cloud on your own hardware or VPS's, not this.
- bdangubic 6mo ago
  exactly this, write - not use some sh*t written by some dude from Akron OH 2 years ago”
  - arcfour 6mo ago
    That's why I wrote my own compiler and coreutils. Can't trust some shit written by GNU developers 30 years ago. And my own kernel. Can't trust some shit written by a Finnish dude 30 years ago. And my own UEFI firmware. Definitely can't trust some shit written by my hardware vendor ever.
    - DASD 6mo ago
      TempleOS, is that you?
    - slopinthebag 6mo ago
      Yeah definitely no difference between GNU coreutils and some vibe coded AI tool released last month that wants full oAuth permissions.
      - arcfour 6mo ago
        Embrace the suck.
      - eddythompson80 6mo ago
        I’m not joking, but weirdly enough, that’s what most AI arguments boil down to. Show me what the difference is while I pull up the endless CVE list of which ever coreutils package you had in mind. It’s a frustrating argument because you know that authors of coreutils-like packages had intentionality in their work, while an LLM has no such thing. Yet at the end, security vulnerabilities are abundant in both. The AI maximalists would argue that the only way is through more AI. Vibe code the app, then ask an LLM to security review it, then vibe code the security fixes, then ask the LLM to review the fixes and app again, rinse and repeat in an endless loop. Same with regressions, performance, features, etc. stick the LLM in endless loops for every vertical you care about. Pointing to failed experiments like the browser or compiler ones somehow don’t seem to deter AI maximalists. They would simply claim they needed better models/skills/harness/tools/etc. the goalpost is always one foot away.
        arcfour 6mo ago
        I wouldn't describe myself as an AI maximalist at all. I just don't believe the false dichotomy of you either produce "vulnerable vibe coded AI slop running on a managed service" or "pure handcrafted code running on a self hosted service." You can write good and bad code with and without AI, on a managed service, self-hosted, or something in between. And the comment I was replying to said something about not trusting something written in Akron, OH 2 years ago, which makes no sense and is barely an argument, and I was mostly pointing out how silly that comment sounds.
        eddythompson80 6mo ago
        I used to believe that too, yet the dichotomy is what’s being pushed by what I called an “AI maximalist” and it’s what I was pushing against. There is no “I wrote this code with some AI assistance” when you’re sending 2k line change PR after 8 minutes of me giving you permission on the repo. That’s the type of shit I’m dealing with and management is ecstatic at the pace and progress and the person just looks at you and say “anything in particular that’s wrong or needs changing? I’m just asking for a review and feedback”
        slopinthebag 6mo ago
      - brookst 6mo ago
        So it’s not a binary thing, there’s context and nuance?
    - steve1977 6mo ago
      cue Jeopardy theme song Who is Apple?
esseph 6mo ago
> We need a different hosting model. There really isn't an option here, IMO. 1. Somebody does it 2. You do it Much happier doing it myself tbh.
- fragmede 6mo ago
  There's a lot of wiggle room on how you define "it". At the ends of the spectrum it's obvious, but in the middle it gets a bit sticky.
0xbadcafebee 6mo ago
It's not a hosting model, it's a fundamental failure of software design and systems engineering/architecture. Imagine if cars were developed like websites, with your brakes depending on a live connection to a 3rd party plugin on a website. Insanity, right? But not for web businesses people depend on for privacy, security, finances, transportation, healthcare, etc. When the company's brakes go out today, we all just shrug, watch the car crash, then pick up the pieces and continue like it's normal. I have yet to hear a single CEO issue an ultimatum that the OWASP Top 10 (just an example) will be prevented by X date. Because they don't really care. They'll only lose a few customers and everyone else will shrug and keep using them. If we vote with our dollars, we've voted to let it continue.
pianopatrick 6mo ago
Just throwing it out there - the Unix way to write software is often revered. But ideas about how to write software that came from the 1970s at Bell Labs might not be the best ideas for writing software for the modern web. Instead of "programs that do one thing and do it well", "write programs which are designed to be used together" and "write programs to handle text streams", I might go with a foundational philosophy like "write programs that are do not trust the user or the admin" because in applications connected to the internet, both groups often make mistakes or are malicious. Also something like "write programs that are strict on which inputs they accept" because a lot of input is malicious.
- deleted 6mo ago
  [deleted]
- mpyne 6mo ago
  The Unix model wasn't simply do one thing and do it well. It was also a different model on ownership and vetting of those focused tools. It might have been a model of having the single source tree of an old UNIX or BSD, where everything was managed as a coherent whole from grep to cc all the way to X11. Or it might have been the Linux distribution model of having dedicated packagers do the vetting to piecemeal packages into more of a bazaar, even going so far as to rip scripting language bundles into their component pieces as for Python and Perl. But in both of those models you were put farther away from the third-party authors bringing software into the open-source (and proprietary) supply chains. This led to a host of issues with getting new software to users and with a fractal explosion of different versions of software dependencies to potentially have to work around, which is one reason we saw the explosion of NPM and Cargo and the like. Especially once Docker made it easy to go straight from stitching an app together with NPM on your local dev seat to getting it deployed to prod. But the issue isn't with focused tooling as much as it is with hewing more closely to the upstream who could potentially be subverted in a supply chain attack. After all, it's not as if people never tried to do this with Linux distros (or even the Linux kernel itself -- see for instance https://linux.slashdot.org/story/03/11/06/058249/linux-kernel-back-door-hack-attempt-discovered https://linux.slashdot.org/story/03/11/06/058249/linux-kerne... ). But the inherent delay and indirection in that model helped make it less of a serious risk. But even if you only use 1 NPM package instead of 100, if it's a big enough package you can assume it's going to be a large target for attacks.
steve1977 6mo ago
I guess we failed at the "do it well" step.

by lijok 6mo ago

slopinthebag 6mo ago

In my mind the unix philosophy leads to running your cloud on your own hardware or VPS's, not this.

bdangubic 6mo ago
exactly this, write - not use some sh*t written by some dude from Akron OH 2 years ago”
- arcfour 6mo ago
  That's why I wrote my own compiler and coreutils. Can't trust some shit written by GNU developers 30 years ago. And my own kernel. Can't trust some shit written by a Finnish dude 30 years ago. And my own UEFI firmware. Definitely can't trust some shit written by my hardware vendor ever.
  - DASD 6mo ago
    TempleOS, is that you?
  - slopinthebag 6mo ago
    Yeah definitely no difference between GNU coreutils and some vibe coded AI tool released last month that wants full oAuth permissions.
    - arcfour 6mo ago
      Embrace the suck.
    - eddythompson80 6mo ago
      I’m not joking, but weirdly enough, that’s what most AI arguments boil down to. Show me what the difference is while I pull up the endless CVE list of which ever coreutils package you had in mind. It’s a frustrating argument because you know that authors of coreutils-like packages had intentionality in their work, while an LLM has no such thing. Yet at the end, security vulnerabilities are abundant in both. The AI maximalists would argue that the only way is through more AI. Vibe code the app, then ask an LLM to security review it, then vibe code the security fixes, then ask the LLM to review the fixes and app again, rinse and repeat in an endless loop. Same with regressions, performance, features, etc. stick the LLM in endless loops for every vertical you care about. Pointing to failed experiments like the browser or compiler ones somehow don’t seem to deter AI maximalists. They would simply claim they needed better models/skills/harness/tools/etc. the goalpost is always one foot away.
      - arcfour 6mo ago
        I wouldn't describe myself as an AI maximalist at all. I just don't believe the false dichotomy of you either produce "vulnerable vibe coded AI slop running on a managed service" or "pure handcrafted code running on a self hosted service." You can write good and bad code with and without AI, on a managed service, self-hosted, or something in between. And the comment I was replying to said something about not trusting something written in Akron, OH 2 years ago, which makes no sense and is barely an argument, and I was mostly pointing out how silly that comment sounds.
        eddythompson80 6mo ago
        I used to believe that too, yet the dichotomy is what’s being pushed by what I called an “AI maximalist” and it’s what I was pushing against. There is no “I wrote this code with some AI assistance” when you’re sending 2k line change PR after 8 minutes of me giving you permission on the repo. That’s the type of shit I’m dealing with and management is ecstatic at the pace and progress and the person just looks at you and say “anything in particular that’s wrong or needs changing? I’m just asking for a review and feedback”
      - slopinthebag 6mo ago
    - brookst 6mo ago
      So it’s not a binary thing, there’s context and nuance?
  - steve1977 6mo ago
    cue Jeopardy theme song Who is Apple?

esseph 6mo ago

> We need a different hosting model. There really isn't an option here, IMO. 1. Somebody does it 2. You do it Much happier doing it myself tbh.

fragmede 6mo ago
There's a lot of wiggle room on how you define "it". At the ends of the spectrum it's obvious, but in the middle it gets a bit sticky.

0xbadcafebee 6mo ago

It's not a hosting model, it's a fundamental failure of software design and systems engineering/architecture. Imagine if cars were developed like websites, with your brakes depending on a live connection to a 3rd party plugin on a website. Insanity, right? But not for web businesses people depend on for privacy, security, finances, transportation, healthcare, etc. When the company's brakes go out today, we all just shrug, watch the car crash, then pick up the pieces and continue like it's normal. I have yet to hear a single CEO issue an ultimatum that the OWASP Top 10 (just an example) will be prevented by X date. Because they don't really care. They'll only lose a few customers and everyone else will shrug and keep using them. If we vote with our dollars, we've voted to let it continue.

pianopatrick 6mo ago

Just throwing it out there - the Unix way to write software is often revered. But ideas about how to write software that came from the 1970s at Bell Labs might not be the best ideas for writing software for the modern web. Instead of "programs that do one thing and do it well", "write programs which are designed to be used together" and "write programs to handle text streams", I might go with a foundational philosophy like "write programs that are do not trust the user or the admin" because in applications connected to the internet, both groups often make mistakes or are malicious. Also something like "write programs that are strict on which inputs they accept" because a lot of input is malicious.

deleted 6mo ago
[deleted]
mpyne 6mo ago
The Unix model wasn't simply do one thing and do it well. It was also a different model on ownership and vetting of those focused tools. It might have been a model of having the single source tree of an old UNIX or BSD, where everything was managed as a coherent whole from grep to cc all the way to X11. Or it might have been the Linux distribution model of having dedicated packagers do the vetting to piecemeal packages into more of a bazaar, even going so far as to rip scripting language bundles into their component pieces as for Python and Perl. But in both of those models you were put farther away from the third-party authors bringing software into the open-source (and proprietary) supply chains. This led to a host of issues with getting new software to users and with a fractal explosion of different versions of software dependencies to potentially have to work around, which is one reason we saw the explosion of NPM and Cargo and the like. Especially once Docker made it easy to go straight from stitching an app together with NPM on your local dev seat to getting it deployed to prod. But the issue isn't with focused tooling as much as it is with hewing more closely to the upstream who could potentially be subverted in a supply chain attack. After all, it's not as if people never tried to do this with Linux distros (or even the Linux kernel itself -- see for instance https://linux.slashdot.org/story/03/11/06/058249/linux-kernel-back-door-hack-attempt-discovered https://linux.slashdot.org/story/03/11/06/058249/linux-kerne... ). But the inherent delay and indirection in that model helped make it less of a serious risk. But even if you only use 1 NPM package instead of 100, if it's a big enough package you can assume it's going to be a large target for attacks.

steve1977 6mo ago

I guess we failed at the "do it well" step.