Inlägg

Det är inte någon hel/halvsmutsig säljtaktik bara? Om "de" nu ringer upp folk så låter det ju mer som att de säljer något nytt?

(Typ "ja, du kan ju även fortsätta med det du har idag, men då får du ju inte 5G än på ett tag" vridet och vänt till något som låter som att man inte har något val)

Frågan får det att låta som att de faktiskt förväntas kontra detta sett till ännu effektivare x86-64-hårdvara och dessutom snart? 🤔
Känns väl mer som att AMD och Intel gör upp för sig om marknaden för native-x86-64 (med detta som USP snarare än effektivitet jämfört andra alternativ). Och det lär väl vara fortsatt relevant på någon nivå rätt länge även om Windows-on-ARM tar fart, men mer nischat.

Sen kan de ju välja att ocskå göra något annat än dagens x86-64, för den delen...

Det är ju inte så att hårdvaran har den funktionen, men Windows har en funktion som gör det på "kompatibla enheter" (tillräcklig beräkningskraft i NPU är väl det konkreta det handlar om, samt PR-spinn då), t.ex. dessa.

Ja, hårdvaran som sådan kommer ju fungera, men sedan är väl då frågan hur nedlåst firmware kommer vara på specifika enheter...

Det är nog många ärenden som är irrelevanta också, jag tycker t.ex. att rubriken här signalerar att folk verkar ha snedvridna förväntningar av vad syftet ens är.
Möjligen att en bättre blankett kan styra om det i viss mån, men jag misstänker att just något slags tröskel kan hjälpa till att tvinga folk att tänka till angående rimligheten.

Angående rubriken då alltså:

Precis, för en sådan enkel adapter från normal PCIe till 1x M.2 NVMe så behövs inte bifurcation.

Bifurcation handlar om att dela upp PCIe-banorna som hör till en (1) PCIe-kortplats i flera mindre grupper så att man kan ansluta flera stycken PCIe-enheter direkt, utan någon mellanhand.
Det behövs förstås en fysisk adapter för att ansluta dina M.2-prylar rent praktiskt, men adaptern behöver då inte något PCIe-bryggchip eller liknande som annars skulle behöva sitta mellan och förmedla kommunikationen åt de andra enheterna.

Det ses väl traditionellt som typ en server/workstation-funktion, inte något som "konsumenter behöver", så det varierar ju hur det ligger till med stödet...

(Och ja, åtminstone teoretiskt kan det finnas en mycket dyrare adapter med någon PCIe-brygga istället, som inte kräver bifurcation)

Ja, det kan ju absolut vara 2G/3G.

Sedan då frågan om vilket/vilka nät som används och hur. Nödsamtal kan väl ringas i vilket nät som helst, även utan SIM, men det finns väl mer funktioner?

Det är det väl inte, men det är också preorder. Jaja, de är väl skapligt i fas just nu (inte riktigt, men ja).
Jag skulle förstås hellre sett att Core Ultra var ute och då hellre att Snapdragon Elite X var preorder.

Najs.

Specmässigt känns det väl som att tenderar släpa efter något (är nog naturligt för en mindre aktör sådär), men själva konceptet med modularitet och reparerbarhet är ju fint.

Åtminstone "på sikt" tycker jag snarast att det låter väldigt sannolikt att också släpper ARM64-modeller, åtminstone om Windows-på-ARM-satsningen med Snapdragon Elite X osv får ordentligt fotfäste.

Dock känns det väl som att de släpar efter lite generellt och lär göra så även i detta avseende...

Just detta är väl inte ens ARNs funktion? (Och vadå "anmäla"?)

I ett ärende hos ARN är deras jobb att lämna *en rekommendation* angående konsumenträttsliga tvister, som ett alternativ till att gå till tingsrätten med allehanda små konsumenträttsliga tvister om struntsaker.

Seriösa butiker tar i regel ARNs rekommendationer på allvar.

Om det nu verkligen är en nätbluff, vad förväntar man sig om man skickar det till ARN? ARN kommer säga att köparen har rätt konsumenträttsligt, och ingen kommer bry sig om vad ARN säger.

Så länge det är standarddialoger i Windows så brukar de faktiskt tillåta ctrl-c (även om det inte finns någon indikation att det ska fungera).

Det finns ju dock alltid någon som vill vara speciell och bygger något eget, Microsoft är förstås själva inkluderade i den listan.

perl -i -pe 's/(GRUB_CMDLINE_LINUX_DEFAULT)="(.*)"/$1="$2 rd.luks.uuid='"${LUKS_UUID}"'"/' /etc/default/grub

Är inte helt säker, men skulle förutsätta att fedora-recovery-usb-miljön bara är allmänt systemd-ig och att localectl set-keymap se fungerar.

Men ja, annars får man ju, som du säger, finna sig och skriva bäst man kan. Eller fippla lite mer och ta det över nätverket...

Okej, ja det kan nog vara rätt praktiskt att ha en försökskanin för den där konverteringen...

Jag körde in Asahi (men då Fedora-spinnen) och gjorde motsvarande LUKS-konvertering på en Macbook Air för en tid sedan. Passade på innan jag hade något viktigt sparat, då spelar det ju inte heller så stor roll om man skulle göra bort sig...

Med Fedora så var det ju i princip bara att följa den där guiden, dock.
(Själva resize/LUKS-stegen stämmer väl fortfarande bra såvida man har Fedora med btrfs, vill minnas att stegen för bootbar usb var lite utdaterade.)

Dvs, jag antar att med ext4 så har du då isf hittat rätt filsystem att ändra på och, förmodar jag, använt resize2fs istället för btrfs resize i föregående steg?

Mount root and home filesystems from the btrfs filesystem on the LUKS mapping device:

mount -o subvol=root /dev/mapper/fedora-root /mnt
mount -o subvol=home /dev/mapper/fedora-root /mnt/home

Då är det bara ett steg iaf, dvs du kan stryka att montera home separat direkt. Och du lär inte behöva några särskilda mount options (dvs inget -o nånting öht).

Guiden har detta steg direkt före:

cryptsetup open /dev/nvme0n1p6 fedora-root
cryptsetup status fedora-root

Om du tagit dig igenom allt fram dit och gjort någon motsvarighet till detta så vet du då vad devicen heter (namngiven ovan) iaf.
(Dvs, i deras exempel namngiven "fedora-root", men du kanske valde ett annat namn). Jag låtsar här att du valde ubuntu-root som namn:

mount  /dev/mapper/ubuntu-root /mnt