Curious, "dynamic masking on LED headlights", are you referring to the LED matrix systems where individual pixels will be turned off as to not blind those in front of you, but the remaining pixels are still on?
If so, they are widely adopted here in the EU but only for full beams not the regular headlights.
Yes, that’s what I’m thinking of. Search says it’s sometimes called Adaptive Driving Beam or Dynamic Light Assist.
Ah too bad if it doesn’t apply to low beams… LED low beams are still extremely problematic.
The search results are telling me that dynamic masking in the US will only apply to low beams and not high beams. Maybe that’s a good thing? I’m just hoping the situation will get better somehow.
Definitely, I'd love for that here in the EU as well. With it being pitch black half of the year here in Sweden I'm constantly blinded by LED low beams to the point that high traffic country roads are becoming very difficult.
However, LED matrix / dynamic high beams is also a godsend. On a country road, you can keep your high beams on and they will disable the pixels that would blind the other drivers, but still light up the side of the road where deers and moose appear.
They are fantastic, but not for the other drivers. I live in Sweden where it's very, very dark for a large chunk of the year. I'm also not a boomer. But when it's very dark, the difference in blinding is staggering between meeting an old yellow light headlight vs a modern LED headlight. It's not about lack of inspection (although that is also an issue as it seems many headlights are not properly calibrated), but difference in the warmth of light itself. LED headlights is great for you at the cost of everybody you meet on the road.
Human eyes are hypersensitive to blue-white light, but the old lighting science found that orange-yellow light is best for humans in a low-light environment.
If you are backing your photos up to iCloud and you're running out of space, of course you will get a notification. Just disable Photos sync to iCloud if you rely on another cloud like Google Photos
I cannot even use Google Photos in the same way that I use iCloud.
With iCloud I can set the system up to only retain low-resolution versions and only fetch high-quality when needed.
I can't do that with Google Photos. ANY app that requires me to open a photo opens up with the standard iOS photo viewer which does not allow anything. I can't even write an integration for iOS photos so I can browse my NAS, or Google Photos or DropBox or whatever.
Finally. I've been so frustrated about the autoplaying previews, especially since I've experienced that after a few seconds, the menu will fade out and Netflix will play the video as if you had clicked "Play". But I haven't clicked "Play", I only happened to rise up from my couch, hear the preview starting, do whatever for 30 seconds and then come back having to stop or restart the episode.
Absolutely terrible. I'm really happy Netflix has given us a way out.
Another bad thing about the fading menu is that it seems to get treated the same as if you affirmatively decided to watch it.
It shows up in "continue watching" and I believe probably stuff like "because you watched A..." (...here are B, C, D, and E).
Which is just silly because even if they want to steer me into watching it because I'm too lazy to tell them to stop, that doesn't mean it makes meaningful data for recommendations. They can tell whether I pushed a button or not, but which seems like a pretty meaningful signal to ignore.
I had my Facebook account linked to my Spotify account. I didn't create an account using Facebook, but linked them later on.
Even when I had a Facebook account linked, I could still login to Spotify using a username (a bunch of numbers) that I was able to dig out from the settings at some point.
I recently deleted my Facebook account, and everything went quite well. The app said my playlists was created by user "null" (they fixed this after a while and now displays the numbers which makes my username), but other than that there's been no changes. So, just deleting your Facebook account and let Spotify deal with it seems to work, but it require you to know the username (and password. I don't know how I got that, maybe it was the same password as the one I used before linking my Facebook account).
Some do, but the way of working can be very deeply rooted. I work with an in-house made DCIM whose primary competition is excel. Switching way of working and also migrating bad quality excel spreadsheets is hard, especially when the spreadsheets have diverged between sites.
I don't see Russia as a threat to the entire Sweden. I do, however, consider Russia a threat to some key locations like Gotland. But as far as threats go, I consider Russia to be Sweden's greatest threat, even if that threat is rather small.
Indeed, the registry is actually a good feature, it's a configuration database rather than relying on flat files as in the "just go to /etc/<package>/<package>.config or /home/<user>/.package/<package>.config" of the linux world.
The problem is that when it was first introduced in windows 95 the registry would easily and often corrupt causing many issues so some people still associate the registry with being a bad design, when it was actually just a bad implementation of a good design.
The windows registry is absolutely terrible at its job. The namespace is polluted from day #1 after installation and this only gets worse as a box gets older. The number of places the same key could appear are baffling and you never really knew when you had exterminated the last instance of HKEYsomethingorother to achieve the desired effect.
Yes, but this is because third-party developers don't know what the hell they're doing in regards to the Registry. The Registry was never supposed to be a persistent storage location for application configuration data. INI files were doing very well when the Registry was created, and Windows still used INI files for most things even as it exposed some things in the registry. The INI API was the official application configuration API. (And today, application manifests are the official configuration API: essentially INIs in XML.)
No, actually, the Registry was supposed to effectively be the place to find and manipulate the same sort of data you'd get from Linux pseudo-filesystems. HKEY_CURRENT_CONFIG is essentially Linux's /sys, for example. HKEY_LOCAL_MACHINE\System\CurrentControlSet is equivalent to Linux's /dev. Etc.
The nice thing is that each Registry hive could be implemented with a different backend, and thus impose its own constraints on the format of the data. HKEY_CLASSES_ROOT, for example, could just be an interface into the shell's filetype database, and require that the data you put in there conform to the columns of that database, and their types.
HKEY_LOCAL_MACHINE\Software, though, was where things went wrong. The HKLM hive, and especially the Software key under it, was essentially a sort of... asynchronous RPC. It was there to allow system daemons to have their configuration changed at runtime, without needing to be restarted. They could just re-read Registry keys directly each time they do something, and so writing to the HKLM keys would change what happens as soon as their next message loop.
But HKLM was also persisted as its own free-floating database file, just because it was much more convenient to write the key once, rather than having to write it once for immediate runtime effect and then another time to an INI file for persistence (like how, say, Linux's sysctl(2) + sysctl.conf(5) work.)
And third-party developers came along and noticed that they could just write whatever they liked into HKLM under some random key (at least during install-time in NT; or all the time in 9x), and then be able to get it back later. So they did. Oops.
Everything since then has been patches to try to fix the problem this caused (because, from Microsoft's perspective, you do still have to keep these programs working, despite their faux pas.) HKEY_CURRENT_USER was created because applications were just writing their config system-globally to HKLM and thus a multiuser system would have each copy of the software retaining its config from other users' sessions. (It was easier to get them to change the target hive, than to get them to rewrite their code to use INI files for config.)
The job of the registry is to be a reliable structured storage with access control and other features. It is not responsible for the things that go into itself.
If you put together a structure like that and leave the sordid details up to the implementer and you supply a mostly confusing example as the set shipped with the OS, and subsequently mess it up even further with your own application installs you own the mess.
An upvote isn't always enough, so I just want to say I support your holistic view of engineering and find the "not a bug, not my problem" approach detrimental to the broader success and acceptance of technology in society.
I'm unable to extract anything specific from your comments. Are you still talking about the registry or about something else? Its cathartic to vent, but the registry is not the source of your frustration.
Okay.. call me small-picture-minded but I much rather prefer - "I press a button M and Feature X doesn't work when I choose option Y" - over "Feature X is terrible at its job"
The problem is not that they don't work as intended, the problem is what is intended. You can't just throw application developers an API like a system wide key value store and expect the whole worlds ecosystem of applications to organize itself around it. Android and iOS solve this much better by sandboxing application settings within the app. Uninstalling the app is guaranteed to remove any traces of it (unless you give access to "all files and photos"), whereas on windows there is always some remains.
Its just a database. Using the registry is not a requirement for any app. They can store their configuration in a text file, they can store it in the cloud, they can do whatever they want, they can even create a C:\etc and store it there :)
Sure, there exist badly behaving apps that don't clean up after themselves when they're uninstalled. Windows gives apps the freedom to choose their own method of installation, but some vendors abuse those freedoms. I don't quite know what the OS is supposed to do about that. Windows already does an insane amount of work trying to keep buggy apps running, something that macOS or iOS or Android or Linux don't. The fundamental goal of any consumer OS should be making sure that the software a user purchased continues to work.
>Android and iOS solve this much better by sandboxing application settings within the app.
So, multiple users on a device = separate settings = multiple app installs? That might work OK for consumer devices, but won't really fly in the IT world.
We live in a world where MongoDB is at the butt-end of all Database and ACID jokes.
But the award should go the Windows Registry, a Key-Value store that combines the drawbacks of a half-assed filesystem with the advantages of piping your database to /dev/null.
A Database would be capable of using an index to traverse all the keys. The Registry does a linear lookup at each pathnode.
I think the macOS User Defaults system is still my favorite config system. Unified api (`defaults` and NSUserDefaults), but stored in user-editable (and easily cleaned up) files with standardized naming and formatting. It's not perfect (kooky and unwieldy XML syntax, no standard equivalent of conf.d), but it solves the pain points I've seen with the Windows Registry (monolithic inscrutable database) and unix commands (random config files each with their own custom place and format)
I think the major problem with the registry - besides being obscure - is that it can grow really slow as it fills up, and many programs do not clean up their registry data when being uninstalled. I think this is one of the major factors why Windows grows so slow after a couple of years on machines where lots of software is being installed and uninstalled.
Granted, but the presence of those files does not slow down the system significantly. With leftover registry keys, you pay the price until you install the system from scratch.
(Windows might have improved the registry handling code since Windows 95/98, I think it's not quite as bad these days... but that might also have to due with computers being much faster than 20 years ago.)
if it's trying to be a database, it's doing a terrible job. all the problems of not being files (can you do "find HKEY_CURRENT_USER -name mypackage" to see what the uninstaller left behind?) with none of the benefits of a database (ACID).
When they were working on Windows 7, Microsoft tried to be more open about the development process in order to repair some of the damage Vista had done. So one day, I came across this video, an interview of a few Windows developers.
At one point, the person doing the interview asks, "So, what do you guys think of the Registry?". Awkward silence, followed by uncomfortable laughter. Finally, one of the programmers says, "I think it's fair to say it was far more [widely used] than any of its designers had anticipated."
(Quoting from memory from a video I saw once, ~10 years ago, so the wording might not be perfectly accurate, but that's how I remember it.)
This is not correct, Windows Registry updates are atomic and transactional. There may be other problems with the registry model, but it is a "real" database.
ACID means more than atomic updates, though. To be ACID-compliant, you'd have to be able to group several changes to the registry and have them take effect either all at once or not at all.
In cases when I need to write several values atomically (e.g. in a program with persistent window positions, after user moved a window I want to write all 4 coordinates of the rectangle), I just keep them in a single value, either string or binary. Even without KTM, registry API already guarantees value writes are atomic.
Weird settings are supposed to be hidden in weird places. There's no reason that a setting like "use broken line endings" should be in a nice easy to find place.
If so, they are widely adopted here in the EU but only for full beams not the regular headlights.