Linux

[TheIdeasMan]

Here's an article, where the author explains his experience with Windows and Linux over the years. It's a bit dated, I gather about 2010'ish. Even though things have improved at MS, I think the underlying theme about the shenanigans with MS still rings true. And yes, it does talk about backwards compatibility and dependencies and all the other topics we have been debating.

http://members.apex-internet.com/sa/windowslinux/index.html

And?? We're talking about the system libraries, here. Of course they're reusable, they're the system libraries. Sorry, I don't understand where you're going. Please state your argument explicitly.

As explained earlier:

TheIdeasMan wrote:

The RedHat PM appears to give the exact opposite advice: Don't provide 1 pkg for your program, provide pkgs for the reusable components of your program; Don't combine your packages with what others have already packaged; Don't re-package what is already packaged.

So software pkgs and the library files they install are supposed to be small and highly reusable as well. Rather than bundle library files into a relatively big pkg, have lots of small reusable library files. Over time, this results in less library files being needed. Linux puts these library files in one place so all the software can use them.

Linux doesn't need a complex linking procedure because, except maybe for RH, none of the distributions care at all about backwards compatibility.

What makes you say this? In my experience, it's been more like they don't worry about backwards compatibility because they know there will nearly always be compatibility.

If you're constantly breaking binaries anyway, there's no point in providing a way to ensure that old binaries continue to link dynamically in the future.

And what do you mean by "breaking binaries" ? Is it that a library dependency is missing? If so, that's not true - as I have said several times, the installation makes sure all the dependencies are there, they don't disappear.

Nice double standard, there. A feature works exactly the same in two systems, but it's a hack in one but not in the other?

As already explained, Linux doesn't need a huge list in the PATH variable, because all the executables (or links to them) are in one directory. So needing to have lots of things in a PATH variable, in the right order could be construed as being a hack. Well it's certainly a lot more complex anyway. So this goes back to the Windows philosophy again: We will put our software under this folder, and add another entry into the PATH. Sounds easy enough to start with but gets out of hand quickly.

We're complaining about PATH itself and the way it's used by the system and abused by developers. The complaint would be equally valid if PATH was stored in a text file.

This whole discussion started with complaints about the Linux directory structure, I have explained several times about the simplicity of the Linux PATH and the directory structure, but now I am confused: are you talking about Windows PATH now? If you are talking about Linux, then I don't see why you have a problem with something so simple.

Yes, let's ignore the several times I've said other Unices such as FreeBSD and MacOS are better.

And we have managed to disagree for the best part of a week?

LB wrote:

There is neither a need for binary files nor a need for GUI applications. In my ideal system, managing these things would be done through system API calls. Then you can use whatever program or code you want. The underlying representation of them is an implementation detail that may change between versions of the system.

So in your ideal system, there are no binary files, so there must be ASCII files somewhere - I wonder if they are human readable/editable? If so, then that is what Linux does now. If not, and considering one must use API functions, then that is 1 skerrick away from what Windows does now - A GUI program that deals with the registry. I say this because no user or administrator is going to want to write code in order to configure something. Why bother with code when one can just edit a text file? Sure if someone provides a GUI to help modify that file, then that's nice, but it's not absolutely required for everything. The Windows / Linux philosophy again.

LB wrote:

These 'standard locations' you talk about are exactly what started this whole discussion, remember? I don't like mixing everything together like that. The ideal way to delect the default version of Python is to make sure it comes first in PATH, but when you mix everything together you make it much more difficult.

No, you have your Windows hat on still :+) See above for the explanation about directory structure and the PATH environment variable. It's not difficult, it's actually easy. The whole point of having all the small executables or link to executables in /usr/bin , is so that any user can run programs they are entitled to run, without having untold entries in the PATH variable.

With python:
My /usr/bin has these versions of python : python, python2, python2.7, python3.0, python3.2 and there are configuration files for them. There is also a version in the crunch-bang line, all scripts should have this, so then the system will use the correct version, no user intervention required. The crunch-bang line uses whatever file is specified, just like a shell script. So #!/usr/bin/python as in the example by ne555 much earlier, would use that file.

python2.7-conf:

#!/usr/bin/python2.7

import sys
import os
import getopt
from distutils import sysconfig

valid_opts = ['prefix', 'exec-prefix', 'includes', 'libs', 'cflags',
              'ldflags', 'extension-suffix', 'help']

def exit_with_usage(code=1):
    print >>sys.stderr, "Usage: %s [%s]" % (sys.argv[0],
                                            '|'.join('--'+opt for opt in valid_opts))
    sys.exit(code)

try:
    opts, args = getopt.getopt(sys.argv[1:], '', valid_opts)
except getopt.error:
    exit_with_usage()

if not opts:
    exit_with_usage()

pyver = sysconfig.get_config_var('VERSION')
getvar = sysconfig.get_config_var

opt_flags = [flag for (flag, val) in opts]

if '--help' in opt_flags:
    exit_with_usage(code=0)

for opt in opt_flags:
    if opt == '--prefix':
        print sysconfig.PREFIX

    elif opt == '--exec-prefix':
        print sysconfig.EXEC_PREFIX

    elif opt in ('--includes', '--cflags'):
        flags = ['-I' + sysconfig.get_python_inc(),
                 '-I' + sysconfig.get_python_inc(plat_specific=True)]
        if opt == '--cflags':
            flags.extend(getvar('CFLAGS').split())
        print ' '.join(flags)

    elif opt in ('--libs', '--ldflags'):
        libs = getvar('LIBS').split() + getvar('SYSLIBS').split()
        libs.append('-lpython' + pyver + (sys.pydebug and "_d" or ""))
        # add the prefix/lib/pythonX.Y/config dir, but only if there is no
        # shared library in prefix/lib/.
        if opt == '--ldflags':
            if not getvar('Py_ENABLE_SHARED'):
                libs.insert(0, '-L' + getvar('LIBPL'))
            libs.extend(getvar('LINKFORSHARED').split())
        print ' '.join(libs)

    elif opt == '--extension-suffix':
        print (sys.pydebug and "_d" or "") + sysconfig.get_config_var('SO')

[LB]

TheIdeasMan wrote:

So in your ideal system, there are no binary files, so there must be ASCII files somewhere

Stop jumping to conclusions. I said there was no need, I didn't say there would not be. For someone who uses C++ I would expect you to underastand 'implementation details' better: you do not and should not need to know or care. Both Windows and *nix get this wrong by making implementation details part of their public interface.

TheIdeasMan wrote:

A GUI program that deals with the registry. I say this because no user or administrator is going to want to write code in order to configure something.

You say this as if terminals do not exist. Don't you already need to do most things via the terminal anyway?

TheIdeasMan wrote:

My /usr/bin has these versions of python : python, python2, python2.7, python3.0, python3.2 and there are configuration files for them.

What a mess! I've already stated that I don't like this at all. Putting the version number in the filename is like putting the file type in the filename (which Windows does). Make up your mind: do you want metadata in the filename or not!?

[Ispil]

...what would your proposed solution be, then, to having a bunch of different-versioned files on the same system? Somewhere there has to be a distinguishing factor where the filestructure says which version you're referring to, and I'd sure as hell not prefer that to be at the bottom of the tree.

[helios]

Rather than bundle library files into a relatively big pkg, have lots of small reusable library files. Over time, this results in less library files being needed. Linux puts these library files in one place so all the software can use them.

How is does this relate to the system libraries, which are always installed and can't be used across OS versions?

In my experience, it's been more like they don't worry about backwards compatibility because they know there will nearly always be compatibility.

I thought at that point it was clear that "backwards compatibility" refers to "backwards binary compatibility".

And what do you mean by "breaking binaries" ?

It means just that. Your binaries (*your* binaries. Those that you built) are likely to stop linking dynamically after a system upgrade because of ABI changes in basic system runtimes, and they will most certainly not work when simply copied to other machines.

As already explained, Linux doesn't need a huge list in the PATH variable, because all the executables (or links to them) are in one directory. So needing to have lots of things in a PATH variable, in the right order could be construed as being a hack. Well it's certainly a lot more complex anyway. So this goes back to the Windows philosophy again: We will put our software under this folder, and add another entry into the PATH. Sounds easy enough to start with but gets out of hand quickly.

If your applications are compartmentalized, you also don't need a huge PATH, because you can just rely on all the dependencies being available on the working directory. On Windows PATH is only used to facilitate invoking utilities from the command line from any working directory, which for most people is entirely useless, and even for programmers only a handful of paths are needed.
Some developers abuse this functionality and don't provide an option to turn off adding stuff to PATH in installers. An alternative to this garbage pileup is providing a script that properly sets the environment when the user executes it. This is what VS has been doing for the command line toolkit for several years.

This whole discussion started with complaints about the Linux directory structure, I have explained several times about the simplicity of the Linux PATH and the directory structure, but now I am confused: are you talking about Windows PATH now?

LB replied to a side comment I made about PATH and I replied back in agreement, then you jumped in. Are you unable to discern when people are replying to you?

[ne555]

> The ideal way to select the default version of Python is to make sure it
> comes first in PATH
given that your PATH would be enormous, that sounds awful.

> but when you mix everything together you make it much more difficult.
consider ~/usr/bin to be first in PATH.
Let's say that /usr/bin/python points to the 2.7 version, but you want 2.5. Then you do ln --symbolic --force /usr/bin/python.2.7 ~/usr/bin/python
So ~/usr/bin would be filled with your beloved symlinks pointing to the programs whose version are different than the defaults in /usr/bin (all identified by the always userful version numbers in the filenames)


Please provide rationale for your dislike of version numbers and symlinks.


> Somewhere there has to be a distinguishing factor where the filestructure
> says which version you're referring to
It's on the path /Apps/program_name/version/executable

> With python:
> My /usr/bin has these versions of python : python, python2, python2.7,
> python3.0, python3.2
I would not consider python2 and python3 different versions, they work with a different programming language.
So you've got python3.0 and python3.2

> There is also a version in the crunch-bang line, all scripts should have
> this, so then the system will use the correct version
disagree, the scripts shouldn't care about what versions you have in your system, they just simply say "I use python".
Consider that you put python2.5 but the user has 2.7, your script will fail because it can't find the interpreter, but the version in your system should work (the thing is how to resolve in the cases were that isn't true)

> So #!/usr/bin/python as in the example by ne555 much earlier,
> would use that file.
my example was #!/usr/bin/env python because python may not be in /usr/bin, perhaps it is in /usr/local/bin or /opt or ~/usr/bin
with that it will look for it on the PATH.

[ne555]

I seem to have problems with the `Edit' feature.
When it says

then you do ln --symbolic --force /usr/bin/python.2.7 ~/usr/bin/python

It should say

then you do ln --symbolic --force /usr/bin/python.2.5 ~/usr/bin/python2

[LB]

@Ispil: I already posted my preferred solution: in the Python directory is a bunch of directories which are named after the version they contain.

@ne555 I don't dislike symlinks. I do dislike metadata in the file name.

[TheIdeasMan]

@ne555

my example was #!/usr/bin/env python because python may not be in /usr/bin, perhaps it is in /usr/local/bin or /opt or ~/usr/bin
with that it will look for it on the PATH.

Ah! Well that is even better, I agree wholeheartedly with what you are saying.

It appears that we both disagree with LB. I still thing that he is applying "Windows Thinking" to a problem that really doesn't exist in Linux. Being able to use different versions of something is trivially solved by making a link, as ne555 has pointed out, specifically not having to put a version number in a script. The programs are installed in a directory with a version, so that suggestion of a new way and better way of doing it, is already happening. On my system there are /usr/lib64/python2.7 and /usr/lib64/python3.2 directories which have a subtree that is the installation. The respective executables or links in /usr/bin are small files (12KB) which must be aware of how to use the other files in /usr/lib64. The purpose of having lots of small executables or links in a bin directory, is so that anyone can run any program they are entitled to run, from anywhere, without having an outrageous PATH.

Stop jumping to conclusions. I said there was no need, I didn't say there would not be. For someone who uses C++ I would expect you to underastand 'implementation details' better: you do not and should not need to know or care. Both Windows and *nix get this wrong by making implementation details part of their public interface.

Well, I can't argue with that. The reason being that, no matter how much I quote you, put forth a logical argument, prove something or otherwise attempt to persuede you, I will be wrong because the ideal and imaginary system that exists in your head will always be right. I can't argue the merits of Linux against something that doesn't exist. I commend you for having a vision of what you expect the ideal system would look like, but IMO it is wrong to dislike something because it looks foreign to you, or doesn't fit your expectations.

You say this as if terminals do not exist. Don't you already need to do most things via the terminal anyway?

Not at all. I can be just like a typical Windows user, I use the software I have - and that's it, no worrying or even caring about details. Seen as I am the only one who uses my Laptop, I can use a bunch of GUI programs that do system admin tasks. I could go for months without using the terminal. If I want to set up a PostgreSQL server, well yes, I need a terminal for that. But once it's going, I can use the GUI PGIIIAdmin program. I have built some software using the terminal, as described earlier, but that is because my distro is so old. If I do what I am supposed to, and upgrade every 6 months, then I can just use the Software Management and other GUI Admin tools to do everything.

[LB]

TheIdeasMan wrote:

a problem that really doesn't exist in Linux

If this problem didn't exist then you wouldn't need version numbers in file names. Clearly the problem is there and it has been 'solved' by making a sacrifice. Since you weren't the one to solve it you might not even notice it being there.

TheIdeasMan wrote:

Well, I can't argue with that. The reason being that, no matter how much I quote you, put forth a logical argument, prove something or otherwise attempt to persuede you, I will be wrong because the ideal and imaginary system that exists in your head will always be right. I can't argue the merits of Linux against something that doesn't exist. I commend you for having a vision of what you expect the ideal system would look like,

You are not wrong, you just have an opinion that I do not share. If I said you were wrong, it was by accident. From my perspective, we're just sharing our opinions and experiences (I thought that was the point of this thread?).There is no right opinion so we are just having a discussion and I am very much enjoying it :)

TheIdeasMan wrote:

but IMO it is wrong to dislike something because it looks foreign to you, or doesn't fit your expectations.

It is not foreign to me - I have spent a very long time thinking about these things. You and others have adapted to these things that I believe should not need adapting to. Computers and computing in general have changed drastically over the years, and to me it seems many of the original decisions are no longer good decisions even if they were good at the time they were made.

Basically my belief is that old decisions are no longer the best decisions - technology has just changed too much for that to be the case.

TheIdeasMan wrote:

ot at all. I can be just like a typical Windows user, I use the software I have - and that's it, no worrying or even caring about details. Seen as I am the only one who uses my Laptop, I can use a bunch of GUI programs that do system admin tasks. I could go for months without using the terminal. If I want to set up a PostgreSQL server, well yes, I need a terminal for that. But once it's going, I can use the GUI PGIIIAdmin program. I have built some software using the terminal, as described earlier, but that is because my distro is so old. If I do what I am supposed to, and upgrade every 6 months, then I can just use the Software Management and other GUI Admin tools to do everything.

I sure wish it was that simple. My experience with both Windows and *nix is that once a week I usually run into some weird issue and when I Google it, the solution involves running commands or editing files. If it weren't for that I would only use the terminal for git and cmake.

[Ispil]

...you have a dislike for using the command line in Linux for anything other than git or cmake. I'm starting to think that the fundamental problem here isn't lying with Linux.

[LB]

Ispil wrote:

...you have a dislike for using the command line in Linux for anything other than git or cmake. I'm starting to think that the fundamental problem here isn't lying with Linux.

That's not what I said. I have a dislike for fixing things that should not have been broken in the first place. I only want to use the terminal for programs that are easier to use in it.

@htirwin: package managers are convenient indeed, I just wish they didn't have to use so much metadata :\

[TheIdeasMan]

@LB

It appears that you have your own considered philosophy - I am fine with that :+) Maybe one day we will see LB.OS being available for global use !

Cheers & Regards