forum.opennet.ru - "Отчёт о развитии FreeBSD за первый квартал 2020 года" (165)

"Отчёт о развитии FreeBSD за первый квартал 2020 года"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
Сообщение от opennews (ok), 13-Апр-20, 16:16
Опубликован отчёт о развитии проекта FreeBSD с января по март 2020 года. Из изменений можно отметить:... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52727
Ответить \| Правка \| Cообщить модератору

Оглавление

Прекрасно Фряшка развивается, что не может не радовать , dvz (??), 16:31 , 13-Апр-20, (2) +49

Скрыто модератором, Аноним (7), 16:55 , 13-Апр-20, (7) –20

Скрыто модератором, анонн (ok), 17:05 , 13-Апр-20, (10) +24

Ну да, интеловское видео перетащили из линукса ZoL тоже Заживём , Аноним (76), 10:02 , 14-Апр-20, (76) –4

Вообще-то из интеля Или загружаемые чере NDISWrapper дрова у вас из винды утащ, Аноним (85), 11:52 , 14-Апр-20, (85) +6

Ммм как бы тебе сообщить это, но даже когда оно было актуально, оно не очень пре, Аноним (86), 12:00 , 14-Апр-20, (86) –3

Ммм, как бы тебе сообщить это даже если это так, то это ровным счетом ничег, Аноним (-), 12:18 , 14-Апр-20, (89) +2

Ну ты сравнил проприетарные блобы другой системы, нелегально загружаемые через к, Аноним (86), 12:28 , 14-Апр-20, (92) –3

И у кого интель их слямзил Судя по всему, вся тема в целом анониму не очень поня, Аноним (-), 12:37 , 14-Апр-20, (96) +3

При чём тут интел, когда он абстрактный Зато анониму надо обязательно приплести , Аноним (86), 12:47 , 14-Апр-20, (97) –2

В вакууме, сферический Если аноним опеннета чего-то не понял, то это не пробел в, Аноним (102), 14:25 , 14-Апр-20, (102)

из всего списка меня больше всего волнует if_bridge, Аноним (4), 16:42 , 13-Апр-20, (4) +1

ng_bridge этих недостатков не имеет , abi (?), 17:36 , 13-Апр-20, (18)

С фигали , Аноним (22), 17:45 , 13-Апр-20, (22)
ты думаешь у них разные клумбы в цветочнике по имени ядро , Аноним (4), 17:51 , 13-Апр-20, (24) –3

В цветнике Цветочник это дяденька такой, цветы продаёт , ААА (?), 22:23 , 13-Апр-20, (59) +6
Клумба в виде netgraph то одна, цветочки абсолютно разные Одни пыльцу и мед пче, bOOster (ok), 09:05 , 17-Апр-20, (174)
Убогие линукс последователи никак врубиться не могут - что сетевая подсистема Fr, bOOster (ok), 09:08 , 17-Апр-20, (175)

жаль, что tuntap на данный момент имеет те же проблемы, как написал в рассылке k, Аноним (4), 21:10 , 14-Апр-20, (129)

Подскажите, почему llvm всегда генерирует дефективный код даже на amd64 Ведь ск, Аноним (86), 16:45 , 13-Апр-20, (5) –4

Пруфы Без них просто наброс фанатика GPL , Аноним (6), 16:51 , 13-Апр-20, (6) +3

Не, не, поймите правильно, я не говорю что гцц идеален У него просто астрономич, Аноним (86), 17:00 , 13-Апр-20, (9) –6

Столько текста и всё зря Если нет внятного аргумента, а лишь невнятные отсылки,, Аноним (6), 17:10 , 13-Апр-20, (12) +10

А смысл Я ничего не обсираю, это общеизвестная общепринятая информация Вон в с, Аноним (86), 17:18 , 13-Апр-20, (14) –4

Ссылочку на тот тред, пожалуйста , Аноним (6), 17:24 , 13-Апр-20, (16)

Как Поисковики не индексируют, поиска тут нет Вся конкурентоспособность сводит, Аноним (86), 17:41 , 13-Апр-20, (20)

Индексируют Запрос вида site opennet ru запрос, Аноним (6), 20:15 , 13-Апр-20, (49)

По-моему там только новости, не комменты , Аноним (86), 20:37 , 13-Апр-20, (52)

В гугле ищи , Аноним (6), 21:16 , 13-Апр-20, (57)

То есть, от разработки вы далеки бесконечно , TheFotoMag (ok), 18:41 , 13-Апр-20, (37) +1

Вы, видимо, ещё дальше -- я там увидел аргумент про отсутствие достаточной диа, Аноним (86), 19:05 , 13-Апр-20, (41)

Но пруфов не будет, ведь это знают все https www phoronix com scan php page ar, анонн (ok), 17:14 , 13-Апр-20, (13) –1

Тест того как дистры работают на процессоре AMD 3970x Тем более там везде разны, Аноним (7), 17:54 , 13-Апр-20, (25)

Ну он просто увидел картинку, где жаба собранная шлангом на любимой десяточке вп, Аноним (86), 17:58 , 13-Апр-20, (28) +1

_моей_ любимой десяточки там нет - моя любимая десяточка уже EoL Поэтому у меня, анонн (ok), 18:22 , 13-Апр-20, (34) +2

И Что там писалось Вот контрпример А больше влет и не гуглится - несмотря на , анонн (ok), 18:16 , 13-Апр-20, (32)

Тестил как-то на фре порты, собранные разными компиляторами, и с разными оптимиз, Аноним (31), 18:16 , 13-Апр-20, (31)

Вон я там ссылку привёл Шланг никогда _никогда_ не обходит гцц, если это только, Аноним (86), 18:23 , 13-Апр-20, (35) –2

Шланг содержит ПОЛНОЦЕННЫЕ СРЕДСТВА ДИАГНОСТИКИ и позволяет, в отличие от гцц с , TheFotoMag (ok), 18:46 , 13-Апр-20, (39) –2

Лол Что это ещё за фантазии Оно появилось в гцц лет 10 назад, сразу после шлан, Аноним (86), 19:02 , 13-Апр-20, (40)

Понятно И гцц, и шланг ты видел на картинке , TheFotoMag (ok), 20:50 , 13-Апр-20, (54)

Угу, кончено Оно теперь даже говорит в гцц , что ты забыл, и на что надо испра, Аноним (86), 21:00 , 13-Апр-20, (56)

Сходи и посмотри на ссылку ещё раз clang там обходит gcc, в табличке написано , Ordu (ok), 23:03 , 13-Апр-20, (60)

Да не, там история большого факапа в табличке, можно было со значительно большей, Аноним (86), 23:13 , 13-Апр-20, (62)

Эмм Что за факап Что различия намекают Если табличка противоречит чистой ре, Ordu (ok), 23:39 , 13-Апр-20, (63) +1

Автор чёт сравнивал-сравнивал, рассуждал, но поленился заглянуть в ассемблер Св, Аноним (86), 07:35 , 14-Апр-20, (70)

Если бы он заглянул в ассемблер, то изменились бы цифры в табличке Или что бы с, Ordu (ok), 08:41 , 14-Апр-20, (72)

Я не знаю, чем там занимается llvm Я вижу только ассемблер, который он генериру, Аноним (86), 09:35 , 14-Апр-20, (75)

Не, всё чуть сложнее Низкоуровневая оптимизация, как и любая оптимизация, совер, Ordu (ok), 20:29 , 14-Апр-20, (128) +1
Всё как раз предельно просто Все вопросы к автору jq, я не могу его ускорить Р, Аноним (86), 21:21 , 14-Апр-20, (130)
Если физически невозможно, не нарушая условия, то можно даже не заморачиваться н, Ordu (ok), 22:54 , 14-Апр-20, (135)
Не низкоуровневая оптимизация, самая обычная 20 секунд превращаются в 12 пересб, Аноним (86), 23:38 , 14-Апр-20, (138)
Эмм, ты нашёл какие-то таблетки от когнитивного диссонанса Или как тебе удалось, Ordu (ok), 00:40 , 15-Апр-20, (139)
Смари Делаешь файл с 500 строк в формате типа такого у меня его генерирует sed, Аноним (86), 08:45 , 15-Апр-20, (143)
Я думал ты стебёшься, но когда увидел, что вытянутый с github а актуальный комми, Ordu (ok), 11:28 , 15-Апр-20, (148)
Да не, нормально версия в ебилде точно такая же не, никаких онигурум конечно, Аноним (86), 12:43 , 15-Апр-20, (152)
Нет json парсится в хеш-таблички, поиск в хештабличке и вставка туда элемента -, Ordu (ok), 19:39 , 15-Апр-20, (157)
Так ведь задача была добавить в жсон, потому что это бд на диске -- жсон Всё , Аноним (86), 21:33 , 15-Апр-20, (159)
Eval Хотя завести список keys, список key1items, потом присваивать уже key1it, Аноним (86), 21:37 , 15-Апр-20, (160)
Я почитал ман к jq, и написал тебе скрипт, который просто работает jq -c echo, Ordu (ok), 20:44 , 15-Апр-20, (158)
Хех, да, отлично работает Я так уже делал где-то, не тут real 0m0 123suser , Аноним (86), 22:54 , 15-Апр-20, (162)
Не сомневаюсь Но исходно я ввязался в этот разговор, потому как ты сказал, что , Ordu (ok), 23:37 , 15-Апр-20, (163)
Ведь практически так и есть, я просто не ожидал такого явного превосходства шлан, Аноним (86), 00:13 , 16-Апр-20, (164)
Размер кода и скорость его выполнения слабо связаны while true скомпилируется, Ordu (ok), 01:20 , 16-Апр-20, (165)
Раздутый код будет быстрее, если это лапша из джампов Или медленнее, если он вн, Аноним (86), 14:50 , 16-Апр-20, (166)
Сам бог велел задействовать sql В ядре, в списке псевдофс, есть RAM-диски , Ordu (ok), 20:14 , 16-Апр-20, (170)
Надо было брать xml вместо json, в 100500 раз быстрее было бы это не точно, фиш, Аноним (86), 21:53 , 16-Апр-20, (173)
Я ещё немного подумал над этим, тут есть огромная проблема Если нужно добавить , Аноним (86), 17:13 , 16-Апр-20, (167)
Ради интереса передал фильтр через временный файл, jq всё равно фейлится, если о, Аноним (86), 21:40 , 16-Апр-20, (172)
Более того, jq обламался ещё на 70кб, так что совсем никуда не годится , Аноним (86), 17:28 , 16-Апр-20, (168)

Сорян, есть обновлённая инфа из проверенных источников На операциях с малыми объ, Аноним (86), 20:07 , 13-Апр-20, (47)

Это кстати для си, с плюсами всё куда интересней может быть , Аноним (86), 20:42 , 13-Апр-20, (53)

Теперь о плохом Вот mediainfo плюсовая программа, весьма тяжёлая и тормозная , Аноним (86), 14:13 , 14-Апр-20, (101)

ПС мои тесты гцц херня скорее всего, там замедляющих харденед флагов по самые , Аноним (86), 18:27 , 14-Апр-20, (115)

Скорее всего скорее всего тут лишнее , Аноним (-), 18:34 , 14-Апр-20, (116)

Не, ну что-то они показывают В частности превосходство гцц над шлангом, а вот с, Аноним (86), 18:48 , 14-Апр-20, (117)

Делают ли 30 погоду Визуально стало очень приятно Прямо очень, а то чутка нап, Аноним (86), 21:57 , 14-Апр-20, (132)

Не дефектный, а с фичами Используя инструмент проприерасов думай как проприерас, Аноним (7), 16:56 , 13-Апр-20, (8) +2
Может потому что аналога LLVM в GCC - немаэ , анонн (ok), 17:06 , 13-Апр-20, (11) –4
А почему никто не жалуется, что в Windows программы не собирают с помощью свобод, slava_kpss (ok), 17:44 , 13-Апр-20, (21) +2

Вообще-то собирают, любой опенсорс и не только всегда им собирался Для навязыва, Аноним (86), 17:54 , 13-Апр-20, (26) –1

Им собирают не потому, что он такой хороший, а вс - плохая Просто, немалое кол, Lex (??), 01:24 , 15-Апр-20, (140) –1

Нет Одни и те же программы собирают msvc и продают за деньги И собирают gcc и , Аноним (86), 08:54 , 15-Апр-20, (144)

Потому что все что надо им собрать нормально собирается , Аноним (7), 17:57 , 13-Апр-20, (27)

Телеметрию , Аноним (31), 22:13 , 13-Апр-20, (58) –1

GCC можно и без телеметрии, а msvc ты без телеметрии от visual studio не обойдеш, Аноним (110), 17:09 , 14-Апр-20, (110)

vulkan построен поверх spir-v что является форком llvm , neAnonim (?), 20:04 , 14-Апр-20, (126)

Eue, даже более того, нвидиевский nvvm тоже llvm я всё ещё собираю гцц по стари, Аноним (86), 21:41 , 14-Апр-20, (131)

А в чем собственно проблема с GCC, ставьте из портов не забывая обновить дерево , Alexey (??), 17:33 , 13-Апр-20, (17)

Так лицензия же, её не включить в base, abi (?), 17:38 , 13-Апр-20, (19)

Зачем он тебе в базе Поставил из портов и собираю базу , Аноним (22), 17:48 , 13-Апр-20, (23)

Так продаваться несолидно , Аноним (30), 18:13 , 13-Апр-20, (30)

Я всё уже много лет собираю на Фрибсд с -O3 и нет проблем , Аноним (29), 18:08 , 13-Апр-20, (29)

Порты Или и систему тоже -О3 кажется даже дает небольшое падение производител, Аноним (31), 18:22 , 13-Апр-20, (33)

И порты и систему Работает быстрее , Аноним (29), 13:55 , 14-Апр-20, (100)

Если вы Настоящий Линуксоид Опеннета, то проблема в недостаточной гибкости вашег, анонн (ok), 19:07 , 13-Апр-20, (42) +7

О отличная новость, ОСь развивается в нужном направление без спешки Очень удобн, Deanon (?), 18:44 , 13-Апр-20, (38) +6

Как там с десктопом Всякие зоомы, и шлаки и скупые запускаются , Аноним (76), 10:07 , 14-Апр-20, (77)

Электрон не осуществляет поддержки фрибсд Все работает на страх и риск бзднутых, Аноним (110), 16:53 , 14-Апр-20, (108) –2
Кто о чем, а пингвиняши о нежно любимых проприетарных зондах , аннон. (?), 18:08 , 14-Апр-20, (114) +4

У тебя реально на десктопе только бздя Просто я как-то не верю А возможность , Аноним (76), 19:01 , 14-Апр-20, (118) –1

Да Это твои проблемы и комплексы Прикинь, если мне действительно нужно будет - я, анонн (ok), 20:09 , 14-Апр-20, (127) +1

Всё пацаны Это начало конца ФриБЗД Отказ от ГНУ это непростительная ошибка и н, Аноним (44), 19:22 , 13-Апр-20, (44) –10

С тех пор, как GNU выгнали Столлмана, они перестали вызывать у меня симпатию , Аноним (61), 23:08 , 13-Апр-20, (61)

Столлмана выгнали не GNU, А FSF , Аноним (65), 00:05 , 14-Апр-20, (65)

В угоду корпорастам , Аноним (46), 20:06 , 13-Апр-20, (46) –3

Как там идет процесс перевода линуксового ядра под GPLv3 , zzz (??), 20:33 , 13-Апр-20, (50) +6

Никак В угоду корпорастам, которые это ядро и развивают , Annoynymous (ok), 20:55 , 13-Апр-20, (55) +10

Да всем в угоду Не каждый в восторге от софта, где лицензия на кучу страниц И бы, iPony129412 (?), 10:25 , 14-Апр-20, (82)

Докер всё там же Прошу понять правильно, клетка не нужна , IdeaFix (ok), 20:37 , 13-Апр-20, (51) –2

На сегодняшний день, если нужен докер - используй линь, если не нужен - спокойно, Аноним (67), 00:18 , 14-Апр-20, (67)
Как в 2000 джейлы появились, так с ними и сейчас все ок Это нативная вещь для F, Anonimous (?), 08:55 , 14-Апр-20, (74) +5

И как в бзд-джейле запустить уже готовый докер-контейнер , Аноним (76), 10:08 , 14-Апр-20, (78) –4

И как в этом вашем дыркере запустить бзд-джейл-контейнеры https bastillebsd or, Аноним (-), 12:29 , 14-Апр-20, (93) +1

Да я и не против бы это сделать, честно Больше возможностей - лучше для меня М, Аноним (76), 19:08 , 14-Апр-20, (120) –2

Ты, наверное, в картер двигателя заливаешь олифу, да , YetAnotherOnanym (ok), 16:33 , 14-Апр-20, (106)

Изначальный вопрос в треде звучал так, между прочим А кому нужен джейл - запустя, Аноним (76), 18:02 , 14-Апр-20, (113) –1

Джейлы не нужны Фрю юзает примерно 0 рынка и под эти нативные реализации полез, IdeaFix (ok), 12:00 , 15-Апр-20, (149) –1

Анонимные опеннетные оналитеки тоже не очень нужны То ли дело портировать для то, Аноним (154), 14:00 , 15-Апр-20, (154)

У докера есть библиотека образов, у бсд есть проблемы Клетка в частности и БСД , IdeaFix (ok), 14:43 , 15-Апр-20, (155) –2

А в огороде есть бузина Ценное мнение от очередного Опеннетного Знатока - то, Аноним (156), 15:51 , 15-Апр-20, (156)

Софт на Go-вне не нужен от слова совсем Докер не исключение , Аноним (81), 10:18 , 14-Апр-20, (81)

Лучше на Go-вне чем на винде , Аноним (84), 11:07 , 14-Апр-20, (84) –1

Докер в БЗДе там же, где и в других ОС, не поддерживающих cgroups нативно Т е , FGSFDS (?), 22:29 , 14-Апр-20, (134)

Т е фрибсд не нужно жаль Так же жаль что по началу докер так лихо втаскивал, IdeaFix (ok), 12:02 , 15-Апр-20, (150) –1

Ну какому-то васяну, в чьей вселенной докер это единственное и самое важное ка, ГабенВул (?), 13:55 , 15-Апр-20, (153) +1

дурачек, которому ты отвечаешь, и в линакс с ним не работает не понятно, зачем, тигар (ok), 08:57 , 20-Апр-20, (181)

Проблемы у MSVC и GCC сходны и видны невооруженным глазом https cloud mail ru, Фанат (?), 00:04 , 14-Апр-20, (64)

Gcc на O3 генерирует очень, очень тормозной и раздутый код, следуя одному ему м, Аноним (86), 15:32 , 14-Апр-20, (105) –1

Это всё здорово, но есть штуки типа этой https reviews freebsd org D21206врод, Ivan_83 (ok), 00:08 , 14-Апр-20, (66)
Редакция эта что-то на двух ноутах даже Х-ы не подняла Линуксы от мала до вел, paulus (ok), 00:57 , 14-Апр-20, (68)

Ой ли На самом деле конфигов ноутов великое множество Потому я своими глазами , G0Dzilla (??), 06:17 , 14-Апр-20, (69) +2

Есть у меня ленивец Е440 На линуксах работал всегда, но ни в одной из БЗДей 10,, Аноним (76), 10:12 , 14-Апр-20, (79) –1

Многие современные производители пользовательской техники немного 171 подзабил, G0Dzilla (??), 17:10 , 14-Апр-20, (111)

Знаешь, нужен Хотя бы мне Наличие альтернатив - всяко лучше, чем отсутствие он, Аноним (76), 19:22 , 14-Апр-20, (124)

Тем, кому нужно, и на QNX соберут рабочее окружение Мой посыл выше был о том, чт, G0Dzilla (ok), 04:31 , 15-Апр-20, (141)
Я сейчас буду телепатствовать, но видимо, по Вашей логике, если у меня на net, IdeaFix (ok), 12:13 , 15-Апр-20, (151)

Согласен, но древняя toshiba с radeon ом как могла не взлететь Может таки пробл, paulus (ok), 22:23 , 14-Апр-20, (133)

зашибись шутишь фрнзи, если что, изначально на базе fbsd была а потом умерла , тигар (ok), 09:01 , 20-Апр-20, (182)

Простой личный пример Дано Ноутбук Dell Inspiron 15 7000 GamingNomadBSD - запус, zshfan (ok), 12:25 , 14-Апр-20, (91) +3

Ubuntu 20 04 стабильная еще не вышла И даже 23 числа когда выйдет по хорошему, Аноним (110), 17:08 , 14-Апр-20, (109)

В Ubuntu вообще надо ждать Некоторые вещи годами Ну чистый дзен , xm (ok), 19:06 , 14-Апр-20, (119)
Ну не соглашусь, убунту 20 04 это лтс, она должна быть вылизана изначально, ибо , zshfan (ok), 06:38 , 15-Апр-20, (142)

Ну молодец Нет Как раз по этому зачастую туда пропихивают что-то по новее, ибо , iPony129412 (?), 09:12 , 15-Апр-20, (145)
Или вот, понятно, что python2 выкинули в Ubuntu - ну не поддерживать же его даль, iPony129412 (?), 09:22 , 15-Апр-20, (146)
Просто пример был изначально неправильный, с неправильными результатами - вот ес, Аноним (-), 10:53 , 15-Апр-20, (147) +1

Это не к вам, а в целом, к свидетелям дефолтных конфигов не ебитесь, поставьте , Аноним (125), 19:24 , 14-Апр-20, (125)

Разработчику NomadBSD в особенности всего наилучшего, лишь бы в комфорте делал с, Аноним (73), 08:44 , 14-Апр-20, (73) +3
Для это поделки фрибсд даже Firefox официальный не выпускают Вывод фря не нужна, Аноним (84), 11:05 , 14-Апр-20, (83) –4

Аноним не осилил pkg install firefox Да, уровень свидетелей святого ядра скат, Dmitry (??), 12:12 , 14-Апр-20, (87) +4

Я Оперу хотел скачать, в интернете мне предложили только линуксулятор, который т, Аноним (86), 12:16 , 14-Апр-20, (88)

Зачему тебе эти хромые сборки и электроды Вот качай нормальную Оперу https ft, Аноним (31), 12:25 , 14-Апр-20, (90)

Не, она конечно нормальная особенно потому что она куда экономней нынешних брау, Аноним (86), 12:36 , 14-Апр-20, (95)

pkg от Васяна который неизвестно что собрал и к фиксам которого Мозилла никакого, Аноним (110), 16:48 , 14-Апр-20, (107) –3

Само дерево портов это часть ОС Это у вас там ядро от Васяна, просто по удачном, Аноним (31), 18:00 , 14-Апр-20, (112) +3

Не в обстоятельствах единых дело Вон ведро от ваших Васянов появилось здесь сле, Аноним (76), 19:18 , 14-Апр-20, (123)

Свидетели ядра и ппа-помоек что-то говорит про васянов Спешите видеть Собираетс, Аноним (136), 23:04 , 14-Апр-20, (136)
Почему сразу неизвестно Зашёл на freshports https www freshports org www fir, KaZaaM4iK (ok), 22:36 , 15-Апр-20, (161) +1

Новости из теплого, лампового 2007 года , аНоним (?), 13:41 , 14-Апр-20, (99) –2

Да уж, ретрограды Ни одного упоминания systemd , Аноним (137), 23:32 , 14-Апр-20, (137) +3

Моя самая любимая ОС кто-бы що не говорил , Аноним (176), 09:18 , 18-Апр-20, (176)
Моя самая любимая ОС кто-бы що не говорил , Сергей (??), 09:18 , 18-Апр-20, (177)
Чето все молчат, а ведь HAMMER от стрекозы - этож идеальная система для десктопа, bOOster (ok), 21:47 , 18-Апр-20, (179)

Файловая система интересная, но сама стрекоза, к сожалению, не может похвастатьс, Аноним (183), 22:29 , 06-Май-20, (183)

Могу подтвердить, что с драйверами во FreeBSD становится лучше Это видно по доб, linuxbuild (ok), 11:53 , 30-Июн-20, (184)

Сообщения [Сортировка по времени | RSS]

2. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +49 +/–

Сообщение от dvz (??), 13-Апр-20, 16:31

Прекрасно. Фряшка развивается, что не может не радовать.

Ответить | Правка | Наверх | Cообщить модератору

7. Скрыто модератором –20 +/–

Сообщение от Аноним (7), 13-Апр-20, 16:55

Судя по характеру обновлений она скорее деградирует. Следующая на свалку после Solaris.

Ответить | Правка | Наверх | Cообщить модератору

10. Скрыто модератором +24 +/–

Сообщение от анонн (ok), 13-Апр-20, 17:05

> Судя по характеру обновлений она скорее деградирует. Следующая на свалку после Solaris.
Что, не обновили в очередной раз CoC? Не решили единым порывом вычистить сорцы от факов и заменить списки рассылок модно-молодежным смузи с тоннами JS, бесконечным скроллингом и прочими "плюшками"?
Ну точно деградируют!

Ответить | Правка | Наверх | Cообщить модератору

76. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –4 +/–

Сообщение от Аноним (76), 14-Апр-20, 10:02

Ну да, интеловское видео перетащили из линукса. ZoL тоже. Заживём.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

85. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +6 +/–

Сообщение от Аноним (85), 14-Апр-20, 11:52

> Ну да, интеловское видео перетащили из линукса.
Вообще-то из интеля. Или загружаемые чере NDISWrapper дрова у вас "из винды утащены!".
> ZoL тоже.
Но только у опеннетчиков на опеннете. У них тут своя, опеннетная реальность.

Ответить | Правка | Наверх | Cообщить модератору

86. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –3 +/–

Сообщение от Аноним (86), 14-Апр-20, 12:00

>NDISWrapper
Ммм как бы тебе сообщить это, но даже когда оно было актуально, оно не очень прекрасно работало. И разве оно не заггружалось через прослойку в неизменном виде? У вас там что, дрова тоже через линуксулятор работают? 32 бита онли?

Ответить | Правка | Наверх | Cообщить модератору

89. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +2 +/–

Сообщение от Аноним (-), 14-Апр-20, 12:18

>>NDISWrapper
> Ммм как бы тебе сообщить это, но даже когда оно было актуально, оно не очень прекрасно работало.
Ммм, как бы тебе сообщить это: даже если это так, то ... это ровным счетом ничего не меняет.
> И разве оно не заггружалось через прослойку в неизменном виде?
Принцип тот же - великодушно выпущенные (и зачастую креноватые и доводимые до "gpu hung всего лишь раз в неделю! Ура!" состояния иногда по нескольку лет) для пингвинят дрова от интеля загружается через враппер - потому что менять там что-то даже сами интеловцы не очень любят.
> У вас там что, дрова тоже через линуксулятор работают? 32 бита онли?
Казалось бы, причем тут линуксулятор, да еще и 32 бита?

Ответить | Правка | Наверх | Cообщить модератору

92. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –3 +/–

Сообщение от Аноним (86), 14-Апр-20, 12:28

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

Ответить | Правка | Наверх | Cообщить модератору

96. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +3 +/–

Сообщение от Аноним (-), 14-Апр-20, 12:37

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

Ответить | Правка | Наверх | Cообщить модератору

97. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –2 +/–

Сообщение от Аноним (86), 14-Апр-20, 12:47

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

Ответить | Правка | Наверх | Cообщить модератору

102. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (102), 14-Апр-20, 14:25

>> И у кого интель их слямзил?
> При чём тут интел, когда он абстрактный?
В вакууме, сферический?
> Зато анониму надо обязательно приплести неревантный треш из каменного века, из тех времён, когда драйверов с исходниками производители принципиально не выпускали.
Если аноним опеннета чего-то не понял, то это не пробел в знаниях опеннетного анонма (ибо опеннетные анонимы знают все-все-все), а просто "нерелевантный треш". Именно так и никак не иначе!

Ответить | Правка | Наверх | Cообщить модератору

4. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +1 +/–

Сообщение от Аноним (4), 13-Апр-20, 16:42

из всего списка меня больше всего волнует if_bridge

Ответить | Правка | Наверх | Cообщить модератору

18. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от abi (?), 13-Апр-20, 17:36

ng_bridge этих недостатков не имеет.

Ответить | Правка | Наверх | Cообщить модератору

22. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (22), 13-Апр-20, 17:45

С фигали?

Ответить | Правка | Наверх | Cообщить модератору

24. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –3 +/–

Сообщение от Аноним (4), 13-Апр-20, 17:51

ты думаешь у них разные клумбы в цветочнике по имени ядро?

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

59. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +6 +/–

Сообщение от ААА (?), 13-Апр-20, 22:23

В цветнике.
Цветочник это дяденька такой, цветы продаёт.

Ответить | Правка | Наверх | Cообщить модератору

174. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от bOOster (ok), 17-Апр-20, 09:05

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

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

175. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от bOOster (ok), 17-Апр-20, 09:08

Убогие линукс последователи никак врубиться не могут - что сетевая подсистема FreeBSD не работает в общем ядре как таковом. к Ядру прицеплен netgraph а дальше уже стэк протоколов.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

129. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (4), 14-Апр-20, 21:10

жаль, что tuntap на данный момент имеет те же проблемы, как написал в рассылке kp@

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –4 +/–

Сообщение от Аноним (86), 13-Апр-20, 16:45

Подскажите, почему llvm всегда генерирует дефективный код даже на amd64? Ведь сколько лет его разрабатывают, почти что сколько и gcc… Что не логично, так это то, что его и в вулкан пихать пытаются. Я хочу логичное объяснение, почему популярный у проприерасов и всяческих противников свободы компиялтор такое убожество.

Ответить | Правка | Наверх | Cообщить модератору

6. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +3 +/–

Сообщение от Аноним (6), 13-Апр-20, 16:51

Пруфы? Без них просто наброс фанатика GPL.

Ответить | Правка | Наверх | Cообщить модератору

9. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –6 +/–

Сообщение от Аноним (86), 13-Апр-20, 17:00

Не, не, поймите правильно, я не говорю что гцц идеален. У него просто астрономическое количество регрессий и багов выплывает (регулярно), а производительность что-то там на 30% ниже проприетарного интеловского компилятора (который ммм адок ещё тот, насколько мне известно, да и вопросы совместимости есть). Но для свободного продукта это нормально, он хотя бы стабильно лучше "стандарта" msvc. А тут продукт любимый всяческими корпорациями, а код стабильно дерьмовый продуцирует. Под стабильно я понимаю стабильно. Это регулярно обсуждается. Если хочется хомячковый аргумент, то для среднего по больнице можно на мандриву посмотреть, она в любом попугаеметре будет проигрывать.

Ответить | Правка | Наверх | Cообщить модератору

12. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +10 +/–

Сообщение от Аноним (6), 13-Апр-20, 17:10

Столько текста и всё зря. Если нет внятного аргумента, а лишь невнятные отсылки, не стоило обсирать.

Ответить | Правка | Наверх | Cообщить модератору

14. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –4 +/–

Сообщение от Аноним (86), 13-Апр-20, 17:18

А смысл? Я ничего не обсираю, это общеизвестная общепринятая информация. Вон в соседнем треде разбирали генерируемый им ассемблер. Он может нагенерировать лапшу из переходов, но не может выбрать нормальные инструкции. А "срезать углы" замечательно и gcc может, pgo просто сказка.

Ответить | Правка | Наверх | Cообщить модератору

16. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (6), 13-Апр-20, 17:24

Ссылочку на тот тред, пожалуйста.

Ответить | Правка | Наверх | Cообщить модератору

20. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 13-Апр-20, 17:41

Как? Поисковики не индексируют, поиска тут нет. Вся конкурентоспособность сводится к способности генерировать лапшу из переходов. Но лапша эта может оказаться совершенно не эффективной в зависимости от данных.
Вот какая-то хомячковая статья откуда-то оттуда же, может для иллюстрации сойдёт https://habr.com/ru/post/483864/

Ответить | Правка | Наверх | Cообщить модератору

49. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (6), 13-Апр-20, 20:15

>Поисковики не индексируют
Индексируют.
Запрос вида:
site:opennet.ru запрос

Ответить | Правка | Наверх | Cообщить модератору

52. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 13-Апр-20, 20:37

По-моему там только новости, не комменты.

Ответить | Правка | Наверх | Cообщить модератору

57. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (6), 13-Апр-20, 21:16

В гугле ищи.

Ответить | Правка | Наверх | Cообщить модератору

37. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +1 +/–

Сообщение от TheFotoMag (ok), 13-Апр-20, 18:41

>> Я ничего не обсираю, это общеизвестная общепринятая информация
То есть, от разработки вы далеки бесконечно?

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

41. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 13-Апр-20, 19:05

Вы, видимо, ещё дальше -- я там увидел "аргумент" про отсутствие достаточной диагностики в гцц, хех.

Ответить | Правка | Наверх | Cообщить модератору

13. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от анонн (ok), 13-Апр-20, 17:14

>  А тут продукт любимый всяческими корпорациями, а код стабильно дерьмовый
> продуцирует. Под стабильно я понимаю стабильно. Это регулярно обсуждается. Если хочется хомячковый аргумент, то для среднего по больнице можно на мандриву посмотреть,
> она в любом попугаеметре будет проигрывать.
Но пруфов не будет, ведь это знают все!
https://www.phoronix.com/scan.php?page=article&item=openmand...
Ой.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

25. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (7), 13-Апр-20, 17:54

Тест того как дистры работают на процессоре AMD 3970x? Тем более там везде разные победители.
Вот что интересно так это даст ли какой то прирост компиляция про помощи amd'шного компилятора aocc который тоже на llvm или нет.

Ответить | Правка | Наверх | Cообщить модератору

28. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +1 +/–

Сообщение от Аноним (86), 13-Апр-20, 17:58

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

Ответить | Правка | Наверх | Cообщить модератору

34. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +2 +/–

Сообщение от анонн (ok), 13-Апр-20, 18:22

> Ну он просто увидел картинку, где жаба собранная шлангом на любимой десяточке
_моей_ любимой десяточки там нет - моя любимая десяточка уже EoL. Поэтому у меня любимая двенадцаточка. Которой там, впрочем, тоже нет.
Или имелась в виду "любимая десяточка" анонима? Странно, я-то думал что аноним больше по макоси.

> впервые в чём-то победила и потёк. Подумать о результатах уже слишком сложно.
Смотрим глазами:
> msec, Fewer Is Better
> OpenMandriva 4.1 Znver  2585
> OpenMandriva 4.1 x86_64  2639
> Windows 10 Enterprise  2999
> Windows 10 Pro  3044
.
> DaCapo Benchmark v9.12-MR1
> Java Test: Jython
> msec, Fewer Is Better
> Clear Linux   3513
> Manjaro Linux 19.0.  3623
> Windows 10 Enterprise 4633
Т.е. ты, балаболка анонимная, не то что пруфануть - даже картнику толком посмотреть не осилил?

Ответить | Правка | Наверх | Cообщить модератору

32. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от анонн (ok), 13-Апр-20, 18:16

> Тест того как дистры работают на процессоре AMD 3970x? Тем более там
> везде разные победители.
И? Что там писалось?
> она в любом попугаеметре будет проигрывать.
Вот контрпример. А больше влет и не гуглится - несмотря на горячие заверения "это знают все!"

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

31. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (31), 13-Апр-20, 18:16

Тестил как-то на фре порты, собранные разными компиляторами, и с разными оптимизациями и без.
Во-первых разница между всеми комбинациями была небольшая, 1-3%
Сказочки про 30143% не рассказывай взятые из головы.
Во-вторых LLVM как раз таки на эти пару процентов обгонял GCC. Разумеется, это справедливо только для того конкретного софта и системы. В каких-то случаях и флаги оптимизации оправданы, в каких-то и GCC обходит, не расстраивайся.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

35. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –2 +/–

Сообщение от Аноним (86), 13-Апр-20, 18:23

Вон я там ссылку привёл. Шланг никогда _никогда_ не обходит гцц, если это только не баг генерации или подобное. И разница там на 3%, ближе к 20 (иногда и все 300).
>В каких-то случаях и флаги оптимизации оправданы
В любых случаях pgo, включающий необходимые оптимизации в нужных местах, мешает шланг с землёй. Ну если задача вообще зависит от качества генерации кода.

Ответить | Правка | Наверх | Cообщить модератору

39. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –2 +/–

Сообщение от TheFotoMag (ok), 13-Апр-20, 18:46

>> Шланг никогда _никогда_ не обходит гцц
Шланг содержит ПОЛНОЦЕННЫЕ СРЕДСТВА ДИАГНОСТИКИ и позволяет, в отличие от гцц с коркой «рантайм еррор, стоппед», получать сообщения «ошибка приведения типов в функции имя функции строка 6778 аргумент блаблабла»
Но вы этого никогда не узнаете, поскольку с кодом не работаете. В связи с этим, зачем и о чем вы тут высказываетесь?

Ответить | Правка | Наверх | Cообщить модератору

40. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 13-Апр-20, 19:02

Лол. Что это ещё за фантазии? Оно появилось в гцц лет 10 назад, сразу после шланга (я нигде не говорил, что от шланга нет пользы).

Ответить | Правка | Наверх | Cообщить модератору

54. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от TheFotoMag (ok), 13-Апр-20, 20:50

> Лол. Что это ещё за фантазии? Оно появилось в гцц лет 10
> назад, сразу после шланга (я нигде не говорил, что от шланга
> нет пользы).
Понятно. И гцц, и шланг ты видел на картинке.

Ответить | Правка | Наверх | Cообщить модератору

56. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 13-Апр-20, 21:00

> Понятно. И гцц, и шланг ты видел на картинке.
Угу, кончено. Оно теперь даже говорит (в гцц), что ты забыл, и на что надо исправить. Лютая дичь, как по мне. Но я думаю тем, кто привык к msvc, шланг действительно кажется чем-то волшебным. Диагностические средства (рантайм, не статистические) у них одинаковые насколько я помню, +- парити поддерживают.
Из ярких преимуществ гцц, помимо нормально генерируемого кода... Я вот не знаю как билдить любую программу совершенно без проблем с пго в шланге. В гцц это задача совершенно элементарная.

Ответить | Правка | Наверх | Cообщить модератору

60. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ordu (ok), 13-Апр-20, 23:03

> Вон я там ссылку привёл. Шланг никогда _никогда_ не обходит гцц
Сходи и посмотри на ссылку ещё раз. clang там обходит gcc, в табличке написано. g++ обходит clang++, но я это не смог проверить, поскольку C++ код автор забыл выложить. Он утверждает что g++ быстрее, но там же в примечаниях он указывает, что перестановка сравнений в в коде приводит к тому, что clang++ оказывается быстрее g++.
То есть твои "никогда _никогда_" -- это прямое следствие твоего нежелания видеть свидетельства тому, что ты не прав.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

62. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 13-Апр-20, 23:13

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

Ответить | Правка | Наверх | Cообщить модератору

63. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +1 +/–

Сообщение от Ordu (ok), 13-Апр-20, 23:39

> Да не, там история большого факапа в табличке, можно было со значительно
> большей пользой время на порнхаб потратить. Ну как бы такие различия
> намекают.
Эмм... Что за факап? Что различия намекают? Если табличка противоречит чистой религиозной вере, то тем хуже для таблички? Или ты к тому, что это история факапа gcc?
Увидев в табличке rust, я заглянул в код и увидел там unsafe, используемый ради ухода от проверок на выход за границы массивов. Мне стало интересно что будет, если убрать unsafe и вернуть проверки, и поэтому я скачал C'шный вариант и rust'овый, а скачав я не поленился в разных вариантах их скомпилировать. clang++ и gcc++ я попытался использовать на сишном сорце, но они ругаются из-за сишных приведений типов указателей -- это несложно пофиксить, но... явно это не тот код, которым автор тестировал C++, так что я не стал париться.
И выходит что-то типа:
clang: 1.12с
rust-unsafe: 1.18с
gcc: 1.27с
rust: 1.49с
Это плюс-минус то, что в табличке. Плюс-минус километр, конечно, но учитывая отличающиеся версии компиляторов и разное железо, вполне объяснимая погрешность.

Ответить | Правка | Наверх | Cообщить модератору

70. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 07:35

Автор чёт сравнивал-сравнивал, рассуждал, но поленился заглянуть в ассемблер. Свои рассуждения по поводу гцц я выразил в #47, ознакомьтесь.

Ответить | Правка | Наверх | Cообщить модератору

72. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ordu (ok), 14-Апр-20, 08:41

> Автор чёт сравнивал-сравнивал, рассуждал, но поленился заглянуть в ассемблер.
Если бы он заглянул в ассемблер, то изменились бы цифры в табличке? Или что бы случилось?
> Свои рассуждения по поводу гцц я выразил в #47, ознакомьтесь.
Я читал. Не интересно. Вот если бы ты вскрыл бы логику и объяснил бы происходящее не словами "запутался в переходах", а в стиле "llvm пытается сделать то-то и то-то, чтобы конвееры были бы забиты работой, а получается сё-то и сё-то, и поэтому половина конвееров простаивает в ожидании", это могло бы быть интересно. А так глянуть на вывод компиляции в -S, прикинуть в уме гистограмму используемых инструкций и строить рассуждения на этом... я не вижу глубинного смысла, и не интересно.
При этом совершенно непонятно, что ты сравниваешь. "Конкатенации строк" -- что за строки и как ты их конкатенируешь? C'шные строки с терминатором в конце и неизвестным заранее размером? Ты их копируешь ручками в стиле while(*src) *(dst++) = *(src++)? Или ты используешь функции из string.h? Или ты используешь builtin'ы компилятора? Что с чем ты вообще сравниваешь?
Автор статьи хоть и не заглядывал в ассемблер, но по-крайней мере привёл исходный код того, что он сравнивал. По-крайней мере вопросов "что он сравнивал" не возникает, могут быть вопросы лишь о том, почему такие результаты. В твоём случае до вопросов к результатам дело не доходит, потому что нет ответа на вопросы об исходном коде. Но при этом, ты почему-то считаешь, что это с твоими сравнениями всё ок, а у автора статьи факап. Точно не наоборот?

Ответить | Правка | Наверх | Cообщить модератору

75. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 09:35

Я не знаю, чем там занимается llvm. Я вижу только ассемблер, который он генерирует. И он генерирует раздутый файл, который на типичном кейсе работает значительно быстрее гцц.
Просто моя бытовая задача, не синтетика: распарсить текст (баш) и добавить его в жсон (jq) для дальнейшей обработки. Что и как тут совершенно не важно, важно то, что 500 строк добавляются до 20 секунд в зависимости от успешности компилятора. И лишние секунды начианают напрягать достаточно быстро.

Ответить | Правка | Наверх | Cообщить модератору

128. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +1 +/–

Сообщение от Ordu (ok), 14-Апр-20, 20:29

> Просто моя бытовая задача, не синтетика: распарсить текст (баш) и добавить его
> в жсон (jq) для дальнейшей обработки. Что и как тут совершенно
> не важно, важно то, что 500 строк добавляются до 20 секунд
> в зависимости от успешности компилятора.
Не, всё чуть сложнее. Низкоуровневая оптимизация, как и любая оптимизация, совершенно бессмысленна в отрыве от задачи. Любые попытки выделить маленький кусочек из задачи и оптимизировать его будут бессмысленны, до того как ты не прошёлся оптимизацией по задаче в целом, не выбрал алгоритмы и структуры данных, и до того, как ты не провёл профилирование и не выяснил, что эта подзадачка поедает у тебя хотя бы процентов 10 времени.
Когда ты выдираешь из своей несинтетичной бытовой задачи маленькую подзадачку, то эта твоя маленькая подзадачка становится той самой синтетикой. Внутри strcpy есть условный переход, из-за него всё происходит не так быстро, как могло бы. Если ты работаешь с C'шными строками, то процессор копируя его постоянно лочится на этом условном переходе, и по сути у тебя работает один конвеер, и далеко не в полную силу.
Если ты этот strcat срастишь со своим лексером, чтобы они стали единым целым, то есть шансы, что тебе удастся сделать это не добавив к лексеру ни единого условного перехода. Таким образом "пустой" прогон лексера (который обходит все синтаксические конструкции но ничего не делает) будет отличаться от прогона в котором лексер копирует полезные строки куда-то на {0-1 такт} умножить на {количество скопированных символов}. То есть реально при некотором везении его скорость работы будет неотличима от пустого прогона, то есть ты получишь _бесплатный_ strcat. В реальности, правда, будет чуть больше кеша использоваться и надо полагать будут почаще промахи поисходить, и может в результате твой лексер будет под нагрузкой работать на 1% дольше, чем без неё.
Если ты правильным образом подберёшь место куда лексеру надо копировать char'ы -- можно ведь сделать так, чтобы он сразу копировал их в строки вида: "name" = "value", то затем тебе останется взять эти строки и скормить их сисколлу writev. Если тебе удастся прям сразу собирать одну большую строку финального json, то тебе даже не придётся доковыриваться до сисколлов, и ты сможешь сделать это аналогом сисколла write который есть в стандартной библиотеки практически любого языка.
Навскидку я скажу вот что: если у тебя 500 строк добавляются 20 секунд, то там что-то серьёзно не так с парсером и даже если ты проведёшь все низкоуровневые оптимизации, ты сэкономишь допустим 50% времени, строки будут добавляться 10 секунд, и всё равно эти числа будут указывать на то, что с парсером что-то серьёзно не так. То есть на несколько порядков не так. Или может у тебя многие гигабайты bash-кода, и нужные строки там попадаются редко и таким образом у тебя бутылочным горлышком оказывается ввод/вывод, а не парсинг и генерация json?

Ответить | Правка | Наверх | Cообщить модератору

130. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 21:21

Всё как раз предельно просто. Все вопросы к автору jq, я не могу его ускорить. Разве что bison внезапно волшебным образом ускорится, подождём.
PS. Если мне надо будет быстрее, я возьму тот же питон, правда я сомневаюсь, что станет значительно быстрее. Да и дело то совсем не в этом. Это вся задача целиком, единственная цель тут - взять сотни жсона и добавить их к другим жсонам. В реальной версии добавляется ещё произвольные запросы жсона из тысяч жсона и мешок регулярок, копированием строк тут не обойдёшься. Быстрее не будет, потому что быстрее физически невозможно, не нарушая условия. В питоне можно разве что можно избавится от запуска процесса на каждую строку.

Ответить | Правка | Наверх | Cообщить модератору

135. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ordu (ok), 14-Апр-20, 22:54

> Быстрее не будет, потому что быстрее физически невозможно, не нарушая условия.
Если физически невозможно, не нарушая условия, то можно даже не заморачиваться на оптимизацию. Оптимизация возможна только тогда, когда есть физическая возможность.
> Все вопросы к автору jq, я не могу его ускорить.
Ты не пробовал. Возьми профайлер и выясни почему он тормозит. Когда ты поймёшь почему, тогда можно будет рассуждать о существовании или несуществовании возможности ускорить.
Хотя, с учётом дополнительной капли информации о задаче, которую ты выдал, я уже даже не знаю, что предположить. Я начинаю подозревать, что проблема в твоём коде: bison никоим образом нельзя назвать генератором самых быстрых парсеров, но всё же его парсеры неплохи в смысле производительности. Можно допустить что jq использует bison как-то не так, но мне это кажется менее вероятным, чем то, что ты jq используешь как-то не так. И если делать ставки, то (учитывая "запросы жсона из тысяч жсона и мешок регулярок") я бы поставил на то, что ты решаешь задачу на уровне json'а, хотя следовало бы решать её на уровне данных -- то есть парсить json в данные, работать с данными, а потом сериализовать эти данные в json. Реально попробуй весь этот json складывать в sqlite, и потом выполнять основной процессинг данных на языке программирования SQL. Кстати, если я угадал в чём дело, то python может оказаться быстрее C. Если я прав в своих предположениях, то можно и без sql сделать, но там тебе ручками придётся создавать индексы, жонглировать хеш-табличками -- в C примерно так же сложно, как пользоваться SQL, поэтому в любом случае лучше взять python, ruby, go, rust, или C++ на крайняк... что-нибудь из этого списка взять и сделать там.
Я повторю ещё раз: 20 секунд на 500 строк -- это уровень производительности пристойный для 70-х годов. Если низкоуровневая оптимизация компилятора применяемая к strcpy может уменьшить эти 20 секунд до 19, то вместо того, чтобы перебирать компиляторы и флаги к ним, тебе следует объявить strcpy своим личным врагом и выкинуть из программы хотя бы 90% вызовов strcpy, заменив их чем-нибудь другим. Тогда твои 20 секунд уменьшатся сразу до 5 секунд или даже вообще превратятся в виртуальный 0 секунд, потому как твоя психика будет воспринимать время работы программы как моментальное.

Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

138. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 23:38

Не низкоуровневая оптимизация, самая обычная. 20 секунд превращаются в 12 пересборкой одного jq (или сменой компилятора который его собирает, лол). В том и дело, что не тормозит. Я решаю задачу максимально быстро, используя все фишечки баша, и работаю я естественно с данными (которые все в памяти), которые для баша просто текст (это не текст, а текст, списки, и много чего ещё, но башу об этом знать не обязательно), но жсон-то прибавляет jq и тут ничего не сделать, разве что заменить его на что-нибудь, что будет исключительно складывать жсон (jq умеет многое, и часть из этого я использую помимо наиболее частой операции сложения). Смысла в этом не много. Или добавить поддержку жсона в баш (на си) или ещё лучше примитивно разбирать и складывать жсон, но это не очень красиво будет.
Вообще, это нормально для баша -- пересылать одни и те же байты туда-сюда и копировать тысячу раз, это всё в порядке вещей. Я могу взять вместо жсона что-нибудь, что будет висеть в памяти, но быстрее оно не будет (пока жсон не разросся до миллионов значений, не актуально). Просто сравнил на кейсе, который достаточно медленно и печально отрабатывает, и шланг оказался где-то пригодным.
Или вот другая задача, более примитивная: гигабайт чисел можно сложить в баше очень быстро, или можно сделать это значительно медленней сотней способов (более универсальных при этом). Можно попробовать поскладывать несколько гигов, и сравнить компиляторы. Но это уже действительно будет синтетика, что интересного в сложении чисел?

Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

139. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ordu (ok), 15-Апр-20, 00:40

> Я решаю задачу максимально быстро,
> используя все фишечки баша,
> это нормально для баша -- пересылать одни и те же байты ... тысячу раз
Эмм, ты нашёл какие-то таблетки от когнитивного диссонанса? Или как тебе удалось, при подобном уровне внутренних конфликтов, избежать принудительной изоляции от интернета?
Вообще, я тут подумал, что если тебя тянет на олдскульные решения, то посмотри на R. Там мозголомность синтаксиса подстать башу, но он заточен на работу с табличками в памяти, и этот его синтаксис даёт плюс-минус те же возможности, что и хипстерский SQL. И да, R создан чтобы работать в виде командной строки, помимо этого к нему есть обёртки, чтобы помимо командной строки у тебя были бы всякие другие плюшки, которые может предоставить gui. А ещё R -- это обработка данных, оттуда один шаг до хайпа бигдаты.
Если же тебе важнее результат, а не олдскульность решения, и бигдата тебе неинтересна, то, реально, глянь на python или Go. Их освоить проще чем bash, и они в отличие от bash заточены на то, чтобы обрабатывать данные в памяти. Баш хорош только для того, чтобы вызывать другие программы, которые будут обрабатывать данные в памяти.
> гигабайт чисел можно сложить в баше очень быстро, или можно сделать это значительно медленней сотней способов
Эмм... Я не думаю, что можно сделать медленнее чем в баше. То есть понятно, что скорость упрётся в скорость используемой реализации чисел произвольной точности, но либо bash не повлияет существенно на скорость, либо он её снизит. Если точный результат не нужен, то можно попробовать разбить гигабайт на килобайты, каждый сложить в отдельный float, получить миллион флоатов, разбить их на куски по 1000 флоатов, просуммировать каждый, получить несколько сотен флоатов и уже сложить их -- точность результата будет не фонтан, но по-крайней мере не придётся упереться в насыщение, когда добавление очередного положительного числа к сумме не меняет сумму. Но это варианты не совсем для bash'а: можно извернуться при помощи какого-нибудь там parallel, чтобы удобно разбивать задачу на подзадачи, да ещё и все ядра задействовать при этом, но проще и быстрее написать на C, и результат будет быстрее. Хотя если связаться с pthreads и раскидывать задачи по потокам, то сумма времени написания кода и выполнения его скорее всего окажется больше, чем в случае с bash и parallel.
> 20 секунд превращаются в 12 пересборкой одного jq (или сменой компилятора который его собирает, лол) [...] сравнил на кейсе, который достаточно медленно и печально отрабатывает
Если у тебя есть возможность выложить этот интересный кейс, чтобы я мог бы его воспроизвести, то я буду очень благодарен. Реально интересно: я подозреваю, что это глупость какая-то, то ли в ./configure, то ли ещё где-то. Но не факт: я бы скорее ожидал, что глупость такого рода будет давать пенальти к производительности при использовании llvm, потому как он менее популярен.

Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

143. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 15-Апр-20, 08:45

Смари. Делаешь файл с 500 строк в формате типа такого (у меня его генерирует sed), каждая строка должна выглядеть так и начинаться с точки, иначе мы её пропускаем, key будет разный (иначе в чём смысл), но может и повторяться:

."key" += {"item":["value"]}
Более сложная структура не нужна.
Потом построчно скармливаешь это jq по типу такого

data="{}"
faileddata=""
while read object; do
    if [[ '."' != "${object::2}" ]];then
        faileddata+="${object}"$'\n';
        continue;
    fi
    data=$(jq --sort-keys -c "${object}"<<<"${data}")
done<<<"$srcdata"
Учить как собирать программы я не буду, у меня генту и я просто переопределяю CC/CXX и флаги, а потом собираю как обычно пакетным менеджером. Можно наверно вручную покопаться в мейкфайле.
ПС и пожалуйста, хватит рассказывать, что мне делать, лучше ускорь jq с любимым strcpy. Всего оверхэда тут на вызов процессов, потому что средствами самого баша не решаемо (sed можно заменить, но тормозит-то не он). ППС сразу говорю, если убрать сортировку, сколько-нибудь быстрее не будет, а пробелы уже убраны (-0.001с ориентировочно).

Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

148. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ordu (ok), 15-Апр-20, 11:28

> Учить как собирать программы я не буду
Я думал ты стебёшься, но когда увидел, что вытянутый с github'а актуальный коммит в master не собирается, потому как там Makefile'ы поломаны, понял что нет. Ппц. Что за быдлософт?
> у меня генту и я просто переопределяю CC/CXX и флаги, а потом собираю как обычно пакетным
> менеджером.
А, да, точно, про пакетный менагер я чёт забыл. Там скорее всего подобран такой коммит из git, который собирается. Ты собирал с USE=oniguruma или без него? Влом разбираться, что это такое вообще. Поставил без этого аниме.
> Можно наверно вручную покопаться в мейкфайле.
Не, всё проще: CFLAGS="-O2 -march=native" ./configure. В configure можно и другие переменные передавать, если сделать configure --help, он расскажет какие.
> ПС и пожалуйста, хватит рассказывать, что мне делать, лучше ускорь jq с
> любимым strcpy.
"Любимым"? C'шная обработка строк -- это один из _худших_ подходов, которые можно придумать.
> Всего оверхэда тут на вызов процессов,
Чта? У тебя тут оверхеда на O(N^2) парсинга, ты складываешь кусочек данных в data, и потом эту data парсишь заново. И потом ещё раз, и ещё раз... Правда я не заметил изменений во времени выполнения jq. Оно увеличивается к концу, но несущественно: за 2k строк время затрачиваемое на выполнение jq изменилось где-то от 0.055 до 0.075. То есть энквадрат сложности не успевает показать себя.
Что наводит на мысль, что тормоза берутся не столько из-за парсинга или ещё какой-то обработки входных данных, сколько из-за накладных расходов на запуск. jq<<<"" отъедает 0.055-0.060 сек. Для сравнения: генерация 2k строк в том виде, как ты показал, отправленная в /dev/null занимает 0.008 сек. Запуск этого же генератора через cargo (который помимо запуска бинаря проверяет грядку файлов, чтобы не пропустить момент, когда надо пересобрать бинарь) отъедает 0.042 сек:
$ time target/release/gen-strings >/dev/null
real    0m0,008s
user    0m0,006s
sys    0m0,001s
$ time cargo run --release >/dev/null
real    0m0,042s
user    0m0,029s
sys    0m0,012s
$ time jq</dev/null
real    0m0,057s
user    0m0,054s
sys    0m0,002s
Какая-то заморочная инициализация в jq? Что он там делает? Телеметрию на сервер отправляет?
Не знаю, буду ли я ковырять jq, чтобы выяснить, чё он так тупит или нет, если будет настроение вечером, поковыряю.

Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

152. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 15-Апр-20, 12:43

>не собирается
Да не, нормально. версия в ебилде точно такая же. ;)
>oniguruma
не, никаких онигурум конечно, и это, --disable-docs --disable-valgrind --disable-maintainer-mode --enable-rpathhack
>всё проще
Это работает с autotools, но не обязательно работает с любым софтом.
>один из _худших_ подходов
Ничего плохого не вижу!
>потом эту data парсишь заново
Ну и что? Где-то будет иначе? Всё равно обходить всё заново.
>ерутся не столько из-за парсинга или ещё какой-то
Вроде да, разве я не это сказал?
>time
Замерять по одному вызову такое себе, надо выполнить хотя бы 10 и брать среднее, и то может там в фоне что-то крутится эдакое.
time jq</dev/null
real    0m0.028s
user    0m0.027s
sys     0m0.001s
Исходя из этих значений, будет на 200% медленнее, чем у меня (у меня старая версия, 1.6-r3).
>Что он там делает
Емнип там интерпретатор байткода (много фишечек, да), так что не так и много. Весь питон со штатным json кстати столько же примерно инициализируется, поэтому заменять на него смысла и нет. Памяти точно в тысячи тысяч раз больше уйдёт, и скорее всего медленнее будет.
А кстати, так и получается, как раз столько и отрабатывает баш (jq собранный обычным способом даёт 16 секунд в норме, можно собрать так, что будет и медленнее).
>>> 0.028*457
12.796
Т.е. всё в порядке, не нарушая законы мироздания, нам не ускориться. А что, где-то есть более быстрый и удобный процессор жсона? Я просто раньше питон с этими целями использовал в скриптах, но jq более быстрый.

Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

157. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ordu (ok), 15-Апр-20, 19:39

>>потом эту data парсишь заново
> Ну и что? Где-то будет иначе? Всё равно обходить всё заново.
Нет. json парсится в хеш-таблички, поиск в хештабличке и вставка туда элемента -- это O(log N). Если ты выполняешь это N раз, то ты получаешь O(N*log(N)), что в принципе терпимо.
>>time
> Замерять по одному вызову такое себе, надо выполнить хотя бы 10 и
> брать среднее, и то может там в фоне что-то крутится эдакое.
Как показывает практика, если запустить один раз для прогрева, и потом второй раз для измерения, то ты получишь числа с точностью достаточной для бытовых нужд. Этот же результат был получен в результате четырёх запусков команды, выкидыванием первого результата, и выбора среднего из оставшихся трёх. И да, если бы эти оставшиеся три сильно различались бы, я бы так не стал делать, а начал бы здесь писать о недетерминированности времени выполнения jq, и о том, что его писали какие-то лохи, которых вообще нельзя допускать до программирования.

>>Что он там делает
> Емнип там интерпретатор байткода (много фишечек, да), так что не так и
> много. Весь питон со штатным json кстати столько же примерно инициализируется,
> поэтому заменять на него смысла и нет. Памяти точно в тысячи
> тысяч раз больше уйдёт, и скорее всего медленнее будет.
Если есть длинная инициализация, то напрашивающийся способ оптимизации -- выполнять эту инициализацию единожды. В этот jq можно засунуть сразу _все_ его команды, чтобы он их выполнил последовательно за один запуск процесса?
на пайтоне нет проблем написать скрипт, который будет читать строки вида ."key" += {"item":["value"]}, парсить их в три локальные переменные key, item и value, а потом делать data[key][item]=value. То есть весь код будет выглядеть так (warning: псевдокод, я не помню python'а и не знаю его API для работы с json'ом):
def read_input_line():
    // тут мы читаем входную строку, парсим её в три строки и возвращаем их
while (key, item, value) = read_input_line():
    data[key][item] = value
print(json_to_string(data))
> где-то есть более быстрый и удобный процессор жсона? Я просто
> раньше питон с этими целями использовал в скриптах, но jq более
> быстрый.
Для быстроты основной подход -- процессить не json, а структуры в памяти. В нативные для языка структуры в памяти. И после процессинга сериализовать в json. Если ты в bash напишешь скрипт, который соберёт все эти строчки в ассоциативный массив ассоциативных массивов, а потом сериализуешь эту конструкцию в json, у тебя получится быстрее чем 500 запусков jq, написанного на C. Но у bash, что-то мне подсказывает, есть проблемы с ассоциативными массивами ассоциативных массивов, потому как, видите ли, поддержка такого "ненужна", потому что всегда можно сделать что-то типа:
$data[$key@$item]=$value
Или это в awk так? Где-то такая офигительная оптимизация работы с хештабличками точно заботливо навязывалась программисту. Типа это быстрее. Я, за давностью лет, не помню где.
А насчёт удобства -- я не знаю, я с json'ом сталкиваюсь эпизодически, и поэтому не особо парюсь об удобстве, пишу на том языке, на котором столкнулся с json'ом.
Я бы, будучи на голову ушибленным rust'ом, написал бы всё на rust'е. Собственно, я и написал:
// сначала тут ~70 строк описывающих генерацию charset'а, и троек случайных строк в этом charset'е, и затем:
fn main() {
    let mut rng = rand::thread_rng();
    let charset = generate_charset("a-zA-Z0-9").expect("Invalid charset");
    let mut data: HashMap<String, HashMap<String, String>> = HashMap::new();
    for _ in 0..2000 {
        let (key, item, value) = random_addition(&mut rng, &charset);
        let entry = data.entry(key).or_insert(HashMap::new());
        entry.insert(item, value);
    }
    println!("{}", serde_json::to_string(&data).expect("Fuck up"));
}
Тут генерится 2000 троек случайных строк (key, item, value), они добавляются в хеш-табличку хеш-табличек, и потом всё это сериализуется при помощи serde_json::to_string();
$ time cargo run >/dev/null
   Compiling gen-strings v0.0.1 (/home/rgo/tmp/jq-test)
    Finished dev [unoptimized + debuginfo] target(s) in 5.14s
     Running `target/debug/gen-strings`
real    0m5,781s
user    0m1,961s
sys    0m0,412s
И это отработала версия собранная без особых оптимизаций в debug варианте. Что гораздо хуже, запущенная через cargo, который прежде чем запускать компилировал. Если эту логику написать на python, bash или чём угодно ещё, то оно будет в разы быстрее, потому что не нужна сложная компиляция.

Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

159. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 15-Апр-20, 21:33

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

jq>"j2.json"<<<$(jq --sort-keys -c '. += {"key1": {"item1":["value1"],"item2":["value2"]},"key2": {"item1":["value1"]}}'<j.json)

Только тут ведь как, jq же их все генерирует, эти элементы, и обновляет при необходимости. Ну, чтобы там не было дубликатов, перезаписывает значения, и всё остальное. Я же не буду это в баше делать... Это придётся костылить массивы и прочее, потом каждый элемент хэштейбла будет хэштейблом. который будет содержать ареи и так далее… Хотя… Не, чёт я прогнал, в баше так будет сделать нельзя. Ну, арей хештейблу не присвоишь, только строку. Это городить eval с овер 100500 (буквально) переменных, этот способ ой ой ой какой костыльный, переменные будут называться key1item1=(value1 value2), нам надо вести учёт этих переменных, потом как-то проверять есть ли они вообще, перебирать через eval это всё по 5 раз, посимвольно сравнивать строки миллиарды раз, и вообще это всё очень неприятно. Тут и баш начнёт тормозить. Средствами баша это нормально не решается, скорее всего.
А зачем в несколько потоков? Это разные процессы, и они добавляют данные параллельно… Есть логика сравнения времени изменения и синхронизации. Конечно, вариант висеть демоном в питоне, но тогда я опять же ограничен синхронизацией, трубой, 1 потоком, и постоянной сериализацией/десериализацией. Наверное, и не скалируется вообще, и этот многогигабайтный питон висящий фоном… Немного быстрее будет конечно, хотя бы потому что питон может в сложные структуры вроде вложенных хэштейблов, но.

Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

160. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 15-Апр-20, 21:37

Eval... Хотя завести список keys, список key1items, потом присваивать уже key1item1=(va1 val2). Ну варик наверно.

Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

158. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ordu (ok), 15-Апр-20, 20:44

>>>> 0.028*457
> 12.796
> Т.е. всё в порядке, не нарушая законы мироздания, нам не ускориться. А
> что, где-то есть более быстрый и удобный процессор жсона? Я просто
> раньше питон с этими целями использовал в скриптах, но jq более
> быстрый.
Я почитал ман к jq, и написал тебе скрипт, который просто работает:
jq -c "$(echo $srcdata | grep '^\."' | tr '\n' '|' | sed -s 's/|$//')"<<<{}

Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

162. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 15-Апр-20, 22:54

Хех, да, отлично работает. Я так уже делал где-то, не тут.
real    0m0.123s
user    0m0.117s
sys     0m0.006s
Но конкретно это не было так чтобы узким местом, Я имею в виду, 15 значений добавляются куда быстрее 500 (типичная нагрузка). И если я использую баш, значит, наверное, такой производительности достаточно…
Зато это всё навело меня на определённые размышления. Я так увлёкся "честными" вычислениями, что начал дёргать тяжёлые программы несколько чаще, чем это необходимо. Хотя там это тоже не узкое место, примерно 0.00000000001% времени уходит. А вот в третьем… Чёрт, и там нужно прочитать гигабайты с диска, и основное время уходит на это.
Ну хоть для части кейсов ускорю, тем более что это ничего не стоит. Хотя нет, стоит. Вот пересобрать с пго и получить в полтора раза ускорения в бонус, это ничего не стоит, а тут сейчас придётся разбирать xml вместо 10 вызовов утилиты. Пожалуй, оставлю как есть.
В любом случае, спасибо за участие! Ускорение в 100 раз получили.

Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

163. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ordu (ok), 15-Апр-20, 23:37

> если я использую баш, значит, наверное, такой производительности достаточно…
Не сомневаюсь. Но исходно я ввязался в этот разговор, потому как ты сказал, что твой тест "не синтетичный" и показывает превосходство компилятора на реальном кейсе. Этот кейс может быть и реальный, но он от этого не перестаёт быть синтетикой. Искусственно созданные проблемы. Я, например, до сих пор не понимаю, зачем городить этот огород, если есть SQL. Создать табличку со строками key, item, value, и всех кого можно отправить работать с sql, а не с json'ом. А те, кого нельзя переориентировать на sql, один хрен получают этот json через сокеты общаясь с нашими демонами.

Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

164. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 16-Апр-20, 00:13

> Не сомневаюсь. Но исходно я ввязался в этот разговор, потому как ты
> сказал, что твой тест "не синтетичный" и показывает превосходство компилятора на
> реальном кейсе.
Ведь практически так и есть, я просто не ожидал такого явного превосходства шланга тут (при том, что файлы у него в 2 раза больше, они всё же быстрее запускаются).
>Искусственно созданные проблемы.
Это не проблемы, а односточник запускавшийся ровно 1 раз, но разница во времени исполнения как по мне очевидна. Пусть это и инициализация интерпретатора или чем он там занимается. Mediainfo работает с файлами на диске (в зависимости от формата файла, делает он это очень медленно), и гцц оказался значительно быстрее (совсем не 3%).
>Я, например, до сих пор не понимаю, зачем городить этот огород, если есть SQL.
Быстрее явно не будет. Когда объёмы будут такими, что нынешний подход начнёт создавать проблемы, тогда и подумаем. Я думаю, какая-нибудь монга тут более уместна.

Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

165. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ordu (ok), 16-Апр-20, 01:20

> превосходства шланга тут (при том, что файлы у него в 2 раза больше, они всё же быстрее запускаются).
Размер кода и скорость его выполнения слабо связаны. while(true); скомпилируется в два байта, но выполняться будет вечно.
>> Искусственно созданные проблемы.
> Это не проблемы, а односточник запускавшийся ровно 1 раз, но разница во
> времени исполнения как по мне очевидна. Пусть это и инициализация интерпретатора
> или чем он там занимается.
Если нет реалистичной проблемы с производительностью, которая упирается в инициализацию интерпретатора, то тогда у нас нет оснований считать, что скорость этой инициализации сколь-нибудь важна, а это значит что и превосходство llvm на этой инициализации тоже может быть никому не нужным. Это вариация на тему тех претензий, которые предъявляют к любым синтетическим тестам.
>> Я, например, до сих пор не понимаю, зачем городить этот огород, если есть SQL.
> Быстрее явно не будет.
Ты попробуй, прежде чем разбрасываться такими заявлениями. 500 запусков SQLite с добавлением одной строчки таблицы, за которым последует один запуск с извлечением всех строк и сериализацией в json совершенно определённо будут быстрее, чем тот твой скрипт, с которого мы начали. Даже если включить сюда инициализацию базы данных и создание таблицы. Даже если сериализация будет написана на bash.
Вот ежели сравнивать выполнение задачи типа "добавить строку, получить сериализованное всё", то тут сложнее утверждать определённо. Можно утверждать определённо, лишь, что существует такой N, что для любого n, такого что n>N, решение на SQL будет быстрее. Но каким должен быть этот N -- я не возьмусь гадать. Может быть 0, а может быть 10000.

Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

166. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 16-Апр-20, 14:50

Раздутый код будет быстрее, если это лапша из джампов. Или медленнее, если он внезапно перестанет помещаться в кэши процессора (simd векторизация этому очень способствует, например).
>нет оснований считать, что скорость этой инициализации сколь-нибудь важна, а это значит что и превосходство llvm на этой инициализации тоже может быть никому
Я вроде упоминал, что при поступлении данных приходится делать выборку каждый раз. Мы ускорили только финальный этап записи данных на диск, перед этим в 3 раза больше вызовов происходит (нам нужно узнать, добавлять ли данные, или мы будем менять имеющиеся -- заодно получаем статистику имеющихся данных для key). Т.е. ускорение инициализации тут как раз ключевая задача, и её решение обеспечивает компилятор.
>определённо будут быстрее
Дело в том, что сейчас я работаю с текстом и по возможности без необходимости не трогаю диск (пока памяти более чем достаточно для данных). Сабж же добавит немало оверхэда и будет дёргать диск сотни тысяч раз. Sqlite можно использовать и для хранения данных в памяти, но на более нормальных языках, а не на баше. Кроме того, на данный момент у меня нет необходимости в каких-то сложных запросах, данные всегда находятся в одном месте (задача перебрать все value для всех item -- самое страшное, что может случиться, и она не очень проблемной окажется).

Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

170. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ordu (ok), 16-Апр-20, 20:14

> заодно получаем статистику имеющихся данных для key
Сам бог велел задействовать sql.
>>определённо будут быстрее
> Дело в том, что сейчас я работаю с текстом и по возможности
> без необходимости не трогаю диск (пока памяти более чем достаточно для
> данных). Сабж же добавит немало оверхэда и будет дёргать диск сотни
> тысяч раз. Sqlite можно использовать и для хранения данных в памяти,
> но на более нормальных языках, а не на баше.
В ядре, в списке псевдофс, есть RAM-диски.

Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

173. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 16-Апр-20, 21:53

Надо было брать xml вместо json, в 100500 раз быстрее было бы (это не точно, фишечек в xpath не сильно меньше чем в jq). Одна из задач тут конечно человекочитаемость (и человекоредактируемость), жсон мне кажется куда более приятным. Обновлённые данные в #172, получается, мои первые выводы были довольно близки к истине. Ну 400к (или сколько там) строк добавлять 7 минут это конечно не очень быстро. Но я уже делал что-то похожее со sqlite, и он даже без rowid не очень быстрый был. Postgres вроде норм в первом приближении оказался. Не помню чем закончилось, не то монгой, не то рокс.

Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

167. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 16-Апр-20, 17:13

Я ещё немного подумал над этим, тут есть огромная проблема. Если нужно добавить данных больше лимита ОС, всё сломается. Может быть и 30кб в зависимости от системы.
Видимо, я уже когда-то отбросил эту затею. Но я решил это проверить. Оказалось, что на моей системе уже строка в 130кб (всего 3к элементов вместо 450, 450 уже 17кб, что, вероятно является пределом для ряда систем).
>просто работает
незачёт, не работает. (:

Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

172. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 16-Апр-20, 21:40

Ради интереса передал фильтр через временный файл, jq всё равно фейлится, если он больше 70кб. В общем, смысла трогать не было, это не юзабельно в таком виде, хоть и быстрее.
Ладно, если ты видишь проблему, ты можешь её решить. Пока что разбил на блоки по 50кб. Посмотрим, зато добавил какую-никакую недостающую логику обработки фейла и сохранения данных вокруг jq.
Это 15мб повторяющихся данных блоками по 50кб (обновляет 17кб данных можно посчитать сколько раз), интересно было бы сравнить эффективность, если скормить одним фильтром, но не очень. Я так прикинул, собственно на вызов jq тут ушло 23 секунды из 7 минут. Лучше, видимо, не получится:
gcc (пго старый под строки 100байт)
real    7m45.175s
user    7m20.088s
sys     0m3.645s
gcc (O2 lto)
real    7m45.812s
user    7m21.456s
sys     0m3.542s
gcc (O2 pgo+lto)
real    7m22.190s
user    7m6.515s
sys     0m3.059s
clang (O2 lto=thin, без харденед фишечек)
real    7m9.484s
user    6m44.182s
sys     0m3.512s
clang (O3 lto-full, максимально близко к gcc версии, минус stack-clash-protection)
real    7m8.272s
user    6m45.443s
sys     0m3.455s
ПС. Компилять гораздо веселее, чем костылять баш.

Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

168. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 16-Апр-20, 17:28

Более того, jq обламался ещё на 70кб, так что совсем никуда не годится. :(

Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

47. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 13-Апр-20, 20:07

Сорян, есть обновлённая инфа из проверенных источников.
На операциях с малыми объёмами данных (конкретно 500 конкатенаций строк ~10-15 символов или около того) clang-10 O3 может показать превосходство над gcc93 Ofast порядка 20%, по сравнению с gcc93 -O3 разница в производительности легко может доходить до 50%. clang-10 O3 быстрее gcc93 Ofast + lto + pgo на ~1.5%.
Скорее всего там та самая лапша из переходов, из-за которой шланг сыпется на более сложных кейсах, я не могу проверить. Бинарники у шланга в 2 раза больше с lto=thin, в 1.7 с lto=full, по сравнению с гцц lto + pgo.

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

53. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 13-Апр-20, 20:42

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

Ответить | Правка | Наверх | Cообщить модератору

101. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 14:13

Теперь о плохом. Вот mediainfo (плюсовая программа, весьма тяжёлая и тормозная) шланг нисколько не помог и только замедлил, у g++ на O2 код более эффективный и быстрый генерируется. Я уже проверял это прежде, потому что она очень уж тормозная и авторы вроде советуют шлангом собирать.
После прогона сборки с PGO, g++ билд оказался на 15% быстрее clang++-10 O3 и на 10% быстрее g++-9.3 O2, Правда, стоило бы собрать более полноценную статистику, я прогнал только для 1 наиболее часто используемого варианта. Но суть остаётся.
Всегда поражало нездоровое желание плюсовиков собирать релизные билды шлангом. Не знаю, как в венде (там есть варианты из-за тех же экцепшенов и много чего ещё), а в свободных системах шланг совершенно не конкурент гцц.

Ответить | Правка | Наверх | Cообщить модератору

115. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 18:27

ПС мои "тесты" гцц херня скорее всего, там замедляющих харденед флагов по самые яйца напихано. А в шланговом билде их нет. Т.е. гцц ещё быстрее, чем у меня вышло. %)

Ответить | Правка | Наверх | Cообщить модератору

116. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (-), 14-Апр-20, 18:34

> ПС мои "тесты" гцц херня скорее всего,
Скорее всего "скорее всего" тут лишнее.

Ответить | Правка | Наверх | Cообщить модератору

117. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 18:48

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

Ответить | Правка | Наверх | Cообщить модератору

132. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 21:57

Делают ли 30% погоду? Визуально стало очень приятно. Прямо очень, а то чутка напрягало. Может ли ускорение на треть принести счастье? Такое ощущение, что может. Пго прелесть всё-таки, респект разрабам.

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

8. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +2 +/–

Сообщение от Аноним (7), 13-Апр-20, 16:56

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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

11. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –4 +/–

Сообщение от анонн (ok), 13-Апр-20, 17:06

> Подскажите, почему llvm всегда генерирует дефективный код даже на amd64? Ведь сколько
> лет его разрабатывают, почти что сколько и gcc… Что не логично,
> так это то, что его и в вулкан пихать пытаются. Я
> хочу логичное объяснение, почему популярный у проприерасов и всяческих противников свободы компиялтор такое убожество.
Может потому что аналога LLVM в GCC - немаэ?

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

21. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +2 +/–

Сообщение от slava_kpss (ok), 13-Апр-20, 17:44

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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

26. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от Аноним (86), 13-Апр-20, 17:54

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

Ответить | Правка | Наверх | Cообщить модератору

140. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от Lex (??), 15-Апр-20, 01:24

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

Ответить | Правка | Наверх | Cообщить модератору

144. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 15-Апр-20, 08:54

Нет. Одни и те же программы собирают msvc и продают за деньги. И собирают gcc и продают за деньги другие ребята, менее корпоративные. Не нужно путать ситуации, когда гцц используется из-за необходимости тащить cygwin.

Ответить | Правка | Наверх | Cообщить модератору

27. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (7), 13-Апр-20, 17:57

Потому что все что надо им собрать нормально собирается.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

58. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от Аноним (31), 13-Апр-20, 22:13

Телеметрию?

Ответить | Правка | Наверх | Cообщить модератору

110. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (110), 14-Апр-20, 17:09

GCC можно и без телеметрии, а msvc ты без телеметрии от visual studio не обойдешься.

Ответить | Правка | Наверх | Cообщить модератору

126. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от neAnonim (?), 14-Апр-20, 20:04

vulkan построен поверх spir-v что является форком llvm.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

131. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 21:41

> vulkan построен поверх spir-v что является форком llvm.
Eue, даже более того, нвидиевский nvvm тоже llvm (я всё ещё собираю гцц по старинке, но куда работает только с 8 -- видимо всё).

Ответить | Правка | Наверх | Cообщить модератору

17. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Alexey (??), 13-Апр-20, 17:33

А в чем собственно проблема с GCC, ставьте из портов не забывая обновить дерево. И, если не ошибаюсь, то с опциями оптимизации сильно увлекаться не стоит, по рекомендации BSD-шников, типа флаг=-O3. А по поводу пути "Солярки", попадание оной грозит свалке долгой стабильной работой (хотя хотелось бы посмотреть на ту свалку космических масштабов). Дальнейшего развития товарищам.

Ответить | Правка | Наверх | Cообщить модератору

19. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от abi (?), 13-Апр-20, 17:38

> А в чем собственно проблема с GCC
Так лицензия же, её не включить в base

Ответить | Правка | Наверх | Cообщить модератору

23. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (22), 13-Апр-20, 17:48

Зачем он тебе в базе? Поставил из портов и собираю базу.

Ответить | Правка | Наверх | Cообщить модератору

30. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (30), 13-Апр-20, 18:13

Так продаваться несолидно.

Ответить | Правка | Наверх | Cообщить модератору

29. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (29), 13-Апр-20, 18:08

Я всё уже много лет собираю на Фрибсд с -O3 и нет проблем.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

33. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (31), 13-Апр-20, 18:22

Порты? Или и систему тоже?))
-О3 кажется даже дает небольшое падение производительности по сравнению с -O2 (по дефолту обычно идет), но я глобально не тестил.

Ответить | Правка | Наверх | Cообщить модератору

100. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (29), 14-Апр-20, 13:55

И порты и систему. Работает быстрее.

Ответить | Правка | Наверх | Cообщить модератору

42. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +7 +/–

Сообщение от анонн (ok), 13-Апр-20, 19:07

> А в чем собственно проблема с GCC, ставьте из портов не забывая
> обновить дерево.
Если вы Настоящий Линуксоид Опеннета, то проблема в недостаточной гибкости вашего восприятия!
Ведь одно дело - Самое Лучшее Ядро. Ну нельзя его под GPLv2 переводить - Платиновые Папик^W партнеры недовольны будут!
И отсутствие изкоробочного компилятора под GPLv3 в той же бубунте и прочих мейнтсримных дистрах - это ... необходимость и Хитрый План! Понимать надо!
И совсем-совсем другое - бзды! Тут отсутствие пропатченой GPLv3 компоненты (из-за которой вполне можно потребовать перевести все остальные компоненты под ту же лицензию, что в свою очередь потребует или выкидывание и переписывание кучи компонентов или услуги некромантов и медиумов для получения согласия всех учавствовавших разработчиков. О возможной, очередной смене лицензии без предупреждения, во время минорного обновления - просто скромно не будем вспоминать) в бсдшом бейз-бандле -- явный признак прогиба под проприерасов! Понимать надо!

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

38. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +6 +/–

Сообщение от Deanon (?), 13-Апр-20, 18:44

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

Ответить | Правка | Наверх | Cообщить модератору

77. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (76), 14-Апр-20, 10:07

Как там с десктопом? Всякие зоомы, и шлаки и скупые запускаются?

Ответить | Правка | Наверх | Cообщить модератору

108. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –2 +/–

Сообщение от Аноним (110), 14-Апр-20, 16:53

Электрон не осуществляет поддержки фрибсд. Все работает на страх и риск бзднутых.

Ответить | Правка | Наверх | Cообщить модератору

114. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +4 +/–

Сообщение от аннон. (?), 14-Апр-20, 18:08

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

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

118. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от Аноним (76), 14-Апр-20, 19:01

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

Ответить | Правка | Наверх | Cообщить модератору

127. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +1 +/–

Сообщение от анонн (ok), 14-Апр-20, 20:09

> У тебя реально на десктопе только бздя?
Да.
> Просто я как-то не верю...
Это твои проблемы и комплексы.
> А возможность запустить зонт - как-то лучше отсутствия оной. Вот у нас
> на работе - все в зооме, например. И реально был случай,
Прикинь, если мне действительно нужно будет - я запущу.
Я ж не опеннетная Пингвиняша, впадающая в уныние от того, что в любимом дистре сменили тему и набок иконок и теперь придется искать новый любимый дистр.
И для которой Пингвинчик - замена Венды, только "на ХАЛЯВУ!" и поэтому привычно и по виндусячьи запускающая двойным кликом пропритерный setup.elf (даже не подумав упихать сие в виртуалку или контейнер).
> вот только ты потерял ещё одного пользователя, и мне от этого - совсем не приколько.
Оу, не переживай - мне лично от "потери" очередного "потреблятеля" ни холодно ни жарко. А уж от потери "потреблятеля", выдуманного опеннетным анонимом ...
> Так что давай, расскажи с вантузомакакоси насколько зонды не нужны на бзде.
Т.е. настойчиво пропаган^W предлагаешь установить винду или макось? Да ты настоящий опеннетный Линухоид!
А можно, я воздержусь или из виртуалки это сделаю? И чур, лицензия с тебя (а то у меня есть только XP - из тех самых официальных халявных образов VDI "для вебдевов", с ограничением на полтора часа).

Ответить | Правка | Наверх | Cообщить модератору

44. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –10 +/–

Сообщение от Аноним (44), 13-Апр-20, 19:22

>Из дерева исходных текстов FreeBSD-CURRENT удалён набор компиляторов GCC, а также неиспользуемые утилиты gperf, gcov и gtc (компилятор devicetree).
Всё пацаны! Это начало конца ФриБЗД. Отказ от ГНУ это непростительная ошибка и начало деградации.

Ответить | Правка | Наверх | Cообщить модератору

61. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (61), 13-Апр-20, 23:08

С тех пор, как GNU выгнали Столлмана, они перестали вызывать у меня симпатию.

Ответить | Правка | Наверх | Cообщить модератору

65. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (65), 14-Апр-20, 00:05

Столлмана выгнали не GNU, А FSF.

Ответить | Правка | Наверх | Cообщить модератору

46. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –3 +/–

Сообщение от Аноним (46), 13-Апр-20, 20:06

>лицензию GPLv3, которая была признана неприемлемой
В угоду корпорастам.

Ответить | Правка | Наверх | Cообщить модератору

50. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +6 +/–

Сообщение от zzz (??), 13-Апр-20, 20:33

Как там идет процесс перевода линуксового ядра под GPLv3?

Ответить | Правка | Наверх | Cообщить модератору

55. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +10 +/–

Сообщение от Annoynymous (ok), 13-Апр-20, 20:55

Никак. В угоду корпорастам, которые это ядро и развивают.

Ответить | Правка | Наверх | Cообщить модератору

82. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от iPony129412 (?), 14-Апр-20, 10:25

Да всем в угоду.
Не каждый в восторге от софта, где лицензия на кучу страниц.
И бывает, что честному разработчику для разъяснения как оно согласуется с лицензией другого продукта с открытым кодом, надо проходить суд на один год, задействовать кучу юристов и консультантов.
А тем временем, в каком-то подпольном Китае нечестные вообще клали на этот GPL, и ничего им за это не будут.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

51. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –2 +/–

Сообщение от IdeaFix (ok), 13-Апр-20, 20:37

Докер всё там же? Прошу понять правильно, клетка не нужна.

Ответить | Правка | Наверх | Cообщить модератору

67. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (67), 14-Апр-20, 00:18

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

Ответить | Правка | Наверх | Cообщить модератору

74. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +5 +/–

Сообщение от Anonimous (?), 14-Апр-20, 08:55

Как в 2000 джейлы появились, так с ними и сейчас все ок. Это нативная вещь для FreeBSD, зачем там докеры?

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

78. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –4 +/–

Сообщение от Аноним (76), 14-Апр-20, 10:08

И как в бзд-джейле запустить уже готовый докер-контейнер?

Ответить | Правка | Наверх | Cообщить модератору

93. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +1 +/–

Сообщение от Аноним (-), 14-Апр-20, 12:29

> И как в бзд-джейле запустить уже готовый докер-контейнер?
И как в этом вашем дыркере запустить бзд-джейл-контейнеры?
https://bastillebsd.org/templates/
https://gitlab.com/bastillebsd-templates

Ответить | Правка | Наверх | Cообщить модератору

120. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –2 +/–

Сообщение от Аноним (76), 14-Апр-20, 19:08

> И как в этом вашем дыркере запустить бзд-джейл-контейнеры?
Да я и не против бы это сделать, честно. Больше возможностей - лучше для меня. Меньше - хуже.
Итак, есть у нас десятки шаблонов под джейлы и лимоны - дыркер-контейнеров. Вот он, выбор.
https://forums.freebsd.org/threads/docker-is-dead.69955/
Для LXC тоже есть какие-то шаблоны, так что джейлы мне ничего нового не датут. А жаль.

Ответить | Правка | Наверх | Cообщить модератору

106. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от YetAnotherOnanym (ok), 14-Апр-20, 16:33

Ты, наверное, в картер двигателя заливаешь олифу, да?

Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

113. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от Аноним (76), 14-Апр-20, 18:02

Изначальный вопрос в треде звучал так, между прочим:
> Докер всё там же? Прошу понять правильно, клетка не нужна.
А кому нужен джейл - запустят джейл. Кому LXC/OpenVZ/Virtuozzo - запустят их. Линуксатор в бзде - есть. Со стороны докера же - есть нехилая библиотека образов. Сильно побогаче той, что у анонима выше.
Так что продолжай дальше заливать про карбюратор.
Я бы не прочь запустить докер на бзде.

Ответить | Правка | Наверх | Cообщить модератору

149. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от IdeaFix (ok), 15-Апр-20, 12:00

> Как в 2000 джейлы появились, так с ними и сейчас все ок.
> Это нативная вещь для FreeBSD, зачем там докеры?
Джейлы не нужны. Фрю юзает примерно 0% рынка и под эти нативные реализации полезных фич никто ничего не будет делать вне нуля процентов мира фрибсдшных юзеров. Т.е. докер форева бета... или совсем сломали?

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

154. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (154), 15-Апр-20, 14:00

>> Как в 2000 джейлы появились, так с ними и сейчас все ок.
>> Это нативная вещь для FreeBSD, зачем там докеры?
> Джейлы не нужны.
Анонимные опеннетные оналитеки тоже не очень нужны.
> Фрю юзает примерно 0% рынка и под эти нативные реализации полезных фич никто ничего не будет делать вне нуля процентов мира фрибсдшных юзеров.
То ли дело портировать для того же нуля процентов пингвинячье нагромождение костылей и подпорок. Л-логика.
> Т.е. докер форева бета... или совсем сломали?
Смысл его портировать, если почти все образы сделаны хвостатыми - и ожидают именно пингвинчика, к которому они прибиты полуметровыми гвоздями и который придется эмулировать?

Ответить | Правка | Наверх | Cообщить модератору

155. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –2 +/–

Сообщение от IdeaFix (ok), 15-Апр-20, 14:43

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

Ответить | Правка | Наверх | Cообщить модератору

156. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (156), 15-Апр-20, 15:51

>> Смысл его портировать, если почти все образы сделаны хвостатыми - и ожидают
>> именно пингвинчика, к которому они прибиты полуметровыми гвоздями и который придется
>> эмулировать?
> У докера есть библиотека образов, у бсд есть проблемы.
А в огороде есть бузина ...
> Клетка в частности и БСД в целом не нужно.
Ценное мнение от очередного Опеннетного Знатока - тоже.

Ответить | Правка | Наверх | Cообщить модератору

81. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (81), 14-Апр-20, 10:18

Софт на Go-вне не нужен от слова совсем. Докер не исключение.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

84. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от Аноним (84), 14-Апр-20, 11:07

Лучше на Go-вне чем на винде.

Ответить | Правка | Наверх | Cообщить модератору

134. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от FGSFDS (?), 14-Апр-20, 22:29

Докер в БЗДе там же, где и в других ОС, не поддерживающих cgroups нативно. Т.е. ставите Linux в виртуалку, ставите /usr/ports/sysutils/docker, докерите себе на здоровье.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

150. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от IdeaFix (ok), 15-Апр-20, 12:02

> Докер в БЗДе там же, где и в других ОС, не поддерживающих
> cgroups нативно. Т.е. ставите Linux в виртуалку, ставите /usr/ports/sysutils/docker,
> докерите себе на здоровье.
Т.е. фрибсд не нужно... жаль. Так же жаль что по началу докер так лихо втаскивали и говорили вот-вот, еще чуть-чуть и будет хорошо, а теперь чот так же пафосно, но уже злобно шлют в так полюбившуюся клетку.

Ответить | Правка | Наверх | Cообщить модератору

153. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +1 +/–

Сообщение от ГабенВул (?), 15-Апр-20, 13:55

Ну какому-то васяну, в чьей вселенной  "докер это единственное и самое важное качество ОС" скорее всего не нужно. Остальные могут в докер на виртуалке, сидят работают и в общем-то их все устраивает. Такие дела

Ответить | Правка | Наверх | Cообщить модератору

181. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от тигар (ok), 20-Апр-20, 08:57

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

Ответить | Правка | Наверх | Cообщить модератору

64. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Фанат (?), 14-Апр-20, 00:04

Проблемы у MSVC и GCC сходны и видны невооруженным глазом.
https://cloud.mail.ru/public/4UL7/5z6UKchAc
GCC и MSVC разрывает последовательность записи и чтения блока данных.

Ответить | Правка | Наверх | Cообщить модератору

105. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от Аноним (86), 14-Апр-20, 15:32

Gcc на O3 генерирует очень, очень тормозной и раздутый код, следуя одному ему (меняющейся регулярно) понятной логике (которая вне всяких сомнений применима… где-то, но не здесь). Какой смысл выбирать O3? Польза иногда действительно перевешивает, но только на всяких кодерах и компрессорах. Вместо O3 надо использовать PGO, который включает оптимизации из O3 (и некоторые дополнительные) в нужных местах.

Ответить | Правка | Наверх | Cообщить модератору

66. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Ivan_83 (ok), 14-Апр-20, 00:08

Это всё здорово, но есть штуки типа этой: https://reviews.freebsd.org/D21206
вроде мелочь но сильно портит жизнь не только на десктопе но и на серверах.
И в багтрекере таких коммитов ещё с десяток, которые иногда даже в апстрим взяли уже, и тут готовый патч лежит который только вмержить но нет.
В amdgpu работа в этом году состоит менее чем в 10 коммитах.

Ответить | Правка | Наверх | Cообщить модератору

68. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от paulus (ok), 14-Апр-20, 00:57

>NomadBSD 1.3.1, представляющего собой редакцию FreeBSD
Редакция эта что-то на двух ноутах даже Х-ы не подняла :( Линуксы от мала до велика себе такое не позволяют...

Ответить | Правка | Наверх | Cообщить модератору

69. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +2 +/–

Сообщение от G0Dzilla (??), 14-Апр-20, 06:17

Ой ли? На самом деле конфигов ноутов великое множество. Потому я своими глазами вижу, как на части этих ноутов даже Ubuntu без напильника не поднимает X-ы. Совсем небольшая часть от всех ноутов, но все же такие есть.

Ответить | Правка | Наверх | Cообщить модератору

79. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –1 +/–

Сообщение от Аноним (76), 14-Апр-20, 10:12

Есть у меня ленивец Е440. На линуксах работал всегда, но ни в одной из БЗДей(10, 11 и производные ливни) - не подымались иксы. Зато есть войфай!
Псевдографики всем! И пусть все будут довольны.
Видеокарты конечно бывают разные, но штеудовский интеграт... Завёлся даже в гайке.

Ответить | Правка | Наверх | Cообщить модератору

111. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от G0Dzilla (??), 14-Апр-20, 17:10

Многие современные производители пользовательской техники немного «подзабили» на унификацию. Несмотря на одну и ту же модель, иногда на двух соседних ноутах стоят разные компоненты. Поэтому на одних и тех же моделях операционная система, которая ценится за серверные качества, может вести себя по разному. Lenovo в этом плане не исключение.
P.S. Бывший сотрудник сервисного центра этой компании и именно на этом бренде основывается мой опыт работы с Linux на рабочих компьютерах.
P.P.S. Я так думаю, не нужен десктоп для FreeBSD. Каждый хорошей на своём месте.

Ответить | Правка | Наверх | Cообщить модератору

124. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (76), 14-Апр-20, 19:22

Знаешь, нужен. Хотя бы мне. Наличие альтернатив - всяко лучше, чем отсутствие оных. Кстати видяшка в этом ленивце - i915. Что может быть ещё унифицированнее?

Ответить | Правка | Наверх | Cообщить модератору

141. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от G0Dzilla (ok), 15-Апр-20, 04:31

Тем, кому нужно, и на QNX соберут рабочее окружение.
Мой посыл выше был о том, что разработчикам FreeBSD не нужно сильно ориентироваться на десктоп. А то мы ведь уже видели примеры десктопизации. Еще раз: каждый хорош на своем месте.

Ответить | Правка | Наверх | Cообщить модератору

151. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от IdeaFix (ok), 15-Апр-20, 12:13

> Знаешь, нужен. Хотя бы мне. Наличие альтернатив - всяко лучше, чем отсутствие
> оных. Кстати видяшка в этом ленивце - i915. Что может быть
> ещё унифицированнее?
Я сейчас буду телепатствовать, но... видимо, по Вашей логике, если у меня на netbsd 8.2 в железном SPARC32 есть пакет i915resolution, то там тоже есть i915?

Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

133. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от paulus (ok), 14-Апр-20, 22:23

> Многие современные производители пользовательской техники немного «подзабили» на унификацию.
Согласен, но древняя toshiba с radeon'ом как могла не взлететь? Может таки проблема nomadbsd, а freebsd может завестись с Х'ами? Что-то типа frenzy на bsd существует?

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

182. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от тигар (ok), 20-Апр-20, 09:01

зашибись шутишь. фрнзи, если что, изначально на базе fbsd была. а потом умерла.

Ответить | Правка | Наверх | Cообщить модератору

91. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +3 +/–

Сообщение от zshfan (ok), 14-Апр-20, 12:25

Простой личный пример:
Дано: Ноутбук Dell Inspiron 15 7000 Gaming
NomadBSD - запустилась, подхватила иксы, подхватила Wi-Fi, всё работает.
Ubuntu Beta 20.04 запустилась, при открытии любого приложения иксы слетают на 1024х768, постоянно теряется Wi-Fi, вот такие вот дела.

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

109. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (110), 14-Апр-20, 17:08

Ubuntu 20.04 стабильная еще не вышла.   И даже 23 числа когда выйдет по хорошему надо ждать полгода чтобы ставить до 20.04.1. Так что не показатель.

Ответить | Правка | Наверх | Cообщить модератору

119. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от xm (ok), 14-Апр-20, 19:06

В Ubuntu вообще надо ждать. Некоторые вещи годами.
Ну чистый дзен.

Ответить | Правка | Наверх | Cообщить модератору

142. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от zshfan (ok), 15-Апр-20, 06:38

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

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

145. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от iPony129412 (?), 15-Апр-20, 09:12

> Ну не соглашусь
Ну молодец.
> убунту 20.04 это лтс, она должна быть вылизана изначально, она должна быть вылизана изначально, ибо предполагается что она на поддержке будет долго
Нет. Как раз по этому зачастую туда пропихивают что-то по новее, ибо потом поддерживать долго.
Например, тот же GNOME 3.26 вышел в 11 марта 2020. Понятно, что за полтора месяца выловить и починить свежие баги на разных конфигурациях сложно.
Поэтому правило до первого сервис пака в полную силу.

Ответить | Правка | Наверх | Cообщить модератору

146. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от iPony129412 (?), 15-Апр-20, 09:22

> на поддержке будет долго
Или вот, понятно, что python2 выкинули в Ubuntu - ну не поддерживать же его дальше.
Ну и привет. Steam вроде до сих пор просто так не ставится.
Не факт, что всё утрясут до релиза.
https://github.com/ValveSoftware/steam-for-linux/issues/6869

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

147. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +1 +/–

Сообщение от Аноним (-), 15-Апр-20, 10:53

> Ну не соглашусь, убунту 20.04 это лтс, она должна быть вылизана изначально,
> ибо предполагается что она на поддержке будет долго, при том что сидя на каррент ветке фри такого не наблюдается.
Просто пример был изначально неправильный, с неправильными результатами - вот если бы под Линуксом работало хорошо, а под васянской сборкой CURRENT тормозило и фризилось -- никто бы и слова не сказал о "показателях".

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

125. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (125), 14-Апр-20, 19:24

Это не к вам, а в целом, к свидетелям дефолтных конфигов: не ебитесь, поставьте винду. Если вы хотите yes->yes->next->install - не надо гнать на бзды и перебирать линксовые дистры. Не хотите разбираться, хотите next->next->ok? Ну так это в винде тру. Хотите вкурить линуксы? Ну это явно не убунта со стимом.

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

73. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +3 +/–

Сообщение от Аноним (73), 14-Апр-20, 08:44

Разработчику NomadBSD в особенности всего наилучшего, лишь бы в комфорте делал свое дело.

Ответить | Правка | Наверх | Cообщить модератору

83. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –4 +/–

Сообщение от Аноним (84), 14-Апр-20, 11:05

Для это поделки фрибсд даже Firefox официальный не выпускают. Вывод фря не нужна.

Ответить | Правка | Наверх | Cообщить модератору

87. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +4 +/–

Сообщение от Dmitry (??), 14-Апр-20, 12:12

Аноним не осилил "pkg install firefox" ?
Да, уровень свидетелей святого ядра скатывается все ниже и ниже...

Ответить | Правка | Наверх | Cообщить модератору

88. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 12:16

Я Оперу хотел скачать, в интернете мне предложили только линуксулятор, который так и не смог её запустить потому что она 64 бита и там какие-то проблемы с версиями. Вот так. Зачем нужна такая система на десктопе, если для неё нет единственной приличной хромосборки. И с электроном кстати тоже проблемы возникли.

Ответить | Правка | Наверх | Cообщить модератору

90. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (31), 14-Апр-20, 12:25

Зачему тебе эти хромые сборки и электроды?
Вот качай нормальную Оперу: https://ftp.opera.com/pub/opera/unix/1216/

Ответить | Правка | Наверх | Cообщить модератору

95. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (86), 14-Апр-20, 12:36

> Зачему тебе эти хромые сборки и электроды?
> Вот качай нормальную Оперу: https://ftp.opera.com/pub/opera/unix/1216/
Не, она конечно нормальная (особенно потому что она куда экономней нынешних браузеров), но уже лет 8 назад у неё были проблемы на куче сайтов (они тогда ещё решались подменой юзерагента). С производительностью и текучестью правда всегда проблемы были.
Мне не совсем нравится нынешняя опера, пару лет назад она была куда круче и удобней (а ещё все её прокси можно было использовать свободно в любом браузере), но она всё ещё самая лучшая и удобная сборка хрома. А без хрома сегодня жизни нет. Электрон нужен, потому что много софта использует электрон. А тому нужны рабочие opengl и vulkan, среди прочего.

Ответить | Правка | Наверх | Cообщить модератору

107. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –3 +/–

Сообщение от Аноним (110), 14-Апр-20, 16:48

pkg от Васяна который неизвестно что собрал и к фиксам которого Мозилла никакого отношения не имеет? Нет уж если уж говорите что десктоп то или поддерживайте или валите на роутеры.

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

112. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +3 +/–

Сообщение от Аноним (31), 14-Апр-20, 18:00

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

Ответить | Правка | Наверх | Cообщить модератору

123. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (76), 14-Апр-20, 19:18

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

Ответить | Правка | Наверх | Cообщить модератору

136. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (136), 14-Апр-20, 23:04

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

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

161. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +1 +/–

Сообщение от KaZaaM4iK (ok), 15-Апр-20, 22:36

Почему сразу неизвестно? Зашёл на freshports (https://www.freshports.org/www/firefox/) и увидел все опции/флаги, которые установлены. И лучше уж какие то фиксы будут, чем оставлять известные проблемы без какого либо фикса.

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

99. "Отчёт о развитии FreeBSD за первый квартал 2020 года" –2 +/–

Сообщение от аНоним (?), 14-Апр-20, 13:41

Новости из теплого, лампового 2007 года.

Ответить | Правка | Наверх | Cообщить модератору

137. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +3 +/–

Сообщение от Аноним (137), 14-Апр-20, 23:32

> Новости из теплого, лампового 2007 года.
Да уж, ретрограды! Ни одного упоминания systemd!

Ответить | Правка | Наверх | Cообщить модератору

176. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (176), 18-Апр-20, 09:18

Моя самая любимая ОС :) кто-бы що не говорил.

Ответить | Правка | Наверх | Cообщить модератору

177. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Сергей (??), 18-Апр-20, 09:18

Моя самая любимая ОС :) кто-бы що не говорил.

Ответить | Правка | Наверх | Cообщить модератору

179. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от bOOster (ok), 18-Апр-20, 21:47

Чето все молчат, а ведь HAMMER от стрекозы - этож идеальная система для десктопа

Ответить | Правка | Наверх | Cообщить модератору

183. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от Аноним (183), 06-Май-20, 22:29

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

Ответить | Правка | Наверх | Cообщить модератору

184. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/–

Сообщение от linuxbuild (ok), 30-Июн-20, 11:53

Могу подтвердить, что с драйверами во FreeBSD становится лучше. Это видно по добавлению поддержки новых устройств в sys: https://github.com/bsdhw/Drivers/blob/master/freebsd/freebsd...
Но чтобы не нарваться на неподдерживаемую плату или компонент, надо как и прежде покупать железо специально для FreeBSD. Найти BSD-совместимые конфигурации можно на сайте https://bsd-hardware.info/

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

2. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+49 +/–
Сообщение от dvz (??), 13-Апр-20, 16:31
Прекрасно. Фряшка развивается, что не может не радовать.
Ответить \| Правка \| Наверх \| Cообщить модератору


	7. Скрыто модератором	–20 +/–
	Сообщение от Аноним (7), 13-Апр-20, 16:55
	Судя по характеру обновлений она скорее деградирует. Следующая на свалку после Solaris.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. Скрыто модератором	+24 +/–
	Сообщение от анонн (ok), 13-Апр-20, 17:05
	> Судя по характеру обновлений она скорее деградирует. Следующая на свалку после Solaris. Что, не обновили в очередной раз CoC? Не решили единым порывом вычистить сорцы от факов и заменить списки рассылок модно-молодежным смузи с тоннами JS, бесконечным скроллингом и прочими "плюшками"? Ну точно деградируют!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	76. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	–4 +/–
	Сообщение от Аноним (76), 14-Апр-20, 10:02
	Ну да, интеловское видео перетащили из линукса. ZoL тоже. Заживём.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	85. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+6 +/–
	Сообщение от Аноним (85), 14-Апр-20, 11:52
	> Ну да, интеловское видео перетащили из линукса. Вообще-то из интеля. Или загружаемые чере NDISWrapper дрова у вас "из винды утащены!". > ZoL тоже. Но только у опеннетчиков на опеннете. У них тут своя, опеннетная реальность.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	86. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	–3 +/–
	Сообщение от Аноним (86), 14-Апр-20, 12:00
	>NDISWrapper Ммм как бы тебе сообщить это, но даже когда оно было актуально, оно не очень прекрасно работало. И разве оно не заггружалось через прослойку в неизменном виде? У вас там что, дрова тоже через линуксулятор работают? 32 бита онли?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	89. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+2 +/–
	Сообщение от Аноним (-), 14-Апр-20, 12:18
	>>NDISWrapper > Ммм как бы тебе сообщить это, но даже когда оно было актуально, оно не очень прекрасно работало. Ммм, как бы тебе сообщить это: даже если это так, то ... это ровным счетом ничего не меняет. > И разве оно не заггружалось через прослойку в неизменном виде? Принцип тот же - великодушно выпущенные (и зачастую креноватые и доводимые до "gpu hung всего лишь раз в неделю! Ура!" состояния иногда по нескольку лет) для пингвинят дрова от интеля загружается через враппер - потому что менять там что-то даже сами интеловцы не очень любят. > У вас там что, дрова тоже через линуксулятор работают? 32 бита онли? Казалось бы, причем тут линуксулятор, да еще и 32 бита?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	92. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	–3 +/–
	Сообщение от Аноним (86), 14-Апр-20, 12:28
	Ну ты сравнил проприетарные блобы другой системы, нелегально загружаемые через крап, и ворованные исходники, написанные (пусть и криво) производителем для своих карточек. Это разные вещи. >причем тут Вот и мне непонятна логика твоих сравнений портированных исходников дров (с клеем или без -- неважно) с эмуляцией для блобов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	96. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+3 +/–
	Сообщение от Аноним (-), 14-Апр-20, 12:37
	> и ворованные исходники И у кого интель их слямзил? > Вот и мне непонятна Судя по всему, вся тема в целом анониму не очень понятна, но почему-то аноним настойчиво высказывает свое ценнейшее мнение.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	97. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	–2 +/–
	Сообщение от Аноним (86), 14-Апр-20, 12:47
	> И у кого интель их слямзил? При чём тут интел, когда он абстрактный? > Судя по всему, вся тема в целом анониму не очень понятна, но > почему-то аноним настойчиво высказывает свое ценнейшее мнение. Зато анониму надо обязательно приплести неревантный треш из каменного века, из тех времён, когда драйверов с исходниками производители принципиально не выпускали.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	102. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от Аноним (102), 14-Апр-20, 14:25
	>> И у кого интель их слямзил? > При чём тут интел, когда он абстрактный? В вакууме, сферический? > Зато анониму надо обязательно приплести неревантный треш из каменного века, из тех времён, когда драйверов с исходниками производители принципиально не выпускали. Если аноним опеннета чего-то не понял, то это не пробел в знаниях опеннетного анонма (ибо опеннетные анонимы знают все-все-все), а просто "нерелевантный треш". Именно так и никак не иначе!
	Ответить \| Правка \| Наверх \| Cообщить модератору

4. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+1 +/–
Сообщение от Аноним (4), 13-Апр-20, 16:42
из всего списка меня больше всего волнует if_bridge
Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от abi (?), 13-Апр-20, 17:36
	ng_bridge этих недостатков не имеет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от Аноним (22), 13-Апр-20, 17:45
	С фигали?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	–3 +/–
	Сообщение от Аноним (4), 13-Апр-20, 17:51
	ты думаешь у них разные клумбы в цветочнике по имени ядро?
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	59. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+6 +/–
	Сообщение от ААА (?), 13-Апр-20, 22:23
	В цветнике. Цветочник это дяденька такой, цветы продаёт.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	174. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от bOOster (ok), 17-Апр-20, 09:05
	Клумба в виде netgraph то одна, цветочки абсолютно разные. Одни пыльцу и мед пчелкам дают, другие мух ловят.
	Ответить \| Правка \| К родителю #24 \| Наверх \| Cообщить модератору


	175. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от bOOster (ok), 17-Апр-20, 09:08
	Убогие линукс последователи никак врубиться не могут - что сетевая подсистема FreeBSD не работает в общем ядре как таковом. к Ядру прицеплен netgraph а дальше уже стэк протоколов.
	Ответить \| Правка \| К родителю #24 \| Наверх \| Cообщить модератору


	129. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от Аноним (4), 14-Апр-20, 21:10
	жаль, что tuntap на данный момент имеет те же проблемы, как написал в рассылке kp@
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору

5. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	–4 +/–
Сообщение от Аноним (86), 13-Апр-20, 16:45
Подскажите, почему llvm всегда генерирует дефективный код даже на amd64? Ведь сколько лет его разрабатывают, почти что сколько и gcc… Что не логично, так это то, что его и в вулкан пихать пытаются. Я хочу логичное объяснение, почему популярный у проприерасов и всяческих противников свободы компиялтор такое убожество.
Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+3 +/–
	Сообщение от Аноним (6), 13-Апр-20, 16:51
	Пруфы? Без них просто наброс фанатика GPL.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	–6 +/–
	Сообщение от Аноним (86), 13-Апр-20, 17:00
	Не, не, поймите правильно, я не говорю что гцц идеален. У него просто астрономическое количество регрессий и багов выплывает (регулярно), а производительность что-то там на 30% ниже проприетарного интеловского компилятора (который ммм адок ещё тот, насколько мне известно, да и вопросы совместимости есть). Но для свободного продукта это нормально, он хотя бы стабильно лучше "стандарта" msvc. А тут продукт любимый всяческими корпорациями, а код стабильно дерьмовый продуцирует. Под стабильно я понимаю стабильно. Это регулярно обсуждается. Если хочется хомячковый аргумент, то для среднего по больнице можно на мандриву посмотреть, она в любом попугаеметре будет проигрывать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+10 +/–
	Сообщение от Аноним (6), 13-Апр-20, 17:10
	Столько текста и всё зря. Если нет внятного аргумента, а лишь невнятные отсылки, не стоило обсирать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	–4 +/–
	Сообщение от Аноним (86), 13-Апр-20, 17:18
	А смысл? Я ничего не обсираю, это общеизвестная общепринятая информация. Вон в соседнем треде разбирали генерируемый им ассемблер. Он может нагенерировать лапшу из переходов, но не может выбрать нормальные инструкции. А "срезать углы" замечательно и gcc может, pgo просто сказка.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от Аноним (6), 13-Апр-20, 17:24
	Ссылочку на тот тред, пожалуйста.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от Аноним (86), 13-Апр-20, 17:41
	Как? Поисковики не индексируют, поиска тут нет. Вся конкурентоспособность сводится к способности генерировать лапшу из переходов. Но лапша эта может оказаться совершенно не эффективной в зависимости от данных. Вот какая-то хомячковая статья откуда-то оттуда же, может для иллюстрации сойдёт https://habr.com/ru/post/483864/
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от Аноним (6), 13-Апр-20, 20:15
	>Поисковики не индексируют Индексируют. Запрос вида: site:opennet.ru запрос
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от Аноним (86), 13-Апр-20, 20:37
	По-моему там только новости, не комменты.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+/–
	Сообщение от Аноним (6), 13-Апр-20, 21:16
	В гугле ищи.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Отчёт о развитии FreeBSD за первый квартал 2020 года"	+1 +/–
	Сообщение от TheFotoMag (ok), 13-Апр-20, 18:41
	>> Я ничего не обсираю, это общеизвестная общепринятая информация То есть, от разработки вы далеки бесконечно?
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору