I have the same feeling. I'm even trying to argument to myself upgrading my phone to something newer that would support AI better but I genuinely can't. The only use case I could ever need is maybe(!) using it to fill up shopping list out loud but at this point it, using shared Google Keep it's roughly the same amount of work to just type it. In professional matter though, having an AI agent on Slack, that can query readonly dbs for us, check things, debug problems reported by our users, it's pretty great.
More than 3 decades. The original world wide web had them. Link "circles"[1] fell out of favor for SEO around 2015 or so, but before that, they had been a primary driver of Page Rank forever.
I worked in SEO from 2008 until 2015, and developed a lot of tools for increasing your PR from backlink indexing, to running a 15k domain blog network designed to build links to links to links to you, and my favorite: Click Faker - if you were ranked on Google already, on Page one or 2, it would search google find your site, click into it, navigate around, sit on some pages for a while before clicking an exit link or closing the browser - it was very powerful, but nearly impossible to scale, since it needed local residential IPs and I'm against botnets.
1. The circles actually couldn't close if you were looking for the ultimate page rank passthrough, they were actually a line, but still called circles.
I didn't "forget". I never agreed that I had some natural right to exclude anyone from or demand payment for using bits of information I "made".
It's not also actually "getting paid for your work" when you're talking about copyright. It's "collecting rent for your property".
Once upon a time, artists and writers got conned into thinking that was a good deal for them, forgoing payment for work in return for a dangling promise of rent extraction. The vast majority of them were wrong.
I work in crypto and this is happening practically every other day. I refuse anyone on LinkedIn that I don't know personally and has web3 or crypto anywhere in the description. It's all fake accounts with fake job offers. It's a pretty known scam.
Unless your job is purely producing code pointlessly, this is not a really good comparison. Most of the time really is spent on understanding the problem and figuring out solutions, not waiting on CPU.
postinstall scripts should've been removed long time ago, it's the cancer of NPM packages. There's so many deeply nested, uncontrolled postinstalls that run randomly when you pull something it's insane, I don't know how someone at some point ever though that was a good idea.
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.
On a project with a 1GB node_modules directory (after aggressive cleanup) I think we only had one dependency that didn't work right with postinstall disabled. Though I can't recall which and I don't work there anymore so I can't hunt.
And IIRC that one was fixable by a PR, because they'd done something weird and there was an idiomatic way to accomplish the same thing.
Your own link says that a proper package manager (e.g. pnpm) supports this out of the box.
If there are other use cases that really need post-install scripts, you can whitelist just those in pnpm. In projects I'm working with, there are often zero post-install scripts that must be enabled for everything to work properly, and it's usually from poorly cobbled packages that use them to download prebuilt binaries (well written packages, like biome or tsgo, use per-architecture subpackages).
You enable just one or two of those, and block everything else.
Given that has an impact over the whole industry, I will for sure tell you that patching on install SHOULD NOT be a thing. Up to you to run your own post install script yourself
Or maybe just add a script in package.json to run whatever patch-package does (eg, "install:patch": "npm install && patch-package") instead of whitelisting every package to have that power.
How would getting rid of postinstall break patch-package? If people use a package, and that package needs some kind of step to get working, user of that package should decide when that step happens. He can very well just call patch before building on his own. There's zero issues with that approach and the upside is he actually has control.
I work in a monorepo where running install calls dozens of deeply nested postinstalls of some elaborate NextJs or React Native dependencies other projects use. It's borderline insane. Unless you regularly screen everything, it's impossible to know whether one of those is compromised, especially in the world of Node where is-even is being used and the sheer amount of crypto scams around.
These laws only apply to megacorps. It's not an existential risk to them, as Apple is clearly proving now.
Who is saying that enforcing companies to open their systems to competition is making them mediocre? Maybe if that's the end result, they should put more time into designing systems that wouldn't become mediocre just by allowing third parties to do things with those said systems? We need to stop defending corporates for abusing their monopolies.
Megacorps weren't always giants and it's not unusual for small companies to eventually become giants through excellent vertically-integrated products, and such companies would become subject to these regulations.
Interoperability is not free. One of the trades it brings is a notably lowered ceiling in terms of tightness and capabilities, and this persists no matter how many man-hours are poured into engineering the systems that enable it.
The Linux desktop is a great example of this at play. While it's technically worked for decades at this point, it's been a constant struggle to make it a high quality, thoroughly polished experience end to end and that's partly thanks to the unavoidable friction and gaps between layers that comes with interoperability and tens of involved parties.
We use almost exclusively Valkey now, mostly because we host on AWS and Render, which both use Valkey. It's faster, cheaper and compatible. I'd consider Garnet too but I believe it doesn't support LUA(or didn't at the time we needed it).
I've used one of the flagship Surface Books two jobs ago, really beefy, could run Cyberpunk(don't ask how I know). Insanely bad machine, the overall finish was terrible, hinges broke often, charging port broke often(like every 3rd-4th person in the office), it overheated with basic office work, fans went rocket level loud when compiling basic things, after a while it was stuttering even with casual use. Had a really good Dell XPS at home too that was dying when compiling big Typescript codebase. I bought an MBP M3Pro 1.5y ago and I could never go back. It's insane how far ahead Apple is when it comes to performance. Noone seems to grasp that until they actually try to work on M-series. Three of my ex colleagues also switched to Macbooks after I told them, they also are never coming back.
My bet is they won't. It's hype driven development. I work in the space(we build one of the bigger exchanges based on Hyperliquid) and our design/product people are spasming at the thought of releasing MCP/Openclaw skill for trading. I'm 99% sure it will all be a flop, month from now noone will ever know these exist but this is what everyone in that space is doing right now, quite literally, everyone. Not a single sane person will give meaningful amount of money to LLM for actual trading.
> Not a single sane person will give meaningful amount of money to LLM for actual trading.
r/wallstreetbets enters the picture... it will happen. And if it's not the "well-regarded" WSB people, it will be someone who drank way too much of the AI kool-aid.
reply