На сегодняшний день компьютеры умеют воспроизводить игры, рисовать картины. Они даже могут знать твой кредитный рейтинг. При этом, на физическом уровне, они делают всего лишь две вещи – включают и выключают тысячи различных битов. Весь компьютер состоит из мелких деталей, которые называют битами или триггерами. В википедии написано, что "бит - единица информации", но в журнале, который я листаю сказано лишь про абстрактную детаель, основное свойство которой, находится в одно из двух состояний: "проводит ток", и "не проводит ток". Внутри любого устройства полдюжины электронных частей, которые называются по разному, реализуют разные функции, и даже состоят из разных материалов. Именно это и является объектом моего любопытства - интересно же знать, как именно идёт ток, и на какой транзистор попадает, чтобы я смог открыть двачик. Но пока, что обойдусь абстракцией в виде "бита". Намедни читал, что и электрический ток сам по себе абстракция - на квантовом уровне всё иначе.
Также, в компьютере присутствует и другое абстрактное устройство - "гейт". Оно имеет два ввода и вывод, к которым подключаются биты. Если оба входных бита проводят ток, то выходной бит его не проводит, в остальных противных случаях выходной бит будет проходить ток.
Уффф.. Не очень то информативный журнал. Но свою ценность, наверняка имеет. Стоит полистать.
Также, в компьютере присутствует и другое абстрактное устройство - "гейт". Оно имеет два ввода и вывод, к которым подключаются биты. Если оба входных бита проводят ток, то выходной бит его не проводит, в остальных противных случаях выходной бит будет проходить ток.
Уффф.. Не очень то информативный журнал. Но свою ценность, наверняка имеет. Стоит полистать.
И зачем тупорылая макака меня забанила? Что я такого писал?
Писать могу только под ВПН-ом.
Не понимаю, как работают RS-триггеры. Нужно ли им напряжение для того, чтобы хранить переменные? У меня есть такое подозрение, что нужно. Если бы триггер мог выдавать сигнал "1" без внешнего источника напряжение, это означало бы, что внутри самого триггера что-то генерирует ток. На схемах из википедии источников тока в триггерах нет. Я думаю моя мысль очевидна.
Так, я полагаю, что в отсутствии "питания" триггер должен в любом случае выдать сигнал "0".
Цитата из википедии:
При включении питания триггер непредсказуемо принимает (с равной или неравной вероятностью) одно из двух состояний. Это приводит к необходимости выполнять первоначальную установку триггера в требуемое исходное состояние, то есть подавать сигнал сброса на асинхронные входы триггеров, счётчиков, регистров,, а также учитывать, что ячейки ОЗУ, построенного на триггерах, содержат после включения произвольную информацию.
Глянул советский научпоп фильм. Интегральная схема - это несколько более гениальный объект, нежели я предполагал. Это не просто маленькая схема, это именно монолитный кристалл, с выцарапанными дорожками. Благодаря особой конструкции, такие кристалы могут работать как целые схемы - физически они и представляют собой схемы. Металлический слой - это проводник, комбинации полупроводников создают собой транзисторы, диоды, и прочие нелинейные элементы. Это удивительно. Одна пылинка - вся схема в помойку.
Процессор, это некоторая большая интегральная схема, содержащая в себе регистры - цепи триггеров. В процессор также встроена постоянная память. Уж не знаю из чего она состоит, но в каком-то смысле это даже не память, так как при подаче питания, ячейки постоянной памяти занимают конкретное, заранее известное положение, и более изменены быть не могут. Назначение этой памяти - просто на просто уже иметь готовые инструкции реализующие работу процессора. Процессору необходимо уметь записывать регистры, читать память, полезно уметь их складывать. Постоянная память и помогает таким механизмам реализоваться. Она содержит куски реальзующих команд. Содержит раскодировку целых чисел. Процессор работает по тактам - каждый промежуток времени, он что-то выполняет.
Кроме процессора, в компьютере есть общая шина - это огромный такой сгусток проводов. Само собой, эти провода микроскопические, и выцарапаны на схеме из диэлектрика. Все сигналы с процессора поступают на общую шину. К общей шине подключено всё подряд - ОЗУ, и контроллеры. ОЗУ представляет большую схему с системой триггеров, которые могут что-то в себе хранить, и могут отдавать синал. На общей шине, часть проводов отделена для адреса. По этим проводникам проходят сигналы обозначающие адрес. Все устройства по умолчанию получают данные с общей шины. Как раз адресация позволяет сделать так, чтобы все устройства игнорировали входящие сигналы, до тех пор пока к ним не придёт их адрес.
Контроллеры - это переходники между каким-нибудь устройством и общей шиной. Устройств много - под каждый инструкции в процессоре не напишешь. Поэтому как-то вот так сделали, чтобы процессор отдавал однотипные сигналы, а контроллер их посредством программы-драйвера уже преобразовывал в понятный для устройства вид.
Приятно посидел, почитал.
Писать могу только под ВПН-ом.
Не понимаю, как работают RS-триггеры. Нужно ли им напряжение для того, чтобы хранить переменные? У меня есть такое подозрение, что нужно. Если бы триггер мог выдавать сигнал "1" без внешнего источника напряжение, это означало бы, что внутри самого триггера что-то генерирует ток. На схемах из википедии источников тока в триггерах нет. Я думаю моя мысль очевидна.
Так, я полагаю, что в отсутствии "питания" триггер должен в любом случае выдать сигнал "0".
Цитата из википедии:
При включении питания триггер непредсказуемо принимает (с равной или неравной вероятностью) одно из двух состояний. Это приводит к необходимости выполнять первоначальную установку триггера в требуемое исходное состояние, то есть подавать сигнал сброса на асинхронные входы триггеров, счётчиков, регистров,, а также учитывать, что ячейки ОЗУ, построенного на триггерах, содержат после включения произвольную информацию.
Глянул советский научпоп фильм. Интегральная схема - это несколько более гениальный объект, нежели я предполагал. Это не просто маленькая схема, это именно монолитный кристалл, с выцарапанными дорожками. Благодаря особой конструкции, такие кристалы могут работать как целые схемы - физически они и представляют собой схемы. Металлический слой - это проводник, комбинации полупроводников создают собой транзисторы, диоды, и прочие нелинейные элементы. Это удивительно. Одна пылинка - вся схема в помойку.
Процессор, это некоторая большая интегральная схема, содержащая в себе регистры - цепи триггеров. В процессор также встроена постоянная память. Уж не знаю из чего она состоит, но в каком-то смысле это даже не память, так как при подаче питания, ячейки постоянной памяти занимают конкретное, заранее известное положение, и более изменены быть не могут. Назначение этой памяти - просто на просто уже иметь готовые инструкции реализующие работу процессора. Процессору необходимо уметь записывать регистры, читать память, полезно уметь их складывать. Постоянная память и помогает таким механизмам реализоваться. Она содержит куски реальзующих команд. Содержит раскодировку целых чисел. Процессор работает по тактам - каждый промежуток времени, он что-то выполняет.
Кроме процессора, в компьютере есть общая шина - это огромный такой сгусток проводов. Само собой, эти провода микроскопические, и выцарапаны на схеме из диэлектрика. Все сигналы с процессора поступают на общую шину. К общей шине подключено всё подряд - ОЗУ, и контроллеры. ОЗУ представляет большую схему с системой триггеров, которые могут что-то в себе хранить, и могут отдавать синал. На общей шине, часть проводов отделена для адреса. По этим проводникам проходят сигналы обозначающие адрес. Все устройства по умолчанию получают данные с общей шины. Как раз адресация позволяет сделать так, чтобы все устройства игнорировали входящие сигналы, до тех пор пока к ним не придёт их адрес.
Контроллеры - это переходники между каким-нибудь устройством и общей шиной. Устройств много - под каждый инструкции в процессоре не напишешь. Поэтому как-то вот так сделали, чтобы процессор отдавал однотипные сигналы, а контроллер их посредством программы-драйвера уже преобразовывал в понятный для устройства вид.
Приятно посидел, почитал.
>МОНОЛОГ - мой любимый способ общения в интернете. Никто тебе не ответит так хорошо, как ты сам.
В сексе то же самое.
А я нигилист - мне такие шутки остроумными не кажутся.
Время пришло. Пора установить себе FreeBSD. К сожалению, автор книги поручил мне задание сделать это самостоятельно.
Ранее у меня стоял Windows 7 / Windows 10 на одном жёстком диске. Иногда семёрка почему-то "уничтожала" Windows 10 после чего приходилось экстренно архивировать файлы и всё сносить.
Чъёрт его знает, что будет если FreeBSD поставить вместе с Windows 7 и Windows 10. Самое глупое, что для моего железа оптимальная семёрка. Десятку держу вообще только из-за накопившегося кэша в браузере - чтобы не потерять пароли, чтобы гугл не начал бить тревогу о подозрительном фингерпринте. А FreeBSD и вовсе мне нужен лишь для обучения. Получается какая-то путаница.
Автор советует купить какой-нибудь старый компьютер.
...Всё, что новее, вам вполне подойдёт. Если подходящего компьютера у вас в запасах не оказалось, вы можете попробовать приобрести такую машинку с рук на какой-нибудь барахолке в Интернете; как правило, денег за них хотят совсем немного, килограмм колбасы может стоить дороже.
Но, честно говоря, у меня скоро денег и на килограмм колбасы не хватит. Деньги нужны, работы нет, квалификации нет. Всё в упадке. Хотя кому я вру. Хоть когда-то было иначе? Надо просто рождаться в нормальном месте, в нормальное время, в нормальной семье. А так, если уже знаешь чем всё закончится - то можно не волноваться за будущее. Люди живут страхами, пытаются обмануть судьбу, но сколько бы они не боялись, не сожалели и не скорбили - в самом конце становится очевидно, что все их потуги - лишь оправдания, для того, что они и так сделают (или не сделают).
Я вот задумался, если языки верхнего уровня ссылаются на ассемблер посредством компилятора - не значит ли это, что по настоящему что-то изобретают лишь планировщики архитектуры процессора, которые и проектируют какие операции и программы может выполнять процессор, согласно постоянной памяти. Что делают программисты? Всего лишь составляют последовательность, из всевозможных комбинаций этих операций и встроеных в процессор программ. Таким образом возможности программиста-разработчика всегда будут ограничены возможностями архитектуры процессора? Звучит, как будто так оно и есть - программы десятилетней давности уже и запустить на современных машинах проблематично. Весь старый софт ушёл на свалку, вместе со старыми процессорами. Хотя может я и ошибаюсь - неофит в этом деле.
Ранее у меня стоял Windows 7 / Windows 10 на одном жёстком диске. Иногда семёрка почему-то "уничтожала" Windows 10 после чего приходилось экстренно архивировать файлы и всё сносить.
Чъёрт его знает, что будет если FreeBSD поставить вместе с Windows 7 и Windows 10. Самое глупое, что для моего железа оптимальная семёрка. Десятку держу вообще только из-за накопившегося кэша в браузере - чтобы не потерять пароли, чтобы гугл не начал бить тревогу о подозрительном фингерпринте. А FreeBSD и вовсе мне нужен лишь для обучения. Получается какая-то путаница.
Автор советует купить какой-нибудь старый компьютер.
...Всё, что новее, вам вполне подойдёт. Если подходящего компьютера у вас в запасах не оказалось, вы можете попробовать приобрести такую машинку с рук на какой-нибудь барахолке в Интернете; как правило, денег за них хотят совсем немного, килограмм колбасы может стоить дороже.
Но, честно говоря, у меня скоро денег и на килограмм колбасы не хватит. Деньги нужны, работы нет, квалификации нет. Всё в упадке. Хотя кому я вру. Хоть когда-то было иначе? Надо просто рождаться в нормальном месте, в нормальное время, в нормальной семье. А так, если уже знаешь чем всё закончится - то можно не волноваться за будущее. Люди живут страхами, пытаются обмануть судьбу, но сколько бы они не боялись, не сожалели и не скорбили - в самом конце становится очевидно, что все их потуги - лишь оправдания, для того, что они и так сделают (или не сделают).
Я вот задумался, если языки верхнего уровня ссылаются на ассемблер посредством компилятора - не значит ли это, что по настоящему что-то изобретают лишь планировщики архитектуры процессора, которые и проектируют какие операции и программы может выполнять процессор, согласно постоянной памяти. Что делают программисты? Всего лишь составляют последовательность, из всевозможных комбинаций этих операций и встроеных в процессор программ. Таким образом возможности программиста-разработчика всегда будут ограничены возможностями архитектуры процессора? Звучит, как будто так оно и есть - программы десятилетней давности уже и запустить на современных машинах проблематично. Весь старый софт ушёл на свалку, вместе со старыми процессорами. Хотя может я и ошибаюсь - неофит в этом деле.
Оно работает! Впервые использую что-то кроме Windows. Теперь с гордостью готов заявить, что я умнее Лопаря.
Зачем нужен курсор в командной строке? Чтобы просто туда-сюда им елозить?
В книге написано, что конечным продуктом обучения должна стать программа, обязательно полезная, и сделанная качественно. Что-то типо курсового проекта, но само собой никто его не заставляет делать, просто упомянается, что это было бы неплохо для обучения. Задумываясь над такой программой - я бы хотел сделать калькулятор с графическим интерфейсом. Стандартный калькулятор Windows везде одинаков, и всегда плох. За годы использования Windows я собрал целый пак программ, которые меня устраивают. Среди них есть SumatraPDF, MPV, notepad++, ungoogled chromium portable, 7-zip, Halite. Но нормального калькулятора я так и не нашёл. Идеально бы подошёл тот, что в яндекс поиске выдаётся - там есть автоматическая замена символов, там проще переключать косинусы и радианы. Но он не подойдёт. Во-первых, яндекс калькулятор открывается только в браузере, и требует интернета, во-вторых, можно было бы расширить его функционал, добавить комплексные числа, и вообще, сделать разные формы отображения дробей.
Зачем нужен курсор в командной строке? Чтобы просто туда-сюда им елозить?
В книге написано, что конечным продуктом обучения должна стать программа, обязательно полезная, и сделанная качественно. Что-то типо курсового проекта, но само собой никто его не заставляет делать, просто упомянается, что это было бы неплохо для обучения. Задумываясь над такой программой - я бы хотел сделать калькулятор с графическим интерфейсом. Стандартный калькулятор Windows везде одинаков, и всегда плох. За годы использования Windows я собрал целый пак программ, которые меня устраивают. Среди них есть SumatraPDF, MPV, notepad++, ungoogled chromium portable, 7-zip, Halite. Но нормального калькулятора я так и не нашёл. Идеально бы подошёл тот, что в яндекс поиске выдаётся - там есть автоматическая замена символов, там проще переключать косинусы и радианы. Но он не подойдёт. Во-первых, яндекс калькулятор открывается только в браузере, и требует интернета, во-вторых, можно было бы расширить его функционал, добавить комплексные числа, и вообще, сделать разные формы отображения дробей.
> Пора установить себе FreeBSD
Говно без задач, бздя давно умерла. Ставь Arch, половчее будет.
> я бы хотел сделать калькулятор с графическим интерфейсом
Изи, бери и изучай Python, потом какой-нибудь PyQt / PyGObject для графического интерфейса, и да, фигачь. Не так и сложно, плюс питон вполне себе востребован. Задача для старта выбрана верно. Но фряху я бы всё же заменил на arch, вот правда крайне рекомендую.
В учебнике стоит FreeBSD, поэтому у меня будет FreeBSD. Сам посуди - в чем смысл выебываться, ставить себе ubuntu или debian, если ты толком не знаешь что это такое. Ну.. может быть ты и знаешь, а я - нет. Фряха хотя бы полезна в обучении будет.
Мне не нравится Phyton. Выглядит как какая-то игрушка, а не язык программирования. Мне больше C нравится.
Я не одобяю твой подход. Мне не нравиться когда берут и делают какой-то мусор. Вначале нужно понять как это работает, и как делают по-уму, а потом уже и делать что-то.
Мне не хватает знаний по таким вещам как: поток, процесс, ввод-вывод, семафор, многозадачность и.т.д.
Я заметил, что поколение перфокарт в этом хорошо разбирается. На прошлой неделе преподаватель так увлекся на лекции разговорами не по теме, что начал рисовать графики, импульсные величины какие-то, тыкал на них указкой и говорил: "смотрите, вот это системы реального времени, а это псевдореального". Полезно знать полезно знать и разбираться во всех тех вещах, что я упомянал.
Также я ненароком встретился со старым знакомым. Он как раз программистом работает. Решил спросить у него - а что он может рассказать на счет потоков и многозадачности. Ну и глаза у него были в тот момент. Он смотрел на меня так, будто бы я сумашедший, и спрашиваю у него какой-то бессвязный бред.
Да, откуда ему это знать - он же не поколение перфокарт. Он своим примером показал, что хорошим программистом можно быть и без знаний всего того, что я перечислял вначале. А может я просто его нагрузил и он не хотел мне ничего говорить. А может я чего-то не того спрашиваю?
В любом случае, надо чуть подробнее понять работу устройств на материнской плате.
Я заметил, что поколение перфокарт в этом хорошо разбирается. На прошлой неделе преподаватель так увлекся на лекции разговорами не по теме, что начал рисовать графики, импульсные величины какие-то, тыкал на них указкой и говорил: "смотрите, вот это системы реального времени, а это псевдореального". Полезно знать полезно знать и разбираться во всех тех вещах, что я упомянал.
Также я ненароком встретился со старым знакомым. Он как раз программистом работает. Решил спросить у него - а что он может рассказать на счет потоков и многозадачности. Ну и глаза у него были в тот момент. Он смотрел на меня так, будто бы я сумашедший, и спрашиваю у него какой-то бессвязный бред.
Да, откуда ему это знать - он же не поколение перфокарт. Он своим примером показал, что хорошим программистом можно быть и без знаний всего того, что я перечислял вначале. А может я просто его нагрузил и он не хотел мне ничего говорить. А может я чего-то не того спрашиваю?
В любом случае, надо чуть подробнее понять работу устройств на материнской плате.
> В учебнике стоит FreeBSD, поэтому у меня будет FreeBSD
Твой учебник отстал от жизни и реальной разработки лет на 15-20, можно конечно изучать технологии древних (а для айти 20 лет - это пиздец какой большой срок, ХР уже сложно встретить или установить самому без плясок с бубнами, хотя 20 лет назад от неё нос воротили и предпочитали 98 использовать), но практического смысла в этом полный ноль.
> если ты толком не знаешь что это такое
А ты и не узнаешь, пока по мануалам не установишь и не настроишь себе оболочку хотя бы, с тем же питоном, чтоб первый "Hello, World" сработал.
> Выглядит как какая-то игрушка, а не язык программирования. Мне больше C нравится.
Только вот современные сложные и интересные задачи (компьютерное зрение, биг дата, машин лёнинг) - решаются на этой "игрушке", а не на С. И платят за них гораздо больше и охотнее, чем за знание С, под которого три с половиной вакансии и те требуют 25 лет опыта низкоуровневого байтоёбства.
> Я заметил, что поколение перфокарт в этом хорошо разбирается.
Потому они и работают преподавателями и обслугой устаревших технологий за 25к рублей на кафедре, лол, а не пилят ИИ для систем риск-менеджмента в банках, смекаешь?
> Он своим примером показал, что хорошим программистом можно быть и без знаний всего того, что я перечислял вначале.
Вот именно. Ты похож на чувака, который всё ещё ест сырое мясо, потому что "ну надо же попробовать, как люди до получения огня питались, а сразу готовить на огне - это хуйня".
> В любом случае, надо чуть подробнее понять работу устройств на материнской плате.
Программисту на это похуй, для этого есть девопсы и прочие технари. Ты можешь быть неебаться дата-сайентистом, который в условном Альфа-банке пилит ИИ, но не знать, как поменять оперативку или как работает семафор, потому что это и не нужно.
В общем, я постарался хоть как-то показать тебе, в чём ты заблуждаешься. Не стоит бояться изучать что-то действительно нужное, ты просто распыляешься на абсолютно ненужные тебе знания, отбрасывая вкат в айти всё дальше и дальше, забивая голову различной хуетой, которая в реальной жизни тебе пригодится чуть реже, чем никогда, а то, что реально может пригодиться - пригодиться тебе на уровне сеньора, не раньше.
Бро, просто поверь мне, я погромист с зарплатой 400к в месяц и стажем 10 лет, причём без оконченного высшего образования.
FreeBSD — это почти чистый Unix, а жму/пинус, который ты ему предлагал ставить — всего лишь Unix-like system.
И про С он прав, для "общения" непосредственно с железом это до сих пор самый важный ЯП. К тому же, выучив обычный С, потом можно относительно легко перейти и на сишарп, и на кресты. Выучив питухон ты не перекатишься никуда. Ну разве что руби синтаксически немного похож на него, а так...
Но начинать лучше всего со Scheme (и двигаться по SICPу), а если уж совсем хочется прочувствовать себя тру-прогером, то с ассемблера и фортрана, которые, кстати, потом и породили С.
Учебник относительно новый. Последние издание 2020 А.В. Столяров. На счет FreeBSD ты меня не понял. Я имею ввиду, что мне не зачем Arch. Я просто не понимаю что на нем делать. Если чисто для обучения - то почему бы не использовать то что в книге
>phyton
Согласен, machine learning полезная вещь, и я даже хотел бы этой технологией овладеть, потому как есть пара мыслей, как она может принести денег.
>Бро, просто поверь мне, я погромист с зарплатой 400к в месяц и стажем 10 лет, причём без оконченного высшего образования.
Уважаю. Но у меня основная цель стать лишь системным администратором. Я получаю высшее образование, но при этом моей квалификации хватает едва-ли чтобы стать грузчиком. Поэтому я решил в свободное время поизучать сети, ведь как я прочитал из треда сис. админов - нужна лишь вышка и немного скилов по сетям. К сожалению я столкнулся с непониманием даже базовых вещей - что такое протокол? Что такое уровень? Что там за сигналы в проводе? Мне посоветовали книги Столярова, "для начинающих". Так что у меня немного другой генезис, и другие планы. Может если бы устроился системным администратором, начал бы делать что-то более интересное. Вот ты сказал про защиту для банков, а меня всегда интересовало обратное - боты, взломы, уязвимости.
Но не суть. Ты меня просто не за того принял. Я не потенциальный гений, я просто ламповый вкатун хоть во что-то.
Можно и в phyton вкатится. Вопрос лишь в том, смогу ли я найти себе работу? (Вопрос риторический)
С ассемблера начинать не будем. Но автор книги имеет примерно схожее с тобой мнение. Начинать вообще будем с Pascal. Автор должен показать на нем общую суть программирования. А потом уже после тома про сети, есть отдельный учебник про C. Я планировал остановиться на втором томе. Мне и С не нужен - я же не разработчик.
Но когда в подростковом возрасте изучал языки, мне c++ показался более серьезным и полезным что-ли.
Опиши себя, ну там профессию, опыт, зарплату, а то пока я вижу либо теоретика, либо такого же упоротого, как ОП, который сам себе напридумывал истины, и свято верит в неё.
Для сетей начинал бы с учебника по сетям, а не с Unix'ов. Время маршрутизации через PC ушло давно, вместе с нулевыми, сейчас всё уже перешло на железки, там совсем другие подходы. Это уже тебе не mpd5 поднять на FreeBSD с кастомным ядром и его тюнингом в качестве PPTP-сервера, и не NAT через pf/ipfw делать. Тут надо изучать сети, всякие там Cisco Packet Tracer, и так далее. Со слитых курсов подготовки CCENT/CCNA начинать, в общем.
Ну тогда ладно, я-то думал, что ты всерьёз решил идти в программирование и CS, но даже сисадмину начальные знания С не помешают в любом случае, так что молодец, что собираешься его подучить.
>Опиши себя,
Средний рост, вес чуть меньше среднего, 26 лет, глаза серые, волосы темно-русые, девственник, молчаливый, социофоб, самодиагностированный аутист (аспи, не ), по MBTI я INTP-T, но вообще не очень верю в эту херню, имхо это гороскоп с элементами юнгианства.
>ну там профессию, опыт, зарплату,
Безработный, опыта нет, зарплаты тоже, получаю 2-3к в месяц от родителей на личные нужды + еду готовит мама.
>а то пока я вижу либо теоретика, либо такого же упоротого, как ОП, который сам себе напридумывал истины, и свято верит в неё.
Не знаю, к какой из этих категорий себя отнести, ставил и пользовался некоторое время OpenBSD, но потом меня всё же достало, что после каждого выхода из системы нужно переустанавливать дрова звуковухи и играться с настройками, поэтому теперь сижу на нормисном минте, с которым пока проблем нет, но ощущение, что это лишь недоюникс, в отличие от BSD-шных систем и MacOS, которые ближе к тому самому юниксу, меня не оставляет. Но в целом я склоняюсь к тому, что системы на микроядре лучше систем на монолитном ядре, поэтому в споре Таненбаума с Торвальдсом мне ближе позиция первого, и я с интересом смотрю в сторону проектов вроде Fuchsia OS, например, хотя и не уверен в коммерческом успехе этой затеи.
> А потом уже после тома про сети, есть отдельный учебник про C
Столяров даёт Си сразу после асемблера, который он даёт сразу после Паскаля.
Отдельный учебник у него по C++ (в котором он отчаянно боится всего нового), но про него он в третьем томе и так рассказывает.
> то почему бы не использовать то что в книге
В книге не говорится использовать именно FreeBSD, Линукс также можно использовать. Там главная мысль о том, чтобы не использовать Windows.
>Тут надо изучать сети, всякие там Cisco Packet Tracer
Я с этого и начал. Хотелось сразу "с места в карьер". Даже скачал CISCO. Но я начал ощущать, что я просто ебланю, почти как в вузе, просто повторяю задания, по той простой причине, но не имею первичных знаний о компьютероведении. Что за Ethernet? Что за витая пара? Для меня это просто провод и разьем под него. С такими навыками сложно прнять что к чему, и с чем мы имеем дело.
Изначально я и искал, что-то что в короткий срок мне даст первичные знания информатики. Так, чтобы не было как у лопаря:
-Что такое DNS
-Ну.. это магазин такой
Хотя понять что такое DNS у меня получилось еще в детситве, и без особых знаний сетей - определение из гугла интуитивно понятное.
>а то пока я вижу либо теоретика, либо такого же упоротого, как ОП, который сам себе напридумывал истины, и свято верит в неё.
То же впечатление при виде противопоставления Python и C, «современных сложных и интересных задач» и «низкоуровневого байтоёбства». Где как не в числодробилочных задачах возникает соблазн распараллелить работу, синхронизировав всё семафорами, или использовать низкоуровневые приколы, такие как индексы переменного размера, т. е. хранение целочисленных массивов, элементы которых умещаются в uint8, как массивов uint8, вмещающихся в uint16 — как массивы uint16, и т. д.. Придумали вот непригодный ни для чего другого формат плавающей запятой bfloat16, и нормально.
Ожидаемая реакция. Только я даже не вкурсе о чем ты. Мне не понравился интерпритатор Phyton в детстве, и понравился компилятор C++, только и всего.
Кстати, сколько ты в этом разделе сидишь? Точно больше двух... или даже трех лет. Запомнил твой никнейм - рируру. Написать просто, взял его для паролей.
>Только я даже не вкурсе о чем ты.
Я говорю, любое развитие эволюционно и IT не исключение, не нужно говорить нинужно, даже если речь идёт о какой-то действительно устаревшей технологии (@oldnewthing любит иногда вспоминать, как были сделаны вещи в 16-битном мире DOS/Windows 3.1/Windows 95, и это могут быть не только исторические анекдоты, но и полезные для культуры программирования рассказы со смыслом). В случае же Python это откровенная чушь, он сделан на C и использует библиотеки на C, в случае каких-либо странностей в их работе тебе придётся смотреть в C (тру стори со случая, когда я наткнулся на этот баг NumPy: https://github.com/numpy/numpy/issues/20048 :з).
>Кстати, сколько ты в этом разделе сидишь?
Я видел рождение и смерть галактик, я перевариваю боль Вселенной, я здесь живу веками во тьме, построенной из сгустков атомов, рождённых смертью света и сотканных в агонии случайных встреч.
У меня нет аутизма, но мне нравиться коллекционировать книги. Я их не читаю. Просто коллекционирую и размещаю по разделам, по полочкам. Вот приложил небольшой список этого говна добра.
https://www.mediafire.com/file/x3y8ijo6es3jtee/BOOKS.zip/file
I. Основы
1.1 - Математика. На мой взгляд, учебник Шведенко, это чистая база для любого технаря. Читать его следует полностью, попутно разбирая примеры.
1.2 - [ОТСУТСТВУЕТ] Было бы неплохо иметь учебник комбинаторики и/или дискретной математики, конкретно для цифровых технологий. Если есть добрые люди - дополните.
К своему стыду, ничего кроме Шведенко по математике я не читал, и плохо понимаю, что может пригодиться именно программисту.
1.3 - [ОТСУТСТВУЕТ] [НЕ ОБЯЗАТЕЛЬНО] Я думаю был бы полезен учебник по векторной алгебре. Всё-таки в трёхмерной графике, да и не только, часто используют матрицы,
векторы. Но особой пользы от знания всех формул векторной алгебры я не вижу. Чисто для ознакомления подойдёт. К тому же сейчас много программ нацелены на дизайн,
трёхмерную графику, видеоигры и всё в этом роде.
1.4 - Физика ч1.[1-41]. Имеет смысл прочитать первые 40 страниц, для того, чтобы освежить знания механники. Сами знания бесполезны, однако они дадут понимание
таких вещей как "поле", или "энергия", что в дальнейшем может пригодиться. Вникайте не в саму механнику, а в то, какие принципы она использует.
II. Продвинутые основы
2.1 - Физика ч3. В отличии от предыдущей, эту часть лучше освоить полностью, потому, что она исключительно про электромагнетизм и всё, что нам нужно.
2.2 - ТОЭ - Теория Электрических Цепей. На первый взгляд может показаться, что это абсолютно бесполезная книга. Но она может быть полезна тем, что объясняет
общие правила цепей. По-простому: эта книга вас научит быстро определить любой ток в любой цепи. Слышали от Петровича слова по типу "фаза","нуль","короткое замыкание"?
Так вот, эта книга поможет снять все вопросы относительно таких понятий.
2.3 - Егоров, А. И. Основы теории управления. К своему стыду, по теории управления я даже эту книгу не до конца освоил. Но она мне показалось довольно понятной и
наглядной для вкатунов. Если есть варианты её заменить чем-нибудь более годным - сделайте это доброе дело. Слышал мение, что следует читать именно про управление
в сфере цифровых технологий.
2.4 - [ОТСУТСТВУЕТ] Разыскивается учебник по основам электроники. К моему сожалению, в ВУЗе электронику нам преподавал дед с деменцией, который не то, что сказать
ничего не мог - на одной из пар он обосрался прямо себе в штаны(я не шучу). Учебников он не посоветовал, за весь курс обучения я посмотрел всего пару роликов про
n-p-n переходы. Так, что в этой сфере я не разбираюсь совсем. Однако, электроника очень полезна, когда речь идёт о компьютерах. Всё железо состоит из полупроводниковых
схем, и элктроника - это наука как раз обо всех этих схемах, и всем, что с ними связано.
III
3.1 - Просто положу в эту папку все книги Столярова. Я не знаю что из себя представляет этот раздел, но предполагаю, что на этом уровне должно произойти плавное
абстрагирование от всей физики. На этом этапе неплохо бы расказать про архитектуры компьютеров, про их историю. Перейти от электронным схем, к упрощённым понятиями типо
"бит", "регистр", потом переходить к "программированию" - что это за процесс, как он осуществляется. Потом по наростающей уже объяснять и процедурное программирование
и ООП.
https://www.mediafire.com/file/x3y8ijo6es3jtee/BOOKS.zip/file
I. Основы
1.1 - Математика. На мой взгляд, учебник Шведенко, это чистая база для любого технаря. Читать его следует полностью, попутно разбирая примеры.
1.2 - [ОТСУТСТВУЕТ] Было бы неплохо иметь учебник комбинаторики и/или дискретной математики, конкретно для цифровых технологий. Если есть добрые люди - дополните.
К своему стыду, ничего кроме Шведенко по математике я не читал, и плохо понимаю, что может пригодиться именно программисту.
1.3 - [ОТСУТСТВУЕТ] [НЕ ОБЯЗАТЕЛЬНО] Я думаю был бы полезен учебник по векторной алгебре. Всё-таки в трёхмерной графике, да и не только, часто используют матрицы,
векторы. Но особой пользы от знания всех формул векторной алгебры я не вижу. Чисто для ознакомления подойдёт. К тому же сейчас много программ нацелены на дизайн,
трёхмерную графику, видеоигры и всё в этом роде.
1.4 - Физика ч1.[1-41]. Имеет смысл прочитать первые 40 страниц, для того, чтобы освежить знания механники. Сами знания бесполезны, однако они дадут понимание
таких вещей как "поле", или "энергия", что в дальнейшем может пригодиться. Вникайте не в саму механнику, а в то, какие принципы она использует.
II. Продвинутые основы
2.1 - Физика ч3. В отличии от предыдущей, эту часть лучше освоить полностью, потому, что она исключительно про электромагнетизм и всё, что нам нужно.
2.2 - ТОЭ - Теория Электрических Цепей. На первый взгляд может показаться, что это абсолютно бесполезная книга. Но она может быть полезна тем, что объясняет
общие правила цепей. По-простому: эта книга вас научит быстро определить любой ток в любой цепи. Слышали от Петровича слова по типу "фаза","нуль","короткое замыкание"?
Так вот, эта книга поможет снять все вопросы относительно таких понятий.
2.3 - Егоров, А. И. Основы теории управления. К своему стыду, по теории управления я даже эту книгу не до конца освоил. Но она мне показалось довольно понятной и
наглядной для вкатунов. Если есть варианты её заменить чем-нибудь более годным - сделайте это доброе дело. Слышал мение, что следует читать именно про управление
в сфере цифровых технологий.
2.4 - [ОТСУТСТВУЕТ] Разыскивается учебник по основам электроники. К моему сожалению, в ВУЗе электронику нам преподавал дед с деменцией, который не то, что сказать
ничего не мог - на одной из пар он обосрался прямо себе в штаны(я не шучу). Учебников он не посоветовал, за весь курс обучения я посмотрел всего пару роликов про
n-p-n переходы. Так, что в этой сфере я не разбираюсь совсем. Однако, электроника очень полезна, когда речь идёт о компьютерах. Всё железо состоит из полупроводниковых
схем, и элктроника - это наука как раз обо всех этих схемах, и всем, что с ними связано.
III
3.1 - Просто положу в эту папку все книги Столярова. Я не знаю что из себя представляет этот раздел, но предполагаю, что на этом уровне должно произойти плавное
абстрагирование от всей физики. На этом этапе неплохо бы расказать про архитектуры компьютеров, про их историю. Перейти от электронным схем, к упрощённым понятиями типо
"бит", "регистр", потом переходить к "программированию" - что это за процесс, как он осуществляется. Потом по наростающей уже объяснять и процедурное программирование
и ООП.
Немного прикоснулся к phyton. Сразу понял, что мне всегда не нравилось в нем.
Во-первых, символ [TAB] в ряде случаев играет роль фигурных скобок из C#. Кто придумал эту нелепость? А вот записал я цикл.. большой такой цикл, а потом вспомнил, что хочу весь блок когда цикла подставить в еще один цикл. И что? Мне теперь табы для каждой строчки проставлять? Ну.. допустим есть обойти это табулирование. Зачем тогда вообще нужно это табулирование? Не проще скобками обойтись.
Во-вторых в phyton нет многомерных массивов. Да и вообще эти списки, кортежи выглядят как-то необычно.
В обучающих роликах постоянно натыкаюсь на комментарии по типу "Проклятый C#! Ничего не понятно! В phyton синтаксис куда логичнее". А как по мне, так наоборот.
>Учи протоколы! Что за пердолинг ты тут устроил
Сказал мне злой сисадмин в каком-то треде, когда я ставил себе оконный менеджер на фряху. Учи протоколы, сука! Не знаешь что такое ssh! Уххх бля.
Во-первых, символ [TAB] в ряде случаев играет роль фигурных скобок из C#. Кто придумал эту нелепость? А вот записал я цикл.. большой такой цикл, а потом вспомнил, что хочу весь блок когда цикла подставить в еще один цикл. И что? Мне теперь табы для каждой строчки проставлять? Ну.. допустим есть обойти это табулирование. Зачем тогда вообще нужно это табулирование? Не проще скобками обойтись.
Во-вторых в phyton нет многомерных массивов. Да и вообще эти списки, кортежи выглядят как-то необычно.
В обучающих роликах постоянно натыкаюсь на комментарии по типу "Проклятый C#! Ничего не понятно! В phyton синтаксис куда логичнее". А как по мне, так наоборот.
>Учи протоколы! Что за пердолинг ты тут устроил
Сказал мне злой сисадмин в каком-то треде, когда я ставил себе оконный менеджер на фряху. Учи протоколы, сука! Не знаешь что такое ssh! Уххх бля.
>Мне теперь табы для каждой строчки проставлять?
Абсолютно всё умеет табать выделенный текст кнопкой Tab и растабывать назад кнопкой Shift-Tab, или какими-нибудь менее очевидными.
>нет многомерных массивов
Есть в NumPy или можно сделать самому (пик 2): хранить многомерный массив D×H×W как одномерный в специальном классе с перегруженными методами __getitem__ / __setitem__, принимающими тьюпл (z, y, x), который сплющивается в одномерный индекс z×H×W + y×W + x = (z×H + y)×W + x, и по аналогии для любого количества измерений. Синтаксис myarr[1, 2, 3] развернётся в вызов myarr.__getitem__((1, 2, 3)). То есть да, было бы прикольно иметь их в стандартной библиотеке, но даже там они бы использовали эти уже имеющиеся средства.
Забавно. Я до этого не додумался - ставил табы как дурак.
У меня отобрали мою игрушку - некропк, Рируру. Пока что вкат приостановлю, почитаю ещё что-нибудь. К пайтону это не относиться, я вообще его с Jupiter запускаю, а код в блокноте храню. Но не попердолиться теперь. Ехх, а я уж планировал собрать идеальный пак софта для жизни на BSD. Откровенное враньё, что на BSD нет софта - для большинства нужд обычного юзера все есть.
Ты прав, пайтон - полезный язык, но байтоёбство - звучит прикольно. Хоть я и далек от всего этого.
Надо решать задачки. В попытке объяснить, что же такое "предел последовательности" своему младшему брату, я заметил, что теория - это готовый продукт. Почему мы знаем что 2×2=4? Мало кто задумывается, но мы эту информацию знаем лишь из практики - нам удобно считать груши, яблоки, апельсины, деньги. В некоторых культурах системы счисления могут быть совсем непонятными нам. Читал, что Инки, например, весь счет записывали в относительных единицах. Им вряд-ли понять, что такое "2+2".
Таким образом, теория - всего лишь готовое представление некоторого опыта. И чтобы понять теорию, нужно этот опыт иметь. В ВУЗе нас натаскивали решать дифференциальные уравнения, которые мы толком не знаем - и не зря, оказывается. Понять что такое "интеграл", можно лишь тогда, когда у тебя стоит задача найти площадь криволинейной фигуры, например. В противном случае - все эти символы лишь пустые закарючки.
И в общем-то когда я читал Шведа, я сам, незаметно для себя, создавал себе задачки. А зачем? Можно же готовые взять - более эффективно и актуально будет.
Поэтому от чтения, я перейду к практике.
На пайтоне это хорошо ощущается. Пишут: "ООП - ну это пук серьк типо... слоники, собачки - это класс.. эмм.." - в помойку это. Надо всего-лишь написать несколько программ с однотипными функциями. И тогда уж и возникает потребность: а вот как не создавать функции каждый раз, а сделать некоторую "обобщенную универсальную программу" которую можно использовать как множество однотипных функций. И тогда даже сомнений не возникает, что "класс" - подходящий термин. И правильно говорят, что класс - не программа. Но это не обьяснишь словами - должна возникнуть необходимость в написании некого "шаблона" для всех функций. На программах типа "Hello World" такой потребности возникнуть не может - все же они простые.
Что касается практики - нашел сайт circuit. В нем есть простой интуитивно понятный редактор электрических цепей. Поймет даже ребенок, а главное и качать ничего не нужно. Желтыми точками показан ток, напряжение - красно-зелеными областями. В ней можно эксперементировать над различными схемами, анализируя их работу.
Решил еще чутка побаловаться - установил Debian. К моему удивлению, тут есть даже некоторые программы от Microsoft. (Выпущены они, правда совсем недавно)
Сразу же были проблемы со звуком и с монтированием флешек. Может быть потому, что я пренебрег стандартными оконными менеджерами и установил i3wm - мне он больше понравился.
Не понимаю, почему так популярен Windows. Линукс бесплатный и имеет все необходимые функции для большинства людей. Зачем школам или небольшим компаниям покупать лицензию на windows, когда все то же самое можно предоставить бесплатно. Как будто бы школьникам нужна последняя версия фотошопа, или что там еще они используют, чего нельзя сделать на linux.
Сразу же были проблемы со звуком и с монтированием флешек. Может быть потому, что я пренебрег стандартными оконными менеджерами и установил i3wm - мне он больше понравился.
Не понимаю, почему так популярен Windows. Линукс бесплатный и имеет все необходимые функции для большинства людей. Зачем школам или небольшим компаниям покупать лицензию на windows, когда все то же самое можно предоставить бесплатно. Как будто бы школьникам нужна последняя версия фотошопа, или что там еще они используют, чего нельзя сделать на linux.
Почему течёт ток? Ну или "по чему течёт ток?". Я вот не догадываюсь.
Реле размыкает контакты - ток течь не должен. Однако он таки течёт.
Сейчас, правда, заметил, что резисторы в 5 кОм - это же всего нагрузка в 10 Вт? Может он просто проходит с соседней фазы, так как считает сопротивление ничтожным. В таком случае почему ток в десятки раз больше чем номинальный? Наоборот сопротивление увеличилось - ток должен стать меньше.
Чего-то я явно не понимаю.
Реле размыкает контакты - ток течь не должен. Однако он таки течёт.
Сейчас, правда, заметил, что резисторы в 5 кОм - это же всего нагрузка в 10 Вт? Может он просто проходит с соседней фазы, так как считает сопротивление ничтожным. В таком случае почему ток в десятки раз больше чем номинальный? Наоборот сопротивление увеличилось - ток должен стать меньше.
Чего-то я явно не понимаю.
С предыдущей схемой разобрался - я не включил в цепь сопротивления проводов, неправильно определил уставки, поставил слишком большое сопротивление на потребителе, и главное - я понял, что реле - не автоматический выключатель, и на переменном токе оно будет работать некорректно, да и ко всему прочему, даже на постоянном токе - реле поспешит открыться снова, как только на нём исчезнет ток, а он исчезает тогда, когда реле закрывается. Бесполезная конструкция выходит.
Смотрел видосики про заземление, зануление и землю. Не умеют эти люди объяснять материал. Объясняют так, что поймет только уже знающий.
С землей все понятно - просто точка с наименьшим потенциалом в электроннике. А с заземлением какая-то путанница. И на деле получается: "просто крепи этот желтый провод к клемме со значком земли и забудь... а если клеммы нету - вовсе так оставь". Это плохо. Заземление это не должно быть какой-то сложной темой, оно же используется повсеместно.
Для начала неплохо было бы сформулировать проблему - т.е. выяснить, а что не так-то с обычной трехфазной системой? Какие в ней могут быть аварийные случаи? Вот есть трехфазная сеть звезда-звезда, я беру и языком лижу фазу - между мной и нулевым проводом мега Омы! Ток по мне не потечет.
Допустим изоляция повредилась - опять лижу фазу, человек сам по себе 1 кОм сопротивления, ну и какой тогда по мне ток потечёт? Несколько милиампер? Так это не страшно. Ну ладно, это не так важно.
Что вообще такое "заземляющие устройство" - все поголовно зачитывают определение с википедии. Три колышка металлических в землю закораны - и что, и чего это? "Зря метал закопали" - для меня это выглядит именно так. Нужно пояснить, какую роль на схеме играет заземляющее устройство. Что это? Сопротивление, реактивная мощность, или быть может какая-нибудь хитрая конструкция для манипуляции физических явлений (каких явлений и за счет чего?). Вот это действительно дало бы понимание того, что такое "заземляющее устройство". Затем дело остается лишь за малым - просто обьяснить типовые схемы с заземлением и рассказать об их приемуществах.
Но я на сегодня так и не понял что такое заземление, поэтому продолжаю считать его дополнительным N проводником.(Хотя это совсем не правильно - оказывается есть схемы, где PE проводник никак не связан с N проводником)
Смотрел видосики про заземление, зануление и землю. Не умеют эти люди объяснять материал. Объясняют так, что поймет только уже знающий.
С землей все понятно - просто точка с наименьшим потенциалом в электроннике. А с заземлением какая-то путанница. И на деле получается: "просто крепи этот желтый провод к клемме со значком земли и забудь... а если клеммы нету - вовсе так оставь". Это плохо. Заземление это не должно быть какой-то сложной темой, оно же используется повсеместно.
Для начала неплохо было бы сформулировать проблему - т.е. выяснить, а что не так-то с обычной трехфазной системой? Какие в ней могут быть аварийные случаи? Вот есть трехфазная сеть звезда-звезда, я беру и языком лижу фазу - между мной и нулевым проводом мега Омы! Ток по мне не потечет.
Допустим изоляция повредилась - опять лижу фазу, человек сам по себе 1 кОм сопротивления, ну и какой тогда по мне ток потечёт? Несколько милиампер? Так это не страшно. Ну ладно, это не так важно.
Что вообще такое "заземляющие устройство" - все поголовно зачитывают определение с википедии. Три колышка металлических в землю закораны - и что, и чего это? "Зря метал закопали" - для меня это выглядит именно так. Нужно пояснить, какую роль на схеме играет заземляющее устройство. Что это? Сопротивление, реактивная мощность, или быть может какая-нибудь хитрая конструкция для манипуляции физических явлений (каких явлений и за счет чего?). Вот это действительно дало бы понимание того, что такое "заземляющее устройство". Затем дело остается лишь за малым - просто обьяснить типовые схемы с заземлением и рассказать об их приемуществах.
Но я на сегодня так и не понял что такое заземление, поэтому продолжаю считать его дополнительным N проводником.(Хотя это совсем не правильно - оказывается есть схемы, где PE проводник никак не связан с N проводником)
Продолжаю вкат в байтоёбство. Лишился работы. Сейчас я нахожусь в деревне, времени у меня предостаточно.
В результате последнего отпуска, оказалось, что в дни, пока отдыхаешь идёт неустойка по коэффициенту труда. То есть, хоть отпуск и оплачиваемый, если работать в него не будешь - зарплату за следующий месяц не жди. Ну и хитрая же схема. В суды естесственно много кто иски подавал - никто не выиграл.
Лишившись всякого дохода, за невозможностью снимать квартиру, я поехал через пол России в деревню к своему двоюродному брату. Он типичный кабанчик в возрасте, владелец небольшой ИП.
Жил в его доме в качестве прислуги. Приготовь, постирай, да пол помой - дела не сложные.
Все началось месяц назад. С утра, я как всегда встал, умылся, и пошел чистить снег вокруг дома. Стоял грубый мороз, градусов под 40. Очистив крыльцо и всю площадку, я продвинулся далее - чистить внешний двор. Под забором лежал какой-то то-ли мешок, то ли мусор. Подойдя поближе, я рассмотрел внимательнее этот объект. Это был бомж. Он спал спокойным сном. Как он тут оказался? Ну, я и думаю.. нужно его ломом по голове огреть, и выбросить в помойку, а то вдруг ещё каких бед принесёт. Я пошёл за ломом. Вернулся. Вот уж было начал замахиваться над этим пьяницой, как тут меня окликнул брат из окна: "что.. ты.. делаешь?!" - кричал он мне, нахмурившись, императивным тоном, точно так же как отчитывают учителя в школе. Спустя пять минут, брат вышел ко мне, ещё в пижаме, накинув только куртку.
"Вот-с, человек какой-то лежит" - как-бы оправдываясь, произнес я. Брат посмотрел на него, и присев на корточки, начал осматривать тело. Это оказалась молодая девушка довольно приятной внешности, но с явными признаками алкоголизма - глаза в синяках, а на губе была черная гематома, тушь с ресниц растеклась. Брат посмотрел на меня с осуждением, и сказал:"Ну ты чего? Совсем что ли бестолочь? Где твоё благородство? Заведи её в дом. 40 градусов мороза, женщина на улице, явно в беде, а ты на неё с ломом.."
Ну, за две руки мы затащили её в дом, и я пошел дальше прибирать снег.
Закончив работу, я вернулся в дом, и поднялся в свою комнату. Надо сказать, что это была скорее коморка, а не комната, так как к моему приезду не были готовы, хоть и были уведомлены, и посем поселили меня где место нашлось. На тот момент у меня не было интернета. Из развлечений были только книги и пара альбомов группы "Kiss", записаных на дискеты. Куда делась та девушка, я понятия не имел. Да и меня это не волновало, по своей скромности не любитель я задавать лишние вопросы.
Но через два дня всё прояснилось, когда кто-то неизвестный начал ходить по лестничной клетке по нескольку раз. Эта девушка жила с нами, но видимо кого-то из них стеснял факт визуального контакта со мной, поэтому обычно я видел издалека как она куда-то ходит по корридору как мышь. Может быть моя внешность действительно отталкивает. Выгляжу я, как патлатый столб-долговяз, с недельной щетиной, в дырявой оверсайз майке группы "metallica", которую даже и никогда особо не слушал. Поверх всего этого обычно накидываю халат, и надеваю тапочки чтобы в сорокоградусный мороз не отстудить чего-нибудь. На месте гостя, я бы полумал, что тут живёт какой-то священник или христианский монах.
Теперь о гостях. Переломным моментом стал новый год. К нам в дом заведалась приехать вся родня - мать и дед с бабкой. За одно они должны были и привести мне мой ноутбук с FreeBSD.
Их приезд состоялся накануне - встретили их с теплом. Старый жигули подъехал ко двору, и я поспешил открыть ворота, чтобы оставить его красоваться рядом с черным гелентвагеном, в гараж.
Чего только не было на моём ноутбуке, после того как он побывал в пользовании у маман - тысячи каких-то троянов, аваст, яндекс.браузер, амиго(Откуда? Насколько я знаю этого браузера уже давно нет). В общем форматнул жесткий диск, и поставил себе винду. Линукс ставить не стал, так как хотелось бы быстрее поучиться работать в программе IDA Pro, а не по два часа искать как бы её установить.
С той девушкой меня познакомили позднее всех - за ужином. Это была брюнетка приятной внешности, и с некоторыми азиатскими чертами лица. Я был как всегда немногословен, и выбросил всего пару слов за всё время трапезы. Из диалогов за столом, я узнал, что девушка вовсе не бомжиха, а просто какая-то несносная рокерша, которую совсем недавно отчислили со второго курса. У неё оказывается есть большая семья, родители - военные, дядя - медик, племянник - начальник завода. Меня даже удивило, и как так у людей может быть так много родственников.
После приезда родственников всё как-то ожило немного. Как будто дом из холодного мрачного замка на краю зимней пустоши превратился в ламповый дом из американского фильма. Хотя никакого гула не было, но присутствие жизни ощущалось. Дед часто ворчал на ручки дверей, которые он не мог повернуть, по какой-то неизвестной причине. Мать сидела и читала какую-то политоту. И что главное - по дому ничего стало не нужно делать: бабка постирает, мама погладит, дед снег приберёт. А та девушка, с которой теперь живет брат, стала, вдруг, готовить. Каждое утро, когда встречал её на кухне, она здоровалась со мной, не смотря на то, что у нас в семье сложилось так, что как-то обычно не здороваются.
Как-то у нас даже завязался диалог. Я упомянул имя Ницще, и она меня спросила:
-А ты разбираешься в философии Ницше?
-Да, конечно! - .Ответил я, хоть на самом деле я ни одной книги Ницше не прочитал, мне просто почему-то очень захотелось поговорить.
-Что ты думаешь о концепции "сверхчеловека"? - спросила она.
-Сверхчеловека? Я знаю про концепцию "античеловека". - зачем-то ляпнул я.
-Никогда не слышала о таком, это из какого его труда?
-Это из "так говорил Заратустра".
-Не, не помню чтобы там что-то такое было.
-Читайте оригинал, на немецком, там все сказано.
-И что же такое "античеловек"?
-Это полная противоположность человеку.
-Малый человек, что-ли?
-Нееет, совсем не человек! Малый человек в оригинале называется "ачеловеком", а тут "античеловек", не надо путать. Античеловек существует как абсолютный дух Гегеля, в противовес реальному существу.
На этой ноте мне начало казаться, что я несу полную ахинею, и пора бы свалить, пока никто не понял шутка ли это или рассказчик - шизанулся.
Праздновали новый год как обычно - ёлка, оливье, деду - водка, остальным - шампанское, мне - сок.
Пьяный дед всех доёбывал до их отношения к войне. Меня долго мучить не стал, как он говорит - "молчишь ты как сектант".
Мать начала докапываться до брата и до нашей недавноприбывшей гостьи, мол когда свадьба, почему она не со своей семьёй празднует. На что, она рассмеялась. Потом начали дарить подарки. Правда дарил подарки только брат и его девушка. Всем это было как-то вново.
Я, как не любитель праздновать новый год, не стал дожидаться полночи и поспешил удалиться в свой чулан, двачевать.
Утром, я проснулся, умылся, и увидел гору немытой посуды, да так, что не было даже свободной талелки, чтобы позавтракать. "Надо вымыть, что-ли" - подумал я и приступил к уборке. Затем встала мама, и пошла делать зарядку. Затем и брат, и девушка.
После завтрака, мать пошла прибирать просуду, а гостья заручилась ей помочь посмыть пол.
В таком темпе и жили эти дни. Пассия моего брата как будто бы пыталась понравиться маме.
Но все прекратилось в два дня. В один из вечеров, за ужином, мать закатила истерику. Как помню, все уже разошлись, я в этот момент стоял у окна и собилался идти, за столом сидели и общались только мать с братом.
-"Да сколько это можно" - вдруг мама громким тоном начала предьявлять брату - "Кто она такая? Она не познакомила меня ни со своими родителями ни с кем! Почему она тут постоянно живёт? У неё своего дома нет что-ли" - продолжала мать. "Успокойся, не волнуйся, я знаю её, она из приличной семьи. Да я уже и не сыночка-корзиночка, чтоб перед тобой отчитываться. Дом мой - мои порядки". - сазал брат. Мать подуспокоилась. На утро брат как всегда пошел на работу. Я решил поспать по дольше, но никак не мог уснуть - кто-то скребся в коридоре.
Когда я уж проснулся, на удивление никто не готовил завтрак и не прибирался. Мать посмотрела на меня и спросила:"Где Катя?" - так звали девушку. "Я не знаю" - ответил я.
"У нас украли деньги" - сказала мать. Открыв кабинет брата, все стало ясно. Ни денег, ни техники там не было - Катя съебалась в закат со всем. По адресам её родственников не находилось ни души. Возможно, Катя - это даже не её имя.
В результате последнего отпуска, оказалось, что в дни, пока отдыхаешь идёт неустойка по коэффициенту труда. То есть, хоть отпуск и оплачиваемый, если работать в него не будешь - зарплату за следующий месяц не жди. Ну и хитрая же схема. В суды естесственно много кто иски подавал - никто не выиграл.
Лишившись всякого дохода, за невозможностью снимать квартиру, я поехал через пол России в деревню к своему двоюродному брату. Он типичный кабанчик в возрасте, владелец небольшой ИП.
Жил в его доме в качестве прислуги. Приготовь, постирай, да пол помой - дела не сложные.
Все началось месяц назад. С утра, я как всегда встал, умылся, и пошел чистить снег вокруг дома. Стоял грубый мороз, градусов под 40. Очистив крыльцо и всю площадку, я продвинулся далее - чистить внешний двор. Под забором лежал какой-то то-ли мешок, то ли мусор. Подойдя поближе, я рассмотрел внимательнее этот объект. Это был бомж. Он спал спокойным сном. Как он тут оказался? Ну, я и думаю.. нужно его ломом по голове огреть, и выбросить в помойку, а то вдруг ещё каких бед принесёт. Я пошёл за ломом. Вернулся. Вот уж было начал замахиваться над этим пьяницой, как тут меня окликнул брат из окна: "что.. ты.. делаешь?!" - кричал он мне, нахмурившись, императивным тоном, точно так же как отчитывают учителя в школе. Спустя пять минут, брат вышел ко мне, ещё в пижаме, накинув только куртку.
"Вот-с, человек какой-то лежит" - как-бы оправдываясь, произнес я. Брат посмотрел на него, и присев на корточки, начал осматривать тело. Это оказалась молодая девушка довольно приятной внешности, но с явными признаками алкоголизма - глаза в синяках, а на губе была черная гематома, тушь с ресниц растеклась. Брат посмотрел на меня с осуждением, и сказал:"Ну ты чего? Совсем что ли бестолочь? Где твоё благородство? Заведи её в дом. 40 градусов мороза, женщина на улице, явно в беде, а ты на неё с ломом.."
Ну, за две руки мы затащили её в дом, и я пошел дальше прибирать снег.
Закончив работу, я вернулся в дом, и поднялся в свою комнату. Надо сказать, что это была скорее коморка, а не комната, так как к моему приезду не были готовы, хоть и были уведомлены, и посем поселили меня где место нашлось. На тот момент у меня не было интернета. Из развлечений были только книги и пара альбомов группы "Kiss", записаных на дискеты. Куда делась та девушка, я понятия не имел. Да и меня это не волновало, по своей скромности не любитель я задавать лишние вопросы.
Но через два дня всё прояснилось, когда кто-то неизвестный начал ходить по лестничной клетке по нескольку раз. Эта девушка жила с нами, но видимо кого-то из них стеснял факт визуального контакта со мной, поэтому обычно я видел издалека как она куда-то ходит по корридору как мышь. Может быть моя внешность действительно отталкивает. Выгляжу я, как патлатый столб-долговяз, с недельной щетиной, в дырявой оверсайз майке группы "metallica", которую даже и никогда особо не слушал. Поверх всего этого обычно накидываю халат, и надеваю тапочки чтобы в сорокоградусный мороз не отстудить чего-нибудь. На месте гостя, я бы полумал, что тут живёт какой-то священник или христианский монах.
Теперь о гостях. Переломным моментом стал новый год. К нам в дом заведалась приехать вся родня - мать и дед с бабкой. За одно они должны были и привести мне мой ноутбук с FreeBSD.
Их приезд состоялся накануне - встретили их с теплом. Старый жигули подъехал ко двору, и я поспешил открыть ворота, чтобы оставить его красоваться рядом с черным гелентвагеном, в гараж.
Чего только не было на моём ноутбуке, после того как он побывал в пользовании у маман - тысячи каких-то троянов, аваст, яндекс.браузер, амиго(Откуда? Насколько я знаю этого браузера уже давно нет). В общем форматнул жесткий диск, и поставил себе винду. Линукс ставить не стал, так как хотелось бы быстрее поучиться работать в программе IDA Pro, а не по два часа искать как бы её установить.
С той девушкой меня познакомили позднее всех - за ужином. Это была брюнетка приятной внешности, и с некоторыми азиатскими чертами лица. Я был как всегда немногословен, и выбросил всего пару слов за всё время трапезы. Из диалогов за столом, я узнал, что девушка вовсе не бомжиха, а просто какая-то несносная рокерша, которую совсем недавно отчислили со второго курса. У неё оказывается есть большая семья, родители - военные, дядя - медик, племянник - начальник завода. Меня даже удивило, и как так у людей может быть так много родственников.
После приезда родственников всё как-то ожило немного. Как будто дом из холодного мрачного замка на краю зимней пустоши превратился в ламповый дом из американского фильма. Хотя никакого гула не было, но присутствие жизни ощущалось. Дед часто ворчал на ручки дверей, которые он не мог повернуть, по какой-то неизвестной причине. Мать сидела и читала какую-то политоту. И что главное - по дому ничего стало не нужно делать: бабка постирает, мама погладит, дед снег приберёт. А та девушка, с которой теперь живет брат, стала, вдруг, готовить. Каждое утро, когда встречал её на кухне, она здоровалась со мной, не смотря на то, что у нас в семье сложилось так, что как-то обычно не здороваются.
Как-то у нас даже завязался диалог. Я упомянул имя Ницще, и она меня спросила:
-А ты разбираешься в философии Ницше?
-Да, конечно! - .Ответил я, хоть на самом деле я ни одной книги Ницше не прочитал, мне просто почему-то очень захотелось поговорить.
-Что ты думаешь о концепции "сверхчеловека"? - спросила она.
-Сверхчеловека? Я знаю про концепцию "античеловека". - зачем-то ляпнул я.
-Никогда не слышала о таком, это из какого его труда?
-Это из "так говорил Заратустра".
-Не, не помню чтобы там что-то такое было.
-Читайте оригинал, на немецком, там все сказано.
-И что же такое "античеловек"?
-Это полная противоположность человеку.
-Малый человек, что-ли?
-Нееет, совсем не человек! Малый человек в оригинале называется "ачеловеком", а тут "античеловек", не надо путать. Античеловек существует как абсолютный дух Гегеля, в противовес реальному существу.
На этой ноте мне начало казаться, что я несу полную ахинею, и пора бы свалить, пока никто не понял шутка ли это или рассказчик - шизанулся.
Праздновали новый год как обычно - ёлка, оливье, деду - водка, остальным - шампанское, мне - сок.
Пьяный дед всех доёбывал до их отношения к войне. Меня долго мучить не стал, как он говорит - "молчишь ты как сектант".
Мать начала докапываться до брата и до нашей недавноприбывшей гостьи, мол когда свадьба, почему она не со своей семьёй празднует. На что, она рассмеялась. Потом начали дарить подарки. Правда дарил подарки только брат и его девушка. Всем это было как-то вново.
Я, как не любитель праздновать новый год, не стал дожидаться полночи и поспешил удалиться в свой чулан, двачевать.
Утром, я проснулся, умылся, и увидел гору немытой посуды, да так, что не было даже свободной талелки, чтобы позавтракать. "Надо вымыть, что-ли" - подумал я и приступил к уборке. Затем встала мама, и пошла делать зарядку. Затем и брат, и девушка.
После завтрака, мать пошла прибирать просуду, а гостья заручилась ей помочь посмыть пол.
В таком темпе и жили эти дни. Пассия моего брата как будто бы пыталась понравиться маме.
Но все прекратилось в два дня. В один из вечеров, за ужином, мать закатила истерику. Как помню, все уже разошлись, я в этот момент стоял у окна и собилался идти, за столом сидели и общались только мать с братом.
-"Да сколько это можно" - вдруг мама громким тоном начала предьявлять брату - "Кто она такая? Она не познакомила меня ни со своими родителями ни с кем! Почему она тут постоянно живёт? У неё своего дома нет что-ли" - продолжала мать. "Успокойся, не волнуйся, я знаю её, она из приличной семьи. Да я уже и не сыночка-корзиночка, чтоб перед тобой отчитываться. Дом мой - мои порядки". - сазал брат. Мать подуспокоилась. На утро брат как всегда пошел на работу. Я решил поспать по дольше, но никак не мог уснуть - кто-то скребся в коридоре.
Когда я уж проснулся, на удивление никто не готовил завтрак и не прибирался. Мать посмотрела на меня и спросила:"Где Катя?" - так звали девушку. "Я не знаю" - ответил я.
"У нас украли деньги" - сказала мать. Открыв кабинет брата, все стало ясно. Ни денег, ни техники там не было - Катя съебалась в закат со всем. По адресам её родственников не находилось ни души. Возможно, Катя - это даже не её имя.
Наконец-то снова появилось свободное время. Решил все-таки вернуться к книгам Столярова.
Для вката в реверс-инжиниринг нужно знание ассемблера. Операционная система FreeBSD как раз даёт возможность скачать компилятор NASM прямо из репозитория.
Да и вообще, работа с ней весьма полезна. Пока копаешься в настройках самой ОС, пытаешься настроить звук, менеджер окон, чуть лучше понимаешь как система устроена. Это даёт практику, и позволяет намного проще понять, что там в учебнике написано.
Поизучал немного что же такое эти ваши "транзисторы". Про p-n переходы пишут много, но мне, как не сведующему в физике человеку, это непонятно. Раньше я любил физику, но в один переломный момент, как начали изучать электромагнетизм, резко разлюбил. Причина - философская. Ранее, все, что пишут в учебниках физики я принимал за истину: есть протон, есть электрон, электрон движется вокруг протона, чего тут непонятного? Но потом мы стали переходить к более сложным вещам, и по итогу, у нас дырки стали переносчиками заряда. Бред? Ну и что? Главное, что всё сходится. И физика - это всегда про подгон результата под желаемое. Физикам на самом деле безразлично то, что существует - физикам главное, чтобы произошла магия, которую они предсказали. А все эти объяснения - чисто для красоты.
Однако, разочаровавшись в физике, я стал хорошо относиться к математике. Математикам и не нужно выдумывать легенд - их наука абстрактна. Математика - это чистая мысль. Они не хотят удивить своими магическими фокусами людей, они сами создают магию.
Тем не менее, вернусь к транзисторам. Подобно макаке, увидив транзистор, я решил подключить его рандомными выводами к источнику наряжения и посмотреть что будет.
Если на участке база-эммитер напряжение меньше чем на коллектор-эммитер, но по эммитеру будет течь ток, при напряжении цепи равном напряжению базы, но сам ток базы будет мал. То есть ток течёт со стороны коллектора к эммитеру, но наряжение, фигурирующее в законе ома берётся с базы. Какой смысл это имеет, я пока не понял.
Если же наоборот (напряжение база-эммитер будет больше напряжения коллектор-эммитер), то произойдет что-то бессмысленное, на мой взгляд: ток базы будет большим, при этом ток через базу будет течь как на эммитер, так и на коллектор. Я думаю так подключать транзистор не стоит, ведь ток базы - это обычно небольшой управляющий ток, а тут он доходит до больших значений. Да и в чем смысл тогда напряжения в цепи коллектор-эммитер? Только чтобы ток уменьшать?
Менял местами эммитер и коллектор - результата никакого, из чего я сделал ложный вывод, что не имеет разницы в какую сторону подключать. Однако, загуглив, оказалось, что на практике всё-таки разница существенна - тразисторы сделаны особым образом, чтобы ток с коллектора на эммитер проходил лучше.
Существует несколько видов транзисторов, и несколько режимов работы. Так, что я решил, что пока хватит копаться в электронике, и стоит почитать что-нибудь поближе к теме. Поэтому я прочитал про RS-триггеры и даже собрал простейший из них в программе.
Также, нашёл схемы того, как устроена оперативная память на RS-триггерах. Мне этого достаточно. Я бы не хотел подробно изучать все виды памяти, мне бы просто отдалённо понять, куда примерно попадают сигналы с процессора.
Для вката в реверс-инжиниринг нужно знание ассемблера. Операционная система FreeBSD как раз даёт возможность скачать компилятор NASM прямо из репозитория.
Да и вообще, работа с ней весьма полезна. Пока копаешься в настройках самой ОС, пытаешься настроить звук, менеджер окон, чуть лучше понимаешь как система устроена. Это даёт практику, и позволяет намного проще понять, что там в учебнике написано.
Поизучал немного что же такое эти ваши "транзисторы". Про p-n переходы пишут много, но мне, как не сведующему в физике человеку, это непонятно. Раньше я любил физику, но в один переломный момент, как начали изучать электромагнетизм, резко разлюбил. Причина - философская. Ранее, все, что пишут в учебниках физики я принимал за истину: есть протон, есть электрон, электрон движется вокруг протона, чего тут непонятного? Но потом мы стали переходить к более сложным вещам, и по итогу, у нас дырки стали переносчиками заряда. Бред? Ну и что? Главное, что всё сходится. И физика - это всегда про подгон результата под желаемое. Физикам на самом деле безразлично то, что существует - физикам главное, чтобы произошла магия, которую они предсказали. А все эти объяснения - чисто для красоты.
Однако, разочаровавшись в физике, я стал хорошо относиться к математике. Математикам и не нужно выдумывать легенд - их наука абстрактна. Математика - это чистая мысль. Они не хотят удивить своими магическими фокусами людей, они сами создают магию.
Тем не менее, вернусь к транзисторам. Подобно макаке, увидив транзистор, я решил подключить его рандомными выводами к источнику наряжения и посмотреть что будет.
Если на участке база-эммитер напряжение меньше чем на коллектор-эммитер, но по эммитеру будет течь ток, при напряжении цепи равном напряжению базы, но сам ток базы будет мал. То есть ток течёт со стороны коллектора к эммитеру, но наряжение, фигурирующее в законе ома берётся с базы. Какой смысл это имеет, я пока не понял.
Если же наоборот (напряжение база-эммитер будет больше напряжения коллектор-эммитер), то произойдет что-то бессмысленное, на мой взгляд: ток базы будет большим, при этом ток через базу будет течь как на эммитер, так и на коллектор. Я думаю так подключать транзистор не стоит, ведь ток базы - это обычно небольшой управляющий ток, а тут он доходит до больших значений. Да и в чем смысл тогда напряжения в цепи коллектор-эммитер? Только чтобы ток уменьшать?
Менял местами эммитер и коллектор - результата никакого, из чего я сделал ложный вывод, что не имеет разницы в какую сторону подключать. Однако, загуглив, оказалось, что на практике всё-таки разница существенна - тразисторы сделаны особым образом, чтобы ток с коллектора на эммитер проходил лучше.
Существует несколько видов транзисторов, и несколько режимов работы. Так, что я решил, что пока хватит копаться в электронике, и стоит почитать что-нибудь поближе к теме. Поэтому я прочитал про RS-триггеры и даже собрал простейший из них в программе.
Также, нашёл схемы того, как устроена оперативная память на RS-триггерах. Мне этого достаточно. Я бы не хотел подробно изучать все виды памяти, мне бы просто отдалённо понять, куда примерно попадают сигналы с процессора.
На странице номер 240 начинается вкат в программирование, написанием программы hello world.
Как же меня это заебало. Я писал этот hello world десять тысяч раз, и на С++, и на паскале, и на бейсике, и на пайтоне. На ассемблере только не писал (хотя это было бы как раз намного интереснее). Учили бы сразу каким-нибудь крутым приёмам, но нет, начинается этот обзор каждого оператора: "Оо! Посмотрите - это же realdn". Зачем мне этот readln? Кто-то пользуется командной строкой до сих пор что-ли? (Может и пользуется. Суть в том, что я так и не извлек никакой пользы от операции "readln")
Опенсорс - это когда все работает крайне нестабильно. Например, я зашел на один сайт для просмотра видео, после чего x window намертво завис. Да даже посмотрите на книгу Столярова - смех и грех, его любимый LaTEX некорректно раскодировал текст, и при копировании в буфер обмена выдаёт какую-то белеберду. Однако есть и плюсы. Мне понравилось, что во FreeBSD графическая среда работает как программа, и является совсем не обязательной. Мне понравилось, что в UNIX нет такого понятия как расширения файлов. Для обучения самое то.
Как же меня это заебало. Я писал этот hello world десять тысяч раз, и на С++, и на паскале, и на бейсике, и на пайтоне. На ассемблере только не писал (хотя это было бы как раз намного интереснее). Учили бы сразу каким-нибудь крутым приёмам, но нет, начинается этот обзор каждого оператора: "Оо! Посмотрите - это же realdn". Зачем мне этот readln? Кто-то пользуется командной строкой до сих пор что-ли? (Может и пользуется. Суть в том, что я так и не извлек никакой пользы от операции "readln")
Опенсорс - это когда все работает крайне нестабильно. Например, я зашел на один сайт для просмотра видео, после чего x window намертво завис. Да даже посмотрите на книгу Столярова - смех и грех, его любимый LaTEX некорректно раскодировал текст, и при копировании в буфер обмена выдаёт какую-то белеберду. Однако есть и плюсы. Мне понравилось, что во FreeBSD графическая среда работает как программа, и является совсем не обязательной. Мне понравилось, что в UNIX нет такого понятия как расширения файлов. Для обучения самое то.
> Да даже посмотрите на книгу Столярова - смех и грех, его любимый LaTEX некорректно раскодировал текст, и при копировании в буфер обмена выдаёт какую-то белеберду
Он сам (причём, в каком-то из изданий текстовый слой нормальный, емнип)
А это даже смешно. Спасибо за интересный факт.
Получай, проклятый "hello world"!
Сделал программу, которая отрисовывает шахматную доску принимая в качестве параметра значения длинны и ширины. Программа, очевидно имеет свои недоработки, но фиксить я их не буду.
Сделал программу, которая отрисовывает шахматную доску принимая в качестве параметра значения длинны и ширины. Программа, очевидно имеет свои недоработки, но фиксить я их не буду.
Транзистор это как труба с вентилем, ток по трубе течёт от коллектора к эмиттеру, а вентиль - база, на неё подаётся управляющий ток, который может быть намного меньше, чем ток по основной трубе. То есть база-вентиль своим малым током управляет большим током по трубе коллектор-эмиттер.
А нужно это, например, для усиления сигнала.
Ты поймал слабый сигнал, который даёт слабый ток, при этом у тебя есть источник питания, который может дать сильный ток. Ты пускаешь сильный ток по трубе коллектор-эмиттер, а на базу-вентиль подаёшь слабый управляющий сигнал, в итоге у тебя сильный напор в трубе принимает форму слабого сигнала @ profit
Ну и кстати от коллектора к эмиттеру может течь ток, также может и наоборот, в этом отличие npn от pnp, но база всегда база
Это всё - анологии, дружище. Я много раз слышал: транзистор - ветиль, проводник - труба, диод - бутерброд. Но зачем это пишут? Если подходить строго, то все эти анологии - ложны. Если подходить "по-инжинерному", то всем эти анологии - крайне бесполезны. Как минимум, для инжинерного понимания вопроса нужно знать соотношения: какое напряжение где окажется, и какой вследствии потечёт ток. Я вот подключил транзистор, и я не увидел усиления сигнала. Ток течёт от коллектора к эммитеру - как ты и сказал, но при этом между этими точками находится напряжение база-эммитер. Так как ток - это всегда следствие напряжения, то значение тока по закону Ома будет небольшим: I = Uбазы/R.
Например, напряжение база-эммитер: Uбаза = 5 В;
Сопотивление цепи: R = 1 Ом;
Напряжение коллектор-эммитер: Uколлектор = 24 В.
Без транзистора ток был бы 24 А. С транзистором 5 А. Усиление? Или управление.
>для инжинерного понимания вопроса нужно знать соотношения: какое напряжение где окажется, и какой вследствии потечёт ток
Вижу дискуссию об электронике - не могу не вставить свои 5 копеек.
Если тебе нужно такое представление, то гугли представление транзистора в виде четырехполюсника. Ну и вообще теорию четырехполюсников. Они характеризуются разными семействами параметров. Чаще всего h-параметры используют. Но например можно пользоваться и z-параметрами.
Переконвертить в PDF и распознать в том же Acrobat. Делов то. Столяров судя по биографии долбоеб. Раньше люди учили ассемблер по работам хакеров и практикующих черное байтоебство инженеров по микроконтроллерам.
Препод, который не работает также в тырпрайзе - не наставник, препод это редактор лекционных материалов и носитель чсв.
мимо закончил универ почти 20 лет назад
> Столяров судя по биографии долбоеб.
Ну он такой.. Шизоидный слегка. Ненавидит рекламу, называет её "информационным насилием", использует pale moon, сидит только на старых гипертекстовых html5 сайтах, по его мнению совеменные браузеры и сайты неоправдано нагружены, не любит java script и считает операционную систему windows - переоценённой и намерено распиареной.
В этом есть что-то прикольное. Да и книги его мне заходят пока-что.
> Раньше люди учили ассемблер по работам хакеров
И по сей день так делают. И очень даже неплохо. Но я не шибко умный, всего 98 IQ. Мне сложно, чтобы вот так сходу взять и сделать что-то крутое. Оно и очевидно, будь я умным - давно бы уже зашибал крупное баблишко. Но вот как-то всё у меня как у мямли, ни то, ни сё. Так, что пока посижу поаутирую в Паскалик. Легко заметить, что я не приверженец тредов "становления сверхчеловеком", и вообще, человек довольно обычный и скучный.
К слову, неплохо было бы научиться дизассемблить хотя-бы свои программы. Можно было бы разобрать как и что, ломать всякое, изучать. Единственная зацепка пока - параграф А. В. Столярова про ассемблер. Но для начала хочу дочитать 200 сраниц про язык Паскаль. Довольно интересно даже. Я в школе и не знал, что все эти функции имеют некоторое другое значение, нежели нам рассказывают.
Прочитавъ лишь ОП-постъ, вдруг пришло понимание: до чего же прекрасно пишет, сукин сын!
PERFECT.
Чувак, тебя же вычислят и набьют ебало. Осторожнее, мудила.
Я тебя обожаю
>Кто-то пользуется командной строкой до сих пор что-ли?
ёбънуть тебе аж захотелось
мечтаю жить в командной строке, но не скажу пока, как это сделаю.
>Ненавидит рекламу, называет её "информационным насилием", использует pale moon, сидит только на старых гипертекстовых html5 сайтах, по его мнению совеменные браузеры и сайты неоправдано нагружены, не любит java script и считает операционную систему windows - переоценённой и намерено распиареной.
Абсолютно трезвый взгляд на вещи в обществе пьяниц.
Одно дело - человек который любит "старый" стиль, другое дело - человек который для себя в ущерб отказываться пользоваться "вконтакте", только потому, что там "информационное насилие". Как можно назвать такого человека, кроме как шизоидом?
Мне тоже нравится легковесный веб, но надо понимать, что это не более чем ностальгия. Если подумать, в чем преимущество "старых" технологий? Разве в 00-10е не существовало говнокода? Разве не существовало слежки? Разве не было ратников, винлокеров, смс-бомберов, фишинга и прочего скама? Разве в прошлом не было риелторов и издательств?
Могу согласиться только с утверждением, что игровая индустрия выродилась.
В остальном современные программы как минимум актуальны, а как максимум ещё и практичнее предшественников.
Научный руководитель занят наукой, ему интересны формулы и испытания. Попрошу заметить, ему не интересно копаться в LaTEX и понимать что там, да как там - он выбирает Microsoft Word. Тем, кто работает вместе с научруком (даже если они и знают LaTEX), будет проще пользоваться Word, дабы не ебаться с совместимостью работ. Таким образом, вордом приходиться пользоваться всем - это есть путь наименьшего сопротивления. Обучение это трудозатратно, это рискованно, и я даже читал, что это вредно для здоровья. Зачем лишний раз изучать что-то? Если бы для Linux не требовалось пердолинга - им бы все и пользовались. Бухгалтеру нужны таблички Exel, а проектировщику AutoCAD. Никто не хочет думать "как же мне установить драйвера под планшет Wacom, настроить Wine для AdobePhotoshop" - это выходит за рамки конкретной сферы деятельности.
Кстати, есть и положительные примеры: Blender - бесплатная программа, технологически опередила и обоссала 3Ds Max. Или тот же MacOS - это же Unix система, но она завоевала свою популярность. Потому, что дело тут в утилитарности, а не в "правильности" или "технологичности" софта.
Но от слов про школьников не отказываюсь. Я так и не понял, зачем в школах ставят Windows, они же там один чъёрт заняты тем, что компьютер изучают. От того, что школьники понастраивают ОС хуже не станет, это все вполне вписывается деятельность "обучение", при этом они и лучше понимать будут с чем работают, и еще и платить не нужно за софт и ОС! Посоветуйте кто-нибудь эту идею министерству образования и науки.
>Посоветуйте кто-нибудь эту идею министерству образования и науки
О, у нас в школе был такой мужик, ремонтник, его иногда приглашали починить электронику какую-нибудь. И он всё пытался продавить эту идею, поставить линукс на все школьные компы. Даже не взамен виндовс, а в дополнение к нему. Но идея была воспринята без энтузиазма — преподавательский состав и с виндой-то не всегда справляется, вообще с компами не очень, поэтому мысль о линуксе блокируется их подсознанием абсолютно
>Зачем мне этот readln? Кто-то пользуется командной строкой до сих пор что-ли?
readln читает текст из файла, то есть
>var f: text; s: string;
>assign(f, 'file.txt'); reset(f);
>readln(f, s);
Без явного указания файла используется стандартный ввод, который может быть перенаправлен в другое место при запуске программы (в КОМАНДНОЙ СТРОКЕ через my_app <data.txt или generate_data | my_app). Стандартный ввод представлен глобальной переменной input: text, так что readln(s) эквивалентно readln(input, s) и можно даже сделать assign(input, 'file.txt'); reset(input), чтобы последующие операции без указания файла работали с file.txt (но это читерство).
> Blender - бесплатная программа, технологически опередила и обоссала 3Ds Max
Можно поподробнее об этом? Чем лучше, в чём опередила, под каким углом обоссала (ну или хотя бы ссылочку)
А зачем мне ссылки? Я как юзер и того и другого сам могу все расписать.
Blender:
-Удобные горячие клавиши.
-Мультиплатформенность.
-Отличный стандартный рендер.
-Куча встроенных процедур для моделлинга.
-Бесплатность.
Большинство корпораций как раз использует блендер, в качестве основного инструмента моделек.
Что же такое 3Dшмякс:
-Интерфейс склеенный из костылей, который всё равно приходится допиливать плагинами.
-Цена зашкаливает, при этом программа по сути выполняет лишь функцию "отрендерить красивые картиночки". Вряд-ли кто то делает анимацию в 3Ds Max.
-Всратый стандартный редактор частиц.
-Работа только под шинду, когда даже Maya поддерживает несколько платформ.
-Магия постоянных вылетов, которые фиксят потом в версиях хххх.1, хххх.2, хххх.3 и так далее пока не дождешься сиабильного релиза.
Ну, то есть в современном Максе работать то и можно, но зачем? Преимуществ никаких ещё и допиливать надо (как минимум заменить стандартный рендер). При этом всём тот же Блендер взял, запустил "из коробки" и он работает. А качество рендера одинаковое.
Спасибо, рируру. Это приобретает новый смысл.
> преподавательский состав и с виндой-то не всегда справляется, вообще с компами не очень, поэтому мысль о линуксе блокируется их подсознанием абсолютно
Преподаватели информатики обычно что-то да понимают. Пользоваться компами умеет хотя-бы.
>читает текст из файла,
уточнение: не из файла, а из дескриптора файла, связанного с этим самым файлом
В мануале по Linux тоже не определились, и https://linux.die.net/man/2/read как системный вызов
>читает из файлового дескриптора (просто)
а https://linux.die.net/man/3/read как C-функция
>читает из файла, связанного с файловым дескриптором
Но те штуки явно принимают файловый дескриптор, а эта штука принимает непрозрачный языковой тип Text (TTextRec), которому даже не предусмотрено способа задать файл по дескриптору (только по имени), поэтому даже для педантов (https://vk.com/wall-92876084_76543) она читает или просто из файла, или, в крайнем случае, из файла, заданного TTextRec.
...Более того, после второй картинки я вспомнил, что во Free Pascal есть функция https://www.freepascal.org/docs-html/rtl/system/readstr.html, которая, аналогично sscanf в C, работает как read, но читает данные из строки, а не файла. Внутри она реализована как конструирование специальной f: TTextRec с коллбэками для строки с последующим вызовом на ней обычной read(f, ...), так что даже с точки зрения реализации в ней не обязательно фигурирует дескриптор.
readln - это высокоуровневая функция, если ты собираешь код под Linux, то все сведется в конечном счете к системному вызову read (что логично, ибо как еще что-то прочитать, в конечном итоге с диска? происходит обращение к ядру)
какие системные вызовы под NT-ядром (или как сейчас называется ядро у Windows?) я не знаю, но что-то наверняка аналогичное.
При этом перед системным вызовом read (или аналог), должен идти сперва open (или аналог) .
Файловый дескриптор - просто структура, содержащая ссылку на inode (№ файла) файла в файловой таблице, чтобы можно было с ним поработать.
Ты под Linux изучаешь программирование? Если да, то очень здорово.
Вот я и говорю, что System.read/ln — настолько высокоуровневая функция, что «файлом» для неё может быть строка, а при большом желании — что угодно, а не только файл ОС (ну, хотя нет официального способа так сделать и это деталь реализации, чтобы переиспользовать имеющиеся механизмы под ReadStr/WriteStr; сейчас загуглил, что FILE в C примерно так же делают: https://sourceware.org/glibc/wiki/LibioVtables), и в свете этого говорить, что она читает из дескриптора — не только ненужная конкретика, но и вводящая в заблуждение.
Просто загуглил, что предпочитали бы говорить в случаях, если бы эта функция действительно была тонюсенькой обёрткой над операциями с дескриптором, на примере функций, работающих с буквальным дескриптором.
>libio is the glibc component which implements the foundations of FILE * streams support
Да мы вообще о разном. Это уже абстракция над абстракцией.
И libio описывает не FILE , а файловые потоки на основе этой структуры. Сама структура FILE определена в stdio.h (https://www.ibm.com/docs/en/zos/2.3.0?topic=files-stdioh-standard-input-output)
И вот еще про системный вызов open() , предшествующий операции чтения/записи
>A call to open() creates a new open file description, an entry in the system-wide table of open files. This entry records the file offset and the file status flags (modifiable via the fcntl(2) F_SETFL operation). A file descriptor is a reference to one of these entries; this reference is unaffected if pathname is subsequently removed or modified to refer to a different file. The new open file description is initially not shared with any other process, but sharing may arise via fork(2).
Почему вводящая в заблуждение? Просто на более низком уровне по-другому и не вывернешься.
Любая чтение/запись - только через дескриптор. Разумеется, сам дескриптор - это не область данных.
Но ты напрямую и не сможешь читать "из файла" (без read) - потому что "файл" это , как ты понимаешь, тоже абстракция.
За тебя в общем делает всё ядро, через которое ты общаешься со всей периферией вроде устройств хранения данных.
>Почему вводящая в заблуждение?
Потому что с учётом того, что за принимаемым readln «файлом» может стоять просто строка с данными, а не файл ОС, моё утверждение из «readln читает текст из файла» верно в любом случае (при нужном понимании слова «файл»), а твоя правка к нему из «readln читает текст из дескриптора файла, связанного с файлом» — нет, она в любом случае бесполезна потому, что Паскаль не предоставляет официального способа ни сообщить (вместо открытия по имени), ни получить этот дескриптор, но и дескриптора-то в случае строки не будет. −_−"
До становления сверхчеловеком осталось чуть меньше тридцати страниц текста. Там дальше начинается раздел посвящённый ассемблеру. За это время я успел шесть раз услышать, что ассемблер "мёртвый язык" или что "ассемблер не нужен". Как он может быть мёртвым, когда даже будучи полным нулём в программировании, я наткнулся на его упоминание не один раз. Мертвый язык - это фортран какой-нибудь или delphi, ни об одном из них я и не слышал, пока не начал читать всякие статьи про историю программирования. Вероятно аноны, пишущие такие отзывы об ассемблере, имели ввиду, что сложно найти работу связанную с программированием на ассемблере. Работа? Будто бы никому никогда не хотелось ничего "взломать", или вскрыть, и посмотреть что внутри программы. При работе на FreeBSD меня увлёк вопрос: Возможно ли программу, изначально предназначенную под Windows, перекомпилировать под FreeBSD?
Для начала, возможно ли это чисто технически? Допустим есть программа "hello world", и мы пропускаем её через дизасемплер-декомпилятор. Можно ли полученный код вставить в .txt и скомпиллировать на FreeBSD (так, чтобы программа работала аналогично с виндоусовской).
В продолжении возникает следующий вопрос: существуют ли такие функции и процедуры, которые принципиально невозможно реализовать на FreeBSD? Если, например, программа чуть сложнее хеллоуворлда, и в ней присутствуют сторонние библиотеки или фреймворки - возможно ли их перенести на другую ОС.
Ну и конечно-же сколько на всё это может уйти времени, с учётом того, что процесс можно оснащать любыми технологиями, вплоть до нейросетей, которые бы помогали декомпилятору опознать псевдокод.
Если ответ - да (в чем я сомневаюсь), то можно было бы иметь Photoshop на FreeBSD, без всяких Wine.
Для начала, возможно ли это чисто технически? Допустим есть программа "hello world", и мы пропускаем её через дизасемплер-декомпилятор. Можно ли полученный код вставить в .txt и скомпиллировать на FreeBSD (так, чтобы программа работала аналогично с виндоусовской).
В продолжении возникает следующий вопрос: существуют ли такие функции и процедуры, которые принципиально невозможно реализовать на FreeBSD? Если, например, программа чуть сложнее хеллоуворлда, и в ней присутствуют сторонние библиотеки или фреймворки - возможно ли их перенести на другую ОС.
Ну и конечно-же сколько на всё это может уйти времени, с учётом того, что процесс можно оснащать любыми технологиями, вплоть до нейросетей, которые бы помогали декомпилятору опознать псевдокод.
Если ответ - да (в чем я сомневаюсь), то можно было бы иметь Photoshop на FreeBSD, без всяких Wine.
Задачка простая, а решить так и не смог. Мог бы подглядеть решение, но всё хотелось попрактиковаться. Так сказать устроить некоторый "краш тест". Вышло неудачно. Видимо я что-то упустил из прочитанного материала.
Формулировка. Написать программу, которая читает целые числа из потока стандартного ввода, до возникновения ситуации "конец файла". После чего, печатает все введённые числа в обратном порядке. Количество чисел заранее неизвестно, вводить явные ограничения на их количество запрещается.
*В решении использовать односвязные списки, так как тема по ним.
Для начала, как вообще выделить числа из стандартного потока ввода? Можно, например, отфильтровать все числа, и записать их в строку через пробелы. Так, собственно я и поступил. Получилось что-то вроде:
_While eof do
___If char = 0...9 then
_____string := string + char
_____trash-detect := 0
___Else
_____trash-detect := trash-detect + 1
_____If trash-detect = 1 then
_______string := string + space
При виде первого, отличного от числа, символа, программа поставит пробел. При виде остальных - ничего не поставит. В дальнейшем, такая программа оснастилась ещё одной функцией: если текущий символ - цифра, и счётчик цифр - нулевой, программа вписывала открывающуюся скобку. Далее при столкновении с прочими символами, обнуляла счётчик цифр, при этом, если счётчик сторонних символов - нулевой, то скобка закрывалась. При столкновении с цифрами, счётчик сторонних символов обнулялся. Таким образом числа "паковались" в скобки. Предполагалось создать процедуру, которая по скобкам вычленяет эти числа, а затем записывает их в обратном направлении. Была идея и как-то это провернуть через рекурсию. Но эта программа, скорее всего, не имеет смысла. Во-первых, если переменная-счётчик переполнится - пробелы будут разделять числа не там где надо. Сомневаюсь, что кто-то введёт 65536-значное число, но всё же, по условию, явных ограничений быть не должно. Во-вторых, сама строка не вечная, это ограничение уже натолкнуло меня на мысль, что лучше разобраться с односвязными списками.
Собственно, есть у нас список, подобный тому, что описан далее в параграфе. А как им пользоваться - нет ни малейшей догадки. Допустим, все целые числа записались во все созданные поля, сколь много мы бы их не создали. Но ведь мало того, что они должны быть разделены, так их ещё и в обратном порядке записать надо. Снова писать переменные-счётчики, и выписывать числа в отдельные переменные? В таком случае роль этого односвязного списка не велика, и программа снова бесполезна.
Надо было сразу бросить все эти недоизобретения и просто прочитать решение. Очевидно же, что ответ будет заключаться в какой-то важной функции односвязных списков, до которой едва-ли можно додуматься, не имея на то должной практики. Зато, теперь, не будет чувства "бесполезности" этих списков.
Формулировка. Написать программу, которая читает целые числа из потока стандартного ввода, до возникновения ситуации "конец файла". После чего, печатает все введённые числа в обратном порядке. Количество чисел заранее неизвестно, вводить явные ограничения на их количество запрещается.
*В решении использовать односвязные списки, так как тема по ним.
Для начала, как вообще выделить числа из стандартного потока ввода? Можно, например, отфильтровать все числа, и записать их в строку через пробелы. Так, собственно я и поступил. Получилось что-то вроде:
_While eof do
___If char = 0...9 then
_____string := string + char
_____trash-detect := 0
___Else
_____trash-detect := trash-detect + 1
_____If trash-detect = 1 then
_______string := string + space
При виде первого, отличного от числа, символа, программа поставит пробел. При виде остальных - ничего не поставит. В дальнейшем, такая программа оснастилась ещё одной функцией: если текущий символ - цифра, и счётчик цифр - нулевой, программа вписывала открывающуюся скобку. Далее при столкновении с прочими символами, обнуляла счётчик цифр, при этом, если счётчик сторонних символов - нулевой, то скобка закрывалась. При столкновении с цифрами, счётчик сторонних символов обнулялся. Таким образом числа "паковались" в скобки. Предполагалось создать процедуру, которая по скобкам вычленяет эти числа, а затем записывает их в обратном направлении. Была идея и как-то это провернуть через рекурсию. Но эта программа, скорее всего, не имеет смысла. Во-первых, если переменная-счётчик переполнится - пробелы будут разделять числа не там где надо. Сомневаюсь, что кто-то введёт 65536-значное число, но всё же, по условию, явных ограничений быть не должно. Во-вторых, сама строка не вечная, это ограничение уже натолкнуло меня на мысль, что лучше разобраться с односвязными списками.
Собственно, есть у нас список, подобный тому, что описан далее в параграфе. А как им пользоваться - нет ни малейшей догадки. Допустим, все целые числа записались во все созданные поля, сколь много мы бы их не создали. Но ведь мало того, что они должны быть разделены, так их ещё и в обратном порядке записать надо. Снова писать переменные-счётчики, и выписывать числа в отдельные переменные? В таком случае роль этого односвязного списка не велика, и программа снова бесполезна.
Надо было сразу бросить все эти недоизобретения и просто прочитать решение. Очевидно же, что ответ будет заключаться в какой-то важной функции односвязных списков, до которой едва-ли можно додуматься, не имея на то должной практики. Зато, теперь, не будет чувства "бесполезности" этих списков.
Ради интереса решил проиллюстрировать примеры односвязного списка из книги. И это было сделано не зря. Открыл для себя одну, казалось бы очевидную, особенность указателей: если присвоить указателю "А" значение указателя "B", то указатель "B" можно удалить, и значение "А" не измениться. И все так и должно быть, указатель - это же переменная. Ведь если обычной переменной "С" присвоить число "6", а переменой "D" - значение "С", то "D" будет иметь значение "6", даже если значение "С" изменить или вовсе удалить эту переменную.
Может проиллюстрировал я и не совсем корректно, ведь я понятия не имею как выглядят адреса памяти, и как в этих адресах будет выглядеть список. Но моя иллюстрация кажется мне более наглядной.
Также обнаружил, что у самого списка должен быть адрес. Исходя из того, что в одной переменной, двух значений быть не может, указатель не сможет присвоить себе адреса всех элементов списка - должен быть один "головной" адрес.
Иллюстрации в книге Столярова немного сбивают с толку. Да и само название "указатель", ассоциируется с чем угодно, но не с переменной. И когда на рисунках в книге были нарисованы стрелочки, я не понимал, а что они значат, и что к чему присваивают. Интуитивно кажется, что А -> Б означает: "А положить в Б", но если слегка подумать, то совсем наоборот: "А указывает на Б, то есть адресс Б кладётся в А".
Может проиллюстрировал я и не совсем корректно, ведь я понятия не имею как выглядят адреса памяти, и как в этих адресах будет выглядеть список. Но моя иллюстрация кажется мне более наглядной.
Также обнаружил, что у самого списка должен быть адрес. Исходя из того, что в одной переменной, двух значений быть не может, указатель не сможет присвоить себе адреса всех элементов списка - должен быть один "головной" адрес.
Иллюстрации в книге Столярова немного сбивают с толку. Да и само название "указатель", ассоциируется с чем угодно, но не с переменной. И когда на рисунках в книге были нарисованы стрелочки, я не понимал, а что они значат, и что к чему присваивают. Интуитивно кажется, что А -> Б означает: "А положить в Б", но если слегка подумать, то совсем наоборот: "А указывает на Б, то есть адресс Б кладётся в А".
Добил эту задачу. Теперь задача решена верно - без всяких дополнительных переменных, которые могут переполниться в неподходящий момент. В отсутстии идей к решению, повспоминать все необычные операторы, такие как Goto. По сути, он - бесполезен. Можно же сделать всё из привычных условных выражений:
if not(kbrd_is_num) or not(b^.data = ' ') then...
Но почему-то именно он меня натолкнул на верное решение.
Ещё, неплохо было бы создать процедуру, которая переводит, введённый с клавиатуры char в целое число, домножает его на соответствующую разряду степень десятки, и уже после этого присваивает b^.data. Тогда уверенно можно было бы сказать, что выводятся именно числа, а не просто строчки с символами цифр. Делать я конечно же это не буду. А то, так можно и экспертом по созданию хеллоуворлдов стать.
if not(kbrd_is_num) or not(b^.data = ' ') then...
Но почему-то именно он меня натолкнул на верное решение.
Ещё, неплохо было бы создать процедуру, которая переводит, введённый с клавиатуры char в целое число, домножает его на соответствующую разряду степень десятки, и уже после этого присваивает b^.data. Тогда уверенно можно было бы сказать, что выводятся именно числа, а не просто строчки с символами цифр. Делать я конечно же это не буду. А то, так можно и экспертом по созданию хеллоуворлдов стать.
С паскалем покончено. Начинаю изучать ассемблер. Пока, что работаю на Windows, по причинам, связанным с софтом.
Пытался найти файл описания макросов "stud_io.inc" под Windows - не вышло. Как оказалось этот модуль не является сиандартным в NASM, и скорее всего написан автором книги самолично, ведь первый запрос в гугле ведёт прямиком на сайт Андрея Викторовича. Зато почитал комментариями под его публикацией - настроение поднялось.
Пользователь #1:
"Добрый вечер. Подскажите, где можно взять файл "stud_io.inc" и в какую папку nasma положить? Пытался на этой странице взять, но куда и с каким разрешением положить не знаю."
Андрей Викторович:
"Папки - в шкафу
Во-первых, термин "папка" в применении к директориям недопустим, оставьте такую терминологию секретаршам. Папки обычно делают из картона и ставят в шкаф. В компьютере никаких "папок" нет и быть не может.
Во-вторых, на вопрос "где взять" вы ответили сами. Файл следует взять на этой странице, выше есть ссылка.
В-третьих, чтобы всё сработало, этот файл должен находиться в той же директории, что и ваш файл, который вы транслируете nasm'ом. Вообще-то это довольно очевидно, если внимательно прочитать в книге, как работает макродиректива %include.
Но вот насчёт "с каким разрешением" — на такой вопрос я ответить не могу, я, пардон, даже представить себе не могу, что вы имеете в виду. Если имеется в виду действительно "разрешение", то такая характеристика присуща растровым графическим файлам, видео и (с некоторой натяжкой) аудио, но никак не текстовым файлам. Если имеются в виду "разрешения" (а не "разрешение"), то есть права доступа (один из очень кривых вариантов перевода термина "permissions"), то пользователь, под которым вы работаете, должен иметь права на чтение этого файла, только вряд ли это то, что вы имели в виду. Наконец, можно предположить, что имелось в виду "расширение" (то есть часть имени файла, указывающая на его формат и отделяемая от имени точкой) — в этом случае да будет вам известно, что это пресловутое "расширение" (extension) бывает только под Windows. В *nix-системах используется понятие "суффикс", которое не является однозначно связанным с типом файла и вообще необязательно. В применении к stud_io.inc таким суффиксом, очевидно, является ".inc".
На всякий случай отмечу, что, ежели вам пришло в голову пробовать это всё под виндой, то stud_io.inc вам ничем не поможет — он зависит не только от конкретного набора поддерживаемых операционкой системных вызовов, но и от конкретной конвенции вызовов, именно поэтому для Linux и FreeBSD используются совершенно разные версии. Версии для Windows нет и не будет."
Или вот ещё:
Пользователь#2: "Что-то вас заносит
> не имея возможности к исполнению алгоритмически полного кода, злоумышленник вряд ли получит контроль над моим браузером
Ой. я вас умоляю. Безопасность браузера слабо коррелирует с яваскриптом. Мне, наверное, будет достаточно напомнить Вам об эпичной дырище с эксплойтами через jpeg картинки. Неужели вы и картинки тоже поотключали для пущей безопасности? :)
В своей паранойе вы забываете о том, что для того, чтобы вас взломали, вы должны кого-то заинтересовать. Если ваши данные никому не интересны, коммерческой ценности не имеют, то можете хоть флеш включить, хоть яву, хоть сильверлайт в браузере, но если он регулярно обновляется, то взлома вам ждать придётся до следующего века.
Кроме того, моя паранойя мне говорит, что такие данные, утечка которых могла бы Вас "сильно огорчить", вообще не должны находиться на компьютере. А всё что есть на моём компе я готов любому показать и так :)"
Андей Викторович:
"Ну что же, тут нужен ликбез
Ой. я вас умоляю. Безопасность браузера слабо коррелирует с яваскриптом
Судя по вашим дальнейшим сентенциям, в безопасности вы вообще ничего не понимаете. Как, впрочем, и большинство людей, в том числе и «профессиональных айтишников» (кавычки выделены жирным). Но я — понимаю, и смею заверить, что связь тут самая прямая. Некоторые пояснения даны ниже.
Мне, наверное, будет достаточно напомнить Вам об эпичной дырище с эксплойтами через jpeg картинки
Это вы не вот этот вот, случайно, имеете в виду?
http://nakedsecurity.sophos.com/2012/06/19/ie-remote-code-execution-vuln...
Это, во-первых, IE (ну, если человек использует Windows, то о безопасности ему можно забыть, а если он ещё и IE гоняет, то ему поможет разве что бригада докторов). А во-вторых, там сразу, то есть прямо сходу, упоминается, что Cunningly-crafted JavaScript code - which can be embedded in a web page to foist the exploit on unsuspecting vistors - is circulating freely on the internet. Как говорится, sapienti sat.
Можно ещё вот такое вспомнить: https://bugzilla.redhat.com/show_bug.cgi?id=639920 Тоже задействованы JPEG'и, и — surprise — речь идёт о Java. Правда, не JS. Ну, обычная Java уже по умолчанию в большинстве браузеров выключена, но принцип всё тот же: есть интерпретатор — есть дыра, нет интерпретатора — нет дыры.
Информации об эксплойтабельных дырах, которые используют JPEG, но при этом не зависят от интерпретатора на стороне ломаемого клиента, сходу не нашел. Ссылку в студию — интересно, о какой дыре идёт речь и что через неё можно было сделать.
В любом случае, дыры бывают, конечно, разные, но если дыра в коде распаковщика JPEG — это (а) последствия безалаберности программиста и (б) как правило, через такую дыру сложно сделать что-то серьёзное, то дыра в алгоритмически полном интерпретаторе (любом) — это, во-первых, свойство предметной области (т.е. недырявых интерпретаторов не бывает, вопрос только в скорости обнаружения дыр и в том, кто первый до неё, дыры, доберётся) и во-вторых, сам факт наличия интерпретатора сильно облегчает взломщику дальнейшую работу после того, как взлом уже состоялся.
В своей паранойе вы забываете о том, что для того, чтобы вас взломали, вы должны кого-то заинтересовать. Если ваши данные никому не интересны, коммерческой ценности не имеют, то можете хоть
Это верно только для случая, когда взлом моей машины выполняется вручную (человеком) и целенаправленно (то есть целью взлома являюсь именно я, а не "просто кто-нибудь"). Если дело до этого дойдёт, то маловероятно, что ломать меня будут через браузер, потому что для этого нужно сначала узнать, на каких сайтах я бываю, потом получить к ним админский доступ (желаю успехов), и только потом что-то может получиться. Ну то есть со мной, конечно, не получится.
Эксплойты, работающие через JS/flash/прочее, обычно нацелены не на конкретную машину и не на конкретного пользователя, а на бомбардировку по площадям. Целью такой бомбардировки является установление контроля над возможно бОльшим количеством случайных машин с целью, например, ретрансляции спама или организации DDoS-атак. Слышали такое понятие "ботнет"?..."
Мне нравится. Его студентам наверное нелегко приходится.
Пытался найти файл описания макросов "stud_io.inc" под Windows - не вышло. Как оказалось этот модуль не является сиандартным в NASM, и скорее всего написан автором книги самолично, ведь первый запрос в гугле ведёт прямиком на сайт Андрея Викторовича. Зато почитал комментариями под его публикацией - настроение поднялось.
Пользователь #1:
"Добрый вечер. Подскажите, где можно взять файл "stud_io.inc" и в какую папку nasma положить? Пытался на этой странице взять, но куда и с каким разрешением положить не знаю."
Андрей Викторович:
"Папки - в шкафу
Во-первых, термин "папка" в применении к директориям недопустим, оставьте такую терминологию секретаршам. Папки обычно делают из картона и ставят в шкаф. В компьютере никаких "папок" нет и быть не может.
Во-вторых, на вопрос "где взять" вы ответили сами. Файл следует взять на этой странице, выше есть ссылка.
В-третьих, чтобы всё сработало, этот файл должен находиться в той же директории, что и ваш файл, который вы транслируете nasm'ом. Вообще-то это довольно очевидно, если внимательно прочитать в книге, как работает макродиректива %include.
Но вот насчёт "с каким разрешением" — на такой вопрос я ответить не могу, я, пардон, даже представить себе не могу, что вы имеете в виду. Если имеется в виду действительно "разрешение", то такая характеристика присуща растровым графическим файлам, видео и (с некоторой натяжкой) аудио, но никак не текстовым файлам. Если имеются в виду "разрешения" (а не "разрешение"), то есть права доступа (один из очень кривых вариантов перевода термина "permissions"), то пользователь, под которым вы работаете, должен иметь права на чтение этого файла, только вряд ли это то, что вы имели в виду. Наконец, можно предположить, что имелось в виду "расширение" (то есть часть имени файла, указывающая на его формат и отделяемая от имени точкой) — в этом случае да будет вам известно, что это пресловутое "расширение" (extension) бывает только под Windows. В *nix-системах используется понятие "суффикс", которое не является однозначно связанным с типом файла и вообще необязательно. В применении к stud_io.inc таким суффиксом, очевидно, является ".inc".
На всякий случай отмечу, что, ежели вам пришло в голову пробовать это всё под виндой, то stud_io.inc вам ничем не поможет — он зависит не только от конкретного набора поддерживаемых операционкой системных вызовов, но и от конкретной конвенции вызовов, именно поэтому для Linux и FreeBSD используются совершенно разные версии. Версии для Windows нет и не будет."
Или вот ещё:
Пользователь#2: "Что-то вас заносит
> не имея возможности к исполнению алгоритмически полного кода, злоумышленник вряд ли получит контроль над моим браузером
Ой. я вас умоляю. Безопасность браузера слабо коррелирует с яваскриптом. Мне, наверное, будет достаточно напомнить Вам об эпичной дырище с эксплойтами через jpeg картинки. Неужели вы и картинки тоже поотключали для пущей безопасности? :)
В своей паранойе вы забываете о том, что для того, чтобы вас взломали, вы должны кого-то заинтересовать. Если ваши данные никому не интересны, коммерческой ценности не имеют, то можете хоть флеш включить, хоть яву, хоть сильверлайт в браузере, но если он регулярно обновляется, то взлома вам ждать придётся до следующего века.
Кроме того, моя паранойя мне говорит, что такие данные, утечка которых могла бы Вас "сильно огорчить", вообще не должны находиться на компьютере. А всё что есть на моём компе я готов любому показать и так :)"
Андей Викторович:
"Ну что же, тут нужен ликбез
Ой. я вас умоляю. Безопасность браузера слабо коррелирует с яваскриптом
Судя по вашим дальнейшим сентенциям, в безопасности вы вообще ничего не понимаете. Как, впрочем, и большинство людей, в том числе и «профессиональных айтишников» (кавычки выделены жирным). Но я — понимаю, и смею заверить, что связь тут самая прямая. Некоторые пояснения даны ниже.
Мне, наверное, будет достаточно напомнить Вам об эпичной дырище с эксплойтами через jpeg картинки
Это вы не вот этот вот, случайно, имеете в виду?
http://nakedsecurity.sophos.com/2012/06/19/ie-remote-code-execution-vuln...
Это, во-первых, IE (ну, если человек использует Windows, то о безопасности ему можно забыть, а если он ещё и IE гоняет, то ему поможет разве что бригада докторов). А во-вторых, там сразу, то есть прямо сходу, упоминается, что Cunningly-crafted JavaScript code - which can be embedded in a web page to foist the exploit on unsuspecting vistors - is circulating freely on the internet. Как говорится, sapienti sat.
Можно ещё вот такое вспомнить: https://bugzilla.redhat.com/show_bug.cgi?id=639920 Тоже задействованы JPEG'и, и — surprise — речь идёт о Java. Правда, не JS. Ну, обычная Java уже по умолчанию в большинстве браузеров выключена, но принцип всё тот же: есть интерпретатор — есть дыра, нет интерпретатора — нет дыры.
Информации об эксплойтабельных дырах, которые используют JPEG, но при этом не зависят от интерпретатора на стороне ломаемого клиента, сходу не нашел. Ссылку в студию — интересно, о какой дыре идёт речь и что через неё можно было сделать.
В любом случае, дыры бывают, конечно, разные, но если дыра в коде распаковщика JPEG — это (а) последствия безалаберности программиста и (б) как правило, через такую дыру сложно сделать что-то серьёзное, то дыра в алгоритмически полном интерпретаторе (любом) — это, во-первых, свойство предметной области (т.е. недырявых интерпретаторов не бывает, вопрос только в скорости обнаружения дыр и в том, кто первый до неё, дыры, доберётся) и во-вторых, сам факт наличия интерпретатора сильно облегчает взломщику дальнейшую работу после того, как взлом уже состоялся.
В своей паранойе вы забываете о том, что для того, чтобы вас взломали, вы должны кого-то заинтересовать. Если ваши данные никому не интересны, коммерческой ценности не имеют, то можете хоть
Это верно только для случая, когда взлом моей машины выполняется вручную (человеком) и целенаправленно (то есть целью взлома являюсь именно я, а не "просто кто-нибудь"). Если дело до этого дойдёт, то маловероятно, что ломать меня будут через браузер, потому что для этого нужно сначала узнать, на каких сайтах я бываю, потом получить к ним админский доступ (желаю успехов), и только потом что-то может получиться. Ну то есть со мной, конечно, не получится.
Эксплойты, работающие через JS/flash/прочее, обычно нацелены не на конкретную машину и не на конкретного пользователя, а на бомбардировку по площадям. Целью такой бомбардировки является установление контроля над возможно бОльшим количеством случайных машин с целью, например, ретрансляции спама или организации DDoS-атак. Слышали такое понятие "ботнет"?..."
Мне нравится. Его студентам наверное нелегко приходится.
Интересный дневник. Хоть большую часть написанного я и не понимаю.
Да тут ничего интересного и понятного нет. Дневник же, да ещё и в добавок монолог. Интересное - это в /izd/.
Параллельно начал читать книгу "Кипичи 2.0". Ожидаю что-то типо "Generation П" - такой насыщенный поток эклектики прямиком из 00-х. Но пока, что только рассказ какого-то человека о том, как он ходит. Надеюсь там начнётся что-нибудь прикольное.
Как-то тухло началась глава про язык ассемблера. Я ожидал насыщенного погружения в тонкости работы процессора. Представлял себе схемы с демонстрацией, что на что воздействует, и что активирует. Но на практике, на основе прочитанного, даже простейшую программу написать не смог. Может в дальнейшем будет понятнее что к чему.
Я так и не понял, почему копьютер не может запустить текстовый файл, как исполняемый? Из прочитанного сложилось впечатление, что программа это три секции: код, данные и стек. При этом, чтобы запустить программу, нужно, чтобы операционная система поместила в регистр указателя команд, первую команду программы. Что мешает записать какие-нибудь команды процессора в текстовый файл, и запустить?
С другой стороны, мне это знать незачем. Глупые вопросы существуют не для того, чтобы на них отвечать. Они нужны лишь для "отладки" собственных знаний.
Я так и не понял, почему копьютер не может запустить текстовый файл, как исполняемый? Из прочитанного сложилось впечатление, что программа это три секции: код, данные и стек. При этом, чтобы запустить программу, нужно, чтобы операционная система поместила в регистр указателя команд, первую команду программы. Что мешает записать какие-нибудь команды процессора в текстовый файл, и запустить?
С другой стороны, мне это знать незачем. Глупые вопросы существуют не для того, чтобы на них отвечать. Они нужны лишь для "отладки" собственных знаний.
>почему копьютер не может запустить текстовый файл, как исполняемый
Исполняемые файлы — это не цельные куски кода, которые можно брать и исполнять с байта 0, они имеют специальный формат, описывающий, что, куда и как для этого загрузить (на Windows это https://ru.wikipedia.org/wiki/Portable_Executable).
.COM-файлы под DOS, насколько я про них читал (https://devblogs.microsoft.com/oldnewthing/20080324-00/?p=23033), были именно «сырым кодом, исполняемым с байта 0» и в обмен на подобное предельно простое устройство имели кучу обусловленных этим ограничений, таких как максимальный размер в 64 Кб.
С прошедшим, рируру. Не смотря на все твои старания показаться старым жирным бородатым программистом, я то знаю, что на самом деле ты няшная аниме-девочка. (Это шутка)
Интересно было почитать. Ранее я почему-то думал, что DLL не относится к конкретной ОС.
Битва калькуляторов.
Захожу в гугловский калькулятор, смело нажимаю кнопку "9", и не отпускаю до тех пор, пока мне не захочется. Мало? Поднажму ещё девяток. Всё ещё мало? А я возьму и поставлю все это в степень 9999... и буду снова жать кнопку девять, пока не надоест.
Ну всё, достаточно. Нажмём-ка кнопку "равно". И что нам выдаст? Результат: "infinity". Число очень большое, это даже не миллион, не триллион, не триллиард. Настолько большое, что можно принять его за бесконечность. Достойный ответ калькулятора. Но кто такой этот калькулятор ? Всего лишь какой-то баннер в поле быстрого ответа гугла. Звучит несерьёзно, ерунда. Пора бы попробовать настоящий standalone калькулятор.
Calc.exe - это несколько раскладок, это возможности перевода в разные системы счисления, calc.exe - выбор настоящего специалиста. Запускаем эту серьёзную машину по убийству чисел. Хочу поспамить девятками. Тыкаем на кнопку девять. Ещё раз. И ещё. 18 раз?! И это всё? И если возвести это всё в степень, жидко пукнув выдаёт "invalid", стерев весь результат? Ну ты даёшь, братан, даже счёты моей бабушки лучше справляются со своей задачей.
Это шутка, calc.exe плох не только потому, что он не может много чисел в строку вместить, у него много других минусов, вводил девятки я не для этого. Введённые числа должны храниться в памяти. Меня волновал вопрос: можно ли конкретно так заполнить память, вычислив невероятно большое число? И если нельзя, то что будет, если всё-таки попытаться? Стандартный калькулятор не смог дать такое число ввести. Калькулятор гугл, оказался довольно добрым в этом плане.
Пробегаюсь по ассемблеру. Осталось 100 страниц до конца тома, а такое чувство, что ещё 500. Вычислительная машина теперь действительно "машина". Компьютер, умеет:
0. считывать наши команды, одну за другой.
1. по команде менять значение в ячейках памяти, то есть переключать цепочку триггеров, счётчиков, согласно нашим преднаписаным указаниям.
2. выставлять флаги - показывать нам значения, которые отображают результаты последних операций.
3. выполнять переходы. То есть получать команду не из следующей ячейки памяти, а из какой-нибудь другой, находящейся по адресу через нескольно ячеек вперёд или назад.
При этом нет типов данных, есть лишь значения байтов, и уже их интерпритируй как хочешь, хоть в двоичном виде воспринимай.
Это напоминает какой-то механизм, или конечный автомат, как будто перфокарты в него заносишь.
Чтобы вкатиться реверс-нижинеринг нужно намного больше опыта, чем просто знание языка ассемблера. Дизасемблировал программу, все команды понятны, но вот что это в целом должно делать - это ещё нужно разобрать. И лучше наверное не чесать репу зря, всё равно невозможно понять, что хочет сделать автор этой программы, покуда не понимаешь, что вообще возможно сделать при разработке программы. Кто-то мне говорил, что чтобы взламывать программы, для начала нужно иметь большой опыт в их конструировании. Я думаю он прав.
Второй томик начнётся с СИ. Я подумал, может пропустить его, но прочитав оглавление, посчитал, что мне это нужно. Там как раз начинаются необходимые основы, для работы с сетями, которые почему-то везде считаются чуть ли не школьными знаниями.
Захожу в гугловский калькулятор, смело нажимаю кнопку "9", и не отпускаю до тех пор, пока мне не захочется. Мало? Поднажму ещё девяток. Всё ещё мало? А я возьму и поставлю все это в степень 9999... и буду снова жать кнопку девять, пока не надоест.
Ну всё, достаточно. Нажмём-ка кнопку "равно". И что нам выдаст? Результат: "infinity". Число очень большое, это даже не миллион, не триллион, не триллиард. Настолько большое, что можно принять его за бесконечность. Достойный ответ калькулятора. Но кто такой этот калькулятор ? Всего лишь какой-то баннер в поле быстрого ответа гугла. Звучит несерьёзно, ерунда. Пора бы попробовать настоящий standalone калькулятор.
Calc.exe - это несколько раскладок, это возможности перевода в разные системы счисления, calc.exe - выбор настоящего специалиста. Запускаем эту серьёзную машину по убийству чисел. Хочу поспамить девятками. Тыкаем на кнопку девять. Ещё раз. И ещё. 18 раз?! И это всё? И если возвести это всё в степень, жидко пукнув выдаёт "invalid", стерев весь результат? Ну ты даёшь, братан, даже счёты моей бабушки лучше справляются со своей задачей.
Это шутка, calc.exe плох не только потому, что он не может много чисел в строку вместить, у него много других минусов, вводил девятки я не для этого. Введённые числа должны храниться в памяти. Меня волновал вопрос: можно ли конкретно так заполнить память, вычислив невероятно большое число? И если нельзя, то что будет, если всё-таки попытаться? Стандартный калькулятор не смог дать такое число ввести. Калькулятор гугл, оказался довольно добрым в этом плане.
Пробегаюсь по ассемблеру. Осталось 100 страниц до конца тома, а такое чувство, что ещё 500. Вычислительная машина теперь действительно "машина". Компьютер, умеет:
0. считывать наши команды, одну за другой.
1. по команде менять значение в ячейках памяти, то есть переключать цепочку триггеров, счётчиков, согласно нашим преднаписаным указаниям.
2. выставлять флаги - показывать нам значения, которые отображают результаты последних операций.
3. выполнять переходы. То есть получать команду не из следующей ячейки памяти, а из какой-нибудь другой, находящейся по адресу через нескольно ячеек вперёд или назад.
При этом нет типов данных, есть лишь значения байтов, и уже их интерпритируй как хочешь, хоть в двоичном виде воспринимай.
Это напоминает какой-то механизм, или конечный автомат, как будто перфокарты в него заносишь.
Чтобы вкатиться реверс-нижинеринг нужно намного больше опыта, чем просто знание языка ассемблера. Дизасемблировал программу, все команды понятны, но вот что это в целом должно делать - это ещё нужно разобрать. И лучше наверное не чесать репу зря, всё равно невозможно понять, что хочет сделать автор этой программы, покуда не понимаешь, что вообще возможно сделать при разработке программы. Кто-то мне говорил, что чтобы взламывать программы, для начала нужно иметь большой опыт в их конструировании. Я думаю он прав.
Второй томик начнётся с СИ. Я подумал, может пропустить его, но прочитав оглавление, посчитал, что мне это нужно. Там как раз начинаются необходимые основы, для работы с сетями, которые почему-то везде считаются чуть ли не школьными знаниями.
Готов вступить в секту информационного насилия. Интересный человек. Ролики отлично подходят, чтобы смотреть на фоне. Ранее, я положил его книгу в стопку избранных, и всё сделал правильно - книгу просто и понятно читать.
Часто натыкаюсь на бурление а-ля:
>Программисты больше не нужны! Нейросети заменят всех! Вас скоро "выпнут"! Вопрос об этом встаёт уже не в первый раз!
И кто в таком случае будет создавать эти нейросети? Наоборот, как по мне, происходит увеличение рабочих мест, теперь нужны будут не только программисты, но и те, кто будут создавать код при помощи нейросети. Может кто-то и потеряет работу... В любом случае, обесценивание некоторых профессий происходит всегда и не то, чтобы это было чем-то фатальным.
Даже художников в полной мере заменить не получится. Я (возможно наивно) уверен, что нейросеть вполне может достичь такого же разума как и человек. Но в чём рентабельность? Какой смысл создавать ещё одного человека со всеми его недостатками? Средства автоматики для того и придуманы, чтобы заменить кривозубого крестьянина на высокоточный аппарат. Конечным потребителем всегда оказывается человек. Какой смысл от нейросети, которая рисует картины исключительно для других нейросетей? Ждать пока эти нейросети выдадут что-то что мы могли бы воспринять? Художники как раз могут быть востребованны, в качестве людей, которые пишут материал для нейросети. У художников появляется новый инструмент, а старые инструменты, такие как кисти и краски, станут чем-то вроде ассемблера: ими никто не будет рисовать, но грамотный художник всегда знает зачем они нужны.
Кроме того, "чурка с лопатой - лучший экскаватор", как говориться. Любая автоматизация стоит денег. Ручной труд и по сей день используется на малобюджетных предприятиях. Один только модуль ПЛК стоит 11к рублей - взял в карман и продал на авито, чтоб научрук клювом не щелкал.
Часто натыкаюсь на бурление а-ля:
>Программисты больше не нужны! Нейросети заменят всех! Вас скоро "выпнут"! Вопрос об этом встаёт уже не в первый раз!
И кто в таком случае будет создавать эти нейросети? Наоборот, как по мне, происходит увеличение рабочих мест, теперь нужны будут не только программисты, но и те, кто будут создавать код при помощи нейросети. Может кто-то и потеряет работу... В любом случае, обесценивание некоторых профессий происходит всегда и не то, чтобы это было чем-то фатальным.
Даже художников в полной мере заменить не получится. Я (возможно наивно) уверен, что нейросеть вполне может достичь такого же разума как и человек. Но в чём рентабельность? Какой смысл создавать ещё одного человека со всеми его недостатками? Средства автоматики для того и придуманы, чтобы заменить кривозубого крестьянина на высокоточный аппарат. Конечным потребителем всегда оказывается человек. Какой смысл от нейросети, которая рисует картины исключительно для других нейросетей? Ждать пока эти нейросети выдадут что-то что мы могли бы воспринять? Художники как раз могут быть востребованны, в качестве людей, которые пишут материал для нейросети. У художников появляется новый инструмент, а старые инструменты, такие как кисти и краски, станут чем-то вроде ассемблера: ими никто не будет рисовать, но грамотный художник всегда знает зачем они нужны.
Кроме того, "чурка с лопатой - лучший экскаватор", как говориться. Любая автоматизация стоит денег. Ручной труд и по сей день используется на малобюджетных предприятиях. Один только модуль ПЛК стоит 11к рублей - взял в карман и продал на авито, чтоб научрук клювом не щелкал.
Посвятил сегодняшний день чтению рассказа "Кирпичи 2.0".
Рассказ неплохой, мне понравился. Эдакое оффисное приключение. Посоветовали мне его в треде, где обсуждали совсем другую книгу под названием "Хватит быть славным парнем!". Я её не читал. Название интригует, но есть в нём что-то отталкиваюшее.
Словом, предполагалось, что книга "Кирпичи" должна раскрыть некоторые черты характера, или хотя бы смотивировать к чему-то. Такого эффекта не ощутил. Видимо не для хикк написано. Не удаётся ассоциировать себя с главным героем.
И в правду, главный герой - нормис. В том смысле, что он не маргинал. Он уже встроен в общество.
К чему это я? Чтобы перестать быть славным парнем, для начала нужно им стать. Сложно уловить, какие именно эмоции он испытывает, когда влюбляется в девушек, когда помогает всем подряд на работе, когда хамит охраннику. Мне ни разу не приходило в голову дать кому-то деньги, ещё и такие большие, да к тому же заняв их в банке. Даже если очень надо, всегда можно сказать что денег нет (не уточняя, что именно лишних денег нет). Возможно, мне ещё предстоит испытать подобный опыт, ведь я ни разу в жизни не работал. Не тая греха, признаюсь - я не люблю работать. Именно поэтому и решил оформить вкат в системное администрирование.
Оффициальное трудоустройство и вовсе считаю вещью вторичной: если кто-то даёт щедрое жалование, я уверен - он заработал на мне гораздо больше. Большие деньги так не заработать, оффициальное трудоустройство - иллюзия стабильности. Большие деньги не обходятся без элемента шарлатанства, к чему я совершенно не склонен. Так, что даже став славным парнем, стоит ли переставать им быть? Мораль книги больше подходит для карьеристов, которые рвут и мечут. Мирный двачер вряд-ли извлечёт из этого толк.
Что касается армейского рукопашного боя, тема зацепила, ведь занятие довольно интересное. Занимался таковым (или подобным) непродолжительное время. Изначально было желание найти какие-нибудь восточные единоборства, проникнуться философией, но рядом с моим университетом находился только небольшой зал с рукопашным боем. Там тренеровались скуфоватые футбольные фанаты и заводская молодёжь - это меня отпугнуло. Других вариантов не было, делать нечего, пришлось брать что есть. Как оказалось, люди там довольно добродушны и не похожи на отморозков.
Правда, в отличии от главного героя книги, никаких груш я не бил, и поставили меня сразу же в спарринг, где неизбежно получал пиздюлей первое время. Меня обучали уже в самом бою. Получив мощный удар в поддых, я откисал, а в это время мне подсказывали что нужно делать чтобы такой удар не допустить. Конечно, было правило "добивать до конца", но большинство соперников, видя во мне неопытного бойца, этим правилом не руководствовались. Неплохая методика. Зачем все эти груши, когда на практике всё гораздо доходчивее? И мотивация прямая - никто же не любит терпеть боль.
Спустя некоторое время, у меня все же получилось немного "махаться" и даже уворачиваться от ударов. Это меня радовало, хоть и ногами работать не умел, от чего получал ехидные подсечки. Я понял, что именно смешанные единоборства - это то, что было нужно. Как правильно заметил автор книги, в них используются наиболее эффективные приёмы. Чувствуешь будто бы играешь в слэшер с хорошо продуманной механникой.
Время близилось к сесии. Совмещать спорт и учёбу не получалось - после каждой тренеровки совсем не хотелось браться за книги. Я выбрал учёбу. Теоретически, совмещать спорт и учёбу было возможно, ведь там в зале тренеровалось пара оброзованных спортсменов, но я видимо не настолько крут и своеволен. Кроме того, я не люблю когда меня "гоняют", а без дисциплины результата не достичь. В любых спортивных секциях такие правила, нужно строится по команде, и казалось бы это вполне разумно, но мой внутренний пердак от таких команд слегка подгорает.
Из минусов книги, отмечу, что в ней не хватает драмы. Проблемы с законом могли бы добавить экшена в историю главного героя. Главный герой не теряет здоровья, сколько бы не дрался. Все описанные проблемы - чисто финансовые. Потреять деньги не так жалко, как потерять здоровье или иметь шанс сесть в тюрьму. Поэтому и выходит как-то "плосковато", не сильно трагично, но и не сильно весело. Даже социальной драмы нет никакой. Это не Пелевин, не Достоевский и даже не Паланик. Хотя даже в этом спокойствии что-то есть, может так и было задумано.
Рассказ неплохой, мне понравился. Эдакое оффисное приключение. Посоветовали мне его в треде, где обсуждали совсем другую книгу под названием "Хватит быть славным парнем!". Я её не читал. Название интригует, но есть в нём что-то отталкиваюшее.
Словом, предполагалось, что книга "Кирпичи" должна раскрыть некоторые черты характера, или хотя бы смотивировать к чему-то. Такого эффекта не ощутил. Видимо не для хикк написано. Не удаётся ассоциировать себя с главным героем.
И в правду, главный герой - нормис. В том смысле, что он не маргинал. Он уже встроен в общество.
К чему это я? Чтобы перестать быть славным парнем, для начала нужно им стать. Сложно уловить, какие именно эмоции он испытывает, когда влюбляется в девушек, когда помогает всем подряд на работе, когда хамит охраннику. Мне ни разу не приходило в голову дать кому-то деньги, ещё и такие большие, да к тому же заняв их в банке. Даже если очень надо, всегда можно сказать что денег нет (не уточняя, что именно лишних денег нет). Возможно, мне ещё предстоит испытать подобный опыт, ведь я ни разу в жизни не работал. Не тая греха, признаюсь - я не люблю работать. Именно поэтому и решил оформить вкат в системное администрирование.
Оффициальное трудоустройство и вовсе считаю вещью вторичной: если кто-то даёт щедрое жалование, я уверен - он заработал на мне гораздо больше. Большие деньги так не заработать, оффициальное трудоустройство - иллюзия стабильности. Большие деньги не обходятся без элемента шарлатанства, к чему я совершенно не склонен. Так, что даже став славным парнем, стоит ли переставать им быть? Мораль книги больше подходит для карьеристов, которые рвут и мечут. Мирный двачер вряд-ли извлечёт из этого толк.
Что касается армейского рукопашного боя, тема зацепила, ведь занятие довольно интересное. Занимался таковым (или подобным) непродолжительное время. Изначально было желание найти какие-нибудь восточные единоборства, проникнуться философией, но рядом с моим университетом находился только небольшой зал с рукопашным боем. Там тренеровались скуфоватые футбольные фанаты и заводская молодёжь - это меня отпугнуло. Других вариантов не было, делать нечего, пришлось брать что есть. Как оказалось, люди там довольно добродушны и не похожи на отморозков.
Правда, в отличии от главного героя книги, никаких груш я не бил, и поставили меня сразу же в спарринг, где неизбежно получал пиздюлей первое время. Меня обучали уже в самом бою. Получив мощный удар в поддых, я откисал, а в это время мне подсказывали что нужно делать чтобы такой удар не допустить. Конечно, было правило "добивать до конца", но большинство соперников, видя во мне неопытного бойца, этим правилом не руководствовались. Неплохая методика. Зачем все эти груши, когда на практике всё гораздо доходчивее? И мотивация прямая - никто же не любит терпеть боль.
Спустя некоторое время, у меня все же получилось немного "махаться" и даже уворачиваться от ударов. Это меня радовало, хоть и ногами работать не умел, от чего получал ехидные подсечки. Я понял, что именно смешанные единоборства - это то, что было нужно. Как правильно заметил автор книги, в них используются наиболее эффективные приёмы. Чувствуешь будто бы играешь в слэшер с хорошо продуманной механникой.
Время близилось к сесии. Совмещать спорт и учёбу не получалось - после каждой тренеровки совсем не хотелось браться за книги. Я выбрал учёбу. Теоретически, совмещать спорт и учёбу было возможно, ведь там в зале тренеровалось пара оброзованных спортсменов, но я видимо не настолько крут и своеволен. Кроме того, я не люблю когда меня "гоняют", а без дисциплины результата не достичь. В любых спортивных секциях такие правила, нужно строится по команде, и казалось бы это вполне разумно, но мой внутренний пердак от таких команд слегка подгорает.
Из минусов книги, отмечу, что в ней не хватает драмы. Проблемы с законом могли бы добавить экшена в историю главного героя. Главный герой не теряет здоровья, сколько бы не дрался. Все описанные проблемы - чисто финансовые. Потреять деньги не так жалко, как потерять здоровье или иметь шанс сесть в тюрьму. Поэтому и выходит как-то "плосковато", не сильно трагично, но и не сильно весело. Даже социальной драмы нет никакой. Это не Пелевин, не Достоевский и даже не Паланик. Хотя даже в этом спокойствии что-то есть, может так и было задумано.
Перепутал издания. В издании 2021 года вторым томом сразу же идут "системы и сети". Небольшое облегчение.
Ассемблер изучать сложно. Текст доходчивый, всё понятно, но практики изрядно не хватает. Лень копаться. Хочется доизучать основы, и перейти уже к чему-то конкретному, чем можно себе на хлеб заработать. Идея в следующем: брать интересующую вакансию, и смотреть требования. Затем находить технологии, соответствующие этим требованиям, и изучать как их используют, эмулировать работу над ними. Тот же пакет CISCO, например.
Последние главы, как журнал для общего ознакомления, просто взять на заметку - "вот такие возможности у программиста есть, и чуть что, можно в них углубится". Животрепещащие темы там всё же раскрыты. "Системный вызов" - слово которое сохраняло интригу до самой последней страницы. На самом деле, я уже догадывался, о чем-то подобном. На сайте Столярова было упомянуто, что в windows эти самые вызовы реализовать сложновато, а значит "системный вызов" - это что-то связанное с выходом из программы. Судя по всему, операционная система содержит в себе особый набор алгоритмов, которые начинаются с прерывания, а затем сами по себе выполняют какую-то задачу в привелегированом режиме. Стстемный вызов, принимает в качестве аргументов области данных, описанные в пользовательском режиме. Навредить соседним адресным пространствам не получится.
Что такое "поток", "процесс", я так и не понял.
По всей видимости, поток - это и есть выполнение команд процессором, одну за другой. Стало быть "многопоточность", это способность создавать внутренние прерывания, для переключения между разными адресными пространствами.
Процесс, он же "задача", как мне кажется, это выполнение цепочки каких-то действий, в целом. Быть может, эти действия даже не связаны с центральным процессором. Например, запись данных на диск - процесс, хоть CPU в этот момент лишь ожидает ответа от контроллера. В таком случае, по какому принципу, действия "объединаются в процесс"?
Ассемблер изучать сложно. Текст доходчивый, всё понятно, но практики изрядно не хватает. Лень копаться. Хочется доизучать основы, и перейти уже к чему-то конкретному, чем можно себе на хлеб заработать. Идея в следующем: брать интересующую вакансию, и смотреть требования. Затем находить технологии, соответствующие этим требованиям, и изучать как их используют, эмулировать работу над ними. Тот же пакет CISCO, например.
Последние главы, как журнал для общего ознакомления, просто взять на заметку - "вот такие возможности у программиста есть, и чуть что, можно в них углубится". Животрепещащие темы там всё же раскрыты. "Системный вызов" - слово которое сохраняло интригу до самой последней страницы. На самом деле, я уже догадывался, о чем-то подобном. На сайте Столярова было упомянуто, что в windows эти самые вызовы реализовать сложновато, а значит "системный вызов" - это что-то связанное с выходом из программы. Судя по всему, операционная система содержит в себе особый набор алгоритмов, которые начинаются с прерывания, а затем сами по себе выполняют какую-то задачу в привелегированом режиме. Стстемный вызов, принимает в качестве аргументов области данных, описанные в пользовательском режиме. Навредить соседним адресным пространствам не получится.
Что такое "поток", "процесс", я так и не понял.
По всей видимости, поток - это и есть выполнение команд процессором, одну за другой. Стало быть "многопоточность", это способность создавать внутренние прерывания, для переключения между разными адресными пространствами.
Процесс, он же "задача", как мне кажется, это выполнение цепочки каких-то действий, в целом. Быть может, эти действия даже не связаны с центральным процессором. Например, запись данных на диск - процесс, хоть CPU в этот момент лишь ожидает ответа от контроллера. В таком случае, по какому принципу, действия "объединаются в процесс"?
Весна. Настало время ПРЕВОЗМОГАТЬ.
Сторчаться и траповать - обязательно! Но не сегодня. Надо попробовать стать качком 90 кг сухих мышц хотя бы раз, в жизни.
Из всего прочитанного мусора в интернете, составил несколько мифов, которые мне интересно начать поддерживать.
1)Режим сна. Его нужно соблюдать. Во время сна, якобы вырабатывается окситоцин. Уже и не помню, зачем он нужен, но воспоминания будто бы это что-то полезное. Настолько я понял, нужно ложиться от 9 до 12, и вставать от 7 до 10, тогда сон уладывается в нужное время.
2)Надо настаивать на своём, хотя бы в мелочах. Читал, что это полезно для мозга. Принцип действия я уже забыл, но суть в том, что если быть нерешительным, то какая-то часть мозга будет стагнировать, и это повлияет на всё тело. Помню, в том тексте ещё был пример, со стариком который буквально не мог шагнуть, хотя ноги у него были вполне себе работоспособными. Такого старика подтолкнули - и он пошёл. У него страдала как раз часть мозга отвечающая за принятия решений - он не мог заставить ноги двигаться, без чужой помощи. Впринципе, я иногда себя сам ловлю на мыли, что не могу встать со стула, и речь даже не про мышцы. Просто сел посидеть - а встать не могу. Только когда сильно хочется в туалет, я соизволяю поднятся и пойти. Это, конечно, не паталогия, но профилактика лишней не будет.
3) После тренеровки нужно побольше питаться. Обычно я ничего не ел после тренеровок, так как аппетита не ощущал. Прочитал где-то, что нужно наоборот, после тренеровок наедаться до отвала, якобы в этот момент, организм обрабатывает всю пищу с наибольшим КПД. До тренеровок следует есть преимущественно углеводы, чтобы была энергия к поднятию тяжестей.
4)Перестать пить кофе и чай после приёма пищи. Сами по себе они не вредны, но вымывают из организма железо, кальций и другие микроэлементы. Помнится, мне как-то давно диагностировали недостаток железа, прописали бады какие-то. Очевидно, что пить я их не стал, и на советы врача положил болт ещё находясь в его кабинете. Ногти у меня всегда были какими-то гибкими, как из пластмассы. Надо попробовать пить только водичку, как в большинстве армий ЕС.
Спортсмены курят, пьют и сидят до поздна в компьютерных игрушках. Так, что строго придерживаться правил не обязательно. С каких-то предпосылок надо начинать в любом случае, поэтому лучше хоть какие-то мифы на вооружение, чтоб потом прийти к сути.
Томик по азам прочитал от корочки до корочки. Можно переходить к сетям. Надеюсь узнать, кто же такие эти ваши "протоколы".
Сторчаться и траповать - обязательно! Но не сегодня. Надо попробовать стать качком 90 кг сухих мышц хотя бы раз, в жизни.
Из всего прочитанного мусора в интернете, составил несколько мифов, которые мне интересно начать поддерживать.
1)Режим сна. Его нужно соблюдать. Во время сна, якобы вырабатывается окситоцин. Уже и не помню, зачем он нужен, но воспоминания будто бы это что-то полезное. Настолько я понял, нужно ложиться от 9 до 12, и вставать от 7 до 10, тогда сон уладывается в нужное время.
2)Надо настаивать на своём, хотя бы в мелочах. Читал, что это полезно для мозга. Принцип действия я уже забыл, но суть в том, что если быть нерешительным, то какая-то часть мозга будет стагнировать, и это повлияет на всё тело. Помню, в том тексте ещё был пример, со стариком который буквально не мог шагнуть, хотя ноги у него были вполне себе работоспособными. Такого старика подтолкнули - и он пошёл. У него страдала как раз часть мозга отвечающая за принятия решений - он не мог заставить ноги двигаться, без чужой помощи. Впринципе, я иногда себя сам ловлю на мыли, что не могу встать со стула, и речь даже не про мышцы. Просто сел посидеть - а встать не могу. Только когда сильно хочется в туалет, я соизволяю поднятся и пойти. Это, конечно, не паталогия, но профилактика лишней не будет.
3) После тренеровки нужно побольше питаться. Обычно я ничего не ел после тренеровок, так как аппетита не ощущал. Прочитал где-то, что нужно наоборот, после тренеровок наедаться до отвала, якобы в этот момент, организм обрабатывает всю пищу с наибольшим КПД. До тренеровок следует есть преимущественно углеводы, чтобы была энергия к поднятию тяжестей.
4)Перестать пить кофе и чай после приёма пищи. Сами по себе они не вредны, но вымывают из организма железо, кальций и другие микроэлементы. Помнится, мне как-то давно диагностировали недостаток железа, прописали бады какие-то. Очевидно, что пить я их не стал, и на советы врача положил болт ещё находясь в его кабинете. Ногти у меня всегда были какими-то гибкими, как из пластмассы. Надо попробовать пить только водичку, как в большинстве армий ЕС.
Спортсмены курят, пьют и сидят до поздна в компьютерных игрушках. Так, что строго придерживаться правил не обязательно. С каких-то предпосылок надо начинать в любом случае, поэтому лучше хоть какие-то мифы на вооружение, чтоб потом прийти к сути.
Томик по азам прочитал от корочки до корочки. Можно переходить к сетям. Надеюсь узнать, кто же такие эти ваши "протоколы".
Третий миф вполне работает. После тренеровок действительно можно много много питаться. Особого аппетита нет, но способность съесть побольше ощущается.
Завалился к друзьям в /fiz/. Никаких точных советов не прочитал. Только лишь "питайся побольше" и "поднимай большие веса" и конечно же, всё это не без мемов про Абзаца. Сколько нужно жать я так и не понял, затем просто взял упражнения из FAQ: жим лёжа, становая тяга, присяд. Делаю их по три подхода, до того веса, пока не нарушится техника. Максимально поднятый вес/количество повторений с этим весом записываю в блокнот. После, выполняю упражнения с гантельками и калистенику, просто ради того, чтобы потратить оставшиеся силы. Уж не знаю насколько такие тренеровки эффективны, но пока не надоест оставлю всё как есть.
Немаловажный пункт FAQ, состоит в том, что необходимо иметь азарт повышения показателей. Для этого спортсмены устраивают соревнования. У меня же соревнований нет, поэтому потренеруюсь в режиме синглплеера: цель - обогнать результат предыдущей тренеровки, ну или хотя бы поднять не меньше чем в прошлой тренеровке (в случае если поднять больше - невозможно).
Мне пришла в голову мысль:
"А что если записывать все возможные параметры тренеровок, составлять из них выборку, и уже методом статистического анализа выявлять зависимости. По этим зависимостям можно выдвинуть гипотезы, проверить их, и основать теорию эффективных тренеровок". Если уж мне пришла эта мысль в голову, то наверняка такое не просто существует, а существует в полном обьёме и со всеми подробностями физиологии. Будет желание - надо обязательно нагуглить что-то подобное.
Устроил драку с бетонной стеной.
Итог: победила стена. Болят костяшки на руках. Драться без перчаток - совсем инное дело, нежели драться в онных. Если уж устраивать нападение на ненавистные бетонные коробки, то лучше бить тремя последними костяшками - они находятся на одной линии, импульс будет распределён на них равномерно т.е. поделён на три. Если бить второй (выпирающей) костяшкой, то вся величина импульса приходится на одну неё.
Завалился к друзьям в /fiz/. Никаких точных советов не прочитал. Только лишь "питайся побольше" и "поднимай большие веса" и конечно же, всё это не без мемов про Абзаца. Сколько нужно жать я так и не понял, затем просто взял упражнения из FAQ: жим лёжа, становая тяга, присяд. Делаю их по три подхода, до того веса, пока не нарушится техника. Максимально поднятый вес/количество повторений с этим весом записываю в блокнот. После, выполняю упражнения с гантельками и калистенику, просто ради того, чтобы потратить оставшиеся силы. Уж не знаю насколько такие тренеровки эффективны, но пока не надоест оставлю всё как есть.
Немаловажный пункт FAQ, состоит в том, что необходимо иметь азарт повышения показателей. Для этого спортсмены устраивают соревнования. У меня же соревнований нет, поэтому потренеруюсь в режиме синглплеера: цель - обогнать результат предыдущей тренеровки, ну или хотя бы поднять не меньше чем в прошлой тренеровке (в случае если поднять больше - невозможно).
Мне пришла в голову мысль:
"А что если записывать все возможные параметры тренеровок, составлять из них выборку, и уже методом статистического анализа выявлять зависимости. По этим зависимостям можно выдвинуть гипотезы, проверить их, и основать теорию эффективных тренеровок". Если уж мне пришла эта мысль в голову, то наверняка такое не просто существует, а существует в полном обьёме и со всеми подробностями физиологии. Будет желание - надо обязательно нагуглить что-то подобное.
Устроил драку с бетонной стеной.
Итог: победила стена. Болят костяшки на руках. Драться без перчаток - совсем инное дело, нежели драться в онных. Если уж устраивать нападение на ненавистные бетонные коробки, то лучше бить тремя последними костяшками - они находятся на одной линии, импульс будет распределён на них равномерно т.е. поделён на три. Если бить второй (выпирающей) костяшкой, то вся величина импульса приходится на одну неё.
Весной все кучкуются в группы, словно банды из GTA San Andres.
По дороге встретил белокурого немного всратого парня. Шёл он в сопровождении двух анимешниц в чулочках: одна жирная как парасёнок, другая наоборот - тощая и горбатая как смерть. Это мило. Напоминает первый курс университета, такой наивный и ламповый. Помниться я точно также как и сейчас шёл по дороге под лучи солнца. Староста попросил меня скинуть денег на подарок к 8 марта - тысячу рублей. "Денег у меня сейчас нет" - сказал я ему тогда, вздохнув. На что, староста мне предложил отдать ему в качестве денег мой, совершенно новый SSD диск. Я согласился.
...
По пришествию домой, я понял что что-то не так. На полке с электронникой "на продажу" у меня не было SSD диска, был только б/у HDD диск, который и отдавать то как-то позорно. Отдать в качестве денег б/у товар - это всё равно, что предложить девушке в ресторане один бургер на двоих. Вообще не давать денег - не вариант, всё-таки хочется порадовать девушек. Я начал думать, как же мне заработать денег. Ничего лучше, чем продавать личные вещи я не придумал. Выставил на Авито: HDD накопитель, старый дедовский телевизор на распайку, механические наручные часы и подшипник диаметром 40 мм.
...
На авито никто так ничего и не купил. Мне написал лишь какой-то странный мужик, предлагал обменять HDD на стаю собак. Ещё написали по ручным часам, но это оказался очевидный фишинг. Я даже посидел на этом фейко-сайте, чтобы посмотреть как это работает. Ничего необычного. По-классике, просят ввести номер карты и CVV код.
"Я оплатил" - написал я мошеннику. Хотелось посмотреть, как он отреагирует.
"Что оплатил, еблан!? Ты денег за товар получить должен был" - написал он в ответ, и закинул меня в ЧС. Действительно. Сам себя с мысли сбил, что аж случайно выдал.
...
Близилось восьмое марта. Набравшись уверенности, я пошёл к старосте.
-Вот, держи, тут всё до единной копейки - сказал я ему.
-Что это? - Ответил он, посмотрев на меня как на придурка.
-Вот ЭЛТ-монитор, я посчитал, в нём конденсаторов ровно на 200 рублей, плюс цветных металлов ещё на 30. Вот консервные банки...пустые.. это где-то на 100 рублей...
-Стой, ты прикалываешься? Ты совсем что-ли еблан?
Такой грубости от старосты я не ожидал. Я хотел помочь устроить достойный праздник, а он не соизволил принять мой депозит.
-Ты меня предал - заявил ему я. Он покрутил палец у виска, и ушёл в общежитие.
...
Что забавно, этот староста умер на четвёртом курсе. Выпал из окна. "Самоубийство" - читал я в новостях, однако одногруппники рассказывали мне, что вероятно его кто-то "подтолкнул". По слухам, староста занимался закладками, и похоже, что кого-то кинул. Это будет ему уроком, за его высокомерие. А.. нет.. похоже, что не будет...
По дороге встретил белокурого немного всратого парня. Шёл он в сопровождении двух анимешниц в чулочках: одна жирная как парасёнок, другая наоборот - тощая и горбатая как смерть. Это мило. Напоминает первый курс университета, такой наивный и ламповый. Помниться я точно также как и сейчас шёл по дороге под лучи солнца. Староста попросил меня скинуть денег на подарок к 8 марта - тысячу рублей. "Денег у меня сейчас нет" - сказал я ему тогда, вздохнув. На что, староста мне предложил отдать ему в качестве денег мой, совершенно новый SSD диск. Я согласился.
...
По пришествию домой, я понял что что-то не так. На полке с электронникой "на продажу" у меня не было SSD диска, был только б/у HDD диск, который и отдавать то как-то позорно. Отдать в качестве денег б/у товар - это всё равно, что предложить девушке в ресторане один бургер на двоих. Вообще не давать денег - не вариант, всё-таки хочется порадовать девушек. Я начал думать, как же мне заработать денег. Ничего лучше, чем продавать личные вещи я не придумал. Выставил на Авито: HDD накопитель, старый дедовский телевизор на распайку, механические наручные часы и подшипник диаметром 40 мм.
...
На авито никто так ничего и не купил. Мне написал лишь какой-то странный мужик, предлагал обменять HDD на стаю собак. Ещё написали по ручным часам, но это оказался очевидный фишинг. Я даже посидел на этом фейко-сайте, чтобы посмотреть как это работает. Ничего необычного. По-классике, просят ввести номер карты и CVV код.
"Я оплатил" - написал я мошеннику. Хотелось посмотреть, как он отреагирует.
"Что оплатил, еблан!? Ты денег за товар получить должен был" - написал он в ответ, и закинул меня в ЧС. Действительно. Сам себя с мысли сбил, что аж случайно выдал.
...
Близилось восьмое марта. Набравшись уверенности, я пошёл к старосте.
-Вот, держи, тут всё до единной копейки - сказал я ему.
-Что это? - Ответил он, посмотрев на меня как на придурка.
-Вот ЭЛТ-монитор, я посчитал, в нём конденсаторов ровно на 200 рублей, плюс цветных металлов ещё на 30. Вот консервные банки...пустые.. это где-то на 100 рублей...
-Стой, ты прикалываешься? Ты совсем что-ли еблан?
Такой грубости от старосты я не ожидал. Я хотел помочь устроить достойный праздник, а он не соизволил принять мой депозит.
-Ты меня предал - заявил ему я. Он покрутил палец у виска, и ушёл в общежитие.
...
Что забавно, этот староста умер на четвёртом курсе. Выпал из окна. "Самоубийство" - читал я в новостях, однако одногруппники рассказывали мне, что вероятно его кто-то "подтолкнул". По слухам, староста занимался закладками, и похоже, что кого-то кинул. Это будет ему уроком, за его высокомерие. А.. нет.. похоже, что не будет...
> цель - обогнать результат предыдущей тренеровки.
Что значит "обогнать результат"? Допустим, на первой тренеровке я поднял 4 раза по 65 кг, а на второй 1 раз, но зато по 70 кг. Это наталкивает на мысль, что между повторениями и весом, должна быть некая зависимость. Для того, чтобы хоть как-то немного тренероваться, необходимо выявить величины, характеризующие тренеровку. В противном случае становится непонятно: "а к чему собственно следует стремится". Всю физиологию оставляю за скобками. То есть, беру за данность, что базовые упражнения + калистеника воздействуют на мышцы в достаточной мере, чтобы их развить.
Существуют следующие величины:
• Количество подходов.
• Количество повторений в подходе.
• Темп подхода.
• Поднимаемый вес.
Количество повторений и темп регламентированны.
Согласно популярной теории, выделяют сеты низкоповторные, среднеповторные и высокоповторные:
• Сеты в 1—5 повторений в первую очередь развивают силу, оказывают большее влияние на размер мышц и не влияют на выносливость;
• Сеты в 6—12 повторений позволяют сбалансировать силу, размер мышц и выносливость;
• Сеты 13—20 повторений развивают выносливость, с некоторым увеличением размера мышц и ограниченно влияют на силу;
• Сеты 20 и более повторений выполняются в аэробных упражнениях, обычно в скоростном режиме, в котором последовательно удаляется молочная кислота, дающая эффект жжения.
Выделяют следующие темпы повторений:
• Быстрый — в нижней точке отдых отсутствует;
• Средний — пауза около 1 секунды;
• Медленный — отдых между повторениями более 1 секунды;
• Очень медленный — отдых между повторениями 10—20 секунд.
Задача первичного вката: изучить основные величины, характеризующие силовые тренеровки, и выявить их зависимости и связи.
Исходить, лучше, наверное, из данных своих тренеровок, поскольку в статьях и книгах могут быть измерены показатели каких-нибудь чемпионов-олимпийцев. Их значения могут не соответствовать моим, ведь в при силовых тренеровках также развивается прочность сухожилий и связок, изменяется нейромышечная связь и скорость обмена веществ.
При прочтении статей и книг, следеут выделять принципы, а цифры уже корректировать под себя.
Увеличивать нагрузки и, соответственно, работу мышц можно разными способами, например:
• Поднимать больший вес, чем на предыдущих тренировках или циклах, затрачивая больше усилий;
• Увеличивать количество повторов при неизменном весе снаряда и количестве сетов;
увеличивать количество подходов при неизменном весе снаряда и количестве повторов;
• Увеличивать количество выполняемых упражнений на мышцу или группу мышц;
• Уменьшать паузу между подходами, однако, в большинстве случаев, как установили ученые, это уменьшает прогрессию и вызывает скорее обратный эффект, так как уставшие мышцы не успевают налиться кровью, избавиться от продуктов распада и восстановиться за несколько секунд.
Последний пункт меня особенно заинтересовал. Во время тренеровок сложилось ощущение, будто бы есть "оптимальное время паузы", ниже которого не успеваешь отдохнуть, выше - слишком расслабляешься.
Показатели тренеровок:
• Интенсивность,
• Объём
• Частота.
Интенсивность относится к количеству работы, необходимой для достижения цели и пропорциональности мышечной массы и поднимаемых весов.
Объём относится к количеству работавших мышц, упражнений, подходов и повторений в течение одной тренировки.
Частота означает количество тренировок, проводимых в неделю.
Для новичков не существует различия между разными моделями периодизации. Как я понял, это связано с тем, что при тренеровках дольше 1-2 лет, спортсмены упираются в некоторый "потолок" из показателей. И было созданно несколько методов для решения этих кочко-проблем. Пока, что это можно не учитывать, однако стоит иметь ввиду, что и такое тоже существует, и немного адаптироваться в эту сторону.
> цель - обогнать результат предыдущей тренеровки.
Можно поступить и проще: Засчитывать "победу" по совокупности условий. Если делать по три подхода, увеличивая вес на каждом из них, вплоть до 1ПМ, то в каком-то из этих подходов может увеличится количество повторений/вес, при неизменных показателях остальных подходов. Тогда победа будет засчитыватся, если хотя бы в одном из подходов было увеличино количество повторений или вес, относительно того же по счёту подхода, что и в предыдущей неделе.
Иллюстрация:
день 0: [60кг × 5; 65кг × 3; 70кг × 1]
день 1: [60кг × 5; 65кг × 3; 70кг × 2] - победа по весу.
день 2: [60кг × 5; 65кг × 5; 70кг × 1] - победа по повторениям.
Создать выборку не так просто. Одну из тренеровок я посвятил большому количеству подходов, с целью собрать достаточно данных. Идея - так себе. За всю тренеровку я не смог поднять максимальный вес, ещё и изрядно устал.
Рекомендуют поднимать веса от 75% до 95% от 1ПМ, по три подхода, до тех пор, пока количество повторений выйдет за 10.
Прочитал, что "новички" - это все те, кто не может уверенно выполнять упражнения 150% от своего веса. До этого порога можно тренероваться свободно, не задумываясь о периодизации.
Надо спиздить калькулятор из Яндекса. Я про тот, который появляется в поле "быстрый ответ", когда набираешь в поисковике "калькулятор".
Просто сохранить Html страничку не выйдет, калькулятор работать не будет.
Тем не менее, при отключенном интернете, калькулятор считает числа исправно. Следовательно, все вычисления происходят на стороне клиента. Выцепить бы те скрипты, что отвечают за работу калькулятора. Пока что нашёл только скрипты для сбора метрик, и персонализации рекламы.
Нагуглил такой язык программирования, как Node.js. Знать не знаю его особенностей, для меня это Java Script на котором, судя по всему, можно скомпилировать бинарник. В него, наверное, и нужно поместить спизженые скрипты, чтобы получить Standalone версию калькулятора.
Первые достижение в тягании железок: прибавил в весе 5 кг. Столько же и увеличился 1ПМ. На первый взгляд, зависимость между весами и повторениями - линейная, но не на каждой тренеровке. Как будто бы прогресс идёт двумя "периодами":
1.На первом периоде хорошо поддаётся лёгкий вес, но поднять максимальный вес, без нарушения техники - невозможно. Чтобы обогнать результат хотя-бы "по повторениям", выполняется дополнительный, четвёртый подход. Слышал, что его называют "первый подход последним". Звучит странно. Поясню: это дополнительный подход, выполняется с тем же весом, что и первый, но с большим количеством повторений. Эффект заключается в следующем: после поднятия тяжёлого веса, лёгкий вес кажется очень простым. Сделать больше повторений с таким весом не составляет труда. Так можно победить хотя бы в "повторениях". Кратко, этот период можно описать схемой:
| 0,8×4 | 0,9×3 | 1,0×0 | 0,8×7 |
*значения веса в относительных единицах
Тут видно, что на последнем подходе, как Папай под шпинатом. Почти в два раза больше повторений чем в первом, хотя вес тот же.
В процессе таких тренеровок, максимальный вес даёт слабину. Представляется возможным поднять 1ПМ один раз, с правильной техникой. Так заканчивается первый период.
2.Во втором периоде уже не составляет труда поднять максимальный вес и два, и три раза. Дополнительный подход, теряет смысл, ведь количество повторений на лёгком весе превышает семь раз.
|0,8×7+| 0,9×5 | 1,0×2 |
На последующих тренеровках, повторения с максимальным весом увеличиваются в количестве. Когда число повторений превышает 5, возникает желание повысить и сам максимальный вес. Увеличив вес всего на 5 кг, штанга становится неподъёмной, словно гружёный самосвал. Поднять её получится едва ли один раз, ещё и с нарушением техники. На этом моменте, происходит переход в первый "период", но уже с новыми весами.
Буду наблюдать и дальше. Может так и получится выявить закономерность.
Просто сохранить Html страничку не выйдет, калькулятор работать не будет.
Тем не менее, при отключенном интернете, калькулятор считает числа исправно. Следовательно, все вычисления происходят на стороне клиента. Выцепить бы те скрипты, что отвечают за работу калькулятора. Пока что нашёл только скрипты для сбора метрик, и персонализации рекламы.
Нагуглил такой язык программирования, как Node.js. Знать не знаю его особенностей, для меня это Java Script на котором, судя по всему, можно скомпилировать бинарник. В него, наверное, и нужно поместить спизженые скрипты, чтобы получить Standalone версию калькулятора.
Первые достижение в тягании железок: прибавил в весе 5 кг. Столько же и увеличился 1ПМ. На первый взгляд, зависимость между весами и повторениями - линейная, но не на каждой тренеровке. Как будто бы прогресс идёт двумя "периодами":
1.На первом периоде хорошо поддаётся лёгкий вес, но поднять максимальный вес, без нарушения техники - невозможно. Чтобы обогнать результат хотя-бы "по повторениям", выполняется дополнительный, четвёртый подход. Слышал, что его называют "первый подход последним". Звучит странно. Поясню: это дополнительный подход, выполняется с тем же весом, что и первый, но с большим количеством повторений. Эффект заключается в следующем: после поднятия тяжёлого веса, лёгкий вес кажется очень простым. Сделать больше повторений с таким весом не составляет труда. Так можно победить хотя бы в "повторениях". Кратко, этот период можно описать схемой:
| 0,8×4 | 0,9×3 | 1,0×0 | 0,8×7 |
*значения веса в относительных единицах
Тут видно, что на последнем подходе, как Папай под шпинатом. Почти в два раза больше повторений чем в первом, хотя вес тот же.
В процессе таких тренеровок, максимальный вес даёт слабину. Представляется возможным поднять 1ПМ один раз, с правильной техникой. Так заканчивается первый период.
2.Во втором периоде уже не составляет труда поднять максимальный вес и два, и три раза. Дополнительный подход, теряет смысл, ведь количество повторений на лёгком весе превышает семь раз.
|0,8×7+| 0,9×5 | 1,0×2 |
На последующих тренеровках, повторения с максимальным весом увеличиваются в количестве. Когда число повторений превышает 5, возникает желание повысить и сам максимальный вес. Увеличив вес всего на 5 кг, штанга становится неподъёмной, словно гружёный самосвал. Поднять её получится едва ли один раз, ещё и с нарушением техники. На этом моменте, происходит переход в первый "период", но уже с новыми весами.
Буду наблюдать и дальше. Может так и получится выявить закономерность.
Что-то я поспешил с калькулятором. Покопался в HTML странице и скриптах. Гуглил каждое слово, что к чему относится. Сделал вывод - скопировать калькулятор пока, что не получится. Нет знаний ни в java script, ни в построении сайтов. В скриптах встречается всё подряд, и какие-то библиотеки БЭМ от яндекса, Facebook react и jQuery, чтобы это не значило.
Но скрипты и элементы страницы сохраню. Может потом дойду до этого, вспомню старую задумку.
Но скрипты и элементы страницы сохраню. Может потом дойду до этого, вспомню старую задумку.
Накидаю набросков, о создании калькулятора. Пока что ничего делать не буду. Да и по-хорошему, надо бы посмотреть код у готовых программ, может лучше бы даже делать "форк". Зачем самому что-то придумывать? Тем более, что я математику совсем не знаю.
В программу "калькулятор" можно ввести следующие данные:
А)Само выражение. Оно представляет из себя набор ascii символов вплоть, до ситуации "конец файла".
Б)Выбор правил оформления и правил. Несколько переменных типа Boolean, которые задают вспомогательные режимы работы калькулятора. Например:
-радианы/градусы
-разделять десятичную часть вывода символом "," или "."
-выводить в 0,001 или 10-3 (или может даже: 10е-3)
Калькулятор может дать следующие результаты:
0)Число в заданном формате. На этот вывод должно хватить одной переменной. Необходимо задатся пределами "адекватного результата", для этого стоит взять самую маленькую и самую большую величину, изспользуемую в науке.
1)Ошибка о недопустимой комбинации символов во вводе.
2.1-2.3)"+-Бесконечность" или "Нуль" или "NaN". Если в выражении делят на нуль, или вводят/получают числа сверх "адекватных", то рассуждение стоит вести как о элементах расширеного множества действительных чисел, и оценивать в первую очередь вообще возможность получения хотя бы недействительного ответа. Так, если встречается 0/0, надо выдать NaN
3)Ошибка недопустимых значений. Проще говоря, арксинус не может принимать аргумент больше единицы.
Основная функция калькулятора заключается в вычислении любых выражений. Выражение представляет из себя упорядоченный набор символов. Должен существовать алгоритм для правильного вычисления арифметических, алгебраических и комплексных выражений.
Исходя из поставленной задачи, калькулятор должен "опознавать" какой вид выражения ему ввели. Если введены только скобки и коммутативные операции, то нужно следовать "арифметическому" алгоритму. Если введены все операции для действительных чисел, то нужно применять более сложный алгоритм. Про комплексные числа можно пока забыть, но их алгоритм должен включатся символами j,i,k,√(-1).
Также вопросом остаётся, а как именно хранить введённые выражения? Я предполагаю, что нужно придумать структуру данных, которая бы хранила в отдельных ячейках операции, скобки и числа. При этом, места в памяти под числа должны быть выделены в соответствии с их разновидностью: если в выражении все числа целые, и встречаются только операции +-, то следует всех их хранить в integer. Если же встретилось хотя бы одно дробное число, то придётся все числа записывать в real. Вообще, даже дробные рациональные числа, с операциями +,-, можно хранить в integer, но даст ли это преимущества? Ведь тогда нужно сделать целый алгоритм, чтобы их правильно сосчитать. Да и вообще, вопрос хранения чисел требуется раскрыть по-подробнее. Например, почему бы не хранить число pi, как функцию, которая выдаёт значения числа pi, с точностью которая бы обеспечивала минимальную погрешность.
Обязательным свойством калькулятора должна являтся неприхотливость. Калькулятор должен уметь правильно интерпритировать хоть 2×2, хоть 2•2, хоть 2*2, вообще всё что используют в математике: 0,01 это то же, что и 0.01, хоть и 10е-2. Конечно, пользователь должен вводить выражения в адекватной форме, но калькулятор должен воспринимать все возможные варианты написания, если они не вступают в противоречие.
По моим догадкам нужна подрограмма-фильтр, которая бы приводила всё к единному виду.
Также нужна и подрограмма-автоформат, которая бы записывала результат в заданной пользователем форме.
----------------------------------------
Сколько денег нужно, чтобы съебать в Европу, или США? Подумал, а что если вкатится в путешествия?
Деньги копятся, обесцениваются. 400к рубликов скопил, как Плюшкин. Понятия не имею куда их тратить, да и думаю, что рано или поздно всё равно их проебу.
Родители постареют, потребуют опекунство. Очень охото жить ради того, чтобы подтирать сраку старым шизофреникам.
С женщинами длительных отношений лучше не строить - судя по статистике, они все склонны к матипуляциям и разводам. Своё ремесло не откроешь - налоги, воинская повинность, подкупные суды, пресупные элиты. Жильё постоянно то сносят, то новое строят, даже его не вижу смысла покупать.
Совершить перекат? Можно будет оставить всех родных наедине с их проблемами, чтобы не высирались из ниоткуда, когда им вдруг деньги понадобятся. Да и просто хочется что-нибудь интересное сделать. Как вообще люди уезжают из страны? Там же рабочая виза нужна, вид на жительство. И зачем кому бы то ни было принимать иностранцев на работу? В чём профит?
Может политическое убежище по-приколу попробовать попросить? Слышал есть способы перебраться через границу незаконно, а потом пойти в миграционную службу и сесть в местное сизо, где с какой-то вероятностью тебя примут. Вот это звучит интересно. Жизнь бомжа. С одной стороны, тут у меня хотя-бы есть где жить, с другой, это жильё стоит копейки, а друзей и связей совсем нуль. Так, что в РФ я тоже почти бомж, только мне, вероятно, ещё и придётся опекунствовать. Надо бы пораздумывать, какие факты могут служить доказательством дискриминации меня в РФ.
В программу "калькулятор" можно ввести следующие данные:
А)Само выражение. Оно представляет из себя набор ascii символов вплоть, до ситуации "конец файла".
Б)Выбор правил оформления и правил. Несколько переменных типа Boolean, которые задают вспомогательные режимы работы калькулятора. Например:
-радианы/градусы
-разделять десятичную часть вывода символом "," или "."
-выводить в 0,001 или 10-3 (или может даже: 10е-3)
Калькулятор может дать следующие результаты:
0)Число в заданном формате. На этот вывод должно хватить одной переменной. Необходимо задатся пределами "адекватного результата", для этого стоит взять самую маленькую и самую большую величину, изспользуемую в науке.
1)Ошибка о недопустимой комбинации символов во вводе.
2.1-2.3)"+-Бесконечность" или "Нуль" или "NaN". Если в выражении делят на нуль, или вводят/получают числа сверх "адекватных", то рассуждение стоит вести как о элементах расширеного множества действительных чисел, и оценивать в первую очередь вообще возможность получения хотя бы недействительного ответа. Так, если встречается 0/0, надо выдать NaN
3)Ошибка недопустимых значений. Проще говоря, арксинус не может принимать аргумент больше единицы.
Основная функция калькулятора заключается в вычислении любых выражений. Выражение представляет из себя упорядоченный набор символов. Должен существовать алгоритм для правильного вычисления арифметических, алгебраических и комплексных выражений.
Исходя из поставленной задачи, калькулятор должен "опознавать" какой вид выражения ему ввели. Если введены только скобки и коммутативные операции, то нужно следовать "арифметическому" алгоритму. Если введены все операции для действительных чисел, то нужно применять более сложный алгоритм. Про комплексные числа можно пока забыть, но их алгоритм должен включатся символами j,i,k,√(-1).
Также вопросом остаётся, а как именно хранить введённые выражения? Я предполагаю, что нужно придумать структуру данных, которая бы хранила в отдельных ячейках операции, скобки и числа. При этом, места в памяти под числа должны быть выделены в соответствии с их разновидностью: если в выражении все числа целые, и встречаются только операции +-, то следует всех их хранить в integer. Если же встретилось хотя бы одно дробное число, то придётся все числа записывать в real. Вообще, даже дробные рациональные числа, с операциями +,-, можно хранить в integer, но даст ли это преимущества? Ведь тогда нужно сделать целый алгоритм, чтобы их правильно сосчитать. Да и вообще, вопрос хранения чисел требуется раскрыть по-подробнее. Например, почему бы не хранить число pi, как функцию, которая выдаёт значения числа pi, с точностью которая бы обеспечивала минимальную погрешность.
Обязательным свойством калькулятора должна являтся неприхотливость. Калькулятор должен уметь правильно интерпритировать хоть 2×2, хоть 2•2, хоть 2*2, вообще всё что используют в математике: 0,01 это то же, что и 0.01, хоть и 10е-2. Конечно, пользователь должен вводить выражения в адекватной форме, но калькулятор должен воспринимать все возможные варианты написания, если они не вступают в противоречие.
По моим догадкам нужна подрограмма-фильтр, которая бы приводила всё к единному виду.
Также нужна и подрограмма-автоформат, которая бы записывала результат в заданной пользователем форме.
----------------------------------------
Сколько денег нужно, чтобы съебать в Европу, или США? Подумал, а что если вкатится в путешествия?
Деньги копятся, обесцениваются. 400к рубликов скопил, как Плюшкин. Понятия не имею куда их тратить, да и думаю, что рано или поздно всё равно их проебу.
Родители постареют, потребуют опекунство. Очень охото жить ради того, чтобы подтирать сраку старым шизофреникам.
С женщинами длительных отношений лучше не строить - судя по статистике, они все склонны к матипуляциям и разводам. Своё ремесло не откроешь - налоги, воинская повинность, подкупные суды, пресупные элиты. Жильё постоянно то сносят, то новое строят, даже его не вижу смысла покупать.
Совершить перекат? Можно будет оставить всех родных наедине с их проблемами, чтобы не высирались из ниоткуда, когда им вдруг деньги понадобятся. Да и просто хочется что-нибудь интересное сделать. Как вообще люди уезжают из страны? Там же рабочая виза нужна, вид на жительство. И зачем кому бы то ни было принимать иностранцев на работу? В чём профит?
Может политическое убежище по-приколу попробовать попросить? Слышал есть способы перебраться через границу незаконно, а потом пойти в миграционную службу и сесть в местное сизо, где с какой-то вероятностью тебя примут. Вот это звучит интересно. Жизнь бомжа. С одной стороны, тут у меня хотя-бы есть где жить, с другой, это жильё стоит копейки, а друзей и связей совсем нуль. Так, что в РФ я тоже почти бомж, только мне, вероятно, ещё и придётся опекунствовать. Надо бы пораздумывать, какие факты могут служить доказательством дискриминации меня в РФ.
Язык "С", обладает свойством Zero Runtime. Это значит, что он не включает в себя ничего. В то время как паскаль имеет операции ввода-вывода Writeln, Readln, язык С, имеет только необязательную стандартную библиотеку. После такого откровения, пропадает всякое желание писать на ассемблере что-либо, за исключением модулей к С. Язык С заменяет ассемблер. В полной мере низкоуровневый язык.
Забыл поздороваться. Здравствуй, дневник. За год вката в IT, я не создал ни одной программы, и не освоил навыки сисадмина. Но я много чего нового в этой жизни узнал. Например, мне казалось что программровать на С, примерно так же как и на паскале. Я ошибался. В "С" многие вещи используются не по назначению. Например Enum - перечисляемый тип, казалось бы точно такой же как и в Паскале. Но не тут то было! Enum, кроме того используется для создания констант. Для создания констант также используется макрос #define. А вот сам модификатор. const, как константа не используется, и не может использоваться. Ведь это не константа, а переменная, которую нельзя изменять. То есть для переменной const область памяти всё равно будет создана в .bss, просто компилятор запрещает эту переменную изменять.
И это не единственный такой странный случай, при изучении С. В языке С не существует массивов. Однако есть "указатели на массивы". И получается что массивы и не нужны, программисты обходятся указателями на них. Конструкция m[4] эквивалентна 4[m]. Нетрадиционно можнг использовать цикл for. Делают так, чтобы цикл всегда выполняется лишь один раз. Такой цикл часто вставляют в макрос, чтобы тем самым поставить блок кода в "скобки".
Функции, вызываемые прямо в заголовках условных конструкций или циклов - это норма. И многое другое удивительное и гениальное. Правда в учебнике лишь знакомят с "С". Я уверен найдётся ещё пол-дюжины различных заковыристых конструкций.
Из принципиально новых для меня технологий, оказалось что у функции тоже есть адрес. Оно и разумно, ведь функция, как и любая другая часть кода находится в памяти, а значит и на неё можно сделать указатель. Таким образом функцию можно "скармливать" в качестве параметра другой функции, и это называется callback, как-то так.
В последнее время чувствую опустошение. Многие в 20 лет становится специалистами в своей области, а я в 24 провожу остаток лета за изучением первичных компьютерных навыков. Мои интеллектуальные способности скудны, мои физические данные не превосходят большинство. Да и я сам на самом деле ничего не хочу, у меня просто на просто нет "области". Я лишь продолжаю играть в какую-то непонятную игру, которую затеял когда-то в подростковом возрасте.
Чувствую себя педафилом-неудачником, который пытается заманить девочку куклой барби, когда в моде давно уже Хаги Ваги. Да и девочки уже понимают все, и сразу просят кэш за сексуальные услуги.
Хотя в мусорный бак это всё. Раз уж играть придётся, то лучше хотя бы запастись энтузиазмом.
Забыл поздороваться. Здравствуй, дневник. За год вката в IT, я не создал ни одной программы, и не освоил навыки сисадмина. Но я много чего нового в этой жизни узнал. Например, мне казалось что программровать на С, примерно так же как и на паскале. Я ошибался. В "С" многие вещи используются не по назначению. Например Enum - перечисляемый тип, казалось бы точно такой же как и в Паскале. Но не тут то было! Enum, кроме того используется для создания констант. Для создания констант также используется макрос #define. А вот сам модификатор. const, как константа не используется, и не может использоваться. Ведь это не константа, а переменная, которую нельзя изменять. То есть для переменной const область памяти всё равно будет создана в .bss, просто компилятор запрещает эту переменную изменять.
И это не единственный такой странный случай, при изучении С. В языке С не существует массивов. Однако есть "указатели на массивы". И получается что массивы и не нужны, программисты обходятся указателями на них. Конструкция m[4] эквивалентна 4[m]. Нетрадиционно можнг использовать цикл for. Делают так, чтобы цикл всегда выполняется лишь один раз. Такой цикл часто вставляют в макрос, чтобы тем самым поставить блок кода в "скобки".
Функции, вызываемые прямо в заголовках условных конструкций или циклов - это норма. И многое другое удивительное и гениальное. Правда в учебнике лишь знакомят с "С". Я уверен найдётся ещё пол-дюжины различных заковыристых конструкций.
Из принципиально новых для меня технологий, оказалось что у функции тоже есть адрес. Оно и разумно, ведь функция, как и любая другая часть кода находится в памяти, а значит и на неё можно сделать указатель. Таким образом функцию можно "скармливать" в качестве параметра другой функции, и это называется callback, как-то так.
В последнее время чувствую опустошение. Многие в 20 лет становится специалистами в своей области, а я в 24 провожу остаток лета за изучением первичных компьютерных навыков. Мои интеллектуальные способности скудны, мои физические данные не превосходят большинство. Да и я сам на самом деле ничего не хочу, у меня просто на просто нет "области". Я лишь продолжаю играть в какую-то непонятную игру, которую затеял когда-то в подростковом возрасте.
Чувствую себя педафилом-неудачником, который пытается заманить девочку куклой барби, когда в моде давно уже Хаги Ваги. Да и девочки уже понимают все, и сразу просят кэш за сексуальные услуги.
Хотя в мусорный бак это всё. Раз уж играть придётся, то лучше хотя бы запастись энтузиазмом.
>Хоть и мразь.
Это потому что я назвал шизоидом Андрея Викторовича? Я успел забрать свои слова обратно. Столяров довольно грамотный. Но с первого взгляда я думаю кто угодно подумает что он шизоид.
Он пишет статьи в Википедии на те темы, которые сам выдумал, и ссылается сам на себя. Он же был социологом в СССР? Напоминает образ того препода по диалектическому материализму из фильма "груз 200".
>Видно же, что ты голова.
Я, пожалуй, лучше знаю себя, чем кто-либо.
IQ у меня нынче 110. Ого! Разница в 12 баллов. Для меня это показатель, что тест не работает. Интеллект генетически детерминирован, и выше стать не может, а погрешность в 12 баллов это что-то слишком. По личным ощущениям, я будто бы уже помнил как решать некоторые задания, не смотря на то, что было это два года назад. Воспоминания будто бы появлялись из далёких закромов. К тому же, два года назад я не понимал в чём суть этого теста. Показывают фигуры какие-то.. А в чём задача-то? Я думал, что это тест на логику, и мне нужно вычислить что-то. Оказалось, что логика здесь ни при чем. На самом деле этот тест измеряет сообразительность - то насколько быстро ты можешь предсказать следующее звено в последовательности. На этот раз я уже знал, что мне нужно обращать внимание сразу на все фигуры и отвечать на вопрос: "а что интуитивно могло бы быть следующим, и почему". Тупить начал ближе к 25-ому вопросу, когда действительно приходилось по несколько минут всматриваться в принцип устройства этих фигурок.
Но что-то мне подсказывает, что если каждую неделю нарешивать этот тест, то можно дорешаться до невиданных результатов.
Но есть и плюсы. Если тест не работает, значит и результат в 98 баллов никакого смысла не имеет.
Но что-то мне подсказывает, что если каждую неделю нарешивать этот тест, то можно дорешаться до невиданных результатов.
Но есть и плюсы. Если тест не работает, значит и результат в 98 баллов никакого смысла не имеет.
Так условие iq теста в том и заключается, чтобы решить его один единственный раз. Так что твой результат 98 баллов.
Как это влияет на характер теста?
Если человеку перед тестом расскажут что надо делать и куда смотреть, то его первый результат будет на 12 баллов выше, чем если бы он ему ничего не объяснили. Узнать как сдавать IQ тест он мог совершенно случайно. К разница в 12 баллов.
Была бы разница в 2-3 балла, я бы согласился, что только первый результат засчитывается.
Впрочем, результат в 98 баллов меня не огорчит.
Хотя 98 IQ вполне правдоподобно. Недавно прочитал информацию, что люди с высоким IQ лучше выстраивают связи в обществе. Я за всю жизнь никаких связей не приобрёл. Да и признаюсь, мне сложно отгадывать капчу на дваче. Казалось бы, надо произвести всего пару математических операций, но я обязательно зависну в полном ступоре на секунд пять, над какой нибудь из операций.
Зря я не узнал как проходить тест IQ перед первой попыткой. Теперь сомнения, а какой бы был реальный результат.
Зря я не узнал как проходить тест IQ перед первой попыткой. Теперь сомнения, а какой бы был реальный результат.
На сегодняшний день, мой вес составляет 78 кг. Мой максимальный результат в жиме и становой тяге - 80 кг по 5 раз.
За это время, план тренировки претерпел некоторые изменения.
Во-первых, "победа по повторениям/по весу", эволюционировали в отдельные серии тренировок. Это означает, что первые шесть тренировок посвящаются работе с тем весом, при котором мне удавалось сделать максимум 12 повторений. В таких тренировках нужно стремиться к результату в 15 повторений, и допускается падать до результата в 8 повторений. Я добился результата 12 раз по 5 подходов вес в 65 кг. Забавно, что вес, который полгода назад я использовал как максимальный, теперь является лёгким. Первый подход, в тренировке "на количество", сделать просто. Поэтому, тут важно следить за временем отдыха между подходами. Я ограничиваю себя во времени отдыха, равном 1,5 минут. Тренировки 5×15, дают наибольшую эмоциональную разрядку, хоть и выполнять их проще.
Вторые шесть тренировок посвящены попытке поднять максимальный вес (не нарушая при этом технику движений). В каждой тренировке из этой серии по 5 подходов (ранее было 3 подхода, но такие тренировки мне показались неэффективными), и по 5 повторений. Время отдыха между подходами, как и скорость выполнения упражнения, особой роли не играет. Главное выдержать правильную технику, потому, что именно на больших весах есть соблазн согнуть кисть, так, чтобы предплечья не задействовались в выполнении упражнения. Тренировки 5×5 довольно скучны, и утомительны, из-за большого отдыха между подходами (без должного отдыха, на следующем подходе ничего уже поднять не получиться). Однако, именно на этих тренировках я заметил увеличение веса. Не знаю с чем это связано. Я рассчитывал, что массу будет увеличивать именно 5×15 тренировка, а 5×5 это так.. для прочности сухожилий.
Во-вторых, такие понятия как 1ПМ или 80% от 1ПМ, ушли в небытие. Дело в том, что с каждой тренировкой максимальный повтор может увеличиться, а может остаться неизменным. Поэтому если придерживаться чётких процентовок, то результат будет часто занижен. Намного проще работать на максимум и увеличивать вес тогда, когда посчитаешь нужным.
Освободилось немного времени, продолжаю читать А.В. Столярова. Завис на главах про операционные системы. Плохо, что автор недолюбливает Windows. Хотелось бы почитать и о том, в чём же разница файловой системы Windows и Unix. Какие системные вызовы предоставляет та или инная ОС. В чём минусы и недостатки? В чём принципиальная разница? На счёт последнего, спрашивал у анонов из /pr/, так там мне ответили, что якобы линукс и шиндоус вообще ничем не отличаются, так как воруют код друг у друга.
Перечитал собственный же дневник. Неужели всё это я начал, чтобы "найти непыльную работу". Родственники меня кормят. По-моему, мне вовсе не нужно идти работать. Новые знания улучшают самочувствие, чувствуешь себя здоровее. Таким образом, прожить можно и без работы.
Процесс-это область памяти которая хранит данные о состоянии программы.
Программа выполняется последовательно команда за командой. Существует регистр, который говорит процессору, какая команда будет следующей. Как мы уже выяснили, современные ОС способны выполнять сразу несколько программ, путём быстрого переключения между ними. Сразу же возникает вопрос, а как тогда процессор не "запутается" между этими программами. Для этого и существует "процесс". Процесс содержит в себе данные о регистрах перед прерыванием, а также локальные переменные, идентификатор самого процесса. Насчёт того, что конкретно содержится в процессе - я могу ошибаться, суть в том, что процесс это некоторая "голова" программы.
Выяснилось, у одной программы может быть два процесса. Этот факт привносит большую ясность в понятие "процесс". С помощью системного вызова fork, происходит нечто новое... два куска кода начинают выполнятся параллельно. При этом код у них общий. Код находится в одной секции, и в частном случае может быть одинаков. А вот переменные могут быть как разными, так и общими, в зависимости от того как захочет автор программы. Получается, что в одной странице когда присутствуют две сущности, которые этот код выполняют.
Ядро - ещё один термин, который мне всегда казался загадочным. Оказалось, что всё совсем лежит на поверхности, ядро это и есть операционная система. Кто-то может закуситься, и поспорить, но это попытка запудрить мозги. Для новичка, понятие ядро эквивалентно операционной системе. Уж копаться в том, что к ядру относиться, а что нет - удел явно не начинающих.
Вплоть до недавнего времени я всё никак не понимал:"- а где хранятся текстовые файлы? В ОЗУ или в ПЗУ". С одной стороны, их слишком много, чтобы хранить на ОЗУ, значит хранятся они на ПЗУ. С другой, если операционная система находится в ОЗУ, то какое право мы имеем редактировать эти файлы прямо в блокноте? Ответ пришёл сам. С помощью системного вызова mmap, можно как подгружать байты с жёсткого диска, так и наоборот, байты с оперативной памяти можно перенаправить на жёсткий диск. Так, что вся загадочность редактирования файлов разрешается сама собой. Но что на счёт хранения? Мы же видим тысячи файлов на гигабайты памяти, при том что все запущенные программы находятся в тесном ОЗУ? Дело в том, что сами файлы, являются порождением операционной системы, и к байтам на жёстком диске прямого отношения не имеют. Задача файлов заключается в том, чтобы удобно реализовать представление этих байтов памяти, сами байты могут располагаться абсолютно случайно, файл лишь связывает эти байты удобной структурой. И не обязательно байты памяти. Во FreeBSD, файл вообще может быть устройством, потоком ввода-вывода или ссылкой на другой файл. Типов файлов всего 4:
1. Файл-блок
2. Файл-поток
3. Файл-мягкая ссылка
4. Файл-каталог
Файл-блок - самый привычный вид файлов. Внутри блока можно переходить к следующему значению, или возвращаться к предыдущему, блок имеет какой-то объём, грубо говоря, блок - это страничка ячеек. Любой текстовый файл, любая картинка - это блок-файл.
В отличии от блока, файл-поток не обладает таким набором свойств. В нём нельзя переходить к конкретному значению, или выделить "часть". В файл-поток может только работать с накапливающимся значением, или с текущим значением в данный момент. Файл-поток, это поток ввода-вывода, это клавиатура, это мышь.
Каталог и мягкая ссылка - это типы файлов, аналогичные "папка" и "ярлык", соответственно. Описание излишне. Но не надо забывать, что по мнению автора "папки - в шкафу, а к директориям такой термин не применим".
В очередной раз все смотрят на меня как на дурака. Во всех тредах меня развернули, сосчитав за троля/школьника/шизофреника. Интуитивно понимаю, что я явно занят чем-то глупым, но я не могу объяснить себе, в чём же заключается глупость.
Во втором томе учебника А.В. Столярова, есть глава под названием "Программа на Си без стандартной библиотеки", где, как и следует из названия, автор демонстрирует написание программы не используя стандартных модулей. Мне эта идея показалась интересной для обучения, и я начал пытаться провернуть то же самое на ОС Windows.
Задача сводится к тому, чтобы написать "с нуля" программу на ассемблере NASM под Windows. Написанная программа должна выводить текст "hello world". Проблема заключается в том, что я не понимаю как реализовать сам вывод. Рассмотрим варианты, которые я отчаянно гуглил.
1. Операционная система Windows, предоставляет API в виде .dll библиотек, которые не являются частью ядра. Устройство и функции ядра Windows не задокументированны. Следовательно любой вывод с использованием библиотек WinAPI уничтожает смысл разработки "без стандартной библиотеки" (хоть и формально стандартной библиотеки действительно не будет). Попытаюсь развить свою мысль: если использовать библиотеки WinAPI, то "моя основная" часть кода будет заключаться в перемещении данных по регистрам и памяти (команды MOV и LEA, рис 4). Эта часть кода меня вполне устраивает, ведь я всегда могу откомпилировать .asm код в .bin и проверить как машинные команды соответствуют командам ассемблера (проверил на заголовке рис 3). Но как раз эту часть кода можно без особого труда реализовать на Си без библиотек, ведь создание переменных и операции присваивания библиотек не требуют. А вот функций WinAPI - это программы, которые даже не являются частью ядра, и в машинный код напрямую не преобразовываются. Таким образом, я коственно вызываю часть стандартной библиотеки. Такая .asm программа не эквивалентна машинному коду, а значит это и вовсе не "с нуля".
2. Один анон, зачем-то скинул мне вот такую статью на википедии https://en.wikipedia.org/wiki/Memory-mapped_I/O_and_port-mapped_I/O. Я так и не понял, что ещё за "вывод в порты"? Разве операционная система не переводит процессор в защищённый режим? С другой стороны, мне искринне не понято, почему операционная система может переключать процессор в защищённый режим, а вот прикладные программы выходить из этого режима не могут. Все команды попадают на регистр-счётчик. Для того, чтобы вывести процессор из защищённого режима необходимо подать какую-то команду. Если прикладная программа имеет право подать что-то на счётчик команд, то почему она не может подать команду выхода в привелегированный режим? Но в книге пишут, что всё идёт через ядро, и не бывает так, чтобы программа имела доступ к переферийным устройствам в обход ядру.
3.Я натыкался на информацию, что якобы, кроме системных вызовов операционной системы, существуют также системные вызовы BIOS. Вообще, я думал, что BIOS только загружает bootloader, а после даже и не работает. К чему это я? Эта информация натолкнула меня на другую мысль: если уж прикладные программы не могут работать в привелегированном режиме, то и никакие .dll не могут напрямую что-то выводить на переферийные устройства. Сколько не спрашивал у анонов про системные вызовы Windows, никто не отвечает. Гугл ничего не выдаёт. Будто бы их и не существует.
Читаю главу "Сети и протоколы". У меня снова возникло неприятное чувство того, что мне рассказывают какие-то непонятные вещи. Взять модель OSI ISO? Почему это "модель", а не "классификация"? При том, каждый уровень описывает какие-то совершенно разные области, с разными задачами и разными реализациями? Выглядит будто бы кто-то взял мышь, монитор и лазерную указку, а затем случайно записал каждый объект в случайный уровень. Допустим, как "физический уровень" вообще связан с сетью, если передавать пакеты можно хоть по RS, хоть по USB? Первый настоящий уровень, это "канальный",второй - "сетевой", остальные вообще чъёрт знает зачем нужны. Так, что эту модель OSI я вообще никогда не понимал, и не понял. Благо, автор пишет, что сама эта модель - лишь формальность. Продолжу читать, это всяко лучше роликов на ютьюбе. Дочитаю второй том, и уже можно устраиваться помощником системного администратора!
Во втором томе учебника А.В. Столярова, есть глава под названием "Программа на Си без стандартной библиотеки", где, как и следует из названия, автор демонстрирует написание программы не используя стандартных модулей. Мне эта идея показалась интересной для обучения, и я начал пытаться провернуть то же самое на ОС Windows.
Задача сводится к тому, чтобы написать "с нуля" программу на ассемблере NASM под Windows. Написанная программа должна выводить текст "hello world". Проблема заключается в том, что я не понимаю как реализовать сам вывод. Рассмотрим варианты, которые я отчаянно гуглил.
1. Операционная система Windows, предоставляет API в виде .dll библиотек, которые не являются частью ядра. Устройство и функции ядра Windows не задокументированны. Следовательно любой вывод с использованием библиотек WinAPI уничтожает смысл разработки "без стандартной библиотеки" (хоть и формально стандартной библиотеки действительно не будет). Попытаюсь развить свою мысль: если использовать библиотеки WinAPI, то "моя основная" часть кода будет заключаться в перемещении данных по регистрам и памяти (команды MOV и LEA, рис 4). Эта часть кода меня вполне устраивает, ведь я всегда могу откомпилировать .asm код в .bin и проверить как машинные команды соответствуют командам ассемблера (проверил на заголовке рис 3). Но как раз эту часть кода можно без особого труда реализовать на Си без библиотек, ведь создание переменных и операции присваивания библиотек не требуют. А вот функций WinAPI - это программы, которые даже не являются частью ядра, и в машинный код напрямую не преобразовываются. Таким образом, я коственно вызываю часть стандартной библиотеки. Такая .asm программа не эквивалентна машинному коду, а значит это и вовсе не "с нуля".
2. Один анон, зачем-то скинул мне вот такую статью на википедии https://en.wikipedia.org/wiki/Memory-mapped_I/O_and_port-mapped_I/O. Я так и не понял, что ещё за "вывод в порты"? Разве операционная система не переводит процессор в защищённый режим? С другой стороны, мне искринне не понято, почему операционная система может переключать процессор в защищённый режим, а вот прикладные программы выходить из этого режима не могут. Все команды попадают на регистр-счётчик. Для того, чтобы вывести процессор из защищённого режима необходимо подать какую-то команду. Если прикладная программа имеет право подать что-то на счётчик команд, то почему она не может подать команду выхода в привелегированный режим? Но в книге пишут, что всё идёт через ядро, и не бывает так, чтобы программа имела доступ к переферийным устройствам в обход ядру.
3.Я натыкался на информацию, что якобы, кроме системных вызовов операционной системы, существуют также системные вызовы BIOS. Вообще, я думал, что BIOS только загружает bootloader, а после даже и не работает. К чему это я? Эта информация натолкнула меня на другую мысль: если уж прикладные программы не могут работать в привелегированном режиме, то и никакие .dll не могут напрямую что-то выводить на переферийные устройства. Сколько не спрашивал у анонов про системные вызовы Windows, никто не отвечает. Гугл ничего не выдаёт. Будто бы их и не существует.
Читаю главу "Сети и протоколы". У меня снова возникло неприятное чувство того, что мне рассказывают какие-то непонятные вещи. Взять модель OSI ISO? Почему это "модель", а не "классификация"? При том, каждый уровень описывает какие-то совершенно разные области, с разными задачами и разными реализациями? Выглядит будто бы кто-то взял мышь, монитор и лазерную указку, а затем случайно записал каждый объект в случайный уровень. Допустим, как "физический уровень" вообще связан с сетью, если передавать пакеты можно хоть по RS, хоть по USB? Первый настоящий уровень, это "канальный",второй - "сетевой", остальные вообще чъёрт знает зачем нужны. Так, что эту модель OSI я вообще никогда не понимал, и не понял. Благо, автор пишет, что сама эта модель - лишь формальность. Продолжу читать, это всяко лучше роликов на ютьюбе. Дочитаю второй том, и уже можно устраиваться помощником системного администратора!
И ещё нашёл, тот момент на котором я вчера уснул. Вот что это?:
...Чтобы минимизировать трудозатраты при настройке сетей, системные администраторы всегда стараются выбрать ip-адреса и подсети так, чтобы ip-адреса, используемые в каждой сети, что бы не понималось под сетью, можно было указать в виде одной ip-подсети. Из этого естественным образом следует, что компьютер, входящий больше чем в одну сеть, должен иметь собственный адрес в каждой из сетей, в которые он входит...
Ничего непонятно. Не сказано ни что такое "сеть" (даже никак не пояснено), ни что вообще из себя представляет протокол ip. Просто ни с того, ни с сего набор какого-то непонятного текста, из которого можно только на заметку оставить разве что отрывок "компьютер, входящий больше чем в одну сеть, должен иметь собственный адрес в каждой из сетей".
Это, конечно, придирка. В отличии от случайных видео по системному администрированию, в главе прос есть много чего полезного. Например, автор демонстрирует, что подключить компьютеры в сеть можно практически любыми средствами, будь то витая пара или RS. Это важно. Такие факты помогают абстрагироваться от конкретного оборудования. Я же как древний человек - вижу, патч-корд - значит интернет тама находится! Чтобы понять, что это всего один из видов соединения компьютеров (причём не обязательно к интернету), посвящено достаточно страниц. Но, я почему-то ожидал, что глава про системы и сети с самого начала сильно удивит меня, как, например, меня удивила глава про паскаль.
...Чтобы минимизировать трудозатраты при настройке сетей, системные администраторы всегда стараются выбрать ip-адреса и подсети так, чтобы ip-адреса, используемые в каждой сети, что бы не понималось под сетью, можно было указать в виде одной ip-подсети. Из этого естественным образом следует, что компьютер, входящий больше чем в одну сеть, должен иметь собственный адрес в каждой из сетей, в которые он входит...
Ничего непонятно. Не сказано ни что такое "сеть" (даже никак не пояснено), ни что вообще из себя представляет протокол ip. Просто ни с того, ни с сего набор какого-то непонятного текста, из которого можно только на заметку оставить разве что отрывок "компьютер, входящий больше чем в одну сеть, должен иметь собственный адрес в каждой из сетей".
Это, конечно, придирка. В отличии от случайных видео по системному администрированию, в главе прос есть много чего полезного. Например, автор демонстрирует, что подключить компьютеры в сеть можно практически любыми средствами, будь то витая пара или RS. Это важно. Такие факты помогают абстрагироваться от конкретного оборудования. Я же как древний человек - вижу, патч-корд - значит интернет тама находится! Чтобы понять, что это всего один из видов соединения компьютеров (причём не обязательно к интернету), посвящено достаточно страниц. Но, я почему-то ожидал, что глава про системы и сети с самого начала сильно удивит меня, как, например, меня удивила глава про паскаль.
Не, ну ни разу не шизоид.
И ведь я на самом деле даже и не против абортов. Я действительно просто решил "поцитировать пролайферские методички", как он и сказал. Чего я точно не ожидал, что он с двух постов изойдёт на говно и в очередной раз будет меня прогонять, будто бы он жертва надоедливого телефонного пранка.
Справедливости ради, учебники у него годные!
И ведь я на самом деле даже и не против абортов. Я действительно просто решил "поцитировать пролайферские методички", как он и сказал. Чего я точно не ожидал, что он с двух постов изойдёт на говно и в очередной раз будет меня прогонять, будто бы он жертва надоедливого телефонного пранка.
Справедливости ради, учебники у него годные!
>Спрашивал у анонов из /pr/, так там мне ответили, что якобы линукс и шиндоус вообще ничем не отличаются, так как воруют код друг у друга
Главное отличие в том что windows это ЛУЧШАЯ (на мой взгляд) операционка для десктопа которая поддерживает лишь ПАРУ архитектур процессоров.
Линукс это операционка универсальный конструктор. Для любого устройства и любой архитектуры цпу, открытая к модификации. Она работает на всех процессорах и самое главное может запускатся на очень слабых девайсах. Типа часов, роутеров, вибраторов, электрочайников. Ты сам можешь пересобрать Линукс под своё устройство удаляя из неё те или иные возможности чтобы она запустилась к примеру на 8Mb озу.
Ну вообщем ты понял. И ты обязательно выйийграешь.
Сделал прототип программы, которая форматирует .txt файлы.
Я часто нахожу текстовые файлы, в которых по какой-то причине весь текст вмещён в одну бесконечную строчку. Можно было бы поступить как мудрый человек - заглянуть в гугл, поискать сайт на котором можно онлайн отформатировать текст. Это самый быстрый способ. Если уж так не хочется заходить на сайты с javascript, то можно разобраться с форматированием в notepad++, и заставить его с какой-то периодичностью ставить символы перевода строки. В конечном счёте, можно нажать ctrl+a и скопировать весь текст в word, который автоматически его приведёт в читабельный вид. Но я не настолько мудр. После прочитанных книг, меня постоянно захватывает мысль, что обязательно нужно создать программу. Мне казалось, это должно быть просто, ведь я же видел в примерах из книги много таких программ-фильтров, и даже некоторые из них повторял (правда это было на паскале). Но на деле оказалось, что я вообще большую часть прочитанного помню фрагментами, а кодить и вовсе не умею (я ведь практически на си ничего не кодил, кроме примеров, которые мне показались непонятными). Итого, у меня ушёл день, чтобы вспомнить чем printf отличается от fprintf, как вводить аргументы, как написать это заковыристое ((c = getchar()) != EOF) (P.S. я до сих пор уверен, что тут какой-то нехороший побочный эффект может быть. Во всяком случае выглядит эта конструкция ненадёжно), найти интересную функцию snprintf а также написать 43 строчки кода. К сожалению, эта программа ещё и даёт хреновый результат: почему-то она корректно работает только на ASCII символах. А вот на символах UTF-8, всё плывёт: во-первых перевод строки начинается на половине от заданной длины (lwdh/2), во-вторых между символами разрыва строки появляются какие-то крокозябры, порой заменяя одну из букв (или даже две).
Что делать с другими кодировками я не знаю, но в этом явно нужно разобраться. Не будешь же ты всю вечность программы на ASCII символах делать.
Желательно, ещё сделать так, чтобы программа умела разбивать слова по слогам, и ставить знак "-" в этом случае.
Как же бесполезно я потратил этот день.
>windows это ЛУЧШАЯ (на мой взгляд)
Вот я действительно не понимаю за что не любят windows. Если опустить идеологические проблемы, типо "слежки", то чем конструктивно плох windows? Я всё же установил себе FreeBSD, чисто для антуража, и даже с учётом всех удобств, я бы не сказал что она стабильнее винды. Как мне кажется, свободное ПО никогда не победит поприетарное платное. Когда ты пользуешься свободным ПО, происходит следующее: программа вылетат с ошибкой, ты обращаешься к разработчику с вопросом: "а каого хрена эта программа не запускается", на что тебе отвечают: "ну так ты ламер, ёпта, вон ошибка - чини". Нужно ли производственнику сидеть и копаться в коде, пока у него конвеера простаивают? Нет, конечно же. Надо чтобы запустил программу - и она работает. Сколь "правильными" в архитектурном плане не были программы из GPL, их разработчики никогда не будут бережно относиться к клиенту, просто потому что недовольный клиент для них - это какой-то недалёкий ламер, который не хочет разбираться в их хобби. А вот поприетарное платное ПО будет беречь каждого значимого* клиента, ведь от этого зависит их прибыль (значимый тут со звёздочкой, потому, что потеря не каждого клиента несёт убыток. Например корпорация Microsoft имеет полные возможности плевать на нас, ведь многие из нас не то, что незначительный доход несут, многие из нас и вовсе ничего у них не покупают). Поэтому производственнику проще заплатить денег и получить то, что стабильно работает, не вникая в "науку". С другой стороны, я думаю что идеи бесплатного ПО благоприятно играют на рынок: они как минимум предоставляют альтернативу от монополий. Хоть они и лишают всех удобств, но предоставляют свободу. Так что негатив в сторону windows сам по себе полезен, хоть и не обоснован.
Сидеть на FreeBSD - это интересный опыт. Код с открытым исходным кодом создаёт благоприятную атмосферу того, что ты (теоретически) можешь изучить каждую часть своей ОС. Само название BSD звучит так, будто бы ты студент беркли из 80-х.
Я часто нахожу текстовые файлы, в которых по какой-то причине весь текст вмещён в одну бесконечную строчку. Можно было бы поступить как мудрый человек - заглянуть в гугл, поискать сайт на котором можно онлайн отформатировать текст. Это самый быстрый способ. Если уж так не хочется заходить на сайты с javascript, то можно разобраться с форматированием в notepad++, и заставить его с какой-то периодичностью ставить символы перевода строки. В конечном счёте, можно нажать ctrl+a и скопировать весь текст в word, который автоматически его приведёт в читабельный вид. Но я не настолько мудр. После прочитанных книг, меня постоянно захватывает мысль, что обязательно нужно создать программу. Мне казалось, это должно быть просто, ведь я же видел в примерах из книги много таких программ-фильтров, и даже некоторые из них повторял (правда это было на паскале). Но на деле оказалось, что я вообще большую часть прочитанного помню фрагментами, а кодить и вовсе не умею (я ведь практически на си ничего не кодил, кроме примеров, которые мне показались непонятными). Итого, у меня ушёл день, чтобы вспомнить чем printf отличается от fprintf, как вводить аргументы, как написать это заковыристое ((c = getchar()) != EOF) (P.S. я до сих пор уверен, что тут какой-то нехороший побочный эффект может быть. Во всяком случае выглядит эта конструкция ненадёжно), найти интересную функцию snprintf а также написать 43 строчки кода. К сожалению, эта программа ещё и даёт хреновый результат: почему-то она корректно работает только на ASCII символах. А вот на символах UTF-8, всё плывёт: во-первых перевод строки начинается на половине от заданной длины (lwdh/2), во-вторых между символами разрыва строки появляются какие-то крокозябры, порой заменяя одну из букв (или даже две).
Что делать с другими кодировками я не знаю, но в этом явно нужно разобраться. Не будешь же ты всю вечность программы на ASCII символах делать.
Желательно, ещё сделать так, чтобы программа умела разбивать слова по слогам, и ставить знак "-" в этом случае.
Как же бесполезно я потратил этот день.
>windows это ЛУЧШАЯ (на мой взгляд)
Вот я действительно не понимаю за что не любят windows. Если опустить идеологические проблемы, типо "слежки", то чем конструктивно плох windows? Я всё же установил себе FreeBSD, чисто для антуража, и даже с учётом всех удобств, я бы не сказал что она стабильнее винды. Как мне кажется, свободное ПО никогда не победит поприетарное платное. Когда ты пользуешься свободным ПО, происходит следующее: программа вылетат с ошибкой, ты обращаешься к разработчику с вопросом: "а каого хрена эта программа не запускается", на что тебе отвечают: "ну так ты ламер, ёпта, вон ошибка - чини". Нужно ли производственнику сидеть и копаться в коде, пока у него конвеера простаивают? Нет, конечно же. Надо чтобы запустил программу - и она работает. Сколь "правильными" в архитектурном плане не были программы из GPL, их разработчики никогда не будут бережно относиться к клиенту, просто потому что недовольный клиент для них - это какой-то недалёкий ламер, который не хочет разбираться в их хобби. А вот поприетарное платное ПО будет беречь каждого значимого* клиента, ведь от этого зависит их прибыль (значимый тут со звёздочкой, потому, что потеря не каждого клиента несёт убыток. Например корпорация Microsoft имеет полные возможности плевать на нас, ведь многие из нас не то, что незначительный доход несут, многие из нас и вовсе ничего у них не покупают). Поэтому производственнику проще заплатить денег и получить то, что стабильно работает, не вникая в "науку". С другой стороны, я думаю что идеи бесплатного ПО благоприятно играют на рынок: они как минимум предоставляют альтернативу от монополий. Хоть они и лишают всех удобств, но предоставляют свободу. Так что негатив в сторону windows сам по себе полезен, хоть и не обоснован.
Сидеть на FreeBSD - это интересный опыт. Код с открытым исходным кодом создаёт благоприятную атмосферу того, что ты (теоретически) можешь изучить каждую часть своей ОС. Само название BSD звучит так, будто бы ты студент беркли из 80-х.
> А вот на символах UTF-8
В UTF-8 символы имеют переменный размер. Грубо говоря, всё что есть в нерасширенном ASCII вмещается в 1 байт, каждый символ кириллицы идёт в 2х байтах, хангыль в 3х и так далее.
И так как ты берёшь строки незаковыристым ((c = getchar()) != EOF) (т.е. побайтово) и длину ограничиваешь также в байтах, то поэтому и случаются плохие вещи...
(абвгдеёжз, символов 9, байтов 18, обрежешь по границе 10, обрежутся первые 5 букв, в этом случае без происшествий, но если вдруг между ними втиснется какой-нибудь символ состоящий из 1 байта...)
Тебе нужно считать не байты, а символы. В UTF-8 с этим очень просто.
Если байт начинается с бита = 0, то это однобайтовый символ.
Если байт начинается с бита = 1, то по количеству ненулевых битов в начале этого байта можно понять, из скольки байтов будет состоять символ. Косноязычно объяснил, пикрил 1 - пример из Википедии. Первые 3 бита в первом байте ненулевые, потом идёт 0, значит весь символ состоит из 3 байтов.
Если байт начинается с бита = 1, а сразу после этого ненулевого бита идёт нулевой, это не значит, что символ состоит из одного байта; это значит, что ты попал в один из дополнительных байтов символа, помимо первого. Ну, по пикрилу должно быть тоже понятно.
Вот...
В UTF-8 все байты-продолжения имеют вид 0b10xxxxxx, то есть байт с любыми другими двумя верхними битами является первым байтом символа, разделять можно только перед такими байтами, и для подсчёта можно тупо считать их (но всё это в первом приближении).
Тогда, наверное, правильно разбить программу на три подпрограммы. Первая из которых детектила бы кодировку, вторая выбирала правила для разбиения по символам, и третья главная программа которая бы осуществляла форматирование.
Может быть есть вариант узнать кодировку из какой-нибудь переменной окружения, когда открываешь поток ввода-вывода в файл?
>незаковыристым ((c = getchar()) != EOF)
Значит незаковыристым. Я тут могу полагаться только на твой авторитет. С одной стороны, сам Cтоляров говорит, что "настоящие сишники" пишут вот так, с другой он советует не пихать всё что имеет кучу побочных эффектов в условные конструкции, а разбить вот так:
c = getchar();
while (с != EOF) {
//... code
c = getchar();
}
Какие системные вызовы я не пробовал, хоть int 0x0008, хоть досовский int 21h, хоть найденный в гугле int 2Eh, они не работают. Скорее всего тут без досканального изучения устройства windows не обойтись, винда как-то по другому наверное создаёт потоки ввода-вывода.
> Значит незаковыристым
Извини, я хотел продублировать то, что ты написал, но неправильно прочитал твой пост. Ну то есть, у меня тоже должно быть "заковыристым". Ну короче, блин...
> С одной стороны, сам Cтоляров говорит, что "настоящие сишники" пишут вот так
Столяров ещё ненавидит UTF-8, называет его бинарным форматом, и, ЕМНИП, пропагандирует использование КОИ-8, потому что если проебется старший бит, то TEKST OSTANETSQ WPOLNE ^ITAEMYM. Не знаю, зачем, но это видимо очень важно.
> ЕМНИП, пропагандирует использование КОИ-8
Ладно, не говорил он ничего такого. Как тут пост удалить...
Говорил. Но мне помнится, что он просто считал, что самой лучшей кодировкой для русского языка является КОИ-8.
Так-то он и Windows напрямую не называет плохой ОС. Он просто вскольз упомянает о некоторой "другой плохой операционной системе". Очевидно, что эта другая ОС уж точно не BeOS.
2
Дочитал главу про системы и сети. Ничего уже не понимаю. Это значит нужно халатно дочитать оставшееся, и переходить к практике. Практика приведёт всё прочитанное в порядок. Дочитать для галочки хочется, просто чтобы знать что вообще в этом мире существует, что можно гуглить.
Кратко перескажу какое представление сложилось о сетях.
Протокол - это соглашение, кодировка, спецификация для взаимодействия двух компьютеров. Протокол не подразумевает собой программу, протокол представляет собой правила соответствия. "Зачем нужны какие-то правила? Сложно что-ли просто передать информацию?" - такие мысли ранее часто приходили мне в голову. Я не углублялся в вопрос детально. Если так подумать, то даже самое простое действие по передаче информации нуждается в соглашениях. Например, когда два человека ведут устный разговор между собой, у них в голове звуковые сигналы приводятся в соответствие с буквами алфавита. Это соответствие и можно назвать протоколом. Если бы в таком примере, собеседник был иностранцем, не понимал русского языка, то взаимодействие реализовать не удалось. Так же и на компьютерах, для того, чтобы двум компьютерам пообщаться друг с другом, им нужно иметь некоторые соглашения.
Протоколы, в модели OSI (на мой вгляд, это больше классификация, нежели модель), подразделяются от низкого уровня, к прикладному. Такое расположение чем-то схоже с классификацией языков программирования: от низкоуровненвых, к высокоуровневым. Разница заключается лишь в том, что протокол верхнего уровня не может работать без нижнего.
Протоколы физического уровня организуют взаимодействие железа, на входные сигналы. Об этом протоколе мало что известно, может потому, что эта работа производителей оборудования. а не системных администраторов, но суть ясна.
Протоколы канального уровня уже работают с MAC адресами. То есть, эти протоколы уже определяют кому и как какие пакеты пересылать. Впринципе, на этом уровне уже можно обеспечивать какую-то сеть, так зачем же что-то ещё? Как выяснилось, организовывать крупные сети, такие как "интернет" на канальном уровне крайне неудобно (и практически невозможно). Только вдуматься: в сети сто компьютеров, и каждый из них может выключиться в любое время, и разорвать узел соединения, и для этого необходимо вручную каждый раз составлять другой маршрут. Нужно что-то универсальное, что могло бы связать все компьютеры, даже если один из них отключился.
Для борьбы с этой проблемой наверняка придумали какой-то алгоритм, для автоматической организации взаимодействия. Тогда соединение через MAC адреса трогать нелья - этим занимается алгоритм. Занчит, нужен новый протокол, уровня выше, который работал с этими алгоритмами, например, IP. На нём работа уже производится с привычными IP адресами. Как он конкретно устроен, я не понял, суть в том, что маршрутизацию теперь можно настраивать намного проще, достаточно знать адреса сети и подсети.
Но и на этом развитие не ограничивается. Кроме того, что теперь уже выдаётся возможность связать множество компьютеров, возникает задача правильной передачи данных. Пускай, нам необходимо передать блок-файл через сеть, мы разбиваем его по пакетам и отправляем. А как наш компьютер-адресат поймёт, что эти пакеты нужно соединить в правильном порядке? Тем более, что разные компьютеры имеют разные архитектуры, и порядок байтов может быть у одного litle-endian, а у другого big-endian. Для этого, мы можем отправить ему записку-дейтаграмму, которая бы содержала порядок этих пакетов. Собственно, для этого существует соглашение UDP. Помимо дейтаграмм, мы можем также организовывать и передачу файла-потока, но тогда нам нужно руководствоваться уже других правил, таких как TCP. Все эти протоколы объединяются классом "транспортного уровня". Они заключаются не только в дейтаграммах, в протоколах транспортного уровня описаны также "порты" - которые являются чем-то вроде идентификатора, для конкретного места в операционной системе адресата. Главное, что все протоколы этого уровня предназначены уже для конкретных данных, адерсованных конкретному процесса.
Также есть и протоколы более высокого уровня, такие как HTTP, POP3, которые работают и вовсе с прикладными вещами: браузер, электронная почта итд.
Сетевые сокеты - вот это уже объекты в области ядра. В отличии от протоколов, это не просто "правила", это конкретные алгоритмы для реализации сетевого взаимодействия по этим правилам. Сетевой сокет, чем-то похож на "канал" при создании параллельных процессов. Разница лишь в том, что сетевой сокет учитывает протоколы, и может работать с несколькими процессами. Связать два процесса на разных комьютерах - задача более тонкая, нежели сделать это внутри одного комьютера. Дело всё в том, что на практике, к компьютеру-серверу, может подключаться более одного клиента, и тогда другие клиенты могут просто зависать, и получать таймаут. Существует два разрешения такой проблемы: либо каждому клиенту выделяется свой процесс, либо же клиент сразу же блокируется, если никаких данных от него не поступает. Второй способ получается выигрышнее, но требует инного способа написания программ: событийно-ориентированного.
Событийно-ориентированный способ оказался мне намного ближе чем императивный, ведь по сути, это и есть моя специальность - автоматизация. Алгоритм представляется, как автомат Мура, а дальше всё как составление программы для ПЛК.
Что же такое DNS? DNS - это магазин, где продают б/у по оверпрайсу.
Ещё DNS - это сервер, это некий компьютер (и не один), со своей базой данных, в котором реализован довольно умный алгоритм сопоставления доменных имён. Домен, как я понял, это имя связанное с IP-адресом какого-нибудь сервера, или имя связанное с множеством таких IP-адресов. 2ch.hk - это домен, но и сам .hk - это тоже домен. И 2ch.hk является частью .hk. Понятное дело, что хранить все IP адреса в одной базе данных не получиться. Даже если они туда поместятся - искать их будет сложновато при всякой балансировке, а уж тем более обрабатывать запросы от пользователей - сервер рухнет. Поэтому сам DNS-сервер, содержит только часть, частоиспользуемых адресов, а в случаях когда необходимо что-то, чего у него нет - он обращается к другим DNS-серверам, чтобы от них перенять новые имена. Кроме того, DNS сервер может и просто так связываться с другими серверами, просто для сверки актуальности информации. Получается эдакая распределённая система, как расписание автобусов, которое есть на каждой остановке.
Кратко перескажу какое представление сложилось о сетях.
Протокол - это соглашение, кодировка, спецификация для взаимодействия двух компьютеров. Протокол не подразумевает собой программу, протокол представляет собой правила соответствия. "Зачем нужны какие-то правила? Сложно что-ли просто передать информацию?" - такие мысли ранее часто приходили мне в голову. Я не углублялся в вопрос детально. Если так подумать, то даже самое простое действие по передаче информации нуждается в соглашениях. Например, когда два человека ведут устный разговор между собой, у них в голове звуковые сигналы приводятся в соответствие с буквами алфавита. Это соответствие и можно назвать протоколом. Если бы в таком примере, собеседник был иностранцем, не понимал русского языка, то взаимодействие реализовать не удалось. Так же и на компьютерах, для того, чтобы двум компьютерам пообщаться друг с другом, им нужно иметь некоторые соглашения.
Протоколы, в модели OSI (на мой вгляд, это больше классификация, нежели модель), подразделяются от низкого уровня, к прикладному. Такое расположение чем-то схоже с классификацией языков программирования: от низкоуровненвых, к высокоуровневым. Разница заключается лишь в том, что протокол верхнего уровня не может работать без нижнего.
Протоколы физического уровня организуют взаимодействие железа, на входные сигналы. Об этом протоколе мало что известно, может потому, что эта работа производителей оборудования. а не системных администраторов, но суть ясна.
Протоколы канального уровня уже работают с MAC адресами. То есть, эти протоколы уже определяют кому и как какие пакеты пересылать. Впринципе, на этом уровне уже можно обеспечивать какую-то сеть, так зачем же что-то ещё? Как выяснилось, организовывать крупные сети, такие как "интернет" на канальном уровне крайне неудобно (и практически невозможно). Только вдуматься: в сети сто компьютеров, и каждый из них может выключиться в любое время, и разорвать узел соединения, и для этого необходимо вручную каждый раз составлять другой маршрут. Нужно что-то универсальное, что могло бы связать все компьютеры, даже если один из них отключился.
Для борьбы с этой проблемой наверняка придумали какой-то алгоритм, для автоматической организации взаимодействия. Тогда соединение через MAC адреса трогать нелья - этим занимается алгоритм. Занчит, нужен новый протокол, уровня выше, который работал с этими алгоритмами, например, IP. На нём работа уже производится с привычными IP адресами. Как он конкретно устроен, я не понял, суть в том, что маршрутизацию теперь можно настраивать намного проще, достаточно знать адреса сети и подсети.
Но и на этом развитие не ограничивается. Кроме того, что теперь уже выдаётся возможность связать множество компьютеров, возникает задача правильной передачи данных. Пускай, нам необходимо передать блок-файл через сеть, мы разбиваем его по пакетам и отправляем. А как наш компьютер-адресат поймёт, что эти пакеты нужно соединить в правильном порядке? Тем более, что разные компьютеры имеют разные архитектуры, и порядок байтов может быть у одного litle-endian, а у другого big-endian. Для этого, мы можем отправить ему записку-дейтаграмму, которая бы содержала порядок этих пакетов. Собственно, для этого существует соглашение UDP. Помимо дейтаграмм, мы можем также организовывать и передачу файла-потока, но тогда нам нужно руководствоваться уже других правил, таких как TCP. Все эти протоколы объединяются классом "транспортного уровня". Они заключаются не только в дейтаграммах, в протоколах транспортного уровня описаны также "порты" - которые являются чем-то вроде идентификатора, для конкретного места в операционной системе адресата. Главное, что все протоколы этого уровня предназначены уже для конкретных данных, адерсованных конкретному процесса.
Также есть и протоколы более высокого уровня, такие как HTTP, POP3, которые работают и вовсе с прикладными вещами: браузер, электронная почта итд.
Сетевые сокеты - вот это уже объекты в области ядра. В отличии от протоколов, это не просто "правила", это конкретные алгоритмы для реализации сетевого взаимодействия по этим правилам. Сетевой сокет, чем-то похож на "канал" при создании параллельных процессов. Разница лишь в том, что сетевой сокет учитывает протоколы, и может работать с несколькими процессами. Связать два процесса на разных комьютерах - задача более тонкая, нежели сделать это внутри одного комьютера. Дело всё в том, что на практике, к компьютеру-серверу, может подключаться более одного клиента, и тогда другие клиенты могут просто зависать, и получать таймаут. Существует два разрешения такой проблемы: либо каждому клиенту выделяется свой процесс, либо же клиент сразу же блокируется, если никаких данных от него не поступает. Второй способ получается выигрышнее, но требует инного способа написания программ: событийно-ориентированного.
Событийно-ориентированный способ оказался мне намного ближе чем императивный, ведь по сути, это и есть моя специальность - автоматизация. Алгоритм представляется, как автомат Мура, а дальше всё как составление программы для ПЛК.
Что же такое DNS? DNS - это магазин, где продают б/у по оверпрайсу.
Ещё DNS - это сервер, это некий компьютер (и не один), со своей базой данных, в котором реализован довольно умный алгоритм сопоставления доменных имён. Домен, как я понял, это имя связанное с IP-адресом какого-нибудь сервера, или имя связанное с множеством таких IP-адресов. 2ch.hk - это домен, но и сам .hk - это тоже домен. И 2ch.hk является частью .hk. Понятное дело, что хранить все IP адреса в одной базе данных не получиться. Даже если они туда поместятся - искать их будет сложновато при всякой балансировке, а уж тем более обрабатывать запросы от пользователей - сервер рухнет. Поэтому сам DNS-сервер, содержит только часть, частоиспользуемых адресов, а в случаях когда необходимо что-то, чего у него нет - он обращается к другим DNS-серверам, чтобы от них перенять новые имена. Кроме того, DNS сервер может и просто так связываться с другими серверами, просто для сверки актуальности информации. Получается эдакая распределённая система, как расписание автобусов, которое есть на каждой остановке.
Количество ядер - не решает.
В детстве, среди школьников из богатых семей часто можно было услышать тёрки:
-а у тебя компьютер сколько ядер
-у меня - два
-а у меня - три!
-врёшь, трёх ядер не бывает!
-бывает! у меня самый новый! там даже виндоус 7
Услышав один раз такой диалог, я на всю жизнь усвоил негласную истину: чем ядер больше, тем мощнее компьютер. А ведь всё это время, я даже отдалённо не представлял, что же такое эти "ядра".
Ядро процессора, при поверхностном погружении можно воспринимать как отдельный процессор. Четыре ядра - четыре отдельных процессора.
Для выполнения одной программы достаточно всего одного процессора - программа будет выполняться последовательно команда за командой, как если бы мы написали список того, что должен сделать наш компьютер. Другие процессоры такой программе и не нужны - они всё равно никак не заставят эту программу работать быстрее. Гораздо более важной характеристикой процессора, для одной одинокой программы, являлась бы частота - чем больше тактов в секунду, тем быстрее считывались бы команды.
Современные программы практически никогда из себя не представляют одну одинокую последовательность команд. Различные последовательности команд работают параллельно, зачастую взаимодействуя друг с другом. Процессор уделяет каждой последовательности определённое количество тактов, а затем переключается выполнять другую последовательность. Если параллельных программ станет слишком много, то процессор будет вынужден уделять по одному такту каждой программе, и в результате все программы будут выполняться намного медленнее. Что для этого можно сделать? Взять ещё процессоров, и распределить работу среди них, чтобы каждой программе уделялось больше тактов.
Так что, неужели чем больше ядер - тем больше мощь? Полгода назад, я бы такой вывод и сделал. Но прочитав про семафоры, мьютексы и критическую секцию, я делаю вывод, что с параллельными программами не всё так гладко, особенно в той части, когда программы зависят друг от друга. Очевиднийшеми проблемами является всеми известная "ситуация гонки". Представим три параллельные программы, с общей переменной X. Первые две программы увеличивают значение переменной X на один, а третья выводит эту переменную на экран. На интуитивном уровне, кажется что результат работы этой программы будет равен 2: два процесса добавили по единице, а третий процесс всё это вывел. Но, не тут-то было... Результат вполне может быть 1 или даже 0. Дело в том, что мы не знаем какой из процессов, планировщик завершит первым. Мы не знаем, и не должны знать, в какой последовательности будут выполняться этапы: может все три такта пойдут на первую программу, или быть может один такт уделится на первую команду первой программы. а остальные два будут выполнять вторую программу.
После ознакомления с проблемой, вообще-то это даже не кажется проблемой: "программировайте нормально, и нормально будет, в чём проблема-то?". И действительно, это ведь состояние гонки - это "ошибка", а не "проблема"... Проблемы начинаются, когда эту "ошибку" начинают решать.
Первое решение, что приходит в голову: "а пусть, вот процесс который выводит всё это на экран, ничего не делает пока всё не посчиталось". Решение хорошее, вот только "ничего не делать" - это действие хоть и не трудозатратное, но такты процессора оно всё равно потребляет. Планировщику безразлично, заставил ли ты задачу ничего не делать, или работать - он всё равно выделит ей такты времени, в то время как остальные процессы выполняться не будут. Чем-то походит на ситуацию, когда к преподавателю пришли тысячи студентов которые ничего не знают: ты вроде всё учил, хочешь получить зачёт и свалить домой, а приходится прожидать длинную очередь из молчаливых студентов, тех самых что ничего не учили, и просто надеятся на милость. Как уже понятно, вполне может получиться ситуация, когда программа на параллельных процессах работает хуже, чем если бы такая программа выполнялась последовательно команда за командой: процессы просто крадут такты времени у других процессов, в то время как реальная польза от них может быть только после выполнения первых. Такая "холостая работа" называется "активным ожиданием". Но, как ни странно, эта проблема разрешима.
Великие умы, на то и умы, то не оставят такой беспредел активного ожидания в покое. Поэтому были реализованы механизмы, которые "усыпляют" процесс, исключают его из списка планировщика до тех пор, пока он не потребуется. Название у таких механизмов довольно подходит по смыслу: "семафор" и "мьютекс". Как бы что-то, что способно устанавливать порядок выполнения процессов. Но даже, и эти механизмы способны породить проблемы, только уже другого рода. Если мы выстроим процессы в замкнутый круг, что работа каждого будет выполняться только после работы следующего, то мы получим "заклинивание" или "тупик". Ни один из процессов не будет работать, так как ожидает предыдущего. Если подумать, то эту проблему разрешить можно, просто разомкнув цикл. Да. Так зачем же я ей упомянул? Дело в том, что наряду с этим, возникает и аналогичной природы проблема, называнная "ресурсным голоданием". Это тот случай, когда вся программа вроде бы и работает, а значительная часть её процессов выполнять работу не могут. Процессы ожидают пока им разрешат произвести чтение какой-нибудь общей переменной, и ожидать они могут вечно, абсолюно никак не работая. Это более подлая проблема, ведь "тупик" можно легко обнаружить, а "ресурсное голодание" может быть и невидимым. Получается, что свиду программа и работает, но большая часть её процессов благополучно спят в очереди, вероятно, изредко пробуждаясь. Это не может не отразиться на общей производительности: если у тебя параллельные процессы вырождаются, превращаясь в слепые изредка работающие фрагменты, то это явно не будет лучше, чем если бы программа состояла из одного процесса, который что-то выполняет последовательно.
И эта проблема тоже разрешима. Правда, с каждым таким "разрешением проблемы", параллельное программирование становиться всё более узкоспециализированным инструментом. Количество параллельных процессов - не равно увеличение производительности. и даже наоборот, паралельное программирование требует особого внимания и подхода, чтобы эту самую производительность не ухудшить. Можно догадаться, что некоторым программам и вовсе, параллельный процесс нужен будет только во вспомогательных целях.
Таким образом, покупая себе Xeon с 32 ядер и 64 потоков, скорее всего, для десктопного ПК никакого роста производительности не будет. Количество ядер наверняка жизненно необходимы серверам, но для десктопа хватит и восьми. Что же на самом деле влияет на производительность? Столяров считает, что пропускная способность шины. Любители игр скажут, что видеокарта. А, я, отличусь дебилизмом, и скажу что решает SSD диск. Нет, ну вправду, я перешёл с HDD диска на SSD, и все файлы стали будто бы в два раза быстрее переноситься.
В детстве, среди школьников из богатых семей часто можно было услышать тёрки:
-а у тебя компьютер сколько ядер
-у меня - два
-а у меня - три!
-врёшь, трёх ядер не бывает!
-бывает! у меня самый новый! там даже виндоус 7
Услышав один раз такой диалог, я на всю жизнь усвоил негласную истину: чем ядер больше, тем мощнее компьютер. А ведь всё это время, я даже отдалённо не представлял, что же такое эти "ядра".
Ядро процессора, при поверхностном погружении можно воспринимать как отдельный процессор. Четыре ядра - четыре отдельных процессора.
Для выполнения одной программы достаточно всего одного процессора - программа будет выполняться последовательно команда за командой, как если бы мы написали список того, что должен сделать наш компьютер. Другие процессоры такой программе и не нужны - они всё равно никак не заставят эту программу работать быстрее. Гораздо более важной характеристикой процессора, для одной одинокой программы, являлась бы частота - чем больше тактов в секунду, тем быстрее считывались бы команды.
Современные программы практически никогда из себя не представляют одну одинокую последовательность команд. Различные последовательности команд работают параллельно, зачастую взаимодействуя друг с другом. Процессор уделяет каждой последовательности определённое количество тактов, а затем переключается выполнять другую последовательность. Если параллельных программ станет слишком много, то процессор будет вынужден уделять по одному такту каждой программе, и в результате все программы будут выполняться намного медленнее. Что для этого можно сделать? Взять ещё процессоров, и распределить работу среди них, чтобы каждой программе уделялось больше тактов.
Так что, неужели чем больше ядер - тем больше мощь? Полгода назад, я бы такой вывод и сделал. Но прочитав про семафоры, мьютексы и критическую секцию, я делаю вывод, что с параллельными программами не всё так гладко, особенно в той части, когда программы зависят друг от друга. Очевиднийшеми проблемами является всеми известная "ситуация гонки". Представим три параллельные программы, с общей переменной X. Первые две программы увеличивают значение переменной X на один, а третья выводит эту переменную на экран. На интуитивном уровне, кажется что результат работы этой программы будет равен 2: два процесса добавили по единице, а третий процесс всё это вывел. Но, не тут-то было... Результат вполне может быть 1 или даже 0. Дело в том, что мы не знаем какой из процессов, планировщик завершит первым. Мы не знаем, и не должны знать, в какой последовательности будут выполняться этапы: может все три такта пойдут на первую программу, или быть может один такт уделится на первую команду первой программы. а остальные два будут выполнять вторую программу.
После ознакомления с проблемой, вообще-то это даже не кажется проблемой: "программировайте нормально, и нормально будет, в чём проблема-то?". И действительно, это ведь состояние гонки - это "ошибка", а не "проблема"... Проблемы начинаются, когда эту "ошибку" начинают решать.
Первое решение, что приходит в голову: "а пусть, вот процесс который выводит всё это на экран, ничего не делает пока всё не посчиталось". Решение хорошее, вот только "ничего не делать" - это действие хоть и не трудозатратное, но такты процессора оно всё равно потребляет. Планировщику безразлично, заставил ли ты задачу ничего не делать, или работать - он всё равно выделит ей такты времени, в то время как остальные процессы выполняться не будут. Чем-то походит на ситуацию, когда к преподавателю пришли тысячи студентов которые ничего не знают: ты вроде всё учил, хочешь получить зачёт и свалить домой, а приходится прожидать длинную очередь из молчаливых студентов, тех самых что ничего не учили, и просто надеятся на милость. Как уже понятно, вполне может получиться ситуация, когда программа на параллельных процессах работает хуже, чем если бы такая программа выполнялась последовательно команда за командой: процессы просто крадут такты времени у других процессов, в то время как реальная польза от них может быть только после выполнения первых. Такая "холостая работа" называется "активным ожиданием". Но, как ни странно, эта проблема разрешима.
Великие умы, на то и умы, то не оставят такой беспредел активного ожидания в покое. Поэтому были реализованы механизмы, которые "усыпляют" процесс, исключают его из списка планировщика до тех пор, пока он не потребуется. Название у таких механизмов довольно подходит по смыслу: "семафор" и "мьютекс". Как бы что-то, что способно устанавливать порядок выполнения процессов. Но даже, и эти механизмы способны породить проблемы, только уже другого рода. Если мы выстроим процессы в замкнутый круг, что работа каждого будет выполняться только после работы следующего, то мы получим "заклинивание" или "тупик". Ни один из процессов не будет работать, так как ожидает предыдущего. Если подумать, то эту проблему разрешить можно, просто разомкнув цикл. Да. Так зачем же я ей упомянул? Дело в том, что наряду с этим, возникает и аналогичной природы проблема, называнная "ресурсным голоданием". Это тот случай, когда вся программа вроде бы и работает, а значительная часть её процессов выполнять работу не могут. Процессы ожидают пока им разрешат произвести чтение какой-нибудь общей переменной, и ожидать они могут вечно, абсолюно никак не работая. Это более подлая проблема, ведь "тупик" можно легко обнаружить, а "ресурсное голодание" может быть и невидимым. Получается, что свиду программа и работает, но большая часть её процессов благополучно спят в очереди, вероятно, изредко пробуждаясь. Это не может не отразиться на общей производительности: если у тебя параллельные процессы вырождаются, превращаясь в слепые изредка работающие фрагменты, то это явно не будет лучше, чем если бы программа состояла из одного процесса, который что-то выполняет последовательно.
И эта проблема тоже разрешима. Правда, с каждым таким "разрешением проблемы", параллельное программирование становиться всё более узкоспециализированным инструментом. Количество параллельных процессов - не равно увеличение производительности. и даже наоборот, паралельное программирование требует особого внимания и подхода, чтобы эту самую производительность не ухудшить. Можно догадаться, что некоторым программам и вовсе, параллельный процесс нужен будет только во вспомогательных целях.
Таким образом, покупая себе Xeon с 32 ядер и 64 потоков, скорее всего, для десктопного ПК никакого роста производительности не будет. Количество ядер наверняка жизненно необходимы серверам, но для десктопа хватит и восьми. Что же на самом деле влияет на производительность? Столяров считает, что пропускная способность шины. Любители игр скажут, что видеокарта. А, я, отличусь дебилизмом, и скажу что решает SSD диск. Нет, ну вправду, я перешёл с HDD диска на SSD, и все файлы стали будто бы в два раза быстрее переноситься.
https://youtu.be/lBW9vJMM2RQ
Его не смущает, что люди которые ему пишут, имеют явно позитивную симптоматику шизофрении: слуховые галлюцинации, одержимость сверхценными идеями. Есть вероятность, что Столяров спорит буквально с инвалидами, с которыми мало того, что спор заведомо бесплоден, так ещё и... это не совсем этично. Ну, старичок, отчебучил.
Информационное насилие!
Написал одной бирже идею "сделать гипертекстовую версию сайта", ответ стандартный:
>«Существует только два вида языков: те, на которые жалуются и те, которыми никто не пользуется»
???
Как будто бы я на сам язык жалуюсь а не на его обязательное использование.
Как будто бы мне синтаксис языка JS не нравится.
>1. Разработка дополнительной версии сайта и дальнейшая поддержка двух версий — трудозатратная, излишняя и напрасная идея (в нашем случае).
>2. В 2024г, создание веб-приложения с таким обильным функционалом и без тех возможностей, которые даёт нам JavaScript — равносильно уходу с рынка.
>3. JavaScript де–факто единственный язык для фронтенд–разработки в браузере, для чего он у нас и используется.
>4. Серверная среда у нас написана на нескольких (и других) языках, не переживайте за наши мощности :)
В изначальном тексте я переживал за мощности клиентских компьютеров. Гипертекст можно открыть с любого чайника, а javascript требует виртуальной машины, и соответственно операционной системы которая может весь этот бутерброд открыть.
>5. В будущем, мы думаем об открытом API и удобной документации для всех желающих.
>6. Немного статистики: за год наш сайт посетило < 0.01% пользователей без включённого в браузере JavaScript.
И вот что, стоило бы сделать? По мнению Столярова следовало бы "не связываться с этими мразями", я так понимаю, чтобы обрезать себе средства на существование и умереть с голода. Есть хоть одна биржа, которая не использует JS (важно, чтобы ещё на ней что-то покупали)? Собственно приходится использовать JS. Оставаться без еды ради идеи - грош цена таким идеям, которые не оставляют возможности вжить людям их исповедующим. Чтобы позволить себе сидеть без JS - надо быть явно не нищим.
Его не смущает, что люди которые ему пишут, имеют явно позитивную симптоматику шизофрении: слуховые галлюцинации, одержимость сверхценными идеями. Есть вероятность, что Столяров спорит буквально с инвалидами, с которыми мало того, что спор заведомо бесплоден, так ещё и... это не совсем этично. Ну, старичок, отчебучил.
Информационное насилие!
Написал одной бирже идею "сделать гипертекстовую версию сайта", ответ стандартный:
>«Существует только два вида языков: те, на которые жалуются и те, которыми никто не пользуется»
???
Как будто бы я на сам язык жалуюсь а не на его обязательное использование.
Как будто бы мне синтаксис языка JS не нравится.
>1. Разработка дополнительной версии сайта и дальнейшая поддержка двух версий — трудозатратная, излишняя и напрасная идея (в нашем случае).
>2. В 2024г, создание веб-приложения с таким обильным функционалом и без тех возможностей, которые даёт нам JavaScript — равносильно уходу с рынка.
>3. JavaScript де–факто единственный язык для фронтенд–разработки в браузере, для чего он у нас и используется.
>4. Серверная среда у нас написана на нескольких (и других) языках, не переживайте за наши мощности :)
В изначальном тексте я переживал за мощности клиентских компьютеров. Гипертекст можно открыть с любого чайника, а javascript требует виртуальной машины, и соответственно операционной системы которая может весь этот бутерброд открыть.
>5. В будущем, мы думаем об открытом API и удобной документации для всех желающих.
>6. Немного статистики: за год наш сайт посетило < 0.01% пользователей без включённого в браузере JavaScript.
И вот что, стоило бы сделать? По мнению Столярова следовало бы "не связываться с этими мразями", я так понимаю, чтобы обрезать себе средства на существование и умереть с голода. Есть хоть одна биржа, которая не использует JS (важно, чтобы ещё на ней что-то покупали)? Собственно приходится использовать JS. Оставаться без еды ради идеи - грош цена таким идеям, которые не оставляют возможности вжить людям их исповедующим. Чтобы позволить себе сидеть без JS - надо быть явно не нищим.
Наступила весна. Поднимается настроение. Так уж и быть отпишусь на пынеборде.
Дочитал второй том до конца. Третий читать не стал, так как мне показалось что было прочитано достаточно, чтобы начать практиковаться по-немногу. Конечно же, первое что меня заинтересовало, так это графика. В opengl-тредах часто натыкался на пестрые треугольники разнообразной формы. Захотелось сделать что-то подобное.
Долго не думая, я перешёл по первой ссылке обучения opengl https://habr.com/ru/articles/248153/. В этом курсе описываются общие алгоритмы по построению графических изображений. Для иллюстрации алгоритмов используется простенький файл, который позволяет отрисовывать tga изображение. Перейдя на github, я обнаружил что tgatools имеет расширение .cpp, то есть C++. Это что получается, прочитав два тома, я до сих не могу ничего сделать, и мне придётся снова читать про плюсы ? Нет уж. Прочитанная информация мало что значит. Начитавшись рассказов про программирование, можно быть разве что, литературоведом. За этим, я решил создать свою tgatool.c. Собственно, берём спецификацию .tga, и пишем в соответствии м ней программу.
Это оказалось весьма полезно. Стало приблизительно понятно, зачем нужны эти ваши malloc'и. Если создавать массив в стеке, то вся картинка будет лежать в одной стопке с переменными функции main(). Казалось бы, чего плохого? Стек - удобно. Не хватает стека? Можно дать компилятору команду, чтобы выделил побольше. Но, взять ситуацию, когда ты положил вначале переменную-указатель a, потом картину, а затем, переменную-счётчик в стек.
а,... картинка..., i.
Тогда, чтобы воспользоваться переменной i, нужно будет перелопатить все байты картинки, от a до i. Это долго. Поэтому, мы можем в стек положить указатель на картинку, а под саму картинку выделить память где-то в пространстве процесса, т. е. в куче.
Как я понял, "куча", это не хэш-таблица и не бинарное дерево. Это просто память. И уже на этом поле памяти можно реализовать любые формы доступа к ней. Кроме того, кучу можно реаллоцировать. То есть это позволяет реализовать алгоритмы билинейной интерполяции для расширения картинки. А вот в стеке от таких алгоритмов могли бы появиться проблемы.
Естественным образом укрепляются знания об указателях на указатели. Огромное количество раз я получал ошибку segmentation fault, прежде чем понял, что в функции должны принимать указатель на указатель, а не указатель на область данных. Ведь сама по себе картинка имеет тип "указатель на картинку".
Разобрался как реализовать двухмерные динамические массивы. Мне долго казалось, что a[1][2] и (а[1])[2] это разные вещи. Для этого даже нарисовал картинку, из которой следует, что на самом деле эти конструкции обозначают одно и то же.
Ну хоть что-то лучше "хелоу ворлда".
Дочитал второй том до конца. Третий читать не стал, так как мне показалось что было прочитано достаточно, чтобы начать практиковаться по-немногу. Конечно же, первое что меня заинтересовало, так это графика. В opengl-тредах часто натыкался на пестрые треугольники разнообразной формы. Захотелось сделать что-то подобное.
Долго не думая, я перешёл по первой ссылке обучения opengl https://habr.com/ru/articles/248153/. В этом курсе описываются общие алгоритмы по построению графических изображений. Для иллюстрации алгоритмов используется простенький файл, который позволяет отрисовывать tga изображение. Перейдя на github, я обнаружил что tgatools имеет расширение .cpp, то есть C++. Это что получается, прочитав два тома, я до сих не могу ничего сделать, и мне придётся снова читать про плюсы ? Нет уж. Прочитанная информация мало что значит. Начитавшись рассказов про программирование, можно быть разве что, литературоведом. За этим, я решил создать свою tgatool.c. Собственно, берём спецификацию .tga, и пишем в соответствии м ней программу.
Это оказалось весьма полезно. Стало приблизительно понятно, зачем нужны эти ваши malloc'и. Если создавать массив в стеке, то вся картинка будет лежать в одной стопке с переменными функции main(). Казалось бы, чего плохого? Стек - удобно. Не хватает стека? Можно дать компилятору команду, чтобы выделил побольше. Но, взять ситуацию, когда ты положил вначале переменную-указатель a, потом картину, а затем, переменную-счётчик в стек.
а,... картинка..., i.
Тогда, чтобы воспользоваться переменной i, нужно будет перелопатить все байты картинки, от a до i. Это долго. Поэтому, мы можем в стек положить указатель на картинку, а под саму картинку выделить память где-то в пространстве процесса, т. е. в куче.
Как я понял, "куча", это не хэш-таблица и не бинарное дерево. Это просто память. И уже на этом поле памяти можно реализовать любые формы доступа к ней. Кроме того, кучу можно реаллоцировать. То есть это позволяет реализовать алгоритмы билинейной интерполяции для расширения картинки. А вот в стеке от таких алгоритмов могли бы появиться проблемы.
Естественным образом укрепляются знания об указателях на указатели. Огромное количество раз я получал ошибку segmentation fault, прежде чем понял, что в функции должны принимать указатель на указатель, а не указатель на область данных. Ведь сама по себе картинка имеет тип "указатель на картинку".
Разобрался как реализовать двухмерные динамические массивы. Мне долго казалось, что a[1][2] и (а[1])[2] это разные вещи. Для этого даже нарисовал картинку, из которой следует, что на самом деле эти конструкции обозначают одно и то же.
Ну хоть что-то лучше "хелоу ворлда".
Реализовал возможность открыть существующие .tga файлы. Функция сначала читает заголовок, затем заносит полученные данные в структуру header. По имеющимся данным о высоте и длине изображения создаётся холст. После этого, на холст записываются байты, порциями по 4 штуки. Открытая на чтение картинка, закрывается, а функция возвращает указатели на созданные области памяти.
Также сегодня, мной, был реализован алгоритм Брезенхема, для отрисовки линий.
Поначалу, я решил вообще забить на эти алгоритмы и реализовать отрисовку линий по их маиематическому уравнению. Примерно вот так:
х = (y - y0) / (y1 - y0) × (x1 - x0) + x0
Если попробовать таким алгоритмом нарисовать линию от угла до центра холста, то результат будет следующий: красная вертикальная линия + точка в середине экрана. Не удивительно, ведь в уравнении используются только целые числа, а значит результат деления (y - y0) / (y1 - y0) будет равен нулю всегда, за исключением самой последней точки.
Тогда можно выразить уравнение в процентах:
х = (((y - y0)×100) / (y1 - y0) × (x1 - x0))/100 + x0
Уже лучше. Линия вырисовывается, но с некоторыми "пробелами".
Намного более удачный результат позволяет получить алгоритм Брезенхема. В Википедии приведено сразу два алгоритма: с использованием чисел с плавающей точкой, и без них. Первый по сути иллюстративный. Он нужен лишь для того, чтобы проще было понять целочисленную версию.
Если взять линию, наклоном меньше 45°, не сложно заметить, что в растровом виде, она представляет собой "ступеньки". Представим, что мы строим ступени проходя по горизонтальной оси. Тогда, на каждом шаге, мы неизбежно будем делать одно из двух: либо ставить новую ступень, тем самым "увеличивая высоту", либо сделаем небольшое "плато". Принять решение о том, наращивать ли частоту, мы можем исходя из коэффициента наклона k, из школьной формулы:
x = k×y
Или попросту "тангенса угла наклона". Что меня удивило, так это то, как алгоритм выражает эту формулу. На каждой итерации Y увеличивается на 1, стало быть k будет увеличиваться как k++. То есть ни k ни y, не связаны формулами "в лоб". Действие этой формулы "зашито" в алгоритм.
Версию с плавающей точкой реализовывать я не стал, так как боюсь таких чисел. У меня не укладывается в голове "а как из дискретных битов можно сделать что-то непрерывное?". Потому, числа с плавающей точкой - это какая-то магия к которой лучше лишний раз не прикасаться.
Дискретный алгоритм намного интереснее. В нем, каждую итерацию, смело прибавляется полная "высота", вместо тангенса. И если накопленное значение превышает ширину, то тогда мы поднимаемся на "ступень". То есть теперь и вычисление тангенса тоже проводится без формул, а чисто самим алгоритмом на основании высоты и ширины.
Алгоритм был придуман в 60-х годах. Будто бы его создатель писал на ассемблере, размышляя в категориях команд, а не формул.
Больше всего времени у меня ушло на то, чтобы "отзеркалить" алгоритм. Как уже было упомянуто, он работает толь с линиями углом наклона меньше 45. А что происходит при большем? На большем наклоне, очевидно, ширина треугольника меньше чем его высота. Переменная Y, просто не сможет превысить X.
Догадаться как исправить это не составляет труда. Надо всего лишь поменять X Y местами, перед тем как закрасить пиксель по координатам. У меня производится это в три этапа:
1)Задетектить угол более 45 градусов
2)Повернуть заданную линию на 90° так, чтобы она составляла менее 45°, т.е заставить алгоритм корректно работать. Достигается это перестановкой x1 x0, y1 и y0.
3) Если детектор превышения 45 градусов был включен, тогда записывать массив холста в порядке y, x, (в противном случае записывается x, y, как обычно).
Собственно, это не заняло большого труда.
Огромную часть дня, я потратил на то, чтобы отзеркалить линии на 180°. Не знаю почему именно это заняло так много времени.
Описанная выше функция не способна рисовать линии в обратном порядке. Если дать ей на вход координаты 300 300 0 0, то результат будет абсолютно нулевой. Вначале, я не понял в чем проблема. Потом я решил вставить функцию printf, в цикл, для того чтобы понять какие числа там вообще крутятся. Ответ: никакие. Цикл даже не запустится. А всё потому что цикл может идти от 0 до 300, но никак не от 300 до нуля. Одно из решений: заменить 300 300 0 0, на 0 0 300 300. Результат ведь одинаков, разница лишь в порядке точек. Но как это сделать? Как определить что какое-то число не подходит, а какое-то подойдёт. Для этого, все возможные пары точек можно представить векторами. Параллельный перенос вектора не изменяет его направления, поэтому любой отрезок можно представить в системе координат, где хотя бы одна точка лежит на оси. На втором рисунке изображены все уникальные отрезки , что можно дать в функцию в качестве параметра. Остальные отрезки представляли бы полутона, и параллельные переносы уникальных векторов. Из рисунка можно интуитивно вычленить оси симметрии. Первая из которых определяется условием
(x0 + y1) = (y0 + x1)
а вторая:
(x0 + x1) = (y0 + y1)
Тогда, при помощи операций сравнения можно и создать множества отрезков.
Собственно, это и является условием для симметрии. Для "серого множества" x0, y0 и y1 и x0 будут менятся местами. А для второго, соответственно - нет.
Теперь всё работает, можно переходить к 3D.
Также сегодня, мной, был реализован алгоритм Брезенхема, для отрисовки линий.
Поначалу, я решил вообще забить на эти алгоритмы и реализовать отрисовку линий по их маиематическому уравнению. Примерно вот так:
х = (y - y0) / (y1 - y0) × (x1 - x0) + x0
Если попробовать таким алгоритмом нарисовать линию от угла до центра холста, то результат будет следующий: красная вертикальная линия + точка в середине экрана. Не удивительно, ведь в уравнении используются только целые числа, а значит результат деления (y - y0) / (y1 - y0) будет равен нулю всегда, за исключением самой последней точки.
Тогда можно выразить уравнение в процентах:
х = (((y - y0)×100) / (y1 - y0) × (x1 - x0))/100 + x0
Уже лучше. Линия вырисовывается, но с некоторыми "пробелами".
Намного более удачный результат позволяет получить алгоритм Брезенхема. В Википедии приведено сразу два алгоритма: с использованием чисел с плавающей точкой, и без них. Первый по сути иллюстративный. Он нужен лишь для того, чтобы проще было понять целочисленную версию.
Если взять линию, наклоном меньше 45°, не сложно заметить, что в растровом виде, она представляет собой "ступеньки". Представим, что мы строим ступени проходя по горизонтальной оси. Тогда, на каждом шаге, мы неизбежно будем делать одно из двух: либо ставить новую ступень, тем самым "увеличивая высоту", либо сделаем небольшое "плато". Принять решение о том, наращивать ли частоту, мы можем исходя из коэффициента наклона k, из школьной формулы:
x = k×y
Или попросту "тангенса угла наклона". Что меня удивило, так это то, как алгоритм выражает эту формулу. На каждой итерации Y увеличивается на 1, стало быть k будет увеличиваться как k++. То есть ни k ни y, не связаны формулами "в лоб". Действие этой формулы "зашито" в алгоритм.
Версию с плавающей точкой реализовывать я не стал, так как боюсь таких чисел. У меня не укладывается в голове "а как из дискретных битов можно сделать что-то непрерывное?". Потому, числа с плавающей точкой - это какая-то магия к которой лучше лишний раз не прикасаться.
Дискретный алгоритм намного интереснее. В нем, каждую итерацию, смело прибавляется полная "высота", вместо тангенса. И если накопленное значение превышает ширину, то тогда мы поднимаемся на "ступень". То есть теперь и вычисление тангенса тоже проводится без формул, а чисто самим алгоритмом на основании высоты и ширины.
Алгоритм был придуман в 60-х годах. Будто бы его создатель писал на ассемблере, размышляя в категориях команд, а не формул.
Больше всего времени у меня ушло на то, чтобы "отзеркалить" алгоритм. Как уже было упомянуто, он работает толь с линиями углом наклона меньше 45. А что происходит при большем? На большем наклоне, очевидно, ширина треугольника меньше чем его высота. Переменная Y, просто не сможет превысить X.
Догадаться как исправить это не составляет труда. Надо всего лишь поменять X Y местами, перед тем как закрасить пиксель по координатам. У меня производится это в три этапа:
1)Задетектить угол более 45 градусов
2)Повернуть заданную линию на 90° так, чтобы она составляла менее 45°, т.е заставить алгоритм корректно работать. Достигается это перестановкой x1 x0, y1 и y0.
3) Если детектор превышения 45 градусов был включен, тогда записывать массив холста в порядке y, x, (в противном случае записывается x, y, как обычно).
Собственно, это не заняло большого труда.
Огромную часть дня, я потратил на то, чтобы отзеркалить линии на 180°. Не знаю почему именно это заняло так много времени.
Описанная выше функция не способна рисовать линии в обратном порядке. Если дать ей на вход координаты 300 300 0 0, то результат будет абсолютно нулевой. Вначале, я не понял в чем проблема. Потом я решил вставить функцию printf, в цикл, для того чтобы понять какие числа там вообще крутятся. Ответ: никакие. Цикл даже не запустится. А всё потому что цикл может идти от 0 до 300, но никак не от 300 до нуля. Одно из решений: заменить 300 300 0 0, на 0 0 300 300. Результат ведь одинаков, разница лишь в порядке точек. Но как это сделать? Как определить что какое-то число не подходит, а какое-то подойдёт. Для этого, все возможные пары точек можно представить векторами. Параллельный перенос вектора не изменяет его направления, поэтому любой отрезок можно представить в системе координат, где хотя бы одна точка лежит на оси. На втором рисунке изображены все уникальные отрезки , что можно дать в функцию в качестве параметра. Остальные отрезки представляли бы полутона, и параллельные переносы уникальных векторов. Из рисунка можно интуитивно вычленить оси симметрии. Первая из которых определяется условием
(x0 + y1) = (y0 + x1)
а вторая:
(x0 + x1) = (y0 + y1)
Тогда, при помощи операций сравнения можно и создать множества отрезков.
Собственно, это и является условием для симметрии. Для "серого множества" x0, y0 и y1 и x0 будут менятся местами. А для второго, соответственно - нет.
Теперь всё работает, можно переходить к 3D.
Долго думал "а как бы реализовать защиту от выхода за рамки холста?". Ведь у пользователя имеется возможность задать любую линию, даже скажем (0,0)(106, 105). И что? Программа будет считать все миллион циклов вхолостую?
Ладно. Будем считать, что пользователь знает что делает, и нарочно выходить за рамки холста уж точно не будет. Но ведь функцией tga_draw_line() может воспользоваться другая программа. Например, если мы отрисовываем 3D модель с определённого ракурса, то в ней будет много полнигонов, находящихся за пределами холста. Тратить время на их отрисовку - уже ошибка. Поэтому необходимо придумать способ "отбросить лишнее".
Я долго над этим думал. Ничего толкового в голову так и не пришло. За неимением хороших идей, решил реализовать плохие.
Перейдём в самый конец функции, к алгоритму Безенхема. Этот участок удобен тем, что координаты начальных точек находятся в состоянии "до симметрии". В такой системе координат, у нас есть только два типа линий: прямые пологие возрастающие, и прямые пологие убывающие. Линии больше ±45° отсутствуют, как и линии с координатами в обратном направлении. Тогда сходу можно отсеять группу "лишних" - линии у которых обе координаты x0, x1 больше ширины холста, либо линии у которых координаты y0, y1, больше высоты холста. Если программа встречает такую линию, то сразу можно сделать return 0, то есть программа завершила работу успешно - ничего отрисовывать и не требуется.
Идём дальше. Раз уж наша функция не завершила работу, значит, скорее всего линия может быть частично отрисована. Если бы мы имели дело только с возрастающими линиями, то можно было бы просто остановить цикл на итерации, когда X равен ширине холста. Грубо говоря, просто "отрезать" кусок линии, когда он выходит за рамки. Но у нас есть и убывающие линии, которые изначально могут начинаться за рамками холста. Следовательно, мы должны каким-то образом уничтожить "начальную часть". Как мне показалось, единственное, что можно сделать, так это найти точку пересечения края холста и линии. Тогда возникает проблема: целочисленное деление. Для того, чтобы найти коэффициент линейного уравнения, необходимо вычислить тангенс угла наклона, то есть дробь. Эту проблему я никак не решил, и так и оставил с ошибкой. На удивление, это дало и не такой уж плохой результат. В общем виде, с учётом смещения уравнение принимает вид:
x = (y-y0)/(y1-y0)×(x1-x0)+x0
В качестве Y, подставляем значение высоты холста:
x = (WIDTH(img)-y0)/(y1-y0)×(x1-x0)+x0
Если домножить уравнение на (y1-y0), то это избавит нас от целочисленного деления, на первых порах:
x×(y1-y0) = (WIDTH(img)-y0)×(x1-x0)+x0×(y1-y0)
Программа вычисляет x×(y1-y0), а потом уже задумывается как бы это всё правильно поделить. Если x×(y1-y0) делится на (y1-y0), без остатка, то проблем нет. Если остаток есть, то нужно понять сколько он занимает от знаменателя. Например, 7/3 = 2+(1/3). Если 3/1 больше единицы, значит знаменатель помещается в числитель хотя бы два раза, и следовательно 1 занимает меньше половины от тройки. В таком случае можно округлить результат в меньшую сторону. Возьмём противоположный пример 7/4 =1+(3/4). Поделим 4/3 - результат "единица", следовательно знаменатель вмещается в числитель меньше нескольких раз, а значит это уже половина и больше. Наверное, для большей точности так можно проделать несколько раз с остатками от остатков, но в любом случае, смысла это не имеет, ведь несёт за собой определённую погрешность, то есть программа заведомо может выдать ошибочный результат.
Чтож. Пока что пусть будет так.
Зато теперь наша программа умеет начинать отрисовку с точки пересечения холста и линии.
Если холст пересекается два раза, то можно применить метод "нахождения пересечения", а оставшийся кусок "отрезать", как если бы он был линией с "началом на холсте". Вроде бы всё. Проблема решена.
Но существует ещё один исключительный случай: когда казалось бы, и один из иксов лежит в пределах ширины, и один из игреков лежит в пределах высоты, но линия никак не пересекает холст. В таком случае, в алгоритм "вычисление точки пересечения" можно добавить условие: если найденная точка пересечения имеет координату X, большую чем ширина холста, то можно завершить работу по причине "рисовать нечего".
На этом всё. Вроде работает. Около 8 отрезков я ей скормил, - отрисовывает правильно. Завтра надо скормить ей все варианты отрезков. Чтобы уж точно убедиться.
Если всё работает, то можно так и оставить.
Ладно. Будем считать, что пользователь знает что делает, и нарочно выходить за рамки холста уж точно не будет. Но ведь функцией tga_draw_line() может воспользоваться другая программа. Например, если мы отрисовываем 3D модель с определённого ракурса, то в ней будет много полнигонов, находящихся за пределами холста. Тратить время на их отрисовку - уже ошибка. Поэтому необходимо придумать способ "отбросить лишнее".
Я долго над этим думал. Ничего толкового в голову так и не пришло. За неимением хороших идей, решил реализовать плохие.
Перейдём в самый конец функции, к алгоритму Безенхема. Этот участок удобен тем, что координаты начальных точек находятся в состоянии "до симметрии". В такой системе координат, у нас есть только два типа линий: прямые пологие возрастающие, и прямые пологие убывающие. Линии больше ±45° отсутствуют, как и линии с координатами в обратном направлении. Тогда сходу можно отсеять группу "лишних" - линии у которых обе координаты x0, x1 больше ширины холста, либо линии у которых координаты y0, y1, больше высоты холста. Если программа встречает такую линию, то сразу можно сделать return 0, то есть программа завершила работу успешно - ничего отрисовывать и не требуется.
Идём дальше. Раз уж наша функция не завершила работу, значит, скорее всего линия может быть частично отрисована. Если бы мы имели дело только с возрастающими линиями, то можно было бы просто остановить цикл на итерации, когда X равен ширине холста. Грубо говоря, просто "отрезать" кусок линии, когда он выходит за рамки. Но у нас есть и убывающие линии, которые изначально могут начинаться за рамками холста. Следовательно, мы должны каким-то образом уничтожить "начальную часть". Как мне показалось, единственное, что можно сделать, так это найти точку пересечения края холста и линии. Тогда возникает проблема: целочисленное деление. Для того, чтобы найти коэффициент линейного уравнения, необходимо вычислить тангенс угла наклона, то есть дробь. Эту проблему я никак не решил, и так и оставил с ошибкой. На удивление, это дало и не такой уж плохой результат. В общем виде, с учётом смещения уравнение принимает вид:
x = (y-y0)/(y1-y0)×(x1-x0)+x0
В качестве Y, подставляем значение высоты холста:
x = (WIDTH(img)-y0)/(y1-y0)×(x1-x0)+x0
Если домножить уравнение на (y1-y0), то это избавит нас от целочисленного деления, на первых порах:
x×(y1-y0) = (WIDTH(img)-y0)×(x1-x0)+x0×(y1-y0)
Программа вычисляет x×(y1-y0), а потом уже задумывается как бы это всё правильно поделить. Если x×(y1-y0) делится на (y1-y0), без остатка, то проблем нет. Если остаток есть, то нужно понять сколько он занимает от знаменателя. Например, 7/3 = 2+(1/3). Если 3/1 больше единицы, значит знаменатель помещается в числитель хотя бы два раза, и следовательно 1 занимает меньше половины от тройки. В таком случае можно округлить результат в меньшую сторону. Возьмём противоположный пример 7/4 =1+(3/4). Поделим 4/3 - результат "единица", следовательно знаменатель вмещается в числитель меньше нескольких раз, а значит это уже половина и больше. Наверное, для большей точности так можно проделать несколько раз с остатками от остатков, но в любом случае, смысла это не имеет, ведь несёт за собой определённую погрешность, то есть программа заведомо может выдать ошибочный результат.
Чтож. Пока что пусть будет так.
Зато теперь наша программа умеет начинать отрисовку с точки пересечения холста и линии.
Если холст пересекается два раза, то можно применить метод "нахождения пересечения", а оставшийся кусок "отрезать", как если бы он был линией с "началом на холсте". Вроде бы всё. Проблема решена.
Но существует ещё один исключительный случай: когда казалось бы, и один из иксов лежит в пределах ширины, и один из игреков лежит в пределах высоты, но линия никак не пересекает холст. В таком случае, в алгоритм "вычисление точки пересечения" можно добавить условие: если найденная точка пересечения имеет координату X, большую чем ширина холста, то можно завершить работу по причине "рисовать нечего".
На этом всё. Вроде работает. Около 8 отрезков я ей скормил, - отрисовывает правильно. Завтра надо скормить ей все варианты отрезков. Чтобы уж точно убедиться.
Если всё работает, то можно так и оставить.
Сделал некий черновик парсера .obj файлов.
Результат на первой картинке. Удовлетворительно: рисует что-то правдоподобное, но не без ошибок.
Данная программа открывает файл wavefront .obj на чтение, и считывает количество строк, начинающихся на "v". Распознание строчки, происходит следующим образом: изначально переменная line_type имеет значение "undefined" (0). Затем, если из потока был взят символ "v", она меняет значение на "vertex", то есть, "строка точек". При получении символа '\n', строка снова получает тип "неопределённая". Кроме наимееований "точки" и "неопределённая", строка может быть "комментарием" или "полигоном".
Полигоны не могут существовать без точек. Поэтому, подсчёт точек можно завершить, когда был встречен хотя бы один полигон.
Зачем вообще нужно считать точки? Изначально, я предполагал, что программа не должна захламлять область памяти в ОЗУ. Поток ведь открыт, можно перемещаться по нему при помощи fseek(), следовательно любой алгоритм можно реализовать без выделения памяти. У такого подхода есть минус: полигоны могут занимать случайные точки(топология ведь может быть произвольной), следовательно мы не можем брать точки просто в порядке возрастания. В свою очередь, это означает, что нам пришлось бы перебирать все точки в поисках нужной, для того, чтобы отрисовать линию, а это долго. Возникает потребность обращаться к точкам "по индексу".
Как вариант реализации этой потребности: сделать двусвязный список. Тогда, можно было собрать сколь угодно точек в этот список, и далее уже обращаться к нему. Плюс данного решения: не требуется подсчитывать точки. Они сами себя считают и заносят в список. Минус данного решения: обильное количество указателей в ОЗУ, а также необходимость создания алгоритмов поиска точки нужного индекса в списке.
Поэтому, я поступил иначе. Я, вначале, сосчитал сколько у нас точек имеется вообще. Затем создал массив из массивов с двумя элементами (первый элемент x, второй y), и выделил под него память, равную (количество точек) ×2. Потом, вернулся в начало файла, и начал чтение сначала, но уже записывая точки в соответствующие ячейки массива.
На этот раз, после прочтения точек наша программа идёт дальше. Полигон представляет из себя набор из минимум трёх индексов (в данном случае всегда 4. Я следил за топологией при создании модели). Собственно, программа должна через каждые две точки нарисовать линию, тогда у нас и получится изображение полигона. На этом месте наверняка и лежит ошибка. Так как сейчас вечер, я по-быстрее хотел получить результат, и сделал несколько нелепый алгоритм: попарно считываются точки Х-1, 1-2, 2-3, 3-4. Как видно, первая пара некорректная, а последней нет. Полигон получается "не замкнут". Решение:
1.Первую пару просто убрать, вставив для этого логическую переменную.
2. У второй пары запомнить первую точку.
3. Как только считаются все точки из строки, добавить дополнительную пару с последней и первой точкой. Итого:
1-2, 2-3, 3-4, 4-1.
В общем-то, это всё что я сделал.
Функция принимает два параметра: указатель на подгруженное tga-изображение, и имя 3d файла, которое нужно отрисовать.
Для полноты картины, следовательно бы добавить параметр "плоскости камеры" или "нормального вектора плоскости камеры", чтобы можно было отрисовывать модель под заданным углом. Точки просто бы проецировались на эту плоскость. Аксонометрия.
Ещё неплохо было бы сделать параметр масштаба, реализовать алгоритм который считывает и цифры после десятичной точки.
Результат на первой картинке. Удовлетворительно: рисует что-то правдоподобное, но не без ошибок.
Данная программа открывает файл wavefront .obj на чтение, и считывает количество строк, начинающихся на "v". Распознание строчки, происходит следующим образом: изначально переменная line_type имеет значение "undefined" (0). Затем, если из потока был взят символ "v", она меняет значение на "vertex", то есть, "строка точек". При получении символа '\n', строка снова получает тип "неопределённая". Кроме наимееований "точки" и "неопределённая", строка может быть "комментарием" или "полигоном".
Полигоны не могут существовать без точек. Поэтому, подсчёт точек можно завершить, когда был встречен хотя бы один полигон.
Зачем вообще нужно считать точки? Изначально, я предполагал, что программа не должна захламлять область памяти в ОЗУ. Поток ведь открыт, можно перемещаться по нему при помощи fseek(), следовательно любой алгоритм можно реализовать без выделения памяти. У такого подхода есть минус: полигоны могут занимать случайные точки(топология ведь может быть произвольной), следовательно мы не можем брать точки просто в порядке возрастания. В свою очередь, это означает, что нам пришлось бы перебирать все точки в поисках нужной, для того, чтобы отрисовать линию, а это долго. Возникает потребность обращаться к точкам "по индексу".
Как вариант реализации этой потребности: сделать двусвязный список. Тогда, можно было собрать сколь угодно точек в этот список, и далее уже обращаться к нему. Плюс данного решения: не требуется подсчитывать точки. Они сами себя считают и заносят в список. Минус данного решения: обильное количество указателей в ОЗУ, а также необходимость создания алгоритмов поиска точки нужного индекса в списке.
Поэтому, я поступил иначе. Я, вначале, сосчитал сколько у нас точек имеется вообще. Затем создал массив из массивов с двумя элементами (первый элемент x, второй y), и выделил под него память, равную (количество точек) ×2. Потом, вернулся в начало файла, и начал чтение сначала, но уже записывая точки в соответствующие ячейки массива.
На этот раз, после прочтения точек наша программа идёт дальше. Полигон представляет из себя набор из минимум трёх индексов (в данном случае всегда 4. Я следил за топологией при создании модели). Собственно, программа должна через каждые две точки нарисовать линию, тогда у нас и получится изображение полигона. На этом месте наверняка и лежит ошибка. Так как сейчас вечер, я по-быстрее хотел получить результат, и сделал несколько нелепый алгоритм: попарно считываются точки Х-1, 1-2, 2-3, 3-4. Как видно, первая пара некорректная, а последней нет. Полигон получается "не замкнут". Решение:
1.Первую пару просто убрать, вставив для этого логическую переменную.
2. У второй пары запомнить первую точку.
3. Как только считаются все точки из строки, добавить дополнительную пару с последней и первой точкой. Итого:
1-2, 2-3, 3-4, 4-1.
В общем-то, это всё что я сделал.
Функция принимает два параметра: указатель на подгруженное tga-изображение, и имя 3d файла, которое нужно отрисовать.
Для полноты картины, следовательно бы добавить параметр "плоскости камеры" или "нормального вектора плоскости камеры", чтобы можно было отрисовывать модель под заданным углом. Точки просто бы проецировались на эту плоскость. Аксонометрия.
Ещё неплохо было бы сделать параметр масштаба, реализовать алгоритм который считывает и цифры после десятичной точки.
Появилось понимание того, что должна представлять из себя tgatool.c. Можно стереть весь говнокод, и начать всё заново, но уже делать качественно, а не "лишь бы заработало". За одно научится пользоваться дебагером.
Структура следующая, программа делится на три уровня "абстрактный", "фундаментальный" и "прикладной".
1.Абстрактный уровень
На данном уровне описываются конструкции, полностью свободные от параметров конкретного изображения. То есть функции из данного уровня предназначены для работы с изображением, как с абстракцией.
1.1 struct header - заголовок изображения. Представляет собой набор полей, по одному (иногда двум) байтам. Каждое поле может содержать какую-то информацию об изображении. Подробнее смысл каждого поля описан в документации. Заголовок одинаков по длине для всех .tga изображений.
(!)1.2 int ⚹⚹canvas - указатель на указатель на тип int. В будущем, при инициализации, получится двухмерный динамический массив. Но пока что это просто абстрактный "указатель". Тут есть проблемка которая ставит под сомнение его "абстрактность". А именно эта проблема - тип int. Мы ведь объявили, что в конечном счёте элементы массива будут иметь тип int - 4 байта. Другими словами: в одной ячейке вмещается цвет в 4 байта: 0xff001122. Что это? это глубина пикселей pixel depth в 24 бит (остальные 8 на альфа-канал). Значит наш холст, уже рассчитан под конкретное изображение. Решение проблемы "в лоб", это просто перенести конструкцию в раздел 2, и создавать переменную уже в зависимости от типа изображения. Но мне захотелось перенести эту конструкцию в первый раздел, чтобы задуматься над более экзотическими вариантами создания "холста".
1.3 header ⚹init_header(header ⚹header_var) - Функция создаёт область памяти для заголовка. Возвращает указатель на эту область в случае успеха, либо NULL, если аллоцировать память не удалось.
1.4 int grab_header(FILE⚹ opened_img, header ⚹⚹result). Функция считывает из файла, открытого на поток, первые байты, и заносит из в заголовок. Если данные заголовка принимают корректные значения, то функция завершается возвращая текущее смещение в потоке. Если же заголовок не может быть прочитан до конца, или же заголовок неклрректный, то, все возвращается на свои места, функция возвращает 0.
1.3 void free_header(header header_var⚹). Освобождает выделенную ранее память под заголовок. Возвращает "ничего". Как бы странно это не звучало, но я только сейчас задумался: "а что возвращает функция free()? Может ли она неудачно высвободить память?".
2.Фундаментальный уровень.
На данном этапе, берётся в расчёт, что мы уже можем работать с "какими то" изображениями, и нам следует углубится в подробности "а что это изображения". Тут учитывается и глубина пикселей, и тип, и размеры.
2.1 enum img_type {grayscale, rgb8, rgb16, rgb24}. Перечисляемый тип. Используется для удобного указания на вид изображения.
2.2 int generate_header(header ⚹header_var, enum img_type, short w, short h). Если в заголовок неиницализирован, то функция его инициализирует, а затем записывает туда данные полей, конкретного вида изображения, а также ширину и высоту изображения. Согласно документации, на поле "ширина" и поле "высота" изображения выделено по два байта, поэтому я поставил тип short. Функция возвращает 0 при успешном выполнении.
2.3 enum img_type analyze_header(header ⚹existing_header). Функция читает заголовок, и возвращает ответ на вопрос "что это за вид изображения соответствует этому заголовку" . Мне показалось, что эта функция могла бы быть полезной в некоторых случаях, но не более. Естественно, без неё можно обойтись.
(!) 2.4 int ⚹⚹init_canvas(int ⚹⚹canvas_ptr) . Не существующая функция. Предполагалось, что вот на данном этапе уже будет известна глубина пикселей в изображении. И эта функция нужна чтобы аллоцировать двумерный массив того типа, который подходит к pixeldepth. Но о существовании таких возможностей я не слышал, поэтому пока что она просто выделяет память под двумерный массив.
2.5 void set_pixel(int ⚹⚹canvas, short x, short y). Процедура рисует пиксель на холсте, по заданным координатам. Не имеет проверок на ошибки, так как предполагает чисто техническое использование. То есть, эта процедура никогда не будет вызвана пользователем напрямую, о чем и говорит параметр "canvas" - рисует то она на холсте, а не на картине.
2.6 int color(char red, char blue, char green, char alpha, enum img_type pixel_depth). Профиль этой функции говорит сам за себя: возвращает значение цвета rgb, для того формата, что мы захотим.
2.7 void free_canvas(int ⚹⚹canvas). Очевидно, освобрждает аллоцированый холст.
3.Прикладной уровень.
На данном этапе реализуются функции, которые доступны для пользователя. То есть, вот это и есть итоговый набор функций.
3.1 struct image. Структура, которая содержит в себе и заголовок и холст одновременно. По сути это тип "изображение".
3.2 int draw_pixel(struct image ⚹image, short x, short y). Аналог функции set_pixel(), но только на вход она принимает уже тип "изображение", а не тип "холст". Также она контролирует, чтобы изображение не вышло за рамки холста, в случае чего сообщает об ошибке.
3.3 int draw_pixel(struct image ⚹image, int color). Заполняет весь холст цветом.
3.4 image ⚹create_img(image ⚹img_var, short w, short h, enum img_type type). Эта функция аллоцирует память целиком для всего изображения: и для заголовка и для холста.
3.5 void eject_img(image ⚹img). Процедура, которая бы убирала область памяти изображения, холста, и заголовка. Эдакий free() для всего изображения.
3.6 image ⚹open_img(char[] filename, image ⚹img_var). Функция, которая бы записывала данные с картинки на жёстком диске в картинку в ОЗУ.
3.7 int save_img(image ⚹ img_var, char[] filename). Функция, которая записывает изображение из ОЗУ на жёсткий диск.
3.8 int draw_line(image ⚹ img_var, short x0, short y0, short x1, short y1). Алгоритм безкнхема, со всеми подводными. Правда, выход за холст лучше классифицировать как ошибку, ведь тогда появляется возможность отследить когда линии рисуются не на холсте. Это может быть полезным.
3.9 int draw3d_wavefront(image ⚹ img_var, char[] model3d_filename, int scale, int[3] rotation). . Отрисовка 3д объекта в аксонометрии.
Далее программа будто бы "расплывается" на несколько других. Если уходить дальше в 2D/3D графику, то весь акцкнт уходит от формата TGA, и переходит к аналитической геометрии. То есть это уже не tgatool, а что-то другое. Поэтому, на данном этапе программу можно считать завершённой.
Структура следующая, программа делится на три уровня "абстрактный", "фундаментальный" и "прикладной".
1.Абстрактный уровень
На данном уровне описываются конструкции, полностью свободные от параметров конкретного изображения. То есть функции из данного уровня предназначены для работы с изображением, как с абстракцией.
1.1 struct header - заголовок изображения. Представляет собой набор полей, по одному (иногда двум) байтам. Каждое поле может содержать какую-то информацию об изображении. Подробнее смысл каждого поля описан в документации. Заголовок одинаков по длине для всех .tga изображений.
(!)1.2 int ⚹⚹canvas - указатель на указатель на тип int. В будущем, при инициализации, получится двухмерный динамический массив. Но пока что это просто абстрактный "указатель". Тут есть проблемка которая ставит под сомнение его "абстрактность". А именно эта проблема - тип int. Мы ведь объявили, что в конечном счёте элементы массива будут иметь тип int - 4 байта. Другими словами: в одной ячейке вмещается цвет в 4 байта: 0xff001122. Что это? это глубина пикселей pixel depth в 24 бит (остальные 8 на альфа-канал). Значит наш холст, уже рассчитан под конкретное изображение. Решение проблемы "в лоб", это просто перенести конструкцию в раздел 2, и создавать переменную уже в зависимости от типа изображения. Но мне захотелось перенести эту конструкцию в первый раздел, чтобы задуматься над более экзотическими вариантами создания "холста".
1.3 header ⚹init_header(header ⚹header_var) - Функция создаёт область памяти для заголовка. Возвращает указатель на эту область в случае успеха, либо NULL, если аллоцировать память не удалось.
1.4 int grab_header(FILE⚹ opened_img, header ⚹⚹result). Функция считывает из файла, открытого на поток, первые байты, и заносит из в заголовок. Если данные заголовка принимают корректные значения, то функция завершается возвращая текущее смещение в потоке. Если же заголовок не может быть прочитан до конца, или же заголовок неклрректный, то, все возвращается на свои места, функция возвращает 0.
1.3 void free_header(header header_var⚹). Освобождает выделенную ранее память под заголовок. Возвращает "ничего". Как бы странно это не звучало, но я только сейчас задумался: "а что возвращает функция free()? Может ли она неудачно высвободить память?".
2.Фундаментальный уровень.
На данном этапе, берётся в расчёт, что мы уже можем работать с "какими то" изображениями, и нам следует углубится в подробности "а что это изображения". Тут учитывается и глубина пикселей, и тип, и размеры.
2.1 enum img_type {grayscale, rgb8, rgb16, rgb24}. Перечисляемый тип. Используется для удобного указания на вид изображения.
2.2 int generate_header(header ⚹header_var, enum img_type, short w, short h). Если в заголовок неиницализирован, то функция его инициализирует, а затем записывает туда данные полей, конкретного вида изображения, а также ширину и высоту изображения. Согласно документации, на поле "ширина" и поле "высота" изображения выделено по два байта, поэтому я поставил тип short. Функция возвращает 0 при успешном выполнении.
2.3 enum img_type analyze_header(header ⚹existing_header). Функция читает заголовок, и возвращает ответ на вопрос "что это за вид изображения соответствует этому заголовку" . Мне показалось, что эта функция могла бы быть полезной в некоторых случаях, но не более. Естественно, без неё можно обойтись.
(!) 2.4 int ⚹⚹init_canvas(int ⚹⚹canvas_ptr) . Не существующая функция. Предполагалось, что вот на данном этапе уже будет известна глубина пикселей в изображении. И эта функция нужна чтобы аллоцировать двумерный массив того типа, который подходит к pixeldepth. Но о существовании таких возможностей я не слышал, поэтому пока что она просто выделяет память под двумерный массив.
2.5 void set_pixel(int ⚹⚹canvas, short x, short y). Процедура рисует пиксель на холсте, по заданным координатам. Не имеет проверок на ошибки, так как предполагает чисто техническое использование. То есть, эта процедура никогда не будет вызвана пользователем напрямую, о чем и говорит параметр "canvas" - рисует то она на холсте, а не на картине.
2.6 int color(char red, char blue, char green, char alpha, enum img_type pixel_depth). Профиль этой функции говорит сам за себя: возвращает значение цвета rgb, для того формата, что мы захотим.
2.7 void free_canvas(int ⚹⚹canvas). Очевидно, освобрждает аллоцированый холст.
3.Прикладной уровень.
На данном этапе реализуются функции, которые доступны для пользователя. То есть, вот это и есть итоговый набор функций.
3.1 struct image. Структура, которая содержит в себе и заголовок и холст одновременно. По сути это тип "изображение".
3.2 int draw_pixel(struct image ⚹image, short x, short y). Аналог функции set_pixel(), но только на вход она принимает уже тип "изображение", а не тип "холст". Также она контролирует, чтобы изображение не вышло за рамки холста, в случае чего сообщает об ошибке.
3.3 int draw_pixel(struct image ⚹image, int color). Заполняет весь холст цветом.
3.4 image ⚹create_img(image ⚹img_var, short w, short h, enum img_type type). Эта функция аллоцирует память целиком для всего изображения: и для заголовка и для холста.
3.5 void eject_img(image ⚹img). Процедура, которая бы убирала область памяти изображения, холста, и заголовка. Эдакий free() для всего изображения.
3.6 image ⚹open_img(char[] filename, image ⚹img_var). Функция, которая бы записывала данные с картинки на жёстком диске в картинку в ОЗУ.
3.7 int save_img(image ⚹ img_var, char[] filename). Функция, которая записывает изображение из ОЗУ на жёсткий диск.
3.8 int draw_line(image ⚹ img_var, short x0, short y0, short x1, short y1). Алгоритм безкнхема, со всеми подводными. Правда, выход за холст лучше классифицировать как ошибку, ведь тогда появляется возможность отследить когда линии рисуются не на холсте. Это может быть полезным.
3.9 int draw3d_wavefront(image ⚹ img_var, char[] model3d_filename, int scale, int[3] rotation). . Отрисовка 3д объекта в аксонометрии.
Далее программа будто бы "расплывается" на несколько других. Если уходить дальше в 2D/3D графику, то весь акцкнт уходит от формата TGA, и переходит к аналитической геометрии. То есть это уже не tgatool, а что-то другое. Поэтому, на данном этапе программу можно считать завершённой.
Не знаешь, откуда второе видео, чьего авторства? Нравится стиль
Нет, не в курсе.
(!)
Точно! существует же тип union. Тогда можно создавать указатель на указатель на тип union
union pixel canvas.
Тогда можно "менять тип": char, short и int.
Довольно глупой идеей было создать функцию init_header(). Что она может сделать? Только лишь вызвать malloc. Проверять header на существование смысла не имеет, ведь вряд-ли возможен случай, когда будет совершена попытка выделить память под существующий заголовок. Да и даже если этот случай возможен, проверка внутри функции init_header() будет весьма бесполезной, ведь проще произвести все необходимые проверки в головной функции. Так что init_header заменяется простым malloc'ом.
Вместо неё, лучше создать функцию generate_header(), которая бы создавала заголовок в зависимости от типа изображения.
К слову, о типах. Типы TGA изображений можно разделить на 2 категории: со сжатием, и без.
"Без сжатия" - это означает, что элементов памяти в картинке ровно столько, сколько в ней пикселей. По простому - матрица, в каждой ячейке которой содержится цвет.
"Со сжатием" означает, что данные о картинке, хранятся в зашифрованом виде. То есть, чтобы отобразить такую картинку, её для начала нужно расшифровать. Хранение картинки в зашифрованом виде, даёт выигрыш в свободном месте на жёстком диске. В случае формата TGA, поддерживается лишь RLE сжатие. Принцип этого сжатия заключается в том, что повторяющиеся пиксели одного цвета заменяются на один такой пиксель, и чисто его првторарий. То есть для строчка:
ddddddd
будет зависана как 7d.
Работать с картинкой в сжатом варианте, я не представляю возможным, ведь это придётся заиметь целый класс функций, способных работать в такой головоломке. Намного проще расшифровать картинку, и работать с ней. Поэтому требуется добавить также функцию encode_canvas(), которая могла бы зашифровать холст из произвольных элементов.
Итак.. Кроме наличия шифрования, типы tga изображений также подразделяются по цветности, соответственно на: палитровые, true color, и оттенки серого. Палитровая картинка отличается тем, что её холст состоит из индексов на цвета, а не из самих цветов. Наглядный пример: представим что у нас есть изображение клетчатой эмо-арафатки. На ней есть только чёрные и розовые цвета. Вдруг, нам захотелось поиграть в шахматы, и шахматной доски у нас нет, так что придётся перекрасить арафатку. Тогда приходится перекрашивать каждый розовый пиксель в белый. Вместо этого, мы бы могли заранее вместо всех разовых пикселей поставить индекс 1, а вместо чёрных 2. И тогда, нам пришлось бы заменить всего лишь значение цвета под индексом 1 на белый. С этим типом разобрались. Правда, тут возникает вопрос "а как определить глубину цвета в данном изображении". (глубина цвета - это количество бит на пиксель). По стандарту везде стомт 8 бит, так как индекс часто укладывается в char. Если изменить значение - выдаст ошибку. При этом настоящая "глубина цвета" регулируется параметрами палитры. Чъерт знает что этим хотел сказать автор данного формата.
Собственно, кроме палитрового, есть также truecolor изображение. Если верить гуглу, truecolor - это просто картинка с глубиной цвета 24 бит. Итого три байта - один на красный, второй на зелёный, третий на голубой. Карты цветов при этом игнорируются, и строго говоря, должны быть нулю. Вместо этого, программы для открытия картинок опять показывают странный результат: картинка открывается даже с глубиной цвета 16 бит, при этом, наличие карты цветов допускается. Что за черт, как это работает?.
Последнее подмножество типов, это grayscale. Оттенки серого. Собственно, в данном случае каждый байт определяет насыщенность цвета, а тон отсутствует. Странно, но программы для просмотра tga, никак не изменяют отображение картинки, если изменить заголовок на тип grayscsle. При этом открывается возможность сделать глубину цвета 8 бит. Правда, это не даёт особо ничего в плане изменения цвета: картинка икажается, но до сих пор является цветной.
Также, ничего не меняется, если выставить глубину альфа-канала на максимум (16 бит). Картинки, имеющие альфа-канал вообще то имеют параметры 32 битных truecolor, а не 24 битых truecolor, с альфа каналом в 8 бит. Переключение альфа канала ничего не даёт. При этом, практически ни одна программа, кроме feh, этот альфа-канал не отображает. Не понимаю, что это за магия.
Оставлю это на совести разработчиков программ. Самому, наверное следует работать по спецификации.
Со всем этим разнообразием опций формата, получается что лучше идти от конечного результата: вначале описать основные итоговые функции модуля, а потом уже придумывать из каких элементов одни должны состоять.
Оказалось, это не так уж и просто. В языках С типизация статическая. Это значит, что функции всегда возвращают только заранее определённый тип. И если уж хочется сделать сделать иначе, то придётся искать какие-то обходные пути. Так же, в интернете я нагуглил некий тип _Generic, добавленный в С11, который таки позволяет создавать переменные универсального типа. Как говорится "слишком сладких плодов не любит воин" , так что я решил придумать что-нибудь своё. За одно, освежил знания касательно callback функций (они правда не пригодились).
Вначале, я думал использовать тип *void - указатель на войд. Но тут сразу нашлись минусы.
Указатель необходимо инициализировать. Это значит, функция color(), должна выделять память под конкретный тип (переменные использовать нельзя, так как они уничтожаются после прекращения функции, ведь стековый фрейм удаляется). Если функция выделяет память - то её придётся позже освобождать, дабы исключить утечку. Это было бы неплохое решение, если бы функция применялись только для внутренних нужд модуля. Но я предполагал, что функцией color(), можно было бы задать цвет уже в друом модуле, а следовательно, уследить за malloc'ами становится проблематично.
Второй вариант решения: я думал сделать функцию, которая возвращает тип "функция". То есть, чтобы было три элементарные функции типов color8(), color16(), color32(), и одна главная color(). И главная функция в результате возвращала адрес одной из этих функций, в зависимости от pixel_depth. Это решение оказалось слишком запутаным, да и в общем-то бесполезным.
Тогда, лучше хранить данные в union. Решение следующее. Создаётся структура pixel, которая состоит из поля "depth", - размер данных в байтах, и поля union data - объединение в котором можно хранить int или short, или char.
Так как функция fwrite, берёт в качестве параметра только адрес и размер, тогда можно подставлять в неё значения &pixel.data и pixel.depth соответственно. Тут есть некоторая неровность, ведь pixel.data это не pixel.data.value8, она ведь имеет размер int, а не char. Но так как в pixel.depth, содержится количество байт соответствующего типа, то fwrite не будет записывать больше чем нужно.
Далее, создаётся макрос UNIDEPTHFUNC, который заставляет некоторую функцию работать для любого типа. Макрос разворачивается в обычный switch. Первый параметр макроса - это переменная, для которой будет выполняться функция. Второй - это имя обобщённой переменной в функции. И третий - это собственно сама функция, которую нужно выполнить.
В зависимости от depth (количество байт), создаётся указатель на соответствующий тип. Затем, этому указателю присваивается адрес соответствующего поля pixel.data.value. И уже потом вставляется функция, в которой вместо переменной конкретного типа указывается обобщенная переменная.
Выглядит довольно странно. Возможно, просто скопировать код было бы проще.
Немного сменил план.
Теперь функции делятся не по уровням, а по типу выполняемых задач. Каждый модуль посвящён чему-то одному. Например, some_math.с необходим только для вычисления некоторых математических функций. Почти как math.h из стандартной библиотеки, но только неоптимизированый, самодельный и пока что содержит только две функции:"возведение в степень" и "число по модулю" .
Далее. Модуль inter_pixels.с. Этот модуль посвящён работе с цветом, интерпретации пикселей. Он работает с такими понятиями как "глубина цвета", "компонента" и "пиксель". Последнее, реализовано в виде структуры pixel, которая содержит поля size_t bpp и uint_t64. Куда же делся union? Я его удалил. Дело в том, что я не понял смысла union. Ведь при вызове функции fwrite(&data, bpp, 1, file), нам не важно что за указатель стоит на первом месте, он всё равно запишет столько, сколько указано в bpp. union в данном случае добавляет только лишние поля, и больше особо ничего.
Так как модуль посвящён интерпритации пикселей, то собственно основная функция pixel color( char red, char green, char blue, char alpha, char depth) тем и занимается, что возвращает в структуру pixel, цвет, вычисленный для заданной глубины, и также количество байт, что занимает этот цвет. Эта функция подбирает, исключительно совместимый с форматом tga, цвет. То есть, если задана глубина пикселей 24 + альфа канал, то функция будет игнорировать прозрачность. Для других цветовых решений можно реализовать свои функции, ведь сам color() выполняется за счёт более элементарных под-функций, таких adjust_component и solidcolor(), alphacolor().
Функция adjust_component приводит значение компоненты цвета, к его максимальному значению в соответствующей глубине. Например, red 255 будет превращен в 0x111, в системе, где три бита - максимум на цвет (это глубина всего цвета - 8 бит). Данная функция позволяет гибко определять значение, по сути для любой из раскладок компонет, даже не для равномерных.
Функции solidcolor(), alphacolor() довольно схожи. Первая, делит память ячейки цвета на три части, и записывает в них компоненты. Если память выделенную под цвет не удаётся равномерно распределить, то функция либо оставляет остаток, либо занимает большую часть под R, и G, а B уделяет меньшую. Функция alphacolor, такой фигнёй не занимается, ведь она делит память ячейки цвета на 4. Все что делится на 8,также делится и на 4. Так как записать "половину байта" мы физически не можем, то получается что любая глубина цвета будет кратна 8. И поэтому для цвета с альфа-каналом можно разделять ячейки равномерно. Как уже понятно, функция color(), использует обе предыдущие функции тогда когда ей это удобно.
Что ещё было сделано? Был создан модуль tga_format, который посвящён чисто формированию составляющих tga формата. Пока что реализован только заголовок header, и холст canvas. В будущем, необходимо также добавить footer подвал, id поле идентификатора и colormap - палитра.
Набор функций ограничивается списком:
headers gen_header(w, h, type)
headers grab_header(FILE)
int analyse(header)
int init_canvas(header)
void free_canvas(int canvas)
Примерное значение уже было озвучено в предыдущих постах. Изначально, функции связанные с canvas, должны были иметь тип void, или pixel, ведь я полагал, что они должны состоять из произвольных пикселей. Но, потом, я понял, что не обязательно. Ведь холст - это набор цветных точек. Важно, что именно "точек", и не обязательно "пикселей". Холст ведь вполне можно вывести в виде ASCII символов. То как выводить холст - это задача уже самой программы. Под понятие "набор из точек" вполне себе подходит матрица int'ов (хотя правильно было бы сделать матрицу из unit_64, чтобы избежать потерь при импортировании 48-битных картинок).
Далее модуль simple_graphic.c, берет в свои задачи отрисовку линий. По аналогии с предыдущем модулем, тут важно, что линия должна отрисовываться вне зависимости от глубины цвета, да и значения её отрисовки. "Линия - есть линия", это не обязательно пиксели, и даже не обязательно ASCII символы, линия вообще может быть показателем какой-нибудь линейной зависимости. Поэтому, предполагается, что в функцию "линия" будет в качестве аргумента входить тип "указатель на функцию", то есть некий обработчик, который бы принимал x, и y, и что-то с ними делал.
Кстати, совсем не по теме, но наконец-то узнал что такое handler. Меня всегда почему-то очень раздражало слово handler - оно непонятно как-то переводится, типо "рукоятка" что ли? Что значит рукоятка в коде? И от этого, сразу же унываешь, когда где-то видишь handler. Но, сегодня я встретил эту конструкцию в коде dwm.c. Выглядит она так:
static void (⚹handler[LASTEvent]) (XEvent ⚹) = {
[ButtonPress] = buttonpress,
[ClientMessage] = clientmessage,
[ConfigureRequest] = configurerequest,
[ConfigureNotify] = configurenotify,
[DestroyNotify] = destroynotify,
[EnterNotify] = enternotify,
[Expose] = expose,
[FocusIn] = focusin,
[KeyPress] = keypress,
[MappingNotify] = mappingnotify,
[MapRequest] = maprequest,
[MotionNotify] = motionnotify,
[PropertyNotify] = propertynotify,
[UnmapNotify] = unmapnotify
};
Не совсем понятно. Но однозначно понятно, что это какие-то функции, ведь именно они запускаются из основного цикла run (который вызывается из main).
Итак.. Это массив указателей на функции.
Вспомним прочитаное.
Объявление функции это:
void ⚹function(int arg);
Переменную типа "указатель на функцию" можно объявить как
void (⚹function_ptr)(int arg);
"массив", это:
char array[5];
И в итоге получается массив указателей на функции
void (⚹function_ptr[5])(int arg);
Причём, arg можно не писать:
void (function_ptr[5])(int);
Итого, получается, что handler - это некий массив из функций отработчиков. Причём, что самое удобное, эти функции можно вызывать по-порядку, ведь они проиндексированы.
Чтож, теперь слово handler звучит как что-то интересное.
Вернёмся к tgatool. Конечный модуль, это собственно tgatool.c. Вот он уже, используя предыдущие модули, предоставляет пользователю набор функций для работы с tga файлами. В данном модуле выполняются все проверки, все защиты, и выводятся готовые функции типо: tga_create, tga_save, tga_eject, tga_setpixel, tga_get_width и прочие подобные. Как видно, модуль уже справляется с отрисовкрй диагональной линии, как в truecolor24 режиме, так и в grayscale8 режиме. Палитры и сжатие пока не поддерживается, хотя учитывая молульность их не сложно добавить. Вконце, для экономии места, я думаю все модули запихнуть в один. Так будет красиво и компактно. Но пока что мне удобнее раздельно компилировать только нужное.
Теперь функции делятся не по уровням, а по типу выполняемых задач. Каждый модуль посвящён чему-то одному. Например, some_math.с необходим только для вычисления некоторых математических функций. Почти как math.h из стандартной библиотеки, но только неоптимизированый, самодельный и пока что содержит только две функции:"возведение в степень" и "число по модулю" .
Далее. Модуль inter_pixels.с. Этот модуль посвящён работе с цветом, интерпретации пикселей. Он работает с такими понятиями как "глубина цвета", "компонента" и "пиксель". Последнее, реализовано в виде структуры pixel, которая содержит поля size_t bpp и uint_t64. Куда же делся union? Я его удалил. Дело в том, что я не понял смысла union. Ведь при вызове функции fwrite(&data, bpp, 1, file), нам не важно что за указатель стоит на первом месте, он всё равно запишет столько, сколько указано в bpp. union в данном случае добавляет только лишние поля, и больше особо ничего.
Так как модуль посвящён интерпритации пикселей, то собственно основная функция pixel color( char red, char green, char blue, char alpha, char depth) тем и занимается, что возвращает в структуру pixel, цвет, вычисленный для заданной глубины, и также количество байт, что занимает этот цвет. Эта функция подбирает, исключительно совместимый с форматом tga, цвет. То есть, если задана глубина пикселей 24 + альфа канал, то функция будет игнорировать прозрачность. Для других цветовых решений можно реализовать свои функции, ведь сам color() выполняется за счёт более элементарных под-функций, таких adjust_component и solidcolor(), alphacolor().
Функция adjust_component приводит значение компоненты цвета, к его максимальному значению в соответствующей глубине. Например, red 255 будет превращен в 0x111, в системе, где три бита - максимум на цвет (это глубина всего цвета - 8 бит). Данная функция позволяет гибко определять значение, по сути для любой из раскладок компонет, даже не для равномерных.
Функции solidcolor(), alphacolor() довольно схожи. Первая, делит память ячейки цвета на три части, и записывает в них компоненты. Если память выделенную под цвет не удаётся равномерно распределить, то функция либо оставляет остаток, либо занимает большую часть под R, и G, а B уделяет меньшую. Функция alphacolor, такой фигнёй не занимается, ведь она делит память ячейки цвета на 4. Все что делится на 8,также делится и на 4. Так как записать "половину байта" мы физически не можем, то получается что любая глубина цвета будет кратна 8. И поэтому для цвета с альфа-каналом можно разделять ячейки равномерно. Как уже понятно, функция color(), использует обе предыдущие функции тогда когда ей это удобно.
Что ещё было сделано? Был создан модуль tga_format, который посвящён чисто формированию составляющих tga формата. Пока что реализован только заголовок header, и холст canvas. В будущем, необходимо также добавить footer подвал, id поле идентификатора и colormap - палитра.
Набор функций ограничивается списком:
headers gen_header(w, h, type)
headers grab_header(FILE)
int analyse(header)
int init_canvas(header)
void free_canvas(int canvas)
Примерное значение уже было озвучено в предыдущих постах. Изначально, функции связанные с canvas, должны были иметь тип void, или pixel, ведь я полагал, что они должны состоять из произвольных пикселей. Но, потом, я понял, что не обязательно. Ведь холст - это набор цветных точек. Важно, что именно "точек", и не обязательно "пикселей". Холст ведь вполне можно вывести в виде ASCII символов. То как выводить холст - это задача уже самой программы. Под понятие "набор из точек" вполне себе подходит матрица int'ов (хотя правильно было бы сделать матрицу из unit_64, чтобы избежать потерь при импортировании 48-битных картинок).
Далее модуль simple_graphic.c, берет в свои задачи отрисовку линий. По аналогии с предыдущем модулем, тут важно, что линия должна отрисовываться вне зависимости от глубины цвета, да и значения её отрисовки. "Линия - есть линия", это не обязательно пиксели, и даже не обязательно ASCII символы, линия вообще может быть показателем какой-нибудь линейной зависимости. Поэтому, предполагается, что в функцию "линия" будет в качестве аргумента входить тип "указатель на функцию", то есть некий обработчик, который бы принимал x, и y, и что-то с ними делал.
Кстати, совсем не по теме, но наконец-то узнал что такое handler. Меня всегда почему-то очень раздражало слово handler - оно непонятно как-то переводится, типо "рукоятка" что ли? Что значит рукоятка в коде? И от этого, сразу же унываешь, когда где-то видишь handler. Но, сегодня я встретил эту конструкцию в коде dwm.c. Выглядит она так:
static void (⚹handler[LASTEvent]) (XEvent ⚹) = {
[ButtonPress] = buttonpress,
[ClientMessage] = clientmessage,
[ConfigureRequest] = configurerequest,
[ConfigureNotify] = configurenotify,
[DestroyNotify] = destroynotify,
[EnterNotify] = enternotify,
[Expose] = expose,
[FocusIn] = focusin,
[KeyPress] = keypress,
[MappingNotify] = mappingnotify,
[MapRequest] = maprequest,
[MotionNotify] = motionnotify,
[PropertyNotify] = propertynotify,
[UnmapNotify] = unmapnotify
};
Не совсем понятно. Но однозначно понятно, что это какие-то функции, ведь именно они запускаются из основного цикла run (который вызывается из main).
Итак.. Это массив указателей на функции.
Вспомним прочитаное.
Объявление функции это:
void ⚹function(int arg);
Переменную типа "указатель на функцию" можно объявить как
void (⚹function_ptr)(int arg);
"массив", это:
char array[5];
И в итоге получается массив указателей на функции
void (⚹function_ptr[5])(int arg);
Причём, arg можно не писать:
void (function_ptr[5])(int);
Итого, получается, что handler - это некий массив из функций отработчиков. Причём, что самое удобное, эти функции можно вызывать по-порядку, ведь они проиндексированы.
Чтож, теперь слово handler звучит как что-то интересное.
Вернёмся к tgatool. Конечный модуль, это собственно tgatool.c. Вот он уже, используя предыдущие модули, предоставляет пользователю набор функций для работы с tga файлами. В данном модуле выполняются все проверки, все защиты, и выводятся готовые функции типо: tga_create, tga_save, tga_eject, tga_setpixel, tga_get_width и прочие подобные. Как видно, модуль уже справляется с отрисовкрй диагональной линии, как в truecolor24 режиме, так и в grayscale8 режиме. Палитры и сжатие пока не поддерживается, хотя учитывая молульность их не сложно добавить. Вконце, для экономии места, я думаю все модули запихнуть в один. Так будет красиво и компактно. Но пока что мне удобнее раздельно компилировать только нужное.
Как оказалось, я не один искал патч на тайтлбар для dwm.
https://www.reddit.com/r/suckless/comments/jht3ra/looking_for_dwm_patch_to_give_twm_or_mwm_like/
Не нашёл. Так уж и быть написал патч сам. Во всяком случае надо и подпрактиковываться чужой код читать. Может что-то интересное узнаю.
Результат на первой картинке.Теперь окна можно перемещать чисто мышью, не дотягиваясь до клавиатуры.
Кнопки решил не добавлять, по двум причинам:
1)Иногда в приложениях уже есть свои собственные кнопки закрытия (например у telegram). Тогда получалось бы как-то глупо: "окно в окне). Также большая часть программ имеет пункт "exit", в главном меню что делает возможным закрыть программу с использованием только мыши. Итого, кнопка закрытия на тайтлбаре - излишняя, а скрыть окно без клавиатуры можно и при помощи awesomebar.
2)Закрываю окна я не так часто как их перемещаю. Так что зачем тратить время на реализацию функций, которые и не особо важны.
Изучать код полностью я не решился, поэтому начал просто вставлять свой код в случайные места и смотреть что будет.
Итак, чего я изучил. Xorg-server - это, как понятно из названия, серверная программа, которая занимается управлением драйверами устройств : монитором, клавиатурой, мышью, видеокартой. Для управления последним, был сделан отдельный модуль ядра (операционной системы), с названием drm, direct-rendering-managment. Изначально xorg работал и без него, используя для доступа к устройствам системные вызовы и встроенные драйвера, но со временем технологии улучшались, появлялись новые драйвера, видеокарты, аппаратное ускорение, и тд., а ядро freebsd, как часто пишут, имеет довольно скудный набор поддерживаемых драйверов и системных вызовов. Поэтому и создали, некое дополнительное ядро для более полноценного доступа к переферии.
Как бы там ни было, все устройства xorg-server обобществляет одним словом display. Дисплей это некоторая сущность внутри xorg сервера, к которой можно предоставить доступ клиентам. В качестве клиентов выступают другие программы, калькулятор там.. или блокнот. Получается что мы, находясь по ту сторону экрана, являемся частью сервера xorg, мы обрабатываем запросы от программ, которые ожидают от нас действий.
Благодаря сетевой архитектуре, xorg предоставляет широкие возможности для расположения клиентов и серверов. Клиент и сервер может находится на одной машине (в учебнике столярова говорилось, что сетевым сокетам впринципе безразлично куда отправлять пакеты, хоть на свой компьютер, хоть на чужой - для них это одно и тоже), или же клиент может находиться на компьютере соседа, при этом я, находясь на сервере, совсем не смогу ощутить разницы, как если бы клиент был запущен на моей машине.
Далее, одним из первых клиентов для xorg, выступает dwm. dwm - это ведь тоже программа, и значит она является клиентом. В функции main, собственно, проверяется, смогла ли программа получить дисплей от xorg сервера, и если смогла, то запускается вначале функция scan, а затем run.
Функция scan, извлекает некоторые данные из полученного дисплея, и по ним кофигурирует глобальные переменные. Функция run, запускает бесконечный цикл обработки событий.
Событие - это некоторая переменная XEvent. Событиями может быть как действия внутри сервера: нажатие клавиш, клацанье мыши, так и запрос от клиента:программа хочет что-то нам передать, например своё название. Событие вызывает соответствующий обработчик. Вот такие обработчики я откопал в dwm:
expose - эта функция обрабатывает событие когда одно окно задевает другое. В моем случае, это используется для переотрисовки тайтлбара. Если одно окно задело другое, то требуется переотрисовка. Следить за цветом и порядком в данном случае не нужно, так в dwm есть глобальная переменная selmon->sel, которая обозначает сфокусированный клиент. Собственно, если клиент сфокусирован, то рисуем тайтлбар зелёным, и выводим его поверх экрана XMapRaised. Если же клиент не сфокусирован, то рисуем его серым, на заднем фоне XMapWindow.
buttonpress - это обработчик событий для нажатия кнопок мыши. Само событие ev имеет несколько полей, таких как координаты точки клика в относительных единицах окна, и само окно по которому попал клик. Тут я добавил свой тип клика ClkTitlebar, что означает "клик по тайтлбару", а функционал скопировал тот же, что и у ClkClientWin, за тем исключением, что для перемещения тайтлбара не нужно зажимать mod key.
В общем то, больше я обработчики не трогал, и дальнейшие изменения делал в других функциях.
Функция resizeclient, как понятно из названия, вызывается, чтобы изменить положение или размеры клиентского окна. Сюда я добавил отрисовку тайтлбара, чтобы он менял размеры вместе с окном.
Функция updatetitle, которая по всей видимости только и нужна для того, чтобы обновлять название клиента, если он этого просит.
Функция manage , это довольно важная функция, которая вызывается в scan и setup. Судя по названию, она начинает менеджмент (ну dwm ведь оконный менеджер) над новым клиентом. В данной функций я добавил создание окна-тайтлбара для нового клиента.
Функции focus и unfocus, соответственно, отвечают за фокусировку и разфокусировку клиента.
https://www.reddit.com/r/suckless/comments/jht3ra/looking_for_dwm_patch_to_give_twm_or_mwm_like/
Не нашёл. Так уж и быть написал патч сам. Во всяком случае надо и подпрактиковываться чужой код читать. Может что-то интересное узнаю.
Результат на первой картинке.Теперь окна можно перемещать чисто мышью, не дотягиваясь до клавиатуры.
Кнопки решил не добавлять, по двум причинам:
1)Иногда в приложениях уже есть свои собственные кнопки закрытия (например у telegram). Тогда получалось бы как-то глупо: "окно в окне). Также большая часть программ имеет пункт "exit", в главном меню что делает возможным закрыть программу с использованием только мыши. Итого, кнопка закрытия на тайтлбаре - излишняя, а скрыть окно без клавиатуры можно и при помощи awesomebar.
2)Закрываю окна я не так часто как их перемещаю. Так что зачем тратить время на реализацию функций, которые и не особо важны.
Изучать код полностью я не решился, поэтому начал просто вставлять свой код в случайные места и смотреть что будет.
Итак, чего я изучил. Xorg-server - это, как понятно из названия, серверная программа, которая занимается управлением драйверами устройств : монитором, клавиатурой, мышью, видеокартой. Для управления последним, был сделан отдельный модуль ядра (операционной системы), с названием drm, direct-rendering-managment. Изначально xorg работал и без него, используя для доступа к устройствам системные вызовы и встроенные драйвера, но со временем технологии улучшались, появлялись новые драйвера, видеокарты, аппаратное ускорение, и тд., а ядро freebsd, как часто пишут, имеет довольно скудный набор поддерживаемых драйверов и системных вызовов. Поэтому и создали, некое дополнительное ядро для более полноценного доступа к переферии.
Как бы там ни было, все устройства xorg-server обобществляет одним словом display. Дисплей это некоторая сущность внутри xorg сервера, к которой можно предоставить доступ клиентам. В качестве клиентов выступают другие программы, калькулятор там.. или блокнот. Получается что мы, находясь по ту сторону экрана, являемся частью сервера xorg, мы обрабатываем запросы от программ, которые ожидают от нас действий.
Благодаря сетевой архитектуре, xorg предоставляет широкие возможности для расположения клиентов и серверов. Клиент и сервер может находится на одной машине (в учебнике столярова говорилось, что сетевым сокетам впринципе безразлично куда отправлять пакеты, хоть на свой компьютер, хоть на чужой - для них это одно и тоже), или же клиент может находиться на компьютере соседа, при этом я, находясь на сервере, совсем не смогу ощутить разницы, как если бы клиент был запущен на моей машине.
Далее, одним из первых клиентов для xorg, выступает dwm. dwm - это ведь тоже программа, и значит она является клиентом. В функции main, собственно, проверяется, смогла ли программа получить дисплей от xorg сервера, и если смогла, то запускается вначале функция scan, а затем run.
Функция scan, извлекает некоторые данные из полученного дисплея, и по ним кофигурирует глобальные переменные. Функция run, запускает бесконечный цикл обработки событий.
Событие - это некоторая переменная XEvent. Событиями может быть как действия внутри сервера: нажатие клавиш, клацанье мыши, так и запрос от клиента:программа хочет что-то нам передать, например своё название. Событие вызывает соответствующий обработчик. Вот такие обработчики я откопал в dwm:
expose - эта функция обрабатывает событие когда одно окно задевает другое. В моем случае, это используется для переотрисовки тайтлбара. Если одно окно задело другое, то требуется переотрисовка. Следить за цветом и порядком в данном случае не нужно, так в dwm есть глобальная переменная selmon->sel, которая обозначает сфокусированный клиент. Собственно, если клиент сфокусирован, то рисуем тайтлбар зелёным, и выводим его поверх экрана XMapRaised. Если же клиент не сфокусирован, то рисуем его серым, на заднем фоне XMapWindow.
buttonpress - это обработчик событий для нажатия кнопок мыши. Само событие ev имеет несколько полей, таких как координаты точки клика в относительных единицах окна, и само окно по которому попал клик. Тут я добавил свой тип клика ClkTitlebar, что означает "клик по тайтлбару", а функционал скопировал тот же, что и у ClkClientWin, за тем исключением, что для перемещения тайтлбара не нужно зажимать mod key.
В общем то, больше я обработчики не трогал, и дальнейшие изменения делал в других функциях.
Функция resizeclient, как понятно из названия, вызывается, чтобы изменить положение или размеры клиентского окна. Сюда я добавил отрисовку тайтлбара, чтобы он менял размеры вместе с окном.
Функция updatetitle, которая по всей видимости только и нужна для того, чтобы обновлять название клиента, если он этого просит.
Функция manage , это довольно важная функция, которая вызывается в scan и setup. Судя по названию, она начинает менеджмент (ну dwm ведь оконный менеджер) над новым клиентом. В данной функций я добавил создание окна-тайтлбара для нового клиента.
Функции focus и unfocus, соответственно, отвечают за фокусировку и разфокусировку клиента.
Возня с TGA форматом изрядно надоела. Поэтому можно завершать.
Итак, общество с ограниченной ответственностью "велосипедзавод" представляет.
"tgatool.c" - Инструмент для работы с tga изображениями.
## ЧТО НЕОБХОДИМО ДЛЯ ИСПОЛЬЗОВАНИЯ?
- Компилятор С;
- Стандартная библиотека С.
## КАК ИСПОЛЬЗОВАТЬ?
1. Откомпилируйте объектный модуль. Например при помощи gcc:
gcc -o tgatool.o -c ./tgatool.c
2. Включите заголовочник в свой проект:
#include "tgatool.h"
3.Используйте функции из модуля согласно их назначению (подробнее описано в самом заголовочнике) ;
4.Профит.
## ЗАЧЕМ?
Этот инструмент создан для учебных целей. Вы можете начать изучать компьютерную графику, создать алгоритм по отрисовке линий, и для минимализации зависимостей использовать вывод в, tga изображение. Или, пользуясь данным модулем, вы можете отрисовывать графики функций, которые сами напишете. Например, если у вас стоит цель получить механическую характеристику асинхронного двигателя, но матлаба вы не знаете, то вы можете реализовать алгоритм, который бы по начальным условиям отрисовывал эту зависимость на языке С.
## ОГРАНИЧЕНИЯ
- Отсутствует возможность сохранения типа "палитровые изображения". Однако, открыть вы их можете. При попытке сохранить палитровое изображение, оно будет преобразовано в truecolor, и сохранено с предупреждением об такой особенности. Почему? Потому что мне лень было делать вывод в палитровые изображения. Да и зачем.
- Модуль игнорирует порядок байтов холста. Это означает, что некоторые изображения могут быть открыты перевёрнутыми.
- Весь холст хранится в массивах из int. Это значит, что картинки глубиной цвета более 32 бит будут терять качество при открытии.
-Поддерживается только основной TGA формат. Зоны разработчика и прочее никак не реализованы.
Всё, хватит этих структур, маллоков, фгетоф. Слишком скучное. Далее, надо сделать какую-нибудь простую клиент-серверную программу, вот что будет по-интереснее. Прикупил китайский мини-компьютер на целероне. Можно его использовать для передачи пакетов/дейтаграм внутри сети.
Итак, общество с ограниченной ответственностью "велосипедзавод" представляет.
"tgatool.c" - Инструмент для работы с tga изображениями.
## ЧТО НЕОБХОДИМО ДЛЯ ИСПОЛЬЗОВАНИЯ?
- Компилятор С;
- Стандартная библиотека С.
## КАК ИСПОЛЬЗОВАТЬ?
1. Откомпилируйте объектный модуль. Например при помощи gcc:
gcc -o tgatool.o -c ./tgatool.c
2. Включите заголовочник в свой проект:
#include "tgatool.h"
3.Используйте функции из модуля согласно их назначению (подробнее описано в самом заголовочнике) ;
4.Профит.
## ЗАЧЕМ?
Этот инструмент создан для учебных целей. Вы можете начать изучать компьютерную графику, создать алгоритм по отрисовке линий, и для минимализации зависимостей использовать вывод в, tga изображение. Или, пользуясь данным модулем, вы можете отрисовывать графики функций, которые сами напишете. Например, если у вас стоит цель получить механическую характеристику асинхронного двигателя, но матлаба вы не знаете, то вы можете реализовать алгоритм, который бы по начальным условиям отрисовывал эту зависимость на языке С.
## ОГРАНИЧЕНИЯ
- Отсутствует возможность сохранения типа "палитровые изображения". Однако, открыть вы их можете. При попытке сохранить палитровое изображение, оно будет преобразовано в truecolor, и сохранено с предупреждением об такой особенности. Почему? Потому что мне лень было делать вывод в палитровые изображения. Да и зачем.
- Модуль игнорирует порядок байтов холста. Это означает, что некоторые изображения могут быть открыты перевёрнутыми.
- Весь холст хранится в массивах из int. Это значит, что картинки глубиной цвета более 32 бит будут терять качество при открытии.
-Поддерживается только основной TGA формат. Зоны разработчика и прочее никак не реализованы.
Всё, хватит этих структур, маллоков, фгетоф. Слишком скучное. Далее, надо сделать какую-нибудь простую клиент-серверную программу, вот что будет по-интереснее. Прикупил китайский мини-компьютер на целероне. Можно его использовать для передачи пакетов/дейтаграм внутри сети.
В общем то и правильно я сделал, что не стал добавлять алгоритм по отрисовке линий в tgatool.
Ведь линия сама по себе никакого отношения к tga формату не имеет. И следовательно модуль, по отрисовке графики должен быть независимым от модуля tga формата.
Сам модуль графики (назовём его simpleGL), оперирует чисто математическими понятиями, такими как "точка", "координата", "линия". Что мы можем сказать о "точке" например? Точка может иметь две координаты, точка может принадлежать к какому-нибудь множеству, точка может иметь "массу" (то есть некоторую величину). Всё это можно описать типом структура. Принадлежность точки можно обозначить указателем. Если указатель NULL, значит это просто абстрактная "точка", а если он содержит адрес, то это точка некоторого множества. Далее, что такое "построить линию", это сделать алгоритм который может сосчитать координаты всех точек на этой линии. Задумка в том, что модуль не должен знать ничего про то, как конкретно будут использованы точки этой линии.
Тут возникает вопрос "а как связать функцию вычисляющую координаты, и функцию которая отрисовывает эти точки?"
Интуитивно хочется иметь что-то типо "потока ввода", чтобы можно было получать X Y как из файла. Увы, проблема: для связывания двух программ каналом, необходимо чтобы они работали параллельно. Но могут ли они в данном случае работать параллельно? Чтобы орисовать точку, нам нужно заблокировать процесс пока не поступят данные о новой координате. А чтобы вычислить координаты, нам надо подождать пока предыдущая точка отрисуется. То есть эти две функции никогда параллельно работать не будут (если конечно нет промежуточного буфера), а значит выполнять их параллельно смысла не имеет.
Можно пойти другим путем, завести буфер, и всё вычисленное просто складировать там, а потом достать всё из этого буфера и нарисовать. Идея по-лучше, но мне не нравится что придётся выделять память для каждой линии, какой бы она ни была.
Мне захотелось реализовать идею, которую я посмотрел в коде dwm. А именно, массив из функций-отработчиков.
Функция лишь вычисляет координаты, а затем вызывает callback функцию, которая уже сама определяет, что делать с вычисленными координатами. В данном случае, функции обработчики принимают параметр типа points, то есть им дают точку. Это мне показалось более выгодным, потому что точки имеют свой вес и принадлежность.
Вот, три иллюстративных callback'a:
add_to_set() - "добавить к множеству". Вычисленные точки можно просто собирать в буфер. Например, если у точки в поле "принадлежность" указан буфер, то функция-обработчик запишет все такие точки в этот массив.
draw_tga() - собственно, это обёртка для set_pixel, из модуля tgatool. Координаты преобразовываютия из int, в short, "вес точки" - означает её цвет, а "принадлежность" - то tga изображение на котором она будет отпечатана.
draw_ascii() - обёртка для рисования линий при помощи ncurses. "Вес точки" в данном случае - это символ, который необходимо отрисовать, "принадлежность" - это главное окно, а координаты преобразованы в col и row.
Впринципе, могут быть и отработчики, которые и не собирают данные, а ожидают пока, например Y не перевалит за какое-то значение.
Пока что из этого сделал только draw_tga.
В первый раз мне выдало segmentation fault. Я искал ошибку, но так и не нашёл. Откомпиоировал, запустил ещё раз - всё работает. Я так и не понял в чем проблема.
Ведь линия сама по себе никакого отношения к tga формату не имеет. И следовательно модуль, по отрисовке графики должен быть независимым от модуля tga формата.
Сам модуль графики (назовём его simpleGL), оперирует чисто математическими понятиями, такими как "точка", "координата", "линия". Что мы можем сказать о "точке" например? Точка может иметь две координаты, точка может принадлежать к какому-нибудь множеству, точка может иметь "массу" (то есть некоторую величину). Всё это можно описать типом структура. Принадлежность точки можно обозначить указателем. Если указатель NULL, значит это просто абстрактная "точка", а если он содержит адрес, то это точка некоторого множества. Далее, что такое "построить линию", это сделать алгоритм который может сосчитать координаты всех точек на этой линии. Задумка в том, что модуль не должен знать ничего про то, как конкретно будут использованы точки этой линии.
Тут возникает вопрос "а как связать функцию вычисляющую координаты, и функцию которая отрисовывает эти точки?"
Интуитивно хочется иметь что-то типо "потока ввода", чтобы можно было получать X Y как из файла. Увы, проблема: для связывания двух программ каналом, необходимо чтобы они работали параллельно. Но могут ли они в данном случае работать параллельно? Чтобы орисовать точку, нам нужно заблокировать процесс пока не поступят данные о новой координате. А чтобы вычислить координаты, нам надо подождать пока предыдущая точка отрисуется. То есть эти две функции никогда параллельно работать не будут (если конечно нет промежуточного буфера), а значит выполнять их параллельно смысла не имеет.
Можно пойти другим путем, завести буфер, и всё вычисленное просто складировать там, а потом достать всё из этого буфера и нарисовать. Идея по-лучше, но мне не нравится что придётся выделять память для каждой линии, какой бы она ни была.
Мне захотелось реализовать идею, которую я посмотрел в коде dwm. А именно, массив из функций-отработчиков.
Функция лишь вычисляет координаты, а затем вызывает callback функцию, которая уже сама определяет, что делать с вычисленными координатами. В данном случае, функции обработчики принимают параметр типа points, то есть им дают точку. Это мне показалось более выгодным, потому что точки имеют свой вес и принадлежность.
Вот, три иллюстративных callback'a:
add_to_set() - "добавить к множеству". Вычисленные точки можно просто собирать в буфер. Например, если у точки в поле "принадлежность" указан буфер, то функция-обработчик запишет все такие точки в этот массив.
draw_tga() - собственно, это обёртка для set_pixel, из модуля tgatool. Координаты преобразовываютия из int, в short, "вес точки" - означает её цвет, а "принадлежность" - то tga изображение на котором она будет отпечатана.
draw_ascii() - обёртка для рисования линий при помощи ncurses. "Вес точки" в данном случае - это символ, который необходимо отрисовать, "принадлежность" - это главное окно, а координаты преобразованы в col и row.
Впринципе, могут быть и отработчики, которые и не собирают данные, а ожидают пока, например Y не перевалит за какое-то значение.
Пока что из этого сделал только draw_tga.
В первый раз мне выдало segmentation fault. Я искал ошибку, но так и не нашёл. Откомпиоировал, запустил ещё раз - всё работает. Я так и не понял в чем проблема.
Дневник каличный, но картинки пиздатые. Те, что не с формулами программистов-пидарасов. Пости картинки, не пости кринж свой анальнический.
диннах
Идея для следующей программы - Cookie manager.
С развитием компьютерных технологий, часто приходится переносить логины и пароли с одного компьютера на другой.
Например, если у вас есть три компьютера: дома, на работе и на даче. Зарегистрировавшись на новом сайте, вы хотите чтобы сессия была доступна и на других ваших компьютерах. В этом вам поможет cookie manager.
Или же может быть вы решили переустановить Windows, но не хотите потерять все ваши пароли, которые вы может быть даже и не помните. И в этом случае применим cookie manager.
Клиентская часть программы должна автоматически находить sql файлы с паролями из браузера, затем расшифровывать их и отправлять на адрес сетевого сокета сервера.
Серверная часть программы ожидает запросов. При получении запроса, создаётся отдельный процесс для сохранения полученных данных в архив.
Такой надёжный инструмент для хранения куков паролей поможет обезопасить множество компьютеров от мошенников.
Помоему идея хорошая. За одно и попрактикую последние главы книги.
С развитием компьютерных технологий, часто приходится переносить логины и пароли с одного компьютера на другой.
Например, если у вас есть три компьютера: дома, на работе и на даче. Зарегистрировавшись на новом сайте, вы хотите чтобы сессия была доступна и на других ваших компьютерах. В этом вам поможет cookie manager.
Или же может быть вы решили переустановить Windows, но не хотите потерять все ваши пароли, которые вы может быть даже и не помните. И в этом случае применим cookie manager.
Клиентская часть программы должна автоматически находить sql файлы с паролями из браузера, затем расшифровывать их и отправлять на адрес сетевого сокета сервера.
Серверная часть программы ожидает запросов. При получении запроса, создаётся отдельный процесс для сохранения полученных данных в архив.
Такой надёжный инструмент для хранения куков паролей поможет обезопасить множество компьютеров от мошенников.
Помоему идея хорошая. За одно и попрактикую последние главы книги.
hello world.
Серверная программа создаёт сокет и ожидает запросов. Клиентская, создаёт сокет, связывается с сервером и отправляет туда свой аргумент. Как только север получает запрос, он помещает данные в буфер, а затем печатает их.
Удивительно, это работает.
Я вот никогда не понимал, а как сделать так, чтобы мой компьютер принимал запросы, не только из локальной сети. Мой внешний IP, это ведь IP шлюза, то есть адрес роутера, а не моего компьютера. Наверное, необходимо настроить маршрутизацию, так чтобы по-умолчанию все запросы на роутер перенаправлялись на мой компьютер. Но проще тогда уж дедик арендовать, он стоит копейки, и если что-то сломаешь - не страшно.
Стек протоколов, похоже что называется стеком, потому что протокол верхнего уровня нуждается хотя бы по одному из протоколов уровней ниже. То есть TCP, не будет работать без IP. При этом, в теории IP можно заменить на что-то другое, но в любом случае TCP подразумевает, что мы уже знаем как связываться с другими сетевыми интерфейсами.
Не знаю, может ли TCP работать "поверх" канального протокола, ведь для примитивной связи двух компьютеров достаточно и mac адреса, а ip, как мне показалось, предполагает автоматическую маршрутизацию (в том смысле, что пользуясь протоколом ip, не нужно знать точный адрес сетевого интерфейса, и не нужно знать как в точности сеть организована, она сама по себе организовывается в зависимости от количества подключённых сетевых устройств). И ведь в книге, было написано, что в бородатые времена данные так и передавали внутри локальной сети.
Теперь понятно почему модель OSI подразумевает иерархию.
Протокол - это как спецификация. Есть, допустим у нас какое-нибудь устройство, например рудничный пускатель. Спецификация предписывает, что рудничные пускали должны иметь механическую блокировку на корпусе. При этом фирмы у пускателей могут быть разные и формы разные, но на всю их продукцию действует соглашение, что должна быть блокировка. Но в отличие от спецификации, протокол работает в две стороны. То есть соглашения, в нем прописные действуют хотя бы на два пускателя, а не на один. Взять к примеру реверсивный пускатель. Тогда между двумя его контакторами, можно составить соглашение, о необходимости блокировки: пока коммутируется один контактор, второй не должен замыкаться во избежание короткого замыкания. При этом, блокировка может быть разной: механическая, электромагнитная, главное чтобы контакторы не работали одновременно. Вот это уже протокол.
Также, и сеть: протокол физического уровня описывает особенности сетевых карт, описывает то, как они должны подавать напряжение на витую пару. Протокол канального уровня, уже работает с драйверами сетевой карты, и описывает как связаться с другой какой-нибудь сетевой картой. Нельзя не заметить, что для его работы, все же необходим коаксиальный кабель, витая пара или же беспроводное устройство, иными словами протокол канального уровня существует в контексте хотя бы одного из физических протоколов. Если нет соглашений о том как подавать напряжение на кабель - то нет и нельзя принять соглашение о каналах связи. При этом, для существования канала, не важно, чем конкретно реализовать передачу. Далее, ip, и далее TCP и UDP - им тоже не важно, используется ipv4 или ipv6, им важно, чтобы было хоть что-то, что позволяло бы автоматически связываться с другими компьютерами, а далее они уже будут выполнять свою функцию.
Серверная программа создаёт сокет и ожидает запросов. Клиентская, создаёт сокет, связывается с сервером и отправляет туда свой аргумент. Как только север получает запрос, он помещает данные в буфер, а затем печатает их.
Удивительно, это работает.
Я вот никогда не понимал, а как сделать так, чтобы мой компьютер принимал запросы, не только из локальной сети. Мой внешний IP, это ведь IP шлюза, то есть адрес роутера, а не моего компьютера. Наверное, необходимо настроить маршрутизацию, так чтобы по-умолчанию все запросы на роутер перенаправлялись на мой компьютер. Но проще тогда уж дедик арендовать, он стоит копейки, и если что-то сломаешь - не страшно.
Стек протоколов, похоже что называется стеком, потому что протокол верхнего уровня нуждается хотя бы по одному из протоколов уровней ниже. То есть TCP, не будет работать без IP. При этом, в теории IP можно заменить на что-то другое, но в любом случае TCP подразумевает, что мы уже знаем как связываться с другими сетевыми интерфейсами.
Не знаю, может ли TCP работать "поверх" канального протокола, ведь для примитивной связи двух компьютеров достаточно и mac адреса, а ip, как мне показалось, предполагает автоматическую маршрутизацию (в том смысле, что пользуясь протоколом ip, не нужно знать точный адрес сетевого интерфейса, и не нужно знать как в точности сеть организована, она сама по себе организовывается в зависимости от количества подключённых сетевых устройств). И ведь в книге, было написано, что в бородатые времена данные так и передавали внутри локальной сети.
Теперь понятно почему модель OSI подразумевает иерархию.
Протокол - это как спецификация. Есть, допустим у нас какое-нибудь устройство, например рудничный пускатель. Спецификация предписывает, что рудничные пускали должны иметь механическую блокировку на корпусе. При этом фирмы у пускателей могут быть разные и формы разные, но на всю их продукцию действует соглашение, что должна быть блокировка. Но в отличие от спецификации, протокол работает в две стороны. То есть соглашения, в нем прописные действуют хотя бы на два пускателя, а не на один. Взять к примеру реверсивный пускатель. Тогда между двумя его контакторами, можно составить соглашение, о необходимости блокировки: пока коммутируется один контактор, второй не должен замыкаться во избежание короткого замыкания. При этом, блокировка может быть разной: механическая, электромагнитная, главное чтобы контакторы не работали одновременно. Вот это уже протокол.
Также, и сеть: протокол физического уровня описывает особенности сетевых карт, описывает то, как они должны подавать напряжение на витую пару. Протокол канального уровня, уже работает с драйверами сетевой карты, и описывает как связаться с другой какой-нибудь сетевой картой. Нельзя не заметить, что для его работы, все же необходим коаксиальный кабель, витая пара или же беспроводное устройство, иными словами протокол канального уровня существует в контексте хотя бы одного из физических протоколов. Если нет соглашений о том как подавать напряжение на кабель - то нет и нельзя принять соглашение о каналах связи. При этом, для существования канала, не важно, чем конкретно реализовать передачу. Далее, ip, и далее TCP и UDP - им тоже не важно, используется ipv4 или ipv6, им важно, чтобы было хоть что-то, что позволяло бы автоматически связываться с другими компьютерами, а далее они уже будут выполнять свою функцию.
Надо записать пару вещей которые вроде бы и простые но я их постоянно забываю. (Забываю их, потому что не практикую, а не практикую потому что забываю)
## Различие между блокирующим и неблокирующим режиме ввода.
Функции read() и write(), могут работать в блокирующем и неблокирующих режимах.
- Блокирующий режим ожидает поступления данных. Если данных нет и не было, функция все равно ждет, и не переходит к следующей инструкции. Такая функция как Windows Media Player: если не удалось открыть видео, программа все равно запустится хоть и не будет ничего показывать.
- Неблокирующий режим, напротив, ничего не ждёт, и при первой же ситуации отсутствия данных функция отдаёт управление. Это можно сравнить с проигрывателем MPV: если формат некорректный или файл поврежден, он моментально закроется, даже не спросив.
То есть, в случае если мы заполняем буфер медленнее чем, читаем из него, то функция в неблокирующем режиме быстренько завершится при первом же исчерпании буфера. Если же данных в буфере изначально не было, то функция завершится даже не подождав пока они там будут. Так что неблокирующий режим подразумевает, что мы вернемся к потоку позже, чтобы дочитать данные.
- Важно, что в обоих из этих режимов, функция завершается при наступлении EOF. Конец файла, означает что читать больше нечего, и следовательно функция в блокирующем режиме завершается. Функция в неблокирующем режиме завершилась бы и так и так, потому что она завершается при первом же отсутствии данных, даже не дожидаясь конца файла.
##Раличие между значениями переменной pid.
Вызов fork() возвращает номер процесса-потомка. То есть, если этот номер равен чему-то, то мы находимся в родительском процессе. Скажем, мы, фигурально, размножились делением, и теперь наш "ребёнок" имеет имя. Если мы знаем его имя, то мы - родитель. Сам ребёнок своего имени не знает. Так что если имени своего ребёнка мы не знаем, то мы и есть ребёнок. Поэтому, если pid == 0, то это именно порождённый процесс, а не наоборот.
У меня сложилась путаница, потому что умозрительно кажется: "ну, когда существовал родительский процесс, никакого ребёнка не было, а вот сделали fork() и что-то появилось, значит у родительского процесса pid == 0, это что - это номер ребёнка и принадлежит самому ребёнку". Нет. Это ложь. Это глупость, так как pid не может быть нулевым. Удобнее было бы называть эту переменную не pid, а child_pid. Если процесс-ребёнок сам" бездетный", то у него переменная pid равна 0, так как номера его потомка пока что не существует. А процесс-родитель всегда будет иметь переменную pid, отличную от нуля, так как у него есть хотя бы один потомок.
##Различие в UDP и TCP.
Почему-то всегда кажется, что UDP, это для файлов, а TCP, для всего. Но нет. И то и другое может быть использовано как угодно. Можно и файл по TCP отправить, и связь построить на UDP. Разница лишь в том, что в UDP, отсутствует соединение как таковое. Всё данные о получаемом пакете лежат в самой дейтаграмме. То есть UDP, это как письмо закидываемое в почтовый ящик. Пакет, отправленный по UPD, можно и пропустить вообще то, и никто ничего не заметит. TCP, это напротив, как личный разговор: перед тем как поговорить, необходимо поздороваться, сесть и начать слушать. И тут уже не получится просто так пропустить пакет, это будет слишком заметно.
##системный вызов wait
Этот системный вызов не создан для межпроцессного взаимодействия, или связи/синхронизации процессов. Этот системный вызов лишь блокирует родительский процесс до тех пор пока потомок не завершится. Почти как read, который ожидает данных, родительская программа просто будет стоять на месте, ожидая что что-то изменится в каком-то из потоков вывода ОС.
Есть также способ сделать вызов wait() неблокирующим. Для этого нужно добавить аргумент WNOHANG. В таком случае, если процесс не завершился то программа не будет ничего ждать, а пойдёт дальше. Ясно дело, предполагается, что wait будет вызван ещё не один раз, чтобы проверить что там с потоком.
Для связи процессов существуют мьютексы и семафоры, а wait, это для завершения процессов.
## Различие между блокирующим и неблокирующим режиме ввода.
Функции read() и write(), могут работать в блокирующем и неблокирующих режимах.
- Блокирующий режим ожидает поступления данных. Если данных нет и не было, функция все равно ждет, и не переходит к следующей инструкции. Такая функция как Windows Media Player: если не удалось открыть видео, программа все равно запустится хоть и не будет ничего показывать.
- Неблокирующий режим, напротив, ничего не ждёт, и при первой же ситуации отсутствия данных функция отдаёт управление. Это можно сравнить с проигрывателем MPV: если формат некорректный или файл поврежден, он моментально закроется, даже не спросив.
То есть, в случае если мы заполняем буфер медленнее чем, читаем из него, то функция в неблокирующем режиме быстренько завершится при первом же исчерпании буфера. Если же данных в буфере изначально не было, то функция завершится даже не подождав пока они там будут. Так что неблокирующий режим подразумевает, что мы вернемся к потоку позже, чтобы дочитать данные.
- Важно, что в обоих из этих режимов, функция завершается при наступлении EOF. Конец файла, означает что читать больше нечего, и следовательно функция в блокирующем режиме завершается. Функция в неблокирующем режиме завершилась бы и так и так, потому что она завершается при первом же отсутствии данных, даже не дожидаясь конца файла.
##Раличие между значениями переменной pid.
Вызов fork() возвращает номер процесса-потомка. То есть, если этот номер равен чему-то, то мы находимся в родительском процессе. Скажем, мы, фигурально, размножились делением, и теперь наш "ребёнок" имеет имя. Если мы знаем его имя, то мы - родитель. Сам ребёнок своего имени не знает. Так что если имени своего ребёнка мы не знаем, то мы и есть ребёнок. Поэтому, если pid == 0, то это именно порождённый процесс, а не наоборот.
У меня сложилась путаница, потому что умозрительно кажется: "ну, когда существовал родительский процесс, никакого ребёнка не было, а вот сделали fork() и что-то появилось, значит у родительского процесса pid == 0, это что - это номер ребёнка и принадлежит самому ребёнку". Нет. Это ложь. Это глупость, так как pid не может быть нулевым. Удобнее было бы называть эту переменную не pid, а child_pid. Если процесс-ребёнок сам" бездетный", то у него переменная pid равна 0, так как номера его потомка пока что не существует. А процесс-родитель всегда будет иметь переменную pid, отличную от нуля, так как у него есть хотя бы один потомок.
##Различие в UDP и TCP.
Почему-то всегда кажется, что UDP, это для файлов, а TCP, для всего. Но нет. И то и другое может быть использовано как угодно. Можно и файл по TCP отправить, и связь построить на UDP. Разница лишь в том, что в UDP, отсутствует соединение как таковое. Всё данные о получаемом пакете лежат в самой дейтаграмме. То есть UDP, это как письмо закидываемое в почтовый ящик. Пакет, отправленный по UPD, можно и пропустить вообще то, и никто ничего не заметит. TCP, это напротив, как личный разговор: перед тем как поговорить, необходимо поздороваться, сесть и начать слушать. И тут уже не получится просто так пропустить пакет, это будет слишком заметно.
##системный вызов wait
Этот системный вызов не создан для межпроцессного взаимодействия, или связи/синхронизации процессов. Этот системный вызов лишь блокирует родительский процесс до тех пор пока потомок не завершится. Почти как read, который ожидает данных, родительская программа просто будет стоять на месте, ожидая что что-то изменится в каком-то из потоков вывода ОС.
Есть также способ сделать вызов wait() неблокирующим. Для этого нужно добавить аргумент WNOHANG. В таком случае, если процесс не завершился то программа не будет ничего ждать, а пойдёт дальше. Ясно дело, предполагается, что wait будет вызван ещё не один раз, чтобы проверить что там с потоком.
Для связи процессов существуют мьютексы и семафоры, а wait, это для завершения процессов.
Как обычно: ЭЛТ-монитор, тяночка, зумерская музыка, случайный предмет. Настроение все равно томное, туман в глазах, мысли не вяжутся. Не могу абстрагироваться.
Перечитал параграф про событийно-ориентированное программирование. Впринципе, понятно что делает вызов select();. Но как его применить, я так и не понял.
Сам по себе вызов select просто блокируется до тех пор, пока один из сокетов не будет доступен на запись или чтение. Это означает, что если вызов select вернул управление, значит в один из сокетов мы можем что-то записать, и он точно не заблокируется. С помощью него, мы можем промониторить сокеты на вопрос возможности принятия данных с них. Проблема как раз у меня возникла в вопросе: "и где мне эти сокеты найти?". Я ведь не знаю сколько в итоге сокетов будет. И следовательно, как я могу добавить их всех в какие-то множества, если я даже и не знаю сколько их. Наверное, надо иметь какую-то сложную схему типо двусвязного списка, чтобы была возможность убрать из него элемент, например когда сокет уничтожается в связи с отсутствиием соединений, и его дескриптор больше не нужен. Но в примере этого нет, там просто Столяров оставил комментарий: "а вот тут перейдите к следующему дескриптору", вообще без указания на то что значит "следующий". Честно, не понял этот пример. Ещё и постоянно задумываешься: а зачем? вроде если каждому клиенту по процессу выдавать - все нормально и логично работает, а тут какая-то возня с этими блокировками наступает.
И как-то не вяжется событийно-ориентированное программирование. Хотя эта тема мне близка. В дипломной работе была спроектирована параметрическая система управления электроприводов мостового станка, на основе конечного автомата Мура. В теорию автоматов я не углублялся, но было ясно, что есть какие-то абстрактные состояния станка, и путем различных событий, он это состояние меняет. Например: нажал кнопку - он пилит.Если он пилит, и в это же время сработал датчик - он останавливается. И эти состояния можно приравнять к состояниям электроприводов: там главный контактор включён, там привод подачи выключен итд. Собственно, такая система, может быть реализована на языке релейной логики. А вот то же самое сделать с программой, я почему-то не могу. Cookie manager, ведь должен просто что-то принять и записать. Как тут какие-то диаграммы строить, если он просто выполняет инструкции и ждёт. Два кружочка Что-ли нарисовать "запись - ожидание". Для такого вроде никаких диаграмм не нужно. А даже если и нарисую, что вообще считать "воздействием". Запись и чтение?
Что я вообще хотел достичь два года назад?
Перечитал параграф про событийно-ориентированное программирование. Впринципе, понятно что делает вызов select();. Но как его применить, я так и не понял.
Сам по себе вызов select просто блокируется до тех пор, пока один из сокетов не будет доступен на запись или чтение. Это означает, что если вызов select вернул управление, значит в один из сокетов мы можем что-то записать, и он точно не заблокируется. С помощью него, мы можем промониторить сокеты на вопрос возможности принятия данных с них. Проблема как раз у меня возникла в вопросе: "и где мне эти сокеты найти?". Я ведь не знаю сколько в итоге сокетов будет. И следовательно, как я могу добавить их всех в какие-то множества, если я даже и не знаю сколько их. Наверное, надо иметь какую-то сложную схему типо двусвязного списка, чтобы была возможность убрать из него элемент, например когда сокет уничтожается в связи с отсутствиием соединений, и его дескриптор больше не нужен. Но в примере этого нет, там просто Столяров оставил комментарий: "а вот тут перейдите к следующему дескриптору", вообще без указания на то что значит "следующий". Честно, не понял этот пример. Ещё и постоянно задумываешься: а зачем? вроде если каждому клиенту по процессу выдавать - все нормально и логично работает, а тут какая-то возня с этими блокировками наступает.
И как-то не вяжется событийно-ориентированное программирование. Хотя эта тема мне близка. В дипломной работе была спроектирована параметрическая система управления электроприводов мостового станка, на основе конечного автомата Мура. В теорию автоматов я не углублялся, но было ясно, что есть какие-то абстрактные состояния станка, и путем различных событий, он это состояние меняет. Например: нажал кнопку - он пилит.Если он пилит, и в это же время сработал датчик - он останавливается. И эти состояния можно приравнять к состояниям электроприводов: там главный контактор включён, там привод подачи выключен итд. Собственно, такая система, может быть реализована на языке релейной логики. А вот то же самое сделать с программой, я почему-то не могу. Cookie manager, ведь должен просто что-то принять и записать. Как тут какие-то диаграммы строить, если он просто выполняет инструкции и ждёт. Два кружочка Что-ли нарисовать "запись - ожидание". Для такого вроде никаких диаграмм не нужно. А даже если и нарисую, что вообще считать "воздействием". Запись и чтение?
Что я вообще хотел достичь два года назад?
И чем я читал код? Вот же, прямо перед носом был второй цикл for, который перебирает все дескрипторы повторно, уже для какого-то дела. Ещё выше, условная конструкция для приёма соединений. Открыл свой предыдущий код - там какой-то случайный мусор написан. Видимо тот день мне было действительно плохо.
Переменная max_fd, нужна только чтобы вызвать select. В книге написано, что первый параметр select, указывает количество значащих элементов в множествах файловых дескрипторов. Из этого я подумал, что первый параметр - это количество дескрипторов в множествах FD_SET. Но в Википедии написано, что первый параметр - это просто номер на единицу больше максимального сокета. И никакое не "количество". Допустим у нас есть три соединения, с дескрипторами 1,2,3,4,5. И вот соединения 2,3,4 взяли и отключились. Тогда у нас сокета осталось два: 1 и 5, но параметр max_fd все равно должен быть 6. Не знаю с чем это связано. Может внутренняя реализация select'а требует знать это число.
Сделал полную версию примера, с односвязным списком для хранения дескрипторов. Сервер выводит сообщения от всех клиентов. Обратно писать им он, к сожалению, не умеет, так как это требует какого-то способа заполнить буфер для ответных сообщений. Делать это необходимо в отдельном процессе, так как основной процесс не может блокироваться на write из стандартного ввода. Основной процесс занят только принятием и отправкой. Если делать отдельный процесс, то это наверное нужно с разделяемыми данными работать, ведь там select работает уже после того, как что-то находится в множествах. Ко всему прочему, нужно ещё и клиентскую программу модифицировать, а она под Windows. Это плюс тканье в гугл, для поиска функций аналогичных unix'овским, типо winsock2, и recv. Это все долго, да и не особо полезно. Главное, изучить фундаментальный функционал, а там уже можно загуглить все необходимое.
Хочется в структуру fd_list добавить ещё два параметра "user_data" и "size", чтобы клиент отправлял размер данных, сервер на это выделял у себя буфер под эти данные, и уже тогда принимал. Сейчас, у всех клиентов буфер общий, на 1024 байт. На качестве сообщений это не отразилось, видимо потому что работу read ничто не может прервать, и он последовательно заполняется и опусташается. Но если бы буфер заполнялся независимо от опустошения, то могли бы появиться проблемы.
Переменная max_fd, нужна только чтобы вызвать select. В книге написано, что первый параметр select, указывает количество значащих элементов в множествах файловых дескрипторов. Из этого я подумал, что первый параметр - это количество дескрипторов в множествах FD_SET. Но в Википедии написано, что первый параметр - это просто номер на единицу больше максимального сокета. И никакое не "количество". Допустим у нас есть три соединения, с дескрипторами 1,2,3,4,5. И вот соединения 2,3,4 взяли и отключились. Тогда у нас сокета осталось два: 1 и 5, но параметр max_fd все равно должен быть 6. Не знаю с чем это связано. Может внутренняя реализация select'а требует знать это число.
Сделал полную версию примера, с односвязным списком для хранения дескрипторов. Сервер выводит сообщения от всех клиентов. Обратно писать им он, к сожалению, не умеет, так как это требует какого-то способа заполнить буфер для ответных сообщений. Делать это необходимо в отдельном процессе, так как основной процесс не может блокироваться на write из стандартного ввода. Основной процесс занят только принятием и отправкой. Если делать отдельный процесс, то это наверное нужно с разделяемыми данными работать, ведь там select работает уже после того, как что-то находится в множествах. Ко всему прочему, нужно ещё и клиентскую программу модифицировать, а она под Windows. Это плюс тканье в гугл, для поиска функций аналогичных unix'овским, типо winsock2, и recv. Это все долго, да и не особо полезно. Главное, изучить фундаментальный функционал, а там уже можно загуглить все необходимое.
Хочется в структуру fd_list добавить ещё два параметра "user_data" и "size", чтобы клиент отправлял размер данных, сервер на это выделял у себя буфер под эти данные, и уже тогда принимал. Сейчас, у всех клиентов буфер общий, на 1024 байт. На качестве сообщений это не отразилось, видимо потому что работу read ничто не может прервать, и он последовательно заполняется и опусташается. Но если бы буфер заполнялся независимо от опустошения, то могли бы появиться проблемы.
Видиш.
Нет, блин, не вижу.
Сегодня вышел, траву потрограть.
Нет, блин, не вижу.
Сегодня вышел, траву потрограть.
Меня никто не любит((
Модератор, пожалуйста, удали тред((я серьёзно))
Модератор, пожалуйста, удали тред((я серьёзно))
Не надо, я люблю. Пиши дальше.
ладно
спасибо
эмо_бой_mode = disable
23 лет отроду.
Характер - скверный, не женат.
Никогда не былъ веселъ. Былъ стыдливъ.
Планирую читать всякую гадость.