I develop asterisk and GUI.
Asterisk GUI were exist several type.
FreePBX, AsteriskNOW, Elastix, Trixbox...
Finally, I have selected two type.
FreePBX and AsteriskNOW.
FreePBX is based on php, AsteriskNOW is based on java.
Almost people used FreePBX.
But I don't know that reason.
I have installed AsteriskNOW and asterisk from command line (apt-get install asterisk) to get the best and easiest startup time. All other versions are a pain in the a$$. I would go for apt-get install asterisk since this way takes care of upgrades.
Your question is valid, since there are very few forums and people who can / do help on asterisk. Any question on asterisk deserves a +1.
I have been using Asterisk for about ~10 years, and always compiled from source and always used CLI. Its simple, flexible, easy to maintain and "solid". For a brief period of time, I used Trixbox. It was nice and shiny for a while, with all the bells and whistles from an "out of the box" distro. But it wasn't long when the thing broke down. I don't know if it was my careless edit or something spooky, but it stopped working. As an emergency repair, I simply re-installed asterisk from source as usual (1.4 that time), using my own handcrafted config files. This setup is still in server as of Today (Sep 5, 2014).
just recently tried 'pbxinaflash' with 'incrediblepbx', mostly because of security ('fail2ban') and to try some other interesting features (such as google voice, and other call routings). Quickly after the installation, I got locked out by fail2ban firewall when I typed incorrect password twice. Finally when I reached the GUI, it looked good (as expected). Struggled with GUI menus for several hours to get some functionality to work. Finally had to resort to editing custom.conf files to get most of stuff in my .conf files replicated. Still was not able to setup trunk. Removed it in frustration. (Oh, the 'pbxinaflash' has lots hidden paid features that are installed on trial basis).
The main issue I have with all the GUIs is that they take control of your .conf files, splitting them into multiple sub files, and allow you to edit only a few of them. This hides a lot of simple stuff under multiple GUI menus. e.g if you need to enable tcp, you would need to edit 3 lines in sip.conf in raw asterisk. On GUI, that needs visiting about 2 menus and editing a config file. My ideal GUI would co-exist with plain .conf files, seamlessly co-existing with manual edits, and still allow easy GUI for things where GUI is really needed, such as call routing etc.
Anyway, I am now trying FreePBX and AsteriskNOW (both use same GUI), while my good old asterisk 1.4 is still quietly doing its job close by.
If anyone is interested I can post more updates.
Current Asterisk NOW(binary distro) use freepbx.org (web framework for asterisk control).
So your question have no real sence or choice.
Older asterisk now(javascript) now not supported and very buggy. Better not use that.
Elastix, Trixbox, PBX in a Flash(icnredible pbx) all different binary distros based on Freepbx.org
Freepbx is not best web in term of architecture, but it most common and stable.
If you question is which distro to use as base for your setup - use PBX in Flash or Elastix.
If you want DEVELOP web, you need have 5+ years extensive asterisk experience to do that.
You can try XiVO. It's based on Asterisk and distributed under the GPLv3 license
Related
My company does Linux embedded systems using Freescale PowerPC processors.
Some years back I wrote an internal HowTo on how to use Dan Kegel's crosstool to set up a cross compiler environment for our product. I hadn't touched it since then but I recently tried it and found it doesn't work. The scripts look for files on redhat.com's ftp server that are currently not there.
The latest cross tool script is the one I am using, version 0.43.
So before I roll up my sleeves and see if I can fix it myself, I am wondering if someone has already done this. Does anyone here know Kegel well enough to contact him and ask if he is planning to do an update? (My guess is not. He works at Google now.)
Alternatively, is there a better GNU cross tool builder than Kegel's cross tool? It might be easier to switch over than to update the old one.
As it turns out Mr. Kegel was kind enough to respond to my e-mail. It turns out his original scripts have been picked up by an open-source group that calls it crosstool-ng. They did an amazing amount of work on this and the tool now uses a curses-based menu system to select the options for the cross development to generate.
You can search for file names directly in Google (try '<filename> site:ftp.redhat.com' or something similar), and often results will yield revised links to the files. If that is the problem, it should just be a case of cut and paste. Alternately, I would recommend downloading the files locally, modifying the script to see them there and then bundling them with the script.
Kegel left Google for a startup. His resume is at http://www.kegel.com/resume.html . Have you tried emailing him? He might just respond.
Our dev team uses VS.NET for app development and TortoiseSVN/VisualSVN for version control. It seems that almost every day issues arise with the working copy or the repository getting screwed up, and folks just throw up their hands and call me when it happens. There are definitely human factors at work (SVN works as it should) but I'm tired of playing SVN helpdesk to the dev team. Can anyone recommend a better/more intuitive setup for version control?
Agent SVN works well for me. It integrates nicely with Visual Studio.
SVN is about as simple as version control systems get. Problems should only arise when dealing with merging operations...those can be tricky.
If you don't address the "human factors" it won't matter which version control system you use, you will always be the helpdesk. To address these kinds of problems, you typically need to:
Set up a wiki with common "recipes" for version control tasks.
Include a workflow diagram for how changes are made to your code (for those who don't like to read).
Host a training session that is specifically
designed for your users (use the wiki
material).
When helping someone with a problem, be sure to make them perform the actual fix. Don't just do it for them, talk them through it instead.
Make a point of directing users to product documentation when helping them.
Introducing a new version control system into any organization should include the items I listed. I realize it is extra work for those who get it done, but it does save you from long "support" hours down the road.
Can anyone recommend a better/more intuitive setup for version control?
Better? Yes. More intuitive? That's debatable. Look into distributed version control software, namely Mercurial or Git. Both have freely available plugins to integrate with Visual Studio. And if you can manage spending a little money, I've heard very good things about Fog Creek's Kiln.
As for your issues with SVN, I have a couple tips. The first is to make sure you keep everyone synced on the same version of the product. It tends to update frequently, and so this can be tricky, as you also don't want to fall too far behind the current version. The second is that we used to have big problems with Tortoise trying to cache icon overlays on mapped network drives. There is an option you can turn off somewhere that suddenly made things way more stable. But that was at my last job, and I don't remember the exact setting any more.
I think you already gave the answer in your question - sort out the "human factors" by providing appropriate training. Version control for software development doesn't get much simpler than SVN, so from the way your question is phrased, my guess would be that said human factors are just going to find other ways of making your life interesting.
if you have issues with your repository getting screwed (like committing on tags, wrong commit messages...), one of the easiest way is to play it the hard way : put hooks on the server to enforce policies. You can have a look in official documentation.
Basically, this is an easy way to enforce naming / formatting and avoid a lot of human issues (committing on tags, messing with externals...)
Last year, in 2009 GSoC, I participated with an organization called Winlibre. The basic idea is having a project similar to Aptitude (or Apt-get) and a GUI like Synaptic but for Windows and just to hold (initially), only open source software. The project was just ok, we finished what we considered was a good starting point but unfortunately, due to different occupations of the developers, the project has been idle almost since GSoC finished. Now, I have some energy, time and interest to try to continue this development. The project was divided in 3 parts: A repository server (which i worked on, and which was going to store and serve packages and files), a package creator for developers, and the main app, which is apt-get and its GUI.
I have been thinking about the project, and the first question that came to my mind is.. actually is this project useful for developers and Windows users? Keep in mind that the idea is to solve dependencies problems, and install packages "cleanly". I'm not a Windows developer and just a casual user, so i really don't have a lot of experience on how things are handled there, but as far as I have seen, all installers handle those dependencies. Will windows developers be willing to switch from installers to a packages way of handling installations of Open source Software? Or it's just ok to create packages for already existing installers?
The packages concept is basically the same as .deb or .rpm files.
I still have some other questions, but basically i would like to make sure that it's useful in someway to users and Windows developers, and if developers would find this project interesting. If you have any questions, feedback, suggestions or criticisms, please don't hesitate posting them.
Thanks!!
be sure to research previous efforts on this. Google turns up several similar/relevant efforts.
http://en.wikipedia.org/wiki/Package_management_system#Microsoft_Windows
http://windows-get.sourceforge.net
http://pina.plasmite.com
IIRC there was an rpm for windows at some point
Also I think there was some guy (who used to work at MS) in the news recently that basically is starting up a very similar project. I can't find a link to this now.
But anyway, yeah, it would be awesome if there was such a standard tool and repository.
I can only speak for myself, but obviously I could definitely make use of such a tool as I found your post through googling! ;)
My two use cases for this tool would the following ones:
1. I generally avoid to re-install my system as long as possible (in fact I manage to do so only for switching to a reasonable (not each an every) new version of Windows every few years or to setup new computers). But still I'd like my software to be up-to-date. Neither do I want to have to go to all the web pages and check manually if there are compatibility issues with the new version of Doxygen, Graphviz and the latest version of MikTeX for example, nor do I want to have to navigate to the download pages and run the setups all by myself. I just want to schedule ONE SINGLE (!) tool, which checks whether there are new updates or not and updates those applications which are not in conflict with any other application version.
If it unavoidably happens to me that I have to re-install my system, I don't want to get the new setups neither (and check compatibility). I even don't want to wait for one setup to finish in order to start the next one, I just want to check the tools I need, or even better, I want to simply load my "WinApt XML" batch installation file, which gets the installers and handles the setups sequentially all by itself.
I don't know enough about the architecture of .deb or .rpm but IMHO the most reasonable would be to maintain a DB with only the names, versions, dependencies and the location of the different versions' download locations. I mean, most of the tools available for Windows provide .msi packages anyways, which (I guess) is the application itself and some custom installation properties (really not sure how scripting is handled, but I know that creating a MSI in Visual Studio has very limited abilities to create custom installation steps and I can only imagine this is due to limitations of MSI protocol).
I guess a GUI will be mandatory for Windows users ;) but I personally would prefer the additional ability to handle the setups with the console.
Well, I like the idea and would love to hear from that (or such a) tool in the future.
Cheers
Check out NSIS. It's an open source MSI creator. You might be able to use it as part of your package creation software.
http://nsis.sourceforge.net/Main_Page
For the ALT-.Net tool/lib stack there have been some affords in this direction: Horn Get
However, the usability in a real world project has been subject in this SO question.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I recently had to struggle with one installation project (which uses most popular product for creating installations: InstallShield) to make it work for product upgrades (migrating from one version to another). In the end it turned out that I needed to use one long package code but was using some other. It wasted my 8 hours (testing and debugging installers is a pain).
Now if I think about it, once you are done all the hard part of coding, all you want to is that correct applications, libraries are copied to target computer and user just runs it. Period. This apparently simple task normally turns out to be a tricky one and "being closed to finish date" makes in even harder.
Don't you think deploying a product is made damn difficult on windows which should have been simpler? (or installer really deserves that much attention and I am just being crazy about it?)
Have you ever used simpler deployment schemes such as "copy the folder to wherever you like and run the exe. When you want to remove it, just delete the folder!"? Was it effective and made things simpler?
Painful as it is you need to wrestle with the windows installer for the benefit of your customers. Otherwise you will need to do a lot more work to
Handle situations where for some reason an error occurs during the installation. What do you do next?
Handle issues like security. What if the installing user does not have rights to particular folders/registry keys?
Correctly cleanup after installation
Patching and patch management
Performing additional tasks -- registering COM objects, creating databases, creating shortcuts, creating an un-installation shotcut and so on
Installing prerequisites
Letting users choose which features to install
Your own custom scripts to solve all these problems eventually become a bigger problem than the installation itself!
I recommend that you check out Wix. It's not exactly child's play but it gets the job done. If you install Votive as a visual studio add in you get intellisense to help you strucutre the tags correctly. With the help file you can create pretty functional flexible installations
I don't think you'll see too many disagreements here, especially regarding MSI. I think one thing to keep in mind is to watch the way many programs are using MSI files these days. Displaying UI dialogs and making complex configuration choices with an MSI is very weak simply due to the way Windows Installer was designed, so I've noticed a lot of programs being split into a bunch of baby MSIs that are installed with the minimal UI by a parent setup program. The SQL Server 2008 setup wizard does this. UPS WorldShip does this. And Paint.NET does this, too--the wizard you see is a Windows Forms app, and it launches msiexec itself (you can see the minimal UI of the Windows Installer pop up on top of the white wizard window), passing any configuration parameters as property arguments to msiexec.
A common scenario where this comes up is where someone is tasked with building an installer for an application that has both server and client counterparts. If the user chooses the server option, then they may or may not want a new database to be installed, which means installing SQL Server. But you can't just install SQL Server while you're in the middle of your own installation because Windows Installer won't let you do that. So a frequent solution is to write an app that displays a wizard that allows the user to configure all of the setup options, and then your app launches the MSI files as needed for SQL Server, your server application, and your client application in the minimal UI mode; basically, eschewing the "features" aspect of Windows Installer entirely and moving it up to the MSI level. 4.5's multiple-package installations seems to be a step further in this direction. This format is also especially useful if you also need to loop in non-MSI installers from third parties as part of your installation process, like installing a printer driver for some bizarre point of sale printer.
I'll also agree that Windows Installer lacks built-in support for common deployment scenarios. It's meant for when setup isn't XCOPY, but they seem to miss the fact that setup usually isn't just "files + shortcuts + registry keys," either. There are no built-in actions for setting up IIS Web sites, registering certificates, creating and updating databases, adding assemblies to the GAC, and so on. I guess they take the opinion that some of this should happen on first run rather than being a transactional part of the install. The freely available tooling and documentation has been awful--flat out awful--for the better part of a decade. Both of these issues are largely addressed by the WiX project and DTF (which lets you finally use managed code custom actions), which is why we're all so grateful to Rob Mensching and others' work on that project.
I've had the same experience. Installation can quickly suck up your time as you go down the rabbit hole of "Oh God, I guess I have to become an expert in this too." I second the idea that's it's best to address it early on in your project and keep it maintained as part of your build process. This way, you can help avoid that scenario of having developed a practically uninstallable product. (Trac was an example of this for a while, requiring to track down specific versions of weird Python libraries.)
(I could go on about how Windows Installer sometimes decides to use my slow, external USB hard drive as a place to decompress its files, how it seems to sit there doing nothing for minutes on end on computers that have had lots of MSI installs on them, and how that progress bar resetting itself a bazillion times during a single install is the most idiotic thing I have ever seen, but I'll save those rants for another day. =)
My two cents; please note that I really just know enough about Windows Installer to do damage, but this is my assessment coming from a small business developer just trying to use it. Good luck!
Well, its a lot easier if you build your installer first, make it part of your build system, and let it grow with your project.
I agree, the windows installer drives me insane. But there are a lot of situations that xcopy just doesn't solve. Sometimes you want to install for multiple users, not just the current user. Sometimes you have to register COM objects. Sometimes you have to make a whole bunch of changes to the system, such as registering services to run at startup, connecting to network servers, etc. Sometimes you have users that can't use a command prompt. And you always want to be able to role the whole thing back when something fails halfway through.
Was the whole MSI database approach the best way of doing it? I'm not sure. Would I rather pound nails into my head than write another line of WiX code? Probably. But you have to admit, it does a good job of doing everything you could ever possibly want. And when it doesn't there is always the CustomAction option.
Really, what I would like to see, is better documentation (really, what is a type 50 action? How about giving it a name?) and a lot more easy-to-usurp templates.
And the WiX users group alias does a good job of answering questions.
You should read RobMen's blog. He does a good job explaining why things are the way they are. He has done a lot of thinking (more than any human should) about the problems of setup.
Have you looked at NSIS: http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System ?
And 1: Yes, 2: No
Personally, I mostly agree with #Conrad and #John Saunders. I wrote about this topic a long time ago on my old blog. I think #jeffamaphone has a point about the Windows Installer complexity (and my over attention to setup, in general ) but I believe the Windows Installer is still the best all round option for installation on Windows.
"Once you have done all the hard part of coding", you haven't done a thing if all your hard work doesn't install. Installers need to be built and tested on every nightly build, every night, almost from day one. You need to test that the installer can be built and run, and you need to verify the installation.
Otherwise, who cares how much hard work you've done coding - nobody will ever see your work if it doesn't install!
Note that this also applies to XCOPY.
Another thing: what is your QA testing if they're not testing what your installer installs? You have to test what the customer will get!
For exactly the reasons you state, we've done internal releases, handled by the dev team by copying the required files, and then done the rest of the setup using scripts and our own utilities.
However, for end users you have to have some kind of hand holding wizard, I've used the MS installer from within VS and found it confusing and clunky. After that experience I've avoided the pain by getting others to do the installation step. Can anyone recommend a good .Net installer?
I use Installshield and if you are not trying to do anything too fancy (I why would you) then it's pretty straighforward - set initial setting, select files, set up shortcuts and create setup.exe.
All future updates I handle inside my code - much more convinient to the user
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm looking for some help and it goes like this:
I'm a fairly green software developer, and focus mainly on the web (python/PHP) but am pretty well experienced with Java applications and as an electrical engineering student, looking forward to dive into some c/c++. I've pretty much grown up on Windows machine, but hate .net with a passion and dont really have a need to develop on Windows - besides the fact that i'm used to it.
I'm looking to switch to Ubuntu as my development machine entirely (without having WinXP on another partition) as I'm quite fedup with Windows, but am tempted to go back to it everytime i'm stuck with countless driver issues (be it headphone drivers, or dual monitor setup, etc). I'm looking for a comprehensive resource that will help this transition and doesn't assume you know alien linux shell keywords.
Cheers.
In my personal experience with Ubuntu, the two places that I consistently found help were Ubuntu Forums and Ubuntu Wiki. These two sites demonstrate just how helpful, organized, and motivated the Ubuntu Community is.
An additional resource is also the Ubuntu channel on IRC. Whenever I was stuck with an issue that I felt warranted a discussion with someone (or a handful of people), IRC was always a good place to go.
Lastly, I tend to learn a lot from reading blogs from people that are heavily involved in Ubuntu's development. Planet Ubuntu is a pretty good feed to keep in your reader. It's essentially an aggregation of a number of blogs. The majority of the posts are related to Ubuntu; however, there are occasional posts that are just about the developer's thoughts and opinions.
I would recommend you set up your PC in such a way that:
Have three partitions, one for swap (1-2x ram size), one for / (root dir) and one for /home.
Keep everything not related to running linux in /home, or on completely separate harddrives. Don't store stuff you wanna keep on the partition that holds /.
This allows you to rather effectively nuke your entire linux install and install another one without losing your data or your settings. This lets you do two things:
If you really break your install you can often just nuke it and reinstall. Most distros you're going to try will deal with upgrading you back to the current version quickly.
If you're not happy with, say, Ubuntu, you can just nuke it and install something else, say OpenSUSE, CentOS or Fedora.
The key thing to remember is that all your personal settings (desktop background, application settings etc) are stored in /home/yourname/ under hidden directories, definied by naming them with a '.', .gnome for example. System settings are stored in /etc, but with most distros these days system settings are so well guessed you never need to care. The data you care is under /home/yourname.
If you're going to move to another distro I would recommend copying those hidden directories into another directory under your home/yourname directory, say 'old-prefs' or something. This is because you want to start 'fresh' with the new install. You can copy back hidden dirs you know you want later (I for example would always copy back .opera, .mozilla).
Also, don't throw away your Windows install, not yet anyway. You may find Linux is not for you. You may find the inability to play any new games without rebooting a pain. You may find various things don't work as seemlessly as they do on Windows, in my experience that includes Adobe Flash and various sound-related things (sound has recently been rooted imo due to early PulseAudio adoption).
As other people have said, the Ubuntu wiki and Ubuntu forums are good, and for that reason it's the first distro I suggest you try. It's so popular that you often get better results in google by replacing 'linux' with 'ubuntu'.
Not an answer, per se, but some unsolicited advice:
All platforms have problems
Developing on one platform is pretty much like developing on another
Familiarity with both the *nix and Windows worlds is useful
Good luck!
I would agree with Tom's answer in terms of resources to answer questions. In addition to that, I would recommend being prepared to learn to use a command prompt and to learn a lot more about the underpinnings of the system than you are probably used to on Windows. Linux in general exposes the "machinery" of the OS quite a bit more frequently than Windows, and if you're the type of person that doesn't like to tinker with things occasionally then it is probably not for you.
For example, my dad is an engineer and experienced programmer, and he has no interest in using Linux, because he doesn't want to have to futz with things to get them working. For him, using Windows is all about the path of least resistance. I on the other hand, use OS X and Linux on a regular basis and I love that when things don't work, I at least have the option of digging in and fixing the problem. I love the ready availability of command line interfaces, multitude of scripting options, and the general openness Linux has. It's hard to tell from your post which type of personality you have, but if you're looking forward to digging into C/C++ and you enjoy electrical engineering, Linux will probably be a good fit for you.
Lastly, I highly recommend using the command prompt frequently, even when there are GUI interfaces. Linux GUI apps are frequently built on top of the console applications. It almost always will be easier to work with things if you're familiar with and comfortable with the command line. Most seasoned *nix users also find that eventually it becomes more efficient and comfortable to get many types of tasks done from a command prompt. If you plan to develop on Linux then this is all the more likely to occur as you get used to thinks like working with build tools and scripts that are common on UNIX platforms.
EDIT: One last thing I cannot recommend enough: use virtualization! Install something like VirtualBox, VirtualPC or VMWare Player to run Linux in a virtual environment. Virtualization has come along far enough since the days I started using Linux such that you can now install and run Linux in a full-screen environment almost indistinguishable from running it natively. Using a virtualized environemtn also will make things like drivers a non-issue, since the generic "hardware" should be supported out of the box. Virtualization or a "Live CD" version of Linux (such as the Ubuntu live CD) is a fantastic way to get used to Linux without having to throw out the safety blanket of Windows right away.
The other advice here is excellent. As somebody who made the same leap at the end of 2005, I just wanted to add my own two penneth.
Expect a steep learning curve. I'd been using Unix / Linux type servers for best part of 13 years when I switched. Not the same. When I switched is when I started learning. My productivity dipped at first, but I know SO much more about our deployment environment now - and of course productivity back an exceeded original. But it 'aint easy.
When you DO switch, you never look at an OS in the same way again. Makes it easy treating any OS as just a set of things you have to learn. This in itself is a good thing (tm)
The biggest problem at first is looking for linux equivalents of windows ways of doing things. I remember looking for decent FTP client (in the end IF I am forced to use FTP now, I use konqueror with two windows - but just wait till you discover rsync!), a decent graphical subversion client (then realised that knowing how to use find, sed, grep and svn cmd line client was much much better) etc.
I have heard people before say that resorting to the command line is admission of failure. While this may be true if there is no choice in it, you soon come to revel the blending of graphical and command line tools to get the job done. For example, I tend to use find and grep and xargs to load up my IDE with stuff I want to work on.
You learn to love computing again. The whole computer becomes a tool for getting things done.
The biggest change is the freedom. Not the cost. But that fact that installing software is as simple as "sudo apt-get install" or graphical equivalent. Even a very non-technical windows user soon comes to relish this amazing aspect that of Linux.
Enjoy!