E5-2xxx.
804 karma · joined January 11, 2017
What you probably meant: This is where being strongly typed helps. Python is and always has been strongly typed.
Is it? How? It's a simple case of length extension, just that here, since we have two independent starting points sharing the same state, we start with a collision and we extend to a collision.
In other words, these are two length extensions on independent prefixes. It just happens that these prefixes share the same state / hash, hence the surprising result (on a first glance).
I feel like Linux has, in general, from a UX point of view, the worst behaviour when swapping and the worst behaviour in general under memory pressure.
I feel like it has gotten worse over time, which might not be just the kernel but the general desktop ecosystem. If you require much more memory to move the mouse or show the task manager equivalent, then the system will be much less responsive when it thrashes itself.
Honestly, I'ld much rather have Linux just crash and reboot, that'd be faster than it's thrashing-tantrums.
Luckily, there's earlyoom, which just rampages the town quickly if memory pressure approaches. Like a reboot (ie. damage was done), just faster.
In any case, it makes me sad (in a bad way) to see how bad the state of things is when it comes to the basics of computing, like managing memory.
No PDF reader was supposed to just execute x86 instructions from a PDF file (wouldn't be very Portable, would it?), although many PDF readers had enough security issues that it's an arguable viewpoint.
Just... lol.
Do they?
> It also adds to confusion as to why you only get static in some cases, or a message about wired headphones being required.
Poor humans, constantly being confused. Life must be difficult.
This is, after all, exactly how systems hungarian misunderstanding came about.
No.
There are two types of Hungarian Notation.
The original one ("apps hungarian"), which made sense and sometimes still makes sense. Here you would assign a meaning to a prefix. For example, if you're writing MS Word a variable named "sWidth" might be the width of something in pixels on the screen (s), while "pWidth" might be the same width, but in logical units (say pt) on the page. Then you could have a function ptos, and it's easy to see whether variables were used correctly in computations - you can't mix screen-space and page-space coordinates without conversion.
This made a lot of sense, because either variable would likely just be an "int".
Similarly in a Python Webapp one might write "us_name" where us means UnSanitized. So before passing that anywhere else you know you need to sanitize it. See a "us_" variable somewhere that isn't a call to a sanitizer? Probably a bug!
Then there's that other one, "system hungarian", which is the stupid thing everyone knows with stuff like lpcstrWindowName.
So you actually agree. To understand the docs you have to understand git jargon, and the docs aren't too helpful about that.
I certainly don't want to say that the git docs are bad. They're quite complete and written in mostly complete sentences, which is already pretty good as far as documentation goes. Doesn't mean that there is a lot of room for improvement.
This is more up to git being horribly leaky about all it's internal implementation details. I'm not a git developer, and not even that great a user, but I know about trees and indices and refs and refspecs and packs and reachability and objects and merge drivers and smudge and clean and diamonds and countless other details that I feel should be encapsulated way better. git also has next to none documentation of these concepts.
We Germans have that, too - Fernwärme :)
Disk IO buffers, it's easy nowadays, just use something like a MB, which is just fine for almost any application, and doesn't stack up to much memory use (unless you're writing many files concurrently, which can bring it's own problems as well)
xfs_mkfile could do what mkfile does, the description isn't conclusive enough.
Also, memory management. Only in very recent years proprietary APIs surfaced in Linux and friends that allow to leverage some of a modern MMUs capabilities (which is good). Meanwhile we still have stupid MM semantics like fixed / non-reversible allocation commits.
> The database people would love to have well-defined semantics like this.
Yes. Yes they would.
Right now there is no way in no operating system to actually do asynchronous disk IO. You can do an equivalent of write(2) asynchronously, at least on Linux, Windows and I think SunOS, but in all of them it's not really asynchronous; they will run extent allocation synchronously which can -worst case- mean multiple disk read/write cycles. This of course means that for many applications that could make use of async write actually need to use threads and queues for doing it.
Practically every non-trivial POSIX-ish program is not portable. This also includes quite some supposedly higher level applications written using things like Java, Go, Ruby, Python ... since they all leak POSIX details all over the place and make non-portable use quite easy.