zetef has quit [Remote host closed the connection]
edr has joined #osdev
Arthuria has joined #osdev
m257 has quit [Quit: Client closed]
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
sham1 has joined #osdev
m3a has joined #osdev
spare has quit [Remote host closed the connection]
m257 has joined #osdev
goliath has joined #osdev
teroshan has joined #osdev
mctpyt has joined #osdev
m257 has quit [Quit: Client closed]
m257 has joined #osdev
Arthuria has quit [Ping timeout: 268 seconds]
foudfou has quit [Quit: Bye]
foudfou has joined #osdev
m257 has quit [Quit: Client closed]
gorgonical has quit [Ping timeout: 264 seconds]
m257 has joined #osdev
<nikolar>
ddevault very impressive
<ddevault>
thanks!
heat has joined #osdev
spareproject has joined #osdev
<gruetzkopf>
neat
<ddevault>
anyone know how to tell groff not to build docs for cross compiling
<gruetzkopf>
i was under the impression that there's a implicit make rule for what you did ( when calling it 'make main' in your example )
<ddevault>
oh I think there is
<ddevault>
but I don't like implicit rules tbh
<gruetzkopf>
fair
<sortie>
ddevault: https://gitlab.com/sortix/sortix/-/tree/master/ports ← In general, if you're looking for cross compilation advise and patches, check my patches. I don't have a groff port anymore though, since I use OpenBSD mandoc
<sortie>
You can usually disable building docs with stuff like --disable-docs, calling ./configure --help can show you options, or you can dig into the configure script and figure it out. Although generally if there's a cross issue, it's better to patch it
<ddevault>
mandoc gave me hell when it came to cross compiling
<ddevault>
ironically so does groff, but I worked it out
<ddevault>
gentoo was a good source for the issue there
<sortie>
I am on an older mandoc though back from when it was called mdocml
<sortie>
Somebody check if bunnix is just a lightly reskinned sortix
<ddevault>
is not!
<ddevault>
at this point bunnix is mostly integration work
<ddevault>
there's an issue with the EFI bootloader to sort out, I could dig into some ext4 stuff if I feel like it
<ddevault>
otherwise it's choosing and integrating the ports I want for the final product (and if I include mandoc or groff or so, writing some man pages)
<ddevault>
day 26
<ddevault>
if I'm not too distracted I should have something shippable inside of a month
xvmt_ has joined #osdev
xvmt has quit [Ping timeout: 268 seconds]
xvmt_ is now known as xvmt
<nikolar>
very cool
<nikolar>
any future plans
<heat>
>writing some man pages
<heat>
do not, HTH
<sortie>
>writing some man pages
<sortie>
Approved
<sortie>
heat is not a successful osdever
<sortie>
Your advise has been overruled
<heat>
wdym
<ddevault>
nikolar: dunno, maybe
Ermine has quit [Remote host closed the connection]
Ermine has joined #osdev
xenos1984 has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
spareproject has quit [Remote host closed the connection]
<dostoyevsky2>
Any ideas why Pulse Audio breaks so easily on Linux? Is it really that hard to properly interface with an Audio Device?
vikn has quit [Quit: Leaving...]
<gruetzkopf>
It's not hard to do with exactly one application using exactly one audio device. it gets substantially more complicated if you exceed that (more devices is a bigger problem than more applications)
vikn has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
k_hachig has quit [Ping timeout: 268 seconds]
<dostoyevsky2>
gruetzkopf: I guess the Linux kernel would need to have some RTOS-like feature to ensure that the audio buffers never stop being filled with many applications outputting audio at the same time... Not sure how common it is to use multiple audio devices at the same time
goliath has quit [Quit: SIGSEGV]
gog has quit [Quit: Konversation terminated!]
stux has quit [Ping timeout: 255 seconds]
k_hachig has joined #osdev
xenos1984 has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
k_hachig has quit [Ping timeout: 252 seconds]
k_hachig has joined #osdev
gog has joined #osdev
m257 has quit [Ping timeout: 250 seconds]
k_hachig has quit [Ping timeout: 268 seconds]
k_hachig has joined #osdev
theyneversleep has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
gorgonical has joined #osdev
<gorgonical>
So I tried to install pijul and I couldn't. Because the rust crate system is immature and some developer yanked a crate because they consolidated various separate crates into one crate. And you can't install yanked crates from rust, so I installed darcs instead
<gorgonical>
So, good job rust
heat_ has quit [Remote host closed the connection]
zxrom has quit [Remote host closed the connection]
heat has joined #osdev
zxrom has joined #osdev
SGautam has joined #osdev
<Mondenkind>
dostoyevsky2: because poettering?
<Mondenkind>
macos does have special kernel/scheduler integration with the audio daemon iirc, but that's not the problem with pulse.......
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
oldgalileo has quit [Ping timeout: 260 seconds]
frumon has quit [Read error: Connection reset by peer]
k_hachig has quit [Ping timeout: 268 seconds]
<dostoyevsky2>
gorgonical: Obviously the solution is to rewrite it in Hare
frkzoid has quit [Ping timeout: 246 seconds]
k_hachig has joined #osdev
k_hachig has quit [Quit: WeeChat 4.2.2]
MrCryo has quit [Ping timeout: 255 seconds]
<heat>
pulse is outdated now, everyone uses pipewire
<heat>
(which seems a good bit better)
<Ermine>
my headset works better with pipewire
<Ermine>
heat: are you still haunted by pipewire bugs?
goliath has joined #osdev
<Bitweasil>
I use Qubes. Working audio is a novelty. :(
<Bitweasil>
And, yeah, MacOS has some special sauce related to audio so it can keep realtime low latency audio generally working.
<zid`>
"audio is a luxury yo cannot afford" --My gameboy emulator
<Bitweasil>
Audio is usually a way to hear someone yapping away in a YouTube video that could have been written.
<Bitweasil>
"I will use several gigabytes of HD video to talk to the camera!"
<zid`>
I'll run it through libcaca at 80x24 for you
<Bitweasil>
What's libcaca?
<zid`>
video renderer that outputs ansi escapes instead of bitmaps
<Bitweasil>
> CET enables the OS to create a Shadow Stack, which is designed to be protected from application code memory accesses, and stores CPU-stored copies of the return addresses.
<Ermine>
Though SDM says that cpu modifies shadow stack on call/ret
<Bitweasil>
So it'll store the call/return addresses, without needing a cooperating compiler. The compiler still has to emit the branch target opcodes if you want to support that.
<Bitweasil>
Yeah, "CPU modifies" implies that the hardware is doing it, not the program.
<Bitweasil>
IMO.
<Bitweasil>
Though I've been in the ARM weeds a bit long so I'm a bit stale on my Intelisms.
<dostoyevsky2>
would be cool to be able to use the stack for O(1) allocations again
<Ermine>
alloca
<Bitweasil>
But fundamentally, mixing data and control flow on the stack enables a range of attacks. You could also split the control flow and data stack, and a suitably clever compiler and cooperating OS could do that easily enough, but nobody really has that I'm aware of.
<Bitweasil>
Shadow stacks are "We just check for mismatch on return and report malfeasance to the OS."
<zid`>
There was a 32bit cfi which abused the segment selectors afaik
<nikolar>
if i had to guess, it stores the return address to both the actual and the shadow stack
<nikolar>
so the code continues to work
<zid`>
you make ss: and ds/gs different
<zid`>
so that push goes to one stack, and you access the stack vars with [ds:]
<Bitweasil>
zid`, ah, nifty. I'm certain a lot of research papers have been written about ways to do it. Just, not aware of any that actually made into widespread use.
<zid`>
yea I don't think cfi/cet is widespread at all
<zid`>
It's slow without hw support, and intel's hw support wasn't very good afaik
<Bitweasil>
I didn't know it had actually shipped...
<Ermine>
dostoyevsky2: so it's not less buffer overflows, but more software crashed before nasty stuff happens
<zid`>
it is also less buffer overflowsw
<zid`>
It's *mainly* a security technique
<zid`>
even
<Bitweasil>
It makes ROP much more difficult, as do the branch target NOPs.
<zid`>
yea ROP is just an attack that bypasses *other* buffer overflow protections :D
<Bitweasil>
(those are essentially a "Your branch must land on one of these!" tag that's a NOP for non-supported CPUs, and if it's enabled, a branch to anything else will fault)
<zid`>
so removing buffer overflows also protects against those attacks too, naturally
<zid`>
CFG is slow and annoying
<Bitweasil>
Yeah. Stack canaries help a lot too.
<Bitweasil>
Computers are slow and annoying. Because software can bloat faster than hardware can improve.
<zid`>
CFG on windows had some good issues where it'd make making processes suuuper slow
<zid`>
because of all the faulting and missing and stuff building the security bitmaps
<zid`>
and bad code
<Bitweasil>
Hm. Which is CFG?
<Ermine>
control flow guard?
<zid`>
yea
<zid`>
the 'only certain branch targets are valid' impl
<Bitweasil>
Looks like Microsoft had the CFG stuff, that was pure software.
<dostoyevsky2>
I wonder if shadow stacks could also help with making threads cheaper... if you can separate the stacks into just return addresses and data, then you could set the minimum stack size much lower... e.g. usually creating a thread costs you at least 2k of RAM for the stack
<Bitweasil>
Intel's approach has the "End branch" targets, that are just a NOP.
<Bitweasil>
If you branch, your next instruction has to be the end branch target, or you'll fault.
<zid`>
dostoyevsky: stacks are usually demand faulted so they're free
Gooberpatrol66 has quit [Quit: Konversation terminated!]
zxrom has quit [Remote host closed the connection]
zxrom has joined #osdev
[Kalisto] has quit [Read error: Connection reset by peer]
[Kalisto] has joined #osdev
[Kalisto] has quit [Read error: Connection reset by peer]
[Kalisto] has joined #osdev
[Kalisto] has quit [Read error: Connection reset by peer]
[Kalisto] has joined #osdev
FreeFull has quit []
goliath has quit [Quit: SIGSEGV]
foudfou has quit [Ping timeout: 260 seconds]
foudfou_ has joined #osdev
<kof673>
> You could also split the control flow and data stack i do not recall details, and relevant "standards" but "forth"s had "return stack" and "data stack" IIRC