Still having trouble with package upgrades

[David Jackson]

On Wed, Mar 7, 2012 at 11:58 AM, Polytropon <freebsd at edvax.de> wrote:

> David, allow me to add a few thoughts:
>
> On Wed, 7 Mar 2012 11:28:47 -0500, David Jackson wrote:
> > As for compile options, the solution is simple, compile in all feature
> > options and the most commonly used settings into the binary packages, for
> > the standard i386 CPU.
>
> I think this can develop into a major problem in certain
> countries where listening to MP3 is illegal. :-)
>
>
You are talking about the codec.

What Ubuntu seems to do is distribute these codecs as a seperate nonfree
addon package which are then loaded by applications at run time. You see,
options do not necessarily have to be compiled into programs, they can be
loaded at libraries and then loaded by programs at run time if they are
available.

This is also a rare circumstance, and there are workaround as above.


>
> > If people want customisations then they can build
> > the software for themselves.
>
> That's what they'll do anyway. :-)
>
>
No, usually they do not. Few people except for hard core geeks want to mess
around with compile options. most will use runtime configuration through a
GUI which is faster.


> Especially on systems low on resources, compiling from
> source is _the_ way to squeeze every required (!) bit
> of performance out of code. Even if compiling may require
> some time (due to optimization flags), the result can
> be really usable.
>
>
>
> > When a new kernel is released, there is no reason to reinstall all of the
> > packages on the system at the same time. Since the kernel and userland
> > packages have different development cycles, there is no reason why there
> > has to be synchronization of the upgrading.
>
> It sometimes is neccessary, for example if kernel interfaces
> have changed. There is some means of compatibility provided by
> the compat_ ports. But if you start upgrading things, libraries
> can break, and the system may become unstable (in terms of not
> being able of running certain programs anymore). Just see how
> "kernel and world are out of sync" errors can even cause the
> system to stop booting. Degrading the inner workings of the OS
> to "just another package" can cause trouble. "Simple updates"
> as they are often performed on Linux systems can render the
> whole installation totally unusable because "something minor"
> went wrong. :-)
>
>
>
A well designed system will provide backwards compatability through various
strategies and this does not necessarily need to affect internal software
design as the backwards compatability can also be provided by compatability
layers and glue code.

Programs communicate with the kernel via interrupts, pushing arguments for
the system call onto the stack. The format of this closely matches the
source code API. The API is used with the system calling convention. These
are mostly mature and do not need to change much. Considering it also a bad
practice to create an incompatable system API, there is little reason to
change the system call interface. The system call interface has little
impact on internal kernel except where adding a new feature can require
additional kernel code. Most system calls are mature and do not need to
change much. If a system call is needed to provide new functionality, a new
system call can be added, which can if needed duplicate the functionality
of an older system call.

There is also ELF and binary code linking and calling conventions. This can
also be maintained to be backwards compatability, if necessary through the
use of compatability layers and glue in this process.

Another strategy that is unlikely to be needed, since there really is not
much reason to make non backwards compatable changes to the current system
call set,  and is only now used for Linux binary compatability is to mark a
binary for a certain system call interface, that system call interface can
be backed by glue code to the the main kernel interfaces.

Other means of communicating with the kernel which are possible include the
/proc interface and as as well UNIX domain sockets. Again if the format of
these needs to changed in a non backwards compatable way, a new file or
socket can be created at a new location for the new version, the old file
or socket location would provide the old interface backed by glue code to
the new interface.

It is possible to provide backwards compatability through compatability
layers and glue code like this, without in anyway impacting the internal
design of a kernel or other software system.




>
> > An OS that requires a user to reinstall
> > everything just to upgrade the kernel is not user friendly.
>
> Why do consider a user being supposed to mess with kernels?
> This question can show that I'm already too old: Programs
> are for users, kernels are for sysadmins. Sysadmins do stuff
> properly, even if they shoot their foot in order to learn
> an important lesson. :-)
>
>
Users have to upgrade the kernel, with a well designed OS this is a process
that does not require any sort of problems for the user. Since good kernel
backwards compatability strategies will assure that the new kernel will
drop into place of the old one without causing problems.

Kernel upgrading should be done through the main package update tool and
the kernel itself distributed as a package, as Ubuntu does it. This is also
how Windows Update does it as well. It can be done automatically with
automatic updates and the user does not need to worry about it.

Not everyone who uses an OS is a system administrator. Do you really think
that anyone who owns an Ipad or has a home desktop computer should be
required just to apply a kernel upgrade? The good thing is that kernel
upgrades do not need a system administrator. A well designed kernel will
not be so problematic that this will be required.


> As I said before: Updating the kernel _may_ cause many "dependency
> programs" (the userland and often the installed 3rd party
> applications) to become target of updating in order to keep
> their functionality. New kernel interfaces, changes in ABI
> or API, new libraries, as well as obsoleted things may be
> a valid (!) reason.
>
>
>
Dependancy problems will not exist if the kernel development follows sound
strategies for backwards compatability, which can include providing a
compatability layer with glue code, which means backwards compatability
need not necessarily affect the internals of the software system.

>
>
>
> --
> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...
>