On Fri, Nov 20, 2015 at 1:46 PM, Rodrigo N Hernandez < re...@minasambiente.com.br> wrote:
> Hello Mehmet, > > I'm not entirely sure if I understand what is the goal but if you're > talking about computer labs: > One option would be using vnc sessions (tightvnc e.g.), so students can > watch lessons on their own terminals. It’s possible to set view only > sessions also. It sounds feasible that all command line work being done > from the virtual X session as well. > It’s also possible to make vnc sessions running from jails (for > testing/disposable jails e.g.). With stuff like this you don’t even need to > worry about extra hardware. In fact it can be all done from a headless > server. > > Well sorry if this have nothing to do about your intents, just some option. > > Cheers, > Rodrigo > > > Assume we started KDE and testing a graphically displayed program . During that time , stdin , stdout , stderr outputs are not visible . Operating system is not using a graphical display . Therefore , there is a need to be able to define stdin , stdout , stderr divertible to different monitors ( by , for example , loader.conf definitions ) attached to PCI , USB , or main board ports . There is possibility of use of xrandr , but this is an extension to X Window . By using different monitors , it will be possible to view inner working of the operating system on line , otherwise , stored information can be viewed off line . As an example , in KDE , start a terminal . In that terminal , start a graphically usable program , for example , Dolphin . You will see that , there will be many messages displayed in the terminal . No one these messages are displayed when Dolphin is started from KDE menus . Ability to divert stdin into an independent monitor is important because when a program continuously displays data onto stdout , it is not possible to enter any input up to end of the working program . Mehmet Erol Sanliturk > Em 20/11/2015 11:47, Mehmet Erol Sanliturk escreveu: > >> On Fri, Nov 20, 2015 at 4:43 AM, George Neville-Neil < >> g...@neville-neil.com> >> wrote: >> >> Howdy, >>> >>> Thursday evening at 18:00 BST I pushed changes to teachbsd.org that >>> update >>> the page so that it points to a new github repo, owned by the teachbsd >>> organization (https://github.com/teachbsd). >>> The organization is run by Robert Watson and myself. >>> We can add or remove collaborators if and when that becomes appropriate. >>> >>> The initial repository (https://github.com/teachbsd/course) contains all >>> of the material for the practitioner and masters style courses as well as >>> a PDF for the teaching guide. >>> All of the material is licensed under a BSD doc team license, also >>> visible >>> in the repo and on the github site. >>> >>> Our goal now is to initially recruit a small number of universities to >>> partner >>> with us to teach this material, and to have the number grow as we polish >>> the material. We also wish to solicit contributions of similar teaching >>> material >>> for inclusion in the site, via links at first, and into the repo if that >>> seems appropriate >>> at a later time. >>> >>> We will keep you posted on our progress. >>> >>> Best, >>> George >>> _______________________________________________ >>> >>> >>> In my opinion , one of the most important tools in such a work is the >> ability to display >> stdin , stdout and stderr on different monitors alongside with output >> monitor(s) for graphic displays such as Gnome or KDE or any other X based >> desktops also . >> >> This requires additions to FreeBSD sources to definition of such >> application which requires to use at the same time multiple graphic cards >> ( >> on board , PCI , USB , etc. , simultaneously ) . >> >> My knowledge is not sufficient to achieve this . >> >> This will allow watching execution steps on line instead of diverting them >> to file and then read the contents of file . >> >> >> Thank you very much . >> >> >> Mehmet Erol Sanliturk >> _______________________________________________ >> freebsd-advocacy@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-advocacy >> To unsubscribe, send any mail to " >> freebsd-advocacy-unsubscr...@freebsd.org" >> > > > --- > Este email foi escaneado pelo Avast antivírus. > https://www.avast.com/antivirus > > _______________________________________________ > freebsd-advocacy@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-advocacy > To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org > " > _______________________________________________ freebsd-advocacy@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-advocacy To unsubscribe, send any mail to "freebsd-advocacy-unsubscr...@freebsd.org"