Я не знаю ни одного человека который бы умышленно выполнял свою работу плохо. Есть недостаточно опытные/квалифицированные люди которые в силу отсутствия знаний или опыта могут выполнить работу не достаточно хорошо. Есть ограничения по ресурсам и времени, которые сильно влияют на качество работы (и так бывает очень часто). Но я не втречал и не слышал о работниках, которые бы специально вредили, потому что им мало платят.
Они хотят писать так, как им привычнее и удобнее. И компилятор плюсов, в отличии от раста, не даёт им по рукам, когда они в очередной расстреливают память или пихают данные в одну и ту же переменную из разных потоков без синхронизации.
Это полнейшая и беспросветная чушь! Так пишут только студенты младших курсов, потому что к старшим курсам они уже вдоволь настрелялись себе в ногу и стараются всеми силами так не делать! Ошибки с памятью (как и с доступом к общим ресурсам), которые возникают в сложных проектах, появляются там не из-за безалаберности программиста, а из-за внутренней сложности архитектуры проекта. Сложность как сущность является причниной большинства проблем. И тут важно то, что эти ваши "безопасные" языки ни как не помогают уберечься от проблемы сложности. Более того, они делают сложную систему еще более сложной и запутанной.
Но хайполовый от бигтеха ухватили беса за хвост и доят тему "безопасных" языков на полную катушку втюхивая тезис о дураках программистах которые не хотят писать как надо.
В Rust существует всего 9 основных умных указателей
Умом двинуться можно от этого вашего Rust. Мне всегда было достаточно одного глупого указателя на тип void. При этом у меня есть успешный опыт разработки и эксплуатации высоконагруженной системы для IP-телефонии (транскодирование голосовых потоков), которая прекрасно функционировала годами на дешевом железе без утечек и с очень-очень редкими крэшами. В гробу и в белых тапках я видел эти ваши 9 умных указателей!
Весьма интересное решение. Сначала мне подумалось, что такой способ реализации многопоточности сильно ущербен, так как делает невозможным одновременное исполнение нескольких hart-ов (иначе это приведет к коллизиям). Но потом подумалось еще, и мне кажется это весьма простым способом сделать многопоточность незаморачиваясь с разграничением доступа к общим ресурсам (память, csr).
Теперь жду описание того, как реализовать в такой схеме контроллер прерываний и обработчик исключений. Напомню, что в спецификации RISC-V прерывания и исключения это одна и та же сущность. Как это должно работать не нарушая спецификацию.
Дмитрий, в контроллер нужно внедрить блок предсказателя и грузить в кэш сектора с наибольшей вероятностью доступа. Задача весьма интересная сама по себе. :-)
Круто! Если кэшировать по несколько секторов и читать с опережением, то скорость исполнения программы будет вполне приличной.
Я в прошлом году реализовал поддержку XiP для QSPI NOR Flash в своём проекте KarnixSoC. С кэшем кода обьемом 1КБ скорость исполнения достигает 90% от RAM. Далее подумал, что не плохо было бы реализовать аналогичную поддержку для SD-карт (через SPI), но от такой идеи отказался и написал простой драйвер на Си для чтения/записи блока, а поверх него сделал поддержку FAT32 и набор команд для загрузки бинарного файла в память. В общем, получился эдакий MS-DOS (или CP/M ?). И памяти у меня почти как в первых PC: 72K (RAM) + 20K (CGA) + 512K (SRAM). :-)
Ejabberd хорош тем, что ему кроме интерпретатора Erlang (BEAM) больше ничего не требуется и ставится он без всяких докеров, двумя командами (плюс настройка SRV записей в DNS). У него даже своя база данных имеется на базе Mnesia. Все остальные решения имеют монстроидальное количество зависимостей.
Почти все XMPP/Jabber клиенты поддерживают групповые чаты (конференции), многие поддерживают голосовые звонки. Гуглите по "xmpp jabber client", их достаточно много. Для андроида есть Xabber (ищите на F-Droid). Для Win/Lin - Pidjin или Gajim. А вообще, есть такой web-сайт: https://xmpp.org/software/
Еще одна прелесть XMPP сервера состоит в том, что к нему можно приделать шлюзы в другие сети. В своё время у нас был шлюз в ICQ, MSN и Yahoo. Сейчас есть шлюзы в SMTP, Matrix и Telegram.
Клиентов с поддержкой XMPP много, но в целом прогресс остановился где-то в 2010 году. С другой стороны, функционала там уже в то время было с избытком. Ну может быть видео и аудио звонки отладили.
Автор статьи делает вид, что не знает (или не понимает) того факта, что в мире open source страшно не приветствуется вайб-кодинг - написанный таким способом код просто не проходит ревью. И это правильно! Весь вайб-кодинг сейчас сосредоточился строго в коммерческом/проприетарном секторе, и там действительно наблюдается бум дешевого низкокачественного софта и сервисов.
Вчера читал срачдебаты на LWN на подобную тему. Жаркая дискуссия была вызвана одним из коммитеров проекта OpenBSD, который ради прикола портировал из ядра Linux в ядро OpenBSD код поддержки Ext4FS с помощью LLM. Причем, чтобы очистить код от GPL лицензии, прогнал его через парочку нейронок. Результирующий код получился радикально другой, но вполне рабочий (все тесты проходит). Кто-то заметил, что этот код очень похож на код ext2fs, только переделанный под 64-х битные указатели и структуры данных, и в целом выглядит не плохо. Тем не менее, Тео де Раадт четко обозначил позицию - такой код не будет принят в репозиторий как минимум по двум причинам: 1) совершенно не понятна и не ясна ситуация с его легитимностью, 2) обслуживать такой код человеку невозможно. А казалось бы, сколько полезных фич можно было бы затянуть сейчас таким способом в BSD проекты с минимальными умственными затратами и способностями. ;-)
Масла в огонь подлил другой коммитер, который взял работу первого, прогнал её через еще одну LLM и заявил, что этот код полностью его личная работа выполненная без участия нейронки - "зуб даю". Уж протроллил, так протроллил! :-)
У кого еще из этой ИИ колды есть прибыль ? Очевидно же, что Nvidia это "продавец лопат" в эпоху лихорадки. Все остальные компании, за редким исключением, полностью дутые, как и в эпоху доткома.
Все верно. В MIK32 обычный EEPROM. В микросхемах посложнее ставят отдельный кристалл с Flash памятью и соединяют с основным внутренними бондами (два кристалла в одном корпусе). Эта практика распространена во всем мире, так как производство Flash памяти это отдельный вид литографии и часто бывает экономически более целесообразно произвести её отдельно от основного кристалла.
И каким боком Rust поможет этим людям ? Rust весьма сложный язык с непростыми концепциями, на овоение которых требуется время и определенные усилия.
Это существенно всё меняет.
Я не знаю ни одного человека который бы умышленно выполнял свою работу плохо. Есть недостаточно опытные/квалифицированные люди которые в силу отсутствия знаний или опыта могут выполнить работу не достаточно хорошо. Есть ограничения по ресурсам и времени, которые сильно влияют на качество работы (и так бывает очень часто). Но я не втречал и не слышал о работниках, которые бы специально вредили, потому что им мало платят.
Это полнейшая и беспросветная чушь! Так пишут только студенты младших курсов, потому что к старшим курсам они уже вдоволь настрелялись себе в ногу и стараются всеми силами так не делать! Ошибки с памятью (как и с доступом к общим ресурсам), которые возникают в сложных проектах, появляются там не из-за безалаберности программиста, а из-за внутренней сложности архитектуры проекта. Сложность как сущность является причниной большинства проблем. И тут важно то, что эти ваши "безопасные" языки ни как не помогают уберечься от проблемы сложности. Более того, они делают сложную систему еще более сложной и запутанной.
Но хайполовый от бигтеха ухватили беса за хвост и доят тему "безопасных" языков на полную катушку втюхивая тезис о дураках программистах которые не хотят писать как надо.
Умом двинуться можно от этого вашего Rust. Мне всегда было достаточно одного глупого указателя на тип void. При этом у меня есть успешный опыт разработки и эксплуатации высоконагруженной системы для IP-телефонии (транскодирование голосовых потоков), которая прекрасно функционировала годами на дешевом железе без утечек и с очень-очень редкими крэшами. В гробу и в белых тапках я видел эти ваши 9 умных указателей!
Весьма интересное решение. Сначала мне подумалось, что такой способ реализации многопоточности сильно ущербен, так как делает невозможным одновременное исполнение нескольких hart-ов (иначе это приведет к коллизиям). Но потом подумалось еще, и мне кажется это весьма простым способом сделать многопоточность незаморачиваясь с разграничением доступа к общим ресурсам (память, csr).
Теперь жду описание того, как реализовать в такой схеме контроллер прерываний и обработчик исключений. Напомню, что в спецификации RISC-V прерывания и исключения это одна и та же сущность. Как это должно работать не нарушая спецификацию.
Дмитрий, в контроллер нужно внедрить блок предсказателя и грузить в кэш сектора с наибольшей вероятностью доступа. Задача весьма интересная сама по себе. :-)
Круто! Если кэшировать по несколько секторов и читать с опережением, то скорость исполнения программы будет вполне приличной.
Я в прошлом году реализовал поддержку XiP для QSPI NOR Flash в своём проекте KarnixSoC. С кэшем кода обьемом 1КБ скорость исполнения достигает 90% от RAM. Далее подумал, что не плохо было бы реализовать аналогичную поддержку для SD-карт (через SPI), но от такой идеи отказался и написал простой драйвер на Си для чтения/записи блока, а поверх него сделал поддержку FAT32 и набор команд для загрузки бинарного файла в память. В общем, получился эдакий MS-DOS (или CP/M ?). И памяти у меня почти как в первых PC: 72K (RAM) + 20K (CGA) + 512K (SRAM). :-)
Ejabberd хорош тем, что ему кроме интерпретатора Erlang (BEAM) больше ничего не требуется и ставится он без всяких докеров, двумя командами (плюс настройка SRV записей в DNS). У него даже своя база данных имеется на базе Mnesia. Все остальные решения имеют монстроидальное количество зависимостей.
Почти все XMPP/Jabber клиенты поддерживают групповые чаты (конференции), многие поддерживают голосовые звонки. Гуглите по "xmpp jabber client", их достаточно много. Для андроида есть Xabber (ищите на F-Droid). Для Win/Lin - Pidjin или Gajim. А вообще, есть такой web-сайт: https://xmpp.org/software/
Еще одна прелесть XMPP сервера состоит в том, что к нему можно приделать шлюзы в другие сети. В своё время у нас был шлюз в ICQ, MSN и Yahoo. Сейчас есть шлюзы в SMTP, Matrix и Telegram.
Клиентов с поддержкой XMPP много, но в целом прогресс остановился где-то в 2010 году. С другой стороны, функционала там уже в то время было с избытком. Ну может быть видео и аудио звонки отладили.
Потому, что это в основном одна и та же шобла.
Автор статьи делает вид, что не знает (или не понимает) того факта, что в мире open source страшно не приветствуется вайб-кодинг - написанный таким способом код просто не проходит ревью. И это правильно! Весь вайб-кодинг сейчас сосредоточился строго в коммерческом/проприетарном секторе, и там действительно наблюдается бум дешевого низкокачественного софта и сервисов.
Вчера читал
срачдебаты на LWN на подобную тему. Жаркая дискуссия была вызвана одним из коммитеров проекта OpenBSD, который ради прикола портировал из ядра Linux в ядро OpenBSD код поддержки Ext4FS с помощью LLM. Причем, чтобы очистить код от GPL лицензии, прогнал его через парочку нейронок. Результирующий код получился радикально другой, но вполне рабочий (все тесты проходит). Кто-то заметил, что этот код очень похож на код ext2fs, только переделанный под 64-х битные указатели и структуры данных, и в целом выглядит не плохо. Тем не менее, Тео де Раадт четко обозначил позицию - такой код не будет принят в репозиторий как минимум по двум причинам: 1) совершенно не понятна и не ясна ситуация с его легитимностью, 2) обслуживать такой код человеку невозможно. А казалось бы, сколько полезных фич можно было бы затянуть сейчас таким способом в BSD проекты с минимальными умственными затратами и способностями. ;-)Масла в огонь подлил другой коммитер, который взял работу первого, прогнал её через еще одну LLM и заявил, что этот код полностью его личная работа выполненная без участия нейронки - "зуб даю". Уж протроллил, так протроллил! :-)
Неправильную технологию ты выбрал для корпоративного чата, Дядя Фёдор, XMPP сервер надо было поднимать (ejabberd).
У кого еще из этой ИИ колды есть прибыль ? Очевидно же, что Nvidia это "продавец лопат" в эпоху лихорадки. Все остальные компании, за редким исключением, полностью дутые, как и в эпоху доткома.
Все верно. В MIK32 обычный EEPROM. В микросхемах посложнее ставят отдельный кристалл с Flash памятью и соединяют с основным внутренними бондами (два кристалла в одном корпусе). Эта практика распространена во всем мире, так как производство Flash памяти это отдельный вид литографии и часто бывает экономически более целесообразно произвести её отдельно от основного кристалла.
Я предпочитаю "как сейчас".
Да.
Не пройдет и года, как все всё перепишут.
Видеоролик отпадный! :)