Ubuntu 16.04 LTS und Abwandlungen ab dem 21.4.2016 verfügbar.

eratte

Redaktion
☆☆☆☆☆☆
Mitglied seit
11.11.2001
Beiträge
21.752
Renomée
2.777
Standort
Rheinberg / NRW
  • BOINC Pentathlon 2012
  • BOINC Pentathlon 2013
  • BOINC Pentathlon 2014
  • BOINC Pentathlon 2015
  • BOINC Pentathlon 2016
  • BOINC Pentathlon 2017
  • BOINC Pentathlon 2020
  • SETI@Home Intel-Race II
  • BOINC Pentathlon 2021
Genaueres dann im Laufe des Tages wenn es verfügbar ist.

Spannende Sachen sind der eingestellte AMD fglrx support und man noch OpenCL nutzen kann und ZFS Unterstützung.

Release notes:
release notes for Ubuntu 16.04 LTS (Xenial Xerus) (ubuntu.com)

Downloads:
Ubuntu 16.04 (Xenial Xerus) Image Download (ubuntu.com)
Kubuntu 16.04 Image Download (ubuntu.com)
Lubuntu 16.04 (Xenial Xerus) Image Download (ubuntu.com)
Ubuntu MATE 16.04 (Xenial Xerus) Image Download (ubuntu.com)
Xubuntu 16.04 (Xenial Xerus) Image Download (ubuntu.com)
Ubuntu GNOME 16.04 (Xenial Xerus) Image Download (ubuntu.com)

Desktop image

The desktop image allows you to try Ubuntu without changing your computer at all, and at your option to install it permanently later. This type of image is what most people will want to use. You will need at least 384MiB of RAM to install from this image.

There are two images available, each for a different type of computer:

64-bit PC (AMD64) desktop image
Choose this to take full advantage of computers based on the AMD64 or EM64T architecture (e.g., Athlon64, Opteron, EM64T Xeon, Core 2). If you have a non-64-bit processor made by AMD, or if you need full support for 32-bit code, use the i386 images instead.
32-bit PC (i386) desktop image
For almost all PCs. This includes most machines with Intel/AMD/etc type processors and almost all computers that run Microsoft Windows, as well as newer Apple Macintosh systems based on Intel processors. Choose this if you are at all unsure.

Server install image

The server install image allows you to install Ubuntu permanently on a computer for use as a server. It will not install a graphical user interface.

There are two images available, each for a different type of computer:

64-bit PC (AMD64) server install image
Choose this to take full advantage of computers based on the AMD64 or EM64T architecture (e.g., Athlon64, Opteron, EM64T Xeon, Core 2). If you have a non-64-bit processor made by AMD, or if you need full support for 32-bit code, use the i386 images instead.
32-bit PC (i386) server install image
For almost all PCs. This includes most machines with Intel/AMD/etc type processors and almost all computers that run Microsoft Windows, as well as newer Apple Macintosh systems based on Intel processors. Choose this if you are at all unsure.

A full list of available files, including BitTorrent files, can be found below.

If you need help burning these images to disk, see the Image Burning Guide or the USB Image Writing Guide.

Von 14.04 und 15.10 aus updaten:
Wer sein Ubuntu 14.04 oder 15.10 für Boinc und crunchen per fglrx/OpenCL nutzt sollte erst mal nicht upgraden:

Upgrading from Ubuntu 14.04 LTS or 15.10

To upgrade on a desktop system:

Open the "Software & Updates" Setting in System Settings.
Select the 3rd Tab called "Updates".
Set the "Notify me of a new Ubuntu version" dropdown menu to "For any new version" if you are using 15.10, set it to "long-term support versions" if you are using 14.04 LTS.
Press Alt+F2 and type in "update-manager" (without the quotes) into the command box.
Software Updater should open up and tell you: New distribution release '16.04 LTS' is available.
Click Upgrade and follow the on-screen instructions.

To upgrade on a server system:

Install the update-manager-core package if it is not already installed.
Make sure the /etc/update-manager/release-upgrades is set to normal if you are using 15.10, lts if you are using 14.04 LTS.

Launch the upgrade tool with the command sudo do-release-upgrade.
Follow the on-screen instructions.

Note that the server upgrade will use GNU screen and automatically re-attach in case of dropped connection problems.

There are no offline upgrade options for Ubuntu Desktop and Ubuntu Server. Please ensure you have network connectivity to one of the official mirrors or to a locally accessible mirror and follow the instructions above.

Zum fglrx:

Graphics and Display

fglrx

The fglrx driver is now deprecated in 16.04, and we recommend its open source alternatives (radeon and amdgpu). AMD put a lot of work into the drivers, and we backported kernel code from Linux 4.5 to provide a better experience.

When upgrading to Ubuntu 16.04 from a previous release, both the fglrx driver and the xorg.conf will be removed, so that the system is set to use either the amdgpu driver or the radeon driver (depending on the available hardware).

More information is available here https://tjaalton.wordpress.com/2016/03/11/no-catalystfglrx-video-driver-in-ubuntu-16-04/

In dem Artikel unter "More Information" findet sich folgender Hinweis:

users relying on pro/workstation class features (latest OpenGL, OpenCL, ..) probably should stay on a supported release until the hybrid stack is available

Artikel zu Ubuntu 16.04 LTS etc. :

Linux: Ubuntu 16.04 LTS Xenial Xerus mit Snap und ZFS (Computerbase)
Linux-Distribution Ubuntu 16.04 LTS freigegeben (heise)
Xenial Xerus: Ubuntu will weiter mit Alleingängen punkten (golem)
Linux: Die Neuerungen der Ubuntu-16.04-Derivate (Computerbase)
Snap: Ubuntus neues Paketformat ist unter X11 unsicher (golem)
Ubuntu LTS: Lauter Sicherheitslücken trotz Langzeitpflege (heise)
 
Zuletzt bearbeitet:
Hat jemand Erfahrungen mit dem Stromsparsupport der freien Treiber? Habe die Beta 1 per Live-CD getestet und da lag der freie radeon-Treiber bei +12w im Idle und +20w beim Abspielen von Videos (per GPU beschleunigt) gegenüber dem fglrx auf 15.10 (Radeon HD 7850) oder den Windowstreibern. Gab es da bis zum Release noch Verbesserungen? Oder geheime Kernelparameter (ich verrate die garantiert nicht weiter, ich schwör's ;))?

Hat jemand Erfahrungen mit dem Verbrauch der neueren Karten (mit amdgpu) gegenüber fglrx (gab's den überhaupt dafür ???), respektive den Windowstreibern?

Hat jemand was von "Portierungen" der Stromsparfeatures von amdgpu zu radeon gelesen (HD 7xxx Reihe wurde ja irgendwie in den neuen Karten (die unterstützt werden) weiterverwurstet)?

Hatte irgendwo gelesen, dass der fglrx in 16.04.1 zurück kommen soll, ist das über den Haufen geworfen worden?

BTW für Xubuntunutzer (Ubuntu mit XFCE): Der instabile Thunar aus 15.10 ist weiterhin ungepatcht dabei, hier arbeitet man an einer Lösung (da gibts auch ein gepatchtes Binary), hab die selbst aber noch nicht getestet.
 
Ich habe jetzt gerade von snap gelesen- ist Canonical jetzt völlig zu MS verkommen?
Ich hoffe, dass dieser Misthaufen komplett von Debian und Suse abgelehnt wird.
 
Ich habe jetzt gerade von snap gelesen- ist Canonical jetzt völlig zu MS verkommen?
Ich hoffe, dass dieser Misthaufen komplett von Debian und Suse abgelehnt wird.

Ich glaube deine Meinung teilen nicht viele, *buck*

Wenn du deine Software für Linux anbieten möchtest, dann darfst du einen Haufen Pakete erstellen, oder bringst du dann nur für Ubuntu LTS? Nur Debain Stable?
Was ist mit Fedora oder Arch? OpenSuse Leap oder doch Tumbleweed?

Es sagt ja keiner, das Software die stable oder nicht "rapid entwickelt" wird, nicht mehr per Repo kommt. Aber für einige Sachen macht es schon Sinn.
Es gab mal eine recht große Diskussion um Debian und OwnCloud. Kannste dir vll ja denken, Debain verteile Munter - im stable Branch - eine uralt OwnCloud-Version. Die war zwei oder 3 Versionen hinterher. Nicht nur Feature-mäßig hinterher, sondern ungestopfte Sicherhetslücken und teilweite nicht kompatibel mit der aktuellen Version.

Also ich freue mich auf snaps oder flatpak, oder was auch immer sich durchsetzt.
 
Zuletzt bearbeitet:
Ich glaube deine Meinung teilen nicht viele, *buck*

Wenn du deine Software für Linux anbieten möchtest, dann darfst du einen Haufen Pakete erstellen, oder bringst du dann nur für Ubuntu LTS? Nur Debain Stable?
Was ist mit Fedora oder Arch? OpenSuse Leap oder doch Tumbleweed?

Da würde es doch reichen wenn sich die Distributionen auf einen Package Manager einigen würden oder zumindest auf einen gemeinsamen Überbau.
Ich muss doch als Entwickler erst einmal nur mitteilen welche Bibliotheken ich in welcher Version benötige, den Rest muss die Distribution erledigen.

Es sagt ja keiner, das Software die stable oder nicht "rapid entwickelt" wird, nicht mehr per Repo kommt.

Es wäre bestimmt auch nicht sooo schwierig einen wrapper von snap auf deb u.s.w. zu basteln. Problem ist dann ja nur, dass zunächst die snap Datei komplett geladen werden muss um dann nur die "neuen" Binärdaten zu holen, also müsste dann auch irgendwo immer die komplette bloat Datei herumliegen. Gut bei OSS kann man einfach das entsprechende Programm kompilieren, bei closed source hat man immer bloat.

Es gab mal eine recht große Diskussion um Debian und OwnCloud. Kannste dir vll ja denken, Debain verteile Munter - im stable Branch - eine uralt OwnCloud-Version. Die war zwei oder 3 Versionen hinterher. Nicht nur Feature-mäßig hinterher, sondern ungestopfte Sicherhetslücken und teilweite nicht kompatibel mit der aktuellen Version.

Ja, das verstehe ich bei Debian manchmal auch nicht. Eclipse krebst da z.B. auch noch in Version 3.8 herum- in Debian unstable :o
Besonders :o da Eclipse eigentlich keine großartigen Dependencies besitzt.

Also ich freue mich auf snaps oder flatpak, oder was auch immer sich durchsetzt.

Dann lieber flatpack, weil es a) nicht von Canonical ist ;) und b) zumindest diesen runtime Unterbau besitzt.
Aber am liebsten wäre mir halt ein vereinheitlichter Package Manager.
 
Aber am liebsten wäre mir halt ein vereinheitlichter Package Manager.

Wird es nie geben und das ist gut so, denn eine Linux Distribution ist nicht Windows und soll es nicht sein oder werden.

Eine Distribution ist in sich abgestimmt. Daher können Pakete nicht beliebig untereinander ausgetauscht werden, es sei denn sie bringen ihre benötigte Umgebung selbst mit.
Was auch nicht gerade effizient ist.
 
Wird es nie geben und das ist gut so, denn eine Linux Distribution ist nicht Windows und soll es nicht sein oder werden.

Eine Distribution ist in sich abgestimmt. Daher können Pakete nicht beliebig untereinander ausgetauscht werden, es sei denn sie bringen ihre benötigte Umgebung selbst mit.
Was auch nicht gerade effizient ist.

Ich meine auch mehr diesen von mir phantasierten "Überbau"- also die Software bringt in einem speziellen Paketformat die Informationen über ihre Abhängigkeiten mit und der jeweilige Paketmanager muss sich dann darum kümmern.
Dann kann in der jeweiligen Distribution immer noch eine weitere "Umgebung" geschaffen werden falls eine "unstable" Bibliothek benutzt werden muss (die kann dann sogar noch mit anderen Programmen geteilt werden).

Dein Satz ist auch ein bisschen inkonsequent- zuerst sagst du, dass ein gemeinsamer "echter" Paketmanager nicht gut sei weil es dann wie Windows wäre, andererseits wenn Pakete ihre eigene Umgebung mitbringen nennst du es nur nicht so effizient*buck*
 
Da ist gar nichts wiedersprüchlich dran.
Es geht darum wenn jedes Paket seine zb. eigenen X-Libraries mitbringen würde ein und die gleiche Lib x-mal am System herumgammeln würde.
Eventuell sogar mit dem X-Server inkompatibel.
Das meinte ich mit ineffizient.
 
Das habe ich schon verstanden, aber warum stufst du das nicht auch so herunter wie den gemeinsamen Paketmanager, der "wie Windows" sei?
Das ist doch sogar noch schlimmer?
Flatpack würde ich mit dem MicroSoft Installer vergleichen. Snap ist noch mülliger.
 
Windows Horror ala c++ runtime will wohl niemand.

Ich sehe keinerlei Vorteil eines gemeinsamen Paketmanagers, außerdem gibt es ja sowieso alien, das Pakete in verschiedene Arten konvertieren kann.
 
Alien hilft halt nicht automatisch bei unerfüllten Abhängigkeiten.
Der Vorteil eines gemeinsamen Paket-Abhängigkeits-Formats und der Unterstützung aller Distributionen (mit jeweils individuellen Paketmanager-Unterbau) ist halt, dass man jeder Menge bloat und unsicheren Dinosaurierbibliotheken (wie es bei Snap und Flatpack wohl aussehen wird) aus dem Weg gehen kann.
Die Entwickler wären zufrieden weil sie sich nur noch um die Eintragungen der Abhängigkeiten in das Paket-Abhängigkeits-Format, welches von jeder Distro unterstützt würde, kümmern müssten und die Distributoren wären gut dabei weil keiner außer denen selbst ins System spuckt.
 
Ein gemeinsames Paketformat bringt in der Praxis nichts, da die Distributionen zu unterschiedlich sind.
 
Mein Vorschlag wäre doch völlig unabhängig von den Distributionen, die kämen erst danach.
 
Der Inhalt ist das vom Programmierer kompilierte Programm nebst einer Liste mit Abhängigkeiten, die erfüllt sein müssen. Zusammengepackt in einem standardisierten Format. Die Distributionen müssen dann die Abhängigkeiten erfüllen, das Programm irgendwohin kopieren und das Dingen läuft.
 
Widersprüchliche Abhängigkeiten können nicht erfüllt werden.
Das ist die Crux warum das nie funktionieren wird.

Es scheitern schon an Dingen wie, wohin das Binary schreiben. Einmal auf /usr/bin einmal auf /usr/sbin usw. usf.
 
Zuletzt bearbeitet:
Ja, wenn das nicht aus der gleichen Distribution kommt.
 
Dann sehe ich da kein Problem. Dein Beispiel wäre vergleichbar mit z.B. einem Spiel was unbedingt Windows 10 benötigt, du aber nur Windows 7 hast. Da hat man dann halt Pech gehabt. Oder auch nicht- das neue X11 wäre schnell installiert ;)
 
Zurück
Oben Unten