Search logs:

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present


http://bespin.org/~qz/search/?view=1&c=osdev2&y=22&m=5&d=27

Friday, 27 May 2022

00:00:00 <mrvn> There is a compiler for it but I want one that outputs music scores for the source.
00:03:00 <klange> https://kuroko-lang.github.io/ been working on a lot of little things
00:03:00 <bslsk05> ​kuroko-lang.github.io: Kuroko
00:08:00 <mrvn> duck typing? fully modifiable classes? decorators?
00:17:00 <klange> I've started to think 'duck typing' is a terrible description of how things work in languages like Python.
00:17:00 <klange> The common description of "duck typing" actually describes structural typing, which is a very different thing.
00:17:00 <zid> I thought it described typing with your peak
00:17:00 <zid> beak
00:28:00 <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...")
00:29:00 <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.
00:30:00 <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."
00:33:00 <mrvn> Yeah, there is no "it's a duck" in python.
00:34:00 <mrvn> isinstance(quacking_thing, duck) doesn't return true
00:35:00 <mrvn> ocaml I think actually has duck typing. And it's a strickly compile time typed language.
00:35:00 <mrvn> If something wants a duck then anything that has the interface of a duck will do
00:36:00 <klange> ocaml is the lead example of a structurally typed language on Wikipedia
00:38:00 <mrvn> which makes it really funny to have duck typing
00:39:00 <klange> Camel-typed languages.
00:47:00 <psykose> is there a language that makes duck quack outside your window?
00:53:00 <mrvn> struct A { A(std::string); } struct B : A { }; Why does A a("foo"); B b("foo"s); B c(A("foo")); work but not B b("foo");?
00:53:00 <klange> Because C++ hates you and wants you to be miserable.
00:54:00 <klange> (Most other languages are ambivalent and you being miserable is just a natural response to programming.)
00:54:00 <mrvn> What constructor does B get? B(std::string s) : A(s) { } doesn't seem to be it.
00:54:00 <mrvn> Does it have aggregate initialization?
00:57:00 <mrvn> C++ has just too many implicit and generated and conditional and maybe on a full moon rules.
01:03:00 <geist> it has aggravated initialization
01:10:00 <geist> oh speaking of esolangs: https://store.steampowered.com/app/1720850/AB/
01:10:00 <bslsk05> ​store.steampowered.com: A=B on Steam
01:11:00 <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
01:11:00 <geist> tis-100 i think is the last hackery game i spent too much time with, and it was quite good
01:19:00 <psykose> this almost looks like a shitpost
01:22:00 <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
01:22:00 <geist> yeah it wasn't so clear cut
01:22:00 <geist> he had to actually add a bug to exploit it, so it wasn't exactly like he found some huge hole
01:22:00 <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
01:22:00 <geist> it was 'assume there's a buffer overrun somewhere' then exploit it
01:23:00 <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
01:24:00 <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
01:24:00 <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
01:24:00 <geist> yeah i dont think it was
01:25:00 <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.
01:25:00 <geist> graphitemaster: /me nods
01:25:00 <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
01:26:00 <gorgonical> https://fuchsia.googlesource.com/fuchsia/+/5be4ba6410494c4c046502df70cf06474d6cfaba%5E%21/#F5
01:26:00 <bslsk05> ​fuchsia.googlesource.com: Diff - 5be4ba6410494c4c046502df70cf06474d6cfaba^! - fuchsia - Git at Google
01:26:00 <gorgonical> Specifically this diff blob is confusing
01:26:00 <graphitemaster> geist, It's the same mentality that makes developing apps on Android and iOS absolutely horrific.
01:27:00 <graphitemaster> If I can compile an executable somehow I just want the OS to fuckin' run it.
01:27:00 <geist> gorgonical: /me nods
01:27:00 <geist> graphitemaster: i encourage you to discuss it on the fuchsia discord
01:28:00 <geist> i mean, yes and i dont disagree with you
01:28:00 <gorgonical> I was hoping you'd be able to explain exactly how that fixes the bug. But if you don't understand it either
01:28:00 <geist> gorgonical: ah i can take a look at it later i'm just not really in the mood right now?
01:28:00 <geist> ie, just stopped working for the day so i'd kina rather not dig right back into work right now
01:28:00 <gorgonical> Oh no not a problem. I just thought you might know off the top of your head
01:28:00 <geist> no i dont
01:28:00 <gorgonical> Then it's not worth the trouble really
01:29:00 <geist> i mean it is interesting, i just dont have the source here becaus ei'm on my personal machine in a coffee shop
01:29:00 <geist> and i dont know that CL, but it indeed looks like a less than fantastic design
01:30:00 <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
01:30:00 <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
01:30:00 <geist> OTOH it just gets you the kernel log, so its basically the equivalent of dmesg
01:31:00 <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
01:31:00 <gorgonical> Something along those lines
01:31:00 <gorgonical> The moral of the blog: state things confidently and hope it convinces enough people you found a meaningful exploit
01:32:00 <geist> and actually we are totally happy that folks find these things. i really am trying not to sound defensive about it
01:32:00 <geist> but you know how any thing like this turns into some gigantic thing as is always
01:32:00 <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
01:32:00 <gorgonical> Of course
01:33:00 <gorgonical> graphitemaster: lol
01:33:00 <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
01:33:00 <geist> i just skimmed through it before
01:33:00 <geist> but i think a CVE came out of it, so good for him. probably goes on his resume
01:34:00 <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
01:36:00 <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)
01:36:00 <geist> sure, but then that's the point (though i didn't know of this particular edge case)
01:37:00 <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
01:37:00 <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
01:37:00 <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
01:38:00 <geist> but really that should be replaced largely with a user space construction
01:38:00 <gorgonical> Manifests, permissions, this that and the other that will allow you to build, but running blows up with somewhat vague error messages
01:38:00 <raggi> Yeah, components end up with a similar manifest configuration problem, and will need ongoing user experience work to improve
01:39:00 <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
01:40:00 * geist imagines a punk band fronted by Henry Rollins called Ambient Authority
01:40:00 * raggi imagines them playing the openbsd release track
01:40:00 <mrvn> https://godbolt.org/z/h6h1fhTh1 3 cases of gcc and clang disagreeing. wow.
01:40:00 <bslsk05> ​godbolt.org: Compiler Explorer
01:41:00 <raggi> Same spec versions?
01:42:00 <geist> looks like they're both jammed to c++20
01:43:00 <raggi> I couldn't see easily on a phone :-)
01:43:00 <geist> ah yeah
01:45:00 <mrvn> gcc -std=c++20 -ansi fails too. Is it some gcc extension?
03:27:00 <mrvn> clang doesn't do aggregate initialization with () and B is an aggregate type, which is why it works for gcc
05:43:00 <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
06:00:00 <mrvn> we realized that
06:15:00 <sham1> Ah
10:26:00 <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?
10:28:00 <GeDaMo> https://www.kernel.org/doc/html/v4.12/process/adding-syscalls.html ?
10:28:00 <bslsk05> ​www.kernel.org: Adding a New System Call — The Linux Kernel documentation
10:38:00 <dostoyevsky2> I actually found a talk on what I want to do directly: https://www.youtube.com/watch?v=uXgxMDglxVM
10:38:00 <bslsk05> ​'Implementing a clone of OpenBSD pledge into the Linux kernel - Guillaume Pagnoux (FR)' by GConfs (00:29:29)
14:17:00 <mrvn> Is there a syntax for "using namespace Foo;" that only affects a block of statements?
14:21:00 <GeDaMo> Could you put the using inside a {} block?
14:22:00 <mrvn> yes I can. the simplest things. :)
14:23:00 <GeDaMo> That's me! :P
14:23:00 <mrvn> Not ideal though: int t = []() { using namespace Foo; return x;} is kind of clumsy.
14:24:00 <mrvn> +()
14:25:00 <GeDaMo> Can you not return Foo::x ?
14:25:00 <mrvn> assume there are lots of Foo::x/y/z/....
14:25:00 <GeDaMo> Ah
14:30:00 <mrvn> In ocaml I write: int sum = Foo(x + y + z); I'm just used to everything being an expression instead of statements.
14:36:00 <GeDaMo> I don't see anything obvious https://en.cppreference.com/w/cpp/language/namespace
14:36:00 <bslsk05> ​en.cppreference.com: Namespaces - cppreference.com
15:05:00 <mrvn> At least with lambdas we finally don't need the gcc extentions anymore: {{ int x = 1; int y = 2; x + y; }}
15:06:00 <mrvn> Had to do that trick in macros a bunch of times.
15:06:00 <mrvn> (if I even still remmeber that syntax correctly)
15:23:00 <mrvn> If I mmap(..., MAP_SHARED | MAP_ANONYMOUS, ...) and the fork() will both processes use the same physical pages for the mapping (linux)?
15:26:00 <sham1> I'd think so, since fork() clones the address space, but you probably ought to check the docs
15:29:00 <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.
15:29:00 <mrvn> That then just leaves memory barriers to get data synchronized.
15:30:00 <mrvn> Lets see if that makes the code work on ARM.
17:20:00 <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?
17:20:00 <mrvn> addr2line?
17:20:00 <mrvn> or in the kernel?
17:21:00 <ckie> yeah, in the kernel, i added -d int,cpu_reset to my qemu flags for the lil register dump
17:23:00 <ckie> anyway it's not being very useful
17:23:00 <ckie> ckie@cookiemonster ~/git/locap -> addr2line -e build/kernel.o 759
17:23:00 <ckie> kernel.c:?
17:23:00 <mrvn> build/kernel.o has no address
17:23:00 <mrvn> you want: -e kernel.elf
17:24:00 * ckie briefly facepalms
17:24:00 <ckie> i figured removing the offset would make it play along
17:24:00 <ckie> still
17:24:00 <ckie> ckie@cookiemonster ~/git/locap -> addr2line -e build/locap.x86_64.elf ffffffffffe02759
17:24:00 <ckie> kernel.c:?
17:24:00 <mrvn> did you build with -g and not strip the elf?
17:26:00 <ckie> was the missing -g, thanks
17:26:00 * ckie really wants to get out of the bootstrapping phase
17:27:00 <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.
17:27:00 <mrvn> (and when you do please write a osdev wiki page for it)
17:28:00 <ckie> i wrote a ceil,floor and round a few minutes ago
17:28:00 <ckie> a bit far from that
17:28:00 <mrvn> why would you need any of them?
17:29:00 <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
17:30:00 * ckie is currently adding a little thing to their makefile so it calls addr2line automatically on crash
17:30:00 <mrvn> with printfs complex formating options generating the string for an int backwards is really the best practice.
17:30:00 <ckie> i don't want a printf
17:30:00 <mrvn> you will eventually.
17:31:00 <mrvn> do you have ptr_to_hex?
17:31:00 <ckie> https://wiki.osdev.org/Alta_Lang
17:31:00 <bslsk05> ​wiki.osdev.org: Alta Lang - OSDev Wiki
17:31:00 <ckie> mrvn: no, but string_bits and a handy repl has gotten far enough
17:32:00 <ckie> for now..
17:33:00 <ckie> i am starting to get annoyed at make though
17:33:00 <GeDaMo> I would also generate the integer backwards
17:34:00 <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
17:34:00 <mrvn> How do you even do a log10ß for uint64_t?
17:34:00 <GeDaMo> Put the digits into the end of the buffer backwards then return the address of the last digit generated
17:35:00 <mrvn> ckie: Huh? YOu generate it backwards and then just print/copy the generated bits. There is no garbage.
17:35:00 <ckie> i am now staring at the realization
17:36:00 <ckie> holy shit last-time-i-worked-on-this me was dumb
17:36:00 <ckie> though i don't suppose having a bunch of annoying math things implemented already hurts
17:40:00 <GeDaMo> https://ideone.com/2M6ALA
17:40:00 <bslsk05> ​ideone.com: 2M6ALA - Online C Compiler & Debugging Tool - Ideone.com
17:41:00 * ckie already got it working
17:41:00 <ckie> (but thanks)
17:41:00 <GeDaMo> :P
17:41:00 <ckie> i'm only doing this bit in C because i want to get a lay for the land before i continue with my language
17:42:00 <mrvn> GeDaMo: why are you using that over godbolt?
17:43:00 <mrvn> shouldn't itoa return a const char *?
17:43:00 <GeDaMo> I tend to think of godbolt as just showing the asm produced by the compiler
17:43:00 <GeDaMo> I knew someone would start nitpicking :P
17:43:00 <mrvn> :)
17:44:00 <mrvn> In godbold you can add "Execution only" windows for various compilers. Nice to see if different compilers produce the same result.
17:44:00 <GeDaMo> https://www.oilshell.org/blog/2022/02/diagrams.html
17:44:00 <bslsk05> ​www.oilshell.org: The Internet Was Designed With a Narrow Waist
17:46:00 <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.
17:47:00 <GeDaMo> Maybe make a note of it in the documentation? :P
17:47:00 <ckie> it'd be nice if past me also added a //TODO for what to do *next*
17:47:00 <ckie> (which i had very clear at the time)
17:48:00 <heat> mrvn, it's called "being a POSIX function without _r" :P
17:49:00 <mrvn> GeDaMo: compilers don't read documentation, users certainly don't read documentation either.
17:49:00 <mrvn> heat: :(
17:49:00 <GeDaMo> You need a sufficiently smart compiler :P
17:49:00 <heat> doing it is a bad idea anyway
17:50:00 <heat> almost certainly wrong
17:50:00 <GeDaMo> I know, I just slapped it together quickly
17:50:00 <mrvn> The C++ core guidelines have owned<T>, maybe there should be a static_buf<T>
17:50:00 <GeDaMo> There's never just one of anything
17:50:00 * heat whispers "what if we add lifetimes to a language"
17:51:00 <mrvn> heat: this is for fixing legacy interfaces :)
17:51:00 <mrvn> and for before we have a heap use
17:51:00 <heat> you add a _r variant that takes a buffer
17:51:00 <heat> the POSIX special :)
18:22:00 <zid> heat_r
18:22:00 <zid> we can run him twice now, unfortunately
18:24:00 <mrvn> That might be nice in the winter. But it's hot enough already.
18:24:00 <mrvn> heat_r(tee); heat_r(food); enjoy();
18:27:00 <mrvn> It's https://www.hellofresh.de/recipes/undefined-62540a523f595e30b615c003?to-instructions=true&week=2022-W21 for me today.
18:27:00 <bslsk05> ​www.hellofresh.de: Knuspriges Kräuterschnitzel Rezept | HelloFresh
18:28:00 * geist yawns
18:29:00 <geist> oh didn't know hello fresh was over there too
18:33:00 <sham1> Does it sponsor today's IRCing
18:47:00 <heat> it's dollar shave club who's sponsoring IRC
18:47:00 <heat> used to be manscaped
18:50:00 <zid> Can we switch to audible
18:51:00 <zid> I don't shave but I do pirate books
18:53:00 <heat> can you do honey?
18:53:00 <GeDaMo> Pirate honey? :|
19:00:00 <sham1> I mean, beekeeping does sometimes feel like the beekeeper is plundering and ravaging the beehive
19:02:00 <heat> karl marx originally wrote about beekeepers
19:03:00 <zid> bees control the means of production
19:03:00 <zid> down with the bees!
19:03:00 * zid throws shoes into the mecahnism of the beehive
19:09:00 <mrvn> mecahnism of the beehive? A box with a hole at the bottom of a side. Not much to throw a shoe into.
19:14:00 <jafarlihi> Is anyone here writing an OS using their own language they have created a compiler for? Like Terry Davis.
19:15:00 <GeDaMo> Does thinking about doing it count? :P
19:15:00 <jafarlihi> Yes, same here
19:16:00 <zid> Does laughing at GeDaMo for thinking about it count
19:16:00 <jafarlihi> No
19:16:00 <GeDaMo> Are you aware of Project Oberon?
19:16:00 <jafarlihi> Yes
19:16:00 <GeDaMo> http://www.projectoberon.com/
19:16:00 <bslsk05> ​www.projectoberon.com: Home
19:17:00 <zid> GeDaMo knows about it because of his deep involvement in the fairy roleplaying fandom
19:17:00 <GeDaMo> And the STEPS project?
19:17:00 <jafarlihi> No, what is it?
19:18:00 <heat> writing a good compiler these days isn't that hard cuz of llvm
19:18:00 <heat> new languages usually just use it for codegen (rust, zig)
19:19:00 <GeDaMo> STEPS was about writing a complete computing system (OS, development tools, applications) in less than 20K lines of code
19:19:00 <GeDaMo> http://vpri.org/writings.php
19:19:00 <bslsk05> ​vpri.org: Viewpoints
19:19:00 <zid> we should write a cool language for writing OSes with, it can be like BCPL but better.
19:21:00 <GeDaMo> "Proposal to NSF Granted on August 31; 2006" http://www.vpri.org/pdf/rn2006002_nsfprop.pdf
19:22:00 <heat> good idea zid
19:22:00 <heat> what should we name it?
19:22:00 <GeDaMo> Also look at the yearly progress reports
19:41:00 <zid> heat: D, obviously.
19:41:00 <zid> Programming D. Language
19:42:00 <zid> Hopefully it can become the pirate king
19:42:00 <ThinkT510> serenityos is written in C++ but they've started a new language: https://github.com/SerenityOS/jakt
19:42:00 <bslsk05> ​SerenityOS/jakt - The Jakt Programming Language (118 forks/1242 stargazers/BSD-2-Clause)
19:42:00 <ThinkT510> probably only a matter of time until they rewrite the OS in it
19:43:00 <sham1> But why
19:45:00 <heat> so you have an OS written in a language nobody knows and generate crappier, slower code
19:45:00 <heat> it makes all the sense in the world
19:46:00 <zid> Well at least it won't be written in C++
19:46:00 <j`ey> then you improve the compiler and the OS goes vrroom
19:47:00 <zid> My favourite bit of osdev + language dev + compiler theory nonsense is people writing the compiler for their language in their language
19:47:00 <zid> which just means their language ends up being tailored to write compilers in
19:47:00 <GeDaMo> https://bootstrapping.miraheze.org/wiki/Main_Page
19:47:00 <bslsk05> ​bootstrapping.miraheze.org: bootstrapping
19:47:00 <heat> is that how rust works j`ey?
19:48:00 <heat> you would know as the CEO of rust
19:48:00 <j`ey> as the CEO of rust, rust is not tailored for writing compilers
19:48:00 <j`ey> even though it is bootstrapped, it is general purpose and can be used for many rojects
19:48:00 <j`ey> *projects
19:48:00 <heat> i'm merely a COO of rust but I think it's perfect to write everything
19:49:00 <heat> i'm almost as big a fan of rust as I am of the caveman language I found out the other day
19:50:00 <heat> we should truly reject languages and become caveman
19:50:00 <heat> amish software engineering
19:55:00 <mrvn> heat: do you know of a tutorial for writing an llvm frontend?
19:56:00 <heat> mrvn, llvm has lots of good docs, I think i've seen some about that before
19:56:00 <sham1> LLVM also does have a tutorial
19:56:00 <heat> mrvn, https://llvm.org/docs/tutorial/index.html
19:57:00 <bslsk05> ​llvm.org: LLVM Tutorial: Table of Contents — LLVM 15.0.0git documentation
19:57:00 <mrvn> thanks
19:57:00 <mrvn> Maybe I will get camomile and caramel finally of the ground with that and some rainy days.
20:03:00 <heat> i'm happy you chose llvm, the best toolchain out there
20:03:00 <heat> liberally licensed too
20:04:00 <j`ey> try libgccjit too
20:04:00 <heat> NO
20:04:00 <heat> libgccjit? more like libgccshit am I right guys and girls haha
20:05:00 <j`ey> >_<
20:05:00 <j`ey> someone is building an alternative rust backend with libgccjit
20:07:00 <heat> downvote
20:07:00 <j`ey> there's quite a few alternatives now, llvm, cranelift, libgccjit, mrustc, gccrs
20:15:00 <heat> a bit offtopic but are OEM platforms that different from the reference Intel/AMD ones?
20:23:00 <mrvn> j`ey: what assembler are they using?
20:23:00 <mrvn> heat: what Intel/AMD platform?
20:24:00 <j`ey> mrvn: idk, binutils?
20:24:00 <mrvn> j`ey: llvm has it's own and can do things gas can't do (PC relative constant loading from another segment)
20:25:00 <j`ey> mrvn: it deoends which project yore talking about, i assume the rust+libgccjit is using binutils, and gccrss too
20:25:00 <mrvn> that leaves cranelift
20:26:00 <heat> mrvn, Intel upstreams a bunch of reference platform code each generation
20:26:00 <j`ey> mrvn: cranelift generates machine code
20:35:00 <jafarlihi> How many months/years into osdev/compilerdev do you ditch books?
20:36:00 <jafarlihi> Books are for noobs, right? At some point you only read code and research papers
20:36:00 <j`ey> lol
20:39:00 <heat> lol2
20:40:00 <jafarlihi> It's a serious question
20:40:00 <heat> nobody knows everything
20:40:00 <jafarlihi> even kling?
20:40:00 <heat> yes lol
20:40:00 <geist> books are not for noobs
20:40:00 <heat> who do you think kling is?
20:40:00 <geist> also who is kling?
20:40:00 <heat> serenity OS guy
20:40:00 <geist> oh
20:41:00 <jafarlihi> Does he still read once he is on that level?
20:41:00 <heat> of course
20:41:00 <geist> of course
20:41:00 <jafarlihi> Like what books? Aren't all books just basics and popular algos?
20:41:00 <heat> (I don't even think he's on a high level)
20:41:00 <heat> no.
20:41:00 <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?
20:42:00 <jafarlihi> I don't hate books, I just can't find ones targeting experts
20:42:00 <jafarlihi> Not that I'm one
20:42:00 <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
20:43:00 <heat> https://books.google.pt/books/about/Practical_File_System_Design_with_the_BE.html?id=HVp0QgAACAAJ&source=kp_book_description&redir_esc=y
20:43:00 <bslsk05> ​books.google.pt: Practical File System Design with the BE File System - Dominic Giampaolo - Google Books
20:43:00 <heat> there's one
20:43:00 <mrvn> when you write The Book you can ditch the old ones.
20:43:00 <geist> yah or lots of computer architecture books, there are some quite advanced ones
20:43:00 <geist> what there aren't are a lot of 'advanced OS design' books.
20:43:00 <geist> but i think that's just cause one of us hasn't written it
20:44:00 <heat> yup
20:44:00 <heat> you can try to piece some information together from the windows internals books
20:44:00 <geist> it's a wide topic and i dont think there's a tremendous amount of general interest in the topic outside of a fairly niche set of folks
20:44:00 <heat> and, above all, it's very poorly documented
20:44:00 <geist> yah when i was learning initially i got a bunch of the internals books and those were useful
20:44:00 <mrvn> I haven't yet found a book about multi-core Data Structures as opposed to (user space) multi-threaded.
20:45:00 <geist> https://docs.google.com/document/d/1-AhU-67DI0L0t5ZmeH8aoMVaowDnUibl2wSQxyGp3IQ/edit?usp=sharing is my usual go to link of books i found useful back in the day
20:45:00 <bslsk05> ​docs.google.com: Computer Books - Google Docs
20:45:00 <heat> geist, yeah and the internals books are probably the most concentrated source of information about modern operating systems
20:45:00 <geist> i learned a lot from the internals books
20:45:00 <geist> yah
20:45:00 <geist> i'm sure there are newer things, i mostly just went through my bookshelf
20:46:00 <jafarlihi> What device do you use for consuming ebooks? Laptop?
20:46:00 <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
20:47:00 <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
20:47:00 <heat> the richard stevens books and the "The Linux Programming Interface" books are also nice
20:47:00 <mrvn> the problem iwt linux books is that 2 years from now they are obsolete.
20:48:00 <heat> the linux MM people are trying to write some sort of better, concentrated docs
20:48:00 <geist> right, in general that's the issue with any book that describes a thing that exists now, vs a more theoretical thing
20:48:00 <geist> like all of those books i used to get on say visual studio X or whatnot
20:48:00 <heat> the latest proper book thing they have dates from linux 2.5 or 2.4 or whatnot
20:48:00 <geist> MFC programming version 2!
20:48:00 <geist> .NET version 5!
20:48:00 <mrvn> dead trees do not age well
20:50:00 <geist> but they do tell tales
20:50:00 <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?
20:50:00 <j`ey> no
20:50:00 <jafarlihi> j`ey: Then why read?
20:51:00 <heat> because you want to?
20:51:00 <heat> whether you should read books or not is subjective
20:52:00 <heat> you were too fixated on copying tutorials, now you're too fixated on the theory
20:52:00 <heat> chill, try to get something going and _UNDERSTAND IT_
20:53:00 <jafarlihi> I want to be able to design my own language and implement a compiler for it
20:53:00 <jafarlihi> That surely would mean I'd have to read few compiler books, no?
20:54:00 <heat> maybe?
20:54:00 <heat> but didn't you want to write an OS before that?
20:54:00 <jafarlihi> I decided it would be better if I did it in my own language
20:54:00 <heat> well, ok, unlikely but focus on the language first
20:54:00 <j`ey> o
20:55:00 <heat> people that created a language and then an OS on top of it are basically like at most 10
20:55:00 <j`ey> 10 years old?
20:56:00 <heat> obviously that's what I meant j`ey
20:56:00 <heat> all genius 10 year olds
21:02:00 <dasabhi> man i missed you guys
21:02:00 <dasabhi> its been a while since i last hopped on
21:02:00 <dasabhi> any one here hack on the xv6 risv port recently?
21:38:00 <zid> I hope that guy buys a clue at some point
21:39:00 <zid> He's driven but in completely the wrong direction
21:42:00 <heat> having a drive is a good start
21:42:00 <heat> i used to cluelessly copy tutorials as well
21:42:00 <heat> until I took an arrow to the knee
21:43:00 <zid> I never had that phase
21:43:00 <zid> I just wrote for fun and gave up if I didn't understand something
22:07:00 <geist> dasabhi: hmm, i dont think too many people fiddle with xv6, but that sounds fun
22:07:00 <geist> riscv is so straightfrward to hack kernels on, so it's probably a straightforward port
22:09:00 <mrvn> IfWill you buy me one
22:10:00 <mrvn> If you buy me one I will fiddle with it.
22:13:00 <geist> what are your requirements?
22:13:00 <geist> i can suggest boards based on what you want