BazookaMusic's comments

This makes sense if you consider the size of the product engineering team vs the amount of customers out there. For every engineer there's probably hundreds or thousands of customers. If they had to engage immediately with every support case, there would be zero progress on any other job.

The problem actually comes from the fact that big tech is becoming increasingly cheap on creating good support organizations. Experienced support engineers are fired and replaced with outsourced low-cost inexperienced personnel. In most cases, issues can be resolved or worked around with the help of a support engineer with access to some extra knobs. When those engineers are removed and are replaced with people who act like a pipe for cat to send the customer's stdout to product engineers, you get what you describe.

Inferiority is how you frame it. You don't need to be Jane Street level to do good things in computer science or life. I've found a job where I do cool things on a compiler and I like it. I don't feel inferior to them, instead I feel inspired from these articles to learn cool stuff and build things I'm proud off.

I can say though that when I was working on stuff I enjoyed less (backend ERP stuff), I felt much worse and would compare myself to others a lot more. So I think these feelings you are expressing can sometimes be a manifestation of not being very satisfied with your own life.

This is probably what you're thinking of:

https://en.m.wikipedia.org/wiki/Bisection_method

Guns do enough killing to be compared to car crashes: https://www.pewresearch.org/short-reads/2023/04/26/what-the-...

Car crashes: https://www.nhtsa.gov/press-releases/early-estimate-2021-tra...

UK for comparison: https://commonslibrary.parliament.uk/research-briefings/cbp-...

To be fair though, the root cause is probably a mental health crisis, especially seeing that suicides outnumber the homicides. But it goes without question that projectile weapons make it tremendously easier for mentally ill or desperate people to kill themselves or other people.

Insider trading sometimes

I liked From the Notes. The story had an Asimov vibe to it and the flow was captivating for me.

Maybe you could make a newsletter so I can subscribe and get notifications for when you write? I'd probably read them once in a while.

I might be wrong on this explanation, but the reason why it was faster might have been the following:

During execution you had two kinds of memory locations, some in CPU caches and some in RAM. By running all the threads on one socket, everything accessed from the cache was just a fast cache access. Everything accessed from the memory was a slower memory load. Frequently loaded/stored locations will tend to go to the cache.

In the NUMA setup, you would have a larger cache (more than one socket) which would mean that more locations were likely to be in the cache. However, if a core on a socket tries to access a location which is on another socket's cache, it will use the interconnect between them to access it.

If you have an unfortunate memory layout, this can make it so that you end up having a large percentage of the accesses using the interconnect (slower than cache access) and values get swapped between the caches constantly, which forces subsequent accesses to also use the interconnect.

Another way to avoid this except using just one socket is for the designer of a program to consider NUMA nodes as separate processing units and design around that. Both should be processing separate data and they should only share small amounts of data for synchronization/communication. Then the caches will be much less affected.

I'm working on a compiler for a DSL which is based on Roslyn. The most useful things for me learning wise have been:

1) Reading the source code of roslyn which can be quite readable 2) Building VSCode extensions to add diagnostics and implement code actions. You can use any open source language server as the reference

-Happiness is not the ultimate pursuit for the wayward person, fulfillment is. Sometimes one must sacrifice happiness to gain fulfillment.

This turned on a light bulb for me, so I really appreciate you sharing your point of view. Specifically, I feel that it helps a lot with my issue of having analysis paralysis to frame things in terms of fulfillment rather than happiness.

I will try to come up with some innoculations of my own going forward.

Anand could very well be moving across countries and investing immense amounts of times to start a new life. He could also be leaving a great job to seek a new challenge in a company he wants to invest years of his effort in. The VP has also dedicated time specifically for Anand's interview. He also probably has the power to fire him in short notice and with limited severance.

Anand should ask all the annoying questions. This way he's saving both himself and the VP all the wasted time of hiring him and then having a broken relationship because things weren't clear later. This way the VP can also see what concerns the potential employee and if they have a potential mismatch in expectations.

Finally, even if we disregard all that I said above, if it's Anand's working style to ask a lot of questions and he hides this style during the interview, then he will invariably clash with management later due to it if he's hired. Then he may have more to lose then just a potential future job.

Any citations for this broad statement?

Perhaps it has been easier historically to converge to the single ruler model due to the available knowledge and resources. Is there any research concluding that one ruler systems offer higher gains in modern societies?

I like this approach a lot. I'll give it a try.

What you're describing about writing a mutex with cmpxchg is a spinlock. If you just use that operation it's also a very inefficient spinlock.

The point of a lock free algorithm is to avoid having a thread wait on a resource and not do any work. It may do useless work that needs to be reverted, but it's not sleeping or spinning until something happens. It's not guaranteed that you can do that for every algorithm in a way that makes sense performance wise.

Here's a nice resource I used on my thesis for an adequate but not perfect spinlock with atomic instructions: https://rigtorp.se/spinlock/

The catch here is that it may be impossible for the creators of simulations to deterministically define the rules of a simulation, especially considering the effect of time.

As an example, let's take the scenario of building a simulator. The simulation needs to have some internal state. This state will need to be stored either using some properties of matter or some kind of signal. The simulation will also need an energy source.

As soon as the stability of matter or the power supply is perturbed, due to reasons like cosmic radiation or the fact that the power source cannot sustain its output, randomness from the creator's "world" will start seeping into the simulation. The interference may affect the internal state and then you may have unpredicted rules in your simulation.

The counterpoint can be that you use error correction algorithms or you insulate the simulation in such a way that interference does not affect it for a reasonable time-frame or in a manner that is very hard to observe for simulated "agents".

But with this in mind, we can imagine some very crafty agents who somehow stumbled upon these weird phenomena. Suddenly we see our agents building complex contraptions to study the emergent phenomena. Who's to say that the interference and thus these phenomena do not contain information about their creator's world? In the end, they could understand more rules than the simulation was programmed with, if that is true.

Maybe in that case you shut down the simulation. Or maybe you observe the simulation to learn more about your own world.

I would say it's more about low empathy and ability to scrutinize their beliefs. This is very often paired with a nice dose of narcissism which makes them think that everyone else is an idiot and has flawed thinking, while they're immune to it.

They're still used, https://www.ferries.gr/en/ferry-companies/aegean-flying-dolp...

You can do it with the type system, although in C# it is a bit clunky.

For example let's say you have a class Resource that needs to be locked and a method Foo(Resource) that needs to operate on the resource under a lock.

You could change Foo(Resource) to Foo(LockedResource). LockedResource could be a class that is defined using a lock object and a resource and takes the lock or validates that lock is taken in the constructor.

Then by making the object disposable the release can be handled as well.

This way the type system handles the validation.

This is kinda like a budget version of having the type system support locking and concurrency like Rust does.

"A protein called FMRP that is absent in the brains of people with FXS modulates the activity of a type of potassium channel in the brain. According to the research group's work, it is the absence of this protein that alters the way sensory inputs are combined, causing them to be underrepresented by the signals coming out of the cortical pyramidal neurons in the brain."

Maybe adjusting the production of the protein they identified would be a reasonable thing to study before resorting to Clockwork Orange therapy.

It's unlikely that they won't use it for more eventually if this works. They're probably playing it safe by mentioning only video conferencing.

As an example, if meetings are made in teams and people comment during the meetings, their input will be in teams. Further communication around the meetings is likely to stay in teams. They're making it inconvenient to use slack or other means.

One thing to keep in mind is that there's a security angle to this as well. It is beneficial for a company to centralize all of its communication through one service which can be audited for security and also support all the features required to meet the internal Requirements. Having multiple tools multiplies the work needed to maintain security standards.

Of course, I'm not saying that teams is more secure than competing products or that this will automatically improve security. The point is that it's a single option that's easier to manage.

Outside of security, this also applies to cooperation between MS and Github teams. Teams helps with keeping common calendars, meeting invites, recordings and transcripts. Having more tools means that an adapter needs to exist between them and might be disincentivising communication, since engineers would prefer to work on their tasks rather than work around fixing soft problems.