Recent submissions

Comment · 6 years ago
> "While technically true... I don't see how it contributes anything useful to the conversation, so I downvoted it."

If you don't see how it contributes to the conversation - why not just ignore it then? Just because you think this doesn't contribute to the conversation, doesn't make it true.

> "If you don't agree, that's fine..."

Clearly it's not "fine", otherwise you wouldn't try to silence comments you disagree with by down-voting them.

This is my last comment on HN.

Comment · 6 years ago
Your explanation doesn't make sense to me.

> "you commit the result if no other thread has stomped on your data"

What does "committing" mean here? If it means performing an atomic write (a-la CAS), then you're using a lock (see my next point).

> "If another thread has stomped on your data, you start over."

So you let your thread sit there in a spin-loop and CAS a condition-variable. That's a lock for all intents and purposes, and your system can still "dead-lock" (read: your thread will never get to "win the race"), if your "data gets stomped on" over and over again in-between reads (which are obviously non-atomic, otherwise you'd be locking there too).

> "Usually, there is some sort of guarantee that lock-free systems always make progress."

Getting a time-slice to continue running in a tight-loop while trying to CAS is not the same as "making progress".

"Making progress" would be - you'd get a chance to commit your changes and proceed to your next bit of business logic. But with contention, that's not guaranteed to happen at-all?

Comment · 6 years ago
I wonder why every single comment I leave in this thread is getting down-voted. This community has truly deteriorated over the years.
Comment · 6 years ago
Yes, that aligns more closely with my mental model of a "lock-free algorithm", but what I see in practicality is people avoiding (or re-inventing) synchronization primitives, thinking that they don't belong in a "lock-free algorithm".

You can still use standard kernel-provided synchronization objects (mutex/events/semaphores) in your "lock-free applications", as long as you provide timeouts to blocking wait() calls, and handle abandoned objects gracefully.

Comment · 6 years ago
> "the lock duration is strictly bounded; it is determined by the application or the thread-scheduler"

Practically speaking - wouldn't the exact duration be heavily influenced by the countless layers of abstraction beneath the application itself (kernel, scheduler, hardware, speculative execution, etc)? If so, can we ever truly make the claim that the "duration is strictly bounded"?

Comment · 6 years ago
> "lock-free"

I never liked that term.

Lock-free algorithms will usually boil down to some combination of polling, waiting (sleep(), futex-style), or use what are essentially more fine-grained, hardware-backed locks (CAS, memory barriers, LOCK instructions, hardware-specific transactional instructions, etc). The locks are very much still there.

Comment · 6 years ago
> "6% get 1.3% => 5x too little. I think we can cry a little."

Surely there's more to it than just percentages and genders?

First, how many companies are we actually talking about here? The Nordics are a smaller market - I don't expect it to be in the orders of thousands of companies - maybe several tens or several hundreds, at most. We shouldn't extrapolate if the sampling group is small.

Then, what about the other factors associated with investments? How are the investments spread across different sectors and industries? Locations? Growth prospects? Revenue/Operating Costs?

It's a very shallow comparison otherwise, without this data.

Comment · 6 years ago
Comment · 6 years ago
I'm not sure why you're getting downvoted, but I think it's yet another confirmation that this place has gone full Reddit.
Comment · 6 years ago
> "https://www.youtube.com/watch?v=1G6oRuu9tLg"

Content aside - I feel like this video is terribly edited, scripted and produced. It's impossible to follow - thanks to all the shallow jokes, weird cuts and messy presentation. Almost like it's intentionally made for people without an attention span...

Comment · 6 years ago
To people using custom domains (for email, etc): what is your plan in-case you end up losing the domain name (either temporarily, or otherwise)? How do you prepare for this, reduce the risk, etc?

Losing your domain name can happen due to any number of reasons: hacked account (at the registrar), social engineering, etc. There can also be issues with registrars going bankrupt, increasing fees (see dot-org case), laws changing (especially with ccTLDs - see the dot-EU case with British citizens post-brexit) and much more...

Comment · 6 years ago
> "What I see here is a senior manager type, maybe a VP or a bit below it, who needs numbers that go dramatically up and to the right in the short term and is thinking about their own personal success."

I mean, there are plenty of other ways to demonstrate value without forcing people to login with a Facebook account to use their Oculus devices. In-fact, I'm not sure what added value this requirement demonstrates in the first place?

People already pay for the hardware, servicing, apps/games, and upgrades.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton