LNX Kroeg - Deel 2

[Brent]

Daar ben ik het niet mee oneens, maar laten we even een stapje terug zetten: het gaat concreet om de kernel (GPLv2) en openzfs (cddl), twee licenties die door zowel OSI als de FSF als FLOSS licenties worden aangemerkt. De (vermeende) incompatibiliteit hangt op de vraag of binaries meeleveren het een afgeleide van de kernel maakt, iets dat wmb prima op beide manieren uitgelegd kan worden. Mozilla had eerder een zelfde soort probleem, vandaar de Firefox 'forks' (dit is inmiddels met de MPLv2 is opgelost). Voorzichtigheid is zeker geboden, maar het is zonde niet het soort verkenning te doen als wat Canonical doet, want beide projecten zijn prachtige FLOSS code, en zouden we denk ik allemaal in een ideale wereld graag samen gebruiken. Het enige wat dit potentieel in de weg staat, is een precieze definitie van 'afgeleide software'. Totdat dit door een rechtbank wordt vastgesteld, ben ik blij dat Canonical een serieuze poging waagt zfs linux-land binnen te krijgen. Als het lukt, dan is dat een mooi resultaat.

Als niet, dan moet btrfs serieuze aandacht gaan krijgen. De beloften zijn tot op heden zeker niet waargemaakt, je wil de mailinglist niet zien. Wat een bugfestijn

[Compizfox]

Brent schreef op maandag 29 februari 2016 @ 21:55:
Daar ben ik het niet mee oneens, maar laten we even een stapje terug zetten: het gaat concreet om de kernel (GPLv2) en openzfs (cddl), twee licenties die door zowel OSI als de FSF als FLOSS licenties worden aangemerkt. De (vermeende) incompatibiliteit hangt op de vraag of binaries meeleveren het een afgeleide van de kernel maakt, iets dat wmb prima op beide manieren uitgelegd kan worden.

Dat is inderdaad het probleem, maar daar komt de incompatibiliteit niet vandaan.

De incompatibiliteit stemt voort uit uit het feit dat de GPL vereist dat een afgeleid werk alleen opnieuw onder de GPL mag worden uitgegeven. De CDDL is een zwakke copyleftlicentie en lijkt dus wel wat op de GPL (wat sterk copyleft is). De CDDL zegt dat code onder die licentie alleen onder de CDDL mag worden uitgegeven, en dat je geen extra restricties mag toepassen. Daarom zijn de GPL en CDDL incompatibel: je kunt GPL-code (de kernel) en CDDL-code (zfs.ko) niet samen onder de GPL uitgeven.

Volgens sommigen heeft Sun dit destijds met opzet zo gedaan, om ZFS (een belangrijke selling point) binnen Solaris te houden.

De huidige 'oplossing' hiervoor is om ZFS niet zomaar mee te leveren, maar bij installatie ter plekke door de gebruiker te laten compileren en linken tegen de kernel. Dat mag gewoon. ZFS is dus al langer mogelijk in Linux, maar niet 'out-of-the-box'. Wat Canonical doet is echter anders (en volgens velen een stap te ver), namelijk het gelinkt meeleveren van ZFS.

Uitgebreidere uitleg: https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

[ Voor 6% gewijzigd door Compizfox op 29-02-2016 22:16 ]

[Brent]

Compizfox schreef op maandag 29 februari 2016 @ 22:12:
Wat Canonical doet is echter anders (en volgens velen een stap te ver), namelijk het gelinkt meeleveren van ZFS.

Omdat, en daar kan ik me in vinden, ze betogen dat het meeleveren niet betekend dat het een van het ander afgeleid is, en het dus niet nodig is zfs te herlicenseren onder de GPL (wat idd niet kan). Om nog preciezer te zijn, lijkt het dat het aanwezig zijn of niet van kernel APIs of ABIs het antwoord moeten geven.

Uitgebreidere uitleg: https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

SFconservancy is meer een GPL waakhond dan FLOSS waakhond. Ieder zijn belang natuurlijk, moge de beste winnen.

[Compizfox]

Brent schreef op maandag 29 februari 2016 @ 22:24:
[...]

Omdat, en daar kan ik me in vinden, ze betogen dat het meeleveren niet betekend dat het een van het ander afgeleid is, en het dus niet nodig is zfs te herlicenseren onder de GPL (wat idd niet kan). Om nog preciezer te zijn, lijkt het dat het aanwezig zijn of niet van kernel APIs of ABIs het antwoord moeten geven.

Daar zit hem inderdaad het controversiële punt. De algemene opvatting is dat kernelmodules combined work vormen met de kernel, maar er zijn mensen die het daar niet mee eens zijn. Quote uit het artikel van m'n vorige post:

Nevertheless, our lawyers have analyzed these situations with the assistance of our license compliance and software forensics staff for many years, and we have yet to encounter a Linux module that — when distributed in binary form — did not, in our view, yield combined work with Linux. The FSF, stewards of the GPL, have stated many times over the past decades that they believe there is no legal distinction between dynamic and static linking of a C program and we agree. Accordingly, the analysis is quite obvious to us1: if ZFS were statically linked with Linux and shipped as a single work, few would argue it was not a “work based on the Program” under GPLv2. And, if we believe there is no legal difference when we change that linking from static to dynamic, we conclude easily that binary distribution of ZFS plus Linux — even with ZFS in a .ko file — constitutes distribution of a combined work, which we name Linux+ZFS.

Canonical has found some lawyers who disagree — a minority position, from our understanding of community norms.

[...]

SFconservancy is meer een GPL waakhond dan FLOSS waakhond. Ieder zijn belang natuurlijk, moge de beste winnen.

Dat is het zeker. Maar Linux is GPLv2, dus dat lijkt me prima relevant in deze situatie.

[begintmeta]

Brent schreef op maandag 29 februari 2016 @ 18:25:
[...]

Ik heb dit nooit begrepen. Btrfs is duidelijk gestart om iets ZFS-achtigs in hun toenmalige OS aanbod (Oracle Linux), en na aankoop van Sun spreiden ze hun eigen mankracht over beide. Althans, ik heb niet recent gekeken wie er aan btrfs commit. Daarentegen is een proprietair OS als Solaris wel weer precies iets voor Oracle, en het is logisch dat ze zsm de boel weer hebben geclosesourced en ZFS ontwikkeling propietair hebben gehouden (OpenZFS is effectief een fork inmiddels).

Ze kunnen of zichzelf helpen door ZFS open te houden en externe ontwikkeling te promoten of door Oracle Linux en btrfs te laten doodbloeden/in maintenance mode te zetten. Effectief komt het op laatste neer, ik geloof dat OL sowieso nooit veel meer dan een custom RedHat/CentOS spin was. De heren muggenzifter zullen wel hebben berekend dat het nadeel van geen externe ontwikkelaars niet opwoog tegen het competitie voordeel.

Wel heel jammer, wmb werd ZFS gisteren nog het default FS voor alles

Er zijn meen ik deiverse partijen die nog aan btrfs ontwikkelen, zelfs Oracle nog. Canonical bind de kat nu een beetje op het spek, men had net als bijvoorbeeld SUSE (of in mindere mate RedHat) ook voor btrfs kunnen kiezen als 'gpl-compatibel bestandssysteem van de volgende generatie'.

Wat mij betreft steekt iedereen lekker veel energie in HAMMER2

[Brent]

btrfs is een buggy puinhoop, het is zeer logisch dat ze daar niet voor kozen.

GPL is zeker het verdedigen waard, maar dat is het argument dan ook niet. Het argument is dat het beide FLOSS licenties zijn en het gebruik van kernel API/ABIs niet maakt dat het een afgeleid werk wordt en en prima beide software onder hun respectievelijke licentie geleverd en gedraaid moet kunnen worden. Niets kat op het spek binden, dat is een situatie forceren die inderdaad opgehelderd moet worden, zeker gezien het feit dat er veel te winnen valt.

[begintmeta]

Brent schreef op dinsdag 01 maart 2016 @ 08:36:
... s niet maakt dat het een afgeleid werk wordt en en prima beide software onder hun respectievelijke licentie geleverd en gedraaid moet kunnen worden. ...

Het is ook best zinning imho om met name deze vraag, wanneer is iets een afgeleid werk, in meerdere rechtsstelsels eens goed te beantwoorden., de kat op het spek binden is dan misschien de verkeerde uitdrukking.

[Auredium]

Compizfox schreef op maandag 29 februari 2016 @ 21:13:
[...]

Sterker nog, die driver is er al uit.

[...]

Zo zit het niet. Die proprietary drivers van AMD/Nvidia zitten niet in de kernel, en worden ook niet zomaar in binary meegeleverd. Volgens mij lossen de meeste distro's dat op met DKMS, waarbij de modules tijdens het installeren op de bak van de gebruiker terplekke tegen de geïnstalleerde kernel(s) gelinkt wordt.

Als er meer van dit soort gevallen zijn, dan zullen die zeker moeten worden teruggedraaid. Maar zover ik weet is dat niet het geval.

Je instelling van "het niet zo nauw nemen met licenties" vind ik ook zorgwekkend. Ten eerste gaat het niet zozeer om het feit dat bedrijven op hun strepen kunnen gaan staan, maar ook om het feit dat proprietary code zoveel mogelijk voorkomen moet worden en al helemaal niet thuishoort in de kernel. Daarnaast gaan distro's vaak zeer zorgvuldig om met dit soort zaken. Je zou kunnen zeggen "dat de GPL vrij heilig wordt beschouwd". Daarom is het juist zo controversieel dat Canonical dit doet.

Duidelijk. Het verklaard natuurlijk ook wel dat je de prop. drivers van Nvidia apart moet installeren.

Betreffende de striktheid; laten we voorop stellen dat ik sowieso Open Source als belangrijk vind en de GPL is wat dat betreft 'heilig'. Alleen...ik maak mij zorgen over adoptie en marktaandeel als de GPL zelf een vertragende factor begint te worden. Dat een bedrijf zoals Canonical nu gewoon maar bokkensprongen maakt om ZFS te integreren geeft aan dat ze ZFS willen hebben omdat ze inzien dat een concurrerend OS gebaseerd op BSD bepaalde marktsectors begint te veroveren.
Nu is het wel zo dat Canonical het niet zo nauw neemt met wat 'de rest' denkt en meer zijn eigen plan trekt wat niet altijd goed is (*kuch Unity interface)

[Brent]

Auredium schreef op dinsdag 01 maart 2016 @ 09:26:
[...]
Dat een bedrijf zoals Canonical nu gewoon maar bokkensprongen maakt om ZFS te integreren

Jouw bokkensprongen zijn mijn innovatie: ook op licentiegebied kan geïnnoveerd worden. Dit specifieke issue is nog nooit in een rechtszaal getest, dus tot die tijd kan een SFconservancy roepen wat ze willen (en dat moedig ik ook zeker aan), maar is er prima ruimte voor andere interpretaties. De GPL is in principe niet heiliger dan anders FLOSS licenties zou ik zeggen, en bovendien is dus het precieze punt van het conflict zeer goed uit te leggen als helemaal geen conflict.

geeft aan dat ze ZFS willen hebben omdat ze inzien dat een concurrerend OS gebaseerd op BSD bepaalde marktsectors begint te veroveren.

ZFS op Linux zou iedereen interessant moeten vinden, niet alleen verkopers van support.

[Hero of Time]

Compizfox schreef op maandag 29 februari 2016 @ 21:13:
[...]

Sterker nog, die driver is er al uit.

Heb je een bron waar dat staat? Want ik zie nog steeds de gesloten drivers in de repo staan en ze zouden een hele hoop gebruikers (waaronder ik) tegen de schenen schoppen als ze 'm er echt uit halen. Ze hebben een non-free sectie voor een reden. Ik hoop dat je dat bedoelt, dat 't niet in main of contrib zit.

[Auredium]

Brent schreef op dinsdag 01 maart 2016 @ 11:41:
[...]

Jouw bokkensprongen zijn mijn innovatie: ook op licentiegebied kan geïnnoveerd worden. Dit specifieke issue is nog nooit in een rechtszaal getest, dus tot die tijd kan een SFconservancy roepen wat ze willen (en dat moedig ik ook zeker aan), maar is er prima ruimte voor andere interpretaties. De GPL is in principe niet heiliger dan anders FLOSS licenties zou ik zeggen, en bovendien is dus het precieze punt van het conflict zeer goed uit te leggen als helemaal geen conflict.


[...]

ZFS op Linux zou iedereen interessant moeten vinden, niet alleen verkopers van support.

Ok, ik begrijp wat je zegt. Wat dat betreft is het gebeuren wellicht ook meer een total drama island gedoe en wat minder iets wat daadwerkelijk veel gevolgen zal hebben.

Dat ZFS voor iedereen interessant moet zijn is een gegeven. De mensen van BSD vonden het jammer dat hun ZFS feature uitvloeide buiten BSD maar moedige het zeker aan.

[Compizfox]

Hero of Time schreef op dinsdag 01 maart 2016 @ 12:24:
[...]

Heb je een bron waar dat staat? Want ik zie nog steeds de gesloten drivers in de repo staan en ze zouden een hele hoop gebruikers (waaronder ik) tegen de schenen schoppen als ze 'm er echt uit halen. Ze hebben een non-free sectie voor een reden. Ik hoop dat je dat bedoelt, dat 't niet in main of contrib zit.

Een paar dagen geleden werd er een proprietary driver ontdekt in de kernel. Die is toen, zover ik begreep, direct verwijderd. Het gaat dus niet om een losse package.

EDIT: Dit klopt niet. Het ging wel om een package (namelijk nvidia-graphics-modules), maar die package bevatte pre-built proprietary kernel modules.

Echter, normaal gesproken wordt altijd de -dkms package gebruikt, niet de pre-built variant. Voor gebruikers zou dit dus geen grote invloed hebben.

Bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815060
Reddit threads: https://www.reddit.com/r/...olates_kernel_license_in/
https://www.reddit.com/r/...y_were_shipping_prebuilt/

[ Voor 33% gewijzigd door Compizfox op 06-03-2016 13:35 ]

[Hero of Time]

Oooohh, is dat alles? Man, laat mensen niet meer zo schrikken!

[Blokker_1999]

Bah, net gemerkt dat men Plasma 5 voor een zoveelste keer gecrashed is. Misschien toch maar eens in de logs gaan duiken want vind het niet leuk.

[Hero of Time]

Blokker_1999 schreef op zaterdag 05 maart 2016 @ 19:57:
Bah, net gemerkt dat men Plasma 5 voor een zoveelste keer gecrashed is. Misschien toch maar eens in de logs gaan duiken want vind het niet leuk.

Welke videokaart heb je en welke driver daar voor? Ik heb op m'n Intel laptop zo goed als geen problemen. De paar die ik had met 5.3/5.4 heb ik sinds 5.5 niet meer gezien. *klopt even af*

[Blokker_1999]

In dit geval een nVidia GTX970 met de drivers uit experimental

[janwillemCA]

Blokker_1999 schreef op zondag 06 maart 2016 @ 12:48:
In dit geval een nVidia GTX970 met de drivers uit experimental

Vreemd! Heb zelf ook een GTX 970 i.c.m Arch Linux en Plasma 5.5. Ik heb eigenlijk geen crashed gehad..

Drivers die ik heb zijn de meest recente van Nvidia zelf!

[ Voor 9% gewijzigd door janwillemCA op 06-03-2016 13:31 ]

[Hero of Time]

Ik heb Kwin op m'n HTPC als vervanger voor Compiz, want die laatste ging nog wel eens uit z'n dak waardoor m'n GUI helemaal niet meer reageerde. Nu ik Kwin 5.5.4 uit Experimental heb gehaald heb ik de paar crashes die het bij mij had eigenlijk niet meer gezien. Met 5.4 had ik nog wel eens dat als een venster in het midden van de dual screen config werd geplaatst, het crashte.

En ik gebruik overigens ook nVidia (GT 610) op deze PC. Wel de driver in Unstable.

[gekkie]

Hmm wellicht toch maar wat dingen over gaan zetten naar stretch .. voor http/2 (>openssl 1.0.2 nodig en die zit weer niet in Jessie helaas) en php7.

[CAPSLOCK2000]

Ik heb net m'n werk-desktop geupdate en ben na een uitstapje van een half jaar weer terug bij KDE, versie 5.4 om precies te zijn. Wat een verademing, het werkt weer heerlijk en het ziet er goed uit. De vorige keer had ik wat problemen met Nouveau-drivers bij 3d-acceleratie van meerdere schermen met nogal verschillende eigenschappen. Nu gaat het gewoon helemaal goed, afgezien van dat ik even moest aangeven dat een bepaald scherm in portrait-mode staat.
Alles ziet er super strak uit en het reageert heel "snappy", ik hoef nooit meer te wachten op feedback. Als ik op het knopje druk dan gebeurt er onmiddellijk iets, waar ik voorheen nog wel eens een paar seconde op feedback moest wachten.

[narotic]

gekkie schreef op zondag 06 maart 2016 @ 22:58:
Hmm wellicht toch maar wat dingen over gaan zetten naar stretch .. voor http/2 (>openssl 1.0.2 nodig en die zit weer niet in Jessie helaas) en php7.

Misschien makkelijker om gewoon een mixed systeem te proberen via apt-pinning? OpenSSL haalt hier geen verdere dependencies binnen. PHP7 weet ik dan weer niet.

[vanaalten]

Mja, zo'n mixed systeem is ook niet altijd een aanrader.
Ten tijde van 'Wheezy' ben ik ook zo'n mixed setup begonnen - waarom en voor wat weet ik niet eens meer - en nu heeft mijn 'Jessie' setup nog steeds RoundCube, waarschijnlijk uit de Wheezy tijd, die dus niet echt meer bijgehouden wordt. Totdat ik overga op Stretch, denk ik - dan wordt het even spannend of de update goed gaat.

[Hero of Time]

Maak geen FrankenDebian!

quote: https://wiki.debian.org/DontBreakDebian

Repositories that can create a FrankenDebian if used with Debian Stable:

• Debian testing release (currently stretch)
• Debian unstable release (also known as sid)
• Ubuntu, Mint or other derivative repositories are not compatible with Debian!
• Ubuntu PPAs

Het mengen van Testing/Unstable met een Stable release is vragen om problemen. Beter ga je kijken in Backports. En anders wacht je nog een jaar, volgend jaar voorjaar komt Stretch waarschijnlijk uit.

[Vicarious]

CAPSLOCK2000 schreef op maandag 07 maart 2016 @ 18:19:
Ik heb net m'n werk-desktop geupdate en ben na een uitstapje van een half jaar weer terug bij KDE, versie 5.4 om precies te zijn. Wat een verademing, het werkt weer heerlijk en het ziet er goed uit. De vorige keer had ik wat problemen met Nouveau-drivers bij 3d-acceleratie van meerdere schermen met nogal verschillende eigenschappen. Nu gaat het gewoon helemaal goed, afgezien van dat ik even moest aangeven dat een bepaald scherm in portrait-mode staat.
Alles ziet er super strak uit en het reageert heel "snappy", ik hoef nooit meer te wachten op feedback. Als ik op het knopje druk dan gebeurt er onmiddellijk iets, waar ik voorheen nog wel eens een paar seconde op feedback moest wachten.

Het viel mij ook al op dat KDE sinds versie 5 weer een stuk sneller aanvoelt. Tot dusverre bevalt mijn Manjaro KDE dan ook prima. Enige wat ik nog wel eens heb is dat die system tray icoontjes wel eens raar doen (heb ik bijvoorbeeld ineens een minuscuul USB icoontje staan).

[gekkie]

Als het een enkel pakket is dat ook compileert met oudere versies van libs, dan pak ik nog wel eens een stretch source pakket en rebuild die. Maar als ik zowel ssl als nginx / apache als php moet gaan vervangen op een VM die eigenlijk alleen die zaken draait .. mjah dan is een update naar stretch wel handiger. Daarbij is de ergste hausse na de freeze en release van Jessie nu wel voorbij en wordt niet alles meer na genoeg tegelijk in heel hoog tempo geupdate.

[Compizfox]

vanaalten schreef op maandag 07 maart 2016 @ 23:25:
Mja, zo'n mixed systeem is ook niet altijd een aanrader.
Ten tijde van 'Wheezy' ben ik ook zo'n mixed setup begonnen - waarom en voor wat weet ik niet eens meer - en nu heeft mijn 'Jessie' setup nog steeds RoundCube, waarschijnlijk uit de Wheezy tijd, die dus niet echt meer bijgehouden wordt. Totdat ik overga op Stretch, denk ik - dan wordt het even spannend of de update goed gaat.

Als ik het me goed herinner is Roundcube uit Stretch verwijderd omdat niemand het meer bijhield. Tegenwoordig moet het dus handmatig installeren (wat overigens niet zo'n probleem is; het is maar een PHP-app).

[Hero of Time]

Oh? Issie weg? Vreemd wat ik dan hier vind.

$ apt-cache search roundcube
roundcube - skinnable AJAX based webmail solution for IMAP servers - metapackage
roundcube-core - skinnable AJAX based webmail solution for IMAP servers
roundcube-mysql - metapackage providing MySQL dependencies for RoundCube
roundcube-pgsql - metapackage providing PostgreSQL dependencies for RoundCube
roundcube-plugins - skinnable AJAX based webmail solution for IMAP servers - plugins
roundcube-sqlite3 - metapackage providing SQLite dependencies for RoundCube
roundcube-plugins-extra - skinnable AJAX based webmail solution - extra plugins

[gekkie]

Mik het in zo'n geval meestal door de https://packages.debian.o...mes&suite=all&section=all

Gelijk een overzicht van alle versies in alle versies en of er toevallig officiele backports zijn.

[Compizfox]

Hero of Time schreef op dinsdag 08 maart 2016 @ 13:23:
Oh? Issie weg? Vreemd wat ik dan hier vind.

$ apt-cache search roundcube
roundcube - skinnable AJAX based webmail solution for IMAP servers - metapackage
roundcube-core - skinnable AJAX based webmail solution for IMAP servers
roundcube-mysql - metapackage providing MySQL dependencies for RoundCube
roundcube-pgsql - metapackage providing PostgreSQL dependencies for RoundCube
roundcube-plugins - skinnable AJAX based webmail solution for IMAP servers - plugins
roundcube-sqlite3 - metapackage providing SQLite dependencies for RoundCube
roundcube-plugins-extra - skinnable AJAX based webmail solution - extra plugins

Oh, ik wist niet dat ie weer terug was.

Zoals te zien valt in de tracker is hij begin december vorig jaar verwijderd en pas aan het eind van de maand weer teruggekomen. Dat is ook niet de eerste keer dat dat gebeurd is met Roundcube.

[ Voor 3% gewijzigd door Compizfox op 08-03-2016 16:46 ]

[gekkie]

Hmm beetje wat leuks flexibels vinden voor remote server monitoring valt ook nog niet mee .. zeker niet als het ook nog op enige honderden hosts moet werken (en enigzins overzichtelijk en configureerbaar moet zijn).

[CAPSLOCK2000]

AFAIK is de oude versie van Rouncube uit testing gehaald voordat Jessie uit kwam. Er is dus geen officiele Debian-versie van RoundCube voor Jessie. Er zit een veel nieuwere versie in unstable maar die is nog niet doorgedrongen tot testing. Aangezien er veel is veranderd zou dat wel eens lang kunnen gaan duren.
Deze packages zijn wel gebackport naar Jessie. Via Jessie Backports kun je ze dus wel krijgen maar zonder de gebruikelijke garanties van Debian.

[Hero of Time]

Unstable heeft versie 1.1.4+dfsg.1-2, Testing heeft 1-1. Dus het is wel degelijk doorgedrongen naar Testing/Stretch. Die in Unstable is pas 24 feb toegevoegd, aldus de changelog. Er is vast nog iets gevonden om niet na standaard 10 dagen wachten door naar Testing te gaan.

[Blokker_1999]

Hero of Time schreef op zondag 06 maart 2016 @ 16:16:
Ik heb Kwin op m'n HTPC als vervanger voor Compiz, want die laatste ging nog wel eens uit z'n dak waardoor m'n GUI helemaal niet meer reageerde. Nu ik Kwin 5.5.4 uit Experimental heb gehaald heb ik de paar crashes die het bij mij had eigenlijk niet meer gezien. Met 5.4 had ik nog wel eens dat als een venster in het midden van de dual screen config werd geplaatst, het crashte.

En ik gebruik overigens ook nVidia (GT 610) op deze PC. Wel de driver in Unstable.

Mag ik vragen hoe je die uit experimental hebt gehaald? Had gisteren avond het lumineuze idee om dat snel even zelf te doen maar heb daarna wel wat werk gehad om een rollback te doen daar ik blijkbaar een combinatie had aangemaakt die niet werkte.

[Hero of Time]

Blokker_1999 schreef op maandag 14 maart 2016 @ 08:10:
[...]

Mag ik vragen hoe je die uit experimental hebt gehaald? Had gisteren avond het lumineuze idee om dat snel even zelf te doen maar heb daarna wel wat werk gehad om een rollback te doen daar ik blijkbaar een combinatie had aangemaakt die niet werkte.

Heel simpel. Ik heb de entries die ik heb voor zowel Testing als Unstable uitgebreid met dezelfde regel maar dan Experimental als distro release naam. Vervolgens via Aptitude alles geselecteerd wat nodig was, want als je 't via apt-get doet trek je echt een beerput open vanwege depedency issues.

Je bent met kwin-x11 zelf, daarvan selecteer je versie 5.5.4 uit Experimental en zo ga je elke dependency af van Kwin, zoals kwin-data, kwin-common, kwin-decoration en kwin-style. Al het andere heb ik eigenlijk op de Unstable 5.4.3 gelaten omdat ik geen breakage meer had.

Eigenlijk is voor iedereen die Testing of Unstable draait van Debian verstandig om Aptitude te gaan gebruiken. Het geeft zo'n geweldig overzicht en is erg krachtig voor het oplossen van dependency issues, heerlijk. Zo kan je veel makkelijker zien wat er aan gezeik is als je multi-arch draait en een package heeft nog geen tweede arch build, waardoor je mogelijk 100 removals voor je neus hebt dat met 1 keep al opgelost wordt.

Voor de package weergave gebruik ik overigens het volgende filter:

aptitude::UI::Default-Grouping "task,status,pattern(?narrow(~i,!~U !~Atesting~|unstable~|experimental !~OOpera~|PPA~|Oracle) => Local Version, ~O, !~O => N/A)";

Wat het doet is een lijstje geven met taken en de status van packages. Binnen in de status wordt het weer verder verdeeld. De query zoekt naar alles dat geïnstalleerd is, maakt daar de subgroepen aan voor de Origin (PPA, Testing, Unstable, etc), wat daar niet aan voldoet is dus niet meer in een repo te vinden en komt in een eigen sectie genaamd 'N/A'. Maar daarvan wordt eerst gekeken of het niet een upgradable is, in Testing, Unstable, Experimental archieven zit, de Origin de tekst Opera of PPA bevat en dat dan een groep genaamd 'Local Version' gezet.
Ik heb het wat warrig omschreven, maar het punt is, dat ik zo snel kan zien zien of een package die ik mogelijk uit Experimental heb gehaald een nieuwe versie heeft of als versie niet meer beschikbaar, maar nog wel een andere versie in de repo. Dat komt dan in 'N/A'. Is iets helemaal niet meer aanwezig in de repo's, of los geïnstalleerd (denk aan Skype) dan komt het in 'Local Version'. Beste is om het zelf toe te passen en zien wat 't doet.

[Blokker_1999]

Zal het zeker eens bekijken

dank

[vanaalten]

FFFFUUUUU....
wil wat files & directories recursief chown-en:

code:

chown -R sickrage:sickrage *

... wat echter dan niet de hidden files & directories doet. Dacht ik slim te zijn:

code:

chown -R sickrage:sickrage .*

... wat dus meteen een directory hoger pakte (want, ".." valt ook onder de ".*"), wat dus directory /home was. Even een uurtje bezig geweest met allerlei dingen terugzetten naar de rechtmatige eigenaar.

[Hero of Time]

Als /home een andere eigenaar krijgt, is dat toch geen ramp? Je zet /home weer op root:root, eventueel lost+found ook in geval het een aparte partitie/schijf is en daarna een chown -R voor de gebruiker van wie de specifieke /home/map is. Zou je nog geen 10 minuten moeten kosten.

Ik heb ook een leuke, weer een puntje van KDE Plasma 5. Ik heb voor Debian kernel 4.5 uit de Experimental repo gehaald. Was eerst rc4, vorige week werd dat rc7 (momenteel niet nieuwer). Had ik op m'n werklaptop eerst staan, zette de laptop in slaapstand, werkte dat niet. Dacht dus dat er iets in de kernel was verandert. Doe als test hetzelfde met m'n HTPC en dat werkte wel gewoon. Nu verdenk ik KDE ervan, want m'n HTPC draait Xfce. Kan uiteraard ook de laptop zelf zijn, maar oudere kernels zoals 4.4 gaan wel gewoon naar slaapstand. Eigenlijk niet verder getest door even een pm-suspend uit te voeren, maar ach. 'Morgen' misschien eens kijken terwijl ik op de pakketdienst wacht.

[vanaalten]

Hero of Time schreef op vrijdag 18 maart 2016 @ 00:07:
Als /home een andere eigenaar krijgt, is dat toch geen ramp? Je zet /home weer op root:root, eventueel lost+found ook in geval het een aparte partitie/schijf is en daarna een chown -R voor de gebruiker van wie de specifieke /home/map is. Zou je nog geen 10 minuten moeten kosten.

/home was het probleem ook niet - wel de mappen daaronder, die van een drietal system users waren en waarbij er bestanden niet consequent van de eigenaar waren van die map. Bestanden onder /home/X konden van gebruiker Y zijn (en waren nu ineens van gebruiker Z). Ja, rommelig, wellicht niet handig opgezet. Maar zolang je geen foute recursieve chown-dingen doet gaat het goed...

[Hero of Time]

vanaalten schreef op vrijdag 18 maart 2016 @ 09:10:
[...]

/home was het probleem ook niet - wel de mappen daaronder, die van een drietal system users waren en waarbij er bestanden niet consequent van de eigenaar waren van die map. Bestanden onder /home/X konden van gebruiker Y zijn (en waren nu ineens van gebruiker Z). Ja, rommelig, wellicht niet handig opgezet. Maar zolang je geen foute recursieve chown-dingen doet gaat het goed...

En wat heb je dus hiervan geleerd? Juist, laat alles in /home van maar 1 gebruiker zijn waar het hoort en ga niet mengen. Daar zijn groepen voor uitgevonden.

[himlims_]

vanaalten schreef op donderdag 17 maart 2016 @ 23:05:
FFFFUUUUU....
wil wat files & directories recursief chown-en:

code:

chown -R sickrage:sickrage *

... wat echter dan niet de hidden files & directories doet. Dacht ik slim te zijn:

code:

chown -R sickrage:sickrage .*

... wat dus meteen een directory hoger pakte (want, ".." valt ook onder de ".*"), wat dus directory /home was. Even een uurtje bezig geweest met allerlei dingen terugzetten naar de rechtmatige eigenaar.

fyi; je hoeft de groep niet te specificeren wanneer die 1:1 is aan de username

dus een chmod -R shickrage: * is toereikend

[vanaalten]

Ah, leerzaam! (al zou het zomaar kunnen dat ik die tip over een half jaar weer vergeten ben, zo vaak chown ik niet).

[begintmeta]

himlims_ schreef op vrijdag 18 maart 2016 @ 10:44:
...

fyi; je hoeft de groep niet te specificeren wanneer die 1:1 is aan de username

dus een chmod -R shickrage: * is toereikend

Volgens mij impliceert : de login-groep, niet noodzakelijk de 'username-groep'

Verder is shickrage wel een aparte 'file mode bit-configuratie'

[Hero of Time]

Als je 'chown <user>:' doet, dan wordt bij het achterwege laten van de groep de standaard/primaire groep gebruikt van die gebruiker, het GID als je 'id' uitvoert op de command line. Dit dus:

$ id lightdm
uid=102(lightdm) gid=105(lightdm) groups=105(lightdm)
$ id
uid=1000(sasquatch) gid=1000(sasquatch) groups=1000(sasquatch),4(adm),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),107(vboxusers)

Zie ook /etc/passwd, waarbij het nummeriek staat aangegeven, gebruikersnaam:x:uid:gid:omschrijving:home:shell.

[d1ng]

Hero of Time schreef op vrijdag 18 maart 2016 @ 23:02:
Als je 'chown <user>:' doet, dan wordt bij het achterwege laten van de groep de standaard/primaire groep gebruikt van die gebruiker, het GID als je 'id' uitvoert op de command line. Dit dus:

$ id lightdm
uid=102(lightdm) gid=105(lightdm) groups=105(lightdm)
$ id
uid=1000(sasquatch) gid=1000(sasquatch) groups=1000(sasquatch),4(adm),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),107(vboxusers)

Zie ook /etc/passwd, waarbij het nummeriek staat aangegeven, gebruikersnaam:x:uid:gid:omschrijving:home:shell.

Dit werkt overigens alleen zo op Linux. Op andere OS-en wordt het gewoon genegeerd als je de group veld leeglaat. Dat is op zijn minst zo op OS X, FreeBSD en OpenBSD.

[begintmeta]

d1ng schreef op zaterdag 19 maart 2016 @ 00:52:
[...]


Dit werkt overigens alleen zo op Linux. Op andere OS-en wordt het gewoon genegeerd als je de group veld leeglaat. Dat is op zijn minst zo op OS X, FreeBSD en OpenBSD.

Vziw interpreteert alleen de gnu-versie van chown de dubbele punt achter de gebruikersnaam zonder groep zo (zal wellicht ook wel eens op een niet-Linux os draaien). Sommige Chowns gebruiken overigens nog de punt in plaats van de dubbelepunt.

[Hero of Time]

Grrrr, %^*$I&# KDE en Intel video. En mogelijk ook Dell, aangezien het om m'n werklaptop gaat. Het had na de lunch al de grap om het lock scherm niet fatsoenlijk naar voren te brengen, waardoor je dus nog gewoon kon zien wat ik allemaal open had staan. Directe interactie met de vensters was dan weer niet mogelijk. Maar even ontgrendelen ging dus ook niet totdat het klaar was met weet ik veel wat het aan het doen was.
Daarna was 't tijd om naar huis te gaan. Dus, laptop naar slaapstand, dichtklappen en inpakken. Nou, dat had je gedacht. Dat *piep* *censuur* ding deed dus helemaal niets. Het bleef dom aan. Wisselen van TTY wilde 't dan nog wel, maar echt zinvol was 't niet. 1x de power knop indrukken deed ook niets, het triggerde geen shutdown zoals 't zou moeten. Heb dus de laptop maar uit z'n docking gehaald en de accu even losgemaakt. Had haast ivm trein halen enzo.

Morgenochtend maar gelijk kijken wat voor verschil het maakt als ik SDDM eraf trap en LightDM weer ga gebruiken. Ik dacht eerst nog dat KDE de oorzaak was van het niet naar slaapstand gaan met kernel 4.5rc7, maar ook m'n Xfce sessie weigerde dienst. Nu verdenk ik SDDM, mede ook omdat die het lockscherm verzorgt.

Naja, het heet niet voor niets Debian Unstable.

[gekkie]

Zit systemD er niet ook nog ergens tussen qua suspend ?

[Hero of Time]

Ja, maar m'n HTPC en gewone PC suspenden wel gewoon. Dus het enige verschil tussen m'n laptop en HTPC (die heeft wel 4.5rc7 draaien) is de videokaart en algemene rest van de hardware. M'n PC is AMD, HTPC is Intel. Goed, eigenlijk is alles anders tussen al m'n systemen, want de CPU is niet hetzelfde type enzo, maar dan nog. Systemd is iig niet de boosdoener hier. Het is de DE of DM en verdenk dus de DM aangezien m'n Xfce sessie ook faalde met de 4.5rc7 suspend test.

[gekkie]

Relatief eenvoudige wissel gok ik ?

Hmm hier zo maar eens kijken of ik nieuwe mesa packages voor sid gebakken krijg.

[narotic]

Hero of Time schreef op maandag 21 maart 2016 @ 20:03:
Heb dus de laptop maar uit z'n docking gehaald en de accu even losgemaakt. Had haast ivm trein halen enzo.

Als je 'm op je toetsenbord weet te vinden, dan is SysRq met combinatie REISUO net iets netter in zo'n situatie. Wel even controlleren of de default bitmask in Debian deze allemaal toestaat.

[Hero of Time]

gekkie schreef op maandag 21 maart 2016 @ 22:18:
Relatief eenvoudige wissel gok ik ?

Jep, zo eenvoudig als aptitude purge sddm en aptitude install lightdm.

Hmm hier zo maar eens kijken of ik nieuwe mesa packages voor sid gebakken krijg.

Welke versie wil je? Ik zie 11.2.0rc3 in Experimental staan.

narotic schreef op dinsdag 22 maart 2016 @ 00:35:
[...]


Als je 'm op je toetsenbord weet te vinden, dan is SysRq met combinatie REISUO net iets netter in zo'n situatie. Wel even controlleren of de default bitmask in Debian deze allemaal toestaat.

Die combo ken ik niet uit m'n hoofd en had ik geen zin/tijd voor.

Laptop begon vanochtend wel doodleuk dat het systeem uitgeschakeld was vanwege oververhitting. Dat betwijfel ik, want ik had de accu eruit getrokken en deze is nu nog 100%. De laptop is dus niet later weer aan gegaan. Dom ding, misschien eens kijken naar een firmware update of wat dan ook, want ook met LightDM en een Xfce sessie deed de suspend met 4.5rc7 het niet.

[gekkie]

Hero of Time schreef op dinsdag 22 maart 2016 @ 08:15:
[...]
Welke versie wil je? Ik zie 11.2.0rc3 in Experimental staan.

Upstream .. probeer openCL aan de praat te krijgen .. maar dat wil nog niet echt.
Waren nog wat wijzigingen voor clover upstream .. dus dat eerst proberen .. en anders nog een suggestie tot wijziging uitproberen. Compileren duurt alleen wel even ...
En anders maar weer proberen die fglrx meuk geinstalleerd te krijgen .. bweh.

Laptop begon vanochtend wel doodleuk dat het systeem uitgeschakeld was vanwege oververhitting. Dat betwijfel ik, want ik had de accu eruit getrokken en deze is nu nog 100%. De laptop is dus niet later weer aan gegaan. Dom ding, misschien eens kijken naar een firmware update of wat dan ook, want ook met LightDM en een Xfce sessie deed de suspend met 4.5rc7 het niet.

Hmm daarom zet ik laptop altijd gewoon uit uit. Die paar seconden opstarten overleef ik ook wel.

[Hero of Time]

Het gaat mij niet om het opstarten, dat gaat ook wel lekker snel. Maar ik heb vaak meerdere dingen nog open staan en het is gewoon fijn om niet elke keer weer 10 dingen te openen. Vooral als je een browser met net iets te veel tabs hebt en met je ticketing systeem waar je elke keer dat je de browser herstart opnieuw moet inloggen.

[gekkie]

Altijd opnieuw inloggen .. maar wel semi-oneindige sessies heeft zonder communicatie ? :x

[ Voor 12% gewijzigd door gekkie op 22-03-2016 11:27 ]

[Compizfox]

[begintmeta]

RedHat overtreft de verwachtingen, een goed teken voor de hele 'NOS-sector'? Of het begin van het einde?

[gekkie]

Hmmm zal vooral zijn "hangt er van af wat ze er mee doen".Niet alles wat ze doen is om over naar huis te schrijven, aan de andere kant is ook zeker niet alles slecht wat ze doen.
Grootste probleem zou kunnen zijn dat hun grip op sommige projecten alleen maar zal stijgen, in combinatie met, een niet altijd even grote "smaak" in de gekozen oplossing / richting.

[Hero of Time]

begintmeta schreef op woensdag 23 maart 2016 @ 19:15:
RedHat overtreft de verwachtingen, een goed teken voor de hele 'NOS-sector'? Of het begin van het einde?

Bah:

To Read the Full Story, Subscribe or Sign In

Wat een nare site. Zonder account kan je maar 3 zinnen lezen.


Ik ga m'n werklaptop eens omzetten van KDE naar Xfce, want vandaag had ik weer wat issues waarbij de hele GUI niet meer reageerde zonder enige aanleiding. Enige wat ik wilde doen, was een .tgz van 600 MB openen vanuit Dolphin. Wisselen naar een TTY gaf een mooi zwart scherm met een knipperende _ en dat was 't. Zelfs een C-A-D deed niets. Heb de laptop hard moeten uitzetten om er weer leven in te krijgen.

Omdat m'n PC en HTPC beide Debian Unstable draaien, geloof ik niet dat het aan Debian ligt. Het kan daarentegen wel aan KDE liggen, maar omdat kernel 4.5 niet wil suspenden, zelfs met LightDM en een Xfce sessie wat op m'n HTPC wel werkt, vermoed ik eerder dat de hardware de schuldige is. Morgen ook maar even aan onze IT afdeling vragen of ze vergelijkbare dingen hebben gezien met mijn type laptop. Daarna maar het BIOS updaten als dat kan en afwachten of dat de problemen oplost.

[silverball]

Aargh, de docent is fanatiek Linux gebruiker (teminste dat denkt hij) , fan van libreoffice, maar wil alleen .docx bestanden aannemen in z'n mailbox. Niet mijn .odt's

[begintmeta]

silverball schreef op donderdag 24 maart 2016 @ 09:56:
Aargh, de docent is fanatiek Linux gebruiker (teminste dat denkt hij) , fan van libreoffice, maar wil alleen .docx bestanden aannemen in z'n mailbox. Niet mijn .odt's

Als het een publiekrechtelijke onderwijsinstelling is: zouden die niet zoveel mogelijk open formaten moeten nastreven, ik meen dat daarover een aanwijzing vanuit de overheid bestaat. En zijn er geen instellingsrichtlijnen?

[Hero of Time]

silverball schreef op donderdag 24 maart 2016 @ 09:56:
Aargh, de docent is fanatiek Linux gebruiker (teminste dat denkt hij) , fan van libreoffice, maar wil alleen .docx bestanden aannemen in z'n mailbox. Niet mijn .odt's

Dan hernoem je die documenten toch naar .odt.docx ofzo. Hij blij. Of als hij dan toch alles in LibreOffice opent, met MS Office 2013 zeer uitgebreide opmaak gebruiken, tekstvakken e.d. zodat het in LO er niet meer uit ziet.

[silverball]

Ach ja. Het is zo verschrikkelijk irritant. Hij gebruikt Libreoffice, Ik gebruik het, maar nee ik moet het toch als .docx opslaan. Beetje zonde van de opmaak die dan vaak door elkaar wordt geharkt.

[Hero of Time]

Des te beter om zo eens wat aan te leveren, waarbij je natuurlijk ook gewoon het .odt hebt dat wel fatsoenlijk is gemaakt.

[idef1x]

Hero of Time schreef op woensdag 23 maart 2016 @ 21:08:

Ik ga m'n werklaptop eens omzetten van KDE naar Xfce, want vandaag had ik weer wat issues waarbij de hele GUI niet meer reageerde zonder enige aanleiding. Enige wat ik wilde doen, was een .tgz van 600 MB openen vanuit Dolphin. Wisselen naar een TTY gaf een mooi zwart scherm met een knipperende _ en dat was 't. Zelfs een C-A-D deed niets. Heb de laptop hard moeten uitzetten om er weer leven in te krijgen.

Omdat m'n PC en HTPC beide Debian Unstable draaien, geloof ik niet dat het aan Debian ligt. Het kan daarentegen wel aan KDE liggen, maar omdat kernel 4.5 niet wil suspenden, zelfs met LightDM en een Xfce sessie wat op m'n HTPC wel werkt, vermoed ik eerder dat de hardware de schuldige is. Morgen ook maar even aan onze IT afdeling vragen of ze vergelijkbare dingen hebben gezien met mijn type laptop. Daarna maar het BIOS updaten als dat kan en afwachten of dat de problemen oplost.

Ik zat in ongeveer hetzelfde schuitje..Welliswaar met Kubuntu 15.10, maar ten 1e kon ik niet echt aan dat plasma wennen, maar erger was dat het grafisch niet denderend werkte. En ik heb dan een Nvidia kaart in mijn laptop. Even naar een tty schakelen en grafisch een mondriaan op beeld waar ik niets meer mee kon. Soms uit resume mode (ging bij mij wel in slaapstand) zelfde verhaal en moest maar weer eens sddm een schop geven om het goed te krijgen (wel sessie pleite).
Uiteindelijk heb ik maar na jarenlang toch wel weer fan te zijn geworden van KDE, de boel eraf gegooid en xubuntu erop gezet (met lightdm) en alles werkt weer normaal. Op zich jammer dat KDE ruk werkte, want gebruik best wel KDE programma's (digikam, kdenlive, gwenview en uiteraard dolphin waar niets anders nog aan kan tippen m.i.)
Afijn het draait nu weer prima, dus laat KDE maar eerst weer eens uitkristalizeren er ik het nog eens probeer.

Mijn enige plasma die ik nog hou is mijn TV

[Lye]

silverball schreef op donderdag 24 maart 2016 @ 09:56:
Aargh, de docent is fanatiek Linux gebruiker (teminste dat denkt hij) , fan van libreoffice, maar wil alleen .docx bestanden aannemen in z'n mailbox. Niet mijn .odt's

Een docent die docx of odt accepteert kan ik niet serieus nemen. Jij levert iets in, dus het is een "gepubliceerd" document, daar bestaat pdf voor.

[silverball]

Lye schreef op donderdag 24 maart 2016 @ 12:29:
[...]


Een docent die docx of odt accepteert kan ik niet serieus nemen. Jij levert iets in, dus het is een "gepubliceerd" document, daar bestaat pdf voor.

Ach zolang hij geen PDF's wil hebben....

[begintmeta]

Lye schreef op donderdag 24 maart 2016 @ 12:29:
...

Een docent die docx of odt accepteert kan ik niet serieus nemen. Jij levert iets in, dus het is een "gepubliceerd" document, daar bestaat pdf voor.

Afhankelijk van het proces wil men nog wel eens voor annotaties, opmerkingen, feedback (-cycli) etc, ondanks dat het uiteraard niet nodig is, gebruik maken van tekstverwerkers en 'bijbehorende bestanden'.

[ Voor 4% gewijzigd door begintmeta op 24-03-2016 12:37 ]

[Lye]

begintmeta schreef op donderdag 24 maart 2016 @ 12:36:
[...]

Afhankelijk van het proces wil men nog wel eens voor annotaties, opmerkingen, feedback (-cycli) etc, ondanks dat het uiteraard niet nodig is, gebruik maken van tekstverwerkers en 'bijbehorende bestanden'.

Het probleem is, zeker in het onderwijs, dat niet iedreen gebruik maakt van standaard tekstverwerkers. Ik kan mij heel goed voorstellen dat niet elke tekstverwerker geschikt is voor dergelijke annotaties.
Ik persoonlijk heb niet eens een tekstverwerker geinstalleerd, voor 9 van de 10 verslagen vind ik LaTeX beter werken.

[begintmeta]

Lye schreef op donderdag 24 maart 2016 @ 12:45:
...

Het probleem is, zeker in het onderwijs, dat niet iedreen gebruik maakt van standaard tekstverwerkers. Ik kan mij heel goed voorstellen dat niet elke tekstverwerker geschikt is voor dergelijke annotaties.
Ik persoonlijk heb niet eens een tekstverwerker geinstalleerd, voor 9 van de 10 verslagen vind ik LaTeX beter werken.

Ik vind latex op zich ook prima (en zit niet eens in de beta-hoek, waar dat toch wat gangbaarder is), maar heb wel drie tekstverwerkers geinstalleerd.

Hoe geef jij doorgaans een comentaar-cyclus in latex of pdf vorm?

Uiteindelijk is printen en op papier werken toch het handigste.

[ Voor 5% gewijzigd door begintmeta op 24-03-2016 12:56 ]

[Blokker_1999]

begintmeta schreef op donderdag 24 maart 2016 @ 10:13:
[...]

Als het een publiekrechtelijke onderwijsinstelling is: zouden die niet zoveel mogelijk open formaten moeten nastreven, ik meen dat daarover een aanwijzing vanuit de overheid bestaat. En zijn er geen instellingsrichtlijnen?

Alleen is .docx ook een open formaat. Dus daar kan je het al niet op steken.

[begintmeta]

Blokker_1999 schreef op donderdag 24 maart 2016 @ 13:04:
...
Alleen is .docx ook een open formaat. Dus daar kan je het al niet op steken.

Dat kan je eventueel wel zo betogen inderdaad, maar docx is primair gewoon een bestandsextensie, volgens mij kan het verschillen wat het bestand met die extensie bevat (eventueel ook ooxml transitional bijvoorbeeld), dus alleen het specificeren van de bestandsextensie zou dan wel wat tekortschieten.

[Lye]

begintmeta schreef op donderdag 24 maart 2016 @ 12:54:
[...]

Ik vind latex op zich ook prima (en zit niet eens in de beta-hoek, waar dat toch wat gangbaarder is), maar heb wel drie tekstverwerkers geinstalleerd.

Hoe geef jij doorgaans een comentaar-cyclus in latex of pdf vorm?

Uiteindelijk is printen en op papier werken toch het handigste.

Niet dat ik vaak in dergelijke situaties heb gezeten. Echter ging feedback bij mij meestal gewoon in de vorm van email met evt. een bijlage met notities.
Een enkele keer ook via annotaties in de pdf zelf (Waar Evince ook support voor heeft). Echter vind ik dit, samen met de commentaar functie in tekstverwerkers, persoonlijk hoogst onhandig werken. Doe mij maar een los bestand met daarin de feedback.

[Compizfox]

silverball schreef op donderdag 24 maart 2016 @ 09:56:
Aargh, de docent is fanatiek Linux gebruiker (teminste dat denkt hij) , fan van libreoffice, maar wil alleen .docx bestanden aannemen in z'n mailbox. Niet mijn .odt's

Niet relevant. Verslagen (of andere documenten) inleveren doe je in PDF

---

begintmeta schreef op donderdag 24 maart 2016 @ 12:36:
[...]

Afhankelijk van het proces wil men nog wel eens voor annotaties, opmerkingen, feedback (-cycli) etc, ondanks dat het uiteraard niet nodig is, gebruik maken van tekstverwerkers en 'bijbehorende bestanden'.

Annotaties kan volgens mij ook in PDF.

[ Voor 34% gewijzigd door Compizfox op 24-03-2016 16:38 ]

[silverball]

Compizfox schreef op donderdag 24 maart 2016 @ 16:36:
[...]

Niet relevant. Verslagen (of andere documenten) inleveren doe je in PDF

Die wilt hij niet hebben gek genoeg
Echt alleen .docx

[pjlgt]

Oude laptop maar eens compleet leeg gepoetst en weer eens aan de Linux. Gebruikte in het verleden meestal Ubuntu of Mint, maar nu gekozen voor Fedora. Helaas out-of-the-box geen support voor de broadcom wifi card (Mint 17 trouwens ook niet), maar Google bracht antwoord. Nu maar eens verder met experimenteren. Als het bevalt, gaat ook de Ubuntu file server (Plex, Transmission, Samba) nog over naar CentOS

[Verwijderd]

pjlgt schreef op vrijdag 25 maart 2016 @ 13:44:

Oude laptop maar eens compleet leeg gepoetst en weer eens aan de Linux. Gebruikte in het verleden meestal Ubuntu of Mint, maar nu gekozen voor Fedora. Helaas out-of-the-box geen support voor de broadcom wifi card (Mint 17 trouwens ook niet), maar Google bracht antwoord. Nu maar eens verder met experimenteren. Als het bevalt, gaat ook de Ubuntu file server (Plex, Transmission, Samba) nog over naar CentOS

Recent ook Fedora ontdekt en ben er erg enthousiast over. Het is allemaal brand nieuw en ook stabiel.

Dit soort van Top x after install handleidingen zijn ook must reads. Al hoeft je in Fedora niet zo heel veel in te stellen na de installatie. http://www.2daygeek.com/t...ter-installing-fedora-23/

[onox]

Compizfox schreef op donderdag 24 maart 2016 @ 16:36:
Niet relevant. Verslagen (of andere documenten) inleveren doe je in PDF

Lye schreef op donderdag 24 maart 2016 @ 12:29:
Jij levert iets in, dus het is een "gepubliceerd" document, daar bestaat pdf voor.

Mee eens Als je een foto wilt delen, dan stuur je toch ook niet het .xcf/.psd bestand?

Lye schreef op donderdag 24 maart 2016 @ 12:45:
Ik persoonlijk heb niet eens een tekstverwerker geinstalleerd, voor 9 van de 10 verslagen vind ik LaTeX beter werken.

Heb hetzelfde. Toen ik op de universiteit LaTeX ontdekte ging er een wereld voor mij open. Geen last meer van die troll acties van (Libre)Office die denken van "hey onox, ik ben vandaag in een ontzettend lollige bui, laat ik dit stukje tekst eens ff een andere lettergrootte geven. Oh, en dan maak ik dit stukje tekst even bold voor je, vind je vast wel leuk ".

Zelfs voor presentaties heb ik nu LibreOffice aan de kant gezet en ben LaTeX Beamer gaan gebruiken. Ik kan nu voor de slides gewoon m'n favoriete teksteditor gebruiken en het bewerken van slides gaat bij mij gewoon sneller dan al dat gemuis in Office. Bovendien kan ik m'n slides nu in git gooien

@silverball: ik weet niet precies wat voor opleiding je doet, maar volgend verslag gewoon: LaTeX + IEEE two column layout + waslijst van referenties m.b.v. bibtex. Dan is ie wel even stil

[Hero of Time]

onox schreef op vrijdag 25 maart 2016 @ 21:56:
Mee eens Als je een foto wilt delen, dan stuur je toch ook niet het .xcf/.psd bestand?

Het eerste fototoestel dat in .psd opslaat moet nog uitgevonden worden, dus dat zou knap zijn. Nee, ik zou dan de .jpg, .tiff of .raw gebruiken, afhankelijk wat het toestel aanbied.

Andere leuke editor is MarkDown. Plain text bewerken, maar met markup syntax die je alleen toegepast ziet worden in MD zelf. Kijk maar eens naar een willekeurig Github project.

[Compizfox]

Markdown vind ik zelf ook wel fijn. Veel fijner dan dat UBB dat we hier op GoT gebruiken in elk geval. Github, Reddit en StackExchange gebruiken allemaal Markdown.

[Raynman]

Markdown is wel leuk als UBB-alternatief (voor HTML-output), maar als je complexere documenten of zelfs boeken wilt maken, zou ik eerder naar AsciiDoc kijken.

[silverball]

Laatst op een eigenlijk veel te trage en moelijk werkbare Windows 7 netbook maar Debian, Gnome gezet. Eigenlijk is iedereen er wel enthousiast over. De interface komt hier echt tot zijn recht. Bovendien na 5 jaar een losse wifi stick erin te hebben gehad, werkt hier de wifi wel gewoon na het instellen van de drivers.

Eigenlijk had ik het veel eerder moeten doen. Windows 7 was lastig te bedienen op het lastige schermpje, en de installatie was rot. Nu is hij prima werkbaar en vlot zat.

[Blokker_1999]

Heb me er vorig jaar al eens bezig gehouden met een PXE netboot van de Debian Installer en had toen al de wens om een preseed mee te geven via http ipv in te bouwen in de initrd voor een project en liep toen al tegen het probleem aan dat deze mijn config niet ging ophalen.

Vandaag pik ik de draad weer op voor het groepswerk in school en loop ik nog altijd tegen hetzelfde probleem aan. Deze keer wat verder blijven zoeken naar de mogelijke oorzaken en dan ontdek je ineens dat hoewel er in de documentatie van Debian staat dat de parameters "auto url=http://server/preseed.cfg" voldoende moet zijn om het process op gang te trekken je toch net iets meer moet meegeven namelijk: "auto=true priotity=critical url=http://server/preseed.cfg"

[Hero of Time]

Zowaar, BIOS update gedaan van m'n laptop en kernel 4.5 doet nu wel netjes suspenden. Dat is iig dus opgelost.

Wat niet is opgelost is de vaagheden van Kwin op m'n HTPC. Net opende ik een terminal via de sneltoets en *poef* Kwin ging weer lekker keihard op z'n bek.

Edit:
De schoft. Wil m'n laptop naar suspend brengen om naar huis te kunnen, gaat de laptop alsnog uit na zo'n 20 seconden.

[ Voor 19% gewijzigd door Hero of Time op 29-03-2016 20:22 ]

[silverball]

Het is misschien makkelijk om de openingspost van "Het grote welk OS topic" te updaten indien mogelijk of eventueel zelfs een nieuw deel van dit topic te openen. De huidige is erg verouderd, en de plaatjes werken niet meer. Het zou erg handig zijn als er soms doorverwezen kan worden naar de openingspost. Veel informatie wordt vele keren opnieuw verteld, bovendien word het nu een beetje overtuigen ipv aanraden.

[Hero of Time]

silverball schreef op woensdag 30 maart 2016 @ 22:01:
Het is misschien makkelijk om de openingspost van "Het grote welk OS topic" te updaten indien mogelijk of eventueel zelfs een nieuw deel van dit topic te openen. De huidige is erg verouderd, en de plaatjes werken niet meer. Het zou erg handig zijn als er soms doorverwezen kan worden naar de openingspost. Veel informatie wordt vele keren opnieuw verteld, bovendien word het nu een beetje overtuigen ipv aanraden.

Gooi dan daar een balletje op, ipv hier.

[silverball]

Ja, das misschien een beter idee

[himlims_]

iemand ervaring met; http://www.linphone.org/n...upported-on-Linphone.html

heeft mijn intresse iig

[ Voor 60% gewijzigd door himlims_ op 31-03-2016 11:06 ]

[Compizfox]

apt upgrade (op Debian testing) wil de volgende zooi installeren.

code:

# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  i965-va-driver libaacs0 libavcodec-ffmpeg56 libavformat-ffmpeg56 libavutil-ffmpeg54 libbdplus0 libbluray1 libcrystalhd3 libdrm-amdgpu1 libdrm-intel1
  libdrm-nouveau2 libdrm-radeon1 libdrm2 libegl1-mesa libelf1 libgbm1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglu1-mesa libgme0 libllvm3.7
  libmodplug1 libmp3lame0 liborc-0.4-0 libpciaccess0 libschroedinger-1.0-0 libsdl2-2.0-0 libshine3 libsnappy1v5 libsndio6.1 libsoxr0 libssh-gcrypt-4
  libswresample-ffmpeg1 libswscale-ffmpeg3 libtheora0 libtwolame0 libtxc-dxtn-s2tc0 libv4l-0 libv4lconvert0 libva-x11-1 libva1 libvdpau-va-gl1 libvdpau1
  libwayland-client0 libwayland-cursor0 libwayland-egl1-mesa libwayland-server0 libx264-148 libx265-79 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0
  libxcb-present0 libxcb-randr0 libxcb-shape0 libxcb-sync1 libxcb-xfixes0 libxkbcommon0 libxshmfence1 libxss1 libxvidcore4 libxxf86vm1 libzvbi-common
  libzvbi0 mesa-vdpau-drivers php-symfony-polyfill-mbstring va-driver-all vdpau-driver-all vdpau-va-driver
The following packages will be upgraded:
  apt apt-utils binutils comerr-dev composer console-setup console-setup-linux cpp-5 cups cups-browsed cups-client cups-common cups-core-drivers
  cups-daemon cups-filters cups-filters-core-drivers cups-ppdc cups-server-common dash e2fslibs e2fsprogs fontconfig fontconfig-config g++-5 gcc-5
  gcc-5-base ghostscript keyboard-configuration libapt-inst2.0 libapt-pkg5.0 libasan2 libatomic1 libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libcc1-0
  libcilkrts5 libcomerr2 libcups2 libcupscgi1 libcupsfilters1 libcupsimage2 libcupsmime1 libcupsppdc1 libfontconfig1 libfontembed1 libgcc-5-dev libgcc1
  libgfortran3 libglib2.0-0 libglib2.0-data libgomp1 libgraphite2-3 libgs9 libgs9-common libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libitm1 liblsan0
  libmpdec2 libmpx0 libncurses5 libncursesw5 libnghttp2-14 libpam-systemd libpcre3 libpj2 libpjlib-util2 libpjmedia-audiodev2 libpjmedia-codec2
  libpjmedia-videodev2 libpjmedia2 libpjnath2 libpjsip-simple2 libpjsip-ua2 libpjsip2 libpjsua2 libpython2.7 libpython2.7-dev libpython2.7-minimal
  libpython2.7-stdlib libpython3-stdlib libquadmath0 libsasl2-2 libsasl2-dev libsasl2-modules libsasl2-modules-db libsigc++-2.0-0v5 libss2 libstdc++-5-dev
  libstdc++6 libsystemd0 libtinfo-dev libtinfo5 libtsan0 libubsan0 libudev-dev libudev1 locales multiarch-support ncurses-base ncurses-bin ncurses-term
  open-vm-tools openssh-client openssh-server openssh-sftp-server php-composer-spdx-licenses php-pear php-symfony-console php-symfony-filesystem
  php-symfony-finder php-symfony-process php5 php5-cli php5-common php5-curl php5-fpm php5-gd php5-mcrypt php5-mysqlnd php5-pgsql php5-readline python2.7
  python2.7-dev python2.7-minimal python3 python3-minimal systemd systemd-sysv tzdata udev whois
136 upgraded, 70 newly installed, 0 to remove and 0 not upgraded.
Need to get 213 MB of archives.
After this operation, 208 MB of additional disk space will be used.

Iemand enig idee waarom? Het is op een server. Lijkt allemaal video-zooi, waar ik (vanzelfsprekend) niet op zit te wachten...

[gekkie]

Weet niet of tie bij upgrades ook iets doet met een wijziging in "recommended packages" bij packages die je al geinstalleerd hebt ?

xscreensaver is ook een flinke soap aan het worden bij Debian.

[Compizfox]

gekkie schreef op zondag 03 april 2016 @ 19:17:
Weet niet of tie bij upgrades ook iets doet met een wijziging in "recommended packages" bij packages die je al geinstalleerd hebt ?

xscreensaver is ook een flinke soap aan het worden bij Debian.

Geen idee. Ik doe alleen een upgrade, geen installatie of iets dergelijks.

Is er een manier om te zien welke package deze nieuwe dependencies meetrekt?

EDIT:

Ik heb wat gevonden: met de optie --only-upgrade kan ik de nieuwe packages (en de packages die die dependencies veroorzaakten) achterhouden. Hij is nu de rest van de packages aan het upgraden, dus straks zie ik welke packages er achtergehouden zijn.

EDIT:

OK, wat er nu overblijft is het volgende:

code:

# apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  i965-va-driver libaacs0 libavcodec-ffmpeg56 libavformat-ffmpeg56 libavutil-ffmpeg54 libbdplus0 libbluray1 libcrystalhd3 libdrm-amdgpu1 libdrm-intel1
  libdrm-nouveau2 libdrm-radeon1 libdrm2 libegl1-mesa libelf1 libgbm1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglu1-mesa libgme0 libllvm3.7
  libmodplug1 libmp3lame0 liborc-0.4-0 libpciaccess0 libschroedinger-1.0-0 libsdl2-2.0-0 libshine3 libsnappy1v5 libsndio6.1 libsoxr0 libssh-gcrypt-4
  libswresample-ffmpeg1 libswscale-ffmpeg3 libtheora0 libtwolame0 libtxc-dxtn-s2tc0 libv4l-0 libv4lconvert0 libva-x11-1 libva1 libvdpau-va-gl1 libvdpau1
  libwayland-client0 libwayland-cursor0 libwayland-egl1-mesa libwayland-server0 libx264-148 libx265-79 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0
  libxcb-present0 libxcb-randr0 libxcb-shape0 libxcb-sync1 libxcb-xfixes0 libxkbcommon0 libxshmfence1 libxss1 libxvidcore4 libxxf86vm1 libzvbi-common
  libzvbi0 mesa-vdpau-drivers php-symfony-polyfill-mbstring va-driver-all vdpau-driver-all vdpau-va-driver
The following packages will be upgraded:
  libpjlib-util2 libpjmedia-audiodev2 libpjmedia-codec2 libpjmedia-videodev2 libpjmedia2 libpjnath2 libpjsua2 php-symfony-console
8 upgraded, 70 newly installed, 0 to remove and 0 not upgraded.
Need to get 27.7 MB of archives.
After this operation, 209 MB of additional disk space will be used.

Ik ga even bekijken wat die libpj packages zijn, en of ik ze nodig heb.

[ Voor 75% gewijzigd door Compizfox op 03-04-2016 19:47 ]

[gekkie]

Compizfox schreef op zondag 03 april 2016 @ 19:39:
[...]

Geen idee. Ik doe alleen een upgrade, geen installatie of iets dergelijks.

Is er een manier om te zien welke package deze nieuwe dependencies meetrekt?

EDIT:

Ik heb wat gevonden: met de optie --only-upgrade kan ik de nieuwe packages (en de packages die die dependencies veroorzaakten) achterhouden. Hij is nu de rest van de packages aan het upgraden, dus straks zie ik welke packages er achtergehouden zijn.

Wellicht de update daarna eens proberen met --no-install-recommend .. geen idee of dat dus ook bij updates werkt, maar tis een eenvoudige poging waard
(bekijken van dependencies doe ik eigenlijk meestal in aptitude)

[ Voor 5% gewijzigd door gekkie op 03-04-2016 19:47 ]

[Hero of Time]

Compizfox, gebruik toch Aptitude. Echt, al je vragen worden daarmee beantwoord. Start 'm op en je ziet bij de preview waar de dependencies vandaan komen.

[Compizfox]

Hero of Time schreef op zondag 03 april 2016 @ 20:33:
Compizfox, gebruik toch Aptitude. Echt, al je vragen worden daarmee beantwoord. Start 'm op en je ziet bij de preview waar de dependencies vandaan komen.

Heb aptitude uiteraard ook geprobeerd maar daar werd ik niet wijzer van dan apt of apt-get:

code:

# aptitude upgrade
Resolving dependencies...
The following NEW packages will be installed:
  i965-va-driver{a} libaacs0{a} libavcodec-ffmpeg56{a} libavformat-ffmpeg56{a} libavutil-ffmpeg54{a} libbdplus0{a} libbluray1{a} libcrystalhd3{a}
  libdrm-intel1{a} libdrm2{a} libegl1-mesa{a} libgbm1{a} libgme0{a} libmodplug1{a} libmp3lame0{a} liborc-0.4-0{a} libpciaccess0{a}
  libschroedinger-1.0-0{a} libsdl2-2.0-0{a} libshine3{a} libsnappy1v5{a} libsndio6.1{a} libsoxr0{a} libssh-gcrypt-4{a} libswresample-ffmpeg1{a}
  libswscale-ffmpeg3{a} libtheora0{a} libtwolame0{a} libv4l-0{a} libv4lconvert0{a} libva1{a} libwayland-client0{a} libwayland-cursor0{a}
  libwayland-egl1-mesa{a} libwayland-server0{a} libx264-148{a} libx265-79{a} libxcb-dri2-0{a} libxcb-dri3-0{a} libxcb-present0{a} libxcb-randr0{a}
  libxcb-shape0{a} libxcb-sync1{a} libxcb-xfixes0{a} libxkbcommon0{a} libxshmfence1{a} libxss1{a} libxvidcore4{a} libxxf86vm1{a} libzvbi-common{a}
  libzvbi0{a} php-symfony-polyfill-mbstring{a}
The following packages will be upgraded:
  libpjlib-util2 libpjmedia-audiodev2 libpjmedia-codec2 libpjmedia-videodev2 libpjmedia2 libpjnath2 libpjsua2 php-symfony-console
8 packages upgraded, 52 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.6 MB of archives. After unpacking 41.6 MB will be used.
Do you want to continue? [Y/n/?]

Ik ben er overigens al achter waar het vandaan komt, namelijk van de libpj packages, die weer nodig zijn voor Asterisk.

Toch wil ik al die videodrivers niet...

[ Voor 56% gewijzigd door Compizfox op 03-04-2016 20:35 ]

[Hero of Time]

Gewoon 'aptitude' en klaar. Krijg je een curses interface waar je alle packages kan zien, zoeken, markeren voor installatie e.d. voordat het uitgevoerd wordt. Overzicht x1000.

[Compizfox]

Hero of Time schreef op zondag 03 april 2016 @ 20:37:
Gewoon 'aptitude' en klaar. Krijg je een curses interface waar je alle packages kan zien, zoeken, markeren voor installatie e.d. voordat het uitgevoerd wordt. Overzicht x1000.

Is het daarmee ook mogelijk om een soort grafiekje te krijgen van alle (recursieve) dependencies? Ik heb even gekeken maar volgens mij doet hij het niet recursief. Ik zie dus alleen de directe dependencies, niet wat erachter zit.

Ik ben inmiddels al zover dat ik weet dat die lijst packages door libpj komt. Libpj kan ik echter niet missen, maar ik wil ook niet die waslijst aan videodrivers binnentrekken. Ik vermoed dat er ergens een foutje is gemaakt bij het packagen of zo, want voorheen was dit ook niet nodig.

[ Voor 4% gewijzigd door Compizfox op 03-04-2016 20:44 ]

[Hero of Time]

Recursief als in je installeert package A, die package B nodig heeft, gevolgd door package C en die moet weer D hebben. Als je dan package D selecteert, zie je het hele pad. Je ziet niet dat B uiteindelijk D veroorzaakt als je op B staat.

[gekkie]

Compizfox schreef op zondag 03 april 2016 @ 20:35:
[...]

Heb aptitude uiteraard ook geprobeerd maar daar werd ik niet wijzer van dan apt of apt-get:

code:

# aptitude upgrade
Resolving dependencies...
The following NEW packages will be installed:
  i965-va-driver{a} libaacs0{a} libavcodec-ffmpeg56{a} libavformat-ffmpeg56{a} libavutil-ffmpeg54{a} libbdplus0{a} libbluray1{a} libcrystalhd3{a}
  libdrm-intel1{a} libdrm2{a} libegl1-mesa{a} libgbm1{a} libgme0{a} libmodplug1{a} libmp3lame0{a} liborc-0.4-0{a} libpciaccess0{a}
  libschroedinger-1.0-0{a} libsdl2-2.0-0{a} libshine3{a} libsnappy1v5{a} libsndio6.1{a} libsoxr0{a} libssh-gcrypt-4{a} libswresample-ffmpeg1{a}
  libswscale-ffmpeg3{a} libtheora0{a} libtwolame0{a} libv4l-0{a} libv4lconvert0{a} libva1{a} libwayland-client0{a} libwayland-cursor0{a}
  libwayland-egl1-mesa{a} libwayland-server0{a} libx264-148{a} libx265-79{a} libxcb-dri2-0{a} libxcb-dri3-0{a} libxcb-present0{a} libxcb-randr0{a}
  libxcb-shape0{a} libxcb-sync1{a} libxcb-xfixes0{a} libxkbcommon0{a} libxshmfence1{a} libxss1{a} libxvidcore4{a} libxxf86vm1{a} libzvbi-common{a}
  libzvbi0{a} php-symfony-polyfill-mbstring{a}
The following packages will be upgraded:
  libpjlib-util2 libpjmedia-audiodev2 libpjmedia-codec2 libpjmedia-videodev2 libpjmedia2 libpjnath2 libpjsua2 php-symfony-console
8 packages upgraded, 52 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.6 MB of archives. After unpacking 41.6 MB will be used.
Do you want to continue? [Y/n/?]

Ik ben er overigens al achter waar het vandaan komt, namelijk van de libpj packages, die weer nodig zijn voor Asterisk.

Toch wil ik al die videodrivers niet...

Je kunt het in aptitude ncurses versie wel andersom doen ... je laadt aptitude ... geeft aan upgrade met 'u' .. (evetueel eerst bij opties het default installeren van recommended zooi uitzetten).
Vervolgens ga je in je lijstje naar de videodriver en zet je die weer terug naar niet installeren.
Dan heb je als het goed is een broken dependency .. en weet je dus waardoor het komt (pakketje in het mooi rood).

Maar goed het kan maar zo dat multimediacodes tegenwoordig gecompileerd worden met support voor hardwareondersteuning .. en daar derhalve een dependency op hebben gekregen.

Als het je er hoog zit zou je dan kunnen overwegen die packages zelf te repackegen zonder die dependencies. Moet je dat bij updates echter wel steeds zelf doen .. maar principes hebben zo hun prijs .

Oh en by the weg .. er lijkt wel iets te bestaan wat een dependency graph kan genereren:
https://collab-maint.alioth.debian.org/debtree/

[Hero of Time]

gekkie schreef op zondag 03 april 2016 @ 20:52:
[...]

Je kunt het in aptitude ncurses versie wel andersom doen ... je laadt aptitude ... geeft aan upgrade met 'u' .. (evetueel eerst bij opties het default installeren van recommended zooi uitzetten).
Vervolgens ga je in je lijstje naar de videodriver en zet je die weer terug naar niet installeren.
Dan heb je als het goed is een broken dependency .. en weet je dus waardoor het komt (pakketje in het mooi rood).

Pssst, met 'u' update je je package list en controleer je op updates. Met 'U' echter markeer je alles als upgradable.

[Compizfox]

gekkie schreef op zondag 03 april 2016 @ 20:52:
[...]

Je kunt het in aptitude ncurses versie wel andersom doen ... je laadt aptitude ... geeft aan upgrade met 'u' .. (evetueel eerst bij opties het default installeren van recommended zooi uitzetten).
Vervolgens ga je in je lijstje naar de videodriver en zet je die weer terug naar niet installeren.
Dan heb je als het goed is een broken dependency .. en weet je dus waardoor het komt (pakketje in het mooi rood).

Maar goed het kan maar zo dat multimediacodes tegenwoordig gecompileerd worden met support voor hardwareondersteuning .. en daar derhalve een dependency op hebben gekregen.

Als het je er hoog zit zou je dan kunnen overwegen die packages zelf te repackegen zonder die dependencies. Moet je dat bij updates echter wel steeds zelf doen .. maar principes hebben zo hun prijs .

Oh en by the weg .. er lijkt wel iets te bestaan wat een dependency graph kan genereren:
https://collab-maint.alioth.debian.org/debtree/

Thanks. Als ik één van die libdrm-* packages deselecteer, worden al die libpj-* packages (libpjlib-util2 libpjmedia-audiodev2 libpjmedia-codec2 libpjmedia-videodev2 libpjmedia2 libpjnath2 libpjsua2) broken.

Het lijkt er dus op dat ik hier niet onderuit kom.

Dat verhaal over hardwareacceleratie zou een logische verklaring kunnen zijn, maar het is alsnog vrij ruk dat het hierdoor verplicht is om al deze meuk te installeren op een server als je Asterisk wil.

[ Voor 7% gewijzigd door Compizfox op 03-04-2016 21:00 ]

[gekkie]

Hero of Time schreef op zondag 03 april 2016 @ 20:55:
[...]

Pssst, met 'u' update je je package list en controleer je op updates. Met 'U' echter markeer je alles als upgradable.

erhmm ja natuurlijk .. doe het alleen maar meerdere keren per week .. moet je het een keertje uittypen krijg je dit