Как стать автором
Обновить

Комментарии 37

Спасибо! Получился отличный сборник советов.
По-моему, получился отличный сборник вредных советов, как делать не нужно. Через строчку — либо откровенно устаревшая информация, либо какие-то недомоловки, либо просто ошибки. Куча картинок не совсем в тему, опять же — большей частью — сильно устаревших. Структура подачи материала (а особенно позиционирование его как какого-то законченного «теоретического минимума») — мягко говоря — странная. Ну какой, нафиг, «тюнинг MySQL» для человека, который, судя по началу, чуть ли не компьютер видит второй-третий раз в жизни?

Статья, может быть, была бы уместна году эдак в 2000, но мир-то несколько изменился. Человек, которому надо просто поставить WordPress или еще какую-нибудь CMSку, в 99% случаев не будет это все разворачивать вручную — он либо пойдет на hosted-решение, либо на какой-нибудь облачный Amazon / DigitalOcean / etc — и развернет все там из веб-интерфейса в 2-3 клика…
Я бы не сказал, что Percona, Jenkins и другие упомянутые инструменты — это прошлый век. И с чего вы взяли, что статья ориентирована именно на тех, кто ставит WordPress в два клика? По такой логике можно совсем ничего не писать о том, что под капотом.
Про Percona и Jenkins в статье — по 3-4 строчки про каждый. Зачем это туда вообще включили — совершенно непонятно. Ну чем человеку поможет CI, если в нормальном мире CI работает в связке с хоть какой-то VCS (про связку в статье почему-то скромно умолчали), генерируемые результаты работы в виде тестов должны светиться в какой-то общей системы организации работы (баг-, таск-трекере, в идеале — в автоматизированном виде в code review), а артифакты — деплоиться через какую-то систему управления конфигурациями (про что в статье тоже скромно умолчали). В итоге что? Система, на входе у которой неизвестно что, на выходе — неизвестно что, но зато «на практике это очень удобный софт».

Но это в целом все относительно ерунда, куда большие претензии к началу статьи и к сильно устаревшим объяснениям основ.
странная статья…
windows вполне умеет симлинки и хардлинки делать…
про многопользовательский режим написано так, как будто в windows его нет и права на файлы не выставить…
wine и специфический софт как раз таки почти не совместим…

почему apache, а не nginx?
давать совет по поводу GRANT ALL для пользователя, который может залогиниться с любого хоста — очень плохая штука…

Вообщем не понятно зачем это.
И, кстати, раз уж LAMP, то где must-have тула phpmyadmin? Для начинающего без нее вообще никуда, кмк.
возможно автор хотел написать PUMP MY DB, а не PIMP?
Интересно, несерьёзная статья с аккаунта серьезной компании.
Как учебник, не пойдет — не структурировано, состоит из своих мыслей о программах и ссылок на них.
Пойдет, как подборка ссылок.

Картинка с деревом порадовала, особенно /mnt/zip/music.
Послушаю-ка я мадонну, где там дискетка с её песнями? :)
Картинка с деревом была, видимо, повзаимствована автором с codeidol.com/img/fedora-4/0672327074/graphics/05fig05_alt.gif — это из статьи про Fedora Core 4, 2005 год. /mnt/zip и X11R6 тогда еще могли быть, да %)
в нашем ремесле без знания *nix-систем никак

Красноглазики выходят на связь. Слишком категоричный тон, как по мне. Что не отменяет того факта, что знание *nix-систем в целом это неплохо, а в частности полезно специалисту в той или иной области.
Win понимает оба слэша.
Еще один повод минусануть: впервые вижу, чтобы «мускул» называли «моськой»)
минусануть мой коммент, а не статью, забыл уточнить, пардоньте)
Статья хороша, но устарела по существу лет эдак на семь если не более.

Сейчас в *nix на порядок все интереснее и закрученнее, а окружение в общем и целом каждый строит под себя и в подавляющем большинстве случаев оно разительно отличается от описанного.

Например, для типичного Rails-разработчика тот же *nix предстает в немного другом свете нежели для PHP-разрботчика, всю жизнь клепающего сайты на виртуальных хостингах под готовыми джумла-перссами.

Совсем недавно попадалась на глаза очень годная настольная книжка из разряда «галопом по Европам *nix» где предисловие как раз несет свет знаний «зачем оно все нужно и примерно как работает», вот очень пожалел что как раз под рукой лет 7-8 назад такой не было. Парадигма там строилась очень правильно — «в *nix, всё есть файл». И только осознав это, начинаешь действительно на ином уровне работать с системой, в этом как мне кажется ключевая фишка никсов, а уже остальное — уточнения да расширения.
как раз закралось подозрение, что изначально статья или заготовка была написана давно… значит не только у меня.
Не могли бы вы в общих чертах описать, что устарело и как оно сейчас (ну или ссылкой киньте)? Хотел бы проверить свою закостенелость =)
По сути актуальна сейчас только первая часть, дальше идет вкусовщина, ориентированная только на PHP-разработчика с определенными «стандартными» задачами.

Все что касается настройки — это только от задач зависит. Почитайте по разработке на Node JS — там одно окружение, по Rails — там совершенно другое. Точно также, если вы в принципе не работаете с MySQL, то он вам и не нужен, можете смело пропускать всю эту часть, равно как и LAMP-ы со всякими XAMP-ами, MAMP-ами и прочими Денверами тоже лучше пропускать, т.к. все необходимое окружение лучше ставить ручками — так опыта больше и понимания что где отвалилось и почему может не работать.

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

Просто в 2014-м году, работа программиста под *nix — это намного более широкий и менее однородный комплекс действий/мер/подходов нежели описано в статье.

P.S. foxmuldercp комментом ниже продолжил мысль этого коммента
И это я не говорю про очень модный нынче подход работы через изолированные контейнеры по принципу Docker, Vagrant и прочими удобствами.

Просто в 2014-м году, работа программиста под *nix — это намного более широкий и менее однородный комплекс действий/мер/подходов нежели описано в статье.


Если бы более широкий.
Нынче модно делать curl github/repo/install-script | sudo bash, чтобы оно «само поставилось».
Каждый раз, как вижу такой туториал
image
Перепечатано с xakep.ru образца конца двадцатого/начала двадцать первого веков?
Еще весь нормальный ентерпрайз давно использует postgresql или оракл, в зависимости от задач, nginx, ну и openvz в качестве виртуализации, а так же активно смотрят на docker.
А использование webmin считается плохим тоном. он спасает разве что в вариантах, когда на телефоне/планшете есть только броузер и что-то реально поломалось а вы черт знает где и у инженера сапорта нет на это прав. И то, я бы такое выставлял не напрямую, а по впн хотя бы.
А еще надо бы рассказать про монтирование удалённых файловых систем для бекапов куда-то вне хоста.
И совет про експерименты в виртуалке недоступной наружу — а то мало ли что откроете или забудете и натворят делов плохие дядьки
Интересно, что за WM используется и в каком окружении на скрине с nmap?
Ощущение, что автора заставили написать статью, вот он и выкрутился. Запахло лабораторными из университета.
Судя по всему да. Не знаю, нубство это (что было бы простительно) или профанация.
Apache лишний.

«Тюнинг БД» какое отношение имеет к «теоретическому минимуму»??? Кстати, в «максимуме» он тоже противопоказан!

Не нашел виртуалки — хотя именно с них и надо начинать!

Почему многие developer-ы любят *nix-системы? Да потому что они стандартизированы системой стандарта POSIX

Нет. Не за posix, а за простоту, безопасность и надежность.

Чувствую себя неловко из-за восклицательных знаков в моем комментарии. С одной стороны, автор проделал большую работу, с другой стороны — материал неполон, неверен и оттого очевидно вреден.
Материал хорош однозначно и автору спасибо. Статью не следует воспринимать как сборник догм или аксиом, скорее как путеводитель — что вообще есть, с чего начать и в каком направлении идти, если хочется что-то узнать.
Спасибо автору! Я ощутил себя где-то в начале двухтысячных. Ностальгия, прослезился.
А я думал
… что точно не пройдёт модерацию:
  • статьи, ранее опубликованные где-либо;
вроде исключения для блогов компаний?
Хосты, которые настроены и существуют (но не факт, что включены!) лежат отдельными файликами в папке /etc/apache2/sites-available. А хосты, которые используются и активны в данный момент, лежат симлинками в папке /etc/apache2/sites-enabled.
Когда вы делаете это руками или просто пишете в файл основнового конфига, где-то плачет один котик, ну, или собачка — кому кого больше жаль :).

Ой ли?

Во-первых, вы описываете просто «debian-way» настраивать Apache/nginx, а не что-то общепринятое и правильное. Просто в какой-то момент мейнтейнеры debian решили, что так удобнее и создали такую сложную структуру. На других системах, дистрибутивах и даже некоторых пакетах не из репозитория debian/ubuntu, а также в nginx и apache по умолчанию нет таких каталогов;

Во-вторых, удобство такого подхода сомнительно, особенно когда речь идет всего о нескольких виртуальных серверах;

В-третьих, до недавнего времени такой подход просто приводил к непредсказуемым результатам в случае nginx. Поскольку в отдельных случаях порядок следования блоков server в конфигурации имеет значение, а до версии 1.3.10 файлы включались в конфигурацию в произвольном порядке, так что с этим подходом можно было легко огрести проблем.
Символы переноса строки Win — “\r\n — CRLF”; *nix — “\n — CR”; mac — “\r — LF”


Перепутали вы всё :) Да и отдельный вариант для Mac актуален только для тех, кто до сих пор пользуется классической Mac OS до 9 версии.

*nix, включая OS X — \n (LF)
Mac OS <=9 — \r (CR)
Падаван и без chroot/selinux/ids?! И ещё и в продакшен?! Или я чего-то не понимаю и это уже джедай-скилл?! В современном мире сервер падавана-по-этой-статье если и заведётся в паблике, то будет уложен школотой с вконтактика смеху ради. Со всем уважением к автору.
Начали неплохо. Заинтриговали. И дальше скатились в перечисление ссылок.
yakuake — та же Guake выезжающая консоль для kde
Зарегистрируйтесь на Хабре , чтобы оставить комментарий