Последовательная запись/последовательное чтение зачастую работает в разы быстрее, чем беготня по файловой системе. И при загрузке диска >30-40% уже может быть быстее dd, чем rsync.
grub-install сам включит всё необходимое, чтобы свои модули нашел груб.
а обновление initramfs зависит от дистрибутива — в некоторых всё лежит сразу, в некоторых сборка автомаизирован.
В дебиане достаточно сделать
sudo dpkg-reconfigure linux-image-`uname -r`
Вы же знаете, что когда ищут причину бага — реально действующие программы упрощают до того минимума, который вызывает ошибку. Программы, в которых реально необходимо несколько больших кусков памяти на некоторое время — это нормально (например, надо прочитать массив, обработать, забыть его).
Проблемы в имитации её через выделение 64M блока не вижу.
2. The «fake» references are from the static variables defined in various go packages. These variables are not pointers. However, as GC scans the data section for potential references to the heap, they are treated as «pointers» and therefore the entire heap blocks which these «pointers» happen to «reference» can never be reclaimed even when they should be.
============
Хороший пример плохой реализации GC. Если переменная может выглядеть как указатель — это плохая реализация ГЦ, это значит он (в языке, где тип, в общем-то, известен!) не использует ту информацию, которую должен использовать.
Если VM или компилятор генерирует для целевой платформы нерабочий код, при корректном исходном алгоритме — это плохой и не заслуживающий доверия компилятор.
Сколько не видел драйверов «из коробки», всегда надо ставить отдельно нормальные от производителя, иначе тупит по-страшному.
Только для интегрированной nvidia можно оставлять базовые, от них всё равно ничего не ждёшь.
дрова проприетарные? на nvidia нормально только с проприетарными дровами, но с ними работало без каких либо проблем — и выравнивание какое хочешь выставляешь, и они не растягиваются а именно как два output, часы только на одном, в общем — красота да и только.
mnesia можно и нужно использовать — для нативных туплов и большой скорости работы (по сравнению с внешним решением) + гарантия атомарности в пределах кластера + много еще чего.
но это _только_ для данных нужных в рантайме вот прямо сейчас. как только данные утряслись — выкидывать в хранилища предназначенные для хранения и обработки.
а обновление initramfs зависит от дистрибутива — в некоторых всё лежит сразу, в некоторых сборка автомаизирован.
В дебиане достаточно сделать
sudo dpkg-reconfigure linux-image-`uname -r`
Проблемы в имитации её через выделение 64M блока не вижу.
Кстати, спокойно может съесть 1-1.5 гига на 32битной машине.
Почему Java не имеет таких проблем с GC?
code.google.com/p/go/issues/detail?id=909#c29
2. The «fake» references are from the static variables defined in various go packages. These variables are not pointers. However, as GC scans the data section for potential references to the heap, they are treated as «pointers» and therefore the entire heap blocks which these «pointers» happen to «reference» can never be reclaimed even when they should be.
============
Хороший пример плохой реализации GC. Если переменная может выглядеть как указатель — это плохая реализация ГЦ, это значит он (в языке, где тип, в общем-то, известен!) не использует ту информацию, которую должен использовать.
Только для интегрированной nvidia можно оставлять базовые, от них всё равно ничего не ждёшь.
но это _только_ для данных нужных в рантайме вот прямо сейчас. как только данные утряслись — выкидывать в хранилища предназначенные для хранения и обработки.