cmbaus

Like there are no bigots in NH. When I lived in Central NH I had a long hair and almost got run out of town for being a "fucking long haired hippie"

What political factors are you referring to? I think Linux took off because it was easily accessible and widely available, and Linus made a lot of pragmatic choices.

I remember in the 90s how awesome it seemed to get a *nix system for free with a book.

But there is a radiator at the front of most air-cooled Porsches; although it cools oil instead of water.

See: http://www.pelicanparts.com/techarticles/911_carrera_oil_coo...

I do think there is a subculture of "hip" motorheads. Look at Zeitgeist (bar in SF) for instance. I think Magnus is someone who qualifies as being able to push fashion trends.

I'm wondering if early Boxsters and 996s might be good values now because there are fixes for the IMS bearing issue on the market. I've read it can be done with a clutch job.

For me it was a Subaru STI. I enjoyed it more in almost every way than the Porsche, other than how it looked. My father has a nice 90s Miyata. I've driven it quite a bit and for the money it is a pretty well thought out and fun vehicle. He's got less into the whole car than I have in my Porsche engine and trans.

Magnus's collection is beautiful and I love his aesthetic, but I can't help but think it is the ultra wealthy buyers who own a dozen 911s who are driving up the prices into the stratosphere. It might be sour grapes, but honestly, how many Porsche's does one guy need?

I have a vintage 911. It is fun as hell when the thing is running right, but it is never running right. Even the years they call "bullet proof" don't hold a candle to the reliability of a modern Japanese sports car (which I've also owned).

When you start to pull the car apart you see all the hacks that had to be done to modernize the car to keep the original chassis design alive. My favorite is the air conditioning. It is obvious that air conditioning was not part of the original design. Another favorite is the oil cooler under the front fender. There are oil lines that go all the way from the back of the car to the front just for cooling. The original car didn't have them because the engines were much smaller and ran cooler.

If anyone is considering buying an air cooled 911, I'd say unless you've cashed out a bunch of stock that is blowing a hole in your pocket, stay away. With the current cost of parts any common problem with the cars could easily be a $10k fix. Ask me how I know.

I like the idea. Are the shoes welted?

This looks interesting, but I don't totally understand how it works. How is the key changed every time on the server? It looks like it requires server side support.

What kind of blades does the company make? Are they multi-blade?

Harry's is a great idea, but I've been happy with double edge razors for a while now: http://baus.net/shave-kit

This is a new idea. Wondering where I should take it next. I would appreciate feedback.

That's interesting. I had been working something similar years ago. I eventually open sourced it, but discontinued work on it. Http://github.com/baus/swithflow

I'm surprised more systems don't take this approach of doing more work in L7 proxies.

This is a good idea. I could see this changing C development for the better.

Cordovan is not a fussy material. It is meant to be worn hard, everyday.

I'm a big fan of horween and alden. If you care about quality and craftsmanship, then I think the products are worth the price (even if it has gone up a lot in the past few years). It is possible to wear out cordovan, but you really have to work at it. Horween shell is an awesome material.

This is a really good way to put this distinction. Most applications use threads because they are waiting on I/O, not because they are concurrently processing.

I'm using asoftmurmur now. I think it is the best noise generator out there. Who cares what the code looks like?

> OpenSSL has an abstraction layer over malloc, which uses an internal stack-based free-list, and which it uses for all allocations

To be clear, this is NOT TRUE. The freelist is used for some allocations, but not in the patch in point. Here is the patch that addresses the bug: https://github.com/openssl/openssl/commit/731f431497f463f3a2...

It clearly uses OPENSSL_Malloc which is basically the equivalent of calling malloc.

https://github.com/openssl/openssl/commit/731f431497f463f3a2...

Here's where the freelist operations are defined: https://github.com/openssl/openssl/blob/21e0c1d23afff48601eb...

But where are they called from?

Update: To answer my own question the freelist is used in

    ssl3_setup_read_buffer()
    ssl3_release_read_buffer()
    ssl3_setup_writer_buffer()
    ssl3_release_write_buffer()

This is not the same as universally replacing the allocator.

I believe there is some confusion (at least I was confused until I looked at the code) that the library had universally replaced malloc with another allocator. While the library allows users to provide their own allocator, it is not done by default.

The code in question does not use the freelist implementation. It goes directly to OPENSSL_Malloc which is basically malloc.

What happened was the exploit allowed remote clients to read beyond the size of the buffer allocated by OPENSSL_Malloc. There just happened to be data from the freelist sitting next to it.

Even if the freelist implementation wasn't used, that wouldn't have prevented this exploit. There would just be something else sitting there in memory, but we can't predict what that would have been.

There is a big discussion going on that could be misleading.

To clarify, are we calling the freelist implementation, which the heartbeat code does not use, an allocator?

Update: I agree with the author that it is wrong to point the blame at the freelist implementation. If every C application that manages the reuse of commonly used data structures is doing wrong, then pretty much every modern server application will have to be re-written -- for instance Apache [1].

C is fast and portable and binds to just about any language which is why OPENSSL is in such wide use. Maybe it would be better to use more 'secure' languages like Go, but if OPENSSL was written in Go, how many applications would use it? I'd say almost none.

[1] https://apr.apache.org/docs/apr/1.5/group__apr__pools.html

> So the focus on the self-written allocator seems to get a little biased in this discussion.

I feel like I'm missing something here. Where are the self written allocators? This article states that the OPENSSL_Malloc is simply malloc by default.

There was some discussion here[1] that OpenSSL had implemented their own allocators, but doesn't seem to be the case. As this article points out, a quick review of the code will show that OPENSSL_Malloc() is simply malloc by default[2].

[1] https://news.ycombinator.com/item?id=7565064

[2] https://github.com/openssl/openssl/blob/a898936218bc279b5d7c...

Regarding point #5. If the performance of OpenSSL was terrible we would not be having this discussion. This is system level component which must pass all encrypted traffic.

OpenSSL is ubiquitous and runs everywhere including phones and low powered VPSs that everyone is using. If OpenSSL burned RAM and CPU cycles for the sake of correctness, alternatives would appear. The hard part about developing a library like OpenSSL is it has to be fast AND secure.

I'm sort of surprised an allocation occurs every time the heartbeat is sent. That is a lot of trips to the heap.

I'm not very familiar with how TLS heartbeats are implemented, but I wonder if the buffer could have just been alloc'd once when the connection was created.

Depending on the language, delegation can be faster. For instance in C++, virtual function dispatch is slower than calling a non-virtual member. It is easier for the compiler to optimize member function calls vs virtual functions which cannot be inlined.

To clarify, what concerns me is that by adding syntax that is similar to Java, developers coming from other languages (namely Java), won't take the time to understand the differences between the two languages and continue to write applications as they would in Java.

Everyone has their biases, and my bias would be to embrace the dynamic and functional aspects of the languages that separate it from Java, rather than creating new syntax that pastes over the fact that the language is fundamentally different.

In JavaScript, like other duck typed languages, you have dynamic dispatch without inheritance.

For example:

    var objA = {doIt:function(){console.log('hello from a')}};
    var objB = {doIt:function(){console.log('hello from b')}};
    
    var doItDynamically = function(doitObj) {
        doitObj.doIt();
    };
   
    doItDynamically(objA);
    doItDynamically(objB);

a and b do not share a common class (since classes do not exist in JavaScript), but they implement the same interface. For this reason, they can be used polymorphically, as if they shared a common base class or interface in Java or C++.

I am bit concerned that the standard committee is going to make the language worse while trying to fix it.

Yes it is inconvenient to do traditional OO programming with JavaScript, but I'm not convinced that is a bad thing. Encouraging subclassing, as pointed out by the author, could actually be detrimental.