Thank you for your feedback. I would appreciate feedback from more people to get a more nuanced and neutral view, preferably from someone who actually works on real software development in 2026, someone with education in computer science, also considering that software development has changed with the introduction of AI llms.
Regards, Andreas Røsdal On Tue, Oct 20, 2026 at 8:27 AM Gard Spreemann <[email protected]> wrote: > Andreas Røsdal <[email protected]> writes: > > > On Mon, Oct 19, 2026 at 9:20 PM Gard Spreemann <[email protected]> > wrote: > >> Will there be churn of 20M more lines ("half a Firefox") between two > Debian > >> releases? > > > > I don't think so. However, a high rate of change in the source code > > could be a positive sign, that we are improving the actual product, > > constantly refactoring the code and doing real software engineering > > work, the way it can be done in 2026, using AI llms such as Claude, a > > state-of-the-art software development process for 2026. > > What happens when a serious problem is found in a version of > Nordstjernen shipped in Debian, and upstream has since undergone > "constant refactoring and 'real software engineering work'"? > > >> I worry that the processes upstream are unacceptable. I fear that huge > >> chunks of Nordstjernen's code comes straight from an LLM without human > >> review whatsoever. I do not believe that this is a foundation for a > >> healthy Debian package. I'd love to be shown wrong. > > > > The process is typical for many open source projects on Github, these > > are some aspects of the current process: > > > > - There are frequent public releases, 34 so far, people use the browser > and report bugs, we fix the bugs. > > See the essay The Cathedral and the Bazaar by Eric S. Raymond. > > https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar > > 34 releases in 4 months. Since there's ~24 months between Debian > releases, can we expect ~200 Nordstjernen releases between each Debian > release? Are you in a position to backport (without "constant > refactoring") serious fixes a hundred releases back? If you do not, will > whoever were to maintain this in Debian be able to do it? Would they > need to use a non-DFSG piece of software to do so? Again, I worry that > with your development team of 1-4 part-time people that this is > something that will be flat out ignored. > > > - The developers and I use the browser and see for ourselves how it > > functions on the websites we test it on. It is quite easy to see if > > the browser successfully supports a particular website just by > > watching it. > > That's nice. > > > - We review the source code, some parts manually, > > Just as a rough estimate, what proportion of the ~2M lines of coded > added throughout the project's 4 month lifetime would you say you > reviewed? (To me, review is fundamentally a human process, but if you'd > like, you can interpret the question to mean "manually reviewed"). > > > and frequently review the full source code using Claude with a > > specific focus, such as: > > - Security review > > - Updating dependencies > > - Performance profiling > > - Searching for memory leaks and infinite loops. > > - Reviewing the code with focus on the actual HTML and CSS > specifications. > > - Continuous integration and tests run on Github, with various tools > there for code quality. > > - The review of the code is more on a high-level abstraction, using the > LLM as a tool for understanding the code. > > - We use web-platform-tests frequently to test the browser: > https://web-platform-tests.org/ > > It sounds more and more like Nordstjernen is merely the output of a > non-free machine with very little review. It seems to me to be extremely > unwise to accept hundreds of thousands of lines of code that nobody has > even looked at into Debian (for both technical and legal reasons). > > >> What would happen if someone discovered a security > > issue (or legal issue, or RC bug, or whatever) in a version of > > Nordstjernen (hypothetically) shipped in Debian? > > > > If a security issue, or any issue is discovered, then it can be fixed > > as soon as possible. > > This doesn't answer my question at all. My question pertains to the > actual process of fixing it. You can't answer "how will problem X be > solved" with "we will solve problem X as soon as possible"; this is > meaningless. Please see for example the scenario in my first paragraph > of this email if you want something concrete to latch onto. > > > The browser is very secure, and we try to make design decisions with a > security perspective. > > - The browser doesn't have a JIT compiler which is a common source for > security vulnerabilities in Firefox and Chrome. > > - On Linux it uses Landlock in the kernel to restrict access control: > > https://docs.kernel.org/userspace-api/landlock.html > > I agree that it seems like a very good idea for a browser to use > Landlock. But "the browser is very secure" is a meaningless statement, > and at any rate completely misses the point of my question: the point is > about your *processes* when e.g. security issues arise. This matters a > lot for Debian. > > >>> Please see "Lehman's laws of software evolution", which is about > software evolution and software decay: > >>> https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution > >> > >>Forgive me, but could you spoonfeed me the point here? > > > > Manny Lehman (computer scientist) studied the evolution and decay of > > software, I encourage you to see his research, since it is relevant > > for the discussion of software maintenance. I remember reading some of > > his work as a student at NTNU. The point is to encourage studying the > > research on software evolution. > > It is quite provocative that you refuse to make your point, instead > demanding that the recipient of your text "do their own research". > > > For example he defined a law which states that > > " the quality of an E-type system will appear to be declining unless it > is rigorously maintained and adapted to operational environment > > changes", > > which is relevant for this discussion about software quality and > > software maintenance. > > I think we can all agree on this. The question is, obviously, is > Nordstjernen rigorously maintained? I see very little evidence to > support this. > > >>> Nordstjernen was implemented initially using Claude, in the "AI-era", > >>> while Firefox and Chrome has been implemented over a very long time, > >>> and accumulated software bloat, decay and is more complex to maintain, > >>> in my opinion. > >> > >> Could you elaborate a bit on why you have come to hold this opinion, and > >> why Debian maintaners should share it? > > > > This is based on my own observations, I have previously studied the > > source code of Firefox to some extent in order to better understand > > it, and this was part of my motivation for creating this web browser > > project. You don't have to share my opinion on this. > > Friendly advice: If you're trying to encourage a Debian developer to > maintain a package for your software, it's important that they are > convinced of beliefs that you hold if those beliefs are what underpin > the software's quality. > > > In summary, the development process of this web browser is adapted to > > the modern technology where AI LLM tools actually write the source > > code. We use AI LLM tools, manual testing on real websites, testing > > harnesses and testing on real users to improve the browser. > > Could you spell it out in black and white? Is the code of Nordstjernen > reviewed (by the human beings who are responsible for the project), or > is it not? > > > What I have described here is how things have been done so far, of > > course the development process can be improved and changed as the > > project evolves and we get a better understanding, or if you have > > specific improvements to the process that you see are needed. > > My point is just that you are unlikely to get any Debian developer to > agree to spend their volunteer time maintaining a package for a piece of > software wherein 2M lines of code enter into 34 releases in 4 months > from an unknown origin without the 1-4 people responsible even looking > at the code. > > Now speaking just personally: This is insane, and nothing more than a > toy or an experiment, certainly not a fit for Debian by a mile. > > > Best, > Gard >
