@toadie great idea! I will consider it just for a fun test
2 Likes
~50 Mbit with active VPN and uploading files to azure and my wife is streaming something.
For me it’s enougth
1 Like
Actually guys no, the update was not large at all.
With Microsoft Windows a long overdue update would be gigs, because it downloads every update. That’s why a new installation of Windows takes forever to set up. All the updates to come down.
With Arch, all it needs to download is the latest library, program file, etc. So if that library was updated 50 times in the last year, it still downloads just the latest one. So total download would be just as big as the OS and all the programs. It took all but 10 to 15 minutes to download and update. And that’s with a 400 MB connection.
I say Arch, because I did an Ubuntu 22.04 to 24.04 upgrade via GUI and had to leave that running overnight. I did the same for Fedora 40 to 41. So those took a while. @hydn What’s your upgrade experience like?
1 Like
Well currently, of course, my update experience is entirely with Kali Linux, the updates are similar but less than Arch Linux; both in frequency and download size.
Also see the LTS kernel for Arch, everything else remains bleeding-edge but at least you reduce the risk of kernel related issues:
Key Differences:
- Arch Linux: Is truly a bleeding edge rolling release. Packages are updated as soon as upstream releases them, often within days.
- Kali Linux: Also rolling, but based on Debian Testing, which means packages already have gone through a stabilization period before release and then also reviewed by Kali devs before pushed to kali-rolling branch.
Kali Linux, like Debian, also provides branches. The default branch is kali-rolling. The other main branch available is kali-last-snapshot.
kali-last-snapshot
- This branch is a frozen version of kali-rolling, providing a stable snapshot at a specific point in time.
- Ideal for users who need a more predictable, tested environment without constant updates.
On Kali, if you want to be as close to the edge like Arch Linux, it’s also possible: you can switch to the kali-bleeding-edge. However, that was why I moved away from Arch, I prefer devs provide the oversight on the bleeding-edge stuff then, provide it to me after they’ve tested.
There’s also kali-dev branch. Ok so here’s basically how they compare with each other and vs. Arch:
kali-bleeding-edge
- This branch is the most up-to-date, pulling directly from upstream sources like Arch Linux.
- If you want the latest packages as soon as possible, this is the best match for Arch.
kali-dev
- This is another option since it sits just ahead of kali-rolling in the pipeline.
- It updates before they make it into the stable rolling branch, making it closer to Arch but not as extreme as kali-bleeding-edge.
Comparison to Arch:
- Arch Linux is always cutting-edge because it follows upstream releases without much of a testing or staging buffer.
- kali-bleeding-edge would be the closest equivalent, since it takes updates directly from upstream sources before they land in other branches.
I’m basically pulling from what I read here:
1 Like
Just for tell you… I started using a Debian stable virtual machine (only in a CLI environment, but it’s no so useful information to know).
Debian stable is having very small updates weekly, the only problem was with the kernel that was upgrading too frequently.
I decided to install the Liquorix kernel updated like 1 week ago at the date I’m typing and I freezed it’s version by commenting it on src/apt/ the Liquorix repository.
I think it’s a good practice, Chat GPT said me it’s a clever mode of mantaining, I might consider to upgrade the kernel next months without pressure. I think most important thing from now is having a stable machine, without too frequently updates. For now I succeded on this goal.
1 Like
I am doing an update to Manjaro i3. It’s been 60 days. Download size: 2.6 GB.
1 Like
2.6 GB for 60 days are not much i guess. Normal nowadays 
One of the reasons I think it reached up there was all the extra software I had installed, which of course meant plenty libraries.
In comparison, when I did the vanilla Arch Budgie, which just had Firefox installed it was 1.3 GB for one year, as I mentioned above.
Actually, one should distinguish between OS updates and software updates.
More software = more updates
I do agree. But is it possible to do that? Besides Linux firmware, systemd and a couple of others, how do you tell the difference?
This begs another question, is the desktop environment or window manager part of the OS or software?
For stay in conversation.. I switched again from POP!_OS last release to Linux Lite.. beside Windows in a dual boot environment.. eheh 
Today it comes out Linux Lite release 7.4. Linux Lite is very well known for not being so bleeding edges on updates.. it’s based at top of Ubuntu LTS.
The upgrade process from version 7.2 to version 7.4 it takes almost 5 - 10 minutes. Just a click in a gui, a progress bar.. et voilà! I don’t know how many megs I did download, I’m guessing about some hundreds.
Daily Linux Lite is getting really few updates, just critical security patches and a little more.
So I would say Linux Lite is very great compromise between fresh software and stability, such as Ubuntu, but less bloated and without telemetry.
I’ll keep you updated about.
2 Likes
What a fun comment of mine I read! Yes when I was happy using Linux Lite! aha (:
Now I’m using fedora you can consider this post legacy ahah
2 Likes
Why did you switch to Fedora? Did Linux Lite not fit your needs and why Fedora?
1 Like
Hey hello @toadie 
You can read the entire conversation here:
Moreover I consider Fedora the perfect system for power users, and the compromise between stability and refreshed packages.
Also keep in mind now I own a RTX 5070, and I barely think it can run ok on Kernel 6.8 (default shipped with Linux Lite).
3 Likes
So how’s everyone doing with system updates?
On Fedora I noticed the Kernel package is delayed 3-4 days from initial release until it finally arrives on our repos. That’s because Redhat put particular effort on testing before releasing, as soon Fedora is pretty fresh distro.
I would moreover say I’m reciving the correct updates amout: I update the system one day yes one day no. Every 2 days I have nearly ~~ 100-200 mb updates, between software releases and system components updates. I think that’s reasonable update amount.
1 Like
Not bad. I switched to kali-last-snapshot on laptop and default rolling on desktop PC. I login on PC just about daily, but often can go for weeks without powering on laptop. So that change helped cut down of the massive # of updates.
One annoyance , I still had was Chrome, the security updates are ridiculously frequent. So I setup a script that sleeps for 30 seconds when booting and then auto updates Chrome. So now, most times there are not any updates pending.
#!/bin/bash
# Wait for network (30 seconds)
sleep 30
STAMP_FILE="/var/log/.chrome-update-stamp"
TODAY=$(date +%Y-%m-%d)
# Skip if already updated today
[ -f "$STAMP_FILE" ] && grep -q "$TODAY" "$STAMP_FILE" && exit 0
apt-get update
apt-get install -y --only-upgrade google-chrome-stable
# Mark as updated
echo "$TODAY" > "$STAMP_FILE"
Save it to /usr/local/bin/chrome-auto-update.sh then
chmod +x /usr/local/bin/chrome-auto-update.sh`
Then added to cron:
@reboot /usr/local/bin/chrome-auto-update.sh >> /var/log/chrome-update.log 2>&1
1 Like
@hydn that’s a clever approach to updates, I like it.
Btw I want to say I have Chrome on my system (altough I don’t use it often), but for me updates are pretty regular, let’s say a security update once every 1-2 weeks.. Are you using a canary build?
Just for tell I have all my bashes script in ~/home/user/Documents folder, I really don’t see any advantages putting the scripts in /usr/local/bin folder, it might be the correct place where to put user bashes executables (?)
Let’s say I prefer having my bashes collection in Documents folder.
1 Like
Im using Chrome stable:
You can see very frequent updates for stable in release log.
Totally fair if you prefer keeping your scripts in ~/Documents, especially if it works for your workflow.
That said, ~/Documents isn’t usually in your $PATH, so you’d need to call the scripts with the full path unless you modify your environment.
For anything you run regularly, placing them in ~/.local/bin (for user-specific scripts) or /usr/local/bin (for system-wide use) keeps things cleaner (follows the Unix filesystem hierarchy standards) and more accessible.
Also, from a security perspective, storing scripts in a dedicated binary path like /usr/local/bin is safer. That directory requires root to modify, which adds a layer of protection against accidental edits or malicious overwrites, compared to a general-purpose folder like Documents.
1 Like
Thankyou @hydn for the explanation, I never think about this. We never ending learn!
And.. sorry for going a little off topic.
1 Like
No mention. It’s all still relevant. I’ve learned a ton here as well. The thing with Linux that’s great is that it’s very rare that any one way is right or wrong. With a few steps or changes most things can be modified to work as desired.
1 Like