Не надо пытаться делать общий стиль вообще, пусть все приложения выглядят как попало?
Ну, не "как попало", а "как сделал разработчик". В остальном да.
Единое оформление и поведение окон это атавизм, который ну просто так случайно получился? Что за чушь Вы несете?
Это факт. Внезапно, если рамки окон рисует одна и та же программа, неудивительно что они получаются в одном стиле. А потом уже из этого сделали религию.
Ага, щас. Декорации это не только простенькие линии на границе окна, это еще и заголовок, кнопочки управления окном в заголовке и вся логика управления размерами окна от переразмерения мышью до всяких двойных кликов для разворачивания на весь экран и т. п.
Ну, я исхожу из того, что если кто-то взялся сам напрямую реализовывать GUI без тулкита, то уж созданием кнопки в заголовке его не напугать. Что до управления размерами и перемещением - я выше написал как это реализуется под вейланд. Вот просто так, если за данную область окна можно таскать - значит программа просто в ответ на событие мыши посылает "move" и всё, остальное делает дисплейный сервер, сам отлавливает изменение положения мыши и сам двигает. С кнопками минимизации/максимизации, кстати, аналогично, только там обрабатывать клик. Что до мелочей вроде максимизации по двойному клику - это очень хорошая функция, но необязательная. Ну и сделать её несложно. Функции типа snap to left/right реализует DS без помощи приложения.
Без прямой или косвенной помощи DE приложение будет и выглядеть, и вести себя как черти-что, полностью выбиваясь из общего стиля и логики работы остального рабочего стола. Я
Чтоб приложение правильно вело себя существует протокол вейланд. В нём прописаны сообщения, которые посылают друг другу клиент и сервер. А выглядеть выбиваясь оно будет в любом случае, SSD тут не поможет вообще никак.
SSD решает эту проблему целиком и полностью. Просто по построению.
Ну хорошо. Давайте представим себе пользователя, которого очень раздражает, когда на экране что-то не в одном стиле. Он запускает SSD программу и видит, что кнопки на заголовке окна совершенно не такие же как в рабочей области, что название окна написано, например, жирным ариалом, а внутри обычный roboto, и размеры букв разные. Теперь расскажите, как SSD решит эту проблему. Хоть "по построению", хоть иначе.
В случае CSD у такого пользователя вообще никаких проблем нет: он просто выбирает DE без лишних элементов или с убирающимися элементами, после чего распахивает окно на весь экран и спокойно работает, видя на мониторе весь GUI в одном стиле.
На самом деле есть 2 последовательные точки зрения на гуй. Одна требует полной целостности стиля, отказа от любых "нескучных" интерфейсов типа винама, и в общем и целом решается через 1 общесистемный тулкит. К сожалению сторонников этой точки зрения, этот бой давно проигран, так как большая часть интерфейсов сейчас представляет собой вебсайты, а туда системный тулкит не интегрируешь. Вторая, вейландовская, заключается в том, что как рисовать кнопочки пусть решает сама программа, а задача дисплейсервера просто предоставить окно на котором рисовать. Но эта точка зрения требует CSD. Вариант "внутри пусть будет что угодно, но заголовок и рамку мне изволь оставить общие" - это совершенно непоследовательное требование, популярное исключительно из-за привычки. Вообще, любой аргумент за SSD можно не меняя ничего существенного переделать в аргумент за единый встроенный тулкит, поэтому если некое утверждение справедливо для SSD, оно же будет справедливо и для единого тулкита.
Тулкит вовсе необязателен, как и поддержка тем. Тулкит - это всего лишь библиотека. Если программа не хочет пользоваться библиотекой, она реализует функции сама. Чтоб не плодить сущностей, можно назвать такую программу программой с собственным встроенным тулкитом. Кстати, декорации окна под голым вейландом делаются примерно настолько же просто как и обычная кнопка. Нужно просто отловить сообщение "mousedown", определить в какую область попало оно и далее послать во ответ либо "move", либо "resizeX" где X - название направления, всё остальное сделает композитор. Т.е. проблем у бестулкитных программ в мире CSD вообще нет. Проблемы начинаются только если начать пытаться решать задачу, которую не нужно решать. Вот не надо пытаться "поддерживать темы и стилизацию конкретного DE". Эта задача принципиально неразрешимая в условиях нефиксированного списка DE и тулкитов, но попытки решения которой способны поглотить неограниченное количество усилий. Её можно попытаться решить частично, прописав похожие темы для пары тулкитов и заставляя DE устанавливать их синхронно, но третий тулкит уже будет мимо, равно как и третье, редкое DE не справится с такой задачей. И SSD эту проблему не решает вообще никак, даже частично. Проблему рассогласованностей стилей невозможно решить просто передав рамку окна в ведение DE, это просто переместит границу рассогласования на несколько пикселей внутрь окна, только и всего. Эта граница ничуть не красивее и не логичнее чем граница по границам окна.
Ну а общий стиль декораций - это именно атавизм. Вот прямо по определению, нечто, что было нужно, но уже потеряло свою функциональность. Когда-то придумали, что для экономии и расширяемости можно передать управление окнами одному объекту, который заодно и будет рисовать функциональные рамки окон. Он и рисует. И одинаковые они не потому, что кто-то так захотел, а потому что декоратору проще рисовать всегда одинаково чем пытаться угадать что там внутри и как-то подстроиться. Теперь, после того как функции оконного менеджера перенесли в дисплейный, совершенно незачем рисовать окно кому-то другому.
Ну а если разработчик "ожидает по умолчанию" - это проблема разработчика, он, видимо, не до конца понимает, под какую среду он пишет.
Как приложение должно узнать о дизайне декораций конкретного Gnome и реализовать их в соответствии со всеми системными настройками, в точности так же, как и все остальные приложения -- тоже очень мало кого интересует.
Никак. Не нужно так делать. Идея "общих декораций" - это атавизм эпохи наличия этих самых общих декораций, в виду технических особенностей реализации архитектуры X. Никакой ценности это не несёт. Если тулкит приложения умеет в темы и если у пользователя установлена тема для данного тулкита, то и рамка окна и содержимое будут в стиле темы. Если тема не установлена или тулкит вообще не поддерживает темы, то и рамка окна и содержимое будут в дефолтном оформлении тулкита. А вот как раз ситуация, когда снаружи красиво, а внутри motif - это ненормально.
Давно не заходил на хабр, оказывается тут есть шикарная возможность заткнуть того, с кем не согласен, накидав ему минусов. И "лучшие" люди этим активно пользуются. Не знаю что в голове у людей, может не знают что минус даёт бан. В общем если надеетесь на дискуссию - я пас, валю с этой помойки.
Также добавлю упоминание шикарное меню "пуск", которое было стандартным иерархическим меню и потому если, ведя мышью над очередным попапом случайно выйдешь за его границы, то можно было свернуть всю открытую уже подветвь и открыть другую. UX был на высоте
Где хранить файлы - ваше дело, можете в d:\files, можете в "мои документы". Я объяснил, почему идиотской идеей был именно "рабочий стол", как место, куда можно положить файл, с которым часто работаешь.
Ярлыки на рабочем столе - это, во-первых, гвоздь в гроб меню "пуск", которое тоже немало крови пользователей попило пока его сделали минимально юзабельным, во-вторых, решение устаревшее в момент появления быстрого запуска.
Собственно интерфейс винды 95 - это набор вынужденных технических компромиссов для системы, которая должна была работать на 4х мегабайтах памяти + набор ошибок людей, не имевших большого опыта разработки GUI.
а вы значит имеете идеальный вкус и понятие о дизайне ОС?
Ну, видимо я имею идеальный вкус и понятие о дизайне ОС.
Ну, по крайней моей экспертизы достаточно чтоб понять, что хранить файлы там, доступ куда появляется после поочерёдной минимизации всех открытых окон - это очень плохая идея. Вы будете спорить?
Да, в следующей версии появился квикланч, а в нём ярлык "свернуь все окна", однако он был запрятан следи других предустановленных ярлыков, так что не очень смелые пользователи не знали о его существовании, а смелые его удаляли. А настоящая кнопка "показать рабочий стол" появилась лет через 10.
Вообще, рабочий стол - худшая идея UI когда-либо придуманная. Для начинающего пользователя с пустым рабочим столом это кажется удобным, потом вырабатывается привычка, убеждение, что именно тут и нужно хранить рабочие файлы, а потом появляется бардак, и постоянные мысли о необходимости чистки стола. Реализация в Windows ещё хуже: нахождение/отсутствие на рабочем столе зависит от расположения файла в дереве директорий. Но при этом путь к файлу на многое влияет, на списки недавно редактированного, на OLE, в результате даже если пользователь пытался пользоваться парадигмой рабочего стола, ну там достал документ, положил на стол, поработал, потом убрал в архив - он отхватывал кучу проблем.
Майкрософт потом одумались, начали приучать пользователей хранить файлы в папке "мои документы", а для любимых приложений добавили квикланч, но им не хватает яиц отключить эту хрень навсегда, отхватить неделю хейта и потом бы всё успокоилось.
Какой, нахрен, привычки? Сейчас найти человека привыкшего к windows 95 сложнее чем человека привыкшего к современной макось. Я уж не говорю об андроиде. Да и не может привычка быть ответом на "решение дурацкое". Рабочий стол - одно из самых идиотских решений евер.
Если убрать из статьи воду (что ни говори, ругать UI редактора движка, на котором написана половина игр как-то странно, видимо люди справляются), то в статье противопоставляются Unity, в котором для тяжёлой графики плюсообразный C#, а для лёгких игр обычный C# и UE, в котором для чего-то сложного плюсы, а для простого блюпринты. Выбор из этих 2х совсем неочевиден. В статье явно не хватает ответа на вопрос о совместимости DOTS с простым юнити кодом. Если уперевшись в производительность классического Unity-кода на C# можно переписать одну подсистему на DOTS и получить высокую производительность это одно, а если нужно будет переписывать всё, то как бы совсем другое.
Какой-то странный асинк/авэйт. Вроде сделали, но сделали ленивым, асинхронная функция не начинает исполняться до авэйта. Получается, что невозможно запустить 2 асинхронные функции параллельно, код
let af = get_a_async();
let bf = get_b_async();
let a = af.await;
let b = bf.await;
не приведёт к поочерёдному исполнению частей get_a_async и get_b_async. Вообще разделение на 2 стадии, вызов функции и ожидание теряет смысл, можно было бы await заменить на вызов функции.
Предположим, некий террорист звонит 10 раз с ложным сообщением и 11й раз проигнорировать нельзя, потому что вдруг в этот раз и вправду заминировал что-то. Чем поможет полная блокировка канала перед 11 разом? Только тем, что звонок не поступал, его никто не игнорировал и задницы прикрыты.
Ввиду несколько грибообразной формы зубов, сделать так, чтоб между зубами никогда ничего не набивалось невозможно. Поэтому плотность посадки зубов не спасёт от набивания, а вот удалению набившегося помешает.
Люди, если про дона Корлеоне годами ходят слухи, что он — мафиози, занимается тем-то и тем-то и те-то и те-то у него подкуплены, поэтому он и неприкосновенен, то это вовсе необязательно правда, но если вдруг дона Корлеоне арестуют по обвинению в чём-то из этого то как-то странно делать удивлённое лицо и начинать искать глубокие и тайные мотивы, вполне возможно, что просто дошла гирька до пола, а новый прокурор в отличие от предшественника, обладает яйцами. То, что китайцы тырят технологии, что занимаются шпионажем и что их крупный бизнес крепко связан с правительством… это как бы распространённое мнение которое никто особо не оспаривал.
Ну и разговоры о том, что Гугл пошёл на поводу у Трампа и перестал сотрудничать с фирмой, попавшей под санкции — это вообще сюр, что ещё Гуглу делать, если закон от него это требует?
Когда это такое было, чтоб к бизнесу не было претензий? Вы вообще на какой планете живёте?
Бизнес отвечает деньгами всегда. Можно вспомнить хоть случаи с ожогом кофе из макдака. Если что-то плохое случилось и бизнес стоял где-то рядом, то его заставят выплатить компенсацию. Просто потому что у бизнеса денег много, а пострадавшего жалко. Презумпция невиновности в подобных спорах не действует, это не уголовное право.
В данном же случае даже натяжек особых не надо, если данные были переданы компании и потом утекли, то ответственность компании очевидна. Пока компания утверждает, что понятия не имеет, как так получилось, что данные вдруг попали третьим лицам, ответ очевиден: сама компания данные и продала. Если компания проведёт расследование и выяснит метод утечки данных, причём её объяснение окажется правдоподобным судье, то судья, без вопросов, присудит компании штраф за то что не прикрыли вот такую очевидную дыру.
Ок, пусть будет www3.somesite.com/~mary-sue/pony-300px.jpg
3, mary-sue и 300px может оказаться идентификатором сайта А.
Суть в том, что есть 100500 методов слежки за пользователем, существенная часть из них неподконтрольна сайту, какие-то можно нейтрализовать, например вставляя нореферер или просто скачивая и рехостя изображения, но это требует усилий и экспертизы со стороны разработчика сайта. А есть ещё возможность, что сайт похакают и тупо украдут базу пользователей со всеми данными.
Короче, на первый взгляд выбор у владельца сайта между «следить, продавать информацию и предупреждать» или «не следить» и, в виду текущей ситуации, не совсем ясно зачем выбирать второй вариант. В реале же выбор немного другой, между «просто добавить попап с предупреждением» против «отказаться от показа банеров, от использования средств анализа посещаемости, постоянно тратить огромные деньги на предотвращение слежки за посетителями и в конце получить негарантированный результат».
И что в итоге? Тот же самый попап на каждом сайте с требованием согласиться на слежку перед тем, как зайти.
На практике, конечно, всё ещё хуже. На форуме или в комментариях посторонний пользователь оставляет
В рамках истории, это любой сайт очевидно не связанный с А, который показывает банеры с banner.com. Кука установлена, то что данный пользователь интересовался понями banner.com известно, задача банерной сети показать то, что заинтересует пользователя, а статистически в данном случае это новые серии Пони. Причём чем более озабочен Джо слежкой (например он часто чистит куки), тем с большей вероятностью ему покажут то, чем он интересовался недавно и, соответственно, с большей вероятностью Джо что-то заподозрит.
Как бороться, если без попапа с требованием согласиться на любую слежку? Не знаю. Задача поставлена так, что судьба сайта полностью в руках любого другого сайта, с которого загружается хоть что-то. Доказать, что не было сговора с целью слежки нереально.
И это абсолютно неработоспособно.
Приведу пример. Пусть есть сайт А на котором расположена статья о чём-то ужасно постыдном, например о мультфильме My Little Pony. Предположим, статья настолько хороша, что на неё отовсюду ссылаются, в результате чего она всегда вверху выдачи поисковика. В статье перечислены важные моменты сериала с ссылками на серии в нетфликсе. И сайт А принципиально не следит за пользователями, не требует регистрации, не устанавливает куки, не торгует информацией. Но вверху находится один ненавязчивай баннер от сайта banner.com. Пользователь Джо заходит на неследящий поисковик duckduckgo и набирает «сумеречная искорка». Просто дочь его попросила игрушку, ему интересно что это вообще такое. Просматривает статью и закрывает. Но сайт banner.com уже выдал баннер и установил куку. Более того, анализируя реферер, автоматика сайта давно вычислила, что люди, читавшие ту статью, в 30% случаев оказывались на нетфликсе в разделе пони, это естественно, они по ссылкам из статьи ходили. Но наш Джо вдруг замечает, что ему начали подсовывать рекламу новых серий my little pony на нетфликсе. Так как он темой интересовался ровно 1 раз, он знает кто крыса и идёт и пишет жалобу на сайт A. И сайт А штрафуют. Пофиг, что «виноват» banner.com, он, возможно, в другой юрисдикции вообще, да и если и в этой, Джо не заходил ни на какой banner.com, он заходил на сайт А и его именно на сайтп А не предупредили о слежке. И даже если у сайта А есть договор с banner.com в котором чёрным по белому написано, что слежки не будет, сначала оштрафуют А и только потом можно будет пытаться через арбитражный суд получить деньги с владельца banner.com.
Соответственно, единственный способ как-то исполнить GDPR — при входе на сайт А требовать от пользователей согласиться на вообще всё. Единственное исключение — сайт, полностью контролируемый, где нет баннеров, счётчиков, даже подгрузки библиотек или шрифтов с внешнего источника.
Безусловно там так и написано. Ни один закон не содержит фразы: «мы делаем это потому, что мы — фашисты и что вы нам сделаете?», нет, везде написано, что это ради всеобщего блага, борьбы с педофилией и терроризмом. Тем не менее, ситуация такова, что самый лучший способ исполнения данного закона заключается в том, чтоб подсовывать каждому посетителю «согласие на сбор персональных данных». Ну а как иначе? Если я вставляю ссылку на гугланалитикс, или просто баннер от гугла, я не могу гарантировать, что этот гугланалитикс не поступит с собранной аналитикой как-то некрасиво. А учитывая, что любому нормальному человеку наплевать на корпоративную слежку, я просто выкидываю попап со словами «соглашайся или уходи».
Ну, не "как попало", а "как сделал разработчик". В остальном да.
Это факт. Внезапно, если рамки окон рисует одна и та же программа, неудивительно что они получаются в одном стиле. А потом уже из этого сделали религию.
Ну, я исхожу из того, что если кто-то взялся сам напрямую реализовывать GUI без тулкита, то уж созданием кнопки в заголовке его не напугать. Что до управления размерами и перемещением - я выше написал как это реализуется под вейланд. Вот просто так, если за данную область окна можно таскать - значит программа просто в ответ на событие мыши посылает "move" и всё, остальное делает дисплейный сервер, сам отлавливает изменение положения мыши и сам двигает. С кнопками минимизации/максимизации, кстати, аналогично, только там обрабатывать клик. Что до мелочей вроде максимизации по двойному клику - это очень хорошая функция, но необязательная. Ну и сделать её несложно. Функции типа snap to left/right реализует DS без помощи приложения.
Чтоб приложение правильно вело себя существует протокол вейланд. В нём прописаны сообщения, которые посылают друг другу клиент и сервер. А выглядеть выбиваясь оно будет в любом случае, SSD тут не поможет вообще никак.
Ну хорошо. Давайте представим себе пользователя, которого очень раздражает, когда на экране что-то не в одном стиле. Он запускает SSD программу и видит, что кнопки на заголовке окна совершенно не такие же как в рабочей области, что название окна написано, например, жирным ариалом, а внутри обычный roboto, и размеры букв разные. Теперь расскажите, как SSD решит эту проблему. Хоть "по построению", хоть иначе.
В случае CSD у такого пользователя вообще никаких проблем нет: он просто выбирает DE без лишних элементов или с убирающимися элементами, после чего распахивает окно на весь экран и спокойно работает, видя на мониторе весь GUI в одном стиле.
На самом деле есть 2 последовательные точки зрения на гуй. Одна требует полной целостности стиля, отказа от любых "нескучных" интерфейсов типа винама, и в общем и целом решается через 1 общесистемный тулкит. К сожалению сторонников этой точки зрения, этот бой давно проигран, так как большая часть интерфейсов сейчас представляет собой вебсайты, а туда системный тулкит не интегрируешь. Вторая, вейландовская, заключается в том, что как рисовать кнопочки пусть решает сама программа, а задача дисплейсервера просто предоставить окно на котором рисовать. Но эта точка зрения требует CSD.
Вариант "внутри пусть будет что угодно, но заголовок и рамку мне изволь оставить общие" - это совершенно непоследовательное требование, популярное исключительно из-за привычки. Вообще, любой аргумент за SSD можно не меняя ничего существенного переделать в аргумент за единый встроенный тулкит, поэтому если некое утверждение справедливо для SSD, оно же будет справедливо и для единого тулкита.
Тулкит вовсе необязателен, как и поддержка тем.
Тулкит - это всего лишь библиотека. Если программа не хочет пользоваться библиотекой, она реализует функции сама. Чтоб не плодить сущностей, можно назвать такую программу программой с собственным встроенным тулкитом. Кстати, декорации окна под голым вейландом делаются примерно настолько же просто как и обычная кнопка. Нужно просто отловить сообщение "mousedown", определить в какую область попало оно и далее послать во ответ либо "move", либо "resizeX" где X - название направления, всё остальное сделает композитор. Т.е. проблем у бестулкитных программ в мире CSD вообще нет.
Проблемы начинаются только если начать пытаться решать задачу, которую не нужно решать.
Вот не надо пытаться "поддерживать темы и стилизацию конкретного DE". Эта задача принципиально неразрешимая в условиях нефиксированного списка DE и тулкитов, но попытки решения которой способны поглотить неограниченное количество усилий. Её можно попытаться решить частично, прописав похожие темы для пары тулкитов и заставляя DE устанавливать их синхронно, но третий тулкит уже будет мимо, равно как и третье, редкое DE не справится с такой задачей.
И SSD эту проблему не решает вообще никак, даже частично. Проблему рассогласованностей стилей невозможно решить просто передав рамку окна в ведение DE, это просто переместит границу рассогласования на несколько пикселей внутрь окна, только и всего. Эта граница ничуть не красивее и не логичнее чем граница по границам окна.
Ну а общий стиль декораций - это именно атавизм. Вот прямо по определению, нечто, что было нужно, но уже потеряло свою функциональность. Когда-то придумали, что для экономии и расширяемости можно передать управление окнами одному объекту, который заодно и будет рисовать функциональные рамки окон. Он и рисует. И одинаковые они не потому, что кто-то так захотел, а потому что декоратору проще рисовать всегда одинаково чем пытаться угадать что там внутри и как-то подстроиться. Теперь, после того как функции оконного менеджера перенесли в дисплейный, совершенно незачем рисовать окно кому-то другому.
Ну а если разработчик "ожидает по умолчанию" - это проблема разработчика, он, видимо, не до конца понимает, под какую среду он пишет.
Никак. Не нужно так делать. Идея "общих декораций" - это атавизм эпохи наличия этих самых общих декораций, в виду технических особенностей реализации архитектуры X. Никакой ценности это не несёт.
Если тулкит приложения умеет в темы и если у пользователя установлена тема для данного тулкита, то и рамка окна и содержимое будут в стиле темы. Если тема не установлена или тулкит вообще не поддерживает темы, то и рамка окна и содержимое будут в дефолтном оформлении тулкита.
А вот как раз ситуация, когда снаружи красиво, а внутри motif - это ненормально.
Давно не заходил на хабр, оказывается тут есть шикарная возможность заткнуть того, с кем не согласен, накидав ему минусов. И "лучшие" люди этим активно пользуются. Не знаю что в голове у людей, может не знают что минус даёт бан. В общем если надеетесь на дискуссию - я пас, валю с этой помойки.
Аргументы, если интересно, перечислены ниже: https://habr.com/ru/company/cloud4y/blog/653949/comments/#comment_24125893
Также добавлю упоминание шикарное меню "пуск", которое было стандартным иерархическим меню и потому если, ведя мышью над очередным попапом случайно выйдешь за его границы, то можно было свернуть всю открытую уже подветвь и открыть другую. UX был на высоте
Где хранить файлы - ваше дело, можете в d:\files, можете в "мои документы". Я объяснил, почему идиотской идеей был именно "рабочий стол", как место, куда можно положить файл, с которым часто работаешь.
Ярлыки на рабочем столе - это, во-первых, гвоздь в гроб меню "пуск", которое тоже немало крови пользователей попило пока его сделали минимально юзабельным, во-вторых, решение устаревшее в момент появления быстрого запуска.
Собственно интерфейс винды 95 - это набор вынужденных технических компромиссов для системы, которая должна была работать на 4х мегабайтах памяти + набор ошибок людей, не имевших большого опыта разработки GUI.
Ну, видимо я имею идеальный вкус и понятие о дизайне ОС.
Ну, по крайней моей экспертизы достаточно чтоб понять, что хранить файлы там, доступ куда появляется после поочерёдной минимизации всех открытых окон - это очень плохая идея. Вы будете спорить?
Да, в следующей версии появился квикланч, а в нём ярлык "свернуь все окна", однако он был запрятан следи других предустановленных ярлыков, так что не очень смелые пользователи не знали о его существовании, а смелые его удаляли. А настоящая кнопка "показать рабочий стол" появилась лет через 10.
Вообще, рабочий стол - худшая идея UI когда-либо придуманная. Для начинающего пользователя с пустым рабочим столом это кажется удобным, потом вырабатывается привычка, убеждение, что именно тут и нужно хранить рабочие файлы, а потом появляется бардак, и постоянные мысли о необходимости чистки стола. Реализация в Windows ещё хуже: нахождение/отсутствие на рабочем столе зависит от расположения файла в дереве директорий. Но при этом путь к файлу на многое влияет, на списки недавно редактированного, на OLE, в результате даже если пользователь пытался пользоваться парадигмой рабочего стола, ну там достал документ, положил на стол, поработал, потом убрал в архив - он отхватывал кучу проблем.
Майкрософт потом одумались, начали приучать пользователей хранить файлы в папке "мои документы", а для любимых приложений добавили квикланч, но им не хватает яиц отключить эту хрень навсегда, отхватить неделю хейта и потом бы всё успокоилось.
Какой, нахрен, привычки? Сейчас найти человека привыкшего к windows 95 сложнее чем человека привыкшего к современной макось. Я уж не говорю об андроиде. Да и не может привычка быть ответом на "решение дурацкое". Рабочий стол - одно из самых идиотских решений евер.
Если убрать из статьи воду (что ни говори, ругать UI редактора движка, на котором написана половина игр как-то странно, видимо люди справляются), то в статье противопоставляются Unity, в котором для тяжёлой графики плюсообразный C#, а для лёгких игр обычный C# и UE, в котором для чего-то сложного плюсы, а для простого блюпринты. Выбор из этих 2х совсем неочевиден. В статье явно не хватает ответа на вопрос о совместимости DOTS с простым юнити кодом. Если уперевшись в производительность классического Unity-кода на C# можно переписать одну подсистему на DOTS и получить высокую производительность это одно, а если нужно будет переписывать всё, то как бы совсем другое.
не приведёт к поочерёдному исполнению частей get_a_async и get_b_async. Вообще разделение на 2 стадии, вызов функции и ожидание теряет смысл, можно было бы await заменить на вызов функции.
Как думаете, по всем пунктам ответ «да»?
Люди, если про дона Корлеоне годами ходят слухи, что он — мафиози, занимается тем-то и тем-то и те-то и те-то у него подкуплены, поэтому он и неприкосновенен, то это вовсе необязательно правда, но если вдруг дона Корлеоне арестуют по обвинению в чём-то из этого то как-то странно делать удивлённое лицо и начинать искать глубокие и тайные мотивы, вполне возможно, что просто дошла гирька до пола, а новый прокурор в отличие от предшественника, обладает яйцами. То, что китайцы тырят технологии, что занимаются шпионажем и что их крупный бизнес крепко связан с правительством… это как бы распространённое мнение которое никто особо не оспаривал.
Ну и разговоры о том, что Гугл пошёл на поводу у Трампа и перестал сотрудничать с фирмой, попавшей под санкции — это вообще сюр, что ещё Гуглу делать, если закон от него это требует?
Бизнес отвечает деньгами всегда. Можно вспомнить хоть случаи с ожогом кофе из макдака. Если что-то плохое случилось и бизнес стоял где-то рядом, то его заставят выплатить компенсацию. Просто потому что у бизнеса денег много, а пострадавшего жалко. Презумпция невиновности в подобных спорах не действует, это не уголовное право.
В данном же случае даже натяжек особых не надо, если данные были переданы компании и потом утекли, то ответственность компании очевидна. Пока компания утверждает, что понятия не имеет, как так получилось, что данные вдруг попали третьим лицам, ответ очевиден: сама компания данные и продала. Если компания проведёт расследование и выяснит метод утечки данных, причём её объяснение окажется правдоподобным судье, то судья, без вопросов, присудит компании штраф за то что не прикрыли вот такую очевидную дыру.
3, mary-sue и 300px может оказаться идентификатором сайта А.
Суть в том, что есть 100500 методов слежки за пользователем, существенная часть из них неподконтрольна сайту, какие-то можно нейтрализовать, например вставляя нореферер или просто скачивая и рехостя изображения, но это требует усилий и экспертизы со стороны разработчика сайта. А есть ещё возможность, что сайт похакают и тупо украдут базу пользователей со всеми данными.
Короче, на первый взгляд выбор у владельца сайта между «следить, продавать информацию и предупреждать» или «не следить» и, в виду текущей ситуации, не совсем ясно зачем выбирать второй вариант. В реале же выбор немного другой, между «просто добавить попап с предупреждением» против «отказаться от показа банеров, от использования средств анализа посещаемости, постоянно тратить огромные деньги на предотвращение слежки за посетителями и в конце получить негарантированный результат».
На практике, конечно, всё ещё хуже. На форуме или в комментариях посторонний пользователь оставляет и всё, пошла слежка.
Как бороться, если без попапа с требованием согласиться на любую слежку? Не знаю. Задача поставлена так, что судьба сайта полностью в руках любого другого сайта, с которого загружается хоть что-то. Доказать, что не было сговора с целью слежки нереально.
Приведу пример. Пусть есть сайт А на котором расположена статья о чём-то ужасно постыдном, например о мультфильме My Little Pony. Предположим, статья настолько хороша, что на неё отовсюду ссылаются, в результате чего она всегда вверху выдачи поисковика. В статье перечислены важные моменты сериала с ссылками на серии в нетфликсе. И сайт А принципиально не следит за пользователями, не требует регистрации, не устанавливает куки, не торгует информацией. Но вверху находится один ненавязчивай баннер от сайта banner.com. Пользователь Джо заходит на неследящий поисковик duckduckgo и набирает «сумеречная искорка». Просто дочь его попросила игрушку, ему интересно что это вообще такое. Просматривает статью и закрывает. Но сайт banner.com уже выдал баннер и установил куку. Более того, анализируя реферер, автоматика сайта давно вычислила, что люди, читавшие ту статью, в 30% случаев оказывались на нетфликсе в разделе пони, это естественно, они по ссылкам из статьи ходили. Но наш Джо вдруг замечает, что ему начали подсовывать рекламу новых серий my little pony на нетфликсе. Так как он темой интересовался ровно 1 раз, он знает кто крыса и идёт и пишет жалобу на сайт A. И сайт А штрафуют. Пофиг, что «виноват» banner.com, он, возможно, в другой юрисдикции вообще, да и если и в этой, Джо не заходил ни на какой banner.com, он заходил на сайт А и его именно на сайтп А не предупредили о слежке. И даже если у сайта А есть договор с banner.com в котором чёрным по белому написано, что слежки не будет, сначала оштрафуют А и только потом можно будет пытаться через арбитражный суд получить деньги с владельца banner.com.
Соответственно, единственный способ как-то исполнить GDPR — при входе на сайт А требовать от пользователей согласиться на вообще всё. Единственное исключение — сайт, полностью контролируемый, где нет баннеров, счётчиков, даже подгрузки библиотек или шрифтов с внешнего источника.