*nix
C
Комментарии 18
+1

А FreeBSD по своему желанию используете или по служебной необходимости? Интересно, почему не Linux?

+2
Да, по собственному желанию, дома. В 2010, когда захотел создать собственный домашний мини-сервер, попробовал FreeBSD — и влюбился.
+2
Пришёл к FreeBSD аналогичным способом, пользуюсь уже много лет. Не так давно пробовал TrueOS (бывшая PC-BSD): есть интересные решения, но в целом пока не то.
+2
Её огромный плюс (FreeBSD) — это то, что она одна и handbook тоже один.
Поэтому нет такого разброда и шатания, как в линуксе, когда есть различия даже в настройке сети в debian, rhel, а теперь и ubuntu (netplan).
+1
Ну, в этом нет ничего удивительного: FreeBSD — система, а Linux — ядро. Даже между DragonflyBSD, NetBSD и OpenBSD есть некоторые различия. Не знаю, как там в Debian и kFreeBSD, но подозреваю, что даже там натягивание совы на глобус не прошло бесследно. А вот что действительно радует, так это более предсказуемые последствия обновлений, в том числе смены версий.
0
Мне она нравится за стабильность и однозначность. Самая, на мой взгляд, «железная» система. И простая.
0

Планируете ли Вы выложить программу в FreeBSD base или хотя бы в качестве порта?

0
Я пока предпочитаю опубликовать эти два патча (второй скоро будет) на GitHub Gist и предоставить пользователям самим решать, нужно ли оно им. Я не уверен в качестве своего кода, чтобы предлагать его в ядро FreeBSD. Нужно, чтобы профессиональные программисты это поправили.
0

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


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


Мне очень интересен процесс и результат, буду благодарен, если будете его освещать.

+1
Ваш код не затрагивает ядро FreeBSD. Чтобы компетентные люди могли посмотреть и поправить ваш код, нужно оформить его в виде патча и создать баг репорт:
bugs.freebsd.org/bugzilla/enter_bug.cgi

Можно так же написать о вашей идее в список рассылки, например freebsd-hackers: lists.freebsd.org/mailman/listinfo/freebsd-hackers

Чуть более развёрнуто: www.freebsd.org/doc/en/articles/contributing/article.html

Так же для рассмотрения патчей существует phabricator: wiki.freebsd.org/Phabricator
0
За ссылки спасибо. Может быть, когда доведу патч до ума, всё-таки отправлю им. Видите, если отправлять патч команде FreeBSD, нужно его тогда делать универсальным. А значит, как минимум, добавить возможность поиска по атрибутам в system namespace.
+1
Удивительно, что FreeBSD не копирует EA. Даже Windows, где эти EA, вроде бы, никак не используются, командой copy их копирует. (Кстати, если патч для cp ещё не написали, погуглите, уже есть такой для NetBSD.)

И то, что не копирует, портит всю затею, к сожалению. Есть шанс разом потерять все нажитые непосильным трудом теги.
0
Да, я видел патч для NetBSD, и на его основе написал для фряшечки. У NetBSD некоторые нужные функции добавлены в extattr.h напрямую, а я дальше кода cp лезть не хотел.
+2
У меня много интересов, а, поскольку всего не упомнишь, постоянно приходится записывать заметки, рецепты, методики, инструкции и фотографии. Распихивать всё это по папкам — уже нет ни сил, ни времени.

На самом деле, то, что Вам нужно, называется PIM — Personal Information Manager. Поищите на Хабре статью про MyTetra или другие аналоги, например, ZIM, CherryTree...


Я так понимаю, где-то в недрах ФС создаётся мета-файл, намертво связанный с основным файлом, и все метаданные записываются в него

Нет, так делала OS/2 на FAT, и, вроде, делает в каких-то случаях Samba. На современных FS же под это выделены прям вот отдельные блоки данных.


где-то читал, что ограничение на размер расширенного атрибута — 1024 байта, но потом не смог найти эту информацию

Может быть, это на размер одного атрибута, или у самбы… на все атрибуты целиком в случае фревой UFS2 в inode выделено два указателя на блоки, т.е. например при типичном сейчас размере блока fs в 32 Кб это будет 64 Кб.


P.S. Присоединяюсь к предыдущему оратору насчет отправить патч в аптсрим. К сожалению, реальность опенсорс-проектов (кроме самых больших, типа Линукса), что надо самостоятельно пробивать дорогу своим патчам, иначе оно так и останется болтаться на гитхабе, а пользователи о нём даже не узнают. А те, кто узнают, забудут — стоимость поддержки накладывания локальных патчей при апгрейдах такая, что это редко делают...

0
За PIM спасибо, не знал, хотя сам для себя написал что-то подобное на Qt. MyTetra выглядит очень достойно.

Про 64 Кб — важное уточнение. Значит, размер буфера можно смело выставлять в 65536 байт. Дойдут руки до гитхаба — поправлю.

А что касается отправки патча в апстрим — я подумаю. Для начала, тогда нужно будет добавить возможность поиска атрибутов не только в user namespase, но и в system namespace.
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.