На самом деле вышеописанное — это баг апача. Потому что нельзя такую фичу "просто отключить", именно по описанной в статье причине. Для производительности можно сделать много другого — кешировать, проверять наличие .htaccess файлов при запуске и выдавать фатальную ошибку если они были найдены (т.е. вынудить админа либо явно включить поддержку .htaccess обратно, либо ручками удалить все такие файлы — и тогда уже он должен понимать, что делает), реализовать перечитывание этих файлов в фоне отдельным процессом или через inotify, etc. В общем, полно способов улучшить производительность не жертвуя безопасностью такого критичного элемента инфраструктуры как веб-сервер. Основная проблема как раз в том, что все озабочены в первую очередь фичами, во вторую скоростью, а о безопасности начинают думать только тогда, когда из-за её отсутствия начинают происходить инциденты. Поэтому эта идея пока относится к ненаучной фантастике:

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

Чтобы не пестрило — есть CSS.
Чтобы не пестрило на сторонних сайтах — есть user.css в браузере.
Чтобы было красиво — можно делать очень много чего, но удаления из текста ссылок среди этого нет.
Чтобы читатель дочитывал до конца — текст должен вызывать интерес, наличие/отсутствие в тексте ссылок не является фактором, определяющим будет ли он дочитан.
Соблазн перейти по ссылке при таком форматировании теряется вообще, потому что к концу статьи найти те три из пятнадцати, которые меня заинтересовали в процессе чтения — нереально, потому что их номера никто не будет запоминать, равно как и не будет прыгать между списком ссылок и текстом в процессе чтения — зачем тогда вообще эти ссылки нужны, если не брать формально-диссерную причину "для порядка"?

Резюмируя, реальная причина ровно одна (у Вас она упомянута последней).

Прошу прощения за оффтопик, но какого чёрта ссылки из статьи вынесены в конец? Это что, стильно-модно-молодёжно бегать от "[8]" в середине статьи в её конец чтобы перейти по ссылке? Вы хабр на бумаге читаете и ссылки с бумаги ручками перебиваете в браузер?

Для работы он вполне юзабельный. И не раздражает. Удобен весьма относительно — при неплохом UX в рамках одной компании/команды всё становится не так радужно когда открытых компаний/команд больше одной (фриланс, тематические чаты разных сервисов/приложений, etc.). Плохо, что они шлюз в XMPP недавно прикрыли, вместо того чтобы его допилить — было удобно общаться в слаке из pidgin. Ещё плохо, что даже привыкнув к нему и смирившись с недостатками туда нереально перетащить не рабочее общение. В общем, на текущий момент и в области рабочей переписки он заметно лучше большинства популярных альтернатив. А потенциально более адекватные и безопасные альтернативы вроде Matrix значительно менее популярны.

Зависит от сервиса.

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

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

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

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

Я NATS Streaming тестировал пару месяцев назад — как по мне, он ещё сыроват. К самому NATS претензий нет, но вот Streaming под нагрузкой и с внезапными рестартами глючил странным образом, что-то терял, что-то присылал не в том порядке.

Э… с каких пор под линухом нет среды разработки?
И для чего под линухом нужен .Net (я к тому, что если уже переходите, так и пишите новые приложения под линух традиционным способом, без использования технологий от Майкрософт)?
С другой стороны, всем известно, что нет ничего более постоянного, чем временное — так что если винду разрешили временно в виртуалке, то скорее всего она там останется очень надолго, и паниковать ещё рано.
Кстати говоря, сейчас Wine уже сильно не тот, что лет 15 назад — я в шоке, но Steam под линухом сейчас запускает половину виндовых игр одним нажатием кнопки! Так что и виндовые САПР/КАД тоже, вероятно, будут неплохо работать и без виртуалки с виндой.

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

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

А почему нет? Риска — ноль. Ответственности — ноль. Работы — почти ноль. Зато пиара — море. Плюс иллюзия активной деятельности на благо общества и/или государства.

Таймауты нужны затем, что данные нужны, но не позднее чем через X. Потому что, например, где-то сидит юзер, отправивший запрос, и ему нужно оперативно вернуть ответ. И если оперативно не получается — нужно прервать операцию и вернуть ошибку — это лучше, чем подвиснуть на несколько минут. Если нативной поддержки таймаутов на соединения нет, то их приходится эмулировать создавая отдельные горутины/callback-и, которые будут вызываться через заданное время, проверять что операция ещё не завершилась, и закрывать соединение чтобы прервать эту операцию. Просто кучка лишней ручной работы плюс лишний источник багов (потому что тестированием таймаутов зачастую пренебрегают, ибо долго и неудобно).

Может выполняться и параллельно, если «исполнятель» (реактор и т.п.) умеет это делать.

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

Из личного опыта — я асинхронный код писал лет 15. В основном на Perl, но не только. Для перла я даже делал свою реализацию event loop на epoll, когда в перле поддержки epoll ещё не было (потом со своей реализации перешёл на восхитительную библиотечку EV/libev). С другой стороны, синхронный код на горутинах и каналах я тоже писал ещё до появления Go — на Limbo (одном из прародителей Go). Я знаю, что у многих программистов проблема с пониманием и написанием асинхронного кода, но я к ним не отношусь — мне асинхронный код всегда давался достаточно легко. Тем не менее, имея много опыта в обоих подходах, я честно скажу: писать на горутинах синхронный код реально в 2-3 раза проще и быстрее. А читать его проще раз в 10.

Горутины:

• выполняются параллельно (напр. если они заняты тяжёлыми вычислительными задачами без какого-либо I/O, т.е. без точек, где можно перехватить выполнение при cooperative multitasking, то всё-равно будет параллельно выполняться примерно столько горутин, сколько на компе ядер CPU) — что позволяет не беспокоится о том, что обработчик какого-то события окажется слишком медленным и приостановит работу всей системы
• позволяют использовать блокирующий I/O — что позволяет писать код более просто и ясно, чем асинхронный на callbacks/futures/promises
• очень быстро создаются и уничтожаются миллионами — что позволяет строить на этом архитектуру приложения, в результате чего оно обычно упрощается
• миллионы горутин используют достаточно мало памяти (обычно у горутины стек 2KB, т.е. миллион сожрёт всего 2GB RAM — иными словами даже на ноуте с 4-8GB RAM вполне реально погонять клиент/сервер на миллион соединений (на практике надо ещё ядро потюнить, иначе ядро на каждый сокет ещё около 8KB сожрёт)

Иными словами, это даёт возможность писать приложения совершенно иначе — в целом, намного проще, и при этом очень эффективно в плане производительности и памяти. Если убрать любой из этих пунктов — в таком стиле нагруженные приложения писать станет невозможно. Как с этими пунктами у тасков C#/Java?

Ничего подобного, Вы меня просто не поняли. Имелось в виду, что при переходе на другой "лучший" язык в котором исключения есть из коробки, не хотелось бы потерять то, что ценно в Go.

Изобрёл, безусловно, не Go. Проблема обычно в том, что каждой нити, лёгкая она или нет, нужен свой стек. И вот размер этого стека, умноженный на миллионы нитей, создаёт одну из основных проблем при реализации этого подхода. Языки, в которых изначально не заложили поддержку маленького, динамически растущего стека, обычно не в состоянии эффективно добавить поддержку этой фичи. Вот, например, бенчмарк (правда, тут задача сильно проще, чем делать I/O): https://github.com/atemerev/skynet — .Net (C# вроде на нём, если не путаю) там упоминается только в контексте Futures/promises, а это, насколько я понимаю, не совсем то же самое, что лёгкие нити в го, это вроде про асинхронный код, как в NodeJS, а он не выполняется параллельно как горутины.

Возможно я немного отстал, я на этих языках не пишу, но, насколько я помню, в C# нельзя было плодить миллионы корутин, и в чистой Java тоже (но вроде можно было на каких-то других языках на базе JVM). Расскажите плз, как с этим делом сейчас — реально можно написать на C# и Java лёгкий сервер, который будет держать миллионы одновременных соединений используя по две корутины на соединение (в которых блокирующие чтение и запись), общающиеся между собой через каналы, и он будет иметь производительность и потребление памяти сравнимое с Go?

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

С чего бы? Я вот не фанат исключений в Go и использовать это не планирую, но — почитать было интересно, работа проделана достойная, причин наезжать на автора просто нет.

С телефонами та же фигня, только LineageOS вместо OpenWrt.

Чтобы что-то обнаружить есть http://rkhunter.sf.net/ и http://www.chkrootkit.org/.

А что такое "VoIP-трафик"? Технически? Это только SIP? Или любой мессенджер а-ля Skype? Если любой, то считается ли текстовая переписка VoIP-трафиком, особенно если протокол мессенджера такой, что отличить одно от другого невозможно? А передача файла через мессенджер? А если трафик юзера завёрнут в VPN?

Да, при условии, что эта сеть не тормозит настолько, как описывает balexa.

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

В zsh выводимое значение задаётся в $PROMPT_EOL_MARK. Думаю, если установить её в пустую строку или перевод строки — сработает как отключение фичи.

Скажем так. Изменять alias-ами команды, которые отвечают за вывод информации (ls, ну grep) — это одно. Изменять команды, которые изменяют/удаляют файлы — это уже совсем другое. Напр. mkdir -p это относительно безобидно, максимум возможного ущерба — создаст не те каталоги из-за опечатки в середине пути, что и маловероятно, и вряд ли станет реальной проблемой. Но вот уже cp -r это другая тема — я согласен с автором насчёт того, что это легаси и сейчас не актуально, но привыкнув запускать cp без -r рано или поздно можно скопировать намного меньше данных, чем рассчитывал (на машине без этого алиаса), и заметить это через месяц, когда уже поздно будет.

Суть не в том, что мы рано или поздно включаем рута, а в том, чтобы не выполнять от рута "случайных" команд. Для этого нужно во-первых всегда чётко осознавать что текущая команда выполняется от рута (что можно достигать разными способами — sudo, явная визуальная индикация что это рутовый шелл, отдельный хоткей для вызова рутового терминала, etc.), и во-вторых стараться не выполнять от рута то, что не требует рута (здесь только sudo спасает из-за лени).
Я тоже предпочитаю индикацию вместо sudo, но при этом нередко запускаю от рута man и т.п. — то, что можно было бы запустить и под юзером… вреда от этого пока не было, но по факту от рута запускается немного больше, чем необходимо.

Есть. Я тоже опасался при переходе на zsh, что это будет критично. На самом деле, неудобства, те или иные, есть всегда.
Раньше их было больше на рабочем компе, сейчас на рабочем компе почти всё (времени нормально разобраться в настройке автокомплита zsh у меня не хватило, так что он иногда работает странно — будет время, допилю) стало намного лучше. Раньше на удалённых компах их было меньше, сейчас их немного больше.
По факту — от перехода на zsh я не забыл bash и как работать в нём на удалённых компах. Отличия есть, но не настолько критичные. Так что новые неудобства совершенно однозначно не перевешивают новые удобства — по факту в результате (если брать в среднем по всем местам где набираются команды) стало таки заметно лучше. Кое-где на удалённых машинах я добавил алиасов в bash. Кое-где поставил zsh, но это скорее в качестве эксперимента, пытался понять насколько он мне там реально нужен — по факту оказалось, что не особо.

В zsh тоже есть:

hash -d MyProj=~/proj/some/long/path/to/my/project

Есть разные реализации, разные оптимизации. Подлагивают далеко не все. Опять же, от детальности выводимой информации зависит то, удастся ли использовать некоторые оптимизации. При адекватном подходе в случае git всё летает, исключая гигантские репо вроде ядра линуха, но их можно исключать в индивидуальном порядке.

Вообще-то в zsh есть штатный механизм для этой фичи: push-input. Судя по быстрому взгляду на используемый автором конфиг у него он может срабатывать по Ctrl-z. Я себе настроил на Ctrl-q и Esc-q вот так:

zbindkey '^Q'  push-input # отложить текущую команду
zbindkey '^[q' push-input # use ^[Q to push single line while at PS2

Работает следующим образом:

1. набираем (частично) команду
2. понимаем, что перед её выполнением надо сначала запустить другую команду
3. нажимаем Ctrl-q
4. вводим забытую команду и Enter
5. в командной строке автоматически появляется то, что было набрано перед Ctrl-q

Ну, формально из этой идеи всё-таки есть несколько вполне практичных следствий:

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

Вот бы ещё всё остальное из PaX и GrSecurity получить на текущих ядрах… minipli остановился на 4.9.74, ниасилив слияние с патчами Meltdown/Spectre. :( Персональных лицензий GrSec не продают. Сидеть вечно на 4.9.74 тоже не вариант. Всё плохо, в общем.

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

Это совет для roodz и consalt, лично мне кириллические буквы в домене не интересны.

С видео может помочь стандартный трюк: https://gist.github.com/ruario/bec42d156d30affef655

Ну, смысл ведь в том, чтобы уведомить пользователя о потенциальном фишинге, а не в том, чтобы он не видел русских букв в url. А уведомить можно массой способов — напр. выделять все не-ascii символы в домене цветом.

Ну да, сейчас на убунте текущая 1.14.0. Ну тогда надо обновляться, а не прикрываться. :)