Всичко за FreeBSD и деривати

[elementaryos]

13-current вече е фикснат, ако все още те влече към него:
http://pkg.freebsd.org/FreeBSD:13:amd64/latest/

Не ме влече вече, ама ако е оправен- защо не

[Тамболианеца]

Очакваният многострадaлен фикс за 12.1 - релийз дойде:
http://pkg.freebsd.org/FreeBSD:12:amd64/latest/

[Тамболианеца]

Излезе ъпдейт на NomadBSD 1.3.1 до FreeBSD-12.1-p2

https://nomadbsd.org/index.html#1.3.1

[Тамболианеца]

Wi-Fi - Ахилесовата пета на FreeBSD.
Но вече са подходили доста сериозно и са излезли от клишето, че FreeBSD бил ОС само за сървъри.

https://www.phoronix.com/scan.php?page= ... SD-Sponsor

[Fernando Sucre]

Компилацията се проточи 76:30 часа за 12.1 amd64 и приключи преди 12 часа, сега пък синхронизирали сървери.
Голяма хумореска спретнаха, оказва се, че метаинформацията на един-единствен пакет е бил причината да се чупи pkg manager-a. Цялата галимация по компилация е била излишна.
Чукчита некакви.

Нищо, поне от такива случаи системите се подобряват и се вадят големи изводи какво трябва да се гледа в архитектурата.

Цялата тази сага идва да ни напомни едно нещо - всички днешни BSD и Linux OS са cloud vaporware, тежко зависими от инфраструктурни проблеми и Интернет свързаност, и като нищо за дни/седмици можеш да нямаш актуализации или инсталации на OS. A при пълна липса на Интернет при форсмажорни обстоятелства - въобще и да нямаш достъп до съответната ОС.
Може би с полу-изключение на последния мохикан - Debian - единственият, който все още предлага time snapshots на пълното си репозитори компилирано и в сорс, и структурирано на DVD/BR за инсталации и актуализации офлайн. Ако си ги дръпнал, когато е могло, разбира се.

Много точно казано за „vaporware“ -а. Чудя се няма ли най-сетне да заблежат, че въпросния недостатък много ги сваля надолу и да вземат мерки?

И още нещо ми е много чудно - кога най-после ще направят нормалния софтуер да върви на стейбъл, некст и олд-стейбъл версиите. Защото, както е сега и като натегнат зависимостите, излиза че трябва обезателно да си с алфа версия на дистрото за да тестваш/разработваш актуален софтуер! Това никой друг разпространител на софтуер не си го причинява! С книгите също е много проблемно, когато не съществува „твърда земя“ като цяло.

[Тамболианеца]

Няма как това да стане според архитектурата на ОС-а - едни и същи компилирани базови пакети гарантирано да работят и на 11-та, и на 12-та и на 13-та версии на FreeBSD.
ABI гарантира единствено безпроблемната работа на компилирани пакети за всичките минорни версии в цикъла на съществуване на мажорната си версия, т.е. примерно пакет компилиран на 12.0 ще работи гарантирано и с последната в бъдещето 12.4 версия на FreeBSD.
При портовете пък можеш да си компилираш съответния порт към съответната мажорна версия на ОС и отново да си в синхрон с ABI на съответната мажорна версия. При портовете обаче има допълнителен момент, че може и да не тръгнат на старо предишно ABI на мажорната версия, поради спецификата на порта, което е логично и естествено за външна за ОС-а програма, и тогава трябва да се търси предишен стар клон на заветния порт в миналото.

[Fernando Sucre]

Няма как това да стане според архитектурата на ОС-а - едни и същи компилирани базови пакети гарантирано да работят и на 11-та, и на 12-та и на 13-та версии на FreeBSD....

Не че няма как, просто не са обмислили въпроса. Например на iOS апликациите е така - компилира за 4, даже и повече главни версии. При FreeBSD това ще значи около 7 години назад, което е постижимо.

Дори не е казано че обезатлено трябва да се спазят всички тези условия. Може би е ОК да не се подържа олд стейбъл. Може би е ОК за някои много централни компоненти да не се прави. Важното е просто като дръпнеш нещо от нета да има опредлена степен на увереност че ще работи под твойта ос. А не да кръстосваш по 5-6 фактора и да накрая все да не става.
Например, би било много просташко, ако не мога да пробвам ssh-a за 13 версия на мойта 12-ка. Това означава че ако съм бета тестер на ssh, потенциално ще ми трябва отделен диск с алфата на 13-ката, който могат да го скапят по всяко време с някои ъпдейт. А ако е направено нормално - просто ще кача версията за 13-ката, ще тествам и после ще си върна версията от 12-ката, без да настъпва апокалипсис или да компилирам като идиот.

[Тамболианеца]

Кому е нужно да компилира нещо си към повече от 3 версии, след като всичко преди 11.x e EOL?

Как си представяш 'да дръпнеш нещо от нета и то да работи'? Това е BSD, не е като при Линукс - един кърнел за всички и съответно голяма степен на съвместимост на всяко дистро към всяко друго. Та то даже за други BSD се прави портване на съвместимост на програми към FreeBSD - от DagonFly, OpenBSD, NetBSD, камо ли за/от нещо хвърчащо из ИнтернетЯ.

Е, няма начин да правиш девелопмент за бъдещата версия на FreeBSD 13.x без да си 'оцапаш ръцете с нея'. Същото е валидно и за девелопмента в Linux.

[Fernando Sucre]

Кому е нужно да компилира нещо си към повече от 3 версии, след като всичко преди 11.x e EOL?

Примера ми беше за комерсиални нужди, където имат повече от 3 версии в обръщение. На Linux-ите също им трябва, защото издават прекалено често в общия случай.

Как си представяш 'да дръпнеш нещо от нета и то да работи'? Това е BSD, не е като при Линукс - един кърнел за всички и съответно голяма степен на съвместимост на всяко дистро към всяко друго. Та то даже за други BSD се прави портване на съвместимост на програми към FreeBSD - от DagonFly, OpenBSD, NetBSD, камо ли за/от нещо хвърчащо из ИнтернетЯ.

Именно че не си го представям.
Ако си напънат каските, ще излезе че не само е постижимо, а даже не е и трудно. Както казах като за начало може да го карат по-полека. Примерно да компилират старата версия x в настоящата версия на ОС. Ще трябва при download да гледаш коя версия сваляш, но вече ще може да ползваш софтуер от некст и олд стейбъл, въпреки че е бинарно несъвместим. Освен това никой не е казал че обезателно всички програми и библиотеки трябва да са съвместими - за някои ключови може да се направи изключение, тъй като и без това никой няма да ги зарежда кръстосано в реални условия. Нито в случаи на форс мажор, както беше със SSL-a.

Всички успешни комерсиални проекти могат да го правят - бинарна съвместимост за няколко версии. Даже почти се обзалагм, че и в Slackware много от бинарните пакети ще тръгнат на новата версия.

Е, няма начин да правиш девелопмент за бъдещата версия на FreeBSD 13.x без да си 'оцапаш ръцете с нея'. Същото е валидно и за девелопмента в Linux.

Именно! Ако открия бъг в настоящата версия на нещо, не мога просто да пробвам версията от олд стейбъл. Трябва компилация, а компилацията може и да не е успешна, освен че ще ми загуби много време. Същото и за преводача на следващата версия - не може просто да пусне следващата версия, трябва да се занимава с цалата ОС за да си напасне нещата.
Затова цялата тази тъпня трябва да се ограничи до разумни величини. Според мен 3 версии са достатъчни - настоящата, предишната и следващата.

[Mozo]

Офтопик:

Примера ми беше за комерсиални нужди, където имат повече от 3 версии в обръщение. На Linux-ите също им трябва, защото издават прекалено често в общия случай.

Сори за оффа, но в случая е обращение

[Тамболианеца]

Дойде ми Музата да сравня по скорост на зареждане операционните системи от dual-boot-a ми Debian Sid(245) и FreeBSD 12.1
Основата за сравнение:
- двете OS използват един и същ хардуер;
- двете OS са инсталирани самостоятелно на еднакви SSD, както и двете са zfs-on-root;
- имат абсолютно еднаква конфигурация за Десктоп - Xfce;
- всички запуснати сървиси са абсолютно еднакви по тип и като брой, единствената разлика е KVM vs VirtualBox host сървъри;
- всички сървиси са с default-ни параметри и не са tweak-вани по какъвто и да е начин.

Трябва да се отбележи, че реалната имплементация на двете ОС обаче се различава като брой инстанции на конкретно запуснати еднакви сървиси:

Код: Избери всички

Debian Sid 	= 76 ( по данни на systemd )
FreeBSD 12.1	= 32 ( по данни на service )

Методология мерене - класическа (с хронометър)
Зареждане - времето е мерено от избора на менюто в GRUB за съответната OS до финалния екран след login.
Изключване -времето е мерено от натискане бутона Restart на диалоговия прозорец до почерняване на екрана преди BIOS

Резултати:

Код: Избери всички

Debian Sid:	start = 30 sec, stop = 10 sec
FreeBSD 12.1:	start = 28 sec, stop = 28 sec

Изводът е ясен:
По-бързото зареждане на OS чрез паралелизмите на systemd спрямо класическия синхронен rc.d e вече митология, може би защото systemd нашишкаве от лавинообразния увеличаващ се брой инстанции на сървиси - 76 vs 32.

[Mozo]

Е, лесно можеш да си спреш това, което не ти е необходмо

[Тамболианеца]

Прегледах ги аз в Дебиана всичките запуснати, всичко трябва и няма почти нищо за орязване, освен nullmailer.service и ModemManager.service, значи мога да ги смъкна най-много до 74.
При FreeBSD същата работа - само sendmail мога да отрежа и да ги смъкна до 31.

[бат-начо]

Офтопик:

Всъщност, на предварително настроен десктоп спирането на което и да е има обратен ефект. Трябва ровене, за да го няма навсякъде по системата записа и да не се случва "броенето до неизвестност" за нещо несъществуващо. На *бунту е така. Ако тръгнеш да го стоиш от нулата твоя си десктоп - си е както трябва.

[Тамболианеца]

@бат-начо

Да това е така за масовите дистра за десктоп употреба.

Работата е там, че съм изграждал и двете ОС от нулата с добавяне:
- Sid от bootstrap stable заради zfs-on-root, последван от base upgrade to Sid и после добавка всичко останало;
- при FreeBSD e същото, там няма понятието готова инсталация, всичко си го изграждаш от нулата също.
Така че резултат и в двата случая е над 95% компактност на добавени необходими сървиси.