Do prodeje jde tichá bezdrátová herní myš Logitech PRO X2 SUPERSTRIKE s analogovými spínači s haptickou odezvou (HITS, Haptic Inductive Trigger System). Cena je 4 459 Kč.
Microsoft na GitHubu zveřejnil zdrojový kód projektu LiteBox, jedná se o 'knihovní operační systém' (library OS) zaměřený na bezpečnost, využívající systémovou architekturu LVBS k ochraně jádra před útoky z uživatelského prostoru. LiteBox je napsán v Rustu a uvolněný pod licencí MIT. Projekt je teprve v rané fázi vývoje.
BreezyBox je open-source shell a virtuální terminál pro populární jednočip ESP32. Nabízí základní unixové příkazy, sledování aktuálního pracovního adresáře (CWD), jednoduchý instalátor a spouštěč aplikací v podobě ELF binárních souborů, zabudovaný HTTP server nebo třeba ovládání WiFi - ukázka použití coby 'malého osobního počítače'. Ačkoliv je BreezyBox inspirovaný BusyBoxem, oproti němu má tento projekt několik externích závislostí, zejména na ESP-IDF SDK. BreezyBox je dostupný pod licencí MIT.
Byl představen cross-assembler xa.sh, napsaný čistě v Bourne shell skriptu. Tento nástroj umožňuje zpracovávat assemblerový kód pro Intel 8080, přičemž je možné snadno přidat podporu i pro další architektury, například 6502 a 6809. Skript využívá pouze různé běžné unixové příkazy jako jsou awk, sed nebo printf. Skript si lze stáhnout z GitHubového repozitáře projektu.
Byla představena nová verze modelu Claude Opus 4.6 od společnosti Anthropic. Jako demonstraci možností Anthropic využil 16 agentů Claude Opus 4.6 k vytvoření kompilátoru jazyka C, napsaného v programovacím jazyce Rust. Claude pracoval téměř autonomně, projekt trval zhruba dva týdny a náklady činily přibližně 20 000 dolarů. Výsledkem je fungující kompilátor o 100 000 řádcích kódu, jehož zdrojový kód je volně dostupný na GitHubu pod licencí Creative Commons.
Kultovní britský seriál The IT Crowd (Ajťáci) oslavil dvacáté výročí svého prvního vysílání. Sitcom o dvou sociálně nemotorných pracovnících a jejich nadřízené zaujal diváky svým humorem a ikonickými hláškami. Seriál, který debutoval v roce 2006, si i po dvou dekádách udržuje silnou fanouškovskou základnu a pravidelně se objevuje v seznamech nejlepších komedií své doby. Nedávné zatčení autora seriálu Grahama Linehana za hatecrime však vyvolává otázku, jestli by tento sitcom v současné Velké Británii vůbec vznikl.
Společnost JetBrains oznámila, že počínaje verzí 2026.1 budou IDE založená na IntelliJ ve výchozím nastavení používat Wayland.
Společnost SpaceX amerického miliardáře Elona Muska podala žádost o vypuštění jednoho milionu satelitů na oběžnou dráhu kolem Země, odkud by pomohly zajistit provoz umělé inteligence (AI) a zároveň šetřily pozemské zdroje. Zatím se ale neví, kdy by se tak mělo stát. V žádosti Federální komisi pro spoje (FCC) se píše, že orbitální datová centra jsou nejúspornějším a energeticky nejúčinnějším způsobem, jak uspokojit rostoucí poptávku po
… více »Byla vydána nová verze 2.53.0 distribuovaného systému správy verzí Git. Přispělo 70 vývojářů, z toho 21 nových. Přehled novinek v poznámkách k vydání.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 216. sraz, který proběhne v pátek 20. února od 18:00 v Red Hat Labu (místnost Q304) na Fakultě informačních technologií VUT v Brně na ulici Božetěchova 1/2. Tématem srazu bude komunitní komunikační síť MeshCore. Jindřich Skácel představí, co je to MeshCore, předvede nejrůznější klientské zařízení a ukáže, jak v praxi vypadá nasazení vlastního repeateru.
Dělám RPM balíček pro svůj program SQL-DK a nevím, jak deklarovat závislosti na JVM. Program potřebuje Javu 7 nebo Javu 8 (případně vyšší, až bude). Nechci vynucovat konkrétní verzi. Stejně jako třeba v Debianu i ve Fedoře to jsou různé balíky, ne jeden v různých verzích (což má výhodu, že člověk může mít nainstalované oba).
Někde jsem se dočetl, že RPM neumí (platí to ještě?) alternativy v závislostech a mají se místo toho použít virtuální balíky.
U .deb balíčku můžu deklarovat závislost:
Depends: java7-runtime | java8-runtime
U .rpm tedy použiji virtuální balík – jenže když tam dám:
Requires: java >= 1:1.7.0
tak to ve Fedoře 20 chce instalovat 7 a nespokojí se to s 8, která už je nainstalovaná.
Takže jsem závislost ze .spec souboru zatím vyhodil úplně a je potřeba ji ohlídat ručně. Jak tam můžu dostat to „nebo“ do závislostí?
Tohle by fungovalo ve Fedoře 21, ale ne v F20, kde balík java-1.8.0-openjdk místo "java" poskytuje "java8" (vizRequires: java >= 1:1.7.0tak to ve Fedoře 20 chce instalovat 7 a nespokojí se to s 8, která už je nainstalovaná.
rpm -q --provides java-1.8.0-openjdk). Myslím, že to tak bylo schválně, protože v době vydání F20 ještě Java 8 nebyla hotová.
Zkusil bych to obejít vlastními virtuálními podbalíčky zhruba takto:
Name: sql-dk
Requires: sql-dk-java = %{version}
...
%package java7
Requires: java >= 1:1.7.0
Provides: sql-dk-java = %{version}
%package java8
Requires: java8 >= 1:1.8.0
Provides: sql-dk-java = %{version}
Díky, trochu to pomohlo, ale pořád to není ono.
Upravil jsem .spec soubor:
Name: sql-dk
Summary: SQL batch client
Group: Applications/Databases
BuildArch: noarch
Version: 0.10
Release: 3
License: GNU GPLv3+
URL: https://sql-dk.globalcode.info/
Requires: sql-dk-java = %{version}
# --- Dependencies -----------------------------------------------------------
%package java7
Summary: Java 7
Group: Development/Languages
Requires: java >= 1:1.7.0
Provides: sql-dk-java = %{version}
%description java7
virtual package for dependency on Java 7
%package java8
Summary: Java 8
Group: Development/Languages
Requires: java8 >= 1:1.8.0
Provides: sql-dk-java = %{version}
%description java8
virtual package for dependency on Java 8
# ----------------------------------------------------------------------------
%description
SQL-DK is a command-line client for relational databases.
%prep
mkdir -p ${RPM_BUILD_ROOT}/usr/bin/
mkdir -p ${RPM_BUILD_ROOT}/usr/share/sql-dk/
mkdir -p ${RPM_BUILD_ROOT}/usr/share/doc/sql-dk/
mkdir -p ${RPM_BUILD_ROOT}/etc/bash_completion.d/
cp ../../../../scripts/sql-dk.sh ${RPM_BUILD_ROOT}/usr/bin/sql-dk
cp ../../../../xml/config.xsd ${RPM_BUILD_ROOT}/usr/share/doc/sql-dk/
cp ../../../../xml/config.rnc ${RPM_BUILD_ROOT}/usr/share/doc/sql-dk/
cp ../../../../xml/config.xsl ${RPM_BUILD_ROOT}/usr/share/doc/sql-dk/
cp ../../../../java/sql-dk/dist/sql-dk.jar ${RPM_BUILD_ROOT}/usr/share/sql-dk/
cp ../../../../java/jdbc-loopback-driver/dist/jdbc-loopback-driver.jar ${RPM_BUILD_ROOT}/usr/share/sql-dk/
cp ../../../../java/sql-dk/dist/bash-completion.sh ${RPM_BUILD_ROOT}/etc/bash_completion.d/sql-dk
%files
%defattr(-,root,root)
/usr/bin/*
/usr/share/sql-dk/*
/usr/share/doc/sql-dk/*
/etc/bash_completion.d/*
Ale při pokusu o instalaci dostávám chybu:
# rpm -i sql-dk-0.10-2.noarch.rpm
chyba: Selhalé závislosti:
sql-dk-java = 0.10 je potřeba pro sql-dk-0.10-2.noarch
Když ve .spec nemám žádné soubory u pod-balíčků, tak se tyto balíčky ani nesestaví a nemůžu je nainstalovat.
Když do java7 a java8 nějaký soubor dám, tak se balíček sestaví a můžu ho nainstalovat, ale přijde mi to strašně krkolomné – uživatel by se musel rozmyslet, jakou verzi Javy používá, pak podle toho nainstalovat sql-dk-java7-0.10-3.noarch.rpm nebo sql-dk-java8-0.10-3.noarch.rpm a pak sql-dk-0.10-3.noarch.rpm, který už bude mít splněné závislosti. Jenže to si rovnou může ručně nainstalovat java-1.7.0-openjdk nebo java-1.8.0-openjdk místo těch mých balíčků. Navíc bych musel šířit tři .rpm soubory místo jednoho.
Rád bych, aby stačilo napsat:
rpm -i sql-dk-0.10-3.noarch.rpm
a jen se zkontrolovalo, že je nainstalovaná Java 7 nebo 8. Případně aby yum doinstaloval závislosti (nejnovější dostupnou Javu).
Když ve .spec nemám žádné soubory u pod-balíčků, tak se tyto balíčky ani nesestaví a nemůžu je nainstalovat.Soubory v nich mít nemusíš, ale musíš u nich uvést %files sekci, klidně prázdnou.
[...] Navíc bych musel šířit tři .rpm soubory místo jednoho.Ano, šířit jednotlivé soubory je krkolomné. Vyrob z nich repo (viz
createrepo).
Jakmile yum bude o tom repozitáři vědět, pak při pokusu o nainstalování sql-dk už si se závislostmi nějak poradí. Vzhledem k tomu, jak si yum vybírá mezi alternativními poskytovateli Provides, měl by preferovat již nainstalovanou verzi Javy.
/usr/bin/java, ale to taky nefunguje.
Pro Bash by to šlo:
# rpm -q --file /bin/bash bash-4.2.48-2.fc20.x86_64Ale pro Javu ne:
# rpm -q --file /usr/bin/java soubor /usr/bin/java nevlastní žádný balíček
Require: java? (predpokladám, že Fedora 20 podporuje len java 1.7+)
Potíž je v tom, že java-1.8.0-openjdk-1.8.0.11-9.b12.fc20.x86_64 neposkytuje balíček java, ale java8:
# rpm -q --whatprovides java java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.x86_64 # rpm -q --whatprovides java-headless java-1.7.0-openjdk-headless-1.7.0.65-2.5.2.5.fc20.x86_64
Takže by to vyžadovalo 7 a já chci, aby to chodilo i lidem, kteří mají jen 8.
BTW: stejným problémem trpí třeba JDBC ovladače ve Fedoře 20:
# rpm -q --requires postgresql-jdbc java jpackage-utils jpackage-utils rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1
Taky jim nebude stačit 8 a musí se kvůli nim nainstalovat 7.
Ale hlavně je mi divné, že by RPM neumělo nijak vyjádřit: „balíček X vyžaduje Y nebo Z“.
Bohužel RPM stále neumí disjunkci uvnitř jednoho balíku. Ale prý se na tom pracuje :(
Pokud jde o balení javových věcí, silně doporučuji přečíst si dokumentaci Java Packaging Guidelines. Případně omáčku jako Java Packaging HOWTO. Případné dotazy směřujte do mailing listu Java SIG.
Pokud Fedora 20 nepodporuje JDK 1.8, tak to neohýbejte násilím. Určitě je pro to dobrý důvod.
Pokud jde o balení javových věcí, silně doporučuji přečíst si dokumentaci Java Packaging Guidelines.
Na to jsem koukal. Tyhle balíčky jsou zatím provizorní/neoficiální. I ty .deb musím předělat. Teď šlo jen o to, aby to bylo možné ručně nainstalovat/odinstalovat/upgradovat. Ale chci to dostat do distribucí, takže to podle těch pravidel musím upravit – původní plán totiž byl, že se nejdřív zkompilují JARy a další věci a pak se ten proces teprve rozvětví – zabalí se tytéž soubory několikrát, pro různé distribuce. Ale asi budu muset kompilovat .class/.jar soubory pro každou distribuci znova.
Pokud Fedora 20 nepodporuje JDK 1.8, tak to neohýbejte násilím. Určitě je pro to dobrý důvod.
Balíčky pro Javu 8 tam jsou a není důvod, proč by moje aplikace s Javou 8 neměla fungovat → tudíž jsem nechtěl nutit nikoho k instalaci 7, když už má 8. Ale potíž je v tom, že když bude chtít třeba JDBC ovladače, tak ho to k instalaci 7 stejně donutí, protože ty deklarují závislost na 7 resp. na balíčku, který v současnosti poskytuje jen 7. Takže bych se na to asi taky mohl vykašlat a počkat na příští verzi Fedory, tam už snad půjde mít jen 8.
Ale asi budu muset kompilovat .class/.jar soubory pro každou distribuci znova.
Samozřejmě. Bezpečnostní tým by vás jinak roztrhl. Každá distribuce vyžaduje kompilaci ze zdrojáků, aby mohla patchovat. Říká se tomu svobodný software.
Balíčky pro Javu 8 tam jsou a není důvod, proč by moje aplikace s Javou 8 neměla fungovat → tudíž jsem nechtěl nutit nikoho k instalaci 7, když už má 8. Ale potíž je v tom, že když bude chtít třeba JDBC ovladače, tak ho to k instalaci 7 stejně donutí, protože ty deklarují závislost na 7 resp. na balíčku, který v současnosti poskytuje jen 7.
Buďto java-1.8.0-openjdk neposkytuje RPM symboly java a java-headless pouze nedopatřením, nebo v tom je nějaký záměr. Za dotaz do mailing listu nebo hlášení do bugzilly vám nikdo hlavu neutrhne. (Například RHEL-6.5: java-1.7.0-openjdk provides changed from java7 to java.)
Z hlediska správy balíčků to není váš problém. Když se budete držet guidelines, tak budete mít balík, u kterého je víceméně zaručeno, že bude fungovat.
Mimochodem pro sestavení neoficiálních binárních RPM balíků mužete použít systém Copr.
Tiskni
Sdílej: