220 VAC allows higher gauge (thinner) wires for the same wattage consumption and more watts per circuit for the same amperage (more powerful appliances and/or more concurrent appliances without tripping a breaker). And the UK in particular has far safer plugs than the US, with a fuse in every plug, partially insulated plug leads, and blocking shutters on the sockets.
So basically we could use less copper, have safer homes, and simplify power supply design since we (and a handful of other holdouts) are basically the only countries using 100-120 VAC rather than 210-230 VAC, which would lower costs and reduce waste.
There are definitely cheaters in (nearly) every match of every game.
I should know, because I decided years ago to take the path of "if you can't beat 'em..."
Once I did, it became painfully obvious how many people cheat. With x-ray, "wallhacks," or 3D "radar," with bounding boxes around all players, it became readily apparent who's aiming at and/or chasing players who shouldn't be visible, always choosing the route the opposing team is taking, without fail. And who on the other team always takes the route you take, chasing you through any maze with no problem, even turning around when (and only when) you try to flank them. Also anyone who out-scores you while cheating (particularly if you're "rampaging") is definitely cheating as well, because you're already doing better than is humanly possible. And believe me, you'll get out-scored plenty.
I would be glad to have functional anti-cheats, but it's just not possible in my experience. Cheats are available on day one of any game launch, or day 2 at worst. It's big business (clearly). Even kernel drivers like this have patched kernels to get around them.
For now, cheating makes games fun to play again. Aimbots aren't perfect anyway, and even if they were, nobody can look or shoot everywhere at once. You still have to manage ammo, you still have to reload, and you can still get the drop on people (cheaters) when their attention is focused elsewhere, and you still get killed while cheating. Sure, it sucks for the people who don't have cheats, but I'm not going to be one of those people as long as a large percent of other people are cheating too. Unless and until anti-cheating actually works, it's just evening the playing field as far as I'm concerned.
I get where the author is coming from, and I'm often dismayed by how much of programming is just shuffling data from one platform/format/structure/persistence layer to another. It's tedious AF.
Still, there appears to be a lot of conflation of concepts here, and I don't see anything approaching crystallization of a coherent solution.
What do I gain by telling the OS that I want a JPG rather than a sequence of bytes that I know is a JPG? I'm probably already using a library to deserialize this for me, unless I'm a masochist, so the heavy lifting has already been done. And that object/struct/whatever is going to be represented somewhat differently in memory for Java than for C++ than for Python. There is no way to reconcile those differences without creating even more problems. So a programming language would need to either be written or adopted to standardize on.
Most application-specific data is already stored in a database of some sort anyway, which is itself (potentially) platform agnostic. To assert that applications should instead rely on the OS and filesystem to provide this persistence layer is to assert that there is a universally appropriate choice of database -- a bold claim.
Moreover, if structure can (must?) be defined by the application which is interfacing with the OS, then nothing is gained but overhead. Every object would need a description of itself, so we either end up with redundant structural information for every file, or else we have some centralized table of "object types" that the OS has to look at every time we request something.
Maybe I'm missing something, but I don't see the appeal here. I understand the desire to reduce overhead, but as far as I can see, this just creates more.
Ok, today we have shells like bash that can help you navigate around a file system, find files, run files, search files, view files etc. Common tools are grep, less, cat, "|", awk, sed, perl, tr, wc, find, etc. The <cr> is a poor mans record seperator.
Experienced people can often do non-trivial things in shell by combining a tools, regular expressions, and manually filtering out false positives. I.e. using grep foo | grep bar for that one email you are looking for.
But as a result things that need more structure require significant coding and create a sandbox that doesn't work well with other systems. Like say thunderbird (an email client).
Now imagine something different that has some higher level of abstraction. Maybe every file gets by default a list of functions to help the OS understand it. How about dump (raw byte encoding), list, add, view, delete, and search. Each file type supported by the OS would get those features, one of those might be jpeg. So of you created an address book, you'd define a record type called person, and a list of fields. One of those fields might even be a JPEG for a image of the person. In a GUI (like thunderbird) you'd just wrap a function called addressbook.insert much like just about every GUI platform has a file picker.
Ideally every application on this OS would make use of these function calls so every app that needed an addressbook could share the OS calls to interact with the addressbook. But also instead of being frustrated at thunderbird you could use your addressbook for new and different things. Like say a map viewer might put icons up for every home address in your addressbook. Or you could query you addressbook for the home address nearest you... from the command line.
Ideally this files are actually objects that include data and code. Said code could inherit based on primitives from the OS like records and fields. That would enable things like extending the addressbook to handle a new field like your keybase ID, PGP key, 3D representation of your face or whatever.
Similarly any image viewer, or even a pipeline using standard image tools could iterate over all your JPEGs and extract geo tags.
The object aware "find" replacement could access records/fields for all file types so you could find photos within a distance of a long/lat.
By combining the above with a relational database instead of a filesystem you could mix and match and create virtual folders for things like the top 1000 newest images on your "filesystem". Suddenly replacements awk, sed, wc, less, etc would understand email message metadata.
Or make a directory that contains the newest email messages you haven't replied to. Running ls --fields=From,To,Date,subject would give you a summary of email in a folder.
The code replication for understanding a file format, serialization, communication, etc would be greatly reduced and moved largely from the application space to the OS space and result in significantly increased compatibility between applications. Imagine instead of a zillion files under ~/.thunderbird that instead it was all in a database compatible with any email client that's supporting the new record/field standard.
Percent of volume says nothing about the line level, which is hardware specific. Since audio jacks were invented before we had industry standards bodies, there is no specification that hardware manufacturers have to meet. Many provide around 1Vpp, or -10dbV, at max volume, but it's going to vary from device to device. The impedance of the headphones are going to affect the SPL as well, and none of it is likely calibrated to any high degree of certainty unless you're buying professional equipment.
