Какого же хрена тогда «вендоадмины» не делают noexec на «хомяк», чтобы их сраные юзеры вирье не ловили? Тогда никакие антивирусы нафиг не нужны будут!
Половина вирусов на венде — блокировщики экрана, распространяющиеся по принципу «скачай обновление к flash player/кодеки/pron/крякер интернета», юзер всегда найдёт, как его запустить. Вторая пишет в местный /etc/hosts, что жадноклассники переехали. Оставшиеся 1% юзают дыры в ведре и/или стянутые цифровые подписи, ради них антивирус и нужен. В какой-то ОС по-другому?
Если в текстовом режиме вместо имени юзера/директории в ~ рисуются вопросы — ОС очевидное говно, поскольку допускает это в дефолтных установках. Поэтому в серьёзных ОС текстовый режим выпилили к чёрту, кроме совсем специальных случаев (native api-софт умеет юзать его, некоторые антитвари и двигатели разделов запускаются в текстовом режиме и пишут вообще все сообщения текстом, причём в ascii). Как минимум VGA работает на каждом десктопе, а на роутеры венда не претендовала.
Каждый раз, когда ты используешь long или long long вместо byte/short/char - кто-то докупает планку оперативки (с).
Ну типа как наиболее распространённый тип int - зависит от разрядности машины... и выделяет для хранения одного целого числа либо 32 бита. Соответственно, программы раздуваются.
Если использовать char/short/long - они будут одинаковыми на всех платформах. (соответственно 8/16/32 бита. 64 бита - это кажется long long. или long int. точно не помню
ЕМНИП, даже в этом нашем линуксе от скриптов noexec не защищает (потому что запускается не сам скрипт, а его интерпретатор, который лежит, конечно же, на нормальном разделе).
У них ещё и win32 API который со временем и правда оказался win32 - пришлось даже им тип long сделать размером 4 байта в x64 системах. По стандарту - sizeof(long)>=sizeof(void*)
А зачем, собственно, большинству программ 64бита? Ну, скажем, торрент клиенту или плееру? Чтобы они памяти жрали на 20-40 процентов больше?
Скажу по секрету - в 64-х битном режиме появляется несколько дополнительных регистров, компиляторы могут это обстоятельство очень неплохо использовать - меньше обращений к стеку, параметры функций в большинстве передаются через регистры.
Что касается большего пожирания памяти на 20-40%, то это миф.
Ну типа как наиболее распространённый тип int - зависит от разрядности машины... и выделяет для хранения одного целого числа либо 32 бита. Соответственно, программы раздуваются.
Ура! Наконец-то я понял, что не сошёл с ума.
#include <stdio.h>
int main(void)
{
printf("sizeof int =%d sizeof long %d\n", sizeof(int), sizeof(long));
return 0;
}
Пока не столкнулся с amd64, тоже был уверен, что int соответствует разрядности процессора, а long это 32 бита.
Когда пришло время перейти на 64-бита, удивлению не было предела.
Большинство плагинов существуют только в версии для 32bit и они, естественно, не совместимы с 64-битной версией Firefox (хотя это не совсем честно - в 64-битном Firefox может работать 32-битный nspluginwrapper)
32 bit Process have a 4GB memory limit, but it's spitted into 2GB for the user address space and the kernel address space.
There is a /3GB switch so that you can use 3GB for the user space and 1 GB for the kernel space. To do this you need to change a setting in the OS through boot.ini(Win 2000, XP, 2003) or the bcdedit utility(Win Vista an later). Also you need to make your exe aware of this switch linking it with the /LARGEADDRESSAWARE flag. You can do this with the editbin utility(it comes with the Windows SDK).
Other than that I'm afraid you have to make some changes to how your app runs so that it doesn't take as much memory.
Просто есть win32, вроде бы из названия ясно, что оно 32 битное, а вот нифига, win64 не существует, там используется тот же самый win32, но при этом в целом не совместимый по апи с win32, причем в этой помойке существует 64битные user32.dll и прочие страшные артефакты, но не существует user64.dll и так далее.
Плюс вместо lib и lib64 и общего bin там полный ад в виду того, что либы все лежат в path и совершенно не очевидно 32 битные они или 64 битные.
На лицо упоротый дизайн, который с размаху налетел на стену и пришлось допиливать эпичный костыль из за чего кстати 32 битные проги на 64битной системе дольше стартуют, чем могли бы.
Плюс выбор размеров для некоторых типов типа long тоже добавляет лулзов. Одним словом, эта херня скорее сдохнет, чем нормально будет 64 бита поддерживать.
На фрейбуфере как нехрен делать, но это скорее похоже на окошко консоли в фуллскрине. Впрочем в Линуксе тоже всё идёт именно к тому, есть проект kmscon и есть мнение, что скоро старую VT подсистему в пользу него выпилят.
История успеха, просто. В то время как хром, опера и ишак будут жрать память гигабайтами, лиса не будет. Потому, что не сможет. Почему они не написали это в аргументы, интересно.
Профита кроме поддержки более 4 гигов оперативы от 64 бит нету, в остальном одна лишняя пердолия с конфигами или что то не работает вообще.
1. Какая связь между 64 битами и SSD? 2. Если вы не видите профита, то это не значит, что его нет. 3. Какие еще проблемы с конфигами при переходе на 64 бита?