А можно, я попробую пояснить, что имел ввиду тов. Invision70?
Так вот, он пытается донести мысль, что обычно CMS пользуются не только админы. Зачастую доступ даётся всяким контент-менеджерам, которые по уровню компьютерной грамотности и элементарных навыков сетевой безопасности находятся где-то в пределах погрешности от абсолютного ноля. Они используют простые пароли, они оставляют залогиненные сессии в паблик местах, они не лочат комп на рабочем месте и тд. и тп.
Так вот речь о том, что получив доступ к аккаунту такого нерадивого товарища можно через xss получить доступ и к админскому аккаунту.
что значит "не прослеживается"?! вы выше по комментариям посмотрите — уже, вон, сколько "статистики" привели. все сразу обнаружили внезапные "то-то я думал" и "да-да я тоже заметил"
довольно глупо выкладывать в паблик со словами "вот, посмотрите, какой я молодец" и надеяться, что все будут только смотреть, не трогать и хвалить "какой ты молодец". Особенно с таким абмициозно-детским посылом:
При написании своей CMS мне хотелось собрать из них все самое лучшее и соединить в одну.
Приличная такая погрешность должна быть как раз за счёт степени того, насколько "плотно прижимаясь к поверхности, и фиксируюсь, группирую тело, чтобы не болталось". Всё-таки человек — не абсолютно жесткое тело и часть импульсов уходит на разминание жиромяса.
Сборник «happy debugging!» Особо умиляют полезностью методы TryDo/Catch, If/IfNot — просто гимн абсурду.
Прекрасный пример, когда из одного метода With было как-то стыдно делать библиотеку и потому туда насовали абсурдных «подобных» методов просто чтоб было. При дебаге такого когда вспомнишь весь словарь обсценной лексики в отношении автора.
Да, Await()-метод прекрасен своей бесполезностью. из той же серии встречал:
public static bool IsNullOrEmpty(this string value)
{
return string.IsNullOrEmpty(value);
}
Неоднократно встречал такой идиотизм.
Вообще экстеншн-методы прям-таки манят слабых духом впасть в маразм расширенияклепания на каждый чих. С матом и подручными предметами приходится отстаивать system.object и классы фреймворка, потому что если не уследить, то там начинается такая дурь…
См. вторую картинку — там "… compared to Previous Generation… @ 4.5W". Сдаётся мне, что тут собака и зарыта- весь «прирост» спрятан за урезание старого проца до tdp 4.5W ;)
Но, конечно же, всё-таки хочется бенчей, а не гадать по пресс-релизам.
Эпический манускрипт по помирающей технологии.
В своё время (когда больше ничего не было и в среде разработок все, как полоумные носились с XML, утверджая, что "за ним будущее и вообще скоро всё будет в XML!") это была хорошая попытка унять разношёрстные реализации и сделать некий стандарт.
Вот только проблема закралась в том, что вы не найдёте двух библиотек на разных платформах, которые его одинаково реализуют. Грабли и костыли будут в любой паре. А если плясать в рамках одной платформы, то зачем вся эта убер-избыточность и переусложнённость?
В общем был такой, претендовал на универсальность, но пока к ней шёл — поезд уехал далеко вперёд. Сейчас разве что в каких-нибудь монструозных корпоративных проектах, которые никто не будет переписывать, и где нужна мифическая "интероперабельность", которую там никто на самом деле никогда не видел.
Каждый первый кладывает в "простой и понятный" своё видение мира. И именно поэтому существует документация. И именно поэтому существуют те, которые "берут, пользуются, удивляются" и те, кто читает документацию.
Заказывая инстанс пользователь может подумать
Если пользователь не в состоянии прочитать документацию по сервису, который он собирается оплачивать — то да, лучше ему впарить что-то другое.
>A какой смысл в их тестировании? При каждой перезагрузке данные с них пропадают.
Смысл этих дисков в том, что они используются под то, что нужно. на них не стоит система, на них хранятся данные. если машина выключается, то локальные данные с неё уже не нужны. Всё остальное время это и есть тот самой быстрый дисковый массив для работы. Не бывает операций на хранение (архивацию) данных, шибко чуствительных к IO. Это всегда кэш, tmp и прочее. Слить потом в персистентное хранилище не проблема. Так что тест системного (сетевого) диска это странная чушь.
Сервер, на котором уничтожаются данные при перезагрузке подходит для чего угодно, что не хранит данные, а должно их быстро принять/обработать/отдать. Та же cassandra на него идеально ложится. Тот же elasticsearch. Да любой кластерный софт с репликациями и шардингом будет прекрасно жить, не теряя ничего и автоматически масштабируясь при изменении количества машин.
Я понимаю, что вы так мощно рады, что запилили такой прекрасный быстрый SSD-кэш, что пытаетесь теперь полить всех кругом фекалями, но всё же стОит немножко отдавать себе отчёт, что бывают разные области применения. И бывают разные требования. По мне так схема сетевой+эфемерный диск в AWS/Azure логична и абсолютно оправдана. Локальный SSD это прекрасный способ получить гарантированную производительность, не подверженную влиянию сети и прочей инфраструктуры. Никто не мешает объединять эти SSD на EC2-машинах в raid и получать космические скорости.
Пара нюансов про «скорость SSD в облаках»:
1. В AWS они тестировали EBS on SSD. Т.е. сетевое хранилище, которое ограничено 24 iops (3000 burst mode на 30 минут). В качестве root на всех машинах в EC2 всегда используется EBS. Это единственное постоянное хранилище. Потому там и получили магические 3000 iops на скриншотах.
Локальные же SSD-диски, которые на M3 указаны в качестве SSD Storage, надо монтировать отдельно при создании — они доступны как Instance sotage и да — они эфемерны. Т.е. обнуляются при рестарте инстанса. В этом они полностью идентичны Temp-дискам в Azure.
2. В Azure точно также диск C всегда является сетевым. Локальный SSD-диск, доступный на некоторых типах инстансов, только D и он тоже эфемерен, о чём и гласит текстовый документ, про который вы так громко заявили "что использование SSD диска в Azure – на свой страх и риск" и "Azure предупреждает о том, что использование SSD диска небезопасно и не рекомендуется для постоянного хранения данных". Божтымой. Читайте описание сервиса. Этот текстовый документ всего-лишь напоминает тем, кто не читает описание сервиса, что D: — это Temporary drive, что он обнуляется при рестартах.
3. Для расчёта цены взят регион «Ирландия».
… как самый дорогой в AWS, ага. Был бы новый Франкфурт дороже — сравнивали бы с ним, оно понятно. А вот если с Орегоном посравнивать.
Да ещё и не с On demand, а с Reserved, например.
Я, конечно, понимаю, что пиар подразумевает истеричность и вбросы на вентилятор… Но здесь я даже затрудняюсь понять — это наивная безграмотность или подтасовка такая нелепая?
А по поводу «зачем платить» — здесь больше играет скорость разворачивания. В AWS/Azure вы один раз настраиваете машину и в любой момент за пару минут поднимаете хоть с десяток _идентичных_ машин. Со всеми точно такими же настройками (потому что системный диск сетевой и персистентный — так что его можно в любой момент клонировать. А все эти SSD/Temporary диски — они под локальные данные.
Или же просто имеющуюся машину переключаете на другой тип инстанса — быстро добавляя ей ядер/памяти.
Т.е., допустим, настроив один раз ту же cassandra так, чтоб хранила данные на локальном (эфемерном) диске, можно в любой момент поднять ещё десяток машин — они сами войдут в кластер, сами всосут в себя данные на быстрые диски и вы сразу получите нужный прирост. Потом просто по-одной выводите машины и они сами свои данные сливают на остальных.
И всё это можно делать скриптами через AWS/Azure API без ручной работы.
А теперь представьте себе, что призойдёт, если по случае праздника/акции/положения звёзд ваш сервер в hetzner не справляется с нагрузкой и надо БЫСТРО развернуть второй такойже и ещё и балансировщик сверху поставить…
И вдогонку: я думаю, этому персонажу уже итак довольно доходчиво объяснили степень его заблуждений относительно подхода к разработке.
Я рад, если на проекте есть вменяемые люди, которые хотят и пытаются что-то сделать. Но реальность такова, что в коде — одна сплошная большая ягодичная мышца. Обижаться тут не на что- это просто факт.
А вот автору добавить в статью пару слов про дремучую опенсурсность, я думаю, не сложно.
По сути, на проект никто не наезжал. Да, автор статьи мог бы и уделить хотя бы пару слов оговорке, что это доисторический проект с жутко разнородной толпой абсолютно никак не организованных контрибуторов — тогда хотя бы выглядело не так ультимативно.
Однако, здесь уже (если пойти от моего комментария вверх и посмотреть, кто же начал эту ветку) речь идёт не о проекте в целом, а о позиции одного конкретнов взятого персонажа, который первым заговорил от лица разработчиков проекта, попутро неся чушь и поливая фекалиями всех вокруг.
Нормальной реакцией было бы "о! руки не доходили, а тут уже за нас сделали. спасибо, надо глянуть".
Вместо этого — попытки огрызаться из разряда "самдурак", вялые оправдания "вы бы видели, что там РАНЬШЕ было!" и тому подобное.
Все ж, вроде, взрослые люди. Понимают, что в опенсурсе может быть что угодно. Тем более, если этому опенсурсу столько лет и он столько раз испытывал боль перерождения. Чо оправдываться-то? Поблагодарить, взять на заметку и пользоваться, пока другие за вас работу делают. Удобно ведь, нет?
А позиция "у всех работает" просто наивна. Довольно толстый проект без единого юнит-теста, живущий на соплях вида "уф, собралось!", даже без вменяемой обратной связи… Когда сообразительному пользователю надоедает, что миранда падает на каждый чих — он выясняет, какой плагин виноват и отключает/обновляет/заменяет его. Если же пользователь ленив или недостаточно технически подкован — он просто сносит миранду к чертям и пользуется чем-нибудь ещё. В обоих случаях вы НИЧЕГО об этом не узнаёте и дальше радостно празднуете "стабильные релизы". И только самые дотошные продираются через дебри «поддержки» на форуме, чтоб оставить багрепорт и заметить, что предыдущее сообщение было пару-тройку лет назад. Т.е. этот плагин вообще никто давно не тащит на себе.
А кичиться багодельней — вообще детсад. "Нашла, дура, чем гордиться".
Т.е. вот прям так взять и при всём честном народе сказать "мы пишем одноразовый код, который никогда не будем рефакторить". Будем сидеть и бояться дышать на легаси код, потому что там живут огнедышащие тараканы. А когда достигнете критической массы костылей и заплаток — так, что любой чих в коде будет вызывать непредсказуемые (причем зачастую отложенные) последстия в совершенно не связанных с ним (казалось бы) областях, то… А, я знаю! Сделаете ещё один форк со словами "там всё плохо, а вот теперь-то мы всё сделаем как надо!", да?
Так вот, он пытается донести мысль, что обычно CMS пользуются не только админы. Зачастую доступ даётся всяким контент-менеджерам, которые по уровню компьютерной грамотности и элементарных навыков сетевой безопасности находятся где-то в пределах погрешности от абсолютного ноля. Они используют простые пароли, они оставляют залогиненные сессии в паблик местах, они не лочат комп на рабочем месте и тд. и тп.
Так вот речь о том, что получив доступ к аккаунту такого нерадивого товарища можно через xss получить доступ и к админскому аккаунту.
спасибо тому, кто порадовал с утра 8)
простите, вырвалось.
Сборник «happy debugging!» Особо умиляют полезностью методы TryDo/Catch, If/IfNot — просто гимн абсурду.
Прекрасный пример, когда из одного метода With было как-то стыдно делать библиотеку и потому туда насовали абсурдных «подобных» методов просто чтоб было. При дебаге такого когда вспомнишь весь словарь обсценной лексики в отношении автора.
Неоднократно встречал такой идиотизм.
Вообще экстеншн-методы прям-таки манят слабых духом впасть в маразм расширенияклепания на каждый чих. С матом и подручными предметами приходится отстаивать system.object и классы фреймворка, потому что если не уследить, то там начинается такая дурь…
Но, конечно же, всё-таки хочется бенчей, а не гадать по пресс-релизам.
В своё время (когда больше ничего не было и в среде разработок все, как полоумные носились с XML, утверджая, что "за ним будущее и вообще скоро всё будет в XML!") это была хорошая попытка унять разношёрстные реализации и сделать некий стандарт.
Вот только проблема закралась в том, что вы не найдёте двух библиотек на разных платформах, которые его одинаково реализуют. Грабли и костыли будут в любой паре. А если плясать в рамках одной платформы, то зачем вся эта убер-избыточность и переусложнённость?
В общем был такой, претендовал на универсальность, но пока к ней шёл — поезд уехал далеко вперёд. Сейчас разве что в каких-нибудь монструозных корпоративных проектах, которые никто не будет переписывать, и где нужна мифическая "интероперабельность", которую там никто на самом деле никогда не видел.
Каждый первый кладывает в "простой и понятный" своё видение мира. И именно поэтому существует документация. И именно поэтому существуют те, которые "берут, пользуются, удивляются" и те, кто читает документацию.
Если пользователь не в состоянии прочитать документацию по сервису, который он собирается оплачивать — то да, лучше ему впарить что-то другое.
Смысл этих дисков в том, что они используются под то, что нужно. на них не стоит система, на них хранятся данные. если машина выключается, то локальные данные с неё уже не нужны. Всё остальное время это и есть тот самой быстрый дисковый массив для работы. Не бывает операций на хранение (архивацию) данных, шибко чуствительных к IO. Это всегда кэш, tmp и прочее. Слить потом в персистентное хранилище не проблема. Так что тест системного (сетевого) диска это странная чушь.
Сервер, на котором уничтожаются данные при перезагрузке подходит для чего угодно, что не хранит данные, а должно их быстро принять/обработать/отдать. Та же cassandra на него идеально ложится. Тот же elasticsearch. Да любой кластерный софт с репликациями и шардингом будет прекрасно жить, не теряя ничего и автоматически масштабируясь при изменении количества машин.
Я понимаю, что вы так мощно рады, что запилили такой прекрасный быстрый SSD-кэш, что пытаетесь теперь полить всех кругом фекалями, но всё же стОит немножко отдавать себе отчёт, что бывают разные области применения. И бывают разные требования. По мне так схема сетевой+эфемерный диск в AWS/Azure логична и абсолютно оправдана. Локальный SSD это прекрасный способ получить гарантированную производительность, не подверженную влиянию сети и прочей инфраструктуры. Никто не мешает объединять эти SSD на EC2-машинах в raid и получать космические скорости.
1. В AWS они тестировали EBS on SSD. Т.е. сетевое хранилище, которое ограничено 24 iops (3000 burst mode на 30 минут). В качестве root на всех машинах в EC2 всегда используется EBS. Это единственное постоянное хранилище. Потому там и получили магические 3000 iops на скриншотах.
Локальные же SSD-диски, которые на M3 указаны в качестве SSD Storage, надо монтировать отдельно при создании — они доступны как Instance sotage и да — они эфемерны. Т.е. обнуляются при рестарте инстанса. В этом они полностью идентичны Temp-дискам в Azure.
2. В Azure точно также диск C всегда является сетевым. Локальный SSD-диск, доступный на некоторых типах инстансов, только D и он тоже эфемерен, о чём и гласит текстовый документ, про который вы так громко заявили "что использование SSD диска в Azure – на свой страх и риск" и "Azure предупреждает о том, что использование SSD диска небезопасно и не рекомендуется для постоянного хранения данных". Божтымой. Читайте описание сервиса. Этот текстовый документ всего-лишь напоминает тем, кто не читает описание сервиса, что D: — это Temporary drive, что он обнуляется при рестартах.
3. Для расчёта цены взят регион «Ирландия».
… как самый дорогой в AWS, ага. Был бы новый Франкфурт дороже — сравнивали бы с ним, оно понятно. А вот если с Орегоном посравнивать.
Да ещё и не с On demand, а с Reserved, например.
Я, конечно, понимаю, что пиар подразумевает истеричность и вбросы на вентилятор… Но здесь я даже затрудняюсь понять — это наивная безграмотность или подтасовка такая нелепая?
А по поводу «зачем платить» — здесь больше играет скорость разворачивания. В AWS/Azure вы один раз настраиваете машину и в любой момент за пару минут поднимаете хоть с десяток _идентичных_ машин. Со всеми точно такими же настройками (потому что системный диск сетевой и персистентный — так что его можно в любой момент клонировать. А все эти SSD/Temporary диски — они под локальные данные.
Или же просто имеющуюся машину переключаете на другой тип инстанса — быстро добавляя ей ядер/памяти.
Т.е., допустим, настроив один раз ту же cassandra так, чтоб хранила данные на локальном (эфемерном) диске, можно в любой момент поднять ещё десяток машин — они сами войдут в кластер, сами всосут в себя данные на быстрые диски и вы сразу получите нужный прирост. Потом просто по-одной выводите машины и они сами свои данные сливают на остальных.
И всё это можно делать скриптами через AWS/Azure API без ручной работы.
А теперь представьте себе, что призойдёт, если по случае праздника/акции/положения звёзд ваш сервер в hetzner не справляется с нагрузкой и надо БЫСТРО развернуть второй такойже и ещё и балансировщик сверху поставить…
Я рад, если на проекте есть вменяемые люди, которые хотят и пытаются что-то сделать. Но реальность такова, что в коде — одна сплошная большая ягодичная мышца. Обижаться тут не на что- это просто факт.
А вот автору добавить в статью пару слов про дремучую опенсурсность, я думаю, не сложно.
Однако, здесь уже (если пойти от моего комментария вверх и посмотреть, кто же начал эту ветку) речь идёт не о проекте в целом, а о позиции одного конкретнов взятого персонажа, который первым заговорил от лица разработчиков проекта, попутро неся чушь и поливая фекалиями всех вокруг.
Нормальной реакцией было бы "о! руки не доходили, а тут уже за нас сделали. спасибо, надо глянуть".
Вместо этого — попытки огрызаться из разряда "самдурак", вялые оправдания "вы бы видели, что там РАНЬШЕ было!" и тому подобное.
Все ж, вроде, взрослые люди. Понимают, что в опенсурсе может быть что угодно. Тем более, если этому опенсурсу столько лет и он столько раз испытывал боль перерождения. Чо оправдываться-то? Поблагодарить, взять на заметку и пользоваться, пока другие за вас работу делают. Удобно ведь, нет?
А позиция "у всех работает" просто наивна. Довольно толстый проект без единого юнит-теста, живущий на соплях вида "уф, собралось!", даже без вменяемой обратной связи… Когда сообразительному пользователю надоедает, что миранда падает на каждый чих — он выясняет, какой плагин виноват и отключает/обновляет/заменяет его. Если же пользователь ленив или недостаточно технически подкован — он просто сносит миранду к чертям и пользуется чем-нибудь ещё. В обоих случаях вы НИЧЕГО об этом не узнаёте и дальше радостно празднуете "стабильные релизы". И только самые дотошные продираются через дебри «поддержки» на форуме, чтоб оставить багрепорт и заметить, что предыдущее сообщение было пару-тройку лет назад. Т.е. этот плагин вообще никто давно не тащит на себе.
А кичиться багодельней — вообще детсад. "Нашла, дура, чем гордиться".
Т.е. вот прям так взять и при всём честном народе сказать "мы пишем одноразовый код, который никогда не будем рефакторить". Будем сидеть и бояться дышать на легаси код, потому что там живут огнедышащие тараканы. А когда достигнете критической массы костылей и заплаток — так, что любой чих в коде будет вызывать непредсказуемые (причем зачастую отложенные) последстия в совершенно не связанных с ним (казалось бы) областях, то… А, я знаю! Сделаете ещё один форк со словами "там всё плохо, а вот теперь-то мы всё сделаем как надо!", да?