Google, potažmo YouTube umožní návrat tvůrcům, kteří byli zablokováni kvůli údajnému šíření dezinformací souvisejících s COVID-19 a volbami. Tvůrci teď mohou požádat o navrácení přístupu. Společnost Alphabet v této souvislosti uvedla, že zákazy byly uděleny kvůli tlaku tehdejší Bidenovy administrativy.
Vývojári z distribúcie Artix, ktorá je postavená na Arch Linuxe, alebo skôr jeho forkom, už skôr prešli na Open-RC init systém, stále však niektoré projekty ako GNOME boli závislé na systemd. Teraz pretiekol pohár trpezlivosti a počnúc GNOME 49, kvôli ktorému komponenta gnome-session je úplne závislá na systemd-init, padlo rozhodnutie na odstránenie GNOME z repozitárov Artixu. Táto zmena sa podľa všetkého týka viac než 90 distribúcií, ktoré tiež nepoužívajú systemd. Viac v príspevku na DistroWatch.
Magazín IEEE Spectrum opět po roce publikoval svůj žebříček programovacích jazyků. Vedou Python, Java, C++, SQL a C#.
Repozitáře pro spolupráci v rámci projektu Fedora se přesunou z Pagure na nově vzniklý Fedora Forge. Ten stejně jako třeba Codeberg běží na softwaru Forgejo, které bylo už před časem vybráno jako náhrada za Pagure. Pagure pochází z dílny Fedory, ale mimo ni se příliš neuchytil. Jeho vývoj a údržba byly náročné a Fedora se rozhodla jít cestou úspěšnějšího projektu, který má větší základnu přispěvatelů.
Byla vydána (𝕏) nová verze 2025.3 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
V IT4Innovations národním superpočítačovém centru byl dnes slavnostně spuštěn první český kvantový počítač VLQ disponující 24 fyzickými qubity s unikátní hvězdicovou topologií. Systém dodala společnost IQM Quantum Computers a jeho celková pořizovací cena činila přibližně 125 milionů korun.
Výrobce čipů Nvidia chce investovat až 100 miliard dolarů (přes dva biliony Kč) do společnosti zaměřené na umělou inteligenci OpenAI. Firmy o tom informují v tiskové zprávě. Oznámené partnerství přichází v době, kdy se mezi technologickými giganty a start-upy zostřuje konkurence o zajištění přístupu k energii a čipům potřebným pro rozvoj umělé inteligence (AI).
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 157 (pdf).
Společnost Cloudflare oznámila, že sponzoruje nezávislý webový prohlížeč Ladybird a linuxovou distribuci pro vývojáře Omarchy (Arch Linux s dlaždicovým správcem oken Hyprland).
Společnost XTX Markets zabývající se algoritmickým obchodováním pro své potřeby vyvinula a dnes představila a otevřela souborový systém TernFS. Zdrojové kódy jsou k dispozici na GitHubu. Vývoj TernFS začal počátkem roku 2022. Od léta 2023 jej XTX Markets používá v produkčním prostředí.
30.9.2006 18:03
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
Jestli máš na mysli to, „jak se v něm dělá ta stránka“, tak o „embedded Pythonu“ nevím. Třeba k Ruby se dodává binárka eruby (případně modul eruby pro použití z programu), která spouští kód z dokumentu – tedy dělá z něj „něco jako PHP“. To ale není obvyklý modus operandi slušných webových aplikací, které používají nějaké ty šablonovací nástroje nebo něco na ten způsob. Snad jen Rails běžně používají přímo Ruby jako šablonovací jazyk, ale to není takové zlo, jak by se mohlo na první pohled zdát, protože se v těch výsledných šablonách typicky používají jen accessory controlleru, a slušný člověk tam žádné výpočty necpe. 
V konečném důsledku na tom tedy nesejde, prostě z programu vyvoláš šablonu nebo jiný kód, který narve response zpátky do socketu. A protože Python by jako šablonovací jazyk mohl fungovat docela obtížně, tak se v téhle roli nepoužívá, a mimo šablony je Python Pythonem.
Perl Výhody - obrovská podpora. Nevýhody - snad všechno. Nečitelná syntaxe, nedokážu si ho představit v projektu nad několik tisíců řádek.Zajimave, o nevyhodach takhle premyslim u php.
Navic resit, proc skripty s prechodem mezi verzemi prestanou fungovat a jestli budou fungovat i v dalsi verzi... Navic potrebuji provedet i "newebove" cinnosti.
Naopak s Perlem problem nemam. Navic mam tu cest pracovat s prostredim, ktere cita radove stovky tisic radku perloveho kodu.
Cčko zase nebylo navrženo na miliónořádkové programy, kdyby ano, mělo by aspoň namespaces. Holt evoluce.
Navic resit, proc skripty s prechodem mezi verzemi prestanou fungovat a jestli budou fungovat i v dalsi verzi... Navic potrebuji provedet i "newebove" cinnosti.Uvážím-li, že chování perlu se také může lišit ($#pole u prázdného pole může být -1 nebo 0, viděl jsem oboje), tak se perlu raději vyhýbám.
Ale to len aby reč nestála
(a precitat na kazdy riadok kodu 10 riadkov mudrych knih )co sa tyka db, jednoznacne postgresql
a btw, webove stranky vy som urcite pisal v HTML
30.9.2006 17:59
Jardík | skóre: 40
| blog: jarda_bloguje
přešel s windows na LinuxAle fůj: s/s/z/g
30.9.2006 18:06
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
30.9.2006 18:27
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
. Potom jsem to přepsal jako cgi skript, takže web se skládal s jedné binárky a souboru s daty (BDB). Zlaté časy.
30.9.2006 18:31
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
A pokud planujes vlastni hosting, tak jsi dvakrat stastny, protoze si muzes delat co chces
Ja jednoznacne doporucuju Python. Jednak jako jazyk a za druhe pro kvality web frameworku pro nej dostupnych.
Je dobre se podivat na mod_python a ten jednoduchy templatovaci engine co obsahuje, prip. PSP kdyby se ti styskalo po PHP a matlani aplikacni logiky do vzhledu
Znalosti mod_pythonu pak muzes vyuzit pri zprovoznovani ruznych frameworku za Apachem (i kdyz to jde i jinak, typicky pres FastCGI - nebo uplne bez Apache samozrejme...). Doporucil bych ti mrknout na CherryPy a Kid templates - to jsou fajn veci, prip. TurboGears, ktere predchozi dva produkty kombinuji a pridavaji jeste par blbosti. Podobne funguje Django. Na me jsou tyhle frameworky ale uz moc uzce profilovane. Na nektere veci jsou ale jak delane...
Moc doporucuju video, ve kterem nejaky typek srovnava Rails, TurboGears, Django, Plone, Java Sevlets/JSP, a plne vyzbrojene J2EE.
30.9.2006 18:52
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
Zjistil jsem, že po dvou měsících učení jsem v Rails asi 2x efektivnější než v PHP.
Výhody Ruby:
30.9.2006 18:52
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
30.9.2006 18:52
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
30.9.2006 19:51
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
).
Už jen příchod YARVu by měl hodně změnit a ten druhý odkaz ukazuje, že není dobré dělat předčasné závěry, když tomu pánovi jeden diskutující vytáhnul kód v Ruby skoro na rychlost Javy. Je pravda, že mě překvapuje, že by dual Opteron zvládal jen 60 hitů/s, a to i včetně Rails. Ono dost záleží i na aplikaci, někdy kešovat jde, někdy to nejde vůbec, a dá se čekat, že v náročnější aplikaci by se to trošku tou srovnalo i vlivem databáze.
Co se týče dotazu níže, tak scalability RoR by měla být dobrá, ostatně jako každé jiné FastCGI aplikace. Ale zatím jsem to nepotřeboval.
?
.
Ano, ukázat "dump" relační databáze na webu, k tomu se RoR hodí, a párkrát za minutu to zpravidla dovede...
Spousta lidí si to zřejmě dokáže vyladit tak, že jim to stačí a jsou s tím spokojení. Jsme snad všichni svéprávní lidé a každý použijeme to, co uznáme za vhodné a o čem se přesvědčíme, že nám to nejlépe vyhovuje.
(BTW, předvedené benchmarky ukazují výkon referenční implementace, kterou do dvou let velká část lidí již nejspíš nebude používat, protože jednu implementaci má teď Sun, druhou vyvíjí Sasada Kóichi a třetí s velkou pravděpodobností vznikne na základě Strongtalku, už teď se k tomu v mailing listu Strongtalku někteří hlásí. Python je na tom přesně stejně, máme Python, Python+Psyco, IronPython, Jython a PyPy. Do pár let budou všechny ty benchmarky neplatné …)
. Škoda, že se nejdříve nevrhli na dokončení Parrotu (jaký máš vlastně názor na register-based virtuální stroj?) a jako prozatímní řešení mohli použít Pugs s Parrot backendem.
Jinak, autoři onoho projektu s tím tak nějak počítají, protože je na titulce
Contribute: you can make a difference
- you can contribute faster more-elegant programs (FAQ)
- you can suggest new benchmark comparisons (FAQ)
Rubisté se shodují v tom, že je třeba rozhodně napsat lepší řešení. Přiznám se, že mi optimalizace kódu v Ruby přijde taky netriviální, začíná to připomínat Lisp, ale vyplatí se to. (To, co napíšu, se nemusí mapovat 1:1 s tím, co se přesně provádí, a to i sémanticky – třeba GO v Lispu, ekvivalent GOTO, taky není „obyčejné goto“, díky lexikálnímu scopingu se dá vyskočit z vnitřní funkce do vnější včetně stack unwindingu a pořešení veškerého cleanupu, třeba i výjimek, a to rozhodně není „jednoduchý skok“. Takže takový vysokoúrovňový jazyk jako je Common Lisp – rozhodně o kilometry výš než třeba Java, v tom smyslu, že konstrukce jazyka vyjadřují spíš sémantiku než implementaci – může člověku přichystat nejedno překvapení. )
Registrové VM? Pořád čekám, až mi někdo hodí link na studii, ...Uf, to jsem rád, že nejsem jediný, komu připadá mapování virtuálních registrů VM na skutečné registry, v těch neskutečných počtech platforem, které máme, jako prakticky nemožné
. Respektive, možné to asi bude, ale složité.
Takže jazyk nad Parrotem bude přiřazovat lokální proměnné 32 registrům (beru teď jen ty celočíselné), které by JIT kompilátor přejmenovával na jeden ze sedmi dostupných GPR registrů IA32, které následně register renaming unit v CPU přejmenuje na jeden z několika desítek fyzických registrů procesoru, a pak se zase výsledek proodpřejmenuje zpátky … Aha, teď už chápu, proč na tohle člověk potřebuje dva doktoráty, aby ho zaměšstnali.
. Nejvíce mi u Ruby chybí UTF-8.
). Nezanedbatelné je i množství hotových aplikací a tříd a fakt, že PHP5 už má konečně trochu slušný objektový model, takže se ten jazyk vyvíjí k lepšímu. Nicméně debugger mi opravdu chybí. Naopak hláška o chybějícím kompilátoru mi připadá poněkud nesmyslná. PHP není programovací, ale skriptovací jazyk. Proto se aplikacím v PHP říká skripty a ne programy a tudíž nemá smysl mluvit o kompilátoru.
Pokud bych měl dneska volit jiný jazyk na tvorbu webu, pak bych asi zvolil Javu. Velmi slibně se rozvíjí a je pro toto použití už teď poměrně oblíbená. Python se mi taky nezdá špatný, ale jsem zatím příliš líný se ho učit. Perl je IMHO natolik obskurní jazyk, že si nejsem jistý, jestli čas věnovaný jeho pochopení by se mi nějak vrátil, čímž mu nechci ubírat zásluhy a tvrdit, že není vhodný pro web. No a Ruby a spol. jsou věci o kterých sice často slyším, ale v praxi jsem je neviděl
Ad databáze:
Zatím zůstávám u MySQL. Dřív byly její možnosti dost omezující (ve srovnání s PostgreSQL), ale prokazatelně se "blýská na lepší časy", takže jsem zatím neměl důvod ji opouštět.
30.9.2006 19:57
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
30.9.2006 22:00
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
1.10.2006 14:28
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
1.10.2006 16:49
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
Zdrojáky included
MySQL odsunuji do pozadí kvůli lincenci a hledám jinou databázi, kterou lze používat zdarma. Na malé jednouživatelské projekty jsem našel - sqlite a na Windows access. Na střední uvažuji o Firebirdu, ale dokumentace chybí, takže Firebird to asi nevyhraje. PostgreSQL nechci, nemám s ní dobré zkušenosti na Windows.
Jsou-li nějaké tipy na další náhradu MySQL, sem s nimi.
Potřeboval jsem vypočítat celočíselný podíl dvou časů - 
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czprovolaný čas / délka tarifní jednotky. Takže jsem prostě v cyklu přičítal délku tarifní jednotky, počítal počet proběhlých cyklů a cyklus se ukončil v okamžiku, kdy tahle suma byla větší než provolaný čas.
Bohužel pro bezplatné terify jsem jako délku tarifní jednotky zvolil 0:00, takže se pořád přičítala 0, a pořád ta 0 nechtěla být větší než ta délka hovoru.
Takže jsem si pro sebe poučku "nulou dělit nelze" poupravil na "nulou dělit samozřejmě lze, nikdo vám v tom nezabrání, ale nebere to konce"
COALESCE (delka_jednotky, konstanta_pre_null), a pre bezplatne tarify nastavoval stlpec na null, to by mozno slo
time / time není v PostgreSQL definován. Když mi došlo, že jsem do té tabulky před pěti minutami vložil nulu jako speciální případ, tu funkci jsem samozřejmě upravil tak, aby pro tento případ vracela nulu. NULL jsem z nějakého důvodu nechtěl použít, ten samý sloupeček se používal ještě v dalších pohledech, nebo se podle něj třídilo nebo něco na ten způsob…
coalesce (nullif (col, '0:0:0'), a/b, KONSTANTA)
N×M (volané číslo × zpoplatnění = jiný tarif je za volání na mobil, jiný místně, jiný dálkový hovor) udělat N×1 tak, aby se ze způsobů zpoplatnění vybral ten, který nejlépe pasuje na volané číslo…
k tomu N*M dve view "za sebou", tam snáď niet čo vymýšlať
z hladiska logiky pre bezplatný interval je správnou dĺžkou intervalu hodnota nekonečno, resp. maximum.No vida, to mě nenapadlo. Jenom jestli PostgreSQL nějakou použitelnou hodnotu pro maximální interval má. No ale hlavně doufám, že rozúčtování telefonních hovorů podnikové ústředny už nikdy dělat nebudu
ok, nabudúce sa pokúsim nezabudnúť explicitne deklarovať vtipný obsah
1.10.2006 21:41
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
A naopak jsem rád, že se se vším, včetně seznamů i map, zachází stejně, připadá mi to přehlednější. Ale přiznávám se rovnou, že jsem si nebyl ani v Perlu ani v Pythonu nikdy schopen zapamatovat, které závorky se používají na vytvoření jakého druhu kolekcí…
int je objekt?
Object get_xyz (Hashtable hash, Int key1, Int key2) {
sum = key1.intValue() + key2.intValue();
return new Int (
( ((Int) hash.get (key1)).intValue()
+ ((Int) hash.get (key2)).intValue()
) / sum);
}
oproti Perl-u
sub get_xyz ($$$) {
my ($hash, $key1, $key) = @_;
return ($hash->{$key1} + $hash->{$key2}) / ($key1 + $key2);
}
# a trochu menej čitateľne
sub get_xyz ($$$) {
($_[0]{$_[1]} + $_[0]{$_[2]}) / ($_[1] + $_[2])
}
ad zátvorky v perli, je to jednoduché, aký index chces použiť, tak referenciu vytvoríš. Nevravím o pseudo-hashes, tam je to inak.
ad Java, aj int je objekt?To skoro v mé věte bylo záměrně
a kde má overloadovanie operátorov?To je nějaká nutná podmínka?
daľšia vec, ktorá mi v Jave vadí, chýbajúca multiple inheritanceA co interfacy? Vícenásobnou dědičnost od různých tříd jsem nikdy nepotřeboval, takže mi nechybí.
potom ešte Hashtable (a tým asi celý príslušný koncept. Vadí mi, že pre každý objekt vytiahnutý z Hashtable musím robiť explicitné pretypovanie, vadí mi, že kľúčom môže byť len Object.Podívejte se na Javu 5 a generiky. Ale účelem této diskuze myslím nebylo sepisovat, co na Javě vadí někomu, kdo v ní neprogramuje…
3.10.2006 09:48
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
daľšia vec, ktorá mi v Jave vadí, chýbajúca multiple inheritance
Tohle je jedna z nejhorších věcí v C++. Vícedědení nemá např. ani C# a je to jen dobře.
a potom ešte Hashtable (a tým asi celý príslušný koncept. Vadí mi, že pre každý objekt vytiahnutý z Hashtable musím robiť explicitné pretypovanie, vadí mi, že kľúčom môže byť len Object.
Cože? Jaké přetypování? Při vytváření hashmapy (a obecně všech kolekcí) si přece určujete typy klíče (a tedy neplatí, že to může být jen Object) a hodnoty, např: HashMap<Integer, String> h = new HashMap...
Dále. Co je to proboha za kód? Když už nic menšího, proč je definovaná návratová hodnota Object a přitom vrací Int? Pokud píšete takhle, tak se nedivím, že jste Javu zavrhl.
ten kód je z roku 1998, kedy podobnými vymoženosťami disponovalo akurát tak C++. Tá inkriminovaná metóda bola implementáciou z Interface (a samozrejme som nepastol inú, ktorá pracovala s náročnejšími datovými štruktúrami.
3.10.2006 10:14
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
viacnasobná dedičnosť je vec, ktorá (v špecifických projektoch) ušetrí množstvo copy-paste
Copy-paste v OOP? V tom případě je špatně navržená hierarchie. Pokud jsem se (jednou), dostal do situace, že jsem "chtěl/musel" okopírovat kód z jiné třídy, kterou jsem nemohl použít rovnou (už tohle je znak, že je něco špatně), tak jsem se zamyslel a změnil hierarchii tak, aby to provést šlo. (Prostě refaktoring.) Což jako důsledek celkově vyčistilo kód.
Chcete naznačiť, že ste sa nikdy nestretli so situáciou, ked existoval Interface, ktorého jedna metóda mala rovnaké chovanie nezávisle na implementáci zvyšku ?
Ne. A zrovna Interface vícedědičnost umožňují.
Nehledě na to, že když 1. třída má 150 metod, 2. třída 70 metod a pak chcete obě podědit, to se Vám to opisování přes dva datové členy a delegování metod trochu natáhne.Myslím, že v eclipse IDE to budou tři, maximálně čtyři kliknutí myší
Tiskni
Sdílej:
