<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.
<kof673>
"permissions" "privileges" is more clear, and it states that elsewhere
agent314 has quit [Remote host closed the connection]
wantyapps is now known as aplel
aplel is now known as wantyapps
gog has quit [Ping timeout: 272 seconds]
<geist>
ooh someone said thunderx2?
<geist>
thundex2 does LSE, yes, but it's a first gen, dunno how well it works
<heat>
apparently poorly
<heat>
context is that cmpxchg is so unfair they had to introduce a retry loop in a cmpxchg loop to drastically improve fairness
<heat>
and performance
<heat>
(cmpxchg loop "decays" into a spinlock)
<mjg>
fairness aside these arms used to have absolutely dogshit scalability when faced with something like this
<mjg>
this includes the graviton cpus
<mjg>
that's compared to intels ofc
<heat>
iirc amd also had some really awful fairness issues in a similar situation
<heat>
like, modern epyc amd 2 or 3 years ago
<mjg>
i have not heard about that
<mjg>
anyhow i'm heading off
<mjg>
ch34rz
<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
<heat>
like, the huge system stalls didn't repro under similar-sized intel systems
<Mondenkind>
wait freeつ ◕_◕ ༽つ
<geist>
also thunderx2 is 4 way SMT
<geist>
but yeah there were some things they were going to fix with x3 before marvell got ahold of cavium and apparently killed it
dalme has quit [Remote host closed the connection]
Matt|home has joined #osdev
MiningMarsh has quit [Ping timeout: 256 seconds]
frkazoid333 has joined #osdev
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
heipiao233 has quit [Quit: Konversation terminated!]
heat has quit [Ping timeout: 264 seconds]
MiningMarsh has joined #osdev
Gooberpatrol66 has quit [Ping timeout: 260 seconds]
<kof673>
ndows 10), 16-bit OS/2 (1.x) and 32-bit OS/2 (2.x)
<bslsk05>
ptspts.blogspot.com: pts.blog: How to cross-compile to various EXE files using OpenWatcom C compiler on Linux
<kof673>
these are just like stupid c89 command-line utilities like "wc" -ish and such
jjuran has joined #osdev
<kof673>
(via wine the first 3), ow post above is linux x86-32 binaries
goliath has joined #osdev
<kof673>
anyways, you probably have a few choices for windows 95 benchmarks lol
* kof673
zzzzzzzzzzzzzzzz
bauen1 has joined #osdev
night has quit [Read error: Connection reset by peer]
night has joined #osdev
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
xenos1984 has quit [Ping timeout: 264 seconds]
xenos1984 has joined #osdev
Vercas3 has quit [Quit: Ping timeout (120 seconds)]
Vercas3 has joined #osdev
003AA1543 has quit [Quit: Nothing in this world is hopeless!]
woky has joined #osdev
node1 has joined #osdev
X-Scale has quit [Ping timeout: 250 seconds]
zzo38 has left #osdev [#osdev]
josuedhg has joined #osdev
node1 has quit [Quit: Client closed]
node1 has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
gog has joined #osdev
pruiz has joined #osdev
khimaros has quit [Remote host closed the connection]
khimaros has joined #osdev
<zid>
nikolapdp is it 10pm yet
xenos1984 has joined #osdev
<nikolapdp>
zid it's not
<GeDaMo>
It is in Mongolia :|
pruiz has quit [Ping timeout: 246 seconds]
gog has quit [Ping timeout: 268 seconds]
gorgonical has joined #osdev
pruiz has joined #osdev
<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
netbsduser has joined #osdev
flom84 has joined #osdev
pruiz has quit [Ping timeout: 264 seconds]
zxrom has quit [Ping timeout: 252 seconds]
josuedhg has quit [Quit: Client closed]
theyneversleep has quit [Remote host closed the connection]
<bslsk05>
Minnerlas/sic - Sic IRC client for BSD 2.11 (0 forks/3 stargazers/MIT)
<mjg>
specifically, do they talk tech
<heat>
mjg, yes
<mjg>
nice
<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
<geist>
nikolapdp: cool thanks
<nikolapdp>
no problem
<nikolapdp>
i want to see it running on an actual pdp :)
<geist>
i just want this place to be positive. mostly talking about making progress, asking questions, being interested in stuff
<geist>
that's the general statement of the channel
<heat>
i want to bikeshed a little and mention that linux (and other systems) does roughly fall into "operating system development"
<geist>
negativity makes me (and probably other folks) stay away
<heat>
in case you're talking about our little discourses from time to time
<heat>
but i generally agree with your sentiment
<nikolapdp>
i feel like it's fair to discuss what linux, or bsds or whatever do
<geist>
agree
<nikolapdp>
but i am one of the newest here so :/
housemate has quit [Ping timeout: 264 seconds]
<mjg>
i don't know if one can genuinely discuss any OS without a solid dose of shitting on it though
<geist>
yes, you can
<nikolapdp>
you can just say "thing is bad"
<nikolapdp>
no need for insults i guess
<mjg>
you can be polite about it for sure
<geist>
exactly
<mjg>
but reality is most stuff is just not good
<nikolapdp>
so say it like that
<geist>
but shitting on it drives people away is my point
<heat>
you can focus on what you like instead of what you don't like
<mjg>
... while papers you will find are trying to paint the opposite picture
<geist>
if nothing else because now they're less likely to point out what they're doing for fear of getting shit on
obrien has joined #osdev
<mjg>
that is fair
<geist>
remember not everyone here is trying to build the bestest/fastest/most scalable thing
<geist>
that's just one aspect of a wide array of stuff to do in this area
<heat>
you can build the funniest thing and end up with ponyos
<geist>
woot yes
<nikolapdp>
is that a thing
<heat>
yes, klange's
<nikolapdp>
i want to laugh
<heat>
april fools joke
<geist>
oh wow, klange isn't here
<geist>
ponyos was an annual treat for a while there. a reskin of taurous (i can never spell it)
<geist>
that they were working on for a while
<geist>
one of the most advanced of the hobby oses for a lot of the 2010s
<heat>
toaru
<mjg>
is there a spot where people who do work on kernels hang out and talk tech, other than project-specific
<mjg>
i mean kernels which at least reached multisuer
<heat>
here and discord?
<geist>
well, we used to d a lot of that ere, but i think the number of active folks has slowly dwindled
<mjg>
perhaps there is a mailing list or something other old fashioned
<nikolapdp>
lkml
<mjg>
geist: ye i remember at least in freenode times
<heat>
oh the forum, i dunno if that's still active
<dostoyevsky2>
templeos forums
<geist>
and again i think we can talk that sort of stuff
<geist>
i just would like to keep it positive to try not to drag the mood down
<geist>
perhaps this is from working at google too long, where everything is positive all the time
<geist>
but frankly, it's pretty nice
<mjg>
visit poland for a week to recalibrate
<heat>
hey geist how large process-wise does a generic fuchsia deployment get?
<mjg>
i'm afkin'
<geist>
hmm process as in what?
<heat>
number of active processes
<geist>
generally in the 100-200
<geist>
a few thousand threads
<heat>
i vaguely remember you talking about hitting a wall wrt page -> mapping in some awful case
<heat>
maybe chromium?
<geist>
yeah there is some work there to unwind how the vmo chains work
<heat>
with regards to a simple list of vm region mappings in a vm object
<geist>
yep. the old libc COW chain problem
<heat>
i am wondering how large the n in O(n) needs to be
<heat>
ah ok it was a COW chain problem?
<nikolapdp>
heat i am sure i've already asked you this, but how does your rcu work
<heat>
how do you get a deep chain, naturally?
<heat>
well, i guess the vm system in zircon kind of lets you create one artificially
<geist>
well basically every time you cow clone it to map it into another process it creates another one
<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
<bslsk05>
github.com: Onyx/kernel/kernel/rcupdate.cpp at master · heatd/Onyx · GitHub
<geist>
the trick is the way the cow clones work now it's a binary tree, not an arbitrary splay
<geist>
it was an algorithmic optimization that works pretty well for most stuff, but terrible for vmos that get cloned a lot
<geist>
so there's *always* a binary copy made and a new parent placed above the current one
<geist>
so as you keep cloning a thing is keeps building a deeper network
<geist>
vs splaying out
<heat>
oh do you necessarily need to keep all cow chains in a single "chain"?
<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
<geist>
there's no 'garbage collection' that has to run asynchronously
<geist>
but downside is deep
<geist>
well, all cow chains of a single vmo
<geist>
so the big one is libc.so which gets duped and COWed in basically every process
flom84 has quit [Remote host closed the connection]
flom84 has joined #osdev
<heat>
wait, how does the binary tree not solve the issue?
<geist>
it's a very very unbalanced tree
<geist>
think of it as one entire arm of a very unbalanced tree. more of a oh i dunno
<heat>
oh :(
<geist>
it's a directed acylic graph, but the property is every node has exactly two children at most
<heat>
i have an interval tree implementation with a wavl tree under it
<heat>
it kind of keeps the O(log n) i think, you might want to consider it
<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
<geist>
interval tree, what is it tracking?
<heat>
start offset, end offset of the map
<geist>
out of what? the address space?
<geist>
or a map of what part of the vmo is mapped?
<heat>
all mappings of a vm object add a [start file offset, end file offset] interval to the tree
<heat>
even COW'd ones
<heat>
but i can be a bit more direct cuz UNIX vm doesn't need to expose all that CoW vmo jazz
<geist>
ah yes, indeed
<geist>
we've thought about that
<geist>
well, we do hae that basically, per vmo we keep a list of all the mappings of it
<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
<nikolapdp>
geist how public is fuchsia code
<heat>
yeah but that's life isn't it
<geist>
nikolapdp: 100%
<nikolapdp>
is it buildable outside google :P
<heat>
i'm pretty sure adding mappings straight onto the struct page is counter-productive in general
<bslsk05>
fuchsia.googlesource.com: zircon/kernel/vm - fuchsia - Git at Google
<geist>
er double paste
<geist>
heat: yeah we've stayed away from that. BSDs have the uh, what is it
<heat>
PMAP!
<geist>
little data structure that tracks every mapping of every page
<geist>
well, pmap is the overall structure
<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
<geist>
yep, i forget if we added that
<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
<heat>
isn't that the main container for the pages?
<bslsk05>
fuchsia.googlesource.com: zircon/kernel/vm/include/vm/vm_page_list.h - fuchsia - Git at Google
<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
<nikolapdp>
why the heck does fuchsia need 80-90gb of space to build
<geist>
a lot of the complexity there is we have some ability to insert sentinel pages for various optimizations
<geist>
nikolapdp: it only really needs more like 20-30GB
<heat>
RADIX TREE
<geist>
it depends on what you're building
<nikolapdp>
what are the options
<geist>
nikolapdp: what sort of machine do you have to build on? I can tell you if it's feasible or not
<heat>
they're all pretty fuckin big
<geist>
keep in mind it's a *very* chonky build
<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
<nikolapdp>
geist, a 64gb ram, r7 7700x
<geist>
ah you could actually build it then
<nikolapdp>
plenty of starage if it's 30gb it needs
<nikolapdp>
how bad is it lol
<heat>
someone that can build fuchsia outside of google? woah!
<geist>
so if you want, you can do it. i'd start with a `bringup.x64` build
<geist>
it'll still take a solid few hours
<nikolapdp>
i need a bit more than that :P
<heat>
nikolapdp, you'll see a lot of rust lto in htop
<nikolapdp>
ah lovely
<geist>
the real limiting factor right now is memory, but 64GB is perfect for it
<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
<nikolapdp>
geist is there some documentation about how to build the bringup things
<heat>
i mean... debug builds are also generally slow as hell to build, maybe not because of lto
<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
<geist>
nikolapdp: yes it's on the whole fuchsia docs page
<geist>
once you set it up its just `fx build`
<heat>
llvm is like 3 or 4x slower to build on a debug build
<nikolapdp>
how do you set up the `bringup.x64`
<heat>
RTFM
<geist>
it's on the docs
<geist>
`fx set bringup.x64`
<nikolapdp>
ah ok
<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)
<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
<bslsk05>
fuchsia.dev: Configure and build Fuchsia
<geist>
par tof the reason it uses so much disk is it will pull down many GB of prebuilt stuff. toolchains, etc
<geist>
qemu, etc
<geist>
OTOH it's basically completely standalone
<nikolapdp>
huh apparently no amd gpu acceleration support
<geist>
correct
<geist>
it will run just fine on your AMD cpu though, which the docs say explicitly otherwise
flom84 has quit [Quit: Leaving]
<nikolapdp>
i really hate all the piping straight into shell
<geist>
yeah, i really hate that too
<geist>
download it and look at it first if you want
<geist>
that's the one time it does that
<geist>
also i hate that the default download of the source is completely silent
<heat>
hey you nailed the options in fx
<heat>
no underscore options!
<geist>
you have to generally add -v to get stuff to show you what it's doing
<nikolapdp>
yeah just says creating project
<geist>
there's a mentality of a lot of the server folks at google that commands should be silent unless error
<geist>
which makes some sense i guess
<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
<zid>
saves you having to have an 'if interactive' version
<zid>
in the code
<zid>
lot of tools follow that rule but ONLY if isatty fails
<heat>
stderr goes brrrrrrr :(
<heat>
i mean goes errrrrrrrrr :(
<nikolapdp>
ERRRR
<zid>
so now it makes no god damn sense when you try to debug your scripts :P
<geist>
note the default fx set is debug, which will compile a lot faster (though it's larger)
<geist>
you have to pass --release if you want the release version
X-Scale has joined #osdev
<nikolapdp>
how much larger
<geist>
oh probably a few GB. not a lot
<geist>
just if that's an issue
<nikolapdp>
that's fine
<nikolapdp>
i have like a tb free
<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
<geist>
so the builds pull down .o files off a server as fast as it can serve it
<geist>
so builds are like a handful of minutes if you have a fat pipe
<geist>
frustrating, because it makes it easier to forget that stuff is huge
<nikolapdp>
kek
<nikolapdp>
"chromium/deps/icu@latest"
dalme has quit [Read error: Connection reset by peer]
<nikolapdp>
heh does it build chromium too
<geist>
no, those are prebuilts
<geist>
which is part of the gigantic amount of downloads
<geist>
the source tree downloads all the prebuilts for everything you might ever want to build, even if you dont
<nikolapdp>
nice
<geist>
at least saves the trouble of fetching during a build, which is a general no-no
<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++
<nikolapdp>
good to know my internet connection will be saturated for a while
<geist>
yah my workstation at the office is a fancy nice 64 core threadripper + 256GB ram
<geist>
RIP and TEAR
<geist>
FWIW the kernel itself builds in like 45 seconds
<nikolapdp>
that's good
<geist>
we dont LTO it and so the linkage is only like 10 seconds
<nikolapdp>
what else does it build
<heat>
EVERYTHING
<geist>
everything
<geist>
it's generating a complete system image
Vercas3 has quit [Quit: buh bye]
<nikolapdp>
what does that entail
<nikolapdp>
like what's the userspace like
<heat>
bringup sounds like "oh haha very minimal system with the kernel and base userspace" but it ends up building like 40K object files
<geist>
yep. a lot of those are tests too, also host side tests
<geist>
we love us some unit tests
Vercas9 has joined #osdev
<nikolapdp>
do i need to run them :P
<geist>
the final image of a bringup build is like 20MB
<geist>
if you want?
<geist>
no the build doesn't run the tests
<nikolapdp>
ah good
<geist>
there are `fx test` stuff for that
<geist>
there's a qemu in there so the fastest way to see if something is going is
<geist>
`fx qemu`
<geist>
it'll build everything it needs, and then run it in qemu
<geist>
will use KVM if present
<nikolapdp>
still downloading stuff
<nikolapdp>
(:
<geist>
yah aside fro the prebuilts there's about 150 git repositories too
<geist>
some of which are fairly large, but the main one is fuchsia.git, whcih is at the root of the tree
<heat>
serbian DSL connection
<nikolapdp>
it's fiber actually
<heat>
pray your mom doens't use the phone or you'll have to restart the whole thing
<heat>
oh :(
<nikolapdp>
thought at 250mbps
<geist>
well, i have the problem ehre that i have a 100mbit link to my office, and it really chokes on this stuff
<nikolapdp>
heh i beat google then :P
heat has left #osdev [Leaving]
heat has joined #osdev
<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
<heat>
oh i hate powerlines
<heat>
i have one too
<nikolapdp>
haven't heard of those
<heat>
they promise you the fucking world but end up giving you a super mid connection
<nikolapdp>
huh done downloading
<nikolapdp>
surprisingly not bad
<geist>
yahnat least it's really solid, but just about 100mbit
<geist>
du it and see how but it is
<nikolapdp>
34gb
<heat>
basically they transport data across your power lines
<geist>
there ya go, thats about right
<heat>
problem is the package says 1400 MBPS!!!!!!!!! but you end up with 100mbps and you're pretty lucky
<geist>
yep. i could set up a wifi bridge, but i bet at best i'd only get like 300mbits
<geist>
that's also a similar lie
<geist>
you never really get anything close to the full speed, theres just too much overhead
<nikolapdp>
wait you can achieve reasanoble speeds over power lines
<nikolapdp>
that's cool
<geist>
but if you can get half of it that's not too bad
<geist>
the one i use for the rest of the house is MoCA. ethernet over coax
<geist>
that you can actually get pretty solid fast stuff,m i just dont have a coax line in that room
<nikolapdp>
is fx setup-ufw
<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
<nikolapdp>
required
<geist>
no, unless you want to network it
<geist>
dont do that yet
<geist>
that's mostlky for talking to devices, whcih you dont have
<nikolapdp>
so the bringup then
<geist>
you should just need to add that bin dir to your path and do a `fx set bringup.x64`
<geist>
and then fx build
<nikolapdp>
yup doing it
<nikolapdp>
let's see how long it takes
<nikolapdp>
all core 5ghz go brrr
<heat>
the great onyx business system takes like 3 minutes on a crappy laptop
<nikolapdp>
i should hope so
<geist>
set NINJA_STATUS_MAX_COMMANDS=16 if you want to see a neat work in progress display
<geist>
i think that is only present on our fork of ninja, or extremely tip of tree
<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
<geist>
yah you can set those to get more verbose is all
<geist>
the default of the buidl has a bit of context
<nikolapdp>
number of jobs out of total jobs if fine by me
<geist>
`367.406s [40506(+14)/86263(+45743)] ...` is what mine is showing is all
<zid>
Time to madly refresh nyaa in 2 minutes nikolapdp, entertain me
<nikolapdp>
hello to you to zi
<nikolapdp>
zid
<geist>
the elapsed seconds is nice because if you walk up to it later you can see how many centiseconds it took or whatnot
<nikolapdp>
heh
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<nikolapdp>
lol does it really need to do all of that linting
<geist>
we are google everything is linted and double checked and unit tested!
<geist>
it's job security!
<zid>
Gotta figure out how to bill for a full day
<nikolapdp>
geist, sure, but on every build lol
<geist>
there are switches to turn some of that off
<geist>
but they're really not a lot of the build time
<geist>
clippy is a lint thing we run on a lot of rust stuff
<nikolapdp>
heh i don't know
<zid>
How bad is rust for compile time btw
<nikolapdp>
almost half of the jobs done
<zid>
I've never checked
<nikolapdp>
it's *not good*
<nikolapdp>
but nothing is compared to like c
<zid>
huh, surprising
<nikolapdp>
why
<nikolapdp>
with all that metaprogramming, it can't be fast
<geist>
we have some rust projects in the tree that take a solid 5 or 6 minutes
<zid>
I figured it'd be like, marginally slower than a C compiler, but nowhere near as bad as C++ level
<geist>
and with LTO some C++ projects get that big too
<zid>
I don't think rust code has the n! issues that C++ has
<heat>
i think you should build chromium now that you're at it
<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
<nikolapdp>
yeah rust is possibly worse than c++ to build
<nikolapdp>
it's certainly no c
<geist>
and there's a tremendous amout of rust template expansion, depending on the style of the project
<geist>
indeed. only with LTO does large C++ porojects get to rust time
<geist>
also rustc is heavily multithreaded, unlike clang
<nikolapdp>
and even that's not helping :P
<geist>
so though it may take 5 minutes to link, that may be running 32 threads simultaneously
<nikolapdp>
but clang assumes that multithreading would come at a different level
<geist>
so if you have a 4 more machine it may take a lot longer
<nikolapdp>
ie at the level of the build tool
<Mondenkind>
i am once again begging mainstream compiler devs to throw out the llvm and build properly fine-grained-incremental crap
<nikolapdp>
which for c works perfetctly
<nikolapdp>
unless you do to
<heat>
lld also multithreads heavily
<nikolapdp>
lto
<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
<geist>
based on both number of cpu cores and amount of ram
<heat>
interpreted languages would NOT have this problem, they compile in 0s
<zid>
wtf is rust DOING to be that slow
<geist>
heat: it depends on the style of LTO. there's a 'split up the objects, lto them separately'. faster but less effective
<heat>
thinlto ftw
<geist>
and there's 'all one program everything considered'
<geist>
right, we are not using thinlto
<zid>
Rust's grammar is pretty picky, that's great for compilation speed
<geist>
the borrow checker is very very expensive
<zid>
Is it just spending forever picking apart invariants for the bo-
<heat>
i'm not sure if lld still spawns all the threaden
<Mondenkind>
parse time is irrelevant
<geist>
and like i said it has a kinda template expansion that's more intrinsic to thelanguage that C++
<zid>
trying to untangle a mess of things and 'flatten' it back into fast code?
<nikolapdp>
also a lot of templates
<heat>
i know they capped the thread spawning at mjg's request
<heat>
they used to spawn a thread per core
<geist>
i think i've seen rust go up to 32
<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
<zid>
boom, it's out
<geist>
so each of the threads ends up duplicating a fair amount of work of the other threads
<zid>
ah so it's not holistic enough
<geist>
ie, if 5 of the 32 partitions are using the same rlib then they'll all recompile the rlib, basically
<zid>
Thread 3 is doing step C so it needs to figure out step B and D for itself
<geist>
yah basically
<zid>
because thread 2 and 4 might still be running and it can't share
<geist>
whereas thread 4 may be using F which just needs B, etc
<geist>
but B gets compiled for both
<geist>
but FWIW they rip and tear. very little internal locking
<Mondenkind>
tbf scheduline is like. _the_ problem. and duplicating work is sometimes (asymptotically, even) the correct tradeoff to reduce communication
<nikolapdp>
basically all of rust stdlib is templates
<Mondenkind>
(though i certainly wouldn't be surprised if they were being stupid here)
<nikolapdp>
a crap ton of them
<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
<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
<geist>
bug
<nikolapdp>
lol rust needs a crapload of servers to offload work to be managable
<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
<geist>
so once the cache is primed at hot you generally get 100% hit rate, until you modify something
<nikolapdp>
or you could just write c and compile everything in minutes :P
<geist>
well see the thing is with RBE it kinda makes it not matter, provided you have the bandwidth
<geist>
*except* when developiubg things
<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
<geist>
for folks that dont have supercomputers. i've railed against it, but it's just not the priority
<nikolapdp>
i guess i got to the c++ part of the build because now each job is taking 10s
<geist>
a lot of those first steps are extraneous doing job steps, like building directories, stamp files, etc
<nikolapdp>
sorry, 20s
<nikolapdp>
what's fuchsia used for anyway
netbsduser has quit [Ping timeout: 246 seconds]
<nikolapdp>
we've passed 1<<16 jobs
<nikolapdp>
whoop
<dostoyevsky2>
what does fuchsia use from chromium?
X-Scale has quit [Quit: Client closed]
bl4ckb0ne has quit [Remote host closed the connection]
<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
<geist>
also some stuff in 'driver' thats pretty interesting
<geist>
or is it device?
<nikolapdp>
there's /dev
<geist>
no i mean that command
<nikolapdp>
ah
<heat>
"why not just run linux" invalidates like all of the hobby operating systems
<nikolapdp>
it's driver
<geist>
`driver list` `driver dump` etc
<nikolapdp>
heat i don't think fuchsia is a hobby os
<heat>
but it is an operating system
<nikolapdp>
ohthat's neat
<geist>
`component list` is pretty interesting too
<nikolapdp>
heat: and i didn't say why not run linux, i said why emulate instead of run linux
<geist>
component mananager is kinda like the main superserver of fuchsia
<geist>
it's showing you essentially all of the 'components' of the system which is kinda the main service control
<heat>
nikolapdp, it's faster
<nikolapdp>
yeah a lot of them are pcie devices
<geist>
think of the shell as sort of sitting on the side with superuser like capabilities
<nikolapdp>
heat faster what
<heat>
a linux compat layer is faster than a vm
<dostoyevsky2>
nikolapdp: I wonder if the graphics support is better in fuchsia than in Linux
<heat>
and integrates more smoothly
<nikolapdp>
heat i am not talking about a vm
<nikolapdp>
if you're writing an os that's just going to run linux stuff, why not run linux
<nikolapdp>
on bare metal
<heat>
emulating linux is really valuable for products
<heat>
including what google probably really wanted/wants to do which is to run android apps </speculation>
<geist>
`kstats -m` and `kstats -c` are kinda interesting too
<dostoyevsky2>
nikolapdp: I like running linux for servers but for the desktop I don't like it that much
<geist>
`kcounter` is sort of interesting
<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
Left_Turn has quit [Read error: Connection reset by peer]
<nikolapdp>
geist a bunch of interesting tools there
<nikolapdp>
heat: yeah well that's why i asked if there was a poisx layer
<nikolapdp>
but at that point, why not just run a posix system
<geist>
`k` is interesting, it passes the rest of the command line to the kernel
<nikolapdp>
what do you get from reinventing the weil
<nikolapdp>
wheel
<geist>
so `k help` shows you the kernel's command line
<nikolapdp>
so the question is, what do they think they gain by reinventing the wheel
<heat>
thank you for telling me google is using linux
<heat>
i did not know that
<nikolapdp>
well clearly you don't want to have a productive conversation about this so let's just drop it
<nikolapdp>
geist, how can i build the "bigger" config
<geist>
i alas can't comment on the why of fuchsia, for FWIW
<geist>
fx set core.x64
<nikolapdp>
see, heat, it's not that obvious
<heat>
i can't answer your questions, i am not google nor a google PM nor a fuchsia core team member
<geist>
it'll reuse the same out dir and you can just build
<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
<geist>
the really big one is `workbench_eng.x64`
<nikolapdp>
how do i get out of the kernel shell lol
<heat>
i can however tell you that "why not just linux" is entirely depressing and really worsens the field overall
<heat>
we should not all use the same fucking awful operating system
<geist>
just stop qemu
<geist>
ctrl-a x
<nikolapdp>
dostoyevsky2 they did fork an exsiting engine when they started
<nikolapdp>
ah so no "please turn off" incantation
<geist>
oh there might be
<geist>
shutdown? poweroff? i forget
<geist>
type help to see the commands
<nikolapdp>
too late, killed it :P
<nikolapdp>
heat: i mean you're recreating linux, just in c++
<geist>
the kernel shell is bsically just LK. it's the same command setuff
<nikolapdp>
so your point is moot there
<nikolapdp>
heh neat
<heat>
what's chromium if not firefox rewritten?
<nikolapdp>
let's see how long this takes
<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
<geist>
yah workbench_eng.x64 is the full one
<geist>
i think that starts a gui and everything
<nikolapdp>
oh what kind of gui is it
<nikolapdp>
and better question, how long to build it
<geist>
i say that because i really haven't fiddled with it
<geist>
i dunno, honestly. it's changed over the years and it's been a solid 6 months since i booted it
<nikolapdp>
ah fair
<nikolapdp>
heat: and my point wasn't "why not use linux", my point was "why use something else to emulate linux"
<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
<nikolapdp>
which you seem to repeatedly miss
<nikolapdp>
oh you support riscv
<nikolapdp>
the readme only mentioned arm and x86
<geist>
oh where? I should get that updated
<nikolapdp>
though i didn't look that deeply into it
<heat>
nikolapdp, reread my messages
<heat>
i touched that too
<geist>
riscv64 to be precise
<nikolapdp>
let me see if i can find it
<nikolapdp>
heat you didn't really, the closest you got was "what's chromium if not firefox rewritten?"
<heat>
<heat> emulating linux is really valuable for products
<nikolapdp>
oh it's done already
<heat>
<heat> including what google probably really wanted/wants to do which is to run android apps </speculation>
<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
<nikolapdp>
heat: that doesn't answer why not linxu
<nikolapdp>
you're just saying linux important
<heat>
you have a system
<heat>
it's different and stuff
<heat>
you want it to be useful to other markets too
<heat>
linux?
<heat>
the alternative is to port everything
<nikolapdp>
no, the alternative is to run linux
<heat>
to your weird excentric system
<nikolapdp>
like they've already been doing for decades at this point
<nikolapdp>
geist, what can core do
<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
<heat>
ok so your question is why fuchsia at all, not why linux in fuchsia
<dostoyevsky2>
s/heat:/nikolapdp:/
<nikolapdp>
no, the question is why use fuchsia to run linux software
<nikolapdp>
i am not at all referring to native fuchsia stuff
<heat>
you keep the advantages of fuchsia while running linux, in the same system
<nikolapdp>
and those are?
<nikolapdp>
advantages i mean
<heat>
stability of a microkernel with ABI stability with running the netflix android app
<nikolapdp>
because linux is so unstable, rigjt
<geist>
nikolapdp: has a net stack, can probalby run starnix, etc
<nikolapdp>
right, so now comes the net config part
<heat>
i've been having oopses and the system goes down
<nikolapdp>
well go job, i haven't
<nikolapdp>
the only issue i've come across was an oom
<nikolapdp>
and micokernels won't save you there
<heat>
nvidia drivers have been completely fucked for a few releases, system just crashes
<nikolapdp>
well i doubt fuchsia has better nvidia support than linux
<nikolapdp>
that's just nvidia being nvidia
<nikolapdp>
i am on amd and it's rock solid
<heat>
ideally in a microkernel world you restart the server and it's done
<nikolapdp>
sure
<nikolapdp>
assuming you get someone to write a whole nvidia stack for you
<geist>
nikolapdp: i think yo uwant to build workbench_eng, not core
<nikolapdp>
i will then
<geist>
thats the full monty, it's surprisingly not that much bigger to build
<nikolapdp>
yeah only 210 jobs more
<nikolapdp>
is that the gui one?
<geist>
i think so yeah
<geist>
you can kinda tell how it works by looking at product/ and there's a .gni file for each of them
<nikolapdp>
you don't run the gui with fx qemu i imagine
<geist>
some of them are baiscallt lower level + ne stuff
<geist>
you can totally run the gui with fx qemu
X-Scale has joined #osdev
<nikolar>
yeah not showing up
<nikolar>
the gui i mean
<geist>
you rebuilt workspace? wow
<geist>
oh, run fx qemu with.... -g?
<geist>
look at --help
<geist>
you need a display
<heat>
do you still have the like... 3 emulators?
<nikolar>
ah there we go
<geist>
heat: yep!
<heat>
lol
<geist>
fx qemu is the low level one where you have to kinda manually drive it
<nikolar>
thogh now i just have a terminal in a qemu window lol
<nikolar>
how do i start the gui
<geist>
ffx emu is the higher levle one, which isprobalby what you should be running but i honestly dunno how to use it
<heat>
wasn't there like a... fx vdl or something?
<geist>
yeah, i think that's gone now
<geist>
so i think it's just 2
<geist>
nikolapdp: dunno
<nikolar>
well fx emu start does start an emulator
<nikolar>
it's now portrait and i can't type into it
<zid>
You accidentally emulated a pinball table
<zid>
They are also portrait and cannot be typed into
<nikolar>
do they have text too
<geist>
i honestly do not know
<geist>
i have not run workbench in an emulator in like years
<heat>
gui is bloat
<nikolar>
indeed
<geist>
moe or less yes
<heat>
oh can you run X in starnix directly?
<geist>
the products that ship on fuchsia have their own gui, so they basically overlay on top of it and build their own stuff
<heat>
i know there's like a wayland shim for the Real Compositor by default
<geist>
and there is a whole fuchsia compositor and whatnot
<geist>
there's a whole mechanism to punch that out of starnix and composite, indeed
<geist>
problem is wha you get is all mechanism and not really a product
<geist>
product comes as a layer on top of what you're getting in the source tree
<geist>
it's kinda like stage3 gentoo or whatnot
<nikolar>
well all i get is a graphical terminal, instead of an emulated serial i assume
<dostoyevsky2>
nikolar: how much of your 1tb of free space is gone by now?
<nikolar>
let's see
<nikolar>
almost exactly 100gb
<heat>
at this point your whole hard drive is google prebuilts and rust programs
<nikolar>
not whole, 1/20th
<geist>
anyway there might be a gui there, but i honestly dunno how to start it
<geist>
we usd to have a tiling like gui, i forget what it was called
<geist>
but i think we dont work on that anymore
<heat>
armadillo
<nikolapdp>
another project in the google's graveyard :P
<dostoyevsky2>
They should make a Zombie Wars game out of Google's graveyard
<geist>
heh
<klys_>
heat I got the same assert problem as previously. fixable though
<heat>
it's entirely possible CSM just doesn't work with new qemu
<heat>
ovmf and qemu kind of want to go hand in hand, and CSM is just... crap that's really unused
<nikolapdp>
can't you just boot bios directly
<nikolapdp>
instead of uefi+csm
<heat>
yes, that's why CSM in qemu is unused
<nikolapdp>
exactly
<klys_>
totally unwarranted response to a slight foible
<nikolapdp>
what
<heat>
i kind of participated in that CSM axing decision and all i could say was good riddance
<nikolapdp>
how "kind of"
<klys_>
all I have to do is edit one line to say >= rather than > and it should work fine