From owner-freebsd-questions@FreeBSD.ORG Mon Jun 20 17:44:07 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDD7B1065674 for ; Mon, 20 Jun 2011 17:44:07 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1B68FC19 for ; Mon, 20 Jun 2011 17:44:07 +0000 (UTC) Received: from r55.edvax.de (port-92-195-180-180.dynamic.qsc.de [92.195.180.180]) by mx01.qsc.de (Postfix) with ESMTP id 0B5B93CA0B; Mon, 20 Jun 2011 19:44:05 +0200 (CEST) Received: from r55.edvax.de (localhost [127.0.0.1]) by r55.edvax.de (8.14.2/8.14.2) with SMTP id p5KHi5rh002980; Mon, 20 Jun 2011 19:44:05 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Mon, 20 Jun 2011 19:44:04 +0200 From: Polytropon To: Chad Perrin Message-Id: <20110620194404.4dceaa66.freebsd@edvax.de> In-Reply-To: <20110620170428.GA89605@guilt.hydra> References: <20110618212315.GB21890@orange.esperance-linux.co.uk> <20110619072518.2115dffb@scorpio> <20110619112248.7c879c1f@scorpio> <20110619154949.GA84264@guilt.hydra> <20110619123451.4a392bec@scorpio> <20110619173046.GB84720@guilt.hydra> <20110620133617.48643fbc.freebsd@edvax.de> <20110620154624.GA89286@guilt.hydra> <20110620182903.aa056264.freebsd@edvax.de> <20110620170428.GA89605@guilt.hydra> Organization: EDVAX X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Subject: Re: Any working SIP-phone on FreeBSD? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 17:44:07 -0000 On Mon, 20 Jun 2011 11:04:28 -0600, Chad Perrin wrote: > This email actually mentions Skype and SIP phones toward the end. Much appreviated. :-) > In general, the simplest possible format to achieve what is actually > needed is the best option. True. > This means that even LaTeX is usually the > wrong choice. LaTeX is for typesetting text (articles, books, technical documents, maybe even letters) - nothing more, nothing less. I would _not_ claim that it is optimal for log files. :-) > Does this programmer get to write a simple script to translate to CSV, > then import CSV into Excel, when the boss turns his/her back? It's not allowed, and on the "Windows" platform (that the scrapped PCs run via network), there are no scripting means. Furthermore, those workstations are monitored (due to security considerations), surely just sampled, not permanently. The easiest way would be the required output writer on the mainframe that could output OpenOffice XML, and that could then be even exported into some outdated "Excel" format, if urgently needed. > An Excel spreadsheet probably would have been easier to use, because of > the ability to export as CSV. No. "Excel" is to make rows and columns where you enter the values you've just read from your desk calculator. :-) > In this case, it was an HR professional (though what we were doing was > well outside of that working environment). Then HR _requires_ the use of a PC (as a tool), those who use it should be _able_ to use it. In reality, it is hardly the case. > I think the approach I need to take next time is to create a Web form > that takes inputs for the values and does not allow the user to touch the > key names. That's good. People like the web. Make sure the web page has some images, so it is entertaining, and maybe plays some music so the users feel comfortable. :-) > When the form is submitted, it creates a plain text file for > me, or just adds it to the database automatically. Placing it in a > browser would make things marginally more effort-intensive for the end > user than editing a text file directly, but much *much* less > effort-intensive than creating that four-column format. For some settings, I really _dislike_ the use of a web browser as any interaction is limited to what the browser can actually do. One example is how the keyboard can be used. Real professionals prefer it over mouse interaction (as this means a break in the natural work flow). Security considerations may also be included when thinking about migrating some functionality into a web browser. You could make an icon for the "Windows" desktop that opens a SSH session (e. g. using PuTTY) where users can enter the data into a simple dialog program (e. g. using NCurses Forms), and this program outputs a CSV data file which then gets incorporated into the database. Just an idea. > With luck, it > would never occur to the end-user to copy and paste from the Webpage into > a Microsoft Word document and send that to me. Just expect they send you a "HTML" export file they made with this "Powerpoint". :-) > If the person in my case had decided to make changes in some image > editing software, that at least would have been effective (for some > definition of "effective"). Importing it into a Microsoft Word document, > however, resulted in nothing getting done until someone else came along > and asked "Where's the original document?" It's hard even to understand what "original document" means. I had a customer (real story again) who wanted to send me a fax, but then phoned me to tell me that he can't, as the page always comes out of the fax machine. Meanwhile, I had more than 20 faxes on my system, all the same page. I needed to ask him: "Do you assume that faxing works like a tube in a pneumatic delivery system?" :-) > As for making telephone calls with the help of a computer . . . > > I do not have high hopes for Skype in the future. As I think I mentioned > in an earlier email, I expect Microsoft to "extend" Skype in ways > intended to break compatibility with non-Microsoft platforms. And in the next step, the use of this functionality, integrated into "Windows", will be a pay-per-use service. > I also > expect that, if Microsoft really support Skype rather than just letting > it die, it will get some MS Office integration "features" added to it > that will make it the voice chat equivalent of exactly the sort of > stupidity we have been discussing. Will be funny to see a worker "working" when we open an "Office" document. :-) > An open source equivalent that could be run just as easily from the > command line as from a GUI and is not dependent upon any specific OS > platform's facilities in particular would be great. General use would be possible, just "Skype" users would be on a dead end soon, left alone in a proprietary network where they can't reach anyone else. > SIP phones and > Asterisk PBXes are great for what they are, but they do not really > address the needs of casual voice chatters who want telephone-like > convenience without having to essentially set up their own telephone > company offices. SIP is good when you want to have telephone functionality in a place where you have some kind (no matter which one) of Internet access. Together with Asterisk for example, this enables a multi-location company to create their own intranet both for computer systems and telephones, so they all "dial inside", and any location can be reached from the outside by a systematic set of numbers. Also _changing_ things can be managed that way easily. For the end user, in many times a "real phone" (something with a cradle, a receiver and some buttons) would be the preferred solution. For a callcenter, on the other hand, connecting a USB headset to a Thin client to access both the telephone functionality _and_ the "normal" computer programs would be better, as both functionalities can be INTEGRATED in a nice manner. > Of course, I don't think such a thing can really be entrusted to the > Linux community these days. It should, as this will be part of the future. > Portability is essentially the last thing on > the minds of most Linux community developers lately, from what I've seen. Yes, LATELY... > So, too, is designing software without making it a monolithic GUI-only > tool that has far too many useless features in a single application. I would like to see an approach like gmencoder: A GUI frontend that makes use of command line tools. As a user of the GUI, you don't need to have any clue about the command line tools. But in worst case, they are there, and you can perform the same tasks with them. You can also do things the programmer of the "GUI abstractor" didn't think about, so it gives you MORE POWER! :-) Command line tools, unlike GUI, allow you to automate things, and finally, this means more profit for a company employing such a system. > For portability in particular, consider the problems of XFCE portability, > and the fact there are people in the GNOME developer community who are > questioning whether they should bother continuing to consider portability > in the future. I exactly thought about that some lines above... Luckily, I do not essentially DEPEND on one of them, so I should be safe. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...