Newest at the top
| 2025-01-23 21:58:33 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-01-23 21:55:48 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-01-23 21:54:47 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2025-01-23 21:52:37 +0100 | poscat | (~poscat@user/poscat) (Ping timeout: 248 seconds) |
| 2025-01-23 21:51:53 +0100 | <homo> | do you mean like some gnu/linux distros package haskell libraries?? |
| 2025-01-23 21:51:30 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-23 21:50:26 +0100 | <dminuoso> | That way updates are easily reflected in git history too. |
| 2025-01-23 21:50:11 +0100 | <dminuoso> | Ideally I would want cabal-install to have a mechanism to quickly vendor all dependencies unpacked locally |
| 2025-01-23 21:49:50 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-23 21:48:40 +0100 | <homo> | you just give example of why bring microhs to plan9 - small dependency footprint of all software combined |
| 2025-01-23 21:46:13 +0100 | <dminuoso> | Why why I belong to the set of people that dislike large dependeny footprints, it makes my job harder. :-P |
| 2025-01-23 21:45:28 +0100 | <dminuoso> | But for now this is a manual process which I rigorously follow. |
| 2025-01-23 21:45:09 +0100 | <dminuoso> | For a while I have been playing around with an idea on how to tie this into cabal-install |
| 2025-01-23 21:44:48 +0100 | <dminuoso> | homo: I do that for our critical software. |
| 2025-01-23 21:44:26 +0100 | <homo> | would be actually an interesting update mechanism for every user: review code before updating |
| 2025-01-23 21:43:49 +0100 | <dminuoso> | Not enough to consider it a pattern, but its a possibility |
| 2025-01-23 21:43:42 +0100 | <dminuoso> | But Ive seen reports from a few maintainers that have to fight floods of PRs of poorly generated code already. |
| 2025-01-23 21:43:32 +0100 | <homo> | also when updates happen rarely, it's easier to make independent review and decide whether or not they are desirable |
| 2025-01-23 21:43:24 +0100 | <dminuoso> | LLMs certainly seem like a promising solution to a lack of open source contributions - whether its for good or worse remains to be seen. |
| 2025-01-23 21:42:54 +0100 | EvanR | (~EvanR@user/evanr) EvanR |
| 2025-01-23 21:42:51 +0100 | <dminuoso> | sm: Especially in projects where there is 1-2 develoeprs, but dozens of issues a day from people that really want things fixed. |
| 2025-01-23 21:42:27 +0100 | <Rembane> | homo: Some ecosystems are so much more chill than others when it comes to updates. |
| 2025-01-23 21:42:15 +0100 | <Rembane> | homo: I think that depends on the ecosystem |
| 2025-01-23 21:42:12 +0100 | <dminuoso> | sm: Well most certainly do not donate 40 hours a week. When I say "little time" I mean it in the sense of "what little time they can donate" while splitting time with family, other hobbies and sleep |
| 2025-01-23 21:41:17 +0100 | <geekosaur> | (or modules in their private `lib` directories) |
| 2025-01-23 21:41:06 +0100 | <geekosaur> | some of us ignore the update culture. xmonad's core barely changes; it's solid and doesn't need to change, and most things can be done via hooks (which mostly come from xmonad-contrib but I've seen a fair amount of personal extensions in people's `xmonad.hs` files) |
| 2025-01-23 21:40:06 +0100 | <homo> | because if you don't push more code, people think your project is dead, irrelevant |
| 2025-01-23 21:40:03 +0100 | <haskellbridge> | <sm> me too. Not all projects can be done; either way, I love the ones that just keep working |
| 2025-01-23 21:39:16 +0100 | <Rembane> | Why? |
| 2025-01-23 21:38:26 +0100 | <homo> | I bet this kind of culture of frequent updates helps exploits like in xz happen |
| 2025-01-23 21:38:08 +0100 | <Rembane> | I love projects that are done. And that just keeps working. |
| 2025-01-23 21:37:09 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 248 seconds) |
| 2025-01-23 21:36:01 +0100 | <homo> | "oh no, last time it was updated was 2 years ago, it's so bad it wasn't updated yesterday" |
| 2025-01-23 21:33:20 +0100 | <homo> | it also depends on how much sense it makes to focus on project, what if it's complete and thus requires updates very rarely? |
| 2025-01-23 21:32:43 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
| 2025-01-23 21:31:51 +0100 | <haskellbridge> | <sm> eh.. for some value of "very little time" |
| 2025-01-23 21:30:52 +0100 | <dminuoso> | Already now, people spend very little time on their open source projects. |
| 2025-01-23 21:30:29 +0100 | <dminuoso> | Why would free software be unimpacted? |
| 2025-01-23 21:30:11 +0100 | <homo> | I welcome it too, because then proprietary software will be so shitty that more and more people will switch to free software |
| 2025-01-23 21:30:00 +0100 | <dminuoso> | I believe to be above the job security threshold. |
| 2025-01-23 21:29:38 +0100 | <dminuoso> | Someone needs to fix the hallucinated garbage in the future, someone who actually knows how to build programs without the tool that broke it in the first place. |
| 2025-01-23 21:29:16 +0100 | <dminuoso> | I welcome it. |
| 2025-01-23 21:29:14 +0100 | <dminuoso> | homo: Personally I dont mind if companies adopt LLMs large scale for programming. |
| 2025-01-23 21:28:59 +0100 | <haskellbridge> | <sm> nobody has trained one focussed on rust/haskell porting yet, but something like that is quite possible in the near future. Much sooner than anyone will manually port darcs or pijul I predict |
| 2025-01-23 21:28:58 +0100 | <homo> | dminuoso don't tell that to companies that want to cut their budget on workers, let them go bankrupt after they replace programmers with llms |
| 2025-01-23 21:28:17 +0100 | <haskellbridge> | <sm> I used an LLM very successfully yesterday for some PHP and JS work. (Sorry to say it, because I don't like their costs and don't want to promote them. But I'm hoping to mostly use a local one soon.) |
| 2025-01-23 21:26:54 +0100 | <dminuoso> | You and I must be reading very different HN articles. :) |
| 2025-01-23 21:26:37 +0100 | Midjak | (~MarciZ@82.66.147.146) Midjak |
| 2025-01-23 21:26:21 +0100 | <haskellbridge> | <sm> homO: I meant that the more successful and more efficient new LLMs seem to be benefitting from a more carefully structured training process (from my HN reading). I'm not saying anything about companies |
| 2025-01-23 21:26:19 +0100 | <dminuoso> | Besides, everything I have seen suggests that LLMs in programming perform rather poor on any non-trivial problems, and yet they get used much in boiler plate code. To me that suggests a negative quality feedback loop, as the generated low quality code increases rapidly |