Убунты

[metaclass]

В связи с накопившимся железячно-программным вудуизмом, выкопал из загашников флешку с коллекцией мемтестов, акронисов и прочих специализированных линуксов, а так же коробку с дисками, где лежат несколько убунт, виндов, кноппиксов, GParted и прочая, и прочая, а так же запас пустых CD-R и CD-RW для войны с железом.
И заодно вспомнил, что я ж скачал новую убунту но до нее так и не добрался, решил поэтому проверить - поставил в виртуалке серверную версию и сейчас поднимаю на ней редмайн(который там таки 0.9.3), а в соседней виртуалке запустил KUbuntu и сижу проникаюсь гламурностью интерфейса.

Конечно, по сравнению с гномом в 9 убунте или дебиане, это выглядит гораздо более макоебскипривлекательно, насчет использования пока неясно - я перекопал где-то 5 пунктов меню, чтобы найти настройку разрешения экрана.
Кто-нибудь гном в 10 убунте видел, там дизайнерского макоебства тоже добавили или где, и как там с юзабилити?


PS: Такс, раз уж тут линуксовый холивор, чтобы два раза не вставать, перескажу рабочий спор недавний. Вкратце, задача: производственный сервак, на нем баг-трекер(редмайн), меркуриал и субвершн. Сейчас это винда, на ней баг-трекер и субвершн, в виртуалке на ней же - линукс, в линуксе - меркуриал(не умею под виндой поднять на нем сервер толком с правильным разделением прав и прочим).
Сервер устарел и потиху глючит, нужно менять. И нужно передать его обслуживание с меня - специально назначенным на это людям.
Я упорно доказываю, что это нужно делать на линуксе, т.к. все это я уже делал на линуксе, все используемые пакеты - линуксовые порты, линукс удобнее для серверов и удобнее в удаленном управлении (никаких тупых графических десктопов). Кроме того, я хочу обучить людей линуксу, т.к. очень много тонкостей, используемых на работе, притянуто оттуда, даже если используется под виндой.
В общем, линукс банально удобен мне, а если что-то пойдет не так - все равно придется мне или восстанавливать или обучать восстановлению людей.
Еще у меня есть соображение, что если я уеду в израиль - то на винду придут 1000 тупиц на собеседование, из которых отобрать можно пару человек в лучшем случае, а на линукс уже будет первоначальный фильтр, и можно будет просто обратится к ребе theiced, он попросит over 9000 баксов, все заплачут, но заплатят и все будет хорошо :)
Начальство колеблется - то ли винда, то ли линукс, в общем прислушивается к техническим специалистам в лице меня и ребе белнетмона.

Ребе белнетмон же упорно отстаивает винду из соображений "не хочу тратить деньги и время конторы на обучение специалистов линуксу" и уменьшения вуду в том плане, что винду люди уже умеют, а линукс нет. Используемый софт в любом случае придется изучать, а ставить его в одном случае проще под виндой (редмайн - bitnami stack, субвершн - svnserve сервисом), в случае меркуриала - апач под линуксом.
В общем, у меня реально аргументов за линукс нету, кроме "это удобнее и проще для меня, а иметь запасных обученных линуксоидов на конторе не помешает".

Comments

[veter-r-r.livejournal.com]

Ну и как вы собираетесь эти три параметра добавлять из свежего конфига в свой существующий?

[zelanton.livejournal.com]

да вообще-то у меня и нужды такой не будет. Дефолтные настройки параметров в 90% случаев меня устраивают. А если захочу поменять - залезу в консоль администрирования и поменяю эти самые значения. Где проблема-то?

[veter-r-r.livejournal.com]

Ребе, вы тупите. Без новых параметров новый функционал не работает. Ну там пути сохранения чего-то там.
Дефолтный конфиг у вас тоже работать не будет, там не те IP и т.д.
И в одном случае вам надо лазать по консолям администрирования, а во-втором просто сделать diff.

А если вы выливаете новую версию продукта на сервер, то вторую операцию вообще может выполнить скрипт, а в первом случае вам придется лазать по консолям.

[zelanton.livejournal.com]

ребе, мне кажется тут тупите как раз таки вы. Где вы видели софт, который не работает на дефолтных параметрах? Если оно не работает на дефолте, то вообще-то такие параметры спрашиваются или инсталятором или конфигуратором при первом запуске (первом запуске после апдейта софта). Иначе софт писан криворукими макаками.

[veter-r-r.livejournal.com]

Они спросились. Прописались. Настроились. При первом запуске. Софт настроился под конкретную систему. С конкретными IP, путями, логинами-паролями.
Потом вышел апдейт. Который ничего не знает про ваши пути-логины-пароли, но знает про новые клевые штуки. И вам надо объеденить эти клевые штуки с вашими существующими настройками.
Вы можете или прокликать все заново или тупо сделать diff.

[zelanton.livejournal.com]

Ребе, ёпрст.
Апдейт ставится инталятором поверх старой версии. Старые настройки, включая пути-логины-пароли никуда не делись. Про новые настройки, без которых жить нельзя спрашивает, как я уже говорил, или инсталятор (инсталятор, блин, апдэейта), или конфигуратор при первом запуске после инсталяции апдэйта. Ну шо тут непонятного?

[veter-r-r.livejournal.com]

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

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

[zelanton.livejournal.com]

кому проще? Юзеру или программисту?

Инсталятор апдэейта собирается двумя пальцами - какое файло заменить (а вы меняете во всех нужных каталогах всё руками, без инсталятора?), и про какие параметры надо спросить. Типизация параметров, их описание обязательны вне зависимости от того, гуи оно или текст, а генерация гуи для редактирования значений, хвала господи, единообразна и не требует разработки.

А за апдэейты в стиле "пользователь сам должен руками поменять файлов в таких-то папках (далее список), смержить руками текстовые конфиги, проверить новые параметры (а вдруг там появились параметры, с дефолтными значениями которых жить нельзя, ведь это целых 3% вероятности)" - вот за такое надо руки отрывать.

[veter-r-r.livejournal.com]

Ребе, тот факт, что на сервере гуи вообще никакого может не быть, вас не смущает?

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

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

[zelanton.livejournal.com]

да какая разница, на сервере или нет?
Типа на сервере - значит апдэйты делать руками?
Ну и далее по списку, который я выше привёл.

[metaclass.livejournal.com]

На сервере в норме нет никакого GUI. Так что, в случае редактирования конфигов не в тексте - нужно еще веб-морду прикручивать, или GUI доступ через файлы/сокеты/пайпы к серверному софту давать.

[metaclass.livejournal.com]

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

[sergiej.livejournal.com]

Решается это совсем по другому, вполне элементарно, добавляются "слои" в конфиг. Новый конфиг добавляет свой "слой" только своих трёх параметров. Хочешь - меняй, хочешь не добавляй слой вообще. Рекомендую - решает все вопросы почти без контроля версий, вернее заменяет контроль версий набором файлов - слоёв.

[veter-r-r.livejournal.com]

Ну и опять-таки для текстовых файлов это решается элементарным инклудом.
А для хмл или бинарников придется продумывать всю эту систему слоев.

[sergiej.livejournal.com]

Неа, в XML инклюды нативны. В XML вообще есть всё, только очень мало кто этим умеет пользоваться.

[veter-r-r.livejournal.com]

Инклуды нативны, но крайне нетривиальны.
Ну и да, никто этим пользоваться не умеет, ибо это придумано не людьми и не для людей. Хотя идея была красивая.

[sergiej.livejournal.com]

Придумано очень неплохо. Хочешь пользуйся - не хочешь не пользуйся. Большинство из тех, кто кричит про ужасность XML его вообще не изучали больше чем "взглянуть на файл и поблевать". Единственная реальная проблема XML для меня это неоптимальность по производительности, если бы его в бинарники сбрасывать и прозрачно работать с текстовым и бинарным форматом (текст для "редактирования", бинарника - для "производства") то было бы ок. К сожалению пока нет эффективных схем для этого, то что обычно делают - распарсить и хранить в памяти мне не нравится - есдт это конфиг, то рестарт приложений а это ад служб мейнтенанса.

[metaclass.livejournal.com]

Так у нормальных приложений reload конфига есть обычно.

[sergiej.livejournal.com]

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

[veter-r-r.livejournal.com]

Производительность это еще ладно. В конце концов с момента изобретения XML можность компьютеров выросла на порядки.

Проблема в том, что большинство XML-ей, которые мне попадались это именно "взглянуть на файл и поблевать". А уж всякие инструменты вроде XPath или схем -- это где-то за гранью человеческого понимания и применения. Да, можно изучить толстенный учебник по XML, чтобы быть в этом гуру, но кто будет это делать для вспомогательной технологии?

В итоге XML годится только для машинной генерации и обработки, но в этом случае они проигрывают по скорости альтернативам вроде JSON.
В общем, единственное разумное применение, которое мне видится -- это экспорт-импорт между разными приложениями. Да и то постоянно вылезают проблемы несовместимости из-за одного лишнего тэга..

[sergiej.livejournal.com]

Ну в том и сок что он годится для всего, чем и силён. JSON только частично может заменять XML. У него нет ни намёка на XSLT, схем, итп.
Экспорт-импорт это мелочи, меня волнует интеграция систем, тут XML очень выручает, а "из-за одного лишнего тэга" - теги тут ни при чём, в JSON была бы лишняя запятая, теги не виноваты, виноваты только кривые руки. Вообще наверно за то и люблю XML, что если передал "другой стороне" DTD и XSD - всё, или будут правильные файлы или можно с садистским удовольствием на системных тестах их чмырить за тупо невалидные XML. Они ноют что интерфейс "не принимает" а, оно на интерфейс то и не доходит, отбивает на валидации :)
Хотя не суть, можно хоть на JSON, хоть на бинарниках делать, важно чтобы был общий стандарт, а XML сегодня "самый общий" и при этом очень сильный, что есть хорошо. Вот если бы глобальным стандартом стал какой-нибудь CSV, тогда бы был ад :)

[volodymir-k.livejournal.com]

> У него нет ни намёка на XSLT, схем

"Ты не поверишь", http://groups.google.com/group/json-schema

[sergiej.livejournal.com]

Факт, схема. Не знал. На фоне XML-овских схем выглядит на первый взгляд сыро, но хорошо что есть.

[volodymir-k.livejournal.com]

> если бы его в бинарники сбрасывать и прозрачно работать с текстовым и бинарным форматом

http://en.wikipedia.org/wiki/Fast_Infoset

[sergiej.livejournal.com]

Ну не совсем пока прозрачно для популярных фреймворков, но кстати да...