Pop!_OS branch issue journal

[RedBearAK]

I was not able to get a screenshot because the screenshot tool seemed to make my whole system go black and become unresponsive, but:

At the prompt for the ssh port, I saw no default value enclosed in square brackets (only "Default is 22" in rounded brackets/parentheses), so I figured why not just type "22" to be sure... and then it got stuck in a loop asking for me to confirm I wanted port 22. Enter key would not proceed with the default "yes" highlighted in the square brackets, typing "y" or "Y" wouldn't work, and typing "n" also wouldn't do anything.

So, at that point even if my system hadn't gone unresponsive, I would have had to hit Ctrl+C or something to end the script and start over. Which I will do now because it was in a VM with a snapshot taken immediately after the first big update.

[rbreaves]

Yea, I fixed that pretty quickly - definitely in flux earlier and even now. That issue is definitely gone, you may need to do git reset --hard HEAD~1 && git pull regularly if you are testing while I am committing on a branch that is under going active changes. To minimize commits I often do ammends - which can break branches for anyone that downloaded an earlier commit that has been wiped out unless they reset the last commit.

Also openssh install script was a base template to help me redo all other individual scripts with more functions broken out for more rapid development and I got part of the order wrong which is why you ended up in the loop. I was fixing the order right when you tried it and I made the break worse initially because I had relocated one variable too many lol - the variable that stops the potential for a loop. Not a serious problem, just dev stuff.

Right now the only issue that seems to remain is getting the xfce4-panel settings fully ported over. The job was only partially done last night it seems. I will hopefully have this done in the next hour. Will likely make an official v0.9 release with a warning that no uninstaller has yet been created so at the risk of borking or being unable to remove the changes, for most users.

v1.0 ought to be better tested and include an uninstaller that removes all applied changes, as well as a better summary of all successes or failures at the very end and more minimized output to the terminal during the install.

[rbreaves]

Only issue I am really seeing right now is that installing snapd takes a really long time for some reason.. I will need to figure out the proper way of handling it. I need to get this to not happen or timeout sooner.

Snapd installed successfully, now continuing...
Waiting for server to restart                                                               -^C^Ccannot communicate with server: Post http://localhost/v2/changes/2: EOF
2021-06-04T20:29:55-05:00 INFO Waiting for automatic snapd restart...

[RedBearAK]

Just an observation, I see you're still installing Nemo and Nemo-preview, but systems like stock Ubuntu and Pop!_OS (and Fedora) already have Nautilus, and gnome-sushi can be installed on every GNOME-based distro I've looked at recently, and that at least has the ability to move between files while previewing, unlike Nemo-preview (unless that's been fixed recently). Nemo and Nautilus still suffer from the problem that they both want to call themselves "Files" which produces user confusion when both are installed on the same system.

So unless there is some specific reason why you feel Nemo is really better than Nautilus, I kind of feel like that install should be disabled for systems that already have Nautilus as the default. Just install gnome-sushi to activate the preview feature in Nautilus.

I liked Nemo in Cinnamon but I've used Nautilus in Ubuntu, Fedora and Pop for weeks now and don't feel like there's really anything missing. Frankly I feel like they are almost identical, due to convergent evolution. But maybe I'm not using some features of Nemo that you are taking advantage of.

[RedBearAK]

Not sure what this is about but after exiting from the zsh prompt to allow the script to continue (there are no instructions that help the user understand they need to do that, by the way) I'm getting e x t r a s p a c e s between all characters in the terminal, and the effect also happens in a new terminal window.

Will see after everything is done whether it goes away...

... Yeah, looks like it goes away after closing the terminal and opening a new one after the script is completely finished. Was pretty weird though.

[rbreaves]

extra spaces is usually the result of not having a monospaced font in place - having said that I have not been having that issue any but I am testing on Pop!_OS 20.04 atm not 21.04 so I need to do that as well. Ought to be pretty minor to fix, even though I am not seeing that issue. If my Deja Vu Powerline font did not install correctly then weird spacing in the terminal is often the result.

Also there just isn't a good way to direct users to know what to do other than have them read the prompts just before it happens - because that is just the nature of dealing with the automated setup of zsh atm. The install of it lands users in the shell right away and if they don't read that they need to exit the zsh shell for the install to continue.. not sure what I can do. Maybe dig more into the zsh setup to avoid the shell kicking into gear - but I can't complete the zsh setup that way I don't think. Users also need to log off and back on a lot of the time to see the zsh default happening.

My biggest issue atm is apparently with xfce4.. despite having backed up all the settings it is not liking what I am giving it. I will have to manually remove the default settings it looks like and then recreate each setting 1 by 1 by hand to get things to take because the "simple" import of the settings do not work or if it ever did then it is certainly broken now. xfconf-query will be the only way to rebuild it.

[rbreaves]

A quick preview and new logo for Kairos, or half of the logo any ways lol, once this v0.9 update is done the renaming of the project will happen as well.

[RedBearAK]

I've done quite a bit more experimenting with themes and icons in the last few weeks and I think you should really look hard at this combination. Try it out for a while and I think you'll see what I mean.

Applications:      WhiteSur-dark-solid (or the light-solid variant)
Cursors:           Yaru
Icons:             Yaru
Shell:             WhiteSur-dark-solid (or the light-solid variant)  
Sound:             Yaru

I ended up trying the WhiteSur themes again (apps and shell) and once I realized there was a solid version everything worked out great, whereas the transparent version was a bad experience on my system. I am preferring WhiteSur quite a bit over the Mojave theme. It feels smoother and more refined. And the recent Firefox 89 update has really blended in nicely with it, if you let Firefox take on the system theme.

I tried many icon sets and there were only a couple that retained good icons in the file manager in the small list view that I prefer. Os-Catalina and Ubuntu's Yaru, and Os-Catalina had some issues like a clipboard icon that looks like a fat candle. So for now Yaru is what I've settled on for icons. The interesting thing is that both the Yaru icon and Yaru sound themes are available as packages to be installed via system repos on both Pop!_OS and Fedora. Possibly other distros. So they are very easy to add. You don't have to go searching for them.

Sound themes are very subjective, but Ubuntu's Yaru sounds seem both more informative (easier to tell different alert sounds apart) and less annoying than what comes with Pop!_OS and Fedora.

The cursor theme is unimportant, defaults are usually fine. I've tried some cursor themes that were supposedly Mac-like but they were terrible. Most distros seem to just stick with what is basically the Adwaita cursor theme even if they rename it.

[rbreaves]

Initially I will probably just get it out the door with Mojave - it is pretty solid, but I like that you mentioned a good sound theme for me to try, if not now then later. I can easily prompt users to let them know of other themes available and to give them the option to install all of them if they want and then decide or cycle through the options.

Part of the slowness with this project was setting up the ground work so that nesting hell of if statements wouldn't be all over the place. I am resharing functions a lot more with this setup. And obviously people can create easy to understand yaml template files. I will be updating the readme pointing people to templates to help get them started in porting this work to other distros.

Bash may not be the preferred language of some - but considering most interactions with the OS happen via the terminal I feel like using ruby or python would just introduce a layer that does not need to be part of this specific project. One thing for Kinto and others, but this is purely about getting distros set right more or less & consistently imo.

[RedBearAK]

This is a bit odd, I'm fairly certain on the install of Pop!_OS 21.04 I did on a MacBook the Ubuntu AppIndicators extension was enabled by default, but here in the VM it's disabled. And so is the User Themes extension, which I don't recall being installed by default on the other Pop!_OS install. The fact that it's disabled makes me wonder how the theme is even working. Oh, wait, maybe that only applies to shell themes. I'm still learning to understand GNOME better.

I see you're going with installing Plank. Which I am also using Plank on Ubuntu (with the Dash to Plank extension for further integration) because I didn't really like the behavior options for Dash to Dock. But I've had others say they prefer Dash to Dock because the workspace isolation doesn't work properly on Plank (I have verified this). Also Plank, like Kinto, is still only compatible with X11. A lot of Fedora users especially really like their Wayland now, despite the remaining bugs.

Anywho, I am not seeing the fabled xfce4-panel with global menu, either before or after a restart, but I'm going to assume that's probably because I didn't pull down your latest efforts with git. I think I will wait for the more official release candidate and try again later.

[rbreaves]

Sounds good - and yea things are still a bit more in flux than what even I realized, but I am thinking the nightmare of slowly stepping through settings in xfce4 might not be what I thought. Instead users may have to be prompted to logoff or reboot to see all the changes take effect is what I am thinking. Restarting the panel is not enough, but starting a new session seems to help.

Also I did leave out a very important xfce4 setup file.. so yea it was definitely not working a moment ago lol and even know I am noticing I forgot a whisker config file so about to add that as well.

[RedBearAK]

I think, yes, you definitely need to grab the 21.04 beta of Pop!_OS because they are doing a number of different things that will probably interfere a bit with what you're trying to do. Their new "dock" for instance. After my restart it was overlaying the Plank dock and I had to move it to the side. Dealing with it, and the new launcher/switcher will be different from the earlier Pop!_OS releases.

[rbreaves]

And yea.. I really should see what this new dock stuff is about.. maybe it is good enough to use.. but I really do like my Plank 😂. Adding dash to dock though I don't think will be an issue.. already installing 2 extensions via cli right now and have configured them quite easily.

[RedBearAK]

Their new dock unfortunately has shortcomings that I and others are trying to get them to fix before the final release. Namely that they use an "intelligent" hiding mode but call it "automatic", when they should have "automatic", "intelligent, dodge active window" and "intelligent, dodge all windows" as options, just like all the other kinds of panels and docks that have hiding options.

I have tried to make this as clear as I can in their beta GitHub issues forum. We'll see what comes of that within the next few weeks. The final release is supposed to be this month. I doubt they will really tackle it before the next release, if at all.

So Plank is still a worthy option as a replacement, as far as I'm concerned. Just be aware the existing setup may need to be worked around a bit. Might be good to at least look at a way to add the special launcher icons you'll find on their dock to Plank, if that's possible. There's one icon each for Applications, Workspaces and the new Launcher.

Dinner time.

[rbreaves]

Yea lol.. I need to eat something too and it looks like I just got one of my test runs looking exactly like my original build, but I've not yet gone through my own installer without any issue.. so rinse and repeat lol. Once 20.04 is solidified I will then look at 21.04 and see what happens. Only after I get the current build working in both will I then start to look into offering Dash to Dock as an option.. not sure if that will be before or after the v0.9 release though. Just depends on how much I like it I guess lol.

[rbreaves]

IPv6 was the cause of much of my slowness earlier.. I have now disabled that temporarily during the setup.. things ought to go a bit faster now. Although behind a NAT config probably not. Behind a bridged network interface in a VM though.. IPv6 was killing me.

[rbreaves]

I think I found the issue.. or at least an alternative to get me where I need to get things. I need to set the xfce4 settings on the system level - not the user. I can do the user but that requires a log off and back on because a bug in the xfce4-panel refuses to pick up the user settings on an initial install. It will if they log off and back on..

So I am not writing to the system defaults so there ought to be little chance of it not pulling in my defaults. Granted I will need to keep track of the original settings and restore them if a user want to delete my changes. Also temporarily I've disabled some packages while I work through this - no reason to install ALL packages just to test this last bit. I will re-enable everything once I feel I have xfce4-panel working fully.

[rbreaves]

I am 99% sure that you can now install the Pop!_OS branch on 20.04. No idea fro 21.04.. downloading it now. @RedBearAK

I assume 21.04 will go fine with minor changes if any and will merge into master once it works - the other features of using dash to dock, etc will be a follow up update I am pretty sure as well as additional themes. Honestly I probably need to prioritize all the bits of logic to run uninstall procedures per each script before moving on with adding more features.

[rbreaves]

I pretty well have 21.04 done now. Turned off a few packages for faster iterations, but about to undo that and update the readme - turn on the domain and forward it to the repo. I will also work on getting a site online this time and let that be the landing page.

Not sure when I will do a v1.0 release with the full uninstaller and other features, but overall I think this will be a good start. Ubuntu Budgie has such a small user base, it is great still, but I think for what I am going after as far as making the type of OS and user base happy that I would like to entice into using Kinto this is probably the best OS to target. I can even see myself owning a Pop!_OS laptop at some point.

[RedBearAK]

I see the renaming happened already. Interesting.

You know what just occurred to me, reading the main page about how you want to make sure you have a consistent theming experience. The one thing that the entire desktop Linux world desperately needs for consistency is some way to unify KDE and GNOME theming better on the same system.

I tried to follow some instructions I found for changing the theme of KDE apps that are running on a GNOME system. It failed. I just wanted apps like digiKam to look a little more like they actually belong on a GNOME desktop. Installing some GNOME apps in KDE Neon wasn't that bad, but running KDE apps on a nicely themed GNOME desktop is a very poor experience.

I keep thinking that surely there is some way to install special "system" KDE themes that these apps would before forced to take on without needing to install the entire KDE settings infrastructure. Wonder if you could look into that while you're working on having consistent KDE theming.

[rbreaves]

@RedBearAK Tbh I am not looking forward to bringing consistency to KDE 😂.. I am sure I won't be able to avoid it forever though. I've just failed so many times in the past to make KDE themes consistent with every other type of app as well. It might require updating or creating entirely new themes for all I know and there are some very intricate build systems out there that I don't even have any real experience with as of yet that do aid in that.

I don't know, even with Pop!_OS I had to play with it for a bit to get QT and GTK apps to look similar with the Mojave theme and what I did may very well break under other themes as it is set to the user profile globablly not the theme(s). (~/.config/gtk-3.0/gtk.css I think)

Well it is released now, so I am closing this issue ticket. Will likely reference it for ideas later but am taking a break now lol.

[rbreaves]

Also I am aware that I have not updated the Budgie template to apply the right wallpaper yet.. guess I should do that lol.

[RedBearAK]

Not sure how much of a fan I am of shoehorning the xfce4-panel into other desktop environments. I had actually found a lot of nice extensions and utilities that I can run in the GNOME top bar.

And due to the problem with auto-hiding panels and docks in GNOME Boxes VMs, I just tried to hide the top Xfce panel and it won't come back, which is strange because I used the "Intelligent" option and closed all windows. So there's no easy way that I know of to get it back.

I'm also still not entirely clear on exactly what you're aiming for in the end with Kairos/SoRun. Other than trying to make a Mac-like desktop with a global menu and a dock wherever you go? Plus the basic dev tools. Or are you just going to let it evolve into whatever is most requested?

[rbreaves]

@RedBearAK Well it is my preference atm to have a design language that I like - but it can certainly evolve with multiple configs for the same distros to include more preferences than my own. If it is solid looking and consistent across distros then that is all I care about concerning this project.

I do limit myself to one UX and design language though as much as I can.

The reasoning for xfce4-panel in Gnome is that I do not trust that projects like Fildem will stick around when you have Gnome devs actively working against you and breaking APIs required for global menus. Xfce4 has no interest in working against authors like Vala-appmenu so I stick with that because it is safe and reliable.

The lack of not being able to get your xfce4-panel back is likely due to that the entire xfce4 shell is not running it and it probably won't ever - I think that would cause problems. Would rather stick to just the panel and hiding something that hosts the global menu probably makes little sense any ways.

[rbreaves]

Also I obviously don't do this on Budgie or any DE that better supports global menus. This is what I think is the best solution for Gnome - they can do whatever they like - it won't break me and my configuration while running on them.

[RedBearAK]

Would rather stick to just the panel and hiding something that hosts the global menu probably makes little sense any ways.

Hiding the menu bar in macOS has been what I've been doing since at least El Capitan, several years ago, when Apple finally gave us a setting to allow that without some janky 3rd party system extension. It's a way to reclaim a bit of vertical screen space on widescreen displays, and just have fewer distractions onscreen. The problem is even worse on 1080p displays that already lose 120 pixels from my 17-inch MacBook Pro with its 16:10, 1920x1200 screen.

I still have all the menus and indicator icons and clock all right where I need them, when I need them. It's just out of the way most of the time when I don't.

The fact that a DE like Pop!_OS defaults to placing an always-visible dock three times the height of the top bar on a widescreen display drives me nuts. At least Ubuntu defaults to putting their "dock" on the left side.

The lack of not being able to get your xfce4-panel back is likely due to that the entire xfce4 shell is not running it and it probably won't ever - I think that would cause problems.

Yes, and on real hardware this won't be an issue. It's only in Boxes where this kind of thing remains a problem. Somehow the software never gets the signal that the mouse has hit the edge of the screen. Or the cursor stops right at the edge and the software needs to encounter a "pressure" condition where the mouse cursor is at the edge but still trying to push past it, and that apparently can't happen in a Boxes VM. It's very irritating, because it means I literally can't autohide any dock or other panels in a VM unless I have a way to call it back with a keyboard shortcut.

Anyway, I'm sure you've noticed the nice launcher/switcher in the new Pop!_OS. It is the default for the Super key action, so most new Pop!_OS users will probably expect the Super key function to be converted to activating the launcher rather than the overview when it is changed to Cmd+Space. But right now you appear to be still hard-setting Cmd+Space to open the overview. Just something to think about.

The reasoning for xfce4-panel in Gnome is that I do not trust that projects like Fildem will stick around when you have Gnome devs actively working against you and breaking APIs required for global menus. Xfce4 has no interest in working against authors like Vala-appmenu so I stick with that because it is safe and reliable.

I will acknowledge that is a logical reason to go that direction. But if I attempted to use this Sorun setup long term I'd have to find replacements for all the tools I've got currently in my Ubuntu 21.04 top bar, which I was able to easily replicate in Fedora with GNOME 40 and in Pop!_OS. It'll take a while before I know how I'll feel about that.

When there is an option to bypass the xfce4-panel install I'll probably take that path, but only time will tell.

[RedBearAK]

FYI: Was able to retrieve the panel by just killing the process and restarting it. That probably wouldn't have worked if I'd used the "automatic" hiding option. It would just keep hiding itself whenever it restarted.

Anyway, only a problem in VMs.

[rbreaves]

@RedBearAK You do mention valid points as well - I had no idea that apple would let you autohide the global menu, unless you were zoomed into an app fullscreen.. So it'd make sense you'd like to retain that. Fildem can certainly become an option and I guess would resolve that issue for you and others - at least temporarily depending on whether it sticks around or not.

Last time I tried to install Fildem I never got it to work - despite people telling me it works for them lol.

[rbreaves]

The typical command for resetting or recopying the default panel settings for xfce4-panel would fix that issue for you as well. I literally replace the defaults of xfce4-panel with my own, so it does not have its original defaults at all. Only way to get it to setup right without asking users to log off and back in and I still do.. but only for the workspace plugin, zsh and nothing else lol.

[RedBearAK]

There is certainly a process to getting Fildem to work. I had to push myself to follow the full instructions for installing the necessary packages and whatever, I even forget what all was involved. But there's a page that explains it. It still has the weirdest misalignment issue with the actual menus that I've been meaning to offer to help the dev track down and eliminate, but for the most part it works fine. And it has that menu HUD, like Unity, if that was something you were interested in. I thought I saw you talking with someone about that on a Budgie forum or something. I don't use anything complex enough like Kdenlive where I would get a lot of benefit from a menu HUD, so I kind of wish there was an easy way to disable it in the preferences.

Yeah, it only took Apple about 30 years to finally let us autohide the menu bar. I actually had some solutions for that between 2002 and whenever El Cap came out, but they were just not reliable. The really nice thing is that Apple seemed to have thought about the tuning when they implemented it, so it doesn't pop up too quickly (HERE I AM!!!) if you accidentally bump the top of the screen. There's a short delay. A lot of autohiding panels in Linux are very bad about popping up instantly and then refusing to hide again unless you move the mouse over the bar and back off, but I've never had that problem in macOS. It always hides when it's supposed to, and doesn't usually come out and get in the way when you don't necessarily want it. That's what I'm always looking for in these Linux DEs. And the "Hide Top Bar" extension fortunately has adequate tuning options to make that happen.

So I've been pretty darn comfortable in Ubuntu and Fedora for the past few weeks.

But of course without Kinto's remapping, this would all just be eye candy.

[rbreaves]

But of course without Kinto's remapping, this would all just be eye candy.

Right 😂.. I already got one guy saying a screenshot of Sorun.me was just more Apple eye candy lol. I was like dude - I have all of the right keymaps and it pretty well functions the way I want so what more would a person actually want? I mean unless you are working on the Darwin version of Wine it doesn't get much better and I don't really care to run native macOS programs inside linux any ways.

I like the UX language and key binds.

[RedBearAK]

Yeah, hard to show key bindings in a screenshot.

What you need are more videos/screencasts, with a visible keyboard shortcut overlay, to help demo to potential users what you're actually trying to accomplish (and who you're trying to appeal to). With the Mac styling and Mac keybindings, are you only trying to appeal to Mac users who might want to try Linux or, like you, have to move between macOS and Linux?

Try to contrast between an existing DE and dev environment to explain what was missing that Sorun.me adds or fixes for the user.

Look at the conversation we just had earlier. I've been working with you for a while and although I love the general idea of a "consistent" Linux desktop that doesn't start out looking like trash, even I was still just not quite sure who you're directly aiming this at. There are a lot of Linux users who will never like either the Mac keyboard mapping or the Mac aesthetic.

You just need to decide how to tighten up the messaging around the project, and who you really want to be serving with this.

But I'm sure it will fall into place in time.

[rbreaves]

@RedBearAK In my mind I am appealing mostly to mac professional users, as in developers, creatives, the creators essentially. While I appreciate aesthetics of macOS I feel like without the ergonomics of the keybinds the aesthetics mean a lot less. It's not the reason why I use one OS over the other, versatility of the macOS platform was the main reason why I had made it my primary OS for as long as I have.

Also just the fact that a person can build or rebuild out their current configuration within minutes by using a bash script/template layout like this ought to be a big help to those that want to take the hassle out of resetting themselves up on any OS. I think there are definitely good design decisions that I made - although I need to go back and re-apply all of it to every script under the scripts folder so they follow the openssh-config.sh script.

The versatility of macOS diminishes as they move to another architecture, although it appears to virtualize Windows and Linux quite well still. Ultimately I dislike their direction as it further isolates their users and integrates the hardware to a level I don't appreciate. I'd rather use hardware and OS's that are more flexible and just start accessing macOS remotely if and when I need it. I have less interest in their laptop, and desktop hardware than I have ever had in the past despite the notable performance gains of their M1 ARM architecture.

I don't really want this project to be looked at as cloning the mac aesthetic - but I don't mind having configs that allow for those type of themes, it is Linux after all. As long as a theme has a clean, and consistent look across GTK, QT and KDE apps or whatever then I think it ought to be acceptable. More work will need to be done to further modularize some of this work though and and present options for modifying a config file just before running it in the terminal as well. Maybe just have a mode that asks if you want to run each individual script before running it, something as simple as that would allow users to pick and choose - although there probably needs to be a concept of dependencies within a script to avoid a broken looking install.

I guess if I offer an option to ask before each component then I could also require that configs designate themselves as optional or required - that'd be simpler than a dependency situation. Some options are clearly optional - so just leave it at that and keep it simple. This does not need to become another package manager in bash form 😂.

[RedBearAK]

In my mind I am appealing mostly to mac professional users, as in developers, creatives, the creators essentially.

Might be best to just focus on that specifically for a while, then expand it to other types of users later.

The versatility of macOS diminishes as they move to another architecture, although it appears to virtualize Windows and Linux quite well still.

I totally understand that point of view. But I think we both might be surprised what may happen in both Windows and Linux areas with the advent of the more advanced ARMv9 architecture. We may be about to see an explosion of ARM hardware that runs Linux and Windows just as well as x86 machines, or better for certain use cases like laptops and mini desktops. The different architectures may soon be blended to the point that nobody really cares anymore whether they are on x86 or ARM, and all the software will just have to keep up and be available for both. Even Apple is going to keep their Intel version of macOS alive for several more years. They're still expected to be coming out with at least one new Intel Mac Pro iteration this year or next year.

Unfortunately, I haven't seen any other themes that I would consider both clean and consistent without any kind of "weird" or ugly parts, other than the better Mac-like themes. I tried not to just flat-out imitate macOS every time I jumped on a new distro. but that was always pretty much where I ended up after looking at the alternatives. As long as it looks as good as Mojave or WhiteSur, I don't think most people will mind. But you will certainly get those people who will just claim it's like macOS until there is an alternative theming available. Just don't know what the heck that would be.

All of the highest rated themes on gnome-look.org are either Mac-like themes or colorful artsy-fartsy stuff that would polarize new Linux users between love it/hate it. That's not the kind of thing most professionals would want to use.

I think to really get people to gravitate to this project you'll have to finish more of the configurability options and show how powerful it can be for creating a usable base of applications and settings.

[rbreaves]

We may be about to see an explosion of ARM hardware that runs Linux and Windows just as well as x86 machines, or better for certain use cases like laptops and mini desktops. The different architectures may soon be blended to the point that nobody really cares anymore whether they are on x86 or ARM, and all the software will just have to keep up and be available for both.

I see some of that, but I am concerned with the proprietary bits being brought into it - particularly on the neural node, AI, side of it, whatever it is that they are calling it - it seems like Apple is building in very closed off hardware designs which makes sense but this transition away from Intel in some ways is going to result in more fragmentation than what we have seen previously. We'll see more things getting rendered and processed in ways that no OS may be able to because they literally don't have access to the same hardware or documentation thereof. Linux right now is gaining support for M1 hardware but not due to any assistance from Apple - whereas Intel literally hires people to help with the Linux project and to bring support for their own hardware on all platforms.

It'll shake up the industry that is for sure, and I hope it all turns out well.