symlink.ch
Wissen Vernetzt - deutsche News für die Welt
 
symlink.ch
FAQ
Mission
Über uns
Richtlinien

Moderation
Einstellungen
Story einsenden

Suchen & Index
Ruhmeshalle
Statistiken
Umfragen

Redaktion
Themen
Partner
Planet

XML | RDF | RSS
PDA | WAP | IRC
Symbar für Opera
Symbar für Mozilla

Freunde
Benutzergruppen
LUG Switzerland
LUG Vorarlberg
LUGen in DE
SIUG
CCCZH
Organisationen
Wilhelm Tux
FSF Europe
Events
LinuxDay Dornbirn
BBA Schweiz
CoSin in Bremgarten AG
VCFe in München
Menschen
maol
Flupp
Ventilator
dawn
gumbo
krümelmonster
XTaran
maradong
tuxedo

 
Linux booten in 200 ms
Veröffentlicht durch chrlen am Dienstag 30. September, 14:10
Aus der schnell-schneller-Linux Abteilung
Linux FSMLabs, Hersteller eines RealTime Linux Systems, hat ein Verfahren entwickelt, mit dem es möglich ist, Linux in ungefähr 200 Millisekunden zu booten. Gemäss Cort Dougan, dem Entwicklungsleiter von FSMLabs, soll es bald schon möglich sein, Linux innert 100 ms zu booten.

Das Verfahren ist Prozessor unabhängig. Ein IBM PowerPC 450GP Embedded Prozessor hat Linux innert 500 ms gebootet und dies inkl. dem Laden einer RAMDisk vom FlashMemory. Zur Zeit werden viele Intel x86 Boards unterstützt und wenn die Nachfrage besteht, wird FSMLabs an dieser Technologie weiterarbeiten, so dass dann auch XScale Prozessoren von diesem Verfahren Gebrauch machen können.
Quelle

Indien sperrt sämtliche Yahoo-Diskussionsforen | Druckausgabe | AMD plant Multi-Core-Opteron  >

 

 
symlink.ch Login
Login:

Passwort:

extrahierte Links
  • Slashdot
  • Linux
  • Quelle
  • FSMLabs
  • Verfahren
  • Mehr zu Linux
  • Auch von chrlen
  • Diese Diskussion wurde archiviert. Es können keine neuen Kommentare abgegeben werden.
    200ms... aber nur für den Kernel! (Score:2, Interessant)
    Von kruemelmonster (symlink0311.5.kruemi@spamgourmet.com) am Tuesday 30. September, 15:56 MET (#1)
    (User #3 Info) http://www.tedaldi.net/
    Offenbar bezieht sich das ganze nur auf den Kernel...
    Das BIOS können die logischerweise nicht beeiflussen (und da gehen bei x86 schon eineige wertvolle Sekunden verloren), ausser natürlich... hm... linuxbios .-)

    Ausserdem dauert das ausführen der init-scripte wohl auf den meisten systemen länger als das laden des kernels... ganz zu schweigen von den startzeiten z.B. von X :-(

    Tja, aber vielleicht kann man damit doch wenigstens mal nen Anfang machen .-)
    Re:200ms... aber nur für den Kernel! (Score:1)
    Von chrlen (chrlen@linux.net) am Tuesday 30. September, 16:08 MET (#2)
    (User #760 Info) http://www.chrlen.ch
    Hi kruemelmonster!

    Du hast natürlich völlig recht, die 200ms beziehen sich nur auf den Ladevorgang des Kernels. Sorry, dass das so "gummig" geschrieben (bzw. oder eben nicht geschrieben) wurde. ;-)

    Gruss,
    chrlen.
    Re:200ms... aber nur für den Kernel! (Score:0)
    Von Anonymer Feigling am Tuesday 30. September, 17:36 MET (#5)
    vor einigen wochen hatte ich mal gelesen das irgend jemand den init vorgang so geaendert hat dass die init scripts im hintergrund - anstatt hintereinander - parallel (forked) gestartet werden (natuerlich in abhaengigkeit von einander). und das kuerzt natuerlich noch einmal die startzeit.
    Re:200ms... aber nur für den Kernel! (Score:2)
    Von asuzuki (as at cynox dot ch) am Tuesday 30. September, 20:55 MET (#11)
    (User #422 Info) http://www.cynox.ch/asuzuki/
    Meinst Du diesen [ibm.com] Artikel?

    Aber mal ehrlich, was ist der Nutzen... wer ist schon drauf angewiesen, dass der Kernel und/oder seine Services in wenigen Sekunden da sind?

    Wenn das für eine Anwendung wirklich kritisch ist, sollte man sich vielleicht eine Speziallösung anschauen...
    Ups... (Score:2)
    Von asuzuki (as at cynox dot ch) am Tuesday 30. September, 20:57 MET (#12)
    (User #422 Info) http://www.cynox.ch/asuzuki/
    Sorry, hab erst jetzt gemerkt, dass der Link schon gepostet wurde.
    Re:200ms... aber nur für den Kernel! (Score:2)
    Von schth (t punkt schmid at gmx punkt net) am Wednesday 01. October, 07:08 MET (#17)
    (User #782 Info)
    Bei Servern die eine möglichst kleine Downtown haben müssen ist es sicherlich praktisch. Aber du hast es schon gesagt. In solchen Fällen wäre ein redundant aufgebautes System mit Loadbalancing, welches ausfälle von einzelnen Systemen verkraftet, warscheinlich sinvoller.

    Grüässli Thomas

    Re:200ms... aber nur für den Kernel! (Score:1)
    Von dino (neil@franklin.ch.remove) am Thursday 02. October, 11:25 MET (#31)
    (User #32 Info) http://neil.franklin.ch/
    Aber mal ehrlich, was ist der Nutzen... wer ist schon drauf angewiesen, dass der Kernel und/oder seine Services in wenigen Sekunden da sind?

    Embedded Systeme. User nimmt Geraet, steckt es ein, drueckt auf Powerknopf und erwartet das er das Geraet *jetzt* benutzen kann.

    Und die duerften eh custom init Scripts haben, die nur das noetigste machen. Und moeglicherweise auch kein standard BIOS.

    Ja, es gibt eine Linuxwelt ausserhalb von Desktoprechnern.
    --
    hardware runs the world, software controls the hardware,
    code generates the software, have you coded today

    Re:200ms... aber nur für den Kernel! (Score:0)
    Von Anonymer Feigling am Tuesday 30. September, 21:18 MET (#13)
    Hab auch mal sowas gesehen.
    lästige startzeiten.. (Score:0)
    Von Anonymer Feigling am Tuesday 30. September, 16:53 MET (#3)
    ..nunja.. mein ibook2 mit linux startet schneller (bis zum init) als mein nokia handy oder der iPod..

    Init scripts beschleunigen (Score:1)
    Von svara am Tuesday 30. September, 17:34 MET (#4)
    (User #1298 Info)
    Die Init scripts brauchen sicher länger als der Kernel, aber zumindest etwas beschleunigen kann man ihre Ausführung so:
    http://www-106.ibm.com/developerworks/linux/library/l-boot.html
    Re:Init scripts beschleunigen (Score:1)
    Von Seegras am Tuesday 30. September, 18:13 MET (#7)
    (User #30 Info) http://www.discordia.ch
    Mir ist da noch eine andere Idee gekommen. Die init-scripts haben ja alle eine Nummer vornedran. Warum also nicht alle mit derselben Nummer gleichzeitig starten? Zu Debug-Zwecken kann ich ja ein /etc/rc1.d haben, in dem jedes Script eine einzigartige Nummer hat und entsprechend seriell startet. Mittels dem Parameter "" kann ich dann auch dem Lilo sagen in welchem Runlevel er starten soll. Alles was dazu geändert werden muss ist /etc/init.d/rc; sowie unter Debian das /usr/sbin/update-rc.d und die Policy ;) Ich denk ich mach das demnächst mal.
    --
    "The more prohibitions there are, The poorer the people will be" -- Lao Tse
    Re:Init scripts beschleunigen (Score:1)
    Von dawn am Wednesday 01. October, 08:50 MET (#19)
    (User #8 Info)
    Wie waere es mit runit?
    --
    Anyone can make an omelet with eggs. The trick is to make one with none.
    Re:Init scripts beschleunigen (Score:2)
    Von brummfondel am Wednesday 01. October, 09:50 MET (#21)
    (User #784 Info)
    Das ist ja alles gut und schön mit gleichzeitigem starten der Init-Scripte. Aber ob das wirklich so viel schneller wird, ist nicht unbedingt gesagt - man stelle sich vor, ein mysql und ein apache starten gleichzeitig - erste checkt wild seine Datenfiles, zweiterer lädt alle Module nach. Das wird ein ziemliches gedränge auf dem Bus und bremst oft noch mehr als wenns nacheinander läuft. Dazu kommt in anderen Fällen, daß die Programme oft aus den gleichen Verzeichnissen kommen (/bin, /sbin, /usr, /usr/local/.....) und damit oft auf den gleichen Partitionen oder zumindest Platten liegen.

    --
    $ cd /dos/c/MICROSO~1
    $ rm -rf *
    Re:Init scripts beschleunigen (Score:1)
    Von dino (neil@franklin.ch.remove) am Thursday 02. October, 11:28 MET (#32)
    (User #32 Info) http://neil.franklin.ch/
    Aber ob das wirklich so viel schneller wird, ist nicht unbedingt gesagt

    Wird ueblicherweise schneller werden, weil Timesharing. All die Zeit wo ein Pogram Disks macht und der Prozi wartet, oder Prozi macht und die Disks warten, oder gar auf etwas anderes wartet und beide nix machen, kann der andere aktiv werden.

    Und langsamer wird es nur wenn der Speicher deswegen ueberlaeuft und geswappt werden muss.

    Also ist paralleles init-en sicher sinnvoll.
    --
    hardware runs the world, software controls the hardware,
    code generates the software, have you coded today

    Ah ja, immer das Rebooten. (Score:1)
    Von mirabile (root@[IPv6:2001:768:194b:1::1]) am Tuesday 30. September, 18:08 MET (#6)
    (User #504 Info) https://mirbsd.bsdadvocacy.org:8890/
    Kinderunix (a.k.a. Linux) wird Microsoft Windows
    immer ähnlicher. Ich verliere mehr und mehr meinen
    Respekt vor der Entwicklergemeinde hinter GNU/Linux.

    Warum zum Teufel soll ich meinen PC in einer Sekunde
    booten können? Richtige Computersysteme konzentrieren
    sich hingegen auf Stabilität - sodaß man _nicht_ neu
    starten muß.

    Meine Güte, diese vertane Entwicklungsenergie, es ist
    echt schade um sie.

    Zum Vergleich: es sind noch ~50 Fehler im aktuellen
    gcc, davon über die Hälfte im C++-Compiler alleine.
    Warum fixen sie nicht die?

    PS: "Shut Up and Hack" wider mich zu verwenden ist
            kein Gegenargument. Genau das tue ich. Und gcc
            dabei zu fixen gehört zu dem Job dazu.


    -- 
    mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
    Re:Ah ja, immer das Rebooten. (Score:1, Tiefsinnig)
    Von Anonymer Feigling am Tuesday 30. September, 18:18 MET (#8)
    macht sinn jetzt wo linux immer mehr auf embedded devices eingesetzt wird... da will niemand lange warten... wenn mal gebootet werden muss...
    Re:Ah ja, immer das Rebooten. (Score:1, Interessant)
    Von Anonymer Feigling am Tuesday 30. September, 19:47 MET (#10)
    Gerade bei Embedded Devices mach ein Suspend-Modus ev. mehr Sinn (sofern genügend Speicherplatz vorhanden), denn wer bootet schon sein Device (a.k.a Stromversorgung wieder herstellen)? Ein Spleep-Modus mit ganz kleinem Energie-Verbrauch ist da wohl besser.

    Momo_102, der wiedermal zu faul war sich anzumelden

    Re:Ah ja, immer das Rebooten. (Score:2, Tiefsinnig)
    Von squisher am Wednesday 01. October, 01:22 MET (#15)
    (User #240 Info)
    Ich stimme da nicht mit dir ueberein. Ich habe einen LiteOn DVD Player, der mit Linux laeuft, und der geht in den Standby mode wenn man ihn abschaltet. Ich faende es viel besser wenn er sich komplett abstellen koennte - denn das wuerde Strom sparen. OK, vielleicht nicht so viel aber mit Sicherheit ist es ein wenig. Da macht ein schneller Bootprozess einen grossen unterschied, denn im Moment braucht der Player ca. 7 Sek. vom Kaltstart bis zur vollen Betriebsfaehigkeit. Wenn da kuerzer waere, dann gaebe es keinen Grund Strom im Standby Modus zu verschwenden.

    ~Squisher
    Re:Ah ja, immer das Rebooten. (Score:1)
    Von mirabile (root@[IPv6:2001:768:194b:1::1]) am Wednesday 01. October, 11:35 MET (#22)
    (User #504 Info) https://mirbsd.bsdadvocacy.org:8890/
    Oh, ein _DVD_ Player braucht sieben Sekunden
    zum Booten. Wie schlimm!
    Meine Güte, dieses Feilschen um Performanz zu
    jedem Preis ist (bzw. erscheint mir, persönlich)
    wirklich kindisch.


    -- 
    mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
    Re:Ah ja, immer das Rebooten. (Score:0)
    Von Anonymer Feigling am Tuesday 30. September, 19:17 MET (#9)
    Hi,
    Gibt halt leute die setzen Linux auch auf dem Desktop ein, und lassen ihren Rechner nicht 24/7 laufen... hab ich gehört :)
    Jeder Entwickler setzt Prioritäten, wenn jemand halt mehr an embedded devices interessiert ist und von C++ nicht viel hält, würde es mich wundern, wenn er am g++ schraubt, nur weil das vielleicht für die Mehrzahl der Entwickler besser ist.

    Grüsse
    Re:Ah ja, immer das Rebooten. (Score:0, Lustig)
    Von Anonymer Feigling am Wednesday 01. October, 00:04 MET (#14)
    So erflogreich scheinst du noch nicht gewesen zu sein :-)

    Blöder Troll !
    Re:Ah ja, immer das Rebooten. (Score:1)
    Von ia97lies am Wednesday 01. October, 06:31 MET (#16)
    (User #890 Info)
    lies bitte richtig, ja bevor du hier blöd rumröhrst wie ein elch in der pampas.

    um dir auf die sprünge zu helfen: es geht hier um embedded devices und nicht um pc systeme.
    Re:Ah ja, immer das Rebooten. (Score:1)
    Von dawn am Wednesday 01. October, 08:41 MET (#18)
    (User #8 Info)
    Warum zum Teufel soll ich meinen PC in einer Sekunde booten können? Richtige Computersysteme konzentrieren sich hingegen auf Stabilität - sodaß man _nicht_ neu starten muß.
    Laptops, Embedded Devices?
    Meine Güte, diese vertane Entwicklungsenergie, es ist echt schade um sie.
    Welchen Punkt von "Jeder entwickelt das, was er benoetigen kann und teilt es mit anderen" hast Du nicht verstanden?
    --
    Anyone can make an omelet with eggs. The trick is to make one with none.
    Re:Ah ja, immer das Rebooten. (Score:2)
    Von asuzuki (as at cynox dot ch) am Wednesday 01. October, 09:31 MET (#20)
    (User #422 Info) http://www.cynox.ch/asuzuki/
    Welchen Punkt von "Jeder entwickelt das, was er benoetigen kann und teilt es mit anderen" hast Du nicht verstanden?

    Nicht zu vergessen der Punkt "was einem auch Spass macht", ist doch besonders bei Opensource Projekten ein Faktor, wo die Leute vielleicht kein Geld für ihren Code kassieren.
    Re:Ah ja, immer das Rebooten. (Score:1)
    Von mirabile (root@[IPv6:2001:768:194b:1::1]) am Wednesday 01. October, 11:37 MET (#23)
    (User #504 Info) https://mirbsd.bsdadvocacy.org:8890/
    Selbst Laptops. Auch diese haben z.B. in der
    Regel Suspend-, Sleep- und oft auch software-
    gestützte Hibernate-Modi.

    Und mein Laptop hat noch einen Vorteil: er bootet
    zwar in >2 Minuten, aber dafür kann man die Fest-
    platte herausholen und in ein gänzlich anderes
    Modell stecken, und (bis auf die "Driver" Option
    in X-Window) muß man das Betriebssystem nicht an
    die neue Hardware anpassen, da einfach alles
    unterstützt und geprobt wird.

    Finde ich persönlich einfacher, YMMV.


    -- 
    mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
    Re:Ah ja, immer das Rebooten. (Score:1)
    Von dawn am Wednesday 01. October, 12:43 MET (#24)
    (User #8 Info)
    Selbst Laptops. Auch diese haben z.B. in der Regel Suspend-, Sleep- und oft auch software- gestützte Hibernate-Modi.
    Aha. Und jeder, der das Laptop nachher in diesem Zustand klaut hat Zugriff auf meine Daten und alles, was im Memory ist?

    Ich habe meine Daten lieber in einem Crypto-FS und lasse meine Swappartition beim Shutdown unbrauchbar machen. YMMV.

    Und mein Laptop hat noch einen Vorteil: er bootet zwar in >2 Minuten, aber dafür kann man die Fest- platte herausholen und in ein gänzlich anderes Modell stecken, und (bis auf die "Driver" Option in X-Window) muß man das Betriebssystem nicht an die neue Hardware anpassen, da einfach alles unterstützt und geprobt wird.
    Toll. Das mache ich mit einer Laptopfestplatte taeglich, wenn nicht sogar mehrmals am Tag :-)

    Obiges impliziert, dass also diverses Zeuchs in deinem Kernel drin ist, das Du nicht brauchst. Ich strebe es hier eher an, nur das installiert zu haben, was ich auch benutze. Gibt weniger Wartungsaufwand. YMMV.

    Zudem hast Du elegant meinen letzten Satz ignoriert. Du scheinst nicht so viel Ahnung von den Absichten und Mechanismen zu haben, die hinter Open Source stehen. Grundsaetzlich geht es darum, etwas zu entwickeln, das mensch selber benutzen kann (weil alle Alternativen schlecht sind, weil alle Alternativen ideologische Macken haben, usf.). Das dann nachher der Quellcode von dieser Entwicklung offen gelegt wird, haben wir einer pragmatischen Art des Denkens zu verdanken: "Ich gebe es allen, damit andere Zeitersparniss dadurch haben". Aus beiden Punkten entsteht dann auch ein gewisser Spass (weil die Leute Spass daran haben, selber etwas zu entwickeln und weil sie Spass daran haben, es mit anderen zu teilen).

    Es zeugt nicht gerade von Intelligenz, ohne Kentnisse dieser Hintergruende einfach gewisse Entwicklungen in gewissen Bereichen zu verurteilen und als kindisch abzustempeln. Es versteckt sich dahinter sogar ein gewisser Ansatz eines Strebens nach Anerkennung. Vielleicht ueberlegst Du dir mal, auf welche Art und Weise Du dir Anerkennung verschaffen kannst. Auf jedenfall sicher nicht durch Postings, die weder fundiert sind noch von Fachwissen in dem diskutierten Bereich zeugen.
    --
    Anyone can make an omelet with eggs. The trick is to make one with none.

    Re:Ah ja, immer das Rebooten. (Score:1)
    Von tmmw (tmmw at fenixnet ch) am Wednesday 01. October, 13:34 MET (#25)
    (User #1032 Info)
    Don't Feed the Trolls! Lass ihm die Illusion.

    Wenn's Ihm zu schnell wird kann er ja sleep 60s in sein Init Skript rein tun. SCNR
    Blöp
    Re:Ah ja, immer das Rebooten. (Score:1)
    Von mirabile (root@[IPv6:2001:768:194b:1::1]) am Wednesday 01. October, 20:09 MET (#26)
    (User #504 Info) https://mirbsd.bsdadvocacy.org:8890/
    Es versteckt sich dahinter sogar ein gewisser
                        Ansatz eines Strebens nach Anerkennung.

    [x] Du weißt, warum MirBSD existiert?

    Letzten Endes ist das nichts anderes als das 200ms-Bootprojekt.
    Ein Versuch, das Betriebssystem, das man mag, noch besser zu
    machen. Ich kann es auch aus diesem Grunde nicht verurteilen;
    was mir aber PERSÖNLICH mißfällt ist diese Attitüde mancher
    GNU/Linux-Jünger, alles noch schneller zu machen um jeden Preis.

    Selbstverständlich gibt es auch Gegenbeispiele, und Debian
    schätze ich z.B. sehr.

    Auf Deinen ersten Abschnitt bezogen: man xlock; Kryptographiesysteme
    kann man auch umounten. (Mein swap ist auch verschlüsselt.)

    Gruß


    -- 
    mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
    Re:Ah ja, immer das Rebooten. (Score:1)
    Von dawn am Wednesday 01. October, 20:48 MET (#27)
    (User #8 Info)
    [x] Du weißt, warum MirBSD existiert?
    Gewiss. Du hasts mir ja am Linux Tag persoenlich erklaert.
    Letzten Endes ist das nichts anderes als das 200ms-Bootprojekt. Ein Versuch, das Betriebssystem, das man mag, noch besser zu machen. Ich kann es auch aus diesem Grunde nicht verurteilen; was mir aber PERSÖNLICH mißfällt ist diese Attitüde mancher GNU/Linux-Jünger, alles noch schneller zu machen um jeden Preis.
    Und wieso verlierst Du den Respekt vor ihnen (wie Du ja im Ursprungsposting schriebst), bloss weil sie etwas entwickeln, das sie anschliessend benutzen koennen und/oder das Spass macht?

    Du verlierst den Respekt vor ihnen, weil sie dieselbe Motivation haben wie Du? Du schlaegst ihnen vor, lieber andere Dinge zu tun (gcc Bugs fixen...), obwohl die Leute ziemlich genau wissen, wieso sie das das entwickeln?

    Du wertest Arbeiten unterschiedlich stark, je nach dem ob sie dir gefaellt oder nicht. Bei Open Source ist aber jede Arbeit gleich viel wert. Dies tust Du vermutlich aus einem Unvermoegen heraus, die Absichten von anderen, fremden Leuten zu erkennen und nachzuvollziehen.

    Auf Deinen ersten Abschnitt bezogen: man xlock; Kryptographiesysteme kann man auch umounten. (Mein swap ist auch verschlüsselt.)
    Ja. Natuerlich. Aber mit dem umounten eines Crypto-FS geht auch fuer mich der groesste Vorteil des Suspend und aehnlichen Modi verloren: Naemlich, an einem bestimmten Punkt aufhoeren arbeiten und spaeter an genau dem Punkt weitermachen (wofuer Suspend auch gedacht ist).

    Wenn ich zuerst alle Applikationen schliessen muss um mein Crypto-FS zu umounten, dann kann ich auch gleich meinen Laptop herunterfahren. Dann frisst er nicht unnoetig Strom.

    Und selbst mit den oben beschriebenen Massnahmen: Zugriff auf Memory und Swap hat mensch dann trotzdem. Ausser Du wuerdest vor dem suspend noch ein swapoff machen.
    --
    Anyone can make an omelet with eggs. The trick is to make one with none.

    Re:Ah ja, immer das Rebooten. (Score:0, Troll)
    Von mirabile (root@[IPv6:2001:768:194b:1::1]) am Wednesday 01. October, 21:21 MET (#28)
    (User #504 Info) https://mirbsd.bsdadvocacy.org:8890/
    Du wertest Arbeiten unterschiedlich stark, je nach dem ob sie dir gefaellt oder nicht. Bei Open Source
                ist aber jede Arbeit gleich viel wert. Dies tust Du vermutlich aus einem Unvermoegen heraus, die
                Absichten von anderen, fremden Leuten zu erkennen und nachzuvollziehen.

    Du magst Recht haben; ich werde mir das beizeiten mal durch den Kopf
    gehen lassen. Bitte nimm es als gegeben hin, daß ich die letzten paar
    Tage ein bißchen viel Streß hatte.

    Die technische Seite können wir auch noch ad absurdum diskutieren; aber
    mangels praktischer Erfahrung (ich habe verschlüsselten Swap, aber kein
    funktionierendes Resume) lassen wir das lieber.

    PS: Ich verliere nur Respekt vor Leuten, die um jeden Preis etwas wollen,
            und dabei alles andere sträflich vernachlässigen.
            OTOH kann man Prioritäten setzen und das in Kauf nehmen; Nachteile zu
            erlangen, um ein gestecktes Ziel zu erreichen. Jetzt, wo ich schreibe,
            fällt mir auf, daß das eigentlich oft meine Art ist.

    Gruß


    -- 
    mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
    Re:Ah ja, immer das Rebooten. (Score:1)
    Von dawn am Wednesday 01. October, 21:40 MET (#29)
    (User #8 Info)
    Du magst Recht haben; ich werde mir das beizeiten mal durch den Kopf gehen lassen.
    Freut mich. So eine Reaktion wollte ich auch ausloesen.
    Bitte nimm es als gegeben hin, daß ich die letzten paar Tage ein bißchen viel Streß hatte.
    Ist doch kein Problem. Menschen neigen dazu, bei Stress manchmal das eine oder andere Bit zufaellig zu swappen....

    Und falls Du sowas ansprechen willst: Nein, ich bin nicht nachtragend. Und eigentlich hat mich das ganze auch nie persoenlich betroffen.
    --
    Anyone can make an omelet with eggs. The trick is to make one with none.

    Re:Ah ja, immer das Rebooten. (Score:1)
    Von mirabile (root@[IPv6:2001:768:194b:1::1]) am Wednesday 01. October, 22:05 MET (#30)
    (User #504 Info) https://mirbsd.bsdadvocacy.org:8890/
    <start mode="shut up and hack" />

    -- 
    mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}

    Linux User Group Schweiz
    Durchsuche symlink.ch:  

    Never be led astray onto the path of virtue.
    trash.net

    Anfang | Story einsenden | ältere Features | alte Umfragen | FAQ | Autoren | Einstellungen