Well time is passing and there is not much activity going on lately.
I must admin that I have some managed switch that is running vanilla OpenWRT already 24.10 and there is new mechanism owut package/tool that is doing most of the time great to update software. HaaS may be used even on OpenWRT systems installed as python package. Honeypots the same but I somehow dont trust them. So there is more and more reasons (at least for me to consider switching from fork to upstream). Well just no DynFW.
It was mentioned somewhere on some presentation or topic. That for new devices (Turris Omnia NG/Enterprise) you guys would need kernel 6.x and it seems like its the only argument for you guys (prove me wrong) to actually keep software more up-to-date which is still somehow not happening. I do understand that you might have priorities as a Company and limited man power. Bu I noticed that there are releases changing really simple stuff. And then most of the times after some hotfixes (due to limited testing) and then air silence for 2 months.
At day work I am dealing with technological debt as well sometimes. And from experience its way easier to maintain small fixes more often to adjust for changes in newer versions/upstream. Then make a big jump from something already EOL. Because there are many sometimes complex problems at once to jump into.
Also from security point of view. Some developers/maintainers may set commit message to simply “Fix” and it wont be assigned CVE sometimes but the fix might actually be security related change. I am talking about upstream/kernel.
I am not rushing and maybe I just dont know internals as well. But maybe some procedure is missing somewhere. The same with release with no tag on your GitLab also happening often. That stuff may be automated and forgotten after. There are milestones set for release that are forgoten and not rescheduled.
Well yes and no. Forks appear when there is different goals for the future. And TurrisOS is mostly developed around Reforis and Turris features. While still taking OpenWRT as base. There are some changes send upstream true but not much.
And regarding HBD. Hmmmm. Well long time ago I was on HBL but as many may notice due to limited testing breaking changes appear even in stable branch often. As I mentioned I dont know the internals. Limited man power etc etc. But I believe HBL is totally untested auto-build (or sometimes even builds-not branch).
I am not saying fix fix fix stuff. I demand now. But I believe in constructive criticism to get better in the future.
So I understand that staying as close as possible to upstream may not actually be the “number one” priority for the company. And thats also ok. But well I am a bit annoyed that there is still bug with DSA switch and VLAN filtering. And the fix is already known for OpenWRT. Switch to kernel 6.1+ and bam fixed. Which is somehow not happening. VLAN filtering broken in kernel 5.15.x (hbl) (#355) · Issues · Turris / Turris OS / Turris Build · GitLab Two years and the status is still unconfirmed which I confirmed myself and some other users actually reporting the issue with a fix ready. And still stalled.
I understand also there are issues reported due to lack of knowledge by users or some simple misconfiguration that may be ignored. Or simply closed as “go back to school”/cannot reproduce. But some stuff is really well written in reports, confirmed and with proposed fixes. So its not like the team will have to spend time figuring stuff out when there might be no time to spend on that. But just check proposed solution. And decide to apply it or not. But its that decision making that is missing.
Edit: Wrong issue linked.
This is the one I talked about:
The one mentioned was fixed half-a-year ago in openwrt still present in TurrisOS.
Yeah, judging from the last years’ development pace it boils down to making a decision:
a) timely updates/timely developmemt → switch to OpenWrt proper
b) automatic updates → stay with turrisOS
both choices seem okay, none is perfect (I still stick to b) simply because I prefer automatic updates (and I trust team turris)). Do I wish we saw more of a) in turrisOS, hell yeah. But I will not hold my breath.
Personally, I wonder whether it might not be possible to skip OpenWrt23 either completely (the first 24.10.0 release is being built right now, so barring any catastrophe will be out this week) or just stay there as short as possible and jump to 24 ASAP?
Thats why I brought up the subject. New owut package in openwrt takes care of lets say semi automatic updates now. You just do owut check then if there are updates owut update and it build an image for you with the same packages as you have installed applies that and reboot.
@moeller0 dont tell me that you actually have automatic updates enabled for TurrisOS I mean without confirming them
Sorry to surprise you ;), but I have automatic updates enabled without requiring confirmation. My whole idea is that I am not the time limiting step in updates; I am aware though of the risk.
I’ve had auto-updates on since I got the router back in 2018. It’s never been a problem, but even if it had, rolling back with a button press is something I can teach even the stupidest person in the house if I’m not around to fix it.
Have you tried vanilla OpenWrt on TO?
I did, and missing the rollback-feature was somewhat KO-criteria for me and I switched back.
I still think apart from the nerd in me needing the most recent hardware, there is no need to switch to another ecosystem.
One can even upgrade to WiFi 7 if feeling the need for it.
If there is some CVE threatening Turris devices, the team has always addressed it timewise in the past and atm I don’t believe that has changed.
Still - and this is been something I was always complaining about - there is too much silence from the project team. Which is sad, but not more than in the past.
BTRFS and schnapps, these I would miss most with vanilla OpenWrt. Ideally, the file system/boot architecture could be upstreamed (it might be useful with other fat router models such as the OpenWrt One, too). Power users would be happy using vanilla OpenWrt and those who want can use/install Turris’ software projects (such as IPS, alternate UI, …) on top.
That said, I see no value in putting more effort into TOS 8. Go to TOS 9 straight so there’s a chance to finally catch up with upstream after many, many years.
On a related note, I noticed that it’s been more than a month that @miska was last active in this forum and on Gitlab. I hope he’s just taking an extended vacation or similar.
(I still stick to b) simply because I prefer automatic updates (and I trust team turris)). Do I wish we saw more of a) in turrisOS, hell yeah. But I will not hold my breath.
