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.
So you see that avg opex price is cheap, thanks for acknowledging. That was the statement, not that in new plants power is more expensive because they need to repay loan (which is balooned due to delays)
We need firm power. This isn't outdated. That's also why Germany approved subsidies for new gas plants, which were recommended even by Fraunhofer ISE
Basically either you build a mix like france/nordics and get very low emissions or you are stuck with vre+bess+gas combo like Germany.
Or, if you are convinced VRE are enough, provide an estimation/simulation for German grid based on existing data of last decade (capacity factors/demand)- how much vre+bess is needed to ditch firm fossils fully
> 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.
I think this is fine as long as the success criteria are strict enough that they are forced to learn something in the end.
Any significant testing will inevitably create that situation. The LLM won't have enough context to handle the more precise business requirements. The dev will have to read the code carefully and make their changes by hand. Additional rounds of testing may cause thrashing between regressed states until something clicks for the developer. That lightbulb going off is called "learning" and they are human after all!
Promotion into management isn't so different. They still experience similar thrashing and have to learn or be fired.
My point was not only that so much human learning happens out-of-band, but that it has to be fundamentally different from how an LLM builds context. I've never seen an LLM overcome the thrashing on its own. There's never any "lightbulb moment".
Yeh but I also mean outside of software engineering. Within the gamut of 'being a programmer' it seems fair to bleed into adjacent areas without too much cheek. We've all done it; it's part of the learning curve. But I was talking more about people in other knowledge work who have to come up with a lot of prose-like material about {insert thing}. Marketing, consultants, PMs, or even domain-specific analysts, .. ya know, the types of office jobs where people basically write emails, attend meetings, discuss reports, and produce mostly text-or-data artefacts all day long.
> 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.
> 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.
You may think this. I may think this. But what really matters is if the lawyers for your customers think this. It may be pure FUD, but AGPL projects have a tough time getting adoption in companies because they would rather avoid the problem than be wrong.
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.
This is true, unfortunately. I've have had to walk away from a client because their software-illiterate lawyer didn't want me to build with copyleft dependencies.
It wasn't the only red flag in this case, but frustrating nonetheless.
Well if it's a commercial project what did you expect? The problem there is working for free for a corporation's benefit - copyright assignment or not.
> 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.
> Is all Perl, Python, etc., generically just categorally unusable for someone?
I am not the OP but my take as someone who is not keen on Perl or Python:
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 (dependency hell etc.) and still does not address the issue of dynamic typing and the inability to test correctly, whilst e.g. Rust and Go will just refuse to build.
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.
But I'm sure you already know all of the above given you have been using Rust for seven years and spending effort migrating Perl scripts .... not exactly something you do for fun. :)
> 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?
> 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.
Following the "Proxmox VE delivers high-availability infrastructure management for NVIDIA Mission Control AI factories" press release [0] some wondered about ARM already - as NVIDIA's AI factories are based on ARM64 - and now the arm64 port is also officially available.
Interesting comparision with NeoVim, given that it was basically created to provide a better default (config) experience than classic vim. We might be close to PostNeoVim (or is helix [0] already that?).
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.
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.
reply