Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Consolidating the Linux Desktop App Story: An Idea

jonobacon.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Consolidating the Linux Desktop App Story: An Idea

#51

Post by flukus »

wmf wrote: post #45
iBelieve wrote: post #42

Earlier quoted context omitted.

The big problem with web apps as first-class citizens is UI inconsistency. What I love about native desktop apps is that they should all follow well-defined user interface guidelines and all use the same toolkit/theme. With web apps, you don't get that - every web app uses its own fonts, its own styles, its own UI structure and navigation.

But no major desktop app [1] follows the guidelines because they think branding and novelty trumps consistency. [1] Except apps written by the OS developer.

> [1] Except apps written by the OS developer.

I assume you mean apple? Because even the apps built into windows 10 are completely inconsistent with one another or any platform standard.

Re: Consolidating the Linux Desktop App Story: An Idea

#52

Post by flukus »

drdaeman wrote: post #25
revelation wrote: post #21

Earlier quoted context omitted.

The biggest takeaway from the era is that no one fucking bothers to write software for 10 different distributions with 15 different ideas on how the most trivial of things are to be accomplished. And here is this guy wanting to build number 16. There is an xkcd on this. This train has left the station.

Nah, almost all mainstream (and even most non-mainstream) distros are basically equal. Seriously, maybe I'm wrong but I don't think that's an issue. As long as your distro doesn't replace glibc for e.g. musl or bionic, and has all the usual GNU (and X11, and DBus if you need that) userland, i.e. no odd stuff - there is no much difference. Most of the time things just work. Normally, the only time you'll have to "writ…

> That is, unless you need to target some specific library version that's higher or lower than the usually available, incompatible with the usual version, and you don't want to have a statically-linked release variant. E.g. something that would work only with Qt5.2 but not with Qt5.6. Don't see why not to just throw it all in a tarball and call it a release. Saw this done many times, I just unpacked it, ran it - and it worked.

In this hypothetical (I hope) example, you've just subjected your users to unpatched vulnerabilities like this one: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0190

Re: Consolidating the Linux Desktop App Story: An Idea

#53

Post by gabrielcsapo »

flukus wrote: post #47
gabrielcsapo wrote: post #32

Earlier quoted context omitted.

The issue is that electron is running a new chromium process for each application. This could be fixed easily sharing that process and making chromium more resource friendly.

And go back to the 80's where one app crashing can take down the whole system? No thanks. Apps would be able to overwrite each others memory then too, you'd get the full Amiga experience.

So make the singular processes run in a tighter sandbox where performance is necessary

Re: Consolidating the Linux Desktop App Story: An Idea

#54

Post by gabrielcsapo »

pcwalton wrote: post #40
michaelmrose wrote: post #28

Earlier quoted context omitted.

Bad for battery and ram. Fixing this is probably difficult to impossible. I have 10 apps open imagine if they were all using 1-2GB of ram.

> Fixing this is probably difficult to impossible. It is absolutely possible to make a browser engine-based shell that is more efficient than Electron is. Electron has the wackiest setup imaginable, mashing together Node and Chromium, with two versions of V8 to boot.

That is what I am talking about. Who is making this happen!?

Re: Consolidating the Linux Desktop App Story: An Idea

#55

Post by jonobacon »

revelation wrote: post #21
marktangotango wrote: post #5

I was rolling my eyes reading this and then hit this, which is the real value of the article IMO: > few Linux platforms (if any?) had taken a series whack at building a consumer grade app and developer experience. We tried, it was not successful, and instead of digging up the past I would rather ensure we can inform the future. "What not to do, and how not to do it" are at least one valid take away from that whole er…

The biggest takeaway from the era is that no one fucking bothers to write software for 10 different distributions with 15 different ideas on how the most trivial of things are to be accomplished. And here is this guy wanting to build number 16. There is an xkcd on this. This train has left the station.

Did you actually read the post? I am not suggesting anyone builds anything new, instead that we are realistic in how much work is involved and distributions consolidate around something that already exists.

Re: Consolidating the Linux Desktop App Story: An Idea

#56

Post by bjpbakker »

mhall119 wrote: post #3
swiley wrote: post #2

I really don't understand the drive to make GNU/Linux a "consumer operating system." The consumers don't care and are happy with absolutely awful software. Shiny GUI toolkits that are a huge pain to develop for, and non-free software gos against what the people who use GNU/Linux now want. That's why ubuntu's unity stuff failed, because they chased after users who don't care and alienated the only ones that might use…

It's because Linux desktop users want to be able to use consumer software, and the only way they're going to get it is if Linux becomes a consumer operating system

Linux desktop has mostly been about using free software IMO. If you don't care about your freedom, why not run macOS?

Most vendors of non-free software do support macOS (or viable alternatives are available). I strongly doubt many of them will even come to Linux. Because it requires more standard configurations. Apple had to make its main FS case insensitive before vendors like MS and Adobe were porting their software.

I like having my own choice in configuring my system. That amd freedom is why I use Linux desktop.

Re: Consolidating the Linux Desktop App Story: An Idea

#57

Post by bjpbakker »

merlijn_s wrote: post #23
mhall119 wrote: post #3

Earlier quoted context omitted.

It's because Linux desktop users want to be able to use consumer software, and the only way they're going to get it is if Linux becomes a consumer operating system

Yes! Developers are people too..

I don't see anyone here who suggested they're not?

Re: Consolidating the Linux Desktop App Story: An Idea

#58

Post by flukus »

gabrielcsapo wrote: post #53
flukus wrote: post #47

Earlier quoted context omitted.

And go back to the 80's where one app crashing can take down the whole system? No thanks. Apps would be able to overwrite each others memory then too, you'd get the full Amiga experience.

So make the singular processes run in a tighter sandbox where performance is necessary

Once you sandbox that much you've just reinvented processes.

Re: Consolidating the Linux Desktop App Story: An Idea

#59

Post by bryanlarsen »

revelation wrote: post #21
marktangotango wrote: post #5

I was rolling my eyes reading this and then hit this, which is the real value of the article IMO: > few Linux platforms (if any?) had taken a series whack at building a consumer grade app and developer experience. We tried, it was not successful, and instead of digging up the past I would rather ensure we can inform the future. "What not to do, and how not to do it" are at least one valid take away from that whole er…

The biggest takeaway from the era is that no one fucking bothers to write software for 10 different distributions with 15 different ideas on how the most trivial of things are to be accomplished. And here is this guy wanting to build number 16. There is an xkcd on this. This train has left the station.

He advocates flatpak, which is basically desktop Docker. You package all your dependencies so you can choose any of the 15 to put inside your flatpak, and it'll work with any of the 15 outside your flatpak.

You get the normal trade-offs for this approach -- large downloads, disk space, slow security updates, UI inconsistencies but XKCD 927 doesn't really apply.

Re: Consolidating the Linux Desktop App Story: An Idea

#60

Post by revelation »

bryanlarsen wrote: post #59
revelation wrote: post #21

Earlier quoted context omitted.

The biggest takeaway from the era is that no one fucking bothers to write software for 10 different distributions with 15 different ideas on how the most trivial of things are to be accomplished. And here is this guy wanting to build number 16. There is an xkcd on this. This train has left the station.

He advocates flatpak, which is basically desktop Docker. You package all your dependencies so you can choose any of the 15 to put inside your flatpak, and it'll work with any of the 15 outside your flatpak. You get the normal trade-offs for this approach -- large downloads, disk space, slow security updates, UI inconsistencies but XKCD 927 doesn't really apply.

Does everyone nowadays only write software that is some messy desktop rendition of a website?

The kind of software I write doesn't exist in a vacuum where all it needs is to run AMD64 code, Linux syscalls and a canvas to draw on. It needs to interact with the system, figure out what drives you have inserted, play nice with keychains and whatever..

You can't flatpak that.

Post reply on HN