First time I’ve heard of this project, so saving others a click:
Arcan is a powerful development framework for creating virtually anything between user interfaces for specialised embedded applications all the way to full-blown standalone desktop environments. Boot splash screen? no problem. SCADA HMI for your home? easy peasy. Xorg backend? got you covered. Wayland compositor? sure thing.
At its heart lies a robust and portable multimedia engine, with a well-tested and well-documented interface, programmable using Lua. At every step of the way, the underlying development emphasises security, performance and debugability guided by a principle of least surprise in terms of API design.
> the ‘elevator- pitch’ to the modern tweet-length attention spanned reader goes as follows:
> Arcan is a curious blend of a streaming multimedia processor, game engine and display server with a novel design that lends itself well for both complex and simple realtime interactive graphics projects alike, and goes well with anything from Sci-Fi UIs for some homegrown embedded project to full blown desktops. It is highly modular, low on dependencies, yet comes with all necessary batteries included.
So, what's it not good at, that's what I'm wondering. That's generally what I look for after reading overviews and PR pieces from evangelists. Right now, if I take the copy at face value, if I'm programming anything with a visual component I should be using Arcan. Knowing where some people find it a poor fit (or just too complicated for a simple use case) helps provide nuance to the hype.
The actual linked article says it aims for very complex things and simple (one-function) things but not in-between. I haven't looked into what that means in practice, but that's what's written.
"The perspective is to instead emphasise the extremes, that is to focus on the small “one task” kind of clients and on integration with bigger “embedded universes” like virtual machines and web browsers, and leave the middle to fester and rot."
I have spent a few minutes looking for an email address to send it to. You can try contacting me on @eitland on twitter (I just followed your account I think).
Edit, to clarify: The only way I know I can send an invite is to input the email address and an invite message into my settings page at that site. I'm not aware of another way to send it.
Wow, this seems to be a critical step towards the truly modern, networked, multimedia terminal(not an emulator?!) I’ve been fantasizing about since 1995.
I completely respect the project owners desire to fly under the radar, but man it sure seems like more contributors would be a good thing to help us finally move past the monstrous x11/xorg legacy.
To be honest, X hasn't been network transparent for the better part decade. Sure you can cut it back down to the point that it is, but the moment you want anything accelerated, no more network transparency.
In my mind, the best possible way to go about replacing X is making something that suits the way computers work today and the way computers are trending. That's why I really like Wayland. The entire point is to optimize for the local experience and anything beyond that is candy. It's designed for accelerated graphics first, which is what most client side users are going to have. It's even more important from a laptop perspective because of just how much more efficient the GPU is at rendering graphics.
As an aside, another great thing is that most the new features of linux and it's graphics stack that were created (at least in part) for Wayland are able to function completely outside of that environment. KMS, DRM, using full OpenGL or Vulkan without a display server, etc.
Is “network terminal” still a useful target? Disregarding the “elegance” of the X model, isn’t there still merit to the integrated approach of Windows’ User32 and kernel-modec local high-performance, low-latency graphics? It’s not like Crysis players in 2007 were asking for remote terminal support then - or now.
Well, Citrix, Remote Desktop, TeamViewer, Rainway, various VNCs, AnyDesktop and a bunch of other systems show that remote access to desktops is an important requirement, for gamers as well.
The lines between a "network terminal" and a "remote desktop" are essentially nonexistent.
Citrix, MS RDP, TeamViewer, VNC and the majority of those other tools you mentioned use fundamentally different architectures to X: they’re based on either local framebuffer mirroring (VNC, TeamViewer, etc) or proxying the local (2D) graphics and windowing API (Citrix, MS RDP). All of those systems are still based on fast local-only graphics and windowing systems, not the “network-first” design that X brings.
Is this design a failure? How many Citrix, MS RDP, TeamViewer, VNC, etc. users are there for every X user? 100? 1000? More?
As others point out contemporary X isn't really network transparent. Extensions compromise network transparency for performance, among other reasons. This compromise is inherent to the requirements of popular desktop environments today. Is this not further evidence of failure of the design intent?
Why has X not to contributed to mobile platforms? X is a native citizen of at least one of the major portable OSes (Linux) and not too far removed from the other (Darwin.) Yet no X.
Cloud hosted gaming is upon us; Google, Microsoft, NVidia and others are building services. If X is the network transparent answer to rendering why is it not the basis for any of this?
Successful designs experience growth beyond their original niche. Yet after 35 years X remains only the display system for a vanishingly small fraction of the desktop computing world, and an alternative has emerged to displace it even from that.
I don't hate X. I use X heavily every day. But I don't have any illusions about its success or future.
There is an XServer for macOS and it allows me to successfully use proprietary cad tools from the comfort of my mac, without having to login to a centos 6 installation via thinlinc and use some atrocious window manager.
macOS is yet another example where, despite X being present and mature at the time Apple decided how they would render stuff, they went their own way with yet another successful non-network-first design.
Windows Remote Desktop is essentially a perfect remote desktop experience. Being able to walk away from my desktop, login remotely and get fast, properly scaled desktops, and then walk back to that machine and log back in to the same environment is something that can't be efficiently replicated on Linux with X, as far as I know.
Like, you can get "near" the concept - but definitely not there.
I got a far better experience using NX on a slow internet connection many years ago. MS RDP, VNC, TeamViewer or NoMachine modern solutions are really far inferior solutions compared when X was network transparent and some one managed to add async + intelligent cache over it (NX protocol)
The lines have blurred long time ago. RDP also has “draw lines” calls (which have not really been used in ages), and double buffered X client programs (as done in the majority of toolkits for the past 10 years or so) basically transfer only bitmaps these days.
History is different, but practically they have been converging to a similar result.
Yes, but the RDP backend doesn't send them to the client that way anymore (and hasn't for years) - instead, it renders them locally and sends the rendered bitmap.
I've been dreaming about that too, but the way I've thought about it is as built up from text terminals (perhaps starting with sixel?), also replacing the file i/o paradigm.
Hopefully it is just the tone of the writing, but your description of how clipboards work makes it sound like clipboards will still be terrible in Arcan. As a user I no interest whatsoever in a clipboard managers. Basic usage (text from one window to another) is so often frustratingly broken, that if you can fix it, that alone is reason to switch to Arcan. Promise me that when I paste I will see whatever text I just copied, and I will praise your name forever.
It's up to the WM. In Durden, that's how the default works. Advanced management is if you are working with different security domains etc. and need to protect against other clients polluting the clipboard (classic bitcoin address replace attack for instance). Point being that clipboard behavior is WM controlled, not display-server+manager.
I'd appreciate a similar writeup comparing Arcan to Wayland... after a cursory read of the linked article it sounds like a major difference is how window decorations are handled (client vs. server side). Though my Wayland knowledge is probably rather stale by now.
Just having a thorough writeup describing how Arcan and Wayland differ in their overlapping areas would be useful in comparing how their architectures differ.
I understand Arcan is larger in scope than Wayland, but Arcan must have a protocol and architecture behind said protocol that can be meaningfully compared to Wayland's.
The closest you'll get is the the "Clients and Privileges" section, and I much prefer to spend time on "what is" and "what will it become" than comparisons.
Part of the problem is that Xorg is much more well defined in that most can grok "what it is" so there is a point of reference to base an explanation from without 'too much' confusion, there's stuff to work on that isn't IRC logs or mailing list posts which is seriously 90% of Wayland right there.
Wayland is not a "protocol" in the traditional RFC/Jon Postel sense. Heck, even the spec PDF itself referred to itself as a Display Server. There's single X extensions with far more coherent descriptions than all of the Wayland Ecosystem. It's full of overloaded terms and technical WTFs!?. If anything, its the worst parts of Micosoft COM resurrected. An asynchronous Object Oriented IDL. Run for the hills.
Some say it'll fix security issues, it'll fix performance issues, it'll fix world peace -- with barely anyone answering or questioning "how", "why" or "why can't X?". When you counter-argue its feature anaemia it is "oh it's just a protocol, the compositor fixes that" and when you question the feature bulimia it is "oh that's compositor extensions, not the protocol".
Neither position is substantiated by its technical underpinnings, the protocol parts itself, nor the documentation, nor any of the the 'project goals'.
Arcan is a powerful development framework for creating virtually anything between user interfaces for specialised embedded applications all the way to full-blown standalone desktop environments. Boot splash screen? no problem. SCADA HMI for your home? easy peasy. Xorg backend? got you covered. Wayland compositor? sure thing.
At its heart lies a robust and portable multimedia engine, with a well-tested and well-documented interface, programmable using Lua. At every step of the way, the underlying development emphasises security, performance and debugability guided by a principle of least surprise in terms of API design.
From the about page, same site as OP.