Conversation

Notices

1. Embed this notice
   Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 18-Jul-2023 12:07:55 JST Haelwenn /элвэн/ :triskell:
   Languages born after 2010 cannot be packaged, all they know is dependabot.
   
   (Hare is like the one exception to the rule)
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 18-Jul-2023 12:10:40 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • iced depresso
     @icedquinn So you end up also being basically a distro for your dependencies.
   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Tuesday, 18-Jul-2023 12:10:42 JST iced depresso

     in reply to
     @lanodan i've never used dependabot :blobcatupsidedown: technically nim has nimble but i don't particularly use it to ship since i vendor with submodules.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 18-Jul-2023 12:11:36 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Julia :verified_trans:
     @julia dx?
   • Embed this notice
     Julia :verified_trans: (julia@snug.moe)'s status on Tuesday, 18-Jul-2023 12:11:37 JST Julia :verified_trans:

     in reply to

     @lanodan@queer.hacktivis.me its a way better dx, in fairness

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 18-Jul-2023 12:33:19 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Julia :verified_trans:
     @julia Not really.
     
     It might be easy at first but most software has ways to install things in whatever path temporarily (and imho pip is worse than PYTHON_PATH), distros also often ship with ways to automagically package some languages (say g-cpan for perl stuff on gentoo, nix probably also has funky things).
     
     But it turns the maintenance into hell, a distro allows to be a team of people and keep what packagers review/audit yourself to a minimum and then just watch a bit what your direct dependencies are doing so your own code still works.
     And I don't think any developers review the code of their npm-style dependencies, it's an impossible load, yet we all know you can end up with trivially detectable malware.
     
     And npm-style is also typically unusable from an admin/user point of view, because the packages don't talk to each others but also because you cannot like `pkg upgrade` all the stuff you have installed.
   • Embed this notice
     Julia :verified_trans: (julia@snug.moe)'s status on Tuesday, 18-Jul-2023 12:33:21 JST Julia :verified_trans:

     in reply to

     @lanodan@queer.hacktivis.me developer experience, ie how easy it is to make apps

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 19-Jul-2023 02:12:50 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ignas Kiela
     @ignaloidas I would ignore the thing hard or be annoyed if I'm forced to use it (like Rust tries hard to with the Rewrite-it-in-Rust meme) and I'm pretty sure other distros also would.
     
     It doesn't scales to (semi-)manually dependencies in every little application and it's a huge security hazard (all distros took like less than a day to fix log4shell, while proprietary software took months).
     And it's a massive pain in the ass to maintain that stuff because any kind of bugfix then has to be done *everywhere by hand*, effectively eating the bandwidth for other things, including better testing and patches.
     
     Just allow to install the dependencies in a PATH (In any form, be it shared libs, static libs, source, …) and consider actual package managers like Nix/Guix if you want reproducible development environments. (pip/npm/… being annoyingly ignorant of the system dependencies)
   • Embed this notice
     Ignas Kiela (ignaloidas@not.acu.lt)'s status on Wednesday, 19-Jul-2023 02:12:52 JST Ignas Kiela

     in reply to

     @lanodan@queer.hacktivis.me tbh I don't really know where my "headlanguage" would land on this
     
     My plan is to vendor all of the dependencies
     
     But also my plan is to have the language be content-addressed underneath, so that each piece of code is identified by what it is
     
     And also absolutely zero dynamic linking, actually, the plan is to not have a traditional linker at all. Interop with C achieved by translating C into the language's AST and compiling/interpreting that.
     
     So I have zero clue how that would be received by distros.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 19-Jul-2023 02:57:07 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ignas Kiela
     @ignaloidas So you'd have a completely new set of problems, good luck with that.
     
     And having seen critical vulnerabilities going across a bunch of years and various long time forks, I'd doubt name-hash would work, or you're just talking about hashing mere function signatures and I don't see how it would only match vulnerable ones.
   • Embed this notice
     Ignas Kiela (ignaloidas@not.acu.lt)'s status on Wednesday, 19-Jul-2023 02:57:09 JST Ignas Kiela

     in reply to

     @lanodan@queer.hacktivis.me tbh I don't particularly care about repo adoption, if I went ahead far enough with the language, I'd also go for my own kernel and stuff
     
     Somewhat automated patching would be possible as long as the API's don't matter (a matter of changing name-hash mapping and updating it all the way up, would be tools for that because it both wouldn't be stored as traditional files (way more annoying to do content addressing on things inside of files than the files, having a "source database" seems nicer). And FWIW some stuff for vuln patching could be nicer, e.g. in a security report you'd get the hashes of the functions that are vulnerable, and you just scan through all packages of the language to check if the specific function is used, so you can be a lot more granular on what to spend CI time on while updating.
     
     But no, there will be absolutely NO way to include "system" libraries, everything would have to be in the source library, and in the source library only, no going out to internet to fetch stuff (separate tools to do that and put it into the source library).