It will fall through much faster than that. I’m thinking two years, tops.

What bug? It’s super easy to do this in an app that already has access to your microphone, like Whatsapp, then extract only keywords from conversations and send them to Meta packed as innocuous numeric codes piggybacking on the overhead of encrypted connections.

A single byte here and there is all you need to know people were talking about cats, or perfume, or shoes etc.

Whatsapp protocol, app and servers are closed source, and Meta apps will download and compile native code upon installation, which escapes normal JVM restrictions and does God knows what.

On certain brands of phones (like Samsung) Meta apps come with a manufacturer-preinstalled system stub that can do pretty much whatever it wants, but is typically used to elevate the rights of Meta apps that were installed via normal means and to collect information from them as well as any app that’s running ads from Meta.

And this is a company that’s a third party to the Android ecosystem — it’s a lot easier for Google themselves, who are datamining the shit out of everything you do on a phone, from second-by-second location to email. And Meta is datamining the shit out of absolutely everything you put on Facebook and Instagram, in spite of any fines and sanctions. And Microsoft are datamining the shit out of everything you do on your PC and they’re openly pushing Recall and Copilot and have been pushing Cortana for so long.

What do you think Cortana and OK Google were listening for?.Hell, Amazon and Google were both caught storing recordings of people’s conversations in the beginning, before they started hiding it better.

So you’re being watched in every way possible in every single thing you do that touches any technology from these companies, we have countless documented instances of them breaking privacy in heinous ways like giving up people to authoritarian governments and to anti-abortion governments in the US and so on…

…and you’re seriously wondering if they’re snooping on your conversations? They have every means at their disposal, they’re using it every second, and you’re wondering if they’re doing that too?

Why wouldn’t they? It’s obvious that we live in a world where it’s ok to ask forgiveness (and you’ll get a slap on the wrist, if that) rather than permission. What would possibly compel them to not do it?

Consequences? What consequences? We already know for a fact they spy on so much stuff and we keep using their tech. There are no consequences.

I use whatever online storage service I want because you can add your own encryption layer so you only sync encrypted files. rclone supports lots of services and will also encrypt files for you.

They’re doing IP location checks, and they’re doing them badly (there’s not really a way to do them well). It’s not working for me with people in the same town, and other people are reporting it’s randomly working or not working with locations in the same neighborhood.

Unfortunately over here it seems to be doing IP-based location as I’m not able to add my brother who lives in a different part of the same town.

The repo delay is not the main cause of AUR warnings. While it can in theory cause mismatched dependencies for some AUR packages, in practice it doesn’t really happen that often.

The main issue with AUR is that it’s completely unregulated. Anybody can put anything in it, there’s no quality criteria, AUR scripts run as root and can do anything on your system, 75% of AUR packages were not updated during the last year, 15% were released once and never updated, and 10% are completely abandoned.

Arch itself doesn’t support AUR for those reasons. You should be wary of using AUR packages in general, on any system that can use them, always assume they can break at any moment, and never use them for anything critical.

Manjaro uses the binary packages prepared by Arch but a distro is more than just a set of packages. (In fact a distro should be more than just copying packages, otherwise it wouldn’t be worth being called a distinct distro.)

Arch’s goal is to be an ultra-customizable distro. To this end it starts out extremely minimalistic and requires the user to “assemble” it during the install from basic components, just so it doesn’t end up with anything that’s not wanted.

If a user can do this then they’re above average in experience and knowledge; and since Arch can reliably assume this about its users it doesn’t coddle them. The maintainers can afford to issue breaking changes that may even go as far as render your install non-operational, because they know their users can deal with it.

Another big Arch feature is being a rolling-release distro and bleeding-edge. This means that packages are released as fast as their developers can make them. This means they often have new bugs. This is the price users pay for the privilege of having very fresh software all the time.

Manjaro prioritizes a safe environment for the user and a more stable experience, where the install doesn’t break (at all, if possible), and can be very easily be restored if it should break. And as a consequence it attracts users with less experience and Linux knowledge.

However, in order to achieve this Manjaro does some things very differently from Arch:

• It holds back new packages and releases them late®, when the Manjaro curators deem them usable.
• It offers an alternate package manager with a more user-friendly interface.
• It recommends the use of long term stable kernel (LTS) releases and mandates installing crucial drivers (graphical drivers in particular) through its own custom tools.

These differences mean that if a Manjaro user were to ask for help from an Arch crowd, the Arch users can’t reliably help because they have no idea what’s going on on the Manjaro side. They may use older packages and the issue being described was fixed in a very fresh version. They use tools (the kernel manager, the package manager, the driver manager) that Arch doesn’t have.

Also there’s very little overlap between the average Manjaro and Arch userbase. If an Arch user is more experienced and the Manjaro user isn’t they’re going to have trouble relating to each other. The Arch user doesn’t see an issue in some occasional breakage, whereas a Manjaro user might consider that unacceptable and so on.

Last but not least there’s a purely technical reason – Manjaro not only delays packages but hosts them in their own repositories, and sometimes goes as far as changing them. This makes it literally “not Arch” – using distinct repos is a step too far in terms of distro heritage.

How long have you been using each of them? In my years-long experience it’s been the exact opposite. Manjaro goes out of its way to not break anything and offers safety measures out of the box to recover if something should break. Arch doesn’t care, it introduces breaking changes all the time and expects its users to be able to cope with them.

They target very different types of users and have very different goals. Manjaro explicitly tries to be stable and user-friendly whereas Arch exclusively caters to advanced users and aims to be customizable above all.

You can achieve the same with Arch that you get out of the box with Manjaro but it’s not there by default – because that’s not something a lot of Arch users are seeking.

For a normal user, you probably won’t notice that technically manjaro is not arch and EOS is.

What’s a “normal” user? On Linux you get all sorts. But you will most definitely notice a difference between daily driving Manjaro vs driving Arch.

All distributions make mistakes. It’s a complex job. Debian stable had a local root elevation exploit on for a while a couple of months ago and nobody batted an eye. People would have a field day if that happened to Manjaro.

It’s a double standard borne out of the resentment of a vocal minority and that sucks. The Linux community wastes so much energy on these pointless feuds. (And then they wonder why there’s never the year of the Linux desktop…) Linux and FOSS are not about treating user share as a zero sum game but unfortunately there are people who can only think in terms of “if you use another distro you’re dumb and I must ridicule you”.

It’s an especially narrow-minded take with distros like Manjaro, which is different enough from Arch that its users were never going to use Arch anyway.

First of all would be the fact that Endeavour is basically just an installer. It should have been an alternative offered by Arch alongside archinstall. I know it also offers some desktop setup but IMO that’s too little to qualify as a distro. You can replicate looks and themes fairly easily. Might as well install Arch.

…but I don’t want Arch because I’m at a point where I want my desktop distro to be boring and predictable, so it enables me to focus on other things. Arch needs more maintenance than I’m willing to put in. But I also want a rolling distro and having recent-enough packages.

Manjaro is a unique combination of rolling and stability. It’s that combo that’s the main factor but I’d be lying if I didn’t say I enjoy not having to ever think about the graphics drivers, or about the kernel, and it’s nice to have a graphical package manager.

As a sidenote, Garuda goes the extra mile and adds similar quality-of-life tools, while staying true to Arch repos. I think Garuda should get the publicity as an actual alternative in-between Arch and Manjaro, rather than Endeavour.

I believe intel-compute-runtime is in the official packages, why install from AUR?

They also may not compile stuff from source, they can download and install binaries and some AUR packages do exactly that.

There’s zero guarantee when using AUR. It’s not supported by Arch for a reason.

There no security and trust when taking about 3rd-party repos… There can be anything in there. Neither the AUR nor PPAs come with any guarantees.

How did it crash?

Manjaro is a very opinionated distro and has a certain way of doing things. There’s also a lot of bad advice online that tells you to do exactly the things that will break it. Doing things like using an experimental kernel, switching to unstable branch, using Arch repos, installing graphical drivers outside its driver tool, installing critical packages from AUR, using Arch-specific config commands and so on.

Manjaro will work perfectly if you let it work the way it was designed, but lots of people don’t. Those people would be much better off using Arch or one of the Arch derivates that stay true to the way Arch does things.

Messing with Manjaro then complaining “it broke” is like using a toothbrush to slice bread and complaining it’s not working. Well, it’s the wrong tool for what you wanted, of course it won’t work.

Manjaro is the only distro I’ve tried whose live image worked flawlessly, out of the box, and did everything I could think of, first try.

Granted this was 5 years ago when I set down to find an alternative to Ubuntu. Maybe today there are more distros that can do that.

At the time I tried all the usual suspects that are supposed to provide a user-friendly, gamer-friendly desktop experience and they all came short — except one.

That sold me. And it was surprising because I didn’t really expect to find such a distro, I was just thinking I will make a list of what doesn’t work out of the box on each, and pick the one with the least stuff. I didn’t expect a distro to have no list.

Endeavour is Arch and Manjaro isn’t. Endeavour is not a replacement for Manjaro for that reason alone.

“I installed distro B over distro A” does not mean “distro B is a replacement for distro A”. They can be wildly different and it could be very misleading for someone looking for something that’s actually similar to distro A.

If you’re lazy (which I take to mean you like low maintenance) and haven’t tried a rolling release distro, you need to try Manjaro. It’s downstream of Arch (like Mint vs Debian) but with a lot of QoL improvements that take the edge off.

It’s"Goldilocks" for me because it’s rolling and has recent packages but also very low maintenance. I was sick of 3rd-party repo incompatibilies and update issues on Ubuntu.

It’s a curated take on Arch in that it sources packages from Arch but holds them back until they’re in a decent shape. Recent example was the Plasma 6 which they’ve held back a couple of months until most bugs had been cleared, but normally they release packages on a 2 week cycle.

It works out of the box, keeps working indefinitely (5 years going for me), and they have integrated system snapshots if you use BTRFS for root, just in case (automatically takes snapshots before every update, which you can restore from Grub). Never had to use a snapshot (did it only once to see if it works).

Limitations of Manjaro compared to Arch:

• Not as bleeding edge due to holding packages for a while.
• You have to stick to their way of doing stuff, like their tools for graphics drivers and kernel management.
• You have to stick to a LTS kernel or at least keep one installed as backup at all times.
• It won’t change your kernel major version for you, ever. Some people see this as a disadvantage, personally I greatly prefer it.
• You have to stick to their stable package repo. If you use their unstable/testing repos all bets are off (which is not going to be news to someone familiar with Debian).
• You get access to the AUR but the usual warnings apply since AUR is even wilder than Sid. Some people say they’ve ran into trouble installing some AUR packages on Manjaro due to missing dependencies. It’s never happened to me but I can see how it could happen due to the package delay.
• You can’t say “I use Arch btw”. Arch fans tend to hate Manjaro because they see its limitations and hand-holding as antithetical to Arch’s goals.

Regarding that last point, there’s a very vocal minority that will smear Manjaro any chance they get All I can say is, try it for yourself.

You don’t have to install drivers or CUPS on client devices. Linux and Android support IPP out of the box. Just make sure your CUPS on the server is multicasting to the LAN.

You may need to install Avahi on the server if it’s not already (that’s what does the actual multicasting). The printer(s) should then auto magically appear in the print dialogs on apps on Linux clients and in the printer service on Android.

On Linux it may take a few seconds to appear after you turn it on and may not appear when it’s off. On Android it shows up anyways as long as the CUPS server is on.

From what I understand OP’s images aren’t the same image, just very similar.

short of all using the same wordpress or whatnot hoster, that is.

That’s the thing, that’s common practice. It’s basically a given nowadays for shared web hosting to use one IP for a few dozen websites, or for a service to leverage a load/geo-balancer with 20 IPs into a CDN serving static assets for thousands of domains.