It's the first link in the delisting section: http://go.microsoft.com/fwlink/?LinkID=614866&clcid
I also recommend signing up for SNDS.
2,996 karma · joined June 20, 2013
It's the first link in the delisting section: http://go.microsoft.com/fwlink/?LinkID=614866&clcid
I also recommend signing up for SNDS.
2. For sure of you are using AWS in US: Traffic across the atlantic will incur at least ~65ms latency per roundtrip.
The only organization that caused issues is Microsoft / Outlook.com, but they seem to block every IP address by default. I was able to unblock myself by filling out a form and waiting a few hours for all my servers so far.
You're welcome. I like giving back to Open Source.
> but it's currently too limiting for my usecases
My personal experience is the opposite: For one project I specifically slapped on an haproxy in front of the nginx after the fact, because I considered it's HTTP "rewriting" abilities way superior. What I could do with a single ACL + http-response set-header (setting a specific CSP for a single path only) would have resulted in great pain with nginx only.
In the future this could be extended to support systemd's socket passing and status messages. The latter allowing you to show a short string in `systemctl status haproxy`. See this example for php-fpm:
[root@example~]systemctl status php7.0-fpm.service
● php7.0-fpm.service - The PHP 7.0 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.0-fpm.service; enabled)
Active: active (running) since Sat 2017-11-25 13:28:22 CET; 1 day 8h ago
Docs: man:php-fpm7.0(8)
Main PID: 4624 (php-fpm7.0)
Status: "Processes active: 3, idle: 29, Requests: 1203613, slow: 545, Traffic: 10.1req/sec"
*snip*
See the mailing list thread for the full discussion of the feature: https://www.mail-archive.com/haproxy@formilux.org/msg27874.h...[1] https://www.freedesktop.org/software/systemd/man/sd_notify.h...
Regarding grandparent: What kind of hardware failure? I had to change different types of hardware in the past. For HDD changes you send a full SMART result + possibly the logs showing that the RAID kicked the faulty disk and they replace the faulty disk in 30 minutes (and one time even apologized that it took 2 hours for a low-priority-support server). In all cases the actual downtime was < 5 minutes, because of RAID. For possibly broken fans I simply stated that according to my Munin logs show consistent temperatures near the upper limit and asked whether they could take a look. They added an additional fan within 30 minutes, again with actual downtime < 5 minutes.
Most of my replacements were during the night in Germany, that might have helped, because there are possibly less requests in parallel. And I always had hard logs proving my HDD failures.
See https://github.com/blog/2188-git-2-9-has-been-released (section Beautiful diffs) for an example and http://blog.deveo.com/whats-new-in-git-2-11/#experimentalheu... for another similar option that I did not try yet.
One can also use one of the 20 additional slots (82-95) the Yubikey 4 provides over the Yubikey NEO by replacing the '9c' with '82'.
Is it even possible to pay for the hosted GitLab.com instance?
Regarding what's gone: The production PostgreSQL database. This suggests that the code itself is fine, but the mappings to the users are gone. But git is a distributed VCS after all, so all the code should be on the developer's machines as well.
Here's a generator for Bash: http://bashrcgenerator.com/, the prompt's format string is stored in the $PS1 variable.
$ apt-get
apt 1.0.9.8.4 for amd64 compiled on Dec 11 2016 09:48:19
Usage: apt-get [options] command
apt-get [options] install|remove pkg1 [pkg2 ...]
apt-get [options] source pkg1 [pkg2 ...]
…
This APT has Super Cow Powers.
$ aptitude --help
aptitude 0.6.11
Usage: aptitude [-S fname] [-u|-i]
aptitude [options] <action> ...
…
This aptitude does not have Super Cow Powers.The --autosquash option of git rebase can save you some work:
--autosquash, --no-autosquash
When the commit log message begins with "squash! ..." (or "fixup! ..."), and there is a commit whose title begins with the same ..., automatically modify the todo list of rebase -i so that the
commit marked for squashing comes right after the commit to be modified, and change the action of the moved commit from pick to squash (or fixup). Ignores subsequent "fixup! " or "squash! " after
the first, in case you referred to an earlier fixup/squash with git commit --fixup/--squash.
This option is only valid when the --interactive option is used.
If the --autosquash option is enabled by default using the configuration variable rebase.autoSquash, this option can be used to override and disable this setting.