🔎 If you see an alert for analytics.usips.org, this is a self-hosted system I am running as a test. It is GDPR compliant and collects no invasive information.
Want to keep track of this thread?
Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading. Create account
I’m not paying to use the AI so I only get about an hour or so and then it locks me out until the next day, and I do some independent research and problem solving until I get stuck. As I go on I’m getting a better idea of what python code looks like and I can make adjustments here and there, and once I have something that is fully functioning I intend to go through and add comments to all the code to ensure I really understand what is doing, possibly find things that are clunky and can be done better. Then I can post it online and get independent advice which might be harsh but useful.
The AI is telling you do exactly what I would tell you to do (use i3wm) so the AI is clearly correct.
A couple suggestions for you (or anyone doing the same thing):
* the 'aider' command line tool is very convenient for working with small projects in a efficient way, where the incremental code changes are not too extreme to manually review and you can manually QA everything yourself. It defaults to straight up making changes, so you likely want to use the /ask command to make plans before making big changes and may want to turn off autocommit.
* are you using OpenRouter? If not, you should be (in addition to whatever else you're using- and aider makes switching between endpoints and models easy). And, while this may not last for very long after they succeeded in selling their massively-money-losing-Uber-of-AI-routers to Stripe, if you are currently hitting the 50 request per day limit on OpenRouter, you should be able to bring that up to 1000 requests if you deposit just 10 USD with them. You don't have to actually spend any of that money on non-free models unless you want to, you can just rape the fuck out of the free ones. You might need to spray things out across a few different free models if you're really hammering it, but it's a pretty generous allocation.
I’m currently in the process of making that window launch every time as a floating window, seems the older way of doing it was depreciated in gtk4 so now I’m looking at i3 specific api calls.
Each monitor gets its own set of workspaces shared from the global pool and you can move workspaces between monitors. So e.g. if you start up with two monitors you'll have workspace 1 on the first and workspace 2 on the second. Switching focus to a workspace also jumps your cursor to that monitor. You will need to do something custom to handle live plugging and unplugging.
@ProudSkibidiTolietAryan is the true hegemon of the Linux thread. Rock on dude. The sooner you prove that BIOSes can be emulated, the sooner someone else with a stable disposition can redo libreboot.
I should clarify that not once did the AI suggest i3. All it did was agree with me when I considered switching to something that would simplify the system from an entire fork of a DE to a handful of python files. It would push back on things that were blatantly wrong, but it not once suggested an alternative solution that would be better.
I've recently set up Void on bare-metal and the performance is genuinely fantastic even with glibc instead of musl. Managing services with symlinks is easy and straightforward, the xbps package manager is really snappy compared to zypper, dnf and arguably even pacman. Really makes u wish more distros went with runit instead of systemd tbh.
I've recently set up Void on bare-metal and the performance is genuinely fantastic even with glibc instead of musl. Managing services with symlinks is easy and straightforward, the xbps package manager is really snappy compared to zypper, dnf and arguably even pacman. Really makes u wish more distros went with runit instead of systemd tbh.
void also idles at like under 500mb ram even with services and desktop added to make it a normal linux desktop
systemd shouldnt on paper create almost any overhead and this is supported by minimal artix installs vs minimal arch installs being about on par idle wise
theres benefits to running alt inits but the performance benefits youre getting on void arent due to runit theyre due to void
Daily driving Fedora is such a strange and surreal experience because... beat for beat, controversy for controversy, I should hate the Red Hat family far more than Debian and its countless clones, derivatives, and variants. But the reality, at least in export $CURRENT_YEAR="2026" is that... the Red Hat world, relative to the utter lunacy of Debian + Ubuntu + all their clones, fairly comfortable to live out of. Unfortunately, every legitimate praise I have is overridden by an annoyance, an inconvenience, or something I patently object to on principle that I come across not too long after.
One such annoyance that I wanna whinge about at length is this Fedora Magazine article about setting up Navidrome via Podman and Podman Compose. But first, some context.
If you're unfamiliar with Fedora Magazine, lemme break it down for you: Firefox on Fedora is set by default to open Fedora Start. It's basically the distro project's main "hub" of information. There's actually some really cool shit buried in there, the problem is that Fedora Magazine articles take up the core screen real estate, and Fedora Magazine is, to phrase it charitably, "total dogshit ass." Imagine DistroWatch Weekly, where Jesse Smith got replaced by some random, self-aggrandising douchebag of the week, who writes a 500+ word "article" that still manages to be technically correct and genuinely fucking wrong.
If you wanna know how far removed Fedora Magazine is relative to the stuff that actually matters (re: release engineering, packaging, etc), this official SVG organisational chart shows that Fedora Magazine is squarely a community-focused effort stewarded by the Fedora Mind Share team. Frame it like this: only the legal team nested within the Fedora Council, and the Fedora Engineering Steering Committee (re: where the developers actually exist) provide any genuine substance. Everything else is, for all intents and purposes, abject fucking drivel.
The Fedora Mind Share Committee is basically a cancer that metastasized once the gatekeepers were eradicated and "community" took root. It looks impressive, but very quickly, you'll find that it's all basically a facade in the worst ways possible. "Special Interest Groups" sound impressive. Like "oh hey, a bunch of users are autistic enough to talk at length about this topic," but they lack any meaningful expertise or institutional sway. They're basically groups of random jackoffs from the community who stroke their egoes as the self-professed "experts."
Earlier this year, CopyFail, DirtyFrag, and so on prompted someone from the Fedora Security SIG to write this article. I will give you the TLDR: it's like 600ish words of sterile, AI-proofread rubbish that could reasonably be boiled down to "The Fedora Project tracks kernel development and updates very closely. These kernel exploits were already patched out in the most recent kernel updates that users received. As always, please remember to run sudo dnf --refresh update -y to receive the latest security fixes for all installed packages."
Except the author got it catastrophically wrong by instructing users to use dnf upgrade --security. Why is it catastrophically wrong? Because dnf --refresh update -y updates the repository metadata and fetches the latest updates (including critical security updates), erstwhile dnf update --security only fetches the most recent critical security updates. The former more or less updates the entire system. The latter is, by definition, a partial system update which significantly increases the risk of breakage.
Mind you: the Fedora Security SIG sounds impressive and authoritative, but it's not the developers who package security updates in that special interest group. It's full of random douchebags like you and I who think they're experts but are manifestations of Dunning-Krueger in its purest form. I would certainly hope that Fedora developers on Red Hat's payroll know better than to advocate for partial system upgrades on a fast-paced, rapidly evolving Linux distribution because this type of mistake would warrant formal disciplinary action if a Red Hat employee got it so catastrophically wrong while acting in Red Hat's official capacity.
But I digress. There's genuinely good stuff within Fedora but there's absolutely nothing of substance from any community space under the Fedora Mind Share Committee's grasp. Fedora Magazine is merely their self-aggrandising mouthpiece, and the purest distillation of why gatekeeping is ultimately a good thing in hindsight.
Circling back to the Fedora Magazine article about Navidrome and Podman... this isn't so much a point by point refutation of Podman and Podman Compose vs. Docker. Rather, I sincerely appreciate the proactive approach to SELinux with standalone Podman, instead of blindly charging ahead and then getting pissy once something's borked. However, there are two critical flaws that make me go from sincere appreciation to genuinely fucking pissed.
1. The author only explains how to get Navidrome up and running under Podman or Podman Compose. They absolutely do not explain command syntax, systemd quadlets for persistence, the caveats of doing this on a Fedora Desktop release or Fedora Server because security defaults differ significantly between the two, and most crucially: Firewalld zone methodology for home server contexts. Seriously, what the hell?!
2. The author completely and utterly fails to explain the benefits and trade-offs of Podman and Podman Compose, and glaringly omits how Docker and Docker Compose actually exist on Fedora. Not even as RPM Fusion packages, no, there are official packages for Docker, Docker Compose, and extensions for Podman that emulate docker-cli (among other such things).
This guy literally states "Whether your hardware is a standard x86 PC server or a low-powered ARM-based Raspberry Pi, this walk-through has you covered," and I just wanna point and fucking laugh because running Fedora on a Raspberry Pi is the easiest way for you to wipe your shit and reinstall the latest version of Raspbian. Why? Because the whole Fedora Pi experience is so fucking half-baked and poorly integrated with the wider Pi ecosystem. Not to mention that Firewalld in itself will make or break your Podman experience depending on whether you're using Fedora Desktop or Fedora Server. The former has many more ports open by default, Server literally has everything locked down and requires you to familiarise yourself with zones, otherwise you're gonna be manually opening/closing your ports with firewall-cmd
But again, I digress. That's a wholly different screed for another day and another time.
Waybar is fine for most if not everyone (if you're willing to settle for "less"), it has some issues here and there (like somewhat inconsistent features per compositor but that's probably more an issue of the compositors more than waybar itself) also from my experience it's really lightweight. (like less than 15mb of RAM)
Quickshell can be really simple or some of the most complicated barely usable bar you're gonna see it's also heavier than you'd expect (my personal config uses ~220mb of ram for a bar that's basically dwm's top bar with a system tray but to be fair to myself, I am a braindead retard that had never touched qml before), from my admittedly light experience with pre made Quickshell configs like DMS are fine if not great for the person that doesn't want to spend a night your free time for a week or two making your config a bit better.
Necroreplying here, but KDE actually spearheaded the DHH approach that the niccolo freak is badmouthing with Blue Systems founded/funded by some german meat lord.
Niccolo is a retarded noob and the fact that the KDE community has let him pretend to speak for them is a shame.
I should clarify that not once did the AI suggest i3. All it did was agree with me when I considered switching to something that would simplify the system from an entire fork of a DE to a handful of python files.
LLMs are famously sycophantic, so of course it would agree with you.
And Python seems completely redundant in your project, tbh., like someone else pointed out you can achieve your goal with a single line in the i3 config (the matching machinery and commands it can run is pretty powerful, and if it's not enough patching i3 is pretty easy as its a tiny well-structured project).
the #1 difference you will notice is that any precompiled software binaries you download from the internet wont fucking work if you dont have glibc
normally this shouldnt be a problem because you shouldnt be doing that but theres always that one case where you need it and get fucked
Well look what i got.
For reference the source code to AMI's UEFI leaked in 2013, Ive rebuilt it and gotten it working on QEMU's q35. Even better ive added some features to it
-Made the setup match the QEMU logos color-scheme
-String changes
-Added the ability to use either AMI's own legacy CSM or you can use Seabios, all at the flick of a menu option for legacy booting, yes it supports legacy and UEFI booting
-A smbios editor where you can change SMBIOS information(This is coming soon)
-Supports pretty much every QEMU -cpu option
-Serial Debugging enabled
-Custom Fullscreen logo
-Some Custom Menu options
-The ability to change the colors of the setup in RGB via the source code
-Theoretically this should support GPU passthrough just fine or even better.
-This has much better booting support even in legacy mode than Seabios or OVMF.
(No I do not use gentoo by the way, Its just that gentoo provides images that are UEFI only in the form of "Cloud" images. Which is great for testing)
0:50
Anyways though I want to go over something in this leaked source code. Something that may blow your mind. There are multiple UNRELEASED INTEL platforms and CPUS in this source code.
I want to show you the structure of the first file containing unreleased intel platforms
Now this is a REAL intel platform. You see that "HuronRiver"? That is a real intel platform. For the help item it goes "Platform name - Testing Board name"
Now on to the unreleased Intel platforms
First off "Intel EDOM" this is a intel platform that has never been released and never mentioned anywhere in this code other than this Acpiplatform file(This is normal, the same applies to released intel platforms in this code ) Intel EDOM.. a Unreleased intel platform.
Another one is "HermosaBeach"
Again unreleased and for nobody has known this. NOBODY on google has ever mentioned such a thing, We are the first people ever to be looking at this. NOBODY has ever heard of these intel platforms before,
Well I know what your thinking "That's great and all but where are the unreleased CPUS." Well I got good news... and even better news. We not only have said CPUS but we have the MICROCODE for it !.
Before I talk about the unreleased CPUS, These unlike the platforms HAVE been mentioned by intel as being cancelled and will show up on google when you well, google them(Nobody has ever held such a physical CPU before still as it was cancelled, nor did we know anything other than "it was cancelled") so nobody's ever seen them before so its still going to be cool. first unrealized CPU HAVENDALE
Now we have more, and its STEPPING label. Now what is a stepping label. A stepping label is basically a "Alpha" "Beta" type label for processors. Starting with A0 and gong to A1 or A2 or B0.
And look there is the microcode for the unreleased havendale CPU
Now one thing about Microcode, every microcode since the pentium has been encrypted. when you install a mircocode update on your computer, that file is encrypted.(Some people have once been able to see CPU microcode on a modern intel processor, check out this https://www.researchgate.net/public...ineering_and_Customization_of_Intel_Microcode
But anyways while we can't read said microcode, I can say, if you HAVE a unreleased havendale processor, you can stick this microcode into it and it would work just fine.
Check the attachments for "M13106F1_FFFF0007"
but BIG news about Havendale.
Do you Remember Windows 8? I know this seems like a complete LEFT field. However what if Microsoft was not blindly guessing that Tablets were going to be the future, but were told via Intel that they are going to have CPUS work on mobile/laptop platforms with ridiculous claims. I mean this wouldn't be new for Intel, they once claimed that they would achieve 10ghz in the 2000s.
Anyways Havendale has a DUPLICATE microcode file in the MOBILE mircocode folder, there is one in the desktop AND the mobile folder. Now this could be a fluke(It won't be as I later prove), But this might imply that Havendale was more than what we thought and maybe a HYBRID mobile/desktop CPU, If intel was making stuff like that, Maybe Microsoft was not just "Blindly guessing" that the future would be tablets(Which we all know now was wrong) But were told by intel internally about such future. Anyways just a theory.
Anyways what about the other unreleased intel CPU.
Well the other cpu is a MOBILE cpu(Which might i say kinda strengthens my theory)
"Auburndale" and of course check the attachments down below for its microcode. Wait you may be thinking, there is only ONE .pdb attachment. So what the hell are you babbling about.
Well. your not gonna believe this, but BOTH Havendale AND Auburndale use the SAME microcode. And we know that this isn't just a stub CPU that AMI didn't get to test because for Havendale at least there are multiple versions or different stepping numbers. So that means that Auburndale is a mobile clone of Havendale with the same microcode, Which makes sense why there is a duplicate in the mobile folder as that is suppose to be "Auburndale" and not a "Second Havendale" however.. it might as well be a second Havendale as the Mirocode is the exact same. I did a md5sum on both the desktop and mobile one and they came out the same.
So what else is in this source code.
Well there's some references to insider/dev versions of Windows 8
Which you can view what that exact development build of windows 8 looked like if you want to go down a rabbithole today https://betawiki.net/wiki/Windows_8_build_8039
First off the logos been cleaned up but also KVM support now works. when booting up under KVM mode the logo turns blue to indicate KVM(KVM takes longer to start up due to reasons outside my control)
Vs when running it WITHOUT the -enable-kvm flag
Second off their is a serial log that shows up immediately on the VGA that shows everything its doing, So in case it hangs, you will know exactly why instead of seeing a "Host has not initialized the display yet. message
(Booting under non kvm and under kvm. you can see that KVM takes alot longer to boot, however everything after the BIOS will not be as slow as this, its because of reasons outside of my control at the moment)
0:51
Before the BIOS shows the logo it pipes the output of the serial console which is used for debugging and puts it to the VGA screen initializing a emergency display.
If you mess something up like not giving it enough ram, normally you would see a black screen or endless reboots endlessly. My System will now will tell you what went wrong and how to fix it.
(You need at minimum 256mbs of ram to boot)
I didn't show this in the previous post as well but in the setup you can choose if you want to use seabios or if you want to use AMI's legacy boot(For older versions of Windows NT. AMI is better and fix things that seabios sometimes breaks. Otherwise Seabios is the faster choice for legacy boot)
as you can see you can select which option you want by selecting it in the bios or as a commnad line argument to your qemu config.
if you want to try it out you can do so here
just add -bios ./latest.rom -machine q35 that is all it needs.
(It does not work with QEMUS 440fx chipset from the 90s. But for most people they are already using -m Q35. )
once the fullscreen logo shows up hit DEL to go to the bios options
Tacoma Falls = Intel's customer reference board. These CRBs sometimes show up for sale if they were sold to a e-waste recycling center. Old marketing slides used to mention these boards with Ivy Bridge U CPUs like the i7-3667U running in them. They used to be available for purchase, but only if you were an OEM involved in designing and producing motherboards.
STHI PPV = Standardized Test Hook Initiative Processor Platform Validation
This pretty much confirms that this board is a CRB.
First off "Intel EDOM" this is a intel platform that has never been released and never mentioned anywhere in this code other than this Acpiplatform file
This looks like an internal identifier for something else, doesn't look like a platform.
Oneonta Falls = Another customer reference board. It supports Sandy Bridge CPUs and is a PGA988B test motherboard.
Ecola Falls = Same as above, no info about it though. I don't think it's anything special.
The microcode actually exists in most Arrandale (mobile) and Clarksdale (desktop) motherboards. They're leftovers from testing, but they do work. Through old ass Intel documents and leaked schematics
Auburndale's part number is Q1Q7/Q2CZ
Havendale's part number is Q2BK
Auburndale needs a PGA988A motherboard to boot, Havendale needs an LGA1156 motherboard to boot.
Collectors had it in their hands for several years ever since they leaked out of Intel's contractors who were told to scrap it or Intel employees who had them for some reason. In fact, Auburndale was sold on eBay a few months ago. Most of these CPUs ended up in China for some reason.
Havendale can't be a hybrid mobile and desktop CPU because its substrate is built for LGA1160, not PGA988A. For that to work, you'd need an interposer which Intel has never done for mobile CPUs since the Mobile Pentium III days. In the case of the PGA615 mobile P2 and the PGA495 mobile P3, it was a BGA substrate soldered on a PGA interposer.
Now we have more, and its STEPPING label. Now what is a stepping label. A stepping label is basically a "Alpha" "Beta" type label for processors. Starting with A0 and gong to A1 or A2 or B0.
The boards are unreleased because they're not intended for average joes to use. That particular CPU was unreleased because Intel needed power consumption lowered for better battery life and were confident that their 32nm fabs wouldn't be delayed by a year.
The boards are unreleased because they're not intended for average joes to use. That particular CPU was unreleased because Intel needed power consumption lowered for better battery life and were confident that their 32nm fabs wouldn't be delayed by a year.
Oh. Im curious why Auburndale and Havendale have the same microcode assinged. There both duplicated files one in DESKTOP and one in MOBILE and match the same hashes.
Guess i was wrong there.
Now here is the thing. You say Hermosa beach is not a intel platfor(which im not arguing at this point) m. However if you look at the HELP menu in the file that contains Hermosa beach
You can see a obvious pattern.
The first word in the string is the Platform name.
So when we look at Hermosa beach and see that in the same file as all the other examples ive shown you.
We can see it follows that same pattern, Except that, The platform name and boardname all in this case. Are both the same? So that causes immediate confusion? Nothing else follows this standard.
We at least know EDOM is a unrealsed intel platform or something that turned into a different released platform by the fact its directly told its a platform it seems
Another thing is that this bios was leaked during the IVY bridge era. It does not have any CPU references/leftovers for even the basic name of Haswell.I am not saying your wrong, you are absolutely right that its NOT a intel platform. However its worth noting that Haswell is not even mentioned in the entire source branch.
I really wonder where this info comes from
Google tells me that
OK so it may not be a platform. Ok so lets sit down and talk about what we do know
Hermosa beach belongs to the Haswell platform. Despite being a ivy bridge codebase and showing up in intel benchmarks up to 2015.
Hermosa beach is defined as not just a platform but also a board. "HermosaBeach - HermosaBeach CRB No BMC Board ID for ASL code." if it ran on the lets say "Sugarbay" platform it would have that, but both the Platform name and boardname are the same indicating that they are different/something is DIFFERENT with this platform.
Haswell only supports up to broadway via a Bios update. Its completely different
Name(FMBL, 0x1) // Platform Flavor - Mobile flavor for ASL code.
Name(FDTP, 0x2) // Platform Flavor - Desktop flavor for ASL code.
Name(FUPS, 0x3) // Platform Flavor - UP Server flavor for ASL code.
Name(FUWS, 0x4) // Platform Flavor - WorkStation flavor for ASL code.
Name(BSH, 0x0) // HuronRiver - Six Hill Board ID for ASL code.
Name(BEL, 0x1) // HuronRiver - Emerald Lake Board ID for ASL code.
Name(BEH, 0x2) // HuronRiver - Elk Hill Board ID for ASL code.
Name(BRH, 0x3) // HuronRiver - Rainbow Hill Board ID for ASL code.
Name(BTF, 0x4) // HuronRiver - Tacoma Falls Board ID for ASL code.
Name(BHC, 0x5) // HuronRiver - Hill City Board ID for ASL code.
Name(BYB, 0x6) // HuronRiver - Yellow Bluff FFVS Board ID for ASL code.
Name(BPH, 0x7) // HuronRiver - Painted Hill Board ID for ASL code.
Name(BSHS, 0x8) // HuronRiver - Six Hill STHI Board ID for ASL code.
Name(BELC, 0x9) // HuronRiver - Emerald lake STHI CPV Board ID for ASL code.
Name(BRHP, 0xa) // HuronRiver - Rainbow Hill STHI PPV Board ID for ASL code.
Name(BTFC, 0xb) // HuronRiver - Tacoma Falls STHI CPV Board ID for ASL code.
Name(BEHP, 0xc) // HuronRiver - Elk Hill STHI PPV Board ID for ASL code.
Name(BPHS, 0xd) // HuronRiver - Painted Hill STHI Board ID for ASL code.
Name(BELP, 0xe) // HuronRiver - Emerald lake STHI PPV Board ID for ASL code.
Name(BTL, 0x10) // HuronRiver - TinyLake Board ID for ASL code.
Name(BTFP, 0x11) // HuronRiver - Tacoma Falls STHI PPV Board ID for ASL code.
Name(BSR, 0x14) // HuronRiver - Slim River Board ID for ASL code.
Name(BOF, 0x20) // Edom - OneontaFalls Board ID for ASL code.
Name(BEF, 0x21) // Edom - EcolaFalls Board ID for ASL code.
Name(BLLE, 0x22) // SugarBay - Los Lunas EV Board ID for ASL code.
Name(BLLC, 0x23) // SugarBay - Los Lunas CRB Board ID for ASL code.
Name(BLCA, 0x24) // SugarBay - Los Lunas CPT AIO Board ID for ASL code.
Name(BLLS, 0x25) // SugarBay - Los Lunas CPT STHI Board ID for ASL code.
Name(BLLP, 0x26) // SugarBay - Los Lunas CPT PI Board ID for ASL code.
Name(BLLD, 0x27) // SugarBay - Los Lunas CPT DOE Board ID for ASL code.
Name(BHBE, 0x30) // HermosaBeach - HermosaBeach EV Board ID for ASL code.
Name(BHBC, 0x31) // HermosaBeach - HermosaBeach CRB Board ID for ASL code.
Name(BHBN, 0x32) // HermosaBeach - HermosaBeach CRB No BMC Board ID for ASL code.
Name(BHBM, 0x33) // HermosaBeach - HermosaBeach CRB ME S0/S1 Board ID for ASL code.
The file is dated Jan 4 2012,23:38:40
HermosaBeach appears to be a server platform, which aligns with haswell.
https://bugs.gentoo.org/982204 -- OMG Gentoo is dropping Chromium from the main repo because Google's release cadence is so insane no one can stay on top of it.
https://bugs.gentoo.org/982204 -- OMG Gentoo is dropping Chromium from the main repo because Google's release cadence is so insane no one can stay on top of it.
Possibly it has to do with the lack of any usage outside of PGA/LGA sockets. Auburndale and Havendale were never produced in BGA form except for the Auburndale QGFL thermal test vehicle, which never POSTed and only generated heat. I'll have a look at my microcode dumps to confirm this theory, because right now I can see that Arrandale and Clarkdale happen to share the same microcode.
If I can find a BGA microcode for Arrandale, then it makes sense for them to share the same microcode as they don't differ much apart from packaging.
Never showed up in leaked Intel documents which I no longer have, plus the fact it's only referred to as a CRB in public Intel slides makes me think it's really just a board.
Notice the 4L and 8L EVs being defined? Those indicate the amount of layers in a motherboard, EV likely means evaluation vehicle. I see zero references for Hermosa Beach being the codename for a platform. That's why I don't believe in it being the codename for a platform.
Yeah if you assume the definitions are 100% free of typos or placeholders, which I doubt because it looks inconsistent.
Edom for example could be an outdated platform codename that Intel changed midway or it could be the manufacturer of these CRBs, which could be a possibility as Edom is a company and did sell motherboards. I would say this is likely as Intel does not have a motherboard factory and relied on Foxconn to produce their discontinued desktop boards. It wouldn't be surprising if they had a 2nd supplier for mobile boards.
Hermosa Beach being used as a platform codename is probably because it's just a placeholder as no other Haswell CRBs showed up in this leak. Shark Bay was never mentioned, correct?
Looking for some first hand experience or thoughts: I have a few installations of Ubuntu 24.04, and I've been mulling over grafting XFCE on them. I've read conflicting notes on how reliable the combination is, some say it's aces while others say it can be a bit crashy.
Anyone here put the peanut butter in their chocolate and it work out?
