История изменений
Исправление ZenitharChampion, (текущая версия) :
> Или очень тупым и ленивым бизнесменом, чтобы не знать что Ubuntu это мейнстрим, и делать надо под нее.
Я бета-тестил Steam в 2012 году, и помню, как он весело сломался в Ubuntu 12.10, ведь бинарники собирались в Ubuntu 12.04. Теперь Valve таскает со стимом тяжёлый Steam Runtime, чтоб внезапно не оказалось, что в Debian 9 выбросили из репов libpng12, например.
На тот момент лучшим выбором в качестве сборочного окружения была CentOS 6. Потому что этот дистр является - промышленным стандартом, с которым другие дистрибутивы Linux дистрибутивы поддерживают совместимость со времён Red Hat 7.2. Даже во FreeBSD линукслятор базируется на bootstrap из библиотек CentOS. В случае со Стимом, сам стим и игры под ним зависели бы от Glibc 2.12+ и ряда стабильных версий библиотек. При этом разработчики игр могли бы воспользоваться новыми компиляторами, которые есть в репозитории devtoolset (без которых не соберёшь, например, steamwebhelper на базе WebKit).
Наверняка Valve на момент разработки знала о Linux не очень много, иначе бы она не стала, например, затачивать Steam только под en_US.UTF-8 (а выбирать язык исключительно в настройках приложения), не позволила бы играм хранить свои конфиги игр непосредственно в директориях самих игр (вместо ~/.config или ~/.local/share). В отличие от ОС Windows, где разработчиков уже никогда не отучишь хранить конфиги игр в Program Files, и из-за чего 99% людей сидят под учёткой администратора (учётка пользователя не умеет создавать файлы внутри Program Files), в Linux можно было решить эту проблему в зародыше, просто не дав ей появиться. Во времена Humble Bundle, Loki Sodftware и LGP, игры исправно хранили конфиги в ~/.appname или ~/.config/appname, вероятно в Valve об этом не знали, и сделали по виндовым привычкам.
И тем не менее, стоит похвалить их трудолюбие (хоть зачастую они героически решали проблемы, которые сами же и создали). За офигенный Steam Overlay, за вклад в SDL2, Mesa и Wine. Кстати, кто-нибудь знает, почему CodeWeavers задавили Cedega, которая предлагала геймерам Wine с поддержкой Direct3D 9 за несколько лет до CodeWeavers, но не давит Proton?
В чём собирать игры сейчас - не знаю. Точно не в CentOS 6, это было актуально лишь в 2012 году и несколько последующих лет. CentOS 8? Но там, блин, гном 3 со всей его неадекватностью, системд и прочее. Хотя играм, наверно, параллельны и то, и другое. Так что пусть будет CentOS 8. Какой там Glibc, кстати, GCC, и есть ли более новый в репах?
Исправление ZenitharChampion, :
> Или очень тупым и ленивым бизнесменом, чтобы не знать что Ubuntu это мейнстрим, и делать надо под нее.
Я бета-тестил Steam в 2012 году, и помню, как он весело сломался в Ubuntu 12.10, ведь бинарники собирались в Ubuntu 12.04. Теперь Valve таскает со стимом тяжёлый Steam Runtime, чтоб внезапно не оказалось, что в Debian 9 выбросили из репов libpng12, например.
На тот момент лучшим выбором в качестве сборочного окружения была CentOS 6. Потому что этот дистр является - промышленным стандартом, с которым другие дистрибутивы Linux дистрибутивы поддерживают совместимость со времён Red Hat 7.2. Даже во FreeBSD линукслятор базируется на bootstrap из библиотек CentOS. В случае со Стимом, сам стим и игры под ним зависели бы от Glibc 2.12+ и ряда стабильных версий библиотек. При этом разработчики игр могли бы воспользоваться новыми компиляторами, которые есть в репозитории devtoolset (без которых не соберёшь, например, steamwebhelper на базе WebKit).
Наверняка Valve на момент разработки знала о Linux не очень много, иначе бы она не стала, например, затачивать Steam только под en_US.UTF-8 (а выбирать язык исключительно в настройках приложения), не позволила бы играм хранить свои конфиги игр непосредственно в директориях самих игр (вместо ~/.config или ~/.local/share). В отличие от ОС Windows, где разработчиков уже никогда не отучишь хранить конфиги игр в Program Files, и из-за чего 99% людей сидят под учёткой администратора (учётка пользователя не умеет создавать файлы внутри Program Files), в Linux можно было решить эту проблему в зародыше, просто не дав ей появиться. Во времена Humble Bundle, Loki Sodftware и LGP, игры исправно хранили конфиги в ~/.appname или ~/.config/appname, вероятно в Valve об этом не знали, и сделали по виндовым привычкам.
И тем не менее, стоит похвалить их трудолюбие (хоть зачастую они героически решали проблемы, которые сами же и создали). За офигенный Steam Overlay, за вклад в Mesa и Wine. Кстати, кто-нибудь знает, почему CodeWeavers задавили Cedega, которая предлагала геймерам Wine с поддержкой Direct3D 9 за несколько лет до CodeWeavers, но не давит Proton?
В чём собирать игры сейчас - не знаю. Точно не в CentOS 6, это было актуально лишь в 2012 году и несколько последующих лет. CentOS 8? Но там, блин, гном 3 со всей его неадекватностью, системд и прочее. Хотя играм, наверно, параллельны и то, и другое. Так что пусть будет CentOS 8. Какой там Glibc, кстати, GCC, и есть ли более новый в репах?
Исходная версия ZenitharChampion, :
> Или очень тупым и ленивым бизнесменом, чтобы не знать что Ubuntu это мейнстрим, и делать надо под нее.
Я бета-тестил Steam в 2012 году, и помню, как он весело сломался в Ubuntu 12.10, ведь бинарники собирались в Ubuntu 12.04. Теперь Valve таскает со стимом тяжёлый Steam Runtime, чтоб внезапно не оказалось, что в Debian 9 выбросили из репов libpng12, например.
На тот момент лучшим выбором в качестве сборочного окружения была CentOS 6. Потому что этот дистр является - промышленным стандартом, с которым другие дистрибутивы Linux дистрибутивы поддерживают совместимость со времён Red Hat 7.2. Даже во FreeBSD линукслятор базируется на bootstrap из библиотек CentOS. В случае со Стимом, сам стим и игры под ним зависели бы от Glibc 2.12+ и ряда стабильных версий библиотек. При этом разработчики игр могли бы воспользоваться новыми компиляторами, которые есть в репозитории devtoolset (без которых не соберёшь, например, steamwebhelper на базе WebKit).
Наверняка Valve на момент разработки знала о Linux не очень много, иначе бы она не стала, например, затачивать Steam только под en_US.UTF-8 (а выбирать язык исключительно в настройках приложения), не позволила бы играм хранить свои конфиги игр непосредственно в директориях самих игр (вместо ~/.config или ~/.local/share). В отличие от ОС Windows, где пользователей уже никогда не отучишь хранить конфиги игр в Program Files, и из-за чего 99% людей сидят под учёткой администратора (учётка пользователя не умеет создавать файлы внутри Program Files), в Linux можно было решить эту проблему в зародыше, просто не дав ей появиться. Во времена Humble Bundle, Loki Sodftware и LGP, игры исправно хранили конфиги в ~/.appname или ~/.config/appname, вероятно в Valve об этом не знали, и сделали по виндовым привычкам.
И тем не менее, стоит похвалить их трудолюбие (хоть зачастую они героически решали проблемы, которые сами же и создали). За офигенный Steam Overlay, за вклад в Mesa и Wine. Кстати, кто-нибудь знает, почему CodeWeavers задавили Cedega, которая предлагала геймерам Wine с поддержкой Direct3D 9 за несколько лет до CodeWeavers, но не давит Proton?
В чём собирать игры сейчас - не знаю. Точно не в CentOS 6, это было актуально лишь в 2012 году и несколько последующих лет. CentOS 8? Но там, блин, гном 3 со всей его неадекватностью, системд и прочее. Хотя играм, наверно, параллельны и то, и другое. Так что пусть будет CentOS 8. Какой там Glibc, кстати, GCC, и есть ли более новый в репах?