Just a question: exactly what does your mail server tell you when you receive a 600MB attachment?
It very politely tells the sending MTA that the message is too large. That MTA had better generate a bounce message back to the sender saying the same thing.
I just check the NBC/CueCat web site and saw that the show that will have "Cue-enhanced commercials" is none other than
The Weakest Link
Now, how appropriate can that be? I mean, one of the lamest game shows on television today being the vehicle for testing your CueCat link? It is to laugh...
The C-Text service was launched in, if memory serves, 1973. This used one of the top lines in the vertical blanking interval (line 16? Anyone remember that detail?) to transmit text at a respectable rate over a standard TV channel. The data stream was organized in numbered frames of about 300 characters each, and the system transmitted 15 C-Text data frames per second. A set-top box would scan the datastream for a frame with the frame number selected by the user; when that frame was received by the box it would put the data into a buffer and display the text on the TV screen.
In the system demo I saw, the frame numbers were three decimal digits. Mini-computers (DEC PDP-11/70s) would structure the datastream and feed it to the transmission system. One reason for using the PDP-11/70s was that the head-per-track disk that seemed to be standard equipment for those computers could ensure that frame assembly could be done in real time. The software kept a "play list" of frame numbers, so that common frames would be transmitted frequently while less-common frames would be transmitted at less frequent intervals.
The reason I saw this demo was that Rockwell was thinking about launching a C-Text type service in the United States. When Marketing was done chewing the numbers, the resulting opinion was that offering the service didn't have a large enough ROI to justify the expense and risk. So Rockwell said "thanks, but no thanks." Broadcasters were worried that C-Text data would interfere with the transmission-quality test signals built into lines 18 and 19, and the telcos echoed the feeling.
When I started writing about the CueCat last year, the promotional material I received included what purported to be recordings of television cues. I didn't have the analysis tools I have today to try to determine how they encode digital data in the sound, but my short attempt with a spectrum analyzer didn't expose anything obvious.
I do know something about the audio chain used in television stations, and can tell you that the chain is unable to pass anything outside the passband 50-15,000 Hz. Remember, television sound is transmitted using FM modulation of a subcarrier at the top end of the channel. (Picture information is transmitted using AM, and color information by phase modulation.) Transmitting anything about 15 kHz at any significant level would cause the audio signal to splatter outside the allowed passband. Not only that, but most television reception equipment -- especially for the home -- wouldn't pass the out-of-band signal out the RCA jacks anyway.
Now that I have a copy of the SDI watermark attacks, I can try some of those techniques to find the embedded information without having to reverse-engineer the stupid Cat software, which doesn't work on Linux anyway...
(It also means I now have a reason to install the TV-tuner card into my PC and get a cable hook-up to it, assuming that I want to try to capture this stuff anyway. Because the TV-card is supposed to play through the computer speakers, I should be able to grab the sound stuff as it goes by.)
Russell Brand has a role-playing game for system admins. The game would have each person in the security class be the sysadmin of a single system, and it was that person's responsibility to (a) keep the system from being cracked, (b) keep the users from cracking the sysadmin, and (c) keep the boss happy.
I won't go into any details because for the three years he presented this game at a conference I attend, the scenerios were completely different. But I will give you some insight into why the game was very, very good:
1) It was possible (although very, very unlikely!) that a system could chug along without ever being attacked.
2) The game was constantly being updated based on the latest attacks common on the Internet. In other words, each attach scenerio was based on a real-life crack.
3) Russell showed us that it was possible to foil the attackers without being killed by the users, even in a worst-case scenerio.
4) You gain a healthy respect for a pair of dice controlling your life.
Sadly, I've not heard of this game being made available in the past few years. I'll have to check to see what the status of the game is; if there is a version you can "play" on the net, I'll post the fact somewhere.
One problem with many out-of-the-box password schemes is that they have too few characters. We are starting to see a trend to reasonable-length passwords (usually incorporating the use of a hash algorithm like MD5 to reduce the password to 64 bits) so that people can use a system of strong but easy-to-use passwords.
One scheme that seemed to work quite well was the system that Compuserve first started using, back when they were H&R Block: the password generator would select two words (each four to six characters long) and a punctuation mark, and combine them into a string. For example:
window/ran
boat=steep
ramble,cart
This scheme took advantage of the fact that the PDP-10 operating system H&R Block was using allowed for 12 characters in a password.
The key was that there were never two nouns, or two verbs, or two adjectives, or two pronouns. Sometimes the generated password would look like something from the original Adventure game, but it was still very hard to guess, and the dictionary attack required the attacker to try pairs of words coupled with selections from the punctuation mark string ".,/?+=*&$@!" and you have a fairly large universe of passwords to try -- around 640 million if you assume a total of 8000 words in the dictonaries. (Much of this is from memory; excuse me if I'm getting some of the details wrong.)
I never heard of a Compuserve password that was cracked in a pristine way. Every single crack I was aware of involved either social engineering or monitoring the user. Oh, I suppose that someone may have been able to do the job, but I never heard about it.
Now, if you have only eight characters to work with, you are out of luck. Sorry.
If the computer case is the source of the problem, then the case shouldn't be in the ICU patient area. There are a number of off-the-shelf products for moving a monitor, keyboard, and mouse far, far away from the system unit.
So you put the PC cases in a machine closet (with proper AC separate from the ICU AC to keep the machines running cool) and run the KVM extender to a convenient point to the bed in the ICU.
Or use Unix in a closet and run VT-100 terminals...
And as for the judges, the judge that found McDonalds liable for not warning some (fully grown and presumably employed) idiot that coffee is hot set a precedent (both in peoples minds and in a very legal sense) that ridiculous lawsuits could be won, even if there was no lasting damage.
Don't beat around the bush, say what you really think. The issue as I see it is that common sense doesn't apply anymore -- and I blame the Kennedys for starting this crap. Clinton just added fuel to the fire. Let's look at how common sense has become a rare commodity in the United States of America:
A farmer sets up a stepladder, a common tool used in homes and businesses by the millions. This is not the first time the farmer has used this tool. The purpose of using the tool was to fix a door on his barn. What the farmer failed to realize is that two legs of this common tool were on solid ground, while two legs were on a pile of manure he had built up over time. When he climbed the ladder, the manure gave way, the ladder pitched forward, and threw the farmer off. The result of his short flight was a broken leg.
The farmer then sues the ladder manufacturer for negligence! It seems there was no warning on the ladder to ensure that all four legs are sitting on a firm surface. Result: $40K settlement in favor of the farmer.
Now do you understand why so many products have so many labels that state the obvious to people with common sense?
I question the right of a US body to continue to make decisions concerning what is a global resource.
As I recall, each country with a two-letter TLD has the right to do whatever it wants with the second-level domain names -- and that includes.com.. Does Verisign control.com.uk.? I didn't think so.
Of course, the right answer is to eliminate the TLD.com,.net,.org,.edu, and so forth and move all existing United States sites to.com.us,.net.us,.org.us,.edu.us, and so-forth.us. That would necessitate creating a TLD called.multi, so that multi-national organizations and corporations could have a home.
It would take the pressure off the.com database, wouldn't it?
What are some better alternatives for handling domain registration, other than having a corporation in charge?
Originally, universities were the keepers of such things. A not-for-profit such as IEEE, ACM, or even The Verisign Foundation would be able to handle the job. (The last is a made-up name, although I would not at all be surprised to hear that Verisign has such a philanthropic arm.)
The military-industry complex is more used to for-profit companies taking on these function -- it makes it easier to sue for damages if the contracted company doesn't do the job. Unfortunately, the Dept. of Commerce doesn't have an effective and measurable performance clause in the contracts...
"We hope these type of games disappear from the landscape," Lawlor said. "People that makes these kinds of things have gone too far."
Now, are any of you game designers deterred from creating yet another shoot-em-up game because of this (possible) CT law? Do you feel that you have gone "too far"? I thought not...
Now, here is an idea I'll toss out for you designers to consider. Robert Heinlein made a big deal about the role of intelligence-gathering scouts, yet I have yet to see any arcade or computer game that has the player perform in this role. Wouldn't it be a hoot if one or more of you were to design a game in which the goal is to not get shot while gathering and transmitting back information? Your only weapon would be your wits and the cover provided by the environment, as well as the med-kit on your belt as you get winged by "the bad guys."
Being a scout, you would be considerably lighter on your feet than the typical weapon-toting warrier. Oh, RAH allowed a knife in his stories, but the point was that the scout is the rabbit, not the lion. So design accordingly.
The game prizes would be microdots, but you get the points only when you successfully transmit them back to base. The survival of the scout is not the object, only the transmission of information. Dying well would be a winning move if the information you send back is valuable enough -- in other words, a sacrifice may well be the play that keeps you going, as the reward could be a new life or complete repair or something.
If you use this idea, all I ask is that you give me a little credit. No money required.
Please, engage brain before putting keyboard in gear. The obvious answer is that government would let contracts for technical support just as they do now. In other words, the revenue stream would shift from software sales to software support.
The really good part about such a shift would be that multiple companies -- including small companies -- would be able to provide support. Small companies are at a severe disadvantage when it comes to software contracts because the barrier to entry is quite high. Support, on the other hand, can be awarded to many, many companies without harming the Government's ability to use them. Cf the translation contracts let by the USPTO.
Indeed, I see the creation of speciality companies that are formed just to meet the needs of the General Accounting Office, the legislative offices, the independent agencies, and even the entitlement agencies.
Because one requirement would be that workers be US Citizens, the H-1B problem is diminished because now there would be a place for all us older technical people who are US citizens to find worthwhile work. No more bashing companies like "a certain chipmaker" for passing over us older techie types.
It also provides a better channel for grant money to create software with specific function. If the US Government needed a Word clone, it could provide the money to fund the development -- no more waiting for Sun or Corel or anyone else to pony up the money with little hope of any return.
Gee, the more I think about the idea the more I like it. Too bad the SIIA and other software lobbies have a lock on our Congresscritters...
Ok, I've read the links, I've read about 1/2 of the comments so far, but I have to take exception to some (but not all) of the assumptions and interpretations of the facts behind this Anonymous Coward's post.
First, let's get one thing straight. What was taken from the police cars were operational contingency plans prepared by Canadian law enforcement to counteract a series of perceived threats to the public peace, including surmised timing information. In those plans, the Canadian police identified items of intelligence gathered in some manner, potentially compromising those sources of intelligence. It could be argued that the publication of those plans rendered those plans less effective as it provides counter-intelligence to the groups involved in disturbing the peace.
How could the United States law enforcement become involved? There was a mention in the plans about intelligence that a group from Oregon was alledged to plan to cross the border and participate in activities illegal on Canadian soil. Further, the server used to post this information against the wishes of the Canadian police exists on US soil.
Not unreasonable, for the FBI to be asked to help and for the FBI to grant the request to identify the source of the information.
Where the FBI, in my opinion, went over the line was with the overbroad search warrant demanding the identity of not only the perps that posted the message but every single person who might have had access -- readers as well as writers. It follows that the FBI [wrongly] assumes that anyone reading those pages are involved in the criminal actions in our Neighbor to the North. Typical LE thinking.
The analogy would be that if those papers had been printed in The Police Gazette that every single subscriber to the magazine would be implicated in the crimes that followed, as well as everyone who visited the library to peruse the issue in question. The IMC is clearly a PUBLICATION, apparently with a wide readership, and with readers that hold many differing views.
Sorry, richie123, I just dumped my leather-bound organizer for a Palm IIIxe. The organizer got too thick to deal with. The Palm is about 1/4 the size and I haven't even begun to fill its 8-MB memory. Plus, I synchronize the Palm with my laptop's PIM data on a regular basis so that I have the backup you imply is important.
The case for the Palm has PostIts and a pad, because sometimes nothing beats a pen and paper for notes. I haven't found a good time-track software package for the Palm, so this function remains a paper one, with good results.
Arrange with your management to set aside a day for a "Little Stuff Contest." It works like this:
Draw some petty cash to purchase a couple of geek toys. If you know your developers you will know exactly what will do the job.
The rules are simple: the developer who submits the most changes during the designated 24-hour period wins his choice of the toys. The developer who submits the most elegant change gets next pick. And so forth -- use your imagination.
The judging will be based on verification and integration of the changes into the product, so don't forget to allocate at least a couple of days for the QA of the changes and retirement of the associated bugs.
You may have to implement a parallel incentive program within DVT/QA. The toys will be different, of course.:)
Make this a regular thing, and you will be surprised how quickly the nuisence bugs get cleared. Moreover, I can tell you from personal experience that in the process of clearing "the small stuff" some big stuff will be found and fixed as well.
(I was a developer who moved into the testing area because my employers and peers found I had a knack for exposing weaknesses in a product. So let me draw on both sets of experiences to provide a "developer-oriented" answer to this question.)
The first goal of DVT/QA testing is to ensure that the product functions as the functional specification and documentation says it should.
That means DVT first tests each operation, each feature, and each option on each environment with a variety of recognized and accepted test data sets. Not only are DVT testers looking for proper operation with proper data, but also proper operation with bad data. In other words, do the error-catching routines actually catch errors? If there is a sequencing error, is it reported properly? Recovered from properly?
In many DVT environments, the test conditions are required, to the best of the DVT system's ability, to test all of the code, using profiling and test coverage tools to indicate when each path has been checked.
Like development, design verification and test (DVT) and product quality assurance have as many levels of abstraction as your typical development effort. Properly structured testing looks at the major stuff first, options next, and then they go for the anomolies. Indeed, in the DVT efforts I have managed, the checkout of a software change required the "20-minute test", the "3-hour test", and the "24-hour test" before I would approve the change to be part of a release candidate subject to full regression testing. (From project to project, the actual length of time taken for each of these tests differed, but the names stuck.)
The second goal of DVT/QA testing is to find operational problems in-house before the customer finds them in the field.
This is the time when testers "bang on the product" to determine if there are any weaknesses or coupling effects. The best testing is when you have a good number of alpha testers that use the product in the manner it was intended to be used, followed by a good-sized group of beta testers. Beta test management is an art unto itself, with the most important function being the selection of the beta testers themselves. Some companies miss the boat by only soliciting one type of beta tester. The best beta programs court fringe users, those who would use the product in unusual ways, in order to ferret out more error conditions.
Frankly, I find development easier to do than testing, but testing is to me the more satisfying activity...especially when my efforts expose some really funny cascades.
There is a third aspect to testing that doesn't get much play in companies: reproducing field problems. I have some war stories if someone serves up the beer...
This is probably a good time in this thread to throw out an allied problem: what happens when management doesn't like the results of the bug evaluation.
True story: a corporate-wide standard for bug determination was defined in a Fortune-50 corporation. In a project, though, the director of engineering decided that the standards "didn't reflect reality" -- or rather, that the numbers made him look bad. It also meant that there was no way he would be able to ship the product on time, because the number of ship-block bugs was just too high for his development staff to clear in a manner acceptible to him and to his superiors.
Now, the definition was pretty strict: Severity 1 bugs were features in the specification that were implemented and broken in significant ways, severity 2 were features in the specification that were implemented and met the operational requirements but not performance requirements, or were not implemented and marked in the specification as required for release, severity 3 were features that were implemented but broken in non-significant ways (cosmetics, usually) or features in the spec that were not implemented and marked as not required for current release, severity 4 were features that met spec but were identified as areas for improvement, and severity 5 were spec change requests. The rule is that the product MUST NOT ship with severity 1 bugs, SHOULD NOT ship with severity 2 bugs (release required a review and analysis of each S2 bug by corporate QA), MAY ship with severity 3 bugs, and MUST ship with priority 4 and 5 bugs.
So, Job One for this manager was to pull a Captain Kirk and change the rules. Severity 1 was redefined as "causing a system crash". Severity 2 was redefined to "causing an operation failure that does not result in a system crash". Severity 3 was everything else that used to be in S1 and S2, as well as what was originall in S3. That meant that missing or severely broken features identified as required for release obtained an S3 rating instead of the original S1 or S2 rating. Or, in other words, a broken product could now be shipped!
Of course, it didn't do very well in the market, but the manager in question still got his raise -- and I suspect that's all he cared about.
The root cause of this breakdown was that QA/DVT was an Engineering function, not a separate function. The guy saying "no" should be a peer to the guy saying "yes". (It would have helped if the original bug definitions would have been part of the specification, because the spec is king within this company -- but that didn't happen.)
There are a number of us who listen to Harris Miller, President, Information Technology Assocation of America tell the Congress that "425,000 job will remain unfilled during 2001." I (and many others on/.) wrote Mr. Miller asking him to convey our desire to take a shot at some of those 425,000 jobs.
I sent that letter on 2 April. I have yet to hear from Mr. Miller, the ITAA, any of the 2,500 member companies, or any headhunter about any of those 425,000 job positions.
How about you, Mr. Anonymous Coward? Do you really want to find qualified people? If so, drop a line -- I don't hide behind an AC name. In fact, to make it easy, here is my e-mail address in easily-clickable form.
When was the last time Intel hired a technical person in the over-40 age group? When was the last time you did?
I spent a half-day looking for information about winmail.dat and found it. As a result, I now have a little tool that picks apart winmail.dat files. If moderators show interest by modding up this post, I'll even make it available under the GNU license.
I have several clients who send me crap in winmail.dat, so I'm glad I have the tool.
I like this one. Rather than go one-on-one with the DC people with regards to the patents, it does an end-run by expanding the scope of the information returned. In my reading of the various patents, this goes beyond the four corners of the claims by looking up "dirt" as well as serving up the direct link.
Will K&K go after these people? I suspect so. The idea of doing a search on the domain name coupled with derogatory terms isn't covered by the claims of the DC patents, but it would serve to dilute the value of Cues, and so DC may launch a pre-emptive strike.
Now, these people would be well served to file a patent on the idea, to protect them from claims of infringement...
PigleT sez: "Bullshit. How the heck can a kernel be released `late'??... As it is, 2.4.3 has been around since Mar 30; I don't see why one package can't get a proper testing in that amount of time. "
18 days? For a package which requires multiple CD-ROMs to distribute? Especially one as complex as a Unix distribution? Do you have any idea how many opportunities there are for unfortunate interactions? No, let me make this stronger: what qualifications do you have in the field of software design and verification testing, PigleT?
When I was managing DVT for a single product of 45,000 lines of code, the entire testing suite required about 40 days to complete...if there wasn't a problem. Final verification after "the last bug fix" required 10 days. By the way, "day" was defined as 24 hours, and included weekends and holidays, using as much automation as we could muster. The crew was nine people full-time, and about 100 alpha testers, as well as a development corps of about 20 programmers who had their own, separately-developed DVT for design changes.
In some respects, testing a well-designed and well-implemented operating system is easier, because you have far more separation of function; in some respects an OS is far harder because of the unfortunate unforseen interactions that can crop up in any co-ordinated resource management system. Further complicating the DVT of an OS is that the problem set is not under the control of the developing company -- you have applications programs that delight in tripping up even the most careful of OS writers.
Red Hat is trying to sell a supported solution to non-geeks, and in particular to companies more interested in doing what they do -- be that selling toothbrushes, building cars, collecting taxes, shooting metal objects into space, curing cancer -- and not have to worry about every little thing about the OS they are running. In order to meet the needs of their target customers, they have to tread cautiously when putting together their distribution. Like Microsoft, they need to control the cost of technical support, and one way to do that is to test the hell out of the product before putting their name on it. That's the way they decided to do business.
Don't like it? Then go use Debian unstable for all your mission-critical projects. When it breaks, call Debian, not Red Hat.
Hey, there are libraries that manage to avoid C++ constructs to abstract this sort of stuff. For example, B-tree operators could use a fixed structure in which there exists the data fields necessary for the library to do its thing, and the "payload" of the structure is a void pointer to the data referenced by the B-tree node. This means that you can have disk-resident B-trees by using the void pointer to refer instead to a byte offset; array-resident B-trees by using the void pointer to hold an index; value-oriented B-trees by having an integer value in the void pointer.
For type purity, you could use an embedded structure definition for the B-tree elements, and the payload would be in the rest of the embedding structure. The B-tree routines would then use appropriate pointers to do its thing.
As you can probably tell, I tend to think C instead of C++ because most of my programming involves real-time processing. I don't like it when a language does things "behind my back" -- sometimes it's a good thing, sometimes it causes bugs that are impossible to find because of this sort of thing.
Oh, I don't mind C++ for computational stuff, but it's been so long since I've done something that's "merely" computational that I don't bother to hone the C++ skills I pick up each time I get these rare projects.
YMMV
WHO CARES? Just use GNU indent(1) when done
on
Spaces vs. Tabs?
·
· Score: 3
Of all the holy wars, this is the one that makes the least sense to me. One of the reasons we have tools is to make such useless pablum as unnecessary as possible.
Now, I speak as one who publishes source code on a regular basis, and finds that Mr. Torvald's edict works when editing but sucks when you are trying to publish on page. Never mind the fights with the "professional" graphic artists who don't understand the readers' needs, the rules according to Torvalds do not work on the published page. Witness Don Knuth's comments about white space management with respect to WEB source.
So let people do it the way they want. Tabs at 8? Tabs at 4? Spaces? No tabs at all? Fine. When you are done with the code, run it through indent(1) with the shop standard specification and be done with it.
And when I decide to write a book chapter using your Open Source code, I'll use my own configuration to make it easier to deal with on the printed page.
Oh, you want to know my standard? Just remember, you asked for it...
Courier 72 with monospacing, with a 66% set width
Braces on their own lines
Open and close braces at the same indent as the enclosed text
Each indent is equal to the type height, which is identical to a M-space followed by an N-space at the 66% setwidth, or an M-space if you ignore setwidth
bolding all appropriate keywords and certain macro variable names
Here is an approximate example (lack of proper typesetting controls in HTML prevent an exact depiction):
int main(int argc, char argv[])
{
printf("Hello world!");
}
If you have a number of "parallel" calculations or procedures to perform, nothing beats a good implementation of co-routines, hunks of code that are called from a master scheduler or process loop. When done correctly, the response time of a co-routine implementation can be better than a multi-threaded implementation because the operating system never has to worry about context switching.
Now, that doesn't mean that threads don't have their place. In my programs, the only use for threads (or processes, for that matter) is real-time I/O monitoring, and I do the absolute minimum I can in each thread/process so as to avoid tromping on shared variables. Everything else is under the control of the main program.
The primary purposes for forking is when you are dealing with human-time activities -- that's one reason that some Web servers will fork a process to handle a request, so that each user sees some response early. Another good reason to fork is to reduce the number of file pointers that have to be monitored. (There has been discussion of this in a number of different places.)
Just remember that threading imposes an overhead that you may be ill able to afford. Within embedded systems with real-time implications (single-CPU modems are a great example) the allocation of time is critical to balance the need to stream data with the absolute requirement to maintain synchronization with the modem line.
I believe you will also find that an appropriate co-routine implementation is much easier to debug, because the time relationships between the routines is strictly controlled by the routines themselves -- it is very easy to implement "critical path" segments without the use of semaphores or other tricks.
The down side? In real-time applications, the key to successfully using co-routines is to design each co-routine to do a useful amount of work without hogging the CPU and still relinquish control often enough to let other time-critical routines run appropriately. Judicious use of event trigger flags set by interrupts and periodically tested by your co-routines can ease this task. The same can be done in Unix applications with judicious implementation of signal-based I/O.
One aspect of co-routine implementation coupled with the correct use of select() timeouts is that it becomes very simple to implement an "I'm-sane" indicator in the user interface, reassuring your user that just because nothing appears to be happening doesn't mean the program is napping on the job.
Slashdot Mirror
I just tried to fill in the survey, and when I press Submit I get "Error: Unsupported method."
Stupid, stupid, stupid.
Just a question: exactly what does your mail server tell you when you receive a 600MB attachment?
It very politely tells the sending MTA that the message is too large. That MTA had better generate a bounce message back to the sender saying the same thing.
What's in your mail server?
I just check the NBC/CueCat web site and saw that the show that will have "Cue-enhanced commercials" is none other than
Now, how appropriate can that be? I mean, one of the lamest game shows on television today being the vehicle for testing your CueCat link? It is to laugh...
The C-Text service was launched in, if memory serves, 1973. This used one of the top lines in the vertical blanking interval (line 16? Anyone remember that detail?) to transmit text at a respectable rate over a standard TV channel. The data stream was organized in numbered frames of about 300 characters each, and the system transmitted 15 C-Text data frames per second. A set-top box would scan the datastream for a frame with the frame number selected by the user; when that frame was received by the box it would put the data into a buffer and display the text on the TV screen.
In the system demo I saw, the frame numbers were three decimal digits. Mini-computers (DEC PDP-11/70s) would structure the datastream and feed it to the transmission system. One reason for using the PDP-11/70s was that the head-per-track disk that seemed to be standard equipment for those computers could ensure that frame assembly could be done in real time. The software kept a "play list" of frame numbers, so that common frames would be transmitted frequently while less-common frames would be transmitted at less frequent intervals.
The reason I saw this demo was that Rockwell was thinking about launching a C-Text type service in the United States. When Marketing was done chewing the numbers, the resulting opinion was that offering the service didn't have a large enough ROI to justify the expense and risk. So Rockwell said "thanks, but no thanks." Broadcasters were worried that C-Text data would interfere with the transmission-quality test signals built into lines 18 and 19, and the telcos echoed the feeling.
When I started writing about the CueCat last year, the promotional material I received included what purported to be recordings of television cues. I didn't have the analysis tools I have today to try to determine how they encode digital data in the sound, but my short attempt with a spectrum analyzer didn't expose anything obvious.
I do know something about the audio chain used in television stations, and can tell you that the chain is unable to pass anything outside the passband 50-15,000 Hz. Remember, television sound is transmitted using FM modulation of a subcarrier at the top end of the channel. (Picture information is transmitted using AM, and color information by phase modulation.) Transmitting anything about 15 kHz at any significant level would cause the audio signal to splatter outside the allowed passband. Not only that, but most television reception equipment -- especially for the home -- wouldn't pass the out-of-band signal out the RCA jacks anyway.
Now that I have a copy of the SDI watermark attacks, I can try some of those techniques to find the embedded information without having to reverse-engineer the stupid Cat software, which doesn't work on Linux anyway...
(It also means I now have a reason to install the TV-tuner card into my PC and get a cable hook-up to it, assuming that I want to try to capture this stuff anyway. Because the TV-card is supposed to play through the computer speakers, I should be able to grab the sound stuff as it goes by.)
Russell Brand has a role-playing game for system admins. The game would have each person in the security class be the sysadmin of a single system, and it was that person's responsibility to (a) keep the system from being cracked, (b) keep the users from cracking the sysadmin, and (c) keep the boss happy.
I won't go into any details because for the three years he presented this game at a conference I attend, the scenerios were completely different. But I will give you some insight into why the game was very, very good:
1) It was possible (although very, very unlikely!) that a system could chug along without ever being attacked.
2) The game was constantly being updated based on the latest attacks common on the Internet. In other words, each attach scenerio was based on a real-life crack.
3) Russell showed us that it was possible to foil the attackers without being killed by the users, even in a worst-case scenerio.
4) You gain a healthy respect for a pair of dice controlling your life.
Sadly, I've not heard of this game being made available in the past few years. I'll have to check to see what the status of the game is; if there is a version you can "play" on the net, I'll post the fact somewhere.
One problem with many out-of-the-box password schemes is that they have too few characters. We are starting to see a trend to reasonable-length passwords (usually incorporating the use of a hash algorithm like MD5 to reduce the password to 64 bits) so that people can use a system of strong but easy-to-use passwords.
One scheme that seemed to work quite well was the system that Compuserve first started using, back when they were H&R Block: the password generator would select two words (each four to six characters long) and a punctuation mark, and combine them into a string. For example:
This scheme took advantage of the fact that the PDP-10 operating system H&R Block was using allowed for 12 characters in a password.
The key was that there were never two nouns, or two verbs, or two adjectives, or two pronouns. Sometimes the generated password would look like something from the original Adventure game, but it was still very hard to guess, and the dictionary attack required the attacker to try pairs of words coupled with selections from the punctuation mark string ".,/?+=*&$@!" and you have a fairly large universe of passwords to try -- around 640 million if you assume a total of 8000 words in the dictonaries. (Much of this is from memory; excuse me if I'm getting some of the details wrong.)
I never heard of a Compuserve password that was cracked in a pristine way. Every single crack I was aware of involved either social engineering or monitoring the user. Oh, I suppose that someone may have been able to do the job, but I never heard about it.
Now, if you have only eight characters to work with, you are out of luck. Sorry.
If the computer case is the source of the problem, then the case shouldn't be in the ICU patient area. There are a number of off-the-shelf products for moving a monitor, keyboard, and mouse far, far away from the system unit.
So you put the PC cases in a machine closet (with proper AC separate from the ICU AC to keep the machines running cool) and run the KVM extender to a convenient point to the bed in the ICU.
Or use Unix in a closet and run VT-100 terminals...
And as for the judges, the judge that found McDonalds liable for not warning some (fully grown and presumably employed) idiot that coffee is hot set a precedent (both in peoples minds and in a very legal sense) that ridiculous lawsuits could be won, even if there was no lasting damage.
Don't beat around the bush, say what you really think. The issue as I see it is that common sense doesn't apply anymore -- and I blame the Kennedys for starting this crap. Clinton just added fuel to the fire. Let's look at how common sense has become a rare commodity in the United States of America:
A farmer sets up a stepladder, a common tool used in homes and businesses by the millions. This is not the first time the farmer has used this tool. The purpose of using the tool was to fix a door on his barn. What the farmer failed to realize is that two legs of this common tool were on solid ground, while two legs were on a pile of manure he had built up over time. When he climbed the ladder, the manure gave way, the ladder pitched forward, and threw the farmer off. The result of his short flight was a broken leg.
The farmer then sues the ladder manufacturer for negligence! It seems there was no warning on the ladder to ensure that all four legs are sitting on a firm surface. Result: $40K settlement in favor of the farmer.
Now do you understand why so many products have so many labels that state the obvious to people with common sense?
Your tax dollars at work.
I question the right of a US body to continue to make decisions concerning what is a global resource.
As I recall, each country with a two-letter TLD has the right to do whatever it wants with the second-level domain names -- and that includes .com.. Does Verisign control .com.uk.? I didn't think so.
Of course, the right answer is to eliminate the TLD .com, .net, .org, .edu, and so forth and move all existing United States sites to .com.us, .net.us, .org.us, .edu.us, and so-forth.us. That would necessitate creating a TLD called .multi, so that multi-national organizations and corporations could have a home.
It would take the pressure off the .com database, wouldn't it?
What are some better alternatives for handling domain registration, other than having a corporation in charge?
Originally, universities were the keepers of such things. A not-for-profit such as IEEE, ACM, or even The Verisign Foundation would be able to handle the job. (The last is a made-up name, although I would not at all be surprised to hear that Verisign has such a philanthropic arm.)
The military-industry complex is more used to for-profit companies taking on these function -- it makes it easier to sue for damages if the contracted company doesn't do the job. Unfortunately, the Dept. of Commerce doesn't have an effective and measurable performance clause in the contracts...
"We hope these type of games disappear from the landscape," Lawlor said. "People that makes these kinds of things have gone too far."
Now, are any of you game designers deterred from creating yet another shoot-em-up game because of this (possible) CT law? Do you feel that you have gone "too far"? I thought not...
Now, here is an idea I'll toss out for you designers to consider. Robert Heinlein made a big deal about the role of intelligence-gathering scouts, yet I have yet to see any arcade or computer game that has the player perform in this role. Wouldn't it be a hoot if one or more of you were to design a game in which the goal is to not get shot while gathering and transmitting back information? Your only weapon would be your wits and the cover provided by the environment, as well as the med-kit on your belt as you get winged by "the bad guys."
Being a scout, you would be considerably lighter on your feet than the typical weapon-toting warrier. Oh, RAH allowed a knife in his stories, but the point was that the scout is the rabbit, not the lion. So design accordingly.
The game prizes would be microdots, but you get the points only when you successfully transmit them back to base. The survival of the scout is not the object, only the transmission of information. Dying well would be a winning move if the information you send back is valuable enough -- in other words, a sacrifice may well be the play that keeps you going, as the reward could be a new life or complete repair or something.
If you use this idea, all I ask is that you give me a little credit. No money required.
Please, engage brain before putting keyboard in gear. The obvious answer is that government would let contracts for technical support just as they do now. In other words, the revenue stream would shift from software sales to software support.
The really good part about such a shift would be that multiple companies -- including small companies -- would be able to provide support. Small companies are at a severe disadvantage when it comes to software contracts because the barrier to entry is quite high. Support, on the other hand, can be awarded to many, many companies without harming the Government's ability to use them. Cf the translation contracts let by the USPTO.
Indeed, I see the creation of speciality companies that are formed just to meet the needs of the General Accounting Office, the legislative offices, the independent agencies, and even the entitlement agencies.
Because one requirement would be that workers be US Citizens, the H-1B problem is diminished because now there would be a place for all us older technical people who are US citizens to find worthwhile work. No more bashing companies like "a certain chipmaker" for passing over us older techie types.
It also provides a better channel for grant money to create software with specific function. If the US Government needed a Word clone, it could provide the money to fund the development -- no more waiting for Sun or Corel or anyone else to pony up the money with little hope of any return.
Gee, the more I think about the idea the more I like it. Too bad the SIIA and other software lobbies have a lock on our Congresscritters...
Ok, I've read the links, I've read about 1/2 of the comments so far, but I have to take exception to some (but not all) of the assumptions and interpretations of the facts behind this Anonymous Coward's post.
First, let's get one thing straight. What was taken from the police cars were operational contingency plans prepared by Canadian law enforcement to counteract a series of perceived threats to the public peace, including surmised timing information. In those plans, the Canadian police identified items of intelligence gathered in some manner, potentially compromising those sources of intelligence. It could be argued that the publication of those plans rendered those plans less effective as it provides counter-intelligence to the groups involved in disturbing the peace.
How could the United States law enforcement become involved? There was a mention in the plans about intelligence that a group from Oregon was alledged to plan to cross the border and participate in activities illegal on Canadian soil. Further, the server used to post this information against the wishes of the Canadian police exists on US soil.
Not unreasonable, for the FBI to be asked to help and for the FBI to grant the request to identify the source of the information.
Where the FBI, in my opinion, went over the line was with the overbroad search warrant demanding the identity of not only the perps that posted the message but every single person who might have had access -- readers as well as writers. It follows that the FBI [wrongly] assumes that anyone reading those pages are involved in the criminal actions in our Neighbor to the North. Typical LE thinking.
The analogy would be that if those papers had been printed in The Police Gazette that every single subscriber to the magazine would be implicated in the crimes that followed, as well as everyone who visited the library to peruse the issue in question. The IMC is clearly a PUBLICATION, apparently with a wide readership, and with readers that hold many differing views.
The Pentagon Papers they ain't.
Sorry, richie123, I just dumped my leather-bound organizer for a Palm IIIxe. The organizer got too thick to deal with. The Palm is about 1/4 the size and I haven't even begun to fill its 8-MB memory. Plus, I synchronize the Palm with my laptop's PIM data on a regular basis so that I have the backup you imply is important.
The case for the Palm has PostIts and a pad, because sometimes nothing beats a pen and paper for notes. I haven't found a good time-track software package for the Palm, so this function remains a paper one, with good results.
It sounds like your life is too simple.
Have you tried social engineering?
Arrange with your management to set aside a day for a "Little Stuff Contest." It works like this:
Make this a regular thing, and you will be surprised how quickly the nuisence bugs get cleared. Moreover, I can tell you from personal experience that in the process of clearing "the small stuff" some big stuff will be found and fixed as well.
Motivation is a beautiful thing.
(I was a developer who moved into the testing area because my employers and peers found I had a knack for exposing weaknesses in a product. So let me draw on both sets of experiences to provide a "developer-oriented" answer to this question.)
The first goal of DVT/QA testing is to ensure that the product functions as the functional specification and documentation says it should.
That means DVT first tests each operation, each feature, and each option on each environment with a variety of recognized and accepted test data sets. Not only are DVT testers looking for proper operation with proper data, but also proper operation with bad data. In other words, do the error-catching routines actually catch errors? If there is a sequencing error, is it reported properly? Recovered from properly?In many DVT environments, the test conditions are required, to the best of the DVT system's ability, to test all of the code, using profiling and test coverage tools to indicate when each path has been checked.
Like development, design verification and test (DVT) and product quality assurance have as many levels of abstraction as your typical development effort. Properly structured testing looks at the major stuff first, options next, and then they go for the anomolies. Indeed, in the DVT efforts I have managed, the checkout of a software change required the "20-minute test", the "3-hour test", and the "24-hour test" before I would approve the change to be part of a release candidate subject to full regression testing. (From project to project, the actual length of time taken for each of these tests differed, but the names stuck.)
The second goal of DVT/QA testing is to find operational problems in-house before the customer finds them in the field.
This is the time when testers "bang on the product" to determine if there are any weaknesses or coupling effects. The best testing is when you have a good number of alpha testers that use the product in the manner it was intended to be used, followed by a good-sized group of beta testers. Beta test management is an art unto itself, with the most important function being the selection of the beta testers themselves. Some companies miss the boat by only soliciting one type of beta tester. The best beta programs court fringe users, those who would use the product in unusual ways, in order to ferret out more error conditions.Frankly, I find development easier to do than testing, but testing is to me the more satisfying activity...especially when my efforts expose some really funny cascades.
There is a third aspect to testing that doesn't get much play in companies: reproducing field problems. I have some war stories if someone serves up the beer...
This is probably a good time in this thread to throw out an allied problem: what happens when management doesn't like the results of the bug evaluation.
True story: a corporate-wide standard for bug determination was defined in a Fortune-50 corporation. In a project, though, the director of engineering decided that the standards "didn't reflect reality" -- or rather, that the numbers made him look bad. It also meant that there was no way he would be able to ship the product on time, because the number of ship-block bugs was just too high for his development staff to clear in a manner acceptible to him and to his superiors.
Now, the definition was pretty strict: Severity 1 bugs were features in the specification that were implemented and broken in significant ways, severity 2 were features in the specification that were implemented and met the operational requirements but not performance requirements, or were not implemented and marked in the specification as required for release, severity 3 were features that were implemented but broken in non-significant ways (cosmetics, usually) or features in the spec that were not implemented and marked as not required for current release, severity 4 were features that met spec but were identified as areas for improvement, and severity 5 were spec change requests. The rule is that the product MUST NOT ship with severity 1 bugs, SHOULD NOT ship with severity 2 bugs (release required a review and analysis of each S2 bug by corporate QA), MAY ship with severity 3 bugs, and MUST ship with priority 4 and 5 bugs.
So, Job One for this manager was to pull a Captain Kirk and change the rules. Severity 1 was redefined as "causing a system crash". Severity 2 was redefined to "causing an operation failure that does not result in a system crash". Severity 3 was everything else that used to be in S1 and S2, as well as what was originall in S3. That meant that missing or severely broken features identified as required for release obtained an S3 rating instead of the original S1 or S2 rating. Or, in other words, a broken product could now be shipped!
Of course, it didn't do very well in the market, but the manager in question still got his raise -- and I suspect that's all he cared about.
The root cause of this breakdown was that QA/DVT was an Engineering function, not a separate function. The guy saying "no" should be a peer to the guy saying "yes". (It would have helped if the original bug definitions would have been part of the specification, because the spec is king within this company -- but that didn't happen.)
There are a number of us who listen to Harris Miller, President, Information Technology Assocation of America tell the Congress that "425,000 job will remain unfilled during 2001." I (and many others on /.) wrote Mr. Miller asking him to convey our desire to take a shot at some of those 425,000 jobs.
I sent that letter on 2 April. I have yet to hear from Mr. Miller, the ITAA, any of the 2,500 member companies, or any headhunter about any of those 425,000 job positions.
How about you, Mr. Anonymous Coward? Do you really want to find qualified people? If so, drop a line -- I don't hide behind an AC name. In fact, to make it easy, here is my e-mail address in easily-clickable form.
When was the last time Intel hired a technical person in the over-40 age group? When was the last time you did?
winmail.dat...when are we going to get rid of it?
I spent a half-day looking for information about winmail.dat and found it. As a result, I now have a little tool that picks apart winmail.dat files. If moderators show interest by modding up this post, I'll even make it available under the GNU license.
I have several clients who send me crap in winmail.dat, so I'm glad I have the tool.
(I am not a lawyer)
I like this one. Rather than go one-on-one with the DC people with regards to the patents, it does an end-run by expanding the scope of the information returned. In my reading of the various patents, this goes beyond the four corners of the claims by looking up "dirt" as well as serving up the direct link.
Will K&K go after these people? I suspect so. The idea of doing a search on the domain name coupled with derogatory terms isn't covered by the claims of the DC patents, but it would serve to dilute the value of Cues, and so DC may launch a pre-emptive strike.
Now, these people would be well served to file a patent on the idea, to protect them from claims of infringement...
PigleT sez: "Bullshit. How the heck can a kernel be released `late'?? ... As it is, 2.4.3 has been around since Mar 30; I don't see why one package can't get a proper testing in that amount of time. "
18 days? For a package which requires multiple CD-ROMs to distribute? Especially one as complex as a Unix distribution? Do you have any idea how many opportunities there are for unfortunate interactions? No, let me make this stronger: what qualifications do you have in the field of software design and verification testing, PigleT?
When I was managing DVT for a single product of 45,000 lines of code, the entire testing suite required about 40 days to complete...if there wasn't a problem. Final verification after "the last bug fix" required 10 days. By the way, "day" was defined as 24 hours, and included weekends and holidays, using as much automation as we could muster. The crew was nine people full-time, and about 100 alpha testers, as well as a development corps of about 20 programmers who had their own, separately-developed DVT for design changes.
In some respects, testing a well-designed and well-implemented operating system is easier, because you have far more separation of function; in some respects an OS is far harder because of the unfortunate unforseen interactions that can crop up in any co-ordinated resource management system. Further complicating the DVT of an OS is that the problem set is not under the control of the developing company -- you have applications programs that delight in tripping up even the most careful of OS writers.
Red Hat is trying to sell a supported solution to non-geeks, and in particular to companies more interested in doing what they do -- be that selling toothbrushes, building cars, collecting taxes, shooting metal objects into space, curing cancer -- and not have to worry about every little thing about the OS they are running. In order to meet the needs of their target customers, they have to tread cautiously when putting together their distribution. Like Microsoft, they need to control the cost of technical support, and one way to do that is to test the hell out of the product before putting their name on it. That's the way they decided to do business.
Don't like it? Then go use Debian unstable for all your mission-critical projects. When it breaks, call Debian, not Red Hat.
It's your choice.
Hey, there are libraries that manage to avoid C++ constructs to abstract this sort of stuff. For example, B-tree operators could use a fixed structure in which there exists the data fields necessary for the library to do its thing, and the "payload" of the structure is a void pointer to the data referenced by the B-tree node. This means that you can have disk-resident B-trees by using the void pointer to refer instead to a byte offset; array-resident B-trees by using the void pointer to hold an index; value-oriented B-trees by having an integer value in the void pointer.
For type purity, you could use an embedded structure definition for the B-tree elements, and the payload would be in the rest of the embedding structure. The B-tree routines would then use appropriate pointers to do its thing.
As you can probably tell, I tend to think C instead of C++ because most of my programming involves real-time processing. I don't like it when a language does things "behind my back" -- sometimes it's a good thing, sometimes it causes bugs that are impossible to find because of this sort of thing.
Oh, I don't mind C++ for computational stuff, but it's been so long since I've done something that's "merely" computational that I don't bother to hone the C++ skills I pick up each time I get these rare projects.
YMMV
Of all the holy wars, this is the one that makes the least sense to me. One of the reasons we have tools is to make such useless pablum as unnecessary as possible.
Now, I speak as one who publishes source code on a regular basis, and finds that Mr. Torvald's edict works when editing but sucks when you are trying to publish on page. Never mind the fights with the "professional" graphic artists who don't understand the readers' needs, the rules according to Torvalds do not work on the published page. Witness Don Knuth's comments about white space management with respect to WEB source.
So let people do it the way they want. Tabs at 8? Tabs at 4? Spaces? No tabs at all? Fine. When you are done with the code, run it through indent(1) with the shop standard specification and be done with it.
And when I decide to write a book chapter using your Open Source code, I'll use my own configuration to make it easier to deal with on the printed page.
Oh, you want to know my standard? Just remember, you asked for it...
Courier 72 with monospacing, with a 66% set width
Braces on their own lines
Open and close braces at the same indent as the enclosed text
Each indent is equal to the type height, which is identical to a M-space followed by an N-space at the 66% setwidth, or an M-space if you ignore setwidth
bolding all appropriate keywords and certain macro variable names
Here is an approximate example (lack of proper typesetting controls in HTML prevent an exact depiction):
If you have a number of "parallel" calculations or procedures to perform, nothing beats a good implementation of co-routines, hunks of code that are called from a master scheduler or process loop. When done correctly, the response time of a co-routine implementation can be better than a multi-threaded implementation because the operating system never has to worry about context switching.
Now, that doesn't mean that threads don't have their place. In my programs, the only use for threads (or processes, for that matter) is real-time I/O monitoring, and I do the absolute minimum I can in each thread/process so as to avoid tromping on shared variables. Everything else is under the control of the main program.
The primary purposes for forking is when you are dealing with human-time activities -- that's one reason that some Web servers will fork a process to handle a request, so that each user sees some response early. Another good reason to fork is to reduce the number of file pointers that have to be monitored. (There has been discussion of this in a number of different places.)
Just remember that threading imposes an overhead that you may be ill able to afford. Within embedded systems with real-time implications (single-CPU modems are a great example) the allocation of time is critical to balance the need to stream data with the absolute requirement to maintain synchronization with the modem line.
I believe you will also find that an appropriate co-routine implementation is much easier to debug, because the time relationships between the routines is strictly controlled by the routines themselves -- it is very easy to implement "critical path" segments without the use of semaphores or other tricks.
The down side? In real-time applications, the key to successfully using co-routines is to design each co-routine to do a useful amount of work without hogging the CPU and still relinquish control often enough to let other time-critical routines run appropriately. Judicious use of event trigger flags set by interrupts and periodically tested by your co-routines can ease this task. The same can be done in Unix applications with judicious implementation of signal-based I/O.
One aspect of co-routine implementation coupled with the correct use of select() timeouts is that it becomes very simple to implement an "I'm-sane" indicator in the user interface, reassuring your user that just because nothing appears to be happening doesn't mean the program is napping on the job.