|
|
|
|
|
|
|
| | Zitat von csde_rats
Der Award für die plumpeste FOMO-Werbung geht an... Twitter:
| |
Ich habe das erst Nachschlagen müssen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Das Debian Projektteam hat das Paket für Weboob rausgeworfen wegen dem Projektnamen. Keine Boobies mehr. | |
uff, also wenn ich mir die applications da so anschau dann weiss ich nicht ob der name des projekts eine koinzidenz ist... insofern, ja, netter scherz, aber als gesellschaft sollten wir echt von dem zeugs wegkommen und endlich mal akzeptieren dass es da noch probleme gibt.
|
|
|
|
|
|
|
|
|
|
|
Ich bin infantil genug um natürlich zu lachen. Was für ein dummer Scheiss 
|
|
|
|
|
|
|
|
|
|
|
|
drum ja "netter scherz" kann man machen, was dann aber offiziell wo als projektnamen steht und man automatisch vielen anderen auch aufzwingt (ok weit ausgeholt bei open source software die man sich installieren kann) ist halt ne andere sache.
|
|
|
|
|
|
|
|
|
|
|
|
Ja, machen würde ich das so auch nicht, ne.
|
|
|
|
|
|
|
|
|
|
|
Ich denke, das ist Freiheit. Ich habe meine Linie, bei beleidigenden oder abwertenden Bezeichnungen. Das ist Schluss.
Wenn jedoch einem der Berufsbetroffenen ein Bezeichner im Quellcode nicht gefällt oder der Projektname nicht passt, müssen sie das nicht nutzen. Borg hat einen passenden Namen. Und bei OpenArena hat Debian auch kein Problem mit den halbnackten Figuren. Devilspie hat mir lange gute Dienste erwiesen.
Einer unserer Kunden bestand auf die - festschnallen - SEXI Schnittstelle. Chef immer noch am rotieren. Klar, als Betreiber von einem Pr0nnetzwerk passend, außerhalb eher nicht. Dafür mag mein Chef meine Icons nicht. Wobei die Namensfindung hier auch eher unglücklich ist.
Ich wäre ja dafür diesem Airbustyp wegen der ungewöhnlichen dunklen Cockpitverglasung passende Namen zu geben:
- Räuber Hotzenplotz
- Ronja Räubertochter
- Pippi Langstrumpf
- Robin Hood
- usw.
- Stigs Cousin
- Zorro (keine Ahnung wie ich den übergehen konnte)
Dazu Erklärbärseite im Bordmagazin oder Kurzgeschichten. Und die 747 Flugzeuge alle nach Königinnen Taufe. Aber da bin ich wieder nicht mehrheitskompatibel und wir bleiben bei Namen der Bundesländer und Städte. Alle nicht einprägsam und langweilig 
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 12.11.2020 10:36]
|
|
|
|
|
|
|
|
|
|
Das Flugzeug sieht aus wie The Stigs flying cousin.
|
|
|
|
|
|
|
|
|
|
|
Was?
|
|
|
|
|
|
|
|
|
|
|
The Stig:
The Stigs lorry driving cousin
|
|
|
|
|
|
|
|
|
|
|
Und alle Folgen von Top Gear sollen im Unterhaltungssystem vorhanden sein. Ich habe die Serie ja noch nicht gesehen. Muss ich jetzt nur noch bei der nächsten Hauptversammlung irgendwie als Frage verpacken 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 12.11.2020 10:45]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
und wir bleiben bei Namen der Bundesländer und Städte. Alle nicht einprägsam und langweilig
| |
Die ICEs der DB nach Städten zu benennen halte ich immernoch für einen genialen Schachzug.
Wann wird Tesla verklagt weil die Modelle SEXY heißen?
|
|
|
|
|
|
|
|
|
|
 
Der Musk ist so ein Troll
Und ich dachte Rats hätte mit der Flagge des deutschen Kaiserreiches beim iPhone SE2 das Produktbingo gewonnen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 12.11.2020 15:14]
|
|
|
|
|
|
|
|
|
https://sneak.berlin/20201112/your-computer-isnt-yours/
MacOS gibt - soweit ich es weiß - bisher jeden Anwendungausführung weiter an die Appleserver. Ausnahme, wenn man seine Notarisierung angeheftet hat. Deswegen wollte ich das bei unsere Anwendung hier auch erreichen. Scheint nun mit der neuesten Version endgültig festgenagelt zu sein, MacOS sendet dann immer die Daten weiter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kollege hat mir das hier im Quellcode hinterlassen:
| |
| Code: |
if (!response.result) {
// Hoschi makes some magic with the rubber service
}
|
|
Magie würde ich es jetzt nicht nennen, aber es freut mich sowas vorzufinden.
|
|
|
|
|
|
|
|
|
|
|
Der war einfach nur höflich:
|
|
|
|
|
|
|
|
|
|
|
|
Das muss diese Firma sein, der Datenschutz total wichtig ist, ehrlich!
|
|
|
|
|
|
|
|
|
|
|
Ich komme nicht weiter. Ich nutze Code OSS mit Latex Workshop unter arch linux und kann mit latexmk/lualatex nicht mehr bauen.
latexmk/pdflatex funktioniert ohne Probleme.
Latexmk/lualatex aus der Konsole heraus funktioniert einwandfrei nur integriert im Code OSS (Visual Studio Code) nicht.
Hier das Log vielleicht seht ihr den Fehler. Meine Vermutung war die komische locale-Fehlermeldung.
| |
| Code: |
[15:26:59] Current workspace folders: ["file:///home/jotde/projects/thesis"]
[15:26:59] Current workspaceRootDir: /home/jotde/projects/thesis
[15:26:59] Keep using the same root file: /home/jotde/projects/thesis/thesis_main.tex
[15:27:00] Linter for root file started.
[15:27:00] Linter for root file running command chktex with arguments -wall,-n22,-n30,-e16,-q,-f%f:%l:%c:%d:%k:%n:%m
,/home/jotde/projects/thesis/thesis_main.tex
[15:27:00] Auto build started on saving file: /home/jotde/projects/thesis/kapitel/kapitel_interoperabilitaet/kapitel_interoperabilitaet.tex
[15:27:00] BUILD command invoked.
[15:27:00] The document of the active editor: file:///home/jotde/projects/thesis/kapitel/kapitel_interoperabilitaet/kapitel_interoperabilitaet.tex
[15:27:00] The languageId of the document: latex
[15:27:00] Current workspace folders: ["file:///home/jotde/projects/thesis"]
[15:27:00] Current workspaceRootDir: /home/jotde/projects/thesis
[15:27:00] Keep using the same root file: /home/jotde/projects/thesis/thesis_main.tex
[15:27:00] Building root file: /home/jotde/projects/thesis/thesis_main.tex
[15:27:00] Build root file /home/jotde/projects/thesis/thesis_main.tex
[15:27:00] Linter for root file successfully finished in 0s 62ms
[15:27:00] Linter log parsed with 82 messages.
[15:27:00] Recipe step 1: latexmk, -synctex=1,-shell-escape,-interaction=nonstopmode,-file-line-error,-lualatex,-outdir=build,/home/jotde/projects/thesis/thesis_main
[15:27:00] cwd: /home/jotde/projects/thesis
[15:27:00] LaTeX build process spawned. PID: 27399.
[15:27:01] Recipe returns with error: 12/null. PID: 27399. message: perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "de_DE.UTF-8",
LC_ALL = "de",
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").
Rc files read:
NONE
Latexmk: This is Latexmk, John Collins, 17 Apr. 2020, version: 4.69a.
Rule 'lualatex': The following rules & subrules became out-of-date:
'lualatex'
------------
Run number 1 of rule 'lualatex'
------------
------------
Running 'lualatex -synctex=1 -shell-escape -interaction=nonstopmode -file-line-error -recorder -output-directory="build" "/home/jotde/projects/thesis/thesis_main.tex"'
------------
sh: warning: setlocale: LC_ALL: cannot change locale (de)
Unable to read environment locale: exit now.
Latexmk: fls file doesn't appear to have been made.
Collected error summary (may duplicate other messages):
lualatex: Command for 'lualatex' gave return code 1
Refer to 'build/thesis_main.log' for details
----------------------
This message may duplicate earlier message.
Latexmk: Failure in processing file '/home/jotde/projects/thesis/thesis_main':
(Pdf)LaTeX didn't generate the expected log file 'build/thesis_main.log'
----------------------
Latexmk: Use the -f option to force complete processing,
unless error was exceeding maximum runs, or warnings treated as errors.
.
[15:27:01] The environment variable $PATH: /usr/local/sbin:/usr/local/bin:/usr/bin:/opt/cuda/bin:/opt/cuda/integration/nsight-compute:/opt/cuda/integration/nsight-systems:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/jotde/.local/bin
[15:27:01] The environment variable $SHELL: /usr/bin/zsh
[15:27:01] Cleaning auxiliary files and retrying build after toolchain error.
[15:27:01] File cleaned: /home/jotde/projects/thesis/build/thesis_main.aux
[15:27:01] File cleaned: /home/jotde/projects/thesis/build/thesis_main.fdb_latexmk
[15:27:01] Recipe step 1: latexmk, -synctex=1,-shell-escape,-interaction=nonstopmode,-file-line-error,-lualatex,-outdir=build,/home/jotde/projects/thesis/thesis_main
[15:27:01] cwd: /home/jotde/projects/thesis
[15:27:01] LaTeX build process spawned. PID: 27402.
[15:27:01] File watcher - file changed: /home/jotde/projects/thesis/kapitel/kapitel_interoperabilitaet/kapitel_interoperabilitaet.tex
[15:27:01] Parsing a file and its subfiles: /home/jotde/projects/thesis/kapitel/kapitel_interoperabilitaet/kapitel_interoperabilitaet.tex
[15:27:01] Parse fls file.
[15:27:01] Cannot find fls file: /home/jotde/projects/thesis/kapitel/kapitel_interoperabilitaet/build/kapitel_interoperabilitaet.fls
[15:27:01] Recipe returns with error: 12/null. PID: 27402. message: perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "de_DE.UTF-8",
LC_ALL = "de",
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").
Rc files read:
NONE
Latexmk: This is Latexmk, John Collins, 17 Apr. 2020, version: 4.69a.
Rule 'lualatex': The following rules & subrules became out-of-date:
'lualatex'
------------
Run number 1 of rule 'lualatex'
------------
------------
Running 'lualatex -synctex=1 -shell-escape -interaction=nonstopmode -file-line-error -recorder -output-directory="build" "/home/jotde/projects/thesis/thesis_main.tex"'
------------
sh: warning: setlocale: LC_ALL: cannot change locale (de)
Unable to read environment locale: exit now.
Latexmk: fls file doesn't appear to have been made.
Collected error summary (may duplicate other messages):
lualatex: Command for 'lualatex' gave return code 1
Refer to 'build/thesis_main.log' for details
----------------------
This message may duplicate earlier message.
Latexmk: Failure in processing file '/home/jotde/projects/thesis/thesis_main':
(Pdf)LaTeX didn't generate the expected log file 'build/thesis_main.log'
----------------------
Latexmk: Use the -f option to force complete processing,
unless error was exceeding maximum runs, or warnings treated as errors.
.
[15:27:01] The environment variable $PATH: /usr/local/sbin:/usr/local/bin:/usr/bin:/opt/cuda/bin:/opt/cuda/integration/nsight-compute:/opt/cuda/integration/nsight-systems:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/jotde/.local/bin
[15:27:01] The environment variable $SHELL: /usr/bin/zsh
[15:27:01] File cleaned: /home/jotde/projects/thesis/build/thesis_main.aux
[15:27:01] File cleaned: /home/jotde/projects/thesis/build/thesis_main.fdb_latexmk
|
|
Und hier der Vergleich der locale.
Konsole
| |
| Code: |
➜ thesis git:(master) ✗ locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
|
|
Und hier in Code OSS:
| |
| Code: |
➜ thesis git:(master) ✗ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=de_DE.UTF-8
LC_CTYPE="de"
LC_NUMERIC="de"
LC_TIME="de"
LC_COLLATE="de"
LC_MONETARY="de"
LC_MESSAGES="de"
LC_PAPER="de"
LC_NAME="de"
LC_ADDRESS="de"
LC_TELEPHONE="de"
LC_MEASUREMENT="de"
LC_IDENTIFICATION="de"
LC_ALL=de
|
|
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von DeineOmi am 15.11.2020 15:35]
|
|
|
|
|
|
|
|
|
Ich konnte das gleiche Verhalten in der Konsole reproduzieren indem ich LC_ALL=de zugewiesen habe.
Jetzt ist die Frage wie ich Code OSS beibringe nicht die locale zu ändern/überschreiben?
/e Alle Plugins deaktiviert und das gleiche Verhalten. D:
/e2 Okay hab mir den halben Tag schenken können. 
Ist ein Bug in Electron.
https://github.com/electron/electron/issues/26443
/e3 Falls jemand das gleiche Problem hat hier die Lösung:
Aus dem Cache:
| |
| Code: |
sudo pacman -U /var/cache/pacman/pkg/electron9-9.3.3-1-x86_64.pkg.tar.zst |
|
oder wenn nicht im Cache:
| |
| Code: |
curl -O [URL]https://archive.archlinux.org/packages/e/electron9/electron9-9.3.3-1-x86_64.pkg.tar.zst[/URL]
sudo pacman -U electron9-9.3.3-1-x86_64.pkg.tar.zst |
|
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von DeineOmi am 15.11.2020 17:01]
|
|
|
|
|
|
|
|
SSH
|
Hi. Ich hab hier eine Linux-Kiste, die sich User aus dem Active Directory holt. Ins AD hab ich das Ding per realm join integriert.
Alle User, die ich in die Berechtigungsgruppe dafür gepackt habe können sich problemlos anmelden.
Außer einer. Er wird quasi nach dem Login sofort wieder rausgeworfen und es kommt dies hier:
| |
| Code: |
Welcome to NVIDIA DGX Server Version 4.99.11 (GNU/Linux 5.4.0-48-generic x86_64)
System information as of Thu Nov 12 11:02:19 CET 2020
System load: 0.11 Processes: 891
Usage of /: 1.1% of 489.69GB Users logged in: 3
Memory usage: 0% IP address for docker0: 172.17.0.1
Swap usage: 0%
Last login: Mon Nov 2 12:52:28 2020 from 10.12.130.26
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: chan_shutdown_read (i0 o0 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> closed
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i3 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1)
debug3: send packet: type 1
debug3: fd 1 is not O_NONBLOCK
Connection to gpudingsi.ad.de closed.
Transferred: sent 2268, received 2712 bytes, in 0.7 seconds
Bytes per second: sent 3369.0, received 4028.5
debug1: Exit status 1
|
|
Allerdings hat er es schon mit 2 Accounts getestet und mit OpenSSH und putty.
Die User sind alle jungfräulich und das home wird bei der ersten Anmeldung angelegt. Die .bashrc ist dementsprechend auch einfach der Ubuntu-Default.
Da alle anderen User sich anmelden können scheint es nicht an sshd zu liegen.
Da er Probleme mit zwei Username hat scheint es nicht am Konto zu liegen.
Und da er unterschiedliche Clients ausprobiert hat wird es wohl auch nicht an der Config derselbigen liegen.
Jemand eine Idee?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Dummvogel am 16.11.2020 20:45]
|
|
|
|
|
|
|
|
|
Wenn Du Probleme mit .profile/.bashrc ausschließen kannst, und die entsprechenden Home-Verzeichnisse nicht voll/am Quotalimit sind, würde ich nochmal die Login-Shell für die User überprüfen (zum Beispiel: chsh <username> , die Shell sollte natürlich existieren/installiert sein/ausführbar sein, und sollte auch vernünftig sein (also nicht /bin/true).
Kommst Du mit su --login <username> (bzw. su <username> in die Accounts?
|
|
|
|
|
|
|
|
|
|
|
"client_input_channel_req: channel 0 rtype exit-status reply 0" will so viel heißen, dass was ausgeführt wurde fertig ist. Das wäre normalerweise die Shell.
- Geht su <nutzer>?
- Ein Home sollte der Nutzer ja haben, weil wird erzeugt. Passen die Berechtigungen?
- Hat der Nutzer eine Shell gesetzt?
- Shell-Startupdateien sollten ja sauber sein weil Home frisch ist
- ...?
|
|
|
|
|
|
|
|
|
|
|
|
zusätzlich würd ich noch mal schauen ob was in der /var/log/auth steht.
|
|
|
|
|
|
|
|
|
|
|
Ich hab hier zuhause ein TrueNas laufen.
Das funktioniert auch schon seit einiger Zeit sehr gut und Dank den Jails (mini virtuelle Maschinen) kann man auch einige Dienste darauf laufen lassen.
Die Basis ist FreeBSD.
Jetzt überlege ich, wie sinnvoll es ist, ein Paar dieser Jails (bspw. gitea oder nen kleinen Webserver) ins Internet zu hängen.
Sollte man das lieber lassen oder ist das Risiko eher gering?
Ich denke mir, wenn jemand auf die virtuelle Instanz kommt, wie schwer fällt es ihm dort auszubrechen und auf das Host System zu kommen?
Oder auf den Rest des Netzwerks zuzugreifen.
Und gibt es Strategien um dies zu verhindern?
|
|
|
|
|
|
|
|
|
|
|
Kommt stark auf den Virtualisierungs-Stack an. Gibt diverse (ältere) guest-to-host privilege escalation Bugs in verschiedenen Virtualisierungs-Lösungen (VMWare, VirtualBox, QEMU).
Entscheidend ist da die Frage: Wie aktuell ist die Software in deinem TrueNas, welche Virtualisierung wird genutzt und in welchem konkreten Setup laufen deine virtuellen maschinen, ob sich da was ausnutzen lässt oder nicht.
|
|
|
|
|
|
|
|
|
|
|
ohne es selbst jemals genutzt zu haben aber was ich bisher(=in den letzten 20 jahren) darüber gelesen hab:
jails auf bsd sind ne solide sache, gibts schon ewigkeiten, in sauber und gut und waren somit mitunter der ideengeber für vserver für linux damals (stümper jails) und den namespaces die danach kamen (was dann auch die grundlage für so tools wie docker geliefert hat).
insofern würd ich (wie gesagt, bauch only) jails vertrauen, _aber_ es hängt natürlich alles von der konfiguration des services dadrin ab.
mit chmod 777 kriegste das beste system unsicher.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
"client_input_channel_req: channel 0 rtype exit-status reply 0" will so viel heißen, dass was ausgeführt wurde fertig ist. Das wäre normalerweise die Shell.
- Geht su <nutzer>?
| |
Ja das geht.
| |
- Ein Home sollte der Nutzer ja haben, weil wird erzeugt. Passen die Berechtigungen?
| |
Ja das passt auch
| |
- Hat der Nutzer eine Shell gesetzt?
| |
Ist eigentlich bei allen gleich. Sind wie gesagt keine lokalen Nutzer. Wie check ich das bei AD-Usern?
| |
- Shell-Startupdateien sollten ja sauber sein weil Home frisch ist
| |
Ja wie gesagt, das sollte soweit richtig sein.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
zusätzlich würd ich noch mal schauen ob was in der /var/log/auth steht.
| |
| |
| Code: |
Nov 12 11:02:19 gpudingsi sshd[40124]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.12.130.17 user=username
Nov 12 11:02:19 gpudingsi sshd[40124]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.12.130.17 user=username
Nov 12 11:02:19 gpudingsi sshd[40124]: Accepted password for username from 10.12.130.17 port 53857 ssh2
Nov 12 11:02:19 gpudingsi sshd[40124]: pam_unix(sshd:session): session opened for user username by (uid=0)
Nov 12 11:02:19 gpudingsi systemd-logind[3918]: New session 7437 of user username.
Nov 12 11:02:19 gpudingsi systemd: pam_unix(systemd-user:session): session opened for user username by (uid=0)
Nov 12 11:02:20 gpudingsi sshd[40165]: Received disconnect from 10.12.130.17 port 53857:11: disconnected by user
Nov 12 11:02:20 gpudingsi sshd[40165]: Disconnected from user username 10.12.130.17 port 53857
Nov 12 11:02:20 gpudingsi sshd[40124]: pam_unix(sshd:session): session closed for user username
Nov 12 11:02:20 gpudingsi systemd-logind[3918]: Removed session 7437.
Nov 12 11:05:01 gpudingsi CRON[40220]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 12 11:05:01 gpudingsi CRON[40220]: pam_unix(cron:session): session closed for user root |
|
Authentifizierung klappt halt. Kann evtl irgendwas aus der default-bashrc fehlschlagen? Wie checke ich das?
|
|
|
|
|
|
|
|
|
|
|
Das mit der Shell sollte sich doch testen lassen, indem man die im ssh-Kommando explizit angibt: ssh my_strange_host /bin/sh
Laut manpage wird das Kommando statt der login shell ausgeführt.
|
|
|
|
|
|
|
|
|
|
|
|
Fragen die hier standen gelöscht. Ich denke nicht, dass sie hilfreich sind.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 17.11.2020 15:13]
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
