channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=24&m=7&d=1
00:02:00 <heat> hah no the thunderx2 implements LSE
00:02:00 <kof673> (minor point) > your firmware consists of free software, but effectively you can't excercise your rights gpl uses both terms, but: > offer you this license which gives you legal permission > You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.
00:03:00 <kof673> "permissions" "privileges" is more clear, and it states that elsewhere
00:31:00 <geist> ooh someone said thunderx2?
00:31:00 <geist> thundex2 does LSE, yes, but it's a first gen, dunno how well it works
00:34:00 <heat> apparently poorly
00:34:00 <heat> context is that cmpxchg is so unfair they had to introduce a retry loop in a cmpxchg loop to drastically improve fairness
00:34:00 <heat> and performance
00:35:00 <heat> (cmpxchg loop "decays" into a spinlock)
00:36:00 <mjg> fairness aside these arms used to have absolutely dogshit scalability when faced with something like this
00:37:00 <mjg> this includes the graviton cpus
00:37:00 <mjg> that's compared to intels ofc
00:37:00 <heat> iirc amd also had some really awful fairness issues in a similar situation
00:37:00 <heat> like, modern epyc amd 2 or 3 years ago
00:38:00 <mjg> i have not heard about that
00:38:00 <mjg> anyhow i'm heading off
00:38:00 <mjg> ch34rz
00:38:00 <heat> i dont have more details cuz it was 2 years ago but there were huge problems at $place due to mmap_sem and amd unfairness
00:39:00 <heat> like, the huge system stalls didn't repro under similar-sized intel systems
00:42:00 <Mondenkind> wait freeつ ◕_◕ ༽つ
00:49:00 <geist> also thunderx2 is 4 way SMT
00:50:00 <geist> but yeah there were some things they were going to fix with x3 before marvell got ahold of cavium and apparently killed it
04:35:00 <Jari--> morning all
04:39:00 <klys_> hi
04:43:00 <klys_> http://show.ing.me/paste/2024-06-30-154326_1366x768_scrot.png
04:48:00 <zid> Disagree.
04:48:00 <zid> None of that actually happened
04:48:00 <klys_> what woukd you do
04:51:00 <klys_> where could it go wrong
04:53:00 <geist> oh reminds me i need to try the 2.11BSD irc
05:02:00 <klys_> putting back regular ovmf I can boot my kernel via serial. there must be something seriously wrong with this OVMF.fd that I compiled.
05:30:00 <klys_> reading https://github.com/tianocore/edk2/blob/UDK2018/OvmfPkg/README#L89 I added the following to qemu's commandline: -debugcon file:debug.log -global isa-debugcon.iobase=0x402 ;and now I have this log: http://show.ing.me/paste/2024-06-30-154326_1366x768_scrot.log
05:30:00 <bslsk05> github.com: edk2/OvmfPkg/README at UDK2018 · tianocore/edk2 · GitHub
05:30:00 <bslsk05> redirect -> 45.55.20.239 <no title>
05:42:00 <klys_> upon realizing the link wouldn't click right I linked http://show.ing.me/paste/2024-06-30-154326_1366x768_scrot.log.txt
05:59:00 <klys_> upon examining https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/DebugLib.h#L400 ;it appears the assertion failed.
05:59:00 <bslsk05> github.com: edk2/MdePkg/Include/Library/DebugLib.h at master · tianocore/edk2 · GitHub
06:05:00 <geist> hrm
06:13:00 <klys_> BiosStart: C0000, OptionRom: C0000
06:16:00 <klys_> changing the assertion to " ASSERT (Private->BiosStart >= Private->OptionRom);" seems to help a bit as I now have the tianocore logo
06:21:00 <klys_> ...and my kernel loads with efifb
07:09:00 <geist> huh so that's kinda trippy. makes sense. i've been playing with github copilot a bit
07:09:00 <geist> and so i'm working on cleaning up an old uart driver
07:10:00 <geist> and if i just start typing the name of the registers it already knows the name, the offset, and all the bits
07:10:00 <kazinsal> I guess when your training data is "all of github" you get pretty good results for things like that
07:11:00 <geist> yah you can basically explicitly ask it even: 'fill in all the registers for pl011'
07:11:00 <geist> and it just blats it out
07:13:00 <geist> https://usercontent.irccloud-cdn.com/file/2ZXshyof/image.png
07:13:00 <geist> etc
07:13:00 <geist> of course it might be wrong...
11:41:00 <heat> geist, i do want to note that "transfer descriptor" is completely bogus
15:57:00 <mjg> > Trying Windows 95 Server Based Setup
15:57:00 <mjg> fucking mad man
16:03:00 <Ermine> ?
16:11:00 <kof673> i added: lcc_win32_v3_2_2016_04_15 tinyc_0_9_27_win32 (x86_64 too) https://archive.org/details/windows-nt-196-linking-and-running-gcc (cobbled together gcc 1.4 or so, optional long long with libgcc2 functions) ) targets today... and that tomorrow maybe: http://ptspts.blogspot.com/2020/04/openwatcom-exeprog.html > cross-compile to EXE files of 16-bit DOS, 32-bit DOS, 16-bit Windows (Windows 3.1), 32-bit Windows (Windows 95 -- Wi
16:11:00 <kof673> ndows 10), 16-bit OS/2 (1.x) and 32-bit OS/2 (2.x)
16:11:00 <bslsk05> ptspts.blogspot.com: pts.blog: How to cross-compile to various EXE files using OpenWatcom C compiler on Linux
16:12:00 <kof673> these are just like stupid c89 command-line utilities like "wc" -ish and such
16:13:00 <kof673> (via wine the first 3), ow post above is linux x86-32 binaries
16:14:00 <kof673> anyways, you probably have a few choices for windows 95 benchmarks lol
16:14:00 * kof673 zzzzzzzzzzzzzzzz
17:47:00 <zid> nikolapdp is it 10pm yet
17:56:00 <nikolapdp> zid it's not
17:57:00 <GeDaMo> It is in Mongolia :|
18:21:00 <gorgonical> I just learned that sea urchins in German are called sea hedgehogs. But that urchin also means hedgehog, from Latin. But that hedgehog is just some nonsense coined in Middle English because they saw a little mammal in the bushes and gave it a name even though it already had one
19:17:00 <zid> hot new bug in openssh, it's stupidly hard to pull off though
19:17:00 <zid> thread race on one thread calling free(), that requires you to guess on the aslr
19:19:00 <zid> 1/10k on the race, and then 1/whatever for the aslr, and it matters which glibc binary you're using too
19:19:00 <nikolapdp> yeah it's basicalyl a non issue for the most part
19:19:00 <nikolapdp> but some people are already panicing lol
19:21:00 <zid> debian will probably be shipping 9.8 or whatever by the time anybody could actually land this
19:21:00 <nikolapdp> yeah
19:35:00 <gog> hi
19:35:00 <mjg> watap
19:36:00 <gog> my keyboard left poland 6 days ago
19:36:00 <gog> :(
19:36:00 <zid> expat keyboard
19:36:00 <heat> optimal keyboard
19:37:00 <heat> handprogrammed by the mjg man
19:37:00 <gog> kurwa
19:37:00 <nikolapdp> use a magnetic needle to manually flip bits in meomry
19:37:00 <heat> qwerty is for chumps, dvorak is for people who've never touched grass, kurwa is based
19:38:00 <zid> my memory isn't magnetic though
19:38:00 <mjg> the kurwa layout is best by test
19:38:00 <zid> I need an electron gun
19:39:00 <mjg> gog: by "left poland" did you mean stolen by belarusans?
19:39:00 <mjg> yo, when russians go to germany to steal a car
19:39:00 <mjg> why do they still *two* instead
19:39:00 <heat> steal
19:39:00 <Ermine> colemak ftw!
19:39:00 <mjg> steal indeed
19:39:00 <mjg> it's because they are going back through poland
19:40:00 <mjg> fucken you're/your thered
19:40:00 <heat> i dont get it
19:40:00 <mjg> the polish will steal one of them
19:40:00 <heat> your eastern european ethnic tension didn't quite land here, sorry
19:40:00 <heat> ethnic tension joke
19:41:00 <Ermine> heat: if you want into eastern europe you gotta get used to those tensions
19:41:00 <mjg> some years back there was a poor fucking sap who decided to cycle his way through europe
19:42:00 <mjg> you wont believe it, his bike got stolen once he reached poland
19:42:00 <mjg> gg my countrymen
19:42:00 <mjg> :d
19:43:00 <zid> nikolapdp: Is it 10pm *now*?
19:43:00 <nikolapdp> no
19:44:00 <nikolapdp> do we even have poles here
19:44:00 <nikolapdp> i don't know
19:44:00 <mjg> hopefully not
19:44:00 <zid> not legally
19:44:00 <zid> slaves aren't allowed
19:45:00 <geist> heat: heh okay. re: transfer descriptor
19:48:00 <heat> geist, what happens if you ask it for a "nvme submission queue entry" struct
19:51:00 <heat> fwiw chatgpt can crank out an nvme submission queue entry pretty flawlessly
19:52:00 <mjg> did not you shit on me for using chatgpt for LULZ
19:52:00 <mjg> duality of man :S
19:52:00 <heat> i'm not shitting on it
19:52:00 <heat> it is at times pretty impressive
19:53:00 <heat> even when violating the good old GPL
19:53:00 <mjg> i said you were shitting on ME for doing it
19:53:00 <heat> you usually do shit on it though
19:53:00 <mjg> ofc i do
19:54:00 <mjg> so what changed mon
19:54:00 <heat> what
19:54:00 <mjg> lemme grep
19:54:00 <heat> i do have to say that for more general well known questions it kicks some ass
19:55:00 <heat> i've used it for some maths questions and it seems to be overall pretty correct
19:56:00 <Ermine> Are you ok today mjg
19:56:00 <mjg> i'm fine, thank
19:58:00 <mjg> welp i somehow can't find it
19:58:00 <heat> maybe you mandela effected into our universe
19:58:00 <mjg> i distinctly recall if you asked if i'm stupid for using chatgpt, even though i only queried it for lulz
19:58:00 <mjg> this is where zid came in to take a stab with something akin to "do you really have to ask him that"
19:59:00 <mjg> somehow can't find it in my logs though :<
19:59:00 <mjg> i did find this zinger
19:59:00 <mjg> 18:49 < zid> heat: mjg never benchmarks anything that does any actual work
19:59:00 <mjg> fucking bellend
19:59:00 <heat> i ask people if they're stupid like 1000 times a day
19:59:00 <heat> ask mcrod
19:59:00 <heat> hahaha
20:00:00 <mjg> well bottom line is you were trying to discourage chatgpt from being used
20:00:00 <mjg> even tho i said several times i am not using the generated code for anything but lulz
20:00:00 <geist> i think you touched a nerve heat
20:01:00 <geist> it's okay mjg
20:01:00 <geist> <pat pat>
20:01:00 <mjg> but now you seem to think chatgpt is fine?
20:01:00 <heat> i do generally discourage chatgpt from being used
20:01:00 <mjg> your attitude at the time was to whack it altogether
20:01:00 <heat> but i was curious if chatgpt shit the bed here
20:01:00 <mjg> merely trying to evaluate what it does with a given prompt was enough to get you going
20:01:00 <nikolapdp> mjg heat ping pongs on various things all the tiem
20:02:00 <heat> oh ethically and morally yeah totally we should nuke chatgpt
20:02:00 <nikolapdp> there we go
20:02:00 <mjg> i am not talking ethics or morality
20:02:00 <geist> gasp, how dare somebody not have a firm completely unchanging opinion on something
20:02:00 <mjg> i am talking technical accuracy mon
20:02:00 <heat> geist, worse, NUANCE??!?
20:02:00 <heat> proposterous
20:02:00 <geist> NUAAANCE is a bad word!
20:02:00 <mjg> :d
20:02:00 <mjg> 21:54 < mjg> so what changed mon
20:03:00 <mjg> if you go from being rather disparaging to the current state you presumably should have some reasoning
20:03:00 <heat> i still think it's ass
20:03:00 <geist> anyway hows everyone today?
20:03:00 <geist> aside from the standard aruging about some silly shit
20:03:00 <heat> what changed is that geist tried it out on his copilot thing and it pooped the panties, so i tried it out on chatgpt. the end
20:03:00 <mjg> the circlejerk on this channel is reddit-worthy
20:03:00 <heat> i feel tired
20:03:00 <geist> well, it wasn't always that way
20:03:00 <nikolapdp> hey giest what's up
20:03:00 <geist> but i think the channel is dying, alas
20:03:00 <geist> nikolapdp: hiya
20:04:00 <nikolapdp> you mentioned something about trying irc on the pdp
20:04:00 <nikolapdp> or am i imagining
20:04:00 <geist> oh yeah i meant to do that and then got side tracked
20:04:00 <geist> what was the url for that again?
20:04:00 <nikolapdp> for my thing?
20:05:00 <geist> yah
20:05:00 <nikolapdp> give me a sec
20:05:00 <mjg> is discord on a better shape? genuine question
20:05:00 <geist> i have it saved somewhere but i dont remember where
20:05:00 <mjg> in
20:05:00 <nikolapdp> geist: https://github.com/minnerlas/sic
20:05:00 <bslsk05> Minnerlas/sic - Sic IRC client for BSD 2.11 (0 forks/3 stargazers/MIT)
20:05:00 <mjg> specifically, do they talk tech
20:05:00 <heat> mjg, yes
20:05:00 <mjg> nice
20:05:00 <geist> mjg: no idea. trouble is as i've been trying to steer it back to some sort of original problem statement, there's somewhat less hobby os stuff going on here by a wide array of folks
20:06:00 <geist> nikolapdp: cool thanks
20:06:00 <nikolapdp> no problem
20:06:00 <nikolapdp> i want to see it running on an actual pdp :)
20:06:00 <geist> i just want this place to be positive. mostly talking about making progress, asking questions, being interested in stuff
20:06:00 <geist> that's the general statement of the channel
20:06:00 <heat> i want to bikeshed a little and mention that linux (and other systems) does roughly fall into "operating system development"
20:06:00 <geist> negativity makes me (and probably other folks) stay away
20:06:00 <heat> in case you're talking about our little discourses from time to time
20:07:00 <heat> but i generally agree with your sentiment
20:07:00 <nikolapdp> i feel like it's fair to discuss what linux, or bsds or whatever do
20:07:00 <geist> agree
20:07:00 <nikolapdp> but i am one of the newest here so :/
20:07:00 <mjg> i don't know if one can genuinely discuss any OS without a solid dose of shitting on it though
20:08:00 <geist> yes, you can
20:08:00 <nikolapdp> you can just say "thing is bad"
20:08:00 <nikolapdp> no need for insults i guess
20:08:00 <mjg> you can be polite about it for sure
20:08:00 <geist> exactly
20:08:00 <mjg> but reality is most stuff is just not good
20:08:00 <nikolapdp> so say it like that
20:08:00 <geist> but shitting on it drives people away is my point
20:08:00 <heat> you can focus on what you like instead of what you don't like
20:09:00 <mjg> ... while papers you will find are trying to paint the opposite picture
20:09:00 <geist> if nothing else because now they're less likely to point out what they're doing for fear of getting shit on
20:09:00 <mjg> that is fair
20:09:00 <geist> remember not everyone here is trying to build the bestest/fastest/most scalable thing
20:09:00 <geist> that's just one aspect of a wide array of stuff to do in this area
20:10:00 <heat> you can build the funniest thing and end up with ponyos
20:10:00 <geist> woot yes
20:10:00 <nikolapdp> is that a thing
20:10:00 <heat> yes, klange's
20:10:00 <nikolapdp> i want to laugh
20:10:00 <heat> april fools joke
20:10:00 <geist> oh wow, klange isn't here
20:10:00 <geist> ponyos was an annual treat for a while there. a reskin of taurous (i can never spell it)
20:11:00 <geist> that they were working on for a while
20:11:00 <geist> one of the most advanced of the hobby oses for a lot of the 2010s
20:11:00 <heat> toaru
20:11:00 <mjg> is there a spot where people who do work on kernels hang out and talk tech, other than project-specific
20:12:00 <mjg> i mean kernels which at least reached multisuer
20:12:00 <heat> here and discord?
20:12:00 <geist> well, we used to d a lot of that ere, but i think the number of active folks has slowly dwindled
20:12:00 <mjg> perhaps there is a mailing list or something other old fashioned
20:12:00 <nikolapdp> lkml
20:12:00 <mjg> geist: ye i remember at least in freenode times
20:12:00 <heat> oh the forum, i dunno if that's still active
20:12:00 <dostoyevsky2> templeos forums
20:12:00 <geist> and again i think we can talk that sort of stuff
20:13:00 <geist> i just would like to keep it positive to try not to drag the mood down
20:13:00 <geist> perhaps this is from working at google too long, where everything is positive all the time
20:13:00 <geist> but frankly, it's pretty nice
20:13:00 <mjg> visit poland for a week to recalibrate
20:13:00 <heat> hey geist how large process-wise does a generic fuchsia deployment get?
20:14:00 <mjg> i'm afkin'
20:14:00 <geist> hmm process as in what?
20:14:00 <heat> number of active processes
20:14:00 <geist> generally in the 100-200
20:14:00 <geist> a few thousand threads
20:14:00 <heat> i vaguely remember you talking about hitting a wall wrt page -> mapping in some awful case
20:14:00 <heat> maybe chromium?
20:15:00 <geist> yeah there is some work there to unwind how the vmo chains work
20:15:00 <heat> with regards to a simple list of vm region mappings in a vm object
20:15:00 <geist> yep. the old libc COW chain problem
20:15:00 <heat> i am wondering how large the n in O(n) needs to be
20:15:00 <heat> ah ok it was a COW chain problem?
20:15:00 <nikolapdp> heat i am sure i've already asked you this, but how does your rcu work
20:15:00 <heat> how do you get a deep chain, naturally?
20:16:00 <heat> well, i guess the vm system in zircon kind of lets you create one artificially
20:16:00 <geist> well basically every time you cow clone it to map it into another process it creates another one
20:16:00 <geist> but... it's because of a quirk of the design of how the cow chain works, partially as an optimization and partially because in the vast majority of cases a single vmo doesn't get cloned
20:16:00 <heat> nikolapdp, https://github.com/heatd/Onyx/blob/master/kernel/kernel/rcupdate.cpp#L20-L98
20:16:00 <bslsk05> github.com: Onyx/kernel/kernel/rcupdate.cpp at master · heatd/Onyx · GitHub
20:17:00 <geist> the trick is the way the cow clones work now it's a binary tree, not an arbitrary splay
20:17:00 <geist> it was an algorithmic optimization that works pretty well for most stuff, but terrible for vmos that get cloned a lot
20:18:00 <geist> so there's *always* a binary copy made and a new parent placed above the current one
20:18:00 <geist> so as you keep cloning a thing is keeps building a deeper network
20:18:00 <geist> vs splaying out
20:18:00 <heat> oh do you necessarily need to keep all cow chains in a single "chain"?
20:18:00 <geist> the nice hting is always having a left/right pair makes it very easy to clean up the tree, it basically automatically removes layers as stuff goes out of use
20:19:00 <geist> there's no 'garbage collection' that has to run asynchronously
20:19:00 <geist> but downside is deep
20:19:00 <geist> well, all cow chains of a single vmo
20:19:00 <geist> so the big one is libc.so which gets duped and COWed in basically every process
20:20:00 <heat> wait, how does the binary tree not solve the issue?
20:20:00 <geist> it's a very very unbalanced tree
20:21:00 <geist> think of it as one entire arm of a very unbalanced tree. more of a oh i dunno
20:21:00 <heat> oh :(
20:21:00 <geist> it's a directed acylic graph, but the property is every node has exactly two children at most
20:21:00 <heat> i have an interval tree implementation with a wavl tree under it
20:22:00 <heat> it kind of keeps the O(log n) i think, you might want to consider it
20:22:00 <geist> but like it said it's a very easy thing to clone a vmo: create new empty parent VMO, move all of the pages from the source VMO into the parent, shoot down the mappings for the source vmo, now you have to children vmos that will fault copuies of the parent
20:22:00 <geist> interval tree, what is it tracking?
20:23:00 <heat> start offset, end offset of the map
20:23:00 <geist> out of what? the address space?
20:23:00 <geist> or a map of what part of the vmo is mapped?
20:24:00 <heat> all mappings of a vm object add a [start file offset, end file offset] interval to the tree
20:24:00 <heat> even COW'd ones
20:24:00 <heat> but i can be a bit more direct cuz UNIX vm doesn't need to expose all that CoW vmo jazz
20:24:00 <geist> ah yes, indeed
20:25:00 <geist> we've thought about that
20:25:00 <geist> well, we do hae that basically, per vmo we keep a list of all the mappings of it
20:25:00 <geist> but we dont know if a page is present or not, so we have to be pretty aggressive about drilling through aspaces to unmap stuff
20:26:00 <nikolapdp> geist how public is fuchsia code
20:26:00 <heat> yeah but that's life isn't it
20:26:00 <geist> nikolapdp: 100%
20:26:00 <nikolapdp> is it buildable outside google :P
20:26:00 <heat> i'm pretty sure adding mappings straight onto the struct page is counter-productive in general
20:26:00 <heat> you'll pay a big cost in the fast path
20:27:00 <geist> https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/zircon/kernel/vm/ so the code for this would be somewhere in here https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/zircon/kernel/vm/
20:27:00 <bslsk05> fuchsia.googlesource.com: zircon/kernel/vm - fuchsia - Git at Google
20:27:00 <geist> er double paste
20:27:00 <geist> heat: yeah we've stayed away from that. BSDs have the uh, what is it
20:27:00 <heat> PMAP!
20:27:00 <geist> little data structure that tracks every mapping of every page
20:27:00 <geist> well, pmap is the overall structure
20:28:00 <heat> linux has a little shortcut i took, they maintain the number of mappings of the page, so if you're iterating the interval tree and find the page mapped N times, you know there's no more mappings and can return early
20:28:00 <geist> yep, i forget if we added that
20:30:00 <geist> vm_page_list is that data structure, it's basicall a WAVL tree that hangs off the VMO, tracking iirc 8 or 16 pages at a time
20:30:00 <heat> isn't that the main container for the pages?
20:30:00 <geist> https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/zircon/kernel/vm/include/vm/vm_page_list.h#638
20:31:00 <bslsk05> fuchsia.googlesource.com: zircon/kernel/vm/include/vm/vm_page_list.h - fuchsia - Git at Google
20:31:00 <geist> well, it's at the end of the day a pointer to the page, which is always owned by exactly one vmo at a time
20:31:00 <nikolapdp> why the heck does fuchsia need 80-90gb of space to build
20:31:00 <geist> a lot of the complexity there is we have some ability to insert sentinel pages for various optimizations
20:32:00 <geist> nikolapdp: it only really needs more like 20-30GB
20:32:00 <heat> RADIX TREE
20:32:00 <geist> it depends on what you're building
20:32:00 <nikolapdp> what are the options
20:32:00 <geist> nikolapdp: what sort of machine do you have to build on? I can tell you if it's feasible or not
20:32:00 <heat> they're all pretty fuckin big
20:32:00 <geist> keep in mind it's a *very* chonky build
20:33:00 <geist> i've been railing against this for years but it's a non-goal of the project to make it easy to build, alas
20:33:00 <nikolapdp> geist, a 64gb ram, r7 7700x
20:33:00 <geist> ah you could actually build it then
20:33:00 <nikolapdp> plenty of starage if it's 30gb it needs
20:33:00 <nikolapdp> how bad is it lol
20:33:00 <heat> someone that can build fuchsia outside of google? woah!
20:33:00 <geist> so if you want, you can do it. i'd start with a `bringup.x64` build
20:33:00 <geist> it'll still take a solid few hours
20:33:00 <nikolapdp> i need a bit more than that :P
20:33:00 <heat> nikolapdp, you'll see a lot of rust lto in htop
20:33:00 <nikolapdp> ah lovely
20:33:00 <geist> the real limiting factor right now is memory, but 64GB is perfect for it
20:34:00 <geist> depends. if you build a debug build it doesn't LTO, release builds now LTO for both C++ and rust, which take a ton of memory to link
20:34:00 <nikolapdp> geist is there some documentation about how to build the bringup things
20:34:00 <heat> i mean... debug builds are also generally slow as hell to build, maybe not because of lto
20:34:00 <geist> i have a VM that i use to lint test this: 16 cpus, 16GB ram, 3950x. takes about 2 hours to build release bringup.x64
20:34:00 <geist> nikolapdp: yes it's on the whole fuchsia docs page
20:35:00 <geist> once you set it up its just `fx build`
20:35:00 <heat> llvm is like 3 or 4x slower to build on a debug build
20:35:00 <nikolapdp> how do you set up the `bringup.x64`
20:35:00 <heat> RTFM
20:35:00 <geist> it's on the docs
20:35:00 <geist> `fx set bringup.x64`
20:35:00 <nikolapdp> ah ok
20:36:00 <geist> it creates a dir, `out/default` (you ca change the name with --auto-dir on the fx set line (we should do that by default but not everyone wants it)
20:36:00 <geist> the key is getting the code checked out, and then getting `fx` in your path, then there's a bunch of commands off that
20:36:00 <geist> there are a ton of args to fx set
20:36:00 <geist> https://fuchsia.dev/fuchsia-src/get-started/build_fuchsia is the page i'm thinking about
20:36:00 <bslsk05> fuchsia.dev: Configure and build Fuchsia
20:37:00 <geist> par tof the reason it uses so much disk is it will pull down many GB of prebuilt stuff. toolchains, etc
20:37:00 <geist> qemu, etc
20:37:00 <geist> OTOH it's basically completely standalone
20:37:00 <nikolapdp> huh apparently no amd gpu acceleration support
20:37:00 <geist> correct
20:38:00 <geist> it will run just fine on your AMD cpu though, which the docs say explicitly otherwise
20:38:00 <nikolapdp> i really hate all the piping straight into shell
20:38:00 <geist> yeah, i really hate that too
20:39:00 <geist> download it and look at it first if you want
20:39:00 <geist> that's the one time it does that
20:39:00 <geist> also i hate that the default download of the source is completely silent
20:39:00 <heat> hey you nailed the options in fx
20:39:00 <heat> no underscore options!
20:39:00 <geist> you have to generally add -v to get stuff to show you what it's doing
20:39:00 <nikolapdp> yeah just says creating project
20:39:00 <geist> there's a mentality of a lot of the server folks at google that commands should be silent unless error
20:39:00 <geist> which makes some sense i guess
20:40:00 <geist> what i have done in the past is download the script, edit it to not do the jiri update at the end, and then run it manually with `jiri update -v` which shows you what it's doing
20:40:00 <zid> saves you having to have an 'if interactive' version
20:40:00 <zid> in the code
20:41:00 <zid> lot of tools follow that rule but ONLY if isatty fails
20:41:00 <heat> stderr goes brrrrrrr :(
20:41:00 <heat> i mean goes errrrrrrrrr :(
20:41:00 <nikolapdp> ERRRR
20:41:00 <zid> so now it makes no god damn sense when you try to debug your scripts :P
20:42:00 <geist> note the default fx set is debug, which will compile a lot faster (though it's larger)
20:42:00 <geist> you have to pass --release if you want the release version
20:42:00 <nikolapdp> how much larger
20:42:00 <geist> oh probably a few GB. not a lot
20:42:00 <geist> just if that's an issue
20:42:00 <nikolapdp> that's fine
20:43:00 <nikolapdp> i have like a tb free
20:43:00 <geist> see the thing is we have google only network assist stuff, used to be a thing called goma and now a thing called RBE
20:43:00 <geist> so the builds pull down .o files off a server as fast as it can serve it
20:43:00 <geist> so builds are like a handful of minutes if you have a fat pipe
20:43:00 <geist> frustrating, because it makes it easier to forget that stuff is huge
20:44:00 <nikolapdp> kek
20:44:00 <nikolapdp> "chromium/deps/icu@latest"
20:44:00 <nikolapdp> heh does it build chromium too
20:44:00 <geist> no, those are prebuilts
20:44:00 <geist> which is part of the gigantic amount of downloads
20:45:00 <geist> the source tree downloads all the prebuilts for everything you might ever want to build, even if you dont
20:45:00 <nikolapdp> nice
20:45:00 <geist> at least saves the trouble of fetching during a build, which is a general no-no
20:45:00 <heat> building fuchsia is like building gentoo but everyone has super fast and big workstations and everything's written in either rust or heavy c++
20:45:00 <nikolapdp> good to know my internet connection will be saturated for a while
20:45:00 <geist> yah my workstation at the office is a fancy nice 64 core threadripper + 256GB ram
20:46:00 <geist> RIP and TEAR
20:46:00 <geist> FWIW the kernel itself builds in like 45 seconds
20:47:00 <nikolapdp> that's good
20:47:00 <geist> we dont LTO it and so the linkage is only like 10 seconds
20:47:00 <nikolapdp> what else does it build
20:47:00 <heat> EVERYTHING
20:47:00 <geist> everything
20:47:00 <geist> it's generating a complete system image
20:47:00 <nikolapdp> what does that entail
20:47:00 <nikolapdp> like what's the userspace like
20:47:00 <heat> bringup sounds like "oh haha very minimal system with the kernel and base userspace" but it ends up building like 40K object files
20:47:00 <geist> yep. a lot of those are tests too, also host side tests
20:47:00 <geist> we love us some unit tests
20:48:00 <nikolapdp> do i need to run them :P
20:48:00 <geist> the final image of a bringup build is like 20MB
20:48:00 <geist> if you want?
20:48:00 <geist> no the build doesn't run the tests
20:48:00 <nikolapdp> ah good
20:48:00 <geist> there are `fx test` stuff for that
20:48:00 <geist> there's a qemu in there so the fastest way to see if something is going is
20:48:00 <geist> `fx qemu`
20:48:00 <geist> it'll build everything it needs, and then run it in qemu
20:49:00 <geist> will use KVM if present
20:49:00 <nikolapdp> still downloading stuff
20:49:00 <nikolapdp> (:
20:49:00 <geist> yah aside fro the prebuilts there's about 150 git repositories too
20:49:00 <geist> some of which are fairly large, but the main one is fuchsia.git, whcih is at the root of the tree
20:49:00 <heat> serbian DSL connection
20:49:00 <nikolapdp> it's fiber actually
20:49:00 <heat> pray your mom doens't use the phone or you'll have to restart the whole thing
20:49:00 <heat> oh :(
20:49:00 <nikolapdp> thought at 250mbps
20:49:00 <geist> well, i have the problem ehre that i have a 100mbit link to my office, and it really chokes on this stuff
20:50:00 <nikolapdp> heh i beat google then :P
20:50:00 <geist> yeah it's for complicated reasons. my office room where i have my work stuff doesn't have a solid connection to the rest of the house, soi i'm using one of those powerline ethernet things which caps out around 100mbit
20:51:00 <heat> oh i hate powerlines
20:51:00 <heat> i have one too
20:51:00 <nikolapdp> haven't heard of those
20:51:00 <heat> they promise you the fucking world but end up giving you a super mid connection
20:51:00 <nikolapdp> huh done downloading
20:51:00 <nikolapdp> surprisingly not bad
20:51:00 <geist> yahnat least it's really solid, but just about 100mbit
20:51:00 <geist> du it and see how but it is
20:51:00 <nikolapdp> 34gb
20:52:00 <heat> basically they transport data across your power lines
20:52:00 <geist> there ya go, thats about right
20:52:00 <heat> problem is the package says 1400 MBPS!!!!!!!!! but you end up with 100mbps and you're pretty lucky
20:52:00 <geist> yep. i could set up a wifi bridge, but i bet at best i'd only get like 300mbits
20:53:00 <geist> that's also a similar lie
20:53:00 <geist> you never really get anything close to the full speed, theres just too much overhead
20:53:00 <nikolapdp> wait you can achieve reasanoble speeds over power lines
20:53:00 <nikolapdp> that's cool
20:53:00 <geist> but if you can get half of it that's not too bad
20:53:00 <geist> the one i use for the rest of the house is MoCA. ethernet over coax
20:53:00 <geist> that you can actually get pretty solid fast stuff,m i just dont have a coax line in that room
20:54:00 <nikolapdp> is fx setup-ufw
20:54:00 <geist> moca is pretty cool too, if yo uhave 3 or 4 moca adaptors on a single coax segment it'll build a set of point to point links between them
20:54:00 <nikolapdp> required
20:54:00 <geist> no, unless you want to network it
20:54:00 <geist> dont do that yet
20:55:00 <geist> that's mostlky for talking to devices, whcih you dont have
20:55:00 <nikolapdp> so the bringup then
20:55:00 <geist> you should just need to add that bin dir to your path and do a `fx set bringup.x64`
20:55:00 <geist> and then fx build
20:55:00 <nikolapdp> yup doing it
20:55:00 <nikolapdp> let's see how long it takes
20:56:00 <nikolapdp> all core 5ghz go brrr
20:56:00 <heat> the great onyx business system takes like 3 minutes on a crappy laptop
20:56:00 <nikolapdp> i should hope so
20:56:00 <geist> set NINJA_STATUS_MAX_COMMANDS=16 if you want to see a neat work in progress display
20:56:00 <geist> i think that is only present on our fork of ninja, or extremely tip of tree
20:57:00 <geist> i also have NINJA_STATUS=%es [%f(+%r)/%t(+%u)] in my environment, shows you time elapsed and how many jobs it has finished and how much it needs to do, etc
20:57:00 <nikolapdp> is see this http://0x0.st/Xaun.txt
20:57:00 <geist> ah neat. okay
20:57:00 <nikolapdp> no config required
20:57:00 <nikolapdp> is that what you were referring to
20:58:00 <geist> yah you can set those to get more verbose is all
20:58:00 <geist> the default of the buidl has a bit of context
20:58:00 <nikolapdp> number of jobs out of total jobs if fine by me
20:58:00 <geist> `367.406s [40506(+14)/86263(+45743)] ...` is what mine is showing is all
20:59:00 <zid> Time to madly refresh nyaa in 2 minutes nikolapdp, entertain me
20:59:00 <nikolapdp> hello to you to zi
20:59:00 <nikolapdp> zid
20:59:00 <geist> the elapsed seconds is nice because if you walk up to it later you can see how many centiseconds it took or whatnot
20:59:00 <nikolapdp> heh
20:59:00 <nikolapdp> lol does it really need to do all of that linting
21:00:00 <geist> we are google everything is linted and double checked and unit tested!
21:00:00 <geist> it's job security!
21:00:00 <zid> Gotta figure out how to bill for a full day
21:00:00 <nikolapdp> geist, sure, but on every build lol
21:00:00 <geist> there are switches to turn some of that off
21:01:00 <geist> but they're really not a lot of the build time
21:01:00 <geist> clippy is a lint thing we run on a lot of rust stuff
21:01:00 <nikolapdp> heh i don't know
21:01:00 <zid> How bad is rust for compile time btw
21:01:00 <nikolapdp> almost half of the jobs done
21:01:00 <zid> I've never checked
21:01:00 <nikolapdp> it's *not good*
21:01:00 <nikolapdp> but nothing is compared to like c
21:01:00 <zid> huh, surprising
21:01:00 <nikolapdp> why
21:01:00 <nikolapdp> with all that metaprogramming, it can't be fast
21:01:00 <geist> we have some rust projects in the tree that take a solid 5 or 6 minutes
21:01:00 <zid> I figured it'd be like, marginally slower than a C compiler, but nowhere near as bad as C++ level
21:02:00 <geist> and with LTO some C++ projects get that big too
21:02:00 <zid> I don't think rust code has the n! issues that C++ has
21:02:00 <heat> i think you should build chromium now that you're at it
21:02:00 <geist> nah, think of rust as always LTO all the time, so every invocatino of rustc is looking at all the source at the same time
21:02:00 <nikolapdp> yeah rust is possibly worse than c++ to build
21:02:00 <nikolapdp> it's certainly no c
21:02:00 <geist> and there's a tremendous amout of rust template expansion, depending on the style of the project
21:03:00 <geist> indeed. only with LTO does large C++ porojects get to rust time
21:03:00 <geist> also rustc is heavily multithreaded, unlike clang
21:03:00 <nikolapdp> and even that's not helping :P
21:03:00 <geist> so though it may take 5 minutes to link, that may be running 32 threads simultaneously
21:03:00 <nikolapdp> but clang assumes that multithreading would come at a different level
21:03:00 <geist> so if you have a 4 more machine it may take a lot longer
21:03:00 <nikolapdp> ie at the level of the build tool
21:04:00 <Mondenkind> i am once again begging mainstream compiler devs to throw out the llvm and build properly fine-grained-incremental crap
21:04:00 <nikolapdp> which for c works perfetctly
21:04:00 <nikolapdp> unless you do to
21:04:00 <heat> lld also multithreads heavily
21:04:00 <nikolapdp> lto
21:04:00 <geist> yah in our build system we use a feature of ninja to put different types of compiles in different buckets so it doesn't load up too many rusts
21:04:00 <geist> based on both number of cpu cores and amount of ram
21:04:00 <heat> interpreted languages would NOT have this problem, they compile in 0s
21:04:00 <zid> wtf is rust DOING to be that slow
21:05:00 <geist> heat: it depends on the style of LTO. there's a 'split up the objects, lto them separately'. faster but less effective
21:05:00 <heat> thinlto ftw
21:05:00 <geist> and there's 'all one program everything considered'
21:05:00 <geist> right, we are not using thinlto
21:05:00 <zid> Rust's grammar is pretty picky, that's great for compilation speed
21:05:00 <geist> the borrow checker is very very expensive
21:05:00 <zid> Is it just spending forever picking apart invariants for the bo-
21:05:00 <heat> i'm not sure if lld still spawns all the threaden
21:06:00 <Mondenkind> parse time is irrelevant
21:06:00 <geist> and like i said it has a kinda template expansion that's more intrinsic to thelanguage that C++
21:06:00 <zid> trying to untangle a mess of things and 'flatten' it back into fast code?
21:06:00 <nikolapdp> also a lot of templates
21:06:00 <heat> i know they capped the thread spawning at mjg's request
21:06:00 <heat> they used to spawn a thread per core
21:06:00 <geist> i think i've seen rust go up to 32
21:07:00 <geist> and yeah there's inefficiency it picks up, not because of internal lock contention, but someone on the rust team told me there's some amount of 'overlap' of how it partitions the program up
21:07:00 <zid> boom, it's out
21:07:00 <geist> so each of the threads ends up duplicating a fair amount of work of the other threads
21:07:00 <zid> ah so it's not holistic enough
21:07:00 <geist> ie, if 5 of the 32 partitions are using the same rlib then they'll all recompile the rlib, basically
21:07:00 <zid> Thread 3 is doing step C so it needs to figure out step B and D for itself
21:07:00 <geist> yah basically
21:07:00 <zid> because thread 2 and 4 might still be running and it can't share
21:08:00 <geist> whereas thread 4 may be using F which just needs B, etc
21:08:00 <geist> but B gets compiled for both
21:08:00 <geist> but FWIW they rip and tear. very little internal locking
21:09:00 <Mondenkind> tbf scheduline is like. _the_ problem. and duplicating work is sometimes (asymptotically, even) the correct tradeoff to reduce communication
21:09:00 <nikolapdp> basically all of rust stdlib is templates
21:09:00 <Mondenkind> (though i certainly wouldn't be surprised if they were being stupid here)
21:09:00 <nikolapdp> a crap ton of them
21:09:00 <geist> we have a few projects within fuchsia (ffx comes to mind, as well as netstack3) that are *highly* modular, and the structure of them causes a tremendous amount of explosion of templates and a lot of dup work in the compiler
21:09:00 <geist> folks are actively working on it, but since we have all these compile accellerators at work, it doesn't tend to be a P0 big
21:10:00 <geist> bug
21:10:00 <nikolapdp> lol rust needs a crapload of servers to offload work to be managable
21:11:00 <geist> RBE is the new thing we use for it, and it basically is a giant content addressible cache of all the inputs and outputs to every compiler invocation, including the final linked binary
21:11:00 <geist> so once the cache is primed at hot you generally get 100% hit rate, until you modify something
21:12:00 <nikolapdp> or you could just write c and compile everything in minutes :P
21:12:00 <geist> well see the thing is with RBE it kinda makes it not matter, provided you have the bandwidth
21:12:00 <geist> *except* when developiubg things
21:13:00 <geist> i am not on this bandwagon, personally, because it lets folks forget how expensive stuff is, but it's a non-goal to make the build fast
21:13:00 <geist> for folks that dont have supercomputers. i've railed against it, but it's just not the priority
21:13:00 <nikolapdp> i guess i got to the c++ part of the build because now each job is taking 10s
21:13:00 <geist> a lot of those first steps are extraneous doing job steps, like building directories, stamp files, etc
21:14:00 <nikolapdp> sorry, 20s
21:16:00 <nikolapdp> what's fuchsia used for anyway
21:17:00 <nikolapdp> we've passed 1<<16 jobs
21:17:00 <nikolapdp> whoop
21:17:00 <dostoyevsky2> what does fuchsia use from chromium?
21:41:00 <nikolapdp> geist 43min
22:33:00 <geist> not bad
22:34:00 <geist> `fx qemu` will boot a version of it
22:34:00 <nikolapdp> ah i have virtual box modules loaded
22:34:00 <nikolapdp> they took over kvm :(
22:37:00 <mjg> is that an ORACLE product
22:37:00 <klys_> back online
22:37:00 <nikolapdp> no it's SUN product :P
22:38:00 <heat> klys_, fyi you're not supposed to use UDK
22:38:00 <nikolapdp> i don0t know how to unload the moduels though
22:38:00 <nikolapdp> rmmod: ERROR: Module vboxdrv is in use
22:38:00 <nikolapdp> not sure by what
22:38:00 <klys_> heat, Csm is deprecated then
22:38:00 <mjg> there is some daemon using it
22:38:00 <mjg> grep systemctl output
22:38:00 <heat> klys_, yes, it is
22:38:00 <klys_> heat, which puts me back at square one
22:38:00 <heat> if you need CSM, pick some older CSM stable release
22:39:00 <heat> but why would you need CSM is probably *the* question
22:39:00 <nikolapdp> does libvirtd care about vbox stuff?
22:39:00 <klys_> how should I choose the version then
22:39:00 <heat> https://github.com/tianocore/edk2/releases/tag/edk2-stable202311
22:39:00 <bslsk05> github.com: Release edk2-stable202311 · tianocore/edk2 · GitHub
22:40:00 <klys_> nikolapdp, libvirt uses qemu not virtualbox's kernel module afaik
22:40:00 <heat> newest CSM-full release
22:40:00 <nikolapdp> well it did
22:40:00 <klys_> heat, ok I'll compile that and see where it takes me.
22:40:00 <nikolapdp> i stopped it and it let me unload
22:40:00 <nikolapdp> fuchsia is booting :O
22:40:00 <nikolapdp> INFO: Bootup completed.
22:41:00 <nikolapdp> what now geist :P
22:42:00 <geist> well, bringup buids you can't do much with to be honest but poke around
22:42:00 <geist> but it was a shorter build than the larger core, or workstation
22:42:00 <geist> so was kinda a baby step
22:42:00 <nikolapdp> can it do anything?
22:42:00 <geist> well, i dunno, depends on what you want it to do
22:43:00 <heat> klys_, why do you want CSM?
22:43:00 <geist> i mean not really, no
22:43:00 <klys_> heat, I'm playing with grub2
22:43:00 <geist> it's for bringup, ie, gettig the kernel going and user space booting
22:43:00 <geist> you can poke around and see the process tree and whatnot
22:43:00 <geist> ps, top, etc
22:43:00 <geist> explore the fs
22:43:00 <nikolapdp> ah ok
22:45:00 <klys_> heat, 202311 ?? Csm was patched out in 2019.
22:45:00 <dostoyevsky2> nikolapdp: what's the uname?
22:46:00 <heat> klys_, ovmf csm wasn't
22:46:00 <nikolapdp> /boot/bin/sh: 10: uname: not found
22:46:00 <nikolapdp> :P
22:46:00 <heat> klys_, the "Intel CSM" thing is completely irrelevant here
22:46:00 <geist> nikolapdp: it's not a posix system
22:46:00 <dostoyevsky2> nikolapdp: `not found' sounds like a cool uname :)
22:46:00 <klys_> the thing that SeaBIOS tells you to do to plant Csm16.bin is not there after said patch.
22:46:00 <geist> but also bringup has almost no tools in it
22:47:00 <nikolapdp> i know
22:47:00 <nikolapdp> but wasn't there a posix layer somewhere
22:47:00 <geist> not really no
22:47:00 <nikolapdp> ah i am misremembering then
22:47:00 <geist> well, there's a whole linux emulation layer, but that's different and not built with bringup
22:47:00 <geist> that's the starnix stuff
22:48:00 <nikolapdp> why do the linux emulation
22:48:00 <nikolapdp> why not just run linux
22:48:00 <geist> dont get me started
22:48:00 <heat> klys_, https://bugs.archlinux.org/task/72856 this might help
22:48:00 <bslsk05> bugs.archlinux.org: FS#72856 : [edk2-ovmf]: SeaBios CSM support?
22:48:00 <nikolapdp> lol why's that geust
22:48:00 <nikolapdp> geist
22:49:00 <geist> anyway, you might want to build core next after you've gotten bored with this, but if you want to poke around and see what the process tree and whatnot looksl ike that's it
22:49:00 <geist> also some stuff in 'driver' thats pretty interesting
22:49:00 <geist> or is it device?
22:49:00 <nikolapdp> there's /dev
22:49:00 <geist> no i mean that command
22:50:00 <nikolapdp> ah
22:50:00 <heat> "why not just run linux" invalidates like all of the hobby operating systems
22:50:00 <nikolapdp> it's driver
22:50:00 <geist> `driver list` `driver dump` etc
22:50:00 <nikolapdp> heat i don't think fuchsia is a hobby os
22:50:00 <heat> but it is an operating system
22:50:00 <nikolapdp> ohthat's neat
22:50:00 <geist> `component list` is pretty interesting too
22:51:00 <nikolapdp> heat: and i didn't say why not run linux, i said why emulate instead of run linux
22:51:00 <geist> component mananager is kinda like the main superserver of fuchsia
22:51:00 <geist> it's showing you essentially all of the 'components' of the system which is kinda the main service control
22:51:00 <heat> nikolapdp, it's faster
22:51:00 <nikolapdp> yeah a lot of them are pcie devices
22:51:00 <geist> think of the shell as sort of sitting on the side with superuser like capabilities
22:51:00 <nikolapdp> heat faster what
22:51:00 <heat> a linux compat layer is faster than a vm
22:52:00 <dostoyevsky2> nikolapdp: I wonder if the graphics support is better in fuchsia than in Linux
22:52:00 <heat> and integrates more smoothly
22:52:00 <nikolapdp> heat i am not talking about a vm
22:52:00 <nikolapdp> if you're writing an os that's just going to run linux stuff, why not run linux
22:52:00 <nikolapdp> on bare metal
22:52:00 <heat> emulating linux is really valuable for products
22:53:00 <heat> including what google probably really wanted/wants to do which is to run android apps </speculation>
22:53:00 <geist> `kstats -m` and `kstats -c` are kinda interesting too
22:53:00 <dostoyevsky2> nikolapdp: I like running linux for servers but for the desktop I don't like it that much
22:53:00 <geist> `kcounter` is sort of interesting
22:53:00 <heat> also you know how most programs are intensely UNIXy or UNIX-like? yeah that doesn't suit an OS too well when its APIs are all weird and stuff
22:54:00 <nikolapdp> geist a bunch of interesting tools there
22:54:00 <nikolapdp> heat: yeah well that's why i asked if there was a poisx layer
22:54:00 <nikolapdp> but at that point, why not just run a posix system
22:54:00 <geist> `k` is interesting, it passes the rest of the command line to the kernel
22:54:00 <nikolapdp> what do you get from reinventing the weil
22:54:00 <nikolapdp> wheel
22:54:00 <geist> so `k help` shows you the kernel's command line
22:54:00 <geist> side note if you want to just play with the kernel without user space
22:55:00 <nikolapdp> fuchsia is a microkernel, right?
22:55:00 <geist> `fx qemu -c kernel.shell=1`
22:55:00 <geist> that will drop you into the kernel shell before starting user space
22:55:00 <geist> yes
22:55:00 <nikolapdp> how do you shutdown
22:55:00 <heat> why doesn't apple just use linux instead of macOS?
22:55:00 <geist> `dm poweroff`
22:56:00 <nikolapdp> heat that's apples and oranges
22:56:00 <heat> it is not
22:56:00 <geist> `dm` is i think device manager
22:56:00 <dostoyevsky2> heat: GPL, that's why they used FreeBSD, for the BSD license
22:56:00 <nikolapdp> that would make sense
22:56:00 <heat> "why doesn't google just use linux instead of fuchsia"
22:56:00 <heat> dostoyevsky2, the kernel is entirely open
22:56:00 <dostoyevsky2> heat: I think Google do use linux instead of fuchsia
22:57:00 <nikolapdp> heat, first, google's been using linux for years, second, apple's already taking a an existing os for their core
22:57:00 <heat> christ
22:57:00 <dostoyevsky2> xnu is open too https://opensource.apple.com/source/xnu/
22:57:00 <bslsk05> opensource.apple.com: Source Browser
22:57:00 <nikolapdp> so the question is, what do they think they gain by reinventing the wheel
22:57:00 <heat> thank you for telling me google is using linux
22:57:00 <heat> i did not know that
22:58:00 <nikolapdp> well clearly you don't want to have a productive conversation about this so let's just drop it
22:58:00 <nikolapdp> geist, how can i build the "bigger" config
22:58:00 <geist> i alas can't comment on the why of fuchsia, for FWIW
22:58:00 <geist> fx set core.x64
22:58:00 <nikolapdp> see, heat, it's not that obvious
22:58:00 <heat> i can't answer your questions, i am not google nor a google PM nor a fuchsia core team member
22:58:00 <geist> it'll reuse the same out dir and you can just build
22:58:00 <dostoyevsky2> nikolapdp: It's always good to have more options as a company, like they could also just use mozilla and not work on Chromium, but your own browser has some advantages
22:59:00 <geist> the really big one is `workbench_eng.x64`
22:59:00 <nikolapdp> how do i get out of the kernel shell lol
22:59:00 <heat> i can however tell you that "why not just linux" is entirely depressing and really worsens the field overall
22:59:00 <heat> we should not all use the same fucking awful operating system
22:59:00 <geist> just stop qemu
22:59:00 <geist> ctrl-a x
22:59:00 <nikolapdp> dostoyevsky2 they did fork an exsiting engine when they started
22:59:00 <nikolapdp> ah so no "please turn off" incantation
22:59:00 <geist> oh there might be
23:00:00 <geist> shutdown? poweroff? i forget
23:00:00 <geist> type help to see the commands
23:00:00 <nikolapdp> too late, killed it :P
23:00:00 <nikolapdp> heat: i mean you're recreating linux, just in c++
23:00:00 <geist> the kernel shell is bsically just LK. it's the same command setuff
23:00:00 <nikolapdp> so your point is moot there
23:00:00 <nikolapdp> heh neat
23:00:00 <heat> what's chromium if not firefox rewritten?
23:00:00 <nikolapdp> let's see how long this takes
23:00:00 <dostoyevsky2> nikolapdp: But yeah, Linux and other open OSes are lacking in the Desktop department, so it could make sense to have something that's more focussed on that like Fuchsia
23:00:00 <geist> yah workbench_eng.x64 is the full one
23:01:00 <geist> i think that starts a gui and everything
23:01:00 <nikolapdp> oh what kind of gui is it
23:01:00 <nikolapdp> and better question, how long to build it
23:01:00 <geist> i say that because i really haven't fiddled with it
23:01:00 <geist> i dunno, honestly. it's changed over the years and it's been a solid 6 months since i booted it
23:01:00 <nikolapdp> ah fair
23:01:00 <nikolapdp> heat: and my point wasn't "why not use linux", my point was "why use something else to emulate linux"
23:01:00 <geist> being a kernel person i generally only deal with bringup and core configureations, but i usually have 3 around for each: arm64, x64, and riscv
23:02:00 <nikolapdp> which you seem to repeatedly miss
23:02:00 <nikolapdp> oh you support riscv
23:02:00 <nikolapdp> the readme only mentioned arm and x86
23:02:00 <geist> oh where? I should get that updated
23:02:00 <nikolapdp> though i didn't look that deeply into it
23:02:00 <heat> nikolapdp, reread my messages
23:02:00 <heat> i touched that too
23:02:00 <geist> riscv64 to be precise
23:03:00 <nikolapdp> let me see if i can find it
23:04:00 <nikolapdp> heat you didn't really, the closest you got was "what's chromium if not firefox rewritten?"
23:05:00 <heat> <heat> emulating linux is really valuable for products
23:05:00 <nikolapdp> oh it's done already
23:05:00 <heat> <heat> including what google probably really wanted/wants to do which is to run android apps </speculation>
23:05:00 <heat> <heat> also you know how most programs are intensely UNIXy or UNIX-like? yeah that doesn't suit an OS too well when its APIs are all weird and stuff
23:05:00 <nikolapdp> heat: that doesn't answer why not linxu
23:05:00 <nikolapdp> you're just saying linux important
23:05:00 <heat> you have a system
23:05:00 <heat> it's different and stuff
23:05:00 <heat> you want it to be useful to other markets too
23:05:00 <heat> linux?
23:06:00 <heat> the alternative is to port everything
23:06:00 <nikolapdp> no, the alternative is to run linux
23:06:00 <heat> to your weird excentric system
23:06:00 <nikolapdp> like they've already been doing for decades at this point
23:06:00 <nikolapdp> geist, what can core do
23:06:00 <dostoyevsky2> heat: Isn't linux just like 300 syscalls? And then you get a whole ecosystem for that... so it kind of makes sense for any new OS to emulate linux, especially if it's not that hard to do
23:06:00 <heat> ok so your question is why fuchsia at all, not why linux in fuchsia
23:06:00 <dostoyevsky2> s/heat:/nikolapdp:/
23:06:00 <nikolapdp> no, the question is why use fuchsia to run linux software
23:07:00 <nikolapdp> i am not at all referring to native fuchsia stuff
23:07:00 <heat> you keep the advantages of fuchsia while running linux, in the same system
23:07:00 <nikolapdp> and those are?
23:07:00 <nikolapdp> advantages i mean
23:07:00 <heat> stability of a microkernel with ABI stability with running the netflix android app
23:07:00 <nikolapdp> because linux is so unstable, rigjt
23:07:00 <geist> nikolapdp: has a net stack, can probalby run starnix, etc
23:08:00 <nikolapdp> right, so now comes the net config part
23:08:00 <heat> i've been having oopses and the system goes down
23:08:00 <nikolapdp> well go job, i haven't
23:08:00 <nikolapdp> the only issue i've come across was an oom
23:08:00 <nikolapdp> and micokernels won't save you there
23:08:00 <heat> nvidia drivers have been completely fucked for a few releases, system just crashes
23:09:00 <nikolapdp> well i doubt fuchsia has better nvidia support than linux
23:09:00 <nikolapdp> that's just nvidia being nvidia
23:09:00 <nikolapdp> i am on amd and it's rock solid
23:09:00 <heat> ideally in a microkernel world you restart the server and it's done
23:10:00 <nikolapdp> sure
23:10:00 <nikolapdp> assuming you get someone to write a whole nvidia stack for you
23:10:00 <geist> nikolapdp: i think yo uwant to build workbench_eng, not core
23:10:00 <nikolapdp> i will then
23:10:00 <geist> thats the full monty, it's surprisingly not that much bigger to build
23:10:00 <nikolapdp> yeah only 210 jobs more
23:11:00 <nikolapdp> is that the gui one?
23:11:00 <geist> i think so yeah
23:11:00 <geist> you can kinda tell how it works by looking at product/ and there's a .gni file for each of them
23:11:00 <nikolapdp> you don't run the gui with fx qemu i imagine
23:11:00 <geist> some of them are baiscallt lower level + ne stuff
23:11:00 <geist> you can totally run the gui with fx qemu
23:13:00 <nikolar> yeah not showing up
23:13:00 <nikolar> the gui i mean
23:13:00 <geist> you rebuilt workspace? wow
23:13:00 <geist> oh, run fx qemu with.... -g?
23:13:00 <geist> look at --help
23:13:00 <geist> you need a display
23:14:00 <heat> do you still have the like... 3 emulators?
23:14:00 <nikolar> ah there we go
23:14:00 <geist> heat: yep!
23:14:00 <heat> lol
23:14:00 <geist> fx qemu is the low level one where you have to kinda manually drive it
23:15:00 <nikolar> thogh now i just have a terminal in a qemu window lol
23:15:00 <nikolar> how do i start the gui
23:15:00 <geist> ffx emu is the higher levle one, which isprobalby what you should be running but i honestly dunno how to use it
23:15:00 <heat> wasn't there like a... fx vdl or something?
23:15:00 <geist> yeah, i think that's gone now
23:15:00 <geist> so i think it's just 2
23:15:00 <geist> nikolapdp: dunno
23:16:00 <nikolar> well fx emu start does start an emulator
23:16:00 <nikolar> it's now portrait and i can't type into it
23:16:00 <zid> You accidentally emulated a pinball table
23:17:00 <zid> They are also portrait and cannot be typed into
23:17:00 <nikolar> do they have text too
23:17:00 <geist> i honestly do not know
23:17:00 <geist> i have not run workbench in an emulator in like years
23:18:00 <heat> gui is bloat
23:18:00 <nikolar> indeed
23:18:00 <geist> moe or less yes
23:18:00 <heat> oh can you run X in starnix directly?
23:18:00 <geist> the products that ship on fuchsia have their own gui, so they basically overlay on top of it and build their own stuff
23:18:00 <heat> i know there's like a wayland shim for the Real Compositor by default
23:19:00 <geist> and there is a whole fuchsia compositor and whatnot
23:19:00 <geist> there's a whole mechanism to punch that out of starnix and composite, indeed
23:19:00 <geist> problem is wha you get is all mechanism and not really a product
23:19:00 <geist> product comes as a layer on top of what you're getting in the source tree
23:20:00 <geist> it's kinda like stage3 gentoo or whatnot
23:20:00 <nikolar> well all i get is a graphical terminal, instead of an emulated serial i assume
23:20:00 <dostoyevsky2> nikolar: how much of your 1tb of free space is gone by now?
23:20:00 <nikolar> let's see
23:20:00 <nikolar> almost exactly 100gb
23:21:00 <heat> at this point your whole hard drive is google prebuilts and rust programs
23:21:00 <nikolar> not whole, 1/20th
23:25:00 <geist> anyway there might be a gui there, but i honestly dunno how to start it
23:25:00 <geist> we usd to have a tiling like gui, i forget what it was called
23:25:00 <geist> but i think we dont work on that anymore
23:25:00 <heat> armadillo
23:26:00 <nikolapdp> another project in the google's graveyard :P
23:27:00 <dostoyevsky2> They should make a Zombie Wars game out of Google's graveyard
23:29:00 <geist> heh
23:33:00 <klys_> heat I got the same assert problem as previously. fixable though
23:34:00 <heat> it's entirely possible CSM just doesn't work with new qemu
23:34:00 <heat> ovmf and qemu kind of want to go hand in hand, and CSM is just... crap that's really unused
23:35:00 <nikolapdp> can't you just boot bios directly
23:35:00 <nikolapdp> instead of uefi+csm
23:35:00 <heat> yes, that's why CSM in qemu is unused
23:35:00 <nikolapdp> exactly
23:36:00 <klys_> totally unwarranted response to a slight foible
23:36:00 <nikolapdp> what
23:37:00 <heat> i kind of participated in that CSM axing decision and all i could say was good riddance
23:37:00 <nikolapdp> how "kind of"
23:37:00 <klys_> all I have to do is edit one line to say >= rather than > and it should work fine
23:39:00 <heat> nikolapdp, https://openfw.io/edk2-devel/CAKbZUD2+19t=tcDnAV5S21gh5QyTueRk-w=bNDSfS_7kmBdaWg@mail.gmail.com/
23:39:00 <bslsk05> openfw.io: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members - Pedro Falcato
23:39:00 <heat> this email ended up starting the chain process of actually axing ovmf CSM