D
Deleted member
Guest
Edit to add tl;dr:
I solved an audio problem, but perhaps my solution is not the best way. Advice about sound servers or in general about how to manage customizations to ports would be welcome.
The rest of this is just observations and thoughts.
------
Hello, all.
BSD Newb. First time poster.
Forgive me for the generality of this post/question -- I suppose the gist of what I'm about to ask is, given the tinkering and troubleshooting that I've done so far, what very dumb things have I done that a more seasoned BSDer would do differently? I don't want to bring in bad habits that I adopted from using other systems.
I am a long-time Linux user -- about 17 years -- using linux at home and professionally. Professional certifications, all that. For a brief time, in 2006 or 2007 I was managing a few hundred Solaris 9 workstations and servers. I think I tried running BSD at home sometime around then when ZFS opened up, and to be honest my estimation of BSD at that time was it had all the difficult parts of Solaris, but I thought that zones were not as easy to use as Solaris zones. And I was new to the tech industry in general -- there are good things about BSD that I wasn't able to recognize until some years later. Another time, I briefly considered learning BSD deeply was around 2012-ish when I learned of rump kernels at a conference, but I never made the switch to BSD in my daily life. I know comparing BSD to other operating systems is a sin, so I'll try not to do so here -- but that's my frame of reference as I muddle through everything.
The goal is to use FreeBSD as a desktop "daily driver". I know this isn't the sexiest use case, but I think it's a good way to learn by doing, and I'm here to learn. I've been using it mostly exclusively for a few weeks so far and I've gotten it to a usable state, with a few changes to my behavior when I couldn't get things to work the way I expected. The only difficulties I'm seeing are relevant to using FreeBSD as a desktop, but I can immediately see that it would not be a problem in another context, and I would absolutely select BSD in the future for individually-managed servers. The desktop problems...are also not that bad. Again, I'm just curious what other people think of my methods and the way I've gone about things.
The installation:
I did not attempt anything fancy here, and the installation is easy as can be. I was happy to learn later that bsdinstall is still installed and can be used for setting up jails. I haven't tried doing any NFS installations, or dual-booting, but it does what it says on the tin. I did end up installing twice because I wanted to change the disk encryption scheme, and I did not know how to change it after install. Later, I ended up wanting to "start over" to make different decisions and I was happy about the separation of ports vs base install, so my "start over" procedure was pretty easy.
wow:
looking at /usr/src/sys is very educational. It's all very readable. Most of the source is concise, and I will definitely want to spend some more time in here.
Surprises about the "base install":
I have no idea why some things are part of the base and not others. NFS is historically implemented as a kernel filesystem driver, so it makes sense to me to include this in the base install. But OpenSSH and unbound -- these are just servers that run in userspace. If you are going to include those, why not then include httpd, or tftpd or any of the other popular server daemons as well? I mean, I would have installed these things immediately anyway, so I'm not complaining, but it seems to me like it's opinionated in a way that doesn't make much sense.
Speaking only of the base system, it would lead you to nonsensical conclusions -- "FreeBSD-13 supports caching DNS queries, but it doesn't support name resolution with RFC 6763/ZeroConf" -- well, that's not exactly true, is it? Becasue you could install ZeroConf support by installing additional packages, but the team that manages the base has a preference for supporting one name resolution strategy and not the other. It just seems odd to me, and clearly there is preferential support for non-desktop-oriented use cases. The end result is *part* of what I would have wanted anyway, so I have no real complaints just a "hmm..seems odd"
Some concepts, to me, seem like they are not completely implemented. The "base install" separate from /usr/local idea is a good one. This would enable you to, for example, install a bunch of ports on an NFS mount or on a separate disk/partition, and then the OS is replaceable/disposable. You'd be able to re-install the "base system" and all the third-party software and configuration is still there. Amazing. Except this is not exactly true. It seems to me like it's nearly true, but the implementation is incomplete. On my system, for example, I needed to install a video driver port, but to use the driver, I need to edit config files on the "base install". I noticed later that you can include configuration in /etc/rc.conf.local -- and this seems like a good file to keep in source control, but I am surprised that the local file is not /usr/local/etc/rc.conf. If /usr/local/etc/rc.conf were sourced instead, this would enable users to re-install base and avoid having to re-configure the system. For that matter, why is there no /usr/local/etc/fstab, etc? I could imagine the "base install" being mounted read-only, or even just a single cpio archive if the idea was pushed further. My thinking here is definitely influenced from heavy docker usage -- it would be cool if the base system was immutable with a configuration layer on top. It seems like that's the idea, but it just doesn't go the whole way.
I haven't run into a problem yet, but my current thinking is that there are critical files in the base system that I'll want to keep backed up. If I do need to re-install, the procedure post-install will be to restore these critical files from backup and then re-mount /usr/local.
There is actually just one thing that really tripped me up, and that was the sound. To fix the sound, I had to make changes I did not expect to make, and I think the fix actions I took actually made the process of maintaining BSD much harder. So really, I'm wondering what other people do about the sound.
There are loads of articles and posts on this forum about sound on FreeBSD, and I have read a good deal of them. It seems like people are really opinionated on the matter and quite defensive of their opinions. This forum post has my favorite exchange https://forums.freebsd.org/threads/using-sndio-in-place-of-pulseaudio.60829/page-2. The base install includes support for OSS, which is a fine, albeit basic audio system. For me, the sound did not work out of the box, but I learned quickly how to configure the right sysutils to fix the default sound device. I think OSS a perfectly fine abstraction to leave in the base install. It's simple to use, simple to write programs around. It's fine. I only noticed the problem when I tried to plug in a webcam with a built-in microphone and listen through wired headphones on the front of the PC -- this does not work well on OSS because two audio devices are required at the same time..... I know I know, it would be theoretically possible for something to work this way. Obviously, nothing prevents software from being written to use OSS ioctls on multiple sound devices simultaneously -- but existing using multimedia conferencing software in popular web browsers -- I could not make this work.
From a linux world, know there are sound servers (popularly, pulseaudio) that can handle mixing and sampling, etc. And when I researched this for BSD I discovered sndio. I decided to give sndio a try. However, not everything has sndio support compiled in, so I decided to start building software from ports, using 'portupgrade' (don't worry, I didn't use portupgrade for long. noob, remember?) and I was re-building everything I found that supported sndio so the sndio option was enabled. Then, I'm sorry that I can't explain exactly what happened, but suddenly my nvidia driver stopped working. I am sorry, I have no detail about what exactly happened, but I think I somehow broke linux emulation support while I was building things from source, and the nvidia driver would fail to load. No worries -- time to rethink my strategy.
While I was looking at make options, I learned some things. sndio support is not ubiquitous! I found more applications that had pulseaudio support than sndio, and I decided -- I know it's not the most BSD-ish configuration, but if I'm going to build everything from souce anyway, I'll just use the sound server I'm already familiar with. So this time, I installed "poudriere" and I created a list of the applications I wanted built with pulseaudio support. It takes about 16 hours to build chromium from source, by the way, but after this, it works. I can finally listen and speak in meetings simultaneously!
While I'm at it, there are some other things that just bugged me, and I fixed those by compiling from source. vim doesn't use the double-buffer to reset the terminal by default? Bah! What are we, cave men? But now that I'm committed to building everything myself, I can fix that on my end at least.
By the way, poudriere is a masterpiece. If I was managing a whole fleet of BSD servers with custom packages, this would make my life much easier.
okay okay okay. So I have some questions and some thoughts. The gist is that it would be cool if I could somehow select packages with a different configuration than what selected by default.
One solution I can think of is to make better use of flavors. The ports system has a concept called "flavors" wherein some packages have multiple variants. But this is not used everywhere, and I do not know why. I could totally imagine there being "oss", "sndio", "pulseaudio" and "pipewire" flavors of any software that has audio, but this is sadly missing. Hypothetically, I suppose you could have a "flavor" file somewhere that indicates preferences that should be selected when there are multiple available. I imagine this would be a config file read by pkg that would say when there are multiple variants, pick this one or that one.. The concept of flavors could extend to server software as well. I could imagine, for example, SSL implementation being a "flavor" so packages could be provided as GnuTLS or OpenSSL flavors depending on what the user has selected. I'm not a port maintainer, and I have no idea if an idea like this seems even remotely feasible.
The other solution I can think of is optional dependencies. Packages could be built with support for OSS, pulseaudio, sndio, and pipewire without including those applications as a dependency. Instead, the user can install one of them if they want to and support will already be there.
Anyway, as a new BSD-er, I hope to stay a while. Was my audio problem solved the right way? Can my decision to use Pottering on BSD be forgiven? Any advice is welcome and will be taken kindly.
I solved an audio problem, but perhaps my solution is not the best way. Advice about sound servers or in general about how to manage customizations to ports would be welcome.
The rest of this is just observations and thoughts.
------
Hello, all.
BSD Newb. First time poster.
Forgive me for the generality of this post/question -- I suppose the gist of what I'm about to ask is, given the tinkering and troubleshooting that I've done so far, what very dumb things have I done that a more seasoned BSDer would do differently? I don't want to bring in bad habits that I adopted from using other systems.
I am a long-time Linux user -- about 17 years -- using linux at home and professionally. Professional certifications, all that. For a brief time, in 2006 or 2007 I was managing a few hundred Solaris 9 workstations and servers. I think I tried running BSD at home sometime around then when ZFS opened up, and to be honest my estimation of BSD at that time was it had all the difficult parts of Solaris, but I thought that zones were not as easy to use as Solaris zones. And I was new to the tech industry in general -- there are good things about BSD that I wasn't able to recognize until some years later. Another time, I briefly considered learning BSD deeply was around 2012-ish when I learned of rump kernels at a conference, but I never made the switch to BSD in my daily life. I know comparing BSD to other operating systems is a sin, so I'll try not to do so here -- but that's my frame of reference as I muddle through everything.
The goal is to use FreeBSD as a desktop "daily driver". I know this isn't the sexiest use case, but I think it's a good way to learn by doing, and I'm here to learn. I've been using it mostly exclusively for a few weeks so far and I've gotten it to a usable state, with a few changes to my behavior when I couldn't get things to work the way I expected. The only difficulties I'm seeing are relevant to using FreeBSD as a desktop, but I can immediately see that it would not be a problem in another context, and I would absolutely select BSD in the future for individually-managed servers. The desktop problems...are also not that bad. Again, I'm just curious what other people think of my methods and the way I've gone about things.
The installation:
I did not attempt anything fancy here, and the installation is easy as can be. I was happy to learn later that bsdinstall is still installed and can be used for setting up jails. I haven't tried doing any NFS installations, or dual-booting, but it does what it says on the tin. I did end up installing twice because I wanted to change the disk encryption scheme, and I did not know how to change it after install. Later, I ended up wanting to "start over" to make different decisions and I was happy about the separation of ports vs base install, so my "start over" procedure was pretty easy.
wow:
looking at /usr/src/sys is very educational. It's all very readable. Most of the source is concise, and I will definitely want to spend some more time in here.
Surprises about the "base install":
I have no idea why some things are part of the base and not others. NFS is historically implemented as a kernel filesystem driver, so it makes sense to me to include this in the base install. But OpenSSH and unbound -- these are just servers that run in userspace. If you are going to include those, why not then include httpd, or tftpd or any of the other popular server daemons as well? I mean, I would have installed these things immediately anyway, so I'm not complaining, but it seems to me like it's opinionated in a way that doesn't make much sense.
Speaking only of the base system, it would lead you to nonsensical conclusions -- "FreeBSD-13 supports caching DNS queries, but it doesn't support name resolution with RFC 6763/ZeroConf" -- well, that's not exactly true, is it? Becasue you could install ZeroConf support by installing additional packages, but the team that manages the base has a preference for supporting one name resolution strategy and not the other. It just seems odd to me, and clearly there is preferential support for non-desktop-oriented use cases. The end result is *part* of what I would have wanted anyway, so I have no real complaints just a "hmm..seems odd"
Some concepts, to me, seem like they are not completely implemented. The "base install" separate from /usr/local idea is a good one. This would enable you to, for example, install a bunch of ports on an NFS mount or on a separate disk/partition, and then the OS is replaceable/disposable. You'd be able to re-install the "base system" and all the third-party software and configuration is still there. Amazing. Except this is not exactly true. It seems to me like it's nearly true, but the implementation is incomplete. On my system, for example, I needed to install a video driver port, but to use the driver, I need to edit config files on the "base install". I noticed later that you can include configuration in /etc/rc.conf.local -- and this seems like a good file to keep in source control, but I am surprised that the local file is not /usr/local/etc/rc.conf. If /usr/local/etc/rc.conf were sourced instead, this would enable users to re-install base and avoid having to re-configure the system. For that matter, why is there no /usr/local/etc/fstab, etc? I could imagine the "base install" being mounted read-only, or even just a single cpio archive if the idea was pushed further. My thinking here is definitely influenced from heavy docker usage -- it would be cool if the base system was immutable with a configuration layer on top. It seems like that's the idea, but it just doesn't go the whole way.
I haven't run into a problem yet, but my current thinking is that there are critical files in the base system that I'll want to keep backed up. If I do need to re-install, the procedure post-install will be to restore these critical files from backup and then re-mount /usr/local.
There is actually just one thing that really tripped me up, and that was the sound. To fix the sound, I had to make changes I did not expect to make, and I think the fix actions I took actually made the process of maintaining BSD much harder. So really, I'm wondering what other people do about the sound.
There are loads of articles and posts on this forum about sound on FreeBSD, and I have read a good deal of them. It seems like people are really opinionated on the matter and quite defensive of their opinions. This forum post has my favorite exchange https://forums.freebsd.org/threads/using-sndio-in-place-of-pulseaudio.60829/page-2. The base install includes support for OSS, which is a fine, albeit basic audio system. For me, the sound did not work out of the box, but I learned quickly how to configure the right sysutils to fix the default sound device. I think OSS a perfectly fine abstraction to leave in the base install. It's simple to use, simple to write programs around. It's fine. I only noticed the problem when I tried to plug in a webcam with a built-in microphone and listen through wired headphones on the front of the PC -- this does not work well on OSS because two audio devices are required at the same time..... I know I know, it would be theoretically possible for something to work this way. Obviously, nothing prevents software from being written to use OSS ioctls on multiple sound devices simultaneously -- but existing using multimedia conferencing software in popular web browsers -- I could not make this work.
From a linux world, know there are sound servers (popularly, pulseaudio) that can handle mixing and sampling, etc. And when I researched this for BSD I discovered sndio. I decided to give sndio a try. However, not everything has sndio support compiled in, so I decided to start building software from ports, using 'portupgrade' (don't worry, I didn't use portupgrade for long. noob, remember?) and I was re-building everything I found that supported sndio so the sndio option was enabled. Then, I'm sorry that I can't explain exactly what happened, but suddenly my nvidia driver stopped working. I am sorry, I have no detail about what exactly happened, but I think I somehow broke linux emulation support while I was building things from source, and the nvidia driver would fail to load. No worries -- time to rethink my strategy.
While I was looking at make options, I learned some things. sndio support is not ubiquitous! I found more applications that had pulseaudio support than sndio, and I decided -- I know it's not the most BSD-ish configuration, but if I'm going to build everything from souce anyway, I'll just use the sound server I'm already familiar with. So this time, I installed "poudriere" and I created a list of the applications I wanted built with pulseaudio support. It takes about 16 hours to build chromium from source, by the way, but after this, it works. I can finally listen and speak in meetings simultaneously!
While I'm at it, there are some other things that just bugged me, and I fixed those by compiling from source. vim doesn't use the double-buffer to reset the terminal by default? Bah! What are we, cave men? But now that I'm committed to building everything myself, I can fix that on my end at least.
By the way, poudriere is a masterpiece. If I was managing a whole fleet of BSD servers with custom packages, this would make my life much easier.
okay okay okay. So I have some questions and some thoughts. The gist is that it would be cool if I could somehow select packages with a different configuration than what selected by default.
One solution I can think of is to make better use of flavors. The ports system has a concept called "flavors" wherein some packages have multiple variants. But this is not used everywhere, and I do not know why. I could totally imagine there being "oss", "sndio", "pulseaudio" and "pipewire" flavors of any software that has audio, but this is sadly missing. Hypothetically, I suppose you could have a "flavor" file somewhere that indicates preferences that should be selected when there are multiple available. I imagine this would be a config file read by pkg that would say when there are multiple variants, pick this one or that one.. The concept of flavors could extend to server software as well. I could imagine, for example, SSL implementation being a "flavor" so packages could be provided as GnuTLS or OpenSSL flavors depending on what the user has selected. I'm not a port maintainer, and I have no idea if an idea like this seems even remotely feasible.
The other solution I can think of is optional dependencies. Packages could be built with support for OSS, pulseaudio, sndio, and pipewire without including those applications as a dependency. Instead, the user can install one of them if they want to and support will already be there.
Anyway, as a new BSD-er, I hope to stay a while. Was my audio problem solved the right way? Can my decision to use Pottering on BSD be forgiven? Any advice is welcome and will be taken kindly.
