Networking is flaky

[Kameko K]

I've noticed the networking in 3.3.0 is very strange. Sometimes it refuses to work, then it starts working again out of nowhere. Sometimes it's incredibly slow, and sometimes it's perfectly fine. It's not my internet, and I'm not sure if it's VirtualBox or not. I'm running Minix 3.3.0 in VirtualBox set up to work on a Bridged Adapter (eth0) using PCnet-PCI II, and I'm using the RealTek 8169 driver (because I have a RealTek 8168 so I figure it's close enough). Is this a common problem? I can't tell if it's a problem with the driver or DHCP. I'd like to get networking to just be stable though.

[David van Moolenbroek]

Hi,

On Saturday, March 7, 2015 at 9:12:43 AM UTC+1, Kameko K wrote:

I've noticed the networking in 3.3.0 is very strange. Sometimes it refuses to work, then it starts working again out of nowhere. Sometimes it's incredibly slow, and sometimes it's perfectly fine. It's not my internet, and I'm not sure if it's VirtualBox or not. I'm running Minix 3.3.0 in VirtualBox set up to work on a Bridged Adapter (eth0) using PCnet-PCI II, and I'm using the RealTek 8169 driver (because I have a RealTek 8168 so I figure it's close enough). Is this a common problem? I can't tell if it's a problem with the driver or DHCP. I'd like to get networking to just be stable though.

Your post is a little confusing, but it sounds like there is some kind of problem between MINIX3 and VirtualBox. You could try another virtual network card, such as virtio_net.

Regards,
David

[grizlyk]

суббота, 7 марта 2015 г., 11:12:43 UTC+3 пользователь Kameko K написал:

Is this a common problem? I can't tell if it's a problem with the driver or DHCP. I'd like to get networking to just be stable though.

I can confirm the issue,  I'm running Minix 3.1.0 in VirtualBox v5.0.12 on a Bridged Adapter or Host only Adapter using Lance (Am79c970A) virtual network card and i got freezing network in minix, constantly, even for ping ICMP. The more reliable work in vbox is internal networking or networking over tty0x only.

>Is the problem with the driver or DHCP?
In network view from minix side it looks like incoming into minix network replay (IP packets) is delayed before /dev/ip code for infinit time and if the delay time is large enough (5-10 seconds) they bursted incoming one by one against new outcoming ip packets (or automaitcal if delay was not infinit in the occasion).

The first picture shows normal single ping request exchange
http://f20.ifotki.info/org/0e6b517909c6ad417e57eea32304cc675f56e5253453584.png 

The second picture shows delayed for 5-10 seconds burst of 3 incoming IP replays for 3 ping outcoming requests
http://f20.ifotki.info/org/5f63d4c00f91ec0d06762735bbc16f405f56e5253453600.png 

Most IPv4 external clients (ftp, telnet) can not work with 5-10 seconds delays between packets and break connections time by time and in additional emits reconnection IP packets that enlarge delays, as results transfer speed is very low.

There is no the same problem with any other guests in VirtualBox i've tryed, so the source of problem is Minix PCI working or lance virtual device in Vbox. It looks like Minix PCI device in Virtual Box can not get incoming packets just in time (does not recieve or does loose any kind of async interrupts or messages if any used in PCI).

Who is familiar with PCI works must be quickly answer what the problem is.

[Antoine LECA]

On 10/08/2016 01:53Z, grizlyk wrote:
> суббота, 7 марта 2015 г., 11:12:43 UTC+3 пользователь Kameko K написал:
>>
>> Is this a common problem? I can't tell if it's a problem with the driver
>> or DHCP. I'd like to get networking to just be stable though.
>>
> I can confirm the issue, I'm running Minix 3.1.0 in VirtualBox
> v5.0.12 on a Bridged Adapter or Host only Adapter using Lance
> (Am79c970A) virtual network card and i got freezing network in minix

Which issue?

The post you are answering (posted 15 months ago) explained a problem of
configuration of 3.3.0 on VirtualBox, where the OP was mixing the
physical adapter of its host (which is irrelevant) with the emulated
virtual adapter. You are using a version which is 10 year older, and you
did not do the same mistake about adapters.

If what you are asking is to fix or enhance networking on MINIX 3.1.0, I
am sure you realize this is not going to happen, or more exactly it has
already been done in part, in posterior and on-going versions.
If this is instead only a report that VirtualBox is an unstable emulator
which has a hard time giving good results with MINIX, we are already
aware, as the reading of this group will show you.


Antoine

[grizlyk]

Note: in addtion to first pending message, i must correct:
Virtual host-only driver looks like is working perfectly (in the tests i had did again and again).
So the problem as if only when Minix+VBox using bridge upon real network card.

Other VBox guests (unix&windows guests) have not any problems with the bridge config.

среда, 10 августа 2016 г., 12:17:05 UTC+3 пользователь AntoineLeca написал:

Which issue?

the OP was mixing the
physical adapter of its host (which is irrelevant) with the emulated
virtual adapter.

The issue is "networking in /minix 3.x.x under VBox/ is very strange. Sometimes it refuses to work, then it starts working again out of nowhere. Sometimes it's incredibly slow, and sometimes it's perfectly fine." I have the same network behaviour.

I do not very understand what do you mean about "mixing the physical adapter with the emulated virtual adapter". Under VBox you can not access any physical devices. If minix 3.3.0 can accept RealTek 8169 from VBox virtual device which is emulating RealTek 8169, there is nothing more to do with RealTek 8168, there is no correlation except the similar names.

 

If what you are asking is to fix or enhance networking on MINIX 3.1.0

No, i think we are speaking about different things, in context of minix 3 nature, the fix is not needed in user level, i am speaking about programming issue in development group, in source code point of view it does not matter version of minix, the problem is not_working code and it is interesting to get answer from developers related to the PCI activity.

 

If this is instead only a report that VirtualBox is an unstable emulator
which has a hard time giving good results with MINIX, we are already
aware, as the reading of this group will show you.

First time i was suspected the VirtualBox issue also, but other OSes are working with VirtualBox perfectly, but with another network VirtualBox virtual device (intel pro/1000 card emulation). I can ask VirtualBox developer team of course, but they can not say me anything about minix IP packets behaviour i've listed in pictures.

 

If you consider matter of my question and is very detailed explanaition, you'll see that incoming IP packets from network VirtualBox virtual device Lance (Am79c970A) delayed from VirtualBox virtual device side for infinit or large time (5-10 seconds!), why?
- first one, they are delayd before VBox VD Lance Am79c970A device, take a look at the picture

http://f20.ifotki.info/org/20ef7bd5efc2fec987ee11bdb63eaa335db5db253501332.png
there is "Atheros phisical device" and "VBox NDIS6 bridge driver" (i suppose it is a kind of 'filter' in chain of windows network processing)
is it possible the devices store IP incoming from "Atheros phisical device" for time 5-10 seconds before deliver them to minix virtual machine?
i do not see reasons of that.

the second picture shows "VBox Host-only network device".

http://f20.ifotki.info/org/f0b4e5b68720de547094b0cb529ebd355db5db253503096.png

This is special VBox driver for windows that pretend to windows as if "VBox Host-only" real hardware device is installed in system. The device is used to locate traffic between windows and guest OSes under VBox. As i noted, the config is working quite perfectly. In cases of both ("Atheros" and "VBox Host-only" devices) we must enable "VBox NDIS6 bridge driver" even for "VBox Host-only" device (the third picture shows error VBox message when i removed "VBox NDIS6 bridge driver" for "VBox Host-only" device)

http://f20.ifotki.info/org/99e769e588d619960f5765d0fa5315b35db5db253503526.png

So VBox either wants "VBox NDIS6 bridge driver" is set just to be or VBox really does unified access to any windows network device via "VBox NDIS6 bridge driver". Take in account, in the last case it is curious why the VBox unified access is working for "VBox Host-only" and does not for "Atheros".

- second one, they are delayed just before "Minix Lance Am79c970A driver" (/usr/src/drivers/lance/lance.c, Created: Jul 27, 2002, Adapted for Minix 3: Sep 05, 2005)

In real hardware the incoming IP packets could be just lost after real time passed, but in virtual "VBox VD Lance Am79c970A device" they are just wrote into very large memory of host PC (memory allocated in windows for "VBox VD Lance Am79c970A device" usage) as if in ordinary buffer and remove them from the buffer for VBox is more hard task then to do nothing when they stored there. In normal way the incoming IP packets must be removed from the queue in Minix side with the help of "Minix Lance Am79c970A driver". To do the delivery "VBox VD Lance Am79c970A device" must post async signal (IRQ pulse for compatile ISA config, or IRQ level for special ISA config or PCI, or execute special PCI transaction 'device message' if PCI bus supprot the messages service) to "Minix Lance Am79c970A driver".
But my listings in first message shows that noone of the possible async signals are not delivered to "Minix Lance Am79c970A driver" (Take in account by OP message, it is curious that the signals are not delivered to "Minix RTL 8169 driver also"). The time when "Minix Lance Am79c970A driver" expects IRQ can be infinit, but in real life there are some process in Minix who listen in /dev/ip and post any IPs to network time by time, the activity of the processes does "Minix Lance Am79c970A driver" awake and the driver begin to got messages from the queue of "VBox VD Lance Am79c970A device", one message by one while the queue is not empty and sleep or not sleep again. You can awake "VBox VD Lance Am79c970A device" manually by post single ping to network is Minix network is freezing.

It looks like more real reasons of minix network failures under VBox.

So, as intermediate facts

- it is curious why the VBox unified access is working for "VBox Host-only" and does not for "Atheros"

- it is curious that the signals are not delivered to "Minix Lance Am79c970A driver" and "Minix RTL 8169 driver" for "Atheros" bridge

- it is curious that the signals are working perfectly for other guests (unix or windows)

I do not know details of Minix PCI works. I think the problem is in Minix PCI works. We should ask who made minix PCI subsystem about the behaviour.

[Sambuc Lionel]

There are 2 major release between MINIX 3.1.x and 3.3.x, and we are progressing towards the next major release.

Can you confirm you get the same behavior when you use MINIX 3.3.0, or even better the release candidate ISO of 3.4.0r2[1]?

If if works with a recent version of MINIX, I don't see the point of spending effort fixing an obsolete release. Currently, the MINIX community doesn't have the developer resources to support old releases.


Kind regards

[1] http://download.minix3.org/iso/snapshot/minix_R3.4.0rc2-373b793.iso.bz2
Accessible through the link "dev snapshots" on http://wiki.minix3.org/doku.php?id=www:download:start

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

[grizlyk]

четверг, 11 августа 2016 г., 9:19:46 UTC+3 пользователь Lionel Sambuc написал:

Can you confirm you get the same behavior when you use MINIX 3.3.0, or even better the release candidate ISO of 3.4.0r2[1]?

Ok. I will try the new kernel of Minix to locate error. And it is also possible the reason of error is "Minix Lance Am79c970A driver" (/usr/src/drivers/lance/lance.c, Created: Jul 27, 2002, Adapted for Minix 3: Sep 05, 2005) to locate the driver error i should find "Lance Am79c970A description and programming" manual.

 

If if works with a recent version of MINIX, I don't see the point of spending effort fixing an obsolete release.

offtopic:

I can not agree with the word "obsolete". Minix 3.1.0 is just a code sample for those who has an interest in minix kernels and changes in the code is useful as itself. Concerning "new efforts of developers", we are speaking about different things, you are working on another task: you get some unix environments and try to accomplish minix kernels under the conditions, it is just another task at least, having another applications. And if we take a look at the efforts, we'll se the multiple things like this:

/*===========================================================================*
 *                              pci_reserve                                  *
 *===========================================================================*/

PUBLIC void pci_reserve(devind)
int devind;
{
        int r;
        message m;

        m.m_type= BUSC_PCI_RESERVE;
        m.m1_i1= devind;

        r= sendrec(pci_procnr, &m);
        if (r != 0)
                panic("pci", "pci_reserve: can't talk to PCI", r);

        if (m.m_type != 0)
                panic("pci", "pci_reserve: got bad reply from PCI", m.m_type);
}

I can not beleive the code like this can be done without intentions, but the intentions are in contradiction with minix kernel purposes and advantages. In other words porting unix environment is usefull to work with minix also, but the idea itself is not the thing we need when we pay attention on minix kernels. 

 

I do not request any, i am just speaking about minix kernel code and we need something (minimal envronment) to kernel could be executed, and from the point of minimal envronment "Minix Lance Am79c970A driver" is very important right now because of VBox supports the device (otherwise we should write new VBox, and it will be much worse). As another case is "Minix Intel PRO/1000 82540EM driver" and "Intel PRO/1000 82540EM description and programming" manual.

 

Best regards.

[grizlyk]

четверг, 11 августа 2016 г., 9:19:46 UTC+3 пользователь Lionel Sambuc написал:

Can you confirm you get the same behavior when you use MINIX 3.3.0, or even better the release candidate ISO of 3.4.0r2[1]?

I have tested MINIX 3.3.0.

Does not works (the OP said truth) 
ping on "Lance Minix3.3.0 device" does not work for "VBOx briged" device
http://f20.ifotki.info/org/682c0592bb80f6bbc2734f73d2e635ac57fd11253604133.png

ping on "Lance Minix3.3.0 device" works for "VBOx host-only" device

Let's check "intel pro/1000" series
VBox emits unrecoverable error
http://f20.ifotki.info/org/a022c3b502f598e9181001aa45c1ff3757fd11253605607.png

offtopic:
I did no insist about the disput, but if one wants to know all and wants to know immediately ...

1.
one can install minix3.3.0, just boot and press shift+F1, and you'll see that minix3.3.0 can not even work with VGA device,
i personally even do not want to continue with so sleazy development
http://f20.ifotki.info/org/89609a92c716be8af737f7cf7be50caa57fd11253604115.png

later i tried to add user, minix3.3.0 did it by default without a home directory, i delete and readd user
later i tried to set password to him, in minix3.3.0 i did it but the user can not login with the password
i was forced to remove pasword in vi, then login new user and reenter the password, in the time of chnges minix3.3.0 emits errors about permission denied

 

then i run "ps l"
it works as "ps lw" does not fit into screen

 

ping on "Lance Minix3.3.0 device" is works for "VBOx host-only" device

 

by default telnet/ftp/ servers in not active
telnet is not exist
man inetd is not exist

 

halt
http://f20.ifotki.info/org/129cc326735c90296173116d25586ef757fd11253604528.png
ACPI/APM does not work
consider usage APM in real mode to switch power off (the BIOS16 based code is very small and can be installed even into MBR loader)

 

set "VBOx briged" device
ping on "Lance Minix3.3.0 device" does not work for "VBOx briged" device

 

halt
set "VBOx briged" device intel pro/1000
change /etc/inet.conf into "e1000"

VBox emits unrecoverable error

 

2.
etc step by step
whom the stuffs were done for?

 

and this is nothing wonderful with the bugs are one by one in the ported code
no one can do the kind of work well

 

and you should no need 2Gbytes of code to enter minix, 200Mbytes is too much
and also you no need to try to pack minix as smaller as you can just to pack

 

there is purpose for which minix is installed and developed and the purpose defines all others (sizes and priopities)
do you think "to work with VGA" is not the kind of work minix should do?

 

if one does not clear realize his own purpose, he just does another work (unknown for me). 

[Jean-Baptiste Boric]

offtopic:
I did no insist about the disput, but if one wants to know all and wants to know immediately ...

I'll bite :-)

 

one can install minix3.3.0, just boot and press shift+F1, and you'll see that minix3.3.0 can not even work with VGA device,
i personally even do not want to continue with so sleazy development

I confirm I can reproduce the issue on QEMU with a development snapshot of Minix (not the latest though, it's not done building yet). This occurs whenever there is nobody logged in the first console.

Occlam's razor says that the reason it wasn't noticed until now is because nobody tried to do that before and thus it wasn't tested. The tty code is also overdue for a major cleanup, which doesn't help.

Rather than saying sleazy development I would rather say lack of manpower and small user community. We don't have an army of developers writing endless amounts of code nor an army of users probing every inch of the operating system like Linux of *BSD. We're even having trouble keeping up with supporting recent hardware since it's a never ending catch-up race.

MINIX isn't Ubuntu. While we always welcome newbies, don't forget this is a hacker's operating system testbed first and foremost, not a finished, defect-free product. Getting your hands dirty is part of the fun and an implicit requirement.

later i tried to add user, minix3.3.0 did it by default without a home directory, i delete and readd user
later i tried to set password to him, in minix3.3.0 i did it but the user can not login with the password
i was forced to remove pasword in vi, then login new user and reenter the password, in the time of chnges minix3.3.0 emits errors about permission denied

10.0.2.15# useradd boricj
useradd: Warning: home directory '/home/boricj' doesn't exist, and -m was not specified
10.0.2.15# userdel boricj
10.0.2.15# useradd -m boricj
10.0.2.15# ls /home
boricj
10.0.2.15# ls -a /home/boricj
.
..
.cshrc
.login
.logout
.profile
.shrc
10.0.2.15# passwd boricj
Changing local password for boricj.
New password:
Retype new password:
10.0.2.15#

Failure to read man useradd and failure to pay attention to error messages will result in failure to create a user.

then i run "ps l"
it works as "ps lw" does not fit into screen

It fits if you're using xterm, a serial console or a remote SSH shell, which is what the majority of people use to interact with MINIX these days.

Fixing this bug would require writing a x86 framebuffer driver and heavy modifications to TTY. It's not going to happen until somebody makes it happen. So far, no one volunteered.

ps lw | less will allow you to scroll to the right in the meantime if you do not want to run X11.

 

 by default telnet/ftp/ servers in not active

No modern UNIX system ever activates these services by default during installation and for good reason. Telnet is one packet sniffer away from stealing your passwords sent in cleartext, it was already a security disaster 40 years ago. Running it on anything else than a trusted, air-gapped network is a really bad idea.

telnet is not exist
man inetd is not exist

We do not have telnet nor telnetd. Mostly because OpenSSH is working on MINIX perfectly. Also because our Berkeley sockets API couldn't handle NetBSD's telnet programs last time it was checked, which is a POSIX conformance bug.

We do not have inetd. That doesn't prevent the OpenSSH server from working.

halt
http://f20.ifotki.info/org/129cc326735c90296173116d25586ef757fd11253604528.png
ACPI/APM does not work
consider usage APM in real mode to switch power off (the BIOS16 based code is very small and can be installed even into MBR loader)

APM has been obsoleted 15 years ago. Windows doesn't support it since Vista back in 2006 according to Wikipedia.

There is an ACPI driver in MINIX, but it only handles low-level interrupt routing stuff. It does not support any kind of power event. This is a missing functionality.
 

halt
set "VBOx briged" device intel pro/1000
change /etc/inet.conf into "e1000"

VBox emits unrecoverable error

Technically, if MINIX can crash VirtualBox this is a bug in VirtualBox, since a virtualized operating system shouldn't be able to crash its hypervisor. However, this is also a bug in MINIX since this driver is thus unusable on VirtualBox.

Either way, a quick search on the issue tracker at GitHub shows that this particular issue has been fixed a few months ago in master, but there hasn't been a stable release of MINIX with the fix yet. You'll need to either grab a development snapshot ISO or build one yourself.

 

2.
etc step by step
whom the stuffs were done for?

 

and this is nothing wonderful with the bugs are one by one in the ported code
no one can do the kind of work well

Feel free to start coding and submit patches.
 

and you should no need 2Gbytes of code to enter minix, 200Mbytes is too much
and also you no need to try to pack minix as smaller as you can just to pack

You'll need all this disk space if you install every last component available, which what the setup script will do. That includes MINIX core files, X11, the C compiler, development files, manual pages and every program imported from NetBSD.

I haven't tried to minimize MINIX beyond shrinking the installation CD a bit, but the boot ramdisk is about 4 MiB and the other boot files are 2 MiB. You could probably add things to make it usable as an interactive system and pack a minimal yet usable, custom-fit MINIX inside a 64 MiB disk image with space to spare, bootable with 32 MiB of RAM.

I made a port of MINIX on the Raspberry Pi, complete with my presentation's slides over the HDMI port and a shell. The ramdisk weighted in at 6 MiB, pictures included.

The setup program is a shell script for quickly installing a reasonable MINIX system on a hard drive. You don't have to use it.

there is purpose for which minix is installed and developed and the purpose defines all others (sizes and priopities)
do you think "to work with VGA" is not the kind of work minix should do?

My PLC plug (Power-Line Communication) doesn't have a VGA card, USB plugs, HDMI, SATA, Firewire, SD card reader, WiFi, Bluetooth or an audio jack. Yet MINIX could (theoretically) run on it and provide my PlayStation 3 with Ethernet connectivity.

Or take Network-Attached Storage (NAS) appliances. My venerable Synology DS-108J doesn't have VGA, yet it runs Linux and it streams movies to my PlayStation 3.

Not everything with a 32 bit processor has to work with VGA. In fact, most of them don't.

And by the way, MINIX does work with VGA, which is ironically why you complained about 80 columns not being enough columns for ps lw.

if one does not clear realize his own purpose, he just does another work (unknown for me). 

Although that may make a decent motivation poster title, I take it you haven't read any of the publications available at http://wiki.minix3.org/doku.php?id=publications, do not know about the history of MINIX or watched any of Andy Tanenbaum's talks on MINIX.

It says right here on the front page of minix3.org : "MINIX 3 is a free, open-source, operating system designed to be highly reliable, flexible, and secure. It is based on a tiny microkernel running in kernel mode with the rest of the operating system running as a number of isolated, protected, processes in user mode."

Try kill -9 $(ps aux | grep at_wini | cut -f 3 -d ' ') and watch MINIX gracefully recover from a crashed hard disk driver, the one containing the root file system. Try the same trick on Linux and you'll have a crashed operating system on your hands.

[grizlyk]

пятница, 12 августа 2016 г., 3:03:52 UTC+3 пользователь Jean-Baptiste Boric написал: 

offtopic:

Rather than saying sleazy development I would rather say lack of manpower and small user community.

I have a break time to claim evidence. The any design of not working things is incorrect, no meaning why.
 

MINIX isn't Ubuntu.

Minix design must be involved to keep system small, clean and in working state. You certainly can continue to make a Linux environment with minix kernel, but i'm not sure the result 'll be usefull for anybody and especially for minix users and i showed why.

 

No modern UNIX system ever activates these /network/ services by default during installation and for good reason.

Minix is not a common UNIX system and is intended for development and should be equipped with most compatible network tools and protocols. In modern time the development 'll be done in virtual environment, there is no sniffers there, if you want to make user workspace with minix you should install separated pakage to update security and disable development services.

 

APM has been obsoleted 15 years ago.

It does not matter the "obsolete" of the protocol, because any correct 16 bit BIOS should provide APM and it is very easy to power off system with APM in real mode for x86.

 

Feel free to start coding and submit patches.

minix/3_1_0/src/kernel   <dir> 245384 bytes

One can patch the 3.1.0 system of 240Kbyte source code with desing docs applied and can not patch 3.3.3 system of 2Gbytes in size, that in addition has no file manager (as FAR file manager) and can not work with telnet, VGA, network cards etc.

 

I made a port of MINIX on the Raspberry Pi

And by the way, MINIX does work with VGA

If anyone intends in future to port minix 3.3.0 to VirtualBox compatible environment he should support Lance network card, it is required for the VirtualBox system.

 

If anyone intends in future to port minix 3.3.0 to IBM PC/AT compatible environment he should support VGA, it is required for the IBM PC/AT compatible system, and there are some other items in the concrete hardware he should support if he wants to be compatible with the concrete machine on real hardware level (without help of other OS to run in).

[grizlyk]

пятница, 12 августа 2016 г., 3:03:52 UTC+3 пользователь Jean-Baptiste Boric написал:

offtopic:
 

10.0.2.15# passwd boricj

Changing local password for boricj.
New password:
Retype new password:
10.0.2.15#

 

Do you really beleive i 've lied? No? "passwd" was not worked as expected from root side - i was unable to change user password.

But i want to ask the next question, maybe it will be usefull for anybody.
what the "3.3.0" number does mean in minix development tree?

 

I.
in theory minix development should be separated into logical parts:
1. kernel improvements
2. kernel related code
 the code must be recompiled and even redesigned for each kernel variation
 2.1 kernel drivers and severs
 2.2 system boot stuffs
 2.3 kernel using application libraries, that provide binary interfaces to applications
3. kernel independed code  
 the code can be recompiled but it is not required

 

programs of the 2 and 3 parts must be in other order divided into:
1. specific minix tools
2. ported software

 

minix setup must provide choices to install/remove:
1. base sets of one or several pakages
 1.1 base hardware config support set to work with concrete machine type (PC/AT, PCI, etc)
 1.2 base (minimal) cmdline environment set to work with installed minix files and to tune minix config
 1.3 base network set to work with configured NICs and via serial devices
 etc
2. separated pakages
 2.1 specific hardware device drivers (SCSI, NICs, sound cards, ets)
 2.2 ordinary app packages
 etc

 

In fact some BSD distributives do the similar division.

 

II.
So, what parts of code affected for each minix version number development? Completely all parts?

 

if the minix development was in the order one can select parts of system to get own desired config, in the case you will not be able to say "the kernel version is wrong" just becaus it is optional install.

 

III.
For developmen purpose trivial design is often better then compicated design.
At least minix 3_1_0 is attractive because of it's small size.

 

There is relation "design_weight/usefull_unremoveable_properties".
If you will add 1 Mbyte of code size for 1 byte of unremoveable properties the design is not very good.

It is not easy to decide "what parts of code you really need to do good thing" - "trim condition".
But it looks like new versions of minix feel itself free to add any new properties without hesistations.

 

To relax the "trim condition" there is next property of good design as "orthogonal parts of design".
In best case we can use only the parts of code you need to change do not dig all code around.
And minix 3_1_0 relax the condition by it's small size if the parts of solid crosslinked code is more large than you want.

 

So, what the reason for someone to use new minix versions which are developed for other purposes?

[Jean-Baptiste Boric]

No modern UNIX system ever activates these /network/ services by default during installation and for good reason.

Minix is not a common UNIX system and is intended for development and should be equipped with most compatible network tools and protocols. In modern time the development 'll be done in virtual environment, there is no sniffers there, if you want to make user workspace with minix you should install separated pakage to update security and disable development services.

I should make clear that I do not oppose telnet or ftp support in MINIX.

However, I personally do not need telnet because OpenSSH meets all my remote access needs. Someone else with another use case of MINIX may disagree.

Remember, volunteers work on their own spare time on things they can and want to work on. If someone needs telnet in MINIX, that person can either make it work himself or convince/pay someone else to do it. I personally won't work on telnet support, but that doesn't prevent someone else from doing it.

APM has been obsoleted 15 years ago.

It does not matter the "obsolete" of the protocol, because any correct 16 bit BIOS should provide APM and it is very easy to power off system with APM in real mode for x86.

Computer firmware is very buggy in the real world.

Most motherboard manufacturers *only* care about Windows compatibility, not implementation correctness. ACPI *has* to work in order to run Windows. APM doesn't have to work in order to run Windows. Therefore, in real, recent hardware I expect ACPI to work much more reliably than APM. Worse, according to osdev recent computers tend not to support APM anymore.

Virtual machines do not suffer the same issues than real computers do, so that argument does not apply (as much) in that case.

Again, I do not oppose implementing APM support in MINIX per se. If someone sends an acceptable patch, I would not oppose it.

(Even if I was opposed to it, I am not a core developer. I have no authority over the MINIX source code tree.)

Personally, I am far more concerned by the current status of pkgsrc in master. gettext doesn't build which in turn makes tons of packages not buildable, like Git, GNU make, nano... Not being able to build Git or a decent text editor is presently more of a problem for me than the lack of self power down at shutdown.

Feel free to start coding and submit patches.

minix/3_1_0/src/kernel   <dir> 245384 bytes

One can patch the 3.1.0 system of 240Kbyte source code with desing docs applied and can not patch 3.3.3 system of 2Gbytes in size, that in addition has no file manager (as FAR file manager) and can not work with telnet, VGA, network cards etc.

MINIX has evolved a lot since 2006 and its source code grew accordingly in size, but you're not forced to use the latest version. You can use MINIX 3.1.0 and modify it if you want, or even an older version.

If you really aim for a really tiny Unix-like operating system to study, one even smaller than MINIX 3.1.0, I'd suggest xv6. The *entire* source tree is under 600 KiB, the Git repository is under 20 MiB and there's a really good booklet that describes it in great detail. It is not self-hosted though.

[Sambuc Lionel]

> On 31 août 2016, at 00:26, Jean-Baptiste Boric <jblbe...@gmail.com> wrote:
>
> No modern UNIX system ever activates these /network/ services by default during installation and for good reason.
> Minix is not a common UNIX system and is intended for development and should be equipped with most compatible network tools and protocols. In modern time the development 'll be done in virtual environment, there is no sniffers there, if you want to make user workspace with minix you should install separated pakage to update security and disable development services.
>
> I should make clear that I do not oppose telnet or ftp support in MINIX.
>
> However, I personally do not need telnet because OpenSSH meets all my remote access needs. Someone else with another use case of MINIX may disagree.

Actually telnet and ftp are available out of the box, they just need to be activated. See their respective man pages and /etc/rc.daemons.dist.

> Remember, volunteers work on their own spare time on things they can and want to work on. If someone needs telnet in MINIX, that person can either make it work himself or convince/pay someone else to do it. I personally won't work on telnet support, but that doesn't prevent someone else from doing it.

Exactly.

> APM has been obsoleted 15 years ago.
> It does not matter the "obsolete" of the protocol, because any correct 16 bit BIOS should provide APM and it is very easy to power off system with APM in real mode for x86.
>
> Computer firmware is very buggy in the real world.
>
> Most motherboard manufacturers *only* care about Windows compatibility, not implementation correctness. ACPI *has* to work in order to run Windows. APM doesn't have to work in order to run Windows. Therefore, in real, recent hardware I expect ACPI to work much more reliably than APM. Worse, according to osdev recent computers tend not to support APM anymore.
>
> Virtual machines do not suffer the same issues than real computers do, so that argument does not apply (as much) in that case.
>
> Again, I do not oppose implementing APM support in MINIX per se. If someone sends an acceptable patch, I would not oppose it.
>
> (Even if I was opposed to it, I am not a core developer. I have no authority over the MINIX source code tree.)

But this is still true, a good, clean and useful patch will not be rejected. At some time it might take a bit longer to merge them, but this is mostly due to limited time to review and merge the patches.

> Personally, I am far more concerned by the current status of pkgsrc in master. gettext doesn't build which in turn makes tons of packages not buildable, like Git, GNU make, nano... Not being able to build Git or a decent text editor is presently more of a problem for me than the lack of self power down at shutdown.

That I would like to hear more about, either as a ticket on github, or as a separate thread.

>
> Feel free to start coding and submit patches.
> minix/3_1_0/src/kernel <dir> 245384 bytes
> One can patch the 3.1.0 system of 240Kbyte source code with desing docs applied and can not patch 3.3.3 system of 2Gbytes in size, that in addition has no file manager (as FAR file manager) and can not work with telnet, VGA, network cards etc.

First of all, 95% or more of those 2GB are regular NetBSD userland, tools, and libraries, barely patched in order to work with the more limited set of system calls and APIs the MINIX 3 operating system supports.

All the MINIX 3 OS code is in the minix/ sub directory, which is currently about 28MB in size. Compared to 3.1.0, the code has actually been reorganized to make it much clearer what is driver code, system servers, kernel, and utilities.

What I mean is that using the NetBSD userland allowed us to actually remove code of the user utilities from the minix subfolder, while keeping and improving the functionality and stability of said utilities.

This is still a work in progress, which is why you will still find some utilities in minix/commands, which are :
1. to be removed and replaced with the NetBSD equivalent, or
2. kept and moved to minix/bin, minix/sbin, minix/usr.bin, minix/usr.sbin as needed).

IIRC this actually include telnet and telnetd. ftp and ftpd have already been replaced by their NetBSD counter parts (usr.bin/ftp and libexec/ftpd).

> MINIX has evolved a lot since 2006 and its source code grew accordingly in size, but you're not forced to use the latest version. You can use MINIX 3.1.0 and modify it if you want, or even an older version.

Very true, and you can even create a fork, and publish it (or keep it private, if you choose so), so long you respect the BSD license.

> If you really aim for a really tiny Unix-like operating system to study, one even smaller than MINIX 3.1.0, I'd suggest xv6. The *entire* source tree is under 600 KiB, the Git repository is under 20 MiB and there's a really good booklet that describes it in great detail. It is not self-hosted though.
>

There is also retroBSD (http://retrobsd.org), and whole lot of others.

[Antoine LECA]

On 30/08/2016 22:26Z, Jean-Baptiste Boric wrote:
>
>>> APM has been obsoleted 15 years ago.
>>>
>> It does not matter the "obsolete" of the protocol, because any correct 16
>> bit BIOS should provide APM and it is very easy to power off system with
>> APM in real mode for x86.
>

> Most motherboard manufacturers *only* care about Windows compatibility, not
> implementation correctness. ACPI *has* to work in order to run Windows. APM
> doesn't have to work in order to run Windows. Therefore, in real, recent
> hardware I expect ACPI to work much more reliably than APM. Worse,
> according to osdev recent computers tend not to support APM anymore.

Another reason probably even more important, is that APM is rooted on
16-bit real mode BIOS; that interface cannot be used from 64-bit
operating system, unless using very convoluted paths which requires
stopping all other functions and switching the CPU to i386 mode for a
while, or using VM80886 emulators and hoping the BIOS does not use mode
switching of its own; both solutions are prone to problems and bugs.

And 16-bit protected mode interfaces of all trades, being APM, VESA or
whatever, were never used widely and were known to be full of bugs (did
you ever use OS/2 1.x?) to the point programmers tended to avoid them
entirely during the '90s and almost always went the VM8086 road back to
using "proved" BIOS-based "real mode" interfaces as used by MS-DOS (like
was doing MINIX until 2011 to use USB drives; or powering the machine off.)

Anyway, all of these considerations are quite remote from MINIX3.


Antoine

[Jean-Baptiste Boric]

> Personally, I am far more concerned by the current status of pkgsrc in master. gettext doesn't build which in turn makes tons of packages not buildable, like Git, GNU make, nano... Not being able to build Git or a decent text editor is presently more of a problem for me than the lack of self power down at shutdown.

That I would like to hear more about, either as a ticket on github, or as a separate thread.

It fails while building gettext-tools (inside gnulib) because of POSIX spawn stuff. Not sure if my commit about POSIX spawn support some time ago is causing it.

I'll file an issue once I collected enough information about it, before the end of the week. Mostly checking if reverting the commit will unbreak gettext.

[Jean-Baptiste Boric]

> Personally, I am far more concerned by the current status of pkgsrc in master. gettext doesn't build which in turn makes tons of packages not buildable, like Git, GNU make, nano... Not being able to build Git or a decent text editor is presently more of a problem for me than the lack of self power down at shutdown.

That I would like to hear more about, either as a ticket on github, or as a separate thread.

I'll file an issue once I collected enough information about it, before the end of the week.

False alarm. I just noticed that the default branch of my Github fork repo is 3.3.0 (compared to no default branch for the upstream). I can't believe I missed that...

Packages seems to build fine so far. X11 processes still crash under stress every now and then.