<klange>
< geist> neat. yeah i think early logging and watching bootup messages to a kernel somehow makes it more real to me ← Exactly this!
<klange>
I take two seconds in QEMU to get from pressing enter on the boot menu to a desktop, but it feels wrong to just not say anything during those two seconds - and on TCG that may be 10 seconds, and on bochs it may even be several minutes.
zacque has joined #osdev
dutch has quit [Quit: WeeChat 3.3]
dutch has joined #osdev
k60 has quit [Quit: k60]
mahmutov has quit [Ping timeout: 260 seconds]
sts-q has quit [Ping timeout: 260 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
archenoth has joined #osdev
mahmutov has joined #osdev
srjek|home has quit [Ping timeout: 245 seconds]
Oshawott has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
mahmutov has quit [Ping timeout: 264 seconds]
stzsch has quit [Ping timeout: 265 seconds]
vai has joined #osdev
ElectronApps has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
remexre has quit [Quit: WeeChat 3.1]
remexre has joined #osdev
gxt has quit [Ping timeout: 276 seconds]
gxt has joined #osdev
<klange>
Working on getting Misaka to boot directly as an Elf64, and with Multiboot2, and possibly also with Stivale since it seems they've got a reasonable community going.
<kazinsal>
nice. I'm on the verge of writing my own bootloader...
m3a has quit [Ping timeout: 260 seconds]
<Mondenkind>
klange: stivale over bootboot or limine?
<Mondenkind>
oh huh, apparently limine is stivale. Didn't know that. I was vaguely aware of limine's existence and not of stivale's, so I assumed it was more popular
<kazinsal>
stivale is the protocol, limine isthe implementation
<kazinsal>
specifically the reference implementation
<klange>
My loader is a mediocre multiboot1 implementation. First step was adding support for AOUT_KLUDGE payloads so I could use that with the Elf64.
<klange>
I've stuck with multiboot1 because of that sweet, sweet -kernel support in QEMU.
vdamewood has joined #osdev
merry_ has joined #osdev
ElementW_ has joined #osdev
lanodan_ has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
<Belxjander>
so what state is Misaka in now?
<klange>
Misaka's been pretty ready for a while, mostly just have lingering tasks around device drivers and network stack improvements blocking my 2.0 target.
<Belxjander>
well the main thing I came into here for was actually for working on device driver level code
* Belxjander
is still messing with concepts a bit while experimenting for the most part :/
zacque has quit [Quit: Bye]
jimbzy has quit [Ping timeout: 260 seconds]
lanodan has quit [Ping timeout: 260 seconds]
ElementW has quit [Ping timeout: 260 seconds]
merry has quit [Ping timeout: 260 seconds]
merry_ is now known as merry
<klange>
Misaka's met all of my goals for it so far. 64-bit, SMP is stable and worth using, everything's much more portable and I am planning an aarch64 port, and I was able to redo things like the network stack from scratch (which is part of why it's still missing things, though it is at and even beyond feature parity with toaru32's).
<klange>
It'll boot with multiboot and multiboot2, it's been tested pretty thoroughly in QEMU, VirtualBox, and VMware Workstation, as well as on a few pieces of real hardware.
<Belxjander>
and here I was looking at it for possibly making it functional on a PPC host...
<Belxjander>
still undecided about that at the moment though
<klange>
ppc64, possibly, but I know nothing about POWER.
<Belxjander>
I've only got a 32bit PPCAMCC440EP processor desktop here...
<Belxjander>
but as far as bitwidth for the instructions concerned... there is a few more for dealing with loading constant values to registers...
<klange>
In building Misaka as a 64-bit-first kernel, I may have made the inverse of mistakes I made in toaru32, and much of my memory layout is highly opinionated (makes heavy use of having a 64-bit address space).
<Belxjander>
but more of the operational width of the r0 through r31 registers is changed... not so much the instructions themselves
<Belxjander>
that won't change on a 32b PPC then... same structural layout
<Belxjander>
the XHCI driver Im working on for AmigaOS 4.x has the same thing... the XHCI controller itself is 64bit hardware but I need to deal with reading/writing as 32bit paired operations
<Belxjander>
I haven't run into anything of a deal breaker in just using 64bit definition structures and reading/writing values the same as 32bit OS structures
<kazinsal>
I keep dragging my heels on a 64-bit rewrite...
<Belxjander>
the only thing I have to really keep in mind for this driver specific code is endianness
<j`ey>
kazinsal: oh i assumed you were already 64bit
<Belxjander>
since the XHCI controller and the PPC are opposing endianness natively
<kazinsal>
j`ey: most of my code is portable enough that I really only need to rewrite the nasty x86 guts to be 64-bit friendly but that's just so much wooooooork
<Belxjander>
but the XHCI controller is "low:high" write order so sequential writing in BE order native for reversed values matches the PPC to the XHCI
<Belxjander>
kazinsal: at least you aren't doing a complete "from nothing" write-up :P
<kazinsal>
technically with my intended scope and somewhat non traditional SMP setup I don't really *need* the extra address space
<Belxjander>
kazinsal: whas different about what you did?
<kazinsal>
different cores are assigned different tasks and kernel event loops; certain ones run a kernel for handling hardware interrupts and I/O, some run ones for run-to-completion of high priority kernel-space tasks, and others do pre-emptive userspace multitasking
* Mondenkind
whispers: SASOS
<Belxjander>
so basically you allow for processors to be assigned off for as specific roles... instead of being dumped as a single group shared resource?
<kazinsal>
if you wanted maximum forwarding throughput with just simple firewalling and don't care about anything else other than remote management, `platform processor-template performance` assigns one processor the userspace role and the rest either I/O or network flow roles based on <magic that currently exists on paper only right now>
<kazinsal>
yeah
<kazinsal>
the I/O Service Processors assign tasks to the Network Flow Processors or the User Service Processors based on hardware interrupts etc
<Belxjander>
oh right...
<kazinsal>
the Network Flow Processors basically just dequeue tasks based on priority and run them in sequence
<Belxjander>
so all the CPUs are default to "multitasking userspace" as a defined role with the option of allocation for other roles with option for exclusion of the default role
meeripeedi has joined #osdev
<kazinsal>
the boot processor is always an IOSP because, worst case, it can handle all three roles
<Belxjander>
sounds like you take the approach of "round-robin" scheduling applied to each processor individually... and then have each processor able to be grouped into a specific role...where each "role" has its own task/process listing
<kazinsal>
the rest are brought up into whatever role they need to be based on <magic algorithm>
<kazinsal>
which is currently hardcoded because I only have one test platform
<kazinsal>
in practice it's... something that needs a lot more testing to be able to generalize
<Belxjander>
kazinsal: thats actually eerilly similar to how I worked up hacking SMP into AmigaOS on 68K some years ago...
<kazinsal>
eg. what's the actual realistic load on the IOSPs per gigabit of IMIX worth of interrupts
<klange>
< kazinsal> I keep dragging my heels on a 64-bit rewrite... ← Beyond other personal things that happened in the last year, my main instigator was seeing a bunch of new projects reference ToaruOS and thinking "man, my kernel sucks, people shouldn't be learning from this".
<kazinsal>
klange: aha, so I need to write more code in general and release something so I can move to 64-bit ;)
<Belxjander>
klange: would it be possible to port just the network stack section of the Misaka kernel on it's own?
* Belxjander
is actually needing to replace the current "default" network stack on AmigaOS with something more capable and modular if possible
<klange>
You wouldn't want to, it's pretty bad. Better than toaru32's, sure, but probably best left where it is. Also it's pretty deepely tied into VFS stuff as part of how I built the new socket layer.
<Belxjander>
uggh
<Belxjander>
so I am stuck with digging through a BSD or Linux kernels sources again :/
<Belxjander>
at least I don't have to care about side-by-side launching of network stack code until the "bsdsocket.library" implimentation details for presenting IPv4 to user applications...
<klange>
To be fair, BSD's is the standard :)
<Belxjander>
AmigaOS network device drivers all follow "SANA2" specification for that at least...so hardware access isn't a question...
<klange>
sortie had a whole test suite looking at several implementations, also sortix's stack is pretty solid from what I've heard.
<kazinsal>
yeah if you want to port a network stack port sortix's
<Belxjander>
klange: I've had SE and NE training before... and *was* deeply knowledgable with regards to the unix stacks... but it has been waaaay too long to remember it all
<Belxjander>
the programming side of things mostly talks about userland applications using sockets API calls
<klange>
As an example of how you don't want to use Misaka's net stack, it's still missing listening TCP sockets, routes, and a loopback interface.
zacque has joined #osdev
<kazinsal>
hey, between the two of us, we have a network stack!
<Belxjander>
well I wasn't even looking at those as being needed...
<klange>
That's essentially my TODO list for ToaruOS 2.0 at this stage.
<kazinsal>
(I'm missing TCP, but I have routing, forwarding, and virtual interfaces...)
<Belxjander>
so sortix networking is recommended?
<Belxjander>
as an alternative to the BSD kernel network stack code?
<Belxjander>
well I'll just have to make checkouts and dig through it all
<klange>
Make sure you look at the 'staging' branch, sortix's default branch is hella old.
<Belxjander>
yeah... once I actually get this XHCI codebase upto "works for me"...
<klange>
I pushed xhci back to my 2.1 roadmap. Can't have too many great things in one release!
<klange>
2.1: xhci, ahci, USB HID, various filesystem things; 2.2: aarch64, RPi400 platform target
<Belxjander>
well for the most part the XHCI code is actually very simplistic for dealing with the controller
<Belxjander>
since the XHCI controller itself handles the majority of hardware related tasks almost on its own
<klange>
I've just been juggling too many things, I had to get rid of a few from the roadmap or 2.0 coming out this year was looking unlikely.
<Belxjander>
it just needs to be given a couple of memory regions for working in... and once it starts... listening and responding to interrupts and handling the TransferRingBuffer logic from what I can tell
<klange>
Now that I've essentially narrowed it down to "finish up this network stack and run a webserver, plus whatever random crap I do to distract myself", it's looking more possible.
<Belxjander>
well I have a whole lot on my own todo list as well
<Belxjander>
was hoping to get this XHCI into a more functional state earlier too
<Belxjander>
ahh well... slowly but surely
<meeripeedi>
I was always unsure what the pickets are about, or what you argue about cause it is all documented how bus and it's control registers work, and i am doing totally fine also, those type of registers in the wiring logic are pulled to a steady state cmos configuration, they do not use energy except the leakage voltage, it is inverter logic based.,
<meeripeedi>
wired truth table was also given tris-state bus truth table, there are transistors that control wether the enable line is in, if that high or low ipmedance or bus overwrite, if one wants to store bits circulating in a wire, it needs to corrupt the enable line logic, so it balances the line correctly and adds more to it, cause one atom at time
<meeripeedi>
electrons move, current on the other way, so they do 3d printed hearts in minutes these days, me i was always wanted to kill, if you are stupid they will succeed if not, you have chanches i surivived and i understand it makes you anxious desperate and jelous, but if you aint gonna commit drastical chancges do your ways of thinking its as for
<meeripeedi>
everybody you will be sent to rest, it will succeed on you if you are stupid what did not on me.
meeripeedi was kicked from #osdev by klange [meeripeedi]
C-Man has quit [Ping timeout: 265 seconds]
dormito has joined #osdev
kardion1 has joined #osdev
<kardion1>
your faulty integral or derivative formulas should not be welcome here either, you have been a waste of time in my life, and very evil nutters who understand nothing, i had many of such on the island bugging me, i was going to tell shart to fuck or buzz off or you gonna regret your words and stalking and corruption towards me, same words to you,
<kardion1>
you are brainless individuals, only troubles to me in life and world of programming and i allready said to sortie and klange very clearly cut this off, you are no match to me, all can see it, just do not come to me with your crap and do not say those words you are used to say towards me if you are not suicidal.
kardion1 has quit [Quit: Client closed]
archenoth has quit [Read error: Connection reset by peer]
archenoth has joined #osdev
<junon>
He's back!
<junon>
Trying to figure out if it's a markov chain type of deal or if it's just a (kind of sad) case of someone who knows a bit of what they're talking about but can't form a coherent thought.
zaquest has quit [Remote host closed the connection]
<Mutabah>
99% sure it is (or at least was) the latter
<junon>
Given that it always tends to end in "you are all brainless individuals" I would wager the latter, too.
zaquest has joined #osdev
<junon>
klange: nice car wrap by the way (I'm having morning tea and stalking you I guess)
<junon>
procrastinating work.
dormito has quit [Quit: WeeChat 3.3]
Arthuria has joined #osdev
GeDaMo has joined #osdev
henistein has joined #osdev
Arthuria has quit [Ping timeout: 264 seconds]
weldering has joined #osdev
C-Man has joined #osdev
weldering has quit [Quit: Client closed]
henistein has left #osdev [#osdev]
weldering has joined #osdev
<weldering>
so the final talks before i leave is about wires/bus topologies when you get the splits right, many will suite perhaps crossbar and cascaded wires are most popular, i just comment on the last either you put the transistor in different parallel hotspots i.e lengths or just make the merges and splits at different distances of the parallel wires.
<weldering>
security talks only cause of current situation in the world which is evil, as ell as my money being ripped my scammers once before, and now i leave.
<weldering>
I have no authority and i never hacked into anywhere.
<calmaser>
technically yes tallinns city council said that i have difficultiest time and want to extend my custodial program cause of mental illness, me i have no difficulties, they have due to their actions, if they do not stop this lunatic terror than they risk with possible death pentalty in combined case, i will accuse them in court , i do not apply for
<calmaser>
money but sanctions allready then. Me no one touches here or tried perhaps then they were told wrong man. Me i do not have problem they allready lost everything against me, but they can get further charges, i am good. I do not want to accuse, cause maybe someone tried to help and did humanly mistakes, i say do not extend sanctions and lock me up,
<calmaser>
or they case starts against them, i do not live in estonia anymore anyways,
calmaser was banned on #osdev by klange [*!*karadon@58.97.228.*]
calmaser was kicked from #osdev by klange [calmaser]
k60 has joined #osdev
<klange>
Ooh, found a lock ordering bug, haven't seen a new one of those in a while.
mavhq has joined #osdev
<Ermine>
Looks like this is the same guy who was banned earlier
<zid>
BUG: Unable to order locks, amazon interface gives 404.
<junon>
Ermine: they come in every once in a while. Today is particularly active.
gareppa has quit [Remote host closed the connection]
adachristine has joined #osdev
gog has quit [Killed (NickServ (GHOST command used by adachristine))]
adachristine is now known as gog
<junon>
err did gog get pwned?
<klange>
looks like a typical lingering session getting knocked off, that's what the GHOST command is for
<junon>
yeah but the nick is entirely different. probably an alternate
<junon>
But still lol
<junon>
> GHOST command used by adachristine
<heat>
it's her name
<junon>
makes sense :)
ahalaney has joined #osdev
brynet has joined #osdev
Oli has joined #osdev
mctpyt has joined #osdev
gxt_ has joined #osdev
gxt has quit [Ping timeout: 276 seconds]
dennis95 has joined #osdev
Oli has quit [Quit: leaving]
Oli has joined #osdev
Oli has quit [Client Quit]
Oli has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
dude12312414 has joined #osdev
lanodan_ is now known as lanodan
<heat>
is there any build system that can check for up-to-dateness with arbitrary commands?
<heat>
ninja and make seem to only do it with timestamps
brynet has quit [Ping timeout: 252 seconds]
<zid>
use a vfs and when you see make is statting the file, run that program ;)
[itchyjunk] has joined #osdev
<heat>
jesus that's cursed
<clever>
heat: i use the nix package manager a lot, and it deals with the hash of the file contents, rather then the timestamp or arbitrary commands
<clever>
its much more like how ccache works, but on whole packages
<clever>
and namespacing is used to enforce that a package can only use the hashed files, and NOTHING ELSE
sprock has quit [Ping timeout: 258 seconds]
gxt_ has quit [Remote host closed the connection]
gxt_ has joined #osdev
<froggey>
scons uses date+md5 and it's configurable
<zid>
I prefer my idea
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
stzsch|2 has joined #osdev
<heat>
my idea would be that I would be able to do "make -q" and use the output as a way to check if the target needs to be rebuilt
<heat>
ninja does support restat which skips rebuilding everything that depends on the target if the timestamp is the same, which /works/ but is not ideal
<heat>
every time I think about build systems I get the big sad :(
<junon>
heat: check out Tup
<junon>
does what you're looking for.
<junon>
They have proven it as they've forked the linux kernel and applied Tup to it entirely. I don't personally prefer it (I'm kind of a build systems snob) but it certainly approaches it with a similar mindset.
<heat>
interesting
<heat>
my particular use case is "project with lots of sub projects that may have their own build systems" so tup fits that I guess
<heat>
right now I'm using gn and trying to use python scripts to fix the "invoke other build system" issue
travisg has quit [Read error: Connection reset by peer]
<junon>
I wrote my own system for that personally, I have the exact same usecase.
dmj` has quit [Ping timeout: 264 seconds]
<junon>
I can tell you definitively that CMake is as close, architecturally, as you can get. It's just such a PITA to use.
travisg has joined #osdev
<junon>
Ninja doesn't even handle this well enough - there's an open PR regarding "submodule"-type functionality since `subninja` is insufficient as currently implemented.
<heat>
i've never written cmake before :)
<heat>
i've mostly used makefiles
dmj` has joined #osdev
<heat>
I was thinking about rolling my own but I suck at parsing text
<heat>
so a quick and easy way to go for it would be "json and inshallah" but that's obviously not ideal from a user POV
brynet has joined #osdev
<junon>
Depends on your school of thought about build configuration. Declarative vs. Imperative. The former requires a good config format, the latter can re-use a scripting language if you want.
<eryjus>
i like/use tup. the thing that is a non-starter for most is that there is a build script in the target folder. Some cannot accept that
<junon>
An example of a JSON-based build system is Grunt, which is a part of the javascript ecosystem and has mostly died out. Another is Webpack, which isn't strictly JSON but is of the same nature.
<junon>
Both are highly inflexible, in my opinion, and cause people to push build concerns directly into the source code, which is a no-go in my opinion.
<junon>
It's also why I dislike Rust's tight coupling of Cargo and the language. Zig as well.
<junon>
Though Zig does this to a much more acceptable extent, at least.
<heat>
portage uses shell scripts but it's more of a package build system
<heat>
lots of versioning and whatnot
<heat>
kind of what I'm looking for and kind of not
<junon>
Makefiles are probably still the best bet to be honest. Make is just slow and highly platform dependent, so it really depends on who is going to be working with the codebase. If it's just you, then it shouldn't be an issue of course. But if you intend on other, potentially random-stranger, contributors to need to work with it outside of a prescribed environment, it can be an issue.
<heat>
a good question is: in how many packages should you divide a base OS?
<heat>
do you want your whole base OS to be individually updatable?
<heat>
or a base-os-0.1?
<junon>
I think if you could answer that with a generalized statement that worked reliably you'd be a very rich person.
<junon>
It's a common software problem.
<heat>
i feel like answering this question is a big-ish deal when thinking about a build system because you intrinsically can't have very tight coupling between components if they're all independent like that
<junon>
Given that OSes are kind of the epitome of subjective software design, there could be a thousand different answers. Unikernels will likely be exactly one package. Something like Linux is going to divide things up into a whole slew of things, if that's what you mean.
<junon>
Well packaging, and testing, are two different subjects. If you want to avoid coupling in order to have a better test story, that's more of a codebase hygiene thing and less of a packaging thing.
<junon>
Subjectively, packaging design should be a product of how you intend users to consume your OS.
<junon>
Not how the codebase is structured, per se.
<junon>
Though of course your codebase structure might reflect those decisions in part.
<heat>
yes exactly
<junon>
But your codebase should optimize ease of maintenance, understanding, build/test/run cycles and collaboration. Your packaging story should optimize for ease of use to downstream consumers. Any overlap is a bonus.
<heat>
this is the kind of design questions that I find hard to answer since ideally the rest of the codebase would need to reflect it
<junon>
Also, in my opinion, your entire codebase should subsist even if you were to remove all of the packaging/testing/CI. To an extent, even your build system.
<junon>
But I know that, for some reason, I am a minority in that school of thought.
<zid>
pfft, build your entire OS as a single binary from one single source file
<zid>
solves all your versioning issues
<heat>
i.e if I go for "each component inside the base OS is separetely updateable", I better hope each component already has packaging information
<junon>
make versions a 1:1 long sha1 hash of the commit that built it.
<junon>
grab life by the horns
<junon>
heat: you really want each component to have an individual build definition. Not packaging.
<heat>
how else would you install it though?
<junon>
CMake does this nicely. `add_subdirectory()` does exactly what you're looking for. It looks in the given directory, relative to the current source directory, for a `CMakeLists.txt` file.
<junon>
Usually if you have multiple artifacts, it's the build system at the top that defines the "layout" of the `pkg`/`dist`/whatever directory.
<junon>
Modules shouldn't care how they're put into the final image.
<junon>
"I live in `my-os/modules/libc` and I implement libc for the MyOS operating system. I produce `lib.so` and `std{io,lib,...}.h` to the current build directory." That's it. The build directory is usually dictated by the parent module (or the user, if the module is the "root" module)
<junon>
Where `lib.so` and the `.h` files actually end up is up to the user/parent module.
<junon>
Then in the parent module you usually have something that says "go into `modules/libc`, set the output directory to `<root>/dist/libc`, and then build."
<junon>
The module still doesn't care where they go, just that there is a specific output directory, and then the root configuration can orchestrate the final image structure by itself.
<junon>
idk if that answers your question or not.
<junon>
In such a design, the `libc` portion doesn't even know it's part of a larger OS.
<heat>
and the root configuration puts *everything*(meaning every file) together?
<heat>
if so, it seems... monolithic?
<junon>
Yep. Usually not explicitly, but usually the root configuration takes care of orchestrating the final packaging step.
<junon>
Depending on the build system, submodules can sort of "export" or expose which files they're expected to produce, usually as a list or something similar.
<junon>
Then the parent module can use that list, usually without caring what is exactly in that last, and generally does a glorified prefix prepend to each of those files
<heat>
I was thinking of: modules declare every file they have (in this case json is pretty suitable), then the image building steps would take every file of every component and put it inside the image, where it belongs
<heat>
dunno if that's also your idea
<junon>
hence why you see a lot of `prefix=` in some build systems.
<heat>
oh yes lol
<junon>
Yes but the problem with that is that there is usually an `n:m` relationship between build inputs and outputs
<junon>
and oftentimes more than one step in a particular build pipeline.
<junon>
Most commonly, `*.c` -> `*.o` (1:1) -> `./my-executable` (n:1)
<clever>
junon: but linking can also produce a map file as well, which is very useful for kernel stuff
<clever>
so that becomes a n:2
<junon>
To make matters worse (not that many OS devs are going to run into this in particular) some build steps produce variable outputs - particularly, `javac` (the Java compiler) can output a variable number of `FooClass$n.class` files for each of the nested classes.
<clever>
and ghc will generate a .hi and .o for each module it compiles
<junon>
Yes sure clever, my point was that it's not always a 1:1 relationship between "files in this module" and "files that end up in the ultimate built image"
<clever>
yeah
<junon>
Ideally, your build and package configurations are one and the same.
<junon>
You compile many C files into a single executable, you compile many executables into a single .tar.gz (conceptually)
<junon>
There's a lot of value to treating both as the same thing.
<heat>
well I think there's an issue with that approach
<junon>
But your intuition of self-contained modules is not a bad one, by the way. IMO it's the ideal design, at the high level.
srjek|home has joined #osdev
<heat>
example: I update libc.so to improve X, same ABI same everything. In a build system, that triggers *every rule that depends on libc* even with the same ABI
<heat>
an update to libc.so shouldn't require changes to every other package
<heat>
in a build system? sure, everything is more tightly coupled. but the user shouldn't need to update literally everything just because I improved malloc a tiny bit
<junon>
Why would libc.so be listed as a dependency to C files?
<junon>
And also, in an OS, updating libc.so should indeed cause other link steps to re-run - for the sole purpose that it's not a guarantee that there is ABI compatibility.
<junon>
And user updates are a different matter. You're looking for a package manager-like functionality, which should be pretty far removed from your build system aside from potentially generating package descriptions for whatever package manager you intend to publish to.
<heat>
libc.so is listed as a dependency to C files because libc is listed as a dependency to C files
<heat>
if there isn't ABI compatibility between one version and the next you generally increment the version number (so, libc.so.1)
nur has quit [Quit: Leaving]
<junon>
That's the linux way of doing it, yes.
<junon>
If it makes sense for your OS then yes do that. But I would still list them as dependencies.
<junon>
Iterative builds should be quick, yes, but builds should be correct above all else. If it's correct to list it as a dependency then you need to be OK with the outcomes of changing all of the module's link-time dependency lists
<junon>
cutting corners in the build system will only give you headaches.
jimbzy has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
ilovelaura has joined #osdev
sprock has joined #osdev
ElectronApps has quit [Remote host closed the connection]
mahmutov has joined #osdev
zacque has quit [Quit: Goodbye :D]
ilovelaura has quit [Ping timeout: 256 seconds]
Wukoo has joined #osdev
Wukoo has quit [Client Quit]
heat has quit [Ping timeout: 260 seconds]
dormito has joined #osdev
dormito has quit [Ping timeout: 260 seconds]
meisaka has quit [Ping timeout: 268 seconds]
meisaka has joined #osdev
dennis95 has quit [Quit: Leaving]
sprock has quit [Ping timeout: 260 seconds]
zhiayang_ has joined #osdev
zhiayang has quit [Ping timeout: 265 seconds]
zhiayang_ is now known as zhiayang
<sortie>
<klange> sortie had a whole test suite looking at several implementations, also sortix's stack is pretty solid from what I've heard.
<sortie>
Besides that, uh, remote crash that got fixed a while back... well it doesn't crash anymore and does tend to work.
ilovelaura has joined #osdev
<sortie>
It's NOT official and it's NOT reviewed. Use it for learning purposes, sure, but yeah. Don't trust it.
<sortie>
I will finish it when I get that far. Right now I'm finishing Unix socket file descriptor passing.
<sortie>
<klange> Make sure you look at the 'staging' branch, sortix's default branch is hella old.
<sortie>
The master branch is not old. Work does happen there. A bunch of recent contributions there.
<sortie>
But a few (lot) things have NOT stabilized and been through properly review and are in the staging branch, yeah. It's my primary project to reduce it. I just don't osdev that often.
srjek|home has quit [Ping timeout: 264 seconds]
<ilovelaura>
But i talked with my therapists face to face, like i always do, that you are not going to do fine going against my fans or lines with this extreme abuse against me, they sayd they are willing to take that risk, so they were aware of the risks, similar to the "heroe nutters" of streets who went house to house to lie about me to live my life, similar
<ilovelaura>
to jamaican the last who also know what is going to happen to them, just like the ones before. if you want to steal my life and live it -- talkk about unhappened dark sides , you get bitten, and their talks are piidle piss to me all the accusal also i whistlyfart to, cause their treatment and handling is nothing to do directly with me, cause i do
<ilovelaura>
not coordinate it, you digusted musical arts with your lethal evil lie obsessions also, trashed people who never diserved it and someone treated you for that, they had their chanche to avoid it, and i warned that i am not an average guy, that i have literally lot of fans around the world.
ilovelaura has left #osdev [#osdev]
<junon>
klange ^
<junon>
also 'whistlyfart' is a delightful album name.
<kazinsal>
side B is an 18 minute experimental prog rock soundscape
<junon>
:D
brynet has quit [Ping timeout: 245 seconds]
sprock has joined #osdev
Arthuria has quit [Ping timeout: 260 seconds]
medusa1 has joined #osdev
<medusa1>
I explained also everything about alkalines, magnesium , potassium , calcium and some fully inorganic allies in kukersite basin oxides they use in alkaline batteries, also known as semi/metals or trace metals very very abundant in estonia, i do not need to access them, but so far nothing sane has been done with them yet, they do everything wrong,
<medusa1>
there are also very valuable fossil parts also very abundant carbon unions with akalies with near ideal structure, there it is impossible to have better materials cause knowingly enough better does not exist in science or photonics world so if the top of the peak is reached again for certain greedy people to access things something needs to be
<medusa1>
crashed again to start seemingly climbing up again.
medusa1 has left #osdev [#osdev]
* geist
sighs.
<geist>
that was a nice break for a few weeks without him around
<kazinsal>
yeah, we actually had discussions here
medusa1 has joined #osdev
GeDaMo has quit [Remote host closed the connection]
<medusa1>
about the organs, yes everything has been done allready, upnano kind of machine is what austrian company commercialized two photon photolithographic bioprinting, same with the vehicles that bypass the defense line of extraterrestrians it needs certain structure for that vehicle to not generate external energy sensable for the nozzle to move the
<medusa1>
vehicle, rocket engine is the vintage tech they first used to discover the geometries and propterties and characteristics of earth, and this was also build by soviet ukranian sergei korolov the first time, being very wise gets you through of troubles also at times.
<junon>
medusa1: why berate the channel, again?
<medusa1>
three days , pig kidney was also transplanted to human with genetical modification without being rejected.
<medusa1>
three days ago
mctpyt has quit [Ping timeout: 260 seconds]
<junon>
Okay but that has nothing to do with OS development. You're spamming this channel with unrelated information.
<junon>
Can you please stop?
<junon>
Asking nicely.
jess has joined #osdev
<medusa1>
yes, when you stop poking me, i explained nicely also, that when enough parallel units are muxed together it will compromise any service, so government can not violate general public if they have not enough resources, one weak link will be exploited and that is it, and to make a civilizarion on mars that of humans, two immediate things, deratiation
<medusa1>
of the surface needs to be done, many ways, some less invasive than the others, and sane vechicles also, some permanend solutions can cause some sides that only god knows what would cause though.
vin has joined #osdev
hippity_hoppity has joined #osdev
mctpyt has joined #osdev
phy1729 has joined #osdev
<zid>
junon: please don't feed the trolls/mentally ill
ThinkT510 has joined #osdev
<zid>
That's how you get ants
<medusa1>
zid: i go through no emotions due to you, same guy who said to invade to estonia, allow me to laugh dude
<medusa1>
you even lost me in eruropean champs with your eng team
<medusa1>
lost to me
<medusa1>
you are entire outsider dude
<junon>
Not trying to :P Asked politely, figured maybe nobody's done that lol. Clearly didn't work.
<medusa1>
mentally vastly ill dude
<zid>
junon: you're going to cure schizophrenia by asking nicely?
<medusa1>
you do not make over the first corner in near my country, where men are third tollest in the world
<medusa1>
mentally ill person talking about illnesses that do not exist
<medusa1>
mr hallucination , can you please shut your mouth
<medusa1>
go to the toiled and shit there monster hallucinative leftover
heat has joined #osdev
<jess>
hey medusa1 what's up
<junon>
zid: Point taken ._.
<jess>
zid: i'd advise against remotely pathologising trolls. it's lazy and dehumanises people wuth those disorders who are not antisocial
<jess>
with*
<zid>
He is diagnosed.
<zid>
It's also blindingly obvious, and PLEASE DO NOT ENGAGE HIM
<zid>
fuck sake
<jess>
do you realise i am network staff
<zid>
great, fix this then
<zid>
instead of adding fuel
<jess>
you're the disruptive one at the moment :(
sprock has quit [Ping timeout: 260 seconds]
<zid>
uh-huh
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
__sen has left #osdev [#osdev]
<medusa1>
don't forget , that i have absolute memory about this case of nonsense for 20years against me, all the participants will be tested for corruptive fixed arrangements of negative kind, and they get easily what they diserve, about medicine , chemistrly and electronics and science of materials those know nothing about , they can not even make proper
<medusa1>
tests, those people are human pigs who diagnosed me, their info is all controversial and very wrong even.
<medusa1>
i.e total lack of coordinational powers in their posession, nothing to do there
ZetItUp has quit [Read error: Connection reset by peer]
medusa1 has left #osdev [#osdev]
masterline has joined #osdev
alexander has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
alexander has joined #osdev
srjek|home has joined #osdev
hippity_hoppity has quit [Remote host closed the connection]
tomaw has joined #osdev
masterline has left #osdev [#osdev]
heat has quit [Ping timeout: 260 seconds]
<klange>
While on my little boot binge, I also patched in a little MBR stub to my CDs so they can booted as hard disks. Just hardcoding the location of the El Torito loader into a little thing that moves itself around and loads that into place, then I fixed up my disk read routines to support different sector sizes.
<zid>
My bios is ridiculously lenient about what it'll boot
<zid>
I've dd'd iso files to hard drives and booted them
<klange>
Those sorts of stubs are pretty common, but I wouldn't be surprised to hear of a BIOS that also groked El Torito on a disk.
<klange>
Grub does a stub if you use its CD rescue builder, for example.
<zid>
yea you might as well just include the lot right, I don't think it's common for anything to /reject/ an iso9660 because the first 32kb isn't zeros or whatever it should be
<klange>
It's actually "the system area" and it can be whatever you want, but smashing an MBR in the first 512 bytes is downright normal.
<zid>
Oh I thought it had to be zero
<klange>
Often even with a partition table... or two.
<zid>
psx disks put the licence file and stuff in it
<zid>
so it knows if it's an SCEA or SCEE disk etc
<zid>
Unless you're the original japanese bios that doesn't give a flying fuck and will boot anything because they hadn't apprently finalized that system yet :D
<klange>
Some of my ISOs use the system area to store... the couple hundred bytes of a PDF.
<klange>
first couple*
<zid>
I've seen bootable CVs like that
<klange>
Exactly.
<klange>
I won't claim I invented the idea, but mine is particularly notable ;)
<zid>
I assume tom7 ahas one
<zid>
that seems like something he'd do
nyah has quit [Ping timeout: 260 seconds]
srjek|home has quit [Ping timeout: 264 seconds]
dormito has joined #osdev
dormito10 has joined #osdev
dormito has quit [Ping timeout: 260 seconds]
ahalaney has quit [Quit: Leaving]
<Mondenkind>
he wrote an executable pdf, I think
<Mondenkind>
but idk bootable
<zid>
bloody knew it
<sortie>
Remind me to find some adobe pdf reader and windows kernel zero days so reading the pdf reboots into the OS to view the pdf
dormito10 has quit [Ping timeout: 260 seconds]
eryjus has quit [Ping timeout: 264 seconds]
eryjus has joined #osdev
<Mondenkind>
oh, no, not a pdf. Just a text file. STILL
<clever>
Mondenkind: i can tell just from the ZM at the front, that its a "valid" windows PE binary, lol
<clever>
or where those MZ?
<clever>
but getting binary offsets with only ascii, is another ordeal entirely...
<kazinsal>
MZ and ZM are both valid magic numbers for DOS/Windows EXEs
<clever>
kazinsal: what is the difference between the 2?
<kazinsal>
nothing
<clever>
weird
zacque has joined #osdev
<Mondenkind>
maybe working around endianness bugs in early linkers?
<Mondenkind>
int magic = 'MZ'; //oops
<Mondenkind>
err that should be /* for the true retro feel
<clever>
Mondenkind: i know that zfs takes advantage of that endian flip, all records are written in native order, and if the magic# is backwards when you read it, you need to flip every field
<clever>
so writing is always fast, and reading is fast if it came from the same endianness
<Mondenkind>
cute
<Mondenkind>
I would probably just say everything is little endian and fuck you if you're be. Probably more practical. But I still really like that
<clever>
but ext4 uses BE in a lot of its core metadata, and LE in the journal
<Mondenkind>
._.
<clever>
the journal was coming from a different codebase, with diff rules