I've come up with countless solutions in the shower as well. However, it usually happens in the morning and I start to think/analyze the problems from the day before. I also ascribe to the "white noise" theory of the shower. It blocks all other outside factors, you're relaxed and you can concentrate more deeply.
I've also woken up in the middle of the night with the solution right there in my mind.
Others, noted that some people can sleep with a lot of external "noise" and yet still sleep and awake only when needed. I think most people do this and it's really just what you are accustomed too. e.g. You're asleep and your girlfriend comes in late, walks around etc. (hypothecital I know...but try to follow). Even though you're sleeping, you still process all the sounds. Subconsciously you recognize it as a familiar sound and you remain sleeping. Now, the next night, someone is in your house but you don't recognize the sound and you immediately awake.
The same is true when I used to live in L.A. and friends would come and visit. They couldn't sleep with all the traffic and noise. I slept like a baby as I recognized those sounds as normal, everyday activity. The reverse was also true. I had a difficult time sleeping in the country. The quiet (or those damn frogs) was deafening. Where was the traffic, the horns, sirens! I needed some sleep dammit!
It's also worth noting that the linked article is on a Christian website. Of course they're going to attempt to tear apart all of the assertions in Dan Brown's book and defend their faith. They're biased.
That's not to say the article is right, wrong or somewhere in between, but read it with a very large grain of salt.
It's also worth noting that the linked article is on a Catholic website. Of course they're going to attempt to tear apart all of the assertions in Dan Brown's book and defend their faith. They're biased.
That's not to say the article is right, wrong or somewhere in between, but read it with a very large grain of salt.
Rand McNally by far is my favorite mapping site. Yahoo has given me very confusing directions. Mappoint is Microsoft and doesn't work with Mozilla.
I once did a test with 4 or 5 major mapping sites seeing how close they would get to the route I take for a rather long drive. Rand McNally was the _only_ site to offer the exact same directions I regularly take. All the others had me going down the obscure back roads or out of my way to take other highways.
I have never yet been steered wrong by Rand McNally, yet...
A Fish Called Wanda: John Cleese, Kevin Kline, Michael Palin and Jamie Lee Curtis are hilarious in this jewel heist film. I've watched it countless times.
"I'm DISAPOINTED!":-)
Time Bandits: Another film with John Cleese and Michael Palin. Time travelling bandits stole a map from the "Supreme Being" and are travelling time looking for loot to steal. Unfortunately "Evil" is watching them and looking to get the map.
---
Evil: If I were creating the world I wouldn't mess about with butterflies and daffodils. I would have started with lasers, eight o'clock, Day One!
[zaps one of his minions accidentally, minion screams]
Evil: Sorry.
---
Supreme Being: I am the Supreme Being, I'm not entirely dim.
---
Evil: Oh Benson, dear Benson, you are so mercifully free of the ravages of intelligence.
---
Supreme Being: I'm going to transfer you to the undergrowth department... bracken, small shrubs... with a nineteen percent cut in salary, backdated to the beginning of time.
Randall: Oh, thank you, Sir.
Supreme Being: Yes, well, I am the nice one.
---
Supreme Being: They'll think I've lost control again and leave it all to evolution.
---
Evil: God isn't interested in technology. He cares nothing for the microchip or the silicon revolution. Look how he spends his time, forty-three species of parrots! Nipples for men!
Robert: Slugs.
Evil: Slugs! HE created slugs! They can't hear. They can't speak. They can't operate machinery. Are we not in the hands of a lunatic?!
From the directors of Airplane! Everytime I watch this movie I see new things. There is so much going on in the background you can't catch it all in one or two viewings.
Nick Rivers: Listen to me Hillary. I'm not the first guy who fell in love with a woman that he met at a restaurant who turned out to be the daughter of a kidnapped scientist only to lose her to her childhood lover who she last saw on a deserted island who then turned out fifteen years later to be the leader of the French underground.
Hillary Flammond: I know. It all sounds like some bad movie.
[Long pause. Both look at camera.]
---
[Hillary and Nick attempting to meet with the French Underground meet their contact and must 'authenticate' with the phrase/counter-phrase]
Hillary Flammond: Who do you favor in the Virginia Slims tournament?
Blindman: In women's tennis, I always root against the heterosexual.
---
[Martin apparently trying to get a stay of execution for Nick being held in the German prison...]
Martin: Nick, I've tried everything: the embassy, the German government, the consulate. I even talked to the U.N. ambassador. It's no use, I just can't bring my wife to orgasm.
First, they put it on a public web server. That's like putting a product in a store for everyone to see, and purchase if they choose.
Second, this is very much like when a product is supposed to go on sale on, say, Saturday, but the employees, because they don't want to come in early on Saturday to set up the display, decide to set up the display on Friday evening. But a customer comes in just before closing, sees the new product and asks to buy it. In this case, an employee can say, no, it goes on sale tomorrow, but a web server is automated and it'll give you anything you want if it's there.
Someone made a mistake in putting it on the public server. Just because their intent was to keep it private, doesn't make it so when they make it available on a publicly accessible server.
So far, my experience with using Mozilla (both 1.0 and 1.1) with People's Bank has been great except for one problem which turned out to be on my side.
I ran into a problem with the People's Bank site not displaying correctly using Mozilla 1.1. I contacted support (since the site worked fine previously) and their official answer was that they didn't support Mozilla, though they are looking into it.
It turns out that the problem was that I enabled HTTP Pipelining and their servers didn't support it. I turned it off and their site worked fine again. I contacted support and let them know.
It would be nice if Mozilla allowed you to turn on HTTP Pipelining per site (e.g. a checkbox in the bookmark's properties) rather than global.
The purpose of agents in the FBI are for law enforcement purposes, specifically, the enformcement of federal laws. All agents need to be able to handle, or contribute to, any type of criminal case, not just the one they have a specialty in. Just becasue you are a computer expert doesn't mean you won't be working a kidnapping or bank robbery. You have to be able to meet the standards that any other agent meets. Plain and simple. This is especially true for major events like the federal building bombing in Oklahoma and the 9/11 investigations. During these times most agents were retasked to assist in these investigations. It's not like you are going to refuse because "I don't do bombings, I do computer fraud." You're not a team player with an attitude like that and the FBI and other federal agencies don't need people like that.
Also, I've been reading about the compensation comments here. Yes, we'd all like to make more money, but money is not the reason you join a group like the FBI. I can't think of one specialty in the FBI that wouldn't pay more on the outside world. There are many reasons people join the FBI (other other agencies): * Patriotism * The opportunity to work with 'the best'. * The opportunity to do things that only working at the federal level will allow you (protecting the President (USSS), protecting Air Force One around the world(USAF SP), developing unique CPUs (NSA), seeing what's really involved with regard to world events (NSA, CIA, State Department), etc.) * Love of a particular field (e.g. law enforcement) * The best training in the world in your field.
Besides, people with backgrounds in the FBI will be able to make very good money once they leave/retire.
Not true.
Many people incorrectly refer to the sniffing of electromagnetic signals as 'TEMPEST attacks'. While it is certainly convenient to use this term, TEMPEST actually deals with the prevention of such signals, not the gathering of them.
As for only reading monitors, you are quite mistaken. TEMPEST covers the entire electromagnetic spectrum. If you've ever seen TEMPEST equipment, everything is 'shielded', not just the monitor. Electromagnetic sniffing can be applied to any electronic device, not just computers. Monitors are probably the easiest for people to think of because it's information they're seeing. But sniffing the monitor does you no good for gather passwords, because they either don't show up on the screen or are some other character. But sniffing the keyboard will certainly give you this info.
Does this person even know what they are talking about?
First off, the speed of sound is roughly 760 Mi/Hr at sea level, but it depends entirely on the density of the medium the sound is travelling in. At altitude, where aircraft perform best, the speed of sound is roughly 640 mi/hr (again, depending on density).
Production jet powered aircraft have been travelling faster than Mach 2.1 since the 60's. Aircraft, off the top of my head, that travel faster than this are:SR-71, F-14, 15, MiG-23, 25, 29, 31, Su-27, 30, Mirage III, and Panavia Tornado. And that's just the unclassified stuff.
This is not true. All Athlon/Duron motherboards use a 100MHz DDR FSB and a 133MHz memory bus (not including the AMD 760 DDR RAM chipset). The P4, BTW, uses a QDR(Quad data rate) memory bus, but still only uses a 100MHz data rate FSB. With all this terminoligy and the marketing spin doctors at these companies, it's easy to get confused.
What does a 100MHz DDR FSB mean? It means that the CPU talks to the chipset at a 200MHz data rate even though the frequency is only 100MHz because it can send two bits of information per clock cycle instead of one.
Let's compare Duron/Athlon vs. Celeron/P4:
FSB MHz: All use 100MHz
FSB throughput: Duron/Athlon: 200MHz, Celeron/P4: 100MHz
Memory Bus MHz: Duron/Athlon: 133MHz, Celeron/P4: 100MHz
Memory Bus throughput: Duron/Athlon: 133MHz, Duron/Athlon(DDR): 266MHz, P4(Rambus): 400MHz, Celeron: 100MHz
OK, so not only does Duron as a chip spank Celeron (especially for the price), we see that a Celeron system is severely lacking compared to a Duron system.
I'm not a hardware guy, so if I'm wrong on any of this, I'm sure it will be corrected in a polite and professional manner:-)
Agreed. Civilization and Civ 2 were the most addicting games I've ever played. Hell, I still play Civ 2...and Civ 2 Multi-player came along and you got to play against real people. That was the pinnacle. I would spend entire days playing. I just need to capture this one city...then I'll stop...yeah, right.
Lemmings is also another fond memory from days gone by. Getting all of those little bastards to the exit was damn frustrating at times....to the point of just maxing out the release rate and then just nuking them:-) But you just couldn't stop.
And finally, I was a HUGE AD&D player back in the early to mid 80's. The moment I played Ultima III back on my Atari 800XL, I was hooked on the Ultima series. I would play until I couldn't stay awake anymore. While the most recent Ultima's were nice, there was something to the more simple graphics that almost made it more enjoyable. I think my favorite was Ultima IV (VI was a close second). They all had fabulous theme music and the stories were engrossing. Sometimes too much flash takes away from the real experience.
Am I advocating using a debugger to track down eveyr single bug? Of course not. But it's unproductive to track down a bug by continually adding printf's everywhere, recompiling, and cluttering the code. There is nothing that printf can do for me that a debugger can't.
Just because someone is using a debugger doesn't mean they don't know what's going on. On the contrary, I would argue that anybody continuously adding printf's everywhere really doesn't know what's going on because they're shooting in the dark hoping for the miracle output that will point them to the error in their code.
Using a debugger requires that you know your code fairly well, although it can also help you learn code you haven't seen before. If you don't know how your code works, how are you going to know where to set your breakpoints and watches appropriately?
Using a debugger to track down a problem should only take a few minutes. Anybody spending hours just isn't using the tool properly. Debugging takes skill and experience. I know newbies who get into the debugger and step through everything. That's nuts and a waste of time. Learn to use the tool. It'll give you much more insight into how your code works and how it interacts with other libraries.
My typical debugging sessions goes like this:
Something incorrect happens in the program.
I look at my diagnostic output. Usually the culprit is pretty obious and I fix it.
If it's not, I take a look at the code itself to see if I missed something. If I notice a problem in the code, I fix it.
If it's not obvious, I fire up the debugger and set appropriate breakpoints and/or watches based on my knowledge of the problem and the code. Usually I'll see the problem on the first pass and I fix the code within minutes.
Enough of the doctor analogies:-) Let's try this one: The problem is like a game of battleship. Printf's are just like the game: hit or miss. If you hit, great, you fix the problem. But you can easily keep missing, wasting lots of time. Using the debugger is like using radar to find the ship. You find it nearly everytime. But, if you don't know how to use the radar, you might as well not use it at all.
Debuggers aren't a a crutch. They are a tool to use...and a productive one at that. You are correct in your statement "The wise programmer uses the right too for the right job." Usually it's a combination of tools.
This is the type of comment I hear from novice and inexperienced developers. Most new hires right out of college seem to have this fear of debuggers and their debugging skills consist of printf's everywhere.
Now don't get me wrong, printf's or some other diagnostic output (such as logging) is very handy to hopefully gain a handle on what is going on, but it's not the solution you want to use if after looking at the output you still have no clue what's happening.
Debuggers (both command line and GUI) are all essentially the same. Learning one isn't doesn't take very long (on the order of a few minutes) to do the basic things like set breakpoints, step, and watch variables.
Here are the problems with printf (and other diagnostic output):
They don't give you the whole picture and very rarely point you to the exact location of your problem.
They have to be maintained. I don't know how many times people have cut & pasted a printf but failed to change its output causing utter confusion. Or the code changes and the printf didn't. They can become a maintenance headache which can actually hinder the troubleshooting process. The should be controlled somehow (preprocessor..some logging level varible etc.) but getting everyone to do that everywhere consistently is also a problem.
They can be misleading especially if the output has not been flushed yet.
They can get in the way of the actual running of the program and mask bugs (especially race conditions).
They can't tell you when a pointer or variable gets stomped on.
Debuggers on the other hand let you see your entire application state and you can see in an instant if everything is right.
If the program crashes you immediately see what went wrong and you can view the call stack to see how it got there.
You can easily debug multi-threaded programs because you can force potential race conditions and see if your code works properly or not.
You can dynamically alter the flow of your program yourself and force potential problems to check your code behaves properly. Using a debugger is a great way of testing all conditions a piece of code might face: valid input, edge conditions, and invalid input.
'Debugging' with printf is an iterative and lengthy process of looking at the output, adding more printf's (adding to the maintenance problem), compiling, and looking at the output again. With a debugger, I almost always find the problem on the first or second pass through. You also invariably find other potential problems lurking in the code that just haven't shown up yet. Tracking down a problem with a debugger usually takes me just a few minutes, but going through the printf process takes much longer and may never show you the real problem.
Think of it this way: You go to a doctor saying you dont' feel well. The printf doctor pokes and prods you until you yell 'ow!'. The debugging doctor uses the intelligent approach where he looks at your symptoms, runs some tests and makes a much more accurate diagnosis of your problem.
I don't think the corporation "used" her or any other temp. They hired outside people through the contracting agency. That's what the agency's business is: to market their product, in this case people. Just because they are called 'temps' doesn't mean that the job is a temporary one. It could be for a few weeks or several years. The point is, the company is using a tool at their disposal. If a 'temp' decides they want to work at the company then they should apply. It's their choice. They aren't getting deprived because they are a temp. It was their choice and they are getting paid by their company - the contracting firm. That's their job. If they have a problem with it, leave like anybody else would leave a 'standard' employee position and seek your fortunes elsewhere.
You mention the conditions us poor, educated, in demand, IT people work in. In some cases it's true and a lot of time the extra hours are unnecessarily forced on us by management to make deadlines some clueless marketing person agreed to. But again, that's the job. Software development and IT is full of unexpected pitfalls (what software does 100% it is documented to do...hell for that matter 90%). But it's not just IT people whose job demand unpaid overtime or that little bit extra. Practically every other job demands this at some point or another. I don't necessarily feel sad for IT people and the 'horrendous' stress they are put under. Try switching places with a cop or fisherman sometime!
It's the career we've chosen and it's up to us to decide when we've had enough either with our current employer or our career. We're all adults and are responsible for our own lives.
IMHO, this is entirely the temp worker's fault. They already work for a company...their contracting firm. They get paid and have benefits thorugh them. Why should they expect any benefits from their client? If they wanted MS to give them benefits, then they should have joing MS instead of their contracting co. Seems to me they want to double dip. Is that any different then a company hiring a large outsourcing company like IBM to do long term work for them? Imagine the IBMers working at this other company demanding that their client give them the same benefits as its employees.
Unfortunately, this decision is bad for the contractors. My sister was a temp for GE and was hired a few months before this case went to court. As a result of this case GE changed their temp policy and after one year, they just let her go out of fear she would sue them for benefits. It's ridiculous.
The temp's that brought this case against MS were just greedy opportunists. I have no sympathy whatsoever for them.
An incremental compiler/linker is one that compiles and links only the changes since the previous build, greating reducing the compile/link time for building programs.
Think of incremental compiling like incremental backups. You do your initial backup which takes the longest. Then you do incremental backups, backing up only the data that has changed since the last backup.
Incremental compiling/linking is similar. You do your initial build, then as you subsequent builds, the compiler only compiles the changes and links the changes, greatly reducing build times.
This white paper has a more detailed description of this technology.
- Rick Alther
Re:Ummmm, correct me if I'm wrong...
on
Is X The Future?
·
· Score: 1
Yes, you are correct. X itself is not a GUI, but merely defines a protocol for applications (clients) to talk to Servers (X Window Managers). It also provides graphical primitives which are display independent.
Most people responding to this article obviously do not know what they are talking about because the keep discussing how the Linux desktop should look. How the desktop looks it totally separated from X itself. Window managers, the libraries apps are linked with and shells define what a particular GUI looks like, not X.
Re:No X -- we need a media-savvy, compositing GUI
on
Is X The Future?
·
· Score: 1
I work on OS/2, WinNT, and Linux and I have X servers for ALL of them. I have to tell you, it is very convienient to run a program on my Linux box and have it show up on my OS/2 system or WinNT system....or at home...or in another state to show a customer....or....
The article is not about how displays look because X does not describe the graphics themselves, but instead defines a protocol for applications (clients) to talk to X Servers. X Window Managers manage the graphics displays. I think people are getting hung up on the 'looks' of a GUI which is totally dependent upon the X Window Manager and the underlying libraries the specific application was linked with.
X is probably the best protocol for a distributed windowing environment. It is certainly the most flexible. Sure, improvements can still be made, but X is a great concept and a stable piece of software using open standards. Name another piece of software that is as flexible, useful and solid.
Has anybody noticed a recent trend in CS graduates lately? When I graduated (almost 4 years ago) most CS students were in that degree program because they truly enjoyed programming, solving problems, and all-round hacking. However, lately I've been seeing CS graduates without that inquisitive nature. A lot of students seem to be taking up the degree now because it is now a more mainstream job and there's 'lot's of money in it' to quote one student that I interviewed. There are still the 'hacker' types who simply love it, but there are more and more 'non-tech' people graduating. I see them all the time.
Also, it seems that students are emphasizing more and more on 'high level' topics and have very little concept and understanding of the lower level stuff. e.g. We're seeing more Java coders and, I love this, 'HTML programmers'. That's great that they are interested in these areas, but we're loosing a vast technical base of people that really understand what's going on under the covers. Very few people know assembler (not that it's used a whole hell of a lot, but if you understand assembler, you can track down compiler problems, JVM problems, etc. and you simply know how things work rather than guess at them.) Very few people can use a debugger proficiently and even more use the debugger as a last resort debugging tool. They would rather litter the code with output statements first because, as one new employee put it 'the debugger is a pain to use.' Hmmmmm. Has anybody else noticed this trend? Sorry for the wind.
With your basic Java applet, you can't accomplish it unless there is a bug in the JVM or someone discovers a hole in the security model.
However, you can write a trusted Java applet that has full reign just like a regular program, so it CAN be done with a Java applet in combination with native code.
Whether someone may acutally get your PIII ID may or may not be a big deal, it's things like this that lead toward a slippery slope of things to come. What's the next 'minor' invasion of privacy that we'll 'accept' because it's no big deal? I can just see it now: A leagally purchased program records the PIII ID and checks the ID every time it is run. But due to oversight on the programmer's part I upgrade my chip to a faster version and, whoops, the program won't run because it thinks it's on another machine....and this is a simple example.
Slashdot Mirror
I've come up with countless solutions in the shower as well. However, it usually happens in the morning and I start to think/analyze the problems from the day before. I also ascribe to the "white noise" theory of the shower. It blocks all other outside factors, you're relaxed and you can concentrate more deeply.
I've also woken up in the middle of the night with the solution right there in my mind.
Others, noted that some people can sleep with a lot of external "noise" and yet still sleep and awake only when needed. I think most people do this and it's really just what you are accustomed too. e.g. You're asleep and your girlfriend comes in late, walks around etc. (hypothecital I know...but try to follow). Even though you're sleeping, you still process all the sounds. Subconsciously you recognize it as a familiar sound and you remain sleeping. Now, the next night, someone is in your house but you don't recognize the sound and you immediately awake.
The same is true when I used to live in L.A. and friends would come and visit. They couldn't sleep with all the traffic and noise. I slept like a baby as I recognized those sounds as normal, everyday activity. The reverse was also true. I had a difficult time sleeping in the country. The quiet (or those damn frogs) was deafening. Where was the traffic, the horns, sirens! I needed some sleep dammit!
"The New Testament is the most accurate ancient work, ever."
Yeah, and Microsoft makes the world's most secure operating system...because THEY say so.
It's also worth noting that the linked article is on a Christian website. Of course they're going to attempt to tear apart all of the assertions in Dan Brown's book and defend their faith. They're biased.
That's not to say the article is right, wrong or somewhere in between, but read it with a very large grain of salt.
It's also worth noting that the linked article is on a Catholic website. Of course they're going to attempt to tear apart all of the assertions in Dan Brown's book and defend their faith. They're biased. That's not to say the article is right, wrong or somewhere in between, but read it with a very large grain of salt.
Rand McNally by far is my favorite mapping site. Yahoo has given me very confusing directions. Mappoint is Microsoft and doesn't work with Mozilla. I once did a test with 4 or 5 major mapping sites seeing how close they would get to the route I take for a rather long drive. Rand McNally was the _only_ site to offer the exact same directions I regularly take. All the others had me going down the obscure back roads or out of my way to take other highways. I have never yet been steered wrong by Rand McNally, yet...
A Fish Called Wanda: John Cleese, Kevin Kline, Michael Palin and Jamie Lee Curtis are hilarious in this jewel heist film. I've watched it countless times.
:-)
... bracken, small shrubs ... with a nineteen percent cut in salary, backdated to the beginning of time.
"I'm DISAPOINTED!"
Time Bandits: Another film with John Cleese and Michael Palin. Time travelling bandits stole a map from the "Supreme Being" and are travelling time looking for loot to steal. Unfortunately "Evil" is watching them and looking to get the map.
---
Evil: If I were creating the world I wouldn't mess about with butterflies and daffodils. I would have started with lasers, eight o'clock, Day One!
[zaps one of his minions accidentally, minion screams]
Evil: Sorry.
---
Supreme Being: I am the Supreme Being, I'm not entirely dim.
---
Evil: Oh Benson, dear Benson, you are so mercifully free of the ravages of intelligence.
---
Supreme Being: I'm going to transfer you to the undergrowth department
Randall: Oh, thank you, Sir.
Supreme Being: Yes, well, I am the nice one.
---
Supreme Being: They'll think I've lost control again and leave it all to evolution.
---
Evil: God isn't interested in technology. He cares nothing for the microchip or the silicon revolution. Look how he spends his time, forty-three species of parrots! Nipples for men!
Robert: Slugs.
Evil: Slugs! HE created slugs! They can't hear. They can't speak. They can't operate machinery. Are we not in the hands of a lunatic?!
One of my favorite comedies of all time!
:-)
From the directors of Airplane! Everytime I watch this movie I see new things. There is so much going on in the background you can't catch it all in one or two viewings.
Nick Rivers: Listen to me Hillary. I'm not the first guy who fell in love with a woman that he met at a restaurant who turned out to be the daughter of a kidnapped scientist only to lose her to her childhood lover who she last saw on a deserted island who then turned out fifteen years later to be the leader of the French underground.
Hillary Flammond: I know. It all sounds like some bad movie. [Long pause. Both look at camera.]
---
[Hillary and Nick attempting to meet with the French Underground meet their contact and must 'authenticate' with the phrase/counter-phrase]
Hillary Flammond: Who do you favor in the Virginia Slims tournament?
Blindman: In women's tennis, I always root against the heterosexual.
---
[Martin apparently trying to get a stay of execution for Nick being held in the German prison...]
Martin: Nick, I've tried everything: the embassy, the German government, the consulate. I even talked to the U.N. ambassador. It's no use, I just can't bring my wife to orgasm.
---
And many more
First, they put it on a public web server. That's like putting a product in a store for everyone to see, and purchase if they choose.
Second, this is very much like when a product is supposed to go on sale on, say, Saturday, but the employees, because they don't want to come in early on Saturday to set up the display, decide to set up the display on Friday evening. But a customer comes in just before closing, sees the new product and asks to buy it. In this case, an employee can say, no, it goes on sale tomorrow, but a web server is automated and it'll give you anything you want if it's there.
Someone made a mistake in putting it on the public server. Just because their intent was to keep it private, doesn't make it so when they make it available on a publicly accessible server.
So far, my experience with using Mozilla (both 1.0 and 1.1) with People's Bank has been great except for one problem which turned out to be on my side. I ran into a problem with the People's Bank site not displaying correctly using Mozilla 1.1. I contacted support (since the site worked fine previously) and their official answer was that they didn't support Mozilla, though they are looking into it. It turns out that the problem was that I enabled HTTP Pipelining and their servers didn't support it. I turned it off and their site worked fine again. I contacted support and let them know. It would be nice if Mozilla allowed you to turn on HTTP Pipelining per site (e.g. a checkbox in the bookmark's properties) rather than global.
Why is this such a big suprise to everyone?
The purpose of agents in the FBI are for law enforcement purposes, specifically, the enformcement of federal laws. All agents need to be able to handle, or contribute to, any type of criminal case, not just the one they have a specialty in. Just becasue you are a computer expert doesn't mean you won't be working a kidnapping or bank robbery. You have to be able to meet the standards that any other agent meets. Plain and simple. This is especially true for major events like the federal building bombing in Oklahoma and the 9/11 investigations. During these times most agents were retasked to assist in these investigations. It's not like you are going to refuse because "I don't do bombings, I do computer fraud." You're not a team player with an attitude like that and the FBI and other federal agencies don't need people like that.
Also, I've been reading about the compensation comments here. Yes, we'd all like to make more money, but money is not the reason you join a group like the FBI. I can't think of one specialty in the FBI that wouldn't pay more on the outside world. There are many reasons people join the FBI (other other agencies):
* Patriotism
* The opportunity to work with 'the best'.
* The opportunity to do things that only working at the federal level will allow you (protecting the President (USSS), protecting Air Force One around the world(USAF SP), developing unique CPUs (NSA), seeing what's really involved with regard to world events (NSA, CIA, State Department), etc.)
* Love of a particular field (e.g. law enforcement)
* The best training in the world in your field.
Besides, people with backgrounds in the FBI will be able to make very good money once they leave/retire.
Not true. Many people incorrectly refer to the sniffing of electromagnetic signals as 'TEMPEST attacks'. While it is certainly convenient to use this term, TEMPEST actually deals with the prevention of such signals, not the gathering of them.
As for only reading monitors, you are quite mistaken. TEMPEST covers the entire electromagnetic spectrum. If you've ever seen TEMPEST equipment, everything is 'shielded', not just the monitor. Electromagnetic sniffing can be applied to any electronic device, not just computers. Monitors are probably the easiest for people to think of because it's information they're seeing. But sniffing the monitor does you no good for gather passwords, because they either don't show up on the screen or are some other character. But sniffing the keyboard will certainly give you this info.
I'm still holding out for my ATA100 5.25" floppy drive.
Does this person even know what they are talking about? First off, the speed of sound is roughly 760 Mi/Hr at sea level, but it depends entirely on the density of the medium the sound is travelling in. At altitude, where aircraft perform best, the speed of sound is roughly 640 mi/hr (again, depending on density). Production jet powered aircraft have been travelling faster than Mach 2.1 since the 60's. Aircraft, off the top of my head, that travel faster than this are:SR-71, F-14, 15, MiG-23, 25, 29, 31, Su-27, 30, Mirage III, and Panavia Tornado. And that's just the unclassified stuff.
This is not true. All Athlon/Duron motherboards use a 100MHz DDR FSB and a 133MHz memory bus (not including the AMD 760 DDR RAM chipset). The P4, BTW, uses a QDR(Quad data rate) memory bus, but still only uses a 100MHz data rate FSB. With all this terminoligy and the marketing spin doctors at these companies, it's easy to get confused.
:-)
What does a 100MHz DDR FSB mean? It means that the CPU talks to the chipset at a 200MHz data rate even though the frequency is only 100MHz because it can send two bits of information per clock cycle instead of one.
Let's compare Duron/Athlon vs. Celeron/P4:
FSB MHz: All use 100MHz
FSB throughput: Duron/Athlon: 200MHz, Celeron/P4: 100MHz
Memory Bus MHz: Duron/Athlon: 133MHz, Celeron/P4: 100MHz
Memory Bus throughput: Duron/Athlon: 133MHz, Duron/Athlon(DDR): 266MHz, P4(Rambus): 400MHz, Celeron: 100MHz
OK, so not only does Duron as a chip spank Celeron (especially for the price), we see that a Celeron system is severely lacking compared to a Duron system.
I'm not a hardware guy, so if I'm wrong on any of this, I'm sure it will be corrected in a polite and professional manner
- Rick Alther
Agreed. Civilization and Civ 2 were the most addicting games I've ever played. Hell, I still play Civ 2...and Civ 2 Multi-player came along and you got to play against real people. That was the pinnacle. I would spend entire days playing. I just need to capture this one city...then I'll stop...yeah, right.
:-) But you just couldn't stop.
...ahhhh memories :-)
Lemmings is also another fond memory from days gone by. Getting all of those little bastards to the exit was damn frustrating at times....to the point of just maxing out the release rate and then just nuking them
And finally, I was a HUGE AD&D player back in the early to mid 80's. The moment I played Ultima III back on my Atari 800XL, I was hooked on the Ultima series. I would play until I couldn't stay awake anymore. While the most recent Ultima's were nice, there was something to the more simple graphics that almost made it more enjoyable. I think my favorite was Ultima IV (VI was a close second). They all had fabulous theme music and the stories were engrossing. Sometimes too much flash takes away from the real experience.
- Rick Alther
Just because someone is using a debugger doesn't mean they don't know what's going on. On the contrary, I would argue that anybody continuously adding printf's everywhere really doesn't know what's going on because they're shooting in the dark hoping for the miracle output that will point them to the error in their code.
Using a debugger requires that you know your code fairly well, although it can also help you learn code you haven't seen before. If you don't know how your code works, how are you going to know where to set your breakpoints and watches appropriately?
Using a debugger to track down a problem should only take a few minutes. Anybody spending hours just isn't using the tool properly. Debugging takes skill and experience. I know newbies who get into the debugger and step through everything. That's nuts and a waste of time. Learn to use the tool. It'll give you much more insight into how your code works and how it interacts with other libraries.
My typical debugging sessions goes like this:
- Something incorrect happens in the program.
- I look at my diagnostic output. Usually the culprit is pretty obious and I fix it.
- If it's not, I take a look at the code itself to see if I missed something. If I notice a problem in the code, I fix it.
- If it's not obvious, I fire up the debugger and set appropriate breakpoints and/or watches based on my knowledge of the problem and the code. Usually I'll see the problem on the first pass and I fix the code within minutes.
Enough of the doctor analogiesDebuggers aren't a a crutch. They are a tool to use...and a productive one at that. You are correct in your statement "The wise programmer uses the right too for the right job." Usually it's a combination of tools.
- Rick Alther
Debuggers (both command line and GUI) are all essentially the same. Learning one isn't doesn't take very long (on the order of a few minutes) to do the basic things like set breakpoints, step, and watch variables.
Here are the problems with printf (and other diagnostic output):
- They don't give you the whole picture and very rarely point you to the exact location of your problem.
- They have to be maintained. I don't know how many times people have cut & pasted a printf but failed to change its output causing utter confusion. Or the code changes and the printf didn't. They can become a maintenance headache which can actually hinder the troubleshooting process. The should be controlled somehow (preprocessor..some logging level varible etc.) but getting everyone to do that everywhere consistently is also a problem.
- They can be misleading especially if the output has not been flushed yet.
- They can get in the way of the actual running of the program and mask bugs (especially race conditions).
- They can't tell you when a pointer or variable gets stomped on.
Debuggers on the other hand let you see your entire application state and you can see in an instant if everything is right.- If the program crashes you immediately see what went wrong and you can view the call stack to see how it got there.
- You can easily debug multi-threaded programs because you can force potential race conditions and see if your code works properly or not.
- You can dynamically alter the flow of your program yourself and force potential problems to check your code behaves properly. Using a debugger is a great way of testing all conditions a piece of code might face: valid input, edge conditions, and invalid input.
'Debugging' with printf is an iterative and lengthy process of looking at the output, adding more printf's (adding to the maintenance problem), compiling, and looking at the output again. With a debugger, I almost always find the problem on the first or second pass through. You also invariably find other potential problems lurking in the code that just haven't shown up yet. Tracking down a problem with a debugger usually takes me just a few minutes, but going through the printf process takes much longer and may never show you the real problem.Think of it this way: You go to a doctor saying you dont' feel well. The printf doctor pokes and prods you until you yell 'ow!'. The debugging doctor uses the intelligent approach where he looks at your symptoms, runs some tests and makes a much more accurate diagnosis of your problem.
- Rick Alther
I don't think the corporation "used" her or any other temp. They hired outside people through the contracting agency. That's what the agency's business is: to market their product, in this case people. Just because they are called 'temps' doesn't mean that the job is a temporary one. It could be for a few weeks or several years. The point is, the company is using a tool at their disposal. If a 'temp' decides they want to work at the company then they should apply. It's their choice. They aren't getting deprived because they are a temp. It was their choice and they are getting paid by their company - the contracting firm. That's their job. If they have a problem with it, leave like anybody else would leave a 'standard' employee position and seek your fortunes elsewhere.
You mention the conditions us poor, educated, in demand, IT people work in. In some cases it's true and a lot of time the extra hours are unnecessarily forced on us by management to make deadlines some clueless marketing person agreed to. But again, that's the job. Software development and IT is full of unexpected pitfalls (what software does 100% it is documented to do...hell for that matter 90%). But it's not just IT people whose job demand unpaid overtime or that little bit extra. Practically every other job demands this at some point or another. I don't necessarily feel sad for IT people and the 'horrendous' stress they are put under. Try switching places with a cop or fisherman sometime!
It's the career we've chosen and it's up to us to decide when we've had enough either with our current employer or our career. We're all adults and are responsible for our own lives.
IMHO, this is entirely the temp worker's fault. They already work for a company...their contracting firm. They get paid and have benefits thorugh them. Why should they expect any benefits from their client? If they wanted MS to give them benefits, then they should have joing MS instead of their contracting co. Seems to me they want to double dip. Is that any different then a company hiring a large outsourcing company like IBM to do long term work for them? Imagine the IBMers working at this other company demanding that their client give them the same benefits as its employees.
Unfortunately, this decision is bad for the contractors. My sister was a temp for GE and was hired a few months before this case went to court. As a result of this case GE changed their temp policy and after one year, they just let her go out of fear she would sue them for benefits. It's ridiculous.
The temp's that brought this case against MS were just greedy opportunists. I have no sympathy whatsoever for them.
Oops! The correct URL to the white paper is: .com/software/ad/vacpp/library/version4/paper.html
http://www-4.ibm
- Rick
An incremental compiler/linker is one that compiles and links only the changes since the previous build, greating reducing the compile/link time for building programs.
Think of incremental compiling like incremental backups. You do your initial backup which takes the longest. Then you do incremental backups, backing up only the data that has changed since the last backup.
Incremental compiling/linking is similar. You do your initial build, then as you subsequent builds, the compiler only compiles the changes and links the changes, greatly reducing build times.
This white paper has a more detailed description of this technology.
- Rick Alther
Yes, you are correct. X itself is not a GUI, but merely defines a protocol for applications (clients) to talk to Servers (X Window Managers). It also provides graphical primitives which are display independent.
Most people responding to this article obviously do not know what they are talking about because the keep discussing how the Linux desktop should look. How the desktop looks it totally separated from X itself. Window managers, the libraries apps are linked with and shells define what a particular GUI looks like, not X.
I work on OS/2, WinNT, and Linux and I have X servers for ALL of them. I have to tell you, it is very convienient to run a program on my Linux box and have it show up on my OS/2 system or WinNT system....or at home...or in another state to show a customer....or....
The article is not about how displays look because X does not describe the graphics themselves, but instead defines a protocol for applications (clients) to talk to X Servers. X Window Managers manage the graphics displays. I think people are getting hung up on the 'looks' of a GUI which is totally dependent upon the X Window Manager and the underlying libraries the specific application was linked with.
X is probably the best protocol for a distributed windowing environment. It is certainly the most flexible. Sure, improvements can still be made, but X is a great concept and a stable piece of software using open standards. Name another piece of software that is as flexible, useful and solid.
Has anybody noticed a recent trend in CS graduates lately? When I graduated (almost 4 years ago) most CS students were in that degree program because they truly enjoyed programming, solving problems, and all-round hacking. However, lately I've been seeing CS graduates without that inquisitive nature. A lot of students seem to be taking up the degree now because it is now a more mainstream job and there's 'lot's of money in it' to quote one student that I interviewed. There are still the 'hacker' types who simply love it, but there are more and more 'non-tech' people graduating. I see them all the time.
Also, it seems that students are emphasizing more and more on 'high level' topics and have very little concept and understanding of the lower level stuff. e.g. We're seeing more Java coders and, I love this, 'HTML programmers'. That's great that they are interested in these areas, but we're loosing a vast technical base of people that really understand what's going on under the covers. Very few people know assembler (not that it's used a whole hell of a lot, but if you understand assembler, you can track down compiler problems, JVM problems, etc. and you simply know how things work rather than guess at them.) Very few people can use a debugger proficiently and even more use the debugger as a last resort debugging tool. They would rather litter the code with output statements first because, as one new employee put it 'the debugger is a pain to use.' Hmmmmm. Has anybody else noticed this trend? Sorry for the wind.
With your basic Java applet, you can't accomplish it unless there is a bug in the JVM or someone discovers a hole in the security model.
...and this is a simple example.
However, you can write a trusted Java applet that has full reign just like a regular program, so it CAN be done with a Java applet in combination with native code.
Whether someone may acutally get your PIII ID may or may not be a big deal, it's things like this that lead toward a slippery slope of things to come. What's the next 'minor' invasion of privacy that we'll 'accept' because it's no big deal? I can just see it now: A leagally purchased program records the PIII ID and checks the ID every time it is run. But due to oversight on the programmer's part I upgrade my chip to a faster version and, whoops, the program won't run because it thinks it's on another machine.