So let me get this straight. You buy Phillips Hue devices because they work offline. Then they change how the devices you bought function making them only work online forcing you to create an account and allow them to collect data.
This should not be legal. This is a breach of contract, they modified the contract after you already signed it (by buying the device). If they want to do this, they should offer full refunds to anyone that wants to exit the contract, or only apply the changed to new devices.
From a career perspective, think of languages and frameworks as tools. Knowing how to work with more tools broadens your horizon about what you can achieve and how efficiently. Sure, you can specialize on certain tools, but these come and go.
You can't push to github without an account. That's how github can validate that you have the rights to push. If that is a problem, host your own gitea instance.
Once you have an account, the way to do it is using ssh keys. Use ssh-keygen (or putty keygen) to generate a key pair, add the public key to your account, and the set up ~/.ssh/config.
Something a lot of open source projects lack are designers and UX experts. Translation is also something a lot of people can help with. Documentation writing too.
For the programming community at large, sharing knowledge is a great thing to do. There are many channels available, blogs, wikis, even videos on YouTube.
But I loved my HTC 10. And let's not forget about LG. Also, Sony, Motorola, Nokia are just a shadow of their former selves.
Today your main choices are Apple, Samsung or a Chinese brand (Oppo, Xiaomi etc). Sure, there are those niche phones like Pixels and Fairphones used mostly by nerds, but they are a tiny market.
Where I live there were a lot of people complaining about order and delivery especially when ordering fruits and vegetables. The delivery people don't care about picking the better ones.
They are ok, but the implementation in some stores is terrible. The one closest to my home has a scale that measures the weight of the products you scan. Almost every time I use it that scale decalibrates itself or doesn't properly detect that I put the product down, and locks itself until a cashier comes and solves the issue. And it locks itself for other reasons too, like if a card payment fails, you can't retry until the cashier comes and unlocks it. The only advantage is the smaller queue.
The issue is that chip sizes are limited (among other things, like the speed of light) by the ability to take away the heat they produce. For example the i9 processor itself is not that big, but needs a massive cooler.
In terms of performance and flexibility, building your own is better. Depends on what you want out of it.
If all you want is an easy to setup NAS with no bells and whistles, get a synology. If you want to build a server that also has a NAS, if you want to be in control of the software, build your own.
You don't even need server hardware. I used an older desktop computer with an HBA card. It's also less noisy and much smaller.
What I think the biggest problem with the traditional package managers is that (1) they don't isolate packages from each other (when you install a program files are placed in many random places, like /usr/bin, /usr/lib etc) and (2) you can't have multiple versions of the same package installed at the same time.
This creates a lot of work for package maintainers who need to constantly keep packages up to date as dependencies are updated.
Also, because of this, every distro is essentially an insane dependency tree where changing even one small core package could break everything.
Because of this, backwards compatibility on Linux is terrible. If you need to run an older application which depends on older packages, your only choice is to download an older distro.
This is what snap and flatpak try to solve. I think they are not great solutions, because they ended up being an extra package manager next to the traditional package managers. Until we see a distro that uses flatpak or something similar exclusively, the problem is not solved.
Depends on what you define as "saying". If saying means communicating, there are alternative forms of communication without involving speaking, like sign language, writing etc. If saying means speaking out loud, then yes.
As a general rule, any code you write on company time and on company resources belongs to the company.
But I think some common sense still applies. If you wrote some autohotkey or shell script that has nothing to do with the projects you worked on and boosts your productivity, sure, it's fine to take it with you. For example, a script that pastes by typing the characters instead by pressing a certain combination of keys. Or a script that mounts the shared files drive in VMware.
But taking code from your company projects is not okay. Maybe you implemented some fancy new middle-out compression algorithm in your company's product, and you would like to take it with you, don't. Maybe that gives your company the competitive edge.
If you decide to build a competing product or work for a competing company, I would recommend being 100% clean. Read your contract carefully, and make sure you are 100% in the clear. Make sure that if your company wants to sue you, they have nothing on you. And maybe consult a lawyer.
Pixels aren't that expensive. And there are very good reasons why GrapheneOS only supports Pixel devices. Pixels are the only devices that have the proper hardware security features.