Yngve vil at Microsoft skal ligge unna tastaturet hans

[missi]

GPO satt opp av arbeidsgiver?

[missi]

Jeg trodde dette var et symptom på at folk ikke vet om ALT+SHIFT (eller evt CTRL+SHIFT).

 

En av disse tastkombinasjonene bytter nemlig tastatur layout, lett å trykke ved en feil...

Hvordan kan en bytte til noe som en har fjernet? (Men som så sniker seg tilbake igjen).

[Gjest Slettet-t8fn5F]

Dette har vært et problem siden Windows 10 ble lansert. Det eneste som hjelper er å benytte seg av et norskt image fra Microsoft. Ikke benytte seg av engelsk image og deretter skifte over til norsk språk. Usikker på om norsk image er tilgjengelig for privatpersoner, men er tilgjengelig via MSDN.

Alle Windows versjonene ble laget med engelsk språk fra og med Windows 7 (tror jeg det var). Før måtte man bruke en spesiell versjon som het MUI versjon, for å ha Windows med flere språk.

Så når du laster ned et "norsk" image, så er det bare ferdig pålagt norsk språkpakke.

[Gjest Slettet-t8fn5F]

Ja, det er det vi snakker om? Når jeg bytter språket mellom norsk og engelsk (tastaturspråket) med windows+space (før jeg deaktiverte det) så endrer alt av plasseringer på seg (æ, ø, å er borte, spesialtegn er flyttet osv).

Trodde du mente displayspråket. Det skifter ikke sånn helt av seg selv, men det må nok en avlogging til først.

 

Tastaturspråket kan skifte sånn helt alt etter hvilket program man kjøre. Kjører man et program som kun støtter engelsk. så kan det programmet be om engelsk tastaturoppsett. At det programmet ikke klarer å skifte tilbake til ønsket oppsett, er nok en svakhet i programmet og ikke Windows. Programmer som kjører i bakgrunnen kan også ha en slik oppførsel.

[Comma Chameleon]

Trodde du mente displayspråket. Det skifter ikke sånn helt av seg selv, men det må nok en avlogging til først.

 

Tastaturspråket kan skifte sånn helt alt etter hvilket program man kjøre. Kjører man et program som kun støtter engelsk. så kan det programmet be om engelsk tastaturoppsett. At det programmet ikke klarer å skifte tilbake til ønsket oppsett, er nok en svakhet i programmet og ikke Windows. Programmer som kjører i bakgrunnen kan også ha en slik oppførsel.

Trodde det var tastaturspråket og ikke displayspråket det var snakk om i tråden her. Hvis jeg har tatt feil så trekker jeg tilbake mine innlegg. 

[Gjest Slettet-t8fn5F]

Trodde det var tastaturspråket og ikke displayspråket det var snakk om i tråden her. Hvis jeg har tatt feil så trekker jeg tilbake mine innlegg. 

Pedantisk sematikk tilsier tastaturoppsett og displayspråk.

 

Flytter man Norsk øverst i listen over språk, så blir norsk til standard app språk og standard inputspråk.

Dette MÅ man gjøre selv og Engelsk er som standard øverst.

 

[Gjest Slettet-t8fn5F]

Installerte nettopp Norsk versjon og der kommer ikke engelsk opp som noe valg i det hele tatt.

 

[Bing123]

Fiksen er å fjerne Windows fra maskinen din.

[nullogniks]

Er jo bare så WINDOWS -ever lasting stupid problems :-((

[Gjest Slettet+5132]

Installerte nettopp Norsk versjon og der kommer ikke engelsk opp som noe valg i det hele tatt.

 

 

Tror du dette dukker opp med en gang? Hvis det var så lett å reprodusere denne buggen, hadde nok utviklerteamet fikset det. Det ligger litt i buggens natur, iallfall når man har minimalt med QA, at bugs som ikke blir oppdaget må på en eller annnen måte opptre sporadisk.

 

Og nei, det trenger ikke å være brukeren som gjør noe "feil". Det kan være du ikke aktiverer en innstilling  som trigger det hele (en innstilling som er helt lovlig, og som egentlig ikke har noe med tastaturlayout å gjøre).

[Gjest Slettet-t8fn5F]

Tror du dette dukker opp med en gang? Hvis det var så lett å reprodusere denne buggen, hadde nok utviklerteamet fikset det. Det ligger litt i buggens natur, iallfall når man har minimalt med QA, at bugs som ikke blir oppdaget må på en eller annnen måte opptre sporadisk.

 

Og nei, det trenger ikke å være brukeren som gjør noe "feil". Det kan være du ikke aktiverer en innstilling  som trigger det hele (en innstilling som er helt lovlig, og som egentlig ikke har noe med tastaturlayout å gjøre).

Ja om det er feil med Windows, så skal dette oppdages lett og det skal skje med alle som har installert Windows. Det er generell debugging. Finne ut om det er systemet eller brukeren som feiler.

 

Men som oftest er det brukere som ikke engang kan lese eventlogger som roper høyest.

[Gjest Slettet+5132]

Ja om det er feil med Windows, så skal dette oppdages lett og det skal skje med alle som har installert Windows.

Det der er en grov misoppfattelse. Har du for eksempel en race condition et sted i koden vil det kun skje et par utvalgte brukere et par tilfeldige ganger. Men det er likefullt en bug. Det kan være en bug som blir trigget av spesiell hardware, uten at det er feil i hardwaren, og det vil likevel være en bug.

 

Det er dessuten mange, mange, mange bugs som IKKE er enkle å oppdage. Altså, enten så lyver du, eller så har du aldri programmert et program mer enn 1000 linjer i hele ditt liv.

 

Jeg klarer ikke å skjønne at du kan påstå noe slikt.

Endret 30. juni 2019 av Slettet+5132

[Gjest Slettet-t8fn5F]

Det der er en grov misoppfattelse. Har du for eksempel en race condition et sted i koden vil det kun skje et par utvalgte brukere et par tilfeldige ganger. Men det er likefullt en bug. Det kan være en bug som blir trigget av spesiell hardware, uten at det er feil i hardwaren, og det vil likevel være en bug.

 

Det er dessuten mange, mange, mange bugs som IKKE er enkle å oppdage. Altså, enten så lyver du, eller så har du aldri programmert et program mer enn 1000 linjer i hele ditt liv.

 

Jeg klarer ikke å skjønne at du kan påstå noe slikt.

Da vil den race condition gjelde alle med samme koden. Windows forholder seg ikke til tilkoblet hardware annet enn standarddrivere om ikke Microsoft har utviklet egne drivere.

 

For øvrig kan du legge av den den tonen med hva jeg har gjort eller ikke gjort. Det er kun idioter som kommer med karakteristikker på personer de vet null om.

Endret 30. juni 2019 av Slettet-t8fn5F

[fokkeslasken]

Da vil den race condition gjelde alle med samme koden.

Selv det å ikke ha identiske innstillinger i et system vil gjøre at de utfører forskjellig kode. At to systemer på noen måte vil kjøre samme kode er ekstremt usannsynlig.

Enhver datatekniker som skal sette opp to helt identiske systemer vil nok kunne si at det er mildest talt vanskelig. Man ender gjerne opp på "de er like nok til denne jobben".

[Gjest Slettet+5132]

Da vil den race condition gjelde alle med samme koden.

Hehe, misforstår du poenget med vilje? Hvis det er en race condition vil kodefeilen finnes på alle systemer, men den trenger ikke å manifistere seg på alle systemer, siden en race condition ikke alltid feiler.

 

Og det finnes strengt tatt hundrevis av muligheter for hvordan dette kan være en feil fra MS sin siden, og ikke en brukerfeil, selv om du har gjort ditt til å insinuere det motsatte.

[Gjest Slettet-t8fn5F]

Selv det å ikke ha identiske innstillinger i et system vil gjøre at de utfører forskjellig kode. At to systemer på noen måte vil kjøre samme kode er ekstremt usannsynlig.

Enhver datatekniker som skal sette opp to helt identiske systemer vil nok kunne si at det er mildest talt vanskelig. Man ender gjerne opp på "de er like nok til denne jobben".

 

 

Hehe, misforstår du poenget med vilje? Hvis det er en race condition vil kodefeilen finnes på alle systemer, men den trenger ikke å manifistere seg på alle systemer, siden en race condition ikke alltid feiler.

 

Og det finnes strengt tatt hundrevis av muligheter for hvordan dette kan være en feil fra MS sin siden, og ikke en brukerfeil, selv om du har gjort ditt til å insinuere det motsatte.

 

 

Så vi er på atomnivå nå... Ja ja hva enn som kreves for at usannsynlige tilfeller skal inntreffe.

[RikardStrand]

15 sekunder med Google gav följande link. Där ligger en registry nyckel som kan vara värt att titta på (en preload key).

 

Vet inte om det löser saken men kan ju vara värt en titt, @yngve.

 

https://superuser.com/questions/1092246/how-to-prevent-windows-10-from-automatically-adding-keyboard-layouts-i-e-us-ke

[fokkeslasken]

Så vi er på atomnivå nå... Ja ja hva enn som kreves for at usannsynlige tilfeller skal inntreffe.

Det heter jo usannsynlig for en grunn. Og hvertfall for min del var det eneste jeg reagerte på at du sa "Da vil den race condition gjelde alle med samme koden", som er beviselig feil bare ved det faktum at bugs eksisterer. Om det du sier der stemmer betyr det at utviklere aldri har kjørt den koden en bruker har funnet feil ved. Det som nok er nærmere sannheten er at utviklerene aldri har kjørt samme kode under samme omstendigheter. Og der kommmer jo usannsynlightene inn i bildet.

[Harald Bjorøy]

Mykje rart i kommentarane her... Eg observerer samme problemet, men det oppstår utelukkande når eg startar eit program som køyrer Java (interaktivt) . Dette er ikkje eit "religionsinnlegg", kun ein observasjon. Kan virke som jvm'en bytter tastatur.

[Gjest Slettet+5132]

Så vi er på atomnivå nå... Ja ja hva enn som kreves for at usannsynlige tilfeller skal inntreffe.

Nei, vi er absolutt ikke på atomnivå. Race condition kan inntreffe bare basert på hvordan scheduleren oppfører seg, og det trenger ikke å være på grunn av atomoistisk fysikk (selv om det selvsagt ikke er helt urelevant, men det er en helt annen diskusjon). Og de kan inntreffe rett som det er.

 

Betrakt følgende elementære C++ program:

 

 

#include <iostream>
#include <thread>
#include <vector>
#include <random>

int main(int argc, char **argv) {
  const int number_of_runs_per_thread = 16;
  volatile int counter = 0;
  int number_of_threads = 4;

  if (argc == 2) {
    number_of_threads = std::atoi(argv[1]);
  }

  std::vector<std::thread> threads;
  for (int t = 0; t < number_of_threads; ++t) {
    threads.push_back(std::thread([&]() {
      std::default_random_engine generator;
      generator.seed(std::chrono::system_clock::now().time_since_epoch().count());
      std::uniform_int_distribution<int> distribution(0, 9);
      for (int i = 0; i < number_of_runs_per_thread; ++i) {
        // add some random delay
        const int wait_time = distribution(generator);

        std::this_thread::sleep_for (std::chrono::milliseconds(wait_time));
        counter++;
      }
    }));
  }

  for (auto &thread : threads) {
    thread.join();
  }

  std::cout << "value of counter is: " << counter << std::endl;
  std::cout << "correct valuee is  : " << number_of_runs_per_thread * number_of_threads << std::endl;

  return 0;
}

 

kompiler og kjør ti ganger med si:

 

$ g++ -O2 threadtest.cpp -lpthread -o threadtest; for i in $(seq 1 10); do echo "RUN $i"; ./threadtest; done

da kan man få noe ala følgende output:

 

 

 

RUN 1
value of counter is: 62
correct valuee is  : 64
RUN 2
value of counter is: 61
correct valuee is  : 64
RUN 3
value of counter is: 62
correct valuee is  : 64
RUN 4
value of counter is: 64
correct valuee is  : 64
RUN 5
value of counter is: 64
correct valuee is  : 64
RUN 6
value of counter is: 64
correct valuee is  : 64
RUN 7
value of counter is: 64
correct valuee is  : 64
RUN 8
value of counter is: 63
correct valuee is  : 64
RUN 9
value of counter is: 63
correct valuee is  : 64
RUN 10
value of counter is: 64
correct valuee is  : 64

 

Altså var det ikke en stor feil hver gang, og den klarer det stort sett riktig, men likevel forekommer det av og til feil. Nå tenk deg at denne race conditionen skjer én gang under oppsett. Det trenger ikke å skje ofte, men det kan skje av og til.

 

Race condition trenger ikke å være eneste grunn til at dette skjer, men det er en av mange mulige opphav til en slik bug. En helt annen kan være at oppsettet kun trigger hvis valg X er satt et annet sted i systemet, selv om valg X ikke kan regnes som feil eller noe som egentlig skal aktivere denne oppførselen.

Endret 30. juni 2019 av Slettet+5132