Als je (Belgische) privacy je lief is.

Door H!GHGuY op zondag 05 juli 2015 23:00 - Reacties (2)
Categorie: -, Views: 2.031

Ik kwam naar aanleiding van dit artikel over een Belgische aftapwet deze vraag tegen op een site waar je Belgische politici kunt bereiken:
http://www.hallopolitici.be/vragen/detail/1120

Je kan aanmelden via Twitter of Facebook of gewoon snel een account aanmaken op de site.
Steun deze vraag (en deel ze!) zodat onze politici weten dat we wakker liggen van onze privacy. De website beoogt ook feedback, dus hoe meer stemmen, hoe groter de kans dat een minister of staatssecretaris antwoordt.

Uitslag poll basisinkomen

Door H!GHGuY op donderdag 14 mei 2015 16:45 - Reacties (15)
Categorie: Maatschappij, Views: 2.485

Famous last words:
Wie een poll maakt voor een ander, ... moet er ook iets mee doen.

De resultaten

Poll was te vinden op http://highguy.tweakblogs.net/blog/11767/poll-basisinkomen.

http://poll.dezeserver.nl/results.cgi?pid=394543&layout=6&sort=prc
Ook een poll maken? Klik hier

Een kleine 1000 mensen hebben geantwoord, waarvoor natuurlijk mijn dank.

Ik ga er voor de rest natuurlijk vanuit dat iedereen weet wat het basisinkomen is. Voor zij die het nog niet zouden weten: het basisinkomen is een bedrag wat iedereen onvoorwaardelijk krijgt. Voor kinderen zou er een lager bedrag gerekend worden, bijvoorbeeld §250, voor meerderjarigen een hoger bedrag zoals §1000. Afhankelijk van wie je het vraagt verschillen de bedragen en sommige details in de uitvoering.

Full-time, part-time, no-time: Impact op de arbeidsmarkt

Wanneer we de groep indelen volgens categorieŽn, dan krijgen we het volgende:
Full-time: 54%
Part-time: 33%
No-time: 8% en 4% studeert

Meer dan de helft van de mensen blijft dus full-time werken. Vanuit de reacties en ook het topic op GoT blijken mensen dit te willen gebruiken als aanvulling op hun loon (voor wie het nu niet makkelijk heeft), om te sparen, of gewoon om de levensstandaard te verhogen en zich wat meer luxe te permitteren. Vermoedelijk komt een redelijk deel van dit geld dus relatief snel terug in de economie. Een kleine groep van 2%, wil echter hard sparen in een job die niemand anders wil om zo vervroegd te kunnen rentenieren - deze groep zal dus waarschijnlijk hard sparen.

Een derde van de respondenten geeft aan part-time te willen gaan werken. Het bijkomende geld kun je dus zien als een afkoopsom om minder te hoeven werken. Vergeleken met de huidige cijfers voor part-time werk, 20.8% van de mannelijke werkende bevolking[1] in Nederland, is dit een verhoging met ruim twee derden.

Uiteindelijk is er ook een kleine groep van net geen 10% die zich al dan niet tijdelijk uit de reguliere arbeidsmarkt wil terugtrekken. Vergeleken met de huidige werkloosheidsgraad van 14,1% in Nederland (volgens werkloosheidsmeter.nl), kun je de hoop uitspreken dat de arbeidsmarkt zou stabiliseren op die 8% door het vrijkomen van jobs door mensen die minder gaan werken.

Hieruit kun je dus concluderen dat de vaak gehoorde stelling dat met "gratis geld" mensen allemaal zullen stoppen met werken niet echt opgaat. Er is waarschijnlijk zelfs een redelijke kans dat de vrijgekomen arbeidsuren de werkloosheidsgraad zullen doen zakken.
De proeven die al geweest zijn in het verleden tonen ook gelijkaardige fenomenen aan.

Van 60-urenweek tot luieren: Wat doen mensen met hun tijd?

De simpelste en grootste groep verandert niets, ze blijven gewoon werken zoals ze vandaag al deden.

10% van de groep wenst zelfstandig ondernemer te worden. Van de Nederlandse mannen blijkt nu ongeveer 20% zelfstandig te zijn. Uit deze vraagstelling is niet ondubbelzinnig uit te maken of huidige zelfstandigen in de "ik word zelfstandig" of "niets, ik blijf gewoon werken" groep zijn terecht gekomen, maar met enige voorzichtigheid zou ik durven stellen dat "tot maximaal 10%" aangeeft nieuw zelfstandig ondernemer te willen worden. Het cijfer van 20% zou dus kunnen groeien tot 30%.

Verder zien we dat 23% van de mensen wel minder werkt, maar dit spendeert aan ander hobby-/project-matig werk. Je zou kunnen veronderstellen dat een deel van deze mensen nu rondloopt met briljante ideeŽn waarvoor ze geen tijd hebben om ze tot uitvoering te brengen. Ongetwijfeld is met zo'n percentage de kans reŽel dat een deel van die projecten uitgroeit tot een full-time job. Zelfs al is het voor het ander deel van de groep niet zo, toch zullen er hiervan ook mensen zijn die met hun projecten op kleine schaal waarde creŽren voor vrienden/familie of op grotere schaal via open-source.
Anderzijds zal deze groep ook mensen bevatten die een extra skillset bevatten die niet zozeer aansluit op hun dagelijks werk of gewoon tweakers die graag knutselen ;)

Een 10% wil minder werken om met familie en vrienden door te brengen, 2% wil zelfs helemaal over op een sociale bezigheid. Een mens is nog altijd een sociaal dier en deze mensen willen dit in de praktijk brengen. Sociale activiteiten zijn een bron voor welbevinden of soms ook gewoon trieste noodzaak door tegenslagen.

Verder wil 4% opnieuw studeren. Ze benutten het extra inkomen om zichzelf te ontplooien of gewoon (bij) te studeren voor een betere job.
Een kleine minderheid van 1% wordt zelfvoorzienend en gebruikt het basisinkomen om die zaken te kopen die niet zelf te maken zijn.

Tenslotte is er nog een groep van 5% die verwacht volledig rond te komen van het basisinkomen door zuinig te leven en geen zin heeft om te werken. Dit is de groep waarvan opponenten van het basisinkomen vrezen dat ze een grote meerderheid zullen vormen.

Conclusie

Minder plichten, meer rechten
Ten eerste lijkt het erop dat een basisinkomen bevrijdend werkt. We zien grote verschuivingen (56%) in tijdsbesteding. Mensen lijken eerde geneigd om dingen te doen die hen gelukkig maakt (projecten, sociaal werk, zelfontplooiing, zelfstandig werk in persoonlijke interessesfeer) eerder dan dingen die veel geld opleveren (voor zover die niet bij elkaar aansluiten). Een basisinkomen wijzigt dus de belangrijkste metriek van bruto nationaal product naar bruto nationaal geluk.

Anderzijds durven mensen ook op kleinere schaal risico's nemen door zelfstandig te worden. Dit onderschrijft het idee dat een basisinkomen een grotere lokale economie creŽert.

Dit punt toont trouwens aan dat de huidige balans werk/leven voor velen teveel overhelt naar 'werk', iets wat we los van deze poll ook wel merken. Ik kwam in mijn zoektocht namelijk een grafiek tegen waarin het aantal part-timers gestaag steeg over de laatste jaren.
Rot op, maatschappij!
De groep die zich uit de arbeidsmarkt wil onttrekken is eerder klein. Door de vrijgekomen arbeidstijd is er zelfs een kans dat mensen die nu geen job hebben er wel een kunnen krijgen. Netto zou dit dus een verbetering kunnen zijn.

Hieruit kun je dus ook concluderen dat een basisinkomen van §1000 onvoldoende is voor de overgrote meerderheid om een voor hen aanvaardbare hoeveelheid comfort en luxe te verschaffen.
Tegelijk kun je zeggen dat het niet onmogelijk moet zijn om van §1000 rond te komen in de absolute basisbehoeften. Zo'n bedrag zou dus naar huidige maatstaven een aanvaardbaar bedrag zijn om absolute armoede uit te roeien en om mensen die het willen een springplank te bieden naar een beter bestaan.
Helaas zou een basisinkomen waarschijnlijk ook effecten hebben op de levensduurte. Daarom is het moeilijk in te schatten wat de evolutie van dit bedrag zou zijn in de realiteit.
It's the economy, stupid!
De claim dat een basisinkomen "gratis geld" is die een race-to-the-bottom verzoorzaakt is waarschijnlijk niet (helemaal) terecht. Het grootste deel van dit geld wordt namelijk uitgegeven. Bij mensen die stoppen met werken is dit hun enige inkomstenbron, mensen die minder gaan werken gebruiken het als compensatie voor het verdwenen loon en wellicht een groot deel van zij die full-time blijven werken zal een redelijk deel van dit geld terug in de economie duwen.
Eens het daar is kan het ook ten dele gerecupereerd worden door de overheid. De reŽle hoeveelheid geld die dus gevonden moet worden om zo'n project te financieren ligt dus een stuk lager dan (basisinkomen x inwoners).

Disclaimer

Dit is natuurlijk geen uitgebreid onderzoek. Er mist een bijvoorbeeld een hoop informatie over ieders huidige situatie. De gegevens die ik van eurostat haal proberen hier een beetje aan tegemoet te komen, maar klakkeloos vergelijken van die gegevens is eigenlijk niet correct.
Mijn punt was vooral om mijn onderbuikgevoel aangaande de intenties van mensen te kunnen aantonen. Ik ga namelijk ook niet in op de betaalbaarheid van het basisinkomen, aanzuigeffecten en alle andere argumenten, dit was trouwens ook niet de bedoeling.

En jij dan?

Waar plaatst dit mij? Onbeslist ;)

Zowel uit het kamp van voor- als tegenstanders komen zinnige argumenten. Andere zijn dan weer op onderbuikgevoel gestoeld. Dit mini-onderzoekje bevestigt er alvast enkele van mij.

Ik kom er meer en meer op uit dat we moeten beginnen met een eerlijker fiscaal systeem:
• hervormen van belastingen zodanig dat alle inkomsten eerlijk en gelijk(aardig) belast worden, zowel uit arbeid als uit kapitaal.
• globalisering van fiscaliteit als remedie tegen globalisering van de economie. Ontwijking moet je gewoon aanpakken. Zoniet blijven we in de huidige race-to-the-bottom waarin alle geld bij de immobiele burger gehaald wordt terwijl mobiele bedrijven belasting betalen waar het hen uitkomt.
• de virtuele economie laten krimpen ten voordele van de reŽle economie. Slechts weinig mensen worden beter van het (computergestuurd) gokken met aandelen.

Eens je deze 2 problemen hebt aangepakt komt een hoop geld vrij die je dan kan besteden aan betere dienstverlening, belastingvermindering, negative tax of basisinkomen, etc. Wat de regeringen ook beslissen, een groot deel van dit geld moet terugvloeien naar de burger en zal los van de vorm waarin het gebeurt voor gelijkaardige effecten zorgen. Eens dat geld begint binnen te stromen kunnen we de discussie van basisinkomen nog wel eens voeren.

Er loopt een topic op GoT waar in-depth discussie over het basisinkomen zelf mogelijk is, hieronder zou ik het liefst houden voor discussie over deze blogpost.

----
[1] Ik ga voor de statistieken verzameld via eurostat (http://ec.europa.eu/eurostat/web/lfs/data/database) even uit van Nederlandse mannen. Gegeven het gemiddelde publiek hier op GoT hoop ik dat niemand me daarvoor wil opknopen - hoewel ik als onderbuur zelf ook verzachtende omstandigheden kan pleiten ;)

Poll basisinkomen

Door H!GHGuY op vrijdag 08 mei 2015 21:00 - Reacties (43)
Categorie: Maatschappij, Views: 4.619

Laten we even wat onderzoek doen naar basisinkomen, maar neem aub de tijd om de kleine introductie te lezen.

De vraag is simpel, maar bedenk even wat je nou wel en niet kan doen met §1000:
Onderdak, verzekeringen, voeding, kledij, medische verzorging, transport, ...?
Bedenk dan ook hoeveel je nodig hebt om je huidige of gewenste levensstandaard aan te houden en hoeveel je moet overbruggen met andere inkomsten. Hou er ook rekening mee dat voor veel mensen meer vrije tijd ook meer uitgaven betekent...

Poll: Wat doe jij als je maandelijk §1000 krijgt?Tussenstand:
http://poll.dezeserver.nl/results.cgi?pid=394543&layout=6&sort=prc
Ook een poll maken? Klik hier

ABI vs API: DLL-hell en package managers

Door H!GHGuY op donderdag 26 februari 2015 21:30 - Reacties (5)
Categorie: Technologie, Views: 1.037

Ik speelde al een tijdje met het idee om blogposts te maken om wat achtergrond informatie te verschaffen bij artikels van T.net. Naar aanleiding van mijn reacties op dit artikel heb ik nu dan ook een goed excuus.

Veel developers kunnen zich bij een stabiele API nog wel wat voorstellen, maar als het over ABI gaat dan is het wel weer iets anders. Nochtans heeft dit voor veel users wel een belangrijke impact.

Stabiele API

Laat ons vooral beginnen met wat een API is, voor de tweaker met andere voorkeuren. API staat voor Application Programming Interface. Of lichtjes vertaald: het is de programmeer-interface tussen 2 stukken applicatiecode.

Een schoolboekvoorbeeldje:

C++:
1
2
3
4
5
6
7
8
9
class IBasicCalculator
{
  public:
    virtual int Add(int a, int b) const = 0;
    virtual int Multiply(int a, int b) const = 0;
    virtual int Sum(int a[], size_t count) const = 0;
    virtual ~IBasicCalculator();
};
IBasicCalculator* GetCalculator();


Hier zien we de API van een eenvoudige rekenmachine waar je mee getallen kunt optellen en vermenigvuldigen of de som van een reeks getallen kunt berekenen.

Een stukje code die dit gebruikt zou er zo kunnen uitzien:

C++:
1
2
3
4
5
6
7
8
9
10
11
int main(int argc, char** argv)
{
  int numbers[] = { 1, 2 ,3 ,4 ,5, 6 };

  /* Maak een calculator aan */
  IBasicCalculator* calc = GetCalculator();
  /* bereken de som van de getallan [1->6]
  int sum = calc->Sum(numbers, 6);
  printf("Sum = %d\n", sum);
  return 0;
}


Deze code berekent de som van de getallen 1 tot 6 en print die af. Allemaal weinig interessant...

Een mogelijke implementatie in de eerste versie van Sum() zou deze kunnen geweest zijn:

C++:
1
2
3
4
5
6
7
int CBasicCalculator::Sum(int a[], size_t count) const
{
  int sum = a[0];
  for (size_t i = 1; i < count; ++i)
    sum += a[i];
  return sum;
}


De oplettende programmeur heeft al gezien dat de code hierboven een kleine optimalisatie bevat door de eerste waarde te gebruiken om 'sum' mee te initialiseren. De nog oplettendere programmeur heeft gezien dat dit een bug is wanneer "count" eigenlijk 0 is.

Dus, we schrijven en verspreiden een nieuwe versie van de code met daarin:

C++:
1
2
3
4
5
6
7
int CBasicCalculator::Sum(int a[], size_t count) const
{
  int sum = 0;
  for (size_t i = 0; i < count; ++i)
    sum += a[i];
  return sum;
}


Het interessante hier is dat de functie signatuur (lees: regel 1) ongewijzigd is bij het doorvoeren van de bugfix. Deze update heeft dus een stabiele API, want de kleine applicatie hierboven zal zonder een letter code te wijzigen opnieuw gecompileerd kunnen worden en werken met de nieuwe versie.

Een stabiele API houdt bijvoorbeeld ook in dat ik methodes mag toevoegen:

C++:
1
2
3
4
5
6
...
    virtual int Sum(int a[], size_t count) const;
    virtual int Divide(int a, int b) const;
    virtual int Power(int a, int b) const;
    virtual ~IBasicCalculator();
    ...


Ze kunnen immers nog nooit zijn gebruikt door applicaties, dus je breekt er niets mee.
Updates die een stabiele API hebben ten opzichte van de vorige release noemt men ook source-compatible. Je kan dus bvb de library een update geven, de applicatie die ze gebruikt zal ertegen compileren en linken zonder probleem.

Stabiele ABI

We gaan opnieuw beginnen met wat een ABI is: een Application Binary Interface. Dit is de interface tussen 2 binaire modules.
Om te weten wat dit betekent, moeten we even dieper gaan in hoe CPU's in elkaar zitten.

Laten we beginnen bij het geheugen. Het grootste stuk rechstreeks aanspreekbaar geheugen is typisch de RAM. In vele gigabytes, verschillende snelheden, met of zonder heatsinks.
Daarna komen van groot naar klein de verschillende caches. Van megabytes L3 tot enkele kilobytes L1 cache.
Wanneer een CPU echter berekeningen uitvoert, dan dat hij dit met waardes die in de registers van de CPU zelf zitten. Een CPU heeft slechts een beperkt aantal registers, X86_64 heeft 16 general purpose registers, terwijl een PowerPC of MIPS CPU er typisch een 32-tal heeft.

Waarom is dit belangrijk? Omdat deze registers ook gebruikt worden om waarden door te geven aan functies. Zie bijvoorbeeld hier wat informatie over de MIPS ABI.
Subroutine calls
----------------

Parameter registers:
general-purpose r4-r11
floating point f12-f19

Register usage:
fixed 0 value r0
volatile r1-r15, r24, r25
non-volatile r16-r23, r30
kernel reserved r26, r27
gp (SDA base) r28
stack pointer r29
frame pointer r30 (if needed)
return address r31
Hier staat het duidelijk: de eerste 8 parameters van een functie worden waar mogelijk in register 4 tot register 11 opgeslaan. De rest wordt via de stack doorgegeven.
Ook de return value(s) worden via parameters doorgegeven. Deze zaken maken eigenlijk deel uit van de "calling convention", de afspraken rond het maken van functie-oproepen.

Dit is echter niet het hele plaatje. Wanneer je een structuur doorgeeft via een pointer/referentie dan moeten beide partijen het eens zijn over de layout van de structuur:

C++:
1
2
3
4
5
struct version
{
  char version_type;
  unsigned long major, minor, build;
};



Een doorwinterde programmeur weet dat er meerdere mogelijke layouts zijn van bovenstaande code:
- unsigned long zal op huidige platformen typisch 32 of 64 bit zijn afhankelijk van de doelmachine (of een compiler optie)
- tussen de "version_type" en "major" velden zal typisch padding (ongebruikt geheugen) zitten, aangezien een unsigned long altijd op een adres moet starten welke deelbaar is door (typisch) 4 of 8. Deze padding zal dus in de meeste gevallen 3 of 7 bytes zijn.

Een voorbeeld zou dus zijn:
| version (1 byte) | padding (3 bytes) | major (4bytes) |
| minor (4 bytes) | build (4 bytes) |


Het is dus belangrijk dat iedereen het eens is, zowel de oproepende code als de opgeroepen code. Deze eensgezindheid krijg je door de ABI te volgen.
De term ABI-compatibility is enigzins verwarrend. De ABI (het document met de beschrijving van bovenstaande zaken) wijzigt niet echt. Met die term wordt eerder bedoeld of 2 versies van bijvoorbeeld dezelfde library op elk vlak compatibel zijn wanneer aangesproken door een externe applicatie.

Laten we even terugkomen op de code uit het vorige stukje. De bugfix die we daar doorvoerden had de API niet gebroken, en ook de ABI was ongewijzigd. We hadden immers geen veranderingen doorgevoerd aan hoe de data tussen de 2 stukken code 'beweegt'.
Het toevoegen van de nieuwe functie was echter wel een ABI-break, maar om die uit te leggen moeten we tot onze knieŽn in het C++-water; Net iets te diep voor nu.
Dan gaan we maar een nieuw feature ontwikkelen!

Onze developer had gehoord van instructies die in 1 keer kunnen vermenigvuldigen en optellen, de zogeheten multiply-add (MAD) instructies en wou deze wel eens gebruiken door de Multiply functie aan te passen tot:

C++:
1
virtual int Multiply(int a, int b, int c = 0);


De nieuwe parameter is een default parameter, dus wanneer aanroepende code ze niet specifieert vult de compiler ze in met 0. De auteur is blij: zijn gebruikers krijgen een compatibele API, want bijvoorbeeld:

C++:
1
int mad = calc->Multiply(3,2);


geeft nog altijd 6 als antwoord zonder enige compilatie-fout.

Jammer genoeg zijn de gebruikers niet blij. De ABI is echter gebroken door deze aanpassing. Tweaker Henk had in zijn systeem de library een update gegeven en had geen zin om zijn applicatie te hercompileren. Resultaat: de applicatie doet niet echt wat ie daarvoor deed.
Henk zijn code gaf 2 parameters door (bvb via regiser r4-r5), terwijl de library er 3 verwachtte (bvb via register r4-r6). Als voor eender welke reden uit het verleden een getal verschillend van 0 in r6 zat, dan geeft de functie een fout resultaat terug.
Oplossing: letterlijk elke applicatie die ooit gebouwd is tegen de calculator code moet je opnieuw bouwen. We kunnen dus zeggen dat die aanpassing niet ABI-compatible is met de vorige versie.

We hebben gezien dat je een verandering kan maken die niet ABI-stabiel is, maar wel API-stabiel. Kan het ook omgekeerd? Ja. Zeer eenvoudig:

C++:
1
2
3
4
5
struct version
{
  char version_name; // was version_type
  unsigned long major, minor, build;
};


Elk stukje code dat "version_type" gebruikte zal vanaf nu niet meer compileren. Als dit echter de enige verandering is, dan zal een update van een library met deze code nog steeds even goed werken. De layout in het geheugen is immers niet veranderd.

Er is nog wat interessant leesvoer. De eerste is een lijst met zaken die je in C++ wel en niet mag doen om de ABI stabiel te houden bij updates. De 2de kwam ik tijdens het schrijven tegen en had ook een mooi overzicht met nog enkele interessante voorbeeldjes.
https://techbase.kde.org/...+#The_Do.27s_and_Don.27ts
http://wezfurlong.org/blo...in-an-evolving-code-base/

DLL-hell en package managers

Wat betekent dit nu voor gewone gebruikers? In een ideale wereld met perfecte programmeurs zou dit heel weinig betekenen. Developers zouden bij kleine updates en (security) fixes waar mogelijk de ABI stabiel houden (API is in deze context eigenlijk irrelevant) en er zou wereldvrede zijn.

Je kan het de developers jammer genoeg niet altijd kwalijk nemen. Voor wie de KDE-link hierboven heeft gevolgd: het is niet eenvoudig om de ABI stabiel te houden. Ik ken persoonlijk zelf de regeltjes ook niet vanbuiten. C++ is echter een moeilijke taal om de ABI van stabiel te houden. Zijn neefje, C, is daar veel makkelijker in.

We weten nu al dat ABI compatibility veel gebroken wordt en dat ABI breaks het noodzakelijk maken dat alle programma's die communiceren met de ABI-incompatible module volledig vanaf de broncode opnieuw gebouwd worden. Wat is dan het effect voor de gebruikers?

…ťn van de mogelijkheden is dat er naast ontwikkelaar en gebruiker een 3de partij in het spel komt, zoals je op Linux ziet: de package maintainer. 1 van de belangrijke taken van een distributie is het integreren van software tot een geheel dat ten allen tijde correct werkt. Dit betekent ook dat als er een update van 1 stukje software is, ze mogelijk een hele hoop andere ook mogen opnieuw bouwen. Om dit te vermijden, gebeurt het veel dat die maintainer kleine updates van een latere versie op een ABI-compatibele manier in hun specifieke versie 'backport'.
Een 2de nadeel van dit model is dat software voor de ene Linux distributie meestal niet zomaar op een andere zal draaien, als er externe code nodig is.
Er bestaan echter initiatieven om ABI incompatibilities op te volgen, zie bijvoorbeeld http://upstream.rosalinux.ru/

Een andere mogelijkheid is dat applicatie-bouwers geen zin hebben om afhankelijk te zijn van derden voor het verspreiden van hun software. Op dat moment kunnen ze kiezen om alle externe software waar ze van afhankelijk zijn zelf mee te bundelen. Zo krijg je dat 10 applicaties misschien 10 keer hetzelfde stukje code zitten hebben. Je kan al raden wat het gevolg is: van de 10 stukjes zal het bij een security update al sterk zijn mocht er 1 van zijn die die update tijdig krijgt.
Dit ligt iets dichter bij de situatie die je op Windows vaker tegenkomt.

Bij eerdere versies van Windows was het bovendien ook de gewoonte om zo'n libraries/DLL's in globale folders zoals c:\windows\system of system32 te gooien. Zo kon het zijn dat 2 software pakketten ofwel 2 verschillende versies naast elkaar installeerden of, erger nog, een bestaande versie overschrijven met een ABI-incompatibele versie. Een regelrechte DLL-hell dus want bestaande pakketen houden plots op met werken als je andere software installeert.

Om af te sluiten nog een mooi samenspel van ABI compatibility en ABI compatibility op Linux. Daar is het namelijk zo dat de kernel van het besturingssysteem er een zeer strikte ABI etiquette op na houdt. Wil je niet een tirade van ome Linus Torvalds op je dak krijgen, dan hou je je er best aan.
Libraries doen dit helaas niet zo strikt. Recent kwam er dus een stukje nieuwe software, Docker, welke het toelaat om op relatief eenvoudige manier applicaties en libraries te bundelen in een 'container', zodat je ze op eender welke Linux distributie kan draaien (want de kernel ABI is wel stabiel). Gelukkig is dit niet het enige selling point van Docker ;)

En zo zie je maar dat Linux met zo'n stap een stukje dichter bij het software distributie model van Windows komt. Gelukkig hebben ze volgens mij met die techniek de mogelijkheid om op termijn het beste van beide werelden te combineren: distributie van applicaties via containers die op elke Linux distro draaien en het eenvoudig updaten van zulke containers met security en andere fixes via het package management systeem. Uiteraard, mits ABI-stability.

Preventie van terrorisme

Door H!GHGuY op donderdag 15 januari 2015 21:00 - Reacties (17)
Categorie: Maatschappij, Views: 2.207

Na de gebeurtenissen in Frankrijk werden er weer veel praatjes verkocht. Politici staken er, zoals gewoonlijk, met de kop bovenuit. Een korte greep uit het gamma:Dit is zelfs enkel Belgisch nieuws... De rest van de wereld zit ook niet stil.

Iedereen is het er hopelijk over eens dat dit slechts lapmiddeltjes zijn. Door Skype, Whatsapp en Facebook te tappen zul je niet verhinderen dat iemand radicaliseert. In het beste geval merk je dat de persoon radicaliseert. In het beste geval...
Idem voor het aftappen van de telefoon van mensen die oproepen tot terrorisme. Het zal wel aan mij liggen, maar dan ben je al te laat, toch? En het isoleren van gevangenen in de gevangenis - de discussie ging over het groeperen van alle radicalen of ze net uit elkaar houden, niet over isolatiecel en co - dan heb je al minstens 1 keer gefaald.

Het grootste publiek geheim van godsdienstterroristen (3 x letterwaarde), is dat godsdienst een dekmantel is. "Maar waarvoor dan?". Politiek natuurlijk.
Het is onderhand al duidelijk dat Osama Bin Laden zijn echte plan, economische destabilisering van de Westerse wereld, wel degelijk is uitgekomen. Dat hij wat islam-gebrabbel nodig had is bijzaak.

De intelligentere lezer zit al met de vervolgvraag over wat we die mensen toch ooit misdaan hebben. Geen eenduidig antwoord van mij, natuurlijk; ik maak ook maar deel uit van het plebs. Maar ik zou gaan denken dat het antwoord gaat van "Niets, we willen gewoon aan de macht." tot en met de verhoudingen in IsraŽl/Palestina of vieze zaakjes van de VS en anderen in Iran, Irak, Afghanistan, SyriŽ, ... You name it, they've been there and ****ed it up.

Hiermee kom ik eindelijk tot mijn echte punt: preventie tegen terrorisme begint bij een eerlijk buitenlandbeleid. Terrorisme is geen aangelegenheid van Binnenlandse Zaken, maar van Buitenlandse Zaken. De wereld is nu natuurlijk al voldoende naar de vaantjes dat je zoiets niet snel-snel oplost, maar het echte verschil maak je, wat mij betreft, op dat departement.

Helaas past zo'n boodschap niet in het kader van economisch lijfbehoud en de politiek van graai-je-rijk-in-andermans-land, dus zal je ze ook nergens horen. Behalve hier, bij een kritische en wakkere burger.