На официальном FTP-сервере FreeBSD появились (ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-I.../) ISO-образы и исходные тексты релиза FreeBSD 9.1. Образы опубликованы для платформ amd64 (ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/), i386 (ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/), powerpc64 (ftp://ftp.freebsd.org/pub/FreeBSD/releases/powerpc/powerpc64/) и ia64 (ftp://ftp.freebsd.org/pub/FreeBSD/releases/ia64/ia64/). С целью снижения нагрузки на инфраструктуру проекта, до официального релиза, который состоится в течение нескольких дней, с загрузкой образов следует повременить, что поможет ускорить распространение новой версии по зеркалам.
URL: ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-I.../
Новость: http://www.opennet.me/opennews/art.shtml?num=35562
кто-нибудь, расскажите им про torrent
http://torrents.freebsd.org:8080/
torrents.FreeBSD.org is offline. It will probably will not be back.
Даже здесь умудрились накосячить...
It will probably not be back.
Второе will лишнее.
Тогда уже второе :)
It probably won't (will not) be back
> Тогда уже второе :)
> It probably won't (will not) be backМожно ещё проще: SNAFU.
all your back are belong to us
> Тогда уже второе :)
> It probably won't (will not) be backЕще можно
Probably, it will not be back :)
В целом все три варианта уместны. Но два will - это нечто.
http://www.freebsd.org/cgi/query-pr.cgi?pr=173665
> http://www.freebsd.org/cgi/query-pr.cgi?pr=173665Угу, закрыт месяц назад с коментом что закрыто на майнтенанс, "скоро починим".
> с загрузкой образов следует повременитьА зачем тогда постить такие новости?
Некоторым достаточно базовой ОС, они могут уже пробовать внедрять. Тем кому нужны все пакеты и бинарный апдейт - могут готовиться :)
Что желающие приняли позу низкого старта :D
Поиздеваться. Показать конфетку и сказать: не получишь до Нового года.
потому что на опеннете есть машина времени
>> с загрузкой образов следует повременить
> А зачем тогда постить такие новости?Затролить на опеннете и бсдешников, и линуксоидов. Makes it double!
новость звучит прямо как "На официальных ftp-серверах загадочно появились iso-образы FreeBSD 9.1-RELEASE "
судя по
http://www.freebsd.org/releases/9.1R/schedule.html
они должны были появиться еще 9го числа
Правильно! Давайте выпустим недоделку в срок как обещали, а через пару недель мы выпустим фикс.
для Вас придумали handgum, "пожуйте" вместо того чтобы писать про "недоделки в срок"потом слейте любую исошку и посмотрите даты каталогов и файлов
> судя по
> http://www.freebsd.org/releases/9.1R/schedule.html
> они должны были появиться еще 9го числаотставание от графика таки есть. ну и типа сегодня будет анонс.
> Для загрузки можно использовать Torrent-ы,А те кто это писал свою писанину вообще проверяют? Они как-то очень уж теоретически можно. А практически хост в глухом дауне уже которую неделю.
Скорей всего хост недоступен из-за недавнего инцидента.
http://mirror.yandex.ru/freebsd/releases/amd64/amd64/ISO-IMA.../
Удобнее http://mirror.yandex.ru/freebsd/releases/ISO-IMAGES/9.1/
10.0-CURRENT .iso = https://snapshots.glenbarber.us/
Ежедневные снапшоты можно скачать тут: https://pub.allbsd.org/FreeBSD-snapshots/
Создание снапшотов временно остановлено в связи с техническими работами http://lists.freebsd.org/pipermail/freebsd-current/2012-Dece...
CDN будет ?
а вот как узнать поподробней, шо нового появилось, для чего и как настраивать? а то хэндбуку 200 лет в обед. я то могу установить шлюз, прокси, почту и т.п. но я точно также устанавливал и настраивал и на 6й версии, а ведь разработчики шото новое вставили или нет все по прежнему?
$ more /usr/src/UPDATING
В русском хэндбуке - да, наблюдается отставание в переводе.
Английский Handbook, в основном, идёт в ногу со временем. Заглядывайте и туда, и туда.
И таки-да, в настройках шлюзы/почты/прокси практически ничего не поменялось еще со времен 4.9... к ipfw добавился pf, да у squid и postfix появились кое-какие новые плюшки.
так ведь squid и postfix и т.д. разрабатывают другие сообщества. это из области дополнений. а мне вот интестно, что нового внедрили в саму ОС и как это применить
Ну внедрили там на самом деле много чего, выше правильно сказали - смотреть в UPDATING, просто для решения озвученных вами задач можно считать, что по сути ничего и не поменялось :), хотя, конечно, это и не так.
Новизна ради новизны???????????? а чем хуже FreeBSD 8.3???????????
> Новизна ради новизны???????????? а чем хуже FreeBSD 8.3???????????под шлюз хостера/провайдера 8.3 с головой хватает!
> под шлюз хостера/провайдера 8.3 с головой хватает!Видел только на домашних роутерах у гиков.Шлюзы у хостеры/провайдеры на
cisco,rhel и,иногда,на solaris 10.
Juniper и на cisco можно фрю поставить
> Juniper и на cisco можно фрю поставитьJuniper!=фря.
>> Juniper и на cisco можно фрю поставить
> Juniper!=фря.при большом желании можно и фря
> при большом желании можно и фряфря там только буковки с консолек читает, да флешку поддерживает. под такие задачЫ обычно берут мелкие RTOS'ы, но у жунов как-то не срослось
> Juniper и на cisco можно фрю поставитьУгу, теоретически. Практически для этого придется горы воротить. Самолично. Поскольку остальные (в т.ч. juniper) код зажали. Так что если вы не крутая корпорация с миллиардным оборотом - удачи, ага.
А чем хуже FreeBSD 4.11??????????????????????????
Тем, что уже пару лет как там многое из портов не собирается. Тем, что железа в 4.11 поддерживается много меньше. Ну а тем, кто таки считает что 4.11 не хуже, а лучше, уже давно по пути с Мэтью Диллоном :)
ну Диллон тоже изменил там многое, ядро дургое и ФС, это наш ответ Танбернауму
> А чем хуже FreeBSD 4.11??????????????????????????
Капец, уже сказки писать начали http://alv.me/?p=1559
Такое бывает, когда народ ВООБЩЕ не понимает, что на распространение релиза по зеркалам и подготовку анонса учитывающего нововведения нужно время. Его нелюбимый systemd ему в плечи
> Такое бывает, когда народ ВООБЩЕ не понимает, что на распространение релиза по
> зеркалам и подготовку анонса учитывающего нововведения нужно время.А у торрентов такой проблемы нет. Правда они у вас сдохли.
Какая же это сказка? Всё по делу написано.
Уже много лет ведется практика создания установочных образов и только спустя несколько дней публикуют информацию о релизе/документацию.Для примена можно посмотреть планы выпуска релизов:
http://wiki.freebsd.org/Releng/9.1TODO
RELEASE build 2012-10-24
RELEASE announcement 2012-10-29http://wiki.freebsd.org/Releng/8.2TODO
RELEASE build 2011-01-21
RELEASE announcement 2011-01-24http://wiki.freebsd.org/Releng/8.1TODO
RELEASE build 2010-07-09 2010-07-17
RELEASE announcement - 2010-07-22http://wiki.freebsd.org/Releng/7.4TODO
RELEASE build 2011-01-21
RELEASE announcement 2011-01-24Торрент тракер по адресу http://torrents.freebsd.org:8080 уже больше недели недоступен.
По информации из Mailing List на нем ведутся технические работы.Просьба, по возможности, не нагружать официальны FTP-сервер FreeBSD считается хорошим тоном во время синхронизации зеркал.
"Сюрприз" для десктопов: http://www.freshports.org/x11/xcb-util/
Для чего он и что дает?
> Для чего он и что дает?Ты не понял. яЗен в шоке, он узнал об /usr/ports/UPDATING.
> Для чего он и что дает?xcb-util опять сломали. Придётся повторить процедуру от 2012-01-16.
> "Сюрприз" для десктопов: http://www.freshports.org/x11/xcb-util/А сюрприз в чем? Он делает рекурсивный rm? :)
> "Сюрприз" для десктопов: http://www.freshports.org/x11/xcb-util/Не, не этот. Вот этот: http://www.freshports.org/devel/pcre/
///---
2012-12-11
Affects: users of devel/pcre
Author: bdrewery@FreeBSD.org
Reason:
The pcre library has been updated to version 8.32. Please
rebuild all ports that depend on it.If you use portmaster:
portmaster -w -r pcre
If you use portupgrade:
portupgrade -fr devel/pcre
If you use pkgng with binary packages:
pkg install -fR devel/pcre
---///Мне придётся обновить 194 установленных пакетов. А вам?
> Мне придётся обновить 194 установленных пакетов. А вам?Ну, о чём тебе, в общем, всегда и толдычилось. Обновление одного пакетика сразу ведет к пересборке мира :)
>> Мне придётся обновить 194 установленных пакетов. А вам?
> Ну, о чём тебе, в общем, всегда и толдычилось. Обновление одного пакетика
> сразу ведет к пересборке мира :)Вот она, модульность C/C++ во всей красе. :))
> Вот она, модульность C/C++ во всей красе. :))Это не модульность С/C++, это ABI changes. Любимая тобой жаба тоже требует подобного же, только выполняться сие будет в фоне (JIT), в трудно предсказуемые моменты. А при API changes также потребует и правки софта. Ну и да - если переписать всё на жабе - тормоза будут неописуемые.
>> Вот она, модульность C/C++ во всей красе. :))
> Это не модульность С/C++, это ABI changes.Что же Java классы, зависмые от изменяемого, не требуют обязательной перекомпиляции? Почему так сложно обеспечить обратную совместимость кода на C/C++ с существующим сторонним софтом, версии которого не изменились, его нужно снова перекомпилировать из тех же исходников?
> Любимая тобой жаба тоже требует
> подобного же, только выполняться сие будет в фоне (JIT), в трудно
> предсказуемые моменты.Эти моменты легко предсазать и даже управлять этим — как правило, затребованный код сразу же проходит JIT и кэшируется в памяти (вот почему Java приложения требовательны к большому объёму памяти).
> А при API changes также потребует и правки софта.
Какой? Если API только расширяется, то зависимые неизменившиесы классы (объекты) всё равно не увидят новые методы. И будут использовать те же самые вызовы, которые в них задействованы изначально.
> Ну и да - если переписать всё на жабе - тормоза будут неописуемые.
При условии, если отключить JIT и урезать оперативную память.
> Что же Java классы, зависмые от изменяемого, не требуют обязательной перекомпиляции?а) JIT пересоберется (ABI change), так что суть та же
б) было fx(a, b), стало fx(a, b, c), причём c обязательное (API change). Не будете ничего менять? Флаг в жо^W руки :)> Почему так сложно обеспечить обратную совместимость кода на C/C++ с существующим сторонним софтом, версии которого не изменились, его нужно снова перекомпилировать из тех
> же исходников?Потому что получится WinAPI/ABI.
> Эти моменты легко предсазать и даже управлять этим — как правило, затребованный
> код сразу же проходит JIT и кэшируется в памяти (вот почему Java приложения требовательны к большому объёму памяти).Вот почему J2EE реально юзают только в тяжеленных приложениях под махровый ынтерпрайз, где не лень отдать 100500 нефти за десяток серверов, лишь бы оно хоть как-то работало. Ибо искать/делать решения попроще западло. Правда, в последние годы наметился обратный процесс - все стали иметь штатных программистов, и многое писать под свои задачи индивидуально.
>> А при API changes также потребует и правки софта.
> Какой? Если API только расширяется, то зависимые неизменившиесы классы (объекты) всё равно не увидят новые методы.Какие классы? Забудьте об этом, OO-подход в портабельных системах опять же используется не везде (читать - почти нигде).
>> Что же Java классы, зависмые от изменяемого, не требуют обязательной перекомпиляции?
> а) JIT пересоберется (ABI change), так что суть та же
> б) было fx(a, b), стало fx(a, b, c), причём c обязательное (API
> change). Не будете ничего менять?Э... это уже как бы считается кардинальным изменением API, так как изменяется сигнатура вызова. Все клиенты должны отвалится, по идее, если их код не поправить в соответствии с новым API. Либо изначально закладываться на особенности языка описания вызовов по использованию функций (методов) с переменным числом параметров.
>> Почему так сложно обеспечить обратную совместимость кода на C/C++ с существующим сторонним софтом, версии которого не изменились, его нужно снова перекомпилировать из тех же исходников?
> Потому что получится WinAPI/ABI.Не понял.
>> Эти моменты легко предсазать и даже управлять этим — как правило, затребованный
>> код сразу же проходит JIT и кэшируется в памяти (вот почему Java приложения требовательны к большому объёму памяти).
> Вот почему J2EE реально юзают только в тяжеленных приложениях под махровый ынтерпрайз, где не лень отдать 100500 нефти за десяток серверов, лишь бы оно хоть как-то работало. Ибо искать/делать решения попроще западло.Решения, которые попроще, не обладают масштабируемостью, требуемое время на создание таких решений и отладку неизмеримо больше.
>>> А при API changes также потребует и правки софта.
>> Какой? Если API только расширяется, то зависимые неизменившиесы классы (объекты) всё равно не увидят новые методы.
> Какие классы? Забудьте об этом, OO-подход в портабельных системах опять же используется не везде (читать - почти нигде).Да я понял давно, что объекты в C++ никакие не объекты вовсе, а так — фальшивая ООП-обёртка для сознания программиста с псевдо-RTTI и статическим связыванием кода на этапе компиляции.
> Мне придётся обновить 194 установленных пакетов. А вам?Если ABI не изменилось, то не обязательно.
Если изменилось имя библиотеки, то man libmap.confЕсли же авторы библиотеки изменили ABI - то кто они и есть злостные буратины, вне зависимости от операционной системы.
Впрочем, на крайний случай ничто не мешает вам ручками подсунуть libsome.123 в /usr/local/lib/compat
http://forums.freebsd.org/showthread.php?t=35711