Archbang 2011.09 is uit

Er komt ook een Oktober versie waarin de meeste bugs in deze versie zullen zijn opgelost, Een probleem is de overgang van alsa naar OSS, dat op sommige pc's en laptops tot gepiep leidt. Op het archbang forum vind je een oplossing voor als je het gaat installeren.

Hier vind je de release notes en downloadlinks.

Torrents hier

Hoe belangrijk is de community van je OS?

Litemotiv, een zeer actieve mod op het Arch forum legt in het Nederlands uit hoe hij het functioneren van het Arch forum ziet en hoe hij het uit de hand lopen op het Arch forum van een discussie rond package signing verklaart.
Crunch
Ik vond het verhelderend. Mijn ervaringen met Linux fora zijn vooral ingekleurd door de zeer positieve ervaringen met het Crunchbang forum. Dat vond ik een plek waar echt een betekenisvolle uitwisseling plaatsvindt/vond (het is de laatste tijd wat minder) rond allerlei ontwikkelingen en niet alleen tussen mensen die Crunchbang gebruiken, maar ook met ex-CB-ers als ik zelf, die gewoon de open en erg vriendelijke en vrolijke sfeer op het forum waarderen. Dat wil niet zeggend dat meningsverschillen uit de weg gegaan worden. Verder is er ook goede informatie bij praktische problemen; daarin vond ik de Ubuntu fora zeer wisselend en dus niet betrouwbaar.
Omdat Corenomimal regelmatig op het CB forum aanwezig is/was, duidelijk op zoek naar input en feedback, krijgt/kreeg het geheel iets leuks informeels en opens.
Aaarch
Daarna is de sfeer op het Arch forum bekrompen (er is wel een hoop geleuter over non-topics als anime en favoriete jongensmuziek), conformistisch (veel fanboyism en men probeert elkaar af te troeven op het gebruik van de meeste, obscure cli/terminal applicaties) en verder vooral op praktisch problemen gericht en daarin wel vaak heel goed. Helaas ook regelmatig nogal onvriendelijk, soms op het botte af naar nieuwe, onervaren gebruikers, die een beginnersfoutje maken. Daarbij valt overigens een verschil in toon op tussen diverse moderators.

Litemotiv legt uit dat je het forum vooral als een helpdesk moet zien en niet een plek waarin een community komt tot een gemeenschappelijke visie komt of waar echt inhoudelijke discussies gevoerd worden, mede omdat de devs het forum toch negeren.
Dit klopt mijns insziens niet helemaal omdat met name Allan, de belangrijkste ontwikkelaar van pacman de discussies over en problemen met pacman zeer goed volgt en vaak reageert. Daar zit ook een sterke mate van sturing en controle bij. Het is niet anders.

Community als asset
Zo kom ik er in ieder geval achter dat de omgang van devs met de gebruikersgemeenschap voor mij een hele belangrijke waarde is bij het kiezen van mij GNU/Linux OS. (En de kwaliteit van de gemeenschap zelf natuurlijk.) Bij Archbang is die verhouding heel open en gemoedelijk. Maar omdat dit als project tot erg zwak is en ik me afvraag of het nog lang bestaat, oriënteer ik me naast het ondersteunen van het AB project als mod op het AB forum weer meer op de Debian wereld, voorlopig dus in de vorm van Aptosid, met een prima forum trouwens.

Nieuwe installatie CD Arch laat nog op zich wachten

Het is alweer een jaar geleden dat de laatste installatie CD van Arch het licht zag.
Dieter geeft in zijn Engelstalige blog een uitleg waarom het zo lang duurt.
Naast persoonlijke redenen en een misschien al te ambitieuze reorganisatie van het release model als verklaring biedt hij al wel een alternatief in de vorm van test releases, die te vinden zijn op http://releng.archlinux.org
Hij moedigt iedereen aan een bijdrage te leveren door deze te testen.

Toch is het een teken van zwakte dat een nieuwe release op zich laat wachten.
Maar misschien hebben de Arch devs ook wel niet zo'n zin een een nieuwe toestroom van gebruikers en de stroom beginnersvragen die dit telkens weer oplevert.

Of zou men eerst het probleem van package signing willen vloeren?
Ik vermoed dat dit geen rol speelt. Op de wiki werd onlangs nog de kortstondige vermelding van dit probleem op de beginnersgids pagina verwijderd.
Het lijkt er eerder op dat dit probleem nog lang zal blijven omdat de kwestie weer totaal onvindbaar is als acuut probleem op het forum of totaal wordt gebagatelliseerd.

Terwijl ik zelf nog steeds erg actief ben als moderator op het Archbang forum, richt ik mij ook steeds meer op Debian Aptosid, dat een aantal voordelen gemeenschappelijk heeft met Arch: rolling release, vanille en nieuwe packages, loeisnel. Extra voordelen dat de Debian repositories voor je openstaan en dat het goed is te kunnen werken met een veelgebruikt systeem als Debian. Ik ontdekte Aptosid dankzij IgnorantGuru's post over zijn overstap van Arch naar Aptosid. Hij is ontwikkelaar van pcmanfm-mod en iemand die ik gewoon vertrouw in zijn kennis keuzes; een soort combinatie van het zoeken naar kwaliteit en dat het makkelijk moet werken. Na wat aanloop problemen bevalt het me prima.

Zorgen over gebrek aan Package Signing breekt Arch steeds meer op

Oftewel gebrek aan
Zorgen over gebrek aan Package Signing breekt Arch steeds meer op
Ik heb heel de discussie rond package signing sinds die recent opnieuw opdook, nauwkeurig gevolgd en werd zoals ik in een vorige post al meldde slachtoffer van het spervuur dat ontstond uit de neiging om de brenger van het slechte nieuws te vermoorden. Toch lukt het de ter discussie staande Arch devs steeds slechter het vuil onder het tapijt te vegen.
Een artikel rond Arch veiligheid op LWN.net brengt de kwestie bij een groter geïnteresseerd publiek.
De reacties van de betrokken Arch devs zijn furieus: Dan McGee op zijn eigen blog:
maar de verdediging beweegt zich weer op de bekende paden; niemand wou ons helpen en beter geen oplossing dan een voorlopige oplossing. Het is de moeite waard voor de buitenstaanders de commentaren te lezen om te zien hoe de Arch-believers zich totaal discrediteren in stuitende stemmingmakerij en gescheld.
Hier het laatste stuk van het artikel geschreven door Nathan Willis:

As you would expect, there is a lot of heated language between the two, which can make it difficult to separate out the nucleus of each side's complaints. It is clear, however, that other Arch contributors have proposed virtually the same package signing plan as IgnorantGuru in the past, at least as far back as 2008. The core developers have never acted to add signature-checking to Pacman, even though patches have been submitted, yet at the same time have resisted all "interim" solutions as a waste of effort, on the grounds that Pacman is the proper place for package signature work.

For his part, IgnorantGuru posted a Bash script on his own site that allows a user a small amount of integrity checking by comparing the checksums of a package from multiple Arch mirrors. In the weeks since the original post, IgnorantGuru announced that he had given up on the hope that the core developers would ever adopt a package signing solution,......

Threats

In the final analysis, Arch users are exposed to a security threat both by the distribution's lack of package signing and by the core developer's resistance to adopting it. However much the Arch "philosophy" says each user is responsible for his or her own system, IgnorantGuru is correct in his first blog post when he observes that without signatures, the distribution's infrastructure is vulnerable to every exploit found in every other system on the path between the main project server and the user's PC. Any exploit on the OS used by the HTTP or FTP mirror server can allow an attacker to replace an Arch package, and the user has no way to even detect that the change has been made. A network-based man-in-the-middle attack does not even require finding a root exploit on one of the servers; it could be performed at a router or network access point.

As for McRae and the other core developers resisting outside work to implement package signatures, there are at least two levels at which their recent statements are troubling. First, they (and commenters taking their side) invariably bring up the "stop whining or start coding" retort, or its kinder cousin "patches welcome."

In theory that reply encapsulates the open source approach — anyone with an itch can scratch it — which is true on the surface. But it overlooks the reality of distribution maintainership: some tasks, such as security, are vital to the health of the project, even though they might not be anyone's idea of fun. In addition, as the Arch developers' responses have shown, the gatekeepers to a project can still prevent new code and patches from getting accepted if they so choose.

That of course is the second level at which the core developers' resistance is troubling: the fact that they would prevent security patches from going into the project. Some on the anti-signature camp argue (essentially) that if you don't like any decision made by the core developers, you should leave, and cite Arch's "not for the faint-of-heart" philosophy as justification. But that is in direct opposition to the "patches welcome" response. A distribution cannot invite contributions, but then treat contributors with hostility when they arrive.

Moreover, in Arch's case it hardens the anti-signing camp into a position where it denies the reality of the package-tampering threat. You can already see this in some of the responses to IgnorantGuru and the bug reports he filed: commenters minimizing the statistical likelihood of an attack as grounds for not adopting any package signing plan at all.

Perhaps there is no reason to read ill will into any of McRae or the other Arch developers' resistance to package signing; perhaps they only seem hostile in context. But even if that is the case, by preventing others' code from making it into Pacman and the package database, they are letting Arch Linux users remain sitting ducks, as well as driving them away. It's hard to see how either result improves the project.

Arch forum: gebrek aan open discussie en onheus gedrag van mods blijft onbestraft

Van begin af aan viel me op dat de mods op het Arch forum nu niet bepaald gebruikersvriendelijk zijn. De toon is vaak kleinerend en uit de hoogte en de heren permitteren zich zelf allerlei gedrag dat bij een ander leidt tot onmiddellijk sluiten van de conversatie (thread) . Zoals opmerkingen die niet echt ingaan op de vraag (bijv. hoe kom je erbij zoiets te willen) of geleuter over non-topic onderwerpen, die in feite de conversatie om zeep helpen.
Kwalijker is nog dat het zeer riskant is de mod daarop te bekritiseren, want daarop zal of het onderwerp gesloten worden en naar de vuilnis bak verwijderd of als je geluk hebt naar Topics Going Nowhere. Andere mods bespringen de ongelukkige als een troep wolven en proberen je met onware verdachtmakingen onderuit de halen. Hier leg ik uit hoe mij dit overkwam. Dit leidt ertoe dat open discussie en echte verschillen met de heersende mening niet getolereerd worden. Dat betekent niet alleen dat een hoop mensen stuk voor stuk afknappen op deze behandeling, maar ook dat een open sfeer ontbreekt en dat er akelige tekenen van conformiteit en slijmerigheid op het forum tevinden zijn. De boot is helemaal los als Arch zelf kritisch bekeken dient te worden.

Laatst probeerde ik deze onmacht ter discussie te stellen, maar waardering voor je inzet om dit aspect van de Arch "code" te verbeteren is er niet.

Het is zeer teleurstellend dat dit soort sociale onmacht en onvermogen de eigen sociale dynamiek kritisch te bekijken juist verbonden is met een distro als Arch, die verder vele voordelen biedt. Toch is het onvermijdelijk dat deze zwakte de distributie inhoudelijk aantast. Een voorbeeld is het veiligheidsprobleem bij authentificatie van de Arch packages, die je download van de Arch repisitories. In deze blog wordt de reikwijdte van dit probleem aangekaart. Iemand die in zijn onschuld mij en andere forum gebruikers via het forum op deze kwestie wees, werd publiekelijk afgebrand en toen ik ervoor opkwam deze conversatie niet te sluiten, richtte de woede , die zich richt op de brenger van het slechte nieuws zich op mij.

Nou gaat het me even niet om de onheuse behandeling an sich, maar dat deze veiligheidskwestie niet fatsoenlijk wordt voorgelegd aan de Arch-gebruikers. Noch op de beginnerspagina noch op de pacman pagina van de Arch Wiki zul je een verwijzing naar dit probleem vinden. Wel twee losse, bijna een jaar oude pagina's die het probleem beschrijven en tonen dat er aan gewerkt wordt
Het blijkt al 6 jaar te spelen en door het onvermogen om onderlinge verschillen van mening te overwinnen over hoe deze kwestie opgelost moet worden, gebeurt er alsmaar niets en wordt deze kwestie zo snel mogelijk als het weer boven komt drijven onder tafel geveegd.

Doordat de boel zo dichtgetimmerd zit, lijken verbeteringen op het Arch forum voorlopig uitgesloten.

Als je er meer over wilt lezen...

Nieuwe versie van Archbang is uit

ArchBang 2011.02 is out in the wild!

-Nieuwe Kernel 2.6.37

-Thunar goed geconfigureerd voor het vinden van media en partities

-Nieuwe look

-base-devel toegevoegd zodat je meteen packer kunt gaan gebruiken voor AUR

fullscreen screenshot

De Arch benadering

Soms kom je een artikel tegen, dat je denkt: wat goed verwoordt; zo had ik het zelf kunnen opschrijven. Daarom maakte ik een vertaling van dit recente artikel van Kevin Bush:

De Arch Benadering

Je houdt van sleutelen aan je computer. Je hebt Ubuntu en Fedora geprobeerd, en ze zijn goed, maar je voelt dat het beter kan. Misschien wil je niet dat al die daemons laden bij het opstarten, of misschien wil je je Linux-desktop te bouwen net hoe je het wilt? Misschien ben je helemaal onbekend met Linux en wil je precies leren hoe een Linux-werkstation werkt? Het wordt dan tijd om Arch Linux te proberen. Arch Linux wordt vaak de binaire Gentoo genoemd, een passende beschrijving. Arch geeft je een volledige, maar simpele command-line basis om van daar verder te bouwen, maar in tegenstelling tot Gentoo, gebruikt Arch voor i686 of x86_64 geoptimaliseerd binaire pakketten in plaats van de broncode.
Dit zal niet een stap-voor-stap handleiding worden hoe je een Arch Linux desktop aan het werk krijgt. Je vindt dat op de fantastische wiki's van Arch. In plaats daarvan zal ik met jullie delen wat Arch onderscheidt van andere Linux distributies en wat Arch een van de beste distributies maakt voor een persoonlijk werkstation.


Eenvoud
Archs ontwikkeling wordt gestuurd door eenvoud. De Arch wiki stelt, 'Eenvoud is absoluut de belangrijkste doelstelling achter Arch ontwikkeling.' De meeste systeemconfiguratie wordt gedaan door middel van tekstbestanden, die kunnen complex lijken op het eerste gezicht, maar in de praktijk blijkt het veel gemakkelijker dan het zoeken via een grafische menustructuur. Bijvoorbeeld, daemons, kernel modules en netwerken worden allemaal geconfigureerd in een enkel tekstbestand, rc.conf. GNU tekst bewerkingshulpmiddelen die in elke versie van Linux te vinden zijn, maken het bewerken van configuratiebestanden een makkie. Het gaat veel sneller om een tekst string in Vim (of met nano of leafpad -paul) te zoeken dan door eindeloze GUI tabbladen te klikken op zoek naar het goede keuzerondje om aan- of af te vinken.


Rolling release
Arch maakt gebruik van een rolling release model. Dit betekent dat de repositories regelmatig worden bijgewerkt met de laatste stabiele pakketten van de upstream ontwikkelaars. Het voordeel hier is dat je niet hoeft te herinstalleren of om de zes maanden een complexe procedure voor het upgraden hoeft uit te voeren. Doe een pacman-Syu om de paar dagen om uw hele systeem bij te werken (meer over het fantastische Pacman hieronder). Dit wil niet zeggen dat er een update nooit problemen zal veroorzaken, maar als je problemen ondervindt, zal er naar alle waarschijnlijkheid een oplossing gepost worden op het forum of de voorpagina van de Arch website.

De schandalig goede Arch Wiki

Over documentatie gesproken: de Arch Wiki is de meest uitgebreide bron van informatie over Linux, die er is. Toen ik Ubuntu nog gebruikte, heb ik vaak het antwoord op een moeilijke configuratie-probleem op de Arch Wiki gevonden. Ja, de Arch Wiki is wel afgestemd op Arch, maar het kan vaak helpen bij het oplossen van problemen met andere distributies.

BSD Style init

Zeg het ingewikkelde System V runlevels vaarwel met de hun bijbehorende symlinks. De meeste distributies gebruiken een System V-stijl init, die een aparte directory voor elk van de acht runlevels heeft. Arch gebruikt een BSD-stijl; dat bewerkstelligt bijna hetzelfde met een eenvoudige set van scripts. Noodzakelijk om CUPS toe te voegen bij het opstarten? Voeg gewoon CUPS toe aan de daemons lijst in /etc/rc.conf. Klaar is Kees.

Pacman
Ik heb gebruik gemaakt van vele verschillende Linux package managers: pacman, aptitude, yum, zypper en netpkg. Pacman is zonder meer mijn favoriet. Het is snel. Downloaden, zoeken en installeren; zijn alledrie het snelst van wat ik heb gezien. Het volledige systeem-upgrades zijn doorgaans probleemloos. Arch heeft vijf officiële repositories: core, extra, community, test en multilib. Core bevat het minimum dat nodig voor een functionele Linux-systeem. Core omvat de kernel, GNU command line tools, pacman, en networking tools; in principe alles wat u nodig om te beginnen met de bouw van de perfecte werkplek. Extra bevat pakketten, die niet noodzakelijk zijn voor een basaal werkend systeem; spul als X, GNOME en Apache bijvoorbeeld. Community omvat pakketten onderhouden door de Trusted Users (vertrouwde gebruikers) van de Arch gemeenschap. Deze pakketten zijn binaire compiles van PKGBUILDS van de Arch User repository, en worden in de community repository gestemd door Arch gebruikers. Test is alleen dat, pakketten die worden getest op stabiliteit. Test is standaard uitgecommentarieerd in pacman.conf. Gebruik het op eigen risico. Multilib voorziet in gesloten (i.t.t. tot open source -paul) binaire toepassingen, die alleen verkrijgbaar zijn als 32-bits binaries, en de 32-bit bibliotheken, die nodig zijn om deze applicaties op een 64-bit installatie draaien. Skype en de Adobe flash plugin zijn hier goede voorbeelden van.

AUR
Wat gebeurt er als de toepassing, die je zoekt niet in de repositories van je distributie aanwezig zijn? Als je Fedora gebuikt, moet je mogelijk een niet-ondersteunde 3rd party repository van twijfelachtige kwaliteit toevoegen . Als je gebruik maakt van Ubuntu, hoop je op een Personal Package Archive. Soms moet je gewoon compileren vanaf de broncode, en ellende van allerlei afhankelijkheden zien op te lossen. Op Arch is het vrij simpel. De kans groot dat de app die u zoekt beschikbaar is met behulp van een PKGBUILD script van de Arch User Repository of AUR. Een PKGBUILD is een script gemaakt door een lid van de Arch gemeenschap en die neemt veel van de pijn weg van het bouwen van een toepassing vanuit de broncode. De opdracht wordt uitgevoerd door makepkg die het PKGBUILD script in werking zet; het detecteert en installeert afhankelijkheden, en bouwt een pacman installeerbare binair pakket. [Via Packer wordt het nog eenvoudiger en kan een simpele pacman achtige syntax zorgen voor het zoeken en vinden, bouwen en installeren van de PKGBUILDs -paul] Er is geen noodzaak om te zoeken naar obscure bibliotheken, die niet kunnen worden geïnstalleerd vanuit de core pakketlijst.

Dus hiermee heb je het op een rijtje, de voordelen van Arch. Dit zijn een paar dingen die Arch Linux onderscheiden van de menigte, en haar maken het tot een binaire geweldenaar. Deze lijst is verre van volledig, dus als uw interesse is gewekt, ga wat tijd doorbrengen op de Arch Wiki en forum. De beste manier om Arch te leren kennen, is echter toch om het te installeren en te gebruiken. Ik beloof het de moeite, je tijd en inspanning waard is, en ze betalen me niet eens om te dat zeggen.

Hoe je hulp krijgt ... Dit vereist Tact
Veel minder wordt je op de Arch Forums bij de hand genomen dan op sommige van forums van de andere distro's, en dat met een goede reden. Arch heeft een van de meest informatieve, gebruiksvriendelijke wiki's, die er zijn. Niet, ik herhaal, NIET een vraag te stellen in de forums of op IRC zonder eerst te zoeken op de wiki en het forum. Als je geen oplossing kunt vinden door te zoeken, zorg dan minstens bij het stellen van je vraag voor alle passende log-bestanden en zo veel mogelijk informatie over je systeem. Kijk naar enkele van de huidige berichten in het forum, gemarkeerd als 'Opgelost' (Solved) in de Arch Forum voor voorbeelden, hoe het moet.

Tot zover dit artikel, maar in het verlengde ervan nog dit.
Popularisering van Arch, zoals ik beoog met deze blog wordt niet toegejuicht in Arch kringen; men moet zelf de weg er naar toe zien te vinden. Men is veel te bang dat de community overstroomt wordt door gemakzuchtige types of mensen die het deskundigheidsniveau ondermijnen. En dat begrijp ik goed en vind ik ook terecht. Zie https://bbs.archlinux.org/viewtopic.php?id=111496