Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Nejde k enumeraci zařízení použít taky udev s vyhledáváním podle major a minor čísel? Já pro enumeraci sériových portů v PC používám tenhle kód:
{ QStringList ret; struct udev * udev = udev_new(); if(udev == NULL) { qCritical() << "udev_new() failed"; return ret; } for(quint8 minor = 64; minor <= 255; ++minor) { struct udev_device * udev_device = udev_device_new_from_devnum(udev, 'c', makedev(4, minor)); if(udev_device != NULL) { ret.append(udev_device_get_devnode(udev_device)); udev_device_unref(udev_device); } else break; } udev_unref(udev); return ret; }
Seznam a vysvětlení major čísel je v dokumentaci kernelu.
Požádám udev o přeložení major:minor na soubor se zařízením (např. /dev/sr0)Tím jsem měl na mysli právě použitím udev_device_new_from_devnum
It is in the process of being merged into udev (main udev, libudev, and udev-extras) and existing udev and kernel functionality. Initially a new daemon DeviceKit was planned to replace certain aspects of HAL, but in March 2009, DeviceKit was deprecated in favor of adding the same code to udev as a package: udev-extras, and some functions have now moved to udev proper.
udisks
According to DeviceKit devel mailing list, DeviceKit is getting merged with udev-extra and the existing DeviceKit programs such as DeviceKit-disks and DeviceKit-power will be switched over to use libudev.Takže by bylo fajn se začít poohlížet jak se vlastně vůbec pracuje s libudev. Jinak by ale na toto měl snad mít Qt svoje serepetičky, ne?
void bla() { struct udev_enumerate* enumerate = udev_enumerate_new(_udev); if (!enumerate) return; udev_enumerate_add_match_subsystem(enumerate, "block"); if (udev_enumerate_scan_devices(enumerate) == 0) { struct udev_list_entry *e; const char *syspath, *prop; struct udev_device *dev, *parent_dev; e = udev_enumerate_get_list_entry(enumerate); while (e) { syspath = udev_list_entry_get_name(e); dev = udev_device_new_from_syspath(_udev, syspath); if (dev) { prop = udev_device_get_property_value(dev, "ID_TYPE"); if (prop && strcmp(prop, "cd") == 0) { qDebug() << "Found CD-ROM device" << udev_device_get_devnode(dev); //printAttrs(dev); } udev_device_unref(dev); } e = udev_list_entry_get_next(e); } } udev_enumerate_unref(enumerate); }Snad se to nějak dá do kupy. Ale mě by spíše potěšilo, aby se ta CD-ROMka dala zamknout pro exkluzivní přístup nezávisle na typu zařízení, přes které se přistupuje.
Problém ale bude určitě v tom, že distribucím bude dost dlouho trvat, než nový model přijmou. Například Arch stále ještě jede na HALu. Nebo prostě bude někdo mít nainstalovanou starší verzi nějaké konzervativní ditribuce s HALem, a bude problém...Tak ten program nebudu vydávat zítra. Než to dám do nějakého použitelného stavu, aby se kvůli každé operaci nemusel rekompilovat zdroják (
Jó no, ona to fakt taková hrůza neníBer to z té pozitivní stránky. Zas se nemusíš drbat s komunikací pomocí DBUSu.
Ale mě by spíše potěšilo, aby se ta CD-ROMka dala zamknout pro exkluzivní přístup nezávisle na typu zařízení, přes které se přistupuje.Tak flock(2) to nebere. Ale jak jsem řekl. Inspiruj se u konkurence. Tady nejsi ve Widlích, ale na otevřené platformě. Co jsem se tak zběžně díval do cdrecord, tak si první autor udělá v paměti buffer a ten si všelijak pozamyká s následujícím komentářem:
/* * Try to lock us im memory (will only work for root) * but you need access to root anyway to send SCSI commands. * We need to be root to open /dev/scg? or similar devices * on other OS variants and we need to be root to be able * to send SCSI commands at least on AIX and * Solaris (USCSI only) regardless of the permissions for * opening files * * XXX The folowing test used to be * XXX #if defined(HAVE_MLOCKALL) || defined(_POSIX_MEMLOCK) * XXX but the definition for _POSIX_MEMLOCK did change during * XXX the last 8 years and the autoconf test is better for * XXX the static case. sysconf() only makes sense if we like * XXX to check dynamically. */, kde když se zámek nepovede, tak: errmsgno(EX_BAD, "WARNING: This causes a high risk for buffer underruns.\n"); a pak se na tu zamknutou paměť snaží připojit (fs = init_fifo(fs); /* Attach shared memory (still one process) */) a následně nějak propojit s nějakou scg což vypadá na knihovnu, viz komentář:
/* * Call scg_remote() to force loading the remote SCSI transport library * code that is located in librscg instead of the dummy remote routines * that are located inside libscg. */A IMHO je za dostání do stavu kdy jednotka nebude komunikovat s ničím jiným je zodpovědná právě ta knihovna nebo ta komunikace skrze SCSI příkazy. Jinak celý proces vypalování vypadá opravdu dost brutálně, takže pokud sis myslel, že to bude jen otevření blokového zařízení, uzamknutí přístupu pro exkluzivní přístup a pár writů, tak ses IMHO docela zmýlil.
PREVENT/ALLOW MEDIUM REMOVAL - zamknu eject mechanismus TEST UNIT READY - test jestli je tam médium a jestli je jednotka ready GET CONFIGURATION - získání aktuálního profilu (podle profilu se určí typ vloženého média (u příkladu DVD+RW)) READ DISC INFORMATION - zkontroluju jestli je naformátováno SET STREAMING - nastavím rychlost pálení FORMAT UNIT - pokud není naformátováno, spustím background format série WRITE(10) popř. WRITE(12) - zapíšu data SYNCHRONIZE CACHE - flush (DVD+RW se nezavírá, nikdy) Pokud stále běží background format tak CLOSE TRACK/SESSION na ukončení formátování PREVENT/ALLOW MEDIUM REMOVAL - povolím ejectSnad jsem nic nezapomněl
Děláte WRITE a při tom se plní buffer a vypalovačka pálí. DVD+RW lze vypalovat "náhodně", není třeba sekvenční pálení, určíte si start sektor, počet sektorů, co pálíte a prostě pálíte. To samé platí o DVD-RAM a DVD-RW v Restricted overwrite módu (tj. naformátované). A pro zbytek ve write parameters mode page nastavíte BUFE bit (ochrana proti podtečení). Pokud nestíháte posílat WRITE a buffer palírny se vyprázdní, tak může dojít a) k průseru, b) provedení "linkingu".
Každopádně prostě vy děláte WRITE, vypalovačka si plní buffer daty, co jí posíláte a pálí. Data čtu v extra vlákně (SW buffer jsem pro zatím zvolil 64 MB, ale dneska asi nemá cenu šetřit, tak bych se nebál půl giga (vtip, samozřejmě půjde nastavit)).rozumíme si, že se nejedná o systémové volání write(), ale o SCSI příkaz WRITE(10), který posíláte přes ioctl(SG_IO) či write()?Aha, tak už jo.
posíláteMy? No my toho neposíláme.
My? No my toho neposíláme.sry
Tiskni
Sdílej: