Здравствуйте, я использую в основном виндовс, но тут возникла необходимость воспользоваться линуксом, загрузил fedora livecd и opera. Проблема заключается в том, что мне нужно зайти на сайт с регистрацией через facebook. В windows всё происходит без проблем, при входе на сайт нажимаешь кнопку через facebook всплывает окно facebook, исчезает и ты попадаешь в свою учётную запись. В linux
это почемуто не срабатывает, окно всплывает исчезает и возникает надпись что не может подключиться к сайту, проверьте то сё...
Уважаемые знатоки linux, может кто-то сталкивался с такой проблемой? Если я на сайте зарегистрирован через емейл то вход на сайт происходит без проблем, а если через facebook то всё валится... что может быть? Может проблема в том что я пользуюсь livecd?
К примеру, кусок кода (событие нового сообщения в telethon):
@client.on(events.NewMessage(chats=('chat')))
async def normal_handler(event):
print(event.message.id)
posts = await client(functions.messages.GetHistoryRequest(
peer=event.message.to_id,
limit=1,
offset_date=None,
offset_id=0,
max_id=0,
min_id=0,
add_offset=0,
hash=0))
print(posts)
Если где-то ниже async допустить ошибку или вообще синтаксически некорректное выражение - программа не падает с исключением, а тупо молча висит. Как такое исправить? Как ловить ошибки?
https://wiki.gentoo.org/wiki/Gentoo_Java_Packing_Policy
unsupported build system such as Gradle or Maven
Вот кто за них (команду java-gentoo) будет поддержку делать, я что-ли?
Где тогда ссылки на соответствующие баги про добавление такой поддержки (прямо в статье на wiki)?
Что останавливает/мешает реализовать поддержку этих систем сборки?
Добрый день.
Пытаюсь стримить с IP камеры (HIKVISION DS-I114), которая умеет аудио.
Но ffmpeg не видит аудио. Может я делаю что не так?
В настройках особо ничего нет.. как будто все включено
root@snt:~# ffprobe rtsp://admin:[email protected]:554/ISAPI/Streaming/Channels/101
ffprobe version 4.2.1 Copyright (c) 2007-2019 the FFmpeg developers
built with gcc 4.9.2 (Debian 4.9.2-10+deb8u2)
configuration: --enable-libx264 --enable-gpl
WARNING: library configuration mismatch
postproc configuration: --enable-gpl --enable-postproc --enable-swscale --enable-avfilter --enable-libmp3lame --enable-libvorbis --enable-libtheora --enable-libx264 --enable-libspeex --enable-shared --enable-pthreads --enable-nonfree
libavutil 56. 31.100 / 56. 31.100
libavcodec 58. 54.100 / 58. 54.100
libavformat 58. 29.100 / 58. 29.100
libavdevice 58. 8.100 / 58. 8.100
libavfilter 7. 57.100 / 7. 57.100
libswscale 5. 5.100 / 5. 5.100
libswresample 3. 5.100 / 3. 5.100
libpostproc 55. 5.100 / 55. 5.100
Input #0, rtsp, from 'rtsp://admin:[email protected]:554/ISAPI/Streaming/Channels/101':
Metadata:
title : Media Presentation
Duration: N/A, start: 0.239000, bitrate: N/A
Stream #0:0: Video: h264 (Main), yuv420p(progressive), 1280x720, 25 fps, 25 tbr, 90k tbn, 50 tbc
Можно что нибудь сделать?
qtox выводит на экран цепочку user-ов при старте, причем почти те же. Слышал, физтеховец хотел сделать хорошо.
Привет, лор!
Вытягиваю с удалённой машины большой файл (неск. Гб) командой:rsync -avhcsz --no-o --no-g --timeout=15 --progress --partial-dir=.rsync_parts -e ssh "$@"
Транспорт по сети интернет. Скорость канала небольшая (от 2-х до неск. Кб/сек), при этом соединение постоянно обрывается, в связи с чем rsync обёрнут в скрипт-супервизор а-ля вот здесь.
В файле нельзя допустить ошибки, поэтому опция -c. Беда в том, что при восстановлении соединения rsync очень доооолго сверяет фрагменты загруженной части с источником (затем догружает неск. Кб., и соединение обычно рвётся: снова проверка, etc&hellip
Может быть я упустил из виду подходящую опцию, с которой, допустим, контрольная сумма будет расчитываться только один раз (загруженная часть + такого же размера начальный кусок источника)? Или, скажем, можно задать размер куска для расчёта хэша?
Вразумите неразумного.
Просто мне иногда хочется поиграть в какие нибудь игрушки, но через bumblebee это просто ужас! В 2D платформере Geometry Dash на дискретной видюхе с использованием bumblebee, лагает! Причём не шуточно! Хотелось бы отключить к чертям встроеную видеокарту. До этого сидел на минте, но там можно через менеджер драйверов установить драйвер только для дискретки и таким образом встройка работать не будет, хотя и будет тирринг, но мне на него уже как то плевать!
Никто не знает никаких способов?
Стоит Intel + Nvidia, на ноуте, из биоса вырубить нельзя встроеную.
Создал зашифрованную папку с модулем CryFS,поместил в нее файлы. Затем переустановил систему. Как теперь мне подключиться к этим зашифрованным файлам чтобы их расшифровать?
Пропало название раздела форума (и возможно ссылка на него, как в трекере) в Уведомлениях — отображается просто «Форум».
Здравствуйте , у меня планшет с 2 гб озу , 1.4 ггц 64x, efi shell 2.4 . Я хотел бы опробывать разновидности ubunty и mint так как там предустановлены программы . До этого как начинающий устанавливал SteamOS , puppylinux , Slitaz . Эти ОС я смог установить только благодаря bootia32.efi который я через биос находил в каталоге . У многих разновидностей linux bootx64.efi который у меня не открывается или нет папки EFI . Получается придется самому создать такой файл ?
Исполнительный директор Intel Боб Свон сообщил, что дискретная видеокарта Xe DG1 (Discrete Graphics 1) вышла на этап рабочей валидации.
Под такими словами мистер Свон подразумевает систему отладки после выпуска микросхемы, а именно, её размещение на печатной плате и оценку работы и загрузки. После того, как эти тесты пройдут успешно, можно будет утверждать, что продукт почти готов, и будет начато тестирование программного и аппаратного обеспечения в реальных условиях.
Как будет выглядит видеокарта Xe в плане экстерьера, пока не известно, но определённо, она будет состоять из тех же конструкционных блоков, что и графика Gen12, интегрированная в процессоры Tiger Lake. Первая версия DG1 (Discrete Graphics 1) будет иметь относительно низкую производительность, возможно, такую же, как и интегрированная в Tiger Lake версия.
Кроме того, избранным партнёрам был передан тестовый набор Discrete Graphics DG1 External FRD1 Accessory Kit (Alpha) Developer Kit. Пока он находится на раннем этапе тестирования, однако это значит, что до релиза осталось несколько месяцев.
Сам факт создания рабочей видеокарты Xe шеф по маркетингу Intel в области графики Крис Спук прокомментировал немногословным твитом: «Она жива!». Господин Спук ожидает, что конечный продукт будет доступен к концу следующего года.
https://nvworld.ru/news/2019/10/30/#intel-made-xe-dev-kit
Вообщем автор этого видео попросил выложить в продолжение предыдущей темы Видео о нас
Из этого видео можно узнать кто он.
Всем привет! На свою голову решил попробовать файловую систему F2FS, создал раздел на 250 гб на своём SSD, поставил на него арч, вроде всё летало.. Решил перенести все свои файлы на раздел с F2FS, не оставив резервных копий. Потом я решил создать SWAP-файл на этом разделе ибо оперативки в ноуте всего 2 гб... Создавал файл через dd + mkswap, но после команды swapon программы перестали запускаться, при попытке выполнить любую команду в терминале был segfault.. Короче у меня такие же симптомы были когда я по приколу решил выполнить rm -rf /*
Решил кнопкой reset перезапустить ноут и в итоге попал в панель восстановления initramfs... Оказалось что файловая система почему-то повредилась и fsck.f2fs разных версий отказывается восстановить раздел. Так как сама ФС создавалась в f2fs-tools версии 1.13.0, то показываю результат работы fsck.f2fs именно этой версии:
dev@dev-laptop:~$ sudo fsck.f2fs -d 10 -f /dev/sda1
Info: Debug level = 10
Info: Force to fix corruption
Info: [/dev/sda1] Disk Model: Samsung SSD 850
Info: Segments per section = 1
Info: Sections per zone = 1
Info: sector size = 512
Info: total sectors = 515735552 (251824 MB)
Info: MKFS version
"Linux version 5.3.1-arch1-1-ARCH (builduser@heftig-3999379) (gcc version 9.1.0 (GCC)) #1 SMP PREEMPT Sat Sep 21 11:33:49 UTC 2019"
Info: FSCK version
from "Linux version 5.3.0-20-generic (buildd@lgw01-amd64-029) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)) #21-Ubuntu SMP Wed Oct 23 16:20:37 UTC 2019"
to "Linux version 5.3.0-20-generic (buildd@lgw01-amd64-029) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)) #21-Ubuntu SMP Wed Oct 23 16:20:37 UTC 2019"
Info: superblock features = 0 :
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
+--------------------------------------------------------+
| Super block |
+--------------------------------------------------------+
magic [0xf2f52010 : 4076150800]
major_ver [0x 1 : 1]
volum_name []
minor_ver [0x d : 13]
log_sectorsize [0x 9 : 9]
log_sectors_per_block [0x 3 : 3]
log_blocksize [0x c : 12]
log_blocks_per_seg [0x 9 : 9]
segs_per_sec [0x 1 : 1]
secs_per_zone [0x 1 : 1]
checksum_offset [0x 0 : 0]
block_count [0x 3d7b000 : 64466944]
section_count [0x 1ea67 : 125543]
segment_count [0x 1ebd7 : 125911]
segment_count_ckpt [0x 2 : 2]
segment_count_sit [0x a : 10]
segment_count_nat [0x 6e : 110]
segment_count_ssa [0x f6 : 246]
segment_count_main [0x 1ea67 : 125543]
segment0_blkaddr [0x 200 : 512]
cp_blkaddr [0x 200 : 512]
sit_blkaddr [0x 600 : 1536]
nat_blkaddr [0x 1a00 : 6656]
ssa_blkaddr [0x f600 : 62976]
main_blkaddr [0x 2e200 : 188928]
root_ino [0x 3 : 3]
node_ino [0x 1 : 1]
meta_ino [0x 2 : 2]
cp_payload [0x 0 : 0]
crc [0x 0 : 0]
version Linux version 5.3.0-20-generic (buildd@lgw01-amd64-029) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)) #21-Ubuntu SMP Wed Oct 23 16:20:37 UTC 2019
Info: total FS sectors = 515735552 (251824 MB)
Invalid CP CRC offset: 0
Invalid CP CRC offset: 0
[f2fs_do_mount:3273] Can't find valid checkpointНовее версии f2fs-tools просто нет, я собирал последнюю мастер-версию с kernel.org
Я проверил, файлы в этом разделе вроде на месте, с нодами вроде тоже всё ок... Я написал небольшой скрипт на php для проверки наличия в этом разделе любой ценной информации, вот его вывод:
root@dev-laptop:~# ./why.php /dev/sda1 10
00000000000000000000
..........
ADDR = 0x400 [1024]
1020f5f201000d0009000000030000000c0000000900000001000000010000000000000000b0d7030000000067ea0100d7eb0100020000000a0000006e000000f600000067ea0100000200000002000000060000001a000000f6000000e2020003000000010000000200000012cef9f64385490b85f7b592a115650600000000000000000000
.............................g........n......g...........................CIe..........
ADDR = 0x87c [2172]
240000006d70000000000000776d0000000000006f670000000000006a7000000000000061766900000000006d347600000000006d347000000000006d6b7600000000006d6f7600000000007765626d0000000077617600000000006d3461000000000033677000000000006f70757300000000666c6163000000006769660000000000706e670000000000737667000000000077656270000000006a61720000000000646562000000000069736f0000000000677a000000000000787a0000000000007a737400000000007064660000000000707963000000000074746300000000007474660000000000657865000000000061706b0000000000636e74000000000065786f00000000006f646578000000007664657800000000736f000000000000646200000000000000000000
$...mp......wm......og......jp......avi.....m4v.....m4p.....mkv.....mov.....webm....wav.....m4a.....3gp.....opus....flac....gif.....png.....svg.....webp....jar.....deb.....iso.....gz......xz......zst.....pdf.....pyc.....ttc.....ttf.....exe.....apk.....cnt.....exo.....odex....vdex....so......db..........
ADDR = 0xa84 [2692]
4c696e75782076657273696f6e20352e332e302d32302d67656e6572696320286275696c6464406c677730312d616d6436342d3032392920286763632076657273696f6e20392e322e3120323031393130303820285562756e747520392e322e312d397562756e7475322929202332312d5562756e747520534d5020576564204f63742032332031363a32303a333720555443203230313900000000000000000000
Linux version 5.3.0-20-generic (buildd@lgw01-amd64-029) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)) #21-Ubuntu SMP Wed Oct 23 16:20:37 UTC 2019..........и так дальше... там и файлы есть, но инфы на диске 250 гб, а метаинформацию с названиями файлов, их размером и расположением на диске хз где и как правильно искать.
В общем диск на первый взгляд в норме, тогда почему он не монтируется и fsck.f2fs ругается на CRC? Есть ли какой-то способ пофиксить это или хоть найти и достать файлы оттуда без написания тысячи строк кода??? Буду благодарен за любую информацию по этому поводу!
Перестал отрисовываться индикатор раскладки.
Он работал исправно многие месяцы, но после недавнего обновления перестал.
Есть другие варианты, которые работают, но мне необходим именно этот, поскольку умеет отображать три раскладки и показывать их определённым образом. В общем, отказываться от него я бы не хотел.
Что в нём некорректно записано, чего может нехватать?
/.config/i3/i3blocks.conf:
[keyboard-layout]
command=~/.config/i3/xkb_layout
markup=pango
interval=1
signal=11
separator=false
/.config/i3/xkb_layout:
#!/bin/sh
LAYOUT=$(xkblayout-state print "%n" | awk '{print toupper($0)}')
case $LAYOUT in
"LAT"
echo -n "<span foreground='#268bd2' weight='bold' background='#00181F'> "
echo -n ${LAYOUT}
echo -n " </span>"
;;
"CYR"
echo -n "<span foreground='#cb4b16' weight='bold' background='#00181F'> "
echo -n ${LAYOUT}
echo -n " </span>"
;;
"MOD"
echo -n "<span foreground='#00181F' weight='bold' background='#859900'> "
echo -n ${LAYOUT}
echo -n " </span>"
esac
Почему UDP пакеты, отправленные на 255.255.255.255 с клиента не видны на остальных клиентах?
На сервере эти пакеты видны, но они похоже никуда больше не идут.
Что и куда нужно прописать, чтобы остальные клиенты внутри VPN получали эти пакеты?
Или оно не так работает?
Как минимум клиенты не видят друг друга в игре по LAN.
Т.е. пакеты с каждого клиента на сервер уходят и тишина.
Логи tcpdump одного из клиентов на сервере на интерфейсе wg0.
16:29:39.942995 IP 10.0.0.10.43124 > 255.255.255.255.43124: UDP, length 88
16:29:49.945035 IP 10.0.0.10.43124 > 255.255.255.255.43124: UDP, length 79
16:29:59.947711 IP 10.0.0.10.43124 > 255.255.255.255.43124: UDP, length 79
16:30:09.951737 IP 10.0.0.10.43124 > 255.255.255.255.43124: UDP, length 79
16:30:34.951693 IP 10.0.0.10.43124 > 255.255.255.255.43124: UDP, length 88
16:30:44.955056 IP 10.0.0.10.43124 > 255.255.255.255.43124: UDP, length 79
16:30:54.956994 IP 10.0.0.10.43124 > 255.255.255.255.43124: UDP, length 79
16:31:04.958339 IP 10.0.0.10.43124 > 255.255.255.255.43124: UDP, length 79
16:31:29.958226 IP 10.0.0.10.43124 > 255.255.255.255.43124: UDP, length 88
Если запустить тот же hamachi, то через него почему-то работает.