swinglock

Speed is the most fundamental feature. Otherwise we could do everything by hand and need no computers.

They will block your tunnel. If you attempt to hide it you will be jailed once found out. Working encryption will be illegal.

My thought too. They are not insecure because they won't be patched, they are just insecure. Even if patched, what's to say there are not 99 other vulnerabilities lurking, even in their supported products?

As you said in the article, the reason is performance and that stands even if a realloc implementation is not poor.

It can't preallocate, so when adding many items it will make many expensive realloc calls that could have been avoided. Though you could have an interface that allows pushing or popping many items at once to make up for it, but this is less convenient.

You can currently forgo shrinking on pop but you can't if mixing popping and pushing. You need to know the capacity for that, otherwise it may actually shrink on a consequent push. This could incur many expensive reallocs if used similarly to a stack.

Even the cheap realloc calls will cost more than checking an int in code that's likely small, inlined, and with its data in one cache line (number of items and capacity next to each other in one struct, which are also next to the first item). The realloc function is probably dynamically linked, more complex, and has to access additional data.

If you don't want to add more memory overhead to the vector, consider just using two ints and it won't be any larger, that's enough unless a vector should be many gigabytes. Otherwise if you think that's not enough and feel like leaning into the complexity instead, use bit fields or bit twiddling to split up one 64 bit int into say, 56+8 bit ints. Let the smaller int track additional capacity rather than total capacity and also use that to solve your hysteresis problem. Well, or just use two 64 bit ints, but what's the fun in that?

Word.

Popular allocators will indeed grow your allocation in-place without moving when possible. This is essentially the same as if you'd tracked it yourself in your vector and grown it once in a while, though it will work with bytes instead of number of items. See for instance the size classes in jemalloc at https://jemalloc.net/jemalloc.3.html. If you ask for 1 byte, you actually have 8 bytes, so realloc within the same size class will be cheap compared to actually moving.

They built the lightning network, it's meant for this use case.

It supports keeping long term history so you can find a page you visited years ago from the history search in the address bar. Chrome/Google likes when you have to search for it and Brave has inherited that.

And XFS will at unexpected shutdowns sometimes leave you with files that previously contained data now being 0 bytes.

I only really trust ZFS on Linux, but it's such a bother it can't be upstreamed and isn't fully integrated with the native Linux caching, as the native file systems are. Ext is fine too but it's missing features like checksumming and compression, and has limitations as you mentioned.

That could perhaps be a useful if you had just enough memory to run a game, if not for other processes using it too. In that case background services should be written to swap while running the game which will probably cause stutters. Doing it before starting the game instead would be better, if it has to be done. So such a utility might then be useful in some cases when someone couldn't afford enough RAM.

Instead try for example "washing machine motor" and you'll find it's a feature fixing issues with clarity, not a style preference.

mimalloc is cleaner but lacks the very useful profiling features. To be fair it also has not gone through decades of changes as described in the postmortem either.

Last I checked Redis used their own fork of jemalloc. It may not even be updated to the latest release.

Both Asus software and customer support is atrocious and always has been.

I figure the programming brain matters the most for programming.

Add enough random nodes and eventually it will be even, so it helps.

What kind of incidents, if you don't mind?

Are you certain that CVEs are a good indicator?

Not quite static. Hitman and Red Faction comes to mind, years before Half-Life 2. Still, it was groundbreaking.

I'll take that bridge off your hands.

Perhaps. Tags might be fitting instead.

Is forking a well defined term? Doubt it will hold up in court.

It seems an attacker can combat that defense by just running more nodes.

Oh well, it was probably just a crash in my Internet connected software where users can just sent inputs to be processed on my machine.

RCE would have been worse than file system bugs, as it leads directly to a superset of problems including potentially losing all your files.

If the market comes to prefer inflation, it should eventually happen.

Does it even have RAID5?

Server class hardware will let you choose. Other varies. Some will let you choose to always start on power, some won't. "Restart on power loss" should cover your use case, since you don't shut down the computer gracefully on low power.

It's more secure because it's resistant to MITM attacks or a compromised host. Because the password is sent, the private key isn't.

Are you upset? Can't do nothing about it? It even made a headline or even just a thread on a forum? That's reason enough for some. It could easily be a teenager with no better excuse than not having a fully developed brain and no better reason than liking to ruin things. Having seen how much that happens, I guess it's more likely than a conspiracy or a crime with any rationality behind it.

The article omitted it, but the message says to update iOS to the latest software and enable its lockdown mode.