2024-11-05 16:50:53 <veltas      > I've not heard of eBPF until today, maybe a fun idea to write a Forth for it?
2024-11-05 16:50:57 <veltas      > Not sure how well it would work with the model, the motivation is it seems to let you write certain kinds of runtime loaded modules for the kernel(?)
2024-11-05 16:51:06 <veltas      > For the Linux kernel, and maybe other OS's too
2024-11-05 16:52:13 <veltas      > vms14: The first AI related doc I saw in there was comparing it with other good AI languages and saying how Forth does not have those qualities
2024-11-05 16:52:19 <veltas      > Really comparing with Lisp
2024-11-05 16:52:34 <veltas      > And I agree with their conclusion really
2024-11-05 16:53:12 <veltas      > Although the whole AI-Lisp association is pretty outdated now, these days Forth is as good as anything for what people call 'AI'
2024-11-05 16:55:07 <veltas      > cp-: They want you joining this one, not #forth, that's why
2024-11-05 16:55:15 <lispmacs[work]> something maybe of interest:
2024-11-05 16:55:21 <lispmacs[work]> https://github.com/ambyshframber/avc2
2024-11-05 16:55:29 <lispmacs[work]> found it on gemini://ambylastname.xyz/avc2
2024-11-05 17:01:03 <GeDaMo      > Remeber the Crowdstrike problem earlier this year? They have a Linux version of their software which uses eBPF and wasn't affected, funny that :P
2024-11-05 17:01:34 <Zarutian_iPad> because eBPF is sanely designed?
2024-11-05 17:01:58 <GeDaMo      > Well, it doesn't let you run arbitrary machine code in kernel space anyway
2024-11-05 17:02:10 <veltas      > I wondered if that was related
2024-11-05 17:02:43 <veltas      > I know Crowdstrike has messed up Linux as well, so they are still able to screw it up, but not in same way
2024-11-05 17:02:49 <Zarutian_iPad> it was plus the CrowdStrike did not parse their files with robust patsers
2024-11-05 17:03:29 <veltas      > lispmacs[work]: Have they written an OS for it?
2024-11-05 17:04:36 <thrig       > "a runtime array bounds check was missing in the Content Interpreter"
2024-11-05 17:05:47 <lispmacs[work]> veltas: I don't think so, but maybe depends what you mean by that. You pass an AVC2 rom file to the avc2 executable
2024-11-05 17:06:11 <veltas      > I mean have they got a ROM file or tape image for an OS yet
2024-11-05 17:06:36 <lispmacs[work]> like, bare bones?
2024-11-05 17:07:21 <veltas      > Well an OS or anything, like any programs
2024-11-05 17:07:33 <veltas      > THey've got a hello world program in the repo
2024-11-05 17:08:03 <lispmacs[work]> yeah, I see a few roms there
2024-11-05 17:08:10 <lispmacs[work]> in examples directory
2024-11-05 17:08:29 <lispmacs[work]> here are the links to the tools:
2024-11-05 17:08:41 <lispmacs[work]> https://github.com/ambyshframber/a2asm
2024-11-05 17:08:48 <lispmacs[work]> https://github.com/ambyshframber/avdrw
2024-11-05 17:08:53 <lispmacs[work]> https://github.com/ambyshframber/a2xxd
2024-11-05 17:08:56 <veltas      > Only saw one assembly source code file
2024-11-05 17:09:04 <Zarutian_iPad> re eBPF forth: isnt eBPF pra level only?
2024-11-05 17:09:21 <Zarutian_iPad> primitive recursive algorythmd
2024-11-05 17:09:29 <Zarutian_iPad> s/md/ms/
2024-11-05 17:09:49 <thrig       > https://thrig.me/tmp/clownstrike.pdf
2024-11-05 17:10:53 <lispmacs[work]> author says "avc2 was never meant to be a proper cpu, just an experiment to improve where uxn failed"
2024-11-05 17:11:42 <veltas      > lispmacs[work]: I don't see any interesting programs written in it yet
2024-11-05 17:11:47 <Zarutian_iPad> where did uxn fail?
2024-11-05 17:12:39 <lispmacs[work]> veltas: you might have to write some ;)
2024-11-05 17:12:52 <veltas      > A point I'd make about little VMs is it's easy to make a little VM, but it's also easy to write that little VM's ops in assembly for a real, big, scary machine that I actually own and can run billions of things a second on; and I'd be writing in the same language on either machine: Forth.
2024-11-05 17:13:43 <veltas      > I think some people enjoy tiny/retro machines, which I get, but I think it's interesting that Forth will work on both
2024-11-05 17:13:47 <lispmacs[work]> Here's a little more description if you don't use gemini
2024-11-05 17:13:48 <lispmacs[work]> https://0x0.st/XDr9.txt
2024-11-05 17:14:34 <Zarutian_iPad> right. Ya seen my FCPU-16 VM spec? it is small as hell and occasationally I like to continue implementing it in vectorized form (many vm instances)
2024-11-05 17:15:45 <veltas      > Which is why at the moment, I'm interested in using Forth for those small/cute projects, but I'd like to produce e.g. AMD64 binaries
2024-11-05 17:15:53 <Zarutian_iPad> it is forcing me to learn risc-v vector instructions
2024-11-05 17:16:12 <veltas      > RISC-V version is in the post
2024-11-05 17:17:08 <Zarutian_iPad> lots use of gather, scatter, and ?: vector instructions
2024-11-05 17:17:32 <veltas      > What I'll also say is uxn stuff is much more interesting to me because the *cool* bit, the programs, actually exist and are fun.  The architecture itself might not be perfect, but I think that matters less than actually having cool demos
2024-11-05 17:18:12 <veltas      > And as neauoire has said before on here, the imperfections are part of the fun anyway, and I do agree.  It's characteristic of every real CPU arch to have rough edges
2024-11-05 17:18:41 <veltas      > Zarutian_iPad: That is very interesting to me, is that code available somewhere?  The vectorised VM?
2024-11-05 17:19:11 <Zarutian_iPad> the rough edges often indicate to me there is an sort of ideas impedence mismatch somewhere in its design
2024-11-05 17:19:30 <veltas      > But it's more 'realistic', if that makes sense
2024-11-05 17:19:45 <veltas      > All the 8-bit arch's had loads of weird problems that just add to their charm
2024-11-05 17:20:13 <Zarutian_iPad> only as an notes gist and I am only like four instructions in in the implementation
2024-11-05 17:20:58 <veltas      > It's still interesting if you're open to sharing it, understand if not
2024-11-05 17:21:09 <veltas      > Although I won't get to read it in detail right away
2024-11-05 17:21:23 <Zarutian_iPad> basically, one loop with vector instructions to implement one vm instruction cycle
2024-11-05 17:22:02 <Zarutian_iPad> it is more like translating register2register level description of the vm core
2024-11-05 17:22:28 <veltas      > Does it run concurrent VM's in those different vector elements?
2024-11-05 17:22:38 <Zarutian_iPad> yebb
2024-11-05 17:22:58 <veltas      > I find SIMD really fascinating, it's something I've got barely any experience with
2024-11-05 17:23:56 <veltas      > I used it once to optimise an embarrasingly parallel problem and just loved the whole experience, but haven't bothered since
2024-11-05 17:24:31 <veltas      > Would you say that RISC-V's approach to SIMD is quite different?  I was a little concerned by their approach of allowing it to be entirely external to the CPU
2024-11-05 17:25:09 <veltas      > Or does it not make a lot of difference in how you vectorise stuff?
2024-11-05 17:25:24 <Zarutian_iPad> it isnt any diffrent from what I have seen of x86
2024-11-05 17:25:28 <veltas      > Nice
2024-11-05 17:25:39 <veltas      > I'm probably getting the wrong impression then
2024-11-05 17:26:08 <veltas      > I find the RV spec quite confusing to read
2024-11-05 17:26:16 <Zarutian_iPad> basically there are different ways to implement them in hw as far as I cantell
2024-11-05 17:26:57 <Zarutian_iPad> as an co proc, as internal to the core, or virtualized
2024-11-05 17:27:01 <veltas      > I wish arch specs were all the same, like a manual of CPU instructions, but a lot of new stuff is written like some kind of research paper (e.g. wasm and RV)
2024-11-05 17:27:14 <veltas      > And it doesn't really aid in understanding
2024-11-05 17:27:30 <veltas      > Also the encoding is quite often kept very 'separate', which doesn't benefit anybody
2024-11-05 17:27:38 <Zarutian_iPad> yeah, the documentation has too much academia flavor to it
2024-11-05 17:27:56 <veltas      > Feels a lot like "My first LaTeX project" rather than a serious arch
2024-11-05 17:28:04 <veltas      > I know, very subjective
2024-11-05 17:28:32 <Zarutian_iPad> it is far from the gold standard of IBM 390 Principals of Operations
2024-11-05 17:28:43 <veltas      > lol I'll have to check it out
2024-11-05 17:31:17 <Zarutian_iPad> the risc-v project or supporters should get technical writers to transform the docs into say mcu datasheet format
2024-11-05 17:31:35 <veltas      > That should be the master document really
2024-11-05 17:31:58 <veltas      > 'MCU datasheet format' is that way for a reason
2024-11-05 17:32:53 <Zarutian_iPad> the thing is that a lot of risc-v stuff is still being specified or being designed/determined/decided-on
2024-11-05 17:33:28 <Zarutian_iPad> but the feature detection design is robust
2024-11-05 17:33:36 <veltas      > I think we're at a point where RV is exposed enough that they need to start locking things down, rather than going for perfection
2024-11-05 17:34:26 <Zarutian_iPad> the base instruction set is very well defined and locked down
2024-11-05 17:35:14 <veltas      > I think they should lock down RV64GCV or whatever it's called, I can never remember the convention
2024-11-05 17:35:21 <Zarutian_iPad> the simd was recently decided on
2024-11-05 17:35:25 <veltas      > Good
2024-11-05 17:35:50 <veltas      > Sounds encouraging
2024-11-05 17:36:32 <veltas      > If they don't choose stuff then industry will choose it for them eventually
2024-11-05 17:36:41 <Zarutian_iPad> its just like any other protocol spec or such, it takes time to argue it out in committee
2024-11-05 17:36:45 <veltas      > Reminds me of AMD64
2024-11-05 17:37:16 <veltas      > Probably better that way, I'd guess a SoC OEM would do better job than committee anyway
2024-11-05 17:37:37 <GeDaMo      > Does RISC-V SIMD have mask registers?
2024-11-05 17:37:41 <Zarutian_iPad> it is a committee of oem socs
2024-11-05 17:38:10 <Zarutian_iPad> GeDaMo: yeb or at least the same functionality
2024-11-05 17:38:23 <GeDaMo      > Yeah
2024-11-05 17:38:43 <Zarutian_iPad> otherwise I could not vectorise my vm implementation
2024-11-05 17:39:30 <Zarutian_iPad> lots of ?: equivs required
2024-11-05 17:39:43 <Zarutian_iPad> (the C trinary op)
2024-11-05 17:42:55 <xentrac     > veltas: you can't really lock RISC-V down; the whole point is that you can hack on it however you want
2024-11-05 17:44:24 <Zarutian_iPad> xentrac: the base instruction set is so you can do feature detection by checking certain priviledged hw registers
2024-11-05 17:45:12 <veltas      > I don't think that's the "whole point", and I think having the full flexibility is probably not that useful or applicable.  But I wouldn't suggest that the spec ignore tiny low-transistor subsets.
2024-11-05 17:45:33 <veltas      > But it feels like there's a bit of bikeshedding gone on with feature selection
2024-11-05 17:46:41 <Zarutian_iPad> hence the different ?spec? lettering
2024-11-05 17:47:31 <veltas      > My gut feeling is that 20 years down the road your average consumer will not be reading the 10-20 feature letters they need for their OS and games of choice
2024-11-05 17:47:48 <Zarutian_iPad> heard vague rumors of matrix multiplcation addons for risc-v
2024-11-05 17:48:48 <Zarutian_iPad> veltas: that is 20-30 years down the road and the feature detection that the compilers and such put in the binaries will ?paper over? it
2024-11-05 17:48:55 <veltas      > So this whole system will become over-complicated and redundant nonsense by then, there will probably instead be a couple of features for embedded SoCs of interest, if they even exist in 20 years, and the mainline "bells-and-whistles" core that includes everything you'd expect from a desktop CPU
2024-11-05 17:49:27 <Zarutian_iPad> but I look at risc-v as sort of high mid range mcu core spec at the moment
2024-11-05 17:49:31 <veltas      > And a load of stuff that's "supported" in microcode and runs like ass, so the feature detection will probably be more harm than good by then anyway
2024-11-05 17:49:39 <thrig       > what, no firmware updates to fix the latest intel flaw??
2024-11-05 17:50:52 <veltas      > Zarutian_iPad: RISC-V for me the attraction is an open arch, breaking away from Intel and ARM
2024-11-05 17:50:53 <veltas      > And I hope, but don't expect, it to replace Intel and ARM in desktop, mobiles, embedded
2024-11-05 17:51:44 <GeDaMo      > Can't I just make my own chips? :P
2024-11-05 17:52:16 <thrig       > sure, it's just expensive and etc.
2024-11-05 17:53:34 <Zarutian_iPad> veltas: the current x86 crap is over complicated today. I look at risc-v as improvement as stuff could actually run instead of just erroring out.
2024-11-05 17:54:17 <veltas      > As a real life example of this confusion, and the reason I've moaned, when I looked at writing a RISC-V Forth I realised that at the very least I'd need one for embedded and one for 'desktop' grade CPUs
2024-11-05 17:54:34 <Zarutian_iPad> GeDaMo, thrig: depends, half micron feature size is getting accessible to hobbiests and hacker/maker-spaces
2024-11-05 17:54:42 <veltas      > And it wasn't that easy for me to find out what could be expected in 'desktop' CPUs, and some things I'd expect to be standard weren't
2024-11-05 17:55:03 <veltas      > And likewise the embedded arch flavors can get *exotic*
2024-11-05 17:55:20 <veltas      > And I was wondering if e.g. the variant with fewer registers was common enough to bother supporting etc
2024-11-05 17:55:45 <Zarutian_iPad> using an resin ?DSP? based projector in stepping step and other neat stuff
2024-11-05 17:56:00 <veltas      > It's an interesting rabbit hole, but I noticed the situation is much more convoluted because of this flexibility than it is in e.g. ARM
2024-11-05 17:57:12 <Zarutian_iPad> I have some ideas involving dna brick origami, oligios, and genes stolen from diatoms for easier ic patterning and circuitry construction
2024-11-05 17:58:03 <veltas      > GeDaMo: There was someone making a DIY chip fab in their house
2024-11-05 17:58:18 <GeDaMo      > Yeah, I think a few people are trying
2024-11-05 17:58:38 <veltas      > It's really cool but probably won't go anywhere, and requires some incredibly dangerous chemicals
2024-11-05 17:59:01 <veltas      > Chips benefit from economies of scale, I don't think that's a bad thing
2024-11-05 17:59:09 <veltas      > And division of labour etc
2024-11-05 18:00:21 <GeDaMo      > On the subject of SIMD: Guy Blelloch is worth a look, he did stuff with vector supercomputers
2024-11-05 18:00:22 <Zarutian_iPad> veltas: how dangerous chemicals are we talking about here?
2024-11-05 18:00:53 <Zarutian_iPad> I have worked with ferrochloride acid
2024-11-05 18:00:54 <veltas      > Well I worked at a place once that did its own chips and they once burnt down their factory, and the moral of the story was that sometimes the factory will burn down
2024-11-05 18:01:15 <veltas      > And nobody could explain how to make it safer, and the firemen cannot put it out
2024-11-05 18:01:31 <veltas      > The best we have is to not leave important or perishable things near it
2024-11-05 18:01:31 <GeDaMo      > E.g. prefix sum scans and Vcode a vector intermediate representation for the NESL language
2024-11-05 18:01:38 <veltas      > So it feels like something I don't want to do in my house
2024-11-05 18:01:58 <veltas      > Really strong oxidisers I'm guessing are the issue here(?)
2024-11-05 18:02:07 <Zarutian_iPad> sounds like trifluridechloride fire
2024-11-05 18:03:21 <veltas      > Although firemen can't even put a Tesla out
2024-11-05 18:04:18 <Zarutian_iPad> but iirc the first ics were made using hydrochloric acid which you probably have under your kitchen sink (diluded)
2024-11-05 18:04:33 <Zarutian_iPad> lithum fires are nasty
2024-11-05 18:04:53 <veltas      > I guess it would be interesting to see what people can do with DIY lithography and safer chemicals
2024-11-05 18:05:38 <GeDaMo      > I seem to remember a company came up with a "make your own chips" system where they supplied "blanks" which could be specialized
2024-11-05 18:05:46 <GeDaMo      > Something like a ULA, I suppose
2024-11-05 18:05:48 <veltas      > Aiming at that 1-4 MHz wild west
2024-11-05 18:08:05 <veltas      > I don't know the physics behind it, but for some reason it's a lot easier to make stuff run around 1-4MHz, CPU's or buses or anything
2024-11-05 18:08:22 <veltas      > I don't know if there's some sort of general principle explaining this, or if it's a coincidence
2024-11-05 18:09:20 <veltas      > Maybe something to do with limitation of open drain
2024-11-05 18:13:16 <Zarutian_iPad> paracitic capacitence and impedence iirc
2024-11-05 18:16:00 <GeDaMo      > https://www.righto.com/2018/05/inside-76477-space-invaders-sound.html
2024-11-05 18:16:26 <GeDaMo      > "An unusual feature of the chip is that it uses Integrated Injection Logic (I²L), a type of digital logic developed in the 1970s with the goal of high-density, high-speed chips."
2024-11-05 18:53:22 <amby        > veltas: at higher frequencies you need to pay more attention to inductance/capacitance/etc
2024-11-05 18:54:19 <amby        > because if you're trying to switch a line at 8MHZ, but the capacitance and inductance means it takes 250ns to swing from 0v to 5v
2024-11-05 18:54:26 <amby        > it's clearly not gonna work
2024-11-05 19:07:27 <xentrac     > veltas: I mean the reason they started the RISC-V project is that they found their research into CPU design was too limited by ARM's licensing.  RISC-V exists as an alternative to ARM because ARM was too locked down.  It's very plausible to believe that the reason it's starting to get adoption in China now is also because ARM is too locked down
2024-11-05 19:07:59 <xentrac     > I don't think average consumers will be aware of most of the CPUs they're using.  They already aren't!
2024-11-05 19:08:06 <xentrac     > that's been true for 20 or 30 years
2024-11-05 19:09:23 <xentrac     > it's true that open-drain or open-collector buses have slower rise times than buses that are directly driven high
2024-11-05 19:09:56 <xentrac     > Zarutian_iPad: you're confusing hydrochloric acid with hydrofluoric acid, which you might have in a glass-etching kit in your garage
2024-11-05 19:13:51 <Zarutian_iPad> probably
2024-11-05 19:14:23 <xentrac     > I mean people probably used hydrochloric acid too just because you use it for everything
2024-11-05 19:27:44 <veltas      > Honestly and no disrespect meant but the impetus of RISC-V initially was benefits for academics, they spent millions creating the first specs which could have been written for a lot less in almost any other environment
2024-11-05 19:28:14 <veltas      > I don't really know why RISC-V specifically is the popular open ISA, given there are others, maybe its initial focus on supporting really tiny transistor counts
2024-11-05 19:29:03 <xentrac     > I agree that the impetus of RISC-V initially was benefits for academics
2024-11-05 19:29:06 <veltas      > Academia is a weird thing
2024-11-05 19:29:16 <xentrac     > I think it's the popular open ISA because academics talk to each other
2024-11-05 19:29:41 <veltas      > Yeah and there's a weird sense of superiority of academia, which I think is mostly deserved, or was mostly deserved at some point
2024-11-05 19:29:48 <Zarutian_iPad> no patent landmines as all of the stuff is above board and likely in the public domain or considered prior art
2024-11-05 19:31:18 <xentrac     > also it's a nicer open ISA than OpenRISC or OpenPOWER or SPARC, especially when it comes to the privileged spec (setting up page tables and stuff)
2024-11-05 19:31:18 <veltas      > I think science has produced all the best written works, the value cannot be understated, however academia today is sort of a weird horrid machine
2024-11-05 19:31:18 <kragen@user/xentrac> H-index?
2024-11-05 19:31:40 <xentrac     > most of the other open ISAs (other than OpenRISC or OpenPOWER or SPARC) don't have support in GCC
2024-11-05 19:32:22 <xentrac     > OpenRISC doesn't have support in *mainline* GCC but that's kind of a chicken-or-egg problem
2024-11-05 19:32:43 <xentrac     > so I think it's unsurprising in retrospect that RISC-V took off
2024-11-05 20:40:08 <xentrac     > here dec. calls . after setting base to decimal 10 using let!, and when dec. returns, let! takes care of setting base back to whatever it was previously
2024-11-05 20:40:20 <vms14       > I get lost with all the stack juggling
2024-11-05 20:40:29 <xentrac     > it's confusing
2024-11-05 20:40:31 <vms14       > which makes me understand what others feel with lisp parenteses
2024-11-05 20:40:45 <vms14       > they only see parenteses, not the actual words
2024-11-05 20:40:52 <vms14       > in forth I only see stack juggling
2024-11-05 20:40:55 <vms14       > xD
2024-11-05 20:41:25 <vms14       > with time I will be able to see beyond stack juggling
2024-11-05 20:42:18 <xentrac     > the great advantage of with-open-file in Lisp, though, is that it closes the file even if you exit with an error
2024-11-05 20:42:27 <xentrac     > I don't think there's a way to do that in standard Forth
2024-11-05 20:42:27 <vms14       > I need to practice more
2024-11-05 20:43:19 <vms14       > you mean unwind-protect?
2024-11-05 20:43:37 <vms14       > if you have some sort of try catch maybe there is a way
2024-11-05 20:43:53 <vms14       > or just forcing to use something else than abort
2024-11-05 20:43:53 <xentrac     > yeah, things like unwind-protect
2024-11-05 20:44:20 <vms14       > essentially making some sort of exception mechanism or alike
2024-11-05 20:45:38 <xentrac     > I mean, if you just want a cleanup stack to execute on abort, you don't need a very complicated exception mechanism
2024-11-05 20:46:21 <vms14       > you can always redefine abort but no idea how to overwrite abort in older defined words that use it
2024-11-05 20:51:54 <xentrac     > in standard Forth you can't
2024-11-05 20:52:16 <xentrac     > maybe this is half the reason people end up writing their own Forths
2024-11-05 20:59:01 <vms14       > actually I have mixed feelings with the ability of overwriting stuff in older definitions
2024-11-05 20:59:41 <vms14       > I think the fact forth does not allow such a thing is the correct way in the long term, since overriding things might create a mess and funny bugs
2024-11-05 21:00:18 <vms14       > it might get handy sometimes, but seems like something that can byte you back quite easily
2024-11-05 21:00:22 <vms14       > bite*
2024-11-05 21:03:19 <vms14       > yet it's true that some exception handling mechanism or at least the ability to add one might be cool
2024-11-05 21:03:58 <vms14       > you can always add one as long as you do not reach a point where abort is called
2024-11-05 21:04:15 <vms14       > which might be over your control
2024-11-05 21:06:12 <vms14       > I can only think about stack underflow, which does not seem like something you should recover from
2024-11-05 21:16:05 <vms14       > guys teach forth to chatgpt
2024-11-05 21:16:16 <xentrac     > well, in general it's pretty common to want to change how parts of your system work
2024-11-05 21:17:08 <xentrac     > and the fact that in standard-conforming Forths you basically can't do that is kind of sad
2024-11-05 21:18:25 <GeDaMo      > Chuck would say to just reboot the machine with the altered version :P
2024-11-05 21:18:56 <vms14       > I think the things abort will be called for are actually not things that would worry you too much when making some sort of exception mechanism
2024-11-05 21:19:16 <vms14       > like stack underflow or a missing word being called
2024-11-05 21:19:56 <vms14       > it has barely any error checking so you have room
2024-11-05 21:27:31 <xentrac     > right, Chuck Moore is not really in favor of Forth standardization
2024-11-05 21:43:33 <vms14       > we should lure him to this channel
2024-11-05 21:50:53 <xentrac     > he's done IRC interviews in the past, but I think he retired from GreenArrays a year or two ago
2024-11-05 21:51:04 <xentrac     > and I don't think he has internet access at his cabin
2024-11-05 22:32:49 <vms14       > I keep loving that forth ai book
2024-11-05 22:33:47 <vms14       > it's telling me that the runtime part of variable points to (var) while constant points to (con)
2024-11-05 22:34:21 <vms14       > that create adds a definition, creates the nfa with the name and sets the cfa to (var)
2024-11-05 22:34:54 <vms14       > other books would just tell me that create pushes the memory address of the word instead
2024-11-05 22:36:32 <vms14       > I like how much info is giving me, just with a very simple explaination of forth
2024-11-05 22:49:19 <vms14       > explanation*
2024-11-05 23:11:39 <xentrac     > 
ACTION points to con