Ну вот, вопрос про ответственность кому-то не понравился, поставили минус, но без комментария)
А ведь на самом деле интересно, как это и почему для критически важных систем были выбраны полностью закрытые решения от Microsoft, которые фактически привязывают все к одному вендору из другой страны. Да, я знаю про частичное раскрытие кода Microsoft, но это только частичное.
При этом такой выбор не дает возможности ни полного анализа безопасности на уровне исследования кода от Microsoft, ни возможности быстрого перехода к другому вендору без переписывания значительной части ПО.
А как насчет ответственности за выбор для критичных приложений таких закрытых систем, которые даже теоретически невозможно исследовать на предмет наличия всякого рода закладок и вредоносного кода, так как нет полных исходников?
Что если поддержка закрытых систем или даже сама возможность их использования может вдруг исчезнуть по тем или иным причинам?
Полагаю, как раз поэтому сейчас и переводят критические системы на открытый софт типа PostgreSQL. И даже обычные компы, где раньше стояла ОС Windows, переводят на локализовнные версии Linux. И конечно, для локализованных версий ОС и БД с открытыми текстами имеется поддержка со стороны тех или иных компаний.
Вообще всякие там социальные сети и прочие подобные системы не делают на решениях Microsoft. Там как раз открытые решения применяются, просто созданные для безумных объемов данных с шардированием, всякие там балансировщики нагрузок, масштабирование на сотни и тысячи серверов, куберы и т.п.
Т.е. на вырост можно выбрать и открытые решения. Но в корпоративном секторе, конечно, свои особенности.
Тут даже дело не в том, чтобы не пользоваться передовыми технологиями, а в том, чтобы уже на этапе до создания системы сделать такой выбор, чтобы и не платить лишнего, и чтобы было куда мигрировать, если такое потребуется.
Для тех кто уже на MS SQL все понятно - если нужна миграция по тем или иным причинам, можно начинать уже прямо сейчас, так как это будет трудно и дорого.
А кто выбирает БМВ для перевозки дров вместо трактора потому что БМВ более передовой по технологиям - ну что ж, если есть лишние деньги почему бы и нет. Кстати эта транспортная компания, про которую я писал выше, выбрала БМВ не просто так, а для рекламы. Так что у каждого выбора есть свои мотивы!
Да, но пересесть, скажем, с MySQL на MariaDB или на Percona Database, и даже на PostgreSQL все же намного легче, чем с MS SQL на что-то еще. Сам пробовал)
Своими не надо, хотя мне иногда приходилось вносить небольшие изменения в то, чем пользуюсь. Это плохо, так как при обновлении версии продукта такие изменения придется вносить снова.
Если есть исходники и проект перспективный, может найтись компания или разработчики, которые возьмутся. Вот тот же MySQL, например, и Percona, разработчики MariaDB. Еще пример - PostgreSQL.
А вот если проект проприетарный и исходников нет, то никто (кроме владельца продукта) не возьмется его развивать или делать на его основе собственный. И своими силами не получится. Если, конечно, не купить исходники у разработчика.
Что касается прекращения поддержки открытого проекта сообществом, то такой риск конечно есть. Но тут уж приходится выбирать такой проект, поддержка которого не должна прекратиться в обозримом будущем.
Если сообщество большое и уже имеются форки, то вероятность полной потери проекта меньше. Если проект создал один человек и он один его сопровождает, то я бы не стал использовать такой проект в критичных случаях. По крайней мере, если мои программисты не смогут сопровождать его самостоятельно.
Само же решение не исчезнет в ИС, остаётся локально до бесконечности.
Вот как раз упомяну еще раз почивший MS VBX Control, MS Windows XP да мало ли еще чего, бывает все! Оставаться на ПО, не получающее обновление, очень большой риск.
Если вы уже на проприетарном решении или на MS то да, переезд может обойтись очень дорого, хотя причины переезда могут быть такими, что никаких денег не жалко. А если только решаете на чем делать, то есть выбор!
Да, идеала нет - нужно смотреть что подходит для конкретной области. У открытого решения есть такое преимущество что исходники доступны, и кто-то может форкнуть свой проект, если с исходным что-то случится. Да вот хотя бы MySQL и MariaDB, решения Percona.
А вот если накроется проприетарный проект, то его если никто не купит, то придется искать замену. И да, например, дрова на БМВ возить не обязательно, хотя я знаю одну транспортную компанию, которая доставляла товары как раз на БМВ)
Поэтому я не могу понять о каких российских Интернет-магазинах в начале 90-х идет речь.
Про свои, конечно. Не считаю настоящим примитивный магазин для продажи авторского CD-ROM, где для покупки каждого диска нужно было заполнять отдельную форму, а заказ приходил в Диалог-МИФИ на электронную почту)
Настоящий первый интернет-магазин я делал для издательства "Русская Редакция" в самом конце 90-х, когда писал для него книгу "Создание Web-приложений: Практическое руководство" (а выбором платформы я озадачился в начале-середине 90-х). И этот магазин как раз был сделан на платформе MS Windows. А потом я перешел на FreeBSD-MySQL-Perl и сделал там магазины матрасов, одежды и еще несколько других, но это уже отдельная история.
То есть отказ от 16-битных VBX Controls в пользу 32-битных OCX/COM/ActiveX Вы считаете ненормальным шагом Microsoft?
Дело в том что Microsoft не предложил никакого решения для обратной совместимости. Поэтому труд, затраченный на создание VBX Controls, пошел в мусорную корзину.
Из этого я извлек урок - можно потратить очень много времени и сил на изучение и внедрение какой-либо проприетарной технологии и остаться у разбитого корыта, если разработчик этой технологии откажется от ее использования или развития, как это произошло с VBX Controls (с Open Source такое, конечно, тоже может быть).
На изучение OCX/COM/ActiveX в свое время я потратил много сил (штука не особо простая), но потом понял, что если это все будет меняться каждый год, то так и буду вечным учеником. А на разработку своих проектов времени и сил уже не останется.
Ну а потом и цены на платформу MS резко поднялись и для моих масштабов стало еще и нерентабельно. Впрочем, не думаю что очень крупные и посещаемые сервисы типа соц. сетей сейчас делают не на Линуксе.
Реклама чего? Linux? Вообще писал сам, история моя, реальная. Очень жаль что не уделял в свое время достаточно внимания платформе Linux, хотя и пробовал некоторые дистрибутивы.
В начале 90-х выбирал платформу для своего первого интернет-магазина. К этому моменту довольно плотно сидел на Microsoft и понял, что это приводит к очень большому расходу времени и денег.
Microsoft непрерывно выкатывал обновления API, каждый год нужно было покупать новый MSDN, MS Visual Studio и изучать все заново. При этих обновлениях каких-то особых прорывов в функциональности не ощущалось, и часть API всегда была не документирована. А после известного "No more VBX Controls" как-то совсем расхотелось и дальше сидеть на игле Microsoft)
Очень рад что избавился от Vendor lock-in, перейдя на платформу Linux!
Насколько я знаю, Microsoft SQL Server стоит очень дорого. Интересно было бы узнать, какие ключевые преимущества есть у него по сравнению с другими распространенными серверами баз данных, в том числе доступными бесплатно?
В общем случае да. Надо еще смотреть какой усилитель, не будет ли он перегружен сигналом от NanoVNA. А то может быть придется ставить два аттенюатора - перед усилителем и после него (10–20 дБ). Убедитесь, что с выхода усилителя на вход NanoVNA не будет подано постоянное напряжение.
NanoVNA измеряет параметры относительно земли - нужен замкнутый контур. Если подключить только центральную жилу, прибор не сможет корректно провести измерения.
Тут нужно обеспечить связь оплетки с противовесом - например, металлической поверхностью, корпусом прибора или отдельным проводом. То есть потребуется имитация земли.
Например, можно прикрутить к разъёму несколько проводов длиной четверть волны, разведённых веером или положить антенну на металлическую пластину, соединённую с землёй NanoVNA.
Вот именно что основатель и директор SAAS-сервиса интернет-магазинов. Поэтому у меня есть опыт миграции с Битрикса и я делюсь этим опытом. При миграции единственное что нам нужно, не считая сохранения URL проиндексированных страниц, - это перенести данные. Поэтому пришлось разбираться со структурой хранения этих данных и с запросами.
Исследуя журнал запросов к базе данных при выполнении простейших операций, типа показа страницы клиентов, я обнаружил огромное количество запросов с JOIN типа таких:
SELECT BE.ID as ID,BE.IBLOCK_ID as IBLOCK_ID,BE.IBLOCK_SECTION_ID as IBLOCK_SECTION_ID,BE.NAME as NAME,IF(EXTRACT(HOUR_SECOND FROM BE.ACTIVE_FROM)>0, DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y %H:%i:%s'), DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y')) as ACTIVE_FROM,B.DETAIL_PAGE_URL as DETAIL_PAGE_URL,BE.DETAIL_TEXT as DETAIL_TEXT,BE.DETAIL_TEXT_TYPE as DETAIL_TEXT_TYPE,BE.PREVIEW_TEXT as PREVIEW_TEXT,BE.PREVIEW_TEXT_TYPE as PREVIEW_TEXT_TYPE,BE.PREVIEW_PICTURE as PREVIEW_PICTURE,L.DIR as LANG_DIR,BE.SORT as SORT,BE.CODE as CODE,BE.XML_ID as EXTERNAL_ID,B.IBLOCK_TYPE_ID as IBLOCK_TYPE_ID,B.CODE as IBLOCK_CODE,B.XML_ID as IBLOCK_EXTERNAL_ID,B.LID as LID FROM b_iblock B INNER JOIN b_lang L ON B.LID=L.LID INNER JOIN b_iblock_element BE ON BE.IBLOCK_ID = B.ID INNER JOIN b_iblock_property FP0 ON FP0.IBLOCK_ID = B.ID AND FP0.CODE='ORDER' INNER JOIN b_iblock_element_property FPV0 ON FPV0.IBLOCK_PROPERTY_ID = FP0.ID AND FPV0.IBLOCK_ELEMENT_ID = BE.ID WHERE 1=1 AND ( ((((BE.IBLOCK_ID = '16')))) AND (EXISTS ( SELECT IBLOCK_ID FROM b_iblock_site WHERE IBLOCK_ID = B.ID AND (((SITE_ID='s1'))) )) AND ((((BE.ACTIVE='Y')))) AND (((BE.ACTIVE_TO >= now() OR BE.ACTIVE_TO IS NULL) AND (BE.ACTIVE_FROM <= now() OR BE.ACTIVE_FROM IS NULL))) AND ((((FPV0.VALUE_NUM = '0')))) ) AND (((BE.WF_STATUS_ID=1 AND BE.WF_PARENT_ELEMENT_ID IS NULL))) ORDER BY BE.ACTIVE_FROM desc ,BE.SORT asc ,BE.ID desc LIMIT 0, 200
И это я еще использование индексов у полей таблиц не проверял, потому что при миграции это не важно.
Перевел один из магазинов с Битрикса на свою платформу - продажи выросли на 30% сразу после переключения из-за резко возросшей скорости загрузки страниц и ускорения процедуры оформления заказов.
Сейчас перевожу еще одну систему, так там да, безумное количество запросов SQL при отображении простой таблицы клиентов из 50-60 строк. Время загрузки страниц полностью не устраивает заказчика, что и не удивительно.
Битрикс создавался очень давно как универсальный инструмент для разработки сайтов. Не удивительно, что попытки применения его для интернет-магазинов не приводят ни к чему хорошему. По моему мнению, универсальные инструменты, разработанные для всего подряд, плохо справляются с решением всех задач, для которых они создавались. Ведь там нет специализации и учета особенностей каждой области.
Ну вот, вопрос про ответственность кому-то не понравился, поставили минус, но без комментария)
А ведь на самом деле интересно, как это и почему для критически важных систем были выбраны полностью закрытые решения от Microsoft, которые фактически привязывают все к одному вендору из другой страны. Да, я знаю про частичное раскрытие кода Microsoft, но это только частичное.
При этом такой выбор не дает возможности ни полного анализа безопасности на уровне исследования кода от Microsoft, ни возможности быстрого перехода к другому вендору без переписывания значительной части ПО.
А как насчет ответственности за выбор для критичных приложений таких закрытых систем, которые даже теоретически невозможно исследовать на предмет наличия всякого рода закладок и вредоносного кода, так как нет полных исходников?
Что если поддержка закрытых систем или даже сама возможность их использования может вдруг исчезнуть по тем или иным причинам?
Полагаю, как раз поэтому сейчас и переводят критические системы на открытый софт типа PostgreSQL. И даже обычные компы, где раньше стояла ОС Windows, переводят на локализовнные версии Linux. И конечно, для локализованных версий ОС и БД с открытыми текстами имеется поддержка со стороны тех или иных компаний.
Вообще всякие там социальные сети и прочие подобные системы не делают на решениях Microsoft. Там как раз открытые решения применяются, просто созданные для безумных объемов данных с шардированием, всякие там балансировщики нагрузок, масштабирование на сотни и тысячи серверов, куберы и т.п.
Т.е. на вырост можно выбрать и открытые решения. Но в корпоративном секторе, конечно, свои особенности.
Тут даже дело не в том, чтобы не пользоваться передовыми технологиями, а в том, чтобы уже на этапе до создания системы сделать такой выбор, чтобы и не платить лишнего, и чтобы было куда мигрировать, если такое потребуется.
Для тех кто уже на MS SQL все понятно - если нужна миграция по тем или иным причинам, можно начинать уже прямо сейчас, так как это будет трудно и дорого.
А кто выбирает БМВ для перевозки дров вместо трактора потому что БМВ более передовой по технологиям - ну что ж, если есть лишние деньги почему бы и нет. Кстати эта транспортная компания, про которую я писал выше, выбрала БМВ не просто так, а для рекламы. Так что у каждого выбора есть свои мотивы!
Да, но пересесть, скажем, с MySQL на MariaDB или на Percona Database, и даже на PostgreSQL все же намного легче, чем с MS SQL на что-то еще. Сам пробовал)
Своими не надо, хотя мне иногда приходилось вносить небольшие изменения в то, чем пользуюсь. Это плохо, так как при обновлении версии продукта такие изменения придется вносить снова.
Если есть исходники и проект перспективный, может найтись компания или разработчики, которые возьмутся. Вот тот же MySQL, например, и Percona, разработчики MariaDB. Еще пример - PostgreSQL.
А вот если проект проприетарный и исходников нет, то никто (кроме владельца продукта) не возьмется его развивать или делать на его основе собственный. И своими силами не получится. Если, конечно, не купить исходники у разработчика.
Что касается прекращения поддержки открытого проекта сообществом, то такой риск конечно есть. Но тут уж приходится выбирать такой проект, поддержка которого не должна прекратиться в обозримом будущем.
Если сообщество большое и уже имеются форки, то вероятность полной потери проекта меньше. Если проект создал один человек и он один его сопровождает, то я бы не стал использовать такой проект в критичных случаях. По крайней мере, если мои программисты не смогут сопровождать его самостоятельно.
Вот как раз упомяну еще раз почивший MS VBX Control, MS Windows XP да мало ли еще чего, бывает все! Оставаться на ПО, не получающее обновление, очень большой риск.
Если вы уже на проприетарном решении или на MS то да, переезд может обойтись очень дорого, хотя причины переезда могут быть такими, что никаких денег не жалко. А если только решаете на чем делать, то есть выбор!
Да, идеала нет - нужно смотреть что подходит для конкретной области.
У открытого решения есть такое преимущество что исходники доступны, и кто-то может форкнуть свой проект, если с исходным что-то случится. Да вот хотя бы MySQL и MariaDB, решения Percona.
А вот если накроется проприетарный проект, то его если никто не купит, то придется искать замену. И да, например, дрова на БМВ возить не обязательно, хотя я знаю одну транспортную компанию, которая доставляла товары как раз на БМВ)
Про свои, конечно. Не считаю настоящим примитивный магазин для продажи авторского CD-ROM, где для покупки каждого диска нужно было заполнять отдельную форму, а заказ приходил в Диалог-МИФИ на электронную почту)
Настоящий первый интернет-магазин я делал для издательства "Русская Редакция" в самом конце 90-х, когда писал для него книгу "Создание Web-приложений: Практическое руководство" (а выбором платформы я озадачился в начале-середине 90-х). И этот магазин как раз был сделан на платформе MS Windows. А потом я перешел на FreeBSD-MySQL-Perl и сделал там магазины матрасов, одежды и еще несколько других, но это уже отдельная история.
Дело в том что Microsoft не предложил никакого решения для обратной совместимости. Поэтому труд, затраченный на создание VBX Controls, пошел в мусорную корзину.
Из этого я извлек урок - можно потратить очень много времени и сил на изучение и внедрение какой-либо проприетарной технологии и остаться у разбитого корыта, если разработчик этой технологии откажется от ее использования или развития, как это произошло с VBX Controls (с Open Source такое, конечно, тоже может быть).
На изучение OCX/COM/ActiveX в свое время я потратил много сил (штука не особо простая), но потом понял, что если это все будет меняться каждый год, то так и буду вечным учеником. А на разработку своих проектов времени и сил уже не останется.
Ну а потом и цены на платформу MS резко поднялись и для моих масштабов стало еще и нерентабельно. Впрочем, не думаю что очень крупные и посещаемые сервисы типа соц. сетей сейчас делают не на Линуксе.
Реклама чего? Linux?
Вообще писал сам, история моя, реальная. Очень жаль что не уделял в свое время достаточно внимания платформе Linux, хотя и пробовал некоторые дистрибутивы.
В начале 90-х выбирал платформу для своего первого интернет-магазина. К этому моменту довольно плотно сидел на Microsoft и понял, что это приводит к очень большому расходу времени и денег.
Microsoft непрерывно выкатывал обновления API, каждый год нужно было покупать новый MSDN, MS Visual Studio и изучать все заново. При этих обновлениях каких-то особых прорывов в функциональности не ощущалось, и часть API всегда была не документирована.
А после известного "No more VBX Controls" как-то совсем расхотелось и дальше сидеть на игле Microsoft)
Очень рад что избавился от Vendor lock-in, перейдя на платформу Linux!
Вот да!
Насколько я знаю, Microsoft SQL Server стоит очень дорого. Интересно было бы узнать, какие ключевые преимущества есть у него по сравнению с другими распространенными серверами баз данных, в том числе доступными бесплатно?
Благодарю за уточнение
Сам не пробовал, но возможно, будет полезен раздел "6 - Appendix II – USB data interface" описания "User Manual - NanoVNA V2".
В общем случае да. Надо еще смотреть какой усилитель, не будет ли он перегружен сигналом от NanoVNA. А то может быть придется ставить два аттенюатора - перед усилителем и после него (10–20 дБ).
Убедитесь, что с выхода усилителя на вход NanoVNA не будет подано постоянное напряжение.
NanoVNA измеряет параметры относительно земли - нужен замкнутый контур. Если подключить только центральную жилу, прибор не сможет корректно провести измерения.
Тут нужно обеспечить связь оплетки с противовесом - например, металлической поверхностью, корпусом прибора или отдельным проводом. То есть потребуется имитация земли.
Например, можно прикрутить к разъёму несколько проводов длиной четверть волны, разведённых веером или положить антенну на металлическую пластину, соединённую с землёй NanoVNA.
Интересно, сколько они вложили в создание сайта плюс к лицензии и на что это пошло. Полагаю, кастомными доработками можно сделать все что угодно.
Вот именно что основатель и директор SAAS-сервиса интернет-магазинов. Поэтому у меня есть опыт миграции с Битрикса и я делюсь этим опытом. При миграции единственное что нам нужно, не считая сохранения URL проиндексированных страниц, - это перенести данные. Поэтому пришлось разбираться со структурой хранения этих данных и с запросами.
Исследуя журнал запросов к базе данных при выполнении простейших операций, типа показа страницы клиентов, я обнаружил огромное количество запросов с JOIN типа таких:
SELECT BE.ID as ID,BE.IBLOCK_ID as IBLOCK_ID,BE.IBLOCK_SECTION_ID as IBLOCK_SECTION_ID,BE.NAME as NAME,IF(EXTRACT(HOUR_SECOND FROM BE.ACTIVE_FROM)>0, DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y %H:%i:%s'), DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y')) as ACTIVE_FROM,B.DETAIL_PAGE_URL as DETAIL_PAGE_URL,BE.DETAIL_TEXT as DETAIL_TEXT,BE.DETAIL_TEXT_TYPE as DETAIL_TEXT_TYPE,BE.PREVIEW_TEXT as PREVIEW_TEXT,BE.PREVIEW_TEXT_TYPE as PREVIEW_TEXT_TYPE,BE.PREVIEW_PICTURE as PREVIEW_PICTURE,L.DIR as LANG_DIR,BE.SORT as SORT,BE.CODE as CODE,BE.XML_ID as EXTERNAL_ID,B.IBLOCK_TYPE_ID as IBLOCK_TYPE_ID,B.CODE as IBLOCK_CODE,B.XML_ID as IBLOCK_EXTERNAL_ID,B.LID as LID
FROM
b_iblock B
INNER JOIN b_lang L ON B.LID=L.LID
INNER JOIN b_iblock_element BE ON BE.IBLOCK_ID = B.ID
INNER JOIN b_iblock_property FP0 ON FP0.IBLOCK_ID = B.ID AND FP0.CODE='ORDER'
INNER JOIN b_iblock_element_property FPV0 ON FPV0.IBLOCK_PROPERTY_ID = FP0.ID AND FPV0.IBLOCK_ELEMENT_ID = BE.ID
WHERE 1=1
AND (
((((BE.IBLOCK_ID = '16'))))
AND (EXISTS (
SELECT IBLOCK_ID FROM b_iblock_site WHERE IBLOCK_ID = B.ID
AND (((SITE_ID='s1')))
))
AND ((((BE.ACTIVE='Y'))))
AND (((BE.ACTIVE_TO >= now() OR BE.ACTIVE_TO IS NULL) AND (BE.ACTIVE_FROM <= now() OR BE.ACTIVE_FROM IS NULL)))
AND ((((FPV0.VALUE_NUM = '0'))))
)
AND (((BE.WF_STATUS_ID=1 AND BE.WF_PARENT_ELEMENT_ID IS NULL)))
ORDER BY BE.ACTIVE_FROM desc ,BE.SORT asc ,BE.ID desc LIMIT 0, 200
И это я еще использование индексов у полей таблиц не проверял, потому что при миграции это не важно.
Перевел один из магазинов с Битрикса на свою платформу - продажи выросли на 30% сразу после переключения из-за резко возросшей скорости загрузки страниц и ускорения процедуры оформления заказов.
Сейчас перевожу еще одну систему, так там да, безумное количество запросов SQL при отображении простой таблицы клиентов из 50-60 строк. Время загрузки страниц полностью не устраивает заказчика, что и не удивительно.
Битрикс создавался очень давно как универсальный инструмент для разработки сайтов. Не удивительно, что попытки применения его для интернет-магазинов не приводят ни к чему хорошему. По моему мнению, универсальные инструменты, разработанные для всего подряд, плохо справляются с решением всех задач, для которых они создавались. Ведь там нет специализации и учета особенностей каждой области.