Einloggen
[c] [test] [fefe]

/fefe/ – Fefes Kommentarfunktion


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] Jörg "cdrecord" Schilling ist an Krebs gestorben.FJörg ... Effe ## Mod Mon, 11 Oct 2021 11:23:32 GMT Nr. 61293
    JPG 424×323 18.7k
    Jörg "cdrecord" Schilling ist an Krebs gestorben [0].

    F

    Jörg war jemand, der Solaris für Linux überlegen hielt, der darum selbst eine Opensolaris-Distribution bastelte. Einer, der GNU tar sah und dann lieber sein eigenes tar-Programm schrieb. Einer, der einen CD-Brenner hatte und darauf nicht brennen konnte unter Unix, also schrieb er sein eigenes Brennprogramm.

    Ein Titan unter den Dickschädeln dieser Welt.

    Ohne Dickschädel gibt es keinen Fortschritt.

    Wir brauchen mehr Dickschädel.

    [0] https://twitter.com/FUZxxl/status/1447319844295254020

    https://blog.fefe.de/?ts=9f9add44
  • [l] Felix Mon, 11 Oct 2021 11:33:05 GMT Nr. 61294
    F
  • [l] Felix Mon, 11 Oct 2021 12:35:24 GMT Nr. 61301
    uck
  • [l] Felix Mon, 11 Oct 2021 12:51:26 GMT Nr. 61305
    >Ohne Dickschädel gibt es keinen Fortschritt.

    Fortschritt ist a priori gut.
  • [l] Felix Mon, 11 Oct 2021 13:41:24 GMT Nr. 61311
    nie vom gehört
  • [l] Felix Mon, 11 Oct 2021 15:11:16 GMT Nr. 61317
    >Ohne Dickschädel gibt es keinen Fortschritt.
    (Jahr-des-Linux-Desktops-Mem) hier einfügen.
    Lebenszeit verschwendet für Frickelscheiße, die sich kein normaler Mensch jemals aufspielen würde.
    Aber Nerdlogik: Windows ist scheiße, ich frickele mir was zusammen, was nie "einfach funktioniert" und halte mich für überlegen wenn ich täglich drei Stunden im Terminal und in Foren rumkrebse damit die Kopfhörerbuchse wieder funktioniert.
    >Wir brauchen mehr Dickschädel.
    Dann wird das auch was mit Linux. Jedenfalls bis Altmaier... wissen schon.
  • [l] lol lolsky Mon, 11 Oct 2021 15:22:21 GMT Nr. 61320
    >Lebenszeit verschwendet für Frickelscheiße, die sich kein normaler Mensch jemals aufspielen würde.
    Hahaha du weist echt nicht auf welchem OS das Internet läuft. Belastend.
  • [l] Felix Mon, 11 Oct 2021 17:46:36 GMT Nr. 61326
    >>61305
    >a priori
    Du benutzt das Wort, aber es sieht nicht so aus, als wüsstest du, was es bedeutet.
  • [l] Felix Mon, 11 Oct 2021 18:21:16 GMT Nr. 61331
    >>61320
    hahahaha, internet wird auf cd verschickt
  • [l] Felix Mon, 11 Oct 2021 23:39:41 GMT Nr. 61344
  • [l] Felix Tue, 12 Oct 2021 02:10:10 GMT Nr. 61345
    JPG 814×500 41.2k
    >>61344
    Schlechter Troll, 1/10
  • [l] Felix Tue, 12 Oct 2021 05:42:48 GMT Nr. 61346
    >>61345
    Er schrieb von IOS, nicht von iOS.
  • [l] Felix Tue, 12 Oct 2021 07:41:25 GMT Nr. 61349
    F
    Schily im Heise-Forum ist auch unvergesslich.
  • [l] Felix Tue, 12 Oct 2021 09:53:12 GMT Nr. 61355
    >>61311
    Der gute Mann hat neben Software für Solaris (die meistens auch auf diesem neumodischen Linux lief) vor allem auch jede Menge Mett ("Berlin Love", [1]) produziert. Fefe selbst hat das meiste davon noch in Newsgroups gekippt, aber etwas davon ist am Anfang des Blogs noch hängen geblieben. [2]

    Natürlich toll, wenn unmittelbar nach der Todesanzeige erst einmal auf einen Bugreport verwiesen wird [3], dass cdrecord ab 2028 einen Integer Overflow im Jahresfeld eines ISO-9660-Zeitstempels produziert, weil Jörg einmal mehr einen (impliziten) Vorzeichenfehler durch die bloße Definition als "char" begegangen hatte.

    [1] https://minnie.tuhs.org/pipermail/tuhs/2021-October/024525.html
    [2] https://blog.fefe.de/?q=Schilling
    [3] https://news.ycombinator.com/item?id=28828853
  • [l] Felix Tue, 12 Oct 2021 11:18:28 GMT Nr. 61370
    JPG 512×178 15.4k
    >>61355
    >[2] https://blog.fefe.de/?q=Schilling
    Danke, lachte raus laut.
  • [l] Felix Tue, 12 Oct 2021 11:41:24 GMT Nr. 61371
    >>61370
    >Aber so ist das wohl, je weniger jemand kann, desto mehr fühlt er sich zu sagen verpflichtet.
    Oh ja.
  • [l] Felix Tue, 12 Oct 2021 15:31:45 GMT Nr. 61386
    Herzlichst
  • [l] Felix Wed, 13 Oct 2021 17:01:49 GMT Nr. 61486
    > Einer, der GNU tar sah und dann lieber sein eigenes tar-Programm schrieb.
    Hatten wir doch schonmal im Blog, https://blog.fefe.de/?ts=bb99b4b6
  • [l] Felix Wed, 13 Oct 2021 18:35:40 GMT Nr. 61492
    Irgendwie schade, dass die Leute erst sterben müssen, bevor man ihnen Wertschätzung entgegen bringt.
  • [l] Felix Wed, 13 Oct 2021 18:38:13 GMT Nr. 61494
    >>61486
    Ich glaube, ich muss da Fefe recht geben. Schillingware mag zwar eine Sternstunde der Datenvalidierung sein, aber ein Archiv mit Hardlinks auf sich selbst anzulegen bedarf schon einen gewissen Anlauf zum Stolpern, z. B. ein kaputtes Dateisystem. Dass ausgerechnet Visual-Studio-Projektmappen betroffen waren, hat außerdem ein gewisses Geschmäckle – ebenso dass das älteste aufzufindende Archiv unter diesem Namen im GNU-Dialekt gehalten ist.
    >ACE+TAO+CIAO.tar: POSIX tar archive (GNU)

    Herr Schilling hat an dieser Stelle seit den 90ern gewarnt, dass das GNU-Format sich nicht nur an keine Standards hält (weil es aus dem vorläufigen Entwurf eines Standards zusammengefrickelt wurde), sondern sich auch zwischenzeitlich gewandelt hat (vgl. oldgnu und gnu im gtar-Handbuch).
    >This is a commonly used, but unfortunately not POSIX compliant (although designed after 1987) enhancement to the old tar format. The gnutar format has been defined between 1989 and 1994. Do not use the gnutar archive format unless you want to create an archive for a target system that is known to have only the gnutar program available.
  • [l] Felix Thu, 14 Oct 2021 19:53:23 GMT Nr. 61558
    Ich habe nie verstanden, warum diese tar Scheiße aus den Achtzigern immer noch relevant ist. Mein Gott, nehmt rar aus den Neunziger oder 7zip aus Zweitausenden, die lösen alle diese Probleme.
  • [l] Felix Thu, 14 Oct 2021 20:28:12 GMT Nr. 61560
    >>61558
    Du möchtest dich über den Unterschied zwischen einem Archivprogramm und einem Kompressionsprogramm informieren und bitte solange die Tür von außen zumachen.
  • [l] Felix Fri, 15 Oct 2021 04:32:19 GMT Nr. 61568
    >>61558
    >rar
    Proprietäre Kackscheiße
    >7zip
    Auf Windows sehr gut, unterstützt aber leider Unixdateirechte nicht und der Entwickler hat kein Interesse daran, das zu ändern. Damit ist es auf Linux leider unbrauchbar.

    Tar ist Überkrebs, aber leider das einzige Format, das wirklich alle Unixfunktionen unterstützt.
  • [l] Felix Fri, 15 Oct 2021 06:31:37 GMT Nr. 61572
    >>61568
    >offene Quelle
    >der eine Entwickler richtet sich nicht nach unseren Wünschen
  • [l] Felix Fri, 15 Oct 2021 07:10:37 GMT Nr. 61575
    GNU tar hat doch alles was man braucht. Sogar LZMA-Kompression also gibt es überhaupt keine Entschuldigung 7zip zu verwenden.
  • [l] Felix Fri, 15 Oct 2021 10:34:28 GMT Nr. 61589
    >>61568
    >das einzige Format, das wirklich alle Unixfunktionen unterstützt.
    Welche Unixfunktionen werden von lha|lzh nicht unterstützt?
  • [l] Felix Fri, 15 Oct 2021 10:47:57 GMT Nr. 61591
    >>61589
    Spaßfakt: tar bündelt nur Dateien in einen Blob, die Kompression kommt danach von einem anderen Werkzeug, zB. g(un)zip. Die Endung 'tar.gz' ist historisch gewachsen :3
  • [l] Felix Fri, 15 Oct 2021 11:15:11 GMT Nr. 61601
    >>61572
    >Wenn es dir nicht passt, dann forke doch einfach
    <Plötzlich: Über 9000 inkompatible Forks, die keiner verwendet
    Offene Soße in einer Nußschale
  • [l] Felix Fri, 15 Oct 2021 11:15:23 GMT Nr. 61602
    >>61591
    Ist durchaus bekannt[0], aber keine Antwort auf die Frage in >>61589.

    --
    [0] inklusive der daraus erwachsenden Problematik, dass man immer erst das ganze Archiv entpacken muss, bevor man auf einzelne Einträge darin zugreifen kann.
  • [l] Felix Fri, 15 Oct 2021 11:23:09 GMT Nr. 61603
    >>61589
    Kenne ich nicht, also sag du es mir.

    Ich rate einfach mal:
    - Unix-Dateirechte?
    - ACLs?
    - xattr?
    - hochauflösende Zeitstempel?
    - Sparse Dateien?
    - Hardlinks?
  • [l] Felix Fri, 15 Oct 2021 14:21:10 GMT Nr. 61611
    >>61601
    War das Problem hier etwa nicht, dass es weniger als einen Fork gab?
  • [l] Felix Fri, 15 Oct 2021 14:52:17 GMT Nr. 61620
    >>61611
    Ich habe nie nach entsprechenden Forks gesucht. Bestimmt hat das irgendwo mal jemand gemacht. Auf jeden Fall wäre das dann aber nicht mehr "7zip", weil es eine inkompatible Änderung wäre.
  • [l] Felix Fri, 15 Oct 2021 15:15:45 GMT Nr. 61623
    Ach Jungens, nehmt doch einfach "bsdtar" auf Linux. Da kann man einfach "tar tf xyz.tar.xz" machen, statt je nach Kompression ein anderes Flag nehmen zu müssen.
    Auf FreeBSD heißt solche Raketensoftware übrigens "tar" und ist im Basissystem.
  • [l] Felix Fri, 15 Oct 2021 15:23:34 GMT Nr. 61625
    >>61623
    Wie kommst du darauf, dass nur bsdtar das kann?
  • [l] Felix Fri, 15 Oct 2021 17:56:36 GMT Nr. 61633
    >>61560
    Ich möchte auflösen, die Beiden können auch ohne Kompression laufen.
  • [l] Felix Fri, 15 Oct 2021 19:28:04 GMT Nr. 61636
    >>61633
    Ein Archivprogramm archiviert. Und ein Kompressionsprogramm komprimiert. Dass 7zip in bester Windows-Tradition beides vermischt und dafür keins von beidem richtig hinbekommt, ist natürlich auch wieder klar.
  • [l] Felix Sat, 16 Oct 2021 07:48:07 GMT Nr. 61655
    >>61636
    Jede moderne tar-Implementierung tut dasselbe.
  • [l] Felix Sat, 16 Oct 2021 10:00:23 GMT Nr. 61657
    >>61655
    Hör bitte auf hier rumzudunningkrugern. Kein tar das noch alle Sinne beisammen hat wird irgendwelche Kompressionsverfahren implementieren.
  • [l] Felix Sat, 16 Oct 2021 11:41:41 GMT Nr. 61665
    PNG 388×357 43.2k
    >>61657
    Was ist dann das hier?

    https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read_support_filter_gzip.c
    https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read_support_filter_xz.c
    https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read_support_filter_zstd.c
  • [l] Felix Sat, 16 Oct 2021 11:56:21 GMT Nr. 61668
    >>$!
    /*
    * Note that we can detect gzip archives even if we can't decompress
    * them. (In fact, we like detecting them because we can give better
    * error messages.) So the bid framework here gets compiled even
    * if zlib is unavailable.
  • [l] Felix Sat, 16 Oct 2021 13:15:56 GMT Nr. 61670
    >>61668
    Du scheinst den Kommentar, den du da zitierst, nicht wirklich verstanden zu haben.
  • [l] Felix Sat, 16 Oct 2021 13:56:48 GMT Nr. 61673
    >>61568
    Einige Entwickler haben das richtige getan und auf Basis des LZMA-SDKs einen Kompressor namens lzip entwickelt, der ein sauber definiertes Dateiformat und Datenstrom besitzt und gegenüber den LZMA/XZ Utils nicht nur aus aus 7-Zip herausgerupftem Code besteht. Aber auch in diesem Fall hat sich einmal mehr durchgesetzt, was zuerst da war.

    >>61657
    tar an sich inklusive seiner Blockstruktur wird sich sicherlich nicht mehr ändern, gerade weil eines seiner Anliegen gemäß des Namens die Bandsicherung ist. Das beißt sich üblicherweise mit Kompression, solange diese nicht vom Laufwerk in Hardware erledigt wird. Grundsätzlich hält dich aber nichts davon ab, für eigene Zwecke einen anwendungsspezifischen Typ (im Bereich A-Z, oder mit entsprechenden pax-Feldern) für "reguläre Datei komprimiert mit XYZ" zu definieren.
    Die Situation beim anderen Unix-Archivformat cpio sieht ziemlich ähnlich aus.

    Interessanterweise liefert Windows 10 auch bsdtar mit, unterstützt aber ab Werk nur gzip per zlib, bzw. bzip2 falls es als externes Programm zur Verfügung steht.
  • [l] Felix Sat, 16 Oct 2021 14:46:54 GMT Nr. 61676
    JPG 225×225 9.8k
    >>61673
    >lzip ist von Antonio Diaz in C++ geschrieben
    Kein Wunder, dass sich das nicht durchgesetzt hat.
  • [l] Felix Sat, 16 Oct 2021 14:51:48 GMT Nr. 61677
    >>61670
    Ich dachte da steht
    >* Note that we can detect gzip archives even if we can't decompress them.
    was gut zu der Aussage passen würde, dass tar die Kompression nicht selbst durchführt.
    Steht das da etwa doch nicht?
  • [l] Felix Sat, 16 Oct 2021 15:07:36 GMT Nr. 61680 SÄGE
    >>61677
    Schau noch mal genau hin, was der Code dieser drei (und weiterer) Quellcode-Dateien libarchive und somit bsdtar ermöglicht, soweit entsprechende Bibliotheken (HAVE_*_H) zur Verfügung stehen.
    Genau genommen musst du nur den Kommentar bis zum Ende durchlesen.
  • [l] Felix Sat, 16 Oct 2021 15:24:45 GMT Nr. 61682
    >>61673
    Ich habe bereits unironisch Dateisysteme wie squashfs (komprimiert) bzw. UDF oder ISO-9660 mit RockRidge-Erweiterung (unkomprimiert, natürlich mit Schilys Programm erstellt) als Sicherungsmedium verwendet, da sie alle nötigen Dateiattribute erfassen, aber im Gegensatz zu Bandarchiven ohne weitere Hilfsmittel eingehangen werden können.
  • [l] Felix Sat, 16 Oct 2021 16:03:31 GMT Nr. 61683
    >>61665
    Ey, wenn schon Dunning-Kruger-Alarm gegeben wurde, solltest du vielleicht innehalten und deine Position überdenken und nicht noch einen draufsetzen. In keinem einzigen der Links wird ein Kompressionsverfahren implementiert. Wenn dein Wissen nicht ausreicht, um dies erkennen zu können, dann solltest du vielleicht echt nicht die Erwachsenen hier belehren zu wollen.
  • [l] Felix Sat, 16 Oct 2021 16:13:50 GMT Nr. 61684
    >>61683
    Fakt ist, dass libarchive/bsdtar sich um die Kompression und die Archiverstellung kümmert und nicht nur um das Erstellen des Archivs, entgegen deiner Aussage. Wenn du hier zu argumentieren versuchst, dass libarchive kein Kompressionsverfahren implementiert, weil es sich einschlägiger Bibliotheken bemächtigt, dann kannst du genauso gut argumentieren, dass jene Bibliotheken keine Kompressionsverfahren implementieren, weil sie auf libc angewiesen sind, oder dass Firefox keinen Browser implementiert, weil er nur Gecko verwendet. Dein Argument ist schwachsinnig und eine reine Torpfostenverschiebung.
  • [l] Felix Sat, 16 Oct 2021 16:17:59 GMT Nr. 61685
    >>61684
    Bei dem Weg unterstützt libarchive noch eine ganze Reihe anderer Formate, unter anderem zip, und – ja – sogar 7zip.
  • [l] Felix Sat, 16 Oct 2021 16:31:53 GMT Nr. 61689
    >>61683
    So kraftvoll werden nicht einmal in Covid-Diskussionen Torpfosten verschoben.
    Es wird nicht einmal klar, ob du das durchaus fundierte Argument vorbringen willst, dass bsdtar kein Kompressionsprogramm ist (wenngleich es diese je nach Konfiguration in diesem Fall redundant macht), da jedes Programm, das libarchive verwendet, von diesen Filter-Modulen Gebrauch machen kann, oder einfach an den Purismus appellierst und behauptest, dass dynamisches Linken und Erfindungen dritter nicht zählen?
  • [l] Felix Sat, 16 Oct 2021 16:57:54 GMT Nr. 61690
    PNG 529×284 27.4k
    >>61685
    Ich wollte gerade nachschauen ob die tar Implementierung in libarchive auch wirklich mein tar ist. Ich kam nicht sehr weit.

    Finde ein tar, dass auch Verschlüsseln kann und gewinne diesen Faden.
  • [l] Felix Sat, 16 Oct 2021 18:02:58 GMT Nr. 61693
    >>61690
    Distributionen, die sich als GNU/Linux brandmarken, nutzen immer GNU tar für den tar-Befehl. Debian lässt hier nicht einmal eine andere Auswahl über das Alternatives-System zu, auch wenn man libarchive-tools installiert – die Eigenheiten werden als [Essentiell] erachtet.
    Als Nebeneffekt ist bsdtar z. B. immer auf Arch Linux installiert, da der Paketmanager pacman Pakete mit libarchive auspackt und in dieser Entwicklerdistribution Pakete nicht in Nutzer- und Entwicklerpakete aufgesplittet werden.
    bsdtar kommt dem Namen her von FreeBSD, allerdings nutzen dies nicht alle BSDs – OpenBSD und Abspaltungen sind beim klassischen BSD-tar ("paxtar", unterstützt ironischerweise nicht das "pax"-Format) geblieben.
    Aktuelles Apple-Betriebssystem hat auch GNU tar herausgeschmissen und durch ein Programm ersetzt, das standardmäßig Archive im POSIX.2001-Format erstellt, was wiederum gerne mal GNU tar verwirrt.
    https://superuser.com/questions/318809/


[Zurück]
[c] [test] [fefe]