klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
Affliction has quit [Quit: Read error: Connection reset by beer]
Affliction has joined #osdev
<mrvn> Don't forget to track file descriptors stuck in sockets.
<Mutabah> "stuck in sockets"?
<mrvn> unix can send FDs from one process to another over a socket. Easy to forget to close them when you throw away buffers from sockets.
<Mutabah> huh
CryptoDavid has quit [Quit: Connection closed for inactivity]
friedy10- has joined #osdev
mrkajetanp has quit [Ping timeout: 240 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.4.1]
gog has quit [Ping timeout: 256 seconds]
hbag has quit [Read error: Connection reset by peer]
hbag has joined #osdev
srjek has joined #osdev
sonny has joined #osdev
ephemer0l has quit [Ping timeout: 240 seconds]
sonny has left #osdev [#osdev]
srjek has quit [Ping timeout: 240 seconds]
smeso has quit [Quit: smeso]
smeso has joined #osdev
eryjus has quit [Read error: Connection reset by peer]
eryjus has joined #osdev
<geist> Hmm never actually used that feature. Does it remove the FD from the process when you stuff it in the socket?
<geist> Is it ‘owned’ by the socket until the other side reads it?
<milesrout> it's basically dup
<geist> Ah
<milesrout> but you're duping the fd into another process instead of into your own
<geist> Right, or into whoever reads it eventually. It’s probably sitting ‘in between’ in the interim
<geist> Or, presumably, closed if the socket is closed
<milesrout> it's probably documented under socket(7) or unix(7) or something
<milesrout> on linux at least, that is
<geist> Yah, just curious
heat has joined #osdev
<heat> helo
<geist> Heya heat
<klange> EHLO
<geist> RST
<geist> Now someone just needs to do a full IMAP handshake manually
<kazinsal> +++ATH0
<heat> it's SCM_RIGHTS btw
<heat> if you send an SCM_RIGHTS ancillary msg through a unix socket it passes a file descriptor
<geist> Ah
<milesrout> SCM_RIGHTS is the name, yeah
<geist> That always seemed to be completely out of phase with the rest of the posix ‘design’
<heat> fun fact: linux has a garbage collector inside the kernel because of SCM_RIGHTS and passing unix sockets through unix sockets
<milesrout> if you think of file descriptors as capabilities then the name and concept makes perfect sense
<geist> But then i thin that’s pretty much the only way to do anything like that? So for the cases where it’s useful, that’s it
<klange> It was a much later thing, sort of last gasp of treating file descriptors as capabilities.
<geist> Yah
<geist> That sort of thing is core to the fuchsia design, but it looks a bit different
<heat> SCM_CREDENTIALS is similar, it passes the sender's credentials (pid, uid, gid) through the socket
<geist> And yeah to avoid the GC thing that heat mentioned zircon limits the amount of duping of channel handles, though i think someone still proved you can do it
<heat> some sudo-like programs use this
<milesrout> if I remember correctly, there have been some good lwn articles on SCM_RIGHTS and the troubles it has caused the kernel wrt needing a gc etc.
<bslsk05> ​lwn.net: io_uring, SCM_RIGHTS, and reference-count cycles [LWN.net]
<geist> Woot
<heat> oh nice channels are pretty similar to unix sockets
mrkajetanp has joined #osdev
lainon_ has joined #osdev
* Griwes makes a mental note to disallow sending a token to the handle of a mailbox over that same mailbox
k8yun has joined #osdev
ephemer0l has joined #osdev
sonny has joined #osdev
k8yun has quit [Ping timeout: 250 seconds]
lainon_ has quit [Quit: Leaving]
eddof13 has joined #osdev
<heat> oh wow a fuchsia compile makes my linux swap!
xenos1984 has quit [Read error: Connection reset by peer]
<heat> it's doing the thing it never does
<heat> omg
<klange> chonky build
<heat> 56K build targets
<heat> and this is the /minimal/ system
<sonny> how big is the kernel in loc?
<klange> smaller than the rest of it
<heat> fax
<sonny> I would hope so
<heat> cloc fuchsia/zircon/kernel says "39455 45786 158852" so add those up
<geist> yah lots of rust compiles
<geist> if you want to jsut build the kernel `fx build zircon/kernel`
<heat> well it's not usable
<geist> the rust compiles are super chonky
<klange> it's taking longer to run `cloc` on the whole tree than it takes to build my OS :)
<heat> geist, i know, i'm not even at the rust compiles part yet lol
<sonny> I probably can't build it on my laptop then
<geist> yah you probably need a minimum of 8GB
<geist> 16GB to be comfortable
<sonny> :(
<sonny> I only have 4gb
<geist> there are a few rustcs that chew up 3-4GB at a time
<heat> depends on the number of threads you're using probably
<geist> and a few C++s that take 800MB or so, last i checked
<heat> the last time I built it I had a mechanical hard drive
<gorgonic-> Makes me wonder if that thermal printer on that r01 devkit I got could be a very rudimentary serial port or something
<heat> i'm curious if the ssd makes a difference
<geist> it will
<geist> though also depends onhow much cpu you have etc. but it can pretty quickly get to be io bound
* sonny thinkins about cloud compiling
<klange> gorgonic-: how's the keyboard?
<geist> yah we have goma to help C++ offload, but alas it's available to us only
<klange> oh right 6 month shipping delay, don't presume you've got one of the ARM models already?
<gorgonic-> the form factor looks like garbage, so i don't expect i'll be doing much with it
<heat> annoying: konsole shows me a square with the fuchsia color when I mouse over the word fuchsia
<gorgonic-> it's a slab type thing, so it'll be probably uncomfortable to use klange
<geist> gorgonic-: yah i kinda gave up on it when i saw how small it actually was
<klange> weirdly shaped, weirdly sized, weirdly arranged, and terrible materials
<bslsk05> ​www.clockworkpi.com: DevTerm Kit R-01 | ClockworkPi
<geist> it seems to be built around an allwinner D1, which you can get in other forms if you need a dev board
<gorgonic-> The main draw for me is definitely the finished product. I have been eyeing a risc-v board that was in my hobbyist price range
<geist> yah
<klange> and that's not just the keyboard, from what I've heard, the whole build quality feels cheap? damn shame, really, for what seems to be the first viable riscv platform that isn't "here's a bare PCB, good luck!"
gorgonic- is now known as gorgonical
<geist> i just fear the keyboard/screen aren't really usable
<klange> of course all of this is based on the ARM ones people haven't actually used, but the riscv model appears to be the same stuff with a different heart
<gorgonical> geist: I honestly expect they won't be. I just don't like the jumble of hooking up my sbcs to my monitors and playing this rat's nest game of cables, etc
<gorgonical> It doesn't even come with the 18650s you put in it apparently lol
<klange> 353232 text files, 254424 unique files ← that's a lot of dupes
<klange> (it's still counting)
<gorgonical> is there a reason that they call it a TF-card and not SD card? they're the same aren't they? Some copyright thing?
heat_ has joined #osdev
<geist> i dunno. i've seen that before too
<geist> usually when coming from china, so maybe they simply call it that
heat has quit [Read error: Connection reset by peer]
<kazinsal> iirc it was the original name for microSD
<geist> perhaps they're not allowed to call things 'secure'?
<klange> Retro™
<kazinsal> but microSD is like a trademark of sandisk or someone
<geist> yeah that's probalby it
<geist> it's probably like Coke vs Soda. a lot of us call it by some sort of specific trademark
<klange> SD-3C, the consortium of SanDisk, Panasonic, and Toshiba, owns the trademarks.
<kazinsal> always found the regional pop/soda/coke divide funny
<geist> yah, i grew up in a Coke Zone
<klange> But my understanding is they don't assert a word mark, just a logo mark...
bradd has quit [Remote host closed the connection]
<geist> "I'd like a coke please" "what kind" "Pepsi"
<gorgonical> Coke zone also
sonny has quit [Quit: Client closed]
<klange> So saying "this is an SD / microSD card" is fine even without full compliance testing and licensing, but slapping the CD-homage logomark on something is no bueno
<gorgonical> Growing up around there has left me with a permanent fear that when I order iced tea it will arrive sweet, even when I say "unsweet tea please"
<heat_> geist: have you noticed the build builds a lot of arm64 stuff on x64?
<klange> (it's still counting)
<klange> (it's almost done, though, I think it's on the long tail of what are presumably generated files)
<klange> It took 9m57s of real time to run `time cloc fuchsia` which counted 44460454 code lines
<heat_> that's horrible
<gorgonical> 4.5 million
<gorgonical> wow
<klange> no
<heat_> wonder if you could open things as O_DIRECT and read them that way
<kazinsal> as an evil communist frost devil, er, canadian, whenever I go to the states I often forget that ordering an "iced tea" does not usually result in a lipton brisk or nestea
<klange> 45 million
<gorgonical> oh man
<gorgonical> I misread. Lordy
Burgundy has joined #osdev
<gorgonical> kazinsal: I would file a formal complaint with my local Coca-Cola(TM) representative if that happened here
<kazinsal> we don't do the whole sweet tea thing up here
<kazinsal> kind of a shame, I do rather like it. on the other hand, it's best for my waistline that we don't
xenos1984 has joined #osdev
<gorgonical> I've lived out of the south a long time now and still have the force of habit. I reflexively ask if they have unsweet iced tea and they say "we *only* have unsweet"
<geist> heat_: yeah there's some reason for that
<kazinsal> it was like a novelty for me last time I was in vegas
<geist> and i dont remember what
heat_ is now known as heat
<gorgonical> I'm surprised they have it in vegas
<klange> For reference, this was from a _built_ checkout from two months ago, so a lot of that is the humongous tree of ports and build tools.
<gorgonical> Maybe I shouldn't be surprised they have anything there
<klange> And also generated stuff.
<klange> Like 10 million lines of JSON
<heat> do it again and exclude out/
<heat> see ya in 8 minutes
<kazinsal> walked into a mcdonalds to get an ultra cheap really large drink to stave off the 110 F heat and saw the enormous fountain drink machine that was *just* for sweet tea and thought "oh, wow, this explains everything"
bradd has joined #osdev
<geist> running it here, though it's on an NFS share so probably will take ages
<heat> why does *core* include spirv-tools and a bunch of compute stuff
<gorgonical> klange: First time I went to japan I was utterly baffled at having to say アイステー in mcdonalds and then receiving *earl grey* iced tea
<klange> f
<klange> that M7.3 last night was a doozy
<gorgonical> A nice idea, but the japanese interpretation of fast food tea is interesting
<gorgonical> Everything still okay around there?
<klange> Locally fine. Lots of places lost power, but we were okay. Less good up north closer to the epicenter - some train derailments, structural damage.
<gorgonical> yeah I though't you were reasonably far from it
<gorgonical> "though't" ??? Come on hands
<heat> thoughn't
<geist> heat: there's some vulkan stuff in there
<geist> there are gpu drivers in that
<heat> yeah I understand but I asked for *core*
<geist> there are gpu drivers in core
<heat> wait am I building the wrong target
<heat> wasn't there a bringup target?
<geist> there is a bringup target
<heat> fucc
<gorgonical> f
<geist> it's probably half the size
<heat> well screw it lets see how this goes
<geist> core has gotten fairly large, but it tends to build a lot of stuff. higher level builds liek workstation mostly add new shells on top of it
<geist> core is i think a fair chunk of the whole thing
<heat> being in the fuchsia discord made me want to see how fuchsia is going along
<heat> not workstation though fuck that lol
<heat> also made me want to contribute but I guess that's always hard xd
<geist> fwiw the cloc thing seems to mostly be cpu bound after an initial scan
<klange> i did want to try to get kuroko building for it
<geist> i'm seeing 100% and no wait time
<gorgonical> oh no I guess this means I have to finally get off my ass and start committing more time to my OS projects if I'm getting that devterm
<gorgonical> I'll lose chat privileges here otherwise
<heat> I heard heat's OS is pretty damn cool and has riscv support
<kazinsal> I still haven't written any vax code yet :(
<kazinsal> partially because the bootup state is pretty byzantine
<gorgonical> Hmm, I happen to remember meeting a guy that had access to a vax system or a vm
<kazinsal> somewhat varies between system to system so for different vaxen you need to throw different stuff at the front of your boot block to get it to think it's a VMS or something
<kazinsal> also you don't get loaded to a fixed location, it's just "512 bytes after good memory starts" or something bizarre like that
<kazinsal> so you've got to relocate yourself
<kazinsal> but you need to first figure out where you've been located to
<kazinsal> conveniently VAX seems to have PC-relative addressing for a lot of things
<geist> cloc finished. looks like about 36mil here
<geist> this clock utility is pretty neat
<heat> were you using a sundial before? :P
<geist> oh hoho
<klange> cloc is pretty nice, has some neat tricks
<klange> and you can teach it about new languages https://github.com/kuroko-lang/kuroko/blob/master/docs/cloc.txt
<bslsk05> ​github.com: kuroko/cloc.txt at master · kuroko-lang/kuroko · GitHub
[itchyjunk] has quit [Remote host closed the connection]
<klange> it also has an option to parse vcs data so it will scan only files from the original repository https://github.com/kuroko-lang/kuroko/blob/master/Makefile#L236
<bslsk05> ​github.com: kuroko/Makefile at master · kuroko-lang/kuroko · GitHub
<kazinsal> ooh, neat
<kazinsal> time to write an esoteric language just to add it to cloc
<klange> just contribute to kuroko, what's more esoteric than Python with declarations?
<heat> C with classes
<kingoffrance> that goes both ways :) pragma with C
<kingoffrance> you can just build preprocessors all day long
<heat> my cpu is at 89C since I started the build
<heat> i kinda feel bad for it
<geist> awww, poor thing
<geist> is it a laptop or a desktop?
<heat> laptop
<geist> i think laptops can have a higher tolerance
<milesrout> what is cloc
<milesrout> is it just for measuring lines of code?
<geist> it's an app someone linked before that does that yeah
<geist> but it's pretty smart, makes a whole table by files and whatnot it seems
<heat> i've seen the temps higher than this (90 somethings) but I guess it's not kicking in like that
<geist> seems to also detect symlinks, etc
<heat> it also gave up from turboboosting to max
<geist> heat: have you considered maybe the problem is... you?
<heat> its not you, its me
<milesrout> am I reading this right? fuschia has 45m lines of code?
<heat> 36m
<geist> a surprisigly large numer is JSON
<heat> can't wait for third_party/chromium
<geist> should run it on android. it's like an order of magnitude larger
<geist> though a lot of that are prebuilts
<heat> friendly reminder that android used to use make
<milesrout> the Linux kernel is 21m loc according to sloccount
<milesrout> 15m of that is drivers
<heat> is that literal code or just lines?
<gorgonical> drivers are the root of all evil
<klange> 113021 code lines a cross 548 files here :)
<heat> cloc separates comments, blank lines and code lines
<geist> even if it is jsut lines i wouldn't expcet it to be off by more than 20% or so
<milesrout> sloccount measures 'source lines of code'
<geist> and frankly, as far as i'm concerned, comment is code too
ElectronApps has joined #osdev
<milesrout> sloccount also does time and cost estimates - it puts Linux at almost $1b
<gorgonical> How dare you not think that m_narupcent isn't a self-documenting variable name
<geist> looks like zircon kernel is about 115kloc
<geist> that's about right
<geist> probably a few more thousand from shared libs out of that directory, but i think that's close
<klys> re: drivers are evil: drivers are zen, you just need a simple example to hack
<geist> interesting that LK that it was derived from clocks in at about 820kloc
<gorgonical> I actually don't mind drivers and such. It's the kernel that's evil. I recently wrote a virt timer driver for Linux and nearly cried. So poorly documented
<heat> Onyx minus ports is 780013 LOC
<geist> also yay someone bought that TRS-80 on craigslist so i no longer have an obligatino to get it myself
<milesrout> just read the code, what do you need documentation for? the worst thing in all of programming is overdocumented code. function header comments longer than the functions themselvs full of @param int x "this is the x coordinate" @param int y "this is the y coordinate" etc.
<geist> milesrout: wrong. wrong wrong wrong
<geist> that's always the argument people use when they say exactly what your'e saying
<heat> my kernel is 308 KLOC nice
<gorgonical> But really the code isn't the hard part. It's not about what the code does, it's what it interacts with and why it does what it does
<klys> yeah documentation isn't purely ecumenical
<milesrout> just grep
<heat> milesrout, do you read the libc's implementation when writing a C program?
<heat> do you go into glibc's printf()?
<geist> clearly useless comments are useless, but that's a reducto ad absurdum argument
<milesrout> i would if glibc weren't the most hideous codebase in the world
<milesrout> i've read musl's source code when writing a C program
<gorgonical> that's highly unusual for library usage, though
<gorgonical> the whole point is that it just does the thing
<heat> if only the functions were documented
<heat> oh wait
<geist> one of my experiences with tasteful and useful comments in code is it tells a reader who's skimming through it what they dont need to bother looking at
<heat> they are
<gorgonical> geist: exactly
<milesrout> and the other day I read munmap's implementation in linux when I wasn't sure about something
<geist> ie, yes, this loop can be figured out, but it takes 20 seconds, etc. but a one liner that says what hteloop does tells someone later, 'oh this isn't what i'm looking for'
<heat> so you go into the rabbit hole?
<geist> since real software engineering is almsot entirely maintaining existing things written by someone else
<klys> use the source, luke!
<milesrout> i agree that documentation can be useful
<gorgonical> re the timer, I had to basically parse the entire kernel timer system just to understand what function registers the timer and what exactly I do and don't need to call, just because the function I needed wasn't documented well
<geist> you're leaving little hints to other folks, little signposts
<milesrout> but i think that overly documented code is worse than underdocumented code as a general rule
<geist> sure, but that in *no* way is ana rgument for not using comments
<milesrout> comments that are out of date and misleading are worse than no comments at all imo
<gorgonical> maybe for productivity, but I don't agree for understandability
<geist> which is precisely what you started off with
<heat> leaving a doxygen function header is absolutely great for usability
<klange> I went all-in on doxygen/javadoc-style comments with Kuroko
<klange> and added a bunch of support for highlighting them nicely in my editor
<geist> yah i'm torn about it, but i can't complain too much
<geist> and some editors can collapse them too
<geist> (though that's a good way to let them get stale)
<heat> it's sooo useful when the editor/IDE can parse through them
<klys> collapsible editing is the thing I want to collaborate using
<milesrout> the thing is that good documentation is actually very hard. the majority of the time when I've opened up something "documentation" and i've seen it was doxygen I have been sorely disappointed
<geist> yah. of course i'm also talking about not just function docs. one liners describing blocks of code, with tasteful use of vertical spacing is a work of art imo
<bslsk05> ​developers.google.com: Technical Writing  |  Google Developers
<heat> technical writing is a skill
<gorgonical> geist: almost a la knuth's literate programming
<gorgonical> it can be incredible as a pedagogical tool
<geist> sadly that doesn't seem to be universal. i've bumped into folks that argue exactly things like comments are bad
<geist> i rarely see anyone argue for too many comments
<geist> so i feel like i have to be the bad person when doing code reviews sometimes asking for more comments
<geist> usually it's code blocks i see where it's not intrinsically obvious what it does at first glance
<milesrout> i used to work with someone who literally removed comments from existing code because he felt that all comments were bad and all code should be 'self-documenting'
<milesrout> which is strongly disagree with
<geist> yeah that is nonsense
<geist> i've talked to folks that work at companies where commenting is literally forbidden
<geist> my suggestion: run the hell away
<gorgonical> geist: oh my god
<geist> yes. it exists.
<Mutabah> Imma back away slowly
<Mutabah> No sudden movements around such unstable people
<geist> not for a good reason, simply what happens when lawyercats run the show
<gorgonical> Is this like a generational thing? How back in the day developing was just your code on your own machine, no regard for versioning or backups?
<geist> no it's a lawyer thing
<geist> as in comments are how you leak secrets, etc
<geist> (according to lawyers)
<CompanionCube> that's just stupid
<geist> anyway, it exists. sounds terrible
<milesrout> yeah it was nutty. he had a phd too, and was a good writer
<milesrout> we had professional technical writers there who wrote absolutely fantastic documentation for internal tools and technical docs for power users
<geist> unpopular opinion: compsci phds frequently aren't the best code writers
heat_ has joined #osdev
<geist> but that's simply based on my relatively small sample size
<geist> or at least recently graduated phds
heat has quit [Read error: Connection reset by peer]
<kazinsal> PhD: Pretty Heckin' Dumb
<gorgonical> As a phd in the last third of the program, I agree with you geist
<geist> haha :)
<milesrout> phds aren't about coding really well or anything so it shouldn't really surprise anyone that that's the case
<gorgonical> Advisors do not put much stock in good, repeatable code. Just what can be accepted for publication without a guilty conscience
<geist> yeah i mean it's not based on any particular reason, jsut that i've bumped into some pretty bad phd writers
<gorgonical> repeatable is not the right word. Maintainable
<geist> yah, the system doesn't select for those particular attributes
<geist> nothing some experience wont fix though
<milesrout> most of the time it's not really relevant how maintainable academic code is though: often the point is just to create a proof of concept of an idea
<geist> yah a friend of mine used to work in some sort of comp sci lab environment, literally maintaining a bunch of phds code
<geist> and that sounded awful
<gorgonical> milesrout: right. No company in their right mind would use paper code
<gorgonical> geist: I have been that guy
<gorgonical> It was awful
<geist> yah i assume every year some grad student forks the code, hacks it for their purpose and then tosses over fence
<geist> and now you gotta integrate it into the lab envirobnment
<milesrout> i think people (and I am as guilty of this as anyone) too readily apply their own standards to other people's work. if you are a pro then it's easy to look at academic code as "bad" because it wasn't built in the style and way that you'd build it for your needs, but easy to forget that it was built for different reasons
<kazinsal> I imagine there are hundreds of discarded forks of old versions of xv6 lying around github
<geist> milesrout: yeah totally
<heat_> xv6 is also horrible code
<gorgonical> Yeah isn't there an xkcd joke about other people's code and that gut feeling?
<klys> how to port isode quipu to linux using libc5 seemed to quickly turn into a project for virtuallyfun or similar since the 90s, and today there's 389-ds so folks aren't scrambling for isode anymore
<klange> xv6 is... more code archeology than an academic OS project
<geist> yah though to be fair i thought it was basically written more or less in teh same style
<geist> or at least to the same level of... completeness
<geist> as system V or so. though i guess that may be dissing system V
<gorgonical> okay here's something I have been grappling with for a long time that's partially been keeping me from really getting going with my projects
<heat_> you mean v6?
<klys> academic projects, there was one prof site I recall downloading ghostscript 3.33 jp version from, presumably his students were that familiar with ghostscript
<geist> i guess i tend to assume 70s and 80s unices are kinda trash fires by today's standards and that's probably really not fair
<geist> heat_: i dunno, i forget what it's a clone of
<heat_> it's v6
<gorgonical> I continually struggle with the desire to re-invent the OS in like a "clean room" way, as though I had never seen kernel code anywhere. It feels like I'm not "doing it" if I re-implement an OS I am familiar with
<heat_> system v is way more complete than unix v6
<geist> oh yeah i guess you're right
<geist> gorgonical: yeah that's a tough personal choice honestly. also depends on whatyou're trying to ge tout of it
<geist> personally i just like to make something out of nothing and run it on bare metal, so it kinda doesn't matter what the design is
<gorgonical> What do you guys think about that? Do you feel like your hobby OSes are from whole cloth, or largely inspired from existing OSes/philosophies that have evolved and grown in their own ways as you built them?
<geist> but some folks are going more for the purity of a new design, more of the theory of OS design than the actual implementation
<heat_> oh my OS is basically budget linux with a bit of fuchsia inspiration on top
<klys> gorgonical, recently I ran menuconfig on linux-5.16.12 and now it's running locally in a vm
<geist> i like to make useful thigns that people can use, which is what LK tends to do. it's simply what it needs to be to do what it does, doesn't follow a particular pattern except it's generally plain synchronous C
<klys> easy enough to do
<gorgonical> geist: my goal somewhat is the purity of "inventing" the OS, which sort of is what draws me to e.g. L4, kernels with specs I can refer to and build in my own way without a several million LOC burden
<klange> My original goal with my OS was learn by building. I _wanted_ to make a Unix-like because that was the thing I wanted to learn and understand internals of.
<geist> but yeah i got to help design large chunks of zircon so that also managed to mine a few ideas i had floating around
<geist> and that sort of helped get that out, but that's rare to be able to do
<gorgonical> klange: that's very interesting to me because you have in the past said you don't think toaru is really unix-y, unless I was misunderstanding you
<milesrout> i think learning by building is my main motivation in software as a whole tbh
<klys> at first you said it was a struggle to desire cleanroom os implementation and now you say it's your goal
<geist> but yeah, learning by building is mostly what i do
<klange> I was really inspired by a cliché interviewing question and wanted to build something that could demonstrate, line-by-line, the 'answer' to that question.
<geist> almost doesn't matter what i build, i just want to do it, and learn what others already did before by doing
<geist> so if that means reimplementing something, it's at least educatinoal that way
<gorgonical> klys: yes exactly, that's the paralyzing problem. I sort of want to do that, but doing it is not exactly trivial and makes me feel like I should study more, know more, etc. Design the whole OS in flowcharts and graphs and specs first
<geist> ah so that i dont have a good answer for gorgonical
<geist> sicne i simply dont think that way. i have no interest in flowchars and graphs and specs first
<gorgonical> But that's quite different from hobby tinkering and programming, which like geist is what I normally do, just solve a problem
<geist> that seems like hell
<heat_> I find that "as though I had never seen kernel code anywhere" thing interesting
<milesrout> recently i have been making an end-to-end encrypted chat program not out of any great desire to have one (there are lots already) but just out of a desire to understand how modern encryption works, modern protocol design, how signal's double ratchet algorithm really works in practice, etc.
<geist> milesrout: ooooh yeah that sounds fun
<heat_> everyone that wrote a kernel has looked at kernel code before I think
<heat_> which makes that a really tough ask
<gorgonical> heat_: I agree. So isn't there a nagging feeling of "am I just subconsciously re-inventing Linux"?
<geist> who cares?
<gorgonical> Do you have to intentionally not do what Linux does?
<geist> well, i think that's the problem. thinking about it in terms of linux is the mistake
<heat_> i'm not thinking in terms of linux
<geist> dont, think of linux has a source of ideas but that's it. it's not a competition
<heat_> just in terms of concepts in general
<gorgonical> well only because I am most familiar with it. I could say kitten or l4 or other, too
<geist> i think of linux as one of a pile of other oses, each with different ways to do a lot of the same things. and *that* i find fascinating
<geist> that's why i like different cpu architectures, old legacy 70s oses, etc
<heat_> if you just invented the concept of a kernel, how would you do things?
k8yun has joined #osdev
<milesrout> when i was a child i hated when my mother ever helped me with my homework, because she would always suggest ways of wording sentences. if I heard one way of wording a sentence, I couldn't get it out of my head, and felt very unoriginal. but objectively speaking, looking back, 99% of the wording was still my own.
<milesrout> so i understand the feeling of 'i dont want to look at that implemenation, i want to have my own ideas'
<geist> it's kinda like approaching music from the point of view of 'all the songs have been written'
<gorgonical> milesrout: a very interesting analogy
<geist> but not saying you dont have a valid thing, i think we're just trying to kick you out of the rut you'rein
<klys> milesrout, you reminded me of some of my own code, http://show.ing.me/hmce-v0.11/05nov2016/queue.h.nl.txt
<geist> since ruts are a real thing and eveyrone has a problem one way or another with them
<geist> the lack of getting started is a big one i've seen here. another huge rut is 'make the best bootloader ever'
<klange> perfect is the enemy of ~~good~~ existing at all
<geist> a variant of 'implement step A, iterate on A until it's perfect, then implement step B, repeat'
<geist> and the you never get out of iterating over step A
<milesrout> klys: what was this for?
<heat_> oh yeah definitely, I'm not saying it's something you should strive to do, because that's essentially impossible if you've ever like read something about OS design ever
<klys> milesrout, a concurrent edit session over ip multicast
<geist> my take is i like to read about *all* the OSes, see how they all work, and then see what the different strategies are
<geist> same with cpu arches. i think that gives you a lot of perspective that comes in handy
<milesrout> oh have you read about CRDTs?
<klys> I have not
<gorgonical> I have finally just found those emails about the VAX stuff. I thought I had lost that contact, wow
<heat_> geist, defo, just wondering if someone right now started with a completely clean slate would make a new interesting design or if the clean design would eventually converge into our "normal" stuff
<milesrout> from what I remember they're all about how you have two or more entities concurrently editing a single document while always being able to merge their changes in a good way. it's a concept used by google docs and other collaborative editing software
<milesrout> if that's what you meant by concurrent edit session
<heat_> kinda philosophical I guess
<milesrout> if it isn't then um, sorry for the irrelevant comment >.<
<geist> heat_: seems like that's the same general problem of thinking about linux too mcuh
<geist> actually i dunno, i think with the rise of virtualization hardware you can probably build something fairly unique nowadays
<geist> something that *really* takes advantage of it at a core level
<heat_> i'm not thinking about linux I think
<geist> no but i mean the premise of the question was 'would it end up being like existing things' and the answer is 'dont compare it with existing things'
<milesrout> or reading a single author too much if you're trying to write a book. i remember as a child reading one or two fantasy series over and over, not very broad reading, and whenever i tried to do creative writing it would always just be regurgitating some combination of lotr and harry potter.
<geist> which was a snarky answer so i retract it
<heat_> if nobody told you how memory allocation would look like, how would it look like?
<milesrout> if you 'read broadly' in terms of software you'll write broadly too
<milesrout> you'll put things together from disparate areas
<gorgonical> heat_: but, you sort of can't answer that, can you? You already know how some solution accomplishes it
<heat_> yeah I can't
<milesrout> "oh that's an interesting idea from X but what about this other idea from Y? How would they work together?"
<gorgonical> So are you really designing your own solution?
<heat_> this is truly a philosophical question
<gorgonical> indeed
<geist> similar to music, i thik it'd be hard to write a truly new form of music having heard existing stuff
<heat_> unless we got someone that had *no idea* what they were doing and made them write an OS
<milesrout> im pretty sure if i had to invent memory allocation from scratch i'd do a bloody bad job.
<geist> if nothing else because you've hard particular scales imprinted on your brain
<milesrout> so i'm quite happy to steal someone else's algorithm
<gorgonical> right. I suppose especially you could take an esoteric approach and sort of like playing a game with extra constraints, you could build an OS intentionally with unusual design choices
<gorgonical> Just to see what would happen
<geist> milesrout: exactly. there's also *that*. which is that in most cases not considering prior art means you're doomed to make all the mistakes and fail to optimize
<gorgonical> Don't build the "right" OS, build a different one on purpose
<geist> well, to be honest, if you *did* then you'd actually do something at least
<kingoffrance> "Just to see what would happen" there was a nick named emacsomancer
<gorgonical> templeOS comes to mind as an example of doing something in a very strange way "for its own sake"
<geist> a few years ago for lulz i sat down to write a little kernel that ran on a 386, using 386 hardware. tried to use the state of the art at the time hardware weise (TSS task switching etc)
<geist> was it a waste of time? probably, but it was fun and a fun experience
<heat_> gorgonical, templeOS is pretty sane in terms of kernel concepts
<heat_> s/kernel/core/
<milesrout> the most bog-standard, derivative, uncreative (bad) UNIX clone of an OS project is still going to be more interesting than my pile of unimplemented (and probably unimplementable) ideas, I suspect.
<geist> possibly, though to be honest i dont think i'e ever seen anyone talk about if it has reasonable task switching (or task switching at all) or memory management, etc
<gorgonical> I know it's mostly like... a c64 clone? But there are a lot of strange choices, like the command-like c interpreter, terminal rendered graphics, etc
<heat_> but yeah exactly as geist was saying, JUST DO IT
<geist> i *think* it's non paging, etc
<milesrout> actually MAKING something is hard enough without forcing yourself to be super creative in every element at the same time
<geist> yah that's a recipe for indecision
<gorgonical> you all have very good points and I'm glad I asked
<CompanionCube> iirc paging was on the divine 'forbidden' list
<geist> setting the activation energy too high
<geist> CompanionCube: well there you go
<gorgonical> CompanionCube: one address space, indeed
<heat_> the only point I have is the JUST FUCKING DO IT
<milesrout> activation energy that's a good analogy
<heat_> you're a software engineer not a philosopher
<CompanionCube> same list that mandated 640x480 as the One True Resolution.
<milesrout> don't let your dreams be dreams </labeouf>
<gorgonical> and that networking was evil
<geist> MODE X or GTFO
<heat_> damn right
<heat_> networking is evil
* kingoffrance grabs basilisk and points at gorgonical ...is there immunity, or will it create sparks?
<heat_> the fuchsia build did the thing
<heat_> real 99m35.266s
<milesrout> to be fair it is interesting to see what you can get if you drop constraints like networking and all the security implications that come with it
<geist> heat_: that's about right. on this 8 core 16GB ryzen VM i think it's about 30m
<heat_> 2GB of swap and the machine didn't freeze!
<milesrout> because those problems heavily constrain the way modern software is built without, to be honest, actually giving us that much security
<geist> see swap is not all evil
<milesrout> any program i run could, after all, simply send my pgp key and all of my emails anywhere on the cloud.
<geist> well i mean i did grow up in the era when you put your stuff on a floppy disk and your computer ran a program
<geist> one at a time to deal with your data on the disk
<geist> it was... a simpler timer
<geist> time even (haha timer)
<gorgonical> heat_: I do broadly agree with this. I think, honestly, human productivity with computers has gone down because of ubiquitous networking. You pollute the notion that the computer is for work, and you instead browse the internet. It was better when you had only webrings and had to wait several minutes to download gifs
<gorgonical> Genuine opinion
<heat_> oh no I love the internet
<heat_> it's just complex and hard
<heat_> :P
<gorgonical> search was a mistake
<milesrout> internet bad! return to monke
<gorgonical> We have to go back
<heat_> if you hate searching you could try using bing
<milesrout> they're probably better than google these days
<heat_> you'll never find anything with that
<klys> well find a way to run a business without catering to search
<gorgonical> I already unduly burden myself with the alternatives. I use mojeek when I'm feeling extra
<milesrout> the quality of search results has plummeted
<gorgonical> milesrout: agreed. You have to verbatim search just to guarantee you don't get a whole page of sponsored ads these days
<milesrout> half the time i google things and some of the top results are websites that are obviously just copy-pasting stackoverflow answers
<gorgonical> I remember discovering a software reversing page written by some guy, ben woods (?) who maintained this sort of thing all on his own. Extremely 90s page, but contained so much useful information
<heat_> geist, reminds me of the time where I installed svr4 on a VM, my only experience with floppies :P
<gorgonical> Modern-day google would never in a million pages return that guys page anymore
<geist> heh to relive the experience i installed an early slackware on my 386 via floppy a few years back
<heat_> I have accidentally looked into SVR4 source code and I'll have to say, the source looks pretty damn legit
<geist> took forever. something like 30 floppies
<heat_> it's 4.4BSD-esque
<heat_> which in turn, is FreeBSD-esque
<heat_> things didn't change that much :P
<milesrout> to be fair gorgonical I just tried to do something similar with a website i was sure would be unfindable on modern google
<milesrout> and it was the first result >.<
heat_ is now known as heat
<milesrout> so it's not all bad
<geist> yeah i always diss on 70s and 80s era unices but they were probably pretty solid by early 80s at least
<gorgonical> holy moly other's know about this site, it was woodman. And it is lost to time because of no archives. :(
<geist> probably was just this general notion that non unices were much more SRS BSNS at the time, ie VMS
<milesrout> if you google "picking x86 registers" do you get the swansontec 'art of picking intel registers' page?
<geist> and really hell, VMS kernel was written in assembly
<milesrout> is this a personalised result for me?
<gorgonical> I get it, too
<geist> same
<geist> but we're probably all in the same bucket
<milesrout> yeah probably
<geist> anyway off i go
* geist wave
<milesrout> cya later
<heat> geist, the only thing is that old unix's C syntax is weird and they're all alergic to comments
<klys> tah-tah-tah
<heat> it's 7am and I have not slept
<heat> i should go too lol
<heat> cya
<milesrout> i wish you could write float foo(float x, y, z);
* klys ~
epony has quit [Quit: QUIT]
<milesrout> i think old unix definition syntax had something like float foo(x, y, z) float x, y, z; { /* body */ } or something, right?
<klys> those are declarations optional to a function definition
<kingoffrance> k&r
<kingoffrance> old programs would also convert (with macros or otherwise) so you could compile with ansi c or k&r compiler
<kingoffrance> *build system for programs
<milesrout> at least you don't have to write float 3 times :D
<kingoffrance> oh, that in particular , i dont know
k8yun has quit [Quit: Leaving]
heat has quit [Ping timeout: 250 seconds]
<kingoffrance> you were asking about something useful...
<klys> try it
<CompanionCube> also must declare vars at start of function until C99
* kingoffrance <--
<gorgonical> CompanionCube: that error message drives me absolutely up the wall
<gorgonical> "C99 forbids mixed declarations and code"
<kingoffrance> 89
<gorgonical> shows how much I actually listen to what the compiler tells me
<kingoffrance> i wouldnt recommend it unless you plan on "parsing" or "generating" i.e. do forbidden things with pragma
<milesrout> i loathe mixed declarations and code personally
<kingoffrance> i find it funny though, people who dont like multiple returns, strangely dont seem consistent on that
<kingoffrance> i dont know whats better for a human, but for code it seems easier they are all in one spot
<milesrout> and i dont like #includes in headers or header guards
<gorgonical> milesrout: I agree with you, but often when prototyping and iterating I move stuff around and this makes -Wall -Werror very angry
<milesrout> I'd suggest not using -Werror until just before you commit, at the same time you run a linter
the_lanetly_052 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
ThinkT510 has quit [Quit: WeeChat 3.4]
ThinkT510 has joined #osdev
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
the_lanetly_052 has joined #osdev
MrBonkers has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
MrBonkers has joined #osdev
garrit has quit [Ping timeout: 240 seconds]
garrit has joined #osdev
dormito has joined #osdev
gog has joined #osdev
epony has joined #osdev
Burgundy has quit [Ping timeout: 240 seconds]
dormito has quit [Ping timeout: 252 seconds]
Belxjander has joined #osdev
ElectronApps has quit [Remote host closed the connection]
GeDaMo has joined #osdev
ElectronApps has joined #osdev
dormito has joined #osdev
elastic_dog has quit [Ping timeout: 240 seconds]
dennis95 has joined #osdev
Burgundy has joined #osdev
joe9 has quit [Ping timeout: 256 seconds]
divine has quit [Ping timeout: 240 seconds]
divine has joined #osdev
paulbarker has quit [Quit: Connection closed for inactivity]
elastic_dog has joined #osdev
lkurusa has joined #osdev
dormito10 has joined #osdev
dormito has quit [Ping timeout: 250 seconds]
bliminse has quit [Quit: leaving]
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
nickjacklittle has joined #osdev
nickjacklittle has quit [Quit: WeeChat 3.0]
[itchyjunk] has joined #osdev
lkurusa has quit [Ping timeout: 250 seconds]
bliminse has joined #osdev
lkurusa has joined #osdev
srjek has joined #osdev
joe9 has joined #osdev
blockhead has quit []
nyah has joined #osdev
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
mahmutov_ has joined #osdev
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
ElectronApps has quit [Remote host closed the connection]
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
<mrvn> klange: does you clock show micro fortnights?
dude12312414 has joined #osdev
phr3ak has quit [Ping timeout: 256 seconds]
phr3ak has joined #osdev
<gog> lol
sonny has joined #osdev
terminalpusher has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
srjek has joined #osdev
fkrauthan has quit [Quit: ZNC - https://znc.in]
fkrauthan has joined #osdev
sonny has quit [Ping timeout: 256 seconds]
lkurusa has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 252 seconds]
sonny has joined #osdev
pretty_dumm_guy has joined #osdev
dennis95 has quit [Quit: Leaving]
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
eck has joined #osdev
terminalpusher has quit [Remote host closed the connection]
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
Oli has joined #osdev
sonny has quit [Quit: Client closed]
Oli has quit [Ping timeout: 256 seconds]
heat has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
Oli has joined #osdev
garrit has quit [Remote host closed the connection]
Oli has quit [Ping timeout: 256 seconds]
sonny has joined #osdev
Oli has joined #osdev
Oli has quit [Ping timeout: 240 seconds]
not_not has joined #osdev
<not_not> Hey hey
sonny has quit [Quit: Client closed]
sonny has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
Oli has joined #osdev
Oli has quit [Ping timeout: 256 seconds]
Oli has joined #osdev
<sortie> You you
<heat> fx serve is probably the greatest thing ever invented ever and I need it now
<GeDaMo> What's "fx serve"?
<sortie> Nothing much, you?
<GeDaMo> :|
<heat> it's a fuchsia developer command where you let it run and it serves packages to the vm/device you have running
<j`ey> so just a http server or?
<heat> meaning you can make changes, build, run them, make more changes, build them, and then serve them just like that
<heat> j`ey, I think it's all ssh
<heat> or maybe a proprietary protocol? dunno
<j`ey> they just auto update on the device?
<CompanionCube> i wonder if nixos has something similar
<heat> i think so?
<bslsk05> ​fuchsia.dev: fx serve  |  Fuchsia
<heat> they also have this thing where (some? all?) packages don't exist until you run them (they're just files with a shebang)
<bslsk05> ​github.com: fuchsia/fx.md at master · vsrinivas/fuchsia · GitHub
<bslsk05> ​'A Tour of the Fuchsia Operating System | Rubber Duck Engineering | Episode #57' by RubberDuckEng (01:03:16)
<heat> I used to mount my disk image, copy everything over (with sudo!), and unmount the partition, then run qemu
<j`ey> that's what I still do for some stuff heh
<heat> now I just overwrite the disk image by flashing a partition over the root one
<heat> but having fx serve is probably way cooler
<heat> you don't even need to re-run qemu or anything
<heat> they also have this thing where their build tool detects changes in source files and rebuilds it
<heat> which means you can literally do nothing except writing code and trying it out
<sortie> I use this cool program called ssh for controlling my VMs
<heat> i don't have ssh :(
<sortie> Ah it's p cool, you're allowed to share the sources, I can send you mine
<heat> my workflow on real hardware is "get flash drive, dd, insert flash drive onto target machine, boot into grub, go to firmware, boot into the flash drive, see if broken"
<heat> my test laptop's keyboard is also completely busted which makes typing really fun
dormito has joined #osdev
dormito10 has quit [Ping timeout: 240 seconds]
sonny has quit [Ping timeout: 256 seconds]
sonny has joined #osdev
blockhead has joined #osdev
dude12312414 has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
<gog> hm strangeness with uefi, was throwing #GP every other test run but now it's working?
<gog> ¯\_(ツ)_/¯
<gog> i changed a bunch of things so it's possible theres a UB/IDB thing going on that i missed
<gog> but i can't even reproduce it
<mrvn> That's what git is for
sonny has quit [Quit: Client closed]
sonny has joined #osdev
GeDaMo has quit [Remote host closed the connection]
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
srjek has joined #osdev
_xor has quit [Ping timeout: 256 seconds]
nyah has quit [Quit: leaving]
sortie has quit [Quit: Leaving]
nyah has joined #osdev
_xor has joined #osdev
<gorgonical> Has anyone here not taken the incremental approach to OS building? Instead of getting/building a bootloader, then getting a kernel to some kind of code execution, building it out from there. Has anyone taken the approach of e.g. defining syscalls and then writing the kernel from that point?
<jimbzy> I just slapped crap together until it partially worked.
<gorgonical> As I was forming that message it started sounding dumber and dumber, but it's an interesting idea, sort of like test-driven development. The kernel is done when it does what the syscall says it should do sort of thing
<bslsk05> ​wiki.osdev.org: Unit Testing - OSDev Wiki
__xor has joined #osdev
g1n has quit [Quit: WeeChat 2.8]
<mrvn> gorgonical: Kind of. Just not top down
<mrvn> TDD kind of requires that you can run the syscall stub and have it fail as first iteration
<gorgonical> that's true
<gorgonical> So you at least need some kind of syscall handler. A bit of a chicken and the egg problem
<mrvn> So first step was to get to have a userspace process that coul try to run syscall
_xor has quit [Ping timeout: 240 seconds]
<mrvn> gorgonical: nah, just syscall and watch it blow up
<gorgonical> lol
<mrvn> then make it fail with ENOSYS
<mrvn> Part of TDD is making it actually fail.
<gorgonical> I actually really like TDD for small, contained problems
<gorgonical> For me it starts to break down as complexity scales. But maybe I'm not approaching my problems the right way
<heat_> you could try to run your OS in user-mode for now
heat_ is now known as heat
<gog> sounds more like contract-driven development
<mrvn> gog: contract-driven does start with the unit test
<mrvn> doesn't
<gog> hm
<mrvn> test driven is basically one level on top of contract-driven.
<gog> right but what gorgonical said was like making a specification and then designing to that specification
<gog> or rather developing until the specification is satisfied
<mrvn> I think with test driven you have a more step by step approach. You don't flesh out all of the contract at the start but just a bare minimum of it. Then implement this. Then flesh it out more with the next test.
<gorgonical> mrvn: that's how I understand TDD. But I guess gog was right about my spec idea
<gorgonical> A riff on yesterday's "clean room design" thought
<mrvn> So it would be more: I want a syscall. Ok, now I want it to do something. Now I want different syscalls, ....
sonny has quit [Ping timeout: 256 seconds]
<mrvn> ... hey, I have POSIX
<jimbzy> They make a pill for that, mrvn.
<mrvn> red or blue?
<gorgonical> yellow, actually
<gog> they used to be red, they're more teal nowadays
<gog> also i can't make this gp happen again and idek why it was happening
<gog> guess i'll just move on
__xor has quit [Ping timeout: 256 seconds]
<jimbzy> Fuchsia.
<gog> bless you
<raggi> heat: the package server part of `fx serve` is just an http server essentially, it hosts a repository that is based on "the update framework", each package is a tuf target in the repository that resolves to a merkleroot (sha hash) of the "pacakge metadata". there's an extension in the developer package server at /auto that the client subscribes to that tells it (over SSE) whenever the repository is updated
<raggi> heat: the #!resolve stubs for shell programs are a bit of a hack/magic that i implemented mostly to get commands out of what was previously a global /system, it's intercepted in exec in libc and resolved through a fidl protocol that requests the binary and a loader service channel for the program, and will do that recursively until it no longer contains a #!. the api that it calls to resolve to a binary and loader service is the thing that triggers package cache
<raggi> updates if they're needed
__xor has joined #osdev
<heat> raggi, can you run something like fx serve over something like serial or something like that?
<heat> in case there's no networking
<raggi> in theory yes, there's an implementation of overnet over serial, `ffx` which is the in-sdk version of 'fx' essentially, can serve repositories over that implicitly - right now, or at least when i left (i left fuchisa/google last week) there was still some more work needed to get overnet serial transports ready for use again, as an earlier prototype had bit rotted slightly
<raggi> we also discussed, and i really wanted to see, implementing an overnet over usb bulk transport too, as networking always introduces extra pains
<gorgonical> wait, how do you mean? like using usb for general purpose interconnect?
<raggi> yep
<raggi> and specifically just using an arbitrary bulk transport endpoint, so that on host systems you can use it without a special driver, from userspace
<gorgonical> I wish I had more competence than I do. Implementing a networkish protocol on USB just because I can sounds hilarious
<heat> well it's genuinely useful
<gorgonical> Sort of like plumbing it into a pipe?
<raggi> overnet already has several layers of reliabiltiy and framing, so pushing it over bulk transport frames is pretty trivial, the work to make that all happen is pretty much just glue
__xor is now known as _xor
<raggi> (and driver boilerplate)
<heat> ethernet, serial and usb are all just slightly different kinds of beep boop
<gorgonical> does overnet refer to something particular? the edonkey protocol?
<raggi> it's a fuchsia thing
<gorgonical> oh
<raggi> it's basically fidl [as a & over] a mesh network
<geist> gorgonical: yah, usb is actually pretty good for this sort of thing
Oli has quit [Quit: leaving]
<geist> if you have say a pair of bulk USB endpoints you can plonk down packets with well defined boundaries
<geist> and retransmit, error correction, etc so it's somewhat nicer than even ethernet in that case
<geist> build whatever packet based protocol you want on top of it
<raggi> yeah, and you mostly don't end up with corp firewall issues and such.. yet
<geist> years ago at palm i wrote a thing called novacom that did a lot of what overnet does. the source is open so i've actually used it in LK
<geist> basically builds a tcp like multiplexor on top of <insert transport here> but mosty usb
<geist> kinda an alternate form of ADB on android
Burgundy has quit [Ping timeout: 240 seconds]
<klange> mrvn: no, it shows regular seconds :P
<heat> i was thinking about doing something similar on top of serial but i guess that's kinda too slow
<mrvn> heat: sending 4k video over a 9600 BAUD link is fun, for hours and hours.
<heat> i don't have USB and I don't trust my network stack all that much
<geist> i've always meant to implement slip. might be a fun weekend hack
<geist> need to beef up my network stack to properly deal wih more than one nic and then fiddle with this sort of thing
[itchyjunk] has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
<heat> trying out fuchsia gave me a lot of ideas
<heat> (well, re-trying out)
<heat> I also *love* the console's font
<klange> mrvn: hours and hours per frame?
<mrvn> klange: got it in one
lkurusa has joined #osdev
lkurusa has quit [Quit: Textual IRC Client: www.textualapp.com]
mahmutov_ has quit [Ping timeout: 240 seconds]
srjek has quit [Ping timeout: 260 seconds]
sonny has joined #osdev
<sonny> wait are we talking about top down os design?
xenos1984 has quit [Read error: Connection reset by peer]
<mrvn> sonny: too late, you missed it
<sonny> maybe next time then
<sonny> how do you debug an OS kernel?
<klange> lots of printfs, tbh
<sonny> hmm
<sonny> ok
<mrvn> gdb works too with some stubs
<klange> or just with qemu, no stubs needed
<sonny> I'm also thinking when you finish your OS, you'd probably want some way for users to debug stuff
<klange> ... finish?
<sonny> complete
<klange> ... complete?
<sonny> ok well I spelt that one correctly
<klange> You spelled both correctly, but neither is a concept applicable to an operating system.
<kazinsal> I suppose you "finish" working on an OS by shuffling off this mortal coil and leaving it in someone else's care
<sonny> It's possible, iirc wirth did project oberon in 3-4 years
<j`ey> was it bug free?
<kazinsal> did anyone use it
<klange> Releasing a v1 isn't the same as completing something.
<klange> Oberon continued to be developed beyond that, and is still maintained.
nyah has quit [Ping timeout: 252 seconds]
<heat> developing an operating system never ends
<sonny> why?
<klange> There's always going to be new hardware to support, new platforms to port to, new functionality to provide.
<heat> it's a never ending cycle of sadomasochistic pain and enjoyment
xenos1984 has joined #osdev
<kazinsal> new ways people find to break stuff
<sonny> new hardware is just driver dev?
<j`ey> sonny: whats your cefinition of done?
<heat> driver dev is os dev
<sonny> ah
<j`ey> definition
<kazinsal> faster hardware requires better low level I/O systems to fully take advantage of
<heat> nothing ever ends ever
<kazinsal> which is a kernel problem, usually
<sonny> all the interfaces to describe the operating system are complete
<klange> Lots of classes of software these days are never truly finished, there just comes a day when they stop getting updates.
<heat> ^^linux(developed since 1992, and never finished) has semi-recently had a bunch of improvements to the IO stack in order to get a lot more IOPS for really fast devices
<heat> sonny, new system calls are created all the time
<heat> that is not true
<j`ey> heat: that was the definition of done i asked for
<sonny> like io_uring?
<heat> yes
<sonny> something about futex
<heat> futexes are old
<heat> but now you have futex2
<heat> an improvement over the original futexes
<sonny> I see
<heat> linux is never finished, and never will be
<sonny> So osdev really favours a dynamic language ... to accommodate such changes
<heat> what
<sonny> it's a dynamic system
<j`ey> no?
<kazinsal> you're doing changes like these over time, not magically instantly
<kazinsal> and these kinds of changes are major API revisions
<sonny> ah
<heat> it's dynamic in the sense that it will always keep changing but you're not changing them while you're running (unless you are, but that's hacky)
<moon-child> operating systems _are_ dynamically typed. But that doesn't mean that they should be implemented in a dynamically typed language
<kazinsal> you don't just retroactively make all I/O use io_uring or kqueue or whatever
<kazinsal> that's impossible
<sonny> I like to dream
<moon-child> kazinsal: people do wild stuff with long-running cl and erlang processes
<heat> sonny, you should type some code
<sonny> yep
<heat> you would understand why osdev n e v e r e n d s
<sonny> I'm trying to figure out clang in visual studio, I will probably read intel manuals after
<sonny> will probably be a while before I get going
<heat> tip: don't use visual studio
<heat> tip: no one ever reads the intel manuals front to back
<sonny> it's an unrelated task
<sonny> I know, but I'd still like more than surface level knowledge
<jimbzy> The old printed ones made great stops for windows and doors.
<sonny> the key will be understanding the abi and file format
<heat> you're not getting more than surface level knowledge if you're reading a big spec like that front to back
<klange> jimbzy: good monitor risers
<jimbzy> Yeah!
<heat> sonny, that's not part of the intel manual
<sonny> sysv abi?
<heat> yes
<sonny> oh
<jimbzy> I've been saying that about programming books for years, heat. Like, who can read the C++ Primer and memorize the entire language? I'm sure there are some exceptional people out there with the talents, but is it necessary?
<heat> agreed
<heat> i'm a strong believer in learning by doing
<klange> most of what its language specs is irrelevant to programmers using the language
<klange> what's in*
<heat> as I think most people here are
<klange> literally why my OS exists
<jimbzy> I agree.
<heat> my OS only exists because 5th grade me wanted to learn how to make an android app
<jimbzy> I argued that with kids in my classes, too. "Teach me how to program"
<j`ey> heat: and you still dont know!
<heat> i still don't know how to make an android app
<j`ey> :)
<heat> i know how x86 cpus work though!
<jimbzy> I can do it with the Godot game engine, but that's clicking "Export"
<jimbzy> heat, Magic?
<jimbzy> I'll bet it's magic.
<mrvn> jimbzy: With c++98/11/20 you have to forget a lot of old cruft
<jimbzy> Yeah, I ran into that coming from Old C++
<mrvn> worse if you come from C
<mrvn> basically forget about x[]
<jimbzy> yeah hehe
<jimbzy> You should have seen me trying to learn C#
<jimbzy> My professor was like, "Stop this nonsense!"
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<geist> nice did you write an OS in perl?
<sonny> yikes
<geist> years ago i remembe someone came in here totally proud of their OS written in perl
<sonny> most line noise lang ever
<geist> we were tryig to be nice, but it was literally a little app that pretended to let you log in, etc
<jimbzy> No, but I did submit some assignments with some geometrically irregular forms and he stopped answering my emails for a while.
<sonny> lol
<sonny> oh, I thought they went hardcore and used the perl ffi
<klange> instead of laughing, tell them that's a Desktop Environment
<heat> jimbzy, it's not magic but it's kotlin
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<heat> which is kind of like magic
<geist> hah no it was like print "login: " and then let yu type something, and then checked your password, etc
<jimbzy> That's how I did my first "OS" back in the day in Qbasic.
<moon-child> so it's a login(1) implementation!
<geist> also reminds me of that person that maybe in 2005 came here with some bootloader thing
<jimbzy> Then I joined this channel and realized how stupid I was.
<klange> did it actually use a hash?
<klange> if so it's better than my login
<geist> and then gave the channel a root login to debug their disk image
<geist> ike, uh, bad idea
<heat> nananna
<heat> hahahhahahaha
<moon-child> lol
<jimbzy> I actually remember that.
<geist> yah we were like bad idea and sure eough someone logged in and trashed their drive
<moon-child> oof
<jimbzy> Dang, that was like back in the Aughts
<geist> yah thinking like 2005 maybe?
<klange> before my time
<jimbzy> Sounds about right.
<klange> i always feel weird using that phase to refer to things that happened when I was alive but before I was involved in a thing
<jimbzy> I'm pretty sure I was still in CA at the time and I moved in late 05
<heat> i could count to maybe 4 in 2005
<jimbzy> Younglings.
<geist> to be fair i dont think they actually gave out their root password
<geist> they were just using BeOS so The login was root imlpicitly
<klange> I don't think I have any surviving code from 2005, that would been mostly TI and Visual Basic era for me, _maybe_ some C#?
<klange> The stuff I have on github only seems to go back to 2008.
<jimbzy> Dang. I've been coming here a long time I guess.
<geist> jimbzy: yah you and air are the oldies
<heat> i've been a regular here since december 2015 I think
<jimbzy> Back when the Hiptop threatened to disrupt the world.
<klange> Surely you mean theSidekick?
<jimbzy> Nope
<klange> Was there even a market it was sold under its OEM name?
<jimbzy> I have no idea, but I remember geist giving us the scoop.
<geist> hiptop was our name. tmobile called it Sidekick
<geist> it sold in some other markets as hiptop
<jimbzy> When was that? '01 or '02-ish?
<geist> i think tmo had the exclusive in US
<geist> somewhere around there yeah
<geist> i think we launched in 01 or 02