Маконенависти очередной псто

Читая RSS, наткнулся пост "что вам нравится в МакОС" на ДОУ. Первым пунктом было:

 Типографика. Алгоритм сглаживания шрифтов в Mac OS настолько хорош, что я искал и ставил специальную программу для Windows, «чтобы было похоже».

На что моей первой реакцией было "лолчто?!" Сглаживание шрифтов в МакОС (а особенно в XCode) меня дико раздражает.  Кстати, интересно, как AppCode удается быть менее ШГ,  используя тот же шрифт, что и XCode?.
Ах да, наверное, если бы у меня был не обычный монитор, а Apple Cinema или MacBook c уриной ретиной, я бы считал по-другому.

 "Гуй застрял в 90х! -- Вы хотите странного и это не нужно".
Развернуть окно на пол-экрана (фича, которая из маргинальных тайловых менеджеров давно перекочевала в гламурный гуй вроде Unity или Win7) -- "А это нужно? Можете описать юзкейс?" Хотя и привели в комментах парочку программ (одну платную, и одну бесплатную), которыми это можно сделать. При этом на сайте бесплатной про клавиатурные хоткеи написано 2 предложения, все остальное -- touchpad gestures).
Развернуть окно, свернутое в док -- "Используй силу мышку, Люк". Ctrl+F2, W, вниз до конца, выбрать из списка, Enter -- весьма эргономично, да. Да и в целом -- мышкой возить приходится на порядок больше, чем в Windows/Linux, что раздражает.
Наверное, будь у меня не трекбол, а Magic Mouse или Magic Trackpad, я бы считал по-другому.

Маковские хоткеи.. О... Особенно в альтернативно одаренных программах вроде XCode. Вообще, разработчиков XCode после смерти в аду будут ждать какие-нибудь дешевые раздолбанные Chicony (нормальных old-school Mitsumi они не заслужили), на которых они должны будут перенабрать код XCode в XCode. И никаких мышей, не говоря уже про тачпады. Попробуйте переключиться на другой файл с клавиатуры. "Используй мышку, Люк".
Поведение Home/End/PgUp/PgDown -- не такое, как в Win/Linux. Think different.
Command, которая основная мета-клавиша, обычно забиндена на Windows key. После месяца-двух работы под OSX начинает болеть левая рука.
Ах да, будь у меня не эргономичная микрософтовская клава, а Apple Keyboard, я бы считал по-другому.

Неспешность. Как оказалось, я не один такой, у которого более-менее современный мак (i5, 4 GB DDR3 1600) тормозит при одновременно запущенных XCode и AppCode. Которые съедают ~500 Mb  и 1 Gb памяти соответственно. При этом free memory ~ 100-200 Mb, inactive memory ~ 500 Mb, но своп в 2-3 Gb присутсвует. Ах да, будь у меня больше памяти и SSD винт, я бы считал по-другому.

iTunes. Помню время, когда он был пусть и перегруженным комбайном, но еще вполне юзабельным. Я даже им пользовался под Windows. А сейчас... Можно поставить другой плейер, но чтобы iTunes не запускался по нажатии кнопки play на клавиатуре, нужно патчить или переименовывать бинарник одного из системных сервисов.

Objective-C. Попытка скрестить скорость C и ООП-идеологию SmallTalk. Язык, который был неплох на момент своего изобретения, но сейчас... Да, язык развивается, ручное управление памятью ушло в прошлое, уступив ARC, появились блоки ака замыкания. Только вот GC и блоки были в исходном Smalltalk-80.
Отдельно доставляет многословность языка. Когда пишешь (утрирую):
NSMutableArray * mutableArray = [NSMutableArray mutableArrayWithCapacity:...];
так и хочется откомментить: "DRY? Не, не слышал."
Ну, и имхо,
fs::path prefix = "/usr";
fs::path bin_prefix = prefix / "bin";
читабельнее, чем
NSString * prefix = @"usr";
NSString * bin_prefix = [prefix stringByAppendingPathComponent: @"bin"];

Когда в rss-ленте читаешь про хаскель, алгебру типов, зависимые типы, Agda/Coq/Идрис, монады там всякие и прочий матан, а потом пишешь код на слабо-типизированном языке, который местами даже "stringly-typed" --  где аналог LINQ выглядит примерно как ...
NSArray * expired = [tasks filteredArrayUsingPredicate:[NSPredicate predicateWithFormat:@"expirationDate < %@", [NSDate date]]];
Когда пишешь на динамическом языке без REPLа...
Когда в динамическом языке при некоторой доле невнимательности все же можно добиться SIGSEGV, таки разыменовав нулевой указатель...
Когда читаешь про transactional memory и минимизацию сайд-эффектов для распрараллеливания, а потом работаешь с обьектами, для которых не то что модифицировать, но даже читать(Привет, CoreData!) свойства в других потоках нельзя...
Это грустно.

---

Ах да, если бы меня покусал Стив Джобс, я бы считал по другому. :)

Справедливости ради, к плюсам OSX можно отнести
- наличие Unix окружения,
- предустановленные perl/python/ruby
- ненужность антивирусов

Achtung, minen! или Shell + Space = @#$&

Работа шелла с пробелами иногда ни разу не интуитивна.

Дано
$ cat count.sh
echo "$# : '$1' '$2' '$3'"
$ cat proxy.sh
./count.sh $@
Пробуем
$ ./count.sh 'a b' c
2 'a b' 'c'
$ ./proxy.sh 'a b' c
3 'a' 'b' 'c'

Теперь я знаю, как это лечится ("$@"), но чем думал автор, когда делал такое поведение?

libtool, мать его.

2012 год на дворе.
Космические корабли бороздят ...
А факин libtool до сих пор не умеет готовить пути с пробелами.
Ненависть!

Смайлики

цитато из Makefile

'^/\*' $< >$@

записки из генераторной

python-скрипт читает конфиг в ini-файле и создает файл, включаемый в Makefile.am.
Тот после обработки automake дает Makefile, который при make создает из XML-файлов .cpp и .h (через qdbusxml2cpp).
полученный h-файл обрабатывается moc, давая еще один .cpp.
Потом все это компилируется...

sh такой sh

Напоролся на интересное поведение в шелл-скрипте.
Изначально скрипт был под bash, но из-за портирования под одну обрезанную платформу переключились на sh.

$ false && echo WTF || echo ok
bash: ok
sh: ok

$ false > /dev/null && echo WTF || echo ok
bash: ok
sh: ok

$ false &> /dev/null && echo WTF || echo ok
bash: ok
sh: WTF

Лекарство:
$ false 1> /dev/null 2>&1 && echo WTF || echo ok
bash: ok
sh: ok

[trick] чтение из /dev/[u]random

Баг: генератор ключей выдает один и тот же ключ, если интервал между запусками достаточно мал.

Лезу в код, вижу примерно такое.

template <typename T>
RandomGenerator::RandomGenerator() {
  T seed = 0;
  {
    std::ifstream in("/dev/urandom");
    in >> seed;
  }
  if (!seed)
    seed = clock(NULL);
  ... // далее seed используется, чтобы инициализировать один из бустовских ГПСЧ.
}

Далее этот класс инстанциируется для T = uint32_t.
Первое, что бросается в глаза, что /dev/urandom мы открываем как текстовый файл. А потом пытаемся читать из него 4хбайтное целое.

Добавил ios::binary -- лучше не стало.

Вынес в отдельный файл, стал экспериментировать.
Не читается uint32 из '/dev/random'.
Поменял тип на char - читает.
На short - опять не читает.
И такое поведение одинаково на osx, linux и freebsd.

А потом я вспомнил, что /dev/[u]random - это character device.