I'm pretty sure it's been the case since at least 7.0, as I've done it a few times on hosts such as Scaleway that only offered a Debian base image for my machine.
Somewhat annoyingly, Proxmox relies on a non-Debian kernel for at least some of its features. This definitely made a difference w/ Bookworm (which was on the 6.1 kernel release series), not sure about Trixie (which will be on 6.12).
I said most of the same things in the Matrix foundation's server. The general response from the team was: "Pay money or shut up and accept what we give you". The number of gigantic changes in direction this project has had in the past couple of years is enough to sink any project. Jitsi to Webrtc, complete change in auth system, Element to Element X. There's two clients. One that's fast, and one that's full featured. You can either skip out on features, or use something slow.
I try to be positive and supportive of project, but my experience with these guys is that they're incredibly arrogant.
It's tough finding an open-standards based IM application for corporate use.
XMPP is kinda fragmented, with no nice clients.
Matrix is a clusterfuck with a BDFL who is probably too smart for his own good.
Signal is open source but hostile towards self hosting.
P.S I suspect the organization is being led by Architecture Astronauts [1]. Every (including the naming) is abstracted to the point of meaninglessness.
Gajim has been genuinely pretty unstable and buggy for me on Wayland (Sway) with lots of "crashing", in quotes because they tell me it's not crashing if I try to report it, but it's more like the windows are lost suddenly (this has improved over time somewhat at least, it used to be the whole client several times per day and now it's just the file picker, which can mostly be avoided). As for Conversations, mostly works great, if I had to complain it would be that you're forced to use relative timestamps with no way to configure them.
To compare Matrix and XMPP, I like that with Matrix you can edit messages that are as far back as you want, not just the most recent one sent from the same device you're on. Sometimes I fire off a storm of messages and then while I'm waiting for replies I go to read over them again and catch some things I wanna fix that I didn't see before. I also like that Matrix is a bit more distributed in that if the homeserver the room is on/from goes down, everyone else can still chat. I even have a group chat originally made on a now completely dead homeserver but we're all still happily chatting in it. I'm using both XMPP and Matrix daily, but Matrix is the one I got IRL friends and family on. XMPP seems more popular with people from fedi and the like, what you might call "internet weirdos". I have considered trying to convince more IRL contacts to get on XMPP, but I'm not sure they could handle another move, and I'm not sure I could justify it when it's not an objectively better across the board upgrade. When we moved people off Facebook chat or Google Hangouts, we were going from something proprietary and centralized to something free and decentralized, also there was encryption I guess. XMPP is kind of a sidegrade. Ideally it wouldn't be a full move anyway so much as getting them all to sign up on it as back-up comms, but again I'm just not sure they could be bothered at this point.
As someone in the exact same boat as you (a happy XMPP user for 10+ years, with family and friends there), if I had to name one, it would be group calls and overall calls being supported in Gajim. We just hyperlink to jitsi meet whenever the need arises, not a big deal at all.
People keep hammering zulip as the example of threads done right. I disagree. They are practically indistinguishable from rooms, in looks and behaviour. It's not like zulip is offering a better abstraction/isolation level: you end-up with just as many threads, as much (in)convenience dealing with them, and the exact same caveats (there's no known solution to people writing out of thread, so the cognitive load is still worse - IMO/E - than "no threading at all").
That's why I wrote it is for geeks. Maybe I should have said it's for geeks that keep don't mind the offort of their stuff/data/code organized. You need to put some thinking to use reusable topics. And when discussion goes off-topic you need know where to move it. Zulip has support to do that, other systems just don't.
I was in a company for over 6 years where zulip threads were very organized. "zulip police" would tell those starting to create a mess. It's a cultural thing. We also spent significant time to keep our code clean. 90% of the work-places keep neither their communications nor their code organzied.
> The general response from the team was: "Pay money or shut up and accept what we give you".
I think you may be unfairly paraphrasing "we don't have enough funding to be able to work on both Element & Element X, or Synapse & Dendrite, or to have landed Threads/Spaces in Element X yet, or <insert complaint here>".
> The number of gigantic changes in direction this project has had in the past couple of years is enough to sink any project. Jitsi to Webrtc, complete change in auth system, Element to Element X.
It feels ironic that our attempts to improve the project are characterised as "gigantic changes in direction which are enough to sink any project".
* Jitsi is unencrypted by default, and doesn't synchronise identity, access control, or cryptographic identity with Matrix, and uses XMPP (Prosody) for signalling. Moving to MatrixRTC (i.e. WebRTC signalled over Matrix) gives proper end-to-end-encryption with verified identity and access control managed by Matrix. Surely this is a good thing?
* "Complete change in the auth system" is a massive improvement, in that one of the main drivers for doing it was to now be able to use any OIDC identity provider to add 2FA/MFA/Passkeys or whatever fancy auth you like (despite the OP's assertion otherwise).
* "Element to Element X. There's two clients. One that's fast, and one that's full featured". Well, that's true, but most people seem to feel Element X's improvements outweigh the fact it doesn't have threads/spaces yet (although they are both in dev currently).
> but my experience with these guys is that they're incredibly arrogant.
> I think you may be unfairly paraphrasing "we don't have enough funding to be able to work on both Element & Element X, or Synapse & Dendrite, or to have landed Threads/Spaces in Element X yet, or <insert complaint here>".
I asked in the chat what's the plan for people who are running on old servers when it comes to migrating to MAS. The general response was "Welp, should've gotten a support contract." Or maybe it was migrating from Element to Element X. I can't remember.
> It feels ironic that our attempts to improve the project are characterised as "gigantic changes in direction which are enough to sink any project".
The real irony is mentioning working on both Element and Element X, Synapse and Dendrite, and not see how much work that's already been done is being completely thrown away. This is not even including all the weird 3D stuff that was once a thing. Even the all the rebranding is kind of like 'wtf is happening over there'
> Jitsi is unencrypted by default.
Then why implement it? Or you could have contributed to it/fixed it instead of building something from scratch using technologies like SFU which no has has heard of before.
> There's two clients. One that's fast, and one that's full featured". Well, that's true, but most people seem to feel Element X's improvements outweigh the fact it doesn't have threads/spaces yet (although they are both in dev currently).
Since when have threads and spaces been in development? Probably almost a year now. And this is not even including the bug/unimplemented feature where in the android app where clicking a message notification just takes you to the bottom of the room instead of the message itself. And what about clicking to join rooms? Matrix.to? Come on, bro.
> For what it's worth, I think i've made some spectacular mistakes in running Matrix,
I wasn't talking just about you, your arrogance is kind of endearing in the right light. The community itself is so hostile to any criticism it feels like talking to toddlers.
> as well as bunch of good stuff
Matrix is great. Just not ready. The communication about how it's so great and ready is probably a big reason of why people are turned off. If Matrix was still labeled beta (and people weren't afraid of New Vector one day moving development behind closed doors) I can almost guarantee the community would be so much more vibrant. The threat of New Vector going fully proprietary is the main reason we decided not to move forward with contributing to the ecosystem. (we're still looking for our messaging home).
I remember when this video first came out. I think it was around the time of MatrixConf. Element X is not ready, and starting the video by calling it "Not just the best Matrix messaging app, but the best messaging app available" is (with all due respect) delusional, or marketing-led dishonesty.
I say all the above with love. I'm someone who has developed an admin panel for our internal proof-of-concept other than the one provided by New Vector or the other half-baked open-source one (I forget what it's called). So I've really dived deep into the ecosystem. But it's not there, yet.
I can see the vision you have for Matrix. The global federated network of eventually-consistent event servers. I love it and I hope it succeeds. But when commercial interests play a role and New Vector has some sort of conflict of interest between spreading Matrix as far as possible, and making it profitable, it's hard to buy in to that utopian vision. Be Linux, not Red Hat. You can't be both, that's where the conflict of interest comes in. Yeah Matrix is an independent foundation etc. etc. but if Synapse dies, the entire ecosystem dies.
"eIRC is a modern, scalable enterprise messaging architecture built on the IRC protocol. Designed for organizations that require ephemeral, real-time communication without the heavy operational overhead of pub/sub systems like Apache Kafka, eIRC delivers high-throughput, low-latency chat experiences while minimizing memory and CPU usage per user."
It does support history as well: "IRC History Bridge: Implement Redis-backed buffer for message replay".
That's too far in the other direction, IMO. The IRC protocol was a poorly designed mess. Tying yourself to it means inheriting all of its bizarre quirks and limitations, and there's very little that existing IRC servers do that would be difficult to replicate.
(For a taste of just how weird and terrible IRC can be, try to answer the question "what is the maximum length of an IRC message". If your answer is a specific number, it is incorrect.)
In my understanding, IRC was not designed at all. It has more like been built in an ad-hoc manner. IRCv3 is an attempt to create a clear specificatiot.
Tech people don't like to hear this, but you also need product people. And I don't necessarily mean those with a business background, but those who can see the larger picture from the user/customer perspective and who can ensure that all of the technology is packaged into one coherent and actually useful thing.
If the project is run by those who are all deep in the weeds of low level technological details, odds are that the larger product turns into a giant mess that is all over the place.
I'm a tech creator who's a product person for a long time, as well as on the business side. Hyper-problem and user focused. Having put in the time for all 3, I agree with you fully on needing product, tech, and user experience awareness.
I can say that tech creators tend to be able to learn product and business easier than the other way around.
One reality is too many product folks don't always know what tech is capable and possible of, which can undermine the asks and the solves. So innovation can become best practices (existing) and increments from there, instead of seeing new ways digital can be delivered.
I'm all for making fun of premature optimization and abstraction into wavy concepts. That can happen as much in product practice as it does development. Maybe the sticky consumption ratio could be part of a KPI.
When building technology solutions to solve people's problems, clever architecture will always beat clever coding and clever product people. Because you make both product and code and architecture evaporate for something simple and flexible that can actually learn and have more than few chances to become what the problem needs.
Another reality is tech folks don't need interpreters like they are sub-human or something either. It all depends how the organization and it's culture is put together to value everyone.
Where tech folks are relegated to be "engineering" it's at the peril of the organization. The more layers between the customers, their problems and those who create the solution (together), the greater the disconnect that can form as the org grows.
The solution is about a table.
A round table.
Where everyone has an equal seat and can understand it together.
The "tech guys", as you call them, are dogfooding the app and feeling the pain every day. Matthew — the CEO — is the biggest poweruser of them all and feels all the pain points, with his account being the worst-case edge case.
It's just that most of the money comes from consulting, and consulting customers care about new features, not performance or UX.
Which is btw not just a problem for Element — the other companies working on Matrix have the same issues, for the same reasons.
Discord can afford this level of UI polish because they're spending an order of magnitude more on dev salaries than the entire revenue of all companies working on matrix combined.
https://schildi.chat is better client than Elememt IMHO. That was the whole point of matrix federated. You dont hear ppl complain oh I am going to give up on SMTP cause outlook or fill in the blank sucks. Then make another client or server.
EDIT:
It really sucks that the default implementation is so bloated. But I do not equate matrix with element.
Ok fair. Did not know that. Just in my personal experience it is better. However like conduite for server , a lightweight http API client can be made. And communicate over https is great for crappy internet over proxy.
This statement might be ok in a generic sense, but it is unfair in a discussion of Matrix and Element. They have gone out of their way to encourage other source.
I get that you didn't say this explicitly about this particular project. I just think these folks deserve some credit.
It's the opposite. Episodes are lengthened with plot points being repeated through dialogue. Hour-long TV shows were really 40 minutes due to advertising, meanwhile on Netflix they are 50-plus minutes. Longer shows = more watch time recorded, which is Netflix's main KPI. Tiktok and others get long watch times because it's more like flipping through channels.
I think FastAPI's one major design difference is its dependency injection mechanism. Django is designed to do things differently, with services provided through an app- or project-global collection of middlewares (although I haven't used it in a while, maybe something had changed since then) and while there are DI solutions for Django they don't feel "native" to me - not the way FastAPI does it. Either way works, of course - it's probably merely a matter of the preferred mental model.
Web version sucks compared to desktop version, unless you use the apps minimally. That said, the Winapps repo is a good linux solution, running a windows VM and accessing the office apps via RDP so they feel like a native app. As soon as it gets wayland support, I'm making the full switch. Winapps in Xwayland has some issues.
A big one is that Microsoft shut off the email of the president of International Criminal Court based on an order from US authorities because he dared prosecute Israeli government officials.
Aoostar WTR series is one change away from being the PERFECT home server/nas. Passing the storage controller IOMMU to a VM is finicky at best. Still better than the vast majority of devices that don't allow it at all. But if they do that, I'm in homelab heaven. Unfortunately, the current iteration cannot due to a hardware limitation in the AMD chipset they're using.
I have the pro. I'm not sure if the Max will do passthrough but a quick google seems to indicate that it won't. (There's a discussion on the proxmox forum)
Has that always been the case? I have a faint memory of trying once and not being able to with Proxmox 7.x