Страница пересобрана: 05:00 17.07.2019
[d | an-b-bro-hr-l-m-med-mi-mu-o-ph-r-s-sci-tran-tv-x | vg | au-tr | a-aa-c-fi-jp-rm-tan-to-vn | gf | azu-bg-dn-fr-hau-ls-ma-maid-me-mo-ne-old_o-p-sos-sp-t-w | misc-vnd | stat ]
[Burichan] [Futaba] [Gurochan] - [Архив - Каталог] [Главная]

[Назад]
Ответ
Файл: 1521329421116.png -( KB, 1366x768, 2018-03-18-042825_1366x768_scrot.png)
No.201977  

>>193792

>> No.202001  
Файл: 1521518865828.jpg -( KB, 600x800, 29e0bbead93bda74b9867ecc61d97bb2.jpg)

Изображение слишком большое. Попробуйте файл меньшего размера.

>> No.202068  
Файл: 1521848253285.png -( KB, 1400x1050, Clipboard01.png)

Одна девочка давеча Service Pack 4.

>> No.202083  

>>202001
https://compressor.io

>> No.202084  

>>202068
Полусерьёзный вопрос: телеметрию бэкпортнуть в ХР не забыли?

>> No.202086  
Файл: 1521922654034.jpg -( KB, 1024x768, xp-tan.jpg)

>>202068

>Service Pack 4

Что, таки выпустили? Таки перестала течь и жрать память как не в себя?
Кажись, теперь можно перекатываться с моей 2000.

>> No.202088  

>>202086
Согласно каталогу обновлений микрософт последнее обнавление для XP было Обновление для системы безопасности Windows XP SP3 (KB4025218) от 12.06.2017

>> No.202090  
Файл: 1521940101112.png -( KB, 510x280, Clipboard01.png)

>>202084
Неофициальный пак же.

>>202086

>течь и жрать память как не в себя?

Не знаю, о чём ты. Система ест максимум 150 MB, остальные 1 850 MB едят браузер, антивирус и акробат.

>> No.202091  
Файл: 1521963839307.png -( KB, 413x445, win2k_2.png)

>>202090

>Система ест максимум 150 M

И куда ей столько? Опять эти индусы чего-то накрутили.

>> No.202094  

От железа зависит. Вернее от драйверов к нему. И степени обмазанности самой оси, в том числе официальными заплатками.
Можно конечно на ноутбуке запустить SP1 в VGA режиме с поддержкой одной лишь только сетевухи, но никто окромя линуксоидов такого праздника жизни не оценит.

>> No.202112  
Файл: 1522014675810.jpg -( KB, 1024x1642, 54 - 1024x1642@32 [SIGff81a12aeb6de414ce(...).jpg)

>>202094
В 2018-м это будет очень специфичный круг линуксоидов, о которых в своё время пели Offspring.

>> No.202139  

>>202112
А как песня называется?Я упустил как-то.

>> No.202140  

>>202139
Подозреваю, что имелась в виду Pretty Fly, как самый известный гимн позеров
Хотя Dirty Magic всё равно лучше.

>> No.202177  

>>202140
Разве не "why don't you get a job"? Другие песни для нефанатов как-то не на слуху для меня.

>> No.202180  
Файл: 1522226173781.jpg -( KB, 1024x768, 10 - 1024x768@32 [SIGc5779c9a5490468f002(...).jpg)

>>202140
Да, она. Только там пелось про воннаби: чувак очень старается, но не рубит фишку до конца. Такие предъявы были актуальны пятнадцать лет назад, когда в типовой пеке было 256 метров всего.

>> No.202193  
Файл: 1522242992409.png -( KB, 1920x1080, 2018-03-28-161133_1920x1080_scrot.png)
>> No.202204  
Файл: 1522266198754.png -( KB, 1366x768, 2018-03-29-004258_1366x768_scrot.png)
>> No.202205  
Файл: 1522266335639.png -( KB, 1920x1080, 2018-03-29-004418_1920x1080_scrot.png)
>> No.202550  
Файл: 1524423124505.gif -( KB, 1280x1024, 2018-04-22-223339_1280x1024_scrot.gif)
>> No.203464  
Файл: 1529314925334.webm -( KB, 1920x1080, glava1.webm)
>> No.203471  

>>203464
Музыка хорошая (хотя вообще не самый лучший их альбом — тот же Time куда лучше). Остальное — фуцу~

>> No.203486  
Файл: 1529696770504.jpg -( KB, 4160x3120, P80623-003842.jpg)

キタ━━━(゚∀゚)━━━!!

>> No.203491  

>>203486
А что это за девайс? Отладочная плата какая-то?

>> No.203507  

>>203491
Маршрутизатор.

>> No.203508  

>>203507
Никогда не видел массовых маршрутизаторов с таким процессором. Может, на цисках каких-то и есть, но это-то не циска, судя по OpenWRT.

>> No.204835  
Файл: 1538408791516.png -( KB, 1920x1080, ecd1e07f792bb1dddfa626a43a3c81a1.png)

:3

>> No.204847  
Файл: 1538476692349.png -( KB, 1280x800, Screenshot.png)
>> No.204848  

>>202550
>>204847
Ничего прекраснее в жизни не видел.

>> No.204851  

>>204835
Что это за штука в левом верхнем углу? Индикатор заряда?

>> No.204854  
Файл: 1538515802350.png -( KB, 500x500, Awesome_logo.svg.png)

>>204851
Теги (почти как рабочие столы, только интересней) awesomewm. Обычно они имеют какие-то названия в одно-два слова, а тут просто полосочки мику-цвета. Самая яркая - одна из активных, остальные с окнами, серые без окон (пока).

>> No.205098  
Файл: 1539258954662.png -( KB, 1920x1080, 2018-10-11-164115_1920x1080_scrot.png)

>>202205
До сих пор не могу остановиться, но все-таки за полгода изменений гораздо меньше, чем до этого.

>> No.205101  

>>204835
Зачем тебе знать объём памяти и загрузку ЦП?

>> No.205103  
Файл: 1539308744180.png -( KB, 1920x1080, 7de5476d98bf56c53c90dff8f18c40cb.png)

>>205101
Чтобы знать когда пора стопать докерные контейнеры / куберовые кластеры / лишние хостовые приложеньки чтобы спасти нужный прогон или окружение. Не просто так 32 гига же, порой и их не хватает.

>> No.205107  

>>205103

>когда пора стопать ручками

Компьютер. XXI век. Средства автоматизации.

>докерные контейнеры / куберовые кластеры

Что это такое и зачем оно?

>> No.205108  

>>205107

>Что это такое и зачем оно?

Компьютерные средства автоматизации XXI-го века.

https://kubernetes.io
https://www.docker.com

>> No.205208  
Файл: 1539631558175.png -( KB, 2880x1800, Screenshot 2018-10-16 00.21.11.png)
>> No.205326  

>>205208
Какая милота! Это, как я понимаю, не Хакинтош не думаю, что на хаке можно пользоваться Docker, Dropbox и Firefox? Что за макбук?

>> No.205327  
Файл: 1540325263468.png -( KB, 1920x1080, Снимок экрана_2018-10-23_23-04-56.png)

>>205208
Ох кот бы в мой Latitude такой экран поставил. Ну то есть не такой, 1440p бы на 12 дюймах бы за глаза хватило. Собственно, для приличных шрифтов хватает и 1080p, но GTK3 cannot into fractional scaling.
Остаётся только надеяться, что рано или поздно такие матрицы появятся на 52хх и я её смогу и в свой пересадить — корпуса в пятой серии не меняются годами

>> No.205328  

>>205326
И на хаке должно всё это работать, но он на ноутбуки проблемно накатывается.
Макбук про 2015 15"

>> No.205431  
Файл: 1541476282389.png -( KB, 1920x1200, Снимок экрана_2018-11-06_05-50-06.png)

Темку надо перепиливать, да.

>> No.205432  
Файл: 1541476397298.png -( KB, 1920x1200, Снимок экрана_2018-11-06_05-52-09.png)

Ой, скринфетч забыл.

>> No.205435  
Файл: 1541502303708.png -( KB, 1024x768, Konachan.com%20-%2013999%20tagme.png)

>>205433

>> No.205484  

>>205467

>Total Commander
>AIMP
>Visual Studio

Удали всё это.

>> No.205489  

>>205484
Why?

>> No.205492  

>>205489
Total Commander и AIMP -- проприетарщина. А первый так вообще платный. А для кодинга достаточно текстового редактора.

>> No.205497  

>>205492
В таком случае начинать стоит вооще с ОСи.

>> No.205504  

>>205492
А, вы из этих

>> No.205506  

>>205504
А я сразу сказал, что он из этих, но меня потер модератор.

>> No.205508  

Вам что, правда нравится сидеть на одном сплошном блобе?

>> No.205509  

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

>> No.205512  

>>205492
Впервые вижу, чтобы кодер писал в блокноте. Может этот текстовый редактор еще и запустит программу? А может, модули подключит?

>> No.205513  
Файл: 1542355086173.png -( KB, 810x698, __haskell_tan_and_ruby_tan_original_draw(...).png)

Для кодинга на большинстве языков действительно достаточно текстового редактора. Обычно это правда [n]vim или emacs, но если кто-то нашёл достаточные для себя сердства автоматизации воркфлоу с чем-то ещё, вай нот. В конце концов вся ОС при правильном дизайне и конфигурации может быть IDE.

>> No.205514  
Файл: 1542355826214.jpg -( KB, 500x375, .jpg)

>>205512
Знаю одного парня не будем показывать пальцем мало того что в редакторе пишет, так еще и без подсветки.
И вообще с чего ты взял что редактор не может запустить программу и подключить модули?

>> No.205524  

>>205514
А что, Линус серьезно без подсветки синтаксиса ебошит? Соус инфы?

>> No.205525  

>>205524
Он использует uEmacs, не знаю, может это как-то настраивается, но по умолчанию он вообще ничего не подсвечивает.

> it's a minimalist's text editor with very little eye-candies, such as syntax highlighting and other visual aids.

Ну и в видео где он дома, когда он открывает файлы не видно чтобы там что-то подсвечивалось.

>> No.205529  

>>205514
Что у него за устройство?

>> No.205532  

>>205529
Что-то из серии Sony Vaio C1. Скорее всего PCG-C1XS.

>> No.205547  

>>205467

> Windows

Не понимаю, какой смысл ставить венду, когда есть Linux'ы и OpenBSD.

> ШГ

Comic Sans это моветон.

> Discord

Сборище самзнаешького, для общения есть IRC, Tox и Matrix.

> Visual Studio

Ave Emacs.

>> No.205548  

>>205547

>Сборище самзнаешького

Очень много кого. А ещё можно звать мимокрокодилов в беседу по одной лишь ссылке без всяких регистраций и смс.

>Ave Emacs.

\._.

>> No.205566  
Файл: 1542828196766.jpg -( KB, 1000x707, 151006976359-sg.jpg)

>>205547

>Не понимаю, какой смысл ставить венду, когда есть Linux'ы и OpenBSD.

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

>Ave Emacs.

Но зачем?

>> No.205573  
Файл: 1542856800348.jpg -( KB, 909x1286, 0_af60a_cbc9674a_orig.jpg)

>>205566

>А я не понимаю, какой смысл трахаться с непривычной ОС

ну, например, привычная «ОС может» забодать в корень тупыми попытками обновиться на десяточку, как у меня. Или «привычная» ОС утомила своими глюкодромами. Или «привычная ОС» не настолько привычна, чтобы при сравнении с другими оставаться на ней, а не переходить на более удобную. Или в «привычной ОС» окружение рабочего стола как-то само собой становится GPL-ным, и переход к «непривычной ОС» не вызывает никакого буттхурта. Или, наконец, «привычная ОС» оказывается менее приемлемой по политическим соображениям (лицензии и вот это всё).

>> No.205574  
>Ну

Починка же.

>> No.205576  

>>205573

> ну, например, привычная «ОС может» забодать в корень тупыми попытками обновиться на десяточку, как у меня.

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

>> No.205593  

>>205576
Не очень понятно зачем с осью воевать, когда можно просто пользоваться. Возможно, путь воина баллмера просто не для меня.

>> No.205594  

>>205576
Я мало того, что перелез на линукс, но ещё и остался на нём. И, в общем-то, нормально себя чувствую. Хотя тут могут играть роль конкретные обстоятельства — приверженность актуальным играм (не все выпускают в нативном виде, из оставшихся не все идут под вайном), конкретное железо (двухмерный режим под проприетарными дровами нвидии у соответствующих видеокарт работает плохо, а трёхмерный — хорошо, в то время как под свободными всё наоборот, например).
С другой стороны, в никсах столько возможностей получить именно то, что тебе нужно, что никакая проприетарщина рядом не стояла.

>> No.205597  

>>205594

> С другой стороны, в никсах столько возможностей получить именно то, что тебе нужно

Мне нужен сай. Вот конкретно сай, крита неюзабельна. Могу ли я поставить его на линупс? Инструкция https://www.deviantart.com/polex-p/art/Install-SAI-in-Linux-Russian-language-Manual-430338728 говорит, что могу, но с некоторыми затруднениям. Правда, несколько напрягает количество пунктов.
В винде три пункта:

  1. поставить винду
  2. поставить дрова на планшет
  3. поставить сай. ну или не ставить, использовать портабл

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

>> No.205600  

>>205597

> сейчас

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

> говорит, что могу

Значит, наверное, можешь. Не проверишь не узнаешь.

> Мне нужен сай. Вот конкретно сай

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

>> No.205601  

>>205600

> А когда срок поддержки кончится что будешь делать?

Когда кончится, тогда и буду думать. Может на десятку перекачусь, LTSB.

> что уже само по себе повод задуматься в своём выборе

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

>> No.205602  

>>205600

>Я утёнок.
>> No.205603  

>>205597
Можно Мупаинтом пользоваться (хотя стабилизатор там прикручивается очень больно). Наборы кистей и уроков у того же Ревоя откапывается. А Крита и мне не зашла, инопланетная какая-то.

>> No.205604  
Файл: 1543025077887.png -( KB, 1920x1200, изображение.png)

>>205603
Смотри, как изящно и лаконично выглядит сай. И крита, и мупаинт выглядит тяпляписто. Почему они не могли скопировать что-то виндовское? Фотошоп выглядит строго и лаконично, цсп выглядит как закос под фотошоп. А крита с мупаинтом как детские рисовалки.

>> No.205606  
Файл: 1543032250170.png -( KB, 1006x867, azpainterb.png)

>>205601
Кстати, кто хорошо знает Сай, что скажете про это
http://azsky2.html.xdomain.jp/linux/azpainterb.html

Для бубунт есть в ppa:dhor/myway

>> No.205607  

>>205604
Исходники открыты. Просто берешь и делаешь какой хочешь интерфейс.

>> No.205609  

>>205607
Классика.

>> No.205616  
Файл: 1543073470521.png -( KB, 1920x1080, Screenshot_2018-11-24_17-24-15.png)
>> No.205622  
Файл: 1543083898840.png -( KB, 1366x768, Снимок экрана_2018-11-24_21-14-26.png)

>>205602
Очень аргументированно. И этот вывод сделан на основании?...
>>205601

> Сай - стандарт

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

> Крита просто ублюдство и желания углубляться не вызывает.

Ты так и не ответил какие у тебя с ней проблемы. Мне правда интересно.
>>205603
>>205604
Ребят, мы точно об одной и той же Крите? С Гимпом, или ещё чем её не путаете?

>> No.205623  

>>205622
У нее даже треугольник вместо квадрата.

>> No.205624  
Файл: 1543093746906.png -( KB, 1324x612, Screenshot 2018-11-25 02.08.09.png)

>>205623

>> No.205718  

>>205616
Кеды с i3... Довольно специфично, но интересно. И какие ощущения при использовании i3?

>> No.205857  
Файл: 1544102972440.png -( KB, 1600x1200, 2018-12-06-162729_1600x1200_scrot.png)

>>201977

>> No.205860  

>>205857
А что такого запаковано только во Flatpak, чего нет в Nixpkgs?

Nix lang очень странный?

>> No.206006  
Файл: 1544779114949.jpg -( KB, 600x553, r.jpeg)

>>205622

> принципиального есть в Сай чего нет в других редакторах

Маркетинговая политика?

>> No.206009  
Файл: 1544787672862.jpg -( KB, 896x768, Smug-7.jpg)

>>206006
Маркетинговая политика, заключающаяся в довольных пользователях, которые сами рекламируют продукт? Я думаю, нужно больше такого.

>> No.206010  

>>206009

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

Linux

>> No.206011  

>>206010
Больше похоже на сектантскую пропаганду..

>> No.206015  

>>205857

>Intel Core 2 Duo E7500 @ 2.926GHz
>KDE Plasma 5

Kicker и рабочитй стол не падают? Анимация не дёргается?

>> No.206016  
Файл: 1544801607654.png -( KB, 1920x978, 2018-12-14-148957489.png)
>С Гимпом, или ещё чем её не путаете?

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

>А я не понимаю, какой смысл трахаться с непривычной ОС, если она тебе не нужна. Способов потратить время и силы я и без этого могу найти много.

Вот, покуда не появилось интересной локальной задачи проще реализуемой под линуксами именно они сидели в виртуальной машине на правах полигона локальной обкатки перед внесением изменений в 'боевую' вдс хобби-проекта. Последние лет пять наоборот уже винда сидит в qemu для запуска несколько раз в год :)
Плюс MS из шкуры вон полезла мой этот самый воркфлоу раздербанивать делением на ноль привычного интерфейса с предсказуемым поведением в целом. Смотрю на сверхумную дисяточку и назад без еще более существенной причины желания вернуться не возникнет.

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

А если внезапно пригорит сагитировать третье лицо на мои болота, начну с тщательной обмозговки как интересное данному персонажу можно делать лучше, быстрее да удобнее чем текущим его инструментарием. Кропотливо и неинтересно без хорошего куша, согласитесь.

>> No.206038  

>>206006

> кроме несовместимости с более чем половиной существующих ОС, закрытости, и платности

>>206016

> вполне адекватная замазывалка красных глаз

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

>> No.206053  

>>206016
Это суйка?

>> No.206057  

>>206053
Вроде бы никаких арбузиков на картинке, только один атомный цыплёнок о трёх ногах.

>> No.206504  

>>205718
Замечательные ощущения, ведь я получаю лучшее от двух:
От i3 получаю функциональные хоткеи и менеджмент окон/воркспейсов. Всё, что я использую (хоткеи на перемещение, открытие-закрытие и изменение размеров окон; перемещение между воркспейсами; открытие нужного приложения в нужном окне; медиа кнопки) - работает без нареканий абсолютно так же, как и в i3 без кед.
От кед получаю верхний бар, графические настройки (которые ещё и работают и меняют), красивый экран бута/блокировки.

Думаю вот на KDE Neon переползать как-то, как время будет, ведь без бубна предоставляется максимум 5.12.7 LTS версия кед, но при этом не хочу обновляться на 18.10 убунты, а хочу .04. И в принципе neon удовлетворяет всем потребностям, надо только время
переехать и понастраивать-попереносить всё :3

>> No.206507  
Файл: 1547440776040.png -( KB, 3840x2160, Screenshot_2019-01-14_07-27-25.png)

>>201977
Доброе утро! А у меня вот не так много чего за два года изменилось.

>> No.206508  
Файл: 1547471944762.jpg -( KB, 1280x800, Yamada over keyboard.jpg)

>>206504
Не надо кед, они то ещё добро.
Пользуй крысу, крыса хорошая.
c:hi

>> No.206515  

>>206507
Оно у тебя на твоем любимом неназывачике доброе. Иди, откуда пришел.

>> No.206520  

>>206507
Ты же не тот самый Fox`y? Ноутбук какой-то странный, разве T25 были с 8650U и 4K?

>> No.206522  

>>206515
Нет ты. И свои нелепые, неудачные попытки по одному посту со скриншотом определить, какие форумы я ещё посещаю, тоже с собой забери.

>>206520

> Ты же не тот самый Fox`y?

Нет, это не я, хотя и знаю, о ком ты говоришь.

> Ноутбук какой-то странный, разве T25 были с 8650U и 4K?

В этом Т25 стоит материнка от Т480, поэтому 8650U. Ну и UHD матрицу можно поставить, коннекторы-то одинаковые, пропускной способности хватает, да и матрицы по размеру плюс-минус подходят.

>> No.206533  

>>206522

> В этом Т25 стоит материнка от Т480, поэтому 8650U.

А почему T25 был раздербанен с заменой материнки?

> Ну и UHD матрицу можно поставить, коннекторы-то одинаковые

Шлейф наверное пришлось ставить 40-40 pin вместо 40-30 pin?

>> No.206535  

>>206533

> А почему T25 был раздербанен с заменой материнки?

Мне захотелось 4-ядерный процессор и матрицу большего разрешения. Т25 имеет 2 ядра и максимальное поддерживаемое разрешение — FHD.

> Шлейф наверное пришлось ставить 40-40 pin вместо 40-30 pin?

У Т25 коннектор 30-пиновый. И можно либо 30-30 для обычных матриц, либо 30-40 для FHD с тачскрином (именно такая и используется в нём, что являлось ещё одной причиной для замены матрицы). Каким образом из 30 на материнке делалось 40, я не представляю, но точно помню, что там 30.
А вот в Т480 коннектор 50-пиновый. И для QHD (и UHD) нужен коннектор 50-40.

>> No.206536  

>>206535
Хм, насколько я понял, T480 были максимум с QHD, матрица получается сторонняя?

>> No.206537  

>>206536
Верно. Вообще, сначала была идея именно QHD ставить, но было немного страшно таким без масштабирования пользоваться, а GNU/Linux не очень хорошо с дробным масштабированием работает (речь идёт о GTK 3). А потом оказалось, что существуют UHD матрицы, которые во всём лучше: лучше цветовой охват, выше яркость, и на них можно использовать целочисленное масштабирование. У меня не было, правда, уверенности, что они будут работать, поэтому пришлось рискнуть и попробовать. И мне повезло, всё работает просто замечательно.

>> No.206538  

>>206537
Да, тебе повезло. Мог пролететь с креплениями матрицы (нередко бывает, что у FullHD уши расположены так, а у UHD - по-другому), с шириной коннектора и собственно его распиновкой (такое бывает со всякими тач-версиями). ИМХО безопаснее было бы продать T25 (или оставить) и купить сразу ноутбук с 4К, но раз всё закончилось благополучно - то и ладно. А матплата T480 уже была в наличии?

>> No.206540  

>>206538
С креплениями как раз проблема была, пришлось самостоятельно их делать, впрочем, об этом мне было понятно ещё при покупке матрицы.
С коннектором всё тоже просто. eDP стандартизирован, и с ним не бывает проблем с распиновкой. Разве что может быть такое, как, например, 2 канала + тач скрин — 40 пинов, или 4 канала без тача — и тоже 40 пинов, но это легко предусмотреть заранее: матрица требует 4 канала, и кабель рассчитан на QHD, т.е. даёт 4 канала. Если бы кабель был рассчитан на QHD с тачем, то пинов было бы 50, и тогда сразу было бы ясно, что кабель не подходящий. Проблема, скорее, могла быть с ПО или с искусственным ограничением разрешения, что предусмотреть было никак нельзя, учитывая то, что в интернете не было упоминания случаев успешной установки UHD в Т480.

> ИМХО безопаснее было бы продать T25 (или оставить) и купить сразу ноутбук с 4К, но раз всё закончилось благополучно - то и ладно. А матплата T480 уже была в наличии?

Мне не нравится клавиатура в современных ThinkPad, кроме как Т25 (который, собственно, только клавиатурой от них и отличается). И смысл как раз и был в том, чтобы, сохранив корпус и клавиатуру Т25, получить производительность Т480 с возможностью ставить действительно хорошие матрицы.

>> No.206544  

>>206522
Тебя и определять не надо, и так известно, кто ты.

>> No.206545  

>>206540
Бывают коннекторы с разным интервалом между пинами. Это всё конечно гуглится на panelook, но по незнанию можно влететь.

И во сколько это всё обошлось, если не секрет?

>> No.206546  

>>206544
Продолжай. Интересно даже послушать, ведь ты, кажется, знаешь про меня даже больше, чем я, раз подобные удивительные заявления делаешь.

>>206545
Насколько я знаю, у eDP всегда используется обычный LVDS коннектор без подобных сюрпризов. Но могу ошибаться.

> И во сколько это всё обошлось, если не секрет?

Мне немного неловко (в неприятном смысле) говорить об этом, всё-таки это, разумеется, было не очень дёшево.

>> No.206549  

>>206508
Есть ли какие-то реальные аргументы в пользу крысы?

>>206507
Выглядит, будто i3-gaps или что-то похожее, но стоит дефолтный xfwm. И панелька совсем другая.
А я вот сколько не искал путей сделать крысу с i3 красивыми (а до кед было так), ничего не вышло.

>> No.206550  

>>206549
Да, это просто xfce с xfwm. А окошки так можно и руками поставить, чтобы скриншот опрятный сделать и выложить на иичан, угу.

>> No.206556  

>>205492

>А для кодинга достаточно текстового редактора.

Для ковбойских фиксов на сервере в мелкоборды, разве что. Или лаб в универе.
Денег за такую работу не дадут, и в опенсурсе коммиты не оценят.

>> No.206559  

>>206556
Ну так-то да, для разосратого проекта напичканного моднейшими баззвордами без других моднейших баззвордов никак.

>> No.206565  

Текстовый редактор понятие растяжимое тащемта. Может он имел ввиду что-то вроде emacs, из него с раширениями практически IDE лепится для кучки языков.

>> No.206566  

>>206559
А Линукс или фрибсд - достаточно разосратые проекты с модными баззвордами?
К текстовому редактору для работы с ними ещё нужны: компилятор, линкер, make/cmake/autoconf, пакетный менеджер для установки сторонних библиотек, система контроля версий, в случае Гита ещё умение работать с конкретной реализацией сервера и ее багами/системы для код ревью/процедурой рассмотрения патчей в списке рассылки.
Конкретно к текстовому редактору даже в самом примитивном случае нужен поиск экспортированных символов по остальным единицам трансляции, не грепать же руками сотни мегабайт исходников на каждую функцию.
И перечисленное - это минимум. Не то, чтобы мне попытка все перечисленное ужать в одну монструозную IDE нравилась, но "достаточно текстового редактора" - это какой-то терминальный юношеский максимализм, достаточно его только для правки отдельно стоящих скриптов для сборки на баше и подобной мелкой одноразовой работы. Любая разработка даже если и ведётся в виме, то с плотной кастомизацией, хотя бы с подсветкой синтаксиса с учётом стайлгайдов и индекс вроде cscope для вима. И применяют вим как раз таки на особо разжиревших проектах вроде последнего андроида - цельный билд на куче языков сразу весом 100+Гб ни одна IDE полноценно не проиндексирует и на лету корректность правок не проверит, а сегментировать рабочий участок кода не всегда возможно.
Под что-то в десяток мегабайт кода и меньше же не применять хотя бы vs code или заточенную под язык ide - идиотизм.

>> No.206616  

>>206566

>К текстовому редактору для работы с ними ещё нужны: компилятор, линкер, make/cmake/autoconf

Это нужно.

>пакетный менеджер для установки сторонних библиотек, система контроля версий

Это, строго говоря, не нужно.
а) Пакетный менеджер, строго говоря, не нужен
б) Система контроля версий нужна, когда она нужна, а не когда ей пользуются разрабы. Если вопрос стоит в шаринге кода, то пацаны, может, и покривят носом от твоего diff -Nur, но вряд ли это приведет к таким уж проблемам. Если вопрос стоит в администрировании кодовой базы, то, строго говоря, это не нужно, лол. Ну, для непосредственно программирования.

>Конкретно к текстовому редактору даже в самом примитивном случае нужен поиск экспортированных символов по остальным единицам трансляции

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

>это какой-то терминальный юношеский максимализм

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

>идиотизм

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

мимокрок

>> No.206712  

>>206549

> Есть ли какие-то реальные аргументы в пользу крысы?

Там все модульное. Т. е. не "модульное", как в КДЕ или Гнуме-3, где установка текстового редактора тянет за собой еще от 400 до 700 мбайт "модульных" зависимостей. Меньше кода - меньше багов.

>> No.206714  

>>206616

>а) Пакетный менеджер, строго говоря, не нужен

Разруливать зависимости с библиотеками и поставлять их понадобится в любом случае. Будет вместо шаренных библиотек + хедеров pip, cargo, или встроенная в .net иерархия классов не принципиально, в любой задаче сложнее хеллоуворлда этим придется пользоваться и взаимодействовать с другими приложениями, железом или сетевыми ресурсами по их апи. Сферически-вакуумный ЯП столь же вакуумно-бесполезен.

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

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

>Не вполне понял, о чем ты,

В одном файле вызывается функция из другого. Греп кроме декларации вывалит прототип из хедера, все вызовы функции, и кучу мусора с более длинным именованием, либо при более точной реулярке рискует что-то пропустить в зависимости от разности в кодстайле, например, есть или нет пробела между именем функции и скобками. А ещё он покажет все неэкспортируемые одноименные функции/переменные/классы.
В итоге в случае ядра линукса получаем пару минут на греп по названию, от двух (определение как макрос в хедере и применение) до тысяч вхождений, и отвлекание на поиск среди них нужной декларации, против секунды в эклипсе. Грепать конечно тоже нужно уметь, например, когда правится что-то на стыке сишных и ассемблерных исходников, или расставляются директивы препроцессора системой сборки, но непосредственно с кодом работать без инструментов просто непродуктивно.

>Если этот список слишком большой по множеству файлов, то он доставит сопоставимые сложности по обработке вне зависимости от того, чем ты будешь искать, нет?

Эклипс с правильно настроенным подмножеством языка на ноутбуке с 8 Гб памяти 500 мб исходников на С индексирует полностью, мгновенно переходя по цепочкам вызовов и разворачивая макросы. Более крупное на одном языке не попадалось, по разнородному билду вроде андроида таки да, грепать, или открывать отдельные директории в vs code.

> но для написания кода "достаточно текстового редактора", хихи.

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

>Аскет может сказать, что идиотизм - писать чрезмерно сложные проекты, в которых без специнструмента ногу сломишь.

Сказать-то он может, а пост отправлять все равно придется через чрезмерно сложный HTTP/2, с написанного с использованием системы контроля версий и слинкованным с libc/bionic/winapi браузером или, о ужас, мобильного клиента на джаве, на операционной системе, с ядром разрабатываемом в гите или svn.
TUI зародился не от религиозного аскетизма, а из прагматичной экономии на устройствах вывода и возможности применять серийные относительно дешёвые телетайпы и заставить юзера работать самого вместо специально обученных набивщиц перфокарт. Никто не предполагал что в 90х компьютер будет автономным полноценным устройством с GUI, в нулевых станет заменителем всего медиаконтента, а в 2010х пойдет на закат с размазыванием функций управления и обработки данных на отдельные встраиваемые компьютеры с соединением в сеть. Почему средства разработки не должны эволюционировать вслед за решаемыми ими задачами?
А поклонение внешней стороне частного решения во имя "трушности" ни к чему не ведёт, это заканчивается как поклонение матану до середины прошлого века: появился алгоритм Риша - и умение брать интегралы с полезного умения превратилось в способ бесцельно прожечь время на невостребованные навыки образца середины 19го века и привить отвращение к актуальным знаниям для большинства.

>> No.206715  

>>206714

>Разруливать зависимости с библиотеками и поставлять их понадобится в любом случае.

Не понадобится, если линковать статически, лол.
На тему модулей скриптов - ок, уел, но это опять же для удобства, так-то их можно и ручками покидать или написать СКРИПТ (инбифо скрипт уровня пакетного менеджера).

>Греп кроме декларации вывалит прототип из хедера

Если ты ищешь тело функции, то оно будет в *.c файле, и при некоторой удаче, в довольно предсказуемом файле по названию. Можно сначала найти все файлы с упоминанием функции, затем найти саму функцию.

>А ещё он покажет все неэкспортируемые одноименные функции/переменные/классы.

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

>В итоге в случае ядра линукса получаем пару минут на греп по названию, от двух (определение как макрос в хедере и применение) до тысяч вхождений, и отвлекание на поиск среди них нужной декларации, против секунды в эклипсе.

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

>Для написания кода достаточно доски и маркеров, или бумаги с ручкой. Что собственно нередко и проверяется при приеме на работу.

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

>> No.206716  
>А для того чтобы код что-то делал, он должен быть интегрирован с уже существующим, в самом максимально сном случае хотя бы начиная с системы команд процессора которую не ты придумал.

Интеграция кода и написание кода - разные стадии, нет?
А то так нам конечно надо скомпилировать код (по факту, сказать машине переписать его в другой вид), слинковать код (уложить его в определенные структуры данных в условно файле), далее, возможно, включить код в какие-то иные объектные файлы (скажем, пресловутый shared object), для которых нам надо составить целую инфраструктуру динамического загрущщика, которую уж подавно не мы придумали и шатать не будем без особой необходимости, ибо мы какбе хотим переносимость, чтобы "код что-то делал", лол.
Но все же это не относится к написанию кода. Можно отнести это к "программированию" в целом, конечно.

>придется через чрезмерно сложный HTTP/2

Не придется, лол. Кстати, я так и не понял, в чем выигрыш, а Poul-Henning Kamp так вообще говорит, что это провал.
https://queue.acm.org/detail.cfm?id=2716278

>с написанного с использованием системы контроля версий и слинкованным с libc/bionic/winapi браузером

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

>с ядром разрабатываемом в гите или svn

Количество регрессий в коде линукса перевалило для меня комфортный порог. В смысле, лично меня беспокоят баги, над которыми чешут репу девы уже не первый год. Конечно, наивно связывать это с наличием/отсутствием git, оно скорее помогает найти коммит, вносящий регрессию. Но то, что в линуксе за 10кк строк кода (или сколько там уже) явно не помогает ситуации.

>TUI зародился не от религиозного аскетизма, а из прагматичной экономии

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

>Почему средства разработки не должны эволюционировать вслед за решаемыми ими задачами?

Потому что задача "написания кода" не особо поменялась, например.
Но вообще, речь скорее о целесообразности того или иного нововведения, чем о том, интегрировать ли индексацию поиска в ide или нет.
Скажем, удобный поиск для греп можно зделать, внося определенные требования к структуре проекта (например, оформлять каждую функцию в отдельном файле). Конечно, ide будет более универсальной, но это просто как пример того, как можно подходить к вопросу.
Можно возразить, что кому-то, мол, надо работать, и работать с тем, что уже есть, и, ну, примерно это я имел в виду, говоря о "смене профессии". Не то, чтобы деятельность по поиску в 500 Мб кода была прям настолько кошмарной, но на мой взгляд, сама необходимость сего понижает продуктивность каждого вовлеченного в процэсс. А еще бывает, что один программист уходит с работы, где он годами поддерживал кодовую базу, и на его место приходит другой, совершенно с ней незнакомый, а база большая, багованная, криво написана, да и вообще для работы с ней ее по-любому надо знать. Развлечение на месяцы, если не на пару лет. Продуктивно? Нет. Инструменты помогут? Да, но минимально. Пример надуманный? Нет, и можно накидать еще большИх кодовых баз, в которых проблемы чинятся месяцами, попутно внося новые (mozilla firefox, лол). Скажешь, ошибаться нормально? Соглашусь, но когда цена ошибки становится настолько высокой, у миня прям стресс.

>> No.206717  

Главная заслуга http/2 то что он 2, дело сдвинулось с мертвой точки и будет http/3. Главная заслуга http/3 - udp 443. Теперь впнки будет проще прятать. UDP TLS, вкусно. Сейчас понастоящему качественно спрятаться под http tls от dpi можно только по tcp - субоптимально.

А вплане их прямого назначения, класть с прибором, 1.1 хватало.

>> No.206720  

>>206715

>Не понадобится, если линковать статически, лол.

Это только перенесет проблему управления зависимостями со времени выполнения на время компиляции, создав разработчику лишнюю нагрузку на сборку всего зоопарка библиотек, каждый со своей билд-системой. Подходящее решение для хипстерского стартапа с десятком микросервисов на го и надобностью максимально быстро их навелосипедить и сэкономить на деплое, или тяжёлого проприетарного приложения стоящего дороже компьютера на котором оно используется, но неприменимое для системной инфраструктуры.
Хеллоуворлд с динамическим glibc имеет размер порядка 25кБ, приложения из coreutils и прочие системные утилиты побольше, до сотен килобайт. Если в каждое влинковать glibc, каждое вырастет на +1МБ, и +2...+5МБ если перевести их на go или lazarus, а ведь многие системные приложения используют и другие библиотеки. В итоге получится распухание на порядок-два без особых преимуществ. Скорость запуска бинарей тоже в таком идеальном статическом мире будет в разы ниже, systemd при каждом старте нового демона вызовом fork() будет создавать свою полную копию, в десятки раз распухшую. Да, с оптимизацией вроде CoW, но удаление даже указателей на старые страницы общим весом ~100МБ при вызове execve() занимает время.
Придется ломать все дальше, отказываться вообще от юникс-вея и переходить на бизибокс-подобные монолитные комбайны, либо отказываться от раздельной компиляции и делать языки и компиляторы с полным знанием всей цепочки вызовов, заплатив за это кубическим вместо квадратичного ростом потребляемой компилятором памяти на количество деклараций и сделав сборку того же ядра просто недоступной простым смертным.

> Можно сначала найти все файлы с упоминанием функции, затем найти саму функцию.

Какой-нибудь read будет найден в большом количестве файлов, и придется отвлекаться от основной задачи на этот поиск.

>Я не понимаю, что значит "неэкспортируемые" в этом контексте.

Применительно к С, локальные переменные, статические переменные, члены структур и перечислений, и объявленные как static функции и глобальные переменные.
Две последних категории в том же ядре встречаются повсеместно.

> В смысле, при копании в исходниках ядра я не находил такой уж проблемой невозможность почти мгновенно пройти по цепочке вызовов.

Это не проблема, это в разы замедляет работу без каких-то преимуществ и отвлекает от предметной области, вроде поиска момента глушения "неиспользуемых" таймеров которыми одновременно пользуется резидентная ось на другом ядре в невиртуализированной системе. Только запуск двух линуксов на двух ядрах без гипервизора задача интересная и оплачиваемая, борьба с инструментарием - нет.

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

Это работает разве что для шелла, потому что компилятор + библиотеки для серьезных языков нужно ещё установить, а часто ещё и явно указать компилятору с чем линковать получаемый бинарник. А если устанавливать все скопом в некоем достаточном для большинства задач наборе вроде .net или pip, то зачем внезапно останавливаться и ударяться в минимализм?

>> No.206745  

>>206720

>Это только перенесет проблему управления зависимостями со времени выполнения на время компиляции, создав разработчику лишнюю нагрузку на сборку всего зоопарка библиотек, каждый со своей билд-системой

Э?
Да, перенесет, но в идеале (развернутая система) разраб просто вместо одной линковки использует другую.
Если разработчику нужны разные версии либ одновременно, то у него что так, что эдак проблемы, только статические бинари будут работать вне зависимости от присутствия/отсутствия нужных либ.

>Если в каждое влинковать glibc

Glibc можно влинковать статически? То есть, бинарники будут без зависимости от ldlinux и libc? Вроде как оно было сломано тыщу лет назад еще. Хинт: glibc для этой цели вообще не стоит использовать.
При статической линковке в целевой бинарник встраиваются только нужные функции. А если нет, то надо заставить линкер сделать это. Хотя в целом бинари распухнут от статической линковки, я бы не стал говорить, что прям "на порядки", особенно в случаях, когда бинари очень простые.

>Скорость запуска бинарей тоже в таком идеальном статическом мире будет в разы ниже

Не знаю, надо мерить.
По идее, тяжолое динамически слинкованное приложение либо тупо содержит мало shared кода (то есть выигрыш от .so минимален), либо вызывает чертов каскад вызовов ld-linux, который будет рекурсивно подгружать все требуемые либы. И даже если она подгружена, время на многократные дерги будет заметно. Вопрос встает так: в эпоху активного использования кэша памяти, так ли нужна инфраструктура dll в современной десктопной/серверной ОС? Как бы да, есть выигрыш от избавления от требования перекомпилять все зависимое при изменении корневых зависимостей, вроде libc, но сама зависимость никуда не девается, и всем потом с ней жить.
Полагаю, архитяжелые приложения с холодного старта тормозят почти одинаково, а с горячего статика может быть даже чуть быстрее.
Средне-тяжелые же покажут похожее поведение до того момента, как степень зашаренности не станет настолько высока, что почти вся система уже в памяти де-факто.
Что же до использования памяти, то, полагаю, заметно повышенное использование памяти приложениями будет только если запускать множество копий относительно тяжелого процесса для каких-то целей.
Вообще, о достоинствах и недостатках динамической линковки написано хотя бы здесь: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.performance/when_dyn_linking_static_linking.htm
Мы не привносим ничего нового в этот дебат, да и вообще консенсус в том, что в общем shared libs более тормозные.

>systemd при каждом старте нового демона вызовом fork() будет создавать свою полную копию, в десятки раз распухшую

Ты уверен, что systemd так работает? Не то, чтобы я его пользовал, но это выглядит не вполне рационально. Зачем вообще ему форкать себя для запуска демона? Это ради каких-то фичей или что?

>Придется ломать все дальше, отказываться вообще от юникс-вея и переходить на бизибокс-подобные монолитные комбайны

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

>либо отказываться от раздельной компиляции и делать языки и компиляторы с полным знанием всей цепочки вызовов

Зачем так?
При чем вообще тут компиляция, если мы линкуем?
Что значит "знать всю цепочку вызовов"? Это в смысле, без запуска программы? Ты там проблему останова уже решил?

>вроде поиска момента глушения

Не знаю точно, о чем ты, и тебе виднее, но эти или какие-либо еще моменты не обязаны быть привязаными к какой-то цепочке вызовов. В смысле, ты вряд ли что-то увидишь, просто "раскрутив стек" с окрестностью в скрин строчек.

>Это работает разве что для шелла

Ты уперся в семантику.
Я говорю: пофигу, что у нас дальше, "gcc -o app app.c" (или простенький относительно мэйкфайл) или полнофункциональный комбайн, по крайней мере с точки зрения кодописания.

>> No.206746  
>А если устанавливать все скопом в некоем достаточном для большинства задач наборе вроде .net или pip, то зачем внезапно останавливаться и ударяться в минимализм?

Очевидно, минимализм начинается не с выбора текстового редактора, и если среда будет знать о проекте гораздо больше, чем ты когда-либо будешь знать или стремиться знать, то использование среды явно приведет к хотя бы меньшему числу ошибок. Но вообще, фишка минимализма не в том, что мы выкидываем все "ненужные фичи", а в careful engineering, ну, или как я это вижу.

>> No.206757  

>>206716

>Интеграция кода и написание кода - разные стадии, нет?

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

>Но все же это не относится к написанию кода.

Набивка операторов как в Фортране в чистом виде никому не нужна, все чистые алгоритмы уже реализованы в библиотеках и оптимизированы в среднем под распространенные архитектуры. Даже если стоит задача расширить эти самые библиотеке в ядре какого-нибудь Maple или Mathemetica, оглядка на интеграцию с уже существующей инфраструктурой первична. В домашних целях, вроде написания плагина к браузеру или часов на ардуине знакомство с инфраструктурой и применяемыми инструментами тоже займет намного больше времени чем изучение синтаксиса js или С на нужном уровне.

>Не придется, лол.

Ради тебя ftp или ssh вряд ли откроют, и это не решит принципиальную предопределённость и багаж ненужного в данный момент наследия.

> Но то, что в линуксе за 10кк строк кода (или сколько там уже) явно не помогает ситуации.

Что-то не видно примеров принципиально иного результата.
А почему вообще отсутствие багов быть должно реальным? Выполняющий код компьютер как конечный автомат имеет невообразимое число возможных состояний, которые полностью оттестировать на корректность даже в виде кода на верилоге невозможно. Поверх него бежит микрокод, который точно так же не может быть оттестирован на корректность, нашумевшие уязвимости годичной давности являются следствием именно этой невозможности честного полного описания всех возможных состояний. Дальше слой багов внесёт реакция на ввод вывод, некорректности компилятора в трактовке UB и описания самих программ.
Даже если ограничиться одним софтом, существование неразрешимости проблемы останова наглядно показывает что можно даже на простейших идеальных машинах сделать практически непредсказуемое (читай: не заданное в ТЗ, бажное) поведение. Отсюда и стремление дробить задачу на уровни абстракции чтобы хоть как-то соотнести общую сложность с возможностями мозга конкретного программиста по учету всего, а смирившись с принципиальной невозможностью все описать статически появляются и такие костыли как динамическое выделение памяти, оверкоммитмент и тому подобное.

>> No.206758  

>>206716

>Аскетизм не религиозен и не "тру", это вполне себе "прагматичная экономия".

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

>Потому что задача "написания кода" не особо поменялась, например.

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

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

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

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

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

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

Потому при адекватной постановке процессов программист - это не набивальщик операторов по своему усмотрению, а человек, владеющий инструментами интеграции и документирования своих изменений, пишущий код не эффективным, а прежде всего читабельным и устойчивым к ошибкам чужого кода. Взгляни на ядро, какая доля кода там алгоритмическая (декомпрессоры, крипта, коды коррекции ошибок), и какая доля проверок входных параметров, сколько занимают общие фундаментальные вещи вроде аллокаторов и сколько костыли под костыли под эрраты разных ревизий модулей SoC-ов. Современное программирование - это не про алгоритмы, а про взаимодействие с другими программистами, примерно как научная работа это не эксперименты с выводом формул и не знание науки, а прежде всего умение интегрировать результаты из них в базу знаний мирового научного сообщества.
Велосипедить же алгоритмы при наличии готовых библиотек в высшей степени непродуктивно - код у них сложен и чреват трудноуловимыми логическими ошибками, они как правило нагруженные и проверки параметров внутри не вариант, и в то же время они как правило принимают в себя достаточно структурированные данные чтобы их можно было сколь-либо полно оттестировать на всех пограничных случаях. Разумнее брать готовую оттестированную миллионами приложений реализацию.

> Скажешь, ошибаться нормально?

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

>> No.206759  

>>206745

>Да, перенесет, но в идеале (развернутая система) разраб просто вместо одной линковки использует другую.

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

>Glibc можно влинковать статически?

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

>При статической линковке в целевой бинарник встраиваются только нужные функции.

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

> я бы не стал говорить, что прям "на порядки", особенно в случаях, когда бинари очень простые.
> echo -e "int main(){return 0;}" > test.c
> gcc test.c -o dynamic
> gcc -static test.c -o static
> ls -l
> 912608 static
> 8552 dynamic

Как раз два порядка, лол.
Статический dar 2.6.0 весит 40МБ, обычная версия 426кБ (обе без учёта сжатия upx-ом, понижающим размер до 13 МБ и 145кБ соответственно).
Потребности и тем более смысла в самостоятельной сборке чего-то тяжелее пока не случалось, но сомневаюсь что итоговый результат изменится.

> Вопрос встает так: в эпоху активного использования кэша памяти, так ли нужна инфраструктура dll в современной десктопной/серверной ОС?

Упомянутый выше dar в кеш не влезет на большинстве систем, при том что это всего лишь архиватор, тащащий в себя достаточно независимые вещи вроде компрессоров и крипты, разве что libcurl исключение. Менее системное и более пользовательское приложение скорее всего потащит на себя зависимости для гуя, работы с существующими типами файлов или api сетевых ресурсов и каждая из подбиблиотек потащит в себя в составе своей сборки ту же libс и распухание пойдет ещё и на многократности включения одной и той же зависимости и станет более чем на два порядка, и тут уже сам бинарь скорее всего не влезет в раму.

>Мы не привносим ничего нового в этот дебат, да и вообще консенсус в том, что в общем shared libs более тормозные.

Поправка: при запуске их от легковесного статического бинаря баша, динамического systemd или непосредственно ядром.

> Зачем вообще ему форкать себя для запуска демона?

Потому что такое исторически сложившееся api у ядра юниксоподобных систем, процесс может либо реплицировать себя с новым pid-ом, либо перезатереть себя и запустить в выделенной на него виртуальной памяти код из другого бинаря, запуск демона включает в себя эти две операции и опционально разделение открытых файловых дескрипторов.
По этой причине про время старта корректно говорить только для процесса запускаемого ядром с /sbin/init, время старта всего остального ещё задаётся временем на завершение отфоркнутого процесса.

>> No.206760  

>>206745

> Олдовые юниксы были слинкованы статически, например

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

>Что значит "знать всю цепочку вызовов"? Это в смысле, без запуска программы? Ты там проблему останова уже решил?

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

> эти или какие-либо еще моменты не обязаны быть привязаными к какой-то цепочке вызовов.

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

>Ты уперся в семантику.

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

>> No.206768  

>>206757

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

Конкретно эта ветка беседы не обсуждает минималистичность, просто оправдывает существование контент трекеров. Needless to say, контент трекеры магически не встроят конфликтующие изменения в проэкт, а патч, сделанный diff, вполне себе consistent, если сделать его от последней стабильной версии, например. Конечно, есть проекты, выкидывающие целые зависимости между версиями, но в таком случае можно выкинуть вообще весь уже неактуальный патч. Вернее, оставить его только для специфической версии. Я не вижу это прям такой уж потерей времени, особенно если принять во внимание, что новую стабильную версию можно ждать довольно долго.

>оглядка на интеграцию с уже существующей инфраструктурой первична

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

>Ради тебя ftp или ssh вряд ли откроют, и это не решит принципиальную предопределённость и багаж ненужного в данный момент наследия.

HTTP/1.1 скорее всего останется еще надолго. И под "надолго" я подразумеваю "еще лет на двадцать".
В любом случае, веб - полная фигня. Вряд ли время, проведенное сейчас со мной было таким уж продуктивным для нас обоих, а что же до остальных людей и сценариев - продуктивность каждого следует рассматривать отдельно и весьма критически.

>Что-то не видно примеров принципиально иного результата.

Вдохновение этому разговору придают Plan 9 и Inferno, лол.

>А почему вообще отсутствие багов быть должно реальным?

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

>Она прагматичная когда есть что экономить

Экономить человеко-часы, лол. Так конечно можно и с работы вылететь, ну да не об этом разговор.

>Учиться минимализму с нуля - это как паять приемники для освоения электроники

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

>Выглядит это так: раньше нужно было таскать 10 килограмм, а сейчас 10 тонн.

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

>> No.206769  
>Так и делают, но в то же время это пример рутины, которую можно и нужно отдавать на откуп IDE и заниматься решением самой задачи.

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

>Понижает, но идеально декомпозируемых задач не существует, абстракции протекают

Если у вас протекают абстракции, следует подумать о том, чтобы придумать новые.
Вообще основной аргумент в этой дискуссии в том, что следует подумать, прежде чем писать код.

>Не всем нужно решать сложные проблемы

Еще один аргумент, если это не было заметно, в том, что сложность применяемого решения еще стоит оправдать. Если у нас сложная предметная область, типа какого-то конкретного производства ИРЛ, то тут все ясно. Но программисты в большинстве своем просто тасуют данные, грубо говоря.

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

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

>Нет смысла в эмоциональных суждениях объективной реальности.

Когда я тоже проапгрейжусь до кибермозга, то, пожалуй, соглашусь.

>Постановки решаемых задач есть? Есть. Принципиальные пути доказательств корректности работы, например, операционной системы с многозадачностью и возможностью ставить произвольные программы есть? Нет. Значит, принять как данность и минимизировать ошибки на своем участке ответственности.

Не вижу логики в этом заключении (только логика личного вклада, а не управления проектом), как и противоречий подобного заключения с доктриной минимализма, лол.

>> No.206810  

>>206712
Не сталкивался с багами или неудобствами "модульных" программ. Места у меня много, место не проблема. Как конечному пользователю, мне всё равно, модульное оно или "модульное" - модульностью я не пользуюсь. Не думаю, что это реальным аргументом можно назвать.

>> No.206816  

>>206810
Меньше железо нагружает в целом. Если дисковое пространство и оперативная память не проблема, возможно тебя заинтересует нагрузка на центральный процессор и не только. Хотя, если железо действительно хорошее, то для него любая операционная система включая любые её компоненты как пёрышко. Последней тростинкой как в той притче спину верблюду не переломаешь.

>> No.206821  
Файл: 1548504723252.png -( KB, 1920x1080, Screenshot (1).png)
>> No.206822  

А подскажите менеджер обоев. Можно кроссплатформенный, можно под венду.
Нужна возможность настраивать вес каждой картинки при рандомной смене обоев в зависимости от её тегов и текущей даты.
Например, чтобы картинки, помеченные как "новый год", чаще показывались с 15.12 по 15.01 и реже в остальное время.
Самое близкое, что нагуглил - http://www.nuonsoft.com/wallpapercycler/, но там по времени можно только включать/исключать категории из списка, не настраивать частоту показа.

>> No.206851  

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

>> No.206852  

>>206851
У меня рабочий стол дефолтная папка для закачки файлов. Очень удобно. Время от времени просто беру всё лишнее на нём и сваливаю в помойку под названием "временная папка". Время от времени заглядывая туда, постоянно удивляюсь сколько великолепных вещей в ней гниёт.

>> No.206893  

>>206759

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

Cathedral > bazaar xD

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

Все это довольно голословно.
Ну, в смысле вмешиваться в потроха может быть довольно сложно и в шаред системе, а вопрос того, насколько часто надо перекомпилировать ВСЁ - все еще открытый. А если держать несколько версий шаред библиотек - то выигрыш от шаринга кода начинает исчезать. Собственно, особенно это заметно в тяжелых standalone проектах, вроде firefox или libreoffice.

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

Вообще, это довольно странно. В смысле логически странно. Если натравить strings на этот толстый бинарь, то можно увидеть штуки вроде _quicksort или __strcpy_ssse3 в программе, которая ничего, кроме return 0 не делает. Надо полагать, организация библиотеки или линкера может нивелировать этот блоат, но я никогда не знал точно, каким стандартам следуют линкеры. Надо полагать, это зависит от конкретного формата объектного файла в том числе.

>> No.206894  
>Как раз два порядка, лол.

Мне стало интересно показать. Да и самому посмотреть лишний раз.

>crossdev -t x86_64-unknown-linux-musl
>gcc test.c -o dynamic-gnu
>gcc -static test.c -o static-gnu
>/usr/bin/x86_64-unknown-linux-musl-gcc-7.3.1 -static test.c -o static-musl
>/usr/bin/x86_64-unknown-linux-musl-gcc-7.3.1 test.c -o dynamic-musl
>ls -l static-* dynamic-*
>7424 dynamic-gnu
>7296 dynamic-musl
>733352 static-gnu
>7280 static-musl

Как видишь, статический musl бинарь вообще самый легкий.

>x86_64-unknown-linux-musl-emerge dar
>hours of masturbating to some crossbuild quirks and musl usage differences
>2938408 dar_static
>2.9M

Я даже не ожидал этого, лол.
Там правда не все фичи врублены, например, это без gcrypt, но три алгоритма сжатия там есть, помимо других фичей.

>Упомянутый выше dar в кеш не влезет на большинстве систем

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

>Поправка: при запуске их от легковесного статического бинаря баша, динамического systemd или непосредственно ядром.

Не понял сути этой поправки.

>Потому что такое исторически сложившееся api у ядра юниксоподобных систем, процесс может либо реплицировать себя с новым pid-ом, либо перезатереть себя и запустить в выделенной на него виртуальной памяти код из другого бинаря

1) Это не значит, что ВСЕ форки будут проходить через инит. Процесс может форкать и сам себя, будучи запущенным от, скажем, шела
2) Тем больше причин делать инит маленьким, лол. Чем тяжелее общий footprint бинаря, даже шаред, тем заметнее небесплатность такого безобразия.

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

А я про то, что последующие средства для обсуждаемой "достаточности" иррелевантны, будь там интерпретатор шела, какого-то динамического языка или там компилятор функционального языка. Условно, если ты представляешь себе логическую модель языка достаточно хорошо (это легче дается с более простыми в средствах выражения языками), тебе не нужны костыли вроде даже подсветки синтаксиса. Для написания кода. Для чтения и последующего редактирования - это более ситуативно. В принципе, довольно продвинутые ide со встроенными дебаггерами или чем там еще существовали еще в 80-е (вроде turbo pascal). При этом они еще и ЛЕГКИЕ, по крайней мере на теперешние мерки, лол. Легковесные ide существуют и теперь, но, надо полагать, поиск с индексатором и какими-то нетривиальными правилами (анализ классов и их областей видимости или что там) может начать ощутимо подлаговывать. Boner killer, короче. А можно просто втыкать в текст, авось чето поймешь в коде, лол.

>> No.206898  

>>206851
Я так делаю.

>> No.206939  
Файл: 1549125933649.jpg -( KB, 1500x932, 1549125929824.jpeg)

>>206851
Обои иногда ставлю, есть несколько "избранных" на всякие поводы и просто (прямо сейчас пикрелейтед), и иногда их даже вижу, но не очень часто, потому что живу в браузере, либо в чём-то работаю/играю. Все значки либо на панелях, либо в меню на панелях, а на рабочем столе фактически ручной /temp.

>> No.206947  

Поставил на ноут debian stretch с теми кедами, которые там по дефолту. И для начала, они без спросу полезли обновлять пакеты (вопиющая дыра в безопасности, вообще-то. Там в этот момент как раз был дырявый apt (DSA-4371-1). Интересно, если им запостить это как багрепорт, это возымеет хоть какое-то действие?).
Хрень, которую это делала (пакет plasma-discover), я нашел и снёс. Но теперь меня интересует, нет ли там других подобных подлянок? Наверняка ведь есть…

Ну и до кучи — как её вообще сделать максимально похожей на предыдущую версию? Просто поставить темой oxigen — помогает слабо… Была ведь хорошая вещь, нет, сделали не пойми что, по наглости сравнимое с виндой.

>> No.206950  

>>206947

>Была ведь хорошая вещь, нет, сделали не пойми что, по наглости сравнимое с виндой.

Чую я тут чей-то хитрый план.

>> No.206964  
Файл: 1549336485652.png -( KB, 1344x227, tab-win.png)

>>206947
Так. В этой чертовой пятой плазме не работает группировка окон.
Совсем, то есть абсолютно: https://bugs.kde.org/show_bug.cgi?id=343690

Сдаунгрейднить ее на четвертую в debian 9 (и, кажется, далеко не только в нём), как я понял, невозможно.

Соответственно — ищу DE/WM на замену.
Требование: группировка окон (windows tabbing, на picrelated можно видеть 5 объединенных окон браузера — так это работает в kde4) должна быть и работать. Это ключевое условие.
Также желательно, чтобы внешне было более-менее похоже на kde4, но это не критично.

>> No.206970  

>>206964

>Соответственно — ищу DE/WM на замену.
>Требование: группировка окон

(и тишина…) Ладно, спрошу иначе:
Fluxbox кто-нибудь юзал? Какие подводные камни?

>> No.206977  

>>206970
Юзал. Он так умеет. Как по мне лучший из боксов, но мне больше про него сказать нечего.
Группировкой пользовался очень мало.

>> No.206983  

Алло, это линукс-тред?
Не подскажите, как сделать физический ключ к компьютеру? То бишь, флешку или ардуину какую-нибудь втыкаемую в usb (второе даже предпочтительнее, так как неспециалисту какой-нибудь эмулятор уарта отгавкивающийся ключом на ключ будет сложнее скопировать себе), без ключа на которой система не стартует и диск не расшифровывается.
В теории понятно что нужно поколдовать с dm-crypt, но не хотелось бы изобретать велосипед и экспериментировать на живой системе без примеров как делается по уму.

>> No.206984  

>>206983
А может все-таки не стоит экспериментировать на живой системе? Сделай себе отдельную для экспериментов из копеечного мусора какого-нибудь. Или из одноплатника вроде Raspberry Pi или Orange Pi.

А по сути вопроса гугли LUKS + smart-card. Гайдов и скриптов довольно много и они зависят от того, какой initrd используется. Очень много тонкостей с ними зависит от того, как организована загрузка на конкретной машине, так что вероятно понадобится адаптация скриптов. Но общая суть в основном заключается в том, что в initrd организован хук, который до операций с корневой фс декодирует keyfile в память так или иначе с использованием USB-токена, а потом использует этот файл как ключ для cryptsetup.

Если хочешь и смарткарту сам сделать, то arduino не подойдет по некоторым железным причинам. Гугли Gnuk и ставь его на STM32.

>> No.206988  

>>206964
В i3 это есть.

>> No.206990  

>>206964
Господи, ну и шрифтопокалипсис в названиях табов.

С группировкой окон вроде бы был то ли FVWM, то ли Haiku fluxbox, - но они эксцентричные.

>> No.207001  

>>206990
fvwm просто из вермён весьма древних.
Так одно время из него было модно пилить темки а-ля 98ая или ХРшная винда.

>> No.207003  

>>206990

>шрифтопокалипсис

А что у меня не так со шрифтами? Лично я не вижу особых отличий между ними и, скажем, теми, которые на ОП-пике.

>fluxbox

Угу, видимо, им и буду обмазываться. Вопрос только, сохраняет ли он свои замечательные свойства, если его поставить в качестве WM куда-нибудь в то же kde или lxqt, или, чтобы всё это работало, нужно сидеть на голом боксе без DE?

>>206988
>>207001
Посмотрел я на все эти i3, fvwm и прочие Window Maker'ы… Ну… Как по мне — это куда большая экзотика, чем боксы.

P.S. Еще вопрос немного не в тему — можно ли так настроить SDDM, чтоб для разных юзеров он по умолчанию запускал разные типы сеансов? Т.е. для одного — fluxbox, для другого — kde и т.д.

>> No.207004  

>>207003

>можно ли так настроить SDDM, чтоб для разных юзеров он по умолчанию запускал разные типы сеансов?

Сам спросил — сам отвечаю. Нихрена:
https://github.com/sddm/sddm/issues/346 (точнее, можно, через кривые костыли и пляски с бубном. Нафиг-нафиг)
Походу, тоже менять. На LightDM, наверное… Или что там у нас еще AccountsService понимает?

За какой кусок нового kde не возьмешься — всюду подстава…

>> No.207008  

>>207004

>AccountsService

То есть ~/.dmrc. А ночью надо спать.

Через AccountsService тоже можно, но, если я правильно понял, это не очень хорошая идея.

>> No.207023  

>>207003
Толщина линий у символов "Э", "и", "к" в активном табе "Электроника и ПО" заметно больше, чем у других символов.

> сохраняет ли он свои замечательные свойства, если его поставить в качестве WM куда-нибудь в то же kde или lxqt

Скорее сохранит, чем не сохранит.

>> No.207033  
Файл: 1549898710682.png -( KB, 1218x592, DejaVuSans9.png)

>>207023

>Толщина линий у символов "Э", "и", "к"

Хм… Да, действительно, если внимательно приглядеться, что-то такое есть.
Тогда, раз ты такой зоркий, можешь сказать — на пикрелейтед это наблюдается только слева, или и справа тоже?
В смысле — дело в самом шрифте, или только в кривых настройках?
Я вижу, что справа сильно отличается толщина некоторых спецсимволов, вроде \®|©/, но не уверен, бага это или фича. Еще, вроде, что-то не так с буквой Х, но, возможно, это мне кажется.

>Скорее сохранит

Это радует.

>> No.207034  

>>207033

> Тогда, раз ты такой зоркий, можешь сказать — на пикрелейтед это наблюдается только слева, или и справа тоже?

Слева и справа в bold шрифтах.

> В смысле — дело в самом шрифте, или только в кривых настройках?

Как я понимаю дело в настройке hintstyle ("Стиль хинтинга"):

> Hintstyle это сумма изменений шрифта, сделанных чтобы выстроить его по пиксельной сетке.
> Значения хинтинга: hintnone(без хинтинга), hintslight(лёгкий хинтинг), hintmedium(средний хинтинг), и hintfull(полный хинтинг).
> hintslight сделает шрифт более нечётким выстраивая по сетке, но сохранит лучше форму шрифта, в то время как hintfull сделает чётким шрифт, выровняет хорошо по пиксельной сетке, но больше потеряет форму шрифта

Вот похоже потеря формы и проявляется в разной толщине линий.

>> No.207036  
Файл: 1549908061136.png -( KB, 1551x532, hinting.png)

>>207034

>дело в настройке hintstyle

Слева направо: low, medium, full.

При low шрифты размытые и от них болят глаза (которые постоянно и безуспешно пытаются на них сфокусироваться). К тому же все менюшки почему-то стали толстыми.
Да и при medium тоже они какие-то как будто слегка мерцающие.

Так что, если дело действительно в этом — ну его нафиг. То что буквы чуть-чуть разной толщины — мне без лупы не разобрать. А портить глаза мыльным изображением я не хочу.
Другое дело, что, может быть, шрифт, всё-таки, неудачный. Здесь (в jessie) DejaVu, а в следующей версии его заменили на Noto. Возможно, не случайно (и когда я, наконец, обновлю на этом компе систему, этот вопрос решится сам).

>> No.207037  

>>207034
Сто лет сижу на винде без хинтинга и сглаживания, буквы одного размера всегда везде одинакоые. Это не может быть результатом хинтинга.

>> No.207039  

>>207036
Noto тоже плох, всегда маскирую его в репо. Вообще с не-latin символами всё плохо в стандартных свободных шрифтах, которые ставят иксы или kde искоропки. Неплохо хинтятся (стандартными настройками из >>207033) всё семейство Droid и старая добрая Verdana с Tahomой вытащенная из M$ OS образца 2009 года или новее.

>> No.207041  

>>207037
Какой-то бред я написал. Теперь я начинаю понимать. Буквы утолщаются для сохранения шрифта, и из-за особенностей алгоритма утолщаются неодинаково?

>> No.207055  

>>207041
Примерно так, да.

Скажем когда нужно отрендерить линию толщиной 1px ровно по границе между двумя пикселами у рендерера есть выбор: закрасить оба соседних пиксела серым цветом (hintslight, пушистые шрифты) либо же подбросить монетку закрасить один из пикселов чёрным (hintfull, шрифты с линиями разной толщины).

Некоторые шрифты от MS из 90х рисовались с учетом пиксельной сетки и потому могут и с hintfull выглядеть ничего себе так.

В идеале все эти проблемы скоро должны исчезнуть с ростом количества пикселов/дюйм в современных дисплеях.

>> No.207057  
>шрифтопроблемы

Вообще, есть пакет под именем corefonts (или mscorefonts, или webcorefonts, я точно не помню), содержащий хорошие шрифты, включенные в Винду, такие как Tahoma, Verdana и другие. Ну, это к тому, что самому вытаскивать их даже не надо.

>В идеале все эти проблемы скоро должны исчезнуть с ростом количества пикселов/дюйм в современных дисплеях.

а) софтопроблемы с этим будут совершенно невыносимы до скончания всего легаси-кода, который не может в масштабируемость
б) что на винде, что на прыщах софтверная поддержка этого находится на печальном уровне, насколько мне известно; то есть, перед тем как покупать hidpi монитор (200+ ppi), следует подумать
в) эти мониторы не то, чтобы массовые (они дороги)

Но на смартфонах это давно уже не проблема, да.

>> No.207059  

Раз здесь разговор про шрифты, то такой вопрос — какой шрифт поставить в консоли (которая до запуска иксов), чтобы в нем был и русский, и псевдографика? А то после запуска setupcon двойные линии превращаются в ромбики/тофу (остаются только одинарные). А из 16 цветов остаются лишь первые 8, кто-нибудь знает, как бороться?
MC норм с этим, а вот фар уже не очень.

>> No.207061  
Файл: 1550113869407.png -( KB, 431x284, font.png)

>>207059
Да, забыл пикчу. Это то, что там сейчас.
Соответственно, нужны ═║╒╓╔╕╖╗╘╙╚╛╜╝╞╟╠╡╢╣╤╥╦╧╨╩╪╫, а всякие Ć憇 и т.д. — прямо скажем, не особо.

>> No.207062  

>>207059>>207061
Дистрибутив хоть сказал. Поищи где у тебя консольные шрифты лежат. Например /usr/share/kbd/consolefonts/. Потыкай те, что по названиям мгут быть русскими (setfont имя-безрасширений), хотя скорее всего их нет. Можешь поставить консольный Terminus, он кирилицу поддерживает setfont ter-v16n, ну или какой там подберёшь, они все начинаются с ter-.

>> No.207063  

>>207062

> Можешь поставить консольный Terminus

Имелось ввиду, что надо поставить из репозитория.

>> No.207064  
Файл: 1550118739068.png -( KB, 776x464, CyrKoi-Fixed16.psf.png)

>>207062>>207062
Так, разобрался. Шрифт пикрелейтед. В /etc/default/console-setup пишется

CHARMAP="UTF-8"
CODESET="CyrKoi"

A FONTFACE может быть любым допустимым: Terminus, Fixed и т.д.

А вот с опцией VIDEOMODE мне разобраться пока не удалось. В каком вообще формате этот самый режим ей писать? dec, hex?

>Дистрибутив хоть сказал.

Дебиан, но это, вроде, верно не только для него.

>> No.207065  

>>207064

> А вот с опцией VIDEOMODE мне разобраться пока не удалось. В каком вообще формате этот самый режим ей писать? dec, hex?

У меня в Ксубунте он вообще пустой. Видеорежим выставлен в загрузчике.

> это, вроде, верно не только для него

В Дебиане/Убунте есть этот самый console-setup, в других другие конфи, да ещё могут по /etc раскиданы.

>> No.207066  

>>207065

>У меня в Ксубунте он вообще пустой. Видеорежим выставлен в загрузчике.

И, похоже, так оно везде. По запросам console-setup VIDEOMODE косяками идут инструкции по настройке консольных шрифтов, с листингами этого console-setup, где VIDEOMODE пустой.

А по запросам debian console videomode — статьи вроде этой: https://blog.rsaffi.com/2017/08/how-to-run-debian-9-1-stretch-with-proprietary-nvidia-driver-and-uvesafb/
И похоже, если я хочу это дело перенастроить, примерно этим инструкциям и придется следовать.

Непонятно тогда, зачем эта опция вообще нужна. Заставить ее хоть как-то работать (даже выдавать ошибку) мне не удалось.

>> No.207067  

>>207066

>примерно этим инструкциям и придется следовать.

И это, что характерно, решило и проблему

>из 16 цветов остаются лишь первые 8

из >>207059.

>> No.207079  

>>207066
В статье хрень написана.
Не надо ничего писать в /etc/default/grub. Наоборот, надо удалить оттуда все параметры ядра вида video= или vga=. И GRUB_GFXMODE_bla_bla_bal тоже лучше удалить. Если этого не сделать, результат будет:

uvesafb: request region 0x3c0-0x3e0 failed

и никакого фреймбуфера.

Ну и опции самого модуля лучше бы вынести в /etc/modprobe.d/uvesafb.conf.

>> No.207288  

>>207003

>можно ли так настроить SDDM, чтоб дон по умолчанию запускал разные типы сеансов?

А если поставить ему темой, например debian-elarun (подозреваю, что вообще любую, отличную дефолтного от breeze), то единственным способом заставить его переключить сессию будет удалить все desktop-файлы, кроме нужного, из /usr/share/xsessions. Менюшка смены сессии у него будет, но реагировать на нее он не будет от слова "совсем". Такие дела.

Кстати, что лучше — LightDM или SLiM?

>> No.207320  
>Ставлю lxqt
>Вижу, что в менюшке очень мелкие значки.
>Ищу как это изменить. Не нахожу. Можно только поменять размер шрифта, что мне не надо.
>Лезу в исходный код. Вижу вот это:
//icon size the same as the font height
const int icon_size = QFontMetrics(menuFont).height();
mTopMenuStyle.setIconSize(icon_size);
mSearchView->setIconSize(QSize{icon_size, icon_size});

Вот теперь я всерьёз хочу убить тех, кто это написал.

В общем — посоветуйте какую-нибудь универсальную менюшку, которой можно было бы это непотребство заменить.

>> No.207322  
Файл: 1552234483328.jpg -( KB, 1280x800, screenshot01.jpg)

Разбавлю-ка обилие пингвинов своим старым ноутом. Сегодня впервые, наверное, за последние лет 10 загрузился в его родную Висту (чисто из любопытства), и оказалось, что она вполне себе работает.

>> No.207323  

>>207322
Виста — это одна из немногих систем, которую хочется облизать. Градиентная панель задач — это большая черносмородиновая карамелька. Кнопка "закрыть" — маленькая барбариска. Кнопка "Пуск" — черника или ежевика со сливками.
Я поехавший, да.

>> No.207324  

>>207288

> Кстати, что лучше — LightDM или SLiM?

Getty остальные DM слишком бажные.

>> No.207330  

>>207320

>какую-нибудь универсальную менюшку,

А такие вообще существуют? Не встроенные в панели, не та хрень, которая у боксов по правой кнопке, а именно в виде отдельного аплета, который можно впихнуть куда-нибудь в tint2, или просто повесить в нужном месте экрана — и оно будет работать?
Я сейчас попробовал погуглить, и что-то сходу ничего не нашлось…

>> No.207331  
Файл: 1552270293612.png -( KB, 609x568, [Raws-4U] 偽物語 第10話 「第拾話 つきひフェニックス 其ノ參」 ((...).png)

>>207036
Можешь спокойно выбрасывать всю гарнитуру DejaVu (за исключением, может, Mono). DejaVu произошла от гарнитуры Bitstream Vera, которую создала профессиональная шрифтодельня. Создала тупо из нежелания платить за Гельветику. О кириллице в этой гарнитуре никто не задумывался изначально, поэтому когда код Vera открыли, кириллицы в ней и не было. Её добавили «умелые ручки» впоследствии. Поэтому там ни хинтовки ни хотя бы даже нормальных очертаний ожидать не приходится.

Возьми лучше PT https://company.paratype.com/pt-sans-pt-serif — они хорошие и бесплатные. Можешь попробовать Lora, More Pro, Lato, Sceptica — вот эти оптимизированы под экран и имеют сносную кириллицу. Всякие Noto, Roboto, Neuron, Fira творят с кириллицей мракобесие, хотя выглядят всё равно лучше, чем DejaVu.

Есть и другие шрифты с хорошей кириллицей, но им либо мало экранного dpi (90–110), или они несвободные.

>> No.207335  

>>207320
Менюшку я бы тебе накодил/нагуглил, но тебе понадобится найти место, из которого она будет создаваться (в настройках, например).

>> No.207336  

>>207320
И ещё тебе нужно будет параметризовать этот код, потому что, даже если ты менюшку сделаешь, куда ты будешь заданное значение передавать?

>> No.207337  

>>207330

>сходу ничего не нашлось

Со второго захода нашлось таки целых две штуки:

>>207335

>но тебе понадобится найти место, из которого она будет создаваться

В смысле? Ей подсовывается файл в формате xdg menu, и из него она всё и рисует. Вот по этой спеке: https://specifications.freedesktop.org/menu-spec/latest/

Вообще, еще один вариант — тупо прописать прямо в коде lxqt-panel нужные настройки и пересобрать пакет. Возможно, это будет быстрее и проще, чем менять всю панель на что-то другое и заново её настраивать (по частям этот кусок хвалёного суперкастомизируемого lxqt, как я понимаю, не слишком-то меняется, там, похоже, даже "плагины" захардкодены).

>> No.207338  

>>207337

>В смысле? Ей подсовывается файл в формате xdg menu, и из него она всё и рисует.

Тогда понятно. Я не знаю ничего про LXQT, я знаю плюсы и Qt.

>> No.207340  

>>207338

>Я не знаю ничего про LXQT

Ну, как бы, xdg menu — это немного про другое, там он просто используется. И в тех двух менюшках из >>207337, кстати, тоже.

>я знаю плюсы и Qt

Тогда, наверное, ты меня поймешь. Вот есть Qt. Красивая и аккуратная библиотека. И есть GTK, код которого выглядит так, словно его писали наркоманы по обкурке. Тем не менее, постоянно я натыкаюсь на вот такое: берем приложение GTK — всё настраивается, кастомизируется, любой модуль можно отпилить и заменить своим. Берем приложение Qt, ищем нужную настройку — и нифига. Даже вот этот пример. В исходной lxpanel, скажем, размеры иконок меняются просто в конфигах темы. А как переписали на Qt — так всё отвалилось. Вот почему так происходит, а?
И ведь ладно, были бы какие объективные трудности. Так нет же, я смотрю вот на код lxqt-panel и вижу, что переписать ее так, чтобы там каждый чих настраивался, в принципе, вполне реально (было бы время… которого никогда нет). Нет, им зачем-то понадобилось всё, включая "плагины" (какие это, нафиг, плагины, если они зашиты в код?), прибивать гвоздями…

>> No.207341  

>>207331
Если мне не изменяет память, вся тема про шрифты началась со скриншота, на котором был заголовок браузера (>>206964). Так вот, у меня вопрос: что будет в этом заголовке, если поставить эти PT (которые, как я понимаю, поддерживают только кириллицу и латиницу) и зайти, скажем, на пиксив?

>> No.207342  

>>207341
Грустно будет.
Я как-то пострадал от Astra Serif, когда готовил огромный плакат, в котором понадобилось держать несколько греческих букв. Буквы-то я поместил куда надо, но осадочек остался, в следующий раз надо будет подробнее этот вопрос проработать.

>> No.207350  

>>207340

>Вот почему так происходит, а?

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

>> No.207351  

>>207331
Пользуюсь Roboto как основым системным шрифтом уже 2.5 года, о каком мракобесии с кириллицей ты говоришь?
c: joy

>> No.207354  

>>207341
Если ты просто поставишь эти шрифты, то ничего не изменится.

Чтобы повлиять на то, чем браузер рисует себя, нужно выбрать эти шрифты в качестве системных. Если это, например, старый firefox (<53), то он пользует настройки GTK+2 приложений, которые редактируются например lxappearance. Для QT был qtconfig -qt4, если память не изменяет. Для GTK+3 самихпосебегуёв не было, правь руками ~/.config/gtk-3.0/settings.ini.

Когда ты зайдёшь на Pixiv, то те символы, которых в шрифтах нет, будут подтянуты из другого шрифта, где они есть. Какого именно — зависит от настройки fontconfig. Ты можешь повлиять на выбор через ~/.config/fontconfig/fonts.conf.

Если у тебя стоит DE, то там могут быть свои надстройки — гуёвые или не очень, — которые могут обидеться на то, что ты полез настраивать что-то мимо них, и перехерачить тебе всё на свой лад. Поэтому проверь сначала их.

>> No.207356  

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

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

К Roboto Sans две основные претензии

  1. Если посмотреть на строчную «б» в крупном виде (от 30 pt), видно, что верхний штрих над овалом почему-то загнут кверху и под прямым углом упирается в потолок. Такого в наших шрифтах никогда не было. В антикве на этом месте может быть засечка, но основной штрих тут не загибается вверх. Он всегда стремится лечь над овалом либо горизонтально, либо наискосок уходит вверх, при этом обязательно истончаясь кверху — никакого тупого обрубка, торчащего под 90° быть не может. В Roboto этот штрих сделан как имбецильно выпяченная нижняя губа, потому что Россия перестала участвовать в создании шрифтов, которые сама же использует. Вот автор и взял за основу работу каких-то индусов, где «д» как «п с перекладиной» и пошло-поехало. К счастью, на размерах около 9 pt этого уродства не заметно.
  2. Автор по всей видимости испытывал трудность в определении того, насколько хвостики у Д, Ц и Щ важны и должны выступать, поэтому трусливо сделал их такими, что «ни туда и ни сюда». Они находятся на грани возможного. Было бы приятнее видеть их чуть более выступающими, чтобы они достойно занимали столько ширины, сколько им нужно.

А вот попробуем Roboto Slab — здесь всё гораздо хуже.

  1. Нижняя перекладина у Д справа выступает даже меньше, чем верхняя засечка. А должна больше неё. Да и слева тоже коротковато, только рано начатый изгиб штриха над ней создаёт объём, близкий к необходимому, иначе бы Д выглядела совсем стиснутой.
  2. Не нравится, что на мелких кеглях часть засечек не пропадает — из-за этого в центре буквы «ж» штрхи стараются сами себя перекромсать. Примечательно, что центральные штрихи в «ш» и «щ» засечки намеренно лишены даже на крупном кегле.
  3. Странно, что левый наклонный штрих в У не следует формам Ж и К — по идее тоже должен бы быть загнут, а не заканчиваться засечкой. Весьма странны обоюдоотсечённые концы у С и Э — ведь в З автор не допустил такой ошибки. Roboto Slab, кажется, косплеит в этих буквах Bodoni, — и это было бы простительно открытой антикве типа London или Playfair, которые действительно подобны Bodoni. А если ты брусковая гарнитура, то и смотреть должна на Clarendon.

В общем, Sans исправили, а Slab так и остался сасуга франкенфонт.

>> No.207360  

Вопрос по поводу WM.
Такую хреновину, как pekwm кто-нибудь юзал?
Какие впечатления/подводные камни?

Вроде бы это должно быть что-то похожее на fluxbox, но без лишних деталей. Но… на их сайте сломаны все ссылки, документация ведёт в 404. В готовых пакетах никаких док нету. В сорцах, взятых с гитхаба, сборка документации сломана. Мне эти доки удалось-таки собрать… даже не "напильником с бубном", а "посредством кувалды и такой-то матери". И то, что собралось, датировано 2013 годом. И все внешние ссылки (на вики и т.д.) в ней мертвы.

И как это всё можно понимать? Проект, вроде, не мертв, какое-то шевеление на гитхабе есть… но можно ли этим пользоваться, раз там такая фигня? И насколько эти древние доки можно считать адекватными?

>> No.207417  

>>207360
Это выглядит как почти абсолютно дохлый проэкт, если я в этом что-то понимаю.

Sourcefourge содержит старую версию и явно заброшен. Сайт pekwm.org поддерживается, но HTTPS сертификат поломан.
Ни одна из ссылок на гит оттуда не работает. Ни www.pekwm.org/git/pekwm.git , ни http://projects.pekdon.net/git/pekwm.git . Ohloh что-то честно отображает, но это все давности несколько месяцев.
Судя по самому сайту, серьезность проэкта низка. "What do people think about pekwm?" "Want to pimp your pekwm?" Этот проэкт выглядит как гротескная шутка из кликбейтов.
Github и правда содержит какой-то код, но ссылки с самого сайта или там с рачвики туда не ведут. Почему я не должен думать, что это какой-то форк с бекдорами в принципе, лол? Коммиты за последние лет шесть можно пересчитать по пальцам рук, ну, или рук и ног, в крайнем случае.
Наиболее актуальную документацию, надо полагать, можно увидеть в doc/
Например: https://github.com/pekdon/pekwm/blob/master/doc/faq/answers/answers.xml (в нескомпилированном виде). Если еще что-то есть, то найти это почти невозможно.

>> No.207418  

>>207417
В репах дебиана он таки имеется (туда вряд ли пустили бы левую сборку с бэкдором. Деб, кончено, уже не торт, но, всё же, не до такой же степени).
Причем везде одна и та же версия, от stable до sid. Это, в принципе, похоже на признак того, что проект уже не совсем жив, но… по этому признаку мертвыми будет и fluxbox. inb4 он и есть мертвый

Впрочем, я в этот тред по немного другому вопросы заглянул.
Так вот…
Можно ли в zenity/yad/etc вывести одну голую менюшку без обрамления в виде всяких заголовков окна и лишних кнопок? И желательно — ведущую себя как нормальное меню, т.е. просто исчезающее, если кликнуть не по ней.
А если нельзя — то подскажите, pls, в чем можно. Конечно, такой скрипт, наверное, легко было бы просто написать… Но…

>> No.207422  

>>207418

>В репах дебиана он таки имеется

Да это я так, ворчал оттого, что по ссылкам с основного сайта нифига не найти. Очень большое "вряд ли" что кто-то станет маяться с таким элементом софта, как wm.

>Это, в принципе, похоже на признак того, что проект уже не совсем жив

Ну, вообще, в принципе, отсутствие изменений в коде wm может значить то, что он совершенен, лол. Нижележащие механизмы (иксы) почти не изменяются. Но мне кажется, дело в том, что они в какой-то момент его подзабросили, народ разбежался, и теперь особо не для кого исправлять баги, если они есть - активность в issues жидхаба тоже маленькая.

>Можно ли в zenity/yad

Понятия не имею, что это, просто поддержать разговор.

>> No.207423  
Файл: 1552923510639.png -( KB, 118x120, yad.png)

>>207422

>Нижележащие механизмы (иксы) почти не изменяются.

Ничего, вот придет вайланд… хе-хе…

>Понятия не имею, что это

Хрень, которая позволяет вызывать GТК-элементы из командной строки.
В принципе, разобрался уже. Пишем

yad --width=120 --height=120 --no-buttons --undecorated --close-on-unfocus \
--list --column "test" "foo" "bar" "baz"

и получаем пикрелейтед.

>> No.207424  

>>207418

> pekwm
> динамическое меню

openbox? (http://openbox.org/wiki/Openbox:Pipemenus)

>> No.207467  
Файл: 1553200542833.png -( KB, 375x554, 6465421d.png)

А кому-нибудь удалось завести раскладку пятого уровня? Всё правильно, не третьего (lv3_switch), и не четвёртого (он же, но с шифтом), а пятого?

В evdev.lst упоминается lv5:ralt_switch_lock, но кастомная xkbmap, в которой прописаны дополнительно 4, 5, 6 уровни для одной клавиши, не взлетает. То ли я что-то делаю не так, то ли фича недопилена/заброшена.

>> No.207469  

>>207467
Не знаю точно, о чем ты, но XKB поддерживает до 4 ки-групп.
https://en.wikipedia.org/wiki/X_keyboard_extension#Key_groups

>XKB allows for the keyboard to switch between any of four different character groups.

Если нужно что-то больше, нужен дополнительный софт, которому ты передашь управление раскладками.
Я даже больше скажу - key groups ≠ keyboard layouts, это разные понятия для иксов или, не знаю, десктопа. Обычно конфигурация смены языка ввода производится именно через key groups, впрочем.

>> No.207480  

>>207469
Уровни живут внутри групп. Уровни 1–2 это строчная-прописная; 3–4 это как раз типографская, 5–6 — над типографской.

>> No.207483  

>>207480
А.
Ну, не использую такое и даже не знал о его существовании.
Я использую Compose Key для вставки странных символов.

>> No.208957  
Файл: 1561136676309.png -( KB, 1280x1024, Untitled-1 copy.png)

Надо бы попробовать поиграться и с LiteStep.

>> No.208961  

>>208957
Из какого анимэ эта девочка?

>> No.208962  
Файл: 1561185677281.png -( KB, 1280x2013, Touhou Gensou Mangekyou ~The Memories of(...).png)

>>208961

https://anidb.net/perl-bin/animedb.pl?show=anime&aid=8624

>> No.208971  

>>208962
Спасибо, там Ёму красивая сверху.

>> No.209143  
Файл: 1562346494690.png -( KB, 1366x768, screenshot.png)
>> No.209172  
Файл: 1562477729208.png -( KB, 1366x768, Screenshot_20190707_103102.png)

Обновился до десятки.

>> No.209180  

>>209172
А своп-то тебе зачем?

>> No.209192  

>>209180
Под гибернацию. Можно бы и уменьшить его, да, но мне лень.

>> No.209227  

>>202068
Лол, да это компьютер настоящей Сырно!

>> No.209228  
Файл: 1562817280859.png -( KB, 1280x800, Screenshot.png)

Тредик интересный, особенно понравился рм-скриншот, но дочитаю я его потом.

>> No.209233  
Файл: 1562836585815.png -( KB, 1920x1080, изображение.png)

Комп на работе, дианон.

>> No.209234  
Файл: 1562837252480.png -( KB, 654x416, изображение.png)

>>209233

>> No.209245  
Файл: 1563029761495.png -( KB, 1920x1080, shit.png)

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

>> No.209246  

>>209245
Да отключи ты эту ручку, и всего делов.
Если это локализованные пятые кеды, в окошке свойств рабочего стола есть разде "Поправки", где эта штуковина отключается.

>> No.209247  

>>209246
То, что ее так колбасит — это скорее симптом. Я же говорю, при этом еще и другие окна разъезжаются кто куда.
Пока что единственный способ исправить — выйти и снова зайти. Тогда есть шанс, что встанет нормально.
Если что — это kde4, а не 5 (5 мне сильно не нравится). И вообще довольно древняя система.

>> No.209248  

>>209245>>209247
Покажи вывод xrandr. И через него же скорее всего и можно будет эти расплывшиеся координаты исправить.

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

>> No.209249  
Файл: 1563046927639.gif -( KB, 66x17, .gif)

>>209228
А предыдущий был ещё интереснее! И притом вовсе не беседами о десктопах.

Правда, ему уже успели сделать 404.

>> No.209252  

>>209247
Тоже сталкивался иногда с такой ерундой, да, и тоже при запуске игор через вайн. Правда, нечасто. Временно (до следующего запуска той кривой игры) лечилось понижением и повышением обратно разрешения экрана на десктопе после выхода из игры.
Полностью эта, как и некоторая другая хрень, вылечилась несколько лет назад, при обновлении до девятки со встроенными пятыми кедами :3

>> No.209262  

>>209248

>вывод xrandr
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)
DP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 299mm
1920x1080 60.00*+ 110.00 59.94 50.00 60.00 50.04
1440x900 119.85
1280x1024 75.02
1280x960 99.78
1280x720 60.00 59.94 50.00
1024x768 119.99 75.03 70.07 60.00
800x600 119.97 99.66 75.00 72.19 60.32 56.25
720x576 50.00
720x480 59.94
640x480 119.52 99.77 75.00 72.81 59.94 59.93

Вывод с глюком и без глюка один и тот же.
Also, сейчас поменял частоту на 110 (кстати это действительно менее вредно для глаз, чем 60, или брешут? Визуально разницы нет). На наличие/отсутствие глюка не повлияло.

>древние игры лучше всего запускать в отдельных иксах

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

>>209252

>лечилось понижением и повышением обратно разрешения экрана

Угу, такие вещи я делал сразу после этого факапа, когда там были куда более жесткие глюки (черный экран с квадратиком рабочего стола 640х480 в верхнем углу, ага). От них помогло, а вот это — осталось.

>вылечилась при обновлении до девятки со встроенными пятыми кедами

Спасибо, но когда у меня наконец дойдут руки до обновления этой системы — кед там точно не будет.

>> No.209264  

>>209262

>кед там точно не будет

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

>> No.209265  

>>209264
Ну, например, посмотри, что обсуждалось в этом треде начиная с >>206947.

>> No.209267  

>>209262
Хм. Тогда это в самой плазме залипнуть что-то могло. Но на всякий случай: если явно сделать xrandr --verbose --output DP-1 --mode 1920x1080, то всё равно ничего не изменится? Если во время проявления глюка перезапустить плазму (kquitapp plasma-desktop && kstartapp plasma-desktop) — что-нибудь изменится? А если сделать kwin --replace? А если все конфигурационные файлы плазмы (~/.kde/share/config/plasma*) на время переместить или переименовать? Последнее лучше всего делать из консоли предварительно разлогинившись.



Удалить сообщение []
Пароль
[d | an-b-bro-hr-l-m-med-mi-mu-o-ph-r-s-sci-tran-tv-x | vg | au-tr | a-aa-c-fi-jp-rm-tan-to-vn | gf | azu-bg-dn-fr-hau-ls-ma-maid-me-mo-ne-old_o-p-sos-sp-t-w | misc-vnd | stat ]
[Burichan] [Futaba] [Gurochan] - [Архив - Каталог] [Главная]