Ну в KDE необязательно знать имя бинарника, он тоже умеет искать по строке «терминал». Да и в gnome тоже (как показали на скриншоте выше), но там будет отдельная фаза поиска и список приложений вывалится в отдельном списке, на который вначале надо перевести фокус. Но вообще, это вопрос запоминания. Тот, кто вообще первый раз использует gnome, будет вначале теряться и набирать terminal. А к следующему разу запомнит, что он называется gnome-terminal
Особенно нравится экономия экрана засчет global-menu
И где там экономия? Как занимало меню свои 30 (или 24, точно не считал) пикселей, так и занимает. Просто раньше было ниже заголовка, а стало — выше. Причём, если для распахнутых окон оно ещё ничего, то для небольших окон (например, контакт-лист в IM) неудобно всё время бегать мышкой между рабочей областью окна и левым верхним углом, где менюшка.
А ещё нет панели быстрого запуска (где размещаются маленькие значки), панели задач, кастомизации панелей (например, навешивания нужных индикаторов) и pidgin'а. Те же яйца.
Нафига по-русски? Я вот помню, что музыкальный проигрыватель называется exaile (теперь clemintine, привет Gnome 3) или консолька — gnome-terminal. А то надо запомнить «центр приложений». Удобства не добавляет.
Продуманный и прекрасный Sidebar
А чем лучше простого добавления иконок запуска на верхнюю панель?
Умный Launcher
ALT+F2? Уже ооочень давно юзаю, фактически почти только через него и запускаю программы. Что здесь добавил Unity?
Удобные Indicators (в едином стиле, что важно)
Gnome 2.32. KDE 4.7. Тоже есть. Тоже убодные. Тоже в едином стиле.
Базовая «тёмная» тема Unity (Ambience) — весьма интересна и рискована, ведь все стараются делать оконные интерфейсы в светлых тонах
Во времена использования Ubuntu отключал такую тему к чертям. Ибо многие приложения (Eclipse, например) под такое просто не заточены.
И вот почему: задумайтесь, что такое Операционная Система?
Очень и очень размытое понятие. По факту — просто прослойка между прикладным ПО и железом. Unity (как Gnome или KDE) — это DE, desktop environment. Одна из таких прикладных программ.
работать над конкретной прикладной задачей
У рабочего окружения не может быть конкретной прикладной задачи. Такие задачи решаются отдельными приложениями.
Полностью отказаться от GNOME в Ubuntu 11.10 и оставить только Unity
Конечно убрали Gnome 3. Потому что взяли, и зачем-то сделали свой вариант этого мерзостного поделия.
Unity имеет продуманный и качественный вид.
Gnome 2.32. KDE 4.7. Что не продумано? Что не качественно?
Всё в одном стиле
Gnome 2.32. KDE 4.7. Что в разных стилях?
В Unity есть много нового
Что именно нового? Неужто запилили новую IDE, в которой можно писать на естественном языке силой мысли? Нет, просто сделали новый DE, в котором по-другом ответили на холиварные вопросы вида «с какой стороны присобачить кнопки управления окном».
на современных экранах ширины гораздо больше, чем высоты, а высоту нужно экономить.
Вот поубивал бы маркетологов, которые всюду сунули эти свои 16x9. Кино смотреть нормально, но для этого вообще телевизор есть. А на своём рабочем компьютере я сижу в Eclipse. И мне конкретно не хватает высоты в перспективе debug, когда в окошке с локальными переменными видно строки 3-4, и, аналогично, строк 10 кода. Но при этом в ширину — хоть ложкой черпай. А веб читать вообще ужасно. Ведь всем давно известно золотое правило типографики — не более 10 слов в строке.
Тем более, что обычно тулбар внизу заполнен чуть менее, чем наполовину, и просто так простаивает «пустая» горизонтальная полоса
Тулбар? Это так панель задач что ли? Мне в KDE (да-да, пересел на него, ибо Gnome 3 ужасен) специально пришлось делать gnome2-образный вид, потому что в одну панель кнопки окон банально не влезают.
Интересно, а небольшой набор популярности у OpenSUSE — это случайность? Или некоторые, подобно мне, увидав Gnome 3, решили перейти на KDE (и потому на самый KDEнутый дистрибутив)?
Не-не-не, это плохо согласуется с идеологией веба. У веба идеология — REST. Т.е. каждая страница — это ресурс со своим адресом, причём всё это без состояния. Чем это хорошо — у любой страницы есть адрес, если нужно поделиться интересной веб-страницей — достаточно просто кинуть ссылку на неё. Поэтому в своё время веб и стал столь популярен и фактически среди масс стал синонимом слова «интернет». А тут дали людям в руки инструмент, так они делают свой браузер внутри браузера, только ущербный. Сайт вида «статический HTML с JS, который мастер-на-все-руки» хорош только в том случае, если это корпоративный интрасайт, потому что быстро разрабатывать, но нет специфических требований, которые идут от «большого» интернета. Причём, если это уж корпоративное ПО, то его лучше писать на GWT/Script#.
GWT основан на другом. Он не исполняет байт-код на стороне браузера, а генерирует JavaScript по исходникам. И используется он для RIA, а не для придания большего интерактива обычным сайтам.
Да уже давно свой шаблонизатор есть. Там всё очень от гугловского подхода отличается. Хотя бы тем, что это не «шаблонизатор, который может быть использован из JavaScript и Java». Я не использую свой шаблонизатор из JavaScript. Я заставляю его на сервере генерировать HTML, а на клиенте — перестраивать уже готовый HTML согласно изменившимся параметрам.
Не, JavaScript неудобен своей динамической типизированностью. Кроме того, остаётся не совсем ясным, как автоматически вынести логику, реализованную на сервере на javascript, на клиент. В Java есть аннотации и т.п. Можно прочитать байт-код. Можно через reflection API поковыряться к любом классе. А в javascript, где всего этого нет, даже и не знаю как поступить…
Кстати, не такая уж далёкая от практики идея. Я сейчас занимаюсь чем-то похожим (пишу преобразователь байткода в JS) с вполне практической целью. Всё началось, когда я задумался, как в своём фреймворке сделать валидацию форм так, чтобы не надо было дублировать код на сервере (Java) и на клиенте (JavaScript). Всяческие аннотации для типовых случаев не всегда спасают, плюс они как-то плохо сочетались с локализацией. В итоге мысль пошла именно в сторону преобразования байт-кода в JS. И тут открылись ещё несколько интересных вещей:
1. Помимо валидации, на клиент можно тащить ту часть логики, которая не зависит от БД. Например, в форме редактирования статьи есть кнопка «предпросмотр», которая без JS просто отправляет форму на сервер, а сервер формирует ту же страницу редактирования, но уже с предпросмотром статьи. Фактически, от сервера тут требуется распарсить вики-разметку и по ней сгенерировать HTML. Это можно вынести на клиент. Опять же, вынести можно автоматически.
2. Аналогично, научить генерировать JavaScript можно шаблонизатор. Эту возможность я планирую использовать всё для той же обработки форм. На кнопку отправки формы ставится обработчик. Этот обработчик делает AJAX-запрос, который сервер обрабатывает и возвращает параметры, назначенные шаблону, вместо того, чтобы рендерить шаблон. По этим параметрам браузер сам перерисует части страницы, которые изменились. Получаем AJAX, ничего специально для этого не дописывая. При этом можно и отключить JS — в этом случае генерацию страниц возьмёт на себя сервер.
Вообще, странно, что до сих пор такие штуки больше похожи на игрушки. Вон, делают же javascript-бэкэнд для LLVM, а кроме как поиграться никто не рассматривает. Впрочем, с Java всё равно интереснее, так как байт-код можно получить прямо в рантайме.
А никто не отменял XHTML. По сути, HTML5 описывает модель построения документа. Какой синтаксис использовать — XML или SGML — решение уже разработчика. Кстати, проблемы с well-formed XML (как и со всякими детскими уязвимостями, вроде SQL Injection или XSS) из-за неправильных инструментов.
JIT в принципе возможен и для Python и для Javascript (и для последнего есть). Вот только беда в том, что из-за динамической природы языка даже JIT породит не самый эффективный код (я писал об этом выше). Кстати, у дефолтной реализации питона есть ещё одна проблема — подсчёт ссылок. Так что, полагаю, всякие IronPython и JPython должны быть пошустрее, ибо они идут поверх среды, где уже есть и быстрый GC и JIT. А с недавних пор ещё и встроенная поддержка динамических языков.
GWT — это не средство для написания веб-приложений. Это фреймворк для написания RIA. Но не всё есть RIA. И сводить веб к ним — это кощунство. Так вот, GWT только для RIA и предназначен. Он не способен описыват серверную логику, генерацию HTML и т.п. JavaScript в общем случае — это не средство написания RIA. JavaScript позволяет сделать более интерактивным и удобным то, что обычным HTML+CSS сделать таковыми не получается. Скажем, в том же вики-движке можно с помощью JS сделать валидацию форм, кнопки для редактора вики-разметки, более удобный загрузчик картинок. Но это никак не отменяет базового функционала сайта — валидация всё равно делается и на сервере, вики-разметку так же парсит сервер, пусть она даже и набита в обычном text area, а файлы загрузить можно через простой input type=«file». При этом сохраняется главное, на мой взгляд, преимущество веба — за каждой страницей остаётся её адрес. GWT на такое не способен, т.к. в принципе для этого не предназначался. Как я понимаю, Dart выступает заменой JS в его различных сферах применения, а не только как алтернатива GWT.
C другой стороны, проблема дублирования остаётся. Лично у меня появилась идея, как можно её избежать. Ряд действий (валидация, отправка и обновление форм, парсинг вики-разметки при предпросмотре) всё равно делаются сервером. Но на стороне браузера такие вещи обычно оказываются более удобными. Не хотелось бы дублировать код, написанный на Java, ещё и на JS. Идея состоит в том, чтобы автоматически получать JS-версию кода, уже написанного на Java. Для этого можно написать декомпилятор байткода Java в Javascript. Вот каковы варианты использования такой штуки:
1. Валидация форм. Валидацию выполняет контроллер. Если вынести валидацию в отдельный метод контроллера, то этот метод можно преобразовать в JS, который то же самое делал бы на стороне браузера и выдавал бы alert'ы. Это вместо генерирования той же самой страницы, но с сообщениями об ошибках ввода.
2. Частичная перерисовка страниц при отправке формы. Логику генерации разметки так же можно перенести на сторону браузера. Когда пользователь нажимает кнопку отправки формы, очень часто пользователю в ответ выдаётся та же страница по тому же шаблону. Вместо этого браузер мог бы передавать веб-серверу только новые параметры шаблона в ajax-запросе и автоматом перерисовывать часть страницы.
При этом тот же самый функционал остаётся и с выключенным JS. Если же нужно написать что-то более динамическое, работающее именно на клиенте, разработчик может взять в руки JS или GWT — что ему нравится.
Я уже сделал кое-какие наработки в этом направлении. У меня есть свой фреймворк, и в репозитории я выделил ветку, в которой работаю над декомпилятором байт-кода — уже есть первые успехи (почти правильно переписанный на JS метод java.util.ArrayList.indexOf в качестве примера). В перспективе хочется добиться генерации качественного читабельного JS, чтобы не столкнуться с проблемой текучих абстракций, которая присуща GWT.
Например, в Яве крайне неэффективный метод загрузки классов — они загружаются по одному (вдумайтесь!) по мере использования, причем из zip-архивов. Причем для работы даже простой программы нужна куча клакссов из rt.jar. На практике это означает огромное число random access обращений к диску.
Во-первых, курим класслоадеры и вообще подробно изучаем архитектуру загрузки классов в JVM и понимаем, почему так сделаны и откуда вообще могут браться классы. Во-вторых, на практике это ничего не означает. Подобные вещи могут свободно кэшироваться. Если что — можно написать свой мегакласслоадер, который работал бы оптимальнее. Вот только я думаю, что инженеры из Sun Oracle не такие уж дураки и о подобных вещах уже подумали.
Ну не знаю насчёт аренды. У нас на серваке в дисковом массиве один диск стоит моих пары з/п. А так даже не знаю по поводу быдлокодеров. Возможно, если проекты серьёзные, то имеет смысл и высококвалифицированных спецов держать. А то быдлокодер так набыдлокодит, что потом больше потеряешь денег, чем на з/п для спецов.
Или вон фейсбук. Построили же себе датацентр. Тут уже не стоимость аренды. Тут и железо дорогое, и программисты крутые нужны. Которые на C++ пишут.
Что за наглая неправда. Расскажите мне, какой процессор умеет выполнять байт-код явы? Никакой. Потому в реальности перед вызовом самого метода тратится куча инструкций на чтение и разбор байткода, проверку типа объекта, поиск адреса метода.
Вот как раз Ваша реплика содержит неправду. Инструкции разбираются только при первом вызове. Дальше всегда работает только скомпилированный код. Впрочем, там даже всё несколько сложнее на самом деле, и всё только для одного — чтобы получить более быстрый нативный код.
Более того, если мне не изменяет память, кривокодеры из сан в модуле хранят названия методов и классов из других модулей *текстом* а не каким-то идентификатором, так что там еще дополнительные расходы идут на их преобразование в id метода.
Ну и что, что преобразовывать? Один раз ведь! И то, в самом байт-коде хранятся не строковые идентификаторы, а смещения в constant pool. Их вполне можно использовать в качестве идентификаторов. А то, что метаданные вообще хранятся — это правильно, иначе RTTI идёт лесом.
И где там экономия? Как занимало меню свои 30 (или 24, точно не считал) пикселей, так и занимает. Просто раньше было ниже заголовка, а стало — выше. Причём, если для распахнутых окон оно ещё ничего, то для небольших окон (например, контакт-лист в IM) неудобно всё время бегать мышкой между рабочей областью окна и левым верхним углом, где менюшка.
А ещё нет панели быстрого запуска (где размещаются маленькие значки), панели задач, кастомизации панелей (например, навешивания нужных индикаторов) и pidgin'а. Те же яйца.
А чем лучше простого добавления иконок запуска на верхнюю панель?
Умный Launcher
ALT+F2? Уже ооочень давно юзаю, фактически почти только через него и запускаю программы. Что здесь добавил Unity?
Удобные Indicators (в едином стиле, что важно)
Gnome 2.32. KDE 4.7. Тоже есть. Тоже убодные. Тоже в едином стиле.
Базовая «тёмная» тема Unity (Ambience) — весьма интересна и рискована, ведь все стараются делать оконные интерфейсы в светлых тонах
Во времена использования Ubuntu отключал такую тему к чертям. Ибо многие приложения (Eclipse, например) под такое просто не заточены.
И вот почему: задумайтесь, что такое Операционная Система?
Очень и очень размытое понятие. По факту — просто прослойка между прикладным ПО и железом. Unity (как Gnome или KDE) — это DE, desktop environment. Одна из таких прикладных программ.
работать над конкретной прикладной задачей
У рабочего окружения не может быть конкретной прикладной задачи. Такие задачи решаются отдельными приложениями.
Полностью отказаться от GNOME в Ubuntu 11.10 и оставить только Unity
Конечно убрали Gnome 3. Потому что взяли, и зачем-то сделали свой вариант этого мерзостного поделия.
Unity имеет продуманный и качественный вид.
Gnome 2.32. KDE 4.7. Что не продумано? Что не качественно?
Всё в одном стиле
Gnome 2.32. KDE 4.7. Что в разных стилях?
В Unity есть много нового
Что именно нового? Неужто запилили новую IDE, в которой можно писать на естественном языке силой мысли? Нет, просто сделали новый DE, в котором по-другом ответили на холиварные вопросы вида «с какой стороны присобачить кнопки управления окном».
на современных экранах ширины гораздо больше, чем высоты, а высоту нужно экономить.
Вот поубивал бы маркетологов, которые всюду сунули эти свои 16x9. Кино смотреть нормально, но для этого вообще телевизор есть. А на своём рабочем компьютере я сижу в Eclipse. И мне конкретно не хватает высоты в перспективе debug, когда в окошке с локальными переменными видно строки 3-4, и, аналогично, строк 10 кода. Но при этом в ширину — хоть ложкой черпай. А веб читать вообще ужасно. Ведь всем давно известно золотое правило типографики — не более 10 слов в строке.
Тем более, что обычно тулбар внизу заполнен чуть менее, чем наполовину, и просто так простаивает «пустая» горизонтальная полоса
Тулбар? Это так панель задач что ли? Мне в KDE (да-да, пересел на него, ибо Gnome 3 ужасен) специально пришлось делать gnome2-образный вид, потому что в одну панель кнопки окон банально не влезают.
1. Помимо валидации, на клиент можно тащить ту часть логики, которая не зависит от БД. Например, в форме редактирования статьи есть кнопка «предпросмотр», которая без JS просто отправляет форму на сервер, а сервер формирует ту же страницу редактирования, но уже с предпросмотром статьи. Фактически, от сервера тут требуется распарсить вики-разметку и по ней сгенерировать HTML. Это можно вынести на клиент. Опять же, вынести можно автоматически.
2. Аналогично, научить генерировать JavaScript можно шаблонизатор. Эту возможность я планирую использовать всё для той же обработки форм. На кнопку отправки формы ставится обработчик. Этот обработчик делает AJAX-запрос, который сервер обрабатывает и возвращает параметры, назначенные шаблону, вместо того, чтобы рендерить шаблон. По этим параметрам браузер сам перерисует части страницы, которые изменились. Получаем AJAX, ничего специально для этого не дописывая. При этом можно и отключить JS — в этом случае генерацию страниц возьмёт на себя сервер.
Вообще, странно, что до сих пор такие штуки больше похожи на игрушки. Вон, делают же javascript-бэкэнд для LLVM, а кроме как поиграться никто не рассматривает. Впрочем, с Java всё равно интереснее, так как байт-код можно получить прямо в рантайме.
C другой стороны, проблема дублирования остаётся. Лично у меня появилась идея, как можно её избежать. Ряд действий (валидация, отправка и обновление форм, парсинг вики-разметки при предпросмотре) всё равно делаются сервером. Но на стороне браузера такие вещи обычно оказываются более удобными. Не хотелось бы дублировать код, написанный на Java, ещё и на JS. Идея состоит в том, чтобы автоматически получать JS-версию кода, уже написанного на Java. Для этого можно написать декомпилятор байткода Java в Javascript. Вот каковы варианты использования такой штуки:
1. Валидация форм. Валидацию выполняет контроллер. Если вынести валидацию в отдельный метод контроллера, то этот метод можно преобразовать в JS, который то же самое делал бы на стороне браузера и выдавал бы alert'ы. Это вместо генерирования той же самой страницы, но с сообщениями об ошибках ввода.
2. Частичная перерисовка страниц при отправке формы. Логику генерации разметки так же можно перенести на сторону браузера. Когда пользователь нажимает кнопку отправки формы, очень часто пользователю в ответ выдаётся та же страница по тому же шаблону. Вместо этого браузер мог бы передавать веб-серверу только новые параметры шаблона в ajax-запросе и автоматом перерисовывать часть страницы.
При этом тот же самый функционал остаётся и с выключенным JS. Если же нужно написать что-то более динамическое, работающее именно на клиенте, разработчик может взять в руки JS или GWT — что ему нравится.
Я уже сделал кое-какие наработки в этом направлении. У меня есть свой фреймворк, и в репозитории я выделил ветку, в которой работаю над декомпилятором байт-кода — уже есть первые успехи (почти правильно переписанный на JS метод java.util.ArrayList.indexOf в качестве примера). В перспективе хочется добиться генерации качественного читабельного JS, чтобы не столкнуться с проблемой текучих абстракций, которая присуща GWT.
Во-первых, курим класслоадеры и вообще подробно изучаем архитектуру загрузки классов в JVM и понимаем, почему так сделаны и откуда вообще могут браться классы. Во-вторых, на практике это ничего не означает. Подобные вещи могут свободно кэшироваться. Если что — можно написать свой мегакласслоадер, который работал бы оптимальнее. Вот только я думаю, что инженеры из
SunOracle не такие уж дураки и о подобных вещах уже подумали.Или вон фейсбук. Построили же себе датацентр. Тут уже не стоимость аренды. Тут и железо дорогое, и программисты крутые нужны. Которые на C++ пишут.
Ага, и к этому серверу обслуживающий персонал. Которому тоже нужно платить з/п.
Run time type information? А я как бы про compile time говорил.
А как там с параметрическим полиморфизмом aka generics? Например, я хочу вызвать метод, который возвращает список. Как узнать тип элементов списка?
Вот как раз Ваша реплика содержит неправду. Инструкции разбираются только при первом вызове. Дальше всегда работает только скомпилированный код. Впрочем, там даже всё несколько сложнее на самом деле, и всё только для одного — чтобы получить более быстрый нативный код.
Ну и что, что преобразовывать? Один раз ведь! И то, в самом байт-коде хранятся не строковые идентификаторы, а смещения в constant pool. Их вполне можно использовать в качестве идентификаторов. А то, что метаданные вообще хранятся — это правильно, иначе RTTI идёт лесом.