Ingo Molnár

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Ingo Molnár (2005)

Ingo Molnár ist ein ungarischer Softwareentwickler, der wesentliche Komponenten im Open-Source-Kernel Linux entwickelt hat.

Arbeit[Bearbeiten]

Seine bekanntesten Entwicklungen sind der O(1)-Scheduler und der Completely Fair Scheduler im 2.6er-Kernel und der kernelbasierte Webserver Tux. Weitere wesentliche Beiträge zum Linux-Kernel sind Verbesserungen am Thread-System des Kernels und der sogenannte Exec Shield, welcher Buffer Overflows auf der x86er-Architektur verhindern kann. Sein aktuelles Projekt ist der realtime preemption patch (rt-tree genannt), das den Linux-Kernel um Echtzeitfähigkeiten erweitert. Ingo Molnár ist zurzeit bei Red Hat angestellt.

Linux Desktop Kritik[Bearbeiten]

2012 kritisierte Molnar den Linux-Desktop deutlich als "nicht frei genug", da die zentral organisierte Softwareverbreitung über die Linux-Distributionen zu träge sei und auch nicht ausreichend mit der Anzahl der Applikationen skaliere um den Erwartungen der Anwender gerecht zu werden.[1] Er plädierte konkret für die Bereitstellung einer dezentralen, skalierungfähigen und distributionsunabhängigen Softwareverbreitungsmethode (ähnlich z. B. Autopackage[2], Zero Install[3], Klik-Nachfolger PortableLinuxApps[4]), das Fehlen eines solchen Mechanismus sei eines der Kernprobleme des Linux-Desktops.[5]

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Ingo Molnar: Technology: What ails the Linux desktop? Part I. (englisch) plus.google.com. 17. März 2012. Abgerufen am 16. Juni 2012: „The basic failure of the free Linux desktop is that it's, perversely, not free enough. There's been a string of Linux desktop quality problems, specific incidents reported by +Linas Vepstas , +Jon Masters , +Linus Torvalds and others, and reading the related G+ discussions made me aware that many OSS developers don't realize what a deep hole we are in. The desktop Linux suckage we are seeing today - on basically all the major Linux distributions - are the final symptoms of mistakes made 10-20 years ago - the death cries of a platform. Desktop Linux distributions are trying to "own" 20 thousand application packages consisting of over a billion lines of code and have created parallel, mostly closed ecosystems around them. The typical update latency for an app is weeks for security fixes (sometimes months) and months (sometimes years) for major features. They are centrally planned, hierarchical organizations instead of distributed, democratic free societies.
  2. Robert Staudinger: Distributionsunabhängige Pakete mit Autopackage - Eines für alle. Linux-Magazin 2006/02. 1. Februar 2006. Abgerufen am 11. April 2012: „Obwohl sie nach dem gleichen Prinzip arbeiten, laufen RPMs von Suse 9.2 nicht unter Suse 9.3 und schon gar nicht unter Red Hat. Das Autopackage-Projekt setzt auf einen einheitlichen Standard für die Erstellung von Installationspaketen. Dabei lösen die einzelnen Pakete ihre Abhängigkeiten selbst auf.
  3. Thomas Leonard: Decentralised Installation Systems (englisch) osnews.com. 16. Januar 2007. Abgerufen am 3. Mai 2012.
  4. Simon Peter: AppImageKit Documentation 1.0 (pdf; 38 kB) PortableLinuxApps.org. S. 2-3. 2010. Abgerufen am 29. Juli 2011: „Linux distributions mostly use package managers for everything. While this is perceived superior to Windows and the Mac by many Linux enthusiasts, it also creates a number of disadvantages: Centralization [...], Duplication of effort [...], Need to be online [...], No recent apps on mature operating systems [...], No way to use multiple versions in parallel [...], Not easy to move an app from one machine to another [...]. The AppImage format has been created with specific objectives in mind: Be distribution-agnostic [...], Maintain binary compatibility [...]
  5. Ingo Molnar: Technology: What ails the Linux desktop? Part II. (englisch) plus.google.com. 17. März 2012. Abgerufen am 16. Juni 2012: „So, to fix desktop Linux we need a radically different software distribution model: less of a cathedral, more of a bazaar. [...] - totally flat package dependencies (i.e. a package update does not forcibly pull in other package updates) [...] - a guaranteed ABI platform going forward (once a package is installed it will never break or require forced updates again). Users want to be free of update pressure from the rest of the system, if they choose to.