Comments 343
Ну так-то, даже участие в разработке линукса не запрещает использовать Mac или Windows :) У каждой ОС свои плюсы. Это ведь не религия)
готовность для десктопов — это очень низкая оценка реальной пригодности для 100% юзеров в отличии от например хорошо продуманного UI и отличного UX.
Пока не видел доказательств того что ездить на аккумуляторе безопасной для экологии в целом(не для конкретного места) чем на двс
При чём здесь аккумулятор? Велосипед же!
Велосипед имеет слишком много ограничений в использовании — погода, здоровье(возраст), температура, перепады высот(в связке с другими факторами), расстояние и т.п.
А для авто всё сложно, если бы можно было использовать ценовую оценку (у.е./км.) с учётом полной стоимости авто(даже без субсидий) то электротранспорт пока проигрывает, но так делать нельзя т.к. мы не берём в расчёт те самые последствия для экологии (в т.ч. утилизацию, хотя формально в моделм с ДВС этот сбор часто заложен).
Как объективно в нашей реальности оценить суммарный вред на км. пробега я увы не знаю, но жить в чистом городе приятней чем в грязном даже если для экологии планеты в целом от этого будет хуже.
Идея свободы в этих лицензиях показалась Стиву Балмеру "вирусной", так как он считал что программа какой либо не была с этой лицензией не станет приносить доход, а труд который вложен в Linux и в сообщество пользователей Linux являлись ему средством смещения позиции Windows на рынке что и назвал он "раковой опухолью". Так как он не понимал идей свободы и считал что закрытый софт приносит гораздо больше средств чем пожертвование разработчикам свободного софта. (Моё личное мнение которое не может совпадать с мнением Стива Балмера и сообществом пользователей Linux.)
Мне кажется, вопрос не в фанатизме, а в публичности — когда публичные действия "лица" некоммерческой организации противоречат одной из целей этой организации. Просто сидеть и контрибьютить в ядро можно и с Windows, если уж так припёрло. Это как актриса публично заявляет, что поддерживает общества по защите животных — но при этом ходит в натуральной норковой шубке.
Как говорится «неверен в малом и во многом неверен» (с)
Ps Мак Форевер :D
Потому что там есть программы!
Давайте конкретику? Чего вам как программисту на js не хватает для повседневной работы и отдыха? Браузеры — есть, видео плееры — есть (vlc), аудио плееры — есть (clementine), почтовые клиенты — thunderbird в целом выглядит отлично. Для офиса у вас есть и старый интерфейс офиса (LibreOffice) и новый вариант (WPS Office).
А вообще хотел бы что то типа воркспейсов по группам.
Вроде такое умеет kde + activities.
Обычный пользователь хочет просто сесть и работать. Он хочет познакомившись с парой программных продуктов ОС уже иметь некоторый пользовательский опыт работы со всей ОС и примерно знать что ему от нее ожидать. В Линукс ты не можешь быть уверен в пользовательском опыте: слишком много разных программ которые выглядят и ведут себя по разному(Разве что консольные утилиты тут молодцы — в этом и сила юникс подобных систем и слабость винды). Давайте просто посмотрим на редакторы текста. Обычная альтернатива блокнота в Линукс Дистрибутиве для обычного пользователя, ничего сверхъестественного, просто человек хочет взять и что-то записать и сохранить, все. Что мы по сути имеем? Давайте ответим хотябы на вопрос: А что собственно запустится? Что пользователь ожидает увидеть? Ладно, не важно. После блокнота пользватель открывает любую другую программу, что он видит? Он видит уже совершенно другой интерфейс который прикидывается нативным. Да он использует те же контроля и темы. Но он вообще по другому продуман. У пользвателя нет уже такого же пользовательского опыта. Все. Он потерялся. Он не может теперь ожидать чего-то. Он не может интуитивно работать следовательно — ему неудобно и неинтересно находится в этой ОС. С этой проблемой с горем пополам как-то справляется элементари и по идее что-то получается у гнома. Все. Остальные придумывают максимум свою DE. Гномы, Кеды, Минт, Юнити и т.д. Оболочки это здорово, но когда нет экосистемы они мало чего стоят. Они только внешне показывают что они современная десктопная ОС а на самом деле они ими только прикидываются
Вы бы хотя бы привели бы mac os в пример, тогда я бы возможно, поверил. Но повседневно используемые мной программы на windows, типа firefox, google chrome, sublime, notepad, explorer, steam имеют вообще разный интерфейс.
Даже у самой windows я знаю как минимум два типа программ, которые предлагают из коробки — обычные приложения с windows компонентами и вот эти плиточные.
Более того, сейчас windows 10 выглядит настолько разной сама по себе, включая неконсистентные настройки, когда настройка bluetooth у меня в виде новый плиток, а настройка девайсов старый интерфейс из windows 7, что такой эффект я могу получить только запустив одновременно несколько de на linux.
Да, проблема, которую вы описываете актуальна, но она не решена даже на mac os (firefox, safary, google chrome например), что уж говорить о других системах
Браузеры всегда были комбайнами и ведут своб историю задолго до того как десктопная ОС стала представлять из себя единое окружение для поьзователя, когда начали задумываться о дизайне и пользовательском опыте. Браузеры в этом плане похожи на саму ОС. Они представляют из себя собственное окружение и тем более кроссплатформенное поэтому они хотят выглядеть одинаково и одинаково удобно на любой ОС как раз для того же самого о чем я и говорил выше. Чтобы перейдя на Линукс с Винды Хром оставался Хромом. и т.д.
Никто не говорил что Винда или Мак идеальны. Но они стремятся к этому, у них есть гайдлайны. У винды все еще идет переход к единому интерфейсу (он начался с 8 версии) и естественно этот процесс не быстрый(тем более что флюент только недавно представили). Но он зотябы ЕСТЬ. Да есть двойственность, но это наследственность, которую устраняют с каждым обновлением. И кстати одна из причин медленного перехода это как раз именно для того чтобы не отпугнуть пользователя. Как вы думаете как много огорченных пользователей ждало бы майкрософт есои бы после 7 сразу был бы полный флюент дизайн? Да как бы это красиво не былов се бы плюнули на это так как ниому не хочется переучиваться полностью ради простой работы в ОС. Никто не будет знать что вообще где находится.
Но опять же там оно хотябы есть. Любое приложение знает что такое проводник и может в него встроится. Может сделать превью или меню правой кнопки мыши. Оно может поставить обои или даже сделать программу для вставки видео обоев. Каждое приложение может сделать оповещение и оно будет одинаково отображаться,
Что мы имем на линукс? Ничего. Потому что нет ничего единого. Вообще нет единого решения. Есть единые оболочки, но на этом все. Опять же приведу в пример хорошего тона Элементари(Возможно мой кругозор немного узок но я просто могу рассуждать осознанно об этой ОС а не о других так как имею дело именно с ней), у них есть гайдлайны, у них есть пакты контролов специально для их ОС которые могут использовать все в своих программах. И это РАБОТАЕТ! Люди уже делают программы специально для этой ОС и специально для их магазина приложений. И эти программы выглядят точно также как если бы их писали разработчики Элементари. И они прекрасно вприсываются в систему и я всегда знаю что меня ждет когда я включаю приложение. И все эти приложения даже специально курируются прежде чем попасть в магазин, это замечательно и этого я и жду от хорошей ОС. Я вижу в этом инструмент которым я хочу польховаться, потому что мне приятно находится в квартире с дизайнерским ремонтом где вся мебель и стилистика подходят друг другу а не в в общаге с мебелью с барахолки. Да это дешево, и эти крутые вещи делали куча людей, но это комуналка где у каждого своя мебель и свои вкусы, тиебе приходится мирится с соседями
У винды все еще идет переход к единому интерфейсу (он начался с 8 версии) и естественно этот процесс не быстрый(тем более что флюент только недавно представили). Но он зотябы ЕСТЬ
И он не работает. И не будет работать лет еще 10, пока у windows 7 почти 50% рынка.
Ничего. Потому что нет ничего единого. Вообще нет единого решения.
Нет, есть freedesktop спека, которая реализована везде. Даже если какой-то кусок не работает, то для него есть или надстройка, или он просто не сработает, но с ошибкой не упадет.
Для обоев вообще есть возможность ставить их даже в тех DE, которые по умолчанию не умеют , например, openbox.
С оповещениями аналогичная штука, у вас есть та же freedesktop спека в которой написано, как оно должно работать. Да, по настоящему красивые уведомления вам так не сделать, ну так этим страдает все. Я вот сижу на awesome WM, которое никем официально не поддерживается, и у меня вполне унифицированные уведомления от slack и skype.
А что касается приложений, окей, отложим браузеры и не следование guideline самой OS (хотя это уже зашквар). IDE, игры, простые инструменты (FarManager?) все выглядят по разному. Возможно, кому-то это не нравится, но из этого никак не выбраться.
KDE и Gnome с коробки тоже вполне выглядят консистентно, даже есть возможность подменять темы QT, что бы приложения выглядели как приложения на GTK. А если уже говорить про приложения, которые были поставлены дополнительно, вы упускаете, что, скажем, вместо "Проводника" я вполне могу использовать какой-то TotalCommander и все, всякие встраивания в проводник мне уже не заметны.
И он не работает. И не будет работать лет еще 10, пока у windows 7 почти 50% рынка.
Оно работает и будет работать уже сейчас. Я вообще не понимаю к чему вы привели долю рынка. Windows это продукт и этот продукт развивается как раз чтобы решать проблемы. Очень странно говорить о переходе к новому интерфейсу говоря о продукте который является предыдущей версией и в нем естественно не будет этих изменений. А перейти на 10 перейдут в любом случае, так как вскоре и игры и приложения перестанут поддерживать 7 из-за технологических ограничений а 10 поставляется как сервис и больше новых версий не будет так что это просто вопрос времени. И да это будет долго. Но никак не 10 лет. Максимум года 4-5 в худшем случае.
Нет, есть freedesktop спека, которая реализована везде. Даже если какой-то кусок не работает, то для него есть или надстройка, или он просто не сработает, но с ошибкой не упадет.
Ага расскажите мне о вашей спецификации когда файловые проводники гнома и кде и элементари работают по разному и что часто нужны как раз надстройки чтобы сделать меню внутри проводника и встроить свою программу в него.
Для обоев вообще есть возможность ставить их даже в тех DE, которые по умолчанию не умеют, например, openbox.
Ага. Пользователь полезет искать консольную комманду чтобы поставить обои.
С оповещениями аналогичная штука, у вас есть та же freedesktop спека в которой написано, как оно должно работать. Да, по настоящему красивые уведомления вам так не сделать, ну так этим страдает все. Я вот сижу на awesome WM, которое никем официально не поддерживается, и у меня вполне унифицированные уведомления от slack и skype.
Мне как пользователю не интересно как оно написано вообще. Пусть хоть испишуться. Мне важно чтобы оно было реализовано. И я говорил о том чтобы ОС (т.е. уже готовый продукт), так как конечный пользоватеь сидит за одним продуктом а не за многими, реализовывал единый вид и единый интерфейс для этого. Во многих из них оповещения и правда УЖЕ(с недавнего времени относительно) работают неплохо.
А что касается приложений, окей, отложим браузеры и не следование guideline самой OS (хотя это уже зашквар). IDE, игры, простые инструменты (FarManager?) все выглядят по разному. Возможно, кому-то это не нравится, но из этого никак не выбраться.
Что из этого является программой этой ОС? Что из этого является инструментом обычного пользователя? Как игры можно называть пользовательской программой? Вы когда последний раз видели обычного юзера который бы пользовался FAR или Total Commander? Они все поголовно кликают мышкой да перетаскивают файики и распаковывают правой кнопкой мыши. Не подменивайте понятия того что все можно подстроить под себя и понятия удобства обычного поьзователя. Все эти программы (кроме игр) вообще никаким боком не относятся к обычной рутинной работе и обычным пользователям для которых собственно и идет продвижение Linux.
Даже есть возможность подменять темы QT, что бы приложения выглядели как приложения на GTK
Ага и программы начнут ПОДРАЖАТЬ облику приложений. Облик и гайдлайны это не одно и тоже. Т.Е, программы будут иметь похожий цвет такие же кнопочки но выглядеть они все еще будут как программы в шкуре ГТК. Посмотрите как себя ведут Программы в разных DE и вы увидите как жутко это иногда выглядит. gnome builder на гноме и на убунту это две разные вещи. На гноме он выглядит прекрасно а Убунту из-за того что старается под себя стили подстроить уродует его до безобразия, хотя он и так выбивается из стилистики ОС
Оно работает и будет работать уже сейчас. Я вообще не понимаю к чему вы привели долю рынка. Windows это продукт и этот продукт развивается как раз чтобы решать проблемы. Очень странно говорить о переходе к новому интерфейсу говоря о продукте который является предыдущей версией и в нем естественно не будет этих изменений. А перейти на 10 перейдут в любом случае, так как вскоре и игры и приложения перестанут поддерживать 7 из-за технологических ограничений а 10 поставляется как сервис и больше новых версий не будет так что это просто вопрос времени. И да это будет долго. Но никак не 10 лет. Максимум года 4-5 в худшем случае.
Доля на рынке — это к тому, что никто не будет писать приложения под технологии, которые не поддерживаются на основной системе. Ну и да, какие новые технологии? Близзард дропнули поддержку XP только в этом году, хотя та вышла в тираж аж в 2014. Поэтому никто не пользуются новыми штуками из Windows 10, так как они сужают рынок из 90% аж до 20% и вы получаете такую же проблему, как в случае с linux, но только менее острую.
Ага расскажите мне о вашей спецификации когда файловые проводники гнома и кде и элементари работают по разному и что часто нужны как раз надстройки чтобы сделать меню внутри проводника и встроить свою программу в него.
А что мне мешает использовать на windows totalcommand и получать такую же проблему?
Ага. Пользователь полезет искать консольную комманду чтобы поставить обои.
Это к тому, что возможность работать с обоями унифицировано у вас есть. И эту программу я привел как пример.
Мне как пользователю не интересно как оно написано вообще. Пусть хоть испишуться. Мне важно чтобы оно было реализовано. И я говорил о том чтобы ОС (т.е. уже готовый продукт), так как конечный пользоватеь сидит за одним продуктом а не за многими, реализовывал единый вид и единый интерфейс для этого. Во многих из них оповещения и правда УЖЕ(с недавнего времени относительно) работают неплохо.
Для всех основных дистрибутивов и их редакций такая возможность есть и может быть использована. Она дает возможность добавить нотификацию в духе заголовок + картинка + текст. То, что это не используют разработчики — это исключительно их вина.
Вы когда последний раз видели обычного юзера который бы пользовался FAR или Total Commander?
Каждый раз, когда захожу в печать, например. Потому что нормально пользоваться проводником винды, который не умеет даже в split довольно сложно.
Посмотрите как себя ведут Программы в разных DE и вы увидите как жутко это иногда выглядит.
А кто заставляет использовать программы из разных DE?
Для KDE и Gnome есть комплекты приложений (необязательно входящие в состав самих DE), которые ведут себя достаточно единообразно (не менее единообразно, нежели те же Notepad, Paint и MS Office).
И смешивать их необязательно.
А еще многие программы обзавелись набором интерфейсов в стиле всех популярных DE.
Кстати, я позволяю себе смешивать стили, используя программы, написанные под разные DE, но меня не волнует разница в их поведении. И под той же Windows у меня такая же эклектика творится.
Смотрите, так сложилось, что есть операционная система (как то Linux, Windows, MacOS, тысячи их) и есть «десктопное окружение»/«окружение рабочего стола» — формулировка достаточно размыта. Вся разница в ситуации Linux vs ДругиеОС в том, что эти самые другие имеют по одному десктопному окружению, которые однозначно с ними ассоциируются. В линуксе же десктопных окружений — на любой вкус и цвет, десятки.
А дальше мы плавно подходим к сфере ответственности. Единая среда, одинаковость поведения приложений, пользовательские паттерны, UI/UX и прочее, за что вы так радеете — это сфера ответственности DE, т.е. десктопного окружения. Т.е. сравнивать будет корректно DE Windows vs Gnome или vs KDE vs тот же Elementary (который, к слову, является одновременно и Gnome, и Ubuntu, даже странно сравнения на тему «Ubuntu и Gnome ниочень, а элементари лучше» читать).
И вот если сравнивать тот же Gnome3 vs Windows DE, у винды все будет уже не так радужно.
То что так сложилось это все ясно и никто не отрицает. В чем-то это дает свои плюсы а в чем-то минусы. Я говорил лишь о том почему это все не подходит обычному пользователю.
Давайте разделять Gnome как операционную систему(грубо говоря любой дистрибутив с его использованием Fedora или Suse) и разделять DE.
Все что я выше перечислил это не ответственность DE. Вообще ни разу. DE это часть всего этого. Лишь одна из многих. И Elementary вообще никак нельзя сравнивать как гном и Убунту. Что за глупости. Обычному пользователю абсолютно плевать из чего оно сделано. Да даже мне плевать из чего оно сделано, меня разве что радует apt к которому я привык. Все.
Гном поставляет с собой оболочку для всего. Но тут нет всего. Это красивая оболочка, грамотно сделанная, мне она нравится. Но внутри она пуста(Хотя должен заметить что как и Элементари начальный пак приложений развивается). Но пока еще рано говорить о полном покрытии нужд.
Обычный пользователь и так ныряет в новую для него систему и новый мир а Линукс не делает ничего что помогло бы ему выжить в этом путешествии. Ему часто и так приходится что-то шаманить в терминале если что-то идет не так и на форумах ему также посоветуют что-то написать в терминале, это страшно.
Просто подумайте, почему люди переходя на мак с винды часто даже не хотят возвращаться на Винду а если с Винды на дистрибутив Линукс то люди чаще всего больше никогда не хотят его видеть. Он сухой. Он не хочет быть с пользователем.
Мало какой дистрибутив задумывается о повседневных задачах пользователя(Хотя опять же повторю сейчас к этому по чуть чуть идет), не хотят сделать свой собственный:
- блокнотик который вписывался бы в систему
- почтовик простенький(Пусть его удалят на лучший инструмент, но обычному пользователю уже не нужно будет искать что-то. Он будет рад что есть красивый инструмент который 100% знает систему и хорошо в нее вписан
- Инструмент показа погоды красиво(Гном и Элементари умеют)
- Архиватор, который встроен в систему и интегрирован с проводником максимально.
- Просмоторщик картинок, видео
- Аудио плеер
- Максимально просто редактор картинок
- Замены разовых инструментов (звукозапись, вэбкамера, калькулятор, будильник)
И ведь большинство из этого сделать вообще не проблема. На столько просто на сколько это возможно. Это же Линукс! Все компоненты есть нужно только обернуть их в нужный фантик и интегрировать с своей же системой. Никто не будет заставлять пользоваться именно этими инструментами, но наличие их для пользователя будет колоссальным и на столько красивым что все скажут спасибо и все захотят дописывать свои программы для этой ОС. Я вот и сам понемножку пишу для Элементари так как мне приятно писать для целой экосистемы(пусть небольшой, но уже экосистемы), а разрозненности и так везде хватает, я не хочу жить в зоопарке из разнообразия. Я хочу видеть целостность и однообразие, а так же чтобы простые действия были действительно простыми и мне не нужно было идти и качать что-то, причем это что-то будет инородным
Я не знаю, где вы такие дистрибутивы берете.
Берем дистрибутив, основанный на KDE5.
Блокнот — kwrite и более продвинутый kate
Почтовик — kmail
Архиватор — Ark
Картинки, аудио, видео — gwenview, amarok, smplayer
Браузер — забыл уже, что они там вместо konqueror в пятерке засунули
Редактор картинок — kolourpaint
Калькулятор — kkalc
Запись CD — k3b
Будильник — в составе korganizer
И т.д, и т.п.
Причем все перечисленное входит в состав KDE5 и имеет единообразный интерфейс.
В гноме примерно то же самое. Есть "родной" мнмальный набор программ.
.IgnisNoir.… Все компоненты есть нужно только обернуть их в нужный фантик и интегрировать с своей же системой.… Я вот и сам понемножку пишу для Элементари так как мне приятно писать для целой экосистемы(пусть небольшой, но уже экосистемы), а разрозненности и так везде хватает, я не хочу жить в зоопарке из разнообразия. Я хочу видеть целостность и однообразие, а так же чтобы простые действия были действительно простыми и мне не нужно было идти и качать что-то, причем это что-то будет инородным
Хорошо поставленный вопрос содержит половину ответа. Здесь дискуссия подошла к логическому концу и Вы сами попались в эту ловушку. Вы сетуете на зоопарк, но при этом сами пишите под элементари, а значит, если ваш продукт кому-то понравится, то не факт что он будет нормально работать в другой среде. Вообще важно понимать, что среды слабо совместимы, беря продукты из разных сред, в лучшем случае мы не досчитаемся иконок в интерфейсе, в вероятном случае, не будут работать некоторые функции из-за неразрешённых зависимостей, отсутствующих у инструмента в неродной среде. Вот это и плохо. Нет фундаментального стандарта, фундаментальных десктоп библиотек, и что важно, фундаментально описываемых ресурсов и их наполнение (например те же иконки), на которых бы строились все DE. Как бы стандарт есть, но почему-то кто в лес, кто по дрова. У каждой DE есть свои отличные инструменты, но они не работают глобально одинаково хорошо без родных сред. Основной аргумент, это интеграция библиотек, уменьшение объёма занимаемого места и т.д. Но позвольте, нам ли жалеть место на десктоп машине для пользователей где стандарт HDD > 500Gb?, или мне так важно знать о скорости работы UI который на современном десктопе с современным процессором в лёгкую укладывается в 25мс отклика с десятикратным запасом, и при этом даже если библиотеки будут не интегрированы?
Мне порой разработчики DE и приложений напоминают велосипедистов, этакий тур-де-франс, летят толпой одной дорогой к одной цели черепашьим шагом, а могли бы собраться, смастерить гоночный автобус.
Пес его знает. У меня гномьи приложения нормально работают под KDE. Правда требуется для нормальной работы установить половину гнома, но тем не менее.
Что же до разнообразия, то оно несет с собой не только минусы, но и плюсы. Оно дает свободу выбора, не ограничивая все прокрустовым ложем одной системы.
И даже то, что есть иксы и Вэйланд, тоже хорошо, несмотря на некоторые проблемы, которые все это порождает.
Нет фундаментального стандарта, фундаментальных десктоп библиотек, и что важно, фундаментально описываемых ресурсов и их наполнение (например те же иконки), на которых бы строились все DE.
Стандарт, стоит признать, есть.
freedesktop.org.
Что реально стопорит — это отсутствие вменяемых средств монетизации разработки. Остальное приложится.
Давайте разделять Gnome как операционную систему(грубо говоря любой дистрибутив с его использованием Fedora или Suse) и разделять DE.
Вот я и говорю, мешанина. Gnome — это DE, так же, как KDE, XFCE, Cinnamon и прочие. Fedora, SUSE, Ubuntu — дистрибутивы операционной системы. Вы противопоставляете «Операционную систему Gnome» «десктопному окружению Ubuntu». При этом Gnome — десктопное окружение, доступное во множестве дистрибутивов Линукс, включая Ubuntu. А Ubuntu — это как раз дистрибутив операционной системы, в котором вполне доступен тот же Gnome. Родное DE Убунту называется Unity, при этом его вполне себе уже «похоронили» в пользу, как раз, Gnome.
Все что я выше перечислил это не ответственность DE. Вообще ни разу.
В том и прикол, что UX, т.е. user experience — это зона ответственности именно DE. Взять тот же Windows. Vista и 7ка юзали десктопный интерфейс Aero, с 8-ки начиная — Metro. Под этим работает ядро операционки NTкакая-то-там-версия. То, что конструктивно ядро Windows нельзя отпилить от его UI, и поставляется оно одним продуктом, не делает Windows DE, а Aero и Metro операционной системой.
В Linux операционная система предоставляет все необходимые юзерспейсу базовые операции: файловые операции, шину событий, много еще чего. Интерфейс же приложений и принципы взаимодействия с пользователем задаются десктопным окружением.
В конечном итоге, корректно сравнивать именно Gnome с KDE, XFCE и прочими. При этом свои стайлгайды, UI/UX паттерны, в данный момент, если я не ошибаюсь, есть у Gnome3 и KDE. Соответственно, и правду вашу вам нужно искать именно где-то между G3 и KDE.
В данный момент наиболее продвинулся в нужном вам плане именно Gnome, и шансов больше имеет так же он (просто потому что RedHat, а также то, что гном — дефолтный в подавляющем большинстве дистрибутивов). При этом у них есть стайлгайды (пусть и местами упоротые), свой look-n-feel (пусть и местами спорный), свой, в конце концов, магазин приложений (пусть и в зайчаточном состоянии).
Так что вам остается:
а) сесть на попу ровно, поставить себе дистрибутив с наиболее свежим Гномом;
б) ждать, пока взлетит экосистема (в данный момент именно экосистему родить пытается именно Gnome)
в) перестать сравнивать DE и дистрибутивы операционных систем.
Собственно, для того, чтобы подтянулся софт с нативным «look'ом», не хватает только средства монетизации этого мероприятия. При этом Gnome Software Center уже есть. Короче, если не накосячат, все будет, узбагойтесь)
Gnome вполне себе экосистема, посмотрите базовый набор приложений.
ИМХО чего не хватает сейчас (дома уже много лет debian + редкоиспользуемый ноут с ubuntu) так это проводника из win8.1+ и не совсем базового notepad++(который умеет хранить "не сохранённые файлы" и почему-то мышка(wireless) идеально работающая в win не хочет нормально работать в linux (теряет нажатую кнопку).
А так же из системного, организация доступа к фс для семьи использующей разные учётки (но это просто у всех разные модели использования, комуто модель изоляции пользователей больше нравится).
В остальном же для дома нормально работает )
В остальном GNU/Linux вполне подходит для десктопа.
Хороший аудио плеер Audacious, Amarok, Clementine, Rythmbox. И в репах они есть. Можете испробовать.
Rythmbox
В котором из принципа не сделана настройка для чтения тэнов из mp3 в кодировке использовавшейся в 1/n части суши по умолчанию очень много лет (это просто для тех кто решит им пользоваться, а так в остальном работает отлично( есть небольшие глюки с интеграцией в "systray" в cinnamon.
Возьмите EasyTag и перекодируйте тэги из CP1251 в UTF-8.
Я знаю как это сделать, я просто как-то прочитал обоснование того почему этого нельзя в настройки :)
Выходит что беря, условно, сборник детских песен из мультфильмов, я сначала должен их конвертировать прежде чем вставлять в плеер. Но это лиш одна особенность, к примеру я решил не конвертировать а брать названия из имён файлов и каталогов, но оказывается это тоже не так просто как казалось ранее (скажем как было в playlist winamp).
Я понимаю что продукт такой каким его видят те кто его разрабатывает и претензий нет(и я им постоянно пользуясь), я просто ответил на комментарий рекомендовавший его, просто чтобы заранее предупредить про особенности.
но иногда хочется не лучший, а такой же как.
Знаете сколько аудиоплееров (ну скажем из топ-10) на linux умеют читать embedded cuesheet во flac, что важно для меня? 1. Поодерживает ли он медиа-библиотеку на необходимом уровне? нет
а сколько имеют встроенный редактор тегов с поддержкой макросов и конвертер (обертку над консольными утилитами)? 0.
юзаю foobar2000 под wine — единственное, чему не нашел полноценных аналогов.
Когда винда управляется кнопочками и на выбор огромное количество красивых программ, то на Линукс тех же красивых прог по пальцам пересчитать.
Что такое "красивые" программы?
Сейчас в планах поднять арч с чем нить типа lxde и навернуть живые обои.
Зачем… скажите, ну зачем нужны эти свистоперделки?
Линуксоиды. Не кидайте минусами.
"Нельзя же такое про русских говорить при Штирлице"
И тут Линукс жестко фэйлит.
Ну да, фотошопа нет. С играми совсем плохо, любимая игрушка на стиме отсутствует.
Но на самом деле не все так плохо, как обычно пишут.
Проблемы наблюдаются только со специфичным профессиональным ПО.
Но это общая проблема. Есть программы, которые представлены только на линуксе. И вариантов для других ОС вы просто не найдете.
Сейчас сижу на macOs и в целом устраивает. Потому что там есть программы!
Уже спрашивали, но повторюсь, какие?
Ну и iOS эмулятор.
Сам не пользовался, но пишут, что уже есть такой под линукс.
на Линукс тех же красивых прог по пальцам пересчитать.
Критерии красивости? По мне так красивых программ полно, особенно если KDE пользовать.
В линуксе вроде все есть, но работает частенько после танцев или не работает.
Давно уже не танцевал вокруг линукса. Ставлю — и работает себе.
Не могу сказать, что все безглючно. Я просто глюки не использую.
В линуксе 100500 менеджеров пакетов.
В конкретном дистрибутиве линукс менеджер один. Редко два.
Для мобильных платформ мак.
В смысле разработка?
Под большинство мобильных платформ есть QT. Так что не вижу никаких проблем в линуксе, если только речь не про iOS с Windows. Но что вы хотите от закрытых платформ?
Для cad уже осталась только винда.
Под линукс есть немного cad. Но это все же специфичный профессиональный софт.
А вообще хотел бы что то типа воркспейсов по группам. Типа для работы, для отдыха.
KDE — наше все.
Сам не пользовался, но пишут, что уже есть такой под линукс.
В случае с iOS проблема не с линуксом как с платформой, а с лицензиями на эппловские библиотеки и утилиты. Которые, внезапно, нельзя запускать не на маках.
Так-то есть maloader, под которым заводится ряд компонент SDK.
Есть программы, которые представлены только на линуксе. И вариантов для других ОС вы просто не найдете.
Охотно верю, что есть. Но что, если расширить условие до «программ, которые стали стандартом де-факто в своей области»? Есть такие?
В Windows он сейчас нативный. И нативно управляет виндовыми же контейнерами. Вот если вы хотите в виндовс запустить линуксовый — там да, добро пожаловать в набор костылей для "бесшовного" запуска этого счастья внутри виртуалки
нужна быстрая «шара» — велком, сообществу нужны новые драйвера и фс для исправления этого косяка)
Файловые системы, увы, слишком другой уровень чтобы помочь :)
Когда винда управляется кнопочками и на выбор огромное количество красивых программ, то на Линукс тех же красивых прог по пальцам пересчитать.
Рискну высказать, вероятно, не общепринятое мнение.
Программы не должны быть "красивыми", они должны быть функциональными и удобными в использовании.
Для разных пользователей функциональность и удобство могут значить разные вещи. Возможно, для кого-то действительно субъективная "красивость" интерфейса является критическим критерием функциональности и удобства, хотя, имхо, практическим такой подход назвать трудно.
Я не уверен, что операционная система Linux должна непременно переманить на себя всех, большинство или хотя бы процентов десять пользователей. Мне бы этого не хотелось, т.к. кто знает, возможно, что при таком раскладе те свойства этой системы, из-за которых я пользуюсь ей, а не Windows или macOS, постепенно исчезнут из-за неизбежной ориентации на массы. Может, это такая паранойа, но подобное развитие событий для меня было бы в высшей степени обидным, т.к. в среде Windows и macOS сравнительно с привычной конфигурацией Linux (i3wm+conky+rofi+terminator+clipit+vim) мне работать крайне некомфортно. В частности, мне проще убить, скажем, распоясавшийся Хром не через взаимодействие с GUI, а простой командой:
ps aux | grep -i chrome | tr -s ' ' | cut -d' ' -f2 | xargs kill -9Возможно я не умею готовить, но если я, программер js не умею, то что умеет менее искушённый пользователь?
Умение программировать на языке Х совсем не обязательно делает пользователя "искушённым". Полагаю, что во многом "искушённость" пользователя сильно "прокачивается" при его готовности серьёзно подружиться со своей системой на уровне CLI — по крайней мере это справедливо для Linux.
killall не всегда убивает все нужные процессы.
А если killall -KILL program_name? Или речь о том, что не находит все PID? Кстати, в man killall говорится даже о поиске по регулярному выражению.
Наверное, сработает, не пробовал. А это принципиально? Я совершенно не против печатать чуть больше и иметь больше контроля. В повседневной работе приходится набирать команды куда длиннее.
Так нет, я никого и не принуждаю :) Просто чтобы людей простотой линуксовой командной строки не запугивать предложил ещё одну альтернативу. Ну, и если уж придираться, то в скрипте такое писать мне было бы страшновато, поскольку мало ли, как поменяется формат вывода ps. Или, например, на моей системе ps aux выводит ещё и командные строки программ — вдруг, там где-то упоминается chrome (более того, наверное, там упоминается grep -i chrome)… Я тоже не уверен, что killall всегда работает идеально. Но точек, где можно ошибиться, в случае killall, видимо, меньше.
Просто чтобы людей простотой линуксовой командной строки не запугивать предложил ещё одну альтернативу.
Вам очень надо, чтобы все-все стали пользователями Linux? Зачем?
Ну, и если уж придираться, то в скрипте такое писать мне было бы страшновато, поскольку мало ли, как поменяется формат вывода ps.
Вы совершенно правы, а я просто привёл конкретный пример, когда лично мне удобней использовать CLI. Ни о каких скриптах даже мысли не было.
Кстати, в качестве более безопасной, чем парсинг ps aux, альтернативы, видимо, можно использовать lsof с ключом -t. Сам, впрочем, не пользовался.
Спасибо, покопаюсь.
Предварительный результат. Интересно… :)
Есть ещё интересная, но экспериментальная, команда execsnoop, которая через трассировку ядра (так что, теоретически, что-то может сломаться на низком уровне, но у меня не ломалось) показывает, кому эти PID принадлежат. У меня два из них, как и следовало ожидать — это lsof -ccrome ... и grep -i chrome, третий — с ходу не понял, четвёртого не было (ну или я команду не точно вбил).
В общем, "lsof -cchrome" фильтрует по имени команды, не принимая во внимание путь к исполняемому файлу. В случае имени команды "nacl_helper" путь — "/opt/google/chrome/nacl_helper" — так что "ps aux | grep -i chrome" отлавливает этот процесс, а "lsof -cchrome -t" — нет. Я не спец по lsof, и сходу фильтровать процессы по паттерну имени файла не нашёл. Т.е., остаётся grep, но при этом остаются все недостатки моей команды с ps плюс добавляются новые:
Есть ещё интересная, но экспериментальная, команда execsnoop
В репозитории моей системы её нет, так что увы.
Да, довольно простая. Если знать рецепт и не париться печатать, но я уже писал, что, имхо, Linux и не должна быть операционной системой "для всех".
<@insomnia> cfdisk /dev/hda && mkfs.xfs /dev/hda1 && mount /dev/hda1 /mnt/gentoo/ && chroot /mnt/gentoo/ && env-update &&. /etc/profile && emerge sync && cd /usr/portage && scripts/bootsrap.sh && emerge system && emerge vim && vi /etc/fstab && emerge gentoo-dev-sources && cd /usr/src/linux && make menuconfig && make install modules_install && emerge gnome mozilla-firefox openoffice && emerge grub && cp /boot/grub/grub.conf.sample /boot/grub/grub.conf && vi /boot/grub/grub.conf && grub && init 6
<@insomnia> это первая
Тем более, что никогда не вредно смотреть и использовать продукцию конкурентов. Это может натолкнуть на новые идеи.
Окей, он использует mac и ...?
Мне кажется, принцип "ешь то, что разрабатываешь" довольно уныл, учитывая, что, скажем, если у вас iphone, то одним linux вы не обойдетесь.
Не совсем удачная аналогия, я всегда так готовлю :)
Ну и проблема в том, что для ряда людей (например, пользователей телефонов от apple) linux в самом деле не покрывает все нужны. Это вас удивляет?
Не совсем удачная аналогия, я всегда так готовлю :)
Вы работаете поваром?
Вы правы, таки нет. Не работаю. Впрочем работающие повара так же пробуют не все, если верит вот этому, например.
Суть в том, что аналогия как раз таки очень ок (а ваш личный пример — не очень релевантен).
Она была бы верной, если бы звучала как «Если повар не пробует еду, которую готовит, то он даже не узнает, что она пересолена или не до готовлена. », но тогда она не была бы релевантной.
А в формулировке «Если повар не ест еду, которую готовит, то он даже не узнает, что она пересолена или не до готовлена. » она не правильная. Повар не обязан постоянно есть свою еду и готовить себе.
*zanuda mod off*
zanuda mod
Ну если вы настаиваете.
Повар не обязан постоянно есть свою еду и готовить себе.
Никто не говорит об «обязан».
Ваш исходный вопрос
«Окей, он использует mac и ...?»
… И это вызывает удивление и необходимость в комментарии от него.
Существуют хорошие практики.
В UI/UX — eat your own dog foot
В поварском деле — пробовать то, что подаёшь.
Видеть директора, который расхваливает достоинства linux как десктопа, но в принципе не использует его как десктоп, так же странно как видеть повара, расхваливающего свои блюда, который при этом в принципе не пробует то, что подаёт.
Сотрудники пусть делают что хотят. Но очевидно, что использование одного бренда, когда ты раскручиваешь другой делает рекламу гораздо менее убедительной. И если ты занимаешься рекламой, то поступить так — значит расписаться в профнепрегодности.
– Ношу. Конечно, я люблю дорогие костюмы. Я же модник. Но на работе – Gloria Jeans, к Ксении Собчак – Gloria Jeans, ко всем этим великим – Gloria Jeans. В 2000 году меня, как успешного представителя среднего бизнеса, пригласили на форум в Давосе. Вместе со мной за столом сидел основатель компании «Майский чай» Игорь Лисиненко. Рядом с нами сел CEO Macro System и спрашивает: «Вы где работаете?» Я ему отвечаю: «В Gloria Jeans». «А что вы носите?» – говорит он. Раз – а я сижу весь в армани–шмармани. «А вы что делаете?» – спрашивает Игоря. – «Майский чай». – «А что вы пьете?» Игорь достает из кармана пакетик «Майского чая» и кладет на стол. После этого CEO Macro System с Лисиненко три часа разговаривал, а ко мне вообще не поворачивался, как будто меня нет за столом.
"Ну, или бы появилась достойная модель в линейке"
Выпускать отдельно модель vip при ориентации компании на mass low & middle-low крайне не выгодно.
А с учётом Рено как основного акционера ещё и устраивать внутреннюю конкуренцию.
p.s. Можно было бы для них ввозить "дорогие" Рено, но тут особенность сертификации и доступа в стану (а в России их не продать массово, дорого). А если сажать на infiniti (тот же концерн) то как-то уже и смысла "рекламного" нет
Но своим личным выбором он явно показал, что готовность линукса к повседневному использованию на дектопе — это, скажем так аккуратно, небольшое преувеличение.
Если человек, который знает линукс намного лучше среднего юзверя, и тот не хочет его использовать в обычной жизни — то куда уж остальным?
Лично для меня дело не в фанатизме, и не в приличиях, и не в этикете.
Просто человек своим личным выбором показал истинное положение вещей.
Слова это слова, дела — это дела.
Ну а чего вы хотите, если даже основатель GNOME сбежал на OSX устав от зоопарка и несовместимости?
Даже если забыть про вечные проблемы с оборудованием, шипение пульсы, несовместимость с проекторами, как человек, пробовавший выпускать под него коммерческий софт могу сказать, что линуксовый десктоп совершенно непригоден в качестве целевой платформы для разработки под него чего-либо из-за отсутствующей обратной совместимости. Рассчитывать нельзя буквально ни на что. Даже необходимый минимум в виде glibc, libfontconfig libX11 и libGL, при наличии которого можно жить в режиме "всё своё ношу с собой", и тот не всегда есть. Остальные либы постоянно ломают от версии к версии, нельзя написать софтину и рассчитывать, что она продолжит устанавливаться и работать через 5 лет. Даже если с либами повезло и они работают или мы накостыляли себе упаковку во flatpak (в который не всякий софт можно паковать из-за отсутствия полноценного доступа к файловой системе), разные хипстеры постоянно что-то ломают в десктопных средах. Так, в GNOME теперь нет системного трея. Вообще ни в каком виде. Объявили ненужным. Заодно объявили "deprecated" GtkStatusIcon, попутно выпилив поддержку оного на Windows и OSX из GTK4. Про звук и этот их новый™ более лучший® дисплейный сервер© вообще молчу.
Вот как так? На Windows я могу взять установщик программы, собранный в 96-ом году, она установится и будет работать. Играя звук без шипения и показывая иконку в трее. На Linux я не могу этого сделать.
Пока не починят проблему совместимости дистрибутивов друг с другом и с самими собой, заниматься популяризацией бесполезно. Софта не-для-разработчиков под платформу не будет.
На Windows я могу взять установщик программы, собранный в 96-ом году, она установится и будет работать.
Если кратно, то не можете.
Можно, конечно, но тогда чем тут ситуация отличается от Линукса?
Инсталлятор 1с 7.7 просто не запустится на 64-битной системе.
Вот прямо собранный в 96 очень вряд ли. Учитывая, сколько выкинули при переходах xp -> 7, 7->8
far100b.rar от «Sep 10 1996» запустился и работает (первая общедоступная версия 1.00 beta)
Можно еще примеры приводить, но Вы спорите ради спора
Смотря чем было скомпилировано, если это delphi(borland c++) то скорее всего заработает(придётся ставит. В отличный от P&F каталог) т.к. завязок на системные библиотеки немного, всё зависит от набора используемых функций, но вроде базовые библиотеки продолжают содержать код для поддержки legacy.
Вот из-за такой позиции большой части сообщества в виде отрицания проблем и их игнорирования, у линукса на десктопе так мало пользователей.
Причём проблема не в линуксе, это отличное ядро с очень хорошей обратной совместимостью по системным вызовам. Проблема в головах у людей, делающих десктопные среды и собирающих дистрибутивы.
У линукса на десктопе мало пользователей из-за того, что в Windows установщик собранный в 96 году не будет работать в 2017?
Вот из-за такой позиции большой части сообщества в виде отрицания проблем и их игнорирования, у линукса на десктопе так мало пользователей.
Я правильно понимаю, что из-за того, что в linux есть куча разных либ и меняется окружение, старые программы не запускаются? А в windows все поставляется монолитным куском и никогда не меняется? Ну так ведь нет, и даже режимы совместимости помогают далеко не всегда, в 80% случаев проще поставить linux + wine, чем заводить старое приложение на windows 10. Если бы это было не так, ReactOS бы скорее всего даже не появился.
Проблем у linux как десктопной системы довольно много, это и раздражающие баги, и нехватка некоторых программ. Но суть в том, что проблем у windows как у дестопа раз в 10 больше, а не бегут с него только из-за инерционности.
На Windows есть достаточно стабильное апи, на которое можно завязываться. Которое kernel32, user32, gdi32, ole32, вот это всё. Оно покрывает 90% задач и не разваливается в руках. Есть менее стабильные части, которые надо доустанавливать отдельно (обычно прилетают через Windows Update, но их на всякий случай кладут в свои установщики) — это различного рода версии .NET Framework, DirectX, сишного рантайма, которые либо полностью обратно совместимы со своими предыдущими версиями, либо живут в системе side-by-side.
В windows и OSX не бывает ситуаций, когда авторы дистра обновили libssl с 0.9.8 до 1.0.0 и после этого начал крашиться код, который пытается использовать системный libcurl (а если таскать его с собой, заодно придётся поставлять свой набор корневых сертификатов, ибо системные могут лежать в десятке разных мест в зависимости от дистрибутива и его версии). Не было такого, чтобы просто удалили какую подсистему ОС и заявили, что теперь надо всё делать по-другому, как это было со звуком или с системным треем. Не было такого, что чтобы показать иконку в системном лотке приходится ставить плугин к системному шеллу и его перезапускать. Не было такого, что вдруг поменяли полностью графическую подсистему и сказали, что теперь нельзя узнать координаты своего окна и что одного из буферов обмена теперь не будет, ибо "несекурно". Не было такого, чтобы в разных версиях windows шли разные несовместимые между собой версии msvcrt и kernel32 (зоопарк с glibc, ulibc и musl, я смотрю на тебя).
Steam кое-как решает эти проблемы, поставляя вместе с собой замороженный набор системных библиотек из состава 12-ой убунты. Но вот сейчас опять ломают звук и меняют пульсу на некую систему, которую в девичистве называли Pinos. И не факт, что всё продолжит работать как было. И неизвестно, как всё это поведёт себя работая через прослойку в виде XWayland. Но вопросы обратной совместимости никого не волнуют, это же сложно, не интересно, не модно и молодёжно, и вообще, это же работать надо.
На Windows есть достаточно стабильное апи, на которое можно завязываться.
Нет такого. Из windows отлично выпиливают и заменяют подсистемы. Вот пример. Вот тут люди утверждают, что даже самое святое win32 api таки подвергается изменениям при переходе на windows 7.
В windows и OSX не бывает ситуаций
Бывает, в windows точно. Вот google запрос, вполне реальные случаи.
которые либо полностью обратно совместимы со своими предыдущими версиями
Да, вот только иногда даже минорные версии dot.net могут быть не совместимы между собой. А так да, все нормально.
Не было такого, что чтобы показать иконку в системном лотке приходится ставить плугин к системному шеллу и его перезапускать. Не было такого, что вдруг поменяли полностью графическую подсистему и сказали, что теперь нельзя узнать координаты своего окна и что одного из буферов обмена теперь не будет, ибо "несекурно". Не было такого, чтобы в разных версиях windows шли разные несовместимые между собой версии msvcrt и kernel32 (зоопарк с glibc, ulibc и musl, я смотрю на тебя).
О да, не было. Разве что при переходе на windows 8, но так да, никогда не было.
Но вопросы обратной совместимости никого не волнуют, это же сложно, не интересно, не модно и молодёжно, и вообще, это же работать надо.
Вам настолько нужна обратная совместимость? Попробуйте десктопный CentOS, там вот все всегда совместимо настолько, что все еще ядро 3.10 с последними плюшками 4.12. У меня такое впечатление, что вы делаете вывод за все десктопы Linux исходя из одной Ubuntu. Ее основная идея — это не обратная совместимость, если вам не нравится, у вас есть другой выбор.
Но вот сейчас опять ломают звук и меняют пульсу на некую систему, которую в девичистве называли Pinos. И не факт, что всё продолжит работать как было. И неизвестно, как всё это поведёт себя работая через прослойку в виде XWayland.
Не факт? Вайланд вышел аж в 2008 (!) году и до сих пор не зашел в кучу дистров (включая ubuntu) из-за того, что каждый раз его откладывали из-за проблем обратной совместимости. Аналогичная фигня с вот этой звуковой подсистемой. Я даже не смог найти новостей про то, что ubuntu на нее переходит, а fedora два года назад представила ее как подсистему для видео. И все.
А что касается графических разработчиков, у вас всегда есть спека, которая обязана быть реализованной везде. Это если вам нужна стабильность api для окошек, то X server + freedesktop есть в 99% случаев. А там где нет, проблемы пользователей.
Хватит натягивать сову на глобус.
POSIX подсистема никогда не входила в Windows API и никогда не была доступна из win32-приложений.
API меняется, но в сторону расширения и в сторону "не используйте эту функцию в новом софте, иначе у вас не будут корректно работать новые фичи винды".
Да, вот только иногда даже минорные версии dot.net могут быть не совместимы между собой
Как .NET разработчик с восьмилетним стажем могу сказать, что проблемы с этим были ровно один раз, когда поставили по умолчанию новый JIT и сломался код логгера, который рассчитывал на недокументированную функциональность. Вылечилось выставлением опции в реестре.
Разве что при переходе на windows 8, но так да, никогда не было
Что именно убрали в Windows 8? Меню пуск? Как это повлияло на старый софт? Правильно, никак.
Вам настолько нужна обратная совместимость
Да, нужна. Без неё я не буду выпускать софт под Linux, иначе его будет слишком дорого поддерживать. Собственно, поэтому софта коммерческого толком никакого и нет.
у вас всегда есть спека, которая обязана быть реализованной везде
Расскажите это разработчикам GNOME. Версии 3.16, из которой убрали поддержку трея через XEmbed. И разработчикам убунты, из которой её убрали ещё раньше.
Что именно убрали в Windows 8? Меню пуск? Как это повлияло на старый софт? Правильно, никак.
Как минимум .Net 1.1. Это тоже не повлияло на старые приложения никак?
Да, нужна. Без неё я не буду выпускать софт под Linux, иначе его будет слишком дорого поддерживать. Собственно, поэтому софта коммерческого толком никакого и нет.
Как показывает практика Android, который унаследовал проблему фрагментации, проблема не в этом, проблема только в популярности платформы.
Как .NET разработчик с восьмилетним стажем могу сказать, что проблемы с этим были ровно один раз, когда поставили по умолчанию новый JIT и сломался код логгера, который рассчитывал на недокументированную функциональность. Вылечилось выставлением опции в реестре.
А тогда вот такие штуки обманывают? Я, конечно, вообще не шарю в C#, но мне кажется, что фраза
You can no longer host Windows Forms controls in the Internet Explorer, because there are better solutions for hosting controls on the Web. Therefore, the IEHost.dll and IEExec.exe assemblies have been removed from the .NET Framework.
Означает, что какой-то кусок фунционала таки был выпилен.
Как минимум .Net 1.1. Это тоже не повлияло на старые приложения никак?
Совсем совсем старые приложения да сломались. Для новых .Net приложений это ненужно.
.NET 1.1 чинится строчкой в манифесте/app.config.
У андроида есть проблемы фрагментации в плане размеров экранов и кривизны китайских прошивок, там нет проблем вида "ой, мы решили положить все библиотеки в другие места или вообще игнорировать FHS", "ой, а у нас новая версия бинарно не совместима со старой", "ой, мы не будем поставлять ffmpeg, потому что нам рожа автора не нравится, вот вам почти совсем совместимый с ним libav". В андроиде старый софт в большинстве своём невозбранно продолжает работать как положено.
.NET 4.0+ ставится отдельно и side-by-side с .NET 3.5. Приложения под .NET 3.5 продолжают использовать старую версию.
Удаление поддержки произвольных ActiveX — общий тренд всех браузеров и является вынужденной мерой для обеспечения безопасности. Вы же не ругаете за это хром и firefox?
Вообще ваша полемика напоминает отмазки вида "а у вас негров линчуют". Вместо того, чтобы принять проблему и начать её решать, начинают искать недостатки у других. И таких вот как вы — половина сообщества. Именно поэтому дела и обстоят настоящим образом.
Вообще ваша полемика напоминает отмазки вида "а у вас негров линчуют".
Исключительно потому что вы сказали, что "у всех все хорошо, и только linux все печально". С обратной совместимостью все плохо у всех. Разумеется, со стабильностью платформ дела у windows и mac OS лучше (хотя на самом деле нет, так как вы должны писать под windows 7, которой половина рынка и надеяться, что оно запустится на новый windows), но не решаемых проблем нет. Вам как разработчику никто не мешает использовать правильные средства платформы, например, зависимости в deb и rpm пакетах и общие интерфейсы для работы с частями системы.
У вас qt приложение? Тяните за собой qt'ы все отлично. И так далее.
Не хотите страдать со всякими libav и прочим? Говорите, нужен ffmpeg и баста.
Я не понимаю, почему вы делаете из этого проблему всея linux, ведь только что указали, что аналогичная проблема есть и в windows, что нужно доставлять либы.
У меня есть продающийся десктопный софт под windows, я понаписал кучу заказного софта под эту платформу и ни разу не испытывал проблем с тем, что "майкрософт всё поломали". У меня был коммерческий десктопный софт под OSX, но ни разу не было проблем из-за того что "эпол всё поломали". Когда я пытался выпускать софт под Linux (причём под 2.5 дистрибутива), у меня буквально через год пошли жалобы вида "после обновления системы ничего не работает", несмотря на то, что написано это всё было на GTK. Через пару лет мы просто отказались от поддержки Linux как платформы.
И поймите, я такой далеко не один. Пока это не исправят, софта под платформу не будет. А без софта не будет и пользователей. Как-то вот так.
И что? Мне найти людей, у которых есть аналогичная ситуация для разработки под Windows? Например, steam внезапно испытывал проблему с windows 10. Разница только в том, что в случае в windows это ваша проблема, а в случае с linux, вы можете на это забить, так как 1.5 анонимуса не сильно сказываются на ваших продажах.
И поймите, я такой далеко не один. Пока это не исправят, софта под платформу не будет. А без софта не будет и пользователей. Как-то вот так.
Что это? Зоопарк разных дистрибутивов, который не влияет на количество софта или же поддержку мифической обратной совместимости, которая тоже на это не влияет? Реальная вещь, которая влияет на количество софта — это количество пользователей. Если все внезапно перейдут на какую-то страшную OS, под которую разрабатывать можно только на c99 с кучей боли, то вы будете это делать. Все остальные факторы вроде "я не пишу на эту платформу софт, потому что там плохая поддержка, много боли или нет нужных мне языков" легко решаются. У вас вот есть QT, который почти никогда не подводит, например. Есть unity для игр. Если в конце концов java с swing или javafx.
Если в конце концов java с swing или javafx
С ними приходится изобретать костыли в виде доустановки своих расширений в гномошелл с его последующим перезапуском. Просто, чтобы всё нормально работало. И да, на арче это не помогает.
В общем, позицию я вашу понял, можете дальше кричать, что линукс круче всех и надеяться, что от этого на платформу кто-то ещё придёт. Больше 20 лет так безрезультатно делают, может, в этот раз поможет.
С ними приходится изобретать костыли в виде доустановки своих расширений в гномошелл с его последующим перезапуском. Просто, чтобы всё нормально работало. И да, на арче это не помогает.
А еще оно не умеет в прозрачные картинки. Поэтому единственный рабочий вариант — использовать QT. Когда я умел только java, я настолько отчаялся, что хотел писать биндинги к QT на java, но это дело десятое.
В общем, позицию я вашу понял, можете дальше кричать, что линукс круче всех и надеяться, что от этого на платформу кто-то ещё придёт. Больше 20 лет так безрезультатно делают, может, в этот раз поможет.
На всякий случай уточню, что я не отрицаю эти проблемы, но это не те проблемы, которые блокируют развитие linux как платформы, потому что они есть и в других более успешных системах.
У flatpak'а основная проблема в том, что он помимо решения проблемы упаковки занимается тем, чего от него вообще не просят. А именно — изоляцией. Ребятам захотелось поиграться с контейнерами и cgroups, и теперь всё упакованное в этот ваш flatpak живёт в хитром контексте, который не видит полностью вашу файловую систему. И отключить это никак нельзя. Если попытаться в него запихнуть, скажем, IDE, которой жизненно необходим доступ к установленным в системе тулчейнам, итог, немного предсказуем. Вон, MonoDevelop во флэтпак упаковали, в нём теперь что-то сложнее хэлловорлда невозможно разрабатывать.
У Snap-а в этом плане хотя бы специальный режим есть.
Но и они вам не помогут, если люди намеренно отламывают кусок шелла, как это произошло с треем.
Суммарная сложность реализации, она, как известно, величина постоянная. Разница лишь в том, каким образом она размазана по проектам/подсистемам, командам разработки. Сравнивая с тем же .Net, стабильность его API — головняк конкретно микрософта. Поэтому весь этот кавардак с версиями, совместимостью, поддержкой api и т.д. — он «скрыт» от конечного разработчика под .Net. Всю эту «кашу» едят специалисты на жаловании у MS.
В линухе весь этот головняк решить аналогичным образом — нереал. Слишком много дистрибутивов, платформ и т.д. и т.п. Попытки унификации, типа того же LSB — они были, но неудачные. Поэтому, вероятно, и пошли тем путем, что пошли — взяли имеющийся инструментарий изоляции/виртуализации и на его базе стали пилить платформу, на которой возможна реализация фреймворков уровня .Net.
А по поводу изоляции. Собственно, рациональное зерно в этом есть. Подавляющему большинству пользовательского софта, собственно, целиком файловая система и не нужна. Вот реально нефиг этому самому софту за пределы «хомяка» лезть. Доступ к специфическим подсистемам, проброс устройств — это уже вопрос отдельной реализации. В том же snap оно, вроде как, плагинами решается.
Короче, постепенно обрастет функционалом. Что-то из этого выйдет. А если уж вашему софту реально нужен низкоуровневый доступ к системе целиком… ну, вероятно, это уже не совсем пользовательский софт.
это уже не совсем пользовательский софт
Ну вот пишу я эмулятор терминала с котиками на фоне и 3D-эффектами. Если я его запакую во flatpak, он станет абсолютно бесполезен. Вообще любой софт, который рассчитывает на возможность запустить консольную утилиту по имени во flatpak упаковывать нельзя. И сделано это специально. Почему так — для меня загадка.
Ну и приложения, использующие GTK/Qt в нём выглядят не нативно, т. к. не видят выбранной темы.
И сделано это специально. Почему так — для меня загадка.
Вот тут то, как раз, загадки нет. Flatpak делался, по сути, как реализация модели распространения приложений по типу Android'ной. Т.е. вся философия в том, чтобы не тащить уйму непонятно кем написанного гамна разной степени корявости в репозиторий системы. А вот этому гумну, как раз, изоляция не помешает.
Собственно, это зачатки аналога Play/Appstore под линуху. Логическая цепочка, как раз, очевидна: Унификация платформы -> Способ монетизации -> Появление тучи софта разной степени корявости -> Увеличение пользовательской базы -> Подтягивание A-class софта -> «Причесывание» магазина приложений.
Собственно, именно то, что Google сделал с Android. В принципе, вполне может выстрелить.
И да, как «коробка» для эмуляторов терминалов и системного софта оно не задумывалось от слова «совсем». А пользовательские «ништяки», типа клиентов всяких «одноклассников», «вайцапов» и «веселых ферм» туда вполне себе ложатся.
Для «условно-систеного» же софта… Ну, тут, собственно, какфсигда, 2 пути. Либо щупайте snap (благо, поддержку теперь и Redhat условно анонсировал) — у него умелок побольше, либо пилите пакет для системы. Собственно, вызов консольной тулзы по имени в сценарий «песочницы для гарантированной совместимости» и не укладывается. В нижележащей системе консольной тулзы, которую вы вызываете, может и не оказаться. Это уже дистроспецифичная вещь — т.е., в некоторых случах может не сработать. Короче, вполне предсказуемая и даже логичная модель «жрите, что дают, если надо еще — заказывайте у шеф-повара».
Ну вот у Snap-а тоже есть средства изоляции, но они отключаемы, есть понятие devmode, в котором установленные пакеты видят всё. Что мешало сделать так же для flatpak?
В нижележащей системе консольной тулзы, которую вы вызываете, может и не оказаться
На OSX/Windows обычно в таких случаях спрашивают путь к утилите и/или предлагают её доустановить. Flatpak не даст так сделать.
Что мешало сделать так же для flatpak?
Концепция, очевидно. Flatpak — песочница для сторонних (3rd party) пользовательских приложений. Нравится это или нет — с этим придется смириться. Для различных фоторедакторов, книг рецептов и прочих веселых ферм — самое оно. Вот реально не надо им доступ за пределы «хомяка».
Если вы системный софт в него пытаетесь запаковать… Ну, видимо, вы используете flatpak не по назначению. Он не плохой, он просто для этого не предназначен.
Snap, к слову, тоже не совсем ваш use-case. Devmode — это режим отладки приложения, не предназначенный для боевого применения, однако. Собственно, запретить вам пользовать devmode в своем проде никто не запретит, но широкого применения данная модель не предполагает.
Другое дело — плагины. Всё, к чему вам изнутри песочницы доступ нужно иметь, вы можете положить в плагин, а потом присобачить к вашему приложению (в случае со snap). Это, типа, «кошерный» путь применения.
На OSX/Windows обычно в таких случаях спрашивают путь к утилите и/или предлагают её доустановить.
Собственно, так сделать, особо, никто не мешает. И даже будет работать примерно в 50% случаев. Нужно, буквально, D-Bus и установщик, который на нем висит. Т.е. реализуемо, например, в Ubuntu или Fedora. Однако «правильный путь» — всобачить то, от чего зависит ваш пак, в зависимости этого самого пака и поставить отдельным слоем.
Собственно, подача про osX и win — ну… какбэ там тоже лютейший и корявейший костыль, например…
Devmode — это режим отладки приложения, не предназначенный для боевого применения, однако
Я с classic перепутал. Тот даёт доступ к корневой файловой системе
Всё, к чему вам изнутри песочницы доступ нужно иметь, вы можете положить в плагин, а потом присобачить к вашему приложению (в случае со snap).
Как мне запустить системный GNU Make или прочитать содержимое системного /usr/include, если я делаю IDE? IDE от системы ничего кроме этого не надо, но flatpak и этого сделать не даёт.
Как мне запустить системный GNU Make
Согласно логике песочницы — принести GNU Make с собой, нужной версии. Иначе опять начнется «у вас патроны не той системы». Make, autotools и прочее, например, рекомендуют так: github.com/snapcore/snapcraft/blob/master/demos/libpipeline/snap/snapcraft.yaml
прочитать содержимое системного /usr/include
В сценарии, заради которого все затевалось, системный /usr/include читать и не надо. Читать надо тот, который для этой песочницы специальный.
Понимаете, философия в том, что относительно стабилен линукс ровно по линии glibc. В ядре — нестабильное ABI, заради развития. В юзерспейсе — вообще форменный угар и содомия. Единственное решение — в песочницу положить все от glibc и выше в сторону юзерспейса. Т.е. и gtk у вас там свой будет, фиксированной версии, и всяческие lib*.*.*.so. Вот именно так гарантируется, что тот же фотошоп не отвалится при обновлении из-за того, что в гноме вылилят DBus, а Gentoo перейдет на BusyBox (так, навскидку, в порядке бреда).
если я делаю IDE
Если вы делаете IDE для разработки приложения-под-песочницу — все норм. У этого IDE прям ровно нужные /usr/include и версии конпеляторов будут. Если общесистемное IDE — вы опять не по адресу. Оно заради пользовательского софта пишется.
Ну так положите "всё выше glibc" куда-нибудь в специальную директорию внутри песочницы, как раньше в /opt всё с собой таскали. Резать доступ-то зачем.
Ну так положите "всё выше glibc" куда-нибудь в специальную директорию внутри песочницы, как раньше в /opt всё с собой таскали.
[sarcasm]Как в Windows создайте DLL-Hell и всё будет нормально.[/sarcasm]
Резать доступ-то зачем.
Снижение возможности конфликтов ПО, снижение уровня заражаемости ПО. Как пример.
С историями про "dll hell" я в последний раз сталкивался в последнем десятилетии. В систему ставится всё установщиками от майкрософта, а остальное таскается с собой в директории с приложением. Такая методика очень хорошо работает.
Зачем вообще этот уровень абстракции, если вам нужен доступ к дистроспецифичным вещам? Нужны дистроспецифичные вещи — пишите под конкретный дистрибутив.
В пример вы приводите Винду, в которой ситуация, вроде как, устаканилась. Ок, только вcя разница в том, что винда одна, а линуксов — море.
Хотите windows-way? В чем проблема, определитесь с конкретным дистрибутивом, который будете поддерживать. Получится стабильно и со своей спецификой.
Хотите, чтобы работало на всем зоопарке линуксов? Суйте приложение в песочницу-абстракцию и не выпендривайтесь.
Ну вот каким боком тот же Android SDK является дистроспецифичным? Или .NET Core. С точки зрения IDE достаточно знать путь к ним и всё. Вместо этого предлагается делать поддержку для каждого дистра по-отдельности, потому что вместо решения для портабельной установки программ аки в макоси предлагают принудительно запихивать всё в песочницу. Не удивлюсь, если тут причины тоже религиозного характера.
Ну вот каким боком тот же Android SDK является дистроспецифичным?
А кто-то говорил про Android SDK?
системный GNU Make или прочитать содержимое системного /usr/include
Вот ЭТО вы просили, и да, ОНО дистроспецифичное.
С точки зрения IDE достаточно знать путь к ним и всё.
А с точки зрения компилятора — недостаточно. Надо еще, чтобы версии библиотек внутри песочницы совпали с версиями снаружи, например. И это превращает весь механизм в пшик, никому не нужный и не работающий.
Вместо этого предлагается делать поддержку для каждого дистра по-отдельности
Ну вот неправда же ваша. Предлагается делать поддержку под SDK той версии, которая во flatpak'е или snap'е. Понимаете? Именно под ту версию, которая в базовом лейере пакета. Т.е. прямо так и говорят: не заморачивайтесь со спецификой различных дистрибутивов, пишите под ваш образ! А уж он будет работать на всех дистрибутивах — это уже наш головняк.
вместо решения для портабельной установки программ аки в макоси предлагают принудительно запихивать всё в песочницу
Ну вот это и логично же. Макось — это коммерческая ось, направление развития которой курирует вполне себе конкретная фирма, и конкретные люди. И, если эти люди договорились между собой, что библиотека Икс во всех продуктах будет версии Игрек с версией билда Зет, она там будет. А в линуксе не договорятся.
Поэтому от системных библиотек вас изолируют, и правильно делают.
если тут причины тоже религиозного характера
Нету тут религии, сугубо техническое решение.
Ну так положите «всё выше glibc» куда-нибудь в специальную директорию внутри песочницы,
Собственно, именно это и предлагается. Всё, что тебе нужно, носи в своем снапе. Что не так?
как раньше в /opt всё с собой таскали.
В /opt до сих пор никто не запрещает таскать, например. Да и chroot не вчера придумали…
Резать доступ-то зачем.
Странно обвинять песочницу в том, что она песочница.
Не странно обвинять средство доставки приложений в том, что оно помимо основной задачи занимается тем, о чём его не просят.
Оно, скорее, такое, как под Android, например
Только вот телефоны под Android рутуются. И у приложений есть доступ к руту после этого. Во флетпаке такого нет.
Нет, я с этими проблемами всеми реально столкнулся. Мы делаем свой кроссплатформенный UI-тулкит для .NET, на базе которого уже делают IDE, которая уже поддерживает разработку в том числе под всякие встраиваемые железки.
И вот организовать упаковку всего этого счастья в пакеты для Linux очень, ОЧЕНЬ больно.
Не говоря уже о предыдущем крайне негативном опыте разработки под эту платформу и куче проблем, вызванных тем, что Xamarin-овцы догадались MonoDevelop упаковать во flatpak.
Xamarin-овцы
Fixed.
Только, ради всего святого, не выдавайте такое поведение за норму. «Для запуска нашего софта под андроид, необходимо рутануть устройство» — это НЕ нормально.
А по сути ваших задач, мнение мое следующее:
1. Кросплатформенный UI-тулкит — это, конечно, хорошо, но:
а) слабореализуемо
б) расходится с политикой поставщиков ОС
в) формально недостижимо
2. IDE на базе кросплатформенного UI-тулкита… Какбэ, в некоторых случаях кроссплатформенность IDE идет только во вред.
3. Выбор для реализации этого проекта неполноценно кроссплатформенного .NET — тем более странно. У вас внутри наполовину Mono, наполовину .NetCore. При этом все это в стадии жесточайшей беты и ваще жесть.
4. Для разработки под встраиваемые железки песочная изоляция — самое оно. Внутри песочницы вы будете иметь ровно те заголовочные файлы, версии библиотек и прочую кашу, которые будут доступны вам на целевой системе. Гарантия того, что где-то не просочится десктопный инклюд с вашей девелоперской машины — это только к лучшему. Еще раз повторю, для сборки под целевую платформу лучше иметь весь рантайм + исходники/либы платформы внутри песочницы, чтобы потом не удивляться, почему «а на моей машине работает».
5. Претензия по поводу пакетов для Linux — она из рода «я под винду собрал, а на макоси не запускается! Оказывается, пересобирать надо! Как так?» Дистрибутивы линухи различаются между собой примерно как Windows и Android. Поэтому претензия к «жопа собрать один пакет под линукс» — она странная. Вы же не сетуете, что у вас один бинарник под виндой и под макосью не запускается. Просто перестаньте поддерживать «Linux». Нету никакого «Linux'а», есть Ubuntu отдельно, Fedora/RH отдельно, Suse, Arch — тысячи их. Поддерживайте целевую платформу, а не зоопарк целевых платформ. Или отказывайтесь от поддержки целиком, если процент пользователей там не критичен. Даже доведи разрабы flatpack до совершенства, до полной усраться-совместимости c миллионом дистрибутивов Linux, вот реально оно на том же Alpine не заведется, и на тысяче других. Потому что они принципиально про другое.
6. Ну а последний абзац — он вообще про Xamarin-проблемы. Т.е. Xamarin-овцы упаковали во флетпак — виновата, естественно, Linux-экосистема. У вас были проблемы с разработкой на Mono под Linux — проблема Linux-экосистемы… Короче, при всех раскладах виноват именно Linux, причем в целом.
Давайте конкретизировать претензии и ограничивать аппетиты.
Рутование, согласно политике производителя — это таки не функция системы, а вполне себе взлом, ведущий к отказу от гарантии.
Тогда в случае вендора тивоизация необходима, да ещё и с нарушением лицензии.
в линухе рут доступен изначально, имеет все права и везде, а потому обход песочницы в линухе должен быть проще.
А ничего что в любой Unix-like системе есть пользователь 'root' с UID и GID 0?
Не забудьте повесить табличку при установке, мол, мы используем патченный flatpack, и для использования нашего софта надо отключить AppArmor и SELinux, если таковые имеются.
Найдите мне человека который так сделает со своим продуктом.
Кросплатформенный UI-тулкит — это, конечно, хорошо, но:
а) слабореализуемо
б) расходится с политикой поставщиков ОС
в) формально недостижимо
С пт. 'в' можно спорить спокойно, этого можно достичь просто нужно время!
С пт. 'б' я не согласен, вопрос тулкита не относится ни к поставщикам ОС ни к вендорам ОС, но только к мэйнтэйнерам самого тулкита
С пт. 'а' я не согласен, причина как с пт. 'в'
- IDE на базе кросплатформенного UI-тулкита… Какбэ, в некоторых случаях кроссплатформенность IDE идет только во вред.
Хмм… Может вы и правы, но Intellij IDEA и PyCharm (CE версии) от этого не страдают.
Еще раз повторю, для сборки под целевую платформу лучше иметь весь рантайм + исходники/либы платформы внутри песочницы, чтобы потом не удивляться, почему «а на моей машине работает».
А вам повторят, "Делай по заданию!" если надо чтобы либы были только системные значит делай как надо. [Человек системы.]
Претензия по поводу пакетов для Linux — она из рода «я под винду собрал, а на макоси не запускается! Оказывается, пересобирать надо! Как так?»
Знаешь подвижки в плане "создадим единую пакетную систему для всех Linux-kernel based систем" рано или поздно должны быть.
Дистрибутивы линухи различаются между собой примерно как Windows и Android.
Ну взяли и сравнили, только сравнение перейдет в
Windows NT или Linux.
А дисты Linux если и имеют различия то только в пакетной составляющей.
Или отказывайтесь от поддержки целиком, если процент пользователей там не критичен.
Тем самым вы ставите крест на своих разработках.
Ваш продут не нужен, значит мусор, а раз мусор то выбросить вместе с идеями. [Вы потребитель, а не созидатель]
Короче, при всех раскладах виноват именно Linux, причем в целом.
Ну конечно при всех раскладах виновато ядро ОС, куда же ещё смотреть кроме как не на самого себя.
Давайте конкретизировать претензии и ограничивать аппетиты.
От созидателя к потребителю, делаем все возможное чтобы вы не мучились просто подождите и успокойтесь и все наладится.
Проследите, пожалуйста, историю дискуссии, если не лень. Дело в том, что я как раз был противником позиции «виноват линукс».
Предыдущий оратор из ПРОТИВОПОЛОЖНОГО лагеря выдвинул сентенцию «Из вашего Линукса вон системный трей выпилили!» Ну неправда же! Не выпиливали! Поясню: в Линуксе как таковом системного трея никогда и НЕ БЫЛО. В ТретьеГноме был, факт. Уродливый и неюзабельный. Да, выпилили. А в KDE, например, оставили. НО… Оба этих факта к Линуксу как таковому отношение имеют весьма и весьма опосредованное. Пляски с треем — это ГномоПроблемы. Не мешайте их с ЛинуксоПроблемами — их и без ГномоПроблем хватает.
Теперь о моей поизции по UI-тулкиту. Видимо, надо обосновать:
а) слабореализуемо
т.к. каждая платформа имеет свой набор поведений, инструментов, best-practices и т.д. и т.п. Что-то универсальное… Хм, как бы, пробовали уже. Canonical пробовал, Microsoft пробовал. «Конвергенция» не взлетает. На выходе мы имеем «плитки», в которые удобно тыкать пальцем, но чудовищные с точки зрения управления мышью и, уж тем более, клавиатуры. Мы имеем заголовки окон в полэкрана на десктопе, и имеем кнопки 15х15px на смартфонах, в которые вы хрен пальцем попадете. Все универсальное заведомо хуже нативного.
б) расходится с политикой поставщиков ОС
Гайдлайны у каждого свои. И даже можно оформить темы, чтобы оно «нативно выглядело» на каждой платформе. При этом есть еще UX и набор паттернов поведения, которые автоматически не сконвертируешь. Ну вот никак, реально. Все равно придется платформо-зависимую часть пилить, хоть убейся. Или забить просто на native-look-and-feel… Но тогда о какой «полноценной поддержке» можно говорить?
в) формально недостижимо
Вот составьте табличку умелок и проставьте галочки, на каких платформах что реализовано. Вот прямо на пункте «значки в трее» ваша затея и поутихнет. Где-то они есть, где-то не предусмотрены, а где-то плагинами (вы тут плюс или минус ставить будете?) Короче, никогда у вас вся табличка плюсами не будет заполнена, т.е. ФОРМАЛЬНО НЕДОСТИЖИМО.
Если говорить про JetBrains, то эти ребята не пытаются взять «универсальный кросплатформенный гуи-фреймворк» и на нем реализовать. Они запилили «необходимый минимум» под нужные им платформы, и ничего, норм, живут. При этом запускаются они далеко не под каждым линуксом, например. И не пытаются запилить версию своих DE под мобильные платформы, зная, что они там на фиг не сдались. Да и по поддержке гайдлайнов они не заморачиваются. Одинаково кладут болт на гайды всех платформ, на которых работают.
>> Знаешь подвижки в плане «создадим единую пакетную систему для всех Linux-kernel based систем» рано или поздно должны быть.
Вот это тоже не выстрелит. Были уже попытки. Вполне обоснованно не взлетели. Кто-то придерживается политики «ставим только то, что необходимо», и его пакетный менеджер ведет разветвленное дерево зависимостей, а в пакетах тонны метаинформации на тему что-от-чего-зависит-и-в-каком-порядке-ставить. Кто-то придерживается более утилитарно-интерпрайзного подхода вида «винты дешевые, чо мы паримся», и вот он с икренним недоумением смотрит в количество метаинформации в пакетах первых. А третий вообще все это пытается в 2-гигабайтную SD-карточку упихать, для него кретинами выглядят и те, и другие. Есть, вероятно, «золотая середина», которая будет одинаково неудобна всем. Но зачем?
>> А дисты Linux если и имеют различия то только в пакетной составляющей.
А вот это уже совсем ошибочное мнение, извините за прямоту. Начать с того, что есть, например glibc. А есть еще libmusl, а есть eglibc. А еще есть AppArmor vs SELinux. А кроме пакетных менеджеров есть еще и инит… А еще не то LSB, даже POSIX не все дистрибутивы поддерживают…
Так что, дорогой мой созидатель, пожалуйста, не смешивайте проблемы Linux'а и проблемы DE. Винду, например, можно за гуй ругать — они, по сути, неотделимы друг от друга. В Линухе, исторически так сложилось, мухи отдельно, котлеты отдельно.
Поэтому со стороны разработки ГУИ-фреймворка логично слышать претензии к Гному, к КДЕ, к ТысячиИх. Ругать Линуху за заскоки гнома — странное занятие.
С точки же зрения IDE, т.е. разработческой платформы — тут да, вопросы, вероятно, больше к Linux'у, но среди этих вопросов уж точно нет «ой, трей отпилили». Не представляю, если честно, зачем реально IDE иконка в систрее.
Ну а про «нужны именно системные библиотеки» — нафига тогда во flatpak пихать, если системные нужны? А если уж прижало именно во flatpak — ну, скопируйте системные вовнутрь, в чем, собственно, проблема?
Ослабьте тон и успокойтесь, я читаю ветку целиком до ответа.
Вот вы уже меня обвиняете
Вы ничего ещё не совершили чтобы быть обвиненным.
"Ну конечно при всех раскладах виновато ядро ОС, куда же ещё смотреть кроме как не на самого себя."
Я ни ставлю вас в положение обвиняемого либо виновного этой цитатой. (Мне самому неловко если я слышу что я кого то задел фразой.)
Я хотел сказать, что перед тем как сказать что ядро виновато во всех бедах, сначала проверьте не наляпали ли вы ошибок.
Проследите, пожалуйста, историю дискуссии, если не лень. Дело в том, что я как раз был противником позиции «виноват линукс».
А я представляю сторону "виноваты все, но нужно исправить положение всех".
Предыдущий оратор из ПРОТИВОПОЛОЖНОГО лагеря выдвинул сентенцию «Из вашего Линукса вон системный трей выпилили!» Ну неправда же! Не выпиливали!
Поясню: в Линуксе как таковом системного трея никогда и НЕ БЫЛО.
В ТретьеГноме был, факт. Уродливый и неюзабельный. Да, выпилили.
А в KDE, например, оставили. НО… Оба этих факта к Линуксу как таковому отношение имеют весьма и весьма опосредованное.
Пляски с треем — это ГномоПроблемы.
Не мешайте их с ЛинуксоПроблемами — их и без ГномоПроблем хватает.
Системный трей относится только к оболочкам, но не к ядру или системе!
А пояснение верно. Хотя замечу что Linux это не ОС, а всего лишь ядро.
Если претензии летят в сторону Linux, а не к прим. ArchLinux, то все претензии идут к ядру, а не к ОС(Учти этот факт).
Теперь о моей поизции по UI-тулкиту. Видимо, надо обосновать:
а) слабореализуемо
т.к. каждая платформа имеет свой набор поведений, инструментов, best-practices и т.д. и т.п. Что-то универсальное… Хм, как бы, пробовали уже. Canonical пробовал, Microsoft пробовал. «Конвергенция» не взлетает. На выходе мы имеем «плитки», в которые удобно тыкать пальцем, но чудовищные с точки зрения управления мышью и, уж тем более, клавиатуры. Мы имеем заголовки окон в полэкрана на десктопе, и имеем кнопки 15х15px на смартфонах, в которые вы хрен пальцем попадете.
Хмм… По поводу плиток и плиточного UI, для управления K+M они настолько же удобны как и кнопки которые не удобно тыкать пальцем если они маленькие.
Заголовки окон на полэкрана для XHIDPI только, а вот кнопки для XHIDPI согласен маленькие.
Все универсальное заведомо хуже нативного.
Не все. Что сделано по стандарту без шагов в сторону, то везде будет работать одинаково.
б) расходится с политикой поставщиков ОС
Гайдлайны у каждого свои. И даже можно оформить темы, чтобы оно «нативно выглядело» на каждой платформе. При этом есть еще UX и набор паттернов поведения, которые автоматически не сконвертируешь.
Если все сделано как надо, а именно чисто специфичные для UI toolkit'а функции не используются, то LnF будет везде один и тот же.
Ну вот никак, реально. Все равно придется платформо-зависимую часть пилить, хоть убейся. Или забить просто на native-look-and-feel… Но тогда о какой «полноценной поддержке» можно говорить?
Все реально просто нужно время для каждого отдельно.
в) формально недостижимо
Вот составьте табличку умелок и проставьте галочки, на каких платформах что реализовано. Вот прямо на пункте «значки в трее» ваша затея и поутихнет.
Здесь[in comments] точно нет, но в статье лучше сделать чтобы двигаться дальше или определить направление.
Где-то они есть, где-то не предусмотрены, а где-то плагинами (вы тут плюс или минус ставить будете?)
Галочка, крест и круг(Есть, нет, через костыль)
Короче, никогда у вас вся табличка плюсами не будет заполнена, т.е. ФОРМАЛЬНО НЕДОСТИЖИМО.
Но и составлена моментально не будет, нужно для этого время и много времени
Если говорить про JetBrains, то эти ребята не пытаются взять «универсальный кросплатформенный гуи-фреймворк» и на нем реализовать.
Они пишут свой.
Они запилили «необходимый минимум» под нужные им платформы, и ничего, норм, живут.
У них одна платформа.
При этом запускаются они далеко не под каждым линуксом, например.
Она по большей части базируется на Java хотя и имеет нативные части.
Скажу большее, что их платформа не будет работать на macOS for PowerPC так как нативные части работают только на IA-32 или IA32E. (Хотя у них есть подвижки для ARM)
И не пытаются запилить версию своих DE под мобильные платформы, зная, что они там на фиг не сдались.
IDE на мобильных платформах не шибко нужно.
Да и по поддержке гайдлайнов они не заморачиваются. Одинаково кладут болт на гайды всех платформ, на которых работают.
Они пишут свою платформу, им не нужны гайдлайны.
"Знаешь подвижки в плане «создадим единую пакетную систему для всех Linux-kernel based систем» рано или поздно должны быть."
Вот это тоже не выстрелит. Были уже попытки. Вполне обоснованно не взлетели.
BeOS также не взлетел, хотя это была перспективная ОС. В РФ это точно бы взлетело с учетом ошибки Be Inc., но тут не сложилось, MS сказали OEM'щикам не ставьте это второй системой, потери были колоссальными для Be Inc. на самом деле как в случае их ошибки, так и в случае сделанного MS действия.
Кто-то придерживается политики «ставим только то, что необходимо», и его пакетный менеджер ведет разветвленное дерево зависимостей, а в пакетах тонны метаинформации на тему что-от-чего-зависит-и-в-каком-порядке-ставить.
Кто-то придерживается более утилитарно-интерпрайзного подхода вида «винты дешевые, чо мы паримся», и вот он с икренним недоумением смотрит в количество метаинформации в пакетах первых.
А третий вообще все это пытается в 2-гигабайтную SD-карточку упихать, для него кретинами выглядят и те, и другие.
Есть, вероятно, «золотая середина», которая будет одинаково неудобна всем.
Но зачем?
Смысл сея цитаты был таков, что сделаем минимум для работы системы + добавим универсальный ПМ для использования его пользователем который будет ставить ему софт который ему нужен.
Первые хотят минимального набора для системы. (ArchLinux)
Вторые хотят все нужное. (Red Hat)
Третьи может делают ОСь для Raspberry Pi (Raspbian, Pidora)
"Золотая середина" мне представляется в виде Ubuntu.
Зачем это делается, у каждого свои задачи и для каждой задачи нужны соответствующие инструменты.
"А дисты Linux если и имеют различия то только в пакетной составляющей."
А вот это уже совсем ошибочное мнение, извините за прямоту.
Да в мнении есть ошибка, но мною она не может быть воспринята в принципе.
Начать с того, что есть, например glibc. А есть еще libmusl, а есть eglibc.
Разные реализации ABI, но все равно являются пакетами как ни крути.
А еще есть AppArmor vs SELinux.
А есть и их отсутствие.
А кроме пакетных менеджеров есть еще и инит… А еще не то LSB, даже POSIX не все дистрибутивы поддерживают…
Системы инициализации хоть и работают по разному, но могут быть заменяемыми(Как было в Ubuntu с upstart и systemd).
LSB — предоставляет всего лишь стандартную базу и всё не более, а также стандарт и его реализация не есть обязательное требование.
POSIX — стандарт и его реализация не есть обязательное требование.
Так что, дорогой мой созидатель, пожалуйста, не смешивайте проблемы Linux'а и проблемы DE.
Я вроде и не мешаю друг с другом проблемы и того и другого.
Винду, например, можно за гуй ругать — они, по сути, неотделимы друг от друга.
Оно было так сделано, но сначала всё же это была оболочка для DOS.
В Линухе, исторически так сложилось, мухи отдельно, котлеты отдельно.
В Unix System так сложилось, но это одна из лучших черт Unix систем.
Поэтому со стороны разработки ГУИ-фреймворка логично слышать претензии к Гному, к КДЕ, к ТысячиИх.
Не логично, DE != GUI-Framework.
Претензии к GTK+, GDK и Qt слышать более логично если речь идет об GUI-Framework.
Ругать Линуху за заскоки гнома — странное занятие.
Тут верно.
С точки же зрения IDE, т.е. разработческой платформы — тут да, вопросы, вероятно, больше к Linux'у, но среди этих вопросов уж точно нет «ой, трей отпилили».
Не больше к Linux чем к компонентам Linux-based OS.
Не представляю, если честно, зачем реально IDE иконка в систрее.
Пример, нарисовать balloon-notification с сообщением что компиляция завершена.
Ну а про «нужны именно системные библиотеки» — нафига тогда во flatpak пихать, если системные нужны? А если уж прижало именно во flatpak — ну, скопируйте системные вовнутрь, в чем, собственно, проблема?
А про техническое задание ничего не слышали?
Если в ТЗ указано что надо сделать и ещё указано что разработать это для Flatpak, а также сказано использовать системные библиотеки другой версии и при этом их нельзя бросать в Flatpak-пакет, то хочешь не хочешь но по заданию должен будешь сделать как там указано.
>> А пояснение верно. Хотя замечу что Linux это не ОС, а всего лишь ядро.
>> Если претензии летят в сторону Linux, а не к прим. ArchLinux, то все претензии идут к ядру, а не к ОС(Учти этот факт).
Вот я и намекнул предыдущему оратору, что он с претензией по трею не по адресу. И, в качестве сарказма, написал, мол, трей — виновато ядро, фон рабочего стола — виновато ядро. Вы восприняли это за мое личное мнение. Это сарказм был.
>> Хмм… По поводу плиток и плиточного UI, для управления K+M они настолько же удобны как и кнопки которые не удобно тыкать пальцем если они маленькие.
>> Заголовки окон на полэкрана для XHIDPI только, а вот кнопки для XHIDPI согласен маленькие.
Все же, согласитесь, плитки таки менее удобны для клава-мышь. Не критично, но менее удобны, чем классическое меню.
Подсказка №1: объем телодвижений между соседними пунктами меню, и между плитками в разных углах экрана.
Подсказка №2: меню реализует древовидную иерархию, причем с возможностью видеть предыдущую ступень иерархии целиком. На плитках — нереализуемо. Не могу сказать, что эта самая иерархия — то, без чего совершенно невозможно обойтись, но таки штука временами удобная.
>> Не все. Что сделано по стандарту без шагов в сторону, то везде будет работать одинаково.
Имеется в виду, что везде будет работать одинаково не-нативно?
>> Если все сделано как надо, а именно чисто специфичные для UI toolkit'а функции не используются, то LnF будет везде один и тот же.
Ну, т.е. да, не нативно. Чем тогда Qt/QML не угодил? Хотя ладно, не будем вдаваться в холивары.
Короче, определиться нужно: одинаково-на-всех-платформах vs нэйтив-лук-энд-фил. Либо-либо. Вот тут нельзя сесть на 2 стула сразу.
>> Галочка, крест и круг(Есть, нет, через костыль)
Ну, т.е. вы согласны, что всю табличку заполнить галочками невозможно? Это и называется формально недостижимо.
О ДжетБрейнс
>> Они пишут свой.
О чём я и упоминал: свой с необходимым минимумом. Если хотите, MVP.
>> У них одна платформа.
В смыыыысле? Win/Lin/MacOS — одна? Или Java одна? Т.е. гуи-фреймворк поверх Xamarin/.Net, запущенный на Win/Lin/MacOS — это РАЗНЫЕ платформы, а гуи-фреймворк поверх Java, запущенный на Win/Lin/MacOS — ОДНА. Здорово живем!
>> Они пишут свою платформу, им не нужны гайдлайны.
Вот я и пытаюсь выяснить, все же: в AvaloniaUI — тот же подход «нам не нужны гайдлайны, у нас своя платформа», или таки «везде нативненько». Просто предыдущий оратор декларировал одно, а описывал совершенно другое.
>> Смысл сея цитаты был таков, что сделаем минимум для работы системы + добавим универсальный ПМ для использования его пользователем который будет ставить ему софт который ему нужен.
Знаете же историю про «14 конкурирующих стандартов»? Универсальный ПМ не взлетит. Их и так достаточно.
Так что оставьте уже базовый ПМ в покое. Логичнее сделать надстройку над базовым ПМ с рюшечками и кнопочками. Ну так есть уже. И тоже не одна штука.
>> Да в мнении есть ошибка, но мною она не может быть воспринята в принципе.
А зря.
>> Разные реализации ABI, но все равно являются пакетами как ни крути.
Ну, т.е. в тот же Debian вы можете просто пакетом положить libmusl и ничего не изменится? Какбэ, есть мнение, что у вас полсистемы отвалится. Пакет — это такая штука, которая, концептуально, не влияет на работоспособность системы в целом, и при замене на аналог не требует пересборки всей остальной системы. Ну, т.е. libc, конечно, ставится пакетом, но, как правило, это формальность. Это часть базовой системы. Хотите заменяемости libc — положите рядом еще один репозиторий целиком, собранный на новой версии libc. Странное поведение для рядового пакета, не?
>> LSB — предоставляет всего лишь стандартную базу и всё не более, а также стандарт и его реализация не есть обязательное требование.
Ну да, это всего лишь спецификация с рекомендациями на тему «чего в этих ваших линуксах должно быть». И если уж строить IDE, работающее поверх набора системных инструментов, стоит завязываться именно на подобную спецификацию, а не на мифический «Линукс». Линукс слишком неоднороден.
>> POSIX — стандарт и его реализация не есть обязательное требование.
С POSIX'ом — аналогично.
Дело в том, что если вы пишете IDE под набор каких-то системных библиотек и с учетом наличия какого-то «стандартного инструментария», вы изначально предполагаете, что он есть. А это не факт. Самое логичное — завязаться на спеку вроде LSB, или написать свою, мол, для работы нам нужно (дальше список...). Не пытайтесь реализовать сборку под ВСЕ линуксы, иначе неизбежны моменты удивления типа «как так ping'а нету???».
В конечном итоге, достижимо создание продукта под некоторое подмножество Linux-based осей, и сильно лучше будет, если это подмножество будет формализовано, желательно с указанием спецификации, что, в каком виде, каких версий и почему нужно для всего комбайна в целом.
>> Не логично, DE != GUI-Framework.
В том и проблема, что логично… DE — desktop environment, т.е. ОКРУЖЕНИЕ рабочего стола. Со своим набором look-n-feel, пользовательских паттернов, гайдлайнов и прочим. Если эти части проигнорировать, то «родным» приложение не будет выглядеть ни на одной из платформ. Т.е. будем одинаково средненько везде. Вот, допустим, изначально заточенное под винду приложение имеет менюху вверху, кнопки действий внизу под активным содержимым. Берете «как есть», переносите в окружение третьегнома… На выходе в третьегноме есть набор изначально системных приложений с право-верхним расположением кнопок и без глобального меню, и ваше — белая ворона. И так на каждую пару окружение-окружение. С линуксом сложность еще и в том, что линукс, условно, один, и все системы на его базе воспринимаются как единое целое, а между тем набор поведений, принятый в гноме, будет так же дико смотреться на KDE, как и принесенный из MacOS.
>> Претензии к GTK+, GDK и Qt слышать более логично если речь идет об GUI-Framework.
Вот тут вы что-то перепутали. В споре о гуи-фреймворках, согласен, слышать претензии к GTK+ и Qt. GDK-то при чем? Это же просто низкоуровневая библиотека примитивов, используемая как бэкенд GTK? Это же не GUI-фреймворк?
>> Пример, нарисовать balloon-notification с сообщением что компиляция завершена.
Например, для данного случая, есть 2 пути:
1. Поступить как ДжетБрейнс — реализовать нотификашки внутри окна приложения, безотносительно трея.
2. Поступить «правильным путем». Допустим, в том же Gnome используется libnotify. Отлично оповещает, к слову.
>> А про техническое задание ничего не слышали?
Допустим слышал. Так это свободный проект энтузиастов, или вы на зарплате?
>> Если в ТЗ указано что надо сделать и ещё указано что разработать это для Flatpak, а также сказано использовать системные библиотеки другой версии и при этом их нельзя бросать в Flatpak-пакет, то хочешь не хочешь но по заданию должен будешь сделать как там указано.
Надо, например, указать разработчику ТЗ на «противоречащие параграфы» этого самого ТЗ.
1. Собрать во flatpak
2. Системные библиотеки
3. «другой версии» — это отличные от тех, которые есть в системе?
4. нельзя все это хозяйство положить внутрь flatpak
Вот прям реально невыполнимо. Ну нельзя flatpak'у давать доступ к системному /usr, он именно с этой целью и делался, чтобы у него туда доступа не было!
Ну и вообще, как-то странно звучит «использовать системные библиотеки другой версии». Это, в смысле, такие же, как в базовой системе, но другой версии? А почему же не положить их в SDK-пакет? Просто «хотелка» постановщика задач? А почему ему никто не сказал, что так не делается?
Перед тем как писать комментарий убедитесь что включили markdown и пишите синтаксисом markdown, так легче читать и писать.
Вы восприняли это за мое личное мнение. Это сарказм был.
Есть люди которые не понимают сарказма. (Я один из этих людей.)
Все же, согласитесь, плитки таки менее удобны для клава-мышь. Не критично, но менее удобны, чем классическое меню.
Большее не удобство для мыши чем для клавиатуры. ИМХО
Что плитки что меню.
Подсказка №1: объем телодвижений между соседними пунктами меню, и между плитками в разных углах экрана.
Не подсказка, действительность.
Подсказка №2: меню реализует древовидную иерархию, причем с возможностью видеть предыдущую ступень иерархии целиком.
Также как и с первой.
На плитках — нереализуемо.
Можно попытаться, но будет выглядеть немного коряво.
Не могу сказать, что эта самая иерархия — то, без чего совершенно невозможно обойтись, но таки штука временами удобная.
Временами да, временами нет.
MS сейчас идет в сторону унификации всего что им доступно.
Начиная от их мобильных устройств(мертвы) до ХабЦентра(Surface Hub если я не ошибаюсь)
Имеется в виду, что везде будет работать одинаково не-нативно?
Я имею в виду что будет правильное преобразование в нативное, для DE.
Чем тогда Qt/QML не угодил?
QML я пока нормально не пользовал, тормоза из-за HW не позволяют нормально его использовать.
А на Qt вроде что-то пытался создать, только это сразу улетело в мусорный бак.
Хотя ладно, не будем вдаваться в холивары.
Холивары всегда были и всегда будут, но я за трезвую позицию участников. (А ведь холивары получаются разве что из-за пустяков.
У продукта есть недостаток, но те кто говорят что мол этот недостаток есть значит ничтожество этот ваш продукт другие принимают это за оскорбление себя как пользователей продукта вместо того чтобы просто принять это как есть.)
Короче, определиться нужно: одинаково-на-всех-платформах vs нэйтив-лук-энд-фил. Либо-либо. Вот тут нельзя сесть на 2 стула сразу.
Никаких "vs.".
Одинаково на всех платформах — принцип унификации, но тут всегда будет хотя бы одна платформа которую унификацию не потерпит и сделает по своему.
Native Look n' Feel — принцип стандартизации, а тут будет такое где есть стандарт то может быть и унифицируют.
Ну, т.е. вы согласны, что всю табличку заполнить галочками невозможно?
Принципиально ничто нельзя заполнить лишь единицами либо нулями.
Это и называется формально недостижимо.
Тогда все что принципиально то формально недостижимо. Гениально!
Прим. Вы полететь на Луну не сможете. Формально недостижимо. А через время сможете по вашей логике?
В смыыыысле?
В прямом.
Win/Lin/MacOS — одна? Или Java одна?
Одна.
Т.е. гуи-фреймворк поверх Xamarin/.Net, запущенный на Win/Lin/MacOS — это РАЗНЫЕ платформы, а гуи-фреймворк поверх Java, запущенный на Win/Lin/MacOS — ОДНА. Здорово живем!
Ищите Intellij Platform, либо загляните на GitHub JetBrains
Вот я и пытаюсь выяснить, все же: в AvaloniaUI — тот же подход «нам не нужны гайдлайны, у нас своя платформа», или таки «везде нативненько».
Но скорее всего первый подход.
Просто предыдущий оратор декларировал одно, а описывал совершенно другое.
kekekeks может ответит на ваш вопрос когда-нибудь.
Знаете же историю про «14 конкурирующих стандартов»?
Нет не знаю, но как будет возможность прочту.
Универсальный ПМ не взлетит. Их и так достаточно.
0install, Snap, Flatpak…
Этого да достаточно, пользователю точно.
Так что оставьте уже базовый ПМ в покое.
Логичнее сделать надстройку над базовым ПМ с рюшечками и кнопочками.
Первое противоречит второму.
Ну так есть уже. И тоже не одна штука.
Synaptic(APT-DPKG, APT-RPM), Pamac(ALPM(Можно использовать и без pacman. Но по умолчанию он использует его.)), YaST(Zypper-RPM) etc.
Это только графические.
А зря.
Причина?
Почему это так я описал тогда следующим.
Ну, т.е. в тот же Debian вы можете просто пакетом положить libmusl и ничего не изменится?
Но это же Essential Package, следовательно полсистемы ругнется.
Какбэ, есть мнение, что у вас полсистемы отвалится.
Это мнение я и озвучил.
Пакет — это такая штука, которая, концептуально, не влияет на работоспособность системы в целом, и при замене на аналог не требует пересборки всей остальной системы.
Неверно. Влияние системы от пакета нельзя установить ни коем образом пока его содержимое не будет проверенно в полевых условиях.
Ну, т.е. libc, конечно, ставится пакетом, но, как правило, это формальность.
Это часть базовой системы.
Формально да ставится пакетом, но это и не совсем часть базовой системы.
Больше прослойка
Хотите заменяемости libc — положите рядом еще один репозиторий целиком, собранный на новой версии libc.
Скорее замените один из репозиториев.
Так кстати в Debian и сделано, но правда для ядер.
(-kfreebsd, -hurd, -elibc это LinuxLernel + elibc(если я не ошибся), для LinuxKernel + libc нет постфикса)
Странное поведение для рядового пакета, не?
А кто сказал что это рядовой пакет?
Часть информации пропускаю, много писать.
GDK-то при чем?
Это же просто низкоуровневая библиотека примитивов, используемая как бэкенд GTK?
Это же не GUI-фреймворк?
Скорее моя ошибка, по привычке пишу GDK, вместо GTK. Но речь вы поняли.
Например, для данного случая, есть 2 пути:
- Поступить как ДжетБрейнс — реализовать нотификашки внутри окна приложения, безотносительно трея.
- Поступить «правильным путем». Допустим, в том же Gnome используется libnotify. Отлично оповещает, к слову.
Либо внутри, либо DBus тогда уж.
Оба варианта правильные, но случай с balloon-notification попал не в те ворота(Это для Windows).
Допустим слышал.
Тут нужен четкий ответ.
Да, слышал и знаю что такое ТЗ.
Или
Нет, я не слышал этого понятия. (На этом разговор будет закончен.)
Так это свободный проект энтузиастов, или вы на зарплате?
Я не на зарплате и да это свободный проект энтузиастов.
А разве свободный проект не может быть сделан по ТЗ?
Надо, например, указать разработчику ТЗ на «противоречащие параграфы» этого самого ТЗ.
Его слушать будут? (Только если тот кто дал задание не упертый балбес.)
- Собрать во flatpak
- Системные библиотеки
- «другой версии» — это отличные от тех, которые есть в системе?
- нельзя все это хозяйство положить внутрь flatpak
Вот прям реально невыполнимо. Ну нельзя flatpak'у давать доступ к системному /usr, он именно с этой целью и делался, чтобы у него туда доступа не было!
А с этим сталкиваются и часто, но делают же.
Flatpak сам ведь использует /usr => и его приложения могут использовать /usr.
Видимо от этой логики все и идет.
Большее не удобство для мыши чем для клавиатуры. ИМХО
Что плитки что меню.
Можно попытаться, но будет выглядеть немного коряво.
MS сейчас идет в сторону унификации всего что им доступно.
Начиная от их мобильных устройств(мертвы) до ХабЦентра(Surface Hub если я не ошибаюсь)
Ну, т.е. на выходе имеем некоторый "компромисс" между универсальностью и удобством конечного пользователя. Что-то неудобно для пальца, что-то неудобно для клавиатуры, что-то для мыши. Зато одинаково и "одинаково терпимо" для всех… Просто всем "не совсем удобно", но никаких поводов для обид — все страдают.
И вот так с "конвергенцией" каждый раз… И не только у "Майков".
Я имею в виду что будет правильное преобразование в нативное, для DE.
А вот тут сразу две собаки зарыты:
- либо частичный отказ от кроссплатформенности (т.е. с наборами API, доступными отдельно для каждой из платформ), либо абстракция во все поля с универсальными интерфейсами для платформоспецифичных возможностей (фактически, то же самое, но с переносом философских сложностей на сторону разработчиков фреймворка)
- если говорить про "правильное преобразование в нативное, для DE" (заметьте, это именно ваша формулировка), то и целевой платформой для GUI-фреймворка должно быть DE, а не "Linux". Т.е. не Windows, MacOS, Linux, а Windows, MacOS, Gnome, KDE, тысячи их, и это еще не вдаваясь в специфику версий.
Есть "универсальное преобразование", и есть "правильное". "Универсальное" — это когда везде одинаково с точностью до закорючки, а "правильное" — это когда по стайлгайдам самого DE. И вот тут — либо крест снимать, либо рясу в трусы не заправлять.
Одна.
Всё-таки, простите за занудство: одна Java или одна платформа? Возможно, сами DE и поддерживают ровно одну IntelliJ-платформу, а платформа-то сколько систем поддерживает?
Если мы говорим про Avalonia-UI, то сравнивать его надо с IntelliJ, а она поддерживает достаточно много целевых платформ, и платформозависимого кода там достаточно много.
Если мы говорим об IDE на базе Avalonia-UI, то, простите, с таким подходом он тоже поддерживает одну целевую платформу — Avalonia-UI. Плюсом, конечно, идет специфика инструментария разработки, специфичного для платформ, но тут, уж извините, ровно с такими же сложностями сталкивается и IntelliJ — тоже тянут слой совместимости для работы с системозависимыми инструментами.
Короче, разницы особо не видно. Может, я чего-то не углядел. Может, вы мне поясните. В чём разница между кроссплатформенной, поддерживающей множество систем вашей IDE и семейством продуктов JetBrains, которые, как оказалось, не кроссплатформенные?
Нет не знаю, но как будет возможность прочту.
Сильно не заморачивайтесь, это просто комик-мем.
"Представляешь, есть 14 конкурирующих стандартов для <вставить нужное>. Необходимо срочно разработать один новый, универсальный, который объединит в себе преимущества и опыт всех имеющися" => "Работа, работа, работа" => "Представляешь, есть 15 конкурирующих стандартов для..."
0install, Snap, Flatpak…
Этого да достаточно, пользователю точно.
Synaptic(APT-DPKG, APT-RPM), Pamac(ALPM(Можно использовать и без pacman. Но по умолчанию он использует его.)), YaST(Zypper-RPM) etc.
Это только графические.
Самое забавное то, что половина всего этого хозяйства родилась именно как попытка создать "универсальный, подходящий всем..." инструмент для управления пакетами.
В конечном итоге, есть apt, есть dnf, есть yum и т.д. и т.п. При этом набор умелок у них, в общем и целом, весьма сходный. Если нужен "инструмент для рядового пользователя, который не разбирается в этих ваших консолях" — без проблем, их есть уже, и при этом они, как правило, часть DE. Пусть и будут. Красивое окошко с рюшечками и кнопочками, которое по нажатию кнопочек тупо шпилить команды в нижележащий ПМ.
Сам-то нижележащий ПМ, простите, заради чего унифицировать? Даже будь формат пакетов одинаковый, установка пакета, собранного под, допустим, Fedora26 в Ubuntu12.04 — достаточно мутная затея. В конце концов, если сильно прижало, есть тот же alien, который вполне сконвертирует пакет. И, по-прежнему, это будет мутная идея.
Потому что линуксы различаются, все же, не только набором пакетов. В конце концов, пакет, собранный для F17 не стоит ставить на F26, а вы предлагаете "единый формат" запилить, и таскать между дистрибутивами?
В конце концов, есть уже "единый и универсальный формат", давно уже есть. *.tar.gz — реально универсальный, и работает везде! Зачем еще один?
Либо внутри, либо DBus тогда уж.
Оба варианта правильные, но случай с balloon-notification попал не в те ворота(Это для Windows).
Вот об этом я выше и говорил. Либо имеем некоторый API, который в линуксе обертывает DBus (к слову, не во всех этих ваших линуксах DBus есть...), а в винде, например, болтает иконкой в трее. Либо имеем две сущности: DBus(который надо дергать в Linux), и TrayIcon(который надо дергать в винде). Оба варианта рабочие, но оба два, простите, выглядят немного костыльно.
Тут нужен четкий ответ.
Слышал, знаю, даже периодически работаю по ТЗ. В случае нереализуемости ТЗ имею привычку сообщать об этом заказчику, прилагая варианты изменения оного до наступления полной реализуемости. Достаточно четко?)
А разве свободный проект не может быть сделан по ТЗ?
Тут, какбы, формулировка зыбкая. ТЗ — это "техническое задание", которое предполагает наличие двух сторон процесса — принимающей ("Заказчика") и выполняющей ("Исполнителя"). И вот тут мотивация первого понятна — он получает продукт. В чём мотивация второго в свободном проекте без оплаты? В случаях самомотивации второй стороны, как мне кажется, оная сторона вполне имеет право отклонить какие-то из требований ТЗ. Или нет?
В случае же общности сторон (т.е. отсутствия ярко выраженных ролей заказчик-исполнитель), как мне кажется:
- не стоит использовать формулировку "ТЗ", хотя, это уже не мое дело
- можно и нужно, как минимум, обсуждать требования оного ТЗ и соразмерять "хотелки" с "умелками"
Его слушать будут? (Только если тот кто дал задание не упертый балбес.)
А если давший задание — упёртый балбес… Какбэ, кхм… А почему вы его лесом не послали, например? Или не сказали: "Надо? Прям никак без этого? Сделай!" Чем он вас мотивирует? Он держит ваших родственников в заложниках? Бьёт? Угрожает? Шантажирует?
Упёртый балбес, руководящий проектом, как правило, имеет печальное влияние на судьбу проекта в целом. Если разработчиков сильно более одного, и весомая часть считает руководителя неправым упёртым балбесом… Ну, форкнуться можно же?
Flatpak сам ведь использует /usr => и его приложения могут использовать /usr.
Видимо от этой логики все и идет.
Ну раскройте уже глаза "постановщику задачи". Ссылку на официальную документацию дайте, что ли, почитать.
Вот прямо оттуда:
Each runtime can be thought of as a /usr filesystem. Indeed, when an application is run, its runtime is mounted at /usr.
Рантайм флатпака — это, условно, его /usr. В момент запуска приложения, содержимое его рантайма монтируется как /usr. Вот ровно то, что в рантайме пакета лежит, в /usr для флатпака и будет. Надо системные библиотеки? Скопируйте. Надо другие версии — положите куда требует спецификация. Не хотите класть — ищите другие инструменты.
Ну, т.е. на выходе имеем некоторый "компромисс" между универсальностью и удобством конечного пользователя. Что-то неудобно для пальца, что-то неудобно для клавиатуры, что-то для мыши. Зато одинаково и "одинаково терпимо" для всех… Просто всем "не совсем удобно", но никаких поводов для обид — все страдают.
Только лучше бы этих страданий не было.
Вместо этого вопрос для каждого элемента интерфейса: А как для вас лучше выглядит этот элемент?
Тогда будет меньше страданий для каждого из интерфейсов управления, но только пользователи будут говорить "А почему не из коробки? И зачем так много вопросов?".
А вот тут сразу две собаки зарыты:
- либо частичный отказ от кроссплатформенности (т.е. с наборами API, доступными отдельно для каждой из платформ), либо абстракция во все поля с универсальными интерфейсами для платформоспецифичных возможностей (фактически, то же самое, но с переносом философских сложностей на сторону разработчиков фреймворка)
- если говорить про "правильное преобразование в нативное, для DE" (заметьте, это именно ваша формулировка), то и целевой платформой для GUI-фреймворка должно быть DE, а не "Linux". Т.е. не Windows, MacOS, Linux, а Windows, MacOS, Gnome, KDE, тысячи их, и это еще не вдаваясь в специфику версий.
Есть "универсальное преобразование", и есть "правильное". "Универсальное" — это когда везде одинаково с точностью до закорючки, а "правильное" — это когда по стайлгайдам самого DE.
Тут так или иначе, одно без другого не может.
Всё-таки, простите за занудство: одна Java или одна платформа?
Это не занудство, но уточнение.
В данном случае я хотел сказать что одна Java и одна платформа на Java.
Возможно, сами DE и поддерживают ровно одну IntelliJ-платформу, а платформа-то сколько систем поддерживает?
Поддерживает(Нативные части) macOS, Windows 32/64, Linux-kernel based OS 32(min k2.6.32)/64(min k2.6.32)/ARM(32 min k2.6.26), но с универсальной платформой на Java, а также не зависимо от GUI-Framework'а.
Если мы говорим про Avalonia-UI, то сравнивать его надо с IntelliJ, а она поддерживает достаточно много целевых платформ, и платформозависимого кода там достаточно много.
Avalonia-UI это фишка kekekeks, подобные вопросы перенаправляйте на него. AvaloniaUI/Avalonia@GitHub
Но раз заговорили про Avalonia то это как IntelliJ Platform, но базируется не только для IDE и не на Java, а на .Net Framework(Что сразу скажет о прямой принадлежности к Windows, и необходимости тянуть за собой .NetCore либо Wine с Wine-mono, Mono и .Net Framework(ver=?))
Если мы говорим об IDE на базе Avalonia-UI, то, простите, с таким подходом он тоже поддерживает одну целевую платформу — Avalonia-UI. Плюсом, конечно, идет специфика инструментария разработки, специфичного для платформ, но тут, уж извините, ровно с такими же сложностями сталкивается и IntelliJ — тоже тянут слой совместимости для работы с системозависимыми инструментами.
- IntelliJ более многоплатформенна чем Avalonia-UI.
- IntelliJ рассчитана для применение в IDE, но не прочих приложений. (Однако тут лучше спросить самих JetBrains)
Короче, разницы особо не видно. Может, я чего-то не углядел. Может, вы мне поясните. В чём разница между кроссплатформенной, поддерживающей множество систем вашей IDE и семейством продуктов JetBrains, которые, как оказалось, не кроссплатформенные?
Разница между IntelliJ и Avalonia приведена в пункте выше.
Но конкретно продуктов на IntelliJ Platform у них совместно используются как Нативные части для оповещения об измененных файлах, так и многоплатформенные скрипты использующие Python(!) служащие для печати переменных среды и перезапуска IDE, а также скрипты на sh для запуска самой IDE, запуска IDE в режиме Formatting и Inspect, кроме того используются Java библиотеки(Куда же без них если проект написан на Java) и основная часть платформы использует Java+Kotlin которые являются кроссплатформой.
Сильно не заморачивайтесь, это просто комик-мем.
Ясно.
Самое забавное то, что половина всего этого хозяйства родилась именно как попытка создать "универсальный, подходящий всем..." инструмент для управления пакетами.
Тоже верно.
В конечном итоге, есть apt, есть dnf, есть yum и т.д. и т.п. При этом набор умелок у них, в общем и целом, весьма сходный. Если нужен "инструмент для рядового пользователя, который не разбирается в этих ваших консолях" — без проблем, их есть уже, и при этом они, как правило, часть DE. Пусть и будут. Красивое окошко с рюшечками и кнопочками, которое по нажатию кнопочек тупо шпилить команды в нижележащий ПМ.
Умелки хоть и сходные, алгоритмы у них разные по большей части.
Те ПМы которые я перечислил по большей части универсальны для каждой DE, разве что Pamac больше для GNOME 3 создан.
Сам-то нижележащий ПМ, простите, заради чего унифицировать?
Вот тут согласен что не нужно унифицировать, но привести в соответствие набор установочных скриптов. У RPM свои у DPKG свои и чаще не совместимы друг с другом.
APT в данном случае пытается быть универсальным как к DPKG для которого он создавался, так и для RPM.
ALPM в данном случае будет как залетная птица так как установочный скрипт там всего один на пакет если он вообще присутствует и там нет разделения на PreInstall, Install, ReInstall, PostInstall, PreRemove, Remove, PostRemove и Setup стадии установки пакетов.
Даже будь формат пакетов одинаковый, установка пакета, собранного под, допустим, Fedora26 в Ubuntu12.04 — достаточно мутная затея. В конце концов, если сильно прижало, есть тот же alien, который вполне сконвертирует пакет. И, по-прежнему, это будет мутная идея.
Вот тут alien просто выполняет преобразование пакета RPM в DPKG и на оборот, только это костыль с которым нужно мирится, но даже после конвертации пакет может быть не работоспособным, его нужно всё равно допиливать руками.
Потому что линуксы различаются, все же, не только набором пакетов. В конце концов, пакет, собранный для F17 не стоит ставить на F26, а вы предлагаете "единый формат" запилить, и таскать между дистрибутивами?
С первым предложением можно спорить до бесконечности(Закончим спор на эту тему, он бесполезен никто ничего не добьется.), но как мне подсказывает опыт ArchLinux всё же есть отличие в наборе пакетов.
Второе предложение, верное, но с оговоркой в плане установочных скриптов в пакете.
Единых форматов пока 6: 0install, Snap, Flatpak, AppImage, PackedApp(tar.gz/tar.xz/etc.), sourcecode.
В конце концов, есть уже "единый и универсальный формат", давно уже есть. *.tar.gz — реально универсальный, и работает везде! Зачем еще один?
Согласен много форматов ненужно.
Вот об этом я выше и говорил. Либо имеем некоторый API, который в линуксе обертывает DBus (к слову, не во всех этих ваших линуксах DBus есть...), а в винде, например, болтает иконкой в трее.
DBus нужен не везде поэтому его в некоторых дистрибутивах нет. И только в этом случае TrayIcon выручает, хотя и не сильно. (Так или иначе некоторые разработчики оставляют этот механизм, если:
А) DBus не поддерживается ОС
Б) DE не поддерживает DBus/libNotify
В) Хочется чтобы было(!))
Либо имеем две сущности: DBus(который надо дергать в Linux), и TrayIcon(который надо дергать в винде).
Описано выше.
Оба варианта рабочие, но оба два, простите, выглядят немного костыльно.
Да костыльно, но если другого выбора нет.
Слышал, знаю, даже периодически работаю по ТЗ. В случае нереализуемости ТЗ имею привычку сообщать об этом заказчику, прилагая варианты изменения оного до наступления полной реализуемости. Достаточно четко?)
Да, это достаточно четко.
Тут, какбы, формулировка зыбкая. ТЗ — это "техническое задание", которое предполагает наличие двух сторон процесса — принимающей ("Заказчика") и выполняющей ("Исполнителя"). И вот тут мотивация первого понятна — он получает продукт. В чём мотивация второго в свободном проекте без оплаты? В случаях самомотивации второй стороны, как мне кажется, оная сторона вполне имеет право отклонить какие-то из требований ТЗ. Или нет?
Только если требования заказчика обязательны к исполнению.
В случае же общности сторон (т.е. отсутствия ярко выраженных ролей заказчик-исполнитель), как мне кажется:
- не стоит использовать формулировку "ТЗ", хотя, это уже не мое дело
- можно и нужно, как минимум, обсуждать требования оного ТЗ и соразмерять "хотелки" с "умелками"
По мнению некоторых у любой разработки есть техническое задание. (С этим{здесь} мнением я не согласен.)
Поэтому первое согласен.
Второе если документ не подписан с одной из сторон.
А если давший задание — упёртый балбес…
Порой такие заказчики встречаются.
А почему вы его лесом не послали, например?
Послать начальника вы не осмелитесь, если от него будет зависеть ваша жизнь.
Или не сказали: "Надо? Прям никак без этого? Сделай!"
Для такого балбеса, это будет звучать так. «Не хочу не буду это делать.»
Чем он вас мотивирует?
Если от этого будет зависеть ваша жизнь, вам придется делать то что он скажет.
Он держит ваших родственников в заложниках? Бъёт? Угрожает? Шантажирует?
А это уже похоже на виды преступления. Если на хоть один из этих вопросов ответ будет носить утвердительный характер, то соответствующие статьи закона требуется поднять. Но после такого придется искать другого заказчика(Если захочется работать.).
Упёртый балбес, руководящий проектом, как правило, имеет печальное влияние на судьбу проекта в целом.
Спору нет.
Если разработчиков сильно более одного и весомая часть считает руководителя неправым упёртым балбесом…
Постучат руководителю начальника на начальника проекта либо потребуют его заменить, если объединятся коллективом.
Ну, форкнуться можно же?
Да, можно если лицензия это позволяет. (Большинство пермиссивных лицензий позволяют.)
Ну раскройте уже глаза "постановщику задачи". Ссылку на официальную документацию дайте, что ли, почитать.
Вот прямо оттуда:
Each runtime can be thought of as a /usr filesystem. Indeed, when an application is run, its runtime is mounted at /usr.
Если ещё согласится это читать.
Рантайм флатпака — это, условно, его /usr. В момент запуска приложения, содержимое его рантайма монтируется как /usr.
За перевод спасибо.
Вот ровно то, что в рантайме пакета лежит, в /usr для флатпака и будет.
Надо системные библиотеки? Скопируйте.
Надо другие версии — положите куда требует спецификация.
Не хотите класть — ищите другие инструменты.
Вроде можно использовать опцию share для системных либов другой версии, разве нет?
Я думаю что лучше диалог попытаться сократить. Следующие мои комментарии будут содержать ответы не на все вопросы, так как уже трудновато перечитывать всю ветку целиком и приходится использовать текстовый процессор для написания текста вместо встроенного здесь редактора вставки текста.
- Чуточку оффтопа: вы адекватней, чем показались на первый взгляд.
Вместо этого вопрос для каждого элемента интерфейса: А как для вас лучше выглядит этот элемент?
Пожалуйста, не надо! Подавляющее количество людей (включая и меня) не способны с ноля по опроснику создать что-то вменяемое и юзабельное в плане look-n-feel и юзабилити. Такой треш будет...
Тут так или иначе, одно без другого не может.
Т.е. мы пришли к согласию, что для GUI-фреймворка целевой платформой логичнее считать Desktop Environment, либо, в случае "нативного" исполнения, ориентироваться на уникальные связки DE+OS, чем на OS?
Но раз заговорили про Avalonia (здесь много поскипано, чтобы не захламлять пост)...
Ну, т.е., по сути, собирается оно на тех же принципах, что и любые Java-приложения, только на .Net.
Тут была копипаста ваших высказываний про DBus, пакетные менеджеры и установочные сценарии, но она куда-то сократилась...
Смысл, КМК, в том, что различия уровня есть/нет DBus, SELinux vs AppArmor, SystemD/other Init, доступные версии библиотек, реализация libc и т.д. и т.п. делают "универсальные" форматы пакетов на "уровне" нативных пакетных менеджеров бессмысленными. На выходе мы получим либо жестоко неюзабельное в ощутимом количестве дистрибутивов поделие, либо дикий оверхед по "умелкам" пакета.
Оставь в пакете только само приложение без специфических правил — чем оно лучше тарболла? Убейся предусмотреть все окружения, куда его вкорячить попробуют — все равно все не предусмотришь, только устанешь.
Вот и получается, что "универсальное" решение — это "песочница" + "зависимости включены". Эдакий chroot-на-стероидах со всеми вытекающими. И изоляция, и "свой рут" и "пользуйтесь тем, что внутри". Фактически, если абстрагироваться от деталей реализации, тот же flatpak — вполне себе замена JVM, например. Вот тебе "виртуальное окружение", вот тебе "рантайм", вот тебе "набор доступных API".
При этом можно, конечно, сколько угодно называть flatpak "пакетным менеджером нового поколения", "универсальным пакетным менеджером", но… Брехня все это. Ставить что-то мелкое flatpak'ом — из пушки по воробьям, оверхедом раздавит. Ставить что-то системное — забодаешься изоляцию побеждать. Вот и имеем flatpak — платформа распространения приложений, а не пакетный менеджер.
Послать начальника вы не осмелитесь, если от него будет зависеть ваша жизнь.
Если от этого будет зависеть ваша жизнь, вам придется делать то что он скажет.
Вы меня пугаете! У вас там точно, всё нормально? Может, спасать уже надо?
Странное какое-то отношение к "начальнику". Особенно учитывая, что вы говорили, что проект открытый, свободный, на самомотивации...
Вроде можно использовать опцию share для системных либов другой версии, разве нет?
Вот этот: --share=SUBSYSTEM?
Не, этот нельзя:
Share a subsystem with the host session. This overrides the Context section from the application metadata. SUBSYSTEM must be one of: network, ipc...
- (вольный перевод) Расшарить подсистему хостовой сессии. Перекрывает секцию "Контекст" из метаданных приложения. SUBSYSTEM может быть: network (сеть), ipc (inter-process-communication, вероятно имеются в виду сокеты/порты, по аналогии с докеровским EXPOSE).
Насколько я помню с того раза, когда читал доки (возможно, что-то и изменилось, но это будет пахнуть уже сменой концепции), слой может быть SDK и Runtime. В первом — все необходимое, чтобы собрать приложение под второй. По логике, единственный вариант использование flatpak'а в IDE — саму IDE натравливать на SDK, а полученный от сборки выхлоп крутить в Runtime.
Если нужно поконпелять под какие-нибудь микроконтроллеры и прочие отличные от вашей системы — соберите SDK, в нем компилируйте. Потом перекладывайте куда надо. Собрать SDK-слой с "системными либами" достаточно просто — сложить в него либы/заголовки/компиляторы и прочие нужные для сборки вещи с хоста. Это и есть "кошерный вариант". А полученный бинарный выхлоп можно будет положить "как есть" в хостовую систему — и он заведется. Вот это я и предлагал как "сценарий". Если "руко-водитель" считает, что надо иначе — вас мне жаль, а разработчикам flatpak'а в этом вопросе я доверяю больше, чем вашему руководителю.
Чуточку оффтопа: вы адекватней, чем показались на первый взгляд.
Скорее вы меня смогли понять. Я был по большей части адекватен и останусь таковым.
Пожалуйста, не надо! Подавляющее количество людей (включая и меня) не способны с ноля по опроснику создать что-то вменяемое и юзабельное в плане look-n-feel и юзабилити. Такой треш будет...
Если человек хочет полную универсальность то пусть будет этот опросник, да фест тайм ужасно, но потом уже не будет.
Т.е. мы пришли к согласию, что для GUI-фреймворка целевой платформой логичнее считать Desktop Environment, либо, в случае "нативного" исполнения, ориентироваться на уникальные связки DE+OS, чем на OS?
Целевая платформа будет определяться количеством пользователей для кого она будет сделана. (Скорее к мобильным устройствам, чем к стационарным.)
Ориентировка на DE+OS вместо OS привлекательнее для пользователей. (Но тут необходимо следовать Guideline, Styleguide, etc.)
Ну, т.е., по сути, собирается оно на тех же принципах, что и любые Java-приложения, только на .Net.
У CIL другие принципы сборки, кардинально хотя и не особо отличающиеся от сборки Java.
Смысл, КМК, в том, что различия уровня есть/нет DBus, SELinux vs AppArmor, SystemD/other Init, доступные версии библиотек, реализация libc и т.д. и т.п. делают "универсальные" форматы пакетов на "уровне" нативных пакетных менеджеров бессмысленными. На выходе мы получим либо жестоко неюзабельное в ощутимом количестве дистрибутивов поделие, либо дикий оверхед по "умелкам" пакета.
В ArchLinux так и сделано, но он не умеет оверхэд, не может SELinux/AppArmor (Соответствующую правку надо сделать для их работы).
Только мне кажется что в ArchLinux это сделано так как надо, а не как попало. (DPKG/RPM по сравнению с libALPM+pacman выглядят ну очень громоздко)
Оставь в пакете только само приложение без специфических правил — чем оно лучше тарболла?
А как по вашему в ArchLinux сделано? Именно так, хотя и добавляются install(в редчайших случаях, для пред/пост установки), .buildinfo(содержащий необходимую для сборки информацию), .pkginfo(содержащий минимальную информацию о пакете), .MTREE(архив, содержащий файловую структуру пакета) и само приложение. Ничего более.
Убейся предусмотреть все окружения, куда его вкорячить попробуют — все равно все не предусмотришь, только устанешь.
Тут сильно предусматривать и заморачиваться не нужно, окружения сами сделают как надо.
flatpak — вполне себе замена JVM
Придираюсь, так как неверно.
Пакетный менеджер не может быть виртуальной машиной как и виртуальная машина не может быть пакетным менеджером.
Вот и имеем flatpak — платформа распространения приложений, а не пакетный менеджер.
А пакетный менеджер разве не являлся/-тся платформой распространения приложений?
Вы меня пугаете! У вас там точно, всё нормально? Может, спасать уже надо?
Да, нормально, спасать не нужно, это просто одна из возможных ситуаций которая может произойти с любым человеком.
Странное какое-то отношение к "начальнику".
Кому как, зависишь от руководства, то соответственно такое отношение и будет.
Особенно учитывая, что вы говорили, что проект открытый, свободный, на самомотивации...
Всякое может быть, это просто одна из ситуаций которая может встретится.
Вот этот: --share=SUBSYSTEM?
Не, этот нельзя.
Понял, посмотрел, ключ filesystem=/[:ro] вроде можно юзать.
С последними согласен.
Ориентировка на DE+OS вместо OS привлекательнее для пользователей. (Но тут необходимо следовать Guideline, Styleguide, etc.)
О чём я и говорю. "Красиво" — это когда смотрится и ведёт себя так, "как будто здесь и родилось". Сконвертировать на автомате не получится, т.к. сильно разные наборы сущностей. Поддержка "платформоспецифичных" вещей по накладным расходам не сильно дешевле "написания нативного GUI", а потому не особо, имхо, осмыслены.
Другое дело, что для IDE такое поведение (нативное для среды) не надо. "Одинаково везде" для IDE логичней.
У CIL другие принципы сборки, кардинально хотя и не особо отличающиеся от сборки Java.
Различается техпроцесс, этапы, форматы и т.д. Детали реализации, в смысле. На выходе результат примерно один: виртуальная машина, исполняющая универсальный байткод. Собрал один раз, запускаешь внутри аналогичной виртуальной машины на любой из доступных под эту ВМ систем.
Для flatpak'а условной виртуальной машиной (корректнее, наверное, будет формулировка "виртуальное окружение") является его /usr. Своеобразная гарантия, что все, что собрано под лежащие в /usr вещи с аналогичным /usr запустятся. А преследуемые цели — аналогичные JVM и .NET.
В ArchLinux так и сделано, но он не умеет оверхэд, не может SELinux/AppArmor (Соответствующую правку надо сделать для их работы).
Ну, т.е. "пакеты ArchLinux мне кажется правильными, но один хрен не подходят для использования в других дистрибутивах". Т.е. нужно взять пакет арча, распаковать, допилить под него набор правил, перепаковать метаданные (выпилить арчеспецифичные, допилить специфичные для своей платформы), пересобрать цели и упаковать заново в формат пакета, отличный от арчевского… вероятно, в нативный, подходящий для платформы? Где универсальность-то? Зачем эти телодвижения? Если пакет все равно пересобирать, логичнее собирать его из source-tarball'а, или из репозитория исходных кодов. Мне кажется, что арч-пакет в этой цепочке сильно лишняя сущность.
А как по вашему в ArchLinux сделано? Именно так, хотя и добавляются install(в редчайших случаях, для пред/пост установки), .buildinfo(содержащий необходимую для сборки информацию), .pkginfo(содержащий минимальную информацию о пакете), .MTREE(архив, содержащий файловую структуру пакета) и само приложение. Ничего более.
Для Debian'а — мало, для alpine — много. Зачем?
Пакетный менеджер не может быть виртуальной машиной как и виртуальная машина не может быть пакетным менеджером.
Давайте попробуем абстрагироваться от деталей реализации и подумаем о декларируемых целях и функционале. Flatpak — он нужен для того, чтобы собрать/скомпилить приложение, упаковать его в некую сущность, и запустить "как есть" на всех целевых линуксах. JVM, .NET — они для того, чтобы собрать/скомпилить приложение, упаковать его в некоторую сущность, и запустить "как есть" на всех целевых платформах.
Не кажется, что функционал похож? Поэтому и говорю, что Flatpak НЕ пакетный менеджер.
А пакетный менеджер разве не являлся/-тся платформой распространения приложений?
Нет, пакетный менеджер — инструмент управления пакетами. Сравните цели существования пакетных менеджеров и платформы распространения приложений (на примере того же Flatpak'а).
Пакетный менеджер:
- проанализировать дерево зависимостей пакетов;
- вкорячить содержимое пакета + его зависимости;
- определить совместимость пакетов между собой, разрулить конфликты;
- установить в систему нативное (собранное под конкретную целевую платформу, вероятно, оптимизированное под нее) приложение/библиотеку/набор сущностей, оптимально подходящее именно этой системе, нужной (при этом конкретно определенной) версии;
- определить и автоудалить неиспользуемые версии пакетов, оставить только нужные зависимости;
- получить консистентную систему с приложениями (каждое в единственном экземпляре) оптимальных версий.
Цели платформы распространения приложений:
- забрать приложение со всеми зависимостями конкретно нужных приложению версий одним куском;
- обеспечить гарантированную работу приложения поверх слоя совместимости на всех целевых платформах.
Чуете разницу: нужные нативные, собранные конкретно под целевую платформу библиотеки/приложения и их зависимости vs собранное единожды приложение + слой совместимости.
Итого, Flatpak НЕ есть классический пакетный менеджер, а классический пакетный менеджер НЕ есть платформа распространения приложений.
Да, нормально, спасать не нужно, это просто одна из возможных ситуаций которая может произойти с любым человеком.
В теории произойти она может. Но назвать нормальной ситуацию, в которой, по вашим словам, "от начальника зависит твоя жизнь" сложно.
Кому как, зависишь от руководства, то соответственно такое отношение и будет.
Честно говоря, сильная зависимость от руководства, особенно до уровня "зависит сама жизнь" — серьёзный повод пересмотреть свой подход к жизни и начать в ней что-то менять.
Либо просто пафос...
Понял, посмотрел, ключ filesystem=/[:ro] вроде можно юзать.
Можно, в принципе. Но костыль, при этом "чреватый".
Ну, т.е. "пакеты ArchLinux мне кажется правильными, но один хрен не подходят для использования в других дистрибутивах".
Не правильно поняли.
Я имел ввиду что ему не нужны Overhead, SELinux и AppArmor.
Т.е. нужно взять пакет арча, распаковать, допилить под него набор правил, перепаковать метаданные (выпилить арчеспецифичные, допилить специфичные для своей платформы), пересобрать цели и упаковать заново в формат пакета, отличный от арчевского…
Забей на меты. Достаточно install и файлов программы.
вероятно, в нативный, подходящий для платформы? Где универсальность-то? Зачем эти телодвижения?
Описано выше.
Если пакет все равно пересобирать, логичнее собирать его из source-tarball'а, или из репозитория исходных кодов.
Это уже AUR.
Для Debian'а — мало, для alpine — много. Зачем?
Debian-like/RHEL-like хочет много X,Y,Z которые не нужны никому другому.
Alpine ставится из сорсов через AUR.
Не кажется, что функционал похож?
Нет, он не похож.
Итого, Flatpak НЕ есть классический пакетный менеджер, а классический пакетный менеджер НЕ есть платформа распространения приложений.
Частично функции распространителя приложений в классическом пакетном менеджере(не DPKG и не RPM, но в libALPM/pacman) все таки имеются. Процедура получения пакета приложения к примеру.
А слой совместимости здесь это лишнее.
В теории произойти она может. Но назвать нормальной ситуацию, в которой, по вашим словам, "от начальника зависит твоя жизнь" сложно.
Честно говоря, сильная зависимость от руководства, особенно до уровня "зависит сама жизнь" — серьёзный повод пересмотреть свой подход к жизни и начать в ней что-то менять.
Повод к жизни сменить все же сложнее.
Легче смирится.
Можно, в принципе. Но костыль, при этом "чреватый".
Чреват чем? Он же как Read-only доступен.
Я имел ввиду что ему не нужны Overhead, SELinux и AppArmor.
Собственно, исключить много чего можно. Но тогда о какой универсальности может идти речь?
Забей на меты. Достаточно install и файлов программы.
Какбы от пакета еще, как минимум, стоило бы получать информацию еще о зависимостях, например. Иначе чем лучше configure-make-make install? И даже преимущества над tar -xzvf -C / становятся достаточно спорными...
Debian-like/RHEL-like хочет много X,Y,Z которые не нужны никому другому.
Ну т.е. debian-based и rh-based дистрибутивы (которых, стоит таки признать, подавляющий процент) со своими запросами идут лесом…
Это нормально, если, допустим, на 80% целевых дистрибутивов ваш пакет будут сначала распаковывать, а потом перепаковывать во что-то другое, пригодное для использования в целевом дистрибутиве? Source-tarball для мейнтейнеров мейнстрима будет предпочтительней, т.к. этап "распаковки" и парсинга чужого и, не побоюсь этого слова, чуждого пакета можно будет опустить. Странный подход к универсальности, стоит признать.
Alpine ставится из сорсов через AUR.
Куда, простите, ставится? Вообще ни разу не слышал о каком-либо сродстве Alpine Linux и арчевского AUR...
Нет, он не похож.
Не похожа реализация. Функционал и целеполагание — абсолютно монопенисуальное.
Частично функции распространителя приложений в классическом пакетном менеджере(не DPKG и не RPM, но в libALPM/pacman) все таки имеются. Процедура получения пакета приложения к примеру.
А слой совместимости здесь это лишнее.
Ни dpkg, ни rpm пакетным менеджером не являются. Пакетный менеджер поверх dpkg называется apt, например. И решает он, в первую очередь, НЕ проблему получения пакета или приложения. Вот реально, не для того весь сыр-бор. Эта "проблема" — наименьшая из проблем, стоящих перед пакетным менеджером. Для решения таковой все эти сложности с графами зависимостей и т.д. не нужны — тут и tar + набор sh-скриптов по необходимости справится.
Даже проблема корректного удаления пакета — более сложный процесс, чем процесс получения оного. А первейшая задача пакетного менеджера — руление зависимостями между пакетами.
Понимаете, в чем разница. Основная цель apt'а или yum'а, заради которой они создавались — автоматически разрулить адЪ, содомЪ и гоморру с зависимостями. Остальное — приятный бонус.
Основная цель Flatpak'а — именно доставка приложения. Причем не всякого и не любого, а конкретно заточенного и собранного под соответствующий рантайм. Он абстрагирован от зависимостей, с рулением сущностей на уровне flatpak'а справится третьеклассник. Дерево сущностей примитивное и ацикличное. Не рулит flatpak зависимостями, а просто приносит их вместе с приложениями и складывает в песочницу. Зато гарантия, что не пересекутся — песочницы-то разные.
Повод к жизни сменить все же сложнее.
Вот к этому я не призывал. Я призывал сменить ПОДХОД к жизни, никак не повод. Мотивация к жизни — это несколько более "нижний" уровень самопознания и биологического выживания вида. С этим уже к психологу, наверное… Ну или к философу, на крайний случай.
Чреват чем? Он же как Read-only доступен.
- Изоляция несовершенна, "побег из турьмы возможен".
- Затевалось все заради стабильного предсказуемого API/рантайма. Прокиньте туда хостовый /usr, и сразу имеем 2 вопроса:
- куда делась кроссплатформенность, портируемость?
- заради чего вообще городили весь этот городок с flatpak'ом, если изоляцию и стабильность API/рантайма только что выкинули.
Короче, первая претензия к этому подходу в том, что на этом этапе flatpak становится лишней ограничивающей сущностью, не приносящей никакой реальной пользы. Зачем обертка, если рантайм системный?
Но тогда о какой универсальности может идти речь?
Универсальность в отсутствии онного. Достаточно только ACL поддерживать, а он есть в любой Linux-kernel based OS, исключая совсем единицы.
Иначе чем лучше configure-make-make install?
PreCompiled vs. CompileSource, Первое для сокращения времени установки, второе как оптимизация под конкретное железо.
И даже преимущества над tar -xzvf -C / становятся достаточно спорными...
50/50
Как раз пакеты libALPM имеют формат tar.xz.
Это нормально, если, допустим, на 80% целевых дистрибутивов ваш пакет будут сначала распаковывать, а потом перепаковывать во что-то другое, пригодное для использования в целевом дистрибутиве?
AUR так в принципе и сделан. (Покрайней мере часть из прекомпиленых файлов)
Куда, простите, ставится?
Упс, май фолт. Я думал об клиенте Alpine, а не о дистрибутиве Alpine.
Ни dpkg, ни rpm пакетным менеджером не являются.
СТОООП! RPM Это и формат пакета, и пакетный менеджер! (Внимание! RPM — Это… Пакетный Менеджер!)
А DPkg это тоже что и RPM.
Только замечу они выполняют роль минимального классического пакетного менеджера.
Пакетный менеджер поверх dpkg называется apt
А поверх RPM APT разве не идет? Посмотрите в сторону ALTLinux.
Изоляция несовершенна, "побег из турьмы возможен".
Все что можно использовать взламывается. (Только нужно время, и это говорилось не один раз.)
куда делась кроссплатформенность, портируемость?
Они никуда не деваются, но сохраняются.
заради чего вообще городили весь этот городок с flatpak'ом, если изоляцию и стабильность API/рантайма только что выкинули.
В любом случае изоляция не всегда работает и не всегда нужна.
А стабильность API/Runtime в случае ломаной изоляции сохраняется.
Зачем обертка, если рантайм системный?
Обертка нужна для других функций.
OFF-TOPIC: С этой темой начинаю уставать.
Пишу это сообщение с вечера на ночь.
Универсальность в отсутствии онного. Достаточно только ACL поддерживать, а он есть в любой Linux-kernel based OS, исключая совсем единицы.
Т.е., вкратце, смысл задумки:
- Имеем пакет как некую сущность
- Этот пакет в чистом виде "как есть" не способен установиться и заработать "из коробке" в подавляющем числе дистрибутивов Linux.
- Называем пакет "универсальным".
Что-то никак не пойму, в чем смысл "универсальности"? Для кого этот "пакет"?
В любом случае изоляция не всегда работает и не всегда нужна.
А стабильность API/Runtime в случае ломаной изоляции сохраняется.
Не совсем понимаю, каким образом она сохраняется.
- Допустим, в flatpak'е лежит приложуха, которая хочет библиотеку my-awesome-lib2.16.57.so. Точно такая же, как на машине разработчика, сидящего, предположим, на Арче.
- В целевой системе, допустим, Ubuntu, лежит my-awesome-lib2.3.12.so.
- Предположим, в Fedora — my-awesome-lib2.4.47.so.
- В пакетном рантайме — ровно нужная версия.
Вы, вместо пакетного рантайма, подсовываете системный хостовый… И получаете печаль.
То, что отлично работало на машине разработчика, при запуске на Ubuntu отказывается работать вообще, а на Федоре ведет себя странно.
"Кроссплатформенность" покрывается медным тазиком...
Обертка нужна для других функций.
В случае flatpak'а "обертка" и "изоляция", в первую очередь, и делаются для того, чтобы упакованное в него приложение имело ровно те версии библиотек в рантайме, которые ему нужны. Поэтому системный /usr и отрезают, чтобы не возникало путаницы. Случаи, когда приложение, по какой-то причине, хочет именно системный /usr — не для упаковки во flatpak.
Просьба не спамить меншнами, у вас тут очень много букв, а что qrKot — тролль с ЛОРа я уже и так понял.
Для упаковки авалонии мы будем из коробки использовать dotnet-packaging, в который я недавно добавил поддержку deb-пакетов. Любители несовместимых с Debian/RHEL дистрибутивов и флетпаков вольны с ними разбираться самостоятельно.
Просьба не спамить меншнами
Я не спамил, а лишь указал что вы автор проекта AvaloniaUI и вопросы по поводу него попросил его переводить вам.
qrKot — тролль с ЛОРа я уже и так понял
Не знал.
Любители несовместимых с Debian/RHEL дистрибутивов и флетпаков вольны с ними разбираться самостоятельно.
В Arch проще реализовать пэкэджинг, только нужно будет сделать соответствующий PKGBUILD.
Я думаю что внести поддержку этого в репо будет несложно.
Не знал.
И не знайте. То, что я тролль с ЛОРа — дважды неправда. Не тролль, и не с ЛОРа.
В Arch проще реализовать пэкэджинг, только нужно будет сделать соответствующий PKGBUILD.
Сори за откровенность, но немного напоминает классику "кулик+болото". Не важно же, проще/не проще. Вариантов же всего два, делать/не делать. Т.е. добавлять проекту еще один формат пакетов, или забить.
В Arch проще реализовать пэкэджинг, только нужно будет сделать соответствующий PKGBUILD.
И иметь проблемы с тем, что всё ломается раз в полгода. Проходили уже, поддерживать тулинг для этого счастья желания нет никакого.
И иметь проблемы с тем, что всё ломается раз в полгода.
Если забывать про PartialUpgrade, то да будет ломаться.
Проходили уже, поддерживать тулинг для этого счастья желания нет никакого.
Достаточно формировать PKGBUILD затем вызвать makepkg и не более.
Если забывать про PartialUpgrade, то да будет ломаться.
Вы же понимаете, что претензия не к пакетному менеджеру, а таки к Арчу в целом? Точнее к Rolling-Release модели...
Проходили уже, поддерживать тулинг для этого счастья желания нет никакого.
Достаточно формировать PKGBUILD затем вызвать makepkg и не более.
Дык, формулировка предыдущего ответа, вроде как, достаточно четко дает понять "мы не тратим времени на поддержку маргинальных дистрибутивов". Т.е. никто не будет заморачиваться, будет просто декларировать "универсальный GUI-фреймворк" и "весь Linux" в качестве целевой платформы, отказываясь ограничивать список поддерживаемых линуксов.
Точнее к Rolling-Release модели...
Никто не мешает делать слайсы из роллинга.
Дык, формулировка предыдущего ответа, вроде как, достаточно четко дает понять "мы не тратим времени на поддержку маргинальных дистрибутивов".
А я и не говорю "поддерживайте дистрибутив", я говорю "просто генерируйте файл и создайте пакет". (Пользователи AUR и Arch сами разберутся как это настроить, ещё и в Wiki напишут если у них будет такая возможность.) Ну а так слова были мне понятны.
И иметь проблемы с тем, что всё ломается раз в полгода. Проходили уже, поддерживать тулинг для этого счастья желания нет никакого.
Ну т.е. целевая платформа таки не все линуксы, а только мейнстрим?
Я не говорю, заметьте, что это в корне неверное решение с вашей, как разработчика, стороны. Оно даже, скорее, правильное. Логичнее сделать нормальный отлаженный рабочий инструмент под ограниченное количество окружений, чем глюкавое поделие "для всех". И поддержка сборок — она тоже вещь "небесплатная", что только оттянет лишние силы.
Но вы настолько настаиваете на безусловной кроссплатформенности своего фреймворка… что я не могу не указать вам на нецелесообразность и нереализуемость декларируемых вами "умелок".
Ну т.е. целевая платформа таки не все линуксы, а только мейнстрим?
Ну вот я и говорю, что линукс как целевая платформа отсутствует в принципе. Вместо этого чёртов зоопарк и кривые костыли типа флэтпака.
Так что подход простой: хотите экзотику — пожалуйста, разбирайтесь сами со сборкой зависимостей, с очередной шизой создателей очередного дистрибутива, с упаковкой всего этого счастья и т. п. Я от этого всего счастья устал и бесплатно на общественных началах заниматься этим не буду.
Об этом я тут распинался на протяжении десятков сообщений, что не будет у линукса нормальной доли рынка, пока на поддержку зоопарка чудо-платформ с очередной дичью надо тратить столько ресурсов.
Так что подход простой: хотите экзотику — пожалуйста, разбирайтесь сами со сборкой зависимостей, с очередной шизой создателей очередного дистрибутива, с упаковкой всего этого счастья и т. п. Я от этого всего счастья устал и бесплатно на общественных началах заниматься этим не буду.
Вас и не заставляют.
Этим займутся DUR'ы. Я имел в виду "Distributive User Repo".
а что qrKot — тролль с ЛОРа я уже и так понял.
"С ЛОРа" — абсолютно безосновательно. В последний раз был там года три назад.
"тролль" — какая-то ваша личная безосновательная проекция на несогласных с вами людей...
Для упаковки авалонии мы будем из коробки использовать dotnet-packaging, в который я недавно добавил поддержку deb-пакетов. Любители несовместимых с Debian/RHEL дистрибутивов и флетпаков вольны с ними разбираться самостоятельно.
Как интересно все повернулось, собственно:
Начало разговора
- Я: Flatpak не подходит для ваших задач.
- Вы: Начальник сказал, должно быть во Flatpak.
- Я: С целевыми линуксами будьте поскромнее, поддерживайте мейнстрим.
- Вы: Линуксы все одинаковые, будем поддерживать скопом.
Сейчас:
- Вы: "Любители несовместимых с Debian/RHEL дистрибутивов и флетпаков вольны с ними разбираться самостоятельно."
- Вы: qrKot — тролль с ЛОРа, а я весь белый, пушистый и во всем прав...
Т.е. пришли примерно к тому, что я говорил в самом начале. И при этом я — тролль, а вы — на коне и весь в чём-то белом...
Ваша аргументация построена на уровне .Net Framework не ломается. Если под Linux заиметь аналог — проблема решится?
Фреймворк — частный случай одного из стабильных апи, который по сути даёт базовую функциональность для работы кода на использующих его языках. Его наличие не отменяет API самой платформы, которое должно быть хоть сколько-нибудь стабильным. На линуксе нельзя рассчитывать на то, что у вас в собранном приложении будет через пару лет нормально работать UI, вывод аудио/видео, доступ к криптографическим примитивам и системному хранилищу сертификатов. Это базовые вещи, проблемы с которыми нельзя обойти используя подход "всё своё ношу с собой". Будет стабильность с ними — можно будет хотя бы спокойно делать толстые архивы на полгигабайта, но которые с гарантией везде заведутся. Сейчас этого нельзя сделать.
А в целом, есть QT, Unity и OpenGL — вроде довольно стабильные вещи.
Есть. Но тот же трей всё равно сломан, просто потому что его намеренно сломали.
Значит там просто не будет показываться иконка, если человек использует gnome без плагина для system tray. Чем это отличается от людей, которые сделают так?
Учитывая, что, скорее всего, в куче дистров по умолчанию добавят к gnome системный трей.
в 80% случаев проще поставить linux + wine, чем заводить старое приложение на windows 10
По-моему, если уже стоит 10, то проще всё же во встроенном в 10 hyper-v поставить старую винду, чем всё сносить и ставить линукс
По-моему, если уже стоит 10, то проще всё же во встроенном в 10 hyper-v поставить старую винду, чем всё сносить и ставить линукс
Может и проще использовать гипервизор, но не у всех он работает.
А коробка(VBox) многих не устраивает, поэтому ставят Linux и не используют компатибилити мод для приложения. Однако желающих установить Linux на ПК всё же меньше чем тех кто просто забьет на единственное не работоспособное приложение.
Поддерживаю на все сто. Сколько ни было попыток перехать и виндовые потребности переселить в вайны и виртуалки — на разгребание косяков времени не хватает. И даже от Vbox VMWare Workstation отказался в пользу HV. Ubuntu и Centos, не говоря уже о Windows(нам же не Win98 поднимать), там отлично живут, FreeBSD особо не глючит, и всегда можно за минуты перекинуть виртуалку на мощный хост, когда ресурсы потребуются.
А то говно, которое и на тот момент не работало в корпоративной NT, очевидно, что и сейчас не будет работать.
Речь о линуксе на десктопе. На серверах же, да через терминал, система, да, замечательна.
P. S. У меня Linux на десктопе. Мы прощаем недостатки тем, кого любим :)
P. P. S. OSX ближе всего придвинулась к идеалу для обывателя, но уши нормальных юниксов торчат и там — попробуйте, например, без ныряния в консоль наладить автомонтирование NFS или бэкап на линуксовую самодельную TimeMachine.
Однако попытки всё же были сделать для пользователей основной осью Ubuntu. Вроде да можно на Desktop ставить, но с некоторым оборудованием(Чаще графические карты AMD(Некоторые видюшки(Чаще устаревшие серии ATI) даже с xf86-driver-ati не способны были работать и требовали каталист который не может с новым Xorg работать) и nVidia(Хотя Nouveau может основные особенности карт, но людям нужен полный функционал и после установки драйвера на nVidia пинают Linux за нерабочий драйвер), реже модемы(если кто-то ими пользуется, частично исключая USB-модемы), да принтеры(У LBP3010 до сей пор нет нормального CUPS драйвера(Librelike драйвера))) начинаются проблемы. (Да всё скомкано, но вроде ничего не забыто за что пользователи ОС с ядром Linux.)
Попытки были, но потом у Марка закончились деньги на благотворительность.
С nVidia история такая, что разработчики ядра намеренно вставляют им палки в колёса, не давая сделать нормальную поддержку оптимуса. Погуглите по "nvidia dma-buf gpl-only".
Что, впрочем, не мешает некоторым дистрам это исправлять.
Да, посмотрел.
Нет доступа к внутриядерному буферу DMA, так как считают что DMA-BUF не может быть экспортированным.(Спасибо, Alan Cox и его сторонники.)
Как я заметил ещё и Optimus'у сказали прощай.
С одной стороны да разработчики правильно сделали что запретили структуры и функции ядра не совместимые с GNU GPL.
Другой стороны те фишки которые nVidia может внести в Nouveau не входят в планы самой nVidia.
У nVidia есть хорошо работающий проприетарный драйвер. Ядро пишут последователи церкви пресвятого равноапостольского Столлмана, которые не хотят, чтобы этот работающий проприетарный драйвер обеспечивал поддержку Optimus. Вот и вся история.
Которые не хотят отдавать кусок функционала ядра в проприетарщину навсегда, потому что обычно это плохо заканчивается?
Жаль, что они не могут сделать просто интерфейс для этого, конечно.
У nVidia есть хорошо работающий проприетарный драйвер.
Работает не во всех дистрибутивах к сожалению.
Ядро пишут последователи церкви пресвятого равноапостольского Столлмана, которые не хотят, чтобы этот работающий проприетарный драйвер обеспечивал поддержку Optimus.
Ядро пишу в соответствии с лицензией и пожеланиями пользователей(и некоторых компаний/корпораций(Вспоминается что Microsoft принимает участие в развитии Linux.), но не с производителями чипов и PU(Intel делает свою продукцию свободной(но не исправления микрокода) => ей по барабану, а AMD поддерживает как GPL-only составляющую так и non-GPL притом обе работают нормально.)).
А не только "самые праведные" последователи Столмана.
Потому что есть принципы за которые люди используют это ядро, и условное большинство на текущий момент не на стороне nVidia, возможно они смотрят немного дальше в будущее и понимают что нельзя идти на поводу некоторых производителей, по крайней мере пока есть хоть какая-то альтернатива.
В итоге мы уже десять лет мучаемся костылями в виде Bumblebee. А я на своём ноуте не могу нормально подключить монитор через HDMI.
Но вы занимайтесь, занимайтесь популяризацией. Вместо решения проблем, которые осознанно и злонамеренно никто не собирается решать.
в последние годы ноутбуков с выделенной видеокартой явное меньшинство, если вы про заботу о массах, то вашим случаем как раз заниматься нет смысла (казалось бы есть смысл для nVidia, но они считают что возможность программно разделять продукцию на классы им более важна чем работа их видеокарт на открытых драйверах).
Если вы о заботе о конкретных пользователях, то вам нужно обращаться к производителю ноутбука, или покупать тот который работает.
Ну я так и понял, что мне предлагается со своей видеокартой идти в пешее эротическое по религиозным причинам.
У не продающихся в магазине продуктов есть одна неприятная особенность, нельзя заставить продавца вам их продать.
Почему-то на ум приходит аналогия когда кто-то покупает дорогую спортивную машину с просветом в 5 см. а потом требует срезать лежачие полицейские на въезде во двор и отменить ограничения скорости, т.к. не может из-за этого использовать машину "по максимуму".
Linux как любой "бесплатный" продукт разрабатывает группа людей, в первую очередь решает задачи поставленные этими людьми. У этих людей есть идеи которые они продвигают, увы ресурсы не безграничны а некоторые производители не хотят делиться своей интеллектуальной собственностью что приводит к ситуации, когда некоторые функции не могут быть реализованы в конкретной системе в конкретный момент времени.
Есть технология Optimus, которая корректно работает на Windows и OSX, где nVidia никто не заставляет никому показать исходники, потому что боженькаСтоллман так хочет.
Есть конкретная группа людей, которые по религиозным соображениям не дают её реализовать для Linux.
Есть другая группа людей, которые страдают из-за первой.
Есть третья группа, которая ни ко вторым, ни к первым отношения не имеет, зато имеет мнение о том, как правильно, и рассказывает в комметариях на хабре про машины и автомобили.
Первые достойны уважения хотя бы за то, что делают ядро. Вторые достойны права не любить первых ввиду доставленных неудобств. Третьи… третьи достойны разве что порицания.
В данный момент ситуация, скорее, патовая, и навешивание ярлыков «прав», «не прав», «фанатик» и «религиозные убеждения» ничего не изменит и мир, тем более, не спасет.
Есть конкретная группа людей, которая «пилит» ядро Linux. Они, что логично, определяют то, как ядро должно работать, и какие его части для чего предназначены.
Есть Nvidia, которая, по вполне очевидным причинам, в модель, данную разработчиками ядра, «ложиться» не хочет. Для того, чтобы заработало «как задумано», нужно предоставить спецификации.
Учитывая открытую модель разработки ядра, спецификации придется предоставить в открытый доступ, т.е. всем желающим. Открытые же спецификации позволят «разлочить» некоторый функционал на более бюджетных моделят видеокарт Nvidia, что неизбежно уронит покупки более дорогих девайсов.
Т.е., с одной стороны, есть совершенно четкие и определенные спецификации, которые гарантируют корректную работу драйвера при соответствии API, и нежелание разработчиков ядра положить болт на свои спеки мало того, что понятно, так еще и похвально. При этом есть нежелание Nvidia урезать свои доходы, которое не менее понятно, но, в данном контексте, значительно менее похвально.
Почему такой попы нет на Windows/osX? Также совершенно очевидно. Обе системы закрыты, т.е. спецификации не «утекут». На предоставлении спецификаций производителям проприетарных систем Nvidia не теряет в доходах.
Первые достойны уважения хотя бы за то, что делают ядро. Вторые достойны права не любить первых ввиду доставленных неудобств.
В данном контексте первые — весьма достойные люди безо всяких «хотя бы за». Право вторых же «не любить первых» весьма сомнительно. В конце концов, проблема создана не на ровном месте, а по вполне объективным причинам. Так что вторым можно порекомендовать, скорее, отказаться от продукции Nvidia в пользу Intel/AMD. Нет, не потому, что Nvidia плохая или что-то подобное, а потому, что, по объективным причинам, реализовать корректную работу вышеозначенной продукции в рамках Linux не представляется возможным. Если же корректная работа Nvidia-девайса более приоритетна, чем операционная система, может быть, вторым просто поменять ОС?
После обновления черный рабочий стол и все остальное за исключением иконок. Можно только открыть консоль через ctrl+alt+f1 и все. Я уверен что проблема из-за gtx 970 для который стояли сторонние дрова. Или, как вариант, проблема в unity.
Все же в винде не нужно переустанавливать систему каждый год после выхода обновлений.
Все же в винде не нужно переустанавливать систему каждый год после выхода обновлений.
Ну вот это, как раз, не совсем правда… Безгеморройный апгрейд между мажорными версиями винды — это, скорее, из разряда фантастики.
:) а я как-то терял win после обновления на 8ке, пришлось ручками атишевский драйвер сносить и переставлять.
И терял возможность загрузиться в debian 8 после обновления (и до сих пор, уже после обновления на 9-й он шразиться только с доп параметрами ядра (и это на одной и тойже hd6970) о чём это говорит? Я думаю о стечении обстоятельств ), не повезло что с той что с другой системой ;)
Вот вы в своём же примере и указываете (предположим что не работает) на очень маленький процент текущих пользователей, абсолютное большинство же использует full-hd и меньше.
Также мне почему-то кажется что не работает конкретно ваша связка, у меня работает нестандартный ноут с 1440x1050 и монитор на десктопе с adobergb deepcolor и 1920х1200 при этом в панели выбора есть и большие разрешения(проверить не на чем).
Все говорят что в линукс-сообществе проблема в сообществе и его нежелании признавать проблемы. И вот вы говорите мне: да не нужен
Так что «обойдешься и перебьешься» это плохой подход, лучше стремиться сделать хорошую работу.
Я не говорю что ненужен, я такой же пользователь как и вы, и тоже с проблемами, и понимаю что конфигурация phenomII+hd6970 не самая распространённая и мягко говоря устаревшая.
Я просто напоминаю про то что ресурсов сделать правильно нет, а делать неправильно, есть печальный опыт.
Хорошо бы просто создать фирму которая будет выпускать чипы аналоги по ТТХ nVidia и при этом с теми-же ценами и открытыми драйверами, но увы лишних пары сотен миллиардов долларов у сторонников открытого и свободного ПО нет, как и нет денег на покупку oracle и открытие кода БД и компонентов, как нет возможности создать полностью бесплатную и свободную версию jira и т.д.
Внутренний API линуксового ядра вполне намеренно и осознанно сделан нестабильным, чтобы не тормозить его развитие. Так что о стабильном ABI драйверов мечтать не приходится. Совместимость API/ABI с юзерспейсом держат на уровне и на том спасибо, осталось либописателей и дистрибутивостроителей вылечить, тогда можно будет использовать это счастье как целевую платформу.
p.s. насчёт каждый 20-й это явно завышенная оценка.
Linux на десктопе годится только для гиков и профессионалов, которые знают, на что идут, выбирая его своей основной ОС.
Скажите это тем кто ставит линукс своим знакомым т.к. сам в нем понимает и считает их компы чуть-ли не своей собственностью (:
Итого: 6 подопечных линукс десктопов/ноутбуков. Потребности: Скайп, одноклассники. Вирусов нет, все прекрасно работает. Система годами не требуют вообще никакого надзора.
На один старичок — комп пришлось ставить хубунту, очень старое железо, но ничего он оказался еще вполне пригоден. Еще лет пять спокойно шуршал винтами. Для такой аудитории линукс несомненное благо.
Насчет блага — можно поспорить. Сталкивался с проблемами подключения фотоаппарата, принтера, телефона к компу на убунте, когда действие «воткнул и работает», в винде, у пользователя убунты превратилось «приезжай и настрой». Мне свое время дорого слишком, чтоб решать чужие проблемы.
Первый — когда пользователь очень продвинутый, знает его кишки и может (а, главное, хочет) всё настроить.
Второй — наоборот, пользователь абсолютный чайник, имеет всего пару-тройку типовых сценариев использования и никуда больше не лезет. Интернетик, одноклассники, переписка, музычка. Ему настраивают систему, кладут на рабочий стол несколько иконок и говорят — тыкай сюда. И тогда действительно всё окей. Сегодня много людей, у которых 95% компьютерной жизнедеятельности происходит в браузере. И почта в браузере, и музычка, и всё остальное. А браузеры работают хорошо. Почему хорошо? Да потому что все браузеры — это коммерческий софт.
Но Линукс совершенно не катит для очень обширного среднего слоя пользователей (большинства), которым от компьютера нужно много чего разного, но знаниями админа они не обладают. Или обладают, но не хотят их применять вне работы — таких тоже немало.
|Для обывателя он как был бесконечно далёк от иделала 10 лет назад, так бесконечно далёк и сейчас.
Почему-то у меня складывается ощущение что обыватель в данном понимании это обязательно играет в нативные ресурсоёмкие игры и пользуется купленным photosop-ом, но кто же тогда все те люди что покупают недорогие ноутбуки без выделенных видеокарт, без сканеров отпечатков и модемов?
На мой взгляд большинство пользователей это браузер+видеоплеер+смотрелка фотографий и несколько встроенных игр типа lines и пасьянс и это всё последние годы вполне сносно работает в ubuntu и даже в debian(и в 9ку занесли автоматическую напоминалку о обновлегиях был удивлён усиленному на экране предложению обновить и перезагрузить).
С офисом для дома тоже проблем не наблюдается, люди очень далёкие от ИТ нормально пользуются годами без поддержки (и даже находят как установить в убунте другой плеер).
В общем мне кажется что прогресс идёт и мы наконец-то добрались до того уровня когда начинается допиливание системы до безпроблемного использования обычными пользователями. Да не так быстро как в коммерческих продуктах но процесс идёт и прогресс налицо.
Слушайте, а вот давно хотел спросить.
Вот чейндж.орг, петиции эти все, все это кококо — оно зачем? ХОТЬ РАЗ кто-нибудь прислушался к петициям на чейндж.орг?
Это же какой-то неизвестный сайт, на котором неизвестные люди пишут, что они что-то от кого-то хотят.
Елки-палки, да одиночный пикет с табличкой "Джим Землин, объяснись, почему макос используешь" напротив администрации села Пердяевка Тульской области и то будет результативнее, хотя бы в сельской газете про чудака напишут.
ХОТЬ РАЗ кто-нибудь прислушался к петициям на чейндж.орг?
Да. Has change.org (or sites like it) ever changed anything? (больше примеров).
Сельские газеты уже написали (ссылки есть в петиции), но пока или слишком сельские, или это просто не работает. Никаких гарантий с петицией, конечно, нет…
Эти штуки поднимают шумиху в интернете. Которая таки работает.
ведь драйверов для моей сетевой карты не было
Achievement unlocked :-) Сам столкнулся один раз (закупив супер-новые дэсктопы HP в офис, но уже на тот момент в репах уже был драйвер (которого не было в исошниках), надо было только сделать apt-get update и apt-get dist-upgrade, временно заюзав USB-шную сетевуху или скачать пакеты на флэшку на другой машине), но всё-таки ситуация очень редкая, мне кажется. Уже много лет Linux отличается от Windows как раз тем, что о драйверах не приходится думать вообще (ну, кроме как для дискретных видеокарт и каких-то специализированных девайсов). Но это да, тоже мой сугубо личный опыт, может мне просто везло.
Если быть откровенным, linux на десктопах сейчас выглядит примерно как столовый топор для масла (если речь идет не о разработчиках, а об обычных пользователях). И в этом нет ничего удивительного — конкурировать приходится с коммерческими продуктами, которые развиваются уже не один десяток лет. Это и должно стать стимулом к развитию линукс на десктопах.
Если быть откровенным, linux на десктопах сейчас выглядит примерно как столовый топор для масла (если речь идет не о разработчиках, а об обычных пользователях).
Не могли бы конкретизировать? Не спорю, а именно интересуюсь. 15-10 лет назад я бы с Вами согласился не раздумывая, а сейчас уже реально непонятно, а потому и любопытно чего же для «обычных пользователей» с Linux не так. Пару лет назад одной совершенно далёкой от IT знакомой, ни с чем кроме Win7 и немного Mac не работавшей, поставил Ubuntu (ну, не в голой стандартной комплектации, конечно, доставил несколько приложений), так она практически и не заметила, ни одного вопроса не возникло. Выглядит именно в эстетическом смысле хорошо — все шероховатости вроде давно заполировали, всё интуитивно, видео смотрится, музыка слушается, скайп базарит, в браузере всё идеально, wifi коннектится без вопросов (когда-то давно с этим бывали проблемы), RDP-клиент пашет, документы открываются, тупит меньше. Чего же может не хватать именно «обычному пользователю» (если не брать профессионалов графического дела, видеомонтажа, прочих специализированных областей и геймеров)? Давно грызёт любопытство на тему в чём же конкретно проблема, собственно.
Скайп. На линукс он есть, но не так удобен как на вин. По самой системе претензий нет. Причем даже можно выбирать дистрибутив, не беспокоясь, что у того или иного могут быть какие-то проблемы.
Под обычным пользователем я скорее подразумевал всех не разработчиков.
Геймеры ведь тоже обычные пользователи (если речь не о подрастающем поколении, использующем пк исключительно для игр), не знаю зачем вы их делите.
Э… нет. В ней куча странной фигни, которую нужно отключать и чистить, иначе оно жрет до 50% моего проца. Не сказал бы, что это «оптимизирована», учитывая, что на том же ноуте у меня windows 7 за три года пользования тупила меньше.
Я не говорил, что на линукс нету офиса или им невозможно пользоваться, но пользоваться им не так удобно, как решениями от apple или ms
отключить обновления нельзя… Еще поговорим об удобстве пользования?
А зачем с вами говорить, вы же некомпетентны. Даже про отключение автообновления не знаете. Не говоря уж об исключениях антивируса (который, к слову тоже необязателен и отключаем).
Ну вот я обожаю Линукс. Использую с 2009-го года. Использую Федору как основную ОС.
Если мне нужно поработать со звуком, видео или графикой или с офисными документами, я перехожу на мак.
Там просто удобнее делать офисные дела. Pages, Numbers и Keynotes очень удобны. Как бы ни старались, LibreOffice ещё далёк до удобства вышеперечисленных программ.
Даже Документы Google удобнее, которые частенько выручают на Лине.
Наличие Photoshop, Final Cut — преимущество.
Большинство ПО для таких задач в Линуксе, к сожалению, неудобное или с ограниченным функционалом.
Использовать Wine можно, но лично мне не нравится такой подход.
Да и было бы ещё глупее, если бы этот мужик запустил презентацию в MS Office под Wine.
Если хотят популяризировать для десктопа, то пусть договорятся и выпустят Adobe * и MS Office. Как только Steam добавил поддержку линукса, сразу появилась куча игр под него. Так же и тут будет.
Ну это надо требовать от Adobe и Microsoft.
Которые в гробу удивительном месте увидят свои продукты на Linux'е.
P.S. Да грубо, но оно так будет.
Кстати любопытно: а не догадался ли кто-нибудь уже изобресть дистрибутив Linux, где Wine был бы «из коробки» так вшит в систему и настроен, чтобы обеспечивать максимально «бесшовную» работу с Windows-программами? Помню около 15 лет назад был Lindows aka Linspire — уже был довольно интересный, но немного «не дотягивал», интересно было бы взглянуть на современные попытки на основе опыта и достижений прошедших лет.
А что в ворде или экселе не работает в макос? Как пользователь последнего офиса интересуюсь.
Причем iWork поддерживает встроенный в МакОсь макроязык, я даже как-то пытался помочь клиенту на нем автоматизировать одну фичу, но он настолько топорный, что легче оказалось решить задачу через формулы.
Microsoft не спешит интегрировать в Офис .Net, наверно готовит что-то новое…
Вам редактора не хватает? Так-то сборки встраивать в документы уже давно можно.
VBA нормальный язык для такого уровня автоматизации (тут ведь не программисты и даже не любители), а то что его нет в других пакетах так это не страшно, т.к. переносить эти решения в том виде в котором они есть в большинстве случаев не имеет смысла (у людей ведь не только сами скрипты но и расположение файлов в каталогах, ссылки на источники данных, 'регламенты заполнения", а для дома это всё не нужно...
Очень надеюсь, что гугл откроют исходники своего офиса и разработчики либреофиса перейдут на него
Честно говоря, очень надеюсь, что этого не произойдет. Гуглоофис — строго web-решение. Веба-на-десктопе и так достаточно много, КМК.
Совместные усилия и гугла и либреофиса помогут довести продукт до полноценной конкуренции с мс. Других оптимистичных путей я не вижу.
Вот тут даже не «других», а в принципе в таком виде оптимистичных путей нет. Гугл может потягаться с MS на рынке офисных систем, но, если он этим займется, то точно без участия «либры».
Да и не нужна она особо, конкуренция эта, в том виде, в каком сейчас работают все офисные пакеты. Тут, ИМХО, концептуально другой подход может выстрелить.
У либры я просто не вижу других путей развития. Я очень хочу свободный офис, но современная либра к сожалению совсем не похожа на тот самый офис. Впрочем это только мое мнение, многих вполне устраивает и даже полностью заменяет мс для них
На выходе 3 проблемы:
1. Упаковать «как есть» веб-приложение и выдать его за десктопное… Тормозить будет люто. Да и смысл? Чем будет отличаться от гуглосервиса?
2. Даже переписать фронт, избавиться от промежуточного REST'а… И для офиса вертеть на своей машинке базу данных? Оно реально надо?
3. Переписать фронт, переписать бек… Т.е. «переписать все»? А зачем тогда исходники гугла?
Rest можно оставить. Почему хотелось бы бека на «быстрых» языках со статической типизацией и без джаваскриптов, так потому что тогда все будет работать быстрее и требовать меньших нагрузок (у меня дома точно не гугловский сервер стоит). А фронт можно переписать относительно быстро и безболезненно — это самая простая часть их офисного пакета, имхо.
Почему хотелось бы бека на «быстрых» языках со статической типизацией и без джаваскриптов, так потому что тогда все будет работать быстрее и требовать меньших нагрузок (у меня дома точно не гугловский сервер стоит).
Вот именно, что дома не сервер. Поэтому основной вопрос к фронту таки. Поверьте, в браузерном исполнении он будет тормозить сильнее, чем бэк.
irony
Если честно — сильно сомневаюсь, что Джим тащил с собой на мероприятие полноценный десктоп, скорее всего ограничился ноутбуком, его таскать удобнее. 2017 год объявлен «годом Linux на десктопах», а не на лаптопах, так что все в порядке.
/irony
Суть не в этом, а в том, что директор организации призванной популяризировать Линукс, в эту самую популяризацию не только не верит, этого неверия не скрывает, но не находит в этом ничего неестественного. Для кармы это плохо.
Нет, ну было бы круто, если бы это все показывалось на линуксе, тогда можно было бы еще дополнительно сказать, что «эта презентация сейчас запущена на ноуте с линуксом». Но еще раз, это дополнительно, т.е. делать так совершенно не обязательно. Требовать каких-то объяснений — еще более нелепо, пусть отстанут уже от человека :)
Оговорюсь сразу: не буду защищать «готовность линукса», отлично понимаю и признаю, что есть очень ненулевое количество достаточно критичных проблем. При этом весьма недоволен вышеуказанной личностью, ввиду несоответствия призывов личному примеру.
Если что — у самого меня Linux и на ноуте и на десктопе, так что у же который год у меня «год линукса на десктопе».
Моё мнение — Джим опозорился и дискредитировал Linux таким поведением.
Вот тут ППКС (в смысле, Подписываюсь Под Каждым Словом, чтобы не было неоднозначности).
Этот пример очень ярко показывает несостоятельность Linux как настольных систем. За десятки лет Linux всё ещё не может составить конкуренцию ни Windows, ни Mac.
Вот здесь все уже не так очевидно. ИМХО, в некоторых областях применения линуха вполне конкурентна и с Windows, и с MacOS по совокупности юзабилити*стоимость владения.
Единственный выход в такой ситуации (для Linux в целом) я лично вижу в объединении усилий разработчиков к работе над одной хорошо настраиваемой десктопной системой,
Вот тут (сугубо мое мнение) — 2 химеры в 1/2 предложения.
Химера №1 — «объединение усилий разработчиков» в условиях экосистемы Linux… Прям всех? На той же мотивации? Честно говоря, я скорее в Деда Мороза поверю. Призывать можно сколько угодно, шансы на успех — стремящиеся к нулевым.
Химера №2 — «хорошо настраиваемая» десктопная система. Вот к этому как к самоцели стремиться вообще не надо. «Хорошая настраиваемость» реально необходима при ужасной «дефолтной» реализации. В остальном стремиться скорее надо к унификации (мы же хотим перешагнуть через второй процент пользователей десктопа?).
Ну и да, на общественных началах «не взлетит». Хочешь удобную консистентную систему — поставь за ней заинтересованную корпорацию, имеющую ресурсы для разработки и мотивацию (вероятно, способ монетизации).
При этом, могу вас порадовать, попытка движения в эту сторону уже есть. При этом явно видно 2, имеющие какие-то шансы на успех. Тужится Canonical, тужится Redhat. А дальше — вопрос лишь в том, кто первый пупок надорвет. Второй останется хозяином «консистентного линукс-гуя».
И что ему мешало презентацию сделать в pdf и использовать ноут ну например с Федорой или Дебианом? Выглядит так как ездящий на иномарке директор завода Москвич.
Да всякое бывает. Вот у меня ноут Acer и на нем убунта — она ни в какую не подцепляет Acer'овский-же проектор. Банально втыкаешь — пустота и ноль реакции (DVI порт). А проектор старый-древний со стертой уже фирмой — вполне нормально видит. Доходит до смешного — приходится тащить ноут с Вистой, когда надо оба проектора задействовать.
НИкогда бы не подумал.
Я люблю Линукс, я люблю Винду.
Но Мак ОС… Взяли худшее от винды, взяли худшее юникса и посыпали сверху традиционными Apple ограничениями
Что в этой ОС хорошего? Она же как и вся продукция Apple — шаг влево/шак вправо — расстрел. Только типовые задачки удобно решаются…
Или где я не прав?
Поймите меня правильно, я не пытаюсь холивар развязать. Понимаю, что здесь много сторонников Mac OS(поэтому и пишу этот пост) и хочу понять что в ней так привлекательно. Ведь явно же умные и адекватные люди пользуются, значит есть скрытая сторона мне не очевидная. Прошу помочь разобраться.
Но ведь уровень владения «чтобы копнуть» он уже предполагает некие навыки, при наличии которых и линукс не отпугнет.
В целом MacOS лучше Windows в это плане.
ТАкже согласен и с качество железок ноутбуков от Apple. Если не принимать во внимание цену — это лучшее что есть на рынке.
Но вопрос всё же про ОС. У меня есть опыт работы со всеми ключевыми ОС, и Mac OS оставляет очень тяжелое впечатление. Вплоть до того, что я полностью отказался от работ связанных с iOS, просто из-за дикого дискофморта во время работы с mac os.
ВПрочем не буду продолжать этот разговор здесь, больно много здесь агрессивных товарищей не способных вести обсуждение. Пойду погуглю, думаю ответ там где нибудь найдется. :)
Я кого-то оскорбил? Или запрещено считать Mac OS X спорной ОС?
Карму за что мне сливаете? Прошу объяснить.
Есть куча инструментов, которые позволят сделать качественную презентацию на Linux. Поэтому отговорки про Keynote — это как расписаться в полной недееспособности кампании.
Всё правильно сделал, ящитаю.
Зачем кому-то впаривать использование инструмента, который не совсем предназначен для некоторых вещей, мне непонятно. У линукса своя прекрасная ниша, он во многих аспектах обошел другие ОС, но не на десктопе, к сожалению или к счастью. Так зачем натягивать козу на баян?
Лично для меня Linux далеко обошла другие операционные системы и на десктопе, но я согласен — эта система безумно удобна, если хорошо дружить с консолью и tiling-менеджером, т.е., "впаривать" её всем без разбора нет никакого смысла. Кто знает, может даже для таких пользователей, как я, чрезмерная популярность Linux чревата потерей удобства через фиксацию разработчиков на удобстве среднестатистического пользователя.
Ну я тоже когда подрабатывал будучи студентом тоже ставил убунту в подобную контору. Только вот не знаю, долго ли оно там простояло, так как поддерживать это после моего увольнения было некому. Вообще поддержка все этого дела в итоге выходит дороже одноразовых лицензий на винду, вспомните метания на линукс и обратно в германии.
К тому же разбаботчики плохие UI дизайнеры, а UI дизайнеры кушать хотят, так что конкуренции с платным софтом не получается. А между тем комьюнити уже 20 лет гоняется за воздушным замком десктопного линукса, когда можно было потратить эти миллионы человека-часов на действительно важные вещи.
Десктопный линукс это уже вполне себе существующая вещь. Конечно до массовости windows/macos очень далеко и возможно даже близко никогда этого не будет. Однако это альтернатива которая заполняет свою нишу и это прекрасно! Не понимаю как можно быть против этого? Если бы я даже ни дня не пользовался линуксом и не планировал бы, то все равно обеими бы руками был бы за самое активное его развитие. Если в мире выбор только между двумя ОС, то это как-то странно и даже опасно.
потратить эти миллионы человека-часов на действительно важные вещи.
Например?
Я лично кроме как в консоли с линуксом уже лет пять не работал, а от новых версий DE у меня вытекают глаза, но я не юзер, меня все устраивает, это мой инструмент, он прекрасен, для своей ниши…
Тут мы имеем дело с обычной монополией, качество самой ОС тут играет далеко не первую роль.
Думаю что комментарии этой темы нужно объединить с комментариями этой https://geektimes.ru/post/293365/#comments
Директор Linux Foundation использует Mac OS X, анонсируя «год Linux на десктопах»