Щас понимаю что пиннинг это антифича. Хорошо хоть нотификации нашел где отключить

да надо просто при пине её снимать :)

Щас понимаю что пиннинг это антифича. Хорошо хоть нотификации нашел где отключить

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

# iperf3 -c 192.168.3.2 -VZ -M 1024 iperf 3.1.7 FreeBSD xxx.local 10.3-RELEASE-p19 Control connection MSS 524 Time: Thu, 04 Oct 2018 09:42:19 GMT Connecting to host 192.168.3.2, port 5201      Cookie: xxx.1538646139.120949.146      TCP MSS: 1024 iperf3: error - unable to set TCP/SCTP MSS: Invalid argument

может его всё же таки для начала подобновить?

Зачем?

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

Будут. И это вообще не должно так работать

не, если при пине не снять галочку, то оповещение вроде всё одно пройдёт

А никто не в курсе когда Куп планирует портировать gimp 2.10? Он что-нибудь внятное, окромя матов, по этому поводу говорил? =)

Экие страсти, чё там накидывай линком :)

Вопрос снят. Оказывается он отметился буквально четыре дня назад: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227769

вот же ж подлец

вот же ж подлец

Это да =)

Хаха, не похоже на бсдшников гордящихся совместимостью с 1.0. rl оставят, остальному туда и дорога

и нечего будет ставить на Net 5501

О боже ну кто же так набрасывает? Так набрасывай! FCP 101: Deprecation and removal of 10/100 Ethernet drivers https://github.com/freebsd/fcp/blob/master/fcp-0101.md https://lists.freebsd.org/pipermail/freebsd-stable/2018-October/089717.html

чо делать и кто виноват?)

и нечего будет ставить на Net 5501

а он ещё будет, года через 4ре?

а он ещё будет, года через 4ре?

кстати, vr там в исключениях ровно из-за него, хаха

ну вот, всё продумали ;)

Да, набор исключений разумный, если ещё rl добавить

ЭрЭл лютое говно, но очень уж их много было

Народ,а где была картинка "Врачи народ творческий" с подписью реаниматолога?

в гугле? "подпись реаниматолог"

Это надо заскринить, не смогу описать. В общем иксы запускаются, но только три окна, терминал часы и ещё терминал и все кривое )

ну классика, так всегда было )

ну классика, так всегда было )

К сожалению не имею опыта с фряхой :)

это ж именно те программы, для которых были созданы иксы!

оправдано: lo0nix юзеры и не знают о существовании xorg.conf

К сожалению не имею опыта с фряхой :)

так было везде, не только во фряхе

просто в популярных дистрибутивах преднастроенные делают, вот и всё

и нечего будет ставить на Net 5501

Это что?

Это что?

Net 5501? эпичнеше легендарная же железка

Не увлекаюсь легендарным железом:)

так было везде, не только во фряхе

Первый раз сталкиваюсь, на линупсе не было

линукс слишком нубский попался, видимо

Это что?

Ну, такая коробка на 4xNIC из тех времён когда AMD Geode был адеватным процессором.

просто в популярных дистрибутивах преднастроенные делают, вот и всё

мне чот казалось оно там на лету генерится

ну это тонкости

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

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

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

чего это ты там такого нахимичил?

чего это ты там такого нахимичил?

Да на всё даже в фабрикаторе записи есть

и нечего будет ставить на Net 5501

а зачем эта древность нужна?

а зачем эта древность нужна?

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

там написано же, что опрос проводят, напиши что у тебя есть куча машин и ты планируешь 13-ую фрю на них ещё 20 лет гонять

у меня уже нету нигде rl, просто не все читают net@ и для кого то удаление драйвера может стать неожиданностью. Впрочем если кому то очень нажо бужет, можно и обратно вернуть.

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

я все понимаю, но в том же мтс в какой-то момент тупо вычистили все старое сановское железо(все эти нетры и санфаеры)

потому что место занимает, а мощи - как у слабенькго pentium

я все понимаю, но в том же мтс в какой-то момент тупо вычистили все старое сановское железо(все эти нетры и санфаеры)

SunFire 15K ещё пойдти замени!

SunFire 15K ещё пойдти замени!

ну, там были и e25k

их, понятно, никто не заменял

Да не, понятно, что надо парк обновлять, чо уж там.

Эпичные железки кстати

Интересно, сейчас есть нечто подобное по подходам?

Интересно, сейчас есть нечто подобное по подходам?

HP до сих пор non-stop выпускает. IBM System/Z совместимо с IBM/370.

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

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

Fujitsu тоже там что-то имеет

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

Сзади наверняка полка из SSD на FC, а всё те же цилиндры-головки-рекорды

Я никак это себе в голову не могу уложить. Можно же было за 50 лет плавно как-то осовременится. Понятно, что с отставанием в 15 лет, но хоть как-то

Был пост про это на Хабре. Типа до сих пор часть кода на Коболе. Типа мама писала а теперь вот и я тоже пишу вместе с ней.

Сведбанк что ли

ЧАСТЬ?!

ВЕСЬ

Что не на языке заданий JPL Или как его там.

Да, пишут новый код на коболе

Ну там что-то переводят. Но медленно и печально. Оно и понятно - потоки там ого-го

Вообще, с мейнфреймами для меня самое удивительное не это а то, что сколько я не читал — нигде нет нормального объяснения ЗАЧЕМ, ПОЧЕМУ и ЧТО ИМЕННО. IBM Transaction Engine. Что такое транзакция? Нигде не написано. Какова отвественность этого Engine, гарантии, контракты? Нигде не написано. Общий движок обработки пользовательских транзакций. Не документация а сплощное буллшит-бинго

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

ERROR: S client not available

Ну там что-то переводят. Но медленно и печально. Оно и понятно - потоки там ого-го

Да не потоки а 6 слоёв прикрытия задницы от аудита. Потоки в в шведском банке наверняка меньше чем в NASDAQ и, тем более, OPRA (опицонная биржа США). Эти нормально живут на Java даже, на вполне разумном количестве железа, и отлично мигрируют на новые технологии.

> Java даже а может всё же пусть кобол остаётся :)

> Java даже а может всё же пусть кобол остаётся :)

Смешно, да. То, что у Java лучший компилятор в индустрии, конечно, ничего не значит. И многопоточность разве что у Erlang/OTP лучше, а у остальных хуже — это тоже пустяк.

Вообще, вот что в System/Z поражает — это то, что два географически разнесённых мейнфрейма могут выполнять ПОТАКТОВО одинаковый код и проверять друг друга. Но банки это, кажется, не используют.

Вообще, вот что в System/Z поражает — это то, что два географически разнесённых мейнфрейма могут выполнять ПОТАКТОВО одинаковый код и проверять друг друга. Но банки это, кажется, не используют.

Круто!

РЖД вроде традиционно мэйнфрэймы IBM юзает - интересно как у них ?

Смешно, да. То, что у Java лучший компилятор в индустрии, конечно, ничего не значит. И многопоточность разве что у Erlang/OTP лучше, а у остальных хуже — это тоже пустяк.

В java обычные потоки ос. Что там лучше?

В java обычные потоки ос. Что там лучше?

Ох. Почитай на досуге что такое Memory model. Почитай, когда она появилсь в JLS, и когда в C/C++. Почитай что такое пакет java.util.concurrent И как его сейчас спешно повторяют в том же C в виде пакета CK (который начал, слава богу, использоваться в ядре FreeBSD). Да хотя бы начни со стать ХиДжей Боэма (Bohem, который Bohem GC) почему многопоточность в принципе не может быть библиотекой (вот тут есть http://www.hboehm.info/c++mm/), а должна быть в ядре языка. Да, в C/C++ В последние пару стандартнов это, к счастью, осознали, и догоняют. Но пока — догоняют. Rust может быть подтянется. Остальным — думаю, не светит вообще. Я могу прочитать ликбез на эту тему, но только лично и за чаем, чтолько текста мне не набрать.

в гугле? "подпись реаниматолог"

Спасибо)))

Ох. Почитай на досуге что такое Memory model. Почитай, когда она появилсь в JLS, и когда в C/C++. Почитай что такое пакет java.util.concurrent И как его сейчас спешно повторяют в том же C в виде пакета CK (который начал, слава богу, использоваться в ядре FreeBSD). Да хотя бы начни со стать ХиДжей Боэма (Bohem, который Bohem GC) почему многопоточность в принципе не может быть библиотекой (вот тут есть http://www.hboehm.info/c++mm/), а должна быть в ядре языка. Да, в C/C++ В последние пару стандартнов это, к счастью, осознали, и догоняют. Но пока — догоняют. Rust может быть подтянется. Остальным — думаю, не светит вообще. Я могу прочитать ликбез на эту тему, но только лично и за чаем, чтолько текста мне не набрать.

Надо на публике. Типа лекцию. Нынче это модно. Да и полезно. Наверное.

Заполировать всё это можно статьями Лэмпорта (того, который LaTeX, но не LaTeX его главный вклад в computer science) о всякой разной Sequential consistency и остальных моделях Consistency. Проблема, собственно, в том, что как только у нас есть shared state, то потоки становятся очень сложным зверем, и для нормальной производительности требуют не столько хорошего скедулера в OS сколько большого знания оптимизатора кода про concurrency, гарантии, особенности конкретного железа и прочие потроха. В Java из мейнстримных языков это было с самого начала, заложено в стандарт и допилено с пониманием реалий в 2004 году (предыдущая версия 1995 года была в паре мест неоднозначна, как выяснилось впоследствии — вообще это очень сложная область Coputer Science, Вполне хардкорная фундаментальная наука). А вот в C/C++ вся модель языка (абстрактная машина, описанная стандартом) была до недавнего времени строго однопоточноый. Даже volatile был про другое и не имел нужных гарантий. В стандарте 2011 года взяли за основу Java'вскую модель, но подрасширили её (добавили гибкости) ради пары экзотических железок (IMHO, зря, гемморою всем прибавили, а железки и правда какие-то странные). Про другие языки и думать не хочется. Кстати, при всей моей любви к Alpha, в этом месте я рад, что она сдохла. Там на апаратном уровне был ад в смысле гарантий доступа к памяти в многоядерном/многосокетном окружении. Портировать туда Java, например, вышло бы только с адской потерей производительности. На другом конце железного спектра — x86/32 и x86/64, которые ОЧЕНЬ строгие. Именно из-за этого во многом многопоточном софте на C/C++ вылезают баги при перекомпиляции на многоядерный ARM — ARM помягче, и незамеченные баги, которые скрадывались строгими гарантиями модели x86, вылезают во всей красе.

Всё просто если у нас нет Shared State и вот тут сияет недосягаемой звездой Erlang/OTP

Ну, такая коробка на 4xNIC из тех времён когда AMD Geode был адеватным процессором.

Гёде никогда не был адекватным

Гёде никогда не был адекватным

Да ладно, когда 10 мегабит было нормальным коннектом к провайдеру, это был адекватный софтроутер.

Да ладно, когда 10 мегабит было нормальным коннектом к провайдеру, это был адекватный софтроутер.

Разве что. Я с ним знаком только как с десктопом, по проекту 50/15. Там даже ethernet не было

Разве что. Я с ним знаком только как с десктопом, по проекту 50/15. Там даже ethernet не было

Ну, он появился несколько раньше моды пихать в процессор всё.

Это оправдание?

И да, где теперь 50/15?

Уже 18, а всё не 50

Хотя проц по своему прикольный

Ох. Почитай на досуге что такое Memory model. Почитай, когда она появилсь в JLS, и когда в C/C++. Почитай что такое пакет java.util.concurrent И как его сейчас спешно повторяют в том же C в виде пакета CK (который начал, слава богу, использоваться в ядре FreeBSD). Да хотя бы начни со стать ХиДжей Боэма (Bohem, который Bohem GC) почему многопоточность в принципе не может быть библиотекой (вот тут есть http://www.hboehm.info/c++mm/), а должна быть в ядре языка. Да, в C/C++ В последние пару стандартнов это, к счастью, осознали, и догоняют. Но пока — догоняют. Rust может быть подтянется. Остальным — думаю, не светит вообще. Я могу прочитать ликбез на эту тему, но только лично и за чаем, чтолько текста мне не набрать.

я немного про другое. вот у тебя есть c10k/c1m, чем тебе помогут потоки в языке?

Это оправдание?

чему? тому что в проц не запихнули сеть? да. Тому, что конкретная система (что такое этот 50/15 вообще?) сделана без сети? Так тут вообще не к процу вопросы

и строго говоря в том же erlang потоков нет вообще.

чему? тому что в проц не запихнули сеть? да. Тому, что конкретная система (что такое этот 50/15 вообще?) сделана без сети? Так тут вообще не к процу вопросы

Проект амд

я немного про другое. вот у тебя есть c10k/c1m, чем тебе помогут потоки в языке?

ну, хотя бы тем, что тебе нужен m:n. Иначе твоя стейт машина будет на одном ядре.

Довольно эпичный

и строго говоря в том же erlang потоков нет вообще.

ну э. Они там процессы называются. И зелёные, да.

ну, хотя бы тем, что тебе нужен m:n. Иначе твоя стейт машина будет на одном ядре.

да, но потоки в языке означают что у тебя везде они будут"протекать"

да, но потоки в языке означают что у тебя везде они будут"протекать"

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

И не всё программирование сводится к коннектам и независимым стейт-машинам. Потоки — не панацея, разумеется.

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

потоки в языке не нужны, см тот же Go.

И не всё программирование сводится к коннектам и независимым стейт-машинам. Потоки — не панацея, разумеется.

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