LINUX.ORG.RU

Подскажите CMSку моей мечты

 


12

9

Сразу скажу, не уверен, что такое вообще существует в природе, ибо требования у меня противоположны всему, что сейчас воспринимается как мейнстрим. В общем, нужна CMS для сайтов, которые заведомо _не_ относятся (и никогда не будут относиться) к категории «высоконагруженных». При этом имеются два совершенно категорических требования:

1) свободное распространение и использование без ограничений (в том числе без всяких обязательных ссылок и т.п.)

2) ничего тьюринг-полного на стороне клиента; JS, HTML5, CSS3 запрещены под страхом смертной казни, то есть если CMS генерит что-то из перечисленного, то она не рассматривается вообще, вот то есть даром не нужна; в идеале — генерит XHTML и использует мелкий CSS-файлик на десяток классов;

Кроме того, есть ещё несколько более мягких, но тоже существенных пожеланий:

3) Язык реализации. В идеале она вообще должна быть написана на C или C++ с использованием минимума (лучше — zero) внешних библиотек, но такого, скорее всего, не бывает. PHP я терпеть ещё готов, Perl с его системой библиотек и dependecny hell — уже с трудом, что касается Питона, Руби, Джавы и прочей экзотики — мне проще будет её самому написать. Или без сайта обойтись.

4) Хранилище. Идеальная с моей точки зрения CMS не использует никакие СУБД вообще от слова совсем, то есть даже SQLite. Для хранения всего и вся — обычные текстовые файлы в обычных директориях.

5) Кастомизация. Сменные темы, среди которых есть что-нибудь лёгкое и НЕ привязанное к конкретной ширине экрана.

При этом она должна обязательно поддерживать настраиваемую навигацию, блоки, появляющиеся на определённых страницах (на всех или на некоторых), а также пользовательские комментарии (крайне желательно, чтобы пользователи могли заходить со своими OpenID — да, я имел в виду именно OpenID, а не OAUTH).

Если кто видел что-то подобное, киньте ссылочку :-)

★★★

Ответ на: комментарий от anonymous

В первую очередь я имел в виду самого Сантаяну...

anonymous
()
Ответ на: комментарий от Croco

Если на стороне клиента имеется интерпретатор тьюринг-полного языка, который согласен выполнять программы на этом языке вне зависимости от их источника, то это является уязвимостью само по себе.

Нет, не является. Более того - наличие тьюринг-полноты даже не коррелирует с уязвимостью.

То есть возможность DoS возникает ровно в тот момент, когда появляется интерпретатор.

Это, конечно, чушь. Во-первых, отсутствие тьюринг-полноты не говорит о невозможности зависания (действительно, язык с единственной конструкцией hang позволяет писать зависающие программы, но не ть.ринг-полон), во-вторых, это не говорит о разрешимости задачи анализа сложности, в-третьих - нет никакой разницы между программой, которая зависла, и программой, которая закончит работать к тому моменту, как Солнце потухнет. Например, np-complete задачи разрешимы формально, но неразрешимы на практике.

Кроме того, есть ещё тезис (если угодно, назовите его тезисом Столярова, хотя я практически уверен, что это высказывали до меня, и не раз): задача написания НЕдырявого тьюринг-полного интерпретатора превосходит человеческие возможности... Тезис, очевидно, недоказуем

Более того - он элементарно опровергается на практике. Интерпретатор комбинаторного исчисления пишется элементарно (парсер скобочного выражения + ф-я подстановки), тьюринг-полон, при этом занимает пару десятков строк и по устройству элементарен - поэтому ошибаться там негде. Парсер хмля (даже невалидирующий) сложнее на порядки.

anonymous
()
Ответ на: комментарий от Croco

При этом виды бесконечностей как раз излагают в курсе математического анализа, в самом его начале, как раз где-то рядом с производными.

Вообще-то не всегда, т.к. во-первых для того чтобы заниматься матаном это не нужно, от слова совсем, а во-вторых матан сам по себе, идеологически, занимается счетными объектами. Просто потому что теория непрерывных ф-й на сепарабельном пр-ве элементарно эквивалентна (как нестандартное расширение) теории ф-й на всюду плотном подмножестве этого пр-ва.

anonymous
()
Ответ на: комментарий от anonymous

наличие тьюринг-полноты даже не коррелирует с уязвимостью.

Как я уже говорил, практика показывает прямо противоположное. Я ещё не видел сообщения о найденной эксплойтабельной дыре в браузере, чтобы там тут же не говорилось, что эксплойт использует JS (или Java — в те времена, когда она ещё часто встречалась в браузерах) — даже когда дыра не в интерпретаторах, а, например, в анализаторе jpeg.

Это, конечно, чушь.

Сам ты чушь

Во-первых, отсутствие тьюринг-полноты не говорит о невозможности зависания

Разумеется, не говорит. Но это никоим образом не опровергает моего тезиса: при НАЛИЧИИ тьюринг-полноты зависание не только возможно, но и при этом заведомо невозможно сказать, произойдёт оно или нет. Ну а неприятность, которая может произойти, обязательно произойдёт — это понятно или тоже надо объяснять? :-)

язык с единственной конструкцией hang

... не существует в природе. А если его сделать, то вряд ли кому-то придёт в голову засунуть его в браузер, хотя я уже ничему не удивлюсь.

нет никакой разницы между программой, которая зависла, и программой, которая закончит работать к тому моменту, как Солнце потухнет

Совершенно верно, и что? Вспоминаем мой исходный тезис: время рендеринга статической HTML-страницы мажорируется некоторой (причём почти линейной) функцией от её размера. Иначе говоря, при анализе языка разметки время работы ограничено и предсказуемо, а вот при исполнении JS (и любого другого тьюринг-полного кода) оно непредсказуемо, и — совершенно верно — нам в целом пофигу, зациклилось оно или просто собралось выполняться миллиард лет. Да чёрт бы с ним с миллиардом, если оно собралось выполняться пару минут, любой нормальный человек пристрелит браузер раньше.

Более того - он элементарно опровергается на практике.

Да неужели? Вот прямо «на практике»? Ну-ка, ну-ка, следующая фраза.... эээ...

Интерпретатор комбинаторного исчисления

Гыгыгыгыгы, практика. Офигенная такая практика. Ты ещё Rule 110 предложи (читать тут, если что: https://en.wikipedia.org/wiki/Rule_110), оно ещё проще реализуется и таки да — тьюринг-полное.

Так вот, эти модельки, на которых практическое программирование заведомо невозможно, не имеют никакого отношения к практике. Это вообще не программирование, это чистая математика, называется теория алгоритмов. Математику я тоже люблю, но практика-то тут при чём?

Ну хорошо, скорректируем мой тезис: «задача написания НЕдырявого тьюринг-полного интерпретатора, пригодного для практического написания программ, превосходит человеческие возможности». Если что, brainfuck недырявый, наверное, тоже не так сложно сделать, но практически применимых программ на нём никто пока что не писал.

Парсер хмля (даже невалидирующий) сложнее на порядки.

Совершенно верно, если в качестве его «сложности» рассматривать, например, объём его кода. Если рассматривать его вместе с рендерером, то по объёму кода они вместе могут оказаться даже «сложнее» интерпретатора JS (не сравнивал, не знаю). А вот сделать при написании кода такую ошибку, которая приведёт к уязвимости (и не потенциальной, а практически эксплойтабельной, то есть такой, для которой тут же пишут рабочий эксплойт), судя по накопленному опыту, оказывается всё равно гораздо проще в интерпретаторе — просто, видимо, в силу его природы.

Croco ★★★
() автор топика
Ответ на: комментарий от anonymous

Вообще-то не всегда

Я не встречал курса математического анализа, в котором виды бесконечностей не излагались бы в самом начале. Поскольку сам я не математик (хотя и кфмн), я вряд ли смогу объяснить, почему это так.

для того чтобы заниматься матаном это не нужно, от слова совсем

Ага, ну успехов тогда в объяснении, что такое функция Дирихле.

матан сам по себе, идеологически, занимается счетными объектами

Что-то мне подсказывает, что те, кто занимаются матаном, от этого утверждения несколько удивятся. Надо будет у кого-нибудь из них спросить :-)

теория непрерывных ф-й на сепарабельном

Это уже не матан. Я, конечно, понимаю, что функциональный анализ можно рассматривать как завершающую часть матана, а не как самостоятельный предмет, но предмет всё же другой. Если же мы влезли в область функана, то там рядом где-то ещё пробегает парадокс Банаха-Тарского, который на счётных множествах вроде бы не проявляется (вот тут могу ошибаться — мой предел уверенной компетентности здесь, увы, находится чуть ниже).

Croco ★★★
() автор топика
Ответ на: комментарий от Croco

Как я уже говорил, практика показывает прямо противоположное.

Практика показывает корреляцию уязвимости со сложностью. А интерпретаторы - это далеко не самый сложный класс приложений, даже интерпретаторы «навороченные», как интерпретатор жс. Если сравнить сложность интерпретатора жс со сложностью парсера хтмл - конечно, интерпретатор сложнее. Если сравнить его со сложностью всей подсистемы рендеринга браузера - уже весьма сомнительно, кто выиграет (хотя я за рендеринг).

Совершенно верно, и что? Вспоминаем мой исходный тезис: время рендеринга статической HTML-страницы мажорируется некоторой (причём почти линейной) функцией от её размера.

Я думаю, следует остановится на том, что данный аргумент бессмысленен просто в силу того, что в современных браузерах жс не виснет и «сильно долго» не работает - любой долго работающий скрипт браузер предлагает остановить. И даже если не так - систему он все равно не повесит и даже не сможет сколько-нибудь существенно снизить ее отзывчивость.

Так вот, эти модельки, на которых практическое программирование заведомо невозможно, не имеют никакого отношения к практике. Это вообще не программирование, это чистая математика, называется теория алгоритмов. Математику я тоже люблю, но практика-то тут при чём?

При том, что это показывает ложность исходного утверждения. _возможно_ системы с тьюринг-полным интерпретатором действительно более уязвимы, но дело явно не в тьюринг-полноте самой по себе, потому как по факту тьюринг-полнота не является ни необходимым, ни достаточным условием роста уязвимости. Есть какой-то другой фактор. По-этому неправильно заявлять «тут тьюринг-полный интерпретатор, по-этому уязвимо», это просто неправда, потому что можно можно написать интерпретатор настолько простой, что в нем негде будет навешать уязвимостей, а можно сделать решето-систему безо всякой тьюринг-полноты. Следует выделить указанный фактор и уже о нем говорить. А рассуждения о тьюринг-полноте опустить.

А вот сделать при написании кода такую ошибку, которая приведёт к уязвимости (и не потенциальной, а практически эксплойтабельной, то есть такой, для которой тут же пишут рабочий эксплойт), судя по накопленному опыту, оказывается всё равно гораздо проще в интерпретаторе — просто, видимо, в силу его природы.

Так говорит интуиция, однако, интуиция имеет свойство ошибаться. Все эти рассуждения могут быть как правильными, так и полностью неверными, каких-то исследований на счет соответствующей статистики мы, вроде, не имеем, а личная выборка - заведомо слишком мала, чтобы по ней можно было судить о тенденциях в общем.

anonymous
()
Ответ на: комментарий от Croco

Я не встречал курса математического анализа, в котором виды бесконечностей не излагались бы в самом начале. Поскольку сам я не математик (хотя и кфмн), я вряд ли смогу объяснить, почему это так.

Важно изложить основы теории вещественных чисел и тот факт, что вещественные числа замкнуты (а потому предел всегда найдется), а вот вопросы кардинальности - вообще говоря, побоку. Ну вот чтобы далеко не ходить, допустим, «курс дифференциального и интегрального исчисления» Фихтенгольца, там вопросы кардинальности не рассматриваются. Есть конечно курсы в которых объясняется про бесконечности все, но я б сказал, что это наверное как раз и есть исключение.

Это уже не матан.

Ну это уже вопрос определений, что именно относить к матану. Если говорить о ф-и Дирихле и тому подобных вещах, то они имеют смысл в контексте теории меры, а под матаном все-таки обычно подразумевается «классический анализ».

anonymous
()
Ответ на: комментарий от Croco

Если же мы влезли в область функана, то там рядом где-то ещё пробегает парадокс Банаха-Тарского, который на счётных множествах вроде бы не проявляется

Это в области теории меры и наличия аксиомы выбора (без нее не построишь неизмеримого множества), а не функана. Парадокс банаха-тарского для счетных множеств просто затруднительно сформулировать. По крайней мере навскидку мне в голову не приходит, как это сделать.

anonymous
()
Ответ на: комментарий от bread

вот только в вебе похоже решили скучные книги искоренить. Теперь даже сугубо техническая инфа все чаще подается в немыслимом оформлении для девочек.

вот! именно оно самое. и самое главное, что этот дезигн для девочек кничтожает инфу. то есть, в ущерб информативности и техническим подробностям сайты ударяются в дизайнерский маразм, не учитывая, что, собственно, потребители их контента - не девочки с ойфончеками, а суровые мужики с десктопами.

Iron_Bug ★★★★★
()

Полагаю, Croco будет недоволен тем, что werc (тот, что по ссылке werc.cat-v.org) требует rc shell. Мне кажется ему хочется использовать то, с чем он уже имеет опыт работы.

anonymous
()
Ответ на: комментарий от Croco

Кроме того, есть ещё тезис (если угодно, назовите его тезисом Столярова, хотя я практически уверен, что это высказывали до меня, и не раз): задача написания НЕдырявого тьюринг-полного интерпретатора превосходит человеческие возможности. Иначе говоря, в любом интерпретаторе любого языка программирования всегда будут оставаться уязвимости (по меньшей мере arbitrary code execution), сколько бы их оттуда ни повылавливали. Тезис, очевидно, недоказуем (то есть формально его можно отнести к разряду голословных утверждений), но весьма убедительно подтверждается практикой: пока что нахождение дыры в любом интерпретаторе оказывалось вопросом времени.

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

проблема не в теории, проблема всегда на практике. реализации чаще всего кривые. и чаще всего этому способствует маркетинг. разработчиков торопят выдать готовый результат. на качество всем пофигу. и пока так будет - будут баги и глюки и уязвимости. Торвальдс правильно призывал не надеяться на чудеса и писать код. нудный, полный деталей. веб хочет чудес. но чудес не бывает.

Iron_Bug ★★★★★
()
Ответ на: комментарий от slapin

я вижу, что многие недовольны браузерами. но никто не хочет их писать. понятное дело, что дописывать что-то к уже существующей кривой реализации бесполезно. надо писать с нуля. например, начать пилить лор-браузер :)

Iron_Bug ★★★★★
()
Ответ на: комментарий от anonymous

ну, rc примитивен и может быть собран в один статический бинарник. так что сайт можно деплоить народным методом $scp откуда куда. Что несомненно плюс.

ugoday ★★★★★
()

rc конечно же хорош (как shell), но как я понял, Croco желает писать на том, что он знает и для него удобно. Нечего о том, что он готов писать на rc в его сообщениях нет.

anonymous
()
Ответ на: комментарий от bookman900

ну, для меня нет сомнений что всё, что должно работать быстро и не жрать ресурсы - это С. в крайнем случае - плюсы. но это моё мнение. щаз набегут неосиляторы и скажут, что они не могут в С, потому что он «небезопасен» и всё такое :)

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

например, начать пилить лор-браузер :)

Ох, лол.

Разработчики переругаются сначала на почве выбора языка. Затем оставшиется перерубятся из-за стилей кода. Немногие оставшиеся после этих побоищ полягут на этапе обсуждения используемых библиотек.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Раз уж мы затронули эту тему, предлагаю в очередной раз пофантазировать. Я понимаю, что браузер, написанный силами пользователей linux.org.ru - шутка. Но с другой стороны, раз мы говорим о даже теоретически невозможном браузере, то почему бы не помечтать. А что если дать каждому свободу выбирать язык программирования и закрепить за этим человеком определенный компонент браузера, который он будет самолично писать? И вместе с данной силой выбирать язык наложим ответственность - компонент не должен потреблять более n-ного количества ресурсов процессора, памяти и т.д. Если не получается написать компонент браузера так, чтобы уложиться в нормативы - пусть разработчик или оптимизирует свой код или меняет язык. Будем считать что написание этого браузера своего рода игра, важен не результат, а процесс. Как вы считаете, какой язык программирования будет использоваться чаще всего? Вопрос ко всем, кто желает ответить.

anonymous
()
Ответ на: комментарий от anonymous

Дык, все понятно: будут писать или на сях, или на крестах. Потому как больше ни один ЯП на серьезные задачи не годится! (я не беру в расчет морально устаревшие фортраны-ады и т.п.)

anonymous
()
Ответ на: комментарий от anonymous

прежде чем что-то писать, надо понять, чем конкретно не устраивает существующая реализация. причём как со стороны юзера, так и внутрение проблемы софта, которые мешают программистам сделать так, чтобы было нормально.

первое как юзер я могу обозреть: браузер жрёт дохрена ресурсов. и чем больше их на машине - тем больше он сожрёт.

о внутренних проблемах я знаю только понаслышке. пристала с расспросами к разработчику браузера, чтобы он мне сказал, куда там сейчас всё упирается. и он примерно мне пояснил, что упирается всё как раз в обработку всяких скриптов. и в безопасность - то есть, разграничение доступа этих скриптов: скрипт из одной страницы не должен получить доступа к данным скрипта другой страницы. и из-за этого там весь сыр-бор. плюс ещё мультимедия. совмещение видео со звуком, расположение самого видео на экране - это довольно существенные задачи.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Это ж где ты таких мудозвонов видела, которые С «небезопасным» называют? Это же вообще бред!

Или таки есть в мире такие дегенераты?

anonymous
()
Ответ на: комментарий от anonymous

ну, есть любители стрелять себе в ногу :) а обвиняют во всём С.

любой профессиональный инструмент требует навыков работы с ним. иначе можно остаться без ног. безопасны только игрушки для детей младшего возраста.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Эти дети младшего возраста, привыкнув к своим ардуинам, и повзрослев остаются такими же тупыми!!!

Мне пхытонисты абдуринщиков напоминают: абсолютно так же себя ведут, клепая копипастой код, значения которого абсолютно не понимают, но «гугол же подсказал!».

anonymous
()
Ответ на: комментарий от anonymous

А как же Rust, Go, Lisp, Java, различные «буквенные» языки программирования? На мой взгляд достойных претендентов много, а пользователи linux.org.ru очень разнообразные. К тому же кому-нибудь может взбрести в голову добавить к javascript еще один скриптовый язык программирования для управления содержимым страницы - например python или lua. Все не так просто, как мне кажется.

anonymous
()
Ответ на: комментарий от anonymous

добавить к javascript еще один скриптовый язык программирования для управления содержимым страницы - например python или lua.

lua - да, можно. но не добавить, а поставить вместо. lua - мелкий и лёгкий. а пистон не нужен: жручее тормозное однопоточное УГ. не надо эту обучалку для школоты тащить в девелопмент, и особенно в рантайм. она для этого не предназначена.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от anonymous

Эти дети младшего возраста, привыкнув к своим ардуинам, и повзрослев остаются такими же тупыми!!!

ну, не все же. сначала игрушки простые. потом простые игрушки надоедают и появляется понимание, что мир сложнее и игрушечным совочком в нём уже ничего не накопаешь.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

пристала с расспросами к разработчику браузера, чтобы он мне сказал, куда там сейчас всё упирается. и он примерно мне пояснил, что упирается всё как раз в обработку всяких скриптов. и в безопасность - то есть, разграничение доступа этих скриптов: скрипт из одной страницы не должен получить доступа к данным скрипта другой страницы. и из-за этого там весь сыр-бор.

Оспадетыбожемой, какой бред.

совмещение видео со звуком, расположение самого видео на экране - это довольно существенные задачи.

Ну ещё композитинг можно назвать существенной задачей. Но вот совмещение видео со звуком — давно решённая задача. Скорости компов достаточно большие, так что выводи звук, считай по нему время, да выводи кадры. Можно всё в одном потоке считать. Плееры так делают, и им норм.

i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

А что если дать каждому свободу выбирать язык программирования и закрепить за этим человеком определенный компонент браузера, который он будет самолично писать?

Компонент — не обособленный элемент типа процесса. Скорее всего он оформлен как внутренняя библиотека, поэтому в случае зоопарка языков будет использован из каждого. Мало того, что с взаимодействием языков всегда проблема, так ещё и умение делать внятный интерфейс библиотеки, от которого не хочется лезть на стенку — сродни таланту. Человек, который умеет писать отличные программы, не всегда умеет писать библиотеки.

компонент не должен потреблять более n-ного количества ресурсов процессора, памяти и т.д.

Не работает для библиотек. Не работает для программ с произвольным вводом. Браузер должен хоть как-то открывать документы любого размера и сложности, поэтому нельзя сделать ограничение сверху.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Оспадетыбожемой, какой бред.

это не бред. это реальные проблемы внутри браузеров, с точки зрения их разработчиков. над этим они ломают головы. и на это, собственно, тратятся ресурсы, пожираемые браузерами.

что касается вывода - всё было бы просто, если бы была одна целевая система с одним набором библиотек. а то ведь их дофига :)

Iron_Bug ★★★★★
()
Ответ на: комментарий от i-rinat

Человек, который умеет писать отличные программы, не всегда умеет писать библиотеки.

любая программа больше, чем примитивное юзерское приложение верхнего уровня, всегда состоит из многих библиотек. так что любой программист, который имел дело с серьёзными проектами, просто обязан уметь писать библиотеки и делить софт на модули. это не какая-то сверхзадача, это минимальное требование. заодно библиотеки упрощают разработку, тестирование и отладку.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Не работает для библиотек. Не работает для программ с произвольным вводом. Браузер должен хоть как-то открывать документы любого размера и сложности, поэтому нельзя сделать ограничение сверху.

Это не принципиальный момент. Я имел в виду эффективность работы приложений как таковую,а ее оценить все равно можно если не одним способом, так другим (признаю, мои слова в предыдущем сообщении можно интерпретировать как угодно).

anonymous
()
Ответ на: комментарий от Croco

Ну а неприятность, которая может произойти, обязательно произойдёт — это понятно или тоже надо объяснять? :-)

Вы таки против атомных электростанций?

anonymous
()
Ответ на: комментарий от Iron_Bug

это не бред

В такой формулировке — бред. Функция работает с двумя состояниями. Есть требование — не проливать одно состояние в другое. Как на это вообще можно тратить ресурсы? Отдельный поток, который ограждает потоки данных?

что касается вывода - всё было бы просто

Я уже сказал, что композитинг — значительная задача. Или это как-то относится к синхронизации аудио и видео?

i-rinat ★★★★★
()
Ответ на: комментарий от Iron_Bug

так что любой программист, который имел дело с серьёзными проектами, просто обязан уметь писать библиотеки и делить софт на модули.

Нет, вообще-то, не обязательно. В крупном проекте библиотеки уже написаны.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

если не понимать, как там всё устроено, то можно любое объяснение обозвать бредом.

ресурсы тратятся на множество потоков. каждый поток (ну или нить, как сейчас модно) - интерпретатор скрипта. плюс разделение совместной работы с ресурсами вроде аудио-видео и т.д. сейчас, по сути, на каждую страницу браузер либо должен породить отдельный поток, либо реализовать машину конечных состояний и пытаться обрабатывать разные процессы в одном потоке (это сложная реализация). и у каждой страницы может быть аудио, видео и хрен знает что. плюс на одной странице может быть много скриптов (и каждый должен иметь гарантию не сломать данные соседних ресурсов).

суть в том, что основной гемор происходит именно от скриптов. и поэтому отключение скриптов сразу уменьшает аппетит браузера на ресурсы.

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Нет, вообще-то, не обязательно. В крупном проекте библиотеки уже написаны.

повезло, если так. но далеко не всем крупным проектам так везёт :) плюс добавим всякие там лицензии. если заказчик хочет коммерческий проект - объём доступного опенсорцного кода сразу резко уменьшается.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

каждый поток (ну или нить, как сейчас модно) - интерпретатор скрипта

Это где сейчас ещё есть разница между нитями и потоками? Solaris?

А во-вторых, ты какой-то ненастоящий сварщик. По потоку на каждую вкладку? Чего? Поток Javascript — один на процесс, если не считать webworker'ов.

О каком браузере речь-то шла? Откуда разработчик?

это сложная реализация

Ну живут как-то и с такой реализацией.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Это где сейчас ещё есть разница между нитями и потоками? Solaris?

ну, реализации в разных осях - это отдельная песня. но я говорю про виртуализацию и «псевдопотоки», реализованные через конечные автоматы. так реализованы «лёгкие потоки» в разных виртуальных машинах а-ля жаба, эрланг. смысл в том, чтобы физических потоков операционки было меньше. ну не создавать же стопицот системных потоков на одно приложение.

по сути, браузер - это такое подобие мини-виртуальной машины, которая до кучи ещё ориентирована на мультимедию. всё прочее - парсинг, конечные автоматы и всё вот это вот там в полном объёме. только жрать он должен не как сервер, а как юзерское приложение.

О каком браузере речь-то шла? Откуда разработчик?

это был разработчик Яндекс браузера. общались на встрече разработчиков С++. мне просто стало интересно, отчего у браузеров такие аппетиты на ресурсы. и вот я в перерыве пошла это выяснять.

Ну живут как-то и с такой реализацией.

жить-то живут. но ресурсы тратятся неоптимально. я сама почти такой софт писала, только для автоматизации. примерно представляю масштабы и сложность задачи. только у нас мультимедии не было. а тут ещё это вот. плюс скрипты могут быть глючные и т.д., а разметка может содержать ошибки. и браузер всё это толерантно пытается обойти.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

и чем больше их на машине - тем больше он сожрёт.

И это правильно поведение. Я не затем себе покупал 16гб оперативки, чтобы браузер, вместо того чтобы кешировать данные лишний раз винт дергал.

anonymous
()
Ответ на: комментарий от i-rinat

По потоку на каждую вкладку? Чего?

Видимо, имелся ввиду процесс на вкладку (хром так делает). И в каждой свой собственный жс.

anonymous
()
Ответ на: комментарий от i-rinat

Это где сейчас ещё есть разница между нитями и потоками?

А то в линуксе разницы нет! Поток использует общее с родительским процессом и другими потоками адресное пространство. Процесс — полная копия, но в дальнейшем ничего общего!

По потоку на каждую вкладку?

Правильней про процессу на каждую вкладку.

anonymous
()
Ответ на: комментарий от Iron_Bug

парсинг, конечные автоматы и всё вот это вот там в полном объёме

Это всё круто и впечатляюще, особенно если не быть в курсе, что такое парсинг и конечные автоматы. Но речь вообще была не об автоматах, а о том, что ресурсы на защиту скриптов друг от друга тратятся. Это как? Вот этот момент я так и не понял: как эта защита ест ресурсы.

я сама почти такой софт писала, только для автоматизации

Ты лучше скажи, в каком софте такого не бывает. Всё взаимодействие с пользователем, реакция на внешнюю среду — это события и код, выполняемый по этим событиям. Такого нет разве что в счётных программах, которые читают входные данные из файла, считают с максимальной загрузкой CPU, а потом пишут результат в файл.

i-rinat ★★★★★
()
Ответ на: комментарий от Iron_Bug

разграничение доступа - стандартная задача в операционых системах

Это совсем другая задача. Я практически уверен, что если бы в ядре внутри был интерпретатор скриптов, которые можно было бы туда загрузить через системные вызовы (ну, э... скажем, чтобы задать «продвинутые» стратегии планирования времени ЦП и дисковых обменов), то именно этот интерпретатор был бы основной мишенью для эксплойтов и основным источником уязвимостей.

разнообразных приложениях

Ровно до тех пор, пока приложение работает так, как предполагал его автор, всё остаётся в рамках приличий. Эксплойт — это когда программу заставляют делать такое, что о самой возможности подобного её автор даже не подозревал.

В общем, разграничение доступа никакого отношения к моему тезису не имеет.

Croco ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.