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.
It’s used flippantly at times, but lock-free is a technical term referring to a guarantee of global progress https://en.m.wikipedia.org/wiki/Non-blocking_algorithm (I think it’s also sometimes used as a synonym for non-blocking, so including “obstruction-free” too).
For instance, if all threads except one are stopped, the single running thread should “finish” (for whatever finish means) in a finite time (lock-free is stronger than this condition, too). An algorithm using mutex-style locks fails this guarantee, if one of the stopped threads is inside the critical section.
‘Lock-free’ means the application cannot ‘lock up’, rather than there are no locks. CAS does use a kind of hardware-level lock in the cache, but can never cause any application to lock up because there is no per-process state like in a software lock.
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.
True, but the key difference in the lock-free approach is that the "lock" is basically a pointer-swizzling or timestamp-swizzling operation, and so the lock duration is strictly bounded; it is determined by the application or the thread-scheduler.
With a lock, you acquire the lock, you perform your operation, and then you release the lock.
Lock-free is typically done differently. You don’t acquire a lock, you start performing the operation “optimistically”, and you commit the result if no other thread has stomped on your data. If another thread has stomped on your data, you start over.
One of the important differences here is that it’s a race. Whoever commits first, wins. With a lock, you have to wait for whatever thread acquired the lock first. That thread may not even be running.
So, lock-free is fundamentally different because with a lock-free system, a thread that is running will always complete work (you just don’t know which thread). In a system with locks, threads that are running may be prevented from making progress by threads that are not running.
Systems with locks can also deadlock, lock-free systems cannot deadlock. Usually, there is some sort of guarantee that lock-free systems always make progress.
> "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 think you’ve just mixed up wait-free with lock-free.
- Lock-free: at least one thread will make progress
- Wait-free: all threads will make progress
The difference between locks and lock-free is very noticeable if a thread holding a lock is suspended (which can happen on a modern system just by accessing memory that is paged out). On real-time systems it’s also possible to guarantee that high-priority tasks will make progress, regardless of how a low-priority task behaves. With locks, a low-priority task can easily prevent a high-priority task from running at all.
> "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"?
Because a lot of your comments in this thread are "missing the point" or (unintentionally) misleading at best, and it's easier for people to use a downvote to make those comments less prominent in the discussion than to go through the trouble of trying to explain why the comments are missing the point or unintentionally misleading.
But, a lot of people have gone through the effort to leave explanations in this case. Isn't that good enough?
For one unaddressed example:
> 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.
This might be technically true, but atomics provide significant performance benefits compared to using a mutex with a timeout, and I don't think of "lock free" as relying on busy loops as you seem to think in your comments. I'm sure a busy loop makes sense in very specific algorithms, and mutexes themselves often use a limited amount of busy waiting to avoid context switches. You can simulate atomics with mutexes, but that's not the point. Lock free is hard to do correctly. Mutexes create the possibility of a deadlock, which is incompatible with being lock-free, so you have to avoid all the footguns of lock-free and the footgun of using mutexes.
So, yes, you can use standard sync objects... but that doesn't make anything better in this case. It misses the point. "Technically correct" isn't always good enough to get an upvote.
If you don't agree, that's fine... but this is completely uncalled for and against the community guidelines:
> This community has truly deteriorated over the years.
No one is obligated to upvote things they consider incorrect, and downvotes are perfectly suitable for this purpose under HN guidelines.
> "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.
Because it's misleading and/or missing the point. As stated. Why would I want more people to read something that I believe is misleading?
> Clearly it's not "fine"
Once again missing the point. The prevailing opinion on HN is what will get upvoted, and a lot of other stuff will get downvoted. I have seen that prevailing opinion be hilariously wrong before.
If you want to be heard with an unpopular opinion, you have to make a compelling argument... you can't expect to be upvoted to the top just because you're sharing an opinion. It's rare for a comment to be lukewarm enough for no one to feel strongly enough to downvote it. It's going up, going down, or it's on a thread no one is reading. Downvotes don't mean people hate the person leaving the downvoted comments; it's just a tool for disagreeing with comments.
> This is my last comment on HN.
Because people disagreed with you? People even left explanations, but that wasn't enough.
> "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.
Performative cynicism + speaking hypothetically about past events = I'd downvote it twice if I could. In reality very very few ISPs are giving one IPv6 address per customer. ISPs are greedy but they're not wantonly cruel.
> "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.
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 :)
Some scenes, foregrounds, backgrounds, lighting conditions, movements, etc work better than others - there's a lot of potential for errors in videos and the videos from the examples page are straight from Unscreen Pro. We're continuously working on improving the AI though (NB: We don't use video uploads for that - see unscreen.com/privacy)
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?
The second of the "four freedoms" of free software is
> The freedom to study how the program works, and change it so it does your computing as you wish.
That is particularly important for students of computer science -- what better way to see how all kinds of software works than by reading and modifying its source code?
I'm surprised if a "standard course" doesn't mostly use free software. Mine certainly did, I remember only a single module where we used a commercial software package (something for hardware simulation). I've never felt that this has limited me in any way. One module had us modifying the Linux kernel.
You find people willing to pay for your work, not for a license. If your ongoing work is not worth anything, why should you be paid extra for work you did in the past?
>If your ongoing work is not worth anything, why should you be paid extra for work you did in the past?
If you write a piece of software that took you a year to write but buyers are only willing to pay $500 for then do (A) live on $500 or (b) try to sell to many buyers including some in the future?
You seem to be saying (b) is out of the question but if it is who will write the software these people wish to buy?
You can find multiple buyers before you write the software, you know - you don't have to have just one person paying you. If it's consumer software, things like Kickstarter or Patreon are how this is often done - if it's b2b, this is how a lot of software development is done anyway. Examples of software successfully funded via crowdfunding include Spine, Magit, and Diaspora - although Spine appears to be closed-source anyway. You can write an MVP, pitch it to potential clients, and write software that provides value to them. That's what I'm doing.
Yes, copyright is unethical, as is closed-source distribution. Sell actual work - there's always work to be done on or around software. My project is livestreaming software, but it turns out there's plenty of folks who don't want to set up livestreaming software, they just want to pay someone for the result of having a solid branded stream - so my business model is providing them that end. If I could do it reasonably with existing software, I would, but I can't, so I'm writing software for it.
And there's nothing to stop someone else letting you write all the code and get paid for the bit you charge for, right.
In fact they could work full time on that while you have to spend time doing software updates/maintenance etc.
If I'm not making money off it, I'm going to stop writing it and find something else to do, obviously?
Being able to say "I have deep technical knowledge of this domain, proven by the fact that I literally wrote the software and can customise it to your needs" is worth something, unsurprisingly.
I think you're assuming that most software work is confection.
In reality, or at least in my case, pretty much all the money I've ever earned was in doing bespoke work.
You _could_ see contributions to FLOSS as loss leaders; though that wouldn't be accurate, since there are definitely benefits beyond just advertising your skills.
A key benefit: if there is a set of freelancers working around a single FLOSS code-base, each of them actually benefits by contributing back; because the shared code-base increases in quantity and quality, and thus leads to competitive advantage for all.
How could an architect of great ability ever become wealthy if they weren’t able to just sell the same building design over and over again with no work for decades? Oh wait, that’s the norm.
Earlier you said copyright is unethical and also why should you be paid extra for work you did in the past.
Architects have copyright to their work. They do sell the same plans over and over. No one can just copy their work without paying royalties or at least getting permission.
Wealthy, great architects make their fortunes on bespoke work. Even the plans they sell often have to be changed for each location - it's uncommon that the exact same building can be replicated in different locations over time, due to local planning constraints, preferences of their clients, new regulations, and so on.
Great software developers deserve to make their fortune too and should be free to do so in a manner that suits both them and their (consenting adult) clients without name-calling from developers with different philosophy/orientation.
Copyright is a legal fiction - it doesn't exist except by force of the state, and there's plenty of evidence that it has a large variety of downsides. I think it's entirely reasonable to argue for alternative methods of providing benefit to society that don't rely on having the state threaten people for you.
Or, in other words - the default state of things is that copyright does not exist, not that it does. It's on copyright proponents to prove that we have a better world with it than without.
Great software developers already largely make their fortune doing bespoke work for clients with a need for it. So do great lawyers, great doctors, great system administrators, great technical writers, and so on. This isn't a new idea.
All software isn't line of business bespoke jobs for mega corp. Family business sometimes need software specific to their vertical market but can't afford to employ someone for a year to do it.
Indeed, but who's making their fortune selling software to family businesses? If you're going to make "a fortune"... sell to people who have money. You can make a living though, quite happily. If there's a pile of small businesses which all need more-or-less the same software, set up a crowdfunding campaign and advertise it wherever they hang out. Sell a support contract. Sell a training course. When someone wants that one extra feature, quote them for it.
Or even better, grab some other people with knowledge of the domain and go find capital so you can do what the other businesses are doing, but better, because you're backed by deep knowledge of the software that runs your company and the other companies have no clue and no money.
Why do you think so? Purism created its products using crowdfunding, i.e. they sold their devices (and free software on them) before anyting was created.
In the particular case of Purism Librem 5 phone, many people decided to buy the device in order to support the development of free software for mobile phones. As opposite to the PinePhone, whose developers do not develop any software and rely on the "community developers".
Really? If the car contained no software, people would still buy it over alternatives that contain software at various levels for a better driving experience, comfort, and entertainment?
Becoming employed by a car company that wants to improve the experience of their vehicle is a perfectly reasonable option though. Or writing software for someone else's car - there's more than enough gearheads who'd spend a ridiculous amount of money on custom code for their vehicle if only they were permitted to.
Develop domain knowledge of the motor car. Ever more outlandish scenarios to enable you to make money from software in an open source way.
Well I want to develop software for devices people already have, their PCs.
Nobody but some software developers and those who don't want to pay anything cares if the software is open source or not.
Proprietary software has worked well for business for decades. It's more likely to be maintained and extended because it's paid for.
In my market there's cut throat competition between various proprietary software companies. All have developed software to migrate each others' data.
Don't like software A then go with software B or C or D.
I'm struggling to understand your reasoning. If the author had said "I only drink fair-trade coffee" would you also object if it happens to be the case that the fair-trade coffee is the cheapest type at his local supermarket?
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)?
You seem to fail to grasp the difference between "free as in beer" (gratis) and "free as in freedom" (libre).
Your coffee-response is all wrong: this is not about "free" coffee, about (not) having to pay for coffee, but about a moral stance on coffee: e.g. demanding the cafetaria only serves Fair Trade coffee, regardless of the price.
This is not about "having to pay for it" at all. The opposite really: running your own jitsi or BigBlueButton is probably more expensive than using the free tier of Teams, Zoom or Hangouts.
I run a large-ish jitsi instance: approx €50/month just for the VPS, my hours probably add another €2000/month to that.
> "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.
> "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...
"It made available licenses for various nonfree programs, but I objected to them on grounds of principle.".
Which is to say Sussman could effectively, for the purposes of this course, get _any_ license for free-as-in-beer.
So the actual decision would purely be on some other grounds. Since Sussman is a world renowned CS teacher, I choose to believe he made his choice based solely on whether it was most suitable to teaching CS.
(This is not an unreasonable belief: The concept of "Free Software" guarantees that the student is able to take the software apart to see what makes it tick. That is obviously a very valuable property when learning how things work!)
> (This is not an unreasonable belief: The concept of "Free Software" guarantees that the student is able to take the software apart to see what makes it tick. That is obviously a very valuable property when learning how things work!)
And something that resonates very well with the basic attitude and culture of academia/research.
The article you point to illustrates that that basic attitude and culture is under threat. I agree. Openness, being able to build on the works of others, and learning "how something ticks on the inside" are still basic to science though.
I, too, wish that what the article illustrates weren't happening, but are you really arguing that you can't take the idea from a published paper, understand it and build your own work on it? The FOSS philosophy is the closest equivalent for code.
> promotes drinking "free coffee", whilst simultaneously portraying it as somehow morally superior to "coffee one has to pay for" to consume.
The price does not enter into Sussman's argument. Maybe it could, given how students tend to be short on money and abhor paying for expensive textbooks, but it doesn't.
> 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.
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.
> Is this a sustainable approach?
For this class? Almost surely!
For some people (e.g. me)? To a large extent (things aren't black and white). Apart from (the admittedly large chunk of) non-free Javascript run by the websites I visit, and some firmware, my computing world runs entirely on FOSS.
For absolutely everyone in every situation? Surely not. That's OK.
Really, the only point that matters a lot here is the first one.
> Does it promote "choosing the right tool for the job", or does it promote blind idealism ("free is better")?
It seems to me to also promote the fact that FOSS is far more compatible with academic culture and behavior. While indeed you may have to pay publishers for access to articles (luckily a practice that's on decline!), you certainly have complete freedoms to build on the work presented in those articles for your own research!
I'd go so far as to say that no closed tool can ever be "right for the job" in an academic research setting! (Although one sometimes does have to compromise when no adequate alternatives exist, especially when it comes to lab equipment – but in the CS world things are a lot 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)?
I don't understand what MIT's tuition fees have to do with this.
> "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?
> 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?
No, but it is also entirely orthogonal to the blog entry we're discussing. At no point does the monetary cost of something enter into what Sussman is talking about. You seem to be conflating free-as-in-beer with free-as-in-freedom (man, I feel nostalgic writing those phrases again – I don't mean this as an offense, but the difference seems to be so much more well understood among the tech savvy these days than it was 15 years ago).
This is where the coffee analogy becomes relevant. While indeed the cost of coffee affects a lot of things in the coffee value chain, the idea of fair trade (for all its flaws, let's not digress into those here) are not about the end product's cost.
Your question is missing the point, but to give an answer:
Sussman taught the first edX course, 6.002x. Agarwal took credit for it (since he shot the videos and was the face), but Sussman did the plurality of the work, followed by Terman, by Mitros, and then by Agarwal.
Open edX is free-as-in-beer but not free-as-in-price.
I actually think that free software is an excellent choice for a classroom because not only can the students examine how everything works, they can take a copy home with them and modify it.
I wish I had had that opportunity when I studied computer science, because my tools were treated as a sort of "magical black box" with no visibility.
The programs we wrote in class were toy programs, and there was no sort of "reality check" for how our editor or compiler or any other tool was actually written.
A large part here is the "sales". Commercial software, almost by definition, has a sales team that ensures their software is bought by universities, companies, governments etc.
Non-commercial software does not have this in that sense. It may have advocates who, out of sheer enthousiasm, bring software into such universities, companies and governments, but hardly ever an actual sales.
And since non-commercial software is largely FLOSS, whereas commercial software if most often proprietary, we see that, simply through sales, the proprietary alternatives are used far more often.
Regardless of any technical merits. Technical superiority hardly "sells" software, sales teams do that. Unfortunately, I might add.
No one objects to people being paid to make software.
What if people were paid through public grants, or paid well through the welfare state; instead of through the legal scarcity provided by intellectual property?
You're assuming a generalization which is not present in the article. People can disagree on the merits of paid software and still agree that teaching using open solutions is has benefits. One does not necessarily follow the other.
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.
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.