ByteCode.NewsSubmit
Use quotes for an exact word.

Subscribe

RSSPodcast
Log in

Chat Logs

  1. dreamrealhttps://bytecode.news/posts/2026/10/where-is-all-the-new-good-software
  2. bluedreamreal: maybe Nate Meyvis should be looking at primate.run, flog.run or repopack.com
  3. dreamrealnot his point
  4. dreamrealthose are drops of water in a massive ocean
  5. bluehis point is flawed. no one is making the claim that "AI skeptics" are looking to refute
  6. blueyou can't prove a negative, the guy fails 101
  7. bluelistening
  8. * dreamreal sighs
  9. bluealso, he doesn't list omarchy
  10. bluewhich is widely popular and almost 100% clankered
  11. dreamrealmein Gott
  12. dreamrealnone of those matter for what he's talking about
  13. dreamrealthe existence of 100 new fascinating things is being drowned out by other noise
  14. dreamrealit's a valid thing to wonder about, even if those 100 things exist
  15. blueI found a regression in the podcast version, dreamreal
  16. dreamrealfire away
  17. blueI can't listen as fast as I read
  18. dreamrealI changed something in how it was record it, Oh, cool! So don't listen
  19. dreamrealI can't listen to them myself
  20. bluewell I prefer listening
  21. bluethis is a good article
  22. dreamrealhold on got something to do here
  23. bluedo you consider repopack falling as a 'reimplementation', or something new?
  24. bluefalling under*
  25. bluebecause at first it was mostly a reimplementation of gh+herdr, but now it's really going its separate ways conceptually, with tasks
  26. dreamrealNo, but why?
  27. bluejust interested
  28. dreamrealI mean, I find new thiings all the time
  29. dreamrealbut then again I *look*
  30. blueya
  31. dreamrealI find the written article > the audio for a lot of reasons, not least is that only one footnote made it into the audio
  32. bluewell this is a good article. which I can't say about the original article
  33. bluedon't like its form much, bulletin lists strike me as lazy
  34. dreamrealI didn't think the original article was bad (or else I wouldn't have written it up on BCN)
  35. bluethat depends on your definition of bad
  36. blueit's pretty bad for what it tries to do
  37. dreamrealI felt like he had a good observation that needed some context
  38. blueI am sorely missing examples, again
  39. blue"We are in fact seeing software improvement, in the form of more and better features in existing products."
  40. bluewhere?
  41. dreamrealSo? I mean, what's better, to run the first mile of a marathon or just to not try at all? If your only metric is "did you finish" then they're equivalent, but I would suggest that the first mile is a START
  42. dreamrealAre you talking about where *I* didn't point out improvements?
  43. blueno
  44. dreamrealBecause I surely did not
  45. dreamrealwell, he has the same problem I do: endorsement
  46. blueno I'm just saying, that article is not *good*. it could have good aspects, but I don't find it useful. the BCN take gave us EXAMPLES
  47. dreamrealhis problem is less severe than mine, I think, but calling out one or three makes it seem like those are THE IMPROVEMENTS
  48. blueand it was prose, which is infinitely better than bulletins
  49. dreamrealwell, that's why BCN wrote it up :D
  50. dreamrealI thought it was a useful thoughtline, but it didn't actually explore the space especially well
  51. bluethe visibility point, was well delivered. but I can't find it in any accessible form in the source material
  52. dreamrealyeah, well, it's not there
  53. dreamrealI think he had an idea and developed it about 50% because it's a blog
  54. bluealso I think the thing that drives the BCN take home, and imho is completely missing, is the implementation-ideation chasm
  55. bluebecause that's the golden nugget here
  56. dreamreal... which is why I wrote it. And I really did ask Fable about that :D
  57. bluethe problem is real, and kind of acute
  58. dreamrealI would have quoted it and GOSH did I want to, but its answer was way too long to quote
  59. dreamrealI was gonna use a vocoder in the podcast version for the bot :D
  60. blueAI cannot imagine us the good/new or new/good software, because it doesn't have access to wishes and desires, which drive this
  61. dreamrealyeah, it basically does efficient combinatorics
  62. bluebut our wishes and devices are infinitely masked by all the bad software out there
  63. blueI *still* don't understand why I need to scan medical bills, upload them to my insurance, get reimbursed, and transfer the money myself
  64. bluebut I have been accustomed, or forced, into this broken flow
  65. dreamrealouch, I haven't had to do that for years
  66. blueso of course I'm not going to think a better one is possible
  67. dreamrealI thought you guys had better medical support
  68. bluewell our private insurance is awesome. but ironically involves a lot of boilerplating, while public insurance involves none, and sucks to no end
  69. bluegotta choose your poison. wait 5 days for an appointment, but do all the invoicing yourself, or wait 5 months
  70. dreamrealheh, don't say that in public HERE, all the blue tribe people would hate you for pointing out the problem
  71. blueit would be nicer though if the doctor could just send the invoice directly to my insurance
  72. blueI do have like 0.5k of out-of-pocket per year, but I wouldn't mind my insurance billing me that
  73. blueor just waiting till year's end to see if it's worth billing
  74. bluebut generally speaking here, the private insurance does not interact directly with the doctors
  75. dreamreallots of BCN changes queued today, mostly QOL stuff, and I'm going to fix startup deployment I HOPE
  76. blueI pay the doctor, then get reimubrsed
  77. bluecool
  78. dreamrealbut there are backend changes, so the UI sync dance gets to happen :/
  79. dreamrealAll of the visible timestamps are UTC and ew
  80. bluedreamreal: related, https://repopack.com/project/primate/tasks/211?tasks=status%3Dopen
  81. bluenote that that is *experimental*. I have yet to ideate how to do that
  82. bluethe problem is probably known, and yet not easy: you want to be able to deploy migrations *while* your service is running; so you need a bridge situation
  83. bluein that bridge situation, your code is old, but your db has a newer state
  84. dreamrealyeah, that's... going to be interesting if the mutation is destructive
  85. bluewell, a lot of this is related to the fact that git is just not a very good tool for complex stuff, let alone AI stuff
  86. blueconsider diffs: diffs are most useful *in context*. if a new function is exported from file A, and now used in file B, you want to see this together; but this isn't how git does diffs
  87. bluethe problem is that git primitives do not lend themselves well at all to those two requirements: mixed-version apps, and context-based diffs
  88. bluedreamreal: cloudflare has been working on a git replacement for agents. I haven't looked at it, but this isn't the first time I'm hearing git hasn't been serving us well
  89. bluethis is the same thing as the BCN article noted: we're so accustomed to (bad) stuff, we hardly ever peek outside
  90. dreamrealyeah, it's hard to think "what's new" as opposed to maybe "how do I make this 1% better" when 1% just isn't good enough
  91. dreamrealanyway, exercise time
  92. blueenjoy
  93. bot[Node.js Blog] Wednesday, October 21, 2026 Security Releases - https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
  94. bluedreamreal: thinking of ai-forking node
  95. bluemostly to add support for "std:" namespaces (rcompat)
  96. blueI'm waiting for the codex refresh, then will embark on that
  97. systemfaultIs that something that can be "shim"ed or that requires an actual fork?
  98. bluesystemfault: I don't know... maybe it's enough to change the .js files without touching the c++ part
  99. bluebut I probably need to touch the package/import resolution
  100. bot[Node.js Blog] Node.js 24.22.0 (LTS) - https://nodejs.org/en/blog/release/v24.22.0
  101. bot[Node.js Blog] Node.js 26.12.0 (Current) - https://nodejs.org/en/blog/release/v26.12.0
  102. bluehi phaleth
  103. bluedid you hear deno is dead?
  104. bluehttps://bytes.dev/archives/529
  105. nevetBytes #529 - A Eulogy for Deno
  106. phalethhi blue
  107. phalethyeah, that's why I've looked up node's permissions
  108. bluethis is done btw https://repopack.com/project/primate/tasks/209
  109. phalethis this correct?
  110. phalethRUN flog install
  111. phalethRUN flog run --cwd apps/website build
  112. blueyes
  113. phalethI thought yesterday or two days ago you figured out how to get only the packages needed to build primate website
  114. blue--cwd is for run, --workspace is for install
  115. phalethyeah, so why not use --workspace for install is the question
  116. phalethalso clanker says it installed over 400 packages there, that's too much I think
  117. blueyou can
  118. phalethso should I fix that Containerfile?
  119. phalethit's overcomplicated anyway
  120. bluechanging
  121. bluechanged
  122. phalethclanker should get: installed 361 packages and 65 workspace links (2 cache hits, 359 downloads)
  123. blueinstalled 361 packages and 65 workspace links (2 cache hits, 359 downloads)
  124. blueyes?
  125. blueI think that's still too much, but ok
  126. phalethwow, flog is so much faster than yesterday
  127. blueyes?
  128. phalethfrom 2:45 to 1:15
  129. blue1:15 minutes?
  130. phalethI mean the whole image build
  131. bluestill too long
  132. phalethyeah
  133. bluehow long was pnpm/nub?
  134. phalethnah, my computer is old
  135. blueah ok
  136. phalethforever I think
  137. blueya flog is superfast
  138. bluephaleth: I'm planning a node fork, called oden
  139. blueai-driven, of course
  140. bluethis is a parallel developed to flog. flog will get support for running js via different engines, but will have a different goal
  141. phaleththat is too much effort
  142. blueoden will maintain node compat 100%, but also support "std:"
  143. bluewell we created flog in 4 days, we can do anything
  144. phalethwhat about repopack?
  145. bluerepopack is still around 95% of the effort, I've been workin on it all week
  146. phalethI'd highly recommend leaving node alone, you already have rcompat to deal with shortcomings
  147. phalethlately it makes steady progress as bun is pushing it around
  148. phalethalso oden sounds like programming lang
  149. phaletheh, it just randomly decided to add react types to apps/website/package.json
  150. phalethand also rxjs
  151. phalethso I cannot revoke approval
  152. phalethoh, I can withdraw submission
  153. blueya
  154. bluerxjs and the react types were left from an earlier thingy, should be removed
  155. phalethyup
  156. blueflog is fastest for you currently, phaleth ?
  157. bluebtw no cgo
  158. phalethI think we will see after you merge 209
  159. phalethI do not have Containerfile with nub or pnpm anymore
  160. bluek
  161. phalethbut you could ask clanker in another issue to reconstruct those and run benchmarks and put that on flog site
  162. phalethcause that's really only thing people are interested in
  163. phalethmyself included
  164. phalethanyway, I think it's too much effort, flog is pretty good now
  165. blueya
  166. bluephaleth could you create a flog task for those benchmarkos? pnpm vs npm (if applicable) vs bun maybe
  167. phalethjust don't worry about it, flog is fine
  168. jreicherblue: do you know about zdiff3 conflict style in git? It's not exactly what you're talking about, but extra context in another sense is what it provides, so I think the problem is somewhat recognised.
  169. bluejreicher: I don't, pray tell more
  170. jreicherThe default conflict style has two text sections, one from the destination and one from the source. The zdiff3 conflict style adds a third: the text from the most recent ancestor, so you see what was there before the branches diverged.
  171. jreichermost recent COMMON ancestor, sorry
  172. blueI see
  173. jreicherIn many merge tools this brings up a different view too, and a really, really good one.