4 ms·

The Debian stable model of having a distro handle common dependencies with a full system upgrade every few years looks more and more sane as years pass. It's a

The Debian stable model of having a distro handle common dependencies with a full system upgrade every few years looks more and more sane as years pass. It's a shame some ecosystems move waaay too fast, or don't have a good story for having distro-specific packages. For example, I don't think there are Node.js libraries packaged for Debian that allow you to install them from apt and use it in projects. I might be wrong.

kykat 11mo ago
It is possible to work with rust, using debian repositories as the only source.
embedding-shape 11mo ago
> For example, I don't think there are Node.js libraries packaged for Debian that allow you to install them from apt and use it in projects Web search shows some: https://packages.debian.org/search?keywords=node&searchon=names&suite=trixie&section=all https://packages.debian.org/search?keywords=node&searchon=na... (but also shows "for optimizing reasons some results might have been suppressed" so might not be all) Although probably different from other distros, Arch for example seems to have none.
- o11c 11mo ago
  Locally, you can do: apt-cache showpkg 'node-*' | grep ^Package: which returns 4155 results, though 727 of them are type packages. Using these in commonjs code is trivial; they are automatically found by `require`. Unfortunately, system-installed packages are yet another casualty of the ESM transition ... there are ways to make it work but it's not automatic like it used to be.
  - 9dev 11mo ago
    > Unfortunately, system-installed packages are yet another casualty of the ESM transition ... A small price to pay for the abundant benefits ESM brings.
    - o11c 11mo ago
      Honestly, I don't see the value gain, given how many other problems the JS tooling has (even ignoring the ecosystem). In particular, the fact that Typescript makes it very difficult to write a project that uses both browser-specific and node-specific functionality is particularly damning.
  - gr4vityWall 11mo ago
    > there are ways to make it work but it's not automatic like it used to be Out of curiosity, what would you recommend? And what would be needed to make them work automatically?
    - o11c 11mo ago
      Some solutions include: add a hook to node on the command line, fake a `node_modules`, try to make an import map work, just hard-code the path ... most of this is quite intrusive unlike the simple `require` path. I really don't have a recommendation other than another hack. The JS world is hacks upon hacks upon hacks; there is no sanity to be found anywhere.
noosphr 11mo ago
Never mistake motion for action. An eco system moving too quickly, when it isn't being fundamentally changed, isn't a sign of a healthy ecosystem, but of a pathological one. No one can think that js has progressed substantially in the last three years, yet trying to build any project three years old without updates is so hard a rewrite is a reasonable solution.
- gr4vityWall 11mo ago
  > No one can think that js has progressed substantially in the last three years Are we talking about the language, or the wider ecosystem? If the latter, I think a lot of people would disagree. Bun is about three years old. Other significant changes are Node.js being able to run TypeScript files without any optional flags, or being able to use require on ES Modules. I see positive changes in the ecosystem in recent years.
  - noosphr 11mo ago
    That is motion not action. The point of javascript is to display websites in the browser. Ask yourself, in the last three years has there been a substantial improvement in the way you access websites? Or have they gotten even slower, buggier and more annoying to deal with?
    - FridgeSeal 11mo ago
      No but the devs can push slower, buggier, more annoying websites to prod, faster! And after all, isn’t developer velocity (and investor benefits) really the only things that matter??? /sssss
    - throwawayqqq11 11mo ago
      > modern websites Your are comparing the js ecosystem and bad project realizations/designs. > Action vs motion I think the main difference you mean is the motivation behind changes, is it a (re)action to achieve a meassurable goal, is this a fix for a critical CVE, or just some dev having fun and pumping up the numbers. GP mentioned the recent feature of executing ts, which is a reasonable goal imo, with alot of beneficial effects down the line but in the present just another hustle to take care about. So is this a pointless motion or a worthy action? Both statements can be correct, depending on your goals.
mkoubaa 11mo ago
The stable model usually implies that your app has to target both the old and the new distro version for a while. That is a bit too much to ask for some, unfortunately

kykat 11mo ago

It is possible to work with rust, using debian repositories as the only source.

embedding-shape 11mo ago

> For example, I don't think there are Node.js libraries packaged for Debian that allow you to install them from apt and use it in projects Web search shows some: https://packages.debian.org/search?keywords=node&searchon=names&suite=trixie&section=all https://packages.debian.org/search?keywords=node&searchon=na... (but also shows "for optimizing reasons some results might have been suppressed" so might not be all) Although probably different from other distros, Arch for example seems to have none.

o11c 11mo ago
Locally, you can do: apt-cache showpkg 'node-*' | grep ^Package: which returns 4155 results, though 727 of them are type packages. Using these in commonjs code is trivial; they are automatically found by `require`. Unfortunately, system-installed packages are yet another casualty of the ESM transition ... there are ways to make it work but it's not automatic like it used to be.
- 9dev 11mo ago
  > Unfortunately, system-installed packages are yet another casualty of the ESM transition ... A small price to pay for the abundant benefits ESM brings.
  - o11c 11mo ago
    Honestly, I don't see the value gain, given how many other problems the JS tooling has (even ignoring the ecosystem). In particular, the fact that Typescript makes it very difficult to write a project that uses both browser-specific and node-specific functionality is particularly damning.
- gr4vityWall 11mo ago
  > there are ways to make it work but it's not automatic like it used to be Out of curiosity, what would you recommend? And what would be needed to make them work automatically?
  - o11c 11mo ago
    Some solutions include: add a hook to node on the command line, fake a `node_modules`, try to make an import map work, just hard-code the path ... most of this is quite intrusive unlike the simple `require` path. I really don't have a recommendation other than another hack. The JS world is hacks upon hacks upon hacks; there is no sanity to be found anywhere.

noosphr 11mo ago

Never mistake motion for action. An eco system moving too quickly, when it isn't being fundamentally changed, isn't a sign of a healthy ecosystem, but of a pathological one. No one can think that js has progressed substantially in the last three years, yet trying to build any project three years old without updates is so hard a rewrite is a reasonable solution.

gr4vityWall 11mo ago
> No one can think that js has progressed substantially in the last three years Are we talking about the language, or the wider ecosystem? If the latter, I think a lot of people would disagree. Bun is about three years old. Other significant changes are Node.js being able to run TypeScript files without any optional flags, or being able to use require on ES Modules. I see positive changes in the ecosystem in recent years.
- noosphr 11mo ago
  That is motion not action. The point of javascript is to display websites in the browser. Ask yourself, in the last three years has there been a substantial improvement in the way you access websites? Or have they gotten even slower, buggier and more annoying to deal with?
  - FridgeSeal 11mo ago
    No but the devs can push slower, buggier, more annoying websites to prod, faster! And after all, isn’t developer velocity (and investor benefits) really the only things that matter??? /sssss
  - throwawayqqq11 11mo ago
    > modern websites Your are comparing the js ecosystem and bad project realizations/designs. > Action vs motion I think the main difference you mean is the motivation behind changes, is it a (re)action to achieve a meassurable goal, is this a fix for a critical CVE, or just some dev having fun and pumping up the numbers. GP mentioned the recent feature of executing ts, which is a reasonable goal imo, with alot of beneficial effects down the line but in the present just another hustle to take care about. So is this a pointless motion or a worthy action? Both statements can be correct, depending on your goals.

mkoubaa 11mo ago

The stable model usually implies that your app has to target both the old and the new distro version for a while. That is a bit too much to ask for some, unfortunately