Wie alle wissen sollten hat Canonical mit Version 18.04 den Unity Desktop mit Gnome Shell Desktop, und den Login Manager LightDM mit GDM3 ersetzt.

Ich bin kein Freund vom GDM3. Es haftet noch immer der Charme vom uralten GDM an. Die Konfigurationsmöglichkeiten finde ich beschränkt und am allerschlimmsten:
GDM ist häßlich. So abscheulich, dass es einem peinlich ist seinen Linux Laptop neben einen Windows PC oder Macbook zu stellen.

Sooooooo hässlich!

Tim Wahrendorff über gdm3

Was ist passiert? Ich schätze dem Ubuntu Team war nach technologischer und personeller Reduktion der letzten Jahre eine Anpassung an alte Ansprüche einfach zu viel.

Schritt Eins: LightDM und Abhängigkeiten installieren:

sudo apt-get install slick-greeter lightdm

So einfach.

Schritt Zwei: LightDM als Login Manager konfigurieren:

sudo dpkg-reconfigure gdm3

Aktuell ist gdm3 der Loginmanager. Nach Eingabe des Befehls erscheint eine Abfrage welcher Loginmanager aktiv sein soll. Man wählt hier lightdm mit den Pfeiltasten und bestätigt mit Enter.

Schritt Drei: LightDM konfigurieren:

LightDM ist nun installiert. Wir können uns abmelden und sehen LightDM als unseren neuen Loginmanager mit dem Standard Ubuntu Hintergrund, Rasterpunkten und ubuntu Logo. Fast so schlimm wie gdm3, aber schon etwas besser.

Wir müssen das Teil konfigurieren:

sudo gedit /usr/share/glib-2.0/schemas/10_unity_greeter_background.gschema.override

Der Befehl erstellt eine leere Konfigurationsdatei für glib, die später noch kompiliert werden muss. Automatismen aus den älteren Ubuntu Versionen sind allesamt nicht mehr vorhanden. Selbst das Paket lightdm-settings ist nicht mehr in der Lage Änderungen an der Konfiguration vor zu nehmen.

Alle Konfigurations Schlüssel für lightdm (bzw. dem unity-greeter) kann man sich mit folgendem Befehl ausgeben lass

There have been some frustration upon AMD/ATI's current decision to drop proprietary driver development, in favor for open source driver development.

Not the decision per se, but the outcome for some ATI users is frustrating: Many older, but not to old, Graphic-Cards do not work anymore, due to normal updates, on supported version.

So, what is the deal here?

The deal here is AMD/ATI completly dropping development of the old driver and Linux development going forward. The now old AMD/ATI drivers need xorg 1.16 to function properly, but at some time mid 2017 Canonical decided to update even ubuntu 14.04's xorg to 1.18 and all the old drivers broke. Leaving users with slightly older cards with xorg config or even black screen on startup, without a warning beforehand.

Let's focus on the solution.

The solution is to downgrade xorg and respective packages and dependencies to a version where the proprietary AMD/ATI driver was working, with this command:

sudo apt-get install xserver-xorg-lts-utopic libqt5gui5 libgles1-mesa-lts-utopic libgles2-mesa-lts-utopic libgl1-mesa-glx-lts-utopic libgl1-mesa-glx-lts-utopic:i386 libglapi-mesa-lts-utopic:i386 libegl1-mesa-drivers-lts-utopic

(source: Askubuntu)

Ok, you might notice you "downgrade" 14.04LTS with packages from "utopic", which is the 14.10 (non-lts) version of ubuntu. I am also confused about this. Please do not ask. I am not sure what this is about, if you know, please leave a comment below.

At least at the "Problem Machine", an Asus Laptop with Radeon 6850M Card, this enabled me to activate the drivers from the "Additional Drivers"-Menu and everything (Minecraft in particular) was running fine again afterwards. You could also install these drivers from the command line, like this:

sudo apt-get install fglrx-updates

Have fun. May the code be with you.

Neues Eclipse braucht frisches Logo für den Launcher. Etwas unsauber, aber dafür frei verfügbar.

hier die GIMP xcf Datei zum selber nachbearbeiten.

May the source be with you.

Es gibt Fälle in denen man sein CD/DVD Laufwerk gerne sperren würde. Z.B. wenn man koffeingetränkt am aktuellsten Code verzweifelt und an seinem laptop rumfummelt, oder weil der Nachwuchs die CD Lade gerne zum Henkelgriff umfunktioniert, wenn man nicht hinschaut.

Bis vor kurzem war das unter Ubuntu mit dem Befehl

eject -i 1

zum sperren bzw.

eject -i 0

zum entsperren möglich, mittlerweil funktioniert das eject tool aber nicht mehr.

Schuld ist eine Änderung in den udev Regeln die bewirkt, das der Nutzer keine Kontrolle mehr über sein Laufwerk hat. Um wieder die Kontrolle über das Laufwerk zu bekommen muss in der Datei

/lib/udev/rules.d/60-cdrom_id.rules

folgende Regel kommentiert werden:

ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $tempnode", GOTO="cdrom_end"

folglich sieht die Zeile nach dem kommentieren so aus:

#ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $tempnode", GOTO="cdrom_end"

Nach dem speichern der Änderung muss noch udev neu gestartet werden:

sudo service udev restart

Jetzt kann wieder eject genutzt werden um die CD/DVD Lade zu sperren und zu entsperren.

[update 04.07.2012]

Getestet mit: Ubuntu 12.04LTS

Vor den Schritten ist sicherzustellen, dass:

• Openjdk bereits installiert ist,
• Tomcat im eigenen Home Verzeichnis bereit liegt.
• Tomcat für die Verwendung von APR konfiguriert ist.
• Das Paket build-essential installiert ist.

1. APR herunterladen und installieren:

• Unter http://apr.apache.org/download.cgi den aktuellen APR Source Code herunterladen.
• Heruntergeladenes Paket entpacken.
• Im entpackten Ordner (bspw: apr-1.4.6) folgendes Befehl ausführen:

./configure && sudo make && sudo make install

Bei einer Ausgabe ähnlich:

Libraries have been installed in:
   /usr/local/apr/lib

war der build erfolgreich.

2. Tomcat native builden

• Im Tomcat Verzeichnis im Ordner bin das Paket tomcat-native-x.x.xx.tar.gz entpacken.
• Wechseln in die neu entpackte Ordnerstruktur: ./tomcat-native-x.x.xx-src/jni/native/
• Folgenden Befehl ausführen (evtl. ist der Pfad zur Java Version an zu passen, hier wird eine 64 bit Version genutzt!!):

./configure --with-apr=/usr/local/apr/bin/apr-1-config --with-java-home=/usr/lib/jvm/java-6-openjdk-amd64 && sudo make && sudo make install

3. Neue Libraries kopieren

• Libraries mit folgendem Befehl in die Systemlibraries verschieben (damit sie vom Tomcat gefunden werden):

sudo cp -r /usr/local/apr/lib/* /usr/lib/

Beim nächsten Tomcat Start sollten die APR gefunden werden. Wenn irgendwas nciht stimmt, teilt einem Tomcat dies sehr genau mit.

Server.xml:

die Server.xml Datei des Tomcats sollte den Connector für den SSL Port konfiguriert haben. Ein APR Connector für Port 8443 kann so aussehen:

<connector acceptcount="100" disableuploadtimeout="true" enablelookups="false" maxhttpheadersize="8192" maxthreads="150" port="8443" scheme="https" secure="true" sslcertificatefile="${catalina.base}/conf/server.cert" sslcertificatek