Archiv der Kategorie: Linux

All about Linux.

Dear Computer Makers: be visionary, unleash the power of Linux

I’ve just read this article by Jim Mendenhall. Yes, a Linux pre-installation would be a good thing. But I just cannot agree with his choice of Linux distribution: Ubuntu.

Linux for the masses

Ubuntu is said to be the Linux for beginners. But it really is awful. A lot of Linux newbies don’t like Linux because of Ubuntu. Show them Gnome 2 or KDE 4 and they may stay, show them Unity and the run away!

Ubuntu has to go its own way. Mir instead of Wayland, Unity instead of Gnome or KDE. Upstart instead of systemd. Yes, upstart was there first, I know; and they will eventually make the switch to systemd, which probably was greatly inspired by upstart. In this regard: thank you Ubuntu! But Mir and Unity really wasn’t necessary on the desktop!

Linux is all about choice!

There is no Linux but all of them! Linux users like to choose which distribution they want to use. They like to choose which desktop to use.

They like to choose on the hardware side as well: it’s not always low-end they want. Sometimes they’d like to get a high-end computer, but there is none specifically for Linux!

If you know that, pre-installation suddenly doesn’t make that much sense anymore. The only thing a vendor can do is to actively help letting the user make choices of his own and to eagerly help with Linux support. This means: a clean and working BIOS or UEFI implementation, which is commited clearly to supporting Linux from the firmware side, and not the other way around. (And there is nothing wrong with supporting Windows as well!)

The hardware and the firmware of a Linux computer

So what does this mean? It means that the firmware (like the BIOS or UEFI) has to be suitable for Linux so that Linux must not use workarounds, so called “quirks” which in their quantity bloat the kernel already. A firmware designed for Linux – that’s real Linux support.

Another support could be to provide firmware blobs for embedded devices inside a special firmware area for the Linux kernel to grab and use. This situation is less a long-term target than it is here-and-now necessity.
The Linux kernel would have to be patched so that support for such a – please: standardised! – “firmware blob interface” would be present, but then this could be used for all Linux firmware implementations from various computer vendors.

The long-term goal is to use hardware that does not require blobs at all. This is the hardest part, as it requires vendors to stand up for open devices. If, for example, a WiFi chip is used, then the computer vendor has to get the WiFi chip vendor to help develop an open source Linux driver that does not require a firmware blob at all. Open specifications would be one way to do this, but most chip vendors say they cannot release this information due to intellectual property and due to their industrial secrets they want to keep. It’s a dilemma.
Even more so, the CPU itself has firmware blob issues, like the Librem Laptop project found out the hard way.

So there are two ways to go:

  1. either try to go fully open source,
  2. or make the best of it and help as much as you can.

Trying to be fully open source

As of 2014, I see lots of small hacking & development devices fully open sourced, and only one laptop-to-be:

  1. the Novena is a low-end laptop-to-be
  2. lots of Rasperry-Pi-like open source hardware
  3. the AMD Gizmo is also intended for developers

Making the best of the firmware blob situation

Most Linux-pre-loaded laptops are basically “designed for Windows” machines that come with Ubuntu:

  1. Dell, HP, ASUS, to name just a few vendors selling lower-end linux laptops and netbooks
  2. the Librem 15 is an exception, as it tries to be higher-end, but it is still a laptop-to-be…

The only problem with how it is now is that support ends with the pre-installed linux. Maybe a driver support site lets you download some linux drivers, but often they will not work well on other distros. And these vendors don’t let the Linux community provide help. And: where are the high-end Linux computers?!?

A new über-firmware approach?

I have an idea. It actually isn’t new, but it transforms the idea of choice towards operating systems.

First, you all know, or have at least heard of, that Microsoft was sued in Europe and finally forced to provide a choice of which internet browser to use on Windows – and this freedom of choice had to be presented highly visible to the user: the Browser Choice.

So, how would you like to get an “operating system choice”? The idea is as follows:

  1. Use an open firmware, like coreboot (wiki)
  2. Include a module (payload) that is some kind of Mini OS
    • read-only
    • Internet access
    • choice of operating system
    • partition management (like gparted)
    • include a special service partition (noexec!), where
      • you can download drivers and manuals to
      • and save configuartion backup on
  3. This Mini OS could let you chooce which OS you would like to use, including commercial operating systems – yes, even Microsoft Windows.

Even more, this firmware should be able to provide a safe pre-initialization environment that prevents malware from being loaded from hard disk drives or other sources, to provide a safe environment for firmware updates.

  1. TWO firmware chips:
    1. read-only firmware ROM chip on a socket: a factory-default hence safe firmware and Mini OS
    2. a flashable – updateable – firmware flash chip with updated firmware blobs (microcode, AGESA update, blobs for various chips), an updated coreboot firmware and an updated Mini OS
  2. the flashable i.e. second firmware chip should be jumper-securable to read-only setting as well. This should cover for malware infection prevention.
  3. each and every embedded chip must be read-only as well, making it only possible to modify by the firmware provided updated
    1. this too provides durable malware protection, as no malware is then able to hide deep in the system – if such a system gets infected, all that is needed it to reset the firmware completely using the factory-default image from the first read-only firmware ROM chip
    2. since both firmware chips riside on a socket, they can even be updated in terms of storage capacity and, for the ROM chip, in firmware version

UTOPIA

I know this idea is kind of idialistic. But hey, all innovations started with some kind of far-fetched vision, right?

In my opinion, an open source computer can only start by using an open source firmware of some kind.

And a Linux computer can only be about choice. Because Linux is about choice. That said, only the program that runs before the actual Linux distribution can provide such a choice to the user. That would be the firmware then: an über-firmware, that asks the user which distribution – which operating system – (s)he wants to install and use. And it should provide means to assist with this installation, like by conveniently providing the required drivers and firmware blobs.

 Virtualization

Even more far-fetched: such an über-firmware could also act as a hypervisor for multi-boot installations. Just imagine: in the firmware you decide which resources an operating system gets, the firmware provides the virtualized environment for the OS and then allows you to boot that operating system. As a hypervisor it would theoretically also be possible to stop that OS, save its state, switch to an other OS, or even let the OS continue to run in the background and finish its job while the user works with one the other OSes.

A Linux vision

As long as Linux computers try to copy pre-installations as we see them from Microsoft Windows they lack a unique Linux vision. There is no Linux way nor a real open source way perceptible.

Linux users deserve better. They deserve better computers than low-end models with pre-installed Ubuntu.

Linux vendors ought to do better. They should work with the open source community, build on already existing software technologies (like coreboot) and envision how to enhance the Linux experience for every user: even if the user installs and uses only one distro. It is worth the effort, since other Linux users will discover the potential, they will help to develop and enhance the implementations, they will help build a community around it. They will spent hours providing drivers/firmware for their favorite distro, help other users in forums, write wiki pages, translate documentations, contribute code – they will even build KVM and Docker images if you let them!

Dear computer makers! Be visionary! And trust in the community – work with them!

Unleash the power of Linux: the freedom of choice!

5 KDE-Funktionen, die ich auf einem Desktop vermissen würde

5 Dinge, die ich auf meinem Desktopbetriebssystem nicht mehr missen möchte – und die ich auf dem K Desktop Environment (KDE) sofort gerne genutzt habe!

1. Markierter Text Kopieren&Einfügen mit Mittelklick

Durch das Markieren von Text wird eine Art zweite Zwischenablage befüllt, deren Inhalt sich mit dem Mittelklick auf das Mausrad (Maustaste 3) einfügen lässt. Benutzt man zuvor bei einer Markierung die normale Kopieren&Einfügen-Funktion mit Strg+C, dann hat man anschließend zwei Einfüge-Vorgänge „frei“, ohne auf das vorige Fenster zurück zu müssen.

Ich liebe das. Außerdem ist für einfaches Copy&Paste kein Ctrl+C mehr nötig, weil ein Markieren + Mittelklick reicht. Viel schneller, viel einfacher.

Leider führt das auch oft dazu, dass ich unter Windows einen zweiten Versuch brauche, weil der Mittelklick in ein leeres Textfeld nicht den zuvor markierten Text einfügt, sondern entweder keine Funktion, oder aber eine andere Funktion auslöst. Ärgerlich.

2. Klipper

Klipper erweitert die Zwischenablage ins unendliche. Damit kann man zuvor zuvor zuvor zuvor markierten Text nochmals einfügen. Klipper funktioniert sowohl mit Strg+C als auch mit einfachem Markieren von Text (der oben schon erwähnten Funktion).

Sicherheitswarnung: alles, was mit der Maus markiert wird, landet auch in Klipper. Wenn du wissen willst, was ich so mache auf meinem Computer, sieh mal in der Zwischenablage nach…
Lösung des Problems: ab und an mal die Zwischenablage löschen. Das kann man auch automatisch mit jedem Neustart machen lassen („Inhalt der Zwischenablage beim Verlassen speichern“ deaktivieren).

3. Eingabefukus folgt Mauszeiger

Fast am meisten vermisse ich unter Windows und OS X, dass meine Eingabe nicht dort landet, wo sich der Mauszeiger gerade befindet. Der Grund: oft stelle ich ein anderes Fenster über jenes, auf dem die Eingabe erfolgen soll. So kann ich beispielsweise ein Bildfenster (z.B. Paint unter Windows) öffnen, und auf dem dahinter liegenden Textfenster (z.B. Notepad unter Windows) einen Text eintippen, den ich eben von jenem Bild abschreiben will. Liegt der Mauszeiger nun über dem Textfenster, so landen die Tastatureingaben auch auf jenem Fenster, während das Bildfenster jedoch im Vordergrund bleibt (und daher nicht vom Textfenster überdeckt wird).

Ebenso verhällt es sich mit dem Mausrad:

4. Mausradfokus folgt Mauszeiger

Wenn ich das Mausrad zum Scrollen verwende, dann doch wohl dort, wo sich der Mauszeiger gerade befindet. Unter Windows geht mir das dermaßen auf den Geist, dass man jedesmal zuerst Klicken muss, bis das Mausrad etwas bewegt. Vorallem im Explorer, wo man einmal auf der Verzeichnisbaumseite, dann aber auf der Detailansicht der Verzeichnisinhaltsseite scrollen möchte, nervt das sehr und hält auf.

5. Kürzel für Suchanfragen im Browser

Im Konqueror kann man zumindest seit KDE 3 einstellen, dass ein „gg:“ gefolgt von einem Suchbegriff eine Google-Suche auslöst. Diverse Suchdienste lassen sich hinzufügen.

Als Beispiel: „gb:“ habe ich mir als Gentoo Bugs eingerichtet. Suche ich nun einen bestimmten Fehlerbericht im Gentoo-Bugtracker, so reicht ein „gb:segfault konqueror“ und schon erscheint die entsprechende Seite.

Unter Windows finde ich mich manchmal bei dem Versuch wieder, beispielsweise „gg:Urlaubstipps Spanien“ eingeben zu wollen, was natürlich nicht zur Google-Suche nach Spanien-Urlaubstipps führt, sondern zu der Fehlermeldung, das „Protokoll gg:“ wäre „nicht bekannt.“

KDE

Diese 5 Funktionen sind unter KDE auf Linux Standard, müssen aber teilweise manuell konfiguriert werden. Das war bei KDE 2 bereits so, mit Klipper ist das seit KDE 3 so und auf KDE 4 funktionieren diese Funktionen natürlich ebenfalls. Nur unter KDE 1 waren die meisten dieser Funktionen noch nicht implementiert.

KDE gibt es auch für Windows. Das nennt sich KDE Windows Initiative und lässt sich mit dem Installer sehr einfach auch unter Windows installieren. Ob jedoch all diese Funktionionen auch unter Windows implementiert sind, weiß ich nicht, denn einige davon scheinen mir eher X11-spezifisch zu sein.

Es war auch einmal angedacht, KDE auf OS X zu portieren. Stattdessen gibt es derzeit nur die Möglichkeit, einzelne KDE-Anwendung nativ unter OS X zu nutzen.

6. Dock

Das Einzige, das offensichtlich aus der Mac-Welt stammt, ist das Dock.  Dabei handelt es sich um eine Kombination aus Programmstarter und Taskleiste/Fensterleiste. Das heißt, Programme, die noch nicht gestartet sind, können einfach über das Symbol gestartet werden (Programmstarter). Wenn diese jedoch bereits laufen und ein oder mehrere Fenster offen sind, so übernimmt dasselbe Symbol die Funktion eines Eintrags in einer Taskleiste bzw. Fensterleiste.

Seit KDE 4 gibt es Versuche, ein Dock, wie es von Mac OS X her bekannt ist, funktionell auch unter KDE zu implementieren. Mit KDE 4.8 wurde die „Symbol-Fensterleiste“ hinzugefügt und muss manuell aktiviert werden (als Plasma-Widget auf der Kontrollleiste). Auf Englisch heißt dieses Widget übrigens “Icon-Only Task Manager” und hieß vorher Icon Tasks.

Die Symbol-Fensterleiste funktioniert ganz gut, wenn auch nicht perfekt. Jedenfalls ist sie das einzige, was noch optimiert gehört – ansonsten ist KDE unter Linux wirklich das für meinen Geschmack beste Desktopsystem auf dem Planeten! Und wenn ich Desktop sage, dann meine ich auch Desktop: ich arbeite mit Tastatur und Maus vor einem Monitor. Auf Laptops mit Touchpad (die meist ohne mittlerer Maustaste daherkommen) bzw. ohne Maus sind einige der Funktionen nicht so gut nutzbar.

Und von Touchscreens rede ich erst gar nicht…

Bauvorschlag für eine Steam-Box

Was eine SteamBox ist, weiß hoffentlich jeder. Auf meiner Wohnzimmer-SteamBox soll Windows und/oder Linux laufen. Der Bauvorschlag basiert auf dem c’t-Artikel „Dampfmaschine“ aus c’t Heft 7/2013. Mehr dazu auf der Projektseite c’t Steam Box: Spielkonsole selbst bauen.

Ingredienzen

Damit sollte alles laufen. Zusammenbauen und loslegen.

Begründungen

Das Gehäuse ist das alternative Gehäuse aus dem c’t-Bauvorschlag. Es gefällt mir einfach besser als die erste Wahl des originalen Vorschlags. Nachteil: das Netzteil ist nicht debei.

Das Netzteil im c’t-Bauvorschlag ist ein be quiet! Pure Power L7, aktuell ist anscheinend das Pure Power L8.

Das Mainboard aus dem Bauvorschlag gibt es nicht mehr – zumindest nicht in Österreich. Darum ebenfalls eines von MSI, aber mit A88X-Chipsatz statt mit A75-Chipsatz. Kann hoffentlich nur besser werden. (Fingers crossed!)

Die CPU wurde von der c’t als Steam-CPU empfohlen.

Software

Ich habe ein Windows 7 Home Premium, das ich damit verwenden werde. Der einzige Grund dafür ist, dass ich auf Steam ein paar Spiele habe, die leider noch nicht unter Linux laufen. Allerdings werde ich eine Dual-Boot-Installation mit Debian testing einrichten.

Der Plan ist, Steam im Big-Picture-Modus automatisch mit dem Betriebssystem zu starten.

Status

Dieser Bauvorschlag ist derzeit noch ein Projekt. Die Finanzmittel stehen noch nicht zur Verfügung 😦

2014-11-02