Open reynhout opened 4 years ago
I mean it is not just about the ease of use when it comes to software centers, they are also great for discovering software you otherwise might not have been aware of (or would not have thought of searching for). But yeah overall I do prefer to use apt and synaptic most of the time above anything else due to less bloat. It is just that, if you all do decide to add a Software Center, GNOME Software Center would probably be the way to go. That is, unless the DE ends up being KDE for the next version, in which case KDE Discover could be an option too possibly.
@coltondrg I totally agree about your opinions on appgrid's looks lol. It is not only hideous but also, to be frank, it feels like it does not belong in GalliumOS and makes the rest of the OS feel less cohesive, as you said.
TBH I agree that apt and synaptic is the superior install method, I think you have to be a little savvy anyway to put gallium on a chromebook?
Not to be elitist about it or anything, but lets be very clear here: apt is the superior method, Synaptic is only barely passable if you're hopelessly addicted to GUIs and white monospace text on a black background gives you PTSD.
In all seriousness, much as you do need to have a little technical know-how (or at least be good at following instructions) to get GalliumOS installed, a lot of our users are new to Linux and aren't completely comfortable with bash, so we should provide some option for them. Is Synaptic good enough? Maybe, but it's obviously not designed for end users (the way package information is displayed, how the package name is used in the list as opposed to the application's human readable name, for example). I think at this point the best route for us to pursue is PackageKit and GNOME Software (or maybe Discover if we end up shipping KDE). I don't know what the dependencies for that look like, but I am pretty sure background daemon is inoffensive compared to the old Canonical one. We might even be able to disable it if we plan to continue using our little script for update notifications.
@Bertanx See, that's actually what AppGrid is good at, in my opinion: The traditional Software Centers are terrible discovery tools, but AppGrid is relatively curated and decent.
My discovery tool of choice is DuckDuckGo, but I get that most people prefer something else.
I'm with you on the DuckDuckGo thing, but then I almost never idly search for random software that doesn't do something very specific that I need for a given task.
This issue has filled with many affirmations of opinion, and I'd like to make this observation without expressing my personal preferences. I have never used appgrid, but have used apt, dpkg, and even dselect extensively in both professional and personal contexts, and have used the Ubuntu Software Centre and Synaptic out of curiosity at several points in their development histories.
It's clear that many people feel passionately about apt's efficiency and capability, and many recognise appgrid's benefits for discovery when new users are faced with the desire or need to install software. But the characterisation of synaptic as a tool for inexperienced users doesn't seem to fit for me. Synaptic is a confusing tool to navigate, and generally only makes sense if you are already a proficient user of apt. It doesn't seem to offer much above apt itself in terms of capabilities or usability, and would appeal only to a very narrow set of users, or as a last resort if a better GUI option were not offered.
As has been mentioned before, the concerns for GalliumOS are mostly focused on average memory consumption. A tool that starts and exits should likely only really be ruled out as "bloat" if it leaves running daemons consuming system resources when not in use, or possibly if it consumes an unusually large amount of filesystem space relative to the benefits it brings.
In my opinion there is no reason to use Synaptic if you are already familiar and comfortable with apt. I wasn't trying to characterize it as suitable for noobs, quite the opposite. Synaptic is great if you're a Windows power user and you understand the concept of package management, but aren't completely comfortable with the lack of colorful buttons to click on in your local terminal emulator. I think the average less experienced user can pretty much stumble their way through it and make it work in most cases, but it is by no means optimal for that sort of thing, which obviously leads to a bad user experience.
On the other hand, unlike most other GUI package managers, I'm pretty sure Synaptic actually has no background daemon or anything like that since it doesn't act as an update notifier, though it does lock the apt database while it's open, even if no operations are in progress.
@spacehobo I agree. We've always shipped apt
(of course) and Synaptic. We added AppGrid in the 3.0 release because Synaptic is too complex for most GUI users, and "a software center" was a common request. I'm not sure whether AppGrid has added value or not -- most comments about it are in reference to the PPA issue, not praising or complaining about its functionality.
Re: bloat, that's exactly the criteria I use for application of the word. We ship with Xfce GUI libs. Adding Ubuntu Software Center (e.g.) would pull in a ton of extra dependencies (a couple hundred MB, for the gtk3 bits IIRC), and leave a fat background daemon running (~60MB, IIRC).
Remember that our hardware baseline has historically been Chromebooks with 2GB RAM and 8GB of storage (16GB hardware, dual-booting ChromeOS and GalliumOS). We can decide to change that baseline, but that has been a very common config.
Anyway, given our constraints (low-spec hardware baseline, limited development staff), GalliumOS has always had to be fairly opinionated. Our decision back in GalliumOS 1.0 era was that the software center apps did not do their intended job well enough to justify their bloat in the default install (remembering that they're all just one apt install
away, for users that disagree). AppGrid looked like a decent compromise, and I still lean toward that being true -- if it's useful to anyone, which I do not have any data on one way or the other.
Has Xfce seriously still not started shipping GTK3 as it's base? Even MATE, the GNOME 2 continuation project, is doing that!
@coltondrg The intention is that the new Xfce (4.14) is mostly gtk3. I haven't re-measured the dependencies in the new version.
I see, that being the case, if those libs get pulled in anyway, that's no longer a concern. Canonical discontinued the Ubuntu Software Center in favour of GNOME Software and PackageKit with a few tweaks. I don't know if those tweaks make it uniquely unsuitable for our use-case, but at the very least I think the bugginess and the background daemons are less intrusive.
@coltondrg Right, if we go with Xfce of course. And we need numbers for the background processes, if they are still present.
Hi there, I brought some goodies. I installed Manjaro KDE on a Lenovo ThinkPad X140e and brought some screenshots so you could see how RAM usage is.
There is nothing else running in the background for this first one, but I had opened a web browser to research something, then closed it.
This second one I took right after opening Discord so I could send the first one to myself.
And finally, to represent a realistic lightweight workload, I left Discord running, fired up Vivaldi, and opened a few common tabs (one ArchWiki, one YouTube, and one GalliumOS website).
I installed Xubuntu 20.04 on one of my computers to test out the performance. I'll post some screenshots later, but here are some early observations:
And some observations about Kubuntu:
I also installed Ubuntu MATE on one of my machines, I only have a couple notes about that:
I haven't installed Lubuntu today, I don't really care about it because, even though it's almost guaranteed to trounce KDE in the memory department, I think the user experience is too terrible, especially for inexperienced users, to be worth even considering, but I am willing to install it if everyone is interested in the performance data. I also didn't try any of the others such as GNOME or Budgie. I actually do believe that Budgie could compete with MATE in terms of memory usage, but I don't think it can get close to KDE, so I think it's safe to rule out here.
@coltondrg This is very interesting, thanks for the detail!
Lubuntu is now LXQt, so it might be more compelling than the old LXDE was. I haven't taken a look yet.
Oh, I've never even used LXQt, I'll certainly look into it in that case. I use Debian or Arch with LXDE on my virtual machines since it seems to have less trouble with solutions like SPICE and X2go, I've never had a reason to try out LXQt.
If there is any hope of an upgrade wouldn't GalluimOS need to stick with Xfce? Though it is true Xfce uses more ram than in the past.
KDE used to be a lard butt but has been working out, and is now leaner than XFCE. Strange times we live in.
Jim
[edited by @coltondrg on June 26, 2020: please don't include links in your email footers to the issue tracker]
On Tue, Jun 23, 2020 at 9:14 PM kbd47 notifications@github.com wrote:
If there is any hope of an upgrade wouldn't GalluimOS need to stick with Xfce? Though it is true Xfce uses more ram than in the past.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/566#issuecomment-648524328, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6BIXSYOS6ZUXZIIM7H7SDRYFHODANCNFSM4MQQFQAA .
If there is any hope of an upgrade wouldn't GalluimOS need to stick with Xfce? Though it is true Xfce uses more ram than in the past.
Not necessarily.
FYI for Pixel Slate, Graphics are MUCH SMOOTHER using Ubuntu on Wayland than the default when you install groovy. (granted this is a WIP and I have kernel boot flags set to play with, but worth mentioning.)
Also, using the 5.4.0-26-generic
kernel the system boots to backlight set to maximum, which means I can see the screen, but switching resolution sets the display to very very dim. (Same goes for 5.7.8 mainline kernel, but the 5.8.x mainline kernels dim the screen during boot. I haven't tracked down where yet.)
@nocturne ~$ cat /sys/class/backlight/intel_backlight/brightness
1486
@nocturne ~$ cat /sys/class/backlight/intel_backlight/bl_power
0
@nocturne ~$ cat /sys/class/backlight/intel_backlight/max_brightness
7500
Also this is interesting:
@nocturne ~$ cat /sys/class/backlight/intel_backlight/bl_power
0
(Setting that to 1
turns off the backlight entirely.)
Also: alsa-info output: From booted into ubuntu: http://alsa-project.org/db/?f=e6d75655e4e52dcd4a4b72d01f8757b87408da5b From booted into ChromeOS: http://alsa-project.org/db/?f=12dc92b61265a9b1d9560ef8aaafb53657b5e3ac
If GalliumOS 4.0 decides not to use Xfce I'd rather it use LXQt. Lubuntu 20.04 is quite lightweight with LXQt. Is there a goal for when GalliumOS hopes to have the 4.0 release?
There is an audio issue that is fixed by kernel version 5.7.1-050701-generic. Will the upcoming GalliumOS include that kernel or at least the patch that fixes this issue. Sadly I don't know the exact patch that fixes this. Also I noted no other issue when I upgraded to 5.7.1-050701-generic. I'm using Acer CB3-131 with full firmware from mrchromebox.
Is this project still being worked on? It's hard to find any new information regarding development progress.
@jpawlowski412 Yes. All in good time.
Based on version 3, KDE Plasma (on other distros) and XFCE have similar graphics (so I don't think that the prettiness is a problem), but I have found that KDE takes an awful long time to load (i am using Samsung Chromebook 3, CELES), and that after loading, it takes even longer to become responsive.
Can we use latest software for this distribution, because most other (non-ubuntu, debian-based) distributions seem to be using software thatiss 5 years old.
The popular (cinnamon, kde, mate, xfce, lxde, icewm) desktop display software all looks so similar now, that It's mainly a matter of resource usage and built in system toolsin my opinion.
Sorry, space bar on my Windows computer isn't super great.
XFCE definitely has shortest boot time
Element name should be fermium.
FYI for Pixel Slate, Graphics are MUCH SMOOTHER using Ubuntu on Wayland than the default when you install groovy. (granted this is a WIP and I have kernel boot flags set to play with, but worth mentioning.)
Also, using the
5.4.0-26-generic
kernel the system boots to backlight set to maximum, which means I can see the screen, but switching resolution sets the display to very very dim. (Same goes for 5.7.8 mainline kernel, but the 5.8.x mainline kernels dim the screen during boot. I haven't tracked down where yet.)@nocturne ~$ cat /sys/class/backlight/intel_backlight/brightness 1486 @nocturne ~$ cat /sys/class/backlight/intel_backlight/bl_power 0 @nocturne ~$ cat /sys/class/backlight/intel_backlight/max_brightness 7500
Also this is interesting:
@nocturne ~$ cat /sys/class/backlight/intel_backlight/bl_power 0
(Setting that to
1
turns off the backlight entirely.)Also: alsa-info output: From booted into ubuntu: http://alsa-project.org/db/?f=e6d75655e4e52dcd4a4b72d01f8757b87408da5b From booted into ChromeOS: http://alsa-project.org/db/?f=12dc92b61265a9b1d9560ef8aaafb53657b5e3ac
Wayland being faster is expected -- Intel iGPUs newer than, say, Sandybridge have strong graphics, and Wayland enables a lot of zero-copy rendering stuff which speeds things up.
I have MX with XFCE, and KDE Neon. 9 year old Dell with a SSD, and the boot times are pretty much the same. I can't decide which I like better.
Jim
On Fri, Aug 7, 2020 at 8:25 PM AriIoffe notifications@github.com wrote:
XFCE definitely has shortest boot time
I think Ferrum would be ironic.
Or Krypton would be super. It would be noble to also have a Neon DE.
I'll get my coat. tough crowd.
Jim
On Fri, Aug 7, 2020 at 8:27 PM AriIoffe notifications@github.com wrote:
Element name should be fermium.
—
I have few ideas for GalliumOS 4.0, you can devise the distro in 3 versions :
GalliumOS Lite with LxQt desktop because his the most lightweight D.E for Linux, more than Xfce and prettier than Xfce, this version will be adapted for EOL and low performance Chromebook (with 16 to 32 GB and 4GB of RAM)
GalliumOS with Budgie 11 (Qt) because it's an environment which fits to your PC hardware and which is close to ChromeOS for his apparence, this will be the principal version of GalliumOS for a big part of Chromebook (with 32 to 128 GB and 4GB of RAM) Budgie 11 is not release today but I think Solus will be released at the end of 2020
GalliumOS Ultimate with KDE Plasma because it's an very complete D.E and and with much better performance than Xfce (I tested on GalliumOS 3.1), this will be the version for the best Chromebook (with 128 to 500 GB SSD and 8GB of RAM)
Another idea for this version is maybe that it be based on Debian 11 Bullseye (which should be released at the end of 2020) rather than Ubuntu 20.04 because Debian is lighter than Ubuntu, but you can also try to lighten Ubuntu 20.04
Final idea is for the name I think Fluorine is a good name
Sorry for my approximate English
I have few ideas for GalliumOS 4.0, you can devise the distro in 3 versions :
We are not interested in maintaining 3 distros instead of 1
GalliumOS Lite with LxQt desktop because his the most lightweight D.E for Linux, more than Xfce and prettier than Xfce, this version will be adapted for EOL and low performance Chromebook (with 16 to 32 GB and 4GB of RAM)
I have been using LxQt lately, and while it is lightweight, I don't know where you get the idea that it's prettier than Xfce, because it's hideous and half-baked still.
GalliumOS with Budgie 11 (Qt) because it's an environment which fits to your PC hardware and which is close to ChromeOS for his apparence, this will be the principal version of GalliumOS for a big part of Chromebook (with 32 to 128 GB and 4GB of RAM) Budgie 11 is not release today but I think Solus will be released at the end of 2020
GalliumOS 4.0 is going to be based on Ubuntu 20.04. Even if the Budgie team did release a new version, the Budgie team uses Arch, backporting Budgie 11 to an older version of Ubuntu will be a pain. Also not sure where you got the idea that Budgie 11 will be based on Qt, because it won't. Furthermore, there is no point in discussing software that hasn't been released yet because we're ready to start building GalliumOS 4.0 as soon as possible. To add insult to injury, I've also used Budgie on a Chromebook before and it uses a relatively high amount of system resources so it's not really suitable for the hardware. Budgie is highly customizable, so it can look kinda like Chrome OS, but it doesn't really provide an experience similar to Chrome OS out of the box.
GalliumOS Ultimate with KDE Plasma because it's an very complete D.E and and with much better performance than Xfce (I tested on GalliumOS 3.1), this will be the version for the best Chromebook (with 128 to 500 GB SSD and 8GB of RAM) Recent improvements to Plasma (post-Ubuntu 18.04) have brought significant performance
Plasma is being considered, as discussed earlier, but right now we're leaning toward the defacto option, which is to continue using Xfce. It has served us reasonably well in the past, we wouldn't have to port our desktop fixes over to other desktop environments, and many of our users are already fond of their riced Xfce setups.
Another idea for this version is maybe that it be based on Debian 11 Bullseye (which should be released at the end of 2020) rather than Ubuntu 20.04 because Debian is lighter than Ubuntu, but you can also try to lighten Ubuntu 20.04
Once again, we don't talk about software that hasn't been released. Citation needed for Debian being lighter than Ubuntu, the only practical difference in our case is which repos we get our software from, since we build the distro from scratch and cherry-pick packages instead of using what Canonical ships with Xubuntu. To be perfectly clear, I do like the idea of having a Debian-based version of GalliumOS, but Ubuntu is what we have been using and because we only want to maintain one distro, the prospect of releasing a GalliumOS Debian Edition is out of reach. If the team was bigger and it's volunteers had more time, we would be able to do things like this, but right now we're already struggling to keep new versions coming out and you're asking us to basically triple our workload.
Seeing that it appears this conflict has resulted in the complete disappearance of at least one major contributor to GalliumOS, the public needs to focus on GalliumOS 4.0 being whatever is usable and whatever the team decides to release. I think that drive-by comments here about which DE to use are unhelpful.
@reynhout, can you tell me what is meant by this?
Port kernel patches to 5.4 LTS and/or 5.6+
Where can I find GalliumOS's existing kernel patches? I'd like to try working on this. Bar receiving better advice I plan to get them working on top of the Debian Live Builder for Debian Testing, but I'm sure you have better advice.
I have the following to test.
@Hurricos Awesome, thanks!
FYI I wouldn't read too much into the previous comment -- there's really no conflict.
I agree that our plan should be to ship the new Xfce in 4.0, because it is the most expedient. A major DE change should probably come as an option first, and then we should do the default switch in the next major release, after the quirks are ironed out.
Re: kernel patches: all of our stuff is at GalliumOS/linux. Check the *-galliumos
branches.
The 4.x patches will need porting to 5.x. This shouldn't be too much work, and some can probably be dropped completely. There are also some new patches floating around out there that we should include in 5.x but getting the baseline booting (e.g. PEPPY) is the first step.
I've never used the Debian Live Builder, I just use the deb
target in the mainline Makefile. Requires some additional options for a release build, but the basics should work for tests.
Hi,
I don't want to dive into the DE debate, I just want to share something that might be useful: https://material-shell.com/
Good luck for GalliumOS 4.0 ;-)
also with the release name i think flerovium sounds good
@reynhout As for the 5th point on your list, I already wanted to open a new issue complaining about that - shipping 4.16 is a large problem imho, as it is an old non-LTS kernel with unpatched known vulnerabalities. It might make sense to complete that as one of the first things - even people who are not using GalliumOS would benefit.
I've never used the Debian Live Builder, I just use the
deb
target in the mainline Makefile. Requires some additional options for a release build, but the basics should work for tests.
Never saw a deb target when I got stuck on this one a few weeks back.
How exactly did you build e.g. https://github.com/GalliumOS/linux
@ v4.16.18-galliumos
?
Edit: Opening a new issue to work on this, since galliumos/linux does not have an issue tracker.
You might just want to start with the 5.4 kernel which Google is patching up for ChromeOS...
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-5.4
I want to start with something I can compile, is all.
I would also recomend Material Shell, easy for underpowered chromebooks to use. My 2013 Toshiba CB1 can run Ubuntu 20.04 with Gnome well but runs material shell perfectly.
It would be nice to add a optional rolling release repository. It is one of the nice features of Kali Linux. They are very convenient. PS. I cant choose between fermium and flerovium (something new, unexplored)
I think that maybe a switch from xscreensaver to the default XFCE locker would be a good addition to the next version of GalliumOS. xscreensaver still locks/blacks out the screen when applications like VLC is being played in fullscreen, and there's a really cumbersome workaround in the form of a script when I looked online. I currently switched to Arch from GalliumOS on my Acer C720 and the locker didn't interrupt the video I was playing.
The new Microsoft Edge (DEV) edition is a less resource intensive application than the Chromium Browser despite being built upon the same code base. I think this should get serious consideration as to the default web browser. I opened a different ticket before I found this GalliumOS 4.0 thread.
I like Fermium as the name. Heaviest element that can be synthesized by neutron bombardment instead of requiring full Fusion to create. And a nice round 100 protons...
The new Microsoft Edge (DEV) edition is a less resource intensive application than the Chromium Browser despite being built upon the same code base. I think this should get serious consideration as to the default web browser. I opened a different ticket before I found this GalliumOS 4.0 thread.
Using (and liking) Edge here, especially since it has built-in "sleeping tabs" (tab suspending), but there currently is only the develop branch, which is of course filled with bugs and lacks synchronisation. Also, the whole reason of bundling Chromium is its less tied to a corporation and is open-source, and let's be honest, most people are using Chromium/Chrome instead of Edge on Linux; I imagine especially if they were using ChromeOS extensively beforehand before installing GalliumOS.
Are you all still working on 4.0. Really interested and looking forward to it. I have little to offer in terms of programming but would like to say its important work.
I am using Microsoft Edge for Linux (the Dev channel), I am not fooling with it, and It seems to be pretty stable. If microsoft releases a beta release in time for GalliumOS 4.0, then I think I vote for using microsoft edge.
Planning and preparations for GalliumOS 4.0.
Our presumptive upstream distribution is Ubuntu 20.04, which released yesterday.
TODO
Fluorine
F 9,Francium
Fr 87,Fermium
Fm 100,Flerovium
Fl 1143to4
(and maybe2to3
for good measure?)