У MS с бизнес-этикой у самих большие проблемы, но эта их претензия абсолютно справедлива.
Одно дело, когда о 0-day уязвимости знают, скажем 1000 злоумышленников за счёт общения в своей среде (и то такую информацию выгоднее придерживать у себя или торговать ей). И совсем другое — когда о ней знает чуть ли не весь IT мир, патча нет, а до многих персональных Win машин он и не дойдёт даже когда будет готов. Google конечно имеет полное право информировать MS согласно своим представлениям о сроках, но такой подход — палка о 2 концах. Получается, если я, скажем, обнаружу уязвимость в Chrome/Chromium, то, аналогично Google, я имею полное моральное право выложить эту информацию в сеть за такое время, которое мне диктуют МОИ представления о сроках? ОК, мои правила говорят, что на патч надо отводить, скажем, 1 час.)) Отправляю письмо в гугл и через час пощу новость на хабр, slashdot, reddit ит.д., а чо, пускай поторопятся с патчем. Гугл будет выпускать патч, скажем, сутки-двое. За это время мошенники поимеют несколько десятков тысяч экземпляров Chrome/Chromium, не говоря уже о том, что не каждый экземпляр регулярно обновляется и эксплойт на такие экземпляры будет действовать пока пользователь не обновит браузер.
Мои глаза… В терминологии ПЭП, словами «электронная подпись» и «закрытый ключ» называются вещи, которые не являются ни электронными подписями, ни закрытыми ключами. Никакой пароль к почте или к чему там не может называться термином «закрытый ключ», никакой логин — термином «открытый ключ», а факт получения документа с доверенного email адреса не может называться «электронной подписью».
И ещё, судя по статье, ФЗ вообще не умеет регулировать криптографические системы, в которых участник идентифицируется чем-то иным, кроме паспортных данных? Например, просто публичным ключом?
> 1. листать ман в консоли и удобно браузить по десятку вкладок — две большие разницы.
Здесь не всё так однозначно… В сети лежит огромное количество информации, в том числе разжёванных howto и т.д., а веб-поиск очень интерактивен и прост («ок гугл, git stash unmerged files»), но на этом преимущества веба кончаются.
groff (aka «man-страница») и info — сто лет существующие форматы, давно ставшие стандартом документации в юниксах, я могу смотреть их на машине без подключения к сети, в какой захочу программе (man и info это далеко не единственные программы просмотра man/info, я например пользуюсь другим просмотрщиком), могу индексировать их, производить сложный поиск, производить поиск только в открытых файлах, делать что угодно, а ещё в юниксы традиционно кладут кучу локальных howto и примеров в довесок к man-страницам (собственно, веб-поиск обычно и приводит просто-напросто на выложенную в сеть man- или howto-страницу).
Справка в виде веб-страницы в сети: требует наличия интернет-подключения и запуска одного из самых тяжеловесных приложений — веб-браузера, а возможности навигации/поиска ограничены тем, что заложено в веб-страницу, браузер и поисковик. Для демонстрации возможностей своего браузера в этой области попробуйте решить задачу «из 30 открытых вкладок быстро найти те, заголовок или содержимое которых содержат слово git».
> 2. чтобы почитать локальную справку нужно хотя бы знать какой утилитой пользоваться а затем её установить, если её нет. Чтобы понять что и как устанавливать — нужен браузер.
Если речь идёт именно о «консольных» форматах, info и встроенной помощи, то нагуглить, что man-страницы открываются утилитой man, info-страницы открываются утилитой info, а консольный вывод смотрится less и т.д., достаточно один раз в жизни.=))) То же самое с изучением этих утилит: требуется потратить некоторое время, но это действие, выполняемое 1 раз в жизни. Эти утилиты как правило есть в системе и ничего ставить не надо.
> 3. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи
Для этого есть поиск по локальной справке, в том числе нечёткий.
Обычно есть локальная справка. У привычки лезть за любой справкой в сеть есть и негативный эффект, особенно он наблюдается среди *nix пользователей в последние годы — люди вообще разучиваются пользоваться локальными man страницами и программами info/man в принципе.
> git checkout < file > // отбросить все изменения в одном файле с последней выгрузки в систему
> git reset --hard // отбросить все изменения во всех файлах с последней выгрузки в систему
> Две разные команды для одной функции с одной разницей в том, что одна для одиночного файла, а вторая — для множества файлов.
Команда для отбрасывания изменений во многих файлах или в целом каталоге проста и логична и ничем не отличается от отбрасывания изменений в одном файле: git checkout file1 file2 dir3 dir4… То, что другие команды (например git reset --hard или git checkout -f) способны произвести тот же эффект, не значит, что «в гит изменение в одном файле откатывается одной командой, а изменение во всех файлах — другой!11». В общем, кто-то ниасилил git checkout --help.
Одно хорошо — на Linux машинах, на которые гарантированно логинятся только не-злоумышленники (например, на личных и домашних ПК), эту уязвимость можно эксплуатировать только если спровоцировать пользователя запустить левый бинарник/скрипт, от чего, надеюсь, большинство отучено.
(Я, правда, не учитываю системные аккаунты вида apache, ftp и т.д.)
Во-первых, мб всё-таки какое-то самописное POSIX-совместимое ядро, а не ядро Linux? Во-вторых, сразу два выражения звучат довольно бессмысленно: «implemented a kernel» (они с ним что угодно сделали — «integrated», «built in», но не «implemented») и указание конкретного релиза ядра.
Так идите и продолжайте холивар в том месте, где кто-то его с вами начал. Вы нашли какой-то Windows-софт для себя и почему-то совместили его описание с детсадовскими наездами на Linux в ответ на какие-то не менее детсадовские наезды на Windows, которые выкопали непонятно где.
> Не нашёл того который будет отвечать моим требованиям.
Какая жалость. Возможно, вам не стоит использовать ОС, в которой нет нужного вам софта, и перестать высказывать в её адрес критику по тем вопросам, в которых не разбираетесь?
Во-вторых, именно про редактирование скриптов на работающем сайте с помощью примонтирования по ssh никто всё равно не говорил. Я повторяю свой вопрос: откуда вы это взяли и зачем приплели к обсуждению?
Она гетерогенные сети умеет поддерживать (т.е. где разные ОС, не только юниксовые), или скажем интегрироваться с Active Directory? Чисто юниксовые сетки всё-таки не так часто встречаются
> Вы говорите что я что-то утверждаю и в подтверждение приводите не мои слова, а Ваши?
Что за бред. Я предлагал найти искомые цитаты из ВАШИХ слов в МОЁМ комменте.
Выражайте мысли яснее, у вас с этим проблемы.
Если вы не пользуетесь сетевой шарой для редактирования работающего сайта, зачем вообще было это приплетать в самом начале, создавая ложное впечатление, что именно так вы и делаете и противопоставляете это sshfs в линуксе? Зачем и кому доказывать, что это неудобно? Ну да, неудобно, никто и никогда так не делает. Сами придумали несуществующий кривой workflow и сами его критикуете, ну отлично.
Про инструменты — а я не имел в виду какие-то навороченные и т.д., прочитайте внимательно мой коммент. Я сказал — «наилучшие», для вас. ОК, вы выбрали какие-то наилучшие для своих задач и выдали список, над которым мне немедленно захотелось поглумиться, тк судя по этому списку, вы пишете/администируете сайты уровня домашней странички, слабо знакомы с соответствующей предметной областью, и считаете, что можно писать на хабр статью, где выражаете своё авторитетное мнение. Ну ок, пойду тоже что ли статью напишу про то, как я сайты правлю блокнотом и мне норм.
Ну как, вы же утверждаете, что провели суперкрутой анализ инструментария и выбрали прям наилучшие инструменты, перечисленные в тексте статьи. Одновременно вы утверждаете, что для редактирования сайта вы подключаете содержимое хоста с сайтом через сетевой диск и правите его наживую. То есть ни средств деплоинга, ни системы контроля версий. Я должен был сделать какой-то другой вывод?
Одно дело, когда о 0-day уязвимости знают, скажем 1000 злоумышленников за счёт общения в своей среде (и то такую информацию выгоднее придерживать у себя или торговать ей). И совсем другое — когда о ней знает чуть ли не весь IT мир, патча нет, а до многих персональных Win машин он и не дойдёт даже когда будет готов. Google конечно имеет полное право информировать MS согласно своим представлениям о сроках, но такой подход — палка о 2 концах. Получается, если я, скажем, обнаружу уязвимость в Chrome/Chromium, то, аналогично Google, я имею полное моральное право выложить эту информацию в сеть за такое время, которое мне диктуют МОИ представления о сроках? ОК, мои правила говорят, что на патч надо отводить, скажем, 1 час.)) Отправляю письмо в гугл и через час пощу новость на хабр, slashdot, reddit ит.д., а чо, пускай поторопятся с патчем. Гугл будет выпускать патч, скажем, сутки-двое. За это время мошенники поимеют несколько десятков тысяч экземпляров Chrome/Chromium, не говоря уже о том, что не каждый экземпляр регулярно обновляется и эксплойт на такие экземпляры будет действовать пока пользователь не обновит браузер.
И ещё, судя по статье, ФЗ вообще не умеет регулировать криптографические системы, в которых участник идентифицируется чем-то иным, кроме паспортных данных? Например, просто публичным ключом?
Здесь не всё так однозначно… В сети лежит огромное количество информации, в том числе разжёванных howto и т.д., а веб-поиск очень интерактивен и прост («ок гугл, git stash unmerged files»), но на этом преимущества веба кончаются.
groff (aka «man-страница») и info — сто лет существующие форматы, давно ставшие стандартом документации в юниксах, я могу смотреть их на машине без подключения к сети, в какой захочу программе (man и info это далеко не единственные программы просмотра man/info, я например пользуюсь другим просмотрщиком), могу индексировать их, производить сложный поиск, производить поиск только в открытых файлах, делать что угодно, а ещё в юниксы традиционно кладут кучу локальных howto и примеров в довесок к man-страницам (собственно, веб-поиск обычно и приводит просто-напросто на выложенную в сеть man- или howto-страницу).
Справка в виде веб-страницы в сети: требует наличия интернет-подключения и запуска одного из самых тяжеловесных приложений — веб-браузера, а возможности навигации/поиска ограничены тем, что заложено в веб-страницу, браузер и поисковик. Для демонстрации возможностей своего браузера в этой области попробуйте решить задачу «из 30 открытых вкладок быстро найти те, заголовок или содержимое которых содержат слово git».
> 2. чтобы почитать локальную справку нужно хотя бы знать какой утилитой пользоваться а затем её установить, если её нет. Чтобы понять что и как устанавливать — нужен браузер.
Если речь идёт именно о «консольных» форматах, info и встроенной помощи, то нагуглить, что man-страницы открываются утилитой man, info-страницы открываются утилитой info, а консольный вывод смотрится less и т.д., достаточно один раз в жизни.=))) То же самое с изучением этих утилит: требуется потратить некоторое время, но это действие, выполняемое 1 раз в жизни. Эти утилиты как правило есть в системе и ничего ставить не надо.
> 3. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи
Для этого есть поиск по локальной справке, в том числе нечёткий.
> git reset --hard // отбросить все изменения во всех файлах с последней выгрузки в систему
> Две разные команды для одной функции с одной разницей в том, что одна для одиночного файла, а вторая — для множества файлов.
Команда для отбрасывания изменений во многих файлах или в целом каталоге проста и логична и ничем не отличается от отбрасывания изменений в одном файле: git checkout file1 file2 dir3 dir4… То, что другие команды (например git reset --hard или git checkout -f) способны произвести тот же эффект, не значит, что «в гит изменение в одном файле откатывается одной командой, а изменение во всех файлах — другой!11». В общем, кто-то ниасилил git checkout --help.
Он что, серьёзно?
(Я, правда, не учитываю системные аккаунты вида apache, ftp и т.д.)
Зачем путать людей, говоря «implemented a Linux kernel»?
Во-первых, мб всё-таки какое-то самописное POSIX-совместимое ядро, а не ядро Linux? Во-вторых, сразу два выражения звучат довольно бессмысленно: «implemented a kernel» (они с ним что угодно сделали — «integrated», «built in», но не «implemented») и указание конкретного релиза ядра.
> Не нашёл того который будет отвечать моим требованиям.
Какая жалость. Возможно, вам не стоит использовать ОС, в которой нет нужного вам софта, и перестать высказывать в её адрес критику по тем вопросам, в которых не разбираетесь?
Во-вторых, именно про редактирование скриптов на работающем сайте с помощью примонтирования по ssh никто всё равно не говорил. Я повторяю свой вопрос: откуда вы это взяли и зачем приплели к обсуждению?
Ваши слова. Нигде выше в треде этот треш не упоминался.
Что за бред. Я предлагал найти искомые цитаты из ВАШИХ слов в МОЁМ комменте.
Выражайте мысли яснее, у вас с этим проблемы.
Если вы не пользуетесь сетевой шарой для редактирования работающего сайта, зачем вообще было это приплетать в самом начале, создавая ложное впечатление, что именно так вы и делаете и противопоставляете это sshfs в линуксе? Зачем и кому доказывать, что это неудобно? Ну да, неудобно, никто и никогда так не делает. Сами придумали несуществующий кривой workflow и сами его критикуете, ну отлично.
Про инструменты — а я не имел в виду какие-то навороченные и т.д., прочитайте внимательно мой коммент. Я сказал — «наилучшие», для вас. ОК, вы выбрали какие-то наилучшие для своих задач и выдали список, над которым мне немедленно захотелось поглумиться, тк судя по этому списку, вы пишете/администируете сайты уровня домашней странички, слабо знакомы с соответствующей предметной областью, и считаете, что можно писать на хабр статью, где выражаете своё авторитетное мнение. Ну ок, пойду тоже что ли статью напишу про то, как я сайты правлю блокнотом и мне норм.