Posts by 7Saturn

    Der Tipp von oben, ob denn selbst formatierte Disketten (also im gleichen Laufwerk formatiert und gelesen) gehen, ist erst mal gut, um zu sehen, ob sie denn generell noch mag, also ob Chips oder Mechanik/Lese-/Schreibkopf einen weg haben. Wenn lesen und schreiben einwandfrei im selben Laufwerk klappt, aber nicht mit den originalen, nicht nochmal anderweitig formatierten Disks, dann ist es wahrscheinlich die Justage.

    Also der Tenor hier war früher mal, dass man Diskettenlaufwerke überhaupt nicht sinnvoll mit irgendwelchen Programmen eingestellt bekommt. Du brauchst eine Referenz-Disk, also eine, die noch original formatiert ist (nix aus demselben Laufwerk, evtl. was aus einem justierten Laufwerk) und ein Oszi, auf dem du sehen kannst, was die Signale wirklich tun.

    Also ich bin mir nicht ganz sicher, welches Setup du meinst. Aber hier läuft TB mit verschiedenen Owncloud Servern als Kalender-Quellen ganz gut. CardBook macht CardDAV auch gut nutzbar. Auch da habe ich zwei Server integriert. Das einzige, was ich mir vorstellen kann, wo TB abstinkt, ist ein bestimmter Server mit verschiedenen Accounts parallel. Ich glaube, da ist TBs interner PW-Manager tatsächlich zu doof zu, weil er bei einer Adresse immer dieselben Zugangsdaten verwendet. Meinst du das?

    Das' mir auch schon sauer aufgestoßen, dass schön langsam x86 einfach weg rationalisiert wird. Ich kann's verstehen, warum. Aber gerade für ältere Systeme hat man ggf. gar keine Alternative. Und gerade bei denen bietet sich Linux sehr oft geradezu an. Aber können, vor Lachen.

    Das mit der Inkompatibilität sollte der Maintainer der Paketquellen unterbinden. Also eben gerade nicht GUI-Version x ausliefern, die Unterbau z verlangt, obwohl nur y mit dabei ist. Ich weiß, das ist nicht immer gegeben. Aber dann kann man halt nicht gerade Arch mit dem neusten Scheiß™ verwenden, sondern z. B. eher ein Debian.


    Worauf ich hinaus wollte ist aber eben, dass insbesondere Konsolen-Tools da meistens schon brauchbar trennen, sodass man sich für seinen Anwendungszweck mit dem was eh dabei ist was zimmern kann und normalerweise auch davon ausgehen kann, dass das auch in 2 Jahren noch immer einfach nur läuft. Wenn ich z. B. nur ein krudes Backup-File anlegen will, das meine aktuelle Fassung der Nextcloud-Software inkl. Datenbank-Dump enthält, brauche ich nicht drauf zu hoffen, dass $irgendwer mir was kleistert, sondern kann das ganz einfach mit den Bordmitteln selbst machen: DB-Dump mit Bordmitteln anlegen, NC-Verzeichnis zusammen mit dem Dump in ein Tar-Archiv packen, wenn ich lustig bin auch in ein gzip oder verschlüsseltes 7zip mit automatisch generiertem Dateinamen, Dump hernach wieder löschen. Das ganze in ein shell-Skript und fertig ist die Laube. Und das aber alles ohne dass ich darauf angewiesen wäre, dass mir irgend ein Dritter das baut oder ich auf irgendwelche obskuren Dinge angewiesen wäre, die nur $Hersteller mir liefert. Ich kann's mit den mitgelieferten Tools machen, die ich auch auf jedem Linux System vorfinde (oder über die Paketverwaltung schnellstens installiert habe) und ggf. die Daten auch händisch wieder auseinander kriege, falls ich mein Skript gerade nicht da habe.


    Unter Windows habe ich da sehr oft schlechte Karten, weil das eben vieles einfach gar nicht mitbringt, bzw. vieles nur in Form irgendwelcher Drittanbieter-Software zu kriegen ist, die sich so nebenbei auch alle Nase ändern kann und ggf. auch meinem Anwendungszweck so überhaupt nicht gerecht wird.

    Ich finde halt, Dinge, die relevant sind, also die nicht nur alle 1.000 Menschen mal einer braucht, könnte man schon mal in GUIs übernehmen, oder anders rum, einen entsprechenden Command dafür schaffen. Das schöne an der UNIX/Linux Konsolen Philosophie ist ja gerade das atomistische. Ein Tool für eine scharf umrissene, relativ kleine Aufgabe, die es aber hervorragend erledigt und was in Kombination mit anderen Tools richtig mächtig werden kann, woraus man andere, tolle Tools schaffen kann. Die Mächtigkeit kann man dann wegen mir gern in ein GUI-Tool gießen, das wegen mir auch gern im Hintergrund einfach nur diese Tools nutzt. Warum nicht?


    Manchmal ist es aber halt echt nervig, dass bestimmte Dinge nur mit Klimmzügen auf die eine oder andere Weise gehen, aber durchaus regelmäßig benötigt werden. Manches daran ist der Philosophie geschuldet. Unter Windows kann ich ganz ohne Admin-Rechte meinen OpenVPN-Client nutzen, was unter Linux dann wieder irgendwie root-Rechte braucht, um zu funktionieren. Klar, ich kann mit geeigneten Kenntnissen dann wieder ein eigenes Skript schaffen, oder einen Aufruf nutzen, der dann ganz speziell immer mit root-Rechten geht, selbst wenn ich normalerweise gar keine root-Rechte habe. Aber warum nicht gleich so? Weil es anders gedacht ist... Es soll ja gar keiner an den Netzwerkeinstellungen rum fummeln können.


    Aber warum dann nicht ein entsprechendes Werkzeug bereitstellen, dass – falls gewünscht – doch wieder die Möglichkeit schafft. Darf ja gern zum Nachinstallieren sein. Denn für $DAU will ich halt keine sudo-Rechte vergeben müssen, nur damit der mit seinem Laptop nach Hause telefonieren kann. Alles selbst per Hand schnitzen will ich aber auch nicht... Woanders hat man das einfach angenehmer gelöst.

    apt install und upgrade weisen Dich auf "verwaiste" Pakete hin und sagen auch gleich, dass Du sie per "apt autoremove" entfernen lassen kannst. :)

    Du meinst auf der Konsole, oder? Ja, das weiß ich. Aber wo ist die entsprechende Info im GUI? Und am besten eben direkt mit dem dazu passenden Knopf, das Problem zu beheben.

    Richtig toll ist ja, dass es inzwischen unter Windows auch in diese Richtung geht. Zumindest ist mein Eindruck spätestens seit Win 7 und 10, dass so einiges wohl besser über die cmd abgesetzt wird (oder zumindest die Tutorials es halt so machen), oder über die Powershell. Was manchmal tatsächlich viel einfacher ist. Ich kann's aber trotzdem verstehen, wenn man bestimmte Dinge einfach sehr gerne auf einem GUI erledigen können will. Einfaches Beispiel: Entferne mir nicht mehr benötigte Pakete. Auf der Konsole weiß ich sehr genau, wie man das macht. Wie das mit dem Standard-Ubuntu-Paketaktualisier-Dingens geht, weiß ich nicht (ich behaupte: es geht nicht). Warum nicht? Ein Knopf, der dasselbe Command absetzt, wie ich es auch machen würde, wäre völlig ausreichend. Wenn ich mich ohnehin schon damit abgegeben habe, ein GUI für den Job zu schreiben, ist das irgendwie naheliegend. Rückwärts dann dasselbe mit Windows, wo man sich manchmal schon fragt, warum man diesen tollen Registry-Hack nicht einfach als Checkbox in das entsprechende Menü gesetzt hat, das es zu dem Thema eh schon gibt. Ich verstehe zumeist einfach nicht, warum man den letzten Meter dann nicht auch noch geht.

    Schaut gut aus und ich fand's mit den besten Weg, speziell wenn es um größere Mengen Disks geht, weil's unglaublich flott geht. Wenn du noch mal eben einen Density-Scan machst, kann's sein, dass evtl. trotzdem Ungereimtheiten auf der Oberfläche zutage treten, die ein einfacher error-scan nicht zeigt. Aber im Prinzip reicht der error-scan völlig aus.

    Es macht die Auswahl der Oberfläche schon so einiges aus. Ich weiß noch, wie damals von Ubuntu 12 auf Ubuntu 14 alles wirklich kriechlangsam auf älteren Kisten wurde. Ubuntus GNOME-Verschnitt war da halt nicht mehr unbedingt die beste Wahl. XFCE wurde hier schon genannt. Für den Anfänger vielleicht einen Ticken zu spartanisch, aber wenn man sich ein bisschen(!) damit auseinandersetzt, freut man sich über die Konfigurierbarkeit, die vieles wieder wettmacht.

    Sicher, dass du nicht nur nebenbei auch noch den Kernel gewechselt hat? Bei mir war BT mit Ubuntu 14 auch ein Krampf, aber mit Debian 9 geht es OOTB problemlos. Neuerer Kernel, und es lief einfach, auch mit XFCE.

    Hier rennen Debians auf den Produktivsystemen (Server, Hauptdesktop) und AntiX auf den älteren, eher Spaß-Projekten (darunter ein Pentium 3 Laptop mit 333 MHz und 256 MB RAM). In VMs laufen noch Arch und Suse, um gewisse Skripte auf mehreren Plattformen zu testen. Dazu noch Spezial-VMS, die z. B. nur den Job haben, 32-Bit-Executables nativ bauen und testen zu können.