I hear a variation of this type of thing from windows fans constantly. "It's your hardware's fault." But never Window's fault. My experience is this; most of my computers are dual boot with windows and linux. When I have a problem with windows, I'll boot into linux and the problem goes away. Same hardware.
Arch looks like it's got a lot going for it, and I sometimes find myself looking at their documentation when I'm trying to shoehorn a package into ubuntu. Even though I used Gentoo linux for a long time, very similar to Arch in lots of ways, I haven't been able to install and configure Arch successfully on my computers. I'm sure if I spend a lot more time on it, I'll be able to do it, but I just don't have that much time to spare, so I stick to ubuntu and variants. But I really do like what I see on Arch.
I've been using Ubuntu and variants for a long time now. I find lubuntu is ok and small in terms of size. As for older computers, I must have some really slow ass hardware, because even lubuntu is kind of slow on some of my hardware. I stick to standard ubuntu on my desktop just to see what it's like, but prefer xubuntu because I prefer the DE over the gnome crap. I'm used to the more standard keystrokes and shortcuts that you see on windows and the IBM standard which gnome wants to ignore. It's also tough to customize gnome to how I like to do things.
#4 makes me laugh because I had that thought when I was trying to work with bluetooth. I think the real problem is two-fold. The original spec required approval from all members of the consortium. I think a lot of things were left out that are really important, such as security. I know they had security from the start, but really, it's bullshit. Plus the original chipsets were incredibly expensive, and my pure speculative thought is that they cut corners (the firmware part) to bring them out to market. I was really surprised, shouldn't have been with hindsight, to see when bluetooth chipsets started to reach price parity with wifi chipsets.
The second thing is that much of the low level firmware for the stack is closed source stuff that is written in house. I suspect, after working with some of that shit, that it's poorly done and is a major cause of unreliability. Don't know if it would make any difference if it was open sourced, because the hardware/software combo is a lot like what you see with graphics cards. Everyone has their own secret sauce and they don't want to show it to the world.
There are a few other open-source and crowd-source projects like this that I've seen. It's interesting to see so much volunteer response to the crisis.
Interestingly, I had the opposite experience. I've been using Firefox for many years after moving away from Chrome because it was too slow. Nowadays, I've been thinking about moving back to Chrome because I tried a recent version of Chrome, and it ran faster than FF. FF does have some nice features like privacy and some really cool extensions. But it's gotten slower and there are some webpages that don't work for me unless I fire up Chrome. But since I've been using FF for many years, and have all of my favorite extensions and logins saved, it's tough to go back.
Not only that, but uber and lyft copy each other's prices. When one of them lowers the pay to drivers, the other one follows soon. Usually, the pay to drivers is lowered, but the cost to riders doesn't go down as much, and uber/lyft has been taking much more from drivers, especially the 'surge' surcharge. Much less of that goes to the driver than before.
Nice looking. That's what the windows terminal should have been like. I've always thought that they made the windows terminal ugly and hard to use because they wanted to discourage using the command line in favor of the gui.
Great project. I'm amazed at how much you can accomplish with today's tools and services. And using the woodfill PLA is a good way to get around the rough look of 3D printers. Great ideas here.
One of the easier video editing programs that I've tried on linux. There are surprisingly quite a few video editing programs for linux, but for me it was easier to learn and use.
They're calling the MPU: Microprocessor Unit, not a memory protection unit. The Cortex A7 has the MMU. BTW, there are some linux distros that are made to run on processors without mmu's. Look at uClinux and NOMMU Linux.
I use the ppa, but doing that opens you up to security concerns. I've tried to build from source, but there are too many dependencies and I couldn't build it due to conflicting libraries.
There aren't as many jobs in the embedded space as there are for higher level software. Nowadays, lots of new embedded processors are hitting the market and there will probably be a shake-out sooner or later. So the embedded space isn't necessarily more stable than the web based stack. Lots of the processors are getting huge with lots of memory, faster and more capable cpu's; all of which will require programming at a higher level. Arduino's use C++, Raspberry Pi's are usually programmed with Python (although you can use any language that runs on linux), and most embedded processors can be programmed with the C programming language. One niche that you might be interested in is the amount of high level software that's required for today's newer and larger cpus/SOCs that have a lot of connectivity, such as wifi, bluetooth, and software that communicates with TCP/IP. Connectivity is driving a lot of the newer stuff. with that, security is a big deal and might become required knowledge. There are also a lot of experimental attempts at introducing new and higher level languages on embedded systems. Rust, javascript, go-lang, elixir/erlang, are some recent examples. The embedded space is beginning to experience the churn that you're dreading in the high level stack.
Yup, I used this in my computer architectures class a long time ago. Good to see that it's still being updated, especially with the QtSpim version that's cross-platform.