Category: Open Source
How To Make $300/mo Selling Simple Websites
🔑 What you’ll learn:
The best platforms to build websites (Wix, WordPress, etc.)
How to find paying clients fast
Tips to scale your income by offering extra services
🚀 Start building and selling websites today and watch your side hustle grow!
Share your feedback about Moodle.org for a chance to win a US$75 gift card!
We are looking for volunteers to help us to improve the Moodle.org website homepage and navigation.
This survey has 9 to 11 questions and should take no more than 5 minutes to complete.
The survey is anonymous. However you will have the option to give your email address to go into a prize draw to win a US$75 gift card.
The Drop Times: Drupal Needs to Innovate: Neurodiversity Might be the Answer
A Casual Conversation with KOW (Karl Oscar Weber) on Camping, Open Source, and More
FRAME sockets added to OpenBSD
Thanks to
work
by David Gwynne (dlg@
),
OpenBSD -current now has a new
“AF_FRAME
”
socket domain:
CVSROOT: /cvs Module name: src Changes by: dlg@cvs.openbsd.org 2024/12/15 04:00:05 Modified files: sys/conf : files sys/kern : uipc_domain.c uipc_socket.c sys/net : if_ethersubr.c sys/sys : socket.h Added files: sys/net : af_frame.c frame.h Log message: add an AF_FRAME socket domain and an IFT_ETHER protocol family under it. this allows userland to use sockets to send and receive Ethernet frames. as per the upcoming frame.4 man page: frame protocol family sockets are designed as an alternative to bpf(4) for handling low data and packet rate communication protocols. Rather than filtering every frame entering the system before the network stack like bpf(4), the frame protocol family processing avoids this overhead by running after the built in protocol handlers in the kernel. For this reason, it is not possible to handle IPv4 or IPv6 packets with frame protocol sockets because the kernel network stack consumes them before the receive handling for frame sockets is run. if you've used udp sockets then these should feel much the same. my main motivation is to implement an lldp agent in userland, but without having to have bpf look at every packet when lldp happens every minute or two. the only feedback i had was positive, so i'm putting it in ok claudio@
There’s been a related change to
aggr(4)
.
Proposed contractual remedies in United States v. Google threaten vital role of independent browsers
Giving people the ability to shape the internet and their experiences on it is at the heart of Mozilla’s manifesto. This includes empowering people to choose how they search. On Nov. 20, the United States Department of Justice (DOJ) filed proposed remedies in the antitrust case against Google. The judgment outlines the behavioral and structural […]
The post Proposed contractual remedies in United States v. Google threaten vital role of independent browsers appeared first on The Mozilla Blog.
Simon Josefsson: Guix Container Images for GitLab CI/CD
I am using GitLab CI/CD pipelines for several upstream projects (libidn, libidn2, gsasl, inetutils, libtasn1, libntlm, …) and a long-time concern for these have been that there is too little testing on GNU Guix. Several attempts have been made, and earlier this year Ludo’ came really close to finish this. My earlier effort to idempotently rebuild Debian recently led me to think about re-bootstrapping Debian. Since Debian is a binary distribution, it re-use earlier binary packages when building new packages. The prospect of re-bootstrapping Debian in a reproducible way by rebuilding all of those packages going back to the beginning of time does not appeal to me. Instead, wouldn’t it be easier to build Debian trixie (or some future release of Debian) from Guix, by creating a small bootstrap sandbox that can start to build Debian packages, and then make sure that the particular Debian release can idempotently rebuild itself in a reproducible way? Then you will eventually end up with a reproducible and re-bootstrapped Debian, which pave the way for a trustworthy release of Trisquel. Fortunately, such an endeavour appears to offer many rabbit holes. Preparing Guix container images for use in GitLab pipelines is one that I jumped into in the last few days, and just came out of.
Let’s go directly to the point of this article: here is a GitLab pipeline job that runs in a native Guix container image that builds libksba
after installing the libgpg-error
dependency from Guix using the pre-built substitutes.
test-amd64-latest-wget-configure-make-libksba:
image: registry.gitlab.com/debdistutils/guix/container:latest
before_script:
- lndir /gnu/store/*profile/etc/ /etc
- rm -f /etc/group
- groupadd --system guixbuild
- for i in $(seq -w 1 10); do useradd -g guixbuild -G guixbuild -d /var/empty -s $(command -v nologin) -c "Guix build user $i" --system guixbuilder$i; done
- export HOME=/
- export LANG=C.UTF-8
- guix-daemon --disable-chroot --build-users-group=guixbuild &
- guix archive --authorize < /share/guix/ci.guix.gnu.org.pub
- guix archive --authorize < /share/guix/bordeaux.guix.gnu.org.pub
- guix describe
- guix package -i libgpg-error
- GUIX_PROFILE="//.guix-profile"
- . "$GUIX_PROFILE/etc/profile"
script:
- wget https://www.gnupg.org/ftp/gcrypt/libksba/libksba-1.6.7.tar.bz2
- tar xfa libksba-1.6.7.tar.bz2
- cd libksba-1.6.7
- ./configure
- make V=1
- make check VERBOSE=t V=1
You can put that in a .gitlab-ci.yml
and push it to GitLab and you will end up with a nice pipeline job output.
As you may imagine, there are several things that are sub-optimal in the before_script
above that ought to be taken care of by the Guix container image, and I hope to be able to remove as much of the ugliness as possible. However that doesn’t change that these images are useful now, and I wanted to announce this work to allow others to start testing them and possibly offer help. I have started to make use of these images in some projects, see for example the libntlm commit for that.
You are welcome to join me in the Guix container images for GitLab CI/CD project! Issues and merge requests are welcome – happy hacking folks!