если совсем-совсем надо по месту, я б сделал джейл с дефолтной системой последней к текущему мейджору и собирал там

?

?

а, теперь понял. вы предлагаете собрать 9.3 под данную архитектуру на другой аналогичной системе, подсунуть /usr/src/ и /ysr/obj в эту и выполнить make install ? (я просто уточняю потому что так раньше не делал)

а, теперь понял. вы предлагаете собрать 9.3 под данную архитектуру на другой аналогичной системе, подсунуть /usr/src/ и /ysr/obj в эту и выполнить make install ? (я просто уточняю потому что так раньше не делал)

можно прям на той же. распаковать http://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.3-RELEASE/ в условно /jail/pristine93, сделать туда джейл, там достать свежие исходники из stable/9, и там делать makeworld

но если опыта нет — там тоже можно ноги поломать ;)

Спасибо за совет, буду пробовать. Опыта мало не бывает!

Кому там вчера хотелось англицких буковок про BSD, не квартальный отчёт, но около :) https://www.freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-update-august-2018/

Alexander P будет жить. Поприветствуем!

Было уже подобное, их вы%#$и по самые помидоры и оштрафовали

а за что именно? я слоупочу че-то....

и кто

и что вообще в этом такого особенного

# cat /etc/make.conf NO_INET6=yes WITHOUT_INET6=yes WITHOUT_INET6_SUPPORT=yes WITHOUT_IPV6=yes WITHOUT_X11=yes

А ты апасный в6 лобзиком выпилить. А потом внедрения нет (

и дырок нет

а если комп не включать - то вообще не страшно

@ri_kk будет жить. Поприветствуем!

ждём мор_тии

из С137 не стоит, его зохавала Джесика

Еще один эффективный менеджер: Я несколько раз сталкивался с тем, что такие люди строили DevOps на FreeBSD. Получалась закрытая система, которую они сами написали, и только они понимали, как она работает. Я, несмотря на мой сисадминский опыт, не мог разобраться, а если я не мог, то как разработчик должен был понять, как деплоить через эту CI-систему? В итоге я административно запретил использовать FreeBSD в компании https://habr.com/company/jugru/blog/421757/

мда, какой он админ, если разобраться не смог

Отлично. Я не понял как это работает и поэтому запретил. Средними веками повеяло

? при этом, он любит BSD

А что, на линуксе нельзя написать так, что никто не поймет, как оно работает?

да любой ОС можно

Можно, я привел пару примеров как не надо делать в Линуксе

да любой ОС можно

как пример Nano Server

можно вспотеть, пока установишь, и ещё разок, пока всё воткнёшь (что нужно)

ну такое на самом деле

Прочитал статью. Крайне сумбурная.

девопс не нужен

это очередная наёбка со стороны бизнеса что бы платить поменьше

Прочитал статью. Крайне сумбурная.

в каментах написали, что много воды ниочем

девопс не нужен

девопс не нужен, а вот CI полезен (но не средство от всех болезней, разумеется!)

типа опенспейс офисов, работы на своих ноутах и прочее модное и прогресствное

> Потому что многие разработчики в предыдущую эпоху этим не занимались: компилятор откомпилировал, а то, что там запустилось и начало работать в контейнере приложений — это уже дело десятое чувак, конечно, нашел с чем сравнивать

девопс не нужен, а вот CI полезен (но не средство от всех болезней, разумеется!)

мой опыт говорит, что совместить в одной голове экспертизу толкового дева и опса никак. Они и по отдельности уже лезут плохо

Я когда такие тексты вижу, то становится понятно что человек не понимает сути описываемых явлений, хотя и что такое на уровне ощущений знает (если можно так сказать).

мой опыт говорит, что совместить в одной голове экспертизу толкового дева и опса никак. Они и по отдельности уже лезут плохо

ну, да, тестировщик всё равно нужен живой (а вот CI ему подспорье)

и мета-админ нужен всё равно (иначе хипстерогоняние получиццо)

Удачи хипстерам с контейнерами разбираться с тонкостями ревизий сетевых чипов и версий патчлевелов системы.

ну, да, тестировщик всё равно нужен живой (а вот CI ему подспорье)

все нужны и CI сам по себе может быть полезным инструментом.

и мета-админ нужен всё равно (иначе хипстерогоняние получиццо)

Ну вот если по devops как профессией (сферой) понимать именно это, то я двумя руками за.

Я когда такие тексты вижу, то становится понятно что человек не понимает сути описываемых явлений, хотя и что такое на уровне ощущений знает (если можно так сказать).

нормально так сказать, на самом деле, даже у технарей слишком дофига завязано на интуиции и всем таком

все нужны и CI сам по себе может быть полезным инструментом.

ну, ты ж кажется знаешь, что мы с тобою одним вокабулярием пользуемся ;)

мой опыт говорит, что совместить в одной голове экспертизу толкового дева и опса никак. Они и по отдельности уже лезут плохо

да ладно, раньше (лет еще 15 назад) это была если не норма, то идеал

да ладно, раньше (лет еще 15 назад) это была если не норма, то идеал

нет. 25, быть может, и то с натягом. скорее в MIT/DARPA на границе 70-80 ?

та ну прям

я начинал как админ, и в моем представлении нормальный админ обязан был уметь программировать

люди из RU.UNIX.BSD как образец, скажем так

Ну то есть, есть объём работ на Эн людей, где есть админская а есть разработчиская составляющие. И тут мы вспоминаем, что разделение труда не просто так придумали. А уволить админов, назвав девов девопсами — это просто увеличить нагрузку на сотрудников, а не что-то улучшить.

я начинал как админ, и в моем представлении нормальный админ обязан был уметь программировать

Тонкий момент. Уметь обязан, но не должен (как бы кто не хотел обратного) :-)

Ну то есть, есть объём работ на Эн людей, где есть админская а есть разработчиская составляющие. И тут мы вспоминаем, что разделение труда не просто так придумали. А уволить админов, назвав девов девопсами — это просто увеличить нагрузку на сотрудников, а не что-то улучшить.

не просто увеличить.

Тонкий момент. Уметь обязан, но не должен (как бы кто не хотел обратного) :-)

ну не совсем - иногда таки _придется_ и это норма, но всё же иногда

я ровно о том, что когда отрасль развивается, универсалов-энциклопедистов остаются единицы. и их надо использовать как архитекторов и драйверов, а не в процессе

(ну, ок, В ИДЕАЛЕ)

ну это-то да

да ладно, раньше (лет еще 15 назад) это была если не норма, то идеал

нет. если речь идёт не о допиливании удобных скриптов, а о серьёзной разработке. Админ должен иметь общий язык с программистом и наоборот, и они должны эффективно взаимодействовать. Как в ралли. Пилот и штурман. никто под предлогом бюджетов и эффективности не делает команду со пиштурами.

с чем?..

+1

с чем?..

ПИлотоШТУРманами

ERROR: S client not available

с чем?..

А то что они по двое ездят и один только бумажку вслух читает, а?

я не в курсе, чо там как на этих ралли

Я рассматриваю концепцию devops как своего рода аналог конвейера для промышленности, когда специалист работает на своём участке в строго ограниченной функциональности и полномочиях выдавая совместно на выходе продукт средней похабности. То есть цель выдавать продукт на гора, а все остальное, включая и его качество, вторично.

Я рассматриваю концепцию devops как своего рода аналог конвейера для промышленности, когда специалист работает на своём участке в строго ограниченной функциональности и полномочиях выдавая совместно на выходе продукт средней похабности. То есть цель выдавать продукт на гора, а все остальное, включая и его качество, вторично.

это серьёзное упрощение, на мой взгляд, но направление ровно это, да

А то что они по двое ездят и один только бумажку вслух читает, а?

У пилота дифицит времени, он не может отвлекаться на чтение маршрутной карты. вот штурман ему ее и дуктует, а иногда и подсказывает, что не так

У пилота дифицит времени, он не может отвлекаться на чтение маршрутной карты. вот штурман ему ее и дуктует, а иногда и подсказывает, что не так

спасибо, Капитан!

сарказм тэги не расставил :)

это серьёзное упрощение, на мой взгляд, но направление ровно это, да

Да, разумеется. Но концептуально. Плюс отсюда вытекают следствия в виде, к примеру, резкого снижения уровня профессиональных требований к специалисту на участке. То есть, опять же, с точки зрения обеспечения процесса это только плюс.

Да, разумеется. Но концептуально. Плюс отсюда вытекают следствия в виде, к примеру, резкого снижения уровня профессиональных требований к специалисту на участке. То есть, опять же, с точки зрения обеспечения процесса это только плюс.

> с точки зрения обеспечения процесса это только плюс. highly questionable

Да нет же. Детали машины должны быть заменяемы и желательно легко.

собственно идеологически все от этой печки пляшет.

тут многослойное. потому что ещё и "создайте систему, которой сможет пользоваться даже идиот — ..."

Что меня удивляет в вакансиях DevOps (кроме самого их наличия, потому что DevOps-ом изначально назвали набор практик а не должность), так это то что требуют знания AWS, Kubernetis, CI/CD-систем, но почти ни где не требуют хорошего знания линукса и сетей. Кто же будет заниматься траблшутингом если что то сломается в продакшене? Или в их мире ничего не ломается?

Мне казалось знания Линукс подразумеваются по умолчанию, учитывая специфику должности и стеки большинства разрабов. А что касаемо сетей - там требуются знания выше базового CCNA и все что около него?

Выше CCNA не нужно (потому что там дальше про роутинг, STP и прочее мало нужное unix-админу), но как работает TCP желательно знать хотя бы в общих чертах. И про прикладные протоколы что то нужно знать тоже. И уметь запускать tcpdump при необходимости...

Да я поэтому и уточнил ибо не могу придумать как можно придти в эту сферу не обладая базовыми знаниями

Легко - изучать только модные технологии (docker, vagrant, aws e.t.c), а в случае если что то не работает делать как в винде - перезагружать, перестанавливать.

Так в любом случае изучать используя Линукс. Минимум нужно комфортно знать любой шелл и coreutils к нему.

У Стивенса есть книжка - TCP/IP Illustrated, Volume 1 - часть написанного в наше время уже не нужна, но большую часть полезно знать. И мне кажется эта книжка незаслуженно забыта, а знание сетей в среднем по больнице (среди админов, девопсов и программистов) достаточно плохое.

С инженерами 2-3 линии в России прям беда

Легко - изучать только модные технологии (docker, vagrant, aws e.t.c), а в случае если что то не работает делать как в винде - перезагружать, перестанавливать.

опытный вин-админ стоит хорошего бабла, он не перегружает, а знает где чо в реестре порыть

Что касаемо devops, то написание тех же плейбуков требует знаний, если речь про разработку и творчество, а не копипасты чужого с гита

У Стивенса есть книжка - TCP/IP Illustrated, Volume 1 - часть написанного в наше время уже не нужна, но большую часть полезно знать. И мне кажется эта книжка незаслуженно забыта, а знание сетей в среднем по больнице (среди админов, девопсов и программистов) достаточно плохое.

А как же Олиферы?

Еще один эффективный менеджер: Я несколько раз сталкивался с тем, что такие люди строили DevOps на FreeBSD. Получалась закрытая система, которую они сами написали, и только они понимали, как она работает. Я, несмотря на мой сисадминский опыт, не мог разобраться, а если я не мог, то как разработчик должен был понять, как деплоить через эту CI-систему? В итоге я административно запретил использовать FreeBSD в компании https://habr.com/company/jugru/blog/421757/

А я бы конкретно с этим согласился. Нафига иметь в проде систему которую только один человек знает

А как же Олиферы?

Отличная книга на старте