Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: Muo 04. 04. 2018, 15:07:31
-
Je jedno, jestli mluvím o klasických PC nebo mobilech. Mohl by mi to někdo vysvětlit? Proč aplikace jsou pořád objemnější a objemnější? Proč je dnes Android mobil s 8GB interní paměti téměř nepoužitelný? Proč jen aplikace Mapy Google zabírá v mém telefonu 148 MB (čistě aplikace, ne její data) a aplikace BurgerKingu (které vlastně nic kromě ukázání kuponů neumí) 73 MB?
-
Je to jednoduché: Všude samý framework, hromady knihoven a závislostí mezi nimi. Kdo programuje bez nich, neni IN a je ostrakizován.
-
Taky musíš započíst textury, obrázky a videa/animace, které se zvyšujícím se rozlišením výrazně nabírají na velikosti.
A samozřejmě ... šetřit místem znamená neúčelně využívat čas vývojářů, místa má dnes každý dost. ;)
-
Protože ty programy toho umí násobně více než dříve.
Je to jasné; do programů se věci v podstatě vždycky jen přidávají. Odebrat se můžou jen málokdy, protože mezitím se najde spousta uživatelů, kteří dotyčné funkce začnou používat a nechtějí se jich vzdát. Občas se zadaří refaktoring, že program dělá to samé, ale je menší. Jenže to je v záplavě těch nových věcí jen plivnutí do moře.
Přičti k tomu nejen program samotný, ale i všech knihoven, na kterých je závislý; i ty se neustále vylepšují a přidávají se do nich nové věci. Výsledek je, že programy v podstatě jenom rostou.
Je to podobné jako se zákony; jejich množství neustále narůstá. Nikdo totiž nemá koule na to nějaký zákon zrušit, protože se celkem špatně domýšlejí důsledky takového zrušení (a navíc na tom ani nikdo nemá moc zájem).
Jediným řešením je asi celý program zahodit a napsat celý znova. Ten nový sice pak bude mít jen půlku funkcí, jenže to tak moc nebude vadit, protože uživatelé můžou zůstat u původního programu. Minimálně do doby, než se daná funkce objeví i v novém programu, nebo dokud uživatelé zjistí, že tu funkci zas tak moc nepotřebují.
-
Je to jednoduché: Všude samý framework, hromady knihoven a závislostí mezi nimi. Kdo programuje bez nich, neni IN a je ostrakizován.
Mozem z autopsie povedat, ze je to tak. Najcastejsie musi byt vnutri embednuty este aj webserver aj kolotoc, aj ked sa to nepouziva.
-
Nejen to, ale take se do programu pridavaji ficury aby se pridavaly ficury. Jinak by nikoho nedonutili upgradovat, kdyz mu stavajici verze staci. Ficury jsou pak reklamnim lakadlem a tez pak staci, aby si to nekdo koupil a ostatni honem upgraduji, protoze to nemuzou otevrit nebo v tom neco nechodi.
-
tohle tema tady bylo tak pul roku zpatky.
-
Vsak to je vecne tema. Cim vypasenejsi mame stroje, tim vetsi sracky do nich sypeme. A bude hur! Je si predstavte, co by se dalo prohanet kvantovymi pocitaci. Treba Notepad o velikosti 350 GB.
-
UI designer nakresli takyto datetime picker ktory niekde videl. v ramci projektu sa schvali design.
a developer ma 2 moznosti - natiahne kretensku 2MB library z ktorej pouzije lennten datetime picker, alebo sa bude 2 tyzdne ondit s tym aby to priblizne tak naprogrmoval.
hadaj ktoru moznost vyberie project manager? cas je drahy na to aby vsetci znova a znova riesili comboboxy. a uzivatel si kupi lepsi telefon
-
To je jak pracovní stůl, koupil jsem si větší aby se mi toho naň více vešlo, ale ve výsledku se mi na něm akorát daří udržovat větší bordel, pač on toho prostě víc pojme :) Platí i o velikosti místnosti nebo harddisku.
-
To je jak pracovní stůl, koupil jsem si větší aby se mi toho naň více vešlo, ale ve výsledku se mi na něm akorát daří udržovat větší bordel, pač on toho prostě víc pojme :) Platí i o velikosti místnosti nebo harddisku.
+1
-
tohle tema tady bylo tak pul roku zpatky.
protože od naposled se zvětšily!
-
... a developer ma 2 moznosti - natiahne kretensku 2MB library z ktorej pouzije lennten datetime picker, alebo sa bude 2 tyzdne ondit s tym aby to priblizne tak naprogrmoval.
Šikovný vývojář vezme z knihovny jen ten datetime picker. Jenže to se dnes nenosí.
-
... a developer ma 2 moznosti - natiahne kretensku 2MB library z ktorej pouzije lennten datetime picker, alebo sa bude 2 tyzdne ondit s tym aby to priblizne tak naprogrmoval.
Šikovný vývojář vezme z knihovny jen ten datetime picker. Jenže to se dnes nenosí.
A proč bych to dělal? Jsem za to snad placen? Ne. Tak se stáhne i troška balastu kolem. Paměť je levná, můj čas ne.
-
Hehe, pamatuju když Ethereal měl pár stovek kB a WinPCAP driver taky. Cca týden zpátky jsem koukal na vlastnosti složky s Portable Wiresharkem a měla 480 MB. A to jsem do ní záznamy provozu nikdy neukládal, měl to na svědomí tuším gtkLib framework, nebo v čem to mají udělaný.
-
... a developer ma 2 moznosti - natiahne kretensku 2MB library z ktorej pouzije lennten datetime picker, alebo sa bude 2 tyzdne ondit s tym aby to priblizne tak naprogrmoval.
Šikovný vývojář vezme z knihovny jen ten datetime picker. Jenže to se dnes nenosí.
A proč bych to dělal? Jsem za to snad placen? Ne. Tak se stáhne i troška balastu kolem. Paměť je levná, můj čas ne.
Problém je v tom, že takhle zprasené aplikace pak plýtvají časem uživatele. Promrhaný čas je pak řádově vyšší, než úspora času programátora.
-
... a developer ma 2 moznosti - natiahne kretensku 2MB library z ktorej pouzije lennten datetime picker, alebo sa bude 2 tyzdne ondit s tym aby to priblizne tak naprogrmoval.
Šikovný vývojář vezme z knihovny jen ten datetime picker. Jenže to se dnes nenosí.
A proč bych to dělal? Jsem za to snad placen? Ne. Tak se stáhne i troška balastu kolem. Paměť je levná, můj čas ne.
Problém je v tom, že takhle zprasené aplikace pak plýtvají časem uživatele. Promrhaný čas je pak řádově vyšší, než úspora času programátora.
Je to ten uživatel ochoten programátorovi zaplatit?
-
Problém je v tom, že takhle zprasené aplikace pak plýtvají časem uživatele. Promrhaný čas je pak řádově vyšší, než úspora času programátora.
Je to ten uživatel ochoten programátorovi zaplatit?
Ne. Uživatel raději přejde k programátorovi, který to už má rychlejší a kvalitnější. Zabránit mu v tom může jen vendor lock.
-
Je to ten uživatel ochoten programátorovi zaplatit?
No prinejmensim pokud se jedna o aplikaci, ktera se prodava po milionech, tak to ten uzivatel plati.
-
Je to ten uživatel ochoten programátorovi zaplatit?
No prinejmensim pokud se jedna o aplikaci, ktera se prodava po milionech, tak to ten uzivatel plati.
A určitě platí za minimalizaci té aplikace? Já tedy když platil za "krabicový" SW, tak jsem tam nikdy neměl rozúčtováno, kolik z toho jde na vývoj nových featur, kolik na opravu bugů, kolik na zisk akcionářům, kolik jsou náklady na platy a kolik náklady na elektřinu a kolik na minimalizaci aplikace na disku a v paměti.
Já osobně vnímám obří nárůst velikosti aplikací negativně. Byl bych strašně rád, kdyby byly dál podstatně malé, ale... Když kupuji aplikaci (nebo stahuji nějakou aplikaci zdarma), tak řeším jiné věci, její velikost je priorita č. 247. Pokud máte pocit, že je dost lidí, kteří jsou ochotni platit za aplikace, jejichž vývojáři věnovali hodně času a energie tomu, aby aplikace nebyla větší, než je nutné (a ten čas a energie pak v té aplikaci chyběli jinde), tak vzhůru - založte si takovou firmu, která bude takový SW produkovat.
-
Problém je v tom, že takhle zprasené aplikace pak plýtvají časem uživatele. Promrhaný čas je pak řádově vyšší, než úspora času programátora.
Je to ten uživatel ochoten programátorovi zaplatit?
Ne. Uživatel raději přejde k programátorovi, který to už má rychlejší a kvalitnější. Zabránit mu v tom může jen vendor lock.
Neboli: Je lepší být bohatý a zdravý, než chudý a nemocný. To je asi každému jasné, že pokud existuje programátor, který má rychlejší a kvalitnější a menší aplikaci, že mu dá přednost většina zákazníků.
Ale ta dělící čára v reálném světě většinou vede jinudy. Většinou pokud chcete mít aplikaci kvalitnější (tedy funkčně bohatší) a chcete jí mít na trhu rychle, tak musíte vyvíjet rychle (tedy v maximální míře používat ty přefouknuté knihovny a frameworky).
Pokud vám vadí, že vám aplikace bobtná, tak si musíte hodně věcí napsat/přepsat sám - a vaše aplikace bude na trhu později a bude mít méně featur, než ta nafouknutá konkurence.
Já jsem nikdy krabicový SW netvořil, já vždy dělal zakázkový SW. Pro náš program si zákazník většinou kupoval dedikovaný počítač. Jestli sežereme 30 % nebo 60 % paměti bylo úplně jedno. Jestli si zákazník bude muset kvůli naší aplikaci koupit dvojnásobek paměti, než bylo v tu dobu běžné, bylo také úplně jedno.
To, jestli naše aplikace poběží nad MSSQL, nebo Firebirdem a proč nikdy nepoběží nad MySQL se rozhodovalo podle úplně jiných vlastností, než kolik si vezme instalace té databáze a kolik si ta DB vezme paměti.
Nikdy jsem se neodvážil přijít za zákazníkem a říct mu: Když si připlatíte X desítek až stovek tisíc Kč navíc na hodinových sazbách programátorů, tak vám dodáme aplikaci, která sežere méně paměti a vy ušetříte jednotky tisíc Kč za paměť v jednom stroji.
Co bylo bežné, že se nabídlo zákazníkovi, jestli si chce připlatit desítky tisíc za hodinové sazby programátorů, aby se vylepšil existující program, aby se s ním zákazníkovi lépe (a rychleji) pracovalo. Bylo to ale vždy ekonomicky podložené rozhodnutí zákazníka, aby si spočítal, kolik času svých zaměstnanců tím ušetří (a za jak dlouho se mu tak vrátí investice do vylepšení softwaru).
-
Toz ja bych si to predstavoval tak, ze bych platil za kvalitu aplikace, tedy az z mala kodu budu mit hodne muziky. Ale nevylucuju, ze jini to berou tak, ze cim vic MB za sve penize dostanout, tim lip, stejne jako v supermarketu, kdyz chteji za sve penize co nejvetsi vahu z kurecich kuzi a prasecich sourku.
SW podle mych predstav by pak mohl byt rychlejsi, pokud by byl dobre napsan a pri trose stesti mene zabugovany, protoze monstruozita s 20 let starymi konstrukcemi, do kterych porad nekdo neco dolepoval, se asi bude dost blbe udrzovat.
-
... a developer ma 2 moznosti - natiahne kretensku 2MB library z ktorej pouzije lennten datetime picker, alebo sa bude 2 tyzdne ondit s tym aby to priblizne tak naprogrmoval.
Šikovný vývojář vezme z knihovny jen ten datetime picker. Jenže to se dnes nenosí.
Problem s takymto udrbanym kodom je, ze pokym v kniznici fixnu bugy, tak v copypaste chyby zostanu.
Tiez treba davat pozor, aby bola licencia dostatocne permisivna.
-
Protože můžou.
-
... a developer ma 2 moznosti - natiahne kretensku 2MB library z ktorej pouzije lennten datetime picker, alebo sa bude 2 tyzdne ondit s tym aby to priblizne tak naprogrmoval.
Šikovný vývojář vezme z knihovny jen ten datetime picker. Jenže to se dnes nenosí.
Problem s takymto udrbanym kodom je, ze pokym v kniznici fixnu bugy, tak v copypaste chyby zostanu.
Tiez treba davat pozor, aby bola licencia dostatocne permisivna.
O důvod víc, proč takovou obludnou knihovnu nedělat. S rostoucí velikostí knihovny se snižuje pravděpodobnost, že takové bugy někdo fixne.
-
... a developer ma 2 moznosti - natiahne kretensku 2MB library z ktorej pouzije lennten datetime picker, alebo sa bude 2 tyzdne ondit s tym aby to priblizne tak naprogrmoval.
Šikovný vývojář vezme z knihovny jen ten datetime picker. Jenže to se dnes nenosí.
Problem s takymto udrbanym kodom je, ze pokym v kniznici fixnu bugy, tak v copypaste chyby zostanu.
Tiez treba davat pozor, aby bola licencia dostatocne permisivna.
O důvod víc, proč takovou obludnou knihovnu nedělat. S rostoucí velikostí knihovny se snižuje pravděpodobnost, že takové bugy někdo fixne.
O koze, o voze...
-
Problém je v tom, že takhle zprasené aplikace pak plýtvají časem uživatele. Promrhaný čas je pak řádově vyšší, než úspora času programátora.
Je to ten uživatel ochoten programátorovi zaplatit?
Ne. Uživatel raději přejde k programátorovi, který to už má rychlejší a kvalitnější. Zabránit mu v tom může jen vendor lock.
Ve skutečnosti to pro uživatele není priorita. Get over it.
-
Ve skutečnosti to pro uživatele není priorita. Get over it.
Spis uzivatel kolikrat nema na vyber, tak se spolehne na radu odborniku a ti rikaji, ze si ma koupit vykrmenejsi pocitac.
-
Problém je v tom, že takhle zprasené aplikace pak plýtvají časem uživatele. Promrhaný čas je pak řádově vyšší, než úspora času programátora.
Je to ten uživatel ochoten programátorovi zaplatit?
Ne. Uživatel raději přejde k programátorovi, který to už má rychlejší a kvalitnější. Zabránit mu v tom může jen vendor lock.
BFU prejde tam kde dostane sluzbu ktoru potrebuje a nebude sa ukajat nad tym ze backend je v Erlangu a DNS ma o 0.97ms rychlejsi
-
... a developer ma 2 moznosti - natiahne kretensku 2MB library z ktorej pouzije lennten datetime picker, alebo sa bude 2 tyzdne ondit s tym aby to priblizne tak naprogrmoval.
Šikovný vývojář vezme z knihovny jen ten datetime picker. Jenže to se dnes nenosí.
A little copying is better than a little dependency.
-
Pamatuju si jak v roce 2007 kdyz jsem jeste pracoval ve vyrobnim podniku a na PC jsme nemeli povoleny internet a IP adresu jsem si nemohl zmenit protoze sem nemel admina. Tak jsem nabootoval linuxovou distribuci brutusware ktera byla na dvou 3,5" disketach. A na techto 2 disketach byl kompletni operacni system vcetne weboveho prohlizece links a normalne jsem to pouzival!! Je to smutne to porovnat se soucasnou situaci kdy jen ovladace pro wifi na windows maji velikost 100MB.
-
Tak jsem nabootoval linuxovou distribuci brutusware ktera byla na dvou 3,5" disketach. A na techto 2 disketach byl kompletni operacni system vcetne weboveho prohlizece links a normalne jsem to pouzival!!
Brutusware jsem s oblibou používal také a vystačil jsem si s tou první disketou, která se po nabootování dala vytáhnout.
-
Ve skutečnosti to pro uživatele není priorita. Get over it.
Spis uzivatel kolikrat nema na vyber, tak se spolehne na radu odborniku a ti rikaji, ze si ma koupit vykrmenejsi pocitac.
Kdyby po té úspornosti uživatelé skutečně masově toužili...
-
Šikovný vývojář vezme z knihovny jen ten datetime picker. Jenže to se dnes nenosí.
To záleží na šikovný vývojáře té knihovny, jestli jde v lepším případě vytáhnout jeden widget nebo v horším případě widget + nějaké jádro. Taky knihovna sešpagetovaná tak, že bude rychlejší napsat widget na zelené louce než se ho snažit izolovat.
-
Vetsinu objemu tvori multimedia.
1. Udelas mobilni apku a chces aby hezky vypadala od mobilu s displejem 480x320 po tablety s 4K. Na zoomovani spoleh neni tak nasekas tu samou grafiku pro 5-6 nejbeznejsich rozliseni.
2. Pak tam potrebujes mit cache na reklamy pro pripad, ze je BFU mimo internetu tak mu je budes sekat z kese jen tak pro konzistentni user experience :-) A nejlepsi reklamy jsou pulminutove full screen videa, podle moznosti opet v 2-3 rozlisenich.
3. Nebudespredse programovat to samy pro 4 platformy. Tak to udelas na webovem jadre a tudis si pribalis vlastni Chrome protoze na verzi co ma BFU spoleh take neni.
4. Protoze poradne programovat v JS chce leta praxe tak si to zjednodusis nainstalovanim 4-5 frameworku z ktreych pochopitelne pouzivas tak 10% funkcionalit.
No uz mame 150 mega ne ?
-
Vůbec nevím, o čem se tu dohadujete. Já s velikostí programů problém nemám... Program mojí mikrovlnky má 8kB a to jen proto, že obsahuje debug po seriový lince. Bez něj by měl 5kB. Z toho docela velkou část tvoří pole s hodnotama pro výpis číslic na čtyřmístnym sedmisegmentovym LED dipleji... Mluvím o Arduinu.
Teď zrovna píšu v Pythonu program pro MP3 vlastní výroby (postaveno na RPi). Předpokládaná velikost bude v řádu kilobajtů. Ano, potřebuje pro svůj běh pár modulů, MySQL (Maria) databázi a X server, ale to mi tak nevadí, pořád se pohybujeme v normální velikosti.
A teď tedy k věci - Mám doma starý mobil, v něm CyanogenMod 7.1 (tuším), což je Android 2.3 (oficiální ROM uměla jen do 2.1). Má 528MHz CPU, 128MB RAM a tusím, že kolem 190MB prostor na aplikace. Pravda, hry mám nainstalované na kartě, ale navigace se v pohodě vešla do telefonu a ještě zbylo místo... Telefon fachá úplně v pohodě, jen na navigaci ho postrkuju na 600+MHz (rychlejší výpočet trasy/objížďky). Samozřejmě ho už nepoužívám, protože na dnešní nabubřelost webů nestačí a na nové aplikace nemám místo. Nicméně v té době na tom šlapalo vše v pohodě a aplikace i v jejich "předpotopní" podobě (s čímž šla v ruku velikost, tedy v tomto případě spíše maličkost) dělaly, co měly...
Dnes má mobil vnitřní pamět 8GB a nestačí to na nic. Proč? 3,5GB systém, aplikace v lepším případě každá několik desítek MB, některý i stovky... Data aplikací lze ukládat jen do vnitřní paměti telefonu (Android verze 4.4.x a 5.x, s nejnovějším nemám zkušenosti a ani o ně nemám zájem), na kartu ne, takže možnost zlepšení stavu bez investice do telefonu přesně 0. Návrháři mobilů jsou prasata (malá paměť), vývojáři jsou prasata (nenažraný; nenažraný aplikace) a největší prase se sám Google, který zakázal aplikacím "ne-od-google" zápis na kartu.
No, odplivnul jsem si a jsem spokojený, že mám ještě ten starý mobil se starými aplikacemi, které i ve velikosti maximálně několika MB uměly to, na co je dnes potřeba více než 10x tolik (místa na disku, paměti RAM i rychlosti CPU).
A ještě přidávám otázku - Proč někdo umí v několika stovkách MB dát dohromady celý OS a jinému to stačí sotva na aplikaci, která navíc uživateli nedá nic extra? Ten OS poběží na 128MB RAM, aplikace se bez 1GB ani nespustí...
Lidé, kteří pracovali na prvních počítačích (řekněme těch, které už nezabíraly celou místnost) si musí dnes klepat na čelo, do jaké zadeke se svět obrátil... Sice se všechno vejde do krabice od bot (pokud počítáme klasický desktop a ne embedded nebo různé mini věci), ale zatímco dřívě běžel systém z jedné diskety, dnes už nestačí pomalu ani DVD...
-
@Pavouk106
No vracet se do těch časů bych nechtěl. Jinak ta velikost je důsledkem základního pravidla Unixu - dělej málo a dělej to dobře. Pak vznikají závislosti závislostí a velikost aplikací roste. Špagetový kód je úspornější, proto taky aplikace dříve zabíraly méně místa. Dnes není tolik důležitý rychlý běh aplikace, nebo její hw nároky, ale její rychlý vývoj a snadná údržba. A to něco stojí.
-
@Pavouk106
Jinak ta velikost je důsledkem základního pravidla Unixu - dělej málo a dělej to dobře. Pak vznikají závislosti závislostí a velikost aplikací roste.
Kdyby se této zásady drželi autoři knihoven a frameworků, bylo by to fajn. Unixové utility se toho drží a proto se tak snadno píší shellové skripty, které vůbec nejsou líné.
-
A prečo je toto vlákno fóra stále dlhšie a väčšie, aj keď bolo všetko už povedané/napísané?
-
A prečo je toto vlákno fóra stále dlhšie a väčšie, aj keď bolo všetko už povedané/napísané?
Ale to je jednoduché, je to dáno počtem příspěvků na stránku, nikdo nečte diskusi celou ale jen aktuální stránku. Pro mnoho lidí pak existuje jen to, co je na poslední stránce.
Paměť kolektivu je relativně krátká, poznatky v čase zvětrávají a nejsou-li obnovovány, jsou zapomenuty. (viz algoritmus ACO)
-
@Pavouk106
Jinak ta velikost je důsledkem základního pravidla Unixu - dělej málo a dělej to dobře. Pak vznikají závislosti závislostí a velikost aplikací roste.
Kdyby se této zásady drželi autoři knihoven a frameworků, bylo by to fajn. Unixové utility se toho drží a proto se tak snadno píší shellové skripty, které vůbec nejsou líné.
Ano, ale musíte k nim přibalit celý Unix.
-
Ano, ale musíte k nim přibalit celý Unix.
Ja pamatuji jednodisketovy QNX tak az tak velky to nebude :)
-
Ano, ale musíte k nim přibalit celý Unix.
Ja pamatuji jednodisketovy QNX tak az tak velky to nebude :)
No ano, uděláte knihovnu pro QNX 1.0, v aplikaci ale potřebujete i jinou knihovnu pro QNX 2.1 a rázem už přibalujete diskety 2. Ta redundance je daň za snadnou údržbu na aplikační úrovni.
-
@Pavouk106
Jinak ta velikost je důsledkem základního pravidla Unixu - dělej málo a dělej to dobře. Pak vznikají závislosti závislostí a velikost aplikací roste.
Kdyby se této zásady drželi autoři knihoven a frameworků, bylo by to fajn. Unixové utility se toho drží a proto se tak snadno píší shellové skripty, které vůbec nejsou líné.
Ano, ale musíte k nim přibalit celý Unix.
Unix je dost miniaturní systém.
-
@Pavouk106
Jinak ta velikost je důsledkem základního pravidla Unixu - dělej málo a dělej to dobře. Pak vznikají závislosti závislostí a velikost aplikací roste.
Kdyby se této zásady drželi autoři knihoven a frameworků, bylo by to fajn. Unixové utility se toho drží a proto se tak snadno píší shellové skripty, které vůbec nejsou líné.
Ano, ale musíte k nim přibalit celý Unix.
Celý ne, stačí jen použité závislosti. Balíčkovací systémy se už postarají. Jsem pro minimalizaci závislostí a Unix je má minimalizované dostatečně. Vynalézat kolo opravdu smysl nemá. Pokud si někdo chce minimalizovat i linuxové jádro, tak se to dá poměrně snadno.
David Grudl měl původně svůj framework jako velký moloch. Poté prozřel a rozdělil ho do několika nezávislých miniframeworků, které si programátor prováže dle svých potřeb. Frameworku to významně prospělo.
-
Unix je dost miniaturní systém.
To je dost odvazne tvrzeni.
-
Kdyby po té úspornosti uživatelé skutečně masově toužili...
Rekl bych, ze nikoho nebavi porad vyhazovat funkcni pocitace jen proto, ze nejaky debil 3x nafoukl nove Widle a k tomu nafoukl Office tak, ze jsou vetsi nez predchozi Widle. Pricemz to dela v podstate jen porad to same a stejne pomalu.
-
Prostě dnešní doba je taková - plýtvá se zdroji, plýtvá se energiemi. Mně zase vždy fascinuje když vidím na nádraží obrzovku s jízdním řádem. Mimochodem - dřív na to stačil (a na spoustě nádraží stále stačí) papír. Ta věc umí je ukázovat tabulku s jízdním řádem nebo řazení vlaku, jinak nic. Čekal bych že po hardwarové stránce to bude nějaké RPi a ta tabulka bude vykreslovaná přímo do grafické konzole. Ale to ne, ta věc běží na Windows, je tam kompletní desktopové prostředí a spuštěná fullscreen aplikace jizdnirad.exe. Kolik ten krám žere ani nechci vědět. A tak je to se vším, a nikoho to nesere. >:(
-
Prostě dnešní doba je taková - plýtvá se zdroji, plýtvá se energiemi. Mně zase vždy fascinuje když vidím na nádraží obrzovku s jízdním řádem. Mimochodem - dřív na to stačil (a na spoustě nádraží stále stačí) papír. Ta věc umí je ukázovat tabulku s jízdním řádem nebo řazení vlaku, jinak nic. Čekal bych že po hardwarové stránce to bude nějaké RPi a ta tabulka bude vykreslovaná přímo do grafické konzole. Ale to ne, ta věc běží na Windows, je tam kompletní desktopové prostředí a spuštěná fullscreen aplikace jizdnirad.exe. Kolik ten krám žere ani nechci vědět. A tak je to se vším, a nikoho to nesere. >:(
No jen ji neumí využít, u nás na nádraží tam ukazuje i aktuální zpoždění vlaku. Mohla by ukazovat i obsazenost jednotlivých vlaků, ovládat by se mohla zrakem a pohledy kolemjdoucích, to je pole neorané pro AI. Váš zrak by utkvěl pohledem na ikonce obsazenost vlaku a tabule by ji na pár sekund zobrazila po vozech i s předpokládanými výstupy ve vaší stanici.
Vše záleží jen na fantazii vývojářů. A ta je mizerná, protože jsou svazováni technologiemi, které se pracně naučili a nic jiného se už učit nechtějí, protože do toho naučení příliš investovali.
-
Prostě dnešní doba je taková - plýtvá se zdroji, plýtvá se energiemi. Mně zase vždy fascinuje když vidím na nádraží obrzovku s jízdním řádem. Mimochodem - dřív na to stačil (a na spoustě nádraží stále stačí) papír. Ta věc umí je ukázovat tabulku s jízdním řádem nebo řazení vlaku, jinak nic. Čekal bych že po hardwarové stránce to bude nějaké RPi a ta tabulka bude vykreslovaná přímo do grafické konzole. Ale to ne, ta věc běží na Windows, je tam kompletní desktopové prostředí a spuštěná fullscreen aplikace jizdnirad.exe. Kolik ten krám žere ani nechci vědět. A tak je to se vším, a nikoho to nesere. >:(
A za chvíli co teprve funkční roboty jen proto, že mají technologickou nadváhu a tolik toho nevydrží.
-
Kolik ten krám žere ani nechci vědět. A tak je to se vším, a nikoho to nesere. >:(
v porovnání s tou obrazovkou asi moc ne.
-
Kolik ten krám žere ani nechci vědět. A tak je to se vším, a nikoho to nesere. >:(
v porovnání s tou obrazovkou asi moc ne.
A proč se na takovéhle zobrazovače nepoužívá technologie e-ink? Je v tom nějaký technický problém, že tak velká nejde vyrobit, nebo je to jen o tom že se to tak nikdy nedělalo?
-
Kolik ten krám žere ani nechci vědět. A tak je to se vším, a nikoho to nesere. >:(
v porovnání s tou obrazovkou asi moc ne.
A proč se na takovéhle zobrazovače nepoužívá technologie e-ink? Je v tom nějaký technický problém, že tak velká nejde vyrobit, nebo je to jen o tom že se to tak nikdy nedělalo?
Stoji to nekomu resit za tu namahu?
-
Kolik ten krám žere ani nechci vědět. A tak je to se vším, a nikoho to nesere. >:(
v porovnání s tou obrazovkou asi moc ne.
A proč se na takovéhle zobrazovače nepoužívá technologie e-ink? Je v tom nějaký technický problém, že tak velká nejde vyrobit, nebo je to jen o tom že se to tak nikdy nedělalo?
železnice i samotné nádraží spotřebují ohromné množství energie. Spotřeba cedule nehraje vůbec žádnou roli. Tam jde hlavně o snadnst realizace a z toho plynoucí spolehlivost. Čím méně času strávíte programováním, tím více času máte na testování.
-
Unix je dost miniaturní systém.
To je dost odvazne tvrzeni.
Skor uz neaktualne.
-
Ve skutečnosti to pro uživatele není priorita. Get over it.
Spis uzivatel kolikrat nema na vyber, tak se spolehne na radu odborniku a ti rikaji, ze si ma koupit vykrmenejsi pocitac.
Kdyby po té úspornosti uživatelé skutečně masově toužili...
A kdyby touzili po nedomrdane D1 tak je taky opravena, vid...
-
Prostě dnešní doba je taková - plýtvá se zdroji, plýtvá se energiemi.
Čas je taky zdroj. Ne že bychom se neshodli v tom, že jsou lidé pěkně rozežraní.
-
Ve skutečnosti to pro uživatele není priorita. Get over it.
Spis uzivatel kolikrat nema na vyber, tak se spolehne na radu odborniku a ti rikaji, ze si ma koupit vykrmenejsi pocitac.
Kdyby po té úspornosti uživatelé skutečně masově toužili...
A kdyby touzili po nedomrdane D1 tak je taky opravena, vid...
Protoze liniove stavby maji uplne stejne naklady na vstup na "trh" jako apky.
-
Je jedno, jestli mluvím o klasických PC nebo mobilech.
Su tri "zakony"
1. Moorov zakon, pocet tranzistorov na jednotku plochy sa kazdych 12-24 mesiacov dvojnasobi.
- co v prenesenj forme znamena, ze vykon pocitacov sa zdvojnasobi za rovnaky cas, alebo, ze kapacita pamate sa zdvojnasobi za rovnaky cas..
2. Gatesov zakon - komercny softver sa spomali o 50% kazdych 18 mesiacov
3. Wirthov zakon - Softver sa spomaluje rychlejsie ako sa hardver zrychluje.
- v prenesenej forme podla Vas znie: ze velkopst softveru sa zvacsuje rychjesie ako sa zvacsuje kapacita pamate...
A dovod je, ze vdka tomu je dopyt po produktoch, rastu predaje a teda ekonomika zainteresovanych firiem zije...
pamatame si legendu
Výrobci pamětí jsou zklamaní z Windows 8, jsou málo náročné
Karel JavůrekKarel Javůrek 28. října 2012
IHS zveřejnilo procentní zvýšení poptávky po operačních pamětech u starších systémů Microsoftu:
Windows 3.1: +29 %
Windows 95: +23 %
Windows 98: +40 %
Windows 2000: +49 %
Windows XP: +41 %
Windows Vista: +26 %
Windows 7: +18 %
Windows 8: +8 % (odhad)
https://www.zive.cz/bleskovky/vyrobci-pameti-jsou-zklamani-z-windows-8-jsou-malo-narocne/sc-4-a-166096/default.aspx (https://www.zive.cz/bleskovky/vyrobci-pameti-jsou-zklamani-z-windows-8-jsou-malo-narocne/sc-4-a-166096/default.aspx)
On je rovnaky dovod, preco OEM vyrobcovia nasadzuju masovo GNU/Linux.. :}
-
Pamatuju si jak v roce 2007 kdyz jsem jeste pracoval ve vyrobnim podniku a na PC jsme nemeli povoleny internet a IP adresu jsem si nemohl zmenit protoze sem nemel admina. Tak jsem nabootoval linuxovou distribuci brutusware ktera byla na dvou 3,5" disketach. A na techto 2 disketach byl kompletni operacni system vcetne weboveho prohlizece links a normalne jsem to pouzival!! Je to smutne to porovnat se soucasnou situaci kdy jen ovladace pro wifi na windows maji velikost 100MB.
No ale v roce 2007 už byly počítače strašně rozežrané, na takovém PDP-10 jelo 5 terminálů a samotný počítač měl operační paměť jen 128 kB. Hardisk měl kapacitu 5MB :-))) Ale elektriky to žralo mnohem více.
http://kormus.cz/mvt/pocitace/smep_system_malych_elektronickych_pocitacu.php
-
Ve skutečnosti to pro uživatele není priorita. Get over it.
Spis uzivatel kolikrat nema na vyber, tak se spolehne na radu odborniku a ti rikaji, ze si ma koupit vykrmenejsi pocitac.
Kdyby po té úspornosti uživatelé skutečně masově toužili...
A kdyby touzili po nedomrdane D1 tak je taky opravena, vid...
Protoze liniove stavby maji uplne stejne naklady na vstup na "trh" jako apky.
Sehnat zakazku na ofiko appku pro BurgerKing bude podobny jako na tu D1 :)
-
Nečetl jsem celou diskusi, tak se omlouvám, jestli řeknu něco co už tu padlo, ale IMHO spousta uživatelů podlehla přesvědčení , že to je prostě vývoj, že to tak (holt) musí být. Navíc mnoho dnešních uživatelů nezažilo ty dávné doby omezenosti HW, optimalizací na kost a ani je nenapadne, že by ta samá apka mohla být třeba o řád menší a úspornější.
-
Nečetl jsem celou diskusi, tak se omlouvám, jestli řeknu něco co už tu padlo, ale IMHO spousta uživatelů podlehla přesvědčení , že to je prostě vývoj, že to tak (holt) musí být. Navíc mnoho dnešních uživatelů nezažilo ty dávné doby omezenosti HW, optimalizací na kost a ani je nenapadne, že by ta samá apka mohla být třeba o řád menší a úspornější.
Ty apky jsou optimalizovány na kost, ale podle jiných optimalizačních kritérií. Například snadnosti a rychlost vytvoření. A vývojáři k tomu byli dotlačeni trhem. Až nebude stačit hw, tak je trh zase dotlačí k něčemu jinému. I ty, co se tomu budou vzpírat.