[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Firmware stuff - was systemd fight



On Mon, 3 Mar 2014, Andrei POPESCU wrote:


On Lu, 03 mar 14, 13:56:45, Bret Busby wrote:

Apart from the systemd fight stuff, I am wondering, in the context
of the above message content, why a spearate firmware distribution
of Debian Linux, needs to exist, rather than the firmware being
included in the offical Debian version.

http://www.debian.org/social_contract
Important are specifically point 1. (of course) and DFSG 2., since for
most firmware the source is not available.

Also, and I do not know how applicable this is, to what is
happening, I wonder why Debian does not provide backward
compatibility with previous versions of Debian; why provision is not
made, to allow software that runs on Debian 5, to run on Debian 6
and Debian 7.

Because this quickly becomes a maintenance nightmare. This is just my
rough understanding, but I'm sure others will correct me if I'm wrong:

1. freeze the "base" system (system libraries and so)
This is what Microsoft has been doing with XP. This seamed to work well
for a while, except that at some point, no matter how many Service Packs
they applied to it, the OS was simply not be able to cope with the
changes around it. Eventually software programmers will want to use new
features of their languages and libraries, but over time this becomes
increasingly difficult and even impossible. And let's not forget about
deep (possible security related) bugs in the underlying system that just
can't be fixed by simple patches that don't affect the applications on
top.

2. Keep multiple versions of libraries around
Debian does that to some extent, but (depending on the library and how
the upstream developers handle changes to it) it quickly becomes too
difficult to maintain. The amount of maintenance work needed is likely
to increase geometrically or even exponentially with the number of
concurrent versions, and don't forget that the maintainer most likely
already has 3 (three) versions to care about: oldstable, stable and
testing/sid.

3. Extend the support times for a release
This is not really a solution, because at some point you will just end
up with 1., but if you're "lucky" this will give the developers of the
old software to migrate to the newer libraries, or the need will just go
away (as per your example below, the hardware gets replaced).



I think that it is unfortunate that we are apparently expected to throw out all of our hardware (including printers and other such accessories), and, replace it all, each time a new version of an operating system, is released.

The MFP thing, as far as I am aware (I have not yet been able to use all of its functionality, due to the Debian policy regarding firmware), is still all working okay (well, it scans and prints, as well as it can, with the limited functionality of the operating system.

But, I had understood that the purpose of creating UNIX (and, Linux IS supposed to be a "UNIX-like" operating system), was to have available an operating system, upon which software would run without requiring modification to adapt to the underlying platform.

Thus, from what I understood, as a crude example, a program written in "C", would include library and function calls, to standard libraries, and could happily operate, if it was written in UNIX "C", on any installation of UNIX, on any hardware platform.

That should be relatively simple - the preservation of the standard libraries, and, the standard functions, with standard functionalities, which could be expanded, if needed, but, at the same time, preserving the standard functionalitites and libraries.

I think that the problem that has occurred, is that, instead, mutations have been imposed, so that functions and libraries, have instead, been renamed or, replaced, in order to impose obsolescence, rather than to maintain functionality.

It seems to be "Who needs functionality, when we have all of these whistles and bells? They might not serve any useful purpose, but, they catch your attention."

We are aware (I think, and, I believe) that Microsoft, in order to force sales of its products, designs operating system and application software, versions, that are not backward compatible, so as to force sales, so that it can keep "squeezing blood out of a stone", requiring people to be continually buying software that they should not need.

But, Linux, and, the Linux community, should not have the same objective; it should instead, be preserving the (that I believe to be) primary objective of UNIX; that a programme that is written for one version, can run on any version, unless it is harmful, in which case, it gets blocked, and the user/administrator, notified.

If I write a FORTAN 4 program, I expect it to be able to run on a FORTRAN 77 platform, or, a FORTRAN 90 platform (I do not know what is the current latest ANSI standard version of FORTRAN - my FORTRAN programming ended, when FORTRAN 90 was just a proposal), otherwise, I would regard the subsequent platform on which it would not run, as defective.

Similarly, if I wrote a program in UNIX "C", I woud expect it to run on any version of UNIX, and, hopefully, Linux, that was created at or after the same time as the UNIC "C" development environment.

I have a photovoltaic inverter output data logging program, that is apparently written for MS Windows XP (the only version of the particular programme, of which I am aware). If that would not run on MS Windows version 7 (from what I have seen of MS Windows 8, about the best analogy to MS Windows 8, of which I can think, is that it reminds me of what we used to shovel out of the yard, after the cows were milked, except, the stuff that we used to shovel out of the yard, after the cows were milked, was useful, and, out of it, coud grow, useful things), I would regard MS Windows 7, as defective.

If nothing else, MS Windows 7, in the case of the photovoltaic output data logging software programme, and, similarly, Linux, in the case of drivers, should be able to run an instance of the programme, in an emulation of the earlier version of the operating system, on the curent version of the operating system, in a virtual machine, or something, if it would not run "natively" in the later version of the operating system.

But, I see no reason why a later version of an operating system, should not be able to natively run software written for an earlier version of the operating system, with, if needed, protections inbuilt into the later version of the operating system.

The lack of that backward compatibility, is probably the cause of most of the problems encountered with current operating systems - "This functionality is gone! It does not work anymore!".

--
Bret Busby
Armadale
West Australia
..............

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
  Chapter 28 of Book 1 of
  "The Hitchhiker's Guide to the Galaxy:
  A Trilogy In Four Parts",
  written by Douglas Adams,
  published by Pan Books, 1992
....................................................


Reply to: