matching other programs and platforms

Actually, Ctrl+C is the interrupt hotkey for pretty much every CLI app/terminal on every platform. Try it within the Command Prompt/PowerShell/Windows Terminal, or the macOS terminal - they'll all behave the same.

The use of Ctrl+C as an interrupt/termination signal has a very long history even predating the old UNIX days and DEC - it goes back to the days of early telecommunications, where control characters were used for controlling the follow of data through telecommunication lines. These control characters, along with regular characters, were transmitted by being encoded in binary, and this encoding scheme was defined by ASCII (American Stanard Code for Information Interchange), published in 1963.

In ASCII, the control character ETX (meaning end-of-text; represented by the hex code 0x03) was used to indicate "this segment of input is over", or "stop the current processing".

Now what does all this have to do with with Ctrl+C you ask?

For that, you'll need to go back to the days of early keyboards. Keyboards back then generated ASCII codes directly, and when a modifier key (Ctrl/Shift/Meta) on a keyboard was pressed in combination with another key, it modified the signal sent by the keyboard to produce a control character.

Specifically, pressing Ctrl with a letter key made the keyboard clear (set to zero) the upper three bits of the binary code of the letter, thus effectively mapping the letter keys to control characters (0x00 - 0x1F: the first 32 characters on the ASCII table).

• The ASCII code for 'C' is 0x43 (binary 01000011).
• Pressing Ctrl+C clears the upper three bits, resulting in 00000011, which is 0x03 in hex.

And would you look at that, 0x03 is the code which represents the control character ETX.

The use of ETX to interrupt a program in digital computers was first adopted by the TOPS-10 OS, which ran on DEC's PDP-10 computer, back in the late 60s. It's successor, TOPS-20 also included it, followed by the RSX-11 (on the PDP-11), and VMS (on the VAX-11).

RSX-11 was a very influential OS, created by a team that included David Cutler. It influenced the design of several OSes that followed, such as VMS and Windows NT. Cutler later moved to Microsoft and became the father of Windows NT. Early NT did not include a GUI, so it was natural to adopt existing terminal operation standards, including the use of ETX. In fact, NT's internals were so similar to VMS that a lawsuit was in the works, but instead, MS agreed to pay off DEC millions of $$$.

Also, when UNIX first came out (1969), it ran on DEC hardware, and so they followed the tradition of using the ETX signal to stop programs. This convention flowed to BSD (1978) which was based on UNIX, and NeXTSTEP (1989), which was based on BSD. NeXTSTEP was developed by NeXT Computers, which was founded by Steve Jobs... and the rest is history.

Therefore, Ctrl+C is something that's deeply rooted in history. You don't just simply change something like that. Sure, you may be able to remap the keybindings, but it's actually hardcoded into many programs so you'll run into inconsistencies - that is, if you used the standard remapping tools built into GNOME/KDE etc.

If you want to truly remap Ctrl+C, you'll want to do so at a lower level (evdev layer) so that it's not intercepted by other programs, eg using tools like evremap or keyd. But even then, it's not guaranteed to work everywhere, for instance, if you're inside a VM or using a different OS, or in a remote session. So it's best to remap the keys at the keyboard layer itself, which is possible on many popular mechanical keyboards using customisable firmware like QMK/VIA.

Over-reliance on proprietary, closed-source products and services from megacorporations.

For instance, it's really absurd that people in many parts of the world cannot function without WhatsApp, they can't even imagine a life without it. It seems absurd that Meta literally has them by the balls, and these people can't do anything about it.

Also the people who base their entire careers on say Adobe or Microsoft products, they're literally having their lives dictated by one giant corporation, which is very depressing and dystopian.

Why don't laptops have proper low power states

Actually, they do, it's called the "S0" low power state, and it's part of the ACPI standard. Microsoft calls this "Modern Standby" in Windows (and "suspend to idle" in Linux) , and it's pitched to do exactly what you've described.

The only problem is, the implementation sucks. Most users actually hate the S0 state because it consumes so much power - on some laptops, even the fans may continue to run on S0, and your laptop may overheat if you've closed the lid and chucked it in a bag, and it's in the S0 state.

Also, because Microsoft and Intel have been pushing this so much, the "standby" mode now defaults to S0 instead of S3 (which is full suspend-to-RAM). So many users actually actively seek to disable S0 and go back to proper S3 standby, via registry hacks etc.

So why is S0 so bad? Part of this is due to the limitations, long history and the variable nature of the x86 platform. All the power-saving stuff was implemented as an after-thought - both at the hardware and software levels. Whereas ARM, at least the modern ARM ecosystem, was developed with mobile usage and power saving from ground up. An x86 PC is also made up of components from disjointed manufacturers, and we need all those components to implement the same standards so that it all works well as expected. So for instance, if a particular component isn't capable of entering a low-power or active standby state, then it won't - and you can't do much about that, unless you're Apple and have a tight control over the ecosystem.

The second half of the problem comes with the software. All applications must be modern standby / S0 aware, if not, one of two things will happen: that app will keep the system awake, or the app will get suspended by the Desktop Activity Moderator (DAM). Either way, the app must be capable of running in the DRIPS phase (deepest idle runtime platform state), which rules out most Win32 apps (basically almost every app that's not on the Microsoft Store).

Finally, the reality is that most PC users don't care about modern standby regardless - and why should they, when they've all got smartphones, which handles notifications well? Also, hardly anyone does large file downloads these days, and the people who do still download, wouldn't care about doing it while on battery (and if they do, they can take manual actions to lower the power consumption, such as switching to a power saving plan and turning off the display etc).

Ultimately, most people would expect a laptop to go into a fully suspended state when the lid so closed and they're on battery, because if they're on battery the #1 concern for them would be the battery life. So most people actively seek to disable S0 and see it as a hindrance.

If you were looking for answers to such questions 10 years ago, your best resource for finding a thorough, expert-informed response likely would have been one of the most interesting and longest-lasting corners of the internet: Quora.

I disagree, the best place for such answers used to be Reddit, and Stack Exchange for the techy stuff. Quora always felt like cancer for some reason and I never really used it.

Just so you're aware, Gitea was taken over by a for-profit company. Which is why it was forked and Forgejo was formed. If you don't use Github as a matter of principle, then you should switch to Forgejo instead.

I'm a Flatpak user myself, but a lot of those arguments against AppImage are outdated or invalid. Here are my counterpoints:

Usability issues

GearLever solves all the problems mentioned.

Updates

There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don't want to use GearLever, there are other updaters like AppImageUpdate.

The lack of repositories
Appimages don't even have a central place where you can find them, not to mention download them.

This is blatantly wrong - AppImageHub exists for this very reason. There are also GUI frontends like AppImagePool which makes it easy to discover/download/install them.

Lack of Sandboxing

That is a fair point, however, AppImage never claimed to be a sandboxing solution, and for some use-cases this can even be seen as an advantage (any Flatpak user would've at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes). But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you're actually running an untrusted app.

Random location
[..] A necessary step would be mounting the entire /home non-executable. This is no problem for system apps, or Flatpaks, but where do you put Appimages now?

There would need to be a standard directory to put such files in, which is normally the PATH. But this is also the easiest attack goal for malware, so PATH would be non-executable as well.

I completely disagree with making the entirety of /home as non-executable, when $HOME/.local/bin is recommended by the XDG standard as a place to store executables. As long as $HOME/.local/bin is in the XDG spec, I'll continue storing my executables there. If you disagree, go argue with the XDG guys.

Duplicated libraries

This is a fair point but "they include all the libraries they need" is the entire point of AppImage - so mentioning this is pointless.

If users would really install every Software as Appimages, they would waste insane amounts of storage space.

Then it's a good thing that they don't right? What's the point of making hypothetical arguments? Also, this is 2024, storage is cheap and dedicating space for your applications isn't really a big deal for most folks. And if storage space is really a that much of a concern, then you wouldn't be using Flatpak either - so this argument is moot and only really valid for a hypothetical / rare use-cases where storage is a premium. And again, in such a use case, that user wouldn't be using Flatpaks either.

Finally, some distros like Bazzite already have the above integrations built-in (GearLever/AppImagePool), so you don't even need to do anything special to get AppImages integrated nicely in your system, and there's nothing stopping other distros adding these packages as optional dependencies - but it's kinda moot at this point I guess since Flatpak has already won the war.

Personally, I'm pro-choice. If AppImage doesn't work for you, then don't use it, as simple as that. Stop dictating user choice. If AppImage is really as bad as you claim, then it'll die a natural death and you don't have to worry about it. What you really need to worry about is Snap, which has the backing of Canonical, and some dev houses new to the Linux ecosystem seem to think packing stuff as Snap is an acceptable solution...

Because:

The DistroWatch Page Hit Ranking statistics are a light-hearted way of measuring the popularity of Linux distributions and other free operating systems among the visitors of this website. They correlate neither to usage nor to quality and should not be used to measure the market share of distributions. They simply show the number of times a distribution page on DistroWatch was accessed each day, nothing more.

So people see it on the list and click on it wondering "what the heck is this MX Linux thing". And that boosts the ranking. And now that it's at the top, it attracts more curious clicks, thus it continues to remain on top.

Not exactly a story, but a picture thread on Reddit where a guy posts a photo of his tattoos on his arms, and someone goes "how did you take this picture", so he posts a selfie showing him balancing a phone on his shoulder, and someone replies "wait how did you take that picture" and then he posts a photo of him taking a photo of him taking a photo... and this continues until he reveals multiple complex camera setups. Such a legendary thread.

Edit: here it is: https://imgur.com/gallery/JThDN

This is my my phone running Debian with XFCE:

That's actually a good thing IMO, Microsoft is giving people more reasons to switch to Linux. How kind of them!

private

If it's on the public facing internet, it's not private.

Here's the TL;DR from Phoronix:

#AMD

• AMD P-State Preferred Core handling for modern Ryzen systems. This is for leveraging ACPI CPPC data between CPU cores for improving task placement on AMD Ryzen systems for cores that can achieve higher frequencies and also helping in hybrid selection between say Zen 4 and Zen 4C cores. This AMD Preferred Core support has been in development since last year.

• Performance gains on AMD 4th Gen EPYC

• AMD FRU Memory Poison Manager merged along with other work as part of better supporting the AMD MI300 series.

• AMD has continued upstreaming more RDNA3+ refresh and RDNA4 graphics hardware support into the AMDGPU driver.

#Intel

• Intel Xeon Max gains in some AI workloads

• Intel FRED was merged for Flexible Return and Event Delivery with future Intel CPUs to overhaul CPU ring transitions.

• Reworked x86 topology code for better handling Intel Core hybrid CPUs.

• Intel Fastboot support is now enabled across all supported graphics generations.

• Intel Core Ultra "Meteor Lake" tuning that can yield nice performance improvements for those using new Intel laptops.

• Continued work on the experimental Intel Xe DRM kernel graphics driver that Intel is aiming to get ready in time for Xe2 / Lunar Lake.

Video, Filesystem & Network

• Support for larger frame-buffer console fonts with modern 4K+ displays.

• Dropping the old NTFS driver.

• Improved case-insensitive file/folder handling.

• Performance optimizations for Btrfs.

• More efficient discard and improved journal pipelining for Bcachefs.

• FUSE passthrough mode finally made it to the mainline kernel.

• More online repair improvements for XFS.

• Much faster exFAT performance when engaging the "dirsync" mount option.

• Many networking improvements.

Full summary here: https://www.phoronix.com/review/linux-69-features/

Unfortunately you chose the wrong distro for your friend - Linux Mint isn't good for gaming - it uses an outdated kernel/drivers/other packages, which means you'll be missing out on all the performance improvements (and fixes) found in more up-to-date distros. Gaming on Linux is a very fast moving target, the landscape is changing at a rapid pace thanks to the development efforts of Valve and the community. So for gaming, you'd generally want to be on the latest kernel+mesa+wine stack.

Also, as you've experienced, on Mint you'd have to manually install things like Waydroid and other gaming software, which can be a PITA for newbies.

So instead, I'd highly recommend a gaming-oriented distro such as Nobara or Bazzite. Personally, I'm a big fan of Bazzite - it has everything you'd need for gaming out-of-the-box, and you can even get a console/Steam Deck-like experience, if you install the -deck variant. Also, because it's an immutable distro with atomic updates, it has a very low chance of breaking, and in the rare ocassion that an update has some issues - you can just select the previous image from the boot menu. So this would be pretty ideal for someone who's new to Linux, likes to game, and just wants stuff to work.

In saying that, getting games to run in Linux can be tricky sometimes, depending on the game. The general rule of thumb is: try running the game using Proton-GE, and if that fails, check Proton DB for any fixes/tweaks needed for that game - with this, you would never again have to spend hours on troubleshooting, unless you're playing some niche game that no one has tested before.

This is informative, but unfortunately it doesn't explain how the actual payload works - how does it compromise SSH exactly?

They should open up RCS first before making demands of Apple.

Solid Explorer. Why? Because I bought it ages ago and it still works fine. Even a decade later, it still gets regular updates, which shows that the dev cares about the app.

More importantly, I like that it jumps straight into my filesystem without any nonsensical abstract views, and I like that it doesn't come with any bloat (no junk cleaner or RAM booster crap), unlike other file managers. With other file managers these days, you open them and instead of seeing your files you get a bunch of mini apps or collections, which is NOT what I want. I just want a simple file manager, not an ecosystem. Thankfully, Solid isn't like that.

So even after all these years and all these updates, the app remains true to its original purpose and hasn't sold out or gone down the enshittification path, which is a refreshing change compared to what we've been seeing with other apps.

Is Android going in the right direction?

Not really, IMO. As a user of Android since v1.5 Cupcake, it's disappointing to see how locked down Android has become over the years. I still recall how I took a leap of faith when I ditched the then highly customisable and feature-full Windows Mobile, to the barebones Android - I believed in the opensource nature of Android, thinking how exciting it was to be on what could be a developer's and power user's dream mobile platform. Although the Android dev scene at the time was nascent, I could forsee an explosion of root utilities, mods and custom ROMs. And I was right - the early Android dev scene was so exciting. From cool and useful utility such as DriveDroid or Chainfire's CF.Lumen, to innovative custom ROMs such as Paranoid Android with their per-app DPI, Halo, Pie controls etc, the early Android scene was full of activity and really exciting as a power user.

But even as Android got more and more locked down and killed my favorite apps, mods and ROMs, I still enjoyed following many of it's developments such as the projects Butter, Svelte, Volta, Treble and Mainline. However, I can't recall anything major or exciting in recent years.

As someone else here mentioned, nowadays all the good stuff seems to be Pixel exclusives (like motion deblur, 7 years or software updates etc). Plus, Google keep pushing more and more stuff towards their proprietary Play Services stack, encouraging developers dependency on them - including anti-freedom features such as Play Integrity (SafetyNet). All of this makes it increasingly harder to break free from Google's grasps, and as former fanboy of a company which once claimed to "not be evil", it makes me sad that the ecosystem I once looked fondly towards, is now something that I'm looking to move away from.

Pixel 8. No bloatware (except the Google bloat of course, but you can get rid of this easily), plus Google has now promised 7 years of updates - which is more than the iPhone. This would increase the resale value of the phone, and even if you don't want to sell it, you could always give it to a family member or something after say 3-4 years of use, and they'd still get many years of official updates remaining. This is great for reducing e-waste whilst still maintaining a good security posture.

And if you're privacy conscious, you could ditch the Google ecosystem completely and load GrapheneOS on it, and GrapheneOS is simple amazing in terms of privacy and security, and arguably has better battery life too (thanks to no Google bloatware running on it).

FYI: The blog post by binarly is a cleaner source and was published a whole week ago.

Probably zero, since LibreOffice is a part of the repo.

And so far we’ve had 1,587,383 downloads from our site! (So that doesn’t include Linux distributions that package it themselves.)

Others here have already given you some good overviews, so instead I'll expand a bit more on the compilation part of your question.

As you know, computers are digital devices - that means they work on a binary system, using 1s and 0s. But what does this actually mean?

Logically, a 0 represents "off" and 1 means "on". At the electronics level, 0s may be represented by a low voltage signal (typically between 0-0.5V) and 1s are represented by a high voltage signal (typically between 2.7-5V). Note that the actual voltage levels, or what is used to representation a bit, may vary depending on the system. For instance, traditional hard drives use magnetic regions on the surface of a platter to represent these 1s and 0s - if the region is magnetized with the north pole facing up, it represents a 1. If the south pole is facing up, it represents a 0. SSDs, which employ flash memory, uses cells which can trap electrons, where a charged state represents a 0 and discharged state represents a 1.

Why is all this relevant you ask?

Because at the heart of a computer, or any "digital" device - and what sets apart a digital device from any random electrical equipment - is transistors. They are tiny semiconductor components, that can amplify a signal, or act as a switch.

A voltage or current applied to one pair of the transistor's terminals controls the current through another pair of terminals. This resultant output represents a binary bit: it's a "1" if current passes through, or a "0" if current doesn't pass through. By connecting a few transistors together, you can form logic gates that can perform simple math like addition and multiplication. Connect a bunch of those and you can perform more/complex math. Connect thousands or more of those and you get a CPU. The first Intel CPU, the Intel 4004, consisted of 2,300 transistors. A modern CPU that you may find in your PC consists of hundreds of billions of transistors. Special CPUs used for machine learning etc may even contain trillions of transistors!

Now to pass on information and commands to these digital systems, we need to convert our human numbers and language to binary (1s and 0s), because deep down that's the language they understand. For instance, in the word "Hi", "H", in binary, using the ASCII system, is converted to 01001000 and the letter "i" would be 01101001. For programmers, working on binary would be quite tedious to work with, so we came up with a shortform - the hexadecimal system - to represent these binary bytes. So in hex, "Hi" would be represented as 48 69, and "Hi World" would be 48 69 20 57 6F 72 6C 64. This makes it a lot easier to work with, when we are debugging programs using a hex editor.

Now suppose we have a program that prints "Hi World" to the screen, in the compiled machine language format, it may look like this (in a hex editor):

As you can see, the middle column contains a bunch of hex numbers, which is basically a mix of instructions ("hey CPU, print this message") and data ("Hi World").

Now although the hex code is easier for us humans to work with compared to binary, it's still quite tedious - which is why we have programming languages, which allows us to write programs which we humans can easily understand.

If we were to use Assembly language as an example - a language which is close to machine language - it would look like this:

     SECTION .data
msg: db "Hi World",10
len: equ $-msg

     SECTION .text
     
     global main   
main:
     mov  edx,len
     mov  ecx,msg
     mov  ebx,1
     mov  eax,4

     int  0x80
     mov  ebx,0
     mov  eax,1
     int  0x80

As you can see, the above code is still pretty hard to understand and tedious to work with. Which is why we've invented high-level programming languages, such as C, C++ etc.

So if we rewrite this code in the C language, it would look like this:

#include 
int main() {
  printf ("Hi World\n");
  return 0;
} 

As you can see, that's much more easier to understand than assembly, and takes less work to type! But now we have a problem - that is, our CPU cannot understand this code. So we'll need to convert it into machine language - and this is what we call compiling.

Using the previous assembly language example, we can compile our assembly code (in the file hello.asm), using the following (simplified) commands:

$ nasm -f elf hello.asm
$ gcc -o hello hello.o

Compilation is actually is a multi-step process, and may involve multiple tools, depending on the language/compilers we use. In our example, we're using the nasm assembler, which first parses and converts assembly instructions (in hello.asm) into machine code, handling symbolic names and generating an object file (hello.o) with binary code, memory addresses and other instructions. The linker (gcc) then merges the object files (if there are multiple files), resolves symbol references, and arranges the data and instructions, according to the Linux ELF format. This results in a single binary executable (hello) that contains all necessary binary code and metadata for execution on Linux.

If you understand assembly language, you can see how our instructions get converted, using a hex viewer:

So when you run this executable using ./hello, the instructions and data, in the form of machine code, will be passed on to the CPU by the operating system, which will then execute it and eventually print Hi World to the screen.

Now naturally, users don't want to do this tedious compilation process themselves, also, some programmers/companies may not want to reveal their code - so most users never look at the code, and just use the binary programs directly.

In the Linux/opensource world, we have the concept of FOSS (free software), which encourages sharing of source code, so that programmers all around the world can benefit from each other, build upon, and improve the code - which is how Linux grew to where it is today, thanks to the sharing and collaboration of code by thousands of developers across the world. Which is why most programs for Linux are available to download in both binary as well as source code formats (with the source code typically available on a git repository like github, or as a single compressed archive (.tar.gz)).

But when a particular program isn't available in a binary format, you'll need to compile it from the source code. Doing this is a pretty common practice for projects that are still in-development - say you want to run the latest Mesa graphics driver, which may contain bug fixes or some performance improvements that you're interested in - you would then download the source code and compile it yourself.

Another scenario is maybe you might want a program to be optimised specifically for your CPU for the best performance - in which case, you would compile the code yourself, instead of using a generic binary provided by the programmer. And some Linux distributions, such as CachyOS, provide multiple versions of such pre-optimized binaries, so that you don't need to compile it yourself. So if you're interested in performance, look into the topic of CPU microarchitectures and CFLAGS.

Sources for examples above: http://timelessname.com/elfbin/

If I'm not mistaken, I believe the 2018 J3 has a locked bootloader. The fact that I can't find even a SINGLE custom ROM on XDA for this model means it's highly likely that the bootloader is locked, and/or the device isn't dev friendly (no kernel sources available etc).

so I guess doing the same on my smartphone wouldn't be too hard.

Mate, you've no idea... Smartphones are a completely different ball game to desktops. You could try and compile your distro, but without the kernel sources and drivers for your specific model, nothings gonna work. You won't even be able to boot the damn thing. And even if you did have those, it's going to take a LOT of effort just to get basic OS functionality working. Forget getting actual phone stuff working, like making calls etc - that's next to impossible. Even large projects like PostmarketOS struggle to get basic functionality going even on dev-friendly phones.

But you can stop dreaming about all the above if you can't even unlock the bootloader.

Basically, what all this means is that there's no point wasting your time on the J3. Stop right now and don't waste any further time on this.

If you'd really like to run GrapheneOS / Linux on your phone, your best option is to sell your J3, and get a used Google Pixel from Swappa/eBay or something.

From what I've heard so far, it's NOT an authentication bypass, but a gated remote code execution.

There's some discussion on that here: https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b

But it would be nice to have a similar digram like OP's to understand how exactly it does the RCE and implements the SSH backdoor. If we understand how, maybe we can take measures to prevent similar exploits in the future.

$19bil is still way too overestimated. I'd laugh at anyone who pay this much if Musk ever decided to sell.

Yes, it's been long abandoned - no updates in over 3 years. Anyways, this is why alternatives like hyfetch, fastfetch (and others) exist.

It's only good because of all the hard work being put in by the moderators. Unfortunately, behind the scenes, Lemmy sucks and is severely lacking in moderation tools to deal with spammers, trolls and sick people who post illegal content.

See this post for instance, I feel pretty bad for the mods who have to deal with such stuff: https://beehaw.org/post/7943139

And the ones who install Arch on a MacBook need extra special therapy.

Um, that wasn't OP's story, it's an old copypasta from Reddit. https://old.reddit.com/r/copypasta/comments/9z7923/sr71_blackbird_copypasta/

Which was in turn derived from the book "Sled Driver: Flying the World's Fastest Jet" by Brian Shul.

This can be easily done using PowerShell, and rar.exe which is part of WinRAR. Just edit the first three variables below according to your needs and run the script. You don't even need to save it as a script, just copy-paste the code into a PowerShell window, you can use the arrow keys to edit the variables (or edit it using notepad if you like) and then press enter when you're ready to run the script.

$winrar = "C:\Program Files\WinRAR\Rar.exe"
$passlist = @("pass1", "pass2", "pass3", "pass4")
$folder = "C:\Path\To\Folder"

cd "$folder"
foreach($file in (dir *.rar).Name) { "Checking $file..."; foreach($pass in $passlist) { .$winrar t -p"$pass" "$file" *>$null ; if($LASTEXITCODE -eq 0){ " → Password for $file is $pass"; break }}""}

This would give you an output which looks like:

Checking file1.rar...
 → Password for file1.rar is pass1

Checking file2.rar...
 → Password for file2.rar is pass2

Checking file3.rar...
 → Password for file3.rar is pass3

If there's something you don't understand in the code above, lemme know - happy to explain further. :)

Here's the Linux version of this:

Really? Well, I'm from Utica and I never heard anyone use the term "upstate."

Before y'all get excited, the press release doesn't actually mention the term "open source" anywhere.

Winamp will open up its code for the player used on Windows, enabling the entire community to participate in its development. This is an invitation to global collaboration, where developers worldwide can contribute their expertise, ideas, and passion to help this iconic software evolve.

This, to me, reads like it's going to be a "source available" model, perhaps released under some sort of a Contributor License Agreement (CLA). So, best to hold off any celebrations until we see the actual license.

Just use NTFS for the whole drive. The new NTFS3 kernel driver in Linux has fairly decent performance (waay better than the old ntfs-3g driver), and has been pretty stable since kernel 6.2.

The key thing you'd want to do though is to use the mount options nocase and windows_names in your fstab.

• nocase enables case-insensitive file/folder support similar to the default behavior under Windows with NTFS volumes.

• windows_names prevents the creation of files or directories with names not allowed under Windows. This checks for forbidden characters in the name like /, , :, *, ?, <, >, |, " or ending with a space or a period. There are also other checks for matching the behavior of Windows with this mount option for rejecting file/folder names that may be valid on Linux systems but not under Windows.

These two mount options should solve most of the issues Linux NTFS users may face. Do note that to use the above mount options, you'll need to be on at least kernel 6.2.

Although not the same, this has been going on for about two years now. Jensen Harris, a former MS engineer, criticized the ads as well as the design of the new Start Menu, over here: https://threadreaderapp.com/thread/1564399431545667585.html

This is a good example of why vertical videos are cancer.

Here's a much better version: https://www.youtube.com/watch?v=dqcAjxVyJZA

Good. Hopefully, at least some of these people realize that Reddit is a lost cause, and that their only option is to migrate to other sites.

This has nothing to do with Arch or Bazzite, it's actually a bug in recent kernels. Switching to Mint only fixed it for you because Mint uses an old kernel.

The fix/workaround is to enable "above 4G decoding" and "resizable BAR" in your BIOS. If your BIOS does not have these options, you can either downgrade to an earlier kernel (or OS image if you're on Bazzite), or switch to a patched kernel like the Cachy kernel.

It was handy to have as a simple .doc/.docx/.rtf viewer. In my previous job, some of our teams would create documentation written in .docx (eg as part of a application package), or automatic reports generated as .rtf files, and WordPad enabled us to view these docs from secure, locked down servers, without needing to install any addition software (which would increase the attack surface and add unnecessary maintenence overhead).

With MS now getting rid of WordPad, I'd imagine it'll be a bit of a hassle - they would now have to switch to a different native file format (which would be a PITA to convert several hundreds existing files), or install a file viewer or some other app, which would add maintenance overhead.

WordPad wasn't bloat, it was a tiny, executable which didn't depend on any special dlls or frameworks.

You know what's actually bloat? Candy Crush, Bing, Ads in File Explorer and all that MS Store / UWP / "Modern UI" crap that MS keeps pushing out.

Just so you're aware, streamdeck-ui is an unofficial program made by one guy in his spare time, so it's kinda unfair to call it "trash", and compare it with official software made by a team of full-time paid developers, who also have full access and documentation for the internals of a device their company created...

Plasma 6, but just as excited for kernel 6.7 featuring:

• bcachefs
• AMD Seamless Boot (for flicker-free streamlined booting)
• Scheduler improvements for better responsiveness/performance
• IO_uring FUTEX support for better performance
• More FUTEX2 work for potentially better gaming performance
• Better write performance for eMMC chips (great for many IoT boards)
• TCP network performance improvements
• DisplayPort Alt Mode 2.1 support over Type-C