But at least he's willing to work with them.
But at least he's willing to work with them.
> I don’t actually mind if System76 doesn’t use fwupd and the LVFS, I just don’t want people to buy new hardware and be disappointed.
As someone uninvolved who occasionally looks at linux laptops, this is really useful information for me. One of the (apparently) core developers of (apparently) a tool that allows cross hardware compatibility for linux is saying "this laptop does not adequately support arbitrary versions of linux, and they don't have a compelling technical reason why".
If what the author wanted to do was simply to spread information, the post would have been the length of a single Twitter post:
Make note: System76 uses a custom fw update util only bundled with "Pop_OS!".
The entirety about this post is to hang System76 out for their process and decision, explaining how they are wrong, and how the author is willing to forgive them for this wrongdoing without the apology the author feels is in place. The post is nothing but emotional.(I have no strong opinion about System76's decision, but I find this post format to be awful.)
If sharing the process issues was valueless, it would definitely seem personal. But it doesn't seem valueless for me. When making informed judgement about which companies to throw in with, their process matters.
It's like MongoDB from days of yore. There was someone who reported a bug and the mongo team were jerks about it. I've specifically chosen not to use Mongo because of that interaction. Don't want my projects hinging on dev teams with good marketing sense but poor communication skills. Don't want my hardware depending on vendors who can't make nice with the FOSS community.
I agree that sharing process is important, and your MongoDB example is a good one (not that I am short on reason to not use MongoDB).
However, I don't find the post to describe System76 processes beyond "there was email communication", and that progress towards a goal aligning with the author's preferences was suspended. The only thing I can conclude from it is that the author is in disagreement with System76.
From the format of the post, I would quite frankly be biased towards assuming that the problem lies with the post author. This assumption is of course not based on tangible evidence, which would require access to the email exchange to obtain.
You're trying to work with that company, help them to use your platform. There might already be some personal attachment here if you really believe in the platform you created and take personal pride in every OEM hopping on board, but even if he just believes in the "greater good" of having this unified experience on Linux I can see how he wants this to happen.
Then there is Apparently some capable person at system76 who reverse engineered the proprietary updater they had to use before, and this is where things start going wrong. This is the part I have experienced personally on both sides. The system76 guy gets a great ego trip out of his achievements, somehow management/marketing hears about it and together they brainstorm how they can build their own independent update infrastructure. Marketing sees their unique selling point, dev sees exciting new things to create, feels like internet super hero, tells lvfs how shitty their whole approach to this is since super-dev has so much more insight into how this should be done properly.
However, two inputs to this. One is that it appears that S76 had to work to do in order to become compatible with LVFS, and ended up just extending this to the point where they had an updater. Two, I can't possibly imagine anyone considering a custom firmware updater a selling point, especially not at the cost of not getting the free labor of having someone else maintain both tools and infrastructure.
I kinda suspect we were dealing with a "Hmm, we could just sprinkle a bit of UI on this and then move on to other tasks", knowing that it was suboptimal, but not finding the issue important for the time schedule.
When I cut corners as a programmer at work, it's usually due to time constraints, priorities or annoying customers, and leaves a bad taste in the mouth of developers and managers alike...
Instead he went over their email exchanges and trivialized the amount of work they need to invest to change systems and what they needed to do to rectify the situation. Oh but they're no need to apologize, just right the injustice.
He completely ignores the fact that they're a business with external motivators driving their decision (i.e. needed to ship, Meltdown, Spectre) and he just complains that they left him hanging.
Sure they could have sent him an email giving him a heads up on what was going on and why they were tabling the LVFS implementation but this sort of thing happens all the time in industry.
We hope to make this all a moot point with completely open firmware in the future, but that's a long and difficult road we're on.