> Мне нужен был мощный консольный редактор. Я пользовался vim
> нельзя просто так взять и начать пользоваться emacs без недели изучения
Как будто vim освоить быстрее) Ну на пару вечеров быстрее чем emacs, ок. На уровне блокнота emacs учится за вечер (и уже можно брать и писать код), за неделю учатся базовые функции и плагины (справка, dired, helm, org, magit, в общем по желанию). А вот после этого что в Vim, что в Emacs изучение фич может идти годами параллельно с использованием, и постоянно будут открываться новые возможности, сколько бы времени ни потратить — этим процесс и увлекателен.
Кстати, в Emacs есть режим эмуляции Vim под названием evil-mode, подходит не только свитчерам с vi/vim, но и просто кому угодно для заимствования от Vim скорости редактирования.
> Или надо тупо вызубрить 100500 команд, а только потом приниматься за редактирование?
Ничего зубрить не надо, выучил команды info, where-is, describe-key и базовые клавиши, и вперёд редактировать текст.
На машинах с UEFI от загрузчика (Grub, lilo/elilo...) можно отказаться вообще, его роль способен выполнить сам UEFI (в случае линукса). См. «EFI stub».
Таких, чтобы производитель заявлял «работает под линуксом!», — пока не видел.
По факту запускать Linux можно пробовать на любом x86 планшете, дальше как повезёт — где-то заработает, где-то будут проблемы с железом (как правило, второе).
Из того, что я видел вживую:
Microsoft Surface Pro 3 — практически полноценно работает под Debian, за исключением пары хардварных кнопок;
Lenovo Thinkpad Tablet 8 и Tablet 10 — формально работает (Debian стартует), но реально работать невозможно, поддержка железа ужасна — wifi не видит, звукового устройства не видит, поддержку накопителя (eMMC) только недавно реализовали (4.1 или 4.2).
Статью стоило бы назвать «Можно ли заниматься веб-разработкой на iPad», а не «Можно ли заниматься разработкой на планшете».
Потому что если брать другие виды разработки и другие планшеты/ОС, то например моя практика даёт такие ответы:
«Можно ли заниматься разработкой десктопных приложений на x86 планшете с Win7/8?» — «Да, можно, при подключении клавиатуры и дисплея это тот же стационарный ПК с Win7/8 с тем же самом набором IDE и средств разработки. Единственная проблема — производительность».
«Можно ли заниматься разработкой десктопных приложений на x86 планшете с Linux?» — «Да, можно, при подключении клавиатуры и дисплея это тот же стационарный ПК с линуксом и с тем же самым набором IDE и средств разработки. Проблем две — поддержка железа и производительность».
«Можно ли заниматься разработкой приложений на Android планшете?» — «Нет, ситуация та же что и с айпадом: нужных локальных приложений нет, можно только через удалённый доступ».
«Можно ли заниматься разработкой веб-приложений на планшете XXX?» — «Возможно. Зависит от набора софта. Желательно, чтобы ОС позволяла поднимать на локальной машине всю инфраструктуру для разработки и тестирования, для большей независимости от сети».
> «Для обычных пользователей получение такого вредоноса, как Shedun, Shuanet, или ShiftyBug может означать необходимость похода в магазин за новым телефоном», — говорит представитель компании по информационной безопасности
Какой тонкий маркетинг. Главное — не рассказывать покупателям про лечение через factory reset, нечего тут, пусть идут покупать новый смартфон каждый раз.
Ну и традиционно раздражающий подход «В любой непонятной ситуации создавай свой дистрибутив Linux». Не библиотеку, не софт, не пакетную базу под Debian/RHEL/итд для взаимодействия с Azure — обязательно дистрибутив. Или сотую по счёту спецификацию дистрибутива, а-ля LSB. Фрагментация платформы уже сколько лет линуксы гробит, я не удивлюсь если MS хочет как раз в этот костёр подкинуть дровишек.
Из статьи и диаграммы ничего не понятно, если честно. Судя по диаграмме, в этом дистре просто будут предустановлены службы/клиентские приложения, дёргающие API платформы MS Azure. То есть дистр — просто запускалка несвободного SaaS, скучнейшая вещь.
«Будет поддерживать open source приложения» — это вообще что значит? Что bash и ls в этом дистре будут работать? Или что всё-таки сделают платформу с открытым API?
Мне кажется, тут ещё проблема, что средний возраст целевой аудитории ниже, чем нужно в данном случае. Тем людям, которые в сравнительно молодом возрасте застали «культовый» период книг-игр в России (это, если я не ошибаюсь, середина девяностых) и играли во всё это, сейчас в среднем по 30-40 лет, а в мобильные игры играет народ помоложе. Для них эти книги-игры это скорее отвлечённый исторический реликт, примерно как старый Doom или Warcraft.
Поигрался, уже лучше, довольно удобно, ведёт себя ожидаемо.
Чуть позже мб посмотрю что конкретно на уровне кода можно сделать, пока сходу по юзабилити вот где недоработки:
— Модуль должен требовать «require 'cl» и «require 'hl-line». Советую вообще работу модуля всегда проверять на голом емаксе (--no-init-file), собственно я так нехватку зависимостей и обнаружил.
— По-прежнему модуль предполагает, что юзер двигает курсор базовыми движениями (next-line ит.д.).
— По-прежнему вставка и удаление пробелов идут в историю модификаций. Я бы попытался как-то откатывать эти операции через undo и затем вообще выкидывать их из истории undo (иначе засоряется и цепочка redo).
— Prefix argument съедается (C-u 100 C-n переносит на 1 строку вниз, а не на 100).
— Что-то не то иногда с поведением, движения C-n и C-p добавляют лишние пробелы (чего ИМХО не должно происходить ни при каких обстоятельствах). Воспроизводится на буфере с 2 строками: «aaa» и «b», если встать в конец строки «aaa» и понажимать C-n C-p многократно. (emacs-24.4.1 x86_64-slackware-linux-gnu)
— Если встать на пустое место (на вставленные пробелы) и сделать backward-char, то ожидается, что курсор сдвинется влево, однако на практике это не так.
Норм, хотя лично мне непривычно видеть манипуляции с изображениями через скрипт, говорящий системе «нажми на этот пункт меню, нажми на окошко, сохрани файл указанный в этом окошке...». Как минимум такой подход требует изучать внутренние скриптовые команды пакета — зачем? Манипуляциями с файлами (сообщать java-приложению пути к файлам, или спрашивать эти пути у юзера) должен заниматься шелл, дело приложения — тупо конвертировать поток символов:
Потому что если например захотите передать выход приложения не в файл, а на вход convert (захотелось разрешение уменьшить), или там напрямую распознающему софту, без всяких промежуточных jpg, то весь скрипт придётся переписывать заново.
Если не секрет, как называется этот брутальный вид мартышек, которые ВЫРЫВАЮТ И ЖРУТ СЕРДЦА УМЕРШИХ СОБРАТЬЕВ? x_x
Идея любопытная, но так её реализовывать нельзя, разве что с елиспом поиграться.
Много лишних модификаций текста (undo в таком режиме превращается в кошмар). Не работает в readonly буферах. Удалит временные пробелы только после 4 фиксированных движений, а их десятки (isearch, Esc+<, Esc+>, прыжки Semantic и Evil...).
Короче, если такое и делать, то это уже надо править сишный код Emacs.
Многопроцессный мб? Я думаю, что там имелось в виду multithreaded.
> Мозилла
> Гекко
Mozilla, Gecko. Транслитерация здесь не оправдана.
> подвисания (jank)
Первый раз слышу про такой перевод слова «подвисание». До этого встречал только hang или freeze.
> нельзя просто так взять и начать пользоваться emacs без недели изучения
Как будто vim освоить быстрее) Ну на пару вечеров быстрее чем emacs, ок. На уровне блокнота emacs учится за вечер (и уже можно брать и писать код), за неделю учатся базовые функции и плагины (справка, dired, helm, org, magit, в общем по желанию). А вот после этого что в Vim, что в Emacs изучение фич может идти годами параллельно с использованием, и постоянно будут открываться новые возможности, сколько бы времени ни потратить — этим процесс и увлекателен.
Кстати, в Emacs есть режим эмуляции Vim под названием evil-mode, подходит не только свитчерам с vi/vim, но и просто кому угодно для заимствования от Vim скорости редактирования.
Да, см. Helm или Icicles
> А поиск по описанию команды?
info-apropos
> Или надо тупо вызубрить 100500 команд, а только потом приниматься за редактирование?
Ничего зубрить не надо, выучил команды info, where-is, describe-key и базовые клавиши, и вперёд редактировать текст.
По факту запускать Linux можно пробовать на любом x86 планшете, дальше как повезёт — где-то заработает, где-то будут проблемы с железом (как правило, второе).
Из того, что я видел вживую:
Microsoft Surface Pro 3 — практически полноценно работает под Debian, за исключением пары хардварных кнопок;
Lenovo Thinkpad Tablet 8 и Tablet 10 — формально работает (Debian стартует), но реально работать невозможно, поддержка железа ужасна — wifi не видит, звукового устройства не видит, поддержку накопителя (eMMC) только недавно реализовали (4.1 или 4.2).
Потому что если брать другие виды разработки и другие планшеты/ОС, то например моя практика даёт такие ответы:
«Можно ли заниматься разработкой десктопных приложений на x86 планшете с Win7/8?» — «Да, можно, при подключении клавиатуры и дисплея это тот же стационарный ПК с Win7/8 с тем же самом набором IDE и средств разработки. Единственная проблема — производительность».
«Можно ли заниматься разработкой десктопных приложений на x86 планшете с Linux?» — «Да, можно, при подключении клавиатуры и дисплея это тот же стационарный ПК с линуксом и с тем же самым набором IDE и средств разработки. Проблем две — поддержка железа и производительность».
«Можно ли заниматься разработкой приложений на Android планшете?» — «Нет, ситуация та же что и с айпадом: нужных локальных приложений нет, можно только через удалённый доступ».
«Можно ли заниматься разработкой веб-приложений на планшете XXX?» — «Возможно. Зависит от набора софта. Желательно, чтобы ОС позволяла поднимать на локальной машине всю инфраструктуру для разработки и тестирования, для большей независимости от сети».
Какой тонкий маркетинг. Главное — не рассказывать покупателям про лечение через factory reset, нечего тут, пусть идут покупать новый смартфон каждый раз.
Впрочем, все эти «тупой начальник vs просветлённые математики» и «лисп — серебряная пуля» — это в любом случае детский сад.
«Будет поддерживать open source приложения» — это вообще что значит? Что bash и ls в этом дистре будут работать? Или что всё-таки сделают платформу с открытым API?
Мне кажется, тут ещё проблема, что средний возраст целевой аудитории ниже, чем нужно в данном случае. Тем людям, которые в сравнительно молодом возрасте застали «культовый» период книг-игр в России (это, если я не ошибаюсь, середина девяностых) и играли во всё это, сейчас в среднем по 30-40 лет, а в мобильные игры играет народ помоложе. Для них эти книги-игры это скорее отвлечённый исторический реликт, примерно как старый Doom или Warcraft.
Чуть позже мб посмотрю что конкретно на уровне кода можно сделать, пока сходу по юзабилити вот где недоработки:
— Модуль должен требовать «require 'cl» и «require 'hl-line». Советую вообще работу модуля всегда проверять на голом емаксе (--no-init-file), собственно я так нехватку зависимостей и обнаружил.
— По-прежнему модуль предполагает, что юзер двигает курсор базовыми движениями (next-line ит.д.).
— По-прежнему вставка и удаление пробелов идут в историю модификаций. Я бы попытался как-то откатывать эти операции через undo и затем вообще выкидывать их из истории undo (иначе засоряется и цепочка redo).
— Prefix argument съедается (C-u 100 C-n переносит на 1 строку вниз, а не на 100).
— Что-то не то иногда с поведением, движения C-n и C-p добавляют лишние пробелы (чего ИМХО не должно происходить ни при каких обстоятельствах). Воспроизводится на буфере с 2 строками: «aaa» и «b», если встать в конец строки «aaa» и понажимать C-n C-p многократно. (emacs-24.4.1 x86_64-slackware-linux-gnu)
— Если встать на пустое место (на вставленные пробелы) и сделать backward-char, то ожидается, что курсор сдвинется влево, однако на практике это не так.
ls source*.jpg | xargs -I {} java_app -batch «script.java» -infile {} -outfile {}.converted
Потому что если например захотите передать выход приложения не в файл, а на вход convert (захотелось разрешение уменьшить), или там напрямую распознающему софту, без всяких промежуточных jpg, то весь скрипт придётся переписывать заново.
Если не секрет, как называется этот брутальный вид мартышек, которые ВЫРЫВАЮТ И ЖРУТ СЕРДЦА УМЕРШИХ СОБРАТЬЕВ? x_x
Много лишних модификаций текста (undo в таком режиме превращается в кошмар). Не работает в readonly буферах. Удалит временные пробелы только после 4 фиксированных движений, а их десятки (isearch, Esc+<, Esc+>, прыжки Semantic и Evil...).
Короче, если такое и делать, то это уже надо править сишный код Emacs.