<sortie>
sonny, that's a multi process compositing gui that happens to run four terminal emulators that are nicely tiled
<sortie>
That's just the code page 437 font although /dev/urandom is indeed being decoded as UTF-8
<gog>
how do i join te professional sortix network
<sortie>
gog, irc.sortix.org
<gog>
hmm do i need another irc serveer
<sortie>
Yes, a professional Sortix irc server
<sortie>
Who knows if this libera thing sticks around
<sortie>
Join the federation of hobby osdev ircd's
<sortie>
klange, who needs the minutely distractions as the clock updates??
<sonny>
damn, at this rate I'll have to start my OS in userspace if I want to get on the federation
<mrvn>
Mutabah: FDs can be passed between processes too
<sonny>
also curious, the terminal is easier than drawing text with opengl?
<sonny>
well, I guess you are already doing that
<sortie>
what is opengl
<sortie>
i am memcpy to framebuffer
<sonny>
oh lmao
<sonny>
neat trick
<klange>
sortie: my clock has been a valuable debugging tool, lets me know things are still running on systems I can not interact with ;)
<mrvn>
klange: does it tell time too?
<sortie>
I need some sort of multi process session concept for the panel I guess
<klange>
not on the rpi :D
<mrvn>
I feel you. I have the same problem.
<mrvn>
every time I try it's 1970 again.
<klange>
My default time is two weeks okay. I just shoved the current time in as the default.
<klange>
But I did implement a terrible `settimeofday` so with the serial console I can set the time
<sortie>
I'm sorry, are they really building tech without an RTC?
<sortie>
how the fuck does Linux work?
<klange>
NTP on boot
<sortie>
NTP in bootloader?
<klange>
I don't think so.
<sortie>
Or during init?
<mrvn>
reads the time of last mount from the FS
<sortie>
Not the worst idea
<klange>
That's also a thing ^ gets you something that's not several deacdes off until you get to the Internet
<mrvn>
fsck,ext4 fails otherwise.
<mrvn>
no checking filesystems from the future, no no.
<klange>
s/two weeks okay/two weeks ago/
<sortie>
k let's see if my magic compiles
<klange>
Magic does not compile. It is cast.
<sortie>
It did not
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<mrvn>
Ocaml does it right. It has Obj.magic : 'a -> 'b
<mrvn>
magic always compiles.
[_] is now known as [itchyjunk]
MrBonkers has quit [Ping timeout: 240 seconds]
MrBonkers has joined #osdev
<sortie>
Dragging the window by the title bar works :)
<sortie>
Resizing them .. well .. goes wrong
<klange>
i tried to add non-lazy resize to my compositor and kept screwing it up, so I gave up :)
<sortie>
non-lazy?
<klange>
s/gave up/determined it was not a valuable investment of time and refocused my efforts on other priorities/
<klange>
lazy resize: while the user is resizing a window, you do not actually change the window size - you present a box, or stretch the window texture
<klange>
non-lazy: as the user drags the edge, the window resizes immediately and the application must recalculate+redraw as it goes
<moon-child>
what were the problems you encountered?
<klange>
Lazy resize is something we did in Compiz; at the time, non-lazy resizing for composited windows was taxing on hardware.
<klange>
Mostly that my existing implemenetation is built around how the lazy resize works with window locations + actual sizes.
<klange>
And some complicated interactions especially when resizing the left or top edge, which would need to update the window location.
<moon-child>
I mean, isn't non-lazy resize just lazy resize but you refresh more frequently?
<klange>
I tried to do that, too, but ran into some problems with how I move windows to handle the up/left resizes :D
<klange>
I'll revisit it later, when I've made more progerss with this rpi stuff.
<sortie>
Ah the resizing logic got confused between the window size as far as the client is concerned vs. the size with decorations applied
* moon-child
has not yet bothered with window resizing yet, but has that sort of dynamic-layout for e.g. splitters (which worked without a hitch), so was curious if there were unique challenges involved
<mrvn>
you can also do half-lazy resize. While you resize the window content is scaled.
<mrvn>
klange: does every window have it's own framebuffer?
<klange>
Yes, that's generally how compositing windowing systems work.
<mrvn>
then why would it matter what corner you drag? The window position only affects the compositor and the size the app.
<moon-child>
as I recall, in some old version of macos (9?), apps would draw directly onto the presentation buffer, and an overflow would mean ... ...
<sortie>
k resizing at one edge works now, although I should keep track of being in the resizing state, cuz the cursor easily moves out of the magical region
<mrvn>
moon-child: That's how it's been for ages because memory is expensive.
<klange>
moon-child: Pretty much all windowing systems used to have applications draw "directly" into the actual framebuffer.
<moon-child>
mrvn: I don't think anyone's done that for decades now
<mrvn>
compositing on the fly is still a rather new thing
<mrvn>
moon-child: X still does it
<moon-child>
does it?
<moon-child>
I was going to point out X as an example of a protocol that _doesn't_ do that
<mrvn>
moon-child: the procotol doesn't, the server does.
<moon-child>
I mean, it's a network protocol first. Then you have xshm and glx. The latter, obviously you get your own framebuffer. I assume it's the same with xshm (though I haven't actually used it)
<moon-child>
mrvn: sure, implementation details. The point is, you don't hand one client a buffer which potentially aliases another client's buffer
<mrvn>
moon-child: oh yeah, that's a different thing though.
<klange>
I put "directly" in quotes above because it's not really "here's the actual framebuffer memory, have fun".
<mrvn>
but X fails at it too. You can open a window and read the content and get whatever was below the window because it hasn't redrawn yet.
<klange>
It's typically been what I call "pen-based". The windowing system holds the pen and lets the application tell it what to draw.
<klange>
But it always draws directly on the framebuffer.
<moon-child>
mrvn: ah, yeah, I have had that happen
<klange>
Some graphics systems literally call this concept a "pen" which si why I use that term.
<mrvn>
It's because internally the window just has a view of the framebuffer it clips against.
<moon-child>
klange, sounds like canvas
<moon-child>
(/postscript/svg/clones)
<mrvn>
klange: when you resize to you reallocate the windows FB on every pixel movement?
<klange>
mrvn: if I were doing non-lazy resize, I would have to do that, yes. That was one of the reasons we did lazy resize in Compiz.
<klange>
If you're doing power-of-two square GPU textures you can be much more efficient...
<klange>
But Yutani's basically hands everything a packed linear framebuffer; stride = width
<mrvn>
How does that work? The resize event send to the app includes the address of the new FB and when the event gets ACKed you free the old one?
<klange>
Server-initiated resize is:
<klange>
"Hey, I want you to be X by Y, is that okay?" "Yes, I can do that." "Okay here's your new framebuffer, let me know when it's ready." "Thanks, it's ready, you can swap to the new one." "You are resized."
<moon-child>
I mean, I don't think you would need padding at the end of each scanline, necessarily. Just some kind of exponential backoff/lazy reallocation for the whole buffer
<mrvn>
That'S an awfull lot of round trips.
<mrvn>
One obvious optimization is that while resizing and when the size is smaller keep the existing FB and just change the stride and height.
<mrvn>
And when growing grow the FB in larger steps than the mouse moves. Only get the optimal size when the mouse button is released.
<mrvn>
klange: iirc in X the application sets resize hints for the window manager. Like a terminal emulator can only grow in font size increments. So the server knows what resizes are legal and the app doesn't need to be asked and just gets the new size.
<klange>
Yeah, I want to add those.
k8yun has quit [Quit: Leaving]
<mrvn>
I would add flags to say if the window content should be lazy resized / scaled or if the redraw is cheap enough to do non-lazy.
<mrvn>
You don't want something like firefox redo the whole page layout during resize for example.
<mrvn>
.oO(Or maybe nowadays you do want that, it's what X does here)
<mrvn>
I remember times when you resized a window, let go of the mouse button and then you could watch the app redraw over and over again in different sizes for a minute.
<mrvn>
Merging resize events when the app can't keep up redrawing is essential I think.
<sortie>
Neat! It works!
<sortie>
It flickers like crazy since the window buffer is cleared on each resize pending the client redraw, there's no cursor for the resize mode, and it doesn't keep track of the resize state so too big mouse movements leaves the magical region
<sortie>
^ "better than nothing"
pretty_dumm_guy has quit [Ping timeout: 245 seconds]
<mrvn>
why would you clear the region?
gog has quit [Quit: byee]
<mrvn>
are you trying to give people ceisures?
<mrvn>
seizure I mean
<sortie>
Just how I happened to implement the resize message
<sortie>
I mean the alternative is a framebuffer reinterpreted at the right size which looks corrupted and also seizures
<sortie>
Or going out of my way to memcpy the contents as a crop, which is, well, wrong
<sortie>
If not actively unpleasant
<sortie>
Curiously the memset to 0 makes the window fully transparent due to the rgba logic
<sortie>
I need to speed up rendering with shared memory and other tricks
<klange>
> I mean the alternative is a framebuffer reinterpreted at the right size which looks corrupted and also seizures
<klange>
This is one of the things that using power-of-two textures like a GPU can help ease
<klange>
and it's also why I do buffer swaps
<klange>
I never re-interpret a buffer as different dimensions, always make a new one and swap.
<sortie>
I mean, I want to have fast rendering, and wait for the client to quickly redraw, and not lose a vsync, frame perfect
<sortie>
With some sort of graceful fallback if the machine isn't fast enough
<klange>
If you really want frame perfect, you want page flipping double buffering, every application has two buffers available.
<sortie>
^
<klange>
Expensive, though. I didn't do it for normal drawing.
<sortie>
But for now, I am just trying to be a tech demo that's more useful than nothing
<klange>
I think I have all the necessary plumbing for it, but it's not been on my radar. Plus actual vsync timing is butts, so a little tearing here and there is just par for the course.
<sortie>
Yeah not going for vsync either
<moon-child>
vsync timing is, in fact, butts
<klange>
Oh right, when I posted the screenshot earlier I was going to also note functionality I have for my tiling...
<sortie>
I can at least just avoid drawing inconsistent frames insofar possible
<mrvn>
sortie: why not do lazy resize till you get a new framebuffer from the app?
<klange>
I have super + up/down/left/right key binds, as well modifiers to do 1/4 splits with ctrl/shift, based on the key binds I used to use on laptops for Compiz
<sortie>
mrvn, that's sort of the plan
<klange>
and I also have drag-to-edge for the left/right half-splits, and drag to top maximizes.
<sortie>
Although that can suck if the redraw is slow
<sortie>
=> degrade to a crop
<klange>
I did a bunch of work to make my client-side decorator work nicely with tiling, so it gets passed flags about what edges are tiled and can make things look nice.
<sortie>
=> degrade to a rightmost/bottommost fill
<mrvn>
sortie: the old window remains visible till the app sends a new fb.
<sortie>
mrvn, yes, and then resizing is laggy as fuck
<sortie>
:)
<mrvn>
sortie: no, you see the lazy box for the resize.
<klange>
It's not laggy. It's immediate upon completion.
<klange>
You do not resize until the end of the motion, that's what makes it lazy.
<sortie>
Right
<sortie>
Well I am resizing non-lazy
<sortie>
Was easiest
<mrvn>
sortie: you mix lazy and non-lazy resize. Every time the app ACKs a resize with a new FB you update the window proper. The rest just the box around it.
<klange>
I have some issues I need to fix still
<mrvn>
I also don't buy that scaling the window proper on resize would be horrible.
<klange>
I stretch the window.
<mrvn>
GPUs can scale and interpolate quite well and fast.
<klange>
GPUs my ass, I software scale that shit.
<klange>
Works fine even in TCG.
<mrvn>
hehe
<klange>
I have a problem because of this, though, which is that for a brief moment before the client has resized I show the original window at its original size
<klange>
Need to fix that...
<mrvn>
If you combine scaling with non-lazy resize you should get great quality.
* moon-child
doesn't like software rendering, also doesn't like the idea of writing a gpu driver
<sortie>
mrvn, you keep using that word... gpu
<moon-child>
I imagine if I try to write one I'll emerge from a cave 10 years hence, with wild hair muttering something about command descriptors
<mrvn>
nah, scale in software for all you want
<sortie>
My drawing is slow as shit :P
<sortie>
niht
<mrvn>
just clearing the screen takes me 4+ seconds.
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
dude12312414 has joined #osdev
pounce| has joined #osdev
pounce| is now known as pounce
srjek has quit [Ping timeout: 240 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
Belxjander has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sonny has joined #osdev
<geist>
Klange: maybe you can give me a good answer: what are affine transformations?
<Mutabah>
Affine transforms are just rotations and translations
<geist>
At least in this case
<Mutabah>
I.e. shapes are preserved
<geist>
Ah okay. Yeah in this context makes sense
<geist>
I’ve also heard people use it at work to describe things like translating from one time base to another
<geist>
Which i guess is the same thing, just on a 1D line
<Mutabah>
Importantly, affine has no scaling or skew
<graphitemaster>
Yeah affine is basically a 3x3 matrix. You can rotate, you can translate, you can even flip, you just cannot do so in a perspective-correct manner.
<graphitemaster>
So they're good for 2D and that's about it.
<Mutabah>
3x3 does perspective too
<geist>
Ah versus a more complex transformation that also can do the others
<geist>
And probably requires additional rows/coils
<graphitemaster>
3x3 cannot do perspective, it can do shearing
<Mutabah>
(I work a lot with 2d->2d perspective matrixes in my job)
<graphitemaster>
perspective requires more than a shear
<Mutabah>
Well... 3x3 with a division can do perspective
<geist>
I’ve used those sort of matrix translations just didn’t have a name for it
<graphitemaster>
Yeah, afterwards, but those don't compose generally with 3x3 matrices, if you want the perspective as part of the matrix compose then you need 3x4 / 4x3 at minimum (assuming uniform scale), and 4x4 if non-uniform scale
<geist>
Yah
<Mutabah>
point
<graphitemaster>
householder transforms or spectral / qr decomposition can actually recover rotation and translation under a non-uniform scale in a 3x4/4x3 in many cases which is kind of cute
<graphitemaster>
but meh meh
<graphitemaster>
too complex
<graphitemaster>
just go 4x4 everything everywhere all the time, save your pain
ElectronApps has joined #osdev
<geist>
Yah that’s generally what I’ve seen
<geist>
Also nice and regular for vectorization
<moon-child>
I just realised a single avx512 register can hold a 4x4 matrix
<moon-child>
wonder if they added a dedicated matrix multiplication op
<geist>
Dunno. I remember ARM having some sort of stuff i think in this area with SVE
<geist>
And of course I always have to tell the tale of the 4x1 * 4x4 op that SH-4 had
<geist>
4 of those and you got a matrix multiply
<moon-child>
oohh nice
<geist>
At the time it was really neat. Basically treated 16 FP regs as a 4x4
<geist>
(And yeah I know, 1x4*4x4)
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
Jari-- has quit [Ping timeout: 240 seconds]
Payam has joined #osdev
scoobydoo has quit [Ping timeout: 250 seconds]
<klange>
Mutabah: scaling and skewing are affine
<klange>
The key property of affine transformation is that ratios of lengths of parallel lines are preserved.
<klange>
so you can't squeeze the top of something while preserving the bottom, and hence can not achieve perspective mapping.
<klange>
Scaling is actually the important thing about arbitary affine transformations that I needed to allow rotated windows to be resized. Previously I could scale _or_ rotate, but not both at the same time, as they were independent rasterization techniques
<klange>
(rotation in an affine transformation space is equivalent to skewing [also known as shearing])
<klange>
(old versions of MS Paint couldn't do arbitrary rotations, but they could skew, so you could (somewhat destructively) repeatedly skew to achieve the same effect)
<bslsk05>
'2022 03 03 15 53 36' by K Lange (00:00:39)
<Mutabah>
Ah
<kazinsal>
I love the rotation gimmick
<Mutabah>
I must have got confused by some old work code that was called "affine" but had no scale/skew
<clever>
you need to rotate the resize mouse pointer too
<clever>
when the window is at 45, the left/right resize isnt at 45!
<klange>
I really do.
<klange>
Imagine what happens when it's rotated 90°! It's all wrong!
the_lanetly_052_ has quit [Ping timeout: 240 seconds]
<klange>
I could do something exceptionally over-complicated like add a full dynamic mouse rendering system using my fancy new vector rasterizer so it's done on the fly, but the shading is all correct...
<klange>
Or I could just rotate the texture like the window.
[itchyjunk] has quit [Read error: Connection reset by peer]
<kazinsal>
the cray was also not a consumer-grade microprocessor architecture
GeDaMo has joined #osdev
<geist>
neat: "This instruction takes the contents of floating-point registers XF0 to XF15 indicated by XMTRX as a 4-row × 4-column matrix, takes the contents of floating-point registers FR[n] to FR[n + 3] indicated by FVn as a 4-dimensional vector, multiplies the array by the vector, and stores the results in FV[n]. "
<geist>
it does point out that the precision is *not* as good as a FADD/FMUL sequence, and it's explicitly designed to be fast
<geist>
it is interesting though that it appears to have some internal register state because it does all the muls first, then aligns, then adds the aligned values
<geist>
moon-child: side note i do recommend reading the cray software manual. it's a fascinating design
<geist>
some of it is quite modern, some of it is totally weird
<bslsk05>
yam.20to4.net: SEGA Dreamcast Programming Hints
<kingoffrance>
s/had/has/
<graphitemaster>
SSE 4.1 has dpps (dot product) x4 for a 4x4 matrix-mul, but absolutely no one I know uses it since a mulps followed by a horizontal sum of that is sufficient, could also use two of SSEs' hadd but that's a bit slower than two regular adds and a shuffle from my tests
gdd has quit [Ping timeout: 272 seconds]
<energizer>
remexre: did you find that diagram of cpu state?
Payam92 has joined #osdev
Payam has quit [Ping timeout: 256 seconds]
dormito has quit [Quit: WeeChat 3.3]
Burgundy has joined #osdev
dormito has joined #osdev
vin has quit [Quit: WeeChat 2.8]
the_lanetly_052_ has joined #osdev
<klange>
I remembered something important that I had realized the last time I was trying to do non-lazy window resize...
<klange>
my signal mechanism is completely broken
<klange>
I'm pretty sure it's even more broken than it was in the old kernel... I think I broke it _more_...
<klange>
So that needs a major overhaul.
<klange>
Something to do this weekend instead of XHCI!
zid has quit [Ping timeout: 272 seconds]
zid has joined #osdev
dormito has quit [Ping timeout: 272 seconds]
dennis95 has joined #osdev
scoobydoo has joined #osdev
dormito has joined #osdev
cvemys has left #osdev [#osdev]
Osm10 has joined #osdev
SikkiLadho has joined #osdev
SikkiLadho has quit [Client Quit]
SikkiLadho has joined #osdev
the_lanetly_052_ has quit [*.net *.split]
wolfshappen_ has quit [*.net *.split]
g1n has quit [*.net *.split]
j00ru has quit [*.net *.split]
Belxjander has quit [*.net *.split]
thinkpol has quit [*.net *.split]
air has quit [*.net *.split]
paulbarker has quit [*.net *.split]
Guest127 has quit [*.net *.split]
basil has quit [*.net *.split]
alpha2023 has quit [*.net *.split]
amj has quit [*.net *.split]
CompanionCube has quit [*.net *.split]
seds has quit [*.net *.split]
ssiyad has quit [*.net *.split]
night has quit [*.net *.split]
warlock has quit [*.net *.split]
nanovad has quit [*.net *.split]
kaichiuchu has quit [*.net *.split]
jeaye has quit [*.net *.split]
the_lanetly_052_ has joined #osdev
amj has joined #osdev
paulbarker has joined #osdev
alpha2023 has joined #osdev
basil has joined #osdev
thinkpol has joined #osdev
Guest127 has joined #osdev
Belxjander has joined #osdev
air has joined #osdev
j00ru has joined #osdev
seds has joined #osdev
wolfshappen_ has joined #osdev
g1n has joined #osdev
ssiyad has joined #osdev
night has joined #osdev
nanovad has joined #osdev
jeaye has joined #osdev
CompanionCube has joined #osdev
kaichiuchu has joined #osdev
warlock has joined #osdev
ssiyad has quit [Max SendQ exceeded]
wolfshappen_ has quit [Max SendQ exceeded]
ssiyad has joined #osdev
wolfshappen has joined #osdev
<SikkiLadho>
I'm trying to build a tiny hypervisor on raspberry pi 4 which only passes the control to linux kernel. However, I can only successfully load a linux kernel compiled with ARM-GNU toolchain. Kernels compiled with aarch64-linux-gnu-(RPI docs suggest this.) cannot be loaded, I can only see blank screen. Here are the uart logs with and without
<clever>
SikkiLadho: is this maybe a 32bit vs 64bit difference?
<SikkiLadho>
Nope, I tried the same kernel repo and config but compiled with different compilers, one ran while other didn't.
<clever>
thats strange
<j`ey>
SikkiLadho: have you tried the 2nd kernel w/o your hypervisor?
<zid>
aren't these logs also completely valid boots?
<SikkiLadho>
Both kernels work without the hypervisor, but with the hypervisor, only one compiled with ARM-GNU toolchain works.
gog has joined #osdev
[itchyjunk] has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
pyzozord has joined #osdev
<pyzozord>
Hey, how does kernel measure cpu usage? It must be timing each process in the scheduler and then summing up the timings for a process for the last second, right?
<gog>
yes
<mjg>
depends, the easiest appraoch is that you check who is on cpu when the timer ticks
<mjg>
and you pretend they used the entire slice
<mjg>
afair linux has a better granularity
<mjg>
with explicitly tracking when you go on/off
<gog>
well the kernel itself doesn't typically measure this, userpsace tools will iterate through the process/thread listings and do the math
<gog>
but the scheduler does keep track
<mjg>
unix systems do measure it
<mjg>
you can query it with waitpid
<mjg>
erm, wait4
<gog>
ah ok
SikkiLadho has quit [Quit: Connection closed]
<mjg>
this is how time(1) works
<gog>
i meant in terms of displaying it as a percentage of used/idle
X-Scale` has joined #osdev
SikkiLadho has joined #osdev
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
SikkiLadho has quit [Client Quit]
masoudd has quit [Read error: Connection reset by peer]
masoudd has joined #osdev
SikkiLadho has joined #osdev
<zid>
basically, scheduler is counting it up anyway to try be 'fair'
<zid>
so it's not hard to export it out of /sys or /proc or whatever
Osm10 has quit [Quit: Client closed]
<pyzozord>
wait, what's that userspace measuring about?
<pyzozord>
how do userspace program iterate through processes and how can it compute cpu usage?
<gog>
on linux for example, a program like top would look through all the entries in /proc
xenos1984 has quit [Read error: Connection reset by peer]
<gog>
and compute the time spent in each process every second
<gog>
or when you force update or whatever interval you set
SikkiLadho has quit [Quit: Connection closed]
srjek has joined #osdev
zaquest has quit [Quit: Leaving]
xenos1984 has joined #osdev
blockhead has quit []
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 240 seconds]
<mrvn>
.oO(The sound of silence)
<mrvn>
graphitemaster: Who has sse 4.1 and optimizes for that?
zaquest has joined #osdev
<pyzozord>
gog: how would they "compute time spent in each process"?
<mrvn>
pyzozord: the process stats file has a counter
<gog>
pyzozord: they look at the schedstat file yeah
<pyzozord>
ok but then it's still the scheduler that keeps track of how long each process takes
<gog>
yeah
<gog>
updating those fields at relevant times
<mrvn>
pyzozord: the user space only computes how much is idle and the %
<mrvn>
Or ask another way: how do I sum up the 4 doubles?
dude12312414 has joined #osdev
<mrvn>
oh never mind, my typedef is wrong.
Payam92 has quit [Quit: Client closed]
ravan has joined #osdev
<pyzozord>
those seem like gnu extensions
<pyzozord>
I mean __attribute__ and __vector
[itchyjunk] has quit [Read error: Connection reset by peer]
<pyzozord>
oh nevermind it was unrelated to my question
<pyzozord>
well thanks for help everyone
pyzozord has left #osdev [#osdev]
[itchyjunk] has joined #osdev
Electron has joined #osdev
ElectronApps has quit [Read error: Connection reset by peer]
k8yun has joined #osdev
Electron has quit [Remote host closed the connection]
<remexre>
energizer: i have not found one
<GeDaMo>
What diagram are you looking for?
<mrvn>
Stockmarket prizes 2022 - 2025 please.
<GeDaMo>
Pfft! My time machine is out of unobtanium :P
sprock has quit [Ping timeout: 252 seconds]
<remexre>
GeDaMo: chart describing all architecturally-visible state to an x86_64-linux userspace process
vdamewood has joined #osdev
zaquest has quit [Read error: Connection reset by peer]
<mrvn>
remexre: including all the debug and profiling registers the userspace has access to?
<remexre>
mrvn: would be great if it did
<GeDaMo>
Is this a diagram you've seen before or are you just hoping it exists? :P
<remexre>
hoping it exists
zaquest has joined #osdev
kkd has quit [Read error: Connection reset by peer]
sonny has joined #osdev
sonny has left #osdev [#osdev]
kkd has joined #osdev
mahmutov has joined #osdev
k8yun has quit [Quit: Leaving]
dennis95 has quit [Quit: Leaving]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
pretty_dumm_guy has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
k8yun has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
k8yun_ has joined #osdev
k8yun has quit [Ping timeout: 256 seconds]
dennis95 has joined #osdev
masoudd has quit [Ping timeout: 256 seconds]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
immibis has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
JanC has quit [Remote host closed the connection]
JanC has joined #osdev
srjek has quit [Ping timeout: 250 seconds]
blockhead has joined #osdev
immibis has quit [Read error: Connection reset by peer]
immibis has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
immibis has quit [Read error: Connection reset by peer]
immibis has joined #osdev
mlombard has quit [Remote host closed the connection]
Teukka has quit [Read error: Connection reset by peer]
srjek has joined #osdev
Teukka has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 256 seconds]
GeDaMo has quit [Remote host closed the connection]
dormito has quit [Quit: WeeChat 3.3]
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
pretty_dumm_guy has joined #osdev
immibis has quit [Remote host closed the connection]
immibis has joined #osdev
bgs has quit [Ping timeout: 256 seconds]
bgs has joined #osdev
immibis has quit [Read error: Connection reset by peer]
vin has joined #osdev
<vin>
What components in an operating system would require tuning? Example scheduling period in a task scheduler
<Ellenor>
That's one of them I guess
<vin>
Other than this? And may be the I/O scheduler
<gog>
thread pool sizes, memory pressure thresholds
<gog>
aka swappiness
<gog>
there are a lot of things that can be tinkered with to alter peformance characteristics
<gog>
linux has dozens of such things
<zid>
dmesg size
<vin>
gog: all the things in /etc/systemd/system.conf
<zid>
most important one
<vin>
zid: why is that?
<zid>
so that I don't lose any dmesg output
<zid>
I might wanna grep for what my e820 looks like when the machine has been on for years
<vin>
Okay. I think other things that are tunable can be found in /boot/config.
<vin>
Anywhere else?
<gog>
those are kernel compilation options, the tweakables are in sysctl
<gog>
the runtime tweakables that is
<gog>
there are compile-time ones in /boot/config && /proc/config.gz
<vin>
Right! Thanks
<gog>
and sysctl is just a bsd-like interface over /sysfs
<gog>
since bsd implements all that stuff in a syscall interface rather than via a VFS
<vdamewood>
gefur gog fisk.
* gog
borða fiskur
dennis95 has quit [Quit: Leaving]
Burgundy has quit [Ping timeout: 260 seconds]
<vdamewood>
Yum, coffee.
dormito has joined #osdev
* gog
holds up her mug and gives a pleading face
* vdamewood
gefur gog kaffi.
<gog>
eee takk fyrir kaffi
<vdamewood>
Það var ekkert
* vdamewood
wonders how well he's bullshitting Icelandic.
<gog>
i don't know that people say það var ekkert in that context, usually it's "minnsta málið"
<gog>
meaning roughly the same thing
<gog>
but idk, i'm mostly bullshitting icelandic on a day-to-day basis i just have a little more practical experience in it :p
<vdamewood>
That's the problem with the 'stock' phrases in a language. "Hi", "How are you?" "Thank you", "You're welcome", "Happy birthday" and so one. They almost never translate, and you really just have to memorize them.
<vdamewood>
Like, if you type "You're welcome" into something like Google Translate, you might get something like: Velkominn, which is certainly not right.
<gog>
no, that would be more like "welcome [to thing]"
<mrvn>
my scheduling period is 10 seconds.
<vdamewood>
Or even worse "Þú ert Velkominn"
<mrvn>
not sure why I would want to tune it.
<gog>
"you are the welcomed"
<vdamewood>
gog: Exactly. It doesn't translate literally.
<gog>
it's weird with icelandic because a lot of phrases do have direct transliterations
<gog>
with the germanic roots and such
<gog>
but others are absolutely not direct and make no sense
<vdamewood>
gog: One example, from a language I'm more familiar with, is Japanes. Where thanks translates to "It's a burden." or something like that. And the response is dismissice. Kind of like (Not really.)
<vdamewood>
dismissive*
nyah has quit [Ping timeout: 272 seconds]
<gog>
aha i see
<mrvn>
vdamewood: never say thanks to a fae.
<mrvn>
it aknowledges an obligation.
<vdamewood>
In Spanish and French, the phrase for You're welcome literally translates to 'of/from nothing'.
xenos1984 has quit [Read error: Connection reset by peer]
<vdamewood>
gog: Anyway, I've mostly been using google translate for literal translations and omniglot for the phrases.
<vdamewood>
The more I look at things, the more I want to put some real effort into learning (some of) the language.
<gog>
ok það var ekkert is a reply to thank you
<gog>
i have never heard it tho lol
<zid>
whoa, það is a word?
* zid
struggles to remember if it's thath or thath
<vdamewood>
Google translate says það means that/it.
<gog>
yes
<vdamewood>
Icelandic has æ right?
<gog>
it does
<vdamewood>
The old English word for that was þæt
<vdamewood>
Well, damn. Gotta ad another language to my To-Do list.
<vdamewood>
add*
ssiyad has quit [Read error: Connection reset by peer]
ssiyad has joined #osdev
xenos1984 has joined #osdev
sprock has joined #osdev
<vin>
mrvn: because I am learning optimization and wanted to apply it to my intersts. So defining constraints and an objective to find the best possible values seems fun