technom

You seem to be pretty invested in Gnome. But your slander against System76 and COSMIC desktop has no merit. Cosmic is still a work in progress and some friction is expected. But there is no problem in their methodology. They are also doing something that's very much a norm in the FOSS world - create something new and share it, if they don't like what's around. And so far they're receiving good reviews despite how immature the software is.

Gnome on the other hand has burnt its users so many times that this isn't even the first desktop to be born out of disagreements with them. And this is also not the first time they have slandered their competition. They absolutely don't respect anyone but themselves.

Why not Fortran 90 or Fortran 2023?

It's not really that baffling. What was done to the Jews by the Nazis is utterly indefensible. And some of the attitude that led to it still persists in society. The Zionists used that to guilt trip the world into banning public criticisms against Jews and Israel - legitimate or otherwise. They use it to silence even the ultraconservative Jewish sects and actual Holocaust survivors who speak up against the transgressions within their community. This was particularly effective in Germany as they were coming to terms with what they had done.

This is why we should never encourage victimhood narratives by anyone. They're very often trying to emulate the atrocities they describe. Hate speech should be condemned and called out - but uniformly without discrimination.

What sort of crappy website is this? It says that this site is not accessible from my location. Even sites about open source are gatekeeping now?

I wanted to give a proper reply to the technical part of the question, but I find the rant part too long, off putting and condescending. So I'm not going to tell you that GDB implements the Debug Adapter Protocol (DAP), and therefore can be used with any GUI DAP client like VSCodium.

I find it infuriating that they didn't design CI to run locally first and then offer a hosted version of it. These tools are not the perfect alternatives for the real thing.

At this point, it may be a good idea to throw the entire git porcelain (frontend) away and redesign it from scratch!

...although uv claims that it includes all pyenv functions and more.

It does. I have used both. UV is the first python development/packaging tool that seems to satisfy Python developers.

The reason I use VirtualBox is simply, that it is the recommendation in the developers guidelines of the project

That's a perfectly reasonable requirement. The problem here is that solution space is like the JavaScript ecosystem. There are more solutions than you can count and no two developers ever agree on everything. Everyone eventually settles down on one solution or the other based on their personal preferences. That's why I thought it was important to give you an overview rather than a definite solution.

I just want to add that VirtualBox is a backend to 'Vagrant'. Developers usually depend on Vagrant, rather than fiddle with VirtualBox directly. Vagrant takes care of some low-level VM configuration on its own and consistently recreates the VM every time with little fuss. You will need a configuration file for the VM (Vagrantfile), either readily available or newly written. I recommend Vagrant rather than direct vbox due to its convenience. However, I'm not pushing it further since I can't judge your options better than you.

I am pretty sure one can isolate some things using docker-compose, but it can be frustrating if you want to get into the project codebase and then have to do so much infrastructure stuff.

Certainly! That's what tools like vagrant are meant for. The only problem is that it replaces tediousness with choice fatigue!

I don't have a GUI in my container which I need of course to run my IDE and the software itself.

This is where the convenience of tools like VM, devpod, etc shines. However, you can also implement this solution manually with VMs or Docker. It's simple - bind mount the source directory on host into the VM/container. Then you can edit it using devtools and IDE from both the host and the VM. Tools like vagrant and devpod manages this for you.

However, the situation gets a bit tricky when you want to use GUI applications inside the VM/container. That involves mounting the X11/Wayland socket from the host into the VM/Container, doing the correct UID/GID mapping and setting the correct file permissions. Developers usually don't do this manually since it's tedious. However, some tools manage that too. I don't remember which one, off hand.

Thanks again for your friendly way of explaining things, much appreciated.

Glad I can help! Take your time - there are a lot of tools to explore, unless you're on a mission. Good luck!

Here's my 2¢. Debian is a reasonable OS to develop on, since it provides a super stable and reasonably secure base platform. I've used it quite extensively for the same purpose without any issues whatsoever.

However, it won't satisfy the needs of the modern style of development. For that, you need a reproducible development environment so that every developer gets the same results. (That means avoiding the 'it works for me' type of bugs). That means you need the same version of runtimes (python), same version of libraries/dependencies and same developer tools on every development system, irrespective of the distro it's running on.

The problem with Debian is that it often ships older versions of software to keep it stable. It will likely not match the version of python and tools you need. For that matter, no distributions including the frequently updated Arch Linux are likely to meet those requirements. (There are exceptions - NixOS and Guix.) So the widely adopted solution is to create a dev environment independent of your core system, from your regular non-root account. That means separately installing a python runtime that's different from your distro repo, etc. They don't touch your core system and keep it clean and pristine.

The way we achieve this is by using 4 tools:

Runtime version manager: Manages the version of runtimes.

Eg: python: pyenv, node: nvm, rust toolchains: rustup

Environment manager: Creates and maintains isolated environments where the correct runtimes, project dependencies and tools are available.

Eg: python: venv, node: node project, rust: rust project

Dependency manager: Resolves and installs the correct version of all project dependencies into the environment.

Eg: python: pip, node: npm, pnpm, rust: cargo add

Tool manager: Installs additional development tools for the project, like formatter, linter, etc.

Eg: python: pip, pipx, node: npx, rust: cargo install

Often, many of these are combined and you may get less than 4 different tools. The current situation is extremely complicated and there are many different tool combinations you can use. So let's address your specific requirements.

If your project uses only Python

In this case, the choice is pretty straightforward. Use uv.

The package management situation in the Python ecosystem was an absolute mess until UV appeared on the scene. UV combines all the 4 functions I mentioned above. It replaces venv, pyenv, pip and pipx in a single fast binary. You'll be surprised by its speed if you're used to the speed of pip. It's easy to use and very well integrated. It also integrates additional functionalities like:

Formatter (replaces black)
Project setup (helps with poetry, flit, hatch, etc)
Project publishing (replaces twine)

If you will use more than Python

If you will use tools or languages other than Python in a single project or in other future projects, you might want to use a 'language-agnostic runtime and tool manager'. They can manage runtimes and tools of multiple languages. Dependencies have to be managed using language package managers (like UV, pip, cargo, npm, etc).

The most well known tool manager is asdf. Others include aqua, vfox, etc. But the upcoming star is mise. I use mise for multiple projects including for Python projects. Mise uses UV behind the scenes for Python. So, mise projects play well with UV projects and with others who use UV.

The only disadvantage with multitool managers like asdf and mise is that they tend to be more complex compared to single language tools like UV. They obviously handle more and provide more features. However, investing time in tools like mise pays in the long run when you're handling multiple languages.

Servers like databases

The tools I mentioned above don't handle daemons like postgresql, redis, etc. This is why your colleagues recommend VMs. I will talk about VMs in a while. But I want to show you some simpler solutions here.

Another commenter has already mentioned the use of docker-compose files to set up such servers. It's the easiest solution possible.

Another more refined solution specifically for development containers is testcontainers. It's essentially the same as the docker compose solution, but with more dials and switches to help with automated tests like unit tests during CI. You'll have to learn a bit more than docker compose, to use it. However, those test servers are also readily available online and require little configuration.

Do you need virtualbox?

The methods explained above don't ruin your base Debian install. So a dedicated VM is not really required. However, I'm leaving this information here for completeness.

Use of VMs was widespread in the past. But they didn't run virtualbox, VMware or Qemu directly. Instead, a CLI frontend tool was used to set up those VMs for development. The most common tool was Hashicorp's Vagrant. Another tool available today is Lima. These tools mount your project directory into the VM, set up its network, install required tools, start required services (like DBs), attach a shell for you to work on, etc. These VMs are complete development environments and you don't need to do anything on the host system other than starting them up.

Since the advent of containers, the same idea has been implemented using containers instead of VMs. These are obviously less resource intensive than VMs. Most of them follow the devcontainers standard. So a devcontainer configuration works on multiple platforms, including GitHub's famous codespaces. Local tools for it include devpod, ona, devbox and devenv.

Conclusion

There are a lot more solutions. But these are the ones you're most likely to settle on. So I leave it at that. Please let me know if you have any questions about this reply. Hope you find your favorite setup soon.

... and adding docker-compose for running dev DBs/services ...

If you're into that sort of setup, you might appreciate testcontainers.

Solid state physics.

Is it legal? There may be alternatives with plausible deniability.

That makes me wonder! All these new GPU uses are enormous energy hogs. Is gaming like that too?

While I understand your point, there's a mistake that I see far too often in the industry. Using Relational DBs where the data model is better suited to other sorts of DBs. For example, JSON documents are better stored in document DBs like mongo. I realize that your use case doesn't involve querying json - in which it can be simply stored as text. Similar mistakes are made for time series data, key-value data and directory type data.

I'm not particularly angry at such (ab)uses of RDB. But you'll probably get better results with NoSQL DBs. Even in cases that involve multiple data models, you could combine multiple DB software to achieve the best results. Or even better, there are adaptors for RDBMS that make it behave like different types at the same time. For example, ferretdb makes it behave like mongodb, postgis for geographic db, etc.

Nobody ever learned from the solarwinds attack. If a massive amount of your infrastructure is backed by some obscure software, bad actors will either try to insert a backdoor or find a zero-day exploit. If people are going to neglect what just happened, crowdstrike will fall heals up, faster than solarwinds did.

I don't think that rust would have prevented this one, since this isn't a compile time error (for the code loader).The address dereferencing would have been inside an unsafe block. What was missing was a validity check of the CI build artifacts and payload check on the client side.

I do however, think that the 'fingers-crossed' approach to memory safety in C and C++ must stop. Rust is a great fit for this use case.

Crowdstrike exists for Linux too. In fact, it apparently crashed RHEL and Debian a few months back. That didn't get so much attention.

Falcon seems to be a cross between an antivirus and an intrusion detection system (IDS). There are many antiviruses on Linux, but only one FOSS AV is popular - ClamAV. As for IDS, snort is an example.

But in the true sense, Falcon is much more than just an AV and IDS. It's a way to detect breaches and report it back to CrowdStrike's threat detection and analysis teams. I don't think there exists a proper alternative even in the commercial sector.

TechNom (nobody)

@ technom @programming.dev

Posts

0
Comments

128
Joined

3 yr. ago

TechNom (nobody)

tough choice?

Reminder: System76 is not to be trusted

tough choice?

tough choice?

"The closer the collapse of the Empire, the crazier its laws" -Marcus Tullius Cicero

IceWM 4.0 Window Manager Brings Smarter Navigation and HiDPI Enhancements

Are there ANY debuggers for Linux, that has a GUI

Fixing CI

Fixing CI

Running Python on Debian - is not so easy?

Running Python on Debian - is not so easy?

Running Python on Debian - is not so easy?

If your project uses only Python

If you will use more than Python

Servers like databases

Do you need virtualbox?

Conclusion

Running Python on Debian - is not so easy?

Anyone here use assembly?

What else should I help seed?

Gravediggers [Forrest Brazeal]

JSON Query Language

imagine if the crowsstrike bug was malicious...

imagine if the crowsstrike bug was malicious...

Is there a use case for Crowd Strike Falcon on Linux?