Category: компьютеры

Category was added automatically. Read all entries about "компьютеры".

Вендекапец, наконец-то?

https://www.facebook.com/sloneus/posts/636050909879742?comment_id=636074829877350&reply_comment_id=636385283179638&comment_tracking=%7B%22tn%22%3A%22R%22%7D

Слушайте, а чо слонеус и лапшин утверждают что винды в госсекторе больше нет и не будет?
Как по мне - так скорее бы это произошло (проще обслуживать, меньше тупизны вроде антивирусов на серверах БД, опять же - лучше бы бабло которое у клиентов идет на виндолицензии себе в карман положить, на доработки и обслуживание всякое), но по моим наблюдениям в РБ даже если где линукс в госконторах и есть - то там его все равно готовить не умеют, потому что доморощенные линуксоиды из БГУИР и прочих институтов инженеров заборостроения, которых не забрали в аутсорс и эмиграцию - это админы локалхостов в основном.

PS: соседний псто http://ru-sysadmins.livejournal.com/2524542.html: "Из минусов - Всё крутится на 2003 и 2008 виндах. Полувоенная организация со всеми вытекающими".
Ну и кому верить?

Файловый кэш винды

Мне кажется, или новые винды (2008, win8, 2012) по умолчанию нихрена не кэшируют файловый i/o?
Вот у меня есть 2003 винда, 32 битная, с PAE - 16 гиг памяти, из них 3 гига занято файловым кэшем, работает вроде приемлемо.
И есть 8 на ноуте и 2008-2012 у клиентов - практически везде Process Explorer показывает размер кэша что-то в районе 150-250 мб, независимо от того, сколько физической памяти на компе.

Только у одного клиента (понятия не имею каким образом, проявилось после установки SSD) внезапно файловый кэш начал забирать все 12 Гб памяти и вытеснять остальное в своп, что пришлось чинить костылями.

Есть опция LargeSystemCache в реестре, есть CacheSet и RAMMap от sysinternals для настройки и диагностики, но добится чтобы 8 винда сожрала больше 250 мб кэша у меня в принципе не получается.

Хрен бы с ним, но она ж субъективно тупит на i/o и старт винды занимает дикие минуты, прежде чем можно пользоваться.

PS: https://support.microsoft.com/en-us/kb/976618
Похоже в новых виндах "починили" проблему забирания всей памяти под кэш так, что теперь кэш почти не используется.

bit rot

Только что обнаружил что-то, по симптомам очень похожее на bit rot.
Рабочий компьютер, тестовый CI сервис ругается, что не может собрать проект. Причем собирает он всегда из репозитория, на других CI серверах все ок. Заглядываю в исходники - а там в нескольких строках биты случайно покорежены:
буква 'e' (код 0x65) заменена на букву 'd' (код 0x64)
буква 'e' (код 0x65) заменена на букву 'u' (код 0x75)
буква 'a' (код 0x61) заменена на букву 'A' (код 0x41)
буква 'o' (код 0x6F) заменена на букву 'O' (код 0x4F)
и еще переносы в другие контрольные символы превращены.

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

Надо на этом компе, что ли, память и диски проверять срочно.

Запретите им.

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

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

Классификация платежей в белорусских интернетах

Платежи в ЕРИП делятся на:
1) Полученные наличными деньгами
2) Содержащие во втором поле номера счета цифру 7
3) Полученные в пользу ООО "Лаборатория перспективных исследований при НИИГиТ"
4) Уплаченные женщинами старше 60 лет.
5) Издали похожие на биткоины.
6) Введенные вручную с указанием паспортных данных
6.1) В том числе с пропиской в г. Хойники.
7) Прочие
7.1) Включенные в эту классификацию
8) Не прошедшие
9) Введенные в отделении почтовой связи с клавиатуры со 78 клавишами.
10) За временное хранение на таможенном складе посылок весом не более 3.14159 кг.

PS: Для незнакомых с местными реалиями - в РБ большая часть постоянно проводимых безналичных платежей (связь, интернеты, коммунальные услуги, школы-детские сады, пошлины, штрафы) внесены в т.н. Единое Расчетно-Информационное Пространство (ЕРИП). Оно же отображается в интернет-банках. Для выбора получателя платежа используется дерево, составление которого велось явно под тяжелыми веществами и под впечатлением от классификации животных Борхеса, потому что логика там явно диктовалась какими-то легаси-технически-содомскими соображениями, но никак не удобством использования или разбиением на разумные категории.

Безумная кложурная жесть

Делаю генератор отчетов, у которого часть работы - запросы к БД и часть - постобработка. Все это работает в фоновых потоках clojure (внутри future) и паралелльно еще несколько потоков (из ScheduledThreadPool и его вариаций из java.util.concurrent) выполняют всякую вспомогательную работу типа "очистить старые данные", "пересчитать изменения пришедшие в очередь в БД".
future в clojure реализованы в том же thread pool что и функция send-off для агентов. Этот thread pool не имеет ограничений по размеру и изначально предполагался для операций, ожидающих i/o, а не cpu-bound. Пока отчет считается в БД - это нормально, но когда начинается постобработка, при превышении некоторого порога количества потоков - возникают совершенно непропорциональные тормоза, типа 30 отчетов одновременно считается за 2 минуты, 64 отчета считаются 30 минут.
Надо как-то более равномерно распределить работу по времени, чтобы количество нагружающих CPU потоков было ограничено, что ли. И вообще, надо как-то осилить профилирование нагрузки, чтобы знать, чем там кложурь и JVM занимаются.

Amazon EMR

Наслушался сегодня зогбиватора про то, как его знакомые на Amazon EMR молотят жабой какой-то Machine Learning c финансово-маркетинговой аналитикой и сижу думаю, где взять столько данных и тяжелой по CPU, но параллелизуемой аналитики, чтобы имело смысл попробовать там что-нибудь посчитать.
А то получается, что у меня, например, похожая аналитика всегда упирается в дисковый i/o и глобального смысла в том, чтобы закачивать данные на S3 и оттуда их уже молотить на EMR, я не наблюдаю.
Вот если бы какие-нибудь десятки-сотни гигабайт данных от независимых источников сразу туда складывать, препроцессить и забирать обработанные - наверно имело бы смысл.

reference types vs value types

Очередной раз посрались с артурегом за типизацию. Его огорчает существование value-types (или примитивных типов в жабе) из-за того, что они накладывают более жесткие ограничения на получение значений этих типов извне.
Например при загрузке из БД с полем, разрешающим null - придется либо сдыхать с исключением, либо устанавливать некое "значение-по-умолчанию", которое потом не отличишь от такого же значения, но введенного явно.
По моему - это какие-то проблемы, не то уровня начинающих, а вообще детсадовские, т.е. проблемы реально не существует.
Либо предметная область разрешает "отсутствие данных" и мы таскаем всюду Option[T] или жабьи объектные врапперы или C# Nullable<T>, либо предметная область разрешает использовать некое значение по умолчанию и нам его отличать от отсутствия данных не нужно, либо данные обязаны присутствовать и мы таскаем value-type, в базе делаем поле not null и в прочих протоколах делаем поле обязательным и дохнем с исключением (возвращаем код ошибки) при его отсутствии.
Если требования не зафиксированы заранее - пользуемся логикой и выбираем один из трех вышеописанных вариантов. Если требования в процессе разработки меняются - рефакторим. Если требования противоречивы - доводим до заинтересованных лиц и дальше либо делаем требования непротиворечивыми, либо ослабляем строгость ограничений (убираем not null и рефакторим все из value-types в reference-types или Option[T]/Nullable<T>)

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

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

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

Мне дичайше "везет"

Очередное программистское сумасшествие.
Как известно, у пользователей в виндах XP/Vista/Win7 есть папка для пользовательских данных. Логично предположить, что на нее всегда есть права доступа, потому что иначе запуск большей части программ теряет смысл вообще - им даже настройки сохранить некуда будет.
Так вот, сегодня я при помощи QA персонала умудрился откопать вариант, при котором доступа нет никуда вообще.
Windows XP - правой клавишей на исполняемом файле - "Run As" - оставить включенной птичку "защитить мой компьютер/restricted access": http://blogs.msdn.com/b/aaron_margosis/archive/2004/09/10/227727.aspx

В этом режиме не работает ничто и нигде. Бездны огораживания. HKCU в реестре недоступен. SHGetFolderPath возвращает первый раз ERROR_ACCESS_DENIED, второй раз что-то вроде "обращение к несуществующему токену".
Как обычно - "невозможные" ошибки обрабатываются плохо - поскольку при тестировании в эту ветку попасть практически нереально, баги в обработке ошибок могут быть совершенно ужасные.

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