It is interesting that something 'not the ultimate window system' can last almost 40 years already, though it also seems like Wayland is getting close to critical mass of adoption?
Wayland is getting close, and is very good indeed, but X is still the default window system. I feel like there are a lot of technologies that are this way. They were not designed to be the best, but good enough, and they have passed the test of time.
Personally I like the modularity of X11 because it has a lot of standardized interfaces. For example, you can exchange the window manager and the compositing manager at runtime without affecting any running programs.
In my opinion X12 should be even more modular and should have even more standardized interfaces. E.g. window decorations should not be tied to a window manager. There should be a standardized way to do toolkits/widgets where the backend and rendering can be swapped at runtime. It should be possible to run headless GUI programs that can be attached and reattached to any running instance of a display server.
John Steinhart though X-Windows could have been a hell of a lot more modular and less complex, and could have been much more simply and modularly designed and better implemented with "less than a dozen API calls":
DonHopkins on May 12, 2018 | parent | context | favorite | on: Build your own X: project-based programming tutori...
Hasn't somebody reimplemented X11 in JavaScript/canvas/websockets yet?
There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly.
"For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm
John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;)
>XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two.
>The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there.
>The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added.
>The bit encodings should be part of a separate language binding, not part of the functional description.
[...]
>X suffers from the same problems as the original Mac API. Scheifler et. al.
didn't really do any system level design and modelling. I know this because
I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that
I have travelled to on business that had no redeeming qualities. He said "I
don't believe in models because they predispose the implementation."
>Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls.
How is that the opposite? Anyone is free to extend the protocol with whatever they want — e.g. wlroots-based compositors have exactly this “standardized way of doing toolkits/widgets”.
The only thing that Wayland standardizes is multi process GPU memory access. Neither GNOME nor KDE (which are far more popular Wayland implementations) use any of the wlroots "standards" and thus they can not really be called as such. Also wlroots does not define one bit about toolkits and widgets.
> Anyone is free to extend the protocol with whatever they want
The protocol itself is very opnionated and strict in some places (especially concerning things like vsync) and completely undefined in other areas where standardization is essential (access control).
AFAIK Wayland in a datacenter still falls back to software rendering and running images through a video codec. I think X is more likely to be replaced by Javascript apps, because those are cross platform and a browser running locally can take advantage of the end user’s GPU.
That's interesting! I love Forth, but I love PostScript even more, because it's so much like Lisp. What is it about PostScript that you dislike, that doesn't bother you about Forth?
Arthur van Hoff wrote "PdB" for people who prefer object oriented C syntax to PostScript. I wrote some PdB code for HyperLook, although I preferred writing directly in PostScript.
DonHopkins on Dec 15, 2020 | parent | context | favorite | on: Source of the famous “Now you have two problems” q...
Leigh Klotz has written more PostScript than Jamie too, while working at Xerox! But "KLOTZ IS A LOGO PRIMITIVE [BEEP BEEP BEEP]". He wrote a 6502 assembler in Logo!
>OK, I think I’ve written more PostScript by hand than Jamie, so I assume he thinks I’m not reading this. Back in the old days, I designed a system that used incredible amounts of PostScript. One thing that made it easier for us was a C-like syntax to PS compiler, done by a fellow at the Turning Institute. We licensed it and used it heavily, and I extended it a bit to be able to handle uneven stack-armed IF, and added varieties of inheritance. The project was called PdB and eventually it folded, and the author left and went to First Person Software, where he wrote a very similar language syntax for something called Oak, and it compiled to bytecodes instead of PostScript. Oak got renamed Java.
>So there.
>And yes, we did have two problems…
>— comment by Leigh L. Klotz, Jr. on June 7th, 2008 at 3:22am JST (12 years, 6 months ago) — comment permalink
Arthur van Hoff (the author of PdB and the original Java compiler written in Java) has also written more PostScript than Jamie, especially if you count the PostScript written by programs he wrote, like PdB and GoodNeWS/HyperNeWS/HyperLook.
Here's the README file (and distribution) of PdB, Arthur van Hoff's object oriented C to PostScript compiler:
>Eventually Arthur left Sun to found Marimba, where he developed the widely used Castanet push distribution technology, and the under-appreciated Bongo user interface editing tool: a HypeLook-like user interface editor written in Java, that solved the runtime scripting extension problem by actually calling the Java compiler to dynamically compile and link Java scripts.
>Nobody else had ever done anything remotely like Bongo before in Java. Dynamic scripting with Java was unheard of at the time, but since he had written the compiler, he knew the API and how the plumbing worked, so had no qualms about calling the Java compiler at runtime every time you hit the “Apply” button of a script editor.
>Danny Goodman’s “Official Marimba Guide to Bongo”
>Danny Goodman, the author of the definitive HyperCard book, “The Complete HyperCard Handbook”, went on to write the “Official Marimba Guide to Bongo”, a great book about Bongo, described as the “reincarnation of HyperCard on the Internet”.
>[TODO: Write about Bongo’s relationship to HyperCard, HyperLook and Java.]
>Java applets are everywhere on Web pages these days, but if you’ve made the move to Java from a contemporary programming environment you’ve probably been dismayed by its relative immaturity. The Official Marimba Guide to Bongo covers Marimba’s Bongo environment, which is designed to allow rapid development of Java user interfaces. The book shows you how to use the large library of graphics “widgets” supplied with Bongo, how to wire them together with simple scripting, and how to integrate other Java applets. It also explains how Bongo can be used to build channels for Marimba’s Castanet system. -Amazon.com Review
>Java users should be rejoicing at the promise of programming aid Bongo, which is is the reincarnation of HyperCard on the Internet. It is fitting that the first major book about Bongo comes from Goodman, the author of the definitive HyperCard book of days gone by (The Complete HyperCard Handbook, Random, 1994). His background is as a journalist, not a technologist, and readers will make good use of this first-rate introduction. This book will circulate. -Library Journal Review
Unfortunately Marimba's Bongo got overshadowed by Sun's announcement of "Java Beans" which Sun was pushing with much fanfare and handwaving as an alternative to "ActiveX", but which eventually turned out to actually be just a server side data modeling technology, not a client gui framework.
Marimba developed Bongo, a Java-based gui toolkit / user interface editor / graphical environment, inspired by HyperCard (and HyperLook), which they used to develop and distribute interactive user interfaces over Castanet.
>Feel the Beat with Marimba's Bongo, By Chris Baron
>In 1996, four programmers from the original Java-development team left Sun to form Marimba and produce industrial-strength Java-development tools for user interface and application administration. Bongo, one of Marimba's two shipping products, allows developers to create either a Java-application interface or a standalone Java-based application called a "presentation." A Bongo presentation resembles a HyperCard stack -- it allows developers to quickly create an application with a sophisticated user interface, but without the tedious programming of directly coding in Java or C/C++. Bongo's nonprogramming, visual approach makes it ideal for producing simple applications that don't involve a lot of processing, such as product demonstrations, user-interface prototypes, and training applications. Bongo is fully integrated with Castanet, Marimba's other product, a technology for remotely installing and updating Java applications.
Bongo was unique at the time in that it actually let you edit and dynamically compile scripts for event handlers and "live code" at run-time (in contrast with other tools that required you to recompile and re-run the application to make changes to the user interface), which was made possible by calling back to the Java compiler (which Arthur had written before at Sun, so he knew how to integrate the compiler at runtime like a modern IDE would do). Without the ability to dynamically edit scripts at runtime (easy with an interpreted language like HyperTalk or PostScript or JavaScript, but trickier for a compiled language like Java), you can't hold a candle to HyperCard, because interactive scripting is an essential feature.
Danny Goodman, who wrote the book on HyperCard, also wrote a book about Bongo. Arthur later founded Flipboard and JauntVR, and now works at Apple.
Here's a paper I wrote comparing Bongo with IFC (Netscape's much-ballyhooped Java Internet Foundation Classes). (Notice how IFC = Internet Foundation Classes was Netscape's answer to MFC = Microsoft Foundation Classes. Never define your product's name in terms of a reaction to your widely successful competitor's name. cough SunSoft cough)
NetScape's Internet Foundation Classes and Marimba's Bongo
>In summary, I think it was too early to write a Java toolkit before JDK 1.1, so IFC has gone and done a lot of its own stuff, which will have to be drastically changed to take advantage of the new stuff. Bongo is not as far down the road of painting itself into a corner like that, and if some effort is put into it, to bring it up to date with the new facilities in Java, I think it will be a better framework than IFC. Java Beans remains a big unknown, that I don't have a lot of faith in. Arthur says Java Beans does too much, and I'm afraid it may try to push competing frameworks like IFC and Bongo out of the limelight, instead of just providing a low level substrate on top of which they can interoperate (like the TNT ClassCanvas). If Bongo can pull off ActiveX integration with style and grace, then it wins hands down, because I doubt IFC can, and I don't trust Sun to deliver on their promises to do that with Java Beans.
It was explained to me by one of Arthur's colleagues at the Turing Institute that PdB stood for "Pure Dead Brilliant" - which indeed it was and the Institute being in Glasgow.
HyperNeWS was definitely one of the neatest systems I have ever worked with.
> What is it about PostScript that you dislike, that doesn't bother you about Forth?
I think it's what we were trying to accomplish. My work with Forth was on Apple II computers while my contact with PostScript was to make printers do things they weren't supposed to do - such as printing fractals - because, for some time, they were the most powerful computers we had at the office.
Apart from that, the syntax seemed awkward for things more complicated than rendering text in predefined positions, but, then, I didn't have any development tools similar to what was available with NeWS (when NeWS was still hot).
I learned FORTH on the Apple ][ too! 6502 FORTH (and others) have a great RPN assembler that is nice for writing the performance sensitive and hardware accessing parts of your program. It was perfect for writing stuff like terminal emulators.
The original LaserWriter was actually a more powerful computer than the Macs that used it, at the time of its release.
Debugging on a laser printer definitely was a challenged, and used lots of paper.
You're right that NeWS made it a lot easier to debug PostScript code interactively without killing trees. It had a command line debugger, but was great for making visual interfaces too! Here's a visual PostScript programming and debugging environment I made with NeWS:
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989
Abstract
The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS.
Was Marimba "push" the inspiration for the expression "This like TV. I don't like TV" going around at the time? I never found out.
"Before co-founding Marimba, [Kim] Polese spent more than seven years with Sun Microsystems and was the founding product manager for Java when it launched in 1995. She also influenced the transition of its internal name of "Oak" to "Java".[11]
"Prior to joining Sun, Polese worked on expert systems at IntelliCorp Inc., helping Fortune 500 companies apply artificial intelligence to solving complex business challenges."
That's a good metaphor. I just wish there was one "official" stable version Electron on all platforms that you could depend on everybody having installed, so instead of shipping huge apps with their own copy of electron, you could just ship little applets in one file (or just a few), like was possible with NeWS.
most webapps have to be updated constantly due to browser changes though, don't they?
if not, would be interesting if there were a protocol for programs to securely serve up front end resources and api endpoints for javascript guis along with a protocol for telling your machine to pop a window and display that gui.
so like the equivalent of an xserver that programs can connect to that pops browser windows and secure plumbing to support it.
I will abandon Linux on desktop after ~20 years if that happens. Once upon a time we had a browser with real color management (firefox)... and lost it. Now it seems that time has come to other things as well.
Not sure about the current state but there was some initiative to implement it. And as far as I know, the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland.
Wayland was released in 2008. In 2008 color management should not be an afterthought for something which entire purpose is to ensure pixels end up on the screen, but rather an integral component.
Having a bunch of pixels with no knowledge of which color space they're in is useless.
You think that color management belongs in the window manager / compositor.
Wayland thinks color management belongs in the app.
The main difference, though, is not this disagreement, but your righteous insistence that your opinion is not an opinion but a very simple obvious fact. I can tell you from having been part of many dev teams of many major app having to do color management that such apps really, really like to be in control.
So no, the lack of color management in wayland is not such an obvious wrong decision. It's debatable, with pros and cons.
My point is, regardless of who does what when it comes to color management Wayland simply cannot be agnostic about it.
At least since it wants to touch pixel data. Alternatively they could have given up on that and never introduced wl_buffer, leaving all the buffer management and drawing up to the client.
edit: At least HDR has finally made Wayland devs wake up and smell the coffee. A good write-up here[1], with ongoing talk in the merge request[2].
Lots of good work going on there, but should be part of core and not an extension. Maybe it's time for Wayland2 soon?
Why does it matter that it is merged into an extension that will become core, or it was already core at inception?
It is hard to get everything right at once, so starting small is not bad, imo. Wayland has a really sane way of extension querying so it is not like clients will suffer due to these — they are already written in a way to query the capabilities.
> Why does it matter that it is merged into an extension that will become core, or it was already core at inception?
> Wayland has a really sane way of extension querying so it is not like clients will suffer due to these
A client shouldn't be able to use Wayland without considering the color space of the pixels it's providing. By not having it in core from day one, there's already apps out there which will need patching to work properly.
Here's[1] a random Wayland hello world example I found. It memcpy's the image it wants to display into a wl_buffer. What color space is that pixel data in? How can this work correctly without changes when the Wayland color management protocol lands?
I am not knowledgeable enough on the topic, but as far as I know X didn’t have a wide-spread way to manage colors either — so I guess clients like that would default to “don’t care about it”, which will translate to some default color space.
Clients that query for this yet theoretical only color space extension can then ask the server for the color balance of the given screen and fill their buffers accordingly. The existing buffer protocol could also be extended to contain information about the color space used for server-side handling of this information, though as the other commenter mentioned, it is best handled by the client, the protocol has to display it only.
> as far as I know X didn’t have a wide-spread way to manage colors either
On the other hand X was created ages ago. Wayland was released in 2008.
> Clients that query for this yet theoretical only color space extension can then ask the server for the color balance of the given screen and fill their buffers accordingly.
Ok, lets say that's how it's done. I set my display to AdobeRGB or BT.2020. My legacy hello world application knows nothing of this just copies its data into the buffer blissfully ignorant of this. If Wayland does nothing more than to display the pixels, the hello world image will look like crap.
Ok, let's say we patch the hello world application, and all the other existing Wayland applications, to respect the output color space. Now I plug in a second monitor which is sRGB, and drag the hello world application over on it. If the hello world application does nothing more, it looks like crap again.
For this to work, it has to be notified it's on a new screen, and fill in new pixel values for the new screen. And every application must handle this or it will look like crap.
I tried looking at how is it done in Apple’s Quartz compositor but couldn’t find it.
But more asking than telling, why wouldn’t defaulting to sRGB for unlabeled buffers work? The compositor knows that this monitor is in C color space, and it knows how to convert between the two, than a simple shader can trivially convert the sRGB hello world app to the monitor’s color space - even in the multiple monitor with different spaces case.
Of course that might not be the intention of the client, but if they didn’t bother with it than they likely are okay with whatever is the default.
Yeah it's the best approach given the current state, and that seems to be what they're going for in the MR.
However you're still in a bit of a mess due to lack of an explicitly documented implicit color space. And it's still a bit of a footgun for developers who don't know they need to care about this.
It's a bit like XML files without the encoding attribute. Except for text you can try to analyze the bytes and find a likely encoding, no such thing for pixel data.
> the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland.
That's a strange way to look at it. It's more like the Wayland folks decided that basically everything of import is out of scope of the protocol. This way any graphical system built on top of Wayland is ridiculously inelegant, but hey, at least there is no responsibility on Wayland itself.
> Once upon a time we had a browser with real color management (firefox)...
I remember that episode... at some point it was basically impossible to display an image that uses the exact same color as some color used in your CSS. Lot's of logos with just the wrong. I'm sure the web platform could be extended to properly support color management in some way, but what Firefox did back than wasn't it.
X is not “network transparent” for any practical definition. Most modern applications don’t use X render commands to draw, so you will get shitload of bitmaps moved over the network, which will result in really bad performance.
Wayland just realized that remoting is not an operation that has to be integrated into the protocol. It can be done by third-party applications better through proper compression techniques.
VNC outperforms it, which is saying a lot since VNC is terrible. Remote x apps were always this selling point in linux culture and I always thought I was doing something wrong because they were so incredibly slow until I realized its the protocol that's just slow.
While common X use evolved way from network (modern apps passing bitmaps around instead of primitives), the network architecture still have one huge advantage over Wayland: it is a client server architecture, so one can restart things without losing state. That is, under X I can crash/restart the DE without losing any application state, open apps continue to run and simply connect to the new instance. But under Wayland any crash anywhere on the stack means all apps are killed and all work lost.
This is not mandated by the protocol — one is free to create a separate server and window manager program under wayland just as well.
But I really don’t find it meaningful — such core functionality should just not crash (just as Xserver itself is not prone to crash, because than your work is also lost).
Not really; there is not a lot of support in the Wayland protocol for multiple clients sharing objects. See for example how difficult it is to emulate XEmbed, systray, wine, etc.
How is that relevant? A client and the server is different processes already. Sharing it between 2 process or 3 is at that point meaningless. (Also, not everything has to be shared to a dumb window manager module)
No, is not really meaningless. Basically, you assume from the server that each relevant object is owned and accessible by 1 client only. If 2 clients want to "own" the same object, they have to coordinate between themselves using an entirely different protocol so that only one client owns the object from the PoV of the compositor (you also can't do it through Wayland since it lacks generic IPC support, which X11 has even if poor). See https://www.winehq.org/pipermail/wine-devel/2021-December/20...
If you want to make a separate window manager, it is likely that the result is going to be incompatible with most existing clients. But this seems par for the course for almost every Wayland extension so far (see Gnome...).
Having more than one mutable reference to the same thing already begets advanced synchronization if that’s what you mean, but I don’t see how is that relevant.
And beside gnome and kde there is a third big group of wayland compositors based on wlroots which does support some form of common set of extensions not in core, effectively making you write only the wm part.
Because this prevents creation of a separate window manager program. You can do all of this with the core protocol in X11. You can't do any of it in Wayland almost by design. The entire idea of a client getting simultaneous access to the objects of another client is not in the protocol. You cannot render in another process surface. You cannot even iterate over its windows! The role of the compositor is hardcoded in the protocol design.
The closest thing you can do is to write some type of modular compositor which speaks _yet another_ protocol with the window manager module (or even exists within the same process). But this is not like in X11, where you plug new things (e.g. a new WM, a new pager) without having to restart the X server, much less having to change it.
that's bullshit. I use Qt apps and they are still in 2022 able to use X11 paint commands to render over the network in a way that is much, much, much more fluid than e.g. rdp, vnc or whatever other bullshit like that. Many GTK apps also seem to work fine (though not all, Geany is snappy while Gimp isn't for instance)
I assume you use it through a local network where it will be reasonably fast. But then please compare it with any sort of “modern” video streaming approach on the same network as well.
here's the exact same case with VNC, on the same network: even with the smaller resolution and lossy image compression, VNC manages to be quite slower than X11
I tried steamlink on the same network to put games on my TV, and it is barely useable with absolutely horrendous image compression (got a GTX1080 GPU so that's likely not the culprit)
RDP also sends draw calls, and as such cannot be compared to VNC or similar. It's not even a remotely close comparison in terms of fluidity. I haven't compared it to Qt over X11, but I wouldn't be surprised if RDP wins over an internet link.
The lack of a proper RDP alternative is the primary reason I don't use Linux as my main driver. I keep checking every 12 months or so, but alas.
RDP is far, far more advanced than X11. In addition to doing "GDI over the wire" much like X11's draw calls, RDP supports compressed bitmaps and streaming video, remote audio, remote file system, remote USB, clipboard sharing, and more recently remote GPU. (Yes, I know about GLX, it's incredibly old and hasn't been updated.)
RDP is to X as PowerShell is to bash: better than the Unix standard thing because it isn't weighed down by Unix community baggage.
Powershell is not at all trash. Being object oriented makes it very easy to do on the fly inspection of your data and allows extremely powerful pipelining. If you want even more functionality, you can load in .NET libraries at runtime. Working with Powershell really feels like working with Python but using a different syntax.
As far as I know NX is just a layer of compression on top of the X11 protocols though, e.g. it uses zlib for compressing paths, jpeg for compressing pixmaps, etc.. Not sure it'd actually help that much on gigabit ethernet.
One part of it (the NXagent) is centered on reducing round-trips rather than compressing the protocol. May not be worth on low-latency links but it is a deal-killer in high-latency ones.
"As [GNOME] is the default Debian desktop environment, Wayland is used by default in Debian 10 and newer, older versions use Xorg by default."
-- https://wiki.debian.org/Wayland
I personally use Arch and GNOME seemed to use Wayland by default without any intervention from me.
Gnome still doesn't support adaptive sync in the Wayland session? KDE does, but last time I tried the Wayland session it had a major bug with display sleep, so I'm waiting for Plasma 5.24 to try it again since it should have some fixes for that.
Wayland is getting close, and is very good indeed, but X is still the default window system. I feel like there are a lot of technologies that are this way. They were not designed to be the best, but good enough, and they have passed the test of time.
i have a hard time liking wayland because they're taking away remoting, which was one of my favorite parts of x.
waypipe is one solution in that realm (i haven't used it myself though). but it's not like x servers and clients will stop working.
Once wayland gets good adoption, people will gradually stop supporting X. That is how it always works in software.
Personally I like the modularity of X11 because it has a lot of standardized interfaces. For example, you can exchange the window manager and the compositing manager at runtime without affecting any running programs.
In my opinion X12 should be even more modular and should have even more standardized interfaces. E.g. window decorations should not be tied to a window manager. There should be a standardized way to do toolkits/widgets where the backend and rendering can be swapped at runtime. It should be possible to run headless GUI programs that can be attached and reattached to any running instance of a display server.
So kind of the opposite of what Wayland is doing.
"X: The First Fully Modular Software Disaster"
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
John Steinhart though X-Windows could have been a hell of a lot more modular and less complex, and could have been much more simply and modularly designed and better implemented with "less than a dozen API calls":
https://news.ycombinator.com/item?id=17056516
DonHopkins on May 12, 2018 | parent | context | favorite | on: Build your own X: project-based programming tutori...
Hasn't somebody reimplemented X11 in JavaScript/canvas/websockets yet?
There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly.
https://news.ycombinator.com/item?id=6864364
"For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm
John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;)
https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047...
https://news.ycombinator.com/item?id=15325226
https://web.archive.org/web/20171028110659/https://minnie.tu...
>XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two.
>The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there.
>The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added.
>The bit encodings should be part of a separate language binding, not part of the functional description.
[...]
>X suffers from the same problems as the original Mac API. Scheifler et. al. didn't really do any system level design and modelling. I know this because I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that I have travelled to on business that had no redeeming qualities. He said "I don't believe in models because they predispose the implementation."
>Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls.
[...]
How is that the opposite? Anyone is free to extend the protocol with whatever they want — e.g. wlroots-based compositors have exactly this “standardized way of doing toolkits/widgets”.
The only thing that Wayland standardizes is multi process GPU memory access. Neither GNOME nor KDE (which are far more popular Wayland implementations) use any of the wlroots "standards" and thus they can not really be called as such. Also wlroots does not define one bit about toolkits and widgets.
> Anyone is free to extend the protocol with whatever they want
The protocol itself is very opnionated and strict in some places (especially concerning things like vsync) and completely undefined in other areas where standardization is essential (access control).
AFAIK Wayland in a datacenter still falls back to software rendering and running images through a video codec. I think X is more likely to be replaced by Javascript apps, because those are cross platform and a browser running locally can take advantage of the end user’s GPU.
Gee, that sounds kind of like the whole point of NeWS. ;)
https://en.wikipedia.org/wiki/NeWS
NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
- used PostScript code instead of JavaScript for programming.
- used PostScript graphics instead of DHTML and CSS for rendering.
- used PostScript data instead of XML and JSON for data representation.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
> - used PostScript code instead of JavaScript for programming.
I'm no fan of JavaScript, but even I would prefer it to PostScript.
And I actually like FORTH.
That's interesting! I love Forth, but I love PostScript even more, because it's so much like Lisp. What is it about PostScript that you dislike, that doesn't bother you about Forth?
Arthur van Hoff wrote "PdB" for people who prefer object oriented C syntax to PostScript. I wrote some PdB code for HyperLook, although I preferred writing directly in PostScript.
https://news.ycombinator.com/item?id=25432748
DonHopkins on Dec 15, 2020 | parent | context | favorite | on: Source of the famous “Now you have two problems” q...
Leigh Klotz has written more PostScript than Jamie too, while working at Xerox! But "KLOTZ IS A LOGO PRIMITIVE [BEEP BEEP BEEP]". He wrote a 6502 assembler in Logo!
https://news.ycombinator.com/item?id=13524588
Leigh Klotz's comment on the regex article:
>OK, I think I’ve written more PostScript by hand than Jamie, so I assume he thinks I’m not reading this. Back in the old days, I designed a system that used incredible amounts of PostScript. One thing that made it easier for us was a C-like syntax to PS compiler, done by a fellow at the Turning Institute. We licensed it and used it heavily, and I extended it a bit to be able to handle uneven stack-armed IF, and added varieties of inheritance. The project was called PdB and eventually it folded, and the author left and went to First Person Software, where he wrote a very similar language syntax for something called Oak, and it compiled to bytecodes instead of PostScript. Oak got renamed Java.
>So there.
>And yes, we did have two problems…
>— comment by Leigh L. Klotz, Jr. on June 7th, 2008 at 3:22am JST (12 years, 6 months ago) — comment permalink
Arthur van Hoff (the author of PdB and the original Java compiler written in Java) has also written more PostScript than Jamie, especially if you count the PostScript written by programs he wrote, like PdB and GoodNeWS/HyperNeWS/HyperLook.
Here's the README file (and distribution) of PdB, Arthur van Hoff's object oriented C to PostScript compiler:
https://github.com/IanDarwin/OpenLookCDROM/blob/master/NeWS/...
Also a paper by Arthur van Hoff about "Syntactic Extensions to PdB to Support TNT Classing Mechanisms":
https://www.donhopkins.com/home/archive/NeWS/PdB.txt
Some before and after examples, like menu.h menu.pdb menu.PS:
https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
menu.h: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
menu.pdb: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
menu.PS: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
GoodNeWS/HyperNeWS/HyperLook:
https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...
pvg on Dec 15, 2020 | prev [–]
Arthur van Hoff (the author of PdB and the original Java compiler written in Java) And the original AWT, if this is to be a full Airing of Sins.
DonHopkins on Dec 15, 2020 | parent [–]
Agreed, AWT was a horrible compromise in an impossible situation! But he made up for it by creating "Bongo" at Marimba.
Bongo is to Java+HyperCard as HyperLook is to PostScript+HyperCard.
https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...
>Arthur van Hoff [...]
>Marimba Castanet and Bongo
>Eventually Arthur left Sun to found Marimba, where he developed the widely used Castanet push distribution technology, and the under-appreciated Bongo user interface editing tool: a HypeLook-like user interface editor written in Java, that solved the runtime scripting extension problem by actually calling the Java compiler to dynamically compile and link Java scripts.
>Nobody else had ever done anything remotely like Bongo before in Java. Dynamic scripting with Java was unheard of at the time, but since he had written the compiler, he knew the API and how the plumbing worked, so had no qualms about calling the Java compiler at runtime every time you hit the “Apply” button of a script editor.
>Danny Goodman’s “Official Marimba Guide to Bongo”
https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/...
>Danny Goodman, the author of the definitive HyperCard book, “The Complete HyperCard Handbook”, went on to write the “Official Marimba Guide to Bongo”, a great book about Bongo, described as the “reincarnation of HyperCard on the Internet”.
>[TODO: Write about Bongo’s relationship to HyperCard, HyperLook and Java.]
>Java applets are everywhere on Web pages these days, but if you’ve made the move to Java from a contemporary programming environment you’ve probably been dismayed by its relative immaturity. The Official Marimba Guide to Bongo covers Marimba’s Bongo environment, which is designed to allow rapid development of Java user interfaces. The book shows you how to use the large library of graphics “widgets” supplied with Bongo, how to wire them together with simple scripting, and how to integrate other Java applets. It also explains how Bongo can be used to build channels for Marimba’s Castanet system. -Amazon.com Review
>Java users should be rejoicing at the promise of programming aid Bongo, which is is the reincarnation of HyperCard on the Internet. It is fitting that the first major book about Bongo comes from Goodman, the author of the definitive HyperCard book of days gone by (The Complete HyperCard Handbook, Random, 1994). His background is as a journalist, not a technologist, and readers will make good use of this first-rate introduction. This book will circulate. -Library Journal Review
Unfortunately Marimba's Bongo got overshadowed by Sun's announcement of "Java Beans" which Sun was pushing with much fanfare and handwaving as an alternative to "ActiveX", but which eventually turned out to actually be just a server side data modeling technology, not a client gui framework.
https://news.ycombinator.com/item?id=21784027
[...]
Marimba developed Bongo, a Java-based gui toolkit / user interface editor / graphical environment, inspired by HyperCard (and HyperLook), which they used to develop and distribute interactive user interfaces over Castanet.
https://people.apache.org/~jim/NewArchitect/webtech/1997/10/...
>Feel the Beat with Marimba's Bongo, By Chris Baron
>In 1996, four programmers from the original Java-development team left Sun to form Marimba and produce industrial-strength Java-development tools for user interface and application administration. Bongo, one of Marimba's two shipping products, allows developers to create either a Java-application interface or a standalone Java-based application called a "presentation." A Bongo presentation resembles a HyperCard stack -- it allows developers to quickly create an application with a sophisticated user interface, but without the tedious programming of directly coding in Java or C/C++. Bongo's nonprogramming, visual approach makes it ideal for producing simple applications that don't involve a lot of processing, such as product demonstrations, user-interface prototypes, and training applications. Bongo is fully integrated with Castanet, Marimba's other product, a technology for remotely installing and updating Java applications.
Bongo was unique at the time in that it actually let you edit and dynamically compile scripts for event handlers and "live code" at run-time (in contrast with other tools that required you to recompile and re-run the application to make changes to the user interface), which was made possible by calling back to the Java compiler (which Arthur had written before at Sun, so he knew how to integrate the compiler at runtime like a modern IDE would do). Without the ability to dynamically edit scripts at runtime (easy with an interpreted language like HyperTalk or PostScript or JavaScript, but trickier for a compiled language like Java), you can't hold a candle to HyperCard, because interactive scripting is an essential feature.
Danny Goodman, who wrote the book on HyperCard, also wrote a book about Bongo. Arthur later founded Flipboard and JauntVR, and now works at Apple.
Here's a paper I wrote comparing Bongo with IFC (Netscape's much-ballyhooped Java Internet Foundation Classes). (Notice how IFC = Internet Foundation Classes was Netscape's answer to MFC = Microsoft Foundation Classes. Never define your product's name in terms of a reaction to your widely successful competitor's name. cough SunSoft cough)
NetScape's Internet Foundation Classes and Marimba's Bongo
https://donhopkins.com/home/interval/ifc-vs-bongo.html
>In summary, I think it was too early to write a Java toolkit before JDK 1.1, so IFC has gone and done a lot of its own stuff, which will have to be drastically changed to take advantage of the new stuff. Bongo is not as far down the road of painting itself into a corner like that, and if some effort is put into it, to bring it up to date with the new facilities in Java, I think it will be a better framework than IFC. Java Beans remains a big unknown, that I don't have a lot of faith in. Arthur says Java Beans does too much, and I'm afraid it may try to push competing frameworks like IFC and Bongo out of the limelight, instead of just providing a low level substrate on top of which they can interoperate (like the TNT ClassCanvas). If Bongo can pull off ActiveX integration with style and grace, then it wins hands down, because I doubt IFC can, and I don't trust Sun to deliver on their promises to do that with Java Beans.
More:
https://news.ycombinator.com/item?id=19837817
>Wow, a blast from the past! 1996, what a year that was. [...]
It was explained to me by one of Arthur's colleagues at the Turing Institute that PdB stood for "Pure Dead Brilliant" - which indeed it was and the Institute being in Glasgow.
HyperNeWS was definitely one of the neatest systems I have ever worked with.
Edit: I also really liked PostScript.
That's right! ;)
http://www.scotranslate.com/translate/scottish/pure-dead-bri...
>pure dead brilliant - Scottish to English : The English translation of "pure dead brilliant" is 1. exceptional 2. fantastic
> What is it about PostScript that you dislike, that doesn't bother you about Forth?
I think it's what we were trying to accomplish. My work with Forth was on Apple II computers while my contact with PostScript was to make printers do things they weren't supposed to do - such as printing fractals - because, for some time, they were the most powerful computers we had at the office.
Apart from that, the syntax seemed awkward for things more complicated than rendering text in predefined positions, but, then, I didn't have any development tools similar to what was available with NeWS (when NeWS was still hot).
I learned FORTH on the Apple ][ too! 6502 FORTH (and others) have a great RPN assembler that is nice for writing the performance sensitive and hardware accessing parts of your program. It was perfect for writing stuff like terminal emulators.
The original LaserWriter was actually a more powerful computer than the Macs that used it, at the time of its release.
Debugging on a laser printer definitely was a challenged, and used lots of paper.
You're right that NeWS made it a lot easier to debug PostScript code interactively without killing trees. It had a command line debugger, but was great for making visual interfaces too! Here's a visual PostScript programming and debugging environment I made with NeWS:
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989
Abstract
The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS.
https://donhopkins.medium.com/the-shape-of-psiber-space-octo...
Was Marimba "push" the inspiration for the expression "This like TV. I don't like TV" going around at the time? I never found out.
"Before co-founding Marimba, [Kim] Polese spent more than seven years with Sun Microsystems and was the founding product manager for Java when it launched in 1995. She also influenced the transition of its internal name of "Oak" to "Java".[11]
"Prior to joining Sun, Polese worked on expert systems at IntelliCorp Inc., helping Fortune 500 companies apply artificial intelligence to solving complex business challenges."
Anybody remember "expert systems"?
Or the Decode-Encode Language:
https://datatracker.ietf.org/doc/html/rfc5
Yeah, I keep saying that Wayland is the replacement for X, but browsers and Electron are the replacement for NeWS.
That's a good metaphor. I just wish there was one "official" stable version Electron on all platforms that you could depend on everybody having installed, so instead of shipping huge apps with their own copy of electron, you could just ship little applets in one file (or just a few), like was possible with NeWS.
most webapps have to be updated constantly due to browser changes though, don't they?
if not, would be interesting if there were a protocol for programs to securely serve up front end resources and api endpoints for javascript guis along with a protocol for telling your machine to pop a window and display that gui.
so like the equivalent of an xserver that programs can connect to that pops browser windows and secure plumbing to support it.
export WEBDISPLAY=localhost:0 myjavascriptterminalemulator &
That's not where it stops... wayland was designed without giving any thought to color management at all. Beware, long read ahead, not happy ending: https://discuss.pixls.us/t/wayland-color-management/10804
I will abandon Linux on desktop after ~20 years if that happens. Once upon a time we had a browser with real color management (firefox)... and lost it. Now it seems that time has come to other things as well.
https://www.collabora.com/news-and-blog/blog/2020/11/19/deve...
Not sure about the current state but there was some initiative to implement it. And as far as I know, the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland.
Wayland was released in 2008. In 2008 color management should not be an afterthought for something which entire purpose is to ensure pixels end up on the screen, but rather an integral component.
Having a bunch of pixels with no knowledge of which color space they're in is useless.
You think that color management belongs in the window manager / compositor.
Wayland thinks color management belongs in the app.
The main difference, though, is not this disagreement, but your righteous insistence that your opinion is not an opinion but a very simple obvious fact. I can tell you from having been part of many dev teams of many major app having to do color management that such apps really, really like to be in control.
So no, the lack of color management in wayland is not such an obvious wrong decision. It's debatable, with pros and cons.
My point is, regardless of who does what when it comes to color management Wayland simply cannot be agnostic about it.
At least since it wants to touch pixel data. Alternatively they could have given up on that and never introduced wl_buffer, leaving all the buffer management and drawing up to the client.
edit: At least HDR has finally made Wayland devs wake up and smell the coffee. A good write-up here[1], with ongoing talk in the merge request[2].
Lots of good work going on there, but should be part of core and not an extension. Maybe it's time for Wayland2 soon?
[1]: https://ppaalanen.blogspot.com/2020/11/developing-wayland-co...
[2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
Why does it matter that it is merged into an extension that will become core, or it was already core at inception?
It is hard to get everything right at once, so starting small is not bad, imo. Wayland has a really sane way of extension querying so it is not like clients will suffer due to these — they are already written in a way to query the capabilities.
> Why does it matter that it is merged into an extension that will become core, or it was already core at inception?
> Wayland has a really sane way of extension querying so it is not like clients will suffer due to these
A client shouldn't be able to use Wayland without considering the color space of the pixels it's providing. By not having it in core from day one, there's already apps out there which will need patching to work properly.
Here's[1] a random Wayland hello world example I found. It memcpy's the image it wants to display into a wl_buffer. What color space is that pixel data in? How can this work correctly without changes when the Wayland color management protocol lands?
[1]: https://github.com/emersion/hello-wayland/blob/master/main.c...
I am not knowledgeable enough on the topic, but as far as I know X didn’t have a wide-spread way to manage colors either — so I guess clients like that would default to “don’t care about it”, which will translate to some default color space.
Clients that query for this yet theoretical only color space extension can then ask the server for the color balance of the given screen and fill their buffers accordingly. The existing buffer protocol could also be extended to contain information about the color space used for server-side handling of this information, though as the other commenter mentioned, it is best handled by the client, the protocol has to display it only.
> as far as I know X didn’t have a wide-spread way to manage colors either
On the other hand X was created ages ago. Wayland was released in 2008.
> Clients that query for this yet theoretical only color space extension can then ask the server for the color balance of the given screen and fill their buffers accordingly.
Ok, lets say that's how it's done. I set my display to AdobeRGB or BT.2020. My legacy hello world application knows nothing of this just copies its data into the buffer blissfully ignorant of this. If Wayland does nothing more than to display the pixels, the hello world image will look like crap.
Ok, let's say we patch the hello world application, and all the other existing Wayland applications, to respect the output color space. Now I plug in a second monitor which is sRGB, and drag the hello world application over on it. If the hello world application does nothing more, it looks like crap again.
For this to work, it has to be notified it's on a new screen, and fill in new pixel values for the new screen. And every application must handle this or it will look like crap.
I tried looking at how is it done in Apple’s Quartz compositor but couldn’t find it.
But more asking than telling, why wouldn’t defaulting to sRGB for unlabeled buffers work? The compositor knows that this monitor is in C color space, and it knows how to convert between the two, than a simple shader can trivially convert the sRGB hello world app to the monitor’s color space - even in the multiple monitor with different spaces case.
Of course that might not be the intention of the client, but if they didn’t bother with it than they likely are okay with whatever is the default.
> But more asking than telling, why wouldn’t defaulting to sRGB for unlabeled buffers work?
If Wayland is to do color management, that's a reasonable approach. Doesn't work at all if the client is supposed to do it.
But are you sure Wayland uses sRGB now? I couldn't find any information regarding the implicit color space currently used by Wayland...
> but if they didn’t bother with it than they likely are okay with whatever is the default
Not like they had a choice now is it?
I don’t think it has any implicit color space in use right now, I mentioned/asked for confirmation whether this approach could work.
Yeah it's the best approach given the current state, and that seems to be what they're going for in the MR.
However you're still in a bit of a mess due to lack of an explicitly documented implicit color space. And it's still a bit of a footgun for developers who don't know they need to care about this.
It's a bit like XML files without the encoding attribute. Except for text you can try to analyze the bytes and find a likely encoding, no such thing for pixel data.
> the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland.
That's a strange way to look at it. It's more like the Wayland folks decided that basically everything of import is out of scope of the protocol. This way any graphical system built on top of Wayland is ridiculously inelegant, but hey, at least there is no responsibility on Wayland itself.
> Once upon a time we had a browser with real color management (firefox)...
I remember that episode... at some point it was basically impossible to display an image that uses the exact same color as some color used in your CSS. Lot's of logos with just the wrong. I'm sure the web platform could be extended to properly support color management in some way, but what Firefox did back than wasn't it.
X is not “network transparent” for any practical definition. Most modern applications don’t use X render commands to draw, so you will get shitload of bitmaps moved over the network, which will result in really bad performance.
Wayland just realized that remoting is not an operation that has to be integrated into the protocol. It can be done by third-party applications better through proper compression techniques.
VNC outperforms it, which is saying a lot since VNC is terrible. Remote x apps were always this selling point in linux culture and I always thought I was doing something wrong because they were so incredibly slow until I realized its the protocol that's just slow.
It was fine until apps ended up doing everything on their end and push pixmaps to the X server. Back in the xaw and motif days, it was fine.
Well yeah, but then you could just as well use an ncurses app through ssh for the same “experience”
While common X use evolved way from network (modern apps passing bitmaps around instead of primitives), the network architecture still have one huge advantage over Wayland: it is a client server architecture, so one can restart things without losing state. That is, under X I can crash/restart the DE without losing any application state, open apps continue to run and simply connect to the new instance. But under Wayland any crash anywhere on the stack means all apps are killed and all work lost.
This is not mandated by the protocol — one is free to create a separate server and window manager program under wayland just as well. But I really don’t find it meaningful — such core functionality should just not crash (just as Xserver itself is not prone to crash, because than your work is also lost).
Not really; there is not a lot of support in the Wayland protocol for multiple clients sharing objects. See for example how difficult it is to emulate XEmbed, systray, wine, etc.
How is that relevant? A client and the server is different processes already. Sharing it between 2 process or 3 is at that point meaningless. (Also, not everything has to be shared to a dumb window manager module)
No, is not really meaningless. Basically, you assume from the server that each relevant object is owned and accessible by 1 client only. If 2 clients want to "own" the same object, they have to coordinate between themselves using an entirely different protocol so that only one client owns the object from the PoV of the compositor (you also can't do it through Wayland since it lacks generic IPC support, which X11 has even if poor). See https://www.winehq.org/pipermail/wine-devel/2021-December/20...
If you want to make a separate window manager, it is likely that the result is going to be incompatible with most existing clients. But this seems par for the course for almost every Wayland extension so far (see Gnome...).
Having more than one mutable reference to the same thing already begets advanced synchronization if that’s what you mean, but I don’t see how is that relevant.
And beside gnome and kde there is a third big group of wayland compositors based on wlroots which does support some form of common set of extensions not in core, effectively making you write only the wm part.
> but I don’t see how is that relevant.
Because this prevents creation of a separate window manager program. You can do all of this with the core protocol in X11. You can't do any of it in Wayland almost by design. The entire idea of a client getting simultaneous access to the objects of another client is not in the protocol. You cannot render in another process surface. You cannot even iterate over its windows! The role of the compositor is hardcoded in the protocol design.
The closest thing you can do is to write some type of modular compositor which speaks _yet another_ protocol with the window manager module (or even exists within the same process). But this is not like in X11, where you plug new things (e.g. a new WM, a new pager) without having to restart the X server, much less having to change it.
that's bullshit. I use Qt apps and they are still in 2022 able to use X11 paint commands to render over the network in a way that is much, much, much more fluid than e.g. rdp, vnc or whatever other bullshit like that. Many GTK apps also seem to work fine (though not all, Geany is snappy while Gimp isn't for instance)
see how it looks: https://streamable.com/t9foij
I assume you use it through a local network where it will be reasonably fast. But then please compare it with any sort of “modern” video streaming approach on the same network as well.
here's the exact same case with VNC, on the same network: even with the smaller resolution and lossy image compression, VNC manages to be quite slower than X11
https://streamable.com/50fdss
I tried steamlink on the same network to put games on my TV, and it is barely useable with absolutely horrendous image compression (got a GTX1080 GPU so that's likely not the culprit)
> much more fluid than e.g. rdp, vnc or whatever
RDP also sends draw calls, and as such cannot be compared to VNC or similar. It's not even a remotely close comparison in terms of fluidity. I haven't compared it to Qt over X11, but I wouldn't be surprised if RDP wins over an internet link.
The lack of a proper RDP alternative is the primary reason I don't use Linux as my main driver. I keep checking every 12 months or so, but alas.
> RDP also sends draw calls
on linux with native linux apps ?
I haven't checked in a few years, but I imagine they haven't implemented that yet given how tightly RDP draw calls maps to the GDI.
Point was that RDP in its natural environment can forward draw calls, and as such is more like X than VNC.
RDP is far, far more advanced than X11. In addition to doing "GDI over the wire" much like X11's draw calls, RDP supports compressed bitmaps and streaming video, remote audio, remote file system, remote USB, clipboard sharing, and more recently remote GPU. (Yes, I know about GLX, it's incredibly old and hasn't been updated.)
RDP is to X as PowerShell is to bash: better than the Unix standard thing because it isn't weighed down by Unix community baggage.
Eh, no. PowerShell is trash. And instead of Bash I prefer ksh and for anything more complex, perl, which curb-stomps PowerShell by large.
Also, you were right on RDP, but something less is more.
If any, I prefer plan9/9front's drawterm/cpu which runs circles over Unix/Linux VNC and RDP. By a huge mile.
And 9p>>>>>>>> NFS/SMB. For anything else, use FS' permissions FFS, and choose wisely what you share.
Powershell is not at all trash. Being object oriented makes it very easy to do on the fly inspection of your data and allows extremely powerful pipelining. If you want even more functionality, you can load in .NET libraries at runtime. Working with Powershell really feels like working with Python but using a different syntax.
You have PERL REPLs like that with Task::Kensho leaving out PSH and .Net libraries on the dust.
What you could do today with PSH and iPython Perl folks did that before with far more modules thanks to CPAN and C bindings.
> If any, I prefer plan9/9front's drawterm/cpu which runs circles over Unix/Linux VNC and RDP. By a huge mile.
How can this [1] code possibly be faster than modern hardware accelerated blitting? I don't see a line of SIMD in there.
[1]: https://github.com/9fans/drawterm/blob/master/libmemdraw/dra...
Call me odd, but 9front on native machines looks smoother than most composited desktops here.
composited WMs are so frustrating to use when you're used to non-composited
GLX is not much older than RDP and has also been updated several times.
Don't forget NX protocol. It's far more faster and lightweight that VNC/RDP.
As far as I know NX is just a layer of compression on top of the X11 protocols though, e.g. it uses zlib for compressing paths, jpeg for compressing pixmaps, etc.. Not sure it'd actually help that much on gigabit ethernet.
One part of it (the NXagent) is centered on reducing round-trips rather than compressing the protocol. May not be worth on low-latency links but it is a deal-killer in high-latency ones.
Note that Qt5 does not send paint commands by default, it sends bitmaps. You need a special env var to revert to drawing commands.
Debian uses Wayland by default these days.
"As [GNOME] is the default Debian desktop environment, Wayland is used by default in Debian 10 and newer, older versions use Xorg by default." -- https://wiki.debian.org/Wayland
I personally use Arch and GNOME seemed to use Wayland by default without any intervention from me.
Gnome still doesn't support adaptive sync in the Wayland session? KDE does, but last time I tried the Wayland session it had a major bug with display sleep, so I'm waiting for Plasma 5.24 to try it again since it should have some fixes for that.
What's pretty wild is it took 3 years to reach X11, and that's where we're at, although there have been a bunch of revisions.