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
> 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