Would any one be willing to port Debian to MINIX?

[Joe Nosay]

Let me know.

[SamuelOPH]

Well, I don't know if I have enough expirence to do, but I'd help.

Do you have anything like a workgroup mail list? I would need to start looking at what I could do.

Samuel Henrique O. P. [samueloph]
Técnico em Informática - UTFPR [2012].
Estudante de Engenharia de Computação - UTFPR.

2016-01-03 16:33 GMT-02:00 Joe Nosay <superb...@gmail.com>:

Let me know.

--
You received this message because you are subscribed to the Google Groups "minix3" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sambuc Lionel]

By MINIX, do you mean the MiniX miniPC (Android-based) from http://minix.com.hk?

If so, you might want to try to reach out to their forum.

This forum is about MINIX, the operating system (http://www.minix3.org).


Regards,

Lionel

[Jacob Adams]

If you are talking about minix the kernel you should just use Debian Gnu/Hurd instead. It's already relatively well supported and is a microkernel like Minix.

Trying to port a kernel designed around a BSD userland to the GNU userland is going to be a lot of work; just take a look at how long it's taken kFreeBSD to even build about 80% of the Debian archive.

Jacob

[Thomas Cort]

It'll be tough without a Debian/NetBSD port to work from, and it will be tough if you don't have at least a few Debian developers pitch in to help. Not impossible but definitely a lot of work.

Is there something that Debian offers that you can't currently get/do with Minix? How could we improve Minix to meet your needs?

TC

[Martin Vahi]

pühapäev, 3. jaanuar 2016 22:06.22 UTC kirjutas Thomas Cort:
> ...

> It'll be tough without a Debian/NetBSD port to work from, and

> it will be tough if you don't have at least a few Debian developers
> pitch in to help. Not impossible but definitely a lot of work.
> Is there something that Debian offers that you can't currently

>  get/do with Minix? How could we improve Minix to meet your needs?

> ...

Thank You, it's very kind of You, but the main problem
with the NetBSD package/port collection
is that it's VERY UNMAINTAINED and therefore BROKEN.

I actually found this thread here by doing a quick search at this MINIX3 Google group
to find out, whether my post might be duplicating. I do not want to induce people to
start remembering, what the "RTFM" stood for and then how to write the "RTFM" in
some constructive and polite manner, but I came to a conclusion that I'm not duplicating.
So, the rest of my current post is the text that I initially considered to be an 
opening posting of a new thread titled:

"Has Anybody Thought About Using the Debian Package Collection with the MINIX3?"


---start--of--my--copy--pasted--message-----


I'm not happy with the current NetBSD package collection

https://github.com/Stichting-MINIX-Research-Foundation/minix/issues/232

and when I as a person, who has never created a single BSD
port in my whole 36-year long life started to look for
documentation, what "manifest"/ant/Makefile/Cmake/whatever-XML-or-language-Foo
I have to write to wrap some software that I tend to
compile anyway, then the NetBSD tutorial at

    http://www.netbsd.org/developers/new-port.html
    (archival copy of the specific version during the time, when I
     looked at it: https://archive.is/AJXIf )

was very superficial and the only link at the
end of the page, the text

    "Valeriy a related paper on how to get started on a new port."

refers to a BROKEN LINK.

    (The URL of the link that as of 2017_08_13 is broken.)
    http://snark.ptc.spbu.ru/~uwe/netbsd/euro2002/krups.ps

On the other hand, the Richard Stallman's GNU Hurd, which,
as I understand, has its historic place in the
friendly rivalry between
the Andrew S. Tanenbaum and the Stallman, is using 
the Debian package collection and is actually PRODUCTION READY,
despite the irony that the MINIX developers got its kernel
running way before the Stallman was just LOOKING FOR a kernel for
its Hurd operating system. If I remember/understand the history
correctly, Stallman asked Tanenbaum, if he could use the
MINIX kernel and then refused the MINIX kernel, because
the free, BSD, license was too liberal for the Stallman :-D


So, fun facts/history to aside, no OS-development team is
able to audit/modify/write all userland applications and
no formal verification suit is able to find flaws that
are not described at the "assertions"/postconditions/preconditions/etc.
of the formal verification suit. As a matter of fact,
not only will there be security holes, but some userland
applications might contain outright malware, carefully
designed by the best malware writers on planet Earth.
(The best does not necessarily mean "best funded", but
money can help, if used smartly.) Obviously weeding out
the various security flaws and intentional malware from
package collections is a novel endeavor, as long as it
is based on labeling, not censorship/blocking, but if the
MINIX3 is aiming to be an operating system for

    SAFETY CRITICAL SYSTEMS

then library level access control in terms of, what gets
loaded/executed is mandatory anyway. May be the MINIX3 already
has that kind of recursive access control, I do not know.
as of 2017_08 I'm new to MINIX, but
my point is that if the operating system has
proper access control, then the mess and malware
at the package collection should not matter and if the
mess at the package collection side can be
contained/jailed from security point of view, then
the "creatively flawed" pile of Debian packages, which
tends to get maintained by a much greater number of people
than the NetBSD collection does, can be a really
practical thing for making the MINIX3

    ACTUALLY PRODUCTION READY
    for
    NON-SAFETY-CRITICAL USE CASES.

As the Debian package collection is so HUGE, a
high quality system can be

    GRADUALLY CREATED

by GRADUALLY migrating from quick-hack-weekend quality
packages to formally-verified-and-exhaustively-tested
quality packages. But, for this GRADUAL MIGRATION
to be possible, there has to be

    SOME SYSTEM

that

    AT LEAST RUNS

I do not mean "just" the kernel side, but I mean
a kernel combined with  userland packages/ports.
Right now (2017_08) the MINIX3 seems to have
a working kernel side and a truly shoddy
userland package collection(the NetBSD ports collection).
If the Debian package collection could be
OPTIONALLY used by those MINIX3 users, who want it, then the

    GRADUAL UPGRADE PATH

would exist. Hence my question: am I the only one
around here thinking about this or has someone already found out
a list of specific pitfalls that accompany the
effort of making the Debian package collection
usable with MINIX3?


Thank You in advance :-)

[Martin Vahi]

The starting point might be to port the GNU toolchain's deepest
dependencies first, may be re-use/refurbish something from the
NetBSD ports collection. Given the GCC extensions to C/C++, the
GCC has to be one of the first ones to be ported.

[Martin Vahi]

Also, given that every COMBINATION OF COMPILER FLAGS gives a de facto new version
of the binary, a solution might be that the versions in the Debian package collection are numbered
combinatorically, by using some simply parseable package name format, like

    minixdebian_SOMEHEXNUMBERHERE_SOFTWAREUPSTREAMNAME_SOFTWAREUPSTREAMVERSION

There would be a separate, userspace, application that keeps
track of the actual dependencies. Dependency calculations might be done
with a help of a theorem prover, may be SPASS

    http://www.mpi-inf.mpg.de/departments/automation-of-logic/software/spass-workbench/

that has a execution time limit for
coming up with a fast, but correct, answer.
The typical, time-consuming, DULL, scanning of HDD
should never be used. According to

    https://packages.debian.org/stable/
    https://packages.debian.org/stable/allpackages?format=txt.gz

the 2017 version of Debian package collection has about 70k packages.
If the different compilation flags and alike are also taken to account, then
there might be about 20 combinations "in average" per package, so the
MINIX3_Debian might have

    70k * 20 = 140k * 10 = 1400k ~ 1500k ~2M

different MINIX3_Debian packages. If loops in dependencies are not allowed, then
the next question for estimating the worst case scenario is, how
to arrange all those 2M packages (read: 2M graph vertices/nodes)
to a set of trees so that the number of edges is maximized.

If it's a single tree, then the answer is easy: the classical tree-drawing
algorithm is that first draw a dot, the root node, and then start attaching
"lollipops" to it. A "lollipop" consists of the sweet candy area, the vertex,
and the handle of the candy, an edge that has the candy-vertex already
connected it. So,

   1 root + 1 "lollipop" gives a tree with one edge and 2 vertices.
   1 root + 1 "lollipop" + one more lollypop gives a tree with 2 edges and 3 vertices.
    ...
   2M vertices minus one vertex for the root gives root vertex + (2M-1) lollipops

That is to say, a tree  with 2M vertices consists of 2M-1 edges. An edge can be
written in RAM by marking down the ID-s of the 2 vertices that the edge connects.
So, the whole graph of 2M vertices should take about

    2M * IDsize + ~2M *2 IDsize

well, all in all, with 8B per ID, ~100MiB of RAM should do. With pre-calculations
and saving of intermittent results, the RAM consumption might be reduced, meaning:
there is a good chance that there is no need to use the terribly slow HDD-IO for
calculating dependencies during the operation of our pkgin/apt-get analogue.
The ID-s of the source packages should be their secure hashes, which
allows them to be downloaded with P2P. The current package distribution
systems tend to depend on central servers, but that's clearly not the way to
go, when there are a lot of huge files to distribute. Central servers should only
offer seeds. That makes the system more DoS-proof and censorship proof.

    (Inspiration for P2P based DoS countermeasures.)
    http://nsl.cs.columbia.edu/past_projects/sos/
    (archival copy: https://archive.is/mUbsc )

I haven't thought of the exact solution yet, but at first the new system might be
kind of "metasystem" on top of whatever the MINIX3 currently
already supports, so that the development is gradual. The nastiest
part is probably the fact that Linux command line tools, for example,
the "ps", give different textual output than the BSD command line tools do.
Without the set of Linux versions of the command line utilities, there's
no point of even trying to port the Debian package collection to MINIX3,
because the various build scripts at the Debian package collection
probably use the various Linux specific command line utilities. If those
are ported, other BSD-s might also adopt the Debian package collection,
"from MINIX3".

As the MINIX3 is supposed to be used for safety critical systems, then
the real-time guarantees and formal verification of utilities like the "ps"
is probably a huge task in its own right. If the specification of the "ps"
turns out to be fundamentally flawed, then the "new ps" needs to be
some dirty compatibility layer between the Debian package collection
and something more reliable. I don't really know right now.

Well, those are my superfical, first thoughts right here right now, "on the spot".

[Martin Vahi]

One complicating matter is that in safety critical systems dynamic
allocation of memory is not allowed, because otherwise the calculation
of finding out, what is the maximum amount of memory that the software
can allocate at the worst case scenario, can become very exhaustive.
Another issue is memory fragmentation related memory allocation time
in the context of real-time systems. Nasty.

[Martin Vahi]

Another, superficial, line of thought is that if the requirements
for safety critical systems, for example, control systems of nuclear
power stations, are in conflict with the requirements of a typical human-usable
software, then may be the effort to make all end-user applications
directly runnable on MINIX3 is a flawed idea from the very beginning,
regardless of the "package collection brand". Add to that the idea that
if the

    /usr/lib

is mounted as a read-only NETWORK DRIVE, then a rootkit
at the computer that mounts the /usr/lib, can not modify the
content of the /usr/lib. The MINIX3 might be the general
piece of software that sits between the hardware and
a set of Linux virtual machines. Basically, if VirtualBox
runs on MINIX3, then that solves the problem.

As a matter of fact, hosting Linux is the approach that
they use at the GenodeOS

    https://genode.org/

and the "federation of Linux Machines" is the idea that they
use at the QubesOS

    https://www.qubes-os.org/

The problem with the GenodeOS is that they don't even
have a CD/DVD that one can download. They had one in 2010, but
as of 2017 it seems that there's nothing, despite a continuous very active
development. So, from that perspective the MINIX3 is clearly
more production ready than the GenodeOS.

The problem with the Qubes-OS is that it's just Linux
on top of Linux and, supposedly, they're also very resource consuming.
As of 2017_08 I haven't tried the Qubes-OS yet, but the Linux-on-top-of-Linux
does not appear appealing to me.

There's also the HelenOS, which boots in seconds, but
the HelenOS does not support multiple users, which makes
it impossible to isolate servers by running different servers
by different users.

    http://www.helenos.org/

May be the most elegant solution might be to forget about
all port collections and try to get some MINIX3 specific containers
running. May be at the age of multi-core computers with
thousands of CPU-cores the idea to run the

    http://bochs.sourceforge.net/

does not sound that crazy any more :-D

I thin I'll try to compile the Bochs and then I'll see, what to think further :-)

[Martin Vahi]

 
Well, the Bochs idea failed, because
the configure script of the Bochs, version 2.6.9,
failed to locate some "pthread" library. According to

    https://stackoverflow.com/questions/36905017/how-compile-with-minix-mthread-h-in-minix

the MINIX is supposed to use something called "mthread"
in stead of the standard pthread that the bochs is designed
to use, but the configure script failed even after doing
a text substitution

    "pthread" -> "mthread"

The pkgin did not install a package named "libmthread",
nor was a package/port named "libthread" available.

Any ideas, suggestions, or do I really have to resort to
GNU Hurd, if I want something more secure than the
monolithic Linux?

Thank You.

P.S. I remember that my effort to compile Ruby
on the MINIX3 also failed with some error message
in the lines of "threading model not found" or something
similar.

[u-l...@aetey.se]

Hello Martin,

On Sun, Aug 13, 2017 at 06:20:23PM -0700, Martin Vahi wrote:
> I'm not happy with the current NetBSD package collection
>
> https://github.com/Stichting-MINIX-Research-Foundation/minix/issues/232

[skipping some good points about various problems]

> Hence my question: am I the only one
> around here thinking about this or has someone already found out
> a list of specific pitfalls that accompany the
> effort of making the Debian package collection
> usable with MINIX3?

You approach the hard problem of software maintenance.

Indeed the Debian packaging concept and the quality of the resulting
system is very good. OTOH it bears an enormous cost necessary to
keep it in this state.

I guess you underestimate the amount of effort necessary to maintain
a collection of packages aimed at a specific and differing environment,
for instance, a kernel without the Linux syscall ABI.

From such a perspective, software maintenance problems are not
Minix-specific and going in depth here would be offtopic.

Consider also that "Minix" is the kernel. Kernel developers do not usually
live (figuratively) in the same world as the deployers, which makes it
harder to understand each other. Naturally, nobody can clearly see the
needs and challenges which one does not experience oneself.

The choice to be API-compatible with NetBSD is a very practical one
and moves the problem of software maintenance somewhere else.
Pkgsrc is not perfect but it is available.

In comparison, there is no Debian package collection for NeBSD in existence.
Worse, an attempt some time ago to create one did not succeed.

I do not say that you are wrong in your reasoning, rather that you may
be aiming too high. The cost of software management, even well organized,
is heavy.

Having said that, I believe another solution would be better compared
to Pkgsrc or to Debian packaging: to place software on a file system
with a global file name space. This is what Aetey has been doing for ages.

This would become possible when Minix gets a suitable networked file
system, like Coda or AFS. Too bad, adding such a file system is also a
noticeable challenge.

Regards,
Rune

[David van Moolenbroek]

Hello,

On Monday, August 14, 2017 at 3:20:23 AM UTC+2, Martin Vahi wrote:

[Richard Stallman's GNU Hurd] is actually PRODUCTION READY

That depends on whom you ask. For example, the wikipedia page on GNU Hurd currently states literally the opposite. I am by no means trying to put down the Hurd project there - I see it as a cool sibling project that faces many of the challenges we do - but I'd like to suggest that assigning such rather arbitrary labels is not particularly meaningful.

If I remember/understand the history
correctly, Stallman asked Tanenbaum, if he could use the
MINIX kernel and then refused the MINIX kernel, because
the free, BSD, license was too liberal for the Stallman :-D

I'm afraid you are pretty far off. If anything, the alleged disagreement was about the compiler: Stallman wanted the Vrije Universiteit's compiler suite (the Amsterdam Compiler Kit or ACK [1] - a commercial product at the time, with Tanenbaum as one of its primary authors) for free, which one of the authors (quite possibly Tanenbaum) refused, in response to which Stallman started working on gcc [2]. As far as I know, only Stallman's side of that story is known, and so even that may be a misrepresentation of what really happened [3].

The MINIX operating system was not BSD licensed until the year 2000. Before that, MINIX was not "open source" in the way we use that term today. However, even if the same situation arose today, "too liberal" would still not be a possible concern: modifications to BSD-licensed code may be released under the GPL without problems.

I have never heard of a direct causal link between the creation of MINIX and GNU Hurd. You may have been thinking of the Tanenbaum/Torvalds debate..

Hence my question: am I the only one
around here thinking about this or has someone already found out
a list of specific pitfalls that accompany the
effort of making the Debian package collection
usable with MINIX3?

 As a general remark to your overall argument, and as a different way of stating what Rune wrote as well: the primary reason that not everything works as expected on MINIX, is that the project is short on manpower. There is nothing wrong per se with the general direction that we set out to pursue (importing NetBSD's userland and packages), but with many challenges on the road to get there and too few people to make substantial progress all the time, it is unreasonable to expect that problems do not exist. As such, the suggestion to break away from that general direction and try something else is simply unhelpful: at best it will not solve the core of the problem, and at worst it will further divide the resources that are already spread thin as it is. If you want to help out, please help us in getting more NetBSD/pkgsrc packages to work on MINIX [4].

Regards,
David

[1] https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
[2] https://www.gnu.org/gnu/thegnuproject.html
[3] given that the I have never seen a reference to the acronym "VUCK" outside of Stallman's telling of the story, and seeing as "VUCK" would not exactly have made for a good acronym for a commercial product, my personal theory is that Stallman changed "ACK" to "VUCK" in his story for dramatic effect; I would love to hear more on this from people involved in the ACK project though..
[4] http://wiki.minix3.org/doku.php?id=developersguide:pkgsrcguide

[Martin Vahi]

Thank You (all/both) for Your answers.

I'm a kind of person, who believes that the person, who
works on the tasks, must have the freedom to make the
final decisions about the task. If some hardworking
people chose the NetBSD out of plain personal taste,
personal preference, then that's good enough of an
excuse for me and I'm happy that people offer the
results of their hard work for free for everyone to use.

    (2015. explanation of "Why BSD?" by Andy Tanenbaum )
    https://youtu.be/hvkn0VcjVPY?t=30m23s

However, I also have a deep belief that if there are
2 teams, for example
MINIX3 ports collection maintainers (hereafter: Team_MINIX)
and Debian package collection maintainers (hereafter: Team_Debian),
then if the Team_MINIX has N people and the Team_Debian has 100*N
people, then the only way the Team_MINIX can be competitive with
the Team_Debian is that the Team_MINIX is either doing something
in some much smarter fashion or the Team_MINIX has automated
a considerable amount of the work that the Team_Debian is doing manually.

A military comparison is the Napoleon army versus a few
modern soldiers with machineguns. My bet is that the small bunch
with machineguns will win the battle, provided that they have
enough ammunition, but rigight now (2017_08_15) the only machinegun analogue
for the Team_MINIX that I'm seeing is the

    "Adapter design pattern"

where some middle-layer connects the Debian package collection
to the MINIX NetBSD userland. As the video about one of the
Debian mini-conferences from 2016_11 points out

    https://www.youtube.com/watch?v=a7yyWpIpeUg

the Debian project is not just a technical project, but
a social project. After all, to get a large number of
people to work on a single project might be something
that MIGHT (I don't know for sure, but I suspect that
this is the case) require some

    SOCIAL ENGINEERING,
 
not only technical engineering. Allowing people to work
at the upper limit of their capabilities is part of
a strategy to keep the endeavor fun and technically
successful and that's also my explanation, why I find
it crucial that people can have the final say within
their "sandbox", "corner of the project". That also
explains some of the reasons, not all, but some, why
people like me should just accept that the MINIX3
uses the NetBSD userland in stead of the Debian userland.
However, in the very same vain, the very same

    SOCIAL EXPLANATION

explains, why there will always be a a nasty mess at least
at some parts of the package collection and why
the Debian package collection is so huge and
"successful-by-size". According to the various MINIX3
architecture introduction videos, the MINIX3 is
an EXCELLENT tool for sandboxing the mess,
keeping the crapware and even malware separated
from clean and carefully crafted software components like
the kernel and some carefully crafted packages/ports.

So, all in all, I think that I'll need to get acquainted
with the various parts of the POSIX standard and
work my way towards the "Adapter design pattern" based
solution from there. Should I ever get it done at all,
and that won't happen for 5 years minimum, given the amount of
other development work that I have to do, the "adapter"
does not need to be cluttering any official ports trees,
so there's no risk that I want to ram some bloat that
others don't like into the general software collection.
Besides, as I said/wrote, I'm not sure that I even
complete the project, but I'll certainly study it,
because I have been working on my own

    "userland distribution"(read: collection of Bash and Ruby scripts)

for may be 2 years, may be more, and I'm currently
at the point, where I'm thinking about how to
package some third party software that I tend to
compile manually. Actually, I've even tried/experimented
with packaging systems like the

    https://nixos.org/nix/

and its ripoff

    https://www.gnu.org/software/guix/

but both of them failed in my assessment. The Nix
people seem to use their package manager only on their
own Nix Linux distribution and haven't tested it
outside of their distro at all, at least that was the
case long time ago, when I tested their package manager.
The GNU Guix failed to compile or crashed or had other issues that
I do not remember any more. Long story short: the Nix
is/was a mess that tries to re-invent the wheel by developing
its own, shoddy, programming language in stead of creating
a "domain specific internal programming language"
(read: library of some general and widely used programming language),
and the Guix people have just tried to do a cleaner Nix, but
failed to notice that if they used some general purpose
scripting language (Perl/Ruby/Lisp/Python/Haskell/...), then
they could have a stable implementation of that language
without imposing end users to study the peculiarities of a
far more incomplete and less tested special purpose programming language.
At least, that's my hazy memory about the Guix. I might be mistaken,
except that the Guix did not pass my tests/assessment.

May be it's a stupid idea, but as of 2017_08_15 I suspect
that may be the solution to thrive for is a kind of solution,
where I have

    my_package
    |
    +---version_for_1_packaging_system
    |
    +---version_for_another_packaging_system
    |
    +---bonnet // contains the common files and scripts

and then some set of tools for testing and dependency calculations.
The MINIX3/NetBSD ports collection is just one
source of inspiration out of many. That is to say,
I have to think about ports collections/package_collections
anyway and I might as well do it in the context of the MINIX3,
which I like from the advertised security features point of view.
(I haven't yet tested/learned the MINIX3 enough to know for sure.)


Thank You for Your answers and
thank You for reading(bearing) my long and
not-so-well-thought-out comment :-)

[Sambuc Lionel]

Dear All, Dear Martin,


I am in a bind, where I do not have much personal time, thus extremely
limited amount of time to spend on my hobby projects, which includes
mainly MINIX.

Martin, I have not read all your emails in details, please excuse me for this.

I will just point out several issues with porting software that you
might not be aware of, for your information:

1. There is a problem of multiple **changing** targets in the long-term
maintenance of software for a platform.

* The compilers evolve (and as software are also prone to bugs)

* The OS (MINIX here) improves, as time goes on, and a patch
required might not be anymore, or even break, as well as simply
new missing feature being supported.

* The ported software evolves, as well as its requirements.
Yesterday a library did not require pthread, today it does, for
example.

2. Compilers are among the most complex piece of software you can find,
and actually require a lot of OS/platform-dependent configuration.

* This requires a lot knowledge of the OS, the compiler, as well as
the platform architecture (x86/arm/etc…) itself.

* This requires a lot of effort to adapt, and keep the patches up to
date, with the ever changing versions of the compiler, and as the
OS and platforms and CPU evolve.


3. MINIX is going towards a NetBSD user land interface, so that
software which compiles and run on NetBSD can be run on Minix simply
by recompiling.

Any software has to "know" in some sense how to behave on all the
OS/platform(s) it supports. This requires extra work on the software
developer part, and most developers nowadays target only one system.

By using NetBSD APIs, we can take advantage of the software which
has been ported to NetBSD, and re-use the same patches.

It often becomes a matter of adding "|minix*" along side "netbsd*"
in configure scripts. 5 years ago it was a small miracle when this
was all that was needed. This is the result of the policy we have
been applying, and of a lot of efforts.

4. PKGSRC vs Debian "Ports".
PKGSRC is actively supported for NetBSD, and although you seem
unfamiliar with it, I can say it contains a lot of patches to get
things working on NetBSD, and many other systems. This includes:

* For high quality software, simply adding the proper detection
in configure scripts

* For less well-written software, patches to the code to add the
necessary support

Maintaining such a thing is a huge effort. Here we can re-use the
effort made towards NetBSD support, and this works better and better
as our implementation of the NetBSD APIs improves.

As I already said, please realise there is already a huge amount of
knowledge included in the PKGSRC tree, in the form of patches to
support NetBSD. This is the biggest part of the maintenance effort, which would be required one way or another if you want to port dpkg.

Porting a package manager is a big project. Think at least several
man-month fulltime to get a proof of concept, and then it requires
on-going work to keep running. This is not a fire-and-forget thing,
where you make it work, and the job is done. I am saying this as it
does not help unless there is not a strong commitment to it, over
several years at least.

Now, I am personally open to any help to improve the situation
regarding packages on MINIX. When I started, there were about 300 packages available, now we can compile several thousand, even if
they do not all work, I still believe this is a huge step forward.

In my opinion, the most critical thing to get is to port the libpthread. When we will have this, I believe we will be able to have
a reasonably clean patch over PKGSRC, and it will make sense to
upstream the result, which will help with keeping up-to-date packages.

Let me finish this by saying that whatever you decide regarding your
endeavour regarding packages on MINIX, I will try my best to answer your
questions and help whenever I can.


Kind regards,

Lionel Sambuc

[Martin Vahi]

Thank You for the answer(s). My reply was/is in the
form of a comment at the previously mentioned

    https://github.com/Stichting-MINIX-Research-Foundation/minix/issues/232

but the purpose of my current post is to add
the following reference to this discussion thread:

    https://github.com/rumpkernel/rumprun-packages

    http://rumpkernel.org/

I guess that might be useful also to those, who believe that the
NetBSD ports collection is the "silver bullet" :-)