331–340 of 362 posts
Earlier quoted context omitted.
Nope - setting up an iCloud account is filling in a username and password. Your approach doesn’t even come close to being anywhere near that easy.
It also requires buying an iPhone and almost none of the features work with your desktop (unless it’s a mac) so IMO that’s not so easy.
Earlier quoted context omitted.
Here is an example : take an Intel nuc : Ubuntu, everything works out of box. Win10 ? Let's download a WiFi driver on Intel site ! Let's hope you have Ethernet or a windows 10 supported wifi device. And no, the wifi dongle lying around is too old, windows 7 only... What is your example ?
Here's a counter example. Buy a thinkpad and try to put whatever distro you want on it.
Also I don't use wayland and don't have the scaling perf problem that someone else was talking about.
Earlier quoted context omitted.
Maybe Linux would get wider adoption if its evangelists weren't so condescending? Maybe instead of assuming everyone who's had a bad experience with your OS must be missing something obvious, you should give the benefit of the doubt? Until earlier this year I ran Lubuntu on 4/5 of the PCs I own. I've tried other distros but that one worked the best for me and it was still a giant pain in the ass. There's only 1 Linux…
You are of course correct. I'm sorry about my outburst. I've had too many experiences with "Haha linux on desktop bad nerd haha" people, and let it get to me. I apologize.
That was happening in this thread too outside of you.
For reference, I too have spent a decent amount of time with Lubuntu. I doubt I’ll switch from Mac for foreseeable future.
Earlier quoted context omitted.
> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. This is not entirely correct. Distributions can use a "brand store" to have complete control over which packages their users get. > You can’t audit them Many Snaps contain a build manifest in `/snap/snap-name/current/snap/manifest.yaml`. This manifest contains a log of every…
> This is not entirely correct. Distributions can use a "brand store" to have complete control over which packages their users get. By “you” I assume they are referring to users, not distributions.
> hold them
Users have many ways to hold snaps temporarily. If they want to hold snaps indefinitely, then they should install them using he `--dangerous` flag. That won't give them any updates, but I'm guessing that's the point. They can always get the latest version of the app manually using `snap download snapname` and install it using `snap install snapname.snap --dangerous`.
> modify them
Just like a `.deb` package, users can unpack a snap, modify any file, repack and install the modified version. Alternatively, you can unpack the snap, modify any file and install the directory using "snap try". You can then modify files and rerun the app without having to reinstall it for every change.
> or even point snap to a different store.
The signing keys are baked into the Snap binary but the URL is configurable via an environment variable. So users can change to a different Brand Store without any issue. If they want to use a store with a different signing key, they have to install a different version of snapd which is compiled with the signing keys of the other vendors.
This isn't an insurmountable problem, but it is less flexible than apt, yes. Although I think "apt remove snapd; apt install snapd-fsnap" is still pretty easy..
Earlier quoted context omitted.
Nope - setting up an iCloud account is filling in a username and password. Your approach doesn’t even come close to being anywhere near that easy.
It also requires buying an iPhone and almost none of the features work with your desktop (unless it’s a mac) so IMO that’s not so easy.
The author mentions popularity as a justification and good reason to go with a central snap store. I am baffled.
(author here) I'm not sure what you are referring to exactly, where do you think I say that? These are the reasons I talk about in the blog: * users can easily discover new applications, * developers can easily publish their apps, * and developing Snap itself is easier.
Earlier quoted context omitted.
> a major reason why most distributions and users won't adopt snap What "most distributions" you mean? Snap is already available for many distros.
And the ones based on Ubuntu are removing it. On the rest, available doesn't mean anything, it is a low quality packaging. On any distro that doesn't run apparmor, the snap sandbox doesn't work, for example. That's not something you would use outside of experiments.
I know of at least three Ubuntu derivatives who have Snap preinstalled and every snap I maintain has between 5% and 10% non-Ubuntu users.
> On any distro that doesn't run apparmor, the snap sandbox doesn't work, for example. That's not something you would use outside of experiments.
Given that every AppArmor thing Snap needs is in the upstream kernel, any distribution with a fairly recent kernel an userspace has full confinement. The main limitation is that Snap can't run when SELinux is running at the same time. Canonical is working with a bunch of other people on LSM stacking in order to make that work.
> That's not something you would use outside of experiments.
That might not be something you use outside of experiments, but don't generalize statements like that.
Earlier quoted context omitted.
> 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…
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…
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.
Earlier quoted context omitted.
And the ones based on Ubuntu are removing it. On the rest, available doesn't mean anything, it is a low quality packaging. On any distro that doesn't run apparmor, the snap sandbox doesn't work, for example. That's not something you would use outside of experiments.
Linux Mint put in an apt rule to avoid it installing as a dependency of other apps. This decision was triggered by Canonical's announcement to stop maintaining the Chromium deb package. Linux Mint was pissed they had to either switch to the Debian version or to the Snap, so they made some fuss. I know of at least three Ubuntu derivatives who have Snap preinstalled and every snap I maintain has between 5% and 10% non-…
Pop!_OS doesn't install snap by default, but it does Flatpak.
> Given that every AppArmor thing Snap needs is in the upstream kernel, any distribution with a fairly recent kernel an userspace has full confinement
Just because it is in upstream kernel, does not mean it is used by other distributions. Only that it can be used. But so can be SELinux, which is also in upstream kernel.
> The main limitation is that Snap can't run when SELinux is running at the same time.
Exactly, different distributions have chosen different LSMs in the past and they are going to stick with them. RHEL or Fedora are not going to switch to AppArmor anytime soon.
> Canonical is working with a bunch of other people on LSM stacking in order to make that work.
Good for them that they are realizing this is a problem. Flatpak was developed from the start with the different LSMs in mind.
> That might not be something you use outside of experiments, but don't generalize statements like that.
OK, some people might be too brave ;)
Earlier quoted context omitted.
I give you a variety of points and all I get back is a single flip quip. This is a disappointing rejoinder. You CAN have a high end desktop. You can even have 3-6 monitors if it makes you happy. The only thing you cannot do is plug your monitors into the outputs of both GPUs. You must purchase GPUs wherein a single GPU has sufficient outputs and let the secondary GPU serve to aid in your favorite GPU compute or game…
Is it possible to have two cards and have the second card do computations for the first one to render? I would have thought the time it took to move the data would make that hard.
Crossfire and SLI rely on a high speed interconnect and game specific support.