SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Like in, ME: let's add some great value to Slackware, while YOU follows with: then let's chop off some another great value from Slackware.
That's not "great value" in my opinion. That's "needless work". (Cf. https://www.plutora.com/blog/feature-creep-problem ) As long as both KDE and GNOME are not required for most of other software, they should be considered "software that a user can install at their own pleasure".
Or, quoting the Revised^7 Report on Scheme:
Code:
Programming languages should be designed not by piling feature on
top of feature, but by removing the weaknesses and restrictions that
make additional features appear necessary. — Revised 7 Report on
the Algorithmic Language Scheme, Introduction.
it is the same thing for Operating Systems. Not piling up a DE on top of a DE, but providing the necessary libraries and hooks that would enable the user to _easily_ install any and all DE they wish.
Quote:
Originally Posted by LuckyCyborg
So, because I proposed adding GNOME4 to Slackware, you propose the removal of Plasma5?
What the heck is the connection between Plasma5 and GNOME4 in your enlighten mind? Oh, well...
Both are not required for a full-featured operating system. Both are very polarizing in terms of user affiliation. Both require an enormous amount of work, and both have userbases large enough to bear the burden of maintaining them without spending Mr. Volkerding's effort.
Having _one_ GTK+ DE (xfce) for the purpose of ensuring the consistency of base libraries, and _one_ Qt DE (I would prefer LXQt), for the same purpose, make sense to me. But having _two_ is certainly not required, and KDE, while it serves the purpose of testing consistency with the rest of the Qt ecosystem, still has too much not-strictly-necessary low-quality components, in my opinion.
Again, I don't suggest "removing Qt-based DE entirely". I suggest replacing a bloated DE with a fairly moderate one, with an option to enable the big one easily (via SBo).
* dhcp: revert restarting DHCP when MAC address changes,
for example during a bond fail over.
* various documentation fixes.
* fix non-exported ABI in libnm which was wrongly present
in the header files but unusable so far.
* ifcfg-rh: fix writing ethtool pause settings to file.
* core: set "proto static" for manual routing rules configured
by NetworkManager.
* Various minor bugfixes.
I would actually like to ask for something, but I do not actually know how to implement it efficiently, so maybe someone could propose a better solution than I have.
I want to have a hook for scripts running before hibernation and after wakeup.
(And perhaps, before and after suspend.)
At the moment I have an improvised solution, which works like this:
Code:
#!/usr/bin/python3
# Time-stamp: <2021-09-09 22:42:29 lockywolf>
# https://askubuntu.com/questions/183516/how-do-i-detect-when-my-system-wakes-up-from-suspend-via-dbus-or-similar-in-a-py
# slightly different code for handling suspend resume
# using login1 interface signals
#
import dbus # for dbus communication (obviously)
from gi.repository import GObject as gobject # main loop
from dbus.mainloop.glib import DBusGMainLoop # integration into the main loop
from gi.repository import GLib as glib
import subprocess
def handle_sleep_callback(sleeping):
if sleeping:
retval_sleep = subprocess.run( [ "/etc/rc.d/rc.pre_sleep" ] )
else:
retval_wakeup = subprocess.run( [ "/etc/rc.d/rc.post_sleep" ] )
DBusGMainLoop( set_as_default=True ) # integrate into main loop
bus = dbus.SystemBus() # connect to dbus system wide
bus.add_signal_receiver( # define the signal to listen to
handle_sleep_callback, # name of callback function
'PrepareForSleep', # signal name
'org.freedesktop.login1.Manager', # interface
'org.freedesktop.login1' # bus name
)
loop = glib.MainLoop() # define mainloop
loop.run() # run main loop
This does the job for me, but I cannot say that this is a clean solution, because python, dbus, glib, and having a resident-in-memory monitoring process is a bit of a crutch. So, any other suggestion welcome.
I am starting this python process from rc.local, and it just keeps running all the way, although, maybe an inittab entry would have been a better choice. But I think this would have made life better for laptop users, while keeping complexity at the minimal level.
I would actually like to ask for something, but I do not actually know how to implement it efficiently, so maybe someone could propose a better solution than I have.
I want to have a hook for scripts running before hibernation and after wakeup.
(And perhaps, before and after suspend.)
At the moment I have an improvised solution, which works like this:
Code:
#!/usr/bin/python3
# Time-stamp: <2021-09-09 22:42:29 lockywolf>
# https://askubuntu.com/questions/183516/how-do-i-detect-when-my-system-wakes-up-from-suspend-via-dbus-or-similar-in-a-py
# slightly different code for handling suspend resume
# using login1 interface signals
#
import dbus # for dbus communication (obviously)
from gi.repository import GObject as gobject # main loop
from dbus.mainloop.glib import DBusGMainLoop # integration into the main loop
from gi.repository import GLib as glib
import subprocess
def handle_sleep_callback(sleeping):
if sleeping:
retval_sleep = subprocess.run( [ "/etc/rc.d/rc.pre_sleep" ] )
else:
retval_wakeup = subprocess.run( [ "/etc/rc.d/rc.post_sleep" ] )
DBusGMainLoop( set_as_default=True ) # integrate into main loop
bus = dbus.SystemBus() # connect to dbus system wide
bus.add_signal_receiver( # define the signal to listen to
handle_sleep_callback, # name of callback function
'PrepareForSleep', # signal name
'org.freedesktop.login1.Manager', # interface
'org.freedesktop.login1' # bus name
)
loop = glib.MainLoop() # define mainloop
loop.run() # run main loop
This does the job for me, but I cannot say that this is a clean solution, because python, dbus, glib, and having a resident-in-memory monitoring process is a bit of a crutch. So, any other suggestion welcome.
I am starting this python process from rc.local, and it just keeps running all the way, although, maybe an inittab entry would have been a better choice. But I think this would have made life better for laptop users, while keeping complexity at the minimal level.
Hi Lockywolf
In order to allow everyone to participate to your post
What do you think to make a dedicated thread with that one?
I would actually like to ask for something, but I do not actually know how to implement it efficiently, so maybe someone could propose a better solution than I have.
I want to have a hook for scripts running before hibernation and after wakeup.
(And perhaps, before and after suspend.)
At the moment I have an improvised solution, which works like this:
Code:
#!/usr/bin/python3
# Time-stamp: <2021-09-09 22:42:29 lockywolf>
# https://askubuntu.com/questions/183516/how-do-i-detect-when-my-system-wakes-up-from-suspend-via-dbus-or-similar-in-a-py
# slightly different code for handling suspend resume
# using login1 interface signals
#
import dbus # for dbus communication (obviously)
from gi.repository import GObject as gobject # main loop
from dbus.mainloop.glib import DBusGMainLoop # integration into the main loop
from gi.repository import GLib as glib
import subprocess
def handle_sleep_callback(sleeping):
if sleeping:
retval_sleep = subprocess.run( [ "/etc/rc.d/rc.pre_sleep" ] )
else:
retval_wakeup = subprocess.run( [ "/etc/rc.d/rc.post_sleep" ] )
DBusGMainLoop( set_as_default=True ) # integrate into main loop
bus = dbus.SystemBus() # connect to dbus system wide
bus.add_signal_receiver( # define the signal to listen to
handle_sleep_callback, # name of callback function
'PrepareForSleep', # signal name
'org.freedesktop.login1.Manager', # interface
'org.freedesktop.login1' # bus name
)
loop = glib.MainLoop() # define mainloop
loop.run() # run main loop
This does the job for me, but I cannot say that this is a clean solution, because python, dbus, glib, and having a resident-in-memory monitoring process is a bit of a crutch. So, any other suggestion welcome.
I am starting this python process from rc.local, and it just keeps running all the way, although, maybe an inittab entry would have been a better choice. But I think this would have made life better for laptop users, while keeping complexity at the minimal level.
WOW! This is not only ridiculous complicated, BUT also there is NO need for this.
And you like to parade your fine knowledge of Slackware Architecture. Oh, well...
With all respect, LuckyWolf-sensei, the elogind from Slackware 15.0 has support for power management scripting (just like systemd) and any suspend/resume and hibernate/thaw hook scripts need to be in the directory /lib64/elogind/system-sleep/ and use the variables $1 (pre or post) and $2 (suspend, hibernate, or hybrid-sleep).
For example, a hook script could have the following format:
Code:
#!/bin/bash
case $1/$2 in
pre/*)
# Put here any commands expected to be run when suspending or hibernating.
;;
post/*)
# Put here any commands expected to be run when resuming from suspension or thawing from hibernation.
;;
esac
PS. These scripts should be executable.
Last edited by LuckyCyborg; 11-18-2022 at 10:19 AM.
Both are not required for a full-featured operating system.
I'm afraid that we have a very different taste about what it's a "full-featured operating system" .
I for one, I believe that a "full-featured operating system" should ship at least both Plasma5 and GNOME4. Each one, being fully featured.
Quote:
Originally Posted by Lockywolf
Both are very polarizing in terms of user affiliation.
That's exactly why I believe that the Slackware should ship both, if our BDFL wants a wider users base. And a wider user base is good, because this means more sales or donations or patreons.
After all, the GNOME is really widely used by the Linux users - because it's the main DE on Ubuntu, Fedora and even openSUSE. Millions of Linux users uses it. Millions of Linux users likes it.
Quote:
Originally Posted by Lockywolf
Both require an enormous amount of work, and both have userbases large enough to bear the burden of maintaining them without spending Mr. Volkerding's effort.
Man, did you understand the phrase "Mr. Hameleers and Mr. Volkerding uses Plasma5" ?
So, now you tell to our BDFL how to use his own Slackware?
Last edited by LuckyCyborg; 11-18-2022 at 11:13 AM.
Maybe removing the ctags bundling within the vim package and use https://github.com/universal-ctags/ctags as a separated package in stead? It is constantly maintained.
+--------------------------+
Sat Mar 26 23:04:41 PST 2005
...
gnome/*: Removed from -current, and turned over to community support and
distribution. I'm not going to rehash all the reasons behind this, but it's
been under consideration for more than four years. There are already good
projects in place to provide Slackware GNOME for those who want it, and
these are more complete than what Slackware has shipped in the past. So, if
you're looking for GNOME for Slackware -current, I would recommend looking at
these two projects for well-built packages that follow a policy of minimal
interference with the base Slackware system:
There is also Dropline, of course, which is quite popular. However, due to
their policy of adding PAM and replacing large system packages (like the
entire X11 system) with their own versions, I can't give quite the same sort
of nod to Dropline. Nevertheless, it remains another choice, and it's _your_
system, so I will also mention their project:
Please do not incorrectly interpret any of this as a slight against GNOME
itself, which (although it does usually need to be fixed and polished beyond
the way it ships from upstream more so than, say, KDE or XFce) is a decent
desktop choice. So are a lot of others, but Slackware does not need to ship
every choice. GNOME is and always has been a moving target (even the
"stable" releases usually aren't quite ready yet) that really does demand a
team to keep up on all the changes (many of which are not always well
documented). I fully expect that this move will improve the quality of both
Slackware itself, and the quality (and quantity) of the GNOME options
available for it.
Folks, this is how open source is supposed to work. Enjoy. :-)
Many people thought that almost 6 years needed to produce stable Slackware 15.0 after 14.2 was a long time. But lets face it, if also Gnome would have still been included in Slackware version 15.0 would probably not have been released during 2022.
Slackware 10.1 which included Gnome was distributed using 4 cdroms with each iso having a size of about 650 MB. That would not be possible today when all software gets more bloated.
Creds to all people giving us third party packages with Gnome for Slackware! It is a hard work and sometimes things will break because of changes from upstream.
WOW! This is not only ridiculous complicated, BUT also there is NO need for this.
And you like to parade your fine knowledge of Slackware Architecture. Oh, well...
It's fine, I don't know _everything_ about Slackware. I am very happy to learn from you when what you are saying makes sense.
Quote:
Originally Posted by LuckyCyborg
With all respect, LuckyWolf-sensei, the elogind from Slackware 15.0 has support for power management scripting (just like systemd) and any suspend/resume and hibernate/thaw hook scripts need to be in the directory /lib64/elogind/system-sleep/ and use the variables $1 (pre or post) and $2 (suspend, hibernate, or hybrid-sleep).
For example, a hook script could have the following format:
Code:
#!/bin/bash
case $1/$2 in
pre/*)
# Put here any commands expected to be run when suspending or hibernating.
;;
post/*)
# Put here any commands expected to be run when resuming from suspension or thawing from hibernation.
;;
esac
PS. These scripts should be executable.
It's a great suggestion, thank you.
If you'd like adding a "standard" /etc/rc.d/rc.sleep and/or /etc/rc.d/rc.wakeup, would you create a new thread, like marav suggested, proposing a default /lib64/elogind/system-sleep/handle-sleeping.bash?
Quote:
Man, did you understand the phrase "Mr. Hameleers and Mr. Volkerding uses Plasma5" ?
So, now you tell to our BDFL how to use his own Slackware?
I suspect that Mr. Volkerding is using software outside of base Slackware as well.
As usual, lots of off topic post in here lately (my opinion), makes it hard to see the on topic post. Really wish folks would take disagreements off to a separate thread.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
As usual, lots of off topic post in here lately (my opinion), makes it hard to see the on topic post. Really wish folks would take disagreements off to a separate thread.
