On 12/30/2023 4:32 PM, Kirk_Rockstein wrote:
> On 2023-12-30, maus <maus@deb2.org> wrote:
>
>>
>> I have been looking for the terminal utility, `cal'. As I am using
>> Debian, for that dist.
>>
>>
>
> It is part of the util-linux package.
>

https://www.computerhope.com/unix/ucal.htm

It would appear from the general theme of the
article, that ncal is a fork of cal. But
the article does not identify when that happened,
or where it was done.

$ ncal
December 2023
Su 3 10 17 24 31
Mo 4 11 18 25
Tu 5 12 19 26
We 6 13 20 27
Th 7 14 21 28
Fr 1 8 15 22 29
Sa 2 9 16 23 30
$ which ncal
/usr/bin/ncal
$ ls -al /usr/bin/ncal
-rwxr-xr-x 1 root root 37832 Mar 30 2020 /usr/bin/ncal
$ ls -al /usr/bin/cal
lrwxrwxrwx 1 root root 4 Mar 30 2020 /usr/bin/cal -> ncal
$

$ apt search ncal
....
bsdmainutils/focal,now 11.1.2ubuntu3 amd64 [installed,automatic]
collection of more utilities from FreeBSD

And a check in synaptic shows /usr/bin/ncal for that package.

Paul

On 12/30/2023 3:04 PM, Lawrence D'Oliveiro wrote:
> On Fri, 29 Dec 2023 08:49:36 -0500, bad sector wrote:
>
>> Why on earth do apps like kwallet or digicam 'utilities' have to be so
>> inextricably intertwined into Plasma or other 'useful' packages?
>
> Because in the view of the developers, that was the best way to implement
> it.
>
> If you think there is a better way to do it, by all means code it up and
> show us. Just like they did.
>

When you make your very own DE, you create programs as "show pieces",
and they are likely to be decorated with your DE decorations.

The programs were not made with the express purpose of
sitting on a Puppy users desktop.

Other programs, are designed for the sake of the program,
and they tend to be DE agnostic. They don't care what
DE you are running.

QMPlay2 uses QT framework, and the purpose of doing such
a thing, is so the program is cross-platform, and runs on
a Mac or on a PC. The developer then, seeks wide distribution
for their creation, at the expense of the package being
100MB in size or larger.

Paul

On 2023-12-30, Mike Easter <MikeE@ster.invalid> wrote:
> maus wrote:
>> No, no `cal' or `ncal'
>
> I can't find a 'wonderful' page that lists all of the 'core' utilities
> which are found in util-linux package, but here is an Arch page
>
> https://man.archlinux.org/man/cal.1.en
>
> I booted a live Sparky which is based on Deb and it has util-linux in
> its repo/s. but the description for the package doesn't list all of the
> utils contained.
>

Ta for answering.

--
greymausg@mail.com
Are there no jails, no lockdowns?
Not even an .Influencer?

On 30/12/2023 19:00, Carlos E.R. wrote:
> On 2023-12-30 10:52, The Natural Philosopher wrote:
>> On 29/12/2023 20:46, Computer Nerd Kev wrote:
>>> In comp.os.linux.misc bad sector <forgetski@_invalid.net> wrote:
>
> ...
>
>> If you want a hand held you don't need to do a thing installation,
>> Linux Mint is for you.
>> If you use their repositories then all code is compatible.
>
> I understand Mint derives from Ubuntu. What is the advantage? I am
> curious, not looking for rant :-)
1. Installation. Once you have a live bootable USB/DVD there is almost
nothing that needs to be done by a noob user. Name the machine, set up
your user id, and your timezone and keyboard and language, make a cup of
coffee and there you are. Full working installation, complete with
things like firefox, thunderbird etc.
2. GUI look and feel. Its instantly very XP like with either of the
default window environments - Cinnamon or MATE - with things like a
control panel and so on. It may be built on Gnome, but it isn't Gnome.
3. Ease of driver management. There is a program that scans the hardware
and looks up what drivers are recommended. And installs them for you.

So all te good things in Ubuntu are all still there, but a lot of the
rough edges are polished out to make it easy for first time users.

In my case, apart from raspberrty Pis I an very uininterested in playing
with Linux. I simply want a stable desktop to browse, do usenet and
email, and a few other things. Mint is the lowest hassle way to get that
that I have found.

I was pretty happy with Win XP as a user interface, mostly. My
unhappiness was the ease with which it caught malware, and its general
instability. It often crashed.

I started with Debian, ran that for a while, then tried Ubuntu, didn't
like it that much and then tried Mint. at least a decade ago I think. I
stopped looking then. It did what I wanted. That's it. No religion. No
rant. Just easy to install good pretty bug free functional code and
pretty enough to bear looking at for long periods of time.

--
Karl Marx said religion is the opium of the people.
But Marxism is the crack cocaine.

On 30/12/2023 19:11, candycanearter07 wrote:
> On 12/30/23 13:00, Carlos E.R. wrote:
>> On 2023-12-30 10:52, The Natural Philosopher wrote:
>>> On 29/12/2023 20:46, Computer Nerd Kev wrote:
>>>> In comp.os.linux.misc bad sector <forgetski@_invalid.net> wrote:
>>
>> ...
>>
>>> If you want a hand held you don't need to do a thing installation,
>>> Linux Mint is for you.
>>> If you use their repositories then all code is compatible.
>>
>> I understand Mint derives from Ubuntu. What is the advantage? I am
>> curious, not looking for rant :-)
>
> For one, a lot of people hate Canonical.
> Snap-packages suck apparently.
> The default desktop environment is also a lot more windows-y than Ubuntu.
> The community is better.

Amen to all that.
Never understood what a snap package was. Good old apt works for me

--
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

On 30/12/2023 19:41, Carlos E.R. wrote:
> On 2023-12-30 20:11, candycanearter07 wrote:
>> On 12/30/23 13:00, Carlos E.R. wrote:
>>> On 2023-12-30 10:52, The Natural Philosopher wrote:
>>>> On 29/12/2023 20:46, Computer Nerd Kev wrote:
>>>>> In comp.os.linux.misc bad sector <forgetski@_invalid.net> wrote:
>>>
>>> ...
>>>
>>>> If you want a hand held you don't need to do a thing installation,
>>>> Linux Mint is for you.
>>>> If you use their repositories then all code is compatible.
>>>
>>> I understand Mint derives from Ubuntu. What is the advantage? I am
>>> curious, not looking for rant :-)
>>
>> For one, a lot of people hate Canonical.
>> Snap-packages suck apparently.
>> The default desktop environment is also a lot more windows-y than Ubuntu.
>> The community is better.
>
> But they still depend on Ubuntu to generate the packages and the updates?
>
Yes and no.

Mint has its own set of packages from different repositories. Not the
core kernel and basic OS, but the little GUI apps and so on. Looking at
my desktop here everything I can see *on screen* is MINT packages.

Everything underneath is pure ubuntu.

One of the things I liked about it versus Debian, was that it wasn't so
sucky about 'non free' packages.

Multimedia support was built in from the get go on the assumption you
wanted it to work 'out of the box'

--
A lie can travel halfway around the world while the truth is putting on
its shoes.

On 30/12/2023 20:47, Mike Easter wrote:
> Carlos E.R. wrote:
>> candycanearter07 wrote:
>>> Carlos E.R. wrote:
>>>>
>>>> I understand Mint derives from Ubuntu. What is the advantage? I am
>>>> curious, not looking for rant :-)
>>>
>>> For one, a lot of people hate Canonical.
>>> Snap-packages suck apparently.
>>> The default desktop environment is also a lot more windows-y than
>>> Ubuntu.
>>> The community is better.
>>
>> But they still depend on Ubuntu to generate the packages and the updates?
>>
> Mint uses Ub's repo/s and its own, and improves on Ub.
>
> LM's flagship DE is Cinnamon; Ub's is Gnome.  Ub LUVs Snap and uses it
> 'strongly'; LM eschews snap and its default eliminates it in favor of
> providing a default Flatpak capability.  LM has a number of useful
> 'minty' tools.
>
> IMO Mint is a much better v of an Ub -based distro than Ub is; but of
> course LM's success is based on how it is able to use the Ub repo/s.  It
> also does a good job of using the Deb repo/s for its LMDE version which
> I prefer over the parent Deb.  Ub has contributed a lot to being a
> Deb-based distro.
>
> Gnome is my least favorite DE; Cinnamon is one of my favorites.
>
>
MATE is my favourite. Its a bit more workmanlike than Cinnamon, which is
uber sexy - probably sexier than OS/X, but lacks features I got used to.

--
If you tell a lie big enough and keep repeating it, people will
eventually come to believe it. The lie can be maintained only for such
time as the State can shield the people from the political, economic
and/or military consequences of the lie. It thus becomes vitally
important for the State to use all of its powers to repress dissent, for
the truth is the mortal enemy of the lie, and thus by extension, the
truth is the greatest enemy of the State.

Joseph Goebbels

On 2023-12-31 09:52, The Natural Philosopher wrote:
> On 30/12/2023 19:41, Carlos E.R. wrote:
>> On 2023-12-30 20:11, candycanearter07 wrote:
>>> On 12/30/23 13:00, Carlos E.R. wrote:
>>>> On 2023-12-30 10:52, The Natural Philosopher wrote:
>>>>> On 29/12/2023 20:46, Computer Nerd Kev wrote:
>>>>>> In comp.os.linux.misc bad sector <forgetski@_invalid.net> wrote:
>>>>
>>>> ...
>>>>
>>>>> If you want a hand held you don't need to do a thing installation,
>>>>> Linux Mint is for you.
>>>>> If you use their repositories then all code is compatible.
>>>>
>>>> I understand Mint derives from Ubuntu. What is the advantage? I am
>>>> curious, not looking for rant :-)
>>>
>>> For one, a lot of people hate Canonical.
>>> Snap-packages suck apparently.
>>> The default desktop environment is also a lot more windows-y than
>>> Ubuntu.
>>> The community is better.
>>
>> But they still depend on Ubuntu to generate the packages and the updates?
>>
> Yes and no.
>
> Mint has its own set of packages from different repositories. Not the
> core kernel and basic OS, but the little GUI apps and so on. Looking at
> my desktop here everything I can see *on screen* is MINT packages.
>
> Everything underneath is pure ubuntu.
>
> One of the things I liked about it versus Debian, was that it wasn't so
> sucky about 'non free' packages.
>
> Multimedia support was built in from the get go on the assumption you
> wanted it to work 'out of the box'

That's nice.

I'm very much used to rpm, though.

Just considering if I need a replacement for openSUSE, now that "Leap"
is going to disappear, and what remains is the development version,
Tumbleweed or Slowroll.

--
Cheers, Carlos.

On 31/12/2023 14.02, Carlos E.R. wrote:

> I'm very much used to rpm, though.

It has some neat features that I fail to find in deb.

> Just considering if I need a replacement for openSUSE, now that "Leap"
> is going to disappear, and what remains is the development version,
> Tumbleweed or Slowroll.

I don't think there is a difficulty to pick between them, do you want
stability then go with slowroll and if you want the latest possible
package of everything then go tumbleweed, but expect that your system
may not always work 100%.

For me that has kept me from using OpenSuse is the lack of packages.

--
//Aho

On 31/12/2023 13:02, Carlos E.R. wrote:
> On 2023-12-31 09:52, The Natural Philosopher wrote:
>> On 30/12/2023 19:41, Carlos E.R. wrote:
>>> On 2023-12-30 20:11, candycanearter07 wrote:
>>>> On 12/30/23 13:00, Carlos E.R. wrote:
>>>>> On 2023-12-30 10:52, The Natural Philosopher wrote:
>>>>>> On 29/12/2023 20:46, Computer Nerd Kev wrote:
>>>>>>> In comp.os.linux.misc bad sector <forgetski@_invalid.net> wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>> If you want a hand held you don't need to do a thing installation,
>>>>>> Linux Mint is for you.
>>>>>> If you use their repositories then all code is compatible.
>>>>>
>>>>> I understand Mint derives from Ubuntu. What is the advantage? I am
>>>>> curious, not looking for rant :-)
>>>>
>>>> For one, a lot of people hate Canonical.
>>>> Snap-packages suck apparently.
>>>> The default desktop environment is also a lot more windows-y than
>>>> Ubuntu.
>>>> The community is better.
>>>
>>> But they still depend on Ubuntu to generate the packages and the
>>> updates?
>>>
>> Yes and no.
>>
>> Mint has its own set of packages from different repositories. Not the
>> core kernel and basic OS, but the little GUI apps and so on. Looking
>> at my desktop here everything I can see *on screen* is MINT packages.
>>
>> Everything underneath is pure ubuntu.
>>
>> One of the things I liked about it versus Debian, was that it wasn't
>> so sucky about 'non free' packages.
>>
>> Multimedia support was built in from the get go on the assumption you
>> wanted it to work 'out of the box'
>
> That's nice.
>
> I'm very much used to rpm, though.
>
> Just considering if I need a replacement for openSUSE, now that "Leap"
> is going to disappear, and what remains is the development version,
> Tumbleweed or Slowroll.
>
I liked the brief excursion I had with SUSE.
But I always felt the Debian (and offspring) community were more on the ball

--
How fortunate for governments that the people they administer don't think.

Adolf Hitler

On 12/31/23 02:45, The Natural Philosopher wrote:
> On 30/12/2023 19:11, candycanearter07 wrote:
>> On 12/30/23 13:00, Carlos E.R. wrote:
>>> On 2023-12-30 10:52, The Natural Philosopher wrote:
>>>> On 29/12/2023 20:46, Computer Nerd Kev wrote:
>>>>> In comp.os.linux.misc bad sector <forgetski@_invalid.net> wrote:
>>>
>>> ...
>>>
>>>> If you want a hand held you don't need to do a thing installation,
>>>> Linux Mint is for you.
>>>> If you use their repositories then all code is compatible.
>>>
>>> I understand Mint derives from Ubuntu. What is the advantage? I am
>>> curious, not looking for rant :-)
>>
>> For one, a lot of people hate Canonical.
>> Snap-packages suck apparently.
>> The default desktop environment is also a lot more windows-y than Ubuntu.
>> The community is better.
>
> Amen to all that.
> Never understood what a snap package was. Good old apt works for me

Me neither.
--
user <candycane> is generated from /dev/urandom

On 12/31/2023 10:29 AM, candycanearter07 wrote:
> On 12/31/23 02:45, The Natural Philosopher wrote:
>> On 30/12/2023 19:11, candycanearter07 wrote:
>>> On 12/30/23 13:00, Carlos E.R. wrote:
>>>> On 2023-12-30 10:52, The Natural Philosopher wrote:
>>>>> On 29/12/2023 20:46, Computer Nerd Kev wrote:
>>>>>> In comp.os.linux.misc bad sector <forgetski@_invalid.net> wrote:
>>>>
>>>> ...
>>>>
>>>>> If you want a hand held you don't need to do a thing installation, Linux Mint is for you.
>>>>> If you use their repositories then all code is compatible.
>>>>
>>>> I understand Mint derives from Ubuntu. What is the advantage? I am curious, not looking for rant :-)
>>>
>>> For one, a lot of people hate Canonical.
>>> Snap-packages suck apparently.
>>> The default desktop environment is also a lot more windows-y than Ubuntu.
>>> The community is better.
>>
>> Amen to all that.
>> Never understood what a snap package was. Good old apt works for me
>
> Me neither.

It's a contain with its own environment and all dependencies inside.

Somewhere, there's a rule file that controls what directories it
can read or write in the real tree.

Snaps are impossible to debug, so they *must* work, or else.

The following sample, shows some content. It would appear that
hunspell is a separate thing it needs, and it might be a service
of some sort.

*******
It's a squashfs.

The snaps are "mounted", to speed access. A firefox package might be
54MB, and the (compressed) snap is a bit bigger than that.

it has a pipewire directory, meaning sound from Firefox is hooked up.

/var/lib/snapd/seed/snaps/firefox_3216.snap 252,190,720 bytes (squashfs, 7ZIP can read it)

Directory:
d----- 9/29/2023 1:57 PM data-dir
d----- 9/29/2023 1:57 PM gnome-platform
d----- 9/29/2023 1:57 PM meta
d----- 9/29/2023 1:57 PM snap
d----- 3/24/2022 12:14 PM usr
-a---- 9/29/2023 1:57 PM 32441 default256.png
-a---- 9/29/2023 1:57 PM 9146 firefox.desktop
-a---- 9/29/2023 1:57 PM 2470 firefox.launcher
-a---- 9/29/2023 1:57 PM 3716 patch-default-profile.py
Directory: data-dir
d----- 9/29/2023 1:57 PM icons
d----- 9/29/2023 1:57 PM sounds
d----- 9/29/2023 1:57 PM themes
Directory: meta
d----- 9/29/2023 1:57 PM gui
d----- 9/29/2023 1:57 PM hooks
-a---- 9/29/2023 1:57 PM 3616 snap.yaml
Directory: meta\gui
-a---- 9/29/2023 1:57 PM 9154 firefox.desktop
Directory: meta\hooks
-a---- 9/29/2023 1:57 PM 12 configure
-a---- 9/29/2023 1:57 PM 66 connect-plug-host-hunspell
-a---- 9/29/2023 1:57 PM 69 disconnect-plug-host-hunspell
-a---- 9/29/2023 1:57 PM 52 post-refresh
Directory: snap
d----- 9/29/2023 1:57 PM command-chain
d----- 9/29/2023 1:57 PM hooks
-a---- 9/29/2023 1:57 PM 46553 manifest.yaml
-a---- 9/29/2023 1:57 PM 22686 snapcraft.yaml
Directory: snap\command-chain
-a---- 9/29/2023 1:57 PM 149 desktop-launch
-a---- 9/29/2023 1:57 PM 156 hooks-configure-fonts
-a---- 9/29/2023 1:57 PM 541 run
Directory: snap\hooks
-a---- 9/29/2023 1:57 PM 147 connect-plug-host-hunspell
-a---- 9/29/2023 1:57 PM 61 disconnect-plug-host-hunspell
-a---- 9/29/2023 1:57 PM 1200 post-refresh
Directory: usr
d----- 9/29/2023 1:57 PM lib
d----- 9/29/2023 1:57 PM share
Directory: usr\lib
d----- 9/29/2023 1:57 PM firefox
d----- 9/29/2023 1:57 PM x86_64-linux-gnu
Directory: usr\lib\firefox
d----- 9/29/2023 1:57 PM browser
d----- 9/29/2023 1:57 PM defaults
d----- 9/29/2023 1:57 PM distribution
d----- 9/29/2023 1:57 PM fonts
d----- 9/29/2023 1:57 PM gmp-clearkey
-a---- 9/29/2023 12:48 PM 700 application.ini
-a---- 9/29/2023 1:57 PM 183952 crashreporter
-a---- 9/27/2023 10:37 PM 3902 crashreporter.ini
-a---- 9/29/2023 1:54 PM 189 dependentlibs.list
-a---- 9/29/2023 1:57 PM 650640 firefox
-a---- 9/29/2023 1:57 PM 650640 firefox-bin
-a---- 9/29/2023 1:57 PM 71238288 geckodriver
-a---- 9/29/2023 1:57 PM 23000 glxtest
-a---- 9/29/2023 1:57 PM 837976 libfreeblpriv3.so
-a---- 9/29/2023 1:57 PM 506056 libgkcodecs.so
-a---- 9/29/2023 1:57 PM 380072 libipcclientcerts.so
-a---- 9/29/2023 1:57 PM 34872 liblgpllibs.so
-a---- 9/29/2023 1:57 PM 3958728 libmozavcodec.so
-a---- 9/29/2023 1:57 PM 244488 libmozavutil.so
-a---- 9/29/2023 1:57 PM 5960 libmozgtk.so
-a---- 9/29/2023 1:57 PM 113264 libmozsandbox.so
-a---- 9/29/2023 1:57 PM 1240952 libmozsqlite3.so
-a---- 9/29/2023 1:57 PM 10120 libmozwayland.so
-a---- 9/29/2023 1:57 PM 218920 libnspr4.so
-a---- 9/29/2023 1:57 PM 698776 libnss3.so
-a---- 9/29/2023 1:57 PM 539616 libnssckbi.so
-a---- 9/29/2023 1:57 PM 183256 libnssutil3.so
-a---- 9/29/2023 1:57 PM 18576 libplc4.so
-a---- 9/29/2023 1:57 PM 14392 libplds4.so
-a---- 9/29/2023 1:57 PM 155216 libsmime3.so
-a---- 9/29/2023 1:57 PM 326024 libsoftokn3.so
-a---- 9/29/2023 1:57 PM 414280 libssl3.so
-a---- 9/29/2023 1:57 PM 142606392 libxul.so
-a---- 9/29/2023 1:57 PM 1387216 minidump-analyzer
-a---- 9/29/2023 1:57 PM 31642840 omni.ja
-a---- 9/29/2023 1:57 PM 695760 pingsender
-a---- 9/29/2023 1:54 PM 167 platform.ini
-a---- 9/29/2023 1:57 PM 642384 plugin-container
-a---- 9/29/2023 1:57 PM 0 removed-files
-a---- 9/27/2023 10:37 PM 825 Throbber-small.gif
-a---- 9/29/2023 1:57 PM 18720 vaapitest
Directory: usr\lib\firefox\browser
d----- 9/29/2023 1:57 PM chrome
d----- 9/29/2023 1:57 PM features
-a---- 9/27/2023 10:37 PM 787 crashreporter-override.ini
-a---- 9/29/2023 1:57 PM 40567859 omni.ja
Directory: usr\lib\firefox\browser\chrome
d----- 9/29/2023 1:57 PM icons
Directory: usr\lib\firefox\browser\chrome\icons
d----- 9/29/2023 1:57 PM default
Directory: usr\lib\firefox\browser\chrome\icons\default
-a---- 9/27/2023 10:37 PM 13513 default128.png
-a---- 9/27/2023 10:37 PM 722 default16.png
-a---- 9/27/2023 10:37 PM 1948 default32.png
-a---- 9/27/2023 10:37 PM 3448 default48.png
-a---- 9/27/2023 10:37 PM 5459 default64.png
Directory: usr\lib\firefox\browser\features
-a---- 9/29/2023 1:57 PM 138214 formautofill@mozilla.org.xpi
-a---- 9/29/2023 1:57 PM 62247 pictureinpicture@mozilla.org.xpi
-a---- 9/29/2023 1:57 PM 172269 screenshots@mozilla.org.xpi
-a---- 9/29/2023 1:57 PM 30815 webcompat-reporter@mozilla.org.xpi
-a---- 9/29/2023 1:57 PM 423940 webcompat@mozilla.org.xpi
Directory: usr\lib\firefox\defaults
d----- 9/29/2023 1:57 PM pref
Directory: usr\lib\firefox\defaults\pref
-a---- 9/29/2023 1:54 PM 429 channel-prefs.js
Directory: usr\lib\firefox\distribution
d----- 9/29/2023 1:57 PM extensions
d----- 9/29/2023 1:57 PM searchplugins
-a---- 9/29/2023 1:57 PM 397 distribution.ini
Directory: usr\lib\firefox\distribution\extensions
d----- 9/29/2023 1:57 PM locale-en-GB # and many more
d----- 9/29/2023 1:57 PM locale-en-US
Directory: usr\lib\firefox\distribution\extensions\locale-en-GB
-a---- 9/29/2023 1:57 PM 538560 langpack-en-GB@firefox.mozilla.org.xpi
Directory: usr\lib\firefox\distribution\extensions\locale-en-US
-a---- 9/29/2023 1:57 PM 529346 langpack-en-US@firefox.mozilla.org.xpi
Directory: usr\lib\firefox\distribution\searchplugins
d----- 9/29/2023 1:57 PM common
Directory: usr\lib\firefox\distribution\searchplugins\common
-a---- 9/29/2023 1:57 PM 7928 google.xml
Directory: usr\lib\firefox\fonts
-a---- 9/27/2023 10:37 PM 1474284 TwemojiMozilla.ttf
Directory: usr\lib\firefox\gmp-clearkey
d----- 9/29/2023 1:57 PM 0.1
Directory: usr\lib\firefox\gmp-clearkey\0.1
-a---- 9/29/2023 1:57 PM 67992 libclearkey.so
-a---- 9/29/2023 1:54 PM 225 manifest.json
Directory: usr\lib\x86_64-linux-gnu
d----- 9/29/2023 1:57 PM pipewire-0.3
d----- 9/29/2023 1:57 PM spa-0.2
-a---- 2/20/2022 12:14 PM 15 libaom.so.3
-a---- 2/20/2022 12:14 PM 5383376 libaom.so.3.3.0
-a---- 5/19/2022 2:10 AM 24 libavcodec.so.58
-a---- 5/19/2022 2:10 AM 14886880 libavcodec.so.58.134.100
-a---- 5/19/2022 2:10 AM 22 libavutil.so.56
-a---- 5/19/2022 2:10 AM 691088 libavutil.so.56.70.100
-a---- 11/27/2021 7:10 PM 15359024 libcodec2.so.1.0
-a---- 7/19/2023 12:23 PM 16 libcurl.so.4
-a---- 7/19/2023 12:23 PM 677656 libcurl.so.4.7.0
-a---- 9/12/2021 8:35 AM 17 libdav1d.so.5
-a---- 9/12/2021 8:35 AM 1316784 libdav1d.so.5.1.1
-a---- 1/31/2022 1:02 PM 16 libgsm.so.1
-a---- 1/31/2022 1:02 PM 59544 libgsm.so.1.0.19
-a---- 4/4/2022 6:38 AM 14 libmfx.so.1
-a---- 4/4/2022 6:38 AM 51592 libmfx.so.1.35
-a---- 3/24/2022 8:09 AM 19 libmp3lame.so.0
-a---- 3/24/2022 8:09 AM 288840 libmp3lame.so.0.0.0
-a---- 3/24/2022 12:21 PM 21 libnghttp2.so.14
-a---- 3/24/2022 12:21 PM 166256 libnghttp2.so.14.20.1
-a---- 3/24/2022 12:21 PM 16 libnuma.so.1
-a---- 3/24/2022 12:21 PM 48152 libnuma.so.1.0.0
-a---- 9/30/2021 10:28 AM 18 libOpenCL.so.1
-a---- 9/30/2021 10:28 AM 69288 libOpenCL.so.1.0.0
-a---- 3/24/2022 12:28 PM 16 libopus.so.0
-a---- 3/24/2022 12:28 PM 378952 libopus.so.0.8.0
-a---- 8/29/2021 10:45 PM 15 libpci.so.3
-a---- 8/29/2021 10:45 PM 60184 libpci.so.3.7.0
-a---- 11/9/2022 6:12 AM 26 libpipewire-0.3.so.0
-a---- 11/9/2022 6:12 AM 875640 libpipewire-0.3.so.0.348.0
-a---- 3/25/2022 5:57 AM 121864 librtmp.so.1
-a---- 12/12/2022 6:52 AM 18 libsasl2.so.2
-a---- 12/12/2022 6:52 AM 105392 libsasl2.so.2.0.25
-a---- 4/19/2018 2:25 PM 17 libshine.so.3
-a---- 4/19/2018 2:25 PM 43104 libshine.so.3.0.1
-a---- 3/25/2022 5:51 AM 18 libsnappy.so.1
-a---- 3/25/2022 5:51 AM 35184 libsnappy.so.1.1.8
-a---- 3/24/2022 12:20 PM 16 libsoxr.so.0
-a---- 3/24/2022 12:20 PM 199736 libsoxr.so.0.1.2
-a---- 5/23/2023 3:29 AM 19 libspeechd.so.2
-a---- 5/23/2023 3:29 AM 47096 libspeechd.so.2.6.0
-a---- 2/23/2022 8:33 AM 17 libspeex.so.1
-a---- 2/23/2022 8:33 AM 116776 libspeex.so.1.5.0
-a---- 5/19/2022 2:10 AM 24 libswresample.so.3
-a---- 5/19/2022 2:10 AM 133112 libswresample.so.3.9.100
-a---- 3/24/2022 12:13 PM 21 libtheoradec.so.1
-a---- 3/24/2022 12:13 PM 117040 libtheoradec.so.1.1.4
-a---- 3/24/2022 12:13 PM 21 libtheoraenc.so.1
-a---- 3/24/2022 12:13 PM 223536 libtheoraenc.so.1.1.2
-a---- 3/25/2022 5:52 AM 19 libtwolame.so.0
-a---- 3/25/2022 5:52 AM 129096 libtwolame.so.0.0.0
-a---- 3/24/2022 12:20 PM 17 libvdpau.so.1
-a---- 3/24/2022 12:20 PM 18592 libvdpau.so.1.0.0
-a---- 3/24/2022 12:21 PM 15 libvpx.so.7
-a---- 3/24/2022 12:21 PM 15 libvpx.so.7.0
-a---- 3/24/2022 12:21 PM 3176976 libvpx.so.7.0.0
-a---- 9/13/2023 1:57 PM 16 libwebp.so.7
-a---- 9/13/2023 1:57 PM 432688 libwebp.so.7.1.3
-a---- 9/13/2023 1:57 PM 19 libwebpmux.so.3
-a---- 9/13/2023 1:57 PM 47440 libwebpmux.so.3.0.8
-a---- 3/7/2022 9:23 AM 1863256 libx264.so.163
-a---- 9/23/2021 6:47 PM 16071296 libx265.so.199
-a---- 2/9/2022 10:28 AM 14 libXt.so.6
-a---- 2/9/2022 10:28 AM 441760 libXt.so.6.0.0
-a---- 2/15/2020 5:02 PM 18 libxvidcore.so.4
-a---- 2/15/2020 5:02 PM 691200 libxvidcore.so.4.3
-a---- 12/29/2021 9:02 AM 17 libzvbi.so.0
-a---- 12/29/2021 9:02 AM 581328 libzvbi.so.0.13.2
Directory: usr\lib\x86_64-linux-gnu\pipewire-0.3
d----- 9/29/2023 1:57 PM v4l2
-a---- 11/9/2022 6:12 AM 18704 libpipewire-module-access.so
-a---- 11/9/2022 6:12 AM 141584 libpipewire-module-adapter.so
-a---- 11/9/2022 6:12 AM 51472 libpipewire-module-client-device.so
-a---- 11/9/2022 6:12 AM 268560 libpipewire-module-client-node.so
-a---- 11/9/2022 6:12 AM 59664 libpipewire-module-echo-cancel.so
-a---- 11/9/2022 6:12 AM 18704 libpipewire-module-fallback-sink.so
-a---- 11/9/2022 6:12 AM 155336 libpipewire-module-filter-chain.so
-a---- 11/9/2022 6:12 AM 22800 libpipewire-module-link-factory.so
-a---- 11/9/2022 6:12 AM 47376 libpipewire-module-loopback.so
-a---- 11/9/2022 6:12 AM 47376 libpipewire-module-metadata.so
-a---- 11/9/2022 6:12 AM 22800 libpipewire-module-portal.so
-a---- 11/9/2022 6:12 AM 55568 libpipewire-module-profiler.so
-a---- 11/9/2022 6:12 AM 301360 libpipewire-module-protocol-native.so
-a---- 11/9/2022 6:12 AM 416784 libpipewire-module-protocol-pulse.so
-a---- 11/9/2022 6:12 AM 55568 libpipewire-module-protocol-simple.so
-a---- 11/9/2022 6:12 AM 59664 libpipewire-module-pulse-tunnel.so
-a---- 11/9/2022 6:12 AM 22800 libpipewire-module-raop-discover.so
-a---- 11/9/2022 6:12 AM 80144 libpipewire-module-raop-sink.so
-a---- 11/9/2022 6:12 AM 30992 libpipewire-module-rt.so
-a---- 11/9/2022 6:12 AM 30992 libpipewire-module-rtkit.so
-a---- 11/9/2022 6:12 AM 190704 libpipewire-module-session-manager.so
-a---- 11/9/2022 6:12 AM 22800 libpipewire-module-spa-device-factory.so
-a---- 11/9/2022 6:12 AM 14608 libpipewire-module-spa-device.so
-a---- 11/9/2022 6:12 AM 71952 libpipewire-module-spa-node-factory.so
-a---- 11/9/2022 6:12 AM 67856 libpipewire-module-spa-node.so
-a---- 11/9/2022 6:12 AM 22800 libpipewire-module-x11-bell.so
-a---- 11/9/2022 6:12 AM 43280 libpipewire-module-zeroconf-discover.so
Directory: usr\lib\x86_64-linux-gnu\pipewire-0.3\v4l2
-a---- 11/9/2022 6:12 AM 76048 libpw-v4l2.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2
d----- 9/29/2023 1:57 PM aec
d----- 9/29/2023 1:57 PM alsa
d----- 9/29/2023 1:57 PM audioconvert
d----- 9/29/2023 1:57 PM audiomixer
d----- 9/29/2023 1:57 PM audiotestsrc
d----- 9/29/2023 1:57 PM control
d----- 9/29/2023 1:57 PM support
d----- 9/29/2023 1:57 PM test
d----- 9/29/2023 1:57 PM v4l2
d----- 9/29/2023 1:57 PM videoconvert
d----- 9/29/2023 1:57 PM videotestsrc
d----- 9/29/2023 1:57 PM volume
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\aec
-a---- 11/9/2022 6:12 AM 14672 libspa-aec-null.so
-a---- 11/9/2022 6:12 AM 18856 libspa-aec-webrtc.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\alsa
-a---- 11/9/2022 6:12 AM 700584 libspa-alsa.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\audioconvert
-a---- 11/9/2022 6:12 AM 702376 libspa-audioconvert.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\audiomixer
-a---- 11/9/2022 6:12 AM 101304 libspa-audiomixer.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\audiotestsrc
-a---- 11/9/2022 6:12 AM 63728 libspa-audiotestsrc.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\control
-a---- 11/9/2022 6:12 AM 55536 libspa-control.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\support
-a---- 11/9/2022 6:12 AM 22800 libspa-dbus.so
-a---- 11/9/2022 6:12 AM 18672 libspa-journal.so
-a---- 11/9/2022 6:12 AM 117072 libspa-support.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\test
-a---- 11/9/2022 6:12 AM 84208 libspa-test.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\v4l2
-a---- 11/9/2022 6:12 AM 112912 libspa-v4l2.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\videoconvert
-a---- 11/9/2022 6:12 AM 108784 libspa-videoconvert.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\videotestsrc
-a---- 11/9/2022 6:12 AM 55632 libspa-videotestsrc.so
Directory: usr\lib\x86_64-linux-gnu\spa-0.2\volume
-a---- 11/9/2022 6:12 AM 51440 libspa-volume.so
Directory: usr\share
d----- 9/29/2023 1:57 PM hunspell
d----- 9/29/2023 1:57 PM pipewire
Directory: usr\share\hunspell
-a---- 8/16/2021 3:56 PM 32953 en_GB.aff
-a---- 8/16/2021 3:56 PM 1121033 en_GB.dic # and many more
-a---- 1/4/2017 12:53 PM 1000898 en_med_glut.dic
-a---- 1/20/2022 12:16 AM 3131 en_US.aff
-a---- 1/20/2022 12:16 AM 860381 en_US.dic
Directory: usr\share\pipewire
-a---- 11/9/2022 6:12 AM 2816 client-rt.conf
-a---- 11/9/2022 6:12 AM 2535 client.conf
-a---- 11/9/2022 6:12 AM 3160 jack.conf
-a---- 11/9/2022 6:12 AM 12636 minimal.conf
-a---- 11/9/2022 6:12 AM 4992 pipewire-pulse.conf
-a---- 11/9/2022 6:12 AM 9476 pipewire.conf

On 2023-12-31 14:33, J.O. Aho wrote:
> On 31/12/2023 14.02, Carlos E.R. wrote:
>
>> I'm very much used to rpm, though.
>
> It has some neat features that I fail to find in deb.
>
>> Just considering if I need a replacement for openSUSE, now that "Leap"
>> is going to disappear, and what remains is the development version,
>> Tumbleweed or Slowroll.
>
> I don't think there is a difficulty to pick between them, do you want
> stability then go with slowroll and if you want the latest possible
> package of everything then go tumbleweed, but expect that your system
> may not always work 100%.

No, slowroll is just tumbleweed with some delay. I don't call that
stable. It changes fast.

> For me that has kept me from using OpenSuse is the lack of packages.

Lack? What lack? There are many many many packages.

--
Cheers, Carlos.

In comp.os.linux.misc Paul <nospam@needed.invalid> wrote:
> On 12/31/2023 10:29 AM, candycanearter07 wrote:
>> On 12/31/23 02:45, The Natural Philosopher wrote:
>>> Never understood what a snap package was. Good old apt works for me
>>
>> Me neither.
>
> It's a contain with its own environment and all dependencies inside.

The trouble is that those dependencies are stuck at the version in
the Snap package, so they don't get updates applied to libraries
installed via Apt. It's therefore quite possible to end up running
code with known security vulnerabilities even if the version of the
vulnerable library that would have been installed by Apt is up to
date.

I don't know about Snap, but AppImages are similar and aimed at
running on any Linux system. Except they often only run on systems
with a same or newer version of GlibC than the system they were
built on, which means package makers have to use an old GlibC to
ensure wide compatibility, and in turn often an old distro release
with old library versions, which are then bundled into the Snap
complete with their known bugs and vulnerabilities.

AppImages have their place, and maybe Snaps do too, but these
systems are a poor substitute for conventional package management
systems.

--
__ __
#_ < |\| |< _# | Note: I won't see posts made from Google Groups |

On 31/12/2023 20.00, Carlos E.R. wrote:
> On 2023-12-31 14:33, J.O. Aho wrote:
>> On 31/12/2023 14.02, Carlos E.R. wrote:
>>
>>> I'm very much used to rpm, though.
>>
>> It has some neat features that I fail to find in deb.
>>
>>> Just considering if I need a replacement for openSUSE, now that
>>> "Leap" is going to disappear, and what remains is the development
>>> version, Tumbleweed or Slowroll.
>>
>> I don't think there is a difficulty to pick between them, do you want
>> stability then go with slowroll and if you want the latest possible
>> package of everything then go tumbleweed, but expect that your system
>> may not always work 100%.
>
> No, slowroll is just tumbleweed with some delay. I don't call that
> stable. It changes fast.

Sure it's based on tumbleweed, but it's synced every two months and
packages will be bug and security fixed until next update, so you will
get far more stability with slowroll than with tumbleweed.

>> For me that has kept me from using OpenSuse is the lack of packages.
>
> Lack? What lack?  There are many many many packages.

There may be "many" packages, but not the ones I need/want, so for me
it's a big lack compared with running Funtoo.

--
//Aho

On 12/31/23 15:27, Computer Nerd Kev wrote:
> In comp.os.linux.misc Paul <nospam@needed.invalid> wrote:
>> On 12/31/2023 10:29 AM, candycanearter07 wrote:
>>> On 12/31/23 02:45, The Natural Philosopher wrote:
>>>> Never understood what a snap package was. Good old apt works for me
>>>
>>> Me neither.
>>
>> It's a contain with its own environment and all dependencies inside.
>
> The trouble is that those dependencies are stuck at the version in
> the Snap package, so they don't get updates applied to libraries
> installed via Apt. It's therefore quite possible to end up running
> code with known security vulnerabilities even if the version of the
> vulnerable library that would have been installed by Apt is up to
> date.
>
> I don't know about Snap, but AppImages are similar and aimed at
> running on any Linux system. Except they often only run on systems
> with a same or newer version of GlibC than the system they were
> built on, which means package makers have to use an old GlibC to
> ensure wide compatibility, and in turn often an old distro release
> with old library versions, which are then bundled into the Snap
> complete with their known bugs and vulnerabilities.
>
> AppImages have their place, and maybe Snaps do too, but these
> systems are a poor substitute for conventional package management
> systems.

AppImages and Snaps could give some better compatibility, since you can
guarantee every user has the same libs. I see the point about
vulnerabilities, though.
--
user <candycane> is generated from /dev/urandom

On 12/31/2023 6:27 PM, candycanearter07 wrote:
> On 12/31/23 15:27, Computer Nerd Kev wrote:
>> In comp.os.linux.misc Paul <nospam@needed.invalid> wrote:
>>> On 12/31/2023 10:29 AM, candycanearter07 wrote:
>>>> On 12/31/23 02:45, The Natural Philosopher wrote:
>>>>> Never understood what a snap package was. Good old apt works for me
>>>>
>>>> Me neither.
>>>
>>> It's a contain with its own environment and all dependencies inside.
>>
>> The trouble is that those dependencies are stuck at the version in
>> the Snap package, so they don't get updates applied to libraries
>> installed via Apt. It's therefore quite possible to end up running
>> code with known security vulnerabilities even if the version of the
>> vulnerable library that would have been installed by Apt is up to
>> date.
>>
>> I don't know about Snap, but AppImages are similar and aimed at
>> running on any Linux system. Except they often only run on systems
>> with a same or newer version of GlibC than the system they were
>> built on, which means package makers have to use an old GlibC to
>> ensure wide compatibility, and in turn often an old distro release
>> with old library versions, which are then bundled into the Snap
>> complete with their known bugs and vulnerabilities.
>>
>> AppImages have their place, and maybe Snaps do too, but these
>> systems are a poor substitute for conventional package management
>> systems.
>
> AppImages and Snaps could give some better compatibility, since you
> can guarantee every user has the same libs. I see the point about vulnerabilities, though.

That's why the Snaps receive updates.
They can receive updates because the main program is revisioned.
Or they could receive updates if a dependency is revisioned.

You can see a wee bit of an n^2 behavior there.

Snap changes are not tied to apt or Synaptic. Like the MicrosoftStore,
different things are on different schedules.

There used to be an indicator at the top of the screen,
indicating incoming Snaps. Presumably for a user with long uptime,
who would want their Snaps to be secure. There was some complaint
about the way that was behaving, and the precise moment the Snap
update comes in or is applied, may have changed.

For example, if you had Firefox open all day long, perhaps the
replacement Snap for that could not be mounted until Firefox closes.

But the basic idea you would not get vulnerabilities patched,
I don't think that is true. The update behavior might still be
getting adjusted.

I'm not really a fan of Snaps, which is why I'm not all that
interested in staying current on the tiny details. I would prefer
the damn things would just go away. apt works good by me.

My concern about computers, is the freaks are turning out desktops
into smartphones. And that is definitely NOT how I want my expensive
desktop to end up. As a toy for some twit on the Internet.

Paul

On Sun, 31 Dec 2023 08:45:20 +0000, The Natural Philosopher wrote:

> Never understood what a snap package was. Good old apt works for me

I think the whole point behind snap/flatpak/appimage/whatever is to come
up with some equivalent to MSI for Windows, that proprietary app
developers can use.

Open-source developers mostly don’t need to care about the fact that their
software needs to be built into a dozen different package formats to work
with a hundred different distros, because normally the distro maintainers
themselves worry about all that. But proprietary developers want to
control the distribution of their own stuff, so they need to bear the
packaging headaches themselves.

So the question comes down to: do Linux users want proprietary apps?

On Sun, 31 Dec 2023 14:33:40 +0100, J.O. Aho wrote:

> On 31/12/2023 14.02, Carlos E.R. wrote:
>
>> I'm very much used to rpm, though.
>
> It has some neat features that I fail to find in deb.

Can you name one or two?

On 12/31/23 09:45, The Natural Philosopher wrote:
>
> Amen to all that.
> Never understood what a snap package was. Good old apt works for me
>

They're so proprietary software vendors can package their app in a way
that works on all distributions.

In comp.os.linux.misc Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 31 Dec 2023 08:45:20 +0000, The Natural Philosopher wrote:
>> Never understood what a snap package was. Good old apt works for me
>
> I think the whole point behind snap/flatpak/appimage/whatever is to come
> up with some equivalent to MSI for Windows, that proprietary app
> developers can use.

This isn't born out by the list of AppImages available, which
include mostly open-source programs.

> Open-source developers mostly don?t need to care about the fact that their
> software needs to be built into a dozen different package formats to work
> with a hundred different distros, because normally the distro maintainers
> themselves worry about all that.

But packages may not exist if a program is new, and if they do then
the maintainers might be slow to update to new versions, or even
unable to do so because one of the dependency packages isn't a new
enough version (which is what's slowed up releases of Firefox Deb
packages in the past, probably why Snap has become popular for it).

The old solution was using static binaries, which still works great
with the right programs, but libraries inc. GlibC have broken that
option in some circumstances. There are a couple of programs where
I use static binaries published by the software author because
packages aren't available for the distro I want to run them on and
compiling from source presents dependency problems. I may one day
need an AppImage instead, though I'd always prefer a static binary
because it's more efficient and there's less to go wrong.

--
__ __
#_ < |\| |< _# | Note: I won't see posts made from Google Groups |

On 1/1/24 00:53, Paul wrote:
> On 12/31/2023 6:27 PM, candycanearter07 wrote:
>> On 12/31/23 15:27, Computer Nerd Kev wrote:
>>> In comp.os.linux.misc Paul <nospam@needed.invalid> wrote:
>>>> On 12/31/2023 10:29 AM, candycanearter07 wrote:
>>>>> On 12/31/23 02:45, The Natural Philosopher wrote:
>>>>>> Never understood what a snap package was. Good old apt works for me
>>>>>
>>>>> Me neither.
>>>>
>>>> It's a contain with its own environment and all dependencies inside.
>>>
>>> The trouble is that those dependencies are stuck at the version in
>>> the Snap package, so they don't get updates applied to libraries
>>> installed via Apt. It's therefore quite possible to end up running
>>> code with known security vulnerabilities even if the version of the
>>> vulnerable library that would have been installed by Apt is up to
>>> date.
>>>
>>> I don't know about Snap, but AppImages are similar and aimed at
>>> running on any Linux system. Except they often only run on systems
>>> with a same or newer version of GlibC than the system they were
>>> built on, which means package makers have to use an old GlibC to
>>> ensure wide compatibility, and in turn often an old distro release
>>> with old library versions, which are then bundled into the Snap
>>> complete with their known bugs and vulnerabilities.
>>>
>>> AppImages have their place, and maybe Snaps do too, but these
>>> systems are a poor substitute for conventional package management
>>> systems.
>>
>> AppImages and Snaps could give some better compatibility, since you
>> can guarantee every user has the same libs. I see the point about vulnerabilities, though.
>
> That's why the Snaps receive updates.
> They can receive updates because the main program is revisioned.
> Or they could receive updates if a dependency is revisioned.
>
> You can see a wee bit of an n^2 behavior there.
>
> Snap changes are not tied to apt or Synaptic. Like the MicrosoftStore,
> different things are on different schedules.
>
> There used to be an indicator at the top of the screen,
> indicating incoming Snaps. Presumably for a user with long uptime,
> who would want their Snaps to be secure. There was some complaint
> about the way that was behaving, and the precise moment the Snap
> update comes in or is applied, may have changed.
>
> For example, if you had Firefox open all day long, perhaps the
> replacement Snap for that could not be mounted until Firefox closes.
>
> But the basic idea you would not get vulnerabilities patched,
> I don't think that is true. The update behavior might still be
> getting adjusted.
>
> I'm not really a fan of Snaps, which is why I'm not all that
> interested in staying current on the tiny details. I would prefer
> the damn things would just go away. apt works good by me.

Same.

> My concern about computers, is the freaks are turning out desktops
> into smartphones. And that is definitely NOT how I want my expensive
> desktop to end up. As a toy for some twit on the Internet.
>
> Paul

Seems to be how most things are going.
--
user <candycane> is generated from /dev/urandom

On 12/29/23 14:49, bad sector wrote:
> On 12/26/23 06:44, J.O. Aho wrote:
>> On 26/12/2023 02.33, Nomen Nescio wrote:
>>> Fucking just hangs, takes 10 seconds to change tabs....
>>> Why do distro maintaners included these bug-ridden
>>> third-rate apps?
>>
>> For not all have the same experience with the same software, they may
>> be working better depend on hardware or system setup.
>>
>> The beauty of Linux distributions is that they don't force you to use
>> a specific software, the give you multiple options without you need to
>> go to a load of shady download pages where you don't know what malware
>> is included in the installer.
>
> It's better than windows but there should still be more discipline,

https://xkcd.com/927/

> I tend to agree with the OP and there's more. Why on earth do apps like
> kwallet or digicam 'utilities' have to be so inextricably intertwined
> into Plasma or other 'useful' packages?

Are they really inextricable or is it just that nobody has bothered to
extricate them?

Distributions are opinionated by nature. Some are more opinionated than
others; if you don't like it, you go to a different distribution. I just
checked mine and Plasma is split up into about 30 packages; I don't know
which components are in each.

> Accommodatable integratables should NEVER be classified as dependencies.

On 2024-01-02 07:52, Computer Nerd Kev wrote:
> In comp.os.linux.misc Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sun, 31 Dec 2023 08:45:20 +0000, The Natural Philosopher wrote:
>>> Never understood what a snap package was. Good old apt works for me
>>
>> I think the whole point behind snap/flatpak/appimage/whatever is to come
>> up with some equivalent to MSI for Windows, that proprietary app
>> developers can use.
>
> This isn't born out by the list of AppImages available, which
> include mostly open-source programs.

Indeed.

I'm new to this, but the other day I started using fre:ac in appimage
format because it is not available as package on openSUSE.

>> Open-source developers mostly don?t need to care about the fact that their
>> software needs to be built into a dozen different package formats to work
>> with a hundred different distros, because normally the distro maintainers
>> themselves worry about all that.
>
> But packages may not exist if a program is new, and if they do then
> the maintainers might be slow to update to new versions, or even
> unable to do so because one of the dependency packages isn't a new
> enough version (which is what's slowed up releases of Firefox Deb
> packages in the past, probably why Snap has become popular for it).
>
> The old solution was using static binaries, which still works great
> with the right programs, but libraries inc. GlibC have broken that
> option in some circumstances. There are a couple of programs where
> I use static binaries published by the software author because
> packages aren't available for the distro I want to run them on and
> compiling from source presents dependency problems. I may one day
> need an AppImage instead, though I'd always prefer a static binary
> because it's more efficient and there's less to go wrong.
>

Oh, and yes, Linux users do use proprietary software. The most salient
one might be the nvidia drivers.

--
Cheers, Carlos.

On 14/01/2024 12:37, Carlos E.R. wrote:
> On 2024-01-02 07:52, Computer Nerd Kev wrote:
>> In comp.os.linux.misc Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Sun, 31 Dec 2023 08:45:20 +0000, The Natural Philosopher wrote:
>>>> Never understood what a snap package was. Good old apt works for me
>>>
>>> I think the whole point behind snap/flatpak/appimage/whatever is to come
>>> up with some equivalent to MSI for Windows, that proprietary app
>>> developers can use.
>>
>> This isn't born out by the list of AppImages available, which
>> include mostly open-source programs.
>
> Indeed.
>
> I'm new to this, but the other day I started using fre:ac in appimage
> format because it is not available as package on openSUSE.
>
>
>>> Open-source developers mostly don?t need to care about the fact that
>>> their
>>> software needs to be built into a dozen different package formats to
>>> work
>>> with a hundred different distros, because normally the distro
>>> maintainers
>>> themselves worry about all that.
>>
>> But packages may not exist if a program is new, and if they do then
>> the maintainers might be slow to update to new versions, or even
>> unable to do so because one of the dependency packages isn't a new
>> enough version (which is what's slowed up releases of Firefox Deb
>> packages in the past, probably why Snap has become popular for it).
>>
>> The old solution was using static binaries, which still works great
>> with the right programs, but libraries inc. GlibC have broken that
>> option in some circumstances. There are a couple of programs where
>> I use static binaries published by the software author because
>> packages aren't available for the distro I want to run them on and
>> compiling from source presents dependency problems. I may one day
>> need an AppImage instead, though I'd always prefer a static binary
>> because it's more efficient and there's less to go wrong.
>>
>
> Oh, and yes, Linux users do use proprietary software. The most salient
> one might be the nvidia drivers.
>
Theres a lot of interesting transcoders out there whose origins are 'non
free'

--
You can get much farther with a kind word and a gun than you can with a
kind word alone.

Al Capone