Is it actually Bulgarian though?

Are you driving? Did you ever have the impulse to just jerk your steering wheel and crash into that tree rapidly approaching at 120mph?

https://en.m.wikipedia.org/wiki/Intrusive_thought

The comic plays off of that.

I don’t know what your previous setup was, but given that running resolved fixes your DNS issues, run:

ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

This will point programs that use /etc/resolved.conf during DNS resolution to the local DNS server provided by systemd-resolved.

Then, enable resolved so that it is started when you reboot:

systemctl enable systemd-resolved.service

Finally, start the service so that it is available immediately:

systemctl start systemd-resolved.service

You will want it run those with the required permissions, e. g. via sudo.

The parent comment is correct. CODE is the server, you need the “Collabora Online app” for document editing. I’m not aware if there are alternatives to the ownCloud / Nextcloud apps.

I did that on purpose, i. e. I wanted to confirm your thoughts about uv, drifted off into a general rant, remembered OP’s original question and later realized it would have been better framed as a top level comment. In my defense, I was in an altered state of mind at the time.

pyenv and uv let you install and switch between multiple Python versions.

As for uv, those come from the Python build standalone project, if I remember correctly, pyenv also installs from there, but don’t quote me on that.

I moved all our projects (and devs) from poetry to uv. Reasons were poetry’s non standard pyproject.toml syntax and speed, plus some weird quirks, e. g. if poetry asks for input and is not run with the verbose flag, devs often don’t notice and believe it is stuck (even though it’s in the default project README).

Personally, I update uv on my local machine as soon as a new release is available so I can track any breaking changes. Couple of months in, I can say there were some hiccups in the beginning, but currently, it’s smooth sailing, and the speed gain really affects productivity as well, mostly due to being able to not break away from a mental “flow” state while staring at updates, becoming suspicious something might be wrong. Don’t get me wrong, apart from the custom syntax (poetry partially predates the pyproject PEP), poetry worked great for us for years, but uv feels nicer.

Recently, “uv build” was introduced, which simplified things. I wish there was an command to update the lock file while also updating the dependency specs in the project file. I ran some command today and by accident discovered that custom dependency groups (apart from e. g. “dev”) have made it to uv, too.

“uv pip” does some things differently, in particular when resolving packages (it’s possible to switch to pip’s behavior now), but I do agree with the decisions, in particular the changes to prevent “dependency confusion” attacks.

As for the original question: Python really has a bit of a history of project management and build tools, I do feel however that the community and maintainers are finally getting somewhere.

cargo is a bit of an “unfair” comparison since its development happened much more aligned with Rust and its whole ecosystem and not as an afterthought by third party developers, but I agree: cargo is definitely a great benchmark how project and dependency management plus building should look like, along with rustup, it really makes the developer experience quite pleasant.

The need for virtual environments exists so that different projects can use different versions of dependencies and those dependencies can be installed in a project specific location vs a global, system location. Since Python is interpreted, these dependencies need to stick around for the lifetime of the program so they can be imported at runtime. poetry managed those in a separate folder in e. g. the user’s cache directory, whereas uv for example stores the virtual environment in the project folder, which I strongly prefer.

cargo will download the matching dependencies (along with doing some caching) and link the correct version to the project, so a conceptual virtual environment doesn’t need to exist for Rust. By default, rust links everything apart from the C runtime statically, so the dependencies are no longer neesed after the build - except you probably want to rebuild the project later, so there is some caching.

Finally, I’d also recommend to go and try setting up a project using astral’s uv. It handles sane pyproject.toml files, will create/initialize new projects from a template, manages virtual environments and has CLI to build e. g. wheels or source distribution (you will need to specify which build backend to use. I use hatchling), but thats just a decision you make and express as one line in the project file. Note: hatchling is the build backend, hatch is pypa’s project management, pretty much an alternative to poetry or uv.

uv will also install complete Python distributions (e. g. Python 3.12) if you need a different interpreter version for compatibility reasons

If you use workspaces in cargo, uv also does those.

uv init, uv add, uv lock --upgrade, uv sync, uv build and how uv handles tools you might want to install and run should really go a long way and probably provide an experience somewhat similar to cargo.

This, however, is about diagnostics, i. e. annotating delete with a reason (message) to express developer intent when deleting a function, not about memory management.

Side note: please don’t abuse the word “toxic” until it becomes absolutely meaningless. Let’s keep that to a more fitting context, having a

I was expressing an obviously personal opinion about the language itself, which is objectively a dull, barren wasteland that sucks out your soul while you walk it. That is precisely the reason why it’s so widespread and loved by business entities and managers - there is no excitement, no surprises, just an everlasting monotony of keys clicking produced by a horde of clones wearing button-down shirts while sitting in absolute identical cubicles, creating yet another instance of FactoryProducer. It’s very easy to plan and schedule for, while at the same time being unnecessarily verbose and mildly unproductive (compared to other languages).

Look, the JVM is fine, just pick another language. There is plenty of work doing Kotlin. But yes, if you’re doing this only for the money, go ahead. I’ve always been unable to separate my job fromy personal life and my other interests, I couldn’t imagine being cursed by Java again.

If you can sit somewhere for 8 to 10 hours each day, doing something that isn’t fun and separate yourself from it, not going insane, all the power to you. I also get that not everyone has the luxury of picking their favorite toy and making it their job, but I firmly believe there are options that are not Java.

Now, if you’re one of the rare types that actually enjoys Java, meet me in the closest Denny’s parking lot, I need your cranial measurements.

Please note: this post contains hyperbole and humor. I don’t hate any of you, I just hate Java

My personal recommendation:

• Pick up Python, it’s easy to learn and highly productive. If you also learn fastAPI, you can benefit from highly validated, declarative models to build REST APIs in the backend, well fast. It will yield quick results, you won’t become demotivated and you can pick up a paid project soon.

• Pick up Rust. It’s “in” right now and I get requests from marketing people that know nothing about programming, asking if their project could be implemented in Rust

• Go with memorizing the shell commands first, try to understand git later. Get productive, try to get where you were with e. g. svn or cvs. If you are comfortable, look at something in depth if you have a problem that you can’t solve with the knowledge you have.

• Fuck Java, seriously.

• You have commercial interests, so it is probably wise to look into becoming a fullstack dev to maximize the kind of projects you can do. Look into React, vue.js, svelte. React is probably still the most widely used framework, you’ll quickly do a project with vue.js and svelte is a super interesting look into things to come.

With type annotations, this problem is mostly alleviated in practice, while still keeping the productivity gains of duck typing.

Based on this comment*, I’ll migrate a large project to bazel now. I’ll report how it goes.

• disclaimer: the comment just pushed me over the edge

Surely not. But also many employees won’t even ask for it, and change will only happen if people care about it.

So first, raise awareness, and naturally, implement those things at any companies you manage or own.

I’m not saying quit your job and become homeless if your employer won’t corporate with you on the issue. Everyone should think about how this could potentially affect them and what they can do within the constraints they operate in, though.

As someone else in this thread said, a separate (VLAN, guest) network for work devices, reasonable access rules etc. can go a long way. Eventually, I would like this to become unacceptable though.

No, have the company buy a laptop, and if necessary, also have them buy the hardware that allows for proper network separation, if not already available.

Just another thing to be aware of.

I know it is somewhat of an accepted practice, and a lot of people lack the means or the knowledge to handle it any other way, but I’d still like to raise awareness that you’re basically inviting a foreign actor into your network.

The days were people would trust corporations, including their employers, to be generally benevolent and to do the right thing are long over.

This is absolutely correct. Heck, you’re free to deny that based on any reasoning, maybe the shoddy icon of the work app doesn’t match your phone wallpaper.

The phone is your private property, if an employer requires an app to be installed to do your job, they can provide a phone.

I would also never let corporate IT manage a device, e. g. a laptop connected to my private network at home.

Yes, absolutely. Not all hinges are adjustable, unfortunately. In fact, I’d argue that most are not. Just have a look at the hinges at your place (doors, cabinets, toilet seat etc.), most will be very simple mechanisms with no inbuilt adjustment.

You can adjust the play mechanically, of course - that is, through application of a certain amount of force via deformation, which can be a destructive process if not done carefully.

There are hinges that expose an axial screw that allows for precise adjustment of hinge friction, but I have not seen those used for laptop display lids (nor did I personally encounter those in the small dimensions you would find on a laptop) . You’ll find examples of those at Misumi or McMaster - Carr.

If your goal is to increase the friction in your laptop’s display lid hinges, you might find that simply tightening all screws of and around the hinge often does the trick. Even though the main axial screw is not meant to be user accessible, it serves basically the same function and can tighten up the hinge. Tightening the screws used for mounting will ensure the lid doesn’t wobble. You will have to (partially) take your laptop apart for that, naturally.

If your hinge doesn’t have an axial screw at all and uses, let’s say a pin, you might have to employ another method, but that would really depend on the actual mechanism being used.

Absolutely, if there is enough plastic left, melting is one of the best options. That also enables mending plastic by melting in metal pins or strips via a cheap plastic welder for 10 bucks (success can be great, but it’s highly dependent on the geometry and how things broke).

Edit: no, as I said, that’s absolutely fine if there is a chunk of sturdy plastic to accept the insert. I just wanted to present another plastic repair technique for the sake of completeness, if somebody stumbles into this comment section.

This is correct and good advice. I’d like to add that it’s also an option to glue in a threaded metal insert in case a self - tapping plastic screw was used and the original thread is stripped.

by loosening the screws of the hinge.