Решил попробовать новую 34-ю Федору. Скачал Fedora-Workstation-Live-x86_64-34-1.2.iso, проверил, что её SHA256 чексумма равна 865c4457dd066d3074c35a8847c8dac1380667c96a4f6d74526324dba14f1b5c как прописано тут. Записал на флешку, начинаю устанавливать, на выборе языка оно стабильно падает. Запускаю терминал и в нём sudo anaconda а в установщике большими красными буквами написано: PRE-RELEASE/TESTING.
Алло, гараж… я конечно бесплатный тестер, но имейте совесть.
И в догонку. Посмотрел сейчас прочие спины - Cinnamon отсутствует. Как это понимать? Единственный нормальный DE выпилили. Какого Столлмана они это сделали?
После прочтения очередной новости о развитии истории с проникновением намеренно уязвимых патчей в ядро Линукса возник вопрос, а возможно ли это в других проектах сравнимого уровня сложности? Взять например OpenBSD. Хотелось бы послушать местных аналитиков о безопасности других таких проектов.
Почему я, как автор темы, не могу удалить это анонимное непротребство сам, а должен идти на поклон к модераторам и ждать их реакцию? Почему единственной альтернативой этому является закрытие комментариев для всех анонимусов, часть из которых вполне нормальные люди и иногда пишут интересные тексты?
В теме о новых символах ухода за текстилем в юникоде я оставил следующий комментарий, который был удалён со следующей формулировкой:
Сообщение удалено xaizek по причине 5.1 Нецензурные выражения (-1)
Хорошая новость. Эти символы гораздо полезнее всяких пони и прочих пидоров.
Я его переформулировал и написал снова, но снова попал под удаление. Причём с ещё большим снятием скора.
Сообщение удалено Shaman007 по причине держи в курсе (-7)
Хорошая новость. Эти символы гораздо полезнее всяких пони и прочих гомосеков.
Shaman007, твоя реакция явно неадекватна. Ты обиделся за 🦄 или за 🏳️🌈 и прочие ЛГБТ символы в юникоде? Я уверен, что ты именно обиделся, потому что твоя реакция была непропроционально резкой.
Что касается первой версии моего комментария, xaizek, посмотри родной кинемотограф:
И таки новые символы ухода за текстилем в юникоде действительно полезнее всей этой ЛГБТ и прочей толерастии там же. Уважаемые модераторы, почему вы такие неадекватные?
Имеется мобильник Samsung со стоковой прошивкой Android 11. В настройках SMS есть пункт, помеченный значком N (новый) - Chat settings. Однако зайти в него невозможно. Сейчас, после очередного обновления стоковой прошивки от Samsung телефон спросил мой номер и этот вопрос относился к функции чата, но я нажал Skip. Куда теперь его ввести, чтобы можно было попасть в Chat settings? Добавление номера в свой профиль (в телефонной книге) не помогло.
Необходимо сделать аутентификацию на основе клиентских сертификатов в nginx. Есть ли в nginx какой-то API, при помощи которого можно управлять (добавлять, удалять) клиентскими сертификатами извне, вместо ручной правки соответствующего файла?
Если есть более удобные альтернативы nginx, буду рад услышать и о них. На самом деле, помимо аутентификации, мне нужен лишь прокси, который будет перенаправлять запросы на те или внутренние URL-и, в соответствии с path в исходных URL-ях запросов.
Поделитесь опытом использованием JHipster-а в Backend Java разработке. Как вы сохраняете написанное/модифицированное между регенерациями кода из JDL? Что рекомендуете почитать?
По плану эта версия должна была появиться ещё в марте, но дальше RC дело не продвинулось. Может кто-то из местных аналитиков в курсе или, что ещё лучше, работает в JetBrains и может рассказать?
UPDATE:
Таки вышел уже, несколько часов назад, но сайт ещё не обновился. Нашёл финальный релиз 2021.1 в Confluence Jetrains-а:
После недавних новостей о RedHat и травле RMS возник интерес в заменене Федоры на что-то другое, тоже rpm based и так же разрабатываемое корпорацией, а не группой энтузиастов. Как SuSE проявила себя в этой истории с преследованием RMS? Какова их позиция в этой драме?
P.S. GPL и идеологию Столлмана не разделяю, но его преследование считаю необоснованным и неправильным.
Вот, не только Lombok пострадал. Всё пропало или скоро починят?
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.springframework.ldap.core.support.LdapContextSource
at org.springframework.boot.autoconfigure.ldap.embedded.EmbeddedLdapAutoConfiguration$EmbeddedLdapContextConfiguration.ldapContextSource(EmbeddedLdapAutoConfiguration.java:205) ~[spring-boot-autoconfigure-2.4.4.jar:2.4.4]
at jdk.internal.reflect.GeneratedMethodAccessor431.invoke(Unknown Source) ~[na:na]
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
at java.base/java.lang.reflect.Method.invoke(Method.java:567) ~[na:na]
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) ~[spring-beans-5.3.5.jar:5.3.5]
... 127 common frames omitted
UPDATE: нашёл источник проблемы.
Exception in thread "main" java.lang.IllegalAccessError: class org.springframework.ldap.core.support.AbstractContextSource (in unnamed module @0x108c4c35) cannot access class com.sun.jndi.ldap.LdapCtxFactory (in module java.naming) because module java.naming does not export com.sun.jndi.ldap to unnamed module @0x108c4c35
at org.springframework.ldap.core.support.AbstractContextSource.<clinit>(AbstractContextSource.java:77)
Очень похоже на то, что случилось с Lombok, но уже в JNDI LDAP:
private static final Class<com.sun.jndi.ldap.LdapCtxFactory> DEFAULT_CONTEXT_FACTORY
= com.sun.jndi.ldap.LdapCtxFactory.class;
UPDATE #2: В spring-ldap-core это уже исправили, исправление должно войти в следующую версию 2.3.4-RELEASE
Как известно, Чебурашка был найден в коробке с израильскими апельсинами. Недавно произошёл очень похожий случай. В коробке с израильскими климантинами (сладкий сорт мандарин), прибывшими в норвежскую деревню Valldal, был найден iPhone 11, принадлежащий израильтянке эфиопского происхождения, работающей на упаковке этих самых климантин и обронившей мобильник в один из ящиков. iPhone удалось разблокировать с первой попытки, набрав простой пароль 123456. Немного труднее оказалось связаться с хозяйкой, не отвечавшей на звонки из Норвегии. Работники норвежского овощного магазина скинулись и уже выслали iPhone-Чебурашку его хозяйке - обратно в Израиль.
Фотографии и подробности, на иврите, тут, на норвежском, тут.
Так получилось, что кофе я пью крайне редко. Не потому, что не люблю, а просто потому, что пить кофе каждый день, как некоторые, не хочу. Если пью растворимый кофе, то обычно добавляю в него молоко. Но молоко я не пью вообще, ну разве что как добавку к кофе. Непереносимости лактозы нет, просто не люблю молоко. В чай, который пью гораздо чаше, молоко никогда не добавляю. В любые другие продукты тоже не добавляю, только в растворимый кофе. Покупать молоко лишь ради 2 - 3 чашек кофе в месяц как-то совсем несерьёзно. Но как тогда пить растворимый кофе у себя дома - те самые 2 - 3 чашки в месяц? Завести кота, чтобы он допивал оставшееся молоко из литровой упаковки? Поселить у себя девушку, любящую молоко, лишь ради молока? Отдавать оставшееся молоко бомжу? Но в моём городе нет бомжей. Есть более практичные решения?
Manifold - плагин для javac, с открытым исходным кодом, добавляющий массу новых и необычных плюшек. Есть поддержка IntelliJ. Кто-то пробовали его использовать? Может ли Manifold заменить Lombok?
Проект собирался Maven-ом при помощи JDK 15. Сегодня решил попробовать JDK 16, а maven-compiler-plugin почему-то с ним не дружит:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project *****: Compilation failure -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project *****: Compilation failure
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure
at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1224)
at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:187)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
Кто-то знает что тут не так или как починить?
JDK 15/16 использую как промежуточные версии перед переходом на JDK 17, которая уже не будет обновляться на следующую мажорную версию достаточно долго, ибо LTS.
Недавно появилась первая официальная версия 7-Zip под Linux. Есть и официальные бинарные сборка от автора (Игоря Павлова) для разных процессорных платформ. Цитата от туда:
These new 7-Zip binaries for Linux were linked (compiled) by GCC without -static switch. And compiled 32-bit executables (x86 and armhf) didn’t work on some arm64 and amd64 systems, probably because of missing of some required .so files.
Please write here, if you have some advices how to compile and link binaries that will work in most Linux systems.
А всё почему? Судя по всему потому, что в разных дистрибутивах Linux мултибиблиотечночть (multilib - одновременная поддержка 32-х и 64-х битных бинарников) настроена или реализована неодинаково.
Видимо Игорь Павлов ещё не понял куда попал. Зато свобода и Столлман такой молодой!
Дайте мне автомат или хотя бы парабеллум, я хочу их расстрелять!
А если серьёзно, достал уже этот зоопарк пингвинов. Вот решил я поставить Skype в свою Fedora 33, а там зависимость на пакет, название которого указано в иной конвенции, принятой в SuSE.
$ sudo dnf install skypeforlinux-64.rpm
Last metadata expiration check: 0:33:21 ago on Wed 10 Mar 2021 15:59:54.
Error:
Problem: conflicting requests
- nothing provides libatomic1 needed by skypeforlinux-8.69.0.77-1.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
$ sudo dnf install skypeforlinux-64-insider.rpm
Last metadata expiration check: 0:33:29 ago on Wed 10 Mar 2021 15:59:54.
Error:
Problem: conflicting requests
- nothing provides libatomic1 needed by skypeforlinux-8.70.76.36-1.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
$ dnf list libatomic
Last metadata expiration check: 1:18:56 ago on Wed 10 Mar 2021 15:31:54.
Installed Packages
libatomic.x86_64 10.2.1-9.fc33 @updates
Недавно возникла проблема аутентификации Git на Bitbucket
$ git pull
Password for 'https://******@bitbucket.org':
remote: Because you enabled two-step verification for your Atlassian account, you'll need to authenticate with an app password. Create an app password at https://bitbucket.org/account/admin/app-passwords
fatal: unable to access 'https://bitbucket.org/******/******.git/': The requested URL returned error: 403
При этом two-step verification моего Atlassian аккаунта был включен гораздо раньше, но до сих пор команды вроде git pull продолжали работать по-прежнему, с простым запросом пароля. Предлагаемый выше app password работает, но пользоваться им совершенно неудобно, непрактично и, на мой взгляд, несекьюрно. Это просто ещё один пароль, сгенерированный самим bitbucket-ом. Очень длинный и сложный пароль, который я никогда не запомню и буду вынужден хранить в каком нибудь текстовом файле для постоянного copy/paste от туда.
Я решил попробовать использовать SSH Keys вместо app password. При помощи ssh-keygen сгенерировал пару RSA ключей, публичный ключ скопировал в https://bitbucket.org/account/settings/ssh-keys/ командой ssh-add -l проверил, что ssh-agent видит новые ключи и попробовал протестировать подключение, но оно не работает
Наш айтишник говорит, что открыл по этому поводу тикет и в Bitbucket сейчас разбираются. У нас эта проблема появилась лишь у части сотрудников и неодновременно. У остальных доступ по ssh пока продолжает работать.
Имеется недавно купленная стиральная+сушильная машина от LG в одном устройстве. Каким-то неизвестным образом у неё пропал звук интерфейса (включение, выключение, смена режима, музыка в конце стирки). Поиски в Google привели к нескольким способам, которые менялись от старых моделей к более новым. В моём случае помогло следующее видео: https://www.youtube.com/watch?v=KnMEGRegGs4 в котором показано, что после включения нужно одновременно нажать и удерживать несколько секунд кнопки Temp и Spin. Но до того, как я нашёл этот способ я пробовал нажимать и удерживать лишь кнопку Temp. При этом, под аккомпонемент какого-то пищания, на экране начинался обратный отсчёт, затем надпись End и полное выключение. Похоже на какую-то диагностику. Кто-то знает что это?
