возможности создать отдельный рабочий стол для работы, для личных задач и даже один для развлечений с помощью опции multiple desktops;
Множественные десктопы были из коробки в Windows 10, я использовал. Откуда утверждение, что они есть в 11, но не в 10?
Или они хотят этим описанием сказать, что ограничили количество таких десктопов тремя? 😨
Вообще же список предельно идиотский. Кажется, что единственная причина - это форсирование авторизации через новые методы, потому что им надоело, что клеят пароли на дисплей, а потом жалуются (и скорее всего это не через рядовых пользователей лаптопов, а через корпорации).
Кстати, у проекта GNOME первой задачей и целью стоит "повышение инклюзивности", а не создание полноценного ГУЯ. Это в принципе все что необходимо знать о линуксе на десктопе.
О проекте Gnome. Который к линуксу в целом имеет примерно такое отношение, как Петербург к России или Лос-Анджелес к США: важная, заметная часть, да, но далеко даже не половина.
Я перешёл на KDE лет 5 назад, до этого почти 15 на WindowMaker. Они другие.
Но вот в Kubuntu делают просто иконку Discoverʼа активной, синяя точка если простые обновления, красные если критичные, видишь и понимаешь, что надо что-то делать. Ну и политика регулируется - от "оно всё само" до "я по пунктам выверяю, что одобрить".
Но боюсь, что основная проблема в пользователях. Нет возможности сказать "да, я уверен, что я достаточно понимаю, что и как делать" и чтобы это было правдой.
Честно, если бы пересадили на винду - я был бы согласен с вариантом "я подтверждаю, что я <название сертификата> и разрешите управлять самому".
Вы не поверите, Но Linux Mint 21.3, RAM 4Гб, HDD 320 Гб, Celeron B820 (2x1.7ГГц) - просто запустить браузер (FireFox) занимает 25-30 секунд. По секундомеру.
Не знаю, что там ещё стоит в системе, но несколько замечание в сторону - для современного десктопа для любой системы 4GB RAM это уже ни о чём. Я меньше чем с 32 не беру. Браузер не виноват, веб-приложения сейчас сожрут что угодно.
Что там Mint делает, не знаю, я ленивый и у меня Kubuntu. Может, они что-то не так собрали. Или то, что Celeron, влияет. Сейчас меньше чем i5 брать вредно даже для дома.
MS ещё с района 2000-го известна хаком, что IE запускался быстро, потому что винда в фоне подгружала его заметную часть. Сравнение тут надо делать честным образом, типа, FF на винде против FF на выбранном вами дистрибутиве (лучше несколько) на идентичных ресурсах, тоже нескольких видов.
Linux начинает свопиться
Это тоже формально не критерий. Он может выселять неактивные страницы. А ещё надо проверить настройку против "bug 12309" (вот тут один из немногих случаев, когда надо хотя бы проверить ручной напильник).
ARM, если AArch64, как раз максимально избавился от костылей. Хотелось бы послушать, где вы там увидели наслоения. (Конечно, с 2011, или когда он там появился, что-то уже искривилось. Но не до такой степени, как x86 со следами разработок 1972 года.)
run --branch=stable --arch=x86_64 --command=NotepadNext --fileforwarding com.github.dail8859.NotepadNext @@ %f @@
"Линукс" ничего такого не требует. Вы выбрали конкретный дистрибутив, в котором такое. И то, я подозреваю, что-то воткнули криво, потому что должно было обеспечиваться автоматически.
Я для десктопа ленив, ставлю убунту. Snap всё это обеспечивает автоматически, максимум работы - воткнуть /snap/bin в $PATH, и то оно при некоторых условиях (лень было вычислять) делает это само.
Можно привести конкретный пример, когда именно в программу это целесообразно захардкодить? Я вам привёл свой конкретный пример, приведите и вы мне свой.
Их миллионы вокруг, этих примеров. Учёт персонала или клиентов: ФИО, как уже обсуждалось (нулевая длина одного компонента не мешает). Счета согласно стандарту и плану счетов, приходы-расходы со счётом, банком и причиной в стандартном формате. Случаев, когда формат данных фиксирован и не требуются дикие изыски (или они просто недопустимы), на порядки больше, когда допускается какая-то супергибкость. И прочая и прочая. Можно не рассматривать чисто внутренние программные интерфейсы, но и в них тоже. И это не просто фактично, это правильно - иначе мы бы все утонули в ненужной сложности. Умение избавиться от громоздкой избыточности и сделать успех через простоту - важнее умения навести гибкость, это как раз умеет "вкатившийся в IT за месяц", по вашим же словам.
Это, однако, не повод рекомендовать для профессиональных программистов практики, принятые промеж невзыскательных кодогенераторов – в лучшем случае вкатившихся в IT за месяц неофитов, а в худшем – механических болванов LLM.
Отличный пример некорректной дискуссии. Сохраню не за идею - в ней нет ничего нового - но за слог.
Но ясно, что там есть свойство "displayName" со значением ассоциативного списка языков, у которого ключу "RU" соответствует "Диафрагменное число", и свойство "getValue" в виде этой лямбды, которая по файлу получает значение поля из EXIF, используя мемоизируемую функцию getExif(object).
И в результате выбор действия перевален на пользователя. Это работает в случае меню Finderʼа, согласен. Но это не работает в подавляющем большинстве случаев, когда именно программе надо понимать, в каком случае и как надо работать с id, в каком с name, в каком с first_name, и так далее.
Если вы скажете, что это по существу таблица виртуальных методов, то будете правы. Только это таблица виртуальных методов, расширяемая в рантайме.
И чего не делается в 99+% кода, ибо избыточно и непонятно, как с ним работать.
Считаю, что этот мой ответ подходит и сюда. Лучше продолжить там (и, как сказал, ваши тезисы, скорее всего, требуют целой статьи для своего обоснования).
Заметьте, что даже фамилия, имя и отчество не идентифицируют клиента.
Замечу. Даже в изначальном примере рядом с name был id.
Но если б использовались нормальные динамические списки свойств, то никакой проблемы бы не возникло.
Это единственное в вашем ответе, что не заслуживает ярлыка "кэпство и оффтопик". Что ж, прошу показать, как именно подобные динамические свойства могут работать в реальном мире, и что будет вместо фиксированного имени поля или ключа в таком случае. Кажется, это тянет на отдельную статью.
А можно привести пример такого бизнеса, которого эти требования?
Хоть банк. Для клиента - физлица или ФЛП пишутся фамилия, имя, отчество. Для простоты мы тут говорили про одно name, даже если их три или больше.
Обычно в нормативно-правовых актах не указывается точный состав ключей, и это как раз произвол погромистов.
Без этого "произвола" не будет адекватного представления, сохранения и передачи данных.
И вся фигня начинается, когда у человека, допустим, нет отчества, а захардкожено, что оно требуется.
Это уже другой вопрос. Как рядом уже писал, отсутствие какого-то компонента нормально, если это описано схемой. Но если вам вместо ключа patronymic придёт отчество или по-батькові, это не должно быть принято как допустимое. И наоборот. И то, что слово patronymic тут "магическая константа" (ц), это не просто можно, это нужно.
Не так важно в данном обсуждении, есть свойство name или нет. Оно может законным образом отсутствовать. Оно может быть разделено на несколько имён разного типа (как Ф, И, О или первое, второе, среднее, последнее). Важно, что оно, если есть, оно в поле (или под ключом) name, а не nomen, імʼя или mane. Именно об этом речь, а ваши возражения выглядят как прямая попытка увода дискуссии куда-то в неадекватную сторону.
Три числа через точку, у которых главное - что при переходе по межнодовому соединению часть компонентов (кажется, только первый?) может меняться? Ну, "такое". Если бы сразу генерировали, например, в виде UUIDv1 с рандомом на месте MAC, получилось бы то же самое, но без необходимости конверсии. Главное, что его вредно запоминать в долговременном.
UUID
Текстовая строка, бинарь в 16 байт, на выбор. Важно только единообразие сериализации. И, что важнее к данному разговору, есть масса эквивалентов для всех случаев.
Итого - оба ни о чём.
стабильного порядка ключей в словарях, который ярко демонстрирует проблемы с дизайном у автора кода
Не у автора кода, а в когнитивных способностях человека, которые начинают проявляться в случае сверки данных (при отладке, верификации, да когда угодно). И снова у вас приступ верхоглядства с игнорированием сути.
А вот задач для них, действительно, увы - именно потому, что отцы-основатели застыли тупыми блоками бетона в концепциях ровно уровня диссера Армстронга и не дальше.
Потому что экспериментировали - и потому что для сервера-раздатчика с небольшим входящим потоком и обменом на среднем уровне "пара сообщений в час" он вполне подходит.
А вот если бы каждый пользователь WhatsApp слал новое сообщение хотя бы раз в три секунды, эрланг бы подох, не сумев отшедулить всю эту массу объекто-серверов по одному на пользователя.
и почему в 90% роутеров используется именно эрланг.
Это уже обсуждали - Erlang где-то там сбоку припёка на конфигурационных функциях (даже в исходном AXD301 было где-то так же, область применения по сути не расширилась). Тут позиция "не упадём и потому не утащим за собой собственно раутинг, даже если конфигуратор что-то не осилил" - самое оно. Но и тут что Go, что Java, что ещё десяток альтернатив подошли бы не хуже.
А у AArch32 развития толком уже не будет, зато есть профили, которые позволяют не работать с полным комплектом костылей.
Я вот этого в упор не понял:
Множественные десктопы были из коробки в Windows 10, я использовал. Откуда утверждение, что они есть в 11, но не в 10?
Или они хотят этим описанием сказать, что ограничили количество таких десктопов тремя? 😨
Вообще же список предельно идиотский. Кажется, что единственная причина - это форсирование авторизации через новые методы, потому что им надоело, что клеят пароли на дисплей, а потом жалуются (и скорее всего это не через рядовых пользователей лаптопов, а через корпорации).
О проекте Gnome. Который к линуксу в целом имеет примерно такое отношение, как Петербург к России или Лос-Анджелес к США: важная, заметная часть, да, но далеко даже не половина.
Я перешёл на KDE лет 5 назад, до этого почти 15 на WindowMaker. Они другие.
Ну если секьюрити, то в этом какой-то смысл есть.
Но вот в Kubuntu делают просто иконку Discoverʼа активной, синяя точка если простые обновления, красные если критичные, видишь и понимаешь, что надо что-то делать. Ну и политика регулируется - от "оно всё само" до "я по пунктам выверяю, что одобрить".
Но боюсь, что основная проблема в пользователях. Нет возможности сказать "да, я уверен, что я достаточно понимаю, что и как делать" и чтобы это было правдой.
Честно, если бы пересадили на винду - я был бы согласен с вариантом "я подтверждаю, что я <название сертификата> и разрешите управлять самому".
Если речь про UX, то лучше Windows 2000. XP уже была подломанная.
А вот внутренности, увы, постоянно требуют развития.
Не знаю, что там ещё стоит в системе, но несколько замечание в сторону - для современного десктопа для любой системы 4GB RAM это уже ни о чём. Я меньше чем с 32 не беру. Браузер не виноват, веб-приложения сейчас сожрут что угодно.
Что там Mint делает, не знаю, я ленивый и у меня Kubuntu. Может, они что-то не так собрали. Или то, что Celeron, влияет. Сейчас меньше чем i5 брать вредно даже для дома.
MS ещё с района 2000-го известна хаком, что IE запускался быстро, потому что винда в фоне подгружала его заметную часть. Сравнение тут надо делать честным образом, типа, FF на винде против FF на выбранном вами дистрибутиве (лучше несколько) на идентичных ресурсах, тоже нескольких видов.
Это тоже формально не критерий. Он может выселять неактивные страницы. А ещё надо проверить настройку против "bug 12309" (вот тут один из немногих случаев, когда надо хотя бы проверить ручной напильник).
ARM, если AArch64, как раз максимально избавился от костылей. Хотелось бы послушать, где вы там увидели наслоения.
(Конечно, с 2011, или когда он там появился, что-то уже искривилось. Но не до такой степени, как x86 со следами разработок 1972 года.)
"Линукс" ничего такого не требует. Вы выбрали конкретный дистрибутив, в котором такое. И то, я подозреваю, что-то воткнули криво, потому что должно было обеспечиваться автоматически.
Я для десктопа ленив, ставлю убунту. Snap всё это обеспечивает автоматически, максимум работы - воткнуть /snap/bin в $PATH, и то оно при некоторых условиях (лень было вычислять) делает это само.
Их миллионы вокруг, этих примеров. Учёт персонала или клиентов: ФИО, как уже обсуждалось (нулевая длина одного компонента не мешает). Счета согласно стандарту и плану счетов, приходы-расходы со счётом, банком и причиной в стандартном формате. Случаев, когда формат данных фиксирован и не требуются дикие изыски (или они просто недопустимы), на порядки больше, когда допускается какая-то супергибкость. И прочая и прочая. Можно не рассматривать чисто внутренние программные интерфейсы, но и в них тоже. И это не просто фактично, это правильно - иначе мы бы все утонули в ненужной сложности. Умение избавиться от громоздкой избыточности и сделать успех через простоту - важнее умения навести гибкость, это как раз умеет "вкатившийся в IT за месяц", по вашим же словам.
Отличный пример некорректной дискуссии. Сохраню не за идею - в ней нет ничего нового - но за слог.
Вы про схему или про закодированное?
И в результате выбор действия перевален на пользователя. Это работает в случае меню Finderʼа, согласен. Но это не работает в подавляющем большинстве случаев, когда именно программе надо понимать, в каком случае и как надо работать с id, в каком с name, в каком с first_name, и так далее.
И чего не делается в 99+% кода, ибо избыточно и непонятно, как с ним работать.
Вижу, я зря надеялся на конструктив.
Какие у неё аргументы? Какой тип результата? Как она представлена в этом списке, под каким ключом? Какие условия для её вызова?
Однако, он подключается каким-то стандартным API.
Надеюсь, понятно, что эти критерии поиска откуда-то взяты и там они записаны как текстом, так и правилами извлечения из файлов.
Считаю, что этот мой ответ подходит и сюда. Лучше продолжить там (и, как сказал, ваши тезисы, скорее всего, требуют целой статьи для своего обоснования).
Замечу. Даже в изначальном примере рядом с
nameбылid.Это единственное в вашем ответе, что не заслуживает ярлыка "кэпство и оффтопик". Что ж, прошу показать, как именно подобные динамические свойства могут работать в реальном мире, и что будет вместо фиксированного имени поля или ключа в таком случае. Кажется, это тянет на отдельную статью.
Хоть банк. Для клиента - физлица или ФЛП пишутся фамилия, имя, отчество. Для простоты мы тут говорили про одно name, даже если их три или больше.
Без этого "произвола" не будет адекватного представления, сохранения и передачи данных.
Это уже другой вопрос. Как рядом уже писал, отсутствие какого-то компонента нормально, если это описано схемой. Но если вам вместо ключа
patronymicпридётотчествоилипо-батькові, это не должно быть принято как допустимое. И наоборот. И то, что словоpatronymicтут "магическая константа" (ц), это не просто можно, это нужно.Не так важно в данном обсуждении, есть свойство name или нет. Оно может законным образом отсутствовать. Оно может быть разделено на несколько имён разного типа (как Ф, И, О или первое, второе, среднее, последнее). Важно, что оно, если есть, оно в поле (или под ключом)
name, а неnomen,імʼяилиmane. Именно об этом речь, а ваши возражения выглядят как прямая попытка увода дискуссии куда-то в неадекватную сторону.Три числа через точку, у которых главное - что при переходе по межнодовому соединению часть компонентов (кажется, только первый?) может меняться?
Ну, "такое". Если бы сразу генерировали, например, в виде UUIDv1 с рандомом на месте MAC, получилось бы то же самое, но без необходимости конверсии. Главное, что его вредно запоминать в долговременном.
Текстовая строка, бинарь в 16 байт, на выбор. Важно только единообразие сериализации. И, что важнее к данному разговору, есть масса эквивалентов для всех случаев.
Итого - оба ни о чём.
Не у автора кода, а в когнитивных способностях человека, которые начинают проявляться в случае сверки данных (при отладке, верификации, да когда угодно). И снова у вас приступ верхоглядства с игнорированием сути.
Лично мне Erlang нравится больше Elixir.
А вот задач для них, действительно, увы - именно потому, что отцы-основатели застыли тупыми блоками бетона в концепциях ровно уровня диссера Армстронга и не дальше.
Потому что экспериментировали - и потому что для сервера-раздатчика с небольшим входящим потоком и обменом на среднем уровне "пара сообщений в час" он вполне подходит.
А вот если бы каждый пользователь WhatsApp слал новое сообщение хотя бы раз в три секунды, эрланг бы подох, не сумев отшедулить всю эту массу объекто-серверов по одному на пользователя.
Это уже обсуждали - Erlang где-то там сбоку припёка на конфигурационных функциях (даже в исходном AXD301 было где-то так же, область применения по сути не расширилась). Тут позиция "не упадём и потому не утащим за собой собственно раутинг, даже если конфигуратор что-то не осилил" - самое оно. Но и тут что Go, что Java, что ещё десяток альтернатив подошли бы не хуже.