Как стать автором
Обновить
2
0

Пользователь

Отправить сообщение

Так дистрибутивы уже вполне себе внедряют контейнеры — snap (Ubuntu, многим не нравится), flatpak (много где, многим нравится), appImage (почти нигде). У меня во flatpak стоят всякие сомнительные проприетарные штуки — Skype, Slack, Discord, Spotify. Никаких проблем с зависимостями.
Удаление/установка по щелчку пальцев — это про AppImage, вроде бы на Маке приложения похожим образом ставятся (1 бинарник — 1 приложение). Но он как-то не слишком распространен, и образ нужного приложения часто не найти.

Состояния шаринга экрана в скайпах-зумах (т.е. основанных на хромиуме приложений) сейчас такое:
1) Хромиум поддерживает шаринг экрана в wayland через PipeWire — https://wiki.archlinux.org/index.php/PipeWire#WebRTC_screen_sharing
2) Приложения поверх хромиума собирают почему-то без флага RTC_USE_PIPEWIRE, поэтому шаринг экрана в человеческом виде не работает
3) Сейчас в дискорде, например, можно шарить приложения, запущенные на XWayland
4) Недавно в Электрон (фреймворк для десктопных приложений на основе хромиума) добавили поддержку Wayland, с шарингом экрана ситуация может стать получше (http://opennet.ru/opennews/art.shtml?num=53955)
5) Для шаринга wayland-экранов на wlroots-based композиторах (см. sway) нужно ставить (https://github.com/emersion/xdg-desktop-portal-wlr), как дела у Gnome и KDE — не знаю.


В общем, ситуация исправляется, но до "просто работает" пока далековато.

Не очень понятно, в чем проблема с радужными таблицами. Вам же нужно не найти qwerty по строке a86850deb2742ec3cb41518e26aa2d89, а найти a86850deb2742ec3cb41518e26aa2d89 по тому, что лежит в базе у сервиса.


P.S. a86850deb2742ec3cb41518e26aa2d89 — это хэш от qwerty\n. Хэш от qwerty нужно считать как


echo -n "qwerty" | md5sum

Получится d8578edf8458ce06fbc5bb76a58c5ca4.

А как же соль? Разве правильная практика — это не генерить случайную соль на каждый пароль, да еще и хешировать каким-нибудь bcrypt или scrypt, которые намного дольше простого SHA-1 считаются? Вам же под каждую соль придется всю базу утекшую паролей заново хешировать.

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


Файл должен быть в формате МП3

image

К слову о 24/16 бит, одна из самых интересных статей, которые я читал (к сожалению, на оригинальном ресурсе почему-то 404):
https://web.archive.org/web/20200202124704/https://people.xiph.org/~xiphmont/demo/neil-young.html


Про lossy vs lossless там тоже чуть-чуть есть: например, на момент написания статьи, в быту могли использоваться старые и низкокачественные mp3 или vo-rbis-энкодеры, поэтому слушать (или хотя бы иметь копию) в lossless имело определенный смысл.


Кстати, интересно, почему vk до сих пор сидит на mp3? Даже 10 лет назад, Vorbis обещал сравнимое качество на меньшем битрейте, а уж сейчас, когда есть Opus (уровень неотличимости от lossless — 96-128 kbps), в mp3 совсем нет смысла (кроме аппаратной поддержки, наверное).

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

Насчет безопасности FF — их песочница исторически критикуется различными секьюрити-исследователями. У меня нет актуальных данных, но вот, например, заявления от авторов GrapheneOS:


Avoid Gecko-based browsers like Firefox as they're currently much more vulnerable to exploitation and inherently add a huge amount of attack surface

Even in the desktop version, Firefox's sandbox is still substantially weaker (especially on Linux, where it can hardly be considered a sandbox at all) and lacks support for isolating sites from each other rather than only containing content as a whole.

Или от разработчиков OpenBSD, 2018 год:


I doubt firefox will ever focus on security. The security mechanisms we
are talking about require breaking compatibility or performance.

I think firefox is YEARS behind, unless they change their strategy.

Насколько я знаю, Project Fisson уже вот-вот должен как-то это изменить, но я не эксперт — не могу сказать.

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

Я ни разу не специалист по нейронным сетям, но мне доводилось делать точно такое же задание (без GUI-части) для домашнего задания в университете. Мне кажется, вот такие вещи можно улучшить:


  1. Размер картинки в 278x278 избыточен, как выше уже отметили в комментариях. Мне оказалось достаточным размера 28x28.
  2. Альфа-канал вы удалили — но зачем вам все 3 оставшихся канала RGB на черно-белых картинках? На вход нейросети достаточно подавать grayscale изображения — у flow_from_directory есть опция color_mode.
  3. API для "размножения" датасета есть в самом ImageDataGenerator
  4. Аналогично, разбиение датасета на trainig и validation есть в ImageDataGenerator, не обязательно его осуществлять руками (хотя, возможно, ручное разбиение будет более надежным).

На Java оно тоже может декларативно выглядеть, для таких вещей циклы уже давно не обязательно писать:


jshell> var in = List.of(List.of(1,2), List.of(3, -4), List.of(-5,-6,-7))
in ==> [[1, 2], [3, -4], [-5, -6, -7]]

jshell> in.stream().filter(inner -> inner.stream().allMatch(e -> e >= 0)).collect(Collectors.toList())
$4 ==> [[1, 2]]
34 года… в таком возрасте старшие дети уже школу заканчивают.

Я где-то пропустил сарказм? Что бы в 34 года иметь старших детей, которые заканчивают школу, нужно стать родителем в 16-18 лет.

Если забить на возможные ошибки(допустим, у нас точно безошибочный лог), то код-то очень быстро напишется, за несколько минут буквально (если я правильно понял задачу). И по памяти О(1). Рабоатет, правда, небыстро (у меня ~1гб/минута), да и не особо эстетично (обычный императивный C-подобный код).


Заголовок спойлера
import json
from collections import defaultdict

with open('log.txt', 'r') as f:
    db = defaultdict(lambda: { 'n': 0, 'sum': 0, 'uniq': set(), "max": -1})
    for line in f:
        record = json.loads(line)
        db_record = db[record['eventType']]
        db_record['n'] += 1
        field_1 = record['field1']
        db_record['sum'] += field_1
        max_value = db_record['max']
        if max_value < field_1:
            db_record['max'] = field_1
        db_record['uniq'].add(record['field2'])

for event_type,record  in db.items():
    avg = record['sum'] / record['n']
    print(f'eventType:{event_type}, avg: {avg},max: {record["max"]}, uniq: {record["uniq"]}')

Справедливости ради, я не знаю, как дела на Windows, но на линуксах, согласно бенчмаркам (да и по личным ощущениям), Firefox все-таки еще заметно от Хрома отстает по производительности (хотя ситуация улучшается в каждом новом релизе). Более того, на линуксах у firefox нет хардварного декодинга видео.

В свое время больно обжегся на таком:


correct = [ [1] * 3 for i in range(0, 3)]
correct[0][0] = 10
print(correct) # [ [10, 1, 1], [1, 1, 1], [1, 1, 1] ]

incorrect = [[1] * 3] * 3
incorrect[0][0] = 10
print(incorrect) # [ [10, 1, 1], [10, 1, 1], [10, 1, 1] ]

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

Это правда, но на тот момент (я не умел программировать вообще), возможность не разбираться (и не ошибаться) в форматной строчке для меня была намного важнее — std::cout и std::cin казались намного более понятными в использовании, чем printf/scanf.

В свое время форматные строки для printf и scanf стали причиной, по которой я выбрал учить C++, а не С (для С взял книжку не K&R, что, конечно, было ошибкой).

Но вообще, в последнем издании Страуструпа, где он учит программированию на примере С++ (http://www.stroustrup.com/Programming/), он явно не ставит себе цели сразу объяснить, как оно все работает внутри — а наоборот, призывает использовать удобные абстракции, так что cout здесь вполне себе адекватно выглядит.
Справедливости ради, впервые collections framework появился в jdk 1.2 — конец 1998 года, когда джаве было почти три года. В красивом виде, с дженериками и concurrency-коллекциями — в J2SE 5.0, 2004 год (джаве — 8 лет). Go вышел в 2012 — ему 7 лет. Почему бы немного не посравнивать?
Уменьшение площади прямоугольника в два раза при уменьшении высоты — это следствие контракта «высота не зависит от ширины». Если мы этот контракт отбрасываем — то можно без проблем наследовать квадрат от прямоугольника. Насколько это было бы удобное и правильное решение — зависит уже от контекста.
Согласен, если независимость ширины от высоты не является контрактом прямоугольника — то никакого нарушения LSP здесь не будет. Автору оригинала стоило бы более четко сформулировать, какие именно объекты моделируются в его коде. Но если контракт на независимость высоты от ширины есть, то при любом из вариантов наследования(Square -> Rectange/Rectangle -> Square) LSP будет нарушаться.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность