About Archive Tags RSS Feed

 

Entries tagged fork

Dirty. Dangerous. Your kind of people.

16 October 2008 21:50

Screen Fork?

There are times when I think of forking. Mostly sanity returns very quickly, though

Still GNU Screen is one program that I use almost constantly, and it seems to work at a glacial pace.

The Debian package has a lot of open bugs against it. Some trivial, some annoying, and some with patches.

Making the program GNU/Linux only would simplify a lot of things. But then again would that be a legitimate reason to fork it?

Me? I'd just like to see some additional primitives.

More QPSMTPD

I've come up with a nice simple qpsmtpd plugin to do spamgourmet-like setup.

This means I can have email addresses:

Plugin code will be in the usual place in the next day or two..

ObFilm: xXx

| 9 comments

 

How could you rationally fork Debian?

9 November 2014 21:50

The topic of Debian forks has come up a lot recently, and as time goes on I've actually started considering the matter seriously: How would you fork Debian?

The biggest stumbling block is that the Debian distribution contains thousands of packages, which are maintained by thousands of developers. A small team has virtually no hope of keeping up to date, importing changes, dealing with bug-reports, etc. Instead you have to pick your battle and decide what you care about.

This is why Ubuntu split things into "main" and "universe". Because this way they didn't have to deal with bug reports - instead they could just say "Try again in six months. Stuff from that repository isn't supported. Sorry!"

So if you were going to split the Debian project into "supported" and "unsupported" what would you use as the dividing line? I think the only sensible approach would be :

  • Base + Server stuff.
  • The rest.

On that basis you'd immediately drop the support burden of GNOME, KDE, Firefox, Xine, etc. All the big, complex, and user-friendly stuff would just get thrown away. What you'd end up with would be a Debian-Server fork, or derivative.

Things you'd package and care about would include:

  • The base system.
  • The kernel.
  • SSHD.
  • Apache / Nginx / thttpd / lighttpd / etc
  • PHP / Perl / Ruby / Python / etc
  • Jabberd / ircd / rsync / etc
  • MySQL / PostGres / Redis / MariadB / etc.

Would that be a useful split? I suspect it would. It would also be manageable by a reasonably small team.

That split would also mean if you were keen on dropping any particular init-system you'd not have an unduly difficult job - your server wouldn't be running GNOME, for example.

Of course if you're thinking of integrating a kernel and server-only stuff then you might instead prefer a BSD-based distribution. But if you did that you'd miss out on Docker. Hrm.

| 10 comments