Slashdot Mirror
Interview with Mark Spencer of Asterisk
comforteagle writes "OSDir has published an interview with Mark Spencer of Asterisk and Gaim about why and how he got started coding up the software platform PBX system and how it has become much more than -just- another phone system. He also shares his insights for the opportunities within the telecom industry for open source."
Would someone care to enlighten we the proletarians as to what PBX is?
I have used and deployed * in a number of setups ( from large businesses to home ), and you folks should really understand something: This is the killer linux app.
Samba is great. qmail/sendmail/ect...is wonderful as well. But, as far as getting linux in the door, this is the application that will do it. For example, my first * implementation cost about 8grand ( parts and service ).
For a similar, but far less featured pbx from avaya, I was quoted 40grand. And that was a quote. Anybody here that has worked with phone venders should be chuckling right now at that number, as it amounts to a pie in the sky dream.
So, for my small business, I saved them 30 grand right up front ( likely more ). On top of that, as their needs change, so can the phone system. Just the other day they found out I was taking my desk phone home ( to play with, but also get my phone calls ). When I told them why, they were floored that the system could do that, no matter how many times I told them it could.
Larger businesses will see far more dramatic cost savings, and get more features to boot.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
PBX is Provate Branch Exchange. Phone switches, basically.
Are you sure it wasn't Mark Spencer from Marks and Spencers?
>
> Spencer: Asterisk, as its name implies, was designed to do everything in telecom -- the name comes from the wildcard symbol. It can do most anything that you need it to do.
A good answer, but I half-expected to read...
"Asterisk? As its name implies - I regret that I have but one asterisk for my company. That's why I went with an open source solution."
But then I'm an invertebrate punster. (so slug me!)
Perfect timing for interview like this for me, i'm just building my first PBX system ever, and it ain't gonna be small :) :)
I'm actually quite overwhelmed about that task, hopefulyl i get by fine
Pulsed Media Seedboxes
If you have iTunes, you can check out the latest systm video cast which features a demonstration by John Todd. Shows how to set up Asterisk. 47 minutes in length. Go to iTunes and search for "systm".
)9TSS
I can not even begin to describe how great asterisk has been to the telecom industry. Asterisk will be (and is currently) just as important to the telecom industry as VoIP itself. I've delt with propietary telecom stuff before. It sucks ass. Take Nortel and Cisco for example. If you are going to buy Nortel IP phones, be prepared to use a Nortel soft switch. Up until recently you couldn't use Cisco power over ethernet with Nortel phones because of Nortel's non-standard implementation. Basically, every switch maker has made it as difficult as they can to use other comapanies equipment with theirs. Everything is expensive, non-extensible, and non-interoperable.
Then there's asterisk. Asterisk uses open standards. Asterisk has an API for writing phone based applications. Asterisk has a clean code base to contribute to. Telecom has almost always wanted to stay as closed as possible. People thought VoIP would change this. It just brought new people to the secret game (Cisco and Nortel being the worst offenders). Asterisk has blown this door wide open. Now, I can use whatever SIP phone I want. I don't have to find a Unistim phone anymore. I can write my own programs to interact with callers. Waaaaaaaaay more than simple tree based IVR's. We're talking full fledged applications through the phone. Without paying a dime. Asterisk has blown the doors wide open on the secret game of telecom. Sure, there will be a lot of people who stick with their traditional telecom equipment. But for those of us willing to roll up our sleeves, Asterisk offers up a way more extensible and programmable soft switch than I've ever seen from the traditional guys.
If an officer ever threatens to taze you, say you have a pacemaker.
not astrix or asstricks or even trixast etc please get it right....
These guys built a digital voice recorder out of it:
http://www.basesys.com/
It's used to provide a dictation service for large medical facilities down to small private practices. Medical dictation systems can cost $40,000+ from the biggest provider. (Dictaphone) We use this service though, and are very happy with their reliability. They can even support some proprietary Dictaphone hardware which uses DTMF tones not found on normal phones. (ABCD or Flash, Flash Override etc. for you military types.)
...when you have a termination provider capable of connecting with SIP phones.
Otherwise, when I go to a computer recycling depot, all I see is Asterisk boxes.
I have run 4 lines on my 450MHz box with no degradation at all.
You can buy cheap FXO cards for $10 and unlock Vonage Linksys PAP2s for $10 per FXS port.
Slap that together with a $25 PowerMAC 9600 and bam!
5 FXO + 10 FXS and witness the power of a fully operational PBX system for 175 bucks!
I am also evaluating Asterisk, I have it running at the moment in VMWare (Asterisk@Home) with Sipgate.co.uk
Since I'm in the UK, that gives me an 0845 number which routes directly to the * server, where a digital receptionist prompts for choices 1, 2, 3 etc. It's been useful since I am starting my own small business, and I am able to have semi-professional numbers on my business cards, take voices mails and queue calls up coming in over my ADSL. Sure beats call waiting or investing all my money into a phone system, where really I need it to support me and the business during the early days.
It is truely an amazing product, but it is quite complex and deep in the configuration files. Asterisk@Home provides a great way to slap an install on an old computer or in VMWare and get started with adding extensions. With the original Asterisk product it is very easy to get bogged down installation and basic configuration, when you don't know what your doing.
Highly recommended - I am hoping to sell the Asterisk server rebranded as my own PBX solution to companies, with a support contract. One of the only draw backs I can see is due to codecs, and using thhe G.729 - a royalty must be paid since it is not open source. This is a real shame since it can get right down to 8Kbps (instead of a standard uncompress 64Kbps channel) and here in the UK - upstream bandwidth is expensive - so the more channels you can transcode and pack down the pipe the better.
I'm also looking for technical information on how to link Asterisk up to UK ISDN30, I am assuming at the moment that it is a PRI connection on the ISDN30 which uses a PRI interface?
If anyone knows any solutions or better codecs to use I would be most interested!
Do you think Asterisk would still be successful if he didn't hang around with that fat guy who fell into the potion cauldron when he was a baby?
Slashdot: come for the pedantry, stay for the condescension.
Take it from me.. I work for one of those large close-sourced PBX companies. I love Asterisk. I think the initial jump in may be confusing to those who have never touched the command line before, but once you get the hang of it, it is much faster to configure than other PBX systems, and much more customizeable. Instead of having to use some special client to make a connection to the PBX server to make changes, all I have to do with Asterisk is SSH to the box and use vi ( of course ) on a couple of easy to understand text files. Asterisk can also interact with everything else on the box using perl or some of the built-in commands in Asterisk. So you could have it write to MySQL db, or email you everytime someone hits option "8" on the phone. All that is required for a simple VoIP system is an older machine ( preferrably 300mhz+ ), a NIC, and a sound card. This simple setup can get you up and running making phone calls from one softphone ( software based, no physical phone needed ) to another. Sign up with someone like nufone.net and start making outgoing calls. Or purchase a DID and have incoming as well.
For those wishing to play with Asterisk, you can't beat Asterisk@Home. Nearly instant setup & web-based GUI config makes easy to administer too. I had it up and running in uner 10 min!
T.J. Schmitz - the man, the myth, the legend - o
Here's a link to a newer interview done with Mark Spencer last week, Jan. 19, 2006.
p lay&id=91&cast=585&castPage=
http://gabcast.com/index.php?a=episodes&query=&b=
Quite sure. Mark Spencer is a personal friend (I'm one of the core developers of Asterisk).
My * application is to send streaming audio to my cell phone. That is, before going out I plug the * console sound card into my streaming audio client. Then I can call in and dial the '1234' extension and listen to Internet audio from the car, while hiking, etc. ;)
Plus it was fun to play with setting up
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Please pardon my igonrance, but for pure VoIP, do you even need a sound card in the Asterisk box?
2^5
I'm not *positive*, but I believe you are correct. I believe if you want any sort of other functionality, like voicemail, or any sort of menu system, it would be required. If you don't have those features, I don't really see the point of having a PBX though. You might as well use Skype or something similar.
No. No sound card is required.
It's not all that esoteric to set up, either. I didn't even bother with the various GUI configuration tools you can download. I did have better luck compiling it myself rather than using the one that Debian has packed for it, but that may have changed since I tried it.
If I were in the business of making commercial PBX systems, I'd be shaking in my boots right now. I think Asterisk will end up putting the lot of them out of business.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
http://voip-info.org/wiki/index.php?page=Asterisk
'Go for the eyes, Boo, go for the eyes, aaarrrrrrrr!' -- Minsc
The only thing you would need a sound card for is to plug your overhead paging system into the asterisk system.
If you run pure voip system, you will need OHCI usb to sync the timing for the realtime audio. If you don't have that then you will need to get some of that $10 telephony hardware, even for pure voip.
No, I don't think you do need one at all. All of the digital signal processing is handled in software. Digital/analog conversion is either done in the FXS/FXO cards, for traditional phones, or in the phone itself if you are using VOIP phones (that's why it matters what codecs the phone supports).
If you don't know where you are going, you will wind up somewhere else.
no sound card required. U can still have voice menus,etc without.
you would need the kernel module zapdummy to provide some sort of a timining interupt expected from the digium hardware by default, if you were running a pure VOIP box. That module now comes auto-setup with all the current asterisk auto installers.
I'm in charge of replacing our to-old NEC PBX for a brand new Asterisk in our ISP.
As a Unix sysop for long time, with some knowledge in general VoIP/H.323/SIP, I would say that the jump into Asterisk is not too dificult. We use SSH/vi/etc. in our day-to-day task, so one more system is not hard to swallow.
However I would like to point out that unless you are a really small user, with standard needs, for example in a situation where Asterisk@Home resolves all your needs, or you can live using only SIP or IAX, you will have some problems.
Asterisk will be a killer-app, but it is not there yet. Each new version tends to break something, configuration switches are added or removed, new features, are added changing the way things should be done, behavior of old functionality changes, etc. Its great, but its still evolving. Just check the mailing list and you will see the kind of problems that arise, and are resolved by the community.
Evolving is a Good Thing, but you have to take that into account before jumping in.
Pablo.
It didn't tell me why Obelix is so quick despite his girth, what's in that magic potion, or why my favourite Asterix film, Asterix and the Twelve Tasks, hasn't received an NTSC-DVD release yet. Instead, the interview was all about technology or some such nonsense. Don't the submitters check their links before they turn them in?
Condemnant quod non intellegunt.
Mark Spencer will be speaking on Sunday at the Southern California Linux Expo. In addition Digium will be exhibiting Saturday and Sunday.
Geeks! Geeks! Geeks! Now read through all these Asterisk posts, and what will you notice? They require a geek to make them work From a computer, to add-in cards, ending with an installation that requires a video to explain. The common man is just shaking his head. Not much of a "killer app" if you have to go through all that. What you need for a home installation is a HEMA box that sits next to the demarcation point.* There should be only three wires going in, power, ethernet, and phone. Everything else is inside the house, and is as easy to plug and use as a regular phone.
*What's in that box? Well the common man doesn't need to know, but for the geek it'll be an embedded computer with some analog hardware for connection to the phone line, and power supply for POE.(1) Naturally a preconfigured Asterisk set up with presets for the most common configurations. The interface could be everything from a browser front-end, all the way to a voice menu prompt (never assume that your users have, want, or feel comfortable with computers).
(1) The engineers here will note some additional hardware for when the fancy setup goes bye-bye, and you're not left hanging (that and 911, naturally)
Who's got reliable info on Asterisk scaling requirements? Eg. what hardware is needed in a cluster to support 10,000 corporate users (with a featurelist), or even 10,000 simultaneous phonecalls? Or, how many simultaneous users can a 2-Xeon/4GHz/4GB/250GB server support?
The useful answer to this question for a real network design is pretty detailed. Where are some actual scaled usage/support results?
--
make install -not war
For what it is worth, I've been running Asterisk for a few years now. It promises a lot, but I always find that half of everything is literally broken in it. For example, recently we've been having lots of problems with app_queue.c and threads, and the monitor() function, and the mixmonitor() function (which completely segfaults asterisk on an x86_64). (The problem is not in my configuration, as when I don't change anything in the configuration, random things break between versions.)
This wouldn't be a problem if telephony was only a hobbyist thing, but I was going to start setting systems up for small businesses using asterisk. I was in line communications in the military, and would never recommend Asterisk for anything requiring 5 nines or more (which covers telephony). I am not even talking about problems with transporting voice over the internet, I am speaking at a design and engineering level within asterisk itself. Change something in one file, and you can cause a cluster bomb to take out several other modules or the whole system. Agree or disagree with me, but I speak from experience. I hope that everybody sees this criticism for what it's worth... and it is not meant to start a ideology war.
Got to add this link:
http://www.zen13655.zen.co.uk/mythphone.html
Anyone tried this?
The future of video phones is cerainly destined for the TV.
My name is Anthony Minessale, After considerable contribution to Asterisk I have learned a great deal about telephony here is a list of my personal contributions to Asterisk: http://www.cluecon.com/anthm.html
The biggest lesson I have learned is that the fundamentals of Asterisk are built on assumptions and hard coded limitations. The flow chart for its code will make you dizzy:
http://www.freeswitch.org/astdoc/structast__channe l__coll__graph.jpg
http://www.freeswitch.org/astdoc/pbx_8c__incl.jpg
People who use asterisk from the outside wouldn't know there is absolutely no structure or discipline in the code and may not care. But once they invest a ton of time trying to make their dream Telco or whatever their dreams may be, the truth is all too obvious. Spoken from experience, only a seasoned technical wizard with years of computer skills to boast will ever be able to successfully implement Asterisk beyond a modest implementation. To truly understand how Asterisk works holds only a slightly smaller prerequisite. To those who find this unimportant, I understand your point, but be aware that Asterisk, being an open source project, needs to have a somewhat easy learning curve to attract new developers especially considering the developer turnover they suffer due to the maddening politics their community has to offer. The development is focused on owning all the code even if it means re-inventing things that already exist just to maintain the right to sell the code. This practice is fine with me though I am less than pleased by the end result when the home-rolled version is a poor contender with several existing solutions. The modular intentions of Asterisk are great though there is no structure there either. Any module can dig its way into nearly all of the code of the core and often, inexperienced module programmers will re-implement existing functionality to the extent that even inside the same C source file, you may find multiple versions of the same functions with different names. The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them. Some modules even depend on each other. This practice limits the portability since many operating systems will not tolerate one dynamic object from using symbols from another without hard linking them together. This is not the worst offense as far as portability; there are dozens more with many being accredited to Linux-specific assumptions. Apart from the technology problems the biggest remaining problem to consider is the community. The first experience for most Asterisk newcomers is an IRC channel where people fight for supremacy like information hungry pirates hording what they know and then sticking it to people for being so "stupid". (In other words, in the same boat they were in a few months back.) For those of us who are experienced developers, we are used to the l33t thing. The deal breaker is the issue management process. Submissions will generally be ignored for months then a one sentence overview will command the developer to fix minor issues and resubmit. This is almost tolerable if the submitted code was a new feature but more times than not it also happens with meaningful clean-up and repair of broken core functionality. I have heard this same complaint from countless ex-asterisk contributors over the past year and I am sure it is the number one cause of their ex status.
In conclusion, I actively develop Asterisk code but now I only do it as a consultant. I am quite good at it and I know what I am talking about and I feel that the issues with Asterisk will never be addressed because there may be more Asterisk users every day but there are also less developers every day too and soon all the developers will be
...Last time I looked, Marks and Spencer didn't sell Asterix books.
/a shame.
Why C and not C++? I've worked on a lot of large software projects (both C and C++), and although C++ is far from perfect, it is orders of magnitude better for something as dependent on extensions as as what freeswitch is proposing to be.
You're losing out on many useful features (data hiding, polymorphism, inheritance, references, the STL, etc.) and risking the same problems of loosely defined structure by tying freespace to C.
FYI - Mark Spencer will be talking at our local Linux group tomorrow. Check www.flux.org for details.
Honestly it does.
Well, I know nothing about the internals of Asterisk. But I am experienced with Linux and a couple of other OSS projects. In my opinion, a lot of OSS projects tend to be hair-balls. Evidently, the "Million monkeys in front of a million keyboards" principle is at play.
from: http://www.freeswitch.org/docs/
l
"Licensing
Freeswitch is licensed under the terms of the MPL 1.1"
this license is *not* compatible with the gpl. even mozilla.org has stopped using this license:
Mozilla Relicensing FAQ
http://www.mozilla.org/MPL/relicensing-faq.html
mozilla is relicensing all of their code under a triple mpl/lgpl/gpl license in order to make their products compatible with the gpl. please consider doing the same with freeswitch.
read this if you need some more convincing as to why to relicense:
Make Your Open Source Software GPL-Compatible. Or Else.
http://www.dwheeler.com/essays/gpl-compatible.htm
bottom line, if freeswitch isn't gpl-compatible it's much less likely to be successful.
Well, you don't need a card per se, but it is probably better to have the timing on a Digium card vs. using zapdummy.
I have my home * server with an FXO card and then use IAX to talk to my co-lo server (zapdummy). It's a good box to then tie to VoIP providers such as NuFone and Voicepulse.
I'm setting up a 50-odd user environment right now with the kicker being four different countries. Just try to get an Avaya or Nortel partner to quote project management and integration costs for two countries.
Blessed be the markster and the OSS application *.
The core is in C, but extension modules can be in C++. I will be working on some of these in C++ in fact.
Of the little code that I have had time to look at, I like anthm's design thus far. If only there were more hours in the day so I could spend more time familiarizing myself with it. Damn school getting in the way of real life!
The big screw-up is timing. Here I am, doing nothing but IAX2. There is no reason that I should have to load a zaptel driver! ("zaptel" being Digium's line of PCI cards) Asterisk refuses to use the normal Linux real-time clock features (POSIX timers, /dev/rtc, etc.) for timing. The zaptel driver is a crude piece of crap that was rejected by the kernel developers. It is unfit for serious use.
Being Linux-only is really not the problem. You could call it an advantage even, since your code will be much simpler if you can rely on modern Linux 2.6.xx features.
Being kind of tied to x86 is a problem. The code is filthy. At a minimum, proper code should tolerate: big-endian and little-endian, 32-bit and 64-bit, and "char" being either signed or unsigned by default.
Where is the OS written in C++? There are a few failed experiments, and Windows using a C++ compiler to compile what is essentially plain C, but nothing like a successful OS actually written to use C++.
For fun, compare the assemply language produced by:
In case you are unable to read assembly: the second is typically a factor of two larger.
I have to remind people that C++ was originally implemented in C as a set of macros. While we certainly can miss many of the obscene features of C++, we disambiguate the code by going the simpler route. While C++ implements a lot of nice ideas, remember that these are programming techniques, to make the program easier to read and maintain. They are properly not language features. At the end of the day, it's all object code, anyway.
Many of these are a nice middle ground between BSD and GPL. If somebody modifies your code and then includes it in a proprietary product, you get the right to any changes made to your code. You don't also get unrelated code unless the other party is feeling generous.
The modular intentions of Asterisk are great though there is no structure there either.
There is plenty of structure, here, and while in the past some of the lines between different concepts have been blurry, we are continually improving the definitions and coming up with yet better core structures. We're improving. Anthony even made some of these contributions, but we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.
The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them.
This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?
The first experience for most Asterisk newcomers is an IRC channel where people fight for supremacy like information hungry pirates hording what they know and then sticking it to people for being so "stupid".
We cannot control how other people act in public. Certainly we have a very vibrant community, but the first experience for Asterisk newcomers is generally the mailing list, not the IRC channel. While we certainly try not to feed the trolls, anybody who has been reading Slashdot for more than a week knows that the trolls stick around. And while we might rebuke others for being cruel on IRC, we cannot control how our users interact. For one thing, we cannot monitor the IRC channel 24/7; for another thing, our work is on Asterisk, not on controlling other users.
I would defy anyone to find a vibrant open source software community that does not have people who will respond in sometimes nasty ways to people who have not yet learned to ask Smart Questions.
Submissions will generally be ignored for months then a one sentence overview will command the developer to fix minor issues and resubmit.
I'll admit that this has been a problem in the past, but we are working hard to correct it. Bugs filed are generally addressed the next day or at least within 7 days of them being posted. While there are certainly bugs that we reject, quite frequently patches go into SVN within hours of them being submitted. There are also complex patches that require more thought and careful consultation with other developers, to ensure they take the code in directions that we wish to go. These are generally the types of bugs which remain open the longest -- not because we're ignoring them, but because we are carefully considering them.
soon all the developers will be nothing but users who have no other choice but to try and be developers
It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough learned and progressed and became developers. It's terrible that some people have forgotten this.
I could go on for ages documenting more issues but they tend to fall on deaf ears.
They actually didn't fall on deaf ears. Many of anthm's criticisms were taken quite seriously and have been addressed. It's sad to see another developer take his ball and go home, but we continue to move forward, with or without him. We aren't his keeper, and it's certainly his right to develop whatever he likes.
Did you have a look at Yate (http://yate.null.ro/)? I have also used Asterisk long enough to learn to hate it, but Yate looks very nice. It doesn't have as many features as Asterisk, but the code base is very clean and it does look rather easy to extend.
Don't take this personally, but every piece of code written by Mark Spencer is a horrible mess. Asterisk? Look at the code - each undergraduate student can do better. Besides it is crashing regularly when under load. L2TPD? Muhahahaha. I'm glad I found rp-l2tpd so that I don't have to use the crap by Mark Spencer. And then GAIM: Ever had a look at the security history? Don't use it! Sorry Mark - you have good ideas - very good ideas, but you suck at coding. Open a Blog, write about your ideas and let others do the architecture and the code.
Is his middle name Sand? ... I'll get me coat.
For non-traditional connections, let me do 16-bit linear samples at 48 kHz.
Conversion should happen as required.
Whenever one side of a connection starts to get ahead or fall behind, let me choose how to fix it. I may wish to cut corners, doubling or dropping individual samples. I may wish to have a polynomial interpolation done for a temporary rate conversion. See the "sox" audio processing source code.
Sir,
I have respect for you so therefore I will simply address your concerns and move on. Please be aware that I am not taking my ball and going home. In fact, I currently have 2 or 3 issues open in the Asterisk bug tracker and I now have a policy not to submit any more until older ones are cleared up.
http://bugs.digium.com/view.php?id=5161
http://bugs.digium.com/view.php?id=5162
I am not close-minded and I will use/develop for any software that I find a need for. I still have much more Asterisk code I can submit.
Now, to adress the concerns:
we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.
I believe he is referring to http://bugs.digium.com/view.php?id=3666
This patch did not propose to make the module loader unloadable rather to make it possible to load an alternate implementation of the PBX functionality.
At the time of that posting there was a general agreement that the Asterisk dialplan and the resulting codepath of traversing the PBX needed work but nobody wanted to break the program to fix it. With that patch one could build an alternate PBX callflow engine without disturbing the existing one. This is actually an important idea which i carried to FreeSwitch that the core would only deal with interfaces and pure low-level functionality. And to implement a PBX it would be done in higher level code supplied in the module API. I agree something has to be core and I have thousands of lines of code in my core already.
The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them.
This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?
I'm sorry but it is true. Allow me to elaborate with specific examples but before I do, remember, in the previous paragraph I was accused of not wanting anything in the core and now my problem is that I want more in the core.
EXHIBIT A
http://bugs.digium.com/view.php?id=2998
Here is a patch, written by me, that fixes a catch-22 in the Asterisk music on hold caused by the core being dependant on the loadable music on hold module.
The symbols ast_moh_start and ast_moh_stop were referred to in the core in several places and these symbols only existed in the dynamic module object therefore if you did not load the music on hold module the entire application would fail to start. At the time I wrote this patch there were still several other such issues that may or may not have been addressed but it still demonstrates the design issues and the inability to define how the core interacts with the modules.
EXHIBIT B
There is a module called res_features.so which contains the actual code that is executed when two channels are bridged ast_bridge_call and the entire parking concept ast_park_call both of the functions are used in other modules causing a module cross dependancy. Many operating systems will not even let you do this because you must employ lazy linking where 1 dynamic object is forced to trust that certian symbols will exist when the time comes.
soon all the developers will be nothing but users who have no other choice but to try and be developers
It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough l
You gripe about having to skip a tick every now and then to use a 1024 Hz clock for a 1000 Hz tick.
Meanwhile... the 1000 Hz clock isn't perfect. It varies from system to system, and even varies with temperature.
To top it all off, you run packets OVER THE INTERNET and you're worried about a wee little bit of wobble from a 1024 Hz RTC?
Come on, this is ridiculous.
In any case, I don't have a RTC chip at all. It does not exist on Macintosh hardware. My kernel supports POSIX timers, which are intended for real-time use. Apps are expected to use the POSIX timers. Why in Hell do you think Linus added POSIX timers to the kernel? It's for you.
Sorry dude, I'm not your Gentoo weenie. I've actually done OS development for real-time embedded systems. Imagine a computer that keeps an airborne laser focused on an incoming missle while both objects move wildly and even the air itself introduces enough distortion that you need to compensate by warping the mirror to focus your laser. Imagine a computer that controls and monitors a jet engine test stand. I've worked on the OS for both of those, the first being non-Linux and the second being Linux. I think I know a few things about real-time.
I've done enough Linux kernel hacking to know that I don't like modules and proprietary crap. I know full well that modules aren't MUCH slower. They aren't MUCH bigger. I just don't feel that you should dictate how I run my system. If I want to save a few kB and a couple TLB slots, that's my business.
A far greater problem is the annoyance and incompatibility. When Linus changes the driver interface, all standard drivers get updated. Your driver lags behind, failing to compile. That is, it fails to compile if I even remember it and decide to screw around with it. I want to untar the kernel, run "make oldconfig ; make install", and reboot. I don't want to mess around with a separate driver.