OpenSimWorld is the directory of 3D Virtual Worlds based on OpenSimulator and connected through the HyperGrid. Learn More
New Members
WestMoon, CapucineFR, MoonlitNomad, Hecklezz, Alterholic✦, DevonSoul, Polarisii, TauAne, AluninEldar, Asteria Starchild, AMBERLEE, Samantha23, KnightOwlLogan, MiraclesWelt, Quenala, AnnaUlfr, Durango, Gabriel_Darko, Tiberius, CountDanteLikes
A REQUEST, not a plea for: Opensimulator to unfreeze XEngine development. I refuse Microsoft; My servers run Linux. I remember the M$ three E's: Embrace, Extend, Extinguish; used to crush rivals. I truly believe they are still playing 'the long game' and nobody can convince me otherwise. I have regions I've been building for years that YEngine's stricter, ternary-breaking syntax will damage. I understand the pitch: YEngine tracks LSL spec syntax more closely, which helps people port scripts over from Second Life. Fine reasoning for new content. Not much comfort for those of us with years of working state built on the assumptions the 'proven and tested' XEngine let us make, assumptions the 0.9.3.0 release now discards completely, since XEngine is dropped there entirely, along with Mono support in favor of .NET 8. My NEXT donation comes when I see some love for the MONO branch. I am not rich but I am not talking petty cash either. Presently, I'm documenting the journey of coding chaos in a world that's ever-adapting. It would be pleasing to report that backward compatibility matters to somebody in the development pipeline. The correct eyes will accept or reject: I personally benefit from this either way. Use that as you will. Peace & Love.
Liked by: 
Comments
.NET8 is toast in november. dev meetings are every tuesday 11am open to all http://opensimulator.org/wiki/Office_hours
AFAIK there's is some issue with libgdiplus from mono that needs to be dealt with
like(1)
AFAIK there's is some issue with libgdiplus from mono that needs to be dealt with
As a systems engineer, I think the switch to .NET 8 is a terrible idea. I haven't seen any benefits from it so far. The only one profiting is Microsoft, because users of Microsoft servers are now being forced to upgrade to newer Windows Server versions that operate on a subscription model. It’s nothing more than a blatant money grab. So, I’m going to freeze the old OpenSim version and—at most—run it on Linux if my Windows Server eventually gives up the ghost. I just hope someone comes up with the idea of creating a fork that uses Mono.
like(0)
As a system Engineer I Tell, you can stay on Mono, but what will you do when mono will be depreacated ?
As a Coder I Tell, Most of Mono developer have migrated to DotNet for many reason, as ability to maintain their projects, and performance is one of them.
I like to read Microsoft haters because they don't seem to know that Microsoft is one of the main contributor to opensource foundation, linux kernel, and many opensource projects.
like(0)
As a Coder I Tell, Most of Mono developer have migrated to DotNet for many reason, as ability to maintain their projects, and performance is one of them.
I like to read Microsoft haters because they don't seem to know that Microsoft is one of the main contributor to opensource foundation, linux kernel, and many opensource projects.
Checkmate: But not how you think! I do not believe that Microsoft's contributions are altruistic. In fact I believe it is at the very heart of their nefarious scheme: EMBRACE and EXTEND is first... I Say EXTINGUISH is coming... The Redmond Giant has always played NASTY. Plenty of NEW venom is constantly being injected into to their 'Malware 11' OS. I call it malware because it serves M$ directives before yours. Every complaint about 11 appears on my YouTube feed; and it pleases me I kicked it to the curb right when version 8 surfaced to annoy the internet! Asking the battle scarred and perspicacious to place trust in their code; is like asking someone to return to an abusive spouse.
Get me ONE, shame on you... Get me TWICE, SHAME ON ME!
like(0)
Get me ONE, shame on you... Get me TWICE, SHAME ON ME!
Checkmate ?
This kind of anti-Microsoft activism is honestly getting tiresome. The irony is that many of the people making these arguments rely every single day on technologies Microsoft contributes to, sometimes without even realizing it, and sometimes by choosing to ignore it.
Yes, Microsoft has had an aggressive history when it came to competition. Yes, the company has benefited enormously from open source, just like Google, Apple, Meta, Amazon, and virtually every other major tech company. But today, Microsoft is also one of the largest contributors to open source and invests billions back into the ecosystem. That's not altruism, it's pragmatism. And that's exactly what you'd expect from a publicly traded company.
For years, Microsoft tried to force everyone into its own ecosystem. Today, it has realized there's far more to gain from working alongside Linux, Kubernetes, Git, Python, open-source .NET, and by developing WSL and contributing directly to the Linux kernel. This shift isn't driven by philanthropy; it's driven by economics. And whether people like it or not, developers benefit from it too.
I also find it a bit too easy to paint Microsoft as the ultimate villain. If the company achieved a near-monopoly, it's also because millions of users, developers, and businesses chose its products for decades. You can't condemn a monopoly without acknowledging that, collectively, we helped build it.
I'm one of the first to criticize Windows 11. I think it's becoming increasingly intrusive and more focused on telemetry than on being a straightforward operating system. Yet I still work on Windows because Visual Studio remains, for my workflow, an outstanding development environment. It's a conscious trade-off. And I seriously doubt there's a single major tech company whose motivations are fundamentally more virtuous than Microsoft's.
The funniest part is that this rhetoric often comes from people using GitHub, VS Code, TypeScript, .NET, WSL, Azure, npm, or dozens of open-source projects funded or maintained by Microsoft. They denounce Microsoft while benefiting from its work every single day. That's a contradiction worth acknowledging.
So sure, let's get rid of Microsoft. While we're at it, let's say goodbye to .NET, VS Code, TypeScript, PowerShell, WSL, thousands of contributions to the Linux kernel and countless open-source projects, along with the billions Microsoft has invested in the ecosystem. Linux would take a serious hit, whether people want to admit it or not. And since we're rewriting history anyway, why not go back to 8-bit computers? They worked just fine too.
Criticizing Microsoft is perfectly legitimate. Portraying the company as the embodiment of evil while simultaneously benefiting every day from the technologies it develops and supports is far less convincing. Black-and-white narratives may be emotionally satisfying, but they rarely reflect reality.
like(0)
This kind of anti-Microsoft activism is honestly getting tiresome. The irony is that many of the people making these arguments rely every single day on technologies Microsoft contributes to, sometimes without even realizing it, and sometimes by choosing to ignore it.
Yes, Microsoft has had an aggressive history when it came to competition. Yes, the company has benefited enormously from open source, just like Google, Apple, Meta, Amazon, and virtually every other major tech company. But today, Microsoft is also one of the largest contributors to open source and invests billions back into the ecosystem. That's not altruism, it's pragmatism. And that's exactly what you'd expect from a publicly traded company.
For years, Microsoft tried to force everyone into its own ecosystem. Today, it has realized there's far more to gain from working alongside Linux, Kubernetes, Git, Python, open-source .NET, and by developing WSL and contributing directly to the Linux kernel. This shift isn't driven by philanthropy; it's driven by economics. And whether people like it or not, developers benefit from it too.
I also find it a bit too easy to paint Microsoft as the ultimate villain. If the company achieved a near-monopoly, it's also because millions of users, developers, and businesses chose its products for decades. You can't condemn a monopoly without acknowledging that, collectively, we helped build it.
I'm one of the first to criticize Windows 11. I think it's becoming increasingly intrusive and more focused on telemetry than on being a straightforward operating system. Yet I still work on Windows because Visual Studio remains, for my workflow, an outstanding development environment. It's a conscious trade-off. And I seriously doubt there's a single major tech company whose motivations are fundamentally more virtuous than Microsoft's.
The funniest part is that this rhetoric often comes from people using GitHub, VS Code, TypeScript, .NET, WSL, Azure, npm, or dozens of open-source projects funded or maintained by Microsoft. They denounce Microsoft while benefiting from its work every single day. That's a contradiction worth acknowledging.
So sure, let's get rid of Microsoft. While we're at it, let's say goodbye to .NET, VS Code, TypeScript, PowerShell, WSL, thousands of contributions to the Linux kernel and countless open-source projects, along with the billions Microsoft has invested in the ecosystem. Linux would take a serious hit, whether people want to admit it or not. And since we're rewriting history anyway, why not go back to 8-bit computers? They worked just fine too.
Criticizing Microsoft is perfectly legitimate. Portraying the company as the embodiment of evil while simultaneously benefiting every day from the technologies it develops and supports is far less convincing. Black-and-white narratives may be emotionally satisfying, but they rarely reflect reality.
Mono is already pretty deprecated to the point of being half-dead AFAIK. Besides, it has always been a filthy hack.
The OpenSim ecosystem doesn't really lack projects that died because they relied on dependencies that were first deprecated and then killed off entirely. Granted, they usually weren't cases of someone hanging on to old dependencies for their dear lives because they considered them better. They were cases of tons of old code that hadn't been touched in well over a decade. Yes, the compiler probably threw tons of "deprecated" messages. But hey, it compiled, and besides, upgrading the code would have been tedious and required tons of time.
Singularity is the prime example. Compiling it requires gcc4, last seen in the Ubuntu 14.04 LTS repository, last installable on Ubuntu 16.04 LTS from 14.04 packages. It probably only runs on Windows up to 10 or so anymore because you can toss almost any Windows binary at it.
I think Singularity has also got some bits of Python. As in Python 2.5 or so. As in so old that Python 3 wasn't even an idea back in the day. I remember a big application written in Python 2 that would have been so tedious to upgrade to Python 3 that the developer offered to fork Python 2 and maintain that fork instead. It appeared to be vastly easier.
Seriously, no development library version will be supported for all eternity. And probably the only thing which you can count on being backwards-compatible forever is TeX. If your compiler says, "Deprecated," don't hope for it to work regardless for the next decades or so, just so you can keep your beloved old dependencies rather than upgrading to something that's being actively maintained.
like(1)
The OpenSim ecosystem doesn't really lack projects that died because they relied on dependencies that were first deprecated and then killed off entirely. Granted, they usually weren't cases of someone hanging on to old dependencies for their dear lives because they considered them better. They were cases of tons of old code that hadn't been touched in well over a decade. Yes, the compiler probably threw tons of "deprecated" messages. But hey, it compiled, and besides, upgrading the code would have been tedious and required tons of time.
Singularity is the prime example. Compiling it requires gcc4, last seen in the Ubuntu 14.04 LTS repository, last installable on Ubuntu 16.04 LTS from 14.04 packages. It probably only runs on Windows up to 10 or so anymore because you can toss almost any Windows binary at it.
I think Singularity has also got some bits of Python. As in Python 2.5 or so. As in so old that Python 3 wasn't even an idea back in the day. I remember a big application written in Python 2 that would have been so tedious to upgrade to Python 3 that the developer offered to fork Python 2 and maintain that fork instead. It appeared to be vastly easier.
Seriously, no development library version will be supported for all eternity. And probably the only thing which you can count on being backwards-compatible forever is TeX. If your compiler says, "Deprecated," don't hope for it to work regardless for the next decades or so, just so you can keep your beloved old dependencies rather than upgrading to something that's being actively maintained.
That's a fair point, although you can still find a few Linux distributions that continue to maintain Mono to some extent.
As for me, I don't really keep up with the latest developments around technologies that I no longer use.
That said, I think the deeper issue is the lack of cohesion and a clear long-term direction. Singularity is just one example among many. New projects keep appearing, but they often continue to build on old components instead of taking the opportunity to modernize them. Eventually, technical debt accumulates, development slows down, and the project ends up dying.
In that respect, I think the OpenSim developers made the right decision by not porting XEngine to .NET. Everyone seems to be heading in their own direction and defending their own preferred solution, but that kind of fragmentation ultimately hurts the project as a whole.
like(1)
As for me, I don't really keep up with the latest developments around technologies that I no longer use.
That said, I think the deeper issue is the lack of cohesion and a clear long-term direction. Singularity is just one example among many. New projects keep appearing, but they often continue to build on old components instead of taking the opportunity to modernize them. Eventually, technical debt accumulates, development slows down, and the project ends up dying.
In that respect, I think the OpenSim developers made the right decision by not porting XEngine to .NET. Everyone seems to be heading in their own direction and defending their own preferred solution, but that kind of fragmentation ultimately hurts the project as a whole.
Yup, Singularity is a fork of a fork of a viewer that predated OpenSim itself; I think it was from as early as 2005. And you can bet that there's a lot of code that wasn't touched since then.
Also, the more old cruft developers decide to keep around because the old-timers are so used to it, the more old cruft they'll have to maintain for all eternity.
In this regard, I'm glad that it was technologically impossible for full EEP support and full Windlight support to co-exist in Firestorm. I also think that cutting forward rendering from Firestorm 7 was a relief for the devs. (And I guess that there are some OpenSim veterans who stick with Firestorm 5 or so because it still lets you turn the rendering of mesh off, and they curse the Firestorm devs for removing that switch and hard-coding mesh to on.)
like(0)
Also, the more old cruft developers decide to keep around because the old-timers are so used to it, the more old cruft they'll have to maintain for all eternity.
In this regard, I'm glad that it was technologically impossible for full EEP support and full Windlight support to co-exist in Firestorm. I also think that cutting forward rendering from Firestorm 7 was a relief for the devs. (And I guess that there are some OpenSim veterans who stick with Firestorm 5 or so because it still lets you turn the rendering of mesh off, and they curse the Firestorm devs for removing that switch and hard-coding mesh to on.)
I recommend to use the new means that will most probably help you solve many of your challenges, cheaper and more efficient and it could be fun... Try AI. You could just start with https://chatgpt.com/, if your problem should be more challenging, look for a more powerful model. We use AI to solve our scripting problems and non of us is a professional programmer.
like(0)
XEngine was removed in version 0.9.3.0 due to the transition to dotnet 8. They didn't plan to port Xengine to dotnet8, maybe because YEngine is more modern, more used and porting XEngine is heavy cost of developpment.
I didn't use it even when I was using mono version.
Personnaly, i prefer they focus on a more modern scripting engine like lua, or maybe python rather than maintain old dépreacated and redundant bricks.
like(0)
I didn't use it even when I was using mono version.
Personnaly, i prefer they focus on a more modern scripting engine like lua, or maybe python rather than maintain old dépreacated and redundant bricks.
Unfortunately, we're stuck with server software (!) that was developed for Windows first and foremost back in the day.
On the other hand, I'm glad that OpenSim has no Python in it. It would certainly have relied on Python 2 beyond Python 2's final, ultimate, this-is-definitely-it-and-we-mean-it end of life, what with large swathes of code not having been touched since before 2010.
And then the wake-up call wouldn't have come from popular Linux distros (Debian stable, Ubuntu LTS etc.) announcing to throw OpenSim out of the repositories due to its dead dependencines as there's no distro that offers OpenSim in the first place. No, the wake-up call would have come from big grids running on Linux servers whose server OS support would have been about to be dropped: Either they get a new OpenSim release that works with Python 3, or they'll have to shut down for good.
Then again, even C or C++ code has to be upgraded every once in a while, even if it still compiles and runs. Sure, they say, "Never touch a running system." But if your system literally announces that it won't be running for much longer unless you do touch it, and if you can easily find out at which point in the future your system will stop running, then by all means, DO touch it. While it's still running.
like(0)
On the other hand, I'm glad that OpenSim has no Python in it. It would certainly have relied on Python 2 beyond Python 2's final, ultimate, this-is-definitely-it-and-we-mean-it end of life, what with large swathes of code not having been touched since before 2010.
And then the wake-up call wouldn't have come from popular Linux distros (Debian stable, Ubuntu LTS etc.) announcing to throw OpenSim out of the repositories due to its dead dependencines as there's no distro that offers OpenSim in the first place. No, the wake-up call would have come from big grids running on Linux servers whose server OS support would have been about to be dropped: Either they get a new OpenSim release that works with Python 3, or they'll have to shut down for good.
Then again, even C or C++ code has to be upgraded every once in a while, even if it still compiles and runs. Sure, they say, "Never touch a running system." But if your system literally announces that it won't be running for much longer unless you do touch it, and if you can easily find out at which point in the future your system will stop running, then by all means, DO touch it. While it's still running.
Personally, I'm not a big fan of Python. Even minor version updates can break things, and before you know it, you end up with ten different Python versions installed side by side. That said, I work with it because most of my AI projects run on Python (avatar service, system and database montoring, llm, generative AI, etc), and I've learned to live with it. Right now, I'm only about two minor versions behind, so it's still manageable.
That said, I don't think we're really constrained by the server software itself. Personally, I've already started cleaning things up. To me, it's mostly a matter of willingness and long-term vision.
For example, my inventory and asset services run on an Oracle database, while the rest of the system uses PostgreSQL. If I had limited myself to the technical choices imposed by the server, I would have given up long ago. Instead, I debugged the entire PostgreSQL layer and wrote an Oracle backend module myself.
Sure, you can write everything in C++, but if you make the same mistake as the viewer and rely on third-party libraries that break with every update, you're never really finished either.
I'm firmly in favor of moving forward. The idea of "don't touch it if it works" has another name: accumulating technical debt. In my opinion, the OpenSim developers did exactly what needed to be done. they kept moving the project forward. That's probably one of the reasons why it still running today.
like(0)
That said, I don't think we're really constrained by the server software itself. Personally, I've already started cleaning things up. To me, it's mostly a matter of willingness and long-term vision.
For example, my inventory and asset services run on an Oracle database, while the rest of the system uses PostgreSQL. If I had limited myself to the technical choices imposed by the server, I would have given up long ago. Instead, I debugged the entire PostgreSQL layer and wrote an Oracle backend module myself.
Sure, you can write everything in C++, but if you make the same mistake as the viewer and rely on third-party libraries that break with every update, you're never really finished either.
I'm firmly in favor of moving forward. The idea of "don't touch it if it works" has another name: accumulating technical debt. In my opinion, the OpenSim developers did exactly what needed to be done. they kept moving the project forward. That's probably one of the reasons why it still running today.