2026-06-30 01:05:35 <Stalevar    > 3dup is still rather nice word
2026-06-30 01:05:49 <Stalevar    > and not present in gforth (so probably not standard)
2026-06-30 08:51:16 <veltas      > xentrac: It's not a bad idea, often if you can factor something with vars enough then basic stack ops become obvious
2026-06-30 08:51:23 <veltas      > It's how I write stuff sometimes
2026-06-30 08:51:49 <veltas      > Although with experience I have some intuition for when stack will be easier in the first place
2026-06-30 09:20:08 <xentrac     > yeah, that makes sense
2026-06-30 09:21:55 <xentrac     > I just think the baseline of how bad things get when you use too many variables is not too bad
2026-06-30 09:22:32 <xentrac     > while the baseline of how bad things get when you try to avoid using variables is roughly unboundedly bad
2026-06-30 09:23:01 <xentrac     > especially for beginners
2026-06-30 10:57:30 <veltas      > That's sort of the argument I make in an upcoming article
2026-06-30 18:37:30 <iv4nshm4k0v > Just heard that Git moves to require Rust.  Assuming it's not some FUD, I kinda hope that the last Rust-free version will remain in pkgsrc for a while.  (Not unlike how pkgsrc still has, e. g., editors/emacs21.)  For both the reason of portability, and the fact that Rust has been a .so-deficient language last I've checked.
2026-06-30 18:39:38 <veltas      > Ultimately I guess if you want git on arch's not supported you'd need to use an older version of .git, which should hopefully work indefinitely
2026-06-30 18:40:09 <veltas      > Although may leave you open to security issues, but with an exotic arch that could be unlikely
2026-06-30 18:40:27 <veltas      > Could fix issues yourself though
2026-06-30 18:40:57 <veltas      > Or make your own git as git is fundamentally simple at the core and can be sort of hacked together in an inferior way with an okay diff etc
2026-06-30 18:49:03 <xentrac     > or use Dulwich
2026-06-30 18:57:49 <iv4nshm4k0v > I typically audit my systems for known vulnerabilities by a. checking what shared libraries are /installed/; and b. checking that no older (uninstalled) versions of shared libraries are still mapped in processes' address space.
2026-06-30 18:57:50 <iv4nshm4k0v > This approach cannot be applied to code that relies on static linking - I must actually check what versions of Rust libraries were used when package was built.  Debian (APT, dpkg) has the Built-Using: header for tracking such compiled-in code (and while it often will be correct, it's not quite /guaranteed/); other package managers might not have even that.
2026-06-30 19:00:27 <iv4nshm4k0v > It's also possible that, say, Debian will end up adopting GCC Rust compiler - which I expect to be more portable /and/ to support dynamic linking - but I'm not holding my breath for it.
2026-06-30 19:01:08 <lofty       > iv4nshm4k0v: your information about instruction sets supported by Rust is out of date.
2026-06-30 19:01:45 <lofty       > And gccrs is a laughing stock. try looking at rustc_codegen_gcc
2026-06-30 19:05:20 <iv4nshm4k0v > lofty: If you have better information, please provide it.
2026-06-30 19:06:51 <lofty       > iv4nshm4k0v: https://doc.rust-lang.org/rustc/platform-support.html
2026-06-30 19:07:02 <veltas      > xentrac: Yeah that's a good one
2026-06-30 19:07:03 <lofty       > Up to and including m68k support
2026-06-30 19:07:21 <iv4nshm4k0v > (I hope to avoid forking Git because I feel I will have more than enough work just maintaining an APT fork.)
2026-06-30 19:08:39 <lofty       > I understand the point of view people have about bad platform support, but Rust supports everything LLVM does, and the project is working on codegen backends like cranelift and libgccjit
2026-06-30 19:09:48 <lofty       > I also understand the point of view that people have about "Rust not having a stable ABI", but Rust does have a stable ABI, the C ABI.
2026-06-30 19:11:31 <lofty       > C++'s ABI is not guaranteed to be stable either; remember that it broke with C++11. But nobody complains about the C++ ABI not being stable.
2026-06-30 19:12:51 <lofty       > (sorry, this is an argument I have had very often)
2026-06-30 19:13:28 <iv4nshm4k0v > lofty: I've been meaning "Tier 1" targets - the ones "guaranteed to work": i386 (MSVC, GNU/Linux), amd64 (MinGW, MSVC, GNU/Linux) and aarch64 (macOS, MSVC, GNU/Linux.)  I'm not sure that "Tier 2" (or "Tier 3") support is quite acceptable for "core" parts of your system or distribution.
2026-06-30 19:14:08 <veltas      > Not really the same with C++, they changed ABI because it was fundamentally broken and there's no 'guarantee' but hell would be raised if they changed it again
2026-06-30 19:14:27 <veltas      > They got to change it for free essentially, and even then it was painful and a "once in a generation" deal
2026-06-30 19:15:25 <lofty       > iv4nshm4k0v: then you do not understand the tier system; Tier 1 targets are Tier 1 targets because they have modern, readily-available CI hardware. Would you trust someone's 30 year old Amiga for your stability guarantees?
2026-06-30 19:15:35 <veltas      > I'd be interested in opinion of someone who's actually had to develop Rust on one of the less supported arch's
2026-06-30 19:15:42 <veltas      > Proof is in the pudding
2026-06-30 19:15:56 <veltas      > At least with an Amiga emulators can probably be used
2026-06-30 19:16:26 <lofty       > In a CI flow? Most emulators are not headless like that would require.
2026-06-30 19:17:50 <iv4nshm4k0v > If it runs stable on one's 30-year old computer, why would it fail on a newer one?  Unless the newer one is, somehow, less reliable - which, in a way, /is/ the case (what with TPM and proprietary everything.)
2026-06-30 19:20:24 <lofty       > That every single code change would never ever break on this 30-year-old computer?
2026-06-30 19:20:27 <lofty       > That someone has to debug a crash that only happens on a 30-year-old computer?
2026-06-30 19:20:41 <veltas      > Someone does have to debug it if it's going to be used
2026-06-30 19:20:56 <veltas      > But I understand if Rust team don't want to take responsibility for that
2026-06-30 19:21:18 <veltas      > But also understand why iv4nshm4k0v might not want to use a lang where that's the way priorities fall
2026-06-30 19:21:29 <lofty       > Tier 1 means that every single change passes the Rust test suite
2026-06-30 19:21:58 <lofty       > I'm not sure GCC has that standard of quality
2026-06-30 19:22:04 <veltas      > Also emulators can be setup that way either by modifying the emulator, or if it's separated out into libraries using the library.  And I think e.g. qemu supports most of these and can be done in that way
2026-06-30 19:22:04 <lofty       > So I guess we shouldn't use it either...
2026-06-30 19:22:21 <veltas      > That's a good point
2026-06-30 19:22:37 <veltas      > I've noticed serious quality drop off even with stuff like PPC on GCC
2026-06-30 19:23:00 <veltas      > Although I think they'd fix any codegen bugs pointed out to them
2026-06-30 19:23:20 <lofty       > So will the Rust project (or more likely LLVM, but)
2026-06-30 19:24:06 <veltas      > I've read and debugged GCC and it wasn't impossible, a few times I've tried to understand LLVM and couldn't get into it
2026-06-30 19:24:29 <veltas      > So I might be too dumb to maintain LLVM for myself, maybe not GCC.  Both of them are too big to build on my laptop anyway.
2026-06-30 19:25:36 <veltas      > I think Rust is okay though from what I've seen.  It scratches an itch that C++ used to scratch, but it scratches it a lot better in most cases.
2026-06-30 19:25:41 <iv4nshm4k0v > My chief issue is that Rust goes against my security practices - by requiring static linking.  I've never tried gccrs, but if it allows shared libraries, that's a huge point in its favor for me.
2026-06-30 19:26:19 <veltas      > I think Rust does allow dynamic linking, it's just not done that way in most codebases and it won't be adopted by distros etc
2026-06-30 19:26:36 <veltas      > And it requires some changes in how code is done, and probably would upset a lot of rust devs
2026-06-30 19:27:43 <iv4nshm4k0v > Thus making the point moot.  If Rust does allow dynamic linking, but all the Rust-based Debian packages will still stick to static, then I'm still on square one: I cannot apply my security practices to such packages.
2026-06-30 19:35:47 <iv4nshm4k0v > Another point is that I do not know Rust, so cannot edit Rust code myself.  If C code breaks, I can, at times, fix it myself; if Rust code breaks, I'll have to find a replacement.  I presume I can /learn/ Rust - but the way it gets in the way with its (whether it's Rust proper, or the devs' community) insistence on static linking, I don't have much incentive to do so.
2026-06-30 19:35:47 <iv4nshm4k0v > The end result is that I try to avoid /relying/ on Rust code at all costs.
2026-06-30 19:47:07 <Stalevar    > iv4nshm4k0v, it sounds like you are maintaining a deb-based distro or something?
2026-06-30 19:47:13 <Stalevar    > If you have your own fork of apt
2026-06-30 19:49:57 <veltas      > iv4nshm4k0v: It's not entirely moot, because it may apply in git, I don't know how they'll use it but git's presumably only using C dependencies anyway (which I think can automatically be dynamically linked into Rust), and the Rust portion might be isolated to a portion that is essentially dynamically linkable anyway
2026-06-30 19:50:29 <veltas      > So just because they're using Rust doesn't automatically make them non-dynamic, especially given where they're starting
2026-06-30 20:00:15 <iv4nshm4k0v > I've /guessed/ that one of the reasons for requiring Rust might be to make use of (third-party) Rust libraries.  Would that not be the case, the use of Rust in Git would of course be less of a problem to me personally.
2026-06-30 20:00:15 <iv4nshm4k0v > Stalevar: I /intend/ to fork APT.  Other than that, I do effectively maintain a (private) Debian derivative.  E. g.: "$ ls -l -- /usr " is "lrwxrwxrwx 1 root root 1 Oct 17  2025 /usr -> ." on my system - you won't find that on a stock Debian Trixie install.
2026-06-30 20:02:13 <Stalevar    > What does it mean /usr symlinked to .? Like usr move but other way around?
2026-06-30 20:02:29 <iv4nshm4k0v > Exactly.
2026-06-30 20:02:38 <iv4nshm4k0v > And my understanding is that I won't be able to use APT from Debian Forky, hence the intent to start a fork.
2026-06-30 20:02:39 <Stalevar    > But why not to / ?
2026-06-30 20:03:14 <Stalevar    > Why not /usr -> /
2026-06-30 20:05:26 <iv4nshm4k0v > Because I sometimes mount "/" of one of my systems, on some other system, somewhere.  That way, /mnt/recovery/foobar/usr/bin points to /mnt/recovery/foobar/bin , not /bin.
2026-06-30 20:25:22 <veltas      > iv4nshm4k0v: I'd guessed it was because Rust is new and shiny, but I literally know nothing about it
2026-06-30 20:25:38 <veltas      > That's essentially the reason Linus gave for it going in Linux
2026-06-30 20:34:39 <lofty       > veltas: do you mean you know nothing about Rust? sorry, having slight issues with that sentence in my tired headspace
2026-06-30 20:35:49 <iv4nshm4k0v > Rust isn't exactly "new" - see, e. g., http://en.wikipedia.org/wiki/Rust_(programming_language)#History .  Rust has been adopted by a few projects I've (formerly) been interested in - that usually resulted in them suddenly having dozens of Rust libraries as their dependencies.  It isn't given that it will happen to Git, granted, but there's no guarantee it /won't/ happen, either.
2026-06-30 20:35:49 <iv4nshm4k0v > Linux is one of the few exceptions to my general rule of "do not adopt software unless you're somewhat confident to be able to do at least minor fixes to it."  (And the existence of this exception is one of the reasons behind my interest in NetBSD.)  So while I'm not eager to see Rust in Linux, I suppose I can live with it.
2026-06-30 20:37:58 <veltas      > lofty: I know little about Rust and nothing about git's decision to use Rust
2026-06-30 20:38:08 <lofty       > iv4nshm4k0v: have you ever actually used the Rust compiler?
2026-06-30 20:38:49 <iv4nshm4k0v > No.
2026-06-30 20:39:51 <lofty       > I think you will find that you can meet the standard of "somewhat confident to be able to do at least minor fixes to it" simply by following the compiler help text.
2026-06-30 20:40:02 <veltas      > I doubt that
2026-06-30 20:40:52 <veltas      > Well I guess that and google
2026-06-30 20:41:11 <veltas      > And IRC maybe, don't know how helpful they are
2026-06-30 20:41:50 <lofty       > https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=c86fbdd4c5c25dc0a675feb6322eb402
2026-06-30 20:41:56 <lofty       > Okay, follow the compiler instructions
2026-06-30 20:43:54 <veltas      > I mean stuff like all the different kinds of lifetimes don't really make sense without reading the tutorial
2026-06-30 20:44:47 <veltas      > The fact that the lifetime of a reference can end before its scope ends is maybe a bit confusing because code that looks similar will work and the borrow checker errors don't really explain that part
2026-06-30 20:44:51 <veltas      > Stuff like that
2026-06-30 20:44:53 <lofty       > Um. You don't need to write the lifetimes unless you're writing incredibly hairy code. The lifetime elision rules are common sense
2026-06-30 20:45:04 <veltas      > lifetimes come up literally everywhere
2026-06-30 20:45:10 <lofty       > They literally don't
2026-06-30 20:45:18 <xentrac     > that's literally nonliteral
2026-06-30 20:45:27 <veltas      > This is where lifetime elision doesn't apply, or there wouldn't be an error ... usually
2026-06-30 20:45:37 <iv4nshm4k0v > Like I've said, until Debian starts providing Rust-based packages that properly use dynamical linking (.so libraries), there's little practical reason for me to touch Rust at all.
2026-06-30 20:45:37 <iv4nshm4k0v > To stress it out: I'm going to avoid statically-linked Rust software on my systems (except for, possibly, Linux.)  So far, it seems all Rust software in Debian is like that.  If I don't /use/ software written in Rust, why would I be interested in fixing it?
2026-06-30 20:46:35 <lofty       > Your argument is highly nonsensical, but, you do you
2026-06-30 20:47:05 <lofty       > Do you understand why people are using Rust? That seems like a good place to start
2026-06-30 20:47:11 <xentrac     > it seems reasonable to me
2026-06-30 20:47:55 <xentrac     > lofty: I think iv4nshm4k0v just values different things than you do, possibly due to different experiences and possibly due to different terminal preferences
2026-06-30 20:48:17 <veltas      > xentrac: "literally" of course I don't mean literal literal, just 'lots', excuse my slang
2026-06-30 20:48:30 <xentrac     > literally figurative
2026-06-30 20:49:05 <xentrac     > "literally" is following the semantic-bleaching footsteps of "really" and "very"
2026-06-30 20:49:10 <veltas      > lofty: You're being a bit condescending, iv4nshm4k0v probably does know about these arguments
2026-06-30 20:50:01 <veltas      > xentrac: figurative is a better word to use, I couldn't think of it, rather than exiting the conversation entirely I decided to use a word that was in my head knowing that it wasn't entirely right but that people would probably understand
2026-06-30 20:50:03 <oak         > "semantic-bleaching" -- I like that.
2026-06-30 20:50:04 <xentrac     > I think Rust has a lot of advantages, but it's not a panacea
2026-06-30 20:50:31 <oak         > I don't love the cultural shift toward casual hyperbole.
2026-06-30 20:50:35 <iv4nshm4k0v > I have explained why I do /not/ use Rust.  If there're flaws with my argument - if it's in fact easy enough to query a binary built from Rust source for versions of the libraries it was statically linked with - I'd be interested in knowing such a way.  Otherwise, arguments that make sense to one person do not always make sense to another person.  I can live with that.
2026-06-30 20:50:54 <xentrac     > veltas: as a Priest of English Usage I tell you your sins are forgiven
2026-06-30 20:51:00 <veltas      > Thanks xentrac
2026-06-30 20:51:28 <xentrac     > oak: I think it's more a linguistic shift than a cultural one.  do you know about the etymology of "very"?
2026-06-30 20:51:46 <iv4nshm4k0v > Related to Latin for "truth", perchance?
2026-06-30 20:51:59 <lofty       > veltas: iv4nshm4k0v directly said they had not used the Rust compiler. I do not think it so obvious that somebody disinterested in the language understands why people might use it. But, whatever.
2026-06-30 20:53:12 <oak         > xentrac: I suspect verily / German wahr!
2026-06-30 20:53:32 <veltas      > lofty: Yeah but it's just litera--- figuratively everywhere you see about Rust, in the manuals, branding, marketing, videos, blogs, online discussion, mailing lists etc
2026-06-30 20:53:35 <xentrac     > oak: originally it meant "literally": https://archive.org/details/oedxbarch/page/n168/mode/1up
2026-06-30 20:53:44 <oak         > Why do you think it's more of a linguistic shift than a cultural one? (I don't know that I fully appreciate the difference.)
2026-06-30 20:54:00 <lofty       > veltas: which you assume they've seen and read.
2026-06-30 20:54:43 <veltas      > I think it's safe to assume if he knows by Rust we're not talking about the thing metal turns into
2026-06-30 20:55:13 <xentrac     > second example: "Warraiman and godd warrai", meaning "literally man and literally God"
2026-06-30 20:56:35 <veltas      > That is interesting
2026-06-30 20:57:01 <xentrac     > to the list we can add "indeed", which also meant, more or less, "literally"
2026-06-30 20:57:09 <veltas      > I'm not surprised the same thing has happened, language seems to be full of similar shifts and cycles
2026-06-30 20:57:38 <xentrac     > I'm reminded because one of the other quotations on that page is "Thre of the greatest ydolis,...verray ydolis in deid"
2026-06-30 20:57:54 <xentrac     > which I think means "idols"
2026-06-30 20:57:59 <oak         > xentrac: Ah. I was thinking about a much shorter timespan than you I think. ;)
2026-06-30 20:58:25 <veltas      > I like the nuncle -> uncle cycle and wonder when we'll start saying nuncle again.
2026-06-30 20:58:34 <oak         > Where I've been seeing people use more hyperbolic wording.
2026-06-30 20:59:25 <xentrac     > oak: there are some surviving uses of "very" in such a sense.  my grandmother, to express shock, used to say "the very idea!"
2026-06-30 20:59:58 <xentrac     > which I think I can unpack as "I am shocked at just the idea itself, much less its practical realization"
2026-06-30 21:00:05 <oak         > Unrelated: I've been poking at RetroForth lately and it's been really interesting! I like some of the design choices it makes, especially around having word namespaces (vs. Forth's "big bag of words" approach).
2026-06-30 21:00:15 <oak         > Unfortunately the site keeps on going down for me :'(  https://retroforth.org/
2026-06-30 21:00:24 <veltas      > It's just word inflation
2026-06-30 21:00:37 <xentrac     > maybe crc has a bug in his RetroForth server
2026-06-30 21:00:44 <veltas      > Forth has some pretty horrific word inflation
2026-06-30 21:01:00 <iv4nshm4k0v > http://web.archive.org/web/2027/http://retroforth.org/ ?
2026-06-30 21:01:32 <veltas      > In Forth 2028 DUP will be a NOP and 2DUP will only put 1 thing on the stack
2026-06-30 21:01:50 <xentrac     > we'll have to start printing 3DUP
2026-06-30 21:01:57 <veltas      > SWAP will be a no-op too and ROT will swap the top two elements
2026-06-30 21:02:10 <oak         > Yesterday I was noodling with writing some C-style string routines in GForth, and, stars, I really do find them much more enjoyable to work with than counted strings! 50% fewer things to manage on the stack. :3
2026-06-30 21:02:28 <xentrac     > that's surprising!
2026-06-30 21:02:44 <xentrac     > you might be interested in: https://theforth.net/package/stringstack Ulrich Hoffmann’s "stringstack" package for #Forth, “based on a string stack implementation by Klaus Schliesiek from 1986”
2026-06-30 21:02:48 <xentrac     > (from my bookmarks)
2026-06-30 21:03:16 <veltas      > PAD is my string stack
2026-06-30 21:03:21 <veltas      > a string stack of 1
2026-06-30 21:03:22 <xentrac     > legit
2026-06-30 21:03:33 <xentrac     > or, as the teenagers seem to be saying now, "real"
2026-06-30 21:03:47 <oak         > xentrac: wooaah, string stack
2026-06-30 21:04:14 <oak         > That's interesting.
2026-06-30 21:04:27 <oak         > I find it very hard to read with the choice of " as a word prefix though, ha ha.
2026-06-30 21:04:50 <oak         > But that looks pretty pleasant to work with.
2026-06-30 21:05:04 <xentrac     > heh
2026-06-30 21:05:38 <oak         > I think you could have a basically identical word set using char* pointers on the regular stack though. I'm not sure I see the benefit of having a separate stack to manage just for strings.
2026-06-30 21:05:52 <veltas      > crc: Getting a certificate issue on retroforth.org
2026-06-30 21:05:52 <xentrac     > oh, for lifetime management
2026-06-30 21:06:16 <xentrac     > adding more stacks is a pretty general way to add new types of objects to Forth
2026-06-30 21:06:19 <crc         > veltas: checkjng into it now
2026-06-30 21:06:34 <xentrac     > it sort of makes the language statically typed
2026-06-30 21:06:47 <oak         > Yeah I haven't enjoyed that pattern.
2026-06-30 21:06:59 <xentrac     > and then you need type conversion operators to move things between the stacks
2026-06-30 21:07:07 <oak         > xentrac: Lifetime management? As in, being able to free the string memory?
2026-06-30 21:07:11 <xentrac     > yes
2026-06-30 21:07:14 <oak         > 
ACTION nods

2026-06-30 21:07:22 <oak         > That makes sense.
2026-06-30 21:08:19 <oak         > I already avoid the floating point stack because I find it awkward, personally.
2026-06-30 21:08:34 <xentrac     > when you need it, you need it
2026-06-30 21:09:10 <oak         > I can't argue with that logic!
2026-06-30 21:09:28 <xentrac     > it's tautological!
2026-06-30 21:11:13 <veltas      > oak: RetroForth and konilo are developed by crc, in case you didn't know
2026-06-30 21:12:20 <veltas      > I've mostly played with konilo and I think that's pretty cool, both are some of the better non-classic Forths you'll find
2026-06-30 21:12:44 <veltas      > Yet both 'retro' in some ways
2026-06-30 21:16:44 <crc         > veltas: I did a manual renewal of the certs and restarted the server processes
2026-06-30 21:17:04 <veltas      > Works here now
2026-06-30 21:17:24 <veltas      > Just checked because oak mentioned not being able to access the site
2026-06-30 21:18:52 <veltas      > For some reason I couldn't access on HTTP either
2026-06-30 21:19:02 <veltas      > Was receiving a blank response
2026-06-30 21:19:10 <veltas      > Now HTTP works though
2026-06-30 21:51:17 <oak         > veltas: Oh neat -- I did not know that.
2026-06-30 22:00:27 <crc         > I'm assuming it was under heavier than normal load; I flipped it to the backup openbsd httpd daemon instead of casket for now.
2026-06-30 22:05:48 <xentrac     > not surprising it was dead if you were using casket
2026-06-30 22:09:22 <crc         > Casket works fine most use of the time; my sites don't get a lot of traffic normally
2026-06-30 22:13:19 <veltas      > Has anyone else got feeling (or actual stats) that Forth is getting more attention recently?
2026-06-30 22:13:51 <veltas      > Like I've seen loads of videos appearing on YouTube about it
2026-06-30 22:14:02 <veltas      > Interest in other forums too
2026-06-30 22:15:39 <crc         > I've noticed more mentions of it in the limited browsing I do than I had been seeing last year