I used to put it first for convenience, but got increasingly paranoid about something same-named getting slipped into my ~/.local/bin; now it lives at the end.
Out of curiosity, if you use the split view, why? I never understood what it can do that my window manager cannot, but maybe I am overlooking something?
I do it sometimes for highly related work (referencing on tab against the other) that will be a longer running task (30+ minutes).
It means that both tabs get maximized and minimized at the same time, and the two tabs are always side by side. Which means if I need to jump to another task, like answering a message or joining a video call, I can get back to my work faster. It’s a small thing that helps with context switching.
I do it when I consider both side of the Split View one unified context I am working on. I do it not only with browser tabs, but sometimes terminal tabs. I most commonly do it with IDE tabs.
I don’t use split view much, but I can understand the appeal.
It makes a lot of sense if one uses subject-based browser windows (e.g. 1 window == 1 subject); it keeps all tab organization within the browser and makes it easy to minimize it, move it to different screens/desktops, save/restore it, etc consistently with less overhead (no secondary organization system [such as that of the window manager] involved).
This becomes even more valuable for cross-platform users who sync and can’t rely on their favorite uberleet-haxor-wm package being available everywhere.
I suppose that depends what your window manager is and how it's configured? Most don't have an easy way to lock two windows together as they are moved as one though - especially on corporate devices.
Practically, it's most useful when I have two references for the same thing I want to move together as I work on that thing. E.g. Jira + Functional Spec as I do things related to them.
The big selling point is that everything stays in the same window.
- The split view is a special looking tab you can come too easily.
- You can have several split views in the same window.
- Selecting what tab you want in the split view is much cleaner than tearing off tabs into windows.
- No conceptual switch between "tab" and "window".
I use a tiling wm, but the split view is more compact because it doesnt have two (vertical) tab bars. Useful on a cramped laptop, less so on a large screen
I think the key here is that split view makes one tab show two sites. So when you switch the tab, you switch both views at the same time. You can't achieve this with a window manager, unless you already (instead of tabs) used only windows that your window manager rendered as tabs, and then comes also with this feature. Does any?
For a non technical user it is much easier to right click a link (for example a reference in a news article) and choose Split View than arrange two windows (which may involve 2 different monitors).
For a Teams/Zoom screen where you are sharing only one app rather than whole desktop, again split may help.
Also good for mental switching, as you can open a link to the side and either promote to it's own tab/close and carry on with same page rather than have it open separately and break the flow
OS components don't need to have compatible licenses if they're separate from each other. The Linux kernel is GPLv2-only which forbids GPLv3 licensing. That doesn't mean GPLv3 code can't be used in a Linux-based OS.
We use GPLv2 and permissive licensing for GrapheneOS to avoid more restrictive licensing than the AOSP. We'll happily use GPLv3 and AGPLv3 for components outside of GrapheneOS if we think it's the best fit for specific projects. We aren't currently licensing anything as GPLv3/AGPLv3 but we aren't strictly opposed to it outside of the OS.
We'll use what we think are the best open source licenses for what we want to achieve. What we want to achieve is usually broad adoption of our code with painless usage of it. That means we usually choose permissive licenses. We use GPLv2 in certain cases such as Vanadium where we decided we wanted extensions to our code to be under a compatible open source license instead of a source available license or GPLv3.
GrapheneOS does include GPLv2 code both via AOSP and our own but not GPLv3. We want GrapheneOS to have no additional restrictions beyond AOSP. AOSP uses GPLv2 but not GPLv3.
We do need to be careful with GPLv2 due to license incompatibilities. For example, GPLv2-only licensing such as the Linux kernel is incompatible with Apache 2 and GPLv3. GPLv3 is compatible with Apache 2 so GPLv2-or-later can be compatible but only by using it as GPLv3 with the extra restrictions too.
It seems like you have more freedom than you think you do. See this comment <https://news.ycombinator.com/item?id=49594824> Packaging software shouldn't change the license of GOS as such. If you haven't had already, maybe the free software foundation could provide you with assurance?
I guess it will make your life much easier if you wouldn't have to restrict yourself that much.
No, we're not talking about packaging software in our app repository (App Store) but rather software being included in GrapheneOS. If any GPLv3 software is included in GrapheneOS then that places more restrictions on how it can be used as a whole.
I think you are confused. You can have a Linux distribution with software with incompatible licenses (e.g. GPLv2 and Apache License version 2), because the license for a particular program or library only applies to that specific work, not other works that it is distributed with. The GPL is very clear on this:
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
There are some cases where a separate work can be considered derivative and thus the GPL can apply. E.g. I think it is generally accepted that a program linked statically against a GPL library is considered a derivative work (and must thus must have a license compatible with the GPL). More controversial is whether dynamic linking creates a derivative work. To cover the latter case, a lot of copyleft libraries are licensed under the LGPL or the GPL with a dynamic linking exception.
At any rate, shipping a Linux distribution with GPLv2 code (e.g. the Linux kernel) and a GUI application that is under the Apache v2 license is not a problem at all (as long as the GUI application is not a derivative of a GPLv2 work).
GPLv2 and Apache 2.0 are not incompatible licenses when bundled together. GPLv3 is the problematic license as it requires all code it is bundled with be GPLv3 as well.
When it comes to AOSP/GOS, bundled apps are not aggregated together, they are built and signed under a singular OS binary.
This is a consequence of browser monopolies, established by Microsoft in the 90s: everyone should have to pay for a browser and make a deliberate choice in vendor. The fact that they're free and subsidized by large businesses in other markets, rather than being a product you choose to buy, is a concrete example of monopolistic market distortion.
Sure, but I would say you almost always want to add to the start of the PATH, not to the end.