<heat>
Ermine, skarnet has a very pecular NIH syndrome of minimalism
<heat>
not exactly the greatest approach either :)
<mrvn>
heat: there are multiple flabours of NIH syndrome?
Matt|home has quit [Remote host closed the connection]
terminalpusher has quit [Remote host closed the connection]
<mrvn>
What do they put in paper straws that they don't melt and how is that better than bio degradable plastic straws?
<Mutabah>
wax I think
<epony>
you wish ;-) organic glue
<epony>
^ highly concentrated farts
<mrvn>
and that with the sudden death of bees.
invalidopcode has quit [Ping timeout: 246 seconds]
<epony>
you know they put elephant dung in some gins and some coffee varietes have been eaten and excreted by an animal before they are used for coffee
<epony>
you can discover the mysteries of cow dung masonry with a bit of imagination too
<epony>
that shit's very popular
<epony>
in some parts of the world it's sprayed over the fields in excess amounts so the entire country smells like an very shitty oil spill in the sea
<epony>
and it's even used for fermentation and biofuels so your car could run on processed dungshitfarts too
<epony>
^ the many uses of manure
Burgundy has quit [Ping timeout: 252 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
<kaichiuchi>
i log into irc cloud and this is the first thing I see
wootehfoot has joined #osdev
FreeFull has quit []
dutch has quit [Quit: WeeChat 3.7]
<geist>
Yeah there’s some here that just sort of spew nonsense continually
<Ermine>
Ah, there's an easier way, OSDev has the triple I need.
<zid>
if your question is what triple do you need
<zid>
we probably would have answered that directly
<kaichiuchi>
still not wrong to ask for a list
<Ermine>
zid: fair enough
<zid>
The answer is alpha-smells-alot
<kaichiuchi>
it'd be nice if clang had -list-triplets
<zid>
(anyone who disagrees is a liar)
xenos1984 has quit [Read error: Connection reset by peer]
heat has joined #osdev
<heat>
i got a glibc build going
<heat>
it probably works
<heat>
pog
<zid>
good work pog
<kaichiuchi>
question
<kaichiuchi>
does anyone know if gcc can do something like this
<kaichiuchi>
void func() __attribute__("use this when optimization level is 01-Ofast") void func() __attribute__("use this when optimization level is -Os");
<bslsk05>
gcc.gnu.org: Function Multiversioning (Using the GNU Compiler Collection (GCC))
<zid>
there's that
<zid>
and
<kaichiuchi>
mmmm
<zid>
the other one I forget
<heat>
that only works for target features
<zid>
oh really?
<kaichiuchi>
"Support is only available in C++ for i386 targets."
<kaichiuchi>
nonstarter
<heat>
yes
<zid>
you're doing i386 aren't you
<kaichiuchi>
I mean, it's not meant to be JUST for i386
<heat>
sounds like you need autoconf then
<kaichiuchi>
yeah sounds like it
<heat>
and gnulib for good measure
<kaichiuchi>
also, this looks like it compiles... both versions, and then selects the appropriate one at runtime
<kaichiuchi>
unless I'm reading into "At runtime" too hard
<kaichiuchi>
see, I have two giant switch-case statements which the compiler will probably not optimize for size very well
<heat>
yesterday I found that glibc's linux build is busted when one particular thing isn't available
xenos1984 has joined #osdev
<heat>
that made me debug for hours
<zid>
go on then
<kaichiuchi>
I mean, I'm slightly overcaring about these things right now
<kaichiuchi>
but I just want to see how much pain I could be in for later
<kaichiuchi>
"pain" loosely, this isn't a world ending issue
<kaichiuchi>
in short: if optimizing for speed, use the giant switch-cases; if optimizing for size, do the deduction at runtime for the opcodes
<kaichiuchi>
but I almost feel like that's too general
<kaichiuchi>
perhaps a compiler flag DEDUCE_CPU_OPCODES may be more efficient since some MCUs may in fact be able to fit the gigantic jump tables
<zid>
I'd be dumb and just make CFLAGS two different things in the makefile, -O3 -DUSESWITCH and -Os -DNOUSESWITCH
<zid>
make gameboy_slow and make gameboy_fast
<kaichiuchi>
yep
<kaichiuchi>
that's where I'm at
<mrvn>
kaichiuchi: those that can fit it all don't care about speed as they are so much faster than a gameboy
<kaichiuchi>
the MCU we use at work has 512KB flash
<kaichiuchi>
_maybe_ everything will fit to 512KB even if I use -Ofast
<mrvn>
for those you need to optimize for the MCU and throw out all else
<kaichiuchi>
maybe.
<mrvn>
You are just wasting time searching for a one-size-fits-all solution. That just doesn't exist for embedded devices.
<zid>
My entire emulator is like 30kB with -O3 using 64bit pointers
<kaichiuchi>
yeah I can't foresee it being stupidly huge no matter what I do
<zid>
that's enough space for *checks notes* every single rom.
<mrvn>
every kB you waste on "optimization" you loose for having games on the flash.
<kaichiuchi>
I wouldn't have games on the flash
<kaichiuchi>
they'd probably be loaded from a USB stick or an SD card or so
danilogondolfo has quit [Remote host closed the connection]
<heat>
guys
<heat>
shut up
<heat>
nerds
<zid>
heat
<zid>
you were supposed to say what the 'thing' was
<kaichiuchi>
heat: hey wanna get some pizza?
<zid>
heat's buying us pizza?
<heat>
kaichiuchi, im going to mcdonalds now sorry
<kaichiuchi>
there's a mcdonalds 5 minutes from my house
<zid>
big mac for m
<kaichiuchi>
I would not _dare_ go there
<zid>
jealous
<heat>
zid, oh ok, it's very boring, just that the Makefile subtly breaks if ldconfig isn't enabled on the build
<zid>
ah okay whatever that means
<kaichiuchi>
zid: how efficient do you think I could make the pixel FIFO
<zid>
'efficient' how?
<kaichiuchi>
is speed really going to be that gimped if I turn it on
<heat>
if it isn't, a particular object file gets compiled as part of the LIBC while being used in external utils
<zid>
oh, absolutely yes
<kaichiuchi>
that kind of strikes me as madness
<heat>
which is wrong because then when compiling the headers will mark functions as hidden
<zid>
it's the thing that stops you from cheating your arse off on the cpu
<zid>
I was going to add a scheduler to get around it but never got to it
<kaichiuchi>
yeah I have a scheduler
<heat>
and then when doing an object-file - libc.so link, the link fails because the symbols are there in the dso but are hidden
<zid>
sched + two cpus cores
<zid>
one that is pre-emptable
<kaichiuchi>
but I want to go further and do lazy evaluations
<zid>
and one that cheats its arse off
<heat>
I was completely confused as to what the fuck was happening and had to debug a good bit of the glibc build system
<heat>
bonkers
<kaichiuchi>
lazy evaluations will probably make it go really really fast
<zid>
use the cheating one until just before the next irq, write to video registers etc
<zid>
then switch to the proper one and catch the LCD back up
<kaichiuchi>
the final step in the madness is a JIT
<zid>
and do the careful intertwined part, go back to the dispater
<kaichiuchi>
and I refuse to believe that a JIT is not feasible
<zid>
JIT is slower
<kaichiuchi>
why?
<zid>
it doesn't gain you anything?
<kaichiuchi>
I mean yes, it's slower at first
<kaichiuchi>
i dunno. maybe it wouldn't.
<heat>
i'll never deal with JITs for self modifying programs
<kaichiuchi>
the closest I've ever seen people come to is cached interpreters
<zid>
You could theoretically make a faster JIT
<zid>
but it'd be incredibly difficult
<kaichiuchi>
i've never done a JIT
<mrvn>
does gameboy code self modify?
<zid>
It'd need to do the same dual cpu-core stuff
<zid>
but now as a JIT..
<kaichiuchi>
i really don't know what you mean by that
Matt|home has joined #osdev
<zid>
okay so the reason you can't just do case CALL_HL: break; as
<kaichiuchi>
mrvn: I think some games do
<zid>
PC = HL; cycles += 12;
<zid>
is because of all the crazy test-roms that sense the bus for when it reads memory
<zid>
by setting DMA, video registers etc up to change mid-instruction
<zid>
so you *need* a cpu core that can handle being interrupted by other things mid-cycle
<kaichiuchi>
what does sameboy do
<zid>
but 99% of the time, you are *not* running code that is trying to detect which cycle you're accessing memory on, and you can just use the above case:
<kaichiuchi>
liji doesn't use threads does he?
<zid>
you can use heuristics to determine which you can currently be doing
<zid>
emulate in the 'coarse' manner until a) just before an interrupt is going to happen (this is predictable)
<zid>
b) you access a hardware register
<zid>
then you switch to the 'fine' cpu emulator, until you are past that point
<zid>
so main() turns into n = calc_cycles_until_next_interrupt(); { coarse_emulate(n); fine_emulate(1); } or such
<kaichiuchi>
well, speed, and not necessarily accuracy is the goal
<kaichiuchi>
i should say, the minimum amount of accuracy necessary
<zid>
then why bother with the fifo at all
<kaichiuchi>
prehistorik man
<zid>
the only game that needs is is prehistorik man
<zid>
's title screen
<zid>
it's like.. 10x speedup to break that one game :P
<zid>
sha1 the rom and run two different emulator cores
<kaichiuchi>
I also don't know anything about how to generate sounds
<zid>
bad sound fairly easy, good sound impossible
<zid>
if you wanna know about how sound works xiph.org has a great video
<sortie>
mrvn, execve fails with ENOEXEC so the execvp POSIX clause kicks in that says to start it in /bin/sh and the empty shell script exits 0
<mrvn>
There is a lot to be said for true/false being a shell script
<mrvn>
sortie: damn you POSIX :)
<sortie>
Turns out #!/bin/sh is basically default
<mrvn>
I'm not sure if it was hpux or solaris or something else but I've seen /bin/true being a shell script with shebang and license and NOTHING else.
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
<GeDaMo>
I feel like there was an IBM thing where it was literally zero bytes
<mrvn>
GeDaMo: but that's the smallest C source that prints it's own source when compiled and run.
<heat>
sortie, 10 true
<heat>
your move
<sortie>
heat, contents?
<heat>
#!/bin/sh
<sortie>
heat, get rid of the whole shebang, it's cleaner
<sortie>
The shortest /bin/false I can think of is "! :" (no newline) (three bytes)
<heat>
but then it wont work out of the shell will it?
<sortie>
heat, sure, execvp takes care of that
<sortie>
Also the shell should have its own builtin optimizing it away
<heat>
but it doesn't?
<heat>
i don't see where in execvp you'd take care of that
<heat>
the kernel takes a shebang-less thing, it doesn't shebang to /bin/sh
<mrvn>
heat: if executable but no idea what it is fork a shell
<heat>
execve("./true", ["./true"], 0x7ffd2fd538b0 /* 60 vars */) = -1 ENOEXEC (Exec format error)
<sortie>
heat: rtfm https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html “In the cases where the other members of the exec family of functions would fail and set errno to [ENOEXEC], the execlp() and execvp() functions shall execute a command interpreter and the environment of the executed command shall be as if the process invoked the sh utility using execl() as follows:“
<bslsk05>
pubs.opengroup.org: exec
<zid>
does modern linux still load the 45 byte elf
<mrvn>
what if someone runs exec style functions on /bin/true other than execlp/execvp?
<zid>
that article is faily old now and relies on some.. quirks
<mrvn>
I wouold rather have true always work
<zid>
not needing +x to be set, the file being smaller than an entire elf header and getting padded, etc
<heat>
sortie, i think musl doesn't implement that
<sortie>
Do you actually ENOEXEC?
<heat>
I would love to tell you for sure that it does/doesn't but I don't speak "\0\1\2\4\7\3\6\5"[(0x17*base)>>5&7]
<heat>
sortie, yup
<sortie>
Should've used superior Sortix technologyt
<heat>
I can see that glibc definitely does implement it
<zid>
./teensy: cannot execute binary file: Exec format error
<zid>
I haven't tested if this kernel can actually run 32bit code at all though to be fair
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
<heat>
I highly doubt they would break it
<heat>
if they did, submit a bug report
<zid>
It abuses several defficiencies in an old elf loader
<zid>
it's not a legal elf
<zid>
gcc main.c -m32; 'fatal error: gnu/stubs-32.h: No such file or directory' that went well :P
<zid>
yea okay tried it with nasm, I just can't load 32bit elf
<heat>
zid, doesn't matter, whatever the kernel loaded, it will continue to load
<heat>
We Dont Break Userspace
<zid>
Except the times when they do
<zid>
which are rare and well reasoned
<zid>
but it happens
<zid>
Usually "Literally nobody uses this interface because it was broken since it was added" but still, it happens
<heat>
my slight refactoring of elf bss zeroing wasn't accepted because it could break old executables
<heat>
old *WRONG* executables I may add
<heat>
because the kernel never checked for ELF validity in a bunch of places, so now they're stuck loading things like out-of-order elf PHDRs and shit
<zid>
ye
terminalpusher has joined #osdev
gorgonical has joined #osdev
epony has quit [Read error: Connection reset by peer]
epony has joined #osdev
<heat>
sortie, why do you say glibc's code quality is bad?
<heat>
it looks fine to me
<heat>
at the very least it's "readable" and "commented", both of which are concepts foreign to musl
<zid>
glibc's code is good it's just.. very feature packed ;)
<sortie>
Mostly feels overengineered and GNU style plus lots of workarounds for poor kernel behavior
<zid>
which to some is bloat, to others is "handles all the edge cases correctly"
<gorgonical>
that's the general complaint I've heard, that it's much too feature-filled. One of musl's core complaints is that the compiled objects do entirely too many things
<gorgonical>
So statically-building it and trimming the features for what you need is borderline impossible
<zid>
glibc for example, lets you set custom printing characters for its printf
<zid>
which is super useful if you want that feature, but adds code to builds that don't need it
<zid>
and has several rand() implementations for if you want to match the old numerical principles rng for freecell, or a complex twister guy for doing real math
<gorgonical>
I was just discussing in a meeting that building glibc is "highly discouraged" because certain things just don't work and glibc doesn't really support/endorse those use cases, anyway
<froggey>
-ffunction-sections and -gc-sections seem like they should resolve the "too much stuff in a .o" problem. whether or not that actually works is another problem tho!
<gorgonical>
And I know it's not the 90s, but static linking is not exactly a dead, esoteric technique nobody uses anymore
<gorgonical>
froggey: yeah I do not know. It's been a long time since I read the musl thesis there
<heat>
sortie, the poor kernel behavior bit is something common to all systems, not just glibc linux
<heat>
glibc looks solid, high quality, well documented
<heat>
it is of course large, but such is the way of GNU
<heat>
and of course, such is the way of having a portable libc
<gorgonical>
heat: it is, but some code is programmed to glibc's idiosyncrasies, not general libc behavior
gxt has quit [Remote host closed the connection]
<heat>
gorgonical, like what?
<heat>
like GNU extensions? that's fine
gxt has joined #osdev
<gorgonical>
under what circumstances? I mean, it's fine for general-purpose computing
<heat>
If I'm writing something and an extension is useful (and I don't really care about portability), I'll use it
<sortie>
heat, if only someone had a kernel that didn't require libc hacks :D
<heat>
if I'm porting something it can ofc be a bitch, but that's life
<heat>
you sacrificy portability for "better code"
<heat>
sacrifice*
<heat>
or you wrap everything in 3 layers of gnulib and autoconf
<heat>
your choice really
<gorgonical>
right. the eternal trade-off. I am probably skewed some because of my regular work is so geared-down in terms of features
<heat>
sortie, totes. the important bit is that glibc does not require any libc hacks, the libc hacks are just hidden away in linux sysdeps shit (and maybe hurd? I don't know much about hurd)
<heat>
they had a kfreebsd port for some time
<heat>
god I sound like such a GNU chill atm
<heat>
s/ch/sh/
<heat>
but I'm impressed with glibc, I thought it was going to be harder
<heat>
it wasn't a fun experience mainly because they dropped the whole idea of having ports to many operating systems many moons ago
<heat>
(so you don't have docs or guides on what to do, but that's osdev)
xenos1984 has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
<heat>
also fwiw i'm definitely not excusing glibc being so shit at static linking
<heat>
that kind of sucks
<heat>
a 500KB printf("Hello World\n") is really poor
<zid>
yea glibc has.. linker issues in general
gog has quit [Read error: Connection reset by peer]
<zid>
I'm not sure what causes them
<zid>
I'm surprised you got it to static link at all, people claim it's not possible
gog has joined #osdev
<mrvn>
zid: all your named services stuff is still dynamic
<mrvn>
anything that does networking for example breaks when the system libc and your static libc are too far apart
<heat>
a good bit of this seems to be gconv and locale crap
gog is now known as pog
<heat>
pog
<pog>
heat
<heat>
🅱️
dude12312414 has joined #osdev
<mrvn>
Not sure when nss ABI changed last in glibc though. It's probably really stable by now
<heat>
do nss libs not use symbol versioning?
<mrvn>
heat: they just dlopen so I don't see why not.
<mrvn>
My experience with libc breakage predates versioned symbols.
<heat>
oh yeah ofc glibc also has stupid amounts of ac
<mrvn>
The big question is: Did they care about it?
<heat>
backwards compat
<heat>
probably
<pog>
we should always be breaking things
<pog>
gimme somethina break
<heat>
🅱️reak things
<mrvn>
FYI: Amiga OS has symbol versioning in like '85
<GeDaMo>
🅰lright
<mrvn>
compile time symbol versioning though
<heat>
isn't compile time symbol versioning just defines? lol
<mrvn>
Amiga OS libraries are more like c++ classes. They have a big jump table for functions and at compile time your function name turns into the offset into the table.
<mrvn>
So openfont(name) turns into font_library[-456](name)
<mrvn>
function pointers go negative, public data goes positive relative to the library base
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<kaichiuchi>
hi
<mrvn>
wo?
<pog>
nya
xenos1984 has quit [Ping timeout: 252 seconds]
<sham1>
Function pointers being negative is absolutely disgusting
<zid>
but how else are you going to see if they're valid kernel functions
<sham1>
Well that, but I meant more the negative offset thing
<kaichiuchi>
heat: why would you ever want to static link glibc?
<sham1>
Like with the AmigaOS thing that was posted above
<zid>
why would you not want to
<mrvn>
sham1: so you better have member data pointers negative?
<zid>
it's a great big bundle of useful functions in a free library distributed over phone lines
<sham1>
I'd rather have neither negative
<mrvn>
kaichiuchi: so your ld.so works
<zid>
I didn't see it
<zid>
maybe I should be glad?
<kaichiuchi>
hm okay
<kaichiuchi>
statically linking a C standard library just seems unnatural
<mrvn>
how about a header only libc? :)
<pog>
yes
<pog>
header only all libs
<zid>
yes, header only only
<pog>
header only everything
<zid>
and never stop doing this, only head only only
<pog>
#pragma only
<zid>
#pragma never_not
<pog>
zid
<zid>
glop
<pog>
let's pair program an operating system
<pog>
you do all the headers and i'll do all the sources
<zid>
okay I will write the zelda clone
<pog>
and the zelda clone
<zid>
I'll draw the graffics
<zid>
I'll use JFEG
<pog>
JFIF
<pog>
not to be confused with JIF
<mrvn>
please, aiff
bgs has quit [Remote host closed the connection]
<mrvn>
Amiga Interchange File Format
<zid>
it's the joint photography something group, with a 'f' sound
<zid>
JFEG
<pog>
experts
<zid>
yes!
<pog>
and mpeg is motion phicture experts group
<pog>
mpreg is something else entirely
<zid>
mpreg is what heat's hdd is full of
<pog>
hot
<zid>
mine is full of mpegs of pregnant men
<zid>
proper mpegs, not mp4
<pog>
mjpegs of mpregs
xenos1984 has joined #osdev
FreeFull has joined #osdev
dutch has joined #osdev
<heat>
kaichiuchi, my initramfs is very small because I statically link those utilities
<heat>
I stick like a whole shell (dash) and my bootstrap init in 1MB
<heat>
a shared lib version would be several times larger
<heat>
the whole glibc usr/lib (not stripped, debug info): 67M
avarai has joined #osdev
<heat>
musl's stripped libc.so is already 1MB in size itself
SGautam has joined #osdev
<zid>
I had a disgusting idea
<mrvn>
no, we are not doing that.
<zid>
You link everything shared, then dump every binary's imports to collect up what you need from the library overall; (strcmp, printf, etc). You then make a main.c with fake calls to all these functions, and re-link the library to it statically, then carve out main(), and rename it to .so
<zid>
you now have a 'static shared library'
<mrvn>
zid: Debian installer does that, just smarter
<mrvn>
Uses the libFOO_pic.a to create a reduces libFOO.so with only functions used in the installer.
<mrvn>
was an interesting challenge to implement.
<mrvn>
zid: even better would be to track which binary uses which functions (their closure) and sort the functions used by only one binary all into common page(s) for each binary. Then those used by two binaries, then three, ... so each binary only maps a minimum of pages.
<mrvn>
s/maps/loads/
puck has quit [Excess Flood]
puck has joined #osdev
epony has quit [Ping timeout: 268 seconds]
epony has joined #osdev
catern has quit [Ping timeout: 260 seconds]
Freja is now known as poggers
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
avarai has quit [Remote host closed the connection]
pie__ has joined #osdev
vancz_ has joined #osdev
<immibis_>
kaichiuchi: it's no different from statically linking any other runtime - which is quite normal for languages other than C. Actually the weird one is glibc for relying on dynamic loading for stuff!
<immibis_>
you use LDAP authentication? you'd think glibc would communicate to some ldap client process. Nope, it runs LDAP inside your process via dynamic loading
<mrvn>
immibis_: they are just ahead of the curve having plugins.
<mrvn>
what ldap would they run? We only run sssd
<immibis_>
i don't know my authentication systems, it's just an example
<immibis_>
the plugin system is called nsswitch
<mrvn>
normaly you run a client for an auth service
<immibis_>
glibc uses it not to authenticate but to look up UIDs and GIDs
<mrvn>
hostnames, service names, pam, ldap auth
<mrvn>
everything that's flexible
<immibis_>
and it's weird that glibc dynamic-loads that and does it from your process, instead of talking to some central thing
<mrvn>
they do that too with nscd
<immibis_>
PAM is another weirdo
<mrvn>
immibis_: a bunch of things glibc uses this for have no server. They just read files.
<immibis_>
glibc plugins bind a whole bunch of things to the C standard library that perhaps shouldn't be bound to glibc. You have a whole program written in FORTRAN? tough shit, load the C library so you can look up your username
<immibis_>
it's like a layering violation
poggers is now known as KaosHaeckse
<immibis_>
language runtimes should depend on core operating system features - not vice versa
<clever>
immibis_: they also cause compatability issues on nixos, when you can potentially have 5 different glibc versions, but only one version of the plugin
<immibis_>
of course the OS is itself written in a language that may need a runtime, but that should only be an implementation detail
KaosHaeckse is now known as theWeaver
<zid>
well, something broke somewhere
<zid>
ERROR:../target/i386/tcg/sysemu/excp_helper.c:517:raise_stage2: code should not be reached
<mrvn>
clever: that's the problem that breaks static linking libc.
<mrvn>
Why don't your libc versions have different paths for the plugins?
<clever>
mrvn: because there is no way to predict what version of glibc will be used, and prepare a plugin for each
<clever>
the config for glibc version, has no connection to the plugin listing
<mrvn>
In a sane world the path would include an ABI part, like a soversion.
<clever>
the nixos specific issue, is that every library gets installed to a path, where the version is hashed
<clever>
and every program, links against exactly one glibc, and that version is never changed out from under it
<sham1>
Same with Guix, except with the path being /gnu/store/...
<clever>
if you want program X to use a new glibc, you create a new version of X, at a different path
<clever>
yep
<mrvn>
That's what I assumed for your plugins too. But then things like sssd have to build a plugin for every installed glibc version and have a hook for compiling plugins when you build a new glibc.
<sham1>
Because of course GNU wants to make sure everyone knows
<clever>
the problem then, is that i might have not reinstalled X for a decade
<clever>
so its using a glibc from 10 years ago
<clever>
should the os above that, build avahi against 200 glibc versions??
<mrvn>
clever: what happens if a program links libfoo and libbar and they are compiled against different glibc versions?
<zid>
what the fuck is a stage 2 error raise in a tcg helper
<clever>
mrvn: at build time, you have 4 package definitions, how to build libc, libfoo, libbar, and X, foo/bar/X take libc as an input, like a global variable in a program
<clever>
mrvn: so everything in that build, is using the same libc
<mrvn>
but libfoo and libbar would be build last year
<mrvn>
or do you always build everything from scratch on every build?
<clever>
the path to libfoo, is based on a hash of both libc, and libfoo.tar.gz (the src)
<clever>
if there is already a libfoo.so, for the right set of inputs, it gets reused
<clever>
if there isnt, it gets built on demand
<mrvn>
ok. So when you build X it recomputes the hash for libfoo build against the current glibc and then picks that across the board
<mrvn>
same for libbar
<clever>
yep
<mrvn>
But X doesn't say it uses sssd so that doesn't get rebuild and then you have no ldap support.
<clever>
exactly
radens has joined #osdev
<mrvn>
you need that hook so sssd can say: I need to be build when glibc gets build.
<clever>
nixos works around that, with nscd, a daemon that primarily gives caching, but its loading the plugins out of process
<mrvn>
reverse dependency
<clever>
so the plugins run in a predictable env
<mrvn>
ja, except nscd sucks. never not had problems with it.
<clever>
mrvn: also, to be more exact, its not that a path is based on the hash of just glibc, and the source
<clever>
rather, the definition of how to build a package, is boiled down to just a set of env vars, and a shell script to run
<clever>
the paths to glibc and gcc are within those env vars
<clever>
and containers/namespacing is used to enforce you only use those paths
<clever>
the serialized form of that whole state, is then hashed, to compute the output path
<zid>
okay rebuilding qemu fixed it.. somehow
<clever>
so if you change any part (source, build directions, dependencies), of any dependency, it recursively changes the hashes of everything, and rebuilds whatever it cant find
<clever>
and both the old and new versions remain on disk
<mrvn>
luckily disk space is cheap
<clever>
there is also a mild form of dedup, nix can scan for identical files, and then hardlink them together
<clever>
all build products are immutable by design, so there is no risk of one change cascading into others
<heat>
zid, if you go to the trouble of creating smaller shared libs, you might as well just link statically since they stop being shared at all
<mrvn>
clever: I'm thinking the filesystem should store data blocks by hash. So identical files (even partial) would just have blocks with identical hash and use the same storage space.
<clever>
mrvn: zfs can do that, but it often has little benefit, and comes at a major performance cost
<heat>
I don't see the point of shared linking on objects that aren't shared nor dynamic
<clever>
and due to limitations in ZAP handling, it can also permanently increase disk usage, even if you try to undo it
<heat>
at that point, you're just paying the cost in performance
<clever>
heat: if your doing a good job at rebuilding everything from the same set of versions, then shared libraries will actually be shared
<clever>
but your free to keep 1 or 2 utils on something old, because the latest glibc breaks them
<heat>
I was talking about zid's idea of making shared objects with only the symbols you need
<heat>
but versioned shared libraries is also an issue
<zid>
heat: the point is the shared bits gets shared, but there's onlyt he funcs that get used
<clever>
related, i need to rebuild ghidra, i went too long without updating it, and the opengl libraries (also plugin like) ceased to be compatible
<mrvn>
not sure where the performance cost would come from. You already compute the hash for each block for safety reasons. There is a slight cost because files aren't a list of disk block numbers but hashes that you have to lookup in the B-tree. So potentially a few extra reads.
<clever>
so the old build just dies hard
<zid>
so if ./proga needs strcmp+strlen and ./progb needs strcmp+memcpy
<zid>
you end up with strcmp+strlen+memcpy
<zid>
and nothing else
<mrvn>
aeh, s/performance/space/
<heat>
hmm
<clever>
mrvn: for zfs, it has a dedup table, where its basically a hashmap from block hash to block location+refcnt
<heat>
yeah I misread your idea
<heat>
my bad
<clever>
so each time you create a block, you can find out of its already on disk, and reuse it
<clever>
and each time you free a block, you can update the refcnt, and maybe free it
<heat>
so what would happen when you run something new? re-link?
<zid>
80000000: fd000000 -------UW
<zid>
hmm that looks about right for a fb
<clever>
but since its a hashmap, the access pattern is random, and that harms performance
<mrvn>
clever: yeah. My way folds that into the general B-tree. You end up with more keys in the key. So in a (quite real) sense that costs you space.
<zid>
heat: This is for your ramfs right? should be.. static enough :P
<heat>
yes that's a qemu FB if i've ever seen one
<clever>
the tree based structure also lacks compacting, so it doesnt shrink when you delete entries
<mrvn>
in the tree I mean
<zid>
my gameboy isn't showing up, I should breakpoint sdl_get_framebuffer
<heat>
zid, I was thinking you were suggesting it for everything
<clever>
mrvn: and that hash tree is several gigs on a few of my machines
<zid>
well you were talking about your ramfs at the time I think
<heat>
for the initrd that would be /an/ idea but damn, no thanks, I would rather statically link
<zid>
initrd
<clever>
but its likely not saving several gigs
<mrvn>
clever: should be O(disk size)
<zid>
yea it's horrendous
<zid>
but it'd technically work
<heat>
I've actually thought about just bringing the whole libc.so into the initrd
<heat>
because it could be handy if you want more tools for recovery, debugging, etc in case you can't bootstrap
<clever>
dedup: DDT entries 222145, size 503B on disk, 162B in core
<mrvn>
clever: It's easy to compute the break even point. If you have 16 byte hash for 1MB blocks then you need 1 hit per 65536 blocks to break even.
<zid>
hmm how do I get debug symbols for user.bin..
<mrvn>
twice that to get a reasonable sparse hashtable.
<clever>
mrvn: this line tells me that there are 222,145 entries in the hashmap, they take up 503 bytes each on disk, for a total of 106mb, and they also take up 162 bytes in ram, 34mb, if the whole table doesnt fit in ram, performance gets even worse during a free/write
<clever>
the numbers arent that round, because of both compression, and leaf nodes that arent filled fully
<zid>
how was I getting to _start before I don't even remember
<mrvn>
clever: any raid? 503 byte seems a bit large
<clever>
no raid on this system
<clever>
dedup: DDT entries 2241821, size 3.28K on disk, 815B in core
<clever>
mrvn: but this system does have raid, and i'm pretty sure they are that huge, because of very space leaf nodes
<clever>
a lot of entries got deleted, and the tree structure didnt compact
<mrvn>
clever: You have the hash (16 byte?) and the disk location (disk ID + block number) and maybe some chaining. No way would I get that up to 503 byte.
<zid>
oh wait am I elf loading this
<clever>
mrvn: all block pointers in zfs are 128 bytes, that contains the hash, the disk location(s), the hash algo, and the compression algo
<clever>
but the leaf nodes in the tree then get compressed
<radens>
Does aarch64 have a way to swap a register with tpidr_el1 like x86 swapgs or riscv csrrw t6,mscratch,t6 ?
<mrvn>
another problem my idea avoids is tail compression. The blocks are just entries in the tree, doesn't matter if they are tail compressed blobs inside the tree or block pointers to full disk blocks.
<clever>
mrvn: but there is one trick up zfs's sleeve i didnt mention, its stored as 2 hashmaps, a unique hashmap, that is just hash -> blkptr, for anything with refcnt=1
<heat>
radens, why do you want that?
<clever>
mrvn: and then a duplicate hashmap, that is hash -> blkptr + refcnt
<mrvn>
radens: on ARM the thread registers have different access rights, kernel+user wirte, kernel write+user read and kernel only. So no need to swap.
<radens>
Heat : exception entry point bs
<zid>
okay framebuffer looks mapped, gameboy emu is running
<zid>
oh it's running
<heat>
radens, you do not need to swap anything there
<clever>
the values in both, are of fixed size, so each entry in the hashmap can be treated like a densely packed array
<heat>
tpidr_el1 has the EL1 tp, tpidr_el0 has the EL0 tp
<clever>
so its easier to insert new entries
<heat>
(and I assume it extends to EL2 and 3)
<clever>
if i inspect my nas (it has raid), i see DDT-sha256-zap-unique = 9904 and DDT-sha256-zap-duplicate = 9905 (those are inode numbers)
<zid>
I'm finally going to commit this shit to a branch, bord of losing it
<clever>
i can then dump those objects and see, that DDT-sha256-zap-unique is 1.33gig on disk, but after decompression its 5.47gig
<mrvn>
the hashes should be random. must be lots of zeros in the block pointers.
<clever>
its also taking forever to print any more data, let me restart on an nvme non-raid system
<clever>
on my desktop (dedup: DDT entries 222,145, size 503B on disk, 162B in core), the DDT-sha256-zap-unique table is 26mb on-disk, and 83mb after decompression
<bslsk05>
github.com: GitHub - zid/boros at gameboy
<clever>
mrvn: but another problem i can see here, is raid and parity, zfs on my nas is configured to operate with 4k sectors, but due to the raid with 2data + 1parity, it will ideally operate on 12k chunks, 8k of data, 4k of parity
<moon-child>
don't tell me what to do
<moon-child>
slut
heat has joined #osdev
<clever>
mrvn: and due to how zfs works, if a file is using 4k blocks, it wont benefit from a properk 8k+4k parity entry, and it degrades into more of a mirror, 4k+4k, using only 2 of the 3 disks
<zid>
faster you say
<mrvn>
clever: zfs doesn't have fixed stripes so it doesn't have to work in units of 8k+4k
<clever>
so the overhead basically doubles, from using too small of a block size
<zid>
heat's usually up for some mpreg, where's heat
<heat>
hell
<clever>
mrvn: yeah, it will dynamically change the stripe size, based on the recordsize
<heat>
oo
<zid>
heat: buid that for me
<heat>
build what father
<clever>
mrvn: but if the record is too small to even make a single 8k+4k stripe, the overhead grows massively
<heat>
GENTOO HARDCORE NO SECURITY NEEDED JUST O3 OFAST FUNSAFEMATH FUNROLLLLLLLLLLLLLLL
<zid>
does it... run, by any chance? you'll need to have a br0 on the default .sh
<moon-child>
doing stack protector yourself isn't hard iirc
<heat>
moon-child, depends
<heat>
some toolchains have the stack cookie on TLS
<zid>
why would I want a stack protector on a non-interactable userspace performance process
<heat>
that's another dependency
<moon-child>
oh yah sure
<heat>
zid, do you want the artifacts? I can give them to you
<zid>
the
<zid>
what
<heat>
(I don't have a br0 and can't bother setting it up)
<heat>
the build artifacts you bozo
<clever>
zid: ive seen an exploit before, mplayer could play chip-tunes from an 8bit console, by running a whole darn cpu and SID emulator, complete with rom banking support
<zid>
just ./qemu-system-x86_64 -cdrom boot/blah.iso it then
<zid>
inore the network stuff
<zid>
it'll boot without it
<heat>
ok pog
<clever>
zid: the code didnt enforce that the bank# was valid, and allowed the virtual cpu to index beyond the end of a buffer
<zid>
clever: the rom is hardcodd.
<clever>
zid: gnome would auto-play these audio files for you, just by selecting them
<zid>
and there's no other processes
<zid>
and there's no way to interact
<heat>
zid, I don't have a boot/blah.iso ?
<clever>
boom, you now have foreign code poking at a buffer overflow, with zero interaction
<zid>
cat qemu-e1000.sh
<heat>
I have a boot.bin
<heat>
ah
<clever>
if the rom is fixed, then that doesnt apply, yeah
<zid>
just get rid of the bridge, or brctl addbr br0
<heat>
i don't think it's working
<heat>
blank screen
<zid>
:(
<heat>
OH WAIT
<heat>
it doe
<heat>
s
<sham1>
zoop
<zid>
oh
<heat>
it needed q35
<zid>
yes it need
<zid>
else it boots via pci and doesn't find the gpu
<sortie>
How many occurrences of dQw4w9WgXcQ is there in your employer's codebase
<heat>
everywhere
<zid>
is that the rickroll youtube uri
<sortie>
zid, that's confidential
<zid>
see, it is
<zid>
Can't slip things past me
<zid>
They call me the funsucker 4000
<sortie>
Is it an OSHA violation to use it as the standard example video id with the inherent risk of rick rolling poor innocent employees
<heat>
how many libcs do your employers contribute to?
<heat>
in the case of LC_CORP I count around 4
<heat>
maybe 5, who knows
<sortie>
heat, I'd count but I should probably just go "that's confidential" because I bet that answer is unlookupable
<zid>
sortie: didn't youtube-dl get sued for that, beacuse their test rig fetched a katy perry video or whatever
<sortie>
heat: Haha in general at our size it's impossible to exhaustively know wtf we're doing
<heat>
i know, it's hilarious
<heat>
I find it very funny to see companies compete with themselves
<zid>
1917 s the best movie, the english soldier communicates with the french person by speaking english at them.
<heat>
intel works on like 4 different firmware solutions at the same time
<heat>
2 of them hate each other
<zid>
No mimes, no trying to remember french, just english
<sortie>
heat, yeah if you bet on all the technologies then you'll always win in some sense no matter how the market works out :)
<heat>
sortie, serious question: why does google really like organizing repos by language
<heat>
like c++/, java/, etc
<sortie>
It's a strength in Dart too, we're doing lots of interop with other languages and trying out platforms, so we'll be ready for the language ecosystem of the future :)
catern has joined #osdev
<heat>
I have seen this bleed into other projects from ex-googlers and omg I don't understand it
<mrvn>
heat: to head-hunt the right programmers
<heat>
what the hell is the advantage?
<zid>
heat: should I change boros from boros/ to boros/c/ and boros/asm
<zid>
is that how it works
<heat>
yeah
<heat>
although I think they like to do it at the root level
<sortie>
heat, oh man there's this whole big internal monorepo with some strict conventions that are carried over everywhere, the top level language dir is an antipattern there though and should've been put in another hierarchical product dir, but at the time it made sense to contain some hellish envs :)
<mrvn>
well, there goes youtube.
<zid>
that ist he root level
<heat>
google5000000000
<sortie>
Youtube is still serving dQw4w9WgXcQ to me
<zid>
or should I recommit every single repo to / and do c/boros and c/gameboy etc
<zid>
and to me, natch
<sortie>
heat, now but if you see third_party/ you know it's def G
<zid>
why would it stop unless sony and youtube fell out
<zid>
sortie: I have one of those, a googler put it there
<zid>
no joke
<heat>
sortie, or 10GB of prebuilts
<zid>
boros has 3rdparty/ from a disgusting googler, maybe I should remove it
<mrvn>
zid: it recovered, but it got stuck for a bit
<zid>
I don't even know what's in it
<sortie>
Yeah third_party/ is a company wide convention to keep the licensing origin clear and everyone are following it
<heat>
you know, I don't dislike third_party
<sortie>
Generally good to know what's first / third party
<mrvn>
aka /nih/#
<heat>
that's not nih
<heat>
nih is first party
<sortie>
Curiously enough sometimes first party stuff goes into third_party such as when open source rolls back internal
<sortie>
heat, I'd like to formally apologize for all the prebuilts
<sortie>
It made sense at the time
<sortie>
heat, here's 120 GB more
<sortie>
Hope it helps
<heat>
it does make sense but it's a PITA
<sortie>
You can always pass --no_prebuilts
<heat>
yo google serving uncompressed 4K textures in prebuilts now?
<sortie>
The underscore makes you die a little inside and the sacrifice recovers a gigabyte
<heat>
--git_filter=!prebuilts
<sortie>
Don't forget to put depot_tools in your PATH
<heat>
hahahahaha
<sortie>
And opt out of analytics
<heat>
and use repo
<heat>
git clone is for amateurs
* sortie
is a survivor of repo sync
<sortie>
Source codes are supposed to be a lot of effort, time, and disk space to get otherwise they wouldn't be valuable
* mrvn
goes and starts Survivor: #osdev edition
<sortie>
"I just want to check out ART and build it" is even a difficult question internally even when ART needs it solved
<heat>
how do you figure out what slightly different modification of chromium's //build you have?
<zid>
Hmm, I'm further away from ny than cali is, just barely
<zid>
atlantic is fuggin big
<sham1>
Well it is an ocean after all
<heat>
everybody gangsta until linux 2.7 comes out
<zid>
that isn't what makes the atlantic big
<zid>
just has to be salt water
<kaichiuchi>
god
<kaichiuchi>
i'm getting nostalgic
<kaichiuchi>
I remember when it was almost impractical to download ubuntu
<kaichiuchi>
so I had to order CDs
<zid>
heat's never seen seen a floppy disk
<heat>
i have
<zid>
heat when were you born
<heat>
i used windows 95
<heat>
2002
<zid>
WHAT
<zid>
Is that allowed?
<heat>
i mean, i guess
<heat>
this is an air bud moment where the rules don't explicitly disallow me so I'm free to stay
<zid>
I meant being born in 2002
<heat>
i mean yeah
<zid>
don't you like, barely not wear diapers
<heat>
when else would I be born?
<zid>
2002 was a couple of years after the matrix came out, so was what, 5 years ago?
<heat>
being born in not-2002 is LITERALLY a crime
<kaichiuchi>
i remember when IRC was in its prime
<kaichiuchi>
it was already on the way out, and then Discord came and killed it
<zid>
*looks around*
<zid>
spooky ghosts!
<heat>
irc was already dead in 2015
<zid>
ye
<heat>
who tf uses irc?
<heat>
discord just killed the other VOIP programs (mumble, teamspeak, etc)
<kaichiuchi>
i mean yeah
<mjg>
IRCMOTHERFCUKER
<kaichiuchi>
I'm just saying, I've been using IRC since 2006
<mjg>
newb
<mjg>
2001 over here
<zid>
yea 2001 ish
<kaichiuchi>
old
<kaichiuchi>
i was like... 13-14
<mjg>
i rmeember entering a channel which had people ~20 years old
<mjg>
discussing some politics crap
<kaichiuchi>
i first started using IRC because I wanted to use homebrew on my PSP and I had no idea how to do it
<zid>
christ
<mjg>
i said some stuff, they asked how old i am and started laughing
<mjg>
:d
<heat>
mjg, were they speaking arabic? in 2001?
<zid>
I remember the PSP coming out when I was a fully formed adult
<mjg>
heat: yidish
<heat>
you might've joined another kind of channel
<clever>
heat: i still use teamspeak, because i dont want a simple voip program to use a gig of ram on electron
epony has quit [Ping timeout: 268 seconds]
<zid>
The only channel heat knows is bearcave
<heat>
ok, consider this: teamspeak sucks compared to discord
<zid>
ts sucks compared to everything
<clever>
yes, teamspeak does also randomly segfault without warning
<zid>
ventrillo, mumble, discord, skype
<zid>
you have to pay for them to host you a server, and the software blows
<heat>
discord beat the competition because discord is better than the competition
<clever>
zid: i'm hosting my own ts server without paying anything
<heat>
you can also have your own discord server without paying
<heat>
and hosting
<clever>
the free license has a limit of 32 users online at once
<zid>
did you steal the server software? That didn't used to be poss- ah
<clever>
heat: id argue that discord could just close up shop and kill the server without any warning, but the license check in the ts server gives it basically the same flaw
<zid>
only good thing about discord is bots that let you react to messages to do polls
<clever>
if i leave the ts server running for several months in a row, the license check expires, and nobody can connect
<heat>
IRC people don't understand products and usability
<clever>
until i restart the server, and it renews itself
<heat>
people actually want things like rich text and images and gifs and screensharing
<clever>
and ts could just close up shop and kill that
<kaichiuchi>
there is only one reason I still use IRC
<kaichiuchi>
and one reason only
<clever>
about the only real difference i see between ts and discord, for how i use it
<kaichiuchi>
the *really really smart people* who I ask questions to, are all on IRC
<heat>
yeah same
<clever>
with teamspeak, i can stay in a channel 24/7, and others can come in and chat if i'm on
<kaichiuchi>
and I don't think that's ever going to change
<heat>
you're also more likely to find less mature people on discord
<clever>
but with discord, you cant do that in a PM, they DC you automatically if you afk too long
<clever>
so you first have to text somebody, "are you online", or just blind call them
<heat>
clever, not true
<clever>
heat: which part?
<kaichiuchi>
overall, I like Discord
<heat>
they only DC you in a 1-on-1 call
<kaichiuchi>
even though the client is garbage
<clever>
yeah
<zid>
you can idle in a channel in discord
<heat>
you can stay in a voice channel for as long as you want
<zid>
it kicks you out of calls, not channels
<zid>
my main issue with discord is just how ephemeral everything is
<clever>
but now there is a second feature, that only teamspeak has, "mic clicks"
<zid>
give me client side logs *please*
<zid>
if I ever close a conversation it's *gone*
<clever>
every time voice activation procs, teamspeak plays a little click noise
<heat>
irc is worse
<clever>
so if i forget to mute, and i start mic spamming
<clever>
or if i'm typing too loudly
<heat>
you can't even have logs if you're not online
<zid>
it's against discord tos to log via bot
<clever>
i can hear that i'm mic spamming
<clever>
discord has no way to do that, and tends to auto-gain too much
<zid>
ptt is mandatory
<zid>
in my world
<clever>
if i dont speak for 5 minutes, it cranks the gain up until you can hear every little noise i make
<clever>
zid: i have a wireless headset and am often not in reach of a PTT key
<zid>
also you're wrong
<zid>
(again)
<clever>
the mic-clicks feature in teamspeak, tells me when i'm transmitting, and i can just whack mic-mute on the headset if i dont want to
<clever>
PTT also leads to people mic-spamming every time they ctrl+c or YELL
<zid>
ptt does not lead to mic spamming
[itchyjunk] has joined #osdev
<zid>
I've played several thousand hours of world of warcraft with strictly enforced ptt
<clever>
zid: it does when somebody uses ctrl for the PTT key, and they start going on a ctrl+c ctrl+v storm
<zid>
Nobody sane would do that, it's a key you need to use to play
<mjg>
> 00:19 < zid> I've played several thousand hours of world of warcraft
<mjg>
????
* mjg
ganks zid
<zid>
mjg: I've done world top 100 damage parses, get on my level
<pog>
push to meow
<clever>
WoW is a very different situation, where you can setup your ingame hotkeys to not conflict with the PTT hotkey
<clever>
vs trying to use PTT while also using the pc as a pc
<zid>
I am aware that some people cannot be trusted and without a way to gkick them for bad ettiquette they will continue doing it
<zid>
but PTT does not lead to *more* mic spam
<zid>
it leads to significantly less
<clever>
with how i use mic-clicks in teamspeak, i know if i'm causing mic spam, and can mute my mic or stop making that noise
<zid>
It may cause some individuals to do it more, but it in itself does not overall cause more
<zid>
it causes most people do it 0
<clever>
others have said the mic clicks are super anoying
<clever>
but ive gotten so used to them, that i sometimes think there is something wrong, if i dont hear them, while talking to somebody in person, lol
<clever>
in the past, ive also had issues with discord, when you leave a call, it doesnt stop the mic capture stream
<clever>
and if your mic capture is running for 24+ hours, it just dies silently
<clever>
so next time you do join a call, nada
<zid>
sounds like a driver bug
<heat>
i don't think i've hit that yet
<clever>
it only happened in discord, teamspeak can be doing mic capture for months on end without issues
<clever>
but it just randomly went away at some point
<zid>
heat what's your discord
<heat>
the only shit that really upsets me is discord's shitty support
<kaichiuchi>
i've never had that happen
<kaichiuchi>
i'm still stunned that zid uses discord
<zid>
asl? zid#8479
<zid>
kaichiuchi: can't not
<heat>
heatd#9849
<zid>
as much as I hate that basically every online community has switched to it and sealed off all their (what would be forums) from web searches
<heat>
the d stands for dong
<zid>
being able to share memes and voice call people is useful
<kaichiuchi>
i will add both of you
<zid>
is that a threat
<clever>
as much as i want to support open source, matrix just isnt able to compete with discord currently
<clever>
and i dont have time to invest into fixing that myself
<zid>
kaichiuchi: I don't t hink it's legal for me to add someone your age
<kaichiuchi>
heat: please tell me that's not you
<kaichiuchi>
zid: i'm 28
<kaichiuchi>
.
<heat>
that is not me
<heat>
or is it
<heat>
i fucking wish i was joji
<zid>
heat's avatar looks exactly like what I thought it'd be
<kaichiuchi>
i have just killed zid
<kaichiuchi>
i sent him a pepe
<zid>
I was trying to find the block button after you did that
<zid>
but noticed we atually both share a discord server
<kaichiuchi>
yes
<kaichiuchi>
i was there the whole time
<zid>
you're attentive as hell if you didn't realize I used discord, then
<kaichiuchi>
wtf I don't go looking for you
<zid>
I have the latest message in like half the channels in it :P
<clever>
now i'm curious as to what server that is
<zid>
playstation dev
<clever>
ive only got a server in common with heat
<clever>
ah
<heat>
we should create another osdev discord server
<clever>
was thinking the same, heh
<zid>
you do it heat
<zid>
name it.. porto geese and friends or something
<kaichiuchi>
would be nice
<heat>
geist should do it
<kaichiuchi>
kinda surprised there isn't a discord bridge here
<zid>
no if geist does it it will be super serious like we are here
<heat>
oh no, not super serious like we are here
<heat>
𓂺
<zid>
I could just start a voice call between us four
<zid>
it creates an ad-hoc server
<zid>
who that
<pog>
woof
<heat>
i would rather blow the fuck up than listen to your voices
<zid>
I did wonder
<heat>
you are not real people and nothing will convince me otherwise
<mrvn>
just you wait for my syslogd to get a twitter account
<zid>
I'd have hung up if you answered I just wanted to see if you would :P
<zid>
I don't speak geese
<heat>
you know, i'd take a geist call in a heartbeat
<heat>
but yours? you'd need to tell me what kind of international terrorism scheme you're getting me into beforehand
<pog>
what about me
<zid>
why, you're not selective
<heat>
geist voted #1 least likely to be a terrorist in #osdev
<zid>
disagree, I vote gog
<zid>
icelandics are too benign, I don't trust americans
<zid>
icelands would declare war on you
<pog>
i
<pog>
m ameriocan
<zid>
americans will install a dictator without telling you they're involved
<zid>
you're iceland now
<heat>
iceland is full of radical extremists
<pog>
yes
<zid>
radical extremeist beliefs like "I like fish"
<zid>
and "what is tree?"
<pog>
i know what tree is
<zid>
in the same way I know what a kangaroo is
<pog>
it's a directed graph with no cycles
<zid>
and heat knows what western europe is like
<zid>
We've all seen it on TV
<geist>
Come on folks
FreeFull has quit [Quit: Reconnecting]
<geist>
Let's try to stay kinda on topic
FreeFull has joined #osdev
<geist>
Or at least stop joking about terrorism or whatnit
<geist>
But sure if folks wanna discord chat or whatnot I'm totally open to it
<mjg>
so RUST
<kaichiuchi>
an osdev discord would make things a lot easier
<mjg>
not liking the syntax, but petty stuff aside the lang is growing on me
<j`ey>
kaichiuchi: there is one
<geist>
There's one
<zid>
There is one indeed
<zid>
It certainly exists.
<kaichiuchi>
then I don't understand
<zid>
What else can I say about it
<geist>
It's just not associated with us necessarily
<kaichiuchi>
people here are talking like it doesn't exist
<kaichiuchi>
ah
<zid>
Or good taste.
<heat>
can you even bridge discord and IRC?
<pog>
you can
<mjg>
where is that discord
<geist>
I don't particularly like that particular one but I don't judge if folks are okay with it
<mjg>
will join as heat and shit on sortix
<pog>
i'm in a channel that has a discord bridge
<zid>
finding out an osdev discord exists should trigger the same emotional response as finding out there's a sequel to your favourite movie coming out with a B-list comedian taking the lead role.
<geist>
Kinda yeah
<sortie>
mjg, your waste will be processed with immaculate reliability in a self-hosting manner
<zid>
Either you have hope "maybe it'll be good regardles??" or you face reality
<bslsk05>
redirect -> discord.com: Operating System Development
<geist>
Computer topic rule 34 for discord. Of course there's a server for it
<zid>
am I still banned do you think
<mjg>
1334 online
<kaichiuchi>
you could just make the discord server say "osdev.org" and say "We have a Discord server now!"
<sortie>
I've never seen someone join discord from their OS
<mjg>
6324 members
<kaichiuchi>
and the other one will drop
<mjg>
i don't know if that means the community is great or bad
<zid>
mjg: It lacks heat (I think) so it's clearly got issues
<mjg>
are there subchannels over there or something
<kaichiuchi>
i don't trust programming anything on discord
* mjg
never used discord
<geist>
I bumped heads with the mgmt and have no interest in dealing with internet drama so I left
<zid>
yea each discord is like an entire irc server
<geist>
As did zid
<geist>
There's folks there that know a thing or two though
<zid>
I got banned within about 8 minutes for telling "some guy" that I disagree with tellin people to write their own bootloaders, he said he was the admin and I said "and?"