4 ms·

> I don't see Linux users demanding snaps in large numbers There is a demand for a way to package and distribute applications independently of distribution and

> I don't see Linux users demanding snaps in large numbers There is a demand for a way to package and distribute applications independently of distribution and with sandboxing. Hence Flatpak, who are doing it right. > I need to first ask all the linux users and all the distros for approval and implement and support all of them. Did you ever worked with some folks doing system-level work? Adoption by distributions is definitely a concern for them. They don't want to work on something that no one would use and by being mostly independent, they can not cram it into distribution as Canonical is doing. Even Redhat people have to prove worth of their solutions. > I do not remember GNOME or systemd listening to what users want, they had a team with a big ego and implemented their vision. Because you never met them. Both teams do listen to what users want. Just do not mistake what users want with what a few loudmouths want. > If I would be a billionaire and I want to create my own DE or distro I would never waste time to make sure my stuff gets approval from people that think they know things Even if you had your own distro, you would be probably interested in it's adoption, right? It is a bummer to have a distro that nobody would want to use ;). But I understand; it is a different thing to work with people who have an idea what they are doing, vs. listening to bikeshedding. However, this is not a case of snap and Canonical. They are doing the wrong thing, because they have different objectives than the ones publicly communicated, and they know it (they communicate technical hows, but not business whys).

simion314 6y ago
Because I am developer and I have experience with different technology and with different kind of users, no I would not try to get the largest number of users. What we need is more science and data, I would not do X because some designer things looks cool or some here developer wants to play with some cool tech. For example a few years ago KDE Plasma had a maintainer in charge with a big ego(yeah, KDE has some people like this not only the other DE), users wanted an option to disable a thing on desktop (the cashew https://www.omgubuntu.co.uk/2019/10/kde-kills-desktop-toolbox-icon https://www.omgubuntu.co.uk/2019/10/kde-kills-desktop-toolbo...) .We had patches but (similar to GNOME devs) the maintainer ego was too big and it took years for normality to happen. IMO is snap is bad or this feature is really needed it will happen or snap will die, same for tray icons in GNOME they will add them back when the big ego guy that is against it will find something else to focus on(not sure we will ever have UX study and use data for decisions)
- vetinari 6y ago
  Tray icons in Gnome are not about big ego guy. The issue is entirely different, rooted in different problem. Systray appeared for a first time in Windows 95, which had no notion of services, say nothing of user services. Here it started to be abused, at first for quicklaunch scenarios (where an app preloaded itself into ram or disk cache at least at login, so when the user clicked the app icon, it launched "quickly"). Later it started to be abused by apps to make them difficult to turn off (Skype is the classic example). The respective developers redirected all the WM_CLOSE to just minimizing the app, removing it from taskbar, but kept the app running and restorable in the systray. Many users were frustrated that they are not able to quit the app (if they noticed), power users just nuked them from the taskbar. Models like this are not acceptable on a modern desktop. Even if some people are used to this and cannot imagine something different. It was Android that came with solution for this: split the app into the UI (Activity in Android parlance) and the background task (the service). The background task cannot interact with the user directly, but it can communicate with the UI (if/when it is running) and send notifications when it needs attention, so the user can launch the UI for ecample (one nice thing is that notifications persist even if the process originating it crashes). It can be launched by the system at login (i.e. as systemctl user service on linux desktop), or it can be launched on demand by the UI part, and it can be similarly terminated. The UI can do many things, but one thing it can't do is to keep it's process running once the user closed all it's windows (Gnome-on-Wayland started to check for this and complains to the user about that, offering whether to quit the app or not). This model works greatly for apps that genuinely need to run in the background, check for things and on some event notify the user (mailbox monitors, instant messaging, file sync, media players etc). It does not work for apps, which want force themselves on the user, do something that the app developer wants but user doesn't (i.e. Skype) or those who have no reason to be in a background, but they do anyway (VLC for example, where users click on video, but since it is already running and it allows only for one instance so nothing happens then, frustrating user again). The split into UI/service is also positive in that the resources needed to run while in background are lower; all the assets the UI needs are only loaded, when the user launches the UI part. Meanwhile, AppIndicators & co extensions are there until the developers migrate their app to the newer model. Which takes a while, Rome wasn't built in a day either.

simion314 6y ago

Because I am developer and I have experience with different technology and with different kind of users, no I would not try to get the largest number of users. What we need is more science and data, I would not do X because some designer things looks cool or some here developer wants to play with some cool tech. For example a few years ago KDE Plasma had a maintainer in charge with a big ego(yeah, KDE has some people like this not only the other DE), users wanted an option to disable a thing on desktop (the cashew https://www.omgubuntu.co.uk/2019/10/kde-kills-desktop-toolbox-icon https://www.omgubuntu.co.uk/2019/10/kde-kills-desktop-toolbo...) .We had patches but (similar to GNOME devs) the maintainer ego was too big and it took years for normality to happen. IMO is snap is bad or this feature is really needed it will happen or snap will die, same for tray icons in GNOME they will add them back when the big ego guy that is against it will find something else to focus on(not sure we will ever have UX study and use data for decisions)

vetinari 6y ago
Tray icons in Gnome are not about big ego guy. The issue is entirely different, rooted in different problem. Systray appeared for a first time in Windows 95, which had no notion of services, say nothing of user services. Here it started to be abused, at first for quicklaunch scenarios (where an app preloaded itself into ram or disk cache at least at login, so when the user clicked the app icon, it launched "quickly"). Later it started to be abused by apps to make them difficult to turn off (Skype is the classic example). The respective developers redirected all the WM_CLOSE to just minimizing the app, removing it from taskbar, but kept the app running and restorable in the systray. Many users were frustrated that they are not able to quit the app (if they noticed), power users just nuked them from the taskbar. Models like this are not acceptable on a modern desktop. Even if some people are used to this and cannot imagine something different. It was Android that came with solution for this: split the app into the UI (Activity in Android parlance) and the background task (the service). The background task cannot interact with the user directly, but it can communicate with the UI (if/when it is running) and send notifications when it needs attention, so the user can launch the UI for ecample (one nice thing is that notifications persist even if the process originating it crashes). It can be launched by the system at login (i.e. as systemctl user service on linux desktop), or it can be launched on demand by the UI part, and it can be similarly terminated. The UI can do many things, but one thing it can't do is to keep it's process running once the user closed all it's windows (Gnome-on-Wayland started to check for this and complains to the user about that, offering whether to quit the app or not). This model works greatly for apps that genuinely need to run in the background, check for things and on some event notify the user (mailbox monitors, instant messaging, file sync, media players etc). It does not work for apps, which want force themselves on the user, do something that the app developer wants but user doesn't (i.e. Skype) or those who have no reason to be in a background, but they do anyway (VLC for example, where users click on video, but since it is already running and it allows only for one instance so nothing happens then, frustrating user again). The split into UI/service is also positive in that the resources needed to run while in background are lower; all the assets the UI needs are only loaded, when the user launches the UI part. Meanwhile, AppIndicators & co extensions are there until the developers migrate their app to the newer model. Which takes a while, Rome wasn't built in a day either.