No, what they are told is going to happen in the future, sometimes doesn't match what happens in the future. Ballot faces are changed, after they are supposed to be frozen. The layout and configuration of the ballots change up until pretty late in the game.
I'm not sure if the certification testing happens with this year's final ballots (I'm not sure I ever even implied it, if I did, I was wrong). They test with a plausible ballot face, or the previous years ballot face. The timing is all wrong. Things can be added to a ballot up until after the software is supposed to be certified. So a late addition to a ballot can cause a configuration change to the ballot face (which is just input into the software), as opposed to swapping out the code that do the actual counting.
However, I believe that there are cases where the certified, frozen configuration had to be changed, because the actual ballot faces were printed incorrectly (the spacing was off). Not sure whose fault it was. I can't remember who prints them (it might be ES&S, but I don't think so). Given that it was figured out two days before the vote, they changed the electronic ballot configuration. They couldn't reprint, and re-distribute all of the corrected ballots to match the software. As their was no typographical mistakes, they switched ballot face configuration in the machine.
I'll have to ask the guys about it the specific situations you talk about.
Okay, where is the evidence that Hagel directly affect the outcome of a vote? Until then, it's merely a conspiracy theory to me (that he didn't register it is a fact, that this somehow implies he's done something improper to affect the outcome of a vote is a conspiracy theory). That's my standard, you can have yours. I'll call it scrutiny if you like. I've never met Chuck Hagel, I've never voted for him, I don't know anything about his politics. It would seem dubious that he didn't say he worked for AIS. Not sure of any good reason who wouldn't say it. However, you'll need something better then that, to convince me anything wrong happened.
I don't trust any system that doesn't have paper ballots. I've never worked on one, I think they are a crock. Never, ever trust a non-paper ballot system. Okay, it doesn't have to be non-paper, but if it doesn't have something that is physically token based, there is a problem with it. I've never, ever worked one of those. I've never seen one that worked that way, I'm not sure how the audit trail works on one of those. I don't need to see the code to say, that they can't be trusted.
They can't have an acceptable audit trail in my opinion. I'll back you as far as you want, if you have a petition to sign to have the laws/rules changed, post the URL, I'll sign it, or physically send you a letter attesting to that fact.
Sure, you can have a trigger, however, I believe a number of people review the actual honest to goodness code. They might, not, but that's not the fault of the companies that do it, it's the fault of the FEC to not do the testing, and to not ensure the testing is done properly. I've always been told they had good rules. They might not be enforcing them.
As I've said in another post, I've never seen how they handle the build configuration managment. That would be my largest concern. Who does the final build, and certifing that the build is from auditted source would be the trickest part. I never was clear on who did that. I always thought ES&S sends the final build machine, and they put the auditted source on. Which I could tamper with the build configuration at that point. Who built the final build machine? Who provided the install media for the toolchain, and the instructions for such an event? How would you verify it, given that a lot of that can't be rebuilt or verified as an exact duplicate (timestamps and other nigling little issues would pop up). It isn't an exact science building software.
Could be. I'll have to ask the guys. I know they've had some fiascos before. When I was there, all I can tell you is they worked hard at it, and had pretty strict rules about how everything had to be done according to procedure. If I didn't follow procedure, I had to fix it, following procedure. It's been a while, now so things might have changed.
I'm not sure what happens on election day, I wasn't high enough of the food chain to be called in for all that. They told me, they had a certification date, that had to be met. I never knew what happened if that date was missed (always wondered about that).
Might be a problem on replacing chips. I knew they had bad ballot layouts that had to be fixed, and they've had ballot faces. The printed ballot faces don't match the ballot layout specification on the chip, because somebody changed the printing on them. Or from the they we're told the ballot face was from the previous year.
Well, as a person who actually had to go re-write code because it didn't meet the standards. I'm reasonably sure they did in fact look at some of the code.
I know they send test ballots thru. I was there, I've had to run the test sets thru to verify the code personally. I was told the FEC runs them thru and certifies it (they might outsource it, I wasn't high enough of the food chain to know). I didn't actually see that happen personally. I was told by several people it did, and I was given test batches of certified ballots with accurate counts to test with.
It was a big deal, and it was a pain in the ass by all measures.
Sorry, I don't know a darn thing about Diebold. I've personally worked, and been thru the testing system they have at ES&S. The article I read, had a conspiracy theory involving the former CEO, the local paper, and major corporations. There had to be a something, but the World Herald wouldn't write about it because they shared similar owners. I got about halfway thru and stopped reading when the smoking gun was, a local politician is part owner of several corporations locally, and well the local paper wouldn't report on it. That's a sign that there is no story there, otherwise somebody would have quit, and written gone public on the matter.
I eat lunch every couple of months with several of the people whom are sent onsite to be there for the onsite support. They are good honest people. They have talked me thru what is the procedure for deploying the systems. It seems reasonable to me. I've read the code that does the ballot counting, I've written the code that does the ballot scanning. Sorry, your hard data might in fact be accurate for Diebold, but ES&S was pretty serious about security and accuracy of the machines when I was there 4 or 5 years ago.
In reality, at least on they systems I worked on, at no point do you have to trust me, or the systems to work. The votes are on paper, and can be hand counted. The electronic system is there for a quick count, and to gather some statistics that would be incredibly laborious if you had to do it by hand. I believe any registered candidate can request a hand recount at nearly every election level in this country. It might have to be reasonably close, but I believe with a court order, a recount could be forced.
Having been on the inside, and seen what the code goes thru, I'd be a lot more worried about the human chain of trust. As soon as you let the voting machine out of your sight, or you let someone else manipulate it, you can no longer trust the machine. Only a single person at a time, can truly trust a machine. The process of letting you verify it, makes me believe it is no longer trustworthy.
You don't have to take my word on it. Go lookup the FEC standards. The standard are not verified by me, or any member of the ES&S company (okay they are, but the FEC re-verifies it independently). The FEC has a very specific set of standards thru with all software must pass to be used in a Federal Election. The first being to run a set of known ballots thru the system, and to do an complete audit of the software to ensure it meets the coding guidelines.
The black box testing is pretty complete, and very good. You set the time and date to the time and date of the vote. You bring in a set of ballots that is larger then any single machine will be expected to process. You run the complete ballot set. At that point, the machines are in all ways, exactly as they will be when shipped out. You read the code from start to finish.
What else do you want? You've got a known regression test, in the precise conditions that will be shipped. At that point, it's merely user error that can happen (or procedure wasn't followed). What can you do to ensure end to end integrity at that point? Sure you can verify that a particular machine is correct, no problem. They send out 1500 machines to different voting centers. How do you plan on using the source code to verify that all 1500 machines have the proper configuration, that they have the proper software, and the hardware is properly configured. Yes you can verify that a single sample you saw at a given moment in time was configured as per the specification, however, open sourcing it, won't allow you to verify the machines at the time they are used. If you don't trust it, count the ballots. The ballots are right there, there is nothing more to subvert them that couldn't happen in a stardard paper vote.
The standards exist, and they are transparent. If you'd like to check them, go pick up a machine from the ES&S, and test it. If believe that the FEC's guidelines are insufficient, lobby to have them changed.
If you want to do the check, lobby to be there when the FEC does the test ballot sets. Examine the test sets, and verify the results of the test. Bring your own set of test ballots and request to test them against a sample machine. It's not like you need the source to do any of it. Buy a machine, set the time on the machine to the day of the vote, then run them. Then re-run them over a period of days while the machine is left on, or turned off to simulate the situation you desire.
Run the precisely as they would be on the election day. Simulate the tests with known results (I don't believe the all test sets are known by ES&S). Submit random tests to which you have the answer. Submit a test deck that has ever known pattern filled in for the upcoming election.
Then aquire a cryptocryphic checksum of your choice, that you believe at a later date you will be able to verify while voting. How you do that, without actually running the ballot voting machine, I don't know. At some point, the people who are running the voting machines must be trusted. If you can't trust them, you can't have a legitimate vote. It's the same reason why FPS will have always have cheats. It's inherint in the system, that an uncontrolled quatity exists, and can subvert the system because it has too much access, and information to make it look like everything is as it normally would be.
You can't have trust at any level. Anything that you didn't personally do, isn't trustable. As soon as a voting machine leaves your sight, it's absolutely not trustworthy any more. You can't watch anyone do the work (I've seen too many people who are good a slight of hand). You have to absolutely verify so many things, that it isn't trust worthy. Actually, as I recall, they wrap, and lock the machines, so there can't be any tampering.
Do you trust Linux? How do you think it has no bugs in it? I've hit known bugs in it. How do you know that the version of Linux you use, is the version that Linus ships? How do you know that the Re
Incremental Backups aren't anybody's focus there. Their focus is voting machines. I've known plenty of guys who are great at building funiture to an exact spec, I never assumed it meant they we're good at assembling computers. Losing a development copy isn't really a problem, other then they have to rewrite the software. That's merely a matter of money. That doesn't affect the trustworthyness at all (in terms of accurate voting tallys), I might not trust them with my data, but I'd be really sure the vote will be accurate. Einstein, according to legend, couldn't do basic algebra. However, that didn't keep him from unlocking fundamental secrets of the universe.
Well, actually them losing their backups has zero to do with their ability to deal with certification. The guys who write code, didn't lose the backups. The SysAdmin did. Those people have zero to do with the certification process, or with anything involved in it. Oh, and until you've done backups for say 5 years, and never lost one, I wouldn't say somebody who lost 6 weeks of backups is a tard unconditionally. Dealing with backups is a pain in the ass. The tapes went bad, or got destroyed, or something. Accidents happen. 6 weeks is probably a bit too much, you probably shouldn't ever lose more then a couple of days, maybe a week. They had a backup, just not a particularly recent one. The nature of backups is that you have to assume some will be bad, and have a plan to deal with bad backups. Then make sure that the cost of having more redundancy costs more then the fallout of not having the backup.
I can tell you why the 200 line limit is there, the guys at the FEC say those are the rules. You don't get to ask them why. You don't get to change the rules. The rules are imposed on you. It's a lot like living with your parents...:-) You want to do business with them, you absolutely follow the rules. The rules cannot be questioned. They are the one true set of rules. Sorry it's the gov't, that's how they work. All the guys who worked on it thought it was stupid. However, that's what Software Engineering said was a "best practice" at the FEC.
If I was really worried about it, I'd have to start to question, Watcom (the compiler maker), QNX (the people who made the QNX4 OS), the company I used to work for, the Intel chip, the company that made the compiler that Watcom originally bootstrapped their compiler from. The original QNX2 OS. The guys who made the Flash chips. The people who laid out the ballot. Just by switching the wording, or the layout of a ballot could easily affect the outcome of a vote.
I'd be more worried about if the people at the FEC used proper cryptographic check sums to ensure the integerity of the software. That the FEC could verify that the changes sent over, were in fact that only changes made. That the FEC had a proper build environment, and that they re-built the software, and just didn't trust the binaries they were given, are actually the generated by the source they have, and that they matched the binaries given to them by the user (modulo date stamps in the binaries). I believe the FEC did do a clean rebuild, however, I'm not sure who setup the build environment (I could setup a build environment that sneakily patched the software after the checksum had been matched). If they did cryptographic checksums and stored them in the results of each vote, so that each voter could be assured that their vote was handled by the software the FEC thought it was.
All that was out of my hands. I didn't do CM for them, and I only handled details dealing with turning black and white marks into votes, and non-votes for them. All of the talling, and other routines weren't my deal. That the people at the voting centers were not stuffing ballots. That the paper ballots were not tampered with, or willfully destoryed (always curious what they do, when if a fire happened and it destoryed all of the ballots before they got counted). Voting is a very, very tricky thing. You can't ever trust any mechnical device, or any electronic device, unless you built it from scratch. You'd have to verify everything from scratch in order to trust it. I mean the motherboard, the BIOS, the keyboard, the RAM, the CPU, the NIC, the disk subsystem, the bus, all of it, to be any more sure of it, then you by just running all of the ballots thru, and doing black box testing on it. Verifying the source, won't do you any good, unless you also verify the build environment, and verify the binaries, and very the hardware configuration of the final voting machines. Oh, now you have to trust all of the people at the FEC who do the verification. Which gets you back to square one again... Until a voter can ensure the setup of the machine, in a trustworthy way, your screwed. An the voter can't, if there is enough collusion going on at high enough levels in the verification process.
I've done contract work for ES&S (actually most of the work I did for them was when they we're know as AIS). I've seen what they get to do for verification. Trust me, somebody reads every single line of code there is. They have specific rules, and very rigorus tests the machines get put thru. I worked for the guy who did most of the original coding for the E100. I helped to start the port for the E500, which turned into the E600 model. Actually I started to finish the port. It was originally in Z80 assembly, they completely ported it to C, and they lost the machine, and all the backups from about 6 weeks before it finished. I was the first guy to start finishing the port.
The company I worked for did all of the original design assembly of the PCB boards.
Everything is done on paper (on those models, I hear they have other electronic only models). So it is completely auditable via a recount. The Federal Election Commision certifies the software and the hardware as fit for use. Once certified, no changes can take place without a re-certification, and justification for all changes made.
They use QNX as their base operating system, and use essentially fax based technology inside the system. They scan it using the fax scanner, using timing bars to tell where the bubbles are. They then read the black/white values using an A/D converter (at some point, they switched to infrared technology instead of fax technology). Each machine gets fed test sets of thousands of ballots ( I want to say over 100,000 ballots go thru the system during the final testing phase). Which the exception of a mis-feed, or jam (which has to be detected), there can't be any mistakes.
They are pretty serious about it. At one point I knew every guy who did the day to day coding on the systems. They are plenty trustworthy. Maybe not coding gods, but naferious evil plots just won't happen. Sorry, take your conspiracy theories and go home.
Oh, and no one in their right mind would want to read the code. For a variety of reasons. First it's boring as hell. Second, the rules make it nearly impossible to write interesting code. All function can have on and only one return. No function can be over 200 lines long. No matter how clear the function is, it can't be longer then 200 lines. Why 200, got me, but it's the rule. There are rules against using macros, and rules about function pointers, and rules about recursion, rules about how data structures have to be stored. Rules about lots of different things. Rules about election layouts. Rules about ballot layouts. All kinds of mind numbing rules.
Open sourcing them, or making them available under NDA for a third party audit, sure seems like a good idea. However, there are plenty of safety measures in place to assure that the right things go on.
Christ the machines run while being hit by a giant as static electricity gun. (Vandigraph generator, I believe it was called).
I believe his point is that, the BSD guys might have demonstrated that AT&T derived a lot of their UNIX code base from BSD (as opposed to the other way around). If that is the case, most of the licenses paid for essentially a license to the BSD product. Which was freely available as long as you are willing to leave the copyright notices in place.
AT&T took a lot of code from BSD and stripped off the copyright notices off, and incorporated it into there codebase. There is conjecture, that the clean "rework" of UNIX that BSD did ended up getting a lot incorporated into AT&T's UNIX. BSD at some point, removed all of the original AT&T code they licensed. It's my understanding that the court agreement was there were 8 files that didn't get re-written. That's way BSD 4.4Lite is, it's the BSD source, with the 8 files removed. 386BSD is the BSD that caused the original lawsuite. It was picked up and turned into FreeBSD after the original maintainer just stopped responding to communication or releasing stuff. I'm not sure which code base NetBSD started from, and OpenBSD forked off NetBSD when Theo had his spat with the NetBSD core.
Thus it might be that SCO owns the tube of toothpaste, that the BSD guys squirted all the paste out in the early 90's. Novell could have asked to seal all the evidence, that the toothpaste is all gone. It's mostly based on urban legend, and rumor. There might be some truth to it, who knows, the documents are sealed.
I believe that's the conjecture he's talking about.
The poster missed something incredibly obvious.... All the cheap labor in India is in the same room. When 2 outsourced employees need to talk, one walks to the other. They work in the same timezone, and more then likely work in the same building.
This makes tons of stuff easier. Like oh, say, when the network is down between you and the world, you can't telecommute. The guys who all work in the same building, can probably press on, continue to have meetings, and make progress on work. Where you are stuck.
Oh, confidential paperwork doesn't leave the building. They don't need nearly as many VPN connections. There is no one making a connection from a Dynamic range of IP's that are outside of the network operations control.
Telecommuting, you aren't in the same building with 500 co-workers. Now if the started hiring lone guys, on their own island in India, yeah, you've got a point. However, your wrong, wrong, wrong.
What I really don't understand, is why they don't start transplanting business from major cities. Look, there is no god damn reason in the world you have to be in downtown SF to write software. You don't need to be in LA, SF, NY, or any other major city. You can get an amazing number of resouces in much cheaper places then a lot of companies feel they need to be in. It's just plain silly.
That's not true. I've seen any number of parts that are rated for the temperature of the room. Look at the specs on your monitor, or a DVD player. They have specific temperatures that involve appropriate temperatures for running the equipment. I've rarely seen one over 120-130F. Computers bought in a single unit, normally talk about the temperature of a room. Then engineer did all the work to figure out what the temperature of the room will mean in terms of overheating individual parts.
CPU components are rated for the appropriate temperature of the core of the CPU, specifically because they have a temperature gauge you can measure with built in.
One doesn't walk around measuring the temperature of a computer parts, one measures the ambient temperature of the room. Call Dell, tell them your running computer equipment in a room that's 120F, I'll bet they tell you the warrenty is voided. Tell them the room temperature is 90F, and I'll bet they will tell you to move it to a cooler area before they will help you trouble shoot the problem. The ambient temperature of the room dictates that temperature of the part after you've had it running for any length of time. It's simple physics.
I'm not so sure about that. A lot of stuff can be that hot, or stored in a room that gets that hot, but can't be run in ambient tempature that hot for extended periods of time. They can't dissappate heat that fast. There is a difference between approved storage tempature, and approved to run in tempature. I wouldn't run computer equipment that I cared about in a room over 80-90F. While CPU's can physically be a lot hotter, running them in a room that hot means they can't vent heat appropriately in my experience. The difference in temperature between the part, and the air around it, dictates how fast it can vent heat. So while a CPU can run while it's at 176F in the core, it generates so much heat internally, that it'd overheat if you ran it in a room that warm in a matter of minutes. There's a reason you need those big fans and large surface area heatsinks to run a CPU even in an A/C environment. The greater the difference in temparature, the faster a part can dissapate heat, which is the whole point of heatsinks and fans.
Also, it's not luck touching a lot of computer parts really makes them instantely turn to 98F, if that was true, ice would melt instanteously in your mouth. You "slowly" heat up computer parts while touching it, depending on the heat transfer constant of the part you are touching. Heat transfer is exponential, it's like half life. There is a certain period of time in which you can half the heat difference between two parts (discounting phase change). So if for a CPU, that is 1 minute. That means if the difference between the CPU and the air is 100 degrees, then you lose 50 degrees in 1 minute. Assuming nothing is heating it, you'll lose 25 degrees the next minute, and so on. However, when the CPU is running, it's getting heat added to it at the same time. The tempature stablizes when the CPU is adding the same amount of heat that it dissapates per unit time. So having the room tempature significantely lower then the rated temperature the part can run at is very important.
No, but the standard stock frozen H2O type does in fact melt into water (I mentioned regular ice in the previous sentence, I only mentioned dry ice because the poster said something about it)... I wouldn't use dry ice, but that's just me. I can get straight regular honest to god frozen water, at the local gas station about 200 feet away from the building. We told them to fire up the ice maker, and we'd keep coming back for more. We had concerns about humitidy, but figured that if we kept enough airflow in the room, eventaually the himidity would follow the airflow out.
I'm not sure what property dry ice has that makes it more compelling then water. In this case, I want the damn stuff to melt to absorb the energy. Having it turn into water is something I can deal with. Having to deal with not breathing in a server room, just seems silly to me.
Okay, we had the AC to a our server room blow out. Two things, first, get plent of airflow into the room... Second, get more airflow into the room. If you have to use dry ice, or just plain ice in buckets. We put holes in the buckets, and let it drain out the floor (you've got a drain right?).
Heat rises. So you can keep the tempature of the room close to the ambient tempature of the rest of the building by getting enough airflow, and creating a way for the heat to escape up out of the room. Not sure how your server room is built, but create as many large holes as you can moving the air up outside the room. I saw a room drop 6 deg F, in about 20 minutes by removing all the ceiling tiles.
Oh, and get incredible airflow over the equipment. Ensure the air is circulating over the actual equipment, so the really hot compenents have a chance to pass the energy on to the cooler airflow, thus cooling the compenents. You don't want hot pockets of air right around the computers.
Now, the ambient tempature isn't exactly great from your remarks. Most computer equipment is rated to run up to 80-90F. So you might be able to get by for a couple of days. If not, read up on how A/C works, and how old time A/C works. Build something that works on the same princepal. Got me what it is, but I'm fairly sure using cold water as a heat exchange to literally carry the excess kinetic energy out of the room is your best bet short of finding an alternative source of power.
I worked for a small company at one point, that was the POP for a bunch of dialup equipment for an ISP based in another city 60 miles away. Since they had dedicated T1 equipment between their two sites, and the expertise to setup voice lines between the two, they setup a voice line that could make a long distance call over their lines for free. They made it available to all of the employees who worked for our small company. A lot of our employees commuted from one city to the other, which is how we ended up with their equipment in our space. One of the owners commuted, and at one point nearly became a partner in the ISP, but instead he just put the equipment in our racks.
Well, it turns out that, if you over phone service to anyone, even for free, especially long distance, guess what, you have to pay various taxes. Even if you don't make the customer pay, your still have to pay the taxes to the local and state gov'ts.
So in the end, you'll end up doing more paperwork, crapola then it's worth to setup your own phone service over your own phone lines. So your options are pay the phone company to run them for you, or pay them to provide the lines you hook up to your own phone. I'm not sure what the cost of buying a pay phone is, or what the cost of a business phone in your are is (it's about $50-75 a month here). So if you think the phones will average less then $75-$100 a month in damage, it's a win to own your own phones. If you think they will average more then that, it's a losing proposition to own your own.
Personally, if it was a fixed cost $150 a month, they have to replace damanged phones, your absolutely nuts not to take them up on it. About the only options are to not provide phones at all, or to literally let them use one of your phones, either a cell, or a land line based in an office.
Hmmm, the poster says, "the regular 8 cents a share dividend". Uhh, didn't Microsoft just pay it's first dividend in the last 12 months. I don't believe they've paid out more then 4 of them, I'm reasonably sure they have only made one dividend payment in their entire corporate history. I'm too lazy to go track down the Slashdot story or the SEC filing on the matter.
Now that there is no dividend tax and Microsoft is no longer a growth company, there isn't any good reason not to pay the stockholders. When there was a dividend tax, Microsoft could argue that by keeping the money, they could put it to more efficient use to build stockholder value in terms of share value, rather then giving some of it to the stockholder, and some of it for the gov't. The other point is, that Microsoft is done growing by leaps and bounds. They don't need any more capital to grow, or smooth out cashflow issues, or any other standard business reason why a company normally keeps money cash on hand.
I believe the shareholders are starting to demand it, as that's the one way the shareholders can get their money out, without having the price go up or down. It's a sign that Microsoft is turning into an old school established company, like so many others, rather then being a hot commodity stock that creates value, because the company keeps growing, and building up more value.
Uhh, I make a living knowing a lot about parcel carriers. Essentially, they all lose stuff, they all delivery it late. UPS is cheaper then FedEx, Airborne will probably be more expensive then UPS (Airborne can beat everybody if the weight is less then 5-8lbs as a general rule).
Airborne is late more often the FedEx who is late more often then UPS. Personally, I'd ship it UPS, and add $3K in insurance. I'd ship it ground, (it'll probably end up on a plane, but if you can deal with not having it for 5-6 days it's a lot cheaper).
Get it ensured. Keep the insurance slip. Make sure it's a must be signed for shipment, and call UPS to have it be arrange for pickup if you don't get it the first time they attempt to deliver it.
If it's not there, and you don't have a note, call UPS. Check the website.
If it's not there within 3 business days of the scheduled delivery date, you are screwed, call UPS, file a tracer. Start the process of getting your insurance money.
Every Tom, Dick and Harry on here is going to tell you their personal story about how they got screwed by carrier X, and how they will never use carrier X again. They think the carrier has some personal vendetta. It's comical. All of the carriers move millions of items a week. An success rate of 5 9's, still means a lot of screw ups a week. Make sure you have the documentation, make sure you take care of it quickly, make sure you follow up with them. You can successfully get your refund if it gets lost or damaged, sometimes it takes a little while, if you can't deal with that rent a car, drive the damn thing.
I've got 3 maybe 5 if you count the ones at work that have exactly the same problem. I've got two of the entry 4 ports, a 2x8 matrix stacked with another 2x8 matrix, and a 4 port pro from belkin. All of them have exactly the problem you describe under Linux (various flavors of RedHat).
There are two things to check, first turn off gpm. It's never done anything but give me grief in all the time I've ever seen turned on. I know that this will solve problems on several different KVM's I have. I know on one of the KVM's, it fixed all my problems so I could use the IMPS driver without doing the second fix.
Second, is that something is completely screwed about XFree86 of handling the PS2 mice, you can switch to a serial mouse, but no wheel then. The way to fix the problem, is to get XFree86 to resync/reset with the mouse. After switching from once machine to the next, immediately switch to a virtual console, then back to X, and the PS2 drivers will resync/reset/"do the magic to make it go". I've got no idea what the problem is, or why switching consoles works, but on the various Belkin Switches I've seen that is the fix that works best.
Hmmm, that's why most serious clusters are built out of state of the are Dual Processor boards loaded with highend Xeon chips. Clusters aren't a "gimmick". There are some people who want to build one that have no use for it. How's that any different the car junkie who soups up his 1970's muscle car? It's just a gimmick. There's really no need to put a 500HP engine in it, no need to get it new paint, new tires, or a turbo, or a new dual exhaust system. It's just fun for them.
However, there are good uses for modification of vehicles, like say air bags. I don't call air bags, gimmicks, just because I think that guys who put dual exhaust systems on a 20 year old car seem like they are wasting money to me.
However, in terms of redundancy, your far, far better off with 10 P3 500's, then with one P4 5Ghz machine. One of the PIII's is having problems, shut if off, run the diagnostics. The P4 has problems, you shut if off, you are in deep shit.
If I had my choice, I'd rather have a cluster of 5-10 well built, redundant machines then one machine 10 times as fast for any problem that can easily be distributed (think websites, DNS, mail servers).
No, I don't want to use 10, 3 year old Dell workstations to serve up my enterprise website, but I wouldn't have any objections to 10 Dell Servers that were bleeding edge 3 years ago assuming it uses parts that are still commonly available.
If the MD5 sums don't match, then the code can't match, if the MD5 sums do match, then check to see if those sections do in fact actually match.
My only beef with this methodology, is that several obvious things should be applied, including stripping leading white space. I copy code and indent it futher then the original block. Turn tabs into whitespace, and then run collapse adjacent spaces into a single space.
Possibly run it thru a good code beatifier to get it all in a single coding style after stripping comments to look for additional possible matches. Really run it thru the ringer, looking for possible matches, then check have experts inspect the possible matches.
First, the async, means that not all reads and writes are syncronous which is an incredibly good thing for speed. Try putting your UFS/FFS filesystem into fully sync mode and then talk about performance, I'm willing to bet that UFS/FFS isn't sync by default either. However, calling fsync in the mail server (normally sendmail) in Linux will actually make it sync before returning. So no worries about RFC 1123. It's the SMTP server's job to ensure that it tells the filesystem, make sure the bits are on the disk. If Linux didn't have the ability to ensure bits where actually on the disk nobody would use it. That's why in Moshe Bar's series comparing Linux, FreeBSD, and OS X, he always said he recompiled after removing the fsync calls, otherwise you just compared how fast the disks in each system were.
For goodness sakes, Oracle ships on Linux, if Linux couldn't get the bits on the disk Oracle would have never ported to it. Not a chance. If Linux tells you the bits are on the disk, they are on the disk in my experience.
I've heard of people losing UFS filesystems while running them under NFS, or losing them due to any number of naferious VM race conditions. So what? Welcome to the real world, people lose data, buy a tape drive, make backups. Knew a guy who got really good at rebuilding filesystems by using dd on Solaris to recover email for customers.
Oh, and as I recall, async actually affects directories more then files, if you put the sync modifier on the filesystem, it only affects directories, not the file data for ext2/3. In ext3, directory writes are always journaled as I recall, so it shouldn't make much difference.
Now, from what I've heard of Linux and FreeBSD, is that until the late 2.2.X and early 2.4.X, there we're certain jobs Linux couldn't do like run big Usenet News services, or really disk intensive applications they the filesystem buffering was really hard to get right, and might cause corruption. The guy who ran a local ISP always said FreeBSD never did that when he was running the Usenet server on it, but Linux did with some regularity.
ext2 hasn't lot any data of mine in my 7 years of using Linux, including running a 120GB Oracle Database for the past 30 months. Ext3's never lost any data since I started using it. I've lost disk drives, I've lost mirrors, I've lost files, never lost a complete ext2 filesystem unless the disk just stopped spinning. Lost a couple of ReiserFS filesystems after installing RedHat7.0. Never tried most of the other journalling filesystems.
Well yes and no. Having modules does not make you not a monolithic kernel. Micro kernels aren't terribly well defined, but QNX doesn't do loadable "modules", like Linux does. In QNX, the modules are generally completely independent of the kernel. The micro kernel in QNX 4 did roughly this:
Message passing,
Process scheduling,
Address space management.
Setup the timing hardware on the ISR.
That's it. The serial driver, done in a process. The keyboard, floppy, IDE, SCSI driver, done in a process. About the only piece of hardware you didn't control in user space was the PIC interrupt processor. Other then that, all interrupts did was call user process-space callbacks.
In Linux, if your IDE driver dies the whole system could lock up. In QNX4, if your IDE driver dies, the only reason your system will lock up, is because you application locks up on failure to write to the filesystem, or the hardware goes crazy. If the CPU works, and the RAM chips don't get hit by gamma rays to cause inadvertant bit flips, QNX will in fact work. Period. Full stop, end of discussion. That's why most applications on QNX use no moving parts, so there is an extremely low likelyhood of failure after running burn in tests on the hardware.
Now, Linux on the other hand, I've seen the SCSI drivers on it, where a single SCSI card will fail, and the identical SCSI card that works fine will have it's driver lock up because the other piece of hardware failed, which creates a situation where RAID 1 won't continue working, so the filesystem fails, which causes an ext3 journalling error, which then causes your kernal to panic. That wouldn't happen under QNX4.
Can I call Bullshit on you? As I worked for the first QNX reseller in the United States, I've never worked on QNX 6, but I did a lot of work on QNX 4, and did a bit of porting work from QNX 2 -> QNX 4. I've stayed in touch with some friends there, and they did a lot of the work of writing certain portions of the QNX 4 compatibility layer for QNX 6.
What security problems did you have?
There are 2 that I know of offhand. First, they used a reversible hash for passwords, or they used one that was trival to brute force. It's my understanding that breaking a password on QNX is relatively simple. Second, if you are user X on a given machine, you are user X on all of the machines when you are using the QNX networking.
QNX isn't meant to be an on the public Internet OS. It's meant to be used in a closed loop networking environment when in production use. Don't configure anyone else as on your QNX network, and the problem is solved.
2. Networking was trivial. The damn network just worked, the biggest trick was coordinating who had what node number. It worked all the time once you got is correctly configured. It always worked. Other then getting the TCP/IP stack installed which took the sacrifice of a small fury animal, and asking my co-worker Bob how to do it. Once it was configured and running, it was trivial, it always worked without fail on the machines I used.
IPC, was cake. It was stock off the shelf redevous style message passing. About the trickest thing there was calling returning a negative value from a inside of a interrupt service routine (not the real ISR, because you should never reprogram the ISR's, but the function you registered to be called when an interrupt happened), that would call issue a Trigger. That was a little weird. The networking itself was simple. Here's the buffer with the message, here's who I want it passed to, call the send message API. Done.
Now, the style you had to use was a little awkward, because you blocked on a receive message call. However, that was a function on the hard real time requirement of processing a message. You could use stock TCP/IP functionality if you wanted to. They had the standard UNIX sockets as I recall. The had shared memory (in fact shared memory was how they implemented all of the Dev Server functionality). I can't remember if it did stock UNIX signals (I'm pretty sure it did). However, you never needed to use those, you could send real QNX messages, which was orders of magnitude easier.
Now, if you want to bitch about the structure of the Photon programs I understand. If you want to bitch about the lack of a number of highly useful utilities, and that all things are freeze/PAX encoded instead of TAR'ed, I'd agree. Networking isn't a problem. IPC is the core of the entire OS, that's literally how it implements everything. Everytime you call open/read/write, a message gets sent to the process that is registered to handle calls to that. I know this because I write a RAM disk buffer as a proof of concept that we could re-implement chunks of the OS if we needed to. Message passing and IPC are what QNX excels at. It's security model is that, don't use it when it's connected to something that isn't trustworthy.
Slashdot Mirror
I'm not sure if the certification testing happens with this year's final ballots (I'm not sure I ever even implied it, if I did, I was wrong). They test with a plausible ballot face, or the previous years ballot face. The timing is all wrong. Things can be added to a ballot up until after the software is supposed to be certified. So a late addition to a ballot can cause a configuration change to the ballot face (which is just input into the software), as opposed to swapping out the code that do the actual counting.
However, I believe that there are cases where the certified, frozen configuration had to be changed, because the actual ballot faces were printed incorrectly (the spacing was off). Not sure whose fault it was. I can't remember who prints them (it might be ES&S, but I don't think so). Given that it was figured out two days before the vote, they changed the electronic ballot configuration. They couldn't reprint, and re-distribute all of the corrected ballots to match the software. As their was no typographical mistakes, they switched ballot face configuration in the machine.
I'll have to ask the guys about it the specific situations you talk about.
Kirby
I don't trust any system that doesn't have paper ballots. I've never worked on one, I think they are a crock. Never, ever trust a non-paper ballot system. Okay, it doesn't have to be non-paper, but if it doesn't have something that is physically token based, there is a problem with it. I've never, ever worked one of those. I've never seen one that worked that way, I'm not sure how the audit trail works on one of those. I don't need to see the code to say, that they can't be trusted.
They can't have an acceptable audit trail in my opinion. I'll back you as far as you want, if you have a petition to sign to have the laws/rules changed, post the URL, I'll sign it, or physically send you a letter attesting to that fact.
Sure, you can have a trigger, however, I believe a number of people review the actual honest to goodness code. They might, not, but that's not the fault of the companies that do it, it's the fault of the FEC to not do the testing, and to not ensure the testing is done properly. I've always been told they had good rules. They might not be enforcing them.
As I've said in another post, I've never seen how they handle the build configuration managment. That would be my largest concern. Who does the final build, and certifing that the build is from auditted source would be the trickest part. I never was clear on who did that. I always thought ES&S sends the final build machine, and they put the auditted source on. Which I could tamper with the build configuration at that point. Who built the final build machine? Who provided the install media for the toolchain, and the instructions for such an event? How would you verify it, given that a lot of that can't be rebuilt or verified as an exact duplicate (timestamps and other nigling little issues would pop up). It isn't an exact science building software.
Kirby
I'm not sure what happens on election day, I wasn't high enough of the food chain to be called in for all that. They told me, they had a certification date, that had to be met. I never knew what happened if that date was missed (always wondered about that).
Might be a problem on replacing chips. I knew they had bad ballot layouts that had to be fixed, and they've had ballot faces. The printed ballot faces don't match the ballot layout specification on the chip, because somebody changed the printing on them. Or from the they we're told the ballot face was from the previous year.
Kirby
I know they send test ballots thru. I was there, I've had to run the test sets thru to verify the code personally. I was told the FEC runs them thru and certifies it (they might outsource it, I wasn't high enough of the food chain to know). I didn't actually see that happen personally. I was told by several people it did, and I was given test batches of certified ballots with accurate counts to test with.
It was a big deal, and it was a pain in the ass by all measures.
Sorry, I don't know a darn thing about Diebold. I've personally worked, and been thru the testing system they have at ES&S. The article I read, had a conspiracy theory involving the former CEO, the local paper, and major corporations. There had to be a something, but the World Herald wouldn't write about it because they shared similar owners. I got about halfway thru and stopped reading when the smoking gun was, a local politician is part owner of several corporations locally, and well the local paper wouldn't report on it. That's a sign that there is no story there, otherwise somebody would have quit, and written gone public on the matter.
I eat lunch every couple of months with several of the people whom are sent onsite to be there for the onsite support. They are good honest people. They have talked me thru what is the procedure for deploying the systems. It seems reasonable to me. I've read the code that does the ballot counting, I've written the code that does the ballot scanning. Sorry, your hard data might in fact be accurate for Diebold, but ES&S was pretty serious about security and accuracy of the machines when I was there 4 or 5 years ago.
Kirby
Having been on the inside, and seen what the code goes thru, I'd be a lot more worried about the human chain of trust. As soon as you let the voting machine out of your sight, or you let someone else manipulate it, you can no longer trust the machine. Only a single person at a time, can truly trust a machine. The process of letting you verify it, makes me believe it is no longer trustworthy.
Kirby
The black box testing is pretty complete, and very good. You set the time and date to the time and date of the vote. You bring in a set of ballots that is larger then any single machine will be expected to process. You run the complete ballot set. At that point, the machines are in all ways, exactly as they will be when shipped out. You read the code from start to finish.
What else do you want? You've got a known regression test, in the precise conditions that will be shipped. At that point, it's merely user error that can happen (or procedure wasn't followed). What can you do to ensure end to end integrity at that point? Sure you can verify that a particular machine is correct, no problem. They send out 1500 machines to different voting centers. How do you plan on using the source code to verify that all 1500 machines have the proper configuration, that they have the proper software, and the hardware is properly configured. Yes you can verify that a single sample you saw at a given moment in time was configured as per the specification, however, open sourcing it, won't allow you to verify the machines at the time they are used. If you don't trust it, count the ballots. The ballots are right there, there is nothing more to subvert them that couldn't happen in a stardard paper vote.
The standards exist, and they are transparent. If you'd like to check them, go pick up a machine from the ES&S, and test it. If believe that the FEC's guidelines are insufficient, lobby to have them changed.
If you want to do the check, lobby to be there when the FEC does the test ballot sets. Examine the test sets, and verify the results of the test. Bring your own set of test ballots and request to test them against a sample machine. It's not like you need the source to do any of it. Buy a machine, set the time on the machine to the day of the vote, then run them. Then re-run them over a period of days while the machine is left on, or turned off to simulate the situation you desire.
Run the precisely as they would be on the election day. Simulate the tests with known results (I don't believe the all test sets are known by ES&S). Submit random tests to which you have the answer. Submit a test deck that has ever known pattern filled in for the upcoming election.
Then aquire a cryptocryphic checksum of your choice, that you believe at a later date you will be able to verify while voting. How you do that, without actually running the ballot voting machine, I don't know. At some point, the people who are running the voting machines must be trusted. If you can't trust them, you can't have a legitimate vote. It's the same reason why FPS will have always have cheats. It's inherint in the system, that an uncontrolled quatity exists, and can subvert the system because it has too much access, and information to make it look like everything is as it normally would be.
You can't have trust at any level. Anything that you didn't personally do, isn't trustable. As soon as a voting machine leaves your sight, it's absolutely not trustworthy any more. You can't watch anyone do the work (I've seen too many people who are good a slight of hand). You have to absolutely verify so many things, that it isn't trust worthy. Actually, as I recall, they wrap, and lock the machines, so there can't be any tampering.
Do you trust Linux? How do you think it has no bugs in it? I've hit known bugs in it. How do you know that the version of Linux you use, is the version that Linus ships? How do you know that the Re
Kirby
I can tell you why the 200 line limit is there, the guys at the FEC say those are the rules. You don't get to ask them why. You don't get to change the rules. The rules are imposed on you. It's a lot like living with your parents... :-) You want to do business with them, you absolutely follow the rules. The rules cannot be questioned. They are the one true set of rules. Sorry it's the gov't, that's how they work. All the guys who worked on it thought it was stupid. However, that's what Software Engineering said was a "best practice" at the FEC.
If I was really worried about it, I'd have to start to question, Watcom (the compiler maker), QNX (the people who made the QNX4 OS), the company I used to work for, the Intel chip, the company that made the compiler that Watcom originally bootstrapped their compiler from. The original QNX2 OS. The guys who made the Flash chips. The people who laid out the ballot. Just by switching the wording, or the layout of a ballot could easily affect the outcome of a vote.
I'd be more worried about if the people at the FEC used proper cryptographic check sums to ensure the integerity of the software. That the FEC could verify that the changes sent over, were in fact that only changes made. That the FEC had a proper build environment, and that they re-built the software, and just didn't trust the binaries they were given, are actually the generated by the source they have, and that they matched the binaries given to them by the user (modulo date stamps in the binaries). I believe the FEC did do a clean rebuild, however, I'm not sure who setup the build environment (I could setup a build environment that sneakily patched the software after the checksum had been matched). If they did cryptographic checksums and stored them in the results of each vote, so that each voter could be assured that their vote was handled by the software the FEC thought it was.
All that was out of my hands. I didn't do CM for them, and I only handled details dealing with turning black and white marks into votes, and non-votes for them. All of the talling, and other routines weren't my deal. That the people at the voting centers were not stuffing ballots. That the paper ballots were not tampered with, or willfully destoryed (always curious what they do, when if a fire happened and it destoryed all of the ballots before they got counted). Voting is a very, very tricky thing. You can't ever trust any mechnical device, or any electronic device, unless you built it from scratch. You'd have to verify everything from scratch in order to trust it. I mean the motherboard, the BIOS, the keyboard, the RAM, the CPU, the NIC, the disk subsystem, the bus, all of it, to be any more sure of it, then you by just running all of the ballots thru, and doing black box testing on it. Verifying the source, won't do you any good, unless you also verify the build environment, and verify the binaries, and very the hardware configuration of the final voting machines. Oh, now you have to trust all of the people at the FEC who do the verification. Which gets you back to square one again... Until a voter can ensure the setup of the machine, in a trustworthy way, your screwed. An the voter can't, if there is enough collusion going on at high enough levels in the verification process.
Kirby
The company I worked for did all of the original design assembly of the PCB boards.
Everything is done on paper (on those models, I hear they have other electronic only models). So it is completely auditable via a recount. The Federal Election Commision certifies the software and the hardware as fit for use. Once certified, no changes can take place without a re-certification, and justification for all changes made.
They use QNX as their base operating system, and use essentially fax based technology inside the system. They scan it using the fax scanner, using timing bars to tell where the bubbles are. They then read the black/white values using an A/D converter (at some point, they switched to infrared technology instead of fax technology). Each machine gets fed test sets of thousands of ballots ( I want to say over 100,000 ballots go thru the system during the final testing phase). Which the exception of a mis-feed, or jam (which has to be detected), there can't be any mistakes.
They are pretty serious about it. At one point I knew every guy who did the day to day coding on the systems. They are plenty trustworthy. Maybe not coding gods, but naferious evil plots just won't happen. Sorry, take your conspiracy theories and go home.
Oh, and no one in their right mind would want to read the code. For a variety of reasons. First it's boring as hell. Second, the rules make it nearly impossible to write interesting code. All function can have on and only one return. No function can be over 200 lines long. No matter how clear the function is, it can't be longer then 200 lines. Why 200, got me, but it's the rule. There are rules against using macros, and rules about function pointers, and rules about recursion, rules about how data structures have to be stored. Rules about lots of different things. Rules about election layouts. Rules about ballot layouts. All kinds of mind numbing rules.
Open sourcing them, or making them available under NDA for a third party audit, sure seems like a good idea. However, there are plenty of safety measures in place to assure that the right things go on.
Christ the machines run while being hit by a giant as static electricity gun. (Vandigraph generator, I believe it was called).
Kirby
AT&T took a lot of code from BSD and stripped off the copyright notices off, and incorporated it into there codebase. There is conjecture, that the clean "rework" of UNIX that BSD did ended up getting a lot incorporated into AT&T's UNIX. BSD at some point, removed all of the original AT&T code they licensed. It's my understanding that the court agreement was there were 8 files that didn't get re-written. That's way BSD 4.4Lite is, it's the BSD source, with the 8 files removed. 386BSD is the BSD that caused the original lawsuite. It was picked up and turned into FreeBSD after the original maintainer just stopped responding to communication or releasing stuff. I'm not sure which code base NetBSD started from, and OpenBSD forked off NetBSD when Theo had his spat with the NetBSD core.
Thus it might be that SCO owns the tube of toothpaste, that the BSD guys squirted all the paste out in the early 90's. Novell could have asked to seal all the evidence, that the toothpaste is all gone. It's mostly based on urban legend, and rumor. There might be some truth to it, who knows, the documents are sealed.
I believe that's the conjecture he's talking about.
Kirby
This makes tons of stuff easier. Like oh, say, when the network is down between you and the world, you can't telecommute. The guys who all work in the same building, can probably press on, continue to have meetings, and make progress on work. Where you are stuck.
Oh, confidential paperwork doesn't leave the building. They don't need nearly as many VPN connections. There is no one making a connection from a Dynamic range of IP's that are outside of the network operations control.
Telecommuting, you aren't in the same building with 500 co-workers. Now if the started hiring lone guys, on their own island in India, yeah, you've got a point. However, your wrong, wrong, wrong.
What I really don't understand, is why they don't start transplanting business from major cities. Look, there is no god damn reason in the world you have to be in downtown SF to write software. You don't need to be in LA, SF, NY, or any other major city. You can get an amazing number of resouces in much cheaper places then a lot of companies feel they need to be in. It's just plain silly.
Kirby
CPU components are rated for the appropriate temperature of the core of the CPU, specifically because they have a temperature gauge you can measure with built in.
One doesn't walk around measuring the temperature of a computer parts, one measures the ambient temperature of the room. Call Dell, tell them your running computer equipment in a room that's 120F, I'll bet they tell you the warrenty is voided. Tell them the room temperature is 90F, and I'll bet they will tell you to move it to a cooler area before they will help you trouble shoot the problem. The ambient temperature of the room dictates that temperature of the part after you've had it running for any length of time. It's simple physics.
Kirby
Also, it's not luck touching a lot of computer parts really makes them instantely turn to 98F, if that was true, ice would melt instanteously in your mouth. You "slowly" heat up computer parts while touching it, depending on the heat transfer constant of the part you are touching. Heat transfer is exponential, it's like half life. There is a certain period of time in which you can half the heat difference between two parts (discounting phase change). So if for a CPU, that is 1 minute. That means if the difference between the CPU and the air is 100 degrees, then you lose 50 degrees in 1 minute. Assuming nothing is heating it, you'll lose 25 degrees the next minute, and so on. However, when the CPU is running, it's getting heat added to it at the same time. The tempature stablizes when the CPU is adding the same amount of heat that it dissapates per unit time. So having the room tempature significantely lower then the rated temperature the part can run at is very important.
Kirby
I'm not sure what property dry ice has that makes it more compelling then water. In this case, I want the damn stuff to melt to absorb the energy. Having it turn into water is something I can deal with. Having to deal with not breathing in a server room, just seems silly to me.
Kirby
Heat rises. So you can keep the tempature of the room close to the ambient tempature of the rest of the building by getting enough airflow, and creating a way for the heat to escape up out of the room. Not sure how your server room is built, but create as many large holes as you can moving the air up outside the room. I saw a room drop 6 deg F, in about 20 minutes by removing all the ceiling tiles.
Oh, and get incredible airflow over the equipment. Ensure the air is circulating over the actual equipment, so the really hot compenents have a chance to pass the energy on to the cooler airflow, thus cooling the compenents. You don't want hot pockets of air right around the computers.
Now, the ambient tempature isn't exactly great from your remarks. Most computer equipment is rated to run up to 80-90F. So you might be able to get by for a couple of days. If not, read up on how A/C works, and how old time A/C works. Build something that works on the same princepal. Got me what it is, but I'm fairly sure using cold water as a heat exchange to literally carry the excess kinetic energy out of the room is your best bet short of finding an alternative source of power.
Kirby
Kirby
Well, it turns out that, if you over phone service to anyone, even for free, especially long distance, guess what, you have to pay various taxes. Even if you don't make the customer pay, your still have to pay the taxes to the local and state gov'ts.
So in the end, you'll end up doing more paperwork, crapola then it's worth to setup your own phone service over your own phone lines. So your options are pay the phone company to run them for you, or pay them to provide the lines you hook up to your own phone. I'm not sure what the cost of buying a pay phone is, or what the cost of a business phone in your are is (it's about $50-75 a month here). So if you think the phones will average less then $75-$100 a month in damage, it's a win to own your own phones. If you think they will average more then that, it's a losing proposition to own your own.
Personally, if it was a fixed cost $150 a month, they have to replace damanged phones, your absolutely nuts not to take them up on it. About the only options are to not provide phones at all, or to literally let them use one of your phones, either a cell, or a land line based in an office.
Kirby
Now that there is no dividend tax and Microsoft is no longer a growth company, there isn't any good reason not to pay the stockholders. When there was a dividend tax, Microsoft could argue that by keeping the money, they could put it to more efficient use to build stockholder value in terms of share value, rather then giving some of it to the stockholder, and some of it for the gov't. The other point is, that Microsoft is done growing by leaps and bounds. They don't need any more capital to grow, or smooth out cashflow issues, or any other standard business reason why a company normally keeps money cash on hand.
I believe the shareholders are starting to demand it, as that's the one way the shareholders can get their money out, without having the price go up or down. It's a sign that Microsoft is turning into an old school established company, like so many others, rather then being a hot commodity stock that creates value, because the company keeps growing, and building up more value.
Kirby
Airborne is late more often the FedEx who is late more often then UPS. Personally, I'd ship it UPS, and add $3K in insurance. I'd ship it ground, (it'll probably end up on a plane, but if you can deal with not having it for 5-6 days it's a lot cheaper).
Get it ensured. Keep the insurance slip. Make sure it's a must be signed for shipment, and call UPS to have it be arrange for pickup if you don't get it the first time they attempt to deliver it.
If it's not there, and you don't have a note, call UPS. Check the website.
If it's not there within 3 business days of the scheduled delivery date, you are screwed, call UPS, file a tracer. Start the process of getting your insurance money.
Every Tom, Dick and Harry on here is going to tell you their personal story about how they got screwed by carrier X, and how they will never use carrier X again. They think the carrier has some personal vendetta. It's comical. All of the carriers move millions of items a week. An success rate of 5 9's, still means a lot of screw ups a week. Make sure you have the documentation, make sure you take care of it quickly, make sure you follow up with them. You can successfully get your refund if it gets lost or damaged, sometimes it takes a little while, if you can't deal with that rent a car, drive the damn thing.
Kirby
There are two things to check, first turn off gpm. It's never done anything but give me grief in all the time I've ever seen turned on. I know that this will solve problems on several different KVM's I have. I know on one of the KVM's, it fixed all my problems so I could use the IMPS driver without doing the second fix.
Second, is that something is completely screwed about XFree86 of handling the PS2 mice, you can switch to a serial mouse, but no wheel then. The way to fix the problem, is to get XFree86 to resync/reset with the mouse. After switching from once machine to the next, immediately switch to a virtual console, then back to X, and the PS2 drivers will resync/reset/"do the magic to make it go". I've got no idea what the problem is, or why switching consoles works, but on the various Belkin Switches I've seen that is the fix that works best.
Kirby
However, there are good uses for modification of vehicles, like say air bags. I don't call air bags, gimmicks, just because I think that guys who put dual exhaust systems on a 20 year old car seem like they are wasting money to me.
However, in terms of redundancy, your far, far better off with 10 P3 500's, then with one P4 5Ghz machine. One of the PIII's is having problems, shut if off, run the diagnostics. The P4 has problems, you shut if off, you are in deep shit.
If I had my choice, I'd rather have a cluster of 5-10 well built, redundant machines then one machine 10 times as fast for any problem that can easily be distributed (think websites, DNS, mail servers). No, I don't want to use 10, 3 year old Dell workstations to serve up my enterprise website, but I wouldn't have any objections to 10 Dell Servers that were bleeding edge 3 years ago assuming it uses parts that are still commonly available.
Kirby
If the MD5 sums don't match, then the code can't match, if the MD5 sums do match, then check to see if those sections do in fact actually match.
My only beef with this methodology, is that several obvious things should be applied, including stripping leading white space. I copy code and indent it futher then the original block. Turn tabs into whitespace, and then run collapse adjacent spaces into a single space.
Possibly run it thru a good code beatifier to get it all in a single coding style after stripping comments to look for additional possible matches. Really run it thru the ringer, looking for possible matches, then check have experts inspect the possible matches.
Kirby
First, the async, means that not all reads and writes are syncronous which is an incredibly good thing for speed. Try putting your UFS/FFS filesystem into fully sync mode and then talk about performance, I'm willing to bet that UFS/FFS isn't sync by default either. However, calling fsync in the mail server (normally sendmail) in Linux will actually make it sync before returning. So no worries about RFC 1123. It's the SMTP server's job to ensure that it tells the filesystem, make sure the bits are on the disk. If Linux didn't have the ability to ensure bits where actually on the disk nobody would use it. That's why in Moshe Bar's series comparing Linux, FreeBSD, and OS X, he always said he recompiled after removing the fsync calls, otherwise you just compared how fast the disks in each system were.
For goodness sakes, Oracle ships on Linux, if Linux couldn't get the bits on the disk Oracle would have never ported to it. Not a chance. If Linux tells you the bits are on the disk, they are on the disk in my experience.
I've heard of people losing UFS filesystems while running them under NFS, or losing them due to any number of naferious VM race conditions. So what? Welcome to the real world, people lose data, buy a tape drive, make backups. Knew a guy who got really good at rebuilding filesystems by using dd on Solaris to recover email for customers.
Oh, and as I recall, async actually affects directories more then files, if you put the sync modifier on the filesystem, it only affects directories, not the file data for ext2/3. In ext3, directory writes are always journaled as I recall, so it shouldn't make much difference.
Now, from what I've heard of Linux and FreeBSD, is that until the late 2.2.X and early 2.4.X, there we're certain jobs Linux couldn't do like run big Usenet News services, or really disk intensive applications they the filesystem buffering was really hard to get right, and might cause corruption. The guy who ran a local ISP always said FreeBSD never did that when he was running the Usenet server on it, but Linux did with some regularity.
ext2 hasn't lot any data of mine in my 7 years of using Linux, including running a 120GB Oracle Database for the past 30 months. Ext3's never lost any data since I started using it. I've lost disk drives, I've lost mirrors, I've lost files, never lost a complete ext2 filesystem unless the disk just stopped spinning. Lost a couple of ReiserFS filesystems after installing RedHat7.0. Never tried most of the other journalling filesystems.
Kirby
Message passing,
Process scheduling,
Address space management.
Setup the timing hardware on the ISR.
That's it. The serial driver, done in a process. The keyboard, floppy, IDE, SCSI driver, done in a process. About the only piece of hardware you didn't control in user space was the PIC interrupt processor. Other then that, all interrupts did was call user process-space callbacks.
In Linux, if your IDE driver dies the whole system could lock up. In QNX4, if your IDE driver dies, the only reason your system will lock up, is because you application locks up on failure to write to the filesystem, or the hardware goes crazy. If the CPU works, and the RAM chips don't get hit by gamma rays to cause inadvertant bit flips, QNX will in fact work. Period. Full stop, end of discussion. That's why most applications on QNX use no moving parts, so there is an extremely low likelyhood of failure after running burn in tests on the hardware.
Now, Linux on the other hand, I've seen the SCSI drivers on it, where a single SCSI card will fail, and the identical SCSI card that works fine will have it's driver lock up because the other piece of hardware failed, which creates a situation where RAID 1 won't continue working, so the filesystem fails, which causes an ext3 journalling error, which then causes your kernal to panic. That wouldn't happen under QNX4.
Kirby
What security problems did you have?
There are 2 that I know of offhand. First, they used a reversible hash for passwords, or they used one that was trival to brute force. It's my understanding that breaking a password on QNX is relatively simple. Second, if you are user X on a given machine, you are user X on all of the machines when you are using the QNX networking.
QNX isn't meant to be an on the public Internet OS. It's meant to be used in a closed loop networking environment when in production use. Don't configure anyone else as on your QNX network, and the problem is solved.
2. Networking was trivial. The damn network just worked, the biggest trick was coordinating who had what node number. It worked all the time once you got is correctly configured. It always worked. Other then getting the TCP/IP stack installed which took the sacrifice of a small fury animal, and asking my co-worker Bob how to do it. Once it was configured and running, it was trivial, it always worked without fail on the machines I used.
IPC, was cake. It was stock off the shelf redevous style message passing. About the trickest thing there was calling returning a negative value from a inside of a interrupt service routine (not the real ISR, because you should never reprogram the ISR's, but the function you registered to be called when an interrupt happened), that would call issue a Trigger. That was a little weird. The networking itself was simple. Here's the buffer with the message, here's who I want it passed to, call the send message API. Done.
Now, the style you had to use was a little awkward, because you blocked on a receive message call. However, that was a function on the hard real time requirement of processing a message. You could use stock TCP/IP functionality if you wanted to. They had the standard UNIX sockets as I recall. The had shared memory (in fact shared memory was how they implemented all of the Dev Server functionality). I can't remember if it did stock UNIX signals (I'm pretty sure it did). However, you never needed to use those, you could send real QNX messages, which was orders of magnitude easier.
Now, if you want to bitch about the structure of the Photon programs I understand. If you want to bitch about the lack of a number of highly useful utilities, and that all things are freeze/PAX encoded instead of TAR'ed, I'd agree. Networking isn't a problem. IPC is the core of the entire OS, that's literally how it implements everything. Everytime you call open/read/write, a message gets sent to the process that is registered to handle calls to that. I know this because I write a RAM disk buffer as a proof of concept that we could re-implement chunks of the OS if we needed to. Message passing and IPC are what QNX excels at. It's security model is that, don't use it when it's connected to something that isn't trustworthy.
Kirby