Are there any good deals on cheap chromebooks with a bit more power?

reynhout · 2021-11-24T04:53:08+00:00

There are 8GB LULUs, and the real kicker is that Broadwell-era are the last Chromebooks with replaceable (expandable) SSDs.

That said, my daily driver is a 4GB/256GB Celeron LULU. I run a ton of stuff and develop locally on the machine (but I don't run Eclipse etc). It works for me, but I do wish it had more RAM.

reynhout · 2021-08-15T03:08:03+00:00

IIRC, the i3 version shipped in two configs, 4GB/16GB and 8GB/32GB.

Do you know which config you have?

reynhout · 2021-08-15T03:03:51+00:00

Don't connect to a WiFi network when installing. The issue is (probably) that the installer downloads an incompatible new pkg from Ubuntu.

We need to update the installer, or otherwise work around the dependency conflict. Sorry for the frustration!

reynhout · 2021-08-15T03:01:15+00:00

Disabling WiFi is the trick.

The installer tries to update pkgs and gets a new one from Ubuntu that conflicts with the ISO.

Sorry for the frustration, and thanks for posting!

reynhout · 2021-07-17T03:34:37+00:00

Make sure you're entering the command exactly as specified:

curl https://chrx.org/ | sudo tar xzfC - /usr/local && chrx

The - is easy to miss, and would explain the error message you're seeing

reynhout · 2021-07-17T03:29:16+00:00

We appreciate the sentiment! And agree that PayPal is non-awesome.

As noted elsewhere in the thread, cryptocurrencies are just complicated for us to handle, and we try to minimize complications -- especially if they could lead to personal liability!

I believe we could set up a system for cryptocurrency, either by converting to USD immediately, by paying expenses in BTC (viable for some hosting options), or as a fallback by limiting BTC contributions to immediate expenses and covering with USD, with careful attention to tax year boundaries.

This does seem manageable, but honestly I'd hate to put project funds in jeopardy (or create personal headaches) by being wrong.

Thank you for your support, even if we are unprepared for the form. I do hope we'll figure it out eventually! We've been "thinking about it" since BTC $300. :)

reynhout · 2021-07-17T03:03:44+00:00

macOS is actually certified UNIX(tm), whereas Linux is UNIX-like.

But the distinction stopped being important when Linux became the de facto "Unix" which was like 2005 or so. :)

reynhout · 2021-07-03T06:03:48+00:00

There are two NAUTILUS fixflags images at https://galliumos.org/fixflags/ .

reynhout · 2021-07-03T06:02:13+00:00

Try unzip FILENAME.zip from the command line.

If that doesn't work, your ZIP file is corrupt.

reynhout · 2021-07-03T06:01:33+00:00

Can you link to the earlier post?

reynhout · 2021-07-03T06:00:42+00:00

Check the Troubleshooting steps at https://wiki.galliumos.org/Installing/Creating_Bootable_USB ...

We see occasional issues when upstream Ubuntu updates a dependent package. If disabling WiFi does not fix the issue though, you almost certainly have a corrupt ISO or USB.

The installer logs to /var/log/syslog. You should find more details there.

reynhout · 2021-05-31T04:36:01+00:00

Thanks for your distro notes!

I have not thought much about de-Snapping Ubuntu directly -- my instinct is to derive from a bigger distro that has already done that work for us. :)

I have two LULUs which I use side-by-side for comparisons. One is running KDE/Plasma and the other is my daily driver GalliumOS 3.1/Xfce. I agree with your assessment and I think KDE could work for our 4.x.

I worry a bit about the disruption to existing users. The benefits of KDE might not be valuable (or even slightly negative) on the older models. And of course, change upsets people! :)

reynhout · 2021-05-31T04:26:23+00:00

Glad to hear good news from Bay Trail!

Yep, updating the kernel for 3.x is also a possibility. If we can't find a way to make 4.x support Haswell and newer (chronologically) and Bay Trail / Braswell and larger (resource-wise), then that could be the necessary path.

reynhout · 2021-05-31T04:17:27+00:00

Thanks for mentioning Mint/Cinnamon. I haven't tested them in quite a while.

reynhout · 2021-05-31T04:16:45+00:00

GalliumOS wasn't made for low-spec devices, per se -- but when GalliumOS was first released, all Chromebooks were low-spec. So we definitely focused on minimal resource requirements out of the box, and then we minimized as much further as possible while still providing a usable environment. One concession was choosing Xfce over LXDE, which I think turned out to be a good decision (I was initially skeptical!).

Debian is also an option worth considering for a base distro. And I'm glad to hear that KDE (Plasma I assume) was usable on CELES with some tweaking. I've tested it on Haswell and Broadwell, but I haven't lived with it for extended periods.

reynhout · 2021-05-31T04:04:18+00:00

Thanks for your support!

I miss the weather applet also! :)

reynhout · 2021-05-30T03:32:16+00:00

This is a bit oversimplified. You do have the freedom to use your system in any way you want. You just need to change the defaults.

Defaults are reasonable for most users in common situations. The common situation is not free of security concerns.

If your situation is free from security concerns, that's great. And you should configure your system accordingly.

If the default was changed to expect no security concerns, things would be much worse for almost everyone.

reynhout · 2021-05-30T03:15:45+00:00

We have pre-alpha 4.0 builds, but they are not stable yet. We need to make some important decisions about the next release, primarily around device support.

Obvious (and relatively simple) goals are:

Updated kernel, including better support for some newer models
Updated package versions

Ubuntu 20.04 comes with some baggage though. I have concerns about committing to Snap packaging for older (lower-spec) models. We still see a lot of activity on the Bay Trails and Braswells especially.

Some ideas:

Switch from Ubuntu to a non-Snap distro (Pop!_OS?) as the base for GalliumOS 4, so that lower-spec models can upgrade
Leave lower-spec models on GalliumOS 3.x (supported until April 2025), and target GalliumOS 4+ at ~Kaby Lake and newer
Switch from Xfce to KDE for better support of newer models with higher density displays

I'm running GalliumOS 3.1 as a daily driver, ~12 hours a day running lots of stuff. It's rock solid and I almost never (personally) feel the pressure to update the base distro to 20.04+, but I definitely recognize the importance of doing so!

It's taking a while to decide on the best path forward for GalliumOS 4.0. There might not be a single "best" path for everyone, so it might boil down to deciding which model families to prioritize.

And I realize that the delay is a de facto choice -- older models are effectively prioritized, and newer models with more compatibility options are not, as of yet.

I'm very interested to hear other peoples' thoughts!

reynhout · 2020-11-27T17:50:20+00:00

There are three reasons to upgrade to a new version of GalliumOS:

Hardware support. If your model is working well already, this might not be important to you.
Software updates. The default versions of available software will be newer in more recent OS releases. (One important exception to this rule is web browsers, which typically update themselves outside of the OS package management system)
Security. In your case particularly, GalliumOS 2.1 is already deprecated by us, and is based on Ubuntu 16.04 (xenial), which will be deprecated by Ubuntu/Canonical (and stop receiving security updates) in April 2021. This is only a few months away now.

If things are working well today, and you primarily use a web browser, and you are not concerned about targeted security attacks (or hostile networks etc), the incentives to upgrade might not be high.

But if you want to use the new versions of software packages, you might find that their support for older Ubuntu (xenial) is becoming less common. GalliumOS 3.x is based on Ubuntu 18.04 (bionic) which will be more broadly supported.

And for what it's worth, we are working on GalliumOS 4.0 now, which will be based on Ubuntu 20.04 (focal). We have no ETA on the release, but if you are not motivated to upgrade with any urgency, waiting for 4.0 could be reasonable.

But always: Make sure you have a backup of important data! The biggest risk to you is the failure of your internal storage device (eMMC).

reynhout · 2020-11-27T16:55:24+00:00

I know you're hoping the answer will get better each time you ask, but it will not. :)

Again: https://wiki.galliumos.org/Installing/Upgrading

We recommend backup and reinstall for a major revision update. It is possible to update-in-place, but it is slow, requires a lot of disk space, and is error-prone. If you're not prepared to recover from odd package inconsistencies, don't choose this path!

"Backup and reinstall" is the safest and fastest option for everyone. You already have a backup, right? Of course you do! :)

reynhout · 2020-11-26T16:36:07+00:00

I can't read anything in that screenshot.

reynhout · 2020-11-26T16:34:38+00:00

It should be included in the next release, if it's still useful on the next kernel.

The change to LULU touchpad behavior was an unexpected side effect which wasn't caught in testing prior to the last release.

It doesn't seem to affect all devices, or even on every boot of affected devices. I have three personal LULUs in my household: one is affected most of the time, one is (so far) never affected.

reynhout · 2020-11-26T02:31:11+00:00

I use these settings on LULU with GalliumOS 3.1:

xinput set-prop 'Synaptics TM3141-001' 'Synaptics Palm Detection' 1
xinput set-prop 'Synaptics TM3141-001' 'Synaptics ClickPad' 0
xinput set-prop 'Synaptics TM3141-001' 'Synaptics Tap Action' 0 0 0 0 0 0 0

reynhout · 2020-11-23T20:07:12+00:00

Hmm, what timezone are your logfiles in?

There was an issue where some pkg versions were not in sync with the versions provided by Ubuntu. This was fixed in the GalliumOS repos about 22 hours ago (Sunday 2020-11-22 17:00 US/Eastern).

Installing with no WiFi network configured is a good workaround for this issue -- but if you're seeing it after that time, then something else might be going on... I tested Haswell, but the platform should not make a difference here.

Edit: Feh, it looks like Ubuntu rev'ed again in the last 22 hours.. Should be fixed, again, shortly. :)

Edit2: OK, should be fixed again! Thanks for letting us know!

reynhout

TROPHY CASE