Винсент Унтц (Vincent Untz), релиз-менеджер проекта GNOME и руководитель управляющего совета openSUSE Linux и бывший глава GNOME Foundation, и Фредерик Кроза (Frederic Crozat), руководитель проекта SUSE Linux Enterprise Desktop, активный разработчик GNOME и участник проекта по интеграции systemd в openSUSE, на конференции SUSECon 2013 сообщили (http://www.itwire.com/business-it-news/open-source/62297-dev...) о необоснованности слухов о том, что GNOME со временем становится зависимым от systemd.
Подобные предположения основаны на появлении в списке планов по разработке GNOME 3.12 пункта (https://wiki.gnome.org/ThreePointEleven/Features/SystemdUser...) с реализацией поддержки средств systemd (http://www.opennet.me/opennews/art.shtml?num=34186) для управления пользовательскими сеансами и запуска каждого приложения в отдельном cgroup. В описании данной возможности упомянуто, что поддержка ранее используемых средств управления сеансами и систем без systemd будет сохранена. Сказано, что следующие несколько выпусков поддержка старых методов управления сеансами не составит труда, а дальнейшая поддержка будет зависеть от развития событий в будущем.
Унтц и Кроз сообщили, что GNOME не отходит от концепции универсального окружения, поддерживающего работу не только в Linux. Переход всё большего числа дистрибутивов на systemd не отменяет работу по обеспечению поддержки в GNOME систем с альтернативными системными компонентами. На вопрос о привязке systemd к Linux и возможности портирования на другие системы, разработчики ответили, что несмотря на то, что systemd базируется на специфичных для Linux программных интерфейсах, данные API могут быть реализованы и в других ОС, как в своё время произошло с подсистемой HAL (Hardware Abstraction Layer).URL: http://www.itwire.com/business-it-news/open-source/62297-dev...
Новость: http://www.opennet.me/opennews/art.shtml?num=38447
Пардон. А зачем тогда systemd в зависимостях у Gnome и других форках на базе Gnome3 в Genoo???
Это чтобы фанбои системд тыкали пальцем в кривую сборку.
если честно, то у меня получилось собрать и без systemd (я его отправила в packaged.provided) приложения работают, включая и gnome-settings-daemon, а десктоп гномский я не использую
у меня gnome 3.10 на openbsd, без единого systemd.правда, нет gnome-games, epiphany (или его так хитро переименовали, что я не нашёл), и мож ещё чего. явно, шашкам очень нужен был systemd.
epiphany не переименовывали
у меня свеженький 3.8.2 c webkit-gtk 2.2.1 , никакого systemd ему не требуется
http://www.opennet.me/opennews/art.shtml?num=37782Разработчики web-браузера Web (ранее Epiphany), развиваемого проектом GNOME... (далее по тексту).
упрощаются во всем.. включая и название
в ебилды пока не попало, так что я пока была не в курсе о смене названия, да и вообще эпифани стала примитивнейшей обложкой для вебкита, настроек меньше и меньше, в 3.8.2 уже и самого необходимого уже практически нет. Вон rekonq или qupzilla поприятнее, из GTKшных новых есть dwb, для мышененавистников и vi-любителей - идеал :)
epiphany - это как перв.... втор... третья любовь. А её, как известно, не выбирают.Впрочем, в любом случае её нет в openbsd.
Но да, когда с панели убрали кнопки зума, я их особо и не искал. Хотел посмотреть, что там в 3.10, но в openbsd не нашёл такого пакета. :(
> epiphany - это как перв.... втор... третья любовь. А её, как известно, не выбирают.Можно выбрать Midori.
> у меня gnome 3.10 на openbsd.Это эпично. Среда для склеротиков-имбецилов в системе для прокачки ЧСВ маргиналами. Круче чем деление на ноль.
> Пардон. А зачем тогда systemd в зависимостях у Gnome и других форках
> на базе Gnome3 в Genoo???А в дебиане у гнома в зависимостях даже адблок. Это же не значит, что без него гном не работает...
Именно в зависимостях? Опция "рассматривать рекомендации как зависимости" отключена?
> Именно в зависимостях? Опция «рассматривать рекомендации как зависимости» отключена?ты сейчас половине «аптгетоненавистников» сломал уютный мир.
Зря ты так. Даже если отключить и Recommends, и Suggests куча шлака все равно по зависимостям тянется. KDE тянет gtk - дебиан такой дебиан.:)
любители kde такие любители kde… одни зачем-то это использовать хотят, а другие собирают в меру своей криворукости.
> Именно в зависимостях?да :)
> Опция "рассматривать рекомендации как зависимости" отключена?у меня aptitude. я все эти вещи могу заплюсовать-заминусовать вручную, и отлично вижу всю раскладку и взаимосвязи через интерфейс, даже без установки.
> у меня aptitude. я все эти вещи могу заплюсовать-заминусовать вручную,Вот только если вручную оверрайдить "жесткие" зависимости - можно в два счета словить невкусный факап, превратив систему в минное поле.
> Вот только если вручную оверрайдить "жесткие" зависимостиэто невозможно в принципе
> это невозможно в принципеКто тебе сказал такую глупость? Возможно, только достаточно неудобно и если что-то поломается - жаловаться можно лишь на свою бестолковость.
Зато стал от зависим от "крутых инновационных дезигнеров и манагеров".
Кажется, ребятам очень не понравилась перспектива вылета из дебиана.
> Кажется, ребятам очень не понравилась перспектива вылета из дебиана.если Дебиан перейдет на кривую поделку бубунту, то он сам вылетит из мира линукс.
>> Кажется, ребятам очень не понравилась перспектива вылета из дебиана.
> если Дебиан перейдет на кривую поделку бубунту, то он сам вылетит из
> мира линукс.Xfce таки в бубунте сделали? breaking news!
И?
Если дебиан вылетит из мира линукс, то линукс вылетит с десктопов.
А поделка... Дык напиши лучше, кто мешает-то вместо холиваров пиши замену, пользы больше будет.
Upstart? А вылетят ли они если останутся на старой системе?
> Gnome зависит от systemd
> В systemd бинарные конфиги
> При переходе на systemd придется выкинуть все инит-скрипты
> SystemD монолитен и вообще не unix-wayКогда уже systemd-хейтеры перестанут лгать?
Тогда же, когда и systemd-фанбои.
А такие есть?
Узри же! Я он и есть! Фапф-фапф-фапф
что несут эти два олигофрена. Уже 3.8 не работает без systemd
Свет истины они несут.
GNOME скоро можно будет переименовать в GNOMED
WASTED
> как долго продлится такая поддержка пока не ясноверсию-другую после того, как полностью «подвяжут» системды. а потом выкинут, потому что «пользователям это не надо и у всех уже системды, а поддерживать столько кода мы не можем».
> версию-другую после того, как полностью «подвяжут» системды. а потом выкинут,
> потому что «пользователям это не надо и у всех уже системды,
> а поддерживать столько кода мы не можем».Ибо законы Паркинсона и Мерфи не обмануть!!!
Ну они написали про апи вроде :). Помнится с KMS тоже некоторые вопили о том как им это не надо и прочая. А как остались без драйверов - вполне себе потопали реализовывать. В таком виде понятно даже stubborn bastard'ам.
> Ну они написали про апи вроде :). Помнится с KMS тоже некоторые
> вопили о том как им это не надо и прочая. А
> как остались без драйверов - вполне себе потопали реализовывать. В таком
> виде понятно даже stubborn bastard'ам.Редхат курируют гном и системде: embrace. Реализует сам, cron, xinet, syslog, shell-scripts :extend. Зависим от dbus, udisks, upower, etc. Уничтожил независимость udev, console-kit, policykit, etc: extinguish. Vendor-lock, в случае что мы сейчас наблюдаем. Только под "свободным" соусом от гномовцев: а зависеть ли нам дальше, а не зависеть ли, а может апи необходимы , а может нет - сродни отмазкам наркомана.
А про KMS - отборный бред. Что, можно остаться без дров, если не использовать KMS?))
> Vendor-lock, в случае что мы сейчас наблюдаем.В открытом софте невозможен полновесный вендорлок. Чисто технически. Помнится с glibc уже был "вендорлок". Ну и появилось сколько-то форков, которые фильтровали выходки Ульриха, eglibc как наиболее известный (многие просто допатчивали за апстримом, не называя сие полновесным форком). Вот и вся недолга. Процесс самобалансирующийся. Пока идет балансировка - может трясти. Но в целом - если есть большая нестыковка того что ALL хотелось бы с тем что есть по факту - кто-то где-то что-то форкает и допатчивает. Если это было реально востребовано - срубает EPIC WIN. А если это десяток безблагодатных изенобразных бакланов на форуме пиндели о том как надо, но код своего "надо" писать не желали - оно постепенно сливается, куда и дорога.
>Только под "свободным" соусом от гномовцев: а зависеть ли нам дальше,
> а не зависеть ли, а может апи необходимыЕсли ничего не менять и бесконечно париться о совместимости - мы бы до сих пор пеклись о наличии торб с овсом для лошадей и воды и дров для паровозов. А оно такое надо?
> А про KMS - отборный бред. Что, можно остаться без дров, если
> не использовать KMS?))Ну вот так вот и можно. Современные драйвера GPU пишутся с KMS-only интерфейсами. Скажем, UMS версии драйвера RadeonSI не существует совсем, да и остальные нынче повыбросили остатки UMS-интерфейса, так что некрофилы могут на выбор или тусовать с древними, тормозными и бажными версиями, имеющих некислые проблемы с поддержкой половины GPU, особенно новых, или распереться и запилить KMSное API в своем ядре, уж как им там удобнее. Еще на выбор можно самостоятельно дрова писать, но тут уже от своей крутизны пупок может развязаться. Запилить KMSный интерфейс явно проще.
Не исключаю что systemd-like api может стать чем-то подобным. При том желающие смогут запилить его и иначе. Например, думается Canonical вполне себе впилит его через апстарт. А более-менее унифицированное апи для запуска контейнеров и впихивания в них сеансов и прочая - не самая плохая штука для системы из XXI века.
>> Vendor-lock, в случае что мы сейчас наблюдаем.
> В открытом софте невозможен полновесный вендорлок. Чисто технически.я вижу его попытку, а ты говоришь что он невозможен. Мы либо о разном говорим, или об одном и том же не понимая друг друга.
> Помнится с glibc уже был "вендорлок".не коммерческая контора, мимо. давай по делу.
> Если ничего не менять и бесконечно париться о совместимости - мы бы
> до сих пор пеклись о наличии торб с овсом для лошадей
> и воды и дров для паровозов. А оно такое надо?ох уж эти метафоры. Под ней подразумевалось: системде - единственный правильный выбор, а всё остальное - прошлый век и должно умереть/никого волновать/etc?
>> А про KMS - отборный бред. Что, можно остаться без дров, если
>> не использовать KMS?))
> Ну вот так вот и можно.Параллельная вселенная такая параллельная.
> Не исключаю что systemd-like api может стать чем-то подобным.
Аххах, Апи? У системде? Еще стабильные небось! Реалисты, вы где? Тут одни мечтатели)))
> А более-менее унифицированное апи для запуска контейнеров и
> впихивания в них сеансов и прочая - не самая плохая штука
> для системы из XXI века.ты не мог контейнеры запускать без апи от системде?
да ну ладно тебе! Стильный, Модный, Прогрессивный пульсаудио схавали же? и Стильный, Модный, Прогрессивный системды схавают. уже схавали, собственно.
> да ну ладно тебе! Стильный, Модный, Прогрессивный пульсаудио схавали же?...пробурчал arisu с пульсом на N900, хоть и допиленным :).
>> да ну ладно тебе! Стильный, Модный, Прогрессивный пульсаудио схавали же?
> …пробурчал arisu с пульсом на N900, хоть и допиленным :).это, увы, не наша радость, а наша беда. впрочем, усилия FPTF позволят его выкинуть.
> это, увы, не наша радость, а наша беда.Да ладно, свое дело вроде делает, каких-то особых глюков или неприличного пожирания ресурсов оным я не вижу. Так что это имхо по состоянию на данный момент больше уже или религиозное или просто "ожегшись на молоке - на воду дуют".
> впрочем, усилия FPTF позволят его выкинуть.
А это кто такие? Что-то никак не допираю как это расшифровывается.
>> это, увы, не наша радость, а наша беда.
> Да ладно, свое дело вроде делает, каких-то особых глюков или неприличного пожирания
> ресурсов оным я не вижу.с mplayer'ом иногда дерётся. при некоторых условиях.
>> впрочем, усилия FPTF позволят его выкинуть.
> А это кто такие? Что-то никак не допираю как это расшифровывается.fremantle porting task force. tmo знает.
> с mplayer'ом иногда дерётся. при некоторых условиях.Ни разу не натыкался.
> fremantle porting task force. tmo знает.
А, понял. Я правда не понял - зачем они какое-то блобье собираются тащить. Как раз шанс избавиться от. Вон BME вроде выпнули. Честно говоря смысл в BME для меня загадка с тех пор как я осознал как рулить подобными чипами "интеллектуальных зарядников" и тому подобной фигни, которой у техаса есть.
> А, понял. Я правда не понял - зачем они какое-то блобье собираются
> тащить.вообще-то как раз наоборот — избавиться.
> да ну ладно тебе! Стильный, Модный, Прогрессивный пульсаудио схавали же? и Стильный,
> Модный, Прогрессивный системды схавают. уже схавали, собственно.Пульсаудио легко отключить (что я и делаю). С системды совсем другая история.
Большинству таких крикунов как ты на самом деле нет разницы, кто у них pid1. Просто кричим на религиозные темы, и то полуправда же.
udev, скандально потеснивший hal писали разработчики systemd. Шока от слияния кодовой базы не было. В linux никто от смены hal на udev не пострадал, только bsd и то потому что свой devd не пилили. consolekit умер немного раньше явления systemd=, они тут не причем.
А еще ты не в курсе про то, что такое vendor lock in. Исходники открыты, можно спокойно либо делать форки либо делать systemd-совместимые продукты. Например, upstart часть кода позаимствовал, часть сам поднаписал.
Кроме того привязка gnome к systemd не должна тебя интересовать, потому что gnome-ом ты вряд ли пользуешься. Пользовался - знал бы, что на самом деле там зависит от systemd. gdm от systemd-logind (выковыриваемо дистростроителями), и куча компонентов от systemd-udev (выковыриваемо, также есть сверхэмоциональные форки гентушников), которым никого не удивить.А вот насчет KMS предыдущий оратор сильно приврал. Я вот не пользуюсь KMS и УМВР, не хочу и не буду, блоб без вариантов (nVidia GTX 680). Для открытых драйверов всех мастей KMS безальтернативен.
> Большинству таких крикунов как ты на самом деле нет разницы, кто у
> них pid1. Просто кричим на религиозные темы, и то полуправда же.и то правда.
> udev, скандально потеснивший hal писали разработчики systemd.)) и consolekit/policykit. То что это писали _будущие_ соавторы - никто не спорит.
> Шока от слияния кодовой базы не было.
Шок - сильно сказано. Но то что пропали несколько продуктов, которых без здоровенного монолотненького системдеца не использовать - факт. Хотя... скажем затруднительно, ибо приходится плодить форки, когда причина для этого одна: авторы системдца хотят чтоб всё было завязано на них.
> В linux никто от смены hal на udev
> не пострадал,списки рассылки найдёшь в интернете /любого дистрибутива/любой программы/; Захочешь действительно глянуть - увидишь. А если как ты уже на меня намекал, главное заявить да покричать, ну тогда ладно. Только какая тогда между нами разница?
> consolekit умер немного раньше явления systemd=, они тут не причем.
еще бы, он стал logind, и потому старый бренд не нужен.
> А еще ты не в курсе про то, что такое vendor lockвкурсе-вкурсе. Не надо тут песенок про открытый код. Открытый код даёт преимущество программисту, а не пользователю.
> Кроме того привязка gnome к systemd не должна тебя интересовать, потому что
> gnome-ом ты вряд ли пользуешься.не о себе ж только думать!
> Пользовался - знал бы, что на самом деле там зависит от systemd. gdm от systemd-logind (выковыриваемо дистростроителями),
> и куча компонентов от systemd-udev (выковыриваемо, также есть сверхэмоциональные форки
> гентушников), которым никого не удивить.ну и чем заменить менеджер сеансов? дохлым console-kit'ом?
> А вот насчет KMS предыдущий оратор сильно приврал.
ой, да там стопроцентный бред, чувак. Даже мы адекватнее морозимся.
> несмотря на то, что systemd базируется на специфичных для Linux программных интерфейсах, данные API могут быть реализованы и в других ОСв генте пытались реализовать грёбанное апи от loginid, как раз для захардкоженного гнома на loginid. Оказалось, сделать этого нельзя, ибо у systemd нет никакого документирванного и стаблиного апи (считай, его вообще нет) и loginid никак не отделим от всего остального systemd.
а мне вот системды очень нравится. удобный очень. сказал человек, что «системды хорошо и прогресс» — и сразу ясно, что больше с таким человеком серьёзно говорить не о чем.
системды хорошо и прогресс
А у пользователя работает и пофиг на чём.
А это уже MS-way!
> системды хорошо и прогрессТеперь arisu придётся игнорить всех Анонимов...
> Теперь arisu придётся игнорить всех Анонимов...Аноним - это не человек, это единственная реплика. :-) Другая реплика - это уже другой Аноним. :-)
> Аноним - это не человек, это единственная реплика. :-) Другая реплика -
> это уже другой Аноним. :-)ну что ты злой такой? человеку хочется почувствовать себя Силой. «анонимус не забывает и не прощает», ага.
> ну что ты злой такой?Я не злой, просто меня смешит эта женская логика, когда человек надевает на себя маску Анонима и пытается вести разговор "переходя на личности".
Неужели тебя не веселит полное отсутствие рефлексии у отдельных комментаторов? :-)
> Неужели тебя не веселит полное отсутствие рефлексии у отдельных комментаторов? :-)меня тут большинство комментаторов так или иначе веселит — зачем бы я сюда ходил ещё?
а. ещё раз или два в комментариях подсказали хорошие софтинки. но читать все комментарии только ради софтинки раз в год…
> Я не злой, просто меня смешит эта женская логика, когда человек надевает
> на себя маску Анонима и пытается вести разговор «переходя на личности».и, кстати, быть анонимом и беседовать «личностно» — никакое не противоречие. вот ты, например — разве не можешь 294-го узнать? а ведь тоже аноним. а если изю в анонима переименовать — думаешь, никто не узнает? про себя и не говорю.
> и, кстати, быть анонимом и беседовать «личностно» — никакое не противоречие.Да, это не противоречие - если собеседник, например, я, хочет, он может проводить "байесовскую оценку", прикидывая написал две анонимные реплики один и тот же человек, или нет.
А вот в том, чтобы подписываться Анонимом и одновременно желать "перехода на личности", сквозит кристальная женская логика.
> вот ты, например — разве не можешь 294-го узнать?
Я не хочу этим заниматься.
>> вот ты, например — разве не можешь 294-го узнать?
> Я не хочу этим заниматься.вообще-то оно получается автоматически.
Кстати, после того, как я сподобился посмотреть архитектуру upstart я начисто перестал понимай хайп вокруг systemd - upstart просто спроектирован приличнее.
> Кстати, после того, как я сподобился посмотреть архитектуру upstart я начисто перестал
> понимай хайп вокруг systemd — upstart просто спроектирован приличнее.красношап же. NIH во все поля. libnih используется в upstart, а nih-синдром отчего-то у красношапа.
Угу :-) Кстати, эта libnih - то ещё чудо... Эмуляция деструкторов впечатлила. Честно говоря, лучше б взяли плюсы, наваяли стайлгайд, запрещающий 95% из возможностей, и использовали их как "better C".
я вообще не читал, что там внутри, люблю только за название.
да я тоже, просто поискал в нете и в числе прочего попалась статеечка, вот: http://ifdeflinux.blogspot.com/2012/05/quick-libnih-tutorial...А название зачетное, да.
И цели проекта хороши:
Its goals are:
* despite its name, to _not_ reimplement anything found in the
standard C library or any library normally found in /lib;* use standard C types and conventions where appropriate;
* have a simple and consistent programming interface;
* be useful to library developers without needing to be exposed in
the library's API;* not hide implementation details or structure contents, we're all
adults after all.
Лично мне всё это весьма близко.
насчёт «safe» — это они, конечно, круто загнули. не знаю, поменяли ли уже, но раньше, например, libnih при выделении памяти упорно крутила цикл, пока malloc() не вернёт !NULL. это, без сомнения, очень новаторский подход к обработке ошибки «что-то с памятью моей стало».
Не, это у них в TODO лежит. С другой стороны - если мы о применении в upstart речь ведем - то если на инит памяти не хватило, то на что ж её хватит? А если это пользовательский апстарт - то вроде и логично. Тем более, что сейчас в ядре вроде сибирались избавляться от OOM в пользу возврата ENOMEM (что, как по мне, весьма логично)
неа, мы тут о libnih речь ведём. и в той же статье, на которую ты дал ссылку, в примере как раз рекомендуют цикл «пока не надоест» (посмотри на макрос). за такое надо отрывать руки по самые ноги.
Если не в контексте апстарта - то да, полностью согласен
> Если не в контексте апстарта - то да, полностью согласенда и в контексте… я очень не уверен, что идея «крутить цикл, пока не дадут памяти» для инита — хорошая идея. ну дык и не надо совать в инит service manager, не место ему там.
> Если не в контексте апстарта - то да, полностью согласенВообще-то иногда желательно знать, из-за чего система повисла при загрузке. :-) Поэтому malloc в бесконечном цикле - не наш метод.
Ну, в ините это предельно маловероятная ситуация. Хотя тем более непонятно, зачем такое чудо
> Ну, в ините это предельно маловероятная ситуация.Оптимизм - это хорошо. Особенно в древних инитах где параллелизации вообще нет - там клинч любого процесса все нагнет. Некоторые субъекты так прикольно условия под ответ подгоняют :).
зачем в *ините* какая-то «параллелизация» вообще? O_O
> зачем в *ините* какая-то «параллелизация» вообще? O_OЗатем что процессы бывают разные. Некоторые например взлетают несколько минут и это может быть совершенно нормально. Совсем не комильфо ставить р@ком при этом вообще все.
ещё раз спрошу: какое к этому отношение имеет *init*?
> ещё раз спрошу: какое к этому отношение имеет *init*?Самое элементарное: если он не параллельный, остальные будут в это время курить бамбук, как минимум без подстановки каких-то сильно отдельных костылей. В более современных инитах сие осознали, даже в sysv-образных вроде как сие запилили уже. А раньше, если меня склероз не подводит, даже получение IP по DHCP могло все поставить колом до нехилого таймаута, если что-то не срослось.
можно увидеть код, который за это «раньше» ответственен? я всё ещё хочу понять, при чём тут «параллелизация в ините», какое отношение инит имеет к «получению IP по DHCP» и что такое тебе подсунул твой дилер, что тебя уже какой день не отпускает.
> Тем более, что сейчас в ядре вроде сибирались избавляться от OOM в пользу возврата ENOMEM (что, как по мне, весьма логично)от OOM можно и сейчас избавиться выключив overcommit. Иначе от него избавиться в пользу ENOMEM невозможно. Ты что-то не так понял в той новости, либо переводчик в очередной раз в процессе родил новость из другой вселенной.
Из новости про 3.12: Интегрирован улучшенный алгоритм OOM (out-of-memory), более корректно обрабатывающий состояние нехватки памяти в системе, но способный привести к появлению ранее не фиксированных ошибок категории "out of memory" в пользовательских приложениях. Основное отличие от ранее используемого алгоритма сводится к тому, что при запросе блока в ситуации исчерпании доступной памяти, процессу теперь возвращается ошибка выделения памяти (ENOMEM) вместо поиска и принудительного завершения прожорливого процесса.Вот более детальное англоязычное описание: https://lwn.net/Articles/562211/#oom
"И вместо рака будет грыжа". Теперь мы узнаем много нового о том как програмеры кладут болт на коды возврата системных вызовов и как они потом пытаются работать дальше, как будто бы сискол успешно завершился. Ну а потом через полчаса счета программа все-таки упадет, нарвавшись на явный левак, который никто никогда и близко не ожидал. Счастливой отладки :).
1)Освобождение локальных переменных (объявленных внутри блока {}) есть задача компилятора, а он nim_ функцию подсовывает.
2)Инициализировать указатель NULL-ом "в школе учат".
Просто он дает возможность дебilам, которые не хотят учиться, почувствовать себя адскими админами.
Что курим? Админы всего этого вообще не видят, это касается только программистов
> Что курим? Админы всего этого вообще не видят, это касается только программистовСори. Оговорка по Фрейду.
К системД это относиться в полной мере.
Просто когда начинаешь городить огород "защта от дурака" - имеешь все прелести в полной мере. А nih_ это только начало.
> Сори. Оговорка по Фрейду.
> К системД это относиться в полной мере.
> Просто когда начинаешь городить огород "защта от дурака" - имеешь все прелести
> в полной мере. А nih_ это только начало.Незаметно становишься на путь MS и дураков становится больше, а затем умные уже выглядят как изгои или мамонты.
Unix-way - дурак должен быть виден сразу.
Рутина вида "явно освободить бъект при уходе из контекста, где объявлен указатель на него" к уму не относится, как мне кажется. Осбенно если учесть, что объектом может быть struct со своими указателями, которым тоже надо сказать free... и так далее. Вот nih_ функции это и делают - мониторят и рекурсивно освобождают память.
Переменные - да. А косвенно адресованные объекты, вроде строк тех же?
Вот и сделали они умные указатели, которые освобождают выделенную память при выходе из контекста. Идея, прямо скажем, не новая, но вот в сях - впервые вижу.А инициализировать указатель NULL-ом - обычно учат для упрощения поиска багов, но в прицнипе оно на работу обычно не влияет. Здесь отличие в том, что без этой инициализации сразу имеем проблемы. Ну что сказать - надо было всё же плюсы брать, хотя бы в варианте "Better C".
> надо было всё же плюсы братьненене, уносите. подальше. и пусть их там берёт кто хочет. деструкторы локальных переменных — это очень удобно, сам использую. а ещё — ты не поверишь — объектную систему иногда, основаную на прототипах и посылке сообщений. правда, всё никак не соберусь написать к ней какой-нибудь препроцессор на том же peg.
Ну и чем тебе плюсовый умный указатель и RAII будут хуже, даже если ты больше вообще из плюсов ничего не будешь использовать? Тем, что оно вылизано сто раз, в отличие от костыля (не спорю, красивого)?У тебя на плюсы какая-то чрезмерно резкая реакция. В них дофига инструментов, ну пользуйся теми, которые тебе подходят, а какое-нибудь виртуальное множественное наследование оставь тем, кого оно устраивает, делов-то.
> Ну и чем тебе плюсовый умный указатель и RAII будут хужеname mangling? спасибо, помойка через два квартала.
> У тебя на плюсы какая-то чрезмерно резкая реакция.
как на любого бесполезного уродца, которого отчего-то считают королём.
> ну пользуйся теми, которые тебе подходят
ты не поверишь: получается обычный си. иногда — с __attribute__((cleanup)).
А что манглинг? Манглинг роляет только если либу пишешь, которую из других языков использовать будут, в остальное время ты его не видишь. Так для интерфейсного можно extern "C" сказать.Лично я плюсам в своё время за RAII и STL продался, о чем не жалею совершенно. Ну и фокусы вроде do_something_with_foo(foo *self) раздражают. Раз оно в каждой второй программе - значит языковый механизм очень даже к месту.
Но дело хозяйское, конечно.
> А что манглинг? Манглинг роляет только если либу пишешь, которую из других
> языков использовать будут, в остальное время ты его не видишь.будут. у меня куча проектов на си, например. я имел в глубоком виду их все под цпп точить (некоторые из них вообще собираются самопальным — ну ладно, спёртым и допиленым — компилятором, который про цпп знать не знает).
> Так для интерфейсного можно extern «C» сказать.
хреновато в «си интерфейс» классы торчат, однако. а без классов хреновато деструкторы работают.
> Лично я плюсам в своё время за RAII и STL продался, о
> чем не жалею совершенно. Ну и фокусы вроде do_something_with_foo(foo *self) раздражают.
> Раз оно в каждой второй программе — значит языковый механизм очень
> даже к месту.да идея с объектами-то хороша. c++ плохой просто. вот если бы губы Никанора Ивановича, да приставить к носу Ивана Кузьмина, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича…
то есть, Objective C взять, да ещё чуть-чуть его допилить, да чтобы на этом не один я писал…
> самопальным — ну ладно, спёртым и допиленым — компилятором, который про
> цпп знать не знает).Хе, это под какие-то экзотичные архитектуры?
> на этом не один я писал…
Самые большие грабли, пожалуй :\.
>> самопальным — ну ладно, спёртым и допиленым — компилятором, который про
>> цпп знать не знает).
> Хе, это под какие-то экзотичные архитектуры?нет, под x86. отчасти собираю просто потому, что прикалывает компилятор допиливать, а отчасти по нужде. ну вот есть иногда желание с собой компилятор носить и «докомпиливать».
У тебя что там - какой-то эмбед суровый, что левый компилятор C?
> У тебя что там - какой-то эмбед суровый, что левый компилятор C?никогда не думал, что во-первых, писать компиляторы мне может просто интересно? а во-вторых, для некоторых моих ручных монстриков есть причина носить с собой небольшой, но рабочий компилятор си «в коробке». нет, ничего такого, что нельзя сделать иначе — просто мне так понравилось.
А, если самописный - тогда вопрос другой. Но монстрики, видать, забавные.
> А, если самописный - тогда вопрос другой. Но монстрики, видать, забавные.да так, в основном генераторы правил и dsl. естественно, ни разу не для какого-нибудь «продакшэна» — так, исключительно по причине: «ну вот, у нас есть компилятор. надо же теперь хоть что-нибудь с ним сделать!»
> Лично я плюсам в своё время за RAII и STL продался, о
> чем не жалею совершенно. Ну и фокусы вроде do_something_with_foo(foo *self) раздражают.
> Раз оно в каждой второй программе - значит языковый механизм очень
> даже к месту.RAII всем хорошо, кроме того, что оно необязательно - забыл поставить в деструкторе delete нужного поля - пролетел.
RAII меня тогда больше освобождением не памяти впечатлило, а внешних ресурсов - локов всяких, файлов. А что до памяти - её везде забыть можно, даже с GC запросто висячие ссылки остаются. Но деструкторы и GC остроту проблемы сильно снимают.
1)Память освобождается по принципу стэка. Контекс он и в С контекс (как переменные окружения в шеле)
2) Ну да по принципу: Представим что дuрак не инициализировал правильно указатель, не будем его обижать а напишем хелпер.
о, Видущий Орхитектор вылез. вы не обращайте внимания на то, что он говорит: его неупоротым никто никогда ещё не видел.
http://dvo.sut.ru/libr/cvti/i618buz/8.htm
Объекты класса auto имеют локальное время жизни и локальную область видимости – только ту функцию или тот блок, где они объявлены. Такие переменные называются автоматическими. По умолчанию, т. е. без указания класса, все переменные, объявленные внутри блока, относятся к классу auto. Переменная класса auto начинает существовать при входе в блок, в котором она объявлена. Память под автоматическую переменную выделяется в стеке. При выходе из блока переменная автоматически исчезает. При этом память, отведенная под эту переменную, освобождается. При повторном входе в блок для этой переменной может быть выделен другой участок памяти.
специально для идиотов я повторяю вопрос: кто должен освобождать память, выделеную по strdup(), указатель на которую сохранён в локальной переменной типа 'char *'?
http://ru.wikipedia.org/wiki/Strdup
если ты уничтожил указатель (объявив его auto), а потом ищешь вне блока - то хелпер как раз для тебя.
> о, Видущий Орхитектор вылез. вы не обращайте внимания на то, что он
> говорит: его неупоротым никто никогда ещё не видел.Ты можешь его деанонимизировать? Больно реплика смешная (см. ниже).
> Ты можешь его деанонимизировать?неа, дураков особо не запоминаю. да и похожи они, как трое из ларца. «неанонимные анонимусы» обладают весьма узнаваемым стилем и некоторыми «флажковыми» темами. а эти… ни кожи, ни рожи. я их объединил давно в Большого Бухарца.
Контекс (contex) - это презервативы такие.
> А инициализировать указатель NULL-ом - обычно учат для упрощения поиска багов, но
> в прицнипе оно на работу обычно не влияет.Ну мы же можем проверить, прошло копирование или нет в помощью сравнения с NULL.
А, ну да. Это ж си, я забыл, что там нет исключения по нехватке памяти, ни соответствуюа каждое выделение надо обрабатывать отдельно. Хоть бы хук соответствующий добавили, что ли, а то в каждой функции проверять - это жесть.
какой жестокий бог запретил тебе сделать нужные функции с хуками?
Да мне и свой компилятор никакой жесткий бог писать не запрещал. Только если все делать самотужки - до результата можно и не дожить. Не говоря о том, что самодельная функция с хуками не спасёт от ENOMEM в какой-нибудь другой используемой либе.
> Не говоря о том, что самодельная функция с хуками не спасёт
> от ENOMEM в какой-нибудь другой используемой либе.сесть перед системным malloc не?
Что-то не соображу, как это сделать без извращений с линковкой
> Что-то не соображу, как это сделать без извращений с линковкойда с извращениями, конечно. но это само по себе особого смысла не имеет: ну, будет у тебя callback. толку? всё, что он сможет хорошего сделать — это с воплями упасть. потому как если библиотека не обработала проблемы с памятью, то и cleanup за собой не сделала. ну, вылетишь ты оттуда через longjmp() — а будет ли потом нормально работать, так это бабушка надвое сказала уже.
проверяй-проверяй. руками. чай, не отвалятся. си, всё-таки.
Хм, в плюсах оно как-то так (ага, там хендлер тоже есть, кроме эксепшнов и возможности глобально переопределить new): если не удалось выделить достаточно памяти и установлен твой хендлер, он вызывается. В нем ты можешь что-то сделать (допустим, освободить какую-то память). Ечли считаешь, что получилось - нормально возвращаешься, и new повторит попытку. Иначе - выбрасываешь исключение или завершаешь программу.А чего библиотека что-то там не обработала? Она о проблеме еще и не знает.
я тебе скажу, что если у тебя есть возможность «освободить какую-то память», то какого чёрта она вообще ещё не освобождена? на кэши растранжирил, небось.ну и да: эта вся красивая плюсовая механика радостно обламывается на первом же malloc() внутри чужой библиотеки. адьёс, амигос.
Да много на что. Кэши - один из вариантов. Дорогая сборка, которую откладываем до последнего - другой.Вот пример: есть у меня вьюер PDF. Я, натурально, постараюсь декодировать и держать в памяти кроме текущей страницы еще сколько-то до неё и после, чтобы юзверю мгновенно показать. Чего ради мне их освоождать без надобности?
Или у меня мутная структура данных из кучи элементов, которые в принципе можно и освободить, но мне остался последний этап работы, после которого вообще процесс завершится.
Или я могу ради освобождения памяти временно придушить размер каких-то буферов, что скажется на производительности, но хоть как-то сфотина продолжит работу, а не вылетит.
Или у меня полуживой процесс обсчета чего-то, жрущий память, которы я в принципе могу сейчас убить и дапустить позже (какое-нибудь индексирование того же PDF, скажем)... В общем, много чего может быть.
И ни фига эта механика не обламывается на чужих аллокациях, в том-то и фишка. По крайней мере пока это плюсовые аллокации - один хрен вызов к тому же рантайму идёт. С malloc из сишной библиотеки - да, там обращение к другому рантайму, сишному, коорый этого не умеет. А вот сишная не обломилась бы ни в каком случае - нет в сях других способов память получить, разве что полность заново memory management реализовывать, но это уже совсем экзотика.
> Да много на что. Кэши - один из вариантов. Дорогая сборка, которую
> откладываем до последнего — другой.да пошутил я про кэши. хотя ты ведь сплошные кэши описал, сам посмотри. :3
> И ни фига эта механика не обламывается на чужих аллокациях, в том-то
> и фишка. По крайней мере пока это плюсовые аллокации — один
> хрен вызов к тому же рантайму идёт.я не зря про malloc() написал. к моему счастью, системные библиотеки пока в большинстве своём написаны на си, а не на цпп.
> нет в сях других способов память получить, разве что
> полность заново memory management реализовывать, но это уже совсем экзотика.есть, есть. wrapper, например. а многие библиотеки и вовсе имеют API для задания функций malloc()/realloc()/free(). да, это не обязательно — так и в цпп никто силой не заставляет везде new использовать, тоже по договору.
а вообще — спор дурацкий. смотри вот сюда, например: http://www.gnu.org/software/libc/manual/html_node/Hooks-for-...
хоть обвешайся своими хуками. да, glibc-specific. ну так не пиши под системы, где таких механизмов нет. :3
Вообще-то не совсем сплошные :-) Я описал еще вариант некритичного процесса, который может быть прерван, и вариант, когда сборка мусора отложена в надежде, что е вообще делать не придется. Кешами я бы это не назвал. Хотя да, кеши более распространены - и что, не юзать их, что ли? Хороши ведь, заразы.По хукам - я это видел, но эта дока ни хрена не специфицирует их поведение ни для чего кроме отладки, так что, как минимум, придется жирно копаться в коде чтобы понять, как это корректно использовать - и то гарантии никакой, что оно будет работать на другой версии - undocumented же. А против glibc-specific и gcc-specific я никогда и не возражал. В том числе поэтому полагаю, что если соответствующий хендлер туда засунуть или эти описать толком - то проблема либ на C, которые это не умеют, будет снята автоматом.
> По хукам - я это видел, но эта дока ни хрена не
> специфицирует их поведение ни для чего кроме отладкину, пример по ссылке достаточно чётко показывает, как их использовать. их *рекомендуют* для отладки, но работает оно везде. хуже то, что их в deprecated перевели.
но я тоже не понимаю, почему нет таких официальных хуков, злобно задокументированых в камне. понятно, что это bad practice, но у нас же си, ёлки-палки — если я хочу прострелить ногу, то дайте же мне уже стандартное ружьё, а не прячьте стыдливо обрез под полой!
> бы хук соответствующий добавили, что ли, а то в каждой функции
> проверять - это жесть.Чувак, си довольно мощная и гибкая штука. Как тебе номер с полностью статичным распределением памяти, без динамического выделения вообще? В си так можно. А вот если с ножом к горлу навязать какой-то крап - все сломается. И не получится потом си юзать в эмбедовке всякой, где надежность важна.
Аксиома: если динамического выделения памяти нет - оно не сможет обломаться. Поэтому высоконадежный встраиваемый софт зачастую использует статичное распределение памяти. И тебе врядли понравится ошибка выделения памяти в проце выкидывающем подушки безопасности чтобы горе-ездок не размазался о стену. Поэтому когда ты думаешь что нечто надо заоптимизировать - подумай немного своей черепушкой что существующее положение дел может быть и не только потому что все вокруг глупые, а ты самый умный, но и по другим, более разумным причинам.
Да успокойся, в этом треде новичков нет.И заодно расскажи мне, как возможность вызвать в нештатной ситуации обработчик, если он установлен пользователем, мешает тебе писать код без динамического выделения. Если не понял, о чем речь - я тут комментом выше объяснил, как оно в плюсах сделано.
Я-то веду речь о самом распространенном случае - обычный десктопный или серверный софт, который работает рядом с чем-то еще и, соответственно, должен быть скрмным и лишнюю память не жрать, и при этом, понятно, омжет на нехватку памяти и нарваться иногда.
> Да успокойся, в этом треде новичков нет.А зачем тогда в 100500-й раз заводить одну и ту же волыну?
> И заодно расскажи мне, как возможность вызвать в нештатной ситуации обработчик, если
> он установлен пользователем, мешает тебе писать код без динамического выделения.Например, тот факт что такового обработчика и инфраструктуры под него быть вообще не обязано. А кому реально надо - таки сделал. Видал и "malloc с retry и таймаутом" например. Ну то-есть получив отлуп вида "ой, памяти нету" - оно подождет, сунется еще раз (или несколько). Если лучше так и не стало - делается вывод что системе настал совсем крындец и возвращается ошибка, инициирующая обработку "полного крындеца".
Еще как вариант: можно выделить себе заранее большой блок памяти системным malloc, выюзать, а потом оттуда уже все раздавать на внутрипрограмные нужды. Получится свой менеджер памяти с своей логикой работы. Возможно опять же сильно кастомной и удобной в какой-то конкретной ситуации. Си хорош тем что все это - можно. А в какой-нть гламурной яве народ с ее рантаймом и дурными свойствами оного воюет дольше чем написать кастомный аллокатор с желаемыи свойствами, etc. Прикольно такое видеть - это называется "горе от ума".
> Если не понял, о чем речь - я тут комментом выше объяснил,
> как оно в плюсах сделано.Мне не особо нравятся плюсы. Они какие-то переусложненные. Хотя возможно это и есть разумный баланс между совсем г-нокодом явы и совсем простым как топор си.
> Я-то веду речь о самом распространенном случае - обычный десктопный или серверный софт,
Стоп-стоп, си - он не только для этого. И об этом не следует забывать. И даже на десктопе и сервере сями собраны и довольно загогулистые штуки типа бутлоадеров, у которых довольно кастомные требования, ибо они запускаются на неинициализированном железе зачастую. Вплоть до того что кто-то должен DRAM проинициализировать до того как туда можно будет мегазы хлама вгрузить, например. А ничего что это тоже код делает? И он тоже на си писан. И совсем не айс если такое отвалится, имхо. А если с ножом к горлу осчастливливать - таки отвалится и поломается. Кому все надо - автоматическую задоподтиралку - есть ява, например. Чего вам си дался? Да, си - не игрушка для овощей типа изена, которые больше похожи на обезьяну с гранатой. Си никогда для такой аудитории не предназначался.
Твою мать, что ты мне тут механику работы арен расписываешь и объясняешь, что на сях бутлоадеры пишут и оборудование инициализируют? Я, вообще-то, в курсе.До тебя в самом деле не доходит, что речь о стандартной библиотеке, которая, между прочим, и так включает ни хрена не детерминированный malloc? Ну и кому было бы хуже, если б этот malloc умел звать пользовательский хелпер, если память сам выделить не может?
вот про кастомные аллокаторы не надо: в цпп этот механизм сделан сильно круче.
> 1)Освобождение локальных переменных (объявленных внутри блока {}) есть задача компилятораа освобождение памяти по указателю чья?
Systemd хорошо и прогресс.Сырой пока правда, но то дело наживное.
А мне, вот, посты на форумах очень нравятся. Начал человек лепить ярлыки, и сразу ясно, что человек - полный утырок и разговаривать с ним не о чем.Или можно еще по-другому.
А мне, вот, посты на форумах очень нравятся. Смотришь - человек не владеет родной речью даже на уровне пятиклассника и думаешь: "Что интересного может быть в человеке, если он даже русский язык не в состоянии осилить?"
и это тоже.
Logind отлелим от systemd. В Ubuntu, например, первый есть, а второго нет.
холивар подан, садитесь жрать пожалуйста.Gnome и systemd из категории "не нужно" имхо переходят в категории "пошли нах" и "посоны поделитесь тем, что вы курите".
>опровергли информацию, что проект становится зависимым от systemd
>поддержка ранее используемых средств управления сеансами и систем без systemd будет сохранена, но как долго продлится такая поддержка пока не ясно
>зависимость от logind была отклонена перед релизом, но при работе GNOME 3.8 без systemd наблюдаются проблемы.Я не понимаю, где тут опровержение.
"Это не мы зависимые, это вы какие-то не такие."
>>опровергли информацию, что проект становится зависимым от systemd
>>поддержка ранее используемых средств управления сеансами и систем без systemd будет сохранена, но как долго продлится такая поддержка пока не ясно
>>зависимость от logind была отклонена перед релизом, но при работе GNOME 3.8 без systemd наблюдаются проблемы.
> Я не понимаю, где тут опровержение.Ну, зависимость пока ещё не выработалась. Но без него уже плохо.
Давайте, вы сможете слезть, мы в вас верим.