The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Представлена LittleFS, компактная файловая система для встра..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от opennews (??) on 15-Янв-18, 13:38 
Проект Mbed OS, в рамках которого компания ARM развивает (https://www.opennet.dev/opennews/art.shtml?num=42932) открытую ОС для устройств "Интернета вещей", представил (https://os.mbed.com/blog/entry/littlefs-high-integrity-embed.../) новую файловую систему LittleFS (https://github.com/geky/littlefs), оптимизированную для встраиваемых систем. Код ФС написан на языке Си и распространяется (https://github.com/ARMmbed/mbed-os/tree/master/features/file...) под лицензией Apache 2.0. ФС LittleFS доступна в составе Mbed OS 5.7 (https://github.com/ARMmbed/mbed-os/tree/master/features/file...), как FUSE-модуль (https://github.com/geky/littlefs-fuse) для монтирования из Linux, в форме Си-библиотеки (https://github.com/geky/littlefs) для интеграции с приложениями и как обвязка (https://github.com/geky/littlefs-js) для JavaScrpt (emscripten) для обращения к данным из браузера.


Реализация LittleFS включает  около 2000 строк кода, система не требовательна к ресурсам и может работать в условиях ограниченного размера ОЗУ. В коде не используются рекурсивные вызовы и возможна работа без динамического выделения памяти с использованием статически определённых буферов. В отличие от других ФС для Flash-накопителей, построенных на основе структур данных в форме лога, в LittleFS размер потребляемой оперативной памяти и служебных структур на накопителе всегда остаётся постоянным, не зависимо от того, что записывается в ФС и какого размера хранилище.

LittleFS включает программные средства для выравнивания износа Flash-носителей (wear leveling (https://en.wikipedia.org/wiki/Wear_leveling)), позволяющие минимизировать повторное использование блоков и равномерно распределить операции очистки блоков на Flash-памяти, контроллер которой не обеспечивает решение данной задачи.


Важной для встраиваемой техники особенностью LittleFS также является устойчивость к сбоям - ФС рассматривает случайное прекращение работы (завершение работы через отключение питания) в качестве штатной ситуации и спроектирована для гарантирования нахождения хранилища на диске в целостном состоянии в любой момент времени.  Для исключения  нарушения целости и потери данных применяется (https://github.com/geky/littlefs/blob/master/DESIGN.md) механизм copy-on-write (COW), при котором изменения не перезаписывают информацию, а сохраняются в новое место.

Структуру LittleFS составляет набор блоков директорий. Каждая директория имеет связанный список пар метаданных, которые могут обновляться атомарно через изменение указателя на активный блок метаданных. Блоки директорий включают ссылки на другие файлы или директории. Содержимое файлов представлено COW-списками CTZ, обеспечивающими уровень сложности O(1) при добавлении и O(nlogn)  при чтении. Выделение блоков осуществляется через сканирование ФС на предмет использованных блоков в области фиксированного размера, хранимой в виде битового вектора. Для упрощения сканирования все директории являются частью связанного списка, охватывающего всю файловую систему. Если при записи блока определяется ошибка, то выделяется новый блок и данные переносятся в него.


Поддерживается полный набор POSIX-подобных функций для работы с файлами и каталогами. Обеспечивается атомарность совершения таких операций, как удаление и переименование, даже в случае пропадание питания во время их выполнения. Фактически изменения файла сбрасываются на диск только после вызова sync или close. Рассогласования, вызванные операциями, которые не могут быть выполнены атомарно, решаются специальным обработчиком deorphan, который проходит по всему дереву ФС при первом распределении после загрузки.

URL: https://os.mbed.com/blog/entry/littlefs-high-integrity-embed.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=47906

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 15-Янв-18, 13:38 
>> уровень сложности O(1) при добавлении и O(nlogn) при чтении

А ок ли это? Или планируется мало читать с этой ФС, типа конфиги на ней хранить которые потом превращаются в рантайм?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Представлена LittleFS, компактная файловая система для встра..."  +1 +/
Сообщение от dq0s4y71 (ok) on 15-Янв-18, 13:42 
> планируется мало читать

Ну, для эмбеддед это норма. Есть ещё romfs такая.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Представлена LittleFS, компактная файловая система для встра..."  +4 +/
Сообщение от Andrey Mitrofanov on 15-Янв-18, 13:47 
>>> уровень сложности O(1) при добавлении и O(nlogn) при чтении
> А ок ли это?

Почему нет? Размер кода и ограничения по памяти у них первее, например, а для таки "небольших" ф.с. фактическое время того nlogn может быть приемлемо для конкретного применения. Корень какого ембеда со 100 файлами и 10ью директориями  --  авдругаесли.

Ну, и они ж logfs в 2kSLOC-ах и для микроконтролёра сделали. Это же #успех.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

60. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 17-Янв-18, 00:39 
> Ну, и они ж logfs в 2kSLOC-ах и для микроконтролёра сделали. Это же #успех.

Сразу за тасксвичером вместо линукскернела, в очереди за игнобелевской премией.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

99. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Асушник on 22-Янв-18, 19:27 
Нередко контроллер генерит много(для его масштабов доступной памяти) данных, а работает например автономно и надо довольствоваться тем, что можно поставить на борт. Например СД карту. А читать с нее вообще не надо, конфиг можно хранить в ЕЕПРОМ самого контроллера. И нередко требования к памяти программ и ОЗУ ключевые. Приходилось как то использовать FAT в приборе с 1024байтами ОЗУ. 512 сразу отьедалось под кластер. А так как прибор много чего делал кроме этого лога, то чтобы все влезло в флеш и в ОЗУ пришлось порубить там все возможноти. Нельзя было создавать директории, файлы только в корне, а в моем случае так вообще 1 возможный файл. Хотя у современных контроллеров можно за небольшую разницу в цене найти вариант с бОльшим количеством памяти и не париться, может играть роль фактор больших серий, когда даже незначетельная разница может дать хорошую экономию. Или надо прикрутить новую периферию к существующей системе. Так что такие поделки имеют свое применение, тем более когда и драйвер есть для этой ФС под линукс.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

101. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от rewwa (ok) on 29-Янв-18, 23:35 
>>> уровень сложности O(1) при добавлении и O(nlogn) при чтении
> А ок ли это? Или планируется мало читать с этой ФС, типа
> конфиги на ней хранить которые потом превращаются в рантайм?

Вот для меня это тоже загадка.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Представлена LittleFS, компактная файловая система для встра..."  +4 +/
Сообщение от dq0s4y71 (ok) on 15-Янв-18, 13:50 
> написан на языке Си

Но как же так? Почему опять не на Джаве/Питоне/Расте/Аде (нужное подчеркнуть)?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 15-Янв-18, 13:54 
Ретрограды, сэр. Опять будем ловить переполнения буферов и прочие исключительно си-стайл ошибки значит.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

23. "Представлена LittleFS, компактная файловая система для встра..."  –2 +/
Сообщение от фывфыв on 15-Янв-18, 17:45 
PVS или прямые руки вам в помощь.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

24. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от фывфыв on 15-Янв-18, 17:45 
> PVS или прямые руки вам в помощь.

И Valgrind еще.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

57. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 16-Янв-18, 23:30 
Ну, понимаешь, поймать баги в 10 кило сишного кода - проще чем например питон до скорости сишки разогнать. Над последним трахалось с пяток огромных корпораций. Гугл затрахался и сделал go в результате. Который может прибить не только питон, но и яву пожалуй.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

9. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Andrey Mitrofanov on 15-Янв-18, 14:29 
>> написан на языке Си
> Но как же так? Почему опять не на Джаве/Питоне/Расте/Аде (нужное подчеркнуть)?

Кстати да, LISP ещё в прошлом веке [в микроконтроллере] на Марс летал, а они со своим апачем... </>  https://duckduckgo.com/?q=lisp+jpl+history+mars //да, я в курсе, что там написано, что тогда же его и выбросили.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

18. "Представлена LittleFS, компактная файловая система для встра..."  +13 +/
Сообщение от Аноним (??) on 15-Янв-18, 16:18 
Потому что хипстеры от кодинга не могут в embed, как штаны не подворачивай.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

39. "Представлена LittleFS, компактная файловая система для встра..."  +3 +/
Сообщение от Ordu email(ok) on 15-Янв-18, 20:21 
Да ладно тебе, не могут. Всё они могут. https://github.com/gergoerdi/rust-avr-chip8-avr/blob/master/...

Я попробовал -- хочу поливалку для цветов, а то они сохнут постоянно, -- и, скажу, что это вполне возможно сейчас, хоть и сложно. Проблема в том, что мало кто ещё ходил этим путём, поэтому дорожка непроторена. Мне пришлось прорваться через сборку rust и llvm из правильных форков на github'е, через баги xargo (cargo для кросскомпиляции), через отсутствие avr.h (есть https://github.com/avr-rust/ruduino , но он под другую атмегу, не ту, что у меня), через фичи rust'а (всё же фичи, а не баги), которые приводили к слишком агрессивной оптимизации, и через какие-то странные баги, которые я пока ещё не решил кому атрибутировать, думаю всё же llvm'у (адресация портов кривая, обойти можно, но костылём). Но, как бы там ни было, мигать диодом я раст заставил, и готов попробовать завести v-usb через ffi.

Короче, подворачивая штаны, хипстер типа меня вполне может писать на расте под восьмибитный микроконтроллер. Но, да, нельзя не согласиться, что браться за серьёзный embed проект и выбирать rust -- это не самая удачная идея.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

58. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от Аноним (??) on 16-Янв-18, 23:45 
Чинить то что не сломано вообще идея очень так себе. На сях десятилетиями писали проекты для микроконтроллеров и не только, при том очень требовательные к надежности - всякие управляющие системы для жесткого реалтайма и ответственных применений.

А целая атмега для мигания светодиодиком - весьма по хипстерски. Надо было не мелочиться и писюк взять. Смотри, в /sys/class/leds, можно даже из баша мигать, даже клавиатурой блин :).

А подворачивая штаны, в 32-битных микроконтролях половина работы с периферией - тупо прямые обращения в память. И еще дрюкание DMA автомата, если хочется чтобы это быстро было и без участия проца. Поэтому толку от rust-а там ноль целых, фиг десятых.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

74. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от Ordu email(ok) on 17-Янв-18, 05:51 
> Чинить то что не сломано вообще идея очень так себе. На сях
> десятилетиями писали проекты для микроконтроллеров и не только, при том очень
> требовательные к надежности - всякие управляющие системы для жесткого реалтайма и
> ответственных применений.

Фе. Ты писал под микроконтроллеры на C? Значит тебе приходилось заливать в mc кривую прошивку, а потом гадать, что происходит? Так вот rust отличается от C тем, что если программа скомпилировалась, то она работает. Отладка нужна крайне редко. И для микроконтроллеров, которые отлаживать сложнее, чем прикладные процессы, это очень полезный бонус.

> А целая атмега для мигания светодиодиком - весьма по хипстерски. Надо было
> не мелочиться и писюк взять. Смотри, в /sys/class/leds, можно даже из
> баша мигать, даже клавиатурой блин :).

facepalm.jpg

У меня на все случаи жизни спаяна на макетке что-то типа dev-board. Я туда впаял atmega16a, кристалл на 12МГц, коннектор под программатор, usb-разъём, регулятор напряжения, несколько светодиодов. Когда я решил заменить в используемом тулчейне C на rust, естественно я решил это делать на самой простой задаче из возможных -- на мигании светодиодами. Даже не светодиодами, а одним светодиодом висящим на нулевом пине порта B. И естественно я не пойду в магазин покупать самую маленькую attiny, и делать на ней другую девборду под программу мигающую светодиодами, только потому, что аноним в интернете считает, что для мигания светодиодами атмега это оверхед. При этом, ну если по-хорошему, любой микроконтроллер мигающий светодиодом -- это оверхед, потому что вообще-то такая задача легко решается на рассыпухе -- на транзисторах, резисторах да конденсаторах. Я в девятом классе ходил в кружок во дворце пиoнeров, и паял там такую штуку, несмотря на то, что тогда я даже не подозревал о существовании микроконтроллеров.

А когда тебе надо калькулятором воспользоваться, чтобы сложить пяток чисел, ты выключаешь свой Core i7, потому что это оверхед, достаёшь МК-61 и считаешь на нём?

> А подворачивая штаны, в 32-битных микроконтролях половина работы с периферией - тупо
> прямые обращения в память. И еще дрюкание DMA автомата, если хочется
> чтобы это быстро было и без участия проца. Поэтому толку от
> rust-а там ноль целых, фиг десятых.

Я логики не понял. Про работу с переферией и DMA понятно, и не поспоришь. В 8-битных avr'ках, кстати, тоже самое. А вот дальнейшие рассуждения я совсем не понимаю каким образом производятся. Ведь, по идее-то, всё ровно наоборот: если вся работа с периферией -- это работа с памятью, то здесь самым ярким образом раскроется основной перк rust'а -- возможность организовать работу с памятью "безопасным" образом, то есть так, чтобы большинство ошибок отлавливалось бы на этапе компиляции.
Можно например описать память таким образом, чтобы обращение к Rx/Tx приводило бы к ошибке компиляции, каким бы образом оно не происходило. Таким образом можно получить гарантии того, что единственный кусок кода, который туда что-то пишет -- это код работающий с usb. Гарантии того, что я ничего не запишу в portd _случайно_.
Я, знаешь ли, хипстер, и сколько я не писал на C, я не смог дорасти до уровня мифического программиста на C/C++, который может работать с памятью вручную и не совершать ошибок. Я постоянно ошибаюсь, а потом часами сижу и медитирую над кодом, пытаясь сообразить, где и как я накосячил. И именно поэтому мне нравится rust: он позволяет автоматизировать эти медитации, заставить компилятор проверяет, работаю ли я с памятью так, как задумал, или совершил ошибку. Я долго учился писать на C, так чтобы компилятор C проверял бы все эти вещи, но возможности C к проверке ограничены. Возможности rust'а, надо полагать, тоже ограничены, но я пока не нащупал границ.

ps. Что за фильтр на форуме... Дворец пиoнepoв не пропускает.

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

90. "Представлена LittleFS, компактная файловая система для встра..."  +2 +/
Сообщение от Аноним (??) on 18-Янв-18, 00:32 
> Фе. Ты писал под микроконтроллеры на C?

И не только я. Но и еще легион писателей. А знаешь почему? Потому что это - работает. И работает довольно хорошо. Грабли за годы изучены, сюрпризов умеренно, а кому надо еще круче, читают про MISRA C всякие и настраивают проверки комитов в проект.

> Значит тебе приходилось заливать в mc кривую прошивку, а потом гадать, что происходит?

Да. И как меня от этого спасет этот твой Rust?

> Так вот rust отличается от C тем, что если программа скомпилировалась, то она работает.

Так вот, врать - не хорошо. Я могу с наскока написать программу на чем угодно, которая скомпилируется но работать (с точки зрения ведения осмысленной активности) не будет. А так если творится какая-то мистика и отладочный printf не помог, я прицеплюсь JTAGом и посмотрю где проц и чем занимается. От раста это не зависит. Более того - словить клин можно и на расте. Ну вот ждешь ты пока железо выставит битик в регистре, допустим, что кварц завелся. А кварц возьми и не заведись никогда. Мало ли какое дерьмо случается. И какая разница на чем ты будешь висеть? Это лечится не ЯПом, а логикой с таймаутом и общей паранойей что все вокруг сговорились программу испортить. Но чтобы знать про это - надо писать программы, а не разводить теоретические рассусоливания как ты, мегаэмбедер от академии.

> Отладка нужна крайне редко. И для микроконтроллеров, которые отлаживать сложнее, чем
> прикладные процессы, это очень полезный бонус.

У современных микроконтроллеров основная проблема - не с программой блин. А с ее взаиможействием с фичастой и навороченной периферией. И с тем что мнение программы о том что периферия должны была сделать не совпало с мнением периферии. И вот на этом стыке можно выкусить. У микроконтроллеров программы специфичные, управляющие. Координация работы периферии и проч.

А конкретно атмел на надежность класть хотел. У проца нет исключений, нет bad opcode, ни малейших намеков на привилегии или защиту памяти. Поэтому если в проц воткнется частица, или по питанию что-то проскочит и program counter влетит на середину программы, атмел будет до упора пытаться что-то выполнять. Конечно же выполнение программы с рандомного места не имеет смысла и не приведет к хорошему результату. Но с атмелкой это вообще можно заметить только сильно опосля, когда вачдог через кучу времени сработает. Может быть. Если ты с ним не очень глупо работаешь. От обслуживания вачдога в IRQ никакой раст не спасет - IRQ будет живым а основная прога может висеть сколько влезет, например. И програмеской глупостью победили даже аппаратный антизависатор.

>> баша мигать, даже клавиатурой блин :).
> facepalm.jpg

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

> У меня на все случаи жизни спаяна на макетке что-то типа dev-board.

Ну, круто, и чего? А у меня прямща есть нормальный девборд + пара прототипов запиленых ЛУТом. Без макеток - нарисовал в KiCAD, распечатал и протравил. Так прикольнее. При желании маску могу запилить, чтобы совсем как с фабы, но для ранних прототипов это пижонство.

> ней другую девборду под программу мигающую светодиодами, только потому, что аноним
> в интернете считает, что для мигания светодиодами атмега это оверхед.

Ок, убедил. Специально искать тиньку при наличии меги - изврат.

> При этом, ну если по-хорошему, любой микроконтроллер мигающий светодиодом -- это оверхед,
> потому что вообще-то такая задача легко решается на рассыпухе --

А тут смотря как считать. МК один корпус, рассыпуха - много корпусов. А то что внутрях кристалл более сложно обработан... ну вот лично ты врядли даже примитивный биполярный транзистор дома сделаешь. Эти технологии одинаково недоступны для повторения. Хотя какой-то маньяк хотел на дому травить микросхемы и добился кой-каких успехов вроде.

> что тогда я даже не подозревал о существовании микроконтроллеров.

Микроконтроллеры позволили делать сложные вещи проще. Ради именно мигания диодиком их обычно жмутся ставить, разве что сильно продвинутого. А аналог блоков меги на рассыпухе займет наверное целый контейнер. Удачи на рассыпухе хотя-бы UART с программируемым baud :)

> свой Core i7, потому что это оверхед, достаёшь МК-61 и считаешь на нём?

Нет :)

> рассуждения я совсем не понимаю каким образом производятся. Ведь, по идее-то,
> всё ровно наоборот: если вся работа с периферией -- это работа
> с памятью, то здесь самым ярким образом раскроется основной перк rust'а

Раскрывается извините основной перк программиста. Он или делает это правильно и понимает с чем имеет дело. Или наслаждается абы каким трэшом. Ну как, если ты например под работающим процом попробуешь тактирование передернуть или с выбором режима DVFS лоханешься, загнав камень за предел гарантированной стабильности, что будет дальше - unspecified, вообще независимо от ЯП. Запиши в регистр baud rate uart'а неверное значение - и останешься без коммуникаций. Независимо от ЯП. И такое везде.

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

Это например как? Работа с периферией априори опасна, половина операций могут заведомо положить чип, сорвать коммуникации, сломать логику и даже чего-нибудь выжечь в внешней цепи. Например управление 3-фазными движками. Как ты представляешь себе это в безопасном виде? Там любой срыв последовательности чреват как минимум расколбасом мотора, как максимум вылетом ключей и прочего. Индуктивность такая интересная штука что ток в ней зависит от времени. Если это будет неправильное время, ключ вовсе и не обязан столько выдержать, да и сами обмотки.

Там все операции опасны. Защищать почти нечего. И эти операции легитимны с точки зрения формирования логики поведения чипа.

> Можно например описать память таким образом, чтобы обращение к Rx/Tx приводило бы
> к ошибке компиляции, каким бы образом оно не происходило.

А смысл? Тогда RX/TX работать не будет. Ну и у более взрослых 32-битников есть MPU - если очень хочется, само железо даст exception при совании в некий регион памяти. При том даже если это обращение будет сформировано например глючным влетом на середину кода после тяжелого системного сбоя типа program counter runaway например.

> Таким образом можно получить гарантии того, что единственный кусок кода,
> который туда что-то пишет -- это код работающий с usb.

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

> Гарантии того, что я ничего не запишу в portd _случайно_.

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

> не смог дорасти до уровня мифического программиста на C/C++, который может
> работать с памятью вручную и не совершать ошибок. Я постоянно ошибаюсь,

А что помешает ошибаться в работе с регистрами rust? Если ты постоянно ошибаешься, что помешает например писать неверные значения в регистры?

> учился писать на C, так чтобы компилятор C проверял бы все
> эти вещи, но возможности C к проверке ограничены. Возможности rust'а, надо
> полагать, тоже ограничены, но я пока не нащупал границ.

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

> ps. Что за фильтр на форуме... Дворец пиoнЭpoв не пропускает.

Он на пионЭров обиделся, это ругательство такое, как и кос-монавты... :\

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

92. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от Ordu email(ok) on 18-Янв-18, 06:19 
Давай я, прежде чем продолжать дискуссию, уточню один момент. Я на самом деле не знаю, насколько rust полезен для embed'а. Я уверен, что полезен, но вот насколько -- не знаю. Пока у меня есть только одна программка на расте под мк, которая мигает светодиодом, я не могу увидеть общей картинки. На самом деле, я полез совать раст в микроконтроллер для того, чтобы освоить раст на том же уровне, на котором я освоил C: высокоуровневый ЯП нужен для генерации ассемблерного кода, и если мне очевидно какой ассемблерный код будет генерироваться из того или иного куска C'шного кода, то что получится из куска кода на rust'е, я не всегда знаю. Но на x86_64 это в большинстве случаев не столь важно, и поэтому скучно ковырять ассемблерные дампы, а вот при решении embedded задач придётся разбираться и это будет гораздо веселее. Я уже успел столкнуться с неожиданными оптимизациями, когда llvm вдруг решил, что вывод в порты ввода/вывода и delay на циклах -- это вещи, которые можно переупорядочить, то есть сначала вывести всё, а потом отработать все задержки. Но меня в основном больше интересует другое -- как компилируется передача значений в функции, в зависимости от const/mut модификаторов и в зависимости от стратегии передачи move/copy. И с учётом этого, как лучше проектировать API -- когда передавать по значению, когда ссылкой, когда вешать на тип трейт Copy, а когда лучше оставить его жить в move стратегии.

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

Давай попробуем.

Твоя аргументация сводится к тому, что а) "мы всегда так делали" и б) "яп -- не серебряная пуля". Но видишь в чём фишка, ты ведь знаешь, что если ты будешь ждать серебряной пули, то ты никогда не дождёшься, потому что серебряной пули не существует и быть не может. При этом "мы всегда так делали" в современном мире -- это путь в небытие. То есть в прошлом было то же самое, но там этот путь был дольше и мог растянутся на несколько поколений. Если ты хочешь чтобы твои знания и навыки оставались актуальными, или ещё лучше становились бы более ценными, то тебе надо непрерывно учиться. Если ты не учишься, то через десять лет ты будешь старпёром, который хорошо умеет выполнять два технологических действия и ни на что больше не годен. Если тебе повезёт уметь выполнять такие технологические действия, которые будут востребованы до конца твоей жизни, то будут неплохие шансы оставаться трудоустроенным до тех пор, пока ты не умрёшь от скуки выполняя десятилетиями одни и те же технологические действия. Если не повезёт, пойдёшь работать дворником.

> Лично я предпочитаю проявлять внимательность что и почему я делаю в коде. Для меня это работает. И объяснить себе проще и быстрее чем компилятору. И если бы я был хронически не способен написать несколько строк без ошибок, стал бы с горя вебмакакой, там не так важно.

Вот это вот как раз установка "меня всё устраивает, менять что-либо я не собираюсь". Не любое изменение -- это улучшение, но любое улучшение -- это изменение. Если ты хочешь стать лучше, то тебе надо меняться. У твоей внимательности есть границы, у твоих интеллектуальных возможностей тоже есть границы (они у всех есть). Ты можешь оставаться в этих границах, и отказываться от задач требующих выхода за них, либо ты можешь развиваться и учиться работать в областях, где не хватает интеллектуальных возможностей.

> Я могу с наскока написать программу на чем угодно, которая скомпилируется но работать (с точки зрения ведения осмысленной активности) не будет.

Это не аргумент нисколько. Если программист нацеленно пишет нерабочую программу, то мне совершенно неинтересен этот случай. Всё же мы рассуждаем о программмисте, который хочет написать рабочую программу, и более того, прилагает к этому всякие разные усилия: пишет код; думает о том, что пишет; он думает о ещё ненаписанной программе в целом, что позволяет ему сделать код более логичным; он придумывает всякие там CodingStyle, которые позволяют избегать каких-то классов ошибок; он находит свои собственные индивидуальные правила написания кода, которые позволяют ему не совершать тех ошибок, которые он часто совершает. И мы говорим, всё же, о таком программисте, а не о том, который назло мамке пишет нерабочую программу.

А если мы говорим о таком программисте, то... Я фактически забыл про дебаггер, работая с rust'ом в прикладном программировании. Дебаггер не нужен, потому что все ошибки типа "я вносил десяток изменений в разных частях кода, и в процессе забыл про одно из них" теперь приводят к ошибкам компиляции. Более того, у меня входит в привычку, потерявшись в пространстве, забыв о том на каком этапе внесения изменений я нахожусь, запускать процесс компиляции и разглядывать ошибки -- это напоминает. И это стратегия, которая плохо работает в C, и почти совсем не работает в асме.

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

> Раскрывается извините основной перк программиста. Он или делает это правильно и понимает с чем имеет дело. Или наслаждается абы каким трэшом. Ну как, если ты например под работающим процом попробуешь тактирование передернуть или с выбором режима DVFS лоханешься, загнав камень за предел гарантированной стабильности, что будет дальше - unspecified, вообще независимо от ЯП. Запиши в регистр baud rate uart'а неверное значение - и останешься без коммуникаций. Независимо от ЯП. И такое везде.

Основной перк программиста -- это автоматизация всего, что можно автоматизировать, и кое-чего из того, что нельзя. Rust имеет расширенные возможности по детекции ошибок на этапе компиляции, а значит сам бог велел попытаться дотянуться этими возможностями до всего вообще. Ну, например, ты упоминаешь регистр baud rate, почему бы не создать глобальный объект нулевого размера, дать ему доступ к этому регистру, не давать никому другому туда доступа. Затем к этому объекту приделать ровно один pub метод set_baud_rate, который будет проверять входное значение на попадание в заданные границы. Метод естественно сделать inline, с тем чтобы у llvm была бы возможность выполнить проверки в compile-time, выкинув их из рантайма. Это, конечно же, больше геморроя, чем написать одну ассемблерную инструкцию, но написать set_baud_rate не сложнее, а рассуждать о коде будет проще -- в случае, если uart не работает, я легко смогу отмести гипотезу о том, что выставлена неверная скорость передачи.

Это можно сделать и на C без создания объекта, а тупо inline функцией, но объект (пускай и нулевого размера) -- это уже, как бы, память, а этом значит что все перки rust'а по контролю за памятью, оказываются применимы к этому объекту. Мне сложно сказать, как это можно использовать применительно к регистру контролирующему скорость уарта -- зачем может понадобиться mutable/immutable доступ, контроль реентерабельности и прочие перки. Но, я говорю, я не готов пока приводить конкретные и реальные примеры.

Тебе не приходилось читать о верификации кода? Если нет, то почитай обязательно: даже если тебе неинтересна верификация в смысле создания математических доказательств валидности кода, такое чтиво может развить твои способности думать о коде. Внимание от этого не станет устойчивее или шире, но вот способность осмыслять сложный код станет сильнее. Из последнего на что я натыкался: http://www.pathsensitive.com/2018/01/the-three-levels-of-sof...
В частности вывод оттуда: если ты пишешь код под мкк так, чтобы он работал и на другом мкк, то твой код становится надёжнее.

> А у меня прямща есть нормальный девборд + пара прототипов запиленых ЛУТом. Без макеток - нарисовал в KiCAD, распечатал и протравил. Так прикольнее. При желании маску могу запилить, чтобы совсем как с фабы, но для ранних прототипов это пижонство.

ЛУТом?! Ох да нифигажсебе! Круто!
А я всё через дырку, так проще припаять/отпаять, что-то добавить или убрать. А вообще, думаю, купить макетку, которую не надо паять. А то тут на макетке периодически такая путаница из проводов случается из-за неверных исходных посылок, а перепаивать влом. Если же просто перетыкивать, то может быть реже придётся тонуть в соединениях.

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

95. "Представлена LittleFS, компактная файловая система для встра..."  +2 +/
Сообщение от Аноним (??) on 19-Янв-18, 09:16 
> деле не знаю, насколько rust полезен для embed'а. Я уверен, что
> полезен, но вот насколько -- не знаю.

ADA тоже была полезна для космической техники. И все-же Arian 5 упал. А Элон Маск клепает бортовые компьютеры из ширпотреба который даже не rad hard и линуха.

Надежность многогранная штука, нет одного правильного способа. Когда вопрос на миллион, никто не верит в 1 сверхнадежный юнит. Вместо этого ставят несколько и делают кросс-чек. Переход к распределенным системам где корректное поведение формируется более глобальной логикой. Это покрывает многие классы глюков независимо от root cause. Даже сбои в железе.

Если открытие ключа вышибает схему за миллион - пустим 3 проца. Заведем их GPIO на AND и ключ откроется только если все три согласны что ключ надо открыть. В допущении что с закрытым ключем остаться в случае чего менее катастрофично. Можно также определить кто именно сбойнул и перезагрузить его, а если не помогло, выключить совсем.

> из того или иного куска C'шного кода, то что получится из
> куска кода на rust'е, я не всегда знаю.

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

> ассемблерные дампы, а вот при решении embedded задач придётся разбираться и
> это будет гораздо веселее.

Мне еще си оказался удобен тем что я перепер на мк часть либ с x86. Часть кода внаглую протестил сперва в "десктопной" программе а потом пересобрал под мк. На асме это не катит.

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

Прикольно :). С memory mapped периферией в 32-битниках на си достаточно сказать volatile и компилер отвалит с потугами оптимизнуть это. Как в атмеле на си я уже и не помню, они ж гарвардец с несколькими адресными пространствами и разным доступом к памяти, там это как-то вкостылено.

> И с учётом этого, как лучше проектировать API -- когда передавать
> по значению, когда ссылкой, когда вешать на тип трейт Copy, а
> когда лучше оставить его жить в move стратегии.

Это как-то слишком сложно для меня. И объекты мне не надо. Я понимаю указатели и фактические значения. Мне этого более чем. А если что-то менять нельзя я напишу const. Я накатал макросы, в них readonly хардварные регистры заявлены const, прописана ширина регистров и проч и компилер на явно левые операции замечательно вопит. Я договорился сам с собой: трогать HW через функции и макросы. Макросы дают 0 оверхеда, так по скорости можно с асмом зарубиться.

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

Много не обещаю, backlog вырастет.

> Твоя аргументация сводится к тому, что а) "мы всегда так делали"

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

> ты никогда не дождёшься, потому что серебряной пули не существует и быть не может.

Вот я и удовольствовался чем-то типа C99, работает и на pc и на мк, удобно. Можно в принципе что угодно, от bare HW до системных вещей и прикладух.

> При этом "мы всегда так делали" в современном мире -- это путь в небытие.

И все-таки мы тысячелетиями делали колеса круглыми и это неплохо работало для нас. Если кто-то считает что теперь колеса должны стать квадратными, пусть обоснует, чтоли.

> То есть в прошлом было то же самое, но там этот путь был дольше и мог
> растянутся на несколько поколений. Если ты хочешь чтобы твои знания и
> навыки оставались актуальными, или ещё лучше становились бы более ценными, то
> тебе надо непрерывно учиться.

Ты в чем-то прав. Но учится имеет смысл тому что дает какие-то новые качества и преимущества при умеренных затратах. Вот Linux-у например учиться на мой вкус перспективно и воздается. А если научиться дружить микроконтроли с Linux, можно научиться делать крутые многоуровневые системы. По этому паттерну много что делается. Уметь так же даже в один фэйс... мм... :)

> Если ты не учишься, то через десять лет ты будешь старпёром, который хорошо умеет
> выполнять два технологических действия и ни на что больше не годен.

Да. Поэтому у меня есть несколько идей, за которые старперы отвинтили бы мне голову, если бы могли. Но это не значит что абсолютно все идеи и опыт старперов плохи. У них тоже есть чему поучиться. Надо просто отсеять то что хорошо работает от того что себя исчерпало. И вот круглые колеса и си на мой вкус себя совсем не исчерпали. А то что с квадратными колесами может стать меньше ДТП - может быть, конечно, но...

А еще мне нравится когда знания долгоиграющие. Моя цель не только учиться, но и сделать что-нибудь прикольное, позажигать. Если все время изучать новые трюки, есть шанс что на "позажигать" времени не останется. Поэтому долгоиграющие знания приветствуются, если дают разумную эффективность. Знания си или линукса выглядят именно так.

> Если тебе повезёт уметь выполнять такие технологические действия, которые будут
> востребованы до конца твоей жизни, то будут неплохие шансы оставаться трудоустроенным

Говоря начистоту, я боюсь этого больше смерти. Это способ стать живым мертвецом.

> до тех пор, пока ты не умрёшь от скуки выполняя десятилетиями одни и те же технологические
> действия. Если не повезёт, пойдёшь работать дворником.

По степени унылости примерно одинаково. Дворником на свежем воздухе даже приятнее, да и для здоровья полезнее, пожалуй.

> Вот это вот как раз установка "меня всё устраивает, менять что-либо я
> не собираюсь". Не любое изменение -- это улучшение, но любое улучшение -- это изменение.

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

> Если ты хочешь стать лучше, то тебе надо меняться. У твоей внимательности есть границы,

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

Если я понимаю что внимание подвергается стресстесту, значит я продолбался. На дележе проекта на части, понимаемые по отдельности. Это ключевая причина по которой софт декомпозируют на модули. Это же дает начало Test Driven Development, суть которого в том чтобы модули проверить. Это же делает проекты масштабируемыми. В том числе и больше чем на одну голову. В случае логически самодостаточног модуля програмеру не обязательно знать детали реализации.

> Ты можешь оставаться в этих границах, и отказываться от задач требующих выхода за них,
> либо ты можешь развиваться и учиться работать в областях, где не хватает
> интеллектуальных возможностей.

Есть еще опция: "хакнуть жизнь". Как с разбиением на модули. Развивать себя - круто, но налетев на квадратичную сложность даже сверхчеловек забуксует. А если проект декомпозировать до линейной сложности, и обычный человек справится.

Вывод? Если задача кажется большой, надо разделить на части. Заодно можно распараллелить на несколько человек.

> Это не аргумент нисколько. Если программист нацеленно пишет нерабочую программу, то мне
> совершенно неинтересен этот случай.

Конечно специально софт не ломают, это лишь пример. Я к тому что серебряная пуля здорово приукрашена. А программы окаазываются нерабочими не по тем причинам которые теоретики (и не только) ожидали. Именно работа с памятью в МК довольно ограничена. А в MISRA C - бан на адресную арифметику, например. Но хорошо когда бан опционален. Случаи бывают разные. Поэтому назвать работу с памятью ключевой проблемой в мк - хз, не факт это.

А первый вопрос который при создании надежного апи возникает: если есть критичная функция, которая ведет к дестрою, апи должно быть устроено так чтобы случайный вызов и даже влет в ее середину не вызывал дестрой. Это очень интересное соображение, важное в плане надежности. Есть много факторов которые не подконтрольны програмеру, но влияют на надежность. А есть ли в чипе код который может стереть флешку? Даже если програмер у себя все сделает правильно? А что чип делает если питание просело? Приветы атмелу, их разрушение флеша и еепрома при севших батарейках наводило ужас на поколения микроконтроллерщиков. По старой памяти половина до сих пор ссыкует 0-ю ячейку еепром использовать, кривой у атмеля BOR по жизни был :).

> Всё же мы рассуждаем о программмисте, который хочет написать рабочую программу,
> и более того, прилагает к этому всякие разные усилия: пишет код; думает о том,
> что пишет; он думает о ещё ненаписанной программе в целом,

....
Я не вижу 1 важной вещи: думания об архитектуре и декомпозиции. Чем раньше об этом подумано тем меньше потом мучительно больно. Хотя можно и как жабисты, 20 раз реfuckторить конечно. Все и сразу не предусмотришь, конечно, но все же.

> дебаггер, работая с rust'ом в прикладном программировании. Дебаггер не нужен, потому
> что все ошибки типа "я вносил десяток изменений в разных частях

Знаешь, мне тоже обычно не требуется. Как максимум в интересных местах плюю в uart сообщения о интересных событиях. Скорее для понимания общей логики, как фоновый main играет с irq handler'ами на пару и проч. Или мне интересно "а сколько намерялось?". Ты наверное согласишься что шестое, седьмое и i++'е чувства это прикольно. Бывает интересно сколько вокруг вольт и миллиамперов, процентов влажности, градусов, mm hg...

> это стратегия, которая плохо работает в C, и почти совсем не
> работает в асме.

Я бы сказал что на си эта стратегия работает "средне". Если обвесить макросами и следовать нехитрым правилам - не ощущаю проблемы с которой ты борешься.

> мк begin_panic -- это вечный цикл, ничего более осмысленного в голову
> пока не приходит,

Как вариант восстановления системы - вкатить RESET? С быстрым восстановлением состояния в нечто осмысленное и выход на режим заново. Если МК будет висеть и прошляпит критичное событие, нехорошо. Но это зависит от того чем управляем и как безопаснее. Если опрос педали газа встрянет и ECU будет фигачить на том что задано ранее, юзер обделается. А если проц быстро ребутнется и возобновит работу, юзер и не заметит, только сервисник который лог прочитает. А в лог записать reset cause и что там еще известно. Если по нормальному делать, долговременный failure analisys штука полезная для улучшения надежности.

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

По хорошему можно крахлог писать. Если инфраструктура позволяет это сделать без гимора при сильно порушенной сиситеме, не убив систему. Если в флеху или еепром писать, маленькая ошибочка в значении протрет нафиг фирмвару или конфигурацию. И в этот момент лучше быть уверенным в системе. Иногда железо может подыграть локом критичных секторов, но это зависит от. Вообще, кладут крахлог в "scratch RAM" (некий оговоренный адрес), ребутаются, и из корректной системы логгят. Буфер, переживающий ребут. Но это продвинутости для больших долговременных проектов где можно позволить себе крутую и правильную инженерию для долговременного failure analisys. К сожалению есть такая штука как technical debt...

> Основной перк программиста -- это автоматизация всего, что можно автоматизировать,

Я думаю что основной перк программиста - сделать задуманное. А автоматизировать есть смысл то что дает хороший выигрыш при минимуме усилий. А если выигрыш от автоматизации меньше чем затраты на нее, это завал теста на разумность существа.

> Ну, например, ты упоминаешь регистр baud rate, почему бы не создать глобальный
> объект нулевого размера, дать ему доступ к этому регистру, не давать никому другому
> туда доступа.

А что это для меня глобально изменит? Я и так могу дергать его в 1-2 местах и легко замечать обращения из иных мест. Завести себе правило: работа с железкой - только из функции.

> Затем к этому объекту приделать ровно один pub метод set_baud_rate, который будет проверять
> входное значение на попадание в заданные границы.

Можно договориться и без объектов звать функцию "set_baud_rate()" в которой проверять... Юзать ее просто удобнее чем регистры, проблема отпадает сама :). И объекты мне не уперлись, честно говоря.

> написать одну ассемблерную инструкцию,

Даже ассемблерщики пишут subroutine'ы, и даже они могут делать проверки валидности baud.

> я легко смогу отмести гипотезу о том, что выставлена неверная скорость передачи.

Все это можно и на си и даже на асме сделать. Но там тоже не все так просто. А что есть верная скорость? Ну а вот захотели мы по ходу пьесы к MIDI интерфейситься. А там какие-то 31200 bps чтоли левые. Если железка не будет умничать, согласится на это и в лучшем случае заюзает совместимый baud (ошибка в 2% ок). А в слишком умной железке придется фирмварь патчить. Это называется горе от ума.

> Но, я говорю, я не готов пока приводить конкретные и реальные примеры.

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

> Тебе не приходилось читать о верификации кода? Если нет, то почитай обязательно:

Я об этом довольно много чего читал. В том числе и с неожиданных для тебя сторон.
Смотри, раз: http://www.st.com/resource/en/application_note/cd00004479.pdf
И два: http://www.st.com/content/ccc/resource/technical/document/us...

Как тебе такой взгляд на мир? Они повернуты на надежности и на это есть причины - ответственные применения.

> В частности вывод оттуда: если ты пишешь код под мкк так, чтобы
> он работал и на другом мкк, то твой код становится надёжнее.

ИМХО это зависит от того что за код и насколько разные камни. Может и наоборот выйти из-за усложнения кода.

> ЛУТом?! Ох да нифигажсебе! Круто!

Мне всегда хотелось научиться делать "как заводы". Я и подумал - чего бы не реализовать мечту. Теперь тоже так могу. Химлужение - просто и красиво. Маска ("зеленка" и "синька") - плата симпатичнее, удобнее паять SMD. SMD современен и крут, не только для роботов, если готовить правильно. И горячий воздух. Разложил детальки, пыщ-пыщ, готово. Клево. Можно QFP с шагом 0.5, 0603 и даже QFN. Мои технологии хороши для маленьких плат. Достаточно плотных, под SMD. Не люблю сверлить. CAD дает готовые слои. Фольгу лутом, маску литографией. Самый писк - фотошаблон из скотча, спер идею из чьего-то бложика. Печатается на бумаге, клеится скотч, бумага смывается с скотча как при луте с платы. Фотошаблон из спичек и желудей готов! Пленка для лазерника лучше, но ее искать специально надо и она дорогая, а скотч и хреновая бумага под рукой и проверка показала - номер катит.

> А я всё через дырку, так проще припаять/отпаять, что-то добавить или убрать.

Если я ожидаю сильные эксперименты, оставляю эн контактных площадок к которым можно допаять что-то. Но обычно я сносно представляю себе что хочу и рисую "схему устройства" которая в лучшем случае и будет делать то что я задумал. А для совсем абстрактного у меня есть девборд с кучей всего.

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

У макеток и клубков проводов есть ограничения. На них решительно невозможно делать скоростные цепи и/или что-то сильноточное. И мелкие детальки недоступны. Я себе запилил многое из того что давно хотелось. Преобразователи питания, вспомогательные модули типа cut-off разряженного лития и прочие мини-ништячки. На макетке оно не имело бы смысла в силу ненадежности или не заработало из-за сильных токов с частотой 100+ кГц, клубок проводов будет дико излучать и сглючит от своего же излучения. Мне так не интересно.

Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

96. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Ordu email(ok) on 19-Янв-18, 10:56 
> Если кто-то считает что теперь колеса должны стать квадратными, пусть обоснует, чтоли.

Чтобы обосновать квадратные колёса, их сначала надо сделать. Пустобрёхи в интернете предпочитают умозрительные рассуждения, но мир так не работает. Умозрительные рассуждения хороши, когда под ними лежит обширный опыт. Но когда начинаешь делать квадратные колёса, чтобы пощупать на прочность то, что принято считать очевидным, набегают всякие, и начинают доказывать, что "тысячи лет делали круглые и не тужили, ты что думаешь, что самый умный, что ли"?

> Если обвесить макросами и следовать нехитрым правилам - не ощущаю проблемы с которой ты борешься.

Дело в том, что психика склонна не замечать стимулов, которые действуют постоянно. Если что-то присутствует в поле твоего зрения всегда, то ты этого не замечаешь. Например, ты не видишь своего носа, хотя он всегда оставляет свою проекцию на сетчатке при открытых глазах (более того, эта проекция играет важную роль при определении расстояний "на глаз"). Поэтому когда человек говорит, что его всё устраивает и у него нет проблем, то это скорее говорит о том, что он хорошо адаптировался к своим проблемам и перестал их замечать, чем о том, что проблем у него нет. Это и в речи часто видно: начинаешь объяснять линуксоиду/вендовозу, что что-то там в его линуксе/венде неудобно и представляет проблему, а он отвечает, что "это не проблема", и решается она так-то и так-то. Может это просто из-за неудачного слова "проблема", может быть стоит пользоваться словом "трудность". Хотя, они ведь начнут убеждать, что "это совсем не трудно", "трудно для безруких" и тп.

> Как вариант восстановления системы - вкатить RESET? С быстрым восстановлением состояния в нечто осмысленное и выход на режим заново.

Это хорошо делать в законченном устройстве. В нём по-крайней мере можно определить понятия "осмысленное состояние" и "режим". В устройстве же, которое создаётся ради исследования, с этим будут проблемы. Я думаю, что надо просто повесить отдельный светодиод, и в тот вечный цикл воткнуть моргание этим светодиодом, предварительно прочистив табличку прерываний. Будет, по-крайней мере, индикация паники.

> ИМХО это зависит от того что за код и насколько разные камни. Может и наоборот выйти из-за усложнения кода.

Может. Именно поэтому разработчиками до сих пор работают люди, а не программы. Если бы всё было просто, то с разработкой вполне справилась бы программа. Но это не значит, что надо забить на то, что говорят computer scientist'ы.

> Я думаю что основной перк программиста - сделать задуманное. А автоматизировать есть смысл то что дает хороший выигрыш при минимуме усилий. А если выигрыш от автоматизации меньше чем затраты на нее, это завал теста на разумность существа.

Сделать задуманное -- это профессиональное свойство, которое отличает хорошего программиста от плохого. А неуёмное стремление автоматизировать -- это то основополагающее свойство, которое делает из человека программиста.

Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

97. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 21-Янв-18, 10:35 
> Чтобы обосновать квадратные колёса, их сначала надо сделать.
> Пустобрёхи в интернете предпочитают мозрительные рассуждения, но мир так не работает.

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

> Умозрительные рассуждения хороши, когда под ними лежит обширный опыт. Но когда
> начинаешь делать квадратные колёса, чтобы пощупать на прочность то, что принято
> считать очевидным, набегают всякие, и начинают доказывать, что "тысячи лет делали
> круглые и не тужили, ты что думаешь, что самый умный, что ли"?

Есть такое явление. Поэтому оконвательным критерием - как это работает, пожалуй.

> Дело в том, что психика склонна не замечать стимулов, которые действуют постоянно.

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

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

Это вполне возможно. И звучит разумно. С другой стороны, у разных индивидов разные стили мышления и предпочтения. Возможно мой mindset больше подходит к сям чем твой. Мне вот например не требуются крутые абстракции, я хочу чтобы все было просто и прозрачно по возможности. Крутые абстракции и лишние сущности этому крайне не способствуют в управляющем софте.

И вообще, я видел примеры как чрезмерно увлекшиеся правильностью и абстракциями типы сливали проект, все приходило к тому что в их наворотах не разбирается ни 1 человек на планете. В этом плане у си жирный плюс: он на самом деле достаточно простой и не способствует наворачиванию слишком высокопарных абстракций.

> Это и в речи часто видно: начинаешь объяснять линуксоиду/вендовозу, что что-то там
> в его линуксе/венде неудобно и представляет проблему, а он отвечает, что "это не
> проблема", и решается она так-то и так-то. Может это просто из-за неудачного
> слова "проблема", может быть стоит пользоваться словом "трудность".

А может быть человек знает хорошее эффективное решение, которое ты не предусмотрел? Или ему так проще. Я например из винды не соберу конфигурации которые из линуха наворачиваю. Глобально это может быть иногда субоптимально. Локально - с линухом я по крайней мере решу задачу а не обломаюсь целиком.

> Хотя, они ведь начнут убеждать, что "это совсем не трудно", "трудно для безруких" и тп.

А знаешь, жизнь так устроена что немного де-идеализированное, приблизительное, чуток субоптимальное но рабочее решение - везде и всюду. Жизнь эмпирически нащупала эти подходы. Они работают. А перфекционизм в real-world проектах до добра не доводит.

> Это хорошо делать в законченном устройстве.

Фифти-фифти. Это наполовину дебажная фича. Баги бывают разные. Некоторые очевидны сразу. А некоторые случаются раз в неделю. Или год. Когда звезды в правильном расположении. И вот такая фича позволяет странное краевое условие поймать. Системы где так сделано я встречал и в законченном устройстве это "should never happen" если уж по хорошему. Но раз в год и палка стреляет.

> В нём по-крайней мере можно определить понятия "осмысленное состояние" и "режим".

Если это task-specific железка, эти понятия надо бы определить еще на фазе постановки требований, ну и дальше - проектирования и архитектуры системы. Чтобы осмысленно делать все остальное так как это уместно для этой задачи. Наоборот работает плохо.

> В устройстве же, которое создаётся ради исследования, с этим будут проблемы.

А это смотря что исследовать. Даже пардон в generic девбордах те кто их делает все-таки приходят к некоторому набору требований и пониманию того что и почему они хотят получить. Это дает им понимание как это лучше сделать и почему так.

> Я думаю, что надо просто повесить отдельный светодиод, и в тот вечный цикл воткнуть
> моргание этим светодиодом, предварительно прочистив табличку прерываний. Будет,
> по-крайней мере, индикация паники.

Возможно. И это просто в реализации. Но это для каких-то совсем абстрактных экспериментов, просто потому что "просто индикация паники" не позволяет понять что, где и почему произошло (и как с этим бороться).

> Может. Именно поэтому разработчиками до сих пор работают люди, а не программы.

Интересный тезис. А можно какое-то обоснование? Любопытно откуда именно это следует именно тут. Логическая цепочка не реконструируется...

> Если бы всё было просто, то с разработкой вполне справилась бы
> программа. Но это не значит, что надо забить на то, что говорят computer scientist'ы.

Как показал пример Таненбаума и Торвальдса, забить на высокопарные рассуждизмы может быть не самой плохой идеей на свете.

>> Я думаю что основной перк программиста - сделать задуманное. А автоматизировать есть смысл то что дает хороший выигрыш при минимуме усилий. А если выигрыш от автоматизации меньше чем затраты на нее, это завал теста на разумность существа.
> Сделать задуманное -- это профессиональное свойство, которое отличает хорошего программиста
> от плохого. А неуёмное стремление автоматизировать -- это то основополагающее свойство,
> которое делает из человека программиста.

Хороший программист, и особенно апгрейты вида PM/архитект/etc отличаются тем что когда они что-то делают - есть рациональное обоснование почему. Зуд все и вся автоматизировать сам по себе рациональным не является и может привести к страданию фигней когда невероятные усилия убиваются ради копеечного выигрыша. Это ни к чему хорошему не приводит. Если бы человек немного де-идеализировал ситуацию, смог бы сделать лучше, больше и возможно даже интереснее для самого себя, просто он об этом никогда не узнает, погрязнув в идеализме.

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

98. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Ordu email(ok) on 22-Янв-18, 09:42 
>> Чтобы обосновать квадратные колёса, их сначала надо сделать.
>> Пустобрёхи в интернете предпочитают мозрительные рассуждения, но мир так не работает.
> Хорошо ты физиков-теоретиков и любителей сперва в среде моделирования спроектировать до
> того как металл портить. Но если Хокингу можно умозрительно осознать излучение
> черных дыр, я как-нибудь позволю себе анализ движения квадратного колеса ДО
> его выпиливания лобзиком, сорь.

Физики-теоретики были бы совершенно бесполезными ребятами, если бы не эмпирики, которые построили LHC или отправляют аппараты на марс, чтобы померять магнитное поле, и показать, что существующие теоретические модели магнитного поля -- полнейшия туфта, только после этого физики-теоретики начали чесаться, и пришли к выводу, что они зря заложили в свои модели сферичность Марса. http://www.planetary.org/blogs/emily-lakdawalla/2008/1710.html

> И вообще, я видел примеры как чрезмерно увлекшиеся правильностью и абстракциями типы
> сливали проект, все приходило к тому что в их наворотах не
> разбирается ни 1 человек на планете. В этом плане у си
> жирный плюс: он на самом деле достаточно простой и не способствует
> наворачиванию слишком высокопарных абстракций.

А я видел, как те, кто просто брал и лепил как придётся, приходили к ситуации, когда они были не в состоянии двигать проект дальше. Я читал интересные рассказы о том, как проект пришёл к состоянию, в котором любое изменение, исправляющее баг, порождало пяток новых багов.
Я как-то читал статейку, в которой человек разбирал два условных подхода к написанию кода в стартапе -- хакерский и академический. Первый давал быстрый старт, ценой последующего прогрессирующего замедления, второй -- медленный старт, но затем выход на стабильную скорость разработки. А собственно вывод в том, что в стартапе подходы надо объединять, и начиная писать код, писать его так, чтобы затем его можно было бы итеративно переписать. А для этого, надо быть "хакером", и при этом быть докой в "академическом" подходе.

> Как показал пример Таненбаума и Торвальдса, забить на высокопарные рассуждизмы может быть
> не самой плохой идеей на свете.

Пример Торвальдса показывает ещё и то, что прежде чем браться за разработку ядра, надо магистратуру по специальности computer science закончить.

>> Хотя, они ведь начнут убеждать, что "это совсем не трудно", "трудно для безруких" и тп.
> А знаешь, жизнь так устроена что немного де-идеализированное, приблизительное, чуток субоптимальное
> но рабочее решение - везде и всюду. Жизнь эмпирически нащупала эти
> подходы. Они работают.

Я не верю в эти идеи. Нащупывает не жизнь, а человек, и чтобы нащупать он должен активно искать. Пассивое "все так делают" -- для слабаков. Если я сомневаюсь, в том что все делают хорошо, я пойду и попробую сделать лучше. Если мне удастся, то не сомневавшиеся будут выглядеть идиотами. Если мне не удастся, они тоже будут выглядеть идиотами, потому что я, в отличие от них, смогу объяснить, почему делать надо именно так, как они делают, а не иначе, причём не прибегая к аргументам вида "все так делают".

> А перфекционизм в real-world проектах до добра не доводит.

Грань между перфекционизмом и real-world -- это не что-то такое фундаментально определённое законами Вселенной. Это условность, которая определяется скиллами 95% программистов. Иногда эта условность пересматривается -- когда человечество накапливает критическую массу идей, когда это дополняется критической массой изменений в технологиях, внезапно случается "БУМ", и 95% оказываются старпёрами, потому что внезапно оказалось, что системно программировать надо на C, а они только в асме подсекают, а молодые быстрее них учатся.
Именно поэтому не стоит сидеть на жoпе ровно и ждать, когда "БУМ" случится. Надо упреждать. Впрочем, применительно к embedded, мне с профессиональной стороны совершенно не страшно отстать от трендов, так что я тут скорее выступаю в роли того, кто помогает человечеству накапливать критическую массу идей.

>> Может. Именно поэтому разработчиками до сих пор работают люди, а не программы.
> Интересный тезис. А можно какое-то обоснование? Любопытно откуда именно это следует именно
> тут. Логическая цепочка не реконструируется...

Если бы процесс разработки можно было бы свести к базе правил "если-то", то дальше было бы делом техники написать алгоритм, который опираясь на эту базу будет проводить процесс разработки. У нас нет таких алгоритмов, значит процесс разработки невозможно свести к базе правил "если-то". Вот и всё обоснование.

>> Если бы всё было просто, то с разработкой вполне справилась бы
>> программа. Но это не значит, что надо забить на то, что говорят computer scientist'ы.
> Хороший программист, и особенно апгрейты вида PM/архитект/etc отличаются тем что когда
> они что-то делают - есть рациональное обоснование почему. Зуд все и
> вся автоматизировать сам по себе рациональным не является и может привести
> к страданию фигней когда невероятные усилия убиваются ради копеечного выигрыша. Это
> ни к чему хорошему не приводит. Если бы человек немного де-идеализировал
> ситуацию, смог бы сделать лучше, больше и возможно даже интереснее для
> самого себя, просто он об этом никогда не узнает, погрязнув в
> идеализме.

Да, хороший программист должен научиться контролировать зуд всё и вся автоматизировать. Но он не станет программистом, без этого зуда. Без него, он может стать кодером, то есть тем кто сидит за клавиатурой и набирает код. Это тоже разновидность программиста, и такой программист может много чего создать, но он никогда не создаст ядра linux.

Вот как ты думаешь, каким образом можно стать таким PM'ом которого ты описываешь? Как можно научиться априри отличать усилия, которые дадут копеечный выигрыш, от усилий которые в конечном окупятся? Я вижу два подхода. Первый -- консервативный: "мы всегда делали так". Второй -- это обширный опыт, поверх которого выработана интуиция.

Но если ты, будешь следовать любому из этих подходов до того, как стал PM'ом, то ты не станешь PM'ом. При первом подходе твоё "мы всегда так делали" устареет до того, как тебя сделают PM'ом по выслуге лет. При втором подходе -- если ему следовать не имея интуиции, -- интуиция ниоткуда не возьмётся. Для интуиции нужен опыт, причём как успешный, так и неуспешный.

ps. просто ссылка в тему эмбеддед rust'а: http://blog.japaric.io/brave-new-io/
Очень вовремя ссылка появилась. Надо попробовать такое же для аврки сделать, посмотреть что получится.
Вот одно обломно, что компилятор нельзя заставить проверять максимальное время выполнения функции и выкидывать ошибки, если это время может превосходить заданное в заголовке функции значение.

Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

19. "Представлена LittleFS, компактная файловая система для встра..."  –3 +/
Сообщение от лютый жабист__ on 15-Янв-18, 16:45 
Жаба для сложных задач, а не фигуль на 2к строк
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

22. "Представлена LittleFS, компактная файловая система для встра..."  +6 +/
Сообщение от Andrey Mitrofanov on 15-Янв-18, 17:14 
> Жаба для сложных задач, а не фигуль на 2к строк

"Любая фигуля на жабе раздувается сама на 2к+ строк."
    лютый жабист__

Могу Вас %)цитировать?

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

29. "Представлена LittleFS, компактная файловая система для встра..."  +7 +/
Сообщение от dq0s4y71 (ok) on 15-Янв-18, 18:24 
То-то я смотрю все ядра ОС на жабе написаны, а все гoвнoприложения для Андройда - на Си...
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

44. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от лютый жабист__ on 16-Янв-18, 09:33 
>То-то я смотрю все ядра ОС на жабе написаны

Господи, Линус плюсы не осилил, какая жаба? :)
А раз Линус не осилил, значит надо часто-часто повторять, что оно не нужно и всё сбудется :)

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

47. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 16-Янв-18, 11:44 
> Господи, Линус плюсы не осилил, какая жаба? :)

Жаба то проще в н-дцать раз. Любой плюсист поймет код на джаве, а вот наоборот нифига.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

48. "Представлена LittleFS, компактная файловая система для встра..."  +1 +/
Сообщение от dq0s4y71 (ok) on 16-Янв-18, 13:40 
> Господи, Линус плюсы не осилил, какая жаба? :)

Такой тупoй Линус, ага. И разработчики всех остальных ОС тоже такие тупые...

> А раз Линус не осилил, значит надо часто-часто повторять, что оно не нужно и всё сбудется :)

А всё уже сбылось. Жабисты любят повторять, что в "сложных" проектах без жабы не обойтись, но, по факту, самые сложные и требующие надёжности проекты пишутся на "небезопасных" низкоуровневых языках. А жаба как таковая - это очередная вариация на тему "Каким должен быть Си". Даже от точки с запятой не избавилась.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

50. "Представлена LittleFS, компактная файловая система для встра..."  –2 +/
Сообщение от Аноним (??) on 16-Янв-18, 18:48 
> самые сложные и требующие надёжности проекты пишутся на "небезопасных" низкоуровневых языках

Ядро ОС — не самый сложный проект. А уж если говорить о линуксе, то он всяко проще systemD, чего уж говорить о реальных энтерпрайзных приложениях с кучей сервисов и сопутствующей предметной областью, одно лишь изучение которой у типикал кернел девелопера займет десятилетия (даже если не потребуется написать ни строчки кода).

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

53. "Представлена LittleFS, компактная файловая система для встра..."  +1 +/
Сообщение от pavlinux (ok) on 16-Янв-18, 19:36 
> Ядро ОС — не самый сложный проект.

Да ты чо?!

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

54. "Представлена LittleFS, компактная файловая система для встра..."  +1 +/
Сообщение от Аноним (??) on 16-Янв-18, 19:53 
> > Ядро ОС — не самый сложный проект.
> Да ты чо?!

Ну да, а чо? Шаблончик потрескался?

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

55. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от dq0s4y71 (ok) on 16-Янв-18, 20:18 
> А уж если говорить о линуксе, то он всяко проще systemD

И, кстати, Поттеринг тоже не осилил С++, надо же! :D

> одно лишь изучение которой у типикал кернел девелопера займет десятилетия

Ну они ж тупые, понятно. Не в пример жабакодерам ;)

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

56. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от Аноним (??) on 16-Янв-18, 20:56 
> И, кстати, Поттеринг тоже не осилил С++, надо же! :D

Применение Java™ в проекте systemD неуместно в связи с тем, что одной из целей и результатом systemD явилась высокая скорость загрузки системы. systemD еще на том уровне абстракции, когда применение си терпимо.

> Ну они ж тупые, понятно. Не в пример жабакодерам ;)

Человеку, всю жизнь копающемуся в регистрах и байтиках, будет проблематично выйти на уровень абстракции вверх и начать манипулировать более сложными понятиями реальной предметной области, которая и в ООП-то моделируется с многочисленными условностями. Впрочем, верно и обратное. «Сложность системы» оценивается не уровнем абстракции, а богатством терминологии предметной области, которую необходимо смоделировать. Ядро Linux сложнее хелловорлда на Java™ потому, что работает с более многочисленными терминами, чем хелловорлд. Обычное энтерпрайз-приложение на Java™, на которое угрохано десятки человеко-лет, сложнее ядра Linux, потому что оно работает с более многочисленными терминами, чем ядро Linux.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

59. "Представлена LittleFS, компактная файловая система для встра..."  +2 +/
Сообщение от dq0s4y71 (ok) on 16-Янв-18, 23:46 
> Применение Java™ в проекте systemD неуместно в связи с тем, что одной
> из целей и результатом systemD явилась высокая скорость загрузки системы. systemD
> еще на том уровне абстракции, когда применение си терпимо.

Да что вы! Говорят же, что Джава по скорости не уступает С++! Врут?

> Человеку, всю жизнь копающемуся в регистрах и байтиках, будет проблематично выйти на
> уровень абстракции вверх и начать манипулировать более сложными понятиями реальной предметной
> области, которая и в ООП-то моделируется с многочисленными условностями. Впрочем, верно
> и обратное.

Чушь собачья. Есть люди, всю жизнь копающиеся в регистрах и байтиках, и считающие это верхом совершенства, а есть такие, как вы, у которых объём наблюдаемой вселенной совпадает с размером объектной модели джавы. И те и другие просто ограничены в своём мировоззрении.

> «Сложность системы» оценивается не уровнем абстракции, а богатством
> терминологии предметной области, которую необходимо смоделировать. Ядро Linux сложнее
> хелловорлда на Java™ потому, что работает с более многочисленными терминами, чем
> хелловорлд. Обычное энтерпрайз-приложение на Java™, на которое угрохано десятки
> человеко-лет, сложнее ядра Linux, потому что оно работает с более многочисленными
> терминами, чем ядро Linux.

Надо же, как всё просто, оказывается! Нас-то в институтах учили, что формальных методов оценки сложности системы до сих пор не существует, и что оценивать можно, в зависимости от условий, и по количеству связей, и по количеству состояний, и по объёму вычислений, требуемых для изучения системы, и по чёрт знает ещё чему. Но очередная Брендованная Идеология™ нам в очередной раз наконец-то рассказала, как всё есть на самом деле...

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

66. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 17-Янв-18, 01:03 
>> Java™
>> Java™
>> Java™
> Да что вы! Говорят же, что Джава по скорости не уступает С++!
> Врут?

Не врут, а набрасывают™, почти не скрываясь – cудя по всему, вполне успешно )

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

84. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от dq0s4y71 (ok) on 17-Янв-18, 12:02 
Хорошо, когда просто набрасывают. А когда такой умник заводится на работе, начинает засирать мозги начальству и начальство начинает принимать безумные решения, от чего страдает качество продукта и, в конечном счёте, твоя зарплата - начинаешь невольно хвататься за пистолет :)
Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

75. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от лютый жабист__ on 17-Янв-18, 05:55 
> Да что вы! Говорят же, что Джава по скорости не уступает С++!

На простых задачах, например криптография, жабка может раз в 10 уступать. И?
На сложных решение на жабе есть, а сишники не осилили совсем.

Уже 100 раз писал тут список, в ответ лишь помёт летит. Графовая субд (полноценная, уровня neo4j), полнотекстовый поиск уровня lucene (не надо про свинкс), аналог кассандры (не надо про ScyllaDB), в целом платформа JavaEE. Где это всё на си? :)

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

80. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от dq0s4y71 (ok) on 17-Янв-18, 11:15 
> Где это всё на си? :)

А зачем пилить дрова ножовкой, если в распоряжении есть бензопила? Нормальные люди так и делают, и только жабокодеры всё делают бензопилой, считая, что только ей можно решать "сложные" задачи...

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

79. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 17-Янв-18, 09:52 
„«формальных методов оценки сложности системы до сих пор не существует», но линукскернел все равно сложнее, мамой клянусь!”
Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

82. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от dq0s4y71 (ok) on 17-Янв-18, 11:30 
Мамой клянусь, что только жаба позволяет решать сложные задачи!
Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

71. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от 0ffh (??) on 17-Янв-18, 03:20 
Человеку, всю жизнь копающемуся в регистрах и байтиках, будет проблематично выйти на уровень абстракции вверх и начать манипулировать более сложными понятиями реальной предметной области, которая и в ООП-то моделируется с многочисленными условностями. Впрочем, верно и обратное.

прежде чем начать ковырятся в битиках - надо абстрактно - конкретно понять как прицепить это к обьекту и какова модель поведения обьекта
практика жизни поазывает что без опыта в электротехнике и механике - знание ООП не помогает от слова ВАЩЕ

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

72. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от 0ffh (??) on 17-Янв-18, 03:22 
> Человеку, всю жизнь копающемуся в регистрах и байтиках, будет проблематично выйти на
> уровень абстракции вверх и начать манипулировать более сложными понятиями реальной предметной
> области, которая и в ООП-то моделируется с многочисленными условностями. Впрочем, верно
> и обратное.

прежде чем начать ковырятся в битиках - надо абстрактно - конкретно понять
как прицепить это к обьекту и какова модель поведения обьекта
практика жизни поазывает что без опыта в электротехнике и механике - знание
ООП не помогает от слова ВАЩЕ


Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

77. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Andrey Mitrofanov on 17-Янв-18, 09:32 
>что одной из целей и результатом systemD явилась высокая скорость загрузки системы. systemD

Враньё-о-о...
https://openbenchmarking.org/embed.php?i=1711248-AL-BOOTTIME...
https://openbenchmarking.org/embed.php?i=1711282-AL-1711286A...

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

61. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 17-Янв-18, 00:42 
> Ядро ОС — не самый сложный проект.

Глядя на линукскернел так и не скажешь...

> о он всяко проще systemD

Что-то не помню патчей по 10 мегабайтов каждый месяц на сорцы системды. А на линукс это норма жизни. И вообще, пакет системды весит пару мегов. Пакет ядря линя со всеми модулями - метров 70.

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

73. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от лютый жабист__ on 17-Янв-18, 05:49 
>Глядя на линукскернел так и не скажешь...

гляжу в книгу, вижу линусккернел?

Во первых, если пофантазировать, что линукс переписан на жабе, объем кода будет в 10-20 раз меньше. И в комментариях не будет ни одного мата, что уже профит :)

Во вторых, сколько там доля драйверов, процентов 70? Вычёркиваем...

Самое главное, в оставшихся 30% как связаны например сетевой стек и системные процессы?
Никак?! А чё так плохо? В винде например _ещё лет 20_ назад можно было зафаерволить заданное приложение, а повторяшам это всё по прежнему "нинужно". А по факту, не шмогли... :(

p.s. А причём тут жаба? Ну, при том, что там как раз можно очень легко делать
Contexts and Dependency Injection
а не вопить, что это никому не нужно.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

78. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Andrey Mitrofanov on 17-Янв-18, 09:40 
> Во вторых, сколько там доля драйверов, процентов 70? Вычёркиваем...
> Самое главное, в оставшихся 30% к

Ага, "ксанф, выпей море".

Жабист всё про своё: про ядро, которому "не нужны драйверы" и оно "run everywheer".  Поверх "того другого" ядра на Си. С драйверами, ага.

>Самое главное, в оставшихся 30%

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

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

83. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от dq0s4y71 (ok) on 17-Янв-18, 11:38 
"Когда в руках молоток, все вокруг кажется гвоздями".
Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

85. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Nameless Anonymous. on 17-Янв-18, 12:20 
В Linux-е для этого существует selinux (или apparmor), который позволяет запретить доступ чего угодно куда угодно. И не только сетевой доступ, BTW, а к любому ресурсу в системе.
Ну или разрешить.
Неодолима любовь любителей известной операционной системы забивать гвозди микроскопом...
Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

89. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним84701 (ok) on 17-Янв-18, 22:54 
> Никак?! А чё так плохо? В винде например _ещё лет 20_ назад  можно было зафаерволить заданное приложение

Но только если оно добровольно файрволилось. А вот если приложение читало или писало файл через "\\?\UNC\webdav-server\file" или просто тупо открывало адрес в системном браузере, то увы.
Это не говоря о более изрващенных способах с инжектингом кода/DLL в процессы или через DNS.

> "нинужно". А по факту, не шмогли... :(

По факту это абсолютно бесполезно против зловреда и пользователю по умолчанию придется  как минимум еще урезать LD_PRELOAD, форки, дебажинг <продолжить список>. В общем, кривое решение действительно никому особо не нужно.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

91. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 18-Янв-18, 01:10 
> Во первых, если пофантазировать, что линукс переписан на жабе, объем кода будет
> в 10-20 раз меньше. И в комментариях не будет ни одного мата, что уже профит :)

У тебя что, произошло переселение душ с изеном? Для начала написать на яве кернель толком не получится. А ты попробуй из явы присвоить адресу в физической памяти 0x80820000 значение 0x200? Мало ли, mmaped железка какая-то, которой ядро какой-то флаг в каком-то регистре хочет выставить.

> Во вторых, сколько там доля драйверов, процентов 70? Вычёркиваем...

Это с чего вдруг их вычеркиваем? Микроядерщики и прочие любители высокоуровенвой байды как раз с этим всем жидко обоцрались. В лине же отличие между модулем и ядром не настолько уж и, так что модуль даже может быть "встроенный".

> Самое главное, в оставшихся 30% как связаны например сетевой стек и системные процессы?
> Никак?! А чё так плохо? В винде например _ещё лет 20_ назад
> можно было зафаерволить заданное приложение, а повторяшам это всё по прежнему
> "нинужно".

А, так ты маздаец и в линухе не разбираешься. А то iptables умеет по pid'ам процессов файрволить много лет к ряду.

>  А по факту, не шмогли... :(

Да все оно умеет на самом деле. Раз в 20 больше любой винды, при том. Просто гламурных кнопочек для самых маленьких не завезли. И то в федоре чтоли какая-то "user friendly" гадость на бидоне такой направленности как раз была.

А на namespaces можно и покруче винды сделать - распихать на штук пять разных "компов". Кому вообще никакой сети, кому LAN левоватый в своем VLAN-е, кому нормальный выход в сеть после одобрения и заброса в контейнер, кому коммуникации в пределах локалхоста через какую-нить пару veth-ов (понятия не имею можно ли аналог этого в винде сделать вообще).

> Contexts and Dependency Injection
> а не вопить, что это никому не нужно.

В контексте кернела то? Ну иди и напиши на свеой жабе кернель, как уделаешь Торвальца так и возвращайся, поговорим о нужности.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

93. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от лж__ on 18-Янв-18, 06:53 
> У тебя что, произошло переселение душ с изеном? Для начала написать на
> яве кернель толком не получится.

Слово пофантазировать не заметил? Ну растолкую, имелось в виду: сравнивать в лоб килострочки сишные и жабовые очень глупо. Сколько ансисишных строчек в ОДНОЙ жабовой строчке

Set<String> colleagues = employees.stream().filter(e -> !e.getFullname().equals(emp.getFullname())).filter(e -> e.getActiveDepts().stream().anyMatch(emp.getActiveDepts()::contains)).map(e -> e.getFullname()).collect(Collectors.toSet());

предполагаю, что несколько тысяч. Таким вот образом фигулька на жабке превращается в огогопроект на си ;)

> А, так ты маздаец и в линухе не разбираешься. А то iptables умеет по pid'ам процессов файрволить много лет к ряду.

Ну, мне это надо было 20 лет назад, тогда точно не было, а ви винде было ;)
Сейчас открыл iptables-1.6.1/extensions/libxt_owner.c
вижу
"NOTE: PID, SID and command matching are broken on SMP\n");

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

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

94. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от лж__ on 18-Янв-18, 07:10 
>> Contexts and Dependency Injection
>> а не вопить, что это никому не нужно.
> В контексте кернела то? Ну иди и напиши на свеой жабе кернель,
> как уделаешь Торвальца так и возвращайся, поговорим о нужности.

Типичный сишник, как вижу, даже читать не умеет. Речь была про то, что линух-кёрнель не особо сложный проект по сравнению с типичным кровавым ынтырпрайзом.

Патамучта:
а. взаимосвязь между модулями минимальная по сравнению с типичным КЫ-монстром.
Я не гуру по потрохам линуха, но из заголовков статей сложилось впечатление, что такие штуки как dbus и 100500 его предтечей полная фигня. В мире жабы уже лет 20 как сформировались стандарты на системную шину, а фофаны всё переписывают и переписывают.

б. 70% кода дров предлагалось не учитывать патамучта дрова варятся сами в себе, работают только с железом (совершенно тупое: бит туда, бит сюда) и одной подсистемой ОС. Можно написать дрова на миллиард устройств, это не увеличит сложность проекта ни на грамм.

в. язык анси си убог, в итоге 1 строчка на жабе превращается в 100500 строчек на си. Назови проект на си объемом 100-200 млн строчек?

И в целом, великий Линус, с его понятиями, что можно сидеть и годами переписывать одно и то же на 50 рядов, в КЫ вообще бы не задержался, а получил бы хорошего пинка под попу на заре своей карьеры.

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

76. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Andrey Mitrofanov on 17-Янв-18, 09:22 
>> самые сложные и требующие надёжности проекты пишутся на "небезопасных" низкоуровневых языках
> Ядро ОС — не самый сложный проект. А уж если говорить о
> линуксе, то он всяко проще systemD,

Кстати, человек прав. В каком-то смысле.

С т.з. пользователя в s-d гораздо _больше_ ненужной(как там по taoup правитильное слово-то?-) сложности. Несмотря на 15М SLOC против каких-то жалких <400K.

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

Эти наслоители лейеров и обструкторы абстракций известны своими пёрлами, да.  И тут Леннарт -- яркая восходящая звездулька.

> изучение которой у типикал кернел девелопера займет десятилетия (даже если не
> потребуется написать ни строчки кода).

Вот про дев-ров толстовато вышло. Про "типикал" так вообще жироновато.

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

34. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Crazy Alex (ok) on 15-Янв-18, 19:11 
Потому что - сюрприз - так выросло - есть специалисты, библиотеки, процессы, инструменты. И стоимость перехода на что угодно обычно ни черта этот переход не оправдывает. Где надо - там джава (в SCADA, например), и ада, и всё остальное есть, но в среднем по больнице дешевле писать на сях и тестировать до достижения нужной надёжности. Это если вообще. А в данном случае - ну дык у них весь mbed на сях, на чём им ещё ФС писать? Особенно в больших масштабах, где копеечная экономия на более хилой железке даёт в итоге приличную разницу в деньгах.

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

42. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от doom (ok) on 15-Янв-18, 22:05 
>> написан на языке Си
> Но как же так? Почему опять не на Джаве/Питоне/Расте/Аде (нужное подчеркнуть)?

Потому, что как ты не ругай Си, но для всякого рода бибиотек и подобных творений он идеален. Т.к. имеет простой ABI, производительность и кросплатформенность. Поэтому все твои Джаве/Питоне/Расте/Аде сходу смогут использовать этот код, в том числе и спомощью автоматом нагенегрированных "биндингов". Удивляет, что это из недр Mbed, где популярен С++, но молодцы в отличии от гугложопников, которые умудряются примитивный Си код засунуть в примитивный С+, когда это нафиг не нужно.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Представлена LittleFS, компактная файловая система для встра..."  +18 +/
Сообщение от Аноним (??) on 15-Янв-18, 14:05 
> ФС рассматривает случайное прекращение работы (завершение работы через отключение питания) в качестве штатной ситуации

Два чая разработчикам.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

33. "Представлена LittleFS, компактная файловая система для встра..."  +4 +/
Сообщение от Аноним (??) on 15-Янв-18, 18:56 
    int err = fs.mount(&bd);
    if (err) {
        // Reformat if we can't mount the filesystem
        LittleFileSystem::format(&bd);
        fs.mount(&bd);
    }

ну а че, проверка есть... обработка тоже. Штатное поведение, не продерешься.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

7. "Представлена LittleFS, компактная файловая система для встра..."  –3 +/
Сообщение от adolfus (ok) on 15-Янв-18, 14:13 
> Структуру LittleFS составляет набор блоков директорий. Каждая директория имеет связанный список ...
> Поддерживается полный набор POSIX-подобных функций для работы с файлами и каталогами ...

Чем директория отличается от каталога?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Представлена LittleFS, компактная файловая система для встра..."  +8 +/
Сообщение от Аноним (??) on 15-Янв-18, 14:29 
На жестком диске файловая система. В файловой системе директория. В директории каталог. В каталоге папка. В папке файл.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

11. "Представлена LittleFS, компактная файловая система для встра..."  +8 +/
Сообщение от Аноним (??) on 15-Янв-18, 14:32 
Говорят раньше в Windows 95 были еще портфели.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

15. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от adolfus (ok) on 15-Янв-18, 15:05 
И шкафы
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

25. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от Мураками on 15-Янв-18, 17:46 
а деньги, деньги то где ?
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

28. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от Аноним (??) on 15-Янв-18, 18:18 
В тумбочке.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

62. "Представлена LittleFS, компактная файловая система для встра..."  +2 +/
Сообщение от Аноним (??) on 17-Янв-18, 00:45 
> а деньги, деньги то где ?

В случае винды - у билгейца!

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

26. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Дегенератор on 15-Янв-18, 17:47 
Ты пропустил "Новая папка", "Новая папка (1)", "Новая папка (2)", "Новая папка (3)"
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

30. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 15-Янв-18, 18:24 
В файле заяц, в зайце утка, в утке яйцо, в яйце игла - смерть кощеева!
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

32. "Представлена LittleFS, компактная файловая система для встра..."  +1 +/
Сообщение от EuPhobos (ok) on 15-Янв-18, 18:55 
mount море-океан /остров
cd /остров
tar xf дуб сундук
mkdir -p заяц/утка/яйцо
echo -e смерть\nкощеева > заяц/утка/яйцо/игла
...
split игла
...
rm -rf /
umount /остров
dd if=/dev/zero of=море-океан
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

64. "Представлена LittleFS, компактная файловая система для встра..."  –2 +/
Сообщение от Аноним (??) on 17-Янв-18, 00:49 
Попробуй как-нибудь так:
mount -B /srv /proc
mount -B /usr /sys
mount -B /bin /lib
mount -B /tmp /usr

Disclaimer: я не знаю что случится с твоей системой после этого. Но чего-нибудь наверное случится.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

10. "Представлена LittleFS, компактная файловая система для встра..."  –2 +/
Сообщение от Andrey Mitrofanov on 15-Янв-18, 14:31 
>> Структуру LittleFS составляет набор блоков директорий. Каждая директория имеет связанный список ...
>> Поддерживается полный набор POSIX-подобных функций для работы с файлами и каталогами ...
> Чем директория отличается от каталога?

Они MS AD в те двакаслока запилили. Матёрые!

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

12. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от pavlinux (ok) on 15-Янв-18, 14:54 
> LittleFS включает программные средства для выравнивания износа Flash-носителей (wear leveling),
> позволяющие минимизировать повторное использование блоков и равномерно распределить операции
> очистки блоков на Flash-памяти, контроллер которой не обеспечивает решение данной задачи.

Умирать так всем сразу, а не по кускам! :)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

65. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 17-Янв-18, 00:51 
> Умирать так всем сразу, а не по кускам! :)

Если бы это было так, SSD и жесткие диски не выходили бы за пределы фабрик. Там factory defect list - норма жизни. А есть еще grown defect list для обработки артефактов приобретенных в run time. Хотя спору нет, хард умирающий от одного бэда наповал - это прикольно. Если его тебе подсунуть.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Представлена LittleFS, компактная файловая система для встра..."  –3 +/
Сообщение от dss (ok) on 15-Янв-18, 14:59 
Всё, SPIFFS можно выкидывать?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Представлена LittleFS, компактная файловая система для встра..."  –3 +/
Сообщение от Аноним (??) on 15-Янв-18, 16:01 
Описание заинтересовало, но после прочтения design doc быстро разочаровался.

Все описанные в новости преимущества имеют нехилые сайд-эффекты.

Малое потребление памяти компенсируется необходимостью сканировать всю ФС при монтировании (причём, не похоже, что от этого недостатка удастся избавиться).

Исходные предпосылки схемы поддержания целостности и атомарности вообще забавные:

> So how do we go about moving a directory atomically?
>
> We rely on the improbableness of power loss.
>
> Power loss during a move is certainly possible, but it's actually relatively rare.

!!!

И дальше

> And we can easily fix the "moved" directory entry. Since we're already scanning the filesystem during the deorphan step, we can also check for moved entries. If we find one, we either remove the "moved" marking or remove the whole entry if it exists elsewhere in the filesystem.

Т.е. "защита от сбоев" обеспечивается запуском полного fsck при каждом монтировании. Офигеть.

В итоге из всего списка фич автору удалось нормально добиться только снижения Write Cycles на флеше. И то, с полу-юмористической отговоркой про то, что де,

> NAND flash already has many limitations that make it poorly suited for an embedded system

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

35. "Представлена LittleFS, компактная файловая система для встра..."  +1 +/
Сообщение от Crazy Alex (ok) on 15-Янв-18, 19:15 
Ну дык ограниченные ресурсы вообще требуют компромиссов, где-то именно такой подход будет оптимальным. Если штатный режим - "включить и чтобы годами пахало", например, а всё остальное - "должно как-то выдержать", и не более.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

69. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 17-Янв-18, 02:05 
> Ну дык ограниченные ресурсы вообще требуют компромиссов, где-то именно такой подход будет
> оптимальным. Если штатный режим - "включить и чтобы годами пахало", например,
> а всё остальное - "должно как-то выдержать", и не более.

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

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

100. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Crazy Alex (ok) on 23-Янв-18, 14:54 
Во-первых, можно просто разделить - есть железки, куда юзер вообще может попасть, и там - да, так и есть. А есть то, где юзера не может быть в принципе - фирмварь стиральной машины какая-нибудь, грубо говоря.

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

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

81. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Alatar (??) on 17-Янв-18, 11:17 
> Малое потребление памяти компенсируется необходимостью сканировать всю ФС при монтировании
> (причём, не похоже, что от этого недостатка удастся избавиться).

Дык в целевом применении ФС монтируется один раз на старте системы и объём диска - десятки-сотни Мб. Прогнать полный ФСЦК на старте - самое разумное решение.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

21. "Представлена LittleFS, компактная файловая система для встра..."  –2 +/
Сообщение от Аноним (??) on 15-Янв-18, 17:06 
Чем лучше F2FS? Драйвер для винд... ой РеактОС есть?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

67. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 17-Янв-18, 01:06 
> Чем лучше F2FS?

Чем самокат лучше самосвала?

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

68. "Представлена LittleFS, компактная файловая система для встра..."  +1 +/
Сообщение от Аноним (??) on 17-Янв-18, 01:15 
>> Чем лучше F2FS?
> Чем самокат лучше самосвала?

Если подумать, то в киоск за углом или за хлебом сгонять на гироскутере^W самокате сподручнее. Езда по тротуару разрешена. Переулочки и тупики не проблема. Не нужно место под парковку.
Итог -- самокат, особенно с электромотором и складной, всяко лучше самосвала! Ну или аналогии такие аналогии что аж аналогируют в аналоги. Как-то так.


Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

70. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от Аноним (??) on 17-Янв-18, 03:18 
А теперь попробуй на самокате тонну песка на стройку притащить, поймешь в чем прикол с аналогиями.
Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

31. "Представлена LittleFS, компактная файловая система для встра..."  +1 +/
Сообщение от Anonymoustus (ok) on 15-Янв-18, 18:51 
>> структур данных в форме лога

Журнала, а не лога. По-русски это до сих пор называется журналом.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Представлена LittleFS, компактная файловая система для встра..."  +2 +/
Сообщение от RobotsCantPoop on 15-Янв-18, 19:20 
Хотя журнал эт заимствование из французского. Тогда уж вѣдомость.
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

37. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 15-Янв-18, 19:40 
угу, часослов.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

38. "Представлена LittleFS, компактная файловая система для встра..."  +2 +/
Сообщение от Аноним (??) on 15-Янв-18, 20:19 
Дневник же!
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

40. "Представлена LittleFS, компактная файловая система для встра..."  –1 +/
Сообщение от Онон on 15-Янв-18, 21:07 
Летопись!
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

41. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от anomymous on 15-Янв-18, 21:17 
Веснопись, осеньпись, зимопись.
Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

43. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Anonymoustus (ok) on 16-Янв-18, 01:00 
Опись.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

46. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 16-Янв-18, 09:42 
Конфискация
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

49. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Аноним (??) on 16-Янв-18, 16:38 
Будет точнее употребить бухгалтерский термин - оприходование. Опись - не поточный таск.
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

52. "Представлена LittleFS, компактная файловая система для встра..."  +2 +/
Сообщение от pavlinux (ok) on 16-Янв-18, 19:34 
> Будет точнее употребить бухгалтерский термин - оприходование. Опись - не поточный таск.

Берлаги

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

63. "Представлена LittleFS, компактная файловая система для встра..."  +/
Сообщение от Anonymoustus (ok) on 17-Янв-18, 00:46 
Годовой отчёт же!


Какой-то микроб перевозбудился при виде нашего чудного флешмоба и наминусовал. :)

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру