Redox — операционная система, написанная на Rust

Это не решает проблему терминологии, лубое ПО можно назвать виртуальным устройством. Например Google Chrome можно назвать виртуальным устройством для просмотра веб страниц - мы в это устройство шлем URL и команды управления а оно нам отдает картинку и звук ...

Имеется в виду абстракции на уровне ОС, а не прикладного ПО.

нет ничего общего с С, кроме нескольких зарезервированных слов

Создатели старались максимально скопировать синтаксис Си с добавлением фич и без превращения языка в крестоподобное говно. Впрочем, у них, ИМО, не очень получилось без превращения в говно.

тип данных следует за именем

И в большинстве случаев не указывается, а выводится компилятором. Кстати, ИМО, такое объявление переменных тупо естественней для языков с выводом типов - не надо придумывать дебильные «специальные» типы вроде auto. И это если не упоминать о том, что это проще парсится и сложные типы проще читать.

То же самое с возвращаемым значением из функций

Для консистентности с объявлениями переменных.

2 стандартных способа передачи аргументов - по значению и ссылке

По твоей логике, Си тоже 2 способа - по значению и указателю.

Стандартный «println» просто содран из паскаля

Кроме названия, ничего общего. Что изменится, если назвать его printf?

Кроме названия, ничего общего.

В Паскале writeln :)

Как бы неэтично рекламировать свои разработки в теме про «конкурируюий» продукт, но вот - http://l4os.ru

В проекте почти всё, включая libc, написано вот этими пальцами, которыми набираю это сообщение. Разумеется, полную поддержку POSIX я не осилил, но возможно по функционалу приближается к первым версиям стандарта.

Планировщик там нужен лишь изредка - под нагрузкой, когда нити конкурируют за машинное время. В обычном режиме треды успевают заблокироваться (предварительно отработав системный вызов) до того как истекает квант времени нити. Т.е. большую часть времени система «спит», как и все современные ОС.

Проект пока ждёт своего «звёздного часа», а в последние годы я неспешно пытаюсь реализовать нечто, созданное по образу и подобию L4 Pistachio, в железе на ПЛИС. Разработка идёт очень медленно и долго, но зато есть время подумать.

Не хочу говорить за другие микроядра, но L4 Pistachio вплотную близок к идеальному микроядру.

А, вот ещё что, я реализовал стартовый протокол, который позволяет запускать системные сервисы как в контексте микроядра, так и в виде процесса. В случае, если сервис работает как процесс, то есть незначительное замедление, вызванное переключением адресных пространств (дать количественную оценку я не готов), но такой подход позволяет проводить пошаговую отладку драйверов и легко ловить ситуации, при которых Windows уходит в BSOD, а Linux в Kernel Panic.

Без проверок прав доступа - да. С проверками - со скоростью беда.

по идее проверка нужна только один раз - когда в таблицу страниц вносишь запись. дальше пользуйся свободно тем, что доступно

такой подход позволяет проводить пошаговую отладку драйверов

и при чем тут микроядра ? в Linux есть KGDB

легко ловить ситуации, при которых Windows уходит в BSOD, а Linux в Kernel Panic

для этого пошаговая отладка не нужна да и вообще

http://elinux.org/Debugging_Portal

Проблема c read который читает в свой буффер будет в том что возможно нам нужно было читать совсем не туда (мы пытаемся дочитать не доконца вычитаный буфер)

да, верно. и именно что придется менять подход к написанию софта.

другое дело, что никто не мешает поверх этого реализовать слой posix-совместимости, который, конечно, будет тормозить, зато базовая система останется чистенькой и быстрой

потом както сигнализировать системе что пришедший буфер нам уже не нужен и система его может использовать повторно. А это опять накладные расходы на свой хип

какая разница, один хип у тебя или 50?

+ возможные мемори лики.

да просто в RAII обернуть

глючить

только если у автора кривые руки

тормозить?

open(«/path/file») у тебя тоже тормозит? разрабы идиоты, надо было вместо имен файлов только номера инодов использовать?

Пруф: количество софта и рыночные доли венды и люникса

толсто

Нормально, только быдло трет комменты

Скорее ты просто не понимаешь, о чем говоришь. И/или просто не знаешь о версионировании в COM и RPC.

Скорее, кое-кто пытается показать свои знания там, где они попросту не нужны. Думаю, лучше сначала ЧЁТКО ПОНЯТЬ, что предлагают другие, а потом уже сверкать подробностями других технологий (и не факт, что эти «подробности» нужны тут, в API).

какая разница, один хип у тебя или 50?

Большой разницы конечно нету, но это усложнает систему (сейчас есть статика есть 1 хип, а так будет локальный хип, хип для дискового I/O, хип для сетевого I/O и т.д). А просадка будет в том что хип подсистем (например хип для дискового I/O) будет иметь высоконкурентную нагрузку (много независимых процессов будут одновременно работать с ним), а как известно накладные расходы на межпотоковую синхронизацию увеличиваются с ростом конкурентности.

Да просто в RAII обернуть

Проблема не только в том что ПО может «потерять» буфер, например некий злоумишленик (студент на общем сервере в университете) запускает ПО которое специально (или по глупости) делает большое количество READ и не освобождает используемые буфера. Что делать в таком случае ? Наращивать IO heap пока модуль ввода/вывода не получит out-of-memory ? Для каждого процесса вести учет используемых буферов и ограничивать потребление памяти на вводе/выводе? (опять таки накладные расходы) + Нужно хранить списки буферов за каждым процессом (если процесс вдруг крашнулся нужно освободить все буфера которые были за ним закриплены).

Я все это к тому что в микроядерной архитектуре проблем намного больше чем в монолитной (с точки зрения организации эффективного ввода вывода). Всетаки не просто так подовляющее большинство современных ОС это системы с монолитным ядром.

Я знаю простую вещь - версионирование интерфейсов никому не удалось убрать. То есть вообще.

Думаю, лучше сначала ЧЁТКО ПОНЯТЬ, что предлагают другие

Ты ровно ничего не сказал о том, каким волшебным образом старые программы будут работать с новыми интерфейсами.

> Значит ты не понял концепции. Или я не понял, где ты нашёл проблему.

Всё верно он сказал.

Верно, но для какой-то своей собственной идеи в голове. В моей идее нет проблем или вы их пока не озвучили внятно.

Вам какая принципиальная разница, называется ваше API

Разница в самой архитектуре. COM - это хорошая идея, запоротая дебилами из M$ (WPF - похожий пример). Я предлагаю некое подобие КОМ, но не надо как бабы сразу кидаться на первое знакомое слово - смотрите на концепцию, а не детали.
Концепция такова, что мы можем ДИНАМИЧЕСКИ, не трогая ядра, улучшать практически любой её модуль. Причём даже не трогая компилятор вообще.

и при чем тут микроядра ? в Linux есть KGDB

Как бы изначальный тезис был о том, что запуск модулей ядра в выделенных адресных пространствах это не основное, не обязательное и не самое главное свойство микроядер.

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

Я знаю простую вещь - версионирование интерфейсов никому не удалось убрать.

Зависит от степени замороченности архитекторов и их целей! Если ты хочешь работать в стиле M$ (совместимость любой ценой), то и получаешь весь геморой с версиями и эйфелеву башню костылей.

Я считаю, что если какой-то API дожил до полного deprecation, у тебя есть два выхода: либо переписывать устаревшую часть кода клиентов этого API (что не так уж и сложно), либо НЕ ОБНОВЛЯТЬ дрова и сидеть в работающей системе.

Я _сейчас_ не вижу никакого смысла (опять как бабы) влезать в мелкие подробности вроде версионирования, НАДО - СДЕЛАЕМ. Суть не в них, а в общей архитектуре - сейчас Линукс-ведро просто свалка этих API и расшевелить этот гадюшник нереально - всё просто упадёт, ибо глиняный монолит. Нам нужна ОС, которая не будет прибита гвоздями сама к себе - т.е. микроядро и как можно более гибкий способ иметь заменяемые компоненты, не требующие перекомпиляции всей системы.

В конечном итоге твоя ссылки так ничего и не показала(кроме того, что оно тормазит в дерьмо) на допотопной хреноте, а ни на чём новом оно не запускается.

https://os.inf.tu-dresden.de/pubs/sosp97/diag1.gif

Тормозит 1 поколение микроядер (MkLinux) по сравнению с ним второе поколение (L4Linux) выглядит весьма неплохо, по сравнению с чистым Linux оно проигрывает в всего в 2 иногда в 2.7-2.8 раза.

Насколько я понимаю - прогресс он должен быть к более быстрому и иллитному, а не к более убогому и не работающему.

Прогресс на лицо, MkLinux хуже Linux на порядок, а не в 2-3 раза.

И да, иногда производительность < безопасность...

Ты ровно ничего не сказал о том, каким волшебным образом старые программы будут работать с новыми интерфейсами.

В COM принято добавлять новые интерфейсы, оставляя при этом старые. И там это вполне неплохо работает. Вот чего (на мой взгляд) неудачно реализовано в COM это «позднее связывание». Microsoft попыталась объять необъятное и вышло как-то не очень удачно.

Несмотря на то, что сейчас Microsoft не пиарит COM, а придумывает новые технологии, половина Windows внутри основана на COM. Просто это не видно за добрым десятком надстроек сверху.

Как бы неэтично рекламировать свои разработки в теме про «конкурируюий» продукт, но в

Расеянцы делают ось/дистр обычно для распила бюджетного добра бабла. Скажите честно, вам нужна каръера Альт Линукса?

Не хочу говорить за другие микроядра, но L4 Pistachio вплотную близок к идеальному микроядру.

Я всегда считал мироядро Таненбаума идеальным, что с Minix3, не так?

Если же вы V4L не реализовывали и для использования камыры темже Skype нужны будут отдельные телодвижения (модификация кода или прелоадинг специальных библиотек) - то это уже драйвером назвать нельзя.

То есть, если кто-то написал модуль ядра Linux, реализующий доступ к веб-камере не через V4L, а через какой-то другой интерфейс, то этот модуль нельзя назвать драйвером?

Вот это поворот!

Не стоит путать драйверы и стандартные интерфейсы драйверов определенных классов устройств.

Я _сейчас_ не вижу никакого смысла (опять как бабы) влезать в мелкие подробности вроде версионирования, НАДО - СДЕЛАЕМ

А, ну тогда конечно.

Суть не в них, а в общей архитектуре - сейчас Линукс-ведро просто свалка этих API и расшевелить этот гадюшник нереально - всё просто упадёт, ибо глиняный монолит. Нам нужна ОС, которая не будет прибита гвоздями сама к себе - т.е. микроядро и как можно более гибкий способ иметь заменяемые компоненты,

Я так понимаю, вопрос «что делать, когда поплывут интерфейсы между компонентами», задавать бесполезно. Напоминать, что ОС - это только нижний компонент программного стека - тоже.

А как концепция абстрактных интерфейсов (тотже COM) решает проблему версионности?

Например возмем старую модель сетевого драйвера Linux (Old API) У нас драйвер сетевого интерфейса вешался на прерывание и через колбек передовал пакеты сетевому стеку (при этом сам выделял буфера для него).

В новом API (New API) концепция поменялась, и теперь система сама опрашивает драйвер на предмет новых пакетов и предоставляет буфера для их получения, зато на откуп драйвера перешли функции работы с чексумами и фрагментирования.

В результате сам API (читай COM интерфейс) стал обсолютно другим (старых методов не стало, новые появились) и проблема версионности она никуда не делась. И в переходной период нужно было либо ядром супортить обе модели драйверов, либо самим драйвером супортит оба API - собственно это и есть проблема версионности.

Не хочу говорить за другие микроядра, но L4 Pistachio вплотную близок к идеальному микроядру.

А что такое идеальное микроядро?

В COM принято добавлять новые интерфейсы, оставляя при этом старые. И там это вполне неплохо работает.

Ну да, еще как в SunRPC. И, в общем-то, в Linux тоже так. Не понимаю я новизны предложения.

Например, сбой в драйвере не приведёт к краху системы, а лишь к аварийному завершению драйвера.

по мне так драйверы должны быть написаны так чтобы его крах не приводил к краху системы - микроядро или монолит тут никакой разницы нет

В каких-то критических применениях это может спасти жизни

сомневаюсь что в критически важных системах микроядро будет достаточным условием, обычная практика в таких сисемах - резервирование с аппаратной избыточностью.

Расеянцы делают ось/дистр обычно для распила бюджетного добра бабла. Скажите честно, вам нужна каръера Альт Линукса?

Я сейчас не готов обсуждать эту тему. Потратить много лет, чтобы выйти на уровень Альт Линукса - это фейл. При всём уважении к команде Альт Линукса. Цели у нас разные.

Я всегда считал мироядро Таненбаума идеальным, что с Minix3, не так?

Честно - не смотрел. Некий фанатизм с моей стороны позволяет не опускать руки. И кстати, игнорирование чужих разработок позволяет избежать траты времени на споры в Интернете. Возможно что у Minix3 можно позаимствовать некоторые идеи, но пока своих на 10 лет вперёд.

То есть, если кто-то написал модуль ядра Linux, реализующий доступ к веб-камере не через V4L, а через какой-то другой интерфейс, то этот модуль нельзя назвать драйвером?

Это хороший аргумент :)

Но сдесь все будет зависить от того потребовалась ли модификация самого Linux ядра, либо этот ктото использовал уже существующую абстракцию (например блочное или символьное устройстов, или файловую систему).

А что такое идеальное микроядро?

http://www.l4ka.org/l4ka/l4-x2-r7.pdf

Ну да, еще как в SunRPC. И, в общем-то, в Linux тоже так. Не понимаю я новизны предложения.

Предложение старо как мир. Но COM (ИМХО) пока наиболее продвинутый из всех существующих. Если выкинуть оттуда лишнее, кое-что изменить, кое-что добавить, то... в общем, хорошо получится.

Создатели старались максимально скопировать синтаксис Си с добавлением фич

Мне только «println», да «fn» перед функциями хватило, чтоб понять чем вдохновлялись авторы. Не скажу что это что-то плохое, но С тут и не пахнет.

И в большинстве случаев не указывается, а выводится компилятором.

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

не надо придумывать дебильные «специальные» типы вроде auto

Ну зачем же сразу ниже пояса? Разработчикам 11 стандарта просто не по карману консультации ЛОР-овских аналитиков. Вот и городят черти-что.

И это если не упоминать о том, что это проще парсится и сложные типы проще читать.

Кстати, простота компиляции - одна из киллер-фич паскаля. Сложные же типы появляются в результате использования шаблонов и вложенных классов/неймспейсов. Это все не про С.

По твоей логике, Си тоже 2 способа - по значению и указателю.

Я знаю, что в rust ссыслка может быть не только в параметрах функции. Но в этом контексте она как раз эквивалентна паскалевскому «var». И если сишный указатель - это то же самое, то покажи как просто можно передать через rust-овую ссылку NULL? Что там есть аналогичного указателю на void?

Кроме названия, ничего общего. Что изменится, если назвать его printf?

printf - это сокращение от print formatted. Название акцентирует внимание на форматых вывода, а не на снесении всех текстовых констант в первый аргумент (если уже говорить об отличиях от println)

Боюсь, что пока Линус с Лёней

Не бойся — я разрешаю.

Тормозит 1 поколение микроядер (MkLinux) по сравнению с ним второе поколение (L4Linux) выглядит весьма неплохо, по сравнению с чистым Linux оно проигрывает в всего в 2 иногда в 2.7-2.8 раза.

Нет, не существует никаких поколений. Это всё булшит.

по сравнению с чистым Linux оно проигрывает в всего в 2 иногда в 2.7-2.8 раза.

Я запустил - оно не работает. Меня интересует только то, что я могу проверить. Балабольство меня не интересует, да и никого интересовать не должно.

Прогресс на лицо, MkLinux хуже Linux на порядок, а не в 2-3 раза.

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

Я придумал гениальную идею - хреначим дерьмо и сразу же выкатываем «первое поколение», вставляя sleep(100500) в каждую дыру.

При этом даже сравнивая с линуксом сейчас, где всё осталось на уровне 200тактов. Т.е. в линуксе не то, что первое - там минус первое поколение и если это реализовать нормально - там не будет 200тактов.

Я лично не представляю что там можно делать 200тактов.

И да, иногда производительность < безопасность...

Есть реальное, а есть брехливое. Каждый алёша кукарекает о том, что он напишет на расте/жабке/пхп - новый опенссл, новый линукс и прочее, которое будет безопасней и не упадёт.

Время идёт - созданы тонны куллязычков - они уже с нулевых годов обгоняют сишку по всем параметрам, а до сих пор сливают сишному дерьму из 70-х по всем параметрам.

Вернее как сливают - их просто нету. А ну да - есть жабкассл в 50-100раз тормазнее - бывает. Это не проблема и скоро она догонит. Мы верим в это.

И в переходной период нужно было либо ядром супортить обе модели драйверов, либо самим драйвером супортит оба API - собственно это и есть проблема версионности.

Вы так рассуждаете, будто моя (абстрактная) система существует уже сто лет и в ней всё криво и тут вылилась проблема - есть два АПИ! Нет никакой ложки, понимаете? Вы сейчас решаете проблемы, которые могут даже не возникнуть, вместо того, чтобы сконцентрироваться на самой идее и подумать, какие _серьёзные_ проблемы её могут ожидать.

Для вашего случая есть море решений и нет никакой проблемы. Варианты:
1. Есть дорогое ПО, которое требует старое АПИ. ПО переписывать некому, поэтому тупо сидим на старом ПО/дровах, все счасливы.
2. Есть улучшаемое ПО. Обновляем дрова, обновляем ПО, нет проблемы.
3. Есть улучшаемое ПО, но есть старые перделки, требующие старое АПИ. Решаем по степени важности вплоть до того, что создаём НОВУЮ ВЕТВЬ, которая будет отвечать за новое АПИ. Например: было HW/Network/Eth, эту ветвь оставляем и создаём HW/Network/Ethernet под ВСЕ новые дрова. Кто захочет - обновит дрова и они (разные lib) будут висеть в разных ветках.

Ваша «проблема» не стоит выеденного гроша, какой смысл её сейчас обсуждать?
Мне интересна не мышиная возня в крошках, а сам хлеб - взлетит система с динамическим АПИ а-ля регистри?

Т.е. в линуксе не то, что первое - там минус первое поколение и если это реализовать нормально - там не будет 200тактов.

Думаю, Торвальдс будет рад принять от тебя такой патч. (Голосом робота Вертера) Ха. Ха. Ха.

Некий фанатизм с моей стороны позволяет не опускать руки. И кстати, игнорирование чужих разработок позволяет избежать траты времени на споры в Интернете.

Да у вас батенька NIH-синдром. Не лечится.

Где позиционирование системы? Где нескучные обои?

И тут некоторые товарищи поднимали вопрос Haiku, Minix и прочее говно мамонта. Так вот, их время ушло, победил Linux. Открыты двери для новых ОС, с новыми концепциями, но никто не хочет войти в эту дверь. Судари-программисты, ссут-c вестимо...

Я так понимаю, вопрос «что делать, когда поплывут интерфейсы между компонентами», задавать бесполезно.

Ты сейчас напоминаешь дотошного (в плохом смысле) прораба, который смотрит на пустое поле под будущий город и тыкает в воображаемый туалет «а где тут вешать бумагу-то?!».
Концепцию я объяснил. Тратить время на несуществующие детали (которые даже мне сейчас неизвестны) - нет смысла.
Я озвучил концепцию, которая куда привлекательнее «всё есть URL». Оч надеюсь, авторы Redox вовремя одумаются, ибо их «тырнет головного мозга» зашкаливает.

Концепцию я объяснил.

Хм. Нельзя ли ссылку на пост или посты с объяснением? Похоже, я его пропустил.

Да у вас батенька NIH-синдром. Не лечится.

Я бы согласился, но Pistachio же not invented here.

Открыты двери для новых ОС, с новыми концепциями, но никто не хочет войти в эту дверь.

Например?

Где позиционирование системы? Где нескучные обои?

Доки почитай, чё на форуме шуметь?

И тут некоторые товарищи поднимали вопрос Haiku, Minix и прочее говно мамонта. Так вот, их время ушло, победил Linux.

Линукс «победил» не больше, чем смертельно заражённый, крупный бык, лезущий в толпу - все понимают, что это уже не жилец, но толкать не торопятся.
«Успех» на рынке ИТ очень размытое понятие. Завтра появится какой-нибудь SuperPupperOS и бывшие апологеты Линукса закидают Трольвадса ссаными тряпками и встанут под новые знамёна. Получится вот такой вот «неожиданно зассаный революционер». ;]
Новые ОС нужны, потому что от существующих дурно пахнет и они, прямо говоря, себя изжили.

Открыты двери для новых ОС, с новыми концепциями, но никто не хочет войти в эту дверь.

Входят многие, ИДУТ не все. Для «идут» требуется громадная работа, неплохие стартовые деньги и верная концепция. Пока что даже с «концепциями» тухляк - вон, уже на URL накинулись от пустоголовья!

Хм. Нельзя ли ссылку на пост или посты с объяснением?

Охотно! Только это краткий коммент, а не «пост».

Redox — операционная система, написанная на Rust (комментарий)

ты случайно не dbus изобрел?

Это маниловщина. Никаких проблем эта «концепция» не решает. Единственное, что в ней хорошего (подразумевается) - вместо фиксированного набора read/write/ioctl драйвер получает приличный RPC. Всё.

Redox — операционная система, написанная на Rust (комментарий)

Очень похоже на внутренне устройство ядра Windows NT. Только там тоже Read/Write/Open/Close и аналог Ioctl

Очень похоже на внутренне устройство ядра Windows NT

В NT нет интроспекции.

Я бы согласился, но Pistachio же not invented here.

какое-то нелепое оправдание, впрочем мало кто в состоянии признать своих тараканов отклонением

игнорирование чужих разработок позволяет избежать траты времени на споры в Интернете

шедевр просто

Для вашего случая есть море решений и нет никакой проблемы. Варианты:

Есть одно решение для всех проблем.

Старьё живёт на старье, а то, что новое - оно итак адаптируется. Правда проблема в том, что линукс, да и другая ОСь, как и любой другой софт не принадлежит себе, а является исполнителем воли того - кому никакая смена не то что не интересна, а наоборот вредна.

Завтра ты меняешь полностью концепцию - и всё. Старый софт теряет конкурентоспособность, которая была у него благодаря тому, что реализовать на текущей концепции реализовать что-то вменяемое просто не реальное и оно максимум будет чуть лучше.

Так что твои решения - неприемлемы и не будут приняты никогда.

чем вдохновлялись авторы

Эм... Логикой и здравым смыслом?

С тут и не пахнет

А как же фигурные скобки, звёздочки, угловые скобки, амперсанды и прочая дрянь?

Если злоупотреблять автотипированием, получишь код, который без подсказок IDE читать невозможно.

Это случается, если злоупотреблять плохим наименованием переменных. Олсо, на всяких Питонах и Рубях пишут как-то читабельный код, а там аннотации типов вообще почти не используются.

Разработчикам 11 стандарта просто не по карману консультации ЛОР-овских аналитиков. Вот и городят черти-что.

В отличие от своих оппонентов, ЛОРовские аналитики в курсе, что ключевое слово auto стали использовать для этих целей потому, что оно уже было зарезервировано в Си в тыща девятьсот лохматом году, чтобы обозначать размещение переменных на стекэ (в противоположность слову register), но не использовалось в C++ от слова совсем, вот и пихнули свободное относительно подходящее по смыслу ключевое слово. Так что просто повезло, а то сделали бы какой-нибудь __var, и было бы ещё веселее. Олсо, оппонентам лоровких аналитиков пора бы уже вырасти из аргументов ad hominem.

Сложные же типы появляются в результате использования шаблонов и вложенных классов/неймспейсов.

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

Я знаю, что в rust ссыслка может быть не только в параметрах функции. Но в этом контексте она как раз эквивалентна паскалевскому «var».

Окей. Тогда и в С++ ссылка эквивалентна паскалевскому var. Скажешь, труп страуса тоже увлекался заимствованием из Паскаля?

Название акцентирует внимание на форматых вывода

Растовское название акцентирует внимание на том, что println служит для вывода и что оно отличается от printf, ибо синтаксис форматирования не сишный и добавляется перенос строки в конце.