* Anarchos
is working hard to understand the haiku PXE boot process
<bitigchi>
hello Anarchos
DKnoto has quit [Ping timeout: 480 seconds]
DKnoto has joined #haiku
paul0 has quit [Remote host closed the connection]
paul0 has joined #haiku
jmairboeck has joined #haiku
<Anarchos>
hello jadedctrl
<Anarchos>
hello jmairboeck
<ermo[m]>
Out of nothing but curiousity: With e.g. FreeBSD and the likes of Gentoo/Exherbo/<insert from-source linux distro> it is possible to do -march=native builds of both the kernel and the base os packages. In the case of FreeBSD, doing so is trivially supported. Does Haiku offer similar functionality and where might I learn more?
<ermo[m]>
The use case I had in mind was to minimise latency by maximising CPU performance, but it's really just a stray thought.
<ermo[m]>
I don't see any mention of CFLAGS/CXXFLAGS, so assume that it's a question of manually specifying them during `./configure` runs (if at all)?
<ermo[m]>
(if this is considered "ricing" and frowned upon, ok, my apologies)
AlaskanEmily has quit [Remote host closed the connection]
Guest3145 has joined #haiku
Guest3145 is now known as Begasus
<Begasus>
finaly back up and running here :)
<Anarchos>
Begasus great!
<ermo[m]>
another thing: Under Linux and FreeBSD, ECC RAM error correction and detection is supported (in Linux reports are made via the edac module and under FreeBSD via the mca module). Does the haiku kernel care/know about ECC RAM at all?
<Begasus>
First upgrade that went bogus, (made backups), then after new install black screen after boot (Ubuntu), glad I found a fix
Begasus_32 has joined #haiku
<ermo[m]>
I'm only asking because I am pondering whether to install Haiku on a motherboard w/ECC ram, so figured I'd ask.
<Begasus>
checked at the forum ermo[m] ?
<ermo[m]>
Yeah, not a lot hits on ECC support
<ermo[m]>
only that it doesn't actively impede the use of Haiku AFAICT
<Begasus>
no idea there, but did you try booting from USB?
<ermo[m]>
The most relevant post appears to be from 2018.
<Begasus>
eeps :)
<ermo[m]>
no, sorry, I didn't try it yet on the ECC hardware. It was more a question of IF I install it on a system with ECC-support THEN how do I check if haiku can detect/report ECC errors. =)
<ermo[m]>
Again, curiousity. Haiku nightly from yesterday booted and worked fine on an old Q9400 w/4GiB of RAM and a HD6450 card connected to a 1080p monitor via DVI.
<Anarchos>
ermo[m] is this a question or an affirmation ?
<ermo[m]>
the "does anyone know if Haiku supports ECC error detection and correction repoting" question was just that: A question.
<Anarchos>
ermo[m] i mean for your Q9400.
<ermo[m]>
The system I installed Haiku on last night (the Q9400) does not support ECC. Sorry if that wasn't clear. The thing is, I have another system that I could use (A Ph II 955BE w/ECC). So I was curious if it was worth it to switch over.
<ermo[m]>
But I'll dig around some more.
<ermo[m]>
as an aside, I was shocked to see that Haiku booted to a graphical desktop with only a Terminal running only used around 350 MiB of memory.
tuaris has quit [Read error: Connection reset by peer]
<ermo[m]>
My FreeBSD system w/Xorg and a bone stock Xfce desktop uses double that.
<ermo[m]>
And my Linux desktop with KDE uses around 1 GiB of RAM at idle with a terminal.
<Anarchos>
ermo[m] with or without ECC, haiku should run the same. Only that if you got error in rams, they won't be detected/corrected if haiku doesn't support ECC (which i have no idea if it does)
<ermo[m]>
Makes sense, cheers. If I'm interminably curious about it, I suspect I'll simply `ack` my way through a clone of the Haiku source code.
<ermo[m]>
For now, I have Haiku running and it looks as glorious as it ever did.
<Begasus>
Nice :)
<ermo[m]>
My regards to all you fine people who contribute to this little gem of an OS =)
xet7 has joined #haiku
<ermo[m]>
Installing was a tiny bit tricky as the disk I used had grub boot sector, but no stage2+3 grub boot loader. I ended up zeroing the first 512 bytes of the raw disk with DiskProber (holding down 0 and it showing how it overwrite the bytes was cool).
<ermo[m]>
I knew that Haiku has its own simple bootloader, but I had to reboot a couple of times to the USB installer to find the tool for installing it (my mistake, can't blame Haiku for that). Once I found it, it worked nicely.
<ermo[m]>
again, DiskProbe was useful for showing that the Haiku tool had indeed installed its own boot loader code in the first 440 bytes of the disk or so.
<Begasus>
Never had to use it (only occasionaly bootman)
<ermo[m]>
Refresh my memory: Is bootman the name of the Haiku tool that install the Haiku bootloader?
<ermo[m]>
*installs
<Begasus>
the bootmanager yes
<ermo[m]>
k
<ermo[m]>
Then that's what I used =)
<Begasus>
got a base USB install (but that only leaves about +600MB for Haiku to work with)
<Begasus>
Used that one to format and install Haiku on a 12GB partition, installed bootmanager on that, haikuporter tool, haikuports, ssh key for github ...
<Begasus>
nice to switch or try it out on other HW :)
<ermo[m]>
I guess that kind of answers my question!
<Begasus>
Or even if I want to do a new native install, I could use that one and update after install :)
<ermo[m]>
yeah, makes sense.
<Begasus>
hmm ... need to copy my ssh key to my Ubuntu install again too ;)
<ermo[m]>
Had a curious issue when using a HD 6570 card connected via DP to a 21:9 monitor. I got the white flash that I get with the HD 6450 connected to a 16:9 monitor, but the HD 6570 on the 21:9 monitor never showed me an image. I think the issue is that Haiku tried to configure the card to use the default monitor refresh rate of 100Hz, but since the card is so old, it only supports bandwidths that corresponds to 60 Hz at 3440x1440
<ermo[m]>
The HD6450 shows the native 16:9 1080p image fine FWIW.
<ermo[m]>
I suppose I should actually test with the HD 6570 card too (just to be sure).
<ermo[m]>
The 21:9 monitor's preferred mode according to its EDID block is the 3440x1440 100Hz one, so the 3440x1440 60Hz is only offered as the second mode. It could be that Haiku is oblivious to the bandwidth constraints of the connector used and simply defaults to picking the preferred mode...?
<ermo[m]>
(Xorg can deal with this fine, so I'm guessing it's simply a issue that comes up so infrequently that nobody's really encountered it before)
<ermo[m]>
in Haiku I mean.
<Begasus>
wip I guess, there is still quite some work done on the drivers
<Anarchos>
ermo[m] xref.landonf.org is a true aid to me to understand the source code
<Anarchos>
ermo[m] my question about TRACE_BOOT was not for you, but for advanced developers
<ermo[m]>
Ah, k.
bitigchi_2 has joined #haiku
jmairboeck has joined #haiku
bitigchi has quit [Ping timeout: 480 seconds]
<ermo[m]>
There's a lot of interesting `TRACE_*` stuff it seems...
<ermo[m]>
From a cursory look, it's not clear to me how boot options are passed -- except it looks like bits might be set in an uint32 field and then bitmasks are checked against that...
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
x10z has joined #haiku
_Dario_ has joined #haiku
tuaris has joined #haiku
<waddlesplash>
Anarchos: you have to enable tracing at build time generally
<waddlesplash>
ermo[m]: indeed we don't have an ECC driver unfortunately
<waddlesplash>
I run Haiku on a machine with ECC RAM but I'm not familiar with what actually utilizing it would entail
kinkinkijkin has quit [Quit: Leaving]
Begasus has joined #haiku
<Begasus>
jmairboeck, alive?
<jmairboeck>
Yes, Begasus, I'm here
<Begasus>
jmairboeck, any work needed for texlive?
<jmairboeck>
the DejaVu fonts seem to be not seen by fontconfig, that is probably the reason why xetex doesn't find them too
<jmairboeck>
I don't know yet, why that is
<Begasus>
did you try to see if you could fix fontconfig to see if it an detect the correct fonts?
<jmairboeck>
I am currently in the process of figuring out how to fix that, but I have no real idea yet
<Begasus>
Made some changes to xpdf to detect the correct fonts, maybe fontconfig also needs something simular?
<jmairboeck>
I don't really know how fontconfig works
<jmairboeck>
I'll take a look at your xpdf fix
<Begasus>
Haven't investigated any thing further yet, so not familiar also
<jmairboeck>
the tex gyre fonts and the noto fonts are shown by fc-list, but not dejavu
Begasus_32 has quit [Quit: Vision[]: i've been blurred!]
gouchi has joined #haiku
<Begasus>
OK, we'll hold of on merging atm untill you can figure this out :)
<Anarchos>
waddlesplash ok
<Anarchos>
waddlesplash i am trying the pxe boot
<andreasdr[m]>
Hi all! How is it going?
<andreasdr[m]>
x512[m]: Any news about Radeon Vulkan driver If I may ask? Also has the RX480 DisplayPort initialization bug been fixed?
<andreasdr[m]>
Super curious. Wasnt here for a while because busy. So super curious.
<x512[m]>
I spent time on RISC-V and other stuff, so currently no significant progress on RadeonGfx. I finally managed to switch from old RISC-V branch to current version. Recompiling a lot of packages was needed.
<andreasdr[m]>
Nice. Ok. Thank you for the update.
cp-- has quit []
cp- has joined #haiku
Yonle has joined #haiku
xet7 has quit [Remote host closed the connection]
DKnoto has quit [Ping timeout: 480 seconds]
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Begasus>
closing down here, g'night peeps
Begasus has quit [Quit: Leaving]
DKnoto has joined #haiku
<Anarchos>
jam haiku-image --> no space left on device :((
vdamewood has quit [Quit: Life beckons.]
<ermo[m]>
waddlesplash: looking at the tracing stuff, it seems that the #ifdefs are actually enabled by default, but some of the trace points are commented out?
<waddlesplash>
some tracing is enabled by default, depends on the driver
<ermo[m]>
Would be nice if they could be enabled at boot time with little branching cost though (I appreciate that it may not be that simple -- each time you don't take a branch, you do a jne instruction)
<ermo[m]>
but if those branches are predicted, then the cost could be low enough that it makes sense to hide it behind a boot-time flag?
<ermo[m]>
or...?
<ermo[m]>
(you're the guy with your hands in the muck, so I'm not going to presume I know something you don't!)
x10z has joined #haiku
<ermo[m]>
oh, while I'm here: Ran into an issue with emacs (GUI version) from haikuports took a really long time to start with DOOM Emacs and not looking sane ootb. I think it's because the default DOOM Emacs config uses fonts that are not normally available on Haiku. The load time become normal once all requested fonts were added (some via Haiku font .hpkgs, some installed manually because DOOM Emacs downloads them at install time)
<ermo[m]>
Yes, fringe-of-fringe-of-fringe use case. But still =)
* ermo[m]
wonders what the round-trip delay/latency is for the matrix<->OFTC IRC bridge...
<ermo[m]>
FWIW, plenty of tracing is available with the radeon driver and it shows selected/configured pixel clock too. So I should in theory be able to check the wonky-looking HD 6570 + 21:9 scenario if I can be arsed to.
Major_Biscuit has quit []
<Anarchos>
are broadcast ethernet packets from qemu sent to the haiku_host ?
<ermo[m]>
Huh. I wonder if there's a technique to "flag" code-paths with a default branch permanently. Like a kind of JIT VM where you "fuse off" code paths at system loader time (so pre-run-time, but post-compile-time)
<ermo[m]>
loader as in shared library loader
<ermo[m]>
anyway, just a stray thought
<Anarchos>
ermo[m] kind of a runtime loader patch ?
pch has joined #haiku
Vidrep_64 has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
Vidrep_64 has quit []
<ermo[m]>
Anarchos: yeah ... I think?
bitigchi has joined #haiku
pch has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 480 seconds]
pch has joined #haiku
ablyss has quit [Quit: Leaving]
mmu_man has joined #haiku
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
x10z has joined #haiku
<waddlesplash>
ermo[m]: well there's __builtin_expect to hint to the compiler which way you expect a branch to go
<waddlesplash>
you can also use "alt code patches" technique to have patchable code regions, though this is a bit annoying to deal with; at present it's only used in the kernel for SMAP/SMEP
<nephele>
ermo: if you want you could also put the tracing and non-tracing variants in seperate add-ons and load only one of them :P
<waddlesplash>
anyway, the vast majority of the time, traces are just not needed. I think FreeBSD et al. use sysctls to have traces enableable at runtime but even then they have some that aren't compiled in
<nephele>
Personally I build haiku with almost all debug flags turned on though... I guess that means my haiku system is the slowest
<waddlesplash>
well most traces are behind per-file flags
<waddlesplash>
the global settings don't affect that
<waddlesplash>
and, I think KDEBUG_LEVEL=2 which is the default on nightlies is already plenty slow
<waddlesplash>
maybe DEBUG_PAGE_QUEUE and a few other flags have even more slowness
<nephele>
Well, atleast the network kit tracing is enabled by my build flags and isn't per default. That already got some bugs fixed with more comprehensive bug reports
<nephele>
waddlesplash: why isn't there a curl/wget like tool build on network kit? FreeBSD has fetch intree. would be cool if we had something too. (especially so i can test the case of "download like webpositive would" easily on the cli)
<waddlesplash>
yeah, it would be nice
<Anarchos>
who could hint me to send broadcast packets from qemu to the haiku host ? i would like my haiku host to serve as a remote disk server for the haiku booting with pxe inside of qemu
Anarchos has quit [Quit: Vision[]: i've been blurred!]
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ermo[m]>
Is there any documentation for the debug stuff? I haven't yet looked, so apologies in advance. Pointers obviously welcome.
jmairboeck has quit [Quit: Konversation terminated!]
<waddlesplash>
what kind of debug stuff?
<ermo[m]>
<waddlesplash> "ermo: well there's __builtin_exp..." <- I was wondering if this could be used to good effect when enabling tracing a runtime (or boot-time at least)
<ermo[m]>
the variables that can be set
<ermo[m]>
e.g. KDEBUG_LEVEL=2, DEBUG_PAGE_QUEUE etc.
<ermo[m]>
*at runtime/boot-time
<waddlesplash>
no, __builtin_expect is purely an optimization thing
<waddlesplash>
KDEBUG_LEVEL=2 is enabled by default
<waddlesplash>
DEBUG_PAGE_QUEUE is an obscure virtual memory debug feature, unless you have some very specific vm-related issues it's not relevant
<waddlesplash>
these options are global and are set in kernel_debug_config.h
<ermo[m]>
so, perhaps I am not making myself clear enough. Imagine that instead of having a debug sprintf hidden behind a compile-time define, you have it predicated on a branch that checks a bitmask (or the equivalent), but you have the `__builtin_expect` hint set on the branch behind the debug flag NOT being taken.
<ermo[m]>
such that, when the flag is NOT enabled, the compiler and the branch predictor will tend to try the non-debug code path first.
<ermo[m]>
I'm talking meta-level here FWIW, not criticising the current implementation or asking you to do stuff. I'm just thinking about it =)
<waddlesplash>
yes, that's a possibility, but it does lead to code bloat and the performance cost is not 0
<waddlesplash>
especially in the kernel, a TRACE() statement, even if disabled behind an if, might be in a code path that gets hit 1000s of times per second
<ermo[m]>
ack
<ermo[m]>
hence my quip about speculation and hiding the branch latency behind that
<waddlesplash>
hence we generally want those compiled out by default
<rennj>
haiku needs dtrace
<rennj>
haha,...dynamic tracing you got the trigger/probes in place
<rennj>
better than truss/strace
<rennj>
haiku needs dtrace,zfs
<ermo[m]>
or, rather, musing if there was way to do this that doesn't cost a non-trivial amount of performance -- there when you need, 0-cost (or as near as) when you don't.
<rennj>
modern day media os my ass
<rennj>
only the amiga makes it possible
<ermo[m]>
I think what Haiku needs is one more paid developer tbqh.
<rennj>
paid for shit
<ermo[m]>
rennj: are you on a rant now?
<rennj>
developers developers developers
<ermo[m]>
If so, don't let me interfere. Nothing like a bit of catharsis.
<rennj>
steve blamer was it
<waddlesplash>
ermo[m]: the performance is trivial but it multiplies
<ermo[m]>
waddlesplash: what's the biggest issues re. Haiku right now? What are you trying to tackle? Is there even any low-hanging fruit left to pick?
<rennj>
you know sun microsystems did good engineering, see how that went
<waddlesplash>
and extra "if" inside, say, the thread context switcher can show up in benchmarks quite readily
<ermo[m]>
I'll take your word for it ^^
<waddlesplash>
ermo[m]: I don't know, what stops you from using Haiku more? :)
<ermo[m]>
considering that I only installed it two days ago...
<ermo[m]>
or was it yesterday?
<waddlesplash>
right now I'm seeing if I can weld OpenBSD's WiFi stack onto our FreeBSD compatibility layer
<rennj>
you should add dtrace to kernel like freebsd did..more probes
<ermo[m]>
I've been wanting to for ages
<waddlesplash>
if successful this will get us 802.11n/802.11ac support in idualwifi7260 (as well as an overall more stable driver) and make PulkoMandy happy because it'll get us iwx which his new laptop needs
<rennj>
measurements
<rennj>
who wants something like that?
<ermo[m]>
I think, since you're asking, that the two things I'm missing "the most" is a) 3D acceleration and video encoder/decoder support and b) Firefox.
<ermo[m]>
I get that b) is a FF decision, not a Haiku decision.
<rennj>
heatmap of boot!
<waddlesplash>
ermo[m]: well, FF is open source, someone can work on porting it
<ermo[m]>
and multi-monitor support + multi-gpu support
<waddlesplash>
but browsers are an insanely big job. we have Chromium now but it crashes very readily
<ermo[m]>
I'm not criticising -- you asked what I was missing and I tried to reply as honestly as I could =)
<waddlesplash>
I tried poking at it but the problem is somewhere deep in memory management, and I didn't spend the time to try and comprehend what Chromium was doing
<waddlesplash>
yes, and I'm just explaining :)
<ermo[m]>
Even if I have only tried out Haiku intermittently over the past 5-10 years, I've always been enamored with its premise and concept, ever since the golden days of BeOS yore.
<waddlesplash>
video acceleration is of course a big one, x512[m] has the experimental RadeonGfx but he hasn't published it yet
<waddlesplash>
multi-monitor is on my radar. I poked around at our display server a few weeks back and finally got a handle on how it handles stuff at present
<waddlesplash>
once I get this new WiFi stuff working, then do a few rounds more work on HiDPI support, I will probably take a crack at multimonitor
<ermo[m]>
FWIW, I think your decision to "only" aim for Vulkan is a _Really Good Idea™_
<waddlesplash>
well, that's not a decision
<ermo[m]>
oh? Did I misunderstand?
<waddlesplash>
it's just that x512[m] decided to write a from-scratch driver and Vulkan support was easier than OpenGL
<waddlesplash>
nobody made any "decisions" that we're not doing OpenGL at the driver level
<ermo[m]>
So not a decision, but more like a fait accompli?
<waddlesplash>
though if Zink takes off more it may not really matter
<ermo[m]>
exactly what I was going to say next -- zink and kopper might be enough
<ermo[m]>
not thay I know/understand that code
<ermo[m]>
just general gist of it
<ermo[m]>
waddlesplash: what has been the most rewarding aspect of working on Haiku?
<ermo[m]>
(genuinely curious)
<ermo[m]>
from the progress reports, it seems like e.g. more POSIX compliance has been on the menu?
<rennj>
hah!
<rennj>
terminal termcap/termlib isnt unistd.h
<rennj>
donut.c prime example
<waddlesplash>
rennj: not sure what this all has to do with haiku, use #haiku-offtopic please
<waddlesplash>
ermo[m]: we are generally posix compliant enough that remaining stuff doesn't much matter
<waddlesplash>
we lack some XSI extensions but that hasn't been a huge deal usually
<ermo[m]>
Btw, am I correct in thinking that the default bash Haiku vendor config doesn't attempt to parse a user .bashrc by default?
<rennj>
terminal no dev/ptys same for x11..its all messed up..haiku console sucks
<waddlesplash>
ermo[m]: no, it does?
<waddlesplash>
but our bash rc/profile/etc are stored in ~/config/settings, not ~
<waddlesplash>
and without a . -- so ~/config/settings/bashrc for example
<ermo[m]>
I only mention it because I tried using Web+ on the latest nightly (ending in 85 IIRC) and it failed to load app.element.io
<rennj>
well my haiku 2021 r1b3 fails
<waddlesplash>
error paste.
<rennj>
ill try nightly
<ermo[m]>
so I would need to manually connect to oftc using an IRC client and I much prefer using matrix (for cross-device purposes and history retention)
<rennj>
if you fixed the console...great
<waddlesplash>
ermo[m]: try Falkon
<ermo[m]>
That failed too =)
<ermo[m]>
it just stops loading
<waddlesplash>
that's the Chromium-based browser. Crashes on YouTube a lot but a lot of other site work
<waddlesplash>
huh
<nephele>
I'm not surprised, Element is pretty "special". You can open a ticket if you want, but using a native matrix client would be far easier
<ermo[m]>
weechat (which I'm familiar with and use for libera.chat channels that haven't yet moved to matrix) has a matrix .py module
<ermo[m]>
It looks as if python is not available on haiku ...?
<nephele>
WebPostive fails on some sites and has some rather annoying issues, would be nice to have some more hands on deck to iron them out :p
<nephele>
Python works just fine on haiku
<ermo[m]>
(if it is, then I made a fatal error in using HaikuDepot)
<ermo[m]>
i.e. looked in the wrong place
<nephele>
quaternion can be used for example
<waddlesplash>
ermo[m]: you need All Packages tab. main tab is basically just GUI applications
<waddlesplash>
or use "pkgman" on the CLI
<ermo[m]>
again, none of this is supposed to be moaning. I'm new to Haiku and am simply reporting what I saw =)
<ermo[m]>
Ack and understood
<waddlesplash>
you can also just ask for commands
<waddlesplash>
pkgman install cmd:python3
<ermo[m]>
cool
<ermo[m]>
like, genuinely cool
<nephele>
Yes, but if you want it fixed better to have a ticket ;)
<waddlesplash>
or libraries. e.g. pkgman install lib:libncurses; or pkgman install devel:libncurses
<waddlesplash>
will show you all things that provide those libs/devel and you can pick
<ermo[m]>
nephele: It's a bit soon for that yet, but I'll keep it in mind. =)
<ermo[m]>
How long has haikuports been a thing?
<waddlesplash>
early 00s
<ermo[m]>
wow
<waddlesplash>
however it is extremely different post-2013, which is when the package manager was introduced
<waddlesplash>
and really only took off after that
<ermo[m]>
ah k
<ermo[m]>
Sounds like I need to fire up le haikubox again and tinker
<ermo[m]>
one last thing I've been wondering about: Is there any particular reason that betas are released so relatively infrequently?
<ermo[m]>
Like, my experiences with nightlies have been pretty decent
<waddlesplash>
we aim for once a year, but there's been talk about twice a year
<ermo[m]>
So was just wondering if there were criteria that wasn't immediately visible
<waddlesplash>
right now there's still regressions from the last beta
<ermo[m]>
* So was just wondering if there were criteria that weren't immediately visible to the lay-person
<ermo[m]>
in case my vote matters any (which I doubt), every six months would get my vote (assuming there's resources for it and that cutting a release isn't too human-time-intensive)
<ermo[m]>
Ah, nice. Cheers.
<waddlesplash>
the blocker & critical priority tickets are the problem
<waddlesplash>
though one or two of those are basically "change this thing before release" so they aren't actually holding anything up
<nephele>
ermo: we try to aim for "better than the previous beta" and no regressions ;)
<ermo[m]>
hehe, not a bad metric by any stretch of the imagination! ^^
<nephele>
6 months has this far not been enough time, maybe that will change, who knows. but releases are generally done once somebody does it
<ermo[m]>
understood
<nephele>
which will likely be waddlesplash for the forseeavle future
<ermo[m]>
I can see how a 6 month cadence would perhaps require a different mindset/approach
<nephele>
Well, it's all volunteer work mainly, and nobody is expected to be around all the time or have to work on a fixed schedule
<ermo[m]>
For reference, I've helped maintain packages (including system packages) for a rolling release Linux distro which synced from unstable to stable every week (sometimes every other week)
<ermo[m]>
every once in a blue moon, we'd cut a new iso with all the related announcements and fanfare
<ermo[m]>
it's a non-trivial amount of work to cross the t's and dot the i's, so I can relate.
<nephele>
If you follow development nightly is fine i guess, sometimes it randomly breaks (you can just roll back then)
<ermo[m]>
Releases are never easy. On the flip-side, they bring a different focus than the day-to-day dev-grind
<ermo[m]>
so it's horses for courses I guess?
<nephele>
Our releases are more focused for end users
<nephele>
I don't know that expression
<ermo[m]>
I think it's meant to imply that a work or a draft horse pulling a heavy cart is different to a race horse or a war horse
<waddlesplash>
we have pretty exacting standards about quality
<ermo[m]>
and that you pick the approach that helps you achieve your goal
<waddlesplash>
honestly I don't understand the Linux mindsets here, they are just so radically foreign to what we do
<nephele>
Ubuntu LTS has a bi-yearly release cycle also, so we are half that :D
<ermo[m]>
The out of the box look and feel of Haiku is finger-lickin' good.
<ermo[m]>
like, literally lovely and excellent was my first impression
<ermo[m]>
so if the same amount of care and love goes into Haiku under the hood...
<ermo[m]>
(sorry to be gushing like that, but I really love how Haiku looks and feels ootb)
<nephele>
waddlesplash: The newest ubuntu release fixed opening files in the file manager, but now the terminal open function is gone, lol
<waddlesplash>
oh yes, we definitely care that much under the hood
<ermo[m]>
the terminal open function is IIRC a plugin
<ermo[m]>
i.e. you might be able to install it
<waddlesplash>
part of the reason Haiku has survived this long is that it's genuinely pleasant to work with internally
<ermo[m]>
to get it back
<waddlesplash>
the Haiku kernel-space APIs and general programming ergonomics are genuinely better than many user-space ones on other OSes IMO
<nephele>
It wasnt before, i installed it, it opens the wrong terminal *shrug*
<waddlesplash>
not to mention we are almost obsessive about code readability and organization
<ermo[m]>
it might be that you have a different xdg-terminal app registered fwiw
<waddlesplash>
PulkoMandy has talked about this before too I think, but the Haiku codebase is a real pleasure to just *read*, which is really rare, and we are proud of that for sure :)
<ermo[m]>
(i can't remember the exact name, but XDG and terminal is a good starting point iirc)
<waddlesplash>
nephele: LOL
<waddlesplash>
ermo[m]: Open Terminal is a "plugin" on Haiku as well, but it's a built-in one
<nephele>
ermo: honestly, even for "console" stuff gaiku to me is so much better, copy and paste is the same /everywhere/, i can press alt to just open files in the terminal, many small things
<ermo[m]>
Here, it's a Nautilus (GNOME file manager plugin) from memory
<waddlesplash>
yeah, Cmd+click to open paths in Terminal is killer
<nephele>
ermo: xdg-open and consortd are horrible, i replaced it with a shell script when i was still stuck on linux to get even bearble apps :(
<ermo[m]>
Some DEs on Linux have that. The only thing that comes close in integration is probably KDE.
<waddlesplash>
ah, good old xdg-open
<waddlesplash>
linux DEs are really just such a disaster when you get down to it
<nephele>
Yeah, in kde you can configure copy shortcut and then it works nowhere
x10z has joined #haiku
<waddlesplash>
the "broad strokes" features work, the little details almost universally do not
<ermo[m]>
And that is nowhere near as polished as Haiku. That said, KDE probably offers more ootb features/functionality. It's a tradeoff I guess.
<ermo[m]>
That's a pretty succint and accurate assessment. I agree.
<ermo[m]>
The curse of configurability out the wazoo some might argue.
<nephele>
waddlesplash: I symlinkef xdg-open to open because motion memory... that was a disaster, xdg-open only takes one argument so naively doing open * failed
<ermo[m]>
nephele: are you on a phone? Your typos are hilarious =)
<nephele>
Yes
<nephele>
My most annoying thing with xdg-open is it opening wine notepad.exe for everything
<ermo[m]>
... not that I'm doing much better today on a real keyboard, mind!
<ermo[m]>
yeah, that notepad.exe wine thing gets me every time
<nephele>
or wine internet explorer for... images
<ermo[m]>
Grinds my gears.
<ermo[m]>
lulz
<waddlesplash>
nephele: LOL
<ermo[m]>
Hrm. What do I need to read about setting up sshd account access on Haiku?
<waddlesplash>
make sure you have a sshd user
<nephele>
Either use useradd or enable root logins
<waddlesplash>
then either create a non-root user, or enable root logins in ssh, yes
<ermo[m]>
curious about that user thing btw
<nephele>
waddlesplash: the package installation is supposed to enable that
<waddlesplash>
nephele: is this because only WINE sets up proper "file associations" and nothing else can be bothered and just expects the file manager to handle that?
<ermo[m]>
It looks like the 'user' account is uid 0 by default, yet it doesn't have traditional "root" full access to everything?
<waddlesplash>
nephele: it's supposed to but that was only fixed just before the last beta iirc, worth double checking
<ermo[m]>
waddlesplash: it hijacks mime types on installation it would seem
<waddlesplash>
fun
<nephele>
waddlesplash: it is because installation order matters to xdg, user preference does not and it has no way to ask the user
<waddlesplash>
ermo[m]: no, it does.
<waddlesplash>
ermo[m]: if you mean /system being "access denied" That's because most of /system is read-only
<waddlesplash>
due to packagefs
<ermo[m]>
Ack, was going to ask about that next
<ermo[m]>
as I assumed that it must be immutable
<waddlesplash>
so, Haiku's package manager is built into the kernel
<waddlesplash>
packages on Haiku are block-compressed filesystem images
<waddlesplash>
the kernel mounts these on boot via packagefs, and installation/uninstallation just mounts/unmounts them
<ermo[m]>
actually, is Haiku a micro-kernel thing or is it more of a hybrid-kernel thing with "kits" or "servers"?
<waddlesplash>
modular monolithic
<ermo[m]>
so /system is "composed" of packagefs blobs?
<waddlesplash>
though it relies on some stuff happening in userland more than Linux or FreeBSD do because the userland and kernel go together
<waddlesplash>
no
<nephele>
waddlesplash: any reason we use the passwd format still? If we had single files in a dir the ssh package could just include a file for its uer
<waddlesplash>
... do we have a document explaining this? I feel like I've explained it so many times we should just have a FAQ :-p
<ermo[m]>
so modular monolithic for performance reasons I'm guessing (to avoid IPC overheads)
<nephele>
blog posts maybe
<waddlesplash>
nephele: talk to mmu_man, he wrote a query/attribute-based user management thing somewhere
<waddlesplash>
ermo[m]: nah, just historically BeOS was monolithic and so are we because in the early days we were 1:1 ABI compatible even at the kernel level
<waddlesplash>
these days we've broken kernel ABI/API quite a bit
<ermo[m]>
for the better I assume...?
<waddlesplash>
yes
<ermo[m]>
(I've no idea what "better" is in this context, mind.)
<nephele>
The monolothic/microkernel destinction is pretty pointless nowadays
<waddlesplash>
no, it's not?
<waddlesplash>
microkernels do basically nothing in kernel mode and hand off to drivers/servers in userspace for even disk I/O or the like
<waddlesplash>
monolithic kernels do everything in kernel space, or at least all the actually important stuff
<ermo[m]>
hence my IPC or, well, context switch really quip
<waddlesplash>
ermo[m]: anyway. /system/packages and /system/settings are real directories, and the former of those contains the .hpkg files and associated data
<ermo[m]>
but IPC (communication between different drivers/servers running in user-space) implies context switching
<waddlesplash>
then /system/bin, /system/lib, etc. are a "union mount" of the packages in /system/packages
<waddlesplash>
the kernel however doesn't know anything about package dependencies or the like, so it relies on userspace to manage all that
<ermo[m]>
and if haiku has everything in ring0 (or the equivalent) then that's monolithic by definition
<nephele>
waddlesplash: almost all OS fall in the middle of that destinction
<waddlesplash>
nephele: no, almost all OS are monolithic
<waddlesplash>
even Haiku. the only drivers we have in userspace are the accelerants and that only half-counts
<waddlesplash>
all other things dealing with devices are in kernel-space
<nephele>
Not really, we run some stuff in userspace and some atuff in kernelspace
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nephele>
same as linux, windows, darwin etc
<waddlesplash>
look, take it from a kernel and driver developer: we are monolithic and not "hybrid"
<waddlesplash>
by any definitions of the terms that make any sense at all
<nephele>
Yes, and I am saying the destinction is pointless and is not interesting to discuss
<waddlesplash>
no, it isn't pointless.
<ermo[m]>
are there any current CPU architectures which make concessions wrt. microkernels and the need for fast(er) context switching via dedicated operations?
<nephele>
Both design share many problems that people keep trying to atribute to one of them, while they have to be solved in both cases just differently
<waddlesplash>
a good test might be: if the kernel *must* start userland in order to even mount the boot device (because device, disk, filesystem drivers are in userland), it's a microkernel
<waddlesplash>
if the kernel *can* but does not *must*, it may be a "hybrid" kernel
<nephele>
stuff like resiliance against crashes, message passing er
<waddlesplash>
if the kernel *cannot* or *does not* start userland before mounting the boot partition, it's a monolithic kernel.
<nephele>
Unix was a microkernel?
<ermo[m]>
microkernels as in "proper" microkernels (where device, disk, fs drivers are in userland)
<waddlesplash>
err, I don't think so
<waddlesplash>
MINIX was, I think?
<ermo[m]>
nephele: I think Minix is
<waddlesplash>
but that's not UNIX
<waddlesplash>
well, UNIX as in "Bell Labs UNIX:
<ermo[m]>
Intel runs Minix in some of their firmware
<ermo[m]>
iirc
<waddlesplash>
as opposed to "UNIX" the generic term of which Haiku is one
<ermo[m]>
... Haiku is a UNIX?!
<ermo[m]>
TIL
<waddlesplash>
yes
<nephele>
Unix has the mount command on a specifoc drive because it was the first one to mount and required to moubt the rest
<ermo[m]>
because it can POSIX presumably?
<waddlesplash>
our POSIX compliance isn't a compatibility layer, it's how the system natively operates
<nephele>
by your definitipn that would be a microkernel
bitigchi has quit [Ping timeout: 480 seconds]
<waddlesplash>
nephele: I don't know much at all about how Bell Labs UNIX operated so I can't judge that
<ermo[m]>
well, it was around 9k SLOC if my memory serves me correctly
<nephele>
Haiku isn't a UNIX because that's trademarked ;)
<waddlesplash>
Haiku adheres in large portions to the "Single UNIX Specification" (i.e. POSIX)
<ermo[m]>
so it's a *NIX then. ^^
<waddlesplash>
yes, we aren't "certified" so we can't call ourselves the term, whatever
<nephele>
Yeah
<waddlesplash>
ermo[m]: yes. we have the fork()-based process model, UNIX-style file descriptors, Berkeley sockets, mmap(), and plenty of other UNIX staples
<nephele>
It's also not unix in the sense of people using "the unix way is to x" :p
<nephele>
I love how / is just virtual in haiku
<waddlesplash>
BeOS was also arguably a Unix though a bit less of one; it also had the fork() based process model
<nephele>
no hangs because / is an nfs mount and the server is down
<waddlesplash>
yes, rootfs is nice
B2IA has quit [Quit: Vision[]: i've been blurred!]
<waddlesplash>
all the little things on Haiku that are like "oh, well that makes sense, why doesn't everyone else do that?"
<nephele>
Linux ramdisk even does that!... and then uses switch_root to kind of chroot to the "bornal system" for some reason, atleast many initramfs inplementations of didtros fo
<ermo[m]>
FreeBSD is imho saner than Linux when it comes to getting info
<waddlesplash>
yes, it is
<ermo[m]>
due to its nearly universal use of sysctl maybe?
<waddlesplash>
FreeBSD is overall saner than Linux in just about every respect
<ermo[m]>
and the obvious intermeshed kernel / userland setup
<nephele>
Indeed
B2IA has joined #haiku
<ermo[m]>
It does feel that way yes.
<waddlesplash>
when I need to look something up I reach for FreeBSD sources not Linux sources
<waddlesplash>
Linux driver code is generally incomprehensible to plebians
<nephele>
FreeBSD is still my goto server
mmu_man has quit [Ping timeout: 480 seconds]
<waddlesplash>
FreeBSD's is still not Haiku's but it's tolerable
<nephele>
sysctl on FreeBSD is nice
<nephele>
just sysctl hw.ncpu, to querry core number
<ermo[m]>
I am seriously considering switching my home server to FreeBSD.
<ermo[m]>
the geom framework is a godsend
<ermo[m]>
so sensible
<nephele>
instead of having a special case of "yeah this has its own cammand"
<milek7>
I really cannot agree with haiku codebase being pleasure to read
<ermo[m]>
with loonix, it's umpteen different things / silos
<zdykstra>
If you're not using ZFS on FreeBSD, you're doing it wrong (TM)
<waddlesplash>
milek7: no?
<nephele>
Oh, still my favorite console partitioning tool, If anything can fix a partition its freebsd
<waddlesplash>
well, tastes differ, I guess
<ermo[m]>
re. the haiku code base, what little I have read doesn't have a lot of "why" in terms of comments/inline documentation...
<ermo[m]>
I just run a spare box as a FreeBSD toy thing to get my feet wet. So that's the extent of my experience with FreeBSD.
<ermo[m]>
So make of my comments on the matter what you will.
<nephele>
Jails are like namespaces
<nephele>
but sane
<ermo[m]>
not containers?
<ermo[m]>
it feels like they do containerisation (in the sense that you cannot escape them)
<nephele>
Containers are build on linux namespaces
<zdykstra>
that's what containers are
<ermo[m]>
potayto potahto
<ermo[m]>
oh, does haiku have a redshift equivalent thing for adjusting display colour at night?
<waddlesplash>
no
<waddlesplash>
there's an open ticket somewhere about this
<ermo[m]>
as lovely as the blue is, it is pretty searing =)
<nephele>
linux namespaces is like 12 different apis to cordon off different things of the system
<nephele>
each container tool you use may use them differently, not use all of them etc
<ermo[m]>
we're back to my point about umpteen different silos
* nephele
still waiting on scientific evidence for night shift doing anything for cardiac rhythms
<ermo[m]>
that's the "danger" of having just a kernel with no defined userland with a single point of control. And the benefit too, I guess.
<nephele>
ermo: anyhow, first we need color calibratiom/ gamma correction
<ermo[m]>
cardiac rhytms?
<ermo[m]>
circadian rhythms?
<ermo[m]>
kk
<nephele>
Ah, used the wrong english word it seems :)
<milek7>
it could be I just explore wrong corners
<milek7>
but I encountered mixture of c and c++ style code, legacy abstraction that's leaky, then new abstraction which isn't much better (but it's in shiny c++!), static variables, and each piece of code doing same thing in different ways
<ermo[m]>
oh oh oh, I did some experiments with focus-follows-mouse and found that 750ms after the cursor has left one window is a good approximation of "now I want to select _this_ window instead"
<nephele>
Same thing in different ways is in some pöaces indeed
mmu_man has joined #haiku
<ermo[m]>
is there a way to tweak the delay for focus-follows-mouse in haiku?
<nephele>
I don't think we implement that with a delay, maybe? You'll have to look at the code, I foubt we will ever expose any ms delay on ghe UI
<ermo[m]>
and my point is that the delay is what makes focus-follows-mouse bearable to me. I'll take a look.
tqh has joined #haiku
<ermo[m]>
if you're wondering about the use case, let's say I'm in an editor which is at the front. I then close that and have a terminal under it. It's convenient for the mouse cursor over the terminal to select it as the new focus for me without me having to explicitly click it. It's a small thing, but I've gotten used to it now. =)
<nephele>
I just use shift tab for that
<ermo[m]>
(i.e. more of a "preference papercut" than a genuine functionality papercut as it were)
<nephele>
but the I've never used focus follows mouse either :p
<nephele>
Anyhow, I'll sleep now, have a good night
<ermo[m]>
g'nite
<waddlesplash>
milek7: ah, right, the architecture code is a particular problem here, yes.
<waddlesplash>
nobody has been bold enough to try to fix the leaky abstraction
KapiX has quit [Quit: KapiX]
<waddlesplash>
because, well, any time anyone winds up changing that code it often breaks things in very subtle ways
Atomozero has joined #haiku
<waddlesplash>
ermo[m]: well, you can change the colors...
<waddlesplash>
and if you are especially lucky on having a certain class of Intel graphics devices we do have brightness control
<ermo[m]>
HD 6450
<ermo[m]>
(on le haikubox)
<waddlesplash>
check Screen preferences
<waddlesplash>
there may be a brightness slider, and it may even work
<waddlesplash>
if it doesn't, see if there's a ticket or open one
<nephele>
waddlesplash: radeon_hd also has brightness
<waddlesplash>
oh, right, it does
<waddlesplash>
I forgot that, it's on the newer end :)
<ermo[m]>
so, keep in mind that this is a desktop with an add-in-board HD 6450, which is connected to an external monitor via DVI-D.
<ermo[m]>
I would be very surprised if I could adjust the brightness from the OS on that configuration ^^
<ermo[m]>
as in: I've literally never seen an OS that could do that.
<ermo[m]>
so if I can't, it is what it is.
<ermo[m]>
it does have brightness slider though. It just does nothing (as expected)
Vitto has joined #haiku
<nephele>
No, that is a bug
<nephele>
It should not appear in that case
Atomozero has quit [Quit: Vision[]: i've been blurred!]
tqh has quit [Quit: Leaving]
<ermo[m]>
waddlesplash: so, according to `man bash`, I should be able to add `~/config/settings/bashrc` and it'll be sourced when I start a terminal and/or open a new terminal tab, correct?
<waddlesplash>
yes
<B2IA>
(Butler) Welcome to BeShare.agmsmith.ca.
B2IA has quit [Quit: Vision[]: i've been blurred!]
<ermo[m]>
I would argue that the correct approach (i.e. the one following "the principle of least astonishment") would be to add an `/etc/profile.d/source-bashrc.sh` vendor config by default?
<ermo[m]>
so that bashrc is always sourced
<ermo[m]>
since that is the preferred/recommended place to add interactive stuff (exports, aliases, functions)?
<ermo[m]>
I'm happy to contribute said patch if you think it's worthwhile.
<ermo[m]>
Some distros use $PS1 to check for interactivity, but I believe the correct option is actually to check SHELLOPTS for the 'i' flag...
<ermo[m]>
(since we're nitpicking)
<ermo[m]>
or, well, since I am.
<ermo[m]>
jesus. Now I need to test that behaviour on all my Linux distro boxen and freebsd. Ouch.
<ermo[m]>
I suspect that there's less of a consensus than I intuitively assumed.
AlaskanEmily has joined #haiku
<waddlesplash>
well, if all Linux and BSD do that with /etc/profile.d then we should too
<waddlesplash>
but if not all do, then our behavior is probably valid
<ermo[m]>
precisely my point
<ermo[m]>
i.e. it doesn't make sense to file a bug until I know how it's supposed to be done
x10z has joined #haiku
x10z has quit []
AlienSoldier has joined #haiku
augiedoggie_ has joined #haiku
augiedoggie has quit [Ping timeout: 480 seconds]
<ermo[m]>
um ... how do I restart sshd in haiku?
DKnoto has quit [Ping timeout: 480 seconds]
DKnoto has joined #haiku
<waddlesplash>
disable/reenable it in Network settings
<waddlesplash>
probably we should get rid of the network service system and merge it into launch_daemon, but that hasn't happened yet
<ermo[m]>
ack
<ermo[m]>
incidentally, that's exactly what I tried (after I asked)
<ermo[m]>
so there's some method to the madness.
<ermo[m]>
It would be nice to also be able to start/stop (known?) services from the cmd line (rather than outright killing them)...?
<ermo[m]>
i.e. "ask nicely"
<ermo[m]>
if that's sending a SIGHUP, ok.
<milek7>
sorry for the gerrit spam
<waddlesplash>
milek7: don't worry about it
<waddlesplash>
ermo[m]: launch_roster
<ermo[m]>
Curious. I have sshd enabled, but no daemon shows up in `ps`
<waddlesplash>
shows up here
<waddlesplash>
maybe it failed to start
<ermo[m]>
I can start it with `/bin/sshd`
<ermo[m]>
but I rebooted.
<ermo[m]>
¯\_(ツ)_/¯
<ermo[m]>
user error. Misread man page. Forgot to add `yes` to `PermitRootLogin` in `/system/settings/ssh/sshd_config`
HaikuUser has joined #haiku
HaikuUser has quit []
<ermo[m]>
OK, Quaternion works well enough (can't really customise font sizes, need to look at that)
gouchi has quit [Remote host closed the connection]
ClaudioM has joined #haiku
<x512[m]>
waddlesplash: I don't think that Haiku process model if fork() based. Native and most efficient way to create processes is load_image/posix_spawn. fork/exec is less efficient. fork may now work well for GUI applications.
<waddlesplash>
yes, but the point is that fork/exec is the process model
<waddlesplash>
as opposed to e.g. Win32 where fork/exec doesn't exist
<waddlesplash>
fork() on Linux also doesn't work right with GUI apps
<x512[m]>
waddlesplash: NT kernel supports fork().
<waddlesplash>
now it does, for WSL
<x512[m]>
NT kernel supports fork() from very beginning but it is not well supported by Win32 subsystem.
<x512[m]>
It is exported by ntdll.dll.
<x512[m]>
waddlesplash: "multi-monitor is on my radar. I poked around at our display server a few weeks back and finally got a handle on how it handles stuff at present"
<x512[m]>
Do you have designs of multi-monotor support?
<x512[m]>
It is related to hardware acceleration so it is better to share and discuss architecture before implementing.
<x512[m]>
Basically total accelerant redesign is needed.
<x512[m]>
It should have framebuffer control capabilities: allocate/free video memory, atomically switch and synchronize framebuffer memory, potentially assign the same videomemory to different screens etc.
<waddlesplash>
yes
<waddlesplash>
I was hoping you would release some version of RadeonGfx and we could design Accelerants V2 based on that
<waddlesplash>
one of the big things I want to do is have a totally separate "accelerant cloning" system
<waddlesplash>
basically, "cloned" accelerants should be a totally separate structure from base accelerants
<waddlesplash>
and will just communicate with the "main" accelerant -- basically what you do for RadeonGfx libdrm2 calling back to the driver across processes
<x512[m]>
Yes. Cloned accelerant is basically client accelerant and not cloned is server accelerant and actual implementation.
<waddlesplash>
indeed
<waddlesplash>
the other goal is to move all accelerant operations to a new display_server
<waddlesplash>
this way, graphics drivers can also live in display_server, and so graphics driver crashes only crash display_server not app_server
<waddlesplash>
and display_server restarts can reconnect to app_server
<x512[m]>
About OpenGL hardware acceleration drivers: I actually managed to compile and run radeonsi Mesa OpenGL driver but it cause GPU to stall. I haven't investigated it in detail. Vulkan+Zink works quite well.