FAQ: Windows -> GNU/Linux - Umstieg, Einstieg, Aufstieg - Seite 33

Seite 33 von 82 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/faq-windows-gnu-linux-umstieg-einstieg-aufstieg_127618/page_33 - zur Vollversion wechseln!

eitschpi schrieb am 12.11.2016 um 20:17

Hat schon mal jemand tlp recalibrate genutzt? Bei mir hört's im Netzbetrieb einfach nicht auf zu laden...

eitschpi schrieb am 13.11.2016 um 10:32

Fein, nach dem "Rekalibrieren" hab' ich noch weniger Akkukapazität.

Garbage schrieb am 13.11.2016 um 10:53

Zitat von t3mp
Je nach Chip funktionieren sie durchaus schon weniger schlecht. Auf Support für moderne Chips brauchst du aber nicht warten seit Nvidia die Firmware signiert.

AMD, punktaus.

Irgendwie ist da aber bzgl. AMD die Meinung offenbar sehr gespalten, ich kenn da auch andere Meinungen und meine Erfahrung ist auch eher mau.

Ich habe unlängst versucht dem HTPC auf Kabini-Basis (Athlon 5350) ein Mint 18 zu verpassen, was natürlich nicht die Schwierigkeit war.
Allerdings ruckelt da selbst der Desktop, vom fehlenden HW-Decoding für Videos gar nicht erst zu reden.

Bekommt man das mit vertretbarem Aufwand hin? Gerade weil die HW jetzt nicht mehr ganz neu ist, aber mit GCN 1.1 auch nicht 100 Jahre alt, sollte man ja annehmen dürfen, dass das funktioniert.

Mit dem Treiber von NVIDIA hatte ich über die Jahre eigentlich nie Probleme und Intel funktioniert üblicherweise auch ganz ordentlich, zumindest nach einigen Updates bei frischer Hardware.

COLOSSUS schrieb am 13.11.2016 um 12:31

Wenn du einen HTPC willst, verwende als Basis lieber LibreELEC oder OpenELEC - das ist auf den Use-Case soweit zugeschnitten, dass ootb alles funktioniert, was mit dem gegnwaertigen Entwicklungsstand funktionieren kann.

eitschpi schrieb am 13.11.2016 um 12:33

Ist LibreELEC jetzt der bessere Fork von OpenELEC?

Vinci schrieb am 16.11.2016 um 22:26

Die Linux Foundation heißt ihr neuestes Platinum Member willkommen...

Nico schrieb am 09.12.2016 um 21:03

kennt jemand einen ubuntu mirror der via https abgefragt werden kann, oder geht das mit ubuntu + apt garnicht?
tia

edit: passt schon, hab eine alte liste gefunden.

COLOSSUS schrieb am 11.12.2016 um 11:26

Dank der PGP-Signaturen der Pruefsummen der Images brauchst du keine Transport Security, um sicherstellen zu koennen, dass deine Downloads OK sind.

wergor schrieb am 19.12.2016 um 23:28

Reliably compromising Ubuntu desktops by attacking the crash reporter

In this post I’ll describe how I found a remote code execution bug in Ubuntu Desktop which affects all default installations >= 12.10 (Quantal). The bug allows for reliable code injection …

Link: donncha.is

gab es nicht irgendwo einen security issues thread? kann den gerade nicht finden.

Hansmaulwurf schrieb am 20.12.2016 um 13:49

Zitat von wergor
Reliably compromising Ubuntu desktops by attacking the crash reporter

In this post I’ll describe how I found a remote code execution bug in Ubuntu Desktop which affects all default installations >= 12.10 (Quantal). The bug allows for reliable code injection …

Link: donncha.is
gab es nicht irgendwo einen security issues thread? kann den gerade nicht finden.

https://www.overclockers.at/general...n_238671/page_1

wergor schrieb am 20.12.2016 um 14:40

Danke, habs dort nochmal gepostet.

Hansmaulwurf schrieb am 16.01.2017 um 11:07

Ich hab hier ein Problem wo ich nicht ganz weiß wie ich das User/Berechtigungs-technisch am besten löse.

SQL-Folder von Maschine A -> Maschine B. via cron-job.
A hat kein Backup, B schon. D.h. ich will die Datenbank von A, auf B sichern.
Jetzt brauch ich aber root-Rechte um es zu kopieren, allerdings geht als root anscheinend das "authorized_keys"-file von ssh nicht. D.h. ich müsste ein passwort eingeben.

Also was ich will ist als root via cron ein .sh Skript ausführen, das ein "scp mysqldaten user@server:backup-folder" macht, ohne dabei ein Passwort zu verlangen. Ergibt das Sinn, oder denk ich gerade verkehrt? Und warum funktoniert's net

COLOSSUS schrieb am 16.01.2017 um 11:26

Die authorized_keys-Datei von Root wird kein Stueck anders behandelt als die irgendeines anderen Users - dein Problem muss also anderswo liegen. Um rauszufinden, was nicht geht, willst du am Client deinen ssh-Client mit -v (fuer verbose) aurufen, und am Server ins syslog (Facility auth) schauen - idealerweise, waehrend der sshd dort mit LogLevel VERBOSE laeuft. Das sollte recht detailliert Auskunft geben helfen, warum die Authentifikation scheitert.

nexus_VI schrieb am 16.01.2017 um 11:49

Eventuell ist in der sshd_config der root login deaktiviert?

Sonst schau, ob die Rechte Stimmen (700 auf .ssh, 600 auf authorized_keys), bzw wirf einen Blick ins auth.log

Hansmaulwurf schrieb am 16.01.2017 um 11:57

Danke euch, das war der richtige Tipp (das die auth-Datei genau gleich funktioniert).
Ich hab verkehrt herum gedacht.. Ich dachte server braucht die keys from client (damit der Client connecten kann), aber der Client braucht natürlich die keys from user am server..
Danke, habt mir sehr geholfen !