Hacker Newsnew | past | comments | ask | show | jobs | submit | davestephens's commentslogin

Credit Suisse | Platform & Cloud Engineer | Full-Time | HYBRID ONSITE / REMOTE | https://www.credit-suisse.com/

We're hiring for our Platform Engineering team in the US (New York) and Poland (Wroclaw). We're a diverse set of technologists working together to reduce the friction of building, testing, deploying and operating infrastructure and software at scale. We've recently completed a large-scale migration to a popular cloud vendor, and are now on a journey of rebuilding our platform from the ground up to take advantage of what it has to offer.

We're a reasonably autonomous team (rare for financials!) and are looking for a good communicator with an eye for detail, and obviously someone with good tech skills. We're not fussy about people that have previously worked in financials, but someone that's up-to-date with their knowledge of the DevOps and cloud ecosphere is a must.

New York: https://tas-creditsuisse.taleo.net/careersection/external_jo...

Poland: https://creditsuisse.taleo.net/careersection/external/jobdet...


Yeah. Screw those guys trying to make a living!


I mean, yeah trying to make a living by annoying the snot out of people is a thing that people don't like. It's the "business-model-belle of the ball" at the moment, but that doesn't mean we folks subjected to it have to like it, nor is it somehow "morally wrong" to object to being inconvenienced.

You can try to diminish the real-world confusion and inconvenience of said business model by saying "cmon, it's not that bad, what's the big deal, why not let them make some money, why you gotta be such a stick in the mud?" That does nothing to reduce my or other peoples annoyance and lost time caused by said business model though. It's real, it does waste my time, and your time, and everyone else's time, it does inconvenience us, and it does make it harder to get the information we want.

Because of that, I'm glad to see these other websites arrive to replace blogspam recipe mills. I plan to use websites like http://www.cookingforengineers.com and https://stovetop.app/ search for most all my recipes going forward. Thanks OP for stovetop and thanks to other commenters here for posting more resources for us to use.


There are Facebook groups that offer reviews in exchange for reviews. You will see very new recipes, that have had zero chance to rank and be cooked, with comments like:

"Ooh I can't wait to make this!"

Or:

"I LOVE making chicken like this!"

...and a five star review.


It must be hard work to push that "jump to recipe" button that features on pretty much every food blog on the planet.


For anyone thinking they want to start a BBS, or just noodle with some software for nostalgia's sake - this is written in node.js and a lot of fun: https://github.com/NuSkooler/enigma-bbs


I can lend you my tamagotchi? ;-)


Would love to see that write-up!


Hey, thanks for the shout :-)


A close friend has a very similar thing recently, except it was/should have been a new Ryzen 3700x, not a warehouse deal.

If you've bought one you'll know it comes in a box with a big cooler on top, and the proc is at the bottom in a bit of plastic packing.

He got the big cooler but no Ryzen. Contacted Amazon, got another Ryzen and cooler sent out.

I think this is incredibly common...


Few things to do:

- specify a LAN IP for your ingress controller so it doesn't change.

- Use ddwrt/dnsmasq to point *.k8s.myhomenetwork.local to said IP

Once that's configured, you just configure the ingress hostname on services as you would "normally".


Also - do not use .local tld. It is a reserved one (RFC6762), for mDNS/Bonjour:

> This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addresses in the FE80::/10 prefix, which are link-local and meaningful only on the link where they originate.

Microsoft used to recommend .local TLD for AD deployment as a best practice, and nowadays there are companies stuck with this decision. Do not make the same mistake; unlike companies, you probably want your zeroconf stuff to work.


Iirc, the last time I looked into this, .test is the recommended TLD to use because it’s reserved for non-production use I.e. it will never be bought or sold.


So what breaks if you use "*.[lastname].local" for your home network?


On zeroconf aware systems, it is still expected to be resolved via multicast; service discovery works by looking up srv/ptr/txt records on __$service.__$protocol.$hostname.local.

How it will behave will depend on your specific stack. Zeroconf aware (Macs, iOS devices, Linux with Avahi - i.e. most modern distributions) one will use multicast, zeroconf unaware (Windows) will use your DNS resolver. Devices (printers, etc) are a toss of a coin.


I'd like to note that a default behavior of Avahi in Debian/Ubuntu/RH/SUSE prevents resolving *.local via unicast DNS to avoid this collision.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: