ABI vs API: DLL-hell en package managers

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

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: 1.982

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.

Monopolie op voeding vs Open Source

Door H!GHGuY op zaterdag 12 juli 2014 18:00 - Reacties (19)
Categorie: Maatschappij, Views: 3.678

Deze 'extra' post is niet waarvoor ik mijn blog typisch voor wil gebruiken, maar de uitzondering...
Om het ook wat technisch te houden, heb ik ook nog wat extra toegevoegd over het Open Source Seeds Initiative - iets wat er heel nauw bij aanleunt...

Voor de TLDR; versie:
Er ligt een wetsvoorstel klaar op Europees niveau die de macht van grote zadenproducenten nog groter zal maken. Er loopt een petitie op Avaaz die je kan bereiken via deze link:
http://www.avaaz.org/nl/monsanto_vs_mother_earth_loc/
Het zou me plezieren mocht je kort even je naam + e-mail adres willen achterlaten. Als ik me niet vergis kun je opt-out doen van hun nieuwsbrieven.

Achtergrond

Een tijd geleden kreeg ik van iemand een Youtube link over een zekere Dr.Rath die strijd voert tegen de chemieconcerns. In tegenstelling tot mijn verwachting was het een interessante les geschiedenis over Wereldoorlogen en het ontstaan van Europa. We kunnen discussiŽren over de inhoud en over wat oorzaak en wat gevolg is - daarvoor ken ik de loop van de geschiedenis en de exacte details te weinig - maar deze man krijgt toch wel de Mythbusters-stempel van 'plausible' mee voor de feiten die hij aanhaalt. Over de manier waarop hij de puntjes met elkaar verbindt ben ik het niet eens.
Voor zij die het interesseert, kijk vooral zelf op Youtube. (TLDR; below)
Wat hij beschrijft is waarschijnlijk slechts 1 van de vele factoren in de hele gang van zaken; Maar als slechts 10% klopt, dan nog is het best schandalig.

In het kort komt het erop neer dat de grote chemieconcerns vele keren langs start passeren.
De eerste maal verkopen ze hun zaden aan boeren.
De tweede maal verkopen ze pesticiden aan boeren. Al ooit gehoord van Round-up resistente tarwe en mais? Genetisch gemodificeerde zaden die niet kapot gaan van de pesticiden van hetzelfde bedrijf. Ingenieus, toch?
Ik meen me trouwens te herinneren dat het bij boeren niet abnormaal is dat zo'n bedrijf de zaden levert en dan de gewassen opkoopt. Maar daar wens ik niet op gequote te worden...

Helaas is het gebruik van pesticiden niet altijd even gezond. De bedrijven leggen dan natuurlijk studies voor die bewijzen dat het onschadelijk is, maar de realiteit bewijst anders. (Zie bijvoorbeeld dit artikel voor een recent probleem. Maar het meeste gekende zal toch DDT blijven...
De derde maal verkopen ze dus geneesmiddelen aan zij die ziek worden van die slechte voeding.
--> edit: Dit werd verder toegelicht in de reacties.

Patenten

Al dat goeds komt tot stand onder de mantel van octrooien en patenten. Volgens die Dr.Rath hebben de chemieconcerns een dikke hand in beide wereldoorlogen en het tot stand komen van de Europese Unie. Ik zou eerder spreken van economisch opportunisme en lobbyen.

Maar laten we even het concept in vraag stellen... Is het niet bizar dat je iets wat in de natuur voorkomt patenteert? Het is schering en inslag dat ze aan een bestaande stof het niet-werkzame deel wijzigen, (opnieuw) patenteren en weer de cash-koe melken... Waarom kun je patent aanvragen op een kruising van 2 bestaande soorten? Of op het resultaat van het in vitro modificeren van genen?

Hun businessmodel is gebaseerd op 2 pijlers: patenteren om een monopolie te krijgen, monopolie misbruiken om iedereen hun wil op te leggen. Overlaatst las ik nog ergens een comment op T.net dat bedrijven zoals Monsanto 'the good guys' zijn. Ik had plaatsvervangende schaamte.

Open Source Seed Initiative

Maar we kunnen er iets aan doen! Jij kan natuurlijk starten door naar boven te scrollen en de petitie in te vullen. Doe ný maar, ik wacht wel even...

Daarnaast bestaat er nog een recent initiatief wat probeert om de macht van chemieconcerns te breken met het ons techneuten welbekende open-source model. Het is een databank van zaden waar, simpel gezegd, iedereen vrij gebruik van mag maken. Het concept is zo simpel als het brilliant is: open-source als middel tegen onethisch kapitalisme...

Het project begon met het verstrekken van de zaden onder een licentie. Na wat discussies en het toetsen van de licentie tegen wat gerechtelijk kan, mag en vooral haalbaar is, zijn ze van de licentie afgestapt. Je moet uiteindelijk ook nog een rechtszaak kunnen winnen als het ooit zover komt... In de plaats daarvan is een 'pledge' gekomen. De exacte juridische details gaan mijn petje te boven, maar dit zou althans in de US voldoende afdwingbaar moeten zijn. De voornoemde link bevat wat discussie voor zij met interesse.

Hoe dan ook, bewijst ook dit project dat het open-source model, waarbij mensen publiekelijk samenwerken aan een gemeenschappelijk doel wat economische belangen overstijgt (of op een positieve manier ondersteunt) toepasbaar is op meer dan wat computer code.

Internet of Things

Door H!GHGuY op woensdag 09 juli 2014 18:00 - Reacties (16)
Categorie: Technologie, Views: 3.959

Naar aanleiding van een artikel waarbij 'slimme' LED lampen WiFi paswoorden lekken ben ik me toch beginnen afvragen of ik het allemaal wel begrijp. De hele IoT industrie kan toch niet fout zijn; het moet toch echt aan mij liggen?

Wat de laatste jaren ons moeten geleerd hebben is dat security een continue proces is. Fabrikanten duwen telkens maar hardware in de winkel met daarop slecht beveiligde software zonder enige vorm van updates. Mobieltjes zijn eigenlijk het puntje van de ijsberg. Routers deden het al veel langer.
WiFi heeft zijn problemen gehad met WEP en WPA. Gelukkig houdt WPA2 iets langer stand.

Daarnaast moet 1 fundamenteel iets toch ook wel onthouden worden: de ether is een gedeelde bus.
Om even de terminologie op te breken in stukjes voor de iets minder technisch aangelegde tweakers:
- een bus verbindt 1 of meerdere punten met elkaar. Bvb de PCI bus verbond de CPU (via de PCI controller) met alle PCI devices in een toestel.
- het 'gedeelde' aspect is slaat op het feit dat er meerdere toestellen op dezelfde bus zitten. PCIe is telkens 1<->1, PCI is 1<->all.
Er is maar 1 ether en alle wireless devices (binnen bereik) delen diezelfde ether. We spreken dus van een gedeelde bus. Om performantie toch op peil de houden delen we die bus op in frequentiebanden, maar er is geen enkele toegangscontrole op de ether. Iedereen die wil, kan zenden en vooral ontvangen.

Tot daar de technische voorbereiding. Let's get to the point: Waarom wil iemand nu wireless communicatie op een lamp? Laten we even stap per stap te werk gaan en het product innoveren naar een veiliger en goedkoper alternatief.

Stap 1: Dump wireless

Wireless is bad, mmkeey? Het heeft een genoeg problemen:
- security. Google 'WPS'. Ga naar de gevangenis, passeer niet langs start, u ontvangt geen miljard om te kunnen rentenieren.
- performance en/of backwards compatibility. 802.11a/b/g/n/... Ik hou de tel niet meer bij, maar het gaat hard genoeg. Moet ik voor die laatste 3 LED lampen die maar niet willen kapot gaan mijn router nog in een tragere mode laten draaien? Hopelijk kan die het in parallel... En als iedereen de ether bevuilt met zijn lampen, dan raakt dat ding ook wel eens verzadigd.

Je _hebt_ een kabel tot in dat ding. Al ooit gehoord van HomePlug? 100Mbps bidirectioneel over het electriciteitsnet. Hoeveel lampen zijn dat? Voor nieuwe huizen is het nog simpeler. Trek 12V tot aan de lamp en leg er meteen 2 draadjes bij voor low-speed communicatie.

Stap 2: Steek de logica in de socket.

We hebben al jaren lang lampen gemaakt. Die dingen hebben standaard formaten, vormen, aansluitingen en wat nog. Houden zo! Prima zo! De lampen mogen niet veel kosten en gaan (relatief) snel kapot - het is een massaproduct. De simpele oplossing is dan ... hou ze simpel! Hoeveel keer heb je al een lamp moeten vervangen? En hoeveel keer heb je ook de socket moeten vervangen? Bewijs geleverd.


Fabrikanten claimen vele jaren levensduur voor LED lampen. Wil je echt een ethernet+WiFi S/W stack zonder updates doorheen je hele huis? Ik dacht het niet. Geef mij maar een simpele kabel.

Er zijn nog wel enkele andere redenen... Het is nog niet onomstotelijk bewezen dat wireless helemaal ongevaarlijk is. Ik ken mensen die waarschijnlijk dubbel-blind placebo controlled getest kunnen worden op hun mogelijkheid om gewaar te worden of er wireless apparatuur in de buurt is.
Controversieel (en lobby-driven) onderwerp waar ik hier niet verder op in wil gaan, maar het is toch iets waar je even stil moet bij staan als je je huis vol hangt met die dingen.

Ik wacht nog wel even tot de IoT kristalliseert. Jullie?

Het nieuwe nieuwe werken

Door H!GHGuY op woensdag 30 april 2014 09:00 - Reacties (15)
Categorie: Maatschappij, Views: 4.463

Elke dag staan we lekker met z'n allen in de file. Of beter gezegd, staan jullie in de file. Ik werk gelukkig ergens waar ik niet voor moet aanschuiven. Dat wil niet zeggen dat ik niet het recht heb om na te denken of en hoe het beter kan. Ik zit immers alsnog elke dag meer dan een uur in de wagen.

Waarom anders gaan werken?


Zoals ik in de inleiding aangaf staan we met z'n allen behoorlijk wat stil. Dat heeft natuurlijk veel gevolgen. Het begint al bij de ecologische impact van al dat fileleed. Auto-fabrikanten dragen hun steentje bij (onder druk van, natuurlijk) met dingen als start-stop, hybrides, lager verbruik, etc. Maar beter nog dan minder verbruiken is _niet_ verbruiken.

Daarnaast is het niet fijn om al gestresseerd op het werk aan te komen. Natuurlijk ben jij anders, maar uw buur in de file heeft zijn stuur al bijna op. Persoonlijk vind ik 's morgens naar het werk rijden best ontspannend, ik heb namelijk niet het gevoel dat ik iets mis. Ik kan al even nadenken over wat ik zo meteen ga doen, of reflecteren over het nieuwe werken.
's Avonds, echter, heb ik wel betere dingen te doen. Van zodra ik in de wagen zit, moet het vooruit gaan. Elke minuut die ik win, heb ik thuis meer vrije tijd. Met de frustrerende gevolgen dan dien...

Waarom kunnen, mogen of willen we niet anders gaan werken


Sommige mensen moeten nu eenmaal fysisch aanwezig zijn op het werk. Daarmee heb je al meteen een grote groep mensen uitgesloten van de directe voordelen. Anderen kunnen hun werk misschien maar gedeeltelijk zo indelen. We komen er dus al snel op uit dat het geen zwart-wit situatie is, maar dat de mogelijkheden (niet, veel, weinig, altijd) afhangen van job tot job.
Ook voor mensen die niet fysisch op het werk můeten zijn, hebben er toch soms baat bij. Soms kan interactie met mensen (lichaamstaal of directe interactie) voordeel hebben, zelfs ten opzichte van telepresence. Of er zijn andere redenen waarom je best dŗŗr bent.

Maar we werken toch al allemaal lekker thuis?



Er blijken in de praktijk nog wel wat problemen met thuis werken. Uiteindelijk is dit allemaal gebaseerd op vertrouwen tussen werknemer en werkgever. Voor velen is dit vertrouwen precies nog een brug te ver.
Het is ook een alles-of-niets. Of je werkt thuis, of je werkt niet thuis. Je werkt niet half thuis, zelfs al zou dit al voldoende voordeel opleveren. En dat is nu net wat er misschien nog beter kan.
Wat als er een systeem is waarmee je elke dag een bepaalde tijd fysisch op het werk aanwezig bent, maar toch fileleed, frustraties en CO≤ uitstoot beperkt? If it sounds to good to be true, ...

Enter the hybrid workcloud


Cloud is in. Er moest dus cloud in de naam. Hybrid cloud is nog mťťr in, dus hybrid moest ook in de naam. En werk? Ja daar gaat het ten slotte over. Maar, genoeg getalmd, je hebt lang genoeg gewacht.
Knijp uw ogen even zo dicht mogelijk (maar zorg dat je deze tekst nog kan lezen - anders heeft het weinig zin, nietwaar?) en beeld je in:

's Morgens sta je op, je neemt lekker je ontbijt, je leest nog een bladzijde of 2 uit je krant tot je een notificatie krijgt: "aankomst binnen 3 minuten".
Je doet jas en schoenen aan; Je neemt je lunchbox en laptoptas en begeeft je richting voordeur.
Net als je buitenkomt stopt een bus(je) voor je deur, je stapt in en neemt plaats op 1 van de bankjes. Begin werkdag. Je groet je collega's, neemt je laptop uit de tas en sluit deze aan. Je klapt de handel open en 5 seconden later zit je op het (beveiligde WIFI netwerk) met directe VPN naar het werk. Kwartiertje later begint een meeting. Je belt in (met telepresence, natuurlijk) en hebt een productieve meeting. Een half-uurtje later komt de bus met jou en je collega's aan op het werk. Je verhuist je gerief naar je eigen bureau en doet gewoon verder.

In de loop van de dag heb je nog wat meetings die wel interessant zijn om face-to-face te volgen en moet je nog enkele zaken doen die fysische aanwezigheid vereisen.

's Avonds, zo rond een uur of 3 doe je de omgekeerde beweging. Je stapt in de bus en werkt nog wat verder. Toevallig heb je nog een face-to-face meeting met collega's die allen op de bus aanwezig zijn (en dit ook lang genoeg zijn). Een halfuurtje later stap je thuis af. Einde werkdag.

What's in it for me?


Voor de werknemer? Je reistijd is ook gewoon werktijd. Niet nog een uur of 2 verliezen in de wagen. Je begin 's morgens wanneer je je huis uitgaat en je stopt als je terug binnenkomt.
Je hebt ook geen wagen nodig als je voornamelijk woon-werkverkeer doet. Je bent niet gestresseerd als je op het werk komt. Het is bovendien veilig en ecologisch.

Voor de werkgever? Geen wagenpark en bijhorende parking meer voor de deur. Meer werknemers kunnen gebruik maken van hybride werken dan als je enkel thuiswerk doet. Er is nog altijd een vorm van "controle" of sociale druk die bij thuiswerk ontbreekt. Gelukkigere werknemers zijn bovendien betere werknemers.

Voor de anderen? Minder wagens is minder files; Zo word ook jij, die zelf niet kan deelnemen aan de hybrid workcloud, er beter van.

En wat met...?


Niet iedereen is voor zijn normale arbeidsduur aanwezig op de bus of op het werk!

Correct. De kans is echter groot dat mensen die voor de hybrid workcloud in aanmerking komen ook in aanmerking komen om 1 dag op 5 van thuis te werken. Zo kunnen die mensen op die dag het verschil compenseren. Als je bvb 2 uur reistijd hebt opgebouwd tijdens de week, dan kun je een dagje van thuis werken en een uurtje of 2 minder werken.
Of je spaart overuren op en neemt af en toe een snipperdagje, of ...

Kun je de kosten nog verder drukken?

Waarschijnlijk wel. Meerdere bedrijven kunnen samenwerken om te gaan carpoolen. Denk Uber maar dan in het groot. En met internet!
Je kan het busrijden uitbesteden of door eigen vrijwilligers/werknemers laten doen. Stel je voor dat je werkgever je betaalt om je rijbewijs voor busvervoer te behalen en je een bus onder je kont schuift?

Die bus, hoe ziet die er dan uit?

Wel, wat heb je nodig op je werkplek? Stopcontact (24VDC, met 24V naar <insert laptop voltage>V adapters), netwerk, tafeltje. Toilet, koffiemachine, airco. Netwerk kan gerust over 4G.

Dit lijkt verdacht veel op...

Openbaar vervoer? Het op een nieuwe wijze toepassen van een bestaand product is ook innovatie, weet je wel? Je hebt de tafeltjes en banken van een trein, de vorm van een bus, het toevoegen van een laagje internetsaus en een werkgever die het betaalt of het rechtstreeks uitbesteedt. Dat is een behoorlijk ongeziene combinatie van bestaande eigenschappen...