• Уходящая от вас безопасность
    +8

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


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

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


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

  • Пять камней в огород блокчейна
    +9

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

  • ? Skype превратился в унылое подобие… и продукт, позволяющий получить полный доступ к вашей системе? Есть ли надежда?
    0

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

  • Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности
    0

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


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


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

  • Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности
    0

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

  • Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности
    0

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

  • Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности
    0

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

  • Импортозамещение, сказки продолжаются (продолжение)
    +3

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

  • Импортозамещение, сказки продолжаются (продолжение)
    +12

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

  • Автоматизация секс-индустрии или госуслуги по-немецки
    +5

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

  • Омбудсмен предложила заблокировать объявления с потенциально опасными детскими товарами
    +1

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

  • Такой исключительный Go
    0

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

  • Такой исключительный Go
    0
    Может выполняться и параллельно, если «исполнятель» (реактор и т.п.) умеет это делать.

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

  • Такой исключительный Go
    +2

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

  • Такой исключительный Go
    +1

    Горутины:


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

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

  • Такой исключительный Go
    0

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

  • Такой исключительный Go
    0

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

  • Такой исключительный Go
    0

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

  • Такой исключительный Go
    0

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

  • Такой исключительный Go
    +5

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

  • IoT Security Week 38: уязвимости в роутерах MikroTik, D-Link и TP-Link
    +3

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

  • Защищаем веб-сервер на Linux
    0

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

  • Почему VoIP признали информационным сервисом в США, и что это значит для телеком-индустрии и пользователей
    +3

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

  • Работаем в консоли быстро и эффективно
    0

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

  • Работаем в консоли быстро и эффективно
    0

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

  • Работаем в консоли быстро и эффективно
    0

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

  • Работаем в консоли быстро и эффективно
    0

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

  • Работаем в консоли быстро и эффективно
    0

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

  • Работаем в консоли быстро и эффективно
    0

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

  • Работаем в консоли быстро и эффективно
    0

    В zsh тоже есть:


    hash -d MyProj=~/proj/some/long/path/to/my/project
  • Работаем в консоли быстро и эффективно
    0

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

  • Работаем в консоли быстро и эффективно
    +1

    Вообще-то в 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
  • Контроль над ситуацией делает тебя счастливым
    +1

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


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

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

  • Для чего хакерам Микротик и как я спрятал 100 тыс. RouterOS от ботнета
    +4

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

  • Vivaldi 2.0 в нашу пользу
    0

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

  • Vivaldi 2.0 в нашу пользу
    0

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

  • Vivaldi 2.0 в нашу пользу
    0

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

  • Vivaldi 2.0 в нашу пользу
    0

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