seduction
 Language:
Welcome, Guest. Please login or register.
Did you miss your activation email?
2020/11/30, 12:46:55


Help

Author [EN] [PL] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd  (Read 10710 times)

0 Members and 1 Guest are viewing this topic.

holgerw

  • Guest
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #15 on: 2011/01/13, 10:13:55 »
Hallo Rainer,

Quote
aber wenn ich linux in einer produktivumgebung einsetze, dann mache ich mir doch vorher gedanken darüber, was da auf mich zukommt. eine rolling-release-distribution ist da nach meiner ansicht völlig fehl am platz.


Ja, das sehe ich genau so.

Quote
wenn ich auf unstable setze, darauf software laufen lasse, die ich in meiner firmen-infrastruktur dringend benötige, dann kann ich doch hinterher nicht die distribution dafür verantwortlich machen, wenn etwas nicht mehr funktioniert.


Ja, sofern seitens der Distributoren nicht darauf verwiesen wird, dass ihre Distrie auch sehr gut in solchen Firmen-Strukturen eingesetzt werden kann. Das erweckt nämlich bei reinen Anwenderinnen und Anwendern berechtigte Erwartungshaltungen.

Viele Grüße,
  Holger

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #16 on: 2011/01/13, 10:45:12 »
Es ist Euch aber bewusst, dass mit BKL hin oder her genau eine Zeile Konfiguration gemeint ist. Und diese Zeile wurde ohne Grund anders gesetzt, als es andere Leute machen. Ich definiere das jetzt mal ganz bewusst als politische Entscheidung. die mit rolling release nichts zu tun hat.

Man klammert sich verbohrt an irgendwelche Ideologien, die mit der Realität nichts zu tun haben. Man kann sehr wohl rolling auch produktiv einsetzen. Es macht allerdings deutlich weniger Spass, wenn man aus solchen nichtigen Gründen Kernel selbst bauen muss oder nicht updaten kann.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

ralv

  • Guest
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #17 on: 2011/01/13, 12:47:04 »
nun, dass debian sehr ideologisch vorgeht, dürfte auch schon länger bekannt sein.
einige sehen das als vorteil, einige als nachteil. fakt ist aber, dass man vorher weiß, auf was man sich einlässt. und wenn ich weiß, das eine distribution alle paar tage einen neuen kernel erhält, oder wichtige dinge wie x.org, grub, udev und co. sich ändern, dann setze ich diese distribution nicht ein, um dort für eine firma wichtige services laufen zu lassen.
es beim einsatz einer sich stark verändernden rolling-release dann der distri anzulasten, dass programm xyz sich nicht mehr kompilieren läßt, finde ich halt etwas kurzsichtig.
das argument, das etwas ohne grund anders gesetzt wurde, als es andere machen, kann ich nicht gelten lassen. BKL wird schon seit jahren als etwas angesehen, das man gern wieder loswerden möchte. nun wird es halt konsequent umgesetzt. ich persönlich finde das völlig okay. würden alle nur das tun, was andere auch schon machen, hätten wir einen ziemlichen stillstand in der entwicklung...


gruß aus münster

rainer

Online towo

  • Global Moderator
  • User
  • *****
  • Posts: 2.417
Ich gehe nicht zum Karneval, ich verleihe nur manchmal mein Gesicht.

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #19 on: 2011/01/13, 13:15:23 »
@ralv
BKL ist bei slh deaktiviert. Im Debian experimental ist bkl aktiviert.
{{{
linux-headers-2.6.37-trunk-amd64 (2.6.37-1~experimental.1) wird eingerichtet ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 2.6.37-trunk-amd64
dkms: running auto installation service for kernel 2.6.37-trunk-amd64:
      fglrx (10-12)...done.
linux-headers-2.6.37-trunk-all-amd64 (2.6.37-1~experimental.1) wird eingerichtet ...
}}}
Ich rede hier also nicht von einem debian-Alleingang, sondern von einem Alleingang von Aptosid in persona slh. Nicht mehr und nicht weniger. Übrigens ist im Sid noch der 32-5, der war hier aber nicht wirklich Thema. Der funktioniert.

Ich laste diesen Zustand, wissentlich Optionen abzuschalten, die einen nicht funktionierenden Zustand hinterlassen, nicht der Distribution an, sondern slh. Der Mann ist lange genug im Geschäft, der sollte wissen, was man macht und was besser nicht. Ich weiss nicht wirklich, wer dieses Entscheidung gefällt hat, ich weiss nur, dass die Entfernung des BKL weit fortgeschritten, aber noch nicht abgeschlossen ist. Und dass ist nicht mehr Sid, das ist allenfalls experimental.

Wenn damit geworben wird, dass aptosid kompatibel zu sid wäre und die Pakete aus Sid auch laufen sollen, dann muss das meiner Meinung auch sichergestellt sein. Genau das zielte auch in die Richtung bleeding edge und cutting edge.

Diese Diskussion habe ich hier auch schon durch und ich wahr sehr froh, dass sich aptosid auf dem Pfad cutting edge bewegt.

Wenn ich bleeding haben möchte, dann fahre ich das auch, ohne Rücksicht auf Verluste. Wenn dann was nicht passt, schraube ich solange, bis es wieder passt, wenn ich kann. Ich habe schon vor Wochen keine Probleme mit .37, qt 4.7, Kde 4.6 und einem X 1.9.X gehabt. Das ist dann wirklich frisch aus der Presse. Mit allem dafür und dagegen. Nur damit muss ich nicht täglich arbeiten, da habe ich noch ein Fallback-System, was nicht ganz so aktuell ist. Insgesamt zwar immer noch frischer als Sid, aber was solls.

Ich habe aptosid als Distri nicht gewählt, um damit bleeding edge zu haben, sondern ein in vernünftigem Maẞe aktuelles debian-System. Und da sah und sieht aptosid wesentlich erotischer als eine reines SID aus, was von debian, nun ja, nicht grade als Produktivsystem gefördert wird. Die großen Klopfer, die in den Paketen auf den User zukommen, habe ich schon Wochen vorher in Arch, da kann ich dann immer schonmal anfangen, mich seelisch und moralisch auf den Einschlag in SID vorbereiten. Und natürlich dann auch Obacht walten lassen.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline ralul

  • User
  • Posts: 1.809
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #20 on: 2011/01/13, 14:32:42 »
@agaida, slh nimmt für neue Kernel auch ziemlich ungetestete stable-queue patches. Wollen wir (ich will helfen) allgemein ein "easy" aptosid Repo bei dir einrichten mit dem Ziel/Sinn:

Weniger Kernel upgrades, udev sicher, aptosid Anfänger auf der etwas sichereren Seite ?
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #21 on: 2011/01/13, 15:19:11 »
Halte ich nicht so viel von. Nachdem ich den gestrigen Tag eigentlich nur mit Lesen verbracht habe (Komisch, die meisten Dokumentationen endeten in .py, .c und .h) bin ich mir sicher, dass man da nicht so viel besser machen kann.

Man hat eigentlich 3 Chancen. Man fährt Sid, was meine Hardware nicht so toll findet, slh oder experimental. Experimental ist dann ungefähr das selbe, was slh auch nimmt, allerdings mit ein wenig Zeitverzug und sehr viel träger bei wichtigen Änderungen. Liquorix empfinde ich nicht als die große Alternative für mich. Das war jetzt nur mal ein Schnellschuss, weil ich noch nicht vollkommen auf freie Treiber setzen wollte. Ich hab da halt gern eine Alternative und auch die Möglichkeiten mir diese zu schaffen. So lange es unbedingt sein muss, halte ich das am Leben, aber auch keinen Tag länger.

Die Entwicklung kann nur nach vorne gehen und das Bewahren von obsoleten Kerneln ist da eher kontraproduktiv. Das Repo hat eigentlich die entgegengesetzte Ausrichtung. Da sollen bleeding-Sachen frisch und ungeschminkt direkt aus git oder svn rein ;) Deswegen auch der Hinweis mit dur als Analogie zum aur. Halt alles, was ich brauche, aber nicht bei debian erhalten kann.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline frankqn

  • User
  • Posts: 127
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #22 on: 2011/02/04, 03:06:55 »
Hallo,

besteht denn Aussicht, dass Vmware in aptosid irgendwann mal wieder nutzbar wird, oder sollte man doch lieber auf eine andere Distribution ausweichen?

Online towo

  • Global Moderator
  • User
  • *****
  • Posts: 2.417
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #23 on: 2011/02/04, 07:37:48 »
Quote from: "frankqn"
Hallo,

besteht denn Aussicht, dass Vmware in aptosid irgendwann mal wieder nutzbar wird, oder sollte man doch lieber auf eine andere Distribution ausweichen?

Das wirst Du schon vmware fragen müssen.
Spätestens in 2.6.39 ist BKL auch upstream Geschichte.
Und nochmal zu mitmeißeln, VMWare hat schon immer Probleme mit aktuellen Kerneln. Das liegt daran, daß VMware eben nur bestimmte Distros, respektive Kernel-Versionen supportet.
Ich gehe nicht zum Karneval, ich verleihe nur manchmal mein Gesicht.

Offline AnJo

  • User
  • Posts: 33
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #24 on: 2011/02/04, 08:43:38 »
Quote
besteht denn Aussicht, dass Vmware in aptosid irgendwann mal wieder nutzbar wird, oder sollte man doch lieber auf eine andere Distribution ausweichen?


Guckst Du hier http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=474

Wobei ich die folgende Variante aus dem Debiananwenderhandbuch:

    #Vorher installieren:
    apt-get install fakeroot kernel-package make libncurses5-dev
    ____________________________________________ ________________________
    #Aktuelle Kernel-Sourcen laden und entpacken
    apt-get source linux-image-2.6-aptosid-amd64 (bzw. i.386)
    #Aktuelles Kernel-Image laden
    wget
http://debian.tu-bs.de/project/aptosid/debian/pool/main/l/linux-aptosid-2.6/linux-image-2.6.37-0.slh.14-aptosid-amd64_2.6.37-14_amd64.deb
#und config-Datei daraus extrahieren
ar -x linux-image-2.6.37-0.slh.14-aptosid-amd64_2.6.37-14_amd64.deb
tar xvf data.tar.bz2 ./boot/config-2.6.37-0.slh.14-aptosid-amd64
#extrahierte config-Datei in das Source-Verzeichnis unter .config kopieren
cp ./boot/config-2.6.37-0.slh.14-aptosid-amd64 ./linux-aptosid-2.6-2.6.37/.config
#in das Source-Verzeichnis wechseln und make menuconfig ausführen
cd linux-aptosid-2.6-2.6.37
make menuconfig
#hier: Kernel hacking --> * Big Kernel Lock
#exit mit speichern
#Kernel-image bauen mit:
fakeroot make-kpkg --append-to-version -0.aj.14-aptosid-amd64 --revision 2.6.37-14 --initrd kernel-image
#Kernel-headers bauen mit
fakeroot make-kpkg --append-to-version -0.aj.14-aptosid-amd64 --revision 2.6.37-14 kernel-headers
[/list]

Das sollte so auch noch für Kernel 2.6.39.. umsetzbar sein.

Und dann läuft Vmware auch wieder fein :-)

Gruß
AnJo

Online towo

  • Global Moderator
  • User
  • *****
  • Posts: 2.417
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #25 on: 2011/02/04, 10:16:36 »
Quote
Das sollte so auch noch für Kernel 2.6.39.. umsetzbar sein.

Nein, wird es nicht, weil BKL in diesem Kernel nicht mehr verfügbar sein wird.
Ich gehe nicht zum Karneval, ich verleihe nur manchmal mein Gesicht.

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #26 on: 2011/02/04, 10:50:11 »
Handaufleg. Ich persönlich glaube nicht, dass der BKL in der .39 aus dem Kernel verschwunden ist. Macht aber nichts. Langsam verstehe ich aber die Aufregung wirklich nicht mehr. Bei mir kommt langsam so eine WZT-Frage auf: WzT ist so schwer daran, so lange die Füsse still zu halten, bis sich das Thema geklärt hat?

Die möglichen Lösungswege sind lang und schmutzig geklärt. Wer unbedingt BKL haben muss, der soll sich einen Kernel mit BKL halten, der gegen das Produkt, was laufen soll, funktioniert. Alternativen zum offiziellen .slh-Kernel sind da. Ich sehe auch keinen Grund, dafür warum das nicht so bleiben sollte.  

Auch wenn ich zum Thema Kernel nicht ganz Towos Meinung bin: Aptosid hängt doch nicht nur an diesem Kernel. Der ist zwar ein Hauptbestandteil von aptosid, aber in meinen Augen auch ein wenig überbewertet. Und wenn man einen Kernelstand mal für einige Zeit einfrieren muss oder eine Alternative benutzt, ist das doch auch kein Problem. Schließlich ist das Linux, da geht so was. Irgendwann werden auch die Hersteller reagieren.

Deswegen aber eine tolle Distribution in die Tonne zu treten, halte ich für ein wenig übertrieben. Vor allem, weil gewisse Hakeleien bei jeder Distri auftreten werden, mal mehr, mal weniger.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline AnJo

  • User
  • Posts: 33
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #27 on: 2011/02/04, 11:23:11 »
Quote
Deswegen aber eine tolle Distribution in die Tonne zu treten, halte ich für ein wenig übertrieben. Vor allem, weil gewisse Hakeleien bei jeder Distri auftreten werden, mal mehr, mal weniger.


Da schließ ich mich mal ganz kräftig an :!:

Gruß
AnJo

Offline frankqn

  • User
  • Posts: 127
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #28 on: 2011/02/05, 17:16:05 »
Quote from: "AnJo"
Guckst Du hier http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=474

Wobei ich die folgende Variante aus dem Debiananwenderhandbuch:

    #Vorher installieren:
    apt-get install fakeroot kernel-package make libncurses5-dev
    ____________________________________________ ________________________
    #Aktuelle Kernel-Sourcen laden und entpacken
    apt-get source linux-image-2.6-aptosid-amd64 (bzw. i.386)
    #Aktuelles Kernel-Image laden
    wget
http://debian.tu-bs.de/project/aptosid/debian/pool/main/l/linux-aptosid-2.6/linux-image-2.6.37-0.slh.14-aptosid-amd64_2.6.37-14_amd64.deb
#und config-Datei daraus extrahieren
ar -x linux-image-2.6.37-0.slh.14-aptosid-amd64_2.6.37-14_amd64.deb
tar xvf data.tar.bz2 ./boot/config-2.6.37-0.slh.14-aptosid-amd64
#extrahierte config-Datei in das Source-Verzeichnis unter .config kopieren
cp ./boot/config-2.6.37-0.slh.14-aptosid-amd64 ./linux-aptosid-2.6-2.6.37/.config
#in das Source-Verzeichnis wechseln und make menuconfig ausführen
cd linux-aptosid-2.6-2.6.37
make menuconfig
#hier: Kernel hacking --> * Big Kernel Lock
#exit mit speichern
#Kernel-image bauen mit:
fakeroot make-kpkg --append-to-version -0.aj.14-aptosid-amd64 --revision 2.6.37-14 --initrd kernel-image
#Kernel-headers bauen mit
fakeroot make-kpkg --append-to-version -0.aj.14-aptosid-amd64 --revision 2.6.37-14 kernel-headers
[/list]

Das sollte so auch noch für Kernel 2.6.39.. umsetzbar sein.

Und dann läuft Vmware auch wieder fein :-)

Gruß
AnJo
Danke, nett gemeint, aber ein- oder zweimal die Woche neue Kernel bauen, dafür muss man erstmal Zeit und Lust haben. Ich halte erstmal meinen letzten 2.6.36er.

Quote from: "towo"
Das wirst Du schon vmware fragen müssen.
Spätestens in 2.6.39 ist BKL auch upstream Geschichte.
Und nochmal zu mitmeißeln, VMWare hat schon immer Probleme mit aktuellen Kerneln. Das liegt daran, daß VMware eben nur bestimmte Distros, respektive Kernel-Versionen supportet.
Ganz so ist das ja nun auch nicht. Bis jetzt ließ sich das immer per Patch regeln. Wenn ich die Diskusionen hier richtig interpretiere, funktioniert Vmware ja nur mit dem 2.6.37er aptosid-Kernel nicht mehr.

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
vbox non-ose und vmwareplayer mit 2.6.36-0.slh.1-aptosid-amd
« Reply #29 on: 2011/02/05, 23:59:51 »
Da hilft auch kein Patch, weil durch den BKL-Schalter einiges an Code schon vor dem Bauen einfach mal nicht mehr mitgebaut wird. Auch wenn es nicht schön ist, es sind ja Alternativen da. Also, was solls. Warum denken alle Leute immer, dass man Kernel so oft wechseln muss, wenn man keine Probleme hat?
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen