I must admit I don't really understand what the point of the post-install script concern is.
Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process.
So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens.
It seems to me that this is a small stumbling block at best, unless the whole ecosystem moves to a deno-like sandboxed environment. Maybe that is the plan?
A lot of packages are only used in the browser; if you don't use SSR they'd only be executed by node in unit tests in something like jest, but that is not the only way to run unit tests (Cypress can run them in a headless browser [1], for example). Running those sand-boxed would be the next logical step.
Removing automated execution of postinstall is a necessary step and may as well be the first one.
You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE).
I didn't try devcontainers stuff, TBH. But that's how I often develop my apps.
That said, there are other attack surfaces for that approach. For example I'm not sure if I can trust LSP server not to execute application code. So keeping everything in a container or in a VM seems to be the only sane approach to work with code you don't trust.
>You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE).
At this point I will not do any dev outside of a container - so many things can be supply chained in the OSS dev stack it's just not worth it, and once you get used to developing in containers it's actually a lot cleaner to move between hosts - you're essentially treating your client as a remote terminal.
If you're doing web dev work in this day an age SSH with tmux or some editor with SSH server support should be your dev setup.
If you only use npm to manage client side deps then it removes the ability to compromise a devs machine or the CI server. Seems like nice attack vectors to just eliminate entirely.
> So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens.
That would / could kill performance
> Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process.
So I doubt most people trace every dependency they install all the way. So sometimes it comes upstream. Maybe you don't run it. It could have been a dev dependency accidentally set for runtime and now you have it.
If you want to build a modern web frontend you will need to use npm. But a lot of those only ever run in the users browser where they can't do any harm. I would never consider the insanity of that ecosystem for backend work.
Unfortunately, real apps and native tech stacks can not only write data to your SSD, they can usually write data to the user directory however they want and they can read it as well!
This is a Linux-centric take. It does not apply for example to iPadOS or to AluminiumOS (coming soon to a Googlebook near you). It applies less and less over time to MacOS.
Yes, if one is committed to the standard Linux desktop, then one must hope that any proprietary apps one might need will continue to be available through the browser, but I'm ready to let the standard Linux desktop go (not right now, but eventually).
It very much applies to macOS, or do you know of a way to know what permissions a sideloaded macOS application will have before opening it that's accessible to regular users?
The very fact that you've qualified your question with "sideloaded" suggests that you are already aware that a non-sideloaded MacOS app is installed into a sandbox that is much more secure than anything available on a standard Linux desktop excepting possibly Qubes and Secureblue, and hardly anyone uses Qubes or Secureblue -- probably for very good reasons.
Yes, and I'm also aware that most macOS apps are still only available as a sideload, where sandboxing is optional and importantly not user visible before the app runs.
I don't know, maybe something about backwards compatibility, maybe nobody can agree on how to do it correctly. It hasn't happened for decades, so I'm not going to hold my breath.
1. in order to run LLMs, especially the best ones, you need complicated devices which are expensive
2. if you buy one for your personal use, you are probably not going to utilize it all the time and it will be idle a lot
It seems to me that it will always be more economical that the LLM-running devices are in a datacenter where it is easier to make sure they are always utilized
If a model is substantially better than most humans at most tasks, the human isn't going to be able to perceive the difference between Claude Opus 7.7 and 8.7. Humans at some point aren't going to be able to perceive the difference on benchmarks either, because they are going to get wildly abstract.
AI vendors are really going to struggle to shift tokens far beyond the frontier of human capabilities. It's reasonable (not guaranteed) to assume that, if the trend of frontier models (doubling capabilities on benchmarks every n months) holds, then the same trend will hold for local models, and those local models will meet and exceed the perception frontier. This would mean a human cannot tell the difference between Mistral-Open-2030 and Claude Opus 2030.
That's a bunch of "ifs", but there's nothing exceptional about those "ifs". They're basically the scenario if nothing changes between now and ~2030 with regards to capabilities trend attainment.
The trend over the past three decades of personal computing has been for devices to become exponentially more powerful regardless of the actual computing needs of users. The excess computing power has famously been requested by projects such as SETI@Home and Folding@Home, and been exploited by bad actors for crypto mining. The most basic laptop today used only for web browsing and word processing would be a powerful workstation 20 years ago, when the most basic laptop was also used only for web browsing and word processing (and arguably for more things, as it was all mostly local software).
There is no ceiling to the power of consumer hardware. If it's cheap enough, it will be bought.
I think you missed the point of my message. Web browsing still happens by connecting to data centres, so why are consumer laptops so much more (unnecessarily) powerful today than they were 20 years ago? All the more so given that, at that time, you were running MS Office locally rather than using Office 365 or Google Docs remotely.
Even two or three years people were pointing out "The ChatGPT subscriptions you can buy with $2000 give you much more compute than whatever home setup you come up with" on r/LocalLLM. I did my own elementary school maths and came to the same conclusion.
Yet till this day people still boast how their beefy M4 Pro/Max machine with 32+GB RAM (which is not at all a "normal person's setup" and costs $2000+) runs LLMs smoothly, and "that's the future".
Someone needs to re-learn basic maths and take a walk around Best Buy to understand what "consumer laptop" looks like.
If there end up being useful workflows where you keep stuff running in the background or overnight that's one advantage, compared to a data center that might cut off your access during peak hours or etc.
Think of it like having a graphics card at home versus using a cloud gaming stream? Technically subscribing to GeForce is much cheaper up front than getting a card, but people still do that. So will the audience of people running agents at home be as large as PC gaming? I think that's kind of plausible.
>2. if you buy one for your personal use, you are probably not going to utilize it all the time and it will be idle a lot
I think consumers are primed for that type of behaviour though. I have an iPhone on my desk. It has something like 2-3tflops CPU+GPU, which is double that of the largest super computer on earth when Jurassic Park came out, and is probably more computing power than existed on earth when I was born in the 80s.
I use this device for around 1hr per day to write text messages.
It's inevitable. What might be a prosumer device today priced at 4000$ will be a regular consumer device in 10 years and models only get better.
Local models today are fine for a lot of mundane tasks and will continue to be so. The use cases where paying for frontier models is worth it, will continue to shrink for folks not doing frontier work.
The problem is that often the program runs into some edge case that requires interpretation, at which point one is tempted to let the LLM deal with the edge case, at which point one is tempted to let the LLM deal with the whole loop and let it do the tool calls
Agreed. I think the approach described here is promising. Most of the workflow is deterministic and includes safeguards, but an LLM is invoked in the one case where it's really useful.
If I'm understanding the thread correctly, I have a git alias to `git commit --amend --no-edit`, for exactly this workflow. When I'm hacking on something locally and want to just keep amending a commit. I only ever do this if it's HEAD though.
I go back and forth between the two approaches, but because of the whole "accidentally made some temporary changes and now it's a pain to separate/undo them because not all changes were temporary", I also usually do a jj new and then jj squash.
I've gone all in on jj with a OSS framework I'm building. With just a little extra context, the agents have been amazingly adapt at slicing and dicing with jj. Gives them a place to play without stomping on normal git processes.
This comment raises an interesting question: Would Serenity OS have brought Andreas the same kind of serenity had it been developed with AI? Open candid question.
I don't think so because if I remember it correctly, Andreas suffered from alcoholism and serenity prayer helped him to go on the right path and iirc he honored that and created an os named serenityos.
God grant me the serenity
to accept the things I cannot change;
courage to change the things I can;
and wisdom to know the difference.
(courage to change the things I can;):- I think that this line must've given Andreas the strength, the passion to make the project reality.
but if AI made the change. Would the line be changed to courage to prompt an all powerful entity to change the things I asked it to.
Would that give courage? Would that inspire confidence in oneself?
I have personally made many projects with LLM's (honestly I must admit that I am a teenager and so I have been sort of using it from the start)
and personally, I feel like there are some points of curiosity that I can be prideful of in my projects but there is still a sense of emptiness and I think I am not the only one who observes it as such.
I think in the world of AI hype, it takes true courage & passion to write by hand.
Obviously one tries to argue that AI is the next bytecode but that is false because of the non deterministic nature of AI but even that being said, I think I personally feel as if the people who write assembly are definitely likely to be more passionate of their craft than Nodejs (and I would consider myself a nodejs guy and there's still passion but still)
Coding was definitely a form of art/expression/sense-of-meaning for Mr Andreas during a time of struggle. To automate that might strip him of the joy derived from stroking brush on an empty canvas.
Honestly, I really don't know about AI the more I think about it so I will not pretend that I know a thing/two about AI. This message is just my opinion in the moment. Opinions change with time but my opinion right now is that coding by hand definitely is more meaningful than not if the purpose of the project is to derive meaning.
I like the idea that people are either coders or builders. So AI can help fulfill your desire to build, create, bring things into reality. But it can't satisfy you if you like programming for its own sake. SerenityOS was not a practical project, it was clearly done for the enjoyment of programming itself.
The project's use of AI now echoes that - it's not being used to create new features, it's used for practical, boring drudge work of translating between two languages. So still very much on brand.
They ported an existing project from CPP to Rust using AI because the porting would've been too tedious. I don't think they're planning on vibe coding PRs the way you're imagining.
Yeah, some weekends ago I tried writing a cross-platform browser without any Rust crates, this weekend I made my own self-hosted compile to Rust Clojure-like lisp, maybe next weekend attempting to create a OS that uses my language to run on bare-metal would actually be a challenge. Thanks for the inspiration :)
Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process.
So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens.
It seems to me that this is a small stumbling block at best, unless the whole ecosystem moves to a deno-like sandboxed environment. Maybe that is the plan?
reply