Дружище, если есть что написать толкового, то пиши, если в теме не разбираешься, то лучше помолчи. Минус ты схватил, за неконструктивную критику, и неуважительное отношение к "коллегам" по Хабру. Про тебя я могу много что написать что ты там в штаны делаешь себе, но это площадка не для этого.
Да у меня тоже появлялись мысли что дальше ПО будет такой же черной коробочкой (в которой никто из людей не разбирается) как собственно и ИИ модели сейчас. Но это влечёт потерю контроля над приложением и мне это не нравится. Ну вобщем для простых клиентских приложух может быть и норм, но серьезные корп. и гос. приложения конечно будут разрабатываться с участием человека.
1. Про IPC и «process/thread». В OptimaOS процессная модель: у процесса есть PID, своё адресное пространство, свой набор capabilities, и endpoint привязан к owner PID. Потоки есть, конечно, но это уровень планировщика внутри процесса. Поэтому термин «process» у нас буквальный, без подмены на thread.
2. Какие прерывания сейчас в ядре. В ядре есть базовый interrupt path через IDT, таймерный путь для тиков и планировщика, page fault #14, IPI для SMP (Halt/Init/Call/Resched), плюс hardware-путь для xHCI/MSI(-X) в HAL-части. Дальше логика уходит в userspace через typed IPC.
3. Что значит «unsafe вынесен в HAL». Смысл простой: риск не размазан по коду ядра. Опасные места сидят в узкой аппаратной границе: MMIO/PCI/APIC/UEFI handoff и соседние low-level участки. Остальной kernel-core живёт под жёстким запретом unsafe по умолчанию, у unsafe-блоков есть инварианты и отдельные проверки. Это облегчает аудит, особенно когда трогаем hardware bring- up.
4. Почему GPLv3, а не AGPL. Для ядра главный сценарий — поставка бинарников в устройства. Тут GPLv3 закрывает нужные вещи: copyleft при дистрибуции, anti-tivoization, патентный грант. AGPL больше про сетевой сервис и удалённый доступ к коду, для kernel-слоя это не главный юридический рычаг. Поэтому выбран GPLv3 + двойная лицензия: сообщество получает открытый контур, коммерческий вендор может работать по отдельной лицензии без обязательства публиковать изменения.
Да вы правы, технологии (внутрянка) ни кому из потребителей не интересны. Главное чтобы работало везде и без сбоев. Выигрывает в конечном итоге тот кто делает интересный продукт, и он может быть на любой технологии. Есть идеи массового продукта на этой идеологии, но чтобы это стало жить нужно упорство, удача и административный ресурс продуманный маркетинг)
Спасибо за интересный проект — это практически "сосед по цеху") Включу его в статью. Он решает задачу как общаться, если центральный сервер заблокирован или нежелателен, на основе email как транспорта. Но я предлагаю чуть иное "контейнеризацию" своего аккаунта и данных (для удобного переноса в любой провайдер или на свою ноду), сообщений, а также статей и новостей (для удобного хранения и подтверждения "неизменямости" информации, а также авторства).
Смотрите, мы не строим конкурента MAX, это в принципе не возможно. Т.к. MAX гос. мессенджер с глубокой интеграцией с госуслугами и государственными информационными системами. Мы хотим просто дать людям выбор где вести свою переписку, возможность дать тот функционал которого нет в MAXe, команда маленькая мы меньше, гибче и быстрее можем фичи пилить. Еще раз повторяю мы не против чего то, мы просто заполняем нишу которая осталась пуста после ухода Телеграмма. Может мы ее займем, может мессенджер от Яндекса, МТСа, Сбера. Ничего страшного.
Вы не поняли, если проект проживет пару лет, мы будем выходить на другие страны. Я не говорил что проект закроется через пару лет. Про выгоду — давайте так, что если этим мессенджером будет пользоваться хотя бы 1000 человек, я буду считать что получил выгоду — сделал полезное дело для 1000 человек.
Мы рассматриваем такую возможность, просто с точки зрения законодательства не все гладко в этом вопросе. Если будет законный вариант такого функционала, мы конечно его сделаем.
Пока на банкете гуляем за свои) Разработка на чистом энтузиазме. Дальше два варианта: 1. Ласточка остается местячковым мессенджером например до 50 000 пользователей, это вполне подъемная инфраструктура на свои. 2. Вдруг проект возымеет большую популярность, тогда потребуются дополнительные источники финансирования, это гранты, инвестиции, реклама и другие способы монетизации. Может попробуем краудфандинг или откроем счет для приема добровольных донатов. Неопределенностей и вариантов очень много. И да есть какой-то план и мы ему следуем))
Да ссылки пока не валидные, завтра будут ссылка на Github и apk мобильного приложения. ИИ агенты конечно использовались в работе, без этого не реально поднять этот проект в ограниченных финансах. Но была переписка только андроид и веб приложения, сервер поправлен был минимально.
Благодарю, с тендерами хорошая идея.
Классная штука, жаль раньше не видел
тьфу-тьфу)
Andreas, ты еще здесь? Я дописал статью, специально для тебя. В конце статьи после UPD посмотри. Да, и не будь таким злюкой)))
Дружище, если есть что написать толкового, то пиши, если в теме не разбираешься, то лучше помолчи. Минус ты схватил, за неконструктивную критику, и неуважительное отношение к "коллегам" по Хабру. Про тебя я могу много что написать что ты там в штаны делаешь себе, но это площадка не для этого.
Да у меня тоже появлялись мысли что дальше ПО будет такой же черной коробочкой (в которой никто из людей не разбирается) как собственно и ИИ модели сейчас. Но это влечёт потерю контроля над приложением и мне это не нравится. Ну вобщем для простых клиентских приложух может быть и норм, но серьезные корп. и гос. приложения конечно будут разрабатываться с участием человека.
Спасибо за комментарий.
1. Про IPC и «process/thread». В OptimaOS процессная модель: у процесса есть PID, своё адресное пространство, свой набор capabilities, и endpoint привязан к owner PID. Потоки есть, конечно, но это уровень планировщика внутри процесса. Поэтому термин «process» у нас буквальный, без подмены на thread.
2. Какие прерывания сейчас в ядре. В ядре есть базовый interrupt path через IDT, таймерный путь для тиков и планировщика, page fault #14, IPI для SMP (Halt/Init/Call/Resched), плюс hardware-путь для xHCI/MSI(-X) в HAL-части. Дальше логика уходит в userspace через typed IPC.
3. Что значит «unsafe вынесен в HAL». Смысл простой: риск не размазан по коду ядра. Опасные места сидят в узкой аппаратной границе: MMIO/PCI/APIC/UEFI handoff и соседние low-level участки. Остальной kernel-core живёт под жёстким запретом unsafe по умолчанию, у unsafe-блоков есть инварианты и отдельные проверки. Это облегчает аудит, особенно когда трогаем hardware bring- up.
4. Почему GPLv3, а не AGPL. Для ядра главный сценарий — поставка бинарников в устройства. Тут GPLv3 закрывает нужные вещи: copyleft при дистрибуции, anti-tivoization, патентный грант. AGPL больше про сетевой сервис и удалённый доступ к коду, для kernel-слоя это не главный юридический рычаг. Поэтому выбран GPLv3 + двойная лицензия: сообщество получает открытый контур, коммерческий вендор может работать по отдельной лицензии без обязательства публиковать изменения.
Добавил прямую "рекламу" в конце статьи)
Да вы правы, технологии (внутрянка) ни кому из потребителей не интересны. Главное чтобы работало везде и без сбоев. Выигрывает в конечном итоге тот кто делает интересный продукт, и он может быть на любой технологии. Есть идеи массового продукта на этой идеологии, но чтобы это стало жить нужно упорство, удача и
административный ресурспродуманный маркетинг)Спасибо за интересный проект — это практически "сосед по цеху") Включу его в статью. Он решает задачу как общаться, если центральный сервер заблокирован или нежелателен, на основе email как транспорта. Но я предлагаю чуть иное "контейнеризацию" своего аккаунта и данных (для удобного переноса в любой провайдер или на свою ноду), сообщений, а также статей и новостей (для удобного хранения и подтверждения "неизменямости" информации, а также авторства).
Удалить свой аккаунт можно в настройках. Почта не работает, это да) Сегодня настрою
Все ссылки теперь на сайте работают
Да, правильно, пока не до ботов на этом этапе
Смотрите, мы не строим конкурента MAX, это в принципе не возможно. Т.к. MAX гос. мессенджер с глубокой интеграцией с госуслугами и государственными информационными системами. Мы хотим просто дать людям выбор где вести свою переписку, возможность дать тот функционал которого нет в MAXe, команда маленькая мы меньше, гибче и быстрее можем фичи пилить. Еще раз повторяю мы не против чего то, мы просто заполняем нишу которая осталась пуста после ухода Телеграмма. Может мы ее займем, может мессенджер от Яндекса, МТСа, Сбера. Ничего страшного.
Приятно познакомиться) Вопросы возможно возникнут, тогда в личные сообщения напишу.
Вы не поняли, если проект проживет пару лет, мы будем выходить на другие страны. Я не говорил что проект закроется через пару лет. Про выгоду — давайте так, что если этим мессенджером будет пользоваться хотя бы 1000 человек, я буду считать что получил выгоду — сделал полезное дело для 1000 человек.
Мы рассматриваем такую возможность, просто с точки зрения законодательства не все гладко в этом вопросе. Если будет законный вариант такого функционала, мы конечно его сделаем.
Выше в статье и комментах вчера писал, что выложу сегодня. Код выложен, ссылки на лендинге поправлены
Пока на банкете гуляем за свои) Разработка на чистом энтузиазме. Дальше два варианта: 1. Ласточка остается местячковым мессенджером например до 50 000 пользователей, это вполне подъемная инфраструктура на свои. 2. Вдруг проект возымеет большую популярность, тогда потребуются дополнительные источники финансирования, это гранты, инвестиции, реклама и другие способы монетизации. Может попробуем краудфандинг или откроем счет для приема добровольных донатов. Неопределенностей и вариантов очень много. И да есть какой-то план и мы ему следуем))
Да ссылки пока не валидные, завтра будут ссылка на Github и apk мобильного приложения. ИИ агенты конечно использовались в работе, без этого не реально поднять этот проект в ограниченных финансах. Но была переписка только андроид и веб приложения, сервер поправлен был минимально.