tlamponi

Your document shows 10.9 ct/kWh normalised production cost for 2025 (roughly double the ~5 ct of a normal year, because the plant was offline half the year). That shows how exposed such a plant is when it's offline; and running an existing, paid-off plant built in the 1970s, like the one you linked, is a very different thing from building a new one today.

Burning coal sure is stupid, but so is being stuck in the outdated idea that we need either coal or nuclear for baseload. Solar, wind and storage are much cheaper, more flexible and far faster to build (a year or two, not 15+). IMO that's a much better answer than starting some SMR pipe dream now. 10 or 20 years ago it would have been different, but there's no point clinging to a solution just because it made sense back then, and was rejected for the wrong reasons.

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

FWIW, this is not exactly new; those same people were just using other sources like Stack Overflow, blog posts, etc. before, cobbling together random code snippets, libraries, and so on without actually understanding any of that at a relevant detail level.

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.

> But A/C it a necessity like water/sewage/electricity? In Europe, nah.

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.

We have been running a business on exactly the opposite premise for over 20 years, and we're not really seeing that problem with the adoption of Proxmox VE or our other (AGPLv3) FLOSS projects that we provide commercial enterprise support for. Very rarely, a potential customer doing extra due diligence, and not yet used to working with FLOSS much, wonders about exactly this - which is also the main reason I bothered writing anything here, as spreading such FUD further only hurts everyone involved. In those cases, a simple reply that a) this makes no sense (more on that below) and b) an assurance in writing that none of their software running on top of, or interfacing with, any of our APIs has to be relicensed settles it. That assurance is technically useless, as it doesn't grant them anything extra, but it costs us nothing either.

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.

> if you run a copyleft service and connect to it via API, is that extending it

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.

You can write dense Perl code just like you can write dense Go, Rust, ... code (did you ever write a rust proc_macro and then wanted to edit/extend that like half a year later?); our common coding style in Proxmox is to not use the more sigil-heavy/dense variants of Perl. Re CPAN: that's not used at all in Proxmox VE; we distribute all packages and dependencies solely through Debian package based repositories, with full audit and supply chain integrity.

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

See the first part of 1.; besides, both Python and Perl have type annotations that can help.

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

Erm, no, that doesn't change anything? Our daemons are also just single executables. Just like you can "link" any interpreted code into one file, that can be OK for distribution but normally provides no benefit on its own. And they still load modules or dynamic libraries, like the stdlib; both Go and Rust are not fully static (as in compiled with musl) in most common use cases after all. For Rust this is actually a significant pain point: a good and stable Rust ABI that allows native dynamic linking would allow more library reuse and thus faster and smaller/more targeted updates for delivering bug and security fixes. As of now you always have to ship the whole (potentially huge!) binary to deliver an update. In some parts we use Rust dynlibs with a C ABI, but that's rather a crutch.

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

Yes, but that doesn't make Perl or Python a worse language to use, it mostly might hinder potential external devs from contributing. But for one, we have enough Perl experts hired to cover that, and for another, we know of one prolific former contributor with a ton of sysadmin and Perl experience that basically stopped contributing to our newer projects due to the Rust adoption and that being a challenge for them to learn. Language widespreadness also has to be looked at from the POV of the existing developer community, not just the global one. In this case the benefits of Rust still outweigh the cost, and it could also be the other way around, but it's still sad to see experienced contributors being hindered, and it's an example of your point not being as simple as it might sound.

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

Yes, that's also why I never stated otherwise, my point was that being able to do so is really not a negative thing. Or would Go or Rust become worse if they got better scripting support?

    > 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.

For one, we're not shipping shell scripts, but polished Perl code with a mature module hierarchy and many modern features that Perl does provide over simpler shells like POSIX sh or Bash. And for another, no, binaries are not easier to audit, on the contrary; they are only auditable at all with reproducible builds, which is still not a fully solved issue (albeit we're getting there). Perl you can just look into, and debsums can also tell you at a glance that all files tracked by the Debian packaging system that we reuse are sound and safe, delivered and signed with our release keys. The latter holds for Rust too, that's why it's fine, but not because they are less introspectable due to being binaries. IMO you got it really backwards.

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

An attacker with root access - which is needed to manipulate these "scripts" as you call them - can also just edit the binary, switch it out with a jump script/executable with their rootkit in there, or a recompiled version of the Rust, Go, whatever code with their malicious code in, ... Or how does being a binary magically avoid that?

> Maybe they mean there’s no enterprise support, but it technically runs?

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).

> Certainly the fact that Proxmox heavily uses perl is a strike against it.

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.

> It's a bummer you can't use this on Raspberry Pi, but then again, they are incredibly bad value right now.

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.

Has anybody experience with using this with strong dialects, like e.g. bavarian-family (German) based ones? Or other languages one too, as I'd figure basic behavior and approaches to improve detection of such is often similar in principle for dialect style variants of a language.

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.

It's because all the frequent comment that this pelican is in the trainings set now also got into the trainings set and models adapt. /joking (I hope)