Den frie kafeen

[Del]

Ssh

[hernil]

Med mindre du har behov som gjør at Wireguard ikke egner seg så anbefaler jeg det på det sterkeste!

Lite forbehold om at tooling for brukeradministrasjon etc. fortsatt er ganske ungt.

[Stratleray]

Noen som vet om jeg kan dytte inn en slik ssd disk inn i min Thinkpad x200 og t420?

https://www.kjell.com//no/produkter/data/datamaskinkomponenter/harddisker/wd-green-ssd-disk-120-gb-p61642?gclid=Cj0KCQjwka_1BRCPARIsAMlUmEoPoYcNqSssogf9ILOxsbd2AfFy5e3YWqGUpyHW66xv0dQ3V6K-oJQaAvwUEALw_wcB&gclsrc=aw.ds

Har aldri drevet med utskifting av hw så det er ikke mitt felt. Hadde vært kjekt å holde liv i dem noen år til

[Gavekort]

Skal være ganske standard det ja. Det eneste er at noen Thinkpad-modeller krever disker av den tynne varianten.

x200 støtter bare SATA II, så du vil være begrenset til 3 Gbps båndbredde.

[tingo]

T420 har drive bay for 7mm høye disker, ifølge denne https://www.thinkwiki.org/wiki/7mm_hard_drive_bay

Ser ut som X200 støtter 9mm tykke disker, basert på denne modellen https://www.youmagine.com/designs/hdd-rails-for-my-thinkpad-x200s

Endret 2. mai 2020 av tingo

[Stratleray]

Flottings! Det var ganske standard ja. Valgte å kjøpe en 250Gb SSD til T420

 

Før brukte den 1:03 ved oppstart. Boot tid til innloggingen.

Ny boot tid er 17sek.

Så dette var skikkelig suksess :)

[Gjest]

Noen som har gode dotfiles og har lyst å dele?

[Gavekort]

Pleier å bruke disse:

https://github.com/timss/dotfiles (tmux, bash, og gitconfig)

https://github.com/timss/vimconf

[minim]

dere som kjører proxmox hvordan håndterer dere overvåking av server samt UPS? Jeg forsøkte å legge inn NUT og koble en Eaton UPS til proxmox direkte og dette fungerer fint. Samme med overvåking der jeg kan bruke grafana på et VM og installere en node på proxmox, men hva er beste praksis her egentlig? Med ESXi er jeg vant til å ha så lite som mulig i hypervisoren og det gjør oppdateringer enklere også. Med NUT + prometheus node og diverse config så baler det på seg med unødvendige ting i hypervisoren. Akkurat NUT kan sikkert kjøres på et VM og sende shutdown kommandoer til hosten, men sensorer fra serveren har jeg ikke funnet noen god måte å hente inn i et VM. 

[Stratleray]

Jeg er kun vant med å installere programmer fra formater som .deb .rpm snap flatpak og Appimage.

Lurer derfor på hva som skjer hvis man installerer noe fra kilde, install from source. Hva slags fil blir det, hvor kan jeg finne den senere, hvordan fjernes dem. Blir den automatisk oppdatert ved bruk av apt update/upgrade f.eks? Er det noen fordeler eller ulemper?

Bruker Ubuntu 20.04 nå.

[Gavekort]

Installerer man fra kildefiler så må man vedlikeholde programmene selv. Hvordan programmene installeres er opp til hver utvikler, men det er vanligst å legge ei binærfil i /usr/bin eller lignende.

Jeg anbefaler å bruke git til å klone repo om du skal vedlikeholde programmer fra kildefiler. Da kan du oppdatere programmer med 'git pull' før du rekompilerer.

[Del]

Jeg vil fraråde deg å legge egenkompilerte program i /usr/bin. Lag heller en egen mappe i hjemmemappen din, som du så legger til i PATH variabelen. Det er altfor lett å knekke systemet hvis du skriver til systemmappene, og et mareritt å debugge etterpå.

[Stratleray]

Ok, takk for svar  

Vil det si at kilde filer er lik exe filer og appimage?  Når de er installert blir de værende sånn helt til man manuelt installerer dem på nytt?

Å legge dem i home mappe høres ut som et bra tips

[xaco]

Kildefilene er bare kildekoden(i praksis txt filer). Kompilerte koden er maskinkode, det er litt mer som exe filer på windows.

En annen vanlig løsninger er å legge selvkompilert kode under /opt

[HawP]

Evt. så finnes også /usr/local  (med underkataloger bin,lib,lib64,osv.) som er beregnet på "local data, specific for this host".

F.eks. har ffmpeg sin configure /usr/local som default "prefix", dvs. de forskjellige filene havner i en passende underkatalog.

Forøvrig har jeg, mest for moro, nettopp klatret opp lærekurven for å kunne lage rpm fra ffmpeg snapshot og ha i et lokalt repository, siden opensuse buildservice skriver at ffmpeg i "full configuration" ikke tillates hostet (pga. linking til patenterte codecs).
Kort fortalt er det slik (kanskje litt spesifikt for opensuse hos meg):
- Installere rpmbuild og evt. andre nødvendigheter.
- Laste ned/hente sourcefiler og om nødvendig/ønskelig lage patcher/diff-filer.
- Evt. pakke om sourcefiler til .tar.xz (tilsynelatende det rpmbuild forventer hos meg).
- Lage eller kopiere og redigere en .spec fil. Denne styrer hvordan kildekoden kompileres og hvordan rpm bygges
- Kjøre rpmbuild -bb  med .spec fila (og evt. andre parametre)
- Evt. signere rpm-filer med en gpg-key (hvis ikke klager pakkebehandler på manglende signering ved installasjon)
- Kopiere filene til (lokalt) repo og oppdatere det (createrepo)
- Signere repodata/repomd.xml (for å slippe varsel fra pakkebehandler om at repositoriet kanskje ikke er til å stole på).
- Eksportere public key for signering til repodata/repomd.xml.key slik at pakkebehandleren kan importere den (engangsjobb)

rpmbuild er beregnet kjørt som "vanlig bruker", dvs. ikke root. Forøvrig støtter opensuse buldservice også å bygge pakker for Fedora, Debian og Ubuntu.

Endret 16. august 2020 av HawP

[Betroz]

Hey

Hvordan får jeg Manjaro Linux (nyeste) til å kjøre CPU med performance governor hele tiden? Jeg har en 5.0 Ghz overklokk, men får bare stock 3.7 Ghz når jeg f.eks tester med Blender Open Data. Frekvensen skal ligge på 5.0 Ghz hele tiden, og ikke 3.7 siden jeg har manuell OC på CPU. Kjører med 5.7.15-1 kernelen. Testa 5.8, men samme der.

Edit : Intel 10900K CPU og XII Apex hovedkort - så kanskje ikke kernelen støtter alt riktig enda?

Endret 25. august 2020 av Betroz

[Betroz]

Ingen som vet om en løsning? Jeg kan jo vente til en nyere kernel kommer ut, eller at Manjaro teamet får til en fix - eller bruke Windows 10 der alt funker som det skal, ironisk nok ?

 

[Del]

Arch har god dokumentasjon, se om du finner det du trenger her:

https://wiki.archlinux.org/index.php/CPU_frequency_scaling

[Betroz]

10 hours ago, Del said:

Arch har god dokumentasjon, se om du finner det du trenger her:

https://wiki.archlinux.org/index.php/CPU_frequency_scaling

Takk for svar. Jeg var innom der, men fant ikke ut av det. Virker som om ikke alt i hardware er fullt støttet enda :

Driver som mangler?

Endret 26. august 2020 av Betroz

[Del]

Betroz skrev (3 timer siden):

Takk for svar. Jeg var innom der, men fant ikke ut av det. Virker som om ikke alt i hardware er fullt støttet enda :

Driver som mangler?

Tvert imot. Hvis du leser dokumentasjonen står det følgende:

Sitat

The pstate power scaling driver is used automatically for modern Intel CPUs instead of the other drivers below. This driver takes priority over other drivers and is built-in as opposed to being a module. This driver is currently automatically used for Sandy Bridge and newer CPUs. If you encounter a problem while using this driver, add intel_pstate=disable to your kernel line. You can use the same user space utilities with this driver, but cannot control it.

Hvis du tar en

sudo lsmod

så kan du jo se om pstate er listet, eventuelt søk etter den i dmesg dersom lsmod ikke lister den. Jeg har ikke noen Intel CPU selv, så det blir litt vanskelig her. For å se frekvens på tilfeldig tidspunkt til alle kjerner bør /proc/cpuinfo gi deg tallene, bare prøv med:

cat /proc/cpuinfo

du kan greppe innohldet også for å få ut kun frekvenser.

Hvis du leser videre i dokumentasjonen til Arch, står det følgende om kontroll av pstate:

• Even P State behavior mentioned above can be influenced with /sys/devices/system/cpu/intel_pstate, e.g. Intel Turbo Boost can be deactivated with echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo as the root user for keeping CPU-Temperatures low.
• Additional control for modern Intel CPUs is available with the Linux Thermal Daemon (available as thermald), which proactively controls thermal using P-states, T-states, and the Intel power clamp driver. thermald can also be used for older Intel CPUs. If the latest drivers are not available, then the daemon will revert to x86 model specific registers and the Linux ‘cpufreq subsystem’ to control system cooling.