md5person

"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.

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?

I wonder why every single comment I leave in this thread is getting down-voted. This community has truly deteriorated over the years.

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.

"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"?

"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.

"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.

"In reality very very few ISPs are giving one IPv6 address per customer"

In actual reality, global IPv6 adoption is at ~33% [0, 1], so I'd say this is, at best, a premature and naive presumption. ISPs actively engage in rent-seeking, and resource scarcity is another contributing factor. In-short, there's nothing in OPs comment that warrants the downvotes.

[0] https://www.google.com/intl/en/ipv6/statistics.html [1] - https://www.akamai.com/uk/en/resources/our-thinking/state-of...

I'm not sure why you're getting downvoted, but I think it's yet another confirmation that this place has gone full Reddit.

"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...

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...

"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.

I think some of the artifacts on the video at 0:12 (handbag thing) are very noticeable. Same thing at 0:19 (cat)and at 0:28 (cat again). Otherwise, looks nice :)

"In my coffee analogy, the promotion of the fair-trade alternative would be based on the fair-trade mechanism for ensuring the lower levels of the production chain receive a fairer share of the income. Whether or not the author pays less or more at the store is irrelevant to the argument."

But for there to be any form of income trickling down production chains, someone has to be willing to pay something for the services they consume. Is this controversial in any way?

"I gave you an example by quoting how expensive it is to run a "free" jitsi service."

That's an entirely meaningless argument. Here's what you're doing:

"I run a large-ish jitsi instance: approx €50/month just for the VPS, my hours probably add another €2000/month to that."

Here's what Sussman is doing:

"I used a Jitsi Meet server that I installed on an obsolete and otherwise useless computer that was sitting idle in my laboratory, on its way to the electronics junk heap."

The two scenarios are not comparable.

I'm not making exaggerated claims here. The University can absolutely afford to do better, the students (who pay exorbitant tuition fees) deserve better, and any "libre software" idealism here is simply people trying to cut costs, jeopardizing the quality of education and the overall experience, while touting moralistic superiority...

Distance learning, for example, could've been a much more widespread and accepted thing, had it not been for instructors cobbling up together scrapyard-bound hardware to use as a chat server. Coming up with a proper solution takes investing (time, money, expertise) - which some people will evidently avoid at all costs...

"You seem to fail to grasp the difference between "free as in beer" (gratis) and "free as in freedom" (libre)."

Why are we going back-and-forth about this again?

I previously asked whether there were concrete examples of software used during the course that were "free as in freedom" but NOT "free as in beer", and the response to my question was that no such examples were available.

It's the actions that matter here, and the bottom line is that they weren't intending to pay for anything to begin with. And by that, they were abdicating the "it's not about the money" argument, in my honest opinion.

This isn't an accurate analogy, is it?

We're discussing an educational institution with power and authority (MIT), which promotes drinking "free coffee", whilst simultaneously portraying it as somehow morally superior to "coffee one has to pay for" to consume.

Growing and selling coffee takes time, labour and effort - yet none of that is being reflected or accounted for when we choose to not pay for the coffee we consume.

Is this a sustainable approach? Does it promote "choosing the right tool for the job", or does it promote blind idealism ("free is better")? And why does a university, which takes exorbitant tuition fees, not prioritize the best software for the course (over the one that's merely free)?

"Sussman means free as in freedom, not free as in beer :) (see: https://en.wikipedia.org/wiki/Free_software)"

Sure, but conveniently enough, the software listed in the parent article [0] all happens to be "free as in beer".

What examples of "free as in freedom, but we had to pay for it before we could use it" software was used during the course?

[0] https://www.gnu.org/education/teaching-my-mit-classes-with-o...

What's wrong with having to pay for software? Or learning to accept that some software is proprietary? Or even with learning to use the right tool for the job, even if that "right tool" may sometimes come at a cost?

Students are required to pay for their education at MIT. Were the costs of this course offset with the costs of the non-free software used in an otherwise "standard course"?

People put immense effort into developing software. Is asking for compensation for one's time and effort somehow wrong?

And in many cases, proprietary/commercial software really does outperform the equivalent FOSS/Libre solution. Why are we teaching people to reach out for the suboptimal tools in these situations?

I think it's because the generated text will generally follow a reasonable "structure", it's "framed" relatively well and you (as a person) will recognize those patterns quickly. There's plenty of "glue" used throughout the text. Those are all patterns which we pick up very quickly, and we're used to seeing them in "real text".

Exampels from the comment above include using things like: "A year ago", "made headlines", "Now, it's the {event}, and {name} is at it again. But this time, ...", "{name} was not impressed", "You know, I feel like, I feel like you could have ...", "I don't know if... but...".

Those are all very common in those "online celebrity magazine" type texts...

It's only when you actually read into the stuff that's in-between, you'll come to see it's pretty much a load of nonsense. But that takes a bit more time and slower reading.

Thanks.

So, a given "specification" (how a font looks to the human eye) can have many different "implementations" (ie. TTF files). The specific "implementations" themselves can be copyrighted, but somehow not the "specifications"?

If so... assume one TTF file which is copyrighted, pay-per-use license. Assume another TTF file, which is open-source, free to use and redistribute. The files both implement the "Helvetica" specification, rendering the same letters to the human eye. How "different" must the free implementation be from the paid one, for it to not be considered an infringement?

Who is this for exactly?

I don't see how the target can be entirely non-technical people, since this still assumes some knowledge around databases/functions/REST/HTTP/Schemas/etc.

Technical people have very little reason to use this, since this platform is a walled garden of proprietary tooling, and there's only so much you can achieve with abstractions and fancy ORM. You won't be able to break out of the mould when the time comes, so why waste your time in the first place? Do it right the first time and maintain your flexibility and freedom later on.

I believe the only remaining target audience here is technically-inclined people that want to build a cheap prototype quickly, just to test ideas. This is a playground basically.

"Who cares if an application's UI elements look the same across platforms?"

Designers.

End users simply want a functional, working product. Polish on top is a nice added bonus, but these days it's been turned into the focal point of software development. A Teams/Slack-caliber project begins with product requirements, immediately followed by design and UI mocks - the software/tech always comes last.

Hmm, let's read this one.

"March 28, 2019"

"Fibers: the Most Elegant Windows API"

"The Windows API — a.k.a. Win32 — is notorious for being clunky, ugly, and lacking good taste. Microsoft has done a pretty commendable job with backwards compatibility, but the trade-off is that the API is filled to the brim with historical cruft. Every hasty, poor design over the decades is carried forward forever, and, in many cases, even built upon, which essentially doubles down on past mistakes. POSIX certainly has its own ugly corners, but those are the exceptions. In the Windows API, elegance is the exception."

I'm glad OP just discovered in mid-2019 an API that has been there since Windows XP (ca. 2001). Why then, does OP start by crapping all over the Windows codebase?

You think the Fibers API is elegant? Have a look at IOCP. IO in Windows in general actually, since the days of Windows 95. Event management. Threading and parallelism. The kernel subsystem. The APIs in Windows have remained stable, consistent, forward and backwards compatible - from pretty much day one.

"Do not use goto, setjmp or longjmp."

Error handling in C without those primitives will almost always result in horrible code. They should've made an exception here: "goto error;" should've been allowed and encouraged.

I appreciate the idealistic take on what a "principal" role should be like, but in all actuality, principal engineers are commonly the ones that simply stayed there long enough (ie. to survive multiple re-orgs), and played their politics cards wisely. They were playing the title game. Often, their work is invisible to most. They perpetuate tribal knowledge, and have trouble letting go of the past and accepting change.

You'll notice plenty of comments here from people who claim to be principal engineers - stating that they "kinda follow it all". I wish we could talk to their colleagues though (the juniors, seniors, PMs, tech-leads, support/escalation engineers, as-well as other principals).