0xd34df00d
14.03.2013 06:12 Azoth_primary
[10:07:45] track_desk: 0xd34df00d: модули это не про то.
[10:10:08] track_desk: когда будет личкрафтИМ и личкрафтБраузер это будет 2-е программы, а когда личкрафтИмБраузерТорентокачалка это комбаин
Чят, как бороться с такими стереотипами?
46 comments
recommend
bookmark
subscribe
это не стереотип. Это так и есть.
Толстовато.
я на полном серьезе.
Вопрос в том, в чем разница. В АП? Нет, как выяснилось. В окнах? Нет.
Послать на хуй, найти единомышленников и продолжать писать Linux^W Leechcraft. Есть же истории успеха. Вот Qt печалит как база — это да.
это не стереотипы, а так и есть. если хочешь делать DE — делай DE, а не комбайн.
разница в том, что отдельные независимые приложения — это одно. А куча приложений, 95% которых не работает друг без друга — это комбайн.
Что такое комбайн, по-твоему?
> не работает друг без друга
FF не работает без gtk и без либц, получается, это все комбайн?
не передёргивай. тулкит и базовая либа — не "приложения", а таки библиотеки.
когда ты приводишь такие аналогии у меня создается впечатление, что ты идиот и продолжать с тобой разговор после этого у меня пропадает всякое желание. U
Слился, лал.
Так модуль качалки по хттп или secman — тоже этакая библиотека. В чем проблема?
Блин, фуд, так бы и указал в тегах, что это вброс. Все же знают, что нормальные приложения — комбайны.
> Все же знают
Как же я люблю этот аргумент ^___^
http://en.wikipedia.org/wiki/Sarin
Сцуко, я теперь полдня буду читать то, что наоткрывал по вики.
ты сам понял, почему твой аргумент невалиден, или пояснить?
Поясни.
по твоей логике — файрокс должен быть библиотекой, а глибц приложением
Ты как-то очень извращенно понял мою логику.
// если что, суть была в том, что 95% модулей зависит от пары-тройки других utility-модулей. Пошуки не зависят от агрегатора, хотя вместе им лучше и веселей.
нет, ты именно такой аргумент привёл про модуль качалки и секман
Аргумент в том, что secman/cstp не видны для пользователей и выглядят вполне себе этакими либами с семантической точки зрения.
сделай ядро библиотекой, сделай плагины приложениями. Тогда поговорим.
и что? кого ебёт этот аргумент? он не относится к вопросу.
Зачем гланды удалять автогеном, да еще и через жопу? Текущая архитектура логичнее и стройнее.
Вполне относится. Зависимость-то только от них.
текущая архитектура для уёбков-комбаиноблядей
при чём тут зависимость?
Ты идиот или просто @mva?
Речь шла про зависимости модулей друг от друга. Я разворачиваю это утверждение и объясняю, почему ссылаться на него некорректно.
речи про зависимость модулей друг от друга не шло. речь шла о том, что подход одно ядро + миллионы говна — крайне уёбищны для DE.
*щен
Эм, ты можешь обосновать, почему оно уебищно?
И я, если что, отвечал на
> А куча приложений, 95% которых не работает друг без друга — это комбайн.
уёбищно оно хотя бы потому (один из тысячи аргументов), что придёт дядя OOM-killer в гости, и въебёт по ядру. И всё сразу сдохнет. Если же будет использоваться распределённый подход — дядя OOM-killer въебёт только по одному модулю, сохранив работоспособность всего остального.
А если либы-плагины запускаются в отдельных процессах отдельным экзешником-раннером?
алсо, я ещё не коснулся твоего синдрома утёнка, проявляющегося плюсо-и-кути-ёбстве и нежелании взглянуть хоть бы даже на тот же EFL ;)
Взглянул. Проблевался. К сожалению, плюсы и кути — самое адекватное для написания приложений такого масштаба.
Кстати, чем EFL лучше?
то будет второй вариант, потому что если какое-то приложение начнёт охуевать — OOMk придёт за ним, а не за раннером. За раннером он в данном случае уже придёт только если выёбываться начнёт он сам.
Эм, вообще-то придет за раннером.
хуй тебе
Пруф или нет.
пруф обратного или да
Твоя мама ест детей // пруф обратного или да.
твоих