The question is not about booting, it's about which OS is running the environment where development happens (writing code, compiling code, testing code, etc).
> Clarification: the operating system where e.g. your IDE runs on
If you're developing on a Linux VM that you connect to via a browser tab opened from your Windows laptop, you're developing on Linux for all intents and purposes.
That is, Windows was not doing enough for you so you switched to Linux for dev tasks.
By the same token, if your IDE is running in WSL, for all intents and purposes you're developing on Linux. A virtual machine, sure, but the virtualized OS is a Linux variant. Because installing the IDE on Windows itself was not doing enough for you.
I wouldn't consider Chrome the "operating system" that I am primarily developing on, even though it is really the VM under the hood. Windows is really the one facilitating running the Chrome application, or the Linux WSL application.
To be way too pedantic, if WSL2 (and therefore Hyper-V) is enabled then Windows actually boots into bare-metal Hyper-V first, which then launches the Windows kernel as a VM under itself, side-by-side with the WSL2 VMs if any are installed, so if the lowest level facilitator is what counts then you're really developing "on Hyper-V". I don't think that's a very useful distinction though.
I mean, that's a debatable definition, one could agree or not.
I program on Windows + WSL 2 e.g. and I have no idea how to develop on windows and barely used powershell in my life, but I know the ins and outs of Linux.
I'm not saying you're wrong and I'm right, I'm merely stating that we have different definitions and AFAICT there's no ISO standard saying what qualifies as developing on Linux and what not.
I guess it depends on what you do. I do python, rust, and web frontend in Windows. I have a personal bias against Docker, which'd otherwise be the primary WSL draw for me since if I want/need Linux, I can SSH into the majority of the machines in my house.
I'll throw out my unpopular opinion/experience here, too: I haven't liked any "desktop experience" I've seen or used for a Linux distro, and they all look and feel very similar to me: foreign, basic, and difficult for me to tweak and produce with. I greatly dislike the React stuff both on the web and in Windows, and use Classic Shell, which I'm satisfied with. Windows is easy to customize and almost everything can be tailored without even needing a reboot, many even with registry options already made and just waiting for a bit to be flipped.
It helps my puny, smooth brain, too, to just think of Windows being graphical and Linux being text-based; helps me remember what I'm doing.
Also my western Google pixel pro 9XL does not support it..while the Japanese version does. I guess google might be saving on the licensing or something.
Its also kind of bad form to scrape a huge website when there's a downloadable dump available. Save yourself, and more importantly wikimedia, a whole lot of bandwidth & CPU cycles.
You are correct. The core is Apache-2 and only lacks very obvious enterprise features. All the important CI bits are included in the Community Edition.
There is an EE edition in the works that will have a commercial license with more enterprise features like SSO, Okta integration, etc . I don't have the exact details but the license will allow small companies to use EE for free. The next step is to release EE.
It can be depending on the context (cultural genocide, for instance, often involves mass rape of native populations), but it isn't in this context - it's just mass slaughter.
...you just need to map keys. It was very easy, so now fn-arrow and fn-return work as a mouse on anything I've attached it to so far. I got an rpi recently, only connected this, and was able to navigate the startup ui with no mouse.
I think the biggest disadvantage to "do it in firmware" is it requires an external keyboard. (& the good ones which let your thumbs use more than one key are more expensive or diy).
Using the keyboard to drive the mouse isn't a nice experience. -- But, it's nice to have in situations like "I use a bluetooth mouse, on desktop, and bluetooth isn't set up/working". I've found that useful for live ISOs.
