Павел Остапенко @mt_
Пользователь
Информация
- В рейтинге
- Не участвует
- Откуда
- Москва и Московская обл., Россия
- Зарегистрирован
- Активность
Специализация
Chief Technology Officer (CTO)
Optimization of business processes
Development management
Mentoring
FullStack
Agile
Это, вроде, называется олигархат? Который не становится клептократией лишь пока Dash не занял серьёзный сегмент рынка и большинство «мелочи» может «соскочить» на другие валюты.
С точки зрения простого человека теперь начинаешь опасаться: при краже телефона, злоумышленник получает сразу твои контакты, звонки, переписку, учётные записи, платёжные реквизиты, а теперь ещё и автомобиль.
Что касается сути. Главная особенность ReactOS с точки зрения просто пользователя — совместимость. Но не с Windows как таковой. А с инфраструктурой: ПО под Windows и тем, как с ним взаимодействует ОС а также совместимость с железом.
Вот этому факту я бы посвятил главную страницу. Я бы подумал как максимально наглядно и красиво показать список основных 100% совместимых с ОС программ Windows. Я бы подумал, как сделать быстрый поиск, совместима ли ОС с конкретной программой, которая нужна пользователю, чтобы ему не пришлось искать это в дебрях сайта. Я бы подумал, как пользователь может выбрать совместимое оборудование и узнать, какое оборудование не совместимо. И я бы подумал, как наглядно показать всё что отличается от Windows: скорость загрузки, требования памяти/диска (это есть!), и т.д.
Сколько у вас девелоперов и прочее, должно быть отображено ниже или на другой странице. По сравнению с вышеперечисленным, для потенциального пользователя это вторичная информация.
— Громоздкий интерфейс
— Известная несовместимость в .doc-форматом
— Невозможность совместного редактирования
— Вопросы по приватности (особенно у бизнеса), учитывая, что набираемый текст «пропускается» через сервер Майкрософта.
Из комментариев представителей Яндекса я сделал вывод, что у самой команды есть вопросы к выбранному решению. И они, возможно, заинтересовались бы альтернативным продуктом, которое решало все эти фундаментальные проблемы при сохранении совместимости. Почему бы и не попробовать?
У меня в браузере выставлен зум 150% (как и у многих, особенно на мониторах с высоким dpi). И текст выглядит крайне замыленным. О чём я честно написал выше. С моей точки зрения, было бы правильно, если бы в текстовом редакторе текст отображался чётко при любом зуме браузера (как в ряде других известных продуктов). Если эта проблема решена — то на этом я бы завершил дискуссию и вернулся к своим наилучшим пожеланиям.
Выше я писал о конкретной проблеме — невозможности чёткого отображения текста в вашем редакторе при довольно типичных настройках браузера.
А также о проблеме методологической — странном нежелании эту проблему признать (в отличие от вашего коллеги). Зачем требовалось обвинять людей во лжи (может не разобрались?) — мне не понятно. Проблема повторяется и у меня, о чём я докладываю в этих комментариях вполне спокойно и доброжелательно. Пишу я это только потому, что «за державу обидно», понимаете?
Вот этой фразы было бы достаточно. Вместо этого ваш уважаемый коллега xkorolx обвиняет пользователей во лжи. Мне стало интересно, я запустил ваш редактор в своём браузере и обнаружил, что проблема действительно существует. Соответственно, лжёт не пользователь, а его обвинитель. И это особенно некрасиво при презентации технологии.
Это не споры, а попытка члена команды разработчиков откреститься от реальной проблемы. Рад, что вы (в отличие от коллеги xkorolx) её признаёте. Уверен, вы сможете с ней разобраться. Также желаю вашему продукту успешной коммерческой реализации.
Ваш продукт для пользователя, или пользователь для вашего продукта? Пользователя не волнует, в конечном счёте, какие технологии вы используете. Ему важно, что на его 4К мониторе, где масштабирование наверняка включено, шрифт выглядит откровенно плохо. И что отвечаете вы? Вместо того, чтобы признать проблему, начинаете хамить в стиле позднего советского общепита, уж извините за резкость. На мой взгляд — хотя может и ошибаюсь — вы почему-то ставите самоценность вашей технологии выше интересов пользователя.
А вот интересующие нас вызовы в D вполне заметны по времени, начинаясь примерно с 5,8%.
То есть сравнение «мутное» даже без парсинга файла. Почему? Надо разбираться. Я навскидку скажу, что очень много new/delete вызовов в цикле. То есть мы по сути тестируем скорость менеджера памяти для конкретной реализации runtime library С++. Стандартный менеджер, действительно, не самый быстрый. Я, например, пользуюсь фреймворком U++, где этот менеджер по умолчанию свой, более быстрый.
В D тоже может быть более эффективный менеджер памяти, особенно вкупе с необходимостью иметь быстрый мусоросборщик.
Но это лишь предположение — чтобы сказать точно, нужно профилировать версии без парсинга.
Но видимо нет, опять не срослось…
В данном конкретном случае нужно говорить не о сравнении языков, а о сравнении скорости функций ввода-вывода двух конкретных реализаций библиотек. Это по большей части.
Являясь профессионалом в D, вы подготовили сравнительно оптимальный код D и «просто работающий» код С++. После чего получили те результаты, которые получили. Что они действительно показывают — вопрос отдельный. Но уж точно не «сравнение производительности двух языков».
На мой взгляд, вопрос хоть не прямо по теме заметки, но вполне релевантен упоминаниям о безопасности здесь, в комментариях.
Кто может уточнить, насколько это противоречит или не противоречит стандарту (С, С++)? И если стандарту не противоречит, то имеет смысл отучать себя вообще использовать указатель на массив в коде — только указатель на первый элемент.
То есть было бы здорово почитать обзор, в котором блее конкретно прописаны меры безопасности. Понятно, что совсем мелкие детали в статью не влезут, да и не так нужны: при желании всё находится.
Здесь бы очень помогла именно обзорная статья с конкретными примерами — это самое ценное знание, которое из поисковика не получишь. Только от профи, который работает в конкретной нише не первый год.
Никто не делает для развития Tox больше, чем Microsoft. Спасибо, ребята!