If you read the article, it is indeed full Linux because the 4004 is running a MIPS emulator that provides the necessary memory management features. Pretty much all of the “run Linux on some old chip incapable of running Linux” projects achieve it via emulating a more featured architecture that Linux supports, not by somehow compiling Linux to natively run on a 4 bit, MMU-less architecture.

Linux on phones and tablets is a thing. Typing from my Xiaomi Pad 5 Pro running postmarketOS and LibreWolf.

How is the external display connected? I have never seen Freesync over HDMI work. The early implementations were AMD proprietary and the new ones require HDMI 2.1 which has some ridiculous bullshit about not being implemented by open source drivers. HDMI sucks, use DisplayPort if possible. If your laptop doesn’t have a DisplayPort connector, try a USB-C to DisplayPort cable, as usually the type C ports on laptops support DisplayPort alt mode.

Pretty much all ext4 except for a few Windows installs on NTFS.

Maybe this explains why my webcam indicator is on when no applications are using it. It’s been confusing me for a while now. I’ve double checked anything that I expect to access it is not, and it doesn’t seem to be locked because opening it works, but it sometimes boots up woth the light on. I am using Arch with pipewire so I’ll check and see if this is what’s going on.

I second this, second disk is best as you can keep your old Windows drive in case you ever need to go back for any reason. Modern UEFI makes dual booting way easier than it used to be as the UEFI itself provides a boot menu so you don’t need to fiddle with dual booting using a bootloader like GRUB.

I’m not sure about FF specifically, but 99% of the time you’re connecting a microcontroller to a PC you’re doing so over a serial port (UART) of some sort. It may be a physical COM port or it may be a USB to serial adapter or even a purely virtual serial port over a USB connection, but the methodology is all the same. Unless you are running a serial terminal on that port (as in, a commandline on your PC served on the given /dev/ttyX interface, not a terminal emulator letting you read/write from the port), the microcontroller can’t just run scripts on the PC. Instead, you will want to write a script/program that opens the port and waits for a command to be sent from the microcontroller, then that listener script can execute whatever functionality you require. Note that only one application can have the port active at a time, so if your listener is a separate program from your event handler, you will have to close the port on the listener before running the handler, then reopen the port on the listener once the handler is done so it can start listening for the next event. Better to just make it all one program that is always running on the PC and does both listening for events and handling them so there’s only one program that needs access to the serial port.

It’s not specific to Microsoft, but the general idea of letting proprietary software install whatever it wants whenever it wants directly into your kernel is a bad idea regardless. If the user had any control over this update process, organizations could do small scale testing themselves before unleashing the update on their entire userbase. If it were open source software, the code would be reviewed by many more eyes and trsted independently by many more teams before release. The core issue is centralizing all trust on one organization, especially when that organization is a business and thus profit-droven above all else which could be an incentive to rush updates.

It’s also a “don’t allow third party proprietary shit into your kernel” issue. If the driver was open source it would actually go through a public code review and the issue would be more likely to get caught. Even if it did slip through people would publically have a fix by now with all the eyes on the code. It also wouldn’t get pushed to everyone simultaneously under the control of a single company, it would get tested and packaged by distributions before making it to end users.

NVK is already usable, performancr isn’t 100% of the proprietary driver but I play Overwatch on NVK at 165FPS on my RTX3070 laptop a lot, low settings but very playable. This is with an Optimus configuration (VRR Freesync panel on AMD iGPU) in GNOME Wayland.

Even if so, it would likely still have proprietary blobs, just embedded into a ROM or flash chip on the card. Personally, I’d rather have firmware loaded at runtime over hard-coded, at least then the blob is able to be reverse engineered possibly.

The only mistake Billy made is giving anything to AdBlock Plus, the people who have sided WITH the ads, instead of uBlock Origin, the true MVPs of the ad blocking world. I guess uBlock doesn’t accept donations unfortunately, but still, ABP is shady and I would not support them.

I’m not familiar with KDE’s new feature yet, but if it only supports sysfs LEDs then it won’t control 99% of keyboards. Few RGB keyboards have drivers that expose this interface. Most RGB keyboards are controlled from userspace on their official software on Windows, and that’s also what most Linux projects that control RGB devices including my OpenRGB project do. I wonder if it would be possible to write an OpenRGB plugin/script that exposes a virtual /sys/class/leds/openrgb device that KDE could talk to, then translate that into OpenRGB calls to set the color on all available devices. It doesn’t sound too difficult.

I tried daily driving a Pinephone for a while but had too many issues. My setup of choice now is to have two phones. I have a OnePlus 6 on stock Android and a OnePlus 6T with postmarketOS. Android for calls and texts as well as some apps, pmOS for experimenting with Linux, coding, remote accessing my PC, file managing, and similar tasks. I got the cheapest Mint Mobile plan on both phones so I can have data and test calling on Linux.

Native in this case means processor architecture, not OS. The Linux Steam is still x86/x86_64 code and to run it on an ARM system (even running Linux) will require an emulation layer. This adds substantial amounts of overhead, much more than Wine/Proton does for Windows games on Linux.

OnePlus 6 or 6T would be the best phones that you have a chance at actually finding if you want to run postmarketOS.

Same. I started really using Linux with Ubuntu 6.06 and was drawn in by its “Linux for human beings” goals - the Ubuntu homepage of the era really pushed the ideals of community and openness. Canonical sat in the background paying to send you free CDs in the mail. It was such an idealistic thing back then.

And then it all changed around 2010. The color scheme shifted to a shitty MacOS lookalike, the human elements were dropped, the logo was reworked, it got bundled with a paid music store, then Amazon ads in the search, and it’s been a roller coaster on a downward spiral ever since. I switched to Debian not long after the initial enshittification in the early 2010s and have not looked back, though I moved most of my systems to Arch a few years back because I like life in the fast rolling release lane and Debian wouldn’t support my new GPUs.

I would say we’re beyond the era of PC referencing the classic “x86 IBM Personal Computer compatible” definition. PC could reasonably be considered to include many ARM systems, considering there are now Windows laptops shipping with ARM processors that can run “PC” software. Besides, most new x86 PCs aren’t IBM PC compatible anyways as legacy BIOS support has been dropped by a lot of UEFI implementations. I would consider any device that runs a desktop style OS (be it Windows, Linux, or even MacOS) a PC. The distinction in my mind is specifically mobile vs. desktop. Android and iOS are not PC. They’re primarily touch driven and apps are restricted to a certain format with a centralized app store where you are expected to get all of your apps. Windows/Linux/MacOS are primarily keyboard and mouse driven and you have a lot more flexibility on acquiring new apps, with their forms of “sideloading” and “rooting/jailbreaking” being things that are just normal and accepted rather than workarounds/hacks to break out of the walled garden. I would also go as far as saying a smartphone can be a PC if you have a PC like OS on it, such as mobile Linux OSes that let you run desktop applications.

Squeekboard is where it’s at. By far my favorite onscreen keyboard for Linux and mainly because you can easily create your own layouts using .yaml files. I’m tired of virtual keyboards that omit keys needed for development and terminal use or shove them off to separate tabs. My custom Squeekboard layout fits my needs exactly and I’m pretty fast at typing on it (typing this on it now). I wish it were usable outside of Phosh, though tbf I haven’t tried. Between GNOME Mobile, KDE Plasma Mobile, and Phosh (Squeekboard), I choose Phosh primarily because of how much I like Squeekboard.

Except that in the case of VGA (and DVI, HDMI, and DisplayPort) the i2c interface is intended for use over the cable. All of those ports have a pair of i2c pins and corresponding wires in their cables. The i2c interface is used for DDC/EDID which is how the computer can identify the capabilities and specifications of the attached display. DDC even provides some rarely-used control functionality. Probably the most useful of which is being able to control the brightness of the display from software. I use the ddcci module on Linux and it lets me control my desktop monitor brightness the same way a laptop would, which is great. I have no idea why this isn’t widely used.

Edit:

This i2c interface is widely used to control the lighting on modern graphics cards that have RGB lighting. We’ve spent a lot of time reverse engineering these chips and their i2c protocols for OpenRGB. GPU chips usually have more i2c buses than the cards have display connectors, so the RGB chip is wired to one of the unused buses. I think AMD GPUs tend to have 8 separate i2c buses but most cards only use 4 or 5 of them for display connectors. There is also an i2c interface present on RAM slots normally used for reading the SPD chip that stores RAM module specifications, timings, etc. This interface is also used for RAM modules with controllable RGB lighting.