by goprisko » May 13th, '13, 17:31
I found a better way:
I removed all references to UUIDs in boot & grub & fstab, replacing them with LABEL=yyyysssssxxxxx
Now, I have a solid way to reference partitions in my 5 drive system, with identifiers immediately and obviously connected to specific partitions.
AND
The system boots properly and fast.
Now, to other upgrading issues:
Earlier, I was forced to go outside the Mageia repositories for applications critical to my needs:
CAD, Scanning of slides and film, processing RAW Image Files, Color Correcting Images, Office software
LibreOffice 4 is a case in point. The Mg2 upgrade to LO.3.5 involves pulling packages including rpm and many system libraries.
Yet, when one goes to the LO repository, fetches the package, and installs it, no such changes to the basic system are necessary.
This tells me that, in bringing Linux to the functional level Mg2 represents, the UNIX client - server model was not maintained. Instead the Microsoft monolithic model was introduced.
It was well known to us in the Systems Engineering Community, that Microsoft's model was drastically inferior to the UNIX client-server model.
In the UNIX model, all applications use system services for printing, input, output, memory management, backup, restore, and other purposes.
Applications do not, and are not allowed to access system level functions except through the API. Applications are assigned their own address space by the
kernel, and those which violate this, are memfaulted, and terminated.
Earlier, I specifically mentioned that applications should be statically linked. This was denigrated in favor of the Microsoft model. In the UNIX model
applications can and often are broken into multiple executables, with VueScan being a case in point. Yes, it is 12 Mb, vs Xsane at 0.6 Mb, but that's
only the tip of this iceberg:
bash-4.2|bash
desktop-common-data|desktop-common-data-2012.0
glibc-2.16.90|glibc
lib64glib2.0_0-2.34.1|lib64glib2.0_0
lib64gobject2.0_0-2.34.1|lib64glib2.0_0
lib64gtk+-x11-2.0_0|lib64gtk+2.0_0-2.24.13
lib64jpeg8-1.2.1|lib64jpeg8
lib64lcms1|lib64lcms1-1.19
lib64png15_15|lib64png15-1.5.12
lib64sane1|lib64sane1-1.0.23
lib64tiff5-4.0.2|lib64tiff5
lib64z1-1.2.7|lib64uClibc-zlib1|lib64zlib1
xsane
Of no small matter is the fact that Vuescan does a much better job of scanning slides and film than xsane, unless one is willing to spend days adjusting parameters.
Of no other small matter is the fact that Vuescan can be placed in it's own directory in /opt and obviously linked to /usr/local/lib.
Since the /opt links are obvious, it is not a problem to police them following a restore from backup media.
Since the app is monolithic, if there is something wrong with it, one need only upgrade it, not the whole system. Likewise, if the system needs upgrading
the apps don't. As long as the API remains intact, the apps work. I, for example have migrated Vuescan from Mdk2008 -> Mg2 by simply installing the
bin in /opt and linking it to /usr/local/bin and updating the Kde menu system each time.
To summarize:
My post directly concerns issues with updating Mg2 -> Mg3. My issues concern the architecture of the system, which affect it's maintainability, and
robustness. My issues no longer are concerned with functionality. Mg2 solved the functionality issues of Linux, hands down. It's functional to the point
it is a direct and complete replacement on the desktop for any Microsoft OS.
My issue specifically is that in progressing to this point, a house that jack built has been created, and gerrymandered as it is, errors cascade through it,
making debugging a formidable task. I have been, and below will use specific examples of this. The solution is to return to the UNIX client-server model
for applications, and to enforce applications using system resources through the API, and only the API, and to enforce boundaries around each application, so any given app in totality can be contained within it's own bin, which is linked to /usr/local/bin. That's right /usr/local/bin. Only system binaries belong
in /usr/bin. Specifically Xsane is an app. LibreOffice is a suite of apps. cp, dd, tar, dar, etc; are system utilities. Apps in /usr/local/bin Utilities in /usr/bin
Apps call utilities through the API. If you have a security problem in any given utility, you fix that, and load the new version without causing cascade replacement of hundreds of other binaries.
Once you implement this discipline, you will find your job of debugging much easier.
Now to the last example: /etc/alternatives & Java:
When /etc was created it was a catchall of items required by system binaries at various times. Fstab is a case in point. Fstab is used during boot to
tell the kernel where to find the drives, and is used during operation to grant/deny mounting permissions to users, and to specify mounting attributes. It is a table, originally hand built, later built with system utilities. Were alternatives embodied in such a table, I'd have no issues here. But alternatives was
implemented via symlinks, as follows:
Directory Sym Link
/etc/alternatives/java -> /usr/lib/jvm/default/
/usr/lib/jvm/default -> /etc/alternatives/default -> /usr/java/default -> /usr/java/latest -> /usr/java/jre1.7.0_21
/usr/lib/jvm/java -> /etc/alternatives/java_sdk/
Now, it is really nice that a utility maintains this, but: This utility doesn't have the job of maintaining the system, including restoring it in the event of disaster. I do.
Since the alternatives are alternatives for applications such as java, and utilities such as gcc, I'd prefer /usr/alternatives. This way, the symlinks are in one file system and restoring that filesystem restores the links.
Java could look like this:
/usr/alternatives/java/default -> /usr/java/jre1.7.0_21
/usr/alternatives/java/java_sdk_1.6.0 -> /usr/java/java-1.6.0-openjdk.x86_64/
Much clearer. Easier to debug. Easier to maintain.
INDY
It's a pseudo-filesystem, representing internal kernel information and settings via sysfs.
