1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
<!--
.. date: 2006/10/11 17:14
.. title: Neunzehnvierundachtzig
-->
Das Akku meines <del>guten</del> alten 12" PowerBook G4 ist inzwischen so abgelatscht, dass es, wenn die Festplatte mal anspringt, gerne die Hufe hochstreckt
und den Rechner ausgehen laesst. (Wenn ich nicht noch die irrationale Hoffnung auf ein 12" MacBookPro haette, haette ichs schon ersetzt...) Gepaart mit einer
defekten Backupbatterie macht das regelmaessig 1984 auf meinem Rechner. Genauer gesagt 01. Januar 1984 gegen ein Uhr. Und zwar so lange, bis das OS sich
entschliesst, das Datum mit den Timeservern abzugleichen.
Normalerweise passiert das, wenn er ne neue defaultroute bekommt, heute jedoch hatte ich vorher schon mit meinem Rechner gearbeitet und mich erstmal
gewundert, warum Safari schlicht stehenbleibt und nicht auf Eingaben reagiert. Zudem warf ich ein laenger dauerndes wget an. Nachdem ich den Zeitabgleich
dann haendisch angeworfen hab, erbrach sich wget folgendermassen in meine Konsole:
<pre>
19% [====> ] 315,586,864 0.32B/s retr.c:291: failed assertion `msecs >= 0'
Abort trap
</pre>
Mjam. Millisekunden rumgewrappt, 22 Jahre waren dann doch zu viel fuer die fancy progress bar implementation. Da MUSS man natuerlich sofort das Handtuch
werfen.
#### Nachtrag
Und natuerlich enttaeuscht mich wget auch beim weiteren Herunterladen eines 2298815162 Bytes langen Files nicht:
<pre>
HTTP request sent, awaiting response... 200 Coming Up
Length: -1,996,152,134 [application/octet-stream]
[ <=> ] 1,226 --.--K/s
19:59:08 (11.69 MB/s) - `<FILENAME>' saved [1226/-1996152134])
</pre>
Und nein, es ist nicht der Webserver, der da die Content-Lenght so rausgib:
<pre>
HTTP/1.1 200 Coming Up
Content-Type: application/octet-stream
Server: Gatling/0.9
Content-Length: 2298815162
</pre>
Qualitaetssoftwaere.
|
