- Принято решение об официальной поддержке архитектуры kFreeBS..., Iv945n, 20:03 , 08-Окт-09 (1) –4 [V]
- Принято решение об официальной поддержке архитектуры kFreeBS..., александр, 20:03 , 08-Окт-09 (2) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., hatelinux, 20:05 , 08-Окт-09 (3) –3
- Принято решение об официальной поддержке архитектуры kFreeBS..., aZ, 20:16 , 08-Окт-09 (5) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., pavlinux, 05:22 , 09-Окт-09 (62) –3
- Принято решение об официальной поддержке архитектуры kFreeBS..., aZ, 13:54 , 09-Окт-09 (95) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 14:24 , 09-Окт-09 (97) –2
- Принято решение об официальной поддержке архитектуры kFreeBS..., aZ, 14:48 , 09-Окт-09 (99) –1
- Принято решение об официальной поддержке архитектуры kFreeBS..., ram_scan, 15:19 , 09-Окт-09 (102)
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 15:50 , 09-Окт-09 (104) –1
- Принято решение об официальной поддержке архитектуры kFreeBS..., aZ, 16:22 , 09-Окт-09 (108)
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 17:08 , 09-Окт-09 (114)
- Принято решение об официальной поддержке архитектуры kFreeBS..., aZ, 17:50 , 09-Окт-09 (118)
- Принято решение об официальной поддержке архитектуры kFreeBS..., аноним, 18:01 , 09-Окт-09 (120)
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 18:14 , 09-Окт-09 (124)
- Принято решение об официальной поддержке архитектуры kFreeBS..., iZEN, 21:40 , 09-Окт-09 (129) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., Денис Юсупов, 17:05 , 12-Окт-09 (152)
- Принято решение об официальной поддержке архитектуры kFreeBS..., sHaggY_caT, 20:17 , 17-Окт-09 (177)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 01:55 , 18-Окт-09 (178)
>>"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. Естественно, даже если корень на другом физическом диске относительно загрузчика и считанного в память ядра.
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 02:10 , 18-Окт-09 (179)
>>>"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.
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 15:07 , 18-Окт-09 (180)
>Шинно-классово-древовидную топологию устройств придумали давно, если не изменяет память еще в Беркли >в 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.
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 13:03 , 19-Окт-09 (184)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 13:05 , 22-Окт-09 (201)
>>>Шинно-классово-древовидную топологию устройств придумали давно, если не изменяет память еще в Беркли >>>в 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тофан как есть. >Конечно, если устройство не определилось - тогда желательно знать его название, чтобы >драйвер искать. Но если определилось - то какая уже разница, каким >драйвером? А если определилось, но не работает как задумывалсь? Не, это ньюансы все конечно, но из них и складывается эволюция технической системы.
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 13:45 , 22-Окт-09 (202)
- Принято решение об официальной поддержке архитектуры kFreeBS..., PereresusNeVlezaetBuggy, 13:58 , 22-Окт-09 (203)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 16:36 , 22-Окт-09 (205)
>Хорошая архитектура - вещь полезная, но 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. Распиаренный "паровоз" - это да.
- Принято решение об официальной поддержке архитектуры kFreeBS..., sHaggY_caT, 18:02 , 22-Окт-09 (206)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 20:23 , 22-Окт-09 (207)
>Эта модель разработки не мешает промышленной эксплуатации :) старые RHEL3 и RHEL >4 будут поддерживаться еще несколько лет (при том, что RHEL 3 Промышленная эксплуатация в промышленности, давайте не будем путать a) вспомогательные дата-центры, рабочие станции и b) автоматизированные системы управления и контроля производственными линиями. Хранилище с бухгалтерскими данными - это еще не промышленность, хотя и очень важная задача :) Шутка. RH - коммерческое предприятие. Бизнес циничен. Бизнес-мэн заинтересовано в получении прибыли, и все его остальные действия вытекают из этого. В развитие именно kernel RH, Ltd. заинтересовано ровно в той степени, насколько это будет приносить прибыль. И если разработчики kernel вдруг решать объявить переход на что-то version Б, несовместимой с версией А, то это повод лишний раз для заработать, скажем, подписав на бинарные пакеты, или продавая иной свой сервис по своим маркетинговым каналам-сети. По похожей схеме наше изменчивое законодательство дает возможность заработать массе 1С-программистов. Впрочем, могу ошибатся, естественно. И RH занимается исключительно благотворительностью :)
И коммерческий саппорт RH нисколько не меняет ситуации с портативностью кода kernel в другие системы.
- Принято решение об официальной поддержке архитектуры kFreeBS..., sHaggY_caT, 00:39 , 23-Окт-09 (208)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 10:05 , 23-Окт-09 (209)
>не в меньшинстве, но тон задают крупные компании. Только что в >этом плохого? Тот же Yahoo! сделал очень и очень много хорошего Да, отчасти, думаю, вы конечно правы. (Лирика за утренней чашкой чая, уж позвольте :) ) Немного присматриваюсь к эволюции технических систем, программные компоненты "живут" вообще без году неделя - 35-40 лет. Был нулевой период переключателей, был первый период RT11, RTRS, RSX, DOS, NetWare и прочих, теперь период UNIX&NT, далее дело (опять) идет к модульно-системно-распределенным системам локально, в одном шасси & стойке, кампусе & городе, ... Kernel еще будет существовать долгое время, но эта программная архитетура быстро дошла до своего плато развития, и либо будет тщательно реинкарнирована - кодом и архитекурой кода, либо плавно уйдет за многие (и возможно, весьма-весьма многие) годы со сцены. Параллельно будет развиватся и эволюционировать неcколько BSD систем, мигрируя кодом между проектами, и интуитивно делаю вывод, не более, за этой мета-веткой большие перспективы. Параллельно будут развиватся и возникать и другие проекты, как пробники идей и специализированные & портативные системки... Про коммерческие тенденции молчу, там такой кавардак & бордель, бордель в квадрате :) Поживем, увидим. Надеюсь, решающими будут все таки не "деньги" как общественная условность (и не жадность :) ), а таки _здравые_ чувства и намерения наиболее талантливых и деятельных из людей.
- Принято решение об официальной поддержке архитектуры kFreeBS..., sHaggY_caT, 14:02 , 23-Окт-09 (212)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 14:24 , 22-Окт-09 (204)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 10:36 , 23-Окт-09 (210)
>А Linux развивался не эволюционным, а революционным путём. "Я плакалъ" :) Все, ует, умыт и сражен. На этот аргумент сказать ответить нечего :) "Долгих 15 лет изнурительной революции, в результате которых была получена совершенно уникальная и не имеющая аналогов кострукция велосипе... управления памятью, шинами, устройствами, процессами, файловые системы, набор системных вызовов, ... Именно благодаря этой революционной конструкции, написанной на уникальном языке SI, удалось применить ранее написанные GNU&PNU-утилиты, применит огромное число революционных проектов, таких как Imacs, Torzilla, Z11, lendmail, ..." - Принято решение об официальной поддержке архитектуры kFreeBS..., sHaggY_caT, 14:14 , 23-Окт-09 (214)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 15:19 , 23-Окт-09 (217)
>Нет, "за долгие 15 лет эволюции" была создана платформа, которая с успехом >заменила, в большинстве случаев, коммерческие UNIX'ы. Очень хорошо. Меня просто порадовала фраза "Linux - революционная система" :) Обсуждение с позиции "А где в системе Ъ возможность Тыдыц, А?!!! Почему не сделали?!!!", извините, считаю неконструктивным. Займитесь и сделайте. Или бартером :) А теперь задайтесть вопросом, почему указанные вами подсистемы (виртуализации, кластеризации, прочей ации) не задумывались как портативные? Причины - техническая недограмотность, амбиции, эгоцентризм, вполне понятный недостаток сил и средств, прочее? - Принято решение об официальной поддержке архитектуры kFreeBS..., iZEN, 18:25 , 23-Окт-09 (218)
- Принято решение об официальной поддержке архитектуры kFreeBS..., sHaggY_caT, 19:15 , 23-Окт-09 (219)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 23:42 , 23-Окт-09 (220)
>находящихся под нагрузкой, и, в целом, не мешающих друг другу, и >даже более 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... Ну а насчет быстро и впереди планеты всей... Тараканы тоже быстро бегают :)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 14:29 , 23-Окт-09 (216)
- Принято решение об официальной поддержке архитектуры kFreeBS..., sHaggY_caT, 20:13 , 19-Окт-09 (195)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 23:16 , 19-Окт-09 (196)
>такое прочее, которые случайно (например, при замене платформы вместе с карточкой) >могут быть ткнуты не туда и не так. Поменять 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, и их километровые руководства по танцам :) )
- Принято решение об официальной поддержке архитектуры kFreeBS..., iZEN, 01:43 , 19-Окт-09 (181)
- Принято решение об официальной поддержке архитектуры kFreeBS..., iZEN, 23:47 , 19-Окт-09 (197)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 12:34 , 20-Окт-09 (200)
>Ещё. Сейчас проверил: в статусе 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
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 17:51 , 09-Окт-09 (119)
>А ничего дебильнее прыгающей нумерации сетевушек в вашей фре я не видел. >Стоят три сетевушки одинаковой модели: rl0, rl1, rl2. Вынимаем вторую, вставляем >ещё одну, но другой модели и что мы видим? rl0, rl1, >xl0. Вперед, переписывать в трёхстах местах название интерфейса. Или алиасики на Хех, добавим огня, с сохранением стиля :) Ничего дебильнее обезличивающего наименования в линуксе я не видел - eth0, eth1, eth2. Выдернул сетевушку, вставил новую - и не поймешь, к какой интерфейс относится? --- 1. Если вы меняете сетевые карты так часто, то это печально. 2. Если часто меняемая локация ifconfig ... route delete ... route add ... Скрипт в три команды, думаю, не проблема. 3. Для постоянного изменить нужно только в /etc/rc.conf Кроме guagga/zebra, влет не припоминаю ПО, сильно или вообще зависимого от имени интерфейса. Firewall, пожалуй, вешь индивидуальная, по уму там хорошо макроподстановкой. И нечего городить огород там, где можно гораздо проще.
- Принято решение об официальной поддержке архитектуры kFreeBS..., bugmenot, 04:14 , 12-Окт-09 (139)
- Принято решение об официальной поддержке архитектуры kFreeBS..., QuAzI, 20:22 , 08-Окт-09 (6) –2
- Принято решение об официальной поддержке архитектуры kFreeBS..., nikll, 21:34 , 08-Окт-09 (23)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Iv945n, 21:40 , 08-Окт-09 (26) +3
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 09:45 , 09-Окт-09 (70)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 10:54 , 09-Окт-09 (73) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., DEC, 11:12 , 09-Окт-09 (76) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 12:27 , 09-Окт-09 (83)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 13:06 , 09-Окт-09 (85)
- Принято решение об официальной поддержке архитектуры kFreeBS..., аноним, 17:49 , 09-Окт-09 (117)
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 18:08 , 09-Окт-09 (122) +2
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 19:27 , 09-Окт-09 (127) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., oops, 06:51 , 15-Окт-09 (174)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 11:52 , 16-Окт-09 (176)
- Принято решение об официальной поддержке архитектуры kFreeBS..., oops, 06:14 , 19-Окт-09 (182)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 12:26 , 19-Окт-09 (183)
>Что мне, как майнтейнеру коммерческого проекта делать? Как "майнтейнеру коммерческого проекта" нужно прежде всего понять, на каких условиях производится дистрибьюция используемого вами программного обеспечения. Потом оценить все ньюансы, их позитивные и негативные составляющие, ваши риски и возможный жизненный путь проектируемой системы. И далее осуществить грамотную техническую подготовку. Где в публичных BSD ограничениях-оферте хоть раз сказано, что кто-то вам обязан чем-то? BSD порты не являются прототипом коммерческой системы сопровождения сторонних приложений, нужно четко это понимать. Как вариант, подготовте слепок портов под клиента, а то и системы, закатайте себе на болванки - и при необходимости переносите акуратно в нее обновления на основе слепка. Не нужно говорить, а что если 100 клиентов - это ваше решение. Исползуйте другой вариант, другую программное решение и другую систему дистрибьюции, скажем - коммерческие системы.
- Принято решение об официальной поддержке архитектуры kFreeBS..., oops, 09:22 , 20-Окт-09 (198)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 11:14 , 20-Окт-09 (199)
>Я все это прекрасно понимаю. И делаю именно так как вы говорите. >Но это _я_ могу так делать. Это хорошо, что вы можете. "Не оскудела земля Русская" :) Правда, Президент Медведев недоумевает - талантов много, а толку мало :) Что не так делаем? Думаю, по мере привлечения грамотных кадров к 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 :) Ну вот такая лирика, с утреца под чашку чая просыпаясь :) Пора работу работать.
- Принято решение об официальной поддержке архитектуры kFreeBS..., fulcrum, 22:44 , 10-Окт-09 (134)
- Принято решение об официальной поддержке архитектуры kFreeBS..., dimanoname, 22:24 , 08-Окт-09 (28) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., Resonance, 22:31 , 08-Окт-09 (30)
- Принято решение об официальной поддержке архитектуры kFreeBS..., xxx, 22:48 , 08-Окт-09 (37) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., Эргил, 22:59 , 08-Окт-09 (41)
- Принято решение об официальной поддержке архитектуры kFreeBS..., аноним, 23:05 , 08-Окт-09 (44)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Resonance, 23:35 , 08-Окт-09 (45)
- Принято решение об официальной поддержке архитектуры kFreeBS..., bugmenot, 06:30 , 12-Окт-09 (141)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 10:35 , 12-Окт-09 (143)
>где во фре При этих словах, как понимаю, 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: ...
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 22:34 , 08-Окт-09 (32)
- Принято решение об официальной поддержке архитектуры kFreeBS..., bys76, 23:40 , 08-Окт-09 (46) –1
- Принято решение об официальной поддержке архитектуры kFreeBS..., pavel_simple, 23:47 , 08-Окт-09 (47)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 00:32 , 09-Окт-09 (48)
- Принято решение об официальной поддержке архитектуры kFreeBS..., pavel_simple, 00:36 , 09-Окт-09 (49)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 08:47 , 12-Окт-09 (142)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 11:04 , 12-Окт-09 (144)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 12:42 , 12-Окт-09 (145)
>Ещё они собирают, потому что порты постоянно обновляются и нельзя закрыть дырки >в программах не прибегая к повышенияю версии софта и используя только >готовые двоичные пакеты. 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 - только инструмент человека, повседневный и/или профессиональный. Возможно, ты встречался не с теми людьми.
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 13:44 , 12-Окт-09 (146)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 13:47 , 12-Окт-09 (147)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 15:16 , 12-Окт-09 (148)
>>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 - и ноль результата.
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 15:37 , 12-Окт-09 (149)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 16:53 , 12-Окт-09 (150)
>же жизнь быть админом), нужна будет предпринимательская жилка, чтобы пробить свой >проект. Для этого нужно просто общаться с народом, грамотно предлагать свои идеи, и таки что-то самому делать. Есть рассылки, форумы, люди в большей части адекватные и вменяемые - пообщайтесь. Только не забывайте, что вам никто ничего не должен. Это добровольцы. >Идеально было бы, чтобы deb-пакеты генерировались из подобия портов (или портежей). Но Действительно, не наблюдаю острой необходимости, хотя указанное действо не столь сложно. По комплексу причин. Одна из которых - система debian пакетирования далеко не идеал. В отношении комплекса тех задач, для которых существует подобные системы. Другая - для многослойного пакетирования и дистрибьюции требуются вычислительные, коммуникационные и человеческие ресурсы, которых не так много. Они требуются для более приоритетных задач. Задачи согласования, обновления, квалификации на возможности НД и прочее частично переложены на инженерный персонал, использующий BSD. Как правило, это достаточно квалифицированный персонал, для которого указанное - несложная задача. Это и остальное уже не раз обсуждалось, лениво пересказывать. >(не люблю компиляцию и bleeding-edge). Не любишь компилировать? Никак не освоить? Ну батенька, может вам MS Windows будет самое то? :) Да и кого, извини, будет интересовать твое мнение голимого потребителя, если ты ничего ни для одного из общественных проектов не сделал, в качестве финансового, трудового или иного вспоможения?
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 08:12 , 13-Окт-09 (161)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 09:49 , 13-Окт-09 (163)
>Каких таких более приоритетных задач? По-вашему лучше переложить вопросы пакетирования на конечных >пользователей, чем освободить их время для более продуктивной деятельности? Если каждый >автор порта возьмёт на себя задачу по грамотному пакетированию всего-лишь одного >своего порта, освободится огромное количество времени пользователей. Они будут тратить У тебя есть прекрасная возможность показать на деле свою грамотность - спроектировать новую систему портов. Более эффективную, приемлимую по техническим и организационным условиям. Реализовать прототип системы пакетирования и дистрибьюции, убедить народ в его эффективности. Народ вменяемый, в большинстве грамотный, с опытом работы. Только еще раз напоминаю - это добровольцы. Тебе они ничего не должны. Списки рассылки на www.freebsd.org, по ссылкам можно найти другие контакты. Или ты думаешь твое переливание из пустого в порожнее, сидя ровно на известном месте, что-то конструктивно поменяет в _общественных_ проектах? Тем более что проблема взята с потолка по большей части.
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 10:11 , 13-Окт-09 (164) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 11:41 , 13-Окт-09 (167)
>У меня есть много возможностей, почему я должен выбрать именно ту, которую >вы мне предлагаете? Если что-то делается 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
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 12:49 , 13-Окт-09 (168) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 14:56 , 13-Окт-09 (169)
>>Понял. Толку - ноль, как ни крути :) >>>для того, чтобы кто-нибудь понял что Debian GNU/kFreeBSD - проект не >>>бессмысленный, он делается не ради гордыни, а ради вполне понятных преимуществ, >>>преимуществ от каждой из двух систем. >> >>Какие "понятные преимущества"? > >Перечитай ещё раз https://www.opennet.ru/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 Насчет непонимания. "Достали, ламерюги проклятые, все им дай, дай, дай". Пиши действительно по делу, с деловым предложением, и тебя прекрасно поймут. Везде.
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 15:39 , 13-Окт-09 (170)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 17:42 , 13-Окт-09 (171)
>>Ах они "упертые фришники", ничего то они не понимают, тут "толпа дебианщиков" >>с "мягкими зависимостями" предлагает "идеал", и может даже сделают "загрузку с >>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кий сад :) Да все я понял. Стебаюсь, есть время. >Больше разговаривать с тобой я не намерен. Да хоть застрелись :)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 10:12 , 13-Окт-09 (165)
>>Каких таких более приоритетных задач? По-вашему лучше переложить вопросы пакетирования на конечных >>пользователей, чем освободить их время для более продуктивной деятельности? Если каждый >>автор порта возьмёт на себя задачу по грамотному пакетированию всего-лишь одного >>своего порта, освободится огромное количество времени пользователей. Они будут тратить Вдогонку. Надеюсь прочитать о твоих успехах в общественной IT-деятельности через несколько лет. Для начала, в общем мыслишь в верном направлении. Осталось кое в чем научится, и реализовать. И почитай http://www.freebsd.org/doc/ru/books/faq/funnies.html#CHANGIN... Этому больше десятка лет :)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 10:22 , 13-Окт-09 (166)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Денис Юсупов, 17:21 , 12-Окт-09 (154)
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 09:56 , 09-Окт-09 (71)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 00:39 , 09-Окт-09 (50)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Анонимный, 01:15 , 09-Окт-09 (56)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 02:36 , 09-Окт-09 (58)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 10:36 , 09-Окт-09 (72) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., Andrey Mitrofanov, 10:59 , 09-Окт-09 (74) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., User294, 11:25 , 09-Окт-09 (79) +1
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 13:15 , 09-Окт-09 (89)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Денис Юсупов, 17:25 , 12-Окт-09 (156)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 12:46 , 09-Окт-09 (84)
Несколько абсурдный проект, по совокупности. Пожалуй, основное - У системы (именно, не ядра, а операционой системы) свои разработчики, либо каждый раз нужно переносить апдейты из FreeBSD, либо нужно становиться со-разработчиками FreeBSD, со всеми вытекающими - работа подсистем FreeBSD обеспечивается рядом взаимоувязанных модулей, библиотек и утилит. - адаптация ПО к FreeBSD - в совокупности очень емкая деятельность. В проекте FreeBSD - GNU-tools и так все портированы во FreeBSD, пользуйся на здоровье.Ну если парням хочется делать двойную, а то и тройную работу, то - аллах акбар. Действительно, раз так нефик делать, лучше бы занялись ext2/3/4 или еще чем более актуальным, а не скрещивать ужа и ежа.
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 13:08 , 09-Окт-09 (86)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 16:08 , 09-Окт-09 (105)
>>Несколько абсурдный проект, по совокупности. >>Пожалуй, основное >>- У системы (именно, не ядра, а операционой системы) свои разработчики, либо >>каждый раз нужно переносить апдейты из FreeBSD, либо нужно становиться со-разработчиками >>FreeBSD, со всеми вытекающими > >А как вы думаете делается Debian? Именно так и делается. У каждого Бла-бла-бла-тысяча-сто-первый-раз, извините, лет 15 это наблюдаю :) Товарищи Вместо цели написания действительно функционального кода в очередной раз решили заниматься джастофаном ради джастофана, с небольшим побочным полезным результатом. Да и то порытым в недрах пакетов Debian, патчем на пропатченый патч. Иначе как амбициозностью это проект объяснить не могу. В свое время была такая же горячая переписка... Debian GNU/NetBSD http://www.debian.org/ports/netbsd/ ... Download experimental install floppies (last updated 6th October 2002)
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 16:50 , 09-Окт-09 (111)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 17:13 , 09-Окт-09 (115)
>>Бла-бла-бла-тысяча-сто-первый-раз, извините, лет 15 это наблюдаю :) >>Товарищи Вместо цели написания действительно функционального кода в очередной раз решили заниматься >>джастофаном ради джастофана, с небольшим побочным полезным результатом. > >То же самое можно сказать о разработчиках FreeBSD. Можно сказать что угодно о чем угодно, не убудет. Когда человек пишет geom или cam, портирует packet filter, это добавляет функциональности. Когда прикручивают apt и glibc, попутно удаляя ту функциональность что уже есть и устойчиво работает - как-то уже не понимаю. Ради косметики и галочки? Или ради амбиций? Толку-то? Все одно тот-же cp, mkdir, gmake, ... >>Да и то порытым в недрах пакетов Debian, патчем на пропатченый патч. > >Это те немногие люди, что доводят дело до конечного результата. А те, >кто пишет программы, чаще всего тоже делают это джастфофан - плевать >они хотели на десктопы пользователей, их образ мыслей примерно таков "Я >пишу для себя, у меня это работает, а на остальных насрать." С уважением отношусь в разработчикам Debian. Грамотная задумка, понравилась еще в конце 90-х. Но и они иногда занимаются фигней.
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 17:33 , 09-Окт-09 (116)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 18:02 , 09-Окт-09 (121)
>Если вы действительно понимаете всю грамотность задумки Debian, то для вас не >составит труда понять и этот проект. Понимаю. Сам такое хотел сотворить лет 12 назад. Фигней занимаются. >Ради того, чтобы сделать мир совершеннее. FreeBSD не совершенна. Успокойтесь, если вы не понимаете зачем делается Debian GNU/kFreeBSD, значит она делается не для вас. А я-то, наивный, думал, что бы работать с ее помощью. Данные обрабатывать, процессы автоматизировать, коммуникациями заниматься... Ан нет - это оказывается квадратура круга, вписанная в философский камень. Памятник нерукотворный. Джо неуловимый.
- Принято решение об официальной поддержке архитектуры kFreeBS..., www2, 18:26 , 09-Окт-09 (125)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 22:40 , 09-Окт-09 (132)
>>А я-то, наивный, думал, что бы работать с ее помощью. Данные обрабатывать, >>процессы автоматизировать, коммуникациями заниматься... > >Если просто работать, и киллерфичи FreeBSD превысят все её неудобства, то пользоваться >ею будут в любом виде. Это сделано не только чтобы работать, >а чтобы работать удобно. Какие неудобства? _Все_ gnu-tools присутствуют. Обновления software в работающих на людей системах происходит только из действительно назревшей необходимости, с четким пониманием того что нужно сделать, и не полагаясь на кого-то. Так в чем же прелесть в данном Debian/kFreeBSD супротив оригинальной FreeBSD? В приставке Debian/k? Или в искуственном интеллекте скриптов и сценариев, заменяющем некоторым интеллект естественный?
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 16:50 , 09-Окт-09 (112)
>В свое время была такая же горячая переписка... >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. Это вызвало дебаты о топике... :)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Аноним, 14:30 , 09-Окт-09 (98)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 14:49 , 09-Окт-09 (100)
>> Действительно, раз так нефик делать, лучше бы занялись 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. Вот и все. Хотя бы для переноса данных. Про порты рассказывать не нужно.
- Принято решение об официальной поддержке архитектуры kFreeBS..., iZEN, 21:54 , 09-Окт-09 (131)
- Принято решение об официальной поддержке архитектуры kFreeBS..., Bulgarin, 14:35 , 10-Окт-09 (133)
>>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
- Принято решение об официальной поддержке архитектуры kFreeBS..., moury, 15:26 , 11-Окт-09 (136)
- Принято решение об официальной поддержке архитектуры kFreeBS..., matroskin, 21:16 , 11-Окт-09 (138)
|