Het grote welk OS (bijvoorbeeld linux distro) topic deel 8

[HollowGamer]

Hero of Time schreef op zaterdag 16 april 2016 @ 20:54:
Ik dacht dat Gentoo ook een binary repo heeft die je via portage aan kan roepen, zodat je niet alles continue van source hoeft te builden?

In een relatief ver verleden heb ik Arch eens in een VM geprobeerd. Dat duurde nog geen half uur en toen was ik 't al zat. Ik had ook wat minder ervaring en kennis van Linux, maar het voelde aan alsof ik alles zelf moest gaan opgeven, idee als 'doe eerst ./configure, dan make, dan kan je een file system maken, dan moet je nog dit bouwen, dat doen, zus selecteren en he, je hebt een initrd en bijbehorende kernel, maar bootloader moet je ook nog even zelf de config schrijven'. Het kwam iig heel erg over alsof je Mount Everest moest gaan beklimmen en het enige wat ik had was een paar bergschoenen en zomerkleding. Laat staan zuurstof voor op hoogte.
En eigenlijk heb ik dat gevoel nog steeds als ik hier zo dingen over Arch hoor.

Dit niet nodig, zie de Beginners Guide, er komt geen ./configure, of andere 'ingewikkelde' dingen aan te pas.
Die handleiding + uitgebreide Wiki's zijn je hele bagage en natuurlijk je Linux-ervaring.

Zelf hoef je bijna geen stappen te doen, en heb je een Arch systeem up-and-running binnen 10/20 min (zelf met encryptie, kernel, bootloader, etc.). Als je echt niks wilt doen, zijn er genoeg scrips te vinden.

[Voor 15% gewijzigd door HollowGamer op 17-04-2016 20:17]

[begintmeta]

pcman007 schreef op zondag 17 april 2016 @ 16:21:
[...]

Nog niet eens over nagedacht om te doen, bedankt voor de suggestie. Draai jij zelf gentoo? Zo ja denk je dat dit pluspunten heeft t.o.v arch?

Ik draai zelf geen gentoo, wel een tijdje gedaan een jaar of 12 geleden schat ik. Of het een of het ander pluspunten heeft is zo niet te zeggen, want afhankelijk van je wensen kan een minpunt best een pluspunt zijn of een pluspunt een minpunt.

[GuntherDW]

Als je echt 12 jaar geleden Gentoo (was toen echt nog in de kinderschoenen IMO) draaide, raad ik het toch echt aan van nog eens te proberen.
Waar 12 jaar geleden je voor veel problemen op jezelf moest terugvallen, en er geen echte "hulp" van portage uit kwam, is er nu veel beter ondersteuning naar de gebruikers toe. Er is veel betere library en dependency handling.
Het is nu veel moeilijker om een unbootable of "kapotte" lib te krijgen, zoals bijvoorbeeld de hele "libpng" move ~10j terug.

Voor die reden zijn spullen als revdep-rebuild, wat je vroeger wel bijna elke keer je een update deed mocht doen, wordt dit nu per package nagekeken elke keer je die build.
Om diezelfde reden heb je het ook niet dat je grote emerge wel 20 keer faalt omdat een of andere library of update weer dingen molde.
Die problemen kan ik de voorbije jaren maar op 1 hand tellen.

voorbeeld : https://www.gentoo.org/su...-gcc-5-new-c++11-abi.html (al is de hele 5 branch nog altijd in ~arch)

Ik draai het zelf sinds 2005, na diskcrash van m'n Slackware install. Sindsdien kan ik eigenlijk nooit meer terug .

[Hero of Time]

HollowGamer schreef op zondag 17 april 2016 @ 16:31:
[...]

Haha, dit is helemaal niet waar. Ik raad om eerst zelf weer eens Arch te draaien in een VM, want met alle respect, dit klopt totaal niet.

Zelf hoef je bijna geen stappen te doen, en heb je een Arch systeem up-and-running binnen 10 min. Als je echt niks wilt doen, zijn er genoeg scrips te vinden.

Als je dat inderdaad niet zoekt, is een andere distro beter. Maar please, ga geen 'onzin' verspreiden, want dat wordt al genoeg gedaan.

Ik deel mijn ervaring, iets wat juist de bedoeling is van dit hele topic. Ik verkondig geen 'onzin' zoals jij dat beweert. Met je opmerking kom je nu juist over als een extremist die z'n geloof wil doordrukken en daar hebben we hier absoluut geen behoefte aan. Volgens mij heb ik je hier al eens eerder op aangesproken.

[HollowGamer]

Hero of Time schreef op zondag 17 april 2016 @ 20:01:
[...]

Ik deel mijn ervaring, iets wat juist de bedoeling is van dit hele topic. Ik verkondig geen 'onzin' zoals jij dat beweert. Met je opmerking kom je nu juist over als een extremist die z'n geloof wil doordrukken en daar hebben we hier absoluut geen behoefte aan. Volgens mij heb ik je hier al eens eerder op aangesproken.

Zet 'onzin' voor expres tussen haakjes, omdat je tuurlijk wel op een aantal dingen gelijk hebt.
Ben verder echt geen extremist, omdat ik ook graag naar andere distro's kijk en diverse heb gedraaid (en nog).

Het enige wat ik zeg is dat je echt niet ./configure hoef te draaien als je Arch installeert, al kan je dat zeker, en dat ik dit meerdere mensen hoor zeggen, zonder dat ze deze distro (volop) hebben gedraaid.
Verder vind ik je ervaring zeker interessant, zal daarom ook wat mijn comment aanpassen.

Excuses voor mijn comment.

[silverball]

Anoniem: 616444 schreef op maandag 04 april 2016 @ 18:45:
[...]
Verder mis ik nog de ' echte GNU'. Want volgens de FSF, the Free Software Foundation voldoet geen enkele hier genoemde distro aan werkelijk open source. Ook distro's zoals ook Fedora hebben kernel blobs met gesloten firmware code.

Op GNU.org "Explaining Why We Don't Endorse Other Systems" :

Debian's Social Contract states the goal of making Debian entirely free software, and Debian conscientiously keeps nonfree software out of the official Debian system. However, Debian also provides a repository of nonfree software. According to the project, this software is “not part of the Debian system,” but the repository is hosted on many of the project's main servers, and people can readily find these nonfree packages by browsing Debian's online package database and its wiki. The installer in some cases recommends these nonfree firmware files for the peripherals on the machine.

Dus volgens het FSF/ GNU clubje is het pas open-source als het de eindgebruiker zo moeilijk mogelijk wordt gemaakt om niet-vrije programmatuur te installeren....... Terwijl Debian standaard alleen volledig vrije software bevat.

openSUSE offers a repository of nonfree software.

Idem dito

Gentoo includes installation recipes for a number of nonfree programs in its primary package system.

ReactOS is meant as a free binary compatible replacement for Windows. Allowing people to continue using the proprietary software and drivers meant for Windows is one of the stated goals of the project.

[8088]

silverball schreef op zondag 17 april 2016 @ 21:19:
Dus volgens het FSF/ GNU clubje is het pas open-source als het de eindgebruiker zo moeilijk mogelijk wordt gemaakt om niet-vrije programmatuur te installeren.......

Volgens mij lees je niet goed. Dat 'clubje' keurt besturingssystemen af die (o.a.) actief opties bieden om niet-vrije software te gebruiken. Bovendien zijn free zoals bedoeld op die pagina en open source niet uitwisselbaar.

[Borromini]

HollowGamer schreef op zondag 17 april 2016 @ 20:14:
[...]

Zet 'onzin' voor expres tussen haakjes, omdat je tuurlijk wel op een aantal dingen gelijk hebt.
Ben verder echt geen extremist, omdat ik ook graag naar andere distro's kijk en diverse heb gedraaid (en nog).

Het enige wat ik zeg is dat je echt niet ./configure hoef te draaien als je Arch installeert, al kan je dat zeker, en dat ik dit meerdere mensen hoor zeggen, zonder dat ze deze distro (volop) hebben gedraaid.
Verder vind ik je ervaring zeker interessant, zal daarom ook wat mijn comment aanpassen.

Excuses voor mijn comment.

Je bedoelt het ongetwijfeld goed, maar je enthousiasme is zo gigantisch dat het alleen als een preek overkomt.

Dial it down.

[Anoniem: 438105]

GuntherDW schreef op zondag 17 april 2016 @ 18:32:
Gentoo .... Ik draai het zelf sinds 2005....Sindsdien kan ik eigenlijk nooit meer terug .

Ik hoor graag van je ervaringen. Ben altijd geintersseerd geweest in Gentoo, mag ik wat domme vragen stellen? Ik heb wél de RTFM gelezen, maar soms snap ik het veel sneller als iemand het even simpel in het Nederlands uitlegt

• E Builds: ik begrijp dat dit bash scripts zijn, een soort build files. Een verwijzing naar de broncode zit er ook in, toch? Zit er een soort check in dat je een waarschuwing krijgt dat er een nieuwe versie is (dus aangepaste broncode, bijvoorbeeld op basis van één of andere diff functie ? En hoe zit dat dan bij grote wijzigingen, waarbij bijvoorbeeld depencies zijn toegevoegd of weggehaald ?
• Klopt het dat je als package builder (of moet je maintainer zeggen ? ) in elk geval, E Build bouwer, eigenlijk "hooks" moet maken waarmee anderen dan bepaalde use of compile flags kunnen aan/uit zetten? [i]Hoeveel Ebuilds moet je zelf schrijven in de praktijk? Hoeveel is er al?
• Kun je puur "unstable" werken? Is dat "stabiel" genoeg ?
• Ik snap weinig van de repo structuur. Is er nou één centrale repo (zoals bij arch) of ook vele locale (zoals bij debian)? Hoe krijg je een Ebuild in de repo ?
• Compileer je op een laptop, of kun je beter op een vaste computer compileren en dan die binaries installeren - in verband met niet te heet opstoken van je laptop ?

Ik vraag heel veel, ik weet het! Als je tijd/ zin hebt om wat te schrijven, graag !

[Jogai]

Verkeerde topic gepost zie ik nu:

Jogai schreef op woensdag 20 april 2016 @ 08:18:
Voor mensen die meer performance uit hun intel cpu willen persen:

quote: http://clearlinux.org

We want to showcase the best of Intel Architecture technology, from low-level kernel features to complex applications that span across the entire OS stack.

Benchmarks: http://www.phoronix.com/s...em=intel-clr-opengl&num=2

[downtime]

silverball schreef op zondag 17 april 2016 @ 21:19:
Dus volgens het FSF/ GNU clubje is het pas open-source als het de eindgebruiker zo moeilijk mogelijk wordt gemaakt om niet-vrije programmatuur te installeren....... Terwijl Debian standaard alleen volledig vrije software bevat.

FSF is een ideologisch clubje die de wereld willen verbeteren. Mogelijkheden aanbieden om niet-vrije software te installeren zien ze als heulen met de vijand.

[Thedr]

Jogai schreef op woensdag 20 april 2016 @ 15:56:
Verkeerde topic gepost zie ik nu:

Jogai schreef op woensdag 20 april 2016 @ 08:18:
Voor mensen die meer performance uit hun intel cpu willen persen:

[...]

Benchmarks: http://www.phoronix.com/s...em=intel-clr-opengl&num=2

Solus OS neemt dit soort dingen ook vrij snel mee: https://solus-project.com...week-in-solus-install-26/.

[Anoniem: 438105]

Thedr schreef op woensdag 20 april 2016 @ 16:08:
[...]
Solus OS neemt dit soort dingen ook vrij snel mee: https://solus-project.com...week-in-solus-install-26/.

Solus geeft aan: we're now ensuring packages only have direct binary dependencies. Solus uses the equivalent of `-Wl,-as-needed` but at the toolchain level, these changes to eopkg now make it respect that.

Net benefit? As you can see here each package has drastically fewer dependencies, allowing more flexibility, and much, much faster repo operations (upgrade, install, search, etc.)

Ik heb even wat gegoogled, niks gevonden, Bedoelen ze gewoon static linking?

[Thedr]

Anoniem: 438105 schreef op woensdag 20 april 2016 @ 16:20:
[...]


Solus geeft aan: we're now ensuring packages only have direct binary dependencies. Solus uses the equivalent of `-Wl,-as-needed` but at the toolchain level, these changes to eopkg now make it respect that.

Net benefit? As you can see here each package has drastically fewer dependencies, allowing more flexibility, and much, much faster repo operations (upgrade, install, search, etc.)

Ik heb even wat gegoogled, niks gevonden, Bedoelen ze gewoon static linking?

Ik denk het wel, hoewel ik zelf geen held ben op dat gebied. Ik denk dat andere hier wellicht meer over kunnen vertellen.
Mijn reactie was bedoeld op een stuk wat later aan bod komt:

PERFORMANCE GUIDED OPTIMIZATIONS

We have now integrated performance guided optimizations directly into our build process. What does this mean? A more powerful, flexible, leaner and meaner Solus. This work was inspired by the work done by the Clear Linux* Project for Intel® Architecture project.

Here are some performance metrics / benchmarks for libxml2:
First set of changes hit libxml2: http://openbenchmarking.org/result/1604106-GA-1604100GA01
Gains in xz decompression: http://openbenchmarking.org/result/1604107-GA-1604102GA92

[Ryatzu]

Thedr schreef op woensdag 20 april 2016 @ 16:08:
[...]


Solus OS neemt dit soort dingen ook vrij snel mee: https://solus-project.com...week-in-solus-install-26/.

Dit komt omdat de maker van Solus OS bij intel werkt aan Intel Clear Linux.
Vrij snel... je bedoeld eigenlijk direct

En als ik het goed heb is er gisteren een lading updates doorgevoerd.

[Voor 9% gewijzigd door Ryatzu op 21-04-2016 10:35]

[Thedr]

Jup, Ikey ramt goed door. En was bij mij idd ook bekend dat hij voor Intel werkt, blijft iig mooi dat ze bij Solus een gezonde hekel hebben aan legacy en nieuwe mogelijkheden willen benutten

[Anoniem: 438105]

Even naar Solus gekeken. Ziet er interessant uit. Maar ik vraag me wel dingen af. Is een klein zelfstandig project in staat om een hele distro levend te houden? Inclusief alle packages enzovoorts? Ook grote distros als Debian, Gentoo, Arch "worstelen" om de repos te vullen en up to date te houden.

Ik ben wel overtuigd geraakt door Donnie Berkholz (RedMonk, ex (?) Gentoo dev.) die vindt dat we afmoeten van packages per distribution.

Ben wel heel nieuwsgierig naar de specifieke Interl-optimalisaties. Iemand ervaring met Solus ?

[GuntherDW]

Anoniem: 438105 schreef op woensdag 20 april 2016 @ 15:31:
[...]

Goed, ik zal concise antwoorden proberen geven, al zijn je vragen nogal vaag, maar dat is waarschijnlijk omdat je nog geen hands-on ervaring hebt met gentoo. Tegenwoordig is zo'n install maken in een VM niet zo moeilijk. Al is als je het nog nooit gedaan hebt een kernel compile/config misschien wat moeilijk en tijdvergend, maar je hebt wel wat scriptjes die je initieel wat snel erdoor helpen, zodat je erna eens je een volledig systeem hebt je daarmee deftig kan bezighouden, terwijl je materiaal kan opzoeken op de PC zelf.

Een groot deel kan je trouwens ook gewoon vanaf de LiveCD doen in die chroot, je kan zo ook leren omgaan met portage zelf.

• E Builds: ik begrijp dat dit bash scripts zijn, een soort build files. Een verwijzing naar de broncode zit er ook in, toch? Zit er een soort check in dat je een waarschuwing krijgt dat er een nieuwe versie is (dus aangepaste broncode, bijvoorbeeld op basis van één of andere diff functie ? En hoe zit dat dan bij grote wijzigingen, waarbij bijvoorbeeld depencies zijn toegevoegd of weggehaald ?

Het zijn niet echt bash scripts. Ebuilds, en eigenlijk portage, als je de default package manager (emerge) gebruikt is volledig in python geschreven. De syntax lijkt eerder op een bash script, daar heb je gelijk in, maar het zijn geen bash scripts.
Je krijgt geen "waarschuwing" dat er een nieuwe versie is, de ebuilds wijzen specifiek naar een versie. In de Manifest file staan dan de hashes van die files (en de ebuilds), zodat portage kan zien of er corruption op de files is geraakt tussendoor.

Ik snap je vraag niet echt qua dependancies weggehaald/toegevoegd. Daar hoef je je enkel echt druk om te maken als je zelf ebuilds gaat schrijven/maintainen. Als "gewone user" hoef je je daar niet echt druk om te maken.

De standaard procedure om een Gentoo systeem volledig te updaten is een "emerge --deep --update --newuse @world", met daarna een "emerge --depclean". (Al lees je best héél goed de output van de depclean na voor je het laat doorgaan!).

• Klopt het dat je als package builder (of moet je maintainer zeggen ? ) in elk geval, E Build bouwer, eigenlijk "hooks" moet maken waarmee anderen dan bepaalde use of compile flags kunnen aan/uit zetten? \

Je bent wat in de war met het hele flags gebeuren heb ik de indruk, dus zal misschien wat verduidelijking geven.

USE flags zijn flags wat je "globally" (in make.conf) of per package (in packages.use) kan aan/afzetten.
Je gebruikte profile zorgt er ook voor dat bepaalde USE flags aan/af gezet worden.

USE flags kan je echter gewoon het makkelijkste zien als "checks" voor functionality in een bepaalde programma of library.
Als je bijvoorbeeld geen X wil op je server, kan je het makkelijkste dan de X flag disablen in make.conf door "-X" toe te voegen aan de lijst.
Hierdoor zal dan elke package die de X use flag heeft weten dat je geen X bindings/tools/... wil. Zo krijg je dus ook minder dependancies en een kleinere build in total.
Het omgekeerde kan je natuurlijk ook doen. Als je bijvoorbeeld liever libressl dan openssl gebruikt, of pulseaudio, kan je dat weer ofwel per package instellen, of globaal in make.conf.

"hooks", ik geloof dat je de hele src_compile(), src_prepare() e.d. bedoelt in de ebuild files?
Ik zou het geen hooks noemen, maargoed. USE flags hebben hier eigenlijk weinig mee te zien. USE flags worden gewoon gebruikt om bepaalde functionality aan jouw bepaalde wensen te laten voldoen.

Het nadeel echter bij Gentoo is dat je veel package maintainers hebt, die dan elks hun eigen manier hebben van werken. Echter zijn de grote lijnen hetzelfde overall. Met name dan zoals ik aanhaalde "X" of "pulseaudio".

[i]Hoeveel Ebuilds moet je zelf schrijven in de praktijk? Hoeveel is er al? [/li]

Vrij weinig, tot eigenlijk geen. In portage zelf zit al héél veel, en dan voor bepaalde andere software is er software als "layman", welke het makkelijk maakt van populaire overlays toe te voegen aan je portage tree.
In de recente portage versies is het hele layman verhaal zelfs nog makkelijker gemaakt. Een "emerge --sync" update ook ineens al je remote layman repo's. Bespaart je wat tijd van elke keer ook je layman overlays te sync'en.

https://wiki.gentoo.org/wiki/Layman

Echter moet je altijd in het achterhoofd houden dat overlays die je gebruikt unsupported zijn. Je zal als je problemen hebt met een bepaalde ebuild wel nog op het Gentoo forum terecht kunnen, maar enige bugs die komen door die bepaalde overlay hoeven de main developers zich niet echt aan te trekken. Je zal je dus moeten wenden tot de overlay maintainer. Echter komen die dingen vrij weinig voor, als je maar weet waar je moet kijken.

Als het niet in portage & de overlays zit zal je het inderdaad wel zelf moeten gaan schrijven. Echter zijn er genoeg guides hierover online te vinden, en hoef je echt bar weinig maar in een ebuild te zetten voor het te laten werken. Veel dingen die je in de ebuilds ziet van de "grote" package maintainers zijn optioneel.

• Kun je puur "unstable" werken? Is dat "stabiel" genoeg ?

"~arch", dus unstable is de voorbije jaren veel stabieler geworden dan in 2005, maar het blijft echter "unstable". Je gaat dus vaker problemen krijgen dan iemand die stable draait, omdat die software dan weer meer getest door mensen die "~arch" draaiden.
Als je het niet erg vindt van wat opzoekwerk nu en dan te doen en bugs.gentoo.org (en eigenlijk dus google) te gebruiken, is ~arch zeker goed te gebruiken.
Echter moet je in het achterhoofd houden dat ze breaking changes kunnen pushen in "~arch", waar dat veel minder vaak gebeurt in "arch".

Een mooi heel recent voorbeeld is de glibc debacle door een dev die "iets" te enthousiast was...
https://forums.gentoo.org...highlight-mesa+glibc.html
Dit toont wel aan dat er ook in Gentoo veel drama te zien valt, maargoed .

• Ik snap weinig van de repo structuur. Is er nou één centrale repo (zoals bij arch) of ook vele locale (zoals bij debian)? Hoe krijg je een Ebuild in de repo ?

Portage an sich, at least volgens de package managers is 1 grote hoop. Een beetje zoals debian dus.
Overlays die je toevoegd door middel van tools als layman, of je eigen local overlay maken "een groot geheel".

Je kan het best vergelijken met de debian structuur. Je hebt 1 grote "main" repo, waar iedereen aan kan toevoegen met z'n eigen kleinere repo's.

https://wiki.gentoo.org/wiki/Overlay

Het maakt dus niet uit in welke overlay het zit als je een bepaalde package installeert.
Stel dat je van programma X in de main repo "1.0" ziet staan, maar jij wil bijvoorbeeld nu al, voordat het in de repo's zit "1.1" gebruiken.
Als je dan je eigen ebuild in je eigen overlay zet, die digest en "emerge x" typt, zal je zien dat hij mooi de ebuild uit je overlay neemt. (tenzij natuurlijk dingen als blockers en andere soort grappen)

Als je een bepaalde ebuild "upstream" wil krijgen, dus in portage kan je best een report aanmaken in bugs.gentoo.org, afgekort bgo. Echter heb je weinig kans dat iemand zomaar je ebuilds aanpakt, ziende dat veel maintainers al hun handen vol hebben.
Als er echter een nieuwe versie van een bepaald programma is dat nog niet in portage zit, kan je de ebuild aanpassen, en voor dit een report aanmaken. Deze zal wel iets sneller aangepakt worden.

• Compileer je op een laptop, of kun je beter op een vaste computer compileren en dan die binaries installeren - in verband met niet te heet opstoken van je laptop ?

Er zijn veel opties met betrekking tot builden. Gentoo is heel versatile in dat aspect.
In de embedded wereld wordt vooral vaak iets gebruikt wat in de volksmond een "stage4" noemt.

Hierbij compilen ze dan alles op hun vrij krachtige desktop, waarna ze dan een image maken van die directory, en gewoon op hun embedded device zetten.

Er zit echter ook native support voor Distcc in portage. Hierbij kan je dan als je wil meerdere hosts inzetten voor het simultaan mee helpen compilen van je packages over het netwerk.
https://wiki.gentoo.org/wiki/Distcc
Je kan het ook zo instellen dat elke keer je compilet je alles door je andere machines laat doen via Distcc, Het is allemaal mogelijk.

Ik persoonlijk liet het gewoon allemaal op de laptop zelf compileren, omdat ik die vaak enkel gebruikte als ik school zat. Thuis stond die laptop amper aan. Echter kan je voor jezelf als je de resources hebt je hele netwerk mee laten compiler met behulp van die distcc. Hierover staan wel een hoopje guides op het forum of de wiki waarschijnlijk.

-----

Je hebt echter wel veel vraag naar "eigen ebuilds schrijven". Ik zou persoonlijk toch aanraden van eerst je weg te vinden in Gentoo, voor je daar aan gaat denken. Ik ken genoeg mensen die jarenlang Gentoo gedraaid hebben zonder ook maar 1 ebuild te hebben moeten schrijven.
Het is voor mij persoonlijk ook lang geleden dat ik echt specifiek m'n eigen ebuilds moest schrijven.

Als het je echter gaat om "user provided patches" bijvoorbeeld, dan kan je dat tegenwoordig ook doen zonder je eigen ebuilds te hoeven shrijven.
https://wiki.gentoo.org/wiki//etc/portage/patches
Long story short, als je een bepaalde patch vind op bgo, is het vrij simpel om die toe te voegen.
https://bugs.gentoo.org/show_bug.cgi?id=574044#c3

Als je die file dan in "/etc/portage/patches/sys-devel/gcc-5.3.0/" gooit, zal ze meegenomen worden als je die specifiek versie van GCC compileert.

Ik heb je ook een paar keer de Gentoo wiki links gegeven, ik raad je aan van die ook eens wat door te bladeren. Er zit echt een schat van informatie in de wiki.
Echter ben ik zoals je waarschijnlijk wel kon lezen vrij slecht in het schrijven van grote lappen tekst, dus als iets niet duidelijk genoeg is hoor ik het wel .

Anoniem: 438105 schreef op donderdag 21 april 2016 @ 13:13:
Ik ben wel overtuigd geraakt door Donnie Berkholz (RedMonk, ex (?) Gentoo dev.) die vindt dat we afmoeten van packages per distribution.

Ach, het heeft beide z'n voordelen en nadelen. In Gentoo zijn er voor veel packages patches en added functionality die het geheel beter laat samenwerken. initscripts zijn het beste voorbeeld, maar het kan ook gewoon iets futile zijn als een patch voor een bepaalde directory structuur aan te passen dat het programma verwacht.

De ietofwat grotere packages als wine, GCC, Glibc e.d. hebben echt een hele resem aan patches, wat geloof ik niet veel anders is bij andere distro's als Debian.

Het is inderdaad veel tijdverspilling om hetzelfde werk te blijven doen voor 200 verschillende distro's, dat heb je wel.

Als je zulke discussies leuk vindt raad ik je de "Linux sucks" talks aan van Bryan Lunduke. Die geeft altijd een mooi opiniestuk en laat beide kanten hun verhaal doen.
YouTube: "Linux Sucks" - 2016 is de talk van dit jaar.

[Voor 11% gewijzigd door GuntherDW op 21-04-2016 14:19]

[Ryatzu]

Anoniem: 438105 schreef op donderdag 21 april 2016 @ 13:13:
Even naar Solus gekeken. Ziet er interessant uit. Maar ik vraag me wel dingen af. Is een klein zelfstandig project in staat om een hele distro levend te houden? Inclusief alle packages enzovoorts? Ook grote distros als Debian, Gentoo, Arch "worstelen" om de repos te vullen en up to date te houden.

Ik ben wel overtuigd geraakt door Donnie Berkholz (RedMonk, ex (?) Gentoo dev.) die vindt dat we afmoeten van packages per distribution.

Ben wel heel nieuwsgierig naar de specifieke Interl-optimalisaties. Iemand ervaring met Solus ?

Ik heb er wat ervaring mee, tevens gebruik mijn vrouw het op haar laptop sinds dit wekend.
Alles werkte out of the box, en tot nu toe 0 problemen mee gehad. Ze gebruikt de laptop voornamelijk voor browsen en office. Overigens als er een package niet bestaat dan kan je dit aan ze doorgeven, meestal kijken ze direct of binnen een paar dagen ernaar of ze er een package van zullen maken.

Ligt vaak aan de licentie en/of wat voor software het is.

[Anoniem: 438105]

GuntherDW schreef op donderdag 21 april 2016 @ 14:14:Echter ben ik ....vrij slecht in het schrijven van grote lappen tekst, dus als iets niet duidelijk genoeg is hoor ik het wel .

WOW! Wat een antwoord, dank voor je tijd! En eh....dit noem jij dus slecht in het schrijven van grote lappen tekst ??

Mijn vragen waren inderdaad naar het schrijven van E Builds...mooi dat dit eigenlijk nooit hoeft.

GuntherDW schreef op donderdag 21 april 2016 @ 14:14:
In portage zelf zit al héél veel, en dan voor bepaalde andere software is er software als "layman", welke het makkelijk maakt van populaire overlays toe te voegen aan je portage tree. In de recente portage versies is het hele layman verhaal zelfs nog makkelijker gemaakt. Een "emerge --sync" update ook ineens al je remote layman repo's. Bespaart je wat tijd van elke keer ook je layman overlays te sync'en.

Als het niet in portage & de overlays zit zal je het inderdaad wel zelf moeten gaan schrijven. Echter zijn er genoeg guides hierover online te vinden, en hoef je echt bar weinig maar in een ebuild te zetten voor het te laten werken. Veel dingen die je in de ebuilds ziet van de "grote" package maintainers zijn optioneel.

Kijk, hier word ik blij van.

GuntherDW schreef op donderdag 21 april 2016 @ 14:14:
"~arch", dus unstable is de voorbije jaren veel stabieler geworden dan in 2005, maar het blijft echter "unstable". Je gaat dus vaker problemen krijgen dan iemand die stable draait, omdat die software dan weer meer getest door mensen die "~arch" draaiden. Als je het niet erg vindt van wat opzoekwerk nu en dan te doen en bugs.gentoo.org (en eigenlijk dus google) te gebruiken, is ~arch zeker goed te gebruiken. Echter moet je in het achterhoofd houden dat ze breaking changes kunnen pushen in "~arch", waar dat veel minder vaak gebeurt in "arch".

Ook al weer goed nieuws.

GuntherDW schreef op donderdag 21 april 2016 @ 14:14:
Ik heb je ook een paar keer de Gentoo wiki links gegeven, ik raad je aan van die ook eens wat door te bladeren. Er zit echt een schat van informatie in de wiki.

Zeker, heb al veel gelezen maar zoals vaak moet je het gewoon gaan doen om te begrijpen. Tot nu toe hield koudwatervrees me tegen.

GuntherDW schreef op donderdag 21 april 2016 @ 14:14:
Als je zulke discussies leuk vindt raad ik je de "Linux sucks" talks aan van Bryan Lunduke. Die geeft altijd een mooi opiniestuk en laat beide kanten hun verhaal doen.
YouTube: "Linux Sucks" - 2016 is de talk van dit jaar.

Zal weer eens kijken! Hij deed vroeger toch ook de Linux Action Show? Zie nu tot mijn verrassing dat hij in de openSuse board zit en ook werkt voor Suse.

Nogmaals dank dat je me verder naar de Dark Side hebt geduwd...

[Thedr]

Anoniem: 438105 schreef op donderdag 21 april 2016 @ 13:13:
Even naar Solus gekeken. Ziet er interessant uit. Maar ik vraag me wel dingen af. Is een klein zelfstandig project in staat om een hele distro levend te houden? Inclusief alle packages enzovoorts? Ook grote distros als Debian, Gentoo, Arch "worstelen" om de repos te vullen en up to date te houden.

Ik ben wel overtuigd geraakt door Donnie Berkholz (RedMonk, ex (?) Gentoo dev.) die vindt dat we afmoeten van packages per distribution.

Ben wel heel nieuwsgierig naar de specifieke Interl-optimalisaties. Iemand ervaring met Solus ?

Ik klooi er ook wat mee in een VM, en ook al eens op een oude pc geinstalleerd (+/- 10jr oude AMD Athlon 64 geloof ik) en ook daarop draaide het ok. Daarnaast volg ik Solus/Ikey op Google+ (sowieso een leuk figuur en community).
Ben momenteel nog steeds happy met elementary OS, maar kijk ook regelmatig met een schuin oog naar andere OSs zoals Solus. Budgie trekt me ook wel, zeker met Raven ziet het er erg god uit. Het enige wat me nog wat tegenstaat (het gebrek aan) een goed workspacemanagement.

[GuntherDW]

PieterGen, ik raad je toch eigenlijk aan van het eens totaan de kernel bouwen in een VM te proberen.
Als je echt in een experimenteer fase zit kan je ook Funtoo proberen. Funtoo is eigenlijk van de originele maker van Gentoo (daniel), maar is een tijdje voor MS gaan werken, en toen hij terug kwam wouden ze z'n radical changes niet echt vreten voor in Gentoo, dus startte hij maar z'n spinoff .
Het zijn eigenlijk bijna dezelfde distro's, met alleen wat subtle changes en apartheiden voor beide distro's.

Dat hele compileren lijkt initieel misschien niet zo'n hassle, maar er zijn veel mensen die het na een tijdje toch vrij irritant beginnen te vinden. Vooral de grotere dan zoals libreoffice & chromium. Both zijn wel in binary package vorm in portage te vinden, maar het blijft een time sink.
Tof dat je ook Gentoo wil proberen, een van de enige grote distro's die nog overblijft waar je niet vastzit aan systemd zonder aparte unsupported repo's te draaien :3.

[Anoniem: 438105]

GuntherDW schreef op donderdag 21 april 2016 @ 16:02:
Als je echt in een experimenteer fase zit kan je ook Funtoo proberen.

Dat hele compileren ......blijft een time sink.

Tof dat je ook Gentoo wil proberen, een van de enige grote distro's die nog overblijft waar je niet vastzit aan systemd zonder aparte unsupported repo's te draaien :3.

- Funtoo heb ik wat naar gekeken, maar lijkt een kleinere / minder actieve community te hebben.
- Wat is jouw ervaring, op de langere termijn, met het compileren ?
- Gentoo kun je idd zonder systemd draaien. Hoewel ik niks tegen systemd heb, de argumenten van Lennart zijn voor mij wel overtuigend en in mijn praktijk (desktop use, tot nu toe archlinux) bevalt het me prima. Mogelijk dat het voor servers minder goed te debuggen e.d. is.

Voor mij lijkt een pré van Gento: de packagemanager (rollbacks zijn te doen e.d.) en het slank houden van applicaties dmv flags.

[GuntherDW]

Oh, je kan gerust je profile instellen op een systemd profile hoor. Maar dat bedoel ik dus net. Als je wil is de optie er. Je zit niet vast aan wel of niet zoals bij zovele andere grote distro's die de keuze al gemaakt hebben voor je.

Maar voor dingen als dit zijn dus wat ik bedoelde met profiles net handig. Het zorgt erdoor dat bepaalde packages (un)masked worden, USE flags aan/af gezet zonder dat je manueel een hele hoop hoeft te doen.
Er is genoeg keuze .

code:

guntherdw@lisa ~ $ eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/13.0
  [2]   default/linux/amd64/13.0/selinux
  [3]   default/linux/amd64/13.0/desktop
  [4]   default/linux/amd64/13.0/desktop/gnome
  [5]   default/linux/amd64/13.0/desktop/gnome/systemd
  [6]   default/linux/amd64/13.0/desktop/kde
  [7]   default/linux/amd64/13.0/desktop/kde/systemd
  [8]   default/linux/amd64/13.0/desktop/plasma *
  [9]   default/linux/amd64/13.0/desktop/plasma/systemd
  [10]  default/linux/amd64/13.0/developer
  [11]  default/linux/amd64/13.0/no-multilib
  [12]  default/linux/amd64/13.0/systemd
  [13]  default/linux/amd64/13.0/x32
  [14]  hardened/linux/amd64
  [15]  hardened/linux/amd64/selinux
  [16]  hardened/linux/amd64/no-multilib
  [17]  hardened/linux/amd64/no-multilib/selinux
  [18]  hardened/linux/amd64/x32
  [19]  hardened/linux/musl/amd64
  [20]  hardened/linux/musl/amd64/x32
  [21]  default/linux/uclibc/amd64
  [22]  hardened/linux/uclibc/amd64

[Ploink]

Ik zit nog met een paar vragen voor het (her)installeren van een Linux server.
Sinds 1999 draai ik een headless server, dus zonder keyboard/muis/monitor/dektop, met Redhat/Fedora (nu F23). Ik heb in al die jaren 2 of 3 keer een clean install gedaan, verder alleen live upgrades via yum en af en toe nieuwe hardware.

Het is voornamelijk een fileserver (samba) en mailserver (courier-mta waarvoor ik zelf de rpm's compileer).

Nu heb ik onlangs een SSD aangeschaft en had ik een probleempje met sata hotplug, dus heb besloten om opnieuw te installeren, maar wat?
Kan ik ook meteen over op UEFI/GPT/64bit.

Ik twijfel om over te stappen op een Debian gebaseerde distro omdat die het meest gangbaar is op de dektop en ik niet voor alles twee systemen hoef te kennen, want er zijn toch best wat verschillen tussen .deb en .rpm distro's.

Fedora is me soms ook wat te bleeding edge (o.a. #@$% systemd toen Fedora ons dat door de strot duwde inclusief nare bugs ) Aan de andere kant heeft Fedora wel recente kernels en btrfs tools en wil ik overstappen op btrfs voor backups met btrfs send/receive en snapshots. Daarvoor is btrfs stabiel genoeg nu denk ik.

Welke distro raden jullie aan?
En dan nog de desktop kwestie... kan het nog wel zonder vandaag de dag of moet ik mijn meterkast servertje dan maar via VNC benaderen ipv SSH?

[FireDrunk]

Ik doe vrij vaak Fedora Main release -1. Dan heb je wel de moderne kernels en updates, maar is het niet mega bleeding edge. Als je RPM based wil maar niet bleeding edge, blijven alleen CentOS en ScientificLinux over gok ik?

CentOS is bewust iets conservatiever. Als je wel updates wil voor specifieke doeleinden, maar niet bleeding edge wil, zit je natuurlijk in patsstelling..

[gekkie]

Kernel zelf compileren is ansich niet moeilijk .. (en als je de config tailored voor jouw hardware en wensen dan duurt het ook niet lang (heb op m'n phenom x6 in een minuutje of 5 a 10 een nieuwe kernel gebakken). (met make-kpkg heb je zo een stapel kernel .debs vanuit upstream git)


Weet niet of btrfs-tools package veel dependencies op bepaalde recente versies van andere packages heeft, anders zou je die wellicht ook zelf kunnen compileren vanuit testing of unstable.
(met debuild of dpkg-buildpackage heb je zo packages gerecompiled voor jouw release).

En waarom zou een server niet zonder desktop kunnen ?.. tis toch geen MS-Windows (al lijkt RedHat steeds meer graag die kant op te willen .. en MS juist weer richting CLI voor servers).

[CAPSLOCK2000]

Ik weet niet wat de stand van zaken is met btrfs onder CentOS maar als dat goed genoeg is denk ik dat die distro het beste bij past.

Een GUI heb je nog steeds niet nodig, ik ken geen enkele goede Linux-beheerder die z'n servers via een GUI configureert. Je kan alles via de CLI en vaak is dat de beste manier.

[FireDrunk]

CentOS 7:

[root@puppet ~]# uname -a
Linux puppet 3.10.0-327.13.1.el7.x86_64 #1 SMP Thu Mar 31 16:04:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[root@puppet ~]# btrfs --version
btrfs-progs v3.19.1

3.19.1 is zeker niet de nieuwste versie, maar ook niet extreem oud. Ze zitten nu op 4.5.1 4.5.2.
Persoonlijk zou ik liever Fedora draaien icm BTRFS, toch net wat nieuwere kernels en BTRFS progs.

Changelog hier: https://btrfs.wiki.kernel.org/index.php/Changelog

[Voor 38% gewijzigd door FireDrunk op 06-05-2016 12:54]

[Ploink]

Fedora is zelf ook BTRFS ontwikkelaar en Fedora Main release -1 zoals FireDrunk zegt vind ik een goede optie. Centos is me weer net iets te conservatief.

Dat het nog steeds goed mogelijk is om een server zonder desktop te draaien stelt me weer gerust
RH/Fedora had vroeger diverse textmode config tools gebaseerd op ncurses en die zijn zowat allemaal uitgefaseerd of niet meer up2date, maar ik ben toch wel gewend om config files te editen.

Ik zie dat kernel en btrfs inderdaad recenter zijn bij fedora en wat dat betreft.... better the devil you know

En voor wat betreft Linux op mijn desktop computer... als ik me als domme gebruiker gedraag en met de GUI tools leer omgaan is Mint ook best.

[Hero of Time]

Grapjas. Mare, als er iets is dat echt zo nodig een GUI moet hebben, kan je ook gewoon via SSH met X-forwarding de zooi draaien. Heb je geen hele GUI nodig.

[d1ng]

Ik denk dat openSUSE Leap beter bij je past dan CentOS of Fedora. Je krijg tevens btrfs in de default install (net als bij SLES). Het feit dat Leap gebaseerd is SUSE Linux Enterprise betekent dat je een robuuste en stabiele omgeving krijgt. Nieuwer dan CentOS (maar minstens net zo stabiel), en dus stabieler als Fedora. En ook nog RPM based.

vm08:~ # btrfs --version
btrfs-progs v4.1.2+20151002

vm08:~ # uname -r
4.1.15-8-default

[Voor 6% gewijzigd door d1ng op 06-05-2016 18:22]

[Hero of Time]

Leuk, RPM based, maar dat is geen enkele garantie dat een CentOS of Fedora RPM gaat werken op SuSE.

[d1ng]

Waarom zou je perse een CentOS of Fedora RPM op SUSE willen draaien?

[gekkie]

Neh als we dan toch gaan patsen met versie nummers ... bij Debian Stable heb je de keuze uit oud of hip en happening met een backport:
jessie 3.17-1.1
jessie-backports 4.4.1-1.1~bpo8+1

[Hero of Time]

d1ng schreef op vrijdag 06 mei 2016 @ 19:00:
Waarom zou je perse een CentOS of Fedora RPM op SUSE willen draaien?

Omdat je soms alleen een RPM kan vinden voor die distro's. En dat probleem heb je met Debian ook wel eens, tof pakket gevonden en dan bieden ze naast de broncode alleen een CentOS RPM aan. Daar heb je uiteindelijk ook niets aan.

[Borromini]

Lang leve alien .

[silverball]

Je kan natuurlijk ook voor Oracle Linux gaan, die direct van RHEL afkomt, maar wel van die hippigheden heeft als "Unbreakable Enterprise Kernel" wat ook eens toevallig een recentere kernel is met allerlei optionele Oracle adjectieven zoals Ksplice (veel kernel updates zonder reboots)

[Hero of Time]

Borromini schreef op vrijdag 06 mei 2016 @ 19:24:
Lang leve alien .

Alien is geen heilige graal, maar een last resort.

silverball schreef op vrijdag 06 mei 2016 @ 21:31:
Je kan natuurlijk ook voor Oracle Linux gaan, die direct van RHEL afkomt, maar wel van die hippigheden heeft als "Unbreakable Enterprise Kernel" wat ook eens toevallig een recentere kernel is met allerlei optionele Oracle adjectieven zoals Ksplice (veel kernel updates zonder reboots)

Ik heb zeer slechte ervaringen met UEK icm OEL5. Dat zogenoemde 'unbreakable' was nog fragieler dan kristal. Nou was het ook icm OCFS2, en ironisch genoeg is dat juist weer van Oracle. Het was zo erg, als je er maar aan dacht of naar keek viel er wat om op de server.

Ik zou OEL alleen gebruiken als je ook daadwerkelijk Oracle Database draait en dan nog vind ik het twijfelachtig. Enige voordeel is dat je updates kan krijgen zonder support contract voor het OS en toch nog ondersteuning op je database.

[Borromini]

Was een grapje/luchtige opmerking... Zie de smiley

[gekkie]

Hrrmm dell server tool meuk is ook een allegaartje aan oude semi ooit community based zooi wat nu niet echt meer vlot lijkt te werken en alle documentatie is al even hopeloos. bweh.

[silverball]

Hero of Time schreef op vrijdag 06 mei 2016 @ 22:49:


Ik heb zeer slechte ervaringen met UEK icm OEL5. Dat zogenoemde 'unbreakable' was nog fragieler dan kristal. Nou was het ook icm OCFS2, en ironisch genoeg is dat juist weer van Oracle. Het was zo erg, als je er maar aan dacht of naar keek viel er wat om op de server.

Ik zou OEL alleen gebruiken als je ook daadwerkelijk Oracle Database draait en dan nog vind ik het twijfelachtig. Enige voordeel is dat je updates kan krijgen zonder support contract voor het OS en toch nog ondersteuning op je database.

Hmmz, klonk allemaal wel interessant om te proberen, denk dat ik het dan maar oversla.

[Hero of Time]

silverball schreef op vrijdag 06 mei 2016 @ 23:03:
[...]

Hmmz, klonk allemaal wel interessant om te proberen, denk dat ik het dan maar oversla.

Oh, het zal best prima werken. In mijn situatie loste het niets op en gaf het alleen maar problemen. Maar OCFS2 is van zichzelf al redelijk brak, daar hoef je al niet veel voor te doen om fouten te krijgen.
Ik vond het ergste nog wel dat ik eerst helemaal niet door had dat we de UEK draaide. Tijdens installatie werd er helemaal niets gevraagd of wat dan ook, er werd gewoon de UEK op geflikkerd ipv de standaard kernel. Kostte ons uiteindelijk ruim 2 dagen voordat het opgelost was (ik moest van m'n manager destijds weekend houden omdat ik het weekend bijna non-stop had gewerkt; hardware migratie).

[silverball]

Hero of Time schreef op vrijdag 06 mei 2016 @ 23:24:
[...]

Oh, het zal best prima werken.

Naja als dat UEK niet zo onbreekbaar is, dan heeft het waarschijnlijk niet zoveel meerwaarde tov centos.

[Hero of Time]

Enige voordeel wat je hebt, is dat je een nieuwere kernel draait. Plus eventuele patches en andere zooi dat Oracle erin gooit, wat Red Hat mogelijk nooit zou doen (afhankelijk van de patches uiteraard).

[Borromini]

silverball schreef op vrijdag 06 mei 2016 @ 23:03:
[...]

Hmmz, klonk allemaal wel interessant om te proberen, denk dat ik het dan maar oversla.

Alleen al door het feit dat Oracle als gehaaid miljardenbedrijf simpelweg Red Hat zijn spul kopieert is voor mij reden genoeg om het links te laten liggen...

[begintmeta]

Spullen kopieren hoort op zich toch wel een beetje bij Linux, en zelfs Oracle heeft wel wat Linux-developers. wel wat minder dan wellicht mogelijk (of gewenst) zou zijn, en veel minder dan miljardenbedrijf RedHat maar toch.

Ik zou het ook niet snel gebruiken, maar mijn steekproefjes lieten zien dat ze de RHEL-kloon zijn die het snelste updates trackt, dus daarvoor is het een overweging waard.

[Voor 28% gewijzigd door begintmeta op 07-05-2016 09:19]

[Ploink]

Hero of Time schreef op vrijdag 06 mei 2016 @ 19:08:
[...]

Omdat je soms alleen een RPM kan vinden voor die distro's. En dat probleem heb je met Debian ook wel eens, tof pakket gevonden en dan bieden ze naast de broncode alleen een CentOS RPM aan. Daar heb je uiteindelijk ook niets aan.

Vaak zit er bij de source dan een .spec file waarmee je zelf een verse RPM kan compileren.

$ rpmbuild -ta broncode.tar.z

Er is ook een truukje om even alle build dependencies te installeren voor een gegeven spec file, maar die weet ik even niet uit het hoofd.

@d1ng: Zal nog eens kijken naar openSUSE.

[Voor 3% gewijzigd door Ploink op 07-05-2016 13:17]

[CAPSLOCK2000]

SUSE is inderdaad een goede tip, die was me even ontglipt, dat gebeurt me helaas wel vaker want SUSE is eigenlijk best wel goed. Als je dan toch een GUI wil om je systeem te beheren dan is het misschien wel de beste keuze.

Oracle moet je van wegblijven. Dat bedrijf is zo vervelend dat je alleen om die reden al hun software niet wil gebruiken. Blijf er van weg als je kunt, als ze je eenmaal te pakken hebben dan wordt het een dure grap.

[Voor 33% gewijzigd door CAPSLOCK2000 op 07-05-2016 14:36]

[Hero of Time]

Voor OEL valt dat echt wel mee, Capslock. Ze hebben gewoon een publieke repo waar je updates uit kan halen, iets wat je met Red Hat niet hebt. Dan moet je naar CentOS of Scientific gaan.

[gekkie]

Opensource spul van Oracle zal nog wel meevallen .. ook de oss-engineers die er werken waar ik tot nu toe mee te maken heb gehad zijn wel geschikte lui. De database kant en mannen in pak daar kun je voor zover ik de verhalen ken idd maar beter ver weg van blijven voordat je zelf alleen nog een adamskostuum draagt.

[MewBie]

Ik zou graag wat input willen voor mijn situatie.

Op het moment heb ik een laptop die dual boot Windows 7 en Lubuntu draait als hoofd computer en een Qnap TS-419P+ voor de nodige bulk opslag. De beperking waar ik momenteel tegen aanloop is dat mijn laptop te weinig schijfruimte heeft om een PostGIS database (5GB aan data) te draaien en mijn NAS geen PostGIS kan draaien.

Nu heb ik nog mijn voormalig desktop staan die ik eigenlijk niet meer gebruik.
Belangrijkste specs:
- Intel Core2Duo 6420
- 2GB DDR2 ram
- nVidia 8600GTS
- Diverse sata HDD's waaronder 2x WD Caviar 320GB en 2x WD Black 1TB.
Wat moet dit systeem gaan doen:
- PostgeSQL + PostGIS database met ongeveer 5GB aan data (een volledig legale topo map van Noorwegen).
- Dienen als backup voor de NAS voor bepaalde folders.
- VM ter vervanging van de windows op mijn laptop omdat ik een aantal programma's heb die windows only zijn en ik ze niet met Wine aan de praat krijg. Een windows VM op de laptop is ook nog een alternatief, maar lost mijn ruimte probleem niet op .

Nu is de grote vraag ga ik het lekker lui doen en knal ik er gewoon Ubuntu (of een andere linux variant) op en draai ik alles op die manier, of pak ik een hypervisor (heb ik totaal geen ervaring mee, maar Proxmox ziet er wel goed uit) met bijvoorbeeld FreeNAS, een windows variant, en wat ik nog meer wil?
Een hypervisor geeft me in ieder geval de mogelijkheid om de zaken die ik nodig heb goed te regelen en daarnaast veilig wat te kunnen spelen in andere VM's, maar gaat mijn hardware dat uberhaupt redden?

[Hero of Time]

2 GB aan geheugen is niet echt veel om VMs mee te draaien. Je CPU is ook behoorlijk oud, dus verwacht daar niet de beste performance van als je dingen in een VM gaat draaien. Je kan met deze specs beter alles bare metal draaien.

[CAPSLOCK2000]

Een VM kun je met die CPU inderdaad vergeten.
Je kan ook de GIS data op je NAS zetten en de software op je laptop (of oude desktop) draaien. Storage aanbieden via het Netwerk is per slot van rekening de primaire functie van een NAS.

[Voor 24% gewijzigd door CAPSLOCK2000 op 10-05-2016 22:39]

[Anoniem: 616444]

Toch eens de nieuwste Ubuntu LTS geprobeerd. Ook al is deze release nog wel heel pril.
Resultaat na een aantal dagen is dat Ubuntu bijzonder goed bevalt. Alles werkt stabiel en alle hardware werd gelijk herkend. Ook Secure Boot in combinatie met de NVIDIA drivers werkt nu goed.

Unity als desktop interface werkt goed , zeker nu je (eindelijk!) de launcher eenvoudig onderaan het scherm kunt plaatsen. Op een of andere manier valt alles dan veel beter op zijn plaats. En ik merk nu pas dat ik echt wat heb gemist: de zeer fraaie font afhandeling van Ubuntu. Weird eigenlijk dat andere distro's hier veel minder aandacht aan besteden, je kijkt toch het meest van alles tegen die fonts aan.

Hiervoor gebruikte ik Fedora en Arch met veel plezier. Alleen al het gedonder met de closed video driver was ik meer dan zat. Iedere keer bij updates van xorg of de kerel de grote kans op een gebroken systeem werd irritant, ook al was het niet ingewikkeld.

Ubuntu LTS: de luxe van 5 jaar 'rust' met een complete en goed beheerde release geeft een goed gevoel. In veel reviews zoals die van Ars Technica wordt nu al aangegeven dat dit de beste release van Canonical tot nu toe is. Tijd zal het leren!

(klikbaar)

[Ploink]

Ik heb voor mijn servertje toch maar weer gekozen voor Fedora 23.
OpenSuse vind ik ook interessant, maar meer iets om te proberen op de desktop. Veel tutorials die ik vind hebben screenshots van Yast en dat maakt het niet eenvoudiger als je alleen maar een command prompt ter beschikking hebt.

Voor de installatie heb ik de netinstaller op USB stik gezet en een minimal install gekozen. Nou dat is echt heel minimaal! Zelfs basis tools als ifconfig en andere veelgebruikte commandline tools ontbreken, maar afgezien daarvan een goed uitgangspunt om weer eens schoon te beginnen. Ik had wel een lijst gemaakt van pakketten in de oude installatie voor dezelfde selectie op 64bit, maar heb toch besloten alleen te installeren wat ik nodig heb.

Inmiddels draait alles weer.
Courier mailserver loopt.
Samba heeft een 3TB BTRFS data schijf gedeeld en met Snapper en VFS_SNAPPER heb ik de "previous versions" feature van windows werkend nu. Btrfs enhanced server-side copy werkt ook.
Alle schijven zijn encrypted met LUKS, dus als de server wordt gestolen ligt er niks op straat.

Nu nog een backup script voor nachtelijke backups op verwisselbare schijven. Ik denk dat ik btrfs send/receive ga gebruiken.

[begintmeta]

Ik ben een herinrichting van mijn thuisservertje met CentOS van plan, waarom heb je voor Fedora gekozen?

[Hero of Time]

Ik kan gezien z'n post maar 1 reden bedenken: veel, en echt veel betere support voor BTRFS dan in CentOS. En mijn ervaring met Fedora is dat het toch wel redelijk stabiel is, ondanks z'n redelijk bleeding edge filosofie.

[Ploink]

Inderdaad. CentOS is prima, maar loopt achter met hun kernels en dus ook met BTRFS. De ontwikkelaars van dit filesysteem raden aan om altijd de laatste versie te gebruiken, ook vanwege de stabiliteit.

Ik ga pas op F24 over als F25 uit is en dan blijf ik 1 versie achterlopen om het wat minder bleeding edge te maken. Dat ik niet voor opensuse heb gekozen is eigenlijk meer koudwatervrees, ik moet er eerst maar eens mee spelen.

OpenSuse ontwikkelt Snapper voor het managen van snapshots. Dit kun je direct bij installatie activeren, zodat je vanuit het grub2 boot menu een oudere snapshot van je OS kan kiezen na een update (als ik het goed heb begrepen).

Hoe ik met Fedora OS backups ga maken weet ik nog niet. Er staan 3 partities op mijn SSD:
/boot (ext4)
/boot/efi (vfat)
/ (LUKS encrypted btrfs)

Hoe Suse dat precies doet is me niet duidelijk, ze maken snapshots van /, maar /boot en /boot/efi dan? Of booten ze ouderwets met MBR en hebben ze geen aparte /boot nodig? Ik las ergens dat grub2 niet van een btrfs subvolume kan booten dus hoe dat nou zit

Anders maak ik gewoon een /boot.bak met een kopie van alles onder /boot voordat ik een snapshot maak van / en die naar een backup schijf stuur. Zo kan ik tenminste mijn SSD reconstrueren mocht die stuk gaan.

[HollowGamer]

/boot is meestal niet zo heel spanned. De kernel(s) en bootloader bestanden kun je 'eenvoudig' weer laten genereren. Verder staat bij grub2 de config in /etc/default/grub.

Ik ben je even kwijt betreft EFI/MBR. Bij EFI wordt er niet meer gekeken naar een MBR, alleen naar de inhoudt van de EFI-vars en dus de EFI-partitie. De laatste kun je tegenwoordig gewoon maken onder /boot met ef00 en formatteren met FAT32. Hier plaatst je dan ook alle kernel/.efi bestanden op. Dus geen aparte partitie voor /boot/efi.

Betreft Btrfs; daar kun je niet vanaf booten en ook niet een swap op aanmaken. Maar dat booten doe je dus met de bootloader (in jouw geval grub2-efi).

[narotic]

Hoe bedoel je geen aparte partitie voor /boot/efi? Voor zover ik weet moet er juist altijd een aparte FAT32 geformatteerde efi partitie zijn, welke normaliter onder /boot/efi gemount wordt. /boot zelf hoeft daarentegen niet perse op een aparte partitie (iig met ZFS), maar vermoedelijk is dat wat moeilijker in dit geval door LUKS.

[Hero of Time]

HollowGamer schreef op dinsdag 17 mei 2016 @ 23:22:
Betreft Btrfs; daar kun je niet vanaf booten en ook niet een swap op aanmaken.

Lijkt mij logisch dat je geen swap kan aanmaken met btrfs, want swap heeft z'n eigen FS dat je niet eens kan formatteren (nou ja, mkswap dan).

narotic schreef op dinsdag 17 mei 2016 @ 23:44:
Hoe bedoel je geen aparte partitie voor /boot/efi? Voor zover ik weet moet er juist altijd een aparte FAT32 geformatteerde efi partitie zijn, welke normaliter onder /boot/efi gemount wordt. /boot zelf hoeft daarentegen niet perse op een aparte partitie (iig met ZFS), maar vermoedelijk is dat wat moeilijker in dit geval door LUKS.

Voor LUKS boeit het niet, GRUB2 kan die gewoon unlocken. Punt is met btrfs is dat er wel modules moeten zijn om btrfs te kunnen lezen en die zijn er blijkbaar niet.

[Voor 47% gewijzigd door Hero of Time op 17-05-2016 23:46]

[Ploink]

Hero of Time schreef op dinsdag 17 mei 2016 @ 23:44:
Voor LUKS boeit het niet, GRUB2 kan die gewoon unlocken. Punt is met btrfs is dat er wel modules moeten zijn om btrfs te kunnen lezen en die zijn er blijkbaar niet.

Full disk encryptie zonder aparte /boot partitie blijkt inderdaad mogelijk, maar of dat ook kan via de installer bij verschillende distro's.... geen idee.

OpenSuse kan wel booten van een BTRFS subvolume.

[HollowGamer]

Hero of Time schreef op dinsdag 17 mei 2016 @ 23:44:
[...]

Lijkt mij logisch dat je geen swap kan aanmaken met btrfs, want swap heeft z'n eigen FS dat je niet eens kan formatteren (nou ja, mkswap dan).


[...]

Voor LUKS boeit het niet, GRUB2 kan die gewoon unlocken. Punt is met btrfs is dat er wel modules moeten zijn om btrfs te kunnen lezen en die zijn er blijkbaar niet.

Bedoelde een swap file.

Hoe bedoel je dat laatste precies? Die modules zijn er toch gewoon? Btrfs kun je laten 'inbouwen' in de kernel of als losse module meegeven aan je mkinitcpio.

@Ploink: Meestal zet ik het gewoon in een aparte boot (EFI), i.v.m. dual-boot Windows. Die extra 512MB doet hem het tegenwoordig ook niet meer.

[begintmeta]

HollowGamer schreef op woensdag 18 mei 2016 @ 09:47:
...

Hoe bedoel je dat laatste precies? Die modules zijn er toch gewoon? Btrfs kun je laten 'inbouwen' in de kernel of als losse module meegeven aan je mkinitcpio.

...

Als je btrfs inbouwt in de kernel (of meegeeft in een initrd), moet je die kernel/initrd op een FAT32-partitie hebben staan om hem als EFI-payload of door de kernel te kunnen gebruiken (UEFI rekent nu eenmaal op een FAT EFS, al zijn er ongetwijfeld uitzonderingen). Als je een traditionele BIOS-boot gebruikt, moet de bootloader ergens een btrfs-module hebben, voor zover ik weet is het daarbij niet mogelijk direct een kernel te booten, wat coreboot of andere systemen kunnen weet ik niet.

[Voor 7% gewijzigd door begintmeta op 18-05-2016 10:06]

[Gait]

Op dit moment draai ik WHS 2011 op:

AMD Sempron LE-1250
Gigabyte GA-MA74GM-S2H
Corsair Value Select VS1GB667D2
Cooler Master Extreme Power 430W
2x WD Green 640GB
1x WD Green 1TB
1x WD Green 3TB (als back-upschijf)

Ik gebruik hem 24/7 voor SABnzbd, fileserver, UniFi Controller, medialibary (Twonky).

Nu wil ik gaan upgraden naar:
Intel Pentium G4400
ASRock B150M Pro4S
2x Crucial CT4G4DFS8213
128 GB SSD
En misschien de 640GB en 1TB schijven vervangen voor een 3TB.

Tevens wil ik een TeamSpeak server en Call of Duty 1 server gaan hosten.

Maar ik heb echt totaal geen idee welke OS(en) ik het beste kan draaien.
Ik probeer me al tijden in te lezen, maar er is zoveel keuze.

[silverball]

Gait schreef op woensdag 18 mei 2016 @ 11:46:

Maar ik heb echt totaal geen idee welke OS(en) ik het beste kan draaien.
Ik probeer me al tijden in te lezen, maar er is zoveel keuze.

Je zal met de meeste server distributies min of meer hetzelfde kunnen, daarom maakt de keuze IMO niet al te veel uit.

Als je bijvoorbeeld gaat voor stabiliteit, is Debian bijvoorbeeld een goede keuze. Ook is er veel ondersteuning/ documentatie beschikbaar voor Debian en zijn afgeleide.

Als je veel in de GUI wilt configureren, en niet de terminal in wilt duiken is er openSUSE, die YaST meeleverd, een grafische configuratietool voor veel voorkomende beheerderstaken.

Wil je bij het RedHat clubje heb je CentOS, wat vergelijkbaar met Debian is, of Fedora, wat meer bleeding edge is. (recentere software ten koste van stabiliteit) .

Wil je meer eigen configuratie is er bijvoorbeeld Arch, wil je geen Linux heb je de BSD's.....

[Hero of Time]

Ploink schreef op woensdag 18 mei 2016 @ 07:36:
[...]

Full disk encryptie zonder aparte /boot partitie blijkt inderdaad mogelijk, maar of dat ook kan via de installer bij verschillende distro's.... geen idee.

OpenSuse kan wel booten van een BTRFS subvolume.

Debian en Ubuntu kunnen het. Volgens mij kan je zelfs je hele schijf met LVM gebruiken dat in LUKS zit als je via legacy/MBR opstart, maar dat heb ik niet getest. Puur LVM wel, maar icm met LUKS niet.

CentOS en waarschijnlijk ook Fedora staan niet toe dat je je hele schijf als LVM gebruikt. Je MOET een partitie maken en dat werkt dan weer tegen de flexibiliteit van LVM in. Als je te maken hebt met een virtuele machine, wil je namelijk ook daar de flexibiliteit van hebben voor je schijven. Dat kan dus pas met een tweede schijf, niet je eerste.

HollowGamer schreef op woensdag 18 mei 2016 @ 09:47:
Hoe bedoel je dat laatste precies? Die modules zijn er toch gewoon? Btrfs kun je laten 'inbouwen' in de kernel of als losse module meegeven aan je mkinitcpio.

Hoe wil je je initrd lezen van een filesystem dat je bootloader niet kan lezen? Kijk maar eens in je /boot/ partitie. Op mijn BIOS boot systeem staat 't in /boot/grub/i386-pc/.
Dus, prachtig dat je alle modules die je maar zou willen in je initrd propt, je bootloader moet 'm nog steeds kunnen lezen. Zonder btrfs module, heb je geen /boot om te lezen waar je initrd staat.

[begintmeta]

Kan je een boot-payload niet sowieso niet van een btrfs-partitie lezen? Tenminste mij is geen manier bekend. Bij grub staat core.img niet in een filesystem, en EFI verwacht de payload meestal in een FAT-partitie.

Hero of Time schreef op woensdag 18 mei 2016 @ 11:54:
...
CentOS en waarschijnlijk ook Fedora staan niet toe dat je je hele schijf als LVM gebruikt. ...

Weet je (gezien het bovenstaande) zeker dat Debian en Ubuntu het kunnen? Ik vermoed dat ook bij die systemen de essentiele grub-delen niet binnen het filesystem/lvm zitten.

[Voor 47% gewijzigd door begintmeta op 18-05-2016 12:12]

[Hero of Time]

begintmeta schreef op woensdag 18 mei 2016 @ 12:06:
Kan je een boot-payload niet sowieso niet van een btrfs-partitie lezen? Tenminste mij is geen manier bekend. Bij grub staat core.img niet in een filesystem, en EFI verwacht de payload meestal in een FAT-partitie.

EFI vereist een FAT32 partitie voor de bootloader. Daar doet het alles mee. Heb je geen FAT32 partitie, dan kan je ook niet booten via EFI. De bootloader die EFI aanroept doet dan de rest en het is dus mogelijk om de GRUB modules op de EFI partitie te zetten. Dat doet Fedora volgens mij.

[...]

Weet je (gezien het bovenstaande) zeker dat Debian en Ubuntu het kunnen? Ik vermoed dat ook bij die systemen de essentiele grub-delen niet binnen het filesystem/lvm zitten.

Ik heb het nog eens getest en op m'n werklaptop heb ik maar 2 partities: 1x ESP voor EFI boot en 1 met LVM/LUKS combi. In een VM heb ik nog eens getest hoe dat zit met de hele schijf als LVM, omdat ik het eerst ook niet geloofde. maar het kan werkelijk. Alleen CentOS gaat zeiken, terwijl er geen enkele technische reden is om grub buiten je LVM te hebben.

[begintmeta]

Hero of Time schreef op woensdag 18 mei 2016 @ 12:24:
...
EFI vereist een FAT32 partitie voor de bootloader. Daar doet het alles mee. Heb je geen FAT32 partitie, dan kan je ook niet booten via EFI. De bootloader die EFI aanroept doet dan de rest en het is dus mogelijk om de GRUB modules op de EFI partitie te zetten. Dat doet Fedora volgens mij.

Dat klopt niet helemaal vziw, er zijn fabrikanten die hun EFI ook ondersteuning voor andere filesystems meegeven (Apple is vermodelijk het bekendste voorbeeld). Je kan prima alle mogelijk payloadbestanden*benodigdheden op de ESP zetten inderdaad, maar dan boot je uiteraard wel van een FAT-filesystem. Je kan overigens ook gewoon een (geschikte) kernel als payload voor het EFI gebruiken, en intermediaire stappen (zoals grub of systemd-boot) overslaan.

...

Ik heb het nog eens getest en op m'n werklaptop heb ik maar 2 partities: 1x ESP voor EFI boot en 1 met LVM/LUKS combi. In een VM heb ik nog eens getest hoe dat zit met de hele schijf als LVM, omdat ik het eerst ook niet geloofde. maar het kan werkelijk. Alleen CentOS gaat zeiken, terwijl er geen enkele technische reden is om grub buiten je LVM te hebben.

Je boot dan dus niet van LVM/LUKS maar van de ESP. Bij een niet-EFI-systeem zitten bijvoorbeeld eventuele benodigde grub-drivers vziw in core.img, en dat wordt dan doorgaans ook buiten de filesystems gehouden (je gebruikt dan min of meer een 'grub-filesystem)

[Voor 4% gewijzigd door begintmeta op 18-05-2016 12:34]

[Hero of Time]

begintmeta schreef op woensdag 18 mei 2016 @ 12:30:
[...]

Dat klopt niet helemaal vziw, er zijn fabrikanten die hun EFI ook ondersteuning voor andere filesystems meegeven (Apple is vermodelijk het bekendste voorbeeld). Je kan prima alle mogelijk payloadbestanden*benodigdheden op de ESP zetten inderdaad, maar dan boot je uiteraard wel van een FAT-filesystem. Je kan overigens ook gewoon een (geschikte) kernel als payload voor het EFI gebruiken, en intermediaire stappen (zoals grub of systemd-boot) overslaan.

De ESP bij Apple is ook gewoon FAT32 hoor. Dat staat ook zo in de EFI specificaties. Zie ook Wikipedia: EFI system partition.

[...]

Je boot dan dus niet van LVM/LUKS maar van de ESP. Bij een niet-EFI-systeem zitten bijvoorbeeld eventuele benodigde grub-drivers vziw in core.img, en dat wordt dan doorgaans ook buiten de filesystems gehouden (je gebruikt dan min of meer een 'grub-filesystem)

Mijn werklaptop niet idd, die doet UEFI. Maar als je in legacy/BIOS boot opties zit, is je schijfindeling in feite volledig LVM. Dat de eerste 4096 bytes niet bruikbaar zijn, is normaal. Dat is net genoeg ruimte voor de bootloader om naar z'n config en verdere informatie te verwijzen. Het is niets meer dan 'op offset 0xdeadbeef (whatever ) vind je de loader en doe je ding'.

[FireDrunk]

Dat is toch alleen bij LILO? (Dat verhaal met die eerste zoveel sectoren lezen). Daar staat dan toch 'ruw' de bootcode die nodig is om de root partitie readonly te mounten, en de kernel te vinden?

Ik dacht dat grub een andere aanpak had, namelijk een hele modulaire waar GRUB weet welke modules voor welk filesystem nodig zijn etc.

[Hero of Time]

Ja, maar hoe moet het die file systems lezen als het zelf niet kan zien waar z'n config en modules staan? Je hebt tenslotte geen 'harde' partitie waar dat precies op staat, je hele schijf is onderdeel van LVM tenslotte.
Dit is overigens hoe ik denk dat Grub zo kan werken, want met Grub1 was dit namelijk niet mogelijk, pas vanaf Grub2 kan je hele schijf LVM zijn.

[FireDrunk]

Dat is dus het smerige wat LILO doet toch?

User doet: lilo op de commandline
lilo binary leest de exacte harddiskblocken uit van je kernel image en initrd, en slaat deze op in RAM.
Die waardes worden weggeschreven in de eerste 512 bytes van je partitie naast een minimale bootloader die dit begrijpt.

Bij boot worden al die blokken van disk gelezen en daadwerkelijk uitgevoerd.

Daardoor maakt het niks meer uit welk fs je draait, omdat gewoon de blokken opgezocht worden die gestart moeten worden.

Als je dus na een kernel upgrade lilo runt, en dan je lvm snapshot terugzet boot je systeem niet meer totdat je lilo runt (in een chroot ofzo).

EDIT: De LILO bootloader kent dus geen filesystem modules, maar de lilo binary in je OS volgens mij wel. Want hij moet begrijpen hoe je FS aan bepaalde blokken komt (dacht ik )

[Voor 13% gewijzigd door FireDrunk op 18-05-2016 13:20]

[Hero of Time]

Geen idee wat LILO doet, daar heb ik geen ervaring mee. Grub zal vast wel iets slims gebruiken om z'n config te vinden. Die kan tenslotte elke keer van fysieke plek veranderen bij het bijwerken. Lees de broncode dan weet je 't, mits je de taal begrijpt.

[begintmeta]

Hero of Time schreef op woensdag 18 mei 2016 @ 12:55:
[...]

De ESP bij Apple is ook gewoon FAT32 hoor. Dat staat ook zo in de EFI specificaties. Zie ook Wikipedia: EFI system partition.

Klopt, maar de firmware zelf kan ook iets anders begrijpen (of in iedergeval kon de Apple-EFI vroeger nog hfs+ begrijpen (en ook booten zonder ESP)). Er zijn efi-drivers voor diverse andere filesystems beschikbaar, maar die worden uiteraard meestal niet geincludeerd (waarom zou men ook, aangezien de spec zoals je ook aangeeft FAT voor de ESP voorschrijft).

Mijn werklaptop niet idd, die doet UEFI. Maar als je in legacy/BIOS boot opties zit, is je schijfindeling in feite volledig LVM. Dat de eerste 4096 bytes niet bruikbaar zijn, is normaal. Dat is net genoeg ruimte voor de bootloader om naar z'n config en verdere informatie te verwijzen. Het is niets meer dan 'op offset 0xdeadbeef (whatever ) vind je de loader en doe je ding'.

De eerste 4096 bytes (meestal meer) zitten dus niet in het fs, en grub boot dus ook niet vanaf het fs (of het LVM-gebied) of misschien preciezer: grub gebruikt het fs niet om de relevante bits (cq core.img) te vinden.

[Voor 4% gewijzigd door begintmeta op 18-05-2016 14:09]

[Ploink]

http://www.gnu.org/software/grub/manual/grub.html#Images

Grub2 werkt iets anders dan grub1 en MBR of EFI boot werkt ook anders. Lilo is.... best wel antiek.
Als je een EFI systeem hebt dan past grub met al zijn modules op de EFI system partition (ESP). Alleen met MBR is er een bootstrap loader nodig (bootsector) die weer een volgende 'stage' laadt van een paar absolute LBA sectoren op de disk.

ps: Overigens heb ik The rEFInd Boot Manager op mijn desktop.

[Voor 12% gewijzigd door Ploink op 18-05-2016 14:20]

[begintmeta]

Ploink schreef op woensdag 18 mei 2016 @ 14:18:
... Als je een EFI systeem hebt dan past grub met al zijn modules op de EFI system partition (ESP)....

Sterker nog, het is dan vrij probleemloos mogelijk een veel grotere payload (zoals de kernel) meteen te booten en eventueel overbodige (tenzij je via een eigen efi-programma bijvoorbeeld wil kunnen kiezen uit wat geboot moet worden/daar voorwaarden aan te stellen) tussenstappen over te slaan.

[Voor 14% gewijzigd door begintmeta op 18-05-2016 14:36]

[Ploink]

begintmeta schreef op woensdag 18 mei 2016 @ 14:35:
[...]

Sterker nog, het is dan vrij probleemloos mogelijk een veel grotere payload (zoals de kernel) meteen te booten en eventueel overbodige (tenzij je via een eigen efi-programma bijvoorbeeld wil kunnen kiezen uit wat geboot moet worden/daar voorwaarden aan te stellen) tussenstappen over te slaan.

Of zelfs een complete linux installatie, wat in feite het geval is op een Live-USB stick.

[begintmeta]

Ploink schreef op woensdag 18 mei 2016 @ 14:43:
[...]

Of zelfs een complete linux installatie, wat in feite het geval is op een Live-USB stick.

Klopt, maar dat is dan niet meer echt een payload voor de EFI-boot zou ik zeggen, ik zou een initrd daar al niet meer echt onder vinden vallen.

[FireDrunk]

Op mijn Linux Ultrabook heb ik ook puur UEFI boot. EFI partitie met daarop alleen de kernel image en initrd, rest is btrfs met maar 1 volume.

systemd-boot (of hoe het ook voorheen heette, iets met efibootmgr dacht ik). Boot ArchLinux in < 5s.

[toro]

Gait schreef op woensdag 18 mei 2016 @ 11:46:
Op dit moment draai ik WHS 2011 op:

AMD Sempron LE-1250
Gigabyte GA-MA74GM-S2H
Corsair Value Select VS1GB667D2
Cooler Master Extreme Power 430W
2x WD Green 640GB
1x WD Green 1TB
1x WD Green 3TB (als back-upschijf)

Ik gebruik hem 24/7 voor SABnzbd, fileserver, UniFi Controller, medialibary (Twonky).

Nu wil ik gaan upgraden naar:
Intel Pentium G4400
ASRock B150M Pro4S
2x Crucial CT4G4DFS8213
128 GB SSD
En misschien de 640GB en 1TB schijven vervangen voor een 3TB.

Tevens wil ik een TeamSpeak server en Call of Duty 1 server gaan hosten.

Maar ik heb echt totaal geen idee welke OS(en) ik het beste kan draaien.
Ik probeer me al tijden in te lezen, maar er is zoveel keuze.

Je had ook gewoon een normale Windows (pro) versie kunnen nemen voor het hosten van hetgeen je beschrijft. Had je ook geen whs voor nodig gehad

Alle Linux distributies kunnen het aan voor wat je het wil gebruiken.

[HollowGamer]

Gait schreef op woensdag 18 mei 2016 @ 11:46:
[..]

Maar ik heb echt totaal geen idee welke OS(en) ik het beste kan draaien.
Ik probeer me al tijden in te lezen, maar er is zoveel keuze.

Heb je al ervaring met Linux? Je zou ook het eerst in een VM kunnen opzetten.
Zo kom je ook achter wat je favo distro is/wordt,

Voor beginners raad ik meestal Ubuntu Server aan (wegens de vele gebruikers, guides, software in de repo's, etc.). Ben je een Pro, dan Arch Linux ook een goede keuze.
Debian is ook een goede keuze, maar die hebben (mogelijk) weer een aantal dingen niet in de repo's.

Van de andere kant.. iedereen heeft zo zijn eigen keuze/meningen over zijn/haar distro.

[begintmeta]

FireDrunk schreef op woensdag 18 mei 2016 @ 15:30:
... systemd-boot (of hoe het ook voorheen heette, iets met efibootmgr dacht ik). ...

Gummiboot, een veel leukere naam IMHO.

[Gait]

Bedankt voor de reacties ik ga vast het eea in VM proberen.

[pjlgt]

Draai thuis Ubuntu Server 14.04 LTS met Plex, Transmission, Smb en Webmin. Vooral omdat ik redelijk bekend met Ubuntu en daar gewoonweg de meeste info over te vinden is. Werk als systeembeheerder voornamelijk met Windows systemen, maar vind Ubuntu als knutselsysteem voor thuis ook wel lekker ter afwisseling. En is ook wel eens handig als je collega's weer eens de ballen niet snappen van een offsite Linux webserver of iets dergelijks.

[HollowGamer]

pjlgt schreef op donderdag 19 mei 2016 @ 15:35:
Draai thuis Ubuntu Server 14.04 LTS met Plex, Transmission, Smb en Webmin. Vooral omdat ik redelijk bekend met Ubuntu en daar gewoonweg de meeste info over te vinden is. Werk als systeembeheerder voornamelijk met Windows systemen, maar vind Ubuntu als knutselsysteem voor thuis ook wel lekker ter afwisseling. En is ook wel eens handig als je collega's weer eens de ballen niet snappen van een offsite Linux webserver of iets dergelijks.

De wereld zou meer moeten bestaan uit Systeembeheerders met Linux kennis, dan deze zonder.. Maar dat is mijn mening.
Helaas worden Windows certificaten meestal meer gewaardeerd, dan een Linux varianten.

Hoewel ik de AD een mooie Windows-feature vindt, is dit met Linux ook prima mogelijk.. Helaas niks bij de opleiding overgekregen, waardoor jezelf het internet en cursussen mag opzoeken. Ik snap de hele Windows-only gedachte van veel opleiders totaal niet.
Er zijn echter ook genoeg mensen die Linux prut vinden, maar dat komt dus denk ik door opleiding en het weinig aanbod komen.

[pjlgt]

Helmaal mee eens. Heb ook al eens voorgesteld om voor bepaalde zaken een Linux server op te tuigen, maar dat vind men eng. Nee liever 100en euro's betalen voor een Windows licentie

[Hero of Time]

pjlgt schreef op donderdag 19 mei 2016 @ 15:35:
Draai thuis Ubuntu Server 14.04 LTS met Plex, Transmission, Smb en Webmin. Vooral omdat ik redelijk bekend met Ubuntu en daar gewoonweg de meeste info over te vinden is. Werk als systeembeheerder voornamelijk met Windows systemen, maar vind Ubuntu als knutselsysteem voor thuis ook wel lekker ter afwisseling. En is ook wel eens handig als je collega's weer eens de ballen niet snappen van een offsite Linux webserver of iets dergelijks.

Wacht even. Je weet het een en ander van Linux af, Ubuntu in dit geval, en je gebruikt een onzintool zoals Webmin? Sorry, maar als je ook maar enig vertrouwen in je kennis hebt, gebruik je dat soort zooi niet.

Wie mij verteld dat-ie Linux kent en dan met zulke tools werkt, lach ik keihard uit. Het komt dan op mij over dat iemand alles van auto's weet omdat-ie toevallig z'n olie kan peilen.
Niet lullig bedoelt verder hoor.

[HollowGamer]

Hero of Time schreef op donderdag 19 mei 2016 @ 16:09:
[...]

Wacht even. Je weet het een en ander van Linux af, Ubuntu in dit geval, en je gebruikt een onzintool zoals Webmin? Sorry, maar als je ook maar enig vertrouwen in je kennis hebt, gebruik je dat soort zooi niet.

Wie mij verteld dat-ie Linux kent en dan met zulke tools werkt, lach ik keihard uit. Het komt dan op mij over dat iemand alles van auto's weet omdat-ie toevallig z'n olie kan peilen.
Niet lullig bedoelt verder hoor.

Heb op het begin van mijn carriere ook een tool als Webmin gebruikt. Niet om bestanden te wijzigen, maar als een handig hulpmiddel (o.a. voor de overzichten, checken welke service runnen, status van HDD's, etc.). Ga je hetzelfde ook zeggen over beheerders die een ander CP gebruiken (o.a. voor hosting)?

Nu gebruik ik een tool als Webmin niet meer, maar er zijn wel tegenwoordig genoeg nice responsive en Ajax CP's, die het beheren van een server of NAS toch echt wel makkelijk maken.

Webmin is inderdaad niet echt goed (genoeg over config file corruptie gelezen), maar op zich zelf is het een vrij lichte en eenvoudig hulpmiddel.

[Voor 8% gewijzigd door HollowGamer op 19-05-2016 16:26]

[gekkie]

Ik gok dat hij niet graag iets met die privileges draait waar dermate veel exploits voor zijn (geweest) in de hele trein (webmin zelf, php, webserver).

[Voor 3% gewijzigd door gekkie op 19-05-2016 16:31]

[HollowGamer]

gekkie schreef op donderdag 19 mei 2016 @ 16:31:
Ik gok dat hij niet graag iets met die privileges draait waar dermate veel exploits voor zijn (geweest) in de hele trein (webmin zelf, php, webserver).

Helemaal mee eens, webmin is brak, maar denk dat HoT doelt op het laten beheren van een server icm. deze tool, i.p.v. bijvoorbeeld via CLI.

Als het anders de insteek was (beveiliging) neem ik mijn comment dan ook graag terug.

[pjlgt]

Krijg gelijk de neiging om webmin te verwijderen Nu ik erover nadenk ook welgeteld 1 x gebruikt, enkel vlak na de installatie. Leek me wel praktisch, maar schijnbaar niet nodig gehad om de boel verder draaiend te krijgen en houden.

Edit: Done

[Voor 3% gewijzigd door pjlgt op 19-05-2016 16:57]

[Hero of Time]

Ik doel op beide kanten. Zowel securitytechnisch, want de meeste van die dingen draaien als root en gaan stuk als je 't als default apache/www-data werken, maar ook beheertechnisch gezien. Webmin is lek, DirectAdmin sloopt je hele server (zie een paar topics hier, ik noem even uit m'n hoofd een Yum dat over de zeik gaat vanwege conflicterende libs in /usr/local). Andere tools doen vergelijkbare dingen op hun eigen manier waardoor je vaak er geen wijs meer uit komt zodra je de server voortaan via de CLI wilt beheren en meer van dat soort ongein. DA is daar van wat ik heb gezien de ergste, die compiled software ipv het netjes uit de repo te halen van de distro.

Als je niet verder gaat dan de webinterface en je niet bemoeid met security, en bovenal, je weet niet beter, is het prima voor je. Maar je moet niet gek staan te kijken als je machine opeens een coin-miner is geworden (mits die iets naar het internet serveert).

[FireDrunk]

Al eens van Cockpit gehoord? Die gebruik ik al een flinke tijd met veel liefde.

Hij is 100% compatible met je normale command line toegang, werkt realtime (dus geen problemen als je tegelijkertijd op de command line bezig bent), is light weight (er luistert alleen een socket, de daadwerkelijke app wordt pas gestart als je connectie maakt). En is volledig live en synchroon

Je ziet dus live mountpoints er bij komen, live netwerk interfaces veranderen, en tal van dat soort dingen

Vooral handig om even snel te kijken naar disk usage, netwerk load, disk load, en dat soort fratsen.

[silverball]

Vandaag op school op mijn development bak stiekem maar even kde/plasma geinstalleerd naast gnome op Fedora. Het viel vies tegen, in Fedora KDE is heel veel kapot. Blijkbaar focust men zich veel meer op gnome.

Neem bijvoorbeeld Apper. Apper is kapot wegens de rewrite van PackageKit . Die bevat alleen de functies die gnome software nodig heeft. Bovendien worden er veel Gnome pakketten gebruikt, omdat waarschijnlijk veel KDE paketten niet (meer?) onderhouden worden. Erg jammer.

[HollowGamer]

silverball schreef op donderdag 19 mei 2016 @ 18:38:
Vandaag op school op mijn development bak stiekem maar even kde/plasma geinstalleerd naast gnome op Fedora. Het viel vies tegen, in Fedora KDE is heel veel kapot. Blijkbaar focust men zich veel meer op gnome.

Neem bijvoorbeeld Apper. Apper is kapot wegens de rewrite van PackageKit . Die bevat alleen de functies die gnome software nodig heeft. Bovendien worden er veel Gnome pakketten gebruikt, omdat waarschijnlijk veel KDE paketten niet (meer?) onderhouden worden. Erg jammer.

Dacht dat Fedora altijd al een beetje GNOME minded is geweest, waren ook de eerste met GS. Welke pakketten bedoel je zo ongeveer?

[silverball]

Het is sowieso allemaal niet erg stabiel, ik kan niet alle pakketten opnoemen want ik was er snel klaar mee. KMail crashte meteen bij openen. De KDE browser werkte niet, en er waren veel gtk programma's aanwezig.

[Hero of Time]

Tja, als je bij een Gnome installatie van Fedora KDE Plasma installeert, is het ook logisch dat je veel GTK programma's ziet. Andersom is hetzelfde, installeer je Gnome naast KDE dan zal je veel KDE programma's tussen je Gnome dingen zien.

Konqueror die niet werkt, wat wilde je precies doen ermee? Over het algemeen werkt het prima, maar het is wel een beetje een vreemde eend in de bijt. Dat Kmail crasht kan ook wat anders zijn, bijvoorbeeld een missend pakket zoals Akonadi, al zou alle afhankelijkheden netjes meegenomen moeten zijn.

Je laat overigens wel een gedeelte van mijn ervaring zien met KDE, maar dan op Debian. Het loopt niet echt lekker met de laatste versies, terwijl KDE4 en KDE3 toch een stuk stabieler aanvoelde.