me

slonik_v_domene


Убей в себе государство


Линукс на десктопе
me
slonik_v_domene
2015 год - год Линупса на десктопе.
Что имеем сейчас:
- Unity адски тормозит на любом разумном железе, делает диафильм из любого анимированного виджета. Найти через стандартный диалог поиска ничего нельзя. Регулярно, раз в 20-30 секунд падают программы из Unity, если у вас 1-2 Гбайт оперативной памяти.

- В KDE нормально нельзя сделать самые простые вещи: вытащить на рабочий стол шорткат для программы, передвинуть его( Карл, его нельзя передвинуть, потянув мышкой!), с первого раза добавить локализацию (а после рестарта - можно!), изменить шрифт в Konsole, все темы, даже контрастные, невообразимо блеклые, и хорошо смотрятся только на IPS. При установке русской локали ставится en_RU.UTF-8 вместо ru_RU.UTF-8, из-за чего куча qt-шных программ падает без четкой диагностики (в коредампе - sigsegv в каком-то messagebox). Поиска по помощи нет, от слова "совсем" (Control-F ищет только по текущей странице, ёбстыд!). Самые простые вещи закопаны внутрь меню третьего-четвертого уровня. Общая бессистемность настроек (в одном месте выбрал локализацию, совершенно в другом - раскладку клавиатуры). И все это тоже тормозит, хотя и меньше чем Gnome.

Я помню времена KDE2 и KDE3. Тормозило всё всегда, но, по крайней мере, раньше не было таких адских требований к оперативке, да и интерфейс был примитивнее и в своей примитивности - менее убогий.

Собственно, к вопросу о том, почему каждый год - год Линукса на десктопе, а как был 1% процент рынка, так он и остался. Причина проста: ваши десктопные продукты - говно, которым невозможно пользоваться. Если вы ими пользуетесь, то либо вас заставили из-под палки, либо вы - мазохист.

Пользоваться десктопным линуксом можно только как запускатором браузера и/или терминала в Windows. Вот и весь результат двадцатилетнего прогресса.

Обсуждение в ФБ: https://www.facebook.com/sloneus/posts/518416144976553

Задачка на знание С++
me
slonik_v_domene
О преждевременной оптимизации, которая обернулась пессимизацией.
http://pastebin.com/JJL9Hf3A

Если закомментировать кусок кода между строками 5 и 8, скорость работы увеличивается в 55 раз.
Кто ответит, почему так?

Психологи в HR
me
slonik_v_domene
Давайте поговорим о девочках, которые отучились в МГУ на психфаке, поступили в аспирантуру и даже защитили диссертацию (впрочем, последнее не обязательно).

Хорошо, когда ты, такая умная устроилась работать по специальности - инженером человеческих взаимоотношений, помощницей потерянным людям и прочая и прочая. Если у тебя так, милая психологиня, дальше можно не читать. Я всзаправду рад за тебя.

Но иногда бывает и так, что приходится работать кадровичкой, по-заморски - HR-ом. И тут вдруг выясняется что почему-то всё плохо, никак не подбирается коллектив, тебе хамят, и жизнь идет мимо. Было такое? А знаешь, почему так? Я объясню.

Все дело в том, что вот ты в свои неполные 30 кандидат психологических наук, выпускник Универа, вроде как ученый, а вынуждена обхаживать заносчивых технарей, каждый из которых имеет мнение, говорит на англорусском суржике, тебя, из-за того что ты не въезжаешь, ни во что не ставит, при этом сам еще и кандидатом наук не является.

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

А знаешь, в чем дело? В том, что хороший HR является психологом в последнюю очередь. Повторяю: быть психологом - совсем не главный навык. Из-за этого твои знания и умения не будут востребованы и должным образом оценены, и если ты к этому не готова, у тебя ничего не получится.

О том, какие умения нужны - в следующем посте. Возможно))

ЖЖ такой ЖЖ
me
slonik_v_domene
http://www.rbc.ru/rbcfreenews/559f98d49a79473e2d0a2a46

Дорогая София Иванова​!
Давайте я вам расскажу почему никто не пойдет в уютную ЖЖ-шечку. Правда, я не совсем понимаю, почему вы сами не видите причин, и почему настолько прописные истины надо объяснять в 2015 году.

Смотрите, в чем дело.
1. Уютная ЖЖ-шечка постоянно вываливает 500-е ошибки. Настолько, что если на странице "Varnish Error 503 Service Unavailable" поставить рекламный баннер доход от него превысит доход от всех платных пользователей.

2. В 2015 году вы предлагаете платить деньги за юзерпики(!). Кто не знает, это - аватарки, мааааленькие такие картиночки. И платным пользователям разрешаете использовать до 30 (тридцати!!! юзерпиков!!!). При размере юзерпика в 40 килобайт максимум и цене в $10 за 40 дополнительных вы хотите снять с пользователя $10 за 1.5 мегабайта дискового пространства в год. Это примерно в 1 300 000 раз дороже чем если самому купить хард-диск соответствующего размера.

3. Купить место для фоточек невозможно не купив платный аккаунт, а изначально дается всего 1 Гб. Примерно 100 фоток можно залить в среднем качестве.

4. ЖЖ, когда не падает, работает. Но делает это откровенно медленно, настолько, что вспоминаются времена до-ADSL.

София, давайте по чесноку, вы действительно считаете что сервис образца 2005 года может быть более привлекателен чем Facebook только на основании того что там никого не банят? Это, кстати, ложь "http://navalny.livejournal.com/ -> ОШИБКА 451
На территории вашей страны просмотр этой страницы запрещен органами власти".

София, пару советов. Прежде чем предлагать перейти из ФБ в ЖЖ, хотя бы сделайте сервис стабильным. Черт с ними, с юзерпиками, все обходятся одним-двумя. Можно обойтись без картинок, для этого есть фоточки Яндекса. Но постоянные 503... - это для 2015 года перебор. И нет, не надо рассказывать что ЖЖ слишком сложен, что его невозможно переделать, что вас DDoS-ят каждый день. Facebook справился - значит, и вы справитесь, если хотите чтобы пользователи пошли из ФБ к вам.

Email list
me
slonik_v_domene
Если вы прочли rfc и вздумали написать парзер списка адресов, у меня для вас очень плохие новости. Эти же плохие новости относятся к Dovecot и Communigate.

Мир намного сложнее стандартов, особенно учитывая наличие программистов на PHP и мега-CMS Drupal, Joomla и 1C Bitrix.

Да, надо следовать стандартам, но если вы пишете парзер, то следовать надо не стандарту, а реальности, иначе у вас вместо логина и домена очень часто будет nil или MISSING_MAILBOX/MISSING_DOMAIN.

Вы не сможете объяснить заказчику, что адрес Ivan <ivan@example.com> - валидный, а адрес .Ivan <ivan@example.com> - нет только на том основании что еще один PHP-джуниор не смог осилить rfc. Особенно, если ведущие почтовые сервисы спокойно обрабатывают битые адреса.

https://tools.ietf.org/html/rfc2822
https://tools.ietf.org/html/rfc5322
https://tools.ietf.org/html/rfc6532
https://tools.ietf.org/html/rfc6854

P.S. И, да. У Мэйлрушечки в парзере списка адресов баги. Хорошо, что в большинстве случаев они не проявляются, но тестировщики их должны были бы найти.

https://www.facebook.com/sloneus/posts/478702688947899

Про ZeroMQ
me
slonik_v_domene
Спасено из тонущего поста ФБ.
https://www.facebook.com/oleg.i.tsarev/posts/10206505560627604

Участники: slonik_v_domene, lionet и zamotivator

Претензии к 0MQ:
- повторяя семантику BSD sockets не работает как BSD sockets;
- дескриптор 0mq нельзя передавать между потоками;
- оно глючит при/после коредампа или любого некорректного завершения одного из peer;
- криво построена работа в асинхронном режиме (все эти poll);
- течёт;
- по дизайну (!) не даёт делать прокси;
- по имплементации не рассчитано на слишком большое количество клиентов;
- по дизайну (!) не рассчитано на облака и доступ интернетных клиентов, только на fixed IP и всякий энтерпрайз подобный;
В общем, использовать это в продакшене = наживать лишний геморрой и седые волосы.

Отдельное замечание про паттерн REQ-REP:
Дело в том, что в 0mq REQ-REP принципиально нельзя работать иначе как вызывая read и write в четкой последовательности.

Отсюда проблема с ребутом: если процесс упал, есть 50% вероятности что данные не были записаны или прочитаны. После чего оно залипает и приходится гасить второй peer. Это все проходили в продакшене, проходили с большой кровью, что когда один компонент отваливался, надо было рестартить все остальные из-за того, что 0mq находилось не в том состоянии.

REQ-REP 0mq - ужасно неудобная вещь, пользовыаться ею как альтернативой BSD sockets нельзя.

В паттерне PUB-SUB этой проблемы уже нет. Но проблема в том, что когда ты все паттерны разберешь и поймешь, что тебе нужен только один, и он — самый сложный, самый нерекомендуемый докой на ømq, самый недодокументированный, и с самыми неочевидными преимуществами над обычными сокетами паттерн ROUTER-ROUTER.

Вообще, с 0mq работа выглядит примерно так: ты что-то делаешь, как правило - простые вещи. И они у тебя получаются быстро и просто.
Потом ты осознаешь что в проекте надо сделать каую-то простую и очевидную вещь, ну там между потоками передать дескриптор очереди.

И вот тут получается Drupal learning curve.

Вопросы на собеседованиях
me
slonik_v_domene
Я вот понять одного не могу: чего добиваются интервьюеры на собеседованиях, когда задают вопрос из серии "реализуйте B/B+ дерево"?
В финском языке есть такое слово "myötähäpeä" - чувство стыда за другого человека. Вот когда я слышу на собеседовании подобное, мне, цЫничному гопнику, становится стыдно до состояния "пойти и удавиться шнурками кед".

Мне.

Становится стыдно.

Да, я сам вахуе.

Дорогие сениоры, техдиректоры и прочие системные архитекторы! Задавая подобные вопросы на собеседовании вы демонстрируете дремучесть студента 1-го курса института при зашкаливающей самооценке, рядом с которой Дейкстра, Керниган и Ричи - дети, едва изучившие BASIC. Сколько при этом котиков убивает господь, я судить не берусь, но думаю, что не меньше 9000 за раз.

Просто запомните, если не готовы сами повторить эксперимент: работоспособное B/B+ дерево начинается от 4000 строк кода. До этого момента это не дерево, а школьное поделие, ценность которого околонулевая с любой точки зрения. Дерево, которое поддерживает транзакции, требует по крайней мере 8000 строк кода (данные - про реализацию на С; но написанное актуально и для Java/C++). Добавление в дерево репликации, lock-free доступа обходится примерно в 3-5 тысяч строк для каждого изменения. Представьте себе, да: это - действительно сложный алгоритм. В любом случае это не тема ни для рисования алгоритма на собеседовании, ни даже для домашнего задания на несколько дней.

Если вы не верите написанному, велкам смотреть исходники SQLite, InnoDB и BerkeleyDB.

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

ФБ-копия поста - тут: https://www.facebook.com/sloneus/posts/476966385788196

О солдатиках и СССР.
me
slonik_v_domene
Так вот. В тоталитарном СССР в 1983 году у меня были солдатики: красного цвета - наши, и зеленого - фашисты. Именно фашисты - со зверскими рожами и шмайссерами.
Потому, что даже пятилетнему ребенку очевидно, что наши с нашими не воюют, а воюют с фашистами. Очевидно это было и тем, кто этих солдатиков делал на заводе.
А тупые поцреоты и ханжи 2015 года, и все те говноеды что устраивают вой, пусть займутся автофелляцией и укусят себя за хуй.

В очередной раз о Хабре, мозгах и безопасности.
me
slonik_v_domene
http://geektimes.ru/post/247794/

Нет повести печальнее на свете, чем повесть об идиотах с Хабры.
Здесь можно много чего обсуждать, но особо хотелось бы отметить следующее:

1. Отсутствие мониторинга происходящего. Хостинг в облаке не дает вам права забить на мониторинг своих проектов. И - нет, мониторинг не должен и не может работать с того же облака, которое мониторит. Более того: доступ к машине мониторинга с серверов облака - серьёзнейшая дыра в безопасности.

2. Имбецильная любовь к графическим тулзам и управляторам в ущерб скриптовой автоматизации. Сейчас этот свойственно не только любителям МакОс и Окон; уже подросло поколение линупсоедов, не способное написать простейший скрипт. Как результат - закат солнца вручную и выключение виртуальных машин кликами в админской панели.

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

4. Абсолютная безответственность по отношению к своим проектам и данным клиентов. Хорошо, что гражданину только подняли дорогие виртуалки, а ведь могло бы так сложиться что грохнули бы все данные.

5. Общая глупость автора, как то: незнание английского языка _хотя_ бы на уровне написания жалобы в саппорт, нежелание найти в конторе (в которой он, на минутку, совладелец) человека, говорящего по-английскию

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

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

Обсуждение - здесь: https://www.facebook.com/sloneus/posts/456730424478459

systemd, как и ожидалось
me
slonik_v_domene
Не прошло и пяти лет как появился systemd, якобы упрощающий процесс загрузки линукса, а уже все сколь-нибудь серьезные проекты пишут скрипты поднятия собственного мира в ExecStartPre и ExecStartPost.

Как всегда: хотели что поудобнее, а в результате вся пидерсия просто перекочевала из /etc в /usr/libexec, причем поп сути ничего не изменилось. Даже хуже стало.

Мораль же проста:
1) не надо улучшать то, что и так работало.
2) не следует делать универсальных решений - они неудобны, и в конечном итоге всё равно сведется к куче скриптов.

?

Log in