Бе тоя линукс няма ли недостатъци. Ако няма недостатъци, що такива неща се разискват из мрежата и на дистрибуторите им смъкват и долните гащи, заради кодирани резили?

Че и аз в steam като съм свободен си играя игри под линукс със ATI Radeon.

Недостатъци има, но почти винаги нещата са решими.

Безсмислена е. Може да сравняваш еквивалентни неща. В съществената си част (тоест приложенията) Уиндоус и Линукс не са еквивалентни.

Идеята беше да обсъждаме новостите и проблемите. Не точно да сравняваме едното и другото.

Да, повечето приложения наистина са различни. От друга страна с какво по-близко да сравняваме Windows-a? Излиза, че е толкова "супер" уникален, че не съществува нищо подобно. И още една идея против тази интерпретация - приложенията са отделно от ОС. Ако сравняваме само по приложенията излиза, че не сравняваме съдържанието, а по-скоро обкръжението.

Не виждам защо трябва да се мъча с една ОС, вместо да правя всяко нещо на тази, на която е най-лесно. Моята логика е проста - търси се минимумът на (Усилие и време да си изградя среда за "работа" + усилие и време да си върша "работата" в тая среда + усилие и време да се справя с проблеми, предизвикани от средата)

На мен примерно ми е по-лесно еднократно да си инсталирам няколко ОС, след което да върша това, което искам под тази ос, за която е предвидено нужното ми приложение.

Има солидна логика в тези доводи. Още повече съществуват задачи, които е немислимо да се изпълнят в различна среда и това важи за всички ОС.

Пък ако кажеш, че няма очевадно и издъно необективни фенове на линукс във форума...

Или просто натрапват личното си мнение, което не всеки би приел. Ето защо гледам да не пиша в теми за Windows.

На мен пък ми вършат, сцепвам се от игра на Linux

 

http://www.kaminata.net/igri-za-windows-koito-sme-igrali-pod-linuks-t94695.html

 

И всички сме сигурни, че нищо не знаеш за Убунту. Само така си мислиш

Такива игри не ми хващат окото, за това съм на Windows

Колко от горещите заглавия в момента официално поддържат Linux?

 

А за Ubuntu знам достатъчно, за да не го избера пред Windows за определени неща

http://www.kaminata.net/igri-za-windows-koito-sme-igrali-pod-linuks-t94695.html

Хареса ми за NFS...

 

Такам, намерих малко време, влизам отдалечено, за да мога да ти обясня, че в работата съм с един утрепан Минт и повечето менюта са наопаки :mrgreen:

Еми кво да кажа. Играта е:

най-лесната игра за инсталиране. Все едно си на Windows

следват 20+ изречения и 6(!!!) скрийншота пояснение.

Не помня вече, как се инсталираше тая игра под уиндоус... Но все си мисля, че в същия обем може да се направи и много кратък преразказ в картинки на самата игра, освен обяснения за инсталацията.

 

Невинен зрител, като моя милост, би се зачудил за големината на обяснението за някоя "по-трудна игра за инсталиране"...

Сега да разясня малко. Идеята на темата е всеки който има наблюдения с времето над Linux + последните неща, които се въведоха/ ще се въвеждат да каже някакво мнение.

 

Изобщо не ме "боли" да сравнявам Linux с Windows и обратно. Въпроса в случая е кой какво мисли относно начини за подобрение на ситуацията в момента. Айде да не си чешем езиците дали ми вървят игрите или ала бала. При мен Starcraft-a си въври и на двете пък за другото не ме боли щото не го играя ..

 

Та сериозно:

 

Заглавието на темата съм го писал нарочно на латиница, защото "Why Linux Sucks" се използва от много време точно за такива дискусии. Ако Ромео не е съгласен ще го сменя.

 

@bvbfan 

.

 

Първо в повечето opensource неща не само Linux има практика да се чупи обратна съвместимост. Поражда се от това, че в повечето случаи се развиват що-годе бързо проектите и се наливат нови хора с нови идеи и в повечето случаи новата major версия е с променена ""идеология". Точно примерно KDE - Не знам дали си спомняш прехода от 3 към 4 - имаше година и нещо след пускането в която наваксваха и имплементираха липсващи фийчъри.

 

Относно организацията на пакетите в момента, ами добре е, но за сървър ( и пак има какво да се желае, но поне се върви на там ). Какво имам в предвид. Ако сервирам Web примерно, имам нужда от последните кръпки на сървъра, openssl и т.н. и е най-лесно да update-на всичко и да се възползвам, защото в повечето случаи нещата, които сервирам нямат пряка зависимост със самия сървър ( е версиите примерно на PHP/Python etc. може да окажат влияние, но в повечето случаи има как да се инсталират различните версии ).

 

Ако обаче съм Desktop потребител и имам софтуер с който ми се налага да работя нещата не са така. Тук пак има условности, Говоря не за потребител, който ползва само Chrome/Firefox и музикален плеър.
Примерно аз имам фирма Х и ми трябва някакъв софт, плащам на Developer-a Y да ми го напише. И тук идва кофти момента. Ок той ми пише софтуера, който в момента работи на система Z, ама след update на система Z библиотека A вече е нова версия ... и аз имам няколко варианта, или стоя на по-стара версия на OS (примерно LTS или някой RHEL, който ми дава support 10 год.) - ама в случая се лишавам от новостите заради 1 програма, вариант 2: плащам на Developer-a да ми пренапише софта ( коства ми пари ). Обеден съм, че точно заради това вендори, като Adobe не си портват продуктите ( просто имаме малък брой потребители за момента и сложности по поддръжката, което го прави икономически неизгодно).

 

Така, как може да се подходи към този проблем ( на там вървят нещата поне ). Не може да се ползва подхода на Apple да линкваме статично библиотеки ( GPL-a не го позволява), пък и е дървено, щото имаме големи binary-та. Та ползваме контейнери. За всяка програма, която пиша си правя контерйнер, като в него си слагам библиотеките на които аз депендвам + самата ми програма. Контейнера си е цялостен Linux ( имаме си folder tree-то, кофигурации и т.н.), въпреки това, самият контейнер се mount-ва в folder на хоста, като по този начин може да се линкват библиотеки от хоста + /dev дивайси. По този начин реално мен не ме бърка аз на каква ОС го слагам този контейнер и какви библотеки има, защото аз си ship-вам мои. И поне на теория трябва всичко да работи. Аз силно се надявам да се интегрира това. Реално по този начин може да се сглоби и ос:

Ето малко примери: http://www.projectatomic.io/ , https://wiki.gnome.org/Projects/OSTree , http://developer.ubuntu.com/en/snappy/

Този подход според мене е 1000 % по-добър от досегашния. Схемата е, че въпреки, че системата ни е сбор от read only имиджи, които са mount-нати един върху друг, а ние пишем само в top layer-a реално това не се усеща. В смисъл реално като правиш нещо по системата това остава скрито.

Много се надявам да се продължи да се интегрира това.

 

Сега относно Hardware vendor-ите на видео и драйверите, там предполагам, че нещата ще се изгладят, когато се разкара X-a и се пишат читави KMS драйвери, след около 3-4 год всичко ще се нареди. Сега друг е въпроса, че има недомислици. Примерно Optimus технологията и изобщо хибридното видео е голяма простотия, както при Linux, така и при Win. Та се надявам да се хванат и да си изгладят нещата там, а не да се мъча с bumblebee или с бозата под windows, която ми бичи сини екрани.

Относно графичния сървър хубавото е, че се разкарва Х-а и нещата започват да се стандартизират. Input-a го поема libinput и всички ползват него (Wayland и Mir), а колкото и да бягат Canonical с Mir 100% рано или късно ще имплементират интерфейси от Wayland протокола за да бачка всичко навсякъде.

 

По другия въпрос UI-а. Там няма значение, как една библиотека имплементира темплейтите. Винаги може да се направят интерфейси, които да уеднаквят поне базовите widget-и.

 

п.с. Та идеята ми беше да си кажете мнението по тези въпроси. Изобщо не ме боли дали Win e по-добър или не.

Относно приложенията идеята ми изобщо не е Windows да заприлична на Linux, мен не ме кефи Windows-a как ги manage-ва. Mac OS е много по-добре в случая хващаш, драг в Applications и имаш инсталирано user-ско приложение. Точно това може супер лесно да се имплементира с контейнери.

Редактирано 27 април 201511 г. от borovaka (преглед на промените)

като по този начин може да се линкват библиотеки от хоста

Тогава не прецакваш ли идеята на тоя контейнер да бъде независим?

Този подход според мене е 1000 % по-добър от досегашния. Схемата е, че въпреки, че системата ни е сбор от read only имиджи, които са mount-нати един върху друг, а ние пишем само в top layer-a реално това не се усеща. В смисъл реално като правиш нещо по системата това остава скрито.

Много се надявам да се продължи да се интегрира това.

Как тия контейнери решават дали да заредят една или няколко инстанции на една библиотека, при няколко пуснати приложения? Примерно А и Б ползват една версия, а В друга. Какво ще се зарежди, като пуснем А,Б и В едновременно? Какво правим, ако библиотеката не е предвидена да работи в много инстанции и има проблем с това?

Какво се прави, ако в ключова библиотека, ползвана от 10-ина такива контейнера от различни провайдъри, се открие критична уязвимост?

Как помага тая работа, ако различните версии искат различно ядро?

Тогава не прецакваш ли идеята на тоя контейнер да бъде независим?

Как тия контейнери решават дали да заредят една или няколко инстанции на една библиотека, при няколко пуснати приложения? Примерно А и Б ползват една версия, а В друга. Какво ще се зарежди, като пуснем А,Б и В едновременно? Какво правим, ако библиотеката не е предвидена да работи в много инстанции и има проблем с това?

Какво се прави, ако в ключова библиотека, ползвана от 10-ина такива контейнера от различни провайдъри, се открие критична уязвимост?

Как помага тая работа, ако различните версии искат различно ядро?

Ти си решаваш дали да ползваш системна библиотека или твоя версия, която да е в контейнера, според ситуацията.

Проблема с инстанциите се решава много лесно - един контейнер един pid, една инстанция.

Ако искаш да стартираш 2 пъти програма X пускаш два контейнера. В смисъл гледай на контейнера, като на приложение а не като на виртуална машина. По-скоро си представи, че имаш виртуална машина която се стартира с init = /bin/yourapp вместо да имаш init система.

 

Относно това, ако има критичен бъг в библиотека, там вече, ако контейнера, не ползва системната ти библиотека (която ще обновиш с ъпдейт на ситемата), докато не обновиш самото приложение си оставаш прецакан в смисъл бъга си го има. Обаче пък печелиш, че имаш изолация от хоста ти, в смисъл и да експлойтнат контейнера ще получат достъп до него ( освен, ако няма някакъв kernel бъг, защото контейнера ползва ядрото на хоста).

 

Та не е пълна панацея, ама е много по-удобно отколкото досегашните методи, поне според мене.

 

Относно различното ядро, там нямаш решение, защото контейнера ти ползва текущото ядро. Ама аз не се сещам за много библиотеки, които да депендват на kernel версия, по-скоро имам в предвид, ако хоста ти ползва ново ядро, не би трябвало да имаш проблеми със стара библиотека в контейнера ( обратното не така ).

Редактирано 27 април 201511 г. от borovaka (преглед на промените)

Ти си решаваш дали да ползваш системна библиотека или твоя версия, която да е в контейнера, според ситуацията.

Ти, като производител на контейнера ли? Нали е предназначен за десктоп системи? Тоест може да има системи с 20 различни версии на външната библиотека и някоя да е със сменен интерфейс... Няма как да знаеш, а нали тва е идеята на тоз контейнер  - да ти осигури предвидима и работеща среда за приложението.

Проблема с инстанциите се решава много лесно - един контейнер един pid, една инстанция.

Ако искаш да стартираш 2 пъти програма X пускаш два контейнера. В смисъл гледай на контейнера, като на приложение а не като на виртуална машина. По-скоро си представи, че имаш виртуална машина която се стартира с init = /bin/yourapp вместо да имаш init система.

Ми тогава защо наплю статичното линкване за размера на бинаритата? Както ми го описваш, размера на зареденото съдържание даже ще е по-голям и при това успешно ще си неутрализирал повечето от предимствата на динамичното линкване, без да имаш никое от предимствата на статичното...

Обаче пък печелиш, че имаш изолация от хоста ти, в смисъл и да експлойтнат контейнера ще получат достъп до него ( освен, ако няма някакъв kernel бъг, защото контейнера ползва ядрото на хоста).

Това ми е трудно да си го представя как ще бъде направено ефективно. Контейнерът в общия случай трябва да има достъп извън себе си, за достъп до данните. Иначе ще е пълна простотия. Представи си, да кажем обработка на изображения. Имаш поне 3 програми - за обработка на RAW, фоторедактор, програма за предпечат. Е те трябва да имат общо място за обработка на снимките, изключително неоптимално ще е всеки да си бърка в градинката и после ти (и как, че да е безопасно) ги прехвърляш от контейнер в контейнер...

Не мога да си представя как ще го направиш, освен ако не дублираш нещо от SELinux функционалността, а що тогава направо не сложиш SELinux...

Та не е пълна панацея, ама е много по-удобно отколкото досегашните методи, поне според мене.

Ми според мен е против много от основните принципи на Линукс-дистрибуциите...

Основно, много прилича на комерсиалните ОС. Примерно нищо не ми пречи да си сложа и затворен код в тоя контейнер и ще си работи.

Редактирано 27 април 201511 г. от flare (преглед на промените)

Разработчикът отговаря за зависимостите, може да ти направи зависими от версиите на системните библиотеки или да даде специфични версии, като прави скрипт за поставяне в path на определена директория. Няма кой друг да реши тези проблеми, ако се стигне до счупвавне на обратната съвместимост, трябва да имаш наборът от небходими зависимости т.е. един вид като портабъл. За Windows само MVC-то има някакви версии, всичко друго като Qt, конкретното приложение си ги дава - примерно wps office дава цялато Qt 4.7, докато друго приложение дава цялото Qt 4.8 и ти получаваш и 2-те, ако имаш 3-то и 3-те и така. Докато начинът със системни е по-универсален, но и той има недостатък, когато се счупи обратната съвместимост. Така, че нито в Windows, нито в Андроид нещата са по-добре.

Не са чак такива кахърите на линукс при декстопите ,просто потребителите са зомбирани колко трудно е да се ползва свободна ОС.

Така, че нито в Windows, нито в Андроид нещата са по-добре.

Не са, но практически се прилагат по-добре. Както borovaka каза, подходът в линукс дистрибуциите е ад за разработчиците - в смисъл на представяне и подръжка на краен продукт - тестване, допълнителни бъгове... Ти го приемаш за нормално, но за общия потребител не е така.

Очаква като си дръпне приложение, то да се инсталира и работи, без да има и предизвиква проблеми. И колкото и да не ти харесва, ако приложението върви с пълен пакет от зависимости е много по-вероятно това да си случи.

Редактирано 27 април 201511 г. от flare (преглед на промените)

Не са, но практически се прилагат по-добре. Както borovaka каза, подходът в линукс дистрибуциите е ад за разработчиците - в смисъл на представяне и подръжка на краен продукт - тестване, допълнителни бъгове... Ти го приемаш за нормално, но за общия потребител не е така.

Очаква като си дръпне приложение, то да се инсталира и работи, без да има и предизвиква проблеми. И колкото и да не ти харесва, ако приложението върви с пълен пакет от зависимости е много по-вероятно това да си случи.

Никой не те спира да дадеш целият набор, wps office, както ти казах, дава целият набор от Qt4.7 и под Линукс. Подходът е, ако пишеш отворен код - слагаш го някъде, gihub примерно, и дистрибуциите си правят spec файл за пакетите, ако правиш затворен код задължително даваш целият набор. По-просто от това няма на къде, никой не те спира да се преебаш както искаш - въпросът е да ти покажат верният път.

@flare Нищо против нямам статичното компилиране, просто не можеш да го ползваш в повечето случаи заради GPL-a. Схемата с контейнерите е, че ти като Developer си решаваш дали да депендваш на системна библиотека или да си добавиш библиотека в контейнера. Потребителя реално го бърка да си инсталне приложението и да работи - него не го засяга реално.

 

Относно сигурността, тъй като контейнерите ползват namespace в кърнала, мисля, че можеш да си форсваш selinux полисита директно ( тука не съм твърде убеден, но така си мисля).

Другото предимство е, че ако цялата ти система е изградена върху контейнери (OSTree и Snappy примерно) печелиш, че можеш да правиш rollback на цялата система, в смисъл, ако нещо се сбози след update пускаш rollback и директно получаваш имидж със старата версия, която знаеш, че бачка. С приложенията е същата схема, щото те реално ти се явяват имиджи.

 

п.с. Някой администратор няма ли, да каже и от негова гледна точка как стоят нещата специално що се отнася до контейнеризацията/systemd и т.н.?

Редактирано 27 април 201511 г. от borovaka (преглед на промените)

По-просто от това няма на къде, никой не те спира да се преебаш както искаш - въпросът е да ти покажат верният път.

Е те това е проблема я. Кой е верният път. Ако има изобщо такъв.

Верният е със системните библиотеки, а пък всеки решава как да дистрибутира продукта си. Линукс не е насочен към комерсиални продукти, разчита се на отворените приложения и всеки затворен софтуер, като Вайбър, сам решава системни ли ще ползва или собствени - какъв ти е кахъра на теб?

@flare Нищо против нямам статичното компилиране,

за статичното не оспорвам лицензирането - беше писал, че е лошо заради размера и аз отбелязах, че с контейнер ще си по-набутан в този смисъл.

За сигурността - ти каза че самите контейнери дават сигурност заради капсуловането и аз казах, че не съм съгласен с това, не и без нещо като SELinux, а за SELinux не ти трябват контейнери.

Тоест тия двете не са предимства на контейнерите.

п.с. Някой администратор няма ли, да каже и от негова гледна точка как стоят нещата специално що се отнася до контейнеризацията/systemd и т.н.?

Другата седмица, Капитана може да каже нещо по въпроса... Което ме подсеща за друго, ти спомена rollback. То хубаво, ама чак толкова да е полезно за десктоп система... Виж за сървър е къде къде по-полезно

Изобщо, това би било полезно за инкрементални ъпдейти на примерно корпорации и такива работи, но основано на съществуващи приложения - т.е. IT-то на компанията сваля приложението, издебъгва го, прави си го на контейнер и го качва на OSTree-то. После всички от компанията ъпдейтват. Обаче за домашни потребители на линукс...

Пък и кърнъла пак те прецаква. Той е извън уравнението на контейнерите, а и неговия интерфейс сменят...

какъв ти е кахъра на теб?

Че просто не съм съгласен Просто сравни потребителската база на едното и на другото - и като хора и като устройства, и като приложения ако щеш.

И какво по-точно ще се скапе от ъпдейт, или пък да правиш rollback на приложения е колосална простотия. Това и в момента е възможно, основно най-добро е решението на Арч, като ти пази старата версия в кеш и може да си я върнеш, ако поискаш. Може да спреш ъпдейтването на определно приложение, но и това не е вярно решение. Тия контейнери по ми приличат на нещо по средата, нито всяко приложение да дава свои версии, нито да са само системните. Осново го правят заради телефонната си джуджавка. Никакво прецакване нямаш от кернела.

Еми печелиш от размер в контейнерите, защото имаш опция да ползваш хибриден подход, в смисъл да не вкарваш всичко в контейнера, а да ползваш и системни библиотеки. Другото което е размера на "приложенията", не виждам да е от толкова основно значение изобщо, в смисъл 50 мб повече или по-малко е все тая.

Относно сигурността, печелиш дотолкова доколкото горе-долу приложенията ти са в chroot подобен режим, от там нататък, може да се слагат и други полисита.

А за incremental update не виждам, защо да не е предимство и при десктопа? Другото, което е нищо не ти пречи самият kernel да ти е пак в контейнер ... В смисъл baselevel-a ти е имидж с кърнал ramfs и т.н. простотии, които ти трябва да запали системата, от там нататък след зареждане, започва инкрементално mount-ване на всичко друго, като всичко е Read Only, и накрая се mount-ва последния layer (потребителския), който ти е read-write. Реално snappy image-a на Убунту си е точно така в момента.

 

А за кърнала, кои точно интерфейси call-ваш от userspace? И кое точно чупят. В смисъл не, че няма такива случаи ама там нещата са по-балансиране, пък дори и да ги чупят, тогава ще се главоболиш само за kernel-a, другите нещата що-годе отпадат и пак излиза по на сметка.

The genesis of Ubuntu Core is our mission to deliver perfect system and application updates on phones — we created the snappy technology and application confinement system to ensure a carrier-grade update experience for Ubuntu mobile users and set a new standard for application security in the mobile era.

Идеята като цяло е много по-добра от на Андроид, в това съмнение няма, защото ще направят обновяването не до carrier brand, а до тяхна поддръжка. Но приложенията са задължение на разработчиците, аз съм такъв, и както сега като излезе Андроид 5.0 имаше една кола приложения, които не работеха - трябва да се донапише нещо или промени.

Па и аз бех кът тебе заблуден .............ма се пробвах веднъж и се оказа ,че е доста по-лесно .И като бивш уиндоус потребител мога да ти кажа ,че Линукс е в пъти по лесен за инсталация и употреба.

На краставичар краставици да продаваш  

Нека "серат" - повече от некомпенетни са

Един човек за да е обективен не трябва да бъде пристрастен.

Ето за това говорех. Изпълзяха зопбираните уинлайно фанатици и забравиха за теми като Защо Уиндоус е боклук, Почистване от зловреден Софтуер, Май хванах вирус какво да правя ?!

Мда изпълзяха

Ае, ти още в началото си бил в конзолата и си пишел "Словото" как да се визуализира и материализира света, животните, човека и жена му. Ма ние простосмъртните сме по-прости от африканци...

Грешно е да се сравняваш с мен...

Мда ти можеш да си напишеш такава

... синия екран ли ти е удобен,... ? 

Или kernel panic

Да уточня че игрите вървят по-добре под Линукс, защото не е толкова натоварена OS!

Да най-вече DX игрите.

Браво!

Така, че нито в Windows, нито в Андроид нещата са по-добре.

Само аз така ли мисля, или ядорот на Android е ядрото на линукс ?

 

П.П.  Тази тема май е направена за обсъждане на НЕДОСТАТЪЦИТЕ на линукс, а не да се оплюват другите операционни системи е да се "доказва" колкооооо велик е ши*аня линукс.