Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Ze systému Slavia pojišťovny uniklo přibližně 150 gigabajtů citlivých dat. Jedná se například o pojistné dokumenty, lékařské záznamy nebo přímou komunikaci s klienty. Za únik může chyba dodavatelské společnosti.
Sněmovna propustila do dalšího kola projednávání vládní návrh zákona o digitální ekonomice, který má přinést bezpečnější on-line prostředí. Reaguje na evropské nařízení DSA o digitálních službách a upravuje třeba pravidla pro on-line tržiště nebo sociální sítě a má i víc chránit děti.
Meta převezme sociální síť pro umělou inteligenci (AI) Moltbook. Tvůrci Moltbooku – Matt Schlicht a Ben Parr – se díky dohodě stanou součástí Meta Superintelligence Labs (MSL). Meta MSL založila s cílem sjednotit své aktivity na poli AI a vyvinout takovou umělou inteligenci, která překoná lidské schopnosti v mnoha oblastech. Fungovat by měla ne jako centralizovaný nástroj, ale jako osobní asistent pro každého uživatele.
Byla vydána betaverze Fedora Linuxu 44 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 14. dubna.
Open source router Turris Omnia NG Wired je v prodeji. Jedná se o Turris Omnia NG bez Wi-Fi. Je připraven pro zamontování do racku.
Zdravim,
potreboval bych zporvoznit udev na embedded zarizeni bezici na kernelu verze 2.6.19.2. Zarizeni ma 2 USB porty, na ktere bych potreboval pripojit 2 USB gprs modemy. Problem je v tom, aby kazdy modem byl identifikovat podel pripojeni (port1 - zarizeni /dev/modem1, port2 - zarizen /dev/modem2). Pro tyto ucely jsem nastavil udev, pridal mu pravidla pro jednotlive modemy:
KERNELS=="1-1:1.0", SUBSYSTEM=="tty", SYMLINK+="modem1"
KERNELS=="1-2:1.0", SUBSYSTEM=="tty", SYMLINK+="modem2"
Udaje jsem opsal z vypisu udevinfo. Problem je, ze symlinky se nevytvori a dokonce udevtest na /class/tty/ttyACM0 nevypise nic, ze by provadel nejakou akci. Pokud do udev.rules pridama pravidlo:
KERNEL=="eth0", SYMLINK+="test_sit"
a spustim udevinfo /class/net/eth0 pak se vypise, ze by se vytvoril symlink test_sit, cili udev jako takovy funguje. Nemate nekdo tuseni, proc udev nefunguje na usb zarizeni, ale funguje na sit? Pripadne jak rozlisit 2 usb modemy podle toho, do jakeho portu jsou pripojeny?
KERNELS=="1-1:1.0" vs KERNEL=="1-1:1.0"?
Zkousel jsem i SUBSYSTEM=="usb", ale ani tak to nereagovalo. Nechapu, ze napr. pro sit to funguje, ale usb udev nejak odmita. Zkousel jsem vytvaret pravidla pro disk KERNEL=="hda1" (pripadne SUBSYSTEM=="block") a taky nic (i kdyz podle vypisu udevinfo by to melo byt spravne).
udevinfo vypisuje KERNELS, primo u zarizeni je KERNEL=="ttyACM0", ale z toho nejsem schopen rozpoznat, na ktery USB port je zarizeni propjeno. Prvnich nekolik zaznamu v udevinfo:
$ udevinfo -a -p /class/tty/ttyACM0
looking at device '/class/tty/ttyACM0':
KERNEL=="ttyACM0"
SUBSYSTEM=="tty"
DRIVER==""
ATTR{dev}=="166:0"
looking at parent device '/devices/pci0000:00/0000:00:0f.0/usb1/1-2/1-2:1.0':
KERNELS=="1-2:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="cdc_acm"
ATTRS{modalias}=="usb:v0681p0034d0000dc02dsc00dp00ic02isc02ip01"
ATTRS{bInterfaceProtocol}=="01"
ATTRS{bInterfaceSubClass}=="02"
ATTRS{bInterfaceClass}=="02"
ATTRS{bNumEndpoints}=="01"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}=="00"
looking at parent device '/devices/pci0000:00/0000:00:0f.0/usb1/1-2':
KERNELS=="1-2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{product}=="MC75"
ATTRS{manufacturer}=="Siemens AG Wireless Modules"
ATTRS{maxchild}=="0"
ATTRS{version}==" 1.10"
ATTRS{devnum}=="12"
ATTRS{speed}=="12"
ATTRS{bMaxPacketSize0}=="8"
ATTRS{bNumConfigurations}=="1"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceClass}=="02"
ATTRS{bcdDevice}=="0000"
ATTRS{idProduct}=="0034"
ATTRS{idVendor}=="0681"
ATTRS{bMaxPower}==" 0mA"
ATTRS{bmAttributes}=="e0"
ATTRS{bConfigurationValue}=="1"
ATTRS{bNumInterfaces}==" 2"
ATTRS{configuration}==""
....
# USB device by USB bus
KERNEL=="sd?1", KERNELS=="3-3", ATTRS{busnum}=="3", SYMLINK+="usb_left"
KERNEL=="sd?1", KERNELS=="7-2", ATTRS{busnum}=="7", SYMLINK+="usb_right_top"
KERNEL=="sd?1", KERNELS=="7-1", ATTRS{busnum}=="7", SYMLINK+="usb_right_bottom
myslím že to funguje dobře. Ale busnum u vás nevidím...? Očekával bych to tam co KERNELS=="1-2" :(
SUBSYSTEM=="usb", ATTRS{serial}=="nejakyserial", SYMLINK+="modem1"
Ještě bych se podíval, jestli někde v jiných udev pravidlech není použita podmínka last_rule pro tento typ zařízení, to by pak tvoje další pravidla nebyla brána v potaz. Hledej něco jako (například):
KERNEL=="ttyACM[0-9]*", GROUP="modem", OPTIONS+="last_rule"
No on momentalne hlavni problem je ten, ze se na usb zarizeni neaplikuje zadne pravidlo (ani bez serioveho cisla). Ani s pravidlem:
SUBSYSTEM=="usb", SYMLINK+="modem1"
(coz by podle me melo platit pro vsechna usb zarizeni) se neprovede nic.
Pravidla popsana v puvodnim prispevku jsou jedina, co tam jsou, jine soubory s pravidly tam nemam.
Možná hloupá otázka, ale není ten udev na embedded routeru třeba nějaký ořezaný?
On to neni router. Ten udev jsem tam kopiroval rucne a je dost mozne, ze jsem neco vynechal. Nakopiroval jsem binarky udevd, udevinfo, udevtest, udevtrigger, udevmonitor a udevcontrol + knihovny nutne pro spusteni techto programu. V adresari /etc/udev/rules.d/ jsem vytvoril soubor s pravidlama, v kernelu je podpora pro sysfs, ktery se po nabootovani primountuje do /sys. Nevim, jestli nejsou pri prekladu kernelu nejake volby, ktere by mely zasadni vliv na funkci udev (krome hotplug).
Adresar /lib/udev tam mam, obsah je nasledujici:
-rwxr-xr-x 1 root root 7684 Apr 21 11:29 ata_id
-rwxr-xr-x 1 root root 7140 Apr 21 11:29 cdrom_id
-rwxr-xr-x 1 root root 499 Apr 21 11:29 check_driver
drwxr-xr-x 2 root root 1024 Apr 21 11:29 devices
-rwxr-xr-x 1 root root 9012 Apr 21 11:29 edd_id
-rwxr-xr-x 1 root root 496 Apr 21 11:29 firmware.agent
-rw-r--r-- 1 root root 3105 Apr 21 11:29 hotplug.functions
-rwxr-xr-x 1 root root 1259 Apr 21 11:29 ide-devfs.sh
-rwxr-xr-x 1 root root 688 Apr 21 11:29 ide.agent
-rwxr-xr-x 1 root root 614 Apr 21 11:29 logger.agent
-rwxr-xr-x 1 root root 2042 Apr 21 11:29 net.agent
-rwxr-xr-x 1 root root 11717 Apr 21 11:29 path_id
-rwxr-xr-x 1 root root 1298 Apr 21 11:29 raid-devfs.sh
-rwxr-xr-x 1 root root 1576 Apr 21 11:29 scsi-devfs.sh
-rwxr-xr-x 1 root root 559 Apr 21 11:29 scsi-re-add
-rwxr-xr-x 1 root root 20156 Apr 21 11:29 scsi_id
-rwxr-xr-x 1 root root 7412 Apr 21 11:29 udev_run_devd
-rwxr-xr-x 1 root root 7280 Apr 21 11:29 udev_run_hotplugd
-rwxr-xr-x 1 root root 13912 Apr 21 11:29 usb_id
-rwxr-xr-x 1 root root 14036 Apr 21 11:29 vol_id
-rwxr-xr-x 1 root root 2784 Apr 21 11:29 write_cd_rules
-rwxr-xr-x 1 root root 3477 Apr 21 11:29 write_net_rules
Tiskni
Sdílej: