cpitman

100%. I fly out of DCA/IAD, and each time weigh the options of parking at the airport and taking a rideshare service. Last time I used Uber from DCA it was much more expensive than I expected, and have been parking there since.

But what if the product is a flop? Part of the benefit of "quick and dirty" is that you can quickly verify the market and iterate on product fit.

Yeah, it is really strange. When it comes to trucking, the vast majority of the industry is individuals or very small companies with a handful of trucks. I would have though the benefits of scale would cause mass consolidation, but that isn't the case so far.

Qpid Dispatch Router/AMQP 1.0 are both very interesting technology. I actually work for Red Hat, and do use Qpid Dispatch a fair bit.

Straight Qpid Dispatch (without waypoint messages to a broker) is basically providing something similar to HTTP, as far as end-to-end acknowledgements and "synchronous" processing (as in both the client and server must be up and stay up for the lifetime of the request). No surprise, this makes it way faster than a traditional broker, while still offering similar delivery guarantees.

In enterprise environments, I more often see overuse of message brokers. I am all for targeted use of messaging systems, but what I usually see is an all or nothing approach where as soon as a team starts using messaging they use it for _all_ interprocess communication.

This has some very painful downsides.

First, traditional message brokers (ie queues, topics, persistence, etc) introduce a potential bottleneck for all communication, and on top of that they are _slow_ compared to just using the network (ie HTTP, with no middleman). I've had customers who start breaking apart their monoliths and replacing with microservices, and since the monolith used messaging they use messaging between microservices as well. Well, the brokers were already scaled to capacity for the old system, so going from "1" monolith service to "10" microservices means deploying 10x more messaging infrastructure. Traditional messaging brokers also don't scale all that well horizontally, so that 10x is probably more like 20x.

Second, performance tuning becomes harder for people to understand. A core tenant of "lean" is to reduce the number/length of queues in a system to get more predictable latency and to make it easier to diagnose bottlenecks. But everyone always does the opposite with messaging: massive queues everywhere. By the time the alarms go off, multiple queues are backing up and no one is clear on where the actual bottleneck is.

What I would like to see more of is _strategic_ use of messaging. For example, a work queue to scale out processing, but the workers use HTTP or some other synchronous method to call downstream services. Limiting messaging to very few points in the process still give a lot of the async benefits to the original client, while limiting how often requests hit the broker and making it easier to diagnose performance problems.

The limitation for train capacity is the need to maintain a "block" to ensure that a train has enough time to brake in the case of an emergency, without hitting the train in front of it. For Japan's high speed rail, it takes ~2.5 miles to stop a train.

On top of that, many railroads still operate with a static set of blocks, where the track is divided into areas called blocks that do not change over time. Only one train has essentially a lock on a block at a time. So a train has to own the block it is on, but also needs to get access to the next block early enough to avoid an emergency braking event. This reduces the capacity of a line.

There's a movement towards "moving block" systems, where railroads use sensors to track train movement and create a moving buffer around the train, which should increase capacity.

Yeah, Red Hat's products are (almost across the board) 100% open source. No "extra" features that you have to pay for.

You are describing OpenShift (https://www.okd.io), a kubernetes distribution that adds on top a lot of common needs like monitoring, log aggregation, git->image build workflow, self-service via a CLI or web console, etc.

I work at Red Hat, happy to answer questions. We also just released OpenShift 4.0, which brings in all the features from the CoreOS acquisition, like single push button kubernetes and OS upgrades.

I'll back this up, I work with enterprise customers to adopt kubernetes. I frequently have customers do installs on both AWS and Azure. I have never had a customer as much as consider GCP without me asking whether it was an option. Even then, it was uniformly dismissed. Google has a cool platform, but they've got major mindshare issues.

There are separate Case-Shiller Indexes for 20 large metro areas, as well as composite indexes for the 10 or 20 largest metro areas.

For the 10 largest metro areas (https://fred.stlouisfed.org/series/SPCS10RSA), the annual returns are the following. Interesting to note that nationally home values are over their 2006 peak values, but that in the 10 largest metro areas home values are only about even with the previous peak.

  10 Years: 3.8%
  20 Years: 4.7%
  30 Years: 3.6%

Alternatively, if you look at just San Francisco (https://fred.stlouisfed.org/series/SFXRSA):

  10 Years: 7.8%
  20 Years: 5.7%
  30 Years: 4.8%

Certainly isn't returns. Over the last 10 years, housing in the US has appreciated on average 39%, or 3.4% annually (https://fred.stlouisfed.org/series/CSUSHPINSA). Over the exact same time period, the S&P 500 with reinvested dividends has gone up ~323%. or 15.5% annually (https://dqydj.com/sp-500-return-calculator/).

To avoid cherry-picking, if we go out to 20 years housing has an average annual return of 4%, and the S&P 500 is at 6%. Go out 30 years and housing hits 5% while the S&P is at 10%.

PS, I really appreciate the Case-Schiller index used above for housing prices. It's methodology specifically targets the change in value of a house, instead of capturing overall price increases caused by house flipping, the expanding size of houses over time, etc.

When using a merge_request pipeline, GitLab defines additional variables for the run. That includes `CI_MERGE_REQUEST_TARGET_BRANCH_NAME`.

So it would look something like this:

  job:
    only:
      refs:
        - merge_requests
      variables:
        - $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

For periodic admin tasks, you might consider giving Ansible AWX a try (https://github.com/ansible/awx). It is a web interface for managing Ansible playbooks, and lets you configure jobs that another user can then execute and provide parameters. It keeps track of all run results, has a fair number of supported integrations for notifications, and can schedule runs.

I work for Red Hat, and AWX is the upstream community project for Ansible Tower, which we provide support for. AWX is one of our newer open source projects (we open sourced it after acquiring Ansible), so you'll sometimes have better luck searching for information on "Ansible Tower".

Is there any open source self-hosted CA that supports ACME? Boulder (the LetsEncrypt system) has big disclaimers in its docs about it not being a good fit for most companies.

In most large companies, issuing certificates remains a manual process. Generate a CSR, create a ticket, wait for response, download certificate, install on host. ACME seems like it should be the standard API for fixing this.

I agree, those graphs were pretty confusing. As far as I can tell, they are not showing the average time each operation takes (ie average elapsed wall time), they must be taking the length of the test and dividing by the number of operations. It would be much easier to parse if they showed operations/second instead.

In other words, 9 concurrent pregnant mothers would show 1 month/baby on those charts.

If I have that right, their comment makes more sense. After 20 concurrent requests, the overall throughput of operations/second does not increase with additional concurrency.

Part of the article calls out how the alternatives (like CRI-O) are shipping docker compatible CLIs, so that users can keep going `docker build` but with a completely different runtime.

Yeah, was going to say, Wyden is usually the "Tech" Senator. This request makes perfect sense.

Consulting is not the main driver of Red Hat revenue, the main thing Red Hat sells is Support.

Support is something enterprise customers want, and they will sign yearly contracts to get it. In return, if/when they have a production issue, 0-day vulnerability, etc, they have someone to contact (or may have contacted them!) to help them resolve the issue. And Red Hat has experts in both support and engineering, meaning resolution can be anything from a config change to a rapidly released patch. Happy customers renew year after year.

I work for Red Hat Consulting. This is a very different beast, consulting involves selling lots of short to medium term projects with the occasional long project, then trying to optimally staff those projects. You only get revenue while consultants are on the ground. It's not surprising to me that an open source company that relies only on consulting wouldn't be sustainable.

Red Hat does not have any "for-fee bolt-on addons", everything we ship is open source (or will be soon after acquisition of a closed-source company).

Responding to some of the other comments, Red Hat revenue is nearly all from providing enterprise support for completely open source software. This is critically different from "services", ie consulting. These are yearly contracts that provide clients insurance if/when they have a production issue, a new major vulnerability is disclosed, etc, that someone knows the technology from the ground up and also knows the details of their deployment and can get them back into a good state. Our support+engineering teams are top notch, so retaining customers year over year is relatively easy.

I work in Red Hat Consulting, which is a much smaller share of overall revenue. It doesn't scale nearly as well, since you only get revenue periodically for weeks to months at a time, with a lot of overhead to sell and manage assignments.

He was certainly allowed to work on it on his own time. He just was no longer being paid by Red Hat to work on it, or to travel to conferences/conventions to work on it.

Unless you can find a way to weave cryptography into light, it will always be possible to trick a video camera into recording something that is "fake". Trust is what society is built upon, we're not going to get away from it now.

I imagine it would work the same as any other information today, like press releases. Who is the source? Where did they get it from? Do I have any reason to doubt them?

Ie, the end of "trusting" videos from unknown sources with unknown reputations and agendas.

Coming off of the recent SEC case against Elon Musk, does anyone know how they look at leaks from public companies, especially high impact ones like this? Are there any examples of SEC action in the past?

Red Hat is not the example you claim, everything in our products is open source, no piece of Open Stack or RHEL is proprietary software or open core. Even when we acquire proprietary software companies, we open source everything.

This model works very well for us, but I appreciate that it can be hard to replicate.

3 miles, to escape the flooding they kept heading inwards till they found a safe spot.

I see this very much. Friends that are surrounded by dual income couples that are lawyers/doctors/etc get convinced that 300k+ household incomes are "not that much". This while being 97+% percentile for household incomes in the US.

USAA really impressed me recently with a really slick feature: I was in their mobile application, and realized that what I wanted to do was a little too complex for what the app could handle. So I called support, and they (1) automatically identified me based on my number and (2) knew I was just using the app, and asked if I'd like to transfer directly to a person!

It is probably not the most complex integration technically, but it made the experience so smooth.

Are diamond foundry's prices an accurate idea of the cost to manufacture lab diamonds? I was surprised by what seem like only slight discounts over natural diamonds.

What if it is a personal website, not affiliated with any corporation?

I sunk a ton of time into Encarta as a kid. In some ways, it still seems superior to Wikipedia.