I've been with pair.com for four years and I have seven domains with them. I've been extremely happy with the service there.
Recently I had a run-in with their support staff when I submitted a support ticket about how to configure my own installation of SpamAssasin to filter POP mailboxes. Their web based configuration tool overwrites the control file I need to change every 15 minutes.
The first response was "this is almost the right answer, but I don't know the last part, I'll send you to another tech". It went downhill from there. Had to fire back the ticket seven times when five people in the middle of the chain barely bothered to read the specifics and continued to propose solutions where I had already clearly stated the reason they wouldn't work.
The service is great (overall) and the prices are reasonable.
My only significant complaint (aside from that one support incident) is that there are some security problems between web users on the same host. No matter how you set your perms, PHP scripts run by other users of that host can read any file in your personal tree that www-data can read. They only have to guess your main site directory (parent dir is r not x) then they can crawl your entire tree by simulating Apache behaviours. You can slow them down by putting strange stuff in.htaccess files, on an obscurity basis, but you can't entirely prevent it.
There is also a way to botch your.htaccess rewrite rules and send the system load spiralling out of control (I've seen the needle hit 77 after logging in to find out why POP access to the same machine was lurching). I made this mistake once myself with my own.htaccess, but I caught the runaway train and killed it before the system load crawled past 3 (they strive for 0.4 average).
These extra costs are guilt by association. How does two OpenBSD boxes add up to a greater risk of being trojaned than a single Windows box?
I suppose the number of hosts could correlate to these cost variables, but many other indicators correspond a lot better, and of those many are negative correlates (power users need less support than novices and are less likely to harbour or spread trojans).
Do I get a discount from my ISP for configuring rules into my OpenBSD firewall preventing any of my client hosts from *sending* packets on known virus ports? I didn't think so.
It's totally bogus to paste someone with extra costs on the implication of a correlate that can be directly disproven for the case in hand.
Actually there are shades of the Laffer curve here. "If we had no hosts, our costs would be nill. Therefore, every extra host is an extra cost."
The problem with the Laffer curve is that *even when* the tax rates are above the value of maximum tax revenue, lowering the tax rate isn't guaranteed to move you toward maximum revenue. You could be caught in some local sworl.
The problem here: the Laffer curve is a curve, not a function, and there is no justification from the premises given for assuming the Laffer curve isn't self crossing.
There's a much deeper point here. In OOP languages there is the notion of public interface and private implementation.
In the case of NAT, the public interface is the amount of traffic generated. The private implementation is how that traffic gets distributed among different hosts behind the NAT.
When a utility decides to regulate a resource on a dimension that they can't even properly measure, what they are trying to regulate has no bearing on their cost structure for providing the service. If the cost structure was impacted, that amounts to something that can be measured directly (amount of traffic, number of packets, time of day, etc.)
The main of this message is that for a certain class of motivated users, the private implementation of his NAT makes it possible for a collection of active machines to have as low an impact on ISP provision cost as a single user who takes no active measures to blunt the impact of his usage pattern.
From the point of view of economic benefit, this is entirely cracked. The point of economic competition is that users who are motivated to maximize the efficiency in their use of scarce resources should be rewarded, otherwise the economic system is encouraging wasteful behaviours.
One of the purposes of creating the legal category of a "utility" sector is to enact legislation to prevent the kinds of wasteful pricing policies individual companies find most profitable to pursue.
Sure, you bet they'd love to change a monthly fee for every device with an IP address anywhere. Five years from now the average fountain pen will have its own IP address.
It's really quite ridiculous if you peel back the implications.
Really, the only sane model is to price a bit pipe on bits transported (congestion weighted if they so desire). If they wanted a per host/user business model, they should have gone into the business of offering network services above the level of the raw pipe.
What the NAT police are after is gatekeeper taxation. A nice business to have if the people you tax are stupid enough to play along.
I've had terrible experiences with HP inkjet printers. I wonder if there is any quality left at all. Hard to believe that HP was once the company mentioned in hushed tones along with Tektronix.
Recently I was helping a friend recover their system from a hard drive failure. Got all the data back after throwing the drive in the fridge for 24 hours. That was a lucky one.
We paid the price later when we installed Windows 2000. First the CD burner software hosed the machine so that it bluescreened on boot up.
We fixed that problem with a fresh Windows 2000 install (and a different CD burner package), then we tried to install an HP PhotoSmart printer. Boom. More blue screens.
It was a complete nightmare. Eventually we could only boot the system in safe mode. In order to fix the problems caused by the HP PhotoSmart driver, we had to run some installer. The installer would start up and then tell us that we had enough processor, memory, and disk space, but we didn't have enough pixels. The installer refused to run in 640x480 mode. Geezus Murphy, we are in fscking SAFE MODE running the installer to pry out the POS crap HP printer driver that is forcing us to boot in SAFE MODE.
Thoroughly battered, beaten, and bruised I resort to the venue of last attempt: write an e-mail message to HP customer support. Actually, it isn't writing an e-mail, it's typing twenty long and precise paragraphs (we tied so many things it was hard to list them all) into a gun-slit web feedback form.
OK, press submit and maybe HP will sort out the mess. No chance. The instant I clicked submit the browser came back "404 not found". HP can't even keep their web support infrastructure running.
By this point there wasn't a tower high enough to pitch HP off of. Any vestage of Hewlett Packard that Walter Hewlett was trying to protect has been thoroughly assassinated.
But my friend wanted more punishment. She actually called the phone support desk. They talked her into many different bluescreens, told her that there must be something wrong with her machine (it worked just fine with the same printer running 98 before the hard drive melted down).
Their final recommendations:
- upgrade IE 5.5 to IE 6
- upgrade Windows Installer
- upgrade from SP2 to SP3
It seems like the HP PhotoSmart printer wasn't working because we hadn't succumbed to the new and improved licensing conditions.
And where would HP be to help us if these upgrades broke something else? Where the button to unclick those license agreements when you decide they haven't improved matters?
I have trouble understanding why the new HP bothers to exist. It reminds me of the era where Compaq went from having the best stuff to having just the weird-ass weird stuff that you couldn't service because the parts were all funny. It was a small miracle if you could get the original Warcraft to run on those beasts. Warcraft was worth the bother, the HP PhotoSmart wasn't.
The collective job is a mixture of changing the sheets, emptying the bedpans, dealing with the dilapitated, the demented and the elderly, funerals, autopsies, coroner's reports, pace makers, life support, and tense meetings with the next of kin.
Nurses and Orderlies. But mostly orderlies. Get over it.
I've always thought that the JVM security model was the moral equivalent of eliminating the FDA in favour of tamper resistant pill bottles.
Tamper resistant packaging is a darn good idea. But it's not a good idea to be so impressed by the packaging that we forget that how easily well intentioned people can create combinations of carbon, hydrogen, and oxygen and a few choice flavour additives that kill.
Bottom line: no matter how much rocket science you pour into the packaging, you still have to ask hard questions before ingesting the contents into your body.
Unless you believe that large software companies have entirely different profit motives than large pharmaceuticals.
A long time ago, at a time in my life when I had more money than brains, I bought myself a Fat Mac with 512K memory and two floppy disk drives the day this model first hit the streets in Toronto.
My girlfriend at the time (I guess there is an upside to having more money than brains) needed to conduct an experiment in cognitive psychogology to complete her undergraduate philosophy degree.
She decided to conduct an experiment in reading comprehension. Both groups were asked to read the text, but with different reading instructions. One group was instructed to proofread the text, the other group was instructed to read for comprehension.
We decided that programming this experiment for my new Mac would automate the timing controls, automatically measure the proofing reading results (how many words were marked with a mouse click), to collect the multiple choice results, and record the text of a written response question (in a dialog box roughly as feeble and distigusting as the web form input box used to compose posts for slashdot twenty years later).
When I showed her the first version, her remark was this, "you have to remove the menu bar or I'll fail". I could see her point. For an experiment in reading comprehension you want to control every word of text presented to the subject. Her professor would see it the same way.
At this point I should have pulled out a roll of duct tape, sliced off a half inch think strip, and covered over the top half inch of the display.
But ego prevailed. Surely, I thought, I just need to read the big Apple developer guide phone book thing to find the right flag to the right system call to remove the menu bar.
Thus began three weeks in hell.
The only way I could find to suppress the menu bar was to skip the initial call to some of the Apple windowing subsystems. It seemed to work. But then my program began to crash in dozens of mysterious and different ways. Eventually I learned that the call I had skipped initialized data structures required by many other subsystems.
Then I found other system calls that would hide the menu bar temporarily. But the nasty thing would reappear randomly as the user performed mouse actions. No matter what I tried, the cat came back.
Within a few months I several other frustrating encounters with the Mac architecture. I grew to despise the architecture of the Mac windowing system. I thought I could escape from Pascal hell by installing the Aztec C compiler. I was instantly much happier, but it wasn't a productive situation because the underlying C to Pascal mapping was full of bugs.
Then I was forced to buy an 8MHz PC for a programming contract. I put the hideously Fat Mac into a closet and I can barely recall using it since. I made one effort to salvage my investment by inquiring about the cost of a making a modification to install an internal hard drive, but the price was outrageous (almost as much as the entire turbo PC I bought instead).
Thanks to Apple, I learned a extremely valuable lesson about decoupling policy from implementation. One man's policy (Steve's) is another man's hell (mine).
Twenty years later, I never complain about X Windows. At least I know that this of kind of question *can* be answered.
Gawd I hated that machine. And it turned out the girlfriend wasn't much better.
In 1976 Earl Butz, the secretary of agriculture, resigned after it was widely publicized tht he had made a racist remark. Butz's statement had been: "I'll tell you what the coloreds want. It's three things: first, a tight pussy; second, loose shoes; and third, a warm place to shit."
Recently, if I believe what I find on the internet, Butz was elected to the NRA board.
Note that doesn't read "erected to an NRA board". Damn.
We have two broadband links to our small downtown office. Each of these links terminates at an OpenBSD firewall. We briefly looked at what kinds of fail-over models being multihomed in the DHCP ghetto makes available to us (actually our ADSL service provides two static IP addresses, but they still grant you those addresses via DHCP leases).
We can do some cool things with Zebra (OSPF) over our VPN (all our offices / developer's have their networks in different portions of the 10.x space). If segments of our VPN fail, the traffic would find other segments forming a viable route to the final destination. Within the VPN we can pretend that we have a real network.
Fail-over to the outside world is more difficult.
One issue which no-one has mentioned here is stateful firewalling. Even if we can broadcast route information to the two OpenBSD gateway machines, it will break stateful firewalling completely. That said, most of our traffic is not session oriented. A broken HTTP request will fail-over at the application layer. No biggy.
The primary form of session oriented traffic we use is OpenSSH tunneling. The simple solution here is to remove stateful firewalling on the SSH port. I have to doubt that stateful firewalling your SSH ports accomplishes much.
For fail-over of our public web servers we decided against nasty DNS schemes. You don't get load balancing (just load sharing, which is not the same thing), there are issues about DNS record caching, your control is poor, when problems arise your ability to investigate the problems is all in a muddle. We don't tolerate that kind of thing here.
Instead we are directing all public URLs to a highly reliable and well connected public hosting company. That host is returning a frameset document containing a single frame window, with the embedded frame directed at one or the other of our two broadband services. Our firewalls are sending pings to the public hosting company so that the PHP script there can decide which of the two URLs to send out on each request.
There are plenty of extra complications since we are also thunking requests into different SSL compartments and we are using the OpenBSD firewalls to run chroot Apache in proxy mode (which allows them to filter the URLs before they reach the internal content servers).
With the right magic additions to the frameset code we can make the public URL track navigation through our content without revealing the ugliness of our internal fault-tolerant, SSL compartmentalized URLs.
Framesets suck, but not nearly as much as borking the DNS standard.
We are fortunate that our client base is narrow and we can impose client browser requirements. Our traffic volumes are low enough that we can afford the overhead of trampoline packets on each URL access.
We achieved a fairly low standard of fail-over in the end, but the good thing is that we didn't have to involve anyone else, and the fail-over we do have is sharply defined and easy to diagnose.
In our small shop, we use OpenBSD for firewalls, FreeBSD for file servers, Debian and Windows 2000 for workstations. For any given purpose, any of these systems might have a decisive advantage. I listed them in my rough order of bias. At the top of the list is maximal purity coupled with the narrowest applicability. At the bottom of the list is maximimal impurity coupled with universal applicability. We try to push our subsystems uphill where possible, but we're not zealots about it.
If I had to pick just one I would pick Debian and I'd be 20% miserable all of the time, but hardly ever 100% miserable (because something you really depend upon works badly or isn't available at all).
My only complaint about the package system in Free/Open is that selecting your packages is somewhat more manual than it ought to be. It's a bit of a pain to clone a known configuration at a different revision level because you have to pick exactly the right package names. I'm no fan of dselect, but dpkg is pretty livable.
Either way, if the package system is your main area of concern, it's a certain sign you have nothing important to accomplish. They both get the job done well enough if getting the job done is your main concern.
There are too many presumptions in this comment about JIT. The protections Theo is using are imposed by the VM system, which means the protections are relative to a *view* of memory. It's not obvious to me that the JIT compiler needs to share the same view of memory as the process for which it compiles. I can't bring myself to believe that for a typical invocation of the JIT compiler, one process transition is a dominant cost.
From the article itself: [[[ These exploits require a high degree of precision. I've tried to take out most of the guesswork, but there are two things that might cause the exploits to fail. The lpstat and rdist exploits expect certain things to be in the environment at exact locations. ]]]
Probably the best metaphor here is the game Twister. The new work by Theo et al. forces the black hat to put his left elbow on the blue bubble. Sure, he can still do something devious with his right leg. But if Theo keeps dealing out the cards, eventually his bowels will explode.
In constructive software development, the programming cost is widely regarded as exponential in the number of constraints faced. Yet in the popular lore, for a black hat, a sliver of a glimmer of a faint and twisted hope is all in a day's work. This from the lips of the same people who pretend not to believe in Area 51.
Has anyone ever considered configuring an HTTP byte server with a filter on the referrer tag for ".slashdot.org/"? With the appropriate server response, the site would appear/.ed before the first/. lamer hits it, and it would seem so normal I doubt anyone would notice. Just wondering.
While you are at it, you should plug the spill pipe in your toilet tanks (the one with the opening just above the high water line). In a properly engineered toilet, the float will always float and the valve will always valve. And if the float doesn't float, hey, it's not our ceiling that will begin to drip.
A firewall should not be considered as a wall. A firewall is best regarded as a damping mechanism. My firewall is configured to make it impossible for my internal network to send out bad packets (forged return address, strange TCP/IP bits or fragments, anything addressed to known virus promulgation ports). Those rules function like the spill valve in the back of your toilet tank. Even if something goes terriby wrong (e.g. with a binary patch where I can't even read the source code) and my float doesn't float or my valve doesn't valve, I'm not going to cause a septic disaster for everyone "downstream".
My suggestion: stop polishing your Brass Testicles ninja sysadmin award and start thinking about reality.
*sigh* C++ doesn't stop you from playing hockey in your pajamas, but it does offer a dozen new varieties of protective equipment not found in the C language, covering just about every risk category short of programmer incompetence. One can argue that programming shouldn't be a contact sport to begin with, but try not to insinuate that C++ doesn't offer appropriate safeguards for the risks involved.
If a programmer adopts the STL containers, there are no buffers allocated on the stack. The STL idiom makes it more difficult to write past the end of a container unwittingly (it's very easy to ask a container for the last legal address), you can elect to use range checked implementations, you can structure your code so that there are very few places where the container can be accessed through a non-const pointer/reference (so the lines of code you need to be anal about are few and obvious), in difficult cases you can often use compile time mechanisms to impose compile time range checking (templates), or you can derive your own container objects which impose "non contact" safeguards on every hung-over asterisk with roughly the same time and space penalties as the languages which impose these semantics by default.
There's one more observation that ought to made here. If the programmer invests the time and energy to master all of the mechanisms which C++ provides, when he goes back to bare naked C (shudder), his C code will be just as correct as his C++ code. Once C++ teaches the proper mental disclipine, the discipline alone resolves 90% of the problems.
I think the root problem with C is that it doesn't force the programmer to master any concepts. "C with classes" should have been "C with concepts". The ++ stands for "clue".
If this guy's math is correct, that moving from 1024 bit keys to 2048 bit keys increases the computational cost of breaking the key by a factor of 2^1024, then this guy must also believe--in some dark corner of his brain--that the first 1024 bits of key also requires 2^1024 operations to crack. I think this fellow needs to sit in a corner and count his way up to 2^1024 before he posts again.
Unlike the symmetric ciphers, the public key cipher does not have a pure exponential structure. If it did, we'd be using 128 bit keys and that would be more than adequate.
Let's just pull a sample key strength function out of some dark place. Let S represent the effective public key bit strength.
S = 1/4 * log2(N) * sqrt(N)
N=256 S=32 N=512 S=50 N=1024 S=80 N=2048 S=124
The new discovery modifies this relationship, but since we are all/. lamers we read the initial three words of whichever link we clicked first and immediately jump to one of serveral interpretations:
To confuse matters, it happens that (1) and (3) amount to pretty much the same thing: a rough factor of 1000 in the computational cost of cracking a key.
I didn't mention column (4). That would be the hypothesis of the post I'm responding to, where S is linear in N with an origin in the vicinity of 2^70 (a high speed computer running for one year) for N=1024.
In a perfect world all the/. posters in category (4) would get jobs as microwave oven repair persons. Then everyone would become a lot more cautious about their dialectic coefficients.
Maxwelld is a daemon process that governs a small gate. For all queries that suck, maxwelld closes a tiny gate. Whenever a query that doesn't suck comes along, maxwelld opens the gate. Only the important and necessary queries are allowed through. This does not violate the laws of entropy. Physicists believe that the inverse entropy generated by this process is radiated into the Murphy field.
% host bigasterisk.com
bigasterisk.com has address 64.139.32.113
% host 64.139.32.113
113.32.139.64.in-addr.arpa
domain name pointer ip-64-139-32-113.dsl.sjc.megapath.net.
The reason Drew perceived this as careless and malicious is that he's not as clueless about how easy it is to determine that a site is hosted on a cable modem. Even a/. editor can correctly spell the 'host' command.
So far no one has mentioned IDT, Centaur, or the Winchip. That product was developed by a very small team who shrewdly avoided applying great complexity for small gains. It's not that difficult at all to great price/performance working a couple of litho generations behind the bleeding edge. (That's an optical pun BTW.)
Translate "can't decide" as "nothing impresses". It's like a beauty competition where one girl can't add 2+2, the next forgets the words to the song that she sings, the final contestent has a missing front tooth. If he did another 130 graphs, do you think these problems would magically disappear?
That may be true, but perhaps the users of OpenBSD do need a book. I started with OpenBSD 2.6 after many years surviving under DOS/NT by installing POSIX shell utilities wherever possible. I knew TCP/IP networking extremely well and x86 hardware inside out. The excellent OpenBSD online documentation was a tremendous help, but it certainly left me hanging on many, many occasions. If you think OpenBSD doesn't need additional materials, it's because you're already an elite member of the OpenBSD cabal. I earned my OpenBSD stripes the hard way, but I'm not so proud of it that I think others need to strike their heals on as many rocks as I did. If every discipline takes that approach, what you end up with is highly fragmented community where no one can afford to have more than three skills and the vast majority of communication takes place between people who already share most of the same knowledge. The world doesn't have to be that way just because you find that acceptable with respect to your own narrow purposes.
For new users setting up an OpenBSD firewall/NAT for their home network, the book needs to stress the importance of configuring the resolvers correctly. I experienced several extremely frustrating days because I didn't understand that portions of the resolver were client side. I mistakenly presumed (for a while) that bind on my firewall was acting on the localhost resolve.conf settings on behalf of the DNS clients. It took me a long time to shake off this small misconception because resolve.conf was being clobbered by/sbin/dhclient-script with extremely little documentation to warn me of this. You have to remember that new users might be learning less, vi, shell commands at the same time. The new user doesn't have the advantage of learning new functions on top of a solid skill base. I had an extremely solid skill base from a non-Unix background, yet mapping those skills onto Unix was consuming enough brain cycles that I was making small conceptual mistakes that I would not have made in a familiar environment.
Another thing that bugged me was "Don't log in as root". I completely understood this was a good idea. However, there is a substantial skill set required to work efficiently learning how to configure and admin a Unix box using root only as necessary. New users don't have the magical knowledge the previous poster seems to assume about what operations require root and what operations don't. An 80% confidence level doesn't get you very far. If it takes ten steps to configure something and a new user has an 80% confidence at each step, when it doesn't work the first time (and it is not likely to if you have undertaken ten steps at 80% confidence) you're up the creek without a paddle in knowing where you went wrong.
OpenBSD is actually rather weak in explaining how to dig into the system for corroboration that individual steps have worked successfully. You can find that material easily if you already know what you are looking for. I've complained about this upstream from time to time and the answer seems to be "if you don't know where to look, it's not our problem to help you".
One thing that would have been extremely helpful at the outset was to know how to use netstat to determine which sockets a daemon was binding on and ps to determine what security context that daemon was running under.
Another area where I made many mistakes was not knowing under what conditions a daemon needed a HUP in the ass. I be busy reconfiguring something and forget to HUP a critical process and then I would come to wild and incorrect conclusions about why my syntax was broken when in fact it had been correct already on many occassions. The OpenBSD man pages are not always blunt enough: if you change this file, you must HUP this process.
The area where I would find the most value is advanced security and networking. I've only played a bit with Kerberos, IPv6, and IPsec. I don't know the exact list of things to examine to determine whether a daemon process is chroot exactly the right way to minimize security risks.
OpenBSD is complex enough that you can't learn all the best practices right from day one. I put a lot of effort into mastering the firewire rulesets and OpenSSH. I didn't put the same effort into the Unix security model until a year later. I made some good guesses about what I could defer and some bad guesses. A book to help me make better guesses would have been valuable.
At this point I've installed a dozen OpenBSD systems and most of this stuff comes automatically. I've reached the point where I don't really an OpenBSD book any more. And since I don't need this book, I'm sure no one else does either. A semblence of documenation is adequate for all comers, certainly. My struggles and setbacks were just payment for lack of intelligence and motivation. The logic of the previous post seems to be along the lines that handing someone a book to teach them to read is either useless or redundant. I don't agree.
Re:Deep blue was a bagel toaster
on
Behind Deep Blue
·
· Score: 2
After encountering a post like that I hardly know where to begin.
First of all, IBM participated in this chess match as a publicity stunt. The technology they were promoting was their ability to built a box with a very large number of computing elements that coordinated effectively. The nature of the standard chess algorithms (90% brute force) make them a good "animal model" for the kinds of technical problems involved in building massively parallel computing systems.
Chess has an additional chachet because in the history of computational theory Alan Turing and others from his era considered chess to be a good "animal model" of complex human thought processes. Back in that era it was broadly assumed that the hallmark of human intelligence was formal reasoning. Within twenty years the evidence started to mount that the human mind is actually very poor at formal reasoning, and that the areas where the human mind holds significant advantages over deductive computation are of a stochastic nature (what people often refer to as "pattern recognition").
The next turn in this story is uniformly neglected once the narrator begins to beat on the man-versus-machine jungle drum. (Another characteristic of the human mind is that analytic thought ceases completely once the preening reflex takes over.) It turns out that it is more useful to build machines that do the things we are not already exceptionally good at. Like adding more than three numbers together and getting the right answer, first thing on a Monday morning after the Super Bowl weekend.
The reason that computers have been so greatly developed in the brute force dimension is because humans are terribly bad at this stuff. The reason why computers have not developed stochastic algorithms of the same power is because humans are already damn good at stochastic pattern recognition. Hand me a four function calculator I can calculate sums and products faster than Newton, Gauss, or Kepler. Yet our best results in visual processing are easily outmatched by a four week old puppy. Do you think it is easy to win grant approvals to underperform a four week old puppy? This is yet another example of how poor the human mind is an analytic reasoning. It's terribly stupid for us to think that underperforming a four week old puppy is slight progress, but we do.
A lot of people say, because of this situation, that computers aren't very good at this kind of application. That's not true. They are good at this kind of application (and they can still get an awful lot better), just not good enough to impress anyone who was born with superior innate abilities courtesy of mother nature and 100 million years. If you look at recent advances in accoustic processing, such as filtering background noise, there are clear signs that we are entering a phase of surprisingly rapid progress. Visual systems are a harder problem, I suspect the same progress curve will be shifted back by about ten years.
In this light, the most important knowledge we gain right now from the study of chess computers is the nature of the boundary between brute force methods and alternative methods. Deep Blue represents the fairly extreme side of brute processing. The advantage held by Deep Blue, at that point in time, was the vast number of coordinated processing elements it contained. IBM had the choice of pursuing a pure brute force approach, or a brute force algorithm tempered with subtlety. Unfortunately, the state of the art is such that adding subtlety to a massively parallel system seriously degrades the massive parallelism. Pure brute force is relatively easy to coordinate. Hybrid brute force is a nightmare to coordinate.
IBM being what they are, and the economic incentives for begin good at brute force being what they are, you can guess which tactic IBM chose. There was only one problem remaining. Pure brute force was not yet at the level of beating Kasparov. The pure brute force has a fairly large number of known weaknesses and sinkholes. The problem for IBM was to "tweak" the evaluator and search heuristics so that it didn't fall into the classic holes (which Kasparov would have exploited mercilessly). So they trained the program (by debasing various weighting factors) to avoid the kinds of positions that offer blood to a shark of a known and especially vicious species.
At this point it is worth mentioning that Kasparov was actually a fortunate choice of opponent for IBM. Kasparov has long been known for his tremendous ability to compute complex lines of play and he has used this weapon to crush many excellent players who could have competed on even terms otherwise. The problem for Kasparov is that his computational ability is roughly equivalent to a four day old puppy feotus compared to the computational ability of Deep Blue. Because Kasparov favours computationally rich positions, he has a tendency to play into mentally exhausting positions if his adversary shows the slightest weakness. The only aspect of the competition I regard as unfair is that Kasparov wasn't given nearly enough time to rest between games.
The question about building a computer SPECIFICALLY (emphasis from the other dork) to beat Kasparov really misses the point. I would guess there is perhaps 1% of such a system that can be tweaked without the immediate prospect of the entire house of cards collapsing. Half of the Deep Blue source code has nothing to do with chess at all (the parallelism, transposition tables, the basic min-max framework, etc.) Leaf evaluator functions have been studied for decades. How much do you think you can improve one in three days? And still have it run correctly in dedicated silicon? I don't think so.
So you end up tweaking a few weighting factors, such as the desirability of retaining the queens. You can witness this same kind of tuning in an elementary school chess club: "Joe is a titan with his queen at the end of the game. I'm going to try as hard as I can to whack his queen with my queen!" Kasparov SPECIFICALLY beaten by a kindygartner! (To quote Home Alone.)
The kind of tuning they did between games is on the order of the batting coach telling his hitters about the pitcher they will face in their next start "watch out for that wicked slider nailing the outside corner". If they didn't tune the program between games, once Kasparov found an area of superiority, he could have won every game on the same basic pitch. What would be interesting about watching chess played like that? And these tweaks were no simple matter. Your desire not to see the queens exchanged could cause some other aspect of how Deep Blue plays the game to deteriorate spectacularly. There's a name for this risk: it's called regression, and it's the curse of clever improvements. If tweaking was 1% as effective as the previous poster would have us believe, a computer would be president already. If your program is tuned to a local optimum, any single parameter you adjust makes the program play worse. In human beings 99.9% of genetic mutations (cosmic tweaks) are benign (if you are lucky) or deleterious, often fatally deleterious. In fact, large chunks of the human genetic system is devoted to removing tweaks. Kasparov didn't get to be world champion by having only one strength. He beat everyone out there, who represent the best of every different style. What do you think was happening between games? They change a 1.6 weighting factor to 1.55 and Kasparov falls to pieces? His vanquished opponents will lynch you if they hear you saying that.
I think Kasparov with more rest between games would have beaten Deep Blue. Ten years from now a machine computationally equivalent to Deep Blue will be a very ordinary piece of equipment. What's the point of keeping Deep Blue alive if they aren't going to invest in continual improvement at the software level as well? Anyone who thinks IBM was setting themselves up for a long term participation in the man versus machine debate really has no clue as to why IBM involved themselves in this chess match to begin with.
Let's not forget that Deep Blue played some positions Kasparov was convinced he would win better than Kasparov believes any human opponent could have played those positions. He commented at the time on how Deep Blue would constantly amaze him by finding slight resources in losing positions that stretched the process out, sometimes until Deep Blue stretched the losing position all the way to a draw. This is a classic observation about computer chess: if these programs weren't so damn good at hording slight resources, they might not be despised for their strategic weakness. The problem with computer chess is they are penny wise and pound foolish. But then we forget that the computer has no difficulty in keeping track of 100,000 slight advantages in a position each worth 0.001 cents.
What I find interesting to observe is the progress of programs like Fritz that plays at a very high level with not nearly as much brute force as employed by Deep Blue. It's a very difficult thing to successfully exchange brute force with additional subtlety. It's like grafting a plastic heart into a human being. Most forms of subtlety are immediately rejected by the host brute. It's difficult to add subtlety into chess algorithms, because the subtlety has to be manufactured exclusively with platinum, titanium, and teflon, otherwise it does more harm than good.
The best thing about having such great chess programs on the classical paradigm is that they will serve as an excellent foil to test out new classes of algorithms. Along the way we'll learn an amazing amount about the limitations and advantages of brute force versus domain heuristics. Compared to that, I find the man versus machine jungle drum exceedingly dull.
Damn. I can't believe I wrote a post this long in a freaking web form. When the computers find out, they'll laugh like hell. Long live 1980.
C++ defines string literals the same way C defines string literals. Compatibility with C has never been a negotiable feature.
If you are making heavy use of the standard string type, your main use of string literals will be as initial values when creating String values. A typical implementation for a sequence type from the C++ standard library is to store pointers to the beginning and end of occupied storage. This makes ptrdiff_t the type used to count the number of elements in the sequence, a size on the order of the program's virtual address space.
A typical string class will support initialization from a C string by first determining the string length (which can be determined at compile time if you wish to do so), allocating enough space in the String class object, then copying the character bytes. You can copy the representation of a zero terminated string as efficiently as the representation of any other string implemenation I've ever seen.
The drawbacks of zero terminated string literals are a few percentage points in a typical C++ program written in a modern idiom and the price is usually paid outside of important loops.
There is a problem with the use of C string literals as constant values in template metaprogramming. Template metaprogramming often seems like death by 1000 leaks. That's the price you pay to implement novel abstractions that don't leak in any of the usual ways. If the assumptions change, a template metaprogram will vigorously adapt and the application programming working on top of the template library might not even realize that all this complicated stuff is taking place, other than noticing that compiles consume 500MB of virtual memory and take 20 minutes to complete.
Slashdot Mirror
I've been with pair.com for four years and I have seven domains with them. I've been extremely happy with the service there.
Recently I had a run-in with their support staff when I submitted a support ticket about how to configure my own installation of SpamAssasin to filter POP mailboxes. Their web based configuration tool overwrites the control file I need to change every 15 minutes.
The first response was "this is almost the right answer, but I don't know the last part, I'll send you to another tech". It went downhill from there. Had to fire back the ticket seven times when five people in the middle of the chain barely bothered to read the specifics and continued to propose solutions where I had already clearly stated the reason they wouldn't work.
The service is great (overall) and the prices are reasonable.
My only significant complaint (aside from that one support incident) is that there are some security problems between web users on the same host. No matter how you set your perms, PHP scripts run by other users of that host can read any file in your personal tree that www-data can read. They only have to guess your main site directory (parent dir is r not x) then they can crawl your entire tree by simulating Apache behaviours. You can slow them down by putting strange stuff in
There is also a way to botch your
Basically, a great service.
These extra costs are guilt by association. How does two OpenBSD boxes add up to a greater risk of being trojaned than a single Windows box?
I suppose the number of hosts could correlate to these cost variables, but many other indicators correspond a lot better, and of those many are negative correlates (power users need less support than novices and are less likely to harbour or spread trojans).
Do I get a discount from my ISP for configuring rules into my OpenBSD firewall preventing any of my client hosts from *sending* packets on known virus ports? I didn't think so.
It's totally bogus to paste someone with extra costs on the implication of a correlate that can be directly disproven for the case in hand.
Actually there are shades of the Laffer curve here. "If we had no hosts, our costs would be nill. Therefore, every extra host is an extra cost."
Oh my god! This guy doesn't get it either: Laffer curve diatribe.
The problem with the Laffer curve is that *even when* the tax rates are above the value of maximum tax revenue, lowering the tax rate isn't guaranteed to move you toward maximum revenue. You could be caught in some local sworl.
The problem here: the Laffer curve is a curve, not a function, and there is no justification from the premises given for assuming the Laffer curve isn't self crossing.
There's a much deeper point here. In OOP languages there is the notion of public interface and private implementation.
In the case of NAT, the public interface is the amount of traffic generated. The private implementation is how that traffic gets distributed among different hosts behind the NAT.
When a utility decides to regulate a resource on a dimension that they can't even properly measure, what they are trying to regulate has no bearing on their cost structure for providing the service. If the cost structure was impacted, that amounts to something that can be measured directly (amount of traffic, number of packets, time of day, etc.)
The main of this message is that for a certain class of motivated users, the private implementation of his NAT makes it possible for a collection of active machines to have as low an impact on ISP provision cost as a single user who takes no active measures to blunt the impact of his usage pattern.
From the point of view of economic benefit, this is entirely cracked. The point of economic competition is that users who are motivated to maximize the efficiency in their use of scarce resources should be rewarded, otherwise the economic system is encouraging wasteful behaviours.
One of the purposes of creating the legal category of a "utility" sector is to enact legislation to prevent the kinds of wasteful pricing policies individual companies find most profitable to pursue.
Sure, you bet they'd love to change a monthly fee for every device with an IP address anywhere. Five years from now the average fountain pen will have its own IP address.
It's really quite ridiculous if you peel back the implications.
Really, the only sane model is to price a bit pipe on bits transported (congestion weighted if they so desire). If they wanted a per host/user business model, they should have gone into the business of offering network services above the level of the raw pipe.
What the NAT police are after is gatekeeper taxation. A nice business to have if the people you tax are stupid enough to play along.
I've had terrible experiences with HP inkjet printers. I wonder if there is any quality left at all. Hard to believe that HP was once the company mentioned in hushed tones along with Tektronix.
Recently I was helping a friend recover their system from a hard drive failure. Got all the data back after throwing the drive in the fridge for 24 hours. That was a lucky one.
We paid the price later when we installed Windows 2000. First the CD burner software hosed the machine so that it bluescreened on boot up.
We fixed that problem with a fresh Windows 2000 install (and a different CD burner package), then we tried to install an HP PhotoSmart printer. Boom. More blue screens.
It was a complete nightmare. Eventually we could only boot the system in safe mode. In order to fix the problems caused by the HP PhotoSmart driver, we had to run some installer. The installer would start up and then tell us that we had enough processor, memory, and disk space, but we didn't have enough pixels. The installer refused to run in 640x480 mode. Geezus Murphy, we are in fscking SAFE MODE running the installer to pry out the POS crap HP printer driver that is forcing us to boot in SAFE MODE.
Thoroughly battered, beaten, and bruised I resort to the venue of last attempt: write an e-mail message to HP customer support. Actually, it isn't writing an e-mail, it's typing twenty long and precise paragraphs (we tied so many things it was hard to list them all) into a gun-slit web feedback form.
OK, press submit and maybe HP will sort out the mess. No chance. The instant I clicked submit the browser came back "404 not found". HP can't even keep their web support infrastructure running.
By this point there wasn't a tower high enough to pitch HP off of. Any vestage of Hewlett Packard that Walter Hewlett was trying to protect has been thoroughly assassinated.
But my friend wanted more punishment. She actually called the phone support desk. They talked her into many different bluescreens, told her that there must be something wrong with her machine (it worked just fine with the same printer running 98 before the hard drive melted down).
Their final recommendations:
- upgrade IE 5.5 to IE 6
- upgrade Windows Installer
- upgrade from SP2 to SP3
It seems like the HP PhotoSmart printer wasn't working because we hadn't succumbed to the new and improved licensing conditions.
And where would HP be to help us if these upgrades broke something else? Where the button to unclick those license agreements when you decide they haven't improved matters?
I have trouble understanding why the new HP bothers to exist. It reminds me of the era where Compaq went from having the best stuff to having just the weird-ass weird stuff that you couldn't service because the parts were all funny. It was a small miracle if you could get the original Warcraft to run on those beasts. Warcraft was worth the bother, the HP PhotoSmart wasn't.
The collective job is a mixture of changing the sheets, emptying the bedpans, dealing with the dilapitated, the demented and the elderly, funerals, autopsies, coroner's reports, pace makers, life support, and tense meetings with the next of kin.
Nurses and Orderlies. But mostly orderlies. Get over it.
If you try zsh and you don't think it is worth the bother to lug zsh around, you didn't have much need for zsh in the first place.
I lug zsh everywhere. Do I really want to? Absolutely.
I've always thought that the JVM security model was the moral equivalent of eliminating the FDA in favour of tamper resistant pill bottles.
Tamper resistant packaging is a darn good idea. But it's not a good idea to be so impressed by the packaging that we forget that how easily well intentioned people can create combinations of carbon, hydrogen, and oxygen and a few choice flavour additives that kill.
Bottom line: no matter how much rocket science you pour into the packaging, you still have to ask hard questions before ingesting the contents into your body.
Unless you believe that large software companies have entirely different profit motives than large pharmaceuticals.
A long time ago, at a time in my life when I had more money than brains, I bought myself a Fat Mac with 512K memory and two floppy disk drives the day this model first hit the streets in Toronto.
My girlfriend at the time (I guess there is an upside to having more money than brains) needed to conduct an experiment in cognitive psychogology to complete her undergraduate philosophy degree.
She decided to conduct an experiment in reading comprehension. Both groups were asked to read the text, but with different reading instructions. One group was instructed to proofread the text, the other group was instructed to read for comprehension.
We decided that programming this experiment for my new Mac would automate the timing controls, automatically measure the proofing reading results (how many words were marked with a mouse click), to collect the multiple choice results, and record the text of a written response question (in a dialog box roughly as feeble and distigusting as the web form input box used to compose posts for slashdot twenty years later).
When I showed her the first version, her remark was this, "you have to remove the menu bar or I'll fail". I could see her point. For an experiment in reading comprehension you want to control every word of text presented to the subject. Her professor would see it the same way.
At this point I should have pulled out a roll of duct tape, sliced off a half inch think strip, and covered over the top half inch of the display.
But ego prevailed. Surely, I thought, I just need to read the big Apple developer guide phone book thing to find the right flag to the right system call to remove the menu bar.
Thus began three weeks in hell.
The only way I could find to suppress the menu bar was to skip the initial call to some of the Apple windowing subsystems. It seemed to work. But then my program began to crash in dozens of mysterious and different ways. Eventually I learned that the call I had skipped initialized data structures required by many other subsystems.
Then I found other system calls that would hide the menu bar temporarily. But the nasty thing would reappear randomly as the user performed mouse actions. No matter what I tried, the cat came back.
Within a few months I several other frustrating encounters with the Mac architecture. I grew to despise the architecture of the Mac windowing system. I thought I could escape from Pascal hell by installing the Aztec C compiler. I was instantly much happier, but it wasn't a productive situation because the underlying C to Pascal mapping was full of bugs.
Then I was forced to buy an 8MHz PC for a programming contract. I put the hideously Fat Mac into a closet and I can barely recall using it since. I made one effort to salvage my investment by inquiring about the cost of a making a modification to install an internal hard drive, but the price was outrageous (almost as much as the entire turbo PC I bought instead).
Thanks to Apple, I learned a extremely valuable lesson about decoupling policy from implementation. One man's policy (Steve's) is another man's hell (mine).
Twenty years later, I never complain about X Windows. At least I know that this of kind of question *can* be answered.
Gawd I hated that machine. And it turned out the girlfriend wasn't much better.
To quote a reference I quickly dug up:
In 1976 Earl Butz, the secretary of agriculture, resigned after it was widely publicized tht he had made a racist remark. Butz's statement had been: "I'll tell you what the coloreds want. It's three things: first, a tight pussy; second, loose shoes; and third, a warm place to shit."
Recently, if I believe what I find on the internet, Butz was elected to the NRA board.
Note that doesn't read "erected to an NRA board". Damn.
We have two broadband links to our small downtown office. Each of these links terminates at an OpenBSD firewall. We briefly looked at what kinds of fail-over models being multihomed in the DHCP ghetto makes available to us (actually our ADSL service provides two static IP addresses, but they still grant you those addresses via DHCP leases).
We can do some cool things with Zebra (OSPF) over our VPN (all our offices / developer's have their networks in different portions of the 10.x space). If segments of our VPN fail, the traffic would find other segments forming a viable route to the final destination. Within the VPN we can pretend that we have a real network.
Fail-over to the outside world is more difficult.
One issue which no-one has mentioned here is stateful firewalling. Even if we can broadcast route information to the two OpenBSD gateway machines, it will break stateful firewalling completely. That said, most of our traffic is not session oriented. A broken HTTP request will fail-over at the application layer. No biggy.
The primary form of session oriented traffic we use is OpenSSH tunneling. The simple solution here is to remove stateful firewalling on the SSH port. I have to doubt that stateful firewalling your SSH ports accomplishes much.
For fail-over of our public web servers we decided against nasty DNS schemes. You don't get load balancing (just load sharing, which is not the same thing), there are issues about DNS record caching, your control is poor, when problems arise your ability to investigate the problems is all in a muddle. We don't tolerate that kind of thing here.
Instead we are directing all public URLs to a highly reliable and well connected public hosting company. That host is returning a frameset document containing a single frame window, with the embedded frame directed at one or the other of our two broadband services. Our firewalls are sending pings to the public hosting company so that the PHP script there can decide which of the two URLs to send out on each request.
There are plenty of extra complications since we are also thunking requests into different SSL compartments and we are using the OpenBSD firewalls to run chroot Apache in proxy mode (which allows them to filter the URLs before they reach the internal content servers).
With the right magic additions to the frameset code we can make the public URL track navigation through our content without revealing the ugliness of our internal fault-tolerant, SSL compartmentalized URLs.
Framesets suck, but not nearly as much as borking the DNS standard.
We are fortunate that our client base is narrow and we can impose client browser requirements. Our traffic volumes are low enough that we can afford the overhead of trampoline packets on each URL access.
We achieved a fairly low standard of fail-over in the end, but the good thing is that we didn't have to involve anyone else, and the fail-over we do have is sharply defined and easy to diagnose.
In our small shop, we use OpenBSD for firewalls, FreeBSD for file servers, Debian and Windows 2000 for workstations. For any given purpose, any of these systems might have a decisive advantage. I listed them in my rough order of bias. At the top of the list is maximal purity coupled with the narrowest applicability. At the bottom of the list is maximimal impurity coupled with universal applicability. We try to push our subsystems uphill where possible, but we're not zealots about it.
If I had to pick just one I would pick Debian and I'd be 20% miserable all of the time, but hardly ever 100% miserable (because something you really depend upon works badly or isn't available at all).
My only complaint about the package system in Free/Open is that selecting your packages is somewhat more manual than it ought to be. It's a bit of a pain to clone a known configuration at a different revision level because you have to pick exactly the right package names. I'm no fan of dselect, but dpkg is pretty livable.
Either way, if the package system is your main area of concern, it's a certain sign you have nothing important to accomplish. They both get the job done well enough if getting the job done is your main concern.
There are too many presumptions in this comment about JIT. The protections Theo is using are imposed by the VM system, which means the protections are relative to a *view* of memory. It's not obvious to me that the JIT compiler needs to share the same view of memory as the process for which it compiles. I can't bring myself to believe that for a typical invocation of the JIT compiler, one process transition is a dominant cost.
From the article itself:
[[[
These exploits require a high degree of precision. I've tried to take out most of the guesswork, but there are two things that might cause the exploits to fail. The lpstat and rdist exploits expect certain things to be in the environment at exact locations.
]]]
Probably the best metaphor here is the game Twister. The new work by Theo et al. forces the black hat to put his left elbow on the blue bubble. Sure, he can still do something devious with his right leg. But if Theo keeps dealing out the cards, eventually his bowels will explode.
In constructive software development, the programming cost is widely regarded as exponential in the number of constraints faced. Yet in the popular lore, for a black hat, a sliver of a glimmer of a faint and twisted hope is all in a day's work. This from the lips of the same people who pretend not to believe in Area 51.
Has anyone ever considered configuring an HTTP byte server with a filter on the referrer tag for ".slashdot.org/"? With the appropriate server response, the site would appear
While you are at it, you should plug the spill pipe in your toilet tanks (the one with the opening just above the high water line). In a properly engineered toilet, the float will always float and the valve will always valve. And if the float doesn't float, hey, it's not our ceiling that will begin to drip.
A firewall should not be considered as a wall. A firewall is best regarded as a damping mechanism. My firewall is configured to make it impossible for my internal network to send out bad packets (forged return address, strange TCP/IP bits or fragments, anything addressed to known virus promulgation ports). Those rules function like the spill valve in the back of your toilet tank. Even if something goes terriby wrong (e.g. with a binary patch where I can't even read the source code) and my float doesn't float or my valve doesn't valve, I'm not going to cause a septic disaster for everyone "downstream".
My suggestion: stop polishing your Brass Testicles ninja sysadmin award and start thinking about reality.
*sigh* C++ doesn't stop you from playing hockey in your pajamas, but it does offer a dozen new varieties of protective equipment not found in the C language, covering just about every risk category short of programmer incompetence. One can argue that programming shouldn't be a contact sport to begin with, but try not to insinuate that C++ doesn't offer appropriate safeguards for the risks involved.
If a programmer adopts the STL containers, there are no buffers allocated on the stack. The STL idiom makes it more difficult to write past the end of a container unwittingly (it's very easy to ask a container for the last legal address), you can elect to use range checked implementations, you can structure your code so that there are very few places where the container can be accessed through a non-const pointer/reference (so the lines of code you need to be anal about are few and obvious), in difficult cases you can often use compile time mechanisms to impose compile time range checking (templates), or you can derive your own container objects which impose "non contact" safeguards on every hung-over asterisk with roughly the same time and space penalties as the languages which impose these semantics by default.
There's one more observation that ought to made here. If the programmer invests the time and energy to master all of the mechanisms which C++ provides, when he goes back to bare naked C (shudder), his C code will be just as correct as his C++ code. Once C++ teaches the proper mental disclipine, the discipline alone resolves 90% of the problems.
I think the root problem with C is that it doesn't force the programmer to master any concepts. "C with classes" should have been "C with concepts". The ++ stands for "clue".
If this guy's math is correct, that moving from 1024 bit keys to 2048 bit keys increases the computational cost of breaking the key by a factor of 2^1024, then this guy must also believe--in some dark corner of his brain--that the first 1024 bits of key also requires 2^1024 operations to crack. I think this fellow needs to sit in a corner and count his way up to 2^1024 before he posts again.
/. lamers we read the initial three words of whichever link we clicked first and immediately jump to one of serveral interpretations:
/. posters in category (4) would get jobs as microwave oven repair persons. Then everyone would become a lot more cautious about their dialectic coefficients.
Unlike the symmetric ciphers, the public key cipher does not have a pure exponential structure. If it did, we'd be using 128 bit keys and that would be more than adequate.
Let's just pull a sample key strength function out of some dark place. Let S represent the effective public key bit strength.
S = 1/4 * log2(N) * sqrt(N)
N=256 S=32
N=512 S=50
N=1024 S=80
N=2048 S=124
The new discovery modifies this relationship, but since we are all
1) S = 1/4 * log2(N) * sqrt(N) - 10
// constant factor improved
2) S = log2(pi) + e/4 * log2(N) * cuberoot(N)
// root improved
3) S = 1/4 * sqrt(N)
// log2(N) term eliminated
To confuse matters, it happens that (1) and (3) amount to pretty much the same thing: a rough factor of 1000 in the computational cost of cracking a key.
orig (1) (2) (3) (4)
N=256 32 22 36 24 -698
N=512 50 40 51 41 -442
N=1024 80 70 70 70 70
N=2048 124 114 97 113 1094
N=4096 192 182 132 180 3142
N=8192 294 284 180 281 7238
I didn't mention column (4). That would be the hypothesis of the post I'm responding to, where S is linear in N with an origin in the vicinity of 2^70 (a high speed computer running for one year) for N=1024.
In a perfect world all the
Maxwelld is a daemon process that governs a small gate. For all queries that suck, maxwelld closes a tiny gate. Whenever a query that doesn't suck comes along, maxwelld opens the gate. Only the important and necessary queries are allowed through. This does not violate the laws of entropy. Physicists believe that the inverse entropy generated by this process is radiated into the Murphy field.
bigasterisk.com has address 64.139.32.113
% host 64.139.32.113
113.32.139.64.in-addr.arpa domain name pointer ip-64-139-32-113.dsl.sjc.megapath.net.
The reason Drew perceived this as careless and malicious is that he's not as clueless about how easy it is to determine that a site is hosted on a cable modem. Even a /. editor can correctly spell the 'host' command.
So far no one has mentioned IDT, Centaur, or the Winchip. That product was developed by a very small team who shrewdly avoided applying great complexity for small gains. It's not that difficult at all to great price/performance working a couple of litho generations behind the bleeding edge. (That's an optical pun BTW.)
Translate "can't decide" as "nothing impresses". It's like a beauty competition where one girl can't add 2+2, the next forgets the words to the song that she sings, the final contestent has a missing front tooth. If he did another 130 graphs, do you think these problems would magically disappear?
That may be true, but perhaps the users of OpenBSD do need a book. I started with OpenBSD 2.6 after many years surviving under DOS/NT by installing POSIX shell utilities wherever possible. I knew TCP/IP networking extremely well and x86 hardware inside out. The excellent OpenBSD online documentation was a tremendous help, but it certainly left me hanging on many, many occasions. If you think OpenBSD doesn't need additional materials, it's because you're already an elite member of the OpenBSD cabal. I earned my OpenBSD stripes the hard way, but I'm not so proud of it that I think others need to strike their heals on as many rocks as I did. If every discipline takes that approach, what you end up with is highly fragmented community where no one can afford to have more than three skills and the vast majority of communication takes place between people who already share most of the same knowledge. The world doesn't have to be that way just because you find that acceptable with respect to your own narrow purposes.
For new users setting up an OpenBSD firewall/NAT for their home network, the book needs to stress the importance of configuring the resolvers correctly. I experienced several extremely frustrating days because I didn't understand that portions of the resolver were client side. I mistakenly presumed (for a while) that bind on my firewall was acting on the localhost resolve.conf settings on behalf of the DNS clients. It took me a long time to shake off this small misconception because resolve.conf was being clobbered by
Another thing that bugged me was "Don't log in as root". I completely understood this was a good idea. However, there is a substantial skill set required to work efficiently learning how to configure and admin a Unix box using root only as necessary. New users don't have the magical knowledge the previous poster seems to assume about what operations require root and what operations don't. An 80% confidence level doesn't get you very far. If it takes ten steps to configure something and a new user has an 80% confidence at each step, when it doesn't work the first time (and it is not likely to if you have undertaken ten steps at 80% confidence) you're up the creek without a paddle in knowing where you went wrong.
OpenBSD is actually rather weak in explaining how to dig into the system for corroboration that individual steps have worked successfully. You can find that material easily if you already know what you are looking for. I've complained about this upstream from time to time and the answer seems to be "if you don't know where to look, it's not our problem to help you".
One thing that would have been extremely helpful at the outset was to know how to use netstat to determine which sockets a daemon was binding on and ps to determine what security context that daemon was running under.
Another area where I made many mistakes was not knowing under what conditions a daemon needed a HUP in the ass. I be busy reconfiguring something and forget to HUP a critical process and then I would come to wild and incorrect conclusions about why my syntax was broken when in fact it had been correct already on many occassions. The OpenBSD man pages are not always blunt enough: if you change this file, you must HUP this process.
The area where I would find the most value is advanced security and networking. I've only played a bit with Kerberos, IPv6, and IPsec. I don't know the exact list of things to examine to determine whether a daemon process is chroot exactly the right way to minimize security risks.
OpenBSD is complex enough that you can't learn all the best practices right from day one. I put a lot of effort into mastering the firewire rulesets and OpenSSH. I didn't put the same effort into the Unix security model until a year later. I made some good guesses about what I could defer and some bad guesses. A book to help me make better guesses would have been valuable.
At this point I've installed a dozen OpenBSD systems and most of this stuff comes automatically. I've reached the point where I don't really an OpenBSD book any more. And since I don't need this book, I'm sure no one else does either. A semblence of documenation is adequate for all comers, certainly. My struggles and setbacks were just payment for lack of
intelligence and motivation. The logic of the previous post seems to be along the lines that handing someone a book to teach them to read is either useless or redundant. I don't agree.
After encountering a post like that I hardly know where to begin.
First of all, IBM participated in this chess match as a publicity stunt. The technology they were promoting was their ability to built a box with a very large number of computing elements that coordinated effectively. The nature of the standard chess algorithms (90% brute force) make them a good "animal model" for the kinds of technical problems involved in building massively parallel computing systems.
Chess has an additional chachet because in the history of computational theory Alan Turing and others from his era considered chess to be a good "animal model" of complex human thought processes. Back in that era it was broadly assumed that the hallmark of human intelligence was formal reasoning. Within twenty years the evidence started to mount that the human mind is actually very poor at formal reasoning, and that the areas where the human mind holds significant advantages over deductive computation are of a stochastic nature (what people often refer to as "pattern recognition").
The next turn in this story is uniformly neglected once the narrator begins to beat on the man-versus-machine jungle drum. (Another characteristic of the human mind is that analytic thought ceases completely once the preening reflex takes over.) It turns out that it is more useful to build machines that do the things we are not already exceptionally good at. Like adding more than three numbers together and getting the right answer, first thing on a Monday morning after the Super Bowl weekend.
The reason that computers have been so greatly developed in the brute force dimension is because humans are terribly bad at this stuff. The reason why computers have not developed stochastic algorithms of the same power is because humans are already damn good at stochastic pattern recognition. Hand me a four function calculator I can calculate sums and products faster than Newton, Gauss, or Kepler. Yet our best results in visual processing are easily outmatched by a four week old puppy. Do you think it is easy to win grant approvals to underperform a four week old puppy? This is yet another example of how poor the human mind is an analytic reasoning. It's terribly stupid for us to think that underperforming a four week old puppy is slight progress, but we do.
A lot of people say, because of this situation, that computers aren't very good at this kind of application. That's not true. They are good at this kind of application (and they can still get an awful lot better), just not good enough to impress anyone who was born with superior innate abilities courtesy of mother nature and 100 million years. If you look at recent advances in accoustic processing, such as filtering background noise, there are clear signs that we are entering a phase of surprisingly rapid progress. Visual systems are a harder problem, I suspect the same progress curve will be shifted back by about ten years.
In this light, the most important knowledge we gain right now from the study of chess computers is the nature of the boundary between brute force methods and alternative methods. Deep Blue represents the fairly extreme side of brute processing. The advantage held by Deep Blue, at that point in time, was the vast number of coordinated processing elements it contained. IBM had the choice of pursuing a pure brute force approach, or a brute force algorithm tempered with subtlety. Unfortunately, the state of the art is such that adding subtlety to a massively parallel system seriously degrades the massive parallelism. Pure brute force is relatively easy to coordinate. Hybrid brute force is a nightmare to coordinate.
IBM being what they are, and the economic incentives for begin good at brute force being what they are, you can guess which tactic IBM chose. There was only one problem remaining. Pure brute force was not yet at the level of beating Kasparov. The pure brute force has a fairly large number of known weaknesses and sinkholes. The problem for IBM was to "tweak" the evaluator and search heuristics so that it didn't fall into the classic holes (which Kasparov would have exploited mercilessly). So they trained the program (by debasing various weighting factors) to avoid the kinds of positions that offer blood to a shark of a known and especially vicious species.
At this point it is worth mentioning that Kasparov was actually a fortunate choice of opponent for IBM. Kasparov has long been known for his tremendous ability to compute complex lines of play and he has used this weapon to crush many excellent players who could have competed on even terms otherwise. The problem for Kasparov is that his computational ability is roughly equivalent to a four day old puppy feotus compared to the computational ability of Deep Blue. Because Kasparov favours computationally rich positions, he has a tendency to play into mentally exhausting positions if his adversary shows the slightest weakness. The only aspect of the competition I regard as unfair is that Kasparov wasn't given nearly enough time to rest between games.
The question about building a computer SPECIFICALLY (emphasis from the other dork) to beat Kasparov really misses the point. I would guess there is perhaps 1% of such a system that can be tweaked without the immediate prospect of the entire house of cards collapsing. Half of the Deep Blue source code has nothing to do with chess at all (the parallelism, transposition tables, the basic min-max framework, etc.) Leaf evaluator functions have been studied for decades. How much do you think you can improve one in three days? And still have it run correctly in dedicated silicon? I don't think so.
So you end up tweaking a few weighting factors, such as the desirability of retaining the queens. You can witness this same kind of tuning in an elementary school chess club: "Joe is a titan with his queen at the end of the game. I'm going to try as hard as I can to whack his queen with my queen!" Kasparov SPECIFICALLY beaten by a kindygartner! (To quote Home Alone.)
The kind of tuning they did between games is on the order of the batting coach telling his hitters about the pitcher they will face in their next start "watch out for that wicked slider nailing the outside corner". If they didn't tune the program between games, once Kasparov found an area of superiority, he could have won every game on the same basic pitch. What would be interesting about watching chess played like that? And these tweaks were no simple matter. Your desire not to see the queens exchanged could cause some other aspect of how Deep Blue plays the game to deteriorate spectacularly. There's a name for this risk: it's called regression, and it's the curse of clever improvements. If tweaking was 1% as effective as the previous poster would have us believe, a computer would be president already. If your program is tuned to a local optimum, any single parameter you adjust makes the program play worse. In human beings 99.9% of genetic mutations (cosmic tweaks) are benign (if you are lucky) or deleterious, often fatally deleterious. In fact, large chunks of the human genetic system is devoted to removing tweaks. Kasparov didn't get to be world champion by having only one strength. He beat everyone out there, who represent the best of every different style. What do you think was happening between games? They change a 1.6 weighting factor to 1.55 and Kasparov falls to pieces? His vanquished opponents will lynch you if they hear you saying that.
I think Kasparov with more rest between games would have beaten Deep Blue. Ten years from now a machine computationally equivalent to Deep Blue will be a very ordinary piece of equipment. What's the point of keeping Deep Blue alive if they aren't going to invest in continual improvement at the software level as well? Anyone who thinks IBM was setting themselves up for a long term participation in the man versus machine debate really has no clue as to why IBM involved themselves in this chess match to begin with.
Let's not forget that Deep Blue played some positions Kasparov was convinced he would win better than Kasparov believes any human opponent could have played those positions. He commented at the time on how Deep Blue would constantly amaze him by finding slight resources in losing positions that stretched the process out, sometimes until Deep Blue stretched the losing position all the way to a draw. This is a classic observation about computer chess: if these programs weren't so damn good at hording slight resources, they might not be despised for their strategic weakness. The problem with computer chess is they are penny wise and pound foolish. But then we forget that the computer has no difficulty in keeping track of 100,000 slight advantages in a position each worth 0.001 cents.
What I find interesting to observe is the progress of programs like Fritz that plays at a very high level with not nearly as much brute force as employed by Deep Blue. It's a very difficult thing to successfully exchange brute force with additional subtlety. It's like grafting a plastic heart into a human being. Most forms of subtlety are immediately rejected by the host brute. It's difficult to add subtlety into chess algorithms, because the subtlety has to be manufactured exclusively with platinum, titanium, and teflon, otherwise it does more harm than good.
The best thing about having such great chess programs on the classical paradigm is that they will serve as an excellent foil to test out new classes of algorithms. Along the way we'll learn an amazing amount about the limitations and advantages of brute force versus domain heuristics. Compared to that, I find the man versus machine jungle drum exceedingly dull.
Damn. I can't believe I wrote a post this long in a freaking web form. When the computers find out, they'll laugh like hell. Long live 1980.
marriage
C++ defines string literals the same way C defines string literals. Compatibility with C has never been a negotiable feature.
If you are making heavy use of the standard string type, your main use of string literals will be as initial values when creating String values. A typical implementation for a sequence type from the C++ standard library is to store pointers to the beginning and end of occupied storage. This makes ptrdiff_t the type used to count the number of elements in the sequence, a size on the order of the program's virtual address space.
A typical string class will support initialization from a C string by first determining the string length (which can be determined at compile time if you wish to do so), allocating enough space in the String class object, then copying the character bytes. You can copy the representation of a zero terminated string as efficiently as the representation of any other string implemenation I've ever seen.
The drawbacks of zero terminated string literals are a few percentage points in a typical C++ program written in a modern idiom and the price is usually paid outside of important loops.
There is a problem with the use of C string literals as constant values in template metaprogramming. Template metaprogramming often seems like death by 1000 leaks. That's the price you pay to implement novel abstractions that don't leak in any of the usual ways. If the assumptions change, a template metaprogram will vigorously adapt and the application programming working on top of the template library might not even realize that all this complicated stuff is taking place, other than noticing that compiles consume 500MB of virtual memory and take 20 minutes to complete.