Изпечатай

[geroy]

Това му е хубавото на opensource soft-a, ще се пръкнат други дистрибуции без systemd и хората, които ги ползват за сървъри и не инсталират нищо графично ще са щастливи

[Acho]

Така си е.

[growchie]

Това му е хубавото на opensource soft-a, ще се пръкнат други дистрибуции без systemd и хората, които ги ползват за сървъри и не инсталират нищо графично ще са щастливи

Еми явно не си допрочел една връзка която пратих. Те дистрибуциите си ги има, проблемът е че искат да ги съсипят. Ето я отново http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI
Ето заканата:
"Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call."
"Also note that this will not be a change that is just internal between udev and libudev. We expect that clients will soonishly just start doing normal bus calls to the new udev, like they'd do them to any other system service instead of using libudev. Good luck."

ядрото иска udev, udev иска systemd за да работи. Форка ще е много сложен, ако започнат да интегрират части от udev в ядрото което е противно на самата изначална идея за userspace /dev. Не знам за кои clients говорят но от тази приказка разбирам, че за да се обърнеш към udev да ти свърши някаква работа трябва да минеш не през libudev, а директно към ядрото. Може би gat3ay има по-добра представа за това, но излиза, че два юзърспейс процеса ще си плямпат през ядрото, а не директно. Явно са намислили да депрекират dbus. Бе пълна каша се заформя.

[bvbfan]

Всичко започна от създаването на система за стартиране, която използва паралелни процеси, докато инит скрпитовете се стартираха последователно. Аз не смятам, че systemd е лошо като замисъл, може би изпълнението закриви по друг път. Иначе на мен ми допада systemd-analyze, journald също е използваем. Колкото до рестартирането на системата, въпросните компоненти ядро, юдев и системд се обновяват не толкова често, вярно за сървърите би било голям проблем, за десктоп никакъв. Аз рестартирам най-малко на половин месец, сравняването с Виндовс ми се струва прекалено преекспонирано.

[growchie]

@bvbfan ми ползвайте си системд, просто ни оставете и нас другите да си ползваме каквото сметнем за добре. За това е цялата патардия.

[jet]

то на книга всички концепции са много хубави дорде не започне реализацията.
Имаше и един друг революционер дето щеше да "оправи" Линукс- М.Де Иказа. Оправи десктопа, портна Моно, оплю Линус, та го наеха Макрософт и миряса.

[bvbfan]

jet, тоя си намери мястото, пълен некадърник като всички, които работят за М$, та точно за там си е.

[growchie]

Точно бозиндолз

http://www.infoworld.com/article/2608798/data-center/systemd--harbinger-of-the-linux-apocalypse.html

While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux -- which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system -- from authentication to mounting shares to network configuration to syslog to cron.

[go_fire]

Мигел не е служител на М$ и всъщност ползва Мац. Но много от нещата, за които си говорите тръгнаха от неговите отрочета. И съвсем не е тръгнало всичко от паралелното зареждане. Преврата тече повече от десет години.

Какъв е проблема на sda, sdb, sdc? Ами проблема им е, че те са част от заговора, на който никой не обръщаше внимание, а ние още тогава надигахме вой. Днес обаче решиха, че sda, sdb, sdc вече не са им необходими и ги обявяват за остарели. Ако им бяхме дали отпор още тогава, днес нямаше да сме тук. Но ние ги търпяхме (включително аз, както си признах по-нагоре) въпреки, че бяха безумие. Една буква, какво толкова. Ето промяната на една буква до къде ни доведе.

Иначе дисковата организация в Линукс по начало си беше досифицирана и беше въпрос на време пезумието да прерасне. Е направи го.

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

И който си разправя, че щял да има сървъри без графика и да си свирка, нещо е проспал последните няколко години развитие. Все още ги имате, но времето ви е изтекло. На практика вече ги нямате, само дето не сте се осведомили. Скоро абсолютно нищо няма да можете да администрирате от конзола.

Е с риск да се повторя. Искахме да изместим Шиндош. Това значи да станем втори такъв. Почти станахме. Но нека не си честитим още победата и не вадим шампанското, това да станем като тях все още не ни е гарантирало победата, макар да сме на крачка.

Поне на един пазар засега ги мачкаме. Може би защото все още нямат подкрепата на Интел на него. А на мен това ми е по-интересният въпрос. Ще падне ли глиненият гигант Интел, какъвто винаги е бил. Ако той падне, значи още нищо не е свършило. Ще е интересно.

[jet]

Мигел не е служител на М$ и всъщност ползва Мац.

Не директно, а чрез Новел

Иначе дисковата организация в Линукс по начало си беше досифицирана

Кое точно е досифицирането?!
S- сериен (SATA или SCSI)   |  P- паралелен
A,B,C,D - номер на канал
N - номер на партишън

Останалото от поста ти нищо не разбрах (стил ала врачка- завоалирано)

[go_fire]

Ес е от скъзи и се използваше за скъзи емулация на устройства. При преврата и появата на /media за уж сменяеми устройства (по онова време още нямаше влашки, говорехме си за компактни дискове, които използваха въпросната емулация) това се разпространи върху всичко. Все пак никой не иска скъзи емулазция за обикновен ATA. Но познай. Ако закачиш устройство, което не е SATA то също ще се покаже като sdX. Корена на всичко това е, имаме участник познал верният отговор — в udisk/udev.

Нищо не започва от днес.

Защо говоря за досификация? Ами елементарно. Вземи едно БСД и виж неговата дискова организация. Вземи Дос и виж неговата. След това сравни с нашата. БСД има юникска организация. По между другото повтори експеримента с мрежовите платки.

Мигел вече не работи за Новел. След като Атачмейт купи Новел обяви Моно за безперспективен. След броени дни Мигел обяви създаването на компания с рисков капитал, която „изненадващо“ се казва Ксамарин. Та така, днес Мигел е честен капиталист. Но да връзката с М$ е доста топла. Официалната теза е, за да не бъдат обвинени в монополизъм. Пък и това, което продава Ксамарин не е в пазарната ниша на М$, нито пък може да се сравнява по производителност.

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

[gat3way]

ядрото иска udev, udev иска systemd за да работи.

Това не е вярно. Предполагам визираш kdbus, kdbus не изисква udev за да работи. kdbus е kernel-базиран message bus, нещо като dbus, само че реализиран в ядрото. dbus е много хубаво нещо като идея, но като реализация е кошмарно. Човек може да преглътне xml простотиите, но това има много проблеми - свързани с performance, някои са архитектурни. Навремето имахме един голям проект, който използваше dbus изцяло като IPC механизъм между всичките наши софтуери, които вървят на една embedded платформа. В началото всичко беше прекрасно, но много скоро се стигна до големите проблеми. Хората започнаха да блъскат какво ли не върху dbus-а, включително стигнаха до свинщината да мятат картинки и аудио. И всичко буквално клекна. Идваха големи глави, оптимизираха dbus (има добре известни неща които могат да се направят и без да си голяма глава, но друго е когато голямата глава го направи). Това не помогна особено, нещата клекнаха отново много скоро. И се почна с проучване на варианти за търкаляне на част от нещата върху shared memory и отебаване на dbus за прилична част от нещата - нито throughput-а му беше като хората, нито латентността в случая в който това имаше значение, беше нормална и предсказуема. И проблемите са архитектурни - има 50 context switch-вания за един RPC call, unicast комуникацията не е много истинска и минава през dbus сървъра, който като има да търкаля някоя голяма свинщина, всички останали чакат.

Та kdbus ако адресира тези проблеми, ще реши доста проблеми поради което съм с две ръце "за". Ако е реализирано в ядрото, една много прилична част от проблемите ще могат да се решат, главно проблема с многото превключвания на контексти. Но както и да е, просто не виждам по какъв начин kdbus би зависил от udev.

Що се отнася до това обвързване на udev със systemd, не съм запознат с драмата и не мога да коментирам.

Форка ще е много сложен, ако започнат да интегрират части от udev в ядрото което е противно на самата изначална идея за userspace /dev.

Това пък защо?

Не знам за кои clients говорят но от тази приказка разбирам, че за да се обърнеш към udev да ти свърши някаква работа трябва да минеш не през libudev, а директно към ядрото.

Предполагам са заменили ползването на dbus с kdbus. Което може и да не е толкова лоша идея.

Може би gat3ay има по-добра представа за това, но излиза, че два юзърспейс процеса ще си плямпат през ядрото, а не директно. Явно са намислили да депрекират dbus. Бе пълна каша се заформя.

Два юзърспейс процеса винаги си говорят през ядрото, защото има изолация на адресни пространства и не биха имали друг механизъм да си говорят, освен механизмите които ядрото им предоставя. Всякаква форма на IPC - шерната памет, пайпове, сокети, дори писането в общ файл, всичко това минава през ядрото. Шернатата памет е малко по-специален случай, защото не се налага да минаваш през ядрото всеки път когато четеш или пишеш в нея. Но дори и тя изисква намесата на ядрото, за да се случи. Просто така работи всяка нормална многозадачна операционна система, не е нещо линукс-специфично.

[growchie]

@gat3way
http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html

Това по въпроса за kdbus за сега.


Това за форка:
Samuli Suominen of Gentoo expressed some hesitation about this change, "I'd really hate to be forced to fork (or carry huge patchset) unnecessarily (I'm not a systemd hater, I'm not a eudev lover, I'm simply working on what is provided to me by *you*, udev upstream)."

[gat3way]

Това пък каква връзка има?

[go_fire]

Проклетника dbus е съществена част от проблема. Типичен пьотеризъм. И да той е част от systemd. Той е въпросната зависимост, която не позволява /usr да е на отделен дял.

Въпросът за dbus ме занимава, от както се е появил. Видиш ли xml, изтрелвай се като бясно куче. Тези три думи са синоним на слабоумие. Но може да се провери и емпирично. Dbus не е нищо друго освен източник на проблеми и нестабилност.

По принцип класически този проблем се решаваше с I39L (познат и като ICCCM). Обаче това, което не знаехме обикновените хора беше, че I39L е една огромна свинщина поради разни причини извън темата ни. И поради това хората търсеха замяна. Гномаджийте заложиха на класическата CORBA. Но дори това извращение не им беше достатъчно. От КДЕ пък си бяха измислили тяхно решение наречено dcop. Тогава в нечии кабинет в Ред Хат се роди гениалната идея да вземат най-лошото от двете системи и се пръкна dbus. Естествено всичко това мина под шапката на Free Desktop, за да изглежда легално.

Linux Hater полудя от това и предложи да се мине на SunRPC. Старо, доказано и… скапано като всичко със слънчева марка, но все пак с някоя и друга идея по-добро от dbus.

От там-натам дойде времето на КДЕ4/Гном3, където всичко стана неспасяемо. Всичко се върза към проклетият dbus.

Проблема е стар точно колкото са стари графичните терминали за Юникс, но ние решихме да го решим по най-кошмарният начин, с което, освен всичко друго имаме поредното самостоятелно място на провал в системата.

Е ако ще сме Шиндош, трябва да сме нестабилни поне, колкото него.