А короч все забыли про юникс философию)

Да, вот интересует вопрос. Чего они там всё время пишут в ядре? Ведь предыдущая версия и так работает.

Как че, очередную вишенку, нахуй никому не нужную

Да, вот интересует вопрос. Чего они там всё время пишут в ядре? Ведь предыдущая версия и так работает.

30 мая 2011 Линус Торвальдс выпустил ядро версии 3.0-rc1. Вместе с ним изменена политика нумерации версий ядра. Отменено использование чётных и нечётных номеров для обозначения стабильности ядра, а третье число означает стабильность ядра. Версия 3.0 практически не несёт никаких изменений, кроме изменения политики нумерации ядра.

в таком духе

Версия 4.0[21] — изменения касаются, в основном, исправлений драйверов (media, sound, pci, scsi target, drm, thermal.), обновлений для архитектур nios2, x86[22]. Некоторые нововведения:[23] установка обновлений ядра без необходимости перезагрузки; улучшения для платформы Intel ‘Skylake’; поддержка Intel Quark SoC; различные улучшения для работы Linux на Playstation 3; поддержка драйвером TOpen-source AMD Radeon функции DisplayPort Audio; различные улучшения в драйверах HID, включая Lenovo compact keyboards, Wacom Cintiq 27QHD; в драйвера управления питания Toshiba добавлены настройки USB sleep/charge functionality, rapid charge, sleep w/ music и др.; улучшения работы с файловой системой, включая F2FS, BtrFS и др.

Ну типа вы написали стабильное ядро. Оно умеет запускать процессы и т.п. Ну и зачем дальше что-то писать? Ведь оно уже умеет запускать процессы.

ниос 2 поддержали

в ядре для компа

плейстейшн 3

А, они же держат все драйвера внутри

ну не внутри

но рядом

не вкомпиливая но ведя в том же разделе контроля версий

Нельзя ли написать какое-нибудь базовое ядро и никогда его не обновлять. Ну разве что иногда, для фикса какой-нибудь уязвимости.

А драйвера клавиатур пусть копошатся в другом репо

Нельзя ли написать какое-нибудь базовое ядро и никогда его не обновлять. Ну разве что иногда, для фикса какой-нибудь уязвимости.

не нельзя а нужно

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

https://www.crowdsupply.com/deepwave-digital/air-t ну вот фыр, а

оомг

$5.7k девять заказчиков и проект окуплен, круто

но это же пиздец

завязываться на гпу, ещё и в неудобном огромном формате

диплёнин к сдр за уши притянут

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

а что драйверам всё время нужно разное, чтобы годами постоянно что-то менять?

Дсп на питоне, ах, ну да. Фильтры ж на нем модно в прошлом году было

Надо запретить на мировом уровне обновления по мелкой хрени, и питон

Лол

Js ограничить

Js ограничить

а js и так не страдает)

Яву задушить максимально, при выпуске продукта на Яве - письмо о целях на 10 листах а4

Все что веб2.0 - расстреливать

https://docs.oracle.com/javase/specs/

Особо опасных и буйных прогрессоров отправить в резервации

?

у тя апрельские тезисы

в сентябре

Chapter 3 describes the lexical structure of the Java programming language, which is based on C and C++. The language is written in the Unicode character set. It supports the writing of Unicode characters on systems that support only ASCII.

ява видимо создана в ответ на проблему старой С++ боли - утечки памяти

отнять у кодера указатели это важно и правильно

new и delete никогда не совпадут числом, так не будем же на это полагаться

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

По данным сайта shootout.alioth.debian.org, для семи разных задач время выполнения на Java составляет в среднем в полтора-два раза больше, чем для C/C++, в некоторых случаях Java быстрее, а в отдельных случаях в 7 раз медленнее[11]. С другой стороны, для большинства из них потребление памяти Java-машиной было в 10—30 раз больше, чем программой на C/C++. Также примечательно исследование, проведённое компанией Google, согласно которому отмечается существенно более низкая производительность и бо́льшее потребление памяти в тестовых примерах на Java в сравнении с аналогичными программами на C++[12][13][14].

но вряд ли если переписать современные проги с яв на плюсы - они вообще влезут в оперативку. не забыть удалить объект невозможно

и там старая проблема которая отпочковала линукс от юникса - обработка исключений

либо си плюсминус проги жиреют сами, следя за своими ошибками и не доверяя своему коду

либо юзают доверенную прогу которая следит за ними, но это простите ява

писать сразу без ошибок - нет, так не бывает

ситуаций которые могут наступить - тысячи

есть решение в микросервисах

оттестированных в хвост и в гриву

собсна идеология линупса

вот тот же тг. зачем он монолитен?

есть приём/отправка данных, это изолированный модуль

тогда сервисов становятся тысячи и запутки начинаются при обновлении апи любого

который будет общим для всех прог для инета

есть парсинг протокола — почти единственный тг-специфичный модуль

есть гуи

тогда сервисов становятся тысячи и запутки начинаются при обновлении апи любого

не начинаются, потому что семвер

всё уже придумано

понимаю, что звучит как утопия, но почему бы не попробовать в отдельной ветке такое

на ком попробовать?)

отдельные модули очень легко оттестировать полностью, и так же легко положить в контейнеры, ещё и со стандартизированным апи наружу

на ком попробовать?)

а на следующей вашей разработке.

можно же

у мя в коммерческом боюсь всё слишком просто для такой архитектуры

а вот в личном

ну можно

ну да, я про личное, конечно

кста, ещё когда я выпиливал менеджер плюсов из прошивки стмки, я думал что можно написать свой. но решил что если уж ОНИ не смогли

блин, я мечтаю такое сделать

менеджер плюсов?

"они не смогли" это вообще не причина. они же не ради искусства это делают, а ради минимизации себестоимости

то что отвечает за фрагментацию по new delete и быстрый конец памяти при созданиии и удалении двух некратного размера классов)))

а, менеджер памяти

я делал статик классы

а

не написал слово и прочел не так

торопился написать)

страшная бага - читаю что должно быть а не что есть

это сложная тема, да, тут у меня тоже нет ответа. то ли "вся динамика в эмбеде зло", то ли "иногда можно", короче по-моему тут мало кто сечёт вообще

я всё вспоминаю как в офисе хр подменили менеджер памяти на кастомный, и он стал втрое быстрее запускаться

это очень мотивирует

это сложная тема, да, тут у меня тоже нет ответа. то ли "вся динамика в эмбеде зло", то ли "иногда можно", короче по-моему тут мало кто сечёт вообще

можно дефрагментить по идее

ВОТ

контейнеры и вообще песочницы

м?)

разграничение

а никуда не деться

причём маленькие расходы же на это

x86 началось с этого

а давайте раздавать страницы по виртуальным адресам

чтоб одна прога не повредила другую

только боюсь что там дублирование

и неоднократное

на пути от железа до явы)