Newest at the top
| 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 |
| 2025-01-23 21:26:19 +0100 | acidjnk | (~acidjnk@p200300d6e7283f96b914b0b581af9338.dip0.t-ipconnect.de) acidjnk |
| 2025-01-23 21:25:01 +0100 | <dminuoso> | For recursive training to add value, we would need LLMs to generate better output than their input, especially in programming since auditing large piles of codes for quality and correctness is just not feasible. |