3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.
Open source webový aplikační framework Django slaví 20. narozeniny.
V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.
Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.
Výroba 8bitových domácích počítačů Commodore 64 byla ukončena v dubnu 1994. Po více než 30 letech byl představen nový oficiální Commodore 64 Ultimate (YouTube). S deskou postavenou na FPGA. Ve 3 edicích v ceně od 299 dolarů a plánovaným dodáním v říjnu a listopadu letošního roku.
Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.
Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.
McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.
Byla vydána (𝕏) červnová aktualizace aneb nová verze 1.102 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.102 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána nová verze 2.4.64 svobodného multiplatformního webového serveru Apache (httpd). Řešeno je mimo jiné 8 bezpečnostních chyb.
31.1.2007 21:58
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
convert mi ho bez problémů zmenšil na 1500x1500, jen při tom potřeboval skoro 2 GB paměti (samozřejmě virtuální).
program požádá třeba o 1M ram a tu potřebuje dostat v celku, takže pro alokaci musí být v RAM volný blok o velikosti 1M.V Linuxe je to pravda, v BSD nikoli, tam neexistuje fragmentacia pamate.
program požádá třeba o 1M ram a tu potřebuje dostat v celku, takže pro alokaci musí být v RAM volný blok o velikosti 1M
Musí být volný blok virtuální paměti, ne fyzické (ta může být klidně celá plná - tedy až na rezervu definovanou v /proc/sys/vm/min_free_kbytes).
To jste na omylu program požádá třeba o 1M ram a tu potřebuje dostat v celku, takže pro alokaci musí být v RAM volný blok o velikosti 1M.Nejsem expert na jadro ale jak to popisujete, tak mi z toho plyne, ze virtualni pamet je prakticky nanic. Resp. pokud by se neco odswapovalo, tak by to musel byt cely alokovany blok pameti. Funguje to opravdu takto? Ja zil doted v predstave, ze fyzicka pamet a pamet jak ji vidi proces spolu vubec nesouvisi a provadi se preklad v procesoru pomoci tabulek.
brk() a mmap(), natož user space - malloc(), new) samozřejmě pracuje s virtuální pamětí.
Aha, cili teda pulka bloku pameti zustane v RAM a druha bude na disku. Mezitim se ta odswapovana fyzicka RAM zaplni necim jinym (to je jedno cim) a nasledne nastane potreba priswapovat puvodni odswapovany blok zpet do RAM (rekneme, ze bude potreba). Protoze uz nemuze na sve puvodni misto, bude to nekam jinam. Dojde tedy k tomu, ze onen puvodni blok se ve fyzicke RAM "roztrhne". Proc tedy nejde naalokovat takto "roztrzeny" blok hned na zacatku, ale jak tvrdite, musi byt ve fyzicke RAM souvisly?
Nebo je nekde v me uvaze chyba?#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#define MAX 1024*1024
#define SIZE 1024*1024
char *pointers[MAX];
int main(void)
{
int i;
char *tmp;
char buf[16];
for (i = 0; i < MAX; i++) pointers[i] = NULL;
for (i = 0; i < MAX; i++) {
pointers[i] = malloc(SIZE);
// memset(pointers[i], 'A', SIZE);
if (pointers[i] == NULL) {
fprintf(stderr, "Nemozem alokovat pamat (pointers)\n");
break;
}
}
for (i = 0; i < MAX; i += 2) {
if (pointers[i] != NULL) {
free(pointers[i]);
pointers[i] = NULL;
}
}
tmp = malloc(SIZE*2);
if (tmp == NULL) {
fprintf(stderr, "Nemozem alokovat pamat (tmp1)\n");
}
for (i = 0; i < MAX; i++) {
if (pointers[i] != NULL) {
free(pointers[i]);
pointers[i] = NULL;
}
}
tmp = malloc(SIZE*2);
if (tmp == NULL) {
fprintf(stderr, "Nemozem alokovat pamat (tmp2)\n");
}
fgets(buf, sizeof(buf), stdin);
return EXIT_SUCCESS;
}
Ne, proč? User space aplikacím po fyzické paměti nic není, ty s ní vůbec nepřijdou do styku. To je to, co tu celou dobu od začátku tvrdím - že má-li convert problémy s alokací paměti, není třeba přidávat fyzickou paměť, ale stačí dočasně zvětšit virtuální (přidáním swapu). Dokonce i ten zmiňovaný convert si poradí s 32 MB fyzické paměti a 256 MB swapu…
malloc() alokoval 224 MB blok (pochopitelně virtuální) paměti na počítači s 32 MB fyzické paměti a 256 MB swapem. Kdo nevěří, může si to klidně vyzkoušet sám.
31.1.2007 09:31
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
ulimit -a').
Na 256M to asi neuděláš. On je totiž rozdíl 250M v 256M fyzické a 650M v 256M fyzické.
Právě jsem zmíněnou operaci, tj. zmenšení 15000x15000 obrázku (644 MB TIFF) příkazem convert z balíčku ImageMagick provedl na stroji s 64 MB fyzické paměti. Mám pro zajímavost zkusit ještě 32 MB?
tifftopnm -byrow big.tiff | pamscale -xscale=0.5 -yscale=0.5 | pnmtopng > output.pngTahle kolona zmenší původní tiff na polovinu a uloží výsledek ve formátu png
)
tifftopnm big.tiff >vystup.pnm pnmscale vystup.pnm -xscale=0.1 -yscale=0.1 > vystup_zmenseno.pnmToto cvičeni jsem provedl na P4 1.5GHz s 512 MB RAMM a šlo to docela rychle. Děkuji všem za odpovědi a názory na problém.
Tiskni
Sdílej:
