Да когда при редактировании кода нужно перемещаться на 5 слов или выделять 3 абзаца? Мы оперируем функциями, классами, условиями, циклами, переменными
Во-первых: по определённым причинам, базовый Vim намеренно не умеет производить синтаксический анализ. Общеизвестно, что для языков вроде C++ это практически равносильно реализации компилятора C++ внутри редактора. Базовый Vim заточен на редактирование чисто текстовых объектов. В нём есть некоторые примитивные синтаксические текстовые объекты, например "блок кода между {}". Синтаксические текстовые объекты добавляются плагинами (пример — текстовый объект "аргумент ф-и").
Во-вторых: модальность настолько же важна, как и функции работы с текстовыми объектами. Это банально возможность перемещаться по коду (а также вызывать операции итд) одно-двухкнопочными действиями без частого нажания неэффективных и вредных модификаторов Ctrl, Alt итд. "Сделайте мне так, чтобы я скроллил экран 1 кнопкой не перемещая кистей". Забудьте про этот несчастный hjkl — избыточное использование движений на 1 символ это признак новичка в виме. Опытные вимеры двигаются пословно, поблочно, поиском, операцией jump to tag, прыжком в списке объектов с подтверждением и ещё десятком способов.
В-третьих: "оперируем функциями, классами, циклами..." — скажем так, разве что при рефакторинге, которого действительно в виме нет. А вот:
при "сыром" редактировании кода (raw editing) — даже в сверхсовременных IDE всё в итоге сводится или к банальному печатанию кода (сниппетами, для эстетов), или к чисто текстовой копи-пасте и правке (сомневаюсь, что в какой бы то ни было IDE есть целостная система команд для копи-пасты синтаксических объектов).
при навигации — Vim с плагинами много чего умеет (jump to def, нечёткий поиск по тегу, переход к файлу по нечёткому имени итд).
действительно ли это так хорошо для моих кистевых суставов длительно время пребывать в одной и той же позиции
Это совершенно нормально, и даже ускоряет процесс набора (travel distance становится меньше). Проблема малоподвижности ни при каком наборе не стоит, тк пальцы и руки всё равно совершают огромное кол-во мелких движений.
А вот постоянно зажатый Ctrl это как раз весьма вредно. Emacs — прекрасный редактор, но многих программистов он отправил к врачу с диагнозом RSI, того же Столлмана. Или модальное редактирование, или мышь, или зажимать Ctrl фалангой согнутого мизинца (известный в узких кругах лайфхак, снижающий нагрузку на мизинец).
Усталость глаз тоже не бывает от слепого набора, глаза постоянно совершают сканирующие движения даже если смотрят на одну и то же область дисплея (w: cаккада), ищите проблему в другом месте.
Тоже столкнулся с этим на Двораке. Понял, что нужно писать свою модальную раскладку. Год делал и до конца всё равно ещё далеко) Но пользоваться можно.
Сейчас пишу документацию на неё и пост на хабр, вот её кусок в нотации Vim:
┌─────┬───┬───┬───┬───┬───┰───┬───┬───┬───┬───┬───┬───┬─────┐
│ │ │ │ │ │ ┃ │ │ │ │ │ │ │ │
│ │ │ │ │ │ ┃ │ │ │ │ │ │ │ │
└─────┴───┴───┴───┴───┴───╂───┴───┴───┴───┴───┴───┴───┴─────┘
┌─────┲━━━┯━━━┯━━━┯━━━┱───╂───┲━━━┯━━━┯━━━┯━━━┱───┬───┬─────┐
│ << ┃ │ P │gE │ ? ┃ N ┃ ┃"_D│[[ │ Y │ D ┃ │ │ │
│ >> ┃ │ p │ B │ / ┃ n ┃ ┃"_d│ ↑ │ y │ d ┃ │ │ │
└─────┺━━━┷━━━┷━━━┷━━━┹───╂───┺━━━┷━━━┷━━━┷━━━┹───┴───┴─────┘
┌─────┲━━━┯━━━┯━━━┯━━━┱───╂───┲━━━┯━━━┯━━━┯━━━┱───┬─────────┐
│ ┃gg │ e │ │ E ┃ge ┃ ┃]] │ C │ │ G ┃ │ │
│ ┃ ^ │ w │:b │ W ┃b ┃ ← ┃ ↓ │ c │ → │ $ ┃ │ │
└─────┺━━━┷━━━┷━━━┷━━━┹───╂───┺━━━┷━━━┷━━━┷━━━┹───┴─────────┘
┌─────┲━━━┯━━━┯━━━┯━━━┱───╂───┲━━━┯━━━┯━━━┯━━━┱─────────────┐
│ ┃ R │ │ │ ┃ ┃ U ┃ a │ v │ J │ ┃ │
│ ┃ r │ │ i │:w ┃ x ┃ u ┃ A │ V │ . │ ┃ │
└─────┺━━━┷━━━┷━━━┷━━━┹───┸───┺━━━┷━━━┷━━━┷━━━┹─────────────┘
┌─────┬─────┬─────┬───────────────────────┬─────┬─────┬─────┐
│ │ │ │ │ │ │ │
└─────┴─────┴─────┴───────────────────────┴─────┴─────┴─────┘
На пустых местах тоже есть некие команды, я их сейчас не привожу.
Принцип примерно как у дворака (упор на перемещение самых частых команд на более удобные позиции, и на смену рук, например cw делается со сменой рук) и также как у Colemak (упор на finger rolls, например переход в <V> и движение вниз — это частая биграмма, начинающая выделение блока, — делается finger-roll'ом). Также вместо hjkl был сделан выбор в пользу hjil (в терминах QWERTY), из-за большей эргономичности вертикальных движений по ij вместо kj.
И она позиционная, т.е. команды привязаны к позициям, просто в разных раскладках будет привязка к разным буквам. (Исключениями являются скобки, тк к ним привязаны движения на открывающую/закрывающую скобку, а в разных раскладках расположение скобок разное). Её можно использовать и на QWERTY и на Двораке и на чём угодно.
Встречал другие позиционные модальные раскладки, но к сожалению не сохранил ссылки.
Способ, которым Vim назначает биндинги в <N>, за исключением hjkl и некоторых других команд, является фонетическим (как вариант, мнемоническим), а не семантическим. [C]hange [w]ord и т.д. Семантический способ как раз у вас: вы назначаете той же C семантику "копирования", единообразно с Ctrl+C, и так далее.
Очень правильная идея в основе (перегруппировка клавиш операций по удобству/лёгкости доступа, а не по названию операции), но реализация делает слишком много допущений о приложении, например что ^backspace удаляет слово. По факту всё заточено под 1 редактор.
PS: на иллюстрации с раскладкой 2 раза PgUp и нет PgDn, видимо опечатка? И что-то странное с действиями на hjkl, не консистентно с вимом, хотя мб так и предполагалось. В тч движение влево на J = самое редкое из 4 базовых движений на самой ценной клавише на клавиатуре наряду с пробелом.
Интересно, во многом согласен. Тоже сижу на альт. раскладке, самодельном форке Дворака, точнее форке Programmer Dvorak. Решил уйти с QWERTY и со стандартной модальной "вимовской" раскладки, когда обнаружил у себя RSI и большое кол-во "трудных" клавиш в топе по частоте (^ $ ~ :w // {}). Переход тоже сломал мне все хоткеи в модальном редакторе (Emacs+Evil) и в приложениях, но модальная раскладка, которая выросла на обломках, в сумме с Двораком избавила меня от RSI.
(PS: почему Ctrl+C на иллюстрации закрашен красным, C в двораке жмётся средним пальцем, в чём проблема? Клавиша дб белой. Ctrl+S дб наоборот красным а не зелёным — задействован мизинец. Вообще странно что "немного неудобно" = зелёный. Зелёный ассоциируется у всех с "OK", для "немного неудобно" лучше жёлтый.)
Как-то приелись мотивашки по расту и статьи со введением в Rust, их уже наштамповали мильён, а вот материалов более высокого уровня наоборот не хватает, из стандартных только rust reference и nomicon.
Вопрос не совсем корректен, тк не относится конкретно к расту. Rust генерирует бинарники в формате целевой платформы, например ELF на линуксе, и этот бинарник обычным образом вызывает код из динамической библиотеки, через Posix С ABI. То же произойдёт если бинарник написан на си или на плюсах. ЕМНИП первый вызов будет более медленный (оверхед на поиск функции в таблице PLT), остальные быстрее.
Так что вопрос здесь "скорость вызова DLL в C# и в компилируемых языках". Не знаю правильный ответ на этот вопрос, интуитивно кажется что компилируемые языки делают вызов из DLL быстрее. Но вот обратный пример с luajit. Там есть ссылка на проект на гитхабе с бенчмарками различных языков при вызове .so кода, шарп там медленнее компилируемых языков. Короче всё зависит от механизма вызова.
Компания вызвала "тяжелую юридическую артиллерию" и подала апелляцию, указав в 59-страничном документе
Вот это самая жесть в новости. Компании обычно не ведут себя в таких ситуациях как истерички. Национальный менталитет здесь что ли сказался… Обычно у корпораций подход к решению таких проблем очень прост — выбирается тот способ, который дешевле обходится. Могли бы вернуть эти несчастные деньги по решению суда и ещё записать себе "психологическую" победу, тк с их стороны потеря была бы 42 евро, а со стороны оппонента — уже немаленький на тот момент расход сил, времени и денег на организацию возврата. Притом могли бы прикинуть — если пойдём в суд и проиграем, этот юзер во всех СМИ расскажет что нас прогнул, а если выиграем, то что? Можем демонстративно заявлять в СМИ, что пытаться вернуть у нас деньги за windows — гиблое дело? Business value выигрыша просто в небеса уходит))
PS: Луке респект за упёртость, но для втыкания линукса на этот ideapad после того, как отпразднует выигрыш, ему упёртости потребуется вдвое больше. Я купил ту же модель в ~2015 и ставил на него Debian с Gnome 3, благо это планшет x86, а не ARM. Формально система поставилась и работала, но не функционировала куча всего, энергосбережение, wi-fi, криво работал тач. Ядро ставил свежайшее собранное с гита. На счастье, в планшете обнаружилась хардверная неисправность и я его с облегчением сдал в магазин обратно.
Результат скорее удручающий. Решать (не распознавать) дифуры нейронкой — это признание поражения в задаче формализации приёмов решения дифуров в виде правил для символьного (формального) вывода. Имеются в виду правила не для символьных математических преобразований вида "сокращение на константу" — это объект статьи умеет делать иначе бы не умел строить цепочку вывода — а именно для выбора правил на шагах преобразования. Рандом (нейросеть) для выбора правил — это так, рабоче-крестьянская эвристика.
В свете этого не понятны 2 вещи в статье: во-первых с каких пор солверы меряются скоростью, а не возможностями вывода и формальной модели, и во-вторых что значит "достигает точности в 85%" — символьные солверы же выдают аналитическое решение? Или это процент решённых задач?
И повторюсь, в статье зачем-то смешивается задача распознавания, задача парсинга, и задача формального вывода
script / scriptreplay существуют в юниксах с 1980-х. :)
Крутой инструмент, к сожалению малоизвестный, и файлы записи в общем случае не переносимы между терминалами. Основной плюс — идеальное изображение и шрифт при проигрывании, не достижимые никаким FullHD скринкастом, тк scriptreplay / asciinema это не запись экрана, а вывод обычного текста на терминал, с родным шрифтом, сглаживанием ит.д.
Есть важный дополнительный инструмент к этим рекордерам, не упомянутый в статье, — кодировщик в gif или видеофайл (congif, etc).
Так как у меня не было доступа к исходному коду explorer.exe
скачивал файлы символов с серверов символов Microsoft
Если вы не в Windows, то сильно вам сочувствую (жаль, что отладка и профилирование, особенно проблем на машинах других пользователей, для вас гораздо сложнее)
… Сказал человек, вынужденный тыкаться как слепой котёнок без исходников explorer.exe и качать дебаг символы, милостиво предоставленные серверами MS. Ну-ну. Если я "не в Windows", то у меня есть -dbg пакеты дистрибутива, ручная линковка с индивидуальными отладочными либами (оффлайн, а не какими-то там серверами символов), подмена любых символов на ходу (LD_PRELOAD / ручная замена), трассировка любых вызовов вплоть до сисколлов (perf, bpf) с кучей статистики из коробки, удалённая отладка через gdb (с поддержкой в IDE), ну и разумеется исходники на весь стек от ядра до чего там у юзера вызывается (если у него не закрытый софт ест-но).
Я не вижу противоречия в своём комменте. Отношений "я тебе плачу X ты делаешь работу Y" и "посещение мной магазина накладывает на персонал обязанность выполнить для меня регламентированную работу по уборке/пробиванию товаров" здесь нет. Покупатель оказывает магазину мелкую услугу, не имеющую формального выражения в денежном эквивалента, но эффект от её оказания влияет на финансы магазина.
Уборка подноса это в первую очередь правило хорошего тона, а не какое-то выполнение работы за другого человека, как вы похоже считаете. Нет вообще никакой "работы кассира" и "работы уборщика" в значении регламентированного списка обязанностей перед клиентом.
IKEA я не просто так вспомнил, тк там в пунктах питания вывешивают явное обращение к покупателям убирать подносы, с объяснением что это позволит сократить издержки на персонал и в итоге повысить качество услуг. Та же логика с кассами самообслуживания в пятёрке — клиент за действие, требующее от него минимального усилия, может довольно существенно снизить нагрузку на персонал, если все повторят его подход. Поэтому я и пользуюсь автоматическими кассами в 5ке и убираю поднос в икее
Во-первых: по определённым причинам, базовый Vim намеренно не умеет производить синтаксический анализ. Общеизвестно, что для языков вроде C++ это практически равносильно реализации компилятора C++ внутри редактора. Базовый Vim заточен на редактирование чисто текстовых объектов. В нём есть некоторые примитивные синтаксические текстовые объекты, например "блок кода между {}". Синтаксические текстовые объекты добавляются плагинами (пример — текстовый объект "аргумент ф-и").
Во-вторых: модальность настолько же важна, как и функции работы с текстовыми объектами. Это банально возможность перемещаться по коду (а также вызывать операции итд) одно-двухкнопочными действиями без частого нажания неэффективных и вредных модификаторов Ctrl, Alt итд. "Сделайте мне так, чтобы я скроллил экран 1 кнопкой не перемещая кистей". Забудьте про этот несчастный hjkl — избыточное использование движений на 1 символ это признак новичка в виме. Опытные вимеры двигаются пословно, поблочно, поиском, операцией jump to tag, прыжком в списке объектов с подтверждением и ещё десятком способов.
В-третьих: "оперируем функциями, классами, циклами..." — скажем так, разве что при рефакторинге, которого действительно в виме нет. А вот:
при "сыром" редактировании кода (raw editing) — даже в сверхсовременных IDE всё в итоге сводится или к банальному печатанию кода (сниппетами, для эстетов), или к чисто текстовой копи-пасте и правке (сомневаюсь, что в какой бы то ни было IDE есть целостная система команд для копи-пасты синтаксических объектов).
при навигации — Vim с плагинами много чего умеет (jump to def, нечёткий поиск по тегу, переход к файлу по нечёткому имени итд).
Что-то слышал про это, но не представляю, как такое проделать на клавиатурах с коротким ходом, где Ctrl почти не выступает.
Это совершенно нормально, и даже ускоряет процесс набора (travel distance становится меньше). Проблема малоподвижности ни при каком наборе не стоит, тк пальцы и руки всё равно совершают огромное кол-во мелких движений.
А вот постоянно зажатый Ctrl это как раз весьма вредно. Emacs — прекрасный редактор, но многих программистов он отправил к врачу с диагнозом RSI, того же Столлмана. Или модальное редактирование, или мышь, или зажимать Ctrl фалангой согнутого мизинца (известный в узких кругах лайфхак, снижающий нагрузку на мизинец).
Усталость глаз тоже не бывает от слепого набора, глаза постоянно совершают сканирующие движения даже если смотрят на одну и то же область дисплея (w: cаккада), ищите проблему в другом месте.
Тоже столкнулся с этим на Двораке. Понял, что нужно писать свою модальную раскладку. Год делал и до конца всё равно ещё далеко) Но пользоваться можно.
Сейчас пишу документацию на неё и пост на хабр, вот её кусок в нотации Vim:
На пустых местах тоже есть некие команды, я их сейчас не привожу.
Принцип примерно как у дворака (упор на перемещение самых частых команд на более удобные позиции, и на смену рук, например cw делается со сменой рук) и также как у Colemak (упор на finger rolls, например переход в <V> и движение вниз — это частая биграмма, начинающая выделение блока, — делается finger-roll'ом). Также вместо hjkl был сделан выбор в пользу hjil (в терминах QWERTY), из-за большей эргономичности вертикальных движений по ij вместо kj.
И она позиционная, т.е. команды привязаны к позициям, просто в разных раскладках будет привязка к разным буквам. (Исключениями являются скобки, тк к ним привязаны движения на открывающую/закрывающую скобку, а в разных раскладках расположение скобок разное). Её можно использовать и на QWERTY и на Двораке и на чём угодно.
Встречал другие позиционные модальные раскладки, но к сожалению не сохранил ссылки.
Так что проблема разрешимая.
А зачем вам ассемблерный вывод, заставили бы copy ctor и move ctor писать что-нибудь в cout, и всё, не надо дизассемблировать.
Upd: формально, не нашёл вашей ситуации в стандарте. Так что я так понимаю стандарт здесь не даёт никаких гарантий по copy elision.
Способ, которым Vim назначает биндинги в <N>, за исключением hjkl и некоторых других команд, является фонетическим (как вариант, мнемоническим), а не семантическим. [C]hange [w]ord и т.д. Семантический способ как раз у вас: вы назначаете той же C семантику "копирования", единообразно с Ctrl+C, и так далее.
Очень правильная идея в основе (перегруппировка клавиш операций по удобству/лёгкости доступа, а не по названию операции), но реализация делает слишком много допущений о приложении, например что ^backspace удаляет слово. По факту всё заточено под 1 редактор.
PS: на иллюстрации с раскладкой 2 раза PgUp и нет PgDn, видимо опечатка? И что-то странное с действиями на hjkl, не консистентно с вимом, хотя мб так и предполагалось. В тч движение влево на J = самое редкое из 4 базовых движений на самой ценной клавише на клавиатуре наряду с пробелом.
Интересно, во многом согласен. Тоже сижу на альт. раскладке, самодельном форке Дворака, точнее форке Programmer Dvorak. Решил уйти с QWERTY и со стандартной модальной "вимовской" раскладки, когда обнаружил у себя RSI и большое кол-во "трудных" клавиш в топе по частоте (^ $ ~ :w // {}). Переход тоже сломал мне все хоткеи в модальном редакторе (Emacs+Evil) и в приложениях, но модальная раскладка, которая выросла на обломках, в сумме с Двораком избавила меня от RSI.
(PS: почему Ctrl+C на иллюстрации закрашен красным, C в двораке жмётся средним пальцем, в чём проблема? Клавиша дб белой. Ctrl+S дб наоборот красным а не зелёным — задействован мизинец. Вообще странно что "немного неудобно" = зелёный. Зелёный ассоциируется у всех с "OK", для "немного неудобно" лучше жёлтый.)
Вроде не первое апреля? Вы переизобрели шелл, включая bind/bindkey, restricted shell и т.д.
Как-то приелись мотивашки по расту и статьи со введением в Rust, их уже наштамповали мильён, а вот материалов более высокого уровня наоборот не хватает, из стандартных только rust reference и nomicon.
Вопрос не совсем корректен, тк не относится конкретно к расту. Rust генерирует бинарники в формате целевой платформы, например ELF на линуксе, и этот бинарник обычным образом вызывает код из динамической библиотеки, через Posix С ABI. То же произойдёт если бинарник написан на си или на плюсах. ЕМНИП первый вызов будет более медленный (оверхед на поиск функции в таблице PLT), остальные быстрее.
Так что вопрос здесь "скорость вызова DLL в C# и в компилируемых языках". Не знаю правильный ответ на этот вопрос, интуитивно кажется что компилируемые языки делают вызов из DLL быстрее. Но вот обратный пример с luajit. Там есть ссылка на проект на гитхабе с бенчмарками различных языков при вызове .so кода, шарп там медленнее компилируемых языков. Короче всё зависит от механизма вызова.
Вот это самая жесть в новости. Компании обычно не ведут себя в таких ситуациях как истерички. Национальный менталитет здесь что ли сказался… Обычно у корпораций подход к решению таких проблем очень прост — выбирается тот способ, который дешевле обходится. Могли бы вернуть эти несчастные деньги по решению суда и ещё записать себе "психологическую" победу, тк с их стороны потеря была бы 42 евро, а со стороны оппонента — уже немаленький на тот момент расход сил, времени и денег на организацию возврата. Притом могли бы прикинуть — если пойдём в суд и проиграем, этот юзер во всех СМИ расскажет что нас прогнул, а если выиграем, то что? Можем демонстративно заявлять в СМИ, что пытаться вернуть у нас деньги за windows — гиблое дело? Business value выигрыша просто в небеса уходит))
PS: Луке респект за упёртость, но для втыкания линукса на этот ideapad после того, как отпразднует выигрыш, ему упёртости потребуется вдвое больше. Я купил ту же модель в ~2015 и ставил на него Debian с Gnome 3, благо это планшет x86, а не ARM. Формально система поставилась и работала, но не функционировала куча всего, энергосбережение, wi-fi, криво работал тач. Ядро ставил свежайшее собранное с гита. На счастье, в планшете обнаружилась хардверная неисправность и я его с облегчением сдал в магазин обратно.
Результат скорее удручающий. Решать (не распознавать) дифуры нейронкой — это признание поражения в задаче формализации приёмов решения дифуров в виде правил для символьного (формального) вывода. Имеются в виду правила не для символьных математических преобразований вида "сокращение на константу" — это объект статьи умеет делать иначе бы не умел строить цепочку вывода — а именно для выбора правил на шагах преобразования. Рандом (нейросеть) для выбора правил — это так, рабоче-крестьянская эвристика.
В свете этого не понятны 2 вещи в статье: во-первых с каких пор солверы меряются скоростью, а не возможностями вывода и формальной модели, и во-вторых что значит "достигает точности в 85%" — символьные солверы же выдают аналитическое решение? Или это процент решённых задач?
И повторюсь, в статье зачем-то смешивается задача распознавания, задача парсинга, и задача формального вывода
script / scriptreplay существуют в юниксах с 1980-х. :)
Крутой инструмент, к сожалению малоизвестный, и файлы записи в общем случае не переносимы между терминалами. Основной плюс — идеальное изображение и шрифт при проигрывании, не достижимые никаким FullHD скринкастом, тк scriptreplay / asciinema это не запись экрана, а вывод обычного текста на терминал, с родным шрифтом, сглаживанием ит.д.
Есть важный дополнительный инструмент к этим рекордерам, не упомянутый в статье, — кодировщик в gif или видеофайл (congif, etc).
… Сказал человек, вынужденный тыкаться как слепой котёнок без исходников explorer.exe и качать дебаг символы, милостиво предоставленные серверами MS. Ну-ну. Если я "не в Windows", то у меня есть -dbg пакеты дистрибутива, ручная линковка с индивидуальными отладочными либами (оффлайн, а не какими-то там серверами символов), подмена любых символов на ходу (LD_PRELOAD / ручная замена), трассировка любых вызовов вплоть до сисколлов (perf, bpf) с кучей статистики из коробки, удалённая отладка через gdb (с поддержкой в IDE), ну и разумеется исходники на весь стек от ядра до чего там у юзера вызывается (если у него не закрытый софт ест-но).
Странно, что в статье, ориентированной на прочтение падающим человеком, в начале нет краткой выжимки по пунктам. :)
А то чёт не успеваю всю статью в полёте дочита
Я не вижу противоречия в своём комменте. Отношений "я тебе плачу X ты делаешь работу Y" и "посещение мной магазина накладывает на персонал обязанность выполнить для меня регламентированную работу по уборке/пробиванию товаров" здесь нет. Покупатель оказывает магазину мелкую услугу, не имеющую формального выражения в денежном эквивалента, но эффект от её оказания влияет на финансы магазина.
Конечно иначе.
Уборка подноса это в первую очередь правило хорошего тона, а не какое-то выполнение работы за другого человека, как вы похоже считаете. Нет вообще никакой "работы кассира" и "работы уборщика" в значении регламентированного списка обязанностей перед клиентом.
IKEA я не просто так вспомнил, тк там в пунктах питания вывешивают явное обращение к покупателям убирать подносы, с объяснением что это позволит сократить издержки на персонал и в итоге повысить качество услуг. Та же логика с кассами самообслуживания в пятёрке — клиент за действие, требующее от него минимального усилия, может довольно существенно снизить нагрузку на персонал, если все повторят его подход. Поэтому я и пользуюсь автоматическими кассами в 5ке и убираю поднос в икее
А человек, убирающий свой поднос в столовой IKEA после еды, бесплатно работает за уборщика?
Мы не разрешаем ставить банковское мобильное приложение на рутованное устройство, потому что это небезопасно, говорили они.
пока что вы тут единственный, кто не соблюдает правила приличия.