- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
Disk /dev/sdc: 14,46 GiB, 15523119104 bytes, 30318592 sectors
Disk model: Storage Device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdc1 1009664 7802879 6793216 3,2G b W95 FAT32
/dev/sdc2 * 73728 139263 65536 32M 6 FAT16
/dev/sdc3 1 1009664 1009664 493M 85 Linux extended
/dev/sdc5 139264 172031 32768 16M 83 Linux
/dev/sdc6 172032 204799 32768 16M 83 Linux
/dev/sdc7 204800 275455 70656 34,5M 83 Linux
/dev/sdc8 275456 776191 500736 244,5M 83 Linux
/dev/sdc9 776192 976895 200704 98M 83 Linux
/dev/sdc10 976896 1009663 32768 16M 83 Linux
Изначально хотел запихнуть в старый PocketBook515 флешку побольше. Она там хитрая, с линуксом, просто так поменять нельзя. Столкнулся с тем, что не могу parted подвинуть границы раздела, потому что overlapping partitions запрещены. Что делать? вот
Follow us!
16 гигов — это уже SDHC как минимум.
Даже на 4 гига SD без HC приходится разыскивать с собаками. Четырёхгиговые карточки без HC ещё остались на складах, но их продают втридорога.
Полез гуглить. На официальном форуме производителя один чувак спросил, как же так, SDHC с этой моделью работает, а в инструкции написано другое. Производитель ответил, да, работает, но мы всё равно не рекомендуем использовать, мы рекомендуем купить новый фотоаппарат.
Ну что логично. Они на момент выхода фотика не тестировали такие карты, поэтому ты юзаешь на свой страх и риск. В целом оно работает, но на каких-то нюансах запросто может заглючить. Например памяти на список файлов не хватит, лол. Вот и отмазываются.
А так то да, если драйвер SD'шек понимает SDHC, то при том же объёме никаких проблем не должно вылезти. При большем объёме софт и скрипты могут просто охуеть, тут никаких гарантий.
Хорошо, что переполнения переменных при этом не происходит...
Гипотетически после 10-тысячной фотографии счётчик в имени файла может перейти через ноль, и начнут затираться старые фотографии или он перестанет снимать.
Мне кажется, алгоритм 9999 все используют один и тот же, только префикс/постфикс добавляют индивидуальный. Я помню, где-то сделали пять цифр, но ноль просто вшили в префикс. 09999 переходило в 00000 или 00001.
Я не знаю, может ли меняться первая цифра.
Хоть и не в HC дело.
Но судя по остальным разделам включительно.
Бекап только полный сделай, раз с копии не грузится и есть шанс закирпичить нахуй... Ну и почитай что именно показывает fdisk перед тем как лезть.
А то вдруг там от SD карты юзается её "secure" часть и ты соснул с заменой.
f(-1) = 1
f(0) = !f(x-1) = 0
f(1) = !f(x-1) = 1
f(x) = x mod 2 != 0
lim x->inf fx = 1 && 0 = 0
https://linux-sunxi.org/PocketBook_Touch_Lux_2_(626)#Images
Вот здесь есть какие-то наводки, модель другая, но на таком же процессоре sunxi A13
Лол, тут даже говнокоды про этот SoC были.
Ну вот u-boot загрузить было бы прикольно, если ему будет куда консольку показать.
> что это
Да обычный embedded загрузчик, считай что grub без наворотов и с уклоном в инициализацию железа (т.к. bios/uefi который за тебя все сделает нету).
Вот его внутренний fstab
> mv /dev/pvi_ioc /dev/pvi_ioc.prev
> ln -s /dev/zero /dev/pvi_ioc
А что, так можно? Я думал, /dev/zero это какбэ виртуальне фс, файлы в которой создают система и драйвера...
> #temporary link pvi_ioc to /dev/zero
> #temporary
А обратно вернуть забыли
Можно самому создать inode с теми же (1, 5), тогда из него будут читаться нули.
В новых Линуксах inode в директории /dev создаются демоном udev. В старых Линуксах такие файлы создавали вручную.
Вроде ничего не напутал?
Не systemd?
https://man.archlinux.org/man/systemd-udevd.service.8
Raspberry Pi и её клоны во всю юзают... По крайней мере для прототипов и поделок.
В общем-то даже в пылесосах линукс.
У меня более суровые контроллеры, без MMU.
А если взять те контроллеры, с которыми я сталкиваюсь - на некоторые думаю можно поставить Linux ценой долгого пердолинга, но зачем? Ядро Linux дает какие-то там абстракции, типа у меня будут какие-то процессы, какие-то сигналы, файловая система, какие-то пайпы, какая-то хуйня в /dev/ и какие-то системные вызовы... нахуя мне это, если можно делать всё намного более напрямую? И вообще, надо чтоб "история одного байта".
Time to market.
Мозги того же пылесоса, разумеется, можно впердолить в какую-нибудь stm'ку с внешней dram. Но конкуренты в это время хуяк-хуяк и выпустят на прыщах с готовыми либами...
> Ценный конечный продукт (ЦКП) – это параметр, по которому (в частности) судят об эффективности любого специалиста. ЦКП программиста – это качественная и эффективная программа. ЦКП менеджера – это прибыль. Фича в том, что менеджер нанимает программиста, а не наоборот. И мы получаем приоритет прибыли над качеством. И мы жрем это дерьмо с кончика лопаты. И будем продолжать жрать, пока будет существовать этот приоритет.
Поэтому я за пет-проекты и опенсорс без всяких говноменеджеров со всякими там "time to market".
Внимание, вопрос. У кого будет качественнее и эффективнее,
* у программиста, который пердолится под микроко-ко-контроллер, для каждой новой модели пишет новый код , создавая дорогие неподдерживаемые модели, которые мало кто хочет купить,
* у программиста, который имеет поддерживаемый код на ЯВУ с использованием стандартных модулей, который может легко переиспользоваться в новых версиях устройств или обновляться сразу для всей линейки устройств?
Обычный пользователь с бОльшим удовольствием купит девайс, на который могут прийти обновления вроде нейропитушни для распознавания узоров ковра, ведь для производителя это импорт библиотечки и выставление минималок.
Энтузиаст с бОльшим удовольствием купит девайс, в который можно будет впаять побольше памяти/флешку, переустановить луникс, прихреначить дисплей и играть на нём в Тетрис.
Тогда почему все пользователи постоянно ищут "как отключить обновления в винде" и ноют, что nokia 3310 грузилась и работала быстрее и батарейку меньше ела, чем айфон?
Однако это наиболее оптимальная питушня. Другие варианты мы ругали бы больше.
потом надо сорок три минуты ждать после перезагрузки пока установится
Виндобляди соснули! Вот в линуксе проги сходу обновляются.
Правда фф вечно от этого охуевает, разваливается и хочет рестарт (не системы конечно). Но это реально быстрее и меньше бесит, чем полный ребут и ждать процентики.
с веб инитерфейсом на пхп который будет зависать, глючить, и через который поломают твой пылесос в итоге
Причем там не то чтобы дыра какая-то в протоколе или скриптах, просто "ключ" для "подписи" заливаемой прошивки захардкожен.
У чуваков на борту была убунта с openssl, gpg и чем угодно ещё, но они замутили какое-то самодельное говнище.
З.Ы. Такое ощущение, что эти дыры сознательно оставляют для моддеров.
CEO: «нужно сделать чтобы он принимал только наши лицензионные прошивки.»
Инженер: «... ОК ...»
Я видел как питушок реально тужился и высирал свой способ "шифрования" (примерно на шифре цезаря) чтобы его хакир не заснифил.
Имхо, пакеты лучше локально проверять перед установкой.
Я бы не стала полагаться на TLS.
В случае с установкой пакетов и их подпиской конечно нужно пилить PKI: в устройство вшиваешь публичные ключи какого-то своего CA.
Перед запуском проверяешь CRL этого CA.
Потом проверяешь подпись пакета.
Не факт, что нужно именно опенссл, но PKI точно нужен
да, в бизибокс и alpine еще не насрали, но уже скоро
В классическом юниксе у inode был тип (файл, папка, устройство или fifo pipe).
У устройства был мажорный номер, минорный номер и тип "блочное" или "символьное" (в блочное устройство писали блоками по 512 и через буфер, но разделение на блочные и символьные уже частично устарело, в некоторых OS его совсем нет)
Драйвер связявался с мажорным номером, сообщая ядру что вызывать при посылке в это устройство ioctl и всяких write, open итд.
на прыще это делалось так
name это имя устройства в /proc/devices.
Это идеология everything is file.
Создавать файлы устройств (записи в тапблице файлов) можно было через mknod, а на линуксе еще был скрипт ``MAKEDEV`` который большинство устройств умел создавать.
С ядра 2.4 появился devfs, и стало можно делать так:
Тут уже name это устройство в /dev/, то есть драйвер стал сам создавать устройство (примерно как в винде), причем ебаться с номерами стало не нужно: их назначали автоматически.
(продолжение ниже)
Кроме того хотелось уметь загружать/удалять модули при вставке нужных устройств.
стало понятно, что харкдодить такую сложную логику в ядро не нужно.
Тогда запилили udev: ядро стало сообщать про устройства через специальный инетфейс юзердемону, а уже он стал создавать устройства и называть их как настроит пользователь, а также загружать нужные им драйверы динамически (почти как в винде)
Потом пришел поцтеринг и унес udev в systemd-udev.
Потом пришел Девуан и форкнул udev.
Молодцы питухи. Скорее бы добрались до винды и сделали что-то адекватное вместо/поверх c:, d:, e:.
В NT любое устройство можно смонтировать в любой путь.
Их еще держат для совместимости с пользователями винды, которые привыкли, что есть какие-то диски C: D: E:
и для совместимости со всяким скриптоговном, написанным васянами(не имеющим отношения ни к Win95, ни к Win3.x), в которое захардкожены какие-то говнопути к диску C: и которое никто переписывать не будет.
Справедливости ради, в Линуксе ты тоже имена системных каталогов просто так не поменяешь по этой же причине.
оно уже не 32, но миллард бат файлов не могут ошибаться
Имена дисков тянутся из тех времен, когда они были частью API прерываний BIOS.
У NT они ссылки на \Device\HarddiskVolume1, которые насрал менеджер томов
тут дествительно нет понятия "C:", а только лишь fixed disk и diskette
А вот в гайде по досу уже есть
MS-LIB strips the drive designation and the extensionfrom the
object file specification, leaving only the filename. For example, if the object file to be appended as a module to a library is
B:CURSOR.OBJ
causes MS-LIB to strip off the B: and the .OBJ, leaving only
CURSOR, which becomes a module named CURSOR in the
library.
Но как же работает tar -x ... -С /dev ? Или при создании файла в /dev ему автоматически прописывается тип "устройство"? Чтобы все последующие открытия файла уже относились не к данным файла, в которые записаны при первом обращении мажор-минор, а к драйверу?
я думал, ты про архивирование файлов
ты увидишь там мажорный и минорный номера и тип файла и ошибку
```
ar: mem: Cannot mknod: Operation not permitted
tar: Exiting with failure status due to previous errors
```
так что при созданеии файла со спец типом само ядро делает mknod
зато теперь в домашней папке у меня есть файл устройства)
Да не ядро, а сам tar вроде правильные аргументы передает в правильный сисколл? Вряд ли он это через creat делает.
Просто вот такой вот архиватор, знающий про особенности системы. Zip так не умеет, емнип.
В отличие от /sys, /proc и т.п. куда реально монтируется волшебная файлуха с интерфейсами ядра.
Он файлики метров на 10 еле-еле открывает, а ты ему бесконечность подсунуть хочешь...