> people are doing real paid work using LLMs that they could not otherwise do

Sure, with LLMs, one can naturally tailor this much closer to the current need (or at least the need one thinks they have) and iterate ("spew") faster, but it's not a new phenomenon in general.

s/Europe/all parts of Europe/

I.e., Europe has a lot of different climate (sub)zones, and it heavily depends on where you actually live.

I'm fine with a fan in the Alps, where I sleep at 1,000 metres above sea level, and nights with the minimum temperature above 20°C are still very rare. I even don't bother turning the fan on most of the time, or just for an hour or so to clear the trapped heat in the bedroom at like 22:00 o'clock once outside cooled down enough.

OTOH I'm NOT fine in my Vienna flat with just a fan. There, this summer we got quite a few nights where the minimum temperature did not go below 25°C, even some with a minimum of 28°C and a maximum of 41°C. The flat is an old building and has only windows on one side facing a small curtilage without any trees or grass, so it traps heat, and I cannot even cool it well at night, even if the outside temperature goes a few degrees below the inside one, as the yard also traps heat.

Without an AC I could not sleep at all-even with a fan, it's very hard to sleep well above 25°, and frankly even above 23° for me. And I had to buy a much less efficient portable one (before the Midea Portasplit was a thing) because of braindead local regulations.

Ironically, in the winter the local gov suddenly starts calling those "bad ACs" again by their alternative "heat pumps" name, and they become the best thing ever for heating. I really cannot figure out how one can do that mental gymnastics without getting a headache.

Anyway, don't assume that your local conditions hold for all of Europe.

And the reason it makes no sense is that by your logic, any tool that can consume some (e.g. HTTP-based REST) API would have to be open-sourced the moment I get it to fetch data from my AGPLv3 service. No offense meant at all, but that would simply be bizarro world, and there is enough precedent against it. If APIs did not act as clear boundaries, AGPLv3 software would indeed spread to everything it touches or traverses, like an epidemic. If yours or your customers' lawyers claim otherwise, you/they should get ones with an actual understanding of software and IP law.

No, it isn't; a client talking to an AGPLv3 service over a network API stays a separate program and is not touched by the license at all. Section 13 places obligations solely on whoever runs a modified version of the service, while remote users, API clients included, only gain the right to receive that service's source. So nothing on the client side must suddenly become AGPLv3, and the only thing that ever has to be shared is the AGPL'd program itself, not anything across the API boundary. The first half of your post is basically unfounded FUD; the second half tracks.

    > 1. Perl has a dense programming style and is quite opaque to new maintainers. You also have CPAN dependencies to keep track of.

    > 2. Python is more readable than Perl, but has its own issues

    > 3. Rust or Go is single-binary shipping. Rust or Go is easier to test.

    > 4. In practical terms the Perl developer population is a shrinking one. Rust and Go are growing.

    > Ultimately you are selling Proxmox as a hypervisor platform and the expectation is the user should not go hacking around in the shell?

    > So shipping compiled binaries is safer (easier to audit) than shipping shell scripts that e.g. an attacker with shell access could easily compromise by manipulating the scripts.

    > an attacker with shell access could easily compromise by manipulating the scripts.

Yes, basically this, but in addition to us not providing a kernel and boot method targetting the RPi or other such SBC, but most of the time all will work if you bring that yourself (or plain Debian provides that for your).

Besides that being very outdated view of our tech stack, given that we have used Rust for every new development for seven years already and migrated lots of Perl code to it - what's actually wrong with using Perl?

Is all Perl, Python, etc., generically just categorally unusable for someone? Or is the fact that Perl - just like Python and many other languages - packs a lot of built-in features while being easy to modify and interpretable so it can also be used for scripting purposes seriously counted as a "strike against it"? Genuinely curious where these - for me completely unrelatable - opinions stem from.

FWIW, you'll now get 90% there with our official repos, basically "just" need to manage kernel and boot procedure yourself. And for that it might be enough to install vanilla Debian (or Armbian?) first.

I.e., not possible means mostly this is not actively supported and we won't put up with RPi's special boot shenanigans.

And we're still open to taking in changes that make this better supported on such hardware, as long as it's a maintainable (targeted) change and does not affect our actually actively supported targets negatively.

[0]: https://www.proxmox.com/en/about/company-details/press-relea...

Comments URL: https://news.ycombinator.com/item?id=49181916

Points: 34

# Comments: 5

[0]: helix: A post-modern text editor. https://helix-editor.com/

I mean, I naturally should try myself, and plan to do so, but slightly lower on my free time priority list and I figured someone else might have explored this already.

Oh, and mailing lists are a bliss to use compared to (barely loading) forges, at least to me and especially with public inbox and tools like b4 and lei for patch review, management and applying. For the sending side it's basically a git send-email command to pve-devel@list.proxmox.com, see https://git-send-email.io for a simple tutorial.

It's certainly subjective, but the amount of tech support I have to give has dropped significantly since switching the few people I care enough about to help from Windows to a mature Linux distro like Debian, while they are certainly not less productive.

A modern Debian or Fedora with KDE is a breeze otoh, I set that up for relatives and my SO, and they're all more than happy with it. Bugs exist, like in all software, but the friction is way less compared to wrangling with Windows nowadays.

Sure, not all workflows are a good fit for this, that's why I started with a disclaimer. But, if you want to do stable release in general, then it's IMO better to adapt the general workflow to that (which provides other benefits too, like on bisecting or when writing actually good release notes), than trying to force that on a not so compatible workflow.

But I'd be happy to hear alternatives, like how you solve this; always interesting to read others perspectives that lay out their solutions (not just why mine doesn't work 1:1 for you, which is basically a given for any non-trivial project).

It really depends on the whole development workflow, but in my experience it was always easier and less hassle to develop on the main/master branch and create stable release or fix branch as needed. With that one also prioritizes on fixing on master first and cherry-pick that fix then directly to the stable branch with potential adaptions relevant for the potential older code state there.

With branching of stable branches as needed the git history gets less messy and stays more linear, making it easier to follow and feels more like a "only pay for what you actually use" model.