For the reason I explained already. If you allow network printer discovery (and the printer advertises itself via DNS-SD as supporting IPP), then no configuration should be necessary.
Assuming sane-airscan is installed, it is the same for scanner devices that advertise themselves via DNS-SD; they should just work without any explicit configuration (firewall allowing mdns). If not, explicit configuration entries can be made in /etc/sane.d/airscan.conf. Refer man sane-airscan for more info.
In the case of USB-connected devices, as long as ipp-usb is installed, then the service is triggered via a udev rule in /usr/lib/udev/rules.d/71-ipp-usb.rules designed to detect such capable devices dynamically…
# Standard IPP over USB devices, with Class/SubClass/Protocol = 7/1/4
ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:070104:*", OWNER="root", GROUP="lp", MODE="0664", TAG+="systemd", ENV{SYSTEMD_WANTS}+="ipp-usb.service"
Very simple these days. 
1 Like
Myrlyn:
https://software.opensuse.org/package/myrlyn
Cockpit
https://software.opensuse.org/package/cockpit
Both are available.
In my case I need
kdesu systemsettings
Otherwise it doesn’t work.
I’m not sure why the difference here. I’m not impacted in that way. Works as expected.
I’m using Leap 15.6 with a long history of upgrades - maybe because of that.
You don’t want my code. I wrote a program once in C that asked my dad how old he was so it could insult him for being old, but he typed anything except a number.
The point is that this is a really common and exceptionally unhelpful refrain in Linux communities. You cannot expect all of your users to be software developers unless you’re expecting to decimate your userbase.
There are other ways to contribute - I mentioned code because that’s the most common thing.
But the reality is that unless someone’s interested in maintaining the code, the code isn’t going to get written or updated.
Expecting developers to work on things that they’re not interested in working on, in an open source community, is also unrealistic.
1 Like
I contribute financially when I can – how can I encourage this to go towards YaST development, which seems to be the implication? I see replies amounting to “just write it yourself, forehead”, followed by a veiled implication that people who like these features are freeloaders. You are not the first person in the Linux community I have seen express this sentiment this week, which is why I was compelled to respond.
As mentioned by someone else above, people who know their way around the OS can access the functionality of YaST without using it, which is why they don’t use it. People who don’t use it don’t maintain it and I think this is something to be mindful of because ultimately the people we are describing here are a vanishingly tiny proportion of PC users. I think we abandon users for developers at our peril. I also think that working on the less glamorous and exciting aspects of an OS is nonetheless imperative to keeping said OS functioning, whether or not its something you are personally interested in. How you encourage development in the less thrilling areas, that’s something for project leadership.
YaST itself isn’t even really the point. The point is that a single GUI point of access for most aspects of administration has been replaced with three or four and it has inevitably led to confusion. I don’t really see this as particularly different to the criticisms I always levelled at Windows 10 for having a Settings app, a Control Panel, a Registry, and various other things that I’ve forgotten in the years since I’ve had to deal with that, that are all required to access different snippets of functionality.
2 Likes
Not really an implication that users are “freeloaders”, more sort of “please recognize that development is often largely volunteer”.
The project isn’t really set up to take financial donations, but that’s generally not the point. Many developers, if not most, are developing to ‘scratch an itch’. If they don’t feel the need to scratch an itch that aligns with what you want, demanding that someone write it isn’t going to encourage them to do so. And that’s often how it comes across.
It’s a collaborative effort.
Cockpit is the future direction, from what I’ve seen. I would start by looking at that and provide constructive feedback on what’s missing there, rather than pining for code that has become more and more difficult to maintain. You can reefer to the mailing list thread referred to earlier in this discussion to see what the issue is. What you’re asking for, according to the developers, isn’t a trivial ask, and their attention is focused on the future admin tool, rather than the past.
1 Like
I honestly wouldn’t try to swim against the tide here. Cockpit and Myrlyn clearly represent the future for those who prefer GUI-based tools, and I believe most would agree with this.
The necessity for explicit manual configuration has vastly reduced for most users, with respect to graphics, printers, and scanners, so many of the YaST modules have been deprecated accordingly.
1 Like
Maintaining and developing software, that you don’t use yourself, is oftentimes a a very painful, and unpleasant experience. And it doesn’t tend to lead to good outcomes, or good software.
It’s bad enough sometimes, to be put in the position of having to maintain dependencies for things I actually use, and want to work on, but a necessary thing to have to do at times. (i.e. $software I’m wanting to use requires $library that isn’t already in the distribution, so I need to package and maintain that $library, in addition to $software).
And to ask developers to continue to work on a piece of software (and lets be honest here, YaST is more an entire framework, and suite of software, with a massive maintenance burden, in addition to a non-zero amount of tech debt and bit rot), that they don’t use, and make accusations that those same developers “don’t care” about users, is both arrogant, and inappropriate.
This is how community projects work.
2 Likes
From a perspective of a retired former developer that has seen / tried to understand the YaST code: I am already worried about the people that think that they can keep YaST maintained. What makes you think you can do better than the (relatively big) team that decided to deprecate it? I for one would not even allow a single of my leftover brain cells to spend time on that. Like I don’t jump from 6 store buildings and hope I will fly.
The reason. I use Suse is that Yast2 makes administration easy. In LEAP 16, Yast is there, but very hard to use. when I try to run Yast2, I get:'Qt GUI wanted but not found, falling back to ncurses.'
From sh -x yast2, it seems that libpy2qt.2.so seems to be missing
++ grep -E ‘/lib64/(.*/)?libc.so’
- plugindir=/usr/lib64/YaST2/plugin
- PLUGIN_SO=/usr/lib64/YaST2/plugin/libpy2qt.so.2
- ‘[’ -e /usr/lib64/YaST2/plugin/libpy2qt.so.2 ‘]’
- return 1
Where do I get this?
Here you go, and pleae use preformated code
Once again, pleasr stop this "re-YaSTing attempts. Like @sfalken already stated, there ie so much more that one would have to recode and maintain, sigh
Rather than giving broad (vague) statements like this, it would be preferable to be more specific about what functionality you use. When responders list various particular requirements, it’s quite clear that there are other means of doing the same (whether graphical or CLI based), and some seem to be unaware that the use cases for some of the YaST modules have been gone for a long time already.
Yast2 has a much nicer partitioner. And IMHO, using a web interface for management is less secure than an app.
@jarome Cockpit has a nice partitioner in the storage plugin?
As indicated earlier, I use the Flatpak version, so it connects over ssh…