Keine Sorge, wir haben alle dein kühles Kugelfisch-T-Hemd gesehen.
Wie ist es so im Alltag, verglichen mit Linux?
Stabil, sicher, schnell und systemd-frei.
Das ist VoidLinux auch
Void ist tatsächlich basiert.
Hmm, mein Linux läuft auch stabil, sicher und schnell ;). Ich kenne die Philosophie rund um OpenBSD, den Fokus auf Sicherheit, meine Frage geht eher in die Richtung: muss man sich als Linux-Nutzer sehr umgewöhnen? Was sind kleine Details, über die man leicht stolpert? Was man online lesen kann, reflektiert im Wesentlichen deinen Kommentar, aber ist doch alles Recht wenig konkret, wenn es darum geht, welche Vorteile ich davon habe, OpenBSD zu nutzen.
Nenn mich naiv, aber ich bin generell ziemlich glücklich mit Wayland, Plasma und SystemD (das sag ich trotz des Risikos, mich unbeliebt zu machen :-)))
Wayland ist in Arbeit, systemd wird es nicht geben. ;-)
Umgewöhnen muss man sich kaum, FALLS man keine proprietäre Software (oder Bluetooth…) braucht. Vieles funktioniert einfach mit weniger Überraschungen, vor allem Upgrades.
systemd-frei
Ich gebe zu. Das klingt verlockend.
Ich verstehe nicht was an systemd schlecht ist, und an diesem Punkt habe ich Angst zu fragen.
(Wenn jemand antworten möchte, versuche bitte, den Begriff “Unix-Philosophie” zu vermeiden.)
Ich glaube es ist einfach cool, systemd uncool zu finden und niemand weiß (mehr) so recht, warum überhaupt.
Aber diejenigen wissen es sicher viel besser als die Entwicklungsteams großer Distributionen.
Ich glaube der Hass kam ursprünglich von den Graubärten, die ihre seit 1990 gepflegten Stiefel-Muschelskripte nicht wegschmeißen wollten.
https://blog.darknedgy.net/technology/2020/05/02/0/
Ist ein relativ langer Artikel aber er kommt mMn ziemlich gut ohne den allgemeinen SystemD hate aus und erklärt trotzdem einige tiefgreifende Probleme mit der Software.
Die Zusammenfassung ist: Selbst wenn man meint, dass einem die Unixphilosophie egal ist, ist SystemD eine sehr komplizierte Software die von Anfang an eine Dissonanz zwischen Dokumentation und Konfigurationssprache und der eigentlichen Implementierung hatte. Darüber kann man mit einer “aber funktioniert doch” Attidtüde hinweg gehen, ist jedem selber überlassen. Und SystemD funktioniert auch in 99,9% der Fälle, insofern hätte man damit nicht komplett unrecht.
Ich glaube, die ursprüngliche Kritik war, dass systemd Aufgaben übernimmt, die es nicht übernehmen sollte.
Dadurch wurde die Software dann fett, schwer überschaubar, hat Sachen vermischt die man gut hätte trennen können (ja Unix Philosophie ich weiß), hat auf manchen Systemen Probleme gemacht.
Einmal ging es sogar so weit, dass Hardware gebrickt wurde, weil systemd Features aktiviert hatte, die niemand gebraucht hat, die aber trotzdem standardmäßig aktiv waren (read-write-mount der Bootloader-variablen).
Edit: Mein Verständnis der Situation ist, dass systemd zwar FOSS ist, der Entwickler von systemd scheinbar aber von einem kommerziellen Unternehmen (RedHat IIRC) nach LOC (lines of code) bezahlt wurde oder so. Dadurch wurde die Software dann unnötig aufgebläht und unelegant, und viele Menschen wollten sie halt (verständlicherweise) nicht mehr verwenden.
Wie sich die Sache heute verhält, weiß ich nicht.
Benutzt wer OpenBSD mit Wayland? Soll laufen, aber keine Praxiserfahrung.
Ich wundere mich auch, warum es so ein Hardwaresupport Problem gibt, wobei es ja nicht Copyleft ist, also doch mehr integrieren könnte?
Ist in Arbeit.
Ich muss sagen, BSD hat mich auch schon das ein oder andere mal gereizt, aber ich find’s schade, dass die BSD Lizenz nicht
copyleftkopierlinks (und noch nicht mal wirklich frei) ist(Abgesehen davon, dass ich davon ausgehe, dass den allermeisten Menschen die Lizenz ihres Betriebssystems ziemlich schnuppe sein dürfte. Selbst die meisten Linuxer nutzen nicht den
linux-libre-Kernel.)Ich stimme mit dem geposteten Artikel nicht überein:
Believe it or not, this scenario is even one which is beneficial to you. Said company, is likely to find bugs in libWidgetCrypt, and fix them. From my experience of such things happening, they more often than not, contribute their changes back to you when they make such fixes to your library, even though they’re not required to! Ich weiß ja nicht. Ich kenne viele gegenbeispiele. Zum beispiel Minix und das OS was auf den Intel ME chips läuft. Dieser Artikel riecht für mich nach Anti-Freie-Software-Propaganda. Ich bin sehr froh, dass Linux unter der GPL Lizensiert ist. Sonst wären Androids wahrscheinlich genauso verschlossen wie Apfel-Schlaufone und Quelloffene ROMs wie LineageOS nicht möglich
iOS basiert wie Android auf einem freien Kern. Ich bin aber auch der Ansicht, dass freie Lizenzen ohne Copyleft immer noch freie Lizenzen sind.
Du kannst Freie Software für dich gern definieren wie du willst. Die Begründung warum die GPL nicht frei ist am Ende des Artikels finde ich auch nicht unbedingt valide, da für Bibliotheken eher die LGPL empfohlen wird, die auch mit proprietärer Software kompatibel ist solange dynamisch gelinkt
Aber ist, wenn man mit proprietärer Software kompatibel sein will, Copyleft nicht mehr oder weniger gegenstandslos?
Nicht wirklich, da modifikationen zu der Bibliothek trotzdem veröffentlicht werden müssen. Die LGPL hat verglichen zur GPL nur eine extra Klausel, die besagt, dass man, in proprietären programmen, dynamisch (vielleicht auch statisch, bin mir nicht sicher) zu der Bibliothek linken kann. Wenn du die Bibliothek für deine Zwecke veränderst musst du den code natürlich veröffentlichen
In der Benutzung ist die Lizenz fast egal, aber natürlich hat die GPL entscheidend dazu beigetragen, wie viel und welche Software für Linux verfügbar ist. Insofern ist es für einzelne Nutzerys eben doch wichtig.
Und die Tatsache, dass beispielsweise das Kubernetes-Ökosystem oder Android keine Copyleft-Lizenzen haben, hat auch recht eindeutige Nachteile, weil es viel öfter vorkommt, dass Bestandteile eines Systems proprietär sind oder in einer Nachfolgeversion proprietär werden.
aber natürlich hast die GPL entscheidend dazu beigetragen, wie viel und welche Software für Linux verfügbar ist.
Stimmt. ZFS zum Beispiel war sehr lange nicht unter Linux verfügbar - die Lizenz von ZFS hätte das zwar erlaubt, aber die GPL nicht… ;-)
Hing das nicht daran, dass Sun eine eigene, absichtlich GPL-inkompatible Lizenz entwickelt hat, um zu verhindern, dass Solaris-Code in Linux auftaucht; Sun sich dann an Oracle verkauft hat und Oracle natürlich keine Lust auf eine Lizenzänderung hatte, obwohl Solaris irrelevant geworden war? Das ist natürlich ein spezielles Beispiel.
Ich nehme aber den Punkt: Mit Lizenzen kann man sich und anderen immer gut in die südlichen Extremitäten fusilieren.
Was aber in viel mehr Fällen von der GPL verhindert wurde, ist, dass einmal verfügbare Software plötzlich proprietär wird. Und wenn mehr Firmen die AGPL unterstützen würden, wäre die Macht von AWS und Azure längst nicht so groß, wie sie es heute ist.
Der ursprüngliche Plan von OpenSolaris war es ja, daraus weiterhin auch ein „kommerzielles“ Solaris abzuleiten. Gepaart mit den eigenen Softwarepatenten von Sun/Oracle kam die GPL da schlicht nicht in Frage, wenn ich die Geschichte richtig verstehe.
Alles richtig. Nur gibt es aber durchaus ganz gute Gründe, warum man eigentlich keine Patentfallen in seinen Open-Source-Projekten haben will. Und dass Sun keine Ahnung hatte, wie Open Source funktioniert bzw. Oracle später alle Sun-Projekte vor die Wand gefahren hat, ist auch nicht die Schuld der GPL. Copyleft-Lizenzen versuchen, das Copyright zu hacken, aber das hat alles Grenzen.
Nein, Oracle hat Sun tatsächlich mit voller Absicht implodieren lassen. Konkurrenz gekauft, Konkurrenz eingestampft, Markt gerettet.
Persönlich nutze ich schon ganz gern mal die CDDL für meine Projekte. Gegenüber der GPL hat sie den Vorteil, dass meine Bibliotheken auch in kommerziellen Produkten genutzt werden können (ich will damit selbst kein Geld verdienen und freue mich, wenn in kommerzieller Software wenigstens zu einem kleinen Teil guter Code drin ist. ;-)) Und gegenüber der MIT-Lizenz hat sie den großen Vorteil, dass sie trotzdem zur Offenlegung des Quellcodes verpflichtet.
Hab von 2.7 bis 3.7 OpenBSD benutzt und fand es damals eher ungeeignet für den täglichen Desktopeinsatz. Habe es dann auf diversen Servern eingesetzt und das ging ganz gut. An den heiligen Dreisatz aus ./configure && make && make install erinnere ich mich aber noch gut. Und dem Grauen, Buildfehler zu beheben. Wollte damals zu viel, was es nicht als Paket gab (wie z.B. PHP).
Hab von 2.7 bis 3.7 OpenBSD benutzt
Was du alles an 2 Tagen schaffst!
2.7, nicht 2.7. 😛
Gibt’s heute alles.
Das glaube ich sofort, aber heute brauche ich es nicht mehr. :) Meine BSD-Kenntnisse sind in der Zwischenzeit auch sehr eingerostet.
Ich sag dazu Nix
Ehre
Fühle mich dadurch, als hätte ich durch die Schale in eine unreife Grapefruit gebissen.
Aber im Ernst, wie benutzt es sich? Hab mich nie tiefer damit beschäftigt, als mir über opensense die Haare zu raufen.
Nach der Installation (die blitzschnell vonstatten geht) benutzt es sich im Wesentlichen genau so wie Linux, nur mit weniger Überraschungen nach einem Update.
Musste noch nie die web GUI von OPNsense verlassen da mein cluster problemlos läuft
Ist das so schlimm?
Welchen Texteditor nutzt du? Ich bin noch nicht von VSCode losgekommen aber electron apps waren zumindest mal problematisch unter BSDs zum laufen zu bekommen. (Hat sich das geändert?)
Electron ist ein nicht notwendiges Übel und es ist ziemlich ok, dass es nicht auf allen Plattformen funktioniert.
Dies vorweggeschickt: Ich war lange zufrieden mit Sublime Text (damals unter Windows), aber auf der Suche nach einer freien Alternative hat es mich zu GNU Emacs verschlagen. (Ich weiß: BSD und GNU - na, so puritanisch bin ich nicht.) Visual Studio Code hatte ich mir (auch unter Windows) mal kurz angesehen, aber ich empfand es eher als lästig mit den zahllosen Popups, der miesen Performance und dem Electron-Unterbau. Als “kleiner” Texteditor für Dinge, für die ich nicht unbedingt ein komplettes IDE hochfahren will (mein Emacs ist doch schon recht vollgepackt mittlerweile), kommt bei mir meist sam zum Einsatz; Sonderfall: auf den Servern, also ohne GUI, nehme ich meist das, was gerade da ist (
nvi,mg,ed, TECO… in der Regel sind das nur einzeilige Konfigurationsänderungen, da ist mir das eingesetzte Werkzeug fast völlig egal).(Oje. Gibt es auf diese Frage eigentlich eine mögliche Antwort, die nicht Folgediskussionen nach sich zieht?)
Ich bin auch eher genervt von VSCode, insbesondere die Integration mit LSP Clients ist gefühlt schlechter statt besser geworden in letzter Zeit. Ich sehe Electron auch eigentlich als eine blödsinnige (oder mindestens blödsinnig umgesetzte) Idee an. Trotzdem war ich mit keinem anderen Editor bis jetzt mehr zufrieden.
Was für mich persönlich das beste Feature von VSCode ist, ist sein Dateistruktur View. Also das was in Vim z.B. NerdTree ist. VSCode integriert die verschiedenen Status der Dateien in diese View (ist die Datei geändert im Sinne von git, hat die Datei warnungen/errors im Sinne von LSP, …). Das finde ich persönlich unglaublich convenient. Vielleicht muss ich mich aber doch nochmal in Emacs reinfuchsen und das mal selber implementieren. Lisp steht sowieso noch auf meiner TODO-Liste.
(Oje. Gibt es auf diese Frage eigentlich eine mögliche Antwort, die nicht Folgediskussionen nach sich zieht?)
Ich hatte aus dem Grund auch kurz gezögert auf den Absenden Knopf zu drücken. Ich hab aber immernoch die Hoffnung, dass da draußen irgendwo ein VSCode in besser rumfliegt das ich einfach nur nicht sehe
Ziemlich sicher, dass es so einen Filetree gibt (teemacs & neotree). Ob die geänderte Dateien anzeigen keine Ahnung. Aber wenn man sich an den Workflow gewöhnt hat, braucht man eh keinen Filetree.
braucht man eh keinen Filetree.
Wie behältst du die Übersicht über geänderte Dateien und noch offene errors/warnings ohne einen Filetree? Hast du dafür eine jeweils eigene View? Oder brauchst du so eine Übersicht in deinem Workflow einfach nicht?
Wofür musst du wissen, ob eine Datei geändert ist? Das sehe ich meistens dann in magit (bestes Git-UI ever), wenn ich entscheide was in den commit kommt.
Ich mach fast nur Python, die Errors und Warnings sehe ich entweder mit LSP direkt für die aktuelle Datei oder in der Python Konsole die ich im unteren Drittel offen hab, wahrscheinlich so wie du auch in VS Code. Mir ist aber eigentlich noch nie passiert, dass ich einen Fehler in einer anderen Datei verursacht habe, die ich gar nicht offen hab? Brauche ich also eigentlich nicht.
Wenn das so ein gängiges Ding ist von VS Code, dann gibt es dazu garantiert auch ein package für Emacs. Oder ist sogar in neotree/treemacs mit drin. Nutze ich wie gesagt auch nie. Für sowas nutze ich immer projectile.
Protip: nutz evil-mode. Wenn schon neue keybindings, dann lern gleich die von vim, die sind eh besser.
Wofür musst du wissen, ob eine Datei geändert ist? Das sehe ich meistens dann in magit (bestes Git-UI ever), wenn ich entscheide was in den commit kommt.
Naja ich nutze keine git-ui und einen groben überblick über die Änderungen zu haben finde ich ganz nützlich um einzuschätzen ob ich jetzt vielleicht mal zwischendurch einen commit machen sollte. Es geht mir dabei nicht um eine Datei sondern um eine Übersicht über das gesamte Projekt.
Mir ist aber eigentlich noch nie passiert, dass ich einen Fehler in einer anderen Datei verursacht habe, die ich gar nicht offen hab? Brauche ich also eigentlich nicht.
Ich maintaine ein paar meiner Projekte schon ein bisschen länger und da kommen manchmal neue Ideen auf wie man etwas besser machen könnte. Wenn man ein Grundkonzept ändert ändert sich eben in vielen Dateien was. Mir hilft es zu sehen wie viel sich ändern müsste um das Konzept so abzuändern wie ich es mir vorgestellt habe. Außerdem gibt es einem eine Art Progressbar wenn man sieht wie langsam aber sicher die Fehler weniger werden.
Wenn das so ein gängiges Ding ist von VS Code, dann gibt es dazu garantiert auch ein package für Emacs. Oder ist sogar in neotree/treemacs mit drin.
Ich habe ein paar Referenzen gefunden, dass man sich zumindest die Git Funktionalität aus ein paar Packages zusammenstückeln kann. Das klingt aber ziemlich fragil ehrlich gesagt und ich weiß nicht ob das dann auch durch die Ordner nach oben propagieren würde. Es ist ja anscheinend nicht so ganz offensichtlich für andere dass das nützlich ist. Bei LSP sind die meisten Editoren dabei stehen geblieben die Errors und Warnings in einer Liste anzuzeigen und das gut genug zu nennen, keine Ahnung ob und wie das dann mit dem gefrickel zum Gitstatus anzeigen zusammenspielen würde.
Okay grober überblick über änderungen mach ich über magit. Spc-g-g und es zeigt mir alle änderungen an, ähnlich zu git status, aber auch aufklappbar usw. Das brauche ich halt auch nur, wenn ich es sehen will, deswegen meiner Meinung nach sinnvoll in einem anderen Buffer versteckt.
Also ich habe den treemacs-git-mode gefunden, der hebt änderungen farblich hervor. Dann gibt es noch einen lsp-treemacs-errors-list-mode, aber wie das funktioniert verstehe ich nicht. Progressbar zu fehlern hab ich durch LSP, indem unten rechts immer steht wie viele Fehler ich hab. Satisfying da keine Zahl stehen zu haben :D
GNU Emacs hat mittlerweile auch ein ziemlich gutes LSP-Paket eingebaut bekommen. :-)
Was für mich persönlich das beste Feature von VSCode ist, ist sein Dateistruktur View. Also das was in Vim z.B. NerdTree ist.
Das ist in GNU Emacs auch schon vorhanden. Es gibt aber natürlich Alternativen.
Lisp steht sowieso noch auf meiner TODO-Liste.
Wissenswert: Emacs Lisp ist älter als Common Lisp und hat manche Eigenheit, die in späteren Lisps “besser” gelöst sind. Um ein Gefühl für Lisps zu bekommen, ist es aber sicherlich ein guter Anfang; und GNU Emacs ist in der Lispwelt allgemein ein beliebtes IDE für die meisten Dialekte. Das hat gute Gründe.
Warum???
Weil gut.
Muss sagen, ich hab das schon 2mal probiert, ein BSD auf meinem Laptop zu installieren.
Ich fand die Idee attraktiv, dass Kernel und Userland “aus einer Hand” kommen und nicht alles so zusammengestückelt ist wie bei Linux.
Bin dann leider an verschiedenen Problemen gescheitert, hauptsächlich aber die Netzwerkeinrichtung über WLAN.
Inzwischen bin ich mit Arch so zufrieden dass sich das Thema für mich erledigt hat.Bin dann leider an verschiedenen Problemen gescheitert, hauptsächlich aber die Netzwerkeinrichtung über WLAN.
Das kann an verschiedenen Ursachen liegen, die sicherlich lösbar gewesen wären. Manche BSDs sind störrischer als andere, was Treiber betrifft. ;-)
Ja, aber nach 2 Tagen rumprobieren hat die Neugier nachgelassen, weil ich mit Linux eigentlich keine Probleme hab, die BSD lösen würde.
Das kann ich verstehen.
Ich habe letztens Mal aus Spaß OpenBSD auf meinem iBook G3 installiert. So weit ich weiß ist OpenBSD das letzte moderne OS, das es noch für 32bit PowerPC Macs gibt. Hat problemlos funktioniert , aber Leider hab ich es nicht geschafft xorg zum laufen zu bekommen, so dass ich keine grafische Oberfläche bekommen habe. Irgendwann hatte ich dann keine Lust mehr, aber vielleicht probiere ich es nochmal
So weit ich weiß ist OpenBSD das letzte moderne OS, das es noch für 32bit PowerPC Macs gibt.
Nee. :-)
Leider hab ich es nicht geschafft xorg zum laufen zu bekommen, so dass ich keine grafische Oberfläche bekommen habe.
OpenBSDs Version von X (“Xenocara”) wird bei der Installation eigentlich “automatisch” installiert und aktiviert, wenn man die richtigen Häkchen setzt (du solltest die Pakete nicht abwählen und bei der Frage, ob du X verwenden möchtest, natürlich ein “y” setzen; zur Einrichtung siehe auch FAQ). Genaueres kann ich ad hoc natürlich nicht diagnostizieren. ;-)
Installiert wurde das alles. Es gibt nur wegen dem alten Display und der uralten ATI rage Grafikeinheit ganz bestimmte Parameter die man in der config manuell setzen muss, aber da hab ich nicht die richtigen gefunden. Hatte mich damals an dem Video hier orientiert https://youtu.be/-7gSMEsF3Q0?si=yYRBI3cNmpieVKM2 Seine config hat für das iBook aber leider nicht funktioniert. Vielleicht probiere ich es Mal mit NetBSD :)
Ah, verstehe. Mein letztes manuelles Konfigurieren von X war in den 90ern, da bin ich leider auch keine große Hilfe.
BSD, ist das sowas ähnliches wie BDSM? Und das machst du dann auch noch in der Öffentlichkeit? Die Jugend von heute.
Spießer!