makcplan, лучше создайте новый вопрос. Я довольно давно этим не занимался и страдаю склерозом. К тому же не я решил проблему автора этого вопроса, а он сам. Я лишь задавал наводящие вопросы.
Нужно тестировать, кто виноват. Запустить видео в разных браузерах(Chrome, Chromium, Opera у всех разные баги, хотя движок и один). Если дело не в браузере, то стоит координально проверить ОС. Запускай Linux LiveCD и смотри на нём. Так же такие проблемы могут быть из за недостаточной буферизации видео при периодических серьёзных потерях пакетов, если используете мобильный интернет или Ростелеком, то примите как данность, что жизнь — боль. Так же причиной может быть роутер, сетевая карта ноутбука или шум на частотах Wi-Fi.
Полагаю проблема в том, что ядро это не сектора с кодом это ELF-файл, который должен лежать в файловой системе. То есть нужно распарсить файловую систему, а затем распарсить ELF-файл, после чего при переходе в 32-битный режим отбразить ядро по нужному адресу в виртуальном пространстве и перейти в точку входа записанную в ELF-заголовке. Вот это вот не загрузчик ядра, смотрите исходники GRUB2.
Протоколы старой закалки абсолютно беззащитны. Без фильтрующих коммутаторов любой клиент может завернуть трафик сервера через отравление ARP-кеша. Не заботились об безопасности тогда просто потому, что нефиг социально-административные проблемы спихивать на компьютеры, ибо они эти проблемы решить не могут.
Есть такая вещь как руткиты, после того как злоумышленник получил доступ к серверу, все ПО на нём можно считать скомпрометированым. В том числе ядро, ПО для установки и сверки пакетов и все системные библиотеки. Только чистая установка или загрузка с бэкапа образа системы.
Тут ещё стоит учитывать, что важно заранее знать как проникли, иначе через минуту после восстановления, ситуация может окажется той же.
Наглая Морда, В случае JVM есть функции на C++ экспортируемые в пространство имён Java. И именно эта функция вызывает write. C# по моему мнению круче. Там все обёртки генерируются JIT на основе атрибутов.
Pan Propan, На самом деле даже если бы не было запущенного терминала есть несколько способов. Обычно у всех установлен grub и там может быть режим восстановления с root консолью. Так же можно запустить LiveCD и хозяйничать в системной файловой системе, если на BIOS нет пароля. В конце концов можно вытащить жёсткий диск и делать с ним, что хочешь. Реально сложно восстановить зашифрованные разделы или хотя бы зашифрованные директории пользователей, обычная парольная защита не более чем шутка.
Речь про Netbios-имя в стиле WIN-853CF... Хотя не факт, что его изменение поможет, ведь вполне возможно, что это шалит защита от использования десктопной винды в качестве сервера.
Как я и сказал ранее sudo --preserve-env=HOME wine cs16.exe это простейший способ. Запуск wine через capsh в принципе возможен, но во многих дистрибутивах непоправимо сломан.
И не только номера прерываний принято записывать в шестнадцатеричной системе счисления. Почти все числа в Ассемблере принято записывать в шестнадцатеричной системе, ибо мы работаем не с голой математикой, а с математикой ограниченной железом работающим с двоичной системой. А Си лишь стал жертвой этой традиции, ибо все помнят, что именно делает int 10h, а int 16, что за int 16?
NonameNoob, Скорее всего в BIOS лезть нужно, а он у всех разный. Честно говоря я плохо помню подробности, так, что лезьте в BIOS, настройки электропитания и гуглите, что меняют тамошние настройки.
NonameNoob, Либо экономия энергии, либо работа приложений. Третьего не дано. Невозможно выполнять хоть, что то в ждущем режиме. Разве, что можно частоты зарезать, чтобы процессор в нормальном, рабочем режиме ел поменьше (расширенные настройки электропитания, максимальная производительность ЦП 50%). Но его поменьше это не 0.
А ты сильно уверен, что это не ждущий/спящий режим, а просто отключение экрана? Wintel когда то стремился подражать мобилкам и уходить в особо быстрый ждущий режим.
Vano01rus, У Вас на интерфейсе L-FW/ens3 не указан шлюз(R-FW вероятно тоже), он же маршрут по умолчанию. Или хотя бы маршрут до сети 20.20.20.0/24. Вероятно условие требует чтобы сети находящиеся за L-FW и R-FW маршрутизировались только через OSPF. А без настройки базовой сети, ни GRE, ни OSPF настроить не получится.
Проверил echo -n testtesttest | nc localhost 9090 вывело testtesttest. Похоже проблема в клиенте. Ну и да, передавая значения в cout лучше использовать string
string s(4096, '\0');
int ret = recv(connfd , const_cast<string::pointer>(s.c_str()) , s.length(), 0);
std::cout<<"value buffer: "<<s.substr(0, ret)<<endl;
В таком виде запись не остановиться из за нулевого символа. Клиента тоже стоит переписать, чтобы исключить вероятность отправки не инициализированных данных.
Создание потоков и переключение между ними это относительно дорогая операция. Процессору нужно изменить таблицы виртуальной памяти и права доступа к страницам памяти. При этом абсолютно все кеши сбрасываются, что для современного процессора компилирующего код приложений в микрооперации с сохранением их в кеше, очень болезненно. Так же каждый поток выделяет виртуальную память под стэк и чем больше виртуальной памяти в пространстве приложения, тем больнее процессору. Иначе говоря вытесняющая многозадачность это зло, но при работе с длительными вычислениями это необходимое зло.
В идеале принудительных переключений контекста с заморозкой потока посреди кода должно быть как можно меньше. В серверных сборках Linux даже частоту таймера уменьшают для этих целей. Но процесс никак не может контролировать ядро ОС, остаётся только уменьшать количество активных потоков. По этому для не слишком долгих задач, стоит использовать кооперативную многозадачность с временем переключением контекста близким к нулю. Придумали её не вчера и в том или ином виде она была даже в Windows 3.11. Конструкцию async/await и кучу всего в комплекте придумали для упрощения кооперативной многозадачности. Писать тоже самое на Си это одна из адских пыток.
Повторюсь: без многозадачности в процессе это всё не нужно, просто некому отдать этот поток, кроме ядра ОС. И для задач, что долго, синхронно выполняются это тоже не нужно, ядро в любом случае будет поток прерывать для выдачи процессорного времени другим процессам.