А всё-таки, почему не используется такая вещь, как спускаемый салон пассажирских самолётов? Описанный ещё незабвенным капитаном Врунгелем?

     Я скорее вытряс пепел, трубку - в карман, прижал огонь каблуком. Сижу молчу. А тут летчик просунул голову в  кабину,  и  я  несколько  воспрянул духом. Все-таки, думаю, бывалый человек, наверное, не  в  такие  переделки попадал - не терялся, успокоит их, и все уладится... А он, представьте,  и сам струсил.
     Смотрю, побледнел, ахнул, ухватился за какой-то  рычаг...  Трах!  Ну, затем шум моторов утих, только слышно  -  ветер  свистит.  Потом  хлопнуло где-то вверху, как из пушки, кабина вздрогнула,  рванулась  и  тихо  стала приземляться.
     Пассажиры недоумевают, а я сразу догадался,  в  чем  дело.  Теперь-то этим никого не удивишь. А в то время это  было  последнее  слово  техники: устроили такое приспособление на  самолетах.  Называется:  "Ступай  вниз". Если какая авария - взрыв, пожар  или  крыло  отвалится,  -  летчик  одним движением отделяет кабину, и она самостоятельно  опускается  на  парашюте. Полезное приспособление, что и говорить, но в данном случае применение его было явно преждевременным.

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

Само собой, применение такого сбрасываемого салона очевидно, когда катастрофа происходит на высоте. Но и при взлёте (после) или посадке (перед) часто возникают аварийные ситуации (обычно не выпускается шасси или загорается мотор). Тогда лайнер долго-долго кружит, сжигая керосин, а потом начинает аварийную посадку (а на аэродром уже стянуты пожарные и скорые). Не лучше ли будет в таких случаях набрать высоту и сбросить салон? А потом - или самим пилотам прыгать или попытаться всё-таки посадить машину налегке?

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

Тем более что десантирование грузов и техники достаточно хорошо отработано.

---

 

 

1.


2.


3.

А почему для очкариков не выпускают "полевые" очки типа "консервов, скажем?

Как в военной форме, должны быть разновидности очков: повседневные, парадные (= модные, дорогие) и полевые; последние для походов, вождения машины, работы в поле и пр. и пр. - для всех ситуаций, где обычные очки с дужками можно потерять или повредить. ("...У меня в Чили даже очки сдуло в море".)

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

Вот такие "консервы", скажем, только с диоптриями.

А уж как в них обладатель будет смотреться - просто красавцем! Хотя бы так.

В принципе, можно с достаточной уверенностью сказать, что концепция компиляции программ в современных компьютерах вследствие их быстродействия практически изжила себя и остаётся востребованной лишь в тех критических областях, где производительность остаётся проблемной.
Так не перевести ли Открытый Код повсеместно на скрипты?
Впрочем, имеет смысл и прекомпиляция, когда скрипт автоматически приводится к некоей канонической, но человекочитаемой форме (фиксированная расстановка пробелов, операторов, адресация посредством закомментированных указателей на строки). В результате программные баги могут легко самостоятельно устраняться относительно продвинутыми пользователями!
Возможно выполнение скриптов с авторским ключом, т.е. с автоматической промежуточной расшифровкой зашифрованного исходника (что переводит данный модуль де-факто из Открытого кода в Закрытый).

Если внимательно посмотреть на работу компьютера, то легко увидеть, что прикладные программы по сути делятся на 2 разряда: файловые манипуляторы (тот же Обозреватель хотя бы, получивший нелепое название "проводник") и все прочие. Первые по сути своей должны иметь доступ на запись к большей части памяти; вторые прекрасно могут обойтись доступом на запись лишь к подпапкам той папки, в которую они установлены.
Разделим память на 3 категории:

1. пользователя ("Мои документы");
2. техническую ("Temp");
3. прочую.

В (1) и (2) можно записывать данные посредством любой программы; в (3) - только зарегистрированными программами манифуляции файлами. Т.е. в ОС, как на Интернет-серверах, установлен изначальный запрет на запись в папки для внешних программ, кроме нескольких.
Естественно, такая концепция однозначно отвергает некогда триумфально заявленную концепцию реестра и возвращает нас к инсталляции программ посредством INI-файлов, которая ей как раз не потиворечит.

Теперь вспомним про Защищённый (безопасный) режим (в который можно войти только при загрузке. Установим правило: регистрировать программу с правом полной записи по всей памяти можно только в нём.

Бросив взгляд на ОС, модифицированную по таким нехитрым правилам, можно увидеть, что пространство для действия внешнего вредоносного кода окажется как минимум резко суженым.

Мысль такая. А не имеет ли смысл оборудовать станции слежения за Землёй на... Луне?
Полёт на Луну дорог и сложен; легче, конечно, что-то просто запустить на земную орбиту. Но зато лунные станции (в чём-то подобные антарктическим) не имеют ограничений на габариты ("селенонавтам" не надо ютиться в крошечной хрупкой конуре), не имеют проблем с ориентацией, навигацией, коррекциями орбиты и т.п. Вдобавок на организм участников "экспедиций" (т.е. попросту, вахт) будет влиять не невесомость, а всего лишь пониженное тяготение, что, несомненно, является более щадяшим фактором.
Расстояние до Земли дальше. Но для современной оптики это, возможно, не принципиально. Если не так, то на Луну следует перенести глобальные и долговременные наблюдения, оставив ситуационный мониторинг за орбитальными станциями. Вдобавок туда можно будет перетащить мощнейшие телескопища - опять же не для наблюдения за "зелёными человечками", а за самыми обычными двуногими, ползающими по Голубой Планете.

В университете Лидса ученые разработали прибор, который ежегодно будет экономить миллиарды литров воды. Новинка использует на 10% меньше воды и на 30% меньше электроэнергии, чем обычные стиральные машины.

 

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

Комментарий циника.

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

 

А почему турбины в самолётах не прикрывают решётками (сетками)?

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

---

И ещё.

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

Проект может быть реализован в двух вариантах: гуманном и негуманном.

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

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

А вот ещё мысль.
Дирижабль, у которого оболочка поворачивается по ветру.
То есть "сигара" узким концом смотрит против ветра, а сам он летит по курсу.
Это было бы рациональнее?

А интересно, если морские суда (танкеры, сухогрузы, даже пассажирские лайнеры) сделать по типу подлодок, чтобы, получив штормовое предупреждение, они погружались в море, а при хорошей погоде опять всплывали, - не будет ли это выгоднее? Чем когда они будут болтаться и даже тонуть? И тем, кто на борту, легче.

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

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

А насколько перспективна вот такая идея самолёта ВВП: винты вертикальной тяги расположены в плоскости крыльев и в полёте закрываются шторками?

Обычно в крылья (на гражданских лайнерах точно) заливают топливо. Здесь для топлива придётся искать другую ёмкость; например, над или под салоном. Это, кстати, упростит управление, поскольку система размещения топлива в крыльях требует большой точности в поддержании баланса.

Подробности в Приложении.

---

Оказывается, моя идея не нова.

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

Но вот ни разу я о ВВП-самолётах такого типа не слышал. Были ли такие проекты?

Идея: наполнить оболочку дирижабля блоками (сетками) из воздушных шариков, общая подъёмная сила которых должна быть несколько меньше веса аппарата. Дополнительная подъёмная сила образуется за счёт газа в оболочке.

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

Подробности в Приложении.

 

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

Почему бы не ездить уже с надутыми (или полунадутыми) подушками безопасности?

Тогда при аварии их надо будет только слегка поддуть.

Намного проще. А пассажиру/водителю всё равно нехуй делать в салоне. (Для водилы можно разработать подушки особой формы, чтобы не мешали рулить.)

 

0. Постановка проблемы

 

Работая с документами формата HTML (в частности, на веб-сайтах), я пришёл к выводу, что требуется расширение языка разметки HTML на графические форматы.

В настоящее время графические объекты вставляются в HTML-документ двумя способами. Во-первых, как внешние посредством элемента <IMG SRC=источник> (вариант - элемент <OBJECT> ), когда рисунок не является частью документа. Во-вторых, как внутренний код посредством атрибута TYPE="/IMAGE"; при этом рисунок опять же выпадает из языка разметки.

Похоже, настала пора внедрять рисунки не просто в документ, а и в сам язык разметки, при желании структурируя само изображения и распространяя на него тем самым DOM-структуру - мощное средство оперирования данными в документе.

Предлагается вариант расширения языка HTML на графически объекты.

 

1. Векторная графика

 

Работа с векторной графикой может быть построена по образцу элемента <AREA>. А именно, в элемент <IMG> добавляются атрибуты: SHAPE со значениями RECT, CIRCLE, POLY, LINE, ARC (для прямоугольника, круга, многоугольника, линии и дуги); COORDS для указания координат и, возможно, COLOR для указания цвета границы (хотя этот атрибут можно задать через стиль). Новыми здесь являются атрибуты LINE для обозначения линии в паре с атрибутом COORDS="x_нач, y_нач, x_кон, y_кон" и ARC  с атрибутом COORDS="x_нач, y_нач, x_кон, y_кон, отклонение" (максимальное отклонение дуги от базовой линии). (Хотя, возможно, атрибут LINE излишний, поскольку может быть выражен через атрибут POLY с двумя парами значений в COORDS.)

Тогда, скажем, японский флаг в верхнем углу документа (взятый для примера как одно из самых простых графических обозначений) может быть изображён помещением в соответствующее место следующего кода:

 

<IMG SHAPE=RECT COORDS="0, 50, 150, 0" STYLE="position: relative; color: black; background-color: white; border-width: thin">

<IMG SHAPE=CIRCLE COORDS="75, 25, 20" STYLE="position: relative; background-color: red; border-width: none">

 

А вот предполагаемый код для рисования перечёркнутой окружности:

 

<AREA NAME=имя>

<IMG SHAPE=CIRCLE COORDS="10, 10, 10">

<IMG SHAPE=LINE COORDS="0, 0, 10, 10" STYLE="position: relative">

</AREA>

 

(Элемент AREA будет объяснён далее.)

 

2. Растровая графика

 

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

Растр в своей основе представляет собой таблицу; поэтому логично было бы использовать для его представления элемент TABLE с подчинёнными элементами TR и TD (последний при этом становится неконтейнерным, поскольку текста внутри нет); границы ячеек растра, разумеется, нулевой толщины. Для этого следует элемент IMG, наоборот, сделать контейнерным, т.е. способным содержать подчинённые элементы: <IMG>...</IMG>.

 

<IMG>

<TABLE>

  <TR HEIGHT=высота>

    <TD ROWSPAN=22 BGCOLOR=цвет/>

    ...

    <TD BGCOLOR=цветWIDTH=ширина/>

  </TR>

  ...

  <TR>

    <TD COLSPAN=8 BGCOLOR=цвет/>

    ...

    <TD BGCOLOR=цвет/>

  </TR>

</TABLE>

</IMG>

 

3. Тиражирование графических элементов

 

Рисунок может не только внедряться "живьём", но и вставляться посредством ссылки. Скажем, выше приведён пример, когда два элемента IMG помещены внутрь элемента AREA с атрибутом NAME. Предполагается, что AREA группирует подчинённые элементы в единый комплекс; этот комплекс может быть вызван посредством кода <IMG SRC="#имя">, где имя - это имя комплекса AREA. Использование <IMG SRC="#имя"> позволяет размещать один и тот же графический элемент в разных местах документа.

Одним из важных применений такого метода может быть воспроизведение экзотических символов, например, из старинных текстов. Скажем, приведённую выше перечёркнутую окружность можно считать изображением буквы Ø. Для использования встроенной графики в таком качестве имеет смысл снабдить элемент IMG ещё атрибутом SIZE со значениями либо "ширина, высота" (т.е. совмещение пары "WIDTH, HEIGHT"), либо со специальным значением FONT, означающим, что рисунок по ширине и высоте вписывается в базовый размер символа текущего шрифта.

 

4. Дополнительные рассуждения

 

В отношении растровых рисунков можно предвидеть очевидное возражение: внедрять в документ такую графику нецелесообразно, поскольку обработка многочисленных тэгов табличного типа должно сильно затормозить его загрузку. Ну, во-первых, на это можно сказать, что в иных документах (например, в письмах) рисунки записываются в коде Base64, по рациональности тоже не особенно оптимальном, но достаточно легко обрабатываемым. Во-вторых, всё хорошо в меру; широкоформатные фотографии с большим разрешением, действительно, вряд ли имеет смысл запихивать внутрь документа, тогда как схемы, эмблемы, иконки и т.п. вполне можно туда поместить. Особенно это будет рационально для одноразовых рисунков, т.е. предназначающихся только для данного документа, которые не имеет смысла помещать отдельно.

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

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

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

 

<IMG SHAPE=CIRCLE COORDS="50, 50, 50" STYLE="border-width: thin">

<IMG SRC="#point_5" STYLE="left: 40; top: 60"><IMG SRC="#point_5" STYLE="left: 60; top: 60">

<IMG SHAPE=ARC COORDS="30, 20, 80, 20, 0" STYLE="position: relative; background-color: black" ONMOUSEOVER="VBSCRIPT: Me.coords.height = 10" ONMOUSEOUT="VBSCRIPT: Me.coords.height = 0">

<!-- Предполагается, что coords.height - это высота дуги, 5-я позиция атрибута COORDS -->

 

...

<IMG SHAPE=CIRCLE COORDS="5, 5, 5" STYLE="position: relative; background-color: black" NAME="point_5">

 

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