Balancer: Все сообщения за 14 Июня 2016 года

digger> Радикальноие решение - свой Офис

OpenOffice/LibreOffice. Если делать своё и с нуля, то это порядка 100 человек команды, работающих в течении 5 лет. Что-то около $100 млн в российских реалиях.

digger> был же в свое время Лексикон без вирусов и лучше Ворда.

Только под DOS. Это были времена, когда конкурентоспособный продукт можно было разрабатывать в одиночку или командой из нескольких человек. Уже с массовым приходом Windows 3.1 и переходом на графический интерфейс Лексикон сразу проиграл Word'у.

digger> С точки зрения эксплоитов и взлома наиболее безопасная ОС в наше время - iOS

iOS или MacOS? Первая практически непригодна в роли ОС общего назначения из-за жесточайших ограничений. Там же даже файловой системы обычной для приложений нет.

А MacOS в плане вирусов ничуть не лучше той же Linux.

•  31
•  инфо
•  инструменты
• Ответить на сообщение

Balancer>> OpenOffice/LibreOffice. Если делать своё и с нуля, то это порядка 100 человек команды, работающих в течении 5 лет.
V.Stepan> Эти оба не с нуля, в девичестве были StarOffice.

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

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

V.Stepan> Тем более, что за 5 лет разработки проект устареет. Так что кол-во программистов однозначно надо увеличивать.

Я грубо учёл сроки и людей на этот процесс.

>составило 485 человек.

Это по числу коммитеров за всю историю проекта, включая тех, кто по несколько строк закоммитил. Более-менее активных разработчиков там, как раз, под сотню, наверное. И работают они не по расписанию за зарплату Так что эффективность наёмных программистов будет повыше.

•  22
•  инфо
•  инструменты
• Ответить на сообщение

Вопроса не понял Ты о том, какие вообще бывают диоды?

— Ртутные — это понятно.

— Электрохимические:

•  2
•  инфо
•  инструменты
• Ответить на сообщение

Balancer>> OpenOffice/LibreOffice.
digger> Там тоже можно писать вирусы

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

digger> Но данные можно сохранять и работать с ними.

Нельзя. Под iOS ты не можешь принести файл на флешке и открыть его в текстовом процессоре. Что сразу ставит крест на ней как на десктопной ОС общего назначения.

digger> iOS как защищенная клиентская ОС для секретарш вполне пригодна.

Секретарше нужно работать с документами. iOS этого полноценно не умеет. Загрузить файл из облака и залить обратно для современного офиса очень мало.

digger> Никакой софт вообще никак не устанавливается, кроме как сисадмином

Это даже под Windows уже много-много лет есть.

•  4
•  инфо
•  инструменты
• Ответить на сообщение

Bod> и что то поломалось:

Уже исправил.

•  инфо
•  инструменты
• Ответить на сообщение

с.т.> возможность принести файл на флэшке - это такая дырень

Но это сегодня обязательный формат документооборота.

•  5
•  инфо
•  инструменты
• Ответить на сообщение

V.Stepan> Я-то как раз слежу, почему и упомянул, что эти продукты для примера не годятся — они не с нуля разработаны

Блин. Ещё раз. Я не пишу о том, сколько времени и человек нужны, чтобы LibreOffice сделать из StarOffice. Я пишу о том, сколько нужно времени и человек, чтобы сделать с нуля продукт, аналогичный LibreOffice.

V.Stepan> Поэтому по ним оценивать трудоёмкость проекта "с нуля" не совсем правильно. Вот, что я имел ввиду.

А я не знаю трудоёмкость этих проектов. Я вижу конечный результат — SLOC и нынешнее число коммитеров. От них и пляшу.

На сами OpenOffice/LibreOffice ресурсов ушло НАМНОГО больше. Потому что это древние, развивающиеся, многократно переписанные проекты. Но это совсем другой вопрос, а не тот, как сложно сделать аналогичный продукт сегодня, с нуля, под заказ, за деньги.

•  17
•  инфо
•  инструменты
• Ответить на сообщение

digger> Я был удивлен, у нас на работе флэшки запрещены

Это ваш частный случай. Весьма распространённый (я сам так вообще никогда на флешке файлы не носил — от CD-R сразу в облака ушёл), но — частный.

Многие офисные компы вообще к Интернету не подключены. Кстати, в том числе и по соображениям безопасности

•  инфо
•  инструменты
• Ответить на сообщение

с.т.> увы, безопасность и удобство это взаимоисключающие вещи

Безусловно. Но что ещё хуже, взаимоисключающие вещи — безопасность и функционал.

•  инфо
•  инструменты
• Ответить на сообщение

Серокой> 2008-й, Карл!
Серокой> Только ссылки протухли. )

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

•  инфо
•  инструменты
• Ответить на сообщение

V.Stepan> Я это понял ещё в первый раз!

Нет, нифига не понял до сих пор.

V.Stepan> Вопрос-то, на самом деле, аналогичный. Ведь когда в момент Х сели писать OO 1.0, то им не с нуля его пришлось писать, получилась экономия и времени, и денег. И так далее по цепочке (1->2, 2->3 и и.д.)

Придётся в третий (или уже четвёртый?) раз писать.

Я оценивают не то, сколько ресурсов нужно на «1->2» + «2->3». Я оцениваю, сколько времени нужно на «1->3». Мне не важно, каким путём оно развивалось. Мне важно, сколько нужно затратить, чтобы получить конечный продукт, а не повторить пусть его развития.

Ну, смотри, совсем тупой пример. Я купил компьютер за $1000. Он устарел, я его выбросил, но взял из него кулер и сделал самодельный вентилятор. Чтобы повторить этот путь для создания нового вентилятора мне потребуется потратить $1000. Но чтобы сделать такой вентилятор с нуля, мне потребуется $5. И задача стоит — создать новый аналогичный вентилятор. А не воссоздать в точности процесс создания старого.

•  17
•  инфо
•  инструменты
• Ответить на сообщение

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

Не только. Есть много фанатов именно заброшенного. Без привязки к атому или пиару. Это целая субкультура.

Вот, для затравки:

•  4
•  инфо
•  инструменты
• Ответить на сообщение

digger>>> был же в свое время Лексикон без вирусов и лучше Ворда.
Balancer>> Только под DOS.
D.2.> Удивись, да?!

Читать нужно весь контекст, а не отдельные слова. Я прекрасно знаю про GUI-версию Лексикона. Вот только он уже не был ни столь популярным, как DOS-версия, ни «лучше Ворда». Лексикон правил под DOS, но не выдержал конкуренции под Windows. В том числе потому, что тут начинался вопрос человекочасов, о котором у нас идёт речь.

•  1
•  инфо
•  инструменты
• Ответить на сообщение

V.Stepan> Повторяю — я имел ввиду то, что ты пытаешься оценивать по проекту, который плохо подходит для оценки "разработать с нуля и сразу до крутого функционала уровня 4.1.2"

Там код — и там код. Там функционал — и там функционал. Почему не подходит-то, если я смотрю не на историю, а на текущее состояние? Сдаётся мне, что ты так меня и не понял.

V.Stepan> Я же говорю, что прекрасно понял твой посыл, просто не согласен с ним. Во-первых, 5 лет на разработку это много

Это очень мало. Я дал большую фору. Не раз уже писалось, что программист большого проекта по итогам проекта пишет 8-20 строк кода в день. (В среднем около 8, я по своим проектам считал, пишут 12 SLOC в день).

Берём 5 млн. строк LibreOffice, делим на 8-20, получаем 7-18 тыс. человеколет. Для команды в 100 человек — 7-18 лет разработки.

V.Stepan> продукт успеет устареть и придётся его переписывать

Эта оценка, как раз, учитывает регулярное переписывание. Она — интегральная. Естественно, что физически программист пишет куда больше 8 строк в день

•  1
•  инфо
•  инструменты
• Ответить на сообщение

digger> Оно переусложнено

Куда проще-то? Notepad?

digger> а это, кроме всего прочего, значит,что где-то непременно есть эксплоиты и крэши.

Это неизбежно в любой сложной системе.

digger> Оффис-97 влазил на 10 дискет, кажется, и был вполне достаточным.

Он совершенно недостаточен под современные требования. И, да, эксплоитов и уязвимостей в нём было куда больше, чем в каком-нибудь Office-2013. Это тоже прямо коррелируемые понятия — низкий уровень программирования с низкой надёжность и безопасностью и высокий уровень программирования с высокими системными требованиями. Хочешь писать надёжно? Писать придётся на высоком уровне и это приведёт к появлению тяжёлой программы.

•  2
•  инфо
•  инструменты
• Ответить на сообщение

digger> Клауд Эппла довольно безопасен.

Во-первых, это не так. Навскидку (и это далеко не всё):

Во-вторых, ты предлагаешь российской ОС пользоваться облаком Apple? Делать своё? Как думаешь, сколько для Apple стоит разработка и поддержка его облака? И какова будет надёжность такого облака в российских реалиях?

•  3
•  инфо
•  инструменты
• Ответить на сообщение

Android> как хунта будет выкручиваться

Да никак. Скажут, что Путин всех подкупил, москали во всём виноваты, тем хуже рабско-ватной Европе, слава Украине, героям слава!

•  инфо
•  инструменты
• Ответить на сообщение

digger> Нисколько : ftps:// и шифрованный контент.Клауд - на самом деле баззворд и куча избыточных технологий
digger> Секретарши на форуме есть? Я Офис ненавижу во всех проявлениях и им не пользуюсь

Ну вот и обсудили

•  2
•  инфо
•  инструменты
• Ответить на сообщение

ИГ0РЬ> Вон оно ка, Михалыч!!! Даже не знаю какой смайлик поставить.

•  инфо
•  инструменты
• Ответить на сообщение

с.т.> VI рулит и всё тут

mcedit

95% моего кода за все времена написано в mcedit В том числе 99% кода Авиабазы.

•  2
•  инфо
•  инструменты
• Ответить на сообщение

Bredonosec> понятно, что не единиц. Но прогеров разве нет в рф?

Прогеры есть. Но чтобы воспроизвести с нуля весь современный востребованный софт, от ОС до прикладного и на отвечающем хотя бы минимальным современным запросам и за те деньги, которые готово платить государство их количество недостаточно. Более того, такого количества сегодня нет ни у одной страны мира. Поэтому даже Китай использует софт на базе имеющегося опенсорса, а США пользуются трудом тех же индусов (через Microsoft).

Bredonosec> Насчет сотен миллионов.. ты не перегнул?

Грубая оценка, конечно, но один LibreOffice — это уже порядка 10 млн. человеко-часов. Ядро Linux — ещё 10 млн. человекочасов. Базы данных, сервера, графические редакторы, растровые и векторые, браузеры...

Вот, кстати, сторонняя оценка 8-летней давности:

Используя данные на 2008 год по зарплате разработчиков , создание дистрибутива Fedora 9, потребует 10.8 млрд. долларов. Система содержит 204,5 млн. строк кода распределенного по 5547 пакетам. Трудозатраты оцениваются в 60 тыс. человеко-лет.

 

Итого, 8 лет назад для создания нормального дистрибутива требовалось 22 млн. человеко-часов и 11 млрд. долл. С тех пор сложность софта возросла в разы. Так что сто миллионов человеко-часов — запросто (по этой оценке мои «сотни» — преувеличение, но не сильное).

Bredonosec> Итого - сто тысяч сотрудников для хотя бы двух сотен млн часов? Несерьезно же.

Что тут несерьёзного?

Bredonosec> А оси мс выпускает регулярно, с периодичностью где-то раз в год-два.

Там львиная доля кода — наследуется из предыдущих проектов. MS не пишет каждые год-два ОС с нуля.

Bredonosec> оппа.. Не знал, что оно такое старое. И из сообщений вроде не вытекает, что нежизнеспособно.

Вот, 12 лет назад

Проекту тогда уже было 6 лет

Bredonosec> Кстати, 9 млн строк - это где-то гигабайт дистрибутива?
Bredonosec> Столько действительно нужно?

В дистрибутивах он идёт уже компилированный. Под Gentoo в исходниках, но они поставляются в заархивированном виде. А вот для компиляции LibreOffice из исходников требуется около 5Гб места на диске.

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

Не может быть сложного софта без дыр. Нереально предусмотреть всё.

•  1
•  инфо
•  инструменты
• Ответить на сообщение

Bredonosec> Напр, в выни - полуось. Кто-то ею пользуется? Она там нужна?

Откуда «в выни - полуось»? Это, наоборот, в OS/2 3.x/4.x была поддержка Win3.x

А если ты про POSIX-подсистему (которая не имеет ничего общего с OS/2), то да, нужна. Ею пользуется огромное количество кроссплатформенного софта.

Bredonosec> Всякие там хэндрайтинги и спич модули - ими кто-то пользовался, что они интегрированы и весьма основательно захламляют ось?

По сравнению с инфраструктурой в целом — это мелочь.

Bredonosec> короче говоря, я понимаю, что это всё дело большое, но не думаю, что столь большое, как сегодня винда.

Видишь ли, при разработке таких систем или ты обеспечиваешь поддержку имеющегося софта и тогда у тебя система пухнет и глючит (привет, Windows), или ты обеспечиваешь работоспособность только текущего актуального софта, тогда система получается легче, надёжнее, но не может потеснить рынок там, где работает система с поддержкой старого (привет, Linux, Android и iOS), или ты полностью забиваешь на совместимость, планируя, что весь необходимый софт будет написан с нуля или портирован тобой или заинтересованными и тогда твоя система умирает (WinPhone, BlackBerry, Tizen, BeOS, Firefox OS, Ubuntu Touch и десятки других).

•  3
•  инфо
•  инструменты
• Ответить на сообщение

Balancer>> Хочешь писать надёжно? Писать придётся на высоком уровне и это приведёт к появлению тяжёлой программы.
Bredonosec> а можно раскрыть тезис? Почему надежно - это обязательно на высоком уровне?

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

Поднимаемся до языков более высокого уровня — и у нас уже нет проблем с учётом памяти и арифметикой указателей. Но остаются проблемы SQL-инъекций, неправомерного файлового доступа и т.п. Чтобы от них избавиться, нужно переходить от ручной работы с запросами и файлами к фреймворкам, которые обеспечат весь нужный функционал, попутно раз и навсегда реализовав всё безопасность. А тебе нужно только вызывать необходимые компоненты.

Следующий уровень — разнесение функций одного приложения на серверы приложений, раздельные ноды.

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

•  1
•  инфо
•  инструменты
• Ответить на сообщение

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

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

Вот нереализованная латентная гомосексуальность, конечно, могла вылиться в ненависть к гомикам. Но на то она и нереализованная

•  2
•  инфо
•  инструменты
• Ответить на сообщение

digger> Сложные функции в ячейке - извращение.Я вместо этого использую Питон

Офис, всё же, пишется не для маргиналов. Маргиналы куда эффективнее используют тот же TeX.

Попробуй заставить свою бухгалтершу писать на Питоне...

•  1
•  инфо
•  инструменты
• Ответить на сообщение

Bredonosec> Я к тому, что с нуля какие-то вещи делаются, хоть и не столь крупные..

С нуля много чего делается

Balancer>> Ядро Linux — ещё 10 млн. человекочасов.
Bredonosec> а там действительно нужно столько?

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

А так, первое попавшееся из changelog последнего релиза:

>compress: remove unused pcomp interface
>removes ethtool_cmd deprecated fields
>Remove mmapped netlink support
>powernv: Remove support for p5ioc2
>Remove obsolete 68360 support
>AHCI: Remove obsolete Intel Lewisburg SATA RAID device IDs
>cpqarray: remove it from the kernel
>iio: Remove periodic RTC trigger driver
>Delete STE RMI4 hackish driver
>Staging: dgap: Remove obsolete driver
>Remove deprecated AU1X00 AC97 driver
>Remove 68328 driver
>Remove Maxim 77802 driver

и т.д., там много

Bredonosec> На каком-нить С# наверно хелловорлрд пару метров займет

HelloWorld на Go занимает около 10 Мбайт Но сегодня это никому не интересно, так как весит столько не сам код «HellWorld», а вся инфраструктура, которую тянет с собой система. Поэтому, что «HelloWorld», что довольно сложное Web-приложение будут весить на Go всё те же 10Мбайт. Последнее будет только на сотню-другую килобайт больше первого

Bredonosec> в германии на конкурсе демок заняли призовой (второе чтоль?) место с демкой на 2 метра, в которой уместили емнис 15-минутный фильм про мир фоллаута.

Да, демки это круто. Я и сам ими баловался ещё в DOS-времена. Но это как раз крайний случай в другую сторону — как писать очень компактно, но очень, очень долго и без всякой надёжности

Bredonosec> но разве идеология программ привязана к оси?

Не идеология, а API. Невозможно написать полноценный API, не потратив на разработку системы время, сравнимое с разработкой системы оригинала. Яркий пример тому как раз ReactOS. Или WinE. Так что или тебе придётся писать вторую Windows/Linux самому и с нуля, или придётся забивать на совместимость, но тогда тебе придётся и весь софт под систему писать самому же

Balancer>> Не может быть сложного софта без дыр. Нереально предусмотреть всё.
Bredonosec> потому и возвращаюсь каждый раз к вопросу - зачем усложнение?

Так потому что задачи от софта всё более сложные требуются. Уже недостаточно уметь зажигать отдельные пикселы на экране в однозадачном режиме или пищать спикером Один только Web-браузер — чудовищная по своей сложности система, разрабатывать которую сегодня тянут буквально 3 команды. WebKit/Opensource/Google + Edge/Microsoft + Gecko/Mozilla. Всё? Safari (Apple, Карл!) и Opera отказались от гонки и перешли на WebKit. Что ещё?

И, вот, как ты полагаешь, для «чисто российской ОС» нужно разрабатывать движок с нуля (с чем в последние годы официально только MS связалась, поменяв Trident на Edge — хотя ещё вопрос, сколько в последнем «с нуля», а сколько от первого? )? Если да — то затея изначально глухая. Если нет и можно использовать сторонние компоненты то, внезапно, а зачем вообще делать систему с нуля, когда можно пойти по пути того же Китая (да и России ) и воспользоваться готовым Linux?

•  инфо
•  инструменты
• Ответить на сообщение

Bredonosec> Ну, напр, выяснилась некая дыра, убрали или изменили некие апи, заодно выслали разрабам софтин сообщение

И вот тут возникает проблема. Есть огромная масса софта, которые больше никак не развивается. Автор забил на софт. Или вообще умер. Софт работает и востребован. И тут, бац — изменение в API. Никакая рассылка уже тут не поможет...

Bredonosec> что так и так - это теперь сменилось на вот так, если ваш софт использует это место - меняйте, обновляйте, патчите или что там хотите делайте.

На самом деле это настолько нереально, что не используется вообще ни в каких системах Либо система пытается обеспечить совместимость практически всего софта длительное время (Windows), либо пытается обеспечить совместимость текущих версий софта (Linux, Android, MacOS) — но это уже писалось выше.

Bredonosec> Или сделать ядро независимым, а софт запускать как вирт-машины, со своими песочницами

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

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

И всё опять утыкается в обмен данными, в файловую систему. В той же iOS или WinPhone приложения очень сильно разделены. Конечно, разделение не столь полноценное, как в Linux-контейнерах, но позволяет решить львиную долю проблем безопасности. Но, внезапно, программы теряют возможность работать с общими файлами. В лучшем случае — пересылать файл друг другу. Попробуй переслать 25Гб BlueRay видео...

•  инфо
•  инструменты
• Ответить на сообщение

Bredonosec> А нет-ли редакторов для низкоуровневого языка, которые б проверяли синтаксис на ошибки?

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

Bredonosec> Или нет?

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

Bredonosec> вот тут уже не понял.. это уже не программирование, а что-то еще?

Программирование. Но более высокого уровня. Скажем, Авиабаза сейчас работает на 5-6-7 (даже точно не знаю навскидку) независимых компонентах. АвиаПорт примерно на таком же количестве.

Bredonosec> Но с учетом позднейшего перетрахивания кода в поисках будущих ошибок и исправлений не выйдет более оптимально изначально написать более простым языком, чтоб потом меньше лопатить?

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

•  инфо
•  инструменты
• Ответить на сообщение

V.Stepan> В первых версиях NT была поддержка 16-битных консольных приложений OS/2.

Да, про это я уже успел забыть. Почему версии NT начинаются с 3.x помню, а вот про поддержку приложений — забыл

•  инфо
•  инструменты
• Ответить на сообщение

Bredonosec> не помню, кто писал, что питон изобрели, чтоб над кем-то поиздеваться, судя по степени его нелогичности ))

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

...

Из того, на чём пишу, на первое место по нелогичности я бы поставил Lua

•  1
•  инфо
•  инструменты
• Ответить на сообщение

Клапауций>> Механические
Fakir> Хм, антиресный девайс...

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

•  1
•  инфо
•  инструменты
• Ответить на сообщение

Fakir> Во, кажется, доходит: интересны, так сказать, способы создания анизотропии проводимости.

Тогда умформеры — точно в теме. Они преобразовывали одни виды напряжения в другие. Переменное в постоянное, наоборот, повышали напряжение, понижали, меняли частоту...

•  2
•  инфо
•  инструменты
• Ответить на сообщение

Fakir> Речь о том, что женатость еще вовсе не гарантирует, и заведомых противоречий тут нет.

Женатость не гарантирует. Но был бы он явным, о чём пытаются утверждать, вряд ли бы пошёл крошить гомиков. Так что, скорее всего, или гетеро, или гомик, но латентный.

•  инфо
•  инструменты
• Ответить на сообщение