Linux-Distribution - Versionsgeschichte

Y2kbug: /* Kompatibilität zwischen den Distributionen */ tf. Genetiv

2024-08-28T09:21:13Z

Kompatibilität zwischen den Distributionen: tf. Genetiv

← Nächstältere Version		Version vom 28. August 2024, 11:21 Uhr
Zeile 88:		Zeile 88:
	Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.<ref name="stillbrokeninstallation" /><ref name="troy">{{cite web\|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp\|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp \|title=Linux Game Development Part 2 – Distributable Binaries\|first=Troy \|last=Hepfner \|date=2007-10-01\|accessdate=2011-12-19 \|archivedate=2007-10-13\|language=englisch\|quote=Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]}}</ref> Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der [[Quelltext]] veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.<ref name="launchpad2010">{{cite web\|url=https://bugs.launchpad.net/bugs/578045 \|title=Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS – Bug #578045 \|first=John \|last=King \|date=2010-05-10 \|accessdate=2012-05-27 \|language=englisch \|work=Launchpad \|publisher=Ubuntu \|quote=It is easier to upgrade to the newest stable versions of most applications – even open source applications – on a proprietary operating system than it is on Ubuntu.}}</ref> Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.<ref name="lgp">{{cite web\|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|title=Playing well with distros \|date=2009-11-24 \|accessdate=2012-01-15\|first=Eskild\|last=Hustvedt\|publisher=[[Linux Game Publishing]]\|language=englisch\|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|archivedate=2011-09-21}}</ref><ref name="icaza2003">{{cite web \|url=http://primates.ximian.com/~miguel/texts/linux-developers.html \|date=2003-11-04 \|author=[[Miguel de Icaza]] \|title=Linux and Independent Software Vendors \|publisher=primates.ximian.com \|accessdate=2012-04-07 \|language=englisch \|quote=[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […] \|archiveurl=https://web.archive.org/web/20120715205643/http://primates.ximian.com/~miguel/texts/linux-developers.html \|archivedate=2012-07-15 \|offline=yes }}</ref><ref>{{cite web\|url=http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/\|first=Dave\|last=Burke\|title=Porting Osmos to Linux: A Post-Mortem (part 2/3)\|date=2010-05-18\|accessdate=2012-06-16\|language=englisch\|quote=Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32 bit and 64 bit executables […]\|publisher=hemispheregames.com}}</ref> Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.		Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.<ref name="stillbrokeninstallation" /><ref name="troy">{{cite web\|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp\|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp \|title=Linux Game Development Part 2 – Distributable Binaries\|first=Troy \|last=Hepfner \|date=2007-10-01\|accessdate=2011-12-19 \|archivedate=2007-10-13\|language=englisch\|quote=Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]}}</ref> Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der [[Quelltext]] veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.<ref name="launchpad2010">{{cite web\|url=https://bugs.launchpad.net/bugs/578045 \|title=Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS – Bug #578045 \|first=John \|last=King \|date=2010-05-10 \|accessdate=2012-05-27 \|language=englisch \|work=Launchpad \|publisher=Ubuntu \|quote=It is easier to upgrade to the newest stable versions of most applications – even open source applications – on a proprietary operating system than it is on Ubuntu.}}</ref> Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.<ref name="lgp">{{cite web\|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|title=Playing well with distros \|date=2009-11-24 \|accessdate=2012-01-15\|first=Eskild\|last=Hustvedt\|publisher=[[Linux Game Publishing]]\|language=englisch\|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|archivedate=2011-09-21}}</ref><ref name="icaza2003">{{cite web \|url=http://primates.ximian.com/~miguel/texts/linux-developers.html \|date=2003-11-04 \|author=[[Miguel de Icaza]] \|title=Linux and Independent Software Vendors \|publisher=primates.ximian.com \|accessdate=2012-04-07 \|language=englisch \|quote=[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […] \|archiveurl=https://web.archive.org/web/20120715205643/http://primates.ximian.com/~miguel/texts/linux-developers.html \|archivedate=2012-07-15 \|offline=yes }}</ref><ref>{{cite web\|url=http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/\|first=Dave\|last=Burke\|title=Porting Osmos to Linux: A Post-Mortem (part 2/3)\|date=2010-05-18\|accessdate=2012-06-16\|language=englisch\|quote=Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32 bit and 64 bit executables […]\|publisher=hemispheregames.com}}</ref> Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.

	Eine weitere wichtige Norm ist [[Portable Operating System Interface\|POSIX]]. Sie geht im Gegensatz zur [[Linux Standard Base\|LSB]] über Linux hinaus und soll einen Standard für alle unixoiden Betriebssysteme bilden. Obwohl die LSB nicht mit POSIX kompatibel ist, halten sich Linux-Distributionen für gewöhnlich an einen Großteil der Norm. Daher gab es lange Zeit keine einzige Distribution, die offiziell als POSIX-konform zertifiziert war,<ref>{{Internetquelle \|url=https://www.opengroup.org/openbrand/register/ \|titel=The Register of UNIX Certified Products \|zugriff=2017-07-18}}</ref> bis 2016 u. a. Huawei mit [[EulerOS]] den Zertifizierungsprozess [[Single UNIX Specification#UNIX 03\|UNIX 03]] durchlaufen hat. Die Bedeutung dieser Zertifizierung, und damit die vollständige Einhaltung des POSIX-~~Standard~~, ist für das Linux- und [[Berkeley Software Distribution\|BSD]]-Ökosystem jedoch nicht wirklich wichtig.<ref>{{Literatur \|Autor=Scott Alan Miller \|Titel=Linux Administration Best Practices; Practical solutions to approaching the design and management of Linux systems \|Verlag=Packt Publishing \|Datum=2022-02 \|Sprache=en \|Kapitel=Is Linux UNIX? \|Seiten=29 ff. \|ISBN=978-1-80056-879-2 \|Online={{Google Buch \|BuchID=VAZZEAAAQBAJ \|Seite=29}} \|Zitat=While most operating systems built from Linux have never bothered to pay for any kind of UNIX certification, one of them recently did: EulerOS by Huawei which is built from CentOS, which in turn, is built from Fedora. Only EulerOS as a product officially carries the UNIX trademark designation, but it shows that the broader ecosystem is meeting the specifications. … In reality, the Linux and BSD ecosystems have demonstrated that the utility of the UNIX certification process has run its course and the process is now detrimental to the industry and serves no purpose. At the end of the day, being compatible with UNIX is worthless, it is Linux and BSD that other systems want to maintain compatibility with.}}</ref>		Eine weitere wichtige Norm ist [[Portable Operating System Interface\|POSIX]]. Sie geht im Gegensatz zur [[Linux Standard Base\|LSB]] über Linux hinaus und soll einen Standard für alle unixoiden Betriebssysteme bilden. Obwohl die LSB nicht mit POSIX kompatibel ist, halten sich Linux-Distributionen für gewöhnlich an einen Großteil der Norm. Daher gab es lange Zeit keine einzige Distribution, die offiziell als POSIX-konform zertifiziert war,<ref>{{Internetquelle \|url=https://www.opengroup.org/openbrand/register/ \|titel=The Register of UNIX Certified Products \|zugriff=2017-07-18}}</ref> bis 2016 u. a. Huawei mit [[EulerOS]] den Zertifizierungsprozess [[Single UNIX Specification#UNIX 03\|UNIX 03]] durchlaufen hat. Die Bedeutung dieser Zertifizierung, und damit die vollständige Einhaltung des POSIX-Standards, ist für das Linux- und [[Berkeley Software Distribution\|BSD]]-Ökosystem jedoch nicht wirklich wichtig.<ref>{{Literatur \|Autor=Scott Alan Miller \|Titel=Linux Administration Best Practices; Practical solutions to approaching the design and management of Linux systems \|Verlag=Packt Publishing \|Datum=2022-02 \|Sprache=en \|Kapitel=Is Linux UNIX? \|Seiten=29 ff. \|ISBN=978-1-80056-879-2 \|Online={{Google Buch \|BuchID=VAZZEAAAQBAJ \|Seite=29}} \|Zitat=While most operating systems built from Linux have never bothered to pay for any kind of UNIX certification, one of them recently did: EulerOS by Huawei which is built from CentOS, which in turn, is built from Fedora. Only EulerOS as a product officially carries the UNIX trademark designation, but it shows that the broader ecosystem is meeting the specifications. … In reality, the Linux and BSD ecosystems have demonstrated that the utility of the UNIX certification process has run its course and the process is now detrimental to the industry and serves no purpose. At the end of the day, being compatible with UNIX is worthless, it is Linux and BSD that other systems want to maintain compatibility with.}}</ref>

	=== Standardisierungsansätze ===		=== Standardisierungsansätze ===

Y2kbug: /* Kompatibilität zwischen den Distributionen */ Zwischensatz eingefügt: großteils POSIX (was Linux (und BSD) ist) und vollständig POSIX-konform sind zwei verschiedene Dinge...

2024-08-28T09:20:03Z

Kompatibilität zwischen den Distributionen: Zwischensatz eingefügt: großteils POSIX (was Linux (und BSD) ist) und vollständig POSIX-konform sind zwei verschiedene Dinge...

← Nächstältere Version		Version vom 28. August 2024, 11:20 Uhr
Zeile 88:		Zeile 88:
	Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.<ref name="stillbrokeninstallation" /><ref name="troy">{{cite web\|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp\|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp \|title=Linux Game Development Part 2 – Distributable Binaries\|first=Troy \|last=Hepfner \|date=2007-10-01\|accessdate=2011-12-19 \|archivedate=2007-10-13\|language=englisch\|quote=Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]}}</ref> Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der [[Quelltext]] veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.<ref name="launchpad2010">{{cite web\|url=https://bugs.launchpad.net/bugs/578045 \|title=Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS – Bug #578045 \|first=John \|last=King \|date=2010-05-10 \|accessdate=2012-05-27 \|language=englisch \|work=Launchpad \|publisher=Ubuntu \|quote=It is easier to upgrade to the newest stable versions of most applications – even open source applications – on a proprietary operating system than it is on Ubuntu.}}</ref> Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.<ref name="lgp">{{cite web\|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|title=Playing well with distros \|date=2009-11-24 \|accessdate=2012-01-15\|first=Eskild\|last=Hustvedt\|publisher=[[Linux Game Publishing]]\|language=englisch\|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|archivedate=2011-09-21}}</ref><ref name="icaza2003">{{cite web \|url=http://primates.ximian.com/~miguel/texts/linux-developers.html \|date=2003-11-04 \|author=[[Miguel de Icaza]] \|title=Linux and Independent Software Vendors \|publisher=primates.ximian.com \|accessdate=2012-04-07 \|language=englisch \|quote=[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […] \|archiveurl=https://web.archive.org/web/20120715205643/http://primates.ximian.com/~miguel/texts/linux-developers.html \|archivedate=2012-07-15 \|offline=yes }}</ref><ref>{{cite web\|url=http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/\|first=Dave\|last=Burke\|title=Porting Osmos to Linux: A Post-Mortem (part 2/3)\|date=2010-05-18\|accessdate=2012-06-16\|language=englisch\|quote=Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32 bit and 64 bit executables […]\|publisher=hemispheregames.com}}</ref> Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.		Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.<ref name="stillbrokeninstallation" /><ref name="troy">{{cite web\|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp\|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp \|title=Linux Game Development Part 2 – Distributable Binaries\|first=Troy \|last=Hepfner \|date=2007-10-01\|accessdate=2011-12-19 \|archivedate=2007-10-13\|language=englisch\|quote=Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]}}</ref> Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der [[Quelltext]] veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.<ref name="launchpad2010">{{cite web\|url=https://bugs.launchpad.net/bugs/578045 \|title=Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS – Bug #578045 \|first=John \|last=King \|date=2010-05-10 \|accessdate=2012-05-27 \|language=englisch \|work=Launchpad \|publisher=Ubuntu \|quote=It is easier to upgrade to the newest stable versions of most applications – even open source applications – on a proprietary operating system than it is on Ubuntu.}}</ref> Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.<ref name="lgp">{{cite web\|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|title=Playing well with distros \|date=2009-11-24 \|accessdate=2012-01-15\|first=Eskild\|last=Hustvedt\|publisher=[[Linux Game Publishing]]\|language=englisch\|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|archivedate=2011-09-21}}</ref><ref name="icaza2003">{{cite web \|url=http://primates.ximian.com/~miguel/texts/linux-developers.html \|date=2003-11-04 \|author=[[Miguel de Icaza]] \|title=Linux and Independent Software Vendors \|publisher=primates.ximian.com \|accessdate=2012-04-07 \|language=englisch \|quote=[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […] \|archiveurl=https://web.archive.org/web/20120715205643/http://primates.ximian.com/~miguel/texts/linux-developers.html \|archivedate=2012-07-15 \|offline=yes }}</ref><ref>{{cite web\|url=http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/\|first=Dave\|last=Burke\|title=Porting Osmos to Linux: A Post-Mortem (part 2/3)\|date=2010-05-18\|accessdate=2012-06-16\|language=englisch\|quote=Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32 bit and 64 bit executables […]\|publisher=hemispheregames.com}}</ref> Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.

	Eine weitere wichtige Norm ist [[Portable Operating System Interface\|POSIX]]. Sie geht im Gegensatz zur [[Linux Standard Base\|LSB]] über Linux hinaus und soll einen Standard für alle unixoiden Betriebssysteme bilden. Obwohl die LSB nicht mit POSIX kompatibel ist, halten sich Linux-Distributionen für gewöhnlich an einen Großteil der Norm. Daher gab es lange Zeit keine einzige Distribution, die offiziell als POSIX-konform zertifiziert war,<ref>{{Internetquelle \|url=https://www.opengroup.org/openbrand/register/ \|titel=The Register of UNIX Certified Products \|zugriff=2017-07-18}}</ref> bis 2016 u. a. Huawei mit [[EulerOS]] den Zertifizierungsprozess [[Single UNIX Specification#UNIX 03\|UNIX 03]] durchlaufen hat. Die Bedeutung dieser Zertifizierung ist für das Linux- und [[Berkeley Software Distribution\|BSD]]-Ökosystem jedoch nicht wirklich wichtig.<ref>{{Literatur \|Autor=Scott Alan Miller \|Titel=Linux Administration Best Practices; Practical solutions to approaching the design and management of Linux systems \|Verlag=Packt Publishing \|Datum=2022-02 \|Sprache=en \|Kapitel=Is Linux UNIX? \|Seiten=29 ff. \|ISBN=978-1-80056-879-2 \|Online={{Google Buch \|BuchID=VAZZEAAAQBAJ \|Seite=29}} \|Zitat=While most operating systems built from Linux have never bothered to pay for any kind of UNIX certification, one of them recently did: EulerOS by Huawei which is built from CentOS, which in turn, is built from Fedora. Only EulerOS as a product officially carries the UNIX trademark designation, but it shows that the broader ecosystem is meeting the specifications. … In reality, the Linux and BSD ecosystems have demonstrated that the utility of the UNIX certification process has run its course and the process is now detrimental to the industry and serves no purpose. At the end of the day, being compatible with UNIX is worthless, it is Linux and BSD that other systems want to maintain compatibility with.}}</ref>		Eine weitere wichtige Norm ist [[Portable Operating System Interface\|POSIX]]. Sie geht im Gegensatz zur [[Linux Standard Base\|LSB]] über Linux hinaus und soll einen Standard für alle unixoiden Betriebssysteme bilden. Obwohl die LSB nicht mit POSIX kompatibel ist, halten sich Linux-Distributionen für gewöhnlich an einen Großteil der Norm. Daher gab es lange Zeit keine einzige Distribution, die offiziell als POSIX-konform zertifiziert war,<ref>{{Internetquelle \|url=https://www.opengroup.org/openbrand/register/ \|titel=The Register of UNIX Certified Products \|zugriff=2017-07-18}}</ref> bis 2016 u. a. Huawei mit [[EulerOS]] den Zertifizierungsprozess [[Single UNIX Specification#UNIX 03\|UNIX 03]] durchlaufen hat. Die Bedeutung dieser Zertifizierung, und damit die vollständige Einhaltung des POSIX-Standard, ist für das Linux- und [[Berkeley Software Distribution\|BSD]]-Ökosystem jedoch nicht wirklich wichtig.<ref>{{Literatur \|Autor=Scott Alan Miller \|Titel=Linux Administration Best Practices; Practical solutions to approaching the design and management of Linux systems \|Verlag=Packt Publishing \|Datum=2022-02 \|Sprache=en \|Kapitel=Is Linux UNIX? \|Seiten=29 ff. \|ISBN=978-1-80056-879-2 \|Online={{Google Buch \|BuchID=VAZZEAAAQBAJ \|Seite=29}} \|Zitat=While most operating systems built from Linux have never bothered to pay for any kind of UNIX certification, one of them recently did: EulerOS by Huawei which is built from CentOS, which in turn, is built from Fedora. Only EulerOS as a product officially carries the UNIX trademark designation, but it shows that the broader ecosystem is meeting the specifications. … In reality, the Linux and BSD ecosystems have demonstrated that the utility of the UNIX certification process has run its course and the process is now detrimental to the industry and serves no purpose. At the end of the day, being compatible with UNIX is worthless, it is Linux and BSD that other systems want to maintain compatibility with.}}</ref>

	=== Standardisierungsansätze ===		=== Standardisierungsansätze ===

Y2kbug: /* Kompatibilität zwischen den Distributionen */ Korr.: wie im Originalzitat nicht Unix, sondern BSD...

2024-08-28T09:17:59Z

Kompatibilität zwischen den Distributionen: Korr.: wie im Originalzitat nicht Unix, sondern BSD...

← Nächstältere Version		Version vom 28. August 2024, 11:17 Uhr
Zeile 88:		Zeile 88:
	Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.<ref name="stillbrokeninstallation" /><ref name="troy">{{cite web\|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp\|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp \|title=Linux Game Development Part 2 – Distributable Binaries\|first=Troy \|last=Hepfner \|date=2007-10-01\|accessdate=2011-12-19 \|archivedate=2007-10-13\|language=englisch\|quote=Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]}}</ref> Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der [[Quelltext]] veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.<ref name="launchpad2010">{{cite web\|url=https://bugs.launchpad.net/bugs/578045 \|title=Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS – Bug #578045 \|first=John \|last=King \|date=2010-05-10 \|accessdate=2012-05-27 \|language=englisch \|work=Launchpad \|publisher=Ubuntu \|quote=It is easier to upgrade to the newest stable versions of most applications – even open source applications – on a proprietary operating system than it is on Ubuntu.}}</ref> Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.<ref name="lgp">{{cite web\|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|title=Playing well with distros \|date=2009-11-24 \|accessdate=2012-01-15\|first=Eskild\|last=Hustvedt\|publisher=[[Linux Game Publishing]]\|language=englisch\|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|archivedate=2011-09-21}}</ref><ref name="icaza2003">{{cite web \|url=http://primates.ximian.com/~miguel/texts/linux-developers.html \|date=2003-11-04 \|author=[[Miguel de Icaza]] \|title=Linux and Independent Software Vendors \|publisher=primates.ximian.com \|accessdate=2012-04-07 \|language=englisch \|quote=[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […] \|archiveurl=https://web.archive.org/web/20120715205643/http://primates.ximian.com/~miguel/texts/linux-developers.html \|archivedate=2012-07-15 \|offline=yes }}</ref><ref>{{cite web\|url=http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/\|first=Dave\|last=Burke\|title=Porting Osmos to Linux: A Post-Mortem (part 2/3)\|date=2010-05-18\|accessdate=2012-06-16\|language=englisch\|quote=Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32 bit and 64 bit executables […]\|publisher=hemispheregames.com}}</ref> Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.		Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.<ref name="stillbrokeninstallation" /><ref name="troy">{{cite web\|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp\|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp \|title=Linux Game Development Part 2 – Distributable Binaries\|first=Troy \|last=Hepfner \|date=2007-10-01\|accessdate=2011-12-19 \|archivedate=2007-10-13\|language=englisch\|quote=Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]}}</ref> Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der [[Quelltext]] veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.<ref name="launchpad2010">{{cite web\|url=https://bugs.launchpad.net/bugs/578045 \|title=Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS – Bug #578045 \|first=John \|last=King \|date=2010-05-10 \|accessdate=2012-05-27 \|language=englisch \|work=Launchpad \|publisher=Ubuntu \|quote=It is easier to upgrade to the newest stable versions of most applications – even open source applications – on a proprietary operating system than it is on Ubuntu.}}</ref> Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.<ref name="lgp">{{cite web\|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|title=Playing well with distros \|date=2009-11-24 \|accessdate=2012-01-15\|first=Eskild\|last=Hustvedt\|publisher=[[Linux Game Publishing]]\|language=englisch\|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|archivedate=2011-09-21}}</ref><ref name="icaza2003">{{cite web \|url=http://primates.ximian.com/~miguel/texts/linux-developers.html \|date=2003-11-04 \|author=[[Miguel de Icaza]] \|title=Linux and Independent Software Vendors \|publisher=primates.ximian.com \|accessdate=2012-04-07 \|language=englisch \|quote=[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […] \|archiveurl=https://web.archive.org/web/20120715205643/http://primates.ximian.com/~miguel/texts/linux-developers.html \|archivedate=2012-07-15 \|offline=yes }}</ref><ref>{{cite web\|url=http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/\|first=Dave\|last=Burke\|title=Porting Osmos to Linux: A Post-Mortem (part 2/3)\|date=2010-05-18\|accessdate=2012-06-16\|language=englisch\|quote=Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32 bit and 64 bit executables […]\|publisher=hemispheregames.com}}</ref> Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.

	Eine weitere wichtige Norm ist [[Portable Operating System Interface\|POSIX]]. Sie geht im Gegensatz zur [[Linux Standard Base\|LSB]] über Linux hinaus und soll einen Standard für alle unixoiden Betriebssysteme bilden. Obwohl die LSB nicht mit POSIX kompatibel ist, halten sich Linux-Distributionen für gewöhnlich an einen Großteil der Norm. Daher gab es lange Zeit keine einzige Distribution, die offiziell als POSIX-konform zertifiziert war,<ref>{{Internetquelle \|url=https://www.opengroup.org/openbrand/register/ \|titel=The Register of UNIX Certified Products \|zugriff=2017-07-18}}</ref> bis 2016 u. a. Huawei mit [[EulerOS]] den Zertifizierungsprozess [[Single UNIX Specification#UNIX 03\|UNIX 03]] durchlaufen hat. Die Bedeutung dieser Zertifizierung ist für das Linux- und ~~Unix~~-Ökosystem jedoch nicht wirklich wichtig.<ref>{{Literatur \|Autor=Scott Alan Miller \|Titel=Linux Administration Best Practices; Practical solutions to approaching the design and management of Linux systems \|Verlag=Packt Publishing \|Datum=2022-02 \|Sprache=en \|Kapitel=Is Linux UNIX? \|Seiten=29 ff. \|ISBN=978-1-80056-879-2 \|Online={{Google Buch \|BuchID=VAZZEAAAQBAJ \|Seite=29}} \|Zitat=While most operating systems built from Linux have never bothered to pay for any kind of UNIX certification, one of them recently did: EulerOS by Huawei which is built from CentOS, which in turn, is built from Fedora. Only EulerOS as a product officially carries the UNIX trademark designation, but it shows that the broader ecosystem is meeting the specifications. … In reality, the Linux and BSD ecosystems have demonstrated that the utility of the UNIX certification process has run its course and the process is now detrimental to the industry and serves no purpose. At the end of the day, being compatible with UNIX is worthless, it is Linux and BSD that other systems want to maintain compatibility with.}}</ref>		Eine weitere wichtige Norm ist [[Portable Operating System Interface\|POSIX]]. Sie geht im Gegensatz zur [[Linux Standard Base\|LSB]] über Linux hinaus und soll einen Standard für alle unixoiden Betriebssysteme bilden. Obwohl die LSB nicht mit POSIX kompatibel ist, halten sich Linux-Distributionen für gewöhnlich an einen Großteil der Norm. Daher gab es lange Zeit keine einzige Distribution, die offiziell als POSIX-konform zertifiziert war,<ref>{{Internetquelle \|url=https://www.opengroup.org/openbrand/register/ \|titel=The Register of UNIX Certified Products \|zugriff=2017-07-18}}</ref> bis 2016 u. a. Huawei mit [[EulerOS]] den Zertifizierungsprozess [[Single UNIX Specification#UNIX 03\|UNIX 03]] durchlaufen hat. Die Bedeutung dieser Zertifizierung ist für das Linux- und [[Berkeley Software Distribution\|BSD]]-Ökosystem jedoch nicht wirklich wichtig.<ref>{{Literatur \|Autor=Scott Alan Miller \|Titel=Linux Administration Best Practices; Practical solutions to approaching the design and management of Linux systems \|Verlag=Packt Publishing \|Datum=2022-02 \|Sprache=en \|Kapitel=Is Linux UNIX? \|Seiten=29 ff. \|ISBN=978-1-80056-879-2 \|Online={{Google Buch \|BuchID=VAZZEAAAQBAJ \|Seite=29}} \|Zitat=While most operating systems built from Linux have never bothered to pay for any kind of UNIX certification, one of them recently did: EulerOS by Huawei which is built from CentOS, which in turn, is built from Fedora. Only EulerOS as a product officially carries the UNIX trademark designation, but it shows that the broader ecosystem is meeting the specifications. … In reality, the Linux and BSD ecosystems have demonstrated that the utility of the UNIX certification process has run its course and the process is now detrimental to the industry and serves no purpose. At the end of the day, being compatible with UNIX is worthless, it is Linux and BSD that other systems want to maintain compatibility with.}}</ref>

	=== Standardisierungsansätze ===		=== Standardisierungsansätze ===

Y2kbug: /* Kompatibilität zwischen den Distributionen */ EulerOS verlinkt

2024-08-28T09:14:14Z

Kompatibilität zwischen den Distributionen: EulerOS verlinkt

← Nächstältere Version		Version vom 28. August 2024, 11:14 Uhr
Zeile 88:		Zeile 88:
	Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.<ref name="stillbrokeninstallation" /><ref name="troy">{{cite web\|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp\|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp \|title=Linux Game Development Part 2 – Distributable Binaries\|first=Troy \|last=Hepfner \|date=2007-10-01\|accessdate=2011-12-19 \|archivedate=2007-10-13\|language=englisch\|quote=Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]}}</ref> Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der [[Quelltext]] veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.<ref name="launchpad2010">{{cite web\|url=https://bugs.launchpad.net/bugs/578045 \|title=Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS – Bug #578045 \|first=John \|last=King \|date=2010-05-10 \|accessdate=2012-05-27 \|language=englisch \|work=Launchpad \|publisher=Ubuntu \|quote=It is easier to upgrade to the newest stable versions of most applications – even open source applications – on a proprietary operating system than it is on Ubuntu.}}</ref> Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.<ref name="lgp">{{cite web\|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|title=Playing well with distros \|date=2009-11-24 \|accessdate=2012-01-15\|first=Eskild\|last=Hustvedt\|publisher=[[Linux Game Publishing]]\|language=englisch\|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|archivedate=2011-09-21}}</ref><ref name="icaza2003">{{cite web \|url=http://primates.ximian.com/~miguel/texts/linux-developers.html \|date=2003-11-04 \|author=[[Miguel de Icaza]] \|title=Linux and Independent Software Vendors \|publisher=primates.ximian.com \|accessdate=2012-04-07 \|language=englisch \|quote=[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […] \|archiveurl=https://web.archive.org/web/20120715205643/http://primates.ximian.com/~miguel/texts/linux-developers.html \|archivedate=2012-07-15 \|offline=yes }}</ref><ref>{{cite web\|url=http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/\|first=Dave\|last=Burke\|title=Porting Osmos to Linux: A Post-Mortem (part 2/3)\|date=2010-05-18\|accessdate=2012-06-16\|language=englisch\|quote=Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32 bit and 64 bit executables […]\|publisher=hemispheregames.com}}</ref> Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.		Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.<ref name="stillbrokeninstallation" /><ref name="troy">{{cite web\|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp\|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp \|title=Linux Game Development Part 2 – Distributable Binaries\|first=Troy \|last=Hepfner \|date=2007-10-01\|accessdate=2011-12-19 \|archivedate=2007-10-13\|language=englisch\|quote=Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]}}</ref> Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der [[Quelltext]] veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.<ref name="launchpad2010">{{cite web\|url=https://bugs.launchpad.net/bugs/578045 \|title=Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS – Bug #578045 \|first=John \|last=King \|date=2010-05-10 \|accessdate=2012-05-27 \|language=englisch \|work=Launchpad \|publisher=Ubuntu \|quote=It is easier to upgrade to the newest stable versions of most applications – even open source applications – on a proprietary operating system than it is on Ubuntu.}}</ref> Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.<ref name="lgp">{{cite web\|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|title=Playing well with distros \|date=2009-11-24 \|accessdate=2012-01-15\|first=Eskild\|last=Hustvedt\|publisher=[[Linux Game Publishing]]\|language=englisch\|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|archivedate=2011-09-21}}</ref><ref name="icaza2003">{{cite web \|url=http://primates.ximian.com/~miguel/texts/linux-developers.html \|date=2003-11-04 \|author=[[Miguel de Icaza]] \|title=Linux and Independent Software Vendors \|publisher=primates.ximian.com \|accessdate=2012-04-07 \|language=englisch \|quote=[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […] \|archiveurl=https://web.archive.org/web/20120715205643/http://primates.ximian.com/~miguel/texts/linux-developers.html \|archivedate=2012-07-15 \|offline=yes }}</ref><ref>{{cite web\|url=http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/\|first=Dave\|last=Burke\|title=Porting Osmos to Linux: A Post-Mortem (part 2/3)\|date=2010-05-18\|accessdate=2012-06-16\|language=englisch\|quote=Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32 bit and 64 bit executables […]\|publisher=hemispheregames.com}}</ref> Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.

	Eine weitere wichtige Norm ist [[Portable Operating System Interface\|POSIX]]. Sie geht im Gegensatz zur [[Linux Standard Base\|LSB]] über Linux hinaus und soll einen Standard für alle unixoiden Betriebssysteme bilden. Obwohl die LSB nicht mit POSIX kompatibel ist, halten sich Linux-Distributionen für gewöhnlich an einen Großteil der Norm. Daher gab es lange Zeit keine einzige Distribution, die offiziell als POSIX-konform zertifiziert war,<ref>{{Internetquelle \|url=https://www.opengroup.org/openbrand/register/ \|titel=The Register of UNIX Certified Products \|zugriff=2017-07-18}}</ref> bis 2016 u. a. Huawei mit EulerOS den Zertifizierungsprozess [[Single UNIX Specification#UNIX 03\|UNIX 03]] durchlaufen hat. Die Bedeutung dieser Zertifizierung ist für das Linux- und Unix-Ökosystem jedoch nicht wirklich wichtig.<ref>{{Literatur \|Autor=Scott Alan Miller \|Titel=Linux Administration Best Practices; Practical solutions to approaching the design and management of Linux systems \|Verlag=Packt Publishing \|Datum=2022-02 \|Sprache=en \|Kapitel=Is Linux UNIX? \|Seiten=29 ff. \|ISBN=978-1-80056-879-2 \|Online={{Google Buch \|BuchID=VAZZEAAAQBAJ \|Seite=29}} \|Zitat=While most operating systems built from Linux have never bothered to pay for any kind of UNIX certification, one of them recently did: EulerOS by Huawei which is built from CentOS, which in turn, is built from Fedora. Only EulerOS as a product officially carries the UNIX trademark designation, but it shows that the broader ecosystem is meeting the specifications. … In reality, the Linux and BSD ecosystems have demonstrated that the utility of the UNIX certification process has run its course and the process is now detrimental to the industry and serves no purpose. At the end of the day, being compatible with UNIX is worthless, it is Linux and BSD that other systems want to maintain compatibility with.}}</ref>		Eine weitere wichtige Norm ist [[Portable Operating System Interface\|POSIX]]. Sie geht im Gegensatz zur [[Linux Standard Base\|LSB]] über Linux hinaus und soll einen Standard für alle unixoiden Betriebssysteme bilden. Obwohl die LSB nicht mit POSIX kompatibel ist, halten sich Linux-Distributionen für gewöhnlich an einen Großteil der Norm. Daher gab es lange Zeit keine einzige Distribution, die offiziell als POSIX-konform zertifiziert war,<ref>{{Internetquelle \|url=https://www.opengroup.org/openbrand/register/ \|titel=The Register of UNIX Certified Products \|zugriff=2017-07-18}}</ref> bis 2016 u. a. Huawei mit [[EulerOS]] den Zertifizierungsprozess [[Single UNIX Specification#UNIX 03\|UNIX 03]] durchlaufen hat. Die Bedeutung dieser Zertifizierung ist für das Linux- und Unix-Ökosystem jedoch nicht wirklich wichtig.<ref>{{Literatur \|Autor=Scott Alan Miller \|Titel=Linux Administration Best Practices; Practical solutions to approaching the design and management of Linux systems \|Verlag=Packt Publishing \|Datum=2022-02 \|Sprache=en \|Kapitel=Is Linux UNIX? \|Seiten=29 ff. \|ISBN=978-1-80056-879-2 \|Online={{Google Buch \|BuchID=VAZZEAAAQBAJ \|Seite=29}} \|Zitat=While most operating systems built from Linux have never bothered to pay for any kind of UNIX certification, one of them recently did: EulerOS by Huawei which is built from CentOS, which in turn, is built from Fedora. Only EulerOS as a product officially carries the UNIX trademark designation, but it shows that the broader ecosystem is meeting the specifications. … In reality, the Linux and BSD ecosystems have demonstrated that the utility of the UNIX certification process has run its course and the process is now detrimental to the industry and serves no purpose. At the end of the day, being compatible with UNIX is worthless, it is Linux and BSD that other systems want to maintain compatibility with.}}</ref>

	=== Standardisierungsansätze ===		=== Standardisierungsansätze ===

Y2kbug: /* Kompatibilität zwischen den Distributionen */ Linux ist UNIX... (wenn es das sein will, und sich jemand den Aufwand antut)

2024-08-28T09:12:15Z

Kompatibilität zwischen den Distributionen: Linux ist UNIX... (wenn es das sein will, und sich jemand den Aufwand antut)

← Nächstältere Version		Version vom 28. August 2024, 11:12 Uhr
Zeile 88:		Zeile 88:
	Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.<ref name="stillbrokeninstallation" /><ref name="troy">{{cite web\|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp\|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp \|title=Linux Game Development Part 2 – Distributable Binaries\|first=Troy \|last=Hepfner \|date=2007-10-01\|accessdate=2011-12-19 \|archivedate=2007-10-13\|language=englisch\|quote=Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]}}</ref> Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der [[Quelltext]] veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.<ref name="launchpad2010">{{cite web\|url=https://bugs.launchpad.net/bugs/578045 \|title=Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS – Bug #578045 \|first=John \|last=King \|date=2010-05-10 \|accessdate=2012-05-27 \|language=englisch \|work=Launchpad \|publisher=Ubuntu \|quote=It is easier to upgrade to the newest stable versions of most applications – even open source applications – on a proprietary operating system than it is on Ubuntu.}}</ref> Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.<ref name="lgp">{{cite web\|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|title=Playing well with distros \|date=2009-11-24 \|accessdate=2012-01-15\|first=Eskild\|last=Hustvedt\|publisher=[[Linux Game Publishing]]\|language=englisch\|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|archivedate=2011-09-21}}</ref><ref name="icaza2003">{{cite web \|url=http://primates.ximian.com/~miguel/texts/linux-developers.html \|date=2003-11-04 \|author=[[Miguel de Icaza]] \|title=Linux and Independent Software Vendors \|publisher=primates.ximian.com \|accessdate=2012-04-07 \|language=englisch \|quote=[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […] \|archiveurl=https://web.archive.org/web/20120715205643/http://primates.ximian.com/~miguel/texts/linux-developers.html \|archivedate=2012-07-15 \|offline=yes }}</ref><ref>{{cite web\|url=http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/\|first=Dave\|last=Burke\|title=Porting Osmos to Linux: A Post-Mortem (part 2/3)\|date=2010-05-18\|accessdate=2012-06-16\|language=englisch\|quote=Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32 bit and 64 bit executables […]\|publisher=hemispheregames.com}}</ref> Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.		Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.<ref name="stillbrokeninstallation" /><ref name="troy">{{cite web\|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp\|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp \|title=Linux Game Development Part 2 – Distributable Binaries\|first=Troy \|last=Hepfner \|date=2007-10-01\|accessdate=2011-12-19 \|archivedate=2007-10-13\|language=englisch\|quote=Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]}}</ref> Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der [[Quelltext]] veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.<ref name="launchpad2010">{{cite web\|url=https://bugs.launchpad.net/bugs/578045 \|title=Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS – Bug #578045 \|first=John \|last=King \|date=2010-05-10 \|accessdate=2012-05-27 \|language=englisch \|work=Launchpad \|publisher=Ubuntu \|quote=It is easier to upgrade to the newest stable versions of most applications – even open source applications – on a proprietary operating system than it is on Ubuntu.}}</ref> Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.<ref name="lgp">{{cite web\|url=http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|title=Playing well with distros \|date=2009-11-24 \|accessdate=2012-01-15\|first=Eskild\|last=Hustvedt\|publisher=[[Linux Game Publishing]]\|language=englisch\|archiveurl=https://web.archive.org/web/20110921031204/http://blog.linuxgamepublishing.com/2009/11/24/playing-well-with-distros/\|archivedate=2011-09-21}}</ref><ref name="icaza2003">{{cite web \|url=http://primates.ximian.com/~miguel/texts/linux-developers.html \|date=2003-11-04 \|author=[[Miguel de Icaza]] \|title=Linux and Independent Software Vendors \|publisher=primates.ximian.com \|accessdate=2012-04-07 \|language=englisch \|quote=[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […] \|archiveurl=https://web.archive.org/web/20120715205643/http://primates.ximian.com/~miguel/texts/linux-developers.html \|archivedate=2012-07-15 \|offline=yes }}</ref><ref>{{cite web\|url=http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/\|first=Dave\|last=Burke\|title=Porting Osmos to Linux: A Post-Mortem (part 2/3)\|date=2010-05-18\|accessdate=2012-06-16\|language=englisch\|quote=Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32 bit and 64 bit executables […]\|publisher=hemispheregames.com}}</ref> Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.

	Eine weitere wichtige Norm ist [[Portable Operating System Interface\|POSIX]]. Sie geht im Gegensatz zur [[Linux Standard Base\|LSB]] über Linux hinaus und soll einen Standard für alle unixoiden Betriebssysteme bilden. ~~POSIX~~ ~~ist~~ nicht ~~kompatibel~~ mit ~~der~~ ~~LSB.~~ ~~Linux-Distributionen~~ halten sich für gewöhnlich an einen Großteil der Norm. ~~Allerdings~~ ~~gibt~~ es ~~derzeit~~ keine Distribution, die offiziell als POSIX-konform zertifiziert ~~ist.~~<ref>{{Internetquelle \|url=https://www.opengroup.org/openbrand/register/ \|titel=The Register of UNIX Certified Products \|zugriff=2017-07-18}}</ref>		Eine weitere wichtige Norm ist [[Portable Operating System Interface\|POSIX]]. Sie geht im Gegensatz zur [[Linux Standard Base\|LSB]] über Linux hinaus und soll einen Standard für alle unixoiden Betriebssysteme bilden. Obwohl die LSB nicht mit POSIX kompatibel ist, halten sich Linux-Distributionen für gewöhnlich an einen Großteil der Norm. Daher gab es lange Zeit keine einzige Distribution, die offiziell als POSIX-konform zertifiziert war,<ref>{{Internetquelle \|url=https://www.opengroup.org/openbrand/register/ \|titel=The Register of UNIX Certified Products \|zugriff=2017-07-18}}</ref> bis 2016 u. a. Huawei mit EulerOS den Zertifizierungsprozess [[Single UNIX Specification#UNIX 03\|UNIX 03]] durchlaufen hat. Die Bedeutung dieser Zertifizierung ist für das Linux- und Unix-Ökosystem jedoch nicht wirklich wichtig.<ref>{{Literatur \|Autor=Scott Alan Miller \|Titel=Linux Administration Best Practices; Practical solutions to approaching the design and management of Linux systems \|Verlag=Packt Publishing \|Datum=2022-02 \|Sprache=en \|Kapitel=Is Linux UNIX? \|Seiten=29 ff. \|ISBN=978-1-80056-879-2 \|Online={{Google Buch \|BuchID=VAZZEAAAQBAJ \|Seite=29}} \|Zitat=While most operating systems built from Linux have never bothered to pay for any kind of UNIX certification, one of them recently did: EulerOS by Huawei which is built from CentOS, which in turn, is built from Fedora. Only EulerOS as a product officially carries the UNIX trademark designation, but it shows that the broader ecosystem is meeting the specifications. … In reality, the Linux and BSD ecosystems have demonstrated that the utility of the UNIX certification process has run its course and the process is now detrimental to the industry and serves no purpose. At the end of the day, being compatible with UNIX is worthless, it is Linux and BSD that other systems want to maintain compatibility with.}}</ref>

	=== Standardisierungsansätze ===		=== Standardisierungsansätze ===

WinfriedSchneider: t

2024-02-12T12:12:06Z

← Nächstältere Version		Version vom 12. Februar 2024, 14:12 Uhr
Zeile 32:		Zeile 32:
	== Geschichte ==		== Geschichte ==
	{{Hauptartikel\|Geschichte von Linux}}		{{Hauptartikel\|Geschichte von Linux}}
	Da [[Linux]] nur ein Betriebssystem-[[Kernel (Betriebssystem)\|Kernel]] ist, wird weitere Software benötigt, um ein benutzbares Betriebssystem zu erhalten. Aus diesem Grund kamen die ersten Linux-[[Distribution (Software)\|Distributionen]] schon kurz nach der [[GNU General Public License\|GPL-Lizenzierung]] von Linux auf, als Anwender, die nicht zum direkten Entwicklerkreis gehörten, Linux zu nutzen begannen. Die ersten Distributionen hatten dabei das Ziel, das System beispielsweise mit der Software des [[GNU-Projekt]]s zu einem arbeitsfähigen Betriebssystem zu bündeln. Zu ihnen gehörten ''MCC Interim Linux'', das auf den FTP-Servern der University of Manchester im Februar 1992 veröffentlicht wurde sowie ''TAMU'' und [[Softlanding Linux System]] (SLS), die etwas später herauskamen. Die erste kommerziell auf CD erhältliche Distribution war 1992 das von Adam J. Richters entwickelte [[Yggdrasil Linux]]. 1993 veröffentlichte [[Patrick Volkerding]] die Distribution [[Slackware]], die auf SLS basiert. Sie ist die älteste heute noch aktive Linux-Distribution. Ebenfalls 1993, ungefähr einen Monat nach der Veröffentlichung von Slackware, wurde das Debian-Projekt ins Leben gerufen, das im Gegensatz zu Slackware gemeinschaftlich entwickelt wird. Die erste stabile Version kam 1996 heraus.<ref>{{Internetquelle \|url=https://www.debian.org/doc/manuals/project-history/ch-detailed.en.html \|titel=A Brief History of Debian - A Detailed History \|hrsg=Debian Documentation Team \|zugriff=2016-08-08 \|archiv-url=https://web.archive.org/web/20150923222945/http://www.debian.org/doc/manuals/project-history/ch-detailed.en.html \|archiv-datum=2015-09-23 \|offline=1 \|archiv-bot=2022-03-15 15:54:40 InternetArchiveBot }}</ref> 2004 wurde von [[Canonical]] das auf Debian basierende, später sehr populäre [[Ubuntu (Betriebssystem)\|Ubuntu]] herausgebracht.<ref>{{Internetquelle \|url=https://wiki.ubuntu.com/Releases \|titel=Releases - Ubuntu Wiki \|hrsg=Canonical \|zugriff=2016-08-08}}</ref>		Da [[Linux]] nur ein Betriebssystem-[[Kernel (Betriebssystem)\|Kernel]] ist, wird weitere Software benötigt, um ein benutzbares Betriebssystem zu erhalten. Aus diesem Grund kamen die ersten Linux-[[Distribution (Software)\|Distributionen]] schon kurz nach der [[GNU General Public License\|GPL-Lizenzierung]] von Linux auf, als Anwender, die nicht zum direkten Entwicklerkreis gehörten, Linux zu nutzen begannen. Die ersten Distributionen hatten dabei das Ziel, das System beispielsweise mit der Software des [[GNU-Projekt]]s zu einem arbeitsfähigen Betriebssystem zu bündeln. Zu ihnen gehörten ''MCC Interim Linux,'' das auf den FTP-Servern der University of Manchester im Februar 1992 veröffentlicht wurde sowie ''TAMU'' und [[Softlanding Linux System]] (SLS), die etwas später herauskamen. Die erste kommerziell auf CD erhältliche Distribution war 1992 das von Adam J. Richters entwickelte [[Yggdrasil Linux]]. 1993 veröffentlichte [[Patrick Volkerding]] die Distribution [[Slackware]], die auf SLS basiert. Sie ist die älteste heute noch aktive Linux-Distribution. Ebenfalls 1993, ungefähr einen Monat nach der Veröffentlichung von Slackware, wurde das Debian-Projekt ins Leben gerufen, das im Gegensatz zu Slackware gemeinschaftlich entwickelt wird. Die erste stabile Version kam 1996 heraus.<ref>{{Internetquelle \|url=https://www.debian.org/doc/manuals/project-history/ch-detailed.en.html \|titel=A Brief History of Debian - A Detailed History \|hrsg=Debian Documentation Team \|zugriff=2016-08-08 \|archiv-url=https://web.archive.org/web/20150923222945/http://www.debian.org/doc/manuals/project-history/ch-detailed.en.html \|archiv-datum=2015-09-23 \|offline=1 \|archiv-bot=2022-03-15 15:54:40 InternetArchiveBot }}</ref> 2004 wurde von [[Canonical]] das auf Debian basierende, später sehr populäre [[Ubuntu (Betriebssystem)\|Ubuntu]] herausgebracht.<ref>{{Internetquelle \|url=https://wiki.ubuntu.com/Releases \|titel=Releases - Ubuntu Wiki \|hrsg=Canonical \|zugriff=2016-08-08}}</ref>

	Die ersten Nutzer kannten noch freie Software aus der Zeit vor den 1980er-Jahren und schätzten Linux, weil sie wieder die [[Verwertungsrecht]]e an der von ihnen verwendeten Software besaßen. Spätere Nutzer waren Unix-Anwender, die Linux zunächst vor allem privat einsetzten und sich vor allem über den geringen Preis freuten. Waren die ersten Distributionen nur der Bequemlichkeit halber geschaffen worden, sind sie doch heute die übliche Art für Nutzer wie auch Entwickler, ein Linux-System zu installieren. Dabei werden die Linux-Distributionen heutzutage sowohl von Entwicklergruppen als auch von Firmen oder gemeinnützigen Projekten entwickelt und betrieben.		Die ersten Nutzer kannten noch freie Software aus der Zeit vor den 1980er-Jahren und schätzten Linux, weil sie wieder die [[Verwertungsrecht]]e an der von ihnen verwendeten Software besaßen. Spätere Nutzer waren Unix-Anwender, die Linux zunächst vor allem privat einsetzten und sich vor allem über den geringen Preis freuten. Waren die ersten Distributionen nur der Bequemlichkeit halber geschaffen worden, sind sie doch heute die übliche Art für Nutzer wie auch Entwickler, ein Linux-System zu installieren. Dabei werden die Linux-Distributionen heutzutage sowohl von Entwicklergruppen als auch von Firmen oder gemeinnützigen Projekten entwickelt und betrieben.

Y2kbug: Linkfix Ubuntu; Ubuntu Software Center verlinkt

2023-12-07T15:42:28Z

Linkfix Ubuntu; Ubuntu Software Center verlinkt

Änderungen zeigen

WAH: Änderungen von 217.151.114.139 (Diskussion) auf die letzte Version von Bleichi zurückgesetzt

2023-09-01T11:32:54Z

Änderungen von 217.151.114.139 (Diskussion) auf die letzte Version von Bleichi zurückgesetzt

← Nächstältere Version		Version vom 1. September 2023, 13:32 Uhr
Zeile 1:		Zeile 1:
	[[Datei:Linux Distribution Timeline.svg\|mini\|hochkant\|Zeitleiste mit der Entwicklung verschiedener Linux-Distributionen]]		[[Datei:Linux Distribution Timeline.svg\|mini\|hochkant\|Zeitleiste mit der Entwicklung verschiedener Linux-Distributionen]]
	Eine '''~~Aarkitanix~~-Distribution''' ist eine Auswahl aufeinander abgestimmter [[Software]] um den [[Linux (Kernel)\|Linux-Kernel]], bei dem es sich dabei in einigen Fällen auch um einen mehr oder minder angepassten und meist in enger Abstimmung mit [[Upstream (Softwareentwicklung)\|Upstream]] selbst gepflegten ''Distributionskernel'' handelt. Üblicherweise wird der Begriff auf Zusammenstellungen begrenzt, die weitgehend linuxtypisch aufgebaut sind, was beispielsweise auf [[Android (Betriebssystem)\|Android]] nicht zutrifft.		Eine '''Linux-Distribution''' ist eine Auswahl aufeinander abgestimmter [[Software]] um den [[Linux (Kernel)\|Linux-Kernel]], bei dem es sich dabei in einigen Fällen auch um einen mehr oder minder angepassten und meist in enger Abstimmung mit [[Upstream (Softwareentwicklung)\|Upstream]] selbst gepflegten ''Distributionskernel'' handelt. Üblicherweise wird der Begriff auf Zusammenstellungen begrenzt, die weitgehend linuxtypisch aufgebaut sind, was beispielsweise auf [[Android (Betriebssystem)\|Android]] nicht zutrifft.

	Distributionen, in denen [[GNU]]-Programme eine essenzielle Rolle spielen, werden auch als „'''GNU/Linux-Distributionen'''“ bezeichnet. Die Namensgebung mit oder ohne GNU-Namenszusatz wird von den Distributoren je nach ihrer Position im [[GNU/Linux-Namensstreit]] unterschiedlich gehandhabt.		Distributionen, in denen [[GNU]]-Programme eine essenzielle Rolle spielen, werden auch als „'''GNU/Linux-Distributionen'''“ bezeichnet. Die Namensgebung mit oder ohne GNU-Namenszusatz wird von den Distributoren je nach ihrer Position im [[GNU/Linux-Namensstreit]] unterschiedlich gehandhabt.

217.151.114.139: Es war Falsch

2023-09-01T11:29:52Z

Es war Falsch

← Nächstältere Version		Version vom 1. September 2023, 13:29 Uhr
Zeile 1:		Zeile 1:
	[[Datei:Linux Distribution Timeline.svg\|mini\|hochkant\|Zeitleiste mit der Entwicklung verschiedener Linux-Distributionen]]		[[Datei:Linux Distribution Timeline.svg\|mini\|hochkant\|Zeitleiste mit der Entwicklung verschiedener Linux-Distributionen]]
	Eine '''~~Linux~~-Distribution''' ist eine Auswahl aufeinander abgestimmter [[Software]] um den [[Linux (Kernel)\|Linux-Kernel]], bei dem es sich dabei in einigen Fällen auch um einen mehr oder minder angepassten und meist in enger Abstimmung mit [[Upstream (Softwareentwicklung)\|Upstream]] selbst gepflegten ''Distributionskernel'' handelt. Üblicherweise wird der Begriff auf Zusammenstellungen begrenzt, die weitgehend linuxtypisch aufgebaut sind, was beispielsweise auf [[Android (Betriebssystem)\|Android]] nicht zutrifft.		Eine '''Aarkitanix-Distribution''' ist eine Auswahl aufeinander abgestimmter [[Software]] um den [[Linux (Kernel)\|Linux-Kernel]], bei dem es sich dabei in einigen Fällen auch um einen mehr oder minder angepassten und meist in enger Abstimmung mit [[Upstream (Softwareentwicklung)\|Upstream]] selbst gepflegten ''Distributionskernel'' handelt. Üblicherweise wird der Begriff auf Zusammenstellungen begrenzt, die weitgehend linuxtypisch aufgebaut sind, was beispielsweise auf [[Android (Betriebssystem)\|Android]] nicht zutrifft.

	Distributionen, in denen [[GNU]]-Programme eine essenzielle Rolle spielen, werden auch als „'''GNU/Linux-Distributionen'''“ bezeichnet. Die Namensgebung mit oder ohne GNU-Namenszusatz wird von den Distributoren je nach ihrer Position im [[GNU/Linux-Namensstreit]] unterschiedlich gehandhabt.		Distributionen, in denen [[GNU]]-Programme eine essenzielle Rolle spielen, werden auch als „'''GNU/Linux-Distributionen'''“ bezeichnet. Die Namensgebung mit oder ohne GNU-Namenszusatz wird von den Distributoren je nach ihrer Position im [[GNU/Linux-Namensstreit]] unterschiedlich gehandhabt.

Bleichi: /* Zusammensetzung */

2023-01-28T15:15:03Z

Zusammensetzung

← Nächstältere Version		Version vom 28. Januar 2023, 17:15 Uhr
Zeile 19:		Zeile 19:
	=== Zusammensetzung ===		=== Zusammensetzung ===
	[[Datei:Linux-Distribution.svg\|mini\|Bestandteile einer Linux-Distribution]]		[[Datei:Linux-Distribution.svg\|mini\|Bestandteile einer Linux-Distribution]]
	Neben dem Linux-Kernel besteht eine Distribution meist aus der [[GNU]]-Software-Umgebung. Diese stellt große Teile des grundlegenden Basissystems mit den zahlreichen Systemdiensten (sogenannten [[Daemon]]s) sowie diverse Anwendungen bereit, die bei einem [[Unixoides System\|unixoiden System]] erwartet werden. Distributionen, welche auch oder nur für Desktop-Systeme gedacht sind, verfügen normalerweise über ein [[Fenstersystem]], derzeit meistens das [[X Window System]]. Ein solches ist für das Ausführen einer [[Grafische Benutzeroberfläche\|grafischen Benutzeroberfläche]] erforderlich. Darauf aufbauend steht meist eine [[Desktop-Umgebung]], wie bspw. [[Gnome]] oder die [[KDE Software Compilation]] zur Verfügung, welche neben der reinen Benutzeroberfläche noch eine Auswahl an [[Anwendungssoftware\|Anwendungsprogrammen]] mitbringt.		Neben dem Linux-Kernel besteht eine Distribution meist aus der [[GNU]]-Software-Umgebung. Diese stellt große Teile des grundlegenden Basissystems mit den zahlreichen Systemdiensten (sogenannten [[Daemon]]s) sowie diverse Anwendungen bereit, die bei einem [[Unixoides System\|unixoiden System]] erwartet werden. Distributionen, welche auch oder nur für Desktop-Systeme gedacht sind, verfügen normalerweise über ein [[Fenstersystem]], derzeit meistens das [[X Window System]]. Ein solches ist für das Ausführen einer [[Grafische Benutzeroberfläche\|grafischen Benutzeroberfläche]] erforderlich. Darauf aufbauend steht meist eine [[Desktop-Umgebung]], wie bspw. [[Gnome]] oder die [[KDE Software Compilation]], zur Verfügung, welche neben der reinen Benutzeroberfläche noch eine Auswahl an [[Anwendungssoftware\|Anwendungsprogrammen]] mitbringt.

	Ergänzend fügt ein Distributor normalerweise zahlreiche weitere Anwendungen bei. Dies sind beispielsweise [[Office-Paket]]e, Multimediasoftware, [[Editor (Software)\|Editoren]], [[E-Mail-Programm]]e, [[Webbrowser\|Browser]], aber auch [[Server]]-Dienste. Daneben finden sich meist Softwareentwicklungs-Werkzeuge wie [[Compiler]] bzw. [[Interpreter]] sowie Editoren.		Ergänzend fügt ein Distributor normalerweise zahlreiche weitere Anwendungen bei. Dies sind beispielsweise [[Office-Paket]]e, Multimediasoftware, [[Editor (Software)\|Editoren]], [[E-Mail-Programm]]e, [[Webbrowser\|Browser]], aber auch [[Server]]-Dienste. Daneben finden sich meist Softwareentwicklungs-Werkzeuge wie [[Compiler]] bzw. [[Interpreter]] sowie Editoren.
Zeile 25:		Zeile 25:
	Viele Softwarebestandteile von Linux-Distributionen, z. B. der Compiler [[GNU Compiler Collection\|GCC]], stammen aus dem älteren GNU-Projekt. Dieses hatte sich schon vor der Entwicklung von Linux die Aufgabe gestellt, eine Alternative zu den kommerziellen [[Unix]]-Betriebssystemen zu entwickeln. Da der eigene Kernel des GNU-Projekts, [[GNU Hurd]], noch in der Entwicklung ist, wird häufig als Ersatz der Linux-Kernel benutzt. Daher ist auch der Doppelname ''GNU/Linux'' für eine Distribution geläufig (z. B. bei [[Debian]]).		Viele Softwarebestandteile von Linux-Distributionen, z. B. der Compiler [[GNU Compiler Collection\|GCC]], stammen aus dem älteren GNU-Projekt. Dieses hatte sich schon vor der Entwicklung von Linux die Aufgabe gestellt, eine Alternative zu den kommerziellen [[Unix]]-Betriebssystemen zu entwickeln. Da der eigene Kernel des GNU-Projekts, [[GNU Hurd]], noch in der Entwicklung ist, wird häufig als Ersatz der Linux-Kernel benutzt. Daher ist auch der Doppelname ''GNU/Linux'' für eine Distribution geläufig (z. B. bei [[Debian]]).

	Es gibt auch Linux-Distributionen, die auf die GNU-Softwareanteile oder ein X Window System komplett verzichten und stattdessen alternative Software nutzen. Diese Distributionen verhalten sich, wie beispielsweise [[FreeVMS]] oder [[BeOS#Cosmoe\|Cosmoe]], teilweise auch nicht annähernd wie ein Unix-System.		Es gibt auch Linux-Distributionen, die auf die GNU-Softwareanteile oder ein X-Window-System komplett verzichten und stattdessen alternative Software nutzen. Diese Distributionen verhalten sich, wie beispielsweise [[FreeVMS]] oder [[BeOS#Cosmoe\|Cosmoe]], teilweise auch nicht annähernd wie ein Unix-System.

	=== Vertrieb ===		=== Vertrieb ===