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

Ukraine cannot win without manpower from either the EU or the US. That's the reality on the ground. No amount of equipment/weapons (conventional) is going to change that.


I wouldn’t be so sure, Russia is already doing so bad they need to deploy North Korean troops, motocross bikes and even donkeys and camels.


According to the Austrian military, there’s currently about 800k Ukrainian soldiers up against 700k Russian soldiers.

Because a substantial number of Ukrainian soldiers need to be present across the Belorussian border and elsewhere in the country, the Russians have a meaningful manpower advantage on the frontlines.

https://m.youtube.com/watch?v=IDRjughhXMg


Remember Ukraine doesn't need to take Moscow to win. Russia is burning resources hard to keep the initiative and achieve Putin's war goals. All Ukraine needs to do is continue to bleed the Russian army and wait until Russia has a hard economic crunch.


That's because github isn't trying to be a replacement for JIRA and source control for most teams.


https://github.com/features/issues

Scroll down to "break issues into actionable tasks", and they have an example that's even labeled as an "Epic". They are definitely headed in the same direction as Gitlab.


Ah, thanks for pointing that out. I missed it on my quick check.


their latest updates to their project management features[1] launched as part of the "new" issues are totally going in that direction though.

I'm unsure as to whether that's a good thing or not.

1) https://github.blog/2021-06-23-introducing-new-github-issues...


The one on the energy grid was wrong on many levels, and didn't understand fundamentally the relationship between renewables generation and transmission.


What is was specifically wrong? Can you clarify?


workspaces are specifically _not_ intended to be used as environment replacements. And it wouldn't have caught the OPs issue to begin with. His problem was he didn't read the plan, because it's pretty basic that any change of a resource name or a change of type equates deletion and TF will report back saying it will destroy a resource that is missing in the config but in the state.

To solve his problem, after switching to the data source type from resource he needed to manually run `terraform state rm` to get rid of the resource from the state.


> workspaces are specifically _not_ intended to be used as environment replacements.

From Terraform's "An Overview of Our Recommended Workflow"[1]:

  "The best approach is to use one workspace for each environment of a given infrastructure component. Or in other words, Terraform configurations * environments = workspaces."
So 1 workspace != 1 environment but workspaces are indeed intended to handle multiple environments.

I've personally struggled with managing multiple environments using Terraform so I'm interested in what the best practices are.

[1]: https://www.terraform.io/docs/cloud/guides/recommended-pract...


Can you elaborate on why terraform workspaces are not intended to be used for environments? I use it exactly for this use case. Same terraform config deploying to production and staging, each maintaining its own state in a separate workspace.


Wow dude, if you're going to be anti-semitic, just do it. Don't bother trying to be "cute", or "subtle" using emojis. Really pathetic.


Not doubting you for a second[0], but I didn’t see anything anti-Semitic in that post, so am I missing some internet meme or American cultural reference?

[0] Footnote in case it is necessary: antisemitism must be stamped out wherever it is found.


Many delis are Jewish. He's saying that whenever he sees buildings named after people, he's in a Jewish neighborhood. In context, it plays into nasty stereotypes about Jews being obsessed with money.


I don't think that was the meaning of the gp post. If you're traveling, names on buildings or businesses tend to reflect the population of that area. Thus, if you're in an area with a large Jewish population, you can expect to see buildings/businesses that reflect that too. Antisemitism is a real issue, but this is just not it. I am Jewish by the way, if that matters.


The post didn't say "when I see a lot of jewish names on buildings I know I'm in a Jewish neighborhood," it said "when I'm in a neighborhood with a lot of names on the buildings I know I'm in a Jewish neighborhood" (both paraphrases to keep the dogwhistly deli->jewish link clear). The implication that Jewish people are uniquely interested in showing off their money and status through naming rights donations seems pretty blatant to me.


Ok, interesting. I would usually be willing to give much more benefit of the doubt, but given how unnecessary the comment seemed to the rest of the post, I guess the obvious conclusion is a dog whistle.


Wow, okay, that's not the response I expected to come back to. I'm trying to understand how you interpreted my comment that way.

To be clear, there were no intentional dog-whistles in my post. I thought I was saying something strongly positive, about a phenomenon which I've observed and have great admiration for.

However, your response and the thread that followed, reveals some things I clearly didn't consider. There is surely a lot of anti-semitism out there, and that my comment was mistaken for it, I think shows how pervasive it must be. And it's important, as has been said, to call it out wherever it appears. And I guess that means looking for even tiny hints of double meanings. Which, logically, includes meanings that someone may not be cognizant of when speaking with one meaning in mind. I honestly thought I was being "cute" with the deli thing.

I'm astonished and saddened to see a well-intentioned comment identified as just the opposite. I didn't mean to play into any negative stereotypes about money -- I didn't say anything about being obsessed with money, and if I got near it at all, I was talking about being recognized for _doing good things_ (with money), and how this cultural pattern does that. I think that's pretty clearly positive! (The whole point of the article, after all, was that more people with money should be committed to doing good things with it. Money's a pretty unavoidable aspect here.) But clearly my comment exists in a world where a lot of terrible things also exist, and I guess I can see how it could be mistaken for a vague hint towards one of those terrible things.

Especially on the internet, where tone and nuance are notoriously tricky.

So I'm honestly looking for input. Is there a better way to say what I was trying to say?

Regardless, I'm sorry that you saw something negative in what I said. I'm even more sorry that anti-semitism is so insidious that you had reason to look for negative interpretations in the first place. That sucks.


For those who can't spot the subtlety, can you explain what you mean?


Many delis are Jewish. He's saying that whenever he sees buildings named after people, he's in a Jewish neighborhood. In context, it plays into nasty stereotypes about Jews being obsessed with money.


Thank you.


To be fair, cultures have characteristics and people should be permitted by their peers to talk about those characteristics in a thoughtful way.

I'm not familiar with what the other guy is describing, nor do I have any opinion on this particular topic. I'm just saying that "people of X culture tend to do Y thing more than the average person" is not in itself a hateful or disrespectful comment.


I think you're reading into it too much. He specifically said he thinks it is not a bad thing. In your opinion, is it possible to say anything about your culture without being anti-semitic?


Then why did they feel the need to obfuscate?


If so, the point of view in the comment wasn't obfuscated very effectively, considering that we are all talking about it.


R has so many problems itself! Attempting to run it at any sort of scale is basically impossible. Its dependency management is atrocious. You can't thread or multi-process effectively. The amount of overhead to even install R on a system is incredible, and amazingly its documentation is even worse than Python. We use R as our foundational Data science language and it has caused nothing but immense pain for everyone attempting to wrap the packages in scalable software.


This piece excludes some incredibly common networking complications: VPC Peering Connections, VPC Endpoint Services, VPN connections.


Holy cow that article is barely legible, the writing is so bad.


Doesn't Microsoft, Google, etc. support the CLOUD act?


Which would be unsurprising. The overall aim seems to be to reduce the legal considerations US companies need to make when responding to foreign government data requests.


Spark is not a buzzword if you do analytics, it's the preferred platform, especially over native Hadoop. Honestly most developers have no idea what the heck Spark is or how to use it. NoSQL/Kafka yes, Analytics/Machine Learning is still far too complicated for most to stand up on their own.


Spark has a place: at large scale. For 100s of GB to a few TB of data PostgreSQL works very well. At least, it does for my team. I don't want Spark, Kafka, NoSQL or any other modern fad near my team's data. It's just not appropriate.


Kafka was useful in a project because of the semantics for what amounts to writing to file from network sockets.

Spark is a terribly inefficient solution to any known/stable data processing or analytics jobs. If you want a common format to trade with buddies, it's useful now. I expect something else will come along to replace that fad tech.


>Spark is a terribly inefficient solution to any known/stable data processing or analytics jobs.

Can you expand on that?


Spark is a terribly inefficient solution to any known/stable data processing or analytics jobs.

You gave a typo there.

Spark is a terribly inefficient solution to any known/stable data processing or analytics jobs I have ever come across.

There, fixed that for you.


I don't think that's fixed, because it's not what I assert.

Any job that is predictable, can be done faster and cheaper with some C (or Go) and ad-hoc delegation to load balanced VMs. Spark is difficult to optimize for consistent processes, poor on resource usage, and requires specialized knowledge. Just pay for someone who has done a little embedded programming and stop creating buzzword jobs because a prototype went to production without comparison.


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

Search: