<nekobot>
[haiku/haiku] 9ae547b297c2 - data/network: Use ports & services files from OpenBSD.
<zdykstra>
thanks waddlesplash
<waddlesplash>
np
<augiedoggie>
64 bit package builder is still hosed :/
<augiedoggie>
i need to revbump a couple package updates that were lost
<zdykstra>
I started digging through the mail daemon code today. I couldn't find any way to show the error/status log, short of disabling the Hide() call. Looks like whatever mechanism was used to trigger that in the past is now disconnected.
<waddlesplash>
augiedoggie: yeah, I sent mmlr a message, hopefully will be fixed tomorrow
<zdykstra>
Has there been a discussion about adding timestamps to messages logged in syslog?
<augiedoggie>
i thought that was an option in the config file
<augiedoggie>
i'm pretty sure i have that turned on
<zdykstra>
Ahh. I'll need to find the config file.
<augiedoggie>
yeah, i'm trying to remember which one
<augiedoggie>
:P
<augiedoggie>
bah, i'll have to boot a VM and look
OrangeBomb has quit [Read error: Connection reset by peer]
BrunoSpr has quit [Quit: Vision[]: Ich wurde verwaschen!]
OrangeBomb has joined #haiku
<zdykstra>
what are the effects of a small swap file relative to physical memory?
<zdykstra>
I have 24GB of RAM, do I even need a swap file?
jmairboeck has quit [Quit: Konversation terminated!]
<waddlesplash>
probably not
<waddlesplash>
I have it disabled as I'm on an SSD
<waddlesplash>
the worst that will happen is that you get more OOM errors, but since there's no overcommit, there's no OOM killer
<phschafft>
how is mapping a large file is handled?
<waddlesplash>
what do you mean?
<phschafft>
let's say I have 1GB of RAM but I mmap a 2GB file completly.
<waddlesplash>
won't work
<phschafft>
hm.
<waddlesplash>
it will only work if you use an overcommit flag
<waddlesplash>
i.e. when invoking mmap
<waddlesplash>
and if you do that, you run the risk of getting SIGSEGV when physical memory is exhausted
<waddlesplash>
since it's an mmaped file, the system may be able to help you by discarding non-dirty pages
<waddlesplash>
but if you write to too many pages at once and the system can't keep up, SIGSEGV
<phschafft>
I mean specifically with a mapping that has a physical file as a backend there is really no problem as data can always be fetched/stored on the backend.
<waddlesplash>
yes, if you're doing read-only then the system can just discard in-memory pages that are unused
* phschafft
nickt.
* phschafft
nods.
<phschafft>
so basically that is a kind of OOM kill.
<waddlesplash>
no
<waddlesplash>
the application can catch the SIGSEGV as a regular signal and decide to do something other than crash
<waddlesplash>
if the OOM killer on Linux decides to kill a process, it's dead, no intervention possible
<phschafft>
yes, but still it's a signal send as the kernel can not provide the memory for a mapped region.
<waddlesplash>
yes
<phschafft>
this is what I mean with *a kind of* OOM kill.
<waddlesplash>
well, it's still pretty different because you can only get this if you specified a "I will accept overcommitting" flag
<phschafft>
maybe a bit more friendly than the linux variant.
<waddlesplash>
so, applications that don't specify that will never get killed
* phschafft
nods.
<phschafft>
what happens when the stack needs to grow but we're out of memory?
<waddlesplash>
i.e. the app that borrows more than exists, is the one that runs the risk
<waddlesplash>
similar thing, faults
<phschafft>
is the signal handler on a seperated stack?
<waddlesplash>
sigaltstack, yes
<phschafft>
ok. :)
<phschafft>
otherwise it's hard to call the handler ;)
<waddlesplash>
that's posix standard
* phschafft
nods.
<phschafft>
several operating systems have a wide range of options here. and some are creative at understanding any kind of standard.
<phschafft>
waddlesplash++ # for actually answering my questions that most devs don't even understand.
<waddlesplash>
most are creative at understanding standards; so are we
<waddlesplash>
sometimes we decide it isn't worth being creative and just not following the standard :)
<waddlesplash>
and this stuff's pretty tricky and highly technical. I certainly didn't know any of it when I first started on Haiku years and years ago. happy to help :)
<phschafft>
:)
<phschafft>
my job is a lot of reading all kinds of standards. I do a lot of lower level stuff. often real time, network, high performance or a mix of all that.
selfish has quit [Quit: Leaving.]
selfish has joined #haiku
<phschafft>
so I often end up in fights on how to creatively understand a standard. but it is also fun to learn about how so many things work on the inside.
<waddlesplash>
nifty!
<waddlesplash>
the lowest I've worked with is device driver submitting commands to hardware, here on Haiku
<waddlesplash>
I've never worked in proper "low level" of firmware
<phschafft>
I did high speed FFTs on signal lines of SoCs, and I still need to answer that request for a smart device app. But my preferred level is right on top of the kernel in the userland.
<phschafft>
so I don't need to think about how to send an ethernet frame with that card, I can just send it. But I still need to care what is inside that frame.
<botifico>
[haikuports/haikuporter] waddlesplash b3987b8 - ShellScriptlets: Avoid interactivity in checkedUnmount.
<botifico>
[haikuports/haikuporter] waddlesplash 9ba1c5c - HaikuPorter: check_call not check_output for cleanupChrootScript.
<accessays>
How do I go about recompiling a single application? Say I want to modify some code in Deskbar and test the new version. I've setup the dev environment to compile Haiku from scratch, but it feels excessive to recompile the whole OS for a single first party app
<waddlesplash>
just build Deskbar, stop the existing one, run your new one
<waddlesplash>
launch_roster controls deskbar, use "launch_roster" to see the list of mimesigs it's managing, then "launch_roster stop <mime_signature>" to stop it
<waddlesplash>
and with a configured Haiku tree, you just run "jam -q -jN Deskbar" to build only Deskbar
<waddlesplash>
note that some apps, like Tracker, put most of their code inside a .so and so modifications for these you have to create a small "testing" directory where the correct new .so will be loaded in order for that to work
<waddlesplash>
you also can recompile just haiku.hpkg and install it instead of a full system image
<augiedoggie>
is the gcc2 builder stuck again? :P
<waddlesplash>
nope
<waddlesplash>
I just checked
<waddlesplash>
it's just got a very slow connection for downloads...
<augiedoggie>
my connection to the package repo is slow from haiku, i usually only get ~400Kb/s
<augiedoggie>
when doing updates
<augiedoggie>
need a US mirror
bjorkintosh has joined #haiku
AlaskanEmily has joined #haiku
<mbrumbelow[m]>
<waddlesplash> "there's a ticket about that" <- I was looking at that ticket. I am seeing strange behaviors like transfer running very slow. Etc….
<waddlesplash>
hmm, not sure about that
<mbrumbelow[m]>
Yeah it’s hard to pin down. I am transferring 1.5 GB file. It takes 30 mins.
<waddlesplash>
well, that can just be Haiku throughput
<waddlesplash>
see how fast it transfers over wget