Web lists-archives.com

Re: Why choose Debian on server

On Friday 04 January 2019 03:34:31 deloptes wrote:

> Gene Heskett wrote:
> > Just one of the reasons I have 5 boxes here running wheezy yet, one
> > running jessie. But its an armhf, an r-pi 3b TBE, and it is also
> > behind dd-wrt.  Perhaps I should watch the dd-wrt logs to see if
> > Ivan has come calling but no one answered the doorbell?
> >
> :) I bought 2006 or 2007 two industrial PCs (fanless). On is for
> : testing and
> one for production. I also was not able to upgrade from wheezy for
> couple of years, because there was no kernel to work out of the box
> with the chipset and CPU. Few years ago I took my time after office
> work to dig into it. I set up NFS boot/root, so that I can easily test
> and found the problem. I could compile 4.x kernel. After it was clear
> what is the magicall combination of features/configuration it was easy
> to keep up with upgrades. The setup was transferred to the CF card of
> the PC and is happily serving as a FW and VPN.
> Regarding the systemd it is installed as dependency, but not running
> ... Anyway these boards are not booting with systemd, but thanks God
> there are the sysv packages that make it easy to setup, so as far as
> we have choice I am happy with debian.

I've built 3 rt kernels on the pi, takes it about 4 hours. But for the 
life of me, I can't find an installer that will actually do the pi, its 
boot is a separate mess. I'm sure it can be done as I also have a pair 
of rock64's running armbian, and I have seen apt install a new kernel on 
the one I'm playing with, twice to its u-sd card. And installer that 
actually works would be nice as a make install doesn't seem to exist in 
the linux-rt kernel sources I have pulled, from the linux-rt lists 
announcements do not seem to have that recipe in the makefiles.

I've tried several different kernels built for realtime from elsewhere, 
and they all have a common problem to a lessor or greater degree, they 
throw away mouse and keyboard events from their own consoles. Remote 
logins via ssh work well.

This problem varies in its severity with a reboot, do it enough times and 
it will eventually work well, and the uptime is good till the next power 

Other than that, its driving a mesa 7i90HD interface card, which is 
controlling an 11x54 Sheldon lathe quite nicely. writing 32 bit packets 
at 42 megabaud, and reading the responses at 25 megabaud using an 
rpspi.ko driver a prof from Sweden wrote. But its pickity about its 
arms, so it checks for an rpi-3b when its loaded, and exits if its not 
an r-pi-3b. The srcs for that driver are gpl, and part of the LinuxCNC 
src packages any one can download from linuxcnc.org. The spi and the 
radio on the pi are the 2 signals I'm aware of that bypass this usb-2 
pinhole. So on a pi, the spi, built of 4 pins of the gpio, is more than 
quick enough to do the realtime job well as the fpga card handles all 
the stuff needed for control with a reasonably steady 1 kilohertz servo 
loop. The fpga card handles the 50 megahertz stuff, needed to be able to 
drive a stepper motor well.

The rock64 is many times faster because its i/o doesn't have to fight for 
bandwidth to get thru its internal usb-2 hub, so the i/o is much more 
robust, and has 4 Gigs of memory, but the support sucks dead toads thru 
soda straws, so I've made zero progress in a years time in transplanting 
LinuxCNC to it. Their only interest is in doing multimedia servers with 
it, and that doesn't need the sort of realtime LinuxCNC needs.

If you've some links to such installers running on the pi or on the 
rock64, I'd be delighted to check them out.

> regards

To you too deloptes.

Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>