The P-2002W (the phone reviewed) looks way cooler than the 2002W I have, which has the feel of an early 90s cordless phone. The only other differences, besides looks seems to be the support for 802.11g and a portable charger to replace the bulky dock one has to carry around with the 2002W. I also noticed that the new model (like the 2002W) does not have support for WPA encryption, which is mandatory in some hotels and labs.
One major complaint I have about the 2002W is that it heats up a lot, and one can only hope that they've brought this factor under control in the new model. The 2002W will give you an unpleasant reminder that you've talked more than 45 minutes if you accidentally bring it in contact with your ear.
A great feature in both phones is support for traversing NATs through outbound SIP proxies and other things (usually requires support from the provider as well, since NAT traversal is not natively part of SIP). This explains why the author of the article was able to get it working everywhere.
Right.
Also, just because the number of published bug reports/security holes in Linux outnumber the ones published for Unix-X doesn't mean Unix-X is more secure. Linux is not only the most popular Unix on the Internet, but also the most widely used platform for security testing and systems research. If you read up papers on automatic bug-finding tools (à la Coverity), testing tools, model checkers that look for security bugs - they're all over Linux, making a case for themselves by claiming having found '100s of security holes in Linux' (http://portal.acm.org/citation.cfm?id=502041).
No other OS gets that kind of attention.
Politicians, by definition work by demagoguery and hot air and thus bogus claims will often go unchallenged and even supported by specious argument and distraction.
I quite agree with this, but just so that the debate is not one-sided, here's a counter-argument with which I agree just as much:
A research triumph is easier to achieve than it may seem, because the researchers who do the work also do most of the reporting.
--Nick Tredennick and Brion Shimamoto, "Mercy, Mercy, Merced," Microprocessor Report," v. 13, i. 12, Sept. 13, 1999.
While politicians (CEOs, actors, lawyers, judges,...) are scrutinized by journalists on every move they make, most researchers can get away with sub-standard work, or even white lies with a bunch of bad anonymous reviews, which often do not prevent their work from getting published.
Well, to be honest most of the time it's hard enough to figure out where exactly trends are leading and what's the best problem/method combination to try next even if you're a researcher plum in the middle of an area, and have all the data and insight required. It would be quite a hard bet to get anywhere close with keyword-oriented statistical analysis:)
Too bad I couldn't post this in time:( I've been waiting for a Firefox story so that I could ask this. I started using Firefox a few years ago - and found it to be perfect since it was better than IE and much faster than Mozilla. Recently, I upgraded to Firefox 1.0.4 on my Gentoo Linux system running kernel 2.6.12 and since then, I've found a marked degradation in performance - to the extent that it's actually quite annoying. Multi-second freezes with multiple tags have become quite common, and there's a real lag between typing a phrase and seeing it appear in the google toolbar. I tried the pre-compiled version as well as compiling it from the sources and got the same results. So my question is - are there other Firefox users who've experienced the same problem?
I hope that this is either a local problem on my system - or a temporary one that'll go away with the next version. If not, we might see those market figures rebounding a little (for one, I'll change back to Opera).
Here's a script that'll give you a charge/time profile that you can read using GNUPLOT (a free utility available on UNIX): http://www.corewars.org/scripts/bat.pl
Ok, maybe two. But no more. There are way too many protocols and device standards to support out there to allow multiple OSes to run properly in diverse environments. MS has a nice model in which device manufacturers write Windows drivers for free. Linux has a community that works relentlessly at adding compatibility... I don't see any other company/OS that has equivalent mechanisms. It's kind of nice that Nokia and Motorola have started taking steps towards Linux. This way, there'll be an alternative short of smashing your PDA if Windows starts to piss you off.
A lot of people seem to have taken my point to be "kde, gnome etc. are not scriptable and hence not extensible.".That's not the point I wanted to make - the point is that general unix apps - like mailers, user-space drivers for protocols like OBEX etc. come stuck in desktops instead of coming as independent utilities. Of course, many of them can be scripted using the desktop scripting interface (dcop etc.) - but that's the whole point - I don't want to use a bloated desktop.
One seldom commented disadvantage of tightly integrated desktops like Gnome/KDE is their lack of extensibility. Yes, you read that right:) As a 10+ year Linux user, the biggest advantage I've felt of using Linux is its extensibility in the 'UNIX way' - using pipes, scripts and files. The more you change these interfaces into object-oriented/middleware derived ones, the more difficult and annoying it becomes for UNIX hackers to script them - which destroys one of the main purposes of being on UNIX.
With the evolving desktop, people stop writing general purpose tools that abstract data and functionalities as simple files and scripts, and instead write their stuff for specific desktops. One good example is synce - a program to sync WinCe devices with Linux, which integrates well into Evolution, but has no 'dangling interface' where you can just snoop in, get your data and do what you want with it. File-oriented interfaces were a given with most Linux apps till very recently. And as their number/dominance diminish, I wonder if Linux hackers will slowly switch to other UNIXes just because they'd be more UNIX-like.
Well, the obvious solution should be an analog of what they do for spam filtering: decide on a set of "features" of "spam clicks" - like time intervals between them if they come from the same IP address (since it might correspond to many machines behind a NAT), the credibility of the originating network etc. and then use a pattern classifer (like a Bayesian classifier, or a fuzzy classifier) to generate a likeliness of spam.
What should make (IMHO) click-spam filtering less of a hassle to implement is the smaller penalty of failure. If a spam filter wrongly classifies legitimate mail as spam, it may cause the recipient a lot of inconvenience. However, if a click-spam filter wrongly identifies a click as spam, it would not prevent the navigator from getting on the site or buying the advertiser's products. It would mean that the advertiser's account would not get debited for the click. So all advertisers will get a bonus of x% in the number of clicks they get for their cash - some more and some less - but no big deal.
Participants need to write programs that control bots - cop bots and robber bots on a pre-defined map. The goal of the robber bots (of which there's only one in the first round) is to rob as many banks as possible (to rob a bank, a robber needs to simply arrive at its location), and that of the cop bots is to minimize the amount of money stolen - and if possible, catch the robber. The map can be seen as a directed graph with various edge attributes that decide how fast and in what direction a particular bot can move.
What is really interesting though, is the format in which the tournament is going to be played. Every game will consist of 5 cop bots going against 1 robber bot. The cop bots will be written by individual participants - and will have the capability to communicate with each other, suggesting 'plans', and voting on them to elect the best one. The whole team gets rewarded if the robber is caught, but you also get individual bonuses for individual achievements. This adds a byzantine-generals like dimension to the problem, since the strategy is always a mix between cooperative effort and individual greed.
The last and most important twist is the fact that the second round is worth 'significantly' more than the first, and involves adapting your bots to a modified version of the problem. What this modified version will be is a closely guarded secret... but it means that it's probably a good idea to spend as much time thinking about the design as thinking about the strategy.
the beginning of non-intrusive advertising. Google has been doing it and see where it's taken them. The reason brand-makers invest in intrusive advertisements is because they exist. If all advertisement was non-intrusive, they'd be forced to invest in that. What advertisers don't see of course is the gift they would get in disguise- of reaching people who might actually care about their products without offending them. I refuse to believe that the whole internet is financed by 'punch the monkey' type ads.
about this interview is this idea of mutating markets, and how dominating a market does not give you a head start in dominating the next mutant. A great example is the embedded OS market - which has a dozen or so instances (tiny uC based embedded systems, embedded network sensors, phones, real-time devices etc.) There's no way MS, with its enormous inertia is going to go zigzagging through each one of them. And that's where (hopefully) open source will win - with its capacity to adapt.
One might argue that most innovation in software engineering, program analysis
and verification in the past decade has been realized in the OO/formal
semantics community. So for instance, since this
exciting piece of work is implemented in a framework of OO-like interfaces,
it is inamenable to crude pipe-based scripting languages. There has long been a
debate between academics and designers of popular scripting languages like perl
on which way to go (eg. http://www.ai.mit.edu/projects/dynlangs/ll1/). Although
no one side has really won, one conclusion that stands is that scripting defines
its own programming paradigm which should not be confused with anything else
that comes close. Scripting languages MUST facilitate quick and dirty
solutions that just work, or they're not scripting languages anymore. Usually,
the more loaded a language gets with type information and rigid control
constructs, the less capable it gets of letting you produce results without
having to design and debug much.
>The Intel chips have ridiculously small L1 caches - >only 8KB. A quick sampling of washington papers >shows they simulate machines with 64-128KB L1 >caches, which are entirely reasonable - all AMD >processors since the Athlon have had 64KB L1 >caches. Both companies are increasing L2 sizes, and >1-2MB is not unreasonable either.
Well, L1 caches don't count for much anymore, since L1 and L2 latencies aren't that much far apart (2-5ns for L1 and 3-8 for L2 for the new Intel Chips). L1 caches are most useful in storing the stack, which really benefits from locality and can capitalize on that 10% or so latency improvement.
The Washington experiments used between 3MB and 8MB L2 caches, which is not reasonable.
I'm a researcher working on high performance computing and have used various configurations of Simultaneous Multithreading (aka Hyperthreading aka CMT) (Intel Xeon, IBM POWER5).
The result is always the same - at the end, memory latencies and OS overheads kill most of the gains of instruction level parallelism coming from SMT.
Look at it this way - the typical latencies of operations on most modern processors are of the order of 1 nanosecond, whereas DRAM latencies are of the order of 200ns. As long as you can't do anything about this latency, there's no point in cutting down on processing times.
There's a very nice paper in this year's ACM SIGMETRICS that gives real experimental data to illustrate this fact - http://www.cs.princeton.edu/~yruan/XeonSMT/smt.pdf
The paper shows that the speedups obtained using SMT in practice are meagre. The reason that the simulation results coming from the original UWashington research on the subject - http://www.cs.washington.edu/research/smt/ - looked far better was their use of unreasonably large caches in their simulations, and that they completely ignored the OS overhead of enabling SMT - which is non-negligeable - and is a thing that has been pointed out often on the Linux Kernel mailing list as well.
You have to understand that the cost benefit will soon cease to be the dominant factor in outsourcing. The prices of supply-chain consulting in India have been rising at a rate of 15-20% every year. Moreover, the mechanics that move this business are nearing a point of saturation (all flights - inland and overseas are _always_ booked, hotels are jam packed).
The other factor, which Americans will probably want to deny - is the productivity factor. The average guy sitting behind a helpdesk in India is more often than not a college graduate. People who do supply-chain related work very often graduate from the absolute best universities in the country. The reason they're doing this kind of work of course, is that there is often no avenue for improvement. Whereas a Berkeley graduate in the US might go into scientific research, or tech-intensive development, a corresponding IIT graduate does not have those kinds of jobs, at least in India. What it means is that Indians in the same positions in outsourced jobs are often more productive, and for the moment, they're also cheaper.
One of the things mainstream consoles lack is a 'boss key', that instantly turns everything into a spreadsheet/C IDE (Alt-[0-9] in WindowMaker). And come to think of it, even if they did that, the concave X-shape of the device would probably give me away... Unless I disguised that too... (((hm))
The idea of homework is right, since it tries to give students an excuse to learn and be productive, without which they sit around and watch TV all day long. The implementation of it is wrong, since it's too specific and more often than not, forces them into doing things they'd much rather not. All students are interested in at least some subjects. There are students who would prefer to write computer programs that solve differencial equations instead of solving them with pen and paper, or students who'd have more fun writing a formal letter to Mr. Vader asking for permission to use the airspace on Planet X than to the principal of their school to ask for leave (which was typical for the institution I went to).
Students need to be forced into motion, but into doing what they want and enjoy, as opposed to what conventions want them to do.
The P-2002W (the phone reviewed) looks way cooler than the 2002W I have, which has the feel of an early 90s cordless phone. The only other differences, besides looks seems to be the support for 802.11g and a portable charger to replace the bulky dock one has to carry around with the 2002W. I also noticed that the new model (like the 2002W) does not have support for WPA encryption, which is mandatory in some hotels and labs.
One major complaint I have about the 2002W is that it heats up a lot, and one can only hope that they've brought this factor under control in the new model. The 2002W will give you an unpleasant reminder that you've talked more than 45 minutes if you accidentally bring it in contact with your ear.
A great feature in both phones is support for traversing NATs through outbound SIP proxies and other things (usually requires support from the provider as well, since NAT traversal is not natively part of SIP). This explains why the author of the article was able to get it working everywhere.
Right.
Also, just because the number of published bug reports/security holes in Linux outnumber the ones published for Unix-X doesn't mean Unix-X is more secure. Linux is not only the most popular Unix on the Internet, but also the most widely used platform for security testing and systems research. If you read up papers on automatic bug-finding tools (à la Coverity), testing tools, model checkers that look for security bugs - they're all over Linux, making a case for themselves by claiming having found '100s of security holes in Linux' (http://portal.acm.org/citation.cfm?id=502041).
No other OS gets that kind of attention.
I quite agree with this, but just so that the debate is not one-sided, here's a counter-argument with which I agree just as much:
A research triumph is easier to achieve than it may seem, because the researchers who do the work also do most of the reporting.
--Nick Tredennick and Brion Shimamoto, "Mercy, Mercy, Merced," Microprocessor Report," v. 13, i. 12, Sept. 13, 1999.
While politicians (CEOs, actors, lawyers, judges,...) are scrutinized by journalists on every move they make, most researchers can get away with sub-standard work, or even white lies with a bunch of bad anonymous reviews, which often do not prevent their work from getting published.
Well, to be honest most of the time it's hard enough to figure out where exactly trends are leading and what's the best problem/method combination to try next even if you're a researcher plum in the middle of an area, and have all the data and insight required. It would be quite a hard bet to get anywhere close with keyword-oriented statistical analysis:)
Too bad I couldn't post this in time:( I've been waiting for a Firefox story so that I could ask this. I started using Firefox a few years ago - and found it to be perfect since it was better than IE and much faster than Mozilla. Recently, I upgraded to Firefox 1.0.4 on my Gentoo Linux system running kernel 2.6.12 and since then, I've found a marked degradation in performance - to the extent that it's actually quite annoying. Multi-second freezes with multiple tags have become quite common, and there's a real lag between typing a phrase and seeing it appear in the google toolbar. I tried the pre-compiled version as well as compiling it from the sources and got the same results. So my question is - are there other Firefox users who've experienced the same problem?
I hope that this is either a local problem on my system - or a temporary one that'll go away with the next version. If not, we might see those market figures rebounding a little (for one, I'll change back to Opera).
1. Download and burn a Knoppix/Gentoo/Ubuntu live CD
2. Boot with it
3. cat
4. cat
http://www.corewars.org/scripts/bat.pl
Ok, maybe two. But no more. There are way too many protocols and device standards to support out there to allow multiple OSes to run properly in diverse environments. MS has a nice model in which device manufacturers write Windows drivers for free. Linux has a community that works relentlessly at adding compatibility... I don't see any other company/OS that has equivalent mechanisms. It's kind of nice that Nokia and Motorola have started taking steps towards Linux. This way, there'll be an alternative short of smashing your PDA if Windows starts to piss you off.
A lot of people seem to have taken my point to be "kde, gnome etc. are not scriptable and hence not extensible.".That's not the point I wanted to make - the point is that general unix apps - like mailers, user-space drivers for protocols like OBEX etc. come stuck in desktops instead of coming as independent utilities.
Of course, many of them can be scripted using the desktop scripting interface (dcop etc.) - but that's the whole point - I don't want to use a bloated desktop.
One seldom commented disadvantage of tightly integrated desktops like Gnome/KDE is their lack of extensibility. Yes, you read that right:) As a 10+ year Linux user, the biggest advantage I've felt of using Linux is its extensibility in the 'UNIX way' - using pipes, scripts and files. The more you change these interfaces into object-oriented/middleware derived ones, the more difficult and annoying it becomes for UNIX hackers to script them - which destroys one of the main purposes of being on UNIX.
With the evolving desktop, people stop writing general purpose tools that abstract data and functionalities as simple files and scripts, and instead write their stuff for specific desktops. One good example is synce - a program to sync WinCe devices with Linux, which integrates well into Evolution, but has no 'dangling interface' where you can just snoop in, get your data and do what you want with it. File-oriented interfaces were a given with most Linux apps till very recently. And as their number/dominance diminish, I wonder if Linux hackers will slowly switch to other UNIXes just because they'd be more UNIX-like.
Well, the obvious solution should be an analog of what they do for spam filtering: decide on a set of "features" of "spam clicks" - like time intervals between them if they come from the same IP address (since it might correspond to many machines behind a NAT), the credibility of the originating network etc. and then use a pattern classifer (like a Bayesian classifier, or a fuzzy classifier) to generate a likeliness of spam.
What should make (IMHO) click-spam filtering less of a hassle to implement is the smaller penalty of failure. If a spam filter wrongly classifies legitimate mail as spam, it may cause the recipient a lot of inconvenience. However, if a click-spam filter wrongly identifies a click as spam, it would not prevent the navigator from getting on the site or buying the advertiser's products. It would mean that the advertiser's account would not get debited for the click. So all advertisers will get a bonus of x% in the number of clicks they get for their cash - some more and some less - but no big deal.
Participants need to write programs that control bots - cop bots and robber bots on a pre-defined map. The goal of the robber bots (of which there's only one in the first round) is to rob as many banks as possible (to rob a bank, a robber needs to simply arrive at its location), and that of the cop bots is to minimize the amount of money stolen - and if possible, catch the robber. The map can be seen as a directed graph with various edge attributes that decide how fast and in what direction a particular bot can move.
What is really interesting though, is the format in which the tournament is going to be played. Every game will consist of 5 cop bots going against 1 robber bot. The cop bots will be written by individual participants - and will have the capability to communicate with each other, suggesting 'plans', and voting on them to elect the best one. The whole team gets rewarded if the robber is caught, but you also get individual bonuses for individual achievements. This adds a byzantine-generals like dimension to the problem, since the strategy is always a mix between cooperative effort and individual greed.
The last and most important twist is the fact that the second round is worth 'significantly' more than the first, and involves adapting your bots to a modified version of the problem. What this modified version will be is a closely guarded secret... but it means that it's probably a good idea to spend as much time thinking about the design as thinking about the strategy.
the beginning of non-intrusive advertising. Google has been doing it and see where it's taken them. The reason brand-makers invest in intrusive advertisements is because they exist. If all advertisement was non-intrusive, they'd be forced to invest in that. What advertisers don't see of course is the gift they would get in disguise- of reaching people who might actually care about their products without offending them. I refuse to believe that the whole internet is financed by 'punch the monkey' type ads.
about this interview is this idea of mutating markets, and how dominating a market does not give you a head start in dominating the next mutant. A great example is the embedded OS market - which has a dozen or so instances (tiny uC based embedded systems, embedded network sensors, phones, real-time devices etc.) There's no way MS, with its enormous inertia is going to go zigzagging through each one of them. And that's where (hopefully) open source will win - with its capacity to adapt.
One might argue that most innovation in software engineering, program analysis and verification in the past decade has been realized in the OO/formal semantics community. So for instance, since this exciting piece of work is implemented in a framework of OO-like interfaces, it is inamenable to crude pipe-based scripting languages. There has long been a debate between academics and designers of popular scripting languages like perl on which way to go (eg. http://www.ai.mit.edu/projects/dynlangs/ll1/). Although no one side has really won, one conclusion that stands is that scripting defines its own programming paradigm which should not be confused with anything else that comes close. Scripting languages MUST facilitate quick and dirty solutions that just work, or they're not scripting languages anymore. Usually, the more loaded a language gets with type information and rigid control constructs, the less capable it gets of letting you produce results without having to design and debug much.
>The Intel chips have ridiculously small L1 caches - >only 8KB. A quick sampling of washington papers >shows they simulate machines with 64-128KB L1 >caches, which are entirely reasonable - all AMD >processors since the Athlon have had 64KB L1 >caches. Both companies are increasing L2 sizes, and >1-2MB is not unreasonable either. Well, L1 caches don't count for much anymore, since L1 and L2 latencies aren't that much far apart (2-5ns for L1 and 3-8 for L2 for the new Intel Chips). L1 caches are most useful in storing the stack, which really benefits from locality and can capitalize on that 10% or so latency improvement. The Washington experiments used between 3MB and 8MB L2 caches, which is not reasonable.
I'm a researcher working on high performance computing and have used various configurations of Simultaneous Multithreading (aka Hyperthreading aka CMT) (Intel Xeon, IBM POWER5). The result is always the same - at the end, memory latencies and OS overheads kill most of the gains of instruction level parallelism coming from SMT. Look at it this way - the typical latencies of operations on most modern processors are of the order of 1 nanosecond, whereas DRAM latencies are of the order of 200ns. As long as you can't do anything about this latency, there's no point in cutting down on processing times. There's a very nice paper in this year's ACM SIGMETRICS that gives real experimental data to illustrate this fact - http://www.cs.princeton.edu/~yruan/XeonSMT/smt.pdf
The paper shows that the speedups obtained using SMT in practice are meagre. The reason that the simulation results coming from the original UWashington research on the subject - http://www.cs.washington.edu/research/smt/ - looked far better was their use of unreasonably large caches in their simulations, and that they completely ignored the OS overhead of enabling SMT - which is non-negligeable - and is a thing that has been pointed out often on the Linux Kernel mailing list as well.
You have to understand that the cost benefit will soon cease to be the dominant factor in outsourcing. The prices of supply-chain consulting in India have been rising at a rate of 15-20% every year. Moreover, the mechanics that move this business are nearing a point of saturation (all flights - inland and overseas are _always_ booked, hotels are jam packed). The other factor, which Americans will probably want to deny - is the productivity factor. The average guy sitting behind a helpdesk in India is more often than not a college graduate. People who do supply-chain related work very often graduate from the absolute best universities in the country. The reason they're doing this kind of work of course, is that there is often no avenue for improvement. Whereas a Berkeley graduate in the US might go into scientific research, or tech-intensive development, a corresponding IIT graduate does not have those kinds of jobs, at least in India. What it means is that Indians in the same positions in outsourced jobs are often more productive, and for the moment, they're also cheaper.
One of the things mainstream consoles lack is a 'boss key', that instantly turns everything into a spreadsheet/C IDE (Alt-[0-9] in WindowMaker). And come to think of it, even if they did that, the concave X-shape of the device would probably give me away... Unless I disguised that too... (((hm))
The idea of homework is right, since it tries to give students an excuse to learn and be productive, without which they sit around and watch TV all day long. The implementation of it is wrong, since it's too specific and more often than not, forces them into doing things they'd much rather not. All students are interested in at least some subjects. There are students who would prefer to write computer programs that solve differencial equations instead of solving them with pen and paper, or students who'd have more fun writing a formal letter to Mr. Vader asking for permission to use the airspace on Planet X than to the principal of their school to ask for leave (which was typical for the institution I went to). Students need to be forced into motion, but into doing what they want and enjoy, as opposed to what conventions want them to do.