Americký výrobce čipů Intel propustí 15 procent zaměstnanců (en), do konce roku by jich v podniku mělo pracovat zhruba 75.000. Firma se potýká s výrobními problémy a opouští také miliardový plán na výstavbu továrny v Německu a Polsku.
MDN (Wikipedie), dnes MDN Web Docs, původně Mozilla Developer Network, slaví 20 let. V říjnu 2004 byl ukončen provoz serveru Netscape DevEdge, který byl hlavním zdrojem dokumentace k webovým prohlížečům Netscape a k webovým technologiím obecně. Mozille se po jednáních s AOL povedlo dokumenty z Netscape DevEdge zachránit a 23. července 2005 byl spuštěn MDC (Mozilla Developer Center). Ten byl v roce 2010 přejmenován na MDN.
Wayback byl vydán ve verzi 0.1. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána nová verze 6.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově se lze k síti Tor připojit pomocí mostu WebTunnel. Tor Browser byl povýšen na verzi 14.5.5. Thunderbird na verzi 128.12.0. Další změny v příslušném seznamu.
Meta představila prototyp náramku, který snímá elektrickou aktivity svalů (povrchová elektromyografie, EMG) a umožňuje jemnými gesty ruky a prstů ovládat počítač nebo různá zařízení. Získané datové sady emg2qwerty a emg2pose jsou open source.
Byla vydána (𝕏) nová verze 25.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 25.7 je Visionary Viper. Přehled novinek v příspěvku na fóru.
Před 40 lety, 23. července 1985, společnost Commodore představila první počítač Amiga. Jednalo se o počítač "Amiga od Commodore", jenž byl později pojmenován Amiga 1000. Mělo se jednat o přímou konkurenci počítače Apple Macintosh uvedeného na trh v lednu 1984.
T‑Mobile USA ve spolupráci se Starlinkem spustil službu T-Satellite. Uživatelé služby mohou v odlehlých oblastech bez mobilního signálu aktuálně využívat satelitní síť s více než 650 satelity pro posílání a příjem zpráv, sdílení polohy, posílání zpráv na 911 a příjem upozornění, posílání obrázků a krátkých hlasových zpráv pomocí aplikace Zprávy Google. V plánu jsou také satelitní data.
Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Byla vydána nová verze 2.4.65 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2025-54090.
Řešení dotazu:
svnadmin create
Kdo k němu může: při HTTP(S) exportu (který doporučuji) se to nastavuje v Apache, stačí hledat „apache svn konfigurace“
svnadmin --help
a pak Vás asi napadne svnadmin create --help
a pak by mělo svnadmin create /var/svn/repository/firstrepo
(cestu jsem si vymyslel)./var/svn/repository/firstrepo/conf/authz
,kde si asi upravíte něco jako
[/] * = r franta = rwa pak najdete
/var/svn/repository/firstrepo/conf/passwd
kde asi upravíte něco jako
[users] * = r franta = frantovoHesloA repository je vytvořená, pro přístup všem read-only a write pro franta z hesle frantovoHeslo.
/usr/bin/svnserve -d -r /var/svn/repository/
, což si předem nastudujete z man svnserve
svn list svn://localhost/firstrepo --username franta
což si zase lehce nastudujete pomocí svn help
a svn list --help
.svn prikaz svn://jmeno-nebo-ip-serveru/firstrepo --username franta
[/] r = franta = rwz restartnút svnserve(fčul nevím jestli je to nutné) jak to zareaguje.
[users] franta = frantovoHeslo
anon-access = none auth-access = write authz-db = authz password-db = cesta na passwd soubor danné repository
/svn/repositories/
podle authz, který by měl být spolu s passwd v /svn/repositories/conf/ máte povolen přístup uživateli 'dark'. Ty mezery na začátku řádku před těmi volbami (password-db, authz) v svnserve.conf bych odstranil (nevím jestli to má význam jen z principu)takže mám zkusit například GIT nebo Hg ?To můžu jen velmi důrazně doporučit :).
V SNV je jednodušší se naučit základní používání než git.Ani bych neřekl... možná tak se smířit s indexem, nebo si zapamatovat příkazy, které ho zpracovávají automaticky.
Ale když se člověk do gitu trochu dostane, dívá se zpět a říká si, jak jsme si mohli s tím svn vystačit :)To si ale řekne člověk s nízkými požadavky. Člověk, který kdy chtěl pracovat offline, nadává na SVN od té doby, co s ním poprvé offline pracoval, o větvích a dalších možnostech ani nemluvím :).
Nastavení pravidel komunikace mezi vývojáři dělajícími na stejných sdílených větvích už není tak triviální a nějakou dobu nám trvalo, než si to sedlo. Ale záleží na modelu vývoje.Tak, existují i jednoduché modely.
Instalace GITu na server není složitá, viz např. gitosis. A nebo v případě open sourcu jít třeba na github a nic neřešit?gitosis je nástroj na pohodlnou správu více gitových repozitářů, na dva-tři repozitáře bych se nebál použít samotný git.
Záleží na Vás, svn je nejednodušíMě přijde spíše složitější a méně užitečné... ve smyslu, některé věci mé denní potřeby tam jdou složitě, jiné vůbec.
Nejsem si jist, jak je na tom git s verzováním binárek, zda umí řešit jejich diffy, nebo každou verzi bere celý soubor.Git binárky a textové z hlediska uložení nerozlišuje.
To by se to pak mohlo pěkně nafukovat a nechtěl bych takový repozitář klonovat.Tak binárky mají tendenci se nafukovat bez ohledu na správu verzí, změny v nich často nebývají lokálního charakteru.
Důvod mého dotazu je ten, že jsem tak před rokem četl diskusi, kde srovnávali git a komerční perforce, kde přišlo mi že znalci obého tvrdili, že např. pro kreativní agentury se git nehodí, protože verzují v podstatě jen binární data a git údajně není pro verzování velkých binárních souborů nijak optimalizovaný.Ona to taky ještě před nějakou dobou byla pravda. Neznám detaily, ale o optimalizaci na binární data v gitu jsem četl něco z mailing listů.
Narozdíl od perforce, který se prý v těchto firmách právě z důvodu efektivního verzování velkých souborů používá. Možná se od té doby leccos změnilo.Git nemá žádné omezení, které by mu bránilo pracovat s binárními daty a ukládat je efektivně. Jak efektivně nakládá s velkými (obvykle binárními) soubory je jiná věc, a na mailinglistu se psalo o změnách (optimalizacích), které to měly zlepšit. Benchmarky jsem nedělal a nikde nemám potřebu udržovat v gitu desítky/stovky gigabajtů, abych něco takového musel řešit.
Tiskni
Sdílej: