<klange>
I've started to think 'duck typing' is a terrible description of how things work in languages like Python.
<klange>
The common description of "duck typing" actually describes structural typing, which is a very different thing.
<zid>
I thought it described typing with your peak
<zid>
beak
heat has quit [Remote host closed the connection]
Oshawott has joined #osdev
<klange>
"Duck typing", as you may know, is "if it looks like a duck, walks like a duck, and talks like a duck, it's a duck" (or more compactly, "if it quacks like a duck...")
<klange>
But languages like Python (and Kuroko) are very strictly typed internally. Attributes do not determine type, and an object can implement all the same methods exactly the same way and still not be that type.
<klange>
What the attribute/method lookup in Python, et al does is "I don't care if you're a duck, if you can quack and I ask you to quack, you quack."
<geist>
i generally stay away from that since i only have a finite number of hack units per day i like to keep to myself
joe9 has quit [Quit: leaving]
<geist>
tis-100 i think is the last hackery game i spent too much time with, and it was quite good
nj0rd has quit [Ping timeout: 246 seconds]
nj0rd has joined #osdev
gorgonical has joined #osdev
<psykose>
this almost looks like a shitpost
<gorgonical>
geist I saw a hackernews post about a linux hacker's take on zircon and he pointed out a bug that made it possible to use debug logs to leak kernel info. In the blogpost he made it seem like it should be obvious but I didn't quite get it
<geist>
yeah it wasn't so clear cut
<geist>
he had to actually add a bug to exploit it, so it wasn't exactly like he found some huge hole
<gorgonical>
So you know what I mean. The way I saw it was the kernel code was indeed checking if the handle was invalid, but then the fix only seems to check options at that same code snippet
<geist>
it was 'assume there's a buffer overrun somewhere' then exploit it
<geist>
i didn't read it too closely. i'm happy he was interested and it wans't a bad blog per se. of course hackernews mostly just acted like the cesspool it is, so i kinda stopped reading it at that point
<gorgonical>
Oh yeah I didn't read the comments at all. It's stuck with me because I feel like I should be able to understand why he thought it was such an egregious bug
<geist>
like i said i'm not dismissing the blog, but it wasn't really that much of an issue, though i think there was at least an actionable item on it
<geist>
yeah i dont think it was
<graphitemaster>
I read that article too and I must say I found the way you're meant to write programs for fuchsia so ... horrible, lol, like the concept of a component and all that custom fx commands to start projects and what not - I don't like that centralization of everything related to software as part of an OS design, made me really unhappy.
<geist>
graphitemaster: /me nods
<geist>
note that none of that is implied by the kernel or the low level design of zircon. its simply the state of the art of the way the current user space has evolved
<bslsk05>
fuchsia.googlesource.com: Diff - 5be4ba6410494c4c046502df70cf06474d6cfaba^! - fuchsia - Git at Google
<gorgonical>
Specifically this diff blob is confusing
<graphitemaster>
geist, It's the same mentality that makes developing apps on Android and iOS absolutely horrific.
<graphitemaster>
If I can compile an executable somehow I just want the OS to fuckin' run it.
<geist>
gorgonical: /me nods
<geist>
graphitemaster: i encourage you to discuss it on the fuchsia discord
<geist>
i mean, yes and i dont disagree with you
<gorgonical>
I was hoping you'd be able to explain exactly how that fixes the bug. But if you don't understand it either
<geist>
gorgonical: ah i can take a look at it later i'm just not really in the mood right now?
<geist>
ie, just stopped working for the day so i'd kina rather not dig right back into work right now
<gorgonical>
Oh no not a problem. I just thought you might know off the top of your head
<geist>
no i dont
<gorgonical>
Then it's not worth the trouble really
<geist>
i mean it is interesting, i just dont have the source here becaus ei'm on my personal machine in a coffee shop
<geist>
and i dont know that CL, but it indeed looks like a less than fantastic design
<geist>
OTOH there are a few of older things like that that we've been slowly replacing, especially in the area of bootstrapping and debugging, so it's entirley likely that's just a hole that needs to be patched, and so good for him
<graphitemaster>
geist, eh, fuchsia isn't exactly something I use yet so these are superficial complaints, if I was using this OS and having to deal with constant friction from these design choices I'd be in the Discord complaining :P
<geist>
OTOH it just gets you the kernel log, so its basically the equivalent of dmesg
<gorgonical>
Yeah that's what the fuchsia devs said: getting this exploit to work sort of gets you little because of what you need to run it anyway
<gorgonical>
Something along those lines
<gorgonical>
The moral of the blog: state things confidently and hope it convinces enough people you found a meaningful exploit
<geist>
and actually we are totally happy that folks find these things. i really am trying not to sound defensive about it
<geist>
but you know how any thing like this turns into some gigantic thing as is always
<graphitemaster>
I too found an exploit, if you have access to the source code and recompile the kernel you can do a lot of damage
<gorgonical>
Of course
<gorgonical>
graphitemaster: lol
<geist>
yah i still dont completely understand what the issue is with that CL but i should just re-read the article when i get a chance
<geist>
i just skimmed through it before
<geist>
but i think a CVE came out of it, so good for him. probably goes on his resume
<raggi>
There's a pretty big trade-off in the "let me run code I just built without any constraints" thing, it's definitely an important feature in a development environment
<gorgonical>
geist: My working hypothesis is that because the check only requires that the handle be non-invalid, maybe you can just pass an invalid handle to it? That would explain why you can still have an invalid handle as long as its write-only (per the new comments)
<geist>
sure, but then that's the point (though i didn't know of this particular edge case)
<geist>
also the debuglog is kinda a big ehh. we haven't relaly found a good replacement for it except it should probably primarily not be a kernel feature
<gorgonical>
raggi: I can't speak for him, but I know the thing that irritated me about android dev was that compile-time restraints << run-time constraints and that's frustrating
<geist>
but it's still there. there's a funnel to shove line oriented data through the kernel that it serializes and buffers and sends out
<geist>
but really that should be replaced largely with a user space construction
<gorgonical>
Manifests, permissions, this that and the other that will allow you to build, but running blows up with somewhat vague error messages
<raggi>
Yeah, components end up with a similar manifest configuration problem, and will need ongoing user experience work to improve
<raggi>
That's going to be generally common to any system that doesn't provide arbitrary ambient authority, it's the same with snap and flatpak, etc
* geist
imagines a punk band fronted by Henry Rollins called Ambient Authority
* raggi
imagines them playing the openbsd release track
<mrvn>
gcc -std=c++20 -ansi fails too. Is it some gcc extension?
gorgonical has quit [Ping timeout: 240 seconds]
ccx has joined #osdev
robert_ has joined #osdev
smeso has quit [Quit: smeso]
Vercas has quit [Ping timeout: 240 seconds]
dude12312414 has joined #osdev
smeso has joined #osdev
Vercas has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
gorgonical has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
elastic_dog has quit [Ping timeout: 260 seconds]
elastic_dog has joined #osdev
<mrvn>
clang doesn't do aggregate initialization with () and B is an aggregate type, which is why it works for gcc
ketan has joined #osdev
mahmutov has joined #osdev
Vercas4 has joined #osdev
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas4 is now known as Vercas
mahmutov has quit [Ping timeout: 260 seconds]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
scoobydoob has joined #osdev
scoobydoo has quit [Ping timeout: 246 seconds]
scoobydoob is now known as scoobydoo
haliucinas has joined #osdev
<sham1>
RE: backlog discussion about `const volatile`, it does make sense in a way. Basically it's saying to you "hey, this can change but you can't write to it", so for example a hardware register thing which is only readable
<mrvn>
we realized that
gildasio1 has joined #osdev
gildasio has quit [Ping timeout: 240 seconds]
<sham1>
Ah
bauen1 has quit [Ping timeout: 250 seconds]
the_lanetly_052 has joined #osdev
bauen1 has joined #osdev
gxt has quit [Ping timeout: 240 seconds]
gxt has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
bauen1 has quit [Ping timeout: 258 seconds]
zaquest has quit [Read error: Connection reset by peer]
zaquest has joined #osdev
gxt has quit [Ping timeout: 240 seconds]
gxt has joined #osdev
bauen1 has joined #osdev
GeDaMo has joined #osdev
FatAlbert has joined #osdev
FatAlbert has left #osdev [WeeChat 3.5]
haliucinas has left #osdev [#osdev]
the_lanetly_052_ has joined #osdev
gog has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
netbsduser has joined #osdev
arch-angel has joined #osdev
wand has quit [Ping timeout: 240 seconds]
<dostoyevsky2>
Anyone know some examples where they describe how to write your own syscall for the Linux kernel and implement a data structure that keeps track of a processes state accross calls?
<mrvn>
At least with lambdas we finally don't need the gcc extentions anymore: {{ int x = 1; int y = 2; x + y; }}
<mrvn>
Had to do that trick in macros a bunch of times.
<mrvn>
(if I even still remmeber that syntax correctly)
particleflux has quit [Quit: 418 I'm a teapot]
particleflux has joined #osdev
<mrvn>
If I mmap(..., MAP_SHARED | MAP_ANONYMOUS, ...) and the fork() will both processes use the same physical pages for the mapping (linux)?
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
bauen1 has quit [Ping timeout: 246 seconds]
<sham1>
I'd think so, since fork() clones the address space, but you probably ought to check the docs
<mrvn>
"Memory mapped by mmap() is preserved across fork(2), with the same attributes.". and "Updates to the mapping are visible to other processes mapping the same region,". I guess that means yes.
<mrvn>
That then just leaves memory barriers to get data synchronized.
<mrvn>
Lets see if that makes the code work on ARM.
bauen1 has joined #osdev
heat has joined #osdev
bauen1 has quit [Ping timeout: 246 seconds]
bauen1 has joined #osdev
jack_rabbit has joined #osdev
knusbaum has quit [Ping timeout: 244 seconds]
<ckie>
x86, c, triple fault, i have the RIP value and i know the offset from my linker script. how can i get the source line of the instruction that faulted?
<mrvn>
addr2line?
<mrvn>
or in the kernel?
<ckie>
yeah, in the kernel, i added -d int,cpu_reset to my qemu flags for the lil register dump
<mrvn>
did you build with -g and not strip the elf?
<ckie>
was the missing -g, thanks
* ckie
really wants to get out of the bootstrapping phase
<mrvn>
you should generate a System.map during build and eventually include the symbol table in the kernel image so the kernel can resolve it's own addresses.
<mrvn>
(and when you do please write a osdev wiki page for it)
<ckie>
i wrote a ceil,floor and round a few minutes ago
<ckie>
a bit far from that
<mrvn>
why would you need any of them?
<ckie>
well i am a big time yak shaver. and i didn't want to loop twice in my int_to_string, so i needed a log10
* ckie
is currently adding a little thing to their makefile so it calls addr2line automatically on crash
arch-angel has quit [Ping timeout: 244 seconds]
<mrvn>
with printfs complex formating options generating the string for an int backwards is really the best practice.
<ckie>
mrvn: no, but string_bits and a handy repl has gotten far enough
<ckie>
for now..
<ckie>
i am starting to get annoyed at make though
<GeDaMo>
I would also generate the integer backwards
<ckie>
it is being generated backwards, and static char[] since no malloc yet, but i want to offset the pointer so there's not a bunch of extra garbage bytes printed
<mrvn>
How do you even do a log10ß for uint64_t?
<GeDaMo>
Put the digits into the end of the buffer backwards then return the address of the last digit generated
<mrvn>
ckie: Huh? YOu generate it backwards and then just print/copy the generated bits. There is no garbage.
<ckie>
i am now staring at the realization
<ckie>
holy shit last-time-i-worked-on-this me was dumb
<ckie>
though i don't suppose having a bunch of annoying math things implemented already hurts
<bslsk05>
www.oilshell.org: The Internet Was Designed With a Narrow Waist
blockhead has joined #osdev
<mrvn>
Is there some convention for marking return values that are pointers into a static buffer? Something so the user imediatly sees not to call the function again without saving the string first.
<GeDaMo>
Maybe make a note of it in the documentation? :P
<ckie>
it'd be nice if past me also added a //TODO for what to do *next*
<ckie>
(which i had very clear at the time)
<heat>
mrvn, it's called "being a POSIX function without _r" :P
<mrvn>
Maybe I will get camomile and caramel finally of the ground with that and some rainy days.
<heat>
i'm happy you chose llvm, the best toolchain out there
<heat>
liberally licensed too
<j`ey>
try libgccjit too
<heat>
NO
<heat>
libgccjit? more like libgccshit am I right guys and girls haha
<j`ey>
>_<
<j`ey>
someone is building an alternative rust backend with libgccjit
<heat>
downvote
<j`ey>
there's quite a few alternatives now, llvm, cranelift, libgccjit, mrustc, gccrs
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<heat>
a bit offtopic but are OEM platforms that different from the reference Intel/AMD ones?
<mrvn>
j`ey: what assembler are they using?
<mrvn>
heat: what Intel/AMD platform?
<j`ey>
mrvn: idk, binutils?
<mrvn>
j`ey: llvm has it's own and can do things gas can't do (PC relative constant loading from another segment)
<j`ey>
mrvn: it deoends which project yore talking about, i assume the rust+libgccjit is using binutils, and gccrss too
<mrvn>
that leaves cranelift
<heat>
mrvn, Intel upstreams a bunch of reference platform code each generation
<j`ey>
mrvn: cranelift generates machine code
jafarlihi has joined #osdev
jimbzy has quit [Ping timeout: 276 seconds]
wootehfoot has quit [Quit: Leaving]
<jafarlihi>
How many months/years into osdev/compilerdev do you ditch books?
<jafarlihi>
Books are for noobs, right? At some point you only read code and research papers
<j`ey>
lol
wootehfoot has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 246 seconds]
<heat>
lol2
pretty_dumm_guy has joined #osdev
<jafarlihi>
It's a serious question
pretty_dumm_guy has quit [Client Quit]
<heat>
nobody knows everything
<jafarlihi>
even kling?
<heat>
yes lol
<geist>
books are not for noobs
<heat>
who do you think kling is?
<geist>
also who is kling?
<heat>
serenity OS guy
<geist>
oh
<jafarlihi>
Does he still read once he is on that level?
<heat>
of course
<geist>
of course
<jafarlihi>
Like what books? Aren't all books just basics and popular algos?
<heat>
(I don't even think he's on a high level)
<heat>
no.
<geist>
tht's the fundamental issue here: you probably think of books as some lame thing that skool makes you read even though you hate it?
<jafarlihi>
I don't hate books, I just can't find ones targeting experts
<jafarlihi>
Not that I'm one
<geist>
now proper computer books may be generally going the way of the dodo bird, but if you zoom out a bit and say that in general pre-prepared information dumps in the form of a series of topics in order, sometimes printed sometimes not, no. those are helpful forever
<bslsk05>
docs.google.com: Computer Books - Google Docs
<heat>
geist, yeah and the internals books are probably the most concentrated source of information about modern operating systems
<geist>
i learned a lot from the internals books
<geist>
yah
<geist>
i'm sure there are newer things, i mostly just went through my bookshelf
<jafarlihi>
What device do you use for consuming ebooks? Laptop?
<geist>
but. it is true: there's not a lot of 'here's how to write an OS' books. there was one back in the 2000s i remember but it was so bad i tossed it
<geist>
it was one of those bad ideas in a form of some long written tutorial that ended up with some half assembly 386 class nonsense
<heat>
the richard stevens books and the "The Linux Programming Interface" books are also nice
<mrvn>
the problem iwt linux books is that 2 years from now they are obsolete.
<heat>
the linux MM people are trying to write some sort of better, concentrated docs
<geist>
right, in general that's the issue with any book that describes a thing that exists now, vs a more theoretical thing
<geist>
like all of those books i used to get on say visual studio X or whatnot
<heat>
the latest proper book thing they have dates from linux 2.5 or 2.4 or whatnot
<geist>
MFC programming version 2!
<geist>
.NET version 5!
<mrvn>
dead trees do not age well
<geist>
but they do tell tales
<jafarlihi>
Are you sure that I will have a better idea of how to implement OS correctly once I read all those books heavy on theory and contain not much code?
<j`ey>
no
<jafarlihi>
j`ey: Then why read?
<heat>
because you want to?
<heat>
whether you should read books or not is subjective
<heat>
you were too fixated on copying tutorials, now you're too fixated on the theory
<heat>
chill, try to get something going and _UNDERSTAND IT_
<jafarlihi>
I want to be able to design my own language and implement a compiler for it
<jafarlihi>
That surely would mean I'd have to read few compiler books, no?
<heat>
maybe?
<heat>
but didn't you want to write an OS before that?
<jafarlihi>
I decided it would be better if I did it in my own language
<heat>
well, ok, unlikely but focus on the language first
<j`ey>
o
<heat>
people that created a language and then an OS on top of it are basically like at most 10
<j`ey>
10 years old?
<heat>
obviously that's what I meant j`ey
dasabhi has joined #osdev
<heat>
all genius 10 year olds
<dasabhi>
man i missed you guys
<dasabhi>
its been a while since i last hopped on
<dasabhi>
any one here hack on the xv6 risv port recently?
Starfoxxes has joined #osdev
jafarlihi has quit [Quit: WeeChat 3.5]
Ali_A has quit [Quit: Connection closed]
<zid>
I hope that guy buys a clue at some point
<zid>
He's driven but in completely the wrong direction
<heat>
having a drive is a good start
<heat>
i used to cluelessly copy tutorials as well
<heat>
until I took an arrow to the knee
<zid>
I never had that phase
<zid>
I just wrote for fun and gave up if I didn't understand something
ripmalware_ has joined #osdev
ripmalware has quit [Read error: Connection reset by peer]
<geist>
dasabhi: hmm, i dont think too many people fiddle with xv6, but that sounds fun
<geist>
riscv is so straightfrward to hack kernels on, so it's probably a straightforward port
wootehfoot has quit [Quit: Leaving]
<mrvn>
IfWill you buy me one
<mrvn>
If you buy me one I will fiddle with it.
<geist>
what are your requirements?
<geist>
i can suggest boards based on what you want
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
Bonstra has quit [Remote host closed the connection]
pretty_dumm_guy has joined #osdev
knusbaum has joined #osdev
jack_rabbit has quit [Ping timeout: 272 seconds]
sebonirc has quit [Read error: Connection reset by peer]