Recommended to try - EndeavourOS.

A nicely-done Arch-based distro. Very snappy in a KVM
machine too.

The standard ISO only offers XFCE - but the online
installation (an option offered, if you have a
fairly fast connection) lets you install any of the
popular desktops. I picked LXDE, as usual.

One of my only complaints about Arch-based distros
is that to get at any of the good stuff you have to
manually bring in the AUR repo. At this point that
should be just automatic.

I found Octopi the best Synaptic substitute. There
is also tkPacMan, but out of the box it doesn't seem
to see the AUR repos. Some urinate on GUI package
managers but there are SO many apps these days that
it's really really nice to be able to search by
keywords and get a note about what they're all
about and all the dependencies.

In Deb10 I wanted the latest Lazarus/FPC ... but
the repos weren't even close and the files direct
from the makers wouldn't install properly. The
trick was that you had to UN-install ALL the Laz/FPC
stuff on the box first. THEN the newest three
debs could be installed without any version conflicts.
There were about 15 FPC-related packages to be
uninstalled ... and you'd only know what they were
by using something like Synaptic.

So, I like GUI package managers. Why waste and hour
on something you could do in a minute ?

Last I checked DistroWatch - Endeavour had moved up
to the #2 position, just behind MX.

On 23.12.2021 at 23:37, 1667p1 scribbled:

> Recommended to try - EndeavourOS.

Personally I prefer Manjaro, and not just because I happen to be a
moderator at the Manjaro forum. :p

I do however have contact with some of the EndeavourOS people — I was
added as an advisor to the Telegram group for the Calamares developers,
and that group contains people from just about every Arch derivative
you can think of. Some of the EndeavourOS people are also former
Manjaro developers/contributors.

> A nicely-done Arch-based distro. Very snappy in a KVM
> machine too.

One of the advantages of Manjaro over EndeavourOS — at least, in my
opinion, but tastes and preferences do differ — is that Manjaro is a
curated rolling release, not just "a" rolling release. This means that
when it comes to the Manjaro Stable branch, the software is tested
longer and bundled together. You rarely get updates to individual
packages in between the major updates — it does happen, but it's rare.

> The standard ISO only offers XFCE - but the online
> installation (an option offered, if you have a
> fairly fast connection) lets you install any of the
> popular desktops. I picked LXDE, as usual.

Manjaro started off with XFCE only, but in the meantime, KDE Plasma and
GNOME have been added as official releases, and in addition to those
three, there are also a bunch of community releases, created by
individual team members in their own time. These include...

- LXDE
- LXQt
- Cinnamon
- MATE
- Budgie
- Deepin Desktop Environment
- UKUI
- OpenBox
- i3
- awesome
- bspwm

On top of that, there are also several spins, but those are usually
just based upon one of the above editions, but set up with different
defaults, perhaps a different choice of preinstalled packages, and
different artwork. The spins are created by community members.

There are yet a couple of other user interfaces — such as Sway — but
that's because Manjaro also has a commercial partnership with the
makers of the Pinephone and ARM64-powered Pinebook.

> One of my only complaints about Arch-based distros
> is that to get at any of the good stuff you have to
> manually bring in the AUR repo. At this point that
> should be just automatic.

That used to be the case in Manjaro, but the Manjaro developers — or
for that matter, the EndeavourOS developers, or the developers
of any other Arch-based distribution, including Arch itself —
cannot possibly vouch for the security and reliability of the software
in the AUR.

The AUR is a community platform, and this platform HAS in the past
already been abused for trying to get people into downloading malicious
software — trojans, et al. Therefore, and considering the enormous
amount of absolutely clueless newbies we're getting over at the forum
every day, makes the enabling of the AUR in the package manager an
irresponsible decision.

> I found Octopi the best Synaptic substitute.

Manjaro has Pamac, which comes with both a GUI and a command-line
interface, and it does have AUR support if enabled. Personally I never
use its GUI because I find it unintuitive, but it's pretty good as a
command-line package manager. The GUI is written in GTK, but there was
also a Qt-based version, albeit that its development is still lagging
behind on that of the GTK version.

Most of the time however I will use pacman, which is command-line-only
and has no AUR support, but it's robust. And if I have to look up on a
package because of some problems that a newbie has at the forum, then
I'll use Octopi, which unlike the Pamac GUI IS very intuitive to use.

> There is also tkPacMan, but out of the box it doesn't seem
> to see the AUR repos.

If I recall correctly, then Octopi has no access to the AUR either
unless you install an AUR helper like yay or trizen.

> Some urinate on GUI package managers but there are SO many apps these
> days that it's really really nice to be able to search by keywords
> and get a note about what they're all about and all the dependencies.

Correct, and that's the kind of thing that I would use Octopi for. For
actually installing software however, I prefer the command line, and
from a character-mode tty, while completely logged out of Plasma — which
is the desktop environment I use, albeit that I've completely
customized mine, so that it doesn't even remotely look like the stock
Plasma install anymore.

I prefer installing and updating via the character-mode console and
logged out of the GUI because then all of the shared libraries used by
the GUI will have been closed, which allows me to remount my /boot,
/boot/efi, /usr, /usr/local and /opt filesystems read-only again after
installing/updating — I normally have those read-only during normal
operation.

Of course, if it 's a big update, then I don't need to remount them,
because then the kernel will have been updated as well, and then I have
to reboot anyway. I also manually TRIM them after updating, installing
or removing software, because the weekly TRIM only handles
read/write-mounted filesystems. But that's just MY setup, and
therefore, that's my choice.

The above all said, I do think it's cool that Arch-based distributions
are getting a little more publicity around these parts. With all of
the .deb- and .rpm-based violence going round these last decades, one
would start thinking there's nothing else anymore than Ubuntu, Mint and
Fedora. ;)

--
With respect,
= Aragorn

On 12/24/21 7:45 AM, Aragorn wrote:
> On 23.12.2021 at 23:37, 1667p1 scribbled:
>
>> Recommended to try - EndeavourOS.
>
> Personally I prefer Manjaro, and not just because I happen to be a
> moderator at the Manjaro forum. :p
>
> I do however have contact with some of the EndeavourOS people — I was
> added as an advisor to the Telegram group for the Calamares developers,
> and that group contains people from just about every Arch derivative
> you can think of. Some of the EndeavourOS people are also former
> Manjaro developers/contributors.
>
>> A nicely-done Arch-based distro. Very snappy in a KVM
>> machine too.
>
> One of the advantages of Manjaro over EndeavourOS — at least, in my
> opinion, but tastes and preferences do differ — is that Manjaro is a
> curated rolling release, not just "a" rolling release. This means that
> when it comes to the Manjaro Stable branch, the software is tested
> longer and bundled together. You rarely get updates to individual
> packages in between the major updates — it does happen, but it's rare.
>
>> The standard ISO only offers XFCE - but the online
>> installation (an option offered, if you have a
>> fairly fast connection) lets you install any of the
>> popular desktops. I picked LXDE, as usual.
>
> Manjaro started off with XFCE only, but in the meantime, KDE Plasma and
> GNOME have been added as official releases, and in addition to those
> three, there are also a bunch of community releases, created by
> individual team members in their own time. These include...
>
> - LXDE
> - LXQt
> - Cinnamon
> - MATE
> - Budgie
> - Deepin Desktop Environment
> - UKUI
> - OpenBox
> - i3
> - awesome
> - bspwm
>
> On top of that, there are also several spins, but those are usually
> just based upon one of the above editions, but set up with different
> defaults, perhaps a different choice of preinstalled packages, and
> different artwork. The spins are created by community members.
>
> There are yet a couple of other user interfaces — such as Sway — but
> that's because Manjaro also has a commercial partnership with the
> makers of the Pinephone and ARM64-powered Pinebook.
>
>> One of my only complaints about Arch-based distros
>> is that to get at any of the good stuff you have to
>> manually bring in the AUR repo. At this point that
>> should be just automatic.
>
> That used to be the case in Manjaro, but the Manjaro developers — or
> for that matter, the EndeavourOS developers, or the developers
> of any other Arch-based distribution, including Arch itself —
> cannot possibly vouch for the security and reliability of the software
> in the AUR.
>
> The AUR is a community platform, and this platform HAS in the past
> already been abused for trying to get people into downloading malicious
> software — trojans, et al. Therefore, and considering the enormous
> amount of absolutely clueless newbies we're getting over at the forum
> every day, makes the enabling of the AUR in the package manager an
> irresponsible decision.
>
>> I found Octopi the best Synaptic substitute.
>
> Manjaro has Pamac, which comes with both a GUI and a command-line
> interface, and it does have AUR support if enabled. Personally I never
> use its GUI because I find it unintuitive, but it's pretty good as a
> command-line package manager. The GUI is written in GTK, but there was
> also a Qt-based version, albeit that its development is still lagging
> behind on that of the GTK version.
>
> Most of the time however I will use pacman, which is command-line-only
> and has no AUR support, but it's robust. And if I have to look up on a
> package because of some problems that a newbie has at the forum, then
> I'll use Octopi, which unlike the Pamac GUI IS very intuitive to use.
>
>> There is also tkPacMan, but out of the box it doesn't seem
>> to see the AUR repos.
>
> If I recall correctly, then Octopi has no access to the AUR either
> unless you install an AUR helper like yay or trizen.
>
>> Some urinate on GUI package managers but there are SO many apps these
>> days that it's really really nice to be able to search by keywords
>> and get a note about what they're all about and all the dependencies.
>
> Correct, and that's the kind of thing that I would use Octopi for. For
> actually installing software however, I prefer the command line, and
> from a character-mode tty, while completely logged out of Plasma — which
> is the desktop environment I use, albeit that I've completely
> customized mine, so that it doesn't even remotely look like the stock
> Plasma install anymore.
>
> I prefer installing and updating via the character-mode console and
> logged out of the GUI because then all of the shared libraries used by
> the GUI will have been closed, which allows me to remount my /boot,
> /boot/efi, /usr, /usr/local and /opt filesystems read-only again after
> installing/updating — I normally have those read-only during normal
> operation.
>
> Of course, if it 's a big update, then I don't need to remount them,
> because then the kernel will have been updated as well, and then I have
> to reboot anyway. I also manually TRIM them after updating, installing
> or removing software, because the weekly TRIM only handles
> read/write-mounted filesystems. But that's just MY setup, and
> therefore, that's my choice.
>
> The above all said, I do think it's cool that Arch-based distributions
> are getting a little more publicity around these parts. With all of
> the .deb- and .rpm-based violence going round these last decades, one
> would start thinking there's nothing else anymore than Ubuntu, Mint and
> Fedora. ;)

On the whole, I prefer the DEBiVerse. Mint, MX and vanilla Deb are
my main standbys. Except for OpenSuse, the RPM distros seem to be
so CRUDE now. I've tried Manjaro - and it's good - even check out
a few things from the Slack universe once in awhile. The only
Cannonical native I use is Ubuntu Server - and then I un-do some
of those pointless 'Buntuisms. It's the upgrade path I like ...

GenToo is TOO MUCH WORK ... it's for a different crowd. Arch has
always had a good rep, but until recently it was a bit too much
work as well. Manjaro and now Endeavour seem to be changing that.

I did put 'yay' on there - and then Octopi has a special "alien"
button you can use to include the RUR repo into the search. Of
course if I KNOW exactly what I want, pacman from the CL works
just fine. But if you're looking for "something that does something
kind of like this ..." then the GUI interfaces are a huge help.

Finally, as I mentioned, Endeavour was suprisingly snappy in
a VM - even when I kinda loaded it down with software. I'll
be looking into Endeavour more closely. Might earn a real
partition on my real disks. Need to see how well it can do
for real-world type server apps. Dunno yet about how easy
it is to implement the security you'd want for a Net-facing
server, for example.

On 24.12.2021 at 11:24, 1667p1 scribbled:

> Finally, as I mentioned, Endeavour was suprisingly snappy in
> a VM - even when I kinda loaded it down with software.

All Arch-based distros are snappy, and that's because their binaries
are compiled without debugging symbols. Not very amusing for the
upstream developers if you're filing a bug report — e.g. I've already
fled several bug reports against upstream KDE, and they hate Arch-based
distros for that reason — but it does make a world of difference in
terms of performance.

--
With respect,
= Aragorn

On 12/24/21 11:42 AM, Aragorn wrote:
> On 24.12.2021 at 11:24, 1667p1 scribbled:
>
>> Finally, as I mentioned, Endeavour was suprisingly snappy in
>> a VM - even when I kinda loaded it down with software.
>
> All Arch-based distros are snappy, and that's because their binaries
> are compiled without debugging symbols. Not very amusing for the
> upstream developers if you're filing a bug report — e.g. I've already
> fled several bug reports against upstream KDE, and they hate Arch-based
> distros for that reason — but it does make a world of difference in
> terms of performance.

Ah HA !

Hmmm ... think Deb/Canonical/etc could be talked into
offering "NDB" distro options .. "No DeBug" ???

Guess it IS possible to compile the kernel and most
everything else from scratch, deliberatly disabling
the debug code ... but what a pain in the ass !

Aragorn <thorongil@telenet.be> writes:
> All Arch-based distros are snappy, and that's because their binaries
> are compiled without debugging symbols. Not very amusing for the
> upstream developers if you're filing a bug report — e.g. I've already
> fled several bug reports against upstream KDE, and they hate Arch-based
> distros for that reason — but it does make a world of difference in
> terms of performance.

How are you measuring that difference and what are the numbers?

--
https://www.greenend.org.uk/rjk/

On 25.12.2021 at 09:40, Richard Kettlewell scribbled:

> Aragorn <thorongil@telenet.be> writes:
>
> > All Arch-based distros are snappy, and that's because their binaries
> > are compiled without debugging symbols. Not very amusing for the
> > upstream developers if you're filing a bug report — e.g. I've
> > already fled several bug reports against upstream KDE, and they
> > hate Arch-based distros for that reason — but it does make a world
> > of difference in terms of performance.
>
> How are you measuring that difference and what are the numbers?

I'm not measuring anything, and I don't have any numbers. It is
however quite well known that Arch and Arch-derivatives perform better
than most other distros, exactly because of the absence of debugging
symbols throughout all binaries in the system.

I suppose one could run a benchmark, but I'm not particularly inclined
to waste my time that. Personally I don't really care too much about
gaining a few microseconds here and there, as long as the overall
system is responsive enough to my user input.

--
With respect,
= Aragorn

Aragorn <thorongil@telenet.be> writes:
> On 25.12.2021 at 09:40, Richard Kettlewell scribbled:
>> Aragorn <thorongil@telenet.be> writes:
>>> All Arch-based distros are snappy, and that's because their binaries
>>> are compiled without debugging symbols. Not very amusing for the
>>> upstream developers if you're filing a bug report — e.g. I've
>>> already fled several bug reports against upstream KDE, and they
>>> hate Arch-based distros for that reason — but it does make a world
>>> of difference in terms of performance.
>>
>> How are you measuring that difference and what are the numbers?
>
> I'm not measuring anything, and I don't have any numbers. It is
> however quite well known that Arch and Arch-derivatives perform better
> than most other distros, exactly because of the absence of debugging
> symbols throughout all binaries in the system.

I’m skeptical because debug symbols don’t get paged into RAM during
normal execution, making it hard to see how they could affect runtime
performance (rather than just sit there inertly on disk).

--
https://www.greenend.org.uk/rjk/

On 12/25/21 6:39 AM, Richard Kettlewell wrote:
> Aragorn <thorongil@telenet.be> writes:
>> On 25.12.2021 at 09:40, Richard Kettlewell scribbled:
>>> Aragorn <thorongil@telenet.be> writes:
>>>> All Arch-based distros are snappy, and that's because their binaries
>>>> are compiled without debugging symbols. Not very amusing for the
>>>> upstream developers if you're filing a bug report — e.g. I've
>>>> already fled several bug reports against upstream KDE, and they
>>>> hate Arch-based distros for that reason — but it does make a world
>>>> of difference in terms of performance.
>>>
>>> How are you measuring that difference and what are the numbers?
>>
>> I'm not measuring anything, and I don't have any numbers. It is
>> however quite well known that Arch and Arch-derivatives perform better
>> than most other distros, exactly because of the absence of debugging
>> symbols throughout all binaries in the system.
>
> I’m skeptical because debug symbols don’t get paged into RAM during
> normal execution, making it hard to see how they could affect runtime
> performance (rather than just sit there inertly on disk).

You may be right there ... the symbols just add a little
bulk, but only a little. The question is whether setting
some 'add debug' flags on gcc insert WORKING code into
the middle of your binary ... array-bounds checking,
exception handling and such. THAT could slow things down.

Anyway, the snappiness of Arch/Endeavour was VERY obvious.
SOMETHING is different there.

1667p1 <z24ba6.net> wrote:
> On 12/24/21 11:42 AM, Aragorn wrote:
>> On 24.12.2021 at 11:24, 1667p1 scribbled:
>>
>>> Finally, as I mentioned, Endeavour was suprisingly snappy in
>>> a VM - even when I kinda loaded it down with software.
>>
>> All Arch-based distros are snappy, and that's because their binaries
>> are compiled without debugging symbols. Not very amusing for the
>> upstream developers if you're filing a bug report -- e.g. I've already
>> fled several bug reports against upstream KDE, and they hate Arch-based
>> distros for that reason -- but it does make a world of difference in
>> terms of performance.
>
> Ah HA !
>
> Hmmm ... think Deb/Canonical/etc could be talked into
> offering "NDB" distro options .. "No DeBug" ???

I think they already have been:
https://manpages.debian.org/testing/debhelper/dh_strip.1.en.html

The symbols are actually packaged separately as [name]-dbg
packages:
https://wiki.debian.org/DebugPackage

Maybe not with kernel modules.

> Guess it IS possible to compile the kernel and most
> everything else from scratch, deliberatly disabling
> the debug code ... but what a pain in the ass !

The Strip program from GNU Binutils allows removing debugging
symbols for existing binaries, so they don't have to be
recompiled:
https://sourceware.org/binutils/docs-2.37/binutils/strip.html

It seems that the main advantage is in reducing the file size
(where the difference can be significant). I guess on a HDD that
could reduce seek time, and perhaps there could be implications
to do with caching, but it doesn't seem like it should make a big
difference to performance because they're not normally read into
memory (from the end of the file).

--
__ __
#_ < |\| |< _#

Aragorn <thorongil@telenet.be> writes:

> On 24.12.2021 at 11:24, 1667p1 scribbled:
>
>> Finally, as I mentioned, Endeavour was suprisingly snappy in
>> a VM - even when I kinda loaded it down with software.
>
> All Arch-based distros are snappy, and that's because their binaries
> are compiled without debugging symbols.

I guess by that metric Debian is snappy then, also.

$ file /bin/ls
/bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a65f86cd6394e8f583c14d786d13b3bcbe051b87, stripped

If it's not obvious, file lists "with debug_info" for files with
debugging symbols.

On 12/28/21 5:31 AM, Anssi Saari wrote:
> Aragorn <thorongil@telenet.be> writes:
>
>> On 24.12.2021 at 11:24, 1667p1 scribbled:
>>
>>> Finally, as I mentioned, Endeavour was suprisingly snappy in
>>> a VM - even when I kinda loaded it down with software.
>>
>> All Arch-based distros are snappy, and that's because their binaries
>> are compiled without debugging symbols.
>
> I guess by that metric Debian is snappy then, also.

CAN be ... if you leave out a lot of the junk.

Check out SliTaz.

But even then, Endeavour/Arch still seems inordinately
snappy. They've done SOMETHING different ....

>
> $ file /bin/ls
> /bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a65f86cd6394e8f583c14d786d13b3bcbe051b87, stripped
>
> If it's not obvious, file lists "with debug_info" for files with
> debugging symbols.

It's not the "symbols" ... it's the WORKING CODE that may
be associated with "debug" compilations that can include
stuff like array range-checking and such and spitting out
error codes when things go wrong. In short, a program
melded with a program.

I compiled a rather smallish 'C' program today after I
updated a bit of it. The 'debug' version was about 33mb
while the 'production' version - minus the debug stuff -
was about 21k. That's a good third of the pgm infiltrated
with 'debug' stuff. That could indeed slow things down.
Hard to benchmark with that particular pgm (a TCP client
app), but surely a benchmarkable test example - with various
bits debug code might monitor/report - could be crafted and
the two versions compared.

Aragorn <thorongil@telenet.be> writes:

> On 23.12.2021 at 23:37, 1667p1 scribbled:
>
>> I found Octopi the best Synaptic substitute.
>
> Manjaro has Pamac, which comes with both a GUI and a command-line
> interface, and it does have AUR support if enabled. Personally I never
> use its GUI because I find it unintuitive, but it's pretty good as a
> command-line package manager. The GUI is written in GTK, but there was
> also a Qt-based version, albeit that its development is still lagging
> behind on that of the GTK version.
>
> Most of the time however I will use pacman, which is command-line-only
> and has no AUR support, but it's robust. And if I have to look up on a
> package because of some problems that a newbie has at the forum, then
> I'll use Octopi, which unlike the Pamac GUI IS very intuitive to use.
>

I used Arch for a little while, and pacman was one of the things I really liked
about it. It's really well-done.

On 02.01.2022 at 06:02, Bud Frede scribbled:

> Aragorn <thorongil@telenet.be> writes:
>
> > On 23.12.2021 at 23:37, 1667p1 scribbled:
> >
> >> I found Octopi the best Synaptic substitute.
> >
> > Manjaro has Pamac, which comes with both a GUI and a command-line
> > interface, and it does have AUR support if enabled. Personally I
> > never use its GUI because I find it unintuitive, but it's pretty
> > good as a command-line package manager. The GUI is written in GTK,
> > but there was also a Qt-based version, albeit that its development
> > is still lagging behind on that of the GTK version.
> >
> > Most of the time however I will use pacman, which is
> > command-line-only and has no AUR support, but it's robust. And if
> > I have to look up on a package because of some problems that a
> > newbie has at the forum, then I'll use Octopi, which unlike the
> > Pamac GUI IS very intuitive to use.
>
> I used Arch for a little while, and pacman was one of the things I
> really liked about it. It's really well-done.

After having used distributions with different package managers — and
even having used the old approach where you had to manually unpack a
tarball — I find pacman to be the best in its class. ;)

--
With respect,
= Aragorn

On 1/2/22 10:23 AM, Aragorn wrote:
> On 02.01.2022 at 06:02, Bud Frede scribbled:
>
>> Aragorn <thorongil@telenet.be> writes:
>>
>>> On 23.12.2021 at 23:37, 1667p1 scribbled:
>>>
>>>> I found Octopi the best Synaptic substitute.
>>>
>>> Manjaro has Pamac, which comes with both a GUI and a command-line
>>> interface, and it does have AUR support if enabled. Personally I
>>> never use its GUI because I find it unintuitive, but it's pretty
>>> good as a command-line package manager. The GUI is written in GTK,
>>> but there was also a Qt-based version, albeit that its development
>>> is still lagging behind on that of the GTK version.
>>>
>>> Most of the time however I will use pacman, which is
>>> command-line-only and has no AUR support, but it's robust. And if
>>> I have to look up on a package because of some problems that a
>>> newbie has at the forum, then I'll use Octopi, which unlike the
>>> Pamac GUI IS very intuitive to use.
>>
>> I used Arch for a little while, and pacman was one of the things I
>> really liked about it. It's really well-done.
>
> After having used distributions with different package managers — and
> even having used the old approach where you had to manually unpack a
> tarball — I find pacman to be the best in its class. ;)

CL package managers are good for getting what you need - but
not so good for discovering stuff you didn't KNOW you "needed" :-)

On 02.01.2022 at 21:36, 1.AAC0831 scribbled:

> On 1/2/22 10:23 AM, Aragorn wrote:
> > On 02.01.2022 at 06:02, Bud Frede scribbled:
> >
> >> Aragorn <thorongil@telenet.be> writes:
> >>
> >>> On 23.12.2021 at 23:37, 1667p1 scribbled:
> >>>
> >>>> I found Octopi the best Synaptic substitute.
> >>>
> >>> Manjaro has Pamac, which comes with both a GUI and a command-line
> >>> interface, and it does have AUR support if enabled. Personally I
> >>> never use its GUI because I find it unintuitive, but it's pretty
> >>> good as a command-line package manager. The GUI is written in
> >>> GTK, but there was also a Qt-based version, albeit that its
> >>> development is still lagging behind on that of the GTK version.
> >>>
> >>> Most of the time however I will use pacman, which is
> >>> command-line-only and has no AUR support, but it's robust. And if
> >>> I have to look up on a package because of some problems that a
> >>> newbie has at the forum, then I'll use Octopi, which unlike the
> >>> Pamac GUI IS very intuitive to use.
> >>
> >> I used Arch for a little while, and pacman was one of the things I
> >> really liked about it. It's really well-done.
> >
> > After having used distributions with different package managers —
> > and even having used the old approach where you had to manually
> > unpack a tarball — I find pacman to be the best in its class. ;)
>
>
> CL package managers are good for getting what you need - but
> not so good for discovering stuff you didn't KNOW you "needed" :-)

Well, that's what I use Octopi for — for getting information. But
once I've decided on installing something, I use pacman — or if it's
from the AUR, yay or pamac-cli. ;)

--
With respect,
= Aragorn

On 1/3/22 6:57 PM, Aragorn wrote:
> On 02.01.2022 at 21:36, 1.AAC0831 scribbled:
>
>> On 1/2/22 10:23 AM, Aragorn wrote:
>>> On 02.01.2022 at 06:02, Bud Frede scribbled:
>>>
>>>> Aragorn <thorongil@telenet.be> writes:
>>>>
>>>>> On 23.12.2021 at 23:37, 1667p1 scribbled:
>>>>>
>>>>>> I found Octopi the best Synaptic substitute.
>>>>>
>>>>> Manjaro has Pamac, which comes with both a GUI and a command-line
>>>>> interface, and it does have AUR support if enabled. Personally I
>>>>> never use its GUI because I find it unintuitive, but it's pretty
>>>>> good as a command-line package manager. The GUI is written in
>>>>> GTK, but there was also a Qt-based version, albeit that its
>>>>> development is still lagging behind on that of the GTK version.
>>>>>
>>>>> Most of the time however I will use pacman, which is
>>>>> command-line-only and has no AUR support, but it's robust. And if
>>>>> I have to look up on a package because of some problems that a
>>>>> newbie has at the forum, then I'll use Octopi, which unlike the
>>>>> Pamac GUI IS very intuitive to use.
>>>>
>>>> I used Arch for a little while, and pacman was one of the things I
>>>> really liked about it. It's really well-done.
>>>
>>> After having used distributions with different package managers —
>>> and even having used the old approach where you had to manually
>>> unpack a tarball — I find pacman to be the best in its class. ;)
>>
>>
>> CL package managers are good for getting what you need - but
>> not so good for discovering stuff you didn't KNOW you "needed" :-)
>
> Well, that's what I use Octopi for — for getting information. But
> once I've decided on installing something, I use pacman — or if it's
> from the AUR, yay or pamac-cli. ;)
>

Octopi can install it just as well. Why switch to CLI ?

On 04.01.2022 at 00:21, 1.AAC0831 scribbled:

> On 1/3/22 6:57 PM, Aragorn wrote:
>
> > On 02.01.2022 at 21:36, 1.AAC0831 scribbled:
> >
> >> CL package managers are good for getting what you need - but
> >> not so good for discovering stuff you didn't KNOW you "needed"
> >> :-)
> >
> > Well, that's what I use Octopi for — for getting information. But
> > once I've decided on installing something, I use pacman — or if it's
> > from the AUR, yay or pamac-cli. ;)
>
>
> Octopi can install it just as well. Why switch to CLI ?

Because...

1. It's more verbose and more flexible.

2. If you completely log out of the GUI first and run the update
process from a character-mode virtual console, then the least
amount of shared libraries will be in use, and then there won't be
any surprises if they get overwritten by the update.

3. I run my system with a read-only /boot/efi, /boot, /usr,
/usr/local and /opt. If I want to update the system, then all of
those have to be remounted read/write — well okay, maybe not
/boot/efi. If I only install or remove software, then I can
generally limit that to /usr and /opt. But remounting /usr
read-only again after installing or removing something is often
problematic — "/usr: filesystem is busy" — and especially so when
the GUI is running. Logging out of the GUI first and running the
install/remove from a tty minimizes that problem, although it has
already happened that /usr was still "busy" when I tried to
remount it. And I don't like rebooting unless it's necessary.

4. I HAVE already come across problems when trying to install and/or
uninstall something via Octopi, whereas doing it with pacman, yay
or pamac always works flawlessly. For instance, trying to
uninstall something with Octopi when it has optional dependencies
and leaving those optional dependencies installed will often
result in either a failure to uninstall the package or an
ambiguous error message that doesn't tell you whether it succeeded
or not. With pacman, it simply uninstalls the package and by
default leaves its optional dependencies alone, period.

--
With respect,
= Aragorn

On 1/4/22 2:20 PM, Aragorn wrote:
> On 04.01.2022 at 00:21, 1.AAC0831 scribbled:
>
>> On 1/3/22 6:57 PM, Aragorn wrote:
>>
>>> On 02.01.2022 at 21:36, 1.AAC0831 scribbled:
>>>
>>>> CL package managers are good for getting what you need - but
>>>> not so good for discovering stuff you didn't KNOW you "needed"
>>>> :-)
>>>
>>> Well, that's what I use Octopi for — for getting information. But
>>> once I've decided on installing something, I use pacman — or if it's
>>> from the AUR, yay or pamac-cli. ;)
>>
>>
>> Octopi can install it just as well. Why switch to CLI ?
>
> Because...
>
> 1. It's more verbose and more flexible.

Not relevant to me. I just want it DONE, easily.

Yes, I oft use "apt"/"apt-get" from the CL in Debs
but it's not because they are "better" than something
like Synaptic - just a tad quicker if I want ONE thing.
Apt-get with the --no-recommends flag is good if you
want to install LXDE or something light on like a rPI.

> 2. If you completely log out of the GUI first and run the update
> process from a character-mode virtual console, then the least
> amount of shared libraries will be in use, and then there won't be
> any surprises if they get overwritten by the update.

This is true. However it's my practice to REBOOT after any
"major" update - esp if the kernel/initrafmfs are involved.
This may not be practical in a busy 24/7 biz environment
however. There ARE distros that PROMISE you never have to
reboot ... worth checking into. I think Oracle Linux is
like that (another RHEL clone - are they screwed the way
Centos was screwed ???)

GAWD will they all DUMP the horrible awful apocalyptic
Gnome-4 desktop sometime soon ?????????

Gnome, I come not to praise you, but to bury you ....

> 3. I run my system with a read-only /boot/efi, /boot, /usr,
> /usr/local and /opt.

Pretty extreme IMHO. Yes, best security, but at a price
in terms of workload, esp at times when there are a lot
of updates coming in like the Log4J thing.

> If I want to update the system, then all of
> those have to be remounted read/write — well okay, maybe not
> /boot/efi. If I only install or remove software, then I can
> generally limit that to /usr and /opt. But remounting /usr
> read-only again after installing or removing something is often
> problematic — "/usr: filesystem is busy" — and especially so when
> the GUI is running. Logging out of the GUI first and running the
> install/remove from a tty minimizes that problem, although it has
> already happened that /usr was still "busy" when I tried to
> remount it. And I don't like rebooting unless it's necessary.

I have fewer "busy" problems in Debian-derived systems. Arch IS a
different animal though.

My other old fav is OpenSUSE ... the "tumbleweed" rolling disto
is pretty much future-proof, but takes a LONG time to update.
They DID screw me recently however by substituting less-capable
versions of some utilities I was using, and leaving out some
that come with pretty much EVERY distro. Had to move those
boxes to U-Server. OSuse IS a very very nice system on the...
whole though - makes a lot of tedious stuff, like setting
up RAID for example, super-quick and easy. The first Linux
I ever bought - and you had to buy them back then - was
RedHat ... xorg was BARELY there. The next one though was
SUSE. I was happy with that.

>
> 4. I HAVE already come across problems when trying to install and/or
> uninstall something via Octopi, whereas doing it with pacman, yay
> or pamac always works flawlessly. For instance, trying to
> uninstall something with Octopi when it has optional dependencies
> and leaving those optional dependencies installed will often
> result in either a failure to uninstall the package or an
> ambiguous error message that doesn't tell you whether it succeeded
> or not. With pacman, it simply uninstalls the package and by
> default leaves its optional dependencies alone, period.

Octopi is NOT infallible. But, you'll know it and then you can
use CL methods. I've had very FEW problems with Octopi so far
however.

ANYway ... EndeavourOS/Arch ... the snappiness impresses.
I will find more uses for it. I wonder if there's an rPI
disto ? I have a number of PIs hooked in at the moment,
each doing their little jobs nicely. You CAN run MX
or Tumbleweed on them - but those systems are just TOO
bulky, TOO slow.

On 05.01.2022 at 00:51, 1.AAC0832 scribbled:

> On 1/4/22 2:20 PM, Aragorn wrote:
>
> > On 04.01.2022 at 00:21, 1.AAC0831 scribbled:
> >
> >> On 1/3/22 6:57 PM, Aragorn wrote:
> >>
> >>> On 02.01.2022 at 21:36, 1.AAC0831 scribbled:
> >>>
> >> Octopi can install it just as well. Why switch to CLI ?
> >
> > Because...
> >
> > 1. It's more verbose and more flexible.
>
> Not relevant to me. I just want it DONE, easily.

Well, so do I, and I find it easiest to use the CLI. ;)

> > 2. If you completely log out of the GUI first and run the update
> > process from a character-mode virtual console, then the least
> > amount of shared libraries will be in use, and then there
> > won't be any surprises if they get overwritten by the update.
>
> This is true. However it's my practice to REBOOT after any
> "major" update - esp if the kernel/initrafmfs are involved.

Yes, mine too, although I sometimes need to delay that by about ten
minutes — among other things, in order to deal with any .pacnew files.

But it may also happen that you get a small update with only a couple
of packages, which cannot be held back until the next major update due
to security reasons. So then I try to avoid a reboot.

> GAWD will they all DUMP the horrible awful apocalyptic
> Gnome-4 desktop sometime soon ?????????

Well, you mention RedHat and Oracle (which is a RedHat derivative).
GNOME is primarily being developed AT RedHat, and it is therefore
somewhat logical that they choose that as the default desktop
environment for RedHat, CentOS and Fedora.

For that matter, RedHat used to have a strong hatred for KDE and
refused to support KDE even after KDE 2 was released, which was based
upon the by that time already free Qt libraries.

I think they only started carrying KDE in their repositories as of KDE
3 on, but even then they were still treating it as a stepchild. It was
definitely not the default, and it was pretty much vanilla in terms of
out-of-the-box setup, unlike with distributions like openSUSE, which
put considerable effort into tweaking KDE and developing additional
software for it — if I recall correctly, then the KickOff application
launcher was actually developed BY openSUSE.

> > 3. I run my system with a read-only /boot/efi, /boot, /usr,
> > /usr/local and /opt.
>
>
> Pretty extreme IMHO. Yes, best security, but at a price
> in terms of workload, esp at times when there are a lot
> of updates coming in like the Log4J thing.

Not just security, but stability as well. And you can easily remount
all of those read/write before applying the updates.

$ for fs in /boot/efi /boot /usr /usr/local /opt; do mount -o \
remount,rw $fs ; done

Then you update and — as you said — you reboot.

> My other old fav is OpenSUSE ... the "tumbleweed" rolling disto
> is pretty much future-proof, but takes a LONG time to update.

I've looked into openSUSE before settling on Manjaro, but one of my
requirements for a new distribution was that it had to have implemented
the /usr merge. In Debian, this was optional and had to be done
post-install.

In openSUSE, they did it exactly the other way around — i.e. they
moved stuff out of /usr/bin, /usr/sbin and /usr/lib into /bin, /sbin
and /lib, while replacing other stuff that was in /bin, /sbin and /lib
by symlinks to /usr/bin, /usr/sbin and /usr/lib.

It's an ugly mess. And then they simply stopped caring about it, so
it's still the same mess today as they created a couple of years ago.
Considering that SuSE and openSUSE had always been a reputed and
well-groomed distribution, I found that unacceptably sloppy, and
definitely not a mess I myself was willing to spend the time on
cleaning it up on my computer after installing.

Arch and its derivatives are squeaky clean in that regard.

> The first Linux I ever bought - and you had to buy them back then
> - was RedHat ... xorg was BARELY there. The next one though was
> SUSE. I was happy with that.

Yes, I too started using GNU/Linux before I had an internet connection,
and therefore, buying a shrink-wrapped box was the way to go. I even
kept on doing that for quite a number of years in order to support the
distribution I was using at the time, and this distribution was
Mandrake — before the merger with Conectiva and the name change to
Mandriva.

> ANYway ... EndeavourOS/Arch ... the snappiness impresses.
> I will find more uses for it. I wonder if there's an rPI
> disto ?

I don't know about EOS, but Manjaro does have an AARCH64 branch, and
we've got many people using it on RPI.

--
With respect,
= Aragorn

On 1/5/22 10:10 AM, Aragorn wrote:
> On 05.01.2022 at 00:51, 1.AAC0832 scribbled:
>
>> On 1/4/22 2:20 PM, Aragorn wrote:
>>
>>> On 04.01.2022 at 00:21, 1.AAC0831 scribbled:
>>>
>>>> On 1/3/22 6:57 PM, Aragorn wrote:
>>>>
>>>>> On 02.01.2022 at 21:36, 1.AAC0831 scribbled:
>>>>>
>>>> Octopi can install it just as well. Why switch to CLI ?
>>>
>>> Because...
>>>
>>> 1. It's more verbose and more flexible.
>>
>> Not relevant to me. I just want it DONE, easily.
>
> Well, so do I, and I find it easiest to use the CLI. ;)
>
>>> 2. If you completely log out of the GUI first and run the update
>>> process from a character-mode virtual console, then the least
>>> amount of shared libraries will be in use, and then there
>>> won't be any surprises if they get overwritten by the update.
>>
>> This is true. However it's my practice to REBOOT after any
>> "major" update - esp if the kernel/initrafmfs are involved.
>
> Yes, mine too, although I sometimes need to delay that by about ten
> minutes — among other things, in order to deal with any .pacnew files.
>
> But it may also happen that you get a small update with only a couple
> of packages, which cannot be held back until the next major update due
> to security reasons. So then I try to avoid a reboot.
>
>> GAWD will they all DUMP the horrible awful apocalyptic
>> Gnome-4 desktop sometime soon ?????????
>
> Well, you mention RedHat and Oracle (which is a RedHat derivative).
> GNOME is primarily being developed AT RedHat, and it is therefore
> somewhat logical that they choose that as the default desktop
> environment for RedHat, CentOS and Fedora.

Started Oracle, thought I'd installed Centos by
mistake :-)

Such a HORRIBLE and USELESS interface !

KDE is obese, but it'd be a HUGE improvement.

Actually, XFCE seems to be the "standard" default
desktop these days - not too big, not too small.
RHEL and clones should REALLY consider it .....

> For that matter, RedHat used to have a strong hatred for KDE and
> refused to support KDE even after KDE 2 was released, which was based
> upon the by that time already free Qt libraries.

The first Linux I ever bought was a VERY early RedHat.
It had Gnome ... horrible even then. Dunno if there
even were alternatives that far back. Woulda had to
download them over dial-up if there were ....

> I think they only started carrying KDE in their repositories as of KDE
> 3 on, but even then they were still treating it as a stepchild. It was
> definitely not the default, and it was pretty much vanilla in terms of
> out-of-the-box setup, unlike with distributions like openSUSE, which
> put considerable effort into tweaking KDE and developing additional
> software for it — if I recall correctly, then the KickOff application
> launcher was actually developed BY openSUSE.
>
>>> 3. I run my system with a read-only /boot/efi, /boot, /usr,
>>> /usr/local and /opt.
>>
>>
>> Pretty extreme IMHO. Yes, best security, but at a price
>> in terms of workload, esp at times when there are a lot
>> of updates coming in like the Log4J thing.
>
> Not just security, but stability as well. And you can easily remount
> all of those read/write before applying the updates.

I've never felt the need to be THAT paranoid - but
certain local situations may warrant it.

> $ for fs in /boot/efi /boot /usr /usr/local /opt; do mount -o \
> remount,rw $fs ; done
>
> Then you update and — as you said — you reboot.
>
>> My other old fav is OpenSUSE ... the "tumbleweed" rolling disto
>> is pretty much future-proof, but takes a LONG time to update.
>
> I've looked into openSUSE before settling on Manjaro, but one of my
> requirements for a new distribution was that it had to have implemented
> the /usr merge. In Debian, this was optional and had to be done
> post-install.
>
> In openSUSE, they did it exactly the other way around — i.e. they
> moved stuff out of /usr/bin, /usr/sbin and /usr/lib into /bin, /sbin
> and /lib, while replacing other stuff that was in /bin, /sbin and /lib
> by symlinks to /usr/bin, /usr/sbin and /usr/lib.

Yep, they do it differently. May or may not be relevant
depending on your situation.

> It's an ugly mess. And then they simply stopped caring about it, so
> it's still the same mess today as they created a couple of years ago.
> Considering that SuSE and openSUSE had always been a reputed and
> well-groomed distribution, I found that unacceptably sloppy, and
> definitely not a mess I myself was willing to spend the time on
> cleaning it up on my computer after installing.

I find OpenSUSE to still be an extremely "usable" distro.
There are a lot of redeeming features, even if the way
they place/update files seems weird.

DID get Tumbleweed to run on a rPI ... but it was way too
slow to be useful for anything.

> Arch and its derivatives are squeaky clean in that regard.
>
>> The first Linux I ever bought - and you had to buy them back then
>> - was RedHat ... xorg was BARELY there. The next one though was
>> SUSE. I was happy with that.
>
> Yes, I too started using GNU/Linux before I had an internet connection,
> and therefore, buying a shrink-wrapped box was the way to go. I even
> kept on doing that for quite a number of years in order to support the
> distribution I was using at the time, and this distribution was
> Mandrake — before the merger with Conectiva and the name change to
> Mandriva.

As I recall, I found RedHat at a WalMart of all places, kinda
stuffed in the shelves full of video games. An early version
of Oracle too. MIGHT still have it stashed somewhere - gotta
look down towards the bottom of The Heap. THE bottom of the
heap - there's a VIC-20 and ZX-81 and comprehensive VMS
manual down there somewhere ... and MAYBE a TI-99-4a. Sold
the C-64 though ... big mistake. Did acquire an Apple-II
however, but I'm afraid to try and boot it in case the
capacitors blow up.

>> ANYway ... EndeavourOS/Arch ... the snappiness impresses.
>> I will find more uses for it. I wonder if there's an rPI
>> disto ?
>
> I don't know about EOS, but Manjaro does have an AARCH64 branch, and
> we've got many people using it on RPI.

I'll check into it.

Saw an ARCH Arch guide to rPi ... but it was a bit
too complicated to be worth my time.

Mostly, rPI is best with it's customized Deb - very
well tuned to the hardware. Not everybody is wiring
stuff to all the little I/O pins though ... I have
several as servers for security cameras, for example.
"Motion".

I know the Debiverse pretty well, but that doesn't
mean I will shun yummy alternatives.

On Thu, 06 Jan 2022 00:20:33 -0500, 1.AAC0832 wrote:
> On 1/5/22 10:10 AM, Aragorn wrote:
>> On 05.01.2022 at 00:51, 1.AAC0832 scribbled:
>>
>>> On 1/4/22 2:20 PM, Aragorn wrote:
>>>
>>>> On 04.01.2022 at 00:21, 1.AAC0831 scribbled:
>>>>
>>>>> On 1/3/22 6:57 PM, Aragorn wrote:
>>>>>
>>>>>> On 02.01.2022 at 21:36, 1.AAC0831 scribbled:
>>>>>>
>>>>> Octopi can install it just as well. Why switch to CLI ?
>>>>
>>>> Because...
>>>>
>>>> 1. It's more verbose and more flexible.
>>>
>>> Not relevant to me. I just want it DONE, easily.
>>
>> Well, so do I, and I find it easiest to use the CLI. ;)
>>
>>>> 2. If you completely log out of the GUI first and run the update
>>>> process from a character-mode virtual console, then the least
>>>> amount of shared libraries will be in use, and then there
>>>> won't be any surprises if they get overwritten by the update.
>>>
>>> This is true. However it's my practice to REBOOT after any
>>> "major" update - esp if the kernel/initrafmfs are involved.
>>
>> Yes, mine too, although I sometimes need to delay that by about ten
>> minutes — among other things, in order to deal with any .pacnew files.
>>
>> But it may also happen that you get a small update with only a couple
>> of packages, which cannot be held back until the next major update due
>> to security reasons. So then I try to avoid a reboot.
>>
>>> GAWD will they all DUMP the horrible awful apocalyptic
>>> Gnome-4 desktop sometime soon ?????????
>>
>> Well, you mention RedHat and Oracle (which is a RedHat derivative).
>> GNOME is primarily being developed AT RedHat, and it is therefore
>> somewhat logical that they choose that as the default desktop
>> environment for RedHat, CentOS and Fedora.
>
>
> Started Oracle, thought I'd installed Centos by
> mistake :-)
>
> Such a HORRIBLE and USELESS interface !
>
> KDE is obese, but it'd be a HUGE improvement.
>
> Actually, XFCE seems to be the "standard" default
> desktop these days - not too big, not too small.
> RHEL and clones should REALLY consider it .....

I bailed on fvwm when I tired of fiddling config files. I bailed on
gnome when it went for the fisher-price appearance and dropped
configurability. I bailed on KDE when it became crashware. I'm about
to bail on XFCE because it's going GTK. Gonna try out LXQT for
my next desktop iteration.

On 06/01/2022 14:57, Joe Beanfish wrote:
> I bailed on fvwm when I tired of fiddling config files. I bailed on
> gnome when it went for the fisher-price appearance and dropped
> configurability. I bailed on KDE when it became crashware. I'm about
> to bail on XFCE because it's going GTK. Gonna try out LXQT for
> my next desktop iteration.

I guess you are a bachelor, too..

http://vps.templar.co.uk/Cartoons%20and%20Politics/unix.jpg

--
"If you don’t read the news paper, you are un-informed. If you read the
news paper, you are mis-informed."

Mark Twain

On 06.01.2022 at 14:57, Joe Beanfish scribbled:

> I bailed on fvwm when I tired of fiddling config files. I bailed on
> gnome when it went for the fisher-price appearance and dropped
> configurability. I bailed on KDE when it became crashware.

KDE Plasma has been rock-solid stable here for decades. If I have
anything that crashes, then it's usually a GTK application — this
Claws Mail here, for instance, and Pan before it.

Crashes in KDE software are rare. [*] Occasional visual glitches are
common, but actual crashes are rare. And the memory footprint of KDE
Plasma isn't much bigger than that of XFCE — in fact, I've even heard
it reported slightly smaller.

> I'm about to bail on XFCE because it's going GTK.

XFCE has ALWAYS been GTK.

[*] Unless you're running it on Wayland. And Nvidia hardware also
appears to be quite crash-prone these days from what I hear, but
I've completely abandoned Nvidia years ago — running on Intel
graphics here, and quite happy with it.

--
With respect,
= Aragorn

On 06/01/2022 at 21.54, Aragorn wrote:
> XFCE has ALWAYS been GTK.

Technically it wasn’t, it was XForms based initially. XFCE meant
XForms Common Environment (named as such because it was inspired
by CDE -- Common Desktop Environment).

--
mrg