| 1.1, аноним (?), 02:08, 18/07/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Интересный факт - FreeBSD Foundation тратит деньги в основном на престиж системы. UTF в консоли и починка паники при вытаскивании флешки - две _абсолютно_ бесполезные фичи, но только к ним и прикапывается школота, которая любит меряться осями.
| | |
| |
| 2.2, Аноним (-), 02:36, 18/07/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
юникод в консоли - не единственная причина почему syscons не оптимален. Более веской причиной будет то, что он
- использует Giant mutex'ы
- нужен интерфейс для KMS (kernel mode setting)[1][2]
- нужен графический режим не только на i386[3]
[1] проблема ослажняется еще тем, что поддержка не-KMS драйверов постепенно уходит в прошлое. По крайней мере так обстоит дело с nouveau.
[2] с KMS наконец-то можно будет отлаживать панику, коя произошла при включенном Xorg'е без необходимости gdb через ssh/serial.
[3] надеюсь эта попытка завершится успехом в отличие от KGI и vtc(4)
Юникод идет скорее как приятное дополнение. 8-битные кодировки уже все равно никто не использует. А от консоли в основном только *требуется* нормальное отображене ASCII.
| | |
| |
| 3.3, аноним (?), 03:27, 18/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
Ну да, про KMS согласен. Только в спонсируемых изменениях этим пока не пахнет.
| | |
|
|
| 1.5, Аноним (-), 04:50, 18/07/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> ed@ упоминает KMS на второй страничке своего гранта
вот оно, один из последних пунктов:
- Implement (common) userspace API for kernel modesetting: 3 weeks.
и далее:
...If we want to support features like kernel modesetting, we will always need to
invest time in writing new drivers to provide modesetting for newer graphics hardware, similar to other subsystems like the network stack.
| | |
| 1.6, pro100master (ok), 11:13, 18/07/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
UTF-8 (16) довольно сомнительная возможность, на мой взгляд.
Юмор. Абдула, вводящий вязь справа-налево будет проклинать неверных, оставивших порядок параметров слева-направо :)))
| | |
| 1.7, Аноним (-), 11:14, 18/07/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну да нафиг unicode в консоли. По прежнему будем при старте Х менять локаль, вместо одной записи в /etc/login.conf. А ntfs-3g только во фре требует де факто X как зависимость. Правильно названия файлов 8.3 транслитом наше все + зоопарк разных кодировок
| | |
| |
| 2.14, prapor (??), 21:28, 18/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Ну да нафиг unicode в консоли. По прежнему будем при старте Х
>менять локаль, вместо одной записи в /etc/login.conf. А ntfs-3g только во
>фре требует де факто X как зависимость. Правильно названия файлов 8.3
>транслитом наше все + зоопарк разных кодировок
Расскажи это клиентам, работающим с всякими арабами, персами, китайцами и т.п. Если, конечно, они есть.
| | |
|
| 1.8, xxx (??), 13:33, 18/07/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>I would almost suggest completely removing the userspace daemon and Sysmouse.
>With Xorg’s switch to the Hardware Abstraction Layer daemon (hald), it would be >a lot more efficient to teach it how to use USB and PS/2 mice directly.
Нафиг этот HAL, оставил бы лучше как есть, ну или хотя бы два варианта.
| | |
| |
| 2.17, аноним (?), 18:25, 20/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Тут имеет место дилемма.
Под FreeBSD есть замечательный devd - легкий, мощный и с удобным конфигом, поэтому мы (BSD'шники) так не любим HAL (хотя его никто не любит, на что там его уже собираются менять?) - во FreeBSD он логически лишняя сущность, вдобавок отягощенная XML, и зависимостями от какой-то слабопонятной хрени. Но не смотря на все преимущества, с devd не умеет работать xorg и DE, т.е. hal все-таки приходится использовать. Логично желание избавиться от лишних сущностей и привести hal и devd к общему знаменателю, но выкидывать devd точно никто не будет, потому что hald убог и gpl - значит, придется дописывать в devd BSD слой для совместимости с hal.
| | |
| |
| 3.19, Аноним (-), 11:46, 21/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> придется дописывать в devd BSD слой для совместимости с hal.
Открой для себя существование hald/freebsd/hf-devd.c
| | |
|
|
| |
| 2.11, iZEN (ok), 15:22, 18/07/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>шрифтом по умолчанию станет знаменитый Terminus. Наконец-то нормальный шрифт искаропки будет.
Terminus нормален? Вы в своём уме?
Посмотрите на Apple Monaco и MS Consolas и сделайте правильные выводы.
| | |
| |
| 3.13, Аноним (-), 20:22, 18/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Посмотрите на Apple Monaco и MS Consolas и сделайте правильные выводы.
TTF шрифты смотрятся ужасно без сглаживания, хинтинга и, иногда, lcd фильтрации. Сомневаюсь, что ed@ будет интегрировать freetype в свой драйвер. Впрочем, freetype доступен под BSD-like лицензией с advertise clause.
| | |
| 3.18, аноним (?), 18:25, 20/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Terminus нормален? Вы в своём уме?
>Посмотрите на Apple Monaco и MS Consolas и сделайте правильные выводы.
По сравнению с этой дрянью Terminus не просто нормален, но замечателен.
| | |
|
|
| 1.10, Аноним (-), 15:17, 18/07/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Мда,от этой бородавки под названием hal уже в линуксе начинают избавляться, а его во фряху тянут за все что можно.
| | |
| 1.12, hatelinux (?), 18:54, 18/07/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
насамом деле при правильном походе к реализации с hald все хорошо работало бы
но у вас в промежутках
xorg->hald->moused->уже драйвер в ядре
появляеться куча глюков
поэтому убрав всякие ненужные демоны и переписав консольный драйвер
возможно удасться добиться более продуктивной и слаженой работы с hald
на самом деле он ничем не мешает(hald)
но вполне вероятно что рано или поздно xorg например выбросит все возможности работы с устройтвами и будет работать только через hald
вот что тогда будут делать те кто пытался избавляться от hald ?
| | |
| |
| 2.21, аноним (?), 04:56, 22/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>на самом деле он ничем не мешает(hald)
Вообще-то он мешает своим наличием, особенно имея только одного consumer'а в виде xorg.
>но вполне вероятно что рано или поздно xorg например выбросит все возможности
>работы с устройтвами и будет работать только через hald
>вот что тогда будут делать те кто пытался избавляться от hald ?
Надеюсь, что к тому времени hald сменят на devicekit и последний окажется не таким угрёбищем.
| | |
|
|
