Historisk set har det ikke fungeret ret godt at være ligeglad med at lande i nærheden begynder at ekskludere og forfølge befolkni
Hvem gør så det nu?
Og fik vi egentligt problemer pga. lige præcist det, eller kom problemerne ikke snarere pga. en en trang til erobring af nabolandene?
Set i det perspektiv skal du være bange for Rusland, ikke Polen.
Alle de ting du vil "reddes fra" kommer i virkeligheden fra dit eget behov fir at presse din moral ned over andre lande. Det er på den måde dig det er "imperialisten".
Det der foregår i Polen kan du i princippet være ligeglad med, mens det Irland var anklaget og frifundet for, rammer dig i form af konkurrenceforvridning.
Det er forskellen på Europas Forene Stater og et handelssamarbejde. I de Forenede Stater har man travlt med at moralisere overfor enkeltlande, mens man i et handelssamarbejde kun skal blande sig, hvis et land optræder konkurrenceforvridende.
Din regel ser ud til at være:
Brugerundtastede tidspunkter kan først oversættes til f.eks. UTC, når tidszonen er endeligt fastlagt.
Jeg har endnu en erfaring: Brug kun UTC, når tidsstempler skal sammenlignes med andre systemer eller overleve reboot. Mange interne timerne med mere skal køre på CLOCK_MONOTONIC eller tilsvarende. Problemet er, at uret kan hoppe, enten ved at nogen stiller tiden, eller NTP først finder tiden efter nogen tid. Så kan alle timerne time ud samtigdigt eller ikke fyre i lang tid. Det er ofte ikke den opførsel, som var tiltænkt. Desværre bruget meget API CLOCK_REALTIME både i C og Java.
På mit $DAYJOB startede vi med at tidsstemple data med UTC. Men så kunne tidsstempler hoppe baglæns eller der kunne komme hullet i datastrømmen. Det kunne algoritmerne ikke rigtigt tåle. Nu bruger vi noget, der er afledt af CLOCK_MONOTONIC og er monotont stigende. Så holdet vi blot styr på offset til UTC og regner først UTC ud vhja offset, når vi sender data ud til andre systemet, som skal sammenligne med andre data-kilder.
Problemet er diverse IT-systemer og protokoller (NTP) bruger UTC og ikke TAI, som er UTC uden skudsekundet.
GPS kører TAI i internt og sender en almanak indeholdende bl.a. skudsekundet ud periodisk. Problemet kommer først i systemklikken og NTP, hvor det måske ikke korrekte skudsekund skal ligges til. Lod man være med det og kun brugte det i, når man skriver tiden ud, præcist som sommertid og tidszoner (i moderne systemer uden for Kina i hvert fald), ville problemet være væk.
Målet for MS er klart stadig profitmaksimering.
Hvad ellers???? MS er et børstnoteret selvskal.
Dot-Com generationen er skyld i rigtig meget Teknisk Gæld.
Jeg har nu set "lortekode" fra før den tid.. Men jeg har også set en kodebase blive smadret af masseansættelser i 0'erne (jeg var selv en af dem). Så ja: "masseindvandring" i form af kraftig vækst i medarbejdere kan kraftigt øge gælden.
Teknisk gæld := problemer i koden, som besværliggøre videreudvikling; men er kunden ligemeget.
Problemer brugeren kan se er bugs. De kan komme fra, at teknisk gæld har gjort det svært at lave en feature rigtigt; men når først kunden ser problemer er det i min optik ikke teknisk gæld mere, men blot en bug. Men når det er blevet til en bug ved kunden, er det ofte for sent at ryde op...
Potentielle bugs, som manglende check på størrelsen af en buffer, er i grunden heller ikke teknisk gæld, men bare bugs, som skal rettes, og/eller komme med i "known defects".
Teknisk gæld er svært at få penge til at rette, da det ikke kan ses direkte som nye features eller bugrettelser her og nu. Men rettes det ikke stiger omkostningerne og kvaliteten daler.
Desværre vil pengefolkene ikke rigtigt høre på udviklerne, da det ofte er svært at kvantificere, hvor mange omkostninger en manglende oprydning koster. Lige her og nu ikke ret meget, men i løbet af 2 år??
Vi skal hele tiden tænke på, at gøre det nemt at udvikle videre inden for, hvad kan være realistiske retninger de næste år. Det er ikke et spørgsmål om, at alt koden skal være pæn, have 100% test coverage, men, at arbejdsgangen for at tilføje og få testet en feature, og released en ny version af systemet, skal være så lille som muligt. Teknisk gæld fordyre den cyklus, da ændringer af dårlig kode eller kode uden ordentlige tests giver en masse overraskelser sent i forløbet, som fordyrer tingene voldsomt.
Tror du ikke blot journalisten har set, at GitHub er købt af Microsoft ?
Hvis man kun har filsystemets sikkerhed med adgangsrettigheder så er den sikkerhed væk når man booter i det andet OS, ligegyldigt om det er linux->windows->mac eller omvendt
Hvad havde du forventet? Et filsystem er en række bits på et read-(for det meste)write medie. Har man adgang til mediet kan man læse alt og ændre alt - inklusivt rettighedsbits. Kun et lag kryptering kan ændre det.
Dualboot er ikke dit problem, det er fysisk adgang til mediet.
Man kunne jo blot give dem højere bevillinger: det absolut vigtigste i retssamfund og demokrati, er at staten holder den indre og ydre fred. Gør den ikke det, har vi ikke hverken demokrati og retsstat.
Derfor skal politiet have midler til at bevogte grænserne OG beskytte Rasmus Paludan OG fange almindelige forbrydere. Der må aldrig blive enten eller.
Har Rust macroer???
Jeg kan se type generiske metoder som i ML og andre funktionelle sprog. Og generiske typer. De minder end del om templates, men er umiddelbart ikke så kraftfulde: man kan så vidt jeg kan se ikke angive andet end typer som argument. Jeg kan derfor ikke se, hvordan man kan lave noget, som minder om boost::unit - fysiske enheder indlejret i typerne og checket compile-time med zero runtime overhead. Man får f.eks. en compile fejl, hvis man ligger en længde til en længde med en tid, fås en hastighed. Enhedsalgebra compile-time, kort og godt.
Det jeg kunne finde på nettet bar rundt på enheder runtime, ligesom forsøget på at lave det i Java. Det giver jo selv sagt et overhead.
Det som man mangler er en generisk type, som kan regne på potenser i enhederne, f.eks. m*m / s / s = m^2 s^-2 compile time.
Det er ikke lige til i Rust, da man ikke kan angive potenserne ovenfor som "template" argumenter og regne på dem compile time.
Der er en del forskel på macroer og templates: de sidste er et Turing-komplet, funktionelt programmeringssprog, som kører i compileren og genererer ny kode og typer undervejs. Med optimering slået til, vil man ofte få fjernet meget af koden igen, og lokkeren kan måske også fjerne ubrugte symboler; men generelt bliver alle "mellemregningerne" hængende i det endelige program.
Jeg foretrækker selv templates frem for macroer, da disse bliver meget værere, hvis de skal skulle bare en smule af, hvad templates kan. Se blot på Linux kernens list implementation: det kan gøres meget kønnere med templates.
Der er en del forskel på macroer og templates: de sidste er et Turing-komplet, funktionelt programmeringssprog, som kører i compileren og genererer ny kode og typer undervejs. Med optimering slået til, vil man ofte få fjernet meget af koden igen, og lokkeren kan måske også fjerne ubrugte symboler; men generelt bliver alle "mellemregningerne" hængende i det endelige program.
Jeg foretrækker selv templates frem for macroer, da disse bliver meget værere, hvis de skal skulle bare en smule af, hvad templates kan. Se blot på Linux kernens list implementation: det kan gøres meget kønnere med templates.
Det, som laver megen ekstra, ukontrolleret kode i C++, er templates. Dem har man så vidt jeg ved også i Rust.
Jeg har selv brændt nallerne med at lave pæn C++ kode, som miksede templates og virtuelle funktioner: det gav et hav af klasser med virtuelle tabeller og runtime type-information, som fyldte alt for meget på et 16 MB stort system.
Nu koder jeg på PC størrelse systemer, og har derfor ikke den slags problemer. Jeg har gennemtvunget, at vi kun lavet een-trådede programmer, men flere af dem på Linux og på den måde bruger MMU'en til at gennemtvinge data-adskillelse. På den måde er C++ mindst lige så nemt som Java - men det oversætter meget langsommere, og værktøjerne er dårligere.
Det samme gør man iøvrigt ofte i mere embeddede systemer uden MMU, her bruger man blot besked-køer frem for pipes eller TCP forbindelser, som vi gør.
Med Rust ville jeg nok turde begynde at parellelliserer noget af koden direkte inde i hvert program, men med C++, holder jeg mig til at parellisere ved at starte flere processor op og samle igen. Det kan også bedre spredes ud på mange maskiner.
Nede i kernen, hvor parellisering er uundgåelig, er Rust nok helt klart at foretrække - men man skal nok ikke drømme om mindre hukommelsesforbrug end C++, da Rust, så vidt jeg kan se, bygger på meget af det samme.
Scrum er "mini-vandfald", hvor man bibeholder en vandfaldsmodel inden for hver iteration: alle opgaver skal være nedbrudt og have klare krav inden man går igang.
Jeg kan personligt langt bedre lide at finde ud af krav og detaljer undervejs: det er mere effektivt og muliggør innovation langt bedre. Det kan snildt være i løbende sparring med en stakeholder. Men på den måde kan et team godt blive opløst i enmandshærer, som løser hver sin opgave.
Scrum er godt hvis estimater er vigtigere end innovation og afvikling af kodegæld, eller for nye udviklere, som ikke har domænekendskab og derfor skal have nedbrudte og præcise opgaver.
I sidste ende tror jeg det bedste resultat opnås med tillid mellem "kunde" og udviklere. For lidt tillid giver for meget fokus på proces og estimater, som igen har det med både at bremse innovation og løbende oprydning af koden og andre indadvendte optimeringer.
Vi var godt igang med online, webbaserede systemer, som virkede i stort set alle browsere på alle platforme op igennem 0erne.
Men så kom iPhone og hele industrien blev så benovet over Apples indtjening på den, så nu skulle alting være en app - altså tilbage til vendor lockin, hvor man ikke kan komme med et nyt OS, der ikke kan køre disse apps. Selv Microsoft kunne ikke komme ind på markedet!!
Jeg foretrækker helt klart en webmodel, hvor hver webapplikation hænger sammen på serversiden, og man kun skal køre javascript på klienten. Så kan jeg nemlig køre Linux, lave sikkerhedsopdatere osv. uden at være nervøs for at knække een eller anden gammel applikation lokalt.
Jeg mener, at alt administrativ IT bør bygges op af små webapplikationer, med tilhørende rest APIer, så systemerne kan snakke sammen. Brugeren skal blot have en browser.
Ud med Office og alle mulige fede klienter.
Han har feks lavet LGPL for at ikke-fri (kommercielt) kan køre ovenpå frie libraries. FSF tog Gnome ind, fordi KDE var baseret på QT, som kun var GPL eller kommercielt licenseret, så man ikke kunne lave kommercielle programmer uden en kommerciel license til QT. GTK var LGPL fra starten.
Han har vist fra starten, at 100% copyleft ikke ville fungere, og derfor indgået kompromisser. (Men med GPLv3 har han godt nok dummet sig, synes jeg..)
Så er landmanden der laver mælk til soldaternes morgenmad vel også et militært mål?
Hvor går grænsen? Hele samfundet levere om ikke andet økonomi til krigsmaskinen.
Og ret beset er vi vel i et demokrati alle voksne militære mål: over 50% af os har jo stemt på det flertal i folketinget, som sender os i krig.
Personligt synes jeg Microsofts - og tidligere Googles - ansatte er meget hykleriske: på den ene side vil de ikke bidrage til egen demokratisk valgte regirings forsvarsstyrker; men på den anden side render de og laver overvågningsteknologi, som deres regering bruger mod egen befolkning i stor stil.
SpaceX's Starlink kræver nogle specialbyggede jord-stationer, som vil være i slæbbar størrelse - bestemt ikke i telefonstørrelse. Phased-array antenner på Ku-bånd, så hver station kan følge den satellit, som er tættest på, og skifte løbende, når de flytter sig hen over himlen.
Det er urealistisk at en mobiltelefon uden beamstyring og meget lille antenne kan have gain nok til at snakke to-vejs med en satellit 1000km væk...
Nej, det er vel fordi SpaceX vil lave deres egen Starlink konstellation. De har sendt to prototyper op, og nogen påstår de kommer igang med første stadie af operative satellitter i år - noget med tilladelserne til brug af spektrum, som skal bruges, samt at de påstår at skulle lave flere opsendelser end der officielle kunder til - dermed udleder nogen, at det er Starlink, de påbegynder i år.
Esben Nielsen