I can't help but wonder whether the payment card industry will adjust their security standards in the face of this kind of threat. Currently, the security standards stipulate that a credit card number has been sufficiently protected/destroyed if only the last four digits of the account number are kept. In the face of this kind of attack, would that be enough? All of a sudden, what information is left is being used to obtain whatever was missing.
I can see security requirements being adjusted in a couple of ways: First, require complete obliteration of the credit card account number when it is no longer needed. Don't even keep the last four digits. Second, require that various pieces of information be kept in separate logical or physical databases. If card numbers are stored separate from addresses and other personal information, it's one more barrier for an attacker to overcome.
It's thus entirely rational not to want to learn this stuff until you absolutely need to use it. But that makes life more frustrating, since it puts you in "learning mode" when you're trying to do something new and possibly stressful...
Rant mode: On.
This is pure intellectual laziness. What is wrong with being in a "learning mode?" We do it our entire lives! Why should someone want to actually stop learning?
I've noticed a very disturbing trend lately. It could just be my perceptions, but it still gives me cause for concern. Many people (both general consumers and professionals in business) don't want to bother learning anything. They want to tackle complex tasks that could never be done before, but insist on not having to learn the tools to do it. I see it here at work with people who insist on holding on desperately to suboptimal programming tools when others would tackle the job more effectively. I even see it in my own family: I once got a call from my mother, while she was on vacation, asking how to access the voicemail for her cell phone. She called me at work, in the middle of the day, simply because she had never bothered reading the instructions from her service provider! (I taught her the meaning of RTFM that day.)
I understand that many products can be difficult to use, especially software. It takes effort to learn these products, and effort to use them. However, very often we barely have the technology working. How can you expect it to be easy to use as well? Automobiles, television sets, and radios are all products that many now consider fairly easy to use. Now ask the question: How long did it take for them to get to be so simple? Some of these products have been continually developed and refined for over a century. Now consider how long VCRs, camcorders, and software products have been around. By comparison, these are all fresh out of the R&D lab!
People need to realize that complex tasks can't generally be simplified overnight. It takes time to find the solution to the problems at hand, and even more time to refine the solution such that it is both effective and efficient (i.e. it requires a minimum of effort to use.) All of the complaining does nothing but add to the noise.
I simply must second this suggestion. For complex groupware, nothing on the market today can beat Lotus Notes and Domino. If you've ever used significant applications in Notes, you'll understand why.
If all you're looking for is an email server and shared calendars, don't bother with Notes. You'll be wasting your time. As an email client, Notes R5 was a huge improvement over prior generations, but still doesn't hold a candle to products like Eudora, Evolution, KMail, or even arguably Mutt! But then, I don't think tossing email around can really be considered groupware.
I've worked as a software engineer at Lotus--though not on the Notes team. I've used Notes for a huge number of applications, from basic administrative stuff to project management and bug tracking. I've also developed applications with Notes. When you have complex collaboration problems to solve, nothing can beat Notes for building a solution. Nothing.
Notes provides you with an infrastructure that lends itself to sharing information quickly and easily. I'm not talking about tossing Word documents at other people. I mean real collaboration, both free-form and with formal processes. With Notes, it's easy to set up a central repository for all documents related to a project. They can easily be linked, indexed, and cross-referenced and searched without the need for extra software. Documents can be signed and authenticated easily thanks to the public key infrastructure built into the system. Workflows can be easily built, including electronic signatures for approvals. To top it all off, most of these applications can be easily exposed to a web browser to enable collaboration with people outside your organization.
I've been often frustrated in my current job because of Exchange and Outlook limitations. Maybe I'm spoiled, but Exchange simply doesn't facilitate the kind of pervasive sharing of information I'm accustomed to with Notes. Then there's those damned email viruses. We laughed within Lotus when the VBScript based viruses first started appearing. We didn't get touched. Notes is, by default, secure enough to disallow execution of unknown scripts. You have to go out of your way to allow such a virus to damage your system. Even then, it won't necessarily harm anyone else in your organization.
I may sound like a saleman here, but I assure you I'm not. Notes isn't perfect, not by a long shot. Nor is it appropriate for all organizations. It has some serious technical problems (IMHO, of course) resulting from its long legacy, not the least of which is its heft. These problems are slowly being remedied, though. R5 made a huge leap in notes database reliabilty and speed. Connectivity to external systems (especially via standard Internet protocols) is improving as well. I expect future updates will continue this trend. However, I believe that IBM/Lotus will continue to emphasize collaborative applications with Notes over simple email and calendar sharing. I think this is the right decision, even though it will disappoint many (such as others posting in this thead.)
In short, if your users just want email and calendar software, go with Exchange or some similar solution. If, however, they need an infrastructure to support serious collaboration, complex workflows, and pervasive information sharing, Notes and Domino are the solution.
Why does the repository need to be public? In an era of very powerful client machines, why must we have a centralized database to make this work? Systems like Napster and Gnutella have already demonstrated the ability of end-user machines to distribute data effectively (though not always efficiently.)
I belive the safest route would be to avoid the publicly accessible, centralized data store and focus on what has worked so well for the Internet in the past: standard communications protocols. By leaving the data on individual systems, we minimize the risk of exposing vast quantities of personal information as an attacker would need to go after millions of machines in turn. It's possible, but it wouldn't be easy.
I see a number of postings here to the effect that voice recognition, especially for dictation, will be largely useless. The problem is that these postings are considering the use of voice recognition as a replacement for typing within the current crop of user interfaces.
The true power of voice recognition is not in replacing the keyboard. It comes with allowing new forms of interaction with a computer. Consider the simple task of checking the weather. Pulling up a browser and heading to weather.com is no big task, but why would I want to sit at my computer and have to do that just so I can decide how heavy a sweater I'll need for the day? Why not just ask the computer to read me the forecast while I'm getting dressed?
Many people would assume in this scenario that one would call out: "Computer, browse to h t t p colon slash slash w w w dot weather dot com. Read page." How about simply calling a script intead that does all the hard work behind the scenes? "Computer, what is the weather forecast for today?" The use of predefined grammars, as the article describes, will make such queries very reliable as they will be much easier to recognize.
This may have been a simple example, but hopefully it gets the point across. Voice recognition is not going to replace typing. As many have said, some people can type much faster than they can dictate text. Once you start considering higher level interaction with the computer, however, the situation changes, and voice recognition systems will really show their colors.
One source that may be useful to you is the Handbook of Programming Languages Vol. 1-4 by Peter H. Salus. (Available at Fatbrain and Borders.)
This is a comprehensive survey of just about every programming language under the sun. It covers some of their history as well as the syntax and sematics of the languages themselves. It should prove to be a useful starting point for intensive research on language topics.
Althought the algorithm used in the above two programs is the same, the specific semantics are different. In the Python program above, you are using global variables. The C implementation of Python is notoriously slow in looking up global variables. In addition, the range() function allocates an array of values, as other posters have pointed out.
I wrote a version of your program which uses xrange() and saw a significant performance increase:
#!/usr/local/bin/python
endp = 10000;
totl = 0
for i in xrange(2,endp):
for j in xrange(2,i):
if i%j == 0:
break
else:
totl = totl + 1
print totl, 'prime numbers between 1 and', endp
Your original script on my machine produced the following (yes, I'm running on W2K; I'm at work. *sigh*):
[//c/Projects/Scripts] time python primes_orig.py
1229 prime numbers between 1 and 10000
real 0m10.215s
user 0m0.010s
sys 0m0.040s
The new script above produced:
[//c/Projects/Scripts] time python primes_xrange.py
1229 prime numbers between 1 and 10000
real 0m6.980s
user 0m0.010s
sys 0m0.000s
I was further able to shave another 1.4s off that time by moving everything into a function:
#!/usr/local/bin/python
def getprimes(endp):
totl = 0
for i in xrange(2,endp):
for j in xrange(2,i):
if i%j == 0:
break
else:
totl = totl + 1
return totl
max = 10000
print getprimes(max), 'prime numbers between 1 and', max
This resulted in:
[//c/Projects/Scripts] time python primes_new.py
1229 prime numbers between 1 and 10000
real 0m5.578s
user 0m0.010s
sys 0m0.000s
I'm sure that the real Python gurus can do a whole lot better. You can always post to comp.lang.python and get some truly outstanding help there. It's one of the few remaining civil newsgroups left on Usenet (in my opinion, of course).
Keep in mind, though, that benchmarks like these don't tell you the whole story. For one thing, consider how much more a developer's time will cost you compared to the extra processing time. A good Python programmer will, in many cases, crank out a program in a fraction of the time that a good C programmer will take. This will vary from programmer to programmer, of course, but I have found that to hold true in my particular case.
I have done a fair amount of commercial Windows development and can say that there are a number of advantages to working in a Unix environment, if not specifically Linux.
The one advantage that stands out the most in my mind is the kill command. I have fought Windows NT countless times trying to get it to kill an errant process. I gave up completely under Windows 95/98, just rebooting the machine when needed. I have NEVER had to do something like this in a Unix environment. Even when I have faced a stubbornly hung Lotus Domino server (which leaves resources open all over the place), I could still force it to shut down and be removed from memory so I could restart it. No reboots necessary. This little trick alone has probably saved me hundreds of hours of grief waiting for a machine to reboot just so I can continue development. There is no doubt in my mind that I am therefore far more productive developing in a Unix environment when compared to Windows.
Now, my preference of Linux over other Unix systems... well, that's another post.:-)
Some state governments, particularly Massachusetts, are making an effort to bring more and more transactions online. For example, take a look at the Registry of Motor Vehicles home page. You can change registration information, get replacement licenses issued, and even pay your tickets online. And let's not forget that many states, and even Uncle Sam himself, are allowing people to file and pay their taxes electronically.
One thing I have learned about user interfaces is that the audience they target matters. Determining who that audience is (the real 'users' of the system) is absolutely critical to assembling a good interface. The requirements for a novice user will be very different than those of an advanced user or developer.
If you are targeting novice users, simplicity is key. Guide the user through tasks, and provide plenty of visual cues for what needs to be done next. Consider using text as well as graphics to label items such as toolbar buttons so the user doesn't have to go on a fishing expedition to find a piece of functionality.
For more advanced users, speed of use becomes more important. Provide shortcuts to certain operations, including special keyboard and keyboard-mouse combinations. Once more advanced users learn the shortcuts for frequently used features, they will (hopefully) be more productive. Options that would be hidden or eliminated for novices can be exposed and presented in plain dialog boxes instead of "wizards".
As for interfaces for developers, just take your best shot. Provide power and flexibility. Beyond that, we're just too damned picky to be kept happy.;-)
The most difficult task is creating an interface that satisfies all of the above groups. Many have tried to build interfaces that can gradually expose functionality, with limited success. In my very humble opinion, no one has yet to fully address all the needs of these various audiences in an application. In my work, I tend to avoid this challenge and simply address a given audience specifically. Developers get powerful and flexible (though maybe overwhelming) UIs, while the "suits" get the wizards and simple UIs.
In my travails through Usenet and other discussion boards, I have found one common thread underlying most of the flames I have come across: a simple lack of communication skills.
Let me first say that I am not a psychologist or sociologist. My statements here are purely my opinion based on personal observation. They are in no way authoritative statements on the matter.
That said, I often find that many who partake in online flaming demonstrate a similar trait to those people I encounter in real life who use profanity. They all lack the ability to compose and communicate their ideas effectively. Online, many discussions degenerate into base name-calling and personal attacks. This downward spiral into flaming seems to begin at a point of frustration for one of the parties involved in the conversation. That is the point in which the poster cannot effectively either compose an argument, or clearly express an otherwise valid argument. This leads to either the use of strong language from sheer frustration, or the selection of inappropriate or inaccurate phrases to express and idea. Once the message is posted, the resulting misinterpretation of the message causes the receiver to go on the defensive. Once that happens, I have found that there is little hope in salvaging the thread of conversation.
I see the same sort of frustration and reaction in face-to-face encounters as well. Many people simply do not have the ability to express themselves adequately, instead choosing to use a string of explitives and other vulgar phrases. Clearly, this continually fails to get the intended ideas across. Many loud arguments, if not outright altercations, result from the frustration and misunderstandings that result.
What is the cause of this? I really can't say. I could easily blame the education systems or point to other societal factors. However, I have never seen any convincing evidence pointing to any one causal factor. Because I do not know the source of the problem, I treat the symptoms as I can. Among my friends and acquaitances, I try to put myself in the position of arbitrator, in the hopes of clarifying ideas between the people involved. I try to explicitly state assumed or implied ideas to avoid misinterpretations. Finally, I try to propose compromises and avenues for further civil discussions.
Can anyone suggest other means for resolving these problems?
The issue with supporting Domino R5 on different Linux distributions comes largely from two points:
1. Different distributions use different libc/glibc versions. Domino was written to use the latest production glibc, thus the support of Red Hat 6.0 and OpenLinux.
2. The QA effort to validate a Domino installation across all the major Linux distributions is immense. Even with automated test suites, the amount of person-hours spent on thoroughly testing a Domino release on one platform (and different OS releases/distributions are considered separate platforms) becomes a prohibitive obstacle to testing all of them.
Domino itself does or uses nothing that is distribution-specific. It installs itself completely under/opt/lotus, as do the other Unix variants. However, with the diverse universe of Linux distributions that exist today, it would be impractical for Lotus to assume responsibility for software/platform combinations that they have not tested.
Now, if you want to complain about the fact that they aren't porting the clients, I'll complain right along with you.:-)
What happened at Jane's really amazes me. It shouldn't, but the rarity of seeing a publication actually listen to feedback before publishing an article makes it so. I am very tired of the reporting I see in the media today. I almost never watch television news, and only selectively read the newspaper (usually online). I am constantly disappointed by the poor research and significant biases I see in what should be unbiased, factual articles.
I have to wonder whether the root of the problem is simply laziness. One could argue that the media has become an intensely competetive environment where more and more publications (and shows) are fighting for a fixed number of eyeballs. As a result, journalists have to scramble to produce their pieces as quickly as possible. One could also argue that the world is becoming increasingly complex and that those same journalists just can't keep up.
I would argue that a culture of laziness has instead grown within the media industry. In that light, the former arguments are simply obstacles to be surmounted like any other. Tight deadlines are no excuse for shoddy or inaccurate reporting. Likewise the complexity of the issues involved are no excuse for a lack of any research. There are experts in all fields, experts that can be contacted to clarify and comment on the actual issues.
Journalists are not omniscient, nor are they infinitely quick at the keyboard. Their job is not to be either. Instead, their job is to gather information from others in the know and to present a balanced, factually based account of the matter at hand.
What really amazes me is how quickly and vehemently many people reacted when this story first appeared. Instead of waiting to hear all sides of the issue, many people automatically assumed the worst.
It seems to me that there is a very prominent fear in the Linux community of any attempt to commercialize Linux. I have seen countless comments over the last few months (here on/. and elsewhere) fearing or predicting that Red Hat would begin to walk the same path that Microsoft has. Many believe that somehow Red Hat would hijack Linux and pervert it for their own purposes. They somehow equate the high visibility that Red Hat has obtained with the tendency or desire to make money at all costs, including screwing the consumers and end users.
When I first read the hubbub surrounding the Amazon.com letter, I didn't jump to conclusions. I knew that Red Hat has maintained an excellent reputation for being open and fair, and preventing all uses of the Red Hat moniker outside of officially sanctioned products didn't seem to fit with that reputation. Red Hat is not a company to fear. Not only are they unable to hijack Linux (thanks to the GPL and other licenses), it would be a very bad business decision. They would lose the trust and support of the very developers and community they rely on in order to provide their product.
Red Hat has done a great job of being open and honest with us in the past. They really do deserve the benefit of the doubt when situations like this arise. I can only hope that those who have risen up against Red Hat in the past will take this into consideration before vilifying them in the future.
Ah, yes. I remember Galaxy rather fondly. At my last job, I was tasked with evaluating a variety of GUI frameworks and toolkits for X11 development across Sun and SGI boxes. I looked at Zapp, Zinc, plain Motif (which the last version of the app had used), and a few free software frameworks which I don't recall at the moment. Galaxy stood heads and shoulders above all the competition.
I was particularly fond of the spring and struts mechanism for putting together dynamically sizeable windows. The layout mechanism allowed you to specify fairly arbitrary constraints on any widget that got placed in a window or other component. I consider it an even better system than the fabulous layout managers we see in Java's AWT or Swing toolkits.
The GUI designer was a wonder to work with as well. I managed to prototype our entire user interface in what seemed like no time at all. We were then able to take some screen shots, clean them up in Photoshop, and drop them straight into our design documents. Our clients loved it. The docs looked great, described the interface far better than prose alone could have, and we hadn't even written a single line of code!
I see a great deal of potential along these lines with Glade (and libGlade). Storing the interface definition as an XML file is a fabulous idea. This gives you far more flexibility than Galaxy ever did, especially if you need to programmatically alter your interface, or perhaps translate it for internationalization purposes.
Now if only we can get springs and struts into GTK+...
Design documents and formal processes have both good points and bad. Sometimes the documentation and rigorous peer-review proves invaluable. Other times, it simply gets in the way of achieving the primary goal, that is, to solve a problem with the computer.
Now, I currently work at a large software development company and have seen quite a number of developers come and go. This is one case in which documentation of the design is invaluable. Keeping up-to-date design documents allows new developers--and even QA staff--to come up to speed quickly. It flattens the learning curve and allows them to begin contributing to the project much sooner than if they had to fight for another developer's time or dig through mountains of source code.
The peer review process helps here as well when the developers coming on board are fairly green. There are many mistakes that developers make (and yes, we all made them at some point) which can be easily caught and rectified with a thorough peer-review and follow-up instruction.
That said, I have to admit that religious adherence to such processes does tend to get in the way of producing a product. At my previous employer, I worked on a government contract where we had to deliver a formal requirements analysis, design documentation, and subsequent detailed code reference. Due to the constantly expanding scope of the project (When does this ever not happen?), the documentation was never quite up-to-date and was useless to the development staff. We had our heads in the code and relied on reading the code and associated comments to figure out what was really going on. The documentation we generated in the end would definitely prove useful to later developers who would maintain the code, but for those working on the first version, it was seen as time wasted.
At my current job, I see the problems that come from constantly changing requirements. No matter how much we try to plan ahead and generate design documentation for a new product feature, we inevitably get caught up in the implementation and the documentation suffers. With constantly impending deadlines and never enough resources, it becomes a struggle to keep design documentation up to date. More often than not, new developers and QA staff end up hunting down the person responsible for developing a feature in order to find the answers to questions. Most of the design documents we do have are horribly out of date or don't have enough detail to answer the questions at hand. Ultimately, developers still dive into the code to figure out what is going on.
There are pros and cons to rigorous engineering practices. What I have learned is that you must find a balance between free-form creating and hacking and disciplined engineering practices. Where that balance point lies depends greatly on the people involved as much as the project itself. Take a good long look at your developers and how they have reacted to processes in the past. Take a look at the software you need to develop and figure out how rigorous you need to be in developing it. Look at your schedule and see how flexible you need to be to get things done. Pick a point somewhere in the middle and give it a shot.
Censorship and Choice are ambiguous words
on
ShutUp Software
·
· Score: 1
I also turn off the filters every once in a while to see what I'm "missing". Sometimes I find things that I should filter back in, most of the time I don't. But having the ability to see things unfiltered is necessary.
I fear you may be in the minority here. Although I avoid it, many people simply add one person or another to a filter and never look back. Though sometimes necessary, this is short-sighted and very closed-minded behavior.
My reading of Katz's article and postings (and I reserve the right to be wrong) is that he is in no way taking issue with the simple existence of these filters. In fact, he acknowleges that the choice to listen must exist. What he is trying to point out is what the consequences of not listening may be. It is indeed a frightening though that the Internet may some day be seen only through rose-colored glasses that eliminate anything offensive or contrarian from view. Criticism and disagreement are the foundation of intelligent discussion. They prevent stagnation of thought. They force us to analyze our assumptions and further investigate the world we live in. Without the challenge, without the disagreement, how will we learn? How will we grow as intelligent creatures?
Overuse of filtering software puts those thick, rose-colored glasses on us. They restrict our vision and, as a result, our thought. This is too heavy a burden to wear, and one which I choose to never carry.
Slashdot Mirror
I can't help but wonder whether the payment card industry will adjust their security standards in the face of this kind of threat. Currently, the security standards stipulate that a credit card number has been sufficiently protected/destroyed if only the last four digits of the account number are kept. In the face of this kind of attack, would that be enough? All of a sudden, what information is left is being used to obtain whatever was missing.
I can see security requirements being adjusted in a couple of ways: First, require complete obliteration of the credit card account number when it is no longer needed. Don't even keep the last four digits. Second, require that various pieces of information be kept in separate logical or physical databases. If card numbers are stored separate from addresses and other personal information, it's one more barrier for an attacker to overcome.
Rant mode: On.
This is pure intellectual laziness. What is wrong with being in a "learning mode?" We do it our entire lives! Why should someone want to actually stop learning?
I've noticed a very disturbing trend lately. It could just be my perceptions, but it still gives me cause for concern. Many people (both general consumers and professionals in business) don't want to bother learning anything. They want to tackle complex tasks that could never be done before, but insist on not having to learn the tools to do it. I see it here at work with people who insist on holding on desperately to suboptimal programming tools when others would tackle the job more effectively. I even see it in my own family: I once got a call from my mother, while she was on vacation, asking how to access the voicemail for her cell phone. She called me at work, in the middle of the day, simply because she had never bothered reading the instructions from her service provider! (I taught her the meaning of RTFM that day.)
I understand that many products can be difficult to use, especially software. It takes effort to learn these products, and effort to use them. However, very often we barely have the technology working. How can you expect it to be easy to use as well? Automobiles, television sets, and radios are all products that many now consider fairly easy to use. Now ask the question: How long did it take for them to get to be so simple? Some of these products have been continually developed and refined for over a century. Now consider how long VCRs, camcorders, and software products have been around. By comparison, these are all fresh out of the R&D lab!
People need to realize that complex tasks can't generally be simplified overnight. It takes time to find the solution to the problems at hand, and even more time to refine the solution such that it is both effective and efficient (i.e. it requires a minimum of effort to use.) All of the complaining does nothing but add to the noise.
Rant mode: Off.
Thanks for reading.-kjz
I simply must second this suggestion. For complex groupware, nothing on the market today can beat Lotus Notes and Domino. If you've ever used significant applications in Notes, you'll understand why.
If all you're looking for is an email server and shared calendars, don't bother with Notes. You'll be wasting your time. As an email client, Notes R5 was a huge improvement over prior generations, but still doesn't hold a candle to products like Eudora, Evolution, KMail, or even arguably Mutt! But then, I don't think tossing email around can really be considered groupware.
I've worked as a software engineer at Lotus--though not on the Notes team. I've used Notes for a huge number of applications, from basic administrative stuff to project management and bug tracking. I've also developed applications with Notes. When you have complex collaboration problems to solve, nothing can beat Notes for building a solution. Nothing.
Notes provides you with an infrastructure that lends itself to sharing information quickly and easily. I'm not talking about tossing Word documents at other people. I mean real collaboration, both free-form and with formal processes. With Notes, it's easy to set up a central repository for all documents related to a project. They can easily be linked, indexed, and cross-referenced and searched without the need for extra software. Documents can be signed and authenticated easily thanks to the public key infrastructure built into the system. Workflows can be easily built, including electronic signatures for approvals. To top it all off, most of these applications can be easily exposed to a web browser to enable collaboration with people outside your organization.
I've been often frustrated in my current job because of Exchange and Outlook limitations. Maybe I'm spoiled, but Exchange simply doesn't facilitate the kind of pervasive sharing of information I'm accustomed to with Notes. Then there's those damned email viruses. We laughed within Lotus when the VBScript based viruses first started appearing. We didn't get touched. Notes is, by default, secure enough to disallow execution of unknown scripts. You have to go out of your way to allow such a virus to damage your system. Even then, it won't necessarily harm anyone else in your organization.
I may sound like a saleman here, but I assure you I'm not. Notes isn't perfect, not by a long shot. Nor is it appropriate for all organizations. It has some serious technical problems (IMHO, of course) resulting from its long legacy, not the least of which is its heft. These problems are slowly being remedied, though. R5 made a huge leap in notes database reliabilty and speed. Connectivity to external systems (especially via standard Internet protocols) is improving as well. I expect future updates will continue this trend. However, I believe that IBM/Lotus will continue to emphasize collaborative applications with Notes over simple email and calendar sharing. I think this is the right decision, even though it will disappoint many (such as others posting in this thead.)
In short, if your users just want email and calendar software, go with Exchange or some similar solution. If, however, they need an infrastructure to support serious collaboration, complex workflows, and pervasive information sharing, Notes and Domino are the solution.
Why does the repository need to be public? In an era of very powerful client machines, why must we have a centralized database to make this work? Systems like Napster and Gnutella have already demonstrated the ability of end-user machines to distribute data effectively (though not always efficiently.)
I belive the safest route would be to avoid the publicly accessible, centralized data store and focus on what has worked so well for the Internet in the past: standard communications protocols. By leaving the data on individual systems, we minimize the risk of exposing vast quantities of personal information as an attacker would need to go after millions of machines in turn. It's possible, but it wouldn't be easy.
I see a number of postings here to the effect that voice recognition, especially for dictation, will be largely useless. The problem is that these postings are considering the use of voice recognition as a replacement for typing within the current crop of user interfaces.
The true power of voice recognition is not in replacing the keyboard. It comes with allowing new forms of interaction with a computer. Consider the simple task of checking the weather. Pulling up a browser and heading to weather.com is no big task, but why would I want to sit at my computer and have to do that just so I can decide how heavy a sweater I'll need for the day? Why not just ask the computer to read me the forecast while I'm getting dressed?
Many people would assume in this scenario that one would call out: "Computer, browse to h t t p colon slash slash w w w dot weather dot com. Read page." How about simply calling a script intead that does all the hard work behind the scenes? "Computer, what is the weather forecast for today?" The use of predefined grammars, as the article describes, will make such queries very reliable as they will be much easier to recognize.
This may have been a simple example, but hopefully it gets the point across. Voice recognition is not going to replace typing. As many have said, some people can type much faster than they can dictate text. Once you start considering higher level interaction with the computer, however, the situation changes, and voice recognition systems will really show their colors.
-kris
This is a comprehensive survey of just about every programming language under the sun. It covers some of their history as well as the syntax and sematics of the languages themselves. It should prove to be a useful starting point for intensive research on language topics.
Althought the algorithm used in the above two programs is the same, the specific semantics are different. In the Python program above, you are using global variables. The C implementation of Python is notoriously slow in looking up global variables. In addition, the range() function allocates an array of values, as other posters have pointed out.
I wrote a version of your program which uses xrange() and saw a significant performance increase:
#!/usr/local/bin/python
endp = 10000;
totl = 0
for i in xrange(2,endp):
for j in xrange(2,i):
if i%j == 0:
break
else:
totl = totl + 1
print totl, 'prime numbers between 1 and', endp
Your original script on my machine produced the following (yes, I'm running on W2K; I'm at work. *sigh*):
[//c/Projects/Scripts] time python primes_orig.py
1229 prime numbers between 1 and 10000
real 0m10.215s
user 0m0.010s
sys 0m0.040s
The new script above produced:
[//c/Projects/Scripts] time python primes_xrange.py
1229 prime numbers between 1 and 10000
real 0m6.980s
user 0m0.010s
sys 0m0.000s
I was further able to shave another 1.4s off that time by moving everything into a function:
#!/usr/local/bin/python
def getprimes(endp):
totl = 0
for i in xrange(2,endp):
for j in xrange(2,i):
if i%j == 0:
break
else:
totl = totl + 1
return totl
max = 10000
print getprimes(max), 'prime numbers between 1 and', max
This resulted in:
[//c/Projects/Scripts] time python primes_new.py
1229 prime numbers between 1 and 10000
real 0m5.578s
user 0m0.010s
sys 0m0.000s
I'm sure that the real Python gurus can do a whole lot better. You can always post to comp.lang.python and get some truly outstanding help there. It's one of the few remaining civil newsgroups left on Usenet (in my opinion, of course).
Keep in mind, though, that benchmarks like these don't tell you the whole story. For one thing, consider how much more a developer's time will cost you compared to the extra processing time. A good Python programmer will, in many cases, crank out a program in a fraction of the time that a good C programmer will take. This will vary from programmer to programmer, of course, but I have found that to hold true in my particular case.
-kjz
I have done a fair amount of commercial Windows development and can say that there are a number of advantages to working in a Unix environment, if not specifically Linux.
:-)
The one advantage that stands out the most in my mind is the kill command. I have fought Windows NT countless times trying to get it to kill an errant process. I gave up completely under Windows 95/98, just rebooting the machine when needed. I have NEVER had to do something like this in a Unix environment. Even when I have faced a stubbornly hung Lotus Domino server (which leaves resources open all over the place), I could still force it to shut down and be removed from memory so I could restart it. No reboots necessary. This little trick alone has probably saved me hundreds of hours of grief waiting for a machine to reboot just so I can continue development. There is no doubt in my mind that I am therefore far more productive developing in a Unix environment when compared to Windows.
Now, my preference of Linux over other Unix systems... well, that's another post.
Some state governments, particularly Massachusetts, are making an effort to bring more and more transactions online. For example, take a look at the Registry of Motor Vehicles home page. You can change registration information, get replacement licenses issued, and even pay your tickets online. And let's not forget that many states, and even Uncle Sam himself, are allowing people to file and pay their taxes electronically.
One thing I have learned about user interfaces is that the audience they target matters. Determining who that audience is (the real 'users' of the system) is absolutely critical to assembling a good interface. The requirements for a novice user will be very different than those of an advanced user or developer.
;-)
If you are targeting novice users, simplicity is key. Guide the user through tasks, and provide plenty of visual cues for what needs to be done next. Consider using text as well as graphics to label items such as toolbar buttons so the user doesn't have to go on a fishing expedition to find a piece of functionality.
For more advanced users, speed of use becomes more important. Provide shortcuts to certain operations, including special keyboard and keyboard-mouse combinations. Once more advanced users learn the shortcuts for frequently used features, they will (hopefully) be more productive. Options that would be hidden or eliminated for novices can be exposed and presented in plain dialog boxes instead of "wizards".
As for interfaces for developers, just take your best shot. Provide power and flexibility. Beyond that, we're just too damned picky to be kept happy.
The most difficult task is creating an interface that satisfies all of the above groups. Many have tried to build interfaces that can gradually expose functionality, with limited success. In my very humble opinion, no one has yet to fully address all the needs of these various audiences in an application. In my work, I tend to avoid this challenge and simply address a given audience specifically. Developers get powerful and flexible (though maybe overwhelming) UIs, while the "suits" get the wizards and simple UIs.
In my travails through Usenet and other discussion boards, I have found one common thread underlying most of the flames I have come across: a simple lack of communication skills.
Let me first say that I am not a psychologist or sociologist. My statements here are purely my opinion based on personal observation. They are in no way authoritative statements on the matter.
That said, I often find that many who partake in online flaming demonstrate a similar trait to those people I encounter in real life who use profanity. They all lack the ability to compose and communicate their ideas effectively. Online, many discussions degenerate into base name-calling and personal attacks. This downward spiral into flaming seems to begin at a point of frustration for one of the parties involved in the conversation. That is the point in which the poster cannot effectively either compose an argument, or clearly express an otherwise valid argument. This leads to either the use of strong language from sheer frustration, or the selection of inappropriate or inaccurate phrases to express and idea. Once the message is posted, the resulting misinterpretation of the message causes the receiver to go on the defensive. Once that happens, I have found that there is little hope in salvaging the thread of conversation.
I see the same sort of frustration and reaction in face-to-face encounters as well. Many people simply do not have the ability to express themselves adequately, instead choosing to use a string of explitives and other vulgar phrases. Clearly, this continually fails to get the intended ideas across. Many loud arguments, if not outright altercations, result from the frustration and misunderstandings that result.
What is the cause of this? I really can't say. I could easily blame the education systems or point to other societal factors. However, I have never seen any convincing evidence pointing to any one causal factor. Because I do not know the source of the problem, I treat the symptoms as I can. Among my friends and acquaitances, I try to put myself in the position of arbitrator, in the hopes of clarifying ideas between the people involved. I try to explicitly state assumed or implied ideas to avoid misinterpretations. Finally, I try to propose compromises and avenues for further civil discussions.
Can anyone suggest other means for resolving these problems?
The issue with supporting Domino R5 on different Linux distributions comes largely from two points:
/opt/lotus, as do the other Unix variants. However, with the diverse universe of Linux distributions that exist today, it would be impractical for Lotus to assume responsibility for software/platform combinations that they have not tested.
:-)
1. Different distributions use different libc/glibc versions. Domino was written to use the latest production glibc, thus the support of Red Hat 6.0 and OpenLinux.
2. The QA effort to validate a Domino installation across all the major Linux distributions is immense. Even with automated test suites, the amount of person-hours spent on thoroughly testing a Domino release on one platform (and different OS releases/distributions are considered separate platforms) becomes a prohibitive obstacle to testing all of them.
Domino itself does or uses nothing that is distribution-specific. It installs itself completely under
Now, if you want to complain about the fact that they aren't porting the clients, I'll complain right along with you.
What happened at Jane's really amazes me. It shouldn't, but the rarity of seeing a publication actually listen to feedback before publishing an article makes it so. I am very tired of the reporting I see in the media today. I almost never watch television news, and only selectively read the newspaper (usually online). I am constantly disappointed by the poor research and significant biases I see in what should be unbiased, factual articles.
I have to wonder whether the root of the problem is simply laziness. One could argue that the media has become an intensely competetive environment where more and more publications (and shows) are fighting for a fixed number of eyeballs. As a result, journalists have to scramble to produce their pieces as quickly as possible. One could also argue that the world is becoming increasingly complex and that those same journalists just can't keep up.
I would argue that a culture of laziness has instead grown within the media industry. In that light, the former arguments are simply obstacles to be surmounted like any other. Tight deadlines are no excuse for shoddy or inaccurate reporting. Likewise the complexity of the issues involved are no excuse for a lack of any research. There are experts in all fields, experts that can be contacted to clarify and comment on the actual issues.
Journalists are not omniscient, nor are they infinitely quick at the keyboard. Their job is not to be either. Instead, their job is to gather information from others in the know and to present a balanced, factually based account of the matter at hand.
So, will the laziness ever end?
What really amazes me is how quickly and vehemently many people reacted when this story first appeared. Instead of waiting to hear all sides of the issue, many people automatically assumed the worst.
/. and elsewhere) fearing or predicting that Red Hat would begin to walk the same path that Microsoft has. Many believe that somehow Red Hat would hijack Linux and pervert it for their own purposes. They somehow equate the high visibility that Red Hat has obtained with the tendency or desire to make money at all costs, including screwing the consumers and end users.
It seems to me that there is a very prominent fear in the Linux community of any attempt to commercialize Linux. I have seen countless comments over the last few months (here on
When I first read the hubbub surrounding the Amazon.com letter, I didn't jump to conclusions. I knew that Red Hat has maintained an excellent reputation for being open and fair, and preventing all uses of the Red Hat moniker outside of officially sanctioned products didn't seem to fit with that reputation. Red Hat is not a company to fear. Not only are they unable to hijack Linux (thanks to the GPL and other licenses), it would be a very bad business decision. They would lose the trust and support of the very developers and community they rely on in order to provide their product.
Red Hat has done a great job of being open and honest with us in the past. They really do deserve the benefit of the doubt when situations like this arise. I can only hope that those who have risen up against Red Hat in the past will take this into consideration before vilifying them in the future.
Ah, yes. I remember Galaxy rather fondly. At my last job, I was tasked with evaluating a variety of GUI frameworks and toolkits for X11 development across Sun and SGI boxes. I looked at Zapp, Zinc, plain Motif (which the last version of the app had used), and a few free software frameworks which I don't recall at the moment. Galaxy stood heads and shoulders above all the competition.
I was particularly fond of the spring and struts mechanism for putting together dynamically sizeable windows. The layout mechanism allowed you to specify fairly arbitrary constraints on any widget that got placed in a window or other component. I consider it an even better system than the fabulous layout managers we see in Java's AWT or Swing toolkits.
The GUI designer was a wonder to work with as well. I managed to prototype our entire user interface in what seemed like no time at all. We were then able to take some screen shots, clean them up in Photoshop, and drop them straight into our design documents. Our clients loved it. The docs looked great, described the interface far better than prose alone could have, and we hadn't even written a single line of code!
I see a great deal of potential along these lines with Glade (and libGlade). Storing the interface definition as an XML file is a fabulous idea. This gives you far more flexibility than Galaxy ever did, especially if you need to programmatically alter your interface, or perhaps translate it for internationalization purposes.
Now if only we can get springs and struts into GTK+...
Design documents and formal processes have both good points and bad.
Sometimes the documentation and rigorous peer-review proves
invaluable. Other times, it simply gets in the way of achieving the
primary goal, that is, to solve a problem with the computer.
Now, I currently work at a large software development company and have
seen quite a number of developers come and go. This is one case in
which documentation of the design is invaluable. Keeping up-to-date
design documents allows new developers--and even QA staff--to come up
to speed quickly. It flattens the learning curve and allows them to
begin contributing to the project much sooner than if they had to
fight for another developer's time or dig through mountains of source
code.
The peer review process helps here as well when the developers coming
on board are fairly green. There are many mistakes that developers
make (and yes, we all made them at some point) which can be
easily caught and rectified with a thorough peer-review and follow-up
instruction.
That said, I have to admit that religious adherence to such processes
does tend to get in the way of producing a product. At my previous
employer, I worked on a government contract where we had to deliver a
formal requirements analysis, design documentation, and subsequent
detailed code reference. Due to the constantly expanding scope of the
project (When does this ever not happen?), the documentation
was never quite up-to-date and was useless to the development staff.
We had our heads in the code and relied on reading the code and
associated comments to figure out what was really going on. The
documentation we generated in the end would definitely prove useful to
later developers who would maintain the code, but for those working on
the first version, it was seen as time wasted.
At my current job, I see the problems that come from constantly
changing requirements. No matter how much we try to plan ahead and
generate design documentation for a new product feature, we inevitably
get caught up in the implementation and the documentation suffers.
With constantly impending deadlines and never enough resources, it
becomes a struggle to keep design documentation up to date. More
often than not, new developers and QA staff end up hunting down the
person responsible for developing a feature in order to find the
answers to questions. Most of the design documents we do have are
horribly out of date or don't have enough detail to answer the
questions at hand. Ultimately, developers still dive into the code to
figure out what is going on.
There are pros and cons to rigorous engineering practices. What I
have learned is that you must find a balance between free-form
creating and hacking and disciplined engineering practices. Where
that balance point lies depends greatly on the people involved as much
as the project itself. Take a good long look at your developers and
how they have reacted to processes in the past. Take a look at the
software you need to develop and figure out how rigorous you need to
be in developing it. Look at your schedule and see how flexible you
need to be to get things done. Pick a point somewhere in the middle
and give it a shot.
I fear you may be in the minority here. Although I avoid it, many people simply add one person or another to a filter and never look back. Though sometimes necessary, this is short-sighted and very closed-minded behavior.
My reading of Katz's article and postings (and I reserve the right to be wrong) is that he is in no way taking issue with the simple existence of these filters. In fact, he acknowleges that the choice to listen must exist. What he is trying to point out is what the consequences of not listening may be. It is indeed a frightening though that the Internet may some day be seen only through rose-colored glasses that eliminate anything offensive or contrarian from view. Criticism and disagreement are the foundation of intelligent discussion. They prevent stagnation of thought. They force us to analyze our assumptions and further investigate the world we live in. Without the challenge, without the disagreement, how will we learn? How will we grow as intelligent creatures?
Overuse of filtering software puts those thick, rose-colored glasses on us. They restrict our vision and, as a result, our thought. This is too heavy a burden to wear, and one which I choose to never carry.