IT в России и мире в реалиях мирового кризиса

Цитата: Поверонов от 12.03.2024 15:49:15уже сделан D

много на нем софта за 20 лет написали?

Цитата: ps_ от 12.03.2024 23:24:32Сейчас все на Rust тяжело дышат

Пограмистов стало много, а среди них пишущих хороший код - мало.
Новые языки пытаются решить эту проблему. Го - пишите пусть много, зато очень просто. Раст - компилятор придирается по максимуму, ублажайте его.
Микросервисы - пишите все в один поток, параллельности выносим на выше уровень, там спец.программисты разберутся, может быть.
А еще любят прогонять код через анализаторы кода - внедряют высокие стандарты. Супервысокие я бы сказал.
В целом все эти инструменты превращают обычного программиста в кодера-слесаря. Для корпораций, где этих пограмистов как грязи - это конечно выход.

Не помню, кто тут рвал полупопия за облака

https://softline.ru/…-iz-rossii

Феерично...
мОт лица ГК Softline мы подтверждаем получение официальной информации от Microsoft и Amazon о приостановлении с 20 марта 2024 г. доступа к облачным продуктам на территории России. В связи с этим ГК Softline предупреждает о возможных функциональных ограничениях в работе облачных продуктов и сервисов Microsoft, Amazon и Google. Согласно письмам от правообладателей, с указанной даты будет прекращен доступ к облачным продуктам, таким как (включая, но не ограничиваясь): Power BI, Dynamics CRM и другие. Мы ожидаем, что приостановка также затронет облачные решения, содержащие эти продукты.
Эти ограничения в отношении России определены так называемым «12 пакетом санкций Европейского союза» от 19 декабря 2023 года, который ограничивает поставку в Россию программного обеспечения для бизнес-аналитики (business intelligence (BI), Customer Relationship Management (CRM) и других продуктов.
Для российских компаний это означает, что воспользоваться этими продуктами или получить доступ к данным, содержащимся в них, с 20 марта 2024 г. будет невозможно. Согласно письмам от правообладателей, данные продукты станут недоступны для российских клиентов в связи с требованиями новых положений Регламента ЕС 833/2014, который вводит ограничения на поставку в Россию различных видов программного обеспечения. Важно отметить, что речь может идти о всех облачных продуктах Microsoft, Amazon и Google, которые правообладатели определят в качестве запрещенных для поставки в РФ согласно требованиям указанного выше Регламента.
Чтобы избежать полной или частичной потери информации, ГК Softline рекомендует всем компаниям в кратчайшие сроки выполнить резервное копирование данных, связанных со всеми облачными продуктами Microsoft, Amazon и Google.
Со своей стороны ГК Softline готова оказать необходимую помощь и всестороннюю поддержку своим клиентам в переходе на альтернативные российские решения. Эксперты Softline могут предложить как развернутые консультации по выбору нового ПО, так и разработку дорожных карт по миграции с иностранных продуктов на альтернативные решения российских производителей, а также тестирование и внедрение выбранных продуктов. С сегодняшнего дня для наших клиентов работает Telegram-канал, который будет пополняться рекомендациями и обновленной информацией по мере получения ее от вендоров Telegram-канал.
ГК Softline имеет все необходимые ресурсы для оперативного решения вопроса миграции из зарубежных облачных сервисов, включая данные пользователей, в готовый и надежный сервис Softline Universe (http://universe.softline.ru) с развертыванием всех необходимых служб базовой инфраструктуры — от почты до офисных приложений. Сервис входит в Реестр Минцифры отечественного ПО, доступен по подписке и включает комплект программного и аппаратного обеспечения от ведущих российских производителей с гарантией высокого уровня доступности сервисов (SLA). 
Контакты пресс-службы ГК Softline: Ащеулова Светлана, pr@softline.ru.

Цитата: GrinF от 16.03.2024 14:31:09Не помню, кто тут рвал полупопия за облака

  Microsoft, Amazon и Google.

Осталось определить разницу между технологией и поставщиком сервиса.

Цитата: gvf от 16.03.2024 15:08:58Осталось определить разницу между технологией и поставщиком сервиса.

ага осталось ждать не долго ...через неделю мы услышим тпрямую и незмутненнную тракторку всех юридицих терминов

• Prohibition to provide enterprise and design-related software to the Russian government or Russian companies. The aim is to further hamper Russia's capacities in its industrial sector. Restrictions in the area of services are an area where we have worked closely with our international partners, including the US and the UK.
  

https://ec.europa.eu…ip_23_6566

) Additionally, Decision (CFSP) 2023/2874 extends the existing prohibition on the provision of services to also include the provision of software for the management of enterprises and software for industrial design and manufacture, subject to appropriate exemptions and derogations.

b) the following paragraph is inserted: ‘2b. It shall be prohibited to sell, supply, transfer, export, or provide, directly or indirectly, software for the management of enterprises and software for industrial design and manufacture as listed in Annex XXXIX to: 
(a) the Government of Russia; or
 (b) legal persons, entities or bodies established in Russia.’;

Paragraph 2b shall not apply to the sale, supply, transfer, export or provision of software that is strictly necessary for the termination by 20 March 2024 of contracts which are not compliant with this Article concluded before 19 December 2023, or of ancillary contracts necessary for the execution of such contracts.’;


ANNEX XXXIX List of software as referred to in Article 5n(2b) Software for the management of enterprises, i.e. systems that digitally represent and steer all processes happening in an enterprise, including:
 – enterprise resource planning (ERP), 
– customer relationship management (CRM),
 – business intelligence (BI),
 – supply chain management (SCM),
 – enterprise data warehouse (EDW),
 – computerized maintenance management system (CMMS),
 – project management software,
 – product lifecycle management (PLM),
 – typical components of the above-mentioned suites, including software for accounting, fleet management, logistics and human resources.

Design and Manufacturing Software used in the areas of architecture, engineering, construction, manufacturing, media, education and entertainment, including:
 – building information modelling (BIM),
 – computer aided design (CAD),
 – computer-aided manufacturing (CAM),
 – engineer to order (ETO),
 – typical components of above-mentioned suites.’.

https://eur-lex.euro…_202302878

Цитата: GrinF от 16.03.2024 17:07:05ага осталось ждать не долго ...через неделю мы услышим тпрямую и незмутненнную тракторку всех юридицих терминов

https://vc.ru/servic…ye-servisy

Цитата: Прокруст от 12.03.2024 21:53:34Эта супероптимизация, когда компилятор умнее программиста - просто треш и угар. Давно не включаю флаг оптимизации больше -O1 - иначе невозможно предсказать,что сделает компилятор.
Забавно сколько сил тратится на фичи, вместо того чтобы просто допилить компилятор, чтоб ошибки показывал, эээ, по точнее.

С Цэ сейчас сложилась странная ситуация. В комитете перепредставлены разработчики компиляторов и недопредставлены те, кто язык использует. Поэтому в стандарт суют всякое странное, но родовые травмы (всякие UB к примеру) лечить не пытаются. Пейсателям компиляторов (что GCC, что CLANG), например очень удобно, чтобы C был подмножеством C++. Вот и тащат в стандарт всякую бяку, а действительно полезные вещи не делают.

Цитата: LightElf от 17.03.2024 12:50:22С Цэ сейчас сложилась странная ситуация. В комитете перепредставлены разработчики компиляторов и недопредставлены те, кто язык использует. Поэтому в стандарт суют всякое странное, но родовые травмы (всякие UB к примеру) лечить не пытаются. Пейсателям компиляторов (что GCC, что CLANG), например очень удобно, чтобы C был подмножеством C++. Вот и тащат в стандарт всякую бяку, а действительно полезные вещи не делают.

Отвечал выше, но отвечу еще раз – все случаи UB перечислены в стандарте. Это значит, что любой факт их появления в программе – ошибка программиста. Если вы не будете создавать условий для UB, никаких проблем у вас не будет. Просто почаще в стандарт заглядывайте. Компилятор ЯП не должен анализировать семантику – это исключительная задача программиста, который должен знать, что он делает. И если программист, например, кастует указатель в целое, значит это так и надо. тем не менее, компилятор, конечно же, в этом случае выдаст предупреждение.
Есть такая библиотека – pthreads, так вот в документации четко написано, что многие функции никаких проверок на значения параметров не делают и правильные значения, переданные в вызов, – это ответственность программиста и только его. В этой библиотеке UB на порядок больше, чем в Std ISO/IEC 9899 и никого это не беспокоит.

Цитата: adolfus от 18.03.2024 02:42:23Отвечал выше, но отвечу еще раз – все случаи UB перечислены в стандарте. Это значит, что любой факт их появления в программе – ошибка программиста...

Стандарт позволяет различные трактовки и этим активно пользуются. Хуже всего то, что разработчики компиляторов создают новые, под предлогом супероптимизации - полностью нарушая принцип наименьшего удивления. Они толкуют вполне ясно написанный текст стандарта так, как им выгодно - и им совершенно плевать на смысл написанного.

Цитата: Прокруст от 18.03.2024 09:04:56Стандарт позволяет различные трактовки и этим активно пользуются. Хуже всего то, что разработчики компиляторов создают новые, под предлогом супероптимизации - полностью нарушая принцип наименьшего удивления. Они толкуют вполне ясно написанный текст стандарта так, как им выгодно - и им совершенно плевать на смысл написанного.

Интересно, какие же различные трактовки позволяет ISO/IEC 9899? Примеры приведите, пожалуйста.
Также интересно, какой из компиляторов и каким образом использует различные трактовки стандарта?

Цитата: adolfus от 18.03.2024 10:03:18Интересно, какие же различные трактовки позволяет ISO/IEC 9899? Примеры приведите, пожалуйста.
Также интересно, какой из компиляторов и каким образом использует различные трактовки стандарта?

Наслаждайтесь чтивом https://thephd.dev/conformance…eestanding
Или вот https://thephd.dev/c-undefined…-guideline
Вообще рекомендую вам почитать этого автора.

Цитата: adolfus от 18.03.2024 02:42:23Отвечал выше, но отвечу еще раз – все случаи UB перечислены в стандарте. Это значит, что любой факт их появления в программе – ошибка программиста. Если вы не будете создавать условий для UB, никаких проблем у вас не будет. Просто почаще в стандарт заглядывайте. Компилятор ЯП не должен анализировать семантику – это исключительная задача программиста, который должен знать, что он делает. И если программист, например, кастует указатель в целое, значит это так и надо. тем не менее, компилятор, конечно же, в этом случае выдаст предупреждение.
Есть такая библиотека – pthreads, так вот в документации четко написано, что многие функции никаких проверок на значения параметров не делают и правильные значения, переданные в вызов, – это ответственность программиста и только его. В этой библиотеке UB на порядок больше, чем в Std ISO/IEC 9899 и никого это не беспокоит.

Значительная часть описанных в стандарте UB уже давно не имеют никакого практического смысла. В 70-х годах их наличие имело причины. В настоящее время этих причин нет. Их можно и нужно тупо вычистить из стандарта, приняв наиболее распространенное поведение за норму. 
Например:процессоров с обратным кодом давно не делают. Везде используется двоичная арифметика в дополнительном коде, никаких оснований сохранять UB на integer overflow - не существует. Если писатели компилятора не заложили специально диверсию (а они это любят, да), то на любом, существующем за пределами музея, процессоре INT_MAX+1 == INT_MIN. У процессора целочисленное переполнение проблем не вызывает. А вот у стандартизаторов - прям беда. Еще можно вспомнить, например, сравнение указателей. Вы в курсе, что сравнение двух указателей между собой - это UB? Алло, 80286 не производятся давно. И уж явно не стоит в 2023 точить стандарт под его причуды.
Таких примеров можно собирать пачками. Одни и те же люди сначала раскидывают по стандарту UB направо и налево, а потом творят дичь в компиляторе, ссылаясь на стандарт. Из свежего в C23: realloc(p, 0) который всегда был полным аналогом free(p), вдруг стал UB. Ахиреть не встать.
Да что там говорит, в стандартной библиотеке C до сих пор нет элементарного макроса для определения, является ли целевая платформа big или little-endian, через изврат приходится выяснять. Но зато всякой хероты туда навтыкали, да.
В комитете по C очень мало людей, которые реально программируют на С. Там сидят на всю башку приплюсные писатели GCC и CLang.
Линус как-то емко высказался про стандарт C:

ЦитатаI've said this before, and I'll say it again: a standards paper is
just so much toilet paper when it conflicts with reality. It has
absolutely _zero_ relevance. In fact, I'll take real toilet paper over
standards any day, because at least that way I won't have splinters
and ink up my arse.

https://lkml.org/lkml/2018/6/5/769

Цитата: Прокруст от 18.03.2024 12:02:26Наслаждайтесь чтивом https://thephd.dev/conformance…eestanding
Или вот https://thephd.dev/c-undefined…-guideline
Вообще рекомендую вам почитать этого автора.

КГ/АМ

Цитата: LightElf от 19.03.2024 15:26:08Значительная часть описанных в стандарте UB уже давно не имеют никакого практического смысла. В 70-х годах их наличие имело причины. В настоящее время этих причин нет. Их можно и нужно тупо вычистить из стандарта, приняв наиболее распространенное поведение за норму. 
Например:процессоров с обратным кодом давно не делают.
...

Вы не поняли, что такое UB (неопределенное поведение). Это когда известно, что так делать нельзя, но вы, не зная этого и не желая узнать, делаете. В резульате напарываетесь и рефлексируете. Есть еще вариант более слабый, – это когда известно, что результат некоторого действия зависит от реализации компилятора или стандартой библиотеки (помним, что libc есть равноправная часть языка), но программисту похрен – у него именно та единственная реализация, где UB как раз оказывается не UB. Это мне напоминает чумаковщину 90-х в отношении "недокументированных функций  виндовс".  Здоровый yf голову программист будет осознанно избегать использования таких "фич".
"Распространенного поведения" не существует – есть стандарт и все нормальные компиляторы стараются ему соответствовать. В тех случаях, когда стандарт говорит, что это UB, использовать это просто нельзя. Не хватает мозгов запомнить все случаи UB – выписываем на лист и цепляем на рабочем месте на стенку.
У компиляторов бывают расширения. Собственно, прежде чем какие-то фичи попадают в стандарты, они обкатываются как расширения на  распространенных компиляторах (разумеется, если их производители в этом заинтересованы). Однако, не все они полезны, этb фичи – здесь важно не то, насколько они удобны нубу или уменьшают риск нуба напороться на UB, важно только то, что примет комитет или не примет это расширение в обязательную часть стандарта. И уж точно, те UB, которое требуют семантического анализа, комитет даже обсуждать не будет – там народ, плотно работающий на си лет сорок, и им не понятно, как так можно напороться на UB. Процесс принятия расширений публикуется в открытой печати и нет проблем за пару лет до выхода std оценить, попадет расширение в стандарт или нет.
Забудьте все, что читали про Си в интернете и книгах кроме книги Фьюэра/Джехани, и читайте только стандарт. Там все перечислено. И как надо и как не надо. Слава разработчикам компиляторов, что, если мы делаем, как не следует делать, в большинстве случаев компилятор обратит наше на это внимание, выдавая предупреждения. Тем не менее, если вы будете четко следовать тому, что написано в стандарте, принимая во внимание именно те предложения, где речь идет о UB, никаких проблем у вас никогда не будет, соответственно, никаких "безопасных" языков и не понадобится. Езда на красный свет, чистка неразряженного оружия, купание в шторм – это, кстати, тоже UB, но нормальный человек всегда прежде, чем что-то делать, всегда прочитает правила и инструкции и будет им следовать не отвлекаясь на позывы самоуверенности.
Просто программируйте на Си всегда, когда это оправдано с точки зрения, не учитывающей навыки и опыт, и все через два-три года у вас начнет получаться. А через пять-семь вы не сможете вспомнить, когда в последний раз вы налетели на malloc()/free() и сюрпризы со строками.

Цитата: adolfus от 20.03.2024 00:24:34Просто программируйте на Си всегда, когда это оправдано с точки зрения, не учитывающей навыки и опыт, и все через два-три года у вас начнет получаться. А через пять-семь вы не сможете вспомнить, когда в последний раз вы налетели на malloc()/free() и сюрпризы

Упал.   Кагбэ Цэ у меня - основной язык последние лет 25. 
Это вы не поняли что такое UB и к чему он приводит с современными компиляторами. Это не про "умные люди решили, что так правильно", это про "мы когда-то накосячили, а вы теперь любитесь как хотите". До определённого момента компиляторы следовали здравому смыслу (некоторые и сейчас следуют), не считали себя умнее программиста и не ломали код целенаправленно. 
Но потом в чьи-то головы пришла идея, что можно запилить "крутые оптимизации", стандарт жеж позволяет. В результате любой большой проект на Си - обложен костылями в три слоя. Посмотрите хотя-бы на линуксовое ядро, где вечно идёт боротьба "каких бы ещё ключей GCC напихать, чтобы он перестал чудить". 
Вдобавок, вы имеете какое-то идеализированное представление о работе комитета ISO. Вам выше дали ссылку на заметки человека, в этом самом комитете заседающего. Где он в красках рассказывает, как комитетчики с 2016 года чинили enum. 
Но информация из первых рук - для вас КГ/АМ
Ещё раз: в комитете, в основном, сидят люди, которые на C не пишут. Им важна ачивка "наш компилятор соответствует стандарту и в одном тесте на 0.05% быстрее конкурентов", желательно при этом не перенапрячься. Как этим компилятором потом пользоваться - их не гребет, совсем.

Цитата: gvf от 16.03.2024 17:41:26https://vc.ru/servic…ye-servisy

Шо скажет начальник транспортного цеха прелставители поставщиков сервиса
https://www.rbc.ru/t…rom_main_2

Autodesk — cоздатель AutoCAD — запретил российским компаниям использовать свой софт — РБК
 

Цитата: DeC от 23.03.2024 12:49:40Autodesk — cоздатель AutoCAD — запретил российским компаниям использовать свой софт

В Асконе побежали за шампанским. Теперь все перейдут на Компас-3d.

Цитата: воффка1 от 23.03.2024 12:58:20Нанокад ещё. Не знаю кто побежит, привыкли сидеть на автокаде, мы точно на трофейном сидеть будем.

До тех пор пока за трофейеый не последуют проблемы с законом.