Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
Google Chrome 152 byl prohlášen za stabilní. Nejnovější stabilní verze 152.0.7977.64 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Opraveno bylo 327 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Před 35 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
Apple představil čipy M6 a M5 Ultra, Mac mini s M6 nebo M5 Pro a Mac Studio s M5 Max nebo M5 Ultra. Fedora Asahi Remix zatím podporuje jenom M1 a M2.
Firefox 157 přinese zapnutou podporu rastrového grafického formátu JPEG XL. Založena je na v Rustu napsané implementaci jxl-rs používané i v Chrome a Chromiu.
Vanilla OS 3 „Reunion“ byl vydán. Tato na Debianu „Sid“ založená desktopová distribuce s transakčními aktualizacemi „neměnného“ základního systému (ABRoot) nově podporuje architekturu arm64 (vedle x86-64), podporuje reprodukovatelné sestavení většiny balíčků a vylepšuje systémové nástroje. Vlastní meta-správce balíčků APX nyní používá Distrobox v2 a je dostupný i pro jiné distribuce.
Personalities : [raid1]
md0 : active raid1 hda6[0] hdc1[1]
1576384 blocks [2/2] [UU]
/etc/raidtab
raiddev /dev/md0
raid-level 1
nr-raid-disks 2
nr-spare-disks 0
persistent-superblock 1
chunk-size 32
device /dev/hdc1
raid-disk 0
device /dev/hda6
raid-disk 1
Chci vyměnit zařízení hdc1 za nové sda5
následujícím způsobem: přidám sda5 do pole, projede
synchronizace, a potom odeberu hdc1.
Takže v fdisku oddíl sda5 označím jako Raid autodetect
naedituju raidtab následovně:
/etc/raidtab
raiddev /dev/md0
raid-level 1
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
chunk-size 32
device /dev/hdc1
raid-disk 0
device /dev/hda6
raid-disk 1
device /dev/sda5
failed-disk 2
a dbaje návodů zadám
raidstop /dev/md0
raidstart /dev/md0
raidhotadd /dev/md0 /dev/sda5
Načež by podle howto a dalších návodů měla začít synchronizace.
Ale nezačne.
[bod1]
/proc/mdstat vypadá pořád stejně:
Personalities : [raid1]
md0 : active raid1 hda6[0] hdc1[1]
1576384 blocks [2/2] [UU]
No, nic, nenapadlo mě nic chytřejšího, než:
raidsetfaulty /proc/md0 /dev/hdc1
Celkem neočekávaně najednou začala synchronizace mezi hda6 a sda5,
ikdyž je fakt, co jiného raidu zbývalo, že ?
[bod 2]
takže po jejím skončení shazuju raid
raidstop /dev/md0
upravuju raidtab
raiddev /dev/md0
raid-level 1
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
chunk-size 32
device /dev/hdc1
failed-disk 0
device /dev/hda6
raid-disk 1
device /dev/sda5
raid-disk 2
raidstart /dev/md0
a ejhle v /proc/mdstat mám:
md0 : active raid1 hda6[1] sda5[2]
1576384 blocks [2/1] [U_]
zadám raidhotadd /dev/md0 /dev/sda5
[bod 3]
probíhá synchronizace, po skončení mám
md0 : active raid1 hda6[1] sda5[2]
1576384 blocks [2/2] [UU]
OK
Provedu reboot, abych si ověřil, že systém je po výpadku
elektriky schopen sám naběhnout do použitelného stavu bez
ručního nastavování.
kouknu do /proc/mdstat:
tam
md0 : active raid1 hda6[1] sda5[2]
1576384 blocks [2/1] [U_]
což jak zrovna není žádaný stav.
Takže shazuju raid,
upravuju raidtab na:
raiddev /dev/md0
raid-level 1
nr-raid-disks 2
nr-spare-disks 0
persistent-superblock 1
chunk-size 32
device /dev/hda6
raid-disk 0
device /dev/sda5
raid-disk 1
po nahození synchronizace, a kýžený výsledek v mdtab:
md0 : active raid1 sda5[0] hda6[1]
1576384 blocks [2/2] [UU]
po dalších rebootech vše OK.
bod1
proč nezačne synchronizace, když by začít měla, jedná se přece
o prosté přidání disku do pole ?
bod2
proč synchronizace startuje až ve chvíli, kdy simulovaně odejde
jeden disk ?
bod3
proč když mám v konfiguraci dva dobré synchronizované disky a jeden
failed, nedojde k vyt vytvoření raid0 z těch dvou dobrých disků
hned po startu ?
Tiskni
Sdílej: