В гноме2 панель для запуска постоянно используемого софта организуется в несколько кликов хочешь слева, хочешь справа, хочешь снизу, хочешь сверху.
Dash — падучее недоразумение, непонятно какую задачу решающее.
Больше места на экране? Да, эти 30 пикселей по вертикали того стоили…
А почему его не брать в расчет? Зачем было его выпиливать и заменять этой панелькой когда он прекрасно решал свои задачи? У меня самые часто используемые приложения — в квик ланче сверху, панель задач — внизу (cairo-dock). На котором кстати тоже прекрасно группируются иконки одного приложения, няшные 3d эффекты и в бонус — можно еще всякие десклеты размещать (хотя мне и не нужно). Но при этом я вполне себе подкрутил размер иконок, шрифты, и если мне завтра что-то в голову стукнет — просто перетащу нужную мне панель влево или вправо. Зачем для этого Unity? Больше разработчикам заняться нечем? Не понимаю.
Так если бы были плюсы… А так кроме катастрофического падения производительности работы я ничего не увидел. Попытался есть кактус недели три, после чего понял, что это путь в никуда и снес к чертовой матери.
Ну тогда я подскажу — а никак. Пользователю это не нужно. И это хорошо (с)
Про расположение панельки — уж поверьте, неудобно. Я там выше отписывал почему. Еще раз — искать элементы мне привычней по горизонтали, ибо так мы читаем и пишем. Места опять же не хватает.
И шрифты не настраиваются. По крайней мере без сторонних твикеров.
То что штука простая — это да. Пока задачи простые. Но я не буду рыдать в подушку если она станет сложнее, просто дайте мне эти чертовы настройки!
А пока разработчики считают что они умнее всех, и вместо десктопного DE пишут эмулятор планшетника для людей которым надо запустить мультики или открыть опенофисик — пусть это юзает кто-то еще, мне мои нервы дороги.
Да на кой черт мне вообще что-то искать там? Почему в gnome2 я спокойно в 3 клика Приложения > Интернет > Клиент удаленного рабочего стола например запускаю, а тут мне чтобы его найти надо еще вспомнить remmina называется?..
Окей. Я хочу перетащить боковую панель вниз. Или вправо. Это так сложно? Просто схватить ее мышкой и перетащить? Я хочу увеличить шрифт в интерфейсе. Мне плохо его видно. Сколько шагов мне для этого нужно пройти? Я хочу чтобы меню приложения не скрывалось, а было доступно всегда, без тыканий мышью вверх экрана. Где мне поставить галку? Насколько это очевидно?
Я хочу поменять высоту верхней панели. И я не хочу чтобы это поделие крешилось, унося с собой в могилу весь оконный декоратор, после чего остается только прибивать иксы. Список можно продолжать, но для этого наверное надо это убожество запустить, а мне как-то лениво его в виртуалке ставить.
Я сильно многого хочу, да?
И мне не 7 лет, но если Unity заточена под семилетних девочек, то так об этом и скажите, — люди постарше просто не будут тратить на него свое время.
Я привык читать слева направо. Соответственно, найти нужный элемент мне проще пробежав глазами в привычном направлении, нежели сверху вниз.
И да, я действительно открываю столько программ чтобы вертикального меню мне по высоте не хватало. Иконки начинают скукоживаться, и поиск нужной напрягает.
Unity — шаг вперед в поисках новых решений для рабочего окружения, но 5 шагов назад в юзабилити. За попытку — зачёт, реализация — не выдерживает критики. Признайте это наконец.
Если с 1-2 еще можно как-то жить (хотя чего это я должен как-то там жить если все уже работает как надо из коробки начиная от гнома2 заканчивая виндой7 и макосью) то п.3 — это epic fail. Canonical еще не доросла до того чтобы диктовать как должно быть удобно пользователю. Тот же Apple & MS это и то осторожней делают, сохраняя обратную совместимость. А тут — все поломать и крикнуть «мы молодцы». Нет, спасибо, я лучше пешком постою.
Я уж не знаю кому как, но мне нужно за компом работать, а не восторгаться «консистентностью и продуманностью» интерфейса, в котором для того чтобы запустить приложение, я по задумке разработчиков должен открыть меню, восхититься 100500 значками, устать искать глазами нужный, начать набивать название приложения в строка поиска, дождаться выдачи, после чего ткнуть в него мышккой. Вы в своем ли уме, господа?
Дальше идем. Вон вы там восторгались шикарным таскбаром. Мол, иконочка подсветилась — программка внимания требует. Ня, прелесть. Только мы этого не увидим пока эту самую панель не вызовем, тыкаясь мышкой в бок экрана. Требует внимания приложение? Ну и пусть — кто понял жизнь, тот не спешит, ага.
Особенно удивляет ваше «это нельзя просто изменить, это тоже неспроста». Я что, похож на имбецила, которому нельзя давать в руки возможность разместить этот ублюдочный таскбар не слева а справа например? Собственно, это относится практически ко всему в Unity. Попробуйте-ка навскидку поменять хоть что-то в ее интерфейсе. Не получилось? Ну это ж не спроста…
Господа разработчики. У меня не планшет, под который вы пытаетесь пилить это недоразумение. У меня десктоп, и я такой далеко не один. Поэтому, поглядев на это торжество здравого смысла в ubuntu 11.10, увидев что в гноме3 дела хоть и немного лучше, но по сути проблема та же — забивание на десктоп-юзабилити полнейшее, я откатился на 11.04 с гномом2, и когда он окончательно протухнет — свалю на кде или xfce. Или вообще на макось, только подальше от этого безумия, именуемого «инновационным интерфейсом».
Вот такой вот крик души. Достало уже подмена понятий «ниасилили, поленились, забили» на «это модно и инновационно, теперь мы будем работать так».
> Бесспорно.
> Но неужели нельзя использовать существующий байт Suboption type
> чуть более оптимально, чем сейчас?
В байте 8 бит. Стало быть бить на равное количество кусков — это или на 2 или на 4. Если на 2- не хватит кусков, если на 4 — куски получатся слишком маленькие. А завтра к ipv6 появится какое-то интересное расширение — и приплыли. Зачем творить странное если TLV — это и есть общепринятое средство избегания подобных велосипедов с разбиванием байтов?
> В общем, это переливание из пустого в порожнее.
> Надо работать с тем, что есть, и не забывать держать в голове все эти
> расклады во избежание некорректного интеропа.
> Циска решила — ключевая фраза. Когда я вижу поле Value, мне в жизни не придёт
> в голову создавать там ещё одну сущность TLV, уже будучи внутри другой TLV.
Увы, на голову отдельный RFC еще не вышел
> Можно пойти дальше и сделать ещё одну иерархию и т.д.
Можно конечно. Именно для этого создатели RFC и определили это поле как набор байт без детального описания формата, оставив это на откуп вендорам.
> Как же мне не додумывать, если в документе явно не оговаривается что такое Value
> и какую информацию оно несёт?
Читаем RFC 3046. Можно даже по диагонали.
3.1 Agent Circuit ID Sub-option
Possible uses of this field include:
— Router interface number
— Switching Hub port number
— Remote Access Server port number
— Frame Relay DLCI
— ATM virtual circuit number
— Cable Data virtual circuit number
3.2 Agent Remote ID Sub-option
he Remote ID field may be used to encode, for instance:
— a «caller ID» telephone number for dial-up connection
— a «user name» prompted for by a Remote Access Server
— a remote caller ATM address
— a «modem ID» of a cable data modem
— the remote IP address of a point-to-point link
— a remote X.25 address for X.25 connections
Отсюда становится понятным зачем там TLV. Ибо данные могут быть ну очень разные, не эзернетом же единым…
> Ну молодцы, сделали запас с прицелом на будущее, но только забыли других предупредить
А кого она должна была предупреждать? В документации это все прекрасно расписано, какие вопросы?
> Циска не смогла продавить это расширение в RFC?
> Так ведь на то, видимо, были причины, не находите?
Если циско каждое свое решение начнет продавливать в rfc, в отрасли начнется что-то не то, не находите?
> Наезжать надо на написателей RFC.
Не надо. Вендорный разнобой в атрибутах — это суровая правда жизни, и ничего с этим не сделать. Авторы тут ни в чем не виноваты, их задача — написать внятный документ по которому можно что-то реализовать. На мой взгяд тут у них все в порядке.
Другое дело что если предстоит общаться с разными железяками, то безусловно стоит держать в голове тот факт что у них могут быть кардинально разные представления об этих атрбутах, и это нормально (по крайней мере на сегодняшний день).
Беглого взгляда на документацию достаточно чтобы понять что это. Циска решила значения субопций хранить в виде TLV-триплетов для расширяемости в дальшейшем. Думается мне, это хорошее, годное начинание. По крайней мере, это абсолюно ничему не противоречит, в том числе и здравому смыслу. В описаниях форматов опции 82 в цисковских доках поле Type = 0 везде где я видел. Остальные значения, вестимо, reserved for future use.
RFC не допускает никаких разночтений. Сказано вам — Value, последовательность байт — извольте не додумывать всякое и не строить беспочвенных теорий на тему того что там мол строго ascii-стринг обязан быть.
И вот ведь как выходит. Juniper написал софт основываясь на предположениях которых в рфц ни разу нигде нет и они якобы молодцы. Edge-Core прогнулись под них (что неудивительно, им похоже вообще пофигу у кого софт передирать) — тоже респект. Кошковцы написали софт который нигде не противоречит rfc — и они злостные нарушители стандартов, проприетарные сволочи и гореть им в аду. Как-то странно, не?
> Формально — да, нигде не сказано, что начиная с первого байта value должна следовать строка, но, чёрт побери, это ведь должно быть очевидно:) Ведь The Agent Information field consists of a sequence of SubOpt/Length/Value. Как можно было в Value засунуть ещё одни заголовки?!
Ну а как можно было тупо решить что там должна быть только ascii, не подумавши что само по себе value может быть каким-то более комплексным? скажем, взять тот же circuit id type. Вот куда его засунуть согласно rfc если не в Value? Можно конечно сказать что эта опция народу не нужна, но это уже совсем неправильно как-то. Описанное вами больше похоже на fail джунипера и спешный прогиб эджиков под него.
Вызывающе неверная информация ;)
Пацаны из циско курят конечно знатную дурь порой, но тут к ним вопросов нет, всё в соответствии с RFC 3046. Suboption type, Length+2 — это первые байты заголовка. Здесь Length — длина ASCII Circuit ID String + 2 байта дополнительных Circuit ID Type, Length. По сути Circuit ID представлен в виде TLV-триплета, значение которого — ascii circuit id string. В RFC нигде не сказано что Circuit ID обязан быть ASCII строкой. Это видать Edge-Core себе что-то понапридумывали уже.
Уж не знаю какие девайсы этого пугаются, но у нас все работает без дополнительных телодвижених, хотя сеть и мультивендорная.
И, кстати, циска не только признает, а еще и разжевывает в картинках всё вышесказанное в документации. Что конечно-же не отменяет возможных ньюансов в части interop поскольку RFC написан достаточно свободно.
Ну а почему ж не использовать option 82 и не выставлять адреса хоть в виде 10.$vlan.$switch.$port/16 раз уж на то пошло? В 82 все эти параметры передаются, и их можно крутить как угодно. Так что с фразой «Решение №4 (самое гибкое)» поспорил бы. Далеко не самое.
Ответ неверный.
Там кстати как дела обстоят с галкой «В терминале» в этом вашем Dash?
А, сорри, забыл. Это ж не нужно.
Dash — падучее недоразумение, непонятно какую задачу решающее.
Больше места на экране? Да, эти 30 пикселей по вертикали того стоили…
А почему его не брать в расчет? Зачем было его выпиливать и заменять этой панелькой когда он прекрасно решал свои задачи? У меня самые часто используемые приложения — в квик ланче сверху, панель задач — внизу (cairo-dock). На котором кстати тоже прекрасно группируются иконки одного приложения, няшные 3d эффекты и в бонус — можно еще всякие десклеты размещать (хотя мне и не нужно). Но при этом я вполне себе подкрутил размер иконок, шрифты, и если мне завтра что-то в голову стукнет — просто перетащу нужную мне панель влево или вправо. Зачем для этого Unity? Больше разработчикам заняться нечем? Не понимаю.
Про расположение панельки — уж поверьте, неудобно. Я там выше отписывал почему. Еще раз — искать элементы мне привычней по горизонтали, ибо так мы читаем и пишем. Места опять же не хватает.
И шрифты не настраиваются. По крайней мере без сторонних твикеров.
То что штука простая — это да. Пока задачи простые. Но я не буду рыдать в подушку если она станет сложнее, просто дайте мне эти чертовы настройки!
А пока разработчики считают что они умнее всех, и вместо десктопного DE пишут эмулятор планшетника для людей которым надо запустить мультики или открыть опенофисик — пусть это юзает кто-то еще, мне мои нервы дороги.
Я хочу поменять высоту верхней панели. И я не хочу чтобы это поделие крешилось, унося с собой в могилу весь оконный декоратор, после чего остается только прибивать иксы. Список можно продолжать, но для этого наверное надо это убожество запустить, а мне как-то лениво его в виртуалке ставить.
Я сильно многого хочу, да?
И мне не 7 лет, но если Unity заточена под семилетних девочек, то так об этом и скажите, — люди постарше просто не будут тратить на него свое время.
И да, я действительно открываю столько программ чтобы вертикального меню мне по высоте не хватало. Иконки начинают скукоживаться, и поиск нужной напрягает.
Unity — шаг вперед в поисках новых решений для рабочего окружения, но 5 шагов назад в юзабилити. За попытку — зачёт, реализация — не выдерживает критики. Признайте это наконец.
Я уж не знаю кому как, но мне нужно за компом работать, а не восторгаться «консистентностью и продуманностью» интерфейса, в котором для того чтобы запустить приложение, я по задумке разработчиков должен открыть меню, восхититься 100500 значками, устать искать глазами нужный, начать набивать название приложения в строка поиска, дождаться выдачи, после чего ткнуть в него мышккой. Вы в своем ли уме, господа?
Дальше идем. Вон вы там восторгались шикарным таскбаром. Мол, иконочка подсветилась — программка внимания требует. Ня, прелесть. Только мы этого не увидим пока эту самую панель не вызовем, тыкаясь мышкой в бок экрана. Требует внимания приложение? Ну и пусть — кто понял жизнь, тот не спешит, ага.
Особенно удивляет ваше «это нельзя просто изменить, это тоже неспроста». Я что, похож на имбецила, которому нельзя давать в руки возможность разместить этот ублюдочный таскбар не слева а справа например? Собственно, это относится практически ко всему в Unity. Попробуйте-ка навскидку поменять хоть что-то в ее интерфейсе. Не получилось? Ну это ж не спроста…
Господа разработчики. У меня не планшет, под который вы пытаетесь пилить это недоразумение. У меня десктоп, и я такой далеко не один. Поэтому, поглядев на это торжество здравого смысла в ubuntu 11.10, увидев что в гноме3 дела хоть и немного лучше, но по сути проблема та же — забивание на десктоп-юзабилити полнейшее, я откатился на 11.04 с гномом2, и когда он окончательно протухнет — свалю на кде или xfce. Или вообще на макось, только подальше от этого безумия, именуемого «инновационным интерфейсом».
Вот такой вот крик души. Достало уже подмена понятий «ниасилили, поленились, забили» на «это модно и инновационно, теперь мы будем работать так».
> Но неужели нельзя использовать существующий байт Suboption type
> чуть более оптимально, чем сейчас?
В байте 8 бит. Стало быть бить на равное количество кусков — это или на 2 или на 4. Если на 2- не хватит кусков, если на 4 — куски получатся слишком маленькие. А завтра к ipv6 появится какое-то интересное расширение — и приплыли. Зачем творить странное если TLV — это и есть общепринятое средство избегания подобных велосипедов с разбиванием байтов?
> В общем, это переливание из пустого в порожнее.
> Надо работать с тем, что есть, и не забывать держать в голове все эти
> расклады во избежание некорректного интеропа.
+1
> в голову создавать там ещё одну сущность TLV, уже будучи внутри другой TLV.
Увы, на голову отдельный RFC еще не вышел
> Можно пойти дальше и сделать ещё одну иерархию и т.д.
Можно конечно. Именно для этого создатели RFC и определили это поле как набор байт без детального описания формата, оставив это на откуп вендорам.
> Как же мне не додумывать, если в документе явно не оговаривается что такое Value
> и какую информацию оно несёт?
Читаем RFC 3046. Можно даже по диагонали.
3.1 Agent Circuit ID Sub-option
Possible uses of this field include:
— Router interface number
— Switching Hub port number
— Remote Access Server port number
— Frame Relay DLCI
— ATM virtual circuit number
— Cable Data virtual circuit number
3.2 Agent Remote ID Sub-option
he Remote ID field may be used to encode, for instance:
— a «caller ID» telephone number for dial-up connection
— a «user name» prompted for by a Remote Access Server
— a remote caller ATM address
— a «modem ID» of a cable data modem
— the remote IP address of a point-to-point link
— a remote X.25 address for X.25 connections
Отсюда становится понятным зачем там TLV. Ибо данные могут быть ну очень разные, не эзернетом же единым…
> Ну молодцы, сделали запас с прицелом на будущее, но только забыли других предупредить
А кого она должна была предупреждать? В документации это все прекрасно расписано, какие вопросы?
> Циска не смогла продавить это расширение в RFC?
> Так ведь на то, видимо, были причины, не находите?
Если циско каждое свое решение начнет продавливать в rfc, в отрасли начнется что-то не то, не находите?
> Наезжать надо на написателей RFC.
Не надо. Вендорный разнобой в атрибутах — это суровая правда жизни, и ничего с этим не сделать. Авторы тут ни в чем не виноваты, их задача — написать внятный документ по которому можно что-то реализовать. На мой взгяд тут у них все в порядке.
Другое дело что если предстоит общаться с разными железяками, то безусловно стоит держать в голове тот факт что у них могут быть кардинально разные представления об этих атрбутах, и это нормально (по крайней мере на сегодняшний день).
RFC не допускает никаких разночтений. Сказано вам — Value, последовательность байт — извольте не додумывать всякое и не строить беспочвенных теорий на тему того что там мол строго ascii-стринг обязан быть.
И вот ведь как выходит. Juniper написал софт основываясь на предположениях которых в рфц ни разу нигде нет и они якобы молодцы. Edge-Core прогнулись под них (что неудивительно, им похоже вообще пофигу у кого софт передирать) — тоже респект. Кошковцы написали софт который нигде не противоречит rfc — и они злостные нарушители стандартов, проприетарные сволочи и гореть им в аду. Как-то странно, не?
Ну а как можно было тупо решить что там должна быть только ascii, не подумавши что само по себе value может быть каким-то более комплексным? скажем, взять тот же circuit id type. Вот куда его засунуть согласно rfc если не в Value? Можно конечно сказать что эта опция народу не нужна, но это уже совсем неправильно как-то. Описанное вами больше похоже на fail джунипера и спешный прогиб эджиков под него.
Пацаны из циско курят конечно знатную дурь порой, но тут к ним вопросов нет, всё в соответствии с RFC 3046. Suboption type, Length+2 — это первые байты заголовка. Здесь Length — длина ASCII Circuit ID String + 2 байта дополнительных Circuit ID Type, Length. По сути Circuit ID представлен в виде TLV-триплета, значение которого — ascii circuit id string. В RFC нигде не сказано что Circuit ID обязан быть ASCII строкой. Это видать Edge-Core себе что-то понапридумывали уже.
Уж не знаю какие девайсы этого пугаются, но у нас все работает без дополнительных телодвижених, хотя сеть и мультивендорная.
И, кстати, циска не только признает, а еще и разжевывает в картинках всё вышесказанное в документации. Что конечно-же не отменяет возможных ньюансов в части interop поскольку RFC написан достаточно свободно.
только народ же не поверит ни разу