Slashdot Mirror
Wayland 1.7.0 Marks an Important Release
jones_supa writes: The 1.7.0 release of Wayland is now available for download. The project thanks all who have contributed, and especially the desktop environments and client applications that now converse using Wayland. In an official announcement from Bryce Harrington of Samsung, he says the Wayland protocol may be considered 'done' but that doesn't mean there's not work to be done. A bigger importance is now given to testing, documentation, and bugfixing. As Wayland is maturing, we are also getting closer to the point where the big Linux distros will eventually start integrating it to their operating system.
You can use Wayland in Fedora today: http://fedoramagazine.org/gnom...
Wow. First post and you've already hijacked the thread into another systemd flame fest?
My first program:
Hell Segmentation fault
anti-systemd trolls
Nice revisionist history. It's the systemd guys that have been acting like children and constantly attack Linux users for pointing-out bugs. After posting a reproduction script to the mailing list about a problem with systemd ignoring the exit status from a script, I was told by one of the main devs that he hoped my mother got cancer. Joke's on him. She died of cancer in 1977. You also have kids like http://slashdot.org/~Eunuchswear here that post some nasty replies, and it appears from looking at the moderation on the posts he is replying to that he or his friends have mod points and are using them to attack people that post about systemd problems.
If the systemd guys spent as much time programming as they did attacking us, then we probably wouldn't have anything to complain about in the first place!
Posting as AC because two of the last three times I posted one of the systemd punks moderated my posts down. I don't want to lose more karma to those trolls.
Remoting should be done at the toolkit level. This is where it belong. Similarly to sftp, gtkclient->ssh->intertubes->ssh->gtkapp
in practice you would call "gtkclient user@host:/path/to/gtk/application" which would connect the ssh pipes, set envar GTK_BACKEND to "pipe" and run the app. Gtk api get serialized both way, piped through ssh and run locally on your gtkclient which use what ever display backend your desktop is set to. This way you get the absolute minimal network traffics with zero lag in display. eg; highlight and scroll are just like local application.
I am unqualified to make this a reality so no amount of 'it open source, do it yourself' is going to help. I am just complaining here because I can. Thanks for your time.
<rant>
For those of us who have not heard of Wayland, the following is how the summary reads:
The x.y.z release of Some Software is now available for download. The project thanks all who have contributed, and especially the desktop environments and client applications that now converse using Some Software. In an official announcement from Some Author of Some Company, he says the Some Software protocol may be considered 'done' but that doesn't mean there's not work to be done. A bigger importance is now given to testing, documentation, and bugfixing. As Some Software is maturing, we are also getting closer to the point where the big Linux distros will eventually start integrating it to their operating system.
So what does Some Software actually do and why should I be interested? I know that I can Google Some Software, but is it really that hard to start with the summary with the following:
The x.y.z release of Somesoftware, a package which does blah blah blah, is now available for download. ...
After all, phrases such as "As Wayland is maturing", imply that this is a relatively new piece of software still under development of which everyone is not familiar, especially for those of us using BSDs, Solaris, and Slackware.
</rant>
> moderated my posts down.
I think three of my last four systemd posts were marked as trolls even though I gave specific examples of bugs. The systemd community is simply toxic.
Last night, I created a bug at:
https://bugs.freedesktop.org/e...
With a script I found from:
http://www.reddit.com/r/linux/...
that I was able to use to reproduce two different systemd bugs with on a Red Hat 7 and a CentOS 7 system. It is a well written and very self-explanatory example. I can no longer find the bug. It looks like they deleted it.
FWIW the reddit you link to has some replies with very reasonable explanations for the behavior you mention. As they state, I think the deal is even if it fails, it failed _after_ it started, and thus the start itself was successful. I think this is reasonable. I also got all log entries when reproducing here (same result as everyone else in that thread).
I'm not saying deleting bugs is cool - at least a WONTFIX or link to a DUP is appropriate - but are you sure it was opened successfully? What was the bug #?
The above said - I do see your point from a usability, if not strict "proper functioning" standpoint; previously for forking services that did some sort of constant time initialization and checking (opening files, sockets, etc) if the initialization failed they could report back and the startup script could return that result - systemd doesn't seem to support that. However there are other problems with the old way too (as you're checking result code I assume you're scripting) - startup could hang and you never get a result.I suppose the solution is similar for both cases - pick a point of time in the future and check if the status is as expected.
Maybe this is a feature request? As stated in the reddit, it only makes sense for forking services. It's not something I'd ever want, but maybe you could give a use case?
SIGDANGER is my middle name