Breaking into the gateway box is no different than breaking into a class5 switch - it takes an individual with drive, motive and skillset. I would much prefer the hands-on security available with VOCAL than using a nortel or lucent voice switch which utilize the old "security through obscurity" principle. With a decent Intrusion Detection system in place, and a well implemented firewall, the chances of having the gateway box compromised is much lower than a telco switch.
Well I know more people that have broken into random Unix systems then any sort of central office phone switches, but I haven't done an extensive survey.
With regards to the wires of an ISP - I agree that it can be sniffed, but not with the ease you suggest. How many people do you know that can de-frame a DS1 and pull the IP traffic out of it inline?
Until about a month ago I did:-)
How many have access to the equipment necessary to strip the shielding off of the exact fibre cable, create a macrobend and have the protocol analyzer to dump the reflected impulses to ATM then to IP?
Who needs to? Cut the cable, paste on new ends, and slap the router in between. A short outage won't normally be checked into. Even a long one will take a while to get remote hands there.
But forget that. If you tap at an ISP hub many of the connections will be 100Mbit ethernet and 1000Mbit (1Gbit) ethernet. Plain old ethernet. Same thing everyone and his brother knows how to tap. You won't get to do that at the transit routers (at least not for large ISPs) but customer aggregation routers'll be easy to hit. Most of these hubs are unmanned. I would guess that most of the rest are subject to social engineering.
The point is not that it cannot be broken into, but that it is more difficult and takes a different skillset than the trusty alligator clip method.
I'll agree with different (except maybe at the house NIs). At a lot of points it ain't harder though.
It would be great if there was encryption built into the standard, but what policy do you use when completing calls?
That would depend on what the customer wants. I would assume most would want a distinctive ring, or visible indicator and the call to complete. Others would want more of a STU-3 emulation and to have the call rejected (and logged). Either of those are better then the nothing you have now.
I assume some would want a more complex policy (calls from inside the company must be encrypted, distinctive ring for outside unencrypted calls...). Without encryption being a standard part of VoIP that makes it a lot harder to build this sort of thing in though.
There is no simple answer to any of this - but VOCAL is a good step in the right direction since we can take the code, and add encryption to it or improve on the standards.
Although those with access to backbone routers can reroute traffic easily through a sniffer or utilize a mirror port, most of the population does not have access to be able to sniff traffic beyond their first upstream router.
Compared to the existing phone system where any preteen with alligator clips can listen in on a phone call it now takes a person with considerable experience, who would be jeopardizing a successful career to listen in on the calls.
No it doesn't. First people could break into the VoIP "gateway" boxes and either splice off a copy, or do a man-in-the-middle attack. Or they could do a DNS attach and do man-in-the-middle. Or rather then being a company employee with router access they could be someone who broke into the router (or the box on the employee's desk!).
Oh, and about that teen with alligator clips? What makes you think the ISP has no wires? Wires go out from your house to the ISP, from the ISP to the other house you call, and wires and fibre all over the ISP's backbone. Oh, and there could be three or four ISPs involved....
The alligator clips should be able to go at the NIs at either home. Some of the other connections can be decoded with relatively inexpensive hardware. Other connections require more, but that hardware might be borrowed or stolen....
Plus some people aren't fond of the government being able to listen to them. That isn't any worse with VoIP, but it could be a lot better (I assume a lot of those people try running VoIP over SSH or encrypted VPNs of some sort -- but the people they talk to don't always have that)
Ah, but Perl supplies the undef() operator for just this reason: In the event that a structure may be circular, you can always explicitly blast it at the end of the scope.
C provides free() for just that reason; In the event that a structure may have been allocated, you can always explicitly blast it when you are done.
That doesn't make C garbage collected does it? I mean is still cleans up auto variables by itself. Or C++ which cleans up dynamically allocated memory stored in autoptr variables.
Or do all three languages fall short? (admittedly Perl falls far less short)
Just because a language has some garbage collecting features doesn't mean you can live by poor coding standards (like not cleaning up after yourself).
No, garbage collection's sole reason for existence is to clean up for you. If it doesn't do that then it isn't garbage collection. Period. It might be useful, but it still falls short of being garbage collection.
Besides, a full mark-and-sweep algorithm is quite an additional load on the processor. (one more reason why Java is slow.)
Mark and sweep is expensive, but there has been twenty years of research in GC since mark-and-sweep was state of the art. Modern GCs can actually be cheeper then reference counts! Regrettably they tend to be a little erratic in when they fire. The real-time GC systems (there are some) are something I don't know a lot about, but I expect they are more expensive.
Notwithstanding, many people I know don't use their telephone company as an ISP, so unless a telco is planning on buying up Earthlink, AOL, etc., they don't pose that much of a threat.
Doesn't most traffic going to Earthlink and AOL still pass over normal dial-up links? The RBOC still gets their pound of flesh there. Then the ISP backbones are made of long haul circuits that mostly come from long distance providers (at reduced rates because of the size of the ISPs).
The only place the RBOC isn't doing so great is DSL where they have to rent out copper and equipment space at pretty low rates. Now long-distance companies may well be losing more long distance voice revenue then they are gaining in data circuit fees. Maybe. I don't think so. Even if it is true, they are losing more due to deep rate cuts to stay competitive.
Why aren't VoIP calls encrypted? Because on-the-fly encryption and decryption takes time, and time is at an utter premium in a VoIP connection. The overall latency of a VoIP call must be less than 250 mSec to approximate toll quality.
Encrypting a stream (w/ blowfish) seems to take well under 5msec on my (two year old) machine. Five years ago (which I think is when VoIP was formed) it would have been 10msec. Not too bad if 250msec is your goal.
Now I don't think 250msec is a good goal. Isn't that like.25 seconds?!! I think 100msec is the upper bound for things like command line user interfaces, and I think GUI's as well. If 100msec is the goal, 10msec is a lot harder to justify, esp since coast to coast latency tends to be 70ms on leased lines.
However I think there are two bigger reasons encryption isn't part of standard VoIP. Five years ago it was almost impossible to do open source crypto in the USA, and doing closed source export crypto was quite painful. In fact doing close source export crypto is still a pain. Ask Apple why SSH was in the preview releases, but failed to make it to the final release.
The other reason? People don't see it as worse then the existing unencrypted phone system. It may actually be worse (simpler to divert IP traffic, probably simpler to systemicly monitor as well), but most people don't see it as worse.
I have another viewpoint. A new technology shouldn't strove to be "as good as" an old one. It should try to "hit the ball out of the park". Crush the old one. Faster, better, stronger. Old one's not safe? The new one is a Volvo. Old one is a tad slow? New one finishes as your finger leaves the enter key. Never aim for second best, there are enough things pulling you down anyway...
That's what I guessed.. I downloaded the source code and the Java is horrible. It uses all the built-in slow string stuff like StreamTokenizer that is the first thing you learn to NOT use when you use Java and want performance.
In other words it used the library, and the library sucks? The C++ code uses the STL for all the heavy lifting. The Perl code does it in a straight forward manner. They all have the look of "get the job done" rather then "use a lot of tricks to make it as fast as can be". The C++ code doesn't pre-size it's vector (actually it has been a while, and I don't recall if it uses a vector).
That is pretty much a good aim for a book focused at non-experts. Or even busy experts:-)
I ran both the Java and the Perl samples and it was 5 secs for Java, 3 for Perl. So so much for a 9 time speed difference.. I thought it was full of shit anyway.
Not surprising, compiler technology marches on. I expect the C++ I/O has improved a lot as well.
I could optimize the Java code a little bit if anyone wants to challenge this for a speed contest. I'm pretty sure I could half the Java execution time with an hour of work..
The question is what would they all do with a little expert tweaking? I remember thinking that C++ version would run faster just by changing the map's to hash_map's (assuming the implementation has them, most do).
I have no idea about the Perl version. Normally when I have to speed up Perl code I rewrite it in C++. I only have a vague idea about the Java since the only "fast" thing I wrote in it was a SSH client, and it beat out a few C (I assume) implementation on a Win95 machine, but blows dead goats on the BSD systems.
After seeing that benchmark, I got very curious cause I thought it was VERY odd. I read up on the web and noticed that several had commented that the test is VERY favorable for Perl and Awk due to it's "heavy use of associative arrays and strings". I can't comment that because I don't have the source code for any of those but I do know that the results are very weird.
You can get it from the author's web page. The Markov chain one was written in C by him a very very long time ago as a prank new.news poster before the re-org (before ANSI C, or Perl existed). I do think this is an updated version though.
A small app that has two nested loops and calls a method, passing two integers as parameters and returning an integer as the result.
Well that's a fine benchmark, if that is really the kind of code you expect to write. The markov chain one at least does some I/O and uses real data structures. Neither are all that close to code I tend to write, but the markov one is quite a bit closer (I normally have data structures, and I/O for example).
Also note that this book was published in Feb 1999, so the book was prob. done six months before, with software possibly months older. The Java for the x86 may well have had Hot Spot stuff, but the Irix version may not have. Also as I recall I/O sucked big time for C++ (surprising to me, I expected it to win), and I/O for Java (also surprising, I didn't expect I/O to rock, but I expected it not to be so bad).
P.S. if you program go get the book. It really is good. It is one of the few that has a chapter on debugging (even if it is pretty elementary).
Everybody I know who tried Perl's regular expression engine never went back.
Mark me down as the exception.
I had a problem perl's RE stuff doesn't handle well. I had a fixed per program set of regular expressions (200+ of them, in priority order) and a lot of input strings that matched at least one of the regular expressions (on of the RE is.*, so there is always a match). I had to find the best match for each string, and the per string runtime had to be extremely low.
The only way perl does this is to read the input string (maybe) call study, and then run the REs one by one in priority order stopping when you get the match. In other words something similar to lex, but just a little too dynamic and otherwise different to use lex.
I wrote a big C++ program that made a NFA from all the regular expressions, transformed it to a annotated DFA, and then shoved strings through it. The cost to check a string was proportional to the string length, but (aside from cache effects) independent of the number and complexity of the regular expressions.
Once in a while even fine pre-built tools like Perl aren't good enough, and you have to hand craft one of your own.
That said, much of my regex work is in Perl or lex.
Perl just added weak references. This is an idea that's been known in the academic programming language design community for over a decade, but until now, it hasn't shown up in a mainstream language.
Doesn't Java count? It has at least 3 kinds of week references (at least as of Java2, maybe before). I think they differ both in how weak they are, and in how they react to destruction (at least one fires before the object is destroyed giving time to save to disk, or make a stronger reference; at least one fires after destruction). One or more of the weak ref types may prevent collection until the system is actually low on memory.
A structure with backlinks, such as a tree in which each node has a back pointer to its parent, is a great use for weak links. If you do that in Perl now, you can get a memory leak, because it looks like a circular reference and the reference counts won't go to 0.
That is one way to fix circular references. Another way would be to have a better garbage collector which can collect up circular references (that is in fact the traditional difference between reference counting which fails on circular references, and garbage collection which works).
This isn't a slam on Perl, it is nice that it now has this feature. Ref counts also have nice features (they aren't faster then a good GC, but the find the garbage they do find at more reliable times so destructors can be relied on to go off at useful times -- there are some hybread systems that do both to get both advantages, like Lucent's Alef).
The more common use of weak references (in languages with proper GC systems) is to have a cache. The cached item stays in memory until a GC sweep takes it away, if it is needed after that it has to be recalculated or read from disk again or something.
What kind of technical work would need to be done to make such wide-spread video viewing a reality?
Beats me. Let me try a strawman. The government has to provide an NTSC or MPEG2 feed from any camera to any entity that pays $500 a month (per camera). That entity can rebroadcast that feed under any terms it likes (from totally free to over $500). -- the $500 is just a starting point, it could be more or less.
Or another strawman, all the cameras have to feed into a ATM or Frame Relay cloud (MPEG2, or a future NIST blessed open standard). Anyone that can pay the normal connection fee plus (to the LEC) plus 10% (to the government) into the cloud can get the bits out, and as above can retransmit them as they wish.
Either of those will get coverage of traffic areas and other areas of high interest onto the web pretty fast, either on ad funded sites, or pages with low monthly fees. They will both self fund (the incoming money should cover the cost to transmit)
Third strawman, to get the camera installed it has to have an internet connection and multicast the feed. This will push taxes up a bit, or keep camera deployment down.
Video Compression: How much improvement is needed?
To view on a PDA? A ton. To view low frame rate stills on a desktop? Thanks to the porn industry, none.
Wireless has a long way to go. But other things are driving it. Broadband is there already. Let me be clear, I'm interested in granting access to these cameras, but I don't care if it has a modest cost. I'm not looking to have another government subsidy. They shouldn't divert a penny from education, national defense, or wasting my tax dollars. They also shouldn't raise my taxes any for this.
PDA Power: How much more processing power does mobile computing need to make live, streaming video a reality?
Well, either a fair amount of general CPU, or a little hardware dedicated to the task. If enough people want it, it'll eventually happen.
Camera Representation: How will the ~10,000 cameras in your city be organized such that you can quickly choose the one you want? Click-thru map?
A click through map (zoomable would be nice). Of corse I expect a 3rd party to do that.
Policy question: Could I see cameras in places I'm not near? From Seattle, could I watch Washington D.C. streets? If not, how do we decide where to draw the line?
Anyone anywhere (if the system is tax neutral, or actually makes money). USA Citizens only (if it costs tax dollars, only tax payers should see). No geographical limits. Why should there be any? If someone spots the police planting evidence, I don't care where they are. If Nike wants to check how well their new sneakers are selling in NY, I don't care if they do it from CA.
Thanks, but it is David Brin's, or at least I read about it in his book "The Transparent Society". I think he had more arguments for it, but those were the ones I remembered:-)
I didn't remember the tile, or his name this morning. I spotted it when I was upstairs looking for another book.
The problem with that is that any user might compile a program, then hand patch the bounds check out of the bytecode (or just use an unapproved compiler). That might be malicious, or just someone who wants their code to run faster and is "sure" there aren't any bugs that require the bounds checking.
On the Bouroghs system, and the IBM AS/400 machines executable are not editable at all. I don't recall if root can edit them or not, or if they are actually uneditable, or if they stop being executable when they are changed (much like the set-uid bit on Unix OSes).
The MMU on a modern processor is a complex beast. Most of the complexity is for performance rather than bounds checking.
Exactly. The complexity in compiler based bounds checking is also all in the attempts to make it fast. Otherwise it would just add two (or more) CMP and Bcc instructions (or whatever the equivalent for the CPU is) before each memory reference.
It at least has the benefit that the basic concept of 'just in time' bounds checking is conceptually a lot simpler than checking by proof.
Yes it does. Although it has to rely on a normally fairly complex OS to set the MMU up right (and with some CPUs handle TLB shoot down, and cache invalidation).
The MMU has the advantage that it can see exactly where things are RIGHT NOW, and make a decision. Code verifiers have to look at the initial state and prove that given that initial state, the code, and any possable input, it cannot generate an access that violates the segmentation.
Point taken, except the compiler (not code verifier) can choose to insert bounds checks, it just won't be "as fast". (after all, the MMU is merely a bounds checker with some extra grot to send "well formatted" messages on violations)
On the other hand the MMU has a ton of difficulties as well. If you look at pipeline diagrams of modern CPUs the MMU tends to get a full pipestage, or two. It is one of the more complex parts of modern CPUs. The transistor count is behind that of a decently sized cache, but (including the TLB) ahead of everything else. The raw complexity it probably behind the modern reordering systems, but ahead of pretty much everything else. It is insanely complex.
To run OS X you'll need a memory upgrade (why Apple is still shipping 64 meg machines when OS X's minimum requirements are 128 is a mystery to me), but you're still under $1000, which is hardly out of reach for the average consumer. Yes, I know you can buy a motherboard+case+power supply+graphics card+CPU in the Wintel world for half the price, but that's not something normal people have the ability or inclination to do.
Actually the local computer stores sell Wintel boxes for $599, I forget how much RAM, but they have a 1Ghz CPU, which sounds better to Joe-sixpack then anything Apple offers in the iMac (unless they are sucked in by the look). Of corse you will have to add a monitor to the WinTel box, but that is still cheaper then the iMac.
Many Unix and Windows users who would never have considered Macs before are very interested in Mac OS X.
That's for sure. That's why I own a Mac for the first time in my life. My OSX PowerBook G3 makes a better web surfing toy then my Viao with Win98 did.
P.S. I find it amusing that Apple spell checker (which the web browser can use) knows what a Mhz is, but not a Ghz.:-)
Someone somewhere will find a way to assemble badly behaving code (deliberatly or not). We might as well call passwords and firewalls unnecessary because all we really need is an internet where people don't go where they're not invited and don't try to crash servers.
Clearly it isn't easy to do it right because so many JVMs have screwed up. Boroughs has been doing it for a long time, and even they have some failures 20 or so years back. But it isn't impossible.
I'm not even sure it is harder then making a CPU where the MMU can't be bypassed in user mode. Except for the one little detail that most people want more then one programming language (thus more then one compile), or that p-code is very slow.
OS X has memory protection. The old MacOS doesn't. The problems will be with old apps that 'got away' with memory violations from time to time (due to dumb luck in some cases) and seemed OK. Now, they will die on a SEGV.
Er, what?
If it is an old app it will run under classic with the other old apps, and have no memory protection.
If it is a new app one assumes it will be debugged under OSX and not get through QA with a ton of memory violations. (that's not guaranteed, it could use the Carbon API, and have been debugged under OS9, and "assumed" to work under OSX -- but I think you can check the "run under classic" box for them if you really really want).
if Carbon/Cocoa apps actually used the system call interface directly.
You may mix any of the APIs (according to the OSX overview doc - I havn't finished my reading, let alone started testing!) except classic (Carbon is 80% to 95% of Classic, depending on how you count).
However if you use a fairly narrow set of APIs you can be a Carbon OS X app under OSX, and still run under OS9 (and I think OS8).
In the older OSes, as I understand it, you have a set amount of virtual memory (set in a control panel). Each application reserves a set amount of memory (which in theory is the maximum amount of memory it would ever need) when it launches. So, IE might reserve 16 megs of memory, but only be using 7 or 8 at any given time. This way, each running application will never had its memory used by another app (in theory). The down side is that since the amount of memory an app has reserved is fixed, you don't get as many apps in physical memory as you do in an OS with a real VM system.
FYI, you can do (almost) that on OSX and other Posix systems (like Linux). Use "setrlimit". It won't pre-allocate the memory though, just limit the apps.
The fact is, it has little in common with bsd other than the fact that there is a bsd interface to the mach kernel that is there for the sole purpose of allowing it to run unix programs such as apache, sendmail, etc.
Sure, it has little in common except the whole 4.4Lite source base. Oh, and all the shims so it can use FreeBSD device drivers and filesystems. Oh, and the systemcall interface, which native OSX applications can/do use (unlike WinNT where you wither have a GUI, or you have Posix, but it is almost impossible to have both).
Most people seem to think that it started out as BSD and apple built their own window system on top, which is far from the truth.
How do you think it started out? It was MACH when NeXT built it, which had a BSD single server on it (not 4.4 at the time because 4.4 wasn't available). NeXT put their own windowing system on top because they felt (like many others) that X sucks.
The BSD stuff is a convenient way for apple to use existing software, nothing more.
Duh. What do you think Linux is? It is an easy way to use all that existing Unix app code.
Actually that is a bit far from the mark since Apple isn't getting a huge amount of mileage from existing Unix apps (mostly they don't have a friendly UI, and the ones that do need to use a new API for the UI anyway!).
Why should it matter that Apple chose BSD to reuse existing code? Isn't that the reason to choose an OS? What's next? Bitching at Red Hat for choosing Linux so they can use all that existing Linux software? Well, duh, of corse.
Being able to call up a terminal which is actually part of a Mac system absolutely rocks. Although, has anyone been able to replace the default shell with bash?
Have you tried chsh/path/to/bash? It worked for switching to zsh.
Applications - well, I hardly ever have to run anything in Classic. I've found an email application, an mp3 player, a web browser, AIM, a LiveJournal client (addict? me? never...) and other things that I need for daily happiness, all either Carbonized or already Cocoa. The only things I need Classic for are things like Photoshop and Dreamweaver - and it works just fine for those. Not every application I'll ever use is available yet - but stuff I need on a daily basis is all already supported in OS X.
I pretty much agree with you, for two reasons:
Classic may not be the ideal solution, but it does work for the vast majority of applications. Hell it even works for pre-release 1980's versions of MacDraw that are written for a different CPU!
I really believe that a lot of places have been dragging their feet on doing OSX ports until there was a release. Not delaying the release for 3rd party apps was a good idea. Also not installing it on new Macs is a great idea, because the thing ain't finished.
Plus, if you think something's missing - add it. Apple couldn't get ssh included, but many many people have gotten OpenSSH installed and working with a minimum of hassle.
I heard the govm'nt didn't OK Apple's paper work until about four hours after the golden master was cut. Beats me if it's true, but it makes a good story. It was only modestly harder to get compiled and installed on this OS then on others. I was kinda looking forward to a mass release OS with ssh built in though.
Another one is that IE performs really badly in its beta-carbonized form.
I think IE is worse in the OSX release then it was in the public beta. Not really slower as much as it crashes way more often, and the "page holder" has stopped working. I have more or less switched to OmniWeb.
P.S. I dig the new finder, but maybe that is because I like the new list view (well the NeXT list view).
P.P.S. umount -f seems to cause lockups pretty easily. Too bad, all the other BSDs are stable after one.
With Bluetooth it's possible to use a standard printing "profile".
On the other hand, if you are a printer maker you not only need to add bluetooth hardware, you also have to make your printer conform to the profile (or do so in one mode), which reduces your ability to make your product "different and better".
That's mostly better for the consumer, but worse for the printer makers.
Slashdot Mirror
Well I know more people that have broken into random Unix systems then any sort of central office phone switches, but I haven't done an extensive survey.
Until about a month ago I did :-)
Who needs to? Cut the cable, paste on new ends, and slap the router in between. A short outage won't normally be checked into. Even a long one will take a while to get remote hands there.
But forget that. If you tap at an ISP hub many of the connections will be 100Mbit ethernet and 1000Mbit (1Gbit) ethernet. Plain old ethernet. Same thing everyone and his brother knows how to tap. You won't get to do that at the transit routers (at least not for large ISPs) but customer aggregation routers'll be easy to hit. Most of these hubs are unmanned. I would guess that most of the rest are subject to social engineering.
I'll agree with different (except maybe at the house NIs). At a lot of points it ain't harder though.
That would depend on what the customer wants. I would assume most would want a distinctive ring, or visible indicator and the call to complete. Others would want more of a STU-3 emulation and to have the call rejected (and logged). Either of those are better then the nothing you have now.
I assume some would want a more complex policy (calls from inside the company must be encrypted, distinctive ring for outside unencrypted calls...). Without encryption being a standard part of VoIP that makes it a lot harder to build this sort of thing in though.
I agree 100% with that.
No it doesn't. First people could break into the VoIP "gateway" boxes and either splice off a copy, or do a man-in-the-middle attack. Or they could do a DNS attach and do man-in-the-middle. Or rather then being a company employee with router access they could be someone who broke into the router (or the box on the employee's desk!).
Oh, and about that teen with alligator clips? What makes you think the ISP has no wires? Wires go out from your house to the ISP, from the ISP to the other house you call, and wires and fibre all over the ISP's backbone. Oh, and there could be three or four ISPs involved....
The alligator clips should be able to go at the NIs at either home. Some of the other connections can be decoded with relatively inexpensive hardware. Other connections require more, but that hardware might be borrowed or stolen....
Plus some people aren't fond of the government being able to listen to them. That isn't any worse with VoIP, but it could be a lot better (I assume a lot of those people try running VoIP over SSH or encrypted VPNs of some sort -- but the people they talk to don't always have that)
C provides free() for just that reason; In the event that a structure may have been allocated, you can always explicitly blast it when you are done.
That doesn't make C garbage collected does it? I mean is still cleans up auto variables by itself. Or C++ which cleans up dynamically allocated memory stored in autoptr variables.
Or do all three languages fall short? (admittedly Perl falls far less short)
No, garbage collection's sole reason for existence is to clean up for you. If it doesn't do that then it isn't garbage collection. Period. It might be useful, but it still falls short of being garbage collection.
Mark and sweep is expensive, but there has been twenty years of research in GC since mark-and-sweep was state of the art. Modern GCs can actually be cheeper then reference counts! Regrettably they tend to be a little erratic in when they fire. The real-time GC systems (there are some) are something I don't know a lot about, but I expect they are more expensive.
Doesn't most traffic going to Earthlink and AOL still pass over normal dial-up links? The RBOC still gets their pound of flesh there. Then the ISP backbones are made of long haul circuits that mostly come from long distance providers (at reduced rates because of the size of the ISPs).
The only place the RBOC isn't doing so great is DSL where they have to rent out copper and equipment space at pretty low rates. Now long-distance companies may well be losing more long distance voice revenue then they are gaining in data circuit fees. Maybe. I don't think so. Even if it is true, they are losing more due to deep rate cuts to stay competitive.
Encrypting a stream (w/ blowfish) seems to take well under 5msec on my (two year old) machine. Five years ago (which I think is when VoIP was formed) it would have been 10msec. Not too bad if 250msec is your goal.
Now I don't think 250msec is a good goal. Isn't that like .25 seconds?!! I think 100msec is the upper bound for things like command line user interfaces, and I think GUI's as well. If 100msec is the goal, 10msec is a lot harder to justify, esp since coast to coast latency tends to be 70ms on leased lines.
However I think there are two bigger reasons encryption isn't part of standard VoIP. Five years ago it was almost impossible to do open source crypto in the USA, and doing closed source export crypto was quite painful. In fact doing close source export crypto is still a pain. Ask Apple why SSH was in the preview releases, but failed to make it to the final release.
The other reason? People don't see it as worse then the existing unencrypted phone system. It may actually be worse (simpler to divert IP traffic, probably simpler to systemicly monitor as well), but most people don't see it as worse.
I have another viewpoint. A new technology shouldn't strove to be "as good as" an old one. It should try to "hit the ball out of the park". Crush the old one. Faster, better, stronger. Old one's not safe? The new one is a Volvo. Old one is a tad slow? New one finishes as your finger leaves the enter key. Never aim for second best, there are enough things pulling you down anyway...
In other words it used the library, and the library sucks? The C++ code uses the STL for all the heavy lifting. The Perl code does it in a straight forward manner. They all have the look of "get the job done" rather then "use a lot of tricks to make it as fast as can be". The C++ code doesn't pre-size it's vector (actually it has been a while, and I don't recall if it uses a vector).
That is pretty much a good aim for a book focused at non-experts. Or even busy experts :-)
Not surprising, compiler technology marches on. I expect the C++ I/O has improved a lot as well.
The question is what would they all do with a little expert tweaking? I remember thinking that C++ version would run faster just by changing the map's to hash_map's (assuming the implementation has them, most do).
I have no idea about the Perl version. Normally when I have to speed up Perl code I rewrite it in C++. I only have a vague idea about the Java since the only "fast" thing I wrote in it was a SSH client, and it beat out a few C (I assume) implementation on a Win95 machine, but blows dead goats on the BSD systems.
You can get it from the author's web page. The Markov chain one was written in C by him a very very long time ago as a prank new.news poster before the re-org (before ANSI C, or Perl existed). I do think this is an updated version though.
Well that's a fine benchmark, if that is really the kind of code you expect to write. The markov chain one at least does some I/O and uses real data structures. Neither are all that close to code I tend to write, but the markov one is quite a bit closer (I normally have data structures, and I/O for example).
Also note that this book was published in Feb 1999, so the book was prob. done six months before, with software possibly months older. The Java for the x86 may well have had Hot Spot stuff, but the Irix version may not have. Also as I recall I/O sucked big time for C++ (surprising to me, I expected it to win), and I/O for Java (also surprising, I didn't expect I/O to rock, but I expected it not to be so bad).
P.S. if you program go get the book. It really is good. It is one of the few that has a chapter on debugging (even if it is pretty elementary).
Mark me down as the exception.
I had a problem perl's RE stuff doesn't handle well. I had a fixed per program set of regular expressions (200+ of them, in priority order) and a lot of input strings that matched at least one of the regular expressions (on of the RE is .*, so there is always a match). I had to find the best match for each string, and the per string runtime had to be extremely low.
The only way perl does this is to read the input string (maybe) call study, and then run the REs one by one in priority order stopping when you get the match. In other words something similar to lex, but just a little too dynamic and otherwise different to use lex.
I wrote a big C++ program that made a NFA from all the regular expressions, transformed it to a annotated DFA, and then shoved strings through it. The cost to check a string was proportional to the string length, but (aside from cache effects) independent of the number and complexity of the regular expressions.
Once in a while even fine pre-built tools like Perl aren't good enough, and you have to hand craft one of your own.
That said, much of my regex work is in Perl or lex.
Doesn't Java count? It has at least 3 kinds of week references (at least as of Java2, maybe before). I think they differ both in how weak they are, and in how they react to destruction (at least one fires before the object is destroyed giving time to save to disk, or make a stronger reference; at least one fires after destruction). One or more of the weak ref types may prevent collection until the system is actually low on memory.
That is one way to fix circular references. Another way would be to have a better garbage collector which can collect up circular references (that is in fact the traditional difference between reference counting which fails on circular references, and garbage collection which works).
This isn't a slam on Perl, it is nice that it now has this feature. Ref counts also have nice features (they aren't faster then a good GC, but the find the garbage they do find at more reliable times so destructors can be relied on to go off at useful times -- there are some hybread systems that do both to get both advantages, like Lucent's Alef).
The more common use of weak references (in languages with proper GC systems) is to have a cache. The cached item stays in memory until a GC sweep takes it away, if it is needed after that it has to be recalculated or read from disk again or something.
Beats me. Let me try a strawman. The government has to provide an NTSC or MPEG2 feed from any camera to any entity that pays $500 a month (per camera). That entity can rebroadcast that feed under any terms it likes (from totally free to over $500). -- the $500 is just a starting point, it could be more or less.
Or another strawman, all the cameras have to feed into a ATM or Frame Relay cloud (MPEG2, or a future NIST blessed open standard). Anyone that can pay the normal connection fee plus (to the LEC) plus 10% (to the government) into the cloud can get the bits out, and as above can retransmit them as they wish.
Either of those will get coverage of traffic areas and other areas of high interest onto the web pretty fast, either on ad funded sites, or pages with low monthly fees. They will both self fund (the incoming money should cover the cost to transmit)
Third strawman, to get the camera installed it has to have an internet connection and multicast the feed. This will push taxes up a bit, or keep camera deployment down.
To view on a PDA? A ton. To view low frame rate stills on a desktop? Thanks to the porn industry, none.
Wireless has a long way to go. But other things are driving it. Broadband is there already. Let me be clear, I'm interested in granting access to these cameras, but I don't care if it has a modest cost. I'm not looking to have another government subsidy. They shouldn't divert a penny from education, national defense, or wasting my tax dollars. They also shouldn't raise my taxes any for this.
Well, either a fair amount of general CPU, or a little hardware dedicated to the task. If enough people want it, it'll eventually happen.
A click through map (zoomable would be nice). Of corse I expect a 3rd party to do that.
Anyone anywhere (if the system is tax neutral, or actually makes money). USA Citizens only (if it costs tax dollars, only tax payers should see). No geographical limits. Why should there be any? If someone spots the police planting evidence, I don't care where they are. If Nike wants to check how well their new sneakers are selling in NY, I don't care if they do it from CA.
You can stream MP3s forever over a totally standard web server. All you need is client software like w3juke.
Thanks, but it is David Brin's, or at least I read about it in his book "The Transparent Society". I think he had more arguments for it, but those were the ones I remembered :-)
I didn't remember the tile, or his name this morning. I spotted it when I was upstairs looking for another book.
On the Bouroghs system, and the IBM AS/400 machines executable are not editable at all. I don't recall if root can edit them or not, or if they are actually uneditable, or if they stop being executable when they are changed (much like the set-uid bit on Unix OSes).
Exactly. The complexity in compiler based bounds checking is also all in the attempts to make it fast. Otherwise it would just add two (or more) CMP and Bcc instructions (or whatever the equivalent for the CPU is) before each memory reference.
Yes it does. Although it has to rely on a normally fairly complex OS to set the MMU up right (and with some CPUs handle TLB shoot down, and cache invalidation).
Point taken, except the compiler (not code verifier) can choose to insert bounds checks, it just won't be "as fast". (after all, the MMU is merely a bounds checker with some extra grot to send "well formatted" messages on violations)
On the other hand the MMU has a ton of difficulties as well. If you look at pipeline diagrams of modern CPUs the MMU tends to get a full pipestage, or two. It is one of the more complex parts of modern CPUs. The transistor count is behind that of a decently sized cache, but (including the TLB) ahead of everything else. The raw complexity it probably behind the modern reordering systems, but ahead of pretty much everything else. It is insanely complex.
Actually the local computer stores sell Wintel boxes for $599, I forget how much RAM, but they have a 1Ghz CPU, which sounds better to Joe-sixpack then anything Apple offers in the iMac (unless they are sucked in by the look). Of corse you will have to add a monitor to the WinTel box, but that is still cheaper then the iMac.
That's for sure. That's why I own a Mac for the first time in my life. My OSX PowerBook G3 makes a better web surfing toy then my Viao with Win98 did.
P.S. I find it amusing that Apple spell checker (which the web browser can use) knows what a Mhz is, but not a Ghz. :-)
I want the camera images accessible in real time to the public. It has a few advantages:
(I'm not saying I want the cameras, but if we have them, these are my terms)
Clearly it isn't easy to do it right because so many JVMs have screwed up. Boroughs has been doing it for a long time, and even they have some failures 20 or so years back. But it isn't impossible.
I'm not even sure it is harder then making a CPU where the MMU can't be bypassed in user mode. Except for the one little detail that most people want more then one programming language (thus more then one compile), or that p-code is very slow.
Er, what?
If it is an old app it will run under classic with the other old apps, and have no memory protection.
If it is a new app one assumes it will be debugged under OSX and not get through QA with a ton of memory violations. (that's not guaranteed, it could use the Carbon API, and have been debugged under OS9, and "assumed" to work under OSX -- but I think you can check the "run under classic" box for them if you really really want).
You may mix any of the APIs (according to the OSX overview doc - I havn't finished my reading, let alone started testing!) except classic (Carbon is 80% to 95% of Classic, depending on how you count).
However if you use a fairly narrow set of APIs you can be a Carbon OS X app under OSX, and still run under OS9 (and I think OS8).
FYI, you can do (almost) that on OSX and other Posix systems (like Linux). Use "setrlimit". It won't pre-allocate the memory though, just limit the apps.
Sure, it has little in common except the whole 4.4Lite source base. Oh, and all the shims so it can use FreeBSD device drivers and filesystems. Oh, and the systemcall interface, which native OSX applications can/do use (unlike WinNT where you wither have a GUI, or you have Posix, but it is almost impossible to have both).
How do you think it started out? It was MACH when NeXT built it, which had a BSD single server on it (not 4.4 at the time because 4.4 wasn't available). NeXT put their own windowing system on top because they felt (like many others) that X sucks.
Duh. What do you think Linux is? It is an easy way to use all that existing Unix app code.
Actually that is a bit far from the mark since Apple isn't getting a huge amount of mileage from existing Unix apps (mostly they don't have a friendly UI, and the ones that do need to use a new API for the UI anyway!).
Why should it matter that Apple chose BSD to reuse existing code? Isn't that the reason to choose an OS? What's next? Bitching at Red Hat for choosing Linux so they can use all that existing Linux software? Well, duh, of corse.
Have you tried chsh /path/to/bash? It worked for switching to zsh.
I pretty much agree with you, for two reasons:
I heard the govm'nt didn't OK Apple's paper work until about four hours after the golden master was cut. Beats me if it's true, but it makes a good story. It was only modestly harder to get compiled and installed on this OS then on others. I was kinda looking forward to a mass release OS with ssh built in though.
I think IE is worse in the OSX release then it was in the public beta. Not really slower as much as it crashes way more often, and the "page holder" has stopped working. I have more or less switched to OmniWeb.
P.S. I dig the new finder, but maybe that is because I like the new list view (well the NeXT list view).
P.P.S. umount -f seems to cause lockups pretty easily. Too bad, all the other BSDs are stable after one.
On the other hand, if you are a printer maker you not only need to add bluetooth hardware, you also have to make your printer conform to the profile (or do so in one mode), which reduces your ability to make your product "different and better".
That's mostly better for the consumer, but worse for the printer makers.