Major version 21.
Minor version 04.
Patch level 3.
Isn’t it more: Release of April 2021, patch level 3?
The Ubuntu release naming doesn’t really follow the normal major/minor conventions - it’s not like 21.04 followed 21.03, after all.
Could be, it really indicates some kind of version, so that proper help can be sought.
This is the Linux way.
What kind of battery life should I expect on Ubuntu 22.04 with the Frame.work laptop and a i5-1240P (12th gen CPU)?
My recollection is the minor version represented the target release month: stable releases are xx.04 and targeted for April, interim releases are xx.10 and targeted for October.
I don’t know how clearly they hew to that now, but I think that’s where those numbers came from…
Close. Yes the convention is YY.MM.patchlevel with releases in April and October every year but it is not as if one or the other is stable. They do mark the April release every other year as LTS (long term support) however so 18.04, 20.04, 22.04, etc are LTS releases which are maintained for 10 years (5 years in general but additional 5 through paid support). All interim releases are stable but only maintained for 9 months.
Your post is almost spot on. It is free for personal use for up to 3 machines or if you are an Ubuntu member for up to 50 machines. Everything else you said sounds correct. Though interim releases can sometimes have new features added which some users find a bit less stable at times. I myself tend to stick to the LTE releases for best stability with my installs.
ESM is also available to personal users on up to three machines and Ubuntu members on 50 machines.
Source …
https://ubuntu.com/blog/ubuntu-16-04-lts-transitions-to-extended-security-maintenance-esm
Digging up an old thread.
Yes, RedHat has a list of certified [laptop] hardware:
https://catalog.redhat.com/hardware/search?p=1&c_catalog_channel=Laptop&rows=60
Framework isn’t currently there.
I wonder how well the 12th gen Intel Framework Laptop would work with RHEL 8[.6] OOTB. I see other brands have their 12th gen Intel laptops already on the list.
Red Hat Enterprise Linux (RHEL) is the downstream of Fedora. I am not sure that RHEL 8’s kernel and library versions are new enough to run Framework Laptop. The RHEL 9 beta is already public: Red Hat Enterprise Linux 9 beta | Red Hat Developer
I have been using UNIX and variants for just under 45 years. I would love to return to FreeBSD, but I am practical person. xxxBSD is a great OS, if you need a server. I have spent countless hours learning the tricks to to try and make Free/Open/Net … BSD work on laptops. It is not worth it IMO.
I chose Ubuntu based in stability, quality and support. Exciting? Nope.
But I need a stable dev environment and none of my work is dependent upon newer kernel features; all I need is up to date Go and Python.
I experimented with a manually installed XFCE build of Debian, but I traded it in for this cave-man method:
- Install Ubuntu (to get 100% of the standard tools)
- Install xubuntu-desktop (to get a working XFCE that auto updates)
- Login to the XFCE environment 95% of the time
- Build new code and pretend it is UNIX
My point is that with cheap disk storage, I can afford to have extra packages installed - and sometimes they are useful. But at runtime, I run lean and light with XFCE.
I am happy that Ubuntu is fully supported - that is what I need.
You might be happy to know that, as of 7.2, the process with OpenBSD is extremely easy, at least with the 11th gen version of the framework. Back in 7.1 you did need to sysupgrade to -current snapshots to get a good experience because of some missing drivers for the included wifi card, but that is no longer the case. So “things that doesn’t work” is now “fingerprint reader” and “bluetooth”, pretty much. (And BT not working on OpenBSD is sort of axiomatic… )
That said, battery life is still comparatively poor to when I have my Arch drive in it, so it’s still a case of “install OpenBSD if what you specifically want is an OpenBSD laptop”. But the process is:
- Install OpenBSD 7.2 (saying yes to xenodm)
- Install your DE/WM of choice or use the included ones
FreeBSD should also be pretty much the same, but I haven’t tried it since 13.1 was in beta. At the time there were issues where you needed to build specific inteldrm from ports to get functional graphics, everything else worked out-of-the-box. I think but have not verified that the correct inteldrm package is now the standard package.
From what I’ve seen, the magic is that Framework actually spent engineer time helping *BSD devs in sorting out issues. Which cannot be said for any other manufacturer I’ve heard of. And, of course, I have no idea of the status for supporting the 12th gen version, and things like updating BIOS will not work while you have a *BSD installed.
Why wouldn’t the process for updating the BIOS work? It’s booting from an external USB, it’s OS-agnostic.
It’s a good question, but I (accidentally) tested this yesterday.
Run the BIOS update stick with my OpenBSD drive installed: “Failed to Update”
Quick switch to my Arch Linux drive: no problem, all good.
My best guess would be that the thing somehow looks for and uses something that is on the drive itself, they do ship separate downloads for if you use Linux or Windows, after all. But as for what precisely: no idea. But if forced to guess: perhaps the thing has some checks in place to try to make sure it doesn’t mess up your boot entries or something like that, and when it sees OpenBSD it has no idea what that is, therefore cannot ensure it didn’t break anything, and fails?
@Daniel_Agorander [Daniel_Agorander]
Thanks for the info - I appreciate knowing this an option. I really prefer an actual UNIX environment. But, as I said above, on Laptops, I can usually make FreeBSD work, but only after more than a dozen tweaks. The FreeBSD project simply does not have the staff to make all the different hardware options work out of the box.
For now, I will stick to Ubuntu overlaid with Xubuntu. That is giving me the CPU/GPU support and performs well. I am very fussy about what I install.
Other than development, 90% of what everyone does now is both online and in a browser. (I don’t game, for example.).
I do hope to find some time over the Holidays to kick the tires of FreeBSD on my new laptop (assuming it arrives ;-).
Bluto
Sounds like you’ll (hopefully) have some great holidays.
For things like this, it is very nice that the Framework is so easy to open up and work in. Captive screws, standard (and included!) screwdriver, no pesky plastic clips in the chassis… So the way I use mine, I have a 1TiB NVME with Arch Linux in it most of the time, and a second 512GiB NVME with OpenBSD. Takes me 3 minutes (if that) to swap them out. (I do play recent games a fair bit, so I did give Linux the bigger of my drives.)
For me, this was the machine where I started trying out some BSDs outside of VMs, after reading reports that it actually worked fairly well (including a detailed blog post somewhere on the specific work that was done with some support from Framework to get screen and touchpad to “behave” in OpenBSD). Compared to trying to get FreeBSD to behave on my desktop computer, it was actually pretty easy. (Perils of having a gaming-oriented an quite new Nvidia graphics card…) And way easier than any other laptop I’ve even heard of that isn’t quite old.
I suspect Framework’s decision to consciously pick as many parts and chips as possible that are “known good” on Linux has paid dividends for *BSD users in this case. Since Linux was supported, it was “just” a matter of the FreeBSD project making a new intel-drm-kmod package based on a Linux upstream and then it works, etc. (Similar for WiFi, where apparently FreeBSD project went with the “use Linux as upstream” route, while OpenBSD just made their own and was therefore slightly slower to get working ones out. But on the other hand, OpenBSD was faster with getting working graphics drivers into the shipped version.)
The EFI partition (on the internal drive, I assume) is actually used by the stand-alone BIOS updater. For me, it first failed and then, when I made more room by removing the remants of a Windows install from the EFI partition, the update worked. So if “switch to Arch Linux drive” means “swap NVMe” then difference in EFI partition size (or at least free room) between the drives may explain success/failure.