926
-29
927
31

The worst kind of accidental complexity in software is the unnecessary distribution, replication, or restructuring of state, both in space and time.

928
10
submitted 8 months ago* (last edited 8 months ago) by elBoberido@programming.dev to c/programming@programming.dev

geteilt von: https://programming.dev/post/42846946

Hi everyone,

we, the iceoryx community, just released iceoryx2 v0.8, an ultra-low latency inter-process communication middleware in Rust, with C, C++, Python and with this release, C# bindings.

If you are into robotics, embedded real-time systems (especially safety-critical), autonomous vehicles or just want to hack around, iceoryx2 is built with you in mind.

Check out our release announcement for more details: https://ekxide.io/blog/iceoryx2-0.8-release

And the link to the project: https://github.com/eclipse-iceoryx/iceoryx2

929
34
930
40
Flocking Quadtrees (www.lbjgruppen.com)
931
2
932
10

Hello Programming.dev gang,

I'm still wrapping my head around classes, oop, and scoping, and was hoping to get some feedback. on a class definition.

Here's the background:

I'm implementing pydantic for handing my .env secrets and constants (Haven't gotten to a secrets manager yet), with pydantic_settings's BaseSettings and SettingsConfigDict, as well as pydantic's SecretStr.

I set up a parent class in settings.py to configure the .env file and settings, which you can see below.

settings.py Parent Class (click to expand)

from pydantic_settings import BaseSettings, SettingsConfigDict
from pydantic import SecretStr


class Settings(BaseSettings):
    model_config = SettingsConfigDict(
        env_file="/opt/pyprojects/media-scripts/.env.dev", extra="ignore"
    )

I've got a self hosted Baserow database that I'm using for my project, and I defined a class in baserow.py that inherits from the Settings class for the .env config, and has all of the fucntions for interacting with the database as methods of the class, which you can see below.

(I've got a number of other classes similar to Baserow planned that will inherit from the Settings class, provided I'm on the right track with this layout.)

I thought it was a good idea to put the methods in the class with the .env var attributes to keep scoping focused and local. I'm wondering if this is a good idea or not, and am also open to any other feedback on the code/classes anyone might have. Thank you to anyone taking the time to read and/or respond.

baserow.py with Baserow child class (click to expand)

import json

import requests
from pydantic import SecretStr

from mods.settings import Settings


class Baserow(Settings):
    br_url: str
    br_api: SecretStr

    def query_db(self, urlFilters):
        url = f"{self.br_url}?user_field_names=true&{urlFilters}"
        headers = {"Authorization": f"Token {self.br_api}"}

        brQueryResults = requests.get(url, headers=headers)

        return brQueryResults.json()

    def get_all_shows(self):
        url = f"{self.br_url}?user_field_names=true&size=200"
        headers = {"Authorization": f"Token {self.br_api.get_secret_value()}"}

        brQueryResults = requests.get(url, headers=headers)

        return brQueryResults.json()

    def post_db(self, showDictionary):
        brPostResults = requests.post(
            f"{self.br_url}?user_field_names=true",
            headers={
                "Authorization": f"Token {self.br_api.get_secret_value()}",
                "Content-Type": "application/json",
            },
            json=showDictionary,
        )

        print(json.dumps(brPostResults.json(), indent=2))

    def patch_db(self, showDictionary, row):
        brPatchResults = requests.patch(
            f"{self.br_url}?user_field_names=true",
            headers={
                "Authorization": f"Token {self.br_api.get_secret_value()}",
                "Content-Type": "application/json",
            },
            json=showDictionary,
        )

        print(brPatchResults)

    def delete_db_row(self, row):
        brDeleteResults = requests.delete(
            f"{self.br_url}{row}/",
            headers={
                "Authorization": f"Token {self.br_api.get_secret_value()}",
            },
        )
        print(brDeleteResults)

933
138
934
24

For a few months I've spent my free time working on a C++ messenger. It started off pretty simple, just two input boxes for IP address and port number, more of a fun experiment. From there it started to grow and soon allowed for peers to connect automatically using a relay. For a while it only allowed two people to speak at once, which was good for security but was very inconvenient. Now Retro Messenger allows multiple users to speak at once, sending encrypted files and messages that exist only in memory.

Although there is plenty of things I could improve, I was curious to see if anyone had suggestions or requests for what else could be added. I'm currently debugging a local-logs feature, and I could look into how to implement voice calls in the future. Thanks for your time and feel free to ask questions

Landing page: https://retromessenger.space/

935
-14
936
-30
937
10
938
17
939
-9
940
-11
941
193
942
132

TL;DR: The big tech AI company LLMs have gobbled up all of our data, but the damage they have done to open source and free culture communities are particularly insidious. By taking advantage of those who share freely, they destroy the bargain that made free software spread like wildfire.

943
30

I'm looking for free resources to learn backend development. I prefer video-based content with a complete, step-by-step learning path. I want lots of hands-on practice, exercises, and real projects to work on.

944
74

Following publication of our original article, GitHub reversed its decision. The Microsoft-owned developer site has taken to X to admit it might have made a mistake by unilaterally announcing plans to charge people for using their own hardware to host runners.

“We’ve read your posts and heard your feedback,” GitHub said. “We’re postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach.”

The company said that it still intends to do something to help offset the “real costs” in running GitHub Actions via self-hosted runners, but “we missed the mark with this change by not including more of you in our planning.”

945
9
946
63
submitted 8 months ago* (last edited 8 months ago) by HaraldvonBlauzahn@feddit.org to c/programming@programming.dev

Here, my summary of key features and decisions of Guix:

  1. Guix is a package manager that can (optionally) run on top of Linux distributions or other POSIX systems, like cargo, pip, conda or Conan. In difference to the pip and cargo package managers, it is language-agnostic, supports many different build systems and languages, and features around 29000 packages now.
  2. Guix allows to define a fully reproducible system. This works by using a declarative language for immutable version-controlled package descriptions, and by deriving any software from package definitions and a fixed version (commit hash) of the source code. In that, it is similar but much stricter than Nix and NixOS. The key point is that any software built, and all its dependencies, go back to unambigously, immutable versions of source code and build recipes - and all inputs to the system are open source and can be reviewed.
  3. Important for programming, this can also define isolated build and development environments, like Python's venv, but also Docker containers. This means that Guix can be used to develop, build, package, and deploy software, very much like Snap packages. And that's independent from the distribution you work in, very much like pip or cargo are independent from the system you work in. (And yes, it supports Rust!).
  4. This allows it, and also makes it technically possible, that any software package can be re-built and run years later. To make this legally possible, the official distribution of Guix also demands all components to be open source (FOSS). This is also a key difference to NixOS and non-free forks of Guix, which allow non-free binary packages, but sacrifice reproducibility. (To illustrate: If you have a binary, proprietary scanner driver in NixOS, and the owning company practices planned obselescence and decides that you should buy their new hardware, and pulls that driver, you are out of luck. In Guix, this can't happen.) (Note that as your own private conponents, you can define any package you like, you can also distribute your definitions as a complement to GNU Guix. Non-free packages for Guix do exist, in the same way as you can buy and run Steam Games software for Linux. Such non-free software just can't become part of the official Guix distribution, just like Amazon or Apple can't sell their non-free software via Debian or the Linux kernel project (or, for that matter, Apple has no obligation to market and distribute, say, Oracle products).
  5. All inputs being open source also means that any software component can be reviewed, that mis-features such as privacy-invasive behaviour can be removed, and that it is hardly possible to hide malware in the system. Because this also applies recursively to all compilers and build tools, this solves also Thompson's "Trusting Trust" problem. In fact, the whole system can be build from a 512 byte binary root (called MER). (Interestingly, that level of user control gets a lot of hate online -- certain companies don't seem to like it).
  6. Because it would take too long to build every user package from source every time, the produced packages are normally cached (while their correct binary content can be easily verified).
  7. The declarative description language for the packages is a well-defined, established, minimalist language called Scheme. This is a member of the Lisp family of languages. That Lisp is very well suited for declaratively building and configuring large systems has been proven with GNU Emacs, whose software, but more importantly, whole user configuration, is written in Emacs Lisp.
  8. The Scheme implementation used is called Guile. It has especially good support for the POSIX environment and has also much better-than-average interactive debugging capabilities compared to other Scheme implementations.
  9. Also worth noting is that the Guix project has superb online documentation. This is a practical advantage compared to Nix.

As example: you are on Debian stable and quickly want to try a recent version of the kakoune editor (as kakoune is in ongoing development): They are available under the Guix package manager. Just

guix install kakoune

and bang you have it!

How it works:

https://codeberg.org/guix/guix#headline-4

Manual:

https://guix.gnu.org/manual/en/html_node/Installation.html

Also informative for using Guix just as a package manager:

https://wiki.archlinux.org/title/Guix

947
36
No graphics API (www.sebastianaaltonen.com)

Sebastian Aaltonen’s super in-depth analysis of all current graphics APIs, GPU history, and a proposal for a much simpler API that better fits today’s GPUs

948
38

Hello everyone,

I've just published the second post in my Linux Inside Out series.

In the first post we demystified the Linux kernel a bit: where it lives, how to boot it in a VM, and we even wrote a tiny init program.

In this second post we go one layer deeper and look at how programs actually talk to the kernel. We'll do a few small experiments to see:

  • how our init program (that we wrote in the first post) communicates with the kernel via system calls
  • how something like echo "hello" ends up printing text on your screen
  • how to trace system calls to understand what a program is doing

I’m mainly targeting developers and self-hosters who use Linux daily and are curious about the internals of a Linux-based operating system.

This is part 2 of a longer series, going layer by layer through a Linux system while trying to keep things practical and approachable.

Link (part 2): https://serversfor.dev/linux-inside-out/system-calls-how-programs-talk-to-the-linux-kernel/

Link (part 1): https://serversfor.dev/linux-inside-out/the-linux-kernel-is-just-a-program/

As always, any feedback is appreciated.

949
39
submitted 8 months ago* (last edited 8 months ago) by Kissaki@programming.dev to c/programming@programming.dev

On January 1, 2026, GitHub will reduce the price of GitHub-hosted runners by up to 39% depending on the machine type used. The free usage minute quotas will remain the same.

On March 1, 2026, GitHub will introduce a new $0.002 per minute GitHub Actions cloud platform charge that will apply to self-hosted runner usage. Any usage subject to this charge will count toward the minutes included in your plan, as explained in our GitHub Actions billing documentation.

Runner usage in public repositories will remain free. There will be no changes in price structure for GitHub Enterprise Server customers.

We are increasing our investment into our self-hosted experience to ensure that we can provide autoscaling for scenarios beyond just Linux containers.

Historically, self-hosted runner customers were able to leverage much of GitHub Actions’ infrastructure and services at no cost.

950
5

Recommend me any good finance related projects that may try to solve an actual problem being faced in the industry now.

view more: ‹ prev next ›

Programming

28304 readers
591 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS