Alex from Seva here: We are actively building integrations with the most popular services. Here is the list of the active integrations: Gmail, Google Calendar, Google Drive, Dropbox, Box, Slack, Confluence, Jira, Clubhouse.
As for the pricing, we are currently offering a free trial. After the trial the price is $10/month
It seems that the author is slightly confused. Description of the thundering herd is mostly correct. Initially it referred to multiple processes calling the accept() on a single listen socket, it used to cause all processes to wake up. This has been fixed a long time ago. Currently multiple processes blocking on the accept() on a single listening socket works in a round-robin fashion (AFAIK). Calling select() from multiple processes on a single fd, should wake all the processes up when IO comes in. This is a documented behavior.
Yes, all this 'fundamentally broken' talk is overblown rubbish. I was working on servers handling large numbers of sockets across lots of processes over a decade ago. Scaling non-blocking I/O was a well known area a long time ago, and problems like the 'thundering herd' and others had multiple solutions across a variety of operating systems.
You are correct. Directly blocking on accept() in multiple processes does not have the "thundering herd" behaviour. This is good to know.
But this proves next point - select is a poor abstraction. This means that accept() is doing something more then just wait for readability (it attempts round robin) - a thing you can't express with select().
In the article I used the accept() case for illustration of the thundering herd problem. Non-blocking connect() taking a long time makes a good case. The same experiment could be done though measuring write() or sendmsg() syscalls.
First, the article starts talking about the accept() and thundering herd but the example shows use of the select().
Second, accept() goes over a queue of the established connections created by a listen() call
select() and accept() are meant for different things. selec/poll/epoll/kqueue work with a list of file descriptors to detect I/O, accept works with a socket.
we are in the same situation. Early morning today found one host with a high cpu usage. Turned out it was running `./yam` process as a `redis` user. I shut the host down for now.
Before shutting it down I did a strace and saw json stream clearly stating that it is a monero app.
Looks like the cpu spiked about 12 hours ago. We do have redis on a host but it should be behind the iptables rules.
Other hosts look ok.
We were able to get in touch with the hacker and he told us he was just mining and not stealing stuff. We're still cleaning the whole system; might even pay him/her a bounty for this though.
Overbooking in the hotel industry is a normal practice. Cancellation rate is pretty high. Hotel Tonight deals with the last minute inventory, overbooking here would result in unsatisfied customers.
I worked for an online hotel booking site in the past. We had integrations with multiple GDS and channel managers, SynXis (Sabre) was one of them.
SynXis was not the fastest or most accurate when it came to inventory. SynXis had some ridiculous throughput limitation to query for availability, luckily we did not have to rely on that API.
I can't speak about original Sabre technology since I haven't used it myself.
using a system package manager does not mean that one needs to use a distribution's (debian, ubuntu, redhat, gentoo, arch, etc) mirror to pull the package, it does mean that you use an OS provided tool to manage all software on your machine.
- It does mean that the common libraries are installed once
- conflicts between common libraries are more transparent
- System tools make sure that package stays up-to date
Except that you haven’t solved most of the problems that I pointed out by saying “use a system package manager” (and have introduced several new ones):
a. I maintain ~13 Ruby gems. I can generate new versions and verify their install on any system that I can run Ruby on. Under “use a system package manager”, I now have to maintain at least four unique package management formats (deb, RPM, emerge, Pacman) just for Linux distributions and at least one for the BSDs. Thanks, you’ve just increased my workload at least five-fold, although I no longer have to worry about Windows or macOS users (wait, I’m a macOS user).
b. Sure I can use a non-distribution mirror (like a PPA), but now you have to have at least six of those mirrors (see point 1) and, again, too bad about Windows and macOS users since they obviously aren’t smart enough to use an OS that has an in-built packaging manager.
c. In truth, you haven’t increased my package load five-fold, you’ve increased it much more than that. I’ve followed instructions for making debs and RPMs…and the only thing that works for me is using FPM because the system package managers are so bloody complex and built for a single particular use-case.
d. You still don’t have a solution for Windows or macOS users because neither of those OSes have system package managers, and no neither ports nor homebrew counts. RubyGems, pip, cabal, npm, etc. may increase the cognitive load but they work for people who don’t use Ubuntu Zany Zebra.
You’ve also introduced a new problem:
e. OS package managers (except probably nix) do not solve the multiple-installed-version problem. RubyGems allows (even encourages) multiple versions of a gem to be installed and applications (through their Bundler Gemfile) can lock to a particular version. I have packages with 1.x, 2.x, and 3.x releases where all three versions are still in use despite some backwards incompatibilities (mime-types 2.x dropped support for Ruby 1.8, deprecated some methods, and changed the default data format and loading mechanism; 3.x dropped support for Ruby 1.9 and removed the deprecated methods, and changed the default data format).
This is not possible in an OS package manager without renaming the installed library in some way. This is mostly fine when you‘re installing compiled software…but it’s not even perfect there. I’ve been working with language-specific package managers for a long time, and I’ve been dealing with how distribution package managers break some of the packages that I work with for just as long. I generally prefer the mess we have now to waiting for the perfect system package manager, especially since there are systems which will never get them.
