HN user

anonymousJim12

50 karma
Posts0
Comments28
View on HN
No posts found.

Counterpoint, I read "The Manager's Path" and I found it to be a pretty redundant overview of the management path for someone in an org that has a well defined management structure/path and that started out as an IC and is now in an M1 role. ie, I had plenty of time to observe as an IC and then when I was ready for the switch I had a good understanding of what good management looks like, expectations were set and a solid group of mentors in my management chain.

To me it's a good book if:

- You are an IC in a "flat" organization/startup that wants to learn how the management path works at large companies - You are now a manager that did not develop in an environment with a well defined management path. You are winging it and want to implement best practices.

I'm not sure if this will be seen but I'm very curious to hear from Indian folk:

I am the hiring manager at a well known software company that employs a lot of Indians on H1B visas. A while back I brought in an Indian person for a full round interview. This person happen to have pretty dark skin. On the interview team was a light skinned Indian person with a very Brahmin last name that I'd say is pretty average technically and wasn't my first choice to be on the interview team. The unbiased interview feedback sent to me was 5 yes to hire and the only no to hire (and strong at that) was the Indian interviewer...

A few days later I read about this caste situation at Cisco and I had to wonder...

Any recommendations on how I can avoid having this uncertainty if discrimination was at play? Seems like a pretty hard thing to prove.

Etcd 3.4 7 years ago

Which k8s version will use this version by default? Has it been tested with any current versions?

Executives live in a global economy. The rest of us might "operate" in one but we don't get to take advantage of that privilege the way the wealthy do. You are right, world wide poverty is on the decline. But given the choice between:

- better for 1 billion people

- worse for 2 billion people

- really outstandingly fantastic for 200 people

and

- really good for 5 billion people

- worse for 200 people

I know which way I'd lean in that spectrum.

I am saying something completely different. The presenter in your YouTube link makes it clear that Julia made the cut for evaluation but that ultimately Swift was the only language left standing. The slides make this less clear as they stop before the final knockout round.

I believe this[0] is the "study" the presenter is summarizing, which further makes it clear that Julia did not in fact "make the cut". Put another way, if we are going to argue that Google said Julia makes the cut, we could just as easily make the argument that Rust and C++ made the cut.

[0] https://github.com/tensorflow/swift/blob/master/docs/WhySwif... w

I just watched the video and the presenter makes it clear that Google picked Swift ultimately and eliminated Julia from evaluation in previous knockout rounds.

I don't use either and to be honest was surprised that their original set of languages evaluated was C++, Rust, Julia and Swift. Seems like an odd list of languages to start with when discussing ML.

This isn't that surprising for someone that has a lot of experience in something like project management or academia and/or is very good at negotiating.

For instance the place I work just hired as a senior engineer a former math professor with a math PhD that hasn't written a line of production code in their life. If this person decided to go through a 9 month bootcamp before applying the outcome would have been the same.

One scenario like this played out after the mortgage crisis in 2008. Many banks now owned homes where the mortgage amount was greater than the market value, ie underwater. There was a ton of bank owned inventory for a long time because a) They are banks, not real estate companies with all of the expertise in marketing and transacting single family homes in bulk b) the market for homes significantly shrunk in the years after 2008.

In hot markets sure, maybe a bank might see a default and repossession as a good thing, but I doubt they are optimizing for those scenarios.

really? It reads like the subject of the criticism is millenials...

I find the tone of the criticism stunning, even if it were about the article and not millenials. The article is laying out how millenials have it different than previous generations. Yes NYC was always expensive but even now places that are 1 hour commute are out of reach for your average 30 something. It's tough to say when the commentor came up but the article is painting a picture that the game has changed and it isn't as easy as it once was to delay gratification for 8 years because it's more like double that amount of time. At that point we need to start asking questions to understand if this is sustainable.

remote code execution doesn't really mean much in an un-privileged container. They could be using cgroup limits, capability drops, MAC, seccomp, etc etc

Now, I'm not saying that containers are super tight by default. It is entirely possible this particular container env is wide open, but I didn't really see anything too concerning from the parents analysis.

But you don't know that they aren't using cgroups or a proxy to throttle traffic or cpu access, right? To me, it seemed that your message was overly dramatic when you didn't really prove anything. Depending on their set-up indeed. I just don't see the compromise in your analysis.

I'm just not sure what you are alleging? Just because you have full "shell" access to the container doesn't necessarily imply any thing needs to be mitigated.

What specifically are your concerns? What about what you've learned will create an exorbitant bill?

White male, middling state university CS, Software Engineer track, US east coast HCOL cities. Never more than a straight 40h/wk.

    2006-2009 - small co                                  - 40k -> 50k
    2009      - took a year off to travel                 - 0k
    2009-2011 - small co                                  - 65k -> 80k
    2011-2012 - stereotypical startup                     - 100k
    2012      - Tried to start a software co              - 0k
    2013-2018 - non-unicorn medium co                     - 105k -> 175k