Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Rad bych vedel, zda nekdo pouziva nejake vyvojove prostredi pro rozsahlejsi informacni systemy, tedy nejen pro ucetnictvi ale i pro vyrobu a pod. Je jedno jestli privatne nebo v zamestnani.
Pod vyvojovym prostredim si ovsem nepredstavuji eclipse nebo neco podobneho, tedy nejaky nadupany editor, ktery nabizi parametry funkci nebo vlastnosti nejakych trid a ma treba i integrovane spousteni kompileru a debugeru. Myslim spise na neco, co uz ma napr. funkce pro sklad, zalozeni nove zakazky apod. tedy funkce svazane s aplikaci. K tomu to obecnejsi, napr. generator vystupu.
Vim, ze existuji systemy (compiere, tinyerp), ktere jsou otevrene a je mozno je vyuzit. Ale mam pocit, ze toto neni spravna cesta - filosofie, ktera se za timto postupem skryva je, "vezmi to, co jsme vymysleli a jestli chces zmeny, tak se hrabej v tech zdrojacich".
Pripada mi divne, ze zadny takovy system nemohu najit - ani ke koupi, ani free. Zatim se vsichni vrhaji na nejake konkretni ucetnictvi, ale kdyz ma dojit na zmeny , tak je nikdo nechce a ani nemuze delat.Rad bych se tedy zeptal, nebylo by lepsi mit spise nastroj na vyrobu tech ucetnictvi, nez ta ruzna ucetnictvi, ve kterych se musim eventuelne s rizikem hrabat, kdyz chci neco zvlastniho. proc takovy system neexistuje. Nebo nekdo neco takoveho zna?
Tiskni
Sdílej:
26.5.2006 19:34
JiK | skóre: 13
| blog: Jirkoviny
| Virginia
) a generování GUI napůl dynamicky a přitom do čitelného kódu. Některé operace budou trošku nestandardní (customized fulltext v texové databázi), relační databáze se mi do toho proto moc tahat nechce, objekty tohle řeší líp. Prevalence by ta data měla zvládnout, tím se vyřeší tři čtvrtě problémů.
Klient desktopový, zabalený do Starkitu, který si bude ze serveru tahat taky generované GUI (aktualizace klienta: řeší se samy. ). Řekněme, že Tk pro mé účely má jisté výhody (oproti jiným řešením) a na cílové platformě, která nebude unixová, nemusím tolik řešit vzhled, na jehož vylepšení se v unixovém Tk teprve pracuje. Jsem holt minimalista. Jestli klient bude mít mega a půl a server čtyři mega (oboje celkem), bude to hodně a přitom to bude kompletní. 
Je pravda, že překladatelská knowledge base nemá s účetnictvím moc společného, ale pro mně je to pracovní IS. 
Tahle technologie vznikla v první polovině 90. let přesně za tímhle účelem a evidentně funguje, lidi v tom takové aplikace dělají. Kromě toho, pokud spuštění aplikace bude trvat pár sekund, tak se snad nic neděje. Spousta aplikací se spouští pár sekund. Co přesně máte na mysli tou "maskou"? Měla by to být aplikace pro cca. 10-15 lidí s důrazem na retrieval textových dat.
I kdyz bude cela databaze "nejak" (co je nejak je zde ta otazka) odstinena, tak jsem zjistil, ze vetsina uzivatelu nejak intuitivne chce si v nejhorsim pripade na ta data "sahnout" ve vlastni rezii.
K tomu clientu - to je pro me jeden ze stavebnich kamenu toho vyvojoveho prostredi. Domnival jsem se, ze chapu co chcete delat, ale ted si nejsem jisty. Proto moje predstava:
- client je nejake exe a toto exe nema v sobe po startu zadnou aplikacni logiku - start muze trvat i nekolik sekund
- exe si natahne po startu z serveru nejake menu a vse ostatni potrebne
- uzivatel si vybere v menu nejakou polozku a klikne na ni
- v tuto chvili to exe natahne ze servru nejaky popis a na obrazovce se objevi to, cemu rikam "maska". Maska je tedy jedno z mnoha oken te aplikace. V tomto okne je tech 500 elementu (widgetu) a doba od toho kliknuti az k uplnemu zobrazeni toho okna by nemala presahovat 0.7 sekundy.
je vas postup podobny, nebo na to jdete jinak
.
BTW, „Neplatí, že OODB -> nonSQL“ – nevím, no, psát definice tříd, generické funkce (v primitivnějších jazycích „rozhraní“), vytvářet z objektů složité datové struktury, používat kontejnerové třídy s libovolnými algoritmy - to už v SQL jde? Jestli SQL 2003 fakt takhle vychytali, tak to se na něj budu muset podívat.
BTW, „Neplatí, že OODB -> nonSQL“ – nevím, no, psát definice tříd, generické funkce (v primitivnějších jazycích „rozhraní“), vytvářet z objektů složité datové struktury, používat kontejnerové třídy s libovolnými algoritmy - to už v SQL jde? Jestli SQL 2003 fakt takhle vychytali, tak to se na něj budu muset podívat.
Napsal jsem to blbě. Spíš tam měly být objektově-relační DB. Na druhou stranu jsou dnes ORDB používané více než čisté OODB... Přes úpadek aspoň dodám, že některé OODB se snaží podporovat i SQL, kvůli klasickým relačním úlohám, které jsou v nich hůře popsatelné (slušně shrnuté to je třeba ve Wiki).
SQL 2003 vychytávají spíše směrem k SQL/XML (paper).
„Additionally, object databases lack a formal mathematical foundation, unlike the relational model, and this in turn leads to weaknesses in their query support.“Upřímně, já nevím, co se pánům nelíbí, ty chybějící „formální matematické základy“ mi přijdou jako FUD. Řádkové zamykání a řešení deadlocků v reálných implementacích – to jako podle nich má být ta „formálně lépe vyřešená“ věc? V tu chvíli je mi je matematicky čistý koncept relačního kalkulu naprd, když si díky takové věci jako je neexistence identit vynucuje takovéhle nesmysly...
Podotýkám, že teorie pana Codda mi nesmrdí, jen vidím kolem sebe hromadu „SQL fanatismu“, aspoň mi to tak přijde.
„Database-centric thinking tends to view the world through a declarative and attribute-driven viewpoint, while OOP tends to view the world through a behavioral viewpoint.“To už mi přijde jako dost velký nesmysl, protože objektová databáze může sama o sobě deklarativní přístup obsáhnout, není s ním v jakémkoli rozporu. Ale možná je to tím, že pojem „objektová databáze“ chápu trošku šířeji, asi jako Lisp a jiné jazyky mimo mainstream chápou o dost obecněji pojem „objekt“...
To už mi přijde jako dost velký nesmysl, protože objektová databáze může sama o sobě deklarativní přístup obsáhnout, není s ním v jakémkoli rozporu.Nesmysl to podle mě není. Autor netvrdí, že objektová databáze deklarativní přístup neobsahuje, jen poukazuje na problém s přístupem k datům kvůli zapouzdření (querying on data content vs. predefined access paths). A v podstatě má pravdu, když říká, že objektové systémy jsou vystavěny na chování objektů. Na nutné (!?) deklarativní "zlo" lze nahlížet i jako na přežitek ze světa primitivních typů, ale to už odbočuji.
Ale možná je to tím, že pojem „objektová databáze“ chápu trošku šířeji, asi jako Lisp a jiné jazyky mimo mainstream chápou o dost obecněji pojem „objekt“...To už mi došlo, když jsi psal o generických funkcích a podvědomě asi ještě mnohem dříve (jak tě tak z diskusí znám
). Smalltalk je mainstream?
Objektová databáze mi umožní udělat si na míru deklarativně popsaný sytém, relační databáze by mi díky vazbě většiny RDBMS na SQL vnutila jeden konkrétní, poměrně rigidní, který by mi pro slušnou část dat ještě ke všemu nevyhovoval a já bych musel dělat separátní data ještě mimo databázi (vlastní fulltextová indexace a spol) a ještě to celé lepit dohromady v několika backendech a starat se o udržování konzistence...kdepak, děkuji, nechci. Prevalence to obslouží mnohem líp, dokud to nebude moc velké. To se hned tak nestane, ale pružnost budu potřebovat úplně od začátku (pár klasických tabulek, nějaký ten hypertext, fulltextový index, dost možná konfigurovatelný, hierarchické slovníky...). Prostě věřím, že dlouhodobě se mi v tom bude dělat příjemněji. A člověk se aspoň něčemu přiučí.
. Možná jsi mohl být konkrétnější ohledně ztraceného významu, protože pokud jde o čistě deklarativní záležitosti, tak by relační model měl stačit. Že to nebude tak pohodlné jako objektový přístup, by mohla vyvážit vyspělost (doplň si aspoň 5 omílaných rysů jako robustnost, škálovatelnost... ne, nechi je shazovat) RDBMS. Ale možná bych být tebou uvažoval i o objektově-relačním systému. Co se vůbec chystáš použít? Jestli to není tajné, nebo doma vypěstované.
Nevím, no, jak moc dobře se z SQL – nebo ještě lépe z existující databáze – dají generovat rozumné formuláře? Třeba Ruby on Rails řeší problém „řešit každý problém na jednom místě“, ale hopsání mezi editorem struktury databáze a definicí třídy mě taky moc neuspokojilo. Asi jsem moc náročnej... Budu taky mít testovací vektor v podobě poměrně slušného množství překladů (šlohnutých z databází Microsoftu, ke kterým mám login ) a pokusím se zreprodukovat fuzzy matching TRADOSovské konkordance, když to bude poskytovat podobné nebo ještě lepší výsledky, ovšem nad daty z naší databáze s custom poli (autor termínu, historie změn, věrohodnost překladu), ušetří nám to integrací hromadu času a práce při překladech. Fakt nevím, jak bych to mapoval nad SQLkem, přijde mi to jako lámání přes koleno.
. Prevayler nicméně vypadá velmi zajímavě. Ach jo, asi bych Tě měl blokovat - je zkouškové! Ale Scalability Test si zkusím.
v poslednej dobe sa mi zapacil OpenLaszlo, snad ma jeho existencia konecne dokope k dotiahnutiu svojho gui projektu do konca
ale viac ma do debaty o uzivatelskej privetivosti nedostanete. moj nazor je, ze design maju robit netechnici pre netechnikov, a technici - programatori vymysliet cestu, ako to vyrobit, nie ako to "osidit" (predsa len slusnejsie ako slovenske "oj*")
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz