Пытаюсь что-нибудь с главной (all, популярное, фотки) сделать.
Занимать левую колонку своей собственной персоной на этих страницах не правильно.
В процессе (ещё не в результате) размышлений получилась такая штука (скриншот).

Вопрос — достаточно ли, если логотип будет вести на all, и в популярное или фотки можно будет попасть только оттуда?

Если делать так, то в шапке образуется достаточно много свободного места. Туда добавится пункт "Уведомления" (когда будет готов). Можно ещё что-нибудь из под аватарки вытащить (PM?). Единственное, что меня смущает — поиск. Хочется его в левую колонку перенести, т.к. он не относится к персональным страницам. Но это плохо, если доступа к поиску не будет с любой страницы.
Заголовок непосредственно под логотипом — странно выглядит. Надо бы логотип в середину переставить. Но тогда слева на данный момент остаётся только Post. в перспективе Notifications, Post и то, что вытащено из меню. Часть персональных ссылок в левом углу, другая часть — в правом, под аватаркой. В центре и справа — логотип (all) и поиск, не относящиеся к персональной навигации...


И второй вопрос — чем ещё дополнить левую колонку в all. У меня есть одна идея — для разлогиненных там одобренный партией список тегов, а для себя можно показывать те теги, на которые подписан. Пока идеи закончились, поэтому выслушаю предложения.

Ещё раз.
Вёрстка жуйка в расчёте на экраны любых размеров.
Проверьте кто на чём может.
тред, залогинен
лента, разлогинен

Вчерашний пост прошёл практически незамеченным.
Но я тут ещё немного дополировал. (Подкрутил тень под меню, чтобы "не так сильно сливалась". При схлопывании меню в одну колонку, нельзя ставить поиск вниз — он скрывается за клавиатурой. Схлопывание в одну колонку происходило раньше, чем нужно. У незалогиненного пользователя нет аватарки, только шеврон.)

Если проблем с этой вёрсткой нет, то могу толкнуть коммит.

wip responsive layout
Задача — сделать шапку и левую колонку юзабельными на экранах любого размера.

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

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

proof of concept доработанной вёрстки

* меню сворачивается при w < 620px;
* левая колонка на flexbox, убирается вниз при w < 1000px (теоретически, можно сделать открывающийся сайдбар, но тогда надо и меню и левую колонку в один гамбургер как-то пихать... пока не вижу, как их совместить);
* несколько доработок в форме ввода сообщений (попробуйте приаттачить картинку).

В код лучше не смотреть.

Related to #2857024

Редактирование постов/комментов как коммент-патч.
В списке комментов отображается как "@username изменил #пост (или /коммент)". (Как именно — тут уточнять не обязательно, лучше у изменённого поста историю с дифами через меню давать возможность открыть, если хочется. А в рассылку имеет смысл прислать полностью.)

Соответственно, будет видно, что те, кто выше — отвечали до правки, те кто ниже — после. Правда, с деревом всё сложнее. Там пометку какую-нибудь делать, что отвечали не на последнюю версию? Или строить дерево так, что новые комменты растут не от изменённого поста/коммента, а от соответствующего "патча".

Наверное, при получении правки стоит проверять количество изменений — если опечатка исправлена, то это не нужно. (Критерий мелкого исправления — в пределах N часов после отправки исходного сообщения и M байт различий.)

Внезапно, сегодняшние баги натолкнули на мысль.

Если пост или коммент #А ссылается на пост #Б, то сейчас:
* в А есть кликабельная ссылка на Б;
* можно встроить пост Б в А.

Хочется ещё, чтобы работало и в обратную сторону:
* В треде Б появляется А в виде полноценного коммента (ветка дублируется как тред А и часть треда Б), ну или хотя бы как упоминание, как в issue-трекерах.

В некотором роде это более мощная штука, чем рекомендация поста с комментарием!

Реализовать в полном виде можно будет, скорее всего, только после рефакторинга, когда посты и комменты станут одного класса сущностями.

Аккаунт Juick должен идти в нагрузку (автоматом создаваться) к каждому новому аккаунту на jabber.ru.
Как "микроблог" qip (когда-то) и как G+ (всегда).

Нужно извлекать выгоду из связей.

(Я уже говорил, что на jabber.ru даже ссылки нет на Juick?)

Сейчас, если спамер заявился в удачное время, его посты могут провисеть целый день до того момента, как придёт лесник @vt.

Я предлагаю ввести команду report @username.
Если пользователь новый и поступили репорты от N юзеров, то его посты скрывать из ленты до выяснения.

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

Жуик, привет! Ты не спишь? Давай поболтаем о кунах, тянах, отношениях, кольцах, предложениях, свадьбах, детях и т. п. Ты этого хочешь? У тебя это уже есть? У тебя это будет? Или тебе этого не надо?

Что мне не нравится в Linux?

1. Полностью незащищённое ядро от самого себя. Любая ошибка при работе с памятью в одном модуле может порушить всю систему (а ошибки такого рода всё равно будут существовать, т.к. ядро написано на небезопасном языке, компиляторы которого не могут проверять программу достаточно хорошо). ИМХО нельзя считать такой выбор удачным решением проблемы производительности микроядерных систем — можно было бы и в отдельные сегменты положить код и данные тех модулей, которые мало (или вообще не) взаимодействуют друг с другом. А ведь последнее время чего только не запихнут в ядро.

2. Текстовые интерфейсы (через open/close/read/write/...) для всего. Реализация этой идеи обладает двумя недостатками: она недостаточна хороша по сравнению с другими универсальными интерфейсами (например, из-за производительности) и одновременно не доведена в Linux до завершения. Например, пусть программе нужно считать ARP-таблицу и взять оттуда MAC-адрес для хоста с IP 1.2.3.4. а потом подключиться к хосту с MAC-адресом 00:11:22:33:44:55 и передать ему этот адрес через какой-нибудь протокол. Для этого ей придётся открыть "текстовый файл" в procfs, прочитать его в память, распарсить его, перевести в своё внутреннее представление. Текстовая информация удобна для человека, но неудобна для программ — везде будут происходить двойные преобразования. Почему бы не преобразовывать информацию в текст только в момент вывода её на экран? Но ведь это не единственный вид интерфейса с ядром — есть ещё ioctl, который уж никак не текстовый (например для cmd = TCGETS, CDROMPLAYMSF, ...). А ещё есть всякие bind/connect/stat/..., которые тоже совсем не текстовые. Но ведь идея полностью текстового интерфейса вполне реализуема (например в Plan 9). Точно так же, как и идея полностью нетекстового (объектно-ориентированные ОС).

3. У (non-root) пользователя нет возможности сделать так, чтобы его окружение выглядело так, как ему хочется. Он не может монтировать fs в свои директории, не может менять корень (chroot), не может менять некоторые настройки только для себя (hostname, создавать сетевые интерфейсы, создавать пользователей, менять настройки файрвола, системное время, ...). Всё это может быть полезным для отладки, изоляции и адаптации приложений.

4. Непрерываемые системные вызовы. Если процесс повис во время выполнения системного вызова, то его нельзя убить. kill -9 не работает.

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

Жуик, а ты задумывался/лась, что останется после тебя, когда тебя уже не станет? Будут ли о тебе помнить? Почему? По чему? А хочется ли, чтобы помнили?