Siduction Forum
Siduction Forum => Rollin', rollin', rolling => Topic started by: ralul on 2011/09/19, 11:50:55
-
openSUSE klaut viel bei anderen: Mandrivas Kde Zusätze sind in openSUSE aufgeschlagen (Stack Folders). Und auch Ubuntus Ayatana-Unity. So soll Gnome3 viel besser bedienbar sein mit dem Dock von unityQt-2d, nach der Aussage eines openSUSE Bloggers.
Ganz davon abgesehen machen sie aber bei openSUSE auch Mitentwicklung an der Front: systemd
Ich hatte keine Probleme jetzt auf systemd umzustellen:
http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/465401-systemd-really-pleasure.html
Debian systemd Entwicklung ist ein bisschen hinten dran im Moment, dafür machen sie multiarch ...
-
Naja, ob das in knapp 4 Wochen klappt mit Multiarch:
Development (future) releases Version Code name Release date End of life date
Ubuntu 11.10 Oneiric Ocelot 13 October 2011 April 2013
-
Für unser erstes Release wäre das natürlich sehr nett, aber ich bezweifle, dass das bis Jahresende was wird. vielleicht reichts fürs 2. Release.
greetz
devil
-
openSUSE klaut viel bei anderen: Mandrivas Kde Zusätze sind in openSUSE aufgeschlagen (Stack Folders). Und auch Ubuntus Ayatana-Unity. So soll Gnome3 viel besser bedienbar sein mit dem Dock von unityQt-2d, nach der Aussage eines openSUSE Bloggers.
Ganz davon abgesehen machen sie aber bei openSUSE auch Mitentwicklung an der Front: systemd
Ich hatte keine Probleme jetzt auf systemd umzustellen:
http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/465401-systemd-really-pleasure.html
Debian systemd Entwicklung ist ein bisschen hinten dran im Moment, dafür machen sie multiarch ...
Hallo @ralul,
systemd kannst Du auch schon auf openSUSE11.4 installieren. Aber es ist meines Erachtens noch nicht sehr ausgereift. Ich muss zum Beispiel auf meinem Lenovo TP R500 mit Intelgrafik den KMS helper Poll loslassen, weil sonst kworker nach kurzer Zeit dermaßen viel CPU Power benötigt, dass es das Notebook fast lahm legt. Für Extra Sachen ist unter openSUSE /etc/rc.d/boot.local zuständig.
Unter systemd wird diese Datei jedoch ignoriert und kworker meint es dann rasch wieder gut mit meiner CPU.
Viele Grüße,
Holger
-
Zum Linux-Bootprozess und speziell systemd gabs letztens auf LWN.net einen guten Artikel (http://lwn.net/SubscriberLink/458789/3ae00c9827889929/)
greetz
devil
-
Sagt einmal Ihr Suse Kenner: Ist denn nun Gnome3 in Suse oder nicht ?
Ich habe mir den Suse Gnome heruntergeladen aber das ist immer noch ein 2er Gnome. :?
Ich bin eigentlich ganz zufrieden mit Fedora 15 aber leider gibt es da keine mspgcc-uniarch Pakete und das Selbstkompillieren kriege ich nicht gebacken. Für die Suse soll es Pakete geben und eben auch Gnome 3.
Grüße,
Stephan
-
@Holger, systemd ist von Greg Kroh-Hartmann für openSUSE-11.4-Tumbleweed gerade wieder zurückgezogen, weil die Basis dafür in dem Release noch nicht stimmt.
@devil, danke für den Link
@OppaErich, Gnome3-3.2-Beta1 läuft gut auf openSUSE-factory, aber die ganzen Extensions, die Gnome3 wieder benutzbar machen, sind gefrostet auf Version 3.1.4 und nicht gangbar. Wenn Du Gnome2 siehst, ist das wahrscheinlich der Gnome3-Notmodus. Oder hast Du die Cdrom iso der M5 Milestone Ausgabe, die auch schon wieder 2 Wochen veraltet ist? Oder, Du musst für den neuen Factory Kernel-3.1-rc5 proprietäre Grafiktreiber selbst kompilieren.
Und was ist mspgcc?
-
Steht nicht dran, einfach dem Standard Downloadlink folgend.
openSUSE-11.4-GNOME-LiveCD-i686.iso
mspgcc ist der gcc fuer MSP430 Mikrocontroller als target.
Danke
-
hier für Gnome3-factory (unstable!):
http://download.opensuse.org/factory/iso/
-
Zum Linux-Bootprozess und speziell systemd gabs letztens auf LWN.net einen guten Artikel (http://lwn.net/SubscriberLink/458789/3ae00c9827889929/)
Dorten:
"by just removing LVM and using the volume management features in Btrfs instead."
Tja, wird Zeit LVM auf den Müll zu kippen, wenn Btrfs soweit ist.
Und ich hab doch schon vor einem Jahr gesagt:
"[systemd] ... to standardize the boot process across distributions, getting rid of lots of little differences that do not need to be there."
Andere Zitate dieses Artikels:
"Once upon a time, all Unix systems were multi-seat; he is, he said, just bringing back a feature that was in Unix at the very beginning. One side effect of this work will be the removal of ConsoleKit"
und:
"The Systemd view of the world has not yet won over everybody, but the opposition seems to be fading. Systemd looks like the init system of the future (and more) for a lot of high-profile distributions."
-
I saw this systemd discussion, so, I thought you might be interested in this article.
http://news.opensuse.org/2011/09/20/systemd-is-being-removed-from-tumbleweed/
I've never had a problem with systemd, using it on Fedora 15 desktops. Although the discussion gets quite heated at times on the fedora-devel mailing list.
IMHO, it's still a work in progress.
-
Hello @GoinEasy9,
thanks for your hint. I'll read the article.
@ralul: Die Betonung bei Btrfs liegt doch aber darauf, wenn es fertig ist.
Was heißt das für mich als Nutzer eines Systemes auf dem Desktop?
Es muss ein stabiles fsck für btrfs geben.
Es hat mindestens genauso schnell zu sein, wie ext4.
Was die Geschwindigkeit angeht, habe ich vor einigen Wochen einen ziemlich ernüchternden Kommentar von Alf gelesen.
Viele Grüße,
Holger
-
Holger, nicht so ernst nehmen, lesend ist das Dateisystem sauschnell. Wenn man also auf der Kiste 90% lesend arbeitet, dann ist das voll in Ornung.
Kompression hilft bei mechanischen Platten auch, hat aber für mich keinerlei Relevanz mehr. Meine Hardware komprimiert.
-
Genau, die meisten Zugriffe im normalen Desktop Betrieb sind lesend (*). Diese sind für Btrfs sogar schneller als auf ext4, eben weil Btrfs sein Dateisystem beim Schreiben besser auf Zugriffe vorbereitet als Ext4 und deswegen länger braucht (Vermutung). Btrfs braucht beim Schreiben aber hauptsächlich länger, weil es noch zusätzlich ein Snapshotfeature vorbereitet beim Schreiben: Damit man vorherige Versionen eines Dateibaums wieder hervorholen kann (Snapshot). Wenn in Ext4 ein Snapshotfeature eingebaut würde (es gibt solch einen Zusatz für Ext4 schon), wäre Ext4 auch langsamer beim Schreiben. Außerdem hat Btrfs noch Verwaltungsfeatures, die dem LVM entsprechen sollen ...
PS (*): Ich könnte mir vorstellen, dass man seinen zukünftigen Btrfs-Dateisystem Desktop tunen kann, indem man dann bestimmte schreibende Sachen auf ein einfacheres Dateisystem exportiert (zB nepomuk-strigi auf eine ext4 Patition verlinkt), oder /home sowieso mit ext4 formatiert.
-
Nur so zum Nachdenken: Viele Features von btrfs prädestinieren btrfs für netbooks & co. Wenn ich aber einige nette Features rauslasse, z.B. transparente Kompression, weil das eine dafür vorbereitete Platte macht, was bleibt dann über? Dateiablagen, die im Zugriff über gewichtete binäre Bäume angesprochen werden mögen auch nett sein. Bei der Entwicklung der Technik ist das aber kein Killerfeature mehr für mich. Einer der Nachteile von btrfs, die Fragmentierung fällt zwar mit ssd auch hinten über. Was bleibt ist der overhead beim Einfügen.
Und ganz ehrlich: Man kann einen Turbo an der einen oder aber anderen Stelle zünden. Genügend schnelle Hardware vorausgesetzt, würde ich dann doch ein stabiles Dateisystem vorziehen. Ganz nebenbei wird ja auch ext4 weiterentwickelt.
Wenn ich an die Entwicklungszyklen grade im Bereich Storage denke, dann kann man sich über so was wie btrfs noch mal unterhalten, wenn Reiser kurz vor seiner Entlassung steht. Mal schauen, was eher passiert. Bis dahin bin zumindest ich mit ext4 gar nicht so schlecht versorgt.
-
Du weisst aber schon, dass der Hauptentwickler von Btrfs schon beim Mörder in Lohn und Brot stand? So gesehen ist:
Btrfs = ZFS+Reiser4-Reiser4SemantikFeatures
-
Du weisst aber schon, dass der Hauptentwickler von Btrfs schon beim Mörder in Lohn und Brot stand?
Werden wir jetzt alle Mörder? (the Devil in uns ;) ) .... Auch ein verwirrtes Genie kann gute Ideen haben!!
-
Ich will das nicht alles nicht werten. Die Mitarbeiter von Einstein haben die Relativitätstheorie auch nicht entscheidend verändert. Den menschlichen Apekt mal ausser acht lassend, auch reiserfs wird weiterentwickelt. Ich sehe im Fall butterfs so einige Probleme:
Redhat beauftragte im Q2/2010 Edward Shishkin, einen der ursprünglichen Reiser4 Entwickler, mit einem Codereview. Shishkins Schluss war, dass das Design fehlerhaft ist, da dem ursprünglichen Algorithmus in Kernpunkten nicht gefolgt wird. Die Designfehler führen dazu, dass in speziellen Fällen der Plattenplatz ausgehen kann, obwohl genügend Platz vorhanden ist.[16][17][18]
Eine stabile btrfs-Version (mit dem endgültigen Datenformat - Version 1.0) war ursprünglich für 2008 zur Veröffentlichung vorgesehen, wurde jedoch bisher (Mai 2011) noch nicht veröffentlicht. Nichtsdestoweniger ist die Unterstützung bereits in die Hauptversion des Linux-Kernels aufgenommen (seit Version 2.6.29-rc1). Bei einigen Linux-Distributionen steht das Dateisystem bereits offiziell bei der Installation zur Auswahl.
Quelle Wikipedia
Warten wir einfach ein paar Jahre ab, bis die sich auf ein Datenformat geeinigt haben und die Prozesse im Dateisystem ausgereift sind. Ich weigere mich einfach, mir um unausgegorenen Scheiss Gedanken zu machen. Vielleicht liegt es am Alter - ich lebe hier und heute. Hier und heute werde ich den Teufel tun und auf halbfertige Dateisysteme setzten. Das sehe ich genauso wie bei Pizza, die esse ich auch nicht ungebacken.
-
In dem Streit letztes Jahr ging es nicht um das Datenformat, sondern um den Algorithmus den freien Plattenplatz zu verteilen: Shishkin kritisierte, dass das nicht rein nach Dogmen der BalancedTrees-Informatiker-Idee implementiert ist. Chris Mason, der Btrfs vebockt, argumentierte, dass es in praktischen Anwendungsfällen in einem CopyOnWrite System gerechtfertigt ist, in Spezialfällen abzuweichen um Geschwindigkeit beim Schreiben rauszulocken.
Ich hatte vor einem Jahr den Eindruck, dass Shishkin wohl ein wenig pedantisch und eifersüchtig hier kritisiert, weil er im Gegensatz zu seinem früheren Kollegen nicht so einen guten Job gefunden hat.
Allerdings hört man heute, dass wohl das eintritt, was Shishkin vor einem Jahr in seiner Kritik vorausgesagt hat, Probleme mit fast vollen Platten:
Hi Jeff,
The day after the openSUSE conference, Jos showed me his laptop and a
problem with it under the most recent Tumbleweed kernel (and older
kernels as well.)
He is copying a very large (3Gb) file to his btrfs partition from a USB
external drive (running ext3) such that if it succeeds, the partition
will almost be full (only a few Mb left). This should be fine, but it
almost kills the system, slowing responsiveness down to nothing being
possible to do at all on the box until the copy completes 15+ minutes
later. It is possible to eventually interrupt the copy, and when that
happens, the system returns back to life.
Copying the other way (from the btrfs partition to the USB disk), works
absolutly fine, so it doesn't seem like the system is hurting from
memory pressure on anything else.
Is this a currently-known issue on btrfs when the filesystem is almost
out of space and it just takes forever to find empty blocks in which to
put things, or is it something that we should log in a bugzilla entry
and try to get resolved?
thanks,
greg k-h
-
Krümelkackerei zahlt sich an einigen wenigen Stellen im System durchaus aus. Das Dateisystem sollte nicht nach dem Prinzip: Shure it destroys your data, but look how fast it is. aufgebaut sein. Das hatten wir vor knapp 30-40 Jahren schon mal. Es hat sich gezeigt das Optimismus nicht unbedingt der beste Weg für verantwortungsvollen Umgang mit Daten ist.
Das nehme ich mal als so gegeben hin und denke nochmal daran, wie lange es gedauert hat, bis ext4 als sicher in den Köpfen angekommen war. Von daher sollen die Jungens bei Fedora und Ubuntu den Feldtest machen. Wenn das dann so 2 Jahre ohne nennenswerte Probleme läuft, dann darf man mir das vorschlagen. Bis dahin sollen deren Daten dran glauben, das tangiert mich dann eher peripher. Und bis dahin hilft moderne Technik, die eventuell nicht so schnellen, aber sicheren Algorithmen zu beschleunigen.
-
Home würde ich auch noch nicht Btrfs machen. Aber ein schnell ersetzbares Betriebsystem:
siduction-advanced: mit 30GiB, was nicht überlaufen kann, würde micht reizen, mit Snapshotfunktion!
Feldtest kann man allerdings auch freiwillig mit openSUSE-12.1 machen ...