Сообщение Re[21]: dotnet vs java 2016-2020 от 11.10.2016 9:04
Изменено 11.10.2016 9:06 vdimas
Здравствуйте, Cyberax, Вы писали:
V>>>>Почему? Есть задача, вот решение.
C>>>Потому, что это не решение.
V>>Такое же точно.
V>>Просто менее популярно, бо это идиотизм сам по себе — вот такое распространение кода.
C>Ну да. Код должен распространятся раз в месяц, в четверг. Если что-то сломалось — пишется заявление в отдел QA и через год фиксится.
В мире Windows фиксится намного быстрее. И мне уже надоело напоминать, почему именно так — потому что всего одна "сборка".
А под Линухами где-то фикс прокатил, а где-то ГОДАМИ под некую сборку нет нужных фиксов, потому что под эту сборку имеющийся фикс не прокатывает, а "сообществу" некогда.
V>>Не спроста же, если атакуют клиентские компы — атакуют винды, а если сервера — то линуха. Причем, с атаками на винды 8.1 и выше уже разобрались, а вот с серверами засада — бедная Клинтон ругает плохих русских, ы-ы-ы. Атаковать же виндовый Server 2012 с установленным в комплекте софтом на ReFS на сегодня абсолютно бесполезно. В этом смысле Линуха — это дуршлак, а не операционка.
C>LOL. У Клинтон как раз был Exchange на Винде.
Там в сетку вошли через их линуховые машины и атаковали клиентские компы, а не серверные.
И да, никакой exchange-сервак напрямую в сеть никогда не торчит, только через линуховые машины или линуховые же роутеры.
И было это в те времена, когда модель распространения софта в Windows была как до сих пор в Linux — т.е. можно было брать код с любой помойки.
Уже в Висте достаточно было не сидеть под админским профилем, чтобы стало невозможно заразить комп через письмо с вложением.
C>ReFS — это та штука, которая является бледным подобием BTRFS и которая выбросила на помойку такие фичи NTFS как транзакции?
Это такая штука, потребность в транзакционности внутреннего механизма которой сильно уменьшена.
И да, транзакции там можно включить по желанию и аж более одного уровня. Но почти никогда не надо из-за банального copy-on-write, доведённого до совершенства. Там всё является транзакцией (грубо), т.е. используются те же технологии, что и для транзакций.
Я не знаю, откуда ты взял про "бледное подобие", если на сегодня никто не умеет "copy-on-write" более эффективно, чем ReFS.
Кароч, я не готов обсуждать, какая файловая система была раньше-позже по этому принципу, хотя бы потому, что этот принцип родился еще намного ранее в файловых БД, а не в файловых системах. ))
Я и помню, как MS нам когда-то давно обещала файловую систему по принципу БД. Вот, разродилось, наконец. Принципы те же.
V>>Набор протоколов у программ на двух сторонах совпал. Обязательного к исполнению списка таких протоколов на сегодня нет, кста.
C>Ну то есть, проблемы нет. Совместимость минимум на 15 лет. В отличие от.
В отличие от чего?
C>>>Т.е. совместимость в 10 лет, как минимум, между разными ОС.
V>>Набор протоколов у программ на двух сторонах совпал.
C>Да. И больше ничего не надо для нормальной работы.
Но некоторые алгоритмы шифрования со временем протухают, признаются небезопасными, скомпроментированными.
Иначе бы не было нужды в новых, верно?
C>>>Опять говоришь из попы. Последние существенные изменения в SSH были в 2006-м году, и даже до этого SSH был де-факто совместим между всеми.
V>>Я уже возвращал тебя на грешную землю тем, что SSH — это тривиальнейший "клей" для алгоритмов и даже целых инфраструктур шифрования. Вся работа происходит в низлежащем слое, а вовсе не в SSH. Сами артефакты алгоритмов шифрования SSH даже не понимает, для него ключи — это просто набор непонятных ему байт некоей длины, эдакий черный ящик.
C>Давай поспорим? На $1k? Раз уж не понимаешь очевиднейших вещей и не можешь даже на RFC посмотреть.
Я тебе уже предлагал СФОРМУЛИРОВАТЬ свои утверждения для спора.
Пока что я не вижу достаточно для спора формулировки.
C>Моё утверждение: SSH — это полностью автономный протокол, который не использует слой TLS/SSL и реализует все необходимые примитивы шифрования как непосредственно деталь протокола. SSH так же не требует инфраструктуры PKI, но даже если её включить, то SSH не использует X509. Ключи и сертификаты SSH тоже не в формате X509.
Это НЕ является возражением на моё утверждение о том, что для SSH происходящее в слое шифрования — "черный ящик". Возражение должно было быть примерно таким:
— SSH понимает как формат ключей шифрования конкретного алгоритма, так и структуру шифрованного потока, т.е. под поля шифрованных потоков конкретных алгоритмов отводит в своём протоколе высокоуровневое описание.
Дерзай! ))
Далее, насчет возражений мне про инфраструктуру X.509. Верификация SSL и SSH построена абсолютно идентично, а именно — отдана на откуп отдельному блоку в стандарте, где сама реализация верификации может быть произвольной. Для текущих реализация SSH и SSL подобная верификация — это всегда некий колбэк, где в некоторой конкретной реализации есть некая дефолтная реализация. В упомянутой тобой реализации open SSH поверх open SSL (ты даже назвал эту связку частью ОС, помнится, ы-ы-ы) есть ровно две дефолтных реализации такого колбэка — с проверкой ключа+подписи и с проверкой только лишь ключа.
Для демона open SSH способ верификации и его параметры прописываются в файле конфигурации. Так вот, самое смешное в этом споре то, что ты выдаёшь дефолтные настройки open SSH за характеристики целого стандарта. Ы-Ы-Ы много раз.
V>>>>Почему? Есть задача, вот решение.
C>>>Потому, что это не решение.
V>>Такое же точно.
V>>Просто менее популярно, бо это идиотизм сам по себе — вот такое распространение кода.
C>Ну да. Код должен распространятся раз в месяц, в четверг. Если что-то сломалось — пишется заявление в отдел QA и через год фиксится.
В мире Windows фиксится намного быстрее. И мне уже надоело напоминать, почему именно так — потому что всего одна "сборка".
А под Линухами где-то фикс прокатил, а где-то ГОДАМИ под некую сборку нет нужных фиксов, потому что под эту сборку имеющийся фикс не прокатывает, а "сообществу" некогда.
V>>Не спроста же, если атакуют клиентские компы — атакуют винды, а если сервера — то линуха. Причем, с атаками на винды 8.1 и выше уже разобрались, а вот с серверами засада — бедная Клинтон ругает плохих русских, ы-ы-ы. Атаковать же виндовый Server 2012 с установленным в комплекте софтом на ReFS на сегодня абсолютно бесполезно. В этом смысле Линуха — это дуршлак, а не операционка.
C>LOL. У Клинтон как раз был Exchange на Винде.
Там в сетку вошли через их линуховые машины и атаковали клиентские компы, а не серверные.
И да, никакой exchange-сервак напрямую в сеть никогда не торчит, только через линуховые машины или линуховые же роутеры.
И было это в те времена, когда модель распространения софта в Windows была как до сих пор в Linux — т.е. можно было брать код с любой помойки.
Уже в Висте достаточно было не сидеть под админским профилем, чтобы стало невозможно заразить комп через письмо с вложением.
C>ReFS — это та штука, которая является бледным подобием BTRFS и которая выбросила на помойку такие фичи NTFS как транзакции?
Это такая штука, потребность в транзакционности внутреннего механизма которой сильно уменьшена.
И да, транзакции там можно включить по желанию и аж более одного уровня. Но почти никогда не надо из-за банального copy-on-write, доведённого до совершенства. Там всё является транзакцией (грубо), т.е. используются те же технологии, что и для транзакций.
Я не знаю, откуда ты взял про "бледное подобие", если на сегодня никто не умеет "copy-on-write" более эффективно, чем ReFS.
Кароч, я не готов обсуждать, какая файловая система была раньше-позже по этому принципу, хотя бы потому, что этот принцип родился еще намного ранее в файловых БД, а не в файловых системах. ))
Я и помню, как MS нам когда-то давно обещала файловую систему по принципу БД. Вот, разродилось, наконец. Принципы те же.
V>>Набор протоколов у программ на двух сторонах совпал. Обязательного к исполнению списка таких протоколов на сегодня нет, кста.
C>Ну то есть, проблемы нет. Совместимость минимум на 15 лет. В отличие от.
В отличие от чего?
C>>>Т.е. совместимость в 10 лет, как минимум, между разными ОС.
V>>Набор протоколов у программ на двух сторонах совпал.
C>Да. И больше ничего не надо для нормальной работы.
Но некоторые алгоритмы шифрования со временем протухают, признаются небезопасными, скомпроментированными.
Иначе бы не было нужды в новых, верно?
C>>>Опять говоришь из попы. Последние существенные изменения в SSH были в 2006-м году, и даже до этого SSH был де-факто совместим между всеми.
V>>Я уже возвращал тебя на грешную землю тем, что SSH — это тривиальнейший "клей" для алгоритмов и даже целых инфраструктур шифрования. Вся работа происходит в низлежащем слое, а вовсе не в SSH. Сами артефакты алгоритмов шифрования SSH даже не понимает, для него ключи — это просто набор непонятных ему байт некоей длины, эдакий черный ящик.
C>Давай поспорим? На $1k? Раз уж не понимаешь очевиднейших вещей и не можешь даже на RFC посмотреть.
Я тебе уже предлагал СФОРМУЛИРОВАТЬ свои утверждения для спора.
Пока что я не вижу достаточно для спора формулировки.
C>Моё утверждение: SSH — это полностью автономный протокол, который не использует слой TLS/SSL и реализует все необходимые примитивы шифрования как непосредственно деталь протокола. SSH так же не требует инфраструктуры PKI, но даже если её включить, то SSH не использует X509. Ключи и сертификаты SSH тоже не в формате X509.
Это НЕ является возражением на моё утверждение о том, что для SSH происходящее в слое шифрования — "черный ящик". Возражение должно было быть примерно таким:
— SSH понимает как формат ключей шифрования конкретного алгоритма, так и структуру шифрованного потока, т.е. под поля шифрованных потоков конкретных алгоритмов отводит в своём протоколе высокоуровневое описание.
Дерзай! ))
Далее, насчет возражений мне про инфраструктуру X.509. Верификация SSL и SSH построена абсолютно идентично, а именно — отдана на откуп отдельному блоку в стандарте, где сама реализация верификации может быть произвольной. Для текущих реализация SSH и SSL подобная верификация — это всегда некий колбэк, где в некоторой конкретной реализации есть некая дефолтная реализация. В упомянутой тобой реализации open SSH поверх open SSL (ты даже назвал эту связку частью ОС, помнится, ы-ы-ы) есть ровно две дефолтных реализации такого колбэка — с проверкой ключа+подписи и с проверкой только лишь ключа.
Для демона open SSH способ верификации и его параметры прописываются в файле конфигурации. Так вот, самое смешное в этом споре то, что ты выдаёшь дефолтные настройки open SSH за характеристики целого стандарта. Ы-Ы-Ы много раз.
Re[21]: dotnet vs java 2016-2020
Здравствуйте, Cyberax, Вы писали:
V>>>>Почему? Есть задача, вот решение.
C>>>Потому, что это не решение.
V>>Такое же точно.
V>>Просто менее популярно, бо это идиотизм сам по себе — вот такое распространение кода.
C>Ну да. Код должен распространятся раз в месяц, в четверг. Если что-то сломалось — пишется заявление в отдел QA и через год фиксится.
В мире Windows фиксится намного быстрее. И мне уже надоело напоминать, почему именно так — потому что всего одна "сборка".
А под Линухами где-то фикс прокатил, а где-то ГОДАМИ под некую сборку нет нужных фиксов, потому что под эту сборку имеющийся фикс не прокатывает, а "сообществу" некогда.
V>>Не спроста же, если атакуют клиентские компы — атакуют винды, а если сервера — то линуха. Причем, с атаками на винды 8.1 и выше уже разобрались, а вот с серверами засада — бедная Клинтон ругает плохих русских, ы-ы-ы. Атаковать же виндовый Server 2012 с установленным в комплекте софтом на ReFS на сегодня абсолютно бесполезно. В этом смысле Линуха — это дуршлак, а не операционка.
C>LOL. У Клинтон как раз был Exchange на Винде.
Там в сетку вошли через их линуховые машины и атаковали клиентские компы, а не серверные.
И да, никакой exchange-сервак напрямую в сеть никогда не торчит, только через линуховые машины или линуховые же роутеры.
И было это в те времена, когда модель распространения софта в Windows была как до сих пор в Linux — т.е. можно было брать код с любой помойки.
Уже в Висте достаточно было не сидеть под админским профилем, чтобы стало невозможно заразить комп через письмо с вложением.
C>ReFS — это та штука, которая является бледным подобием BTRFS и которая выбросила на помойку такие фичи NTFS как транзакции?
Это такая штука, потребность в транзакционности внутреннего механизма которой сильно уменьшена.
И да, транзакции там можно включить по желанию и аж более одного уровня. Но почти никогда не надо из-за банального copy-on-write, доведённого до совершенства. Там всё является транзакцией (грубо), т.е. используются те же технологии, что и для транзакций.
Я не знаю, откуда ты взял про "бледное подобие", если на сегодня никто не умеет "copy-on-write" более эффективно, чем ReFS.
Кароч, я не готов обсуждать, какая файловая система была раньше-позже по этому принципу, хотя бы потому, что этот принцип родился еще намного ранее в файловых БД, а не в файловых системах. ))
Я и помню, как MS нам когда-то давно обещала файловую систему по принципу БД. Вот, разродилось, наконец. Принципы те же.
V>>Набор протоколов у программ на двух сторонах совпал. Обязательного к исполнению списка таких протоколов на сегодня нет, кста.
C>Ну то есть, проблемы нет. Совместимость минимум на 15 лет. В отличие от.
В отличие от чего?
C>>>Т.е. совместимость в 10 лет, как минимум, между разными ОС.
V>>Набор протоколов у программ на двух сторонах совпал.
C>Да. И больше ничего не надо для нормальной работы.
Но некоторые алгоритмы шифрования со временем протухают, признаются небезопасными, скомпроментированными.
Иначе бы не было нужды в новых, верно?
C>>>Опять говоришь из попы. Последние существенные изменения в SSH были в 2006-м году, и даже до этого SSH был де-факто совместим между всеми.
V>>Я уже возвращал тебя на грешную землю тем, что SSH — это тривиальнейший "клей" для алгоритмов и даже целых инфраструктур шифрования. Вся работа происходит в низлежащем слое, а вовсе не в SSH. Сами артефакты алгоритмов шифрования SSH даже не понимает, для него ключи — это просто набор непонятных ему байт некоей длины, эдакий черный ящик.
C>Давай поспорим? На $1k? Раз уж не понимаешь очевиднейших вещей и не можешь даже на RFC посмотреть.
Я тебе уже предлагал СФОРМУЛИРОВАТЬ свои утверждения для спора.
Пока что я не вижу достаточной для спора формулировки.
C>Моё утверждение: SSH — это полностью автономный протокол, который не использует слой TLS/SSL и реализует все необходимые примитивы шифрования как непосредственно деталь протокола. SSH так же не требует инфраструктуры PKI, но даже если её включить, то SSH не использует X509. Ключи и сертификаты SSH тоже не в формате X509.
Это НЕ является возражением на моё утверждение о том, что для SSH происходящее в слое шифрования — "черный ящик". Возражение должно было быть примерно таким:
— SSH понимает как формат ключей шифрования конкретного алгоритма, так и структуру шифрованного потока, т.е. под поля шифрованных потоков конкретных алгоритмов отводит в своём протоколе высокоуровневое описание.
Дерзай! ))
Далее, насчет возражений мне про инфраструктуру X.509. Верификация SSL и SSH построена абсолютно идентично, а именно — отдана на откуп отдельному блоку в стандарте, где сама реализация верификации может быть произвольной. Для текущих реализация SSH и SSL подобная верификация — это всегда некий колбэк, где в некоторой конкретной реализации есть некая дефолтная реализация. В упомянутой тобой реализации open SSH поверх open SSL (ты даже назвал эту связку частью ОС, помнится, ы-ы-ы) есть ровно две дефолтных реализации такого колбэка — с проверкой ключа+подписи и с проверкой только лишь ключа.
Для демона open SSH способ верификации и его параметры прописываются в файле конфигурации. Так вот, самое смешное в этом споре то, что ты выдаёшь дефолтные настройки open SSH за характеристики целого стандарта. Ы-Ы-Ы много раз.
V>>>>Почему? Есть задача, вот решение.
C>>>Потому, что это не решение.
V>>Такое же точно.
V>>Просто менее популярно, бо это идиотизм сам по себе — вот такое распространение кода.
C>Ну да. Код должен распространятся раз в месяц, в четверг. Если что-то сломалось — пишется заявление в отдел QA и через год фиксится.
В мире Windows фиксится намного быстрее. И мне уже надоело напоминать, почему именно так — потому что всего одна "сборка".
А под Линухами где-то фикс прокатил, а где-то ГОДАМИ под некую сборку нет нужных фиксов, потому что под эту сборку имеющийся фикс не прокатывает, а "сообществу" некогда.
V>>Не спроста же, если атакуют клиентские компы — атакуют винды, а если сервера — то линуха. Причем, с атаками на винды 8.1 и выше уже разобрались, а вот с серверами засада — бедная Клинтон ругает плохих русских, ы-ы-ы. Атаковать же виндовый Server 2012 с установленным в комплекте софтом на ReFS на сегодня абсолютно бесполезно. В этом смысле Линуха — это дуршлак, а не операционка.
C>LOL. У Клинтон как раз был Exchange на Винде.
Там в сетку вошли через их линуховые машины и атаковали клиентские компы, а не серверные.
И да, никакой exchange-сервак напрямую в сеть никогда не торчит, только через линуховые машины или линуховые же роутеры.
И было это в те времена, когда модель распространения софта в Windows была как до сих пор в Linux — т.е. можно было брать код с любой помойки.
Уже в Висте достаточно было не сидеть под админским профилем, чтобы стало невозможно заразить комп через письмо с вложением.
C>ReFS — это та штука, которая является бледным подобием BTRFS и которая выбросила на помойку такие фичи NTFS как транзакции?
Это такая штука, потребность в транзакционности внутреннего механизма которой сильно уменьшена.
И да, транзакции там можно включить по желанию и аж более одного уровня. Но почти никогда не надо из-за банального copy-on-write, доведённого до совершенства. Там всё является транзакцией (грубо), т.е. используются те же технологии, что и для транзакций.
Я не знаю, откуда ты взял про "бледное подобие", если на сегодня никто не умеет "copy-on-write" более эффективно, чем ReFS.
Кароч, я не готов обсуждать, какая файловая система была раньше-позже по этому принципу, хотя бы потому, что этот принцип родился еще намного ранее в файловых БД, а не в файловых системах. ))
Я и помню, как MS нам когда-то давно обещала файловую систему по принципу БД. Вот, разродилось, наконец. Принципы те же.
V>>Набор протоколов у программ на двух сторонах совпал. Обязательного к исполнению списка таких протоколов на сегодня нет, кста.
C>Ну то есть, проблемы нет. Совместимость минимум на 15 лет. В отличие от.
В отличие от чего?
C>>>Т.е. совместимость в 10 лет, как минимум, между разными ОС.
V>>Набор протоколов у программ на двух сторонах совпал.
C>Да. И больше ничего не надо для нормальной работы.
Но некоторые алгоритмы шифрования со временем протухают, признаются небезопасными, скомпроментированными.
Иначе бы не было нужды в новых, верно?
C>>>Опять говоришь из попы. Последние существенные изменения в SSH были в 2006-м году, и даже до этого SSH был де-факто совместим между всеми.
V>>Я уже возвращал тебя на грешную землю тем, что SSH — это тривиальнейший "клей" для алгоритмов и даже целых инфраструктур шифрования. Вся работа происходит в низлежащем слое, а вовсе не в SSH. Сами артефакты алгоритмов шифрования SSH даже не понимает, для него ключи — это просто набор непонятных ему байт некоей длины, эдакий черный ящик.
C>Давай поспорим? На $1k? Раз уж не понимаешь очевиднейших вещей и не можешь даже на RFC посмотреть.
Я тебе уже предлагал СФОРМУЛИРОВАТЬ свои утверждения для спора.
Пока что я не вижу достаточной для спора формулировки.
C>Моё утверждение: SSH — это полностью автономный протокол, который не использует слой TLS/SSL и реализует все необходимые примитивы шифрования как непосредственно деталь протокола. SSH так же не требует инфраструктуры PKI, но даже если её включить, то SSH не использует X509. Ключи и сертификаты SSH тоже не в формате X509.
Это НЕ является возражением на моё утверждение о том, что для SSH происходящее в слое шифрования — "черный ящик". Возражение должно было быть примерно таким:
— SSH понимает как формат ключей шифрования конкретного алгоритма, так и структуру шифрованного потока, т.е. под поля шифрованных потоков конкретных алгоритмов отводит в своём протоколе высокоуровневое описание.
Дерзай! ))
Далее, насчет возражений мне про инфраструктуру X.509. Верификация SSL и SSH построена абсолютно идентично, а именно — отдана на откуп отдельному блоку в стандарте, где сама реализация верификации может быть произвольной. Для текущих реализация SSH и SSL подобная верификация — это всегда некий колбэк, где в некоторой конкретной реализации есть некая дефолтная реализация. В упомянутой тобой реализации open SSH поверх open SSL (ты даже назвал эту связку частью ОС, помнится, ы-ы-ы) есть ровно две дефолтных реализации такого колбэка — с проверкой ключа+подписи и с проверкой только лишь ключа.
Для демона open SSH способ верификации и его параметры прописываются в файле конфигурации. Так вот, самое смешное в этом споре то, что ты выдаёшь дефолтные настройки open SSH за характеристики целого стандарта. Ы-Ы-Ы много раз.