Hacker News Reader

>there are certain desktop things I don't enjoy messing with at all

One of the advantages of NixOS model.

   hardware.pulseaudio.enable = true;
   hardware.bluetooth.enable = true;
   services.blueman.enable = true; #for systray applet

They work fine and are wm/de independent. As for displays, I simply use `arandr`. Can even save/apply layouts for specific setups.

I'm not saying you're lying (I'm sure you're not), but... colour me skeptical. This sounds too good to be true.

Can you explain how audio and bluetooth works independently of the desktop session? Does it need custom support compiled in to every window manager?

If it's so easy to do it independently of the desktop session, why does Ubuntu etc. make it dependent on the desktop session? I had assumed that it was something like the desktop session needing to set up environment variables so that all your applications knew how to talk to PulseAudio.

From the documentation on the PulseAudio module (the nix term for those 'enable = true' things) [1]:

> Explicit PulseAudio support in applications

> Normally, the system-wide ALSA configuration (/etc/asound.conf) redirects the audio of applications which use the ALSA API through PulseAudio. For this reason, most applications do not need to be PulseAudio-aware. Some NixOS packages can be built with explicit PulseAudio support which is disabled by default. This support can be enabled in all applicable packages by setting:

> nixpkgs.config.pulseaudio = true;

[1] - https://nixos.wiki/wiki/PulseAudio

I can't answer your questions about why Ubuntu ties sound to desktop session, but i can say audio and bluetooth in NixOS has been that trivially easy and worked on 8 different machines of mine and friends without issue.

> If it's so easy

Note that the parent is only changing a config option; there may be all sorts of logic behind the scenes which branch on that value, e.g. to splice different text into /etc files, to add compile flags to package builds, etc. ;)

From starting up the session on the login manager to the final state of it there're various intermediate steps. Full desktop environments (GNOME and KDE) will load everything needed for you whereas when running a window manager alone you've to do it yourself. Those Nix options set up things (essentially abstracting what you'll have done manually) in some previous step (before starting the window manager).

>why does Ubuntu etc. make it dependent on the desktop session

Because what if you didn't want them? Non-Nix systems don't have this centralized configuration model therefore they cannot provide this flexibility. Therefore they just let each session to load what it needs.

I really like NixOS (I just barely distro-hopped away from NixOS back to Arch). One reason I switched away is because similar to my i3 setup I would find myself tweaking my actual desktop/system more than getting work done. Mostly because I haven't sat down for a few hours to become more familiar with Nix's declarative language -- but I kind of don't Nix's language and think it is far from intuitive for me.

For reference, here's my nixpkgs repo (galaxy-chromebook is my most recent config): https://github.com/heywoodlh/nixpkgs

Maybe Regolith [1] is something for you. It's an Ubuntu derivative that combines i3 and Gnome. It has sane defaults, a nice app launcher, and everything 'just works': audio, bluetooth, wifi.

I have been using Regolith for half a year now, after 10 years of endless tweaking of XMonad and Gnome under Ubuntu.

[1] https://regolith-desktop.com/

I am a very happy Arch (and sometimes NixOS) user but I am thrilled to know that Regolith leverages GNOME and i3 (I knew about Regolith using i3 but I didn't know it combined that with GNOME).

Gets me interested in getting my build setup like that!

Theres also the Fedora-i3 spin. Not nearly as plug-and-play as Regolith though, just thought I'd mention it.

I'm on Manjaro-i3-minimal from Mint+i3. Manjaro (Arch-based) seems so far a very good match. Minimal tweaking as most defaults are sane and looks good.

Most of the time was spent just to familiarize with Arch and find packages, which will pay off later.

Regular Manjaro seems newbie friendly as well.

I feel like Manjaro strikes a good balance at providing all the benefits of an Arch-based system without the downsides of stock Arch. For example, Arch's super newbie-unfriendly install process. Hopefully the archinstall script[1] now included in the official Arch ISO eventually becomes a more mainstream method of installing Arch -- but still allows for users like me to do the by-hand installation when I need custom/more flexible configuration.

I would say if someone is curious to give Arch a try but doesn't want to go through the installation process that they should give archinstall a try! In my opinion, the preset profiles (for GNOME, KDE, etc.) really removes a bunch of friction to using Arch if you are a new user or just want to save yourself time.

(I would imagine my views don't reflect the majority of the Arch community as it often seems like deliberate steps are taken to keep Arch as a gated community to those who are elite enough to invest in Arch 100%)

[1] https://wiki.archlinux.org/title/Archinstall

I get Arch. The docs are spot on. It's very polished and you can actually learn quite a bit.

However, for work, I need something not bleeding edge, and hope Manjaros tests and security test, will help in that regard. That it's a positive thing they wait about 2 weeks.

I had to tweak Manjaro a little, but so much worked out of the box. Don't have that dedicated time for ricing, though default installs in Arch seems very sanely configured.

Totally agreed with all these points.

It's interesting (to me at least) because I have ended up using Arch for all my personal servers and workstations and it has been pretty rock solid! Although, I typically use containers for running all the applications I care about -- which might lend to the stability I have seen with my systems.

I found a lot of stuff became simpler when I switched to FreeBSD. Audio is still OSS, same way it's been for ~30 years. Displays are still X11. Networking is still ifconfig. Admittedly I didn't touch bluetooth, but I'd trust them to get something similarly plain and simple going.

The two blockers I've had with FreeBSD as a workstation:

- huge lack of basic hardware support for things like wifi (or bluetooth) chipsets

- lack of Docker support (I'm one of those that uses Docker as my universal CLI package manager)

Aside from these things, I absolutely love the mentality and philosophies behind FreeBSD and would love to have a FreeBSD workstation!

I can't imagine going back to a desktop after using a tiling manager ...

99% of the time, you just need full screen windows, on dual screens (or even triple screens!), with (OF COURSE) virtual desktops.

Yeah, for me, I find the only parts I care about with a tiling window manager is a minimal looking environment and windows that organize themselves automatically. On GNOME I am able to get all the same workflows and benefits that I care about from a tiling window manager while not worrying about having to tweak something on my work machine when I'm on a Zoom call working on an issue.

Audio is fixed by just using pipewire.

Displays is fixed by using Wayland (sway).

Bluetooth is indeed an unsolved problem. I suppose the skilled hacker types have just declared the whole protocol as broken and use wires.

Pipewire “solves”, or at least improves the bluetooth landscape quite a bit.

Do I read parent as saying that these things are best managed through GUI widgets attached to the desktop environment

> Do I read parent as saying that these things are best managed through GUI widgets attached to the desktop environment

100% you are reading my original comment correctly. An example I ran into recently: I start up bluetoothctl, I power on the adapter, start scanning for Blueooth devices and am spammed by a bluetooth device nearby to the point where I can't see the one I am trying to pair to (even after turning off scanning). In contrast, blueman-applet or GNOME's control-center neatly organizes each unique Bluetooth device as individual icons and makes it easy to see each of those. Lots of little papercuts like that can make it frustrating when you're just trying to get work done.

This is also true things like displays -- sure I could take 20 minutes write a script to rearrange my displays the way I prefer -- or I could just open GNOME's control center and take two minutes using the display setting.

There are lots of little things like this that can get in the way when you just need to get something done.

And this is totally subjective to my experience, my opinion and what I currently value so please don't take this like I am saying everyone should prioritize things the way I do. For those more comfortable in i3 or something else -- great! :)

Perhaps my tolerance is just too high again, if my 2nd display is on the wrong side, I just move my mouse cursor via the other direction. It doesn't seem to cause any friction for me.

What would cause friction is if the display plain didn't work, or had bad aspect ratio or fonts. Wayland (in combination with kernel graphics probably) seems to have fixed those problems.

> Audio is fixed by just using pipewire.

My experience with Pipewire has definitely been excellent.

> Displays is fixed by using Wayland (sway).

I still have some tooling that requires X11 -- but whenever I've used Wayland I feel like there is still a lot that relies on X11. For me, Rofi is one of those tools that I just haven't been able to totally replace in Wayland (even with the Wayland forks of Rofi). Some other day-to-day examples are Zoom[1] and Nvidia graphics cards[2]. While I am aware that these are third parties lagging behind Wayland support and not really an issue with Wayland itself, it still demonstrates how everything is not magically "just fixed" simply because you are on Wayland.

[1] https://support.zoom.us/hc/en-us/articles/6634039380877-Shar...

[2] https://forums.developer.nvidia.com/t/wayland-information-fo...

VcXsrv + WSL2 means I don't have to care about any of this.

Though note I basically only use Windows as a fat driver layer unless I'm playing games (Wintendo!)

Random anecdote: I use Docker as my universal package manager for a large majority of my tools/workflows. I was so pleased when the Docker + WSL2 integration was released as it made all of my Docker workflows on Linux/MacOS + a POSIX shell (BASH, ZSH, etc.) totally functional on Windows. I'm a big fan of WSL2.

> unless I'm playing games

This is one area I've not been able to completely ditch Windows. Valve is doing some great work to get Windows games running on Linux in Steam but I find myself playing a bunch of games that are not in Steam with an anti-cheat engine that sucks in Proton. I hope more external game launchers/stores and anti cheat engines are motivated by Valve to implement Linux (or emulated) support.

I love being a linux/BSD server admin.

I totally cannot be arsed being a desktop admin for either.

So I use WSL2+Xsrv to give me my -client- environment on windows and then use that to ssh into servers to actually do stuff.

Meanwhile, windows acts as a fat driver layer that provides firefox and my X11 setup and easy access to games.

I am in no way recommending this. But it works for me.

I sometimes use Sway. My approach to Bluetooth was always to use bluetoothctl in a terminal. Then I saw there was an Emacs interface to bluetoothctl and I started using that. A system tray applet for bluetooth would be better (by analogy to nm-applet), but I don't know of one that is currently maintained and working.

Add the following lines to your sway config. It works for me when using Waybar.

exec_always --no-startup-id blueman-applet

exec_always --no-startup-id nm-applet --indicator

Ah, blueman wasn't in my distro's repositories for the longest time, which led me to believe it was unmaintained. Apparently it was incompatible for a while, but that's now been fixed.

I had the same problem as you. You should look into Manjaro's i3 edition. It's not perfect but it's serviceable.

I use both Sway and GNOME, and have tried various tiling window extensions for GNOME. I absolutely agree with you that the Pop! OS shell extension is a good balance. I also think it's an excellent introduction to tiling window managers for people who might otherwise be afraid to try them.

Absolutely agreed!

The thing I care about that a tiling window manager brings me is a way to automatically organize your windows in a minimal looking environment. The way I set up GNOME I am able to achieve that.