Opbouw van Filesystems

[jkuiper]

Windows is teveel backwards compatible. Nog steeds houdt men zich vast aan driveletters, waardoor er niet echt een structuur aanwezig is. In Unix/Linux (voor degene die dat een apart OS vinden) is er één root directory. Al zijn er onder Unix verschillende filesystemen zoals HTFS, EAFS, VXFS, NFS, minix, ext, ext2, ext3, xia, nfs, iso9660, hpfs, sysv, smb, ncpfs, deze kunnen altijd worden aangehangen aan een directory. Zo heb je verschillende (her)schijfbaar hardware onder één noemer.
Nu kan je vanaf Windows XP een (her)schijfbaar hardware koppelen als een directory. Maar deze wordt nog steeds gezien als een extern iets en zal zich nooit binden.
Het zal voor programmeurs, die in verschillende OS werken, heel prettig zijn als dit een universele optie zal zijn. Geen geklooi met een slash of backslash. Altijd een vindbare pad. Universele diskfuncties, die gewoon werken, waar je ook vandaan komt.

Het enige nadeel zit in de oude software, die afhankelijk is van een driveletter, maar die kan je met een virtuele letter aanroepen.
Zelf wordt ik gek van die driveletters. Je hebt 1 schrijf met 1 partitie, een multicardreader met een aantal poorten (als is dit aardig gereduceerd), een usbstick, een cdrom en een aantal netwerkdrives. Kortom, het worden er al gauw zes tot acht driveletters, die totaal niet samen kunnen werken.
Voor de virusscanner zal het één grote opluchting zijn als er één boomstructuur is.

Ik pleit voor één boomstructuur. Maar waar zullen jullie voor kiezen?

Ik kan niet spreken voor MAC. Daar heb ik nooit mee gewerkt.

[GolezTrol]

Op de Mac werkt het volgens mij hetzelfde als op Unix. Dat OS komt daar oorspronkelijk ook vandaan. De keuze voor driveletters vind ik niet zo onlogisch, maar dat is misschien omdat ik vooral ervaring heb met DOS en Windows.

Ik zou niet weten waarom ik een USB stick zou willen koppelen als directory. Ik moet dan nog steeds weten waar die staat en hoe ik erbij kom. Ik zie geen enkel bezwaar tegen de driveletters. Ik zou het op zich ook niet erg vinden als ze kiezen voor een andere oplossing, maar het moet toch backwards compatible blijven. Hoe ga je dat uitleggen aan je gebruikers?

En niet alleen aan de standaard gebruikers van het OS, maar zelfs aan ontwikkelaars.
Hoeveel commotie is er niet ontstaan in de developers-wereld, dit forum incluis, over de beperkte schrijfrechten in de program files directory, simpelweg omdat mensen nu, in 2010 nog steeds data in inifiles naast de executable zitten te prakken terwijl dit al sinds Windows 95 deprecated is... Het duurt denk ik nog wel 80 jaar voor we Windows-developers over hebben op volume mounts.
Nee, ik zie niet zo snel gebeuren dat dat standaard wordt, en eerlijk gezegd kan ik me er ook niet echt aan storen.

Overigens bestaan dat soort features al wel in NTFS. Je hebt namelijk:

- Volume mount points
Wat jij bedoelt. Hiermee kun je een lokaal volume mounten als directory.

- Junction points.
Hiermee kun je een virtuele map maken die eigenlijk verwijst naar een map op een ander station.

- Hard links.
Dito, maar dan voor files in plaats van mappen.

- Symbolic links (Sinds Vista)
Combineert de werking van Volume Mounts en Junctions. Kan tevens verwijzen naar een SMB.

Wat zou je nog extra willen hebben?
PS: NTFS viert dit jaar ook alweer z'n tiende verjaardag.

[edit]
Ik hoor trouwens bij de groep die ook nog tot Vista netjes in Program Files zat te schrijven. En op het idee van die volume mounts kwam ik vooral omdat ik eens bij het opstarten in veilige modus een lijst van geladen drivers gepresenteerd kreeg. Dat vond ik al wel een beetje op Unix-achtige paden lijken, waardoor ik dacht dat zoiets er al wel in zou zitten. De rest van de info komt rechtstreeks van Wikipedia. Ik ben geen NTFS-expert.

[Marcel]

Ik begrijp eerlijk gezegd niet waarom driveletters opeens een probleem zouden zijn.

Ik gebruik zelf meer netwerkpaden dan driveletters, maar ik ben IT'er en heb de illusie dat ik iets van computers en netwerken begrijp. In een gemiddelde kantooromgeving stort de wereld echter in als je daar gaat uitleggen dat de gedeelde Word bestanden voortaan te vinden zijn op \\Server25\Gedeeld, en dan kies ik nog een makkelijke naam terwijl de gemiddelde systeembeheerder de server liever POKJGYJYTY123HKJ zou noemen. De Word bestanden staan al jaren op de G-schijf en dat daar de afgelopen jaren een Novell 2, 3, 4, 5 en een NT, Server 2003, 2008 server achter heeft gehangen zal de gebruiker een zorg zijn, de G is de G gebleven.

Kortom: de mogelijkheden zijn er in Windows en ze worden ook uitgebreid gebruikt, maar ik zou dat zeker niet tot aan de desktop van de gebruiker doorvoeren. Die is al 25 jaar gewend aan de G-schijf, waarom zou je dat willen veranderen?

[jkuiper]

We willen al jaren een universeel systeem hebben. Java is daar een voorbeeld van. Dit werkt op elke browser, die java ondersteunt, en hoef maar één keer geprogrammeerd worden. Google is ook druk bezig met Chrome OS. Een OS onafhankelijk van hardware, die overal ter wereld kan gebruiken.
Ik weet dat 80% van pc-gebruikers vastzitten op schijfletters. Vaak zeg ik ook van: Je bestanden staan in H:\, terwijl je makkelijker kan zeggen dat je bestanden in /server staan.
Dus waarom niet één boomstructuur, waarin je alles kan vinden. Het interesseert de gebruiker geen biet waar hij zijn gegevens kan vinden.

[WhatJac3]

Ik ben wel een voorstander van compatibiliteit, alleen moeten de gebruikers de opties houden voor schijfletters. Bijvoorbeeld zoiets zou wel handig zijn

\root
|- HD1
|- HD2
|- HD3
|- USB1
|- USB2
|- MyData - je default data directory
|- OS - de default OS directory
|- Programs - de default programs folder
Waarbij je die iedere van een eigen naam kan voorzien, zodat je |-HD1 bijvoorbeeld zelf H kan noemen en dat \H direct de HD1 zou zijn. Als je dat zou combineren met schijfletters zou dat prima zijn.

C:\ (: als aanduiding houden van schijfletter) voor de harde schijf waar het OS op staat)

A-B floppy drives
C-F = harde schijven (4 zou voldoende zijn de rest gebruikt maar de \HDx optie
G-I = Drives (3 maximaal, G= cd-rom, H=dvd, I = blu-ray, indien opvolger blu-ray komt die in plaats van letter G omdat CD-rom dan toch al uit is)
J = brander (hoogste optie, dus indien blue-ray brander en aparte dvd brander dan wordt het de blu-ray brander)
K-M = usb drives (3 maximaal, rest via \USBx)
N-Q = multicard reader (4 maximaal in standaard volgorde), N = MMC, O = SD, P = Memorystick, ......
R-U = netwerk schijven (R = netwerk user folder, S = netwerk user profiel, T = company data, U = ... (zelf invullen)
V-Z = zelf invullen

Lijkt mij geen verkeerde oplossing. Eventueel zou je dit aankunnen vullen met opties voor cijfers als schijfletter. Dus een
0:\, 1:\, 2:\ ...9:\

[GolezTrol]

Origineel gepost door JKuiper

We willen al jaren een universeel systeem hebben.

Gelukkig is Linux open source, dus ik zou zeggen: Begin maar aan de implementatie van drive letters.

Chrome OS is overigens niet te vergelijken met Java. Java gebruikt een virtual machine, een onderlaag die wel degelijk specifiek op de hardware, of tenminste op het OS geschreven is.

De hardware-onafhankelijkheid is overigens ook niet waar. Ook Chrome OS is afhankelijk van hardware en draait op dit moment volgens mij ook alleen op Intel en ARM. Daarbij is er in Chrome OS maar zo'n beetje één applicatie, namelijk de Chrome browser. De rest draait via die browser. De applicaties zijn dus onafhankelijk van de hardware, omdat het webapplicaties zijn. Diezelfde applicaties kunnen ook draaien in je Chrome browser onder Windows. Opslag van bestanden zit dan vast ook weer gekoppeld aan allerlei Googlediensten. Als je alleen een Google skydrive hebt, dan heb je inderdaad weinig aan drive letters.

Als je de hardware-onafhankelijkheid wilt die Google introduceert met chrome, dan moet je niet overstappen op Java, C# of FPC, maar gewoon naar HTML5 en Javascript.

[jkuiper]

Even op web gekeken naar Volume Mount Points op MSDN. Daar stond dit interessant stukje:

Using mounted folders, you can unify disparate file systems such as the NTFS file system, a 16-bit FAT file system, and an ISO-9660 file system on a CD-ROM drive into one logical file system on a single NTFS volume. Neither users nor applications need information about the target volume on which a specific file is located. All the information they need to locate a specified file is a complete path using a mounted folder on the NTFS volume. Volumes can be rearranged, substituted, or subdivided into many volumes without users or applications needing to change settings.

Windows gaat al aardig op Unix lijken. Alleen jammer dat iedereen, die op windows zitten, verzot is op zijn schijfletter.

[Marcel]

zo kun je het ook zien.

[marcov]

Origineel gepost door GolezTrol

Op de Mac werkt het volgens mij hetzelfde als op Unix. Dat OS komt daar oorspronkelijk ook vandaan. De keuze voor driveletters vind ik niet zo onlogisch, maar dat is misschien omdat ik vooral ervaring heb met DOS en Windows.

Heel simpel gezegd heb je op Windows niet echt een mapping van logische indeling (wat wil ik waar hebben qua structuur) en fysieke mapping (welk filesysteem staat op welke disk). Dat is ook waarom bijna elk op Windows gericht RAID systeem hier een laag tussen mept om dit te bewerkstelligen.

Je kan daardoor niet in een lopend systeem zeggen, och, de systeem disk loopt vol, dus ik move program files naar een ander filesysteem, en mount het terug op de originele positie. (of document en settings enz).

Ik zou niet weten waarom ik een USB stick zou willen koppelen als directory.

Ook da's niet zo moeilijk. Als je een paar hebt, en je kan aangeven dat usb mass storage allemaal mooi onder \sticks gemount wordt, kan je makkelijk over alle sticks heen zoeken, er makkelijk over itereren enz.

Ik moet dan nog steeds weten waar die staat en hoe ik erbij kom. Ik zie geen enkel bezwaar tegen de driveletters.

Nou, dat is wel heel erg in de simplische verdediging. Zelfs een Windows fanaat moet toegeven dat 24 stuks (2 als je de gereserveerde a en b ook meeteld) wel erg bepekrt is.

Ik zou het op zich ook niet erg vinden als ze kiezen voor een andere oplossing, maar het moet toch backwards compatible blijven. Hoe ga je dat uitleggen aan je gebruikers?

Dat is een fractie van de pijn die mensen nu hebben met alle folder virtualizatie fratsen. Dat is tien keer erger (want gebeurd alleen op shell niveau, en niet op kernel niveau zoals mounten, waardoor het af en toe niet werkt).

Als MS dat aandurft, kan de rest makkelijk.

En niet alleen aan de standaard gebruikers van het OS, maar zelfs aan ontwikkelaars.
Hoeveel commotie is er niet ontstaan in de developers-wereld, dit forum incluis, over de beperkte schrijfrechten in de program files directory, simpelweg omdat mensen nu, in 2010 nog steeds data in inifiles naast de executable zitten te prakken terwijl dit al sinds Windows 95 deprecated is...

De weerstand is zo hoog omdat Microsoft daar de onpopulaire keuze heeft gemaakt om met installers te werken, wat omslachtig is. En daarna nog diverse keren de eisen aan de installers aangescherpt heeft.

Misschien hadden ze moeten zorgen dat het alternatief direct acceptabel was, en niet een eindeloos glijdend vlak moeten creeren.

Iets als Apple's bundles b.v.

Het duurt denk ik nog wel 80 jaar voor we Windows-developers over hebben op volume mounts.

Je ziet hoe het gaat met folder virtualisatie. Eerst moet er een richting gegeven worden, en dan moet MS een jaar of 5 doordrammen. Easy peasy.

Overigens bestaan dat soort features al wel in NTFS. Je hebt namelijk:

Ja. De functionaliteit is er ruwweg sinds Windows 6 en Windows 6.1. Of het voldoende is weet niemand. Zelfs de Unix emulators op Windows (cygwin et al) gebruiken deze functionaliteit niet. Windows 5.2 is nog te populair, maar van Windows 5.0 zijn we nu sinds een paar weken af.

Wat zou je nog extra willen hebben?
PS: NTFS viert dit jaar ook alweer z'n tiende verjaardag.

Een folder layout zo dit ook echt zin heeft, en druk van MS zodat de bulk van de nieuwe apps er tenminste mee werkt. Als ik met behulp van deze tools niet makkelijk homedirs e.d. van een system volume kan moven, dan heeft het geen zin. (deels past dit allemaal overigens dat goed in de MS kernel team policy het registry terug te dringen).

Het staat al sinds het uitkomen van Vista op de agenda hier toch eens in te duiken, maar och, je weet hoe het gaat.

[edit]
Ik hoor trouwens bij de groep die ook nog tot Vista netjes in Program Files zat te schrijven. En op het idee van die volume mounts kwam ik vooral omdat ik eens bij het opstarten in veilige modus een lijst van geladen drivers gepresenteerd kreeg. Dat vond ik al wel een beetje op Unix-achtige paden lijken, waardoor ik dacht dat zoiets er al wel in zou zitten. De rest van de info komt rechtstreeks van Wikipedia. Ik ben geen NTFS-expert.

Het boekje van Helen (Custers?) is erg informatief. Een aanrader. Een van de betere dingen die ik in de aanloop van mijn MCSE gelezen heb (al heb ik het examen nooit gedaan).

[marcov]

Origineel gepost door Marcel

De Word bestanden staan al jaren op de G-schijf en dat daar de afgelopen jaren een Novell 2, 3, 4, 5 en een NT, Server 2003, 2008 server achter heeft gehangen zal de gebruiker een zorg zijn, de G is de G gebleven.

Ik weet niet helemaal zeker, maar ik geloof dat drive mappings door MS als Novell legacy gezien wordt.

De MS way is met shortcuts naar UNC paden. Shortcuts zijn in feite symlinks die alleen op shell niveau werken.

[GolezTrol]

Shortcuts zijn in feite symlinks die alleen op shell niveau werken.

Kun je aan symbolic links een afwijkend startup pad, een sneltoets en parameters meegeven? Of is de vergelijking tussen shortcuts en symbolic links misschien wat vergezocht?

Of het voldoende is weet niemand. Zelfs de Unix emulators op Windows (cygwin et al) gebruiken deze functionaliteit niet.

Dat moet toch uit te zoeken zijn, zou je denken? In ieder geval zou ik verwachten dat iemand zich verdiept in de mogelijkheden die er zijn, voordat er geroepen wordt dat de mogelijkheden er niet of onvoldoende zijn.

Zelfs een Windows fanaat moet toegeven dat 24 stuks (2 als je de gereserveerde a en b ook meeteld) wel erg bepekrt is.

Ik ben geen Windows-fanaat; ik weet gewoon niet beter.
Overigens heb ik hier maar 10 driveletters in gebruik, en dat is met twee hardeschijven, een floppydrive en zo'n multicardreader. Maak dat 11 voor een USB-stick erbij, en dan heb je het wel weer. Op m'n werk heb ik dan nog een 3-tal netwerkschijven die een letter hebben, maar daar heb ik de floppy driver en card reader weer niet.

Natuurlijk zijn er ook wel letterloze netwerklocaties waar ik heen blader, maar ik moet eerlijk zeggen dat ik het juist wel fijn vind dat die apart zijn.

[marcov]

Origineel gepost door GolezTrol

Kun je aan symbolic links een afwijkend startup pad, een sneltoets en parameters meegeven?

Nee. Logisch, want dat zijn shell items.

Of is de vergelijking tussen shortcuts en symbolic links misschien wat vergezocht?

Hangt van je insteek af. De shell aspecten van het fenomeen beperking zich logischerwijs uitsluiten tot euh, de shell ?

Maar dit was een thread over filesystemen, niet over de shell.

Dat moet toch uit te zoeken zijn, zou je denken? In ieder geval zou ik verwachten dat iemand zich verdiept in de mogelijkheden die er zijn, voordat er geroepen wordt dat de mogelijkheden er niet of onvoldoende zijn.

Dat is het verhaaltje van aanmoedigen, en microsoft die bepaalde keuzes (folder virtualizaties) wel maakt, en andere niet.

Het gros van het nut zit hem in als het systeem het gebruikt. De meeste mappen die je niet zo maar kan veranderen zitten daar aann vast, of aan de registry. Pas als MS daar iets aan doet gaat het echt de goede kant uit. Tot dan is het een speeltje van unixers.

En MS ziet het niet in. Apple zag het tien jaar geleden in. Maar ja, daarom is de beurswaarde van Apple tegenwoordig groter dan van Microsoft :-)

Ik ben geen Windows-fanaat; ik weet gewoon niet beter.
Overigens heb ik hier maar 10 driveletters in gebruik, en dat is met twee hardeschijven, een floppydrive en zo'n multicardreader.

Tsja, mensen die er niet over na willen denken, dan kan ik ook niet verder helpen. Ik heb nog steeds de grootste moeite mijn moeder uit te leggen dat schijf "d" op de ene machine een cdrom is, en op een andere een tweede hardeschijf.

Tis een gekke suggestie, maar misschien was als alle DVD/cdroms in een map /dvd - cdroms stonden/ met hun type naam, en nog een symlink naar "cdrom" en "writer" nu zo ontzettend veel lastiger dan de huidige driverletters van buiten leren?

En alle USB sticks in /sticks ?

Maak dat 11 voor een USB-stick erbij, en dan heb je het wel weer. Op m'n werk heb ik dan nog een 3-tal netwerkschijven die een letter hebben, maar daar heb ik de floppy driver en card reader weer niet.

Ik zit wel wat hoger. 4-5 sticks, en als ik wat moet zoeken steek ik ze in met een hub in een keer in. 2 hds met 2 partities elk, paar netwerkschijven en een cardreader die er zelf al zo'n 6 vreet. Het is nog niet schaars, maar de beperking komt wel in zicht.

In het verleden met scsi kaarten en een paar ouwe disk en CD en CD changers cabinets _heb_ ik overigens wel tekort gehad. Geen echt probleem, want echt werken daarmee deed ik natuurlijk onder Unix.

Natuurlijk zijn er ook wel letterloze netwerklocaties waar ik heen blader, maar ik moet eerlijk zeggen dat ik het juist wel fijn vind dat die apart zijn.

Dat doe ik eerlijk gezegd nooit. Al was het maar omdat connecties met net use veel sneller tot stand komen (in een domeinloze situatie tenminste) Eugh, Samba 4 laat veel te lang op zich wachten.

[GolezTrol]

Maar ja, daarom is de beurswaarde van Apple tegenwoordig groter dan van Microsoft :-)

Nee, dat is omdat Apple wél goed is in het maken van MP3-spelers... En natuurlijk omdat mensen dénken dat Apple ook goed is in het maken van telefoons.

Tsja, mensen die er niet over na willen denken, dan kan ik ook niet verder helpen.

Ik wil er best over nadenken, getuige mijn reacties in deze thread. De vraag is of ik me per se (nog meer) verdiept moet hebben in de werking van Unix voordat ik wel of niet antwoord kan geven of ik me nou stoor aan die drive letters onder Windows. Lijkt me niet strict noodzakelijk, of wel?
't Kan vast handiger. Ik ben ook blij met m'n stuurbekrachtiging, maar heb die nooit gemist toen ik 'm nog niet had. Feit is wel dat Windows-gebruikers over het algemeen heel snel zeuren als er iets verandert. Niet alleen de programmeervoorbeelden, maar ook qua GUI. Het startmenu was voor menigeen behoorlijk schrikken, maar ook de interface van Office 2007 heeft op veel weerstand gestuit, terwijl het 100 keer beter was.

Apple heeft wat dat betreft nog redelijk makkelijk. De vrij selecte groep mensen die nu gebruikmaakt van Apple OS en software, bestaat voor het overgrote deel uit fanatiekelingen. Designers en designliefhebbers. Misschien geen computernerds, maar op een bepaalde manier toch nerds. Dat zijn mensen die goed omgaan met veranderingen en daar zelfs blij mee zijn. Als Apple z'n marktaandeel in besturingssystemen uitbreidt tot 10 of 20%, dan zullen ze waarschijnlijk tegen wat meer bezwaren aanlopen als ze iets veranderen of niet implementeren.
Microsoft heeft die fase al gehad (zeg maar in de periode tot 1987) en draagt nu de lasten van een hoop legacy features en gebruikers die klagen als er ergens een pixel verandert in de GUI, laat staan in de fundamentele werking van het systeem.

Dat zou ze er natuurlijk niet van moeten weerhouden om verbeteringen door te voeren, en ik ben ook geen tegenstander van de Unix-manier. Ik denk alleen dat het in de praktijk niet zo makkelijk door te voeren is als je hier schetst.

[marcov]

Origineel gepost door GolezTrol

Nee, dat is omdat Apple wél goed is in het maken van MP3-spelers... En natuurlijk omdat mensen dénken dat Apple ook goed is in het maken van telefoons.

Wel, beter dan MS (Zune, kin) in ieder geval :-)

Ik wil er best over nadenken, getuige mijn reacties in deze thread. De vraag is of ik me per se (nog meer) verdiept moet hebben in de werking van Unix voordat ik wel of niet antwoord kan geven of ik me nou stoor aan die drive letters onder Windows. Lijkt me niet strict noodzakelijk, of wel?

Meer noodzakelijk en fundamenteler dan UAC e.d.

't Kan vast handiger. Ik ben ook blij met m'n stuurbekrachtiging, maar heb die nooit gemist toen ik 'm nog niet had. Feit is wel dat Windows-gebruikers over het algemeen heel snel zeuren als er iets verandert. Niet alleen de programmeervoorbeelden, maar ook qua GUI. Het startmenu was voor menigeen behoorlijk schrikken, maar ook de interface van Office 2007 heeft op veel weerstand gestuit, terwijl het 100 keer beter was.

Omdat veel van die dingen relatief oppervlakkig (en dus potentieel onnodig zijn)

Apple heeft wat dat betreft nog redelijk makkelijk. De vrij selecte groep mensen die nu gebruikmaakt van Apple OS en software, bestaat voor het overgrote deel uit fanatiekelingen.

Ze zijn een beetje apart ja. Ik tel gelukkig niet mee, want ondanks al mijn Appletjes (stuk of 6 gehad inmiddels, 3 nog) zijn 2e hands.

Designers en designliefhebbers. Misschien geen computernerds, maar op een bepaalde manier toch nerds.

Ik haat die term. Te veel emotioneel en te weinig inhoud.

Dat zijn mensen die goed omgaan met veranderingen en daar zelfs blij mee zijn. Als Apple z'n marktaandeel in besturingssystemen uitbreidt tot 10 of 20%, dan zullen ze waarschijnlijk tegen wat meer bezwaren aanlopen als ze iets veranderen of niet implementeren.

Nee. Ze kunnen met de huidige filosofie makkelijk nog 50% andere casual thuisgebruikers aantrekken. Pas als ze echt de bedrijven markt opgaan, dan gaat er een en ander veranderen.

Microsoft heeft die fase al gehad (zeg maar in de periode tot 1987) en draagt nu de lasten van een hoop legacy features en gebruikers die klagen als er ergens een pixel verandert in de GUI, laat staan in de fundamentele werking van het systeem.

Denk eraan dat Microsoft dan ook 4-5 keer zoveel vraagt voor een OS.

Dat zou ze er natuurlijk niet van moeten weerhouden om verbeteringen door te voeren, en ik ben ook geen tegenstander van de Unix-manier. Ik denk alleen dat het in de praktijk niet zo makkelijk door te voeren is als je hier schetst.

Ik denk dat ze het al halfslachtig (op shell niveau) gedaan hebben. (documents en settings en andere folders die virtueel/links zijn) En eerlijk gezegd denk ik dat het slimmer was geweest om het heel in te zetten, en een fase van zeg 5 jaar in te gaan waar driveletters legacy zijn.

Het had in Windows 6 moeten zitten (Windows 6.1 is maar een pointrelease), ach, maar afwachten tot windows 7 uitkomt.

[GolezTrol]

Denk eraan dat Microsoft dan ook 4-5 keer zoveel vraagt voor een OS.

Daar boven zeg je dat het vooral bedrijfsgebruikers zijn die klagen. Dit argument is dan irrelevant. Binnen een bedrijf zijn de mensen die klagen andere mensen dan de mensen die de rekening betalen.

Tegen de tijd dat het geklaag die laag heeft bereikt, is men er alweer aan gewend.