Pull to refresh
0
0

User

Send message

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

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

В целом наверное +/- как везде по России (ну может кроме Казани - там вроде все круто)

До маршрутки вы же пешком идете? ;)

я живу в регионе где в году кол-во дней с осадками - больше 200 ))
- достаточно иметь правильную одежду...

Реальных дней когда сложно дойти пешком/на велосипеде (сильный ливень/жуткая метель) - всего несколько в год, в метель на любом транспорте есть сложности с перемещением, в ливень - ценник на такси более чем конский...
- в такие дни проще поработать с дома (мы же про IT говорим?)

до работы 4км:
* пешком - 35 минут,
* на маршрутке - на 5 минут быстрее,
* на такси - на 15 минут быстрее,
* на велосипеде - как на такси

то есть по факту нужно найти не 1.5 часа каждый день, а всего лишь 10 минут в случае маршрутки vs пешком, а на велосипеде - еще и лишних 20 минут появляется

лучше хотя бы тем, что если скрипт упадет с ошибкой lockfile все равно удалится и не придется его чистить руками. exit 255 правда не к месту в случае нормального завершения ))

На самом деле на бакенде apache+mod_php кушают примерно столько же, сколько php-fpm при одинаково настроенных пулах. Так что выбор того или другого бакенда — вопрос больше личных предпочтений.
Вы спрашивали «если рынок труда подорожает на 20-30 процентов» согласитесь это не одно и то же с «если цены вырастут за полгода на 20-30 процентов как было в 2014м» — все таки стоимость специалиста на рынке зависит не только от цен в магазине…
Если стоимость специалистов вырастет — ЗП будет индексирована. В 90-е с их гиперинфляцией (далеко не 30% за полгода) такое наблюдал лично.
Ну я работаю в такой компании… И сын — тоже (замечу — в другой )) )

ЗП определяется ценностью сотрудника для компании, если по мере работы в компании ценность сотрудника возрастает — ЗП растет. Более того это анонсируется сразу при приеме на работу, часто с указанием конкретных уровней которых должен достичь сотрудник для изменения своего статуса. И индексация в соответствии со средней по рынку тоже есть, иначе банально можно потерять специалиста…

На самом деле в большинстве случаев так есть везде: берут junior/middle, он вырастает до midlle/senior — соответственно с повышением ЗП. Senior`у тоже как правило есть куда развиваться: новые технологии, переход в в architect/team-lid/… В адекватной компании все это приводит к изменению ценности сотрудника, из неадекватной проще уйти, что обычно и делают.

Кстати не всегда сотрудники хотят повышение ЗП, некоторые например предпочитают уменьшение рабочего времени, возможность заниматься определенными проектами. Гораздо более важно чтобы эти желания были вовремя озвучены менеджеру, потому что открытая позиция действительно повышает взаимное доверие.
в PrepareRequest можно обращаться к любым объектам OTRS, например для получения всего объекта тикета:
my $TicketObject = $Kernel::OM->Get('Kernel::System::Ticket');
my %Ticket = $TicketObject->TicketGet(
        TicketID => $Param{Data}->{TicketID},
        DynamicFields => 1,
);

после чего выдать нужные поля в Data…

Еще замечу, что не надо хранить свои правки в otrs/Kernel/* — для этого есть каталог otrs/Custom (то есть свой Invoker надо положить в otrs/Custom/Kernel/GenericInterface/Invoker).
В этом случае при обновлении самого OTRS ваши правки не будут потеряны
ну русская википедия то еще чудо ))
давайте посмотрим на английскую: en.wikipedia.org/wiki/PHP
— там хоть пруфы есть, типа такого: twitter.com/rasmus/status/226405807305138176
мне исправно приходят уведомления за 2 недели до кноца уже 3-й год,
и на сертификаты на email и на сертификаты на домены…

может уведомление порезало спам фильтром?
хранить бакапы на той же ФС как-то небезопасно: если ФС развалится, то снапшоты — тоже

я бы все таки делал на другое устройство хотя бы тем же rsnapshot
— он умеет делать хардлинки и одинаковые файлы в разных бакапах не будут занимать лишнего места
Видео декодируется на сервере, 3D рендерится там же, задача тонкого клиента — организовать удаленный терминал к серверу…
Ну еще прокинуть на сервер некоторые устройства (флешки, e-token например), ничего более.
Если посмотреть на чем сейчас зачастую делают тонкие клиенты — так Atom по сути топовое решение ))
а декодировать видео или 3D тонкому клиенту надо?
вот уменьшиться цена — тогда уже можно думать…
по поводу корпуса — тут его тоже нет, сколько спец. корпус + БП будет стоить?
корпус mini-itx с встроенным БД и vesa креплением на монитор стоит 1500- 2000
в итоге тонкий клиент который спокойно держит FullHD мониторы и звук в обе стороны
и для которого есть готовый софт обойдется 4000-4500

а зачем WoL на тонком клиенте?
— мы вообще предпочитаем ТК с сетевой загрузкой — так обновлять и конфигурировать софт ТК проще

вот только цена платы на сайте (3200) делает бессмысленным ее приобретение
— комплект mini-ITX на Atom + 1Гб памяти обойдется около 2500-2700 даже в розницу
при этом будет иметь большую производительность и возможность поставить кучу стандартных дистрибутивов
а что в бинари логи стали писать селекты?
Не знаю как насчет экономии памяти — у нас ситуация получилась обратная:

Сравнивали на реальной нагрузке (40-50 разных сайтов на php) nginx + php-fpm + xcache и nginx + apache + mod_php + xcache, настройки пулов worker в apache и php-fpm одинаковые.
Да при старте php-fpm занимает в памяти меньше места, но через некоторое время догоняет и обгоняет apache. У apache больше памяти остается разделяемой между процессами.
Разница в использовании памяти не велика (в пределах 7-10%), но она сесть.

Производительность php-fpm по сравнению с apache + mod_php меряли на синтетических тестах (ab), на том же наборе сайтов — php_fpm на 2-4% быстрее apache. Причем на apache стоит mod_security, который явно не ускоряет процесс…

С учетом того что часть сайтов не наши и необходимо для них конвертировать rewrite apache в nginx — остались на связке nginx + apache
в принципе — нет, скорее наоборот:
Ubuntu LTS имеют более долгий жизненный цикл (5 лет против ~2 года у Debian)
мы в своей компании например долгое время использовали Debian, но сейчас все новые сервера — Ubuntu Server

Information

Rating
Does not participate
Registered
Activity