scj

The word matches his intent of "Free Software" without English's ambiguity around gratuity vs. freedom.

The article makes it sound like the later. Which will be about as effective as "thoughts and prayers."

There are a lot more practical and lucrative skills for a young programmer to focus on than C or C++. Many will be able to have good careers without going that low level.

What impact will that have on the economics of legacy C/C++ code bases in the 15-30 year time frame?

Sure, you'd like to have been dealt a better hand. But you haven't, and dwelling on that won't help anyone.

The problem with this metaphor is that it's easy to describe the contents of a hand. But computer programs are a lot more complex than that, and sometimes it's non-trivial (and possibly NDA violating) to describe why the recommended solution isn't feasible.

If you ever help someone in that situation, know that you are a hero among programmers.

Skimming Intel's spec ( https://cdrdv2.intel.com/v1/dl/getContent/776648 ), the X86S looks really risk-adverse towards changing Long Mode user space.

I don't recognize any changes offhand, but my knowledge of x86 legacy is pretty limited (and will hopefully be obsolete soon).

There were a lot of little things that added up:

  1. Everyone interprets the 1.0 - 10.0 rating scale differently.
  2. Most users just rate the same, universally known games.
  3. For the other users, the games they've played are usually really different.  It's a sparse matrix.

I managed to find a few dozen similar users. Found some hidden gems by going through their pages manually. Fewer than I would have hoped though.

I'd add a conditional lesser virtue when working on certain codebases that should have been accounted for when making perl6: Fear.

Sheer tenacity is typically sufficient for scientific codebases.

Remember, the opposition and the Senate can get bills through in a minority parliament.

Betting a mere $20 on a case currently in court could be fun.

But my time is worth a lot more than that. So if I'm thinking about starting a viable open source fork off this thing, I'm effectively betting a lot more.

That kind of begs the question, who am I betting against? I'm suggesting on the other end is an entity that chose a licence that attempts to minimize competition. Please, re-read the last sentence as I can't stress it enough. What happens if that competition-adverse entity's business model is existentially threatened by my fork?

Maybe they're willing to try their luck and try the MIT license in court.

Whether or not I'd win doesn't matter to me. A long lawsuit is going to be expensive either way. The question I'd pose is if the case would be quickly dismissed?

I'm not a lawyer, I have no way of answering that. But I've donated money to more than one programmer's legal fund against an absurd case that was clearly meant to just kill the project [0]. I don't want to be that programmer. I'd rather work on something else.

Which gets to the actual point I've been trying to make all along. I personally wouldn't want to fork this, and I suspect a percentage of the open source community feels the same way. And forking is one of the most important aspects of open source.

[0] https://lwn.net/Articles/181261/ - The programmer actually emailed me back with a thank you note, expressing some surprise that a non-American would care about a legal system they were not subject to.

Makes it seem like it would be a legal grey zone in the US. And a reminder, not all of us are American and the ambiguity might be even less favourable in other jurisdictions.

The trick is that you don't need to threaten everybody, just any fork that gains traction and might be a viable open source project.

Otherwise stated, you don't go after every user, just the competition.

An open source project that starts to "scratch an itch" is far less likely to revoke a license than one that is motivated by money.

Motivation aside, if it's a non-trivial organic project, they've likely taken many patches from others and effectively cannot revoke the license of the code base.

But I shouldn't say "motivation aside" as motivation is the point when it comes to trust.

At some point, a significant enough portion will be two years old and changed to the escrowed license. A fully open source fork will become tempting for pragmatic and ideological reasons.

If forked, what are the odds the copyright holder will re-license their source code for the sake of control & profit?

Every semi-open license/core tactic is just a rug-pull waiting to happen.

"There's no question that it was a coffin, and I'd have flown it gladly."

Of course, it begs the question if such a clause remains open source (as it will effectively discriminate based on country). But defending open source developers in a hostile environment should take precedence over cooperation.

It's just unfortunate that such measures seem necessary (looks at the EU's CRA).

Doing so helped me become a better assembly programmer.

Software can be installed on billions of devices. Even a low liability could be financially ruinous...

Especially for open source.

I don't know what case history is like for damages with open source projects, but I suspect it wouldn't be that big of a concern for Microsoft.

Otherwise stated, Microsoft's downside to this is committing their lawyers. And the upside is to improve their code generation tools.

IANAL though.

Even if I don't buy one, I dread to think of what might happen if enough fridges across the world stopped working all at once (demand for non-perishable food and fridges would skyrocket).

For the sake of consumer safety in our imperfect world, there should be a safe-mode hard switch fallback for any life-critical and/or high wattage device that gets networked.

Although a flat memory space / full file approach would be nice, I wonder if a paging scheme would be possible?

Where you would only need all possible finite strings of length N, where N would ideally be the max page size of RAM, but could be less if the substring could not be found within a reasonable offset...

Ignoring compression speed, I suspect it'd have a practical limitation where using a maximum offset would mean that some strings wouldn't be as big as the cell needed to describe them. That's usually the gotcha in schemes like this...

In order to entertain this, I think all possible 12 byte strings (64bit offset + 32bit size) would need to be found within whatever a reasonable amount of storage is.

I suppose the computational challenge is "How big an offset is required to have all possible strings of length N?"