Re: Timeouts beim sshd/FreeBSD 6.0: remote login unmoeglich ...

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Tue, 10 Jan 2006 16:57:01 +0100 (CET)

Alvar Freude <alvar(at)a-blast.org> wrote:
> -- Oliver Fromme <olli(at)lurza.secnetix.de> wrote:
> > Und Du bist auch sicher, daß Du der einzige bist, der die
> > IP 83.142.84.130 verwendet? In /etc/messages findest Du
> > Meldungen, falls freeBSD feststellt, daß ein anderer ver-
> > sucht, dieselbe IP zu verwenden.
>
> sicher nicht, aber in /etc/messages steht nichts und auch bei netstat -i
> wurden keine Kollisionen angezeigt.

Die Kollisionen, die »netstat -i« anzeigt, beziehen sich
auf das Medium, in diesem Fall Ethernet. Wenn zwei Sta-
tionen in einer Broadcast-Domain gleichzeitig versuchen,
einen Ethernet-Frame zu senden, gibt das eine solche Kolli-
sion. In einem geswitchten Netz mit Fullduplex sollte
sowas nicht passieren können.

Jetzt etwas off-topic ...

> da bin ich schon skeptischer; das was ich von Python gesehen habe war
> dann doch auch etwas verwirrend ;)

Es ist halt eine etwas modernere Sprache mit moderneren
Konzepten. Verwirrend ist am Anfang jede Sprache, die man
nicht kennt. ;-)

> Perl wird ja oft unterschätzt

sed(1) wird auch oft unterschätzt und als Suchen-Ersetzen-
Tool mißbraucht. Auch awk(1) wird häufig unterschätzt und
lediglich als eine Art besseres grep(1) oder cut(1) einge-
setzt.

Man kann sowas eigentlich über viele Tools sagen.

> und als eine Art Shell-Ersatz gesehen;

Naja, eine Shell oder Batch-Sprache ist es eher nicht, da-
für fehlen ein paar typische Eigenschaften. Auch Python
ist nicht als Shell oder Batch-Sprache konzipiert (obgleich
man es so verwenden kann, wenn man mag, und außerdem gibt
es noch »ipython«).

> es wird erst richtig interessant, wenn man mal umfangreicher damit arbeitet,
> das CPAN nutzt, POD, Test-Suiten baut und so weiter :)

Das muß ich gelegentlich tun -- leider. Ich würde behaup-
ten, daß ich mich sowohl mit Perl als auch mit Python recht
gut auskenne. Je komplexer die Sachen sind, die man machen
muß (und je größer das Team ist, das an einem Projekt ar-
beitet), desto abschreckender ist Perl. Das sind meine Er-
fahrungen aus der Praxis.

> > tcsh --> zsh
>
> das ist mir ehrlich gesagt so ziemlich wurscht; hauptsache das Teil hat
> eine History und die Cursor-Tasten gehen und so Kleinkram ;-)

In dem Fall sollte Dir dann auch /bin/sh genügen, die hat
die von Dir aufgezählten Funktionen ebenfalls. :-)

Für mich als Admin ist die Shell das wichtigste Werkzeug
überhaupt. Ich muß mit ihr so effizient wie möglich ar-
beiten können, dazu gehört z.B. eine konfigurierbare
Tab-Completion (bei mir werden u.a. Namen von Manpages
und Sysctls per <Tab> komplettiert), History-Expansion,
Editieren mehrzeiliger Kommandos aus der History usw.
Da man in einer (t)csh nichtmal einzeilige Schleifen
schreiben kann, kann ich das als Shell zum Arbeiten nicht
ernst nehmen.

> [...]
> Letzteres ist auch der Grund, warum ich eher kein C mehr nehme,

C ist auch nicht gerade ein ebsonders glänzendes Beispiel
für ein gutes Sprachdesign. Wobei es natürlich immer
Beispiele gibt, die noch schlechter sind ...

> sondern lieber Perl

Das zum Beispiel (was ja genau genommen nichtmal eine
Sprache ist). :-)

Ohne jetzt einen Flamewar vom Zaun brechen zu wollen. :-)

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"Clear perl code is better than unclear awk code; but NOTHING
comes close to unclear perl code"  (taken from comp.lang.awk FAQ)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 10 Jan 2006 - 16:58:26 CET

search this site