breser

Yup, when I talk about stability I'm not talking about stability of function, which I presume is what people buying OpenShift want. I'm talking about stability as in few changes. Anyone doing things in the Container space shouldn't be expecting lack of changes, even if you're using OpenShift.

A fork can imply many things, but all supersets are forks. I realize that RedHat doesn't like calling OpenShift a fork, but it fundamentally is. The only people that will maintain their additional functionality is RedHat themselves.

If you manage to avoid all of their added functionality then you can avoid the vendor lock in. But you can't avoid the delays in getting upstream features/bug fixes.

If Kubernetes was super stable and you weren't likely to want any of that stuff I would agree it probably wouldn't be a big deal. But it's not. Significant improvements are coming in every single release.

RedHat is managing a decent pace in keeping up with Kubernetes for now. But all that it takes to upset that apple cart is for something to get added in a way that breaks their additional functionality.

If RedHat doesn't have the clout to get their improvements in upstream, why should I presume they have the clout to avoid their additions won't be broken by other changes?

OpenShift is a fork of Kubernetes. Case in point. OpenShift has functionality called a Route. That isn't in Kubernetes. Kubernetes of course went and added something similar called ingress.

This means that anytime Kubernetes does a release that RedHat has to manage merging all those changes in with their local changes that aren't part of their project.

This is exactly the same sort of thing that RedHat does with their Linux kernels. It's exactly why you RHEL has been such a terrible platform to run Docker on. Because RedHat is only pulling in some of the upstream changes into their kernels rather than upgrading everything.

This sort of merging is slow, error prone and costly. If you use anything that they've added that isn't in the upstream it creates vendor lock-in. Sure OpenShift's Route code is open source, but you can't take that to any other vendor without building everything yourself. Want that new feature in the latest Kubernetes release, you better be prepared to wait.

As time goes on it will become harder and harder for them to maintain this fork. If OpenShift doesn't become the dominate Kubernetes distribution then RedHat may lose interest in it and then you'll lose your maintenance of that fork. For that matter, if RedHat loses the maintainers as employees they may lose their ability to maintain this fork.

It's my opinion that anyone buying OpenShift is playing with fire.

The fact that RedHat has failed to get their modifications integrated upstream and have to maintain themselves is a massive failure on their part. This sort of thing was understandable in the past, but we really should expect more of them now.

You made me curious, I've had mine since Feb 2011. So 6 years for me.

Probably because Li-ion batteries don't have much of a memory effect and don't discharge on their own much.

I don't think there is such a thing as a less flammable alternative, ultimately you're storing a lot of energy. Energy means potential for fire.

Finally, I doubt these have the same chemistry as what they're putting in cars. There are a lot of Li-ion chemistries that are suited to different applications. It's more of a class of chemistries than a single specific one. Some Li-ion chemistries are cheaper and heavier than others but have longer lifetimes.

Maybe my view here is somewhat jaded on distro versions since from the time 2.4 was released it was serveral years before major distros actually were shipping it. Some of that was just coincidence that 2.4 was released right after several distros froze for their major versions.

But yes the difference between patch versions is usually quite small.

Yes that is very much the case, but people are still using these things.

In my experience it really comes down to NGINX is trying to position themselves as a replacement for load balancers like F5's BigIPs. So they have functionality that goes well beyond what you'd call an HTTP Server. For instance Layer 4 proxying rather than just Layer 7 proxying.

But that's just my experience at work. I'm sure there's a ton of other reasons. I can't say that I really agree with your list. I actually find Apache's documentation to be much better, I find myself needing to go read the code to figure out some behaviors with NGINX quite often still. Process isolation with CGI can be equally done with Apache httpd as with NGINX. I can't say I'm familiar with NGINX's caching behavior in detail since we're not using it. Also not sure what you mean by vhosting ecosystem since I see the design as pretty similar, unless you mean the upstream configuration.

And the reason distros do this is because modules like mod_php and mod_perl have historically not worked well with other MPMs. As far as I'm aware this should be resolved with newer versions of Apache and the modules. Also historically the MPM was built into the server and required a rebuild, but newer versions provide the MPM as a loadable module. But the distros have very long upgrade cycles and are hesitant to change their defaults since they don't want to break peoples existing setups.

If you care about performance then you probably don't want to use the distribution's copy. People tend to use NGINX's distributions directly from NGINX or build it on their own. Since NGINX didn't have dynamic loadable modules until recently that drove more people to build their own copies.

I do think it's fair to say that NGINX has a reputation for getting better performance out of the box without configuration. However, it doesn't take long before you have to start tweaking it as well in my experience.

So I don't think some peoples impressions of Apache are entirely unfair but I don't think they are entirely fair either. But this shouldn't surprise anyone given that NGINX is a business and has a marketing department. Apache is a foundation and really doesn't market like NGINX does.

Full disclosure: I'm a committer on the Apache httpd server.

I hope this is sarcasm. Apache has support for the same event driven model that NGINX has. Since most people get their copy of Apache from their distribution they're often getting a rather old version of Apache. NGINX has taken good advantage of this to imply that Apache is out of date.

I happen to also use NGINX at work. What I'll say is it has it's own set of problems. There are various reasons to choose one or the other for a particular problem. But the idea that Apache httpd is obsolete is nonsense.

You'd have to find collisions that are of an identical length and still be useful (i.e. able to do something evil rather than just being a bunch of random data). The current techniques for creating collisions in SHA1 don't make it possible to find identical length collisions. So your statement that nobody has bothered to spend the money to create the collisions is not correct.

Now if you want to say that nobody has spent the time to find a technique to produce identically sized collisions, that would be correct. But that's far from trivial and we don't know that such a technique is guaranteed to exist.

Calling Tesla just another car company is really missing the boat on their business. Tesla started as a car company. It's how most people are aware of them. So I don't really blame you for this mistake.

However, Tesla today is an integrated energy company. They make Solar Cells (the part of the business formerly called SolarCity), Stationary Battery Systems (generally referred to as Tesla Energy) that range in size from residential to grid sized and of course cars (which ultimately also use batteries).

Comparing them to car companies is like comparing Amazon with bookstores. Yes Tesla is a car company and yes Amazon is a bookstore. But both both of them are so much more than those simple comparison.

In fact I suspect the Amazon comparison here is rather apt because Amazon is now in the situation where Amazon Web Services is essentially able to prop up the retail business. I suspect Tesla Energy will be able to prop up the car business in the near future.

Where the heck are you living that your house's value increased by an order of magnitude over 20 years. I live in one of the hottest real estate markets in the country, I bought in 1999 and my house is just barely under doubling in value. If not for the mess of 2008 it might have been worth more, since it was about where it is now before that crash. But I can't think of any place where people have seen an order of magnitude increase in 20 years.

Over a longer period (essentially a lifetime) I'm sure that's a possibility. So I suspect you've simply chosen your time period poorly.

But it's not a refundable credit. Which means you get whichever is the lowest of your tax liability or $7,500. Please note saying it's not refundable is term of art that does not mean what you might take it to mean. So let's walk through some examples.

Let's say your total tax liability for a year is $10,000. You paid in $11,000 via Payroll and other taxes. Without the credit you'd be due a refund of $1,000. If you are eligible for a $7,500 credit because you bought a Tesla you'd be due a $8,500 refund.

Let's say your tax liability for the year is $5,000. You've paid nothing in taxes for the year (probably because you knew you were buying the car and didn't need to). You bought a Tesla which makes you eligible for a $7,500 tax credit. You do not get anything refund from the IRS, but the $7,500 tax credit offsets your entire tax liability.

So just because it's a credit doesn't mean the credit is effective for low income people. You have to have enough income to have a high enough tax liability to even get the full $7,500.

I see a lot of people debating free speech rights. There's a simple solution to this. Don't write the law such that it's illegal to ask the question. Write the law such that it's illegal to use the information in hiring decisions or determining how much to pay. If the people involved with making those decisions have that information consider that prima facia proof that the information was used that way.

Now they have their free speech rights. They can indeed ask the question. But parties responsible for certain things cannot have access to that information.

Most reasonable companies will simply not bother to ask rather than jumping through the hoops to do so. But further most people won't have a reason to ask because the information can't be used for the normal reasons to ask.

My employer asks this question. I refused to answer when asked in person/phone. As we got further in the hiring process they asked as part of the form they fill in to setup the background check. Again I refused to answer this question. I failed the background check due to this.

When we discussed it they said it was necessary so they could verify if I had lied about my salary when I'd given it previously. I pointed out that I had never given this information. HR insisted that I must have since they require it. Round and round we went for a while.

Eventually they let it go and hired me anyway.

So to answer your question. Companies will typically call up your previous employer and ask if the salary you provided them is correct.

Lying on your application form is almost always cause to fire. So if they ever find out you lied you about your previous salary you can be fired on the spot.

SmartThings is Z-Wave and Zigbee compatible. SmartThings is just a hub to control devices that work on those protocols. If you decide you don't like SmartThings anymore for whatever reason you just replace it with a different hub that also supports whatever protocol you've got devices for.

Graphite's pickle format does this: http://graphite.readthedocs.io/en/latest/feeding-carbon.html

We ran into a similar issue when someone was trying to send a line protocol data to a pickle port.

Yes this format stinks.

Your comment was addressed in the session on Shield at AWS re:Invent. You were indeed correct they've been doing it for a while.

That's not exactly true. You can renew it before it expires. You just can't renew it until it is nearly expired. I think it's like a 2 week window or something like that.

The bigger complaint about StartSSL should be that if you need to revoke the certificate you have to pay for it.

For a free service though I don't think their requirements are too terrible.

If you read the Wired article I linked earlier you'll see that this is indeed a concern since the updates aren't signed. Tesla is relying on the two way verification of their VPN that is used to communicate between the car and Tesla to validate the software.

You can opt out but I don't know of anyone that has. Their language suggests you might not get updates, but I think that language is more of a cover every possibility than reality. They always install updates when the vehicle is serviced anyway. So it's not like you're entirely blocked from updates if you do opt out.

From https://www.teslamotors.com/about/legal

    Rights and Choices

    We give you many choices regarding our use and
    disclosure of your personal information. You may opt 
    out at any time and free of charge from:

[snip some irrelvant bits]

    Any processing of personal information for which you 
    have provided your prior explicit opt-in consent by 
    contacting us as indicated in the "How to Contact Us" 
    section below.

    Our collection of Tesla vehicle data. If you no longer 
    wish us to collect Telematics Log Data or any other data 
    from your Tesla vehicle, please contact us as indicated in 
    the "How to Contact Us" section below. Please note
    that, if you opt out from the collection of Telematics Log Data or 
    any other data from your Tesla vehicle, we will not be able
    to notify you of issues applicable to your vehicle in real 
    time, and this may result in your vehicle suffering
    from reduced functionality, serious damage, or inoperability, 
    and it may also disable many features of your vehicle 
    including periodic software and firmware updates, remote 
    services, and interactivity with mobile applications and 
    in-car features such as location search, Internet radio, 
    voice commands, and web browser functionality.

    Our collection of real-time traffic feature data. We 
    only collect this data if the real-time traffic feature is 
    available to you and you elect to use it. If you no longer 
    wish us to collect or share data from your vehicle for this 
    feature, you can stop this collection at any time by simply 
    turning the feature and the data collection off via the 
    "TRAFFIC-BASED ROUTING" setting in Controls > Settings > 
    Apps > Maps & Navigation.

There's a much better article on Wired that goes into more details: http://www.wired.com/2015/08/researchers-hacked-model-s-tesl...

It's also worth noting that Tesla pushed a patch to all of their cars for this yesterday.

Your battery sizes for the cars is way off. The Model S has come with a 60 (no longer available), 70 and 85 kWh battery. The 240 mile vehicle is the newer 70 kWh battery.

70 is 7 * 10. 7 * $3500 = $24,500.

Model S is using NCA (Nickel Cobalt Aluminum). It's not clear if the stock Panasonic batteries have the same battery chemistry (they might but Panasonic doesn't share their battery chemistry), but we do know that the Tesla batteries are not exactly stock Panasonic batteries. They have casing modifications made to them for Tesla's purposes.

I think it's probably time to point to a different link though. Given that there are now pictures of bodies (albeit pixelated on the page).

Here let me help you here. Your comment should read. "Pretty much everything we hear through the media is propaganda." There much better now.

I think Firefox is actually wrong. They do have long standing open bug on this with a lot of, in my opinion, nonsensical arguments. [1]

RFC 6125 [2] says that DNS-IDs should be fully qualified domain names and points you at RFC 1034 [3] for a definition (which doesn't have a definition sadly).

RFC 1034 does specify the difference between complete (or absolute) domain name and a incomplete (or relative) domain name, with complete domain names including the trailing dot. As best as I can tell the first use of Fully Qualified Domain Names (FQDN) came from RFC 1535 [4]. It doesn't really define the term either but proceeds to use it and mentions "absolute 'rooted' FQDN" in such a way that it implies that absolute is adjective. Finally, we get to RFC 1594 section 5.2 [5] which tries to clear up the matter and describes a FQDN in a way that would seem to agree with your usage (requiring the trailing dot), while giving examples that omit the trailing dot. The Wikipedia article on FQDN [6] says otherwise that the trailing dot is necessary. So at best the definition of FQDN is ambiguous in my opinion which means the RFCs don't help us much here with determining the proper way of handling the trailing dot with respect to PKIX certificate validation.

However, I think that there are some conclusions we can draw using some common sense and thinking about the implications of the behavior.

1) Hostnames are commonly used without the trailing dot. As long as they only are missing the trailing dot they are still fully qualified. They may not be absolute and are still relative to the root.

2) Nobody issues certificates with the trailing dot in the common name. It doesn't make much sense for the RFC to be defined in a way that is entirely incompatible with the existing certificates. Especially since it went to such an effort to define how to deal with the old Common Name sytle and not only the newer SubjectAltName style.

Maybe they should have been using absolute hostnames in order to allow everyone to distinguish between certificates that were issued for relative domains but they don't. In general I don't think CAs should be issuing certificates for relative domains.

Mozilla's own CA Certificate Inclusion Policy [7] disallows certificates being issued that are not absolute domains. It does so by saying "the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate." I can't fathom how issuing a certificate based on a relative domain say "www" could ever be compliant with that.

3) What's the worst that could happen if you allow a match on "www.example.com." to the certificate with "www.example.com" in the CN or SNA? Well not much because the trailing dot forces you to the absolute hostname which happens to be what the CA issued the certificate for.

You can't (assuming a search domain of "example.org") ever end up at "www.example.com.example.org" and therefor be matching the wrong domain because of the trailing dot tells the resolver not to do that. If a browser does do that then they have a separate bug.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=134402 [2] http://tools.ietf.org/html/rfc6125 [3] http://tools.ietf.org/html/rfc1034 [4] http://tools.ietf.org/html/rfc1535 [5] https://tools.ietf.org/html/rfc1594#section-5 [6] http://en.wikipedia.org/wiki/Fully_qualified_domain_name [7] http://www.mozilla.org/en-US/about/governance/policies/secur...

GCC support in XCode has been less and less GCC and more and more just the LLVM cleverly disguised as GCC. With XCode5 there is nothing left from the actual GCC project, even gdb has been entirely replaced with lldb. So now if you chose GCC in XCode you're not really using GCC at all.

Yes it's replaceable. I've used it with newer builds from the open source project. They even provide binaries and instructions: http://clang-analyzer.llvm.org/xcode.html

If by replaceable you mean using some other analyzer, I'd say it's not easily replaceable but if you can produce an analyzer that produces similar output and that's has the same options, then sure. clang in fact did that sort of thing with their gcc driver.