I would say that statement is highly misleading. While there a negative prices sometimes on the spot market, this does not not mean that most power exported on the day are sold at negative prices. Most exports are based on long-term contracts, and not affected by negative prices on a short term market at all.

I think the big deal is how decisions are made: In the past, somebody would write a new software and people who liked or needed it would start to migrate to it. Then later it may become the default, but other software would still continue to work and be supported for a long time. Nowadays, a decision is made somewhere and changes are pushed to users who do not want it, while support for alternatives is dropped quickly. So in the end, I think it is a question of software freedom in a very real and practical sense.

Nonsense. Many important allies of the US such as Germany and France opposed the invasion. The veto of the Russians was not a slap in the face (this is business as usual). A slap in the face was that the foreign minister of a close ally directly questions the "evidence" for WMD presented officially as justification to invade a foreign country.

They didn't run their mobile phone business into the ground by clinging to symbian. In fact, they had a great successor already ready: Meego. They killed themselves by: 1) switching to Windows Phone, which was already failing on the market, and at that point in time was in no way competitive 2) already declaring Symbian to be dead before they had working Windows Phones ready 3) refusing to sell the N9 in major markets also it was a clear hit and could have brought in a lot of cash 4) having Windows Phones which initially had a lot of bugs and problems 5) screwing over the few customers who bought their initial Windows phones by not upgrading to Windows Phone 8, 6) having only few very similar smartphones etc....

Yes, it is still no match, but you are confusing specs with design. If one looks at the values from the TOP 500, it doesn't seem to perform bad. In the LINPACK benchmark it comes much closer to the theoretical value than other systems. To me, this is a sign of a very good design. The processor is said to be inspired by alpha. My point is: China is already building supercomputers using their own processors... They are catching up.

Looked at the TOP 500 recently?

ShenWei SW1600

This should be up-modded. Yes, we need a way for users to fund open source developers directly. I would certainly pay a few hours of development time for somebody to implement video playback support in evince. (I am waiting for the feature for years, but instead evince got a new GUI).

Yes, these are the C++ answers which I expected and they demonstrate the problem: You can only have static arrays which can live on the stack or dynamic arrays which then must live on the heap. My real world requirement (this is not a synthetic example) is to have dynamic arrays on the stack, because allocation overhead would be huge if you have to allocate temporary arrays each time you process a voxel of 3D volume. Of course, you could work around this ans pre-allocate the temporary memory outside of the loop, but this would unnecessarily complicate the design, especially when you then parallelize the loop. That C++ has no good way of doing this is simply a deficiency of the language.

I don't think that putting this on the stack is "fundamentally wrong". First of all, it is 2015: 424 bytes are not much at all. You can have Gigabytes of stack and it does not matter. On all modern systems with a MMU, it is virtual memory, so if you don't use it it does not cost you anything. With multi-threading on 32 bit there is the risk that you can run out of address space (some compilers support split stacks for this reason). On 64 bit this issue simple does not exist any more. There is no reason whatsoever to not use the stack as much as you can.

But even if you have bounded stack space for some reason (e.g. an embedded system without MMU), this not even a valid argument against VLAs at all. Dynamic arrays are not necessarily bigger than static arrays, or other stuff people are putting on the stack. In fact, the opposite is true: If you need to put things on the stack (see above) and do not have dynamic arrays, you would have to put an array of the maximally possible size on the stack. This is clearly worse.

You have a minor point that heap allocation might give you a useful error while stack overrun might corrupt some other part
of the memory. I do not think this is really true in practice though. For the following reasons:

- Usually with memory overcommitment you would not get a allocation error even on the heap, but a SEGFAULT when accessing a new page which cannot be allocated. To get an actual memory allocation error you basically have to limit your heap size.

- With a stack overrun you would also get a SEGFAULT which you can catch. You are right that there is the possibility to jump over the guard area with a large allocation, but remember, the guard area is virtual memory and on 64bit you can make it very big at no cost at all. Finally, if you really need to close this loophole, you could use a compiler which inserts run-time checks. So this is not a language-level problem at all.

But the array dimensions would be template parameters - and not be dynamic.

Also the type would look something std::array< std::array<double, 3 >, 3 > . This is a lot more complicated than int[3][3]. But again, I need int[A][B] where A and B are not constant. And this is a simple example, god forbid you need a temporary array on the stack... Maybe you can use alloca (which is not standard I think) and compute the array indices by hand.

As far as I know, there is no good C++ solution. I guess this is the reason std::dynarray and runtime arrays have been proposed for C++14 (did one of them got in?).

True. But you claimed X11 does not have async IPC.This is clearly false. Also a lot of stuff is asynchronous even in Xlib. If your point is that Xlib sucks I agree with you - but this does not imply that one needs to invent a new on-the-wire protocol.

Wayland is - as you point out - also an async API. I also used xcb myself, and did not find it too difficult. (most developers woulde use a toolkit and do no care anyway). Legacy code is not a valid criticism. Arcance is simply your personal opinion. I find the X protocol quite OK. "Storms of messages" may be true in some cases, but is not really a problem in an async API or for local clients and could also be easily adressed without rewriting everything and breaking compatibility.

I am bit puzzled why you think a pixmap could not be on the GPU.

I am not sure what this has to do with what you said before and why you think Wayland would not be damaged-based, e.g. the client also tells the compositer which part of a buffer is damaged:
wl_surface::damage - mark part of the surface damaged

I looked at the website before. I even watched the stupid talk everybody refers to all the time. I still see no real advantage.

That seems to be a myth spread by Wayland proponents.

It will also throw a runtime exception with my default version of g++ if I don't add a '-pthread' line. Why is this not a compile time error? Insane.

Not at all the same thing. This would give me templatic code for static - not dynamic - arrays.

Somebody else answered this already and I prefer the C solution. But this example seems rather contrived anyway. Let's do something much simpler: Write a matrix multiplication routine for arbitrary-sized matrices which is not allowed to use the heap.

void mat_mul(int A, int B, int C, double out[A][C], double in1[A][B], double in2[B][C])
{
    for (int i = 0; i A; i++) {
        for (int k = 0; k C; k++) {
              out[i][k] = 0.;
              for (int j = 0; i B; j++)
                out[i][k] += in1[i][j] * in2[j][k];
          }
    }
}

http://en.wikipedia.org/wiki/X...
"In the X Window System core protocol, only four kinds of packets are sent, asynchronously, over the network: requests, replies, events, and errors."

It is called a pixmap.

The extensions already exist. The thing which does this is called a compositing manager. Yes, being a separate process means there are extra context switches (if both run on a single core). I don't think this matters, but I gain, this not a problem of the X protocol. One could just integrate the compositing manager into the server if one really wanted to.

Why? You are confused: I just continue to use X. No need to re-implement anything.

In X there are no differences between local and remote applications and there are powerful and generic ways in which local and remote programs can interoperate. This makes a much better protocol in my opinion. Yes, on low-latency links performance sucks, but one can always use VNC and RDP or XPRA on top of it. But one never gets the ful integration and flexibility of X back when using the other protocols, so they are no replacement.

I am not crying. In fact, I am happy with X. I just point out that I don't see how Wayland has *anything* to offer for a desktop user. Not even performance. But it has disadvantages: And breaking compatibility is most serious one. XWayland only solves one direction (running X clients on Wayland) and not the other (running Wayland clients on X). Finally, there are already mobile devices with Wayland without XWayland, e.g. Jolla. It breaks compatibility with the excellent N9, which is really stupid.

I do not think that X is badly engineered. Quite the opposite.

Cairo, for example, is considered to be so good that it has been proposed that it becomes part of the ISO C++ standard.
I guess if it were still called Xr, people would hate it just because they "know" from reading Phoronix tha everything
related to X is bloated and slow.