форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
Сообщение от opennews (ok) on 08-Окт-09, 20:03
Официально принято решение (http://www.debian.org/News/2009/20091007) о включении в состав релиза Debian 6.0 (Squeeze) полной поддержки архитектуры kFreeBSD (http://www.debian.org/ports/kfreebsd-gnu/), сочетающей в себе ядро FreeBSD с пользовательским окружением на базе glibc и GNU-утилит. Платформа kFreeBSD будет обеспечена полноценной поддержкой со стороны мантейнеров пакетов, эквивалентной поддержке таких архитектур на базе Linux, как i386, amd64, armel, mips, s390, powerpc и sparc. Релиз Squeeze будет первым в истории гибридным дистрибутивом, поставляемым одновременно с возможностью работы с ядрами Linux и FreeBSD. Основной мотив включения ядра FreeBSD в Debian связан с желанием предоставить пользователям возможность использования таких средств, как пакетные фильтры PF и IPFW2, изолированных окружений jail, сетевой подсистемы NetGraph, поддержки загрузки NDIS (http://ru.wikipedia.org/wiki/NDIS)-драйверов без внешних патчей. С другой стороны, пользователей привыкших к FreeBSD мо... URL: http://www.debian.org/News/2009/20091007 Новость: http://www.opennet.me/opennews/art.shtml?num=23772
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–4 +/–
Сообщение от Iv945n (ok) on 08-Окт-09, 20:03
А как там дела с UTF-8? Как в FreeBSD или как в Linux?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Антон (??) on 08-Окт-09, 20:29
	>А как там дела с UTF-8? Как в FreeBSD или как в >Linux? проблемы только при попытке отображения utf-8 в физической консоли, но кто нынче в консоли работает. При входе по ssh и при запуке X-ов все нормально.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–1 +/–
	Сообщение от QuAzI (ok) on 08-Окт-09, 20:30
	Надо бы знать что тихим сапом в FreeBSD прикрутили UTF-8, будет вам s4'aast'e
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–1 +/–
	Сообщение от Антон (??) on 08-Окт-09, 20:53
	>Надо бы знать что тихим сапом в FreeBSD прикрутили UTF-8, будет вам >s4'aast'e Насколько я знаю, это только во FreeBSD 8. Debian GNU/kFreeBSD на базе FreeBSD 7.2
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–2 +/–
	Сообщение от Iv945n (ok) on 08-Окт-09, 21:33
	>Насколько я знаю, это только во FreeBSD 8. И то вроде не до конца. Помню была новость здесь, так там таки было написано что прикрутили но с каким-то подвохом, с каким конкретно - уже не упомню.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от IvanDurak (??) on 09-Окт-09, 12:19
	>>Насколько я знаю, это только во FreeBSD 8. > >И то вроде не до конца. Помню была новость здесь, так там >таки было написано что прикрутили но с каким-то подвохом, с каким >конкретно - уже не упомню. Подпроект syscons+utf гнездится тут http://wiki.freebsd.org/SysconsUnicodeProject
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+2 +/–
	Сообщение от Ы on 08-Окт-09, 22:57
	>Насколько я знаю, это только во FreeBSD 8. Debian GNU/kFreeBSD на базе FreeBSD 7.2 Вообщето еще в 5-ке, В 6-ых - уже работало яко скала. В 4-ке да - нет и не будет :))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 09-Окт-09, 07:27
	>>А как там дела с UTF-8? Как в FreeBSD или как в >>Linux? > >проблемы только при попытке отображения utf-8 в физической консоли, но кто нынче в консоли работает. При входе по ssh и при запуке X-ов все нормально. Я работаю. И знаю многих кто работает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от kegf (ok) on 09-Окт-09, 08:22
	для физ.консоли можно поставить фреймбуфер терминал, например jfbterm
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	81. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 09-Окт-09, 11:50
	На мой взгляд это опять таки, не совсем верное решение. Зачем мне на сервере (к примеру) ядро с поддержкой фреймбуфера?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	159. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Денис Юсупов on 12-Окт-09, 17:37
	http://www.opennet.me/opennews/art.shtml?num=23809 === Реализован новый консольный драйвер newcons, с поддержкой многобайтовых кодировок в консоли через ремапинг Unicode символов в представление стандартных VGA шрифтов. ===
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
Сообщение от александр (??) on 08-Окт-09, 20:03
проясните ситуацию... это я смогу в граб иметь возможность выбрать с каким ядром загрузиться в данный момент? freeBSD или linux? или как... не понимаю.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Антон (??) on 08-Окт-09, 20:28
	>проясните ситуацию... это я смогу в граб иметь возможность выбрать с каким >ядром загрузиться в данный момент? freeBSD или linux? или как... не >понимаю. нет, там другая архитектура. Это тоже самое, что двойную загрузку i368 и amd64 пытаться делать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Iv945n (ok) on 08-Окт-09, 21:32
	>Это тоже самое, что двойную загрузку i368 и amd64 пытаться делать. А что, никто не делал? Винду ставили так, никсы просто нет смысла т.к. почти весь софт можно скомпилить под 64, но не думал что это так уж сложно должно быть (правда и наборы либ и софта придётся отдельно держать для 64 и 32, но, наверно, можно общие home, var, и т.п. сделать). И Линуксовый бинарный софт (тот же Oracle например) для той же аппаратной платформы под фряхой вполне прикручивается.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–1 +/–
	Сообщение от oops on 08-Окт-09, 22:27
	весь ли софт? а вайн и сдл уже компилятся под x64?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Iv945n (ok) on 08-Окт-09, 22:48
	>весь ли софт? а вайн и сдл уже компилятся под x64? хз, волею судьбы не приходилось углубляться x64 (тем временем вон MS по слухам уже 128-битную винду готовит :-) ) но вроде где-то читал что не без проблем но таки да - вайн для x64 есть.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от аноним on 08-Окт-09, 22:56
	SDL всю жизнь компилилась под amd64. А Wine в любом случае придется под 32бита собирать, при этом никто не запрещает его таким использовать и под 64бита.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	96. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от oops on 09-Окт-09, 14:02
	под фрей? что-то по-моему меньше, чем год назад порты мне показывали фигу
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	106. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от аноним on 09-Окт-09, 16:17
	> под фрей? что-то по-моему меньше, чем год назад порты мне показывали фигу Под фрей. Это починили менее чем год назад, проблема была в тем что ядро не сохраняло сегментные регистры. Теперь все работает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–3 +/–
Сообщение от hatelinux on 08-Окт-09, 20:05
а иного пути примирить пользователей бсд и линукса они не нашли? имхо любое скрещивания разных осей не токо этих это бред возможно у дебиана появилось желание линукс пользователей незаметно перетянуть в бсд тогда одобряю а потом незаметно дебиан откажеться от линукса вообще ))ггг
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Iv945n (ok) on 08-Окт-09, 20:14
	> имхо любое скрещивания разных осей не токо этих это бред Ну не скажи. ZFS, D-Trace (вот это, правда, не знаю портировали ли из Соляры во FreeBSD), PF, и т.п. Вполне можно себе представить ситуации в которых люди хотят иметь эти вещи + полноценное окружение Debian/GNU. > а потом незаметно дебиан откажеться от линукса вообще ))ггг Не дождётесь :-( Попытка уже была - Debian GNU/Hurd, но умерла вскоре после рождения :-( Увы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от Антон (??) on 08-Окт-09, 20:33
	>> а потом незаметно дебиан откажеться от линукса вообще ))ггг > >Не дождётесь :-( Попытка уже была - Debian GNU/Hurd, но умерла вскоре >после рождения :-( Увы. На http://wiki.debian.org/Debian_GNU/kFreeBSD_why есть весьма недвусмысленное заявление: "If you're concerned about running a 100% free system, our commitment to the Debian Free Software Guidelines (DFSG) guarantees that Debian GNU/kFreeBSD doesn't contain any non-free software. In fact, we have removed some non-free binary-only drivers that are contained in the upstream FreeBSD tree, like the ath driver. " Или еще круче: "kFreeBSD offers an alternative in case Linux is branded illegal by the SCO case or other threats. In legal terms, Linux sources are like a minefield. kFreeBSD is much less vulnerable to such attacks because of its less bazaar-like development model."
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–2 +/–
	Сообщение от Iv945n (ok) on 08-Окт-09, 21:18
	>Или еще круче: "kFreeBSD offers an alternative in case Linux is branded >illegal by the SCO case or other threats. In legal terms, >Linux sources are like a minefield. kFreeBSD is much less vulnerable >to such attacks because of its less bazaar-like development model." Во веселуха будет если SCO победит (а видно керосином дело уже реально попахивает, раз Отцы заёрзали), раз и все ломанутся на FreeBSD... По мне так лучше бы на Hurd конечно, но вопреки логике тут я чувствую ещё меньшую вероятность чем победа SCO.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Vitaly_loki (ok) on 08-Окт-09, 20:44
	DTrace портирован, я юзал в FreeBSD 7.2
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	151. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Денис Юсупов on 12-Окт-09, 16:59
	Опишите опыт использования? Технология интересная, но описания [работы во FreeBSD] мало.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	153. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 12-Окт-09, 17:11
	>Опишите опыт использования? Технология интересная, но описания [работы во FreeBSD] мало. Solaris Dynamic Tracing Guide http://wikis.sun.com/display/DTrace/Documentation DTrace on FreeBSD http://wiki.freebsd.org/DTrace
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	158. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 12-Окт-09, 17:35
	>Опишите опыт использования? Технология интересная, но описания [работы во FreeBSD] мало. И тут есть на русском. http://www.sunhelp.ru/categories/7-DTrace
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от Knuckles (ok) on 08-Окт-09, 20:56
	Нет такой ОС "Linux". Есть ОС "GNU Debian", которая в текущих релизах использует ядро "Linux", а со следующего релиза будет иметь 2 ядра на выбор.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от Iv945n (ok) on 08-Окт-09, 21:12
	>Нет такой ОС "Linux". Есть ОС "GNU Debian" Нет такой ОС "GNU Debian". Есть ОС "Debian GNU/Linux" ;-) > которая в текущих релизах использует ядро "Linux", а со следующего релиза будет иметь 2 ядра на выбор. И есть ОС "Debian GNU/kFreeBSD". А ещё теоретически есть ОС "Debian GNU/Hurd". Так что ядра как минимум три и не со следующего релиза а были и раньше и вряд ли на выбор - я таки понимаю что это какбэ отдельные ОС.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от Knuckles (ok) on 08-Окт-09, 21:23
	Да, ты прав. Я только хотел указать, что никакого "скрещивания осей" не происходит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от www2 (ok) on 09-Окт-09, 09:32
	В понятии дебианщиков есть ОС Debian, и не суть важно какое там ядро. Различия для пользователя, админа и программиста минимальны, т.к. все средства конфигурирования, пакетная система, программы и библиотеки те-же. Различия будут только в ядрах (файловые системы, фаерволлы, сетевая подсистема).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–2 +/–
	Сообщение от hatelinux on 08-Окт-09, 21:26
	>Нет такой ОС "Linux". Есть ОС "GNU Debian", которая в текущих релизах использует ядро "Linux", а со следующего релиза будет иметь 2 ядра на выбор. гг теперь дебиан мне напоминает компанию самсунг которая по итогам кризиса выпускает "и туалетную бумагу"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+3 +/–
	Сообщение от Knuckles (ok) on 08-Окт-09, 21:33
	Извини, несмотря на сработавший детектор сарказма, я не понимаю, что ты хочешь сказать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Iv945n (ok) on 08-Окт-09, 21:35
	Я так понимаю что он хочет указать на то, что Дебиан увлёкся диверсификацией.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Knuckles (ok) on 08-Окт-09, 21:53
	>Я так понимаю что он хочет указать на то, что Дебиан увлёкся >диверсификацией. И говорит так, будто это что-то плохое.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
Сообщение от aZ (ok) on 08-Окт-09, 20:16
"cистема конфигурации /etc/network/" О нет, только не это убожество.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	62. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–3 +/–
	Сообщение от pavlinux (ok) on 09-Окт-09, 05:22
	Что, мозг ниасилил /etc/network/* :-Ъ
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	95. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от aZ (ok) on 09-Окт-09, 13:54
	"Осиливать" в то там нечего, просто неудобное громоздкое говно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	97. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–2 +/–
	Сообщение от www2 (ok) on 09-Окт-09, 14:24
	>"Осиливать" в то там нечего, просто неудобное громоздкое говно. ifupdown - это network manager. Прописал настройки в /etc/network/interfaces, добавил по вкусу в /etc/network/ip-[up|down].d/ скрипты, которые нужно выполнить при поднятии интерфейса (или повесил команду на pre-up, post-up, pre-down, post-down), сделал ifup интерфейс и всё заработало. Сделал ifdown - и всё связанное с этим интерфейсом удаляется (в том числе, например фаерволльные правила, таблицы маршрутов, демоны). А во фре слабо то же самое сделать, чтобы при поднятии/опускании интерфейса выполнялась куча связанных операций? Костыли devd не предлагать - это не сетевой менеджер, этак и в Debian можно всё сделать средствами udevd. Или слабо при поднятии интерфейса определить по ARP-пингу, находимся ли мы в одной сети или в другой, и в зависмости от этого применять одни или другие сетевые настройки? Причём нужно наглядно, а не самописными скриптами с изобретением велосипедов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	99. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–1 +/–
	Сообщение от aZ (ok) on 09-Окт-09, 14:48
	ifupdown и есть ваш велосипед на костылях. Чем он отличается от самописных скриптов? Его кто-то не писал, он "автописный" или как? Какие конкретные преимущества помимо встроенной кофеварки? Если через devd/udevd можно это делать, то на кой чёрт писать велосипед? Ничего дебильного как ваш арп-пинг или тоже запоминание названия интерфейса по мак адресу я ещё не видел. Это уже прямо винда - засирать в /etc (!) автоматом какое-то дерьмо типа "очень нужной штуки" - параметры сетевой карты. Для каждой сети я единоразово пишу скриптики с добавлением адреса на интерфейс, роутинга или же просто запускаю дшсц-клиента если не знаю настройки сети. Трудно сообразить тебе в какой же ты сети? Дома, в офисе или в кафе? Но просто даже в жизни, банально - прописать альясы на интерфейс в /etc/network/interfaces - это уж извините, придумать такой убогий синтаксис нужно ещё постараться.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	102. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от ram_scan on 09-Окт-09, 15:19
	А чем там убогий синтаксис ? Весь кайф в том, при дебианском подходе можно апдейтить любые скрипты, включая системные, и ничего у вас не отвалится, потому-что скрипты самописные и системные связаны только документированными подергушками и больше никак друг от друга не зависят. А то я помню, как когда был еще молодой, зеленый, и еще не носил очков, прописал в красношляпе еще тогда создание виланов по "фряховски", в скрипте. Как какое-то писание нагугленое велело. И грохнулось все мое творчество после автообновления какой-то сетевой приблуды, которая rc.network фикшеный подложила, уж не вспомню какой, вместе с виланами. С той поры я в гробу видел хоть одну букву в системных скриптах исправлять.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	103. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от aZ (ok) on 09-Окт-09, 15:38
	Прописывать альясы убого. :) "Кайф" в дебияне относителен. Лично когда я работал (в принципе и сейчас работаю, ставлю на очень дешёвые, не важные сервера, где хостер не хочет ставить фрибсд) с дебияном меня бесили автоматические скрипты после установки/обновления софта. Вот на кой чёрт запускается тот же апачь или нгингс сразу после установки? Неужели разработчики действительно думают, что нормальный человек будет использовать то, как оно по дефолту настроено? Или вот почтовик был на цирусе.. ну и после обновления цируса оно почему-то решает сделать chown на все файлы почтовой базы, а то что база там на десятки гигабайт и пока оно раздаст уже разданные права пройдёт не один час, а почтовик "вежливо" остановлен - разработчикам такого "умного" скрипта в голову не пришло. По поводу грохнулось - это честно говоря у меня уже автоматом в сознании - так и должно быть на линуксе, ничего особенного. Как говорится - благими идеями проложена дорога в ад. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	104. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–1 +/–
	Сообщение от www2 (ok) on 09-Окт-09, 15:50
	>ifupdown и есть ваш велосипед на костылях. Чем он отличается от самописных >скриптов? Тем, что он хорошо отлажен и в нём есть заготовки на большинство типовых случаев. >Его кто-то не писал, он "автописный" или как? Какие конкретные >преимущества помимо встроенной кофеварки? Если через devd/udevd можно это делать, то >на кой чёрт писать велосипед? На кой чёрт /etc/rc.conf, если настройки можно делать скриптами в /etc/rc.local? Аналогия ясна? >Ничего дебильного как ваш арп-пинг или >тоже запоминание названия интерфейса по мак адресу я ещё не видел. А ничего дебильнее прыгающей нумерации сетевушек в вашей фре я не видел. Стоят три сетевушки одинаковой модели: rl0, rl1, rl2. Вынимаем вторую, вставляем ещё одну, но другой модели и что мы видим? rl0, rl1, xl0. Вперед, переписывать в трёхстах местах название интерфейса. Или алиасики на сетевушки припедаливать через devd. >Это уже прямо винда - засирать в /etc (!) автоматом какое-то >дерьмо типа "очень нужной штуки" - параметры сетевой карты. Если переместить настройки udev в /var, как это сделано в RedHat, ты успокоишься? >Для каждой сети я единоразово пишу скриптики с добавлением адреса на интерфейс, >роутинга или же просто запускаю дшсц-клиента если не знаю настройки сети. На каждый случай свой велосипедный скриптик. А на каждый пакет, с сособым наборам зависимостей, собираешь из портов. Продолжай тратить время. >Трудно сообразить тебе в какой же ты сети? Дома, в офисе >или в кафе? Пришёл из офиса в кафе, заюзал su, и давай редактировать udev и самописные скриптики? >Но просто даже в жизни, банально - прописать альясы на интерфейс в >/etc/network/interfaces - это уж извините, придумать такой убогий синтаксис нужно ещё >постараться. Ты про это? auto eth2:0 iface eth2:0 inet static         address 10.3.17.1         netmask 255.255.255.0 Это убогий синтаксис? Да, конечно ifconfig_rl0_alias0="inet 10.3.17.1/24" гораздо лучше. А если так: auto eth2:0 iface eth2:0 inet static         address 10.3.17.1         netmask 255.255.255.0         up echo "eth2:0 up" > /root/log         down echo "eth2:0 down" > /root/log То ты уже полез в дебри devd.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	108. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от aZ (ok) on 09-Окт-09, 16:22
	> На кой чёрт /etc/rc.conf, если настройки можно делать скриптами в /etc/rc.local? Аналогия ясна? На то, чтот там запускаются уже готовые скрипты, а rc.local то что нет в скриптах, всё просто и логично. Нумерация сетевух не прыгает. Она логично раставляется чем мне и нравится. Более того - сменив сетевуху в дебияне - сменится и интерфейс, а вы поди не знали? Причём сменится автоматом каждый раз при новой сетевухе и вот тут уж менять правила или прыгать с бубном вокруг этого автоматического определения новой сетевухи и ручками править имя интерфейса. > Если переместить настройки udev в /var, как это сделано в RedHat, ты успокоишься? Успокоюсь когда на кернел.орг сделают rm -rf / > На каждый случай свой велосипедный скриптик. Чем плохо? Оно работает и отлично, чем "универсальные" которые работают через раз и не так как хочется. > Пришёл из офиса в кафе, заюзал su, и давай редактировать udev и самописные скриптики? Ну если вам делать нечего - можете этим заниматься. А я просто запускаю /root/bin/network-home, /root/bin/network-office /root/bin/network-имя_кафе, очень просто. > Ты про это? Да, про это. А то что показал дальше - я ни в одном страшном сне даже делать не буду. Просто в 99.9% это не нужно. Хотя что вам говорить, вы же не знаете что фря по дефолту логирует поднятие интерфейса в /var/log/messages
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	114. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (??) on 09-Окт-09, 17:08
	>> На кой чёрт /etc/rc.conf, если настройки можно делать скриптами в /etc/rc.local? Аналогия ясна? > >На то, чтот там запускаются уже готовые скрипты, а rc.local то что >нет в скриптах, всё просто и логично. Ну так и ifupdown - тоже готовый скрипт, а всё, чего в нём нет, помещается в /etc/network/ip-[up|down].d, "всё просто и логично". >Нумерация сетевух не прыгает. Она логично раставляется чем мне и нравится. Более >того - сменив сетевуху в дебияне - сменится и интерфейс, а >вы поди не знали? Причём сменится автоматом каждый раз при новой >сетевухе и вот тут уж менять правила или прыгать с бубном >вокруг этого автоматического определения новой сетевухи и ручками править имя интерфейса. Да, поменять привязку названия интерфейса к мак-адресу в конфиге udev - для вас непосильная задача. >> Если переместить настройки udev в /var, как это сделано в RedHat, ты успокоишься? > >Успокоюсь когда на кернел.орг сделают rm -rf / В таком случае ПНХ, дальше разговаривать с тобой не о чем. >> На каждый случай свой велосипедный скриптик. > >Чем плохо? Оно работает и отлично, чем "универсальные" которые работают через раз >и не так как хочется. Рассказывай давай. Ты же и про пакет resolvconf поди тоже не знаешь. auto eth0 iface eth0 inet static         address 10.0.0.1         netmask 255.255.255.252         dns-nameservers 10.2.0.1 10.3.0.1 auto eth1 iface eth1 inet dhcp auto provider iface bis inet ppp         provider provider А теперь внимание, вопрос. Как ты своими велосипедными скриптами будешь изменять содержимое файла /etc/resolv.conf, да ещё чтобы учитывались приоритеты DNS-серверов в таком порядке eth1, eth0, provider (прописываются через /etc/resolvconf/interface-order), да ещё чтобы об изменении файла /etc/resolv.conf узнавали squid и named (при этом named чтобы делал форвардинг DNS-запросов на этот список именно в указанном порядке). Время пошло. >> Пришёл из офиса в кафе, заюзал su, и давай редактировать udev и самописные скриптики? > >Ну если вам делать нечего - можете этим заниматься. А я просто >запускаю /root/bin/network-home, /root/bin/network-office /root/bin/network-имя_кафе, очень просто. Что делать мне? 0. Один раз настроил 1. Пришёл в кафе - заработал инет, 2. Пришёл на работу - заработал инет, 3. Пришёл домой - заработал инет, 4. Повторил по желанию любой из пунктов 1, 2, 3 сколько угодно раз и в любой последовательности, 5. ... 6. PROFIT! >> Ты про это? > >Да, про это. А то что показал дальше - я ни в >одном страшном сне даже делать не буду. Просто в 99.9% это >не нужно. Хотя что вам говорить, вы же не знаете что >фря по дефолту логирует поднятие интерфейса в /var/log/messages HINT: В правилах up и down может стоять любая команда, а в каталогах /etc/network/if-[up|down].d/ может лежать любой скрипт. А заготовки вроде "dns-nameservers 10.2.0.1 10.3.0.1" позволяют иногда и вовсе обойтись без велосипедных скриптов с ручным приводом и при этом добиваться очень сложного поведения системы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	118. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от aZ (ok) on 09-Окт-09, 17:50
	Ты чудик. Ты придумываешь решение проблем которые не существуют. Более того, очень я сомневаюсь что твои супер скрипты автоматом цепляют вайфай в моменты когда оно нужно. Или ты в кафешке заказываешь кофе с кабелем? Или какую-то софтину для инвалидов запускаешь? В ней то поди что-то ищешь и потом "кликаешь" что-то чтобы законнектиться. Да уж, элегантное решение, лучше чем запустить уже подготовленную для этого команду. P.S. днс я использую свой и в /etc/resolv.conf у меня прописан 127.0.0.1, доверять чёрти каким серверам у меня никогда не было желания, а также из-за специфики моей работы мне не нужен чужой кеш запросов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	123. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (ok) on 09-Окт-09, 18:12
	>P.S. днс я использую свой и в /etc/resolv.conf у меня прописан 127.0.0.1, >доверять чёрти каким серверам у меня никогда не было желания, а >также из-за специфики моей работы мне не нужен чужой кеш запросов. Ты ещё скажи что сам начиная с корневиков DNS-запросы решаешь. Короче всё ясно - "у меня есть всё, что нужно, а чего нет - то и не нужно".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	135. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от QuAzI (ok) on 10-Окт-09, 23:06
	>>P.S. днс я использую свой и в /etc/resolv.conf у меня прописан 127.0.0.1, >>доверять чёрти каким серверам у меня никогда не было желания, а >>также из-за специфики моей работы мне не нужен чужой кеш запросов. > >Ты ещё скажи что сам начиная с корневиков DNS-запросы решаешь. Короче всё >ясно - "у меня есть всё, что нужно, а чего нет >- то и не нужно". Я что-то не понял в чём проблема. Вы вдвоём какую-то проблему из пальца высосали и со смаком обсасываете. Выбрал себе два-три DNS-сервера, которые нормально работают, прописал их адреса однажды и забыл о ваших проблемах. И они у меня работают не зависимо от того, использую я беспарольный dialup, ADSL, точку wifi в кафешке или gprs - ОНИ ВСЕГДА ДОСТУПНЫ в инете. Более того, в своё время у провайдера работали какие-то укурки, благодаря которым адреса DNS-серверов выдавались через раз и чтобы нормально сёрфить по инету приходилось их прописывать их статично на любых ОС. Благодаря этим укуркам я на память помню два DNS-сервера - для работы хватает, доступны всегда, работают отовсюду, где есть доступ в интернет. Где доступа по дефолту нет (домосеть и рабочая локалка) - DHCP умные люди придумали ДАВНО. Лениво мне ещё какие-то ваши настройки, скрипты ковырять... стар я уже для этого =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	211. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Дмитрий Ю. Карпов on 23-Окт-09, 11:52
	> Ты ещё скажи что сам начиная с корневиков DNS-запросы решаешь. Он вообще держит у себя копию содержимого корневой зоны.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	213. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 23-Окт-09, 14:13
	>> Ты ещё скажи что сам начиная с корневиков DNS-запросы решаешь. > >Он вообще держит у себя копию содержимого корневой зоны. Да, но он забывает про домены второго, третьего и т.д. уровней. Кажется я начинаю догадываться, что может означать фраза "скачать весь интернет".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	215. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 23-Окт-09, 14:17
	>>> Ты ещё скажи что сам начиная с корневиков DNS-запросы решаешь. >> >>Он вообще держит у себя копию содержимого корневой зоны. > >Да, но он забывает про домены второго, третьего и т.д. уровней. Кажется >я начинаю догадываться, что может означать фраза "скачать весь интернет". А помните лет восемь (?) назад был большооой DDoS корневых серверов? Теперь мы знаем виновника!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	120. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от аноним on 09-Окт-09, 18:01
	Вы ниже очень хороший термин употребили - `восторженный хомячок'. По этому сообщению он вам на 100% соответствует, между тем FreeBSD позволяет делать все абсолютно то же самое. Хотя я лично не понимаю зачем все это надо, у меня на ноуте прописано ifconfig_xxx=DHCP, и с этим у меня работает сеть без каких-либо телодвижений, как дома по проводу, так и где угодно по wifi.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	124. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (ok) on 09-Окт-09, 18:14
	>Вы ниже очень хороший термин употребили - `восторженный хомячок'. По этому сообщению >он вам на 100% соответствует, между тем FreeBSD позволяет делать все >абсолютно то же самое. Только кучей велосипедных скриптов, уже знаем. >Хотя я лично не понимаю зачем все это надо, у меня на >ноуте прописано ifconfig_xxx=DHCP, и с этим у меня работает сеть без >каких-либо телодвижений, как дома по проводу, так и где угодно по >wifi. То, что у вас чего-то там работает - ни разу не показатель. Продолжая мысль, "А меня всё есть. А чего нет - то не нужно." Мне нужно, а у вас нет. Или есть, но надо писать скрипты. Как быть? Это преимущество?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	129. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от iZEN (ok) on 09-Окт-09, 21:40
	>>Вы ниже очень хороший термин употребили - `восторженный хомячок'. По этому сообщению >>он вам на 100% соответствует, между тем FreeBSD позволяет делать все >>абсолютно то же самое. > >Только кучей велосипедных скриптов, уже знаем. Какие такие "велосипедные скрипты" в FreeBSD? Новые hot-plug(!) интерфейсы поднимаются devd: при втыкании-вытыкании USB-адаптера, при втыкании-вытыкании Ethernet-кабеля выполняется определённый "велосипедный скрипт", если он(внимание!) специально ОЧУМЕЛЫМИ_РУКАМИ прописан в /etc/devd.conf. А если скрипт не прописан (что естественно на незамусоренной системе), то и подниматься нечему при хот-плаге какой-то железки. Все остальные интерфейсы жёстко прописываются в /etc/rc.conf и получают настройки при старте системы или же во время её работы (DHCP). Ещё тут нафантазировал о смене адресации сетевушек при выдёргивании одной из них -- бред. Если есть несколько однотипных сетевух, использующих один драйвер, то в /etc/rc.conf их интерфейсы привязывают к MAC-адресам и они уже никак не перепутываются. "eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	152. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Денис Юсупов on 12-Окт-09, 17:05
	> в /etc/rc.conf их интерфейсы привязывают к MAC-адресам Это где/как там такое?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	177. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от sHaggY_caT (ok) on 17-Окт-09, 20:17
	>"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими >разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ. Это называется "ниасилить" :))) И это как раз про упоминавшихся уже хомячков :) В тех же RH-системах в /etc/sysconfig/network-scripts/ifcfg-бла-бла есть опция HWADDR, которая по-дефольту верно выставляется Анакондой. Встречный вопрос фряховодам: fstab(5) Linux,   =============================================        Instead  of  giving  the  device explicitly, one may indicate the (ext2 or xfs) filesystem that is to be mounted by its        UUID or volume label (cf.  e2label(8) or xfs_admin(8)), writing LABEL=<label> or  UUID=<uuid>,  e.g.,  ‘LABEL=Boot’  or        ‘UUID=3e6be9de-8139-11d1-9106-a43f08d823a6’.   This  will  make  the system more robust: adding or removing a SCSI disk        changes the disk device name but not the filesystem volume label. ============================================ туда же можно писать девайсы lvm и md, которые сами (by design) нормально привязываются к железкам fstab freebsd (тоже 5), где там хоть что-то аналогичное? Может быть, я не замечаю? Да, девайсы геома привязываются нормально, но вот с одиночными дисками, и, особенно, с LUN аппаратных контроллеров, это _проблема_ Вопрос не праздный, и, хотя и с подколкой, ответ мне очень интересен, я бы хотела оказаться не правой и чего-то не осилевшей, так как приходится работать со фрей, но пока недостатки by design по нумерованию железок, простите, вижу не у Linux'а
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	178. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 18-Окт-09, 01:55
	>>"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими >разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ. > >Это называется "ниасилить" :))) И это как раз про упоминавшихся уже хомячков >:) >В тех же RH-системах в /etc/sysconfig/network-scripts/ifcfg-бла-бла есть опция HWADDR, которая по-дефольту верно >выставляется Анакондой. Товарищъ имел ввиду, что индексы к сетевым интерфесам вычисляются последовательно +1 c нуля, по мере обхода всего дерева шин-устройств c dev_probe()/dev_attach(). pcib1@pci0:1:0: class=0x060400 card=0x00008086 chip=0x29f18086 rev=0x01 hdr=0x01 pcib2@pci0:6:0: class=0x060400 card=0x00008086 chip=0x29f98086 rev=0x01 hdr=0x01 pcib3@pci0:28:0:        class=0x060400 card=0x00000000 chip=0x29408086 rev=0x02 hdr=0x01 pcib5@pci0:28:2:        class=0x060400 card=0x00000000 chip=0x29448086 rev=0x02 hdr=0x01 pcib6@pci0:28:3:        class=0x060400 card=0x00000000 chip=0x29468086 rev=0x02 hdr=0x01 pcib7@pci0:28:4:        class=0x060400 card=0x00000000 chip=0x29488086 rev=0x02 hdr=0x01 pcib8@pci0:28:5:        class=0x060400 card=0x00000000 chip=0x294a8086 rev=0x02 hdr=0x01 ... uhci0@pci0:29:0:        class=0x0c0300 card=0x31fe103c chip=0x29348086 rev=0x02 hdr=0x00 uhci1@pci0:29:1:        class=0x0c0300 card=0x31fe103c chip=0x29358086 rev=0x02 hdr=0x00 uhci2@pci0:29:2:        class=0x0c0300 card=0x31fe103c chip=0x29368086 rev=0x02 hdr=0x00 uhci3@pci0:29:3:        class=0x0c0300 card=0x31fe103c chip=0x29398086 rev=0x02 hdr=0x00 .. bge0@pci3:4:0:  class=0x020000 card=0x703e103c chip=0x167814e4 rev=0xa3 hdr=0x00 bge1@pci3:4:1:  class=0x020000 card=0x703e103c chip=0x167814e4 rev=0xa3 hdr=0x00 Это универсальная логика для всех устройств, и для понимания просто где какой интерфейс нужно знать имя класса устройства, и его порядок данных устройств на шине при опросе. Для PCI это по степени удаления слота от моста. Добавил карту такого же класса на ту же шину перед существующей - подумай, сдвинь индекс +1 в настройках. Автомагичность по hw-адресам - нафик-нафик... От лукавого это, лишнее. Змеи еще какие-то, анаконды... Шинно-классово-древовидную топологию устройств придумали давно, если не изменяет память еще в Беркли в 80-x, писатели Linux kernel таки решили толи выпендрится, то ли от великого ума, и сделали именование network interfaces гм... другим. >Встречный вопрос фряховодам: fstab(5) Linux, Гм... После "фряховодам" отвечать не хочется... :| Ответил - значит "фряховод" :) Хотя такой зоопарк иной раз в проекте бывал... >Вопрос не праздный, и, хотя и с подколкой, ответ мне очень интересен, >я бы хотела оказаться не правой и чего-то не осилевшей, так >как приходится работать со фрей, но пока недостатки by design по >нумерованию железок, простите, вижу не у Linux'а Таки тебе недостатки искать, или работать? :) # man glabel ...      This class also provides volume label detection for file systems.  Those      labels cannot be set with glabel, but must be set with the appropriate      file system utility, e.g. for UFS the file system label is set with      tunefs(8).  Currently supported file systems are:            ·   UFS1 volume names (directory /dev/ufs/).            ·   UFS2 volume names (directory /dev/ufs/).            ·   UFS1 file system IDs (directory /dev/ufsid/).            ·   UFS2 file system IDs (directory /dev/ufsid/).            ·   MSDOSFS (FAT12, FAT16, FAT32) (directory /dev/msdosfs/).            ·   CD ISO9660 (directory /dev/iso9660/).            ·   EXT2FS (directory /dev/ext2fs/).            ·   REISERFS (directory /dev/reiserfs/).            ·   NTFS (directory /dev/ntfs/).      Support for partition metadata is implemented for:            ·   GPT labels (directory /dev/gpt/).            ·   GPT UUIDs (directory /dev/gptid/).      Generic labels are created in the directory /dev/label/. ... Собственно, этого более чем хватает что бы "пилевать" на шинную адресацию, SCSI LUN, ATA CH, USB ADDR, ... Опознание-отображение делается по все иерархии GEOM. Указание корня при загрузке в соотв. glabel так же возможно, man loader. Естественно, даже если корень на другом физическом диске относительно загрузчика и считанного в память ядра.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	179. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 18-Окт-09, 02:10
	>>>"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими >разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ. >> >>Это называется "ниасилить" :))) И это как раз про упоминавшихся уже хомячков >>:) >Собственно, этого более чем хватает что бы "пилевать" на шинную адресацию, SCSI >LUN, ATA CH, USB ADDR, ... Опознание-отображение делается по все иерархии >GEOM. >Указание корня при загрузке в соотв. glabel так же возможно, man loader. >Естественно, даже если корень на другом физическом диске относительно загрузчика и >считанного в память ядра. И вдогонку - если сделаешь FS whole disk # newfs -L suberlabel /dev/ad2 то этикетка диска также будет опознана Можно придумывать даже странные топологии (не пробовал :) ), типа UFS in BSD slice in MBR in GPT - и этикетка также будет опознана, даже если ты выставишь тип раздела для UFS вместо 165 - 6, MSDOS.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	180. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 18-Окт-09, 15:07
	>Шинно-классово-древовидную топологию устройств придумали давно, если не изменяет память еще в Беркли >в 80-x, писатели Linux kernel таки решили толи выпендрится, то ли >от великого ума, и сделали именование network interfaces гм... другим. "Тихо сам с собой я веду беседу". А там глядишь, кто и прочитает :) Но самому захотелось освежить в памяти, и посмотрел код - BSD 2.9..2.11 (~82-93гг,DEC PDP11), - BSD4.2-4.4 (~82-94гг, DEC VAX) и - Linux kernel 1.0...1.3 (~93-96гг,Intel i386). Действительно, имена драйверов в его дескриптор struct somedev_softc{} были введены примерно в 83-84 году. 4.2BSD, фрагменты: --- /*      if_en.c 6.1     83/07/29        */ #include "en.h" /* * Xerox prototype (3 Mb) Ethernet interface driver. */ struct uba_driver endriver =         { enprobe, 0, enattach, 0, enstd, "en", eninfo }; struct  en_softc {         struct  ifnet es_if;            /* network-visible interface */         struct  ifuba es_ifuba;         /* UNIBUS resources */         short   es_delay;               /* current output delay */         short   es_mask;                /* mask for current output delay */         short   es_lastx;               /* host last transmitted to */         short   es_oactive;             /* is output active? */         short   es_olen;                /* length of last output */ } en_softc[NEN]; enattach(ui)         struct uba_device *ui; {         register struct en_softc *es = &en_softc[ui->ui_unit];         es->es_if.if_unit = ui->ui_unit;         es->es_if.if_name = "en";         es->es_if.if_mtu = ENMTU;         es->es_if.if_init = eninit;         es->es_if.if_output = enoutput;         es->es_if.if_ioctl = enioctl;         es->es_if.if_reset = enreset;         es->es_ifuba.ifu_flags = UBA_NEEDBDP | UBA_NEED16 | UBA_CANTWAIT; #if defined(VAX750)         /* don't chew up 750 bdp's */         if (cpu == VAX_750 && ui->ui_unit > 0)                 es->es_ifuba.ifu_flags &= ~UBA_NEEDBDP; #endif         if_attach(&es->es_if); } --- Благодаря именованию появилась возможность собирать устойства c одним драйвером в субклассы вне зависимости от шинной топологии, и в дальнейшем - и вне зависимости от типа шины (1982-83гг и по настоящее время). В Linux kernel 1.3 (~1996г) данное именование напрочь отсутствует. Почему Торвальдс (или T&К?) в 93-94гг решил примитивно именовать сетевые интерфейсы в соотвествии с type of network frame of level 2 - аллах акбар, не знаю. Может просто потому что плохо знал-понимал основы сетевой коммуникации? :) Теперь "linux-кульное поколение" говорит что это фича, и придумывает AI-костыли для обхода косяков непродуман... пардон - базарной архитектуры. А модифицировать механизм ассоциации некому, и много зацепок вылезает, да и бардак в драйверах, там воистине китайская классификация - "животные делятся на шестиногих, драконов, летающих, принадлежащих Императору, ...". Поверх это громоздится HAL, с ничем кроме Linux kernel нормально не работающая... "Кино и немцы". --- PS К вопросу об имени UNIX/BSD, репринт этикетки с ленты: Back of tape:         4.3 RENO        6250 VAX         30 JUL 90        Distribution Master Front of tape:         4.3BSD-RENO Vax UNIX System 7/1/90         7 files on tape         1 bootstrap FS,  bs=1024         2 mini root,  bs=10240         3 root dump,  bs=10240         4 /usr         5 /usr/src         6 /usr/src/sys         7 /usr/src/contrib На других аналогично, в 80-е писали просто - BSD lalala UNIX.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	184. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 19-Окт-09, 13:03
	>>Шинно-классово-древовидную топологию устройств придумали давно, если не изменяет память еще в Беркли >>в 80-x, писатели Linux kernel таки решили толи выпендрится, то ли >>от великого ума, и сделали именование network interfaces гм... другим. Каким другим? Если заглянуть в /sys/, то можно увидеть ту самую шинно-классово-древовидную топологию. >Благодаря именованию появилась возможность собирать устойства c одним драйвером в субклассы вне >зависимости от шинной топологии, и в дальнейшем - и вне зависимости >от типа шины (1982-83гг и по настоящее время). Какой в этом практический смысл? Сказать: "вот в линупсе - куйня, там все Ethernet-интерфейсы называются eth, а в бздях - круто, там всё по драйверам"? Если очень приспичит изменить наименование устройств и привести его в соответствие со стилем именования FreeBSD, то конфиг udev вам в руки и барабан на шею - именуйте как хотите, хоть по имени драйвера - для этого есть ключ DRIVER. >В Linux kernel 1.3 (~1996г) данное именование напрочь отсутствует. >Почему Торвальдс (или T&К?) в 93-94гг решил примитивно именовать сетевые интерфейсы в >соотвествии с type of network frame of level 2 - аллах >акбар, не знаю. Может просто потому что плохо знал-понимал основы сетевой >коммуникации? :) Просто потому что пользователю накуй не сдалось знать, что за драйвер рулит устройством. Пользователь воткнул модем - появилось ppp, воткнул Ethernet-карточку - появилось eth, настроил SLIP или PLIP - появилось sl или plip, запустил программу, эмулирующую сетевой интерфейс - появилось tun или tap. Всё логично. Конечно, если устройство не определилось - тогда желательно знать его название, чтобы драйвер искать. Но если определилось - то какая уже разница, каким драйвером? >Теперь "linux-кульное поколение" говорит что это фича, и придумывает AI-костыли для обхода >косяков непродуман... пардон - базарной архитектуры. Не понял, а что не продумано-то? Схему именования устройств можешь переопределить любым нравящимся тебе способом - конфиг udev в руки. >А модифицировать механизм ассоциации некому, и много зацепок вылезает, да и бардак >в драйверах, там воистине китайская классификация - "животные делятся на шестиногих, >драконов, летающих, принадлежащих Императору, ...". Классифицировать можно по разным признакам. Одно и то же устройство может быть одновременно "летающим" и "принадлежащим Императору". А то, что они в Linux именно "делятся на" - это ваша буйная фантазия. >Поверх это громоздится HAL, с ничем кроме Linux kernel нормально не работающая... HAL вообще к Linux никаким боком не относится. Это продукт жизнедеятельности FreeDesktop. Давайте уж не будет обвинять Linux во всех смертных грехах. В популярности HAL виноваты пользователи KDE, Gnome и прочих "интегрированных" с HAL'ом систем. Я HAL'ом в Linux не пользуюсь. Немного неудобно, поскольку проторенных дорожек тут похоже нет, но магистральная линия HAL мне претит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	201. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 22-Окт-09, 13:05
	>>>Шинно-классово-древовидную топологию устройств придумали давно, если не изменяет память еще в Беркли >>>в 80-x, писатели Linux kernel таки решили толи выпендрится, то ли >>>от великого ума, и сделали именование network interfaces гм... другим. > >Каким другим? Если заглянуть в /sys/, то можно увидеть ту самую шинно-классово-древовидную топологию. Начало шинной организации уже хорошо прослеживается в Unix V7 (1979г), и четко прописано в Беркелейских BSD UNIX (1982г и далее). Но писал именно о именах собственных интерфейсов. struct dev_softc {} в BSD 1983 г. уже содержит поле собственного имени драйвера, в Linux kernel 1996г. его нет, нет и по сей день. >>Благодаря именованию появилась возможность собирать устойства c одним драйвером в субклассы вне >>зависимости от шинной топологии, и в дальнейшем - и вне зависимости >>от типа шины (1982-83гг и по настоящее время). > >Какой в этом практический смысл? Сказать: "вот в линупсе - куйня, там >все Ethernet-интерфейсы называются eth, а в бздях - круто, там всё >по драйверам"? Это уже фантазии. Написал, то что написал. Каждый при желании может сравнить код самостоятельно. А практически - имя интерфейса, наименование модуля, структура в памяти ядра, и название исходного текста содержит один и тот же индекс-имя, который легко запоминается или записывается. Есть _система_ именования. /boot/kernel/if_ae.ko /usr/src/sys/dev/ae/if_ae.c # ifconfig ae0 ae0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 # devinfo -v | grep ae             ae0 pnpinfo vendor=0x1969 device=0x2048 subvendor=0x1043 subdevice=0x8233                 class=0x020000 at slot=0 function=0 # pciconf -l | grep ae ae0@pci0:3:0:0:    class=0x020000 card=0x82331043 chip=0x20481969 rev=0xa0 hdr=0x00 Что мы имеем в Linux kernel device/net, начиная с 90-х? Относительно "причесанности" BSD это выглядит как свалка разностильного кода, слегка упорядоченная. И это не повод для "криков" "linux дерьмо, bsd рулит". Просто немного труднее разобратся в системе при необходимости, добавить код или поправить. Драйвера сразу из воздуха же не появляются? >Если очень приспичит изменить наименование устройств и привести его в соответствие со >стилем именования FreeBSD, то конфиг udev вам в руки и барабан >на шею - именуйте как хотите, хоть по имени драйвера - >для этого есть ключ DRIVER. Так можно и новую систему написать. А че - барабан на шею... :) 200 тыс строк для начала, потом добъем остальные... >Просто потому что пользователю накуй не сдалось знать, что за драйвер рулит >устройством. Пользователь воткнул модем - появилось ppp, воткнул Ethernet-карточку - появилось >eth, настроил SLIP или PLIP - появилось sl или plip, запустил >программу, эмулирующую сетевой интерфейс - появилось tun или tap. Всё логично. Простая якутская логика. Вот Солнце, вот море, вот снег... Пользователь воткнул модем? И появилось... что? Потому что модем как бы в самом низу DSL протоколы, а выше него ATM (если ADSL, или HDLC какой-нить), а выше либо с PPP, либо Eth, либо PPPoEth. Так как нам именовать интефейс, таки dsl, atm, ppp или eth? Пользователь воткнул другой модем... Теперь как именовать - ppp или gprs, или edgi? А тут был создан туннель - интерфейс как назвать, gre или ipip? Опять включаем простую якутскую логику? :) Когда в 90-х код linux ядра писался, да и по сей день, о пользователях кто-то думает? :) Не смешите мои тапочки. Если бы не получал/скачивал linux-рассылки в оригинале, то еще бы может и поверил. Там сплошной жастофан товарищей. И не товарищи из RedHat, не Caldera, ни все остальные особо переписывать ничего не собирались. Просто юзают жаcтофан как есть. >Конечно, если устройство не определилось - тогда желательно знать его название, чтобы >драйвер искать. Но если определилось - то какая уже разница, каким >драйвером? А если определилось, но не работает как задумывалсь? Не, это ньюансы все конечно, но из них и складывается эволюция технической системы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	202. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 22-Окт-09, 13:45
	Так и вижу разгуливающего вправо-влево перед доской старого пердуна с лысиной и убранными за спину руками, который начитывает студентам лекции. Старый пердун, разумеется, не знает, что иногда академические построения расходятся с инженерной практикой. А потому иногда инженеры забивают на архитектурную красоту, а делают вещи, которые работают _уже_ _сейчас_, а не заработают потом, когда прояснятся детали правильной архитектуры. Вот Эндрю Танненбаум как мечтал о правильной архитектуре, так до сих пор и мечтает. На Minix 3 портированы SDL, браузер Dillo и OSS. Теперь на Minix 3 можно слушать "Hello, this is Linus Torvalds, and I pronounce Linux as Linux!", смотреть на интернет с квадратиками вместо непонятных браузеру букв и играть в Super Tux'а. Вот Ричард Столлман мечтал о правильной архитектуре, начиная Hurd. Так и до сих пор не могут решиться, какая же архитектура более красива - по типу Mach-ядра или по типу L4-ядра. Подыхает перед выбором, как буриданов осёл. Вот авторы Unix'а, Кен Томпсон, Деннис Ричи и свежая кровь Роб Пайк, которые наконец довели концепцию Unix до совершенства и сделали сначала Plan 9, а затем и Inferno. Вот разработчики NetBSD и pkgsrc, портировать которые на новую процессорную архитектуру вместе со всеми дровами и программами - дело пары дней. Вот Тео ДеРадт, со своей OpenBSD безопасной по самое не хочу и правильными инструментами вроде pf, openntpd, openbgpd и прочих. Вот разработчики FreeBSD со своей правильной и красивой архитектурой в виде унифицированного CAM, GEOM и NetGraph, ZFS. И с правильно названными именами сетевых интерфейсов типа rl0, ae1 и прочими. Хорошая архитектура - вещь полезная, но Linux - это паровоз всего свободного ПО. Пока академики сравнивают стотысячную красивую архитектуру с каждой из предыдущих, дроча на какой-то один конкретный аспект красоты этой архитектуры, Linux пробует каждую архитектуру и уделяет меньшее, но более равномерное внимание всем аспектам красоты. Прыгает, спотыкается, встаёт, кружит на месте, набивает шишки, синяки и болячки, но всё равно идёт впереди остальных.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	203. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 22-Окт-09, 13:58
	>Хорошая архитектура - вещь полезная, но Linux - это паровоз всего свободного >ПО. Пока академики сравнивают стотысячную красивую архитектуру с каждой из предыдущих, >дроча на какой-то один конкретный аспект красоты этой архитектуры, Linux пробует >каждую архитектуру и уделяет меньшее, но более равномерное внимание всем аспектам >красоты. Прыгает, спотыкается, встаёт, кружит на месте, набивает шишки, синяки и >болячки, но всё равно идёт впереди остальных. Вот именно поэтому Windows всё ещё самая популярная ОС, между прочим. Идёт впереди остальных. Хотя когда-то была всего лишь зачуханной оболочкой для DOS (да, да, я знаю, что NT — это совсем другая песня, но тогда об NT и речи не было), которая тоже прыгала, спотыкалась, но как-то работала. А потом всё-таки сдохла. В самом Microsoft признают, что Windows через некоторое время умрёт. Но и Linux умрёт тоже. Где-то в течение 10 лет наступит время совсем других разработок, связанных, в том числе, и с представляющими ныне больше маркетинговый «пф-ф-ф» облаками. Google уже просёк тренд, Apple тоже. Microsoft, очевидно, тоже, но они темнят успешнее всех. Так что все умрут, :) останутся лишь отточенные в «красивых проектах» идеи, которые и лягут в основу новых решений.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	205. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 22-Окт-09, 16:36
	>Хорошая архитектура - вещь полезная, но Linux - это паровоз всего свободного >ПО. Пока академики сравнивают стотысячную красивую архитектуру с каждой из предыдущих, >дроча на какой-то один конкретный аспект красоты этой архитектуры, Linux пробует Mach2,3,4 - проекты дали жизнь многим идеям и разработкам, использованных в других системах. Wiki/Google. Если не ошибаюсь, nextStep был основан BSD4.4+Math3. Проблема была вполне логически-техническая - чрезмерно высокие затраты на обработку сообщений между компонентами, IPC. --- Пока писал с перерывами на работу :) freebsd# grep -l 'Mach Operating System' /usr/src/sys/vm/* /usr/src/sys/vm/pmap.h /usr/src/sys/vm/vm_contig.c /usr/src/sys/vm/vm_fault.c /usr/src/sys/vm/vm_glue.c /usr/src/sys/vm/vm_init.c /usr/src/sys/vm/vm_kern.c ... Итого - 17 файлов из 44, значительная часть системы управления памятью. --- Minix3 - совершенно новый проект. Ему по техническим меркам от году неделя. Показывает неплохие результаты, затраты на IPC намного меньше чем в Math - ~6% Minix3 и ~15-80% по разным инкарнациям Math, в сравнении с работой ~того же кода в ядерном режиме. Не столь большая стоимость за устойчивость. pf, bgpd, ipsec портированы из OpenBSD в другие системы. Действительно, компактный и устойчивый код. ну и так далее... Да, с помощью кода Linux kernel от рабатывается много идей, и хороших. Но в чем проблема, причем корни ее уходят в саму идеологию разработки. Fast & dirty. Сейчас работает - и ладно. И можно забыть. Нет вдумчивого пересмотра, нет вдумчивой идеологии с запасом на будущее. Только появился LVM1 (только - по проектно-техническим меркам), как уже обкатывается LVM2, со структурой c LVM1 несовместимой. Только-только устаканился Xen - все, извините, в новых ядрах его не будет. Наигрались, объявили устаревшей технологией. И так далее... Нет приемственности и переноса кода даже внутри проекта Linux kernel. И очень плохие возможности переноса кода ядра в другие системы. Этого как бы и не предусматривается в техничеcкой постановке задач на компоненты. Есть только kernel, и все другое пусть идет лесом. Большинство кода, составляющего дистрибутивы (приложения), с успехом может работать и с другим ядром. И неисключено, что наступит момент, когда 350Mb+ кода ядра будет проще "покрасить и выбросить", чем использовать в новой инкарнации. И очередное поколение будет говорить "Linux - старье, L'alix - это ново, это круто, вереди планеты всей". Не исключено, что (а почему бы и нет?) этой основой станет тот же Minix3,4,5. Распиаренный "паровоз" - это да.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	206. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от sHaggY_caT (ok) on 22-Окт-09, 18:02
	>Fast & dirty. Сейчас работает - и ладно. И можно забыть. Нет >вдумчивого пересмотра, нет вдумчивой идеологии с запасом на будущее. >Только появился LVM1 (только - по проектно-техническим меркам), как уже обкатывается LVM2, >со структурой c LVM1 несовместимой. >Только-только устаканился Xen - все, извините, в новых ядрах его не будет. >Наигрались, объявили устаревшей технологией. >И так далее... Эта модель разработки не мешает промышленной эксплуатации :) старые RHEL3 и RHEL 4 будут поддерживаться еще несколько лет (при том, что RHEL 3 на 2.4 ядре!), в четвертый RHEL все еще добавляются новые фичи из последних ядер, а Xen будет поддерживаться (включая развитие функционала) как минимум до 2014. Стоит разделять инновационный проект kernel.org, и тестовые дистрибутивы для гиков, и таки револиционного развития платформы, как Gentoo, Arch, Fedora, и то, что используется в промышленности (RHEL, SLE, Oracle Unbreakable Linux, даже Ubuntu LTS, хотя и с натяжкой) В последних опробованная технология как раз используется годами :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	207. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 22-Окт-09, 20:23
	>Эта модель разработки не мешает промышленной эксплуатации :) старые RHEL3 и RHEL >4 будут поддерживаться еще несколько лет (при том, что RHEL 3 Промышленная эксплуатация в промышленности, давайте не будем путать a) вспомогательные дата-центры, рабочие станции и b) автоматизированные системы управления и контроля производственными линиями.   Хранилище с бухгалтерскими данными - это еще не промышленность, хотя и очень важная задача :) Шутка. RH - коммерческое предприятие. Бизнес циничен. Бизнес-мэн заинтересовано в получении прибыли, и все его остальные действия вытекают из этого. В развитие именно kernel RH, Ltd. заинтересовано ровно в той степени, насколько это будет приносить прибыль. И если разработчики kernel вдруг решать объявить переход на что-то version Б, несовместимой с версией А, то это повод лишний раз для заработать, скажем, подписав на бинарные пакеты, или продавая иной свой сервис по своим маркетинговым каналам-сети. По похожей схеме наше изменчивое законодательство дает возможность заработать массе 1С-программистов. Впрочем, могу ошибатся, естественно. И RH занимается исключительно благотворительностью :) И коммерческий саппорт RH нисколько не меняет ситуации с портативностью кода kernel в другие системы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	208. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от sHaggY_caT (ok) on 23-Окт-09, 00:39
	>RH - коммерческое предприятие. Бизнес циничен. Бизнес-мэн заинтересовано в получении прибыли, и >все его остальные действия вытекают из этого. >В развитие именно kernel RH, Ltd. заинтересовано ровно в той степени, насколько >это будет приносить прибыль. Да, это именно так, но что это меняет? >И если разработчики kernel вдруг решать объявить переход на что-то version Б, >несовместимой с версией А, то это повод лишний раз для заработать, >скажем, подписав на бинарные пакеты, или продавая иной свой сервис по >своим маркетинговым каналам-сети. Ну да, все-таки деньги управляют этим миром. Это может нравится, может не нравится, но это так. >Впрочем, могу ошибатся, естественно. И RH занимается исключительно благотворительностью :) Нет, конечно, зачем им это? Но их заказчики так же не занимаются благотворительностью, а решают свои бизнес-задачи. Я написала пример про именно таки промышленные системы (есть такое устойчивое словосочетание в российской ИТ-среде, может быть, не до конца отражающее суть), что бы показать, что модель разработки kernel.org никак не мешает эскплуатации Linux в серьезных системах, даже наоборот :) >И коммерческий саппорт RH нисколько не меняет ситуации с портативностью кода kernel >в другие системы. А это нужно kernel.org? Если Вы внимательно посмотрите на список коммитеров в линуховое ядро, там сплошь корпорации и крупные конторы, индивидуальные разработчики, конечно, не в меньшинстве, но тон задают крупные компании. Только что в этом плохого? Тот же Yahoo! сделал очень и очень много хорошего для проекта FreeBSD. Возможно, это эгоизм. Но GPL вообще эгоистическая лицензия, больше защищающая вендора, чем потребителя, может быть, это правильно, и более жизнеспособно?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	209. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 23-Окт-09, 10:05
	>не в меньшинстве, но тон задают крупные компании. Только что в >этом плохого? Тот же Yahoo! сделал очень и очень много хорошего Да, отчасти, думаю, вы конечно правы. (Лирика за утренней чашкой чая, уж позвольте :) ) Немного присматриваюсь к эволюции технических систем, программные компоненты "живут" вообще без году неделя - 35-40 лет. Был нулевой период переключателей, был первый период RT11, RTRS, RSX, DOS, NetWare и прочих, теперь период UNIX&NT, далее дело (опять) идет к модульно-системно-распределенным системам локально, в одном шасси & стойке, кампусе & городе, ... Kernel еще будет существовать долгое время, но эта программная архитетура быстро дошла до своего плато развития, и либо будет тщательно реинкарнирована - кодом и архитекурой кода, либо плавно уйдет за многие (и возможно, весьма-весьма многие) годы со сцены. Параллельно будет развиватся и эволюционировать неcколько BSD систем, мигрируя кодом между проектами, и интуитивно делаю вывод, не более, за этой мета-веткой большие перспективы. Параллельно будут развиватся и возникать и другие проекты, как пробники идей и специализированные & портативные системки... Про коммерческие тенденции молчу, там такой кавардак & бордель, бордель в квадрате :) Поживем, увидим. Надеюсь, решающими будут все таки не "деньги" как общественная условность (и не жадность :) ), а таки _здравые_ чувства и намерения наиболее талантливых и деятельных из людей.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	212. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от sHaggY_caT (ok) on 23-Окт-09, 14:02
	>Kernel еще будет существовать долгое время, но эта программная архитетура быстро дошла >до своего плато развития, и либо будет тщательно реинкарнирована - кодом >и архитекурой кода, либо плавно уйдет за многие (и возможно, весьма-весьма >многие) годы со сцены. > >Параллельно будет развиватся и эволюционировать неcколько BSD систем, мигрируя кодом между проектами, >и интуитивно делаю вывод, не более, за этой мета-веткой большие перспективы. Это уже вопрос религии :) Мне же, наоборот, кажется, что схема роста ради роста (революционного прогресса) стоит того, что бы ее сохранить. Вопрос же приемственности кода, смерти FreeBSD, OpenBSD, NetBSD да и Linux в их нынешнем виде, конечно, лишь вопрос времени. Что там будет в облаках за платформа, никто не знает... >наиболее талантливых и деятельных из людей. :) Или что бы чувства и желания наиболлее талантливых людей совпали с бизнес-устремлениями:))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	204. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 22-Окт-09, 14:24
	>Пользователь воткнул модем? И появилось... что? >Потому что модем как бы в самом низу DSL протоколы, а выше >него ATM (если ADSL, или HDLC какой-нить), а выше либо с >PPP, либо Eth, либо PPPoEth. Так как нам именовать интефейс, таки >dsl, atm, ppp или eth? По канальному уровню, доступ к которому предоставляет устройство, естественно. Если поверх Ethernet можно передавать IP-пакеты, это не значит что теперь сетевая карточка должна именоваться ip0. Из-за того, что все дружно забили на уровни модели OSI, чётко этот уровень бывает и не определить. >Пользователь воткнул другой модем... Теперь как именовать - ppp или gprs, или >edgi? Точно так же - по канальному уровню, предоставляемому устройством компьютеру. >А тут был создан туннель - интерфейс как назвать, gre или ipip? В зависимости от того, какой это туннель. >Опять включаем простую якутскую логику? :) Да, опять включаем простую якутскую логику и придумываем двух- или трёхбуквенное название, в котором иной раз даже нет ни одной буквы, совпадающей с моделью устройства. >А если определилось, но не работает как задумывалсь? Как к этому относится вопрос именования интерфейса? Если работаёт не так, как вами задумывалось, можете поменять название интерфейса на fuck0. >Не, это ньюансы все конечно, но из них и складывается эволюция технической >системы. А Linux развивался не эволюционным, а революционным путём.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	210. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 23-Окт-09, 10:36
	>А Linux развивался не эволюционным, а революционным путём. "Я плакалъ" :) Все, ует, умыт и сражен. На этот аргумент сказать ответить нечего :) "Долгих 15 лет изнурительной революции, в результате которых была получена совершенно уникальная и не имеющая аналогов кострукция велосипе... управления памятью, шинами, устройствами, процессами, файловые системы, набор системных вызовов, ... Именно благодаря этой революционной конструкции, написанной на уникальном языке SI, удалось применить ранее написанные GNU&PNU-утилиты, применит огромное число революционных проектов, таких как Imacs, Torzilla, Z11, lendmail, ..."
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	214. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от sHaggY_caT (ok) on 23-Окт-09, 14:14
	>[оверквотинг удален] > >Все, ует, умыт и сражен. На этот аргумент сказать ответить нечего :) > > >"Долгих 15 лет изнурительной революции, в результате которых была получена совершенно уникальная >и не имеющая аналогов кострукция велосипе... управления памятью, шинами, устройствами, процессами, >файловые системы, набор системных вызовов, ... Именно благодаря этой революционной конструкции, >написанной на уникальном языке SI, удалось применить ранее написанные GNU&PNU-утилиты, применит >огромное число революционных проектов, таких как Imacs, Torzilla, Z11, lendmail, ..." > Нет, "за долгие 15 лет эволюции" была создана платформа, которая с успехом заменила, в большинстве случаев, коммерческие UNIX'ы. Где в BSD кластерные файловые системы? Где нормальные контейнеры (извините, но jails по сравнению с OVZ, тем более PVC, и даже с Solaris Zones выглядит просто неубедительно и смешно), где, в конце концов, нормальная тяжелая виртуализация? Почему в качестве Dom0 все ведущие мировые вендоры используют Linux, а не NetBSD, в крайнем случае, Solaris? Где аналог своего гипервизора, как KVM Linux? Где прямая бинарная пакетная система? Извините, но я вижу глобальное отставание BSD платформы, сейчас ощущается рывок (в семерке фрибсд появились некоторые вкусные вещи), но... как-то бесконечно далеко. Все новшества, это бэкпорт фич Solaris, в котором не смотря на явный застой развитие видно...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	217. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 23-Окт-09, 15:19
	>Нет, "за долгие 15 лет эволюции" была создана платформа, которая с успехом >заменила, в большинстве случаев, коммерческие UNIX'ы. Очень хорошо. Меня просто порадовала фраза "Linux - революционная система" :) Обсуждение с позиции "А где в системе Ъ возможность Тыдыц, А?!!! Почему не сделали?!!!", извините, считаю неконструктивным. Займитесь и сделайте. Или бартером :) А теперь задайтесть вопросом, почему указанные вами подсистемы (виртуализации, кластеризации, прочей ации) не задумывались как портативные? Причины - техническая недограмотность, амбиции, эгоцентризм, вполне понятный недостаток сил и средств, прочее?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	218. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от iZEN (ok) on 23-Окт-09, 18:25
	>Нет, "за долгие 15 лет эволюции" была создана платформа, которая с успехом >заменила, в большинстве случаев, коммерческие UNIX'ы. >Где в BSD кластерные файловые системы? Известно где -- у проприетарщиков, которые код не дают, но используют FreeBSD. А что? Имеют право. >Где нормальные контейнеры (извините, но jails >по сравнению с OVZ, тем более PVC, и даже с Solaris >Zones выглядит просто неубедительно и смешно), O_o, а Solaris Zones уже научилось делать вложенные Zones, как это умеет jail2? Чем OVZ лучше jail?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	219. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от sHaggY_caT (ok) on 23-Окт-09, 19:15
	>[оверквотинг удален] > >Известно где -- у проприетарщиков, которые код не дают, но используют FreeBSD. >А что? Имеют право. Где я могу купить FreeBSD с параллельной файловой системой с репликацией между нодами, как междельмашовская проприетарная GPFS? Так, что бы держала массивные load'ы? Если нигде, то это просто слова) >>Где нормальные контейнеры (извините, но jails >>по сравнению с OVZ, тем более PVC, и даже с Solaris >>Zones выглядит просто неубедительно и смешно), > >O_o, а Solaris Zones уже научилось делать вложенные Zones, как это умеет >jail2? Zones единственные из контейнеров, которые умеют запускать Virtual Enviroment с другими ОС, не совпадающими с базовой. >Чем OVZ лучше jail? Если коротко, то всем: это абсолютно несравнимые технологии:) Для PVC это вообще разгром: SLM в дополнение к UBC менеджменту, VZFS с OS и аппликешн темплейтами, нормальный менеджмент уровня дата-центра через PIM/VZCP (готовое решение для бэкапов, управления тысячами физических серверов, темплейтами и несметным количеством контейнеров) OVZ (PVC это все так же, конечно, умеет): - live migration - чекпоинт (сохранение состояния контейнера в дамп и восстановление в любой момент, в том числе на другом физическом сервере) - Жесткий менеджмент ресурсов всех Virtual Enviroments(память, cpu, лимиты, приоритеты, барьеры по выделению ресурсов - если ресурса избыточно, ядро поделится им  с остальными контейнерами, если это разрешено для этих контейнеров), двухуровневый CPU планировщик, внутри контейнера можно сделать renice:), даже есть виртуализация PID'ов процессов (у init'а каждого контейнера, внутри его Enviroment, номер 1) - двухуровневая дисковая квота (внутри VE поддерживаются свои квоты и acl так, как будто это не VE) - Приоритеты по i/o для процессов контейнера (к сожалению, пока нет лимитов), контейнерам с массивными запросами к диску можно дать меньше disk time - Свой пакетный фильтр для каждого контейнера (я про iptables) - Вообще, виртуализированный сетевой стек (что там с IP адресами у jails?), три вида сетевых интерфейсов у контейнеров (быстрый venet, почти "настоящий" veth с мак-адресами и arp-таблицами, физические интерфейсы машины, на которой крутится контейнер) - Поддержка подавляющей части системных вызовов абсолютно прозрачно для ПО (например, bind ставится и работает искоропки в chroot) - Невероятная плотность, достигающая 50-ти контейнеров на одном средненьком физическом сервере, постоянно находящихся под нагрузкой, и, в целом, не мешающих друг другу, и даже более 100-150 в случае быстрой дисковой подсистемы резюме: это просто не сравнимые технологии, как несравнима, например, 3BSD с семеркой, а уже на базе VZ созданы LXC с их аппликейшн контейнерами(которые, правда, пока так же не стоит использовать в production как FreeBSD 8 c ZFS), оставание, мне кажется, уже безнадежное.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	220. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 23-Окт-09, 23:42
	>находящихся под нагрузкой, и, в целом, не мешающих друг другу, и >даже более 100-150 в случае быстрой дисковой подсистемы Умничаете, да? Листовку нафигачили... :) Шутка. Вы же все равно наверняка в работе пользуетесь тем чем пользуетесь, и ничем иным. И подобные прокламации  рассматриваю не более чем рационализацию исторически сложившегося хода событий. Но если вы действительно интересуетесь, обработка вызова jail в FreeBSD 8 сильно переделана. В сочетании с остальными возможностями (jailed sockets/route/ipfw, virt. ip-stack, secure level, zfs quota, system quota, ...) конструкция получается вполне отвечающая техническому заданию на изоляцию (скажем, для хостера), с учетом ограничений самой идеи chroot-переростка. Без бантиков, но то уж звиняйте. Кому шо бильше треба. Небольшой документ про jail, объясняющий некоторые моменты реализации: http://docs.freebsd.org/44doc/papers/jail/jail.html Документация http://www.freebsd.org/cgi/man.cgi?query=jail&sektion=8 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ja... Ну а насчет быстро и впереди планеты всей... Тараканы тоже быстро бегают :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	216. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 23-Окт-09, 14:29
	>[оверквотинг удален] >"Я плакалъ" :) > >Все, ует, умыт и сражен. На этот аргумент сказать ответить нечего :) > > >"Долгих 15 лет изнурительной революции, в результате которых была получена совершенно уникальная >и не имеющая аналогов кострукция велосипе... управления памятью, шинами, устройствами, процессами, >файловые системы, набор системных вызовов, ... Именно благодаря этой революционной конструкции, >написанной на уникальном языке SI, удалось применить ранее написанные GNU&PNU-утилиты, применит >огромное число революционных проектов, таких как Imacs, Torzilla, Z11, lendmail, ..." Не надо утрировать. Я имел в виду, что во-первых в Linux никогда не было унаследованного кода - весь код изначально был написан "с нуля". Во-вторых, я имел в виду то, что разработчики Linux не боятся пробовать новые решения. Сколько было попробовано и переписано фаерволлов, сколько файловых систем устройств, сколько менеджеров управления томами, сколько подсистем модулей ядра, сколько планировщиков процессов? Пока лагерь *BSD не спешит заменять хорошее на более хорошее, Linux делает это. После нескольких итераций в Linux появляется лучшее, и тут уже приходят люди из *BSD, посмотревшие на все мытарства, и заменяют хорошее сразу на лучшее. Сейчас Linux вышел на некое плато, где он практически не развивается. Пишутся новые драйверы, переписываются отдельные небольшие подсистемы, но в целом ядро Linux уже несколько лет как созрело. Большинство разных направлений перепробовано, в них найдены лучшие решения. Цена превосходства - может быть несколько бардачный код и сравнительно большое количество ошибок. Что будет дальше? Возможно код Linux будет подвергнут рефакторингу, а возможно будет пущен под нож на детали для нового ядра с GPL-совместимой лицензией.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	195. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от sHaggY_caT (ok) on 19-Окт-09, 20:13
	>"Тихо сам с собой я веду беседу". А там глядишь, кто и прочитает :) Прочитала:) >>>"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими >разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ. Типичная ситуация: есть стандартная серверная архитектура, есть стандартные сетевые карточки, и все такое прочее, которые случайно (например, при замене платформы вместе с карточкой) могут быть ткнуты не туда и не так. Правильная архитектура это лишь повод для гордости девелоперов и фанатиков, системным администраторам все равно, что там внутри ядра :) В этой ситуации нумерация девайсов по шине просто не нужна. Нужен параметр в ether в rc.conf (не важно, будет он ставится sysinstall или скриптом при PXE заливке системы), нужна прогрессивная система конфигурации /etc/network(c), нужна Anaconda >Автомагичность по hw-адресам - нафик-нафик... От лукавого это, лишнее. Змеи еще какие-то, >анаконды... Не нравится, ставьте руками :) Это же не Windows, а "прогрессивная система /etc/network". sysinstall, Anaconda, и т д >Что за змея? Почему не знаю? Есть новый POSIX-стандарт на змей? Думаете на слово "sysinstall" нельзя придумать что-то подковыристое? >[оверквотинг удален] >     Generic labels are created in the directory >/dev/label/. >... > >Собственно, этого более чем хватает что бы "пилевать" на шинную адресацию, SCSI >LUN, ATA CH, USB ADDR, ... Опознание-отображение делается по все иерархии >GEOM. >Указание корня при загрузке в соотв. glabel так же возможно, man loader. >Естественно, даже если корень на другом физическом диске относительно загрузчика и >считанного в память ядра. Что мне не нравится во всем этом, так это то, что уже просетапленную систему без переформатирования дисков нельзя привести к предсказумому, при перетасовки дисков, виду. Для крупных сетей, когда все серверы стандарные и шаблонные это, обычно, не актуально, а вот для мелких... Да и для крупных: приняли новый сервер на баланс, просетапленный просто на слайсы, пока его сервисы не перетащат на стандарные серверы, залитые по PXE-шаблонам компании, может случится все что угодно :( А про нумерацию девайсов, в Linux это by design делается в UDEV/DeviceKit. Кто и где сказал, что девайсы обязательно должны нумероваться кёрнелем? Если это было так в дремучих временах Денниса Ричи и Ко с Bell Labs & AT&T, с тех пор уже прошли десятилетия! Может быть, юзер-мод конфигурялки часто удобнее? СТоит вспоминить тот же pf и сравнить его с исключительно ядерным iptables, тут как раз сравнение очень не в пользу iptables по функционалу и гибкости. Вспомнить тот же УГ, который называется IIS(много ему дал ядерный листенер)?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	196. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 19-Окт-09, 23:16
	>такое прочее, которые случайно (например, при замене платформы вместе с карточкой) >могут быть ткнуты не туда и не так. Поменять ifconfig_ab0 на ifconfig_bc0 в одном файле при старте - минутное дело. Учитывая, сколько занимает возня в аппаратной зачастую - это мгновение :) >Правильная архитектура это лишь повод для гордости девелоперов и фанатиков, системным администраторам все равно, что там внутри ядра :) Извините, это посредственным администраторам - все равно. К сожадению, таких много, если не подавляющее большинство. Грамотно спроектированная система быстрее познаваема, и в общем за счет более четкой структуры (ошибок меньше) более устойчива. Но это все лирика. >Не нравится, ставьте руками :) Это же не Windows, а "прогрессивная система >/etc/network" Наверное, становлюсь старым ретроградом :) >Что мне не нравится во всем этом, так это то, что уже >просетапленную систему без переформатирования дисков нельзя привести к предсказумому, >при перетасовки дисков, виду. Кто вам такое сказал? Labels in GPT, UFS, названия томов ZFS легко меняются, естественно, в отмонтированной FS. После устаканивания меток меняйте диски на той же SCSI как хотите - монтирование будет производится по меткам (именам томов). # gpart modify -i N -l suberlabel # tunefs -L /dev/adXpN # zpool export oldname; zpool import oldname newname #mount /dev/ufs/suberlabel /mnt #zfs import suberpoolname C ZFS есть ньансы по монтированию, нужно привыкнут к другой методике. Автомонтирование можно не использовать. >Для крупных сетей, когда все серверы стандарные и шаблонные это, обычно, не >актуально, а вот для мелких... >Да и для крупных: приняли новый сервер на баланс, просетапленный просто на >слайсы, пока его сервисы не перетащат на стандарные серверы, залитые по >PXE-шаблонам компании, может случится все что угодно :( Извини, не понял ситуацию. Вечер, голова совсем глупый. >А про нумерацию девайсов, в Linux это by design делается в UDEV/DeviceKit. >Кто и где сказал, что девайсы обязательно должны нумероваться кёрнелем? Если >это было так в дремучих временах Денниса Ричи и Ко с >Bell Labs & AT&T, с тех пор уже прошли десятилетия! И так, и не так. Шинная архитектура как была так и осталась. Граф устройств как был, так и есть. Появились новые уровни абстракции (в FreeBSD это CAM & GEOM), но в его ближнем к аппаратуре слое логика ядра так или иначе отражает аппаратное устройство. >Может быть, юзер-мод конфигурялки часто удобнее? СТоит вспоминить тот же pf и >сравнить его с исключительно ядерным iptables, тут как раз сравнение очень >не в пользу iptables по функционалу и гибкости. "Вы кошек готовить не умеете" :) iptables также встроен в ядреный сетевой стек на стыках in/out. >Вспомнить тот же УГ, который называется IIS(много ему дал ядерный листенер)? Это есть и будет в микроядерных архитектурах, где уровни абстракции будут вынесены в отдельные процессы-трансляторы представлений, настраиваемые хуками друг к другу в нужном порядке. Пока работаем с тем что есть, и не думаю что оно самый худший вариант (вспоминая IBM370/Серия EC, и их километровые руководства по танцам :) )
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	181. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от iZEN (ok) on 19-Окт-09, 01:43
	>>"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими >разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ. > >Это называется "ниасилить" :))) И это как раз про упоминавшихся уже хомячков >:) >В тех же RH-системах в /etc/sysconfig/network-scripts/ifcfg-бла-бла есть опция HWADDR, которая по-дефольту верно >выставляется Анакондой. Что за змея? Почему не знаю? Есть новый POSIX-стандарт на змей? >[оверквотинг удален] >       UUID or volume label (cf.  e2label(8) or xfs_admin(8)), writing LABEL=<label> or  UUID=<uuid>,  e.g.,  ‘LABEL=Boot’  or >       ‘UUID=3e6be9de-8139-11d1-9106-a43f08d823a6’.   This   >will  make  the system more robust: adding or removing >a SCSI disk >       changes the disk device name >but not the filesystem volume label. >============================================ > >туда же можно писать девайсы lvm и md, которые сами (by design) >нормально привязываются к железкам Приведу только свой /etc/fstab: > cat /etc/fstab # Device    Mountpoint    FStype    Options        Dump    Pass# /dev/mirror/Swap       none    swap    sw              0       0 -- это только swap, так как остальное место для ZFS == собственный кэш имён дисковых устройств в файловой системе, а кроме ZFS на дисках у меня никаких ФС нет. Пример работы с носителями по UUID (GPT ID) в FreeBSD 0) Подготовительные операции: % echo 'geom_mirror_load="YES"' >> /boot/loader.conf и, на всякий случай: % echo 'geom_label_load="YES"' >> /boot/loader.conf % kldload geom_mirror % kldload geom_label 1) Ищем идентификаторы разделов: % gpart list ... Geom name: ad4p3 Providers: 1. Name: gptid/6e34319f-83a6-15de-4bc4-02203d4562eb ... Geom name: ad5p3 Providers: 1. Name: gptid/7b263792-52a6-11ed-7cb6-06531d23a4eb ... 2) Создаём зеркало (для двух физических разделов ad4p3 и ad5p3): % gmirror label -v Data gptid/6e34319f-83a6-15de-4bc4-02203d4562eb Metadata value stored on gptid/6e34319f-83a6-15de-4bc4-02203d4562eb Done. 3) Форматируем зеркало (а фактически -- единственный носитель в нём): % newfs -U /dev/mirror/Data 4) Вносим запись в /etc/fstab: # Device    Mountpoint    FStype    Options        Dump    Pass# /dev/mirror/Data       /Data    ufs    rw              1       1 Всё. Его уже и в таком виде можно использовать —- даст бог, не развалится. :)) 5) Опционально добавляем ещё один зеркалирующий носитель в зеркало: % gmirror insert Data gptid/7b263792-52a6-11ed-7cb6-06531d23a4eb 6) Смотрим статус (после полной синхронизации зеркала): % gmirror status        Name    Status  Components mirror/Data  COMPLETE  gptid/6e34319f-83a6-15de-4bc4-02203d4562eb                        gptid/7b263792-52a6-11ed-7cb6-06531d23a4eb
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	197. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от iZEN (ok) on 19-Окт-09, 23:47
	>1) Ищем идентификаторы разделов: >% gpart list >... Не "% gpart list", а "% glabel list". Ещё. Сейчас проверил: в статусе gmirror, когда смонтирована файловая система, пишутся не метки/идентификаторы gptid, а реальные устройства. Когда ФС зеркала не смонтирована, вместо устройств -- метки. Наводит на мысль, что семантика использования меток в ключе использования GEOM RAID поменялась при переходе с FreeBSD 7.x на 8.x. Вот лог действий: % glabel list Geom name: ad6p2 Providers: 1. Name: gpt/rio_swap1    Mediasize: 2147483648 (2.0G) ... Geom name: ad6p2 Providers: 1. Name: gptid/e0fa02b3-81a6-11de-8aa6-02508d92a2eb    Mediasize: 2147483648 (2.0G) ... Geom name: ad10p2 Providers: 1. Name: gpt/rio_swap2    Mediasize: 2147483648 (2.0G) ... Geom name: ad10p2 Providers: 1. Name: gptid/e2aef92e-81a6-11de-8aa6-02508d92a2eb    Mediasize: 2147483648 (2.0G) ... % gmirror label Swap gpt/rio_swap1 % gmirror status        Name    Status  Components mirror/Swap  COMPLETE  ad6p2 % cat /etc/fstab # Device    Mountpoint    FStype    Options        Dump    Pass# /dev/mirror/Swap       none    swap    sw              0       0 % swapon -a swapon: adding /dev/mirror/Swap as swap device % gmirror insert Swap gptid/e2aef92e-81a6-11de-8aa6-02508d92a2eb gmirror: Unknown provider gptid/e2aef92e-81a6-11de-8aa6-02508d92a2eb. % gmirror insert Swap gpt/rio_swap2 % gmirror status        Name    Status  Components mirror/Swap  DEGRADED  ad6p2                        ad10p2 (16%) % gmirror status        Name    Status  Components mirror/Swap  COMPLETE  ad6p2                        ad10p2 % swapoff -a swapoff: removing /dev/mirror/Swap as swap device % gmirror stop Swap % gmirror status        Name    Status  Components mirror/Swap  COMPLETE  gpt/rio_swap2                        gpt/rio_swap1 % swapon -a swapon: adding /dev/mirror/Swap as swap device % gmirror remove Swap gpt/rio_swap1 % gmirror status        Name    Status  Components mirror/Swap  COMPLETE  gpt/rio_swap2 % gmirror remove Swap gpt/rio_swap2 % gmirror status        Name  Status  Components mirror/Swap     N/A  N/A % swapoff -a swapoff: /dev/mirror/Swap: No such file or directory % gmirror stop Swap gmirror: No such device: Swap. % gmirror insert Swap gpt/rio_swap2 gmirror: No such device: Swap. % gmirror label Swap gpt/rio_swap1 % swapoff -a % swapon -a swapon: adding /dev/mirror/Swap as swap device % gmirror status        Name    Status  Components mirror/Swap       N/A  N/A mirror/Swap  COMPLETE  ad6p2 % swapoff -a swapoff: removing /dev/mirror/Swap as swap device % gmirror remove Swap gpt/rio_swap1 gmirror: No such provider: gpt/rio_swap1. % gmirror remove Swap ad6p2 % gmirror status        Name  Status  Components mirror/Swap     N/A  N/A % gmirror stop Swap gmirror: No such device: Swap.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	200. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 20-Окт-09, 12:34
	>Ещё. Сейчас проверил: в статусе gmirror, когда смонтирована файловая система, пишутся не >метки/идентификаторы gptid, а реальные устройства. Когда ФС зеркала не смонтирована, вместо >устройств -- метки. >Наводит на мысль, что семантика использования меток в ключе использования GEOM RAID >поменялась при переходе с FreeBSD 7.x на 8.x. Есть изменения в /src/sbin/geom/class/part/geom_part.c  gpart_show_geom() - появился вызов новой функции gpart_autofill(), мэй би это она рисует провайдеров по новому? # svn diff http://svn.freebsd.org/base/stable/7/sbin/geom/ \ #    http://svn.freebsd.org/base/stable/8/sbin/geom/ На заметку, это как-то не отражено в документации, просмотр реальной иерархии GEOM, из sys/geom/geom_dump.c: # sysctl -b kern.geom.conftxt Можно .confdot, если установлен graphviz # sysctl -b kern.geom.confdot > geom.dot # dot -Tps  geom.dot > geom.ps Или # dot -Tpng geom.dot > geom.png
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	119. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 09-Окт-09, 17:51
	>А ничего дебильнее прыгающей нумерации сетевушек в вашей фре я не видел. >Стоят три сетевушки одинаковой модели: rl0, rl1, rl2. Вынимаем вторую, вставляем >ещё одну, но другой модели и что мы видим? rl0, rl1, >xl0. Вперед, переписывать в трёхстах местах название интерфейса. Или алиасики на Хех, добавим огня, с сохранением стиля :) Ничего дебильнее обезличивающего наименования в линуксе я не видел - eth0, eth1, eth2. Выдернул сетевушку, вставил новую - и не поймешь, к какой интерфейс относится? --- 1. Если вы меняете сетевые карты так часто, то это печально. 2. Если часто меняемая локация ifconfig ... route delete ... route add ... Скрипт в три команды, думаю, не проблема. 3. Для постоянного изменить нужно только в /etc/rc.conf Кроме guagga/zebra, влет не припоминаю ПО, сильно или вообще зависимого от имени интерфейса. Firewall, пожалуй, вешь индивидуальная, по уму там хорошо макроподстановкой. И нечего городить огород там, где можно гораздо проще.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	139. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от bugmenot (??) on 12-Окт-09, 04:14
	> Костыли devd не предлагать а в чем костыльность способа с devd(8)? При поднятии и опускании интерфейса в /dev/devctl или /var/run/devd.pipe появляются такие строчки !system=IFNET subsystem=xl0 type=LINK_DOWN !system=IFNET subsystem=xl0 type=LINK_UP На основе примера из devd.conf(5) получим notify 0 {     match "system"                  "IFNET";     match "type"                    "LINK_DOWN";     action "/etc/network/ip-down.d/$subsystem"; }; notify 0 {     match "system"                  "IFNET";     match "type"                    "LINK_UP";     action "/etc/network/ip-up.d/$subsystem"; }; Таким образом будут выполняться /etc/network/ip-(up|down).d/ скрипты. Однако detach/attach будут выглядеть так !system=DEVFS subsystem=CDEV type=CREATE  cdev=xl0 !system=DEVFS subsystem=CDEV type=DESTROY cdev=xl0 поэтому они *не будут* попадать под сие правило и конфликта не будет. Чем этот метод плох? Он не привязан к имени интерфейса.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–2 +/–
Сообщение от QuAzI (ok) on 08-Окт-09, 20:22
Людям надоело париться по поводу "а под каким ядром и с каким патчем вот эта версия вот этой писаной на коленке софтины будет работать" и искать новый репозитарий по поводу и без повода для каждой ОС. Хороший софт должен работать под хорошими ОС из коробки. И это, ИМХО, правильно. А вантцзы пусть дальше строят из себя ССЗБ и пишут сами себе несовместимый софт с куцыми стандартами.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 08-Окт-09, 20:37
	А можно для тупых - по-русски ? И кто такие вантцзы ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–1 +/–
	Сообщение от QuAzI (ok) on 08-Окт-09, 21:01
	> А можно для тупых - по-русски ? И кто такие вантцзы >? Так уж сталось, что Ц и У очень близко на клавиатуре расположены =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+2 +/–
	Сообщение от Iv945n (ok) on 08-Окт-09, 21:38
	>> А можно для тупых - по-русски ? И кто такие вантцзы >>? > >Так уж сталось, что Ц и У очень близко на клавиатуре расположены >=) Это не значит что они равноценны и вместо у можно ставить ц. Enter и Backspace тоже рядом находятся, тем не менее внимательный пейсатель таки может усмотреть некое различие в их смысловой нагрузке ;-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от QuAzI (ok) on 08-Окт-09, 22:39
	Да неужели? И Вы не опечатываетесь никогда? Молодец, возьмите пряник с полки. А я живой человек, при наборе "на скорую руку", не глядя на клавиатуру, я таки иногда мажу, опечатываюсь, мне как живому человеку своственно ошибаться. ИМХО, Windows от того как я её обзову лучше работать не станет, как была вантузом, так вантузом и останется.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
Сообщение от nikll on 08-Окт-09, 21:34
Ну на мой взгляд ничего толкового в этой затеи нет, /etc/network/ в топку, rc.conf удобней, никакой apt незаменит портов это тоже факт, линуксячьи системные библиотеки? а нафига козе баян? там и родные отлично справляются. Единственное что возможно будет ценным это то что юзеры сериии "большая кнопка сделай мне хорошо" будут потяхоньку подтягиватся на фрю, возможно слегка улудшится ситуация с драйверами т.к. ядро будет юзатся на большем количестве машин, ну может кто сповадится адаптировать свою линухо-заточенную софтину на другие никсовые оси (в основном пропиретанщина, оракл, вмваря, и прочая...)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+3 +/–
	Сообщение от Iv945n (ok) on 08-Окт-09, 21:40
	Да, таки это из серии "что только люди не придумают чтобы просто не взять и не поставить FreeBSD..." :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+5 +/–
	Сообщение от xxx (??) on 08-Окт-09, 22:33
	Я думаю они это делают в меньшей степени для пользователей FreeBSD, скорее для пользователей Debian, желающих получить те или иные фичи FreeBSD, при этом оставаясь в привычной и удобной для них среде. Но в любом случае от этого проекта выиграют все. А спорить rc.NG vs /etc/rc.d, apt vs ports - это бесполезно, пользуюсь и тем и тем, у всего есть свои плюсы и минусы. Вобщем, удачи мужикам из Debian!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	70. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (ok) on 09-Окт-09, 09:45
	>Ну на мой взгляд ничего толкового в этой затеи нет, /etc/network/ в >топку, rc.conf удобней, Я одинаково легко орудую и тем и другим. >никакой apt незаменит портов это тоже факт, Никакие порты не заменят мягких зависимостей dpkg и стабильной ветки в репозиториях Debian. >линуксячьи системные библиотеки? а нафига козе баян? там и родные отлично справляются. Вот именно, нафига Debian'у BSD-шные библиотеки? Там и GNU'тые отлично справляются. А поддерживать GNU и BSD-библиотеки в рамках одного дистрибутива тяжелее, нежели одну. >Единственное что возможно будет ценным это то что юзеры сериии "большая кнопка >сделай мне хорошо" будут потяхоньку подтягиватся на фрю, Во фре и так много восторженных хомячков. Единственное, чем они отличаются от Ubuntu'йцев, так это верой в превосходство FreeBSD над остальными системами и потрясающим мазохизмом. Потому что только мазохисты могут жить без стабильной ветки программ и без нормальной двоичной системы пакетов. От отсутствия первого после обновляения постоянно что-то ломается, а от отсутствия второго приходится компилить и компилить. >возможно слегка улудшится >ситуация с драйверами т.к. ядро будет юзатся на большем количестве машин, Это из разряда "Если посадить за печатные машинки миллионы мартышек, то возможно они напишут "Войну и мир"". >ну может кто сповадится адаптировать свою линухо-заточенную софтину на другие никсовые >оси (в основном пропиретанщина, оракл, вмваря, и прочая...) Это да. Мэнтейнеры Debian и так во-всю патчат изначально работающий Linux-софт для запуска под kFreeBSD, значит поток патчей направленных именно на совместимость увеличится. А проприетарщина Debian игнорирует, Debian - не коммерческая система. Они как концентрировались на RedHat, SuSE, Ubuntu и Solaris, так и продолжат.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от Аноним (??) on 09-Окт-09, 10:54
	>и без нормальной двоичной системы пакетов Вы считаете что во фре нет бинарных пакетов ? Или что она ненормальная ? >то возможно они напишут "Войну и мир"". не "возможно", а неизбежно. Согласно теории больших чисел.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от DEC (??) on 09-Окт-09, 11:12
	>Вы считаете что во фре нет бинарных пакетов ? Или что она >ненормальная ? > Во фре есть система бинарных пакетов. И она ненормальная. В нормальных возможен бинарный апдейт и выходят бинарные же обновления. По теме - весть хорошая, обязательно буду тестить!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	110. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от QuAzI (ok) on 09-Окт-09, 16:46
	>Во фре есть система бинарных пакетов. И она ненормальная. В нормальных возможен >бинарный апдейт и выходят бинарные же обновления. У portupgrade есть параметр указывающий тащить пакеты. Что дальше?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	130. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от iZEN (ok) on 09-Окт-09, 21:43
	>>Вы считаете что во фре нет бинарных пакетов ? Или что она >>ненормальная ? >> > >Во фре есть система бинарных пакетов. И она ненормальная. В нормальных возможен >бинарный апдейт и выходят бинарные же обновления. "portupgrade -aPP" в помощь.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	173. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от oops on 15-Окт-09, 06:36
	При всей моей любви к фряхе не могу не выразить свое "фи" по поводу portupgrade. Такого кривого костыля еще в жизни не видел. Который опять же лечит кривую пакетную систему.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (ok) on 09-Окт-09, 12:27
	>>и без нормальной двоичной системы пакетов > >Вы считаете что во фре нет бинарных пакетов ? Или что она >ненормальная ? В ней нет мягких зависимостей. Я не могу поставить вот этот пакет без вот этих и вот этих - мне нужно будет пересобрать этот пакет из портов. В dpkg мягкие зависимости есть и от их установки можно отказаться, не прибегая к перекомпиляции. Это первый момент. А второй является не претензией к пакетам, как таковым, а к отсутствию стабильной ветки пакетов, которую бы вылизывали также тщательно, как стабильный Debian. Нет способа обновлением закрыть дырки в пакетах, не повысив версии софта. >>то возможно они напишут "Войну и мир"". > >не "возможно", а неизбежно. Согласно теории больших чисел. Это чисто математическая абстракция. Обезьяны сдохнут, машинки сломаются, весь лес будет вырублен и переведён на бумагу для них, Луна оторвётся от Земли, Солнце превратится в Красного гиганта, Млечный Путь столкнётся с Туманностью Андромеды, вселенная расширится и остынет до температуры тепловой смерти, а "Войны и мира" вы так и не дождётесь. А вы можете подождать, когда эти обезьяны напишут вам драйверы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	85. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 09-Окт-09, 13:06
	Естественно, гипотеза бесконечных обезъян это математическая абстракция. Я думал это очевидно для всех. А насчёт гипотетического времени наступления этого события вы не правы. Бесконечно малая вероятность совсем не говорит о том что событие произойдёт через бесконечный промежуток времени. Любая попытка может завершиться успехом равновероятно. Так что драйвера могут быть уже завтра :) А вообще проблема с драйверами уже значительно утратила свою остроту. У меня за последние года 3 проблема была только с драйвером под картридер Rikoh в ноуте. Приходится качать драйвер отдельно и собирать. Я, конечно, не тестер суперновых дивайсов, но на мейнстрим железо драйвера давно есть.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	88. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (ok) on 09-Окт-09, 13:10
	>Естественно, гипотеза бесконечных обезъян это математическая абстракция. Я думал это очевидно для >всех. А насчёт гипотетического времени наступления этого события вы не правы. >Бесконечно малая вероятность совсем не говорит о том что событие произойдёт >через бесконечный промежуток времени. Любая попытка может завершиться успехом равновероятно. Но если уж речь пошла о математике, то вам должно быть знакомо понятие математического ожидания. И равно оно половине времени перебора всех возможных вариантов. >Так что драйвера могут быть уже завтра :) А могут и не быть ещё миллиарды лет :( >А вообще проблема с драйверами уже значительно утратила свою остроту. У меня >за последние года 3 проблема была только с драйвером под картридер >Rikoh в ноуте. Приходится качать драйвер отдельно и собирать. Я, конечно, >не тестер суперновых дивайсов, но на мейнстрим железо драйвера давно есть.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	117. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от аноним on 09-Окт-09, 17:49
	> В ней нет мягких зависимостей. Ваши `мягкие зависимости' - фикция. Не надо быть семи пядей во лбу, чтобы понимать, что пакет либо собран с поддержкой какой-либо библиотеки, либо без нее, и никакими зависимостями это не исправить. Ваши мягкие зависимости годны только на то, чтобы включать/выключать документацию для пакетов, и чтобы совать под нос кучу ненужного барахла. Фактически, первое, что я делаю при установке дебиана - выключаю автоматическую установку suggested/recommended пакетов. > Нет способа обновлением закрыть дырки в пакетах, не повысив версии софта. Щаз, будут там ради вас патчить допотопные версии софта.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	122. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+2 +/–
	Сообщение от www2 (ok) on 09-Окт-09, 18:08
	>> В ней нет мягких зависимостей. >Ваши `мягкие зависимости' - фикция. Не надо быть семи пядей во лбу, >чтобы понимать, что пакет либо собран с поддержкой какой-либо библиотеки, либо >без нее, и никакими зависимостями это не исправить. Это понятно. Но если библиотека - динамическая, то она уже может быть плагином. А плагин можно загружать, можно не загружать - программа от её отсутствия колом не встанет. Ставить ли мне все модули для PHP, ставить только нужные или вообще не ставить - такой выбор Debian мне даёт. В портах FreeBSD это можно выбрать только при сборке, а как собран пакет - неизвестно, то ли там всё есть, то ли ничего, то ли что-то по вкусу мэнтейнера. >Ваши мягкие зависимости >годны только на то, чтобы включать/выключать документацию для пакетов, и чтобы >совать под нос кучу ненужного барахла. Выше расписал ситуацию. А если учесть, что кроме плагинов и документации, бывают ещё плагины-скрипты, пакеты бывает состоят из демона, клиента и кучи утилит, то возможностей для использования мягких зависимостей становится ещё больше. В чём профит? Мне не нужно собирать что-то из портов, когда мои предпочтения не совпадают с предпочтениями мэнтейнера. >Фактически, первое, что я делаю >при установке дебиана - выключаю автоматическую установку suggested/recommended пакетов. Я тоже делаю это в первую очередь. И ставлю при этом самую-самую базовую систему Debian, где даже traceroute нет. >> Нет способа обновлением закрыть дырки в пакетах, не повысив версии софта. > >Щаз, будут там ради вас патчить допотопные версии софта. Этим и отличается распиздяйство от заботы о пользователях.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	127. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от Аноним (??) on 09-Окт-09, 19:27
	Приведённый пример с модулями php работает абсолютно одинаково во фре и дебиане. База пхп - это один пакет, модули - отдельные пакеты. В дебе базовый пакет пхп тянет какие-то модули, впихнутые майнтейнерами, что мне кажется излишним. С другой стороны во фре пакет пхп (и, соответственно, дефолт в портах) не содержит модуля для апача, так что почти всегда приходится его пересобирать. Это неудобно, но логично, т.к. "единственно верной" версии апача не предлагается. И таких аргументов можно привести вагон. Так что здесь вопрос скорее в субъективном удобстве для каждого конкрентого человека.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	174. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от oops on 15-Окт-09, 06:51
	>С другой стороны во фре пакет пхп (и, >соответственно, дефолт в портах) не содержит модуля для апача, так что >почти всегда приходится его пересобирать. Это неудобно, но логично, т.к. "единственно >верной" версии апача не предлагается. И здесь как раз полная засада!. Имя php пакета никак не отражает то, с какой версией апача он собран. соответственно пакет без libphp, для ap20 и ap22 будет иметь одно и то же имя. Такая же канитель с модулями php, часть из них не содержит в имени версии php и версии апача для которой они собраны(mod_perl, mod_python, mod_jk2, pecl). Получается что под каждую конфигурацию нужен свой пакетный репозиторий. Когда я обратился к разработчикам - меня послали. Сказали, что так и должно быть.     Говорю про то, чего сам накушался - фряшная пакетная система - самый серьезный тормоз для прихода коммерческого софта в BSD мир. Слишком неудобная дистрибуция и большие затраты на тестирование(разворачивание окружения. Особенно апгрейд) по сравнению с даже rpm based системами.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	176. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 16-Окт-09, 11:52
	>Такая же канитель с модулями php, часть из них не содержит в имени версии php Все модули php5-* работают с любой версией php5, php4-* c php4. > и версии апача для которой они собраны(mod_perl, mod_python, mod_jk2, pecl) это, извините, бред. Модулям пхп без разницы какой установлен апач и установлен ли вообще.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	182. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от oops on 19-Окт-09, 06:14
	>>Такая же канитель с модулями php, часть из них не содержит в имени версии php > >Все модули php5-* работают с любой версией php5, php4-* c php4. >> и версии апача для которой они собраны(mod_perl, mod_python, mod_jk2, pecl) да-да. И с любой версией апача: >это, извините, бред. Модулям пхп без разницы какой установлен апач и установлен >ли вообще. 1. test# pwd /usr/ports/sysutils/pecl-fileinfo test# make -V PHP_EXT_DIR 20060613 <- это отдельная папочка для модулей php. test# make -V PKGNAME pecl-fileinfo-1.0.4 Как видим имя пакета не отражает ничего. Порт один для всех версий пхп. Соответственно чтобы собрать пакет нужно понимать на каком срезе портов мы это делаем(чтобы не уехал PHP_EXT_DIR). И для какой версии php. 2. test# pwd /usr/ports/lang/php5 test# make -V WITH_APACHE yes test# make -V PKGNAME php5-5.2.8 test# pkg_info -L php5-5.2.8 | grep libphp5 /usr/local/libexec/apache2/libphp5.so Это для apache20. Для версии 2.2 путь до модуля будет другим. В результате имеем два набора пакетов php и модулей для двух версий апача. С одинаковыми именами пакетов. И это достаточно типовая ситуация. 3. Вопрос: Что мне, как майнтейнеру коммерческого проекта делать?   a) становиться майнтейнером собственного порта?   б) собирать blob-ом с приседаниями как, например, в опера(shared|static qt)?   в) как граммотно устроить апгрейд? Очень желательно без компиляции, чтобы снизить downtime клиента. Ферму не предлагать - клиент не осилит.   г) как мне снизить временный затраты на тестирование?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	183. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 19-Окт-09, 12:26
	>Что мне, как майнтейнеру коммерческого проекта делать? Как "майнтейнеру коммерческого проекта" нужно прежде всего понять, на каких условиях производится дистрибьюция используемого вами программного обеспечения. Потом оценить все ньюансы, их позитивные и негативные составляющие, ваши риски и возможный жизненный путь проектируемой системы. И далее осуществить грамотную техническую подготовку. Где в публичных BSD ограничениях-оферте хоть раз сказано, что кто-то вам обязан чем-то? BSD порты не являются прототипом коммерческой системы сопровождения сторонних приложений, нужно четко это понимать. Как вариант, подготовте слепок портов под клиента, а то и системы, закатайте себе на болванки - и при необходимости переносите акуратно в нее обновления на основе слепка. Не нужно говорить, а что если 100 клиентов - это ваше решение. Исползуйте другой вариант, другую программное решение и другую систему дистрибьюции, скажем - коммерческие системы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	198. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от oops on 20-Окт-09, 09:22
	Я все это прекрасно понимаю. И делаю именно так как вы говорите. Но это _я_ могу так делать. > BSD порты не являются прототипом коммерческой системы сопровождения сторонних > приложений, нужно четко это понимать. BSD пакеты тем более таковыми не являются. Я лишь указал на то, что BSD системы сильно осложняют себе этим жизнь. И на серверах в том числе.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	199. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 20-Окт-09, 11:14
	>Я все это прекрасно понимаю. И делаю именно так как вы говорите. >Но это _я_ могу так делать. Это хорошо, что вы можете. "Не оскудела земля Русская" :) Правда, Президент Медведев недоумевает - талантов много, а толку мало :) Что не так делаем? Думаю, по мере привлечения грамотных кадров к BSD-разработкам прогресс будет и в направлении системы портов. В андерграунде давно ведется над этим работа (черт, ссылок нет под рукой), но все как-то критической массы не хватает. Может потому что удовлетворительный результат тут враг хорошего, и объем имеющихся наработок в портах как ... АвтоВАЗ, те слишком большой, отказатся недьзя, и перейти безболезненно, без потерь на другую модель нельзя. Или "настоящих буйных мало, вот и нету вожаков"? :) >> BSD порты не являются прототипом коммерческой системы сопровождения сторонних >> приложений, нужно четко это понимать. > >BSD пакеты тем более таковыми не являются. Пожалуй, их минимальная задача - получить работающую систему на некоторый момент, без проведения компиляции. Во многих случаях - как работы по контракту, так и для самого себя этого _достаточно_ как миниум с удовлетворительным результатом, хотя бы для начала. Конечно, этому есть границы, кошмар несоответсвий бинарных объектов можно получить очень быстро - вы это понимаете. Debian, RedHat и его подобные дистрибутивы позволяют держать его в границах, ценой определенных ограничений-формализмов и огромной работы разработчиков-сборщиков дистрибутивов. Социальный эффеект этого, один из них - массив зависимых леммингов-псевдоспециалистов, безинициативных и отученных от самостоятельного мышления. Мечта сбылась - кто-то делает за него работу, и бухгалтер за смету-накладные не спрашивает. Тлько что вчерась очередной, "системный администратор ... Unix" с 4-5 летним стажем, и не знает что такое Makefile, и как компилятор хидеры находит, это показательно ("Я знаю, он туфту гонит" - внутренний голос читающего. А кто ж себя дураком признает? :) ). В _частности_, отсюда и вопли, как только в среде леммингов заходит речь об использовании BSD - для многих это дополнительное обучения/самообучение, а это вызывает довольно сильный адаптационный стресс (что верно для случаев любой смены ПО). >Я лишь указал на то, что BSD системы сильно осложняют себе этим >жизнь. И на серверах в том числе. Операционные системы не могут осложнять себе жизнь сами по себе - они не живые. Осложняем жизнь мы себе сами, друг другу по кругу :| Или облегчаем, что отрадно наблюдать и в чем участвовать :) Хаббард, Вильямс, Грамс, Раад, Крукс, ... & K добились основной цели - 4.4BSD/386BSD OS как мета-проект не канула в лету и неплохо развивается, усилиями добровольцев со всего мира. В частности, показатель этого развития - действия по адаптации BSD OS для решения коммерческих и личных задач. BSD cистемы довольно привлекательны для инженерно-научной части социума. Были, есть, и наверно, будут. Как и проект Debian/FreeBSD. К сожалению, проетк весьма нежизнеспособный, и чем далее, тем более - между Debian, базированным на Linux kernel API&toolkits (именно этим он обязан своей популярности) & Debian logics, и BSD слишком много технических отличий, оборачивающимися в систему технических (и социально-организационных) противоречий. В конечном итоге, участники каждого проекта - живые люди. Как компромиссный вариант, можно завернуть базовую BSD в один большой deb-пакет, будет бАльшой freebsd-x.y.z-i386.deb :) Ну вот такая лирика, с утреца под чашку чая просыпаясь :) Пора работу работать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	134. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от fulcrum (??) on 10-Окт-09, 22:44
	>А проприетарщина Debian игнорирует, Debian - не коммерческая система. Они как >концентрировались на RedHat, SuSE, Ubuntu и Solaris, так и продолжат. Оракулы включили Дебиан в список официально поддерживаемых ОС. И правильно сделали, так как не поддерживать серьезнейший дистр глупо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
Сообщение от dimanoname (ok) on 08-Окт-09, 22:24
долго сижу думаю над предложением и не понимаю, чем меня, как пользователя FreeBSD, может заинтересовать пакетный менеджер APT, cистема конфигурации /etc/network/ и прогрессивная система инициализации Debian...Какое то неравноценное сравнение: pf jail netgraph и то, что указано выше...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от xxx (??) on 08-Окт-09, 22:38
	>долго сижу думаю над предложением и не понимаю, чем меня, как пользователя >FreeBSD, может заинтересовать пакетный менеджер APT, cистема конфигурации /etc/network/ и прогрессивная Так ничего, зато пользователям Debian-подобных дистров это может быть интересно. Ещё раз повторюсь, они не делают FreeBSD с APT, /etc/network - они делают Debian с pf, jail и т. д. >Какое то неравноценное сравнение: pf jail netgraph и то, что указано выше... А тут вообще сравнение уместно?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–1 +/–
	Сообщение от Аноним (??) on 08-Окт-09, 22:43
	>пакетный менеджер APT APT позволяет бинарно обновлять софт. Во фре release-пакеты не обновляются. Правда обновление сильно старого софта через APT может стать pain in the ass вплоть до неработоспособности системы из-за того что обновлениие небольшой софтинки потянет за собой обновление бОльшей части пакетов включая ядро. Но при регулярном обновлении, наверное, удобно. >прогрессивная система инициализации Debian по удобству, конечно, на любителя, но грузится система гораздо быстрее чем фря. >cистема конфигурации /etc/network/ тоже сомнительное преимущество, но кому-то может привычнее Итого - фришники врядли перейдут на эту систему, а кто-то из линуксоидов - может и попробуют.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от аноним on 08-Окт-09, 23:04
	> APT позволяет бинарно обновлять софт. Во фре release-пакеты не обновляются. stable обновляются, а они совсестимы со всей веткой. >Итого - фришники врядли перейдут на эту систему, а кто-то из линуксоидов >- может и попробуют. Во-во. Кстати для сбора Linux vs. FreeBSD весьма показательно, с какой ОС больше народа перейдет на гибрид.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	175. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от oops on 15-Окт-09, 06:53
	Гораздо интереснее будет потом погонять тесты на разных ядрах с одинаковым окружением.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	140. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от bugmenot (??) on 12-Окт-09, 05:08
	>>прогрессивная система инициализации Debian > >по удобству, конечно, на любителя, но грузится система гораздо быстрее чем фря. rc.d (пока) не умеет параллельный запуск сервисов. Вот если в 9-ке сделают параллельный attach/detach (в ядре) и параллельный rc.d, то фря должна быстрее грузится. Там просто скриптов меньше и они проще. ps, не знаю почем, но на netbsd на том же железе rc.d выполняются быстрее
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от аноним on 08-Окт-09, 23:00
	>долго сижу думаю над предложением и не понимаю, чем меня, как пользователя >FreeBSD, может заинтересовать пакетный менеджер APT, cистема конфигурации /etc/network/ и прогрессивная >система инициализации Debian... Разумеется, ничем. Зато ядро FreeBSD может заинтересовать дебианщиков - поэтому проект реализовали они, а не FreeBSD'шники. По-моему, тут все логично.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

30. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
Сообщение от Resonance on 08-Окт-09, 22:31
Одно не пойму, почему FreeBSD? Почему не OpenBSD? Ведь у Debian c OpenBSD намного больше общего в стремлении к открытости!
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от xxx (??) on 08-Окт-09, 22:48
	>Одно не пойму, почему FreeBSD? Почему не OpenBSD? Ведь у Debian c >OpenBSD намного больше общего в стремлении к открытости! Может потому, что ядро OpenBSD в отрыве от самой системы, мало представляет интереса? Ну и наверное недавний epic fail с OpenSSL/SSH сильно подорвал общее стремление =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от mma on 09-Окт-09, 04:44
	альтернативы?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	91. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 09-Окт-09, 13:38
	>>Одно не пойму, почему FreeBSD? Почему не OpenBSD? Ведь у Debian c >>OpenBSD намного больше общего в стремлении к открытости! > >Может потому, что ядро OpenBSD в отрыве от самой системы, мало представляет >интереса? Ну, положим, тот же pf, например, в OpenBSD не в пример свежее. ;) >Ну и наверное недавний epic fail с OpenSSL/SSH сильно подорвал общее стремление >=) 1. Причём тут OpenSSL? Этот проект не имеет никакого отношения к OpenBSD, за исключением того, что опёнковцы в своё время его основательно чистили перед тем как добавить в базовую поставку (патчи в апстрим ушли, ессесно). 2. Что это за недавний epic fail с OpenSSH?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Эргил on 08-Окт-09, 22:59
	где-то в недрах еще в свое время шевелился Debian GNU/kNetBSD
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от аноним on 08-Окт-09, 23:05
	>Одно не пойму, почему FreeBSD? Потому что самая продвинутая из трех. >Почему не OpenBSD? Ведь у Debian c OpenBSD намного больше общего в стремлении к открытости! С чего бы это?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	45. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Resonance on 08-Окт-09, 23:35
	И Debian и OpenBSD против закрытых компонентов в системе...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	92. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 09-Окт-09, 13:42
	>И Debian и OpenBSD против закрытых компонентов в системе... И не только. Сам изначальный подход к разработке ОС у них во многом схож. Не знаю, как среди дебианщиков, но разработчики OpenBSD (кажется, в том числе сам де Раадт) так говорят. Stable-порты, жёсткий подход к релизам, (хотя у Debian он всё же мягче), жёсткая политика лицензионной чистоты (а вот тут Debian до недавнего времени был ещё непримеримее OpenBSD)…
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	101. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от aZ (ok) on 09-Окт-09, 14:53
	Были бы схожи - была бы одинаковая лицензия. А так - сравнивате козла и овцу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	107. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от аноним on 09-Окт-09, 16:21
	>И Debian и OpenBSD против закрытых компонентов в системе... Воотбе-то против закрытых все одинаково.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	141. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от bugmenot (??) on 12-Окт-09, 06:30
	>>Одно не пойму, почему FreeBSD? > >Потому что самая продвинутая из трех. Продвинутая в какую сторону? где во фре domain0 для Xen [1] multiboot (загрузка чужого ядра по спецификации без chainloding'а) возможность вкомпилить /boot/mfsroot внутрь ядра загрузка сжатого gzip'ом ядра kauth veriexec fileassoc rump umapfs (было во фре, но удалили без альтернативы) lfs (то же что и nilfs, кою нетка *уже* умеет читать) resize_ffs (и lfs) portalfs с поддержкой rfilter/wfilter variable symlinks софтовый midi aka opl(4) управление сенсорами (спасибо флейму от phk@) Video4Linux2 (cf. video(4)) автодополнение комманд/путей в sh(1) и поддержка кросскомпиляции из других ОСей? и этот неполный список только в сравнении с netbsd, исключая текущее портирование puffs и замену syscons(4) на vt(4), планый(!) по обновлению/замене gcc/gdb/binutils. Фря разве что ближе всего к десктопу/роутеру подвинута. Забавное сочетание, не правда ль? [1] впрочем, в нетке dom0 пока не умеет SMP, а domU не умеет фреймбуффер без HVM
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	143. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 12-Окт-09, 10:35
	>где во фре При этих словах, как понимаю, developers FreeBSD, всей командой во главе с вице президентом FreeBSD Foundation, должны нервно заерзать, потупив глаза в пол и что-то бурча в оправдание... :) >и этот неполный список только в сравнении с netbsd, исключая текущее портирование >puffs и замену syscons(4) на vt(4), планый(!) по обновлению/замене gcc/gdb/binutils. Сколько возможностей для приложится к проектированию и программированию. Или "оно само там появляется"? Или трындеть, сидя ровно, таки намного легче? :) http://www.freebsdfoundation.org/projects.shtml http://wiki.freebsd.org/FrontPage Рассматривать приведенный список как-то не хочется, поскольку он наполовину высосан из пальца. Только одно показательно # man kgzip NAME      kgzip — compress a kernel SYNOPSIS      kgzip [-cv] [-f format] [-l loader] [-o output] file DESCRIPTION      The kgzip utility compresses a kernel or some other bootable binary.      Operation is in two phases as follows: ...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
Сообщение от Аноним (??) on 08-Окт-09, 22:34
Наглая брехня. netgraph, ipfw2, там нет, и не было. не запутывайте людей своими выдумками.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от moonug (ok) on 08-Окт-09, 22:45
	И куда его дели? Из ядра выпилили?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 09-Окт-09, 01:01
	вообщето суть проэкта - создание гнутого окружения со всеми вытекающими. пусть хоть трижды оно будет в ядре, толку от того.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	109. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от аноним on 09-Окт-09, 16:22
	>вообщето суть проэкта - создание гнутого окружения со всеми вытекающими. пусть хоть >трижды оно будет в ядре, толку от того. Вообще-то там есть пакет необходимых утилит из FreeBSD-шного юзерленда, иначе смысла вообще никакого нет. Вы что, серьезно полагаете что они будут анонсировать фичи, которыми нельзя воспользоваться?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

46. "Принято решение об официальной поддержке архитектуры kFreeBS..."		–1 +/–
Сообщение от bys76 on 08-Окт-09, 23:40
Смесь бульдога с носорогом - кому-то явно больше заняться нечем. Хотя все-равно это интересно только на серверах и маршрутизаторах, где юниксы и так сильны. Зачем изобретать новый велосипед???
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от pavel_simple (ok) on 08-Окт-09, 23:47
	>Смесь бульдога с носорогом - кому-то явно больше заняться нечем. >Хотя все-равно это интересно только на серверах и маршрутизаторах, где юниксы и >так сильны. Зачем изобретать новый велосипед??? видимо не всем нравиться система портов или пакаджей в том виде в котором она есть во фряхе, но при этом вполне допускаю что многим импонирует само ядро. opensolaris + apt = nexenta (дивизом у них кстати "Power of OpenSolaris, with he usability of Linux") про пока несостоявшийся GNU/Hurd я думаю слышали все вот ... дай бог - будет и Debian/kFreeBSD P.S. моё скромное мнение: люди считающие что "если этj не нужно мне - не нужно никому" интеллектуально ущербны.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 09-Окт-09, 00:32
	>видимо не всем нравиться система портов или пакаджей в том виде в котором она есть во фряхе Видимо, но их число безразлично мало
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от pavel_simple (ok) on 09-Окт-09, 00:36
	>>видимо не всем нравиться система портов или пакаджей в том виде в котором она есть во фряхе > >Видимо, но их число безразлично мало ииииии? какой вы хотите сделать вывод из?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	142. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 12-Окт-09, 08:47
	>ииииии? какой вы хотите сделать вывод из? Фряшникам этот лисапед не нужен
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	144. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 12-Окт-09, 11:04
	>>ииииии? какой вы хотите сделать вывод из? > >Фряшникам этот лисапед не нужен Фряшники вообще консервативные, им ничего кроме их фри не нужно. Они потратили так много времени на изучение фри, что остальное изучать у них просто нет сил. А ещё они так много времени тратят на компиляцию, что у них нет времени на чтение документации, отличной от документации на фряху. Они собирают: 1. волшебное кастомизированное ядро с волшебно отобранными модулями, вкомпиленными в ядро, 2. волшебно кастомизированную базовую систему (у кого без sendmail, у кого без bind, у кого без них обоих и ещё без тележки того, что разработчики базы посчитали нужным в неё засунуть), 3. волшебным образом собранные порты (именно собранные, потому что двоичные пакеты обычно собраны с ненужными зависимостями, а единственный способ избежать установки ненужных зависимостей - это пересобрать из портов). Ещё они собирают, потому что порты постоянно обновляются и нельзя закрыть дырки в программах не прибегая к повышенияю версии софта и используя только готовые двоичные пакеты. Ещё они некоторое время тратят на чтение /usr/ports/CHANGELOG, чтобы не дай бог при повышении версии софта что-то не отвалилось. Ещё, поскольку на слабых говнороутерах кастомизированное ядро будет собираться двое суток, они настраивают билд-сервер и экспортруют результаты компиляции по NFS. А поскольку при обновлениях портов что-то может сломаться, то фряшники сначала всё тестируют на отдельном тестовом сервере. А тут, представьте, люди не тратя времени на компиляцию всего и вся, тратя время на чтение CHANGELOG всего один раз в два года, будут пользоваться волшебным фряшным ядром! Конечно же нужно крикнуть "не нужно", "извращение", "смесь бульдога с носорогом", чем реально попробовать что-то отличное от фри и реально узнать преимущества и недостатки различных систем.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	145. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 12-Окт-09, 12:42
	>Ещё они собирают, потому что порты постоянно обновляются и нельзя закрыть дырки >в программах не прибегая к повышенияю версии софта и используя только >готовые двоичные пакеты. FreeBSD Porter's Handbook http://www.freebsd.org/doc/en/books/porters-handbook/makefil... See sections: 5.2.1 PORTNAME and PORTVERSION 5.2.2 PORTREVISION and PORTEPOCH --- По поводу предкомпилированных пакетов. Всего два примера, из огромного множества: ports/net-mgmt/net-snmp/Makefile: OPTIONS=        IPV6 "Build with IPv6 support" on                 MFD_REWRITES "Build with 64-bit Interface Counters" off                                   PERL "Install additional perl modules" on                                                 PERL_EMBEDDED "Build embedded perl" on                                                     TKMIB "Install graphical MIB browser" off                                               DUMMY "Enable dummy values as placeholders" on                                             DMALLOC "Enable dmalloc debug memory allocator" off       ports/net/samba33/Makefile: OPTIONS=        LDAP            "With LDAP support" on \                 ADS             "With Active Directory support" off \                 CUPS            "With CUPS printing support" on \                 WINBIND         "With WinBIND support" on \                 SWAT            "With SWAT WebGUI" off \                 ACL_SUPPORT     "With ACL support" off \                 AIO_SUPPORT     "With Asyncronous IO support" off \                 FAM_SUPPORT     "With File Alteration Monitor" off \                 SYSLOG          "With Syslog support" off \                 QUOTAS          "With Disk quota support" off \                 UTMP            "With UTMP accounting support" off \                 PAM_SMBPASS     "With PAM authentication vs passdb backends" off \                 DNSUPDATE       "With dynamic DNS update(require ADS)" off \                 DNSSD           "With DNS service discovery support" off \                 EXP_MODULES     "With experimental modules" off \                 POPT            "With system-wide POPT library" on \                 MAX_DEBUG       "With maximum debugging" off \                 SMBTORTURE      "With smbtorture" off Так какой из вариантов из factorial(count_options) ты считаешь самым верным для бинарного пакета? :) Опционность software - это возможность иметь выбранную функциональность, но это и головная боль интегратора. Что бы не порождать N-подмножеств портированного software, в Linux-based distribution интеграторы формируют некий custom-набор из возможной логики, но не факт, что именно в данной ситуации он удовлетворяет техническим и эксплутационным требованиям. И еще один момент при использовании бинарных пакетов, не технический - мне часто встречаются "linux-куул-админы", испытывающие серъезные затруднения при необходимости самостоятельно откомпилировать software from source code, даже при использовании autotools. Остальное, в раздел юмора, по моему, не очень позитивного и конструктивного. Скорее мелко-злобного, извини, такое впечатление при чтении. В конечном итоге, software - только инструмент человека, повседневный и/или профессиональный. Возможно, ты встречался не с теми людьми.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	146. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 12-Окт-09, 13:44
	>FreeBSD Porter's Handbook >http://www.freebsd.org/doc/en/books/porters-handbook/makefil... > >See sections: >5.2.1 PORTNAME and PORTVERSION >5.2.2 PORTREVISION and PORTEPOCH Ну прочитал, соглашение для именования deb-пакетов выглядит примерно так же? PORTNAME_PORTVERSION-PORTREVISION_ARCH.deb PORTEPOCH нет, потому что версии вроде 20000801 обычно именуются так: 0.0.20000801, так что если разработчик вдруг выпустит версию 1.0, то никакие PORTEPOCH не понадобятся. Если же что-то подобное всё-таки происходит, то выпускают PORTNAME_PORTVERSION-PORTREVISION_ARCH.deb Но речь _вообще_, _абсолютно_ не об этом. Речь о том, что нет такой замороженной версии портов, затестированной по самое нехочу, где бы только вносились патчи, закрывающие уязвимость  пакете. Хочешь закрыть дырку - либо делай патч сам, либо обновляйся из текущей (или стабильной, не суть важно) ветки портов, где повышаются PORTVERSION, а не только PORTREVISION. Вот в стабильном дебиане именно такая система: если выпущена ветка stable, то PORTVERSION или PORTEPOCH в ней никогда уже не поменяются, будут меняться только PORTREVISION, где каждая ревизия будет закрывать определённую дырку и ничего более. Это даёт мне возможность в течение двух с лишним лет не думать о том, что при очередном обновлении нужно будет поправить где-то конфиг или прогнать какой-нибудь преобразователь базы MySQL в новый формат. Я могу просто поставить пакет cron-apt, настроить его на автоматическое обновление и система будет обновляться без моего участия, а я не буду бояться что что-то сломается и мне нужно будет срочно куда-то ехать, когда я расслабляюсь в отпуске на пляже или лежу после днюхи в дупель пьяный. >[оверквотинг удален] > >ports/net-mgmt/net-snmp/Makefile: >OPTIONS=        IPV6 "Build with IPv6 >support" on >             >    MFD_REWRITES "Build with 64-bit Interface Counters" off > >             >    PERL "Install additional perl modules" on >    PERL_EMBEDDED "Build embedded perl" on В пакете perl-modules. >             >    TKMIB "Install graphical MIB browser" off В пакете tkmib. У этой приблуды ровно две прямые зависимости libsnmp-perl и perl-tk. >    DUMMY "Enable dummy values as placeholders" on > >             >    DMALLOC "Enable dmalloc debug memory allocator" off Получается уже насчитали две ситуации, когда Debian гибче? >[оверквотинг удален] >    ADS       >      "With Active Directory support" off >\ >             >    CUPS       >     "With CUPS printing support" on \ > >             >    WINBIND       >  "With WinBIND support" on \ В отдельном пакете winbind. >    SWAT       >     "With SWAT WebGUI" off \ В отдельном пакете swat. >[оверквотинг удален] >             >    QUOTAS       >   "With Disk quota support" off \ >             >    UTMP       >     "With UTMP accounting support" off \ > >             >    PAM_SMBPASS     "With PAM >authentication vs passdb backends" off \ В отдельном пакете libpam-smbpass. >[оверквотинг удален] >             >    EXP_MODULES     "With experimental >modules" off \ >             >    POPT       >     "With system-wide POPT library" on \ > >             >    MAX_DEBUG       >"With maximum debugging" off \ Отладочные символы - в пакете samba-dbg. >             >    SMBTORTURE      "With >smbtorture" off В пакете samba-tools. Документация выделена в два отдельных пакета, один из них с pdf-доками. Поддержка монтирования smb-каталогов доступна при установке пакета smbfs, без установки самой samba. >Так какой из вариантов из factorial(count_options) ты считаешь самым верным для бинарного >пакета? :) Факториал - это количество перестановок. В данном случае, если каждая опция может быть только лишь включенной или выключенной, речь идёт о 2^count_options. >Опционность software - это возможность иметь выбранную функциональность, но это и головная >боль интегратора. >Что бы не порождать N-подмножеств портированного software, в Linux-based distribution интеграторы формируют >некий custom-набор из возможной логики, но не факт, что именно в >данной ситуации он удовлетворяет техническим и эксплутационным требованиям. Не факт, но для того, чтобы не ставить или наоборот, поставить swat, мне пересобирать в Debian ничего не потребуется. То же самое и с tkmib. Иногда отключение всего одной зависимости позволяет отказаться от установки ещё кучи всякого хлама. Например установка tkmib потянет за собой иксы. Хорошо, что её устновка отключена в портах, но если программа понадобится - порт нужно будет пересобирать. Не удобно. >И еще один момент при использовании бинарных пакетов, не технический - мне >часто встречаются "linux-куул-админы", испытывающие серъезные затруднения при необходимости самостоятельно откомпилировать software from source code, даже при >использовании autotools. Собрать из исходников - не проблема, проблема - собрать из исходников так, чтобы не засрать систему. Тут нужно либо ставить куда-нибудь в /opt/ (или в /usr/local), либо пытаться собрать двоичный пакет (это идеально), чтобы он обслуживался пакетной системой наравне с остальными программами. >Остальное, в раздел юмора, по моему, не очень позитивного и конструктивного. Скорее >мелко-злобного, извини, такое впечатление при чтении. В конечном итоге, software - >только инструмент человека, повседневный и/или профессиональный. Да, я специально попытался написать позлобнее, в некоторых местах это была гипербола. Но чтобы люди поняли, нужен шок, иначе всё это пройдёт мимо ушей как какое-то невнятное бормотание. В том, что software - только инструмент, согласен. Но хороший инструмент позволяет в повысить производительность десятки раз. Когда не думаешь о том, как правильно использовать инструмент, а инструмент сделан так, чтобы его невозможно было использовать неправильно, начинаешь думать не об инструменте, а о цели. >Возможно, ты встречался не с теми людьми. Не говорю, что все такие, но как правило среди встречавшихся мне фришников преобладают люди, которые ничего кроме фри и не знают. Отсюда такая злоба по отношению ко всему непонятному. С другой стороны те, кто фри не знают, ничего плохого о ней не говорят. Кто знает фри и линукс, обычно злится не на саму фри, а на её упёртых фанатиков, которым обычно бесполезно приводить какие-то аргументы в пользу линукса.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	147. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 12-Окт-09, 13:47
	>Если же что-то подобное всё-таки происходит, то выпускают PORTNAME_PORTVERSION-PORTREVISION_ARCH.deb Самофикс: Если же что-то подобное всё-таки происходит, то выпускают PORTNAMEPORTEPOCH_PORTVERSION-PORTREVISION_ARCH.deb.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	148. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 12-Окт-09, 15:16
	>>FreeBSD Porter's Handbook >>http://www.freebsd.org/doc/en/books/porters-handbook/makefil... >> >>See sections: >>5.2.1 PORTNAME and PORTVERSION >>5.2.2 PORTREVISION and PORTEPOCH > >Ну прочитал, соглашение для именования deb-пакетов выглядит примерно так же? Ну и слава богу. Не все же "после днюхи пьяным валятся" Мабуть, изучишь еще пару операционных систем. Вникнешь в их историю и текущее состояние. Перейдешь от голого критиканства к результативной деятельности. А там глядишь, да спроектируешь и сплотишь людей на новую систему портов. Продуманную и гибкую, удовлетворяющую техническим условиям и задачам. --- Более 10 лет поверхностной трепотни тысяч студеозусов о rpm & deb & ports - и ноль результата.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	149. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 12-Окт-09, 15:37
	>Ну и слава богу. Не все же "после днюхи пьяным валятся" Все или не все, но моё мнение - система должна быть рабом человека, а не человек - рабом системы. Человек должен отдыхать, а система - работать. И никак иначе. Если я не могу позволить себе расслабиться, из-за опасения в надёжности системы, то эта система плохая. >Мабуть, изучишь еще пару операционных систем. Вникнешь в их историю и текущее >состояние. >Перейдешь от голого критиканства к результативной деятельности. Ну разве не понятно, что я не с потолка взял мнение о FreeBSD? Я пользовался ею до Debian. приходилось админить Solaris 8 (хорошо хоть ставить её не приходилось), RedHat, имею представление о DragonFly BSD, NetBSD, в сильно меньшей степени - о Gentoo и Arch (не люблю компиляцию и bleeding-edge). В Solaris 8 с системой двоичных пакетов было вообще всё плохо, а обновления на систему ставятся как на винду - запускаемым бинарником. В RedHat всё было не плохо, за исключением отсутствия мягких зависимостей, а yum тогда вообще отсутствовал. DF BSD и NetBSD скорее академические изделия, нежели промышленные, но они интересны из-за собственной философии. Первая - ядром с лёгкими нитями ядра, вторая - своей юниксовой олдскульностью. >А там глядишь, да спроектируешь и сплотишь людей на новую систему портов. >Продуманную и гибкую, удовлетворяющую техническим условиям и задачам. Увы, каждый сверчок - знай свой шесток. Я не программист или программный архитектор, я админ. И даже если я стану программистом (не всю же жизнь быть админом), нужна будет предпринимательская жилка, чтобы пробить свой проект. Потому что количество крикунов "велосипед - ф топку" зашкаливает. Вон тут фришники как уже успели обосрать сабж, куда уж там им новые порты. Их вообще всё устраивает. А меня не устраивает - я проголосовал ногами, ушёл с FreeBSD на Debian. >--- >Более 10 лет поверхностной трепотни тысяч студеозусов о rpm & deb & >ports - и ноль результата. Идеально было бы, чтобы deb-пакеты генерировались из подобия портов (или портежей). Но предвижу выкрики фри-фанатиков "велосипед, ф топку, не нужно".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	150. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 12-Окт-09, 16:53
	>же жизнь быть админом), нужна будет предпринимательская жилка, чтобы пробить свой >проект. Для этого нужно просто общаться с народом, грамотно предлагать свои идеи, и таки что-то самому делать. Есть рассылки, форумы, люди в большей части адекватные и вменяемые - пообщайтесь. Только не забывайте, что вам никто ничего не должен. Это добровольцы. >Идеально было бы, чтобы deb-пакеты генерировались из подобия портов (или портежей). Но Действительно, не наблюдаю острой необходимости, хотя указанное действо не столь сложно. По комплексу причин. Одна из которых - система debian пакетирования далеко не идеал. В отношении комплекса тех задач, для которых существует подобные системы. Другая - для многослойного пакетирования и дистрибьюции требуются вычислительные, коммуникационные и человеческие ресурсы, которых не так много. Они требуются для более приоритетных задач. Задачи согласования, обновления, квалификации на возможности НД и прочее частично переложены на инженерный персонал, использующий BSD. Как правило, это достаточно квалифицированный персонал, для которого указанное - несложная задача. Это и остальное уже не раз обсуждалось, лениво пересказывать. >(не люблю компиляцию и bleeding-edge). Не любишь компилировать? Никак не освоить? Ну батенька, может вам MS Windows будет самое то? :) Да и кого, извини, будет интересовать твое мнение голимого потребителя, если ты ничего ни для одного из общественных проектов не сделал, в качестве финансового, трудового или иного вспоможения?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	161. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (??) on 13-Окт-09, 08:12
	>По комплексу причин. Одна из которых - система debian пакетирования далеко не >идеал. В отношении комплекса тех задач, для которых существует подобные системы. deb-пакеты - единственные известные мне двоичные пакеты, в которых есть мягкие зависимости. И поэтому они - идеал. >Другая - для многослойного пакетирования и дистрибьюции требуются вычислительные, коммуникационные и человеческие >ресурсы, которых не так много. >Они требуются для более приоритетных задач. Каких таких более приоритетных задач? По-вашему лучше переложить вопросы пакетирования на конечных пользователей, чем освободить их время для более продуктивной деятельности? Если каждый автор порта возьмёт на себя задачу по грамотному пакетированию всего-лишь одного своего порта, освободится огромное количество времени пользователей. Они будут тратить время не на ту работу, которая должна быть выполнена мэнтейнером, а займутся "более приоритетными задачами". Кто драйвер напишет, кто багрепорт накатает, кто документацию переведёт, а кто и другую систему освоит. Но по-вашему, получается что точить пилу некогда, нужно пилить. >Задачи согласования, обновления, квалификации на возможности НД и прочее частично переложены на >инженерный персонал, использующий BSD. >Как правило, это достаточно квалифицированный персонал, для которого указанное - несложная задача. Ваше утверждение не меняет абсолютно ничего. Ваш "квалифицированный персонал" будет выполнять работу мэнтейнеров. Он будет выполнять её хуже мэнтейнера пакета. Потому что мэнтейнер занимается только этим пакетом и поэтому хорошо его знает, а ваш специалист будет вынужден знать очень много пакетов. Количество часов в сутках для всех одинаково, поэтому ваш специалист будет знать каждый пакет значительно хуже команды мэнтейнеров. Для каждого пакет нужно будет тратить время на перекомпиляцию, на разбор с обновлениями и т.д. и т.п., а пакетов много. И того - ваш специалист будет тратить непропорционально много времени на сопровождение системы, а результат будет всё равно хуже. Добавим к этому ещё то, что квалифицированный персонал стоит дорого и он редок. Гораздо проще найти одного толкового спеца, при необходимости направить его на платные курсы с сертификацией, и добавить ему 20% к зарплате, чем найти, обучить, и платить зарплату троим. Иначе говоря, умные люди придумали разделение труда. Просто бизнес - ничего личного. Пока BSD'шники этого не поймут, им нет дороги в "ынтырпрайез", они так и останутся кустарями. >Это и остальное уже не раз обсуждалось, лениво пересказывать. Мне тоже было лениво, но я лишний раз пересказал. >>(не люблю компиляцию и bleeding-edge). >Не любишь компилировать? Никак не освоить? Да. Не люблю. Не потому что не освоить, а потому что на это уходит много времени. Непропорционально много. Собрать один пакетик для себя с нужными опциями - это одно, а собирать всё и вся при каждом обновлении - это другое, это для фанатиков наблюдения за бегущими по экрану строчками. И не люблю bleeding-edge. По той же причине - уходит много времени на разборки: "это я тупой или система поломана?" А когда выясняется, что система поломана, дополнительное время уходит на поиск источника проблемы и на поиск пути решения: то ли патч наложить, то ли откатиться, то ли другую программу выбрать, то ли вообще забить. >Ну батенька, может вам MS Windows будет самое то? :) [s]Смех-смехом, а пи... с мехом.[/s] Что ни говорите, а в Windows компилировать не приходится. Это не значит что все Windows-пользователи тупые или в Windows невозможно компилировать, там в большинстве случаев просто нет в этом необходимости. Хотя откуда ей взяться - это же закрытая система. Но по крайней мере в ней не приходится прибегать к компиляции при обновлении. >Да и кого, извини, будет интересовать твое мнение голимого потребителя, если ты >ничего ни для одного из общественных проектов не сделал, в качестве >финансового, трудового или иного вспоможения? Тактика http://lurkmore.ru/%D0%A1%D0%BF%D0&... не отменяет того, что порты FreeBSD - говно :) Позвольте процитировать: Варианты беспроигрышной контратаки     * Не нужно быть поваром, чтобы оценить блюдо.     * Не нужно быть курицей, чтобы понять, что яйцо — тухлое.     * Не обязательно быть коровой, чтобы судить о вкусе молока.     * Не нужно быть говном, чтобы понять, что это говно.     * Необязательно быть поленом, чтобы знать, что такое огонь.     * Для того чтобы судить об Аде, Данте не потребовалось в нем побывать.     * Не обязательно выпить все море, чтобы понять, что вода в нем соленая.     * Я не пивовар, но это не делает хреновое пиво хорошим.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	163. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 13-Окт-09, 09:49
	>Каких таких более приоритетных задач? По-вашему лучше переложить вопросы пакетирования на конечных >пользователей, чем освободить их время для более продуктивной деятельности? Если каждый >автор порта возьмёт на себя задачу по грамотному пакетированию всего-лишь одного >своего порта, освободится огромное количество времени пользователей. Они будут тратить У тебя есть прекрасная возможность показать на деле свою грамотность - спроектировать новую систему портов. Более эффективную, приемлимую по техническим и организационным условиям. Реализовать прототип системы пакетирования и дистрибьюции, убедить народ в его эффективности. Народ вменяемый, в большинстве грамотный, с опытом работы. Только еще раз напоминаю - это добровольцы. Тебе они ничего не должны. Списки рассылки на www.freebsd.org, по ссылкам можно найти другие контакты. Или ты думаешь твое переливание из пустого в порожнее, сидя ровно на известном месте, что-то конструктивно поменяет в _общественных_ проектах? Тем более что проблема взята с потолка по большей части.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	164. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от Аноним (??) on 13-Окт-09, 10:11
	>У тебя есть прекрасная возможность показать на деле свою грамотность У меня есть много возможностей, почему я должен выбрать именно ту, которую вы мне предлагаете? Если что-то делается just for fun, а я фана от этого не испытываю, по-вашему мне нужно себя насиловать? >Или ты думаешь твое переливание из пустого в порожнее, сидя ровно на >известном месте, что-то конструктивно поменяет в _общественных_ проектах? Я же сказал, я проголосовал ногами - перешёл с FreeBSD на Debian. А всё это я здесь пишу не для того, чтобы убедить кого-то в том, что порты хуже двоичных пакетов. Понятия "хуже" и "лучше" относительны. В разных ситуациях бывают разные преимущества. Я пишу лишь для того, чтобы кто-нибудь понял, что Debian GNU/kFreeBSD - проект не бессмысленный, он делается не ради гордыни, а ради вполне понятных преимуществ, преимуществ от каждой из двух систем. >Тем более что проблема взята с потолка по большей части. Ты чем-нибудь кроме FreeBSD, Gentoo или Arch пользовался? Почему-то складывается ощущение, что нет. Или пользовался не настолько долго, чтобы устать от них. Ну не может человек реально посопровождавший одновременно FreeBSD и Debian не ощутить разницы во времени, необходимом на сопровождение той и другой системы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	167. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 13-Окт-09, 11:41
	>У меня есть много возможностей, почему я должен выбрать именно ту, которую >вы мне предлагаете? Если что-то делается just for fun, а я >фана от этого не испытываю, по-вашему мне нужно себя насиловать? Понял. Толку - ноль, как ни крути :) >для того, чтобы кто-нибудь понял что Debian GNU/kFreeBSD - проект не >бессмысленный, он делается не ради гордыни, а ради вполне понятных преимуществ, >преимуществ от каждой из двух систем. Какие "понятные преимущества"? Для кого понятные? Что за преимущества? Постоянное отставание в коде? Отсутствие внятной связи с имеющимися bsd-проектами? Удаление ZFS? Удаление libc? И так далее? Да у них косяков вылезет больше, чем в оригинальных системах, до этого франкенштейна. Ты думаешь, люди из bsd core developers не знают про системы пакетирования и прочее? Может ты напишешь им, или и дальше будешь трепатся в курилке? :) The FreeBSD Developers http://www.freebsd.org/doc/en/articles/contributors/staff-co... NetBSD Developers http://www.netbsd.org/people/developers.html
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	168. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от Аноним (??) on 13-Окт-09, 12:49
	>Понял. Толку - ноль, как ни крути :) >>для того, чтобы кто-нибудь понял что Debian GNU/kFreeBSD - проект не >>бессмысленный, он делается не ради гордыни, а ради вполне понятных преимуществ, >>преимуществ от каждой из двух систем. > >Какие "понятные преимущества"? Перечитай ещё раз http://www.opennet.me/openforum/vsluhforumID3/59688.html#146, если не понял. Тезисно: гибкие зависимости, стабильная ветка. >Для кого понятные? Что за преимущества? Понятные мне и толпе дебианщиков. Не понятные тебе даже после стольких разъяснений и куче таких же как ты упёртых фришников. >Постоянное отставание в коде? В Debian кроме ветки stable есть ветки testing и unstable. Я уже понял тебя, для тебя "отставание - всегда плохо". И ниибёт. А что мне делать, если софт пятилетней давности меня устраивает по функциям, а свежий не устраивает по надёжности? У меня есть выбор, у тебя - нет. >Отсутствие внятной связи с имеющимися bsd-проектами? Это мэнтейнер пакета с ядром FreeBSD в Debian: http://www.google.ru/search?hl=ru&client=firefox-a&rls=org.m... Скажи, что он ничего не сделал для FreeBSD? >Удаление ZFS? Кто удалил? На странице http://wiki.debian.org/Debian_GNU/kFreeBSD_why написано, что возможно поддержка ZFS будет в ядре по умолчанию. Проблема наверное в поддержке GRUB'ом загрузки ядра с раздела в ZFS, или в инсталляторе, который не умеет ставить систему на ZFS, или в том, что в ядре FreeBSD 7.2 поддержка ZFS имеет какие-то проблемы. Во всяком случае запретить использовать ZFS вам никто не сможет, а из ядра ZFS с корнем никто не вырывает. >Удаление libc? Я вам больше скажу, дебианщики настолько обнаглели, что выкинули из Debian GNU/Linux и glibc :D Вы не понимаете простую вещь - они выкинули libc не по политическим причинам, а по экономическим. Зачем им переводить все пакеты на libc, когда они и под eglibc нормально работают? Зачем им использовать в половине Debian'а glibc, а в другой - libc? Чтобы объём работы для всех мэнтейнеров увеличился в два раза (потому что им тогда придётся сопровождать каждый пакет одновременно на libc и eglibc)? Именно поэтому и было решено остановиться на одной библиотеке. При чём проект Debian GNU/kFreeBSD и начинался именно с портирования glibc на ядро FreeBSD. Им сейчас ради вашего непонятного принципа "хочу libc" всё заново начинать что-ли и делать двойную работу по сопровождению двух систем? >И так далее? Как далее? Ни одного убедительного аргумента против Debian GNU/kFreeBSD я не услышал. Перестаньте упираться рогом в FreeBSD, на ней свет клином не сошёлся, есть масса других систем и людей с другим мышлением. >Да у них косяков вылезет больше, чем в оригинальных системах, до этого >франкенштейна. Поживём - увидим. Я качеству работы ментейнеров Debian доверяю. >Ты думаешь, люди из bsd core developers не знают про системы пакетирования >и прочее? Они знают, но системы пакетирования находятся за пределами их задач. Они занимаются только базовой системой - не более. >Может ты напишешь им, или и дальше будешь трепатся в курилке? :) Может ты напишешь? Я подозреваю, что я далеко не первый, кто это пишет. Только ты будешь не первым, кто наткнётся на стену непонимания фришников. >The FreeBSD Developers >http://www.freebsd.org/doc/en/articles/contributors/staff-co... > >NetBSD Developers >http://www.netbsd.org/people/developers.html Кстати, в NetBSD ситуация с pkgsrc значительно лучше, пусть разработчики FreeBSD учатся на их примере.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	169. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 13-Окт-09, 14:56
	>>Понял. Толку - ноль, как ни крути :) >>>для того, чтобы кто-нибудь понял что Debian GNU/kFreeBSD - проект не >>>бессмысленный, он делается не ради гордыни, а ради вполне понятных преимуществ, >>>преимуществ от каждой из двух систем. >> >>Какие "понятные преимущества"? > >Перечитай ещё раз http://www.opennet.me/openforum/vsluhforumID3/59688.html#146, если не понял. Тезисно: гибкие зависимости, стабильная ветка. Ах они "упертые фришники", ничего то они не понимают, тут "толпа дебианщиков" с "мягкими зависимостями" предлагает "идеал", и может даже сделают "загрузку с zfs по умолчанию", только "наверное" проблемы с grub :) Спасибо, развлек :) Детский сад, че слово... Молодой человек, проект Debian мне известен с 1996 года, если не изменяет память, первый стабильный дистрибутив назывался Buzz. Компакт специально заказывал. Впрочем, тогда меня устраивала самосборная линуксячесть на базе Slackware. Но спустя какое-то время лет, "интеллектуальность" Debian стала мерзкой - в пакеты напихивали скриптов, за которые хотелось просто прибить разработчиков под горячую руку. Сама система стала монстроидной, перегруженной избыточной "AI" логикой. В grub, который первый, нет портируемого stage1.5 (pre_stage2) for zfs, точнее есть, но как доработка SUN, для Solaris. Где-то была ссылка на их репозитарий, с наскока мне оттель портировать не удалось. Впрочем, /usr/src/sys/boot/i386/zfsboot уже вполне рабочий. # zfs list NAME                 USED  AVAIL  REFER  MOUNTPOINT netzroot            3,09G   813M  99,5M  / /usr/src/lib/libc содержит довольно много специфичного кода, с которым связана остальная логика системы, как ты пишешь, "возможности", ради которых весь сыр-бор в Debian. SCTP, name service, sockets operation, systen information, NLC, RPC, MAC, extended ACL, ... Достаточно просто глянуть в код libc, и твои заявления насчет "экономики", "пошли дальше" и "вашего непонятного принципа "хочу libc", извини, на этом фоне выглядят полной ахинеей. Код между BSD проектами постоянно переносится, в любой BSD OS можно найти туеву хучу кода из другой BSD OS. Так что "пусть учатся у " звучит, ну как-то, пустозвонством. Наскидку # grep -l NetBSD /usr/src/sys/*/*.[ch] /usr/src/sys/*/*/*.[ch] | wc -l      621 # ls -1 /usr/src/sys/*/*.[ch] /usr/src/sys/*/*/*.[ch] | wc -l     4942 Насчет непонимания. "Достали, ламерюги проклятые, все им дай, дай, дай". Пиши действительно по делу, с деловым предложением, и тебя прекрасно поймут. Везде.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	170. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 13-Окт-09, 15:39
	>Ах они "упертые фришники", ничего то они не понимают, тут "толпа дебианщиков" >с "мягкими зависимостями" предлагает "идеал", и может даже сделают "загрузку с >zfs по умолчанию", только "наверное" проблемы с grub :) Дебианщики делают проект для себя, не для фришников. Повторюсь, я вижу только одну причину, по которой фришники встречают в штыки новую систему - они боятся, что кто-то будет пользоваться их святым ядром и получать с этого профит, не трахаясь с портами. Ещё бы, вот они освоили порты, ходят такие с завышенным ЧСВ, срут на линупсы, а тут какой-нибудь недавний убунтушник поставит систему и будет ей пользоваться, не трахаясь с портами. Клоунаду можешь оставить при себе, она на меня не действует. >Но спустя какое-то время >лет, "интеллектуальность" Debian стала мерзкой - в пакеты напихивали скриптов, за >которые хотелось просто прибить разработчиков под горячую руку. Сама система стала >монстроидной, перегруженной избыточной "AI" логикой. Я с этой монстроидальностью разобрался и меня она устраивает. (Так и хочется применить тот аргумент, который применяют фришники, когда слышат что я не люблю компилировать - "не осилил". Но воздержусь.) >В grub, который первый, нет портируемого stage1.5 (pre_stage2) for zfs, точнее есть, Ты проигнорировал остальные предположения - просто я не слежу за процессом разработки системы через рассылки. Наиболее вероятно то, что нет готового инсталлятора на ZFS. >/usr/src/lib/libc содержит довольно много специфичного кода, с которым связана остальная логика системы, >как ты пишешь, "возможности", ради которых весь сыр-бор в Debian. >SCTP, name service, sockets operation, systen information, NLC, RPC, MAC, extended ACL, >... Достаточно просто глянуть в код libc, и твои заявления насчет >"экономики", "пошли дальше" и "вашего непонятного принципа "хочу libc", извини, на >этом фоне выглядят полной ахинеей. >SCTP, name service, sockets operation, RPC Что из этого отсутствует в glibc? >NLC, Что это? Гугление результатов не дало. Опечатка? >systen information, MAC, extended ACL Ядро-специфичным фишкам место в отдельных библиотеках, которыми должны пользоваться отдельные утилиты (наверняка единственные программы, знающие об этих фишках - это утилиты из состава базы). Не зря glibc изначально делалась переносимой, а libc - нет. >Код между BSD проектами постоянно переносится Речь вообще-то шла о pkgsrc, а не о ядре. pkgsrc лучше портов - есть стабильные ветки, pkgsrc можно развернуть почти на любой Unix-системе. А то, что все BSD заимствуют друг у друга, я и так знаю. >Насчет непонимания. "Достали, ламерюги проклятые, все им дай, дай, дай". >Пиши действительно по делу, с деловым предложением, и тебя прекрасно поймут. Везде. Я написал почему проект имеет право на существование, наглядно пояснил почему порты в нынешнем виде не удобны. Ты не понял. Я повторил. Ты начал опять брызгать слюной. Если там в во фришных рассылках все фришники такие же как ты, то фри обречена. Ты лишний раз проиллюстрировал собственной персоной сложившийся у меня стереотип фришника. Больше разговаривать с тобой я не намерен.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	171. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 13-Окт-09, 17:42
	>>Ах они "упертые фришники", ничего то они не понимают, тут "толпа дебианщиков" >>с "мягкими зависимостями" предлагает "идеал", и может даже сделают "загрузку с >>zfs по умолчанию", только "наверное" проблемы с grub :) > >Дебианщики делают проект для себя, не для фришников. Повторюсь, я вижу только >одну причину, по которой фришники встречают в штыки новую систему - >они боятся, что кто-то будет пользоваться их святым ядром и получать >с этого профит, не трахаясь с портами. Ещё бы, вот они Обиделся, поди, святых начал упоминать :) Насчет кода - ты не гугли, ты в него самый посмотри, в первоисточник. Мабуть, не смотрел ни разу? :) Что б не загромождать сильно, руководства для примера и начала system depended API. Это только примеры, там увязок гораздо больше. # man 3 mac NAME      mac — introduction to the MAC security API LIBRARY      Standard C Library (libc, -lc) SYNOPSIS      #include <sys/mac.h> # man 3 acl NAME      acl — introduction to the POSIX.1e ACL security API LIBRARY      Standard C Library (libc, -lc) SYNOPSIS      #include <sys/types.h>      #include <sys/acl.h> # man sctp_connectx NAME      sctp_connectx — connect an SCTP socket with multiple destination      addresses. LIBRARY      Standard C Library (libc, -lc) SYNOPSIS      #include <sys/types.h>      #include <sys/socket.h>      #include <netinet/sctp.h> # man 3 setlocale NAME      setlocale — natural language formatting for C LIBRARY      Standard C Library (libc, -lc) SYNOPSIS      #include <locale.h> #uname -v FreeBSD 8.0-RC1 #10 r197979: Mon Oct 12 17:09:26 EEST 2009 Имеющаяся libc - стабильный и выверенный код, используемый всем програмным обеспечением системы. И предлагается заменить это на eglibc, которая является сторонним проектом для внедряемых систем, и которую еще отлаживать и отлаживать? С какого перепугу? :) А потом будет новый bsd-проект, который потребует изменений как в ядре, так и в системных библиотеках. И что тогда? Кто занимался программированием, прекрасно понимает какой дурной объем работы это за собой тянет. Кто будет этим заниматся, _на добровольных началах_, что бы доводить до ума в Debian? Восторженные потребители халявы, не любящие компилировать? И прежде чем разговаривать о системе, неплохо бы ознакомится c особенностями и структурой логики операционной системы, а не знать о ней поверхностно и понаслышке. "Упертые фришники", "брызгать слюной", "Я. Я. Я", "ты не понял". Ну детcкий сад :) Да все я понял. Стебаюсь, есть время. >Больше разговаривать с тобой я не намерен. Да хоть застрелись :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	165. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 13-Окт-09, 10:12
	>>Каких таких более приоритетных задач? По-вашему лучше переложить вопросы пакетирования на конечных >>пользователей, чем освободить их время для более продуктивной деятельности? Если каждый >>автор порта возьмёт на себя задачу по грамотному пакетированию всего-лишь одного >>своего порта, освободится огромное количество времени пользователей. Они будут тратить Вдогонку. Надеюсь прочитать о твоих успехах в общественной IT-деятельности через несколько лет. Для начала, в общем мыслишь в верном направлении. Осталось кое в чем научится, и реализовать. И почитай http://www.freebsd.org/doc/ru/books/faq/funnies.html#CHANGIN... Этому больше десятка лет :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	166. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 13-Окт-09, 10:22
	>И почитай >http://www.freebsd.org/doc/ru/books/faq/funnies.html#CHANGIN... >Этому больше десятка лет :) Читал.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	154. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Денис Юсупов on 12-Окт-09, 17:21
	Не понимаю, откуда столько шума. Сколько серверов ни обслуживал, ни разу не возникало неразрешимых проблем с/после обновления портов/пакетов. Ладно ещё 10 лет назад, действительно время сборки из портов было актуально, а сейчас-то чего жаловаться? У меня ядро за 3-5 минут пересобирается, железо нынче настолько мощное. Есть distcc, которое эффективно раскидывает компиляцию на несколько машин, есть "make package" с нужными вам опциями из портов для дистрибьюции на остальные машины. Ну да, наличие чисто stable-ветки портов звучит интересно...но не более того. Поскольку "и так всё работает". P.S. Упёртые линуксоиды встречаются на порядок чаще упёртых фряшников. ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	162. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 13-Окт-09, 08:17
	>P.S. Упёртые линуксоиды встречаются на порядок чаще упёртых фряшников. ;) Просто линуксоидов больше. А соотношение в процентном отношении никому не известно :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (ok) on 09-Окт-09, 09:56
	>Видимо, но их число безразлично мало Видимо достаточно, если разработчики Debian GNU/kFreeBSD не включились в разработку самой FreeBSD. Для меня одного меня вполне достаточно. Мне не нравятся порты и концепция базовой системы, но ядро FreeBSD нравится.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

50. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
Сообщение от Аноним (??) on 09-Окт-09, 00:39
Интересно хватит ума начать именно с "реализации драйвера для работы с EXT2/EXT3 разделами" и потом хватит ли ума BSD включить это чудо в ядро и самый главный вопрос, а как насчет лицензий??? BSD -> GPL может, а вот обратно прокатит ли? P.S. Может можно будет послать нахер этот Debian, а вот FreeBSD с поддержкой EXT - это круто!!!
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от pavel_simple (ok) on 09-Окт-09, 00:42
	>P.S. Может можно будет послать нахер этот Debian, а кто вам запрещает -- я так понимаю никто не огорчиться >а вот FreeBSD с поддержкой EXT - это круто!!! считаете??? -- даже странно - последнее время все нахваливают ZFS чуть-ли как не лучшее что есть -- вы не согласны?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Alatar (??) on 09-Окт-09, 01:13
	Да, только Линухи её не умеют... И UFS они поддерживают так же хорошо, как фря - EXT... NTFS под никсами я вообще не доверяю. Что ж остаётся, в качестве универсальной ФС для всех систем использовать FAT32? Это, конечно, чисто десктопная заморочка, но тем не менее...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от QuAzI (ok) on 09-Окт-09, 01:24
	Как не умеют? А через fuse? Её же на уровне readonly даже Mac OS X умеет, опять таки одни вантузы в пролёте.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	80. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от User294 (ok) on 09-Окт-09, 11:37
	>а вот FreeBSD с поддержкой EXT - это круто!!! А что такого крутого в ФС эпохи царя гороха? Да и EXT4 (наиболее нормальный из EXTов) поди как всегда или не будет поддерживаться или через хренадцать лет только.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

56. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
Сообщение от Анонимный on 09-Окт-09, 01:15
А в каком состоянии GNU/HURD? Там обещали много вкусных плюшек...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

58. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
Сообщение от Аноним (??) on 09-Окт-09, 02:36
У сквиза три глаза, надо было ещё Debian GNU/Hurd выпустить, что бы с трёх точек на мир смотреть ! :) Debian круче всех ! :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от rm (??) on 09-Окт-09, 03:14
	> надо было ещё Debian GNU/Hurd выпустить Как жаль, что они об этом не подумали! http://www.debian.org/ports/hurd/ :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 09-Окт-09, 03:43
	он ещё не готов и в сквиз не войдёт, эх... кто там ещё трёхглазый есть в Toy Story ? :) Ха ! или GNU/Hurd выдет с именем Zurg ? :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Серж (??) on 09-Окт-09, 08:17
	Даешь Debian GNU/QNX!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	75. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+2 +/–
	Сообщение от Alan Makoev (ok) on 09-Окт-09, 11:07
	Даешь Debian GNU/RTEMS! Даешь Debian GNU/FreeDOS! :))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	90. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Анонимный on 09-Окт-09, 13:33
	Вот это было бы интересно. ОС с микроядром, которая не тормозит. А лицензия QNX это позволит?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	93. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 09-Окт-09, 13:50
	>Вот это было бы интересно. ОС с микроядром, которая не тормозит. А кто вам сказал, что она не тормозит? Микроядро изначально как раз тормознутее монолита. А "real-time" означает лишь гарантированное время реакции на событие, а не скорость работы модуля, осуществляющего эту самую реакцию. >А лицензия QNX это позволит? Нет: You must obtain a written license from and pay applicable license fees to QNX Software Systems before you may reproduce, modify or distribute this software, or any work that includes all or part of this software.   Free development licenses are available for evaluation and non-commercial purposes.  For more information visit http://licensing.qnx.com or email licensing@qnx.com.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	155. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Денис Юсупов on 12-Окт-09, 17:24
	>>А лицензия QNX это позволит? > >Нет: > >You must obtain a written license from and pay applicable license fees >to QNX Software Systems before you may reproduce, modify or distribute >this software, or any work that includes all or part of >this software.   Free development licenses are available for evaluation >and non-commercial purposes.  For more information visit http://licensing.qnx.com or email >licensing@qnx.com. Не вижу из приведённого участка ничего, что мешало бы выпустить такую версию. Да, требуется лицензия, но она бесплатная при условии некоммерческих целей - с которой Linux и распространяется.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	160. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 12-Окт-09, 18:57
	>[оверквотинг удален] >>You must obtain a written license from and pay applicable license fees >>to QNX Software Systems before you may reproduce, modify or distribute >>this software, or any work that includes all or part of >>this software.   Free development licenses are available for evaluation >>and non-commercial purposes.  For more information visit http://licensing.qnx.com or email >>licensing@qnx.com. > >Не вижу из приведённого участка ничего, что мешало бы выпустить такую версию. >Да, требуется лицензия, но она бесплатная при условии некоммерческих целей - >с которой Linux и распространяется. Нет. Linux бесплатен и для коммерческого использования, при условии доступности исходных текстов (как уже уточнялось, для клиентов). Если хотите, можете попробовать уговорить QNX распространять Neutrino под GPL. Вот только, боюсь, что QNX, будучи Злобным Пропиетарщиком™, вас кое-куда пошлёт. ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

72. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
Сообщение от Аноним (??) on 09-Окт-09, 10:36
Даешь Debian GNU/kInferno!
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	74. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от Andrey Mitrofanov on 09-Окт-09, 10:59
	Да, чего там - _начинай_. Мы не против.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+1 +/–
	Сообщение от User294 (ok) on 09-Окт-09, 11:25
	>Даешь Debian GNU/kInferno! Хоть Debian/qnx... осталось только найти кто этим будет пользоваться и поддерживать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	94. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 09-Окт-09, 13:51
	>>Даешь Debian GNU/kInferno! > >Хоть Debian/qnx... осталось только найти кто этим будет пользоваться и поддерживать. Не выйдет. Повторю свой коммент выше: >Вот это было бы интересно. ОС с микроядром, которая не тормозит. А кто вам сказал, что она не тормозит? Микроядро изначально как раз тормознутее монолита. А "real-time" означает лишь гарантированное время реакции на событие, а не скорость работы модуля, осуществляющего эту самую реакцию. >А лицензия QNX это позволит? Нет: You must obtain a written license from and pay applicable license fees to QNX Software Systems before you may reproduce, modify or distribute this software, or any work that includes all or part of this software.   Free development licenses are available for evaluation and non-commercial purposes.  For more information visit http://licensing.qnx.com or email licensing@qnx.com.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	128. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от User294 (ok) on 09-Окт-09, 20:54
	>Не выйдет. Я и не сомневался ;) >Повторю свой коммент выше: Не требуется, я и без вас это знаю. Так, прикалываюсь над затеей. >а не скорость работы модуля, осуществляющего эту самую реакцию. Некоторые очень по своему воспринимают слово реалтайм. У х86 угробища вообще реалтаймность плохая, реакция на события - тормозная очень, несмотря на гигагерцы.И плохо предсказуема по времени. >>А лицензия QNX это позволит? >Нет: Ну да, все так.Но мало ли каких извращенцев на свете :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	89. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (ok) on 09-Окт-09, 13:15
	>Даешь Debian GNU/kInferno! Это будет эпический фэйл. Концепция систем настолько разная, что вряд-ли кому-то действительно нужно будет это дикое сочетание. В лучшем случае получится виртуальная машина, работающая поверх Inferno, внутр которой будет работать Debian.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	113. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от xxx (??) on 09-Окт-09, 17:07
	Это уже будет эпическое извращение =) Но можно будет сделать Debian внутри которого Inferno, внутри которой Debian, внутри которого Inferno, ... И тогда Plan9 перестанет хвастать rio запущенным внутри окна rio =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	156. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Денис Юсупов on 12-Окт-09, 17:25
	>Даешь Debian GNU/kInferno! Да ладно, чего мелочиться-то, "даёшь Debian GNU/Windows"! :D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

84. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
Сообщение от Bulgarin on 09-Окт-09, 12:46
Несколько абсурдный проект, по совокупности. Пожалуй, основное - У системы (именно, не ядра, а операционой системы) свои разработчики, либо каждый раз нужно переносить апдейты из FreeBSD, либо нужно становиться со-разработчиками FreeBSD, со всеми вытекающими - работа подсистем FreeBSD обеспечивается рядом взаимоувязанных модулей, библиотек и утилит. - адаптация ПО к FreeBSD - в совокупности очень емкая деятельность. В проекте FreeBSD - GNU-tools и так все портированы во FreeBSD, пользуйся на здоровье. Ну если парням хочется делать двойную, а то и тройную работу, то - аллах акбар. Действительно, раз так нефик делать, лучше бы занялись ext2/3/4 или еще чем более актуальным, а не скрещивать ужа и ежа.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	86. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (ok) on 09-Окт-09, 13:08
	>Несколько абсурдный проект, по совокупности. >Пожалуй, основное >- У системы (именно, не ядра, а операционой системы) свои разработчики, либо >каждый раз нужно переносить апдейты из FreeBSD, либо нужно становиться со-разработчиками >FreeBSD, со всеми вытекающими А как вы думаете делается Debian? Именно так и делается. У каждого пакета или архитектуры есть ответственное лицо или группа ответственных лиц, они держат связь с разработчиками и совместными усилиями латают дырки и исправляют неисправности. >- работа подсистем FreeBSD обеспечивается рядом взаимоувязанных модулей, библиотек и утилит. Хотите сказать, что в Debian не будет средств для управления ядром FreeBSD или Debian будет их переизобретать? >- адаптация ПО к FreeBSD - в совокупности очень емкая деятельность. В проекте FreeBSD >- GNU-tools и так все портированы во FreeBSD, пользуйся на здоровье. Суть в том, что легче уже готовый Debian перевести на ядро FreeBSD, чем сопровождать ещё один юзерспейс, но основанный не на GNU libc, а на BSD'шной libc. Мэнтейнеры у всех пакетов в Debian уже есть, для них не изменится почти ничего - добавятся две новые архитектуры и всего-лишь. >Ну если парням хочется делать двойную, а то и тройную работу, то >- аллах акбар. Не хочется, именно поэтому они и не делают свою FreeBSD. Они как делали свой Debian, так и делают. Добавили небольшую по отношению к имеющимся наработкам часть, которую сопровождать будет легче, чем ещё одну независимую систему. >Действительно, раз так нефик делать, лучше бы занялись ext2/3/4 или еще чем >более актуальным, а не скрещивать ужа и ежа. Людей в Debian держит не зарплата, а "джастфофан". Каждый делает то, что ему нравится и не вам указывать, чем им следует заняться.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	105. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin on 09-Окт-09, 16:08
	>>Несколько абсурдный проект, по совокупности. >>Пожалуй, основное >>- У системы (именно, не ядра, а операционой системы) свои разработчики, либо >>каждый раз нужно переносить апдейты из FreeBSD, либо нужно становиться со-разработчиками >>FreeBSD, со всеми вытекающими > >А как вы думаете делается Debian? Именно так и делается. У каждого Бла-бла-бла-тысяча-сто-первый-раз, извините, лет 15 это наблюдаю :) Товарищи Вместо цели написания действительно функционального кода в очередной раз решили заниматься джастофаном ради джастофана, с небольшим побочным полезным результатом. Да и то порытым в недрах пакетов Debian, патчем на пропатченый патч. Иначе как амбициозностью это проект объяснить не могу. В свое время была такая же горячая переписка... Debian GNU/NetBSD http://www.debian.org/ports/netbsd/ ... Download experimental install floppies (last updated 6th October 2002)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	111. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (??) on 09-Окт-09, 16:50
	>Бла-бла-бла-тысяча-сто-первый-раз, извините, лет 15 это наблюдаю :) >Товарищи Вместо цели написания действительно функционального кода в очередной раз решили заниматься >джастофаном ради джастофана, с небольшим побочным полезным результатом. То же самое можно сказать о разработчиках FreeBSD. >Да и то порытым в недрах пакетов Debian, патчем на пропатченый патч. Это те немногие люди, что доводят дело до конечного результата. А те, кто пишет программы, чаще всего тоже делают это джастфофан - плевать они хотели на десктопы пользователей, их образ мыслей примерно таков "Я пишу для себя, у меня это работает, а на остальных насрать." >Иначе как амбициозностью это проект объяснить не могу. > >В свое время была такая же горячая переписка... >Debian GNU/NetBSD http://www.debian.org/ports/netbsd/ >... >Download experimental install floppies (last updated 6th October 2002) Опомнись, проект Debian GNU/kFreeBSD тоже не сегодня появился. И в отличие от названных, они доказали свою готовность трудиться ради достижения результата. Именно поэтому их труд и получил поддержку уже не как experimental, а как почти готовый stable.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	115. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 09-Окт-09, 17:13
	>>Бла-бла-бла-тысяча-сто-первый-раз, извините, лет 15 это наблюдаю :) >>Товарищи Вместо цели написания действительно функционального кода в очередной раз решили заниматься >>джастофаном ради джастофана, с небольшим побочным полезным результатом. > >То же самое можно сказать о разработчиках FreeBSD. Можно сказать что угодно о чем угодно, не убудет. Когда человек пишет geom или cam, портирует packet filter, это добавляет функциональности. Когда прикручивают apt и glibc, попутно удаляя ту функциональность что уже есть и устойчиво работает - как-то уже не понимаю. Ради косметики и галочки? Или ради амбиций? Толку-то? Все одно тот-же cp, mkdir, gmake, ... >>Да и то порытым в недрах пакетов Debian, патчем на пропатченый патч. > >Это те немногие люди, что доводят дело до конечного результата. А те, >кто пишет программы, чаще всего тоже делают это джастфофан - плевать >они хотели на десктопы пользователей, их образ мыслей примерно таков "Я >пишу для себя, у меня это работает, а на остальных насрать." С уважением отношусь в разработчикам Debian. Грамотная задумка, понравилась еще в конце 90-х. Но и они иногда занимаются фигней.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	116. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (??) on 09-Окт-09, 17:33
	>Можно сказать что угодно о чем угодно, не убудет. Убудет. Плодится информационный мусор. Не имеющие под собой основания мысли луше держать при себе. >Когда человек пишет geom или cam, портирует packet filter, это добавляет функциональности. >Когда прикручивают apt и glibc, попутно удаляя ту функциональность что уже >есть и устойчиво работает - как-то уже не понимаю. >портирует packet filter >прикручивают apt и glibc Объясните в чём разница? Портирует или прикручивает? Фактически один и тот же смысл, но с разным эмоциональным оттенком. А может быть это FreeBSD прикручивает pf, а Debian портирует ядро FreeBSD под свою платформу? И, кстати, Debian не хочет осчастливить вас прелестями apt'а и glibc, он хочет осчастливить дебианщиков прелестями FreeBSD. Это делается не для вас, поэтому вас забыли спросить нужно вам это или нет. >Ради косметики и галочки? Или ради амбиций? Ради того, чтобы сделать мир совершеннее. FreeBSD не совершенна. Успокойтесь, если вы не понимаете зачем делается Debian GNU/kFreeBSD, значит она делается не для вас. >Толку-то? Все одно тот-же cp, mkdir, gmake, ... Поэтому и взяли не bsd libc, gnu libc, потому что у Debian всё это уже есть. Разницы нет ни какой, а если использовать gnu libc, нужно будет делать меньше работы. >>>Да и то порытым в недрах пакетов Debian, патчем на пропатченый патч. >> >>Это те немногие люди, что доводят дело до конечного результата. А те, >>кто пишет программы, чаще всего тоже делают это джастфофан - плевать >>они хотели на десктопы пользователей, их образ мыслей примерно таков "Я >>пишу для себя, у меня это работает, а на остальных насрать." > >С уважением отношусь в разработчикам Debian. Грамотная задумка, понравилась еще в конце >90-х. Но и они иногда занимаются фигней. Если вы действительно понимаете всю грамотность задумки Debian, то для вас не составит труда понять и этот проект. С их позиции FreeBSD - жемчужина, а порты (том виде, в котором они есть сейчас) - какашка. И по-моему они правы. Вот разрабатывались бы порты по правилам Debian с выпуском и поддержкой stable-ветки в течение нескольких лет, возможно Debian GNU/kFreeBSD был бы не нужен. Лично я FreeBSD в том виде, в котором она существует сейчас, ставить на сервер не стану - процесс поддержки слишком красноглаз: вместо закрытия дырок обновление на следующую версию программы, вместо гибких зависимостей - компиляция из портов. У FreeBSD в настоящее время есть лишь один путь получить моё признание и признание многих других не красноглазых серьёзных пользователей, и этот путь через Debian GNU/kFreeBSD.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	121. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 09-Окт-09, 18:02
	>Если вы действительно понимаете всю грамотность задумки Debian, то для вас не >составит труда понять и этот проект. Понимаю. Сам такое хотел сотворить лет 12 назад. Фигней занимаются. >Ради того, чтобы сделать мир совершеннее. FreeBSD не совершенна. Успокойтесь, если вы не понимаете зачем делается Debian GNU/kFreeBSD, значит она делается не для вас. А я-то, наивный, думал, что бы работать с ее помощью. Данные обрабатывать, процессы автоматизировать, коммуникациями заниматься... Ан нет - это оказывается квадратура круга, вписанная в философский камень. Памятник нерукотворный. Джо неуловимый.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	125. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от www2 (ok) on 09-Окт-09, 18:26
	>А я-то, наивный, думал, что бы работать с ее помощью. Данные обрабатывать, >процессы автоматизировать, коммуникациями заниматься... Если просто работать, и киллерфичи FreeBSD превысят все её неудобства, то пользоваться ею будут в любом виде. Это сделано не только чтобы работать, а чтобы работать удобно. >Ан нет - это оказывается квадратура круга, вписанная в философский камень. Памятник >нерукотворный. Джо неуловимый. petrosyan.jpg
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	132. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 09-Окт-09, 22:40
	>>А я-то, наивный, думал, что бы работать с ее помощью. Данные обрабатывать, >>процессы автоматизировать, коммуникациями заниматься... > >Если просто работать, и киллерфичи FreeBSD превысят все её неудобства, то пользоваться >ею будут в любом виде. Это сделано не только чтобы работать, >а чтобы работать удобно. Какие неудобства? _Все_ gnu-tools присутствуют. Обновления software в работающих на людей системах происходит только из действительно назревшей необходимости, с четким пониманием того что нужно сделать, и не полагаясь на кого-то. Так в чем же прелесть в данном Debian/kFreeBSD супротив оригинальной FreeBSD? В приставке Debian/k? Или в искуственном интеллекте скриптов и сценариев, заменяющем некоторым интеллект естественный?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	112. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 09-Окт-09, 16:50
	>В свое время была такая же горячая переписка... >Debian GNU/NetBSD http://www.debian.org/ports/netbsd/ >... >Download experimental install floppies (last updated 6th October 2002) http://www.debian.org/News/weekly/1999/8/ Someone proposed a Debian distribution based on FreeBSD. _There was considerable debate on this topic._ Most of the favorable opinions expressed were based on the argument that there should be a Debian distribution for as many open source UNIX variants as possible. This was countered with the argument that this would drastically _increase_the_workload_ of the package maintainers. Это вызвало дебаты о топике... :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	98. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Аноним (??) on 09-Окт-09, 14:30
	> Действительно, раз так нефик делать, лучше бы занялись ext2/3/4 Да успокойся ты уже, припадочный.. не нужно там ЭТО. Есть там ZFS из солярки
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	100. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin on 09-Окт-09, 14:49
	>> Действительно, раз так нефик делать, лучше бы занялись ext2/3/4 > >Да успокойся ты уже, припадочный.. не нужно там ЭТО. Есть там ZFS >из солярки Сам такой, Анонимус :) И к доктору сходи... [ root@t2.xxxxxxx - пт окт 09 13:47:29 - ~ ] # zfs list NAME                            USED  AVAIL  REFER  MOUNTPOINT t2zroot                       2,93G   783M  96,8M  / t2zroot/tmp                     19K   783M    19K  /tmp t2zroot/usr                   2,83G   783M   697M  /usr t2zroot/usr/local             2,15G   783M  2,15G  /usr/local t2zroot/usr/local@2009-10-08   444K      -  2,06G  - ... ext2/3/4 бывает необходима как общая устойчивая часть LinuxBased<->FreeBSD. Вот и все. Хотя бы для переноса данных. Про порты рассказывать не нужно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	131. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от iZEN (ok) on 09-Окт-09, 21:54
	>ext2/3/4 бывает необходима как общая устойчивая часть LinuxBased<->FreeBSD. >Вот и все. Хотя бы для переноса данных. Про порты рассказывать не >нужно. Чем вам не нравится текущая поддержка ext2 (rw, между прочим) в FreeBSD?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	133. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Bulgarin (ok) on 10-Окт-09, 14:35
	>>ext2/3/4 бывает необходима как общая устойчивая часть LinuxBased<->FreeBSD. >>Вот и все. Хотя бы для переноса данных. Про порты рассказывать не >>нужно. > >Чем вам не нравится текущая поддержка ext2 (rw, между прочим) в FreeBSD? После слов "текущая поддержка", извините, отвечать даже не хочется. Спасибо что не написали "текущая поддержка в продакшене на рынке из коропки" :) # cd /mnt/ufs # tar cf src-bin.tar /usr/src/usr.bin # time tar xpf src-bin.tar real    0m7.903s user    0m0.244s sys    0m1.441s # cd /mnt/ext3 # tar cf src-bin.tar /usr/src/usr.bin # time tar xpf src-bin.tar real    0m41.740s   <------------ user    0m0.001s sys    0m2.017s # mount ... /dev/da1s2 on /mnt/ext3 (ext2fs, local) /dev/da1s1a on /mnt/usf (ufs, local, soft-updates) # du -sch /usr/src/usr.bin 15M    /usr/src/usr.bin 15M    total # find /usr/src/usr.bin -type f | wc -l     4718 # find /usr/src/usr.bin -type d | wc -l     2583
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	137. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от iZEN (ok) on 11-Окт-09, 20:19
	>>>ext2/3/4 бывает необходима как общая устойчивая часть LinuxBased<->FreeBSD. >>>Вот и все. Хотя бы для переноса данных. Про порты рассказывать не >>>нужно. >> >>Чем вам не нравится текущая поддержка ext2 (rw, между прочим) в FreeBSD? > >После слов "текущая поддержка", извините, отвечать даже не хочется. >Спасибо что не написали "текущая поддержка в продакшене на рынке из коропки" >:) Пользуйтесь кошерной UFS2 в продакшене. ;) А для переноса данных Ext2 хватает, да.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	157. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
	Сообщение от Денис Юсупов on 12-Окт-09, 17:33
	http://www.opennet.me/opennews/art.shtml?num=23809 === Ведется работа по улучшению поддержки файловой системы Ext2fs и переписыванию частей кода, распространяемых под лицензией GPL. Из планов можно отметить оптимизацию Ext2 для многопроцессорных систем и реализацию возможностей Ext4; ===
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

136. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
Сообщение от moury on 11-Окт-09, 15:26
Скорее бы этот Debian/kFreeBSD приводили в пригодный для эксплуатации вид. Сейчас (на начало октября 2009) это - полное угробище. Смесь бульдога с носорогом (ц) Федорчук. А там - посмотрим.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

138. "Принято решение об официальной поддержке архитектуры kFreeBS..."		+/–
Сообщение от matroskin (??) on 11-Окт-09, 21:16
> Релиз Squeeze будет первым в истории гибридным дистрибутивом, поставляемым одновременно > с возможностью работы с ядрами Linux и FreeBSD. Так был же gentoo с ядром от freebsd, довольно долго поддерживался. Получается, что не "первым в истории"..
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Индекс форумов | Темы | Пред. тема | След. тема