Links & Thoughts & Stuff

Gerade auf das Security Release 2.2.3 aktualisiert.

@schoeppchen: Direkt auf der Shell :-p

So treffend! Ich hab mich (teilweise) wiedererkannt … wer noch?

Linux ist nichts für dich. Lass es. jetzt lesen.

This site is dedicated to showing demonstrative videos produced by our community. For many subjects seeing something done is the most effective way to learn, whether it’s peering over an expert’s shoulder while they explain how to program or watching while someone grinds beans and makes coffee.

Featuring currently over 100 Video-Tutorials on topics like Java or Blender I’m pretty sure this site has something for everyone and will be a complete success.

So it’s up to you to make it successfull Visit ShowMeDo now and learn something new!

The problem: a number of people are working on the same (set of) CSS file(s) for a web site, and strict class and id naming standards have not been created and enforced. This has led to a proliferation of somewhat meaningful but overall ambiguous labels for CSS ids and classes and selectors. Some of the selectors conflict with each other, and these overlapping declarations are causing unexpected results in the page rendering. Your task is two fold:

• create a list of the selectors of all CSS rules from every CSS file
• find out which declarations possibly conflict with each other so they can be examined manually to see if the conflict can be resolved and/or the CSS file can be optimized by consolidating declarations

This sounds very simple at first, but the article is really hard stuff. Read the complete article Optimizing CSS definitions at thwartedefforts and be prepared to meet some exotic regular expressions and linux commands you may never have heard of

For a while, Debian was the community Linux darling. In its heyday, Debian was known for its strong moral point of view and its outstanding code. Numerous important distributions, such as Linspire, Knoppix, and today’s most popular distribution, Ubuntu, have sprung from it. Things have changed.

Is Debian dying?

Und um das gebührend zu feiern anbei das Original Releasenote des Kernels 0.01, veröffentlicht vor genau 15 Jahren am 17. September 1991 auf der Mailingliste comp.os.minix:

Notes for linux release 0.01

0. Contents of this directory

linux-0.01.tar.Z	- sources to the kernel
bash.Z			- compressed bash binary if you want to test it
update.Z		- compressed update binary
RELNOTES-0.01		- this file

1. Short intro

This is a free minix-like kernel for i386(+) based AT-machines.  Full
source is included, and this source has been used to produce a running
kernel on two different machines.  Currently there are no kernel
binaries for public viewing, as they have to be recompiled for different
machines.  You need to compile it with gcc (I use 1.40, don't know if
1.37.1 will handle all __asm__-directives), after having changed the
relevant configuration file(s).

As the version number (0.01) suggests this is not a mature product.
Currently only a subset of AT-hardware is supported (hard-disk, screen,
keyboard and serial lines), and some of the system calls are not yet
fully implemented (notably mount/umount aren't even implemented).  See
comments or readme's in the code.

This version is also meant mostly for reading - ie if you are interested
in how the system looks like currently.  It will compile and produce a
working kernel, and though I will help in any way I can to get it
working on your machine (mail me), it isn't really supported.  Changes
are frequent, and the first "production" version will probably differ
wildly from this pre-alpha-release.

Hardware needed for running linux:
- 386 AT
- VGA/EGA screen
- AT-type harddisk controller (IDE is fine)
- Finnish keyboard (oh, you can use a US keyboard, but not
without some practise  

The Finnish keyboard is hard-wired, and as I don't have a US one I
cannot change it without major problems. See kernel/keyboard.s for
details. If anybody is willing to make an even partial port, I'd be
grateful. Shouldn't be too hard, as it's tabledriven (it's assembler
though, so ...)

Although linux is a complete kernel, and uses no code from minix or
other sources, almost none of the support routines have yet been coded.
Thus you currently need minix to bootstrap the system. It might be
possible to use the free minix demo-disk to make a filesystem and run
linux without having minix, but I don't know...

2. Copyrights etc

This kernel is (C) 1991 Linus Torvalds, but all or part of it may be
redistributed provided you do the following:

- Full source must be available (and free), if not with the
distribution then at least on asking for it.

- Copyright notices must be intact. (In fact, if you distribute
only parts of it you may have to add copyrights, as there aren't
(C)'s in all files.) Small partial excerpts may be copied
without bothering with copyrights.

- You may not distibute this for a fee, not even "handling"
costs.

Mail me at "torvalds@kruuna.helsinki.fi" if you have any questions.

Sadly, a kernel by itself gets you nowhere. To get a working system you
need a shell, compilers, a library etc. These are separate parts and may
be under a stricter (or even looser) copyright. Most of the tools used
with linux are GNU software and are under the GNU copyleft. These tools
aren't in the distribution - ask me (or GNU) for more info.

3. Short technical overview of the kernel.

The linux kernel has been made under minix, and it was my original idea
to make it binary compatible with minix. That was dropped, as the
differences got bigger, but the system still resembles minix a great
deal. Some of the key points are:

- Efficient use of the possibilities offered by the 386 chip.
Minix was written on a 8088, and later ported to other
machines - linux takes full advantage of the 386 (which is
nice if you /have/ a 386, but makes porting very difficult)

- No message passing, this is a more traditional approach to
unix. System calls are just that - calls. This might or might
not be faster, but it does mean we can dispense with some of
the problems with messages (message queues etc). Of course, we
also miss the nice features :-p.

- Multithreaded FS - a direct consequence of not using messages.
This makes the filesystem a bit (a lot) more complicated, but
much nicer. Coupled with a better scheduler, this means that
you can actually run several processes concurrently without
the performance hit induced by minix.

- Minimal task switching. This too is a consequence of not using
messages. We task switch only when we really want to switch
tasks - unlike minix which task-switches whatever you do. This
means we can more easily implement 387 support (indeed this is
already mostly implemented)

- Interrupts aren't hidden. Some people (among them Tanenbaum)
think interrupts are ugly and should be hidden. Not so IMHO.
Due to practical reasons interrupts must be mainly handled by
machine code, which is a pity, but they are a part of the code
like everything else. Especially device drivers are mostly
interrupt routines - see kernel/hd.c etc.

- There is no distinction between kernel/fs/mm, and they are all
linked into the same heap of code. This has it's good sides as
well as bad. The code isn't as modular as the minix code, but
on the other hand some things are simpler. The different parts
of the kernel are under different sub-directories in the
source tree, but when running everything happens in the same
data/code space.

The guiding line when implementing linux was: get it working fast. I
wanted the kernel simple, yet powerful enough to run most unix software.
The file system I couldn't do much about - it needed to be minix
compatible for practical reasons, and the minix filesystem was simple
enough as it was. The kernel and mm could be simplified, though:

- Just one data structure for tasks. "Real" unices have task
information in several places, I wanted everything in one
place.

- A very simple memory management algorithm, using both the
paging and segmentation capabilities of the i386. Currently
MM is just two files - memory.c and page.s, just a couple of
hundreds of lines of code.

These decisions seem to have worked out well - bugs were easy to spot,
and things work.

4. The "kernel proper"

All the routines handling tasks are in the subdirectory "kernel". These
include things like 'fork' and 'exit' as well as scheduling and minor
system calls like 'getpid' etc. Here are also the handlers for most
exceptions and traps (not page faults, they are in mm), and all
low-level device drivers (get_hd_block, tty_write etc). Currently all
faults lead to a exit with error code 11 (Segmentation fault), and the
system seems to be relatively stable ("crashme" hasn't - yet).

5. Memory management

This is the simplest of all parts, and should need only little changes.
It contains entry-points for some things that the rest of the kernel
needs, but mostly copes on it's own, handling page faults as they
happen. Indeed, the rest of the kernel usually doesn't actively allocate
pages, and just writes into user space, letting mm handle any possible
'page-not-present' errors.

Memory is dealt with in two completely different ways - by paging and
segmentation.  First the 386 VM-space (4GB) is divided into a number of
segments (currently 64 segments of 64Mb each), the first of which is the
kernel memory segment, with the complete physical memory identity-mapped
into it.  All kernel functions live within this area.

Tasks are then given one segment each, to use as they wish. The paging
mechanism sees to filling the segment with the appropriate pages,
keeping track of any duplicate copies (created at a 'fork'), and making
copies on any write. The rest of the system doesn't need to know about
all this.

6. The file system

As already mentioned, the linux FS is the same as in minix. This makes
crosscompiling from minix easy, and means you can mount a linux
partition from minix (or the other way around as soon as I implement
mount  . This is only on the logical level though - the actual
routines are very different.

NOTE! Minix-1.6.16 seems to have a new FS, with minor
modifications to the 1.5.10 I've been using. Linux
won't understand the new system.

The main difference is in the fact that minix has a single-threaded
file-system and linux hasn't. Implementing a single-threaded FS is much
easier as you don't need to worry about other processes allocating
buffer blocks etc while you do something else. It also means that you
lose some of the multiprocessing so important to unix.

There are a number of problems (deadlocks/raceconditions) that the linux
kernel needed to address due to multi-threading.  One way to inhibit
race-conditions is to lock everything you need, but as this can lead to
unnecessary blocking I decided never to lock any data structures (unless
actually reading or writing to a physical device).  This has the nice
property that dead-locks cannot happen.

Sadly it has the not so nice property that race-conditions can happen
almost everywhere.  These are handled by double-checking allocations etc
(see fs/buffer.c and fs/inode.c).  Not letting the kernel schedule a
task while it is in supervisor mode (standard unix practise), means that
all kernel/fs/mm actions are atomic (not counting interrupts, and we are
careful when writing those) if you don't call 'sleep', so that is one of
the things we can count on.

7. Apologies  

This isn't yet the "mother of all operating systems", and anyone who
hoped for that will have to wait for the first real release (1.0), and
even then you might not want to change from minix.  This is a source
release for those that are interested in seeing what linux looks like,
and it's not really supported yet.  Anyone with questions or suggestions
(even bug-reports if you decide to get it working on your system) is
encouraged to mail me.

8. Getting it working

Most hardware dependancies will have to be compiled into the system, and
there a number of defines in the file "include/linux/config.h" that you
have to change to get a personalized kernel.  Also you must uncomment
the right "equ" in the file boot/boot.s, telling the bootup-routine what
kind of device your A-floppy is.  After that a simple "make" should make
the file "Image", which you can copy to a floppy (cp Image /dev/PS0 is
what I use with a 1.44Mb floppy).  That's it.

Without any programs to run, though, the kernel cannot do anything. You
should find binaries for 'update' and 'bash' at the same place you found
this, which will have to be put into the '/bin' directory on the
specified root-device (specified in config.h). Bash must be found under
the name '/bin/sh', as that's what the kernel currently executes. Happy
hacking.

Linus Torvalds		"torvalds@kruuna.helsinki.fi"
Petersgatan 2 A 2
00140 Helsingfors 14
FINLAND

For all of you who have to perform some basic operations on a linux shell but don’t know the correct commands this link is very useful:

http://tipp.bar-games.de/

Here you find an overview and description to nearly every command and how it works. Furthermore there is a section for Linux tipps which provides answers to common questions like:

How many files contains a certain directory?

This is a new wiki for administrators in german. Oli, something for you?

Dies ist das Wiki für alle Administratoren! Tragt Euer Wissen zusammen und schöpft aus dem Erfahrungsschatz Anderer!
Da dies ein Wiki ist, kann JEDER neue Seiten anlegen und vorhandene ändern!

AdminWiki

Just discovered a cool site InstaLinux where you can build your own unattend-installation ISO image for the following distributions:

• Debian 3.1 i386
• Debian 3.2 i386
• Fedora Core 4 i386
• Fedora Core 4 x86_64
• SuSE 10.0 – i386
• SuSE 10.0 – x86_64
• SuSE 9.3 – i386
• SuSE 9.3 – x86_64
• Ubuntu Breezy – i386
• Ubuntu Hoary – i386

This morning I generated a Debian 3.1 ISO image and what should I say – it worked perfectly.

The only thing I missed was post-boot actions to take place (e.g. configuring some things unatteneded when logged into the system first).

So if you need a standard system without any special install-treatments (such as RAID Systems, kernel modules to be loaded at boot-time via shell, …) you can use this to save a lot of keyboard strikes when installing many systems.

BlackDog is a fully self-contained computer with a built-in biometric reader and a host of other powerful features. Unlike any other computing device, BlackDog is completely powered off of the USB port of your host computer – no external power adapter required!

To access and use your BlackDog, you merely plug it in to your host computer’s USB port and BlackDog takes over! Your host machine’s monitor, keyboard, mouse, and Internet connection are taken over by BlackDog for the duration of your session, when you are done, you simply remove BlackDog and everything on the host is returned to its original state.

Black Dog is so extremely cool!

Check out the demo video. If I only had the smallest clue what to do with such a device I’d buy it.

Hmmm, this sounds a lot like advertisement, but I’m just too impressed to be objective