Привет.

Есть какой-нибудь крупный опенсорц-проект с хорошим кодом для образца? Питон или С++. Мне хотелось бы узнать.

Можно конечно Страуструпов всяких почитать, но в книжках приводится учебный код, который далек от реальности, так что я хз как на самом деле надо писать код. Я пишу как понимаю и стараюсь следовать правилам.

Но опытный программист сразу распознает мой код как код новичка. Как на самом деле пишут опытные прогеры?

Можно еще накидать сюда примеры хорошего (эффективного) и плохого (неэффективного, дублирующегося и т.д.) кода.

Прога на borland c++ опрашивает датчик каждые 3 мс, накапливает данные в большой буфер, буфер memory mapped на файл и когда наполняется, прога делает сброс на диск. Периодически сброс на диск происходит 100-300 мс, вместо приемлых 1-2 мс. Происходит из-за этого подвисание опроса и пропускаем данные с датчика в те 100-300 мс, потраченные на сброс. Как бы лучше реализовать это ? Сейчас сброс на диск и опрос идут в одном потоке, у потока приоритет наивысший. Получится ли решить проблему, если сброс на диск делать в низкоприоритетном потоке ? Важно, чтобы пока идет сброс длительный, поток опроса продолжал работу. И как можно исправить эту проблему видимо с хардом ?

8 марта состоялось обновление системы кеширования данных в оперативной памяти Memcached до версии 1.6.0. Основное отличие от предыдущих релизов в том, что теперь для хранилища кэшированных данных стало возможно использовать внешнее устройство.

Memcached применяется для ускорения работы высоконагруженных сайтов или веб-приложений путём кэширования доступа к СУБД и промежуточным данным.

В новой версии при сборке по умолчанию включен параметр extstore, который и отвечает за использование внешнего носителя. Для отключения функции следует указать в ./configure параметр --disable-extstore. Однако несмотря на включенную по умолчанию сборку при запуске следует прямо указать использование этой функции.

Extstore позволяет использовать внешние Flash- или SSD-накопителя для увеличения размера кэша. Это позволит кешировать гораздо большие объемы данных, чем без использования этой функции.

Ещё одним важным нововведением стала переработка сетевого взаимодействия, которое теперь адаптировано для автоматической обработки пакетных обращений в рамках одного системного вызова. В предыдущих версий обработка каждого GET-запроса передавалась в отдельном пакете, тогда как в новой версии ответы на несколько запросов собираются в один метапакет и передаются за один раз. В результате такого нововведения была снижена нагрузка на CPU на 25%.

Также в результате этой модернизации сократилось потребление памяти на буферизацию - с 4.5 Кб до 400-500 байт на вызов, и сократилось использование функций malloc, realloc и free, что привело к меньшей фрагментации памяти. Каждый поток теперь обрабатывает свой пул буферов для чтения и записи для активных соединений. Для настройки размера этих буферов предусмотрены опции -o resp_obj_mem_limit=N и -o read_buf_mem_limt=N.

Также было объявлено о переводе в разряд «устаревших» бинарного протокола обмена с сервером. Ему на смену пришел протокол meta — текстовый вариант протокола с компактными meta-командами. В новом протоколе учтены все доступные ранее операции, использующие старые версии бинарного протокола.

>>> Официальный сайт

>>> Исходный код (лицензия BSD)

>>> Описание Extstore

>>> Описание meta-комманд

>>> Подробности

​​Роскомнадзор будет блокировать mesh-сети, I2P, TOR, TON, Freenet, Zeronet, anoNet. Купол окончательно захлопывается господа.

Как следует из размещённого на сайте госзакупок контракта, подведомственный Роскомнадзору «Главный радиочастотный центр» заключил сделку с Российской академии наук на выполнение ряда работ стоимостью более 9 миллионов рублей.

При проведении работ должны быть разработаны комплексные рекомендации по ограничению доступа к запрещенной информации с использованием mesh-сетей (в контракте указаны Yggdrasill, cjDNS, Briar, Signal Offline, FireChat), I2P, TOR, Telegram Open Network, Freenet, Zeronet, anoNet, а также технологий и протоколов IoT

Окончание работ – 30 июня 2020 года.

https://zakupki.gov.ru/223/purchase/public/purchase/info/common-info.html?regNumber=32008950175

Пользуюсь Thunderbird на десктопе.

Подскажите, есть ли хорошие альтернативы этому клиенту? Желательно кроссплатформенные, с поддержкой нескольких ящиков, imap.

Собственная разработка АстроСофт — новая российская операционная система реального времени МАКС для IT-оборудования и Интернета вещей включена в Реестр российского программного обеспечения.

Министерство связи и массовых коммуникаций включило ОСРВ МАКС в Единый реестр российского программного обеспечения (Приказ Минкомсвязи России от 28.03.2017 №146, реестровый № 3226, экспертное заключение).

МАКС создан без использования элементов стороннего кода (в том числе Linux и FreeRTOS).

Подробности

Перемещено Shaman007 из russia

В php же в куках хранится id сессии, а во flask там у сессионной куки(session) зашифрованное value. По сути тот же механизм, но почему в php сессии серверные а во flask клиентские если данные сессии хранятся в обоих случаях на сервере? И еще вопрос:во flask по умолчанию куки сессии существуют до тех пор, пока не закроется браузер. Если пользователи не закроют браузер в течение длительного промежутка, то как это скажется на нагрузке сервера и потреблении его памяти?

Дэмиэн Рил, юрист, программист и бакалавр музыки, и Ноа Рубин, музыкант, (Damien Riehl, Noah Rubin) написали программу, которая сгенерировала все возможные короткие 12-тактные мелодии, использующие 8 нот в пределах октавы (около 69 миллиардов комбинаций), зарегистрировали их от имени своей компании All the Music, LLC и передали в общественное достояние. Выложили на archive.org 1200 Gb в архивах tar.gz по несколько сотен мелодий. (Проблема в архивах: сняты все биты разрешений, может понадобиться chmod -R a+rw.)

Заявленная цель — предотвратить иски как у Тома Пэтти против Сэма Смита, которого суд признал виновным в подсознательном копировании мелодии. Если в будущем кто-то будет требовать с кого-то денег за то, что его мелодия похожа на существующую, можно будет ссылаться на архив. По крайней мере, если мелодия истца издана после выкладки архива.

Сама программа, перебирающая сочетания нот, выложена на GitHub под лицензией Creative Commons-Share Alike 4.0. Язык — Rust. Авторы сравнивают её работу с брутфорсом паролей, 300 000 комбинаций в секунду.

Новость на vice.com

Рил объясняет, что число мелодий конечно, YouTube

>>> Новость на opennet.ru

Суть — доступ к базе в event-loop при большом количестве входящих http соединений — over 30k.

event-loop подразумевается на базе libuv.

UPD. На данную вакансию людей уже взяли, но ищем специалиста на схожую вакансию - нужен специалист по анализу и закрытию уязвимостей (описание на сайте https://www.rosalinux.ru/vakancies/). Плюс на ещё более схожую - на кросс-мейнтейнера («Перенос и сборка пакетов с архитектуры x86 на такие архитектуры как Elbrus, MIPS, ARM»).

UPD2. На закрытие уязвимостей тоже взяли. Осталась только вакансия кросс-мейнтейнера.

Может кому тут подойдёт - желательно тем, кому нравится собирать пакеты, кому интересно смотреть, что там в новых версиях разного софта появилось, какие-нибудь фичи самому в софт добавлять патчами (или отдельными программами в дистрибутив) и вот это всё. Часть работы - на своё усмотрение разные пакеты собирать/обновлять. Часть - будут ставиться задачи, надо будет по ним работать (скажем, чинить падения сборок пакетов, которые не собрались с OpenSSL 1.1.x, патчить их под новый API).

Собственно, сама вакансия.

1. Задачи:

• Работа с пакетной базой, пересборка программной платформы, обновление пакетов и исправление ошибок.

2. Требования:

• Понимание устройства современных линукс-дистрибутивов
• Сборка RPM-пакетов
• Владение скриптовыми языками программирования (минимум Bash)
• Знание систем сборки проектов (autotools, cmake и т. д.)
• Желательно владение языками программирования (одним или несколькими: C/C++, Python, Perl, Java, Ruby)
• Умение читать чужой код, находить и исправлять в нём ошибки

3. Условия

• Работа удалённая или в офисе в Москве - на выбор (про офис можно почитать по ссылке, график работы и т.п. - https://www.rosalinux.ru/vakancies/ ; на удалёнке график относительно свободный, но желательно всё же быть на связи в рабочее время по Москве).
• Оформление по ТК РФ
• Заработная плата полностью белая, выплачивается 2 раза в месяц
• Сама з/п - от 40к и выше, сильно зависит от результатов собеседования; верхняя граница - может в районе 100к, но если в офис, то может и повыше будет - специфика вакансии такая, что иной человек может нескольких других стоить в плане КПД, знаний/навыков и т.п... Знание selinux тут будет большим плюсом, в частности. Или хорошее знание perl или java. В общем, всё это надо на собеседовании обсуждать, на 40к особо не смотрите, это для тех, кто едва подходит, а предпочтение всё-таки будет отдаваться хорошим специалистам.

4. Дистрибутив - ROSA (десктоп). Пакетная база своя, не пересборка чужой.

5. Контакты (куда отправлять резюме и т.д.):

• Email: job@rosalinux.ru
• Телефон: +7 (495) 137 88 66

Но лучше тут тоже писать, если отправили резюме (чтобы я был в курсе). Если есть вопросы по существу - задавайте.

P.S. Есть ещё аналогичная вакансия, но с акцентом на вопросах безопасности - отслеживать и закрывать уязвимости и т.п.

Особенности:

• KISS;
• self-hosted;
• отсутствие сборов (для примера, bountysource и gitcoin забирают себе 10% от выплаты);
• поддержка множества криптовалют (на данный момент это Bitcoin, Ethereum и Cardano);
• предполагается (и предусмотрена) поддержка GitLab, Gitea, и других Git-хостингов в будущем.
• глобальный список задач со всех (то есть одного, на момент написания новости) инстансов на donate.dumpstack.io.

Механизм работы для GitHub со стороны владельца репозитория:

• (опционально) необходимо развернуть сервис, можно использовать готовую конфигурацию для NixOS;
• необходимо добавить GitHub Action — внутри вызывается утилита, которая сканирует задачи проекта и добавляет/обновляет комментарий о текущем состоянии кошельков для пожертвований, при этом приватная часть кошельков хранится только на сервере пожертвований (в будущем с возможностью вынести в оффлайн для крупных пожертвований, для ручного подтверждения выплаты);
• во всех текущих задачах (и новых) появляется сообщение от github-actions[bot] с адресами кошельков для пожертвований (пример).

Механизм работы со стороны выполняющего задачу:

• в комментарии к коммиту указывается, какую именно задачу этот коммит решает (см. closing issues using keywords);
• в теле pull request указываются адреса кошельков в определенном формате (например, BTC{address}).
• при принятии pull request выплата совершается автоматически.
• если кошельки не указаны, либо указаны не все, то выплата средств для неуказанных кошельков совершается на кошельки по-умолчанию (например, это может быть общий кошелек проекта).

Безопасность:

• поверхность атаки в целом небольшая;
• исходя из механизмов работы, сервис должен иметь возможность отправлять средства самостоятельно, так что получение доступа к серверу будет означать контроль над средствами в любом случае — решением может быть только работа в неавтоматизированном режиме (например, подтверждение выплат вручную), которая вероятно (если проект будет достаточно успешен для того, чтобы кто-то задонатил на эту функциональность, то не вероятно, а точно) будет когда-то реализована;
• критически важные части четко отделены (по сути, это единственный файл pay.go на 200 строк), тем самым упрощая security code review;
• код прошел независимое security code review, что не означает отсутствие уязвимостей, но снижает вероятность их наличия, особенно в свете запланированной регулярности ревью;
• также есть те части, которые не контролируются (например, API GitHub/GitLab/etc.), при этом возможные уязвимости в стороннем API планируется закрывать дополнительными проверками, тем не менее, в целом проблема в текущей экосистеме нерешаема и out of scope (возможная уязвимость с, например, возможностью закрывать чужие pull request и тем самым добавлять код в чужие проекты ― имеет гораздо более глобальные последствия).

>>> Подробности

Правильно я понимаю, что идея language server'а в том, чтобы не писать поддержку каждого нового языка для всех редакторов и сред разработки?

Вот вроде бы в Emacs'е есть lsp-mode. Правильно я понимаю, что с этим плагином Emacs выступает клиентом lsp-сервера, информация о подсветке, автодополнении и прочих штуках должна поступать от lsp-сервера, её не должно уже реализовывать в Emacs'е. Так?

Но почему тогда на страние lsp-mode'а написано, что поддерживаются только некоторые языки, а не все поддерживаемые LSP?

Support for programming languages is provided by the following packages:

lsp-rust
lsp-go
lsp-python
lsp-haskell
lsp-java

Как мне через LSP получить CSS, JavaScript, C#?

Я произвожу сборку ядра из исходников с kernel.org . Делаю make && make modules && make modules_install && make modules_install install && make install (возможно тут есть лишние команды. я плохо понимаю, как производится сборка) Получаю готовое ядро, перезагружаю систему. Она загружается с новым ядром. А вот в /usr/src нет kernel-headers для нового ядра. Как их получить из собранных исходников?

Нигде не нашел внятного ответа на простой вопрос.

В программе нужно иметь несколько синглтонов, например один из вариантов синглтона Майерса:

class CMySingleton
{
public:
  static CMySingleton& Instance()
  {
    static CMySingleton singleton;
    return singleton;
  }

// Other non-static member functions
private:
  CMySingleton() {}                                  // Private constructor
  ~CMySingleton() {}
  CMySingleton(const CMySingleton&);                 // Prevent copy-construction
  CMySingleton& operator=(const CMySingleton&);      // Prevent assignment
};

Каждый день видим рождение дистрибутивов с разной банальной функциональностью, вроде минимализма, или дружелюбностью для пользователя или каким-то конкретным DE по дефолту.

Для поддержки оборудования возьмем ядро линукса за базу, но будем мыслить шире. Архитектуру userspace можно делать совершенно по-разному.

Я привел список сильно и средне оригинальных идей с мультивыбором. Некоторое достигается в обычном линуксе сторонними приложениями, но мало кто допиливал эти возможности до полноценного применения или предоставлял как функциональность по умолчанию.

Некоторые идеи все-таки реализованы в дистрибутивах, но я добавил их в список из-за малой распространенности. Возможно люди о них не знают, потому интересно посмотреть насколько высоко они будут в опросе по сравнению с другими идеями.

Вылез из криокамеры и обнаружил оную. Вижу также много критики в ее сторону (стандартная: «Дракон может *специально* крякать как утка, чтобы попасть к вам в пруд».) Так всё же: это благо или зло (если рассматривать не только в контексте языков с динамической типизацией)?

https://twitter.com/jack/status/1204766078468911106

Джек Дорси (тот, который глава твиттера и один из создателей Square), анонсировал разработку протокола для распределенной социальной сети.

Пообещал, что твиттер будет частью этой сети, так что в отличии от других РСС, у этой есть шанс выстрелить.

Ниже есть его размышления о том, почему это правильно. Тоже интерсно почитать.

Twitter is funding a small independent team of up to five open source architects, engineers, and designers to develop an open and decentralized standard for social media. The goal is for Twitter to ultimately be a client of this standard.

Вольный перевод:

Твиттер профинансирует небольшую независимую группу из пяти архитекторов, инженеров и дизайнеров, которые будут разрабатывать открытый и децентрализованный стандарт для социальных медиа. Выжная цель Twitter - быть клиентом этого протокола.

Принцип «программа должна выполнять одну функцию и выполнять её хорошо», думаю, объяснять не требуется. Однако проскочила мысль, почему так получилось? Почему вместе с C в составе UNIX введено несколько мощных языков, как язык сценариев или AWK?

Специалистов писать на Си не так уж много, а сам язык довольно прост. Но для решения задач быстро наклепать на Си код, как на питоноперле, не получится, да и не было в 70-е ни питоноперлов, ни вычислительных мощностей. Вот и было придумано отдавать выводы программ на откуп sh, чтобы не заниматься отловом нулевых символов - так что требовательные к ресурсам места скрипта были программами на Си, а чёрную работу по осмыслению вывода выполняла оболочка.

Не в этом ли причина существования UNIX-way?

Перемещено leave из general

Категорический всех приветствую!
Ребята, посоветуйте современный фреймворк на javascript или php для запила несложного хоббийного одностраничного сайта.
Очень желательно чтобы фреймворк имел низкий порог вхождения, чтобы можно было запилить страницу за несколько вечеров.
А что Bootstrap, он еще актуален?

И да, чтобы избежать шквала ‘добрых советов’ сразу поясню, что сайтостроительство не моя тема)

Что-то у меня мозоли от попыток задействовать IPC-семафоры:

• shared posix mutexes - нету (из всех «бздей» есть только у FreeBSD и то с выкрутасами);
• POSIX.1 семафоры отключены еще в v5.5 (Revert to return EPERM for sem_init(3) pshared until it works properly). Причем в NetBSD и DragonFly эти семафоры больные (вплоть до сore dump).
• SysV семафоры похоже глючат.

На самом деле сложно понять что именно глючит (может у меня руки кривые) без допиливания теста. Но тот-же код работает на Linux, FreeBSD, NetBSD, DragonFly, Darwin и Solaris (OpenIndiana).

На этом фоне были замечены глюки ядра OpenBSD. Например, после заполнения /tmp (tmpfs), после последующей очистки и до перезагрузки semget() стабильно выдавала «no space left on device», а ipcs выдавала встроенный help вместо обработки опций.

На OpenBSD еще есть futex-ы (aka benaphores) портированные из Linux. Соответственно, можно попробовать их в IPC-блокировках. Но я уже сомневаюсь - стоит ли тратить время на это «унылое говно»? (уж извините).

Вскрытие стюардессы показало, что причина уже не в SysV-семафорах (они работают), а в Buffer/Page Cache.

Технически происходит следующее:

1. файл mmap-ится в память несколькими процессами в режиме read-only.
2. один из процессов обновляет фрагмент файла, например через pwrite() или writev() и затем инвалидирует mmap и/или кэш CPU.
3. все процессы видят изменения в своих mmap-регионах.

Упомянутая инвалидация mmap не требуется во всех актуальных операционках. Только MIPS требует инвалидировать кэш CPU. Но на всякий случай попробовал и с msync().

Так вот, проблема в том, что на OpenBSD третий пункт выполняется не всегда. Даже если явно пнуть ядро посредством msync(MS_INVALIDATE).

При этом, если mmap-ить файл в read-write режиме и менять данные не через запись файл, а непосредственно в памяти то всё работает.

Короче, диагноз ясен. Напишу в bugs@openbsd.org, может-быть поправят.

Добавлено 2019-11-14: На сабмит в bugs@openbsd.org был получен ответ «это не баг, а фича». Лично для меня открытие, что оказывается в OpenBSD «by design» либо mmap, либо write(fd).

https://marc.info/?l=openbsd-bugs&m=157373953304874

https://github.com/leo-yuriev/libmdbx/issues/67