Discussion:
Elephant in the room -- utility value.
(too old to reply)
Martha Adams
2018-10-16 05:09:18 UTC
Permalink
I was just reading the nearby Gimp vs Photoshop thread. I think
it moves all around something central. Namely, that interest and
using some software does not require that it be the latest, most
elaborated, largest, most expensive, greatest, and etc. What
counts is its *utility*. Which detail is too often lost and by
being lost leaves the door open to unending elaboration.

"Utility" to me is, can it do what I need in some way that is
accessible and comfortable to me? And for the Photoshop user
in the Gimp vs Photoshop thread, the question is, if she goes
over to Gimp then can she still do the things she needs to do.
If some purchaser of her work *requires* Photoshop then that
settles the question. Else, Gimp may be "inferior" to Photoshop
according to some people by their thinking, but that's actually
off-topic. Which topic is, Gimp's *utility* for the work at
hand.

This Elephant is on my mind now because I've been thinking about
it lately. It has two or more sides. I've been thinking why
don't we have a small fixed Linux that never changes? If I
think about that another side emerges immediately: that such
a Linux gives the several very useful periodicals about Linux,
nothing to do. Etc etc.

Thus the Elephant is there and I think including it in discussions,
would improve the discussions. And I don't think that in the
process, you can throw-out the Luz...Windows, because 1) so very
many people use it; and 2) there's a lot of talent over there and
it's unwise to shut it out. But that's another topic....

Titeotwawki -- Martha Adams [Tues 2018 Oct 16]
Joe Rosevear
2018-10-16 06:47:41 UTC
Permalink
Post by Martha Adams
I was just reading the nearby Gimp vs Photoshop thread. I think
it moves all around something central. Namely, that interest and
using some software does not require that it be the latest, most
elaborated, largest, most expensive, greatest, and etc. What
counts is its *utility*. Which detail is too often lost and by
being lost leaves the door open to unending elaboration.
"Utility" to me is, can it do what I need in some way that is
accessible and comfortable to me? And for the Photoshop user
in the Gimp vs Photoshop thread, the question is, if she goes
over to Gimp then can she still do the things she needs to do.
If some purchaser of her work *requires* Photoshop then that
settles the question. Else, Gimp may be "inferior" to Photoshop
according to some people by their thinking, but that's actually
off-topic. Which topic is, Gimp's *utility* for the work at
hand.
This Elephant is on my mind now because I've been thinking about
it lately. It has two or more sides. I've been thinking why
don't we have a small fixed Linux that never changes? If I
think about that another side emerges immediately: that such
a Linux gives the several very useful periodicals about Linux,
nothing to do. Etc etc.
If I understand what you're saying, and I think I do, then I believe
you have touched on a somewhat odd truth. That truth is that we cannot
always hold onto the past technology.

It is really odd, because very often, I believe, we move forward too
readily. Linux, in general, is something of an antidote to that
poison, but not a perfect one. It is great the way that you can still
use software (like tin, which I'm using now, for example) which is
really old and not much changed for a long time. There is such a
comfort in familiarity and stability. And, of course, Slackware Linux
is perhaps the best in this regard.

Yet some changes, sadly, seem to be necessary. Pulseaudio is an
interesting example, but perhaps not a good one. I was so mad when I
was forced into learning to use pulseaudio. I was comfortable doing
things the old way. Well, I'm gradually learning to use it. I'm not
sure if I'll ever like it. This mostly depends on the programmers. If
they do a good job, then maybe there's hope for it. It *does* seem to
complicate things, but the subject of sound management is complex by
nature, or perhaps it is *becoming* complex.

This is somewhat like what happened with udev which is another thing I
struggle with. Once upon a time we probably didn't need it. Then
suddenly the world was immersed in USB devices. I've got to say, udev
is a deep mystery that I'm only beginning to get a little comfortable
with. Often I deal with it by turning it off (I render it in-operative
by replacing the /etc/udev/rules.d directory with an empty file).

Now Akonadi, on the other hand, I think should just go away. I do not
understand its usefulness. All I know about it is that it is
responsible for generating many Gigabytes of data. This is definitely
not the way I want to use my storage devices. So I wipe the files that
it generates. (See Akonadi link at
http://joeslife.org/links/computing/unixes).

My point I was trying to make was that some change is needed, even
though it is painful. Bummer.

But is there an elephant in the room? Perhaps so.
Post by Martha Adams
Thus the Elephant is there and I think including it in discussions,
would improve the discussions. And I don't think that in the
process, you can throw-out the Luz...Windows, because 1) so very
many people use it; and 2) there's a lot of talent over there and
it's unwise to shut it out. But that's another topic....
Titeotwawki -- Martha Adams [Tues 2018 Oct 16]
--
http://joeslife.org
Sarcastic Fringehead
2018-10-16 12:26:05 UTC
Permalink
On Tue, 16 Oct 2018 06:47:41 +0000, Joe Rosevear wrote:

(snip
Post by Joe Rosevear
Yet some changes, sadly, seem to be necessary. Pulseaudio is an
interesting example, but perhaps not a good one. I was so mad when I
was forced into learning to use pulseaudio.
Suppose you're throwing a party at your estate this weekend. You want
all the computers, in the main house, the guest house, the boathouse,
etc. to all play the same music at the same time from a central music
server. That's the problem pulseaudio was designed to solve.

What's that? You say you're not throwing a party at your estate this
weekend? Then maybe pulseaudio is not for you (or me). I never had any
problems with audio via ALSA.

(snip)
Post by Joe Rosevear
Now Akonadi, on the other hand, I think should just go away. I do not
understand its usefulness. All I know about it is that it is
responsible for generating many Gigabytes of data.
Agreed. Nepomuk too. KDE4 has driven away many users, like me.
Programmers scratching their own itch. There are products at the drugstore
for problems like that.
jrg
2018-10-16 16:05:33 UTC
Permalink
On 10/16/2018 05:26 AM, Sarcastic Fringehead wrote:
<snip>
Post by Sarcastic Fringehead
Programmers scratching their own itch. There are products at the drugstore
for problems like that.
post needs a C&C :)
Richard Kettlewell
2018-10-16 07:55:09 UTC
Permalink
Post by Martha Adams
I was just reading the nearby Gimp vs Photoshop thread. I think
it moves all around something central. Namely, that interest and
using some software does not require that it be the latest, most
elaborated, largest, most expensive, greatest, and etc. What
counts is its *utility*. Which detail is too often lost and by
being lost leaves the door open to unending elaboration.
"Utility" to me is, can it do what I need in some way that is
accessible and comfortable to me? And for the Photoshop user
in the Gimp vs Photoshop thread, the question is, if she goes
over to Gimp then can she still do the things she needs to do.
If some purchaser of her work *requires* Photoshop then that
settles the question. Else, Gimp may be "inferior" to Photoshop
according to some people by their thinking, but that's actually
off-topic. Which topic is, Gimp's *utility* for the work at
hand.
This Elephant is on my mind now because I've been thinking about
it lately. It has two or more sides. I've been thinking why
don't we have a small fixed Linux that never changes?
There are long-term support branches of several distributions. But they
need maintenance effort - if you just abandon them then the collection
of known vulnerabilities will gradually grow and hardware support will
get out of date. Moreover that effort increasingly falls on the
integrators as upstream developers lose interest in old versions of the
code (they only have finite capacity, after all).

And if the feature you need isn’t in an LTS release, then it’s no use to
you...
--
https://www.greenend.org.uk/rjk/
Peter Chant
2018-11-28 22:02:50 UTC
Permalink
Post by Richard Kettlewell
And if the feature you need isn’t in an LTS release, then it’s no use to
you...
I'm also thinking of the example where you have two applications, A & B
that both share dependency C. A has worked fine for you for the last
decade any you can't see a reason to change it for the next decade, but
you need the features in the latest version of B. But to run B you must
upgrade the common dependency C which then breaks the first package A.

I was hoping that I could make that explanation simpler.

Pete
Mike Spencer
2018-11-29 07:40:17 UTC
Permalink
Post by Peter Chant
And if the feature you need isn't in an LTS release, then it's no
use to you...
I'm also thinking of the example where you have two applications, A & B
that both share dependency C. A has worked fine for you for the last
decade any you can't see a reason to change it for the next decade, but
you need the features in the latest version of B. But to run B you must
upgrade the common dependency C which then breaks the first package A.
I was hoping that I could make that explanation simpler.
Make perfect sense.

If I understand correctly, in some cases you could compile the older
libs into the old A, then upgrade to system libs needed by new B.

Won't work if you don't have source (say, Netscape) or the source libs
don't allow for it (Allegro 4 game programming library).

And of course, "dependencies" have become such a can of worms -- far
beyond just the libs -- that I have to genuflect whenever I think of
Pat and what it takes to sort them all out.
--
Mike Spencer Nova Scotia, Canada
Eli the Bearded
2018-11-29 19:10:43 UTC
Permalink
Post by Mike Spencer
If I understand correctly, in some cases you could compile the older
libs into the old A, then upgrade to system libs needed by new B.
Won't work if you don't have source (say, Netscape) or the source libs
don't allow for it (Allegro 4 game programming library).
I've been able to sort that out sometimes by having separate trees
of files and dependencies for different programs. Tell everything I need
for program X to configure for install in /usr/local/programX/, possibly
with shell script wrappers setting LD_LIBRARY_PATH. It eats disk, but
it gets you pretty far.

I recently became aware of Nixos. That distro takes this idea to an
extreme, with versioned installs of everything and boot selection
chooses which set of files to use. It's probably not a distro most
Slackware users would want to switch to, but it's certainly something to
learn from:

https://nixos.org/

My exposure to this came when I was searching for a way to get current
Google Chrome to run on (years out of date) Centos 6 for $WORK. Using
a tool developed for Nixos, I was able to get the whole parallel library
thing to work for Chrome *even going so far as replacing glibc just for
that program*. This is a large step beyond where I've ever gone before
with this system.

Here's where I found out how to do it:

https://intoli.com/blog/installing-google-chrome-on-centos/

I downloaded the install-google-chrome.sh and ran it (cut-n-paste)
slowly by hand to understand it. The steps where it finds and installs
dependencies would need to be different on Slack, but conceptually
remain the same.

The nixos `patchelf` program was a vital part of it working.

Elijah
------
very impressed by the technique
Mike Spencer
2018-11-30 03:52:24 UTC
Permalink
Post by Eli the Bearded
Post by Mike Spencer
If I understand correctly, in some cases you could compile the older
libs into the old A, then upgrade to system libs needed by new B.
Won't work if you don't have source (say, Netscape) or the source libs
don't allow for it (Allegro 4 game programming library).
I've been able to sort that out sometimes by having separate trees
of files and dependencies for different programs. Tell everything I need
for program X to configure for install in /usr/local/programX/, possibly
with shell script wrappers setting LD_LIBRARY_PATH. It eats disk, but
it gets you pretty far.
I recently became aware of Nixos. That distro takes this idea to an
extreme, with versioned installs of everything and boot selection
chooses which set of files to use. It's probably not a distro most
Slackware users would want to switch to, but it's certainly something to
https://nixos.org/
Interesting. Saved for reference. I have a really old version of
Maple that I'd dink around with occasionally but it needs really old
libs. I managed to get it working afterone Slack upgrade, then wimped
out on the next. Maybe I shd look at it again.
Post by Eli the Bearded
My exposure to this came when I was searching for a way to get current
Google Chrome to run on (years out of date) Centos 6 for $WORK. Using
a tool developed for Nixos, I was able to get the whole parallel library
thing to work for Chrome *even going so far as replacing glibc just for
that program*. This is a large step beyond where I've ever gone before
with this system.
https://intoli.com/blog/installing-google-chrome-on-centos/
I downloaded the install-google-chrome.sh and ran it (cut-n-paste)
slowly by hand to understand it. The steps where it finds and installs
dependencies would need to be different on Slack, but conceptually
remain the same.
The nixos `patchelf` program was a vital part of it working.
Elijah
------
very impressed by the technique
--
Mike Spencer Nova Scotia, Canada
Lew Pitcher
2018-11-29 14:26:46 UTC
Permalink
Post by Peter Chant
Post by Richard Kettlewell
And if the feature you need isn’t in an LTS release, then it’s no use to
you...
I'm also thinking of the example where you have two applications, A & B
that both share dependency C. A has worked fine for you for the last
decade any you can't see a reason to change it for the next decade, but
you need the features in the latest version of B. But to run B you must
upgrade the common dependency C which then breaks the first package A.
That's where the various loader options, and "versioned" shared-object files
come in. It /is/ possible to run application A with a different version of
shared-object library C than application B uses. You do not need to static
link library C to application A to ensure compatibility.
Post by Peter Chant
I was hoping that I could make that explanation simpler.
--
Lew Pitcher
"In Skills, We Trust"
Richard Kettlewell
2018-11-29 15:26:00 UTC
Permalink
Post by Lew Pitcher
Post by Peter Chant
Post by Richard Kettlewell
And if the feature you need isn’t in an LTS release, then it’s no use to
you...
I'm also thinking of the example where you have two applications, A & B
that both share dependency C. A has worked fine for you for the last
decade any you can't see a reason to change it for the next decade, but
you need the features in the latest version of B. But to run B you must
upgrade the common dependency C which then breaks the first package A.
That's where the various loader options, and "versioned" shared-object files
come in. It /is/ possible to run application A with a different version of
shared-object library C than application B uses. You do not need to static
link library C to application A to ensure compatibility.
It’s true, and it goes on all the time. But it only gets you so far.
Firstly not all dependencies are shared libraries. Config files, shared
data files and kernel userspace API are other examples (although Linux
is generally pretty good at the last one). Secondly it’s hard or
impossible to compose across these versions: if my application depends
on version 1 of a library and some plugin library depends on version 2,
they cannot normally be mixed in the same process.

Anyway the original spec was “a small fixed Linux that never
changes”. If you’re introducing newer versions of fundamental system
libraries (e.g. libc), even if they’re backward-compatible with, or
co-installed with, older versions, then you no longer have a Linux that
never changes.
--
https://www.greenend.org.uk/rjk/
Peter Chant
2018-11-29 20:47:27 UTC
Permalink
Post by Richard Kettlewell
Anyway the original spec was “a small fixed Linux that never
changes”. If you’re introducing newer versions of fundamental system
libraries (e.g. libc), even if they’re backward-compatible with, or
co-installed with, older versions, then you no longer have a Linux that
never changes.
I'm thinking, if it is a critical app for you then run it in a virtual
machine. However, I'm only just getting in to that as my previous
machine, though it ought to have been powerful enough, was too laggy on
the UI to do that. Not an trivial solution if sharing data necessarily.*

* Yes it is you say - but I although I've got plan9 running on an MX
linux guest I cannot get it to work on a lubuntu guest.



Pete
Loading...