Login
Newsletter
Werbung

Thema: Debian GNU/Hurd 2019 veröffentlicht

42 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Oiler der Borg am Mo, 8. Juli 2019 um 15:18 #

hat es im Produktiveinsatz :cry:


=======================

Abgesehen davon finde ich den Artikel etwas irreführend geschrieben, Debian Hurd ist keine weitere Linuxdistribution als zusätzliches Standbein, sondern ein eigenes Betriebssystem mit einem überreifen Microkernel
Debian passt im wesendlichen einen Teil der Anwendungen und Tools aus dem Standardrepo an GnuHURD an, damit das überhaupt testbar ist...
Vom Produktiveinsatz ist die Nummer wohl noch ein paar Dekaden entfernt!

Dieser Beitrag wurde 1 mal editiert. Zuletzt am 08. Jul 2019 um 15:26.
1
Von Drubadix am Mo, 8. Juli 2019 um 16:34 #

"Hurd kommt!"

Nur damit das mal gesagt ist.
Das muss schließlich so sein.

  • 0
    Von schmidicom am Mo, 8. Juli 2019 um 16:46 #

    Ja, nämlich dann wenn sich erst recht keine Sau mehr dafür interessiert.

    PS: Ich hätte ja nichts gegen Konkurrenz einzuwenden aber dann soll sie bitte auch eine sein, das Ding ist doch einfach nur peinlich.

    EDIT: Fuchsia war interessant, sowohl allgemeines Interesse als auch finanzielle Unterstützung (kein wunder bei Google, wenn die es nicht haben wer dann?) war vorhanden.

    selbst Haiku hat da mehr zu bieten...

    Dieser Beitrag wurde 4 mal editiert. Zuletzt am 08. Jul 2019 um 16:52.
    • 2
      Von rgsidler am Mo, 8. Juli 2019 um 18:27 #

      Was genau ist denn daran peinlich? Es ist ein Projekt, an dem viele mitarbeiten, weil sie an der Umsetzung einer These interessiert sind.
      Niemand hat je behauptet, dass es für den Produktivbetrieb gedacht ist; genauso wenig muss sich irgendjemand damit persönlich beschäftigen oder gar versuchen, es zu installieren.

      Ohne die Erkenntnisse aus Projekten gäbe es keinen Fortschritt. Dass dabei das eine oder andere scheitert, ist nur natürlich.

      Nichtsdestoweniger bleibt jeder Versuch, etwas Neues zu schaffen, achtenswert und sollte nicht mit solchen Kommentaren herabgewürdigt werden.

      Es geht hier nicht um Konkurrenz, sondern um eine intellektuelle Herausforderung und, um Sie zu zitieren, "keine Sau" interessiert sich dafür, ob Sie oder ich das jemals nutzen werden.

      Also lassen wir doch die Meldung einfach stehen und finden es toll, dass es noch Menschen gibt, die Ihre Stärke nicht mittels Pferdestärken oder Geld zeigen, sondern mit ihrem Geist tatsächlich etwas schaffen, was bisher noch keinem gelungen ist.

      Es grüsst


      Roland

      • 1
        Von glasen am Mo, 8. Juli 2019 um 19:23 #

        Niemand hat je behauptet, dass es für den Produktivbetrieb gedacht ist;
        Hurd sollte mal der Kernel für das GNU-Betriebssystem werden. Also war der Kernel schon für den Produktiveinsatz gedacht. Das war so um 1990. Seit dieser Zeit ist Hurd in Entwicklung.

        1
        Von Oiler der Borg am Mo, 8. Juli 2019 um 23:25 #

        Das hat irgendwie noch eine geschichtliche Komponente ;)

        Als der legendere "LINUX is obsolete"-Zwist von Andy Tanenbaum losgetreten wurde, stand RMS breit in zweiter Reihe und postulierte, das wäre ja nur eine kurzfristige Zwischenlösung, bis der Messias unter den Betriebssystemen, eben GNU/HURD ein völlig neues Zeitalter einleitet!

        Nach knapp 30Jahren des Versagens sei doch hin und wieder ein kleines Bisschen Häme toleriert :evil:

        • 1
          Von gnu am Di, 9. Juli 2019 um 00:28 #

          Häme gerechtfertigt? Wohl kaum. Dazu reicht es bereits die Beteiligung von Unternehmen am offiziellen Linuxkernel unter Betrachtung zu nehmen und damit auch die Abhängigkeit von eben diesen. Daran hängen also geschäftliche Interessen und ein entsprechendes Modell ebenso während Hurd selbst auf freiwilliger Basis entwickelt wird. Deutlich auch an der weit kleineren Basis Beitragender zur Quelltextbasis zu erkennen. Sicherlich war es damals etwas vorschnell in der Reaktion, ändert aber nichts daran wo konkret die Problemstellungen lagen und weiterhin liegen und welchen Interessen vorzugsweise mehr Gehör geschenkt worden ist. Kleiner Tipp: Mitnichten der freiheitlichen Ausgestaltung und die Häme ist dahingehend einfach nur Ausdruck von offenkundiger Abwertung und vielsagend für die Art und Herangehensweise. Eben wie auch die klare Differenzierung zwischen "Open-Source" und wirklich freier, quelloffener Software.

      1
      Von asdfghjkl am Do, 18. Juli 2019 um 14:02 #

      Beitrag 4 mal editiert und doch vollkommen argumentfrei?
      Sowas finde ICH einfach nur peinlich...

2
Von Gokh am Mo, 8. Juli 2019 um 17:59 #

Muss ja nicht jeder hier spannend finden, aber mich freut es.
Auch wenn noch lange nicht produktiv einsetzbar, finde ich es klasse, dass es
weiterentwickelt wird.
Eine Alternative zu M$ neusten Lieblingskind Linux wäre schon eine schöne Vision.

Danke für den Artikel.

  • 2
    Von Oiler der Borg am Mo, 8. Juli 2019 um 23:43 #

    BSD anyone ?

    Ich setze mal übermütig einen Fünfer (nur für die ersten fünf Gegenwetter!) darauf, das wir nach der bedauerlicher " fortschreitenden Widowisierung" von Linux der nächste Erbe.....

    • 1
      Von gnu am Mo, 8. Juli 2019 um 23:58 #

      Das Problem bei BSD ist die Lizenz selbst: Freiheiten gut und schön. Aber kaum bis gar keinen wirklichen Schutz und eine meines Erachtens eher fragwürdige Definition von Firmware-Blobs beispielsweise. Kann ja Jeder halten wie gewünscht und man kann auch ein OpenBSD möglichst frei von proprietären Blobs halten. Dennoch ist mir beispielsweise da ein Linux-libre Kernel weit lieber, da dieser erst gar nicht dazu verleitet und im Hinblick darauf wie "unfrei" die x86-Plattform als Ganzes selbst bereits ist erübrigt sich die Diskussion insofern auch: Aus der Perspektive wirklich freier Hardware ein bereits sinkendes Schiff und RISC-V wäre hier schon interessanter.

      Insofern viele Aspekte für eine weitergehende Betrachtung! :)

      • 2
        Von kraileth am Di, 9. Juli 2019 um 08:22 #

        Für jemanden mit Deinem Benutzernamen schreibst Du angenehm sachlich und machst gewisse Aussagen als Deine Meinung kenntlich, statt Dogmen zu verkünden. Vielen Dank dafür! Ich möchte deswegen ebenfalls freundlich in Form zweier Fragen eine Gegenposition einwerfen, die aus meiner Sicht der Betrachtung lohnt um nicht ein einseitiges Bild der Lizenzfrage zu erhalten.

        1) Wieso ist die Lizenz ein Problem? Ich behaupte hier einfach mal das Gegenteil: Einer der großen Vorteile von *BSD ist die Lizenz. Durch ihre permissive Natur stellt sie das eigentlich Wichtige in den Mittelpunkt - nämlich den Menschen als Wesen mit eigener Entscheidungsgewalt über ethisches oder unethisches Handeln. Nur dadurch, daß dieser die freie Wahl hat, aus sich selbst heraus eine ethische Entscheidung zu treffen, ermöglicht diese Art von Lizenz der Menschheit, moralisch zu reifen. Copyleft - und damit der Zwang zum Handeln nach vorher festgelegten Mustern - eignet sich zugegebenermaßen natürlich besser, wenn man einen Kult um den Code zimmern möchte. Ich frage mich inzwischen aber ehrlich, warum jemandem die Freiheit des Codes wichtiger sein sollte als die Freiheit des Menschen. Der Quellcode ist ein Ding, noch dazu kein materielles. Er kann mit seiner Freiheit nichts anfangen, er kann sie nicht begründen, kann sie nicht einmal wertschätzen. Dafür den Menschen die Freiheit nehmen? Wohlgemerkt: Allen. Und das nur, weil einige diese Freiheit in einer unerwünschten Weise wahrnehmen würden?

        2) Was meinst Du damit, daß es bei *BSD keinen wirklichen Schutz gebe? Keinen Schutz vor eigennütziger/kommerzieller Verwertung durch „lachende Dritte“? Das ist richtig und aus meiner Sicht sogar sehr wichtig, um eigene Entscheidung zu ermöglichen und nicht einer Lehre folgen zu müssen, die sich einmal der Gründer einer Bewegung ausgedacht hat. Besonders betont sei hierbei aber: Der permissiv lizenzierte Quellcode ist ausreichend geschützt! Er ist frei und niemand kann ihn der Allgemeinheit wegnehmen. Natürlich kann jemand ein Projekt davon ableiten und entscheiden, dies nicht mehr mit der Allgemeinheit zu teilen. Aber, auch wenn gewisse Kreise es gerne anders aussehen lassen, dadurch verschwindet der ursprüngliche Quellcode nicht und er steht weiterhin allen Interessierten zur Verfügung.

        Blobs sind ein eigenes Thema. Ich mag sie auch nicht sehr, kann aber die Argumentation verstehen, die z.B. OpenBSD ins Feld führt (entweder die Firmware läuft direkt auf den Geräten oder aber sie wird vom Betriebssystem nachgeladen. Letzteres ist auch nicht schlechter als ersteres, bei dem die Hardware auch mit einem unfreien Blob läuft, nur eben unsichtbar). Hinsichtlich RISC-V sind wir allerdings einer Meinung. Ich habe diese Plattform von Anfang an mit Begeisterung beobachtet und hoffe weiterhin darauf, daß wir irgendwann brauchbare und offene Hardware bekommen.

        • 2
          Von blablabla233 am Di, 9. Juli 2019 um 10:06 #

          Ich nutze fast auschliesslich BSD's im Serverbereich.
          Die Lizenz ist fuer mich auch das optimum, denn wenn ich eines auf gar keinen Fall in der Software Entwicklung haben will, dann sind das Anwaelte.
          Auch brauche ich keinen Gnu-Jesus.

          1
          Von gnu am Di, 9. Juli 2019 um 11:09 #

          Vielen Dank für die Anmerkungen. Grundsätzlich bin ich kein Freund davon dogmatisch an Sachverhalte heranzugehen sondern mit Prinzipien wie auch grundlegend idealistisch.

          Zu 1) Für mich ist Beides wichtig und genau deswegen setze ich auch Beides in den Mittelpunkt. Den freier Quelltext bietet durchweg die Möglichkeit zur Modifikation und damit auch weiterhin einer Wahlmöglichkeit selbst entscheiden zu können. So kann man ja auch einen Libre-Kernel selbst nach eigenen Maßstäben erstellen und modifizieren. Denn die Emanzipation der Nutzer*Innen steht dabei durch Copyleft-Lizenzen im Mittelpunkt, aus meiner Perspektive gesprochen. Und die "Freiheit des Quelltextes" ermöglicht in meiner Betrachtung erst weitere Freiheiten der Nutzer*Innen.

          Zu 2) Der Schutz bezieht sich darauf, dass Risiken bestehen sofern abgeleitete Projekte Mehrheiten bilden und kein Quelltext zu ihnen entsprechend auffindbar ist. Der eigentliche Quelltext steht davon unbenommen und sicherlich kann man das der Allgemeinheit nicht einfach wieder nehmen. Dennoch ist dabei der Mensch wie auch sein Verständnis von "Freiheit" ein wichtiger Faktor. Wenn man sich selbst wichtiger nimmt als Andere, wird es immer schwierig und zusehends erschwert.

          Es gibt insofern neben der rein technologischen Komponente immer auch eine soziale Ableitung. Tatsächlich sind "Freiheiten Aller" gleichwertig zu beachten und entsprechend ist für mich die Emanzipation der Nutzer*Innen oberste Priorität.

        1
        Von Ghul am Di, 9. Juli 2019 um 21:02 #

        Die Lizenz bei BSD ist für Entwickler besser, weil sie mehr Freigeiten erlaubt, ohne das man Gefahr läuft von Rechtsanwälten abgemahnt zu werden.

        Qt steht bspw. unter der LGPL, aber die meisten Firmen müssen sich eine kommerzielle Lizenz holen, weil ihr proprietärer Code in der Praxis doch nicht so einfach von dem komplexen LGPL Code zu trennen ist, was aber zur Einhaltung der LGPL notwendig ist.
        Du magst jetzt sagen, dass Firmen das verdienen, die ihre Software nur als Close Source Software freigeben, aber du übersiehst hier völlig, dass es auch gerade diese Firmen sind, die wieder Code zurücksteuern würden und somit das Projekt als ganzes vorantreiben.

        Eine sehr freie Lizenz wie die MIT oder BSD Lizenz schadet einem Open Source Projekt also gar nicht, wie du irrtümlicherweise annimmst, sonder es hilft ihm.

        Die SDL 1.2 hat bspw. kaum eine Firma angerührt, der Grund war der, weil diese eben unter der LGPL Stand.
        Man hat das Problem beim SDL Projekt erkannt und Version 2.0 steht daher unter einer wesentlich freieren Lizenz und die Folge davon ist, dass Firmen sich an der Entwicklung von SDL beteiligen, weil sie viel eher sich für die SDL entscheiden, denn im Zweifelsfall steht bei der kein Rechtsanwalt vor der Tür mit einer teuren Klage. Dieses Problem kann man bei der LGPL nie gänzlich ausschließen und man muss höllisch beim Linken aufpassen.

        Aus dem Grund scheitern auch alle 3d Engines die unter der LGPL stehen.
        Die Crystal Space Engine, OGRE Engine usw. rührt kein kommerzieller Spielehersteller an, eben weil die alle unter der LGPL stehen und somit immer das Problem mit möglichen rechtlichen Angriffen bei Fehlern besteht.
        Die Godot Engine blüht dagegen wie keine andere auf und wird von kommerzielen Indieentwicklern vielfach unterstützt und der Grund dafür ist ihre freie MIT Lizenz.


        Eine freiere Lizenz als die LGPL oder gar GPL sorgt also dafür, dass mehr bezahlte Entwickler daran mitwirken.

        Warum das bei Linux anders ist, liegt lediglich daran, weil Linux wesentlich schneller gewachsen ist, als FreeBSD und Co.


        Was auf dem Markt somit definitiv fehlt ist eine freie crossplattform fähige GUI Bibliothek unter einer freien Lizenz wie eben die MIT oder BSD Lizenz.

        • 0
          Von gnu am Di, 9. Juli 2019 um 22:26 #

          Dürfte eine relativ endlose Debatte werden, allerdings wurden auch Spiele mit OGRE erstellt und kommerziell weiter vertrieben. Entsprechende Beispiele: Die Ankh-Serie wie auch Torchlight.

          Und Firmen steuern schlicht aus einzig einem Eigeninteresse bei: Bei einem ausgewogenen Projekt mag dieses vielleicht noch aufgefangen werden. Allerdings sieht man bereits beim Linux-Kernel wie auch beim Mesa-Stack wohin die Reise dann geht: Ohne proprietäre Firmware-Blobs eine AMD-Grafikkarte betreiben? Wohl kaum. Von NVidia und Noueveau kann man ein leidiges Bildnis zeichnen, immerhin ist AMD hier offener. Und auch Intel hat entsprechend in neueren Versionen das umgesetzt.

          Ich übersehe insofern da nichts völlig sondern schließe bewusst ein, dass Unternehmen Quelltext beisteuern. Allerdings ist der Ausgang vorzugsweise zu oft vorgezeichnet und genau deswegen hege ich da weiterhin eine klare Position, die genau das kritisiert.

          Eine freiere Lizenz mag initial für mehr Mitarbeit und Beteiligung sorgen, sie schließt aber auch gleichermaßen nicht aus, dass Abhängigkeiten geschaffen und dann später nur für kommerzielle Interessen ausgenutzt werden. Dann sind Freiheiten auch nicht sonderlich viel wert, da dann Unternehmen darüber entscheiden und mitnichten eine Gemeinschaft von Interessierten. Ganz davon zu schweigen, dass der Quelltext dann auch nicht zwangsweise weiter zur Verfügung gestellt werden muss. Leidtragende sind dann die Nutzer*Innen und gleichermaßen Entwickler*Innen!

          • 0
            Von Ghul am Di, 9. Juli 2019 um 23:19 #

            Ja, die paar Spiele kannst du an einer Hand abzählen.

            Und Firmen steuern schlicht aus einzig einem Eigeninteresse bei:
            Das mag so sein, aber letzten Endes hilft es oft allen.

            Wo nutzt NVidia OSS? Die machen nur Treiber für Linux, weil deren prof. Kunden (Z.b. Filmindustrie) das so wollen und natürlich weil sie der Konkurrenz nicht das Feld alleine überlassen wollen.
            Ansonsten ist NVidia keine Firma, die jetzt umfangreich mit OSS selbst arbeitet, insofern ist die kein gutes Beispiel.

            Eine freiere Lizenz mag initial für mehr Mitarbeit und Beteiligung sorgen, sie schließt aber auch gleichermaßen nicht aus, dass Abhängigkeiten geschaffen und dann später nur für kommerzielle Interessen ausgenutzt werden.
            Was für Abhängigkeiten?
            Freier Code ist frei.

            Dann sind Freiheiten auch nicht sonderlich viel wert, da dann Unternehmen darüber entscheiden und mitnichten eine Gemeinschaft von Interessierten.
            Diejenigen, die die Entwicklungsarbeit erledigen, das sind auch die, die entscheiden, wo der Weg hinläuft.
            Das war bei Open Source Software noch nie anders und hat nichts mit von der Gemeinschaft entwickelt vs. von Firmen entwickelt zu tun.

            Ganz davon zu schweigen, dass der Quelltext dann auch nicht zwangsweise weiter zur Verfügung gestellt werden muss.
            Bei gesunden aktiven Projekten würde ein proprietär agierendes Unternehmen, das nichts zurück gibt, immer riskieren, dass es dem offiziellen öffentlichen Code hinterher rennt, weil dieser sich von deren Code weiter und somit weg entwickelt.

            Will man das als Untenehmen nicht und will man Kosten bei der eigenen Entwicklung einsparen, dann wird man den Code lieber in den offiziellen öffentlichen Code beisteuern, denn am Ende spart das Geld.
            Und was Unternehmen am meisten interessiert ist nun einmal das verdienen von Geld, die Gewinnmarge wird hierbei von den Kosten mit bestimmt.

            Die Angst die du da hast, besteht also allerhöchstens bei sehr großen Konzernen, die sich unterschiedliche Codezweige auch leisten können.
            Der größte Teil der Entwickler, also die tausende an Mittelständischen Unternehmen usw.. die werden ihren Code lieber in den offiziellen Code einpflegen wollen.
            Insofern schadet eine freiere Lizenz der Gemeinschaft überhaupt nicht, sondern die Entwicklung geht durch bezahlte Entwickler aktiv voran und das weit aus besser, als wenn es diese bezahlten Vollzeitentwickler nicht geben würde.
            Der Positiveffekt überwiegt ganz klar und ist größer, als der Negativaspekt durch die ein zwei Konzerne, die alles für sich behalten wollen.

            • 0
              Von gnu am Mi, 10. Juli 2019 um 00:16 #

              Sagte ich doch: Endlose Diskussion, weil es nicht um Sachverhalte sondern das berühmte "letzte Wort" geht. Wegen mir sei das wem auch immer nun überlassen. Allerdings dazu noch Anmerkungen meinerseits:

              - NVidia macht nur das was "Kunden" wollen? Na großartig, müsste die Kundschaft ja auch fordern, dass die proprietären Treiber in die quelloffenen Entwicklungen übergeben werden. Ach passiert nicht? Warum bloß ... ach ja, weil ein Großteil der "Kunden" auch im Privatbereich lieber dem bequemen Weg widmet und so den Weg des geringsten Widerstands geht.

              - Ich habe von freier, quelloffener Software geschrieben und nicht von "Open-Source". Es besteht für mich ein Unterschied zwischen FOSS und FLOSS.

              - Weiterhin wird deinerseits ignoriert was ich über Abhängigkeiten geschrieben habe: Schön, wenn man BSD-Basis nutzt. Und wenn die Nutzerbasis sich dann dem proprietären Fork einzig und allein zuwendet hilft das konkret wem? Es gibt eine technologische und eine soziale Komponente!

              Du verwechselst auch Ursache und Wirkung: Ich habe keine Angst sondern bewerte einzig und allein konkrete Tatbestände. Einen Positiveffekt kann ich mitnichten darin entdecken, wenn sich Unternehmen in Projekte mischen und dort ihre Interessen entsprechend nach vorne bringen. Das mag auf den ersten Blick natürlich vollkommen legitim erscheinen, aber auf den zweiten Blick wird das Ungleichgewicht überdeutlich. Als würde ich Microsoft auf einmal diese "Liebe für Open-Source" glauben. Mitnichten: Anderes Vorgehen mit dem gleichen Ausgang - Embrace, Extend and Extinguish. Es sind auch mitnichten "nur" ein oder zwei "Konzerne" sondern weit mehr oder vergisst du da so Einige in der Liste? Google, AT&T, Cisco, Fujitsu, Hitachi, Huawei, IBM, Intel, Microsoft, NEC, Oracle, Qualcomm, Samsung, Tencent, VMWare, Facebook, Citrix, Juniper, Toshiba, Toyota, ja selbst Adobe ist zumindest in der Förderung eingetragen (und die Liste ist noch weit länger für Linux). Das sind Tatsachen und du versuchst sie hier zu marginalisieren. Insofern bin ich auch raus aus der Debatte!

              Bezüglich OGRE solltest du übrigens wirklich deine Informationen auf den aktuellsten Stand bringen denn es wird die MIT-Lizenz genutzt (Link).

              • 0
                Von Ghul am Mi, 10. Juli 2019 um 03:19 #

                Einen Positiveffekt kann ich mitnichten darin entdecken, wenn sich Unternehmen in Projekte mischen und dort ihre Interessen entsprechend nach vorne bringen.

                Wenn Vollzeitentwickler mitmachen, weil die Firmen das bezahlen, dann kriegst du halt Feature A, B, C, D, E, F, G, H, I usw. und das alles in einem Jahr.

                Wenn die alle nicht mitmachen wollen, weil deine Lizenz zu restrikitv, also GPL oder LGPL ist, dann kriegst du nur Feature C, E und I und das ganze dauert dann 5 Jahre.

                So, was ist nun besser?
                Und wie alt willst du werden, bis du alle Feature von A bis I in einer rein von der Community in der Freizeit entwickelten Version erhältst?

                Und das möglicherweise noch gebastelt, anstatt professionell entwickelt. Weil Freizeitentwickler oftmals noch recht jung sind, also in die Schule oder in die Uni gehen und somit die Freizeit haben womit ihnen dann aufgrund ihres jungen Alters aber auch die Erfahrung fehlt, was zum Gebastel führen kann, während die erfahrenen Vollzeitentwickler, gar keine Lust haben in der Freizeit etwas zu Programmieren, weil sie Abwechselung im Alltag brauchen, aber dafür, wenn sie dann programmieren, auch ihre echte Erfahrung einbringen können.

                Also kriegst du in Variante Freizeit nur C', anstatt C.

                Es sind auch mitnichten "nur" ein oder zwei "Konzerne" sondern weit mehr

                Je mehr mitmischen, desto demokratischer bewegt sich das Projekt für alle in eine gewünschte Richtung und desto weniger bestimmt ein Konzern, was damit passiert.
                Insofern ist die GLPL bzw. GPL gegenüber der freieren BSD oder MIT Lizenz sogar gefährlicher, eben weil weniger Unternehmen mitmachen werden.

                - Ich habe von freier, quelloffener Software geschrieben und nicht von "Open-Source". Es besteht für mich ein Unterschied zwischen FOSS und FLOSS.
                Völlig unnötiger Beitrag. Aus dem Kontext geht klar hervor, worüber wir sprechen. Nämlich um GPL und LGPL sowie BSD und MIT Software.
                Wenn das für dich kein FOSS oder FLOSS ist...

                Bezüglich OGRE, dann aktualisiere den WP Artikel.
                Aber gut das du das sagst, denn es gibt mir Recht.
                Die haben jetzt wohl gesehen, dass die Godot Engine viel stärker benutzt wird, weswegen sie nun bei OGRE einen Lizenzwechsel durchgeführt haben. Also gleiches Spiel wie bei der SDL, aus Fehlern lernen, bedeute das.
                Freiere Lizenzen wie die MIT und BSD Lizenz sind somit besser als die GPL oder LGPL.

                0
                Von Verfluchtnochmal-05995bd7b am Mi, 10. Juli 2019 um 05:00 #

                > Einen Positiveffekt kann ich mitnichten darin entdecken,
                > wenn sich Unternehmen in Projekte mischen und dort
                > ihre Interessen entsprechend nach vorne bringen

                Weil du blind bist

                Wenn Goolge, Netflix, Facebook zum Kernel beitragen weil sie Linux kommerziell nutzen und einen schönen Teil des Internet-.Traffcis tagtäglich abwickeln siehst du keinen Vorteil wenn deren Verbersserungen im TCP-Stack im nächsten linux-release für alle die auch Server betreiben inkludiert sind?

                Du kannst mal davon ausgehen dass etwas was deren Anforderungen genügt deinen Servern nicht schadet

                zstd = Facebook
                brotli = Google

                [root@firewall:~]$ cat /proc/pressure/cpu
                some avg10=4.35 avg60=0.94 avg300=0.25 total=3654559930

                Dafür sage ich danke Richtung Facebook

                • 0
                  Von gnu am So, 14. Juli 2019 um 02:18 #

                  Ach echt? Na dann sage ruhig "Danke" in Richtung von Facebook und zieh weiter in Richtung Pragmatismus. Hübsches Cherrypicking, um sich schönreden zu können wie weit das ganze Thema "freie, quelloffene Software" bereits im Bereich der Kommerzialisierung angekommen ist.

                  • 0
                    Von Gorzelniaski am Mo, 15. Juli 2019 um 14:31 #

                    Ist der Code frei oder nicht ? Ist der Code quelloffen oder nicht ? Wäre dir lieber, das der Code vom faschistischen Großrat oder von irgendeinem stalinistischen Zentralkomitee verwaltet werden würde ?

1
Von gnu am Mo, 8. Juli 2019 um 18:07 #

Hurd ist auch als Paket im Repository von GuixSD entsprechend verfügbar (Link). Und insofern ist der offizielle Linuxkernel schon zu hinterfragen und wenn überhaupt GNU/Linux-libre zu verwenden! ;-)

1
Von Tessterr am Mo, 8. Juli 2019 um 18:49 #

Sorry ich hab es immer noch nicht installiert zum test

1
Von user am Di, 9. Juli 2019 um 10:24 #

Es sieht so aus als würde HURD eine Mischung aus UNIX und Plan9 sein wollen, also warum nicht gleich Plan9 nutzen.

Alternativen zu GUI Programmen und Klick OS mit guten Unix fähigkeiten, sollte man Haiku nutzen.

Wer ein wirkliches UNIX braucht nutzt OpenBSD, FreeBSD.

Wer was komplett eigenes Bauen will mit guter Hardware Unterstützung, sollte sich was mit den Linux Kernel bauen.

  • 2
    Von djaxa am Di, 9. Juli 2019 um 12:24 #

    Wieder mal vergesse: Die Solaris-Derivate auf Illumos-Basis, z.B. OmniosCE oder OpenIndiana... Vor allem als Server-OS tauglich. :D

    Djaxa

    1
    Von Oiler der Borg am Di, 9. Juli 2019 um 14:15 #

    Hurd ist schon was eigenes , und an gewissen Ecken konzeptionell sogar ganz chique (etwa Gerätetreiber im Userspace), aber es kommt nicht vom Fleck

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Jul 2019 um 14:15.
    1
    Von klopskind am Di, 9. Juli 2019 um 16:32 #

    Es sieht so aus als würde HURD eine Mischung aus UNIX und Plan9 sein wollen, also warum nicht gleich Plan9 nutzen.
    GNU Hurd wurde in erster Linie als direkter FLOSS-Ersatzkandidat für traditionelle Unix-Kernel entworfen. Entwurfsvorgabe hierfür waren die Implementierung diverser Protokolle auf Basis des GNU Mach Microkernel bzw. dessen IPC-System. Die bestehenden Unix-Konzepte wurden quasi mit anderen Techniken reimplementiert und nicht signifikant erweitert.
    Seit 1990 steht es unter der Schirmherrschaft des GNU-Projekts, und ist seitdem unter der GPL (aktuell GPL2+) lizenziert. Die Entwicklung hielt nicht Schritt mit den Anforderungen und Erwartungen, bis sie mit dem Erfolg von Linux als FLOSS-Alternative quasi stagnierte.
    Quellen: [0], [1]

    Plan 9 hingegen war der Versuch ein verteiltes Betriebssystem auf Basis bestehender Unix-Konzepte zu errichten und begann als reines Forschungsprojekt in den Bell Labs ohne direkte Anwendung in der Praxis. Dafür waren diverse Erweiterungen und neue Konzepte nötig. Das Mantra lautete "everything is a file". Eine Eigenschaft, die andere unixoide Betriebssysteme teilweise übernommen und implementiert haben, was unter Anderem ein Grund war, weswegen Plan 9 selbst nicht populärer.
    Es war erst 1995 öffentlich verfügbar (nur für nicht-kommerzielle Zwecke), und zuvor - seit 1992 - nur an Universitäten. Seit 2002 war es schließlich unter der Lucent Public License verfügbar (kein Copyleft, nicht GPL-kompatibel). Erst seit 2014 wurde es unter der GPL2 verfügbar.
    Quellen: [2], [3]

    Haiku ist eine Reimplementierung des modularen BeOS als Betriebssystem für den PC (Hauptzielkundschaft Desktop-Anwender), wobei die Kompatibilität zu BeOS inzwischen stark eingeschränkt ist. Es verwendet einen Hybridkernel und ist in C++ geschrieben, und bietet eine durchgehend objektorientierte Entwickler-API. Es ist weitestgehend POSIX-kompatibel.
    Die Erstveröffentlichung war 2002. Seit 2003 steht es unter Haiku, Inc., einer NPO mit Sitz in Rochester, NY. Es ist größtenteils MIT-lizenziert.
    Quellen: [4], [5]

    So gesehen finden sich deutliche Unterschiede - sowohol technischer, als auch zeitlich-juristischer, sowie philosophisch-organisatorischer Natur, sodass die Projekte nicht direkt miteinander vergleichbar sind.

    Wer ein wirkliches UNIX braucht nutzt OpenBSD, FreeBSD.
    Was ist ein "wirkliches UNIX" denn? Die einzige mir bekannte, derzeit gängige Definition von UNIX ist die markenrechtliche, siehe hier. Die hier aufgelisteten Systeme sind UNIX-zertifiziert. Weder OpenBSD noch FreeBSD sind darunter.
    Falls Sie darauf anspielen wollten: Die BSDs sind historisch gesehen enger verwandt mit dem traditionellen Unix als es Haiku, GNU Hurd, Plan 9, Minix oder Linux sind, siehe hier.

    1
    Von Ghul am Di, 9. Juli 2019 um 21:16 #

    Haiku hat keine Benutzer- und Rechtetrennung.
    Das ist ein OS für Einzelplatzsysteme und daher allein aus Sicherheitsgründen schon in der heutigen Zeit ein absolutes NoGo.

    Und solange man da bei Haiku nichts ändert, was man ja auch nicht will, weil man unnötigerweise die Kompatibilität zu BeOS aufrecht erhalten will, wird sich da auch nicht viel ändern.

    Unnötig ist es meiner Meinung nach deswegen, weil die ganze alte closed source Software, die für BeOS erschienen ist, schon so alt ist und es somit besseres aufn dem Markt gibt und diese verkauften Stückzahlen dieser CS Software so eine Verbreitung hat, dass man sich die Kompatibilität problemlos sparen könnte.
    Denn alte Zöpfe verhindern auch neue Konzepte.

    Was Haiku am Anfang vielleicht einen Schwung an Entwicklern gebracht hat, schadet Haiku am Ende, weil die das gesamte Projekt an das Konzept eines alten Eisen orientieren müssen.

    • 0
      Von user am Mi, 10. Juli 2019 um 12:07 #

      Haiku hat sehr wohl user rechte, genau so wie in linux, bsd ...

      "multiuser support is included at the kernel/FS level by default and has been for some time, so chown/chmod work, as does useradd & etc. So you can set up SSH access to your machine using this."

      • 0
        Von Ghul am Mi, 10. Juli 2019 um 18:57 #

        In der GUI merkt man davon nichts. So war das jedenfalls bei meinem letzten Test.
        Es gab weder einen Multiuserlogin, noch irgendwo eine Konfiguration wo man das einstellen konnte. Die Prozessansicht verriet darüber auch nichts, dass diese bestimmten Nutzern zugewiesen werden würden.

        Und BeOS war nie ein Multiuserbetriebssysytem zu dem Haiku kompatibel sein will.

        Wenn sich da also etwas getan hat, dann lediglich in letzter Zeit und nicht von Beginn an der Entwicklung.
        Wer weiß ob das überhaupt gut integriert ist oder einfach nur oben drauf gepappt ist, so wie bei Win9x. Bei dem man auch mehrere Benutzerprofile anlegen konnte, Sicherheitstechnisch das aber gar nichts brachte, da alle Nutzer schlicht Adminrechte hatten.

      0
      Von klopskind am Mi, 10. Juli 2019 um 13:21 #

      1. Mir war so, als ob Haiku POSIX-Kompatibilität anstrebt.

      Da stellt sich die Frage: Sind Benutzer- und Rechtetrennung nicht grundlegende Bestandteile von POSIX? Immerhin hatten Multics und Unix aus den Bell Labs als time-sharing-Systeme, großen Einfluss auf POSIX, und sie waren bereits von Beginn an multiuser-fähig, konnten also Nutzer und deren Rechte sauber trennen.

      Daher scheint mir Ihre Aussage, Haiku hätte keine Benutzer- und Rechtetrennung, kompletter Kokolores zu sein.

      Übrigens schließen sich Einzelplatzsystem (kein multiseat) und multiuser-Fähigkeiten nicht direkt aus.

      2. Ja, die Kompatibilität von Haiku zu BeOS ist unvollständig, schon seit Jahren nur eine technisch dürftige Krücke mit großen Einschränkungen, und hat langfristig keine Zukunft. Man ist allerdings in einer Situation, wo man trotzdem vieles weiterentwickeln kann.

      [...], dass man sich die Kompatibilität problemlos sparen könnte.
      Ja, kann man machen. Und ich würde denken, dass diese Ansicht global mehrheitsfähig wäre, aber eben nicht innerhalb des Haiku-Projekts. Lassen Sie den Beteiligten doch bitte die Ausübung ihrer Freiheiten, z.B. um alten Kram zu unterstützen, ohne Rechtfertigungsansprüche zu stellen, die ohnehin nicht bestehen!

      Sie haben im Gegenzug die Freiheit dem Projekt etwas beizusteuern, es zu forken oder einfach nur darüber zu lamentieren. Das ist Ihre Entscheidung. Egal wie Sie sich entscheiden: Bitte berücksichtigen Sie zuvor die abschätzbaren Konsequenzen, ohne im sich Nachhinein darüber zu beschweren!

      Denn alte Zöpfe verhindern auch neue Konzepte.
      Jein, nicht in jedem Fall. Wie sieht es hier aus?

      3.

      Was Haiku am Anfang vielleicht einen Schwung an Entwicklern gebracht hat, schadet Haiku am Ende, weil die das gesamte Projekt an das Konzept eines alten Eisen orientieren müssen.
      Was qualifiziert Sie dazu, das ernsthaft und glaubhaft zu behaupten? Falls Sie sich dennoch so sicher sind, rate ich Ihnen, Ihre Sorgen und Weisheiten mit dem Haiku-Projekt zu teilen, wenn Sie es nicht schon getan haben, um das Projekt in Ihrem Sinne "auf den richtigen Weg" zu bringen, denn scheinbar liegt es auch in Ihrem Interesse.
      Ich denke, dass Haiku Inc. am besten weiß, was gut für das Projekt ist.

      • 0
        Von Ghul am Mi, 10. Juli 2019 um 19:09 #

        1. POSIX Kompatibilität kannst du mit API Kompatibilität gleichsetzen.
        Das bedeutet nicht, dass das OS getrennte Nutzer haben muss, es muss nur mit Multiuser Datensätzen entsprechend umgehen können. Das kann aber jeder Adminzugang.

        Ja, Multics und Unicy konnten das, aber BeOS konnte das nicht, es war als Win9x Ersatz mit Schwerpunkt im möglichst latenzfreien Multimediabereich entwickelt worden und Win9x war eigentlich nur ein Singleuserbetriebssystem, das lediglich mehrere Benutzerprofile erlaubte.
        Eine Nutzer- und Rechtetrennung wurde aber weder bei Win9x noch bei BeOS durchgesetzt.

        Insofern ja, als BeOS dann mit der Version 3.5 ungefähr 1997s der breiten Öffentlichkeit bekannt wurde, war es in diesem Gebiet bereits veraltet, denn sowohl WinNT, OS/2 als auch Linux boten eine Nutzer- und Rechtetrennung.
        Als BeOS 4.0 dann erschien, stürzte sich schon eine große Anzahl an Nutzer, die von Windows weg wollten, auf Linux.
        Der Rest ist Geschichte.

        BeOS kam zu spät und hatte keine Nutzer- und Rechtetrennung.
        Und Haiku orientiert sich daran und hat bzw. hatte diese auch nicht.

        2. unnötig

        3. Weil es stimmt.
        Guck dir einfach mal die Geschichte an wie Haiku entstand.

        • 0
          Von klopskind am Do, 11. Juli 2019 um 14:30 #

          1.

          Das bedeutet nicht, dass das OS getrennte Nutzer haben muss, es muss nur mit Multiuser Datensätzen entsprechend umgehen können. Das kann aber jeder Adminzugang.
          Was genau soll das bedeuten und wo liegt der Unterschied?

          Ja, Multics und Unicy konnten das, aber BeOS konnte das nicht, [...]
          Im Punkt 1 ging es allein um Haiku bzw. um die Aussage, Haiku hätte keine Benutzer- und Rechtetrennung (Zitat: "Haiku hat keine Benutzer- und Rechtetrennung.").

          Und Haiku [...] hat bzw. hatte diese [Nutzer- und Rechtetrennung] auch nicht.
          Genau das habe ich bezweifelt. Wie sonst sollten die Haiku-Ports gängiger Unix-Programme, die wie bspw. Shells auch multiuser-Konzepte aus POSIX verwenden, laufen?

          Um das abzukürzen habe ich ein wenig recherchiert, wie das technisch umgesetzt wird. In Beispielen: 1, 2, 3, 4, 5, 6, 7, 8 usw.
          Ich muss zugegeben, dass es mehr wie eine Emulation der POSIX-Kompatibilität wirkt. Und trotzdem unterstützt es genug, um diverse Unix-Programme auszuführen und auf Wikipedia als "mostly POSIX-compliant" geführt zu werden. (Im Übrigen wird dort auch BeOS aufgeführt, aber das nur am Rande.)

          2. geschenkt

          3. Sie verwerfen meine Zweifel ("Was qualifiziert Sie dazu, das ernsthaft und glaubhaft zu behaupten?") an Ihrer Aussage (s.o.) damit, dass Ihre Aussage stimmt ("Weil es stimmt.") und Sie mir weiterhin Unwissenheit ("Guck dir einfach mal die Geschichte an wie Haiku entstand.") unterstellen.
          Sie haben eine äußerst bestechende Logik!

          Zur Geschichte Haikus können Sie mir sicherlich einige Weisheiten aus Ihrem reichhaltigen Wissensfundus darlegen, die Ihre Thesen auf eine solide Grundlage stellen, oder? Ich habe das gelesen. Welcher Teil dieses Artikels stützt Ihre These?

    0
    Von asdfghjkl am Do, 18. Juli 2019 um 14:06 #

    Oh, so viele "sollte" in einem Post...

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung