Forgot your password?
typodupeerror

Comment: Re:Throwing out all compatibility hooks makes it e (Score 1) 164

by cnettel (#47030715) Attached to: 30-Day Status Update On LibreSSL

If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.

As a person making their living writing software for MacOS X and iOS, do I care about this code running in MacOS 9? I don't care one bit. They explain it very well: You don't need to be "multi-platform" if you are standard. Instead of "we have thirteen implementions of SSL_memcpy that run on a dozen completely outdated platforms that nobody cares about", they use memcpy and say "if your platform doesn't support a standard C function correctly, fuck you and your platform". Which is the correct approach.

A slightly more pragmatic approach is to keep those implementations, at least the most crucial ones, but please make sure that you use memcpy etc directly on any sane modern platform.

Comment: Re:Throwing out all compatibility hooks makes it e (Score 1) 164

by cnettel (#47030707) Attached to: 30-Day Status Update On LibreSSL

What is so difficult to understand, and why is everyone getting their knickers up in a bunch over it?

The OpenBSD project used to be pretty rude to a number of people (mostly you could understand why, but that doesn't justify). While some of this is just ignorance much of it is likely people wanting to get back at them and people from the various security services trying to spread dissent.

Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).

He's bitching, whether he realises it or not. He didn't point to a single instance of Alpha support slowing down other platforms. His analogy doesn't apply just because they provide portability. It applies if providing portability to old platforms such as the Alpha slows down the development of OpenBSD, which it probably occasionally does and on the other hand probably keeps people interested in developing on their old Alpha machines contributing and so overall has a positive effect.

I haven't watched the full talk (yet), but previous outlines of what OpenSSL did reeked of a Javaesque approach, provide such a thick runtime library on top of the OS, that you don't really need to care about what the platform gives you. That gives you a great portability story, once the layer is in place. The bad thing is that you do not benefit from the specifics of the platform. If you let your portability/base layer rot, you are also behind everyone's game. What's happened during the last 5-10 years is a lot of work to make the C standard library (or slight variations of it), as well as base system calls, much more hardened, to some extent providing security in depth. The LibreSSL critique has been based on the fact that OpenSSL went with their home-rolled, slightly inferior, slightly unpredictable (not handling NULL values in places, at least not in the same way any sane platform did, etc) layer for far too many things, even on modern platforms. As a provider of a platform with security in mind, I can understand the frustration of having a crucial library saying "hey, we don't care about that stuff, we can implement everything we need".

Comment: Re:PRACTICAL zero emission aircraft (Score 2) 160

by cnettel (#47013885) Attached to: Airbus E-Fan Electric Aircraft Makes First Flight
The power output of a Boeing 747 is 140 MW according to a slightly unreliable Wikipedia list. Now, this is probably the total engine output, but you would certainly need a significant fraction of that in electrical power for propellers. Note the other number in that list? A full Nimitz-class destroyer is 190 MW (that seems to be electrical power). A nuclear submarine does not even come close. The cooling environment of that 20 ton reactor is probably quite different, too. You can cool off the rector coolant against the ocean. Not so at 30,000 feet.

Comment: Re:How did OpenRISC not have atomic ops until now? (Score 2) 77

by cnettel (#47001603) Attached to: OpenRISC Gains Atomic Operations and Multicore Support

yes, you do. in a preemptable OS, in a multi-threaded app, you need atomic operations to share data between threads, as any read-modify-write operation on shared data gets wrecked when it is preempted between the read and the write.

Furthermore, what is atomic in terms of context switching preemption is not necessarily atomic in terms of memory bus arbitration. The two can usually coincide, but they don't have to.

Comment: Re:Actually it's both. (Score 1) 360

The one question I still have is why the flow stops at 41,000 ft. I would have expected a kind of spring effect, followed by the lower portion of the siphon slowly descending as water vaporizes off the pre-apex portion, allowing the water in the lower part to descend while maintaining the same vapor pressure. I'm sure it is my failure to understand, so if anyone can offer a better explanation please do so!

I think it does. The time scale is just staggeringly different. Watching a water surface dry, and one with low area versus the volume, at that, is a boring activity. Put some table salt in a glass and fill an identical glass with water. Put some lid over it all. The equilibrium state will be more water in the initially empty, salt-containing, glass, than in the one originally containing water. Why? Because of the change in boiling enthalpy. But that change, and the formation of a water film or drops on all other surfaces in the enclosed volume, is immensely slow anywhere near room temperature.

Comment: Re:Function call overhead (Score 1) 231

by cnettel (#46403549) Attached to: Bug In the GnuTLS Library Leaves Many OSs and Apps At Risk

Nested blocks are refactorable into smaller functions.

And the program eats the function/method/message call overhead, the overhead of passing all local variables as arguments, and the overhead of constructing and destroying an object through which to return multiple values from each function call.

I think you need to be introduced to a modern optimizing compiler. It will handle the first two for you, just fine, as long as you are in the same compilation unit (or doing fancier global optimziation). Since you just refactored this from a single function, you are supposedly still in the same compilation unit. If you pack the data in something like a stack-allocated struct even the last one will be reduced or completely avoided.

Comment: Re:Freedom is better than dependency. (Score 1) 231

by cnettel (#46403509) Attached to: Bug In the GnuTLS Library Leaves Many OSs and Apps At Risk
The Apple library itself was open source, right (although rebuilding the OS files would be precarious in OS X and outright impossible in iOS)? The mess with libraries like this (proprietary or not) is all other code (proprietary or not) that not only link to shared objects provided with the OS, but roll their own, sometimes even modified, build of the library. Now, thanks to the fact that it's GPL it cannot be hidden in a blob without at least a license notice, but tracking it down everywhere will be a mess. And then we haven't even got started about embedded systems...

Comment: Re:Gravity wells and other distance issues (Score 1) 330

by cnettel (#46319647) Attached to: Japanese Firm Proposes Microwave-Linked Solar Plant On the Moon
Go to the company website instead. They say lunar resources and are able to tell the difference between kms and miles. However, it's all a bit pie in the sky even there. Even with the advantage of lunar resources, I would be more optimistic about geostationary orbital solar power. Microgravity would mean that you could get away with really thin structures, even concentrated thermal solar might make sense if you can work out a reasonable cooling part of the cycle (just make an extremely thin mirror as the bulk of the concentrator).

Comment: Re:is that really better than earth based? (Score 1) 330

by cnettel (#46319615) Attached to: Japanese Firm Proposes Microwave-Linked Solar Plant On the Moon

Solar insolation on the moon is not dramatically higher than on Earth - around 1400 W/m^2 versus around 1000 W/m^2 on Earth. Granted, a Lunar solar station wouldn't be affected by weather, but Earth based receivers will suffer from efficiency loss during bad weather.

Could they achieve the same result by building a bit larger system on earth, but without the hundreds (or thousands?) of rocket launches it would take to get the materials to the moon to get the thing started?

Besides, who wants to see a big black ribbon around the moon?

They plan to use lunar materials, so no hundresds of rocket launches to get started. I guess the point is kind of that real estate and raw materials are "free", if you get the proper manufacturing equipment up there. If that equipment is automated enough, you can build up slowly, but steadily.

Comment: Re:Just don't do it (Score 1) 526

by cnettel (#46204725) Attached to: Customer: Dell Denies Speaker Repair Under Warranty, Blames VLC

How about putting a filter (low-pass/high-pass - I'm not an audio engineer, so I don't know) to stop any of the "damaging" waveforms from reaching the speaker? It's probably just a capacitor or inductor in line with it and you could get away with the same shoddy speaker that wouldn't blow from the clipped signal.

And in all likelihood you would have (non-negligible) worse sound performance for any sane waveform you played. BTW, you could easily script a mechanical hard drive to power off and power on, all the time, for days and days. I am pretty sure a lot of drives would fail in the first year and I would honestly not want the manufacturer to honor the warranty if the total power on count exceeded half a million (powering on once per minute every minute for a year), even though it was all "legal instructions given to the machine".

Comment: Re:Intel's version of a IBM/Sony Cell CPU (Score 1) 208

by cnettel (#45869749) Attached to: Intel's Knights Landing — 72 Cores, 3 Teraflops

Plus writing software that uses 72 cores is such a walk in the park

Some stuff actually is. It depends on how trivially parallel the problem is. With some stuff there is no interaction at all between the threads - feed it the right subset of the input - process the data - dump it out.

More importantly, for some applications a limited amount of very low-latency/high-bandwidth communication is enough to give spectacular performance improvements. In those cases, the fully coherent x86 model, kept up by this kind of cache and memory architecture, will do wonders, compared to an MPI implementation with weaker individual nodes, but also possibly against (current) nVidia offerings. It's harder to say how it will stack up against Maxwell.

Comment: Re:Not going to work (Score 1) 208

by cnettel (#45867569) Attached to: Intel's Knights Landing — 72 Cores, 3 Teraflops
20 years? I would be very doubtful regarding any prediction beyond the point where current process scaling trends finally break. Note, they might break the other way. Switching to a non-silicon material might allow higher frequencies which will again shift the tradeoff between locality, energy, and production cost. But there is no reason, no reason at all, to expect the current style to last for more than ten years, while you could be quite right that it could stay much the same for the next five years or so.

Comment: Re:Seems reasonable. (Score 1) 262

by cnettel (#45794837) Attached to: Linux x32 ABI Not Catching Wind
Not really. For an x32 binary, you would have x32 libc and use all the fancy features. For an x86 binary running on an AMD64 processor, you are still stuck in "compatibility mode" on the processor, even when you enter libc, which means you can only use actual x86 instructions (with the smaller register file etc). It is my impression that on-the-fly switching between long and compatibility mode within the same proecss would still incur a cost that's comparable to (at the very least) a kernel mode transition, so the benefits would only exist for very few operations. Large memcpys wouldn't be among them, since the x86 vector instructions are actually quite fine for that purpose.

You see but you do not observe. Sir Arthur Conan Doyle, in "The Memoirs of Sherlock Holmes"

Working...