LVM on top of hardware RAID?

I have RAID5 disk and recently added new 2 disks to the server as RAID1 configured.

LVM is configured on the RAID5 disk and I would like to extend the logical volume to include RAID1, newly added one.

Are there any data corruption or lossing risk?

What happen if one of disk in RAID5 or RAID1 is broken?

https://redd.it/cduyjf
@r_linux

i386 Salvation - Support information for the i386 architecture
https://github.com/prahladyeri/CuratedLists/blob/master/lists/x86_salvation.md

https://redd.it/cdveuq
@r_linux

Why we don't use Docker

When you don’t have clients, you don’t have to follow the herd. You cut your own path. And that is what we do. Every day.

Technology is a solution to a problem. And our problems are quite unique. As a low-latency proprietary trading firm, we need systems that strip-away complexity and for us, Docker is not it.


**Not having clients, liberates us**

While it seems like a small detail, not having clients makes a substantial difference to how we code, compared to most companies. We trade 24 hours a day with our own capital at our own risk, in a wide range of financial products on all major financial markets globally. This means, we are only accountable to ourselves.

And our code is written exclusively for our traders. The resulting auto trading application will run on our servers, monitored by our application engineers. This is quite unique and amazing position to be in: nobody influences our choices when it comes to technology! While many companies are being pushed to use various languages or frameworks due to dependencies - or trends... -, we are not.

Which leads me to the first reason why we don't use Docker: we like consistency, and if a technology is not a perfect fit for our stack, we won't use it.

The most quoted Docker benefit, is reproducibility. Yes, our developers need production-like servers to test their code. We simply buy some more and configure them the exact same way as production.

​

**A simple, fast growing environment**

Our industry moves fast. We’re talking nano seconds. Because we offer competitive, tradable prices to market participants in all market conditions, continuously, across the world, we as engineers have to move equally fast.

We’ll discuss a new feature with our traders on Monday, have a design meeting the next day and put the feature in production at the end of the same week. There is only one way to move that fast: things need to be as simple as possible - every tiny bit of complexity that doesn't pay-off is stripped away. We always favour the simple - almost naive-version of an algorithm to an overcomplicated and over-engineered one that supposedly performs better.

This ties in nicely with our view on consistency: as our entire stack is developed in-house and uses the same set of languages and libraries, our production environment is lean, homogeneous and simple enough to not being in need of containers.

You could argue that Docker is simple to use and while this is true, for our business the added complexity of a containerisation layer between your application and the OS, by far negates all of Docker's advantages.

​

**We like fast code, running on bare metal**

Unlike other industries, we like bare metal servers and we don't use virtual machines nor containers for our trading systems. All our production code is running on Linux and bare Intel CPUs.

The reason for this choice is simple: we need to be fast, and when you want to be the fastest, virtual machines are a no-go for almost all of our applications. Like other Market Makers, we use FPGAs for the most speed-sensitive part of our business, but we still need [low latency C++](https://www.youtube.com/watch?v=NH1Tta7purM) for the code operating our trading strategies.

Over and above the FPGAs, we are also trading with full software automated trading systems on many exchanges around the world and network latency on those applications is crucial. In this perpetual fight against jitter, Docker would be the antithesis to [ultra-low latency network cards](https://solarflare.com/), userspace drivers and optimized C++.

​

**Fat binaries as a container**

Even with handcrafted C++ applications, we might hit some dependency issues: dependencies between applications, between applications and libraries, with conflicting versions. The latter is often mentioned as the reason for Docker to use a single container per application.

This problem has been effectively solved a long time ago by Linux package managers and CMake, but we didn't even need to go as far: at Optiver, we like

fat binaries!

Fat binaries is an incredibly simple, powerful (and old) way to develop and deploy binaries. Recent languages such as Golang and Rust support it as a way to containerize their noscripts instead of using Docker. By "fat binaries", I refer to a binary that has been statically linked to all its dependencies. It doesn't seem great at first glance, I know.

There are a few reasons for this choice:

* *Simplicity of deployment*: the same way a Docker container runs your application with all its dependencies in an isolated environment, a fat binary doesn't have any external dependencies (except libstdc++ and libc)
* *Safety*: when you test a binary, you are certain that you are testing the exact same code as the one that will run in production. This might seem paranoid, but [you could imagine why](https://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stock_trading_disruption).
* *Performance*: static linking will always be faster: at the very least you will skip a jump through the PLT, at most you can benefit from in-lining

The main downside with fat binaries is that the binary itself is bigger - still much smaller than a Docker image... - this is not a problem for us at all, as we deploy them on our servers. Our main automated trading system is thus a binary around 150MB, 14MB stripped. Again, if the size would ever be an issue we could strip them, but so far it isn’t, so we don't.

​

**Tech fetishes are real**

Some engineers out there, get so hung-up on the technology, they forget to consider the context. For us, that is working backwards. We don’t contain our options by starting with a set container tech ;-). We consider the problem first and build from there.

This way of thinking is real, it’s called having a tech fetish, and we see it surprisingly often. Especially during interviews. And as you can probably guess, it's not our cup of tea.

​

David Gross,

Engineer at [Optiver](https://www.optiver.com/eu/en?utm_source=reddit&utm_medium=blog-post&utm_campaign=optiver-eu-tech-blog-david)

https://redd.it/cdw9om
@r_linux

Proxmox VE 6.0 release with Ceph Nautilus and Corosync 3
https://www.proxmox.com/en/news/press-releases?view=article&id=133:proxmox-ve-6-0&catid=11:news

https://redd.it/cdvp0b
@r_linux

Office 365 declared illegal in German schools due to privacy risks.
https://arstechnica.com/information-technology/2019/07/germany-threatens-to-break-up-with-microsoft-office-again/

https://redd.it/cdxb6w
@r_linux

ZFS on Linux still has annoying issues with ARC size
https://utcc.utoronto.ca/~cks/space/blog/linux/ZFSOnLinuxARCShrinkage

https://redd.it/cdwl7m
@r_linux

Proxmox VE 6.0 released
https://forum.proxmox.com/threads/proxmox-ve-6-0-released.56001/

https://redd.it/cdy6my
@r_linux

Reproducing the Linux builds of Firefox 68
https://glandium.org/blog/?p=3923

https://redd.it/cdz56w
@r_linux

Using LightDM with an External Monitor on a Laptop or the Multi-monitor Setups
https://chaoticlab.io/posts/lightdm-extmonitor/

https://redd.it/cdxjks
@r_linux

How Suse is taking open source deeper into the enterprise
https://www.computerweekly.com/news/252466754/How-Suse-is-taking-open-source-deeper-into-the-enterprise

https://redd.it/cdzwpa
@r_linux

Btrfs gets cleaned up & code refactoring for Linux 5.3
http://lkml.iu.edu/hypermail/linux/kernel/1907.1/05873.html

https://redd.it/ce292e
@r_linux

Tor Mode Add-on proposal for Firefox
https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/Notes/FirefoxTorUpliftAndTorModeAddOn

https://redd.it/ce2z91
@r_linux

Snȯwflake: an addon by the Tor Project that lets you help censored users access the Tor network by just installing it!
https://snowflake.torproject.org/

https://redd.it/ce4d10
@r_linux

Flatpak devs close issue about supporting CLI apps
https://github.com/flatpak/flatpak/issues/1188

https://redd.it/ce5bis
@r_linux

Weekly Questions and Hardware Thread - July 17, 2019

Welcome to r/linux! If you're new to Linux or trying to get started this thread is for you. Get help here or as always, check out r/linuxquestions or r/linux4noobs

This megathread is for all your question needs. As we don't allow questions on r/linux outside of this megathread, please consider using r/linuxquestions or r/linux4noobs for the best solution to your problem.

Ask your hardware requests here too or try r/linuxhardware!

https://redd.it/ce7uqg
@r_linux

Linux Mint 19.2 "BETA" released
https://www.linuxmint.com/rel_tina_cinnamon.php

https://redd.it/ce7g9o
@r_linux

Discussion: the future of the operating system

It is well known that the architecture that GNU/Linux is built on is robust but old and especially POSIX feels outdated. also, some new operating systems (fuchsia, redox, haiku) are slowly emerging. there are few old but interesting OSes as well ( eg: Plan9, hurd ).

Now, what new inventions / breakthroughs / gradual upgrades do you expect in OS space? ( server / desktop / embedded etc.. ).. What features / techniques from existing research is interesting in this regard? I would like to hear a bit more about OS research....

https://redd.it/ce8j2d
@r_linux

The PGP Problem
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

https://redd.it/ce9drh
@r_linux

Tutanota now has an encrypted calendar, also available in the F-Droid app.
https://tutanota.com/blog/posts/free-encrypted-calendar

https://redd.it/cea74m
@r_linux

The Best Linux Distros 2019
https://writeabout.tech/programming/the-best-linux-distros-2018

https://redd.it/ceako0
@r_linux