We will switch authentication from OpenID to OIDC (OpenID Connect). There will be a short outage to do this.
We will switch authentication from OpenID to OIDC (OpenID Connect). There will be a short outage to do this.
admin )
on 2024-12-06 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 2 – 6 December 2024
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.
The post Infra and RelEng Update – Week 49 2024 appeared first on Fedora Community Blog.
admin )
on 2024-12-06 08:00:00 UTC
The IDM/IPA team is working on testing the new IPA (Identity Policy Audit) migrate feature and functionality. As a result, the Identity Management and QA teams have organized a test day on Monday, December 09, 2024. The wiki page in this article contains links to the test images you’ll need to participate. Please continue reading for details.
A testday is an event where anyone can help ensure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.
To contribute, you only need to be able to do the following things:
The wiki page has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test week web application. If you’re available on or around the day of the event, please do some testing and report your results.
Happy testing, and we hope to see you on the test day.
remi )
on 2024-12-06 06:52:00 UTC
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for a parallel installation, the perfect solution for such tests, and also as base packages.
RPMs of PHP version 8.4.2RC1 are available
RPMs of PHP version 8.3.15RC1 are available
RPMs of PHP version 8.2.27RC1 are available
The packages are available for x86_64 and aarch64.
PHP version 8.1 is now in security mode only, so no more RC will be released.
Installation: follow the wizard instructions.
Announcements:
Parallel installation of version 8.4 as Software Collection:
yum --enablerepo=remi-test install php84
Parallel installation of version 8.3 as Software Collection:
yum --enablerepo=remi-test install php83
Parallel installation of version 8.2 as Software Collection:
yum --enablerepo=remi-test install php82
Update of system version 8.4:
dnf module switch-to php:remi-8.4 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.3:
dnf module switch-to php:remi-8.3 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.2:
dnf module switch-to php:remi-8.2 dnf --enablerepo=remi-modular-test update php\*
Notice:
Software Collections (php82, php83, php84)
Base packages (php)
Recently I was asked why the syslog-ng newsletter looks odd. At first I did not even understand what is the problem. Then I realized that I kept using the same format for the past 14 years, that was optimized for UNIX terminals :-)
So, what is the problem? 14 years ago I was kindly asked by syslog-ng users to use plain text e-mails instead of HTML formatting. Of course it also means that there is no easy way to emphasize titles in the newsletter. For that I started to use a long list of hyphens under the titles, equal length to the title. It all looks perfect in a terminal window, which has fixed width fonts. It definitely looks odd in a GUI e-mail client, which does not use fixed width fonts. Something like this:
---------------------------
The lenght of the line and the title are different. Luckily the mailing list archive also uses a fixed width font when showing e-mails. So, if you take a look at the last syslog-ng newsletter, you will see that it looks completely OK: https://lists.balabit.hu/pipermail/syslog-ng/2024-December/026735.html
So, what is next? My suspicion is that over the past decade even the most diehard terminal users started to use graphical e-mail clients (most likely a web browser). Starting next year I’ll switch to HTML formatting, hoping that nobody will complain :-)
czanik )
on 2024-12-05 10:07:40 UTC
The December syslog-ng newsletter is now on-line:
FreeBSD audit source for syslog-ng
Version 4.8.1 of syslog-ng is now available
Where should I present syslog-ng and sudo?
It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2024-12-freebsd-audit-4-8-1-conferences
yselkowitz )
on 2024-12-05 00:00:00 UTC
There are less than six weeks until the Fedora 42 mass rebuild. While mass rebuilds inevitably result in some breakage, the following issues appear likely to be common causes of FTBFS:
While not yet announced as a change for Fedora 42, each winter mass rebuild is immediately preceded by a new major (prerelease) version of GCC. (I might still be recovering from GCC 14 which coincided with the branching of RHEL 10.) Each major GCC version ends up introducing some strictness which results in compile errors in existing (particularly older) code. Hopefully we’ll be hearing more from the Tools team about what to expect this time, but in the interim there is a WIP list of major changes.
Newly introduced in rawhide just yesterday, this is the first major release in more than six years. The upstream release announcement does not indicate any major incompatibilities, but I have already seen one failure in a package which tried to make now-outdated assumption automake version numbers, and there are likely to be more such changes needed.
So far, the major incompatible change here is that the long-deprecated setup.py test is no longer supported, which will break dozens of packages.
The Python SIG has already filed bugs for at least some of these. If you haven’t already,
now is the time to fix your Python packages by calling the tests directly.
Unfortunately, the latest cmake has caused some issues in Qt/KDE land by breaking builds involving QML.
Also, there was a regression with the %ctest macro and the double-hyphen separator before short arguments (e.g. %ctest -- -E foo) but that should now be fixed.
This may not affect that many packages, but the introduction of struct sched_attr and userspace functions for the sched_getattr and sched_setattr syscalls
(upstream commit) has caused conflicts with code which had been
providing their own such wrappers. The “proper” way to handle this is to guard these based on configuration tests, but for those that do not do so,
!__GLIBC_PREREQ(2,41) will only help once 2.41 is released. In the meantime, workarounds may be necessary
(e.g. here and here).
There will likely be more FTBFS themes to emerge in the coming weeks, but it’s not too early to fix your packages for any of the above, and to check for any other issues rebuilding your package in rawhide, particularly if you haven’t rebuilt in a while.
The decision to move to Forgejo as the new git forge has reached a new stage. Fedora Linux’s leadership has decided to choose Forgejo as their preferred git forge replacement. There are numerous factors involved in this decision and this article will discuss them, present some background on the process, and invite one more chance for feedback before the formal Fedora Council vote.
We’ve known for a long time that the Fedora Project needs a new git forge solution. The software we currently use, Pagure, has served us well. Sadly, it never took off in the wider world. So we had to maintain the Pagure git forge ourselves and use it to build the Fedora Linux releases at the same time. A few years ago, we considered GitLab, and had a lot of discussion… which ultimately didn’t go anywhere. Out of that we got a clear message. It’s important that this crucial part of our infrastructure be free and open source software.
At the Fedora Council’s annual face-to-face meeting in February we discussed a large list of options. By the end of the day, we crossed off all but two: GitLab Community Edition and Forgejo. We also determined that no hosting providers can meet our unique needs; we’ll have to self-host. We then asked the Advanced Reconnaissance Crew (ARC, a subteam of Fedora Infrastructure) to investigate these in more detail. They were particularly asked to look at 1) any show-stopper missing features and 2) maintenance effort and cost.
ARC has presented their initial results (about which Akashdeep goes into detail below). The quick summary: either option could work, and both have some gaps we’ll need to fill. Several things tilt the scales one direction. GitLab CE is “open core”, with some features only in the non-open-source “premium” version (including some we really want). This is both an immediate practical concern and a long-term one. Open core software tends, over time, to get less open (no matter how good the initial intentions). In addition, the Infrastructure team is more comfortable with the Forgejo codebase and the language it is written in.
So, what’s next? The Council, currently, has a clear preference for Forgejo. This is a big decision and we don’t want it to feel rushed. Therefore, we’re opening this up one last time to everyone’s comments. We have created a discussion thread referencing this article to submit your feedback to. You can find it using the #git-forge-future tag. After two weeks, we’ll take our formal vote — and then get on with the work!
– Matthew
The earliest attempts to move over to an alternative git forge solution started as early as January 2020. At that time the development work on Pagure became increasingly inconsistent. This resulted in the maintenance costs soaring due to the unmaintained state of the development. Shortly after that, in March 2020, the decision was made to move over to GitLab after evaluating over 300 user stories and a SaaS offering was planned for the Fedora Project. While the development of new features for Pagure slowed down, an exemplary group of contributors stepped up to ensure that the current state of Pagure was maintained well. After a detailed AMA session with folks from GitLab in September 2020, a SaaS offering was announced for Fedora Project in October 2021, and a bunch of sub-projects and SIGs started moving their workflows over to the Fedora Project namespace of GitLab.
While the case looked mostly positive for the sub-projects and SIGs like Fedora Websites and Apps team, there were concerns regarding the scalability in terms of contributor counts and suitability in terms of the Dist Git purposes. This was specifically brought up in the Fedora Council issue ticket discussion and realized at a much later stage in function which led to the initiative request of Dist Git to GitLab from Fedora Infrastructure in February 2023. Fedora Infrastructure worked on an application that helps migrate repositories from Pagure to GitLab through November 2023. By December 2023, the evaluation of Git Forges had become a priority for Fedora Council and a concurrent investigation that explored migrating Dist Git functionality in a forge-agnostic way to another git forge was completed by March 2024.
After the Git Forge alternatives were shortlisted during the Fedora Council F2F Hackfest in February 2024, the Community Linux Engineering (CLE) team (previously called the Community Platform Engineering (CPE) team) were tasked with the investigation. The Advanced Reconnaissance Crew (ARC) sub-team was to report the positives and negatives of each git forge option, while working with various stakeholders across the Fedora Project community to capture the projects requirements for our dist-git. The initiative was led by Tomas Hrcka and Akashdeep Dhar, and Akashdeep also represented the Fedora Councils needs to the team. They began collecting these requirements in the form of user stories in March 2024 to use as the baseline of the investigation. The initiative was then joined by David Kirwan and Ryan Lerch who were able to deploy an instance of both Forgejo and GitLab CE in the CommuniShift app, and the team began validating that each user story worked in each git forge instance. These findings were reported in the official documentation.
The availability of these instances really helped onboard more contributors into the user stories validation efforts. This meant that the focus was not only on the packagers and release engineering workflow but also covered those associated with subprojects/SIGs like Design, Documentation, Accessibility, Websites & Apps, Mindshare etc.
Throughout the investigation, conversations on Fedora Discussion and on the Fedora Project mailing list were happening, making sure Fedoras use cases were being addressed, and the ARC team had presentations during the Fedora Linux 40 Release Party as well as Tomas Hrcka’s talk during the Flock To Fedora 2024 to give this huge change maximum exposure.
Once the investigation completed, Fedora Council was slated to make the final decision on which forge the project would choose to migrate to.
Like any other initiative, or large project or piece of work, the plan is never perfect, and this particular effort was quite literally years in the making. The next step for all the parties involved is to have some retrospectives to reflect on how this all went. There are plenty of learnings to be had for sure, and we hope to have a better understanding of how to drive such major decisions in a much better way.
With the investigation on the git forge solutions now wrapped up, we plan to work with Community Linux Engineering (CLE) to direct the migration of Dist Git assets and the conversion of team workflows to the deployed Forgejo Server instance once the decision is formally (and finally!) announced in the coming weeks by Fedora Council.
Pagure Dist Git is connected with a variety of ecosystem services. These include, among others:
Please do not hesitate to reach out to the Fedora Infrastructure team to provide your support.
Utmost attempts will be made to ensure that the git forge replacement has feature parity with the systems it is attempting to replace (i.e. Pagure Dist Git and Bugzilla). However, it is important to understand that this is a complex undertaking. Most workflows related to various subteams, subprojects and SIGs are likely to remain the same. In some cases we might have to re-imagine the workflows to fit the change (best case scenario). In other cases it may be necessary to deprecate workflows that are no longer reasonably supportable (worst case scenario).
Folks are requested to have an understanding of the user stories that were taken into consideration while comparing the git forge alternatives. Please collaborate with the Fedora Infrastructure team to integrate your specific workflows into the Dist Git Replacement platform.
We look forward to bringing this change to Fedora collaboratively with you in 2025!
bcotton )
on 2024-12-04 13:00:00 UTC
Making decisions in an open source community is hard. Most communities have some sort of consensus model where major decisions require broad support. There’s not just one Big Boss who can come in and unilaterally decide. But sometimes decisions become bogged down in an attempt to get unanimous support or achieve the One Best Decision
. If you’re the person who is supposed to make the decision, make the damn decision.
Consensus is important. People want to feel like their input matters, especially when they’re contributing on a volunteer basis. If participating in your project stops being fun, people will leave. It’s hard to make sustainable progress if you can’t get the majority to go along with you.
But we sometimes overcorrect toward consensus. In those cases, the decision drags on. If a decision is ever made, it no longer has momentum. It might be the most correct decision, but it loses impact because it sits in a state of limbo for months.
In most cases, a good decision made quickly is better than a great decision made slowly. You can iterate on decisions, and that works better with short cycles. The smaller the decision — or the easier it is to reverse — the less time you need to spend building consensus. This is not to say that you should go around making a bunch of decisions on your own. That’s chaos.
Instead, you should have a defined process for how decisions are made: who can gives input, who is empowered to make the decision, and what the time frame looks like. Set a deadline and then make the best decision you can. The process doesn’t have to be complicated — it’s better if the process is simple — it just needs to not catch the community by surprise. Chapter 4 of Program Management for Open Source Projects lays out a framework for building your decision process.
This post’s featured photo by krakenimages on Unsplash
The post The best way to make a decision is to decide appeared first on Duck Alignment Academy.
We're updating Copr servers to F41
This outage impacts the copr-frontend and the copr-backend.
Basedpyright is a fork of pyright with various type checking improvements, improved vscode support and pylance features built into the language server. It has a list of benefits over Pyright.
In case you want to use that inside of neovim using
Mason, you will have to remember
to have the configuration inside of a settings key. The following is from my
setup.
basedpyright = {
settings = {
basedpyright = {
analysis = {
diagnosticMode = 'openFilesOnly',
typeCheckingMode = 'basic',
capabilities = capabilities,
useLibraryCodeForTypes = true,
diagnosticSeverityOverrides = {
autoSearchPaths = true,
enableTypeIgnoreComments = false,
reportGeneralTypeIssues = 'none',
reportArgumentType = 'none',
reportUnknownMemberType = 'none',
reportAssignmentType = 'none',
},
},
},
},
},
Struggled for a few hours to fix this couple of days ago.
fun fact: in #Fedora dependent packages can be checked by running:
fedrq wr -F "name" -s "package name"
If you are looking for #examples of the aforementioned #macros I suggest looking through the latest #rpm *.spec files that can be found here: 'https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz'
#Fedora packager, here's a fun fact: If you're #packaging software with custom patches in its git repo, Fedora RPM has built-in macros for #git
macros like '%autosetup' and '%autopatch' use these git macros under the hood.
https://github.com/rpm-software-management/rpm/blob/master/macros.in#L1246
A few weeks ago Bahnhof organized an evening to celebrate
technology/innovation/freedom, and opened Bahnhof Bar only for the evening.
Back in 2005 their office was raided and servers were taken, and the latest TV
series, The Pirate Bay on SVT Play already showed that as part of the
series.
The evening went too fast, met a lot of new people and a few old friends too. I love Bahnhof's service as Internet provider, but also love how they fight for privacy and freedom.
You can read their blog post about the event too.
admin )
on 2024-12-02 08:00:00 UTC
This article introduces projects available in Flathub with installation instructions.
Flathub is the place to get and distribute apps for all of Linux. It is powered by Flatpak, allowing Flathub apps to run on almost any Linux distribution.
Please read “Getting started with Flatpak“. In order to enable flathub as your flatpak provider, use the instructions on the flatpak site.
These apps are classified into four categories:
In the Productivity section we have Ghostwriter. Ghostwriter is a distraction-free text editor for Markdown featuring a live HTML preview as you type, theme creation, focus mode, fullscreen mode, live word count, and document navigation. All of this appears in an aesthetic writing environment. It comes with the cmark-gfm Markdown processor built in, and can integrate with Pandoc, MultiMarkdown, Discount, and cmark processors, if they are installed. I personally use it when I’m offline before moving it to my markdown online application and the syntax works perfectly.
You can install “Ghostwriter” by clicking the install button on the web site or manually using this command:
flatpak install flathub org.kde.ghostwriter
Ghostwriter is also available as an rpm in the Fedora Linux repositories
In the Games section we have Hedgewars. Hedgewars is a turn-based strategy, artillery, action and comedy game. It features the antics of pink hedgehogs with attitude as they battle from the depths of hell to the depths of space. As commander, it’s your job to assemble your crack team of hedgehog soldiers and bring the war to your enemy.
Game features:
You can install “Hedgewars” by clicking the install button on the web site or manually using this command:
flatpak install flathub org.hedgewars.Hedgewars
Hedgewars is also available as an rpm in the Fedora Linux repositories
In the Miscellaneous section we have Podcasts. Play, update, and manage your podcasts from a lightweight interface that seamlessly integrates with GNOME. Podcasts can play various audio formats and it remembers where you stopped listening. You can subscribe to shows via RSS/Atom, iTunes, and Soundcloud links. Subscriptions from other apps can be imported via OPML files.
You can install “Podcasts” by clicking the install button on the web site or manually using this command:
flatpak install flathub org.gnome.Podcasts
In the Creativity section we have FamiStudio. FamiStudio is a simple music editor for the Nintendo Entertainment System or Famicom. It is targeted at both chiptune artists and NES homebrewers. I’ve been playing around with 8-bit art, and the start was with music. FamiStudio is a complete suit so you don’t need to move between a MIDI editor and then and instrument/music sheet program; you have everything in here. I love the tutorial and how everything is very well explained. Some of its features are:
You can install “FamiStudio” by clicking the install button on the web site or manually using this command:
flatpak install flathub org.famistudio.FamiStudio
Even in the cloud, it is sometimes convenient to monitor systemd logs via the
serial console (or even log into the machine) when services like sshd
fail or disks fail to mount. With EC2, you can use SSH for this purpose.
Either go to the console (web-ui) and get the instance ID there, or just ssh to the machine and query the Metadata Service:
$ ssh <user>@<host>
$ TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id ; echo
i-015xxxxxxxxxxxxxx
$ exit
On your machine, setup a few environment variables:
$ instance_id=i-015xxxxxxxxxxxxxx
$ pubkey=/home/praiskup/.ssh/id_rsa.pub
$ region=us-east-1
Tell EC2 what SSH key you want to use first, and then ssh to the console:
$ aws ec2-instance-connect send-serial-console-ssh-public-key \
--instance-id "$instance_id" \
--serial-port 0 \
--ssh-public-key file://"$pubkey" \
--region "$region"
-----------------------------------------------------
| SendSerialConsoleSSHPublicKey |
+----------------------------------------+----------+
| RequestId | Success |
+----------------------------------------+----------+
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | True |
+----------------------------------------+----------+
$ ssh "$instance_id".port0@serial-console.ec2-instance-connect."$region".aws
copr-fe-dev login:
Use the neat SSH control keys, start with ~?, quit the session with ~.:
copr-fe-dev login: ~?
Supported escape sequences:
~. - terminate connection (and any multiplexed sessions)
~B - send a BREAK to the remote system
~R - request rekey
~V/v - decrease/increase verbosity (LogLevel)
~^Z - suspend ssh
~# - list forwarded connections
~& - background ssh (when waiting for connections to terminate)
~? - this message
~~ - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)
Watch the systemd logs over SSH:
[root@copr-fe-dev ~][STG]# reboot
Stopping session-160.scope - Session 160 of User root...
Stopping session-49.scope - Session 49 of User root...
[ OK ] Removed slice system-modprobe.slice - Slice /system/modprobe.
[ OK ] Removed slice system-sshd\x2dkeygen.slice - Slice /system/sshd-keygen.
[ OK ] Removed slice system-systemd\x2dzr…- Slice /system/systemd-zram-setup.
...
Currently there’s a problem with Grub in EC2, but in general you would be doing something like:
$ cp /boot/grub2/grub.cfg /var/tmp/ # backup
$ grub2-editenv - unset menu_auto_hide # https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
$ vim /etc/default/grub # change the $GRUB_TIMEOUT
$ grub2-mkconfig > /boot/grub2/grub.cfg # re-generate
$ vim -d /boot/grub2/grub.cfg /var/tmp/grub.cfg # review!
You might notice a problem that I did, systemd disallows reboot over EC2
console, not reported for now. The EC2 console has no “send
ctrl+alt+delete” button, nor an on-screen keyboard. You can’t send
ctrl+alt+delte over the SSH-console. SysRq is disabled of course (by
default). Could we have something like ctrl+R for rebooting? Not sure.
It’s been a long time since I’ve tried to do this, but now that I’m working regularly in more publicly visible open source packaging again, it seems appropriate to have a place where I can write about it. Of course, a lot has changed since then, and I don’t really worry about hosting, so here we are. Let’s see how this goes…
admin )
on 2024-11-29 10:00:00 UTC
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 25 – 29 November 2024
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues
Minor update of Bodhi from 8.2.0 to 8.3.0 on 2024-11-25: https://github.com/fedora-infra/bodhi/releases/tag/8.3.0
If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.
The post Infra and RelEng Update – Week 48 2024 appeared first on Fedora Community Blog.
admin )
on 2024-11-29 08:00:00 UTC
The kernel team is working on final integration for Linux kernel 6.12. This version was just recently released, and will arrive soon in Fedora Linux. As a result, the Fedora Linux kernel and QA teams have organized a test week from Sunday, December 01, 2024 to Sunday, December 08, 2024. The wiki page in this article contains links to the test images you’ll need to participate. Please continue reading for details.
A test week is an event where anyone can help ensure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.
To contribute, you only need to be able to do the following things:
The wiki page for the kernel test week has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test week web application. If you’re available on or around the days of the event, please do some testing and report your results. We have a document which provides all the necessary steps.
Happy testing, and we hope to see you on one of the test days.
2 Weeks ago I was down with fever, but as I became better after a few days I managed to attend Amnesty International's Stockholm chapter's event on activism. I had to travel to a different part of Stockholm, which was fun.
The day started with welcome talk and then a new "Palestine Activist Group" presented their work (in both English and Swedish). Then the main opening talk (in Swedish) from a very senior Swedish journalist about history and important dates related to Palestine. I managed to understand 50-60% of the words. Still a lot of learn.
During the break I had longer chats about privacy, data and our lives. It was good to find folks who knows/uses Python/Fedora/Debian/Ubuntu and other Open Source tools in their daily lives, sometimes even without knowing.
After the morning break, I attended a workshop about being an activist. It was filled with discussions, and of course a lot of new words in Swedish for me. But, the delivery of the workshop was good, people talked about what they think about being an individual activist and things to consider etc.
Next day I had a workshop for a selected group, about boycotting large services and how to providing least amount data to preserve our privacy. The group consisted people from various parts of Swedish society, people working in other government agencies and large multinational companies.
We talked about metadata and phones provide both metadata and real data to the various services via apps. Explaining people to imagine that every time they get out of home, there are many humans walking with them to every destination, keeping notes of every place visit, and every chats they are having with another person or about groups, and then later selling that information to other businesses. It is one thing to talk about these, but it is complete opposite to show. So, I showed them live how much our phones/computers talk. I had my old Pixel4a configured with GrapheneOS, and one of the participant connected their regular Pixel phone to the same VPN. And people seemed to be offended by seeing the amount of data flowing, even when the phone is not use. The below is a screenshot I took today morning from the same demo setup.
We also talked about various chatting platforms, I already built another system to teach kids about how various social chatting platforms work. It was a perfect tool for this demo. We discussed about various other technologies in our daily lives and how they affect privacy.
czanik )
on 2024-11-28 08:37:03 UTC
Last week I introduced you to my latest project: a syslog-ng container based on Alma Linux. This week I added a syslog-ng Prometheus exporter to the container, so you can also monitor syslog-ng, if you enable it.
bcotton )
on 2024-11-27 13:00:00 UTC
A little over a year ago, a colleague suggested I read the book Innovation Happens Elsewhere: Open Source as Business Strategy by Ron Goldman & Richard P. Gabriel. It’s nearly two decades old, but it’s a good look at how open source and business were interacting in the “early” days. The authors made the book open-access on their website, but I wanted to put it on my e-reader for airplane reading. Thankfully, it’s under CC BY-NC-SA 2.0, so I could do something about that.
After working on conversion off-and-on, I’ve finally made it available in PDF and epub formats. The source is available in a GitHub repo if you find any errors. Note that I am explicitly not looking to update it. That’s too large of a project. (Plus, if you want an up-to-date book about the intersection of open source and business, you can read VM Brasseur’s Business Success With Open Source.) I will gladly accept fixes to formatting, broken links, and so on.
This post’s featured photo by Aaron Burden on Unsplash.
The post Innovation Happens Elsewhere: now in a portable form appeared first on Duck Alignment Academy.
ankursinha )
on 2024-11-25 14:49:25 UTC
I needed to use the UCL VPN again, on my Fedora/Linux machine. Linux isn't really supported by the university infrastructure, but there are instructions that others have come up with and they had worked for me the last time I'd needed VPN access. Unfortunately, that was a few years ago, and things have changed a little since then. Notably, UCL has introduced two factor authentication (2FA).
I had to look around a little but I did manage to get it to work again using NetworkManager. I thought I'd write it up quickly so everyone that needs it, including future me, have a quick reference to look at.
This is on Fedora 41 with the following OpenConnect packages:
$ rpm -qa \*openconnect\* openconnect-9.12-6.fc41.x86_64 NetworkManager-openconnect-1.2.10-6.fc41.x86_64 NetworkManager-openconnect-gnome-1.2.10-6.fc41.x86_64
In NetworkManager one needs to create a new VPN connection with the following settings:
Here are the settings in a list too:
/usr/libexec/openconnect/csd-post.shThis is similar to what had worked before. What changed:
This opens up a web login page where one can enter their credentials.