Вот в телеграмме есть broadcast каналы, а есть какие-нибудь хорошие автоматизированные решения для feedback-а? А то может туда проще чем в жуйки писать, но без обратной связи это ж бесполезно

вот будет новый ноут, что туда ставить:
* nixos
* gentoo
* qubes-os
* какое ещё извращение (например gentoo+nix для бинарных юзеропакетов)

Gentoo существенно расширяемее и контролируемее nixos. В nixos хоть все эти derivations пишутся вроде и просто, но как-то желания учить их странный язык и писать совсем нет, в отличии от ебилдов, с которыми проще.
В общем с nixos всегда когда хочется чего-то странного я в итоге забивал и использовал дефолт, даже с latex, которому кастомизация точно нужна.
При этом с gentoo нужно обновляться часто и следить за всякими мелочами, т.к. иначе я умудряюсь закинуть систему в неконсистентное состояние, в котором все работает, но для обновления нужно 15 прыжков сделать. Сейчас частично порешал это использованием genoo+nix и всякий мусор собираю nix, а основу системы и полезные вещи и требующие кастомизации через gentoo.

При этом раз уж такие дела, то можно поиграться с чем-то новым, например, посмотреть qubes-os, тем более, что там, как я понимаю, usecase — templates VM распространен, поэтому можно собрать образ для работы.

Про требования:
* а никаких нет, мне фишек от дистра почти не надо
* большая часть работы все равно по mosh и VM
* возможность пускать nix очень желательно, т.к. разные проекты его используют
* желательна возможность использовать xmonad вместо менеджера окон
* DE не обязательна, но если можно прикрутить фишки и интеграции dm, через cli или простой интерфейс то было бы круто

Ну и да, мне на самом деле будет лень разбираться со всеми технологиями подробно, т.к. для работы мне достаточно tmux, mosh, vim (без конфигов), virtualbox, chrome браузера с плагинами для hangout, ghc (с возможностью разумно собирать любые версии в т.ч. HEAD) и без каких-либо кастомизаций вообще.

а чего-там у нас хорошего в мире ноутбуков сейчас, из хотелось:

1. 16+Gb памяти, желательно расширяемого до 32
2. видяшка пофиг какая
3. разрешение от 1680x1050 (или близкого)
4. 14''+
5. если с тачскрином, то круто
6. если достаточно крепкий, чтобы неаккуратный человек типа меня не раздолбал его
7. вес не имеет никакого значения
8. батарею хотелось бы хорошую, но значение не имеет
9. из всяких бонусов можно TPM, и прочие интеловые штуки на поиграться, но тоже не очень важно.
10. на ноуте будет linux, так же железо желательно чтобы поддерживалось
11. ???
12. Profit

?

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

В последнем второтеге полвыпуска обсуждали как привлечь программистов в хаскель, а то чо-то он непопулярен. Но несколько выпупсков назад у них уже был человек, который искал себе хаскельщика и в общем как оказалось найти не проблема. То есть никакого недостатка программистов знающих хаскель и желающих на нём писать нет. В чём есть недостаток — в количестве контор которые хотят его использовать. Это и надо фиксить, а не гоняться за мифическими васями, которые вот уже сейчас начнут писать на хаскеле, но не могут этого делать потому что для него нет IDE (или что там они думали для этого надо), а если ему дать IDE так он уже завтра будет монады кляпать.

*erlang *haskell *ктонановенького

Стандартная банковская задача. Предыстория будет отдельным постом. Интересно как можно решить подобную задачу с использованием стат. типизации. Чтобы был контроль компилятором, не надо было полагаться на 100500 тестов, чтобы проверить, что определенные ветки не выполняются и т.п.

Есть модуль X, реализующий API-вызов «изменить сумму заказа».

Заказ
— может быть отправлен или неотправлен
— может быть предоплачен или не предоплачен
— может быть помечен, как несущий риск, или не помечен
(и т.п., см. по ходу пьесы)

Заказ — это сущность, получаемая из базы данных c уже готовыми свойствами. То есть нет последовательности вызовово create_order->risk_check->....->change_sum. Когда-то кем-то где-то был создан заказ. Через две недели мы получили API-вызов, который требует изменить сумму в этом заказе.

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

Конечно, в конце концов интересут решение Шага 3. Но интересно увидеть и весь процесс Шаг 1 -> Шаг 2 -> Шаг 3

Шаг 1

— если заказ неотправлен и непредоплачен, сумму можно увеличивать и уменьшать

— если заказ отправлен, сумму нельзя увеличивать, можно уменьшать

— если сумма увеличивается, мы должны провести risk check. если risk check не проходит, товар никак не помечается, но изменение суммы не проходит

— если товар помечен, как risk, то изменять сумму нельзя


Шаг 2

Потом оказалось, что не, так нельзя, поэтому внеслись изменения.

Изменение суммы:

Все то же самое, что и в первой задаче, только:

— увеличивать можно на max(фиксированная сумма1, процент1 от оригинальной суммы заказа)

— уменьшать можно на max(фиксированная сумма2, процент2 от оригинальной суммы заказа),
где сумма1, сумма2, процент1, процент2 — это конфигурация, считываемая из базы данных

Если изменение не попадает в эти рамки, то увеличить/уменьшить нельзя

Шаг 3

И этого оказалось недостаточно

Все то же самое, что и в шаге 2. Дополнительно:

— если заказ предоплачен (неважно, отправлен или нет), можно увеличивать сумму, если это разрешено конфигурацией магазина. Сумма, на которую можно увеличивать высчитывается, как в шаге 2

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

— если заказ предоплачен, отправлен, и сумма увеличивается, надо сделать auth-запрос в банк на разницу в сумме, а потом сделать capture запрос на всю сумму. Если хоть один из них не срабатывает, увеличить нельзя.

Написал письмо в «Юлмарт» с просьбой прокомментировать, как их предложение вскрывать посылки соотносится с Конституцией РФ:

«Здравствуйте. Я являюсь клиентом компании «Юлмарт». Также я получаю товары почтой из Китая. Я прошу прокомментировать ситуацию, описанную в статье kommersant.ru . Я считаю, что деятельность вашей компании в составе АКИТ направлена на ущемление моей свободы и тайны переписки, и на нарушение Конституции РФ: статей 2, 7/1, 8/2, 17, 18, особенно статей 23/1, 23/2, 24/1, 34/1 и 34/2. Прошу прокомментировать данную ситуацию. Оставляю за собой право публикации и иного использования нашей переписки.»

Есть где почитать, какие результаты вычислений хаскель кеширует, а какие нет? А то возникают дурацкие вопросы типа "будет ли каждый раз создаваться новый thunk в instance Foo Bar where foo _ = show (sin 0)" и т.п., хотелось бы прояснить для себя картину или хотя бы найти способ проверять такие вещи самому.