[Gllug] Hacker Attack

Nix nix at esperi.org.uk
Thu Jan 12 07:39:16 UTC 2006


On Thu, 12 Jan 2006, Mike Brodbelt whispered secretively:
> On Thu, 2006-01-12 at 00:01 +0000, Bruce Richardson wrote:
> 
>> Well, even where a kernel was built using kernel-package, it isn't
>> necessarily easy to tell precisely how it was built just from
>> /boot/config and the auto-generated files in
>> /usr/share/doc/kernel-image.  Any number of gruesome and unstable
>> patches might have been applied with little or no external evidence.
> 
> Yes - odd patches are a nightmare.

Personally, even on my home systems I keep patches for everything in
a rigidly structured form; if there's nothing in a package's diffs/
directory, there are no applied patches. (Some packages add extra
complexity below there, e.g. those I'm working on and thus rolling
much more elaborate changes to.)

(Of course this isn't documented, but these are my *home* systems!
The analogue on the systems at work is documented. Nobody, as far
a I can tell, has ever read the documentation, *sigh*... I should
learn to growl more easily when people come begging with questions
that RTFM would answer.)

>> Then there is the "spare kernel", where some bright boy installs a new
>> kernel on a system without doing anything to verify that it is suitable.

ARGH KILL

>> Does it provide all the required features?  Will it even boot?  Nobody
>> knows, but the magic of package management and automatically managed
>> grub configuration is likely to have made it the default kernel and a
>> lovely surprise for somebody at some unknown point in the future.

... made the *default*? Oh what joy.

> One of the worst bits of sysadmin is all the stuff that should be done
> to provide a robust environment that makes no perceptible difference
> (until something blows up), but takes up a lot of time

And this is where the `curse of the gifted' really does kick in: the
smarter you are the more likely you are to put it off because of
course you can fix the problem when it happens in about five minutes.

And then it happens and you're on holiday and you get a frantic phone
call...

> don't appreciate why we package stuff though - they just think its a
> pain because they can't install the software on every junk screensaver
> CD they get in the post.

`This is a feature, not a bug'.

(We do things that way at work, as well, with centrally pushed changes.
It took *forever* to get permission to install things off my own bat on
my machine, because the centrally installed set didn't include things
like Cygwin or any of the dev environments I'm actually supposed to be
doing my job with, *sigh*)

>> Rolling custom kernels can give very definite benefits if done with
>> some thought.  Building custom application installs from source is less
>> often useful (most distributions provide perfectly good packages that
>> not only do the job but are usefully integrated with the rest of the
>> system)
> 
> I used to build some stuff from source. for small gains. These days I do
> it reluctantly, and only if necessary. Where I do it at all, I
> build .debs an install from them, and I mark them with a version suffix.

I wrote my own autobuilder and to some extent my own package manager.
(What? Why does the world need another one? Whyever would you ask that?
Honestly, you'll be asking why the world needs another text editor or
another mountain next.)

>> Unfortunately, these things are done all the time by people who have
>> given it no thought at all but who do it on principle, because they
>> think that a) these activities have intrinsic value and b) that it shows
>> how skilled they are.
> 
> One day they'll have to pick up after someone with the same attitude....

Of course I package things properly at work, but I consider my home net
in part an experimental testbed for doing things they'd never let me
try at work.

-- 
`I must caution that dipping fingers into molten lead
 presents several serious dangers.' --- Jearl Walker
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list