# Enabling software longevity **URL:** \ **Category:** Blog\ **Created:** [April 16, 2024, 4:18pm UTC](https://community.frame.work/t/enabling-software-longevity/49041 "2024-04-16T16:18:41Z")\ **Posts on this page:** 18\ **Page:** 3
**Author:** ![Destroya](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/destroya/32/47793_2.png) [@Destroya](https://community.frame.work/u/Destroya)\ **Post date:** [November 19, 2024, 7:16am UTC](https://community.frame.work/t/enabling-software-longevity/49041/43 "2024-11-19T07:16:42Z")
> [@Azure](#): > > addition of the Community Support topic Community Support is not a new category; it has been here for a while, but it wasn’t being used effectively. People were reporting their issues under the Framework Laptop 13 and Framework Laptop 16 categories instead. We’ve introduced new tags to the Community Support category and have started moving “community support” threads there so that users can easily find and organize relevant information. We also [redefined](http://community.frame.work/t/framework-community-forums-101/59702) each category, which has led to more posts in the Community Support category, increasing visibility for these issues. As I mentioned to Takaides, we haven’t announced anything new recently, which means no pre-orders or reviews of new products. There just isn’t much to talk about at the moment. Things will be lively again in the future and there will be more questions and more topics to be discussed 🙂 ---
**Author:** ![Obasav](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/obasav/32/16995_2.png) [@Obasav](https://community.frame.work/u/Obasav)\ **Post date:** [November 19, 2024, 9:50am UTC](https://community.frame.work/t/enabling-software-longevity/49041/44 "2024-11-19T09:50:57Z")
> [@Destroya](#): > > In hindsight, perhaps we could have communicated that we’re still investigating and working on the BIOS update—do you think that would have helped?) I do think that mentioning it is still being investigated can help. I believe that I can speak for a few community members here by saying we like to be kept in the loop of things. Silence regarding the issue can maybe feel like nothing is being done with it, and I think that may be what brings about the update questions. We can provide more data points if needed to help speed up any updates, just let us know what data needs to be provided. (Hardware surveys, OS/kernel, bios settings, OC/UV data points like xtxu/RyzenAdj settings, etc) Thank you for letting us know issues are still being worked on and that Framework is working on projects to improve the devices. 🙂 ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [November 19, 2024, 10:41am UTC](https://community.frame.work/t/enabling-software-longevity/49041/45 "2024-11-19T10:41:09Z")
Hi, I think some of the problem is that FW don’t seem to do support in a process that users have become used to with other suppliers. As an example. I raised a bios bug with a different manufacturer. There was some early interaction until we reach the bug status of “customer bug reproduced by supplier support team” Then a delay until “alpha release for customer to confirm the fix works” Once I confirmed it fixed the bug for me, the next status was being given a release version that will contain the fix. The release version was released up to a month later. The release notes for the prior release were continually updated, in the Known bugs section, once the “bug reproduced” step was reached. I don’t see any of this interaction with users happening in relation to bios bugs. ---
**Author:** ![sgilderd](https://avatars.discourse-cdn.com/v4/letter/s/439d5e/32.png) [@sgilderd](https://community.frame.work/u/sgilderd)\ **Post date:** [November 19, 2024, 11:40am UTC](https://community.frame.work/t/enabling-software-longevity/49041/46 "2024-11-19T11:40:54Z")
> [@takaides](#): > > So, from my point of view, **since the iteration speed hasn’t significantly improved, nor has the communication significantly improved, I assume the priorities that were communicated in the post have changed or updated**. Policies and priorities change all the time. Stagnation in business, and especially technology companies, can lead to a quick and brutal death (of the company). I agree. There have been numerous commitments to improve software maintenance, particularly on BIOS updates which have not materialised. There are still bugs on the PD handling for the FW 13 AMD, and an accumulation of microcode and other patches which should really made available. Until FW’s support in this dimension improves, it is hard to recommend FW for business use. ---
**Author:** ![takaides](https://avatars.discourse-cdn.com/v4/letter/t/ac8455/32.png) [@takaides](https://community.frame.work/u/takaides)\ **Post date:** [November 19, 2024, 3:48pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/47 "2024-11-19T15:48:32Z")
> [@Destroya](#): > > Regarding the Framework Laptop 16 BIOS, we haven’t shared any updates primarily because there hasn’t been anything new to share. The issues are still being tracked and investigated, and we are conducting extensive internal testing. ( **In hindsight, perhaps we could have communicated that we’re still investigating and working on the BIOS update—do you think that would have helped?** ) YES! 1000x this. Bad news, with a planned path forward, is much better than no news. Neutral news is better than bad news. Not everything has to be sunshine and daisies, but no news is particularly difficult. > [@Destroya](#): > > We have released BIOS updates for each of our products **this year** … > [@Destroya](#): > > Apart from Intel Core 12th Gen, we’ve released new driver bundles for each of our products **this year**. > [@Destroya](#): > > The overall longevity of devices as complex as modern notebooks also **depends on how long the software and firmware continues to be useful**. That includes compatibility updates to support newer generations hardware modules, **fixes for bugs or compatibility issues** found by end users, and especially **patches for security vulnerabilities**. In the fast-moving world of modern computers, yearly updates are better than no updates, but not what I expect in terms of software longevity. I understand Framework can’t do anything about proprietary/closed-source software provided by vendors that doesn’t have upgrades available, but many of these vendors (especially AMD and Intel) are releasing nearly monthly driver updates with bug and compatibility fixes, and security patches, as well as support for new features (October’s first AMD update includes support for “AMD Fluid Motion Frames (AFMF) 2,” which has major performance improvements specifically for gaming). As of October 2nd, [issues had been reported to Framework (via community forums)](http://community.frame.work/t/frwk16-amd-software-adrenalin-edition-24-9-1-issues/58567) of major crashing and issues related to this release. [You chimed in on the same day to remind folks to use official Framework drivers](http://community.frame.work/t/frwk16-amd-software-adrenalin-edition-24-9-1-issues/58567/3), and, [on the following day, confirmed Frameworks driver bundle was from April](http://community.frame.work/t/frwk16-amd-software-adrenalin-edition-24-9-1-issues/58567/8). To me, this is a compatibility issue for a bug fix, security patch, and new feature release. I feel that this specific update hits all of the points mentioned in the quote. > [@Destroya](#): > > we’re dependent on the support lifetimes of our upstream silicon vendors who in some cases haven’t shared public end of support dates. Instead, we can state that our intent is to provide security updates for at least as long as our silicon vendors are able to. Note that this specifically applies to the UEFI firmware **and drivers** that are provided to us as binaries. AMD has released 9 driver updates for CPU/APU/GPU alone, since Framework’s bundled drivers were last updated. (I’m going off of the Driver Build date of 2/22/2024, a few days before the Adrenalin 24.2.1 release on 2/26/2024.) **What is Framework’s intended policy regarding ongoing software (specifically drivers) support?** > **Unrelated note regarding response times** > > Also, as an aside, I don’t work for Framework, and can post whenever I please. I don’t know where you are located (and have no need to know), but it was well after what I hope would be an end of shift for California/PST based folks when you posted your response. I hope you are able to have downtime and aren’t burning the candle at both ends on my behalf. I can wait until standard business hours for a response (especially if you need to check with any other Framework employees to formulate a response). I am not sure if I appear hostile/angry (which is not my intent), but I want Framework to succeed, and that includes healthy work/life balance to prevent burnout. I am frustrated, but I do seriously want everyone at Framework, especially those in customer facing roles of any kind, to have a great day, everyday. ---
**Author:** ![Destroya](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/destroya/32/47793_2.png) [@Destroya](https://community.frame.work/u/Destroya)\ **Post date:** [November 19, 2024, 5:48pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/48 "2024-11-19T17:48:06Z")
Thank you all for chiming in. I’ll share your feedback with our firmware team and the larger communications team to help improve our processes and provide more frequent updates. In an ideal scenario, we’d release a beta version of the BIOS, and if no issues are found within a week or two, it would be promoted to stable. At that point, we would update the knowledge base articles, send emails to subscribers, and so on. For the Framework Laptop 16, we discovered some bugs and have been in an ongoing period of tracking and investigation since this summer. I personally thought there wasn’t much to share (beyond the fact that we’re still working on it), but it seems I was mistaken. Moving forward, I’ll make it a point to be more active in providing updates after we release a beta BIOS and before promoting it to stable. > [@James3](#): > > I raised a bios bug with a different manufacturer. > There was some early interaction until we reach the bug status of “customer bug reproduced by supplier support team” > Then a delay until “alpha release for customer to confirm the fix works” > Once I confirmed it fixed the bug for me, the next status was being given a release version that will contain the fix. > The release version was released up to a month later. > The release notes for the prior release were continually updated, in the Known bugs section, once the “bug reproduced” step was reached. This is really good—honestly, I would expect this as a customer. Maybe we could track these bugs on GitHub instead of the community forums. This way, we could manage them more effectively and provide better visibility. > [@Obasav](#): > > We can provide more data points if needed to help speed up any updates, just let us know what data needs to be provided. (Hardware surveys, OS/kernel, bios settings, OC/UV data points like xtxu/RyzenAdj settings, etc) Do you think it would be easier to provide this data and track these issues on github instead of community forums? > [@takaides](#): > > but it was well after what I hope would be an end of shift for California/PST based folks when you posted your response Not gonna lie, it was 11:16 PM, sometimes it just happens 🙂 ---
**Author:** ![takaides](https://avatars.discourse-cdn.com/v4/letter/t/ac8455/32.png) [@takaides](https://community.frame.work/u/takaides)\ **Post date:** [November 19, 2024, 6:23pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/49 "2024-11-19T18:23:54Z")
> [@Destroya](#): > > Do you think it would be easier to provide this data and track these issues on github instead of community forums? I personally have a (underutilized) GitHub and think that would be a great idea. ---
**Author:** ![Obasav](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/obasav/32/16995_2.png) [@Obasav](https://community.frame.work/u/Obasav)\ **Post date:** [November 19, 2024, 7:12pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/50 "2024-11-19T19:12:22Z")
> [@Destroya](#): > > Maybe we could track these bugs on GitHub instead of the community forums. This way, we could manage them more effectively and provide better visibility. I think that tracking the issues and progress towards fixing using GitHub is an excellent solution to this. It can be organized a lot more easily compared to using community forums, and it’s a great location to have more technical details as well. > [@Destroya](#): > > Do you think it would be easier to provide this data and track these issues on github instead of community forums? I definitely think it would be a lot easier to provide data and track issues on GitHub. Community forums are nice way to communicate big updates regarding things, but I think the more technical details and incremental progress updates through GitHub will be a lot easier to manage compared to different forum posts. For example, each beta bios could have updates listed in GitHub as well as any way we can help test the changes. For the ability to provide data, I think anywhere could work but for convenience it should be close to the other data regarding the systems. If GitHub is being looked at for communication regarding updates, it maybe could have polls or ways to provide data about how we use the systems and would like to see them improve. ---
**Author:** ![next\_to\_utter\_chaos](https://avatars.discourse-cdn.com/v4/letter/n/3da27b/32.png) [@next\_to\_utter\_chaos](https://community.frame.work/u/next_to_utter_chaos)\ **Post date:** [November 19, 2024, 8:37pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/51 "2024-11-19T20:37:07Z")
> [@Obasav](#): > > I definitely think it would be a lot easier to provide data and track issues on GitHub. Well, why not use [GitHub - FrameworkComputer/SoftwareFirmwareIssueTracker: Public Issue Tracker for Firmware Issues related to Framework Products](https://github.com/FrameworkComputer/SoftwareFirmwareIssueTracker) for that? It has been semi-officially announced for the latest Beta (now Release) BIOS of the Intel Core Ultra Series 1: > [@Framework Laptop 13 Intel Core Ultra Series 1 BIOS 3.04 Release](http://community.frame.work/t/framework-laptop-13-intel-core-ultra-series-1-bios-3-04-release/59579/1): > > ## Reporting Issues > > To report issues we have created a public issue tracker on github. [Issues · FrameworkComputer/SoftwareFirmwareIssueTracker · GitHub](https://github.com/FrameworkComputer/SoftwareFirmwareIssueTracker/issues) > > We hope that this is a better way to track issues with community involvement moving forward as we have found it difficult to both gather relevant information about issues people are reporting on the forums, and track the issues through their lifecycle in a transparent way. ---
**Author:** ![Destroya](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/destroya/32/47793_2.png) [@Destroya](https://community.frame.work/u/Destroya)\ **Post date:** [November 19, 2024, 8:51pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/52 "2024-11-19T20:51:46Z")
Yep, that’s the one. We created it but haven’t utilized it yet. ---
**Author:** ![Obasav](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/obasav/32/16995_2.png) [@Obasav](https://community.frame.work/u/Obasav)\ **Post date:** [November 19, 2024, 8:52pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/53 "2024-11-19T20:52:46Z")
I wasn’t aware they had semi-announced any GitHub issue trackers. Thank you for letting me know. I don’t have a framework 13, so I don’t look at release notes regarding it. ---
**Author:** ![Morgwai](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/morgwai/32/34142_2.png) [@Morgwai](https://community.frame.work/u/Morgwai)\ **Post date:** [November 19, 2024, 9:21pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/54 "2024-11-19T21:21:03Z")
+1 for github or even better, a dedicated gitlab instance (historically, relying on any proprietary service tends to backfire sooner or later, but for now github will do). ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [November 19, 2024, 9:37pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/55 "2024-11-19T21:37:11Z")
Maybe a good start would be FW to enter in all the known bugs of the FW16 into the github issue list and then label which of those they intend to fix in BIOS 3.0.4 and FW can then update each one so we can all see progress towards the BIOS 3.0.4 release. We can then also see which bugs might be fixed and which might have to wait. (post 3.0.4) I do understand that it is actually quite difficult to know when a BIOS is ready for release, because the risk of bricking customers laptops is not a 0% risk. I don’t know if the FW 16 is “unbrickable”. By unbrickable, I mean even if you totally corrupt the BIOS flash, there is always a way to recover it without needing to solder anything. For example some desktop and server motherboards can upgrade the BIOS even with the CPU removed!!! Almost 100% of ARM platforms are also unbrickable because they have ROM that can never be wiped, and it always has a feature whereby one can load the BIOS into ram via the Serial port and run that, thus allowing the system to boot and then be recovered. Obviously, if the FW16 BIOS was unbrickable, FW would not need to be so cautious about BIOS updates. ---
**Author:** ![Azure](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/azure/32/18838_2.png) [@Azure](https://community.frame.work/u/Azure)\ **Post date:** [November 20, 2024, 5:16am UTC](https://community.frame.work/t/enabling-software-longevity/49041/56 "2024-11-20T05:16:24Z")
> [@Destroya](#): > > it has been here for a while it has, but I’ve been here longer haha! I don’t want to get this thread too off track, but I do appreciate all your work to keep things nice and tidy! I was mostly just commenting on how my feelings about the forum being less excited could have come from seeing more posts about support since I’ve been here since before there were products for people to even ask for support with! To get back on track, I will say that I am glad to see your report on all the BIOS updates that have been released this year, and I’m glad to know that Kieran and the team are continuing to work hard on more updates in the future! It’s also great to see the whole conversation that has unfolded in this thread since your response to me. I really hope to see Framework continue to make progress on hardware and software longevity, as well as keeping the community in the loop about things! ---
**Author:** ![Lucas\_Lindfors](https://avatars.discourse-cdn.com/v4/letter/l/b2d939/32.png) [@Lucas\_Lindfors](https://community.frame.work/u/Lucas_Lindfors)\ **Post date:** [November 20, 2024, 5:48pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/57 "2024-11-20T17:48:25Z")
Yes! Github would provide a clean slate, and allow for an easy to access, reliable source of information to find bug tracking, bios updates, or news in general regarding software updates. EDIT: Make sure that the github is something that is easily noticed/accessed on the main Framework store page, that way people can easily access it an know where to go for more info. ---
**Author:** ![Destroya](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/destroya/32/47793_2.png) [@Destroya](https://community.frame.work/u/Destroya)\ **Post date:** [November 21, 2024, 8:10pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/58 "2024-11-21T20:10:00Z")
just FYI, we have new beta versions of BIOS for Framework Laptop 16 and Framework Laptop 13 - AMD. ---
**Author:** ![Simon84](https://avatars.discourse-cdn.com/v4/letter/s/9d8465/32.png) [@Simon84](https://community.frame.work/u/Simon84)\ **Post date:** [February 3, 2025, 10:14pm UTC](https://community.frame.work/t/enabling-software-longevity/49041/59 "2025-02-03T22:14:16Z")
> [@Destroya](#): > > Obviously, our words here are not enough. We need to and commit to demonstrating this by actually improving both our iteration speed on software updates and our communication processes around them. What about a Gen12 update? ---
**Author:** ![Schlongevity](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/schlongevity/32/45950_2.png) [@Schlongevity](https://community.frame.work/u/Schlongevity)\ **Post date:** [February 12, 2026, 1:02am UTC](https://community.frame.work/t/enabling-software-longevity/49041/63 "2026-02-12T01:02:29Z")
Can anyone at framework give us an update for 2026? Still the same mission? [Previous page](https://community.frame.work/t/enabling-software-longevity/49041.md?page=2)