Опубликован первый выпуск проекта labwc, развивающего композитный сервер для Wayland с возможностями, напоминающими оконный менеджер Openbox (проект преподносится как попытка создания альтернативы Openbox для Wayland). Из особенностей labwc называется минимализм, компактная реализация, широкие возможности настройки и высокая производительность. Код проекта написан на языке Си и распространяется под лицензией GPLv2...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54715
Я надеюсь, они отказались от xml хотя бы, тот же json на порядки удобнее для конфигурирования. Или лучше вообще yaml.
Судя по упоминанию sway, на nvidia не заработает. Придётся оставаться на kwin_wayland (который работает с nvidia).
С nouveau sway работает если очень вам хочется.
> С nouveau sway работает если очень вам хочется.Нам хочется vulkan и cuda, да и управлять картой неплохо бы -- минимальной частоты явно не хватает для работы. Opengl via vulkan это конечно хорошо, но так можно и вейланда сразу на вулкане дождаться наверно, потому что opengl ровно такое же легаси как и иксы -- зачем они все на него завязываются?
Прочитал не так давно, что xwayland будет ещё лет 20 рулить приложухами. потому выгодно использовать именно так, а потом останется только BSD. :)
>Прочитал не так давнозачем вы всякую пакость на заборе читаете ?
> Прочитал не так давноВот и не надо там больше читать. XWayland сделан исключительно из соображений того, что разом все приложения под новый сервер никто не перепишет и, также, обязательно кто-то захочет пользовать старые несопровождаемые приложения/игры, которые никто и никогда переделывать не будет.
Для примерно тех же целей в MacOS сто лет как есть XQuartz, который есть ровно тоже самое, что и XWayland. И что-то особой паники не наблюдается.
Считать фигурные скобочки или пробелы так увлекательно!
Чем вам ini не мил, ироды?!
> Считать фигурные скобочки или пробелы так увлекательно!
> Чем вам ini не мил, ироды?!Ну, это проще, чем искать в xml лапше где же ты ошибся. Особенно, с подсветкой редактора.
Ну, т.е. мысль что "можно не есть гумно" в голову не приходит даже после явной подсказки. "С маянезиком"(ТМ) в виде подсветки синтаксиса почти и не воняет, ага.
Говорю же, ироды!
>Ну, это проще, чем искать в xml лапше где же ты ошибсяочевидно, что XML должен быть pretty-форматированным, тогда оно становится самым УДОБНЫМ из трёх: yaml, json, xml
обычно конфиг на xml на порядок сложнее любых других. проблема не в xml, а в том что в XML сильно много пихают.
Это до тех пор, пока тебе не понадобится добавлять/изменять элементы вручную -- там свихнуться от этой лапши можно. Как ЭТО можно считать удобным?
ini хорош только для дилетантов вроде тебя. Конфиги могут быть ОЧЕНЬ СЛОЖНЫМИ, с несколькими уровнями вложенности - как и зачем их делать на ini???
JSON - ответ на ближайшие 20 лет.
> ini хорош только для дилетантов вроде тебя. Конфиги могут быть ОЧЕНЬ СЛОЖНЫМИ,
> с несколькими уровнями вложенности - как и зачем их делать на
> ini???
> JSON - ответ на ближайшие 20 лет.Да, наверное, если что-то сложное, оно выглядит универсальным. Но когда я открываю json мне неприятно от оверхеда, от осознания, что я пропущу символ и конфиг будет неправильным, я недостаточно хорошо вижу логику в этой каше...
Открой для себя jq, он может выдать отформатированный для чтения файл. Ну или питон. Это то, что я использую для работы с жсоном.
Ну, т.е. помимо ide с подсветкой синтаксиса нужен ещё отдельный процессор для работы, да ещё линтер какой на-заполировать?
Так, посоны - кому там sendmail.mc не нравился? Отличное же, современное, человекочитаемое и универсальное решение было, ну?
Какие ещё ide? Любой блокнот подсвечивает жсон. Jq или python нужны чтобы минифицированные файлы привести в читаемый вид. Для начала, никто не заставляет их минифицировать раз это редактируемые пользователем файлы.
"Любой" - это какой? notepad.exe вот не подсвечиваает ничего. ee тоже не-а. Ванильный vi(m)? Что там еще из "блокнотов"? А, nano вроде искаропки подсвечивает скобочки в бесконечной строке... "У" - удобство! И даже "Ч" - человекочитаемость!
И да - вы тот аноним, что рядышком советовал jq\python для пущей человекочитаемости к человекочитаемому формату применять, или другой?
Не надо передёргивать. Минимифицированный json а ля 10 мегабайт одной строкой понятное дело будет не редактируемым вручную (это такой намёк, что он не для пользователя), нормально отформатированный же он на порядки сподручнее xml.
"Чем лучше? чем грузины!"
С тем, что "в ряде случаев" "в ряде блокнотов" почти-совсем человекочитаемый формат будет лучше, чем чудовище обло, огромно, стозевно и лаяй - никто и не спорит.
Ну, т.е. вы думаете, что в ближайшие 20 лет ничего более кривого, косого и не удобного не появится? У меня для вас плохие новости! БУДУЮЩИЕ за нашим новым, универсальным, распределенным, человекочитаемым (ну, почти - gnu poke уже понимает) синтаксисом на основе blockchain - no-sql-sqlite (sql-like запросы в виде grapql-нашлепки ставятся отдельно) с git-подобным (но не совсем) синтаксисом! Что? Etcd уже есть? И "реестр windows" тоже изобрели? Ну... У них есть Фатальный Недостаток...
Json хорош чисто как human readable формат сериализации объектов (на что вам, упёртым, даже название намекает).Язык конфигурации без комментариев это даже не неудобно, это просто нежизнеспособно.
> human readableуау, крутой англичанин в треде
>Конфиги могут быть ОЧЕНЬ СЛОЖНЫМИОни не должны, это хрестоматийный пример плохого дизайна.
И при чём тут json? В голову не приходило, что конфиг это конфиг? У него должен быть свой формат. И не надо использовать формат для обмена данными в качестве конфига. Оно для этого не предназначено и как минимум не умеет комментарии.
И ini-стиль как бы может быть иерархичным - какие проблемы?
Для отступа пробелами можно использовать линейку, если приложить ее вертикально
Вот и мне интеремно чем им не угодили нориальгые конфиги вида ключь - значение? Чего все с этим дурацким json и xml лазят.
Json хорош только для языков с динамической типизацией, сейчас число строка, потом число число, для остальных даже xml лучше
Вы ведь в курсе что числа и строки в JSON это разное?
— Мне две книжки "JS для чайников" по $9.
— С Вас $99.
убил! :)))))))))))))
С Вас по-прежнему $99.
(cdr(cdr(cdr price)))
> сейчас число строка{
numStr: "123"
}> потом число число
{
numNum: 123
}Таки есть разница, не так ли ?
Но вообще, в каких-то сильно серьезных/ответственных случаях, когда структура данных ещё толком не определена( или гомнопроект или только в стадии разработки с ежедневно меняющейся структурой ) обычно используют приведение к нужному типу или сравнение с ожидаемым тИпом - и предупреждение/ошибка, если не сходится
Только "numNum" и "numStr" (в кавычках)Ох..нный язык для конфигурации, да...
> Только "numNum" и "numStr" (в кавычках)Для чистого JSON'а - да, поля в кавычках. Очень неудобно было набирать с телефона, потому забил.
Сейчас нередко вместо него применяют JS-скрипты, возвращающие объект/массив, синтаксис у подобного проще получается.
В итоге, есть и возможности JSON'а и появляется возможность вычисляемых полей/данных/аргументов, в т.ч стандартных( т.е нет функции - делается что-то по умолчанию, есть - вызывается с документированными аргументами и ожиданием ответа с конкретными конфигами )
Ну, в общем - хипстеры изобрели sendmail.mc. Браво, бис!
Добавляй в поле любого значения. json в котором одно поле тип, например type, а другое значение, например value. Да тип придется писать текстом, ну а что делать.
А почему нельзя было считать то, что записано цифрами - числом?
И если бы я писал программу, то эта логика параметров была бы просто внутри самой программы, думаю. Зачем для конфигурации нужно явно знать тип данных смотря на текстовый файл?
> А почему нельзя было считать то, что записано цифрами - числом?000 -- что за число?
Тебе, гуманитарию, это не понять. Но это 0.
Спешу разочаровать, мсье гейм-аналитик не угадал даже систему кодирования.
> Зачем для конфигурации нужно явно знать тип данных смотря на текстовый файл?Чтобы знать, что туда можно вписать, а что нельзя.
К.О.
И как это решает XML, если нет схемы?
>А почему нельзя было считать то, что записано цифрами - числом?потому что получится гребучий эксель, который теряет начальные нули )
Не, подход к конфигурированию там целиком с Openbox унаследовали
JSON похуже чем XML для конфигурации, проверено на собственном приложении.
XML головного мозга.
JSON вообще не конфигурация, а представление данных, для обмена например.
Чтобы перегнать его, например, в XML надо применить к каждому свойству JSON что-то типа/boolean|number|undefined|null/.test(typeof value) ? value.toString() : value
> JSON вообще не конфигурация, а представление данных, для обмена например.
> Чтобы перегнать его, например, в XML надо применить к каждому свойству JSON
> что-то типа
> /boolean|number|undefined|null/.test(typeof value) ? value.toString()
> : valueЧолхан учи русский, там написано "для конфигурации". Советую начать с предлогов.
Спасибо за совет! Судя по всему, ты понял, язык все-таки способ передачи информации, а не ДЛЯ пустой болтовни ))
Ого, сколько боли ты причинил фанбоям json, судя по минусам...
Потому что это синдром утёнка, не иначе. Лично я для хранения конфигурации использую одновременно json, yaml и msgpack и из них только yaml предполагает ручное исправление. Кроме того, это была единственная причина его использовать, json не очень удобно писать вручную, а мне это нужно делать постоянно. Json для передачи по сети и msgpack для сериализации локальных данных. Но отличий между ними не так чтобы и много. Зачем тащить xml туда где в нём нет никакой нужды?
А я использую пары ключ-значение, разделённые знаком равенства. Ели теперь я буду минусовать всех, кто использует json и приводит аргументы в его пользу, я буду таким же идиотом, как те, кто минусанул коммент о преимуществах XML.
> А я использую пары ключ-значение, разделённые знаком равенства. ЕлиКак ты хештейблы с вложенными списками записывать будешь?
Да-да! И html-шаблоны с мамой клянус! Савсэм чуть-чуть js-кода! не положишь. И svg-файл текстом не запихнешь! И 10 строк с генерацией констант на python'е (не, так-то сломаться не должно - но будешь yaml'ину в кубер класть - пробелы посчитай, бро!) не вставить - в общем, плохой формат, не годный.
Опять передёргивания. Например, в yaml это выглядит вот так, это десериализовывается в очень удобный хэштейбл. Десериализовывается, не парсится! Это важно.
key1_1:
- list1_1
- list1_2
key1_2:
key1_2_1:
key1_2_1_1
- list2_1
- list2_2
key1_2_1_2
- list3_1
- list3_2
key1_2_2:
key1_2_2_1
- list4_1
- list4_2
key1_2_2_2
- list5_1
- list5_2
А вот не надо массив данных для инициализации состояния объектов "конфигурацией" называть, и в конфигурационные файлы пихать - тоже не надо.
И думать, что вывернутая мехом внутрь и сериализованная в json часть внутренней логики программы это "конфигурация" - не стоит. Это классическое фигак-фигак, конфигуратион-из-зе-код-кукарек и в продакшон, а там дева-песики распедалят.
Зависит от сложности. Да, ровно это же делают и через ini, но такие данные представленные в виде лапши хуже структурированы и сложнее как для пользователя, так и для разбора в коде.
И снова "Чем грузины!"
С тем, что афедроном можно писать хоть ini, хоть xml, хоть json, хоть yaml/toml/все-что-угодно никто не спорит.
Не понятно нахрена вообще использовать для целей написания афедрон? В ответ на этот простой вопрос тебе начинают рассказывать, как плохо продукт афедронной деятельности умещается в "плохой, нинужный" формат и как хорошо и удобно (с ide, препроцессором, форматтером и линтером) этим продуктом можно обмазаться с ног до головы в три слоя.
>ide, препроцессором, форматтером и линтеромТак разве это я предлагал ини? Как я уже сказал, ямл из всех наиболее простой и удобный со всех сторон для пользовательских данных и конфигурации, жсон самый универсально-понятный и лучше всего подходит для передачи по сети, а мсгпак наиболее эффективен. Нет универсального инструмента на все случаи, но, при таком разделении, как у меня, всё происходит наиболее красиво и успешно. Ини же никаким боком кроме как для самых простых случаев переопределения умолчательных параметров пользователем не подходит. Если от пользователя ожидается сколько-нибудь сложная конфигурация, ини моментально превращаются в нечитаемую лапшу с кучей ошибок, а код становится нагромождением всякой дряни. Хмл же просто легаси и блоатед, и, кроме случаев, когда софт выдаёт поток тагированных данных с которыми придётся работать посредством XSLT (что весьма удобно в ряде ситуаций), он не подходит, и уж точно этот формат не для ручного вмешательства пользователем, что ограничивает применимость. Жсон же в то же время более чем подходит для модификации руками, для ипц (особенно между разными стеками), для сохранения конфигурации на диске ("не для пользователя"), для чего угодно.
Тоже мне, проблема. Например, вот так:
hash=/path/to/file
Или так:
hash=name_of_table_in_DB
> Зачем тащить xml туда где в нём нет никакой нужды?так говорите, будто json имеет какие-то приемущества
> Ого, сколько боли ты причинил фанбоям json, судя по минусам...Каждая обезъянка считает, что она самая сообразительная, мы не будем мешать им заблуждаться.
Примеров когда JSON становится слишком монтсруозный и плохо читаемый вполне себе не мало.
Это конечно не значит что его нельзя использовать в каких-то случаях. К примеру в dotnet System.Configuration уже JSON, а не XML, и даже взлетел, но других примеров таких я не знаю.Поэтому в целом как general rule для описания сложных конфигураций с большим количеством данных XML препочтительнее. Конечно нужно создавать тестовые семплы и смотреть что получается.
Большинство моделей данных это XML и Sybase PD не даст спистеть...
Было дело писались 3 форматтера (билдеры <-> директор) для сериализации кастомных данных - JSON, XML, и бинарный (первых два для ручного редактирования). JSON в итоге получался не читаемый, редактировать его вручную просто не было никакого желания, особенно если важен порядок следования ключей, который не сохраняется в JSON объекте и начинаются бубны с массивами и аттрибутами order/position/index - сплошная туфта. В итоге отказались от поддержки JSON формата.
Кстати можно вспомнить xproj от VS2015 и новый xml-based csproj, который пришел ему на смену.
Глянуть один и второй и понимаешь что первый - не читаемый булшит. А 2 проекта с одинаковыми именами наглухо клали всю их "стройную" модель )))
В итоге индустским фанбоям пришлось слюни с монитора вытереть и вернуться к модификации оригинального msbuild используещего XML.Мне иногда хочется, чтобы нельзя было поставить минус без аргументов, без ремарки.
Чтобы сразу было видно тех, кто "Марiя Алексова, 2 года пишу джейсоны".
А где очерёдность ключей "в памяти" гарантирована? Кажется, это UB какое-то, сломается при следующем обновлении тулинга. Сортировать жсон не обязательно, это опционально. Он записывается именно как он представлен в памяти.Из написанного понятно, что ты живёшь в своём отдельном уютном мирке вендоразраба. В этом нет ничего плохого, но, пожалуйста, прекрати делать вид, что знаешь, как делать надо, или как делать лучше.
> А где очерёдность ключей "в памяти" гарантирована? Кажется, это UB какое-то, сломается
> при следующем обновлении тулинга. Сортировать жсон не обязательно, это опционально. Он
> записывается именно как он представлен в памяти.
> Из написанного понятно, что ты живёшь в своём отдельном уютном мирке вендоразраба.
> В этом нет ничего плохого, но, пожалуйста, прекрати делать вид, что
> знаешь, как делать надо, или как делать лучше.порядок следования в XML может быть определен
<xs:element name="compElement">
<xs:complexType>
<xs:sequence>
<xs:element name="ele1" type="xs:string"/>
<xs:element name="ele2" type="xs:string"/>
<xs:element name="ele3" type="xs:string"/>
<xs:element name="ele4" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>Так что Мария иди в анус.
Маня, это не хештейбл.
> Маня, это не хештейбл.а кто что говорил про hashtable? притом в текстовом файле.. лол
Ты и говорила про ключи, подразумевая сериализацию хештейблов. И тут внезапно оказывается, что речь-то была совершенно не об этом. А в таком случае, последовательность элементов массива в жсоне никак не меняется при записи, и вообще не понятно о чём тут говорить и зачем. Кроме того, валидировать жсон можно ровно так же в процессе загрузки, зато экономия и эффективность очевидны.
И, кстати, ничего не мешает ровно так же использовать список вместо словаря в жсоне, там точно так же сохранится очерёдность. Только это будет {'ce1':['e1','e2','e3','e4']} -- посчитай сама недостатки при таком подходе.
Не фанбоям json, а хейтерам xml. Я всей душой ненавижу xml, совершеннейший убожественный бред сивой кобылы, который ещё может и годится для разметки текста (Markup Language), но для конфигов, для хранения произвольных данных существуют гораздо лучшие решения. В том числе и json, но помимо json'а, есть же sql, yaml, да хоть тот же csv.
Вкусовщина чистой воды, имхо. Для хранния произвольных данных ничто не лучше, всё имеет свои сферы применения. А с XML удобно работать с помощью XQuery. Есть ещё XSLT, но я его пока не ковырял за ненадобностью.
> Вкусовщина чистой воды, имхо. Для хранния произвольных данных ничто не лучше, всё
> имеет свои сферы применения.Угу. Для XML такой сферой является разметка текста. Не конфига.
>А с XML удобно работать с помощью XQuery.
На самом деле не удобно. XML и библиотеки к нему мне всегда напоминали Java тем насколько там всё погрязло в оверинжиниринге. Я хочу взять и сделать что-то типа:
Config cfg = read_cfg("~/.my-config");
Theme theme = cfg.get("app").get("theme").or(DEFAULT_THEME);Что-то типа, не обязательно именно так. Можно скажем так:
Theme theme = cfg.get("app/theme").or(DEFAULT_THEME).
Или
theme_t theme = json_get(cfg, "app.theme") || DEFAULT_THEME;
Или даже
(defparameter *theme* +default-theme+)
(unwind-protect
(eval (read "~/.my-config"))
(msg "There is an error in your config, so if you see something weird, try to fix it in the config"))Как нибудь так, без всей вот этой хрени, с именами функций по 50 символов, которые принимают не меньше пяти аргументов, половина которых задаёт режим работы функции, от чего начинаешь задаваться вопросом: нахрена было 50 символов в имя пихать, чтобы потом уточнять ещё режим работы функции аргументами? И при этом, одной функции всегда будет мало, надо будет сделать по три вызова на каждый запрос. Ах да, ещё и парсинг xml радостно и необратимо обломается, при малейшей ошибке или несоответствии dtd.
XQuery крайне неудобен без обёртки над ним. Это корпоративная хрень для разработки корпоративных аппликух на Java, которые радуют глаз эффективного менагера. Даже в javascript никто не использует XQuery, предпочитая всякие обёртки над ним, css-селекторы и проч.
Это с точки зрения API. С точки зрения пользователя xml-конфига всё не сильно лучше: объём полезной информации в конфиге минимален, потому что по большей части там сплошные угловые скобки, слеши, многократные повторы имён тегов... То есть захламлено всё так, что дальше некуда. Это мутное разделение на атрибуты и контент тега -- зачем делать и так и эдак? Никто до конца не понимает, потому у каждого своё понимание, что пихать в атрибут, что в контент: атрибут вроде удобнее, он меньше писанины требует, но нет ведь у всех какие-то глубинные идеи, типа one-to-one отношение, или one-to-many, и "может быть когда-нибудь понадобится one-to-many, поэтому давайте пользователи прямо сейчас начнут страдать от ещё одного вложенного тега в конфиге вместо няшного атрибута, а если one-to-many не понадобится никогда и страдания будут бесцельными, то нам покакать на них".
Композитный сервер с возможностями оконного менеджера? Это бомба!
Замедленного действия
Очередной велосипед с квадратными колёсами.
Выглядит интересно. Желаю проекту успешного развития.
Смотрится интересно, в общем посмотрим во что выльется =)
Wmaker лучше запилите, а еще лучше нечто где будут проекты, а в проектах множество рабочих столов. Выбираешь/создаешь в меню проект и переключаешься на его рабочие столы - должно быть удобно вести множество проектов длительное время
Три буквы: KDE.
Несколько букв: KDE с Wayland УГ.
Это вопрос времени.
Это как послать на.
Уже есть - Activity в KDE называется
Очередная попытка, в то время как оригинал просто работает.
Надеюсь иксы продержатся в линях хотя бы до 30-го года, чтобы продолжать спокойно работать без излишней блоатвари.
А к тому времени возможно и БСД допилят до юзабельного использования в роли десктопа.
с разморозкой, BSD уже давно допилили, называется MacOS
Платиновый огороженный огрызок.
Уж лучше БЗДя тогда.
Есть у нас у пары разрабов, зачем они опустошили свои карманы понять невозможно.
Для разработки макакось сливает линю по всем параметрам.
>А к тому времени возможно и Haiku допилят до юзабельного использования в роли десктопа.
Хайку не юникс лайк, поэтому не подойдет.
Да и думаю никогда ее не допилят, где они возьмут драйвера неясно.
Те же БСД тянут дрова из линя, хоть так, а то вообще мало на чем можно было бы запустить.
> Те же БСД тянут дрова из линя,Правда, пермиссивщина в этих дровах немного намекает на то, что дрова были сделаны _для_ линя немного не самими (и уж тем более не местными) пингвиняшами.
И гордое задирание гузочки в этом случае немного непонятно - это все равно что вендузятникам гордиться наличием дров от производителя ...> хоть так,
Учитывая количество костылей и подпорок в Ынтелловских дровах под каждую конкретную версию, сами пингвинятки дрова к закрытому GPU тоже не осилят. Потому что оно вроде как "опенсорс", но без знания специфики закрытой железки пользы от этого - около нуля.
Но вместо того, чтобы возмущаться насчет креновой политики штеуда или хотя бы более трезво смотреть на этот фарс, местные пингвинята почему-то гордятся неимоверно, повторяя как мантру "Бе-бе-бе! А мы у господина любимый жена, вот!".
> Правда, пермиссивщина в этих дровах немного намекает на то, что дрова были сделаны _для_ линя немного не самими (и уж тем более не местными) пингвиняшами.Это значит, что дрова в линуксе ненастоящие? Или нерабочие? Что с ними не так?
> И гордое задирание гузочки в этом случае немного непонятно - это все равно что вендузятникам гордиться наличием дров от производителя ...
У линукса дрова хотя бы присутствуют, и эти дрова делаются для линукса, а не для бзди, бздя тащит дрова из линукса
> Учитывая количество костылей и подпорок в Ынтелловских дровах под каждую конкретную версию, сами пингвинятки дрова к закрытому GPU тоже не осилят. Потому что оно вроде как "опенсорс", но без знания специфики закрытой железки пользы от этого - около нуля.
То есть драйверов на самом деле в линуксе нет? Или они ненастоящие? Или нерабочие? Что с ними не так? А если с ними что-то не так, почему бздя тащит эти драйвера?
> Но вместо того, чтобы возмущаться насчет креновой политики штеуда или хотя бы более трезво смотреть на этот фарс, местные пингвинята почему-то гордятся неимоверно
Дак что с драйверами то не так? Они не работают? Они ненастоящие? В чем фарс?
> , повторяя как мантру "Бе-бе-бе! А мы у господина любимый жена, вот!".
А бздя нелюбимый жена, раз тащит драйвера из линукса? А если она не жена, почему тащит драйвера из линукса?
>> Правда, пермиссивщина в этих дровах немного намекает на то, что дрова были сделаны _для_ линя немного не самими (и уж тем более не местными) пингвиняшами.
> Это значит, что дрова в линуксе ненастоящие? Или нерабочие? Что с ними не так?Это значит ровно то, что написано в тобой же процитироавнном. Просто читать желательно не опой.
>> И гордое задирание гузочки в этом случае немного непонятно - это все равно что вендузятникам гордиться наличием дров от производителя ...
> У линукса дрова хотя бы присутствуют, и эти дрова делаются для линукса, а не для бзди, бздя тащит дрова из линуксаВообще-то, бздя тащит дрова от интеля под ителовский же интырьфейс.
Да и вряд ли вот эти поцы
https://www.nvidia.com/Download/driverResults.aspx/170806/en-us
> FREEBSD DISPLAY DRIVER – X64
> Version: 460.56
> Release Date: 2021.2.25
> Operating System: FreeBSD x64на зарплате у линухофундейшна.
> То есть драйверов на самом деле в линуксе нет? Или они ненастоящие?
> Или нерабочие? Что с ними не так? А если с ними
> прочий бред скипнутЭк тебя припе^W задело ...
> Это значит ровно то, что написано в тобой же процитироавнном. Просто читать желательно не опой.Тогда я вынужден назвать тебя демагогом, потому что тема была про хайку и отсутствие в ней драйверов, в отличие от бзди, ты же начал нести бред про то, что линуксоиды не могут сами написть драйверов
> Вообще-то, бздя тащит дрова от интеля под ителовский же интырьфейс.
Из линукса
> Да и вряд ли вот эти поцы
То есть амуде и интел драйвера не тащит бздя, потому что невидия не на зарплате у линухофоундейшена?
> Эк тебя припе^W задело ...
Ты так говоришь, будто это хужем, чем подгорать от того, что бздя тащит из линукса драйвера
>> Те же БСД тянут дрова из линя, хоть так, а то вообще мало на чем можно было бы запустить.
> Тогда я вынужден назвать тебя демагогом, потому что тема была про хайку
> и отсутствие в ней драйверов, в отличие от бзди,Тогда я вынужден назвать тебя чтецом опой ...
>>> У линукса дрова хотя бы присутствуют, и эти дрова делаются для линукса, а не для бзди, бздя тащит дрова из линукса
>> ссылка на сайт нвидии с драйвером под фрю
> То есть амуде и интел драйвера не тащит бздя, потому что невидия
> не на зарплате у линухофоундейшена?Какой неуклюжий спрыг ...
> Тогда я вынужден назвать тебя чтецом опойНу балаболкой ты от этого быть не перестанешь
> Какой неуклюжий спрыг
Но бздя от этого тащить драйвера из линукса не перестает, те самые драйвера, которые делаются для линукса и для которых в бзде слои совмеестимости пихают
>> Тогда я вынужден назвать тебя чтецом опой
> Ну балаболкой ты от этого быть не перестанешьТ.е. с нвидией в лужу сел ты, а "балаболка" теперь вдруг я. Занятно.
>>> У линукса дрова хотя бы присутствуют, и эти дрова делаются для линукса, а не для бзди, бздя тащит дрова из линукса
>> ссылка на сайт нвидии с драйвером под фрю
> Но бздя от этого тащить драйвера из линукса не перестает,Уныло и все еще неуклюже, попробуй еще раз.
> Т.е. с нвидией в лужу сел ты, а "балаболка" теперь вдруг я. Занятно.Ну то есть по-твоему, раз невидия не на зарплате у линухфоундейшн, то бздя не тащит драйвера от интела и амуде из линукса? Я, кажется, явно задал этот вопрос. Или невиядрайвера как-то влияют на другие драйвера?
> Уныло и все еще неуклюже, попробуй еще раз.
Ну давай еще раз.
От того, что в линуксе драйвера под пермиссивной лицензией, они становятся хуже? С ними что-то не так? Они сломаны? Или они не для линукса? Что с ними не так? Или быть может с ними не так то, что их бздя тащит к себе?
А БСДешники наоборот, штеуду молятся, мол он им с барского стола дрова кидает ням ням очень вкусно.
А вот другие бяки недают.
У Невидии к примеру дрова унифицированы и в принципе один и тот же для всех. Потому не надо домыслов и болтовни про Штеуда. Общественность ничего лучше кроме ньювоу все равно не предоставило. Корпорасты же всё порешали и очень качественно. Надо бы радоваться, но нет, писькамерство на пустом месте присутствует постоянно и это несмотря на то, что тысячи глаз имеют крайне посредственное отношение к запилу дров.
На БСД нет куды.
Сетевухи реалтека работают только с модулем из портов который последние 10 лет нужно было собирать вручную.
Карты челсио вешают систему.
Да и у самого интела сетевые драйвера ломались не так давно.
Куду и на лине надо по-извращаться чтобы включить.) За остальное не скажу - не знаю...
С разморозкой, в BSD всё активнее внедряют Wayland, реализуя возможности, которые есть только в Linux. BSD без линукса - ничто. Как десктоп разумеется.
> С разморозкой, в BSD всё активнее внедряют Wayland, реализуя возможности, которые есть только в Linux.Это в перепончатых мечтах - "возможности, которые только в Линукс!!", а в реальности - реализовали интерфейс под метровые шурупы с нестандартной резьбой (тот же evdev), которыми реализацию "замены иксам" прикрутили к пингвинчику.
(рандомный) патч для поддержки фри, 2013 год:
https://lists.freedesktop.org/archives/wayland-devel/2013-Fe...
> event-loop: Add support for BSD???s kevent() instead of epoll()ответ:
https://lists.freedesktop.org/archives/wayland-devel/2013-Fe...
> Would it be a better overall solution if we simply replace timerfd and signalfd with a more generic architecture and then move the guts of the event loop to poll or select?Но нет. "Лучше сначала реализовать архитектурную абстракцию, в которую и вынести ОС специфичный код!" (ну да, и правда - это ведь не задача разработчиков "замены", у них оно и так работает)
и на этом усе ... опять у местных перепончиков "бздуны не участвуют в развитии никсовых графических подсистем, а потом удивляются и ноют, что поезд ушел без них!"
Ссылки порезало:
> (рандомный) патч для поддержки фри, 2013 год:https://lists.freedesktop.org/archives/wayland-devel/2013-Fe...
> event-loop: Add support for BSD???s kevent() instead of epoll()
> ответ:https://lists.freedesktop.org/archives/wayland-devel/2013-Fe...
> Would it be a better overall solution if we simply replace timerfd and signalfd with a more generic architecture and then move the guts of the event loop to poll or select?пофиксил.
А бздунов никто и не спрашивал. Захотели - реализовали под Linux и его особенности. Что-то не видно независимости в вашей фре, без DRM/KMS и линуксовых драйверов. Слабо своё написать?
>> Wayland is the next-generation display server for Unix-like systems,
> А бздунов никто и не спрашивал. Захотели - реализовали под Linux и его особенности.Какое бесподобное переобувание в прыжке!
> Что-то не видно независимости в вашей фре, без DRM/KMS и линуксовых драйверов. Слабо своё написать?
И "своего" - у пингвиняток только нуво, который известно как работает.
Впрочем, в его разработке лично ты тоже вряд ли участвовал (нет, ношение маечки с пингвинчиком и оттопыривание гузочки - за разработку не катят), как бы не старался примазаться.
А в таком случае - ты бы еще закрытым блобиком нвидии погордился бы.
> Это в перепончатых мечтах - "возможности, которые только в Линукс!!", а в
> реальности - реализовали интерфейс под метровые шурупы с нестандартной резьбой (тот же evdev), которыми реализацию "замены иксам" прикрутили к пингвинчику.Это просто такое специфичное понимание
>> Wayland is the next-generation display server for Unix-like systemsнапоминает
"Any customer can have a car painted any colour that he wants, so long as it is black."
В BSD очень даже самостоятельное, независимое сообщество.
Вы бы на фряхе месяц посидели бы, прежде чем такое говорить.
Я как сидящий на фре 14 лет заявляю, что там всем заправляет пара охреневших корпораций.
А "сообщество" в перерывах между поливпнием грязью любых внешних инициатив лижет жопы спонсорам.
Похоже на что-то бессмысленное.Но раз авторам нужно, значит нужно.
Почему оконный менеджер должен явно поддерживать xwayland, скриншоты и так далее?
Потому что в этом суть вейленда. Не быть суперклассом.
Потому что это суть вяленого:не уметь ничего. Сделай все сам.
> Потому что в этом суть вейленда. Не быть суперклассом.И мы приходим к странному супер WM :-(
Теперь прогу надо компилить под каждый оконный манагер... жесть.
Lab WC? Хмм…
композиты, отрисовки, клиент-серверы... ребят, вам не надоело? Что за чудовищные задачи решает Линуnс, что ему нужны все эти заморочки? (причём глобальные такие, повышающие сложность НА ПОРЯДОК)Вон, венда - 30 лет живёт на простой идее: экран, пиксель. И ВСЁ РАБОТАЕТ, прикинь! И видео, и игры, и удалённый стол... "чего тебе ещё надобно, собака?!" (ц) И.В.Грозный
Сделайте уже простые дрова - экран, прямоугольник, переместить регион, вывести глиф и т.п. Далее поверх будет обычный Window Manager - он перемещает окна, передаёт фокус. Над ним - Desktop Environment - вот эти все tray, window header, task bar. И к ним цепляются плагинами уже непосредственно контролы - кнопки-тулбары-пассатижи.
Получаем невероятную гибкость, причём любой элемент стека можно заменить, соблюдая API.
> Вон, венда - 30 лет живёт на простой идее: экран, пиксель. И ВСЁ РАБОТАЕТ, прикинь!Наивный чукотский юношь вообще не в курсе, что там в винде, ему кажется, что там всё просто и всё работает.
Разница между графической подсистемой в Windows 95 и Windows 10 примерно как между велосипедом и Boeing 777.
Колёса есть и там и там, да.
Кстати о птичках. Что есть по теме помимо «Программирование графики для Windows» за авторством Фень Юань (1070 страниц), которая малость поверхностна и слегка устарела?
первый выпуск кейлогера для labwc: https://github.com/Aishou/wayland-keylogger
Хейтеры всё никак не успокоятся. То что по ссылке - это не кейлоггер. Дрю Деволт уже это объяснял.
если это выглядит как кейлогер, крякает как кейлогер и логирует кнопки как кейлогер, то скорее всего это кейлогер
> если это выглядит как кейлогер, крякает как кейлогер и логирует кнопки как
> кейлогер, то скорее всего это кейлогерДа, только он не для labwc.
А теперь внедри его в десктоп на Wayland и перехвати все нажатия клавиш. А не заставляй самому это компилять и запускать
ждём интеграции в проприетарный софт, а то видите ли это проблема в ld_preload, а не в вялом.
Мне больше статья Дрю про Wayland нравится.
Поржал!
Во-первых, Fluxbox!
Во-вторых, ЧТО ЭТАА-А-А!?
Я порой вздрагиваю от местных новостей :)
>В качестве основы используется библиотека wlrootsСразу нафиг.
Ну так как? Wayland вышел из версий альфа? Или всё ещё в песочнице?
Спрашиваю с барских иксов.
Да уж, вместо того что бы улучшать DE, теперь все дружно реализуют один и тот же функционал 100500 разными способами, при этом рандомно ломающимся на разном софте.
Создание Wayland и миллиона DE - было гениальным шагом со стороны MS, чтобы раз и навсегда закопать десктопный линукс. :)
> В будущем планируется ... добавить возможность размещения экранных индикаторов (osd) и интерфейса переключения окон в стиле Alt+Tab.ждун.jpg
Да, конечно, версия 0.1.0. Можете не напоминать.
Ссылка неправильная в статье, https://github.com/labwc/labwc, а не https://github.com/johanmalm/labwc.