1

Отрезано от: Нужна помощь по установке  Linux Mint 19.3

Wolfenberg пишет:
ZhuK пишет:

Аthlon II не способен Full hd? Что-то новенькое на горизонте замаячило.

Способен, но при этом будут лёгкие подтормаживания.

Добро пожаловать в Линукс!
У дочки под виндой 7 стоял athlon II 250. Без проблем кушало hd из интернетов. Модель настолько убогая, что даже разгону не подлежала. И тем не менее.

2

ZhuK пишет:

У дочки под виндой 7 стоял athlon II 250. Без проблем кушало hd из интернетов.

А причём тут проц, в винде работает аппаратное декодирование на видюхе в браузерах.

И в Linux на свежих видюхах nvidia, аппаратное ускорение видео работает в chromium-vaapi.

Arch Linux x86_64 на btrfs

3

Wolf пишет:
ZhuK пишет:

У дочки под виндой 7 стоял athlon II 250. Без проблем кушало hd из интернетов.

А причём тут проц, в винде работает аппаратное декодирование на видюхе в браузерах.

И в Linux на свежих видюхах nvidia, аппаратное ускорение видео работает в chromium-vaapi.

"Видюха" с тех пор так и не поменялась. Radeon 4670. Заоблачный и свежий декодер всего, что ни попадя. Ну и ОС 8 - ми летней давности на тот момент.
Пардон, но было сказано, что под атлоном 2, хд будет подтормаживать. А потом вы спрашиваете - при чем тут проц к хд?
Я запутался.  ag

4

ZhuK пишет:
Wolfenberg пишет:
ZhuK пишет:

Аthlon II не способен Full hd? Что-то новенькое на горизонте замаячило.

Способен, но при этом будут лёгкие подтормаживания.

Добро пожаловать в Линукс!
У дочки под виндой 7 стоял athlon II 250. Без проблем кушало hd из интернетов. Модель настолько убогая, что даже разгону не подлежала. И тем не менее.

У меня - нет ab
Отключал видеокарту и переходил на встроенное - процессор вис намертво на Full HD. Были такие порясающие артефакты, что словами не передать.
*** Добавлено: 25.05.2020 07:06:18 ***

ZhuK пишет:
Wolf пишет:
ZhuK пишет:

У дочки под виндой 7 стоял athlon II 250. Без проблем кушало hd из интернетов.

А причём тут проц, в винде работает аппаратное декодирование на видюхе в браузерах.

И в Linux на свежих видюхах nvidia, аппаратное ускорение видео работает в chromium-vaapi.

"Видюха" с тех пор так и не поменялась. Radeon 4670. Заоблачный и свежий декодер всего, что ни попадя. Ну и ОС 8 - ми летней давности на тот момент.
Пардон, но было сказано, что под атлоном 2, хд будет подтормаживать. А потом вы спрашиваете - при чем тут проц к хд?
Я запутался.  ag

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

Linux Mint 19.3 Mate Edition
Windows 7

5

ZhuK пишет:

А потом вы спрашиваете - при чем тут проц к хд?

https://img11.lostpic.net/2020/05/25/08cdb59cb8f84d1c69b9cee92fc5f7a3.th.png

Проц AMD Athlon(tm) X4 840

Arch Linux x86_64 на btrfs

6

Wolfenberg пишет:

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

Что значит минимальную графику?
АМ3 разработан для параллельной ветки.... Тут запутался ещё сильнее. Что за источники информации у вас?
*** Добавлено: 25.05.2020 18:50:20 ***

Проц fx 4300 загрузка при просмотре хд 13-23%. Опера. Винда 7. Видео radeon 4670.
Добро пожаловать в Линукс!
Если я вас правильно понял.
Разница в производительности между этими процами выявляется только бэнчмарками. На глаз не заметите.
Что то явно в оптимизации не то.

7 (26.05.2020 09:22:12 отредактировано Wolfenberg)

ZhuK,

Что значит минимальную графику?

SD 320 максимум. В основном, так любимый вами DivX.

ZhuK пишет:

АМ3 разработан для параллельной ветки.... Тут запутался ещё сильнее. Что за источники информации у вас?

У меня сокет FM2+ он поддерживает два вида процессоров: с возможностью обработки графики (серия AMD A) и без оной (серия Athlon II)

Linux Mint 19.3 Mate Edition
Windows 7

8

Понял, спасибо. Но все равно не ясно, как процессор не имеющий графического ядра может поддерживать минимальную графику. Но в любом случае это не важно. Ибо, как я понимаю, Ютуб явно divx не использует и процессор работает насколько это требуется.
Другими словами: 4670 это не та видеокарта, которая что то способна. Атлон 250 тоже не шедевр. Но не тормозило с Ютуб. Думаю загвоздка в ОС. И это видно по загрузке схожих процессоров.
Но есть и хорошая новость. Линус пересел на процессор от АМД. Есть шанс на более качественную оптимизацию ядра под АМД.
Мои любимые кодеки h264 и h265.

9

ZhuK пишет:

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

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

Linux Mint 19.3 Mate Edition
Windows 7

10

Wolfenberg пишет:

из-за гневных воплей "геймеров", которым подавай 100500 ядер и турбину в пятую точку.

Ну не будем так с горяча.  ag  Линус Торвальдс пересел на АМД именно из за количества ядер и потоков. Под которыми его задачи выполняются быстрее. Так что не только геймеры.

11 (28.05.2020 15:32:04 отредактировано ValentinK)

ZhuK пишет:

Линус Торвальдс пересел на АМД именно из за количества ядер и потоков.

Он это сделал также ради престижа!
У старшего - старшая модель проца и компа.
Хотя, скорее всего, будет оптимизировать ядро под многоядерные системы.

Fedora 35 KDE.
Linux is great and super! Long live rock'n'roll! Opera and libretto.
По-русски калинка-малинка моя! Люблю оливье и винегрет.
Yours sincerely, wasting away! Salute people!

12

ValentinK пишет:

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

А что это такое - многоядерные системы?

13

ZhuK пишет:
ValentinK пишет:

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

А что это такое - многоядерные системы?

Уточняю. Многоядерные и многопоточные процессора хотел сказать.
А Вы могли бы и догадаться.

Fedora 35 KDE.
Linux is great and super! Long live rock'n'roll! Opera and libretto.
По-русски калинка-малинка моя! Люблю оливье и винегрет.
Yours sincerely, wasting away! Salute people!

14

Я предполагал, но решил уточнить.
А не поздно начинать оптимизацию? Многоядерные на рынке лет 13 уже.  ag
Я не специалист, но мне кажется, что приложений использующих многоядерность/многопоточность не так уж много. Может с них начать?

15 (29.05.2020 15:40:30 отредактировано ValentinK)

ZhuK пишет:

Я предполагал, но решил уточнить.

ОК!

ZhuK пишет:

А не поздно начинать оптимизацию? Многоядерные на рынке лет 13 уже.  ag
Я не специалист, но мне кажется, что приложений использующих многоядерность/многопоточность не так уж много. Может с них начать?

Так ведь ядер много, а сокет на плате один.
Хотя в процессоре имеется несколько контроллеров доступа к памяти.
Но системная шина одна.
Задачи выполняются параллельно, но данные скидываются по очереди.
Ещё, если система многозадачная, то может каждой задаче выделять процессорное ядро.
Или из-за одного сокета всё равно получается система с разделением времени?
Ну, скажем, есть главный процесс-супервизор, рапределяющий процессам время процессора и память.
Вот интересно, как он работает со многими ядрами.
Это ведь совсем нетривиальная задача.

Fedora 35 KDE.
Linux is great and super! Long live rock'n'roll! Opera and libretto.
По-русски калинка-малинка моя! Люблю оливье и винегрет.
Yours sincerely, wasting away! Salute people!

16

А при чем тут системная шина и как она мешает вычислительном процессу?

17

ZhuK пишет:

А при чем тут системная шина и как она мешает вычислительном процессу?

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

Fedora 35 KDE.
Linux is great and super! Long live rock'n'roll! Opera and libretto.
По-русски калинка-малинка моя! Люблю оливье и винегрет.
Yours sincerely, wasting away! Salute people!

18

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

19

ValentinK пишет:

Вот интересно, как он работает со многими ядрами.
Это ведь совсем нетривиальная задача.

Эта задача упрощается до вполне понимабельного уровня в акторной модели выполнения -
так работают, например, Erlang, и Akka - для Java-мира.
То бишь процессы, сообщения (а именно запросы и ответы),
и все разделяемые ресурсы - тоже процессы, хоть ты тресни.
Над всей этой красотой надзирает супервизор (не более чем ещё один процесс ab) -
и, если он располагает адекватной системой ранжирования процессов по приоритетам,
даже и конкуреннтые системы работают ожидаемым и предсказуемым образом.
Отдельно следует отметить проблему времени при согласовании работы процессов -
чтобы система была актуальной в каждый момент времени и давала релевантные ответы именно
для текущего состояния "обрабатываемого мира" -
чтобы не вышло так, что выдан ответ по текущему состоянию какой-нибудь структуры,
а через мгновение в эту структуру прилетает нечто,
требующее дать совершенно другой ответ на тот же самый запрос.

Но! Так выглядит работа с зелёными, легковесными, в отличие от процессов ОС, процессами.
На более низком уровне, внутри BEAM, JVM, ядер ОС -
треша и угара ещё больше. Борются с ними и вышеприведёнными методами, и более врукопашную.
Но так мой пост никогда не кончится ab

Давно уже не забавно наблюдать торжество отрицательного отбора.

20

ZhuK пишет:

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

Всё равно путь один. Сокет процессора один. Дорожки на плате для обмена данными одни для всех ядер вместе.
*** Добавлено: 30.05.2020 12:52:53 ***

Chars67 пишет:

Эта задача упрощается до вполне понимабельного уровня в акторной модели выполнения -
так работают, например, Erlang, и Akka - для Java-мира.

Акторы - это UML?

Chars67 пишет:

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

Это очень интересно!

Chars67 пишет:

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

Но! Так выглядит работа с зелёными, легковесными, в отличие от процессов ОС, процессами.
На более низком уровне, внутри BEAM, JVM, ядер ОС -
треша и угара ещё больше. Борются с ними и вышеприведёнными методами, и более врукопашную.
Но так мой пост никогда не кончится

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

Fedora 35 KDE.
Linux is great and super! Long live rock'n'roll! Opera and libretto.
По-русски калинка-малинка моя! Люблю оливье и винегрет.
Yours sincerely, wasting away! Salute people!

21

ValentinK пишет:

Акторы - это UML?

По большому счёту - да.
И при визуализации архитектуры системы в erlang:Observer используется именно UML.
Просто разные уровни абстракции одной модели, акторной:
в рамках UML рисуется картинка, чтобы начать забарывать сложность,
в рамках инфраструктуры Erlang/Elixir пишется код
(не сильно отличается от картинки - потому что скриптота с динамической типизацией),
а когда вся эта красота начинает тормозить,
на С/C++ переписываются тормозные участки кода, имея перед глазами рабочий прототип.
Дык встроенные функции (стандартная библиотека языка) Erlang отродясь на С писалась ab

ValentinK пишет:

Получается, супервизор один, а процессов десятки и сотни и тысячи.

Дерево супервизоров - совершенно устойчивое понятие  ab
И большой ай-я-яй - в адрес архитектора системы. Проще надо быть, проще.
Чему помогает Процесс-Ориентированное Программирование (а не ООП).
Не тупая замена объектов процессами, а по-умному ab

В Scala+Akka - сложнее с переписыванием - тут уже в кишки JVM надо залезать,
чтобы получить от кода на С реальное ускорение работы.
Но исходные принципы модели - одни и те же.

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

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

Давно уже не забавно наблюдать торжество отрицательного отбора.

22

Chars67 пишет:

По большому счёту - да.
И при визуализации архитектуры системы в erlang:Observer используется именно UML.
Просто разные уровни абстракции одной модели, акторной:
в рамках UML рисуется картинка, чтобы начать забарывать сложность,
в рамках инфраструктуры Erlang/Elixir пишется код
(не сильно отличается от картинки - потому что скриптота с динамической типизацией),
а когда вся эта красота начинает тормозить,
на С/C++ переписываются тормозные участки кода, имея перед глазами рабочий прототип.
Дык встроенные функции (стандартная библиотека языка) Erlang отродясь на С писалась

Был такой язык - prolog. (programming logic)
Задавались начальные условия, а остальное выводилось логически.
Я лично только читал книгу по prolog.
Про Erlang слышал, но не знаком.
Сам программировал только приложения баз данных на RAD + SQL.
Иногда тонкий клиент на Web.
Грубо говоря, прикручивал морды к базе данных.
Есть ещё интересная задача - распараллеливание запросов к базам данных.

Chars67 пишет:

Дерево супервизоров - совершенно устойчивое понятие  ab
И большой ай-я-яй - в адрес архитектора системы. Проще надо быть, проще.
Чему помогает Процесс-Ориентированное Программирование (а не ООП).
Не тупая замена объектов процессами, а по-умному

Вот вы и коснулись вопроса иерархичности процессов.
Используя то же ООП, можно строить иерархию объектов.
За распараллеливание кода отвечает компилятор.
Другое дело, как этот компилятор так написать.
Программирование процедурами - труднее, так как при большом объёме работы требует много процедур без какой бы то ни было иерархии.
Хотя, возможно, работает быстрее.

Chars67 пишет:

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

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

Fedora 35 KDE.
Linux is great and super! Long live rock'n'roll! Opera and libretto.
По-русски калинка-малинка моя! Люблю оливье и винегрет.
Yours sincerely, wasting away! Salute people!

23

Ага. А наиболее прогрессивная часть человечества предпочла работать с одним ядром, но очень мощным. Правда несколько ограниченным, в отличии от ЦП, но действительно мощным. И весьма преуспела в этом.

24 (30.05.2020 17:47:18 отредактировано ValentinK)

ZhuK пишет:

Ага. А наиболее прогрессивная часть человечества предпочла работать с одним ядром, но очень мощным. Правда несколько ограниченным, в отличии от ЦП, но действительно мощным. И весьма преуспела в этом.

Я не говорил, что распараллеливание вычислений - это плохо.
Одно время даже интересовался языком Вирта Modula-3.
Для решения задач математического моделирования физических явлений,
для решения больших матриц линейных уравнений распараллеливание просто необходимо.

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

Fedora 35 KDE.
Linux is great and super! Long live rock'n'roll! Opera and libretto.
По-русски калинка-малинка моя! Люблю оливье и винегрет.
Yours sincerely, wasting away! Salute people!

25

ValentinK пишет:

Был такой язык - Prolog.

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

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

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

А ещё - это "моя первая любовь" в программировании ab

ValentinK пишет:

Используя то же ООП, можно строить иерархию объектов.

Наверно, вы имели в виду иерархию типов.

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

Что же касается соответствующих компиляторов...
Альтернатива - Erlang/Elixir+OTP или Scala/Akka - не как языки,
а скорее как фреймворки для работы со всеми этими умными словами -
параллельность, конкуррентность, дистрибутивность.

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

Давно уже не забавно наблюдать торжество отрицательного отбора.

26 (30.05.2020 19:06:42 отредактировано ValentinK)

Chars67 пишет:

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

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

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

Chars67 пишет:

Наверно, вы имели в виду иерархию типов.

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

ООП и предпологает наследование и повторное использование кода объектами или классами.
Существуют даже вирутальные, перезаписываемые методы.
Актор, в сущности, тоже объект и взаимодействует с классами ввода-вывода и через них дополнительных расчётов.

Chars67 пишет:

Что же касается соответствующих компиляторов...
Альтернатива - Erlang/Elixir+OTP или Scala/Akka - не как языки,
а скорее как фреймворки для работы со всеми этими умными словами -
параллельность, конкуррентность, дистрибутивность.

Вы меня заинтересовали.
Scala вроде как работает на JVM.
Я знаю Java и C# - очень удобно, когда не надо вручную уничтожать объекты и возникает меньше ошибок с выделением памяти.
Параллельность в них реализована классом Thread - можно запускать параллельные потоки.
Вообще, объектно-событийная модель присуща всем RAD - Rapid Application Development инструментам.

Fedora 35 KDE.
Linux is great and super! Long live rock'n'roll! Opera and libretto.
По-русски калинка-малинка моя! Люблю оливье и винегрет.
Yours sincerely, wasting away! Salute people!

27

ValentinK пишет:

Декларативный язык предполагает решающий задачи движок.

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

Что же касается символьных вычислений...
У Клоксина и Меллиша в книжке по Прологу зачатки были даны для программы символьного дифференцирования.
Показал их старшему сыну, когда он Matlab в ЛЭТИ изучал. Теперь деточка работает в Алмаз-Антей, куда его взяли с радостным визгом.
А то у них там всё больше на Delphy и десятилетней давности.

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

ValentinK пишет:

Актор, в сущности, тоже объект и взаимодействует с классами ввода-вывода

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

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

ValentinK пишет:

Scala вроде как работает на JVM.

Да, но есть и забавная такая игрушка - Scala native.

ValentinK пишет:

Параллельность в них реализована классом Thread

Затруднюсь назвать больший источник непоняток.
Потому и выдумали Akka.

Давно уже не забавно наблюдать торжество отрицательного отбора.

28 (30.05.2020 20:19:10 отредактировано ValentinK)

Я учился за границей. В Польской Республике, в Варшавском Университете.  Факультет Математики, Информатики и Механики.
Магистр по специальности Прикладная математика.
Мой отец - пухлый рыцарь и царь.
И он меня мучал больницами.
Я программирую на II категорию (от III до i) и на 4 разряд (от 1 до 6).
Разбираюсь в средах RAD и в реляционных базах данных.
Но тоже не дурак.
А меня крючили апостолы, им слово магистр нравится, считают магистра за грузчика в продуктовом магазине.
Но это плохой счёт.
А понятиями они не думают и не мыслят.
Если интересно, мой сайт http://valentink.site90.net

Fedora 35 KDE.
Linux is great and super! Long live rock'n'roll! Opera and libretto.
По-русски калинка-малинка моя! Люблю оливье и винегрет.
Yours sincerely, wasting away! Salute people!

29

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

ᛈᚺ'ᚾᚷᛚᚢᛁ ᛗᚷᛚᚹ'ᚾᚨᚠᚺ ᚲᛏᚺᚢᛚᚺᚢ ᚱ'lᚷᛖᚺ ᚹᚷᚨᚺ'ᚾᚨᚷᛚ ᚠᚺᛏᚨᚷᚾ

Asus Prime B460M-K, i5-10500, Intel 630 UHD, DDR4 32 GB, SSD 500GB + HDD 2TB | Linux Mint 21.3 Cinnamon + Fedora 39 MATE (Compiz) + Windows 11 + macOS 12 Monterey

30 (31.05.2020 21:36:55 отредактировано ZhuK)

Rizado пишет:

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

Гдеж они там от распараллеливания процессов к политике свалились?!  ag
Rizado, обратил внимание, что в профиле у тебя ryzen. А что стояло до этого и насколько ощутима разница в производительности? Да, и почему винда 7 а не 10?