<mjg>
if linux is doing some funny chaining this plausibly will cause trouble
<mjg>
if they don't GC like bsd does
<zzo38>
An idea that I had seen for an operating system design is to not have "fork"; if you create a process it will be initially empty; you will have to fill it in and then unsuspend it
<mjg>
i'm turning in
<mjg>
cheers
<heat_>
hmm so the concern is just the DoS?
cow321_ has quit [Ping timeout: 268 seconds]
<Ermine>
heat_: how about asking guys concerned with those vmo chains about their case?
<Ermine>
also, fork bomb qualifies
<heat_>
not sure if charles cranor still takes emailen
gog has quit [Ping timeout: 252 seconds]
<heat_>
hmm UVM is worried about stranded memory in between the CoW chain, not exactly the length itself
dude12312414 has joined #osdev
cow321 has joined #osdev
housemate has joined #osdev
cow321 has quit [Ping timeout: 255 seconds]
<Ermine>
Woah, nvidia supports illumos
cow321 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<Ermine>
and opensuse apparently doesn't have any archives with older firmwares...
<Ermine>
oh, they do actually
dgz has joined #osdev
<Ermine>
downgrading the firmware brought iwlwifi back to life
<FreeFull>
I wonder what kind of testing they do
<FreeFull>
Clearly not enough
node1 has joined #osdev
<Ermine>
What is this 'testing' thing you're talking about? We push stuff directly into production
graphitemaster has quit [Ping timeout: 268 seconds]
m257 has joined #osdev
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
<immibis>
oh yeah I think I had a similar thing with iwlwifi once
MiningMarsh has quit [Ping timeout: 255 seconds]
MiningMarsh has joined #osdev
pg12 has quit [Ping timeout: 268 seconds]
node1 has quit [Quit: Client closed]
pg12 has joined #osdev
pg12 has quit [Ping timeout: 268 seconds]
pg12 has joined #osdev
goliath has quit [Quit: SIGSEGV]
m257 has quit [Quit: Client closed]
graphitemaster has joined #osdev
Arthuria has joined #osdev
raphaelsc has joined #osdev
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
exit70 has quit [Ping timeout: 252 seconds]
exit70 has joined #osdev
Arthuria has quit [Ping timeout: 240 seconds]
goliath has joined #osdev
<heat_>
serenityOS is still porting ladybird commits to their in-repo version
<heat_>
apart from that, doesn't seem to have much activity, heh
<nikolar>
well when the project leader pivots to the browser and does most of the work there
<nikolar>
and films that
<nikolar>
and eventually leaves the os side
<zid>
He's filming it? disgusting bastard
<nikolar>
well used to
<mjg>
is it mroe than onyx though
<mjg>
personally i feel bad for the haiku folk
<heat_>
no, less than onyx probably
<heat_>
i didn't look at the individual commits but i seem to have more activity (and my commits are fairly consequent, not random fixes)
<mjg>
well let me rephrase
<mjg>
the serenityos got borderline rugpulled
<mjg>
which is a massive bummer
<heat_>
serenityOS was already barely an OS tbqh
<mjg>
to my understanding they kept hacking away
<heat_>
"web browser guy starts an OS and quickly pivots to a web browser" is hilarious though
<nikolapdp>
indeed
<nikolapdp>
but yeah, a rug pull
<mjg>
i am saying
<nikolapdp>
mjg: what's taht about haiku
<mjg>
you put years of free time into something, probably are part of a community 'n shit
<mjg>
and suddenly bam
<mjg>
so haiku to my understanding had seen even less development than sereinityos
<nikolapdp>
while being (arguably) a more complete system
<mjg>
while i don't care for haiku specifically, they did get the system to a semi-usable state and it appears the system hit a wall
<heat_>
dragonflybsd is worse lol
<heat_>
5 commits in a month
<mjg>
dragonflybsd literally has 1 commit for the last 30 days
<mjg>
and it's a doc change
mbr57 has joined #osdev
<mjg>
in the entire ordeal i think linux is kind of funny
<mjg>
insane patch churn
<nikolapdp>
PATCHEN
<mjg>
and somehow other systems can get majority of the way there with a tiny fraction of that
<heat_>
most patches are niche features or driver changes
<mbr57>
Hello there
<mjg>
heat_: i am ignoring that
<mjg>
not counting some shite arm SoC
<mjg>
the problem with linux is that they commit 1.5 step forward, 1 step sideways and 1 back
<mjg>
all in 1 commit
<mjg>
and hten you have to add several more to patch it up
<mjg>
hence the total patch count
josuedhg has joined #osdev
<heat_>
reading the frontpage of lore.kernel.org/linux-mm: memcg patch, memory-failure niche feature patches, thp contpte patches, bug report, thp swapping optimization (it seems?), data structure work, netfs fix, powerpc hugepages on some random machines out there
<mjg>
yes a lot of it is stuff most people don't care about
<mjg>
i'm ignoring it here
<heat_>
the only consequential to the aveage user (but not really required not noticeable): thp contpte
<heat_>
that's basically why the churn doesn't put linux lightyears away, the churn is unrelated to core functionality or adds random stuff
<mjg>
meanwhile in illumos they squash unrelated commits into one
<nikolapdp>
obviously
<heat_>
like freebsd jails might be great to use and all that jazz, but are they optimized if you have a google server removing and adding 1000s of processes? no
<bslsk05>
lore.kernel.org: [RFC PATCH] vfs: wrap CONFIG_READ_ONLY_THP_FOR_FS-related code with an ifdef - Mateusz Guzik
<mjg>
did you even read the fuckin' commit message
<heat_>
i did
<mjg>
everyone pays for the fence
<heat_>
i'm taking the piss
<mjg>
besides i sent a v2!
<mjg>
OLD NEWS you are pasting here
<mjg>
anyway this fence is some bsd engineering ethos
dgz has quit [Remote host closed the connection]
<heat_>
btw, you might find this funny: linux does not writeback dirty pages in LRU on most commodity filesystems now
<mjg>
?
<mjg>
you gonna have to elaborate
<mjg>
is this as accurate as your previous commentary
<heat_>
they slowly removed the writepage callbacks for ext4, ext2, xfs, btrfs, etc over the last year
<heat_>
which is the thing the page reclamation code uses to writeback, meaning that if it's NULL, it just activates the page and moves on
<mjg>
what's the rationale
<mjg>
presumably there is a replacement
mbr57 has left #osdev [Leaving]
<heat_>
replacement is good old balance_dirty_pages
<heat_>
rationale is that writeback in LRU order is awful
<mjg>
:]
<mjg>
i mean what do they do to land stuff on disk after all
<heat_>
balance_dirty_pages just doesn't let you get ridonculous amounts of memory dirty
<mjg>
look at this wanker, learned about scan resistance and is now acting like he knows everything
<mjg>
caching-related
<heat_>
if you're asking about regular writeback, .writepage is not required, you can just have a .writepages (which is the thing they actually use, and can intelligently write ranges of the file back)
<mjg>
so the funny thing about various heuristics 'n shit is that they like to make things WORSE
<mjg>
makes you wonder how this compares to something "well fuck it" quality a bsd would be doing
<heat_>
i'm not talking about heuristics here
<mjg>
same with caching state tracking algos
<mjg>
like LRU
<mjg>
basically any attempt at making an informed decision what to do likes to be counterproductive
<heat_>
but as you said, "well fuck it" quality somewhat roughly approximates "mega-optimized with insane heuristic and logic"
<mjg>
there was a great paper about ssds
<mjg>
turns out wear leveling algos were DECREASING the fucking lifespan (lol)
<heat_>
let me guess: wear leveling was a problem, software adds wear leveling algos, ssd vendors add algos to smartly avoid wear leveling on dumb software, the two conflict and boom
<mjg>
i don't remember the details
<mjg>
> We argue that wear leveling in SSDs does more harm than good under modern settings where the endurance limit is in the hundreds. To support this claim, we evaluate existing wear leveling techniques and show that they exhibit anomalous behaviors and produce a high write amplification.
<bslsk05>
meyerweb.com: “Considered Harmful” Essays Considered Harmful
housemate has joined #osdev
<heat_>
goto makefile recursion while working on a wear leveling algorithm
<zid>
nikolapdp: Is it hot in balkansland?
vdamewood has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
gog has joined #osdev
<zid>
glug glug, what temp is it in fireiceland?
<gog>
9°
<zid>
cor, scorcher
<gog>
i'm about to go on the ocean too
Vercas3 has quit [Ping timeout: 260 seconds]
<zid>
omg gog is jesus
<gog>
ye
<zid>
It's.. 25.3C here
<vdamewood>
If I give gog a fish, can she make it into enough to feed a whole crowd?
* vdamewood
gives gog a fishy
<gog>
yes
* gog
eatss for a day
<gog>
jk
<zid>
Teach a gog to strike a match, she'll be warm for a day
<zid>
Set a gog on fire, she'll be warm for the rest of her life
<gog>
wisdom
dalme has joined #osdev
<vin>
I am wondering why my mremap is failing here? https://godbolt.org/z/Txxq9vs4o I suspect I am using the flags incorrectly? I am trying to resize the file after mmap and keep the page table entries as is for already mapped pages and update the map size for future use
<bslsk05>
godbolt.org: Compiler Explorer
<vin>
ah nvm!
<heat_>
MREMAP_DONTUNMAP (since Linux 5.7)
<heat_>
This flag, which must be used in conjunction with MREMAP_MAYMOVE, remaps a mapping to a new address but does not unmap the mapping at old_address.
housemate has quit [Read error: Connection reset by peer]
Vercas3 has joined #osdev
<immibis>
TIL! I was looking for something like that recently.
cow321 has joined #osdev
netbsduser has joined #osdev
<heat_>
oh this is so weird
<heat_>
The MREMAP_DONTUNMAP flag can be used only with private anonymous mappings (see the description of MAP_PRIVATE and MAP_ANONYMOUS in mmap(2)).
<heat_>
After completion, any access to the range specified by old_address and old_size will result in a page fault. The page fault will be handled by a userfaultfd(2)
<heat_>
handler if the address is in a range previously registered with userfaultfd(2). Otherwise, the kernel allocates a zero-filled page to handle the fault.
<heat_>
looks handtailored for some weird usecase
<heat_>
yeah looks hand-tailored for GC (+ userfaultfd)
xenos1984 has quit [Read error: Connection reset by peer]
<nikolar>
how so for gc
<heat_>
there's a NOTES in the manpage with a rough mention, but i'm not familiar with GC algorithms anyhow
<heat_>
i'm sure they're loving it in the JVM and V8 and ART and all that
<zid>
can't be a live address if it faults!
<nikolar>
yeah i don't get how that helps though
<nikolar>
exactly zid
<zid>
I think that's literally the plan
spare has joined #osdev
<nikolapdp>
what
<zid>
intentionally faulting on delete
<zid>
after it has been deleted*
<nikolapdp>
so to catch use after free or something?
<bslsk05>
lore.kernel.org: [PATCH v5 1/3] mm: Extend MREMAP_DONTUNMAP to non-anonymous mappings - Brian Geffon
<zid>
then you post a message to the other guy to say ERESOURCE
<zid>
objc or whatever the fuck idk
<nikolapdp>
yeah odd
<vin>
You mean fault on any live address accessed to this mmaped region and the userfaultfd can then take some action on it (like delete)?
<zid>
I bet I can use that shit for like, memcached
<immibis>
or not, since it sdoesn't actually allow sharing
<immibis>
why would you want that
<immibis>
i thought it would double-map the same page
<heat_>
it's for a convoluted userfaultfd scheme that google added for android
<heat_>
for GC
<heat_>
i didn't really get how it worked but i assume it's super optimal and great
<zid>
nikolapdp: vulkan is rad, it has a define that's a void * on 64bit, but a uintptr64_t on 32bit
<nikolapdp>
lol wat
<nikolapdp>
why
<zid>
so it always warns unless you ifdef around it, depending on which arch is your premier arch!
chiselfuse has quit [Remote host closed the connection]
foudfou has quit [Remote host closed the connection]
<nikolapdp>
warns what though
foudfou has joined #osdev
<zid>
integer and pointer conversions
<zid>
on 64bit it's a pointer, on 32bit it's a long long unsigned int
chiselfuse has joined #osdev
<zid>
VKHANDLE h = CreateBoobs();
<nikolapdp>
wait, a handle is a pointer or uintptr64_t
<zid>
yes
<nikolapdp>
why can't it just be a ptr
<zid>
because a ptr is 32bit on 32bit
<nikolapdp>
so
<zid>
they clearly do silly things internally with the pointer bits, or maybe vulkan only works on 64bit kernels? idk
<nikolapdp>
yeah exactly
<nikolapdp>
self inflicted
<zid>
yes I was laughing at vulkan
<zid>
it's fine if you do VKHANDLE h = CreateBoob();s or whatever because the typedef matches on both sides
<nikolapdp>
deservedly so
<nikolapdp>
but NULL doesn't work then
<zid>
but all the struct blah { VKHANDLE h; } stuff can't be initialized properly
<zid>
because NULL doesn't work on it
<nikolapdp>
heh yeah just said that
<zid>
VK_NULL_HANDLE >_<
chiselfuse has quit [Remote host closed the connection]
<nikolapdp>
yuck
<nikolapdp>
why are they being weird
SGautam has joined #osdev
xenos1984 has joined #osdev
<heat_>
why do you care what type the handle is?
chiselfuse has joined #osdev
<nikolapdp>
i care that it differs between 64 and 32bit systems
<heat_>
implementation detail
<nikolapdp>
sure
<zid>
Just more stupid shit to have to remember, same as not being able to pass NULL to varargs
<zid>
for the exact same reason, too
<zid>
we learned this lesson 35 years ago
<nikolapdp>
and that's why we have nullptr_t
<zid>
die
<heat_>
goated nullptr_t
<nikolapdp>
are we going to get a vkhndl_t in the standard
<nikolapdp>
shut up heat
<nikolapdp>
you c++ shil
<heat_>
i wish i was getting paid
<SGautam>
im paid for shilling C++
<heat_>
sgautam what's your favourite programming paradigm
<GeDaMo>
Why not just wish to be very rich? :P
<nikolapdp>
yeah just wish to be rich without promoting a crap language
<SGautam>
OOP
<heat_>
wrong
<nikolapdp>
the correct answer is all of them
<heat_>
you're getting paid by the C people aren't you?
<heat_>
absolutely
<heat_>
found the C++ shill
<nikolapdp>
i am not a shill, i am just talking too much with you
<nikolapdp>
it's rubbing off
<heat_>
good
<heat_>
you'll be writing your very own picky variant of C++ in no time
<nikolapdp>
trust me, i won't
<heat_>
anyway, file descriptors should've had their own opaque type
<nikolapdp>
why do you care what type they are
<nikolapdp>
implementation detail
<heat_>
it's not
<nikolapdp>
sure
<heat_>
int open(const char *filename, int flags) dumbass
<heat_>
that's my point
<SGautam>
heat_, last company I worked at I shilled C++ to shift a huge part of the "low latency" algorithm-based backend to C++
<SGautam>
from Java
<SGautam>
for some reason corpos love java
<heat_>
we're all stuck with int, and int has been kind of big for a file descriptor for like... 40 years or so
<zid>
I don't mind opaque handles being int as long as people realize that you're limited to 64k on shit systems, and 4 billion on regular ones, and don't do dumb shit
<zid>
opengl also does it, it works fine, it just indexes the handle into an array to get the pointer back
<nikolapdp>
yeah i don't mind fds being 4bytes
<nikolapdp>
who cares
<SGautam>
it's honestly the ugliest language i've worked it imo. its even uglier than rust
<nikolapdp>
and you know you literally never need to worry about overflow
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<zid>
imagine if the api was FILEDES open(...); and filedes was void * on 32bit, long on 64bit :D
<SGautam>
but then there's a lot of support, and its got a huge legacy
gog has quit [Ping timeout: 252 seconds]
<zid>
<
<nikolapdp>
also you can set the file limit to more than 65536
<zid>
3
<heat_>
they could've been u16 for *ages* (as they were in early UNIX, int was 16-bit)
<zid>
nikolapdp we should make this the API on our future OS project
<nikolapdp>
oh yeah definitely
<nikolapdp>
all good ideas
<heat_>
and now if we get some dumbass really large system, we're screwed as we can't get more than 2^31 fds
<SGautam>
a pointer as a file descriptor sounds nasty
<zid>
#ifdef 64BIT int read(int fd, ...); #else int read(void *fd, ...); #endif
<heat_>
unless we *change int*
<zid>
glorious
<nikolapdp>
zid indeed
<nikolapdp>
glorious
<immibis>
sgautam: windows does it
<heat_>
files are glorified handles
<SGautam>
ya
<SGautam>
HANDLE is a void*
<nikolapdp>
heat_ thought that ints are too big for the fds
<SGautam>
but still
<immibis>
windows handles are officially opaque pointers
<immibis>
they don't actually point to anything - they're just pointer-sized
<SGautam>
Win32 API is really difficult to work with
<immibis>
if you think win32 is bad, where is linux IOCP?
<zid>
hmm?
<zid>
I always found winapi exceptionally easy
<zid>
other than the fact they typedef pointers
foudfou has quit [Remote host closed the connection]
<nikolapdp>
also who's replying to who
<zid>
that can die in a fire
<immibis>
and how do i creat ea window in wayland?
<zid>
no idea
<SGautam>
immibis, why not use GTK instead?
<heat_>
PVOID
<immibis>
sgautam: eww, gnome
<SGautam>
or Qt
<immibis>
eww, c++ meta-compiler
<SGautam>
lmoa
<nikolapdp>
eww, c++
<immibis>
java was popular because it Just Worked
zxrom has joined #osdev
<immibis>
no bullshit. you want a socket server? new ServerSocket. you want a window? new JFrame.
<heat_>
java windows look fugly
<nikolapdp>
also it was release at the height of oop hype
<SGautam>
biggest issue with Java imo is lack of operator overloading
<heat_>
every time someone desires operator overloading i die
<nikolapdp>
get help then
<nikolapdp>
:P
<immibis>
heat_: go write some 3d graphics code
<nikolapdp>
pp operator
<immibis>
then tell us your opinion
<nikolapdp>
immibis, easy v2_add(v1, v2)
<nikolapdp>
or whatever
<zid>
operator overloading is heavily abused and misused and makes debugging hard, but it isn't like.. fundamentally bad?
<zid>
idk what to do about it
<nikolapdp>
just don't
<zid>
you told heat you liked it
<SGautam>
operator overloading is great for ml
<immibis>
nikolapdp: it's like writing assembly instead of C
<zid>
he should seek help for not liking it
<SGautam>
and math heavy tasks
<nikolapdp>
no, i told him to get help for not being ok
<SGautam>
your code just looks right
<heat_>
immibis, tell me what [] does on std::vector
<zid>
Only time I've seen operator overloading work okay is on math code yea
<nikolapdp>
immibis, no?
<zid>
and that was merely 'okay'
<zid>
it had obvious issues still
<immibis>
writing v2_add(v1, v2); instead of v1+=v2 is literally like writing 'add r1, r2` instead of i1+=i2;
<SGautam>
zid, ML, Simulations, Game Engines, lots of usecases still
<nikolapdp>
what's your point
<immibis>
if the expression is heavily nested, it's exponentially worse
<nikolapdp>
call f1 is literaelly the same as f1()
<zid>
like needing to allocate temporaries inside anonymous bits of code 14 files away because a '+' appeared
<nikolapdp>
yeah, spooky action at a distance
<immibis>
nikolapdp: yup now what is literally the same as f1(1, 2, vector1.cross_product(vector2), 5.0f);
<zid>
good luck with the stack trace from that in a compiled version
<nikolapdp>
kek
<nikolapdp>
but again, i don't see your point
<immibis>
hint: it's not push 1, push 2, push vector1, push vector2, call cross_product, push 5.0f, call f1
<nikolapdp>
sure
<immibis>
and even if it was that, like I said, it's like writing assembly instead of C
<SGautam>
allowing Discord to prosper while having IRC was a massive L for the open source community, IRC had a headstart of like 30y or so. Someone could've worked to make it more accessible.
<nikolapdp>
so calling functions for things is like writing assembly, cool
<heat_>
discord prospered because IRC sucks
<SGautam>
exactly
<zid>
inline images too useful
<mjg>
irc was a product of its time
<mjg>
and hsould have been retired
<zid>
but irc too open access to allow that, every channel would be full of goatse
<mjg>
we are all boomers for even using it
<heat_>
yes
<nikolapdp>
i guess i should have a read operator too
<nikolapdp>
oh wait, c++ already does that and it sucks
<zid>
nikolapdp: I recommend <<
<zid>
it should be unable to signal errors, also
<zid>
and require exceptions
<nikolapdp>
mjg: speak for yourself
<nikolapdp>
i am no boomer
<heat_>
haha
<zid>
that'd be perfect
<SGautam>
Discord sucks because there
<SGautam>
's way too many channels within a server
<heat_>
discord is totally fine
<nikolapdp>
i know right, zid
<nikolapdp>
it's great
<immibis>
nikolapdp: v2-2*dot(v1,v2) <- write it your way for me
<zid>
discord sucks because it's ran by an awful webdev company
<zid>
not because the idea sucks
<immibis>
nikolapdp: sorry, v2-2*dot(v1,v2)*v2
<SGautam>
IRCCloud could've been a competitor to discord ig
<zid>
it's a horrendous walled garden that has slowly been evaporating information from the web
<SGautam>
It has inline images and a few fancy features
<mjg>
neoboomer
<zid>
(anti logging TOS)
<immibis>
it could not. the users demand emojis.
<zid>
and had horrible semantics for pings and notifications and stuff
<immibis>
discord could be worse than IRC in every way except for not needing a server address, and it would win
<immibis>
nikolapdp: you appear to be returning structs
<zid>
If discord goes offline, or if they ever decide to shut up shop, half of the knowledgebase of every fan org on the planet is going to disappear lol
<zid>
because it's all in discord pins now
<zid>
not gamefaqs or a forum
<nikolapdp>
what do you mean immibis
<heat_>
you're all acting like IRC was ever a competitor to discord lol
<SGautam>
back when Discord didn't release yes
<heat_>
IRC has been bleeding users for 20 years
<immibis>
nikolapdp: shouldn't you avoid returning structs from functions for reasons similar to why you avoid operator overloading?
<heat_>
it was dead when discord popped up
<nikolapdp>
no?
<nikolapdp>
but you could easily avoid that too
<immibis>
nikolapdp: every one of those returns calls a copy constructor just like operator overloads call operators
<nikolapdp>
c doesn't have a copy constructor
<SGautam>
heat_, where would you go prior to 2015 for live chat with members belonging to a community of interest?
<immibis>
or, well, it *could* call a copy constructor
<nikolapdp>
it literally just vgives you a struct
<nikolapdp>
also that sounds like a c++ problem because it's a shit badly designed language
<immibis>
nikolapdp: if C, this is a weird area of C compilers that can't be assumed to be efficient, so you should probably avoid it
<nikolapdp>
which area
<heat_>
sgautam, teamspeek, mumble
<zzo38>
Additionally to being lost than Discord being lost, it is also difficult to access if you do not have or want to use Discord
<heat_>
teamspeak
<immibis>
returning and passing structs
<immibis>
everyone uses pointers
<nikolapdp>
sure, you're doing that regardless
<nikolapdp>
wether you overlaod or don't
<SGautam>
First time I'm hearing lol
<Ermine>
> teamspeak --- is it a thing in 2024?
<heat_>
GOOGLE PLUS
<SGautam>
im pretty sure there userbase is smaller than IRC
<SGautam>
Google+ died
<SGautam>
see thats my point
<SGautam>
IRC sort of had its niche
<heat_>
google+ wasn't live chat
<immibis>
google plus was neve ralive
<SGautam>
and Discord capitalized it
<SGautam>
heat_, I was on G+ posting programming memes in 2012, it was fun
<zzo38>
IRC is much better than Discord in my opinion, and I use IRC
<SGautam>
while it lasted
<heat_>
IRC did not have its niche and usage numbers show it
<heat_>
it was already dead 10 years ago
<Ermine>
i posted some cringe in g+
<immibis>
openness is the only way that IRC is better than discord, and generally, the only way that open platforms are better than walled gardens
<immibis>
unless you also value minimalism, which can also be one
<nikolapdp>
well it does have its niche since we're all here
<immibis>
there are no meme spam channels on IRC because you can't post memes because you can't post images
<SGautam>
to not sound pretentious but
<nikolapdp>
sounds like a featuer to me
<nikolapdp>
feature
Arthuria has joined #osdev
<SGautam>
like the crowd on Discord way less filtered than on irc
<Ermine>
I think the lack of voice messages is a perk of irc these times
<SGautam>
the IRC math channel has been far more helpful tbh
<zzo38>
There is also the protocol; I think that the protocol is working better because IRC is the command has a reasonable simple format and you can use it without any special software (although having specialized IRC software still is better, it is not mandatory)
<SGautam>
the Discord math channels are made of high schoolers
<zid>
discord is a much much younger crowd, on average
<Ermine>
and no need to bind a phone number
<heat_>
i'm here to speak with the oldies
<zid>
irc is for old people to whine about the kiddos
<zid>
discord is for making your HOT NEW APP
<heat_>
also if i wasn't online i would lose a lot of logs
<Ermine>
am i an oldie to you?
<nikolapdp>
heat and i a re kidos though
<heat_>
which is a feature
<heat_>
i guess
<heat_>
Ermine, super
<zid>
nikolapdp: you have an older soul at least, you're not a total zoomer
<Ermine>
lack of logging is a drawback, that's for sure
<Ermine>
OH
<zid>
if you were, you'd do all your coding in roblox
<heat_>
mon
<mjg>
mon?
<mjg>
dafaq does that evn mean dawg
<Ermine>
no wonder why my spine hurts these days
<immibis>
IRC has an killer feature (as in one which kills it) which is needing a TCP connection all the time, which is incompatible with phones, which are more popular than PCs.
<heat_>
mon
<zzo38>
Logging can be made on IRC, usually client-side although server-side logging is also possible
gorgonical has quit [Ping timeout: 252 seconds]
<Ermine>
obviously
<heat_>
immibis, it's also incompatible with going outside, turning off your PC, suspending your PC, bad internet, power losses, etc
<Ermine>
but network does server side logging for some reason
<zid>
nikolapdp: Are you a computer wizard?
<nikolapdp>
define computer wizard
<heat_>
unless you opt into one of those awful workarounds for the awful IRC protocol
<heat_>
you need to spend a significant amount of time compensating for IRC being so shit
<Ermine>
So, anyway, three things to discuss in #osdev: messaging systems, text editors and languages
<zzo38>
I think that IRC is not so bad though
<heat_>
i discussed osdev today
<nikolar>
(both programming and actual languages)
<Ermine>
cool
<Ermine>
Otoh no logs = nothing to show in the court
<zid>
There are logs, it's just discord has them not you
<zid>
so it can only be used by corps to sue you for dmca shit :P
<nikolapdp>
and you are not allowed to collect your own logs
<zid>
defending yourself in court gets you banned from discord
<zid>
true fact
<nikolapdp>
ohw so
<zid>
what's an ohw
<nikolapdp>
s/ohw/how
<zid>
logging discord violates tos
<Ermine>
TIL abstract unix sockets exist
<zid>
violating tos = ban
<nikolapdp>
so you can't scroll up and take a screenshot or somthing
<zid>
correct
<nikolapdp>
wtf
<clever>
zid: what about all of those irc/discord/matrix bridge bots?
<clever>
those let things like irc log things
<zid>
skirting, technically violating tos but they'd annoy people
<heat_>
Ermine, just on linux (and onyx)
<zid>
it's bizzare that it's even part of the tos tbh
<zid>
It doesn't seem like they actively enforce it very hard
<zzo38>
One of the bridges that I had used no longer seems to work though
<nikolapdp>
zid it really is
<Ermine>
heat_: when did that thing appear in linux?
<nikolapdp>
i can't think of a good reason to have it in the tos
<heat_>
Ermine, idk, it's an old feature i think
<zid>
I guess they just don't want 'private' discord discussions coming up on google
<clever>
zid: somebody i talk to often has a non-standard discord client, which he mainly uses to get audio capture when screen sharing on linux
<heat_>
SCM_CREDENTIALS and the abstract namespace were introduced with
<heat_>
Linux 2.2
<nikolapdp>
weird
<clever>
zid: but ive also noticed, it shows edit history, and doesnt delete deleted messages
gbowne1 has joined #osdev
<nikolapdp>
i am sure there are othre ways to achieve that
<clever>
all things id want to have, but i dont want to risk my acct :P
<zid>
You'd n eed to be online to have seen the edits
<clever>
yeah
<zid>
but you could do it on the base client easily
<Ermine>
Oh, it's very old
<zid>
there's a modding tool for the base client
<clever>
its just not deleting the old info, when an edit comes in
<heat_>
Ermine, there's also socketpair which is standard and can create two unnamed, connected UNIX sockets
<nikolapdp>
zid: the modding tool is also against the tos though, isn't it
<zid>
yep
<nikolapdp>
nice
<heat_>
Ermine, OH if you want a fun bigger project for onyx, you could implement SCM_RIGHTS
<Ermine>
I'm just investigating powerdevil complaining about dbus session bus not existing, though it does exist
<heat_>
and the horrible garbage collector
<Ermine>
so, dbus made an abstract socket
<nikolapdp>
heat_ what's the gc for
<heat_>
you can legally pass a unix socket in a unix socket
<nikolapdp>
it is just an fd, no?
<heat_>
yes
<clever>
heat_: i first encountered that with the hamachi vpn, it uses a tiny open source root daemon, to pass a /dev/tun fd over to the closed-source non-root vpn daemon
<nikolapdp>
so completely expected the
<nikolapdp>
then
<clever>
it was their solution to the paranoid users who didnt want to run closed-source as root
<vin>
would passing 0 as mremap flag mean the address of the map should remain unchanged and simply extend the map? I couldn't find the documentation of this
<heat_>
the problem is that you can have a unix socket A that passes a unix socket B, then pass unix socket A into unix socket B
<heat_>
you have a loop!
<clever>
but just recently (a few weeks ago), i discovered you dont even need that anymore, tun/tap has its own solution to that problem
<clever>
heat_: oh no!, and now if you close a/b, what happens?
<bslsk05>
'Fire rips through battery recycling plant' - 'A major fire has broken out at a battery recycling plant in North Ayrshire.'
<zid>
Local depression rates crashing
<nikolapdp>
lol
<heat_>
clever, leak unless you have the unix socket GC
<nikolapdp>
oh
<heat_>
which is the traditional solution AFAIK
<clever>
heat_: i would have assumed, that is only a weak reference, and doesnt prevent closing the socket
foudfou has quit [Remote host closed the connection]
<clever>
heat_: the sender shouldnt close until after it has sent the thing, and the receiver should receive it, oh, but there is a tiny window in between those 2....
<heat_>
nope, it's a strong reference
foudfou has joined #osdev
<nikolapdp>
clever can't the socket take over ownership until it's passed to the receiver
<clever>
nikolapdp: and what if you create a cycle, where a owns b, and b owns a?
<clever>
then you close both
<heat_>
the socket does take over ownership
<heat_>
"Semantically, this operation is equivalent to duplicating (dup(2)) a file descriptor into the file descriptor table of another process"
<nikolapdp>
but you need a gc, don't ou
<nikolapdp>
oyu
<nikolapdp>
you
<heat_>
well yes cuz you can easily create weird loops
<clever>
there was a JS framework i used a decade ago, which was designed arround the assumption that the browser cant detect cycles when doing GC
<clever>
so they put every single object into a global array
<zid>
nikolapdp: how hot is it in balkandlandlands?
<clever>
and at page unload, it walks the array, and shreds all inter-object references (it had implemented destructors in js)
<heat_>
a owns b, b owns a, you close a, you close b, a refs = 1, b refs = 1, a and b are unreachable
<clever>
the problem, is that the game using this framework had a leak, and this resulted in 5 minutes of shreding references
<nikolapdp>
zid: it's 26C here at the moment
<clever>
and at the time, firefox was single threaded
<clever>
so the entire browser would hang
<nikolapdp>
lel
<nikolapdp>
why would you want to do that manually though
<clever>
firefox was nice enough to ask you, do you want to terminate it?
<zid>
oh same
<zid>
but it's later where you are
SGautam has quit [Ping timeout: 268 seconds]
<zid>
so hotter technically I guess
<clever>
but the "dont ask again" option, just stopped the prompt, causing it to remain hung for the full 5mins
<clever>
nikolapdp: because the framework assumed the browser GC cant detect cycles
<nikolapdp>
ah it assumed, ok
<clever>
nikolapdp: so it shreds all inter-object references, so when the page unloads, it hits a refcnt of 0 and free's
<clever>
it was designed for an older era, when that assumption was true
<nikolapdp>
zid: yeah zid, though it's breezy so not that bad
<heat_>
a GC that can't detect cycles sounds like hell
<nikolapdp>
indeed
<nikolapdp>
that's just refcount
<clever>
heat_: i think it was only a refcnt based gc, yeah
<clever>
far simpler to implement, and easy to leak
<nikolapdp>
i am surprised it's not an internal only write-up or osmething
<Ermine>
SCM_RIGHTS sounds complex
<heat_>
companies doing technical blogs for good will is in vogue
<heat_>
Ermine, i mean, it's not that hard, the GC is the trickier bit IMO
<nikolapdp>
heat_ yeah but it's oracle we're talking about
<heat_>
sortie just banned passing some types of fds (unix sockets) for sortix which is technically ok i guess
<nikolapdp>
heh nice
<heat_>
i don't like it because i'm a technical purist and I'LL HAVE MY OWN GARBAGE COLLECTOR DAMN YOU
<nikolapdp>
garbage collector?
<nikolapdp>
in my kernel??
<nikolapdp>
never
<heat_>
net/unix/gc.c
<heat_>
dang, garbage.c, i was close
Vercas3 has quit [Ping timeout: 260 seconds]
<nikolapdp>
heh i was just checking that
Vercas3 has joined #osdev
foudfou has quit [Remote host closed the connection]
SGautam has quit [Ping timeout: 260 seconds]
foudfou has joined #osdev
<vin>
why is the kernel not able to allocate memory here? https://godbolt.org/z/9d7c698d9 I reserve a large virtual address beforehand and then mmap a file, grow it, and the call mremap on it.
<bslsk05>
godbolt.org: Compiler Explorer
Vercas3 has quit [Quit: Ping timeout (120 seconds)]
Vercas3 has joined #osdev
Vercas3 has quit [Quit: Ping timeout (120 seconds)]
<immibis>
zzo38: irc works ok, but it's an impedance mismatch with the way that people actually chat (or do anything!), which is on their phones
<heat_>
vin, i'll guess it can't expand without moving
<heat_>
MREMAP_MAYMOVE works. as for the why, who knows. it could've picked a random hole in your mmap that fits the first allocation but not the second, you may have memory allocation in between the mmap and the mremap that's stopping the in-site growth, etc
<heat_>
if you see the /proc/self/maps on failure you'll be able to see it doesn't have space
foudfou has quit [Remote host closed the connection]
Vercas3 has joined #osdev
foudfou has joined #osdev
<heat_>
oh x86 mmap allocation grows down
<heat_>
i forgot that. yeah that sounds like a good reason why it's not working
<vin>
heat_: I furhter simplified the code https://godbolt.org/z/qoKvzf6GG I assumed if I reserve a contigous block of memory (much larger than I want 32 MB) and then create a mmap of 1 MB at fixed address (offset 0 of reserved) that maps a file of 1 MB. The file later grows to 2 MB then since the next 31 MB of the virtual address space is reserved by me, doing a remap on my 1MB map to become 2MB should
<bslsk05>
godbolt.org: Compiler Explorer
<vin>
work.
<vin>
It's wierd such a simple thing is not working
<dostoyevsky2>
vin: if programs were to remap mmap'ed memory regularly, that could easily thrash the kernel
<heat_>
what
<vin>
Understandable. I just want to remap a single map which maps a file that can grow. To shrink the file I just fallocate and punch holes dostoyevsky2
<heat_>
i just told you why. mmap allocating growing down
<heat_>
say mmap A returns 0x2000. mmap B returns 0x1000. you cant grow B.
<heat_>
this is how mmap works for most relevant linux architectures
<vin>
heat_: yes I understand that. If mmap A of size 1000 returns 0x2000 and mmap B of size 10 returns 0x2000 (MAP_FIXED) then I can call mremap B to size 20 and return 0x2000 (MAP_FIXED)
<vin>
is what I expected ^
<heat_>
mremap doesn't overrun other segments
<heat_>
if a mapping stops it from growing, it fails with -ENOMEM
<heat_>
which is what you're seeing
<heat_>
the kernel doesn't know what "reserving a contiguous block of memory" is, it knows there's a huge segment stopping it from mremapping the 1MB segment to 32M
<heat_>
oh btw new_address can't overlap
<heat_>
when MREMAP_FIXED. you seriously need to start reading the man page
<vin>
Ah I missed this part "Any previous mapping at the address range specified by new_address and new_size is unmapped." I was fooled by the: mremap() *expands* (or shrinks) an existing memory mapping.
<vin>
How do people deal with this? When a file size changes (grows/shrinks) they unmap and map the file again? This will not only require msync but also will lose all the old virtual addresses that were pointing to parts of the file
<heat_>
>msync
<heat_>
msync is practically a noop
<heat_>
mapping, growing a file and remapping (without being able to re-assign pointers!) is such a weird edge case
<dostoyevsky2>
vin: you can set the mmap size arbitrarily high, and if you never access that memory, then it doesn't incur any overhead... also file on disk is just virtual if your filesystem supports sparse files
<heat_>
also that, mmap size can be arbitrarily large, you'll just SIGBUS if you reference anything larger than file size
<vin>
Makes sense, I guess I will just mmap something super large and don't bother calling mremap. Later call madvise MADV_DONTNEED on parts I wrote to in the map. I moving things I don't want out of memory
<dostoyevsky2>
vin: My problem with mmap'ed data structures was always when I would run out of physical memory, then addresses couldn't be mapped anymore, and then the error message is just SIGBUS/SIGSEGV ... so then I had to guess how much memory was left... to be able to provide a better error message
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<vin>
swap + rss could help there? dostoyevsky2
jistr has joined #osdev
<zid>
nikolapdp: 10PM IS HERE
spare has quit [Remote host closed the connection]
<zid>
*madly refreshes nyaa for 5 mins*
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 268 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
vinleod has quit [Ping timeout: 255 seconds]
vdamewood has joined #osdev
vdamewood has quit [Ping timeout: 268 seconds]
netbsduser has quit [Ping timeout: 268 seconds]
vdamewood has joined #osdev
MiningMarsh has quit [Ping timeout: 268 seconds]
MiningMarsh has joined #osdev
vdamewood has quit [Ping timeout: 268 seconds]
<zzo38>
About returning structures from functions, this is sometimes useful for small structures. In Free Hero Mesh, many functions use the Value structure for arguments and return values without using a pointer to the structure, since it is useful to pass values in the Free Hero Mesh programming language with C functions. (The structure consists of two 32-bit members, and on some computers is passed as though it was a 64-bit integer)
goliath has quit [Quit: SIGSEGV]
<zzo38>
I had also found it useful in another case, which is an implementation of an immediate mode TUI with C macros, although this is really a hack, and in other programming languages it would be done differently. #define win_form(xxx) for(win_memo win_mem=win_begin_();;win_step_(&win_mem,xxx))
<Ermine>
> returning structures
<Ermine>
don't
<nikolar>
KERNAL
<mjg>
fuck this i'm learning LISP
<mjg>
(+ 2 2)
<nikolar>
4
<Ermine>
5
<mjg>
LISP has fearless advocacy
<mjg>
that's about it tho
<zzo38>
I had also read about handling error conditions in Lisp, I think it is reasonable. Also, Lisp has a different type for file names, which I also think is reasonable.
<zid>
return (struct r){1, 4};
<zid>
fight me
* nikolar
kicks zid
Starfoxxes has joined #osdev
<zid>
I'd return all sorts of tuples if it was slightly smoother to do in C, ngl
<nikolar>
heh
<nikolar>
they get passed through register if it's only two values anyway
<zid>
yea eax:edx is the return reg in x86 conventions anyway
<nikolar>
yea
<zid>
so you can do tuple returns of like value + error, and it just compiles to call f; test edx, edx; jz err; /* Do thing with eax */
<zid>
don't even need fancy sysv struct packing for it
<nikolar>
yeah basically
bauen1_ has joined #osdev
vdamewood has joined #osdev
<zzo38>
I usually only use passing/returning structures for small structures anyways (often only two values), which is usually when it is most useful anyways. It isn't such bad to do in C.
<zzo38>
However, passing a structure might also be usable if you want to implment named arguments (possibly with default values which are specified by a macro)
bauen1 has quit [Ping timeout: 240 seconds]
<Ermine>
passing/returning structures is PESSIMAL
<zid>
Except when optimal as above
<zid>
do you want me to *out you
<zid>
DO YOU?
vdamewood has quit [Ping timeout: 268 seconds]
<zzo38>
A compiler might also be able to optimize it out if using inline functions, although it might be able to work with "static register" also (although I think a function cannot be declared as register, although it would make sense to indicate that you cannot take the address of the function, which is what the "register" command means for variables in C)
<azonenberg>
So my flash fuzzing adventures have led me down an even deeper rabbit hole of analog edge case behavior in flash bit cells
<zid>
There was a classic story on the internet about that
<zid>
It was an early genetic algorithmn thing, they were trying to get an fpga to act as a signal processor by training it against the signal
<azonenberg>
That's not flash and that was exploiting analog effects of coupling within the FPGA
<zid>
it ended up using half of the unprogrammed bits as a big capacitor or something weird, said the writup
<zid>
god that thing must be like, 25+ years old now?
<azonenberg>
What i'm hitting now is flash bits that read back correctly initially and then give erroneous data later on
<zid>
DEGRADATION :(
<azonenberg>
(but then when i power cycle the board again are fine)
<azonenberg>
This is a metastability issue of sorts
<zid>
That's your new mortal kombat finisher
<Ermine>
> register
<azonenberg>
in that i have flash bits that are partly programmed (this only happens when i'm constantly power cycling the board)
<azonenberg>
basically simulating the case of somebody pulling the plug on the thing at the exact worse moment
<azonenberg>
My test case power cycles or resets the DUT every 750 +/- 250ms while in a tight loop reading and writing flash
<azonenberg>
about once a day i hit this failure condition
<Ermine>
the only codebase in which I saw that keyword is an educational text editor which was used on my faculty in fucking 1980s
<Ermine>
and which has some VMS bits
<azonenberg>
I've fixed a lot of legitimate bugs in my code, which handled things like "first 16 bytes of a 32-byte object key were written then pwoer was lost, leading to an object whose filename is {"A", 15x 0x00, 16x0xFF} instead of the intended {"A", 31x 0x00}
<nikolar>
was that your post
<azonenberg>
or corrupted flash ECC bits triggering NMIs which had to be gracefully handled to resume execution
<azonenberg>
the /r/embedded post? yes
<azonenberg>
Basically i'm trying to get some feedback on whether i've done enough to mitigate data corruption on power loss or if there's any other things i can do to improve reliability
<azonenberg>
(I already have supervisors in my more complex boards that can detect power outages before Vdd gets critical and trigger a clean shutdown, this feature isn't fully implemented yet but ideally this would prevent power from being lost midway through a flash write at all)
<azonenberg>
i.e. as the 48V power starts dipping, trigger a panic shutdown using the energy stored in all your filter capacitors and be in a quiescent state by the time the final voltage regulators start having output droop because the input voltage is too low
<azonenberg>
ideally it would anticipate the failure, send a "panic shutdown" signal to every chip in the system, flush any pending storage writes, then enter a suspend state and wait for power to be completely lost
<azonenberg>
(but at the same time I also want the actual flash data structure and write code to be as resilient as possible)
<heat_>
mjg, consider haskell mon
<heat_>
lisp for the 21st century
<nikolar>
does haskell have macros
<heat_>
no
<heat_>
no decent language has macros
<nikolar>
rust has macros
<heat_>
you heard me
<nikolar>
rust isn't a decent langauge
<nikolar>
qed
<nikolar>
the rust discussion is settled
<heat_>
though aren't rust macros like completely insane too
<heat_>
not even cpp-level shit, rather much worse
<nikolar>
no, they are lisp level macros
<nikolar>
completely arbitrary ast rewrites are allowed
<heat_>
exactly, completely insane, thanks
<nikolar>
i think their inline asm is a macro
<zzo38>
Haskell does have macros, although they work differently than C macros; rather it is Haskell code that can access the AST and create it, and you must indicate explicitly in your program that you can to use it in this way
<zzo38>
Lisp macros are probably better though in some ways
<zzo38>
Also, I think that macros are not a bad idea. Macros and GOTO are both good ideas. Unicode string types are a bad idea. The syntax for octal numbers in C is a bad idea, although having octal numbers is a good idea (you could have "0o" instead of just "0", or do like PostScript you can write "8#" for octal and "16#" for hexadecimal)
<heat_>
ok haskell sucks then
<mjg>
c'mon lisp
<mjg>
is what i'm doing
<mjg>
fuck you
<heat_>
fuck you
<mjg>
(iswanker? 'heat)
<heat_>
im writing a kernel in fortran 77
<mjg>
ok
<mjg>
see, i don't shit on your projects
<heat_>
it'll scale so hard you'll lose your job
<mjg>
i'm wriring a kernel in COBOL
<heat_>
based
<mjg>
IDENTIFICATION DIVISION
<mjg>
did you know mofers did not even have func arguments
<mjg>
utterly fucking bizzare
<mjg>
fucking DOS of programming languages
<heat_>
business language for the real world, real business
vdamewood has joined #osdev
<heat_>
not C, crap language full of technicalities the neckbeards can discuss forever
<heat_>
they want to convince us "dereferencing a null pointer is undefined behavior" is a coherent sentence
<nortti>
COBOL didn't even have functions, really. it's too imperative for anything other than subroutines
<nortti>
(probably different nowadays – I only know up to like COBOL 74)
<mjg>
> Enterprise COBOL for z/OS
<mjg>
fuck this
<Ermine>
better invert a matrix in fortran
<nikolar>
mjg: there's java for z/OS if you prefer that
Turn_Left has quit [Read error: Connection reset by peer]
Matt|home has quit [Quit: Leaving]
<Ermine>
I really consider giving fortran a try
<Ermine>
... one day
<heat_>
inverting a matrix is also utter nonsense that doesn't provide value to the shareholders
<heat_>
unlike COBOL which is shareholder-value-optimized
<dostoyevsky2>
Ermine: It's good for numerics, e.g. you can write handling code for when numbers under/overflow directly in the language
<mjg>
fbsd bootloader used to have a fortran interpreter
<mjg>
now it's lua
<nortti>
do you mean forth?
<mjg>
erm ye
<mjg>
4th
<heat_>
does netbsd have a B interpreter?
<mjg>
supposedly great for "low level"
<nikolar>
mjg: they have lua in the bootloader??
<Ermine>
heat_: how so, that matrix inversion algo is at core of some algo trading system which brings $$$
vdamewood has quit [Ping timeout: 268 seconds]
<heat_>
matrix inversion is a math people jedi trick to convince us that their job is useful
<heat_>
prove me wrong, you can't
<heat_>
and don't let me get started on matrix determinants