In the mobile Linux scene, Qualcomm chips are some of the best supported ones. I don't love everything Qualcomm does, but the Snapdragon 845 makes for a great Linux phone and has open source drivers for most of the stack (little thanks to Qualcomm themselves).
CalcProgrammer1
joined 3 years ago
RISC V is just an open standard set of instructions and their encodings. It is not expected nor required for implementations of RISC V to be open sourced, but if they do make a RISC V chip they don't have to pay anyone to have that privilege and the chip will be compatible with other RISC V chips because it is an open and standardized instruction set. That's the point. Qualcomm pays ARM to make their own chip designs that implement the ARM instruction set, they aren't paying for off the shelf ARM designs like most ARM chip companies do.
Hopefully Qualcomm takes the hint and takes this opportunity to develop a high performance RISC V core. Don't just give the extortionists more money, break free and use an open standard. Instruction sets shouldn't even require licensing to begin with if APIs aren't copyrightable. Why is it OK to make your own implentation of any software API (see Oracle vs. Google on the Java API, Wine implementing the Windows API, etc) but not OK to do the same thing with an instruction set (which is just a hardware API). Why is writing an ARM or x86 emulator fine but not making your own chip? Why are FPGA emulator systems legal if instruction sets are protected? It makes no sense.
The other acceptable outcome here is a Qualcomm vs. ARM lawsuit that sets a precedence that instruction sets are not protected. If they want to copyright their own cores and sell the core design fine, but Qualcomm is making their own in house designs here.
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.
Change for the sake of change is so dumb. I'm tired of pointless UI changes every so many years because some middle manager and their designers need to wow some dumb exec to get a promotion and they do so just by rearranging all the existing functionality because the product itself is already a complete solution that doesn't actually need a new version. Sadly, this mentality even creeps into FOSS spaces. Canonical and Ubuntu wanting to reinvent the wheel with Unity, Mir, Snap, etc. GNOME radically changing their UI all the time.
You can view WiFi passwords for saved networks on pretty much every OS. There's no reason to be secretive about entering WiFi passwords, at least to the people whose devices you're entering the password on.
LibreWolf on everything that supports it (Windows/Mac/Linux) and Fennec F Droid on Android.
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.
view more: next ›
APIs can be complex too. Look at how much stuff the Win32 API provides from all the kernel calls, defined data structures/types, libraries, etc. I would venture a guess that if you documented the Win32 API including all the needed system libraries to make something like Wine, it would also be 850 pages long. The fact remains that a documented prototype for a software implementation is free to reimplement but a documented prototype for a hardware implementation requires a license. This makes no sense from a fairness perspective. I'm fine with ARM not giving away their fully developed IP cores which are actual implementations of the ARM instruction set, but locking third parties from making their own compatible designs without a license is horribly anticompetitive. I wish standards organizations still had power. Letting corporations own de-facto "standards" is awful for everyone.