Portál AbcLinuxu, 26. prosince 2025 18:49
U příležitosti oslav sedmi let prací na debianím balíčku vyšlo GPXSee 13.33. Nová verze přináší rychlejší vykreslování vektorových map a vylepšení/doladění nového stylu pro OpenAndroMaps/Mapsforge mapy. Kdo by rád OSM mapy v "prémiovém" barevném schématu a nechce čekat až nová verze dorazí do jeho distribuce, nalezne zdrojové kódy na GitHubu.
Tiskni
Sdílej:
Na webu je podobných aplikací spousta, cílem je právě mít něco rychlého "lokálního". U prohlížení několika GB map si pak posílání na web nedovedu představit vůbec (co vím, tak přístup k lokálním souborům v prohlížeči spíš nefunguje, než funguje...).
Co se týče Maců, tak ty oficiální buildy se samozřejmě testují, ale jsou jenom x86-64, protože zájem uživatelů nestačí ani na nákup ARM železa... Pro ARM to nicméně balíčkují Macports, ale jak dobře jim to funguje netuším, neb to nemám na čem vyzkoušet.
Dokud byly Macy na x86 tak byl hackly MacOS co bezel ve vmweare nebo v KVM
a tam to lidi ladili, Apple ma takovou hnusnou politiku, ze kdyz treba chcte vyvijet pro iPhone, musite mit MacOS, jinak zadna emulace, zadne ladeni atd. ... u nas na to kupuji Macy, mame jak stanice na siti, tak lidi maji MacBookPro a jednou to na nich.
a skoro cely userspace v terminalu je GNU
... treba u nas muzu mkt bud WIndows, nebo MacOS ... jsou lidi co chteji Linux, ale sec. tym jim zkryplil serverove ubuntu !!! do ktereho jim dal MS Antivirus a nejakou MS Proxy a dotazy na vse nekde do MS cloudu a zvykonneho PC jim udelali kalkulacku ...
Tak to uz si radeji vezmou Maca nebo win s moba xterm ... a nechaji si na vmware udelat virtualku
)
... pak kde co lanamanger a ted rapis7security - coz je podle me dira do OS, nebot je to deamon bezici pod OS, ale zase to reportujer, zda je OS aktulizovan centralni konsoli ... umi to tez grafana ...
U RHEL i fedory to umi treba Satelite - nastroju je vice, umi to reportovat i samotny package managemnt, co jsou secure patche ... a nebo uplne nasprosto auto-upgrade - umi jak yum, dnf, tak i apt ... a jine distra ... cest je tedy mnoho vcetne centralni konsole, u nas to dela pro nas grafana a pro sec. tym to dela rapid7 ... hlavne servery, ale linux testuji taky, jen jim rikam, hele hosi neblbnete, povolte selinux, antivir netreba, rapid7 - OK ...
Na MacOS maji Jamf-pro - coz je sranda, neni to od Apple, ale tak integruje se to s AD a funguje to
... u Linuxu je dobre povolit 10-2 distro, idelane asi Fedoru - ta ma nejlepsi ingeraci do korporace, castecne Ubuntu - to ma tez nejakou integraci - ale ta optavdu dobra je placena
...i SUSE ma centralni management, drazsi nez Satelite
BTW - u virtulaizovanych RHEL lze zaplatit za unlimited snaz 1k euro nebo 2k euro + snad 1k euro za satelite - s tim, ze mate virt. severy v jednom VC, beztak by neresili ani desktopy s tim, ze nemate support
... teda efektivne mate nejaky opensource support ve verejnem bugtraku, kde muzete reportovat chyby, ale nemate garanci ani casu, ani vyreseni ... navrhoval jsme to filme pro servery, ze by jem presli z CentOS na RHEL ... pry Alma Linux ... za me je umho lepsi Rockylinux - proc ? proze sere na RHEL a dava tam nutne veci co ma Oracle
treba BTRFS ze ... jeden server totiz nutne potrebuje deduplikaci a kompresi ... ono to teda dela i diskove pole a az nam vyrobce tvrdil, ze se to do licence nezapocitava, tak jsme zjistili, ze to neumi zjistit a takl zjistuje jen relne obsazeni diskoveho pole ... mame 1PB pole s tim, ze nekde mame licenci na 1PT ... a kdyz tam dame 2.5PT s kompresi tak OK a pak kde mame licenocvabno jen 500TB a nebo 750TB - a tam to ma byt pry bez komprese i kdyz ji pouzivame, ale uz davnio jsme to presvihli a vyrobce nic nerika a nic nechce
... asi sami nevedeli, myslim, ze by se ozvali az by jsme to prekrocili fyzicky - mozna je to soucast slevy kdyz jsme tech poli vzali 6 najednou
... i IBM maji fedoru a RHEL jako firmeni volbu.
U nas bylo firmeni UBUNTU a pak navody jak co rozbehnout, plno lidi ale jelo Fedoru jako ja - firma se pro ISO audit tvraila, ze to nevi
- a ano kazdy si to aktulizoval jen jsme u notebooku slibili, ze budem pouzivat sifrovani, LIKS mam i na soukomych noteboocich a domacim PC - nikdy nevite, kdyz vam to kdo ukradne, domaci PC vetsinou krade police CR
Firma sice keca, jak vse hlida, ale jen co to neni ukecany windows, co neustale na siti brodcastuje ahhoj, ja jsme ten a ten, jsme tady a nejsem v AD, ale workgrupe - tak ten najdou, kdyz mate linuix, co na siti drzi hubu a jen dela to co ma, tak nepoznali nic, i kdyz jsme z domeny bral kerberos tikety a autentikooval pres lokalni kerberos webove apky - ktere to SSO vyzadovaly a neslo se tam prihlasit jinak ... staci to povoliit v browseru ze jim duveruji, udelat si krb5.conf a spustit obcas kinit USERNAME a prihlasit se ... ani pote to nezjistili ...
Az kdy se s nama bavil sekuritak, tak zjitil, ze tam mame svoje notebooky
- tak jen rikal, zda to mam sifrovane a ze si to mame upgradovat ... ukazali jsme mu, ze mame sifrovani a byl happy .. zase komu jinemu verit, nez senior architektum
umí to zobrazit openseamap?
Kdo by rád OSM mapy v "prémiovém" barevném schématu a nechce čekat až nová verze dorazí do jeho distribuce, nalezne zdrojové kódy na GitHubu.Což krom pár geeků reálně nikdo neudělá. Fajn by byl spíše (oficiální) Flatpak.
pár dní, než se objeví v jejich distribuciCož je třeba v případě Ubuntu půl roku (či dva roky u LTS).
Tak to přidej. V Ubuntu, stejně tak jako v čemkoliv jiném založeném na Debianu, je to minimálně 7 let a odpočet stále běží...
Nicméně to je volba těch lidí, co si Debian(Ubuntu) vybrali a pokud jim to tak vyhovuje, je to jejich věc. Pokud s tím mají problém, vždycky můžou zvolit nějakou moderní distribuci. Distribuce vhodné k provozování moderního desktopu mají to zpoždění v úplně jiných řádech. Představa, že celý svět bude produkovat nějaký pseudobalíčky typu Snap, Flatpak či AppImage jenom proto, že Debianistům (a jejich příbuzným) trvá "normální" distribuce SW roky, je prostě zvrácená.
Nejsou aplikace instalované z repozitářů třetích stran potenciálně rizikovější než ty typu flatpak umožňující jejich sandboxing?
Nejsou. To si myslí akorát lidé, kteří vývojářům říkají: "Já si od tebe rád zadarmo vezmu výsledek tisíců hodin tvé práce, ale stejně si myslím, že jseš zmrd a chceš mě ojebat!". Reálně jsou staticky linkované aplikace (nebo jejich hipsterské alternativy) mnohem děravější a zabugovanější, protože knihovny v nich nikdo neupdatuje.
Co je kritériem rozhodujícím o špatnosti popsaných řešení?
Velikost, rychlost a aktuálnost použitých knihoven.
Co brání autorům vydávat periodické statické buildy z prostředí postaveném na posledních verzích (budeme předpokládat těch se známými zranitelnostmi opravenými) potřebných knihoven (samozřejmě pokud to kompatibilita src dotyčného programu unese)?
Nemají na to prostředky.
Pokud koncový uživatel periodicky ověřuje existenci novější verze programu v repository, mělo by se mu tak dostat bezpečnějšího produktu. Možná dokonce v předstihu než tyto verze knihoven uvolní (případně záplaty backportuje) jeho OS distribuce a to včetně těch s rolling release.
Jistě, teoreticky taková situace může nastat. Ale prakticky (statisticky) se to neděje a těžko předpokládat, že tuto duplikaci práce distribucí najednou začnou vývojáři s nadšením dělat jenom proto, že to tobě přijde jako skvělý nápad. To že jsme se v Linuxu dostali od "statické" prehistorie k současnému stavu distribuce balíčků má své dobré důvody.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.