Become a fan of Slashdot on Facebook


Forgot your password?

Comment: Re:debian digital signing and the GPG keyring (Score 1) 90

by Uecker (#49751135) Attached to: NSA Planned To Hijack Google App Store To Hack Smartphones

this is why debian has the GPG key-signing parties, and why all packages are GPG-signed by the package maintainer when they compile it, why the ftp masters sign the package when it's uploaded, and why the release files which include the checksums of all the packages are also GPG-signed.

Sorry, this is almost completely worthless without reproducible builds. (which finally some people started working on in debian) A compromised build host of a single debian developer (of which there are how many?) could easily introduce backdoor into a binary package which could be very hard to detect.

But because we have gaping security holes in essential crypto and with the low quality of software in general this is a mood point anyway.

Comment: Re:Snowball effect (Score 1) 469

by Uecker (#49635755) Attached to: Why Was Linux the Kernel That Succeeded?

I am more a fan of Linus than RMS myself, but your comments about RMS are far off. The GPL allows for-profit use. In fact, adding restrictions to only allow non-profit use is incompatible with GPL.
Also RMS created highly successful projects. Ever heard of gcc, emacs, ...? Linux would probably not exist without gcc. So far these projects seem to do quite well.

Comment: Re:With the best will in the world... (Score 1) 486

by Uecker (#49563425) Attached to: Audi Creates "Fuel of the Future" Using Just Carbon Dioxide and Water

Regardless of the efficiency of the process, overgeneration of renewable power is still a huge problem. Germany actually pays its neighbors to take it when the wind is blowing and the sun is shining as the price of electricity between utility companies goes negative.

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.

Comment: Re:systemd is a bad joke (Score 4, Insightful) 494

by Uecker (#49545751) Attached to: Ubuntu 15.04 Released, First Version To Feature systemd

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.

Comment: Re:Define 'Terrorists' (Score 3, Informative) 230

by Uecker (#49528695) Attached to: UK Police Chief: Some Tech Companies Are 'Friendly To Terrorists'

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.

Comment: Re:I thought MSFT bought Nokia for $7 Billion (Score 4, Interesting) 66

by Uecker (#49478343) Attached to: Nokia To Buy Alcatel-Lucent for $16.6 Billion

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

Comment: Re:Soon this will be impossible (Score 2) 229

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.

Comment: Re:At least Microsoft and Slashdot listen to users (Score 1) 236

by Uecker (#49264319) Attached to: Microsoft Has Received 1 Million Pieces of Feedback For Windows 10

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

Comment: Re:Write-only code. (Score 1) 757

by Uecker (#49237835) Attached to: Was Linus Torvalds Right About C++ Being So Wrong?

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.

Comment: Re:Write-only code. (Score 1) 757

by Uecker (#49235699) Attached to: Was Linus Torvalds Right About C++ Being So Wrong?

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?).

Comment: Re:Let me guess (Score 1) 166

by Uecker (#49234981) Attached to: Google Introduces Freon, a Replacement For X11 On Chrome OS

In the X Window System core protocol, only four kinds of packets are sent, asynchronously, over the network: requests, replies, events, and errors.

That whole request / reply bit sailed over your head I see. The wire might be asynchronous but Xlib, the library that virtually all client code uses is filled with synchronous code that sends the request and waits for the reply. e.g. call XGetWindowAttributes and it will block until the response comes back.

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.

There have been attempts to use xcb instead which is an async API but it turns out writing async code is hard, particularly when dealing with legacy code and an arcane windowing system that sends out a storm of messages. It's not hard to find xcb backend projects that have floundered.

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.

It is called a pixmap.

A pixmap is not a surface. A surface is a texture under the management of a GPU (or software emulation of a GPU). X has no concept of surface.

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

It is damage based windowing system. Hence the reason for extensions to work through this.

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

If you don't see why it has anything to offer I suggest you look at the Wayland website where it explains in detail why X is broken.

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

If virtually every X developer can see the need then I don't see why others can't.

That seems to be a myth spread by Wayland proponents.

Comment: Re:Write-only code. (Score 2) 757

by Uecker (#49231487) Attached to: Was Linus Torvalds Right About C++ Being So Wrong?

Little short line of code. Surely for such an obvious, non-esoteric task, C can't be much harder, right? Any takers?

(Don't bother responding if your code can't meet all of the boldface conditions... in the real world, you can't simplify the system requirements to meet the deficiencies of your coding language)

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

"Ahead warp factor 1" - Captain Kirk