Alternative and corresponding configuration tools to YaST modules

English Open Chat
103

Except … as i suspect you know just as well as me, that AI makes massive mistakes. I will bet they will propose a scanning app (which is only for scanning) when in fact one wants an app for configuring. Hence I would be very suspicous of anything from an AI here.

If wanting to use an AI, I would ask a very specific question re: a YaST alternative for configuring a scanner, and then dump the answer in a different AI , with a clear instruction it is only to include scanner configuring. Watch it tear apart the first answer and propose a new one. Dump that into a 3rd AI and watch it tear that apart.

and even after that, … I suspect the output could have errors.

IMHO those who have experience with specific scanner manufacturers and GNU/Linux really are the one’s from whom the best input can come.

One can point to that very good wiki : https://en.opensuse.org/SDB:Configuring_Scanners … instead … but as I noted, that does make me think we stepped back 2 to 3 decades in time.
.

104

You need to take a large step back. Breath. You seems lost, as you focus to much on YaST. There is no need for a YaST scanner alternative for scanner setup/use. Make a simple search how to setup scanners on other linux distributions. And you will see, that all linux distributions use the same way …completely without YaST. And essentially, this is described in the cited AI output above.

1 Like
105

That’s the truth of it. The use cases for the YaST scanner module (and other hardware modules) have largely vanished over time.

When scanners aren’t detected, a troubleshooting process must ensue, as I’ve already outlined.

I’ve been openSUSE since version 10, (and Red Hat before that) for around the same length of time. I’ve assisted dozens of users with scanner issues. YaST never came in to it and was never the path to resolution anyway. Sometimes, vendor drivers or utiltities are required, sometimes a firewall adjustment - things that the YaST module was never designed for anyway.

106

All the things hui said are what I’ve been trying to articulate - you need to look at this like others do when using other distributions.

107

It would be problematic if actual manual configuration was required for typical environments, but for the most part this is just not true anymore. Driverless scanning is a possibility for many as well. The biggest issue tends to be the firewall (allowing mdns)…and there was a user who was trying to access a scanner on another network to the LAN his PC was connected to. In that case, the IP address of the scanner needed to be explicitly added in the backend configuration file (as DNS-SD is generally limited to the local network).

108

Well I do, and have been trying to guide you here. :wink:

To summarize, when scanners aren’t detected, it’s more a matter of troubleshooting than simple configuration — something I feel is being conflated here.

109

Chances are that AI is now basing suggestions also on this topic … :slight_smile:

110

deano_ferrai and hui, I appreciate both your input. Clearly you do not share my concern here, and I think that is good. Perhaps I am being overly pessimistic. Let see if I understand this now.

Presumably, most GNU/Linux distributions may have to do some of the following (if not automatically included in the basic install):

  • Step-1: install sane-backends + other (?)
  • Step-2: install a GUI scanning tool (simple-scan, or skanlite, or xsane)
  • Step-3: install manufacturer specific drivers if necessary (ie via hplip, or epson-inkjet-printer-escpr, or bjnp (for Canon)
  • Step-4: try to detect scanner: " scanimage -L "
  • Step-5: (Possibly necessary for networks). May need avahi-daemon installed if not already

In the case of openSUSE, perhaps sane-backends is installed by default as part of the basic install) - hence:

  • Step-1: As part of the LEAP install: sane-backends and sane-backends-autoconfig (possibly this has the udev configuration info for sane) installed automatically <<< so no user action needed here.
  • Step-2: install a GUI scanning tool (simple-scan, or skanlite, or xsane)
  • Step-3: install manufacturer specific backends/drivers if necessary (ie hplip, or epson-inkjet-printer-escpr, or bjnp (for Canon)
  • Step-4: try to detect scanner: " scanimage -L "
  • Step-5: Not necessary as avahi-daemon installed by default in LEAP (?)

And assuming that the case, then the YaST alternative wording (approximate) for the 1st post could be: (consistent I think with what is being recommended:

YasT alternative: Sane support for scanner provided at install. Install manufacturer specific drivers as required (see note-x).

And in note-x states :
Note-x: vendor specific driver examples are: hplip for HP or epson-inkjet-printer-escpr, or bjnp (for Canon))`

Apologies if my learning here is frustrating … but if this puzzles me, I suspect if there is anyone who knows less than me :roll_eyes: :joy: , it may puzzle them too.
.

111

Usually none of the above would be needed, as the desktop environment patterns would include the required SANE environment to begin with. Sometimes, users will have a preference for a GUI frontend that may need to be installed I guess. If no scanner is detected, then one can begin troubleshooting. Running scanimage -L is a good start. Users may need to seek forum assistance. It may not be obvious that a particular brand/model device requires vendor drivers to some users.

This applies to network devices: Avahi should be active, but check the firewall. (I’ve already mentioned what is required.)

I would refine that a bit…

YaST alternative: N/A. SANE support for scanners is provided at install. However, users may have hardware that needs vendor drivers or undertake other troubleshooting steps if their scanner isn’t automatically detected (see note-x).

112

@oldcpu I strongly agree with @hui and @deano_ferrari . Basically:

  • YaST = Yet another Setup Tool. I.e. a configuration tool, not a troubleshooting tool, which YaST never was.
  • The alternatives should be just in place replacements for YaST modules
  • I will repeat that making the page more than that will result in
    – An overwhelming, long page that no doubt will bring confusion for users
    – A page that needs daily maintenance: every single change on wiki pages, tool documentation, upstream changes has to reflect on “your page”.
  • You are completely losing the KISS principle way with alternatives that need extra configuration
    – Audio setup these days never needs ALSA configuration, pulseaudio settings etc. The only useful tools replacing YaST Sound are pavucontrol and the DE settings tools. Using other, outdated tools can actually break / interfere with automatic setup configs.
    – YaST Software example: dnf and zypper IMNSHO are not alternatives, since no GUI. Which leaves Myrlyn and the PackageKit based DE alternatives (Discover, GNOME Software)
  • In general, redefine you target audience.

IMHO It should be no more than this example:
YaST Software | Myrlyn | link_to_Myrlyn_page

1 Like
113

Come to think of it: this thread already shows what I mean. From YaST Module alternatives it has turned into a brainstorm session about potential troubleshooting.

1 Like
114

@knurpht I appreciate your observation (and those of the others on this thread) … but I can’t help shake the feeling, that sometimes the ‘line’ dividing what should be in place for “default installation/setup” and “troubleshooting”, is not so clear.

Years back, when YaST hardware > sound module was maintained to keep up with the audio changes,… back then, going to YaST to test one’s audio was quite common. Back then YaST had both an installation/setup and a troubleshooting functionality. Of course, the maintenance of the YaST sound module mostly stopped, and that is no longer the case. Still the point there is installation/setup vs troubleshooting functionality of YaST was not always clear-cut.

There are great recommendations on this thread, but in truth, I do not believe I am currently in a good position (with only LEAP-15.6 on my PCs) to evaluate the suggestions.

I think I may need to install LEAP-16.0 RC1 on my desktop PC (perhaps replacing an old Tumbleweed install) so I can see what is installed by default.

No need to answer … But I think before I do any more updates to this list, for myself, I need to install LEAP-16.0 RC so to better understand what apps & basic dependencies are installed, so to assess what is needed for installation/setup, and what is needed for troubleshooting.

I suspect you see the distinction (between YaST alternatives and troubleshooting apps) being more clear cut and definitive than myself, and maybe after I install LEAP-16.0 RC1, (without LEAP-16.0 having YaST), and having played with it, and having increased my knowledge level here, … maybe then I will completely share your view in regards to individual packages to support YaST alternatives and which not to mention as they are ‘only’ for troubleshooting.

But for now, I have to understand better the basic LEAP-16.0 install & setups.

116

Here works better:
ip route

117

OK … Leap-16.0 RC installed on my old destkop. That was ‘interesting’ , a bit tricky since I have rather fussy ideas as to the partitioning on my PC (and I did not want to destroy 3 other OS I have on this desktop’s SSD and HD) and given the installer is very different from the old installer, installing LEAP-16.0 RC was a bit of an adventure for me (possibly not for others). I think I quadruple checked every setting (mounting for / , /home, /boot/efi ) before proceeding with the install. But I diverge …

I guess one could say (given I am age-71) … old dogs sometimes have an issue learning new tricks … :joy: (but that is also off topic).

I am now going to start looking at some of the YaST alternative options, given this is a fresh install and that nothing has been configured much on this PC yet.

One thing I did discover right away (no pun intended) under 1.b (software management) is I am tempted to add ‘Discover’ to "Myrlyn, zypper’ in that location.

Why?

I downloaded ‘chrome browser’ (which I mostly use instead of firefox). Clicked on the icon with Dolphin to install, and the dolphin (?) menu suggestion was to use ‘Discover’.

If Myrlyn was an option from there, I didn’t see it.

Of course I could install with the CLI zypper, but I am comparing to what I recall was YaST functionality. Perhaps my memory is wrong.

Myrlyn is in the nominal desktop application area thou ( and I like the look).

Anyway - as noted - I very much appreciate all the suggestions. I often get things wrong and hence the suggestions provided should hopefully help keep me on the correct path.

But first I want to see how some of the ‘YaST alternatives’ work on this LEAP-16.0 RC1 fresh install.

Also - my apologies in advance - if I am slow in adopting some of the excellent ideas.

= = = =

Edit : and on the topic of YasT alternatives (and me thinking to do some testing), I did not have to do anything with YaST re: my network. During the install, I ensured both wired and wifi selected. My wifi hardware device is a no-name inexpensive dongle (where in LEAP-15.6 I had to go to a 3rd party OBS repos to get the drivers), and so I thought I would get to check out YaST alternatives to set it up that dongle given that it required extra work in LEAP-15.6. Nope. Both wired and wifi just worked in LEAP-16.0 RC. … So scratch that test idea for YaST alternatives. lol !

118

NetworkManager should be handling the network connectivity by default, and recommended for most desktop users.

119

Yes - and LEAP-16.0 RC configured my network with less effort than LEAP-15.6 (no effort with LEAP-16.0 (and no YaST) actually, other than selecting and typing network password during the install). I guess the new kernel (?) means the no-name brand dongle for wifi I have, in this desktop PC, is better supported in LEAP-16.0 than it was in LEAP-15.6.