I think this is a very cultural thing. When I interview candidates at my current job, we are interested in hearing about their life outside of work, since we want to know how we can best collaborate
If they have to pick up their kids in the afternoon, then it's probably better that they work closer with the other parents than of they're late risers who prefer coming to the office at 10
The age API is not a prerequisite for adding a location API.
You start with the age verification because "think of the children" is an easy sell, then a year from now, there'll suddenly be a massive worry about criminals using their phones for "crime-stuff", so we need to track where these people are - there's then already a system in-place for easily adding such a functionality
A year after that it'll be online fraud that is apparently rampant
My reason for this conclusion is that there's no good reason that age verification should live at the OS layer. It is technically cleaner and simpler to have it as an external service - just look at the amount of issues it's causing for Linux distributions
FB are not dumb - they know this hurts Linux distributions, but they're an ad business and they need PII to sell those ads
They're pushing for an API at the system level, where they can query the age
Such an API can then be extended to provide location data to "help the police find bad guys", track purchase histories to "prevent fraud"; all the stuff that Apple and Google blocked fb from sniffing from user devices
It's circumvention of these privacy protections with added vengeance since now Google and Apple will be sitting with the cost of implementation and the liability
> if you want strong versioning with source controlled configuration, containers are 1000x easier and give you 95% of the benefit
For some I'm sure that's the case; it wasn't in my case.
I ran docker for several years before. First docker-compose, then docker swarm, finally Nomad.
Getting things running is pretty fast, but handling volumes, backups, upgrades of anything in the stack (OS, scheduler, containers, etc) broke something almost every time - doing an update to a new release of Ubuntu would pretty much always require backing up all the volumes and local state to external media, wiping the disk, installing the new version, and restoring from the backup
That's not to talk about getting things running after an issue. Because a lot of configuration can't be done through docker envs, it has to be done through the service. As a consequence that config is now state
I had an nvme fail on me six months ago. Recovering was as simple as swapping the drive, booting the install media, install the OS, and transfering the most recent backup before rebooting
Took about 1.5 hours and everything was back up and running without any issues
I'm not really sure what your point is, but I'll try to take it in good faith and read it as "why doesn't docker solve the problem for it, since you can also keep those configurations in a git repo?"
If any kind of apt upgrade or similar command is run in a dockerfile, it is no longer reproducible. Because of this it's necessary to keep track of which dockerfiles do that and keep track of when a build was performed; that's more out-of-band logging. With NixOS I will get the exact same system configuration if I build the same commit (barring some very exotic edge cases)
Besides that, docker still needs to run on a system, which must also be maintained, so Docker only partly addresses a subset of the issue
If Docker works for you and you're not facing any issues with such a setup, then that's great. NixOS is the best solution for me
I just realised I didn't answer the first question about what keeps me from discovering the issues earlier
The quick answer is complexity and the amount of energy I have, since I'm mostly working on my homelab after a full work day
Some things also don't run that often or I don't check up on them for some time. Like hardware acceleration for my jellyfin instance stopped working at some point because I was messing around with OpenCL and I messed up something with the Mesa drivers. Didn't discover it until I noticed the fans going ham due to the added workload
I think the sibling answer by oasisaimlessly is really good. I'd supplement it by saying that because you can have the entire configuration in a git repo, you can see what you've changed at what point in time
I'm the beginning I was doing one change, writing that change down in some log, then doing another change (this I'll mess up in about five minutes)
Now I'm creating a new commit, writing a description for it to help myself remember what I'm doing and then changing the Nix code. I can then review everything I've changed on the system by doing a simple diff. If something breaks I can look at my commit history and see every change I've ever made
It does still have some overhead in terms of keeping a clean commut history. I occasionally get distracted by other issues while working and I'll have to split the changes into two different commits, but I can do that after I've checked everything works, so it becomes a step at the end where I can focus fully on it instead of yet another thing I need to keep track of mentally
I can see your point that it can be daunting to have all the pain upfront. When I was using Ubuntu on my servers it was super simple to get things running
The problem was when I had to change some obscure .ini file in /etc for a dependency to something new I was setting up. Three days later I'd realise something unrelated had stopped working and then had to figure out which change in the last many days caused this
For me this is at least 100x more difficult than writing a Nix module, because I'm simply not good at documenting my changes in parallel with making them
For others this might not be a problem, so then an imperative solution might be the best choice
Having used Nix and NixOS for the past 6-7 years, I honestly can't imagine myself using anything than declarative configuration again - but again, it's just a good fit for me and how my mind works
GDPR is not about Cookies, it's about all tracking, including the examples you mention. As far as I understand the GDPR, the things you mention would also require the user to opt-in to be legal
My understanding is it's possible to license either new contributions to a project under GPL, with the original contributions keeping EUPL or you can license a derivative work under GPL, though you still have to comply with the EUPL in regards to the original work (meaning the SaaS loophole will remain closed)
I would extend the term "communication" to also include how we speak and listen to ourselves
I don't think I am able to explain it clearly without writing a very long post. There's a really good book by Marshal Rosenberg, titled non-violent communication, which gives a better explanation than I can right now. I would recommend it to pretty much anyone, if only for the very healthy way of treating oneself that it provides. Mileage may vary, but it fits my mental model pretty well
As an aside, I'm very glad to read through the replies to your post and see all the constructive you've engaged in. I've gotten mare than a few new thoughts and ideas because I chose to get involved in this post - thank you :)
I think we're saying the same thing in two different ways, so I agree with your point. What I'm reading is a good "why" - why wasn't there time to prevent this bug.
Better is a subjective word, so I think I could have made my point more clear by instead writing "99% of bugs are there because there wasn't allocated enough time to prevent them"
Do you agree more with that statement than the one I originally posted? :)
I agree with the difference between programming and software development, though I'm not entirely sure on why you're pointing this difference out. Do you think my answer is not answering the OP's question? :)
Being able to clearly explain why your solution will solve a given problem better than the alternative and listen to your colleagues when their suggestion is better than yours, will save you an incredible amount of frustration. It is in my opinion the most important skill I have learned
- Asking why when debugging
Finding the code that's causing a bug is only the first step. The next is preventing a similar one happening again. By constantly asking "why was this choice made", you end up finding the actual weak points in both the code and your process. Whether it's because a hack some other place forced you to write another hack, that then failed or because there was a deadline so the commit was made at 3am, there is an important lesson to be had. If you combine that with good communication, you can talk to the team about changing things, so you avoid creating similar bugs in the future. (Pro-tip: 99% of bugs are there because there wasn't time to do things better)
If they have to pick up their kids in the afternoon, then it's probably better that they work closer with the other parents than of they're late risers who prefer coming to the office at 10