No I just use YouTube’s feeds.

Yes, a lot of feeds, especially the more commercial ones, only have a teaser in the feed. Most people don’t like this. But lots of feeds want to try and estimate how many readers they have. Since RSS has better privacy by design they can’t really tell if you read it or not. So they force you to visit the site.

However IMHO RSS is still valuable here. Because now I get my notifications in the same place. For example I subscribe to YouTube via RSS even though YouTube tries as hard as it can to force you to watch the video on-site or in-app. This is because RSS lets me reliably get notified about all of the channels and playlists that I am interested in. I can also mix in feeds from elsewhere (Nebula, PeerTube, …) into the same feed so that I just look at one place and have all of my video history.

In some cases you can combat this. Many feed readers will attempt to scrape the full article from the site. This means that you may not have to leave your reader to enjoy the whole article. However this isn’t very reliable and can be pretty difficult depending on how antagonistic the site is. There are also tools that will consume the original feel and produce a new feed with (hopefully) full text articles.

But at the end of the day this is the choice the site is offering you. If you don’t find their feeds useful just don’t use them. You can either visit manually to check, use whatever other notification systems they provide or try to build your own feed (see “feed builder” tools that scrape sites to produce feeds).

It’s always sad when a well-love project goes unmaintained. However it is nice that if had a clear exit. I would have appreciated if the code could be kept online a bit longer for archival efforts but a month isn’t the worst.

I hope other maintainers step up with forks. It will take a while to see which forks are stable and well maintained but it seems like the project was fairly complete and stable so it shouldn’t be too difficult to keep going.

I did take an archive of all of the Git repos on https://git.tt-rss.org/. I encourage anyone who can to grab a copy for preservation. I’ll seed it myself a long while, probably at least a year. But probably not forever.

magnet:?xt=urn:btih:0d70be6a837096aff29e13c29e7ec25961ce3d09&xt=urn:btmh:1220054379c509e2c722d5109a10ff594d5f8916baf9d6152a278e05768fd8d76f65&dn=tt-rss&xl=246415360&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.stealth.si%3A80%2Fannounce

I’m also not familiar. But my understanding is that the package maintainers should prevent this situation. Because otherwise even if there are package version dependencies (I don’t actually know if pacman does this) it would just block the update which results in a partial update which isn’t supported. For example if your theoretical unmaintained Firefox blocks the update of libssl but Python requires new functionality you would be stuck in dependency hell. Leaving this problem to the users just makes this problem worse. So the package maintainers need to sort something out.

It is a huge pain when it happens but tends to be pretty rare in practice. Typically they can just wait for software to update or ship a small patch to fix it. But in the worst case you need to maintain two versions of the common dependency. In lots of distros very common dependencies tend to get different packages for different major version for this reason. For example libfoo1 and libfoo2. Then there can be a period where both are supported while packages slowly move from one to the other.

IF no dependency tries to update too. Off course in that case I would stop. Without pacman -Sy, I never do that anyway, only -Syu.

That’s all you need to know. As long as you always use pacman -Syu you will be fine. pacman -Sy is the real problem. The wiki page is pretty clear about the sequences of commands that are problematic https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported.

Right? What i don’t understand is, when I uninstall with pacman -Rs firefox, delete the cached firefox package (only that file), then the system is in the same state as before I installed it. Then -S firefox should be okay, right? And it even looks up the new version.

This isn’t correct. It won’t look up the new version. Assuming that the system was in a consistent state it will download the exact same package that you deleted. The system only ever “updates” when you run pacman -Sy. Until you use -y all packages are effectively pinned at a specific version. If the version that gets installed is different than the one you removed it probably means that you were breaking the partial update rule previously.

But that is my point. Just running pacman -S firefox is fine as long as you didn’t run pacman -Sy at some point earlier. It won’t update anything, even dependencies. It will just install the version that matches your current package list and system including the right version of any dependencies if they aren’t already installed.

But that means if you already have Firefox installed it will do nothing.

I think you are a little confused at the problem here. The issue is that partial updates are not supported. The reason for this is very simple, Arch ensures that any given package list works on its own, but not that packages from different versions of the package list work together. So if Firefox depends on libssl the new Firefox package may depend on a new libssl function. If you install that version of Firefox without updating libssl it will cause problems.

There is no way around this limitation. If you install that new Firefox without he new libssl you will have problems. No matter how you try to rules lawyer it. Now 99% of the time this works. Typically packages don’t depend on new library functions right away. But sometimes they do, and that is why as a rule this is unsupported. You are welcome to try it, but if it breaks don’t complain to the devs, they never promised it would work. But this isn’t some policy where you can find a loophole. It is a technical limitation. If you manage to find a loophole people aren’t going to say “oh, that should work, let’s fix it” it will break and you will be on your own to fix it.

Focusing on your commands. The thing is that pacman -S firefox is always fine on its own. If Firefox is already installed it will do nothing, if it isn’t it will install the version from the current package list. Both of those operations are supported. Also pacman -Rs firefox && pacman -S firefox is really no different than just pacman -S firefox (other than potentially causing problems if the package can’t be allowed to be removed due to dependencies). So your command isn’t accomplishing anything even if it did somehow magically work around the rules.

What is really the problem is pacman -Sy. This command updates the package list without actually updating any packages. This will enter you system into a precarious state where any new package installed or updated (example our pacman -S firefox command form earlier) will be a version that is mismatched with the rest of your system. This is unsupported and will occasionally cause problems. Generally speaking you shouldn’t run pacman -Sy, any time you are using -Sy you should also be passing -u. This ensures that the package list and your installed packages are updated together.

Reverse DNS is different than static IP.

But yes for outbound email, if you can’t control reverse DNS you will have pain. (Inbound is totally fine) You can in theory just use whatever hostname the ISP’s reverse DNS resolves to however you will get some spam score (or be rejected) as it doesn’t match your “from” domain.

Outbound email is a huge pain really no matter what. Unless you have a long-term lease on the IP and it isn’t in a bad network you really have to pay someone else if you want reliable delivery.

Yeah, it is very important to consider how dependant you are on third parties. At the very least the more dependence the more power they have over you. But also how screwed you are if they just go under.

• If you use SaaS they can interrupt your use at any time and you can only react (for example demanding a reversal or lawsuits).
• If you host closed source software they can’t interrupt service on an existing contract but can legally require you to stop using it if they don’t renew the contract. (And if the company goes under you can likely get away with using the software as long as it doesn’t need code fixes.)
• If the software is open source you can continue using the software indefinitely including making code fixes. (Maintenance may be expensive as it is now your problem but that can be costed and an exit plan made if required.)

Gotta wish for a 64-bit genie.

Only rail. Toronto has an excellent bus network that is not pictured here.

There is not even enough money for proper maintenance let alone new construction! Of course new construction looks good politically so it will get separate budgets while the existing infrastructure slowly crumbles. Look at the “reduced speed zones” that have lasted for years because the rails can’t properly be maintained.

But the 1 line did get longer. So total capacity is probably higher overall. That being said the 1 line is already insufficient for the capacity needed downtown so I’m not sure making it longer helps that much. Maybe in a decade when the Ontario Line opens it will get the long needed relief.

It’s a disaster until you compare it to most other North American cities. Like what is better? NYC and Montreal? I’m sure there are a few other cities that I can’t think of.

But its true that it has been neglected for decades. Thankfully that has changed a bit recently with 2 new lines being in construction. However the maintenance budget is continually insufficient to keep everything in good repair. Only new projects make your government look good I guess. (But we need both new projects and maintenance)

I live in Toronto and was in the Chengdu metro a month ago. I didn’t do a close inspection but it was fine. Honestly probably better than Toronto. The trains had AC and the terminals that I went to were not crumbling.

I think this meme is pretty reasonable. Toronto had a great start with subways, and still has huge ridership. They also have an excellent bus network. But the funding is very tight and the city has long prioritized inefficient personal vehicles. But it is a good point that you are comparing cities that an order of magnitude apart in population. Toronto also has 2 train lines (one light rail that should be opening within a year, and one subway that is probably 10 years away from opening) which are great to see, finally showing some investment in public transit. But the rate is nowhere near what the political will in China allows and also has a huge focus on new projects rather than keeping maintenance of existing infrastructure.

In many ways this is a wakeup call. If we wanted this level of infrastructure we could have it. But we need to actually commit rather than continuously slashing budgets so that we can let the rich pay less taxes and continue to subsidize car ownership.

Its a problem but it isn’t a major problem. I am using rspamd without any sort of exotic configuration (basically just enabling things that are provided, not my own rules) and I only get a few spam messages leaking through a week. Maybe slightly worse than GMail but not considerably slow.

IMHO the only real missing thing out of the box is contacts checking. Which is a huge thing because it is great to have reliable delivery from contacts. But my false-positive ratio is so low anyways that it isn’t a big issue and things like the known_senders module mostly mitigates it.

Yes, blocking port 25 outbound is incredibly common by default. Even on some server connections. It is probably better overall for exactly the reasons that you mentioned.

Or just don’t self-host email

IMHO this is a bit overblown. Hosting inbound is fairly easy. Mail senders (probably for the worst) are very forgiving even if your TLS cert is expired you will probably get mail. Plus senders are supposed to retry for days if you have downtime.

However it is unfortunately true that due to spam sending is a huge pain because IPv4 reputation is a huge component. Sure you can get GMail to trust your domain after a month or so of sending if you have decent volume. But other providers who you may mail once a year are just going to go off of IP reputation. However email was basically designed for forwarding and you can use a service like AWS SES to forward your email from a trusted IP pretty easily. If you are low volume (like personal mail) there are tons of services that will do this for free.

But holy shit a marvel of marketing. Better be a case study in business school. They had little to no actual implementation for years and years but are still the go-to name for autonomous driving and selling subscriptions to something that doesn’t exist. Absolutely wild.

Off topic. But I can’t help but rate the trash cans.

• 1995: Excellent can. Obviously not that many pixels to work with but it is clear, legible and clean.
• 1998: I mean its fine, but a bit of a downgrade. Why so much black? Especially that top rim that apparently was painted black. The shading on the arrows also just hurts legibility, why do 2D arrows have shading anyways?
• 2000: Nope. The only good thing about it is that it is throwing away Windows. The shading is to simple arrows are strange colours and lacks a sense of depth.
• 2001: I don’t love the theme but the execution is great. It looks clean shiny and bright. The only real weird thing is the bag inside, it is a bit strangely round despite seemingly not going over the edge.
• 2006: This is a nice refinement of the last one. Cleaner look, skip the bag, more realistic trash. This is the second best executed after 1995.
• 2015: This one is bland and lacks contrast and detail. The arrows are also oddly stubby for some reason. It’s not bad, but also not good.

This is one of those things that must have been an absolute shit thing to discover the first time. Sure now we are ready and can prepare. But having to diagnose and improvise a solution would not be pleasant.