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

Практика показывает корреляцию уязвимости со сложностью. А интерпретаторы - это далеко не самый сложный класс приложений,

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

дело явно не в тьюринг-полноте самой по себе

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

Так говорит интуиция

Так, ещё раз подчёркиваю, показывает практика. Поищите отчёты об эксплойтабельных уязвимостях в браузерах и найдите хоть одну, для которой эксплойт не использовал бы JS или Java (или в крайнем случае flash :), хотя я таких не помню) на стороне ломаемого клиента. Я в своё время не нашёл.

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

Столько комментариев, и никто не написал про werc.cat-v.org :-(

Выглядит интересно. JS там есть, но, судя по всему, используется только для всякой фигни типа google-analytics и баннериков, так что, видимо, либо штатно отстригается, либо нештатно, но безболезненно.

Смущает вот что:

# All you need is some Plan 9 commands (cat, grep, sed, rc, etc.), and an HTTP server with CGI support.

# If you use Debian you can install the 9base package that will provide all the required commands

Активная (вроде бы) ссылка на «Plan 9 from User Space» ведёт на какую-то попсу, не имеющую отношения к делу. Больше никаких упоминаний о том, как это деплоить, если я НЕ на дебиане; но, судя по всему, одного только rc shell не хватит. Где брать исходники всего это дела, непонятно.

Кто-нибудь пробовал это всё разворачивать?

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

как эта защита ест ресурсы.

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

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

если бы в ядре внутри был интерпретатор скриптов

дык, давно уж: http://www.phoronix.com/scan.php?page=news_item&px=MTQ4ODk

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

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

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

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

куча проверок

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

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

плюс на отдельные скрипты запускаются разные потоки(если системные - то ещё хуже).

Javascript — принципиально однопоточный. Так что даже несмотря на то, что формулировки специально размытые, видно, что ты пыль в глаза пускаешь. Непонятно только, зачем.

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

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

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

Не хочу додумывать, хочу конкретики.

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

Javascript — принципиально однопоточный.

внезапно жабаскриптов одновременно выполняется овеодох-я. и потоков много.

Сто страниц, на которых пользователь нажал на кнопочки чуть-чуть по-разному.

и что? это данные. код парсить не надо. это как раз типичный конечный автомат.

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

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

отловить все нарушения памяти, которые там внезапно могут оказаться

Что за бред? Какие нарушения памяти? В браузер приходит HTML текстом, CSS текстом, Javascript текстом. Там что, есть доступ к памяти напрямую?

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

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

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

внезапно жабаскриптов одновременно выполняется овеодох-я. и потоков много.

Пример в студию.

и что? это данные. код парсить не надо. это как раз типичный конечный автомат.

Представим ситуацию. Ты открываешь в браузере одну и ту же страницу 100 раз в разных вкладках. Приведи доказательство того, что веб сервер 100 раз отдаст идентичный ответ. (Hint: ты не сможешь :) )

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

а как ты магическим образом «запускаешь» жабаскрипт?

В интерпретаторе.

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

Приведи пример невалидного обращения к памяти в Javascript. И такой же пример для обращения к ресурсам, пожалуйста.

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

Пример в студию.

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

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

Приведи пример невалидного обращения к памяти в Javascript. И такой же пример для обращения к ресурсам, пожалуйста.

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

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

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

Неее, давай не отлынивай. Приведи мне пример многопоточного Javascript. И давай пример, как два скрипта на странице одновременно работают. (Не web workers. Они — в отдельной реальности живут, с доступом сообщениями.)

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

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

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

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

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

OK. И как Яндекс.браузер от этого защищает, какие проверки?

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

я хз. спроси это у тех, кто его пишет. ты до меня-то чего дое-ся?

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

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

да не пишу я на твоём жабаскрипте

но два скрипта могут работать только параллельно

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

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

ты до меня-то чего дое-ся?

Было заявление о том, что ресурсы тратятся на проверки скриптов и защиту. Я спросил, как именно тратятся ресурсы на защиту. Спросил, потому что это идёт вразрез с моей картиной мира. А в ответ я читаю сказки. Причём чем дальше, тем замысловатее сказки. И никакой конкретики.

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

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

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

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

но то ли ты читать не умеешь, то ли никогда не писал парсеры

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

хочешь конкретики - возьми сорцы браузера и посмотри

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

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

Javascript — принципиально однопоточный.

С точки зрения javascript-разработчика. Под капотом все может работать иначе.Если вы сейчас поищите исходные коды spidermonkey (js интерпретатор Firefox), то заметите что потоки то в коде используются активно. Причем в некоторых случаях их количество зависит от «однопоточного» js-кода.

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

Столько комментариев, и никто не написал

Тут в основном занимались тем, что объясняли автору, что он желает неправильного и вообще немоден. :-)

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

Я практически уверен, что если бы в ядре внутри был интерпретатор скриптов

Все гораздо печальнее - такой интерпретатор есть в прошивке процессора :)

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

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

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

Да, дело в том, что «по ту сторону» находится интерпретатор языка программирования, причём такого, на котором можно писать.

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

Поищите отчёты об эксплойтабельных уязвимостях в браузерах и найдите хоть одну, для которой эксплойт не использовал бы JS или Java (или в крайнем случае flash :), хотя я таких не помню) на стороне ломаемого клиента. Я в своё время не нашёл.

А можно примеры, которые используют?

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

более того, если одну страницу открыть сто раз, то ресурсов будет в сто раз больше.

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

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

и что? это данные. код парсить не надо. это как раз типичный конечный автомат.

Я тебе больше того скажу - в некоторых случаях браузер парсит весь код заново при каждом событии отрисовки dom. И проблема не в браузерах, проблема просто в том что когда продумывали инфраструктуру уеба никто не предполагал во что оно выльется. Как следствие - множество архитектурных ошибок.

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

а как ты магическим образом «запускаешь» жабаскрипт? внезапно, его нужно парсить и проверять все обращения к памяти и ресурсам на валидность.

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

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

ты сначала парсер напиши!!!11 онажпрограммист и знает лучше.

anonymous
()

С первого по пятый пункт — лучше всего статический генератор страниц;

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

Если я правильно понял, то при добавлении комменатрия, должна пересоздаваться страница/страницы с комментариями?

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

Вкладка лора жрет в хромом 25мб,

Увы, не все сайты такие хорошие.

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

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

Переполнение буфера требует от взломщика намного лучшей подготовки, большего количества времена и больших усилий. В сложно устроенных системах, которые используют различные способы защиты от переполнения буфера, даже обнаружение такой уязвимости делает ее использование для чего-то кроме порчи данных скорее «гипотетическим». В таких случаях написание кода, который реализует эту уязвимость, можно охарактеризовать как «rocket science» в мире IT. Но предлагаю уйти от всякого рода теорий и поговорить о практике. Просто ответьте - лично вам легче получить доступ к данным сайта через sql-инъекцию или переполнение буфера? Или, скажем, что легче - украсть cookies через уязвимость в js или посредством того же переполнения буфера?

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

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

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

Просто ответьте - лично вам легче получить доступ к данным сайта через sql-инъекцию или переполнение буфера?

Безусловно, второе. Потому что переполнения буфера в 2017 году существуют, а вот sql-инъекции - уже нет.

Или, скажем, что легче - украсть cookies через уязвимость в js или посредством того же переполнения буфера?

При помощи переполнения буфера у тебя полный доступ к системе. Делай что хочешь.

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

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

Совершенно верно... в теории. А на практике у вас силенок хватит для использования такой уязвимости?

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

При помощи переполнения буфера у тебя полный доступ к системе. Делай что хочешь.

Про размер полезной нагрузки, стек-протектор и ASLR знаешь? И доступ не к системе, а к пользователю/контейнеру под которым работает сервис.

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

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

Вы, похоже, не понимаете, о чём идёт речь. «Переполнение буфера» — это ещё не дыра. Дыра — это когда можно написать эксплойт, использующий данное конкретное переполнение (или другую багу в программе, переполнение тут только пример), чтобы что-то сделать; в большинстве случаев интересно получить arbitrary code execution, то есть через это вот переполнение «на ту сторону» засунуть машинный код и его там выполнить. Сделать это возможно не всегда, причём бывает и так, что оно вроде бы возможно, но не находится достаточно квалифицированного хакера, чтобы соответствующий эксплойт сделать. Трудно это. И этому нигде не учат.

Возможности, которые даёт интерпретатор, как раз вот это вот — создание эксплойта — резко облегчают. Иначе говоря, одно и то же переполнение буфера может быть non-exploitable, когда никакого интерпретатора на той стороне нет, и вполне себе exploitable, когда он есть.

Изоляция жса вообще происходит по факту на уровне ОС.

ОС ничего не знает про JS. Вообще ничего. И у неё нет таких средств изоляции. Интерпретатор выполняется в обычном процессе, каковой имеет полномочия запустившего его юзера. Поймали его на чём-то — всё, аккаунт юзера наш. Вот до рута расширить на нормальной системе не получится (только где они, эти нормальные системы).

А можно примеры, которые используют?

Сходу вот раз: https://nakedsecurity.sophos.com/2012/06/19/ie-remote-code-execution-vulnerab...

вот два: https://bugzilla.redhat.com/show_bug.cgi?id=639920

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

Если я правильно понял, то при добавлении комменатрия, должна пересоздаваться страница/страницы с комментариями?

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

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

Про размер полезной нагрузки, стек-протектор и ASLR знаешь? И доступ не к системе, а к пользователю/контейнеру под которым работает сервис.

Поскольку обсуждается клиентская машина, в большинстве случаев доступ таки ко всей системе. Увы. Винда постепенно отмирает, но пользовательский идиотизм непобедим: привет sudo без пароля (а даже если и с паролем, вопрос лишь в трудоёмкости атаки).

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

В таких случаях написание кода, который реализует эту уязвимость, можно охарактеризовать как «rocket science» в мире IT.

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

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

Только этого может оказаться достаточно.

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

у меня на старом ноуте было 2 гига памяти. и кроме браузера мне нужно было программировать и много чего ещё. а лет 15 назад у меня на компе было 256 метров памяти и браузер работал нормально! так что Дийкстра бы собственными руками задушил этих макак и пейсателей браузеров.

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

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

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

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

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

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

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

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

Внезапно, ЛОРчую. Говнодизайн веб-макак даже в технические доки, сука, пробрался.

Когда уже наконец веб-пузырь лопнет и все они уйдут уже наконец кричать «свободная касса»?

---

Кто отличился? Конечно же, модные и молодёжные культи:

http://doc.qt.io/qt-5/qpainter.html

Нахера тут заголовки в 3/4 экрана? Нахера нечитаемый фигурный шрифт аля Comic Sans MS? Нахера убогие блоки кода?

А вот как было:

http://doc.qt.io/archives/qt-4.7/qpainter.html

Заметьте, здесь в блоках кода методы кликабельные. Тыкаешь на них и получаешь нужную инфу. А в новых доках уже такого нет. Деграданты сраные. Новые доки как-будто сделаны для iPad'а и смуззипоедателей.

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

дык, давно уж: http://www.phoronix.com/scan.php?page=news_item&px=MTQ4ODk

Маааааамаааааааа.....

Фух, хорошо что я не пользую NetBSD. Кстати, там же сразу же

# many would be appalled by the idea of having a scripting language interpreter within kernel-space from a security and performance perspective

Таки да, я вхожу в это many.

рут должен быть не жопоруким ламером, а нормально соображать.

Как видно по этому треду, нормально соображающих на всех не хватит. Впрочем, оно не поможет. Будь рут хоть семидесяти семи пядей во лбу, если он сам не хакер — то хакеры всегда будут на шаг впереди. А хакеров в роли рутов не хватит не только на «всех», их вообще ни на кого не хватит.

задача программиста - предусмотреть всё.

Вы в это верите? Я — нет. Я вот даже понимаю, как эксплойты делаются (большинство программистов этого не понимает), но вариант «предусмотреть всё» отбрасываю как заведомую утопию. А те, кто сами пишут эксплойты и — да — умеют предусматривать если не всё, то почти всё, внезапно, в большинстве своём не умеют программировать. Не в том смысле, конечно, что они языков программирования не знают — это они знают лучше всех как раз; но вот сидеть и кодить полгода, не разгибаясь, какую-нибудь прикладнуху — реально не могут. Им это, впрочем, и не надо.

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

А вот как было:
http://doc.qt.io/archives/qt-4.7/qpainter.html

Выглядит просто убого. Половина код-листингов с помощью .js не прячется. Картинки баландаются кое-как. В итоге — простыня какаков. И просто невозможно читать контент.

Неужели не понятно, что чем няшнее выглядит сайт — тем лучше его читать?

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

Какая разница, если результат - пачка html файликов?

Разница очень простая: я не стану собирать питон под Openwall Linux. Мне в своё время Эрланга хватило.

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

Неужели не понятно, что чем няшнее выглядит сайт — тем лучше его читать?

Сайт не должен вообще никак «выглядеть». За слово «дизайн» в применении к сайтам нужно убивать сразу же.

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

За слово «дизайн» в применении к сайтам нужно убивать сразу же.

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

Вас же могут быстро тормознуть 90% пользователей Интернета, которые генерируют трафик.

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