You are not logged in.
$ sudo apt-cache show stumpwm
Package: stumpwm
Version: 2:22.11-3
/usr/share/doc/stumpwm/NEWS:
* Changes since 0.9.6
** in float mode windows can be resized with the middle mouse button
....
And while StumpWM is running Prefix + v gives : 1.0.1 compiled at January 2024.
So what is the 2:22.11-3 for ?
Also the version i use has various bugs . If anyone has managed to compile (or wants to) the latest
version please tell me to help each other.
-------------------------------- my compilation effort
$ dpkg -L stumpwm
/usr/bin/stumpwm // that is the stumpwm binary from the package Version: 2:22.11-3 in Daedalus.
Following the instructions more closely in the github page i managed to compiled.
I think it crucial to install a linux sbcl binary from the sbcl project page as instructed
and follow the instructions from there.
After installing the sbcl binary and loading to it the libraries needed we
compile the stumpwm src :
$ git clone https://github.com/stumpwm/stumpwm.git
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
'/usr/local/bin/stumpwm' is the directory that will be installed if we compile the github sources.
We put that path in .xinitrc and we are ok
-----------------------------------------
Of course that leaves a bitter taste in my Devuan admin mouth. The package 'stumpwm' can not work with sblc devuan package and that result in an older version running? And thus instead of 22.11-3 we get 1.0.1 ?
----------------------------------------
StumpWM main page
Debian tracker / StumpWM
I wouldn't be so hasty to focus my attention to synthetic AI-driven bio-engineering. I dont trust the extremely well oiled (with billions) hype engines that trigger massive diversion of public or shareholders money and value to exciting new techs that instigate FOMO feelings to the public and to the investors while more pressing ecological and society problems get under the radar . On the contrary that attention diversion highlights the great power imbalance and pathological power concentration on the mass media , and mass social platforms.
Can we really entrust our future to companies that build their fortunes on parent's money for pc room-cell gaming? Last time i checked farmers in Taiwan were suffering in order to sustain the water-hungry TSMC. Can we trust steam to guide the future of the display server??
That's one reason that i prefer more often to look back . Like in How X started..
Touche! big_smile
Seems I hit a nerve. FWIW . . . the rage quit and deletion was completely unnecessary and deprives the forum of your thoughts which had value historically if not practically.
Are you answering ? Or fueling with more facts the nonpoliteness that i attributed to you ?
Oh is that all! So easy to say. So useless to say. Show us the fork YOU are going to initiate and we will take your babblings seriously. Hot air does nothing but add to our collective climate woes. wink
I hope you can make sense of what you write. Because it seems to me that your response except from lacking politeness is also so easy to say and so contradictory to say.
My 'babblings' will get elevated to not 'babbling' status when i present in front of you code ?
Show me your code ? That is the babbling status elevator ? Really ? That old opensource mentality ?
Have you read my arguments? Who drives Wayland developemt ? How 386 arch opensourced X11 started?
Have you tried to answer 'Why no X11 fork exists?' And lastly have you pondered how ethical are the gaming money?
And i guess all other comments on an offtopic thread have pass you babbling status filter.
Even comments that promote possibly false inflammatory dichotomies X vs Wayland .
I guess you intend to program the heck out a harmonious libre community since last time i checked politeness
hasnt been incorporated in any existing programming language.
I'd like to remind my relative posts ;
How X started
Copy paste , a hard problem?
A very short recap of my current understanding is that historically speaking a Display Server (DS) is a concept broader than a rendering frame perfect protocol. And than Wayland can be seen as an improvement in the a DS's RP (Rendering Protocol) and not as a replacement of X11. Why ?
Because X11 was a DS with network-centric nature from day one. So i think posing Wayland as X11 replacement creates confusion and harm.
For those interested in detailed arguments in favor of my claim you could read my posts where is the results of days digging in the web for X and x386 history.
As for the future..
I am pessimistic too. But not only of X . I am pessimistic of Steam and Codeweavers too . PC - roomcell gaming is a selfdefeating aim. Contradictory .I am also pessimistic of the perfect frame goal.As Wittgenstein would said every construction is a short of a prison. And i guess prisons, how matter fanciful ,after a while they start to suck more and not suck less.
Game money and gpu money is currently in the driving seat. That could end . I think , as in the X case , the 'new' wont came from the hackers . They look blind sometimes. It will come from society new needs. BUT i think in order for libreIT world to respond quiclly to those needs X11 networking and platform - vendor independence spirit must be kept alive.
Lastly , i think it very basic discussing about X and Wayland to answer why there is not a fork ? Isnt that supposedly the spirit of libresoftware that shines ? Could it be that Wayland is a fork ? And then the case is simple. One group of people must step forward and do another fork focusing not on the rendering site but on the network centric side. And that means proposing a common standard - protocol for remote - desktop , remote graphics . And remote-network-graphics cant be frame perfect. They must be typed and semantically sound. A pixel or mime cant be a sound type for that kind of remote computing, And you cant have either one type-system. You must be able to accommodate many.
2D drawing primitives that almost nobody uses because these days most programs render directly to buffer instead, or use the GPU's 3D rendering functions.
You mean that certain set of 2d primitives is outdated or the idea of a network centric DS having 2D primitives is outdated?
I think indeed an ethics purist could vanish form nigthmares because before even purchasing a motherboard s(he) must eat. And i guess many we are still eating meat and i do believe that animals could have consciousness. Let's not start on what entities funded the internet..
So i prefer practical ethics. Meaning , that in a community with certain objectives if alternatives do exist and have been weighted and there is a consensus that choiceA promotes those objectives then the community should encourage by various means that choice .
So in that path of practical ethics in IT space , i think that there are alternatives to google . I try to use searx instances and in my kid's pc runs only Devuan + netsurf with wikipedia as search engine. Ofcourse i am not sure as to how much a metasearch that uses google search can be valued as an alternative or as a facelift. Anyway even more i value the fediverse alternatives.
But speaking of google.. i think the surface is way to more slippery that we can imagine .
Many libre-land organizations and projects have been funded by it. Even FSF has dipped it's fingers in the sponsor's honey pot. And then.. if we start that discussion i think it unavoidable to discuss the donation's ethics . And my opinion is that on that issue the surface has been more than slippery.
So slippery that a couple of years ago almost all know libre-land organizations that had been practising happy sponsor hunting from google, microsoft , redhat etc were willing to hump on on the RMS lynch bandwagon in a witch-hunt that acted also as a much needed distraction of the funding scandals from eipstein that had shaken from the ground the MIT!.. So ethic wise the libreland's most prominent organizations seems to me in such a bad shape that they are in danger to be tagged as a Grace Field House in the Promised Neverland manga..
How else to call organizations that under a freesoftware flag promote google hacker initiation events. (now this is getting also political!!..because the power that google has amassed makes it eventually a political entity..and politics are too much heated those days...).Or how else to call organizations that under a libreland flag call has github as sponsor , lay roses for programmers to use that forge and then we realize that the AI agenda needed fresh ideas to feed upon..
As to the hardware i think projects like MNT reform show the way forward and open risc architectures seem a good alternative too.
And last but by far not least.. we should discuss also the gaming ethics. Empires,fortunes and mega-egos have being build on gaming , and even nvidia that promotes itself in the well-oiled hype engines as futuristic AI -cloud company , a solid argument could be made that the kid's parent's purse have being the humble (but ethicwise questionable) fuel of those mega-ambitions. I think gaming is the elephant in the closet that nobody dares to touch and surely that closet has monsters in various forms.
I think minimalist can mean not only the code size but also the graphical elements . Both meanings have be mentioned in that thread. I dont pay much attention to the code size because in my case it doesnt make a difference. On the other hand if a wm in the spirit of X offers maleability and less policy,that could help in creating more interesting workflows..
Speaking of workflows, a supervisor is needed to manage automated workflows. For those interested, the user-workflow supervisor idea 's theoretical exploration (user runit) has been discussed in the elist.
In my case interesting workflows would need support of multi-tagging of windows among other things.
Also speaking of maleability ,X allowed me to pass in a couple of minutes from i3 to testing StumpVM.
So 1983's X DisplayServer project legacy seems to me to favor recombinations . I wonder , evolutionary speaking , in software terms, if Wayland's more integrated style that binds a DS's rendering protocal (DS's RP) and a certain WM and call that DS is going to be fruitfull in the long run..
I say DS's RP because as i have proposed in another thread Wayland is a project that doesnt align with X's 1983 legacy , philosophy, incubator enviroment ,and generaly it's dna. That misalignment is painted in the most striking colors in some presentations in the www that present X as a project that has been stagnated in a bad IPC layer. But i propose a different intepretation. That instead ,the Wayland project represents , if not a stagnation, a narrowing in the scope of a network-centric DS that the Athena X project represented.
Wayland is a notable effort to improve the rendering protocol but by various circumstances of fate , it promotes it self , falsely, as successor to X11 . But if you study the project history, easily, we can see that x386 - xfree86 and xorg represent groups focused only on one aspect of the DS protocol stack.
Thus i think it's more fair to say that Wayland it's an extension or a DS's RP fork. I would like to being able to use Wayland compositors but as co-operating components - extensions of a X12 or Y project that promotes and improves while at the same time aligns and respects the initial unix-centric network-centric philosophy of Athena's X.
I try last days stumpwm. I think it was inspired by ratpoison but they wanted it to run on common lisp.
It certainly seems minimal as quickfur describes.
quickfur doesn't your argument applies to every aspect of a display protocol ?
if wayland specifies a protocol for committing pixel perfect frames, it would still be up to the relevant applications to implement it in a sane way before it would work. If one of the authors is lazy and decides to just ignore it, or implement it minimally then you'd get various screen artifacts
A protocol is a contract . To be of any use the programmers must study it and use it. A lazy programmer would use could use it wrongly.
So i think we could make a DS protocol with perfect copy paste. And it would be a perfect copy paste desktop for those apps that conform to the protocol rules.
Now we are in a situation that i hear horror stories of a user that must know what apps run on xwayland and what not in order to predict if copy paste or drag and drop would work.
So we have a pixel perfect desktop BUT it seems that 'we' miss something essential . And that essential could be a problem not amenable to hackers skills but out of their reach. That's an idea that i explored for days in my post How X started.. .
I mean the speed by which X was used and prospered is in great contrast with what is happening with Wayland. Wayland is not X. Shouldnt be seen as a display server protocol DSP replacing X but either as a pixel perfect extension or as another type of display protocol aiming perfecting a certain aspect of the a display protocol.
I personaly think wayland is not a DSP. Wayland is a DSP's perfect frame component.
All those companies and institutions that are in the remote desktop 'business' i think would agree. They all implement various free or proprietary protocol to share desktop rendered data across various networks. (the initial X use case) . So those are protocol controlling display data sharing. There we are.
Display Server Protocols chassing a differerent rabit hole!..
A DSP must encompass more. For me a generic DSP needs a RenderingProtocol (RP) But the RP cant be the DSP .
So i think 'we' the IBM-PC clone era architecture users are getting dangerously close to the 80's !!.
Back then we did have again x86 PCs. And we used various 'display servers' . But 1) they were proprietary 2). they were aligned closely to a pc desktop not-networked view of computing .
ps: I just realized that another issue i have with firefox in sway could be also related to copy-paste problem. I cant drag and drop links inside bookmark menus . Something that i was doing the last years . On top of that i cant copy paste text to the 'foot' wayland terminal from many of my favorite apps.
I'm not blaming. I just say that although you have a difficult issue you prioritize the perfect frame .
Isnt it essential, to productive desktop workflows, to have desktop apps exchange data ?
In my devuan+sway installation indeed i dont see graphically speaking anything buggy but i cant copy paste simple text between some apps breaking my workflow.
And isnt it the essence of a DS protocol to laydown some rules for the clients . And the clients should coooperate in order to use the DS's services and resources ?
So my question is could a protocol BOTH apply rules to committing pixel perfect frames AND enforcing data exchange protocols ?
An tty-analog example could be Unix. To have pipes in Unix a unix pipe-friendly program must follow some conventions. Use stdout by default , use ascii. If a program decides to write to the console not in ascii but in a finer-grained private encoding then doesnt that brake the pipe ?
Also isnf a legitimate display server functionality to enforce certain type-constraints on data written to it's graphical memory so that sharing could be easily exposed to it's client as a service? (generally type constraints have also a security bonus).
Shouldn't also the integration of the window manager in the display-server compositor made the matter easier for wayland (if there isnt not any protocol inherited constraints) ?
In X11 you have 4 parties involved: X11,windows manager, target app, source app
I came across on the web of discussions (1) on how difficult is the implementation
of copy paste and drag and drop on Wayland.
I wonder .. is copy paste a hard problem ? Or is it possible when you lay down the
architecture of a display server targeting perfect frames your construction becomes
hostile to copy paste ?
What information do you loose when 'you' as a Display server you let every app
draw whatever they want how ever they want on their private frame buffers?
So 'you' don't have the faintest clue
of what the apps graphically do.
To the graphical memory you guard
bits and pixels play their card.
------ refs
(1) discussion ref1 (2010)
discussion ref2 (2021)
wayland-clipboard-drag-and-drop/
Synchronizing the X11 and Wayland clipboard
copy-paste-from-firefox-88-0-1-not-working-properly-on-ubuntu-21-04
(2) Discussion on X's copy paste (2010)
Regarding the relation of a display server and a kernel i found some interesting ideas in a design article
about Whitechapel MG-1 's windowing system:
One of the major problems in the design of a window management system for a Unix operating system is that of determining the degree of functionality to embed in the kernel. Ideally, very little of the window management system would be represented in the operating system kernel; but because of the inadequate inter process communication mechanisms and susceptibility to scheduling delays under heavy load such a system would not offer fast enough feedback for a good user interface.
Now compare that thinking with the VS100 -thin- workstation leaflet :
You already own the best possible foundation for a technical workstation - a VAX computer. The VAXstation 100 workstation terminal is a subsystem you can add to your VAX system as a low-cost practical alternative to a stand-alone workstation.
I read in the news that X seems to be getting into the freeze. By studying X's history(0) i think a better phrasing would be:
'Certain companies , developers and maintainers' of Xorg X11 implementation are switching their focus and energy
from X11 to Wayland' . I think that phrasing is more just because X doesnt seem to me that is a certain person(s)'s project
as it is presented usually in many news articles that seem historically blind. X has a long long history that isnt rooted only on a certain
coorporation's agenda to grab a market. So i think with great care that history should be studied in order to better understand the present.
So in that spirit i found and old paragraph on the book The Joy of X by Nial Mansfield (1993) that i found it interesting and helpful in giving us a better persective on what X is :
1.4 How X compares with other systems :
Microsoft Windows for DOS give you a true windowing system on PC with a consistent GUI,and multiple applications which can be more or less active simultaneously. Like X is not part of the operating system,but is a separate optional piece of software which you run on top of the operating system.
It differs from X in two important ways:
1. The user interface is fixed and build into the system, so you cannot change it. For example , if you wanted to emulate the Macintosh interface, you just can't do it with MS Windows.
2. You can only run local applications ,which means that you can only use applications written for DOS PCs. You cannot compile a program for VAX VMS , say , with the Windows GUI built into it, and run it on the VAX displaying to your PC.
That quote first highlights that initially the MS Windowing system was not part of the main OS (DOS) . That it's interesting because lately (1) i was troubled about the relation that a Display Server can have with an OS. And looking back we see that computational functionality doesnt belong somewhere by it's nature. The relation that X or MS Windows's windowing system has with a OS are fluid and susceptible to human and organizational needs.
Initially there was MS DOS and the first windowing system on it was VisiOn(1983) and Windows 1.0.
Secondly that quote highlights that what once was presented as a strength not available at other OSes (network transparency ,policy-free, separation from the OS -OS independence - ) now there are presented as flaws that must be get rid of. But by doing that.. in a similar future comparison would that put a Linux windowing system more close to the MS view of how and where a windowing system works ?
Could it be that X is a functionality nucleus suitable for a distributed-network and flexible centric-view of computing and by abandoning it libre software community is loosing a gift that was once handed to it ?
Wouldnt it be better to have both Wayland view on what a windowing system is and X's views ?
(0) How X started?
(1) Should a display server contain a drawing API ?
Thinking it a little more i think i can try a first answer to one of my questions:
Also what is the relation of NHDS to the kernel ?
Sure NHDS must access OGDDs . But does it need something more? Access to memory ? To filesystem ? But if kernel controls access to memory how GM is different ? Isn't it memory ? Isn't that strange ? Kernel mediates and supervise access to memory to hundreds of processes and GM supervision could be NOT part of the kernel ?
If we assume that each user has his own graphical workstation with certain resources then we could say that the X server is a part of distributed OS . Lets call it Z !
The reason X wasn't part of an OS at the start and afterwards could be that it was running closer to the resources that it was meant to supervise.
But we could draw new imaginary user-kernel boundaries and imagine that a user program calls a distributed OS's (Z) services to access an Xtty . And Z would initiate calls to its X part running at a remote workstation . Like drawpolyarc(x,z..,IDwindow,IPworkstation).
Also in project Athena they wanted that part (X server) to be independent of the OS of the available IBM and DEC workstations. So there lies the second part of my answer:
The weak to non-existent organization-integration coupling of two OS is manifested in the weak integration (towards either or those OSes) of a new software component that must work with both of these OSes.
So my guess is that all those 'merits' that were advertised back then for X (device independence, minimal dependence of server,network transparency) cant be part of Wayland not because of technology efforts but because of organizational issues .
All that effort that was put in Project Athena , ( ref2 , ref3 ) to coordinate MIT,DEC,IBM and infuse in the project a future flexibility in integration with various third party systems can not be found in the efforts and motives that initiated the Wayland project.
One the one hand i feel an aura or coolness towards X and its "environment" that gave rise to it. But i see that even MIT Athena has move to other Virtual Desktop solutions instead of trying an X12 or Z solution.
So i guess that the libre community must try to maintain X and keep it's culture alive. Wayland is a solution that maybe needed for a desktop centric view of personal computing but it maybe not the road that must be taken for a networked-interconnencted approach . Maybe X can find a better home inside a push for distributed-micro-kernel OSes.
GM: Graphics Memory
NH-DS : NucleusHarmonyDisplayServer
OGDD: Output Graphics Device Driver
First there was : VGTS by Nowicki et al [1] Partitioning of Function in a Distributed Graphics System William I. Nowicki
Then W. W is a bit mysterious as not much public information exist on internet. But from the quote below two persons are credited for W ,Paul Asente and Chris Kent.
We acquired a UNIX based version of W for the VS100 (with synchronous communication over TCP produced by Paul Asente and Chris Kent at Digital’s Western Research Laboratory.
But if W was ported to the DEC's VAX-11 computers in order to be used with the VS100 (which was a graphic terminal) from the V operating system then what was the use of Workstation Graphics Architecture documented in document on WGA from Henry M. Levy who for 8 years from 1975-1983 was Engineer at VAX/VMS ? I get a satoshi vibe on W..
It could be that W is just the initial letter of Workstation Graphics Architecture created for DEC's VS100 ? Maybe Henry M. Levy created W and Paul Asente[ and Chris Kent did the porting of W to Unix (because DEC was also selling a Unix like OS? All three were working at DEC ..
Paul Asente was also involved later in the X toolkit development. (see also X Toolkit Intrinsics - C Language Interface. )
The Western Research Laboratory (WRL) was a computer systems research group that was founded by Digital Equipment Corporation in 1982.
(1983) In May 1983 MIT announced the establishment of a five-year program to explore new innovative uses of computing in the MIT curriculum. This program was Project Athena.
Aside from educational goals additional technical objectives were:
- support of a heterogeneous hardware configuration
- provide a user interface independent of hardware.
- provide a software development enviroment independent of hardware
- maximize the exportability and importability of hardware
Also one umbrella requirement was that the system created should have ''coherence'' . Coherence meant that Athena should act as unifying glue allowing sharing of computational resources . That need couldnt but lead to the requirement for indepedence. So we could say that Athena had in it's dna a distributed soul since it mean to unify diverse computational resources across a networked campus.
Michael Dertouzos is credited for that idea . Dertouzos was also Director of MIT/LCS and is also credited as one of the heads that initiated and supported Project Athena..
It's interesting also to note that for some applications( Athena Laboratory Data System ) the 'coherence' requirement was abandoned and the Unix thin workstation couldn't meet real time requirement of certain hardware (multiple signal processing) in favor of an integrated IBM PC.
I think that means that if you need more control on the peripherals added that can not be done on the thin client and wait for all the signals to propagate to the server to process them. That could be an argument against a fixed division of computational labor implemented in X. Although i am not sure if real time computational requirement can be met by any future distributed system. When you distribute work far away across a shared network you win in sharing and economy but you lose real time requirements.
Finally many many people in MIT, DEC,IBM are credited for making the Athena Project a reality . Combining various things i guess is like genetic merging ... :-) . Some times can be fun and productive ! But lets also not forget that all Project MAC (project was a misnomer in purpose, it was a lab) was funded by DARPA.
( ref )
(1984) X was announced . It was based on W . Initial development by Robert W Scheifler and Jim Getty ( ref )
19 June 1984
From: rws@mit-bold (Robert W. Scheifler)
To: window@athena
Subject: window system X
Date: 19 Jun 1984 0907-EDT (Tuesday)I've spent the last couple weeks writing a window
system for the VS100. I stole a fair amount of code
from W, surrounded it with an asynchronous rather
than a synchronous interface, and called it X.
(1985) An X11 License (precursor to MIT License) was added to X version 6 . .X was originally under a proprietary license but what we would now call an open source license was added to X version 6.
(ref ) Computer Systems Research (CSR) Group of the MIT–LCS (precursor to CSAIL) had developed several pieces of network software that were generating outside interest and requests for both information and copies of the code. That was the environment that created the fertile ground for MIT License. Jerome H. Saltzer seem to had a crucial role in the initial push for open licenses. Also that guy had Fernado J. Corbato as Doctoral advisor (Corbato was a pioneer in timesharing) he was a team leader to Multics (the Unix precursor) , led MIT's MIT-LCS/CSR and was techical director to Project Athena that gave X.
Keep in mind that moden MIT's CSAIL formed in 2003 by merger of : The Laboratory for Computer Science (LCS) and the Artificial Intelligence Laboratory (AI Lab). LCS has central role in Project Athena and has its roots at Project MAC and AI Lab was a lab where hacker like Richard Stallman thrived. ( ref ) .
In the fall of 1985, the question arose of how to license the X Window System[20] that was being developed by Jim Gettys[21] and Bob Scheifler[22] for MIT Project Athena.[23] In discussions parallel to those of two years earlier, they had noticed that proprietary licensing of early versions of the X Window System was becoming a hassle both for them and for prospective recipients and had the potential of interfering with widespread adoption. There were significant contributions made by early adopters, but that only made it more apparent that it was important to minimize the licensing friction.
Jerome H. Saltzer, The Origin of the “MIT License”
(1988-1993) MIT X Consortium formed as a non-profit vendor group, with Robert Scheifler as director. ( wikipedia )
Also the same year Keith Packard joined in March 1988 as senior developers. (i mention him because 15 years later it seems he had probably central role in the XFreee86 split and X.Org foundation )
(1993-1996) X Consortium, Inc is formed (a non-profit corporation) formed as the successor to the MIT X Consortium. ( ref ) X11 R6 (16/5/1994). According to that analysis of the negatives of the pro-paid work model used were : a) volunteer labor was crowded out b) drop in transparency in X to most of its developers c) change the direction of the project in ways that do not always serve the interests of users.
Because toolkits, desktop environments, and 3D were each controversial or proprietary areas among the funders, staff was not paid to work on these areas. The result was several major gaps in the X11 platform that restricted the ultimate usefulness of the software. Had the workers been working as volunteers, these were problems that would have been addressed early on — there was high demand from users. However, the introduction of paid labor directed the project in other directions.
(1999) X.Org is formed by Open Group.
(1991) X386 was an implementation of the X Window System on x86 arch.
X386 was created by Thomas Roell while at Technische Universität München . ( LJ Interviews Thomas Roell ),( Announcement of release 1.1 (as X386 1.1, based on X11R4) in 11/02/1991 .( ref ) (for reference 25/08/1991 Linux was announced.. so i guess that is a merit of os independence. The kernel came after the display server).
(1992) XFree86 project was formed to continue X386 probably from 1.2+ . initial release.
The project was originally founded by David Dawes, Glenn Lai, Jim Tsillas and David Wexelblat. ( an interesting archived interview with David Dawes that offer valuable insights about the funding of XFree86. Like for example the support from Tungsten Graphics that was co-founded by Brian Paul developer of Mesa library. )
(2003) A split happened in XFree86 core team. Keith Packard an X11 developer from 1988 was removed from XFree86 project ( ref1 ). Some months pass and the core team left sorf of disbands it self! ( Why a history of the X.org fork?)
(2004) X.Org foundation is founded and release X.Org X11 server.( wikipedia/X.Org) . X.Org foundation seem to be the continuation of
Interestingly i found that quote from David Wexelblat (XFree86 initial founders) from that 2003-2004 era:
"X is obsolescent," he wrote in a mailing list posting.
"I've been working in the Windows world for years now, and client-server display systems are utterly irrelevant to the majority of real-world computer users. X needs to be replaced by a direct-rendered model, on which a backwards-compatible X server can be reasonably trivially implemented".
It seems that at some point 3d accelerated graphics in personal computers created a 'gold rush' era that expanded and in the GNU/Linux t. Echoes of that era still makes waves by repeating old arguments and division about X and its role.
I wonder if the solution would simple enough. Those who dont care about the destktop intergrated style of windowing systems (DIWS) to step forward and maintain and improve X.
Ironically the XFree86 and the XOrg seems to represent a majority that favors DIWS. But at the same period 2002-2003 you could find stories about Linux thinclients networks that saved the budget of whole cities!
So i hope that short X history study of mine highlights that X is not only an old an inadequate 2d,3d renderer. X was a first of its kind successful open software distributed-networked windows system designed from day one to be platform independent and network native.
. An X12 or Y should improve on all that accounts. Why not an extensible NeWS like display server that can be part of a microkernel of a distributed OS ? (see also Why X is Not Our Ideal Windows System.) But surely an all in one solution that puts as priority the rendering aspect is for me a different window system. Not X like but Windows like.
The bad news is that it seems that from day one, in Linux land,those who worked to bring X to x86 , probably had in mind not X but a Wayland-like solution investing more of their energy mainly in the rendering-gpu-support aspect. Who knows.. maybe that was a job that HAD to be done before exploring other venues.. Its nice to have cool graphics in your windowing system in you GNU/Linux pc. But that is not in X tradition. That is something else.
Now seeing the more slowly rate of Wayland adoption it could mean that the Wayland-type window-system push although is a welcomed addition to the libre land and should be welcomed and encouraged nevertheless it could be that libreland and it's inhabitants are not an ms-window alternative land.
I think some want that . Steam wants that. Propably RedHat and many developers since there is where the more users are. But i think that over-done push could be also a mark of a certain stagnation..
On the other hand what did we expect ? When Thomas Roell started porting X11 to x86 PC i don't think he had in his mind the VS100 connected to a VAX 11 superminicomputers. IBM PCs were never meant to be thin clients.
It could be the case that X11's distributed soul in the process of being ported to a PC-oriented platform has been ''hijacked'' in favor for a PersonaWindowSystem PC's PWS . And it makes more sense to pay more attention to having fast and eyecandy graphics in a PWS than pay any attention to (as the wayland proponets call it) niche use cases that nobody cares for!.. And it makes sense in developing a PWS to want WS developers that can deliver that aspect.
Reading emails and articles from the Xfree86 - X.orgs 2003 (''split'') i havent found (so far) any trace of arguments in between Xfree86 developers regarding the use-cases that must be worked on the most. Instead the differences were on licenses and the organization efficiency to keep pace with rapid changes in the gpu - market.
In this view and context its seems logical (and a dream come true if you read the aspirations of the PWS developers mentality 30 years back) for a Wayland PWS to emerge.
What i dont like is that there are not any Distributed Windowing System (DWS) devs to come forward and claim X11's legacy. Since that was not the case from day 1 of the X386 port that explains the fact that X is being abandoned in favor for Wayland!!!.
That is happening because of the circumstances that i describe here. While it would make much more
sence for PWS proponent devs to split and create their own PWS project and dont tarnish X11 DWS aura.
Now we are stuck with X11/amd64 users (minority) that rely on X11/amd64 's DWS dna and indepedence form day1 (1980-83) era and X11/amd64 developers with a PWS mentality and abilities that are controlling (or that it seems to me so far) its development fueled by a strong flux of money and interest by GPU mammoths that see in games and AI huge market grow opportunities.
So the minority seems to be slowly getting thrown out of the AMD64/x86 Linux bus...
I wonder why Linux desktop virtualization (or DaaS) solutions of companies like NX-based solutions (nomachine), vmware ,teamware dont have any interest on the development of X11 i mean in a way to feel the necessity to be part of X.Org.
If they build X11 forwarding proprietary protocols shouldn't they want also to have a voice in the X.Org BoardOfDirectors ? Isnt it strange to have Valve and Codeweavers as guardians of X11 ? Or as i said before , it could be the case the X11's distributed spirit is long dead. That hypothesis could be tested also easily by looking at the sources to see the changes in various areas. Or could it be the case that Wayland can also function without any deficiances as Distributed Diplay server by its own extensions mechanisms ?
Speaking of distributed souls have you heard of Sun Ray. Sun's thinclient solution (1999-2013) that was based on separate network display protocol, Appliance Link Protocol (ALP)? SunRay was a successor to JavaStation a previous attempt (1996-2000) from Sun to create a thinclient market.
Is there any plan by Wayland to incorporate ssh forwarding? 2019 , Interesting discussion about X11 forwarding and Wayland . I think the discussion centers on one 'architectural' difference between X11 and Wayland. X11 has graphics primitives and that can beat a framebuffer 'forwarding' approach. But still couldnt wayland offers as extension Cairo primitives ?
chomwitt wrote:But why should it have a drawing api ?
I misunderstood your intention. I think what you're asking about is closer to Cairo or DRM. ....
Thank you very much for the links!
My intention is to find a more coherent way perhaps to make sense of display servers and the pros and cons. Now , i read about wayland vs x and my head aches.
I found thought that quote from LPC: Life after X by Jonathan Corbet (05/11/2010):
But things have changed in the 25 years or so since work began on X. Back in 1985, Unix systems did not support shared libraries; if the user ran two applications linked to the same library, there would be two copies of that library in memory, which was a scarce resource in those days. So it made a lot of sense to put graphics code into a central server (X), where it could be shared among applications. We no longer need to do things that way; our systems have gotten much better at sharing code which appears in different address spaces.
So that it's interesting. X server's drawing functionality being part of the display server because the other option (each client having the drawing api as a staticaly linked lib) would put pressure on memory usage.
So we have architectural choice (on display server) based on a resource constraint. A resource constraint leads to simpler designs with less choices (less drawing apis).
We dont want each app to have each own drawing api. Choices and variety is not inherently bad but need memory.
In that light we could say that the choice to leave a drawing API outside a DS protocol makes the protocol compatible with a computational enviroment that can support and-or want more choices. Interestingly focusing only on the drawing api it seem that the wayland protocol is more unix-like .
The fun part is that X didnt include UI toolkits (in contrast to other window systems of the 80s like SunView 'selling' that as a feature of the 'mechanism not policy' mantra !
Wait a minute! .. We have a memory restricted enviroment and we say lets dont put drawing APIs in the clients (in contrary to the 'mechanism not policy' mantra ) BUT lets allow clients to have UI toolkits because we promote the ''mechanism not policy' mantra ! ...
Depends on what you include in said drawing API.
By drawing API i had in mind primitives shapes like drawline , drarcircle , printtext , etc .
I've read that wayland protocol doesnt include such drawingAPI and i wonder if we're playing with words and boundaries.
I mean, lets say in a wayland based compositor i create a drawing API library for the wayland clients with the same primitives as X11 . So we can say then that wayland is more minimal protocol and more flexible and maybe more modular since it could accomodate more drawing APIs than X11 ?.Or we can say that there is no big difference , and that even X11 can by extensions accomodate thirdparty drawing APIs but it has a default one?
Assuming also the simplest b/w OGD supporting one resolution how difficult would be to implement it ?
It may take some elbow grease.
Should NHDS support also a drawing API ?
yes.
should it ... leave a user app draw whatever it likes directly to the portion of the GM thats was handed to it
no.
But why should it have a drawing api ?
Trying to make better sense of Wayland vs X11server comparison the more i read the more confused i feel.
So i figured to try to approach that as general as possible.
What is a display server? Wikipedia says:
A display server or window server is a program whose primary task is to coordinate the input and output of its clients to and from the rest of the operating system, the hardware, and each other.
So when a resource (graphics memory GM) is shared ,then not having a process to coordinate the GMRequests coming from different user apps would mean basically that there is not rules imposed and each program could draw everywhere and anytime. So i guess that is the most fundamental restriction that somehow it must be imposed .
A user program should not be allowed to draw anywhere it wants!..
So the most rudimentary display server should accept requests from GM-clients and have a fixed partition of its GM. That elementary GM would accept only lets say 4 apps. Also the GM would need to impose a certain data format to the incoming GMRs and being able to send the appropriate formatted-typed request to the OutputGraphicsDevice Drivers (OGDD).
Lets say someone wants to implement that rudimentary DS ..lets call it :Nucleus Harmony Display Server (NHDS) .
Assuming also the simplest b/w OGD supporting one resolution how difficult would be to implement it ?
Should NHDS support also a drawing API ? If not should it support drawing API's as extensions or leave a user app draw whatever it likes directly to the portion of the GM thats was handed to it ?
Also what is the relation of NHDS to the kernel ?
Sure NHDS must access OGDDs . But does it need something more? Access to memory ? To filesystem ? But if kernel controls access to memory how GM is different ? Isnt it memory ? Isnt that strange ? Kernel mediates and supervise access to memory to hundrers of processes and GM supervision could be NOT part of the kernel ?
i had an issue with the service not opening a socket at reboot. I think maybe it has to do with the export XDG_RUNTIME_DIR=/run/user/1000.
Maybe is not set up until i log on ? In which case what should i do ? Try it as a user service ?
Ok. Here is the run script that allows emacsclient to connect without a full 'socket' name:
#!/usr/bin/env /lib/runit/invoke-run
export HOME=/home/chomwitt
export XDG_RUNTIME_DIR=/run/user/1000
exec 2>&1
cd $HOME
exec chpst -u chomwitt:chomwitt emacs --fg-daemon=chomwitt-emacsdI've managed to start emacslient .
$ lsof -c emacs
emacs 623 chomwitt 6u unix 0x000000006612cb3d 0t0 1292858 /tmp/emacs1000/chomwitt-emacsd type=STREAM (LISTEN)
$ emacsclient -s /tmp/emacs1000/chomwitt-emacsd -c .when started from the command line it uses a different 'socket'.
$ lsof -c emacs
emacs 27340 chomwitt 6u unix 0x00000000d0fa297b 0t0 1696185 /run/user/1000/emacs/chomwitt-emacsd type=STREAM (LISTEN)
emacs 27340 chomwitt 4u unix 0x00000000331e1ac8 0t0 1518638 type=STREAM (CONNECTED)My guess is that from command line emacs --fg-daemon=chomwitt-emacsd uses $XDG_RUNTIME_DIR
$ echo $XDG_RUNTIME_DIR
/run/user/1000
So i will try to make $XDG_RUNTIME_DIR visible to my /etc/sv/emacs/run script