[02:11] <lotuspsychje> good morning
[11:15] <tomreyn> sounds like a good approach overall. but... for nvidia and other out of tree users, things will break not just during kernel series upgrades but also during bridge kernel -> stabilized kernel upgrades.
[11:18] <tomreyn> and nvidia (and others producing "dependant components") will always take waaaay too long to get the patches ready, so bridge kernels will have to last for much longer than anticipated.
[11:22] <tomreyn> i'm also not sure how much companies building integrated systems, such as for vehicles or planes, will appreciate an OR where the base kernel is called x.y.z.rc3+patchset4268
[11:22] <tomreyn> OS, not OR
[11:22] <tomreyn> or distro rather
[11:26] <tomreyn> this new scheme will also drive more idiots to constantly use (and sometimes upgrade) mainline test builds 
[11:27] <tomreyn> and it doesn't fully solve (though improve upon, somewhat) the issue of "you have too new hardware for the latest supported ubuntu release"
[11:27] <tomreyn> so those last two are not counter arguments, they are just effects that may be seen.
[11:37] <tomreyn> oh, i may have misunderstood some of this. apparently, LTS releases receive no bridge kernel, that is, nvidia users (and others with depedant compenents) deciding to upgrade to the latest LTS release (do-release-uopgrade -d) before .1 will be, at best, be using vesa graphics until not just .1 but until dependant components will be available for this kernel. then -d really needs a much bigger warning sign.
[11:48] <tomreyn> this will also mean more kernel 0-days affecting (also) LTS releases. which increases the importance of live kernel patching, and relibility of those, as well as kernel security update packages.
[16:52] <tomreyn> i guess https://security.stackexchange.com/questions/254795/is-wsl-2-secure-for-commercial-work/254847#254847 should be mandatory reading for anyone wanting to try / using WSL
[16:54] <pragmaticenigma> I honestly thought that was common knowledge
[17:04] <tomreyn> maybe it is amongst ubuntu on linux users
[17:05] <tomreyn> i doubt it's the case for a majority of ubuntu on wsl users
[17:09] <pragmaticenigma> Perhaps because Linux has enjoyed the benefits of WINE, and have had longer to understand how it works.
[17:10] <pragmaticenigma> at least, my initial thought of WSL was effectively a reverse WINE tool. WINE tranlates windows API calls to the host system. WSL does the reverse
[17:11] <Tenkawa> Keep in mind... WSL and WSL2 work completely different
[17:12] <Tenkawa> WSL2 is a thin hypervisor
[17:12] <Tenkawa> WSL is still emulation
[17:16] <Tenkawa> Its not even emulatiom... its technically called a "compatibility layer" ie Wine/Cygwin
[17:16] <pragmaticenigma> WSL was not an emulator, it was a compatibility layer, much like WINE is
[17:16] <pragmaticenigma> heh... jynx
[17:17] <pragmaticenigma> must have taken us the same amount of time to double check our notes :)
[17:17] <Tenkawa> pragmaticenigma: yes but in no way is it WSL2 like 1
[17:17] <Tenkawa> pragmaticenigma: they are completely different
[17:17] <pragmaticenigma> that I understand, WSL2 is hypervisor based
[17:18] <Tenkawa> Well that in itself changes the security scope
[17:18] <Tenkawa> and what is possible
[17:20] <Tenkawa> I personally like WSL2 (just too bad cross arch support is lacking)
[17:20] <Tenkawa> I am a non-x86 environment
[17:21] <Tenkawa> all arm/risc-v.... even my Win11 box is arm
[17:21] <Tenkawa> and Ubuntu on the linux ones
[17:24] <pragmaticenigma> I'm hoping RISC-V gets wider adoption soon... ARM had so much potential, but the nature of ARM licensing makes it really hard for products to have continuing support after product release. RaspberryPi being the rarity (but likely due to market demands and popularity) to keep updating the kernel and supporting software
[17:27] <Tenkawa> I'm trying to push the RISC-V's along (I have several already) ... just need more vendor/developer involvement
[17:30] <lotuspsychje> the new kernel aproach sounds complex tomreyn tnx to elaborate a bit
[17:35] <Tenkawa> What new approach? Using the mainline and RC kernels?
[17:36] <lotuspsychje> Tenkawa: https://www.omgubuntu.co.uk/2024/08/canonical-announce-major-ubuntu-kernel-change
[17:36] <tomreyn> https://discourse.ubuntu.com/t/kernel-version-selection-for-ubuntu-releases/4700
[17:36] <Tenkawa> yeah the mainline/rc aggressive apprpach
[17:37] <Tenkawa> er approach
[17:37] <lotuspsychje> we will have to see that how it works in realtime
[17:37] <Tenkawa> Nothing new for me... I already use them
[17:38] <tomreyn> lotuspsychje: i think it adds *some* more complexity, but for the average user (desktop, and less so, server) it can be an improvement, and for maintainers, too - we'll have to wait and see how it all plays out.
[17:38] <Tenkawa> (I've been doing kernel development though since the 90's)
[17:38] <lotuspsychje> nice Tenkawa 
[17:39] <Tenkawa> I'm a weirdo who considers this "fun"
[17:39] <lotuspsychje> your link gives an oopsy now tomreyn 
[17:40] <Tenkawa> (looks over at a machine compiling 6.11-rc3 as we type lol)
[17:40] <tomreyn> https://discourse.ubuntu.com/t/kernel-version-selection-for-ubuntu-releases/47007
[17:40] <tomreyn> sorry, i stole that 7
[17:40] <lotuspsychje> tnx : )
[17:41] <Tenkawa> tomreyn: no no I stole it *ducks and runs*
[17:41] <tomreyn> thiiiief!
[17:41] <Tenkawa> I hate these urls some days with those article #'s....
[17:42] <Tenkawa> they are "not" forgiving
[17:42] <tomreyn> well, my mistake entirely, URLs aren't meant to be self-healing ;)
[17:43] <Tenkawa> looks like if you just use https://discourse.ubuntu.com/t/kernel-version-selection-for-ubuntu-releases its also just as good
[17:43] <tomreyn> or just https://discourse.ubuntu.com/t/47007 - yes
[17:44] <Tenkawa> Ahh but thats so non-descript lol