Ivan Bogachev, Вроде, ё-апострофы должны запустить то, что внутри них, как команду; и подставить на своё место результат stdout этой команды.
Sorry, перепутал с sh/csh/bash.
При передаче кино - сервер быстро заливает буфер, предоставленный клиентом. И далее - при потере данных есть время переслать пропавшие пакеты.
При передаче игрового видео - это невозможно.
А управляющие команды - можно тупо дублировать, их же мало.
Для начала - надо, чтобы на этом разделе не было ни одного процесса. Т.е. если зайти туда файловым менеджером - то он заблокирует раздел от размрнтирования.
И затем - размонтировать. Не получится - написать сообщение системы об отказе.
"Gfn - GeForce now, стриминговый игровой сервис" - написано в начале вопроса. Вряд ли DontQuantum намеренно нас обманывает.
Я говорил про иную избыточность - не ту, которая в радиоканале, а ту, которая на всём пути от сервера к клиенту.
Поскольку стриминг заключается в передаче аналоговой картинки - метод кодирования можно подобрать так, чтобы он был устойчив к довольно существенным потерям. Например, известно, что человеческому глазу важнее яркость, чем цветность (это учтено в формате JPEG). Значит, мы можем гнать чёрно-белую картинку с большой избыточностью, а информацию о раскрашивании - без избыточности, и при потере части пакетов картинка потеряет цветность, но будет вполне различима. Также можно усиленно дублировать старшие биты и не дублировать младшие - поскольку при потере головы по волосам не плачут.
Правильно ли я понял, что есть Web-сайт, который выдаёт клиентам странички? И на всех страничках д.б. одно и то же число?
А насколько случайным/непредсказуемым д.б. число? Я могу придумать функцию, которая делает примерно то, что требуется - типа n+2*(n+sin(w*n)), где n = номер дня. Но она - предсказуемая, т.е. клиент после какого-то числа запросов может предсказать следующие результаты.
Если эта функция устраивает - я могу погонять тесты и подобрать более лучшую функцию, там же ещё надо округлять до целого. Как вариант - надо взять сумму нескольких синусов с разными частотами.
Функцию можно реализовать на стороне клиента или сервера, без разницы.
АртемЪ, По идее, стриминговый сервис должен закладываться не на TCP, а на изначальную избыточность. Т.е. если в TCP при пропаже пакета он запрашивается заново (точнее, в подтверждении о доставке указывается, какие были доставлены - и отправитель видит, чего не хватает), то стриминг должен изначально слать данные избыточно (что-то типа ECC) в предположении, что сколько-то пакетов могут пропасть.
Довольный Жизнью, Возможно, в BIOS'е надо подправить режим работы контроллера. Ну, типа того, что SATA умеет работать в собственном режиме, но при необходимости может работать в режиме совместимости с ATA-66/100/133; причём режим совместимости умеют не все контроллеры (я как-то на такое напоролся и выяснил, что W'XP умеет работать с SATA только при наличии SP3).
Надо смотреть, что за дистрибутив W'10. Возможно, он старый и не понимает нового контроллера, так что его надо обновить.
Ну или как вариант - ставить W'10 в вирт.машину.
Никита, Ставили ли Вы W'10 именно на этот компьютер, и именно этот дистрибутив?
0xD34F, Каждый из нас (и каждый из гуру) - когда-то был аналогичным позорищем (с поправкой на то, что он позорился в иных языках - которые были актуальны в то время). Более того: когда-то каждый из нас не умел говорить, а также не умел дойти до туалета и писал прямо в штаны/пелёнки.
Ну, трансляция тоже весьма затратна - поскольку обычно одна команда транслируется в несколько. А есть вещи, которые невозможно корректно транслировать - например, использование кода в роли данных; или самомодифицирующийся код.
И я не понял фразу "не только для процессора, но и для железа".
Edheldor, Ну, можно отслеживать момент, когда юзер закончил рисовать новый полигон. И в этот момент решать - делать ли кнопку сохранения доступной.
Если полигон в любой момент считается завершённым, т.е. юзер может переключаться с одного полигона на другой - то можно отслеживать перестановку очередного угла, как-то так.
Ну или проверять полигоны в момент нажатия кнопки сохранения.
Вроде, ё-апострофы должны запустить то, что внутри них, как команду; и подставить на своё место результат stdout этой команды.Sorry, перепутал с sh/csh/bash.
Rerurk, Это почти во всех языках так.