Brian Kernighan добавляет в AWK поддержку Unicode

Это респект, даёшь матчинг по иероглифам

Што? В AWK не было поддержки Юникода? Да ладно!

А Дедушка таки молодец.

Дедушка в 80 лет хочет разобраться с Git и GitHub, чтобы сформировать Pull Request с добавлением поддержки Unicode в тот самый AWK.

Гвозди бы делать из этих людей!

Plan9 был таки после Unix™️.

Юникод рулит!

Юникод рулит!

saahriktu

Тебя выгнали из клуба любителей однобайтных кодировок?

https://en.wikipedia.org/wiki/Character_arc

Кто-нибудь скорее объясните дедушке про Perl!

Тебя выгнали из клуба любителей однобайтных кодировок?

Вы проспали последние 5 лет.

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

С 2017-го года я пишу на ЛОР про линуксы с иксами, а теперь и с Wayland'ом.

Дед видимо перебрал с колёсами.

Брайан Керниган осилил Сишечку и 10% Плюсиков, но не смог разобраться с Гитхабом? Хорошая иллюстрация того, что человек очень узкоспециализированное существо даже в рамках своей области деятельности.

Я посмотрю, какая у тебя будет специализация в 80 лет, сможешь ли ты разобраться с вращающейся дверью.

Надеюсь, что доживу и разберусь. И тебе того же желаю.

git просто-напросто является лишней сущностью для тех, кто привычен к тому, что софт распространяется тарболами.

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

Это как, например, юзер собирает себе софт rpmbuild'ом и не знает бед. А потом выясняется, что существуют ещё mock, ABF и hasher, которые собирают пакеты в chroot'е. И там тоже свои атмосферы, нужно понимать как это всё работает. При этом юзкейсы у сборки пакетов в chroot'е весьма специфичны. Это либо обрубание лишних зависимостей, либо сборка в предпочитаемом окружении, которое отличается от имеющегося на машине у юзера, либо воспроизводимая сборка. Так и с git'ом. Да, он упрощает совместную разработку, но если разработчик один, то ему ещё нужно вычислять какие конкретные профиты ему даёт git помимо того, что где-то он просто обязателен.

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

Попробуй фреймбуффер, там всё работает.

Во FreeBSD vt (вместо старого sc) теперь по умолчанию, и проблем с "квадратиками" уже давно нет, хотя у меня в системе достаточно расширенной латиницы (польский, немецкий, французский) в именах файлов, и если бы проблемы были, я бы это точно заметил.

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

Не знаю что там за шрифты во FreeBSD, надо уточнять, но в линуксовой ядерной консоли используются растровые PSF шрифты.

Я шрифты себе из Terminus собирал для Linux (psf), продолжаю собирать для FreeBSD (vtfnt). С дефолтными шрифтами у меня так же как и у тебя. И в serial console тоже.

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

Ты точно что-то делаешь не так, потому что у меня в Linux в tty таких проблем не было. Если хочешь разобраться — создай тред и кастани меня, я тебе из бэкапа свои шрифты вытащу и примеров накидаю.

И все символы, которых нет в шрифте, отображаются квадратиками.

Это везде так. Не только в tty, и даже не только в Linux, и даже не только в UNIX-like.

Я шрифты себе из Terminus собирал для Linux (psf)

Я про Terminus и говорю.

Ты точно что-то делаешь не так, потому что у меня в Linux в tty таких проблем не было.

Гм. Ну, возможно, что-то в моём шрифте оказалось урезано.

Это везде так. Не только в tty, и даже не только в Linux, и даже не только в UNIX-like.

Это да. Только в векторных шрифтах глифов гораздо больше. Плюс в графической среде в квадратики ещё и код отсутствующего глифа вписывается. А в ядерной консоли все квадратики одинаковые.

Есть ещё расширение на шрифты с 512 символами, в том числе в ядерной консоли, но это не особо помогает.

Да, в юникоде тысячи символов, а в ядре PSF шрифт ограничен 64-мя килобайтами. При том, что приемлемый для меня размер глифа - 16x30 пикселей, не меньше. Поэтому особой разницы тут, да, не будет. Потому я и топил за KOI8-R, тем более что был к ней привычен со времён когда я начал юзать линуксы. В мануалах тех времён описывали настройку конкретно KOI8-R.

но если разработчик один, то ему ещё нужно вычислять какие конкретные профиты ему даёт git

Нет, не нужно. Нормальные разработчики пользуются VCS в проектах более 20 лет, даже если они пишут код в одно лицо.

Нормальные разработчики пользуются VCS в проектах более 20 лет, даже если они пишут код в одно лицо.

На Хабре пишут что для некоторых из них знакомство с VCS началось с книги Kernighan :)

Лично для меня началом знакомства с системами контроля версий послужила два десятка лет назад (теперь уже классическая) книга «Практика программирования» (https://en.wikipedia.org/wiki/The_Practice_of_Programming) Кернигана и Пайка.

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

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

Именно так. Дедушка великий, дедушка разберётся с каким-то там инструментом :)

Я посмотрю, какая у тебя будет специализация в 80 лет, сможешь ли ты разобраться с вращающейся дверью.

Можно с совсем другой стороны посмотреть. Это ж насколько должна быть пустая у человека жизнь, чтобы дожив до 80 лет, по-прежнему зацикливаться на каких-то сраных утилитах. Конём бы они шли.

Дед офигенен :)

Гвозди бы делать из этих людей!

Нахрен нам надо этих гвоздей!

Из людей гвозди делать. Это только Маяковский из людей гвозди делал. На том и сгорел.

Расскажи что такое полная жизнь

дожив до 80 лет, по-прежнему зацикливаться на каких-то сраных утилитах

Возможно, у него всё хорошо. И живёт он не на пенсию в 150-200$.

Поэтому и занимается любимым делом.

Расскажи что такое полная жизнь

Если бы я знал, я бы на лоре не сидел.

Возможно, у него всё хорошо.

Тоже вариант. :)

Любому навыку нужно учиться. Если бы было всё так просто, то не было бы столько гайдов «как сделать пулл-реквест».

Любому навыку нужно учиться. Если бы было всё так просто

Да я понимаю. Git на самом деле жутко переусложнен. Я самостоятельно разобрался с CVS и SVN, я понимал как они работают и делал в них сложные вещи, большие слияния, разрешения конфликтов, все что мне было необходимо в работе. Для этого хватало официальной документации, какой-то переведенной книжки и немногочисленных статей по теме.

Когда появился Git я надеялся, что работать с ним будет еще удобнее чем с SVN. Я думал что отличие будет в распределенности и в полных срезах состояния проекта (в SVN в репу можно было коммитить отдельные файлы, не имея у себя итоговое состояние проекта). Но как же я ошибался. В ступор человека загоняет даже перемещение по истории рабочей директории. Переключишься на исторический коммит - и сразу detached head состояние получаешь. Что за дичь? Человек всего лишь совокупную историю файлов в проекте смотрит. И в каждом действии Git будет какая-то засада. Проблема даже в том, чтобы понять что вообще происходит, перед тем как будешь ремонтировать. А потом надо понять как ремонтировать. Это сжирает кучу времени. И нужно знать кучу тонкостей. Например, всегда держать в голове, что git pull закачивает изменения только для текущей ветки, а переключившись на другую ветку никто не гарантирует что в ней есть актуальные данные. И как-то это сделано неочевидно, и система тебя никак не предупредит, если ты только однозначно ее не заставишь что-то сделать, и только по совокупности реакции поймешь что происходит и что ты там забыл сделать. В общем, какой-то нечеловеческий подход.

Ты собралсо жить вечно молодым... или надеешься не дожить? :)

Да-да!

И это ещё не всё. После того как ты поймёшь как git работает технически, тебе ещё нужно научиться работать с процедурами поверх гита. Pull-реквест – это не фича git, а фича github.

А когда нужно делать git-merge, когда cherry-pick, когда rebase?

В SVN всё куда более однозначно.