hwpplayer1 has quit [Remote host closed the connection]
edr has quit [Read error: Connection reset by peer]
hwpplayer1 has joined #osdev
housemate has quit [Remote host closed the connection]
<zid>
Guys, with the new year coming up, it's probably time to do some cleaning up on your linux systems
<zid>
I recommend removing the french language pack, with rm -fr /
<zid>
If you want it to also remove the latin language pack, add --no-preserve-root
hwpplayer1 has quit [Remote host closed the connection]
* kof673
points at ibis the only cure is go back to a non-corrupted version frozen in time :D
<kof673>
early chinese maybe, > Why We Still Can't Read the Writing of the Ancient Indus maybe ok....
<kof673>
stng "darmok" episode > All our technology and experience - our universal translator, our years in space, contact with more alien cultures than I can even remember...and we still can't even say hello to these people
<bslsk05>
www.cs.unm.edu: Doom as an Interface for Process Management
<isabella>
peak os design
hwpplayer1 has quit [Remote host closed the connection]
spare has joined #osdev
Left_Turn has joined #osdev
jkra has joined #osdev
netbsduser has quit [Ping timeout: 265 seconds]
jkra has quit [Quit: Konversation terminated!]
spare has quit [Remote host closed the connection]
netbsduser has joined #osdev
Left_Turn has quit [Ping timeout: 246 seconds]
FreeFull has quit [Ping timeout: 246 seconds]
Left_Turn has joined #osdev
FreeFull has joined #osdev
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
obrien has joined #osdev
pog has joined #osdev
<nikolar>
KORNUL
SGautam has quit [Quit: Connection closed for inactivity]
<sortie>
The cool thing about zsh is that it executes gzip compressed shell files
<Ermine>
hence 'z' in its name
<Ermine>
like zgrep, zcat, zless, zetc...
<sortie>
/zetc is of course the compressed configuration directory
<isabella>
lmao Ermine
<Ermine>
you can load your compressed config files into zram with zmmap syscall
obrien has quit [Remote host closed the connection]
FreeFull has quit []
FreeFull has joined #osdev
pog has quit [Quit: byee]
heat_ has joined #osdev
f_ is now known as funderscore
melnary has quit [Ping timeout: 252 seconds]
vdamewood has joined #osdev
pog has joined #osdev
rom4ik has quit [Quit: bye]
rom4ik has joined #osdev
pog has quit [Quit: byee]
gildasio has quit [Ping timeout: 264 seconds]
pog has joined #osdev
sdomi has quit [Ping timeout: 245 seconds]
sdomi has joined #osdev
goliath has joined #osdev
goliath has quit [Quit: SIGSEGV]
netbsduser has quit [Ping timeout: 265 seconds]
netbsduser has joined #osdev
gildasio has joined #osdev
msv has joined #osdev
alexander has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
alexander has joined #osdev
Turn_Left has joined #osdev
melnary has joined #osdev
Left_Turn has quit [Ping timeout: 248 seconds]
melnary has quit [Remote host closed the connection]
melnary has joined #osdev
<the_oz_>
zfs zos zapple zindewz
<the_oz_>
zurkle zyztem ziztributzion
xenos1984 has quit [Ping timeout: 272 seconds]
xenos1984 has joined #osdev
<pog>
mrrp
mpetch has quit [Ping timeout: 240 seconds]
ionut_f has joined #osdev
<the_oz_>
oooOOOoooohhhh tel e phone yup yupyupyupypyipyip
bauen1 has quit [Ping timeout: 252 seconds]
bauen1 has joined #osdev
xenos1984 has quit [Ping timeout: 264 seconds]
funderscore is now known as f_
craigo has quit [Quit: Leaving]
xenos1984 has joined #osdev
<mcrod>
hi
<ring0_starr>
has anybody tried an OS that extensively uses segments the way they were intended?
<ring0_starr>
I vaguely recall the designer of the 8086 explaining how segments were intended to be used, like they were meant to describe a file loaded into memory, and any accesses within that segment out of bounds causes a fault
<ring0_starr>
and then you can expand file to any discrete data structure like a network packet for that matter
<ring0_starr>
so bounds checking kinda becomes irrelevant because that gets automatically handled by the segmentation
* kof673
.oO ( did anyone read the instructions first? <crickets, tumblewood, wolf howls, crow caws, shambles> )
<kof673>
*weed
<the_oz_>
x86_64 still uses but assumes values that makes it irrelevant, but it depends on the hardware and I do not have that kinda time
<the_oz_>
so not really, for me because I'm gonna ignore x86
hwpplayer1 has joined #osdev
<ring0_starr>
and here we have the circle of time
<the_oz_>
but try setting it up in the LDT'/GDT and see if your processor will even let you
<ring0_starr>
in the beginning there were flat address spaces, this is widely considered to be clean and easy to reason with, state of the art. then we enforce bounds in accessing memory objects by adding program logic, and/or in the runtimes of the programming languages
<ring0_starr>
then somebody comes along and says "oh wow, what if we had entire virtual address spaces for single memory objects instead of entire processes"
<ring0_starr>
and then segmentation is re-born
<Ermine>
flat memory model and pages handle all of this just fine
<the_oz_>
it's not that segmentation is reborn, it's that entire code bases baggage is what is actually the limiting factor
<ring0_starr>
it doesn't, otherwise there would've never been any memory corruption bugs
<the_oz_>
if everyone coded in asm for their hardware ffs etc etc
<kof673>
i have about 7 "ELAN SC520" system on a chips (soekris net4501 and similar models), which are AMD 586-ish....that cpu has a "programmable address region" 16 of them, supposed to be faster than the normal x86 stuff, they let you set regions that are "noncacheable, write-protected, and/or nonexecutable buffers"....so i ever get that far i will mess with those, but that is both ancient and cpu-specific
<kof673>
can be used in addition to the normal x86 stuff
<ring0_starr>
it's not like what i'm saying would be possible unless you were able to start from scratch, most of the problems with computing are caused by: A). reinvention of old concepts B). misunderstanding of current concepts C). interoperatbility with broken things
<kof673>
it is the cycle of conway's law, hindsight is 20/20/etc.
<kof673>
everything does that...
<kof673>
if you knew ahead of time exactly what you needed, you could always "optimize" more than not
<the_oz_>
the problem is the hardware assumes everyone has moved on so it fakes support maybe
<the_oz_>
it depends
<ring0_starr>
i haven't moved on because i like the old shit
<ring0_starr>
i like the capabilities of the new stuff as well, but i hate how they solve issues that wouldn't need to be issues in the first place if only...
<the_oz_>
for instance a20 line flipping
<\Test_User>
memory corruption bugs would still be a thing, just usually more limited (and entirely possible that the program now just selects the wrong segment instead to corrupt memory with)
<ring0_starr>
lol a20 line is an anacronism
<the_oz_>
segmentation is an anachronism
<the_oz_>
see?
<ring0_starr>
segmentation is a concept, a20 line used to be a real thing 40 years ago
<the_oz_>
tell that to x86_64
<ring0_starr>
the a20 line is like the OS dev equivalent of a floppy disk icon for saving
<ring0_starr>
but it sure makes a good story to tell the kids when they ask "why does we gotta do that outb"
ionut_f has quit [Remote host closed the connection]
<\Test_User>
a20 line's problem is that it [probably] should've just been dependent on the cpu mode (and then there would be no such problem, though it would still "exist") and the weird things you'd have to do to toggle it; not related to its age
xenos1984 has quit [Ping timeout: 252 seconds]
hwpplayer1 has quit [Remote host closed the connection]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<ring0_starr>
can you imagine how clean it'd be if we had modern software on modern hardware without being weighed down by 5000000000 security mitigation things
<\Test_User>
also if you actually want to do this on x86, you're probably going to run into issues with the number of segments you can have
<ring0_starr>
yea i was about to add that caveat
<ring0_starr>
perhaps if the concept is applied everywhere it'd just turn into hardware fat pointers
vdamewood has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
xenos1984 has joined #osdev
<the_oz_>
Did you know you can use relative addressing based on implicit understanding?
<the_oz_>
By convention alone!
<ring0_starr>
without automatic bounds checking and fault handling
<the_oz_>
>assuming your CPU implements that
<ring0_starr>
the 80286 does, which is why i brought it up
<the_oz_>
I'm on a bunch of x86_64
<the_oz_>
running in x86_64 mode
<zid>
That's why the LDT exists!
netbsduser has quit [Ping timeout: 244 seconds]
<the_oz_>
yes
<\Test_User>
still only ~8k/task for the LDT, which is a problem if you want to try using one per object or similar as they seemed to want
<zid>
well you can't go beyond the hw limits no, but the LDT is still your best shot
<ring0_starr>
i mean it's not really feasible after thinking about it out loud because there is the 8k limit and it'd force you to pass around the segment along with the address which would defeat the purpose
<ring0_starr>
without disciplined usage, the segment number would need to become part of the pointer itself which would be subject to corruption
<the_oz_>
whaddya mean relative pointers aren't the standard usage
<\Test_User>
it retains some of the bounds advantage since you're just adding/subtracting on the 'index' part, not the segment itself, but yeah it's certainly not going to solve all of your memory safety problems. not really anything the hardware can do anyways to ensure you don't access the wrong index (or wrong segment); only check that it's valid, so you're still going to have to write your programs correctly
<zid>
Yea, at this point, you just write it in a managed language
<zid>
and skip all the slow segmentation and just do slow bounds checks
<ring0_starr>
segmentation is only slow because the hardware is unoptimized for it because it fell into disuse
<ring0_starr>
bounds checks are extra cmps and jmps
<ring0_starr>
i just feel like shifting the burden onto the programming language is kind of unfair
<\Test_User>
segmentation is just a hardware-level cmp&jmp
<ring0_starr>
i don't know. maybe having hardware fat pointers (the logical conclusion of my proposal) isn't so bad because the ISA would have support for them built in as well and it'd be streamlined and optimized
<\Test_User>
(well, bit fancier than jmp, since access violation, but you get the point)
<ring0_starr>
that feels too reductionist to me, there's always going to be extra overhead if it goes into software
<zid>
It's slower and the error path is slower
<the_oz_>
You're not going to convince many to uptake the increased responsibility on their own (though stranger things have happened) without abstraction into something sellable like "here use this language it's got coroutines!" for example
<zid>
the segmentation ends up adding a cycle to *every* memory op, but with good bounds removal on flat segments you get 0 cycles added
<ring0_starr>
or it could be +1 latency...
<ring0_starr>
whereas with the explicit bounds checking that's at least +4 bytes of instructions and +2 cycles
<ring0_starr>
the_oz_: yeah but what if WW3 broke out and there was a global EMP shockwave that killed everything and we needed to start from scratch. i am not going for practicality here, just thought experiments
<ring0_starr>
the optimal path for what we have right now is always going to look different from the optimal path for an earlier starting point
<zid>
and the error is a segmentation fault, rather than a jc hitting :P
<the_oz_>
imagine not needing bounds checking becasuse you could prove your codebase never esxceeded bounds
<the_oz_>
then you just add the verifier into the compiler
<\Test_User>
+2 cycles? my cpu seems able to combine a cmp and a conditional jump into a single cycle
<the_oz_>
no need to do at runtime what you never do at all
<zid>
unlikely(if(badptr)) should be free most of the time
<zid>
while waiting for the memory to come back
<ring0_starr>
Test_User: that implies it's a single instruction
<\Test_User>
ring0_starr: my cpu can do >1 IPC (as is typical for x86_64)
<ring0_starr>
yeah with pipelining, i'm not sure what the right phrasing is
<ring0_starr>
two slots added to the pipeline with two instructions
<ring0_starr>
not two whole cycles
<\Test_User>
then, yeah, it's +1 latency on your fat pointer stuff (cpu does cmp&cond jmp while waiting for speculative memory return, or perhaps while doing that other instruction if the memory is there; could be made optional hardware-level too) vs +1 latency (for any memory access even if you already know it's not out of bounds)
<\Test_User>
well, +1 latency isn't right on the first case there, it's more like "might interfere with other instructions being computed, if it's not waiting for memory or the likes"
<ring0_starr>
speculat......
<ring0_starr>
nevermind
<kof673>
> because the hardware is unoptimized for it if the hardware and software are designed together, then greater gains are possible
<kof673>
but you see, this is basically your fault for not being born with a cpu/chip/hardware/factory j/k
<kof673>
you could write things as if an instruction existed, and then wait until someone implements it
<kof673>
if this c or posix or....then theoretically people lobby somehow for new functions. does that exist anywhere for cpu instructions? it is internal to the vendor i suppose
<kof673>
*hardware<space> *if this was
<kof673>
do people lobby arm or whoever to add some new instructions?
<the_oz_>
there's some kinda working group to confer with other compasnies and such iirc
<the_oz_>
no idea how approachable they are, doubt very
<zid>
\Test_User: Don't forget that you can amortize the tests too, so if a for loop is over 128 bytes of object or whatever, then you do the check *once* outside the loop, then 128 memory accesses
<kof673>
> A CPU designed using an HDL for an FPGA is called a soft core. > Design of A Soft-Core Processor in FPGA the normal person can screw around with those, but how much work is this, cost, .... [microblaze] > top speeds of more than 700 MHz (on Virtex UltraScale+ FPGA family)
<kof673>
i am not advocating such, but that is [the spoken reason anyways] why people of yesteryear wanted One Giant "Company" to theoretically reduce the layers of "inefficiencies" > King Camp Gillette > all industry should be taken over by a single corporation owned by the public, and that everyone in the US should live in a giant city called Metropolis powered by Niagara Falls. A later book, World Corporation
<kof673>
of course, if it is just one giant entity making everything, you would think such a person would recognize that could create more problems :D > the double-edged safety razor
<kof673>
c.f. "i know, i'll use a regular expression!" "now you have 2 problems"
cloudowind has quit [Ping timeout: 252 seconds]
cloudowind has joined #osdev
<heat_>
linux kernel
<mcrod>
LIENIXU KERNAL
<sham1_>
Did someone say kernal‽
sham1_ is now known as sham1
<zid>
no but someone said WORKBENCH 47.4
<heat_>
did someone say UNIX PROGRAMMERS WORKBENCH
<pog>
kronel
<zid>
No, amiga workbench heat
<heat_>
no hablo amigo
<zid>
Ein hablez amigoes por pa thanks
<zid>
sumimasorry
vdamewood has joined #osdev
<kof673>
Conan the Barbarian: [chuckles] Amiga Crom laughs at your four winds windows logo. He laughs from his mountain.
<cloudowind>
gemini is no way near to chatgpt
Turn_Left has quit [Read error: Connection reset by peer]