<klange>
Managed to speed up my terminal a bit, and the glyph cache has made the truetype rendering just as fast as the bitmap font on average, so those two combined make things pretty fast - about on par with halfassed benchmarks in iTerm, 2~3x slower than a more optimized VTE terminal on Linux...
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<zid>
cool beans
<klange>
This has made the QEMU TCG experience much better, as well.
smach has quit [Ping timeout: 252 seconds]
<heat>
my vt code isn't great
<heat>
it's super unusable under KASAN
<heat>
under KVM, it's just "slow"
<zid>
we've always said that about you heat, merely slow
<heat>
meanie
<zid>
You started it by not buying me the pony
<klange>
I have this complicated triple buffering cell state thing going on, a back buffer with the "real" VT contents, a middle buffer where cursor + selection are applied, and a shadow buffer that represents what the drawn output looks like.
<klange>
Visual operations usually modify both the back buffer and the middle bufefr, and then a deferred render step draws things that differ from the shadow buffer and updates it accordingly.
<klange>
But the middle buffer is also helpful for scrollback
<heat>
i currently just have a framebuffer and a console 2-d array of cells
<heat>
each cell has {dirty, fg color, bg color, char}
<heat>
i try to be as smart as possible but I think I could go smarter
<heat>
it's super slow even compared to other software vt's
matt__ has quit [Ping timeout: 255 seconds]
<klange>
I really need to figure out what is taking so long in driver module installation _sometimes_ (pooossibly the e1000 driver having a spin-yield until it is running on core 0...) but
<bslsk05>
'ToaruOS improved terminal speed' by K Lange (00:00:56)
<klange>
Turns out OBS caused the speed to drop enough while recording that the fullscreen cat of bim.c took half a second, I swear it's normally about half that :)
<zid>
quick, dupe all the frames
heat has quit [Ping timeout: 255 seconds]
<klange>
But yeah, rather happy with the state of my terminal. It is has TrueType fonts, text selection, pretty solid escape sequence support, rudimentary Unicode (frankly, not far off from what many "real" terminals manage; it's at least good enough for Japanese, which is important to me), and now it's reasonably speedy.
<klange>
s/is has/has/
<zid>
when are we doing the 0.00 0.33 and 0.66 renders
<klange>
When you asked about it the first time, like within five minutes.
<zid>
oh you didn't list it as a feature
<klange>
But the terminal won't do that, it only does aligned rendering.
<klange>
The terminal has no use for fun kerning.
<zid>
ah so it's still outstanding and I can still ask when we're getting it then, good
<zid>
I suppose not, it's presumably mono :(
<klange>
The one thing I still want for text rendering that will affect the terminal is hinting, and I would do old school full hinting for it to get an exact match to what I see out of FreeType.
<klange>
But alas, I lack the motivation to really sit down and complete my hinting interpreter... I have basic debug facilities for looking at the instructions, but haven't gotten around to some of the vector math.
<klange>
I have too many open things to work on.
[itchyjunk] has joined #osdev
<klange>
I should work on this XHCI/USB stack... I should finish the libm for aarch64... I should build a widget toolkit... Kuroko's gc needs improvements for mulithreading... Why have I not merged the Help Browser's reflowing text renderer with the markup_text library's better interfaces and glyph cache... I should package dash... I should redo the regex engine for `grep` to support POSIX BREs...
<klange>
I have a rework of the Yutani bindings for Kuroko I need to finish, I should build a proper event queue for that, I should actually try to write some more apps or port the old Python ones...
<klange>
Why does my TCP stack still suck, when am I going to get listening sockets, why have I not finished the dependencies for porting my little HTTP/CGI server...
<klange>
I have several pages in my actual pen-and-paper notebook on reimplementing my old package file format, I have a bunch of packages I should automate builds for....
heat has joined #osdev
<klange>
heat drops off just in time to miss my rant, and comes back in just after it's over
<heat>
my route to the interwebz fucked off just in time
<zid>
he did it on purpose
<klange>
Anyway, tldr, I have so many things that I suffer from choice paralysis over what to work on.
<geist>
kazinsal: oh fun! i thought it'd be fun to implement a 286 based protected mode system
<geist>
16 bit segments out of a 16MB space
epony has quit [Ping timeout: 252 seconds]
outfox has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
ZipCPU has quit [Read error: Connection reset by peer]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #osdev
epony has joined #osdev
<kazinsal>
yeah, I kind of figured that specs-wise an XT isn't too dissimilar from a PDP-11/45 without the MMU option so it should be able to comfortably run a relatively early unix in its base configuration
<kazinsal>
V4 was the first one that was written in C and the original troff files for the manual still exist and are freely available so that's a solid reference point for an implementation from the user-facing perspective
<klys_>
so eh
<kazinsal>
plus, y'know, statistically the most common hobby osdev project is to reimplement modern unix on modern systems, so I figured that since I've never done that before and don't intend to do that I'd do vintage unix on a vintage system :)
<klys_>
kazinsal, do you have phys memory management implemented?
<kazinsal>
not yet, currently figuring that all out on paper before I go in and start implementing
<kazinsal>
also had to fight with open watcom for a bit to get it to properly link modules in reliably useful ways
<klys_>
ah yes, it can be pretty tough translating all that into C code
<klys_>
I may have had a malfunction in my theory before I started implementing it too:
smeso has quit [Quit: smeso]
<klys_>
it's kind of like "the buddy system" except each "layer" has 16 "buddies"
<klys_>
and the 16 pointer structure, get this, had last and next pointers
<klys_>
so I'm not sure what I'm using those for anymore
<kazinsal>
my current "how the hell am I going to do this" that I'm working on is a memory defragmentation algorithm
<klys_>
one thing I do like about my memory manager is how it allocates individual bytes out of a page using a bitmap of 456 bytes at the end
<klys_>
so you're focussing on one potential problem that it will most assuredly encounter, fragmentation, and leaving that up to the operating system
<kazinsal>
kinda have to, no MMU
<kazinsal>
gotta do it all on the fly by pausing processes in flight and shuffling them around
<klys_>
I don't think I will leave that up to the os + libs, instead I'll make it part of the api that the program can be signalled with a range of pointers it ought to relocate
<klys_>
...which should work great if every program works with data structures and acts like a text editor would
smeso has joined #osdev
vdamewood has joined #osdev
sonny has joined #osdev
sonny has quit [Quit: Client closed]
sonny has joined #osdev
sonny has quit [Quit: Client closed]
opal has quit [Ping timeout: 258 seconds]
opal has joined #osdev
\Test_User has quit [Quit: e]
\Test_User has joined #osdev
skipwich has quit [Ping timeout: 268 seconds]
\Test_User has quit [Quit: \Test_User]
skipwich has joined #osdev
Piraty has quit [Quit: -]
Piraty has joined #osdev
\Test_User has joined #osdev
nyah has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
arch_angel has joined #osdev
vdamewood has joined #osdev
knusbaum has quit [Ping timeout: 252 seconds]
knusbaum has joined #osdev
GeDaMo has joined #osdev
vdamewood has quit [Quit: Life beckons]
smach has joined #osdev
dh` has quit [Ping timeout: 252 seconds]
epony has quit [Remote host closed the connection]
gog` has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.0]
heat has joined #osdev
SpikeHeron has joined #osdev
gog has quit [Ping timeout: 252 seconds]
gog has joined #osdev
gog has quit [Read error: Connection reset by peer]
ZipCPU has joined #osdev
carbonfiber has joined #osdev
terminalpusher has joined #osdev
gog` has quit [Quit: byee]
frkazoid333 has joined #osdev
kori has joined #osdev
frkazoid333 has quit [Ping timeout: 244 seconds]
scoobydoo_ has joined #osdev
scoobydoo has quit [Ping timeout: 260 seconds]
scoobydoo_ is now known as scoobydoo
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<sbalmos>
heat: I know. I run it on my Asus Pentium-something Chromebook. It's a bit of a slug.
<heat>
on some chromebooks you can even flash your own firmware, although I think you can't do that on the ARM ones
<sbalmos>
heat: tried running VSCode inside it for giggles. That was... interesting
<heat>
what gen?
<sbalmos>
oh hell lemme go get it from the other room
<heat>
remotely new intel gens are usually all pretty fast, even ULP i3's
<heat>
maybe pentium CPUs are an exception
<sbalmos>
igg, nevermind, it's an Acer CP311-2H series. Base chip is a Intel Celer(on, -y Stalk). It just reported as a Pentium.
<heat>
yeah that's old
<sbalmos>
oh well, my Samsung laptop is more lightweight than this Chromebook, and lasts almost as long, if I really wanted to do dev. :D
<heat>
2017-old, but old nonetheless
<heat>
TDP of 6W :D
<heat>
yeah, I wanted a new laptop but I don't know if I want to spend much on it
<heat>
I was also thinking about a desktop...
<sbalmos>
heat: this one was $1k at Costco
<heat>
getting a cheap chromebook and ssh'ing onto the new desktop @ home seems like an interesting idea
<heat>
although getting a relatively capable arm64 cpu sounds sweeeeet
<heat>
sbalmos, which one? I hope the samsung one?
<sbalmos>
heat: yup
<heat>
problem with mid-range laptops these days is that OEMs just sticked SSDs into them and took out the dGPU, so they're useless for gaming
<sbalmos>
heat: mind you I do that all the time also - remote to the desktop from the other side of the house on my Chromebook.
<heat>
you either get a gaming laptop (big, bulky, usually expensive), or a iGPU-only laptop (and /usually/ discard gaming altogether)
<heat>
kinda grinds my gears
<clever>
heat: ive been considering getting a dedicated desktop for VR stuff (dual-boot windows/linux), and using steam in-home streaming to then let me play games via it, on another less capable machine
<clever>
then i can leave that desktop in VR friendly room, but still use it from a desk elsewhere
<heat>
yeah
<sbalmos>
still wish remoting in Linux wasn't such a cluster****. I'm way too spoiled from working here at the desktop console in Windows, then just randomly grabbing that console session - logged in or not - via RDP on the Chromebook elsewhere, and then sitting back down later and vice versa
<heat>
or maybe get an nvidia shield :D
pdough has joined #osdev
<pdough>
yo wanna see my OS written in Typescript
<heat>
no
<heat>
you started off really well but that typescript thing really ruined it for you
jafarlihi has quit [Ping timeout: 260 seconds]
<heat>
try again next week
<pdough>
whats the prob with TS, are you against trans people?
<heat>
you're the one that abbreviated it
<heat>
i said typescript
<zid>
swing and a miss, that joke
carbonfiber has quit [Quit: Connection closed for inactivity]
<sbalmos>
must've pissed off others more quickly in a more important channel
<dzwdz>
Killed == K-lined, right?
<mjg>
yes
<mjg>
well maybe
<zid>
no
<zid>
killed is force-disconnected
<sbalmos>
just killed
<mjg>
now that you metnion it, no, k-line is typically denoted
<zid>
they may also have been g-lined or k-lined
<dzwdz>
sbalmos: ah, irl?
<sbalmos>
keep dreaming
kof123 has quit [Ping timeout: 268 seconds]
<heat>
is g-lined when you find the g-spot?
<zid>
The nick is registered and we're +r so they can also just de-register the nick
terminalpusher has quit [Remote host closed the connection]
<dzwdz>
what did they do in #archlinux? was it at least creative?
<dzwdz>
this was just bad
<heat>
it was exactly this
<sbalmos>
<Maximus> Are you not entertained?!?!?
<mjg>
not even the f-word?
<mjg>
back in my day we had better trolls
<GeDaMo>
Eternal September applies to trolls too :P
<mjg>
LOL o \o \o/ \o o <o <o> o> o DANCE
<mjg>
LOL / \ >\ /< >\ /< >\ /< >\ /< DANCE
<mjg>
DANCE .|. |. | / X \ | <| <|> LOL
<clever>
mjg: i remember some trolls going into a religious channel, asking the bot to quote the bible, then watching as the bot gets kicked for cursing, lol
<dzwdz>
i mean before they expressed their dislikes
<CompanionCube>
troll is not doing allah is doing
<mjg>
clever: solid
<heat>
dzwdz, not even a setup
<dzwdz>
...
<heat>
he tried here
<heat>
was a shitty try anyway
<heat>
who tf wants to see a os written in typescript?
<sbalmos>
kids
<sbalmos>
why do you think 3/4 of new-age backends nowadays are in Node?
<CompanionCube>
heat: could've been worse, could've fucked up the ascii art by making it too long so it gets kiooed in the middle
<sbalmos>
it's damn near the worst language to write a backend process in. but it's what the kids know (from the frontend)
<mjg>
i'm sure they tested :>
<GeDaMo>
It didn't work for me :P
<dzwdz>
yeah, #archlinux was their testing bed
<mjg>
get a btter terminal :>
<sbalmos>
heat: export function kmain(boot_args: IBootArgs): void { console.log(`Jovial greetings to you, from TypeScriptOS ${build.version}`); }
<CompanionCube>
didn't someone make 'nodeos' but it's actually just linux
<mjg>
? :)
<sbalmos>
CompanionCube: Just replace /sbin/init with a call to node's repl. BOOM, PROFIT!
<heat>
oh oh oh, so like freebsd? which is actually just linux
<sbalmos>
heat: dem's be fightin' werds
<dzwdz>
it even calls itself lightweight, lol
<mjg>
heat: i ran into a troll once which claimed that freebsd stole locks from linux
<mjg>
heat: i mean the eprson was serious afaics
<heat>
freebsd stole the API from linux
<mjg>
which is quite funny given the locking model was 100% stolen from solaris (code most notdefinily was not)
<heat>
why doesn't RMS sue the BSD demon????????'??
<heat>
>concurrency stolen from solaris
<heat>
>scalable
<sbalmos>
because Beastie was cuter than Tux back in the day
<mjg>
(:
<heat>
oh fuck oh shit i'm almost there
* Ermine
googled js os
<mjg>
freebsd took the idea of using locks from linux
<mjg>
that much i know
<sbalmos>
heat: plus no judge would let a barefooted man like RMS into their court
<CompanionCube>
sbalmos: 'barebones custom Linux kernel with an initramfs that boots to a Node.js REPL' from the nodeis repo
<bslsk05>
NodeOS/NodeOS - Lightweight operating system using Node.js as userspace (622 forks/6691 stargazers/MIT)
<mjg>
:[
<mjg>
thanks i got cancer
<Ermine>
"It was also presented as the degree thesis of Jesús Leganes Combarro with a qualification of 10/10 with distinction."
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<heat>
I want freebsd with a linux kernel as an initrd, and that linux kernel would have windows as an initrd
<heat>
have them load each other, but slowly, so you can slowly realise !windows is shit and bad
<Ermine>
?
<heat>
!
<GeDaMo>
‽
<heat>
☭
<sbalmos>
yeah, well I wrote a thesis too, on a C#/CLR-based OS with a tag-based object FS and blah blah blah. That earned me Honors Distinction too... in 2006. Just words.
<mjg>
lol @ people getting cs degrees, for real
<mjg>
i got thesis code submitted along with CVs at times and good grief
<heat>
sbalmos, did it have COM objects?
<sbalmos>
heat: oh hell no
<heat>
downvote
<heat>
that is not very cash money of you
<mjg>
ye i would fail you sbalmos
<sbalmos>
heat: academics. making money is irrelevant.
<mjg>
actually teaching is not relevant either
<sbalmos>
mjg: but... but... .Net Remoting! It's like COM, only Moar Gooder
<heat>
academics is 80% stealing paychecks
<mjg>
poor saps "learn" to use gprof
<zid>
academics is looking at grant requests I thought
<mjg>
here is a joke for you
<heat>
sbalmos, either everything is a file, or COM; anything else is an instant fail
<mjg>
- so why have you decided to pursue a phd in our department?
<mjg>
- common dad
<mjg>
from an interview process
<CompanionCube>
heat: COM isn't cross-platform, let's use XPCOM instead!
<zid>
I don't understand any of it
<sbalmos>
CompanionCube: DICOM
matt__ has joined #osdev
<CompanionCube>
isn't that a medical thing
<GeDaMo>
CORBA!
<sbalmos>
in one sense, yes
<sbalmos>
you know what, f*** it, an OS isn't modern nowadays unless it can be accessed through GraphQL and protobufs!
<heat>
people that exclusively use COM really miss out on the fun of everything is a file and sprintf
<heat>
so, every COM object is a file?
<zid>
every com entry is a registry tree
<zid>
even better
<sbalmos>
hive
<sbalmos>
it's a registry hive. you get stung every time you open it
frkzoid has quit [Ping timeout: 255 seconds]
<heat>
COM/DOORS, or as I've recently taken to call it, COM plus DOORS
<bslsk05>
man7.org: posix_spawn(3) - Linux manual page
<zid>
ah cool
<geist>
there's all this 'file action' stuff tht lets you move fds around before strting to new process
<geist>
yah i'm fairly certain lots of modernish posixy stuff like ninja totally take advantage of the relative speed of this
<geist>
if present, of course
gildasio has joined #osdev
<clever>
one problem i have seen with the normal fork+exec loop, is leaking FD's
<clever>
some programs just use a for loop to close fd's 3-256 for example
<clever>
but thats costly, and can still leak
<clever>
according to the man-page, only 3 actions exist, addopen, addclose, and adddup2
<geist>
yah, linux has CLOEXEC, but i dont know if that ever became standard in posix
<clever>
so you would still need to generate a ton of addclose entries, but i assume thats now all in userland, and a single syscall
<clever>
or yeah, demand that every library you use, do CLOEXEC
<clever>
so they dont leak
<geist>
if you're careful about cloexecing everything then you can do that yeah
<clever>
exactly
<geist>
i'd assume something like ninja does that
<clever>
but this new call, is also better, in that you can give it an array of FD's to close
<clever>
and it will close all of them in one syscall
<clever>
its still costly, in that the kernel now has to iterate over the array, and loopup each fd you list
<clever>
but its not doing a full user->kernel->user change for each one
<geist>
yah now the question is does modern linux implement this in a syscall or still emulate it in glibc on top of clone/fork/exec, like the man page says
<clever>
i have never seen it in strace
<clever>
$ strace -e posix_spawn ls
<clever>
strace: invalid system call 'posix_spawn'
<clever>
strace also doesnt consider it a valid syscall
<clever>
arch/x86/entry/syscalls/syscall_64.tbl
<clever>
geist: and its not in this table, as-of 5.10
* geist
nods
<geist>
the man page says it uses clone + exec
<geist>
i dnt know te precise semantics of that clone call, but i guess that ends up being faster than fork or vfork
<heat>
i think you can theoretically use vfork but that's riskier
<clever>
ive heard that after CoW fork got added, vfork was just an alias to fork
<heat>
lie
<geist>
the man page says it used to use vfork but moved to clone, so presumably there's a reason
<heat>
dirty little lie
<geist>
anyway, there you go. use that api when you wanna just start a thing
epony has joined #osdev
<geist>
and it's posix, so i'm guessing the BSDs also do it
<heat>
geist, they use clone(CLONE_VM|CLONE_VFORK). it's exactly like VFORK but they pass a stack to it
<heat>
with vfork you need to hope it doesn't touch the parent's stack ever
<heat>
well, that it doesn't mess with it
<heat>
clone lets you set the stack so if you check the musl code they reserve a chunk of it for the child
<heat>
it's safer
<heat>
since CLONE_VFORK suspends the parent, you know the parent will not use that bit of the stack either
<geist>
the freebsdimplementation is of course totally different
<geist>
uses rfork() and friends, which i've never heard of
<heat>
oh, rfork is clone but BSD
<geist>
ah got it
<geist>
so looks like similar stuff there
<geist>
actually honestly i'm a little dissapoint: i thought posix_spawn would be implemented directly in the kernel to skip any sort of foo + exec step
<geist>
it looks easier to use and a win in general, but i'm not entirely sure how it's faster, unless the whole trick is the clone/rfork stuff
<heat>
yes, that's the trick
<heat>
the trick is the exact same thing as vfork
<geist>
and i guess it hides the sausage factory a bit since on linux it uses clone and on bSD it uses rfork, tc
<geist>
ie, non standard apis (i think)
<heat>
yes
<geist>
and presumably on things like WSL1 or fuchsia or whatnot, you could implement it directly
<geist>
might be interesting to see what mac does here
<heat>
rfork() as well?
<CompanionCube>
well, can't really implement it directly on WSL1 without patching libc
<geist>
i dont see a man page for rfork on mac
<geist>
CompanionCube: hmm, good pint, since it is using a standard libc isn't it
<mjg>
oh man
<mjg>
> 23:43 < clever> ive heard that after CoW fork got added, vfork was just an alias to fork
<mjg>
triggering
<mjg>
there is a common myth outside of osdev circles that fork is cheap cause cow
<mjg>
made me into a sad panda let me tell ya
<heat>
geist, btw posix_spawn is a syscall in darwin
<bslsk05>
github.com: darwin-xnu/posix_spawn.c at main · apple/darwin-xnu · GitHub
<moon-child>
I think at some point they canvased all their packages for use of fork + stuff + exec, and figured out how to make their posix_spawn support all the stuff
<heat>
i think it makes sense to implement it in userspace
<heat>
a-la fuchsia
<heat>
spawn()-like calls are very much not great
<heat>
and ofc you're not really going to standardize on vfork or clone agian
<heat>
again*
<heat>
at least not in a useful way (involving vm internals, process internals, etc)
<CompanionCube>
specifically it seems to be darwin syscall 244
<CompanionCube>
out of 545
<mjg>
moon-child: that's what i remember, but i don't think they do anything special inside
<mjg>
moon-child: as in it just wraps vfork *in* the kernel afair
<moon-child>
oh!
<moon-child>
well
<mjg>
it might have changed, last time i had seen it was like 6 years ago
<heat>
lul
<mjg>
i'm not opposed to it in the sense that should this ever get fixed, even legacy libc will immediately take advantage
<moon-child>
yeah, implementation is a lot easier to fix than implementation, but still, wow
<moon-child>
err, implementation a lot easier to fix than interface
<mjg>
i think it's the better choice than wrapping in libc, if ultimately you will do a vfork anywya
<heat>
you could avoid the vfork I guess
<mjg>
how about you check the current state man
<mjg>
i'm not going there :>
<moon-child>
lol
<heat>
I think that no UNIX-like kernel is ready to support exec without execve
<mjg>
moon-child: what's up with your interest in that system anyway
<mjg>
:>
<heat>
I'm not familiar with BSD's exec code but linux has a bunch of it set up for flushing of the old address space for the new one you just set up
<moon-child>
mjg: netbsd? Not really interested in it at all, just remember reading that somewhere
<mjg>
both have similar general approach
<mjg>
you get a new address space, old one gets whacked and that's your point of no return
<heat>
netbsd is only for people who want to access the interwebs
<mjg>
should somethign go wrong past that point you get killed
<heat>
mjg, yeah. honestly that is surprisingly tricky
<moon-child>
I never touch that stuff
<moon-child>
I heard if you go on the interweb a hacker will steal your credit card
<moon-child>
using untraceable blockchain proxies
<heat>
how do you get the most error-recovery possible in execve?
<heat>
it's un-easy
<mjg>
moon-child: not if you use NORDVPN
<mjg>
moon-child: let me tell you about my sponsor...
<heat>
USE CODE MATTHEWGARRET40 FOR 40% DISCOUNT
<mjg>
heat: well you don't past reporting there is no binary :-p
<klange>
/kickban mjg
<rpnx>
Does anyone know how to link a kernel using LLVM?
<klange>
very carefully
<heat>
like in gcc, but with clang
<mjg>
freebsd is doing it, i can find the one-liner, but it may be quite longish
<zid>
clang kernel.c
<heat>
mjg, can u oneline me the kernl thx
<klange>
gotta expand all these macros first, those can't go on one line together
<mjg>
life would be better if they skipped the other 'e'
FreeFull has quit []
Oshawott has joined #osdev
<heat>
HEYG UYS HEAT HERE FOR ANOTHER RUST TUTORIAL
<moon-child>
I thought we're getting rid of es
<mjg>
fd = ope("/dev/zero", ...);
<moon-child>
isn't it hat now?
<heat>
TODAY WE'RE SETTING UP PAGING, CRAZY I KNUW RIGHT
<mjg>
heat: allright motherf^Wman you asked for it
<mjg>
heat: at (naming a company!) red hat a very incompetent person decided to deliver a training to other incompetent peole
<klange>
children, please, play nice
<heat>
ok so I now know what the incompetent company is
<mjg>
heat: subject matter was kernel crash analysis, taught to bad sysadmins by someone who can't code C
<heat>
thanks
<moon-child>
meh you can always name redhat
<mjg>
heat: ... even that guy had to abort as it turned out the audience does not know what a pointer is
<heat>
what does tht have to do with rust tutorials
bauen1 has quit [Ping timeout: 252 seconds]
<mjg>
it was most bizzarre
<heat>
no its not
<heat>
they're sysadmins, why should they need to know what a pointer is
<moon-child>
why are you expecting someone who doesn't know what a pointer is to analyse a kernel crash?
<heat>
your life gets progressively worse as you understand what pointers are
bauen1 has joined #osdev
<zid>
If you're in a position to find out, your life is already ruined
archenoth has quit [Ping timeout: 252 seconds]
<heat>
I don't expect non-kernel-devs to analyse kernel crashes
<mjg>
heat: the bizzare part was teaching them kernel crash analysis
<klange>
sometimes I don't understand my crashes and I wrote all the damn code
<mjg>
heat: ... if you don't know what a pointer is, what's even going on here
<heat>
should've taught them firmware crash analysis
<heat>
it's like kernel crash analysis but without the tools
<heat>
just vibes and DEBUG ((DEBUG_INFO))
<moon-child>
fun
<mjg>
there was a general push by management to "educate" non-programmers to become programmers
<zid>
I debug kernel using the backtrace instead
<mjg>
as usual it did not work for (bad word for excrements goes here)
<zid>
"It crashed in the 8139too code, time to buy a different network card"
<mjg>
NE2000
<heat>
it crashed in the 8139too code, but what about the other NIC?
<heat>
mjg, not everyone should be a programmer and this is a fact
<mjg>
agreed
<zid>
we need fewer already
<heat>
"hey, everyone should learn how to code" people are setting back programming by decades
<zid>
we've hit aliexpress levels of programmers as a commodity
<heat>
no, your 10 year old daughter doesn't want to learn how to code
demindiro has joined #osdev
<zid>
teach her how to use a computer first
<mjg>
well you can still get a programming job while doing nothing
<zid>
mjg: give
<mjg>
i don't know when that's going to stop
<zid>
I 100% will take any job you have where I do nothing
<mjg>
zid: take any not-FAANG corp and you will find roles
<zid>
that sounds like work
<mjg>
all you need to do is a little organisation jockeying
Irvise_ has joined #osdev
<mjg>
most useless fuck i ever met was in meetings half his work hours
<zid>
If your job is looking for jobs, that's still a job
<mjg>
and was paid more than everyone else in the team
<mjg>
his meetings were mostly set up with other grifters, so it's not like he was accomplisying anything
<mjg>
big corps are fucking amazing at wasting money all over and then looking for savings by whacking people who do actual work
<moon-child>
being in meetings half the day seems less pleasant than actually writing code
<mjg>
dude he would be watching youtube videos and whatnot
<rpnx>
Ah okay finally found out how to do it. need to use ld.lld to get llvm to use gcc syntax
<mjg>
while dialled in
<moon-child>
oh, well
<rpnx>
it was defaulting to apple LD syntax
<heat>
rpnx, mate, clang has gcc syntax all over
<klange>
Not everyone should learn to be a mechanic, but if you earn a living driving cars, you should at least know how to change the oil and tires...
<bslsk05>
wiki.osdev.org: Raspberry Pi Bare Bones - OSDev Wiki
<heat>
'ate me vim, 'ate me nano, luv me sum ed
<klange>
those instructions assuem you have a binutils toolchain
<zid>
heat: That's less fun
<heat>
here's a tip for life: osdev wiki isn't gospel, lots of articles there are deeply flawed
<zid>
ed is actually the editor daemon
<klange>
and not just a binutils toolchain, but a targeted cross-compiler toolchain that only knows how to build aarch64 ELFs
<zid>
I only use osdev wiki for pirated pci spec info
<rpnx>
yeah I've been trying to adapt it to clang/llvm
<rpnx>
I seem to have it working now
<zid>
the code and commands people submitted is all total trash
<rpnx>
(not booted test, but compiles and links)
<heat>
+1 (usually)
<klange>
it's a wiki, submit better code then
<heat>
>worth noting the instructions say to invoke the linker manually
<heat>
no they don't?
<klange>
lol yep, heat's right, that guide calls gcc to link
<heat>
anyway if you're using a random clang to osdev you're going to need to compile compiler-rt yourself
<klange>
unlikely for aarch64
<heat>
because apple's clang won't have aarch64-elf builtins I'll guarantee you that
<heat>
i ship a compiler-rt with the kernel and it Just Works(tm)
<heat>
for both clang and gcc
<rpnx>
Why do I need compiler-rt?
<heat>
the compiler sometimes needs to do stuff it can't easily do so it calls a function in compiler-rt
<heat>
a good example is 64-bit operations in 32-bit code
<klange>
I explicitly do not link any compiler runtime libs for my kernel, gcc/clang should not be producing function calls to their rts for anything you'd do in a kernel on x86-64 or aarch64
<rpnx>
hum I agree with that
<klange>
did have to do a little bit of coaxing to get gcc to not emit calls for some atomic stuff, but otherwise it's been smooth sailing
<heat>
riscv is a bitch
<rpnx>
you didn't reimplement the standard library?
<heat>
no
<klange>
they aren't standard library things
<rpnx>
oh the c version
<klange>
heat is definitely right about 64-bit ops on 32-bit platforms, 32-bit x86 for example will shit out tons of rt function calls in either compiler