Собственно, сабж: https://store.steampowered.com/app/925580/Euro_Truck_Simulator_2__Beyond_the_...
DLC примечательно тем, что в игру наконец-то включили Россию, пусть и всего несколько городов.
Карта: https://steamcdn-a.akamaihd.net/steam/apps/925580/extras/map.jpg
Учитывая, что он 2-пиновый?
Приветствую, ЛОР.
Проблема такова: по непонятной причине, производитель видеокарты установил очень странную кривую скорости вращения вентилятора — так, на 100% они включаются только при температуре в 91 градус (sic!), что, само собой, грозит перегревом. На винде подобная проблема решается легко — кривую можно настроить в MSI Afterburner. Но как это сделать в GNU/Linux? Пока вижу только два варианта:
1. В nvidia-settings можно установить произвольную скорость вращения, но только статическую — т.е. не зависящую от температуры, что неудобно.
2. Как вариант, можно написать скрипт, который бы сверял температуру через определённый интервал времени, и устанавливал соответствующую скорость вращения, но это костыльное и ненадёжное решение.
Как быть, ЛОР?
Разработчики Lubuntu выпустили очередную бета-версию дистрибутива, но в этот раз, с большим отличием: начиная с этого момента, проект окончательно перешёл на рабочее окружение LXQt, и во всех последующих версиях LXDE поддерживаться уже не будет. Ранее в качестве причин для такого решения разработчики называли стагнацию в разработке LXDE и устаревание тулкита GTK2 (с использованием которого он и был написан).
Напомним, что LXQt — это легковесное и модульное рабочее окружение, развиваемое совместными усилиями участников проектов LXDE, Razor-Qt и Hawaii. Его разработка началась в 2013г., а первая версия вышла годом позже. Примерно в тоже время сообщество Lubuntu начало обсуждать перспективу перехода дистрибутива на LXQt, а в 2017 году начало выпускать соответствующие полуофициальные тестовые сборки под названием Lubuntu Next, однако окончательная миграция с LXDE откладывалась до сих пор.
Перемещено anonymous_incognito из ubuntu
TL;DR в конце поста.
В 2013 году я писал про то, с какими проблемами столкнулся при попытке использовать openSUSE — одной из них, в частности, была невозможность создать PPPoE-соединение и подключиться к сети из-за отсутствия соответствующих пакетов, которые, по неизвестной причине, не вошли в состав дистрибутива по умолчанию.
Казалось бы, с тех пор прошло 5 лет, и таких глупых ошибок в мажорных дистрибутивах уже нет. Но, как выяснилось, это не так.
Сегодня, с целью проверить «живучесть» старой флешки, я решил записать на неё что-нибудь полезное, а именно, Fedora 28 редакции «Python Classroom». Насколько я понял, редакция полуофициальная, а учитывая, что в ней в состав всего лишь была добавлена пара десятков пакетов, то проблема, с которой я столкнулся, скорее всего присутствует и в других версиях.
Итак, образ записан, проверен в Qemu, перезагружаемся. После загрузки, само собой, я сразу же решил настроить сеть. Случайно отключив апплет (как оказалось, «Turn off» относилось не к конкретному соединению), отправился в настройки. Тут-то и начались первые подозрения — пункта «PPPoE/DSL» просто нет! Есть лишь три секции, Wired, VPN, Proxy и Wi-Fi в отдельном окне. И всё.
Подумав, что за всем этим стоят разработчики гнома, желающие запрятать чуть менее популярные возможности как можно дальше от глаз пользователя, я пошёл по другому пути, запустил nm-connection-editor. Создал PPPoE-соединение, как обычно, без каких-либо проблем. Но необходимый пункт на странице настроек сети так и не появился. Окей, подлючаемся по-другому, nmcli c up [имя соединения], И... ничего. Обрывается с ошибкой.
Смотрим логи, они указывают на отсутствие /usr/lib64/NetworkManager/libnm-ppp-plugin.so. Без какой-либо надежды копирую соответствующий файл из установленной системы. Само собой, желаемого результата (подключения) это не дало, но, что характерно, на странице настроек сети появилась секция PPPoE, а моё созданное соединение начало отображаться в апплете.
Перезагружаюсь обратно в уютную Manjaro, Гуглю. Как выяснилось, необходимый пакет носит имя NetworkManager-ppp. Нахожу несколько интересных ссылок:
https://bugzilla.redhat.com/show_bug.cgi?id=1591963
https://fedoramagazine.org/fedora-26-is-here/
https://ask.fedoraproject.org/en/question/107815/dsl-not-working-on-f26/
Все они указывают на одно — NetworkManager-ppp не был включён в состав системы по умолчанию! Причём, как миинимум начиная с Fedora 26. И они об этом знают (см. багрепорт по первой ссылке — баг подтверждают несколько человек, но ни единого ответа нет, причём уже довольно долго)! И ничего не предпринимают.
Я прекрасно понимаю, почему у разработчиков может возникнуть желание урезать дефолтную систему, даже за счёт мелких пакетов. Но это — не очередная утилита, не бесполезная прикладная программка. По сути, удалив этот пакет из состава, разработчики лишили дистрибутив автономности — и тогда как при установке это недоразумение не вызовет серьёзных проблем (достаточно лишь каким-то отдельным образом скачать один небольшой пакет — нужно лишь знать о проблеме заранее), то в качестве Live-системы для использования в чрезвычайных ситуациях Fedora практически потеряла свою ценность.
Честно говоря, я в шоке. Почему? Что заставило федоровцев пойти на такое? Неужели им совершенно наплевать на своих пользователей?
TL;DR: в федоре из коробки невозможно подключиться по PPPoE.
https://i.imgur.com/NpVf9xg.png.
Для Ъ: видео продолжает проигрываться при браузинге сайта (просмотре истории, плейлистов, поиске других видео и т.д.).
Кажется, они поняли, что YouTube постепенно превращается в музыкальный сервис, и делают шаги в этом направлении. Годно.
Приветствую.
Проблема заключается в том, что я сменил свой чрезвычайно бюджетный (AMD A4-7300) процессор на чуть менее бюджетный (AMD Athlon X4 840). TDP обоих — 65 Вт, при этом температура разнится значительно: первый показывал 32-37 в простое и до 50 градусов в нагрузке, тогда как второй — 40-45 в простое и до 65 в нагрузке. Кулеры (процессорный/системный), всё остальное осталось прежним (кроме термпопасты, см. ниже), при этом разница велика.
На данный момент есть два подозрения:
1. Термопаста. На первом использовалась термопаста, идущая в комплекте, на новом — Steel Frost Zinc (STP-1), причём характеристики последней явно лучше. Нанесена она тоже, по субъективным ощущениям, правильно.
2. В предыдущем процессоре было интегрированное видео, при этом оно НЕ использовалось, в новом же его нет. Может ли это сказаться на температуре?
Google, как и всегда в таких случаях, ответа не даёт — судя по отзывам в интернет-магазинах, обзорам и т.д., данные о его средней температуре сильно разнятся — кто-то утверждает о 45 градусах в нагрузке, кто-то заявляет о той же температуре, но в простое...
В чём проблема, ЛОР? Возможно ли, что температура отличается так сильно при одинаковом TDP?
Приветствую.
Непосредственно проблему можно наблюдать на скриншоте графика из xfce4-taskmanager: https://i.imgur.com/qIcXbXM.png. На протяжении временного периода, который отображает график, был запущен Firefox (актуальной версии). Причём, что характерно, пики нагрузки могут возникнуть из-за разных ситуаций: так, всплеск до 100% практически гарантированно происходит при загрузке более 3 вкладок одновременно (что, в целом, объяснимо), но не только: порой открытие выпадающего элемента на, казалось бы, вполне простой странице происходит с заметным визуальным лагом, а нагрузка ЦП в это время находится на уровне 60-80%.
Само собой, сайты становятся тормознее с каждым годом, а процессор довольно слабый — AMD A4-7300, но нагрузка выглядит слишком высокой даже для него... Более того, на прошлой конфигурации я использовал Chromium, и, несмотря на явно более старое железо, столь нехарактерного поведения не было.
Собственно, вопрос: нормально ли это? Неужели всё действительно столь плохо?
P.S. layers.acceleration.force-enabled включён, но, по субъективным оценкам, он практически не влияет на производительность. Из дополнений лишь uBlock Origin, система — Manjaro, но на Ubuntu ситуация абсолютно идентична. Запуск Firefox из терминала не даёт какой-либо дополнительной информации об ошибках или чём-то подобном.
Для Ъ: «Compositor» был переведён как «Эффекты» (!), а «Display fullscreen overlay windows directly» как «Отображать полноэкранные окна сразу» (!!!).
Полное извращение сути написанного.
Собственно сабж: https://www.bountysource.com/issues/56146126-ice-turn-tcp-via-an-http-proxy-d..., (что-то специфическое и связанное с WebRTC).
Заявка висит уже 2 года, но вчера вознаграждение за неё подняли с $8k до $50k.
ЛОР'овцы, налетайте.
http://www.dfworkshop.net/projects/daggerfall-unity/live-builds/
https://github.com/Interkarma/daggerfall-unity
Обещают улучшенную графику, поддержку модов и высоких разрешений, а также прочие нужные ништяки. Судя по Roadmap, игра ещё далека от реализации, но проект выглядит многообещающим.
Для запуска требуются ресурсы оригинального Daggerfall. Лицензия — MIT, но написано с использованием мерзко-проприетарного Unity3D.
Приветствую.
Последняя версия Manjaro GNU/Linux, systemd 238. Система загружается чрезвычайно долго — около 2 минут, при этом на протяжении загрузки наблюдается высокая нагрузка на HDD. Что характерно, перезагрузка после этого проходит нормально — в течение 20-30 секунд — до следующего раза.
systemd-analyze blame:
23.728s dev-sdb2.device
22.058s systemd-journal-flush.service
20.006s systemd-udevd.service
18.153s udisks2.service
1.952s systemd-sysusers.service
1.332s ufw.service
1.138s user@1000.service
1.113s NetworkManager.service
1.061s ldconfig.service
1.009s systemd-modules-load.service
1.009s polkit.service
1.002s systemd-fsck@dev-sdb1.service
806ms macspoof@multi-user.service
753ms systemd-logind.service
744ms alsa-restore.service
740ms avahi-daemon.service
558ms systemd-sysctl.service
537ms systemd-tmpfiles-setup-dev.service
427ms systemd-journal-catalog-update.service
361ms systemd-binfmt.service
312ms systemd-update-utmp.service
272ms dev-mqueue.mount
269ms systemd-tmpfiles-setup.service
250ms systemd-tmpfiles-clean.service
213ms systemd-udev-trigger.service
202ms sys-kernel-debug.mount
200ms dev-hugepages.mount
199ms kmod-static-nodes.service
198ms systemd-remount-fs.service
194ms tmp.mount
172ms systemd-journald.service
139ms boot-efi.mount
97ms systemd-random-seed.service
91ms rtkit-daemon.service
34ms dev-sdb3.swap
29ms systemd-user-sessions.service
8ms systemd-update-done.service
7ms proc-sys-fs-binfmt_misc.mount
6ms sys-fs-fuse-connections.mount
3ms sys-kernel-config.mount
4.207s dev-sdb2.device
1.962s systemd-journal-flush.service
1.758s systemd-udevd.service
1.455s ufw.service
921ms NetworkManager.service
876ms polkit.service
681ms systemd-tmpfiles-setup-dev.service
547ms macspoof@multi-user.service
544ms udisks2.service
540ms systemd-modules-load.service
503ms systemd-logind.service
481ms avahi-daemon.service
478ms alsa-restore.service
461ms systemd-journald.service
386ms systemd-tmpfiles-setup.service
353ms sys-kernel-debug.mount
352ms systemd-remount-fs.service
352ms dev-hugepages.mount
338ms user@1000.service
272ms systemd-udev-trigger.service
260ms systemd-fsck@dev-sdb1.service
229ms systemd-binfmt.service
176ms dev-sdb3.swap
161ms boot-efi.mount
117ms systemd-sysctl.service
116ms rtkit-daemon.service
115ms dev-mqueue.mount
109ms kmod-static-nodes.service
52ms systemd-random-seed.service
41ms systemd-user-sessions.service
40ms systemd-update-utmp.service
32ms proc-sys-fs-binfmt_misc.mount
12ms tmp.mount
6ms sys-fs-fuse-connections.mount
3ms sys-kernel-config.mount
Как решить эту проблему?
Приветствую.
Проблема заключается в следующем: COD:MW2 под Wine'ом с gallium-nine вылетает через несколько секунд после загрузки локации, в выхлопе следующее:
0009:fixme:module:load_dll Loader redirect from L"d3d9.dll" to L"d3d9-nine.dll"
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32f5e4,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x32f5e4,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",1,0x32f5e4,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),1,0x32f5e4,0x00000000), stub!
0009:fixme:d3d9nine:d3dadapter9_new
Native Direct3D 9 is active.
For more information visit https://wiki.ixit.cz/d3d9
0009:fixme:system:SystemParametersInfoW Unimplemented action: 59 (SPI_SETSTICKYKEYS)
0009:fixme:system:SystemParametersInfoW Unimplemented action: 53 (SPI_SETTOGGLEKEYS)
0009:fixme:system:SystemParametersInfoW Unimplemented action: 51 (SPI_SETFILTERKEYS)
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32f9d4,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x32f9d4,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",1,0x32f9d4,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),1,0x32f9d4,0x00000000), stub!
0009:fixme:d3d9nine:d3dadapter9_new
Native Direct3D 9 is active.
For more information visit https://wiki.ixit.cz/d3d9
0009:fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x32f8e4,0x00000000), stub!
0009:fixme:d3d9nine:DRI3PresentGroup_GetMultiheadCount (0x1bd9e8), stub!
0009:fixme:d3d9nine:DRI3PresentGroup_GetMultiheadCount (0x1bd9e8), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32f6e4,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32e584,0x00000000), stub!
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
Ошибка сегментирования (стек памяти сброшен на диск)
dmesg (релевантная часть):
[ 666.807870] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 668.137058] radeon 0000:00:01.0: vbo resource seems too big for the bo
[ 668.137070] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:855 texture bo too small (layer size 8388608, offset 0, max layer 1, depth 1, bo size 356352) (1024 2048)
[ 668.137133] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 674.250704] Forbidden register 0x0B58 in cs at 10014
[ 674.250766] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 674.883699] radeon 0000:00:01.0: vbo resource seems too big for the bo
[ 674.883703] radeon 0000:00:01.0: vbo resource seems too big for the bo
[ 674.883704] radeon 0000:00:01.0: vbo resource seems too big for the bo
[ 674.883706] radeon 0000:00:01.0: vbo resource seems too big for the bo
[ 674.883708] radeon 0000:00:01.0: vbo resource seems too big for the bo
[ 674.883715] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:855 texture bo too small (layer size 16384, offset 0, max layer 6, depth 1, bo size 36864) (64 64)
[ 674.883767] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 1448.240558] radeon 0000:00:01.0: vbo resource seems too big for the bo
[ 1448.240567] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:855 texture bo too small (layer size 8388608, offset 0, max layer 1, depth 1, bo size 5308416) (1024 2048)
[ 1448.240630] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 1450.782923] [drm:radeon_cs_packet_parse [radeon]] *ERROR* Can not parse packet at 14285 after CS end 14285 !
[ 1450.782945] [drm:evergreen_packet3_check.isra.14 [radeon]] *ERROR* bad SET_RESOURCE (tex)
[ 1450.782961] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 1451.015988] radeon 0000:00:01.0: vbo resource seems too big for the bo
[ 1451.015998] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:855 texture bo too small (layer size 8388608, offset 0, max layer 1, depth 1, bo size 5308416) (1024 2048)
[ 1451.016064] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 1453.256810] [drm:radeon_cs_packet_parse [radeon]] *ERROR* Can not parse packet at 16150 after CS end 16150 !
[ 1453.256833] [drm:evergreen_packet3_check.isra.14 [radeon]] *ERROR* bad SET_RESOURCE (tex)
[ 1453.256848] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
При этом перед вылетом видны артефакты в текстурах игры.
Схожая проблема и с проигрыванием видео через mpv:
AO: [pulse] 48000Hz 5.1(side) 6ch float
Using hardware decoding (vdpau).
VO: [opengl] 1280x536 vdpau[yuv420p]
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22)
...
[ 1993.198548] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:916 mipmap [5] bo too small (layer size 1024, offset 870400, coffset 1045504, max layer 1, depth 1, bo size 1044480) level0 (640 136 1)
[ 1993.198551] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:921 problematic surf: (128 4) (1 2 1 0 1 4 3)
[ 1993.198585] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 1993.238516] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:916 mipmap [5] bo too small (layer size 1024, offset 870400, coffset 1045504, max layer 1, depth 1, bo size 1044480) level0 (640 136 1)
[ 1993.238520] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:921 problematic surf: (128 4) (1 2 1 0 1 4 3)
[ 1993.238554] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 1993.284603] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:916 mipmap [5] bo too small (layer size 1024, offset 870400, coffset 1045504, max layer 1, depth 1, bo size 1044480) level0 (640 136 1)
[ 1993.284607] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:921 problematic surf: (128 4) (1 2 1 0 1 4 3)
В этом случае вылета не происходит, но вместо видео видны лишь артефакты.
Видеокарта Radeon HD 8470D (интегрированная), система Ubuntu 17.10, ядро 4.15.0-041500-generic, на данный момент стоят драйверы/mesa/etc из PPA padoka — до этого я использовал PPA oibaf'а, но проблему это не решило.
Xorg.0.log: https://pastebin.com/qVY5FMvv
glxinfo | grep OpenGL:
OpenGL vendor string: X.Org
OpenGL renderer string: AMD ARUBA (DRM 2.50.0 / 4.15.0-041500-generic, LLVM 7.0.0)
OpenGL core profile version string: 4.3 (Core Profile) Mesa 18.1.0-devel - padoka PPA
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 18.1.0-devel - padoka PPA
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel - padoka PPA
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
Гуглинг подсказал, что некоторым удалось решить схожую проблему путём отключения ColorTiling2D в xorg.conf, но мне это решение не помогло. Также я попробовал установить драйверы (xserver-xorg-video-radeon) штатной версии (не из PPA), но эффекта тоже не было — видимо, проблема лежит в другом (Mesa?).
Собственно, как решить эту проблему?
P.S. Судя по S.M.A.R.T., жёсткий диск находится на грани отказа, но я не совсем уверен, связано ли это с моей проблемой.
Приветствую.
Собственно, проблема заключается в невозможности загрузить систему при включённом DPM. С параметром radeon.dpm=0 система загружается успешно, но страдает от низкой производительности. С включённым же DPM, монитор переходит в «режим сохранения энергии» через несколько секунд после начала загрузки, после чего система перезагружается...
Мат. плата MSI A68HM-P33 v2, процессор AMD A4-7300 APU (с Radeon HD 8470D), система Ubuntu 17.10 с ядром 4.13.0-32-generic.
Вывод dmesg (с отключённым DPM):
https://pastebin.com/af5Zi9nV
Xorg.0.log, опять же, с отключённым DPM:
https://pastebin.com/U9E6SVw3
Как решить эту проблему?
Итак, с сентября Alibaba Cloud предлагает некоторые домены по цене в $0.17 за первый год регистрации, один домен на аккаунт. В целях экономии я решил воспользоваться этой возможностью, но в итоге потерял ещё больше. Обо всём по порядку.
Во-первых, регистрация в Alibaba Cloud не работает в Chromium — на одном из шагов начинается бесконечный редирект — в итоге пришлось расчехлить Firefox. Но это далеко не самая печальная проблема. Далее, после заполнения всех регистрационных данных, Alibaba Cloud требует провести верификацию карты, с использованием которой осуществляется платёж. И хотя процедура стандартная, конкретно здесь она реализована неприятным образом.
Во-первых, в справке указано, что для верификации будет произведено 2 списания средств — $1 и рандомная сумма меньше одного доллара. Так как на балансе моей карты было примерно $0,60, то первой транзакции не было, во время второй же было украдено $0,36.
Начались новые проблемы: как заявляет справка Alibaba Cloud, для подтверждения верификации необходимо ввести код, включённый в описание транзакции, но его попросту не оказалось. Гуглинг выявил, что проблема распространённая, поэтому было решено использовать второй метод подтверждения — необходимо было указать точную сумму транзакции, в долларах.
Естественно, и это вызвало проблемы, так как моя основная карта для серых интернет-платежей — рублёвая. При этом, что характерно, основной интерфейс Qiwi также показывает стоимость транзакций исключительно в рублях. Попытки произвести необходимый расчёт самостоятельно провалились из-за различных курсов обмена. Изюминку добавляло то обстоятельство, что количество попыток произвести верификацию ограничено, и неизвестно, что произойдёт, если они закончатся. К счастью, Qiwi позволяет получить выписку не только лишь по связанному Qiwi-кошельку, но и непосредственно по самой карте, с указанием сумм транзакций в долларах, поэтому последняя из допустимых попыток удалась.
Верификация удалась. В личном кабинете, что характерно, рекомендовано использовать Chrome — при этом войти в этот самый кривой кабинет получилось лишь с помощью Firefox. Домен был приобретён, всё якобы завершилось удачно, но не совсем.
В справке Alibaba Cloud указано, что средства, украденные во время процесса верификации, должны вернуться в течение 24 часов. Разумеется, этого не произошло, но я не уделял этому внимания — в личном кабинете Qiwi значилось, что платёж ещё обрабатывается, а значит, первый, верификационный, платёж просто не завершится, и деньги будут возвращены.
Каково же было моё удивление, что сегодня оба платежа завершились успешно — и мои $0,36 не были возвращены законному владельцу, но оказались в руках классового врага! Время вышло, платёж обработан — шансов уже нет. Бороться с идиотской техподдержкой также, скорее всего, нет смысла.
В итоге, вместо $0,17, я потратил $0,17 (домен) + $0,03 (комиссия) + $0,36 (украденные верификацией средства). = $0,56. Проще говоря, Alibaba Cloud жестоко обокрал меня, при этом уровень удобства, качество документации и поддержки были фактически на нуле.
Видимо, скупой и вправду платит дважды, но Alibaba Cloud показала себя чрезвычайно некомпетентной организацией, ошибки которой могут привести к финансовым потерям.
Никому нельзя доверять :-(.
Приветствую. Озадачился интересной проблемой, которую мой разум разрешить не в состоянии.
Допустим, имеется две страны. X и Y. По результатам социологических опросов, 98% граждан страны X верят, что съедать маленьких котят заживо — это плохо. В стране Y такого же мнения, в свою очередь, придерживается лишь 96% населения.
Допустим, что есть котят заживо действительно плохо, и допустим, что чем меньше (относительно) сторонников поедания котят в стране, тем эта страна лучше.
Выходит, страна X в 1.020833333 раз (98/96) лучше, чем страна Y, так как именно настолько больше (в процентном соотношении) противников поедания котят в X. Но при этом, страна Y в 2 раза (4/2) хуже страны X, так как в ней именно в два раза больше сторонников поедания котят (опять же, в процентном соотношении).
Итак: страна X в 1.020833333 раз лучше чем Y, но при этом страна Y в 2 раза хуже чем X.
Числа не совпадают! Почему? Что я упустил? Объясните, пожалуйста.
Приветствую.
Чтобы не быть голословным, сразу же прикладываю ссылку, как всегда:
А теперь обо всём по порядку.
Итак. Как мы все прекрасно знаем, долгое время Wiki была частью ЛОР'а. Золотые времена. Ею управляли наши любимые (но не всегда справедливые) модераторы, статьи правились и дополнялись, вандалы банились, единороги испускали радугу и т.д. и т.п.
Но в июне 2015 года всё резко изменилось. Не могу знать, в чём была истинная причина. Скорее всего, организационные проблемы. Но так или иначе, Wiki прекратила своё существование в составе ЛОР'а.
И, казалось бы, большинству было совершенно наплевать... Кроме 
proud_anon, пожалуй, никто не озаботился её спасением.
Но меня это категорически не устроило. И я сделал то, что должен был сделать. Так началась история lorwiki.ru.
И, скажу честно, я всё понимал. Я знал, что неспособен на адекватность, неспособен на диалоги и т.д., поэтому в какой-то мере судьба проекта была предрешена. Но, повторюсь, меня поражает лицемерие людей, которые не предприняли ничего для спасения этого чудесного источника знаний, но при этом постоянно обвиняющих меня во всевозможных грехах.
В общем, судьба проекта была непростой. Драмы было много. Уход одного из модераторов LorWiki, конфликт с администрацией ЛОР'а, политические разногласия. Но проект жил. До некоторого времени.
Жил, несмотря на давление, оказываемое на его администратора. Серьёзно — многие пользователи ЛОР'а, горячо поддерживаемые модераторами, устроили настоящую травлю. Они гнобили и унижали, банили и удаляли мои сообщения.
Естественно, длиться это вечно не могло. И в начале мая этого года, когда один из модераторов ЛОР'а повёл себя особенно неконструктивно, а один из пользователей донёс на меня в МВД из-за политических разногласий, я сдался. Можете называть меня слабаком, но подобные вещи действительно способны очень сильно ударить по мотивации человека.
Я, взбешённый всем этим, начал мстить. Жестоко и беспощадно. Я делал не вполне этичные вещи, но это был ответ на то безграничное зло, что творила модерация.
Когда же огонь прекратил полыхать, остались лишь пустота и апатия. Я был разочарован. Я забросил LorWiki, делая лишь мелкие изменения, такие как установка политического баннера, например. Но вскоре и это дело я забросил.
Я начал думать, что проблема была во мне. Я осознавал это сильнее и сильнее. Тогда я отрёкся от всего. Я просто не оплатил хостинг, и в итоге LorWiki прекратила работу... Я не знал, что будет дальше, и мне было, в общем, наплевать.
Но позднее мелькнул лучик света. 22 июня mandala объявил о воссоздании LorWiki. Я был безумно, безумно рад этому событию! Люди продолжили моё дело, несмотря на то, какой сволочью я был.
Казалось бы, всё пришло к лучшему. LorWiki в надёжных руках психически здорового человека. Но нет, нет и нет! Всё обрушлось уже очень скоро.
Итак. 25 июня администратор новой LorWIki (LorWIki 3.0) cetjs2 объявил, что намерен включить новую LorWiki в состав вики-объединения WikiUnion; прочие администраторы, включая главного — mandala — его поддержали. Я начал интересоваться темой WIkiUnion и углубился в их идеи, планы и т.д. Ссылок давать не буду, так как этот гадюшник достоин смерти и пиарить я его не намерен.
То, что я прочитал меня ужаснуло. Первое, что бросилось в глаза — это участники этого проекта.
Но и это ещё не всё! Для полного впечатления необходимо взглянуть на документ организации. Во-первых, она очень бюрократична, в худшем смысле этого слова. Состоит из нескольких «органов», включая «службу безопасности» (sic!). И эти «органы» имеют огромную власть над всеми участниками союза. Всего лишь пара цитат:
Конгресс занимается приемом важнейших решений, которые имеют значение для всех проектов и для организации вообще. Принимает решение о блокировке и разблокировке лиц во всех проектах
Прекрасно, просто прекрасно! Некие нонеймы, не имеющие отношения к ЛОР'у, будут иметь право забанить любого участника LorWiki! Читаем далее.
Также Комиссар имеет право зачищать из любого вики-проекта — члена WU личные данные, в случае, если ему поступил запрос или жалоба от заинтересованного компетентного лица
Проще говоря — цензура по первому запросу определённых людей.
Что всё это значит? Если заявка, которую подала администрация LorWIki 3.0, будет одобрена, то проект будет потерян для общества. Люди, явно не благородные и совершенно точно не имеющие отношения к ЛОР'у, получат полную, неограниченную власть над LorWiki...
Сказать, что это меня разочаровало, это значит не сказать ничего. Но я не имею морального права указывать mandala, кейтсу и остальным, что делать. Я их покинул — и больше не имею власти. И это хорошо.
Но, само собой, оставить ситуацию такой, какова она есть, я не мог. Я искренне не желал вновь возвращаться в строй, но этот проект был моим детищем долгое время. И я не позволю над ним надругаться.
В итоге, сегодня, была создана LorWIki 4.0. Адрес: https://wiki.gnu.technology. База данных была сохранена, поэтому вы можете использовать свои пароли для входа на свои аккаунты, как всегда.
Политика проекта осталась той же. Главная цель — сохранение и поддержание архива, развитие второстепенно. И пусть раньше я уделял недостаточно внимания проекту, я постараюсь предпринять усилия для того, чтобы он жил.
Я прекрасно понимаю, что вы считаете меня фриком. Я знаю, что в моих руках LorWiki будет нестабильной, политизированной и полной неоднозначости. Но задумайтесь. Что лучше: свобода и неадекватность, или адекватность и несвобода?
Повторяю ещё раз: я не оказываю давление ни на кого. К проекту mandala — https://lorwiki.org.ru — я по-прежнему отношусь хорошо и желаю ему всяческих успехов, но я вынужден был создать LorWiki 4.0 из-за несогласия с его политикой. Это нормально. Это естественно. В конце концов, две лорвики — это даже лучше, чем одна.
Мир всему миру. И пусть ЛОР и связанные с ним проекты цветут и развиваются.
На ЛОР'е об этом ещё не писали, поэтому...
Обнаружил сегодня на реддите: https://github.com/dino/dino. Jabber-клиент с красивым интерфейсом, GPLv3, на Vala и GTK3. Есть GPG и OMEMO плагины, но вот список поддерживаемых XEP'ов небольшой, к сожалению: https://github.com/dino/dino/tree/master/xmpp-vala/src/module/xep. Впрочем, проект развивается (последний коммит 5 дней назад) и выглядит многообещающим.
Что думает ЛОР'чик?
Искал статью Троцкого про индивидуальный террор, набрёл на какой-то большевистский сайт, и в результате скроллинга обнаружил вот эту интересную статью: https://www.1917.com/XML/wX7i37V6VPikUWQNApidtHLDYkU.xml
В целом грамотно написано, хотя я не совсем понял, что автор имел в виду, когда он говорил «Программный код, опубликованный под лицензией GNU, сохраняет потребительную стоимость, но одновременно теряет стоимость меновую». Ну и, конечно же, явно чувствуется его ненависть к коммерческому распространению софта. что есть бред.
Несколько цитат:
Одним из неофитов, привлеченных новой инфраструктурой, стал финский студент Линус Торвальдс, автор первоначальной версии ядра ОС Linux. Если бы он выбрал для кода другую лицензию, чем GPL, то его операционную систему постигла бы та же самая участь, что и тысячи других ОС, написанных энтузиастами — забвение
Оказалось, что единственный путь ко всеобщей свободе лежит через ограничение свободы меньшинства в интересах большинства
Как это произошло? Эпоха тотальной приватизации 80-х началась с распродажи созданных в университетах в предыдущие десятилетия технологий. Это стало возможно после принятия Конгрессом акта Байля-Доуля 1980 года
Подробнее про этот акт: https://en.wikipedia.org/wiki/Bayh–Dole_Act (лично я не знал о нём до этого момента).
Хотя, конечно же, есть и явные ляпы:
В конце 90-х система верстки [TeX] была почти полностью вытеснена коммерческими конкурентами в нишу «программ для математиков». Несмотря на то, что сообщество обладало полной свободой делать с исходным кодом системы все, что угодно, оно не смогло реализовать эти возможности.
Заявлять, что TeX/LaTeX провалился — это идиотизм, ИМХО.
Что думает многоуважаемый ЛОР'чик?
P.S. Картиночка в тему: https://i.imgur.com/jqbNs6j.jpg
В общем, я уже с 2014 года использую в качестве основной системы Linux Mint Debian Edition. 32-битную версию, само собой, так как оперативной памяти у меня не очень много.
Собственно, никаких проблем за это время у меня, в общем, не возникало. Обновлял систему не очень регулярно, но в целом поддерживал её в актуальном состоянии, не считая парочки нюансов.
Но сегодня я, читая старые посты на реддите, случайно обнаружил эту страницу на сайте Linux Mint: https://www.linuxmint.com/rel_betsy.php.
Сказать, что я был шокирован, значит не сказать ничего. Встревожила меня эта надпись:
To guarantee compatibility with non-PAE processors, the 32-bit versions of Linux Mint Debian come with a 586 kernel by default. This kernel does not support SMP, and as a consequence is only able to detect one core and one CPU
Собственно, в лёгкой панике я решил проверить, как обстоят дела:
pelmen@linuxmint ~ $ nproc
1
Вопрос: кто более идиот — я или разработчики Mint'а?
| ← назад | следующие → |