Ваша мысль такова: ставь ПО только из репозитория и своевременно обновляйся только через репозиторий. Про то, что в этом ПО, библиотеках или ядре ОС могут быть уязвимости, не известные никому, кроме узкого круга злоумышленников, просто не думай. Если на компьютер проник вирус, то виноват только ты сам, у тебя кривые руки и вообще ты не разбираешься в линуксовой части. Я вас понял.
> Весь софт обновляется централизованно и регулярно
Это очень спорное утверждение. Во-первых, в большинстве популярных unix-linux-дистрибутивах официальные репозитории обновляются очень медленно. Обновить mysql, php и т.д. до новейшей версии через официальный репозиторий практически невозможно. Поэтому те, кто поумнее, ставят критичное ПО из исходников руками, остальные — подключают сторонние репозитории и берут на себя огромные риски безопасности. Я понимаю, что в случае нахождения критических багов, пакет в официальном репозитории тоже может быть экстренно обновлен, но все же обычно новые версии там появляются с большой задержкой.
Во-вторых, даже если вы используете последнюю версию ПО, это совсем не значит, что в нем нет ошибок. Представьте, что завтра будет опубликована новая уязвимость ядра linux. Да, все сразу побегут обновляться и как-бы проблема будет решена. Но настоящая проблема в том, что есть люди, которые об этим завтрашних уязвимостях знают уже сегодня и эксплуатируют их. Нахождение уязвимостей ПО — это целая теневая индустрия, где крутятся огромные деньги.
> Всё это делает производство массовых вирусов под линукс делом бесполезным
Все относительно. Да, о такой массовости, как в случае с windows, речи не идет. Но это не значит, что меньшая целевая аудитория не может быть интересна вирусописателям.
Надо понимать, что уязвимости могут быть всегда и, исходя из этого, желательно постараться на корню решить проблему. Классический антивирус не всегда может быть полезен, т.к. сам оперирует сигнатурами вирусов, которые обновляются с задержками. Но антивирус как сервис, где, к примеру, есть активный сетевой экран, который может предупредить пользователя о подозрительной сетевой активности, или же гипервизор, анализирующий подозрительную активность программ в памяти и на диске — это однозначно хорошие вещи.
Только поймите меня правильно, я не агитирую за антивирусы и не напускаю страшилок. Антивирус — это что-то вроде страховки. Покупать ее не обязательно (хотя в рекламе страховых услуг обычно утверждается обратное), но кто-то все же покупает страховки, для кого-то они нужны. Так же и с антивирусом. Лучше, чтобы Касперский все же выпустил полноценный KIS под linux, а уж покупать или нет — это каждый сам решит.
Есть миф, что антивирус нужен. Но есть еще один миф: что антивирус не нужен. Истина где-то посередине, решение нужно принимать в каждом конкретном случае. Я пользуюсь антивирусом на винде о и очень сожалению, что Касперский не выпускает полноценного аналога KIS для Линукса.
Меня всегда удивляет мнение, что на Линуксе или Маке вирусов нет. Надо понимать три вещи… Во-первых если вы не замечаете вируса, это не значит, что его нет. Во-вторых вирусы могут проникнуть даже на самую защищенную систему, эксплуатируя уязвимость, в т.ч. и нулевого дня. От уязвимостей ни одно серьезное ПО не застраховано. В-третьих, про систему прав доступа — не все вирусы стремятся закрепиться в вашей ОС навсегда. К примеру, на Хабре была статья про Java-вирус, который загружался на компьютер жертвы через дыру в JVM и оставался в памяти до перезагрузки системы. Никаких изменений в файловой системе он не делал, а поэтому с ограничениями прав доступа не сталкивался. Он просто висел в памяти с правами браузера и на фоне неторопливо рассылал спам, участвовал в ddos и т.д. И пусть этот вирус запущен с ограниченными правами моего браузера и не может навредить ядру ОС (ведь все права настроены правильно), мне все равно было бы неприятно иметь такого временного парозита на своем ПК.
Но и считать, что без антивируса пользоваться ПК или смартфоном нельзя — это тоже перегиб.
> Из статьи стало понятно, что конфигурация PHP по умолчанию опасна!
Я просчитал указанную вами статью и ничего такого про опасность стандартной конфигурации PHP не нашел. В статье описана история взлома, которая началась с эксплуатации известной уязвимости старой версии форума phpBB. Не было бы устаревшего phpBB, не было бы и истории. Настройки интерпретатора PHP здесь ни при чем.
>Но не могу я без боли смотреть на статьи про «производительность» PHP
Конечно, вы правы, что C++ на порядок круче PHP в плане производительности. С этим вообще никто не спорит. Но реальность такова, что на свете есть много людей, которые по разным причинам используют PHP, и для них вопрос повышения производительности может быть актуален. Зря вы так критикуете статью, в ней нет ничего плохого.
Я думаю, что у подобной ОС нет будущего на ПК, но на стороне сервера стабильная ReactOS была бы очень востребована. Легковесная, быстрая и бесплатная windows-совместимая ОС — это то, что нужно многим. Рекомендую разработчикам ОС делать упор именно на серверную часть. Запустите там веб-сервер и покажите, что он работает в разы быстрее IIS. И все вопросы сразу отпадут. Желаю удачи!
Спасибо за «Header set Content-Encoding: gzip». Я слышал что-то об этом, но думал, что апачевский модуль Header, который нужен для выполнения данной инструкции, не включен по умолчанию на большинстве хостингов. А сейчас проверил на нескольких — везде работает. Теперь буду пользоваться!
> По моему очевидное отрицать глупо. Или у Вас аргументы есть? :)
Я не отрицаю очевидное. Вы пишете, что сжатие имен css-классов мало кому нужно. Я с вами абсолютно согласен. Но кому-то это нужно и с этим ничего не поделаешь. Я не понимаю сути спора.
> отдаем сжатый файл и выставляем соотвественно content-encoding
Ладно, я вас понял. Я не хочу более спорить, т.к. этот спор заходит в тупик.
> И реализовать это можно даже если у Вас на виртуалке отключен ZIP.
Я хотел бы уточнить насчет предлагаемого вами метода предварительного gzip-сжатия. Как это можно сделать в рамках виртуального хостинга?
К примеру, мне нужно раздавать сжатый gzip-ом css-файл. Насколько я понимаю, я не могу просто так взять и сослаться на этот файл из html-кода. Чтобы браузер корректно налету распаковал этот архив, нужно послать ему (браузеру) http-заголовок «Content-Encoding: gzip». Это можно легко сделать через, к примеру, php-скрипт, который загрузит с диска сжатый файл, добавит на выход недостающий http-заголовок и далее пошлет файл клиенту. Но php-скрипт для раздачи статики — это уж совсем как-то не рационально.
Что мне нужно сделать, чтобы мой статический сжатый gzip-ом файл отдавался бы напрямую клиенту с нужным http-заголовком? Проблема актуальна именно для виртуального хостинга, где нет доступа к настройкам веб-сервера.
Согласитесь, что вы занимаетесь передергиванием. Конечно, сжатие css нужно не всем. Конечно глупо сжимать css и одновременно подгружать не оптимизированные изображения и т.п. Я согласен. Но ведь есть люди, кому это нужно, кто уже много чего оптимизировал, но все равно пытается выжать максимум там, где это еще возможно. А рассуждения о том, насколько значимы спасенные 1.5Кб — это чисто субъективный момент, у каждого на это свой взгляд.
И не стоит всех пользователей виртуального хостинга ровнять под одну гребенку. Если твой сайт на виртуальном хостинге, это не значит, что ты не думаешь о производительности и непременно подгружаешь «изображения или библиотечку метра на 1.5».
Подгружать скриптом заранее сжатый zip-ом статический файл я бы точно не стал. Уж лучше тогда оставить без zip-сжатия. Виртуальных же хостингов с нормальных zip-сжатием я, признаюсь, не встречал.
На виртуальном хостинге это позволит сэкономить время загрузки страницы. Может вы живете в какой-то другой Москве, но на моем Мегафоновском 3G сайты грузятся, как улитки. А по вечерам часто Интернета вообще нет. Т.е. он как бы есть, но его нет :)
Странно читать в комментариях столько скепсиса и критики данного подхода. На самом деле идея очень хорошая и, действительно, Гуглом активно используется. Но, как многие заметили, в программном коде порой названия классов формируются динамически и этот случай ваш плагин никак не распознает. Поэтому универсального плагина, сокращающего названия css-классов, сделать не получится.
Однако, совершенно реально создать некую спецификацию, подход к именованию классов. Например, можно договориться, что все имена классов, подвергающихся сжатию, должны быть записаны с определенным префиксом. В таком случае разработчик сам сможет выделить для себя группу классов, имена которых сжимать не нужно. В таком походе есть смысл. Конечно, эта лишняя спецификация несколько усложнит написание кода, но ведь в Гугле она используется и ничего, никто не умер.
Наличие zip-сжатия с данным методом не вступает в противоречие, т.к. zip сжимает еще много чего, для него работа все равно останется. А вот для владельцев сайтов на виртуальных хостингах, где zip-сжатия обычно нет, этот подход пригодился бы.
«Считать байты в наш век гигабитного интернета как-то глупо» — да, это верно. Но мобильный Интернет еще далек от века гигабитных технологий. А через мобильные устройства сегодня в Рунете делается каждый четвертый хит.
Вашу предыдущую статьи читал в свое время. Очень рад за вас, в правильно направлении идете. Но наделся, что в этой статье вы что-то этакое расскажете. Однако все равно молодцы.
Спасибо за данные по росту нагрузок. Я долго вдумывался в вашу последнюю фразу и, наконец, понял: если после ввода https рост нагрузки не заметен, то это значит, что ваш сервис настолько сильно тормозит, что нагрузка https — это капля в море.
Все эти оптимизации (keep-alive, уменьшение запросов на получение пользовательских данных) можно было сделать и для http, к https они не имеют никакого отношения. Поэтому по факту вы не сделали ничего такого, что бы снизило нагрузку на сервер именно для https-протокола. Жаль, что нет какого секретика, позволяющего ускорить обработку https.
Основываясь на вашем опыте использования огромного парка железа, ориентировочно на сколько процентов возрастает нагрузка на сервер при включении https? Речь идет о самом простом случае — сервер раздачи статического контента.
Да, вы правы, скорее претензии к компании, а не к санкциям в целом. Но проукраинское население страдает и это как-то не по товарищески со стороны Запада. Будь я украинцем до мозга костей, проживающем в Крыму, реально прифигел бы от этого всего. Санкции выдавливают украинское население из Крыма и это как-то странно…
Суть закона я понимаю. Конечно, санкции не ставят целью наказать физлиц, но в данном случае, хоть и без прямого умысла, но именно так получается. Если уходить совсем далеко, то можно представить, как американские банки будут закрывать счета жителей Крыма и их деньги выкидывать в помойку только лишь из-за невозможности больше эти счета обслуживать.
Жителям санкционных регионов нужно было дать время на перенос доменов к другим регистраторам по причине того, что godaddy более не может их обслуживать на законных основаниях. Это бы я понял — нормальные санкции. А то, что делает godaddy — это разводка какая-то.
Хоть я и не одобряю западные санкции против Крыма, но при желании я могу найти в них хоть какое-то разумное объяснение. Но вот как объяснить санкции против физических лиц, проживающих в Крыму — совершенно не понятно! Представьте, жил себе в Крыму с рождения самый настоящий патриот Украины. После оккупации (так он ее называет) он не стал покидать свою родину, но от этого своих взглядов не изменил. И тут батц… У него отбирают его кровные домены. В чем этот человек виноват? За что с ним так поступать? И в чем виноваты все остальные жители Крыма?
140 руб. — это была цена домена, если его заказать через панель управления Мастерхоста. Т.е. как-бы для клиентов хостинга, хотя в реальности хостинг не обязательно было покупать. И эти цены были очень давно. Поэтому это была никак не временная акция. Я тоже регистрировал домены там на протяжении многих лет, но теперь не буду.
Упоминание PHP прогрнозируемо вызывает ярость толпы разработчиков. Но если подумать, ничего плохого в предложении нет. Важно понять, что имеется ввиду под обучением программированию? Если речь идет о системном или низкоуровневом программировании, то да, не типизированные языки не подходят. А если вы хотите научиться построению алгоритмов, то PHP, Basic, Perl и т.д. — «то, что доктор прописал».
Помню свою школу и вступительный экзамен в универ по информатике — там только про алгоритмы и шла речь. Вопросов про управление памятью не было и в помине. Я писал на Pascal, но все эти программы с равной степенью успешности мог бы писать и на Бейсике, разницы не было бы никакой.
Когда же человек, получив начальные знания, продолжает интересоваться программированием, то если будет нужно, он уже сам и с низкоуровневым ассемблером, и с высокоуровневыми языками познакомится.
Это очень спорное утверждение. Во-первых, в большинстве популярных unix-linux-дистрибутивах официальные репозитории обновляются очень медленно. Обновить mysql, php и т.д. до новейшей версии через официальный репозиторий практически невозможно. Поэтому те, кто поумнее, ставят критичное ПО из исходников руками, остальные — подключают сторонние репозитории и берут на себя огромные риски безопасности. Я понимаю, что в случае нахождения критических багов, пакет в официальном репозитории тоже может быть экстренно обновлен, но все же обычно новые версии там появляются с большой задержкой.
Во-вторых, даже если вы используете последнюю версию ПО, это совсем не значит, что в нем нет ошибок. Представьте, что завтра будет опубликована новая уязвимость ядра linux. Да, все сразу побегут обновляться и как-бы проблема будет решена. Но настоящая проблема в том, что есть люди, которые об этим завтрашних уязвимостях знают уже сегодня и эксплуатируют их. Нахождение уязвимостей ПО — это целая теневая индустрия, где крутятся огромные деньги.
> Всё это делает производство массовых вирусов под линукс делом бесполезным
Все относительно. Да, о такой массовости, как в случае с windows, речи не идет. Но это не значит, что меньшая целевая аудитория не может быть интересна вирусописателям.
Надо понимать, что уязвимости могут быть всегда и, исходя из этого, желательно постараться на корню решить проблему. Классический антивирус не всегда может быть полезен, т.к. сам оперирует сигнатурами вирусов, которые обновляются с задержками. Но антивирус как сервис, где, к примеру, есть активный сетевой экран, который может предупредить пользователя о подозрительной сетевой активности, или же гипервизор, анализирующий подозрительную активность программ в памяти и на диске — это однозначно хорошие вещи.
Только поймите меня правильно, я не агитирую за антивирусы и не напускаю страшилок. Антивирус — это что-то вроде страховки. Покупать ее не обязательно (хотя в рекламе страховых услуг обычно утверждается обратное), но кто-то все же покупает страховки, для кого-то они нужны. Так же и с антивирусом. Лучше, чтобы Касперский все же выпустил полноценный KIS под linux, а уж покупать или нет — это каждый сам решит.
Меня всегда удивляет мнение, что на Линуксе или Маке вирусов нет. Надо понимать три вещи… Во-первых если вы не замечаете вируса, это не значит, что его нет. Во-вторых вирусы могут проникнуть даже на самую защищенную систему, эксплуатируя уязвимость, в т.ч. и нулевого дня. От уязвимостей ни одно серьезное ПО не застраховано. В-третьих, про систему прав доступа — не все вирусы стремятся закрепиться в вашей ОС навсегда. К примеру, на Хабре была статья про Java-вирус, который загружался на компьютер жертвы через дыру в JVM и оставался в памяти до перезагрузки системы. Никаких изменений в файловой системе он не делал, а поэтому с ограничениями прав доступа не сталкивался. Он просто висел в памяти с правами браузера и на фоне неторопливо рассылал спам, участвовал в ddos и т.д. И пусть этот вирус запущен с ограниченными правами моего браузера и не может навредить ядру ОС (ведь все права настроены правильно), мне все равно было бы неприятно иметь такого временного парозита на своем ПК.
Но и считать, что без антивируса пользоваться ПК или смартфоном нельзя — это тоже перегиб.
Я просчитал указанную вами статью и ничего такого про опасность стандартной конфигурации PHP не нашел. В статье описана история взлома, которая началась с эксплуатации известной уязвимости старой версии форума phpBB. Не было бы устаревшего phpBB, не было бы и истории. Настройки интерпретатора PHP здесь ни при чем.
Конечно, вы правы, что C++ на порядок круче PHP в плане производительности. С этим вообще никто не спорит. Но реальность такова, что на свете есть много людей, которые по разным причинам используют PHP, и для них вопрос повышения производительности может быть актуален. Зря вы так критикуете статью, в ней нет ничего плохого.
Я не отрицаю очевидное. Вы пишете, что сжатие имен css-классов мало кому нужно. Я с вами абсолютно согласен. Но кому-то это нужно и с этим ничего не поделаешь. Я не понимаю сути спора.
> отдаем сжатый файл и выставляем соотвественно content-encoding
Как вы меняете content-encoding через htaccess?
> И реализовать это можно даже если у Вас на виртуалке отключен ZIP.
Я хотел бы уточнить насчет предлагаемого вами метода предварительного gzip-сжатия. Как это можно сделать в рамках виртуального хостинга?
К примеру, мне нужно раздавать сжатый gzip-ом css-файл. Насколько я понимаю, я не могу просто так взять и сослаться на этот файл из html-кода. Чтобы браузер корректно налету распаковал этот архив, нужно послать ему (браузеру) http-заголовок «Content-Encoding: gzip». Это можно легко сделать через, к примеру, php-скрипт, который загрузит с диска сжатый файл, добавит на выход недостающий http-заголовок и далее пошлет файл клиенту. Но php-скрипт для раздачи статики — это уж совсем как-то не рационально.
Что мне нужно сделать, чтобы мой статический сжатый gzip-ом файл отдавался бы напрямую клиенту с нужным http-заголовком? Проблема актуальна именно для виртуального хостинга, где нет доступа к настройкам веб-сервера.
И не стоит всех пользователей виртуального хостинга ровнять под одну гребенку. Если твой сайт на виртуальном хостинге, это не значит, что ты не думаешь о производительности и непременно подгружаешь «изображения или библиотечку метра на 1.5».
Подгружать скриптом заранее сжатый zip-ом статический файл я бы точно не стал. Уж лучше тогда оставить без zip-сжатия. Виртуальных же хостингов с нормальных zip-сжатием я, признаюсь, не встречал.
Однако, совершенно реально создать некую спецификацию, подход к именованию классов. Например, можно договориться, что все имена классов, подвергающихся сжатию, должны быть записаны с определенным префиксом. В таком случае разработчик сам сможет выделить для себя группу классов, имена которых сжимать не нужно. В таком походе есть смысл. Конечно, эта лишняя спецификация несколько усложнит написание кода, но ведь в Гугле она используется и ничего, никто не умер.
Наличие zip-сжатия с данным методом не вступает в противоречие, т.к. zip сжимает еще много чего, для него работа все равно останется. А вот для владельцев сайтов на виртуальных хостингах, где zip-сжатия обычно нет, этот подход пригодился бы.
«Считать байты в наш век гигабитного интернета как-то глупо» — да, это верно. Но мобильный Интернет еще далек от века гигабитных технологий. А через мобильные устройства сегодня в Рунете делается каждый четвертый хит.
Спасибо за данные по росту нагрузок. Я долго вдумывался в вашу последнюю фразу и, наконец, понял: если после ввода https рост нагрузки не заметен, то это значит, что ваш сервис настолько сильно тормозит, что нагрузка https — это капля в море.
Основываясь на вашем опыте использования огромного парка железа, ориентировочно на сколько процентов возрастает нагрузка на сервер при включении https? Речь идет о самом простом случае — сервер раздачи статического контента.
Жителям санкционных регионов нужно было дать время на перенос доменов к другим регистраторам по причине того, что godaddy более не может их обслуживать на законных основаниях. Это бы я понял — нормальные санкции. А то, что делает godaddy — это разводка какая-то.
Помню свою школу и вступительный экзамен в универ по информатике — там только про алгоритмы и шла речь. Вопросов про управление памятью не было и в помине. Я писал на Pascal, но все эти программы с равной степенью успешности мог бы писать и на Бейсике, разницы не было бы никакой.
Когда же человек, получив начальные знания, продолжает интересоваться программированием, то если будет нужно, он уже сам и с низкоуровневым ассемблером, и с высокоуровневыми языками познакомится.