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=1&d=5

Wednesday, 5 January 2022

00:00:00 <moon-child> sure. But fast rendering means it happens a lot less in practice
00:00:00 <klange> That's why I'm getting out of this game. The ceiling is too high and you will never get close to it. Doing things from scratch, you'll never even approach the state-of-the art.
00:00:00 <moon-child> and: it doesn't come up so much outside of graphics, because you don't have much of a choice: you have to retain coherent state
00:00:00 <moon-child> only in signal processing can you cheat
00:01:00 <moon-child> klange: I think you pushed a lot closer to the ceiling than pretty much anyone else
00:02:00 <zid> signal processing being "anything that interacts with a user or another computer" :P
00:02:00 <zid> clearly what we need is tcp window scaling, but for.. window events
00:02:00 <zid> window window scaling scaling
00:02:00 <zid> so that your window scale events can scale
00:03:00 <moon-child> lol
00:06:00 <geist> yah the whole flying too close to the sun thing
00:06:00 <geist> thats always been my ceiling. i reallt only like to do kernel stuff, so at some point your kernel gets 'good enough' that any additional work is just polish
00:06:00 <geist> or extreme diminishing returns and/or just adding more instability (simple code is easier to debug, etc)
00:07:00 <kazinsal> yeah, at a certain point you end up tracing bugs through dozens of modules and it starts to become really unfun
00:07:00 <zid> That's why I never have goals
00:07:00 <zid> goals are evil, just do what's fun
00:11:00 <klange> I am glad I could get 2.0 out and meet the two main goals for it (64-bit, SMP) as well as clean up the kernel with the rewrite, even if it does still have disastrous bugs around signals.
00:13:00 <klange> But after ten years of trying to take a hobby and turn it into a career, without success and with a stark reminder of the futility of this work in achieving that goal...
00:14:00 <klange> ... combined with feeling like I'm back to the point where it's just a grind - more device drivers that to do the same things, struggling with that "90% done, 90% to go" march towards compliance with standards...
00:15:00 <klange> ... it's just time to focus on something else that still has that spark of fun for me. Right now that's my Python clone and my editor, both of which were projects that came out of the OS so it's not all a complete loss.
00:19:00 <klange> It's... quite a contrast, working on these things that are actually viable. I use my editor constantly, it uses my language for syntax highlighting. These are things I have put far less time into compared to the OS, but they are already usable. The barrier to entry for having a useful thing is so much lower.
00:21:00 <Clockface> that is encouraging
00:24:00 <Clockface> the
00:24:00 <Clockface> bit about useful things being far quicker than the reimplementations of things
00:26:00 <Clockface> i misread that, crap
00:26:00 <klange> It's not even the reimplementation of things. I think it's just... operating systems as a whole. It's not a place where you can reach viability with hard work and persistence. It was in the 90s, when Linus started on Linux, but it's not any more. And it applies to platforms in general - browsers are the new thing.
00:28:00 <klange> There was a time when you could reasonably browse the web in one of the hand-built text-mode browsers, or Netsurf, or any of a dozen engines. Now there is zero chance of every building a new browser engine from scratch that will ever work well enough to matter, even Firefox can't keep up.
00:29:00 <klange> Categories of things that have escaped the realm of mere mortals.
00:29:00 <moon-child> I know somebody who was working on a browser back in the early 2000s or so
00:29:00 <moon-child> unsurprisingly, he no longer works on it :P
00:29:00 <Clockface> its like working on a nuclear reactor instead of a model steam engine
00:29:00 <Clockface> ?
00:31:00 <zid> someone actually got google docs working in a browser that isn't ff or chrome
00:32:00 <zid> and by someone I mean, a software project with a whole bunch of people
00:32:00 <zid> just to see if they could
00:32:00 <zid> their conclusion was "It's impossible don't bother"
00:33:00 <Clockface> my current ambition is to have something that can load programs into memory and provide a way to call them later (probably with a shell type thing)
00:34:00 <klange> < Clockface> its like working on a nuclear reactor instead of a model steam engine
00:35:00 <zid> see all of those things sound hard so I didn't bother
00:35:00 <zid> but.. it does respond to ping, because that was easy!? technology is weird.
00:35:00 <klange> It's more like building an actual steam engine in a world where they are so pitifully useless not even a developing nation would use them compared to a state-of-the-art nuclear reactor
00:36:00 <kazinsal> in this metaphor, buying a CANDU reactor is a RHEL subscription
00:37:00 <klange> With OSes you can achieve parity and even vastly overtake the functionality of an OS from a few decades ago, even targeting the same hardware as those OSes did.
00:37:00 <moon-child> hm, I think the metaphor is not entirely apt, because the difference between a hobby os and a production one is one of degree, not kind
00:37:00 <klange> But that means nothing if you want to compare your OS to what the real world is using now.
00:37:00 <moon-child> but there's no upgrade path from a steam engine to a nuclear reactor
00:37:00 <Clockface> what about BWR
00:37:00 <klange> moon-child: nuclear reactors _are_ steam engines, with a very particular steam generation source
00:38:00 <moon-child> klange: sure, but there are complications. If you're burning wood or coal you don't care about that heat escaping
00:38:00 <kazinsal> steam engines made with spicy rocks
00:38:00 <klange> Nuclear fission is the Nvidia GPU or the 10gbit NIC.
00:38:00 <moon-child> err, that steam
00:38:00 <klange> Or the myriad of existing software.
00:39:00 <moon-child> not so with nuclear, so you need additional containment and transfer. There's more that's different than that's the same
00:39:00 <zid> steam engines are when you put the black tangy rock in, nuclear engines are when you put the grey tangy rock in
00:39:00 <Clockface> steam engines are just heat exchangers with smokey flames > water transfer
00:40:00 <Clockface> nuclear reactors have heat exchangers too, they power several steam engines
00:40:00 <zid> They both have REAL bad issues with running out of water
00:40:00 <zid> like, run away really fast issues
00:42:00 <klange> I used to throw around a toy train set metaphor, but I don't think that really gets the point across. It's more like the industry is building shinkansens and you're building a handcart. They'll both run on the track if you build them to the right gauge, and a millenia ago that handcart was state-of-the-art, but you're not remotely close to being in the same league.
00:43:00 <zid> I think more close is handmade timepieces
00:43:00 <zid> cnc vs hand files, but you still end up with the same product... eventually
00:43:00 <Clockface> if you arent shooting for state of the art, its still just fine to have a novelty to put in a VM or usb
00:45:00 <klange> Sure, just don't get it into your head that you've got any experience with rail car design even if you've put in the decade of work to upgrade your handcart into a steam engine.
00:46:00 <zid> still lots of engineering experience though
00:46:00 <klange> My particular situation is like thinking a lemonade stand is "beverage production business management" experience...
00:47:00 <Clockface> you know more about it than if you never had a lemonaid stand in the first place
00:47:00 <Clockface> *lemonade
00:48:00 <klange> But taking a factory tour of a lemonade plant would be more worth your time.
00:49:00 <Clockface> true
00:51:00 <klange> I think that's probably the most apt metaphor for how I feel about osdev now. You can grow your own lemons, harvest your own sugar, get your own water from a spring, and spend ten years selling it at your local farmer's market, and not a single aspect of that is relevant to the production of industrial mass-produced lemonade, so don't think it will ever help you get a job at [Big Company that makes an OS].
00:52:00 <Clockface> this isnt supposed to be productive for me, i just think its interesting and i want to make my glorified bootloader with bonuses
00:54:00 <Clockface> i do not know how far i will get, but its interesting to work on regardless
00:56:00 <Clockface> its a hobby, like building a model railway
00:56:00 <klange> I don't even know where I'm going with this rant.
00:57:00 <Clockface> you seem like you are having a tough time
00:59:00 <klange> I wanted it to be more than a hobby, I was mistaken in thinking that having done it as a hobby for so long would maybe possibly qualify as an ounce of experience, and someone finally decided to break the news to me.
00:59:00 <klange> So maybe just let it be a lesson. There are industries where hobbies can translate to careers. OSdev is not one of them.
01:02:00 <Clockface> the guy watching his little trains go around in circles is still probably having more fun than the engineer babysitting a freight train all day
01:04:00 <Mutabah> Sure they can - if that's their goal.
01:06:00 <Mutabah> However, we (used to?) see a lot of people here who wanted to make a semi-usable OS, and then said they wanted tos tart at a bootsector
01:07:00 * Mutabah goes to properly read scrollback
01:07:00 <Clockface> i made a
01:08:00 <Clockface> bootable print to BIOS thing a year ago, then i remembered osdev.org exists and got interested in ibm pc compatibles again
01:09:00 <Clockface> and now i havent done anything but at least i wrote down more of what im going to do
01:11:00 <Clockface> i doubt i will stick with this for too long as i never really do
01:13:00 <Clockface> but it would be nice to have something to show off and then crash because of a syntax error at the command prompt
01:15:00 <Mutabah> Ah, the above wasn't a "don't do bootsector" rant.
01:16:00 <Clockface> mine is supposed to go with GRUB
01:16:00 <moon-child> you know, I think the most apt metaphor is really
01:16:00 <moon-child> a
01:16:00 <moon-child> a hobbyist os vs a production-viable os
01:17:00 <Mutabah> :)
01:17:00 <bauen1> you learn quite a few things when writing / designing an operating system, related software and infrastructure, so it's pretty much the opposite of wasting time
01:17:00 <Mutabah> As long as you treat it as abstract learning.
01:18:00 <clever> my goal is to make a functional os on hw where no open source os exists
01:18:00 <Mutabah> klange: I think you were both lucky and unlucky. You had probably the most success at pushing towards mainstream of all of us...
01:18:00 <clever> so i'm choosing to not waste time on parts (malloc, threading) that are already in the open source world
01:18:00 <Mutabah> with the downsides that brings.
01:20:00 <Clockface> mine is supposed to be extendable, the "command prompt that crashes with a syntax error" could easily be substituted for the "kernel?" of something more advanced
01:21:00 <clever> Clockface: yeah, mine already has a compile-time module framework (it came free with the kernel), so i can easily add optional features
01:21:00 <Clockface> so i could lose interest in it and if someone ever wants to do something they have something to build off of
01:21:00 <Clockface> mine keeps the kernel binary modules in files, and loads them into memory
01:22:00 <Clockface> when it loads each file, im designing it to assign a 12 character ascii "label" to each one
01:22:00 <Clockface> if another kernel space thing wants to call it they can use the "label" phonebook to see what the memory location that module got loaded to is
01:22:00 <clever> i dont have any runtime module support
01:24:00 <Clockface> mine is just some .txt files and a GRUB header, so im not too far along
01:25:00 <Clockface> it shouldent be too far to implement though, its simple enough to implement
01:25:00 <Clockface> *hard
01:27:00 <geist> yeah, exactly. re: losing interest and people build on it
01:27:00 <geist> you can indirectly help other people that way, which is kinda nice in its own way
01:27:00 <Mutabah> It's what I do
01:27:00 <Mutabah> I've spent the last few years on a compiler
01:30:00 <Clockface> while im here, GRUB what you tell it to load into a predictable spot in memory right?
01:32:00 <Mutabah> I'm pretty sure grub honors the load/physical address field in ELF
01:33:00 <Clockface> awesome
02:20:00 <clever> Clockface: oh, you may want to look at dlopen and dlsym on linux
02:29:00 <heat> GRUB + multiboot2 can dynamically load you in memory if you have a PIE kernel
02:55:00 <klange> > you may want to look at dlopen and dlsym on linux
02:56:00 <klange> Those would be in glibc / ld-linux.so, or in musl, and as complete real-world implementations that are quite complicated.
02:57:00 <klange> This is literally why I did what I did with ToaruOS over the last several years; it does the thing, but more simplerly. https://github.com/klange/toaruos/blob/master/linker/linker.c
02:57:00 <bslsk05> ​github.com: toaruos/linker.c at master · klange/toaruos · GitHub
03:02:00 <heat> klange, /bin/ld.toaru when?
03:04:00 <clever> klange: but it can serve as an idea on how to build your own runtime module loader
03:05:00 <heat> clever, a kernel module loader is wayyy simpler than ld.so
03:05:00 <klange> heat: that _is_, effectively, /bin/ld.toaru
03:06:00 <klange> My kernel module loader is over here, it links static objects like Linux, different process from linking shared objects: https://github.com/klange/toaruos/blob/master/kernel/misc/elf64.c#L42
03:06:00 <bslsk05> ​github.com: toaruos/elf64.c at master · klange/toaruos · GitHub
03:08:00 <heat> https://github.com/klange/toaruos/blob/master/kernel/misc/elf64.c#L244
03:08:00 <bslsk05> ​github.com: toaruos/elf64.c at master · klange/toaruos · GitHub
03:08:00 <heat> sin counter: 1
03:12:00 <heat> actually a few days I was helping a friend of mine learn C and I noticed he only does allocations using VLAs because he's scared of malloc lol
03:19:00 <geist> sounds like a smart guy
03:22:00 <clever> VLA's?
03:22:00 <klange> Being scared of malloc is smart, but using VLAs is biting off your nose.
03:22:00 <geist> clever: variable allocs on the stack
03:23:00 <clever> ahh right
03:23:00 <clever> but thats harder to persist long-term
03:24:00 <geist> i mean they're not too bad but generally a dangerous thing for stack constrained environments. if you ever use them really need to make sure you have a hard upper limit
03:25:00 <heat> they also generate horrible code too
03:25:00 <clever> yeah
03:25:00 <clever> ive had the ext2 code fail on LK, when the stack was too small
03:25:00 <clever> it puts 2 inodes on the stack, and blows it hard
03:25:00 <geist> it puts the inodes in the basket
03:26:00 <heat> woah
03:26:00 <clever> and worse, the stack overflow detection never catches it, because i end the thread before a reschedule
03:26:00 <heat> how big is the stack?
03:26:00 <clever> heat: maybe 2kb in some cases
03:27:00 <clever> i had to change some config to just not put the stack there
03:27:00 <heat> inodes aren't that big
03:27:00 <clever> finding a line# to reference...
03:27:00 <heat> 128 bytes in ext2, ~256 in ext3/4
03:28:00 <clever> geist: 2 ext2_inode's on the stack: https://github.com/littlekernel/lk/blob/master/lib/fs/ext2/dir.c#L72-L76
03:28:00 <bslsk05> ​github.com: lk/dir.c at master · littlekernel/lk · GitHub
03:28:00 <clever> https://github.com/littlekernel/lk/blob/master/lib/fs/ext2/ext2_fs.h#L103-L155
03:28:00 <bslsk05> ​github.com: lk/ext2_fs.h at master · littlekernel/lk · GitHub
03:29:00 <clever> heat: which is ~136 bytes i think
03:29:00 <clever> and ext2_walk is recursive
03:29:00 <heat> hm?
03:30:00 <clever> so each directory element in your path, consumes 272 bytes of stack
03:30:00 <heat> inodes are 128 bytes
03:30:00 <heat> that's just how they do be
03:30:00 <clever> heat: i may have mis-counted the bytes in the struct i linked
03:30:00 <clever> but thats still 256 bytes for each dir, so /a/b/c/foo.txt takes up 1536 bytes
03:31:00 <clever> oh wait, its only for symlinks
03:31:00 <clever> normal dirs are handled by the while loop
03:31:00 <clever> but its probably my fault, for just having so little space in the stack
03:32:00 <moon-child> I have used vlas before, but only for convenience
03:36:00 <heat> clever: why do you have 3 pull requests
03:36:00 <clever> heat: i have a bad habbit of not finishing things, really need to finish those PR's
03:45:00 <geist> yah i'd actually like to revisit that driver at some point
03:45:00 <geist> but would like to get your changes in first
03:45:00 <geist> then i was thinking about gutting it and morphing it into something more substantial
03:45:00 <clever> the pl011 or the ext2/3/4?
03:46:00 <geist> ext2
03:46:00 <geist> the pl011 would be nice too
03:46:00 <clever> ah, i'll try to remember to check on them next weekend
03:47:00 <heat> https://godbolt.org/z/613nn8zoq <- yuck
03:47:00 <bslsk05> ​godbolt.org: Compiler Explorer
03:47:00 <clever> i was thinking about implementing a `sha256 --check` command, so i could generate a tree or random files/folders/symlinks, hash them, then validate under lk
03:48:00 <clever> there where bugs involving files in the 2nd block group
03:48:00 <clever> that only turned up when using a real os disk image
03:49:00 <clever> ive fixed them, but it reveals flaws in my testing
03:50:00 <heat> quick reminder that there is an *excellent* ext4 driver in edk2 written by a genius that can be used as a point of reference
03:50:00 * heat drops https://github.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg/Ext4Dxe
03:50:00 <bslsk05> ​github.com: edk2-platforms/Features/Ext4Pkg/Ext4Dxe at master · tianocore/edk2-platforms · GitHub
03:50:00 <clever> heat: but is it compatible with LK's license?
03:50:00 <heat> yeah bsd-2-clause
03:51:00 <clever> ah, so i could just replace the ext2 driver entirely
03:51:00 <clever> does it also have write support?
03:51:00 <heat> no
03:51:00 <heat> not yet at least
03:52:00 <heat> and I, oops, the author, hasn't added ext2 support but that's just having a branch in ext4_read() that takes you to bmap code
03:52:00 <heat> also the code style is super different from lk
03:54:00 <heat> theoretically write support shouldn't be too hard
03:54:00 <heat> the ext2 bmap path is relatively simple I guess
03:54:00 <heat> not sure about ext4's extents though
03:54:00 <clever> LK's ext driver also lacks write support, and i'm not sure i would want to attempt that
03:55:00 <clever> extents are pretty simple, the problem is more about deciding what blocks to allocate
03:55:00 <heat> yeah like maybe write support isn't really required for lower level things like these
03:55:00 <clever> write support is something ive been wanting, it would make data capture for some testing far simpler
03:56:00 <geist> agreed
03:56:00 <heat> for example apple's filesystem isn't writable in the firmware and that's why they have a FAT32 fs (for firmware update capsules)
03:57:00 <clever> currently, my only way to export data is to either hexdump it to the serial port, or boot full linux on another core and exchange it over
03:57:00 <clever> its fine for a one-off rom dump
03:58:00 <clever> but when i begin messing with graphical stuff, and have to take a dozen screenshots a day.....
06:36:00 <Jari--> sure deal - but first a C64 demo in Assembly language, then I can continue on JTMOS Kernel OS Project
07:15:00 <geist> word
08:07:00 <sham1> L
08:07:00 <sham1> Oh yes, VLAs
08:12:00 <zid> VLAs indeed
08:12:00 <zid> (what?)
08:13:00 <sham1> I was reading the scrollback
08:14:00 <sham1> But yeah. VLAs are... tricky
08:14:00 <zid> they're not tricky but they're basically unusable if you want your shit to be portable/reliable
08:14:00 <sham1> The only place where I've seen them being useful is stuff like float (*mat)[n][m] = malloc(sizeof(*mat));
08:15:00 <sham1> That is, one doesn't allocate them on the stack, but on the heap
08:15:00 <zid> I use imaginary VLAs with sizeof to make the syntax nicer :P
08:15:00 <zid> that isn't a VLA
08:15:00 <sham1> Yes it is
08:15:00 <sham1> It's a pointer to a VLA
08:15:00 <moon-child> int mul(int x, int y) { return sizeof(char[x][y]); }
08:15:00 <zid> moon-child: exactly
08:17:00 <zid> float (*a)[2][3]; "declare a as pointer to array 2 of array 3 of float"
08:18:00 <zid> how does your thing even.. work? Hrmph
08:18:00 <zid> Pointer to unspecified size array of arrays.. would need vla *mechanics* to work, but isn't itself a vla
08:18:00 <zid> confusing
08:19:00 <klange> It's confusing overlap in terminology between that usage and stack allocations.
08:20:00 <zid> Let's all stick to FAMs
08:20:00 <zid> also, hot dang it's cold this morning
08:20:00 <zid> It's An degree, apparently.
08:22:00 <sham1> I think the standard does call that a VLA, but that's getting more into the territory of #C
08:24:00 <moon-child> can somebody please explain what the deal is with leetcode? Because I really don't ge tit
08:26:00 <sham1> Supposedly helps one get hired by doing all these challenged
08:28:00 <zid> some of it is kinda fun
08:28:00 <zid> most of it is not
08:33:00 <kazinsal> they're whiteboard questions for silicon valley tech startups
08:34:00 <kazinsal> you are basically doing the most obnoxious part of the interview process so often on your own time that you can do it without really having to put any effort in when you go to do it for real
09:43:00 <moon-child> I mean that makes sense but ... I see stuff like https://news.ycombinator.com/item?id=26468248 and -really_ don't know what to make of it
09:43:00 <bslsk05> ​news.ycombinator.com: 5 years of leetcode with no progress. I'm giving up | Hacker News
09:50:00 <zid> I mean, some people are just mental
09:50:00 <kazinsal> "I am quitting programming out of humility and recognition of my limitations. It’s ok to give up and wise to do so when you aren't good enough for something." what the fuck
09:51:00 <kazinsal> HN commenters are among the most bizarre fucking people on this planet
09:56:00 <sham1> Yes they are
09:57:00 <klange> Notably, Hacker News is not a programming forum. It's a startup forum.
09:57:00 <kazinsal> yeah, paul graham is a venture capitalist first and a programmer second
09:58:00 <kazinsal> this means that HN is full of bonkers libertarian programmers who think they're venture capitalists
10:02:00 <moon-child> I don't think that's quite the problem
10:02:00 <moon-child> I mean
10:02:00 <moon-child> it's not like (say) reddit is any better
10:02:00 <moon-child> it's more: internet forum at scale (startup flavoured)
10:05:00 <kazinsal> it's also a moderation problem
10:06:00 <kazinsal> if you have little moderation and a staff that are also all unhinged true believer types then you get an echo chamber
13:59:00 <Jari--> tough shit doing osdev, no deal
14:00:00 <moon-child> can't have shit in os
14:00:00 <Jari--> meaning the amount of dedication lost on existing projects, which stopped for a reason
14:00:00 <Jari--> probably most on funding, and focusing on too extra verbose category, area of focus
14:01:00 <Jari--> cloud os probably, which runs on a virtualization, has networking.. this is good... uIP kernels pretty neat e.g.
14:01:00 <Jari--> uIP = TCP/IP stack that runs in 64K RAM system, even on a Commodore 64
14:01:00 <Jari--> C code
14:02:00 <Jari--> besides, I have been thinking how to make a memory management... basically all I am doing next, is to make it 64K segmented banks, all memory almost is like this, better manageable
14:02:00 <moon-child> kazinsal: I think hn moderation is actually decent. The problem is it's hard to moderate low-quality discussion
14:02:00 <Jari--> moon-child: does anyone have automatically expansionable stacks in kernels / OS ?
14:02:00 <Jari--> Linux wise (like)
14:03:00 <moon-child> Jari--: sure
14:03:00 <moon-child> overcommit is thattaways
14:03:00 <Jari--> e.g. I spent hours fixing working code.. all I had to do to fix was to expand the fixed stack size
14:03:00 <Jari--> MS-DOS code... typical how they crash it
14:03:00 <moon-child> can also CPS and ditch the stack
14:04:00 <Jari--> moon-child: is it safe to do an exception, segmentation fault.. catch it up and handle and expand the pages ? I feel like it is quite delicate thing to do. But I am going to do this as well.
14:04:00 <Jari--> sbrk function in libc helps in guidance of this
14:05:00 <moon-child> Jari--: in kernel space, you must be careful. What if there's no free memory, so you have to swap something out, so you have to do a bunch of work in your vm system and disc driver?
14:06:00 <moon-child> so, switch to an alt stack, be careful specifically in vm&disc to use bounded stack space? Could work. But fragile
14:06:00 <sham1> I don't think you'd need much stack anyway on an OS kernel
14:07:00 <sham1> Maybe 16 K or 32 K max
14:07:00 <sham1> Since you probably shouldn't be doing all that much recursion nor allocating big things on the stack
14:07:00 <moon-child> sham1: sure. But plan for the worst
14:07:00 <sham1> Sure
14:07:00 <moon-child> some environments, if you don't recurse, you can statically calculate max stack usage
14:07:00 <moon-child> that is cool
14:07:00 <moon-child> but I don't think mainstream compilers (gcc/clang) will do that today
14:13:00 <Jari--> moon-child: and it helps a lot if your HD driver does not do any interrupts, purely I/O (PIO)
14:13:00 <Jari--> non-queued interrupts that is
14:13:00 <Jari--> stability conformed
14:18:00 <moon-child> yeah
15:04:00 <Jari--> I wanted a good script, so I made autogen.pl
15:04:00 <Jari--> it builds only whats new
15:04:00 <Jari--> and it is about 75 lines of Perl code
15:05:00 <Jari--> autoconf and automake for kernel... well if you are that much a hero
18:22:00 <superleaf1995> hi
18:24:00 <GeDaMo> Hi superleaf1995 :)
18:31:00 <superleaf1995> welp
19:57:00 <sham1> mov
19:57:00 <GeDaMo> add
20:20:00 <Oli> asl
20:31:00 <heat> everybody gangsta until acpi source language shows up
20:36:00 <sham1> mmhm
20:49:00 <superleaf1995> everybody gangsta till Java OS
20:53:00 <bauen1> those are all your smallest problems when Enterprise Java rolls through the door
21:09:00 <heat> log4j dmesg?
21:09:00 <heat> sounds great
21:10:00 <sortie> oh lol it just occurred to me that the last week of osdev time has been spent on logs
21:11:00 <sortie> gimme em syslog4j vulns
21:12:00 <heat> my last week of osdev time has been spent on football manager and watching football
21:12:00 <heat> and a bit of device files
21:12:00 <heat> tiny tiny bit
21:51:00 <bauen1> heat: does updating the copyright year count ? :D
21:51:00 <sham1> git hookk
21:55:00 <heat> dont update the year if you didn't touch the file in the new year
21:56:00 <heat> there ya go, problem solved
21:56:00 <sham1> Thus: git hook
23:20:00 <superleaf1995> when the memory manager is
23:20:00 <superleaf1995> stack based