It really depends but useful knowledege can be derived from this. If user accounts use sequential ids the id 1 is most likely the admin account that is created as first user.
There are some things that simply do not work under Linux because of lack of driver support. An example is fingerprint readers. I agree that most x86 laptops are usable under Linux.
Fingerprint reader works fine on mine. But then I bought Lenovo because they support their hardware including making drivers for their fingerprint readers.
It's a hit and miss unfortunately. On my Lenovo Yoga 920, it doesn't work for example because there is no driver support. Similary on my Acer laptop too.
> On my MacBook M3, Windows doesn't work. Similarly on my Chromebook too.
I mean, if it isn't a supported platform that's hardly the operating systems fault. However there are plenty of systems that do have drivers and are supported.
The original quote was that the best supported is WSL, and that is not true.
Actually since Virtual Box and VMWare got good enough on Windows around 2010, but having one less thing to install, pay license for, is definitely welcoming.
Honestly, I'm inclined to agree with you. When our employer wanted to transition away from Linux desktops (which I'd used for 10 years to that point) to Windows Laptops I pushed back and got a MacBook Pro. I felt like being unix-y made things easier with deep integration of the shell.
However, I recently bought myself a Windows laptop (for games and miscellaneous other things). When I've tried doing a bit of development on it I've been pleasantly surprised. The WSL2 integration works well enough that it actually is probably easier than my development environment on MacOS where I have to worry about lots of subtle differences (and since getting it replaced with an M1 MBP due to the battery expanding - some not so subtle differences).
Time in software is fascinating.
If you say time - everyone thinks he understands it perfectly as we use it in our everyday. But it has so many pitfalls in the details.
1. That is likely to exceed the maximum length allowed for the form fields you have to use to enter it on web pages or in apps.
You might find that on the page where you initially set it up the page silently truncated it to say 1000 bits, and that's what got stored on the server. But the page where you need to use it for password recovery handles 1500 bits, and the form in their app only handles 500.
So you cannot get it to work in the app no matter what, and can only use it on the recovery page if you somehow figure out that only 1000 bits are on the server and truncate to that yourself.
2. Some places use the same security questions when you phone support. The support person asks you one of the security questions and can read the answer from the database. They compare that to what you tell them over the phone.
You probably don't want to go through that with a random 4096 bit string.
Yeah, easy way to own the security conscious is call customer service and "authenticate yourself" by "answering" that you made the security response a bunch of random letters and numbers beacuse you were in a hurry and was confused about the assignment.
If you want the cloud to be a powerful tool you will use their higher level services. These are incompatible and cannot be reasonably abstracted away.
The simple services like files which you could reasonably abstract away in your code you can also migrate when needed.
If you don't want lock in you might be better of with a traditional hosting provider. The cloud is only really useful if you go in with a mindset to embrace what it offers.
Exactly, if the self-driving is good enough after some time you will reduce your attention and will not be able to quickly take over if the car suddenly fails to self-drive in a corner for example.
If you don't see that the feature would fit your vision of the codebase then just tell them that.
If you think it is a useful feature tell him that you currently don't have time to implement it yourself but a PR is welcome.
Often people only want that there issue is tracked, so to avoid conflict and just do nothing just tell them that it goes into the backlog of future features to be considered ;)
Just another point to consider: sometimes reviewing a PR and getting it up to your standards is significantly more work than doing it yourself.
If you don't have time to implement it, there is a chance you don't have time to review it.
If it is like that, you can simply say you don't have the bandwidth to review, and/or you don't want the feature in your repo. You can emphasize that they can always simply fork the project and do whatever they want with it.
