Sys

Status
Für weitere Antworten geschlossen.
Das ist aber ein allgemeines Problem von Linux, bei deiner Denkweise koennte man dann ueberhaupt nichts machen. Nur: ich behebe schnellstmoeglichst nachvollziehbare Probleme ! Es reicht dass eine neue Version kommt wo die lib von libX.so.56 nach .57 geaendert wurde und schon funktioniert etwas nicht mehr. Chronisch problematisch sind, python oder perl upzudaten
 
So ... hier mal die Ausgabe von fdisk (so war sie vor der Install und ist sie immernoch):
Code:
Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x38d038cf

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         609     4891761    7  HPFS/NTFS
/dev/sda2             610         731      979965   82  Linux swap / Solaris
/dev/sda3             732         743       96390   83  Linux
/dev/sda4             744       26275   205085790    5  Extended
/dev/sda5             744        6822    48829536    7  HPFS/NTFS
/dev/sda6            6823        8038     9767488+  83  Linux
/dev/sda7            8039       25059   136721151   8e  Linux LVM
/dev/sda8           25060       26275     9767488+  83  Linux
Zusatz: Wie man sieht, hab ich damals (aus Unachtsamkeit) die extented Partition zu klein angelegt, so dass da 30GB toter Raum sind ... aber an sowas darf sich der Installer nicht stören.

Log-File gibt es keines. sda1 hat ein zerstörtes FS und auf allen anderen ist keine zusätzliche Datei (ich geh mal davon aus, sie wird nicht irgendwo versteckt) vorhanden.
Mit anderen Worten ... der Installer glaubte, alles ist o.k. ... selbst als offensichtlich die Install des Bootloaders in die Hose ging.
Ich denke auch, es ist ungünstig, den Automatismus auf die primären Partitionen zu beschränken. Bei einer Partitionierung wie oben würde sonst sinnloserweise die komplette erweiterte Partition in Mitleidenschaft gezogen. Das ist auch der Grund, warum ich die derzeitige sda1 nicht vergrößern kann um eventuell an ein Logfile zu kommen, was schon beim schreiben zerstört worden wäre, da keine Platte unter dem Filesystem war (bildlich gesprochen).
Aber unabhängig davon hätte der Installer NIE die 5GB-Partition für die Install nutzen dürfen.
 
Das ist aber ein allgemeines Problem von Linux, bei deiner Denkweise koennte man dann ueberhaupt nichts machen. Nur: ich behebe schnellstmoeglichst nachvollziehbare Probleme ! Es reicht dass eine neue Version kommt wo die lib von libX.so.56 nach .57 geaendert wurde und schon funktioniert etwas nicht mehr. Chronisch problematisch sind, python oder perl upzudaten

Und das sind eben DInge bei denen man sich mittels Paketmanagement wahnsinnig viel Zeit erspart.
 
Also ich kann mich noch an die Zeit erinnern von Mandrake 9 bis 10, da hat sich die Installierung aller 7 CDs 4 Tage lang hingeschleppt, selbst mit rpm -Uhv --replacepkgs --replacefiles --nodeps --ignoresize *.rpm also ohne Ruecksicht auf Verluste, Kontrollen usw vorwaertsinstalliert.

Was so lange dauert ist der Dependenzencheck. Dies geht exponentiell mit der Anzahl. Umgekehrt nimmt linear mit der Anzahl die Wahrscheinlichkeit zu, dass irgendeine zufaellig benoetigte Bibliothek schon da ist. Daher ist bei grossen Systemen das .tgz -System ueberlegen. Meine Installierung ist sehr gross, aber ich habe kaum Probleme und vor allem geht alles schnell. Wenn ein Programm nicht startet, startet man es in xterm, dann bekommt man ausgedruckt was fuer eine lib fehlt. Meist ist es nur eine geaenderte Versions-Nr und man hat die richtige sowieso nicht, beim rpm-System wuerde dann ohne das fehlende Paket aufzutreiben garnichts mehr gehen, bei Sys macht man dagegen einen Link zu was aehnlichem zBsp wenn irgendeine lib.so.56 gebraucht wird aber man hat lib.so.54 macht man einfach einen link dahin und dann geht es fast immer

@62: Gut das ist schon mal etwas. Du hast ganz Recht dass irgendwas schief gelaufen ist, insbesondere dass nicht die 5 GB Partition verwendet werden sollte. Und dass der Installer leider fehlerhaft dachte alles sei OK, sonst haette er das logfile auf alle Partitionen geschrieben incl. auch auf /dev/sda3. Ich versuche einmal, das auf einer leeren Platte zu simulieren.

Komisch ist auch, dass er nicht die leeren 30 GB am Ende der Platte genommen hat, und die Nr . 1 als Partitions-Nr. und dazu die 1. Partition disabelt hat (mit Warnmeldung) wie es eigentlich bei 4 schon vhd. Partitionen funktionieren sollte, und wie ich im vor-vorigem post noch hoffte; dann bekommt man die alte 1. Partition leicht mit fdisk zurueck incl. der Daten und der Moeglichkeit diese woanders hin zu kopieren.

Im Prinzip kannst du die Installierung in Rescue-System wiederholen um das logfile zu erhalten; dazu im rescue-System ./init eintippen, aber am Schluss das CD nicht rausnehmen und mit CTRL-C das Install-Programm abbrechen bevor es rebootet.
Im rescue-System ist der #mc vorhanden; vor Beginn der Installation kannst du damit auch noch in /init (= Install-Prog) am Schluss die reboot-Anweisung loeschen bzw. durch exit ersetzen und/oder davor eine Anweisung reinschreiben womit das logfile explizit in eine Linux- Partition kopiert wird; die Partitionen sind schon gemountet, /dev/sda3 zBsp als /sda3. Ich aendere das jetzt jedenfalls so ab, dass das logfile immer in alle Partitionen geschrieben wird. init ruft das script mkpart auf was den freien Platz und die Install-Partition macht und das script copysys was dann dort das System hinkopiert und lilo einrichtet. Vor Eintippen von ./init koenntest du noch /dev/sda1 ntfs-formatieren damit alles gleich ablaeuft wie vorher. Man koennte auch (in ./init) nach Aufruf von mkpart und vor Aufruf von copysys schon das logfile auf eine Partition kopieren und durch exit ins rescue-System zurueckkehren, denn der Fehler passiert wohl schon in mkpart; im file fdisk.machen findet man uebrigens die Anweisungen der Partitionierung.

Gerade an der extended Partition soll nichts veraendert werden, deshalb wird dort das System nicht installiert; einzige Ausnahme wenn eine extended Partition so gross ist dass der Rest nicht reicht und wenn sie auch noch leeren Platz hat und zusammen mit einer logischen Partition verkleinert werden kann
 
Zuletzt bearbeitet:
Werner, so langsam werden Deine Beiträge derart wiedersprüchlich, dass man sich fragt, wem Du hier eigentlich was vormachen willst. Ich finde es grundsätzlich prima, wenn man sich für Linux einsetzt und es von einem neuen Standpunkt aus zu betrachten versucht, z.B. dahingehend, wie man *noch* mehr Menschen ermöglichen kann, Linux zu verwenden. Das ist zumindest für sich betrachtet erstmal nicht grundsätzlich falsch.

Aber wenn Du einerseits sagst, dass Du ein System entwickeln möchtest, welches meinetwegen auch von drogensüchtigen Analphabeten bedient werden können soll, Du andererseits aber empfiehlst, bei Problemen beim Start von Anwendungen symlinks auf irgendwelche Bibliotheken zu setzen, dann passt das einfach nicht zusammen, verstehst Du? Davon abgesehen sollte man diese Abhängigkeiten durchaus berücksichtigen, denn nicht umsonst gehen Anwendungen davon aus, dass mit dem Aufruf einer Bibliothek eben diese Bibliothek angesteuert wird und nicht irgendeine andere. Es stimmt zwar, dass dies oft genug gut geht, aber früher oder später führt dies zwangsweise zu Scherereien, denn Bibliotheken unterscheiden sich nicht nur in der Versionsnummer, sondern auch in den von ihnen bereitgestellten Funktionen. Auch passt es kaum zusammen, einerseits riesige Mengen an Software in ein System zu schaufeln, andererseits aber zu bemängeln, das eine Abhängigkeitsprüfung desto länger dauert, je mehr Pakete installiert sind. Davon abgesehen stimmt es nicht, dass diese Abhängigkeitsprüfungen grundsätzlich sehr lang dauern müssen. Ich habe derzeit in etwa 2000 Pakete auf meinem System installiert, das ist ausgesprochen viel, dennoch lässt sich ein einzelnes Paket via smart (übrigens ein distributionsunabhängiger Paketmanager) innerhalb weniger Sekunden installieren.
 
Zuletzt bearbeitet:
SYS kommt als fertiges System, dessen Installierung so einfach wie moeglich sein soll. Zumindest in diesem Punkt ist es wie bei einem live-CD. Es ist also meine Aufgabe, dieses fertige System frei von fehlenden Abhaengigkeiten, fehlenden Bibliotheken usw. zu liefern, anders als bei paketgebundenen Systemen wo sich der Benutzer mit den Abhaengigkeiten rumplagen muss.

Insofern ist alles ganz korrekt und maximal einfach fuer den Anfaenger.



Bloss bin ich halt auch nur eine Person, mit beschraenkter Zeit und beschraenkten Kenntnissen. Daher kommt es bei Tausenden von Paketen leicht vor, dass einige davon Probleme haben.

*** Nach wie vor sehe ich das aber hauptsaechlich als mein Problem, das zu beheben. *** Wichtig ist nun, dass SYS bzw. ich mit diesem Problem leicht umgehen kann, und dass ich Wartung/updates betreibe. Genau das mache ich auch.

Dazu gibt es u.a. zwei fuer den Benutzer meist-einfache Moeglichkeiten:

a) Ich mache ein Wartungs-Paket, wo alle fehlenden Links , Bibliotheken usw drin sind; einfaches Installieren mit #installpkg *.tgz korrigiert dann all diese Fehler. Das letzte Wartungspaket, was 0.21 , 0.21-r1 , 0.21-r2 auf den Stand 0.21-r3 updated, ist hier:
ftp://ftp.copaya.yi.org/tgz/SYS_Linux-r-0.21-r3-noarch-1mn.tgz

b) Auf den Install-DVDs , damit nicht neue Fehler hineinkommen, wird einige Zeit ein bestimmtes fertiges System beibehalten, und werden bei der Installierung dieselben Aenderungen angebracht. So ist beim Install-DVD 0.21-r3 das fertige System, .lzma-gezippt, dasselbe wie bei 0.21 , aber es werden bei der Installation iW dieselben Korrekturen angebracht wie im og Wartungspaket. Deshalb sind auf dem DVD Ordner /to_copy , /to_install , /to_upgrade , /to_upgrade_firstrun sowie noch scripts wie SYS_Linux.lzma.correction . In diesen Ordnern befinden sich dann solche Korrekturen -- im einfachsten Fall o.g. Wartungspaket.

Fuer die meisten Korrekturen ist es dabei wurst, ob man sie in welchen der genannten Ordner tut, aber zBsp. ist es gut einen neuen Kernel in /to_install zu tun, sodass er dann nach der Installation gleich benutzt wird, waehrend dann auf diesen neuen Kernel zu beziehende/re-installierende Sachen wie ndiskwrapper, fuse ... in /to_upgrade_firstrun kommen.

Das mache ich schon eine ganze Weile so. Dadurch sind die Install-DVDs sehr einfach wartbar. Und die mirrors kopieren mit rsync und haben das DVD dann oft schon in 1-4 Std.

*** Nochmals zur Klarstellung: Das Wartungspaket was alle Korrekturen anbringt, bzw das neue Install-DVD, zu erstellen ist mein Problem, nicht Problem des Benutzers/Anfaengers. Also nichts kompliziert fuer den Anfaenger ***


Oben hatte jemand geschrieben dass die Installierung neuer Pakete via Internet bei Ubuntu oder RedHat einfach per Doppelklick geht. Das ist bei SYS jetzt einfacher, ich habe das gerade von Doppelklick auf Einfachklick umgestellt, denn wie gesagt ist es meine Politik fuer SYS, auf Wuensche der Leser weitgehendst einzugehen. Wenn man auf irgend ein Paket *.tgz klickt -- egal ob lokal oder im Internet (http oder ftp) -- wird auf diese Datei die Anweisung #upgradepkg --install-new --reinstall %u ausgefuehrt
 
Zuletzt bearbeitet:
Es ist also meine Aufgabe, dieses fertige System frei von fehlenden Abhaengigkeiten, fehlenden Bibliotheken usw. zu liefern, anders als bei paketgebundenen Systemen wo sich der Benutzer mit den Abhaengigkeiten rumplagen muss.

Welche Abhängigkeiten fehlen einem System wie SuSE, Fedora, Mandriva oder Debian nach der Installation? Dieses "Rumplagen" ist doch ein Mythos, den Du hier aufstellst.

Bloss bin ich halt auch nur eine Person, mit beschraenkter Zeit und beschraenkten Kenntnissen. Daher kommt es bei Tausenden von Paketen leicht vor, dass einige davon Probleme haben.

Und das wird wohl auch so bleiben, denn Du deutest nicht an, dass Du Dir auch nur dabei helfen lassen möchtest - vermutlich, um Deine äußerst dogmatischen Sichtweisen erhalten zu können, die Dir vielleicht besonders liberal erscheinen, aber in Wirklichkeit nur vollkommener Quatsch sind. Davon abgesehen wird es Dir nicht möglich sein, sämtliche Pakete aktuell zu halten - Du selber sagst, dass Dir die Zeit dazu fehlt, und da Versionsupgrades einzelner Anwendungen u.a. auch sicherheitsrelevante bugfixes beinhalten, mutest Du den Nutzern von SYS ein unsicheres System zu. Und daher...

werner1234 schrieb:
[...] kommt es bei Tausenden von Paketen leicht vor, dass einige davon Probleme haben.

...und das ist alles andere als nutzerfreundlich, denn im Gegensatz zu anderen Distributionen muss man bei SYS aufgrund der extrem dünnen Personaldecke warten, bis Du eine bestimmte Anwendung endlich übersetzt hast - bei den meisten großen Distris, die Du hier explizit angreifst, stehen bugfixes in der Regel innerhalb von 24 Stunden bereit.

Mach Dir doch nichts vor: Deine Distribution ist ein unsicheres, unsauberes und aufgeblähtes. Einwände (wie z.B. die aus meinem letzten post) ignorierst Du. Du machst Versprechungen, von denen Du noch nicht mal selbst glaubst, dass Du sie einhalten kannst.
 
Alldas was du sagst, ist nun einmal zueigen allen .tgz -artigen Distros - einschliesslich Slackware, VectorLinux, Zenwalk, SLAX, backtrack, AmigoLinux, RIP. Deiner Meinung nach sind diese Distros dann alle Muell. Trotzdem leben die Leute aber damit -- einschliesslich Anfaenger. Einer Umfrage im kurumin-Forum in Brasilien (das einige Millionen Teilnehmer hat), ist dort Slackware die beliebteste Distro ...

Insofern nichts anderes als die schon tausendfach ausdiskutierte Frage nach dem besten package-System ...

Ich kann dazu nur sagen: ich lebe damit. Aehnliche Bibliotheken funktionieren erstaunlich gut, waehrend bei striktem Erfuellen von Dependenzen man viele Programme ueberhaupt nicht installieren koennte.
 
Okay, da Du konkreten Nachfragen weiterhin ausweichst und auch noch fulminanten Blödsinn behauptest, steige ich hiermit aus. Viel Spaß noch!
 
Nein, ich weiche Fragen nicht aus. Ich halte es nur fuer wenig ergiebig, grundsaetzliche Maengel einer bestimmten Paketverwaltung wie .tgz , .rpm oder .deb meiner Distro anzulasten, und dann zu sagen sie sei deswegen schlecht. Grundsatzdiskusionen ueber diese Paketverwaltungen sind schon tausendfach gefuehrt wurden, jedes System hat seine Vor- und Nachteile, und alle drei haben bisher ueberlebt sodass sie auch benutzbar sind.



Und, diese Welt ist nicht perfekt. Man kann mit viel Muehe binnen 2 Monaten vielleicht alle Probleme eines gegebenen Systemes beheben. Gleich danach kann aber die kleinste Aenderung wieder das gesamte System ruinieren (dazu reichen Aenderungen an Perl oder Python). Und selbst wenn nicht, ist das System veraltet wenn es rauskommt.

Das habe ich auch mal versucht bei v. 0.20, die sich mit bis zu 7 -rc's fast 4 Monate hingeschleppt hat. Als sie endlich rauskam, waren die meisten Programme schon so veraltet und waren trotzdem noch ein kleine Fehler drin, sodass 4 Tage spaeter die Version 0.21 mitneuen Programmen und neuem .lzma-gezipptem System gemacht wurde ...

Daher begehe ich nicht mehr diese Strategie, versuchen das System perfekt zu machen. Vielmehr erstelle ich es incl. neusten Programmen, teste es ein paar Tage, gebe es dann heraus, und mache fuer die kleinen unvermeidbaren Fehler dann alsbald Wartungspakete von denen man das jeweils letzte einfach installiert und die Probleme sind behoben.
 
Mal ein paar Beispiele, wo Du meiner Ansicht nach tatsächlich meinen doch recht einfachen Kommentaren ausweichst:

Davon abgesehen sollte man diese Abhängigkeiten durchaus berücksichtigen, denn nicht umsonst gehen Anwendungen davon aus, dass mit dem Aufruf einer Bibliothek eben diese Bibliothek angesteuert wird und nicht irgendeine andere.

Auch passt es kaum zusammen, einerseits riesige Mengen an Software in ein System zu schaufeln, andererseits aber zu bemängeln, das eine Abhängigkeitsprüfung desto länger dauert, je mehr Pakete installiert sind.

Ich habe derzeit in etwa 2000 Pakete auf meinem System installiert, das ist ausgesprochen viel, dennoch lässt sich ein einzelnes Paket via smart (übrigens ein distributionsunabhängiger Paketmanager) innerhalb weniger Sekunden installieren.

[Nachtrag hierzu: ein komplettes Systemupgrade wird über zwei Mausklicks und (je nach aktivierten Repositories) der Investition von etwa 5 bis 10 Minuten bewerkstelligt.]

Welche Abhängigkeiten fehlen einem System wie SuSE, Fedora, Mandriva oder Debian nach der Installation?

Du selber sagst, dass Dir die Zeit dazu fehlt, und da Versionsupgrades einzelner Anwendungen u.a. auch sicherheitsrelevante bugfixes beinhalten, mutest Du den Nutzern von SYS ein unsicheres System zu.

Zu diesen Einwänden gibt es von Dir keinerlei Kommentar.

Was Du als unumgänglich bezüglich der Paketverwaltung mit .tgz-Paketen darstellst, nämlich dass diese gewissermaßen nicht im klassischen Sinne verwaltbar sind und deshalb zu tausenden in ein System geschaufelt werden müssen, ist zudem nicht ganz korrekt. Was ist z.B. mit slapt-get?

Schon klar, ein "perfektes" System wird es kaum geben, dazu ist so etwas wie eine Distribution einfach viel zu komplex - schon einzelne Programme mit etwas umfangreicherer Codebasis können kaum fehlerfrei sein. Aber was Du hier tust, ist das Hinnehmen von Konflikten, wie sie z.B. mit dem laufenden Umbiegen von Bibliotheken via Symlinks zwangsläufig früher oder später entstehen müssen.

Ich finde sogar, dass Du fahrlässig vorgehst, indem Du anderen Leuten ein System zumutest, welches lediglich von Dir selbst und nur "ein paar Tage" getestet wird, bevor es released wird. Probleme, wie sie Goodspeed darstellt, sind wirklich naturgemäß.
 
Ich kann dazu nur sagen: ich lebe damit. Aehnliche Bibliotheken funktionieren erstaunlich gut, waehrend bei striktem Erfuellen von Dependenzen man viele Programme ueberhaupt nicht installieren koennte.
Klar, wenn du ein Benziner mit Diesel tankst, faehrt der auch noch einen Moment...

Der Rest ist bloedsinn, Abhaengigkeiten ueberpruefen dauert bei dpkg bei 3.400 Paketen (4,6 Gb, das System komplett und enthaelt jede Menge lib-Leichen, die ich noch nicht entsorgt hae, wobei hier schon ein autoremove reichen wuerde) dauert auf meinem p3 768mhz gerade mal 7 Sekunden, wenn er einen schlechten Tag hat.

So what?
 
Die Nr. von Bibliotheken gibt nichts anderes als die Version an. Eine andere Nr. zu benutzen, bedeutet daher keineswegs Inkompatiblitaeten, wenn es sie allerdings geben kann.

Wichtig ist, dass beim Aufruf die Parameter dieselben bleiben, also zBsp: "procedure" A(X1,X2) aufgerufen wird durch etwas wie A(X1,X2). Bei kuenftigen Aenderungen kann das auch noch benutzt und aufgerufen werden durch A(X1,X2,X3) oder A(X1), wenn auch nicht ganz sauber und dann ohne die Parameter X3 bzw X2 zu nutzen (wobei dann schon ihr Nachtrag bzw. Ausscheiden bedeutet, dass sie anscheinend nicht sehr wichtig sind, und daher bei der frueheren oder spaeteren Version von Programm oder library ignoriert wurden und werden konnten - bei einem Video-Player koennte etwa X1 Name des Video, X2 Art wie avi oder mpg, X3 zBsp die Monitorhelligkeit-Adaptierung sein, ohne der aber das Video auch noch funktioniert). Dagegen ein aufrufendes Programm abgeaendert zu A(X2,X3) oder A(X2,X1) wuerde wirklich die Verwendung einer auch entsprechend geaenderten Bibliothek erfordern .

Mit deiner Argumentation wuerde gar nichts mehr gehen. Schon der Kernel aendert sich und ist insbesondere/ausdruecklich weder auf- noch abwaertskompatibel um seine Fortentwicklung nicht zu behindern. Ganz genau genommen und nach deiner Argumentation, darf man glibc und Programme die damit zu keadern von Kernel X uebersetzt wurden, nicht mehr zusammen mit einem anderen Kernel Y benutzen.

Aber hier kommt der Unterschied, was theoretisch und was praktisch relevant ist. Theoretisch ist schon nach kleinster Aenderung im Unterprogramm ein Parameter X1 nicht mehr derselbe wie vorher da er dort etwas geringfuegig anderes macht als vorher. In der Praxis ist er aber, zumindest bei halbwegs sinnvollem Programmieren, "hinreichend ungefaehr" "derselbe" und wird also solcher angesehen und benutzt. Andernfalls waere ueberhaupt keine Informatik mehr moeglich !!!

Tagtaeglich kommen viele neue Versionen. Nur als Beispiel, vorgestern kam wine 0.9.60 , vorher war es 0.9.59. Wegen dieser Aenderung rufe ich vielleicht 1 oder 2 W$-Programme damit auf, danach nehme ich an dass es geht. Ich kann nicht wegen jeder Versions-Aenderung Tausende Anwendungen damit testen. Das ist auch Verantwortung des Programmierers von wine, nicht der Distro. Der Herausgeber einer Distro testet anfangs die Programme, incl. zur Entscheidung ob das Programm prinzipiell brauchbar ist und zusagt, aber dann bei Versions-Aenderungen nur noch bedingt. Auch wenn sich der Kernel aendert, kann ich ihn nicht jedesmal selbst voll durchkriechen nach Fehlern, das ist Problem der Kernel-Spezialisten.


Nun gut, obwohl ich selbst nur geringe Probleme mit dem .tgz -System habe, soll SYS ja selbst festgefahrene Maengel und verkrustete Denkweisen durchbrechen um die Anfaenger- und Desktop-Freundlichkeit von Linux zu verbessern. Daher denke ich ueber eine Verbesserung der Paketverwaltung nach. Meine eigenen Pakete haben schon eine Datei drin mit den Dependenzen, die ich per libtool erzeuge -- nur wird die vom .tgz -System nicht benutzt (also wird nicht ueberprueft dass diese noetigen Programme auch da sind). Ich glaube, guenstig ist es zunaechst einmal, dass ich ein tool benutze und beifuege, was ein gegebenes System nach allen bzw. fehlenden Dependenzen abklappert, sodass ich/man danach installiere was fehlt.




Bitte verwechsele nicht das Install-Programm mit den sonstigen Programmen. Das Install-Programm habe ich selbst gemacht und auch sehr gut getestet. Hier besteht nicht obiges Problem mit den Abhaengigkeiten. Das Install-Programm hat in jedem Fall zu funktionieren und wenn es Probleme gibt, bemuehe ich mich auch maximal die zu beheben. Auch hier ist es wie bei der Informatik allgemein: selbst wenn ein Programm theoretisch immer funktionieren sollte, kann man in der Praxis nur eine begrenzte Zahl an Moeglichkeiten austesten, und kann bei anderen irgendwas Unvorhergesehenes passieren. Ferner hat man zum Testen nur eine begrenzte Anzahl an Hardware. Theoretisch sollte das Install-Programm abbrechen, wenn die Festplatte kleiner als 18 GB ist oder ihre Groesse gar negativ -- nur habe ich nicht solche Festplatten sodass ich es nicht damit testen kann.
 
Zuletzt bearbeitet:
Die Nr. von Bibliotheken gibt nichts anderes als die Version an. Eine andere Nr. zu benutzen, bedeutet daher keineswegs Inkompatiblitaeten, wenn es sie allerdings geben kann.
Doch. Neue Version heißt nicht automatisch "alles wie vorher plus ein feature".

Wichtig ist, dass beim Aufruf die Parameter dieselben bleiben, also zBsp: "procedure" A(X1,X2) aufgerufen wird durch etwas wie A(X1,X2). Bei kuenftigen Aenderungen kann das auch noch benutzt und aufgerufen werden durch A(X1,X2,X3) oder A(X1), wenn auch nicht ganz sauber und dann ohne die Parameter X3 bzw X2 zu nutzen (wobei dann schon ihr Nachtrag bzw. Ausscheiden bedeutet, dass sie anscheinend nicht sehr wichtig sind, und daher bei der frueheren oder spaeteren Version von Programm oder library ignoriert wurden und werden konnten - bei einem Video-Player koennte etwa X1 Name des Video, X2 Art wie avi oder mpg, X3 zBsp die Monitorhelligkeit-Adaptierung sein, ohne der aber das Video auch noch funktioniert). Dagegen ein aufrufendes Programm abgeaendert zu A(X2,X3) oder A(X2,X1) wuerde wirklich die Verwendung einer auch entsprechend geaenderten Bibliothek erfordern .
Nein, denn auch innerhalb der Bibliothek kann sich einiges aendern.

Mit deiner Argumentation wuerde gar nichts mehr gehen. Schon der Kernel aendert sich und ist insbesondere/ausdruecklich weder auf- noch abwaertskompatibel um seine Fortentwicklung nicht zu behindern. Ganz genau genommen und nach deiner Argumentation, darf man glibc und Programme die damit zu keadern von Kernel X uebersetzt wurden, nicht mehr zusammen mit einem anderen Kernel Y benutzen.
Ganz genau, den ein fuer eine Kernelversion gebautes Kernelmodul wird mit einem anderen kernel nicht gehen. Auch eine andere glibc macht gewaltige Unterschiede.

Aber hier kommt der Unterschied, was theoretisch und was praktisch relevant ist. Theoretisch ist schon nach kleinster Aenderung im Unterprogramm ein Parameter X1 nicht mehr derselbe wie vorher da er dort etwas geringfuegig anderes macht als vorher. In der Praxis ist er aber, zumindest bei halbwegs sinnvollem Programmieren, "hinreichend ungefaehr" "derselbe" und wird also solcher angesehen und benutzt. Andernfalls waere ueberhaupt keine Informatik mehr moeglich !!!
Das ist ein bißchen blauaeugig, sorry. Gerade in der Informatik haben kleinste Aenderungen in der Praxis gewaltige Auswirkungen, ich erlebe das taeglich durch meine Arbeitsstelle, eine Softwarefirma.

Tagtaeglich kommen viele neue Versionen. Nur als Beispiel, vorgestern kam wine 0.9.60 , vorher war es 0.9.59. Wegen dieser Aenderung rufe ich vielleicht 1 oder 2 W$-Programme damit auf, danach nehme ich an dass es geht. Ich kann nicht wegen jeder Versions-Aenderung Tausende Anwendungen damit testen. Das ist auch Verantwortung des Programmierers von wine, nicht der Distro. Der Herausgeber einer Distro testet anfangs die Programme, incl. zur Entscheidung ob das Programm prinzipiell brauchbar ist und zusagt, aber dann bei Versions-Aenderungen nur noch bedingt. Auch wenn sich der Kernel aendert, kann ich ihn nicht jedesmal selbst voll durchkriechen nach Fehlern, das ist Problem der Kernel-Spezialisten.

Irrtum, gerade wenn man eine Distribution rausgibt sollte man die Programme die man mitliefert ausgiebig testen. Einfach 1000e Pakete mitliefern nach dem Motto "wird schon hinhauen" ist nicht sehr verantwortungsvoll.


Bitte verwechsele nicht das Install-Programm mit den sonstigen Programmen. Das Install-Programm habe ich selbst gemacht und auch sehr gut getestet. Hier besteht nicht obiges Problem mit den Abhaengigkeiten. Das Install-Programm hat in jedem Fall zu funktionieren und wenn es Probleme gibt, bemuehe ich mich auch maximal die zu beheben. Auch hier ist es wie bei der Informatik allgemein: selbst wenn ein Programm theoretisch immer funktionieren sollte, kann man in der Praxis nur eine begrenzte Zahl an Moeglichkeiten austesten, und kann bei anderen irgendwas Unvorhergesehenes passieren. Ferner hat man zum Testen nur eine begrenzte Anzahl an Hardware. Theoretisch sollte das Install-Programm abbrechen, wenn die Festplatte kleiner als 18 GB ist oder ihre Groesse gar negativ -- nur habe ich nicht solche Festplatten sodass ich es nicht damit testen kann.
Eine Distribution ist mehr als nur ein Installer.
 
Keine ahnung, ob wer diesen aspekt auch schon angesprochen hat:

wenn es in deiener umgebung, soviel armut und vor allem analphabetismus gibt, ist es dann nicht sinnvoller in deinem umfeld dafür zu sorgen, dass die leute erstmal lesen und schreiben lernen.

oder unterstellst du den menschen von vorn herein, dass sie gar nichts lernen wollen? wenn du das glaubst, halte ich dich für ignorant, da meines erachtens lernen ein natürliches bedürfnis eines jeden menschen ist,- genauso wie essen und trinken.

du solltest deinen mitmenschen nicht einfach unterstellen, dass sie doof sind oder nichst lernen wollen und irgndewie so ne distri zusammenklempnern, die keiner braucht. ubuntu wird z.b auch in afrika in den ländern eingestezt wo die menschen auch nicht lesen und schreiben können,- dort wird ihnen auch nicht einfach was auf ihren computer gerotzt, sondern dort gibt es förderprgramme, die den leuten zeigt, wie man mit einem computer umgeht.

deine einstellung finde ich zum *** du fummelst da ne distri zusammen, die nicht funktioniert und wahrscheinlich immer fehler haben wird, weil so etwas wie ne eigene distri ganz allein zu pflegen unmöglich ist, die sich nicht an den standard hält: da werden eben mal die /usr/doc und /usr/share/doc verzeichnisse gelöscht und die nen patzen software installiert die selbst ich nicht brauche und ich habe eigentlich von allem etwas,- dann bietets du diesen müll als die ultimative lösung an. du kommst mir vor wie der arzt, der zu allem erstmal penizilin verschreibt, ohne die ursachen zu bekämpfen.
 
Bekanntlich kann eine einfache Person mehr dumme Fragen stellen als tausend Wissenschaftler beantworten. Auch bei Distros ist es so, dass man sich im Prinzip jede x-beliebige hernehmen und zerpfluecken und am Schluss sagen kann dass das alles Muell und fuer niemanden nuetzlich ist.

Ich versuche sachlich zu bleiben.

1) Ich benutze seit den Anfaengen Linux, ohne nennenswerte Probleme mit meinem eigenem System. Um den upgedated zu halten, uebersetze ich schon lange Programme selbst, und vor ca. 1 Jahr bin ich dazu uebergegangen, sie auch zu packen und zu einer der 3 Paketverwaltungen als ausschliesslich ueberzugehen. Gleichzeitig kommen zu mir dauernd Nachbarn, Freunde, andere Leute mit kaputten W$-Computern, oft sogar in kurzer Zeitabfolge dieselben Leute wegen eines neuen Virus.

Es ist daher naheliegend und objektiv angemessen (unabhaengig von irgendwelchen religioesen, puristischen , bekehrungsartigen Einstellungen, sondern hauptsachlich zweckorientiert), zumindest versuchsweise den Leuten Linux zu installieren ind sehen ob sie damit klarkommen.

Unabhaengig davon wird derzeit die Linux-Desktop-Tauglichkeit diskutiert. Entgegen andersartigen Behauptungen wird diese von L.Torwald und den fuehrenden, wohl auch den meisten anderen Programmierern i.Ue. auch gewuenscht, zumindest steht sie ihnen nicht entgegen.

Man sieht dann ziemlich schnell, das da zwei Seiten sind, die voellig aneinander vorbeireden bzw. sich und ihre Probleme oder potentielle Nutzung gar nicht kennen. Anders dagegen W$, was auf die Bevoelkerung eingeht oder eingehen muss, wobei die Gruende nebensaechlich sind und nur der Sachverhalt letztlich von Belang ist.

Da es von Pakete machen bis zu einer Distro nur ein kleiner Sprung ist; da das Kopieren eines gut adjustierten Systemes viel schneller als das Neuinstallieren usw geht, aber ich es leid bin, immer meine Festplatte raus- und reinzuschrauben; und da es im Kontakt mit den Menschen ziemlich schnell ersichtlich ist, in welchen Punkten Linux benutzerfreundlicher werden sollte, habe ich letztlich eine entsprechende Distro gemacht.

Dieser Herkunft nach, ist fast zu erwarten dass: / die Distro maximal einfach installierbar und bedienbar sein soll, incl. fuer einfache Leute. Selbst der Name wurde maximal einfach, fast logisch, gewaehlt ; / dass iW ein gut installiertes fertiges Programm einfach kopiert und dann an den Ziel-Computer angepasst widr ; / das dies konsequent und schnell und einfach benutzbar erfolgt, also nicht wie bei den live-CDs 100x probieren aber W$ installiert lassen

Schon lange bevor ich meine Distro begonnen habe, habe ich gesehen, dass die Leute zumindest mit meinem fertigen System wo kaum noch was anzupassen ist, Internet usw funktionieren, klarkommen. Typischerweise kommen sie erst nach Monaten wieder, wenn etwas nicht mehr geht, oder wenn sie zusaetzliche Programme wollen. Jetzt auf dem Install-DVD kann ich nicht eine Kopie meines viel groesseren eigenen Systemes unterbringen, aber ich kann ein zweites kleines System machen, wo die wichtigsten derselben Programme enthalten sind, und die wesentlichen Sachen (wie Video, Internet, wifi, bluetooth usw) direkt funktionieren, und das so reichhaltig ist, dass zumindest am Anfang der Benutzer nicht dringend fehlende Sachen nachinstallieren muss.

Bis zur V. 0.19 gab es noch Probleme mit der Installierung. Diese hatte Probleme mit extended Partitionen, ferner waren nur IDE aber keine SATA -Geraete vorgesehen, und es waren noch Fehler im Partitionierungs- und im Installprogramm. Ich habe dann das Programm nochmal sorgfaeltig ueberarbeitet und auf meinen und einigen anderen Rechnern getestet. V. 0.20-rc2 war auch die erste, die umfangreich im Internet verbreitet wurde (ueber 1000x downgeladen). Mit dem Install-Programm wurden dann bis vorgestern (hier im Forum) keine Fehler mehr gemeldet. Es gab allerdings folgende Probleme bei der Installierung wegen anderen Programmen: / bei einigen Rechnern Probleme mit der hardware-Erkennung / Behandlung durch den Kernel und Absturz beim booten; der Parameter pci=off half hier immer aber ist nutzlos da dann auch keine Festplatten usw gefunden werden / bei einer neuen Version von busybox geht lzmacat nicht richtig, Abbruch vor Ende der Datei, im Installer durch normales lzma ersetzt / fatresize von Debian funktioniert nicht, das ca. 260k grosse Programm macht 'irgendwas' aber jedenfalls nichts richtiges. Have ich vorgestern selbst uebersetzt, wurde nur 12k gross und funktioniert jetzt.

Die meisten Bemaengelungen betreffen Programme die nicht starten. Diese Bemaengelungen sind aber anzahlmaessig wenige, und ich schaetze dass der Anteil an nicht funktionierenden Programmen bei etwa 2% liegt. Das kann man sozusagen als Rauschen ansehen. Bei jeder neuen Version sind es andere Programme, waehrend die vorher problematischen gehen, jenachdem wo irgendwelchen libs, links fehlen oder andere Versions-Nr haben.

Weil sonst wieder neue Fehler hineinkaemen und sich nichts niemals stabilisieren wuerde, lasse ich das kompaktierte System eine Zeitlang so, und mache fuer die gemeldeten Probleme ein Wartungs-Paket was man installiert und was dann die Fehler behebt. Die kuenftigen Install-DVDs VersionX - rY enthalten schon diese Korrekturen die bei der Installation oder beim ersten Benutzen angebracht werden.

In dieser Weise funktioniert das inzwischen gut und ist auch sehr bequem fuer mich und fuer die Benutzer wartbar.


2) Zumindest hier sind die Leute sehr zufrieden damit. Selbst Kinder schaffen es meistens, das DVD einzulegen und die automatische Installation abzuwarten. In meiner naeheren Umgebung ist bereits auf 40 Rechnern SYS installiert, in ganz Cayenne vielleicht auf 100. Und die 4 Computer-Shops hier benutzen mein Rescue-System, um von kaputten W$-Rechnern die Daten woandershin zu kopieren. Inzwischen sehe ich auch hierher ueber Paraguay oder China direkt importierte systemlose PCs mit SYS ausgestattet.

Es ist verhaeltnismaessig selten, dass jemand mit einem Problem kommt; viel oefter sind es Fragen, wie man bestimmte Programme benutzt.

Zu beachten ist, dass Anfaenger oder neue Rechner selten 4 oder extended Partitionen haben. Meist ist Windows installiert und entweder nur 1 primaere Partition, oder 1 extended mit einer logischen da; beide Faelle bearbeitet das Install-Programm korrekt. Leute die mehr Partitionen und/oder gar Linux-Partitionen haben, kennen regelmaessig Linux schon und sind nicht bekehrungs- oder hilfsbeduerftig, sodass ich um solche Faelle nicht sonderlich besorgt bin. Aber das Install-Programm hat auch in solchen Faellen entweder zu funktionieren oder abzubrechen, jedenfalls nicht falsch funktionieren.


3) Schon deshalb besteht nicht die geringste Frage, dass SYS Erfolg hat; den hatte es schon bevor damit begonnen, als ich mein eigenes System den Leuten kopiert habe. Und wie in den letzten 15 Jahren, uebersetze ich selber weiterhin Programme fuer meinen Rechner und das packen geht jetzt automatisch mit meinem script auto.SlackBuild was auch im rescue-System ist.

Und jetzt erst recht, wo sich die DVDs gut verbreiten. Bei der Zielgruppe hat es jedenfalls Erfolg, und mir erleichtert es die Arbeit bei Bekannten Linux zu installieren wozu ich jetzt selbst die DVDs nehme (und dann bei den Leuten lasse) und so auch selbst sehe wenn etwas nicht funktioniert. Pro Woche installiere ich 3-4 Rechner damit.

Theoretisch ist es ja richtig, dass ein depenzenabhaengiges System sauberer ist. Aber in der Praxis, wie gesagt, sind die Reklamationen deswegen selten, und korrigiere ich zu jeder Version vorher gefundene Fehler schnell.

Daher wollen wir hier jetzt nicht uebertreiben und den Teufel an die Wand malen. Unbrauchbar fuer Anfaenger ist SYS sicherlich nicht, das sehe ich hier direkt vor Ort genau gegenteilig.

Andererseits moechte ich die von BENUTZERN vorgebrachten Bemaengelungen auch beruecksichtigen. Ich denke daher einmal darueber nach, was man da machen kann.


4) Bekanntlich reicht ein einzelnes falsches bit aus, und ein DVD bootet/installiert nicht mehr; der Kernel startet nicht mehr; ein System oder die Grafik geht nicht mehr ...

Die Install-DVDs von Slackware 12 booten nicht, wenn man nicht eine bestimmte Kernel-Option eintippt. Am letzten Tag hatte der Vertreiber auf Empfehlung von Intel auf die Schnelle noch eine Aenderung gemacht ....

Hier ist SCHWERWIEGEND von SCHWERWIEGEND zu unterscheiden. Schwerwiegend ist das insofern, dass die Funktion des Systemes in diesem Moment nicht geht, ohne Frage. Aber schwerwiegend ist es nicht insofern, dass damit jahrelange Entwicklung des Systemes hinfaellig geworden waere, oder das das System an sich nichts taugt. Denn genauso einfach wie ein solcher Fehler entsteht, ist er nach dem Auffinden auch behoben.

Es war sowohl mein als auch sein ausgesprochenes Pech, dass auf dem Rechner die Installation fehlschlug. Den genauen Grund dafuer wissen wir noch nicht, grundsaetzlich moechte ich den Fehler auch beheben und hoffe, dafuer genauere Kenntnisse des Grundes zu finden. Man kann aber deswegen nicht sagen, dass SYS unbrauchbar, zukunftslos, oder gescheitert sei. Den mirrors nach wurde es rd. 1500 x downgeladen, und schon seit langem kam keine Beschwerde mehr ueber eine fehlgeschlagene Installierung.
Aber nochmals: das ist lediglich die Erwiderung auf solche totale Schwarzmalerei gegen SYS inegesamt; es ist keine Rechtfertigung des Fehlers der in jedem Fall behoben (Korrektur des mkpart Programmes) oder abgestellt (Verweigerung der Installation bei kompliziert partitionierten Festplatten) werden muss.


5) Nun, sobald das Programm behoben ist, kuemmere ich mich ernsthaft um das Problem der Abhaengigkeiten, wenn das wohl auch erst in V. 0.23 oder 0.24 verbessert sein wird; die Aktualisierung ist in den Augen der Benutzer viel wichtiger sodass ich mich momentan darum kuemmere.

Nun, wie koennen Teilnehmer diese Forums noch zu meinem Projekt beitragen ? Grundsaetzlich: umso spezialisierter man ist, desto weniger kann men zu einer Distro fuer Anfaenger beitragen. Weniger spezialisierte, einfache Teilnehmer koennen versuchen, es zu installieren und zu benutzen, und berichten wo stns der Benutzerfreundlichkeit etwas verbessert werden sollte.

Allgemein und auf geringerer Stufe als durch / Vorstufe zu einer Distro, kann man zu Linux beitragen, indem man Programme compiliert und packt fuer die das sonst niemand macht. Dazu gehoeren zBsp alte Spiele von CPM oder den ersten PCs inclusive abandonware . Das habe ich ebenfalls vor sys schon gemacht (u.a. digger). Solche Pakete .tgz oder .rpm kann man dann zum download tun. Viele Distros incl. SYS kommen mit dem Packen nicht nah, beschraenken sich auf die wesentlichsten Pakete, und nehmen nebensaechlichere von anderen Quellen. Waehrend zBsp Zenwalk usw. solche Pakete ohne eigener Compilierung trivial re-packen und ihre Abkuerzung hinzusetzen, bin ich bei SYS so ehrlich und benutze solche Pakete in der Originalform und schreibe auch dass ich teilweise Pakete anderer Distros benutze. Ebenso waehrend andere die Original -Slackware skripte benutzen, benutze ich zum Uebersetzen / Packen mein eigenes Verfahren und script auto.SlackBuild . Die einzigen die ich da ausser Slackware selbst fuer innovativ halte ist AmigoLinux.
 
Du solltest dich insbesondere auch darum bemühen dich an die GPL zu halten.

Lizenzverstoß => Meldung an ********** => Abmahnung!

Schönen Tag noch.
 
Hör auf hier werbung für dein komisches friemellinux zu machen. Das interessiert hier niemanden.

Ich denke, wir freuen uns alle dass du imstande bist, deine eigene distribution zusmmmenzukleistern und es freut uns auch, dass das in deiner umgebung von deinen mitmenschen positiv aufgenommen wird,- und genau das ist es auch: etwas mit denen du den leuten in deinem sozialen umfeld eine freude machen kannst,- aber hier will davon niemand etwas wissen.

Nimm mal die Scheuklappen ab, wenn du hier postest.

over and out
 
Zuletzt bearbeitet:
Gut, unter Voraussetzung meines posts gehet ich jetzt noch auf die verbleibenden Fragen der Teilnehmer ein.


@71

Massgeblich ist, ob eine Bibliothek mit einer geaenderten Versions-Nr noch funktioniert oder nicht. Wenn bzw soweit wie das der Fall ist, ist es OK. Das sieht man ja dann wenn man den link macht, ob das Programm hinterher laeuft oder nicht. Erfahrungsgemaess ist das in 99% der Faellen so. Am besten macht man das via xterm, da sieht man dann auch glaich noch weitere ggf. fehlenden libraries / links / deps. Wenn ich dann eine neue Version mache und alle Programme update, wird das automatisch verbessert/ersetzt wenn die neue Version der lib dann kommt.

Bei .tgz findet ueberhaupt keine Abhaengigkeitspruefung statt, und geht alles schnell

Bei sys sind es ungefaehr 5000 Pakete. Hinzu kommt noch, dass beim .tgz -System nicht jedes Programm in 20 Pakete unterteilt wird und / oder -dev wie bei .rpm, vielmehr ist alles zusammen. ZBsp fuer perl, python usw nur 1 Paket. Bei mir auch fuer den Kernel 1 Paket.

Bei den .rpm -Systemen moegen am Schluss keine Abhaengigkeiten fehlen. Dafuer hast du aber viel mehrfach installiert weil sowohl lib.so.56 als .57 als .58 .... gebraucht werden, und andere Programme kannst du ueberhaupt nicht installieren weil eine lib nicht auftreibbar ist. Stattdessen mache ich da einfach einen link. 99%-iges Funktionieren ist besser als 0-%iges.

slapt-get ermoeglicht automatisches downloaden und Installieren, aber ueberprueft auch keine Abhaengigkeiten.

Zenwalk, AmigoLinux, Vector, und auch SYS erstellen fuer Pakete die Abhaengigkeiten (bei mir unter /doc Datei mit Dependenzen enthalten), benutzen sie dann aber nicht

Was bitte soll deswegen an sys 'unsicher' oder fahrlaessig sein sein ???? Wie gesagt, die wesentlichen, wichtigen Programme hatten nie Probleme wegen Abhaengigkeiten, das wuerde ich beim Testen schnell merken. Nur teste ich nicht jedesmal Tausende nebensaechlicher Programme. Einen Teil schon aber nicht alle. Wenn halt mal smplayer oder acidrip nicht geht, dann bricht nicht das gesamte System zusammen, noch entstuenden dadurch 'unsichere' oder 'fahrlaessige' Resultate ...

@74

Die Nr. ist rein die Versios-Nr, rein das und nichts anderes. Die Funktion kann anders sein, muss es aber nicht, und selbst wenn, betrifft dies nur 0.001% der Faelle.

Beispiel: heute Nacht mache ich vstl SYS 0.21-r5. Das ist zunaechst nur rein eine neue Versions-Nr zur Unterscheidung. Geaendert werden sein wird das Install-Skript init und mkpart und copysys, ferner tue ich in den Ordner to_update noch evtl. nachher kommende neue Version irgendwelcher Programme (gestern war es zBsp wine). Alles andere bleibt gleich. Von 4482 MB aendern sich weniger als 0.1 MB . Also praktisch alle Programme vom installierten SYS 0.21-r5 werden funktionieren wie bei 0.21 . Mit Ausnahme (hoffentlich) des Installers

Die Funktion innerhalb von Subroutinen mag sich aendern, idR aber aufwaertskompatibel. Deswegen verlinkst du ja auch libX.57 mit .60 und nicht umgekehrt . Auch hier wieder: alles aendert sich, wenn auch nur minimal, wenn sich eine kleinste Bibliothek im System aendert -- aber praktisch ist das als belanglos zu behandeln, sonst waere keine Informatik mehr moeglich.

Beim Kernel spreche ich nicht ueber die Module. Diese haben eine besondere Funktionsweise / Verbindung zum Kernel selbst, und sind de facto inkompatibel zu anderen Versionen. Vergleichbar mit sonstiger software sind dagegen bereits die Treiber, oder ueberhaupt alle Programme die die Kernel-header benutzen. Gerade der Kernel ist ausdruecklich nicht aufwaertskompatibel, um seine Fortentwicklung nicht einzuschraenken. Theoretisch um alles ganz sauber zu machen im hier von euch reklamierten Sinne, muesste man saemtliche Programme zum jeweils uebersetzten Kernel neu uebersetzen. Das ist aber eben unpraktikabel. Deshalb formalisiert man die Wechselwirkung der Programme mit dem Kernel in Kernel-Headers. Auch die sind genaugenommen nicht aufwaertskompatibel, meist wird die Anzahl der Parameter nachfolgend erweitert oder verringert. Aber die Kernel-Entwickler achten darauf, dass das in einer Weise erfolgt, dass die Anwendungen zu 99,999% noch funktionieren. Abgesehen von grossen Spruengen (von Kernel 2.2 , 2.4 , 2.6) kann man in der Praxis dieselben Programme fuer geaenderten Kernel weiterverwenden, theoretisch koennte man das nicht und wuerden dann alle euere Argumente gelten (wie, dass Aenderungen im Kernel de facto erfolgten und er daher als subroutine anders funktioniert)

Du benutzt das Problem mit einer Installierung also das Problem des Installers, um zu sagen, die ganze Distro sei Mist, das ist unsachlich. Auf den (vielen) Rechnern wo die Installation geklappt hat, interesiert anschliessend das Install-Programm nicht mehr

@75

Dieser post ist so wenig sachlich dass es kaum relevant ist darauf zu antworten.

Lesen und schreiben, entweder die leute lernen das in der Schule oder danach oder ueberhaupt nicht mehr. Wie auch immer, auch Analphabeten wollen und tun Computer, Video, Internet benutzen.

Die hier relevante Frage ist daher allenfalls, ob man ihnen Linux installieren oder besser W$ lassen sollte.

Antwort: Von der positiven Richtung her: wenn Linux einen leichten Schliff bekommt - und das ist ja gerade Absicht von SYS - dann spricht zumindest nichts dagegen, den Leuten Linux zu installieren. Von der negativen Richtung her: W$ kriegt fortwaehrend Virus oder fehlendes irgendwas32.dll , wird sehr schnell sehr langsam, usw, Linux ist objektiv besser. Man muss die Menschen nur von den baertigen Spinnern freihalten die ihnen ihre kranken programme andrehen wollen

Ich tue niemand disqualifizieren oder diskriminieren, im gegenteil meint ihr, Linux sei nur fuer euch, die dummen sollen mit W$ bleiben. Ums nochmal zu wiederholen: Linux ist nicht im Prinzip ungeeignet, sondern nur im make-up und in der technischen Aufkochung; ferner in einzelnen Programmen die eingestampft gehoeren; hier leicht verbessert ist es gut geeignet.

Jede Distro hat irgendwelche Fehler. Anders als bei manchen wo wesentliche Sachen nicht gehen, geht bei SYS zumindest alles Wichtige und haben nur nebensaechliche Programme Probleme. Es wird nie gehen ???? Haha !! Die Macken von 0.21 sind in 0.21-r1 schon korrigiert usw. Binnen Stunden oder Tagen !!!

Guck dich doch mal um. Beo 99% der Distros berichten irgendwelche Leser ueber Probleme incl. Erfolglosigkeit der Installation ! Trotzdem bedeutet das nicht, das die Distro insgesamt Mist ist. Abgesehen davon dass die auf anderen Rechnern geht, werden Fehler normalerweise schnell behoben

Auch bei 70% der live-CDs fehlt /usr/doc

@77

Ich halte mich an die GPL zusammen mit der gueltigen Rechtsprechung soweit wie dies im Durchschnitt alle Distros tun
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Zurück
Oben