LINUX.ORG.RU

Frugalware - хорошо, Slackware - хорошо, а олени лучше

chukcha, я призываю тебя!

ashot ★★★ ()

Slackware. Во Frugalware давно из коробки systemd. И когда я последний раз смотрел Frugalware она была разбита на кучу мелких пакетиков без метапакетов и было непонятно как это собирать в единое целое. Доустанавливаешь, доустанавливаешь,... , а всё только ещё начинается. А Slackware можно поставить левой пяткой и она сразу взлетит.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

Тогда почему не FreeBSD? Там нет systemd, там есть пакеты и порты.

IPR ★★★★★ ()
Ответ на: комментарий от IPR

Гм. FreeBSD тоже неплохой вариант, да. Но, к сожалению, ext4fuse (как и системный драйвер ReiserFS) умеет только читать, что несколько усложняет переход с линуксов. Также, если юзать без иксов, то огорчает, что новый vt (он же newcons), в отличие от syscons'а, заточен конкретно под UTF-8, а новые фреймбуферовские драйвера заточены именно под vt, а в syscons'е есть только какая-то обгрызенная VESA. А вот если юзать или локаль UTF-8 или с иксами, то FreeBSD тоже неплохой вариант, да.

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от kshmr

У меня сетевуха не поддерживается.

Это какая? Я вот ноут б/у прикупил, поставил Фряху, настроил под себя и горя не знаю. https://imgur.com/a/RTZOw

IPR ★★★★★ ()
Ответ на: комментарий от IPR

rtl8723ae. Проверял на фряхе, про Open и NetBSD не знаю пока.

kshmr ()
Ответ на: комментарий от saahriktu

utf-8 норм же, ну. Никто не мешает использовать для хранения текстов koi8-r.

IPR ★★★★★ ()
Ответ на: комментарий от kshmr

Так поменять же минута дела, ну. Atheros'ы отлично работают.

IPR ★★★★★ ()
Ответ на: комментарий от IPR

Ноут от ДНонС, поэтому его никак не разобрать, следовательно сетевуху не вытащить.

kshmr ()

фругал это слака+пакман из арча, не?

eR ★★★★★ ()
Ответ на: комментарий от IPR

В прямом. Я однажды пытался - там все скреплено пластиком (весь ноут внутри пластиковый), пытался вытащить CMOS батарейку - её не вытащить, ибо она прикрыта крышкой. Сетевухи не нашёл - так далеко не смог забраться. Только USB свисток покупать...

kshmr ()

bormant, я призываю тебя!

На этот раз мимо. Про Frugalware только слышал, сам не пользовался, посоветовать ничего не могу...

bormant ★★★★★ ()
Ответ на: комментарий от saahriktu

А есть хоть одна серьёзная причина использовать не UTF-8?

Ну кроме древнего проприетарного софта или чего-то другого древнего. Для домашнего пользователя.

Xenius ★★★★★ ()
Ответ на: комментарий от Xenius

Тут наоборот. Какие серьёзные причины использовать UTF-8? Тем более в тех условиях, когда у юзера 256 символов в шрифте, а все остальные отображаются одинаковыми квадратиками? У ряда людей есть свои основания не любить UTF-8. Тот же автор GNU'того однобайтного текстового редактора moe писал:

Moe uses ISO-8859-15 instead of UTF-8 because an 8-bit character set (combined with romanization if needed) can convey meaning safely and more efficiently than UTF-8 can.

UTF-8 is a great tool for tasks like writing books of mathematics or mixing Greek with Chinese in the same document. But for many other everyday computing and communication tasks, an 8-bit code like ISO-8859-15 is much more practical, efficient and reliable. There is no such thing as an «invalid» or «out of range» ISO-8859-15 character.

UTF-8 is fine for non-parsable, non-searchable documents that must look «pretty», but not so fine for things like configuration files or C++ source code. UTF-8 greatly hinders parsability (and may even become a security risk) by providing multiple similar-looking variations of basic alphabetic, punctuation, and quoting characters. UTF-8 also makes search difficult and unreliable. For example, searching for a word like «file» in an UTF-8 document may fail if the document uses the compound character 'fi' instead of the string «fi».

В общем, во многих случаях однобайтные кодировки гораздо удобнее чем юникод. То, что под юникод могут быть не заточены старые реализации свободного софта, - это, можно сказать, совпадение. Когда юзер выбравший однобайтную кодировку находит тот софт, который не умеет работать с тем, что ему и не нужно, но прямо оно его и не касается. Оно же ему не нужно.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

Какие серьёзные причины использовать UTF-8?

Такие, что любой айтишник из России в любом случае половину времени пишет и читает латиницу, а не кириллицу.

UTF-8 is fine for non-parsable, non-searchable documents

Что за бред? Там всё прекрасно ищется и парсится.

UTF-8 also makes search difficult and unreliable. For example, searching for a word like «file» in an UTF-8 document may fail if the document uses the compound character 'fi' instead of the string «fi».

Кто ж заставляет лигатуры использовать? Их и не использует никто, кроме людей, которые в Индизайне или каком-нибудь Латехе книжки верстают. И те, кто их используют, отлично знают про подводные камни.

В общем, во многих случаях однобайтные кодировки гораздо удобнее чем юникод.

Ты просто любишь ретро-софт и, вероятно, ретро-железно. Но пытаешься своим эстетическим предпочтением найти логическое обоснование, мол это «иногда удобно и эффективно».

// Не, я не пытаюсь тебя всерьез переубедить.

Deleted ()
Ответ на: комментарий от saahriktu

Какие серьёзные причины использовать UTF-8?

А какие серьёзные причины использовать ASCII? Она в общем-то довольно неоптимально устроена.

Вот UTF-8 сейчас и занимает место ASCII постепенно, но уже не только для латиницы. Другие кодировки в софте поддерживают всё реже и тд.

Тем более в тех условиях, когда у юзера 256 символов в шрифте, а все остальные отображаются одинаковыми квадратиками?

Кто запрещает использовать более полный шрифт, например Unifont?

but not so fine for things like configuration files or C++ source code.

Не вижу проблем. Главное символы, не входящие в ASCII использовать только в литералах и комментариях, а лучше вообще нигде не использовать (но подразумевая что документ UTF-8). Вообще по-моему выкладываь код с не-ASCII символами, который не в UTF-8 — это плохой тон.

if the document uses the compound character 'fi' instead of the string «fi».

Никто так в здравом уме не делает. А если хочется затруднить жизнь народу можно подменять часть a на а и тд

Xenius ★★★★★ ()
Ответ на: комментарий от Xenius

Есть причина таки внутри хранить в 32-х битных wchar.

Shadow ★★★★★ ()
Ответ на: комментарий от Xenius

А есть хоть одна серьёзная причина использовать не UTF-8?

Как ты умудрился пропустить все диалоги с ним на эту тему?

ashot ★★★ ()

Frugalware не использовал, но Пацман - весомый довод. Но тут уже встаёт вопрос - а почему не использовать просто Арч, с его АУР, огромным репозиторием, и т. д.

meliafaro ★★★★★ ()
Ответ на: комментарий от Xenius

А какие серьёзные причины использовать ASCII?

Любая однобайтная кодировка больше чем ASCII.

Кто запрещает использовать более полный шрифт, например Unifont?

Ограничения ядра. Да, речь в т.ч. (и особенно) про ядерный vt, в который захардкожено, что максимальный размер *.psf шрифта - 64 Кб.

saahriktu ★★★★★ ()
Ответ на: комментарий от meliafaro

Слака сама по себе не развалится. Я очень люблю арч, но он мне уже порядком поднадоел.

kshmr ()
Ответ на: комментарий от saahriktu

Любая однобайтная кодировка больше чем ASCII.

Там байты другие штоле? Более жирные?

Ограничения ядра.

Зачем потребности приложений юзерспейса загонять в рамки ограничений ядра? Кесарю кесарево, слесарю - слесарево.

meliafaro ★★★★★ ()
Ответ на: комментарий от meliafaro

Там байты другие штоле? Более жирные?

ASCII - это 7-ми битная кодировка. Она использует байт не полностью. Оставляя в этом байте столько же места для второй половины таблицы символов однобайтных кодировок.

Зачем потребности приложений юзерспейса загонять в рамки ограничений ядра?

Что значит «загонять»? У разных людей разные эмуляторы терминалов. Ядерный vt - это тоже эмулятор терминала. И в нём можно жить без иксов и вейланда. Только ядерная консоль с её *.psf шрифтами.

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Любая однобайтная кодировка больше чем ASCII.

Я знаю. Но почти все содержат ASCII как подмножество. А почему бы не использовать кодировку, где первая половина таблицы распределена более экономно? Из управляющих символов больше половины не нужно, а нужные используются неоптимально.

К примеру, сочетание \r\n там где было бы достаточно просто \n. И роли значительной части символов плохо определены. Хотя гораздо удобнее было бы иметь отдельные символы для разрыва строки, разрыва абзаца, разрыва страницы, разрыва раздела с чётко определенными ролями вместо \r \n \v \f. И какое-то чётко заданое значение для символа \t, например как в концепции elastic tabstops.

В общем ASCII далеко не идеальна, но все пользуются и не проявляют ни малейшего желания что-то в ней менять, потому что единый везде стандарт, даже не очень хороший оказывается много лучше зоопарка стандартов. Вот так же и UTF-8, хоть и не во всём идеален, но гораздо лучше зоопарка устаревших однобайтных кодировок, которых для одной кириллицы около десятка.

И ни одной кодировки которая лучше UTF-8 пока нигде не внедрили.

Xenius ★★★★★ ()
Последнее исправление: Xenius (всего исправлений: 1)
Ответ на: комментарий от Xenius

К примеру, сочетание \r\n там где было бы достаточно просто \n.

В UNIX'ах и так «просто \n». А устаревшие управляющие коды могут использоваться современным софтом по-своему. Так что, наличие такого резерва кодов в ASCII даже полезно, а не «неоптимально». У простых как палки однобайтных кодировок свои преимущества. Никаких модификаторов, каждый символ ровно по байту, а каждый байт - символ. Никаких непредсказуемостей, неопределённостей и «некорректных последовательностей байтов» на которых ломаются парсеры юникода. Любая последовательность байтов всегда будет корректной последовательностью символов в той или иной однобайтной кодировке, причём единственно возможной (а не так что в байтах не только символы, но и служебная информация, которая срезается по маске). В юникоде всего этого нет.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

В UNIX'ах и так «просто \n».

Не совсем. Есть ведь HTTP и IMAP всякие. И терминал.

А устаревшие управляющие коды могут использоваться современным софтом по-своему.

Стандарт нужен чтобы везде было всё одинаково и из-за проблем совместимости чаще всего в софте управляющие символы игнорируют или объявляют некорректными, а не используют по-своему.

Так что, наличие такого резерва кодов в ASCII даже полезно, а не «неоптимально».

Да ладно, и где ты видел современный софт который как-то использует коды ASCII кроме пары-тройки нужных для форматирования текста?

Никаких непредсказуемостей, неопределённостей и «некорректных последовательностей байтов» на которых ломаются парсеры юникода.

Вообще-то есть. Например коды C1 и довольно известные глюки DOS с буквой я

Любая последовательность байтов всегда будет корректной последовательностью символов в той или иной однобайтной кодировке, причём единственно возможной

Тоже не совсем. В последовательности байт могут встретиться управляющие коды.

Xenius ★★★★★ ()
Ответ на: комментарий от Xenius

и где ты видел современный софт который как-то использует коды ASCII

То, что такого софта нет, не значит, что такого софта не может быть вообще. Тот же софт от Microsoft'а, ЕМНИМС, для своих внутренних нужд делает разметку текста прямо в самом тексте.

Вообще-то есть. Например коды C1 и довольно известные глюки DOS с буквой я

Это проблемы конкретного софта, а не кодировок.

Тоже не совсем. В последовательности байт могут встретиться управляющие коды.

Управляющие коды - это тоже символы, хоть и не отображаемые (отдельные - отображаемые частично в виде форматирования). При необходимости визуализации им могут назначаться свои соответствия. Ну или может быть достаточно представления уровня «hexdump -C»:

00000170  06 cc 22 2c 77 9c af d6  15 1c 3a 77 b3 75 7e 0c  |.л",w°╞ж..:wЁu~.|

saahriktu ★★★★★ ()
Ответ на: комментарий от Xenius

А есть хоть одна серьёзная причина использовать не UTF-8?

Очевидно, типографика. Ну и одновременное использование нескольких языков в тексте тоже полезно. Вот есть ли хоть одна причина использовать нынче koi8-r? Кроме древнего проприетарного софта.

skiminok1986 ★★★★★ ()
Последнее исправление: skiminok1986 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.