Byla vydána nová verze 10.0 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Vypíchnout lze nové balíčky ownCloud Infinite Scale a Uptime-Kuma.
Byla vydána nová verze 3.0.8 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Microsoft poskytl FBI uživatelské šifrovací klíče svého nástroje BitLocker, nutné pro odemčení dat uložených na discích třech počítačů zabavených v rámci federálního vyšetřování. Tento krok je prvním známým případem, kdy Microsoft poskytl klíče BitLockeru orgánům činným v trestním řízení. BitLocker je nástroj pro šifrování celého disku, který je ve Windows defaultně zapnutý. Tato technologie by správně měla bránit komukoli kromě
… více »Spotify prostřednictvím svého FOSS fondu rozdělilo 70 000 eur mezi tři open source projekty: FFmpeg obdržel 30 000 eur, Mock Service Worker (MSW) obdržel 15 000 eur a Xiph.Org Foundation obdržela 25 000 eur.
Nazdar! je open source počítačová hra běžící také na Linuxu. Zdrojové kódy jsou k dispozici na GitHubu. Autorem je Michal Škoula.
Po více než třech letech od vydání verze 1.4.0 byla vydána nová verze 1.5.0 správce balíčků GNU Guix a na něm postavené stejnojmenné distribuci GNU Guix. S init systémem a správcem služeb GNU Shepherd. S experimentální podporou jádra GNU Hurd. Na vývoji se podílelo 744 vývojářů. Přibylo 12 525 nových balíčků. Jejich aktuální počet je 30 011. Aktualizována byla také dokumentace.
Na adrese gravit.huan.cz se objevila prezentace minimalistického redakčního systému GravIT. CMS je napsaný ve FastAPI a charakterizuje se především rychlým načítáním a jednoduchým ukládáním obsahu do textových souborů se syntaxí Markdown a YAML místo klasické databáze. GravIT cílí na uživatele, kteří preferují CMS s nízkými nároky, snadným verzováním (např. přes Git) a možností jednoduchého rozšiřování pomocí modulů. Redakční
… více »Tým Qwen (Alibaba Cloud) uvolnil jako open-source své modely Qwen3‑TTS pro převádění textu na řeč. Sada obsahuje modely VoiceDesign (tvorba hlasu dle popisu), CustomVoice (stylizace) a Base (klonování hlasu). Modely podporují syntézu deseti různých jazyků (čeština a slovenština chybí). Stránka projektu na GitHubu, natrénované modely jsou dostupné na Hugging Face. Distribuováno pod licencí Apache‑2.0.
Svobodný citační manažer Zotero (Wikipedie, GitHub) byl vydán v nové major verzi 8. Přehled novinek v příspěvku na blogu.
Ha, díky za nápad - dala by se na tom testovat rychlost komprimace/dekomprimace. Rozhodně jestli se mi to povede vygenerovat, tak zkusim LZMA kompresi a někam to uploadnout. Zatim jsem "jen" na 39.113.249.255 
Narazil jsem už na pár programů, které neukončený poslední řádek považovaly za chybný, nebo ho ani nedokázaly načíst...
'\n'.
wc -l
jinak by poslední (prázdný) řádek nesplňoval požadavkyto zalezi jestli newline character povazujes za oddelovac nebo ukoncovac radku. Pokud za ukoncovac tak tam prazdny radek neni, i kdyz ho nektery editory zobrazi...
There is also some confusion whether newlines terminate or separate lines. If a newline is considered a separator, there will be no newline after the last line of a file. The general convention on most systems is to add a newline even after the last line, i.e. to treat newline as a line terminator. Some programs have problems processing the last line of a file if it is not newline terminated. Conversely, programs that expect newline to be used as a separator will interpret a final newline as starting a new (empty) line.zdroj: http://en.wikipedia.org/wiki/Newline
\n není oddělovač, nýbrž ukončovač řádku.
Také by se to dalo říct tak, že každá položka v souboru je oddělená ukončením řádkuŘíct se to sice dá, dokonce i napsat, po striktní logice dokonce dojdeš k tomu, že je to pravdivý výrok (pokud je každá položka na samostatném řádku), ale přesto je nesmysl se podle toho řídit.
Ano, řádky mají být odddělené, takže poslední řádek je oddělený od konce souboru.
if je zbytečný – když máš metodu/funkci načtiDalšíŘádek(), tak v ní prostě čteš vstup, dokud nenarazíš na konec řádku nebo* souboru a načtenou hodnotu vrátíš. Takže z tohoto pohledu (načítání souboru, kde položka = řádek) je úplně jedno, jestli tam to poslední \n je nebo ne. (význam to má akorát při spojování souborů nebo při výpisu do konsole…)
*) je jasné, že za koncem souboru už řádek nepokračuje, takže vrátíme hodnotu. Kdybychom chtěli být zlí, tak vyhodíme výjimku, že je řádek v neplatné syntaxi (není ukončen \n), ale to by asi k ničemu dobré nebylo.
Zaujímalo by ma ako na tom bola ramka počas vytvárania súboru.
já moc ne.
unsigned long i;
for (i=0; i<2^32; i++) {
sprintf("%i.%i.%i.%i",(*i & 0xff000000)>>24,(*i & 0x00ff0000)>>16,(*i & 0x0000ff00)>>8,(*i & 0x000000ff));
}
XOR
uint32_t i = UINT32_C(0xffeeffee);
printf("%" PRIu32 "\n", i);
tohle jsem někde našel a upravil, snažil jsem se to pochopit... mé znalosti končí u PHP, čímž jsem značně deformován
#include <stdint.h>
#include <stdio.h>
int main()
{
uint32_t ip = 0;
do
{
printf("%u.%u.%u.%u\n", (uint8_t)(ip >> 24), (uint8_t)(ip >> 16), (uint8_t)(ip >> 8), (uint8_t)ip);
}
while (++ip <= 0xffffffff);
}
Ale nemám dost místa na disku na to abych to odzkoušel
Určitě je to správně? Gynerovaný soubor má už 63GB a pořát jede, zdá se, odzačátku .. :D
poky@antik:~$ time ./c > ips
Ukončen (SIGTERM)
real 28m31.981s
user 25m41.980s
sys 1m38.766s
poky@antik:~$ du ips
69162400 ips
poky@antik:~$ du -h ips
66G ips
poky@antik:~$ wc -l ips
4998991943 ips
poky@antik:~$
Taky jsem si ten kód mohl nejdřív pořádně pročíst...
int main(void)
{
int i,j,k,l;
long long int x=0;
char ip[20];
for (i=0;i<POCET;++i)
{
printf("%03d\n",i);
for (j=0;j<POCET;++j)
for (k=0;k<POCET;++k)
for (l=0;l<POCET;++l)
{
sprintf(ip,"%d.%d.%d.%d\n",i,j,k,l);
x+=strlen(ip);
}
}
printf("%lld\n",x);
return 0;
}
O ukládání do souboru jsem se ani nepokoušel, nejvíc místa na jednom disku mám gigabajt. I takhle ten program trval rovné tři hodiny
A kde je test ipv6? 
PS: výplety mám taky v jednání, podle počtu kusů buď rovnou v UK (jen ty pola), nebo v PL.
...tak je pochopitelně jasný, že pro kernelultras.org je 1000+ triček kapku moc...
Počet ipv4 adres vám trochu hapruje, 10^12 jste vzal kde? Je to snad 2^32 ne? Tedy 4 294 967 296 adres..
X.X.X.X
(10+2*90+3*156)/256 = 658/256 = 329/128 = 2.57
4+4*329/128 = 4+329/32 = 457/32 = 14.28
2^32*457/32 = 2^(32-5)*457=2^27*457=61'337'501'696
Máme 4 čísla (X.X.X.X), kde každé z čísel může nabývat 255 různých možností.
256
1.2.3.4
10.0.128.240
196.168.0.1
AB.CD.EF.51
10.A.1B.1
Podle masky sítě může být i 11.22.33.0/8. Ale zpravidla se toto nepoužívá.
akú veľkosť by mal súbor obsahujúci v každom riadku presne jednu IPv4 adresu
IPv4 adresa je 32b číslo, tedy 4B. 2^32*4B = 16 GiB. Použijeme-li nějaký znak jako oddělovač tak to bude 20GiB. Netřeba generovat a hlavně netřeba ukládat. Btw. jsi to mohl prohnat přes pv do /dev/null.
IPv4 adresa je 32b číslo, tedy 4B. 2^32*4B = 16 GiB.To mi bolo jasné pred testom - nebolo mi jasné akú veľkosť by mal ASCI súbor. Ešte by som chcel odfiltrovať _nejako_ (???) len adresné rozsahy patriace SR a CR z tohto zoznamu, takže hádzať to do /dev/null pre mňa nemá nejako význam :)
To mi bolo jasné pred testom - nebolo mi jasné akú veľkosť by mal ASCI súbor.
Nicméně počítat to tak, že si je všechny vygenerujete, je nesmysl (a když už, je nesmysl si ten soubor generovat na disku a pak na něj pouštět wc, od toho máme roury). Stačí jednoduchá úvaha: každý byte může nabývat 10 jednociferných, 90 dvouciferných a 156 tříciferných hodnot, každá se ve výpisu zopakuje 2^24-krát (pro všechny kombinace zbývajících tří). K tomu navíc na každý řádek připadají tři tečky a jeden linefeed. Celkem tedy 4*2^24*(10+2*90+3*156) + (3+1)*2^32 = 61337501696. I kdybych to počítal ručně pomocí tužky a papíru, budu o řád rychlejší než váš program…
.
Ešte by som chcel odfiltrovať _nejako_ (???) len adresné rozsahy patriace SR a CR z tohto zoznamuTo sa stále mení
Nestačilo by jen definovat přes regulární výraz třeba formu IP adresy a pak podle potřeby s tím pracovat? Z toho bys mohl i spočítat velikost souboru ... místo samotného generování.
49*48*47*46*45*44
------------------- = 13983816 sloupečků
1*2*3*4*5*6
A samozřejmě to musíš vydělit počtem sloupečků na tiketu (ani nevím kolik jich dneska je), vyjde ti počet tiketů...
No, 1:14M, to je asi stejně pravděpodobný, jako že mě sundá meteorit, když vyjdu před barák :)pokud to mam interpretovat jako P(sunda me meteorit | vyjdu pred barak) = 1/14e6, tak pri 10e6 lidech, kazdy vyjde pred barak prumerne 2x denne (jenom odhad), by meteorit sundal prumerne 2*10e6 / 14e6 = 1.43 lidi denne.
Jooo
VŠICHNI 
BTW všichni ne, někteří stahovali na IPv6
.
Uz chapu, proc vsichni potrebuji tak rychle pocitace a velke disky.To jako že u pornosbírky ti taky stačí si poznamenat, jak je velká a kolik je minut a obsah už mít nemusíš?
.
.
, nejvíc mě u videí štve .mp4, ten se nedá přehrát mplayerem, dokud není celý
.
Tiskni
Sdílej: