These were Twitter engineers who had once worked at Google: John Sirois, Travis Crawford, and Bill Farner. They told Hindman that they missed Borg, and that Mesos seemed like the perfect way to rebuild it.

He and his fellow engineers continued to run Mesos as an open source software project, but at Twitter, he also worked to move the platform into the company’s data center and fashion something very similar to Google Borg.

라이버트 CEO는 트위터의 엔지니어링을 이끌었던 인물이다. 그는 트위터의 신규 서비스에 모두 메소스를 사용하도록 했다. 트위터를 떠난 후 에어비앤비에서 메소스 상에 분석 환경을 구축했다. ETL 관리와 스케줄리을 위한 크로노스 아파치 메소스 프레임워크의 주요 저자기도 하다.

• Repeated Serialization - A tuple is represented as a collection of plain old Java objects. The Java objects are converted into byte arrays using either Kryo or Java serialization. The byte arrays are again serialized when included in a protocol buffers object used for data exchange between stream managers and Heron instances.
• Eager Deserialization - The stream manager is responsible for receiving and routing protocol buffer tuples. When it receives a tuple, it eagerly deserializes it into a C++ object.
• Immutability - To simplify the implementation and reasoning, stream manager does not reuse any protobuf objects. For each message received, it uses the malloc allocator to allocate a protobuf object, which it then releases back to the allocator once the operation is completed. Instead of modifying the protobuf in place, it copies the contents to a newly allocated message, makes the modification on the new message and releases the old one.

• ~17% of the CPU is used to create/delete a protobuf object from memory allocator (not including those protobuf objects allocated on stack).
• ~15% of the CPU is used to copy a new protobuf object instead of updating one in place.
• ~18% of the CPU is used to eagerly deserialize a protobuf message, despite the fact that eager deserialization is not needed; instead we could just handle the byte array.

• Added a separate memory pool for each type of protobuf message thereby reducing the expensive cost to create/delete a protobuf message.
• Changed an internal data structure that caches tuples from std::list to std::deque to facilitate preallocation of protobuf messages.
• Optimized away the code that was duplicating the protobuf message to do in-place update whenever possible.
• When a stream manager receives a message from another stream manager, instead of eagerly deserializing the inner tuple message, it now transfers the underlying serialized byte array directly to the instance.

After 3.0, we’ll take this even further: we will release 3.x versions monthly.  Even releases will include both bugfixes and new features; odd releases will be bugfix-only.  You may have heard this referred to as “tick-tock” releases, after Intel’s policy of changing process and architecture independently.

The primary goal is to improve release quality.  Our current major “dot zero” releases require another five or six months to make them stable enough for production.  This is directly related to how we pile features in for 9 to 12 months and release all at once.  The interactions between the new features are complex and not always obvious.  2.1 was no exception, despite DataStax hiring a full time test engineering team specifically for Apache Cassandra.

We need to try something different.  Tick-tock releases will dramatically reduce the number of features in each version, which will necessarily improve our ability to quickly track down any regressions.  And “pausing” every other month to focus on bug fixes will help ensure that we don’t accumulate issues faster than we can fix them.

배시 (Bash, Bourne-again shell, 본 어게인 셸)은 본 셸을 대체하는 자유 소프트웨어로서 GNU 프로젝트를 위해 브라이언 폭스(Brian Fox)가 작성한 유닉스 셸이다.^[2][3] 1989년 발표되어 GNU 운영 체제와 리눅스, 맥 OS X 그리고 다윈 등 운영 체제의 기본 셸로 탑재되어 광범위하게 배포 되었다. 또한 DJGPP와 노벨 넷웨어에 의해 도스로 이식되었고 시그윈과 MinGW의 배포로 마이크로소프트 윈도로 이식되었다.

Easy Deployment (on EC2)