2026-07-23 00:00:05 <pyzozord    > 02you cannot simply execute a list of addresses on virtually any processor
2026-07-23 00:00:20 <pyzozord    > 02you need a small loop that jumps to each address
2026-07-23 00:00:33 <pyzozord    > 02doesnt that make this list of addresses a kind of bytecode?
2026-07-23 00:00:45 <lofty       > you are right that you cannot "simply execute" a list of addresses, but no, you don't need that small loop
2026-07-23 00:01:23 <pyzozord    > 02ohh ok sorry right there is no loop, it's "threaded" so simply each address eventually ends in instruction "go to the next address from the list"
2026-07-23 00:01:39 <lofty       > yes
2026-07-23 00:02:07 <pyzozord    > 02ok i think i am starting to see what it is
2026-07-23 00:02:23 <pyzozord    > 02it's not defined in terms of or in relation to "normal" interpreters
2026-07-23 00:02:47 <lofty       > which is distinct from bytecode because you need to map the bytecode to the next address, but with threaded code you already have the next address
2026-07-23 00:03:23 <pyzozord    > 02right i can imagine a bytecode vm doing this as an optimisation, but then you would call it a threaded vm
2026-07-23 00:03:28 <pyzozord    > 02i get it now, thank you
2026-07-23 00:03:58 <lofty       > happy to help
2026-07-23 00:04:01 <pyzozord    > 02:)
2026-07-23 00:04:44 <pyzozord    > 02btw, this seems to me like an implementation detail, but i notice many places pretty much introduce forth and bring up "threaded code" in the first 30 minutes or so, like it's a critical thing to understand to use forth correctly
2026-07-23 00:05:03 <pyzozord    > 02but it seems to me that whether it's threaded or it has a dispatch loop, doesn't change at all how you use it, am i wrong?
2026-07-23 00:05:47 <lofty       > people bring up threaded code because Forth is "shaped" to be implemented with threaded code naturally
2026-07-23 00:06:26 <lofty       > Forths have what we call the "outer interpreter" which is more or less the "read" part of the read-evaluate-print-loop
2026-07-23 00:06:56 <pyzozord    > 02oh ok so they bring up implementation detail because they assume audience who wants to learn forth probably wants to write a forth interpreter soon?
2026-07-23 00:07:31 <lofty       > which amounts to "look up this word in the dictionary; if it exists, append its function address to the current definition; otherwise, try to interpret it as a number, and append a way to put that number on the stack to the current definition; otherwise error"
2026-07-23 00:08:09 <lofty       > to implement this in any way _other_ than threaded code is making life painful for yourself
2026-07-23 00:08:56 <lofty       > Forth is a language that actively resists trying to be parsed ahead of time because it is possible to redefine primitive words
2026-07-23 00:08:59 <pyzozord    > 02right but i dont think any other interpreted language is introduced with how to implement it's interpreter
2026-07-23 00:09:33 <lofty       > Lisp might be an exception to that, but sure
2026-07-23 00:09:39 <pyzozord    > 02im not comparing to say its better or worse at all, im comparing because im trying to learn in terms of what i know
2026-07-23 00:10:22 <lofty       > doesn't change at all how you use it, am i wrong? <-- sure, I agree there
2026-07-23 00:10:38 <lofty       > audience who wants to learn forth probably wants to write a forth interpreter soon? <-- and yes, pretty much
2026-07-23 00:10:42 <pyzozord    > 02ok so people talk a lot about threaded code simply because they are excited about how simple it is to implement its interpreter, not because it has anything to do with how you use forth as a forth programmer
2026-07-23 00:10:58 <lofty       > not because it has anything to do with how you use forth as a forth programmer <-- this I disagree with
2026-07-23 00:10:59 <pyzozord    > 02ooh ok perfect got it, thanks again :)
2026-07-23 00:11:12 <pyzozord    > 02?
2026-07-23 00:11:44 <pyzozord    > 02how does it affect the forth programmer if they do not write their own interpreter ever?
2026-07-23 00:12:05 <lofty       > because a lot of the time a Forth programmer wants to change interpreter behaviour in some way
2026-07-23 00:12:27 <pyzozord    > 02oooh i see
2026-07-23 00:12:36 <pyzozord    > 02why do they want to change the interpreter?
2026-07-23 00:12:40 <pyzozord    > 02the most common usecase
2026-07-23 00:15:52 <lofty       > not to go too deep into the history of Forth, but the idea of it was that it is a "domain-specific language" (or as Chuck Moore called it originally, a "problem-oriented language"). the point is not necessarily that you write all of your things in Forth, but that you use Forth as a way to expose and compose functionality together
2026-07-23 00:16:30 <lofty       > you might know that a bunch of programs will expose an API through Python to allow you to interface with it
2026-07-23 00:16:50 <lofty       > Forth was intended for the same thing
2026-07-23 00:17:10 <lofty       > so to integrate your functionality with the interpreter, you either write your own Forth interpreter, or modify an existing one
2026-07-23 00:17:45 <pyzozord    > 02so basically a scripting language
2026-07-23 00:17:49 <lofty       > yes
2026-07-23 00:17:59 <pyzozord    > 02but one that is like very dsl-y
2026-07-23 00:18:44 <pyzozord    > 02ok, i still dont understand why change any of the interpreter parts, when i use python or javascript or lua, i dont need to change the parts of the interpreter
2026-07-23 00:19:03 <pyzozord    > 02(again not comparing to judge, just saying i dont understand based on what i know)
2026-07-23 00:19:16 <pyzozord    > 02(in fact im quite fascinated by forth)
2026-07-23 00:19:39 <lofty       > I admit I am pulling an example out of my ass, but
2026-07-23 00:19:53 <lofty       > in something like Forth 2012, $xyz means that xyz is a hex literal.
2026-07-23 00:20:09 <lofty       > but in a piece of accounting software, you might want that to mean literal dollars.
2026-07-23 00:20:35 <pyzozord    > 02oh ok so it has to do with the dsl-y nature of forth
2026-07-23 00:20:52 <lofty       > I think the thing you might be missing is that - from my own experience of Python or Lua - you would create some new class or such to represent a value in dollars
2026-07-23 00:21:01 <lofty       > and in Forth, you would change how the interpreter parses that value
2026-07-23 00:21:13 <lofty       > because Forth does not have the concept of types or classes
2026-07-23 00:21:15 <pyzozord    > 02so i could say forth's philosophy is about creating dsl's so as part of that it opens and encourages changing parts of the interpreter itself to fit the problem domain better
2026-07-23 00:21:27 <lofty       > yes
2026-07-23 00:21:48 <pyzozord    > 02got it
2026-07-23 00:21:49 <pyzozord    > 02perfect
2026-07-23 00:21:56 <pyzozord    > 02thanks for the third time
2026-07-23 00:22:10 <pyzozord    > 02wait, now we need one more to make it whole lol
2026-07-23 00:22:22 <pyzozord    > 02to make it forth times
2026-07-23 00:24:18 <lofty       > the flipside of Forth being based around making DSLs for things is the community saying of "when you have learned one Forth, then you have learned one Forth"
2026-07-23 00:24:44 <lofty       > because every implementation and every use of Forth is going to shape its DSLs and such differently
2026-07-23 00:24:56 <pyzozord    > 02yeah i get it it's a personal language
2026-07-23 00:25:04 <pyzozord    > 02and that's what i want it for anyway
2026-07-23 00:25:31 <lofty       > a lot of Forth implementations are themselves heavily written in Forth, and so they have their own custom extensions to allow them to implement bits of Forth to suit their implementation
2026-07-23 00:26:22 <lofty       > a good example is that some Forth implementations will expose a way to access the value of the return stack pointer, and some implementations will stubbornly refuse to expose such details
2026-07-23 00:26:35 <pyzozord    > 02i guess maybe over the years some idioms, patterns and conventions were agreed on that help forth programmers understand each other?
2026-07-23 00:26:56 <lofty       > 
ACTION laughs

2026-07-23 00:27:23 <pyzozord    > 02i hear a sad laugh :p
2026-07-23 00:27:39 <lofty       > maybe a few, but consider that Chuck Moore's response to the standardisation of ANS Forth was to actively resist its usage in favour of going in a very different direction with the language
2026-07-23 00:28:01 <lofty       > Forth is, perhaps, a collection of related language dialects
2026-07-23 00:28:57 <pyzozord    > 02right
2026-07-23 00:29:45 <lofty       > people will agree that "idiomatic Forth" looks very heavily factored, but will not agree on how such code should be factored
2026-07-23 00:31:35 <lofty       > https://www.complang.tuwien.ac.at/anton/euroforth/ef00/ceballos00.pdf <-- take a look at Table 3. the second INNER-PRODUCT is in "machine Forth" as Chuck Moore would call it. even people in this channel have disagreed with how the first INNER-PRODUCT in ANS Forth is written.
2026-07-23 00:32:22 <lofty       > bluntly, even though I am somebody heavily in favour of efficient code, the Machine Forth is unreadable to me
2026-07-23 00:40:01 <pyzozord    > 02it sounds like getting forth programmers to agree is equivalent to herding cards
2026-07-23 00:40:06 <pyzozord    > 02cats*
2026-07-23 00:40:15 <pyzozord    > 02which i recognize immediately as my people lol
2026-07-23 00:41:50 <pyzozord    > 02lofty: would you recommend some bookies beside thinking forth so i can um like feel more like a native forth programmer?
2026-07-23 00:42:47 <pyzozord    > 02lofty: also another question i was wondering about. I've heard of people writing c compilers in forth, and i'm wondering is it possible to modify the forth interpreter enough to truly parse c because c is not as strict on whitespace as forth
2026-07-23 00:44:11 <lofty       > I think at that point you would want to write a C parser in Forth, rather than trying to modify the interpreter
2026-07-23 00:45:38 <lofty       > pyzozord: to be quite honest, a lot of the way I think about writing Forth code was shaped by xentrac and their post here: https://news.ycombinator.com/item?id=33264506
2026-07-23 00:46:27 <pyzozord    > 02thanks!
2026-07-23 00:47:08 <pyzozord    > 02ok so it's not possible to literally turn forth interpreter to parse anything and everything you want there are some limitation like the fundamental word tokenizer
2026-07-23 00:49:09 <lofty       > yes, you can quite heavily shape the semantics of forth, but the syntax stays as it is because Forth doesn't really have a _parser_ to modify
2026-07-23 00:49:55 <pyzozord    > 02right
2026-07-23 00:50:07 <lofty       > pyzozord: https://forth.chat/logs/libera/forth/2026-06-16 <-- look at the discussion from 20:35:48 where xentrac exposits heavily on Forth
2026-07-23 00:50:40 <pyzozord    > 02ok thanks a lot for all the answers again, and finally this is the fo(u)rth time i got help from you today hehe
2026-07-23 01:15:36 <pyzozord    > 02R  explain what this means
2026-07-23 01:15:44 <pyzozord    > 02?
2026-07-23 01:15:51 <lofty       > uh, context?
2026-07-23 01:16:01 <pyzozord    > 02ooh i'm so sorry
2026-07-23 01:16:05 <pyzozord    > 02this was meant for my ai
2026-07-23 01:16:28 <pyzozord    > 02which happens to also be in a channel with the same name
2026-07-23 01:24:10 <psf         > Question. Parsing Forth line-by-line (from a terminal) or block-by-block (as from a disk) are both convenient.  If I'm parsing Forth bufferful-at-a-time from a file, this is more troublesome, as the buffer could run out of bytes in an awkward place, like halfway through a word's name.  I think this means my file buffering has to be separate from the input buffer described by SOURCE and >IN in the Forth standar
2026-07-23 01:24:16 <psf         > d.  That sound right?
2026-07-23 01:30:34 <lofty       > well, it's also possible to write an incredibly long terminal line that overfills the input buffer, right? how do you handle that?
2026-07-23 01:33:23 <psf         > My terminal handling code has a maximum line length and new characters aren't accepted/echoed beyond that.
2026-07-23 01:34:36 <lofty       > then I think you could make an argument that you do not need to accept source that overflows the buffer as long as you REFILL every line
2026-07-23 01:41:52 <psf         > Let's say my input buffer is 120 characters and contains an 80-character Line 1 and the first 40 characters of an 80-character Line 2.  If I REFILL at the end of Line 1, wouldn't that also eat the first half of Line 2?  I guess this problem wouldn't arise if REFILL went line-by-line, and the problem becomes how to efficiently implement a REFILL that works this way.
2026-07-23 01:43:23 <lofty       > This is also a problem that e.g. libc "fgets" has to handle
2026-07-23 01:47:21 <psf         > If the input buffer is supposed to only contain complete lines, that answers my question.
2026-07-23 01:48:28 <lofty       > That would be my interpretation
2026-07-23 01:49:25 <psf         > Thanks!
2026-07-23 01:51:38 <lofty       > "When the input source is a text file, attempt to read the next line from the text-input file." - https://forth-standard.org/standard/file/REFILL
2026-07-23 01:51:58 <lofty       > Given it specifically says "line" here
2026-07-23 07:56:53 <veltas      > My hot take this morning: AI is real, is going to change everything, and yet there will be a bubble burst.
2026-07-23 07:58:39 <veltas      > You know the reason I've not been using AI is not because it's not useful, or is going to produce copyrighted content, but because I enjoy technical problems and don't want to boss around either an intern or a jagged intelligence matrix to do it for me.
2026-07-23 07:59:16 <veltas      > Also I want people to be interested in what I release and nobody is interested in AI-generated stuff.  I'm certainly not.  Will be plenty of time for that after the singularity.
2026-07-23 08:00:18 <veltas      > Or another way of looking at it: I'm interested in anything you guys write, but if you vibecoded it then you didn't write it.
2026-07-23 08:07:34 <iv4nshm4k0v > LLMs are a tool that I have little familiarity with, that I find difficult enough to familiarize myself with (have anyone here had much luck running any LLMs under Trisquel, BTW?), and whose long-term benefits remain unclear (including the "you didn't write it" part.)  As such, I have little incentive to learn it.  And as the saying goes, "any tool used without understanding, tends to become a footgun."
2026-07-23 08:07:35 <iv4nshm4k0v > (To think of it, much of the above - aside, perhaps, of the "difficult to familiarize" part - applies to my stance with regards to other now-popular things, like, say, D-bus, Rust, and Wayland.)
2026-07-23 09:01:23 <X-Scale     > Having a machine on the centralize web controlled by a few cloudalists doing all the coding for me is like asking some unknown guy in the middle of the street to have sex with my wife for me.
2026-07-23 09:01:48 <X-Scale     > I don't want to outsource all the fun and magic of doing the programming myself.
2026-07-23 09:11:26 <X-Scale     > Also I want to control the full process of coding and making the machine do exactly what I want.
2026-07-23 09:12:59 <veltas      > I think there's a lot of value in making as much of computing approachable as possible
2026-07-23 09:21:12 <veltas      > LLMs are surprisingly simple tech for what they do, but the training is beyond most of our means
2026-07-23 09:21:34 <veltas      > I do think it will be more approachable to make LLMs personal computing in the future
2026-07-23 09:37:13 <iv4nshm4k0v > I do not expect GPUs to run all-free software anytime soon, so for the time being, LLMs will most likely remain out of reach of people who try to keep their computing as free as possible.
2026-07-23 09:44:16 <veltas      > What about Vortex GPU?
2026-07-23 09:45:33 <lofty       > https://fieldprogrammable.gay/files/e5524be3-31e6-44c1-8124-27008016a7cc.png <--- well, Vortex is slopped to all fuck
2026-07-23 09:45:45 <iv4nshm4k0v > No idea?  Is it listed on http://ryf.fsf.org/ ?
2026-07-23 09:46:08 <lofty       > I have serious issues with RYF certification, tbh
2026-07-23 09:46:44 <lofty       > because, well, it does not do a very good job of respecting your freedom
2026-07-23 09:47:03 <iv4nshm4k0v > Namely?
2026-07-23 09:47:35 <lofty       > proprietary firmware is allowed, but must be in ROM, so you cannot develop free replacements for these proprietary firmwares
2026-07-23 09:48:13 <veltas      > I guess I should exit out of this conversation as I write proprietary firmware for a living :)
2026-07-23 09:50:32 <iv4nshm4k0v > "Being in ROM" does not make it impossible to develop free replacements.  It, however, ensures that the code in question is in fact /firmware/ - rather than preinstalled software.  Back in the day, RMS argued that proprietary firmware is bad, but acceptable; unlike (preinstalled) proprietary software.
2026-07-23 09:51:08 <veltas      > So if a proprietary firmware blob is needed to boot the chip then that's no good?
2026-07-23 09:51:27 <lofty       > by the very definition of it being read-only, yes, it makes it impossible to develop free replacements.
2026-07-23 09:51:39 <iv4nshm4k0v > If I need to "$ package install chip-firmware " then "chip-firmware" is software, not firmware.
2026-07-23 09:51:46 <veltas      > Because you'll get germs from it?
2026-07-23 09:52:09 <veltas      > It's not really software it's just firmware that comes from your CPU side I/O rather than SPI
2026-07-23 09:52:16 <veltas      > That's my opinion
2026-07-23 09:54:44 <veltas      > Firmware is bluring the lines
2026-07-23 09:55:20 <lofty       > I also think that requiring firmware to be in ROM makes devices actively less secure
2026-07-23 09:55:29 <veltas      > From my perspective as a firmware writer it's just software, but as a product it's essentially like hardware if it's a block box that has "one job" and it does it well enough and can't physically spy on you etc
2026-07-23 09:56:01 <veltas      > And I guess that's why the term 'firmware' exists, it's special
2026-07-23 09:56:06 <lofty       > meltdown/spectre were hardware vulnerabilities that required microcode updates
2026-07-23 09:56:30 <veltas      > You're 100% right of course lofty
2026-07-23 09:57:24 <veltas      > The free software stuff is very ideological and there are many inexplicable choices they made on the way to their definitions, yet they act like their definitions are fundamental and you are immoral if you disagree
2026-07-23 09:57:43 <iv4nshm4k0v > From where I stand, "firmware" is software-like component of a device.  Unlike software proper, it is not supposed to require regular maintenance (such as upgrades), much less obligates the device's /user/ to perform such maintenance (such as by running "# package upgrade " from time to time.)
2026-07-23 09:58:30 <veltas      > I'd rather have hardware I can upgrade than not... although updates aren't always an upgrade!
2026-07-23 09:59:13 <lofty       > it would be nice if we lived in a world where software could be considered complete
2026-07-23 09:59:39 <lofty       > https://ariadne.space/2022/01/21/the-fsfs-relationship-with-firmware.html <-- but this sums up my feelings pretty well
2026-07-23 09:59:59 <veltas      > Honestly I think you've already explained yourself quite well lofty
2026-07-23 10:00:03 <veltas      > It's not that complicated
2026-07-23 10:01:01 <iv4nshm4k0v > My microwave over, I presume, has firmware - and my Pentax K-5 DSLR definitely so.  I have no qualms with the former, and little with the latter.  Firmware proper is supposed to be sufficiently well tested, as firmware deficiency is a "manufacturing defect" to be rectified at (in part) vendor's expense.
2026-07-23 10:01:12 <veltas      > It depends on the hardware though, like a GPU for example is essentially another full computer
2026-07-23 10:01:13 <iv4nshm4k0v > Microwave oven, that is.
2026-07-23 10:01:31 <veltas      > I guarantee some microwaves get firmware updates now
2026-07-23 10:01:58 <veltas      > If you don't like it don't buy them, but for a lot of people it will be the best value for money
2026-07-23 10:02:19 <veltas      > I wouldn't buy one of those either, but I'm not a normal consumer
2026-07-23 10:05:33 <iv4nshm4k0v > I'm not trying to decide values for other people - I can only explain my own.  And to me, computers that require proprietary software - whether preinstalled or "freely downloadable," are inherently "bad."  About the only exception I make are for computer BIOS software (when in flash, it's arguably /not/ firmware), and my HP LJ 1020 printer.
2026-07-23 10:07:04 <iv4nshm4k0v > Were it Samsung refrigerators that started displaying ads on their screens after a software update a year or so ago?
2026-07-23 10:07:37 <veltas      > And that's why I wouldn't buy one
2026-07-23 10:07:46 <veltas      > Yet presumably some people do
2026-07-23 10:08:18 <X-Scale     > your home will be transformed into a Times Square before you notice it
2026-07-23 10:08:22 <veltas      > I wish I understood why you think it's 'bad' but unfortunately I don't get it
2026-07-23 10:08:34 <veltas      > I think it's bad as in not ideal, rather than immoral
2026-07-23 10:09:01 <iv4nshm4k0v > The reasons of another person are unknowable.  Discussing unknowable seems rather unproductive to me.
2026-07-23 10:09:24 <lofty       > also, I feel like even if it was open-source it would almost certainly fail iv4nshm4k0v's policy of being able to apply fixes to it
2026-07-23 10:09:34 <veltas      > Well I mean I am inviting some kind of rationalisation, but I can't force you
2026-07-23 10:12:27 <veltas      > The fact you don't feel the same way about BIOS firmware raises more questions in my head
2026-07-23 10:12:47 <veltas      > That's one place I think would be more beneficial to have more openness and understanding
2026-07-23 10:14:29 <veltas      > I don't like the fact that even your BIOS OEM is receiving a fat blob of proprietary Intel stuff before they even add their firmware, chock full of mysterious 'management engine' incantations
2026-07-23 10:15:05 <veltas      > Fortunately there are SBC's available with simpler boot firmware that aren't too expensive now
2026-07-23 10:15:09 <veltas      > Much more open hardware
2026-07-23 10:15:54 <iv4nshm4k0v > veltas: Indeed, ME is the reason I've avoided Intel mainboards for nearly two decades now.
2026-07-23 10:16:20 <lofty       > what do you run?
2026-07-23 10:20:21 <iv4nshm4k0v > That said, AMD is not much better: AIUI, as of a decade or so ago, instead of giving the BIOS writers /specifications/ to their chips, they offer a ready-to-use binary blob that you can base "your" BIOS on.  Personally, I buy Socket AM2 mainboards and DDR2 DIMMs (both secondhand now, obviously) whenever I get the chance - so I don't have to switch to that.
2026-07-23 10:20:21 <iv4nshm4k0v > Still, there's a separate category of open-source hardware.  FSF was established to promote software freedom - not other (even if also important, or related) freedoms.
2026-07-23 10:21:22 <lofty       > (actually, AMD Bulldozer chips have open-source AGESA and coreboot support. that brings you up to DDR3.)
2026-07-23 10:24:52 <iv4nshm4k0v > lofty: Yes, it seems like I've stopped being interested in AMD around the time DDR4 was introduced, but as I've mostly used DDR2 at the time, I kinda decided to stick to it.  I'd appreciate more information, and on top of that, I haven't /seen/ secondhand DDR3 hardware on sale around here, but Socket AM3 indeed seems an acceptable platform, under criteria above.
2026-07-23 10:26:46 <veltas      > I like the small cheap SBC's they're making now because they are at least a lot more approachable, if I had to fix something myself, so I value that
2026-07-23 10:27:00 <veltas      > But that said I mostly use my old thinkpad so I guess I don't value it that much
2026-07-23 10:27:35 <veltas      > One good thing about Forth is it's extremely portable so I'm not tied down to a computer or arch
2026-07-23 10:27:51 <iv4nshm4k0v > I also second the "SBCs with simpler firmware" part - I do have an Allwinner A64 based Olinuxino OSHW SBC (not /thoroughly/ OSHW, obviously - just the board design), and (yet again, under my criteria above) it sounds like the platform offers good value per cost, but I have to admit I've so far failed to quite /familiarize/ myself with it.
2026-07-23 10:29:01 <iv4nshm4k0v > I hope I'm not mistaken that Allwinner A64 firmware bootloader is indeed firmware?  I. e., ROM- and not flash-based?
2026-07-23 10:29:57 <veltas      > It's probably flash
2026-07-23 10:30:07 <iv4nshm4k0v > Why?
2026-07-23 10:30:19 <veltas      > That's just the cheap highly available option for ROM now
2026-07-23 10:30:26 <lofty       > "cover your ass"
2026-07-23 10:30:30 <veltas      > It's not ideological they just use flash everywhere
2026-07-23 10:30:59 <veltas      > It would probably be more expensive to use ROM, that's the main reason, Flash is seriously cheap and has advantage of supporting updates
2026-07-23 10:31:25 <veltas      > But if it's open or "more open" then it still is a move in right direction, surely
2026-07-23 10:35:18 <iv4nshm4k0v > Last I've checked, a number of Olinuxino boards were OSHW, with Kicad files available for download from their website.  Not that I intend to order any modified versions, so no idea how "open" they are in practice.
2026-07-23 10:37:14 <iv4nshm4k0v > FWIW, http://linux-sunxi.org/Boot_Process calls it "ROM," so there.
2026-07-23 10:38:40 <veltas      > That doesn't prove it's not Flash by any means, it's normal to call Flash 'ROM' in lots of situations
2026-07-23 10:38:55 <veltas      > Because in many places it's replaced what would have been ROM in practice
2026-07-23 10:39:44 <veltas      > These SBCs are probably a good option for you eventually when your AMD stuff gets too old, they will probably support a better personal computing experience eventually
2026-07-23 10:39:53 <veltas      > And I suspect around then I'll be using them too
2026-07-23 10:40:06 <veltas      > I hope we continue to have this open hardware / software stack
2026-07-23 10:42:52 <veltas      > It sounds like it really does use an actual ROM that's tiny to start the boot, and then the main bootloader is on Flash
2026-07-23 10:43:32 <veltas      > By bootloader I mean most of what you'd usually associate with "BIOS firmware" on an x86 system
2026-07-23 10:43:48 <iv4nshm4k0v > The "main bootloader" that I've personally used on that SBC is U-Boot, which, I believe, is free software.
2026-07-23 10:47:25 <iv4nshm4k0v > (That is, my variant of Olinuxino A64 board has none of NAND, SPI or eMMC flash options, so the only way it can boot /any/ bootloader is from a microSD card.  And the image for that card I've prepared myself, using U-boot binaries from Debian "main".)
2026-07-23 10:48:11 <veltas      > Yeah U-Boot is GPL v2 or later
2026-07-23 10:48:52 <veltas      > It's quite bad but boot firmware doesn't need to be thrilling, it just needs to get the OS kicking
2026-07-23 10:50:54 <iv4nshm4k0v > How is it "bad"?  I actually prefer "not thrilling" boot process myself.  Say, I've eventually grown tired of GRUB "smartness" on x86 and now boot my GNU/Linux installs with Syslinux exclusively.
2026-07-23 10:51:28 <veltas      > It basically implements non-volatile variables, a shell, etc, and it's all incredibly buggy
2026-07-23 10:51:36 <veltas      > There's probably loads of security holes
2026-07-23 10:51:54 <veltas      > Hopefully it's in a better state now but when I worked with it last that's how it was
2026-07-23 10:52:12 <veltas      > Upstream is probably in better shape now that it's more popular?
2026-07-23 10:53:37 <veltas      > But it probably doesn't matter for where it's used
2026-07-23 11:00:13 <iv4nshm4k0v > I certainly can't vouch for U-boot to be bug-free, but a. its shell seemed reasonably straightforward (so I don't expect to be bitten by some obscure corner cases), and b. aside of its (optional) support for network boot, I don't have a threat model under which exploitable security issues are even possible.
2026-07-23 11:07:06 <iv4nshm4k0v > U-boot claims to provide support for Syslinux(-like) configuration files, but IME "compatibility layers" like that tend to be buggy more often than not, so I'm not eager to make use of that.
2026-07-23 11:07:06 <iv4nshm4k0v > The two issues I've had with it so far are: a. NetBSD 10 fails to initialize HDMI when booted directly from U-boot, rather than through its own boot(8) (might rather be a bug in the kernel itself: NetBSD 11 RCs fail either way there); b. non-volatile variables aren't (I might've used the wrong U-boot image for my case, though.)
2026-07-23 11:10:51 <veltas      > Yeah the way that these bootloaders work, it's really unlikely that it's U-Boot's fault that HDMI isn't working
2026-07-23 11:11:05 <veltas      > It's possible but just unlikely
2026-07-23 11:12:00 <veltas      > I did give NetBSD a shot a few months ago but it is definitely more recommended for people who can maintain their own drivers and kernel
2026-07-23 11:12:22 <veltas      > I just don't have time ... and I don't know even then if I would be up to task
2026-07-23 11:20:36 <iv4nshm4k0v > Not drivers specifically, but indeed, one of the reasons I've got interested in NetBSD is to get some kernel coding experience.
2026-07-23 11:32:06 <veltas      > I hope you get to do that
2026-07-23 16:51:39 <tabemann    > .