Нужно проверить факт задержки на разных дистрибутивах. GNome, KDE, XFCE на том-же железе.
Если будет залипать только гном - то это похоже на баг. Вообще из того что на экране можно
видеть буферизацию клавиатурных событий. Причем когда автор уже отключил CAPS lock
триггер еще как будто зажат. И поэтому вторая буква печатается тоже uppercase.
Мне кажется что я такое наблюдал в 2000е на своем слабом железе на SuseLinux или Fedora
я уже не помню точно. Но это точно дефект потому что не должно быть рассинхрона
между капсом и прочими клавиатурными событиями. А тут - рассинхрон.
Для начала - надо читать багтрекер Gnome. Возможно это дефект уже известен.
Операторы в конце месяца (скорее всего) считают суммарный трафик по категориям: voice, sms, internet
и выставляют друг другу счета. Учет конкретного абонента их не будет интересовать.
Светодиод точно не причем. Там их обычно два. Один показывает несущую. Второй - тухнет
когда приходит фрейм на вход. Wake on lan - вообще отдельная технология и светодиоды
- просто следствие того что она не включена.
Если ключи числовые (int32) и имеют ярко выраженную последовательность, то хеш-мапу
можно свести к массиву с дырками. Но это надо исследовать саму природу ключей.
Как они генерируются. Как идет ротация.
значение - вектор указателей
Еще наблюдение. Работа с хеш-мапой - это работа не только к ключами но и с value.
Надо в реальном времени посмотреть как часто читается value или насколько удачно
оно заполняет например L1/L2. При неудачных раскладах у нас будет рециркуляция
значений в кешах и алгоритм хеширования будет здесь вообще не причем. А будет
идти работа с медленной памятью. Тоесть векторов оптимизации у нас много
и алгоритм хеширования здесь просто - один из факторов.
TheAthlete, это очень консервативный стандарт. Кажется для LTO ширина ленты совпадает с VHS видеокассетой.
По поводу услуг восстановления данных. Вопрос звучит немного по другому. У тебя на ленте
есть обычно последовательность backups за какие-то года и месяцы. Лента обычно не переписывается
а дописывается в хвост. Тоесть у тебя на кассете полюбому несколько backups.
И такое чтоб все из них были испорчены - маловероятно.
@SunTechnik
По поводу фактов. Сейчас на дворе стоит 2024 год. И если у вас на производтсве были кассеты
2004 года - то берите и просто проверяйте их содержимое. Вот это и будет факт. Это будет
лучшая реклама чем какие-то там заявления от производителя.
Политика QNA это - ответы на вопросы. Автор спрашивает вопрос. Мы отвечаем ответ.
Очень верно задан вопрос - зачем 200 тыс. Я не знаю зачем. Если печатать это на принтере
то понадобиться 4000 листов бумаги А4.
Ясное дело что автор никогда это глазами не осилит посмотреть. И я надеюсь что он
это быстро поймет. Нужно будет добавить ограничитель чтоб while покзывал хотя-бы
первые 100 строк к сведенью.
В любом топике должен быть дискурс. В данном случае новичек услышал про регулярки.
Вот он услышал и дальше пойдет, как утёнок фабриковать регулярку на любой пустяк.
Получится эдакое regexp-ориентированное программирование. Поэтому
пускай посмотрит и подумает что есть 2 варианта. И есть встроенная функция isDigit
которая почти решает задачу и осталось только добавить точку с сравнению.
А что касается всего диапазона Unicode символов. Ну тут главное чтоб тесты зашли
в зеленый сегмент. Позитивный сценарий есть - оно и ладненько.
Не очень понятно зачем ты втащил сюда С-программирование.
int num_bytes = atoi(content_length);
здесь ты пропустил проверку на 0. atoi в случае неуспеха конвертации возвращает ноль. fread(data, 1, num_bytes, stdin);
здесь тоже нет проверки на ноль.
malloc(num_bytes + 1)
если ты в коде где-то использовал malloc то в конце надо память удалить. Критично
для джобов. Но и для таких коротких функций - правила хорошего тона. Чтоб под контролем было.
и эта штука не обязана никакие файлы писать. Она пишет в файл STDOUT. Чтоб перенаправить
ее принт в файл надо сделать что-то вроде ./http_handler >> file.txt
Maksim Herasim, с точки зрения надежности у тебя с большей вероятностью упадет MySQL
чем брокер. У БД - больше слабых мест и больше причин падать.
Ну впрочем как будет угодно. И тут вобщем
нет какого-то математического доказательства что один метод лучше а другой хуже.
Это только твой личный опыт покажет.
Если будет залипать только гном - то это похоже на баг. Вообще из того что на экране можно
видеть буферизацию клавиатурных событий. Причем когда автор уже отключил CAPS lock
триггер еще как будто зажат. И поэтому вторая буква печатается тоже uppercase.
Мне кажется что я такое наблюдал в 2000е на своем слабом железе на SuseLinux или Fedora
я уже не помню точно. Но это точно дефект потому что не должно быть рассинхрона
между капсом и прочими клавиатурными событиями. А тут - рассинхрон.
Для начала - надо читать багтрекер Gnome. Возможно это дефект уже известен.