PSF (Python Software Foundation) po mnoha měsících práce získala grant ve výši 1,5 milionu dolarů od americké vládní NSF (National Science Foundation) v rámci programu "Bezpečnost, ochrana a soukromí open source ekosystémů" na zvýšení bezpečnosti Pythonu a PyPI. PSF ale nesouhlasí s předloženou podmínkou grantu, že během trvání finanční podpory nebude žádným způsobem podporovat diverzitu, rovnost a inkluzi (DEI). PSF má diverzitu přímo ve svém poslání (Mission) a proto grant odmítla.
Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Od 3. listopadu 2025 budou muset nová rozšíření Firefoxu specifikovat, zda shromažďují nebo sdílejí osobní údaje. Po všech rozšířeních to bude vyžadováno někdy v první polovině roku 2026. Tyto informace se zobrazí uživateli, když začne instalovat rozšíření, spolu s veškerými oprávněními, která rozšíření požaduje.
Jste nuceni pracovat s Linuxem? Chybí vám pohodlí, které vám poskytoval Microsoft, když vás špehoval a sledoval všechno, co děláte? Nebojte se. Recall for Linux vám vrátí všechny skvělé funkce Windows Recall, které vám chyběly.
Společnost Fre(i)e Software oznámila, že má budget na práci na Debianu pro tablety s cílem jeho vyžívání pro vzdělávací účely. Jako uživatelské prostředí bude použito Lomiri.
Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Byl publikován říjnový přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Pracuje se na podpoře M3. Zanedlouho vyjde Fedora Asahi Remix 43. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Iniciativa Open Device Partnership (ODP) nedávno představila projekt Patina. Jedná se o implementaci UEFI firmwaru v Rustu. Vývoj probíhá na GitHubu. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0. Nejnovější verze Patiny je 13.0.0.
Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.
Typst byl vydán ve verzi 0.14. Jedná se o rozšiřitelný značkovací jazyk a překladač pro vytváření dokumentů včetně odborných textů s matematickými vzorci, diagramy či bibliografií.
To je na delší povídání, v podstatě jde o to že uživatel bude muset ten hash opsat z webu do mobilu, takže dlouhý hash nebude zrovna to pravé. Napadlo mě jedno řešení - vzít třeba jenom prvních x cifer z MD5 hashe, to by snad mělo stačit...
Jinak souhlasím, že je lepší ptát se na původní problém, normálně bych to udělal, teď ale dělám na progamu pro jednu firmu a nemůžu mluvit o tom co přesně dělám.
Tak jsem ti něco malýho napsal, protože jsem se nudil. Koukni na to. Jinak by to měl bejt jednosměrnej algoritmus (neměla by se dát napsát funkce, která z čísla udělá string).
public static double getHash(String s, int lenght) {
Double tmp = new Double(0);
for (int i = 0; i < s.length(); ++i) {
char c = s.charAt(i);
int j = (int) c;
tmp += j;
}
while (tmp < Math.pow(10, lenght - 1) || tmp > Math.pow(10, lenght)) {
if (tmp >= Math.pow(10, lenght)) {
//System.out.println("vetší než " + Math.pow(10, lenght));
double zbytek = tmp % 2;
tmp = ((tmp / 2) + zbytek)- (zbytek / 2);
}
if (tmp < Math.pow(10, lenght-1)) {
//System.out.println("menší než " + Math.pow(10, lenght-1));
tmp = tmp * 2;
}
}
return tmp;
}
No tohle je myslim tak trochu odstrasujici priklad, jak podobnou vec neimplementovat
Je to čístě nástřel. Zajímala by mne vaše implementace, když tahle je odstrašující.
Proc je napriklad promenna tmp Double a ne double?
S tim Double máte pravdu, to jsem tam nechal omylem (předtím jsem to tam měl úmyslně).
Proc ten hash neni celociselny?
Hash je celočíselný, ale typu double. Snad napsat return (int)tmp; a přepsat předpis metody dotazující zvládne.
Jenom teď ještě řeším,že pro podobné stringy to hází dost podobné hashe. Ještě pošlu druhou verzi, kde bude tohle ošetřeno.
public static int getHash(String s, int lenght) {
int usedLenght = lenght + 1;
double tmp = 0;
for (int i = 0; i < s.length(); ++i) {
char c = s.charAt(i);
int j = (int) c;
tmp += j;
}
tmp = Math.abs(Integer.reverse((int)tmp));
while (tmp < Math.pow(10, usedLenght - 1) || tmp > Math.pow(10, usedLenght)) {
if (tmp >= Math.pow(10, usedLenght)) {
int zbytek = (int)(tmp % 2);
tmp = ((tmp / 2) + zbytek) - (zbytek / 2);
}
if (tmp < Math.pow(10, usedLenght - 1)) {
tmp = tmp * 2;
}
}
return (int) (tmp / 10.0);
}
Proc vymyslet kolo.
Na 100% souhlasim. Já tu metodu vymýšlim čístě ze zvědavosti.
prehozeni pismen vedlo na ruzny haskod, coz trivialni scitani znaku nesplnuje
Po malé úpravě (viz. příloha) splňuje. Ale trochu se stydím, že mě to nenapdalo hned (a hlavně samo od sebe).
Realizovat celociselne operace v typech s plovouci carkou samozrejme ciste technicky lze (dokud nejsou cisla moc velka), ja to ale povazuji za spatny programatorsky postup, protoze to neni logicke.
Javu se teprve učím. Normálně programuji v jazycích kde se datové typy moc neřeší (hlavně PHP). Upravil jsem metodu, aby celou dobu pracovala s celočíselnými datovým typem. Takhle vám to příjde logicky správné už ?
podivej se treba, jak se pocita hashcode pro tridu String, zdrojaky jsou napriklad pro Sun implementaci k dispozici
Kouknul jsem, implementoval jsem sám ze zvědavosti. Má to však pro zadání (pevná délka a asi by autor chtěl pouze kladná čísla) nějáké mouchy.
Jinak děkuji za poznámky. Rád se něco přiučím.
Jen pro srovnání, jsem změřil NetBeans profilerem rychlosti všech tří hashů (můj originální - getHash, moje implementace hashCode - hashCode a originální hashCode - origHashCode). Výsledky jsem přiložil jako obrázek.
public static long getHash(String s, int lenght) {
int usedLenght = lenght + 1;
long tmp = 0;
for (int i = 0; i < s.length(); ++i) {
char c = s.charAt(i);
int j = (int) c;
tmp += (j*(i+1));
}
tmp = Math.abs(Integer.reverse((int)tmp));
while (tmp < Math.pow(10, usedLenght - 1) || tmp > Math.pow(10, usedLenght)) {
if (tmp >= Math.pow(10, usedLenght)) {
int zbytek = (int)(tmp % 2);
tmp = ((tmp / 2) + zbytek) - (zbytek / 2);
}
if (tmp < Math.pow(10, usedLenght - 1)) {
tmp = tmp * 2;
}
}
return (tmp / 10);
}
public static int hashCode(String s) {
int hash = 0;
for(int i =0; i < s.length(); i++) {
hash = hash + s.charAt(i) * (int)Math.pow(31, s.length() - (i + 1));
}
return hash;
}
tmp = ((tmp / 2) + zbytek) - (zbytek / 2);
Máte uplnou pravdu, je to zbytečné. Teď to opravdu postrádá smysl. Kód jsem opravil. V podstatě jsem došel sám ke stejnému výpočtu, jako je originální javovský String.hashCode. Rozdíl je skoro jen v tom, že já používám:
hash += s.charAt(i)*(i+1);
a originál Sun metoda hashCode:
hash += s.charAt(i) * (int)Math.pow(31, lenght - (i + 1));
Long.reverse() nechápu vůbec. Váš algoritmus se od algoritmu použitého v Javě dost podstatně liší – ovšem je pravda, že ty algoritmy jsou co do míry hashování srovnatelné. Myslím, že pro oba dva nebude problém napsat inverzní funkci (která vrátí některý z možných vstupů), implementace String.hashCode() ve skutečnosti hashuje jenom podle pravých 7 znaků, další znaky se k hashi prakticky jen přičtou (takže u ASCII textu se osmý a další znak zprava promítnou jen do dolních 7 bitů hashe).
Pokud to celé má sloužit jako bezpečnostní kód, použil bych nějakou prověřenou hashovací funkci (SHA nebo klidně i MD5), výsledek bych rozdělil na skupiny bitů požadované délky a z těch bych XORováním udělal jednu skupinu požadované délky.
Tiskni
Sdílej: