Maybe XBC (?)

But i have no idea about sound and where i can get better netbsd sound documentation than the guide i can see on users guide

<b>aaron:</b> VMS (Telegram): As long as you’re not using DirectX, any library is pretty much fine.

Chapter 11. Audio https://www.netbsd.org/docs/guide/en/chap-audio.html

<b>aaron:</b> VMS (Telegram): My best guess would be apropos audio, check what driver is loaded, see what sound system it’s connected to, then use that API.

audio(4) - NetBSD Manual Pages http://netbsd.gw.com/cgi-bin/man-cgi?audio+4+NetBSD-current

Mmm

I will have seriously troubles if i want port it to linux

<b>aaron:</b> Yes.

So i should use portaudio? Or i have better options

I must check better ?

aaron: There’s about twenty sound libraries that where written to solve this exact problem (free cross-platform support, with a sane API.)

I will have seriously troubles if i want port it to linux

Will be uncompatible with other bsd so... no way

Yeah. I must think hard

I want make a good choice and don't cry later

<b>aaron:</b> And yes, if you use OS-specific APIs, you should expect that it will be tied to that OS. This is the opposite of the Linux problem, where people unnecessarily depend on random kernel APIs because it seems fun.

But will be interesting a little game which runs on netbsd if it can run on all architectures supported by netbsd

aaron: (And this is why Gnome depends on the init system for some reason...?)

<b>aaron:</b> VMS (Telegram): Using a library doesn’t mean you automatically loose support for all the NetBSD platforms.

<b>aaron:</b> In fact, there aren’t many cases where using a library decreases the number of systems and platforms you can run on.

<b>aaron:</b> VMS (Telegram): Also, one of the rules of thumb in programming is you will rewrite your program at least once during development. So just write something, and then make it better later.

Yeah... but this library must be on all pkgsrc arquitecture-specific repos

Or most of them

Just i must choose the best sound cross-platform supported by netbsd?

<b>aaron:</b> VMS (Telegram): Also, one of the rules of thumb in programming is you will rewrite your program at least once during development. So just write something, and then make it better later.

I remember they said. Write once compile everywhere

I don't like "versionitis" and i think i don't like put an incomplete online version

But i will need make a testing version anyway

<b>aaron:</b> VMS (Telegram): I think you are vastly underestimating pkgsrc. We’re not talking a hundred libraries here. It’s tens of thousands across some 15 platforms. You’re going to have to work hard to find a sound library of all things that hasn’t been ported (or is simply a direct compile) to all platforms with a sound device.

<b>aaron:</b> VMS (Telegram): And any sound library with NetBSD support will be using a kernel interface available across all platforms. That is the job of the NetBSD porting team.

I don't understand how works and what can do the netbsd abstraction layer. I know it's related with the rumpkernel

<b>aaron:</b> VMS (Telegram): And to put it bluntly, you don’t know how to program yet. The first few hundred pieces of code you write are going to be terrible as you learn. You’re going to have to go back and fix them when you know more. This is not versionitis, this is simply the learning process.

And don't understand how works and what can do pkgsrc

<b>aaron:</b> VMS (Telegram): And to put it bluntly, you don’t know how to program yet. The first few hundred pieces of code you write are going to be terrible as you learn. You’re going to have to go back and fix them when you know more. This is not versionitis, this is simply the learning process.

Yeah. XD i mnow

I know all

All i will write now must be erased or modified

Because i will write shit

<b>aaron:</b> VMS (Telegram): I’ll start from the bottom and explain upwards a bit, then start at the top and explain down a bit. Hopefully that’ll clear up some things for you.

<b>aaron:</b> At the bottom you have a speaker attached to a sound card which has some memory the kernel maps (shares). To make sound, the kernel writes out a soundwave into that memory, then writes go for a time.

<b>aaron:</b> When a program wants to play a sound, it uses a library to make it easy write a digital soundwave to the kernel who will then pass it off to the sound card. The library is largely invisible mechanically.

Just it's a short way to write on sound card buffer

aaron: Rump kernels come in when you want to wrap up a NetBSD driver and bring it to another platform. (Or twenty other strange things that are more convoluted than strictly necessary.)

<b>aaron:</b> VMS (Telegram): Indeed. You can just skip the kernel and write directly to your sound card’s memory. Just gotta figure out how to do that for every sound card you want to run on.

<b>aaron:</b> VMS (Telegram): Indeed. You can just skip the kernel and write directly to your sound card’s memory. Just gotta figure out how to do that for every sound card you want to run on.

You mean with assembler?

<b>aaron:</b> C. Or whatever you want.

Mmm

Ty

I like the tips and teaching

<b>aaron:</b> Using the kernel interface (called a sound driver) saves you that pain. Using a sound library steps you up one layer higher; instead of writing your sound to each card, you have to write your sound out to each operating system. It’s like a pyramid.

Yeah. Got it

<b>aaron:</b> There is a balance between using forty libraries like Chrome/Firefox, and no libraries. It’s your job as a programmer to find the right location on that spectrum.

<b>aaron:</b> Where pkgsrc comes in is an easy way to bring software to many systems without the requirement to manually track down the dependencies or the build instructions.

I like hard way. But must be a possible way xD

<b>aaron:</b> Some rules of thumb here for writing portable software: 1.) Pick a portable language. Anything with a compiler/runtime that is already ported around quite a bit is a good idea. C is the best here. Any llvm language like rust is not great for going beyond x86/x64.

C is my main option

<b>aaron:</b> 2.) Avoid direct system interfaces. Most programs have no business accessing the init system. Sound and graphics are other ones that should be abstracted.

<b>aaron:</b> Following 2 is to try and use libraries when possible (or where it makes sense.) It’s generally easier to port a library around simply because of how they break up concerns.

<b>aaron:</b> VMS (Telegram): I have some experience porting Linux software over to BSD systems. Generally it’s simple and stupid stuff like extended commandline flags that need to be retargeted or rewritten. Every now and then there’s something that was written against a Linux kernel interface or driver, and that’s just a painful experience. You’re almost writing new software at that point, not porting.

I want have few dependences

aaron: Why?

I don't like dependendences

Dependences*

aaron: Why not?

Just a trauma from slackware

?

And every dependence you add will be worst to porting it

<b>aaron:</b> This is why normal people use package managers.

Well, package managers with dependency resolution

<b>aaron:</b> You want to use smart dependencies then. Make sure they’re already in pkgsrc before you pick them. Check a few other platforms, like Ubuntu and Redhat.

Slackware has a package manager, just won't track deps for you

<b>aaron:</b> You want to use smart dependencies then. Make sure they’re already in pkgsrc before you pick them. Check a few other platforms, like Ubuntu and Redhat.

I will have some v

aaron: Doesn’t Slackware just have a wget wrapper?

some VM to try it

Slackware have some options and package managers

<b>aaron:</b> VMS (Telegram): Or just go to their website and search? Saves a lot of time.

I will use slackware and more linux distros to check compatibility

<b>aaron:</b> I never used Slackware because I have better things to spend my time on than a problem solved 15 years ago.

Btw slackware supports pkgsrc

And every dependence you add will be worst to porting it

Sure, but unless you want to reimplement everything and distribute as a static binary, you're going to need to make some compromises

Sure, but unless you want to reimplement everything and distribute as a static binary, you're going to need to make some compromises

Yeah

Btw slackware supports pkgsrc

I think it'd be easier to point out what systems don't support pkgsrc

I think it'd be easier to point out what systems don't support pkgsrc

Teorically pkgsrc supports "all" linux distros or most of them

But seems it worked on slackware one time

<b>aaron:</b> You have to work hard to not support pkgsrc. The requirements are basically a C compiler and some basic binutils implementation.

<b>aaron:</b> As long as you don’t have a lisp machine in your basement, or some other mainframe/embedded system, pkgsrc should run just fine.

When i've discovered pkgsrc i've thought it's the best package manager i've seen. I want take a better overview of pkgsrc and i want try installing it on linux and see how works. And make a package and install it with pkgsrc

I've seen pkgsrc makes some tests while instsll

Installing a package and if tests fails the package can't install himself

<b>aaron:</b> It works about the same as it does on NetBSD, except you don’t have access to all the work the distro did to patch and optimize the software.

You know what tests mean?

<b>aaron:</b> Yea. Almost every package manager does that.

XD i was thinking it was a special feature from pkgsrc

<b>aaron:</b> Pkgsrc/NetBSD don’t have a monopoly on being sensible.

Btw i was

Talking about pkgsrc and some people sa

Said me it's insecure use it if it's using a ftp repo

I said i think pkgsrc is not insecure and less if it's just for using ftp

But are they right?