С учётом того, что википедия на запрос soc перенаправляет сюда https://ru.wikipedia.org/wiki/Система_на_кристалле, то ответ на первый вопрос не помешал бы.
Прим.: soc это реально много где "система на кристалле".
сомнительно, что все читатели хабра умеют обходить блокировки. Подозреваю, что читают хабр намного больше людей, чем пишут статьи или комментарии;
ресурс русскоязычный, почему бы не сделать удобнее для российской аудитории (в целом, это основной носитель русского языка)? Опять же - расширение аудитории.
И вместо "Авторизация" в большей части текста статьи использовать "Аутентификация". Если от слова аутентификация сводит челюсть, то есть варианты на замену: "Идентификация", "Вход". Также:
Аутентификация — это сам процесс проверки подлинности пользователя, чтобы убедиться, что он является тем, за кого себя выдает. Для аутентификации пользователи могут вводить логин и пароль, биометрические данные или другие методы идентификации.
Авторизация — это процесс проверки прав доступа пользователя к определенным ресурсам или функциям. Он проводится после успешной аутентификации.
Предлагаю давать чуть больше контекста по математическим выкладкам, всё таки в тегах заявлен C++ (которого в статье нет :( ).
Например, в C++ (который Вы упоминаете в первом абзаце) результат выражения (AX, X) очень часто оказывается равен X. (а для "классического" скалярного произведения вроде бы (поправьте) существует другое обозначение, не скобки).
Собственно, основной вопрос: чем "фичекрайний" отличается от менеджера проекта обыкновенного?
Уж очень похоже, судя по описанию.
А если в роли фичекрайнего начинается ощущаться убыль программистских навыков (например, когда пытаешься что-то реализовать сам, вдруг ощущаешь, что навык-то просел: что-то в коде упустил, где-то сделал глупые ошибки) -
Вот тогда это точно: менеджер проекта обыкновенный.
Язык это не только логика, но и возможности среды исполнения.
Если говорить про возможности чистого C:
Чистый C позволяет писать программы без динамической памяти. И в ряде случаев это хорошо. Однако чистому C требуемся стэк (и, возможно, немного локальной памяти). Без стэка C не может. С другой стороны: много ли языков могут работать в таких условиях?
И если пойти чуть дальше:
Ассемблер (который про процессоры, не про браузеры) позволяет писать программы без стэка (правда, иногда подставляя кэш процессора как квази-память для создания ощущения стэка). И в ряде случаев это тоже нужно. А вот тут совсем мало подобных языков.
К чему это? А, да: сомнительно, что таких подобных языков (заменителей C, Asm) много. Вот честно: очень сомнительно. Приведёте парочку примеров?
Если содержимое одной клетки существует изолированно и при крэшах и т.п. восстановление идёт целой клетки, то возможно ли ускорить взаимодействие в микросервисах, используя менее изолированные механизмы?
Как предел такой гранулярностив клетки: переход от микросервисов к монолитным "клеткам", в которых вместо сетевого взаимодействия и других (огромных) накладных расходов будут использоваться существенно быстрые механизмы: прямой вызов функций и т.п.
Отмечу, что есть оценки о десятикратном увеличении нагрузки при использовании микросервисов против монолитов (при том же вычислительном результате). Поэтому такое ускорение очень может иметь смысл.
В общем: при наличии клеток, нужны ли микросервисы?
По-моему, автор статьи слегка передёргивает: безопасности памяти В ПРИНЦИПЕ не может быть, пока есть понятия разъёма pci, pci-ex или подобное.
Так как: типовое взаимодействие с внешним устройством (сетевая карта, звуковая или ещё +100500 устройств): программа отправляет некий адрес памяти во внешнее устройство и потом устройство само, БЕЗ участия центрального процессора, пишет в эту память данные.
Если программа чуть-чуть ошибётся в отправляемом адресе (и укажет на адреса в другой программе/процессе), то от повреждения памяти (по-моему) уже ничего не спасёт.
От этого можно защититься, только работать всё будет слегка медленно.
Примечание: текст по ссылке на CHERI как раз об этом и говорит: защита от некоторых угроз, связанных с виртуальной памятью и C++.
решения нет. Однако рекламироваться всё равно надо;
если у вас облегчённый случай, то заплатив "цуть денех" получите немного попоболи;
если у вас сложный случай, то рекомендуется заплатить много денег единовременно и (об этом явно не говорится) в дальнейшем добавлять по "не так много";
Если рассматривать тему ухода от microsoft office, то:
нужно поднимать проблему (по-моему, одну из самых основных) формата выдачи документов заказчику: пока требуют в условном word/excel/powerpoint - использовать другие продукты это явно себе вредить. Поменяются требования по формату - и (есть надежда) сразу пойдёт движуха к переходу на альтернативные продукты.
Вопрос немного в сторону методики: чем обусловлено использование не одного года (2013 / 2023), а приплюсовка ещё 2,5 месяцев? Подозрение, что за эти 2,5 месяца в 2024 году выпущено больше статей, чем пропорционально в 2023 году. Так?
По-моему, очень сильно притянутые за уши примеры кода.
Эта статья мало того, что автоматически переведённая (порадовал термин "Поймал" в табличке), так и примеры приведены странные.
Например, в статье приводится такой код:
#include <stdlib.h>
int main() {
char *p = malloc(16);
char *p2 = malloc(16);
p[24] = 1; // выход за пределы буфера, в p всего 16 байт
free(p2); // free(): некорректный указатель
free(p);
return 0;
}
И утверждается, что glibc такое ловит и это хорошо. Ругается на освобождение p2, так как он некорректный. А чем, собственно, p2 оказался плох? Из примеров это непонятно, и glibc выдаёт какую-то странную диагностику.
Хорошо, попробуем разобраться. И тут выясняется, что если, например p[24] заменить на p[23], то всё отлично будет выполняться: glibc ругаться не будет, всё выполняется без ошибок. Хотя выход за пределы буфера остаётся.
А в сухом остатке: в коде подобран такой параметр, чтобы оно ловилось. То, что для других ошибочных ситуация оно не работает (которых сильно больше) - "Ну ведь это не важно, да?".
Прим: магическое число 24, подозреваю, связано с описателями блоков памяти: после 16 байт валидной памяти выделяется ещё 8 байт, которые можно портить безнаказанно (не падаем на "лёгком" переполнении), а вот дальше - уже проблемы.
Это самый первый вопрос статьи.
Ответа нет.
С учётом того, что википедия на запрос soc перенаправляет сюда https://ru.wikipedia.org/wiki/Система_на_кристалле, то ответ на первый вопрос не помешал бы.
Прим.: soc это реально много где "система на кристалле".
Предложение информационной службе Хабра:
Делать так, чтобы видеоролики появлялись и на rutube тоже. И статья ссылалась (в том числе) и на эти ролики.
Всё таки веяние времени - оно такое.
Добавлено: блокировки, естественно, обходятся. Однако:
обход это лишние (некоторые) действия;
сомнительно, что все читатели хабра умеют обходить блокировки. Подозреваю, что читают хабр намного больше людей, чем пишут статьи или комментарии;
ресурс русскоязычный, почему бы не сделать удобнее для российской аудитории (в целом, это основной носитель русского языка)? Опять же - расширение аудитории.
Поберегите читателей. Уберите "Системное программирование" - нет тут такого.
совсем режет глаз.
Лучше так: "заполняется мусором". И, конечно же, потом этот мусор можно заменить осмысленным значением.
например, пользоваться правильной терминологией.
И вместо "Авторизация" в большей части текста статьи использовать "Аутентификация". Если от слова аутентификация сводит челюсть, то есть варианты на замену: "Идентификация", "Вход". Также:
Предлагаю дополнить статью-инструкцию чисто из логических соображений:
Если в статье описывается как СОЗДАТЬ префикс в портпротон, то почему бы не написать как УДАЛИТЬ префикс в портпротон?
Достаточно ли для этого удалить файлы префикса? Возможно есть какой-то "правильный" способ?
Прим: Очистку префикса пожалуйста не предлагать - она удаления не делает. Удаление/переустановка портпротона целиком тоже не самое хорошее решение.
Предлагаю давать чуть больше контекста по математическим выкладкам, всё таки в тегах заявлен C++ (которого в статье нет :( ).
Например, в C++ (который Вы упоминаете в первом абзаце) результат выражения (AX, X) очень часто оказывается равен X. (а для "классического" скалярного произведения вроде бы (поправьте) существует другое обозначение, не скобки).
Собственно, основной вопрос: чем "фичекрайний" отличается от менеджера проекта обыкновенного?
Уж очень похоже, судя по описанию.
А если в роли фичекрайнего начинается ощущаться убыль программистских навыков (например, когда пытаешься что-то реализовать сам, вдруг ощущаешь, что навык-то просел: что-то в коде упустил, где-то сделал глупые ошибки) -
Вот тогда это точно: менеджер проекта обыкновенный.
Язык это не только логика, но и возможности среды исполнения.
Если говорить про возможности чистого C:
Чистый C позволяет писать программы без динамической памяти. И в ряде случаев это хорошо. Однако чистому C требуемся стэк (и, возможно, немного локальной памяти). Без стэка C не может. С другой стороны: много ли языков могут работать в таких условиях?
И если пойти чуть дальше:
Ассемблер (который про процессоры, не про браузеры) позволяет писать программы без стэка (правда, иногда подставляя кэш процессора как квази-память для создания ощущения стэка). И в ряде случаев это тоже нужно. А вот тут совсем мало подобных языков.
К чему это? А, да: сомнительно, что таких подобных языков (заменителей C, Asm) много. Вот честно: очень сомнительно. Приведёте парочку примеров?
По-моему, Касперский и Ко написал поболее программного обеспечения, чем правительсво сша.
Так что лучше верьте Касперскому.
(можно использовать как сарказм; а можно и не использовать)
Вопрос про производительность и наподумать:
Если содержимое одной клетки существует изолированно и при крэшах и т.п. восстановление идёт целой клетки, то возможно ли ускорить взаимодействие в микросервисах, используя менее изолированные механизмы?
Как предел такой гранулярностив клетки: переход от микросервисов к монолитным "клеткам", в которых вместо сетевого взаимодействия и других (огромных) накладных расходов будут использоваться существенно быстрые механизмы: прямой вызов функций и т.п.
Отмечу, что есть оценки о десятикратном увеличении нагрузки при использовании микросервисов против монолитов (при том же вычислительном результате). Поэтому такое ускорение очень может иметь смысл.
В общем: при наличии клеток, нужны ли микросервисы?
По-моему, автор статьи слегка передёргивает: безопасности памяти В ПРИНЦИПЕ не может быть, пока есть понятия разъёма pci, pci-ex или подобное.
Так как: типовое взаимодействие с внешним устройством (сетевая карта, звуковая или ещё +100500 устройств): программа отправляет некий адрес памяти во внешнее устройство и потом устройство само, БЕЗ участия центрального процессора, пишет в эту память данные.
Если программа чуть-чуть ошибётся в отправляемом адресе (и укажет на адреса в другой программе/процессе), то от повреждения памяти (по-моему) уже ничего не спасёт.
От этого можно защититься, только работать всё будет слегка медленно.
Примечание: текст по ссылке на CHERI как раз об этом и говорит: защита от некоторых угроз, связанных с виртуальной памятью и C++.
Вторая ссылка (платформа VR) ведёт на "todo". Желательно исправить.
Если резюмировать статью, то:
решения нет. Однако рекламироваться всё равно надо;
если у вас облегчённый случай, то заплатив "цуть денех" получите немного попоболи;
если у вас сложный случай, то рекомендуется заплатить много денег единовременно и (об этом явно не говорится) в дальнейшем добавлять по "не так много";
Если рассматривать тему ухода от microsoft office, то:
нужно поднимать проблему (по-моему, одну из самых основных) формата выдачи документов заказчику: пока требуют в условном word/excel/powerpoint - использовать другие продукты это явно себе вредить. Поменяются требования по формату - и (есть надежда) сразу пойдёт движуха к переходу на альтернативные продукты.
По статье создалось ощущение лёгкого мема:
Все отдыхали, потягивая мартини;
Пришёл новый дир по продуктовке;
... И заставил работать! Ты представляешь?!
Хотя, если это так, то всё отлично. Здравый подход.
И всё же вопрос в конкретику: как возросла нагрузка на отдельных сотрудников? Или ChatGPT и т.п. почти всё сам сделал?
Вопрос немного в сторону методики: чем обусловлено использование не одного года (2013 / 2023), а приплюсовка ещё 2,5 месяцев? Подозрение, что за эти 2,5 месяца в 2024 году выпущено больше статей, чем пропорционально в 2023 году. Так?
"Малый бизнес" виноват хотя бы тем, что хочется "Broadcom" кушать.
Поэтому "вкусное" заберём себе, остальные отвалятся сами. Ничего личного, просто бизнес.
По-моему, очень сильно притянутые за уши примеры кода.
Эта статья мало того, что автоматически переведённая (порадовал термин "Поймал" в табличке), так и примеры приведены странные.
Например, в статье приводится такой код:
И утверждается, что glibc такое ловит и это хорошо. Ругается на освобождение p2, так как он некорректный. А чем, собственно, p2 оказался плох? Из примеров это непонятно, и glibc выдаёт какую-то странную диагностику.
Хорошо, попробуем разобраться. И тут выясняется, что если, например p[24] заменить на p[23], то всё отлично будет выполняться: glibc ругаться не будет, всё выполняется без ошибок. Хотя выход за пределы буфера остаётся.
А в сухом остатке: в коде подобран такой параметр, чтобы оно ловилось. То, что для других ошибочных ситуация оно не работает (которых сильно больше) - "Ну ведь это не важно, да?".
Прим: магическое число 24, подозреваю, связано с описателями блоков памяти: после 16 байт валидной памяти выделяется ещё 8 байт, которые можно портить безнаказанно (не падаем на "лёгком" переполнении), а вот дальше - уже проблемы.
Опять реклама ТГ-канала :(.
Такое ощущение, что теперь вместо "вкатиться в айти" все вкатываются в тг.
Э-э-э, граждане США составляют примерно 1/3 среди американцев. Зачем мне подменять понятия?