It doesn't even seem to be piping anything around though. The result of the filtering certainly isn't getting piped anywhere.
If I wanted something like this I'd probably just reach for pampy and use pattern matching. Which still isn't "Monadic".
HN user
It doesn't even seem to be piping anything around though. The result of the filtering certainly isn't getting piped anywhere.
If I wanted something like this I'd probably just reach for pampy and use pattern matching. Which still isn't "Monadic".
What's monadic about this?
The Thanos query nodes have the same interface as Prometheus itself, including the web UI (with a few small changes), so you can just use the same Prometheus plugin pointed at Thanos.
Thank you for that answer, it's helpful. We've also been considering Calico but it seems like a fair bit of work and the project's pretty overdue as it is.
The trick with flanneld on our other hosts is that AFAICT there's no way to run flanneld as purely a "grab routes and install them" without having it get a totally unnecessary (and completely unused) subnet lease.
I have considered just writing a quicky daemon that will do just the work of syncing routes without getting a lease (or trying to modify flanneld to do so).
The service in this case is memcache with a bunch of mcrouter pods in front of it to handle failure and cold cache warming. I still need to get traffic to the mcrouter instances and that's where I'm running into the bottleneck.
Yes, Dell 1950s and R420s. The gateways are R420s with Intel 10gbit cards.
Anyone working on K8s at Box or I guess anywhere else that has deployed it partially feel free to answer this, but:
How do you handle gatewaying traffic into Kubernetes from non-K8s services? I've been trying to get a basic cluster out the door with one of our most stateless services, but I'm having a having a hard time just getting the traffic into it.
The mechanism I'm using is having a dedicated K8s nodes that don't run pods hold onto a floating IP to act as gateway routers into k8s. They run kube-proxy and flannel so they can get to the rest of things, but ksoftirqd processes are maxing CPU cores on relatively recent CPUs trying to handle about 2Gbps of traffic (2Mpps) which is a bit below the traffic level the non-k8s version of the service is handling. netfilter runs in softirq context, so I figure that's where the problem is.
Are you using Calico+BGP to get routes out to the other hosts? What about kube-proxy?
FYI they switched from btrfs a while back. I think you need to reinstall with a newer version to get it though, it won't change on upgrade.
Not the parent poster, but needing GPU isn't necessarily the same as having UI. You can use GPU for a variety of general purpose math (Example: mining bitcoins, or doing stuff like Folding@Home), or for offline rendering.
I can't find a news story about the incident I'm thinking of, but there are SEC regulations about the release of information to investors. You basically have to try to ensure that they all get the same data at the same time.
"Well, since they load the file from a Python script, it's easy to make a copy of the "decrypted" file before it's reverted."
He edited their Python script to make a copy.
I transferred mine today without any problem.
ING Direct implemented read-only credentials for Mint, after fighting with them about access for months. (ING kept blocking Mint, and then Mint would find a way around it.)
I used a Norwegian friend's Spotify account for a bit, and I'm now using rdio. I don't see any significant difference between them, other than the client, which ... eh? Rdio works in my web browser, and it works on my phone. That's pretty much all I care about.
The only advantage an actual app could have is responding to my hardware play/pause/next buttons, I think.
So, under "For Buyers", it says that if you don't release the funds, it gets refunded to you.
Under "For Sellers", it says that you get the funds unless they specifically block it.
WTF?
That's exactly why.
(Incidentally, perlcritic will warn you if you have a map that modifies $_.)
I have no idea who he was, but I was in tears by the end. Condolences to all who knew him.
I got an invite a few months ago and tried it out. It was pretty amazingly rough for how long they'd been working on it. I did check out the source and was... not impressed.
I'll agree to some extent about the consistency, but I don't think that the "fork and go" mentality makes stability any worse.
I mean, as it is, I see segfaults and whatnot regularly in the canonical, distro-released versions of Apache. Major software releases all the time with bugs that could potentially be a show-stopper. My experience hasn't shown this to be any worse with non-canonical sources. Sometimes it's better.
Further, I like to think of the sysadmin's job as fostering business continuity. While uptime is a primary indicator of this, I think it's lower in priority than say, losing a crapload of customer data. If I have to shut a site down for an hour to prevent losing all transactions for the previous 24 hours or something, then it's not a terribly difficult choice. (Having to make this choice at all, of course, means you should be engineering something better. But we don't have the luxury of infinite time.)
And having all the uptime in the world won't help you if your engineers can't do their jobs effectively because the tools you give them are insufficient. Sometimes the best option is to suck it up and try that patch.
It's a delicate balancing act, and I'm not by any means advocating running all your software out of unofficial repos. Sometimes you gotta make that call, though. And if I'm looking at github at all, it's probably because a package doesn't already exist, or because I need a fix for one specific bug.
Yeah, but I wouldn't install alongside. (Nor do I install anything via gem.)
I see a number of things discussed in those links. Could you clarify which you're referring to?
As a sysadmin, I have to say that I hate Launchpad. I always have click many levels deep to find the thing I want. The interface just sucks.
I also know plenty of other sysadmins who use github but find no value at all in Launchpad.
Also: FWIW, I never notice folks' names on github. The important thing for me is that the code is right there front and center. If I want to download it, I click the clipboard button and then go clone it. Boom.
Edited to add: I also think that if it's not immediately apparent which fork is the "canonical" one, it probably doesn't matter. Just grab whatever looks most popular. If you decide you'd rather have a different one, then grab that later. shrug
I already have an Amazon account. Why would I go out of my way to get a different account just so a few pennies of my purchase can go somewhere different?
I don't think the "leave it to the users" option really works here. A lot of people will choose the least-work path.
I've used my current phone with both SenseUI and without, and did not notice any difference in battery life, FWIW.
So you block the /64. There aren't any subnets smaller than a /64 in IPv6, so you're guaranteed to be blocking a leaf node.
This is still miles better than having all of the customers behind large scale NAT, where you risk blocking innocent folks who happen to be behind the same NAT.
Apparently the job entry you actually want to look at is the second one: http://imvu.jobscore.com/jobs/imvu/linux-systems-administrat...
We are pretty thoroughly MySQL. You'd have to be very convincing, although one of the four of us on ops already has expressed a preference for Postgres.
IMVU in Palo Alto, CA is looking for a sysadmin or two. (http://www.imvu.com/jobs/)
... that description is full of shit. I'll have to talk to my manager about that.
Basically, we need three things from a sysadmin candidate:
We're a Debian/Ubuntu shop, with huge deployments of MySQL. Some of the job is day-to-day management of servers. You should know how to manage databases and handle replication.
We also require solid networking knowledge. You should know about the difference between TCP and UDP, and be able to explain Spanning Tree or ARP. (It actually shocks me how many sysadmins don't have this knowledge.)
The third part is programming ability. Most of what ops does is in Perl, but we also have to interact with other systems, so any knowledge of Python, PHP, etc. will enhance your appeal.
We're doing pretty awesome things, and only getting bigger and better. Come work with me! :-)
(E-Mail to treed@imvu.com if you have any questions or whatever.)
I had to leave LA last year because I couldn't find work, and now I'm in the Bay Area. Maybe all the perl hackers moved away? I wasn't seeing many Linux jobs in general.