система позволяет владельцам Мастернод (полных узлов, имеющих 1.000 DASH обеспечения) голосовать по важным вопросам
владельцы Мастернод Dash являются движущей силой в принятии решений
Это, вроде, называется олигархат? Который не становится клептократией лишь пока Dash не занял серьёзный сегмент рынка и большинство «мелочи» может «соскочить» на другие валюты.
Полностью поддерживаю. Вопрос в использовании подхода на сложных динамических сценариях, но и здесь есть решения. Откровенно говоря, за всё время ещё ни разу не встречал в С++ необходимости использовать мусоросборщик в масштабах программы (исключая специализированные классы, внутри которых та или иная сборка «мусора» может быть уместна).
Мне кажется, что в комментариях к статье будет вполне адекватно упомянуть и о подходе, который позволяет избегать проблем с памятью без мусоросборщика. Не претендуя на «метод на все случаи жизни», очень надеюсь, он будет полезен некоторым. Речь идёт об этой хабрастатье.
С технологической точки зрения — новость интересная.
С точки зрения простого человека теперь начинаешь опасаться: при краже телефона, злоумышленник получает сразу твои контакты, звонки, переписку, учётные записи, платёжные реквизиты, а теперь ещё и автомобиль.
Стилистику комментировать не буду — не моё.
Что касается сути. Главная особенность ReactOS с точки зрения просто пользователя — совместимость. Но не с Windows как таковой. А с инфраструктурой: ПО под Windows и тем, как с ним взаимодействует ОС а также совместимость с железом.
Вот этому факту я бы посвятил главную страницу. Я бы подумал как максимально наглядно и красиво показать список основных 100% совместимых с ОС программ Windows. Я бы подумал, как сделать быстрый поиск, совместима ли ОС с конкретной программой, которая нужна пользователю, чтобы ему не пришлось искать это в дебрях сайта. Я бы подумал, как пользователь может выбрать совместимое оборудование и узнать, какое оборудование не совместимо. И я бы подумал, как наглядно показать всё что отличается от Windows: скорость загрузки, требования памяти/диска (это есть!), и т.д.
Сколько у вас девелоперов и прочее, должно быть отображено ниже или на другой странице. По сравнению с вышеперечисленным, для потенциального пользователя это вторичная информация.
На днях Яндекс выкатил систему редактирования для документов Яндекс.Диска. По сути, они договорились с Майкрософт и подключили их Офис Онлайн к Диску. Это повлекло определённые фундаментальные проблемы:
— Громоздкий интерфейс
— Известная несовместимость в .doc-форматом
— Невозможность совместного редактирования
— Вопросы по приватности (особенно у бизнеса), учитывая, что набираемый текст «пропускается» через сервер Майкрософта.
Из комментариев представителей Яндекса я сделал вывод, что у самой команды есть вопросы к выбранному решению. И они, возможно, заинтересовались бы альтернативным продуктом, которое решало все эти фундаментальные проблемы при сохранении совместимости. Почему бы и не попробовать?
Ни в коем случае не хочу «наводить тень на плетень». И если вас ввели в заблуждение (подробно не перечитывал), то мне, безусловно, жаль.
У меня в браузере выставлен зум 150% (как и у многих, особенно на мониторах с высоким dpi). И текст выглядит крайне замыленным. О чём я честно написал выше. С моей точки зрения, было бы правильно, если бы в текстовом редакторе текст отображался чётко при любом зуме браузера (как в ряде других известных продуктов). Если эта проблема решена — то на этом я бы завершил дискуссию и вернулся к своим наилучшим пожеланиям.
К сожалению, вы ответили на какой-то другой комментарий, а не на мой (возможно, промахнулись?)
Выше я писал о конкретной проблеме — невозможности чёткого отображения текста в вашем редакторе при довольно типичных настройках браузера.
А также о проблеме методологической — странном нежелании эту проблему признать (в отличие от вашего коллеги). Зачем требовалось обвинять людей во лжи (может не разобрались?) — мне не понятно. Проблема повторяется и у меня, о чём я докладываю в этих комментариях вполне спокойно и доброжелательно. Пишу я это только потому, что «за державу обидно», понимаете?
мы видим проблему с тем, что есть браузерный зум и у нас возникли варианты улучшения нашего приложения
Вот этой фразы было бы достаточно. Вместо этого ваш уважаемый коллега xkorolx обвиняет пользователей во лжи. Мне стало интересно, я запустил ваш редактор в своём браузере и обнаружил, что проблема действительно существует. Соответственно, лжёт не пользователь, а его обвинитель. И это особенно некрасиво при презентации технологии.
Здорово, что возникают такие споры
Это не споры, а попытка члена команды разработчиков откреститься от реальной проблемы. Рад, что вы (в отличие от коллеги xkorolx) её признаёте. Уверен, вы сможете с ней разобраться. Также желаю вашему продукту успешной коммерческой реализации.
Что значит «на этом закончим»?
Ваш продукт для пользователя, или пользователь для вашего продукта? Пользователя не волнует, в конечном счёте, какие технологии вы используете. Ему важно, что на его 4К мониторе, где масштабирование наверняка включено, шрифт выглядит откровенно плохо. И что отвечаете вы? Вместо того, чтобы признать проблему, начинаете хамить в стиле позднего советского общепита, уж извините за резкость. На мой взгляд — хотя может и ошибаюсь — вы почему-то ставите самоценность вашей технологии выше интересов пользователя.
К сожалению, автор не привёл профилирование версии без ввода-вывода, но судя по результатам общего профилирования, в версии для С++ не связанные с парсингом файла вызовы даже не попали на первую страницу. Всё что мы там видим — это библиотечные вызовы и загрузка данных. Единственный вопрос вызвал dynamic_cast, но его нет и в исходниках автора.
А вот интересующие нас вызовы в D вполне заметны по времени, начинаясь примерно с 5,8%.
То есть сравнение «мутное» даже без парсинга файла. Почему? Надо разбираться. Я навскидку скажу, что очень много new/delete вызовов в цикле. То есть мы по сути тестируем скорость менеджера памяти для конкретной реализации runtime library С++. Стандартный менеджер, действительно, не самый быстрый. Я, например, пользуюсь фреймворком U++, где этот менеджер по умолчанию свой, более быстрый.
В D тоже может быть более эффективный менеджер памяти, особенно вкупе с необходимостью иметь быстрый мусоросборщик.
Но это лишь предположение — чтобы сказать точно, нужно профилировать версии без парсинга.
Немного прокомментирую не по теме, а по оформлению. Вот эта фразу: «Незаменимых нет» нужно иллюстрировать не той картинкой, что у вас, а этими:
В России это выражение известно как фраза И. В. Сталина, хотя в таком виде нигде в его речах или сочинениях она не встречается… Имея в виду некоторых высших партийных и советских чиновников, он сказал: «Эти зазнавшиеся вельможи думают, что они незаменимы и что они могут безнаказанно нарушать решения руководящих органов. Их надо без колебаний снимать с руководящих постов, невзирая на их заслуги в прошлом».
Кстати, а интересная задумка. КОмпилируй из любого фронт-енда в llvm и будет счастье. Отличная совместимость и куча бонусов.
Но видимо нет, опять не срослось…
С моей точки зрения, заголовок некорректен.
В данном конкретном случае нужно говорить не о сравнении языков, а о сравнении скорости функций ввода-вывода двух конкретных реализаций библиотек. Это по большей части.
Являясь профессионалом в D, вы подготовили сравнительно оптимальный код D и «просто работающий» код С++. После чего получили те результаты, которые получили. Что они действительно показывают — вопрос отдельный. Но уж точно не «сравнение производительности двух языков».
Пользуясь случаем, хочу узнать из первых рук: в Яндекс.браузере информация о посещении страницы также поступает на серверы Гугла (или не Гугла, а Яндекса, скажем)? Или у вас как в Iron Browser, эта «фича» удалена?
На мой взгляд, вопрос хоть не прямо по теме заметки, но вполне релевантен упоминаниям о безопасности здесь, в комментариях.
А вот такой тонкий момент, как эквивалентность указателя на массив и указателя на первый элемент массива. Встречал такое предостережение, что в некоторых компиляторах при сборке с проверками и отладочной информацией, в массиве сначала идёт несколько байт отладочной информации, а потом уже данные. В этом случае указатель на массив не совпадает с указателем на первый элемент.
Кто может уточнить, насколько это противоречит или не противоречит стандарту (С, С++)? И если стандарту не противоречит, то имеет смысл отучать себя вообще использовать указатель на массив в коде — только указатель на первый элемент.
Планируется ли уточнение конкретных мер безопасности вместо указания нормативов?
То есть было бы здорово почитать обзор, в котором блее конкретно прописаны меры безопасности. Понятно, что совсем мелкие детали в статью не влезут, да и не так нужны: при желании всё находится.
Здесь бы очень помогла именно обзорная статья с конкретными примерами — это самое ценное знание, которое из поисковика не получишь. Только от профи, который работает в конкретной нише не первый год.
Это, вроде, называется олигархат? Который не становится клептократией лишь пока 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. Спасибо, ребята!