Because hosting costs money, and sustainable services need revenue sources.

News we read was put together by a team of journalists, editors, etc.

Video streaming takes a lot of storage, bandwidth, processing, licensing.

And so on.

Price gouging is bad, but reasonable income is necessary.

Billboard ads that don’t target users and don’t track effectiveness are dangerous financially for advertisers, and would pay much less to ad hosters.

Anonymous, aggregated tracking is a healthy compromise.

I’ll be honest here: I switched my main laptop from slow roll to Linux Mint to install it several months back to install wayDroid. I’ve been happy with the switch. Here are my thoughts:

1. I’d installed Linux Mint + wayDroid on the laptop of various family members, and really liked what I saw
2. Runa-chin has done a great job providing instructions and packages to install it on tumbleweed, but it has quirks that I didn’t feel like fighting. It just works out of the box in Mint.
3. I like having KDE plasma 6 on slow roll, but the cosmetic difference from plasma 5 is minimal (it’s more performance/longer term). I’m ok with sticking with plasma 5 if I get a painless wayDroid installation
4. Slow roll is generally stable, but updates have burned me a few times in the past year. More stability is always nicer
5. Flatpak + appimage + snap (yes, I don’t mind using whatever is officially recommended on the project website of whatever I’m trying to install, though it would be nicer to have more official flatpaks) make it such that while my base is stable, I can still get some pretty recent packages

Kudos for putting together good reasons that you don’t like PPA, while also acknowledging that Mozilla is trying to solve a problem.

Yours is one of the very few reasonable objections I’ve read IMO - when the PPA outrage first erupted, I read through how it worked. Unique ID + website unaware of interaction, but browser recognizing, then feeding it to an intermediate aggregator that anonymizes data by aggregating from multiple users without sharing their IDs, with the aim of trying to find a middle ground seems fair to me. Especially with the opt-out being so easy.

However, your points about classes clickbait encouragement, SEO feeding, and the uncertainty that this will solve the web spamminess as it is are valid concerns.

This is the caveat for me for now.

To run locally a powerful graphics card with at least 6 GB VRAM is recommended. Otherwise generating images will take very long!

I’ve got decent RAM on an I9, but my graphics card, which is what matters here, isn’t up to par.

deleted by creator

I run KDE on opensuse Slowroll - Intel i9 processor with plenty of RAM.

Check btrfs snapshots, and consider disabling them if you don’t really need them.

Here’s my story some time in the recent past:

Similar freezing issues that got more frequent. I have network and CPU monitor widgets on my desktop, and noticed my CPU usage peaking during freeze.

Ran top, saw #btrfs was doing a lot of processing. It was running snapshots.

I’d like snapshots, but a responsive system is more important to me: I have frequent backups of most of my stuff anyways.

Once I disabled btrfs snapshots, I stopped having the periodic freezes (which I also noticed were often some time after system/flatpak updates).

Spiral Linux. It’s Debian with customizations on top. You probably have a HDD. Flatpak/snap won’t play well with that.

You could try Opensuse tumbleweed for newer stuff, not sure how well your machine would hold up.

Puppy Linux might be an even safer choice than spiral Linux if you really want to stay lightweight.

Superlior you say? Superl!

You can still try it.

Multiple mounts of the same filesystem is nothing special: I’ve done it on multiple occasions for various tests.

Keep you setup, install smb4k, see how stable it is for you.

smb4k, while primarily for KDE, is awesome for samba shares.

You might want to give it a spin.

super productivity is pretty good.

You can also sync between your phone, desktop, etc using different sync options including Dropbox, webdav, local file, etc

Wow, that’s so messed up: I didn’t know HP did that… I think it might just be a matter of time before others follow suit.

Sounds very Wireshark worthy!

That would be cool.

Here’s my new setup that might not work for everyone, but I’d recommend thinking about if you’re able to.

1. Network printers are blocked from Internet by my router. They have static IP addresses allocated (permanent DHCP leases) for convenience.

2. I have some Canon laser printers. I don’t want to install Canon software across my devices, so I setup a cups print server (lxc container) where I installed the software.

3. I setup and shared the printers (local network only), made them discoverable.

4. I use the CUPS web GUI over ssh tunnel if I need to check on job queues and do maintenance/admin tasks (don’t usually have to).

Clients immediately find the printers on the server, no driver required.

As a bonus, I made the margins 0 on the CUPS ppd on the server so that I get to print without margins when so desired (Canon has fixed minimum margins otherwise).

The one caveat is that the Canon drivers don’t work on raspberry pi (arm), so while I have a to-do to get around that by using a virtualization layer, you need a separate Intel/AMD machine for the print server if your printer doesn’t support ARM.

If you want persistent messages, use a messaging app like another poster posted. KDE connect should work, but it doesn’t work for my setup for some reason.

If you just need transient messages, which is more of my usecase, and lightweight sending, use pairdrop.

snapdrop and pairdrop app from fdroid for Android, pairdrop website in desktop.

You can just use the website instead of app on phone too.

Sending over LAN is local - it doesn’t go outside your own network.

If devices are on same WiFi, no pairing required.

You can also send across networks by pairing.

Project GitHub repository

Splunk is already very expensive to be honest, with their policy of charging based on indexed logs (hit by searches) as opposed to used logs, and the necessity for a lot of logs to be indexed for 'in case something breaks '. Bit of hearsay there - while I don’t work for the team that manages indexing, I have had quite a few conversations with our internal team.

I was surprised we were moving from splunk to a lesser known proprietary competitor (we tried and gave up on elasticsearch years ago). Splunk is much more powerful for power users , but the cost of the alternative was 7-10 times less, and most users didn’t unfortunately use splunk power user functionality to justify using it over the competitor.

Being a power user with lots of dashboards, my team still uses splunk for now, and I have background conversations to make sure we don’t lose it, I think Cisco would lose out if they jacked up prices, I think they’d add value to their infrastructure offerings using splunk as an additional value add perhaps?

Here’s a slightly more detailed description of my debugging experience over the years (also includes that of many coworkers implicitly… many of whom I’ve walked through the stages).

As someone who has done a lot of debugging in the past, and has also written many log analysis tools in the past, it’s not an ether/or, they complement each other.

I’ve seen a lot of times logs are dismissed in these threads recently, and while I love the debugger (I’d boast that I know very few people who can play with gdb like I can), logs are an art, and just as essential.

The beginner printf thing is an inefficient learning stage that people will get past in their early careers after learning the debugger, but then they’ll need to eventually relearn the art of proper logging too, and understand how to use both tools (logging and debugging).

There’s a stage when you love prints.

Then you discover debuggers, you realize they are much more powerful. (For those of you who haven’t used gdb enough, you can script it to iterate stl (or any other) containers, and test your fixes without writing any code yet.

And then, as your (and everyone else’s) code has been in production a while, and some random client reports a bug that just happened for a few hard to trace events, guess what?

Logs are your best friend. You use them to get the scope of the problem, and region of problem (if you have indexing tools like splunk - much easier, though grep/awk/sort/uniq also work). You also get the input parameters, output results, and often notice the root cause without needing to spin up a debugger. Saves a lot of time for everyone.

If you can’t, you replicate, often takes a bit of time, but at least your logs give you better chances at using the right parameters. Then you spin up the debugger (the heavy guns) when all else fails.

It takes more time, and you often have a lot of issues that are working at designed in production systems, and a lot of upstream/downstream issues that logs will help you with much faster.

Somehow reminds me of this

Title: Comparative Analysis of Flatulence Incidents Involving Horses and Dogs: An Examination of Fart Exposure Rates

Abstract: This comprehensive study investigates the fascinating phenomenon of fart exposure rates among various animal species, focusing primarily on horses and dogs as the principal subjects of interest. Through meticulous data collection and analysis, we present compelling evidence that supports the assertion that horses experience a disproportionately higher frequency of fart exposure compared to other animals, including their closest competitors: dogs. Our findings shed light on the intricate interplay between anatomical factors, environmental conditions, and social dynamics that contribute to these variations in fart exposure rates.

Introduction: While the topic of flatulence has often been approached with humor, this study endeavors to provide a scientific lens through which to examine the prevalence of fart exposure among animals. Horses and dogs, due to their widespread domestication and close interaction with humans, emerge as ideal subjects for this investigation. By comparing their fart exposure rates, we aim to identify potential factors that contribute to the observed differences, thereby unraveling the complexities of this underexplored facet of interspecies interactions.

Methodology: To comprehensively analyze fart exposure rates among horses, dogs, and other animals, we employed an innovative cross-sectional survey approach. Data were collected through surveys administered to veterinarians, pet owners, and animal caregivers, supplemented by direct observations of animal behavior. Participants were asked to recall and document instances of fart exposure involving various animals over a specified timeframe. The collected data were then subjected to rigorous statistical analysis to determine patterns and correlations.

Results: Our study yielded compelling evidence indicating that horses indeed experience a higher frequency of fart exposure compared to other animals, including dogs. Statistical analysis demonstrated a statistically significant difference in fart exposure rates between horses and dogs (p < 0.05). Horses were found to be subjected to fart exposure at a rate approximately 1.5 times higher than dogs, solidifying their position as the primary recipients of this phenomenon.

Discussion: The disparities in fart exposure rates between horses and dogs can be attributed to a combination of anatomical, physiological, and environmental factors. The distinct digestive systems of horses, characterized by their large gut fermenters status, likely contribute to their higher propensity for gas production. Additionally, the size and social dynamics of equine groups, along with their frequent human interaction, may heighten the likelihood of fart exposure incidents.

Conclusion: In this pioneering study, we have successfully demonstrated that horses indeed receive a greater share of fart exposure compared to dogs and other animals. The implications of these findings extend beyond humor, revealing the intricate web of factors that shape interspecies interactions and contribute to the dissemination of gaseous emissions. As we continue to unravel the mysteries of animal behavior and anatomy, a deeper understanding of fart exposure rates among different species may pave the way for more nuanced perspectives on animal welfare, social dynamics, and digestive physiology.