LNX Kroeg - Deel 2

[aawe mwan]

Borromini schreef op vrijdag 4 december 2020 @ 23:18:
Dan nog lijkt het me toch makkelijker om de naam van de interface aan het MAC-adres te linken? MAC A -> eth0, MAC B -> eth1, ...

Sommige systemen zetten het MAC adres in de naam van de ethernetpoort.

Op mijn oude x64 computer heten de aansluitingen nog eth0 en eth1 en ze wisselen nooit.
Op een ARM computer (zoals Raspberry Pi) heb ik nog nooit wat anders gezien dan eth0.

Op een oude Intel NUC heet de ingebouwde netwerkpoort hier tegenwoordig "eno1".

Op een computer met 2 netwerkpoorten op een PCI insteekkaart heten de poorten (even uit het hoofd) enp2s0 en enp2s1 en de poort op het moederbord heet weer anders.

Verder heb ik een Mele mini-PC en daar heet de netwerkpoort enx00ce39xxyyzz (macadres) dus dat is eigenlijk de enige die technisch echt uniek is.
Maar praktisch is dat niet, want etherwake pakt bijvoorbeeld altijd eth0, tenzij je zelf de naam van de poort opgeeft en ik weet het MAC adres van die poort dus niet uit m'n hoofd. (ik los dit op met een alias)

Het bovenstaande allemaal met recente versies van debian/Ubuntu.

[|sWORDs|]

nero355 schreef op zaterdag 5 december 2020 @ 00:40:
[...]

Als ik @|sWORDs| mag geloven dan is de IOMMU implementatie heel lang buggy geweest bij AMD en dan heb ik het over EPYC systemen!


[...]

AsRock Support in Nijmegen is inderdaad een toppertje!

Onlangs nog voor mijn 7 jaar oud moederbord allerlei tips en info gehad omtrent de kapotte chipset fan

Ik heb al flink wat avonden met Wendell (Wilson, Level 1 Techs), aan IOMMU op EPYC Naples besteed. Het meeste is door de implementatie van de groups, maar er is nog wel meer aan de hand (met name met vIOMMU). Op Rome gaan de groepen meestal wel goed, zeker met Supermicro, vIOMMU nog niet. Echter is alles hier wel over naar AMD (dual 7601 en dual 7542).
En ik weet dat Wendell met Gigabyte aan de slag is geweest, voor hun implementatie, echter is Gigabyte support voor mij zo’n drama geweest dat ik nooit meer een Gigabyte server (workstation/game PC heeft wel een consumer Gigabyte bord) component neem. Supermicro support is (voor mij, geen idee hoe het voor stervelingen bij een normale werkgever is) fantastisch. Als ik een mailtje naar support stuur, krijg ik gewoon antwoord van de PM, niet altijd het antwoord wat ik wil horen, maar wel snel en bij een nee nemen ze het component gewoon weer terug en kan ik iets anders nemen. Vraag ik om een BIOS fix heb ik ‘m meestal binnen 24 uur.
Asrock is vaak traag (als in na maanden nog steeds geen nieuwe microcode, of sommige borden die helemaal nooit een update krijgen) met BIOS updates, verder geen support ervaring.

[ Voor 39% gewijzigd door |sWORDs| op 05-12-2020 13:51 ]

[gekkie]

Hmm bij debian buster zijn ze kennelijk bezig met de migratie naar Python 3.9, maar duidelijk nog niet alles is gerebuild, maar eventjes wachten met updaten aantal packages wat tie wil removen is best groot

[vanaalten]

gekkie schreef op maandag 7 december 2020 @ 09:55:
Hmm bij debian buster zijn ze kennelijk bezig met de migratie naar Python 3.9, maar duidelijk nog niet alles is gerebuild, maar eventjes wachten met updaten aantal packages wat tie wil removen is best groot

Debian Buster (= stable)? Of Bullseye, testing?

Hier draai ik Buster met Python 3.7.3-1. Kan mij niet voorstellen dat ze zo'n wijziging in 'stable' zouden doen.

[gekkie]

vanaalten schreef op maandag 7 december 2020 @ 12:41:
[...]

Debian Buster (= stable)? Of Bullseye, testing?

Hier draai ik Buster met Python 3.7.3-1. Kan mij niet voorstellen dat ze zo'n wijziging in 'stable' zouden doen.

Oops, bullseye met die opmerking

[Eärendil]

Ik had het laatst ook in Unstable. Toen de eerste Python 3.9 packages kwamen gaf dat wat conflicten, maar dat kwam vanzelf goed na een paar dagen.

[himlims_]

tooltje van deze week
https://gitlab.com/CalcProgrammer1/OpenRGB

de kerstverlichting van de computer regelen

[nero355]

himlims_ schreef op maandag 7 december 2020 @ 13:19:
tooltje van deze week
https://gitlab.com/CalcProgrammer1/OpenRGB

Ik lees daar inderdaad steeds vaker hele positieve berichten over van de RGB gebruikers

Scheelt ook weer het zoveelste account aanmaken bij Razer, Logitech, enz...

[Hero of Time]

Eärendil schreef op maandag 7 december 2020 @ 12:49:
Ik had het laatst ook in Unstable. Toen de eerste Python 3.9 packages kwamen gaf dat wat conflicten, maar dat kwam vanzelf goed na een paar dagen.

Dat is altijd de oplossing met Unstable/Sid. Gewoon paar dagen wachten, lost zich vanzelf op.

Tenzij je fastboot nodig hebt, wat onderdeel is van de Android tools. Die in Unstable is onbruikbaar. Het is namelijk vervangen met een script dat niets anders zegt dan "fake placeholder until fastboot builds".

himlims_ schreef op maandag 7 december 2020 @ 13:19:
tooltje van deze week
https://gitlab.com/CalcProgrammer1/OpenRGB

de kerstverlichting van de computer regelen
[Afbeelding]

Gadvergamme, ga eens weg met dat Windows screenshot.

[syl765]

CentOS gaat van een LTS release cycle naar een rolling release cycle.
Daar ben je volgens mij niet blij mee als als je als bedrijf juist die long term support wilt en je je hele infrastructuur op deze versie heb gezet.

https://blog.centos.org/2020/12/future-is-centos-stream/

[ Voor 17% gewijzigd door syl765 op 11-12-2020 18:18 ]

[FireDrunk]

Rolling Releases die weinig upgrades doen qua major versies zijn toch ook gewoon stabiel?
Het is maar net hoe die rolling release er uit gaat zien, of het impact heeft.

Je kan nog steeds rustig kiezen wanneer je welke upgrade doet toch? Tis maar net hoe je het bekijkt.

[syl765]

Zeker waar, maar een hoop bedrijven kiezen een LTS voor de lange ondersteuning van pakket X op het OS en het OS gaat dan een jaar of 6 mee en pakket X blijft ook op zijn versie. Nu kan je niet updaten omdat het officiele pakket X ook een upgrade krijgt en dat wil je nu net niet. Tevens had je een stabiele basis met CentOS, nu gaat CentOS vooruit lopen op RHEL wat de stabiliteit niet altijd ten goede zal komen denk ik.

https://www.zdnet.com/art...inux-and-users-are-angry/

[nero355]

Ik denk dat er een heleboel bedrijven in de wereld van hosting dat niet bepaald leuk gaan vinden!

DirectAdmin/cPanel/Plesk i.c.m. CentOS was/is zo'n beetje een default setup voor heel veel bedrijven...

[Hero of Time]

nero355 schreef op vrijdag 11 december 2020 @ 18:35:
Ik denk dat er een heleboel bedrijven in de wereld van hosting dat niet bepaald leuk gaan vinden!

DirectAdmin/cPanel/Plesk i.c.m. CentOS was/is zo'n beetje een default setup voor heel veel bedrijven...

Voor dat laatste deel maakt het al geen drol uit, van o.a. DA maakt geen gebruik van de packages uit de repo maar compileert de bende zelf via custombuilds. Er blijft op die manier heul weinig over van de distro en filosofie.

U wilt php? Prima, in de repo vind je 7.2. DA geeft u 7.4 en over een maand of twee is dat voor de extra node die u nodig hebt spontaan 8.0, want dat is de actuele versie geworden.

Bij zulke panels is het principe meer dat je maar naar de nieuwere upstream versie moet als je een security issue wilt oplossen. Met als risico dat je applicatie niet meer werkt. Dus dan heb je óf een werkend maar lek systeem óf een veilig maar niet functioneel systeem.

[nero355]

Hero of Time schreef op vrijdag 11 december 2020 @ 20:11:
Voor dat laatste deel maakt het al geen drol uit, van o.a. DA maakt geen gebruik van de packages uit de repo maar compileert de bende zelf via custombuilds. Er blijft op die manier heul weinig over van de distro en filosofie.

Dat was ik effe vergeten!

U wilt php? Prima, in de repo vind je 7.2. DA geeft u 7.4 en over een maand of twee is dat voor de extra node die u nodig hebt spontaan 8.0, want dat is de actuele versie geworden.

Bij zulke panels is het principe meer dat je maar naar de nieuwere upstream versie moet als je een security issue wilt oplossen. Met als risico dat je applicatie niet meer werkt. Dus dan heb je óf een werkend maar lek systeem óf een veilig maar niet functioneel systeem.

Van wat ik me kan herinneren was er toch wel vaak vraag naar een specifieke CentOS versie vanwege die panels, maar hoe en wat precies weet ik niet meer...

[Hero of Time]

@nero355, waarschijnlijk omdat die panels anders niet meer werken ivm 'verkeerde' versie van software waar het afhankelijk van is. Dan kunnen ze opeens iets niet meer. En is de klant boos, want de server doet het niet meer.

[syl765]

@nero355, waarschijnlijk omdat die panels anders niet meer werken ivm 'verkeerde' versie van software waar het afhankelijk van is. Dan kunnen ze opeens iets niet meer. En is de klant boos, want de server doet het niet meer.

Dat is dus die stabiele basis die je nodig hebt. Dat zou wel eens kunnen veranderen als je dus een rolling release gaat maken waarbij er op het OS bij updates te vaak versies worden verhoogd.

[Hero of Time]

syl765 schreef op zondag 13 december 2020 @ 11:08:
[...]

Dat is dus die stabiele basis die je nodig hebt. Dat zou wel eens kunnen veranderen als je dus een rolling release gaat maken waarbij er op het OS bij updates te vaak versies worden verhoogd.

Er wordt aangegeven dat er een specifieke versie van een CentOS wordt vereist. Bijvoorbeeld geen CentOS 7 2009, maar dat het niet nieuwer mag zijn dan CentOS 7 1809. Om maar even iets te noemen. Beide zijn stable, maar bij de 2009 zijn er meer fixes aanwezig, iets nieuwere libraries (wat geen enorme impact mag hebben), en een nieuwere kernel (of eerder, meer zut gebackported).

Als je panel die eisen gaat stellen, waarbij het dus niet kan draaien op de laatste versie van een enterprise LTS distro release, is er toch echt iets goed mis met het panel. Dat het zelf zut compileert en de package manager volledig negeert is al een enorme rode vlag wat dat betreft.

[nero355]

Hero of Time schreef op zondag 13 december 2020 @ 12:41:
Er wordt aangegeven dat er een specifieke versie van een CentOS wordt vereist. Bijvoorbeeld geen CentOS 7 2009, maar dat het niet nieuwer mag zijn dan CentOS 7 1809. Om maar even iets te noemen.

Hero of Time schreef op maandag 7 december 2020 @ 17:20:
Gadvergamme, ga eens weg met dat Windows screenshot subversiesupportpackgedoe.

[Hero of Time]

nero355 schreef op zondag 13 december 2020 @ 18:43:
[...]


[...]

Alsof ik er iets aan kan doen dat MS de versienummering van CentOS heeft overgenomen?

[silverball]

syl765 schreef op vrijdag 11 december 2020 @ 18:06:
CentOS gaat van een LTS release cycle naar een rolling release cycle.
Daar ben je volgens mij niet blij mee als als je als bedrijf juist die long term support wilt en je je hele infrastructuur op deze versie heb gezet.

https://blog.centos.org/2020/12/future-is-centos-stream/

Het zal in de praktijk allemaal wel meevallen, maar het voelt gewoon niet helemaal lekker om de rolling dev branch van RHEL te gaan draaien, hoewel die vermoedelijk al erg stabiel is. Bij ons op kantoor iig reden genoeg om de keuze van vendor/distro opnieuw tegen het licht te houden. Oracle Linux willen we niet, primair door onderbuikgevoelens en van Rocky Linux moeten we nog maar even zien wat daar van gaat komen.

[Miki]

Ik had een klein half jaar een proxmox servertje draaien maar ik merkte dat ik eigenlijk alleen containers gebruik voor applicaties en VM’s eigenlijk nauwelijks gebruik. Zodoende had ik mijn zinnen gezet om een CentOS servertje op te zetten toen het nieuws kwam de koers flink gewijzigd zou gaan worden. Ondanks dat ik vermoed dat CentOS stream voor homelabs prima zal volstaan ben ik eens verder gaan kijken. Na met wat proef VM’s te hebben gespeeld heb ik voor openSUSE Leap (headless) gekozen. Vooraf niet verwacht maar ik kan de distro voor server gebruik sterk aanraden. De text based Yast omgeving is bijvoorbeeld heel prettig en ook de balans tussen stabiliteit en beschikbare pakketten lijkt in goed in orde te zijn.

Edit: Suse heeft ook aangekondigd dat ze de betaalde Enterprise SLES ook beter willen aansluiten op openSUSE Leap. Met dat betreft bewegen zij dus de andere kant op die IBM/Redhat bewandeld met CentOS.
Zie aankondiging: https://lists.opensuse.org/opensuse-announce/2020-04/

[ Voor 16% gewijzigd door Miki op 19-12-2020 15:11 ]

[Touchdomex]

Zo vandaag ook maar Manjaro erop gezet. Was wat klaar met Ubuntu en liep tegen wat dingen aan met betrekking tot de store. Niet dat het nu veel beter is wat ergernisjes betreft maar heb er in ieder geval meer controle over

Mag nu wel alles weer opnieuw leren. Moet wel nog enkele dingen echt goed zetten maar eerst laat ik maar gaan wennen

[silverball]

Bij ons op kantoor overwegen we om de webservers t.z.t. te migreren naar debian-stable+btrfs vanaf een centos6/7/8+zfs/ext4/xfs/btrfs mengelmoes en dan zal mijn werkmachine ooit ook wel gaan volgen. Enige puntje is dat de debian installer in principe geen ondersteuning heeft voor btrfs subvolumes maar dit is vrij makkelijk te fixen door na 't partitioneren in de shell de gewenste subvolumes aan te maken en dan te mounten op de installatie /target. Zo bijvoorbeeld:

code:

mount -o subvol=@var_log /dev/BTRFS_DISK /target/var/log

Uiteraard dient ook de fstab gemuteerd te worden.

Privé teruggaan naar debian-testing is eigenlijk ook wel een fijn idee. Op Fedora/centos is de ondersteuning buiten 't redhat paadje toch wat beperkt. Denk aan kde ipv gnome of ufw ipv firewalld (wie verzint die syntax). Ook is stratis maar een flauw excuus voor btrfs en zfs IMO.

[Hero of Time]

Dat verzoek is al redelijk oud, 5 jaar al: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802707. Er is ondertussen wel een ander report een jaartje later met daadwerkelijk wat activiteit: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840248.

Zou idd mooi zijn als ze de filesystems die mogelijk zijn beter ondersteund worden qua opties.

[silverball]

Het blijkt dat het aanmaken van meerdere btrfs subvolumes tijdens de debian installatie nog makkelijker kan;

Drop na het aanmaken van een grote btrfspartitie met mountpoint '/' naar de shell:

code:

cd target

Root subvol creëren in de nieuw gemaakte btrfs partitie (heet hier '@')

code:

btrfs subvol create @ .

Subvolume id's weergeven

code:

btrfs subvol list .

Root subvolume id (enige die je bij 't vorige commando ziet) als standaard zetten; hierdoor is de mount optie 'subvol=@' niet nodig en spaart daardoor ook de fstab modificatie

code:

btrfs subvol set-default 257 .

Reeds aangemaakte meuk verplaatsen naar de nieuwe root

code:

mv etc /target/@/
mv media /target/@/

De btrfs partitie unmounten en de nieuwe root mounten op /target, door btrfs subvol set-default wordt direct de reeds aangemaakte subvol gekozen (sdX -> jouw btrfs apparaat)

code:

umount target
mount /dev/sdX /target

Dan eventueel simpelweg extra subvols maken in /target voor /var/log, /tmp, mysql en zaken. Deze zullen automatisch als kinderen van @ gemount worden. Daarna de installatie hervatten.

[Vishari Beduk]

Effe een vraagje.
Ik ben eigenlijk meer een Ubuntu gebruiker maar wilde toch eens Manjaro + KDE proberen.
Eerste indruk is niet echt positief; de UI ziet er niet mooi uit. Zelfs het Rasp Pi OS ziet er mooier uit.
Maar nu zit ik met het probleem dat het systeem steeds in lock screen schiet.
Nu kan ik wel de power setting vinden waardoor de monitor niet uit gaat.
Maar de setting voor lock screen kan ik nergens vinden.

Ik heb natuurlijk met google op 'manjaro lock screen settings' maar daar kom ik niet verder mee.
Ook op de 'login screen' settings van KDE kan ik niet vinden.

[WernerL]

Vishari Beduk schreef op zondag 27 december 2020 @ 12:53:
Effe een vraagje.
Ik ben eigenlijk meer een Ubuntu gebruiker maar wilde toch eens Manjaro + KDE proberen.
Eerste indruk is niet echt positief; de UI ziet er niet mooi uit. Zelfs het Rasp Pi OS ziet er mooier uit.
Maar nu zit ik met het probleem dat het systeem steeds in lock screen schiet.
Nu kan ik wel de power setting vinden waardoor de monitor niet uit gaat.
Maar de setting voor lock screen kan ik nergens vinden.

Ik heb natuurlijk met google op 'manjaro lock screen settings' maar daar kom ik niet verder mee.
Ook op de 'login screen' settings van KDE kan ik niet vinden.

In KDE kun je dat vinden onder system settings -> workspace behaviour -> Screen locking.

[Vishari Beduk]

WernerL schreef op zondag 27 december 2020 @ 13:27:
[...]
In KDE kun je dat vinden onder system settings -> workspace behaviour -> Screen locking.

Eindelijk verlost, mijn dank is groot.

[himlims_]

iemand tip omtrent (open source) tooltje voor 'registratie van hardware / software' (asset registration) welke goed bevalt?

[Hero of Time]

Zakelijk heb ik recentelijk GLPI ingevoerd. Is een totaalpakket dat ook als helpdesk ingezet kan worden, maar voor een cmdb kan je 't ook gebruiken en het ticket systeem gewoon niet inrichten. Bevalt prima tot nu toe.

[himlims_]

Hero of Time schreef op maandag 4 januari 2021 @ 12:44:
Zakelijk heb ik recentelijk GLPI ingevoerd. Is een totaalpakket dat ook als helpdesk ingezet kan worden, maar voor een cmdb kan je 't ook gebruiken en het ticket systeem gewoon niet inrichten. Bevalt prima tot nu toe.

glpi vond ik wat te uitgebreid voor wat we willen, nu testje van; https://snipeitapp.com/demo aan het uitrollen. Lijkt precies te doen wat ik wil; assets/licenties registreren, barcode erop en geschiedenis

[Hero of Time]

Ziet er ook wel aardig uit zo kijkende naar de screenshots. Ook een mooi knopje om direct aan iemand toe te kennen. Dat heeft glpi niet.

[silverball]

himlims_ schreef op maandag 4 januari 2021 @ 14:34:
[...]

glpi vond ik wat te uitgebreid voor wat we willen, nu testje van; https://snipeitapp.com/demo aan het uitrollen. Lijkt precies te doen wat ik wil; assets/licenties registreren, barcode erop en geschiedenis

Hmm asset registration, dat ga ik toch ook eens proberen. Ben onze spreadsheet 'uitleenlijstjes' een beetje zat.

[Hero of Time]

silverball schreef op maandag 4 januari 2021 @ 20:08:
[...]

Hmm asset registration, dat ga ik toch ook eens proberen. Ben onze spreadsheet 'uitleenlijstjes' een beetje zat.

Een controle en je bent de sjaak, dat wordt afgekeurd. Want geen goede tool en al helemaal geen historie.

Iets is nog wel beter dan niets. Maar liever fatsoenlijk.

[silverball]

Ben dan ook erg blij dat het op 't moment helemaal mijn verantwoordelijkheid niet is.

Overigens, puur uit nieuwsgierigheid; zijn er hier nog mensen die BSD op de desktop draaien ?

[Sjah]

Beetje flauw dat Bluestacks de pc Windows noemt. Volgens mij is pc ook linux. En als je wiki erop naslaat is pc zelfs ook macOS, waar ik het grondig mee oneens ben, omdat je macOS niet zomaar overal op mag zetten.

[Hero of Time]

Sjah schreef op maandag 4 januari 2021 @ 21:20:
Beetje flauw dat Bluestacks de pc Windows noemt. Volgens mij is pc ook linux. En als je wiki erop naslaat is pc zelfs ook macOS, waar ik het grondig mee oneens ben, omdat je macOS niet zomaar overal op mag zetten.

In het verleden werd er ook altijd gezegd 'PC or Mac'. Maar als je de definitie van PC bekijkt, wat staat voor Personal Computer, hoort een Mac toch wel in die classificatie. Ik zou anders niet weten waar een Mac onder zou vallen, naast 'onding' dan.

Helaas wordt PC veelal onlosmakelijk geassocieerd met Windows, want je kan eigenlijk in geen normale winkel een PC kopen dat geen Windows heeft, tenzij je dus voor een Apple apparaat gaat. Het is namelijk niet zo dat je de Mediamarkt in loopt en naast de Windows systemen een paar met Linux ziet staan.

[gekkie]

Hero of Time schreef op maandag 4 januari 2021 @ 22:09:
Helaas wordt PC veelal onlosmakelijk geassocieerd met Windows, want je kan eigenlijk in geen normale winkel een PC kopen dat geen Windows heeft, tenzij je dus voor een Apple apparaat gaat. Het is namelijk niet zo dat je de Mediamarkt in loopt en naast de Windows systemen een paar met Linux ziet staan.

Aan de andere kant is de kans ook klein dat ik een eventuele voorgeinstalleerde linux versie erop zou laten staan. Waarschijnlijk zal het voor het gros die in linux geïnteresseerd zijn tevens verspilde moeite zijn.

[himlims_]

onder de norm; server parkje energie moeten we wat zuiniger maken [..]

nu aantal oude storage bakken, platter schijfjes, x86 van 80wat cpu etc.
die dingen doen opzich niet veel qua cpu/load, voornamelijk backup/filer.

weet van dektop dat die atom(?)/arm dingen best efficiënt zijn; op server 0 ervaring mee. Verwacht qua compatability weinig issues (omdat linux is en blijft).

hoe is jullie ervaring daarmee? (power/hitte reduceren)

[Hero of Time]

The Qt Company Is Tomorrow Moving Qt 5.15 To Its Commercial-Only LTS Phase
Vanaf 5-1-2021 is Qt 5.15 LTS niet meer open source en zullen fixes dus alleen nog maar voor betalende klanten beschikbaar zijn. Qt 6.0, wat als alternatief wordt opgeworpen, is nog helemaal niet productieklaar en 6.1 gaat zo enorm veel veranderen dat het op ABI niveau niet eens meer geschikt is.

Lekkere kut actie zeg.

[himlims_]

himlims_ in 'nieuws: Qt Company sluit broncode Qt 5.15 na verschijnen commerc...

zag m op de frontpage ook langskomen; begrijp nog steeds niet hoe een code welke onder (l)gpl uitgegeven is, commercieel kan worden. of men moet van iedere commit toestemming krijgen, of men moet alles herschrijven.

[nero355]

himlims_ schreef op woensdag 6 januari 2021 @ 14:10:
zag m op de frontpage ook langskomen; begrijp nog steeds niet hoe een code welke onder (l)gpl uitgegeven is, commercieel kan worden.

Ik dacht ook dat zoiets alleen kan als de code onder een BSD License valt, maar blijkbaar zijn er dus een aantal achterdeurtjes die ook GPL code commerciëel kunnen maken

Best wel klote nieuws voor mij als Qt voorstander, want GTK applicaties vind ik op de een of andere manier altijd wat minder fijn dan Qt applicaties qua "feel" en soms ook stabiliteit/bugs in de GUI zeg maar

Zou wat zijn... Qt weg... KDE weg... en opeens moet ik switchen naar mijn dirty pleasure genaamd Xfce

silverball schreef op maandag 4 januari 2021 @ 20:38:
Overigens, puur uit nieuwsgierigheid; zijn er hier nog mensen die BSD op de desktop draaien ?

Zit er weleens stiekem aan te denken!

Ergens in 2004/2005 een volledige X omgeving compileren op mijn S939 Athlon 64 X2 4400+ met 2 GB RAM en 1900XTX was stiekem best wel gaaf!

Daarna t/m FreeBSD 6.3 of zo alleen als server OS gebruikt en vooral sinds de tijd waarin ZFS werd geïntroduceerd gelezen dat er heel veel veranderd is qua ports en OS management

[gekkie]

QT code is al sinds jaar en dag multi-license. En als je iets in de officiele repo wilt hebben dan zul je er ook akkoord mee moeten gaan dat ook die patch multilicense is. En een van die licenses die staat Trolltech toe om met die code bijdrage alles te doen, ook wat god verboden heeft.

Wat ze nu doen is op bepaalde branches de patches die ze zelf maken niet meer openbaar maken.
Dat verandert dus niets aan de licensiering van de tot dan toe bestaande code (dus geen re-licensing).

Alleen kunnen opensource projecten daar dus geen gebruik van maken. En als ze eventueel ook bugzilla's enzo niet meer openbaar maken dan wordt ook dat lastiger (anders zou je nog met wat effort die bugs ook zelf fixen en onder een van de opensource licenses bijdragen aan een forked-repo.

Maar goed het is dus een hoop dubbelwerk waarbij QT6 nog niet echt af is, dus nu een stuk meer "troll" dan "tech" helaas.

Wat ook vervelend kan zijn is dat betalende QT klanten inzicht hebben in security bugs die in de opensource branch niet gefixed worden.

De vraag is volgens mij dan ook of ze nog (snel) bijdraaien of dat er inderdaad geforked zal moeten worden, zal dan wel een KDE gedreven fork worden denk ik en een nieuwe naam zoeken.
Maar buiten KDE zijn er nog wel meer zelfstandige applicaties die er ook mee zullen zitten zoals bijvb Calibre.

Aan de andere kant wordt dan de opensource kant maar matig voor commerciele bedrijven, omdat er geen commerciele license op mogelijk is. De kans dat een opensource fork de handel zou kunnen re-licensen van iets van L(GPL) zal nul zijn als trolltech niet meewerkt als grootste contributor, dus het zal dan (L)GPL blijven.
Dus ik denk dat het vooral vooruit gang zal laten stokken en tegelijkertijd een hoop dev-uren zal opeten en dat is nogal zonde.

[ Voor 24% gewijzigd door gekkie op 06-01-2021 19:08 ]

[silverball]

himlims_ schreef op woensdag 6 januari 2021 @ 11:41:
onder de norm; server parkje energie moeten we wat zuiniger maken [..]

nu aantal oude storage bakken, platter schijfjes, x86 van 80wat cpu etc.
die dingen doen opzich niet veel qua cpu/load, voornamelijk backup/filer.

weet van dektop dat die atom(?)/arm dingen best efficiënt zijn; op server 0 ervaring mee. Verwacht qua compatability weinig issues (omdat linux is en blijft).

hoe is jullie ervaring daarmee? (power/hitte reduceren)

Ik heb +- 2 jaar een Supermicro A2SDi-4C-HLN4F in huis en dat werkt eigenlijk prima, geen issues tegengekomen en dankzij de lage tdp kon ik de supermicro 80mm server fan ook nog eens vervangen door een set noctuas van 40 en 80mm ter behoeve van de geluidsproductie. Later nog eentje weggezet bij een familielid, ook als homeserver (en mijn offsite backup). Maar dat werkt als een tierelier als OpenZFS router/seed/kvm/git/ttd/vpn/teamspeak/file -servertje. Ik had mijn buggy consumer NAS veel eerder weg moeten doen.

Enige waar ik even mee heb moeten stoeien was dat de noctua's een te lage minimum pwm snelheid hadden voor de UEFI/ipmi firmware, maar dat is redelijk snel gefixt.

Dat herinnert mij eraan dat ik voor mezelf tzt ook nog iets vergelijkbaars moet bouwen. Ik vlieg over ongeveer een maand uit en moederlief wilt vermoedelijk haar kodi library en fotocollectie houden.

[himlims_]

silverball schreef op woensdag 6 januari 2021 @ 20:23:
[...]

Ik heb +- 2 jaar een Supermicro A2SDi-4C-HLN4F in huis en dat werkt eigenlijk prima, geen issues tegengekomen en dankzij de lage tdp kon ik de supermicro 80mm server fan ook nog eens vervangen door een set noctuas van 40 en 80mm ter behoeve van de geluidsproductie. Later nog eentje weggezet bij een familielid, ook als homeserver (en mijn offsite backup). Maar dat werkt als een tierelier als OpenZFS router/seed/kvm/git/ttd/vpn/teamspeak/file -servertje. Ik had mijn buggy consumer NAS veel eerder weg moeten doen.

Enige waar ik even mee heb moeten stoeien was dat de noctua's een te lage minimum pwm snelheid hadden voor de UEFI/ipmi firmware, maar dat is redelijk snel gefixt.

Dat herinnert mij eraan dat ik voor mezelf tzt ook nog iets vergelijkbaars moet bouwen. Ik vlieg over ongeveer een maand uit en moederlief wilt vermoedelijk haar kodi library en fotocollectie houden.

hier voornamelijk als storage, ceph kleine 300gb per dag aan log, totaal tegen de petabyte aan opslag. replicatie naar identieke bak. Denk niet dat of zo'n klein sunnetje voor hier gaat werken

meeste hitte/energie wordt toch door de opslag/storage gegenereerd. langzaam zijn we over naar ssd, maar voor de koude opslag mag dat nog wel plattertje zijn. nog maar even verder zoeken welke richting ik op moet

@silverball als alles bij elkaar optel (live+backup etc.) kom tot de 2800TB https://ceph.io/ is wel mijn redding

[ Voor 11% gewijzigd door himlims_ op 07-01-2021 13:51 ]

[silverball]

himlims_ schreef op donderdag 7 januari 2021 @ 11:24:
[...]

hier voornamelijk als storage, ceph kleine 300gb per dag aan log, totaal tegen de petabyte aan opslag. replicatie naar identieke bak. Denk niet dat of zo'n klein sunnetje voor hier gaat werken

Dat is wel even een andere schaal inderdaad. Hier zo'n 48tb netto.

[FRidh]

gekkie schreef op woensdag 6 januari 2021 @ 19:03:
QT code is al sinds jaar en dag multi-license. En als je iets in de officiele repo wilt hebben dan zul je er ook akkoord mee moeten gaan dat ook die patch multilicense is. En een van die licenses die staat Trolltech toe om met die code bijdrage alles te doen, ook wat god verboden heeft.

Wat ze nu doen is op bepaalde branches de patches die ze zelf maken niet meer openbaar maken.
Dat verandert dus niets aan de licensiering van de tot dan toe bestaande code (dus geen re-licensing).

Alleen kunnen opensource projecten daar dus geen gebruik van maken. En als ze eventueel ook bugzilla's enzo niet meer openbaar maken dan wordt ook dat lastiger (anders zou je nog met wat effort die bugs ook zelf fixen en onder een van de opensource licenses bijdragen aan een forked-repo.

Maar goed het is dus een hoop dubbelwerk waarbij QT6 nog niet echt af is, dus nu een stuk meer "troll" dan "tech" helaas.

Wat ook vervelend kan zijn is dat betalende QT klanten inzicht hebben in security bugs die in de opensource branch niet gefixed worden.

De vraag is volgens mij dan ook of ze nog (snel) bijdraaien of dat er inderdaad geforked zal moeten worden, zal dan wel een KDE gedreven fork worden denk ik en een nieuwe naam zoeken.
Maar buiten KDE zijn er nog wel meer zelfstandige applicaties die er ook mee zullen zitten zoals bijvb Calibre.

Aan de andere kant wordt dan de opensource kant maar matig voor commerciele bedrijven, omdat er geen commerciele license op mogelijk is. De kans dat een opensource fork de handel zou kunnen re-licensen van iets van L(GPL) zal nul zijn als trolltech niet meewerkt als grootste contributor, dus het zal dan (L)GPL blijven.
Dus ik denk dat het vooral vooruit gang zal laten stokken en tegelijkertijd een hoop dev-uren zal opeten en dat is nogal zonde.

Mja, gratis open-source software is fijn, ik gebruik het nu bijna 20 jaar en draag ook bij aan projecten. Maar ik denk dat we ook realistisch moeten zijn met het financieren van de ontwikkeling. Zodra het meeste gratis is, dragen veel bedrijven gewoonweg niet meer bij. Ik merk het zelf met Nixpkgs/NixOS; medewerkers van bedrijven die Nix gebruiken zijn, als ze bijdragen, voornamelijk bezig met de "toffe" dingen, maar niet het bijhouden van kritieke pakketten.

Men wilt maar al te graag Qt gebruiken, wat inmiddels een immens grote toolkit is. Die ontwikkeling moet ook gefinancieerd worden. Bedrijven zijn doorgaans meer dan bereid om te betalen voor software welke ze nodig hebben, zeker meer dan om te doneren aan projecten. Voor de open source community is deze verandering jammer, maar ook weer niet zo'n groot probleem. Kritieke bugs zullen voornamelijk voorkomen in het webgedeelte (qtwebengine). Tig programma's gebruikten nog qtwebkit terwijl het al harstikke lek was. Als je qtwebengine (of nog steeds qtwebkit) gebruikt zul je dus sneller moeten overstappen naar Qt 6, wat voor applicaties redelijk makkelijk zal zijn. Bij veel software welke qtwebengine gebruikt moet je je ook al afvragen waarom ze een browser willen integreren in hun applicatie...

Het lastigste zal dit wellicht zijn voor de KDE community, maar als ik Nixpkgs even snel kijk naar de dependencies wordt qtwebengine ook niet zoveel gebruikt door hun. Kontact (kmail enzo) en konqueror zullen het hardst getroffen worden.

[syl765]

Overigens, puur uit nieuwsgierigheid; zijn er hier nog mensen die BSD op de desktop draaien ?

Ik voor mijn dagelijkse werkzaamheden (werk veel op de cli). Voor mijn werk gebruiken we alleen maar Ubuntu, maar sinds we thuis werken kan ik lekker mijn Desktop PC gebruiken als ik op de servers van de baas moet inloggen.

En dat bevalt prima. Teams en dergelijke heb ik op mijn MacBook draaien.

[gibraltar]

gekkie schreef op woensdag 6 januari 2021 @ 19:03:
[...]

Wat ook vervelend kan zijn is dat betalende QT klanten inzicht hebben in security bugs die in de opensource branch niet gefixed worden.

[...]

Aan de andere kant wordt dan de opensource kant maar matig voor commerciele bedrijven, omdat er geen commerciele license op mogelijk is. De kans dat een opensource fork de handel zou kunnen re-licensen van iets van L(GPL) zal nul zijn als trolltech niet meewerkt als grootste contributor, dus het zal dan (L)GPL blijven.
Dus ik denk dat het vooral vooruit gang zal laten stokken en tegelijkertijd een hoop dev-uren zal opeten en dat is nogal zonde.

Ik gebruik voor mijn werk zowel de commerciële als de open source variant voor klanten. Ik moet eerlijk bekennen dat de redenen om commercieel te gebruiken het meestal niet rechtvaardigt. De plugins die daardoor wel in een commercieel project te gebruiken zijn, zijn kwalitatief niet geweldig (Qt Charts, Qt VirtualKeyboard). Er is geen goede roadmap voor en ze 'voelen' gewoon niet gesupport.

De mysterieuze sfeer rondom de prijzen voor die licenties gaan ze nu transparant maken. Het is gewoon lastig om geld te verdienen voor de Qt Company. De nieuwe Qt for Microcontrollers is wel interessant en ik denk dat ze daarmee wel een goede route inslaan kwa commerciële toevoeging.

[himlims_]

whoooot

na 3 werkdagen prielen en frotten, -eindelijk- ELK-stack weer aan de praat.

Het is prachtig stukje logging/analyse wanneer het werkt en draait. Maar omfg wat een draak van een kaartenhuis is het. Staat een parametertje verkeerd, of een versie te ver vooruit of verschil klapt het in je gezicht

[nero355]

@himlims_

Gefeliciteerd dan maar hé!

Je ervaring klinkt een beetje net als mijn Ubuntu NetPlan aanvaring...

[Hero of Time]

nero355 schreef op maandag 11 januari 2021 @ 17:15:
Je ervaring klinkt een beetje net als mijn Ubuntu NetPlan aanvaring...

Ik hoorde vorige week dat je netplan compleet kan negeren en nog gewoon met /etc/network/interfaces de boel kan configureren. Fuck netplan!

[nero355]

Hero of Time schreef op maandag 11 januari 2021 @ 20:11:
Ik hoorde vorige week dat je netplan compleet kan negeren en nog gewoon met /etc/network/interfaces de boel kan configureren.

MOOI!!!

Fuck netplan!

HELL YEAH!!!

[Hero of Time]

nero355 schreef op dinsdag 12 januari 2021 @ 20:40:
[...]

MOOI!!!

[...]

HELL YEAH!!!

De persoon van wie ik het hoorde, draait sinds gisteren Debian Sid. Heck yeah!

Reden hiervoor was dat in Sid nu kernel 5.10 zit en hij draaide Mint en zat nog op 5.4. Om een of andere vage reden gaf Mint-update 'm niet 5.8 of nieuwer. En hij had dus issues met 5.4 die bij nieuwere kernels was opgelost. Dus, welkom Debian. En de vorige keer dat 'ie Testing/Bullseye probeerde (vorige maand) had 'ie gezeik met Optimus en had 'ie op een bepaald moment een kernel panic. Niet meer te herstellen. Nu gelukkig geen issues.

[Zjemm]

als je bijvoorbeeld een package als Postfix zelf hebt geïnstalleerd uit source.
kan je dan gewoon postfix als package uit de repository er overheen installeren?

source over source install gaat gewoon goed

ben het even kwijt

en heb de source files van destijds niet op die bak staan, maar wil nieuwe versie gaan draaien

[ Voor 35% gewijzigd door Zjemm op 13-01-2021 17:28 ]

[Hero of Time]

Ehm, laatste zin van de TW gemist?

Maar by default gebruikt source een andere prefix, dus er is geen 'overheen' installeren.

[Zjemm]

Tja vond het een beetje een grijze 😁


Maar vanuit source heb je bijvoorbeeld /etc/postfix ongebruik. Maar vanuit de package installatie zal die ook gebruikt worden.

Word het dan overschreven? Of faalt de package installatie?

Geen idee wat het standaard gedrag zou moeten zijn

[Hero of Time]

Backup en probeer 't.

[Zjemm]

Ja ga ik ook doen
Was gewoon benieuwd hoe of het hoort te gaan

[nero355]

@Zjemm

Onder FreeBSD was er alleen een verschil tussen (destijds) Sendmail van het OS zelf en Sendmail via pkg of vanuit de ports (zelf compileren) geinstalleerd.

Maar je kon prima via pkg iets installeren en dan via de ports updaten!

Dus... dan weet je dat in ieder geval!

[Zjemm]

het lijkt te werken

[silverball]

silverball schreef op dinsdag 22 december 2020 @ 18:35:
Bij ons op kantoor overwegen we om de webservers t.z.t. te migreren naar debian-stable+btrfs vanaf een centos6/7/8+zfs/ext4/xfs/btrfs mengelmoes

We gaan ervoor , alle andere aangedragen opties zijn afgeschoten (met als grote concurrent ubuntu server). Ook komt er offsite een extra debian-stable+btrfs servert zodat we mooi de snapshots vrij efficiënt kunnen back-uppen.

Nu alvast het een en ander voorbereiden en dan wachten op Bullseye. Vanzelfsprekend komen de centos 6 servers eerst, de onlangs gemigreerde centos 8 servers zullen tijdelijk overgezet worden naar een andere RHEL rebuild zoals CloudLinux, of Oracle.

[himlims_]

silverball schreef op vrijdag 15 januari 2021 @ 10:27:
[...]

We gaan ervoor , alle andere aangedragen opties zijn afgeschoten (met als grote concurrent ubuntu server). Ook komt er offsite een extra debian-stable+btrfs servert zodat we mooi de snapshots vrij efficiënt kunnen back-uppen.

Nu alvast het een en ander voorbereiden en dan wachten op Bullseye. Vanzelfsprekend komen de centos 6 servers eerst, de onlangs gemigreerde centos 8 servers zullen tijdelijk overgezet worden naar een andere RHEL rebuild zoals CloudLinux, of Oracle.

hier vergelijkbaar 'projectje' high availability openstack ( ), co-locaties, is nogal een gepuzzle wat wel/neit kan. en wat nodig heb. vooralsnog lijkt het een redelijk prijskaartje te gaan krijgen. en dat netwerk met tich vlans zucht ... lekker complex heb er al bijna zin in. Nog niet eens gehad over de migratie van de bestaande bakken naar de vm. eerst maar eens concept uitschrijven

[Blokker_1999]

Afgelopen weekend kwam YT met een aanbeveling van iemand die een boxed versie van Debian 2 op de kop had getikt en deze ging installeren. Tijdens installatie op een oudere Thinkpad werd het al snel een rant van hoe slecht Debian in die tijd wel niet in elkaar stak. En hoewel ik hem niet helemaal ongelijk kon geven wilde ik het zelf ook even proberen. Heb snel even gezocht naar de oudste ISO die ik kon vinden, bleek een 1.3 versie te zijn van Debian en heb deze in Virtualbox gegooid. Zonder al te veel moeite:



En ja, zelfs het netwerk doet het

Nu is de vraag: kunnen we hier nog iets leuk mee doen?

[GuntherDW]

Met virtualbox gaat het qua "plezier" snel voorbij zijn gezien je geen deftige grafische performance hebt omdat je VESA moet draaien.
Kans dat je ook "vastzit" op 640x480 dus tenzij je gaat friengelen.

Beter dat je dan iets als PCem gebruikt en ineens dus de GPU's van toen erbij emuleert.

Zo heb ik een nog oudere stel mandrake en zelfs Slackware's (welke je nog samen met SLS moest installeren) "online" gekregen en wat games gespeeld zoals de originele "svgadoom" van de id ftp servers.

Enige probleem danwel is dat de hardware requirements ietsje zwaarder zijn natuurlijk maar je moet er iets voor over hebben

Heb voor de lol toen ook geprobeerd om een oude slackware te installeren, over NFS. En ja, it worked... kinda.


Enkele screenshots van toen :

https://i.imgur.com/NCOs46R.png - NFS mounten en instellen.
https://i.imgur.com/MbWBYmj.png - het installeren
https://i.imgur.com/em7fsi6.png - telnet werkende van host -> guest

EDIT: Eigenlijk, door het gebruik van PCem "cheat" je eigenlijk omdat je letterlijk de hardware van toen vrij "perfect" emuleert, maar dat moet je ook omdat de moderne emulatie dingen als vbox e.d. voorbij de terminal en heel misschien nog een oude netwerkkaart de compatibility en dus leute in X (als het dat al heeft) vrij snel over is.
Maar dan kan je op z'n minst in de "levende lijve" als het ware ervaren hoe het toen was natuurlijk

Alsook, het kon niet ontbreken, maar om het helemaal "juist" te doen had ik met pcem ook een win95 "VM" nog waarin ik de bootdisks mooi schreef, met timing correcte snelheden .
Al kwam die versie van slackware uit voor windows 95 uit kwam, dus had in principe een win3.11 ding correcter geweest maar die had ik miner snel handig met ook werkende TCP stack. Die heb ik nu nadien wel in orde gekregen trouwens.

https://i.imgur.com/cUSEN5Y.png

[ Voor 51% gewijzigd door GuntherDW op 18-01-2021 13:46 ]

[himlims_]

tooltje van de week; sosumi-snap

installeer macos (in vm/qemu)



https://github.com/popey/sosumi-snap

werk hier (verplicht) op macbook ... na jaar vind ik het nog steeds niets, doe mij maar een xubuntu desktop

[aawe mwan]

Blokker_1999 schreef op maandag 18 januari 2021 @ 12:24:
Afgelopen weekend kwam YT met een aanbeveling van iemand die een boxed versie van Debian 2 op de kop had getikt en deze ging installeren.

Die aanbeveling heb ik ook gehad, dat was YouTube: Installing Debian Linux 2.1 From 1999 Was A Painful Experience ... .

Ik heb laatst mijn boxed RedHat exemplaar uit 199x proberen te installeren. Dit met de bedoeling om hem daarna gewoon gratis te updaten naar de nieuwste versie. Ik liep pas vast op de netwerkkaart; die van mij is blijkbaar niet NE-1000 compatibel meer?

[ Voor 6% gewijzigd door aawe mwan op 19-01-2021 18:02 ]

[Blokker_1999]

aawe mwan schreef op dinsdag 19 januari 2021 @ 18:00:
[...]


Die aanbeveling heb ik ook gehad, dat was YouTube: Installing Debian Linux 2.1 From 1999 Was A Painful Experience ... .

Ik heb laatst mijn boxed RedHat exemplaar uit 199x proberen te installeren. Dit met de bedoeling om hem daarna gewoon gratis te updaten naar de nieuwste versie. Ik liep pas vast op de netwerkkaart; die van mij is blijkbaar niet NE-1000 compatibel meer?

De Red Hats uit de jaren 90 (heb er hier ook nog ergens 1 liggen, RH5 of RH6, niet zeker welk van de 2) zijn eigenlijk de Fedora's van vandaag. Op een gegeven moment hebben ze de ontwikkeling ervan bij RH stopgezet en de verantwoordelijkheid bij de community neergelegd met Fedora Core (later Fedora) om uiteindelijk zelf opnieuw meer controke erover te nemen.

[Blokker_1999]

himlims_ schreef op dinsdag 19 januari 2021 @ 11:43:
tooltje van de week; sosumi-snap

installeer macos (in vm/qemu)

[Afbeelding]

https://github.com/popey/sosumi-snap

werk hier (verplicht) op macbook ... na jaar vind ik het nog steeds niets, doe mij maar een xubuntu desktop

En ik blijf hier maar sukkelen met macOS op een nuc te installeren ... life ain't fair.

[GuntherDW]

Dat soort tooltjes zijn wel vaker opgesprongen de laatste paar jaar. Dat is er maar eentje van.

Als je het niet als snap wil omdat je geen ubuntu draait kan je een van deze 2 gebruiken


https://github.com/kholia/OSX-KVM of
https://github.com/foxlet/macOS-Simple-KVM (heb ik gebruikt indertijd)

Heb er deliberately geen Big Sur op gesmeten maar ik kon wel zomaar updaten zonder dat de bootloader gesnagged/modified werd.
Al is er blijkbaar bij de eerste wel Big Sur support?

Wel grappig gezien ik een Ryzen build heb
Als je trouwens meerdere GPU's hebt kan je ook via KVM (indien je goede IOMMU support hebt at least) een AMD GPU dedicaten naar die OSX VM's, zodat de GPU performance ook degelijk is en van GPU accel gebruik maken in je applicaties naar keuze.
Als je enkel nvidia hebt ben je out of luck, al is dat niet zo raar gezien ze bij Apple al lang niet meer met nvidia samenwerken.



Alleen moet je er wel bij beseffen dat Apple niet zo happig is op dit soort projecten natuurlijk.
Ze hebben al eens geprobeerd mensen een rechtzaak aan te spannen (zonder te winnen echter).

[ Voor 12% gewijzigd door GuntherDW op 20-01-2021 06:09 ]

[himlims_]

Hero of Time schreef op maandag 4 januari 2021 @ 16:49:
Ziet er ook wel aardig uit zo kijkende naar de screenshots. Ook een mooi knopje om direct aan iemand toe te kennen. Dat heeft glpi niet.

hebben die snipe-it vandaag live gegooid - larvarel hell - maar t werkt best nifty systeempje.
nu de administratie nog

[Hero of Time]

himlims_ schreef op woensdag 20 januari 2021 @ 16:54:
[...]

hebben die snipe-it vandaag live gegooid - larvarel hell - maar t werkt best nifty systeempje.
nu de administratie nog

Ik had 't paar weken terug geïnstalleerd op een loze vrijdag. Data wat we in glpi hadden naar csv gegooid, wat omgekat zodat SnipeIT het snapt en gaan. Welk framework er gebruikt wordt boeit mij niet zo veel. Larvarel heeft iig niet nog een composer install nodig, dat vind ik pas waard. Gewoon alle afhankelijkheden uit de repo pakken en klaar, niets geen externe meuk moeten ophalen voordat het z'n werk kan doen.

Nog bedankt voor de tool trouwens. De checkout en EULA functionaliteit is wel nice. Alleen jammer dat als je hardware aanvraagt, deze niet automatisch wordt afgehandeld wanneer de hardware wordt uitgegeven. Je moet het dan weer annuleren. Daar is al een issue van bekend.

[himlims_]

amazon forkt elasticsearch en kibana; https://opendistro.github.io/for-elasticsearch/ zie ook; https://aws.amazon.com/bl...pen-source-elasticsearch/

benieuwd hoe/wat (of puur aws wordt) ik vind machtig systeem (beetje complex) maar functioneel erg plezierig

//edit;
kwam deze vandaag tegen; https://www.jingos.com/ - ubuntu voor tablet met ipad look/feel. vond m wel interresant (verder niet gekeken hoe te gebruiken) maar goed, keertje wat anders dan zoveelste ubuntu flavor met andere thema/wallpaper.

nhahahahah

[ Voor 60% gewijzigd door himlims_ op 22-01-2021 13:50 ]

[nero355]

himlims_ schreef op vrijdag 22 januari 2021 @ 11:17:
//edit;
kwam deze vandaag tegen; https://www.jingos.com/ - ubuntu voor tablet met ipad look/feel. vond m wel interresant (verder niet gekeken hoe te gebruiken) maar goed, keertje wat anders dan zoveelste ubuntu flavor met andere thema/wallpaper.

Hmm... wel een beetje op de Chinese markt gericht, maar desondanks wel grappig bedacht en uitgevoerd

Misschien maar eens een keer kijken of het een beetje leuk draait op een oude Toshiba tablet met iets van een Atom SoC erin, want Windows 8.1 doet dat absoluut niet!

nhahahahah
[Afbeelding]

Iets met : YouTube: The Big Bang Theory "The Whip App" (HD)
En zo...

[FRidh]

Tijd weer voor wat drama?

PyCA cryptography is een Python pakketje wat best wel veel gebruikt wordt door andere pakketten. Voor performance zijn bepaalde delen in C geschreven.

Nu bestaat Rust al een poosje en vanwege de memory safety kreeg men het idee om delen die in C geschreven waren nu in Rust te herschrijven. Met andere woorden, voor het bouwen van een Python pakketje heb je nu ook Rust met cargo nodig.

Helaas betekent dit dat cryptography nu op veel platforms niet meer gebruikt kan worden aangezien Rust daar niet op werkt. En het brak voor veel mensen hun CI/CD (wat hun eigen fout is).

Jammer dat op veel platforms dit pakket niet meer gebruikt kan worden, maar aangezien memory safety essentieel is hier, lijkt het mij een goede keuze.

[himlims_]

ken er iemand een 'simpel' framwork/library om een console interface te frotten?

nu met whiptail bezig; werkt opzich prima, erg eenvoudig in gebruik, maar ervaar toch wat beperkingen.

erg bekend is ncurses, maar voor simpel console ben lappen text verder (dan wordt de UI 2x zo groot, dan daaadwerkelijke funcie die erin zit wil zetten )

[Hero of Time]

Ik ken dialog als alternatief voor whiptail. Schijnt dat als je het vanuit een GUI zou uitvoeren, je grafische dialogen krijgt ipv in je terminal. Maar is een simpele 'read -p' niet voldoende als er alleen wat antwoorden moet komen?

[himlims_]

hip tooltje


Akira is a native Linux Design application built in Vala and GTK. Akira focuses on offering a modern and fast approach to UI and UX Design, mainly targeting web designers and graphic designers. The main goal is to offer a valid and professional solution for designers who want to use Linux as their main OS.
https://github.com/akiraux/Akira

[init6]

FRidh schreef op dinsdag 9 februari 2021 @ 16:57:
Tijd weer voor wat drama?

PyCA cryptography is een Python pakketje wat best wel veel gebruikt wordt door andere pakketten. Voor performance zijn bepaalde delen in C geschreven.

Nu bestaat Rust al een poosje en vanwege de memory safety kreeg men het idee om delen die in C geschreven waren nu in Rust te herschrijven. Met andere woorden, voor het bouwen van een Python pakketje heb je nu ook Rust met cargo nodig.

Helaas betekent dit dat cryptography nu op veel platforms niet meer gebruikt kan worden aangezien Rust daar niet op werkt. En het brak voor veel mensen hun CI/CD (wat hun eigen fout is).

Jammer dat op veel platforms dit pakket niet meer gebruikt kan worden, maar aangezien memory safety essentieel is hier, lijkt het mij een goede keuze.

Rust bouwt geen binaries die meegenomen worden?
Ben zelf een fan van Golang, kan het compilen naar een target platform en dan kan iedereen de binary files gebruiken. Deze week nog een tooltje gemaakt om JWT tokens mee te genereren, erg nice. Vooral toen ik nog veel deed met namespaces en cgroups was het vrij lekker om mee te werken, gewoon een binary van een s3 bucket downloaden en opstarten in de namespace en cgroup setup en je had een redelijk geisoleerde applicatie. Tegenwoordig is alles in een docker container dus kan ik gewoon python of de jvm neerzetten, dus Golang heeft zijn grootste glans in dat opzicht een beetje verloren in mijn omgeving... Maar blijf het een prettige taal vinden om in te schrijven.

[ Voor 5% gewijzigd door init6 op 02-03-2021 16:44 ]

[himlims_]

krijg ineens mailtje; artikel gepubliceerd op mijn rootgamer.com (linux gaming)

ik doe er al tijdje bizonder weinig meer mee, vreemd dat er artikel gepubliceerd werd.

wordrpess 'hacked' (updates beetje verzaakt)

350.000 registered users, 700 artikeltjes afgelopen 9jr, publicatie in linux-mag (NLD) ach was leuk zolang het duurde. tijd voor nieuw projectje. (nog wel even backup van 2wk terug zetten) dan zet ik alles op read-only

[ Voor 7% gewijzigd door himlims_ op 11-03-2021 15:55 ]

[Jogai]

Whoops, heb een platgeslagen directory met meer dan 200.000 files. Is er nu een handig rsync commando dat ik alle bestanden in een mapje van de eigen file extensie kan krijgen. Dus alle .jpg files in de map 'jpg/' en alle .mpv bestandjes in de 'mp4/' map etc? Sommige bestandstypes hebben wel meer dan 10000 bestanden, en dan is het mv commando best traag...

[Hero of Time]

@Jogai, standaard mv *.jpg kan ook mislukken met 'argument list too long'. Er is verder niet echt iets dat sneller is, een move binnen hetzelfde filesystem is niets meer dan de inode updaten.

Je kan door de bestanden heen loopen en ze op die manier snel naar een eigen map te gooien zonder elk bestandstype afzonderlijk op te geven. Ik heb dit eens met bestanden moeten doen die UUIDs als naam hebben en in eigen mappen stonden. Maar door de te korte mapnaam, konden er geen nieuwe mappen meer gemaakt worden. Het herorganiseren daarvan was redelijk snel klaar.

De tijd tussen je vraag en mijn antwoord nu is iig veel langer dan het je zelf had gekost als je via find of andere manieren de bestanden had verhuisd.

[Eärendil]

Met Regex en Perl rename:

Als je dit hebt:

code:

$ ls -l                                            
total 8
-rw-rw-r-- 1 menno menno    0 mrt 21 09:34 a.jpg
-rw-rw-r-- 1 menno menno    0 mrt 21 09:34 b.jpg
-rw-rw-r-- 1 menno menno    0 mrt 21 09:34 c.jpg
-rw-rw-r-- 1 menno menno    0 mrt 21 09:34 d.png
-rw-rw-r-- 1 menno menno    0 mrt 21 09:34 e.png
drwxrwxr-x 2 menno menno 4096 mrt 21 09:40 jpg
drwxrwxr-x 2 menno menno 4096 mrt 21 09:40 png

Test-run:

code:

$ ls | file-rename -n 's|(.*)\.([^\.]+)$|$2/$1.$2|'
rename(a.jpg, jpg/a.jpg)
rename(b.jpg, jpg/b.jpg)
rename(c.jpg, jpg/c.jpg)
rename(d.png, png/d.png)
rename(e.png, png/e.png)

Echte rename:

code:

$ ls | file-rename 's|(.*)\.([^\.]+)$|$2/$1.$2|'

Resultaat:

code:

$ find 
.
./jpg
./jpg/c.jpg
./jpg/b.jpg
./jpg/a.jpg
./png
./png/e.png
./png/d.png

[Jogai]

Hero of Time schreef op zaterdag 20 maart 2021 @ 23:18:
@Jogai, standaard mv *.jpg kan ook mislukken met 'argument list too long'. Er is verder niet echt iets dat sneller is, een move binnen hetzelfde filesystem is niets meer dan de inode updaten.

Je kan door de bestanden heen loopen en ze op die manier snel naar een eigen map te gooien zonder elk bestandstype afzonderlijk op te geven. Ik heb dit eens met bestanden moeten doen die UUIDs als naam hebben en in eigen mappen stonden. Maar door de te korte mapnaam, konden er geen nieuwe mappen meer gemaakt worden. Het herorganiseren daarvan was redelijk snel klaar.

De tijd tussen je vraag en mijn antwoord nu is iig veel langer dan het je zelf had gekost als je via find of andere manieren de bestanden had verhuisd.

Dat laatste klopt niet. Hier een timing van een mv van 15361 bestanden (263 mb):

code:

Executed in   80.03 secs   fish           external 
   usr time    2.50 secs    2.39 secs  112.02 millis 
   sys time    1.32 secs    0.42 secs  898.43 millis

Het is een externe SSD die ntfs is geformatteerd. Misschien is het dat laatste wel. Maar het lijkt ook wel of het niet lineair schaalt, want hier 2.6GB aan mp3 in 489 bestanden:

code:

Executed in  719.07 millis    fish           external 
   usr time    7.36 millis  527.00 micros    6.84 millis 
   sys time   13.78 millis  113.00 micros   13.66 millis

En er zijn iets van 50 bestands extensies, dus handmatig iedere keer het mv commando geven vind ik ook niet zo fijn schaalbaar

[Hero of Time]

Jogai schreef op maandag 22 maart 2021 @ 08:09:
[...]

Dat laatste klopt niet. Hier een timing van een mv van 15361 bestanden (263 mb):

code:

Executed in   80.03 secs   fish           external 
   usr time    2.50 secs    2.39 secs  112.02 millis 
   sys time    1.32 secs    0.42 secs  898.43 millis

Hoezo zou mijn laatste opmerking niet kloppen? Je bent nu een dag verder. In het eerste uur had je al alles, of iig een hele berg, al klaar kunnen hebben.

Het is een externe SSD die ntfs is geformatteerd. Misschien is het dat laatste wel. Maar het lijkt ook wel of het niet lineair schaalt, want hier 2.6GB aan mp3 in 489 bestanden:

code:

Executed in  719.07 millis    fish           external 
   usr time    7.36 millis  527.00 micros    6.84 millis 
   sys time   13.78 millis  113.00 micros   13.66 millis

Ah, je zit op NTFS te werken. Dat gaat waarschijnlijk via ntfs-3g, middels fuse in userspace. Dat is inherent traag. Dit zou je dan beter op Windows kunnen doen via powershell oid.

En er zijn iets van 50 bestands extensies, dus handmatig iedere keer het mv commando geven vind ik ook niet zo fijn schaalbaar

Daarom script je de boel. Je schrijft eenmalig een lijstje met bestandsextenties (die je ook nog eens geautomatiseerd kan laten genereren), loopt door dat lijstje heen en verplaatst zo direct alles met die extentie naar een aparte map.

code:

for i in $extenties do
  mv *.$i $i
done

Maar dan wat optimaler zodat je niet tegen een te lange argumentlijst aan loopt.

[Jogai]

Hero of Time schreef op maandag 22 maart 2021 @ 13:47:
[...]

Hoezo zou mijn laatste opmerking niet kloppen? Je bent nu een dag verder. In het eerste uur had je al alles, of iig een hele berg, al klaar kunnen hebben.


[...]

Omdat je antwoord er in 3 minuten stond, en ik dus meerdere keren een halve tot anderhalve minuut bezig was.

Ondertussen heb ik het wel voor elkaar. Mijn vraag naar rsync was omdat die file deletes soms ook sneller doet: https://www.kinamo.be/en/...on-files-on-linux-servers

Idd, gescript, adhv:

code:

find allfiles/ -type f | sed -n 's/..*\.//p' | sort | uniq -c

(behalve txt's, daar waren er alsnog teveel van)

[ Voor 3% gewijzigd door Jogai op 22-03-2021 15:04 ]

[himlims_]

klopt; rysnc naar /dev/null gaat sneller dan delete nooit uitgezocht waarom
maar zo'n opdracht zet je toch een keer aan? boeien als ie wat langer duurt - toch eenmalig zou me niet blindstaren op optimalisatie van iets wat je als incident gebruikt

[Hero of Time]

Jogai schreef op maandag 22 maart 2021 @ 15:02:
[...]

Omdat je antwoord er in 3 minuten stond, en ik dus meerdere keren een halve tot anderhalve minuut bezig was.

3 minuten? Ik heb meer dan 3 minuten nodig gehad om je post te lezen en een antwoord te schrijven. En sinds wanneer is van 22:15 naar 23:18 maar 3 minuten ipv 63 minuten?

Ondertussen heb ik het wel voor elkaar. Mijn vraag naar rsync was omdat die file deletes soms ook sneller doet: https://www.kinamo.be/en/...on-files-on-linux-servers

Idd, gescript, adhv:

code:

find allfiles/ -type f | sed -n 's/..*\.//p' | sort | uniq -c

(behalve txt's, daar waren er alsnog teveel van)

Ik heb tijdens m'n carrière geleerd van een collega dat Python ook sneller is vergeleken met sommige acties zoals rm en mv.

Maar voor een eenmalige actie boeit het niet zo. Je wilde het beter organiseren, dat zou niet regelmatig nodig moeten zijn.

[Jogai]

Sorry, niet nauwkeurig genoeg naar de timestamps gekeken.

En idd, het is georganiseerd nu.

[himlims_]

https://pine64.com/produc...martphone/?v=0446c16e2e66 2gb ram
https://pine64.com/produc...rder-soon/?v=0446c16e2e66 3gb ram + conversion/docking kit

verkoop is zojuist live gegaan - de prijs is best wel interresant 'om het eens te avonturen' [..]

//edit; besteld @work ~230euro de 'desktop' variant

[ Voor 39% gewijzigd door himlims_ op 24-03-2021 15:59 ]

[himlims_]

https://github.com/akavel/up



geinig tooltje voor 'interactief' pipe gebruik

[himlims_]

Ben geen fan van docker-achtige systeen (vaak te bloated en 'onbeheerd' - who know what er allemaal in die contains zit). Zo kwam ik deze tegen; https://github.com/nemasu/asmttpd - een 6KB webserver is wat anders dan een docker van 800mb

[Cyphax]

himlims_ schreef op donderdag 22 april 2021 @ 10:03:
Ben geen fan van docker-achtige systeen (vaak te bloated en 'onbeheerd' - who know what er allemaal in die contains zit). Zo kwam ik deze tegen; https://github.com/nemasu/asmttpd - een 6KB webserver is wat anders dan een docker van 800mb

Hmmmmm ik zit nou net te kijken naar Docker; mijn fileserver (zo'n MicroServer van HP) heeft een vrij kale Debian-install maar ik wil 'm wat meer functies geven. Leek me Docker wel een fijne manier voor. Ik zou dit "vroeger" met een hypervisor gedaan hebben (ESXi ofzo) maar die machine is daar denk ik te licht voor. 4GB geheugen (wat ik natuurlijk wel kan uitbreiden) en een simpele dual core (Celeron G1610T).

[mithras]

himlims_ schreef op donderdag 22 april 2021 @ 10:03:
Ben geen fan van docker-achtige systeen (vaak te bloated en 'onbeheerd' - who know what er allemaal in die contains zit). Zo kwam ik deze tegen; https://github.com/nemasu/asmttpd - een 6KB webserver is wat anders dan een docker van 800mb

Dit klinkt een beetje als klok/klepel verhaal eerlijk gezegd.

Leuke side note die hier mee te maken heeft: Tiny Container Challenge: Building a 6kB Containerized HTTP Server! (asmttp verpakt in docker ).

Ik draai heel veel docker images met static sites, alpine container met nginx. Grootte van de volledige image, exclusief eigen content (die heb je in welke opstelling dan ook, met of zonder docker): 8,88MB. Mijn containers zijn met alle content maximaal 50MB eerlijk gezegd. Daarnaast is schijfruimte eerlijk gezegd zo goedkoop dat je je over een paar MB niet druk hoeft te maken. In virtuele servers speelt geheugen natuurlijk veel meer een rol. Maar containers (idle) verbruiken zo'n 2-3MB aan RAM in mijn geval. Dus ook op dat vlak is verbruik minimaal (en RAM schaling is eigenlijk gelijk als nginx verbruik buiten docker).

Het onbeheerde; je hebt zeker een punt, maar is dat specifiek iets voor docker? Je kan de discussie parallel trekken met bijv snaps, je hebt wel degelijk een afhankelijkheid van je package maintainer. Maar ik gebruik ook niet zomaar base images van jan en alleman. Zie bovenstaand nginx package, dat is gewoon een docker official container. Zegt niks dat het gegarandeerd veilig is, maar zoiets doorloopt eenzelfde procedure als bijv releases die op een nginx debian repository worden gepubliceerd.

Voor mij is hét voordeel dat je een all-in-one image hebt, een volledig pakketje inclusief alle dependencies die geheel zelfstandig kan draaien. Zonder gedoe kan ik op één server gebruik maken van diverse talen (java/php/python/node). Ik kan verschillende versies van een taal foutloos naast elkaar draaien zonder gedoe. Ik kan containers met nagenoeg 1 commando verplaatsen naar een andere server of opschalen naar meerdere instances. Uiteraard kan dit allemaal ook zonder docker, maar dat is altijd taal, versie of server-specifiek. En daardoor ben je best veel tijd kwijt om het allemaal voor al die talen & versies te onderhouden. Die last valt met docker geheel weg.

[Jogai]

@mithras Goed gezegd. En het idee is volgens mij ook dat een docker container maar 1 ding moet doen. Dus als je een database hebt draai je die in een andere container. Daarmee zou het niet 'bloated' moeten worden. Alhoewel 800 mb voor nginx-proxy-manager dan wel weer groot lijkt. Misschien toch eens controleren wat daar inzit.

[Jogai]

On that note: wat als je nu een app wil draaien waar geen container voor is. Hoe gek is het dan om een algemene container te pakken en die naar je app directory te verwijzen tov zelf een container voor die app bouwen?

[FireDrunk]

Jogai schreef op donderdag 22 april 2021 @ 14:45:
On that note: wat als je nu een app wil draaien waar geen container voor is. Hoe gek is het dan om een algemene container te pakken en die naar je app directory te verwijzen tov zelf een container voor die app bouwen?

Probleem daarmee is dat 'voortbrenging' van je service gebeurt zonder redeployment van je container.
Dat is een bad-practise.

Het is beter om je container opnieuw te maken bij elke software wijziging.

[mithras]

Jogai schreef op donderdag 22 april 2021 @ 14:45:
On that note: wat als je nu een app wil draaien waar geen container voor is. Hoe gek is het dan om een algemene container te pakken en die naar je app directory te verwijzen tov zelf een container voor die app bouwen?

Voor een dev omgeving doe ik dat vaak. Source lokaal, volume mounten in de container en met wat extra spul (auto refresh bij wijzigingen bijvoorbeeld voor web services) kan je makkelijk ontwikkelen. Voor def builds kan je je app beter verpakken in je image en daar een nieuwe versie van bakken.

Voor bestaande source code kan je een docker file maken waar je de source inlaadt (bijv github) en hem dan als image inzet.

Ik gebruik ansible voor mijn orchestration, dus een docker_container (met bestaand image), een docker_compose (met div containers die aan elkaar gerelateerd zijn) of een docker image bouwen en die direct draaien, is een hybride setup die ik gebruik afhankelijk van beschikbare software/images.

[nero355]

himlims_ schreef op donderdag 22 april 2021 @ 10:03:
Ben geen fan van docker-achtige systemen

+1

Doe mij maar gewoon VM's waar je alle kanten mee op kan!

Zo kwam ik deze tegen; https://github.com/nemasu/asmttpd - een 6KB webserver is wat anders dan al die bloated software, drivers en websites van tegenwoordig!

"There... I fixed it!"

Cyphax schreef op donderdag 22 april 2021 @ 10:33:
Ik zou dit "vroeger" met een hypervisor gedaan hebben (ESXi ofzo) maar die machine is daar denk ik te licht voor. 4GB geheugen (wat ik natuurlijk wel kan uitbreiden) en een simpele dual core (Celeron G1610T).

Als een Intel Atom 2830 NUC het kan dan kan die G1610T het ook!

Gewoon wat RAM erbij proppen en wat leuke storage en gaan met die banaan!