* Package name    : northstar
  Version         : 1.0.4
  Upstream Author : Andreas Røsdal <andreas.rosdal@gmail.com>
* URL             : https://github.com/nordstjernen-web/northstar-browser
* License         : GPL-3+
  Programming Lang: C
  Description     : minimalist GTK 4 web browser with an original engine

Northstar is a web browser written from scratch in C, with a GTK 4
user interface and a libcurl network stack. Its HTML, CSS, and
JavaScript engine is an original implementation -- it is not based on
Gecko, WebKit, or Blink. Pages render in a sandboxed renderer process
(seccomp + Landlock on Linux); the browser supports HTML5, modern CSS,
modern JavaScript (via quickjs-ng).

The engine is deliberately small and intended to be readable and
maintainable
end to end by a single person.

Website: https://nordstjernen.org/

I believe it is useful for Debian because it adds genuine browser
engine diversity: essentially every graphical browser in the archive
today is a Gecko, Blink, or WebKit derivative. Northstar is a fully
independent GPL-3+ implementation with a small footprint (a single
~8 MB binary linking only against libraries already in Debian).

The upstream build vendors two meson subprojects: lexbor (HTML/URL
parsing) and quickjs-ng (JavaScript). Debian's lexbor is at the exact
version Northstar pins (3.0.0) and I plan to support building against
the system library upstream; Debian's quickjs-ng source package
currently ships no shared library or -dev package, so that copy stays
embedded for now, statically linked. Both are documented in
debian/copyright and debian/README.source. The remaining vendored
single-file components (wuffs, pl_mpeg, minimp3, WAMR) are not
packaged in Debian.

The source code is programmed by Claude and ChatGPT Codex,
and tested and architected by me.

I am the upstream author, and the packaging is prepared and
lintian-clean (builds verified in sid and forky chroots). I intend to
maintain the package long-term and will be looking for a sponsor; an
RFS will follow once this ITP has a bug number.


Regards,
Andreas Røsdal

Le sam. 17 oct. 2026 à 20:37, Andreas Røsdal <andreas.rosdal@gmail.com> a
écrit :

First things first, keep the ITP bug in the loop.

Debian strives when dependencies are not vendored, so this is interesting
to analyze:
https://github.com/nordstjernen-web/nordstjernen-browser#dependencies

Debian is going to favor ffmpeg, for example. (or even gstreamer, if it was
possible).

That being said, this browser looks good, considering it is so young.
It is slow, its UI is looking like old browsers, but it can run windy.com
or youtube.com,
which is impressive.

I tried that one too, doesn't load anything, as expected for a less mature
browser.

These are strong arguments, however, it might be a good idea to not target
next debian stable,
given the youngness of this browser.

Jérémy


Regards,

Karsten, Carsten, Jérémy, Sebastian,

*I pray and beg that you please include Northstar Browser (Nordstjernen) in
Debian, in next stable Forky in 2027.*

*If the Northstar browser is included in Debian Linux, I will do my utmost
to make the browser successful and ensure it works well in Debian,*
*and I will make sure that the Debian project and Debian contributors like
you, and the four of you in particular, will be rewarded*
*and forever honoured for your contributions to Debian, open source
software and for providing diversity of web browser software on the
internet.*

We believe the Northstar browser is well suited for Debian Linux, and that
including Northstar browser is in philosophical spirit:
https://www.debian.org/intro/philosophy - "We want to create a free
operating system, freely available for everyone. Now, when we use the word
"free", we're not talking about money,
instead, we are referring to software freedom."
Northstar browser is secure, because the code-base is new, modern C,
written by state-of-the-art technology such as Claude, and we are also many
contributors who review
the generated source code and test the browser continously.  The source
code is now *245,000 lines of C code*, which is much more maintainable and
easier to review and audit,
 than the source code of Firefox and Chrome where the source code runs into
many millions of lines of source code.

We have applied for a grant from* NLnet Foundation, the Restack*, with
deadline in November 2026: https://nlnet.nl/restack/
Northstar fits the goals on NLNet: "Free and *open source software* and
hardware, open standards, open data, open science, and open core internet
infrastructure are democratising innovation and learning,
 and are together driving society and industry forward at an unprecedented
pace.". We hope NLnet will fund the Northstar (Nordstjernen) browser
because it is an independent, JIT-free, C-based browser engine
 developed in Europe that directly aligns with their Restack mission to
build a secure, open, and sovereign internet stack free from Big Tech
monopolies.

I suggest we focus on including the Nordstjernen-browser project
<https://github.com/nordstjernen-web/nordstjernen-browser>, instead of the
two other variants, Southstar
<https://github.com/nordstjernen-web/southstar-browser> and Northstar
<https://github.com/nordstjernen-web/northstar-browser>. In the future we
can also include the Rust version when it becomes
mature enough. In Debian I suggest we use the English name Northstar /
northstar-browser,
while actually including Nordstjernen:
https://github.com/nordstjernen-web/nordstjernen-browser

We can also have discussions about the dependencies and how to package the
application in Debian,
and we will make changes according to your specifications. For *QuickJS *and
*Lexbor *we recommend that we
use our custom versions of these libraries because they are optimized for
our use-case and improved for
security and preformance.


Sincerely,
Andreas Røsdal

Le dim. 18 oct. 2026 à 09:34, Andreas Røsdal <andreas.rosdal@gmail.com> a
écrit :

For a young software like this, it might be a better strategy to maintain
it in testing, and upload updates to https://backports.debian.org/ to
distribute to stable users.
When in stable, a package is supposed to only receive patches (bug-fixing,
security patches): that might actually hurt your users, because for now
your browser is still growing and changing.
In any case, once this browser is in debian/sid, it might be a good idea to
contact the release team about the best way to deal with it.

Hello Andreas,

I noticed your browser project through the d-devel list, and I was
enticed to look at this ITP. It is not often one sees attempts at new
web browsers!

You write:

The git repository of your project tells, at least to me, a very
different story. As far as I can tell, the first commit is

 commit eb9e73f79fb72d6099cb20cb24928126bfb2d82c
 Author: Andreas Røsdal <andreas.rosdal@gmail.com>
 Date:   Mon Jun 15 08:13:14 2026 +0200

and the latest is

 commit c6a2caabcf9dcda2f3d33f13f34f873044ab26de
 Author: Claude <noreply@anthropic.com>
 Date:   Mon Oct 19 05:57:36 2026 +0000

That's about 4 months. I also see 4 people contributing. In that time,
the four of you have

 $ git log --pretty=format:'' --numstat | awk '{insertions+=$1; deletions+=$2} END {print insertions " insertions, " deletions " deletions"}'
 2623722 insertions, 1527351 deletions

I must say I struggle to reconcile your goal of "more maintanable, ease
of review and audit" with ~160k lines of code being added and ~100k
being removed per person per month.

(In reality it's even worse – a cursory glance indicates that you alone
are the committer for the vast majority of the code, and that activity
was actually spread over just 3 months, but I digress.)

Could you elaborate on this herculean effort? Review alone, not to
mention testing and maintenance, seems beyond hard even if this were the
full time occupation of all four of you.


 Best,
 Gard

Hello Gard,

I suggest that a web browser with a significantly smaller source code base
is easier to maintain. A larger source code size is more difficult to
understand, change, slower to compile and more difficult to maintain.

Today, Nordstjernen has about 0.46 million lines of code including its
JavaScript engine (0.30 million without it) in a 0.011 GB tarball, against
about 38.1 million in a 0.81 GB tarball for Firefox and 160.0 million in a
4.39 GB tarball for Chromium, depending on how one counts, but the main
argument about source code size is clear.


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

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.

I hope you will be interested in helping getting this web browser into
Debian, and that you see the value of having multiple web browsers working
on the Internet, and also that an additional web browser is interesting
research object for NTNU and Sintef.


Sincerely,
Andreas Røsdal


man. 19. okt. 2026, 14:03 skrev Gard Spreemann <gspr@nonempty.org>:

Andreas Røsdal <andreas.rosdal@gmail.com> writes:

All else being equal, I would agree.
people able to review ~2.6M lines of code entering into Nordstjernen's
repository over the course of ~4 months? I undertand that "only" ~0.4M
lines remain, but my question is about the processes involved. Will
there be churn of 20M more lines ("half a Firefox") between two Debian
releases?

I agree that less code is a good thing for maintenance and
reviewability, but it's not the only thing that matters. I'll be blunt:
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.

As just one example: 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? This question is not
rhetorical, it would be beneficial to hear a concrete answer.

Moreover (orthoginally to the previous question): Do you believe that a
Debian maintainer for Nordstjernen can meaningfully modify and work with
upstream's source code without employing the same non-DFSG services that
you yourself have used for the majority of your work in "creating" the
software?

Forgive me, but could you spoonfeed me the point here?

Could you elaborate a bit on why you have come to hold this opinion, and
why Debian maintaners should share it?


 Best,
 Gard

 On Mon, Oct 19, 2026 at 9:20 PM Gard Spreemann <gspr@nonempty.org> wrote:
Debian

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.

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

- 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.

- We review the source code, some parts manually, 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/
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.
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
software evolution and software decay:

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. 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.

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.

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.
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.


Sincerely,
Andreas Røsdal

Andreas Røsdal <andreas.rosdal@gmail.com> writes:

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'"?

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.

That's nice.

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").

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).

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.

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.

It is quite provocative that you refuse to make your point, instead
demanding that the recipient of your text "do their own research".

I think we can all agree on this. The question is, obviously, is
Nordstjernen rigorously maintained? I see very little evidence to
support this.
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.

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?
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

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