Great, with Version 1.3.0, Ly display manager introduced a brightness feature, where you can increase or decrease brightness.
-
This doesn't bother me too much. Ideally the program should hide the buttons if it can't find a brightnessctl to execute (and probably should fix the search path, because there may be privilege escalation attacks if you can make a login manager run a program that you can control before it drops privileges). A FreeBSD port can provide this program (which probably can just be a shell script that reads / sets a
sysctl).At least this has a form of abstraction layer, in that it delegates to another program to provide the OS-specific functionality. It would be much worse if it just used the Linux kernel APIs to do it.
@david_chisnall I agree. In this case, it doesn't bother me too much, but I have got the feeling that it only shows a general trend, where everything is more and more tailored towards Linux and the BSDs are ignored. We see this particularly with certain desktop environments.
In this case, it's easy to handle, but from a simple and lightweight display manager like Ly, I would expect that it just works and uses no OS-specific functionalities.
-
Great, with Version 1.3.0, Ly display manager introduced a brightness feature, where you can increase or decrease brightness. I never felt the urge to change the brightness of my black login screen with green text, but now it's there.... Pressed F5, nothing happened but a message appeared "failed to change brightness".
It seems that Ly tries to use brightnessctl to adjust display brightness, which is not available on FreeBSD.
I really liked Ly because it's a simple and easy to use display manager with a minimalistic approach, but I have the feeling that more and more open source software is being developed with a focus on Linux, leaving other systems out in the cold.
@NebulaTide It doesn't solve the underlying ecosystem issue; but if you really wanted to use Ly - you could write a tiny shell script called brighnessctl that provided the correct compatibility backend.
For fun, I asked Claude Code to take a stab at a script: https://gist.github.com/tstromberg/1e097edb2dbab3e8464b5908192e601d - it's overengineered AI slop - you can make a far simpler version with a single backend.
In the long run, the community is probably better off with contributing FreeBSD support to brightnessctl, though.
-
Great, with Version 1.3.0, Ly display manager introduced a brightness feature, where you can increase or decrease brightness. I never felt the urge to change the brightness of my black login screen with green text, but now it's there.... Pressed F5, nothing happened but a message appeared "failed to change brightness".
It seems that Ly tries to use brightnessctl to adjust display brightness, which is not available on FreeBSD.
I really liked Ly because it's a simple and easy to use display manager with a minimalistic approach, but I have the feeling that more and more open source software is being developed with a focus on Linux, leaving other systems out in the cold.
@NebulaTide it seems you are left in the dark in that case
(don't look for me, I already ran away with my shame)
-
Great, with Version 1.3.0, Ly display manager introduced a brightness feature, where you can increase or decrease brightness. I never felt the urge to change the brightness of my black login screen with green text, but now it's there.... Pressed F5, nothing happened but a message appeared "failed to change brightness".
It seems that Ly tries to use brightnessctl to adjust display brightness, which is not available on FreeBSD.
I really liked Ly because it's a simple and easy to use display manager with a minimalistic approach, but I have the feeling that more and more open source software is being developed with a focus on Linux, leaving other systems out in the cold.
@NebulaTide That sort of thing has been going on since forever, and is IMO fine. As long as thé project is happy to accept and maintain portability patches.
Ripping out support for non-Linux OSes is where things go wrong
-
Great, with Version 1.3.0, Ly display manager introduced a brightness feature, where you can increase or decrease brightness. I never felt the urge to change the brightness of my black login screen with green text, but now it's there.... Pressed F5, nothing happened but a message appeared "failed to change brightness".
It seems that Ly tries to use brightnessctl to adjust display brightness, which is not available on FreeBSD.
I really liked Ly because it's a simple and easy to use display manager with a minimalistic approach, but I have the feeling that more and more open source software is being developed with a focus on Linux, leaving other systems out in the cold.
@NebulaTide The config seems to suggest that it use this commands:
# Brightness decrease command
brightness_down_cmd = /usr/bin/backlight - 10# Brightness decrease key, or null to disable
brightness_down_key = F5# Brightness increase command
brightness_down_cmd = /usr/bin/backlight + 10Which is the correct command.
-
@NebulaTide That sort of thing has been going on since forever, and is IMO fine. As long as thé project is happy to accept and maintain portability patches.
Ripping out support for non-Linux OSes is where things go wrong
@tfb Unfortunately this is something that we see more and more often. Not in this case, but when it comes to desktop environments. When it becomes impossible to run a certain desktop environment on *BSD because it requires systemd, this DE is useless on BSD.
-
@tfb Unfortunately this is something that we see more and more often. Not in this case, but when it comes to desktop environments. When it becomes impossible to run a certain desktop environment on *BSD because it requires systemd, this DE is useless on BSD.
@NebulaTide Yeah, definitely. The hostility towards portability from some corners is very upsetting; I haven't seen anything like that since trying to send Minix-compatibility patches to projects in the late 1990's. I'm quite concerned that my preferred DE isn't very kool anymore.
I also think it's important to remember that of course most projects will have inconsequential Linux-isms in them, the same way so many had commercial unix-isms in them in the 90's. And as long as the reaction to BSD or illumos patches is "cool, thanks!" those are the good ones, and we should encourage them
-
@NebulaTide Yeah, definitely. The hostility towards portability from some corners is very upsetting; I haven't seen anything like that since trying to send Minix-compatibility patches to projects in the late 1990's. I'm quite concerned that my preferred DE isn't very kool anymore.
I also think it's important to remember that of course most projects will have inconsequential Linux-isms in them, the same way so many had commercial unix-isms in them in the 90's. And as long as the reaction to BSD or illumos patches is "cool, thanks!" those are the good ones, and we should encourage them
@NebulaTide also also, make some noise if you send them a FreeBSD patch, I'll do the same for NetBSD. The sysctl incantations are slightly different
-
@NebulaTide The config seems to suggest that it use this commands:
# Brightness decrease command
brightness_down_cmd = /usr/bin/backlight - 10# Brightness decrease key, or null to disable
brightness_down_key = F5# Brightness increase command
brightness_down_cmd = /usr/bin/backlight + 10Which is the correct command.
@monwarez Actually it was easy to fix and no evil intention by the developers of Ly. It seemed to be a backlight issue on my system. So in this case I was wrong, but this doesn't change the fact that development becomes more and more Linux-centric.
-
@monwarez Actually it was easy to fix and no evil intention by the developers of Ly. It seemed to be a backlight issue on my system. So in this case I was wrong, but this doesn't change the fact that development becomes more and more Linux-centric.
@NebulaTide I don't think it is, they seems to care about FreeBSD by looking at the Readme, repo description and also some design choice like not forcing XDG_RUNTIME_DIR to use Linux specific path.
-
@david_chisnall I agree. In this case, it doesn't bother me too much, but I have got the feeling that it only shows a general trend, where everything is more and more tailored towards Linux and the BSDs are ignored. We see this particularly with certain desktop environments.
In this case, it's easy to handle, but from a simple and lightweight display manager like Ly, I would expect that it just works and uses no OS-specific functionalities.
@NebulaTide @david_chisnall What are BSDs doing with the non-portable XDG_CONFIG_HOME (.config/)? (Which is also backwards-incompatible, yay - funny thing that it'd all be avoidable if only subdirectories and files were required to still start with a "."?)
-
R ActivityRelay shared this topic
