[ВХОД]

Главная | Содержание | Форум | Флуд | Файлы | Поиск | Контакт
NAVIG
О форуме
Резонансные генераторы
Магнитные генераторы
Механические центробежные (вихревые) генераторы
Торсионные генераторы
Электростатические генераторы
Водородные генераторы
Ветро- и гидро- и солнечные генераторы
Струйные технологии
Торнадо и смерчи
Экономия топлива
Транспорт
Гравитация и антигравитация
Оружие
Нейтронная физика
Научные идеи, теории, предположения...
Прочие идеи (разные)
Новые технологии
Коммерческие вопросы
Барахолка
Патентный отдел
Сделай сам. Советы.
Конструкторское бюро
мобильная версия
Печатать страницу
Поделиться...

Яндекс.Директ
Форум - Новые технологии - Сделай сам - Операционная система Linux. Вопросы без ответа. - Стр.34
<][ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 ][>
Модератор: dedivan
Post:#471944 Date:06.06.2015 (00:41) ...
21 августа 1991 года закончился августовский путч в СССР-
24 августа 1991 в центре Киева. Люди приветствуют провозглашение независимости
25 августа 1991 года Линус Товальдс опубликовал ядро Linux Date: 25 Aug 91 20:57:08 GMT
Просто совпадение? Можно быть, но есть еще много других совпадений.
Главное- это одинаковая методика зомбирования адептов Линукса и Нэзалежной.
Линуксоидов в мире точно столько же сколько и укропов- около 1 %.
О чем не спросишь линуксоида- ответ : хто нескаче тотмастдай
JohnZ | Post: 478724 - Date: 23.09.15(12:01)
proggi Пост: 478712 От 23.Sep.2015 (03:52)
Я както для дебиана собирал непосредственно deb пакеты а их потом ставил.
Но у вас похоже проблема не в том что не ставится а в том что не запускается при старте. А чем именно не устроили готовые пакеты из репозитория?

В репе идёт 5.5, даже 5.1 ~месяц как убрали, а с ними в моей проге малость гимор
с доступом и раздачей прав, там уже по-взрослому, кроме того имеет значение размер и быстродействие. 4.1 вполне устраивает по всем параметрам. На RPi2 в
3 потока (4 ядра) он собирается менее чем ~ 20 мин
Прога типа 1С (переписанный Ананас - www.ananas.su, если в курсе) и для RPi2 ей нужен "легковесный" и шустрый сервак.
Пока идёт допиливание и тестирование, не очень хочется "играться" с раздачей "слонов" в 5.5. После "make install", я так понимаю, и копирования скрипта старта сервака в /etc/init.d он должен был-бы стартовать. Пришлось в rc.local дописывать строчку для его "ручного" старта, что не есть гуд.
Кроме этого, также меняются права доступа к создаваемому сокету , т.к. директория /var/run/mysql/ создаётся с правми rw-r---- и соответственно никто не в праве к нему доступиться. Хотелось-бы как-то автоматизировать этот процесс ...

- Правка 23.09.15(12:05) - JohnZ
dedivan | Post: 478743 - Date: 23.09.15(20:14)
airman Пост: 478718 От 23.Sep.2015 (06:06)
(- зарыть что ни будь интересное в куче специализированных функций - не проблема...


Вот вы все таки невнимательно прочитали мою ссылку на форум иксбит.
А там самый интересный момент- непонятное и нелогичное использование внутренних регистров проца самим компилятором. Копирует туда переменные- и не использует. Возникает вопрос- зачем?
А я вот думаю, что как раз разработчики компиляторов оставляют черные ходы.
При выходе из любой функции- не обязательно хитрой, а самой обычной-
компилятор там оставляет след, по которому следующая функция может что то узнать.
это самый примитивный например доступ к данным ядра.
Я же не просто так спросил насчет того, как работает кэш.
Прогги вон скромно промолчал. Значит не знает ничего.
А там самое интересное. В кэше много чего остается после выполнения.
Даже готовые доступы в режим ядра. надо только знать, как вытащить их.
И на сях это не делается. А на ассемблере запросто.
Но не для всех. Обычно про эти команды не говорят и не пишут.
Я вот например сам выковыривал их из биоса.
Там такая хитрость- когда комп только включился- обычная динамическая память недоступна- надо еще контроллер памяти настроить и запустить.
В это момент проц пользует вместо озу как раз статическую память кэша.
И неважно, интеловский проц или арм- все это работает по одной методе.



_________________
я плохого не посоветую
dedivan | Post: 478744 - Date: 23.09.15(20:15)
JohnZ Пост: 478724 От 23.Sep.2015 (13:01)
Хотелось-бы как-то автоматизировать этот процесс ...


Тут это флуд. Разговор то ведь не об этом.

_________________
я плохого не посоветую
proggi | Post: 478749 - Date: 23.09.15(21:00)
dedivan Пост: 478744 От 23.Sep.2015 (21:15)
JohnZ Пост: 478724 От 23.Sep.2015 (13:01)
Хотелось-бы как-то автоматизировать этот процесс ...


Тут это флуд. Разговор то ведь не об этом.

Почему флуд, какраз нет. Все по теме.


А вот то как работает биос, и процессор это уже флуд, никак не связанный с линуксом.

_________________
Пожертвования на разработку 4276 8381 4130 4578
proggi | Post: 478750 - Date: 23.09.15(21:03)
Про кэш dedivan, ничего у меня не спрашивал, не надо выдумывать того чего не было.
И Если бы компиляторы делали бы код программы который работает медленно то пользовались бы иными компиляторами, а то что там чтото остается, так и пусть, зачем тратить время на чистку.

_________________
Пожертвования на разработку 4276 8381 4130 4578
dedivan | Post: 478752 - Date: 23.09.15(21:29)
Вот видишь какой ты невнимательный-
proggi Пост: 478687 От 23.Sep.2015 (00:11)
Чего там понимать, используй иной не GCC компилятор, они тогда должны также, единообразно врать))))))


dedivan Пост: 478699 От 23.Sep.2015 (01:48)
Ты вот если с программированием имеешь дело- расскажи как проц пользует кэш память. Какими командами инфа идет в кэш, какими выбирается из кэша, а какими из основной памяти.


А раз не знаешь как работает кэш- вот и кидаешь такие заявы-
proggi Пост: 478749 От 23.Sep.2015 (22:00)
А вот то как работает биос, и процессор это уже флуд, никак не связанный с линуксом.


Компилятор должен чистить кэш, а он мало того что не чистит, да еще и копирует для себя что то на память. Ничего страшного для лохов.
А для того кто знает, что он копирует и куда складывает- это готовый бэкдор.
Причем созданный самим компилятором. Не важно как ты защищаешь свою систему,
и насколько защищенный твой код- компилятор всегда оставляект черный ход,
о котором разработчики компилятора знают, они специально оставили его для себя,
и для тех кому нужно.

И это не мелкософт и не винда, это разработчики GCC.

_________________
я плохого не посоветую
- Правка 23.09.15(21:32) - dedivan
airman | Post: 478760 - Date: 23.09.15(22:41)
Дед Иван - я впечатлен масштабом информации!... За раскапывание всего этого - с моей стороны - уважение!!!
Зная что делает компилятор - можно добавить в ядро процесс (на ассемблере его написать наверное нужно), который будет "портить" эти "неиспользуемые переменные" и капут бобику... И, хотя "бобиков" наверняка несколько, потихоньку передавить и заблокировать их наверное можно... - только вот мало кому нужно...

- Правка 23.09.15(22:58) - airman
dedivan | Post: 478764 - Date: 23.09.15(22:55)
Так люди не зря пишут-
Открытое ПО для Linux на сегодня - миф Очень дорогостоящий причем.


И люди не простые, а те, кто по нужде залез в компилятор и обнаружил там, мягко говоря, некоторые несуразности.
Это тебе не прогги, который даже не знает как кэш запустить.


_________________
я плохого не посоветую
JohnZ | Post: 478766 - Date: 23.09.15(22:58)
Нееее dedivan , давай отделим мух от ...

dedivan Пост: 478699 От 23.Sep.2015 (01:48)
Ты вот если с программированием имеешь дело- расскажи как проц пользует кэш память. Какими командами инфа идет в кэш, какими выбирается из кэша, а какими из основной памяти.

Кэш работает на апаратном уровне, а ты спрашиваешь о командах !?
Это как ? В теории любая команда может его использовать ...
Но тебе видимо известно (а судя по посту нет) что КЭШ чистится любой командой перехода, т.к.
на этом его актуальность исчерпывается. Какой смысл это обсуждать ?

Кроме участка памяти СОЗУ (тот который КЭШ) есть ещё "фоновые" регистры
(вернее могут быть в схеме проца) которые тоже нигде не учтены, и о которых тоже
мало кому известно, только разработчикам аппаратной части по долгу службы
Их тогда тоже сюда "за уши" приплюсуй

dedivan dedivan Пост: 478752 От 23.Sep.2015 (22:29)
Компилятор должен чистить кэш, а он мало того что не чистит, да еще и копирует для себя что то на память.
Ничего страшного для лохов.
А для того кто знает, что он копирует и куда складывает- это готовый бэкдор.
Причем созданный самим компилятором. Не важно как ты защищаешь свою систему,
и насколько защищенный твой код- компилятор всегда оставляект черный ход,
о котором разработчики компилятора знают, они специально оставили его для себя,
и для тех кому нужно.
И это не мелкософт и не винда, это разработчики GCC.

dedivan , что-бы такое утверждать, нужно как минимум попытаться не только понять
принципы на которых он работает, но и хотя-бы глянуть в его исходник в том месте,
где генерится асм-кий код "под проц". Была у меня книжка, автора не помню, называлась
"Smoll C", в конце которой был полный исходник этого компилера и перечень вставок на асм-е
под 8080 проц, Если найдёшь, - рекомендую ознакомиться, там всё понятно, и то что ты называешь
чёрным ходом ещё с тех времён тянется ! Короче говоря, это долго объяснять, проще тебе
прочесть и понять самому, тем более, насколько я знаю, ты с 8080 знаком, и оч-чень давно.

dedivan | Post: 478767 - Date: 23.09.15(23:01)
Просто забывается все быстро, или кто то старается чтобы все забыли-
суют красивые ништяки в обертке блестящей- вот так мол быстрее и проще.
А что внутри- этож знать много надо, голова заболит.
А лет 20 всего назад ничего не болело.
dedivan Пост: 474689 От 11.Jul.2015 (14:30)
psih Пост: 474662 От 11.Jul.2015 (08:29)
У этих устройств есть собственная ОС на базе Linux. Получается компьютер в компьютере.


Помню такую эпопею- когда появились пентиумы- то появилась идея старенькие 486 машины использовать как многопроцессорные -
благо кэш у них встроенный, и вот туда пихали свое микроядро.
Почитай лет 20 уже прошло.
Почти как на этапе загрузки- когда микросхамы памяти еще не инициализированы- проц пользуеттся только своей кэш памятью.


_________________
я плохого не посоветую
dedivan | Post: 478768 - Date: 23.09.15(23:04)
JohnZ Пост: 478766 От 23.Sep.2015 (23:58)
Но тебе видимо известно (а судя по посту нет) что КЭШ чистится любой командой перехода, т.к.
на этом его актуальность исчерпывается. Какой смысл это обсуждать ?



Ответ неправильный.
Есть разные способы доступа к памяти- для простого юзера- через менеджер памяти, вот он и решает что актуально, а что нет.
А есть доступ через регистры контроллера памяти.
Там нет никакого менеджера. Там сам можешь решать- что актуально, а что нет.


_________________
я плохого не посоветую
dedivan | Post: 478770 - Date: 23.09.15(23:07)
JohnZ Пост: 478766 От 23.Sep.2015 (23:58)
что-бы такое утверждать, нужно как минимум попытаться не только понять
принципы на которых он работает, но и хотя-бы глянуть в его исходник в том месте,
где генерится асм-кий код "под проц".


Так я вам именно про это и дал ссылку- глянули люди именно в асмовский код и тихо прихуели.


_________________
я плохого не посоветую
proggi | Post: 478771 - Date: 23.09.15(23:14)
dedivan, ну хорошо, предположим, что компилятор действительно после себя оставил некий мусор.
Но как вы собираетесь его использовать, вы понимаете что это принципиально не реально.
На современных процессорах это принципиально не возможно, так как до того момента пока вы запустите некий "код" довас эти регистры милион раз затрут все другие нити программ, которые как понимаем написаны на совершенно разных компиляторах!!!
А нести чуш что все компиляторы одинаковые просто бредово!

_________________
Пожертвования на разработку 4276 8381 4130 4578
JohnZ | Post: 478774 - Date: 23.09.15(23:59)
dedivan Пост: 478768 От 24.Sep.2015 (00:04)
JohnZ Пост: 478766 От 23.Sep.2015 (23:58)
Но тебе видимо известно (а судя по посту нет) что КЭШ чистится любой командой перехода, т.к.
на этом его актуальность исчерпывается. Какой смысл это обсуждать ?

Ответ неправильный.
Есть разные способы доступа к памяти- для простого юзера- через менеджер памяти, вот он и решает что актуально, а что нет.
А есть доступ через регистры контроллера памяти.
Там нет никакого менеджера. Там сам можешь решать- что актуально, а что нет.

Ты про _уже_ загруженную операционку говоришь ? Поясни ! Что выполняется и в какой среде !!! ???
Команды кто выполняет, проц или контроллер памяти ?
Контроллер памяти команду на пере-загрузку КЭШ-а по команде перехода откуда получает ?

А доступ через регистры контроллера памяти НЕ является следствием доступа к памяти для простого юзера через менеджер памяти ??? В смысле как одна из функций ОС ? Поэтому повторю вопрос - Что выполняется и в какой среде !!! ???

И если компилер оставляет некий мусор после себя, так это не специально, поверь.
Если он ещё будет генерить "чистку" после каждой команды, ты сам захочешь работать с такой прогой ?
Вон выше Проги всё внятно пояснил ...

- Правка 24.09.15(00:13) - JohnZ
dedivan | Post: 478832 - Date: 24.09.15(16:16)
JohnZ Пост: 478774 От 24.Sep.2015 (00:59)
Команды кто выполняет, проц или контроллер памяти ?
...


Так это ты, прежде чем спорить, разберись кто выполняет.
Там почти десяток устройств, одновременно, в одних и тех же тактах работают и обслуживают кэш. Часть из них аппаратная, часть микропрограммная а часть просто програмная. Производители процев прячут этот механизм от простого юзера. Но для первичного запуска проца он нужен, поэтому для производителей биосов его открывают,
и нам остается только подсмотреть что там и как сделано.
Даже не все трансляторы знают эти команды.


_________________
я плохого не посоветую
<][ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 ][>
У Вас нет прав отвечать в этой теме.
Форум - Новые технологии - Сделай сам - Операционная система Linux. Вопросы без ответа. - Стр 34

Главная | Содержание | Форум | Флуд | Файлы | Поиск | Контакт
Valid XHTML 1.0 Transitional Valid XHTML 1.0 Transitional
Генерация страницы: 0.012 сек