<bslsk05>
zork.net: Real VT102 emulation with MAME - Screwtape's Notepad
MrCryo has joined #osdev
oldgalileo has quit [Ping timeout: 240 seconds]
oldgalileo has joined #osdev
node1 has quit [Quit: Client closed]
netbsduser has quit [Ping timeout: 252 seconds]
goliath has joined #osdev
xenos1984 has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
Arthuria has joined #osdev
oldgalileo has quit [Ping timeout: 255 seconds]
oldgalileo has joined #osdev
xenos1984 has quit [Ping timeout: 240 seconds]
scaleww has quit [Quit: Leaving]
xenos1984 has joined #osdev
oldgalileo has quit [Ping timeout: 268 seconds]
<geist>
Ermine: yep i can personally attest that it does
<geist>
but.... 'fine' is debatable
<geist>
main problem is most vaxen dont have much ram unless you had one of the mainframe versions
<geist>
and running netbsd 10 on something with 16 or 24 or 32 MB is pretty rough
<geist>
most folks are running netbsd 10 on simh emulated vax, where you can dial up 512MB quite easily
<geist>
512MB is i think the architectural max
oldgalileo has joined #osdev
<geist>
but anyway for more or less exactly the same hardware the youtube stream has i have a copy of netbsd 3.1 on it. a nice vintage. fairly modern but small enough to not instantly swap
<geist>
32MB ram
oldgalileo has quit [Ping timeout: 272 seconds]
MrCryo has quit [Remote host closed the connection]
navi has quit [Read error: Connection reset by peer]
navi has joined #osdev
rustyy has quit [Ping timeout: 240 seconds]
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 272 seconds]
oldgalileo has joined #osdev
<dostoyevsky2>
They say netbsd runs on everything but yet it doesn't run on a esp32
<Ermine>
One could say that running anything more or less modern in 32Mb is a tall order
<dostoyevsky2>
> RetroBSD is a port of 2.11BSD Unix intended for embedded systems with fixed memory mapping. The current target is Microchip PIC32 microcontroller with 128 kbytes of RAM and 512 kbytes of Flash
<heat>
onyx booting takes like 30MB of ram too
<heat>
just dropping to the shell
<heat>
granted most of it is page cache but... yeah
<Ermine>
woah
joe9 has joined #osdev
<heat>
libc.so is like 6MB, libstdc++ is similar
<Ermine>
musl? BLOATED
<nikolar>
What if you statically linked
<nikolar>
How small can you get
<Ermine>
go and build onyx userspace statically and check
oldgalileo has quit [Ping timeout: 255 seconds]
<heat>
+ caching of executables (login, dash, init) + 1MB minimal initrd + space-inefficient SLAB usage (for MAXIMUM SCALABILITEH) + space-inefficient per cpu page allocator lists (for MAXIMUM SCALABILITEH)
<heat>
buncha tradeoffs in general
<heat>
readahead eats up to iirc a megabyte possibly, in chunks
<heat>
if you allocate a large unreclaimable object, it's N objects in a slab (at least a page, but if they're large they're a bunch of pages) that can't be reclaimed
<kof673>
well...static linking is one thing.....but another meaning, an "embedded" os everything in one "binary" ....versus, can separate programs be loaded (meaning, the former i believe can be even smaller, because it is totally fixed, more information known, more chances for optimizing, etc.)
<heat>
i did analyse this a bit, on the SLAB allocator's end
<heat>
ended up minimizing memory usage at boot quite a bit
<kof673>
*more information known == more opportunities to cheat
<Ermine>
Well, tradeoffs
oldgalileo has joined #osdev
<heat>
the rest was mostly file pages, which should be okay to reclaim but it'll just be slow
<geist>
yah in the case of netbsd 10 the kernel fits reasonably nicely and you could always recompile it to be smaller, but it's basically just general user space code bloat that happens, even on fairly basic posixy systems
<geist>
libc is bigger for reasons, shells are bigger for reasons, etc
<heat>
yep
<heat>
libstdc++ is big too, bash is ginormous, GNU coreutils are big
<geist>
though that being said netbsd 10 is still fairly small, it's just as soon as you start doing something reasonably complicated (log in twice, run an editor, try to compile something) you're in swapsville
<Ermine>
Anyway, even openbsd doesn't support systems with 32Mb RAM
<geist>
especially compiler. though it's stuck o gcc 10.1 iirc, because vax cant be switched to clang
<geist>
i fiddled with simh and basically you want to run the vax at 64MB+ and then it starts to have some room to breathe
<kof673>
(and, semi-related, modern bsd stuff used to have "crunched binaries" which i think busybox does/did similar, one binary, invocable under different names, as a similar concept)
<kof673>
(that was specifically used for rescue floppies to save some space IIRC)
<dostoyevsky2>
hmmm how much ram does grub require?
<heat>
nikolar: you can probably get a nice win if you compile everything statically, but that's it's own can of worms
<geist>
yah /rescue has crunched stuff
<geist>
actually i think most of /bin and whatnot may be crunched. which helps
<geist>
or hurts, depends. the first tool you invoke pulls in 10MB, but then subsequent ones dont, etc
<Ermine>
busybox and toybox are sizecoded, at the cost of code quality
<heat>
^^
<dostoyevsky2>
Also, if grub is so great why not make grub the OS
<heat>
char toybuf[4096] // now all your IO is 4KB max
<geist>
because that's silly dostoyevsky2
<heat>
who said grub is great??
<Ermine>
you're literally the first person saying that grub is great
<nikolar>
heat yeah I imagine so
<nikolar>
Especially with -ffunction-sections, --gc-sections
<zid>
efi is trying to do that, dostoyevsky, no need
<dostoyevsky2>
Always when you install linux it's grub here, grub there
<geist>
but it's the exact same argument as to why dont you write all your apps in uefi. well if you want to make dos great again, sure
<geist>
ie, it's a single tasking program loader. those are 'easy' and useful in certain contexts
oldgalileo has quit [Ping timeout: 256 seconds]
<geist>
like uefi, grub, etc. but not a modern OS does that make
netbsduser has joined #osdev
<heat>
dostoyevsky2: grub is the most portable less awful bootloader atm
<heat>
as in it works for BIOS and EFI, and some other architectures (but thats rarer)
<nikolar>
Portable how
<nikolar>
Ah
<geist>
though i'd 'acktually' probably respond to that by saying 'uboot is'
<heat>
also for many operating systems
<nikolar>
It is grand unified after all
<geist>
but grub has x86 portable stuff locked down
<heat>
uboot can't boot x86 :(
<geist>
sure but it boots Everything Else
<geist>
but that's why i quoted my actually thing. ie, grub has x86 locked down, uboot has everything else
<heat>
now, quality wise GRUB is a trainwreck, and the distro situation with GRUB is much much worse
<dostoyevsky2>
heat: I guess grub is when you try to implement a Linux OS without it being a linux OS but you still have the minimum features to read any filesystem or interpret ansi escape sequences
<geist>
and they both are similar: a big pile of drivers/etc that let you assemble a fairly complicated secondary loader that can pull things from anywhere and put it in ram and provide some apis
<dostoyevsky2>
nikolar: ^^^
<geist>
dostoyevsky2: well no. it's not trying to implement a linux os
<kof673>
> the first tool you invoke pulls in 10MB yes, good point, double-sided crunch sword :D
<kof673>
depending on how much you cram in there lol
<geist>
it's trying to be a bootloader, and then features are needed (pluggable fses, etc) and then it gets more complicated
<geist>
but then it ends up being a very complete solution, if bigger than needed in any given context
<kof673>
ditto stuff like upx....faster to load from disk, but now decompression cost
<heat>
grub also has the distinct problem of actually acting like its "the OS" atm
<heat>
which conflicts with... EFI
<geist>
i know this from personal experience since so many existing phones and devices also use LK (my project) as their bootloader
<heat>
grub fighting with EFI is not unheard of
<geist>
it's the Other Thing other than uboot that seems to be popular on arm/riscv devices
<heat>
like, it still loads its own drivers for filesystems etc
<geist>
but then i guess in that case the LK-as-bootloader thing does start to blur the line between OS and bootloader
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
<geist>
basically 'boot a rtos thas has multiple threads and fses and drivers to load the next stage and/or provide recovery'
<heat>
lk blurs the line a little yeah, but it's still far from a full fledged kernel
<geist>
in the common case LK starts a thread or two, loads some shit from disk and then quiesces the cpu and jumps into the next stage. probably a few hundred ms
<geist>
in that case generally never leaves supervisor mode. but there are other places where folks build their own user space on top of it
<geist>
but generally not needed for bootloader stuff
<heat>
right yeha
<Ermine>
Everybody is using grub because nobody came up with good alternative
<geist>
also because grub is pretty nice
<geist>
i dont understand the grub hate, it's a far better solution in my experience than anything else on the x86 side of the world
<heat>
the internals are crap
<geist>
i think folks complain about it but they also probably havent had to deal with the pre-grub world
<heat>
that's all i hate about it
<Ermine>
There were breakages in Alpine world this winter
<geist>
sure, exactly the same as uboot. design that expands over time and no refactoring so it's hack after hack
<Ermine>
due to grub
<dostoyevsky2>
nikolar: But seeems like grub can load elf files but defines no syscall API itself... I guess that limits the kind of applications it can run
<Ermine>
But everything else is worse
<heat>
the worse bit is that distro ppl actively fuck it up
<geist>
dostoyevsky2: because it's not an OS!
<geist>
it's a loader
<heat>
like, red hat and debian grubs are stuck in old versions without fixes because they have fat stacks of patches they need to rebase
<heat>
they take the kernel + initrd + cmdline and package it together in a single pe file
Arthuria has joined #osdev
<heat>
which you then Just Execute
<heat>
this has the nice property of working well for measured booting and secure boot
<dostoyevsky2>
So if you were to write an OS where you don't support any of grub's filesystems... then you have to write your own bootloader too, unless your OS fits into a boot sector
netbsduser has quit [Ping timeout: 264 seconds]
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
<heat>
or you add your weird filesystem to GRUB
Arthuria has quit [Read error: Connection reset by peer]
<dostoyevsky2>
and then add a syscalll handler to grub, and start /bin/sh
m3a has quit [Ping timeout: 264 seconds]
<dostoyevsky2>
you could make that an onion os
<Ermine>
When I thought of a scope of project that could serve as grub replacement, I was kinda scared
<dostoyevsky2>
Add your OS to grub and then write a TUI to setup boot options for your os... saves one recursive call to itself
Arthuria has joined #osdev
<dostoyevsky2>
So seems like Grub itself requires 256-512K of RAM... I guess you could actually make it an OS that would run on an ESP32
<Ermine>
oh gosh, r/linuxmemes is cringe
<Griwes>
reddit? cringe? impossible
<Mondenkind>
#osdev is cringe
<dostoyevsky2>
I guess ESP32 is an interesting use case because the thing that you run on it is https://micropython.org/ which doesn't even have a syscall api, but it does have TCP/ip and filesystem drivers and you can do TLS/https requests and install pip packages I guess
<bslsk05>
micropython.org: MicroPython - Python for microcontrollers
gbowne1 has joined #osdev
gbowne1 has quit [Remote host closed the connection]
<bslsk05>
'Can you do that on Mac-OS or Windows? No. Only on Linux!' by polytect (00:00:23)
netbsduser has quit [Ping timeout: 260 seconds]
zxrom has quit [Quit: Leaving]
MrCryo has joined #osdev
MrCryo has quit [Ping timeout: 264 seconds]
brynet has joined #osdev
MrCryo has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
gog has quit [Quit: byee]
gog has joined #osdev
<Ermine>
btw I've seen old thinkpad in my uni's library
\Test_User has quit [Quit: \Test_User]
\Test_User has joined #osdev
netbsduser has joined #osdev
goliath has joined #osdev
<lukflug>
Given the recent vandalism, and the more long-standing annoyance of having a very outdated MediaWiki version on the OSDev wiki, I've decided to set up a fork (with full edit history on all pages) on Miraheze: https://osdev.miraheze.org/. It runs on a modern MediaWiki version and has proper anti-vandalism tools. Most changes so far were mostly to ensure that it's clear this is a fork and not something endorsed by OSDev.org.
<bslsk05>
osdev.miraheze.org: Just a moment...
<heat>
the wiki was vandalized?
<lukflug>
Yeah, it got reverted tho.
<lukflug>
Problem is apparently there's nothing preventing the vandal from just creating a new account and carrying on.
<lukflug>
Our "luck" is that the vandal is not persistent enough to do that.
xenos1984 has joined #osdev
netbsduser has quit [Ping timeout: 240 seconds]
netbsduser has joined #osdev
Turn_Left has quit [Read error: Connection reset by peer]
<heat>
cool :)
<heat>
as you may know the relationship with the admin is pretty crap, so you may be stuck maintaining that fork
<lukflug>
Yeah, although one advantage is that I can give other people the same permissions as myself. So I don't need to be the only one doing everything.
lukflug has quit [Quit: Leaving]
MrCryo has quit [Remote host closed the connection]
netbsduser has quit [Ping timeout: 268 seconds]
MrCryo has joined #osdev
<geist>
ah how did yo uget the dump of it? I have a .zip file dump of the osdev wiki from 2021, but AFAIK the feature isn't enabled all the time
oldgalileo has quit [Ping timeout: 255 seconds]
Gooberpatrol66 has quit [Ping timeout: 268 seconds]
Gooberpatrol66 has joined #osdev
<dostoyevsky2>
> Offline archive: You can download a copy of the wiki for offline viewing: https://files. osdev.org/osdev_wiki.zip The wiki archive is automatically generated on a weekly basis.
<bslsk05>
osdev.org: Just a moment...
<dostoyevsky2>
I actually added a space the in the url so bslsk05 wouldn't download the zip