With Android Oreo, Google is introducing Linux kernel requirements
betanews.com
betanews.com
That all said, it has gotten much more user friendly with e.g. Ubuntu over the past decade or so and hopefully the aforementioned state of affairs begins to change. The language chosen is harsh, but outside of our community, I'd argue that's commonly true without massive training for users.
... and of Linux internal unstructure and how it came to be. As someone who grew up with Windows and only later started to use Linux more and more, I'm still puzzled by the latter whenever something breaks. I'm no longer annoyed the way I used to be, though, because I understood the crucial thing: Linux distros are big hodgepodges of components. A distro is nothing but someone's opinionated vision of what software should be put on top of the kernel, and thus depending of the distro, version and the phase of the moon, you get different combination of stuff. And each piece of software has its own quirks, its own way of management, stores configuration in its own format in its own special place, etc.
I suppose it's fine for an ever-evolving landscape of solutions, but for a casual user, it made it impossible to reconfigure pretty much anything in the system without having Google on-hand (preferably on a secondary machine, in case you break something).
For a casual user it's impossible without google to figure out how to change simple settings like making alt-tab stop being on crack and disappear after 0.5 seconds of indecision. Or figure out why plugging in a headphone requires a confirmation on some machines, but not on others... Etc.
I recently tried to set up Fedora running a VNC or RDP server, and after a couple of days of futzing I gave up. I guess Wayland has managed to regress on that from where X was a decade ago? Systemd also made startup issues impossible to debug, and also apparently f--ked up with how log files are stored? It's a mess.
I used to operate under the assumption that I could sit down and use Linux if I needed to - and I started a job that required just that, and it was fine. I'm increasingly less certain of that, because things seem to change rapidly and it's very hard to find documentation that is clear and up-to-date. It's already hard enough to figure out how to do things like add a shortcut to Ubuntu's app launcher.
It's not harder, it's just different. As a counterpoint, I never figured out how sysvinit works and got by with guesswork and Stack Overflow answers. And I hated how logs were scattered all over the place. Nowadays you have systemctl(1) and journalctl(1) which are exceptionally well-documented in their manpages, and now services and logs work the same all the time across all distros.
(Not going to argue about journald's weird binary log format though. I don't get that. But at least it doesn't get in the way for me.)
Second, systemd troubleshooting and RDP servers are not common uses for Grandma, so even if valid points were made, most users aren't affected.
Something that was working up to a few months ago, the last time I used it.
Also, systemd can cause anyone problems - I'm not sure it can distinguish between you or Grandma.
There are no macOS or Windows subdistros. So, the only difference may be between different versions. Adding to that, Apple generally does not have the tendency to replace/rewrite macOS subsystems every few years, so it is much more likely that thing still work after a couple of years.
That's a pretty naive trust in Microsoft's branding/marketing team. Of course there are heaps of different Windows distributions. They don't necessarily differ as much as, say, Ubuntu vs Gentoo, but they do differ.
A random non-expert user would simply not be able to enable scaling properly (and stare at miniature windows).
Yes, I know KDE is better and GNOME is working on this. The fact is that hardware that has been around for years does not work out of the box or even with a 'blah fedora'.
As to your other point—grandma has an iPad. To the extent Linux has relevance in the desktop, it’s for CS students, people setting up a lab of workstations, etc. Simple stuff like setting up a Remote Desktop is squarely within that use-case.
According the Wayland FAQ [1] they have specifically avoided defining a remote API.
[Q]: Is Wayland network transparent / does it support remote rendering?
[A]: No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.
Which leaves you using Spice, or older solutions like X+VNC. Check out Apache's incubator project Guacamole [2] if you'd like a solution that can stream a Linux or Windows desktop to a browser via HTML 5; it supports SSH, Telnet, RDP and VNC. And despite supporting those older protocols it integrates with LDAP or CAS [3] for external authentication along with DUO for two-factor authentication.
[1] https://wayland.freedesktop.org/faq.html#heading_toc_j_8
[2] https://guacamole.incubator.apache.org/
[3] https://en.wikipedia.org/wiki/Central_Authentication_Service
N.B.: I added the Q and A tags to the Wayland FAQ quotes for clarification which is why they're highlight differently from the copied text.
I scanned the Kernel section of the AOSP documentation and it appears to be a far more comprehensive summary of the new requirements, as well as some nice background information (such as the kernel development process).
The overview to that section is here: https://source.android.com/devices/architecture/kernel/
Anyone concerned with ease of use wouldn't be doing this in the first place - and at the same time, people can Ubuntu and get a full environment for internet, media, etc. pretty much out of the box, with most other 'incompatibility' issues having to do with poor vendor support and having nothing to do with the system itself being hard to use..
I'm in agreement with the parent here - just because being a F1 car mechanic is difficult doesn't mean changing the oil in a Honda requires an expert and is difficult.. different actual tasks being performed...
OTOH for a lot of users even Windows is "horrendously difficult to use".
Device tree is mandatory and vendors are encouraged to upstream the code. It sounds like Google has an eventual goal of building a single kernel that can boot on most devices which is a great thing for everyone.
To me it seems like a chicken-egg problem: silicon designers have no incentive to standardize the way SOCs work because there will be no benefit to the software ATM.
I'm curious if forcing the egg, common kernels, will have silicon designers rethink their engineering efforts in order to save time on software.
An example that comes to mind was a video chip that also had a GPIO pin that we needed to control. The chip had a driver in the kernel but it didn't have support for the GPIO (it is after all a very secondary function). That required a small patch.
It would of course have been possible to upstream it but then that meant implementing a "clean" patch (using the kernel GPIO API etc... instead of a one liner to toggle the PIN high on dereset) then submitting it upstream, maybe doing a couple of back and forth... Some will bother to do it, many won't.
[1] https://github.com/UDOOboard/linux_kernel/commit/b2fc4a3cba4...
It also means that you'd have to wait for the kernel to be released and then google to pick it up before you can use an "official" kernel for your device. In the meantime you'll have to ship your own customized version. I'm not really sure how that's going to work.
That seems to be also a goal of postmarketOS, which was discussed here recently.
The situation is the same for all embedded Linux devices. All have non-mainlined (and non-sidelined) changes to device tree, startup code, pin muxing code, special kernel parameters, special drivers, specially adjusted drivers, special vendor drivers that are C wrappers around binary blobs etc..
Out-of-tree maintenance is possible, but this still often needs to build against the kernel sources, not some more generic kernel library (or ABI, if you want). Other embedded platforms are worse (eCos), some are better (QNX, MQX) in separating device driver code into units that do not depend on the whole world.
Kernel maintainers are very vocal in saying "it's not me, it's you" and laughing in your face, but if every vendor has the same issues with managing in a sane way customization of your operating system since a decade and a half, it becomes a bit of a running joke.
Except every vendor doesn't. By some magic voodoo witchcraft, x86 remains consistently capable of producing a single kernel that can run on anything from Intel or AMD.
Because they upstream their platform support.
That is literally it. No, it is not a technical impossibility of the ARM world to support common hardware abstractions like IBM-PC platforms. They choose not to.
It's a bit easier to upstream when the gatekeeper sits on the next chair and is paid out of the same pocket as you are.
The "magic voodoo witchcraft" is Microsoft's "Hardware Compatibility Specifications for Windows".
https://docs.microsoft.com/en-us/windows-hardware/design/com...
Linux and the other free OSes run on commodity x86 hardware by targeting the same Microsoft-issued specification. There is no standards body or other neutral organization that defines what an x86 PC is.
It went the other direction: anything new from Intel or AMD had to run the same proprietary, binary-only kernels and applications (since MS-DOS was more of a loader, applications could and did access the hardware directly).
Later, Microsoft started specifying exactly what would be required so that their proprietary, binary-only kernel would run (https://en.wikipedia.org/wiki/PC_System_Design_Guide). It was not the vendors upstreaming their platform support; it was Microsoft dictating what the platform support would be. Even today, Linux's ACPI support mimics Windows', since that's what vendors test against.
ARM systems never had a dominant vendor which could dictate its terms, and new systems were not expected to be backwards-compatible with older kernels.
As for Fuchsia, it seems to be coming along quite nicely. Here's a short demo of the GUI that was uploaded to YouTube:
As for the UI, their new compositor requires a GPU with Vulkan support to make it run. Unfortunately QEMU doesn't support Vulkan at the moment, so I wasn't able to test it.
And given that Android 7 (where Vulkan is anyway optional), is about 13%, I wonder what the target users would be, if this ever gets out of the lab.
Yeah, no, I'm glad they're doing this.
On the other hand, it's possible to upstream the changes, but if you're dealing with anything like Qualcomm's 1.7 million line kernel fork[0] it's exceedingly unlikely if you're not the SoC manufacturer. And if you're not able to upstream them, you're stuck backporting security patches til the end of time/you throw the device out.
[0] https://events.linuxfoundation.org/sites/events/files/slides...