DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Zdravim,
mam taky problem, s ktorym si neviem uz dlhsie poradit. Resp. poradit ano, ale neviem sa ho uplne zbavit.
Problem je v tom, ze mam externy usb disk a na nom JFS filesystem. Pri kazdom uspavani sa vykona toto:
umount /media/disk
sync; sync; sync
Problem je ale v tom, ze ked sa ho pokusim neskor znovu pripojit, je potrebne vykonat fsck /dev/disk
, inak mu furt nieco vadi.. Vacsinu casu to nie je problem - pri fsck sa len prehra journal a je pokoj. Dnes sa ale journal neprehral, miesto toho sa spustila standardna kontrola a par giga dat (nastastie tam mam "len" nedolezite data a zalohy) slo do lost+found (samozrejme pod divnymi nazvami atd., takze v podstate su to uz nepouzitelne veci...).
Nie je divne ze aj po umount + 3x sync ostane ten disk v nekonzistentom stave?
Mna teda napada ako mozny zdroj problemov len to, ze ten disk je kus blby a nezapisuje data, ked ma ale drzi si ich pridlho v cache. A mam pocit ze cez USB mu neprikazem, ze uz to ma flushnut...
Druha moznost je ze niekto v ubuntu teame ten JFS pekne zmrsil - ale to sa mi az nechce verit, ze je to mozne.
Stretol (a vyriesil) sa niekto z vas s takymto niecim?
A jak ten disk napájíš ? Neodpojí PC dřív napájení než ten disk zapíše fyzicky ty data na plotny?
Co se stane když provedeš umount ručně, a počkáš třeba 1minutu a potom dáš Pc uspat ? Taky to poničí data ?
toto by problem nemal byt - umount snad nezabuda, ze ma nieco ulozit na disk :)
no to je prave jedna z tych moznosti - skusil som teraz taku vec, ze za sync dat este dd if=/dev/sdc of=/dev/null bs=1M count=100 iflags=direct
- tak uvidime, ci sa nieco zmeni.. mozno to disku pomoze, aby sa flushol..
on je totiz pripojeny externe v USB sufliku.. keby to rozhranie usb-disk nebolo tak blbo navrhnute, mohlo by sa pouzit hdparm -W 0
a bolo by po problemoch no...
Na Debianu (Etch, posléze Lenny i chvilkově Sid) jsem cca rok jako FS používal JFS.
Bez nějakých problémů.
Pak jsem loni na podzim zkoušel Kubuntu 8.10 a protože se mi nechtěla dělat instalaci a chtěl distro s KDE 4 pořádně omakat, nechával jsem cd v nb a ten uspával do ram (v podstatě několik dnů po sobě) ... pohoda.
Jenže, pak najednou nešly partišny s JFS po probuzení připojit - nastala pocopitelně panika, pak fsck /dev/disk ... opravilo se ... jen po dalším uspání jak přes kopírák to samé ... z nainstalovaného Debianu to pochopitelně taky nefakčilo.
To samé se při testování opakovalo před pár dny s Kubuntu 9.04 po uspání (instalace na hdd) a použítí JFS jako fs pro /.
Takže asi tak.
Ale třeba je to rukama .
prave teraz mam podozrenie skor na hw problem - ale mozno tomu debianu dam sancu :))
Kdysi mel linux kernel problem v tim, ze presne nebylo jasny co znamena, ze data byla zapsana na disk. V nekterych pripadech byla data povazovana za zapsana i v pripade, ze je pouze prijala hw cache primo na disku. Zajimavy na tom bylo, ze tahle chyba vadila nekterym zurnalovacim systemum vice a jinym mene. Pokud se dobre pamatuju, tak se dlouho hledala chyba v XFS. Mozna ze mas podobny problem - zkus hledat mezi parametry hdparmu, taky je mozny, ze ten tvuj USB ramecek proste nektery ATA commandy nepropousti.
no, tak teraz som zapol stroj po uspani a snad prvykrat neprebehol fsck s tym ze teda volam pred uspanim ten horeuvedeny "dd
prikaz", vdaka comu sa zrejme vyprazdnila cache...
uvidim, ci to bude robit aj nabuduce - predpokladam ale, ze toto bude ten problem.. holt je ten USB ramcek blby :)
Tiskni Sdílej: