HN user

gizdan

935 karma
Posts3
Comments253
View on HN

This is almost what we do as well. The difference being that we have a API Gateway in front that just invokes the lambda on an internal network, which validates the webhook data and only then does it forward it.

Takes the complexity of having to use a queue out of the equation, though at the expense of potentially lost webhook calls.

Which is fine, and surely an honest mistake. Automation is great, but the way I see it is, how many other projects have been forked and automatically re-licensed, and then profited from without proper attribution? An accident still needs to be flagged, and still needs to be corrected. They also need to be learned from and avoided in the future.

Besides what the other commenters have said, I have 32GB RAM. If Firefox or IntelliJ don't use it, nothing else will. I'd rather have the applications I live in utilise as much memory to make the experience faster and better, than to have unused RAM be wasted. IntelliJ is far superior over VS Code, VIM, etc. IntelliJ is batteries included, whereas VS Code, VIM, and most other editors require additional configurations. Some configurations I've seen have required hours and hours of set up and integration. With IntelliJ on the other hand, it just works. I click run on the main function, and it asks me for the compiler/runtime config the first time round, and afterwards it just fully works. Even running tests is as simply as clicking run from there on.

The CD community is overly obsessed with velocity.

I think CD is about minimising the amount of code released in one go, which allows you to catch issues much faster and revert issues much quicker. Compare that to something most banks do, release once a quarter, and you'll get stuff like that UK bank that went down for days (can't remember which one it was).

I've yet to meet anyone saying you have to finish your features faster.

Seems odd for PM to be vulnerable by the log4j CVE considering (from what I understand) they're mostly Go house. Maybe in the Android app, but otherwise I'd be surprised.

Unrelated: I've been getting quite frustrated with some of the functionality and limitations of PM especially for the price I pay (I have 2 catch-all domains, 1 user for each, which requires 2 times pro accounts), so recently I've been trying to migrate away to mailbox.org. Mailbox allows for automatic PGP encryption when the emails come in which is great. However, there is no way to move all my PM emails onto my mailbox.org account while keeping the encryption (not via the original key set up in Protonmail, nor via new key set up in mailbox.org). Has anyone ever run into such a scenario, and what can be done in this scenario?

I wish there was a good theme out there that has support for lots of different apps, and has a light and dark theme. Dark themes are great when you're working in the dark, but during the day, when the sun is at its highest, and your brightness is maxed, Dark themes just don't work.

Young Dems mirror the behaviour of Conservatives how exactly?

They have problems with media and depictions that doesn't fit their worldview and don't favor free speech because it was a value by people that partially rejected their ideas.

This is completely missing the point of what the younger generation want. They don't have problems with media and their depictions. They tend to be more inclusive. They fight for people that haven't had a voice previously, or have been mistreated. What they have problems with is hate speech, not free speech.

JSON in shell might not be faster (or it might be, I've not benchmarked), but it certainly is more efficient to do select and filter and whatnot using something like jq. It's not about network, it's about making the output more predictable when running a script. I've lost count the number of times I've tried to capture a specific part of the output of a command only to be tripped up by an edge case like spaces or something else.

Can someone elaborate on why Nomad should be avoided?

The answer is, as always, it depends on your use-case. I'm not personally not a huge fan of Nomad for reasons I won't go into because a) they're irrelevant because opinions, and b) they're probably outdated. However, to say "it isn't much better" is very vague and extremely subjective. I don't really know what OP means with it, but consider the following things I know about Nomad vs Kubernetes:

Kubernetes has many more features that you or your users don't have to deal with (in terms of setup). Obviously that brings in complexity that Nomad may not have to deal with. This also means that some features may need to be supplemented using other software, which otherwise means learning those other software and having different interfaces to manage it. Kubernetes on the other hand, provides all of these features using the same interface. Obviously this also means with Nomad you can add some of these features as you need them over time, instead of having it all at the beginning regardless of whether or not you need them. Some features I can think of: secrets management*, load balancing, config management, service discovery.

Kubernetes has a much bigger community, many more tools you can just plug and play. The relatively recent phenomenon that is Kubernetes Operators is just awesome and makes running software a breeze. Software that otherwise requires a lot of knowledge to run.

Kubernetes only does Linux containers, compared to Nomad that has support for just about any thing you can throw at it (Java, containers, plain binaries), and it has first class Windows support (via Windows executables). Last I checked Windows support for Kubernetes was still in its infancy.

In terms of support, with K8s you will need to get a third-party to give you support, whereas with Nomad you can get support directly from Hashicorp.

Nomad requires a Consul cluster, at least last time I looked this up, though as I understand this, HC was working on this in the past year or so, so this may not be accurate any more. Kubernetes uses etcd internally, which itself takes some understanding.

Lastly, Nomad will likely lead to vendor lock-in. Kubernetes can run just about everywhere including on-prem, all major cloud providers, and even at the edge (see KubeEdge). Chick-fil-A famously runs Kubernetes on Intel NUCs in all their stores. I'm assuming there is nothing stopping a Nomad cluster being run at the edge, but I suppose it's not been proven yet.

* note: secrets management is a bit of an overstatement for Kubernetes. By default it is base64 encoded "secrets", and the only thing preventing one from accessing the secrets is ACLs, but if you have access to the underlying etcd cluster, it's game over. If you want proper secrets management (i.e. encryption at rest and/or in transit), you'll need to integrate it with something else such Hashicorp Vault (the most advanced option), or Mozilla SOPS.

Minimal containers shouldn't need that though. Your logs should tell you enough about the application it's running. K8s (get/describe) should tell you about the lifecycle of the pod. Lastly something like "dive" should tell you all you need about the image's file layout.

My parents emigrated to the Netherlands when I was young. In my native tongue we say numbers in the same way as they do in English. My 8 year-old brain struggled to understand this new way saying numbers when I started school in the Netherlands. I got there in the end but I recall it feeling like it took forever.

Sure, except for the fact that this specific email is <firstname>.<lastname>@gmail.com and I have only ever used it when I've been directly in contact with companies after I've gone through the whole process, or when I've developed a relationship with the recruiters. I've never connected it to LinkedIn either. In addition, as I mentioned in my previous comment:

Every time I reply to ask where they got my email, they mention some service that scrapes emails based on LinkedIn addresses.

Again, zilch to do with my email being allowed to be public.

Every time when I've reached out to these spam companies, they've mentioned scraping and guessing emails. I.e. if my name on Linked is John Smith, and they'll add john.smith@gmail, john.smith@outlook, j.smith@gmail, and some other common name formats.

It's ridiculous.

They should know because my email isn't available anywhere online for a reason. Every time I reply to ask where they got my email, they mention some service that scrapes emails based on LinkedIn addresses. This isn't okay. That's spam. They're clearly trying to avoid LI's platform for whatever reason (probably cost).

It's not just about blocking domains, it's about figuring out what those services are and yelling at them for scraping my data and assuming I want them to hold my email when I've not put those details online.

This is an inherent limitation of the way OSs are built. Linux, Windows, macOS are all like this. macOS is currently the furthest ahead in this since they're sharing code with iOS, but it's still not where it should be.

The Linux kernel is not at a point of allowing this kind of fine grained sandboxing or mocking of APIs. I'm guessing because it's a significant undertaking. I'm sure as more features become available in the Kernel w.r.t. sandboxing Snap and Flatpak will definitely utilise them.

Counterpoint: half of those are based on bots, and thus when you reply, you're automatically ignored because your profile doesn't really fit.

Counterpoint: I really don't want spam in my email. I've got LinkedIn for that. I get countless emails from recruiters because they use some tool that scrapes LinkedIn and guesses my email. Then I get "I have a role for you, pls respond", "Please hear me out, great role!", "Last try, I'll show nice things", and sometimes even then it doesn't stop.

Personally I always yell at recruiters who directly reach out to me. I get many more LI messages from recruiters, but I can ignore those if I want, though quite often I reply and politely mention that I'm not interested. I've built good relationships with several recruiters who have reached out to me via LinkedIn, but never via email.

No. It doesn't. You still need to trust the people who package the thing.

Flatpak and Snap have never claimed to solve the trust issue though. Flatpak allows you to add your own repositories and thus developers can package their own applications. So if you trust the developer enough to run their software, you should be able to trust them to package their own app with.

When we were taught Java at university, we were taught it using BlueJ because it could visualise objects and had some other beginner friendly features. For our assignments we were given the choice of using BlueJ to write the code, or JEdit. Considering BlueJ was horrible to use for me as a power user and pretty decent at PHP back then, I struggled really hard. JEdit was came to the rescue. It certainly wasn't the best, but it good enough and loved it.

From the github user's ("i-voted-for-trump")

Well, his Twitter is on point.

Anyway, I'm pretty sure it wasn't a joke originally. I recall him heavily defending it even after people trolled him for creating such a package.