Debian 12 “bookworm” is released: Debian -- News -- Debian 12 "bookworm" released
OSMC apt already knows this:
N: Repository ‘Index of /debian bullseye InRelease’ changed its ‘Suite’ value from ‘stable’ to ‘oldstable’
Is there an ETA for bookworm on OSMC?
Will the Vero 4k+ get it?
Thanks, and keep up the good work!
Here we go again…
You might find this boring, feel free to ignore this thread and issue.
Other people don’t find it boring, please don’t make fun of them. Stay polite. Thanks.
Same answer as before. I’m more than aware that Bookworm has been released.
Thanks for the reply. But I still don’t know the answer: Will the Vero 4k+ get the upgrade to bookworm?
I’m not sure anybody knows yet. Is there a particular reason why it should?
Yes, it will.
Currently I’m not sure whether to start working on Bookworm just yet.
I’d like to move us over to a completely 64-bit environment. That will take some time and with Vero V about to launch, this may not be the exact time to do it.
Furthermore, when we do this users won’t be able to upgrade - they’ll need to perform a fresh install.
To end-users, switching to an new OS is a checkbox.
To the developers, it is a new platform that requires support and adds to the overall cost of support for the entire company. It would be nice if it wasn’t just one more platform in cost, so if Sam’s company is supporting 5 platforms currently (IDK the number), then dropping a few would likely happen. For example, raspberry pi v2/3 users. There is a real cost in providing support to many different platforms and the change from 32-bit to 64-bit can be a huge problem.
I worked as a cross-platform developer for about a decade. On one project, we were deploying to the first mass-produced 64-bit CPUs available (Alpha CPUs) and found all sorts of strange things between the 32-bit version and the 64-bit version. Unexpected things would break. Passing bit-packed variables on the stack, for example. Big vs Little endian-ness matters. I doubt that applies with ARM-based platforms.
Every OS change has similar issues, especially with Linux. Over time, libraries that are core to a project get dropped completely and newer ones become involved. In linux now, there are changes to which audio management system will be used going forward. I don’t know how that impacts OSMC, but it must. The fact that I don’t know deserves credit to Sam for making a system that works and doesn’t make me need to know! On my other computers, I know exactly which audio control system is used and curse at it a few times a month when it doesn’t behave.
If, and when, Sam decides to migrate to a newer release, that’s fine. I’m not in any hurry. And always remember that
New is the enemy of stable.
I much prefer stable over anything else.
Well spoken,
I will drop Pi 2/3 when Pi 5 comes out.
The supply chain for 4/5 will be much improved by then, and nothing will stop users from using older versions of OSMC.
Don’t say the P word.
We’ll stick with ALSA for the forseeable because Pulse (and Pipe) are great when multiple applications want to access a sink, but it sucks when it’s a single application or use case trying to use a sink.
Thanks for your feedback. Great to hear the Vero 4k+ will get bookworm!
The Vero V and a switch to 64 bit are cool projects. But I’m not sure the bookworm upgrade and the 64-bit switch are the same process, AFAIU they can be separate steps.
While I agree with many things @Spammer456 said, I disagree with a generic “new is the enemy of stable” (especially when “new” is a “new stable version”). Software is not a state, it’s a process, and Debian will not support bullseye forever.
I am however aware of work needed and limited resources. That’s why I am asking, not demanding.
Thanks, all.
They are the same step.