Между вводом адреса загрузки в восьмеричном формате и кучей неотпимального говнокода на python есть огромная пропасть. Uboot - далеко не главный пожиратель ресурсов.
Простите, что задаю вопрос, а не иду читать об архитектуре GPT-подобных сетей.
Получается, что объем контекста, которым может оперировать сеть, ограничивается размером (количеством токенов) входного слоя? В отличие от RNN, где можно передавать токены+скрытое состояние, что в теории (с поправкой на затухание градиента и прочее) контекст не ограничен, пока мы передаем скрытое состояние? Можно ли делать рекурентный трансформер, где некое скрытое состояние передается в следующий запрос, чтобы преодолеть ограничение на объем контекста?
Gentoo не использовал, поэтому не знаю, как оно там. У Gentoo там есть еще механизм слотов, возможно, там все совсем хорошо.
Как пользовтаель Arch не испытываю проблем с обновлениями, потому что роллинг и репозиторий оперативно обновляется на свежие версии. Хотя суть остается - использование разных версий зависимостей в системе - боль.
Эти проблемы на мою жизнь особо не влияют, почему нужно о них задумываться?
Это из разряда рассуждений о вечном и прекрасном :)
А менеджер пакетов, как в настольных линуксах, приводит к тому, что требуются мейнтейнеры, которые разруливают зависимости, чтобы всё в репозитории зависело от одних и тех же версий библиотек. Что приводит к хорошо известным проблемам: трудности с обновлением на более новые версии, кучу работы мейнтейнеров и вообще превращение всего дистрибутива и репозиториев под него в огромный монолит.
К сожалению, в 2022 году настольные линуксы плохо умеют в решение DLL hell
На Делфи не писал. Но самое простое и юзабельно в плане разработки GUI, с чем я сталкивался - это VB6. IDE, маленький бинарь. Потом я перекатился на C#, и там уже все тянет за собой целый .NET, и Qt, который тоже немаленький.
Еще был (есть) C++ Builder, в котором был и редактор форм, и целая хренова туча виджетов, втч всяких сложных. И еще помню были всякие пакеты компонетов для C++ Builder. Эх, времена.
Что касается GUI, то чем более новая технология, тем она сложнее и выше порог входа.
К примеру, хочешь ты принтануть содержимое структуры несколько раз
Их есть у меня. Без ООП, абстракций, а исключительно печать структур, при этом не какой-нибудь там отдельной функцией в буфер, а возможность печатать структуру как один из спецификаторов форматной строки: https://github.com/Garrus007/advanced-fprintf
Вот что получаем:
struct foo foo = { .a=1, .b=2 };
struct bar bar = { .a=3.14, .b=10, .c="hello world" };
aprintf("Print: int: %d, foo: %Y, str: '%s', bar: %Y, bad one: %Y. The end!\n",
123,
FORMAT_FOO(&foo),
"some string",
FORMAT_BAR(&bar),
FORMAT_FOO(NULL));
Подготовка за кулисами
Ну, тут придется немного пописать, чтобы предоставить структуре возможность печататься...
struct foo
{
int a;
int b;
};
// Function to print "struct foo" to the FILE*
void format_foo(FILE* f, void* data)
{
if (data == NULL) {
fprintf(f, "foo(nill)");
return;
}
struct foo* foo = (struct foo*)data;
fprintf(f, "foo{a=%d, b=%d}", foo->a, foo->b);
}
#define FORMAT_FOO(ptr)format_foo, (ptr)
Под капотом
А вот тут колдунство. Согласно стандарту, семейство *printf-функций не трогает "лишние" аргументы, после того, как форматная строка закончилась.
afprintf - это враппер над fprintf, который находит специальный спецификатор формата %Y, разделяет форматную строку по границе этого спецификатора, скармилвает подстроку обычному fprintf, потом печатает кастомную структуру, используая переданный указатель на функцию печати, а затем продолжает печатать обычным fprintf до следующего %Y или до конца форматной строки.
Плюсы:
можно печатать структуру, задавая ее в форматной строке
можно печатать сразу несколько структур (нет какого-то буфера, который затрется)
Про то, что вы пишете (практически) только про веб-разработчиков, полностью опуская как разработчиков всего нижележащего (ОС, компиляторы, движки, фреймворки итп), так и забываете прикладников из других отраслей (где помимо Python и JS - C#, Java, Kotlin, Swift, C++ и чего только нет) уже сказали.
О том, что это все может быть ненужно для того, чтобы быть спецом - тоже сказали.
Но я не соглашусь с тезисом.
демотиватор
сложности с которыми можно столкнуться по пути и ответить на вопрос, что делает кодоклепателя настоящим специалистом.
Разве это демотиватор? Я трогал и работал с кучей технологий из разных направлений, потому что это было интересно в тот или иной период. Разработка GUI приложений под винду на WinAPI, Qt (C++), Windows Forms, WPF (C#). Веб разработка на ASP.NET и весь этот вот HTML, CSS, JS, React, Vue. Разработка мобильных приложенйи на Java, Kotlin. Программирование микроконтроллеров на C. Библиотеки и утилиты под линукс на C и Python. Разработка модулей ядра Linux. Компьютерное зрение на OpenCV. Роботы на ROS. Нейронные сети с Keras. OpenGL. Ассемблер. Ядро ОС. Где-то в универских годах пылятся трансляторы и verilog.
Я дилетант широкого профиля (в основном - всё-таки Си), и не такой успешный, как 25-летние сеньоры, получающие 500к/нсек. Но ничуть не могу сказать, что столкновение с кучей технологий на разных языках, стеках и уровнях абстракции - это какой-то демотиватор, отталкивающий от работы программистом. Наоборот, это просто офигенно, и возможность потрогать какую-нибудь технологию, иногда совсем из другого конца стека технологий - это приятно и интересно.
Часто вижу в обсуждениях "плохие районы", "no go районы" итп, при этом упоминалось, что границы довольно резкие. Выглядит, как какое-то неявное знание, которое для любителя рандомно бездумно шляться, вроде меня, может выйти боком.
Интересно, существуют ли карты опасности? Или стоимость жилья - достаточный показатель?
На правах шутки
З.Ы. Интересно, гео-сервис (если его нет) криминогенной опасности территорий - это нетолерантно или еще нет?
что с бездомными тут тоже всё сильно хуже, чем в среднем в Европе, а оно, короче, наоборот.
Так это в Остине и прочих "красных" местах? Согласно комментам к этому же посту (где-то в верху) в ЛА целые палаточные городки на площадях, под мостами.
Можете поделиться знаниями или точкой входа в существующие актуальные алгоритмы/реализации SLAM? В университете хотим испытать и сравнить различные SLAM'ы для использования на небольшой автономной машинке.
По Visual SLAM я знаю (и пробовал) родной софт zed-камеры и (в меньшей степени) ORB-SLAM2. ZED хорошо работает на небольших расстояниях (в пределах комнаты), но на бОльших расстояниях (большое помещение, улица) очень часто неправильно определяет углы поворота по yaw и весь трек уплывает.
Лидарами тоже интересуюсь ("игрался" с Velodyne VLP-16). Тестировали известный SLAM LOAM и его модификацию LeGO-LOAM.
Из какого-то списка SLAM'ов со сравнениями знаю только бенчмарк KITTI.
З.Ы. А, я невнимательный. Вы в этой статье привели пару публикаций по SLAM'ам.
Благодарю вас за изложенные мысли в этом и в других комментариях в этом треде. Ваши мысли очень близки к тому, к чему я сам пришел в процессе рассуждений (разумеется, дилетантских) на эти темы.
Собственно, ИМХО: страх смерти и неприятие переноса, телепорта итп - это не отражение каких-то объективных, имеющих материальную природу, вещей, а "convention", наше интуитивное (возможно, рожденое культурой и социумом) представление о положении вещей.
Добавлю от себя несколько рассуждений на тему иллюзорности подобной сильной привязки к "я/не я":
Замечено, что люди в штыки воспринимают деструктивные и способы переноса/телепорта, но нормально воспринимают "плавный" перенос/синхронизацию (как можно заметить по этому треду):
Вот это уже больше похоже именно на научную фантастику - перетекание сознания в другое тел, без прерывания восприятия этим сознанием действительности. Ведь даже если человек в отключке, спит, он не перестаёт осозновать .Спит личность, а мозг продолжает работать.
В данном случае, интересен мысленный эксперимент с устремлением времени синхронизации в пределе к нулю.
Еще можно рассуждать о смерти мозга. Этот процесс явно не мгновенный, и вряд ли можно провести строгую черту между моментами, когда "я" еще существует, и когда "я" уже не существует. Например (боюсь, сильное допущение с точки зрения биологии), с помощью "наносборщиков" (раз уж мы весь организм можем собрать при телепортации), осуществить ремонт/замену поврежденных/мертвых кислородным голоданием/продуктами обмена клеток головного мозга, чтобы восстановить его функционирование (и сознание) после смерти мозга.
Зачем договариваться? Достаточно копировать, что и просходит на рынке.
Очень популярный производитель A выпускает телефон с фичей Х или определенным дизайном.
Производители B, C, ... Z со временем начинают выпускать телефоны с похожим дизайном и похожим набором фич, видимо, потому что это повысит спрос на их продукцию (напр., смартфон без фичи X будет менее конкуретно-способен).
Можете наблюдать на примере эволюции дизайна смартфонов или появления различных особенностей (например, вырезов в экране).
Между вводом адреса загрузки в восьмеричном формате и кучей неотпимального говнокода на python есть огромная пропасть. Uboot - далеко не главный пожиратель ресурсов.
Достаточно дообучать на этих диалогах.
Простите, что задаю вопрос, а не иду читать об архитектуре GPT-подобных сетей.
Получается, что объем контекста, которым может оперировать сеть, ограничивается размером (количеством токенов) входного слоя? В отличие от RNN, где можно передавать токены+скрытое состояние, что в теории (с поправкой на затухание градиента и прочее) контекст не ограничен, пока мы передаем скрытое состояние? Можно ли делать рекурентный трансформер, где некое скрытое состояние передается в следующий запрос, чтобы преодолеть ограничение на объем контекста?
Как Вы себе это представляете? kernel.org (а также всевозможные дистрибутивы) будет блокировать айпишники из РФ?
Посыпаю голову пеплом.
Насколько я помню, там либо не было .NET, либо был очень-очень старый (чуть ли не 1.0)
Gentoo не использовал, поэтому не знаю, как оно там. У Gentoo там есть еще механизм слотов, возможно, там все совсем хорошо.
Как пользовтаель Arch не испытываю проблем с обновлениями, потому что роллинг и репозиторий оперативно обновляется на свежие версии. Хотя суть остается - использование разных версий зависимостей в системе - боль.
Это из разряда рассуждений о вечном и прекрасном :)
А менеджер пакетов, как в настольных линуксах, приводит к тому, что требуются мейнтейнеры, которые разруливают зависимости, чтобы всё в репозитории зависело от одних и тех же версий библиотек. Что приводит к хорошо известным проблемам: трудности с обновлением на более новые версии, кучу работы мейнтейнеров и вообще превращение всего дистрибутива и репозиториев под него в огромный монолит.
К сожалению, в 2022 году настольные линуксы плохо умеют в решение DLL hell
На Делфи не писал. Но самое простое и юзабельно в плане разработки GUI, с чем я сталкивался - это VB6. IDE, маленький бинарь. Потом я перекатился на C#, и там уже все тянет за собой целый .NET, и Qt, который тоже немаленький.
Еще был (есть) C++ Builder, в котором был и редактор форм, и целая хренова туча виджетов, втч всяких сложных. И еще помню были всякие пакеты компонетов для C++ Builder. Эх, времена.
Что касается GUI, то чем более новая технология, тем она сложнее и выше порог входа.
Их есть у меня. Без ООП, абстракций, а исключительно печать структур, при этом не какой-нибудь там отдельной функцией в буфер, а возможность печатать структуру как один из спецификаторов форматной строки: https://github.com/Garrus007/advanced-fprintf
Вот что получаем:
Подготовка за кулисами
Ну, тут придется немного пописать, чтобы предоставить структуре возможность печататься...
Под капотом
А вот тут колдунство. Согласно стандарту, семейство *printf-функций не трогает "лишние" аргументы, после того, как форматная строка закончилась.
afprintf - это враппер над fprintf, который находит специальный спецификатор формата %Y, разделяет форматную строку по границе этого спецификатора, скармилвает подстроку обычному fprintf, потом печатает кастомную структуру, используая переданный указатель на функцию печати, а затем продолжает печатать обычным fprintf до следующего %Y или до конца форматной строки.
Плюсы:
можно печатать структуру, задавая ее в форматной строке
можно печатать сразу несколько структур (нет какого-то буфера, который затрется)
Минусы:
копирование форматной строки и аллокация
Про то, что вы пишете (практически) только про веб-разработчиков, полностью опуская как разработчиков всего нижележащего (ОС, компиляторы, движки, фреймворки итп), так и забываете прикладников из других отраслей (где помимо Python и JS - C#, Java, Kotlin, Swift, C++ и чего только нет) уже сказали.
О том, что это все может быть ненужно для того, чтобы быть спецом - тоже сказали.
Но я не соглашусь с тезисом.
Разве это демотиватор? Я трогал и работал с кучей технологий из разных направлений, потому что это было интересно в тот или иной период. Разработка GUI приложений под винду на WinAPI, Qt (C++), Windows Forms, WPF (C#). Веб разработка на ASP.NET и весь этот вот HTML, CSS, JS, React, Vue. Разработка мобильных приложенйи на Java, Kotlin. Программирование микроконтроллеров на C. Библиотеки и утилиты под линукс на C и Python. Разработка модулей ядра Linux. Компьютерное зрение на OpenCV. Роботы на ROS. Нейронные сети с Keras. OpenGL. Ассемблер. Ядро ОС. Где-то в универских годах пылятся трансляторы и verilog.
Я дилетант широкого профиля (в основном - всё-таки Си), и не такой успешный, как 25-летние сеньоры, получающие 500к/нсек. Но ничуть не могу сказать, что столкновение с кучей технологий на разных языках, стеках и уровнях абстракции - это какой-то демотиватор, отталкивающий от работы программистом. Наоборот, это просто офигенно, и возможность потрогать какую-нибудь технологию, иногда совсем из другого конца стека технологий - это приятно и интересно.
Напомнило
https://youtu.be/xKmZnIHzldk
<sarcasm>
Вот поэтому так по мир и помотало - Москва, Лондон, NY, Остин. А родились бы сразу в квартире - так другое дело!
</sarcasm>
Часто вижу в обсуждениях "плохие районы", "no go районы" итп, при этом упоминалось, что границы довольно резкие. Выглядит, как какое-то неявное знание, которое для любителя рандомно бездумно шляться, вроде меня, может выйти боком.
Интересно, существуют ли карты опасности? Или стоимость жилья - достаточный показатель?
На правах шутки
З.Ы. Интересно, гео-сервис (если его нет) криминогенной опасности территорий - это нетолерантно или еще нет?
Так это в Остине и прочих "красных" местах? Согласно комментам к этому же посту (где-то в верху) в ЛА целые палаточные городки на площадях, под мостами.
Можете поделиться знаниями или точкой входа в существующие актуальные алгоритмы/реализации SLAM? В университете хотим испытать и сравнить различные SLAM'ы для использования на небольшой автономной машинке.
По Visual SLAM я знаю (и пробовал) родной софт zed-камеры и (в меньшей степени) ORB-SLAM2. ZED хорошо работает на небольших расстояниях (в пределах комнаты), но на бОльших расстояниях (большое помещение, улица) очень часто неправильно определяет углы поворота по yaw и весь трек уплывает.
Лидарами тоже интересуюсь ("игрался" с Velodyne VLP-16). Тестировали известный SLAM LOAM и его модификацию LeGO-LOAM.
Из какого-то списка SLAM'ов со сравнениями знаю только бенчмарк KITTI.
З.Ы. А, я невнимательный. Вы в этой статье привели пару публикаций по SLAM'ам.
Подскажите, какой алгоритм/реализацию и набор датчиков использовали для Visual SLAM?
Благодарю вас за изложенные мысли в этом и в других комментариях в этом треде. Ваши мысли очень близки к тому, к чему я сам пришел в процессе рассуждений (разумеется, дилетантских) на эти темы.
Собственно, ИМХО: страх смерти и неприятие переноса, телепорта итп - это не отражение каких-то объективных, имеющих материальную природу, вещей, а "convention", наше интуитивное (возможно, рожденое культурой и социумом) представление о положении вещей.
Добавлю от себя несколько рассуждений на тему иллюзорности подобной сильной привязки к "я/не я":
Замечено, что люди в штыки воспринимают деструктивные и способы переноса/телепорта, но нормально воспринимают "плавный" перенос/синхронизацию (как можно заметить по этому треду):
В данном случае, интересен мысленный эксперимент с устремлением времени синхронизации в пределе к нулю.
Еще можно рассуждать о смерти мозга. Этот процесс явно не мгновенный, и вряд ли можно провести строгую черту между моментами, когда "я" еще существует, и когда "я" уже не существует.
Например (боюсь, сильное допущение с точки зрения биологии), с помощью "наносборщиков" (раз уж мы весь организм можем собрать при телепортации), осуществить ремонт/замену поврежденных/мертвых кислородным голоданием/продуктами обмена клеток головного мозга, чтобы восстановить его функционирование (и сознание) после смерти мозга.
Зачем договариваться? Достаточно копировать, что и просходит на рынке.
Очень популярный производитель A выпускает телефон с фичей Х или определенным дизайном.
Производители B, C, ... Z со временем начинают выпускать телефоны с похожим дизайном и похожим набором фич, видимо, потому что это повысит спрос на их продукцию (напр., смартфон без фичи X будет менее конкуретно-способен).
Можете наблюдать на примере эволюции дизайна смартфонов или появления различных особенностей (например, вырезов в экране).