Papierkorb wo im Dateisystem

[Albrecht Mehl]

opensuse 15.2

Entfernt man eine Datei, landet sie im Papierkorb, den man leicht im
Dateimanager dolphin links in der Übersicht findet. Der ist aber so
voll, dass man darin mit kfind suchen möchte. Wo findet man den
Papierkorb in der Ordnerhierarchie?

A. Mehl
--
eBriefe an| mehlBEIiesyPUNKTnet
1 kWh ⩯ 0,5 kg Steinkohle ⩯ 1,5 kg CO2
1 W dauernd 7/24 ≈ 10 kWh/Jahr ⩯ 5 kg Steink./Jahr ⩯ 15 kg CO2/Jahr

[Michael Brand]

Albrecht Mehl wrote:
> opensuse 15.2
>
> Entfernt man eine Datei, landet sie im Papierkorb, den man leicht im
> Dateimanager dolphin links in der Übersicht findet. Der ist aber so
> voll, dass man darin mit kfind suchen möchte. Wo findet man den
> Papierkorb in der Ordnerhierarchie?
>
> A. Mehl
>

Guck doch einfach mal unter den "Eigenschaften" vom Papierkorb nach,
welcher Pfad dort angegeben ist. Ich tippe mal auf ".thrash" in deinem
Heimatverzeichnis.

Michael

[Hermann Riemann]

Am 24.06.21 um 11:55 schrieb Michael Brand:

$HOME/.trash habe ich in SuSE 15.0 nicht gefunden.

Ich würde eine mit touch erzeugte Datei xyz.xyz
in den Papierkorb schieben, und sie dann mit find $HOME xyz.xyz
suchen.

Hermann
vermutend, das Gnome und KDE unterschiedliche Papierkorbordner haben.

--
http://www.hermann-riemann.de

[Michael Brand]

Hermann Riemann wrote:
[...]

> $HOME/.trash habe ich in SuSE 15.0 nicht gefunden.

Hmpfh...Supportende: 3.12.2019.
Benutz' mal was aktuelles.

> Ich würde eine mit touch erzeugte Datei xyz.xyz
> in den Papierkorb schieben, und sie dann mit find $HOME xyz.xyz
> suchen.
>
> Hermann
> vermutend, das Gnome und KDE unterschiedliche Papierkorbordner haben.

Du schreibst ja nicht dabei, welches von beiden du nutzt.

Bei openSUSE/KDE ist es normalerweise $HOME/.trash.

Bei meinem Devuan Beowulf mit KDE liegt er unter
$HOME/.local/share/Trash.

Oder halt, wo immer man den hin haben will.

Michael

[Hermann Riemann]

Am 24.06.21 um 14:06 schrieb Michael Brand:

> Hermann Riemann wrote:
> [...]
>> $HOME/.trash habe ich in SuSE 15.0 nicht gefunden.
>
> Hmpfh...Supportende: 3.12.2019.
> Benutz' mal was aktuelles.

Für SuSE 15.2 war die gekaufte DVD defekt
Debian 10. ist in der Testphase
SuSE 42.3 ist noch auch noch im Betrieb.

>> Ich würde eine mit touch erzeugte Datei xyz.xyz
>> in den Papierkorb schieben, und sie dann mit find $HOME xyz.xyz
>> suchen.
>>
>> Hermann
>> vermutend, das Gnome und KDE unterschiedliche Papierkorbordner haben.
>
> Du schreibst ja nicht dabei, welches von beiden du nutzt.

KDE

> Bei openSUSE/KDE ist es normalerweise $HOME/.trash.

die mit Dophin 16.08.3 in den Papierkorb geschobene Datei xyz.xyz
habe ich mit find / -name "xyz*" 2>/dev/null wiedergefunden.

Hermann
der ab SuSE 11.? nicht mehr
alle SuSE Versionen neu installiert hat.

--
http://www.hermann-riemann.de

[Marc Haber]

Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>Debian 10. ist in der Testphase

Unsinn.

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Hermann Riemann]

Am 24.06.21 um 17:26 schrieb Marc Haber:

> Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>> Debian 10. ist in der Testphase
>
> Unsinn.

Debian 10. ist bei mir in der Testphase


Hermann
der da noch nicht alles, was er braucht,
getestet und ausgebaut hat.

--
http://www.hermann-riemann.de

[Marc Haber]

Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>Am 24.06.21 um 17:26 schrieb Marc Haber:
>> Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>>> Debian 10. ist in der Testphase
>>
>> Unsinn.
>
>Debian 10. ist bei mir in der Testphase

Und das nächsten Monat erscheinende Debian 11 testest Du dann ab 2023?
Da ist ja manches multinationale Unternehmen schneller.

[Hermann Riemann]

Am 24.06.21 um 18:18 schrieb Marc Haber:

>> Debian 10. ist bei mir in der Testphase

> Und das nächsten Monat erscheinende Debian 11 testest Du dann ab 2023?

Nein im Herbst plane ich weiterzumachen.
Dann wäre Debian 11 dran.

Wenn es funktioniert,
wird es dann Debian 9, Suse 14.3 und SuSE 15.0 ersetzen.
SuSE 42.3 und älter wird vermutlich nicht mehr ersetzt.

Bei meinem Haupt PC plane ich zusätzlich
zur SATA SSD eine m2 SSD einzubauen.
Auf der M2 SSD dann debian installieren,
Dann kann ich statt über grub über BIOS das aktuelle OS
auswählen. ( SSD Bootlaufwerk: m2 Debian SATA SuSE )

Neueres Raspi OS ist auch in der Warteschlange.

> Da ist ja manches multinationale Unternehmen schneller.

Auch in Deutschland?

Hermann
der den Betrieb seines Hauptrechenzentrums
http://www.hermann-riemann.de/pic/Arbeitsplatz.jpg
bei hohen Zimmertemperaturen vermeidet.

--
http://www.hermann-riemann.de

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:

> Und das nächsten Monat erscheinende Debian 11 testest Du dann ab 2023?

Oh, nice!

Da ist dann das neue systemd mit drin, was die IPv6-Adressblöcke
weiterverteilen kann, richtig?

Hast Du eine Einschätzung, wie weit die Draft-Release-Notes schon
gediehen sind? Mich juckt es ein wenig, jetzt schon umzustellen und
ggf. noch einen Bugreport beizusteuern.

ZFS und Kernel 5.10 sind ja auf dem gleichen Stand wie die Backports,
das sieht für mich so aus, als ob ich direkt wechseln könnte.

Gruß
Christian

PS: Die neue Website sieht auch gut aus!
--
....Christian.Garbs....................................https://www.cgarbs.de
_o o/ \o_ \ / __ __o |o \__/o | o____ _o o/
__|- |__ __/ \__/o | / | / o\ / \ |
> | > / \ /o\ o| << | << < \

[Ulli Horlacher]

Christian Garbs <mi...@cgarbs.de> wrote:

> > Und das nächsten Monat erscheinende Debian 11 testest Du dann ab 2023?
>

> ZFS und Kernel 5.10 sind ja auf dem gleichen Stand wie die Backports,
> das sieht für mich so aus, als ob ich direkt wechseln könnte.

Heisst das, das kommende Debian hat offiziell ZFS dabei?
Gabs da nicht ein Lizenz-Problem?


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>
>> Und das nächsten Monat erscheinende Debian 11 testest Du dann ab 2023?
>
>Oh, nice!
>
>Da ist dann das neue systemd mit drin, was die IPv6-Adressblöcke
>weiterverteilen kann, richtig?

Richtig.

>Hast Du eine Einschätzung, wie weit die Draft-Release-Notes schon
>gediehen sind? Mich juckt es ein wenig, jetzt schon umzustellen und
>ggf. noch einen Bugreport beizusteuern.

Ich habe den Updateprozess schon auf etlichen Test- und zwei
Livemaschinen erledigt, das scheint reibungslos zu tun. Auf meinem
Router verwende ich einen Eigenbackport des bullseye-systemd-networkd
auf buster, das tut im Wesentlichen reibungslos und ich habe keinen
Grund anzunehmen dass das im Release anders ist. Bugreports beisteuern
dürfte immer helfen, aber gefixt wird nur noch das, was truly
releasekritisch ist, da bist Du mindestens zwei Monate zu spät für
eine so wichtige Kernkomponente des Systems.

Grüße
Marc

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Christian Garbs <mi...@cgarbs.de> wrote:
>> > Und das nächsten Monat erscheinende Debian 11 testest Du dann ab 2023?
>>
>> ZFS und Kernel 5.10 sind ja auf dem gleichen Stand wie die Backports,
>> das sieht für mich so aus, als ob ich direkt wechseln könnte.
>
>Heisst das, das kommende Debian hat offiziell ZFS dabei?

Die Kernelmodul-Sourcen sind in contrib, damit nicht offiziell
"dabei".

Vermutlich hat man das irgendwie so definiert, dass die Sourcen frei
sind und wenn man kein Binary liefert dann ist Debian auch nicht
derjenige, der das GPL-widrige "derived works" herstellt. Aber das ist
jetzt nur meine persönliche Einschätzung.

Grüße
Marc

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >Christian Garbs <mi...@cgarbs.de> wrote:
> >> > Und das nächsten Monat erscheinende Debian 11 testest Du dann ab 2023?
> >>
> >> ZFS und Kernel 5.10 sind ja auf dem gleichen Stand wie die Backports,
> >> das sieht für mich so aus, als ob ich direkt wechseln könnte.
> >
> >Heisst das, das kommende Debian hat offiziell ZFS dabei?
>
> Die Kernelmodul-Sourcen sind in contrib, damit nicht offiziell
> "dabei".

Ok, ich hab mich leider etwas falsch ausgedrueckt.
Ich wollte wissen, ob ZFS ohne externe Paketquellen installierbar ist.
Damit habe ich bei Redhat sehr schlechte Erfahrungen gemacht. Da war nach
security-bedingten Kernel-Update ZFS nicht mehr verfuegbar. Somit waren
die ZFS-Server 2 Wochen lang nicht mehr verfuegbar.

> Vermutlich hat man das irgendwie so definiert, dass die Sourcen frei
> sind und wenn man kein Binary liefert dann ist Debian auch nicht
> derjenige, der das GPL-widrige "derived works" herstellt.

Aehnlich handhabt es wohl auch Ubuntu.
Ich bin nur (positiv) ueberrascht, dass Debian jetzt einen aehnlichen Weg
geht.
Bisher war Ubuntu die einzige Linux-Distribution, die diesen Spagat wagte.

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

>> Heisst das, das kommende Debian hat offiziell ZFS dabei?

> Die Kernelmodul-Sourcen sind in contrib, damit nicht offiziell
> "dabei".

> Vermutlich hat man das irgendwie so definiert, dass die Sourcen frei
> sind und wenn man kein Binary liefert dann ist Debian auch nicht
> derjenige, der das GPL-widrige "derived works" herstellt. Aber das ist
> jetzt nur meine persönliche Einschätzung.

Das war ja schon immer so. Die CDDL an sich ist ja eine Freie Lizenz für
sich selbst, lediglich die entstehenden Binaries sind problematisch.

Das gleiche gilt ja z.B. auch für Exim, wenn man diesen gegen OpenSSL
linkt.

S°

--
Sigmentation fault. Core dumped.

[Sven Hartge]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>> Christian Garbs <mi...@cgarbs.de> wrote:
>>>>> Und das nächsten Monat erscheinende Debian 11 testest Du dann ab 2023?
>>>>
>>>> ZFS und Kernel 5.10 sind ja auf dem gleichen Stand wie die Backports,
>>>> das sieht für mich so aus, als ob ich direkt wechseln könnte.
>>>
>>> Heisst das, das kommende Debian hat offiziell ZFS dabei?
>>
>> Die Kernelmodul-Sourcen sind in contrib, damit nicht offiziell
>> "dabei".

> Ok, ich hab mich leider etwas falsch ausgedrueckt.
> Ich wollte wissen, ob ZFS ohne externe Paketquellen installierbar ist.

Ja nachdem, wen du bei Debian fragst sind "contrib" und "non-free"
extern und nur "main" ist wirklich Debian.

Praktisch gesehen werden aber beide über die Debian-Mirror
bereitgestellt.

>> Vermutlich hat man das irgendwie so definiert, dass die Sourcen frei
>> sind und wenn man kein Binary liefert dann ist Debian auch nicht
>> derjenige, der das GPL-widrige "derived works" herstellt.

> Aehnlich handhabt es wohl auch Ubuntu.
> Ich bin nur (positiv) ueberrascht, dass Debian jetzt einen aehnlichen Weg
> geht.
> Bisher war Ubuntu die einzige Linux-Distribution, die diesen Spagat wagte.

Ubuntu liefert doch die ZFS-Module direkt kompiliert als Binär-Module
aus. *Das* ist problematisch, der Ansicht vieler nach.

Debian selbst stützt sich hier auf DKMS, wodurch die Kompilation ja erst
auf dem End-System passiert und somit viele der potentiellen Probleme umgeht.

[Ulli Horlacher]

Sven Hartge <sh-...@svenhartge.de> wrote:

> > Ich wollte wissen, ob ZFS ohne externe Paketquellen installierbar ist.
>
> Ja nachdem, wen du bei Debian fragst sind "contrib" und "non-free"
> extern und nur "main" ist wirklich Debian.
>
> Praktisch gesehen werden aber beide über die Debian-Mirror
> bereitgestellt.

Mir gehts um die Praxis :-)

> > Aehnlich handhabt es wohl auch Ubuntu.
> > Ich bin nur (positiv) ueberrascht, dass Debian jetzt einen aehnlichen Weg
> > geht.
> > Bisher war Ubuntu die einzige Linux-Distribution, die diesen Spagat wagte.
>
> Ubuntu liefert doch die ZFS-Module direkt kompiliert als Binär-Module
> aus. *Das* ist problematisch, der Ansicht vieler nach.

Achso, ja, stimmt. Das ist lizenztechnisch nochmal deutlich problematischer.

> Debian selbst stützt sich hier auf DKMS, wodurch die Kompilation ja erst
> auf dem End-System passiert und somit viele der potentiellen Probleme umgeht.

Solange die Debian-Maintainer darauf achten, dass das funktoniert, ist das
fuer den Anwendunder wenig problematisch. Ein update dauert halt nur
laenger. Und der Compiler muss installiert sein.

Bei Redhat ging halt genau das schief und fuehrte dazu dass die
ZFS-basierten Server ausfielen - fuer 2 Wochen!

[Ralph Angenendt]

Well, Hermann Riemann <nosp...@hermann-riemann.de> wrote:

> $HOME/.trash habe ich in SuSE 15.0 nicht gefunden.
>
> Ich würde eine mit touch erzeugte Datei xyz.xyz
> in den Papierkorb schieben, und sie dann mit find $HOME xyz.xyz
> suchen.
>
> Hermann
> vermutend, das Gnome und KDE unterschiedliche Papierkorbordner haben.

Genau. Warum nachgucken, wenn man auch vermuten kann.

| For every user² a “home trash” directory MUST be available. Its name and
| location are $XDG_DATA_HOME/Trash³ ; $XDG_DATA_HOME is the base
| directory for user-specific data, as defined in the Desktop Base
| Directory Specification .
|
| ²To be more precise, for every user who can use the trash facility. In
| general, all human users, and possibly some “robotic” ones like ftp,
| should be able to use the trash facility.
|
| ³For case sensitive file systems, note the case.

https://specifications.freedesktop.org/trash-spec/trashspec-1.0.html

Ralph
--
Übervaterlandverräter und Mutterkornblumenblau

[Ralph Angenendt]

Well, Albrecht Mehl <unv...@invalid.invalid> wrote:
> opensuse 15.2
>
> Entfernt man eine Datei, landet sie im Papierkorb, den man leicht im
> Dateimanager dolphin links in der Übersicht findet. Der ist aber so
> voll, dass man darin mit kfind suchen möchte. Wo findet man den
> Papierkorb in der Ordnerhierarchie?

Hier: $XDG_DATA_HOME/Trash

[Bernd Mayer]

Am 24.06.21 um 14:06 schrieb Michael Brand:

> Hermann Riemann wrote:
> [...]
>> $HOME/.trash habe ich in SuSE 15.0 nicht gefunden.
>

> Bei openSUSE/KDE ist es normalerweise $HOME/.trash.
>
> Bei meinem Devuan Beowulf mit KDE liegt er unter
> $HOME/.local/share/Trash.

Hallo,

Man sollte dafür auch im Dateimanager das Anzeigen von versteckten
Dateien aktivieren.


Bernd Mayer

[Hermann Riemann]

Am 25.06.21 um 16:44 schrieb Ralph Angenendt:

> Well, Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>
>> $HOME/.trash habe ich in SuSE 15.0 nicht gefunden.
>>
>> Ich würde eine mit touch erzeugte Datei xyz.xyz
>> in den Papierkorb schieben, und sie dann mit find $HOME xyz.xyz
>> suchen.
>>
>> Hermann
>> vermutend, das Gnome und KDE unterschiedliche Papierkorbordner haben.
>
> Genau. Warum nachgucken, wenn man auch vermuten kann.

Wenn man bereit Gnome oder etwas anders hat,
ist die Methode mit xyz schneller als suchen.

Allerdings ist das korrekte find Kommando

find / -name "xyz*" 2>/dev/null

was in jeder GUI, welches trash verwendet, funktionieren müsste.

Hermann
dessen Bücher nicht alle aktuell sind,
und die Suche mit google aufwendiger wird.

--
http://www.hermann-riemann.de

[Ralph Angenendt]

Well, Hermann Riemann <nosp...@hermann-riemann.de> wrote:
> Am 25.06.21 um 16:44 schrieb Ralph Angenendt:
>> Well, Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>>> Hermann
>>> vermutend, das Gnome und KDE unterschiedliche Papierkorbordner haben.
>>
>> Genau. Warum nachgucken, wenn man auch vermuten kann.
>
> Wenn man bereit Gnome oder etwas anders hat,
> ist die Methode mit xyz schneller als suchen.

Und dadurch findest du raus, ob Gnome und KDE unterschiedliche Ordner
dafür haben?

[Michael Brand]

Hm, meinst du, das könnte eine zu große Hürde für Hermann sein?
Er sollte eigentlich wissen, das Dateien und Verzeichnisse die mit einem
"." anfangen versteckt sind und im Dateimanager nicht ohne weiteres
angezeigt werden.
Ich vermute mal, er vermutet...lassen wir das.

> Bernd Mayer

Michael

[Bernd Mayer]

Am 25.06.21 um 20:09 schrieb Michael Brand:

> Bernd Mayer wrote:
>> Am 24.06.21 um 14:06 schrieb Michael Brand:
>>> Hermann Riemann wrote:
>>> [...]
>>>> $HOME/.trash habe ich in SuSE 15.0 nicht gefunden.
>>>
>>> Bei openSUSE/KDE ist es normalerweise $HOME/.trash.
>>>
>>> Bei meinem Devuan Beowulf mit KDE liegt er unter
>>> $HOME/.local/share/Trash.
>>

>> Man sollte dafür auch im Dateimanager das Anzeigen von versteckten
>> Dateien aktivieren.
>
> Hm, meinst du, das könnte eine zu große Hürde für Hermann sein?
> Er sollte eigentlich wissen, das Dateien und Verzeichnisse die mit einem
> "." anfangen versteckt sind und im Dateimanager nicht ohne weiteres
> angezeigt werden.

Hallo,

er kann ja nicht mal openSUSE richtig schreiben, und wenn eine gekaufte
openSUSE-DVD bei ihm nicht funktioniert, dann ist er ratlos und weiß
nicht weiter.

Außerdem sind ja weitere hier bekannte Anwender von der erfolglosen
Suche nach dem Papierkorb im Dateisystem betroffen.


Bernd Mayer

[Sven Hartge]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> Sven Hartge <sh-...@svenhartge.de> wrote:

>> Debian selbst stützt sich hier auf DKMS, wodurch die Kompilation ja
>> erst auf dem End-System passiert und somit viele der potentiellen
>> Probleme umgeht.

> Solange die Debian-Maintainer darauf achten, dass das funktoniert, ist
> das fuer den Anwendunder wenig problematisch. Ein update dauert halt
> nur laenger. Und der Compiler muss installiert sein.

Probleme mit der Kompilation von ZFS hatte ich eigentlich nur auf den
Systemen, auf denen ich ZFS aus den Backports genommen hatte. Auf
Systemen, bei denen ich das nicht gemacht hatte, gab es diese speziellen
Probleme dann natürlich nicht.

> Bei Redhat ging halt genau das schief und fuehrte dazu dass die
> ZFS-basierten Server ausfielen - fuer 2 Wochen!

Und das führte bei Debian nicht zu einem Ausfall, das Update
funktionierte nicht für einen Moment, aber das bestehende Setup war
davon nicht betroffen.

[Hermann Riemann]

Am 25.06.21 um 19:14 schrieb Ralph Angenendt:

> Well, Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>> Am 25.06.21 um 16:44 schrieb Ralph Angenendt:
>>> Well, Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>>>> Hermann
>>>> vermutend, das Gnome und KDE unterschiedliche Papierkorbordner haben.
>>>
>>> Genau. Warum nachgucken, wenn man auch vermuten kann.
>>
>> Wenn man bereit Gnome oder etwas anders hat,
>> ist die Methode mit xyz schneller als suchen.

> Und dadurch findest du raus, ob Gnome und KDE unterschiedliche Ordner
> dafür haben?

Wenn beide installiert und im betrieb sind,
sollte es sich damit herausfinden lassen.

Es könnte auch bei Papierkorbordner in VMs sein,
deren Ort ich mangels aktiver VMs nicht testen kann.

Hermann
der bei "wo finde ich was"
an "woanders" denkt.

--
http://www.hermann-riemann.de

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Bei Redhat ging halt genau das schief und fuehrte dazu dass die
>ZFS-basierten Server ausfielen - fuer 2 Wochen!

Wenn ich schon wichtig out of tree module verwende, dann würde ich
versuchen, die selbst zu paketieren und als verifiziert
funktionierende Pakete auf die Server zu bringen.

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >Bei Redhat ging halt genau das schief und fuehrte dazu dass die
> >ZFS-basierten Server ausfielen - fuer 2 Wochen!
>
> Wenn ich schon wichtig out of tree module verwende, dann würde ich
> versuchen, die selbst zu paketieren und als verifiziert
> funktionierende Pakete auf die Server zu bringen.

Ging nicht. Der Sourcecode war unter Redhat nicht (mehr) compilierbar.

Ich hab dann Redhat durch Ubuntu ersetzt. Seitdem ist Ruhe :-)

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> >Bei Redhat ging halt genau das schief und fuehrte dazu dass die
>> >ZFS-basierten Server ausfielen - fuer 2 Wochen!
>>
>> Wenn ich schon wichtig out of tree module verwende, dann würde ich
>> versuchen, die selbst zu paketieren und als verifiziert
>> funktionierende Pakete auf die Server zu bringen.
>
>Ging nicht. Der Sourcecode war unter Redhat nicht (mehr) compilierbar.

Und das ist Dir erst in der Produktion aufgefallen?

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >Marc Haber <mh+usene...@zugschl.us> wrote:
> >> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >> >Bei Redhat ging halt genau das schief und fuehrte dazu dass die
> >> >ZFS-basierten Server ausfielen - fuer 2 Wochen!
> >>
> >> Wenn ich schon wichtig out of tree module verwende, dann würde ich
> >> versuchen, die selbst zu paketieren und als verifiziert
> >> funktionierende Pakete auf die Server zu bringen.
> >
> >Ging nicht. Der Sourcecode war unter Redhat nicht (mehr) compilierbar.
>
> Und das ist Dir erst in der Produktion aufgefallen?

Ja. Nach security-bedingten Kernel-update.
Mit dem alten Kernel gings noch, aber das war keine Option. Security geht
vor. Da mach ich keine Kompromisse.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> >Marc Haber <mh+usene...@zugschl.us> wrote:
>> >> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> >> >Bei Redhat ging halt genau das schief und fuehrte dazu dass die
>> >> >ZFS-basierten Server ausfielen - fuer 2 Wochen!
>> >>
>> >> Wenn ich schon wichtig out of tree module verwende, dann würde ich
>> >> versuchen, die selbst zu paketieren und als verifiziert
>> >> funktionierende Pakete auf die Server zu bringen.
>> >
>> >Ging nicht. Der Sourcecode war unter Redhat nicht (mehr) compilierbar.
>>
>> Und das ist Dir erst in der Produktion aufgefallen?
>
>Ja. Nach security-bedingten Kernel-update.
>Mit dem alten Kernel gings noch, aber das war keine Option. Security geht
>vor. Da mach ich keine Kompromisse.

Und genau wegen sowas sollte man halt keine Out-of-Tree-Software
verwenden. Ein Modul-Interface ändert man ja mit einem Security-Update
nicht ohne Not.

Ich verstehe diese Leute nicht, die "wegen des Supports" eine teure
Enterprise-Distribution einsetzen und diese dann außerhalb des
Supports betreiben und dann auch noch rumfluchen wenn was explodiert.

Grüße
Marc

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >Marc Haber <mh+usene...@zugschl.us> wrote:
> >> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >> >Marc Haber <mh+usene...@zugschl.us> wrote:
> >> >> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >> >> >Bei Redhat ging halt genau das schief und fuehrte dazu dass die
> >> >> >ZFS-basierten Server ausfielen - fuer 2 Wochen!
> >> >>
> >> >> Wenn ich schon wichtig out of tree module verwende, dann würde ich
> >> >> versuchen, die selbst zu paketieren und als verifiziert
> >> >> funktionierende Pakete auf die Server zu bringen.
> >> >
> >> >Ging nicht. Der Sourcecode war unter Redhat nicht (mehr) compilierbar.
> >>
> >> Und das ist Dir erst in der Produktion aufgefallen?
> >
> >Ja. Nach security-bedingten Kernel-update.
> >Mit dem alten Kernel gings noch, aber das war keine Option. Security geht
> >vor. Da mach ich keine Kompromisse.
>
> Und genau wegen sowas sollte man halt keine Out-of-Tree-Software
> verwenden.

Deshalb hab ich dann ja zu Ubuntu gewechselt.

> Ich verstehe diese Leute nicht, die "wegen des Supports" eine teure
> Enterprise-Distribution einsetzen und diese dann außerhalb des
> Supports betreiben und dann auch noch rumfluchen wenn was explodiert.

Es war CentOS, Kosten = 0.
Ich habs noch nit Redhat original probiert, aber wie zu erwarten mit
demselben Ergebnis.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Es war CentOS, Kosten = 0.

Dann war's wenigstens nur der Produktionsausfall.

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >Es war CentOS, Kosten = 0.
>
> Dann war's wenigstens nur der Produktionsausfall.

Auch das nicht. Es war ein Testsystem.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> >Es war CentOS, Kosten = 0.
>>
>> Dann war's wenigstens nur der Produktionsausfall.
>
>Auch das nicht. Es war ein Testsystem.

<sb4j9h$dmk$1...@news2.informatik.uni-stuttgart.de> ?

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >Marc Haber <mh+usene...@zugschl.us> wrote:
> >> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >> >Es war CentOS, Kosten = 0.
> >>
> >> Dann war's wenigstens nur der Produktionsausfall.
> >
> >Auch das nicht. Es war ein Testsystem.
>
> <sb4j9h$dmk$1...@news2.informatik.uni-stuttgart.de> ?

!

[Dr Eberhard Lisse]

Auf den Mülleimer rechts-klicken und entleeren.


el

On 24/06/2021 10:03, Albrecht Mehl wrote:
> opensuse 15.2
>
> Entfernt man eine Datei, landet sie im Papierkorb, den man leicht im
> Dateimanager dolphin links in der Übersicht findet. Der ist aber so
> voll, dass man darin mit kfind suchen möchte. Wo findet man den
> Papierkorb in der Ordnerhierarchie?
>

> A. Mehl

--
To email me replace 'nospam' with 'el'