DCKing

I wouldn't automatically prefer any random N100 mini PC over a nice second hand enterprise mini PC.

In home server use cases, mini PCs stay idle the vast majority of their runtime. So it's idle power consumption that is the most useful metric to look into. The N100 can have great idle performance in theory, but most data I can find about N100 boxes is them idling in the 12W-15W range. This is something that older enterprise mini desktops have no trouble matching or beating [1]. Especially since roughly the Skylake era (Intel 6th gen), idle power consumption for enterprise PCs has been excellent - but even before then it wasn't bad.

Enterprise vendors like Dell/HP/Lenovo have always optimized for TCO and actually usually use quite high quality power supply circuitry, whereas most N100 mini PCs tend to be built with cheaper components and not as optimized for low power usage for the whole system.

[1]: I recommend reviewing Serve The Home's TinyMiniMicro project, which often finds the smallest enterprise PC form factors to idle at 8 to 13W, even older ones. Newer systems can get below 7W! https://www.servethehome.com/tag/tinyminimicro/

The Shield TV has had an impressive support lifecycle for an Android device but it still falls well short of a 10 year support cycle.

The Shield was released in May 2015 and its latest software update has an Android security patch level of April 2022 and was released November 2022. No more updates seem to be forthcoming. Notably, all Shield TVs today are vulnerable to remote code execution when displaying a malicious WebP image [0], a widespread issue uncovered last year.

Apple released the Apple TV HD two months after the Shield TV, but it still receives the latest tvOS updates to this day and will be receiving this year's new tvOS 18 [1] [2]. It received a fix for that WebP issue the same day as supported Macs, iPhones and iPads did last September.

Even the best Android device examples with good vendor support still seem to be falling short. The Shield TV is still capable streaming hardware in 2024 used by many people, but it's sitting there doing that while missing important security patches unbeknownst to the users.

[0]: https://blog.isosceles.com/the-webp-0day/

[1]: https://www.macrumors.com/2024/06/10/tvos-18-compatible-appl...

[2]: To be fair it's the only Apple A8 device that receives support until today. The iPhone 6 with the same chip was launched mid 2014 and received its last update in early 2023.

In 2014, the Debian project cited accessibility [1] as a main reason to offer Gnome as the default desktop. Since that was over 9 years ago, a lot could have changed. However, observing that Gnome is generally the most well funded Linux desktop, and is sponsored by/the default for Red Hat Enterprise Linux [2] that has large incentives to meet government accessibility regulations, there's a good chance it is still ahead.

[1]: https://salsa.debian.org/installer-team/tasksel/-/commit/dce... (they cited systemd integration too, but that situation has probably changed a lot since then)

[2]: It is also the default on other enterprise Linux vendors, such as Ubuntu (albeit customized) and even major KDE supporter SUSE uses Gnome Classic mode as the default for SUSE Linux Enterprise Desktop

Other emulators want to solve the problem generically, and this solution doesn't quite.

Static recompilation from one machine language to one other language is somewhere between extremely difficult to not being generally possible in practice [1]. To make recompiling something like this properly, you need some help from the binaries that make recompilation easier [2] and on top of that you need to patch certain things to make this work [3].

Dynamic recompilation doesn't have this problem. It allows you to create software you can dump the original binaries+assets ("ROMs") in and it will generally emulate it.

There's a lot of confusion about how generic this solution it. It's extremely impressive in how much work it saves making recompilations/"ports" much easier, and it will be very valuable. But it is not able to replace the need for traditional emulators.

[1]: https://cs.stackexchange.com/questions/155511/why-is-static-...

[2]: N64 game binaries may happen to avoid a bunch of things that make general static recompilation hard that help this approach, but I don't actually know.

[3]: The Majora's Mask recompilation repository contains a lot of handcrafted patches to make it work: https://github.com/Mr-Wiseguy/Zelda64Recomp

The iPad App Store is perhaps an even more dysfunctional place than the iPhone in how much it holds hardware and use cases hostage to the manufacturer's vision. Just imagine how much more versatile the iPad Pro would be if only you could run Linux VMs on it in the moments you want to do anything remotely tinkery on an iPad.

Apple's hardware since the 2021 iPad Pro (with M1) has had the ability to do this. The iPads have the RAM (16gb on higher storage models), appropriate keyboard and trackpads, the works. Great hardware being held back by Apple's vision people weren't allowed to deviate from.

A straightforward reading of the DMA suggests that Apple is not allowed to restrict apps from using hardware features. Let's hope that means Parallels/VMware style VMs are possible without too much of a fight.

> That statement was based on the old text, correct?

Yes it has. The updated text was published on December 20th [1], and does a lot to address these concerns. See also Bert Hubert's analysis [2].

The amount of knee jerking in the comments for this law really brings down the quality of discussion and detracts from remaining issues.

[1]: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CONS...

[2]: https://berthub.eu/articles/posts/eu-cra-what-does-it-mean-f...

Matrox and 3dfx never came close to making general purpose GPUs, they just got completely outcompeted in the regular PC graphics market of the late 90s. Matrox and 3dfx last tried to compete on architecture in 2002 [1] and 1999 respectively, while the first GPUs capable of general purpose computing were released many years later at the end of 2006 (by Nvidia) and mid 2007 (by AMD/ATI). High performance GPUs have been a completely Nvidia and AMD/ATI affair for two decades until Intel entered the fray last year, since before people even conceived of GPGPUs.

Matrox and 3dfx were gone before they could even conceive of a general purpose GPU strategy.

[1]: The Matrox Parhelia itself being out of date tech on release to boot, lacking a Direct3D 9.0 class architecture that ATI launched two months later.

It's not as dire as you think :) Gimp should get Wayland support automatically when they complete the move to Gtk3 (which supports Wayland, Gtk2 does not) and the betas already support Wayland [1]. Enlightenment has clear plans for a Wayland mode [2]. Xfce has stated they'll support it too of course, but it's the largest change they'd be making in decades so it's understandable they're cautious. Maybe the momentum will have people get involved for Xfce, I'm pretty hopeful for all projects.

[1]: https://www.phoronix.com/news/GIMP-2.99.2-Released

[2]: https://www.enlightenment.org/about-wayland

Worth noting that Firefox has run on Wayland by default on Fedora for many, many years at this point because the Fedora team patched it to do that. Firefox also uses Wayland on the default RHEL9 desktop and its derivatives, and it's been quite easy for power users to enable it in other environments. So it's quite well battle tested.

I am sensing a large momentum for Wayland in the Linux community though. Finally there is maturity for Wayland in KDE, there is very strong commitment from various projects to default to Wayland (this being one of them). Traditionally more conservative projects like Cinnamon and Wine are finally adopting Wayland too. It seems critical mass has been achieved to get things really moving in the community, and it's about time.

What layers do you mean that would remain?

I wouldn't expect the experience to be identical nor quite as accurate [1], but if audio and input latency could be made indistinguishable between a Raspberry Pi and a Mister FPGA that would already be quite a significant feat :)

[1] FPGA emulation is not intrinsically more accurate, but most Mister cores are considered to be more accurate than popular Retropie cores.

One of the key advantages of FPGA retro game emulation is its low overhead processing input and audio. This is because the FPGA emulates hardware directly and doesn't have to go through OS abstraction layers built to accomodate multitasking.

I wonder if bare metal emulators can achieve similar latency for software emulation.

> What is mind-boggling to me is that it includes an actual, physical, hardware Gameboy Advance CPU in it for when it's playing Gameboy Advanced games.

The reasoning why as pointed out by the article makes it even more mind-boggling to me. It includes the GBA CPU almost by accident, because Nintendo took a Matroshka doll approach to backwards compatibility.

The Nintendo 3DS contains the entire system architecture of the Nintendo DSi for backwards compatibility (the DSi CPU also functions as a supervisor CPU of the system), which is mostly an overclocked variety of the original Nintendo DS architecture. The first two Nintendo DS models contained a GBA slot for backwards compatibility and therefore also contain the GBA's original ARM7TDMI. The Nintendo DS also used this as an auxiliary processor for various things. The reason the GBA hardware is there is because Nintendo kept shipping their previous gen hardware in the new generation twice over.

As part of the that Ambassador Program you mention, Nintendo released a boot firmware for the 3DS called "AGB_FIRM" to boot into Game Boy Advance mode (another being "TWL_FIRM" to boot into Nintendo DS mode). If you hack your 3DS today it can be made to load other Game Boy Advance software and essentially achieves perfect backwards compatibility and runs GBA games with perfect accuracy, modulo any GBA peripherals that were popular.

I don't think this is that unfair at all? What people are invested in is Linux desktop popularity. The old Windows vs Linux (desktop) thing. The Linux desktop has somewhat of a muddier definition than other desktops, but it's whatever free desktop stack people use - Gnome, KDE, or whatever other X.org/Freedesktop based stack people use.

If Linux is only popular on Android, Chromebooks, SteamOS, servers, embedded devices it strongly suggests to me that people are perfectly content with using Linux as long as they don't have to use the Linux desktop. (I know it's available on the Deck, but it's not the primary UI for it).

The Steam Linux numbers used to be indicative of Linux desktop popularity. If their large rise now is in large part due to the Steam Deck, that doesn't quite mean that the Linux desktop is getting popular. So it seems this is a totally fair nuance to me?

Oh great! Yeah as you can probably tell from the script I'm using it as a (locally built) container in my own setup. Feel free to pretend it's BSD licensed if that helps :)

Tube Archivist is quite heavyweight as it's meant to do heavy full archiving of YouTube channels and search through positively huge libraries. I'm getting the sense that it's a data hoarding tool, not a casual web video watching tool. I found that I just want to add a few channels to my media library, for which I use Jellyfin already.

For people looking for a more lightweight option of that kind, I run the following script hourly [1]. This script uses yt-dlp to go through a text file full of YouTube RSS urls (either a channel RSS or a playlist RSS works for channels where you're only interested in a subset of videos) [2] and downloads the latest 5 videos organized in folders based on channel name. I watch these files by adding the output folder in a Jellyfin "Movies" type library sorted by most recent. The script contains a bunch of flags to make sure Jellyfin can display video metadata and thumbnails without any further plugins, and repackages videos in a format that is 1080p yet plays efficiently even in web browsers on devices released in at least the last 10 years.

It uses yt-dlp's "archive" functionality to keep track of videos it's already downloaded such that it only downloads a video once, and I use a separate script to clean out files older than two weeks once in a while. Running the script depends on ffmpeg (just used for repackaging videos, not transcoding!), xq (usually comes packaged with jq or yq) and yt-dlp being installed. You sometimes will need to update yt-dlp if a YouTube side change breaks it.

For my personal usage it's been honed for a little while and now runs reliably for my purposes at least. Hope it's useful to more people.

[1]: https://pastebin.com/s6kSzXrL

[2]: E.g. https://danielmiessler.com/p/rss-feed-youtube-channel/

Yeah absolutely - I think this is a relatively recent change for them. The only thing stopping me from doing that is that 1) setting up an OIDC server for personal use is a lot of work I don't necessarily want to do, especially if it's just for Tailscale 2) this announcement suggests they may be working a full passkey setup, which would make that work useless.

Good. I get they don't want to be responsible for keeping user credentials. But requiring permission from a big tech company to manage or access your own networks boggles my mind and made me not use it.

Now if only they supported this for setting up the entire account too, as opposed to additional users only. I hope that's coming.

> Metal itself is the parallel stack, no?

Ah perhaps I interpreted the quote in the wrong way then. At first it read to me as if Apple did their own bespoke compatibility work, but it's a comment about the mostly artificial Apple Silicon GPU / Metal stack that is only available on Apple devices.

I don't care much for it being open source or not, it's just a shame Apple is making attempts to limit its use cases through licensing [1]. It's on brand for Apple and totally expected, but still sad. It's not going to stop a bunch of homebrew efforts springing up around it, but it will likely be enough to stop third party app stores like Steam from opening up a huge game library on the Mac in a straightforward way like what happened with Proton.

[1] The license is probably actually meaningless in a lot of jurisdictions, but it still has a chilling effect for commercial parties using it. That's probably exactly what Apple intends.

> Apple built it's own little parallel gaming stack world that works really well on their hardware

I think saying "its own parallel gaming stack" probably gives them too much credit [1]. Yes - they put in significant effort, but their gaming stack is neither "parallel" to the rest of the world, nor "their own" in any real sense. They seem to have adapted the open source efforts of Codeweavers, Valve, Wine and the broader Linux community put in Proton and achieving Windows games compatibility on Linux with Vulkan. Adapting that for Metal is no small feat [2] but an investment a giant like Apple can easily make without much risks. Don't forget that Wine has always been developed for Linux and macOS (and the BSDs) in parallel too - it was right there for the taking.

[1]: I'm assuming this is a quote sourced from someone who just isn't aware of all the effort being made at the Linux side of thing in the last five years.

[2]: At a technical level Metal and Vulkan are actually similar enough, but there's just a lot of surface to cover and edge cases to get right.

No, I mean slightly patched. The list of patches is included in the Homebrew formula [1].

The D3DMetal framework and its DirectX 12 support are independent of that Wine work.

[1]: https://raw.githubusercontent.com/apple/homebrew-apple/main/...

From what I gather, Game Porting Toolkit is two things - a fork of Wine, and their own adaptation/extension of open source projects for DirectX compatibility. Some observations:

Windows compatibility:

* Windows platform compatibility is achieved with a slightly patched version of Codeweavers' Wine fork - virtually all of the hard work of Windows compatibility has been achieved by the Wine developers and Codeweavers and was already available open source before today.

* Interestingly, Apple is distributing this thing as a Homebrew library. Has Apple ever done this before? [1]

DirectX compatibility:

* In addition, outside of the core Wine based stuff, there's a framework called D3DMetal.framework. This is a DirectX 9-12 compatibility layer akin to DXVK used in Proton as a compatibility layer from DirectX 9-11 to Vulkan. This is what seems to be the game changer here compared to before. Before today, running DirectX on macOS was possible but lost a lot of performance and compatibility needing to go through Apple's old OpenGL support or a third party Vulkan intermediary layer in MoltenVK. This is direct (heh) first party Direct3D to Metal translation.

* Actually, it's more than "akin to DXVK". The D3DMetal.framework contains copyright attribution to DXVK as required under their MIT license. It's quite likely Apple ported a lot of DXVK to Metal. It's worth noting that DXVK itself doesn't support Direct3D 12 though, Proton uses another LGPL2.1 licensed library called VKD3D for that.

* However, D3DMetal.framework is very much not open source itself. Its license is actually very restrictive, seemingly only permitting use for game development/QA use cases. [2]

* The restrictive license seems to make it harder for someone like Valve to use this akin to how they use Proton on Linux in a sanctioned way. Apple seems intent on preventing developers from dumping their games on macOS with just their compatibility layer. It definitely won't stop hobbyists making better tools to continue run Windows games on Macs though.

* The fact that D3DMetal.framework appears to support DirectX 9 and 10 is interesting. No new commercial efforts use those anymore, so that's just there for what? Allowing homebrewers to run their 00s era Windows games?

[1]: https://github.com/apple/homebrew-apple/tree/main/Formula

[2]: It contains a license with the following language - "you are granted a limited, non-exclusive, non-transferable, personal copyright license to (i) install, internally use, and test the Apple Software for the sole purpose of developing, testing, or evaluating video games for use on Apple-branded products".

I wonder if the new Mac Pro's full PCI Express support resolves any limitations that prevents people from using GPUs over Thunderbolt on existing Apple Silicon hardware (this is apparently a hardware limitation).

Although the Mac Pro's PCIe extensibility makes it a pretty mystifying niche product from Apple without providing memory and GPU expandability, once Asahi Linux gets running on there you should be able to not get the full abilities of the latest Vulkan and full OpenGL 4.6 by putting in a recent AMD card. The open source Radeon drivers should "just work" on ARM as they do in the Talos II POWER-based workstation, if they can be stably initialized that is. Heck, Nvidia publishes a binary Linux aarch64 driver and they sound petty enough with Apple to try to make that work.

You could have Asahi Linux running and delegate any not-yet-supported hardware to the 7 PCIe devices it supports. Would be quite a mighty ARM Linux workstation. Again though - only if Apple has the PCI Express support for it.

It's a thought provoking angle you have here for sure. However, am I right that the implication of this direction of thinking is that we should stay with our current ways of doing authentication simply because them being too hard to use puts up a natural barrier? That some of the ways in which they are broken are intrinsically good?

Sure, but it's worth noting that the Cortex X3 in the Snapdragon 8 Gen 2 is _almost_ at the level of the A14 in single core performance, just not quite there. Even if the performance bump is less than promised, they will still equal it.

I did not expect ARM would take so long to catch up with even the Apple M1 or the same core designs in the Apple A14. The Cortex X3 in the current flagship chip Snapdragon 8 Gen 2 still _just_ fails to match the Apple A14 (let alone the A15 and A16), perhaps this little design boost is finally enough to match it.

If Microsoft can get Qualcomm to implement some of the same chip tricks Apple pulled off for x86 emulation performance they can use it for a potentially somewhat compelling laptop package. It's a tough ask though, as Qualcomm seems mostly to just use pretty vanilla ARM designs. And I don't expect anyone but Microsoft to be interested in taking that plunge.

I know there are reasons why Android works like this, but you may not be aware you've been replying to a post where I listed what I missed about Android compared to a regular Linux distro.

Android is highly opinionated to work as a platform for apps on touchscreen devices, but those opinions do add a lot of restrictions compared to other things built on Linux.

> How is Android not fulfilling your needs as a full Linux distro?

I mean there's a lot of things that make life difficult with Android.

* If you want most hardware to keep on working, no kernel updates are possible after the manufacturer ends support.

* Root support and service managers need to be installed aftermarket using the unofficial solution Magisk.

* No vendor kernel out of the box supports kernel compile time flags to enable the infrastructure to run Linux containers using Docker, Podman or LXC.

* Self-invented file hierarchy with a lot of restrictions that make sense from an Android UI perspective but are prohibitive when used as a regular distro.

* Since Android and drivers use bionic libc, it's not possible to run regular Linux binaries that tap into certain hardware features like Vulkan without reworking and recompiling them.

Just from the top of my head, there's a bunch of other things people could name I'm sure. Android misses a lot of the expectations people have for regular GNU/Linux distributions have - expectations that non GNU/Linux distros like Alpine do meet for the most part.

As pointed out in other replies I don't think you're doing a good job to connect bank fraud to sideloading here, and therefore I don't really believe that they are so directly connected. But for the sake of discussion I can assume there's some truth to it. It is true that Apple's restricting freedoms could have some positive side effects, so I'm happy to go along with this gut feeling.

> I suspect that the EU will regret forcing Apple to enabling sideloading when the number of fraud cases go up.

Maybe some degree of that is worth it? The functioning of digital markets and preventing platform monopolies seems very intrinsically valuable for both ethical and economical reasons. Moreover, it's highly unlikely this will be in some cartoon situation with some massive explosion of fraud.

What if this is just a small price worth paying? Something we need to accept in our lives and help further focus education efforts? That seems like a more valuable discussion than most of the discussion going on in this thread.

Is that the central question?

Most people using Android or Apple's very own macOS today use their device as if they're in the second situation with not a care in the world.

Anyone's walled garden experience isn't meaningfully dependent on anyone else's sanctioned sideloading or not.