Follow Slashdot stories on Twitter


Forgot your password?
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment Re:Wayland bashing (Score 1) 151

But some 10 years ago clients started doing client rendering and just sending bitmaps to the display server. Mostly that meant higher bandwidth and fewer round-trips. Whether that is good or bad depends on the clients and the environment.

Actually they started doing that back in the 90s, the X primitives were already very outdated when KDE/Gnome launched in 1998/1999. And this is really the core issue, if you want a modern looking Linux with gradients, transparency, animations, anti-aliasing and various pretty effects you let a graphics toolkit do the job and hand X a bitmap. And they run roughly as bad under remote X as under VNC, because under those circumstances they do pretty much the same thing.

The applications that do work well using remote X are the same applications that shy away from the "render bitmaps" strategy and with their primitives they look... primitive.

The idea that remote graphics works only efficiently when sending line-drawing primitives over the network is a myth. The applications which do currently not work well are those which do have a lot of round-trips. Most of the time for stupid reason because the toolkits stopped caring about remote X. But this has nothing to do with being bitmap-based. In fact, the XRENDER extension was introduced 20 years ago (or so) to make remote X work exactly for this reason. And yes, it works. I have a special-purpose image viewer which works great remotely.

There's actually not a lot of sense in trying to make one system that'll work both for graphics hooked up over a >15GB/s x16 PCIe 3.0 link with nanosecond latency and a system with 1/1000th the bandwidth and 1000x the latency. Applications will tend to work well in just one of those two scenarios no matter what kind of protocol you wrap it in, even if it's theoretically network transparent. If it wasn't being used, it wouldn't be the fastest interlink we have in modern computers.

I also do not think this is true. A discrete GPU on a PCI buys is for all intends and purposes remote to the CPU. The programming model is the same as remote graphics: You send commands over the network/PCI bus. You try to do this in batches/asynchronously to avoid latency overhead and instead of copying data all the time one manages buffers on the remote side.

Comment Re:Wayland bashing (Score 1) 151

I've read the codebase. Mostly to discover the grey areas in the protocol when I was working on a X/Window server running on ms-windows. The code is not pretty but that is mostly due to being an old code base.

The X protocol has its problems and quirks too, particularly when dealing with long latency between server and client. It was designed when using high-level primitives (eg "draw line to (x,y) in color Z") made sense. When client just use such primitives the speed is impressive. But some 10 years ago clients started doing client rendering and just sending bitmaps to the display server. Mostly that meant higher bandwidth and fewer round-trips.

Bandwidth does not matter nowadays and using Xrender than drawing commands does not really use more round-trips. In fact, Xrender was exactly designed for this purpose. The round-trips come from badly-designed clients, and synchronous use of the X protocol although it is designed for asynchronous use. I have have image viewers which work perfectly fine over the network also they move a lot of pixels.

Comment Re:Wayland bashing (Score 4, Insightful) 151

The code base of X is OK. Yes, I have read the code of many different open-source projects (and some close-source). But the real problem is not the code at all, I don't mind if somebody decides it needs to reimplement the X server for some reason. The real problem with Wayland is breaking backwards and forwards compatibility with a universally supported protocol instead of carefully revising it in a backwards compatible way (which would easily be possible with extensions). This is just insanely stupid.

Comment Re:nokia already going downhill before M$ (Score 1) 88

Nokia was the largest smartphone vendor with with faster growing sales than everybody else. Not saying they didn't have trouble: There was competition entering the market, and they were in an internal state of disarray, but they had lots of options: The best one would have been to just bring a few Meego phones to market just as planned and transition Symbian developers to Meego via QT. I owned a N9 and it was really good and Android still wasn't really big at that time (and even today is still not as good as Meego was in my opinion). Ofcourse, adopting Android would also have been far better than switching to Windows phone.

Comment Re:Nokia was going downhill well before that (Score 1) 88

I disagree. They should just have executed their previous plan which was excellent: Push Meego and keep Symbian alive. Transition Symbian developer to Qt and then to Meego with Qt. Meego was very good and obviously ready (they released the N9 in the same year after anouncing the switch to Windows phone). I still consider the N9 a much better phone than my current Android phone. And people tend to forget: Android wasn't nearly as big as today. At that time Nokias was still the biggest smartphone vendor and had faster growing smartphone sales than all other vendors. Of course, after Nokia imploded Android quickly filled the void.

Comment Re: Eugenics (Score 1) 93

Abortion, of which I'm pro, is already a step towards eugenics. In 200 years, many diseases will have ceased to exist because of this.

Down's Syndrome has already been reduced over 90% in Europe, and by about 70% in America. The American parents almost certainly include a number of hypocrites, since 44% of Americans think abortion should be illegal.

Down syndrome happens by change so it will not cease to exist in the future just by having abortions today.

Comment Re:There's a very cool live version also (Score 4, Insightful) 179

shell scripts are great. They are flexible, powerful, transparent, easily changeable, debug-able ... With systemd you have a blackbox and have to learn magic keywords. It is like windows - for idiots - not for hackers. Yes, the shell script based system sometimes was a mess. But the solution is to clean the scripts up not to replace them...

Comment Re:a pointer to VLA is a bounded pointer type (Score 1) 208

Which has nothing to do with VLAs. A regular array (or any other data struture) can also be allocated on the stack or on the heap. In both cases this can decided by the programmer (by placing the array on the stack or on the heap). I don't know of any C compiler which would allocate a VLA defined as local variable (on the stack) using malloc behind the back of the programmer.

Comment Re:That reserves memory, it doesn't add bounds che (Score 1) 208

This does not reserve memory. This declares ptr to be a pointer to an array of length 256. This is exactly what a bounded pointer is. And yes, compilers can sometimes detect out-of-bounds accesses at compile time (not only for literals) and because out-of-bounds accesses are undefined behavior, there are free to add run-time bounds checking when the pointer is de-referenced. And this is exactly what the undefined-behavior sanitizer for clang and gcc does if you use it. I know, because I fixed this for gcc because it wasn't working.

    void foo(int n, char (*buf)[n])
                    (*buf)[n] = 1;
    int main(int c, char* argv[])
                char buf[10];
                  foo(10, &buf);
    $ clang-3.5 -fsanitize=undefined -O3 c.c
    $ ./a.out
    c.c:4:2: runtime error: index 10 out of bounds for type 'char [n]'

Slashdot Top Deals

We are experiencing system trouble -- do not adjust your terminal.