Na serveru je nejvĕtším lákadlem jednoznačnĕ LXC 2/LXD. Klasické kontejnery (LXC 1) jsem používal už dřív, ale LXD je opravdu skvĕlý software a i způsob, jak v Xenialu integrovaný do distribuce, si zaslouží chválu, i když má samozřejmĕ svoje mouchy a nedodĕlávky. Je to koneckonců první ostré vydání. Sám často na Canonical nadávám, ale v tomto případě rád a upřímně smekám.
Ne, samozřejmě jsem to zkoušel dvakrát, pokaždé ta stejná chyba.
Pokud nemají odladěnou ani tak základní věc, jako je stažení image, na FS, který se mi nabídl jako výchozí (čili to zřejmě vůbec netestují, nebo nevím), nemůžu to nasadit. LXC se naštěstí zdá jakžtakž fungovat, takže se dá zůstat u něj.
Ubuntu 16.04 testuji již od early alpha verze a zatím jsem z něj spíše zklamaný. Hromada neopravených bugů, ať už kosmetických chyb v GUI aplikací nebo vážnějších bugů, hromada balíků v dost starých, neaktualizovaných verzích (například Wine ve verzi 1.6, která je cca 3 roky stará a novější aplikace/hry v ní často nechodí) apod. Takhle si LTS vydání fakt nepředstavuji...
Stará verze Wine je škoda, to je pravda, ale LTS vydání jsou určena především firmám a profesionálním uživatelům, takže chápu, že to není hlavní priorita. Wine 1.8.x pro 16.04 je už mimochodem v PPA.
Mě osobně mrzí, že o fous zmeškali Network Manager 1.2, ale jinak mi 16.04 připadá - snad po dlouhé době - jako pěkné vydání. Na rozdíl od autora a zřejmě i od Vás bych ale řekl, že na LTS je možná skoro až moc dobrodružné. Fůra čerstvých technologií ve vůbec první integraci je trochu koledování si o problémy - LXD, Snap, ZFS, AMDGPU atd... to se všechno mělo nejdřív otestovat v 6ti měsíčních verzích a ne to nasadit ausgerechnet do LTS.
Jo a vážně byly v early alpha verzi nedořešené bugy? Tomu se mi fakt nechce věřit ;-)
Ja jsem dlouhodoby uzivatel Linuxu (od roku 97) a dnes po nem uz jen chci, aby dobre fungoval, nemam cas se v nem stourat jako zamlada. Konzervativni pristup ubuntu mi vyhovuje. Verze 14.04 me zklamala, je nestabilni, ma problemy s ftp a dokonce mi cas od casu zatuhne, takze se na 16.04 tesim a doufam, ze bude bez problemu.
Není to blábol. Ubuntu 14.04 opravdu trpí dlouhodobě problémem s připojením ftp/sftp z Nautilusu. Já to používám dost intenzivně a tak obden se mi stane, že spojení zatuhne, od serveru se nedá odpojit a je třeba ručně pozabíjet příslušné procesy a někdy dokonce i restartovat Nautilus.
Pokud bude tohle v 16.04 vyřešeno, budu nejšťastnější člověk na světě.
"Tenhle bug je i v mintu"
Vzhledem k tomu, že Mint používá balíčky Ubuntu, je to docela logické. Otázka je, jestli je ten problém i v upstreamové verzi. Upstreamové bugzilly jsou plné uzavřených bugů s vyjádřením "U nás dávno opraveno, dokopejte správce balíčku ve vaší distribuci, ať tam tu opravu aplikuje".
No docela by mě zajímalo vaše řešení, jak relativně pohodlně nahrát/spravovat/aktualizovat web na hostingový server s možností např. úpravy oprávnění na adresářích/souborech... Přesně k tomu byl FTP protokol navržen a to, že to už bylo dávno nic nemění na tom, že je stále velmi dobře použitelný, tudíž jeho existence má své opodstatnění. Stejně jako SMTP, IMAP atd.
Aby nedošlo k omylu, samozřejmě je řeč o přístupu na úrovni tvůrce/správce webu/webové aplikace, ne o správě obsahu.
Samozrejme, ze git. Jak treba pres to tvoje FTP poznas, ze nemas nejaky hack v nejakym souboru? Jak pres ftp "posles" jednoduse delete(jednoduse = tak abys na to nemusel myslet)? Jak resis kdyz na tom pracuje > 1 clovek? Jak resis (i kdyz tam mas 1 jedineho vyvojare) vyvoj vice features/bugfixes najednou?
Tazek za me: ne, FTP uz davno neni vhodne vubec na nic.
GIT se samozřejmě dá použít pro deploy aplikace na server a má na to přímo hook: "post-receive" a použije se proměná "git --work-tree". Samozřejmě FTP má ne 90 a 99% hostingů a zároveň nenabízí SFTP. Ale to nikdo neřeší. Ještě jsem nezažil firmu, kterou by to zajímalo. Naopak, ještě si hesla posílají mailem. Git deploy, jak jsme používali, je ideální na stejném stroji, ale dá se udělat i workaround přes FTP nebo SSH. Jestli si vzpomínám, používali jsme GIT deploy přes SSH.
FTP = file transfer protocol. To myslím hovoří za vše. Zcela jistě existují situace, kdy vyhovovat nemusí. Nicméně to, k čemu byl navržen a je používán (přenos souborů) dělá dobře a spolehlivě.
Nebo opravdu v situaci, kdy potřebujete nahrát na server jeden soubor nebo pár fotek, použijete git?
Nebo v situaci, kdy tam jednorázově nahrajete celý web (hotový, nemluvím o vývoji)? Nesmysl.
Ale jo, mailuje to na výbornou na milionech mailserverů. Nemá to totiž žádný problém s dynamickými porty, narozdíl od zoufalého FTP protokolu, který se stává ještě zoufalejším, pokud člověk použije k přihlášení a přenosu dat šifrovanou komunikaci, protože do toho firewall už nevidí vůbec a nenadělá s tím vůbec nic.
Tak samozřejmě všichni víme co je FTP. Osobně GIT deploy nepoužívám, používám takové "custom" scripty na deply a přes FTP/SFTP podle toho, co daný klient má/požaduje.
Pokud ale máte třeba managed server s GITem, pracujete v gitu a deploy máte nastaven přes SSH (třeba pokud nemáte možnost SFTP) a jenom si vyplníte cestu k webrootu, tak proč to nedělat deploy přes GIT?
"Nebo opravdu v situaci, kdy potřebujete nahrát na server jeden soubor nebo pár fotek, použijete git?"
To ale nikdo neřekl v tom vláknu pokud vím. To je nějaká vaše konstrukce, kterou jste sem vsunul.
"Nebo v situaci, kdy tam jednorázově nahrajete celý web (hotový, nemluvím o vývoji)? Nesmysl."
No, jednorázově nahrajete web. Hmmm, ano i takové situace jsou. Taky si musíte nastavit FTP a nebo jako to máte na localu, tak dáte do scriptu GITu cestu k webrootu a každý push do mastera se nahraje.
No jasně, běžně se to dělá přes FTP/SFTP i já to tak momentálně dělám. Určitě. Ale co je obvyklý případ? Webhosting, FTP, totalcommander a nejaký Sublime 3. Ale taky jsou firmy, kde mají 1/2/3 ... managed or selfmanaged servery + GIT, projekty v GITU a bez push do mastera nic nerealesují, a tam je dobrý ten git deploy třeba. A nebo třeba ne. Je spousta možností jak to dělat nebo nedělat.
Ale vybral jste si jednu z možností deploye a ostatní šmahem zavrhl. Tak to ale nefunguje ....
Pane bože!!!
Můj původní příspěvek k chybě v 14.04, kdy jsou problémy se stabilitou FTP ve znění:
"Není to blábol. Ubuntu 14.04 opravdu trpí dlouhodobě problémem s připojením ftp/sftp z Nautilusu. Já to používám dost intenzivně a tak obden se mi stane, že spojení zatuhne, od serveru se nedá odpojit a je třeba ručně pozabíjet příslušné procesy a někdy dokonce i restartovat Nautilus.
Pokud bude tohle v 16.04 vyřešeno, budu nejšťastnější člověk na světě."
se dostal až k deployingu projektů přes git.
Pro boha svatého, dělejte si co potřebujete jak potřebujete, já si to budu dělat taky tak, jak to vyhovuje mi, ale pokračovat v téhle nesmyslné diskuzi, kdy jeden mluví o voze a druhý o koze, fakt pokračovat nehodlám.
Dobrou noc.
Aha, no tak to jsi asi zapomenul na tento:
"No docela by mě zajímalo vaše řešení, jak relativně pohodlně nahrát/spravovat/aktualizovat web na hostingový server s možností např. úpravy oprávnění na adresářích/souborech... Přesně k tomu byl FTP protokol navržen a to, že to už bylo dávno nic nemění na tom, že je stále velmi dobře použitelný, tudíž jeho existence má své opodstatnění. Stejně jako SMTP, IMAP atd."
A pak se oz val ještě někdo . . . . . . . . Ale promiň, jestli má tvé vlákno nějaké pravidla, možná by nebylo špatné kdyby jsi to napsal dopředu. Třeba: "Kdo odbočí od tématu, tak já už nehraju"
Tak jako kdo dnes nepoužívá VCS, ideálně GIT, je tak maximálně bastlič. Ale třeba místo CI nástrojů lze použít něco jako tohle, je to FTP script https://phpfashion.com/ftp-deployment-nahravejte-pres-ftp-chytre když člověk nemá plně automatizovaný deploy
- co presne myslis tim, ze nemam zadny ssh? (napada me jen git pres http, ale tak zase nejsem padlej na hlavu)
- co myslis uber kanalem?
- ne, ne, ne. nemam duvod to delat. a druhak nemam moznost to delat - proste ten klic ktery tam mam tak ma nastaveny na serveru readonly. nemam duvod nekam chodit do nastaveni a davat mu full a pak zpatky kdyz push z develop stroje znamena, ze mi to CI probubla az na produkci.
Naopak aktuálne to vyzerá veľmi dobre- akurát staré karty sú hodené za hlavu..
Windows 10 Radeon Software vs. AMDGPU On Ubuntu Linux
Written by Michael Larabel in Operating Systems on 18 April 2016
http://www.phoronix.com/scan.php?page=article&item=amd-win10-amdgpupro&num=2
Ten progres oproti Vami citovanému How Ubuntu 16.04 Is Performing With AMDGPU/Radeon Graphics Compared To Ubuntu 14.04 With FGLRX
Written by Michael Larabel in Operating Systems on 15 March 2016.
http://www.phoronix.com/scan.php?page=article&item=ubuntu-1604-amd&num=2
Je až neuveriteľný
Podobne nemam ziadnu mechaniku skoro 2 roky chcel som si kupit externu ale dako nic tak som pred mesiacom zlikvidoval vsetky opticke media(az na dva do zbierky).
Absencia fglrx je skor vyhoda s open je o dost menej problemov a vykonovo su natom horsie len v niektorych hrach (tak 1/10) zato ich vykon je pomerne vyrovnany.
UBUNTU/Xubuntu/Kubuntu nepouzivam uz 3 roky (Debian/Arch/OpenSUSE to nahradilo) ale skusal som vo VB a ten wine 1.6 bola tiez jedna s veci co ma zarazilo(ale aspon funguje) a zdaleka nieje sam, mohli by uz aspon nefunkce SW, ktore je tam 2-4 roky(vtedy ho skopcili s debian experimental) zmazat (lepsi ziadny SW ako neudrziavany/nefunkcy casto nikdy nefungoval ani v predchodcoch skad eho skopcili)
Podobne voladace nvidia su tiez aktualne radsej ich tam nedat a na wiki odkaz na PPA (pripadne v help v OS odkaz na wiki) a bolo by to lepsie.
Já mám nový počítač z května 2015. A rozhodl jsem se tam přeci jen tu bluray mechaniku ještě dát. Je fakt, že jsem ji poprvé (a jedinkrát) použil až letos po Amperu, kde jsem si koupil pár ročníků amatérského rádia na CD (nebo to je DVD?). Takže jsem docela rád, že jsem tam tu mechaniku dal. Byť ten poměr cena/užitek je dost tragický.
to moc nechapu co tim myslis... nac nekolik ISO obrazu? jdu instalovat -> fouknu to na flashku. nainstalovano, mazu a pouzivam flash na jine veci. kdyz pak nekdy potrebuju instalovat tak stahuju fresh image a opakuju postup... je jasny, ze flash neni etalon spolehlivosti - ale na to neni urceny. nevidim nic spatnyho na tom kdyz clovek prijde o "mp3 v autoradiu", "image OS pro instalaci" apod. to vsechno jsou veci ktery lze v pohode natahnout znovu.
[Citation needed]?
http://www.videocardbenchmark.net/high_end_gpus.html
Já mám nvidii radši jak na Win, tak linuxu, ale může to být jen osobní preference ;)
lol ... nv vs ati je asi tak 30 vs 70%, ze se neco bude srat. A je jedno, jestli v tuxovi, kde ty problemy sou alespon pomerne znamy a specifikovany nebo ve widlich.
Ano, ATI (obcas, v nekterych generacich) dodava HW, ktery umi trochu vic a ma trochu zajimavejsi parametry. Jenze v globale je to jedno. A co je podstatny to sou problemy. Gamesku, ktera by mela problem s NV ... vidno jednou za uherak, zato s ATI ma problemy spousta games a defakto neustale.
Ja treba schvalne koupil R9 380x, protoze jsem proste nechtel nv. Bez problemu na openSUSE Tumbleweed s mesa + amdgpu od kernelu 4.5rc1 (kernel zacal mit podporu powerplay). Je pravda ze vykon je proti fglrx (potreba xorg downgrade) nizsi, ale v zasade to nevadi (cca -10%). Arch uz myslim kernel 4.5 ma, zkuste.
Já jsem na kombinaci ADM CPU + ATI Gfx fungoval už na přelomu tisíciletí. Vystřídal jsem za ty roky čtyři sestavy a vždy bez problémů. Až můj poslední počítač je Intel + nVidia. Na Intel jsem šel kvůli výkonu (i7 4790K, AMD nic podobného ani nevyrábí) a nVidia spíše ze zvědavosti.
Z hlediska spolehlivosti a problémů nepozoruji rozdíl. Výkon je někde jinde, ale to byla i cena.
Třeba já. Několik let zpátky jsem měl první generaci APU a byl jsem celkem spokojený (byť ne tolik jako s Intel HD teď, na tu nemusím vůbec myslet).
Kdybych chtěl připojit třetí monitor, bez váhání jdu pro Sapphire R5 230 FLEX, protože (1) na trhu nic jiného s pasivním chlazením a možností připojit tři monitory přes digitální výstup za ty prachy není, (2) open-source ovladač `radeon` je pro desktop naprosto bezproblémový (a v pohodě stačí i na tu spoustu starých her, které mě zajímají).
Nevite nahodou jak to vypada s Kubuntu? Na strankach je sice napsano ze vysla 16.04 Beta2 ale na prechod na neco co mozna nebude dotazene nemam koule. Premyslel jsem, ze bych presel na NEON, ale ten projekt je pro me hrozne necitelny a bojim se, ze skonci stejne jako Kubuntu. Je to skoda, protoze jsem si Kubuntu oblibil. Ale v posledni dobe me zacina KDE 5 resp. Plasma 5 pekne stvat a pomalu mi s KDE, ktere jsem mel tak rad, dochazi trpelivost.
Kubuntu 16.04 mam nainstalovano na notebooku asi uz 2 tydny a neni dotazene, je tam dost hloupych bugu (i na betu se mi to zda hodne). Asi nejvice mi vadi, ze kdyz se pripoji a odpoji externi monitor parkrat, tak to zblbne panel a nevim jak to resit bez logoutu. Panel nekdy i zmizne. Na to, jak je panel dulezita soucast prostredi, je to dost neprijemny bug. Window manager dost casto segfaultuje. Mozna se ty bugy brzo dockaji opravy, ale ze zkusenosti jak dlouho trvalo vyladit KDE4 bych to necekal.
Proti jiz odladenym KDE4 je Plasma5 dost velky krok zpet. Prechod bych tedy nedoporucoval.
No tak já jedu na 15.10 takže vím co od zabudované plasma 5 čekat. Na ten panel pomáhá zabít plasmashell a pak ho znovu spustit z konzole nebo krunneru. Co mě ale nejvíc štve je nefunkční krunneru to prostě člověk nepochopí, že ve kde 4 fungoval krásně a teď jednou z 10 pokusů. Myslím, že plasma 5 ještě rozhodně není stable tak mezi alpha a beta což je smutné po tom co se dělo s KDE 4
Kubuntu používám dlouhodobě. Upgrade na 16.04 jsem provedl a zatím v pořádku. Byl jsem docela spokojen s 15.04, ale 15.10 ke konci života dostávalo divné aktualizace, po kterých byly stále nějaké problémy s uživatelskými právy. V 16.04 zdá se všechno opět funguje správně.
Pokud jsem v 15.10 měl potíže s divně se chovající Plasmou, pomohlo ALT+F2 (KRunner), zadat "kquitapp5 plasmashell". Tím se zabije Plasma a následně se dá opět nastartovat ALT+F2 a zadat "plasmashell".
Jinak Plasmy 5.5 bych se určitě nebál a nemyslím, že by byl důvod zůstávat u staré čtyřky.
To ale na KRunner nepomuze. Kdyz mam jeden monitor, tak to jakztakz funguje, akorat po zobrazeni a napsani prvniho pismena to jakoby zamrzne a kdyz pisu dal, tak se text zobrazi az po chvili a to same se stane kdyz chci vybrat z nabidky akci. Pokud mam monitory dva, to se KRunner zobrazuje jenom nekdy a to jenom na jednom monitoru. Pritom pouzivam jenom spousteni aplikaci resp. spusteni necoho v bashi a kalkulacku od Plasma 5 jsem se to celkem odnaucil a spoustim aplikace rovnou z yakuake
"pokud dbáte na stabilitu, doporučuji s instalací ještě tak měsíc počkat"
z 14.04 LTS se oficialne doporucuje pockat do prvniho udrzovaciho vydani, tedy 16.04.1 ktere vyjde v cervenci, do te doby 14.04 LTS ani nenabidne automaticky moznost prechodu na 16.04...
btw: umisteni launcheru je dostupne v normalnim klikaci skryteho nastaveni "Unity Tweak Tool"...
Pouzivam to jiz od ledna kdy sem si stahl denni build a mezitim i upgradoval. Pri instalaci mi to nahodilo proprietarni drivery GPU. Testoval jsem r9 280x,r9 290, gtx 970 naprosto bezchybny provoz az do nejake aktualizace. AMD tehdy jelo na catalystech 15.2.
Ted se to kvalitativne vraci pomalu zpet. Oproti win driverum tehdy co jsem testoval tak AMD ztracelo 2-10%. pak jsem presel na GTX 970.
Ubuntu 16.04 hodnotim kladne uz ted u me prekonal rady 14.04-15.10. Posledni dobra verze kterou jsem zaznamenal byla 13.10.
Klikněte všichni, že se vás ten bug taky týká, ať s tím vývojáři něco udělají...
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1573206
misto dpkg (ktere neresi zavislosti) muzes pouzit gdebi(resi zavislosti a ma i moznost gui a tedy i asociace z nautilusu doubleclick na deb)
https://apps.ubuntu.com/cat/applications/gdebi/
opravdu se tam nevejde 750kB? a na te 486 se Ubuntu jinak hejbe? jestli k tomu nemas HDD, tak gdebi bude jen pulka diskety navic ;)
nerozporuju ze nejlepsi je aby bug byl opraven, nicmene gdebi je nastroj co ma vyuziti i v pripade ze bug uz nebude, jednoduse je to malinke a superrychle reseni ;)
Mám sice 5,6 GB, ale potřebuji místo taky na soubory, a proč instalovat něco navrch, když dpkg funguje taky? Stejně je ten software manager jenom gui obal pro dpkg + apt. Navíc čím víc balastu, tím větší šance, že se mi někde zkříží závislosti. A my staří linuxáci stejně radši tu příkazovou řádku, ono to gui občas není tak vymakané jak by mělo (u software managera to u Ubuntu není zrovna nový problém)
jasne kdyz z 5.6GB ukousnes 750kB tak uz na nic nezbyde ;)
gdebi narozdil od dpkg resi zavislosti, takze se ti nerozbori apt tak ze je potreba apt-get install -f jako pri pouziti dpkg, navic gdebi funguje samozrejme i jen z terminalu (od kdy rika linuxak "prikazova radka" ? ;)
ano GUI u UbuntuSoftCenter bylo silene, proto taky kazdej normalni starej ci mladej linuxak co pouziva deb based distro, tak nainstaluje synaptic a gdebi (neni li predinstalovane)...
osobne preferuju terminal, ale nezatracuju jednoduche a kvalitni gui pro urcite situace, pokud chces usetrit 200kB staci nainstalovat jen gdebi-core (tedy bez balicku gdebi ktere zajistuje gtk gui)
vyuziva to apt (resp. python-apt a dpkg), jen to nejde prasackou cestou ze "rozeserem zavislosti a pak je nasilim doresime", ale cestou "zjistime co je potreba, vsechno si nejdriv stahnem a pak to pekne ciste nainstalujem i s tim puvodnim lokalnim deb" :)
koneckoncu co myslis ze bylo UbuntuSoftwareCentrum, nebo ted Ubuntu(Gnome)Software? "jen" python "obal" pro dpkg a apt :)
"Mám sice 5,6 GB, ale potřebuji místo taky na soubory"
Možná by pro Vás mohlo být řešením, sehnat si starší disk a dát ho místo CD/DVD mechaniky, občas když se poptám mezi kamarády, tak se něco najde, občas někdo vyhazuje starý komp po rodičích a třeba 125G disk si do nového nenechává ....
Tipuju to bude nějaký s diskem 8G nebo 16 atd a s vymlácenýma clustrama zbylo 5.6 G :-)
Ne vážně. Pokud je starý, tak má cd-dvd romku a místo toho se dá dát disk, jenže je tam pomalejší sběrnice, takže systém je lepší dát na původní disk a "na data" disk místo té romky, ale asi mít 5.6 - to si radši kup 32/64 SSD okolo 2 litrů (nebo jak to sypou) a budeš z toho mít najednou dělo a když notebook umře, tak ti disk zbude.
tak z 22GB Windows par GB by slo dolu, smazat a vypnout body obnoveni, pustit "vycisteni disku => vycisteni systemu" kde zrusis data windows aktualizaci... a 750kB by se hned naslo :)
kazdopadne tvuj problem ma reseni ktere si prejes (pro pouziti nekolika MB GnomeSoftware ;) na blizku, jeste to neni v main repositari, ale uz je v testu(v proposed repo) opravane:
http://www.webupd8.org/2016/04/gnome-software-update-that-fixes.html
Protože většina programů, které potřebuji mimo Linux, běží jen na Win 8 a novějších (a Win 8/8.1 jsou shit) a protože pod Wine z nich 99 % nerozjedu. Moc alternativ taky většinou nemají, holt jsem se dal na dráhu chemika. Jasně, Toshiba Satellite Pro 4200 s trochu vylepšenou grafikou a procesorem, aby to zvládalo rozjet Ubuntu, a větším HDD (větší už tam dát nejde, ale mně to stačí).
Zdravim, narazil niekto na problemy s eap-tls pri nastavovani wifi? nejde vybrat subor s privatnym klucom, aj ked je v danom adresary, a nie je mozne zadat full cestu ako vo verzii 14.04.
ak vytvorim wifi profil manualne, tak network manager skoncim tutok: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1573720
vyzera to ze aktualne neviem pripojit ubuntu 16.04 do WIFI:EAP-TLS :-(
BTW: ma niekto zvladnutu integraciu EAP-TLS, s certifikatom v TPM/smartkarte? poradi ako na to?