Enlightenment Mysteriously Drops Wayland Support

jones_supa writes: According to Enlightenment 0.19.12's release notes, it's an important release that fixes over 40 issues, which is quite something, considering that previous versions had only a few improvements, with most of them being minor. However, the big news is that 0.19.12 drops support for the Wayland display server. Unfortunately, the Enlightenment developers have omitted to mention why they decided to remove any form of support for Wayland from this release, and if it will return in upcoming releases of the software.

Comments

I guess they realised...

[Viol8]

... that Wayland is a solution for a problem thats already been solved better.

Re:I guess they realised...

[buchner.johannes]

How/where has the problem been solved better?

Re:I guess they realised...

[Anonymous Coward]

Windows

Re:I guess they realised...

[Junta]

I suspect the sentiment is that X11 is better because of the network transparency angle. Of course the underpinnings of how X11 does it are actually decrepit and inefficient and compare poorly to other strategies that leverage different entry points that Wayland actually preserves. Injection into the compositing and WM provides a simpler and nowadays better performing strategy than X11 primitives. It meant something when the X11 primitives were actually used in the typical X applications with some sort of relevance, but now pretty much applications running over remote X are pretty much dumping bitmap data rather than any useful shorthand for complex UI concepts. Meanwhile intejecting the payload via compositor and the context via WM avoids a lot of the complexity that X contends with and allows a compositor freedom in picking good client-server protocol/compression.

Re:I guess they realised...

[myowntrueself]

How/where has the problem been solved better?

systemd?

Surely systemd solves *everything* better, thats why all the distros have gone with it?

Re:I guess they realised...

[squiggleslash]

Well, it's funny how something with "the underpinnings of how X11 does it are actually decrepit and inefficient and compare poorly to other strategies that leverage different entry points that Wayland actually preserves" still manages to solve the problem, and Wayland doesn't.

X11 isn't perfect. Nobody's ever argued that. It's just nobody's really asking for a replacement, and if they were, they wouldn't be asking for Wayland. X11 is an extraordinary piece of technology, it takes some gal to claim everyone should just throw it out and replace it with a ground up rewrite that adds no new features and doesn't support the major features X11 is famous and loved for.

It's not like init/SystemD, where init really was a bug ridden piece of garbage that's needed replacing now since before Linux itself came on the scene, and SystemD implements everything init did but does it right.

Re:I guess they realised...

[Anonymous Coward]

it takes some gal

Found the problem. It's more of that horrible misogyny in the Linux community.

Re:I guess they realised...

[jon3k]

It's just nobody's really asking for a replacement

No one asked Henry Ford to make cars, either. This attitude, specifically in technology, is baffling to me.

Re:I guess they realised...

[fisted]

init really was a bug ridden piece of garbage

Care to point out a couple of those bugs?

SystemD implements everything init did

And a lot more, yes

but does it right.

Hahaha, yeah, it probably looks right from a Windows-centric POV

Re:I guess they realised...

[jareth-0205]

It's not like init/SystemD, where init really was a bug ridden piece of garbage that's needed replacing now since before Linux itself came on the scene, and SystemD implements everything init did but does it right.

Talking of statements that take some gall...

Re:I guess they realised...

[Viol8]

If you have to ask the question you won't understand the reason for the answer.

Re:I guess they realised...

[Anonymous Coward]

This is a common argument from someone that has no idea what they're talking about. Watch this.

https://www.youtube.com/watch?v=RIctzAQOe44

Re:I guess they realised...

[rjmx]

Wow. That's a lot of buzzwords.
I think you left out "user experience", tho.

Re:I guess they realised...

[Anonymous Coward]

...

It's not like init/SystemD, where init really was a bug ridden piece of garbage that's needed replacing now since before Linux itself came on the scene, and SystemD implements everything init did but does it right.

BWAAA HAAAA HAAAAAAHAAAAAA HAAAAA AHAAAAA HAAAAAA!!!!!!!!!!!!!!!!!

Stop. stop. I'm gonna pee.

Re:I guess they realised...

[serviscope_minor]

No one asked Henry Ford to make cars, either.

And you know what? No one asked the Stanley Motor Carriage Company to make cars either.

Simply being new doesn't mean it's better. The trouble with Wayland, or rather why I'm deeply suspicious of it is that some of the claims from the devs about waykand and X11---and bear in mind they're X11 devs too---are flat out wrong at best and deeply deveptive at worst. Why the need for a FUD attack? If Wayland is better it ought to win on merit, not FUD.

Tahe for example this article: http://www.phoronix.com/scan.p...

Going through one at a time.

1. Extensions are what X11 calls API updates. Wayland will get API updates too, so this is not an advantage of wayland beyond version 1.0.

1. A, B, C: Almost all extension version updates add new API calls and keep the old ones. Sending Foo 2.0 calls to Foo 2.2 works just fine. Not to say that versioning isn't a problem, but then fixing the API is apparently bad for X but nothing else.

2. Well core X11 is super simple and a tiny setup of Xinput 2. This leaves essentially 2 input systems left of any complexity, 2.2 and 2.0, and as far as I can tell 2.0 isn't actually separate from 2.2. So, basically X has one major input system which actually looks kinda similar to the Wayland one.

3. That's a misunderstanding of "mechanism not policy"

4. So Xorg and Xfree86 got a bit crazy and then got refactored. Apparently historical cleanups are a bad thing? This happens in any project of any age.

5. Apparently it's impossible to add a new API call for synchronisation because from (1) that X11 isn't allowed api updates unlike every other system.

6. Yeah OK, fonts are not great.

7A A badly designed chunk of Xorg is apparently a problem with X11 now. Oh and it's been fixed so it's not a problem at all. But apparently every misstep in one implementation of an X server fixed 5 years ago is a reson it's bad now.

7B That was pure fud in 2013 when it was written. Xrandr and monitor hotplugging has worked flawlessly for years.

7C Huh? There's been xrandr front ends for years which remember certain layouts. Hell, Arandr, the nice GUI point and click one in all the repos remembers layouts just fine.

7D That smells like bullshit to me. Unless the second monitor is a separate screen (X11 term for something little used now) they it'd be impossible for one to have compositing and one not. I've not heard of anyone using screens in years.

8 Yeah and real toolkits are poorer for it. The window tree is a really nice thing when you have latency. Because with tree'd systems the server remembers which sub-sub-sub window a mouse click went to, and you could ignore the absolute position. With a treeless system all you have to go on is the position.

With latency, if you click, then the display updates then it processes the click, your click goes not where you want, but where the GUI is now. This I find happens more often than I'd like in web "apps". With tree based systems, sure the widget moved, but the assignment of the click to the window was latency free, so your click ends up correctly on the now-moved widged.

IOW tree based systems are superior. Many toolkits abandoned it for compatibility with non tree based systems. What we have now is actually fundementally worse in high latency environments.

9 Yes this is finally a genuine, no-nuance flaw.

10 C this is not correct if you have a compositing window manager, because it can do whatever it likes with the final display.

10 D their solution is to make the compositor do all this shit in Wayland. That could be done equally well in X. Sure, the current convention has a small flaw, but X11 now supports the Wayland way too.

10 E just use the features of the compositing window manager. It intercepts all key presses and windows anyway.

So without getting into the merits or demerits of Wayland, it's disappointing to see the devs engaging in a colossal FUDstorm.

Re:I guess they realised...

[Anonymous Coward]

X11R3, 1988. Hasn't been improved upon since.

Re:I guess they realised...

[DrXym]

Exactly. X11 was designed for a different world where there was clipping, damage, rendering primitives, immediate rendering etc. It doesn't have any concept of compositing or GPU surfaces and thus a raft of extensions have appeared to support those things. But of course they're still hampered by a brain damaged pipeline which still thinks in the old way and they are constrained by.

Re:I guess they realised...

[Uecker]

It is a myth that supporting old drawing primitives in X11 somehow slows down modern clients and you can essentially have the same buffer handling as Wayland with X. In fact, the design of Wayland is basically copied from X minus some old parts which are not needed by modern clients. The problem with this is: Breaking compatibility with a decades old protocol for no good reason is just moronic.

Re:I guess they realised...

[TheRaven64]

It's not that supporting the old things slows things down, it's that it doesn't speed things up. It actually does cause some problems, because various things in the X11 protocol use 8-bit fields of which a significant space is used by legacy stuff that no one uses anymore, but that's largely worked around in newer extensions.

If you're in a world where most applications are sending commands like 'draw line from x,y to x1,y1' then X11 network transparency is really fast. At the protocol layer, anyway - if you use xlib then performance will suck unless network latency is very low because it adds a synchronous API on top of an asynchronous protocol (XCB fixes this). Modern applications don't do that, they typically render pixmaps and just have the X server composite them. X11 can still do a reasonable job here, with XDAMAGE, XFIXES, and XRENDER, allowing you to keep most of a pixmap (a Picture, in fact) on the server, update image data in selected parts, and do all of the compositing in the server. The problem is that none of the X11 toolkits actually do this very well. Wayland doesn't solve this at all - it simply says 'well, grab an OpenGL context and send drawing commands'. That works okay - the OpenGL protocol allows you to copy textures to the server (and the GPU) and composite them very fast. The problem is that this approach also works fine in X11, and with X11 you get network transparency when you do it (which works reasonably).

The main criticism I'd have of X11 is that it puts too much state on the server. There is no way, at the X protocol layer (or even in the low-level X libraries) of saying 'disconnect this window from this display, reconnect it here', or 'oh, my X server has crashed, recreate my state on this newly restarted version'. The latter worked fine in BeOS almost 20 years ago and works fine in Windows today. The former worked on NeWS 30 years ago. Both are use cases that I'd love to see addressed for modern devices. The Wayland solution to this is 'write a web app'.

Re: I guess they realised...

[Anonymous Coward]

Defense of merit is not hatred of women.

Re:I guess they realised...

[Junta]

It doesn't slow down, but they also don't help. That's the point I was making, that the lines, text, and pattern primitives that X was able to simply describe aren't leveraged in modern UI.

Now I can't speak to the question of what Wayland fixes in exchange for getting to ignore having X11 as part of the core, and whether it's worth it. I can say that even if it Xorg, it's time for most folks to move on to strategies like Xpra that preserve the awesome facets of seamless remote applications, perform better, and are not sensitive to things like network disconnects trashing the ability for the application to keep running.

Re:I guess they realised...

[Junta]

I haven't seen it in Wayland per se, but look at xpra. The way it implements remote app execution is in theory possible based on my understanding of wayland architecture. It doesn't have problems with detaching windows, etc. It currently requires a dummy X server, but it's not really in the actual display stack. It's a project that gives me hope for Wayland being able to provide a decent experience. Of course I don't know if Wayland is badly needed or not, but at least I could see a tolerable way of coping with applications that could not run over X without something like a dumb VNC session.

Re:I guess they realised...

[Uecker]

It's not that supporting the old things slows things down, it's that it doesn't speed things up. It actually does cause some problems, because various things in the X11 protocol use 8-bit fields of which a significant space is used by legacy stuff that no one uses anymore, but that's largely worked around in newer extensions.

Yep. I am not opposed to cleaning things up with extensions without breaking backwards and forwards compatibility.

If you're in a world where most applications are sending commands like 'draw line from x,y to x1,y1' then X11 network transparency is really fast.

X11 network transparency is also very fast if you move bitmaps over network and are a bit smart of how you do it (I wrote an image viewer
which works quite well over the network).

At the protocol layer, anyway - if you use xlib then performance will suck unless network latency is very low because it adds a synchronous API on top of an synchronous protocol (XCB fixes this).

Yes, absolutely. But the important thing is: It is not a protocol problem. Replacing xlib is a sensible thing to do, inventing a new protocol is not.

Modern applications don't do that, they typically render pixmaps and just have the X server composite them. X11 can still do a reasonable job here, with XDAMAGE, XFIXES, and XRENDER, allowing you to keep most of a pixmap (a Picture, in fact) on the server, update image data in selected parts, and do all of the compositing in the server.

Absolutely. The great thing is: X11 lets you do all this stuff because it is based on a very generic framework. In contrast to almost everybody here, I think that X11 has a *great design*.

The problem is that none of the X11 toolkits actually do this very well.

It is still working OK for most stuff. But yes, the toolkits do not care about network transparency anymore, which is quite sad.
But you can write clients which work really well over the network. And just yesterday I used Matlab over a trans-atlantic connections.
This sucked because it was slow, but it was really really useful that I was able to do this.

Wayland doesn't solve this at all - it simply says 'well, grab an OpenGL context and send drawing commands'.

Wayland doesn't solve _anything_, because you can do the same stuff with X.

That works okay - the OpenGL protocol allows you to copy textures to the server (and the GPU) and composite them very fast. The problem is that this approach also works fine in X11, and with X11 you get network transparency when you do it (which works reasonably).

How is this a problem?

The main criticism I'd have of X11 is that it puts too much state on the server. There is no way, at the X protocol layer (or even in the low-level X libraries) of saying 'disconnect this window from this display, reconnect it here', or 'oh, my X server has crashed, recreate my state on this newly restarted version'.

Toolkits could easily do this. You can disconnect from one server on reconnect to another. For example, there is libdisplaymigration. I added it to my software in the past, then you could move windows from one server to another. GTK had a bug where it connect disconnect properly, but his was a bug in GTK and had nothing to do with X. Xlib had problems with recovering after a lost connection. But again, this was a problem with Xlib not with X.

The latter worked fine in BeOS almost 20 years ago and works fine in Windows today. The former worked on NeWS 30 years ago. Both are use cases that I'd love to see addressed for modern devices. The Wayland solution to this is 'write a web app'.

I wish people would work on adding disconnect, reconnect, and display migration to the X11 toolkits. Another useful feature would be drag&drop which works between windows on different clients by moving the data through the server (.i.e. the clients do not need to know anything about each other). You could do so much cool stuff with X, especially nowadays with fast wireless everywhere...

Re:I guess they realised...

[vadim_t]

Care to point out a couple of those bugs?

Okay, sure.

1. It does next to nothing. All the real functionality is in distribution specific scripts, which means you need to research and write a script for each distribution you want to support, each with its own particular features and idiosyncracies.
2. Each script is a bunch of boilerplate that has to reimplement the same stuff. Often badly, especially when an init script has to be improvised.
3. The functionality is inconsistent between services. Some can be restarted, some not. Some have a status command, some not.
4. To check whether a service is running, it uses pid files. Pid files are horribly unreliable and prone to failing if a pid file happens to be left around, and something else happens to use the same pid.
5. If you want start on demand, eg, something like xinetd, that's an entirely different system that's managed differently and separately.
6. If you want a service to get automatically restarted, that's also done with an entirely different system like monit.
7. It doesn't have useful logging. Processes can vanish into the ether without useful information in the logs because stderr may not be captured in some cases, and because init doesn't log service crashes.
8. Service providing services are tricky. You may know the daemon has started, but you don't know it's now accepting requests. Yay for "sleep" hacks.
9. Breaks horribly the moment something goes wrong. Network cable not plugged in? Well, if you boot like that nothing network related works, so you've got to log in and fix it by hand.

Re:I guess they realised...

[Alomex]

It's just nobody's really asking for a replacement,

Except SunOS which replaced it with SunNews,

--Ok, but apart from SunOS no one is asking for a replacement.

Well NeXTSTEP replaced it with display postscript.

--Ok, apart from SunOS and NeXTSTEP no one wants a replacement.

Android dumped it.

-- Yes, aside from SunOS and NeXTSTEP and Android, who else wanted a replacement?

OSX replaced it with Quartz as well as iOS.

-- All right, but apart from SunOS, NeXTSTEP, Android, OSX, iOS what have the Romans ever done for us, i mean who wants a replacement?

Ubuntu with Mir and the Xorg with Wayland?

--Oh, SHUT UP!

Re:I guess they realised...

[Anonymous Coward]

1. Breaks horribly the moment something goes wrong. Network cable not plugged in? Well, if you boot like that nothing network related works, so you've got to log in and fix it by hand.

My favorite is: "Can't connect to wifi? You didn't need to continue booting for the next 2 minutes, did you?"

Re:I guess they realised...

[Uecker]

It doesn't slow down, but they also don't help. That's the point I was making, that the lines, text, and pattern primitives that X was able to simply describe aren't leveraged in modern UI.

Yes, this is why XRENDER was introduced 15 years ago.

Now I can't speak to the question of what Wayland fixes in exchange for getting to ignore having X11 as part of the core,

Well they don't have to deal with the old code, I can understand this. But it breaks compatibility on the protocol level, this is really stupid IMHO.

and whether it's worth it. I can say that even if it Xorg, it's time for most folks to move on to strategies like Xpra that preserve the awesome facets of seamless remote applications, perform better, and are not sensitive to things like network disconnects trashing the ability for the application to keep running.

Xpra is nice if you have a slow connection, but I use X applications just fine over the network every single day and it works just fine. Being able to disconnect would be nice though, and I do not understand why toolkits still do not support this. Well, the reason is that rewriting everything from scratch all the time is apparently more fun...

Re:I guess they realised...

[Endymion]

hey typically render pixmaps and just have the X server composite them

This is just nonsense. Your applications may be overly pixmap based (certain GTK+ engines started that mess when people prioritized "themes" over good design), but it is foolish to assume everybody else uses the same limited set of software. Remember, most of the software in the world is smaller private stuff used internally by businesses, academia, etc. Simply asserting that nobody uses various features doesn't make it true.

Wayland advocates really need to learn one of the most important lessons of software design, which was best explained by Joel Spolsky's essay "Things You Should Never Do, Part I".

[Y]ou can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."

Why is it a mess?

"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for." [...]

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. [...]

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. [...]

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Yes, there are rough areas in X11 that really need to be fixed. That's true for almost any software project of sufficient size. Fortunately, the extension system in X11 allows a lot of those problems to be solved one at a time, while retaining backwards compatibility. The people that believe the very existence of backwards must somehow be a bottleneck are not creating the next version of X. Instead, they are creating something new. This is fine, but by their own definition, it is not a replacement for X11, and if Wayland tries to be such a replacement, it will inevitably grow to a similar level of "messiness" as numerous fixes, workarounds, and minor features are re-invented.

The problem with Wayland (and many other modern "replacement" projects, with systemd as the canonical example) is not technical in nature, but the hubris that so easily throws out so many man-years of effort.

Re:I guess they realised...

[Camel Pilot]

Oh look a hockey game broke out in a boxing match :)

Re:I guess they realised...

[fisted]

What about the part where you were going to mention bugs in init?

Re:I guess they realised...

[Endymion]

Each script is a bunch of boilerplate that has to reimplement the same stuff.

So shared libraries don't exist? That hasn't been a problem in a long time on BSD or OpenRC systems. Seriously, it's not hard to factor out code into a library. If you're only considering Debian, you have to remember that they are always behind (sometimes FAR behind) the update cycle.

The functionality is inconsistent between services.

Again, only if you were a moron and reinvented the wheel each script instead of using a common library.

That said, the ability to do things different is very important when you need to support something unusual.

To check whether a service is running, it uses pid files.

No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.

It doesn't have useful logging.

Again, this is by design, as it left logging *unspecified*. If you don't like syslog, nothing was preventing you from using something else. (also, "useful" is subjective)

because init doesn't log service crashes.

Patently incorrect, as I have used syslog to inspect startup crashes many times over the last *twenty years* I've been using UNIX. Maybe this has been a problem for other people, but I've never seen it. If your syslog is configured badly, that's an entirely separate problem.

Yay for "sleep" hacks.

While I can't speak for all distributions (you seem to have had some history with poorly-configured environments), there is nothing wrong with using sleep based polling. The only reliable way to detect if a prerequisite service is ready is by directly polling the service. (e..g issue an HTTP GET to a web server) The timeout is to allow startup to proceed in case of an error, (so you don't end up bricked, unable to use your computer)

on demand

There is a reason most distributions stopped using super-servers like xinetd: on-demand startup isn't that useful. Start your service at boot. You can defer expensive tasks until the first requests, if you want, which is when you would pay that cost anyway in an "on demand" launch. Listen to on the port, block on accept(2) or select(2) or similar, and let the OS page you out to the swap partition.

"On demand" isn't necessary, because the kernel already provides that feature. Adding a redundant implementation simply increases complexity and adds more opportunity for bugs. Super-servers make it even worse, as they add the risk that a problem in on service could take down all the services provided by the super-server.

Breaks horribly the moment something goes wrong.

Ok, now you're just trolling.

Want to have some fun? On a systemd box, pretend you just installed some updates, and you need to restart a few daemons so they run the updated versions. Try restarting dbus (system, not user). (You might want to make sure any open files are saved first)

Also, you might want to actually read about UNIX before you make these kinds of accusations. Reading taoup is a good place to start.

Re:I guess they realised...

[Anonymous Coward]

Wow. Insightful? It's odd. Even some of the kernel developers apparently miss the point.

Why develop a windowing system, there are some already out there?
Why develop Android, there are already iPhones?
Why develop iPhones, there are already smart phones?
Why develop smartphones, there are already feature phones?
Why develop Linux, there is already other OSes out there?
Why develop Windows, there is already GEOS out there?
Why bother developing anything?

Re:I guess they realised...

[Anonymous Coward]

It... disappoints me that the more vocal systemd proponents have never actually *looked* at what modern (that is, built in the last ten years) sysvrc replacements do and how they do it.

To get anywhere *near* the power and flexibility of what you get from OpenRC in systemd, you're going to *have* to roll your own shell scripts. Given that the systemd folks are deathly allergic to shell scripting and won't provide these scripts *for* you, this means that -surprise!- each service with non-trivial is-it-started determination or pre-start configuration validation requirements is going to have... *its own set of one-off, hand-rolled shell scripts*!

Re: I guess they realised...

[Anonymous Coward]

Actually it's about ethics in UI programming.

Re:I guess they realised...

[Anonymous Coward]

Unless you go out of your way to configure it otherwise, on Gentoo, having the *loopback* device started is enough to consider the network up and online. Additionally, after the WiFi device is brought online, its startup is backgrounded so that the time taken by AP discovery and association and IP address acquisition doesn't stall the rest of system start. When backgrounded, WiFi network interfaces are marked as "started, but unready". When AP association and IP address acquisition is complete, that interface is marked as "started and ready".

Of course, the amusing thing about your snark is that the network connection handling software used on most non-enterprise Linux distros is NetworkManager; another Poettering special. I've dumped it and rely only on wpa_supplicant, wpa_gui, and the link detection stuff built right in to Linux. It works *really* well.

Re:I guess they realised...

[ardor]

If one of the X developers essentially calls X obsolete crap, then I think we should listen to him.

There are certain things that just don't work well in X. One of them is vsync, which requires a rather large amount of nontrivial workarounds, like Intel did.

To get something like vsync integrated properly, you need to fundamentally change how frames are updated. This is what Wayland developers refer to when they say that "every frame is perfect". The X11 model is essentially dumb drawing and updating, with no regards to complete frames. It goes further when you have for example 2 videos on screen. Even if both have the same framerate, temporal jitter will cause lots of problems. With a display server like Wayland, it is possible to inform the server that "surface X needs to be presented at timestamp Y", giving the server the chance to correctly schedule and group together updates. This possibility doesn't exist in X.

X is an anachronism, designed for graphics hardware from a bygone era. X does not in any way reflect properly how today's graphics chipset work. Sure, X can be used, but you need to use so many extension that very little is left from core X, at which point you have the display server equivalent of the Ship of Theseus.

One other big problem with X: it is single-threaded. Applications *can* cause X to block and become unresponsive. LibreOffice is good at this.

That said, I am not particularly fond of Wayland. I think it is a step in the right direction, but I slightly prefer the DisplayPDF approach of OSX. I believe certain primitives like text do have to be part of the server. Not for network transparency, but because rendering text is not easy, and especially because it makes it easier to deal with display scalability issues (physical size, PPI etc.) and multi-monitor setups (and also allows for very nice benefits like system-wide font atlas caching). However, in order for this to work properly and efficiently, you need to merge the display server interfacing libraries (= the equivalent of libX11/libxcb), the server itself, and the UI toolkit(s) to work consistenly across the board (and this is what OSX Quartz does). In particular, this requires the protocol between the interfacing libraries and the server to be opaque, implementation-defined, and not guaranteed to remain the same. This is because it makes modernizations, subsystem replacements, and extensions much easier. In X, there are still old extensions around because some old programs use the (Xinput vs Xinput2 for example). With such an encapsulated protocol as I describe, there would be only one high-level input API. The possibility of API breaking changes would not be that high, since unlike in the 80's and 90's, these days, the essentials of a 2D on-screen user interface (basic widgets, interface structures, crucial features and behaviors etc.) are well-known and stable.

Re:I guess they realised...

[ardor]

.. aaand I just experienced another ugly wart of X: the dual clipboard madness (middle-click vs. Ctrl+C / Ctrl+V). The youtube link was incorrect, and some other link was present in the clipboard. https://www.youtube.com/watch?... is the right one.

Re:I guess they realised...

[Anonymous Coward]

Yeah, let's all just trust that this smug asshole on slashdot is smarter than all of the x maintainers that wrote and designed wayland after working with x for decades.

Re:I guess they realised...

[vadim_t]

No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.

Of course. Keeping track of running services is out of scope for a service management system. Genius.

It seems to me that the reason why pid files still exist is because sysv provides next to nothing, so people end up using the easiest, but about the worst approach available.

Patently incorrect, as I have used syslog to inspect startup crashes many times over the last *twenty years* I've been using UNIX. Maybe this has been a problem for other people, but I've never seen it. If your syslog is configured badly, that's an entirely separate problem.

Not startup. Crashes, as in segfaults. Those of course don't get logged since sysv doesn't monitor what it runs. Add the wonders of pid files to that and you get a service that sometimes needs to be fixed by hand to be restarted.

Also note that I'm talking about the init system, and not about individual services doing their own logging.

While I can't speak for all distributions (you seem to have had some history with poorly-configured environments), there is nothing wrong with using sleep based polling. The only reliable way to detect if a prerequisite service is ready is by directly polling the service. (e..g issue an HTTP GET to a web server) The timeout is to allow startup to proceed in case of an error, (so you don't end up bricked, unable to use your computer)

No, no polling. Just a plain "sleep 5" in a script that hopes that the service it depends on has time to properly get started in time. I sure hope no distribution ships this kind of crap anymore, but I seem to run into such hacks annoyingly often for some reason.

There is a reason most distributions stopped using super-servers like xinetd: on-demand startup isn't that useful. Start your service at boot. You can defer expensive tasks until the first requests, if you want, which is when you would pay that cost anyway in an "on demand" launch. Listen to on the port, block on accept(2) or select(2) or similar, and let the OS page you out to the swap partition.

Of course it's useful. Why should something like cups get started without a printer? Why should the user know to enable it once they get one? These days hardware changes at runtime, and things are expected to work when you plug in a printer or a bluetooth adapter, and not to complain or stop booting if some hardware turns out not to be there anymore.

Want to have some fun? On a systemd box, pretend you just installed some updates, and you need to restart a few daemons so they run the updated versions. Try restarting dbus (system, not user). (You might want to make sure any open files are saved first)

I get a slightly ugly message from systemctl, but other than that everything seems to be working fine. Restarted it a couple times just to be sure, checked that yep, the pid changes.

Also, you might want to actually read about UNIX before you make these kinds of accusations.

I speak from personal experience

Reading taoup is a good place to start.

Thanks, but I'm not religious. I prefer things that are convenient to those that are ideologically pure.

Re:I guess they realised...

[Anonymous Coward]

No one asked Henry Ford to make cars, either. This attitude, specifically in technology, is baffling to me.

There's a lot of technological innovations that we've forgotten about because they just didn't work as well as the alternatives.

For every Henry Ford, there's people whose names are mostly forgotten because their great idea wasn't so great after all.

Re:I guess they realised...

[Anonymous Coward]

There is one BIG flaw in X11 that wasn't mentioned: by design, every program that hooks into X also gets access to ALL input X gets. Meaning by design you cannot prevent any keyloggers from logging your sudo password. Wayland only allows access to all input to the compositor itself, and with a sandbox it can prevent any other program from keylogging.

Re: I guess they realised...

[Anonymous Coward]

How would we cope without Captain Obvious?

Re:I guess they realised...

[TheRealMindChild]

Here is a good video commenting on why X is a dead end and Wayland makes sense https://www.youtube.com/watch?...

Re:I guess they realised...

[Anonymous Coward]

I mean seriously, you had to switch platforms to create a zinger?

There's no connection between Windows and SystemD. None. No matter how hard you shill to make it so, it doesn't exist. Do try to stay at least minimally relevant. This discussion started out about Wayland and mutated to SystemD and now you bring Windows into it. What's next, a reference to your conflicting feelings towards your parents?

Re:I guess they realised...

[fisted]

Try reading comprehension.

Re:I guess they realised...

[Richy_T]

With latency, if you click, then the display updates then it processes the click, your click goes not where you want, but where the GUI is now. This I find happens more often than I'd like in web "apps". With tree based systems, sure the widget moved, but the assignment of the click to the window was latency free, so your click ends up correctly on the now-moved widged.

IOW tree based systems are superior. Many toolkits abandoned it for compatibility with non tree based systems. What we have now is actually fundementally worse in high latency environments.

Man, this explains a lot. Mainstream Linux GUIs have been going backwards for a long time. But at least we have, uh, well, we already had most of it back then, come to think of it.

Re: I guess they realised...

[Anonymous Coward]

Just. Wow.

'cat' sucks because it only does one thing. ls? Piece of shit. sed? Laughable.

Man, have you ever used UNIX before? Small utilities that do one thing and do it right. Chain them together to make great things. What the fuck is so difficult about that philosophy?

Because httpd and syslogd have different operations they can perform -- and therefore the init.d script for each support different operations -- you need to replace the init system? That's totally fucking batshit bananas.

I could understand the argument about each distro having their own little flavor of init.d (yes, writing a script that works on both RHEL and Debain is tedious) being a pain in the ass, but the conclusion that the only way to fix it is to re-write everything from the ground up is just ... a giant waste of otherwise available talent.

You want one ring^H^H^H^H init to rule them all? Fine: write one and tell everyone that Linux init scripts have to work the same way everywhere. No need to change anything else. At all.

Re:I guess they realised...

[Anonymous Coward]

The problem with X11 is not that the code is messy or buggy. It's the protocol *design* what's wrong, and no amount of code refactoring can fix this. X11 is essentially a remote drawing protocol. The idea is that a central computer does complex calculations and sends drawing primitives to the (much weaker) client display machine, which is basically a glorified display. That was useful in the 80s, but the world has moved on. Today cell phones (and watches) are much more powerful than the servers of old, so pushing computing to the server not really that useful, most of the time. And when it is (when working with shared data, for instance), we have a much better remote display protocol today: HTML.

Re:I guess they realised...

[DrXym]

X11 isn't perfect. Nobody's ever argued that. It's just nobody's really asking for a replacement, and if they were, they wouldn't be asking for Wayland. X11 is an extraordinary piece of technology, it takes some gal to claim everyone should just throw it out and replace it with a ground up rewrite that adds no new features and doesn't support the major features X11 is famous and loved for.

I think you'll find lots of people are asking for a replacement, starting with the people most familiar with X11. And more generally anybody who wants Linux to be able to host a modern, responsive desktop experience without suffering the latency and other bottlenecks of an arcane and mostly obsolete architecture for no reason whatsoever.

Re:I guess they realised...

[DrXym]

GNOME 3 is utter garbage? Interesting.

Re:I guess they realised...

[Damouze]

If init is such a big piece of crap why do UNIXes stick to it? There is no way to implement what init does with systemd. Systemd is flawed by design. It is a monstrosity that should never have seen the light of day. To name a few fundamental flaws: using a binary system log, using binaries for helper programs and xml files for configuration (what's wrong with using shell scripts and flat text???). Thirdly, it violates the very thing that underlies nearly every single component of UNIX or a UNIX-like operating system: have tools that do one single thing and do it well.

Storing systems logs in a binary format by start is simply stupid. It's okay to do that if you want an (external) backup of your system logs, say for example on a log host. Still, there are better ways to go than to roll your own binary format. Use a database server for heaven's sake!

As for Wayland, like Mir (or whatever Canonical would like to call it these days, they just can't seem to make up their minds about it), and in many ways something systemd as well, it is just the first step to the proprietarization of the operating system on top of the Linux kernel and the first step in the way to vendor lock-in all over again.

Re:I guess they realised...

[DrXym]

The Wayland API is nothing like X11 except in broad concepts that all display / input APIs share - listening for input events, connecting to a display, creating a drawing area and so on. It's just that Wayland's map onto modern concepts such as GPU surfaces and compositing so that rendering is as efficient as possible.

As for the primitives, nobody has ever said they slow modern clients. The point is that clients don't even use the primitives any more and its the same story applies for most of the rest of X11. It has a 1980s 2D-centric, damage based view of the desktop and extensions are used to fool it into supporting surfaces and composition. But those extensions are workarounds which are design compromised by the architecture and so they are slower and less efficient than they would be.

Hence the push for Wayland. It will ultimately lead to a more lightweight and responsive desktop. Fedora Core 23 will be released soon and GNOME 3 should be feature complete for Wayland. And 24 might flip the switch and make Wayland the default. It doesn't stop people using X11 if they want so I don't see the problem.

Re:I guess they realised...

[Anonymous Coward]

It doesn't have useful logging.

Again, this is by design, as it left logging *unspecified*.

Then the design is an utter failure and a bug in itself.

Re:I guess they realised...

[Anonymous Coward]

Why do you think it looks right from windows-centric POV?

Re:I guess they realised...

[serviscope_minor]

There is one BIG flaw in X11 that wasn't mentioned: by design, every program that hooks into X also gets access to ALL input X gets. Meaning by design you cannot prevent any keyloggers from logging your sudo password. Wayland only allows access to all input to the compositor itself, and with a sandbox it can prevent any other program from keylogging.

Indeed, though entertainingly this isn't part of the X protocol, but part of the Xinput extension brought to you by the folks now working on Wayland. However, I don't see any reason that the compositor model of X11 can't be updated to intercept all events: it already has to intercept all events anyway because it needs to be able to arbitrarily mangle them before feeding them into the various captured windows.

So this flaw could be fixed for compositing window managers with a small update to the API. Given the architecture of X, the 10 remaining people like me using non compositing window managers could do it with an external compositor. However, one of the main bonkers criticism of X is that the API sometimes receives updates. So make of that what you will.

Re:I guess they realised...

[serviscope_minor]

Man, this explains a lot. Mainstream Linux GUIs have been going backwards for a long time. But at least we have, uh, well, we already had most of it back then, come to think of it.

Indeed and it really pains me. What Linux/unix had way back when was far from perfect. However, it had some awesomely brilliant features that neither Windows nor MacOS and then OSX had. The desire to blindly chase Windows 95 then XP then OSX has systematically stripped out almost all of the unique but superior features giving us what is essentially a barstardised and inferior hybrid of Windows and OSX.

And you know what? That chasing was a complete fools errand. It didn't "win" us linux on the desktop, all it did was take a system which was superior to all others for some people and make it superior for even fewer.

Re:I guess they realised...

[silentcoder]

>Thanks, but I'm not religious. I prefer things that are convenient to those that are ideologically pure.

That's all well and good but when that "ideology" is the result of 40 years of practical experience by a culture that has produced the engine that drives the entire 21st century (yes, that engine is Unix, because it drives the internet), which has allowed that system to survive thousands of incredible changes to technology virtually unchanged - because no matter how the world changed, it was still working, still useful, still more powerful than the alternatives and changing it to make use of the latest and greatest available technology was always ridiculously easy, when it produced the only operating system that runs on everything from the tiniest embedded systems to the largest supercomputers - then rejecting it requires a strong, rational argument - and even the best such arguments are likely to hold only in very rare niche cases.

And the problem with systemd is it violates virtually every one of the principles of that philosophy and offers NO rational reason for ANY of the violations - and it isn't doing so in a niche where perhaps some of those principles are genuinely not applicable, it's doing it to the heart of the system.
These changes are the ONLY reason Linux exists - because they are the reason Unix didn't die in 1969 when it was invented, or in the 1970s when mainframes met microprocessors, or in the 1980s when PCs were invented... they are what allowed unix to adapt and scale to the fast changing world of technology at the front of the curve at all times, exactly because they made changing it always easier than building something new.

It violates the rule of separating mechanism from policy. It now enforces policy on what ought to be a pure mechanism - and there is a very solid and rational reason for that rule: policy changes often but mechanism tends to be long-lived. Failing to separate them means tying the policy to the lifespan of the mechanism and when new technology requires new policies you get incredible hardship. Virtually every major problem windows ever had sprung from it's marriage of mechanism with policy. Why do you think it took them 20 years to implement the bare beginnings of proper multi-user support ? Because the policy of single user was tied fundamentally into the mechanisms of the system 20 years earlier.
And what does systemd offer as a rational reason for violating this ? Nothing.

It violates the rule that applications should always expect simple clear text as input, and produce simple clear text as output. That rule is so fundamental to the flexibility and power of unix that to break it at the init level is to completely destroy that power. If systemd becomes universal, linux will lose all the marketshare it gain in every market, and lose it to unix systems that kept the rule - because the next breakthrough in technology will require adaptations - which systemd will have made incredibly hard.
More-over, it weakens what you can do with the system - the ability to string commands together in utterly arbitrary ways via pipelines have allowed a relatively small set of primitive applications to serve literally ever conceivable user need, exactly by NOT trying to conceive of every possible user need - but providing the means to construct whatever solution you could possibly want on the fly.
And what rational reason does systemd offer for this ? Nothing.

And those are just two out of a very long list.
The argument that the unix was is "too complex" is not new, people have been making that argument for the entire 36 years since Unix was first invented, they have always been proven wrong -because even if it's true, the reality is that the trade-off is worth it, because it creates a system where anything and everything is possible - including the one thing no other system has EVER managed: to survive fashions.

Re:I guess they realised...

[Uecker]

The Wayland API is nothing like X11 except in broad concepts that all display / input APIs share - listening for input events, connecting to a display, creating a drawing area and so on. It's just that Wayland's map onto modern concepts such as GPU surfaces and compositing so that rendering is as efficient as possible.

I disagree. Wayland is essentially a subset of what X11 can do. It is based on sending messages over a unix domain socket and sharing buffers. This is exactly what modern X clients also do. This is no surprise: It was designed to support exactly what is needed for modern clients and no more with the explicit goal to get rid of everything else. But it does not add anything which you cannot also do in basically the same way with X.

As for the primitives, nobody has ever said they slow modern clients. The point is that clients don't even use the primitives any more and its the same story applies for most of the rest of X11.

This is true. This is about retaining backwards compatibility.

It has a 1980s 2D-centric, damage based view of the desktop and extensions are used to fool it into supporting surfaces and composition.

Extensions are nice way to make modern rendering possible without breaking backwards possibility. "fool" "2D-centric" "1980" is just FUD to make it sound bad, but X supports modern applications just fine. You have no technical argument.

But those extensions are workarounds which are design compromised by the architecture and so they are slower and less efficient than they would be.

Because modern clients work essentially in the same way on X as on Wayland,nothing is slower or less efficient. Just because some API is based on an extension or not doesn't make it faster or slower. This is simply FUD.

Hence the push for Wayland. It will ultimately lead to a more lightweight and responsive desktop.

No. Mostly, it will break backwards compatibility, and remove features. The few kilobytes on unused drawing API in X11 will not make any noticable different on desktops (or mobiles) with gigabytes of ram.

Re:I guess they realised...

[silentcoder]

The ability to use a DIFFERENT logger is not a bug, in fact that feature is the reason Unix has survived for 40 years - because no matter how technology changed, no matter what hardware changes we saw, no matter what new demands were placed on it, you can meet them by swapping out just one or two simple components.

It is possible - only when every component is independent and simple, so you CAN swap out components individually and everything else still just works.

Re:I guess they realised...

[Anonymous Coward]

"decrepit and inefficient" The universal way do describe wonderful, stable, thoroughly tested and super efficient code by people who want to write their own replacement.

Re:I guess they realised...

[Anonymous Coward]

Care to point out a couple of those bugs?

Okay, sure.

1. It does next to nothing.

I'd argue that's a feature, not a bug.

Re:I guess they realised...

[31eq]

You may put bugs in your init scripts if you edit them with emacs, but you'll find everything works a lot better if you switch to vi.

Re:I guess they realised...

[Slay]

Care to point out a couple of those bugs?

Okay, sure.

1. It does next to nothing.

I'd argue that's a feature, not a bug.

To elaborate, init is not doing nothing, it is providing some essential services:
it provides an attachment point to the kernel for orphaned child processes that would otherwise end up outside of the tree.
it performs essential resource cleanup for orphaned zombie processes, among other things allowing reuse of the PID by future processes.

Re:I guess they realised...

[Anonymous Coward]

where init really was a bug ridden piece of garbage

I don't see how a program whose main purpose is to reap zombie processes and can be implemented in under 20 lines of code can elicit such a strong judgement.

Perhaps you're talking about something else than init(8)?

Re:I guess they realised...

[vadim_t]

Since systemd was mentioned I figured that sysv init + rc scripts was implied, otherwise it's not a really fair comparison.

Re: I guess they realised...

[Anonymous Coward]

You can't, Obviously.

Re:I guess they realised...

[vadim_t]

I have no problem with shell scripts. I just don't see the point in keeping 20 copies of the same script, slightly customized. It's much cleaner to have a systemd style config file, where the file only contains what's important, and lacks any boilerplate content that might or not have been customized.

What kind of flexibility are you talking about, by the way? I've been using systemd for a while and don't really feel limited.

Re:I guess they realised...

[vadim_t]

then rejecting it requires a strong, rational argument - and even the best such arguments are likely to hold only in very rare niche cases.

There are quite a few reasons. For instance, like I already mentioned, sysv init has no logging and bad error handling. Processes may disappear without any logs being emitted. PID files may result in services not properly restarting. It's not a very reliable system, it's fragile and can break in ways that require you to manually do its job.

Consistency is not in any way enforced, for instance the S/K system means that changing from runlevel 1 to 2, and from 3 to 2 can result in different things running.

Performance can be much improved, because there's no parallel startup in many implementations and no on demand loading.

Processes are not tracked, if you see some mysterious process in the process list, the system doesn't help you figure out what service it belongs to. systemd uses cgroups and always knows what a process belongs to.

Things like CPU and memory limits have to be hacked in by hand, rather than being supported by the system itself.

And the problem with systemd is it violates virtually every one of the principles of that philosophy and offers NO rational reason for ANY of the violations - and it isn't doing so in a niche where perhaps some of those principles are genuinely not applicable, it's doing it to the heart of the system.

The sysv init reached the end of its life. There is a reason why Ubuntu, Apple and Solaris (which is by the way True Unix, which nevertheless decided that init scripts were getting rusty) moved on to better things. This isn't even new, it's been coming for ages. Dependency systems and parallel boot have long been a feature added on top of sysv init in Linux distros, but it rarely worked perfectly.

Why do you think it took them 20 years to implement the bare beginnings of proper multi-user support ? Because the policy of single user was tied fundamentally into the mechanisms of the system 20 years earlier.

Unix wouldn't have fared much better if it didn't have multiuser from the start. It's a fundamental part of the API, you can't just graft on multiuser to something that didn't have it before. Take for example that on a multiuser system there are access restrictions. An application made for an initially single user system will often poke to deep into where a multiuser system can't allow it to, and a flexible policy isn't going to save you from that.

It violates the rule that applications should always expect simple clear text as input, and produce simple clear text as output. That rule is so fundamental to the flexibility and power of unix that to break it at the init level is to completely destroy that power. If systemd becomes universal, linux will lose all the marketshare it gain in every market, and lose it to unix systems that kept the rule - because the next breakthrough in technology will require adaptations - which systemd will have made incredibly hard.

Hah. Linux lost market share to OS X, which by the way has a very systemd-like service system. Interestingly nobody seems to have got turned off by that.

More-over, it weakens what you can do with the system - the ability to string commands together in utterly arbitrary ways via pipelines have allowed a relatively small set of primitive applications to serve literally ever conceivable user need, exactly by NOT trying to conceive of every possible user need - but providing the means to construct whatever solution you could possibly want on the fly.

Um, systemd isn't about to take over the commandline. Pipes still exist, you know.

In fact, systemd makes it easier to string stuff together. You can trivially make even a single line script into a systemd service in about a minute. sysv init is rather more involved.

Re:I guess they realised...

[DrXym]

I disagree. Wayland is essentially a subset of what X11 can do. It is based on sending messages over a unix domain socket and sharing buffers. This is exactly what modern X clients also do. This is no surprise: It was designed to support exactly what is needed for modern clients and no more with the explicit goal to get rid of everything else. But it does not add anything which you cannot also do in basically the same way with X.

Trying to say that just because it uses sockets makes it like X11 doesn't make it so.

This is true. This is about retaining backwards compatibility.

Right... so we must maintain backwards compatibility for barely used functionality even when it impacts on performance in the every day use case. And even when you can have backwards compatibility by running Xwayland or by running X11 without Wayland while everyone else enjoys a better experience.

Extensions are nice way to make modern rendering possible without breaking backwards possibility. "fool" "2D-centric" "1980" is just FUD to make it sound bad, but X supports modern applications just fine. You have no technical argument.

It's not FUD, it's true. X11 is from an age where the screen screen was a bitmap and every window to be a region in that bitmap. When you moved one window over another the server would throw out damage events and every client would repaint their areas. And x, y coordinates for mouse moves were simple transforms from screen to window coords.

This model is totally discordant with a modern compositing desktop. X11 has gained a compositor extension which is hacked into this model but underneath it still thinks the same way. So the compositor must duplicate state from X11 except sometimes windows might be scaling or otherwise not where X11 thinks they are. So all the x, y mouse coords are screwed up and don't map properly. Oh and because the compositor is a separate process it means extra context switches in and out of the damage event so the server can preserve its worldview.

In Wayland the compositor, server and window manager are the same process. So the state isn't duplicated or mismatched and compositing does not require a context switch.

Because modern clients work essentially in the same way on X as on Wayland,nothing is slower or less efficient. Just because some API is based on an extension or not doesn't make it faster or slower. This is simply FUD.

Wrong. X11 incurs more context switches than Wayland to recomposite or to handle input messages. There is a simple diagram that demonstrates this point.

No. Mostly, it will break backwards compatibility, and remove features. The few kilobytes on unused drawing API in X11 will not make any noticable different on desktops (or mobiles) with gigabytes of ram.

Run X11 over Wayland if you want backwards compatibility or start the desktop with the X11 backend. There's no reason your esoteric needs should impact on the experience everyone else suffers from. And thankfully that reality will soon be realized.

Re:I guess they realised...

[Anonymous Coward]

I imagine it can work if set up properly. "All the real functionality is in distribution specific scripts, which means you need to research and write a script for each distribution you want to support, each with its own particular features and idiosyncracies."

Re:I guess they realised...

[fisted]

But that still wouldn't be a fair comparison because systemd does so many more things not remotely related to sysvinit+init scripts. So what are we going to compare, systemd vs init+scripts+httpd+ntpd+consolekit+policykit+this+and+that?

Do you understand the problem, now that it's staring you in the face?

Re:I guess they realised...

[vadim_t]

But that still wouldn't be a fair comparison because systemd does so many more things not remotely related to sysvinit+init scripts. So what are we going to compare, systemd vs init+scripts+httpd+ntpd+consolekit+policykit+this+and+that?

Yes

Do you understand the problem, now that it's staring you in the face?

I don't see any problem.

Re:I guess they realised...

[Anonymous Coward]

Systemd is no monolithic. You could conceivably replace the logger with a compatible one, so it's different yet the same. You just don't like it that it's packaged together, presumably you also hate distributions.

Re:I guess they realised...

[vadim_t]

using a binary system log

$ cat /etc/systemd/journald.conf
# This file is part of systemd.
...
[Journal]
...
#ForwardToSyslog=no

Change that to "yes", and there you go.

using binaries for helper programs

start-stop-daemon was written in C last time I checked. So was bash, and awk, and perl and a whole bunch of other stuff system scripts use.

and xml files for configuration (what's wrong with using shell scripts and flat text???)

Try actually looking at the config files? They're INI style text files, as quoted above. Systemd in fact doesn't depend on libxml at all, so I have no clue where you got that from.

Thirdly, it violates the very thing that underlies nearly every single component of UNIX or a UNIX-like operating system: have tools that do one single thing and do it well.

Who cares? Apple, Ubuntu and Solaris also have or had systemd-like init systems. In fact, Solaris is a true UNIX system, certified and all, and it has SMF, which seems to be a quite similar idea.

Re:I guess they realised...

[silentcoder]

No, I don't like that it requires replacement with "something compatible" - ANYTHING that can accept a message should be compatible.

Re:I guess they realised...

[silentcoder]

Right... because the only alternative to systemd is SysV - actually I am in favor of parallel init and helped Richard Gooch worked on his back in circa 2000.

The fact is though - none of those ended up replacing half the damn base system with other components. Every other init replacement was an init replacement. The end.
Upstart was very nice, hell even slackware's RC based one was quite nice and lacked most of the issues you raise (though it didn't support paralel bootups out of the box I added support for those to OpenLab back in 2005 with trivial effort).

That's just it though - if any component didn't do EXACTLY what I want, I want to be able to swap THAT component out with anything else I choose, or write, and the init system has no business telling me what that should be.

The pipeline concept fundamentally depends on not violating one of the principle unix philosophy rules which systemd does not honour: everything should always be clear-text. Never store data in a binary format. It is NEVER a good idea. The sole justifiable exception to that rule is relational databases and I'm not even sure it was a good idea to make that exception. Everything should always be editable with standard tools. And nothing, should EVER be strongly coupled, weak coupling only.

Let me give you an example of why systemd is really a problem. A few years ago I worked for a company that build an application which, among other things, needed to know about ip-phone registrations on the network from CISCO hardware. As it happens the CISCO hardware does not expose this information in any sane way - but it DOES log it via syslog and can send those via the syslog protocol to another system.
There's just one problem - when a site comes online, it is incredibly common to have tens of thousands of phones registering in a matter of seconds. No syslog system out there could (at the time anyway) handle 40-thousand messages arriving in 5 seconds, and reliably log them all.

And we had to process these, and could not afford to lose a single one. So we wrote our own syslog daemon, that was backed by a powerful queueing system which could get the whole bunch and queue them up so the application could process them and add the phones to the database.
An incredibly niche requirement, absolutely, but being able to meet that niche by simply writing our own replacement for a core OS utility which met our unique needs - that's WHY Unix runs the internet, and systemd harms that. No harm, no matter how minor, can be tolerated of that - because if we lose that, we will lose everything.

We are not trying to compete with MacOSX. Nobody sane runs servers on MacOSX. The desktop is important, but we cannot and shouldn't try to get it by becoming what the desktop OS's are, if we can't offer what's unique and powerful about our system there - then what's the point of being there at all ?

Re:I guess they realised...

[vadim_t]

That's just it though - if any component didn't do EXACTLY what I want, I want to be able to swap THAT component out with anything else I choose, or write, and the init system has no business telling me what that should be.

You ARE aware that systemd is configurable, right? You can ask it to direct your data to syslogd (where you can use your own implementation), you can configure it to log only to RAM (for maximum performance for the case you mentioned), and you can tell it to turn off its own logging (so it all goes to syslog and nowhere else)

The pipeline concept fundamentally depends on not violating one of the principle unix philosophy rules which systemd does not honour: everything should always be clear-text. Never store data in a binary format. It is NEVER a good idea. The sole justifiable exception to that rule is relational databases and I'm not even sure it was a good idea to make that exception. Everything should always be editable with standard tools. And nothing, should EVER be strongly coupled, weak coupling only.

The point of the binary format is that it's indexed and quickly seekable. You can search it by date, by service, by boot, etc. You don't need to wonder what to grep for and whether LVM ever logs something without the string 'LVM' in it (in fact it does) -- there's a service for LVM, and anything it logs can be found under that.

If you want to grep/sed/whatever it, then journalctl outputs the data in text, so you can do that to your heart's content. This even has some nice things to it, for instance the output is customizable. It'd be more comfortable to grep with ISO 8601 timestamps? There's an argument for that. You want the data in JSON? There's that too.

Also while binary, it's an append only format, which means that if it does go wrong it's not going to do anything to the data that's already been logged.

Re: I guess they realised...

[silentcoder]

None of those are good enough reasons to violate a fundamental unix design principle thats been in place since Thompson's earliest experiments.
I cant edit the log with vi ? Then you broke unix. Its not unix anymore.
Cant imagine why anybody would possibly want to edit a log by hand ? Neither can I but thats the point: fundamental to the unix philosophy. We never ever try to imagine what a user may need to do or why. We do not do that. We let them do whatever they want exactly by not trying to imagine what that will be: because that way the system is never limited to what we can imagine.

There is nothing you cited worth losing that for. And formatted text is fine. Why not store it in json then ? You could get all those features without losing text as a format.

I should not need a specific tool to get the text. You should never ever have data that cannot be accessed by every tool you have. No work arounds required.

Re: I guess they realised...

[vadim_t]

None of those are good enough reasons to violate a fundamental unix design principle thats been in place since Thompson's earliest experiments.

Oh dear. Unix turned into a religion. I guess we're going to disagree here because I'm not religious and don't care about staying true to the doctrine.

I cant edit the log with vi ? Then you broke unix. Its not unix anymore.

That's actually entirely intentional. journald contains a way to sign log files in such a way that it would make tampering detectable.

Why not store it in json then ? You could get all those features without losing text as a format.

First it wouldn't be as quick to access, second it would take a lot more space. An 87 byte log line (in the format normally seen in /var/log) turns into 1085 bytes of JSON. There's quite a lot of data stored in there.

But I guess if you want that anyway you could try submitting a patch. It's an open source project after all.

Re:I guess they realised...

[Uecker]

I disagree. Wayland is essentially a subset of what X11 can do. It is based on sending messages over a unix domain socket and sharing buffers. This is exactly what modern X clients also do. This is no surprise: It was designed to support exactly what is needed for modern clients and no more with the explicit goal to get rid of everything else. But it does not add anything which you cannot also do in basically the same way with X.

Trying to say that just because it uses sockets makes it like X11 doesn't make it so.

This is not what I said. I said Wayland is similar by design to a subset of X because it is designed that way. Domain sockets and sharing buffers matters because those things essentially determine the performance.

This is true. This is about retaining backwards compatibility.

Right... so we must maintain backwards compatibility for barely used functionality even when it impacts on performance in the every day use case. And even when you can have backwards compatibility by running Xwayland or by running X11 without Wayland while everyone else enjoys a better experience.

Unsubstantiated claims: 1. It does impact performance in every day use case. 2. people will enjoy a better experience.

Xwayland will certainly not be everywhere (it already isn't), breaking compatibility in practice. Also Xwayland is only one direction of compatibility. Wayland clients will not work with X. And yes, I think maintaining compatibility is important.

Extensions are nice way to make modern rendering possible without breaking backwards possibility. "fool" "2D-centric" "1980" is just FUD to make it sound bad, but X supports modern applications just fine. You have no technical argument.

It's not FUD, it's true. X11 is from an age where the screen screen was a bitmap and every window to be a region in that bitmap.

How is it relevant from what age X11 is? It isn't. X has a very open and flexible design and has been extended many times to adapt it to new use cases without breaking compatibility. That things were done differently originally does not matter as long as you can do it differently today.

When you moved one window over another the server would throw out damage events and every client would repaint their areas. And x, y coordinates for mouse moves were simple transforms from screen to window coords.

This model is totally discordant with a modern compositing desktop.

And yet, X supports a modern compositing desktop just fine.

X11 has gained a compositor extension which is hacked into this model but underneath it still thinks the same way. So the compositor must duplicate state from X11 except sometimes windows might be scaling or otherwise not where X11 thinks they are. So all the x, y mouse coords are screwed up and don't map properly.

For some reason, it works just fine in practice.

Oh and because the compositor is a separate process it means extra context switches in and out of the damage event so the server can preserve its worldview.
In Wayland the compositor, server and window manager are the same process. So the state isn't duplicated or mismatched and compositing does not require a context switch.

You could merge all that stuff into a single process without changing the protocol on wire. Not that I think it would make any noticeable difference. But if it matters form some gamer who wants to play a game in a rotating and wobbling window or something, this could certainly be done... But I would like to see benchmarks first.

Because modern clients work essentially in the same way on X as on Wayland, nothing is slower or less efficient. Just because some API is based on an extension or not doesn't make it faster or slower. This is

Re:I guess they realised...

[Richy_T]

Definitely. I remember being excited going from a 486 to a Pentium and how much it sped up the X session (which was already snappy enough to work with). It seemed like zero lag user interaction was just around the corner. Instead, we joined Windows in its laggy unresponsiveness. This wasn't just PCs either, even an Atari ST could run a usable monochrome X server. Instead of thoughtful coding, it's frameworks all the way down now.

Re: I guess they realised...

[silentcoder]

>Oh dear. Unix turned into a religion. I guess we're going to disagree here because I'm not religious and don't care about staying true to the doctrine.
Ah the classic "call it a religion" and you can dismiss it argument. There's just one problem - this is the exactly OPPOSITE of a religion: because it's based on solid evidence. 40 years of hard experience and engineering principles that have seen the single greatest success in the entire history of software and produced the most flexible, powerful and reliable operating system that has ever existed. You can't dismiss that as blind faith. The Unix philosophy is more like a software-world application of the scientific method than it is like religion.
If anything - everything that goes against it tends to be religious - and based on programmers casting themselves as priests who know better than users what users will need to do.

>That's actually entirely intentional. journald contains a way to sign log files in such a way that it would make tampering detectable.
If I making log files untamperable is my particular use-case, I will be happy to get a third-party tool to do that for me. Taking it away is a terrible thing to do, the developers are assuming that the use-cases THEY can think of are all the use-cases that can legitimately exist. In the entire history of software that assumption has never once been true of any program. It is literally mathematically impossible for it NOT to be a false assumption. It's arrogance, plain and simple.

>First it wouldn't be as quick to access, second it would take a lot more space. An 87 byte log line (in the format normally seen in /var/log) turns into 1085 bytes of JSON. There's quite a lot of data stored in there.
So maybe, indexing is not as useful as you initially thought ? There are plenty of other formatted text outputs without the overhead of JSON though - the colon-seperation format of the passwd file for example. We've solved these problems very well, repeatedly, for 40 years without ever having to abandon clear-text for a core utility, the argument to go against that now - when computers are faster and more powerful than ever before in those 40 years, would have to be incredibly strong indeed, and nothing presented so far has come anywhere close.
You're tearing the wings of the plane, which could be a great innovation - but you'll need to PROVE that your wingless plane can fly better. So far, the project has failed to even prove it can still fly.

>But I guess if you want that anyway you could try submitting a patch. It's an open source project after all.
Or I can do what I did do - change distros to one that doesn't use systemd. But since Linux is now the unix of enterprise, and the distros that are being used professionally have all found the dependency hell created by systemd overwhelming and given up on offering alternatives - the problem isn't solved by that, it solves it for me at home, but it leaves me dealing with it when I get to the office in the morning.

Software development is an engineering discipline and there has, in it's history, never once been a more successful set of design principles than the unix philosophy. They have stayed - not out of blind faith - but as a consequence of their incredible and utterly unmatched success. There is a reason why Unix systems have come to dominate the OS space throughout the entire breadth of devices we've invented: it's the only design that is flexible and scalable enough to do ANY job you could possibly want. Every other design ends up in the same trap: easy things are easy, hard things are impossible. Unix alone found a way to make easy things easy, hard things possible (and not very hard).
SystemD is a perfect example of the kind of changes that win a battle and lose the war.

Re:I guess they realised...

[Blaskowicz]

Of course it's useful. Why should something like cups get started without a printer? Why should the user know to enable it once they get one? These days hardware changes at runtime, and things are expected to work when you plug in a printer or a bluetooth adapter, and not to complain or stop booting if some hardware turns out not to be there anymore.

Cups should be started without a printer, because then you can print in a file, put the file on a USB stick and go to a print shop or a place with a printer :).
Or it may not know when an network or LPT printer becomes available.

That is a technicality, though.

Re:I guess they realised...

[Blaskowicz]

Run X11 over Wayland if you want backwards compatibility or start the desktop with the X11 backend. There's no reason your esoteric needs should impact on the experience everyone else suffers from. And thankfully that reality will soon be realized.

I agree but applications and toolkits etc. will have to continue supporting X11.
For now I'll keep running a 2D uncomposited X11 desktop mostly built around gtk2. Not too esoteric I believe. I want Wayland to leave vaporware status : I just don't want to use any 3D accelerated desktop on X11 (although they might be a bit too heavy on RAM and disk I/O anyway). But if I have to I'll stay on X11 till end of times.

Re:I guess they realised...

[Anonymous Coward]

Who cares if it's not speeding things up? If you want to speed things up, you can change the PROGRAM to remove bottlenecks.

What is to say that Wayland (when it eventually starts working) will be faster? Windows uses the same "paradigm" as Wayland for its operation, and there are many Windows DX games (and more OGL games) running faster under Wine on Linux than natively on windows DESPITE RUNNING ON X.

Wayland solves nothing, other than a desire to try something new.

Re: I guess they realised...

[vadim_t]

Ah the classic "call it a religion" and you can dismiss it argument. There's just one problem - this is the exactly OPPOSITE of a religion: because it's based on solid evidence.

Well, I don't see this evidence of yours.

Look at how this conversation has gone. I started by answering your technical concerns. Initially you had a real technical issue, a real need for better performance than the system originally provided, and how you needed to be able to replace the logger to solve it.

So I explained how systemd allows to do the exact same thing. You can have your syslogd if you want it, and you even have a special mode that logs to RAM that might have solved your particular issue without needing to roll your own daemon in the first place.

With that answered (since you didn't have any counterargument to the solution I provided), what's your answer? That it's no excuse, that the unix philosophy is absolutely holy and critical to keep for reasons you can't quite articulate. You keep on railing against the binary log format despite that I told you it can be disabled, as the very idea of binary data seems to offend your sensibilities.

And that's why I call it a religion. Because you've ran out of real technical concerns and now your only argument is that it goes against the True Way of doing things.

Taking it away is a terrible thing to do, the developers are assuming that the use-cases THEY can think of are all the use-cases that can legitimately exist.

I'll repeat for the third time that if you want syslogd, you can have syslogd. Maybe saying it for the third time will sink in finally.

It's arrogance, plain and simple.

Now there's something that sounds a lot like religion. When lacking a legitimate technical argument, complain of the arrogance.

So maybe, indexing is not as useful as you initially thought ?

Why would I ever conclude that? Modern computing is heavily reliant on indexing information. No need to look further than Google.

There are plenty of other formatted text outputs without the overhead of JSON though - the colon-seperation format of the passwd file for example. We've solved these problems very well, repeatedly, for 40 years without ever having to abandon clear-text for a core utility,

Sure, separate by colons data in a file with fields that can contain colons. That'll be nice and convenient to parse with awk.

And there's core stuff that has binary data. lastlog and package managers for instance. Berkeley DB is as UNIX as it gets, and I don't hear anybody whining it's a binary format. How about RRD? You probably use that for graphs, and that's binary too.

Or I can do what I did do - change distros to one that doesn't use systemd. But since Linux is now the unix of enterprise, and the distros that are being used professionally have all found the dependency hell created by systemd overwhelming and given up on offering alternatives - the problem isn't solved by that, it solves it for me at home, but it leaves me dealing with it when I get to the office in the morning.

What dependency hell? Systemd is being adopted for a very simple reason: the people who actually do the work of making distributions like it. It saves them lots of work, improves debuggability and performance, and provides additional functionality for free. At the start there was a first adopter, and they couldn't have adopted it because everybody else was already dependent on it.

It's very interesting that you have so many arguments about historical evidence but keep on ignoring the one that's staring you in the face: that the people who most directly deal with these things disagree with you.

Re: I guess they realised...

[silentcoder]

Ive spent the majority of my career building distributions. Trust me as a distro developer of some distinction (linux.com once said that I did for slackware what Ubuntu did for debian, my distro at its height ran 95% of all computers in an entire country) when i tell you i know the decision making process and the motivation for adopting systemd has absolutely nothing to do with technical superiority.

But its worthless debating you. I showed you a legitimate case for not ever integrating core utilities. You responded with work arounds. I told you work arounds are not good enough. You pretend I changed topics !
Then you give examples of binary formats nobody minds... all of them databases, the very thing I said in five posts earlier was the only case in all software where binary formats for textual data had a legitimate case.
Logs dont have the needs of databases or the constraints. Databases are an edge case. You dont apply edge case reasoning to core technology. Its bad engineering.

And here is the real issue. In the past I could swap out any utility on my box for any other utility that was compatible. This allowedfor experimentation. For competition and evolution. I could replace sysv in any distro with upstart or openrc. Nothing else would be affected. Nothing would break. Now if I try replace the init system it breaks the message bus and that breaks the desktop.

That. Is. Insane.

Re: I guess they realised...

[vadim_t]

Ive spent the majority of my career building distributions. Trust me as a distro developer of some distinction (linux.com once said that I did for slackware what Ubuntu did for debian, my distro at its height ran 95% of all computers in an entire country)

Ooh, that explains things.

when i tell you i know the decision making process and the motivation for adopting systemd has absolutely nothing to do with technical superiority.

So what is it, then?

But its worthless debating you. I showed you a legitimate case for not ever integrating core utilities. You responded with work arounds. I told you work arounds are not good enough.

An option that makes something do exactly what you want is a workaround? In what way?

You pretend I changed topics !

More like you ran out of geniune technical concerns and started ranting about philosophy.

This seems to be the main fundamental disagreement here: I just don't think that the Unix Philosophy has holy status. Hell, the Linux kernel violates it. Why aren't you running HURD, anyway?

Then you give examples of binary formats nobody minds... all of them databases, the very thing I said in five posts earlier was the only case in all software where binary formats for textual data had a legitimate case.
Logs dont have the needs of databases or the constraints. Databases are an edge case. You dont apply edge case reasoning to core technology. Its bad engineering.

A database is a nice fit for a log system. What were the errors yesterday? What are all the messages logged by this service? What was logged on Monday, between 10 and 12 AM? What are the statistics of the various types of messages? Those are all questions that a database is well qualified to answer, and the practical concerns I have when doing system administration.

And here is the real issue. In the past I could swap out any utility on my box for any other utility that was compatible. This allowedfor experimentation. For competition and evolution. I could replace sysv in any distro with upstart or openrc. Nothing else would be affected. Nothing would break. Now if I try replace the init system it breaks the message bus and that breaks the desktop.

Finally another technical matter. You are aware that dbus has multiple implementations of it, right? It's not intrinsically bound to systemd. While systemd does have its own implementation, nothing is stopping you from running another. In fact, since slackware doesn't use systemd, I imagine that's what they do.

Re: I guess they realised...

[Anonymous Coward]

They were just making a joke about how the word 'gal' was used when 'gall' should have been used.

gal (gl)
    n. Informal A girl.

gall (gôl)
    n. See bile.
    n. Bitterness of feeling; rancor.

Re:I guess they realised...

[silentcoder]

I've worked as a unix sysadmin in a shop where that meant having copies of every commercial and free unix. Hell I had two actual DEC Alphas running ! I had every version of Solaris from 8 onwards, every version of HPUX ever released and numerous linux systems there.

I'll know from bitter experience which things which unixes did best or worst. Linux had the best package managers by far for example, and HPUX probably the worst one you could ever have the misfortune of having to work with.
And as for init systems - there was nothing, absolutely nothing, that was more sheer hell to administer than SMF. SMF was a truly horrendous and unmanageable piece of crapware. Building a system similar to it is an act of sheer, calculated sadism.

Re:I guess they realised...

[vadim_t]

And as for init systems - there was nothing, absolutely nothing, that was more sheer hell to administer than SMF. SMF was a truly horrendous and unmanageable piece of crapware. Building a system similar to it is an act of sheer, calculated sadism.

Actually I never worked with SMF, so I don't know much about it besides that it exists. What I was pointing out that the deviation from the holy "unix philosophy" is getting pretty much universal, and that if the old way of things was so wonderful we wouldn't have multiple completely independent companies looking for alternatives and coming up with similar conclusions.

Certainly there are better and worse approaches of the same style. I have no love for upstart, but no issues with systemd so far.

Re: I guess they realised...

[silentcoder]

While I was quite happy with upstart.

Re: I guess they realised...

[vadim_t]

It's been a while since I had to work with upstart, so I don't remember the exact list of grievances I had with it. But I do remember that one problem I had is that it has a seriously weird dependency model that works backwards: rather than saying what you need for your service to work, your service starts when it has what it needs.

As far as system administration goes I find this is very weird and undesirable. If a service is for some reason not starting it's now my problem to figure out what it wants, and isn't getting.

I guess that given that slackware lacks package dependency resolution, it can be expected that you don't have a problem with hunting down dependencies. I, on the other hand, prefer to leave the boring and simple jobs like dependency resolution to the computer, and have more time for things that require actual brains.

Re: I guess they realised...

[Anonymous Coward]

Hey now, GNU is not Unix for a reason, leave HURD out of this wackjob's ramblings.

Re:I guess they realised...

[Anonymous Coward]

And anything that can accept it is.

Re:I guess they realised...

[silentcoder]

And what if I have legitimate reasons to want no logging at all ?

Or, as I recently discovered, I need to change the details of how a startup service installed from a repo is launched... on RHEL7 where the suggested command "systemctl edit" does not exist, and no amount of searching could find the configuration for it - it certainly wasn't in the path where google responses said it's meant to be..

I managed to find an alternative hack to remove the need to modify the bootscript in the end (I had to change which user the service runs as) but I had wasted the better part of an hour googling and reading man pages to try and figure out how to do this on a systemd RHEL7 box... this is not something that should be hard, this is such a basic sysadmin task that it should be ridiculously easy.

Yes and?

[Anonymous Coward]

It's not a 1.0 release, which means anything, even core features, can change.

Re:Yes and?

[Junta]

This is enlightment. They've never ever had a '1.0' release in decades of existing.

Re:Yes and?

[Anonymous Coward]

In general, they don't seem to be particularly good software engineers: https://what.thedailywtf.com/t...

Re:Yes and?

[Anonymous Coward]

Those knowledgeable in the horrible language of C...

That's where I stopped taking the article you linked seriously.

Re:Yes and?

[LWATCDR]

My guess is the team just does not have time to support Wayland.

Re:Yes and?

[Anonymous Coward]

I agree that passing in void* and especially void* const is quite evil (ESPECIALLY if you're supposed to be writing the documentation!), but otherwise, it's one long "I don't like C" BWAAAAAAA-fest.

Re:Yes and?

[myowntrueself]

Those knowledgeable in the horrible language of C...

That's where I stopped taking the article you linked seriously.

C isn't a horrible programming language!

Its a beautiful practical joke.

Re:Yes and?

[Anonymous Coward]

I take the guy's point. You can write good or bad code in any language, but some languages do a lot less to encourage good code that others. And for a programmer who wants to write obtuse, un-debuggable code, C has many features just begging to be abused.

Re:Yes and?

[Anonymous Coward]

And yet for that purpose, C shall never defeat Perl, the true master language of deliberately obtuse un-debuggable code.

Re:Yes and?

[Anonymous Coward]

we are two. this guy present absolutely no arguments besides his bias.

Re:Yes and?

[Anonymous Coward]

the guy in the mentioned article is a bad C programmer, he doesn't know what he is talking about!

But wait! If you can pass a const, you can pass a string literal for example, which will then be de-const’d, so you can modify it at will. Welcome to the land of undefined behavior by design!

Re:Yes and?

[OrangeTide]

My impression of EFL was that it was written by someone who uses C like a portable assembly language. That's just not highbrow enough for some people, but C does lend itself most naturally to that treatment.

Re:Yes and?

[Anonymous Coward]

typedef void(* Evas_Smart_Cb)(void *data, Evas_Object *obj, void *event_info);

(...)
And what’s with that cryptic event_info? Also – could be anything. It’s some info for some events, I guess.

another gem in the article, clearly this guy never heard about callbacks and passing private data into them.

Re:Yes and?

[Anonymous Coward]

You take that back!!!!

-Larry Wall

Re:Yes and?

[Anonymous Coward]

In general, they don't seem to be particularly good software engineers: https://what.thedailywtf.com/t...

That article made me laugh and cry at the same time.

Re: Yes and?

[Anonymous Coward]

I choked on that too but kept going. I finally stopped at the sjw dig. It's possible that enlightenment is bad code, but the author's sensibilities aren't much better.

Re:Yes and?

[TheRaven64]

His point about ownership is spot on, however. Newer EFL is starting to use an IDL so that it can integrate with other languages. I talked to the designer of it at FOSDEM. The idea that your IDL couldn't just use char* for strings (without something to indicate that these ones were null-terminated strings and these other ones were data buffers whose length is represented in this other parameter) and needed to know who was responsible for freeing pointers had not occurred to him. My interest in Enlightenment ended shortly after that: it's not just FFIs that need to know these things, it's C programmers too, and if the underlying APIs are not designed with this in mind then code using them is going to be buggy.

Re:Yes and?

[HiThere]

C is, essentially, a good portable assembler. It's barely a compiler at all, which is why it could fit on really small 8-bit systems.

For that matter, Byte once ran an article where they implemented most of C in M68000 assembler macros, so that it ACUTALLY was assembler. It wasn't all of C, just most of it, and it was too clumsy to actually use (M68000 assembler code was as readable and much more efficient), but it worked.

For that matter, LifeboatC, an i8080 compiler, really was a translator from C to assembler (a translator, not exactly a compiler) to the point that if you knew what you were doing you could drop assembler instructions in the middle of your C code and have them work properly. It emitted assembler code or (I believe, it's been awhile) could directly build an executable. But C is much more similar to M68000 assembler than i8080 assembler, so LifeboatC was rather of a tour de force. It wasn't a full K&R C, but it was quite close.

So I consider C a portable assembler, and as such quite good. I don't think of it as a good compiler language. At this point in time a good computer language needs to handle unicode characters quite well. Vala has potentials, if it ever matures. Similarly D (Digital Mars D) has potentials. If you don't need speed, Python is a good choice. Soon a good computer language will also need to handle parallel processing gracefully...but so far I haven't seen any contenders for this. Even C will do it if you don't demand grace and elegance.

P.S.: I no longer consider assembler a reasonable thing to require...either of myself or of anyone who isn't implementing things at the hardware level. C is as close to that as I consider reasonable, and even C is limiting. The complexity of code anyone can write is limited, so any complexity you can push off onto your tools should be so pushed...unless you are a tool designer or builder, or, to a much lesser extent, evaluator.

Re:Yes and?

[Anonymous Coward]

Yeah, C is just like assembler, except for structured stuff like conditionals, loops, switches, and expression parsing. Oh, and data structures, types, operators, enums, and variable scoping... but other than all that 'computer language' syntax and grammar stuff it's just like assembly!

Re:Yes and?

[myowntrueself]

http://www.stokely.com/lighter...

We stopped when we got a clean compile on the following syntax: for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

Re:Yes and?

[HiThere]

The macro assembler in Byte had conditionals, loops, etc. Don't know about switch statements. It had operators. I think it had types, and enums, but I'm not sure about structs. It had at least limited scoping.

I never used it enough to really get a handle on its capabilities, so it may well have done more than I'm saying. It *didn't* implement libraries other than assembler (no I/O, e.g.), so it was clearly not very useful. But it was over 80% of the C language, and possibly over 90%.

Re:Yes and?

[Anonymous Coward]

Actually he's right. In modern languages you typically use lambdas which capture any arbitrary state without compromising type safety. In C you just cast around stuff hoping you made it right - the compiler will never tell you.

Re:Yes and?

[Anonymous Coward]

That's actually in the language standard, so seems like he is right, not you.

Re:Yes and?

[Anonymous Coward]

Indeed, it's possible to do "high-level" or structured assembly, but leaving aside the issue of whether this is really assembly (which has been hotly debated) it's still limited by what a macro processor can do. You may as well say the C preprocessor is a portable assembler.

Re:Yes and?

[HiThere]

Yes, and it's not the real reason I consider C to be a high level assembler. The real reason is that I got tired of translating normal assembler to run on different processors. I had one piece of code that had to be in assembler (the Fortran dialects I had access to couldn't handle it) that I translated to run on everything from a CDC 3800 to an Apple ][+ to a Z-80 and when I hit the 80186 I said E****Nough, and converted it over to C. I only use a small subset of C for this, and every C dialect I've ever seen can handle it. So C is my portable assembler.

Re:Yes and?

[Anonymous Coward]

I'm sorry, but I still can't see how abstracting away the details of the machine architecture makes for a "portable assembler." This is what high-level languages do.

The fact that C abstracts away less than other HLLs doesn't make it like assembly. K&R described as a "not very high-level language," but the essence of assembler is getting close to the metal, and C doesn't give you that capability. It might be 90% equivalent to a high-level macro assembler, but only because the HLA meets you halfway.

Re:Yes and?

[Anonymous Coward]

As long as the conventions are understood and consistent, then who cares if all strings have to be null terminated or if the strings returned as static, garbage collected or must be free'd? It's your FFI wrappers jobs to do the conversion, and it's not the job of each individual library to provide support for every possible convention.
If you want to have some buggy code, try making software that does everything, including things you don't need and aren't able to test.

Re:Yes and?

[TheRaven64]

As long as the conventions are understood and consistent, then who cares if all strings have to be null terminated or if the strings returned as static, garbage collected or must be free'd?

That information has to be encoded somewhere. If your convention is that every char* parameter is a null-terminated C string that must be copied by the callee if it is expected to persist beyond the duration of the function call, then that's great (you'd better be really consistent about not using char* for arbitrary data though). Similarly, if every pointer that is returned needs freeing by the caller, then that's also fine, and you can machine-generate the wrappers on that assumption.

If you're going to create a metamodel with the primary goal of allowing wrappers from other languages, then you need to think about these things. EFL now has a metamodel intended for FFI, and it doesn't think about these things. Functions take char* arguments (and the metamodel describes their type solely as char*), which may be null-termianted C strings or blobs of data with the length encoded somewhere else. They may be held by the callee and freed later, or the caller may be responsible for freeing them. None of this information is encoded in anything machine readable.

I figured out the mystery

[Anonymous Coward]

After about 1 minute of investigation, I figured it out.

https://www.mail-archive.com/git@lists.enlightenment.org/msg05157.html

The code they had was old and unmaintained and didn't work so they removed it.

It's TEMPORARY, No Big Deal

[Anonymous Coward]

This is just a temporary change just for E19.... They have better Wayland support in E20. Explained @ http://www.phoronix.com/scan.php?page=news_item&px=Enlightenment-Wayland-Temp

Re:It's TEMPORARY, No Big Deal

[Anonymous Coward]

Temporary? With the Enlightenment Project? It took them 16 years to get from E16 to E17. Anyone know the timeframe for E20?

Re:It's TEMPORARY, No Big Deal

[Anonymous Coward]

Temporary? With the Enlightenment Project? It took them 16 years to get from E16 to E17. Anyone know the timeframe for E20?

The alpha's already out so likely not too long. I believe things really sped up after E17.

Because Wayland support is moved to DR 0.20

[Jizzbug]

See here: https://phab.enlightenment.org/phame/live/3/post/e20_alpha_release/

Re:Because Wayland support is moved to DR 0.20

[Jizzbug]

Official statement on Wayland support in Enlightenment and its libraries:

"It also is in the transition from X11 to Wayland. We are fully committed to moving to Wayland eventually as this is definitely the future of the graphical display layer on Linux."

From the Enlightenment home page.

Re:Because Wayland support is moved to DR 0.20

[CajunArson]

Thank you.
I was pretty sure there was some click-baityness occurring here, and you just proved me right.

Re:Because Wayland support is moved to DR 0.20

[Anonymous Coward]

You can't expect the submitters to actually read articles now, do you?

Re:Because Wayland support is moved to DR 0.20

[Anonymous Coward]

I guess non-Linux is doomed to an eternity of Enlightenment-less X11 then?

Just ask

[Anonymous Coward]

Why not just ask the developers why?

it's all in the commit message

[Anonymous Coward]

https://git.enlightenment.org/core/enlightenment.git/commit/?h=enlightenment-0.19&id=d9501096bfaf626699dd6a61b49be2fb96ee6713

author Mike Blumenkrantz 2015-09-26 02:53:16 (GMT)
committer Mike Blumenkrantz 2015-09-26 02:53:16 (GMT)
commit d9501096bfaf626699dd6a61b49be2fb96ee6713 (patch)
tree 729fa82c90fd58c539391575ac2534101781b8c6
parent map/unmap x11 client windows when toggling iconic state (diff)
completely remove all wayland support from build system
this is unmaintained and out of date. the protocol versions are old,
and it's extremely unlikely that any client will work and be in a
usable state given the development progress since E19 was originally
released.

use E20+ for wayland support.

fix https://phab.enlightenment.org/T2746

Re:it's all in the commit message

[TeknoHog]

Ewige Blumenkrantz! Ewige Schlangenkrantz! Hail Eris! All hail Discordia!

Re:it's all in the commit message

[Anonymous Coward]

Mit meinem Deutsch ist es nicht weit her.

Re:Europe is being overrun by Muslim hordes

[Anonymous Coward]

So you are saying that Muslims in Europe are the cause of Enlightenment dropping support for Wayland??? I knew they were savages!

Re:Europe is being overrun by Muslim hordes

[0123456]

And Linux is being overrun by hipsters who can't see something that works without wanting to replace it.

In any case, I heard they dropped Wayland support because systemd will soon be the new Linux GUI.

Re:Europe is being overrun by Muslim hordes

[Anonymous Coward]

Ain't this the truth. BSD just looks better and better. But, alas, BSD support for my hardware is not quite there.

Years ago I standardized on KDE, not because it's the best, but because I got sick and tired of suffering from decision fatigue relating to picking a DE/WM. And, KDE allows me to customize my environment easily and quickly. Having said this, I still prefer Windowmaker for its elegance and simplicity, but at work, I need to use KDE.

Wayland is about embedded

[HalWasRight]

I understand the sentiment that on the desktop X11 doesn't need replacing. But in embedded systems, X does nothing but get in the way of performance. It is the embedded community that has asked for a better way, and wayland is the "way" embedded Linux GUIs are moving.

Hey, great, Enlightenment on X11

[Anonymous Coward]

Gonna install this and party like it's 1999

What's moronic is idiots like yourself

[Anonymous Coward]

still clinging to the past and trying to justify using a TERRIBLE, TERRIBLE, codebase
full of exploitable security bugs stemming from features NOBODY uses today but
that we somehow should *support* in order not to "break compatibility".

X is a fucking disaster period. It was stupid when it was designed, stupid when it
got introduced in Linux systems and guess what? It's EVEN MORE FUCKING STUPID
today and so are all the clueless fanboys who still cling to it.

If you had a clue

[Anonymous Coward]

You'd use a real portable assembler (NASM hello?) rather than regurgitating whatever
garbage you saw somewhere without understanding one iota of it.

NO, C is not a portable assembler. Not even close. The amount of serious issues
one can run into with C that stem from different platforms/portability concerns
is *staggering*. Undefined behavior too. Compiler-specific undefined behavior too.

Compared to that whole fucking mess, Assembly is PERFECT, it has NO WARTS.
So next time you get the urge to spew "C is a portable assembler" inform yourself
on all the reasons why that's BS.

next release

[Theolojin]

In other news, Enlightenment 0.20.0-alpha includes full support for Wayland. Since 0.20.0 is coming soon(-ish), removing support from 0.19.x is simply an acknowledgment that all Wayland effort is being directed at 0.20 rather than the existing 0.19.x series.

Who uses Wayland anyway?

[Blaskowicz]

To run Wayland I guess you have to be an enthusiast or a developer (writing a toolkit, a graphics driver or a desktop environment) or some fringe Fedora + Gnome 3 user.

Let's say 0.1% users use Enlightenment, and 0.1% users use Wayland. So people running Enlightenment on Wayland could be as low as a millionth desktop linux users, thus perhaps 15 to 20 people, likely less.
Wayland is dying!

Inits

[Tenebrousedge]

So shared libraries don't exist? That hasn't been a problem in a long time on BSD or OpenRC systems. Seriously, it's not hard to factor out code into a library. If you're only considering Debian, you have to remember that they are always behind (sometimes FAR behind) the update cycle.

You're aware that OpenRC does the exact same thing as systemd here, yes? That common library is written in C like God and Dennis Ritchie intended. Similarly, they annotate their files with dependency information and other useful info; many of the anti-systemd complaints apply equally to both projects.

No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.

PID files are a bad hack. They are the reason cgroups exist, and why every other unix has replaced SysV init. And cgroups aren't even the first process tracking feature to land in Linux, just the one that actually got adopted.

The timeout is to allow startup to proceed in case of an error

So let's examine this a little. Init is the tool you use to change your system state by starting or stopping services, but it doesn't have any information about those services. It doesn't know if they're started, stopped, hung, or snake-bit. Each script has to provide that information, and while it does anything it gets the system's whole undivided attention. Sleeping in one script sleeps the entire startup. I know you know how stupid this is.

So when process tracking (cgroups) became a thing on Linux, it made sense to write a service management system built around it. If Linux had included such things at the beginning (and Eris only knows why it didn't) then we wouldn't have retarded things like PID files and we wouldn't be having this argument. But instead we have a quarter-century of technical debt. Dependency resolution is an obvious feature for a service manager, and so is parallelism -- OpenRC seems to agree. Most of the other design decisions of systemd are similarly obvious: a service manager should be able to start services on demand, or on a timer. There's no reason to look outside the ecosystem for a tool to do this, since the service manager has more information about the service and can respond intelligently if something goes wrong.

Ditching the veil of nostalgia, imagine if the roles were reversed: Linux had cgroups and something like systemd from the beginning, and J. Random Hacker proposes SysV init as a replacement: "Guys, the ability to have user-defined scripts in startup is awesome, but I want more. I want all the startup to be run as a script. The user will be in complete control, and if we don't use any Linux-specific features, we can be compatible with anything that speaks POSIX!" Or if the proposal was for OpenRC, you'd be talking about trading process tracking for broader compatibility, and you'd find the question of why Linux needs a POSIX-compatible service manager hard to answer.