IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
On the console indian characters cannot be displayed, hence it is
advisable to disable indian locales on the console, which most
distributions traditionally did from a shell fragment executed post
login. If getty gets started with locale settings passed it would itself
however be translated without the no-indian-on-console fixup applied.
Hence, for now don't pass any locale settings to getty/login, and thus
rely on the classic post-login script fragment to set and fix the
locale.
Eventually we probably want to drop this again since the system locale
should be read and set at one place, and not at multiple, and that one
place should be PID 1.
https://bugzilla.redhat.com/show_bug.cgi?id=663900
TERM=vt100-nav was necessary for compat with some ppc hvc devices, a
long time ago. Unfortunately vt100-nav terminfo is not installed by
default on most distros, hence change the default to v100 which is
available universally and still should be a relatively safe and
conservative default.
Should it turn out that vt100 is not really the best choice we can
revert this change again and then ask distros to move vt100-nav into
their default install.
While this offers quite a few benefits for normally scheduled processes
this breaks RT scheduling for all user processes, since we do not assign
an RT share to the cgroups created via this mechanism. If the user
cgroups have no RT share assigned no member process can make use of RT
functionality. However, software like JACK and PA/rtkit assume that RT
is available in some way or another, either via RLIMIT_RTPRIO or via
some privileged service. Creating implicit cpu cgroups but not adding
RT shares to them hence breaks these applications.
There is no sane way to implicitly add RT shares to these groups, since
they are pulled from a global, limited pool and it would hence be very
hard to make this work without limiting the number of concurrent
sessions, or constantly rewriting the cpu share settings of already
logged in session cgroups.
Most likely this issue needs to be fixed in-kernel because we can enable
this feature by default again.
