/dev/null
- Overig
Grappig datumprobleem....
02-01-2022, 18:33 door Anoniem, 29 reacties
Sommigen hebben een datum in YYMMDDHHMM format gebruikt als een soort timestamp, bijvoorbeeld als serienummer
voor DNS of als volgnummer voor een virus db update ofzo. Dingen die niet heel vaak geupdate moeten worden.
Dit geeft dan nu waardes als 2201021830.
Kennelijk zijn er onder die sommigen ook nog die dat getal dan in een 32-bit signed integer zetten, maar die heeft de
maximale waarde 2147483647. Dus vorig jaar ding dat nog goed, maar nu niet meer.
Met een unsigned value is het maximum 4294967295 dus dat werkt nog tot 2043.
Natuurlijk is het wel een vreemde beslissing om zo te programmeren. Maar het bekende bedrijf uit Redmond heeft dat
kennelijk toch geflikt en daar is nu een probleempje...
(in Exchange server malware scanning, die dit format wellicht gebruikt voor signature versies)
voor DNS of als volgnummer voor een virus db update ofzo. Dingen die niet heel vaak geupdate moeten worden.
Dit geeft dan nu waardes als 2201021830.
Kennelijk zijn er onder die sommigen ook nog die dat getal dan in een 32-bit signed integer zetten, maar die heeft de
maximale waarde 2147483647. Dus vorig jaar ding dat nog goed, maar nu niet meer.
Met een unsigned value is het maximum 4294967295 dus dat werkt nog tot 2043.
Natuurlijk is het wel een vreemde beslissing om zo te programmeren. Maar het bekende bedrijf uit Redmond heeft dat
kennelijk toch geflikt en daar is nu een probleempje...
(in Exchange server malware scanning, die dit format wellicht gebruikt voor signature versies)
Reacties (29)
In applicaties is het verstandig om gebruik te maken van ISO-8601 voor date-timestamps.
Bijna alle software libraries ondersteunen ISO-8601 format, en dit maakt import/export van data gemakkelijk.
Bijna alle software libraries ondersteunen ISO-8601 format, en dit maakt import/export van data gemakkelijk.
Het lijkt eerder een marketingstrategie: net zolang problemen en ellende in een product inbouwen totdat iedereen het heeft laten vallen en naar Exchange Online over is.
03-01-2022, 07:28 door
gradje71
Ik dacht dat ze daar al in 1999 hier serieus aan gewerkt hadden, maar kennelijk hebben die programmeurs dat probleem nog niet onderkent. Wederom een heel goede reden om MS de deur uit te gaan doen.
Door gradje71: Ik dacht dat ze daar al in 1999 hier serieus aan gewerkt hadden, maar kennelijk hebben die programmeurs dat probleem nog niet onderkent. Wederom een heel goede reden om MS de deur uit te gaan doen.
De oplossing die ze 21 jaar gelden bedacht hadden is nu weer achterhaald :-)
En de volgende oplossing weer in 2043.
Etc, etc, etc
Door gradje71: Ik dacht dat ze daar al in 1999 hier serieus aan gewerkt hadden, maar kennelijk hebben die programmeurs dat probleem nog niet onderkent. Wederom een heel goede reden om MS de deur uit te gaan doen.
Inderdaad, dat was ook de reden, dat Windows-98 gereset moest worden, omdat de up-time werd bijgehouden als 32bits getal, deze kon dan ook niet een week non-stop werken.Werd het getal groter dan 32 bits, dan crashte Windows-98.
Leren uit het verleden en fouten onthouden is blijkbaar lastig.......... :-)
Door Anoniem: In applicaties is het verstandig om gebruik te maken van ISO-8601 voor date-timestamps.
Bijna alle software libraries ondersteunen ISO-8601 format, en dit maakt import/export van data gemakkelijk.
Ik zou voor RFC3339 (https://www.rfc-editor.org/rfc/rfc3339) gaan. Beter nog, gebruik een formaat dat door beide standaarden wordt geaccepteerd.Bijna alle software libraries ondersteunen ISO-8601 format, en dit maakt import/export van data gemakkelijk.
Door Anoniem: In applicaties is het verstandig om gebruik te maken van ISO-8601 voor date-timestamps.
Bijna alle software libraries ondersteunen ISO-8601 format, en dit maakt import/export van data gemakkelijk.
Bijna alle software libraries ondersteunen ISO-8601 format, en dit maakt import/export van data gemakkelijk.
Het probleem is dat men (zoals zo vaak bij dat bedrijf) geprobeerd heeft om met een "slim gekozen format" (het jaar
maar als 2 cijfers ipv 4 en dan nauwkeurigheid tot op 1 minuut) het voor elkaar gekregen heeft om een timestamp in
8 cijfers te proppen, terwijl men dat dan ook nog eens als een binaire waarde wilde gaan verwerken.
Was er gekozen voor YYYYMMDDHH dan was het voorlopig niet fout gegaan. Maar 1 uur resolutie vond iemand
kennelijk niet goed genoeg. Dus werd het compromis YYMMDDHHMM gekozen. Alsof Y2K nooit bestaan heeft.
Dit gecombineerd met signed waarden breekt hen nu op.
Kijk ze hadden ook YYYYMMDDHHMMSS kunnen gebruiken en dan een 64-bit variabele. Die mag dan zelfs signed
zijn. Afijn genoeg goede oplossingen.
Door Anoniem: Zie ook: https://borncity.com/win/2022/01/02/microsoft-besttigt-exchange-year-2022-problem-fip-fs-scan-engine-failed-to-load-1-jan-2022/ en https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-exchange-on-premises-transport-queues/ba-p/3049447
Gaat nog wat worden in 2038 .....
Of Epochalypse... Dat is al 2 jaar eerder en als je ziet hoeveel legacy daar nu nog mee draait. Gaat nog wat worden in 2038 .....
https://en.wikipedia.org/wiki/Year_2038_problem
Door gradje71: Ik dacht dat ze daar al in 1999 hier serieus aan gewerkt hadden, maar kennelijk hebben die programmeurs dat probleem nog niet onderkent. Wederom een heel goede reden om MS de deur uit te gaan doen.
Je bedoelt onderkend, maar dat terzijde.Exchange is er al sinds 1996, maar van wanneer de FIPS-FS Scanner Engine is is mij niet duidelijk. Ik vermoed dat het datumveld waar het om gaat pas na de eeuwwisseling in gebruik is genomen, want negatieve getallen inzetten bij een binair getal dat in decimale weergave overeenkomt met een datum is wel erg omslachtig.
Mij zou het niet verbazen als het ver na 2000 is gebouwd door programmeurs die te jong zijn om het Y2K-probleem zelf bewust te hebben meegemaakt, en die door gebrek aan die ervaring een soortgelijke fout hebben gemaakt.
Is er hier iemand die weet wanneer de FIPS-FS Scanner Engine voor het eerst is uitgekomen?
Door Anoniem:
Exchange is er al sinds 1996, maar van wanneer de FIPS-FS Scanner Engine is is mij niet duidelijk. Ik vermoed dat het datumveld waar het om gaat pas na de eeuwwisseling in gebruik is genomen, want negatieve getallen inzetten bij een binair getal dat in decimale weergave overeenkomt met een datum is wel erg omslachtig.
Mij zou het niet verbazen als het ver na 2000 is gebouwd door programmeurs die te jong zijn om het Y2K-probleem zelf bewust te hebben meegemaakt, en die door gebrek aan die ervaring een soortgelijke fout hebben gemaakt.
Is er hier iemand die weet wanneer de FIPS-FS Scanner Engine voor het eerst is uitgekomen?
Het grote probleem van MS is dat zij zo'n grote blobs maken. Waar stond Microsoft oorspronkelijk ook voor? "Micro" "soft", dus micro software. Daar zijn zij al heel lang geleden vanaf gestapt. Als zij de UNIX filosofie hadden geimplemtenteerd dan hadden zij waarschijnlijk iets meer moeten gaan doen in hun documentatie, maar hadden zij hun code veel beter kunnen controleren en waarschijnlijker ook een veel veiliger systeem op kunnen zetten. Dat hebben die briljante gasten dus niet gedaan en nu zitten jullie met de problemen. Veel succes allemaal.Door gradje71: Ik dacht dat ze daar al in 1999 hier serieus aan gewerkt hadden, maar kennelijk hebben die programmeurs dat probleem nog niet onderkent. Wederom een heel goede reden om MS de deur uit te gaan doen.
Je bedoelt onderkend, maar dat terzijde.Exchange is er al sinds 1996, maar van wanneer de FIPS-FS Scanner Engine is is mij niet duidelijk. Ik vermoed dat het datumveld waar het om gaat pas na de eeuwwisseling in gebruik is genomen, want negatieve getallen inzetten bij een binair getal dat in decimale weergave overeenkomt met een datum is wel erg omslachtig.
Mij zou het niet verbazen als het ver na 2000 is gebouwd door programmeurs die te jong zijn om het Y2K-probleem zelf bewust te hebben meegemaakt, en die door gebrek aan die ervaring een soortgelijke fout hebben gemaakt.
Is er hier iemand die weet wanneer de FIPS-FS Scanner Engine voor het eerst is uitgekomen?
Wie zei dat ook alweer? "Succes is een keuze"
Door gradje71: Waar stond Microsoft oorspronkelijk ook voor? "Micro" "soft", dus micro software. Daar zijn zij al heel lang geleden vanaf gestapt.
Het zal eerder bedoeld zijn geweest als software voor microcomputers. In die tijd was een indeling in mainframes, minicomputers en microcomputers gangbaar. De huidige pc's en servers waar Windows op draait zijn nog altijd een doorontwikkeling van wat destijds onder microcomputers viel.Het lijkt misschien een datumprobleem, maar dat is het niet. Vooral niet als je kijkt naar e oplossing die Microsoft nu voor de korte termijn gekozen heeft. Ze zijn de malware-definities gewoon gaan doornumeren.
Dus de eerstvolgende werkende versie na 1-1-2022 werd 2112330001. Als dit een datum zou zijn, dan is het dus 33 december.
Lijkt gewoon op een onhandig gekozen versienummer-systeem, of nog waarschijnlijker werd de integer gecompileerd naar een int32 terwijl er een aanname werd gedaan dat op een 64-bitsysteem het een int64 zou zijn en dus nooit een probleem had mogen opleveren.
Dus de eerstvolgende werkende versie na 1-1-2022 werd 2112330001. Als dit een datum zou zijn, dan is het dus 33 december.
Lijkt gewoon op een onhandig gekozen versienummer-systeem, of nog waarschijnlijker werd de integer gecompileerd naar een int32 terwijl er een aanname werd gedaan dat op een 64-bitsysteem het een int64 zou zijn en dus nooit een probleem had mogen opleveren.
03-01-2022, 14:37 door
Bitje-scheef
Gewoon knullig. Hieraan vertrouw je een essentiële communicatiedienst toe.
Het grote probleem van MS is dat zij zo'n grote blobs maken. Waar stond Microsoft oorspronkelijk ook voor? "Micro" "soft", dus micro software. Daar zijn zij al heel lang geleden vanaf gestapt. Als zij de UNIX filosofie hadden geimplemtenteerd dan hadden zij waarschijnlijk iets meer moeten gaan doen in hun documentatie, maar hadden zij hun code veel beter kunnen controleren en waarschijnlijker ook een veel veiliger systeem op kunnen zetten. Dat hebben die briljante gasten dus niet gedaan en nu zitten jullie met de problemen. Veel succes allemaal.
Wie zei dat ook alweer? "Succes is een keuze"
Wie zei dat ook alweer? "Succes is een keuze"
Dit heeft niet zoveel met Unix filosofie te maken. Dit is gewoon knullig coderen van de bovenste plank. Controleren en testen is behoorlijk weggezakt bij MS. Teveel focus op cloud.
03-01-2022, 15:05 door
Briolet
Door Bitje-scheef: Dit heeft niet zoveel met Unix filosofie te maken. Dit is gewoon knullig coderen van de bovenste plank. …
Ja Als je een representatie systeem verzint, kijk je toch ook wat het grootste en kleinste getal is wat er in past? Een signed integer kan natuurlijk voor een datum, want je wilt misschien ook een datum van voor het nulpunt kunnen weergeven. (Hoewel zulke oude mail natuurlijk niet zal bestaan)
Toen ik in de jaren 80 leerde rekenen op computers, werd ons er al op gewezen dat de volgorde van bewerken, uitmaakte op de uitkomst. Dit vanwege de begrensde opslaglengte van getallen. Als programmeur moet je daar altijd rekening mee houden.
Door Anoniem: Het lijkt misschien een datumprobleem, maar dat is het niet. Vooral niet als je kijkt naar e oplossing die Microsoft nu voor de korte termijn gekozen heeft. Ze zijn de malware-definities gewoon gaan doornumeren.
Dus de eerstvolgende werkende versie na 1-1-2022 werd 2112330001. Als dit een datum zou zijn, dan is het dus 33 december.
Lijkt gewoon op een onhandig gekozen versienummer-systeem, of nog waarschijnlijker werd de integer gecompileerd naar een int32 terwijl er een aanname werd gedaan dat op een 64-bitsysteem het een int64 zou zijn en dus nooit een probleem had mogen opleveren.
Het was een datumprobleem omdat in die versienummers een datum verwerkt was en dat in een veld belandde waar dat niet meer in paste. Dat men het heeft opgelost door te stoppen het als datum te interpreteren wil niet zeggen dat dat het probleem niet was. Dat was het wel, er werd binnen een veld een codering gebruikt met een datum erin die vanaf 2022 niet meer past. Dan is het volkomen terecht om het een datumprobleem te noemen.Dus de eerstvolgende werkende versie na 1-1-2022 werd 2112330001. Als dit een datum zou zijn, dan is het dus 33 december.
Lijkt gewoon op een onhandig gekozen versienummer-systeem, of nog waarschijnlijker werd de integer gecompileerd naar een int32 terwijl er een aanname werd gedaan dat op een 64-bitsysteem het een int64 zou zijn en dus nooit een probleem had mogen opleveren.
Door Anoniem: Is er hier iemand die weet wanneer de FIPS-FS Scanner Engine voor het eerst is uitgekomen?
Vergeet de bashers, die herkennen het probleem niet als de code voor ze open en bloot ligt.Van voor 2013 zijn er geen hits te vinden.
https://social.technet.microsoft.com/Forums/en-US/4b6293a3-0c2c-4299-b1fd-55d732586904/exchange-transport-filtering-management-services-throttling-fail-to-start?forum=exchangesvrgeneral
Ik zie andere hints dat het vanaf 2013 geintegreerd werd.
Duidt op een eerdere overname. deze zou dat kunnen zijn: https://news.microsoft.com/2005/06/21/sybari-and-microsoft-delivering-enterprise-security-value-through-integration-and-collaboration/
Door Anoniem: Het was een datumprobleem omdat in die versienummers een datum verwerkt was en dat in een veld belandde waar dat niet meer in paste. Dat men het heeft opgelost door te stoppen het als datum te interpreteren wil niet zeggen dat dat het probleem niet was. Dat was het wel, er werd binnen een veld een codering gebruikt met een datum erin die vanaf 2022 niet meer past. Dan is het volkomen terecht om het een datumprobleem te noemen.
Je beschrijft een klassiek bufferoverflow probleem. Met een conversie (gebruik geen is8601 strings intern!) moet je met een bereik rekening houden. Niets bijzonders en er lijkt zeer snel een oplossing voor te zijn.Gevolg van Agile werken waarbij ontwerp niet relevant is als het maar werkt. Zeer bekend als open source aanpak
Door Anoniem:
Door gradje71: Waar stond Microsoft oorspronkelijk ook voor? "Micro" "soft", dus micro software. Daar zijn zij al heel lang geleden vanaf gestapt.
Het zal eerder bedoeld zijn geweest als software voor microcomputers. In die tijd was een indeling in mainframes, minicomputers en microcomputers gangbaar. De huidige pc's en servers waar Windows op draait zijn nog altijd een doorontwikkeling van wat destijds onder microcomputers viel.Klopt. Microsoft ontwikkelde in die tijd ook voor IBM. Ze werden betaald per KLOC (1000 regels code). Die cultuur (more is more) zal ook wel hun eigen producten beinvloed hebben.
Door karma4: Je beschrijft een klassiek bufferoverflow probleem.
Nee, dit is geen buffer overflow. Dit is een conversie van vermoedelijk een string naar een 32-bit integer die stukloopt omdat de waarde niet in de integer past. Dat is iets wezenlijk anders dan het corrumperen van de inhoud van geheugen dat aan een buffer grenst omdat de grenzen van de buffer niet worden bewaakt. De berekeningen van de conversie worden in CPU-registers uitgevoerd, de buffer en het aangrenzende geheugen staan in RAM. Het komt niet in de buurt van hetzelfde probleem zijn.Gevolg van Agile werken waarbij ontwerp niet relevant is als het maar werkt.
Je kan onmogelijk weten of dat hier het geval is. Dit soort fouten werd bij waterval-ontwikkelmodellen als SDM net zo goed gemaakt. Zeer bekend als open source aanpak
Grappig hoe vaak je die opmerking plaatst als er iets in closed source misgaat. Alsof je iets aan probeert te vallen met argumenten die je niet hebt.Agile is een familie van werkwijzen voor ontwikkelteams in bedrijven en organisaties. Menig open source-project zal bijvoorbeeld geen boodschap hebben aan timeboxing om de kosten en voortgang voorspelbaar te houden, daar is juist veel vrijheid om het tempo aan te houden dat nodig is om een feature te realiseren. Een dagelijks, staande scrum-bijeenkomst van maximaal een kwartier is ook vrij lastig als de ontwikkelaars helemaal niet op dezelfde plaats en tijd werken aan het project. Agile is vooral bekend als closed source-aanpak, als je het mij vraagt.
Datumproblemen zijn niets nieuws.
Op 5 t/m 14 oktober 1582 hadden zo ook een aardig probleem.
(Check je kalender maar eens).
Op 5 t/m 14 oktober 1582 hadden zo ook een aardig probleem.
(Check je kalender maar eens).
Door Anoniem: Datumproblemen zijn niets nieuws.
Op 5 t/m 14 oktober 1582 hadden zo ook een aardig probleem.
(Check je kalender maar eens).
Op 5 t/m 14 oktober 1582 hadden zo ook een aardig probleem.
(Check je kalender maar eens).
Dat is een beetje misleidend.
"We" zijn toen overgestapt van de Juliaanse naar de Gregoriaanse kalender. En beiden kenden een andere berekening om bij het startpunt te komen. Vandaar dat die dagen die je noemt "verdwenen".
Anders gezegd: Na 5 oktober 1582 kwam als volgende dag 14 oktober 1582.
Zulk soort problemen ontstaan ook als bv de Joodse kalender door de Juliaanse kalender vervangen zou worden. oid (zoek ook maar op)
Het MS probleem heeft te maken met de opslag van de datum in een integer.
En dat past niet meer. IMHO luiheid van de toenmalige programemeurs (in het verlengde van "64k is voldoende voor alle gebruikers").
Door Anoniem: Datumproblemen zijn niets nieuws.
Op 5 t/m 14 oktober 1582 hadden zo ook een aardig probleem.
(Check je kalender maar eens).
Op 5 t/m 14 oktober 1582 hadden zo ook een aardig probleem.
(Check je kalender maar eens).
oktober 1582
ma di wo do vr za zo
1 2 3 4 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Er zijn vanwege de invoering van de Gregoriaanse kalender tien dagen vervallen: op 4 oktober volgde 15 oktober.
We zitten nu toch al opgescheept met een door Romeinse keizers verpeste kalender die 2 maanden opgeschoven is
waardoor je die rare situatie krijgt dat "september" de 9e maand is enz. (sept = 7), en de extra schrikkeldag in het
jaar zelf valt in plaats van helemaal aan het eind (als Maart de 1e maand was en Februari de laatste was dat handiger)
Nog beter zou het zijn als nieuwjaar op 21 maart zou vallen, of in ieder geval op het begin van de lente.
En een wat handiger maandindeling zou ook niet weg zijn.
Maar ja, ijdelheid en religie hebben het gewonnen van rationaliteit.
waardoor je die rare situatie krijgt dat "september" de 9e maand is enz. (sept = 7), en de extra schrikkeldag in het
jaar zelf valt in plaats van helemaal aan het eind (als Maart de 1e maand was en Februari de laatste was dat handiger)
Nog beter zou het zijn als nieuwjaar op 21 maart zou vallen, of in ieder geval op het begin van de lente.
En een wat handiger maandindeling zou ook niet weg zijn.
Maar ja, ijdelheid en religie hebben het gewonnen van rationaliteit.
Door Anoniem: We zitten nu toch al opgescheept met een door Romeinse keizers verpeste kalender die 2 maanden opgeschoven is
waardoor je die rare situatie krijgt dat "september" de 9e maand is enz. (sept = 7), en de extra schrikkeldag in het
jaar zelf valt in plaats van helemaal aan het eind (als Maart de 1e maand was en Februari de laatste was dat handiger)
Nog beter zou het zijn als nieuwjaar op 21 maart zou vallen, of in ieder geval op het begin van de lente.
En een wat handiger maandindeling zou ook niet weg zijn.
Maar ja, ijdelheid en religie hebben het gewonnen van rationaliteit.
waardoor je die rare situatie krijgt dat "september" de 9e maand is enz. (sept = 7), en de extra schrikkeldag in het
jaar zelf valt in plaats van helemaal aan het eind (als Maart de 1e maand was en Februari de laatste was dat handiger)
Nog beter zou het zijn als nieuwjaar op 21 maart zou vallen, of in ieder geval op het begin van de lente.
En een wat handiger maandindeling zou ook niet weg zijn.
Maar ja, ijdelheid en religie hebben het gewonnen van rationaliteit.
Je mag in de achterhoede gaan lobbyen voor een nieuwe revolutie .
Het is al eens geprobeerd :
https://nl.wikipedia.org/wiki/Franse_republikeinse_kalender
En nog een kleine oplevering
https://en.wikipedia.org/wiki/Swatch_Internet_Time
Door Anoniem: We zitten nu toch al opgescheept met een door Romeinse keizers verpeste kalender die 2 maanden opgeschoven is
waardoor je die rare situatie krijgt dat "september" de 9e maand is enz. (sept = 7), en de extra schrikkeldag in het
jaar zelf valt in plaats van helemaal aan het eind (als Maart de 1e maand was en Februari de laatste was dat handiger)
De werkelijkheid is rommelig, ja.waardoor je die rare situatie krijgt dat "september" de 9e maand is enz. (sept = 7), en de extra schrikkeldag in het
jaar zelf valt in plaats van helemaal aan het eind (als Maart de 1e maand was en Februari de laatste was dat handiger)
Nog beter zou het zijn als nieuwjaar op 21 maart zou vallen, of in ieder geval op het begin van de lente.
En een wat handiger maandindeling zou ook niet weg zijn.
Maar ja, ijdelheid en religie hebben het gewonnen van rationaliteit.
Ik zie het meer als de hardnekkigheid van gewoontes, versterkt doordat allerlei werkwijzen en systemen die gewoontes hebben geïntegreerd. Kijk bijvoorbeeld naar hoe moeilijk het is om het onderscheid tussen zomer- en wintertijd weer af te schaffen. Dat heeft niets met religie of ijdelheid te maken, en alles met weerstand tegen veranderen waar men aan gewend is.En een wat handiger maandindeling zou ook niet weg zijn.
Maar ja, ijdelheid en religie hebben het gewonnen van rationaliteit.
Door Anoniem:
Wat jij beschrijft is hoe moeilijk het is om er nu nog vanaf te komen. Wat ik bedoel is de manier waarop dit tot standDoor Anoniem:
Maar ja, ijdelheid en religie hebben het gewonnen van rationaliteit.
Ik zie het meer als de hardnekkigheid van gewoontes, versterkt doordat allerlei werkwijzen en systemen die gewoontes hebben geïntegreerd. Kijk bijvoorbeeld naar hoe moeilijk het is om het onderscheid tussen zomer- en wintertijd weer af te schaffen. Dat heeft niets met religie of ijdelheid te maken, en alles met weerstand tegen veranderen waar men aan gewend is.Maar ja, ijdelheid en religie hebben het gewonnen van rationaliteit.
is gekomen.
Door Anoniem: Kijk bijvoorbeeld naar hoe moeilijk het is om het onderscheid tussen zomer- en wintertijd weer af te schaffen. Dat heeft niets met religie of ijdelheid te maken, en alles met weerstand tegen veranderen waar men aan gewend is.
Zeg maar rustig: Politici die geen keus kunnen en willen maken?
Wat ze ook kiezen, ze hebben het altijd gedaan. Dus stellen ze een keuze uit.
De Europese Commissie legde de hete aanrdappel bij de landelijke regeringen. Die keken elkaar weer aan, want ze willen weer niet teveel van elkaar afwijken. En hun burgers en bedrijven hebben verschillende wensen of belangen.
Dan is de politieke kop in het zand steken, het veiligste.
En ik wordt nu al weer ruim 3 maanden voor 5 uur in de ochtend klaar wakker.
Lang leve een constante biologische klok die geen rekening houdt met een verzonnen zomer- of wintertijd.
Door Anoniem: Wat jij beschrijft is hoe moeilijk het is om er nu nog vanaf te komen. Wat ik bedoel is de manier waarop dit tot stand is gekomen.
Je noemde iets dat je beter zou vinden dan nu gebruikt wordt of ooit gebruikt is, en gooide je "maar ja"-opmerking over ijdelheid en religie direct daarachteraan. Dan is een reactie over weerstand tegen verandering niet zo vreemd, hoor. Ik reageerde kennelijk niet op wat je bedoelde, maar volgens mij wel op wat je schreef. ;-)Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime
Ben jij er klaar voor om de leiding te nemen in het bevorderen van de regionale samen-werking in de strijd tegen gedigitaliseerde criminaliteit en cybercrime? Samen met collega's, politie en regionale en landelijke partners? Dan is de dynamische rol van Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime bij het Regionaal Samenwerkingsverband Integrale Veiligheid (RSIV) jouw op het lijf geschreven!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.