Why does it take the debian-7.3.0-i386-lxde-CD-1.iso installer so long to install inside a VirtualBox VM?

Why does it take the debian-7.3.0-i386-lxde-CD-1.iso installer so long to install inside a VirtualBox VM?

Oleg Goldshmidt pub at goldshmidt.org
Thu Jan 9 12:03:56 IST 2014


"E.S. Rosenberg" <esr+linux-il at g.jct.ac.il> writes:

> Debian does that too, that still doesn't change the fact that the
> system needs to know which version of config to use, you don't want
> apache, squid or any other program to revert to vanilla state after
> you worked hard on configuring it (even if you can replace your custom
> config in a second, between it hapenning and you noticing you have
> 'down time').
>
> Also you want to know when new configs come because even when you
> choose to keep your own the old sometimes is incompatible with the new
> so you will actually know that something may go wrong.

You can find the %config(noreplace) algorithm in the docs or on the web
easily. Most of the time it does the right thing to deal with both these
problems.

The admin is well advised after an update to check what
*.{rpmnew,rpmsave} files were created (perusing either the log or
locate(1)) and clean up, which typically consists of removing the
unnecessary files, unless the original config was edited and at the same
time the new config is so incompatible with the old version that the
latter should be replaced.

To that end, check out:

* rpmconf(1) # yum install rpmconf

  It is a standalone tool.

* yum-plugin-merge-conf 
 
  This is a yum plugin that I *believe* launches an interactive
  diff/merge tool after update.

I have never tried either, so no recommendation. I just know they exist.

> And restarting services without asking the admin is that really
> something you want to be default? You can tell it to behave like that,
> but handle with care Windows tends to do stuff like that and everyone
> curses it for it (rightly so).

\begin{rant}

Oh, the number of war stories I could tell about variations on the
brilliant idea that if a service crashes it should be restarted
automatically! Making a service that does not crash is often considered
too difficult/expensive compared to a "watchdog". It is then discovered
that it may not be easy to distinguish between a service that crashed
due to a bug and a service killed by the admin, thus much ingenuity
applies, with limited success.

I myself was asked to write such a thing at least twice, against my own
strongly worded advice. I did, investing in a configuration system that
allowed the watchdog to do different things on a per service basis, thus
accompanied by user documentaton, etc. I still put a warning IN CAPITALS
that the solution (in both cases) was not reliable and could really piss
off customers. Not sure if the warning ever appeared in the user
manuals though. ;-)

In short: don't. The owner of root permissions will exact his revenge
when you least expect it.

\end{rant}

In addition, restarting a service may be an overkill. Many a
well-behaved daemon will reload configuration on a HUP or USR signal,
without restarting/downtime. Apache does, for instance.

-- 
Oleg Goldshmidt | pub at goldshmidt.org



More information about the Linux-il mailing list