LINUX.ORG.RU
ФорумTalks

На freebsd.org обновили handbook в KOI8-R

 ,


1

2

Сабж.

   Добро пожаловать в FreeBSD! Это Руководство охватывает процесс установки и ежедневного использования FreeBSD
   10.3-RELEASE и FreeBSD 11.0-RELEASE. Оно находится в процессе разработки и являет собой результат работы
   множества людей. Многие из разделов до сих пор не существуют, а некоторые из существующих требуют обновления.
   Linkname: Руководство FreeBSD
        URL: https://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/?C=M&O=D
    Charset: koi8-r
     Server: ToTheCloud/v0.01
       Date: Fri, 03 Mar 2017 14:38:56 GMT
   Last Mod: Fri, 03 Mar 2017 12:27:11 GMT
Читать: https://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/?C=M&O=D

★★★★★
Ответ на: комментарий от redgremlin

Я говорил только, что в их багзилле глухо. А так tty в ядре постоянно развивается. Разница между drivers/tty только между ядрами 4.9 и 4.10 в виде патча формата «unified context diff» весит 67841 байт, 2259 строк.

Конечно, всё это можно было пилить гораздо активнее. Как и многое другое. Но, что сегодня вообще активно пилят кроме Firefox'а/Chrome/etc и серверного софта и скриптов? Да и надо ли особо пилить, если софт и так уже достиг потолка функциональности? Остаётся вносить только исправления для согласования технологий. И как получается их вносить, так и получается.

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

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

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

Например, Ганс Христиан Рейзерстен.

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

На этот момент есть разные точки зрения. То, что Вы приводите, лишь одна из них, и больше похожа на «экономическую точку зрения». В смысле родственности с такими утверждениями как: «Надо активно развивать экономику, поскольку деньги решают всё...». Но, далеко не все с этим могут согласиться. Более того, это, так сказать, более циничный и более грубый путь жизни. При большом жизненном опыте и незакрытых глазах человек неоднократно может видеть ситуации, которые никакими деньгами и технологиями никогда не решить. Конечно, человек может занять ту позицию, что вот лично его это всё никак не касается, а сам для себя он всё решает. Но, это опять же тот же самый грубый цинизм. Конечно, можно занять позицию, что грубый цинизм - норма, но... Это замкнутый круг и не все хотят его не разрывать. А для ряда людей оно и так всегда было чуждо.

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

Глупости какие-то. Как koi8 сделает мир лучше? Это пережиток прошлого, используемый тремя с половиной маргиналами, которым потеря пары десятков мегабайт оперативной памяти кажется невосполнимой утратой. Да и плевать на убогих.

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

KOI8-R помогает упрощать низкоуровневую работу со строками. Если каждый символ - один байт, то и каждый байт - один символ.

Есть, конечно, та же UTF-32, но не случайно такую локаль и её поддержку в компиляторах и утилитах командной строки так и не ввели. Наибольшая часть кода и текстов всё равно в ASCII, а тратить на каждый ASCII символ по 4 байта... Это только лишняя трата ресурсов памяти и машинного времени.

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

git не использует библиотечные юникодные функции с их wchar_t по 4 байта на символ. Его разработчики как раз таки пошли путём экономии памяти через усложнение парсеров строк.

А при использовании KOI8-R эти самые парсеры усложнять нет необходимости.

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

В библиотеке нет юникодных функций

Как это нет? wprintf, wscanf, wcscpy, wcscat, wcscmp,... - всё это и есть библиотечные юникодные функции для работы с «wide char» (т.е. юникодными) строками.

Классические printf, scanf, fputs, putc, strcmp,... которые и использует код git'а вместо специализированных из wchar.h - это функции для строк в однобайтных кодировках.

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

Покажи мне функцию нормализации юникодной строки. Не говоря уже о том, что в unicode4 прямо прописано, что этот хидер не имеет с юникодом ничего общего.

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

Покажи мне функцию нормализации юникодной строки.

Это уже другой вопрос. От того, что такой функции в библиотеки нет, другие функции для работы с мультибайтными (юникодными) строками из неё не исчезают.

Не говоря уже о том, что в unicode4 прямо прописано, что этот хидер не имеет с юникодом ничего общего.

В давно устаревшем стандарте юникода? В wchar.h прямо прописано:

/*
 *      ISO C99 Standard: 7.24
 *      Extended multibyte and wide character utilities <wchar.h>
 */
«multibyte and wide character utilities», а не «singlebyte character utilities». А всё, что не имеет отношения к работе с однобайтными строками, - юникодное, поскольку предназначено для работы именно с многобайтными (юникодными) строками.

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

Это самый прямой вопрос. Потому что без таблицы кодирования и функций композиции / декомпозиции эти твои функции никому не уперлись. Не говоря уже о том, что wchar разный на разных платформах, а стандартом де-факто является utf8, не utf32.

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

без таблицы кодирования и функций композиции / декомпозиции

Где такое вообще есть?

wchar разный на разных платформах

Тем не менее, проблемы с кроссплатформенностью у wchar_t возникают только на винде при работе с текстом в UTF-32.

а стандартом де-факто является utf8, не utf32

Ну так а я о чём. Из за того, что в UTF-8 у разных символов разный вес в байтах, при работе со строками в UTF-8 есть только 2 варианта:
0) прочитать не в «char *», а в «wchar_t/char16_t/char32_t *». При этом, условно говоря, оно автоматически переконвертируется в условные UTF-16/UTF-32, что облегчит дальнейший разбор строк функциями из wchar.h и т.д., но и выжрет больше памяти.
1) прочитать в «char *», а дальше парсить сложными парсерами на основе функций для однобайтных кодировок.

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

Впрочем, именно поэтому такой софт сохраняет совместимость с однобайтными кодировками на всех уровнях.

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

Это есть в icu, например. И да, чтобы прочитать в wchar32, тебе нужно провести нормализацию. Иначе две одинаковые строки могут оказаться разными для функции сравнения строки.

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

Так библиотека ICU использует wchar_t и wchar.h:

*   file name:  cwchar.h
*   encoding:   US-ASCII
*   tab size:   8 (not used)
*   indentation:4
*
*   created on: 2001may25
*   created by: Markus W. Scherer
*
*   This file contains ICU-internal definitions of wchar_t operations.
*   These definitions were moved here from cstring.h so that fewer
*   ICU implementation files include wchar.h.
*/

#ifndef __CWCHAR_H__
#define __CWCHAR_H__

#include <string.h>
#include <stdlib.h>
#include "unicode/utypes.h"

/* Do this after utypes.h so that we have U_HAVE_WCHAR_H . */
#if U_HAVE_WCHAR_H
#   include <wchar.h>
#endif
А, повторяю, речь о том, что разработчики предпочитают избегать мультибайтных функций и ICU, и вместо этого парсят UTF-8 однобайтными функциями без ICU. Просто потому, что это экономит память. Иначе софт жрал бы гораздо больше оперативки.

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

Так библиотека ICU использует wchar_t и wchar.h

Ты видел, как они используют wchar?

U_CAPI int32_t   U_EXPORT2
u_strlen(const UChar *s) 
{
#if U_SIZEOF_WCHAR_T == U_SIZEOF_UCHAR
    return (int32_t)uprv_wcslen((const wchar_t *)s);
#else
    const UChar *t = s;
    while(*t != 0) {
      ++t;
    }
    return t - s;
#endif
}

И ещё три подобных вызова. На этом всё :)

А, повторяю, речь о том, что разработчики предпочитают избегать мультибайтных функций и ICU, и вместо этого парсят UTF-8 однобайтными функциями без ICU. Просто потому, что это экономит память. Иначе софт жрал бы гораздо больше оперативки.

Нет, просто потому, что авторы программ на C частенько из США или Канады, где остальные кодировки просто никому не уперлись. А во всех остальных языках (ну кроме плюсов), юникод не требует какой-то особой обработки и вполне доступен из коробки.

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

Как бы то ни было wchar.h и ICU одного поля ягоды, и не рассчитаны на работу со строками типа «char *». ICU вообще работает только с собственным классом UnicodeString и типом данных UChar, который приближает строки к UTF-16:

UChar to be an unsigned 16-bit integer type. This is the base type for character arrays for strings in ICU.

Нет, просто потому, что авторы программ на C частенько из США или Канады, где остальные кодировки просто никому не уперлись.

Это не отменяет того, что юникод проще парсить при помощи мультибайтных функций и ICU. Но, разработчики их избегают, и усложняют парсеры.

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

Ну конечно всем лениво постоянно гонять конверсию между utf16 и char *, который ожидает большая часть существующего кода. Чуваки идут по пути наименьшего сопротивления, не понимаю, что тебя удивляет.

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

Для выделения подстрок нужно разбирать строки на отдельные символы. Это проще делать через специализированные мультибайтные инструменты как wchar.h и ICU. А без них остаётся разбирать по байту руками, да ещё и прикручивать таблицу модификаторов, чтобы случайно не оказаться посреди символа. Это если по-хорошему. А на практике таблицу модификаторов прикручивают не всегда. А потому внимательные юзеры юникода замечают как софт неправильно делит юникодные строки. Чего могло бы не быть при привлечении мультибайтных функций и ICU.

С однобайтными кодировками таких проблем никогда нет.

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

Чувак, я повторюсь, твоя проблема есть только в си и плюсах. Остальные переехали на юникод сто лет назад и даже не задумываются про кодироъвки. То, что в си и плюсах нет utf8 из коробки, это наследие ранней эпохи. Не говоря уже о том, что строки там убогие.

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

что в мире ничего к лучшему и не менялось бы.

ну так и поменялось, же. С утф больше нет проблем со всякими бНОПНЯ'ми

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

в прошлом столетии «идеалисты» отправили на тот свет людей на МНОООГО больше чем «циники». Так что нет, спс, циники получше будут.

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

Так и у юзеров локали KOI8-R нет проблем с кодировками, поскольку всё кругом автоматизировано на автоматическое получение текстов в KOI8-R. lynx тоже автоматически всё конвертирует на лету. бНОПНИ остаются только в виндовых *.txt, которые были получены байт в байт, но это спокойно решается через enca и iconv.

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

А если математики соберутся и пойдут стрелять людей, то математика сразу станет хуже какой-нибудь лингвистики? В любой группе можно найти лиц с перегибами.

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

Так, внезапно, и юзеры локали UTF-8 при скачивании виндовых *.txt байт в байт получат их в кодировке cp1251, и им тоже надо будет применять enca и iconv.

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

если они это будут делать во имя математики - то да.

В любой группе можно найти лиц с перегибами.

нормальные такие перегибы, положить во имя своих идеалов ~100кк людей за столетие... хорошие такие перегибы.

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

если они это будут делать во имя математики - то да.

Каким образом это может что-то менять? Мало ли кто что думает. Сколько людей столько и мнений.

А если завтра сторонники юникода во имя юникода заминируют каждый пятый автобус, оставляя на местах взрывов рекламу юникода, и таким образом рекламируя юникод, то Вы перейдёте на однобайтную локаль? Ведь по Вашей логике это должно в обязательном порядке бросать тень на юникод.

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

Не надо, на венде уже тоже юникод.

И в качестве кодировки при сохранении файлов тоже? Какая разница что внутри виндовых подсистем если рядовой юзер сохраняя тексты из Блокнота получает *.txt файлы в cp1251? А, как свидетельствуют некоторые товарищи, так было до самого последнего времени.

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

ЩИТО?

Сколько угодно попадается побайтно разорванных на полусимволе сокращённых фраз, например.
обычно в заголовках или автоматически сформированных цитатах.
Характерный признак — «убитый» в кракозябра последний символ строки перед каким-нибудь многоточием.
( http://www.opennet.ru/openforum/vsluhforumID3/110093.html )

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

угу, читая дальше:

А, на опеннете же. Да, точно, хороший пример.

Но вот проблема-то создана именно тем, что сайт использует KOI8-R. а пользователи вводят данные в UTF-8. :)

нуф сказал.

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

Там автор комментария написал, что это он наблюдал именно что не на опеннете, а в интернете вообще.

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

ну обс, же. скриншотик хотя бы приложил.

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

И в качестве кодировки при сохранении файлов тоже? Какая разница что внутри виндовых подсистем если рядовой юзер сохраняя тексты из Блокнота получает *.txt файлы в cp1251? А, как свидетельствуют некоторые товарищи, так было до самого последнего времени.

Какая разница, что там в блокноте? Он до сих пор кривые linebreak'и ставит, тебе один хрен конвертировать придется. Я знаю очень мало людей, которые им вообще пользуются.

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

Какая разница, что там в блокноте?

Ну так *.txt файлы из него потом попадают в интернет, и их приходится конвертировать как юзерам локали KOI8-R так и юзерам локали UTF-8. Я не говорил, что им пользуются все виндузятники. Но, в интернете куча виндовых *.txt файлов в cp1251.

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

Ну так *.txt файлы из него потом попадают в интернет, и их приходится конвертировать как юзерам локали KOI8-R так и юзерам локали UTF-8. Я не говорил, что им пользуются все виндузятники. Но, в интернете куча виндовых *.txt файлов в cp1251.

Во всех файлах, что попадают ко мне из сети, utf8. Сорри чувак, у тебя какие-то придуманные проблемы.

kirk_johnson ★☆
()
Ответ на: комментарий от cvs-255

У кого как.

> uname
Linux
> echo "$LANG"
ru_RU.KOI8-R

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

Да в линуксе консоль-то давно ненастоящая, эмулируемая.

А где неэмулируемая? FreeBSD'шные sc и vt - точно такие же эмуляторы терминала как и vt в Linux'е. И vt в Linux'е никто не отменял. А вот в FreeBSD новые видеодрайвера затачивают под vt, которая заточена под юникод. Для sc с KOI8-R остаётся только VESA. А в Linux'е можно юзать vt с KOI8-R и свежими видеодрайверами для NVidia/Intel.

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

«НЕНАВИСТЬ ШРИФТЫ ПРЕДАТЕЛЬСТВО!!!»

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

Я вообще думал, что настоящая это телетайп. А они тут меряются у кого эмулятор толще.

bread
()
Ответ на: комментарий от kirk_johnson

Вот не понимаю, почему баттхертит от utf8? Чем кодировка, полностью отображающая unicode, менее предпочтительна чем та, которая отображает лишь малую часть символов unicode?

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

Дада. Я уже понял. Проблема в том, что технических аргументов у тебя нет (потери в памяти и врепемени обработки ничтожны), из чего можно сделать вывод, что это просто хобби такое. Проблема в том, что разработчики софта не очень хотят тратить время на подобные выкрутасы, поэтому поддержка однобайтных уходит в прошлое. И телеграм тому пример.

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

Более простая архитектура (один символ - один байт, один байт - один символ) - вполне аргумент. Для Вас может и нет, а для меня и ряда других людей - да.

Совсем поддержку однобайтных кодировок никогда не выпилят. По крайней мере пока жива UTF-8.

Не всем нужен Телеграм. А разработчики telegram-cli с таким подходом просто теряют часть юзеров.

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

Не забудь про отдельный шрифт для каждой кодировки и возню с iconv, лолка. Простая у него архитектура. Алсо авторам телеграма не очень существенна потеря одного юзера.

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

Я же уже много-много раз сказал, что те люди, которые выбирают KOI8-R, не работают в типографии и не коренные жители Азии. А потому больше 256-ти символов нам и не нужно.

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

Конечно. Но писать софт ради пары маргиналов никто не будет. Поэтому авторы телеграма ссут тебе в рот.

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

Мне просто не нужна UTF-8.

Не ври. Это сообщение написано в UTF-8, так что тебе _нужен_ софт, который способен переводить из/в UTF-8.

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

А разработчики telegram-cli с таким подходом просто теряют часть юзеров.

Всех обоих.

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

Речь шла про локали, а не список поддерживаемых кодировок в iconv'е и т.п. софте.

И с моей стороны оно набрано в KOI8-R. Всё остальное уже технические детали.

Могу переформулировать если уж у вас чешется: мне просто не нужна UTF-8 в качестве локали.

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

Не весь нужный мне софт поддерживает UTF-8, зато весь нужный мне софт поддерживает KOI8-R. А если когда что и дропнется, то всегда можно будет достать с полки версии с поддержкой и пропатчить/написать с нуля. Это же не юникод чтобы по нескольку лет парсеры писать.

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

Всё остальное уже технические детали.

Остальное — это то, что ты пользуешься utf8. Ты не можешь пользоваться только koi8. Никто не может пользоваться только koi8. Абсолютно все пользуются utf8. А вот то, что некоторые поехавшие, по непонятным психически здоровым людям причинам, время от времени переводят текст из пригодной для всего utf8 в непригодную ни для чего koi8 — это уже технические детали.

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

Всё зависит от настроек серверов. Вот на тот же opennet я отправляю сообщения без перекодировки, и никакие UTF-8 в этой связке для этого не нужны.

Если перенастроить ЛОР на KOI8-R, то на него также можно будет отправлять сообщения без перекодировки.

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

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

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

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

А если когда что и дропнется, то всегда можно будет достать с полки версии с поддержкой и пропатчить/написать с нуля.

Это же не юникод чтобы по нескольку лет парсеры писать.

То есть ты согласен переписывать софт, который не умеет koi8-r, вместо того, чтобы перестать страдать и начать использовать utf-8 потому, что ты считаешь, что с koi8-r проще жить? Да, ты поехавший.

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

Какие ещё оправдания? Таким темпами и Вы юзаете KOI8-R, поскольку её поддержку реализуют на уровне glibc'а. И если у Вас установлен glibc, то у Вас установлен и файл usr/lib/x86_64-linux-gnu/gconv/KOI8-R.so.

При этом если проgrep'ать содержимое ещё готовящегося Debian'а 9, то можно найти гораздо больше мин: http://saahriktu.org/deb9koi8.xz

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

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

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

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

С чего бы вдруг его сложнее переписывать, лол? Не пиши на системном языке программирования и все будет хорошо.

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

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

А в том и суть, что по-хорошему всё должно летать на armv6/256-512 Мб RAM. Иначе оно и на более мощных машинах разогревает проц до высоких температур. И это не метафора, особенно если есть проблемы с железом. Тогда при перегреве срабатывает защита, и системник вырубается. На эти грабли легко наступить в иксах если попробовать скомпилировать на проблемном системнике какой-нибудь Chrome или Libre Office.

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

А в том и суть, что по-хорошему всё должно летать на armv6/256-512 Мб RAM.

И чо? emerge там работает без проблем.

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

Купи нормальное охлаждение. У меня ничего не вырубается.

На эти грабли легко наступить в иксах если попробовать скомпилировать на проблемном системнике какой-нибудь Chrome или Libre Office.

Которые написаны на плюсах. Молодец, чо.

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

И чо? emerge там работает без проблем.

Скрипты бывают разных масштабов и сложности. У меня есть игрушка на Python 3/Tk в ~10 Кб, которая на i7-2600K работает более-менее нормально, а на armv6 стартует минуты и надолго задумывается после каждого хода игрока. Вот оно: http://saahriktu.org/downloads/renshuchogyoretsu-v0.3.tar.xz

А вот другая версия той же самой игры на С/ncurses, которая летает на armv6: http://saahriktu.org/downloads/xtgyoretsu-0.2.tar.lzma

Купи нормальное охлаждение.

Достаточно просто не нагружать через меру.

Которые написаны на плюсах.

Мягко говоря, не совсем так. Libre Office не собирается без jdk, и работает через jvm. А в исходниках Chrome куча самых разных 3rd-party библиотек.

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

Сидя в ядерной консоли с кодировкой кои8 тяжело читать документацию в utf8.

redgremlin ★★★★★
()
Ответ на: комментарий от dexpl
> zgrep libreoffice debian-9-Contents-amd64.gz | grep \.jar | wc -l
512
> zgrep libreoffice debian-9-Contents-amd64.gz | grep \.jar | tail -n 10
usr/share/maven-repo/org/libreoffice/jurt/5.2.5/jurt-5.2.5.jar libs/ure
usr/share/maven-repo/org/libreoffice/jurt/debian/jurt-debian.jar libs/ure
usr/share/maven-repo/org/libreoffice/officebean/5.2.5/officebean-5.2.5.jar java/libreoffice-officebean
usr/share/maven-repo/org/libreoffice/officebean/debian/officebean-debian.jar java/libreoffice-officebean
usr/share/maven-repo/org/libreoffice/ridl/5.2.5/ridl-5.2.5.jar libs/ure
usr/share/maven-repo/org/libreoffice/ridl/debian/ridl-debian.jar libs/ure
usr/share/maven-repo/org/libreoffice/unoil/5.2.5/unoil-5.2.5.jar editors/libreoffice-java-common
usr/share/maven-repo/org/libreoffice/unoil/debian/unoil-debian.jar editors/libreoffice-java-common
usr/share/maven-repo/org/libreoffice/unoloader/5.2.5/unoloader-5.2.5.jar libs/ure
usr/share/maven-repo/org/libreoffice/unoloader/debian/unoloader-debian.jar libs/ure
saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

Скрипты бывают разных масштабов и сложности. У меня есть игрушка на Python 3/Tk в ~10 Кб, которая на i7-2600K работает более-менее нормально, а на armv6 стартует минуты и надолго задумывается после каждого хода игрока. Вот оно: http://saahriktu.org/downloads/renshuchogyoretsu-v0.3.tar.xz

Ну поздравляю, ты быдлокодер. К остальным-то это как относится?

Достаточно просто не нагружать через меру.

Бгг. То есть теперь ты вместо покупки нормального охлаждения софт не будешь ставить? Да, ты точно поехавший.

Мягко говоря, не совсем так. Libre Office не собирается без jdk, и работает через jvm.

Чо, правда?

$ file /usr/lib64/libreoffice/program/soffice.bin
/usr/lib64/libreoffice/program/soffice.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, stripped

А в исходниках Chrome куча самых разных 3rd-party библиотек.

На C и С++.

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

Ну поздравляю, ты быдлокодер. К остальным-то это как относится?

А так и относится, что языки высокого уровня многие предпочитают чтобы быстро быдлокодить, чтобы уже никогда не возвращаться к этому коду.

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

Нет, я и так другой софт юзаю.

soffice.bin: ELF 64-bit

И что? Никогда про «гибридный» софт не слышали что-ли? Такой, который линкуется с разными Perl'ами и Python'ами, а в родных исходниках идут неотделимые части модулями соответствующих языков.

Тот же irssi линкуется с библиотекой Perl'а, а у GIMP'а свои Python'овские модули. Вот и у Libre Office также, только вместо Perl'а и Python'а у него Java.

На C и С++.

Но, создающие такой уровень абстракций, который не снился многим интерпретаторам. Потому и могут проявляться аппаратные проблемы, что пока это всё прокомпилируется за один подход...

В общем, речь шла про то, что комбайны - это плохо.

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

А теперь запусти libreoffice'ный autogen.sh и узри --without-java.

И насколько он себя урежет? Почему-то маинтейнеры с этим ключом не собирают.

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

А так и относится, что языки высокого уровня многие предпочитают чтобы быстро быдлокодить, чтобы уже никогда не возвращаться к этому коду.

Я и на C такое видел. И дальше что?

Нет, я и так другой софт юзаю.

Потому что охлаждение лениво поставить? Бгг.

И что? Никогда про «гибридный» софт не слышали что-ли? Такой, который линкуется с разными Perl'ами и Python'ами, а в родных исходниках идут неотделимые части модулями соответствующих языков.

Тот же irssi линкуется с библиотекой Perl'а, а у GIMP'а свои Python'овские модули. Вот и у Libre Office также, только вместо Perl'а и Python'а у него Java.

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

Но, создающие такой уровень абстракций, который не снился многим интерпретаторам. Потому и могут проявляться аппаратные проблемы, что пока это всё прокомпилируется за один подход...

Кто сказал Linux Kernel?

В общем, речь шла про то, что комбайны - это плохо.

В общем, у тебя делириум. Проспись уже, серьезно.

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

Конечно, быдлокодить можно на любом языке. Только на Си многим быдлокодить ленивее. А потому наибольшая часть софта на Си неплохого качества.

Потому что охлаждение лениво поставить?

Нет, потому что я его юзаю ещё с i486/12 Мб RAM.

Я только что его запустил и не вижу никакой jvm.

Ну, допустим, на Java там только расширения. Ну так расширения-то, которые являются частью Libre Office, всё равно работают через jvm. Но, это только то, что касается jvm.

А в целом я не случайно говорил именно про этап компиляции. На этом этапе происходит перекладывание всех компонентов. И сборка 512-ти jar файлов выжирает немало ресурсов. Потому, что интерпретаторы и виртуальные машины тормознее чем нативный код.

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

Конечно, быдлокодить можно на любом языке. Только на Си многим быдлокодить ленивее. А потому наибольшая часть софта на Си неплохого качества.

Хохот в зале, плавно переходящий в истерику.

Нет, потому что я его юзаю ещё с i486/12 Мб RAM.

Вылезай из криокамеры.

Ну, допустим, на Java там только расширения. Ну так расширения-то, которые являются частью Libre Office, всё равно работают через jvm. Но, это только то, что касается jvm.

А в целом я не случайно говорил именно про этап компиляции. На этом этапе происходит перекладывание всех компонентов. И сборка 512-ти jar файлов выжирает немало ресурсов. Потому, что интерпретаторы и виртуальные машины тормознее чем нативный код.

Ну если пользоваться i486 то конечно.

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

И насколько он себя урежет?

Не знаю, да и причем тут это в контексте утверждения о необходимости jvm для сборки и работы LibreOffice?

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

Ну, в слакбилде Libre Office на slackbuilds.org jdk прописан в обязательных зависимостях. В бинарных дистрибутивах оно тоже собрано не без jdk. В этом контексте говорить о том, что jdk/jvm для него не нужны можно только при наличии соответствующего опыта сборки, которого у меня нет.

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

Этот софт работает и на более шустрых машинах, и при этом может молотить гораздо больше чем жирный софт.

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

Этот софт работает и на более шустрых машинах, и при этом может молотить гораздо больше чем жирный софт.

Ты про lynx? Я могу в lynx посмотреть на котика, который есть блинчики, зайдя на YouTube?

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

Я про cli/tui софт вообще. Можно через связку lynx + youtube-dl + mplayer/mpv, и это и есть Unixway.

Упоролся, наркоманище? Ты ещё предложи через ed и cat программировать.

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

ed - вполне удобный текстовый редактор, и как раз входит в число моих любимых наряду с vim'ом. И не только у меня. Не так давно его обсуждали: Вышел ed 1.14 .

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

ed - вполне удобный текстовый редактор, и как раз входит в число моих любимых наряду с vim'ом. И не только у меня. Не так давно его обсуждали: Вышел ed 1.14 .

Я могу сделать автодополнение или прикрутить к нему cscope? Нет? Значит в этом нельзя программировать.

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

Кому как. Не всем нужны автодополнение и cscope.

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

те люди, которые выбирают KOI8-R, не работают в типографии и не коренные жители Азии

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

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

Почему-то маинтейнеры с этим ключом не собирают.

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

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

В этом контексте говорить о том, что jdk/jvm для него не нужны можно только при наличии соответствующего опыта сборки, которого у меня нет.

Для обратных утверждений нужен ровно такой же опыт, но его отсутствие тебя не остановило. Более того, ты заявил, что для работы LO нужна jvm, хотя достаточно запустить тот же LO Writer и посмотреть список процессов, чтобы убедиться, что это не так.

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

Нет, это Вы прёте против паровоза маинтейнеров, которые включают jdk в список сборочных зависимостей. А я, повторяю, говорил в первую именно про сборку, а во вторую про работу собранных *.jar файлов, которые являются частью LO, в jvm.

saahriktu ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.