This request is outrageous. There is any amount of material on the net already about security theory and practice. I've read most of it myself. How much of it am I practicing myself? Not very much. I'm not a full time sysadmin, I sysadmin during my recess breaks from my development activities. Why do I not bother to take security measures I hear preached on every street corner? Because the devil is in the details, and I can't afford to have my FreeBSD server go offline because ICMP was accomplishing something I didn't know about.
This guide is more useful to me than another dozen sermons. It gives me confidence that I can lock down aspects of the system I don't have time to understand in depth with a modicum of confidence that the essential functions of my box will continue to perform.
In my development life there are some aspects of security I work with daily: OpenSSH (tunnels, authpf), OpenSSL, IPsec. Despite my meager time budget to practice host-based security, I'm far from clueless about good security practices.
Do people forget what an incredible sinkhole of human productivity security has become? A simple overview of X.509 destroyed a week of my time. Yet another horror show more easily avoided in theory than practice.
One of the problems with Google is that you never see the thickness of the fully assembled tome. I recall an era where system documentation was measured in shelf-feet. Whenever I had the urge to make my life more complicated than necessary, I just had to look at that bookshelf and ask myself "do I really want to go there?"
I'm at the point in my life where I'm never again going to set aside whole days to master intricacies like all the special perm bits on the FreeBSD implementation of FFS.
I cherish the people out there who return from the trenches with a tattered cheat sheet with the barbed wire, machine gun nests, and landmine locations carefully documented. And then I read highly rated comments from the Rear Admiral types that "this is all well and good, but it isn't another volume of War and Peace". I would love to find to a complete set of VAX manuals on Ebay to donate to this idiot, but I don't think I could afford the shipping charge.
What this article needs is not more theory, but more warnings about "if you experience this kind of problem after making these changes, you took your security measures too far too fast". The art of security is not in knowing what you ought to be doing, it's knowing *what you get away with hardening* given other constraints, such as having any time left over to accomplish something productive.
I always remember the famous quote about building the Fermilab accelerator. When challenged about how Fermilab improved national security, someone shot back: Fermilab is the kind of project that makes America *worth* defending. People and nations who can't grasp that response end up eating their own tails.
I read an article on Science Daily, IIRC, about the concept of hormesis: that low level exposure to pathogenic forces improves the health of the organism.
A few years ago I read an article about the spread of bacteria when handling raw chicken. They asked a number of people to prepare a roast chicken starting with a sanitary kitchen, and then they went around afterwards looking for salmonella bacteria. The woman in the study who cleaned most compulsively proved best as smearing the bacteria onto every kitchen surface. Unless you clean with bleach, the average soapy rag is just an efficient distribution system.
Compared to kitchens and door handles, the average floor is a dose of penicillian. Hormensis from fallen gummy bears prepares my body for food that has contacted the kitchen counter for more than a few seconds.
Don't recall exactly where I read about the salmonella study, but it was around the time that The Sciences was still good, so it was a while ago.
I don't follow this argument. There is no onus on me to reveal anything about myself to a party that contacts me through their own error.
If there were such an onus, it's hard to imagine how many "errors" would be made by this kind of outfit.
The second error in this argument is confusing people with their phone numbers. I wonder how many "business relationships" exist between companies and unknown parties as a result of my habitual carelessness when filling out web forms.
No, the onus is on the blood suckers to reveal the person they are trying to reach, and until they do, they are practicing harrassment.
It works like this: pick up the phone, dial the number from your corporate database, wait for an answer and then ask "Can we please speak with Mr Bob Dog?" "One moment, I'll get him". "Hello, there, are you Mr. Bob Dog?" "OK, we have an issue to clear up."
I learned how to type on an Underwood manual typewriter in a grade 7 typing class. I was barely strong enough to lift the carriage with my pinky fingers to get capital letters. I used to do 30 wpm on a manual typewriter when I was still a puppy, now I type faster than most people think (not so hard really).
There's not much to it. Form the habit of using the right finger for the right key, and try not to look at the keyboard more often than necessary. Use the shift key opposite the hand typing the capital letter (added benefit: you'll never write in all caps ever again). Bonus points: put two spaces after every end of sentence punctuation mark (except in Evolution 1.2 which bites so bad it wraps the second space to the next text line--how can any editor in this age be *that* bad?).
Does typing fast help programming? Does being able to record your thoughts as fast as you can think help? I'll let you form your own opinions. BTW, you can tell a really fast typist, because most of the mistakes are whole missing. My biggest problem is that I can type slightly faster than I can spell unusual words. For some reason the word "bureau" always causes me a ten car pileup.
Worst name to type fast of all time: Krzysztof Czarnecki. He does cool research into generative programming. I have strong passwords barely that good.
One detail to bear in mind: sometimes you need to NAT within NAT. You can end up with nested NAT zones. 10.x.x.x does *NOT* NAT well within 10.x.x.x I've had to debug routing table illness for this situation several times.
My company makes a security product with its own Linux host, and the host operates cameras with a private NAT of its own. In one version, we had the Linux host and cameras behind an 802 network gateway, and the gateway performed NAT. We had the gateway configured to create a 10.x.x.x network address space within the private NAT zone. Then one day I brought the system home and plugged it into my own 10.x.x.x private network.
Do you think the Linux host inside the 10.x.x.x address space behind the 802 gateway NAT could access my local DNS server at 10.0.0.1 upstream from the 802 gateway? Not a chance.
For this reason, I tend to use all three zones for different purposes, depending on the size of the zone, and whether I think the zones might someday become nested.
I had to get back into microcontrollers, after a long absence (since the days when the 6809 was state of the art).
I decided to go with the Motorola HC12. Unlike the HC11, it runs compiled C code with reasonable efficiency (gcc supported), it's highly integrated, and you have a simple execution model (not very many registers, etc.) when debugging by hand. It's reasonably capable, and almost trivial to design your own project board (clock frequencies within reason, few external components required, every kind of I/O pin conceivable).
The more powerful versions have huge amounts of internal FLASH (256K), but not quite as much internal memory as I would like (8K is typical of recent versions).
There are cheap modules available from Technological Arts in Toronto. They don't seem to be very active this year with new designs, but they continue to supply their product line to local colleges last I checked.
Anything more complex than an HC12 I think I would want some kind of kernel OS. The next step up the food chain, in our evaluation, was an Atmel chip.
"The problem is that for the average AOL user, who to put it bluntly is probably both too stupid to figure this out on their own and too lazy..."
I call this arguing from the idiot. It's an interesting stance, because it leads to actions and conclusions based on the behaviour of idiots. I don't know about anyone else, but I attempt to *suppress* this term in my own decision making processes. One of the first signs of age and wisdom is the realization that idiots are a fixed point in the analysis.
As a good case in point, there's nothing anyone can do to prevent "the average slashdotter" from making posts like this. The best you can do concerning idiots is lean back with your pipe and waggle your hairy knuckles. There is no such thing as an average tropical disease, there is no such thing as an average idiot.
There are two things I hate about this article. The first is that it is a straw man attack. The second is his premise that no one think too hard. The users won't think hard, he won't think hard, so why should anyone else? I can agree with the first two, but I don't think it follows for the third group, those of us who conduct the development process.
I've never had any patience for the "take over the desktop" mantra. Satisfying the general public is the most difficult task in programming. Where this does this notion come from that importance is measured in eyeballs? I thought we ditched that one after the dotcom implosion.
The general population is not a fixed target. What was "obvious" to a non technical person in 1985 is far different than what is "obvious" to such a person now. Even if we all agreed that "one size fits all" would improve the landscape (over my dead body) "one size" is a moving target.
Finally, uniformity is a marketing process, not a development process. Leave the developers alone. For once, Apple had the right idea when they packaged FreeBSD in a translucent gumdrop (the gumdrop stands for the amalgam of two incompatible user interfaces, one nested inside the other).
Let's get down to brass tackies: there is a large segment of the population which is relatively careless about where they double click (beer goggles, teenage pregnancy, reality TV). These people are well served by Outlook and Explorer. There is another group that is more fastidious about how they conduct themselves. These people are better served by any other mail client and Opera/Mozilla.
The choice is not about windows managers, it's about lifestyle, and that choice doesn't go away no matter how you package the underlying technology.
I was talking with a friend yesterday about why the "Linux on the desktop" debate always strikes me as entirely moronic. I finally found the right words to express the situation. Linux can't "win" the desktop until people respond "who cares?" Relevance of the desktop is a false value. The best technologies are the ones you rarely notice.
How is pushing a button on a keyboard *and* the mouse at the same time "easier" than having a mouse with two buttons in the first place?
Apple aggressively marketed the one button mouse concept for years to promote their own unique slant on "easy to use" and then when world+dog discovers that the human hand has more than one finger, no one stops to ask what they were smoking.
What boils my cheese is how Apple gets away with a vacuous redefinition of the word easy.
Easy is one of the most complicated human criteria in human language. For a two year old, it is easy to go down stairs on your bum. That is how I always felt using a Mac.
When a teenager I discovered that stairs (on the way down) were mostly optional. I discovered that I could make it all the way to the bottom in a single bound, two steps from the top. Then one day my forehead sailed into the overhang, dropped me on my ass halfway down, with a concussion and a damaged tailbone. That's how I feel using older versions of Windows.
One Christmas morning I spent at my girlfriend's, she had an older house where the carpet was not glued onto the steps, but pinched down with metal rods at the nook of each step. The steps underneath were the old wooden style with the rounded projection. There were shiny patches from long years of use worn into the stiff carpet bubbles folded around the stair edges. I put my bare foot onto a shiny patch as slippery as a skating rink, then smashed my leading heal on every step all the way to the bottom. That's how I feel using Unix. Ten years later, that same heal still hurts in the shower.
One time I worked in an office building with highly depressurized stairwells. Because I still had my keys in my right hand, my pinky was folded outside the handle. I pulled hard to crack the airlock, the door swung open ballisticly (which I was prepared for), I was just to pull my hand free when hard steel door handle crushed the small knuckle of my pinky finger against a decorative rockface. What I didn't realized is that the decorative rockface stuck out six inches from the plane of the door hinges so it crushed my finger well before it finished swinging to 90 degrees. This left me with a mild, permanent disfiguration of that knuckle. I'm not sure what OS that represents, but both Windows NT and VMS spring to mind.
So here Apple comes along and proclaims that their stairwell is easier to use because there design has only one handrail, so you don't get confused about which handrail to grab, nothing can go wrong, and I'm supposed to feel impressed.
I think I could fill a 500 page book on stairwell design factors: step dimensions, surface materials, footwear, footsize, materials carried, overhead clearance, emergency lighting, evacuation, firefighting, bannisters and handrails.
At the end of the day the answer would be that different designs are better for different people, different tasks, different situations.
Not even a common stairwell has a one-size fits all solution.
One decision has made my life easier: never underestimate the complexity of the task you are facing. After beating myself senseless on dozens of different stairwell designs, that's the only kind of easy that still interests me.
If you really want to counter the SCO FUD machine, widely publishing the notion that this is a stock pump for the benefit of insiders, who might already expect the gavel to fall heavily against them (if proovable by the SCO shareholders the SCO executive could be facing a class action *after* SCO goes bankrupt), would hit them where it hurts.
Yet this weasel guest columnist would appears far too concerned about his own liability to float such a claim in a self-styled national newspaper, even though it would put a much sharper point on his broad interpretation of the situation.
Yet somehow his peronsal forebearance vanishes entirely when he finds time to suggest that major Linux vendors indemnify their own customers, knowing full well that the wrath and considerable litigious muscle of SCO will be violently focussed on the first company with the temerity to do so.
As every career activist knows, the success of this kind of agitation depends on finding someone sufficiently wet-behind-the-ears who does not yet comprehend that a carefully staged, photogenic arrest nevertheless leads to a permanent criminal record and a lifetime of legal discrimination.
Hey Wynn, we'd be more than happy to indemnify our Linux customers. Small obstacle: you first.
At one point in time Einstein was an unqualified patent clerk. Many years later, he is finally awarded a Nobel prize, because one of his three main discoveries was finally within the certain appraisal of his peers.
Interestingly, at no point in time were Einstein's qualifications equal to his peers'. He managed to pass the Achilles' Academy at a non-instant of time.
I don't understand this concept of indeterminate relationship. It strikes me that his claim boils down to saying that time and motion are not possible unless you regard the set of physical relationships as constituting an uncountable infinity.
But what is the big deal with that? R is uncountable on an open interval, but it still retains a fully ordered relationship.
Zeno's paradox functions because it forces you to analyze time as if it could be mapped onto a countable set (halving interval N).
That said, I don't regard time as a well defined physical quantity. Einstein proved long ago that time does not function as a simple ordering relationship. Yet the only reason I can see that we use the abstraction of time is to suggest that physical ordering relationships exist.
I tend to view physics as having a trinary logic: true, false, and ungrantable. A foundation for physics which was formally non-predictive (lacking a human interpretation of time) would certainly belong to the last bucket, for as long as time remains a proxy of human purpose.
I take a hard view on issues like this. If the standard body can't get its act together to deprecate a function this misbegotten, I have a hard time listening to anyone argue that compliance with POSIX for the sake of compliance is a good thing.
A standard codifies practice, and that is the primary work output of a standards body. But the moral authority of the standard does not rest on the fact that it has been endorsed as a standard: the practice it codifies must ultimately provide the moral foundation for its acceptance.
We all know that gets() should be taken out back by the toolshed and summarily executed. We all know we can't do this, because gets() retains a purely historical legitimacy.
This is why we invent fancy terms such as 'deprecated', where we admit that we've learned from our mistakes. Back in 1950, the use of CFCs didn't seem like suck a bad idea.
Once we learned the true effects of CFC on the ozone layer, refusing to deprecate CFC would have called into question the moral authority of the entire chemicals industry.
gets() pollutes the programming environment every bit as much as CFC destroys the ozone layer. I feel it sabotages the moral authority of the entire programming profession.
Someone commented that POSIX is in fact a living standard. That would seem to imply that the most recent POSIX standard has failed, once again, to deprecate gets(). To my eye, this is far more damning than if POSIX had remained unchanged for the last twenty years.
If the people involved in the POSIX standard care about standards and standards compliance, they should care enough to take the minimum necessary measures to sustain their moral authority, or they should be prepared to sit back as the world rallies around alternative codifications of standard practice that does live up to its moral obligations.
The analysis of Risk is a trivial problem. I once wrote a small program to do exactly the same analysis for Axis und Alies, a vastly superior game IMHO. Sometimes I played A&A for 24 hours straight and then couldn't sleep because of a pivotal scenario developing, usually a land grab in Indonesia by one side or another before a fateful invasion of Tokyo by the Americans.
Then I would get up and it would take another 24 hour day, several pots of coffee, and two trips to the beer store to play it out.
Axis and Alies has more degrees of freedom than Risk. The person losing units has the choice about which units to sacrifice. Not all units can attack other units. Submarines can't attack airplanes. (They laughed at me the first time I played for thinking I could do this, no one told me I couldn't, they let me buy four subs to defend against a fighter plane outpost. Later I was reading about submarine technology in WWII and I discovered that submarines often carried surface to air mortar shells--not terribly effective though).
Because of the problem of the exact order in which each player chooses to remove their own casualties, the complete tree explodes exponentially. However, in practice, the order of removal is automatic 90% of the time, and the cases where the removal order is debated tends to come at the end of a close battle where you are more concerned about what is left behind when the roles reverse than who actually wins.
In my program, the attack and the defense both submit their roster in a predetermined removal order. You could try different removal orders, but you couldn't make the removal contingent on battle outcomes.
My program calculated the exact probability of every terminal outcome. You don't even need Markov models, that's just a view of what the final math represents. The actual algorithm is like a fertilizer spreader that tosses little chunks of probability from one bucket to another until all the probability is sorted into buckets representating terminal outcomes.
It worked out to perhaps three pages of code. Memory requirements go up roughly on the cube of the number of armies involved IIRC.
I learned an incredible amount about the strategy of A&A from this program. Moral of the story: you can never have too many grunts. The strategic problem with grunts is they move so slowly. I learned to invest in waves of grunts (esp. for Germany) at the beginning of the game, get the waves moving outward, and once the fronts were established, replenish a fixed supply of tanks as these were consumed in battle, and grunts grunts grunts with the leftovers.
For my money, A&A is the best game I've ever played at pressuring the strategists to set up confrontations with the potential to break symmetry and channeling the game down unpredictable paths, forcing everyone to adapt their goals. Except for the Eastern front, where the game was a little too close to being historically accurate. For a five person game, being stuck with Russia was a chore in the early going.
No one has calculated Risk in 50 years? Phffff.
More likely, no one interested in that kind of analysis considers Risk much worth the bother.
The Markov analysis of Monopoly I saw a few years ago in SciAm was far more interesting to me. Verdict: Never underestimate "go directly to jail" as a form of rent control.
I had to laugh when I saw the comment that "go directly to Australia" was a fundamental Risk strategy.
When you roll over the level counter on Space Dungeon, it prints out the rhyme "you're the hero on level zero". I should know. That's where my undergraduate career ended. Level zero, 6,999,995 points.
With a little help from my friends while I guzzled an omelette.
My file server in my basement has three of those 4G Fujitsu SCSI drives, bought them on auction as discontinued Unisys models. They do resemble boat anchors, but I've never lost a byte. And for my most important files, I've learned that 8G of reliable SCSI RAID is more than enough.
The problem with those darn reliable drives is they caused me to go out and buy a bunch of 40G Fujitsu MPG drives (which also had the virtue of being extremely quiet).
Well, that second batch of Fujitsu drives are sooo quiet now, not even the worms can hear them.
I really should have put the center of those 4G drives in upside down. The case would be more stable when the drives spin up.
I've been with pair.com for four years, and my experience has been great. They do use regular IDE disk drives (last I checked), but uptimes are great nevertheless (ten minutes a year downtime as a reasult of hardware issues on my own hosts, plus one or two scheduled facility moves and major OS upgrades).
I also agree that pair.com has been good about increasing quotas to reflect realistic costs. I've never felt like I was being hosed just because they could get away with it.
However, I still agree with the original post. Average cost per MB/month has not tracked Moore's law in the hosting industry. Furthermore, the hosting centers could make mass storage available without the extreme uptime guarantees. A pair of hotswap 120GB IDE drives plus enclosure (we use ARAID in some of our cheap servers at work) costs about U$800. $5/GB/month would generate $600 per MONTH.
Obviously it's not the cost of the hardware, or the hosting overheads that create this cost model.
I've had applications where I didn't need host site backups at all. The documents generated were intended to be permanently archived, many documents were searched, few retrieved, we pulled down our own backups over the network as new documents were created. There was *no need* to have a document that sits on the server unchanged for years at a time backed up on the hideously expensive datacenter backup fabric, daily, weekly, monthly, or even yearly.
What creates this cost model is that people with large amounts of this kind of data are already well served by the colo model, so the hosted sites have a cost model to cover the datacenter storage they have *already decided* to build.
If you really want to understand this, read "Who Does What and Why in Book Publishing". The author explains that the internal cost models created by a publishing company can make it impossible to print a book that would make a profit (as viewed from an external perspective). Some publishing houses had internal formulas which allowed them to justify coffee table books with huge volumes of colour plates. Other houses didn't.
That's half the reason why hosted storage costs so much. The other half of the reason is that bandwidth is a commodity, so storage is the only degree of freedom hosting companies have in their pricing structure to ensure that revenues exceed overheads.
Absolutely there is a price distortion involved. It's not as bad as when DRAM cost $30/MB, but I still have that same sense of end prices frozen in time while the underlying technology is improving by leaps and bounds.
The best example ever: my local phone company wants another $5/month so that my voice mailbox can hold more than 20 voice messages. And this hasn't really changed since I first had a telco voice mailbox in the late 1980s.
parvus makes a five port 10/100 ethernet switch with extrended temp ratings in a PC/104 form factor (but you can use it for anything). It consumes just 1.25 watts. We had to hunt high and low to find a COTS switch for our own battery powered datalogger within this power budget. Most ethernet hubs/switches consume 3 to 5 watts.
After throwing around that piece of shit sound bite about "hiring known criminals" the same customer goes out into the parking lot and smokes a joint. Good thing he hasn't been caught yet, must be the universal instinct (aka moral fortitude) to keep a low profile at work here.
Haven't we learned anything at all from the Catholic Church and the Moral Majority? It seems to me that the people who most love to push these disgusting buttons of knee-jerk public opinion ride a very interesting elevator in their own private lives.
"It is unwise to be too sure of one's own wisdom. It is healthy to be reminded that the strongest might weaken and the wisest might err." -Mahatma Gandhi
Posts like this one make me wish we'd criminalize adultery. If criminalizing pot isn't enough to make people think twice, that's about the only thing I can think that would cast a wide enough net to shut the idiots up.
Nothing pisses me off like the virtuous who haven't been caught yet.
Now we understand why Microsoft has created some narrow "open source" situations: once they contrive to leak some of their own code into the Linux kernel as a plausible consequence of exposing some code to third parties, they'll finally have their way to crush the Linux windpipe, er, shut down the air supply.
Re:OpenBSD = Coordinated Innovation
on
OpenBSD 3.3 Released
·
· Score: 2, Interesting
Once you get used to it OpenBSD is not at all difficult to install. I use it entirely for network security (five machines) so I've never bothered to install X.
The man pages are excellent. The only place I've been bit is that the dclient man page doesn't mention that it runs a script in/sbin/dhclient (which is not an obvious place to look) and that this script clobbers resolv.conf That was a bugger to sort out back in the 2.6 days when I didn't what I know now about DNS and resolvers.
Since the 3.2 release of OpenBSD we have been making heavy use of chroot Apache as a forwarding web proxy to hide the real server machines from the public internet. This way all of our SSL connections terminate at an OpenBSD box. If OpenSSL requires a security patch, we only have one OS to update. And the security is great even if we don't patch, because only the chroot Apache on OpenBSD is exposed.
It seems like very version adds another great feature. In this release we are anxious to experiment with the failover NAT in PF.
I generally don't praise OpenBSD in public. I figure if you need it, you know it already.
I was reading a comment by the coach of the Edm Oilers the other day. He was talking about the 1990 season when they last won the Stanley cup. In the first round, his team was down 3-1 against Winnepeg. MacT said, "they just didn't realize how close they were to knocking us off". The Oilers recovered to win three games in row, and then they went on to win the cup, becoming stronger with every round.
About the same time I read a long article in the NYT (random values required) about how we are losing the war on spam.
They cited the example that as soon as a spam filter filters out "penis enlargement" the spam changes to "p.e.n.i.s e.n.l.a.r.g.e.m.e.n.t" that escapes the filter.
Talk about not recognizing that you are halfway there to winning the war.
Once the spammers start to pollute their own messages, the battle is over. The people dumb enough to pay money for what spam promises can only handle so much noise in the message before they become overwhelmed and find a different way to injure their pocketbooks.
The same rule applies with pop-up ads. Once the ads go over the top on the amount of annoyance they create, the war is over. At a certain point of annoyance, even the idiots whose misguided purchases drive this entire cycle are going to look for different opportunities to prove PT Barnham correct.
There's a fool born every minute, and there's a new way to fleece fools born every five years--because ultimately the fleecers shit their own bed.
Slashdot Mirror
This request is outrageous. There is any amount of material on the net already about security theory and practice. I've read most of it myself. How much of it am I practicing myself? Not very much. I'm not a full time sysadmin, I sysadmin during my recess breaks from my development activities. Why do I not bother to take security measures I hear preached on every street corner? Because the devil is in the details, and I can't afford to have my FreeBSD server go offline because ICMP was accomplishing something I didn't know about.
This guide is more useful to me than another dozen sermons. It gives me confidence that I can lock down aspects of the system I don't have time to understand in depth with a modicum of confidence that the essential functions of my box will continue to perform.
In my development life there are some aspects of security I work with daily: OpenSSH (tunnels, authpf), OpenSSL, IPsec. Despite my meager time budget to practice host-based security, I'm far from clueless about good security practices.
Do people forget what an incredible sinkhole of human productivity security has become? A simple overview of X.509 destroyed a week of my time. Yet another horror show more easily avoided in theory than practice.
One of the problems with Google is that you never see the thickness of the fully assembled tome. I recall an era where system documentation was measured in shelf-feet. Whenever I had the urge to make my life more complicated than necessary, I just had to look at that bookshelf and ask myself "do I really want to go there?"
I'm at the point in my life where I'm never again going to set aside whole days to master intricacies like all the special perm bits on the FreeBSD implementation of FFS.
I cherish the people out there who return from the trenches with a tattered cheat sheet with the barbed wire, machine gun nests, and landmine locations carefully documented. And then I read highly rated comments from the Rear Admiral types that "this is all well and good, but it isn't another volume of War and Peace". I would love to find to a complete set of VAX manuals on Ebay to donate to this idiot, but I don't think I could afford the shipping charge.
What this article needs is not more theory, but more warnings about "if you experience this kind of problem after making these changes, you took your security measures too far too fast". The art of security is not in knowing what you ought to be doing, it's knowing *what you get away with hardening* given other constraints, such as having any time left over to accomplish something productive.
I always remember the famous quote about building the Fermilab accelerator. When challenged about how Fermilab improved national security, someone shot back: Fermilab is the kind of project that makes America *worth* defending. People and nations who can't grasp that response end up eating their own tails.
I read an article on Science Daily, IIRC, about the concept of hormesis: that low level exposure to pathogenic forces improves the health of the organism.
A few years ago I read an article about the spread of bacteria when handling raw chicken. They asked a number of people to prepare a roast chicken starting with a sanitary kitchen, and then they went around afterwards looking for salmonella bacteria. The woman in the study who cleaned most compulsively proved best as smearing the bacteria onto every kitchen surface. Unless you clean with bleach, the average soapy rag is just an efficient distribution system.
Compared to kitchens and door handles, the average floor is a dose of penicillian. Hormensis from fallen gummy bears prepares my body for food that has contacted the kitchen counter for more than a few seconds.
Don't recall exactly where I read about the salmonella study, but it was around the time that The Sciences was still good, so it was a while ago.
I don't follow this argument. There is no onus on me to reveal anything about myself to a party that contacts me through their own error.
If there were such an onus, it's hard to imagine how many "errors" would be made by this kind of outfit.
The second error in this argument is confusing people with their phone numbers. I wonder how many "business relationships" exist between companies and unknown parties as a result of my habitual carelessness when filling out web forms.
No, the onus is on the blood suckers to reveal the person they are trying to reach, and until they do, they are practicing harrassment.
It works like this: pick up the phone, dial the number from your corporate database, wait for an answer and then ask "Can we please speak with Mr Bob Dog?" "One moment, I'll get him". "Hello, there, are you Mr. Bob Dog?" "OK, we have an issue to clear up."
There, was that so darn hard?
A single use of the apostrophe key would do wonders to his prose. Maybe he thumbed the entire article. That would explain a lot.
Less than ten minutes ago it was the red hat guy. Now it's some serious looking chick who might fall into a tar pit before the third episode.
I learned how to type on an Underwood manual typewriter in a grade 7 typing class. I was barely strong enough to lift the carriage with my pinky fingers to get capital letters. I used to do 30 wpm on a manual typewriter when I was still a puppy, now I type faster than most people think (not so hard really).
There's not much to it. Form the habit of using the right finger for the right key, and try not to look at the keyboard more often than necessary. Use the shift key opposite the hand typing the capital letter (added benefit: you'll never write in all caps ever again). Bonus points: put two spaces after every end of sentence punctuation mark (except in Evolution 1.2 which bites so bad it wraps the second space to the next text line--how can any editor in this age be *that* bad?).
Does typing fast help programming? Does being able to record your thoughts as fast as you can think help? I'll let you form your own opinions. BTW, you can tell a really fast typist, because most of the mistakes are whole missing. My biggest problem is that I can type slightly faster than I can spell unusual words. For some reason the word "bureau" always causes me a ten car pileup.
Worst name to type fast of all time: Krzysztof Czarnecki. He does cool research into generative programming. I have strong passwords barely that good.
One detail to bear in mind: sometimes you need to NAT within NAT. You can end up with nested NAT zones. 10.x.x.x does *NOT* NAT well within 10.x.x.x I've had to debug routing table illness for this situation several times.
My company makes a security product with its own Linux host, and the host operates cameras with a private NAT of its own. In one version, we had the Linux host and cameras behind an 802 network gateway, and the gateway performed NAT. We had the gateway configured to create a 10.x.x.x network address space within the private NAT zone. Then one day I brought the system home and plugged it into my own 10.x.x.x private network.
Do you think the Linux host inside the 10.x.x.x address space behind the 802 gateway NAT could access my local DNS server at 10.0.0.1 upstream from the 802 gateway? Not a chance.
For this reason, I tend to use all three zones for different purposes, depending on the size of the zone, and whether I think the zones might someday become nested.
I had to get back into microcontrollers, after a long absence (since the days when the 6809 was state of the art).
I decided to go with the Motorola HC12. Unlike the HC11, it runs compiled C code with reasonable efficiency (gcc supported), it's highly integrated, and you have a simple execution model (not very many registers, etc.) when debugging by hand. It's reasonably capable, and almost trivial to design your own project board (clock frequencies within reason, few external components required, every kind of I/O pin conceivable).
The more powerful versions have huge amounts of internal FLASH (256K), but not quite as much internal memory as I would like (8K is typical of recent versions).
There are cheap modules available from Technological Arts in Toronto. They don't seem to be very active this year with new designs, but they continue to supply their product line to local colleges last I checked.
Anything more complex than an HC12 I think I would want some kind of kernel OS. The next step up the food chain, in our evaluation, was an Atmel chip.
"The problem is that for the average AOL user, who to put it bluntly is probably both too stupid to figure this out on their own and too lazy ..."
I call this arguing from the idiot. It's an interesting stance, because it leads to actions and conclusions based on the behaviour of idiots. I don't know about anyone else, but I attempt to *suppress* this term in my own decision making processes. One of the first signs of age and wisdom is the realization that idiots are a fixed point in the analysis.
As a good case in point, there's nothing anyone can do to prevent "the average slashdotter" from making posts like this. The best you can do concerning idiots is lean back with your pipe and waggle your hairy knuckles. There is no such thing as an average tropical disease, there is no such thing as an average idiot.
There are two things I hate about this article. The first is that it is a straw man attack. The second is his premise that no one think too hard. The users won't think hard, he won't think hard, so why should anyone else? I can agree with the first two, but I don't think it follows for the third group, those of us who conduct the development process.
I've never had any patience for the "take over the desktop" mantra. Satisfying the general public is the most difficult task in programming. Where this does this notion come from that importance is measured in eyeballs? I thought we ditched that one after the dotcom implosion.
The general population is not a fixed target. What was "obvious" to a non technical person in 1985 is far different than what is "obvious" to such a person now. Even if we all agreed that "one size fits all" would improve the landscape (over my dead body) "one size" is a moving target.
Finally, uniformity is a marketing process, not a development process. Leave the developers alone. For once, Apple had the right idea when they packaged FreeBSD in a translucent gumdrop (the gumdrop stands for the amalgam of two incompatible user interfaces, one nested inside the other).
Let's get down to brass tackies: there is a large segment of the population which is relatively careless about where they double click (beer goggles, teenage pregnancy, reality TV). These people are well served by Outlook and Explorer. There is another group that is more fastidious about how they conduct themselves. These people are better served by any other mail client and Opera/Mozilla.
The choice is not about windows managers, it's about lifestyle, and that choice doesn't go away no matter how you package the underlying technology.
I was talking with a friend yesterday about why the "Linux on the desktop" debate always strikes me as entirely moronic. I finally found the right words to express the situation. Linux can't "win" the desktop until people respond "who cares?" Relevance of the desktop is a false value. The best technologies are the ones you rarely notice.
How is pushing a button on a keyboard *and* the mouse at the same time "easier" than having a mouse with two buttons in the first place?
Apple aggressively marketed the one button mouse concept for years to promote their own unique slant on "easy to use" and then when world+dog discovers that the human hand has more than one finger, no one stops to ask what they were smoking.
What boils my cheese is how Apple gets away with a vacuous redefinition of the word easy.
Easy is one of the most complicated human criteria in human language. For a two year old, it is easy to go down stairs on your bum. That is how I always felt using a Mac.
When a teenager I discovered that stairs (on the way down) were mostly optional. I discovered that I could make it all the way to the bottom in a single bound, two steps from the top. Then one day my forehead sailed into the overhang, dropped me on my ass halfway down, with a concussion and a damaged tailbone. That's how I feel using older versions of Windows.
One Christmas morning I spent at my girlfriend's, she had an older house where the carpet was not glued onto the steps, but pinched down with metal rods at the nook of each step. The steps underneath were the old wooden style with the rounded projection. There were shiny patches from long years of use worn into the stiff carpet bubbles folded around the stair edges. I put my bare foot onto a shiny patch as slippery as a skating rink, then smashed my leading heal on every step all the way to the bottom. That's how I feel using Unix. Ten years later, that same heal still hurts in the shower.
One time I worked in an office building with highly depressurized stairwells. Because I still had my keys in my right hand, my pinky was folded outside the handle. I pulled hard to crack the airlock, the door swung open ballisticly (which I was prepared for), I was just to pull my hand free when hard steel door handle crushed the small knuckle of my pinky finger against a decorative rockface. What I didn't realized is that the decorative rockface stuck out six inches from the plane of the door hinges so it crushed my finger well before it finished swinging to 90 degrees. This left me with a mild, permanent disfiguration of that knuckle. I'm not sure what OS that represents, but both Windows NT and VMS spring to mind.
So here Apple comes along and proclaims that their stairwell is easier to use because there design has only one handrail, so you don't get confused about which handrail to grab, nothing can go wrong, and I'm supposed to feel impressed.
I think I could fill a 500 page book on stairwell design factors: step dimensions, surface materials, footwear, footsize, materials carried, overhead clearance, emergency lighting, evacuation, firefighting, bannisters and handrails.
At the end of the day the answer would be that different designs are better for different people, different tasks, different situations.
Not even a common stairwell has a one-size fits all solution.
One decision has made my life easier: never underestimate the complexity of the task you are facing. After beating myself senseless on dozens of different stairwell designs, that's the only kind of easy that still interests me.
If you really want to counter the SCO FUD machine, widely publishing the notion that this is a stock pump for the benefit of insiders, who might already expect the gavel to fall heavily against them (if proovable by the SCO shareholders the SCO executive could be facing a class action *after* SCO goes bankrupt), would hit them where it hurts.
Yet this weasel guest columnist would appears far too concerned about his own liability to float such a claim in a self-styled national newspaper, even though it would put a much sharper point on his broad interpretation of the situation.
Yet somehow his peronsal forebearance vanishes entirely when he finds time to suggest that major Linux vendors indemnify their own customers, knowing full well that the wrath and considerable litigious muscle of SCO will be violently focussed on the first company with the temerity to do so.
As every career activist knows, the success of this kind of agitation depends on finding someone sufficiently wet-behind-the-ears who does not yet comprehend that a carefully staged, photogenic arrest nevertheless leads to a permanent criminal record and a lifetime of legal discrimination.
Hey Wynn, we'd be more than happy to indemnify our Linux customers. Small obstacle: you first.
Fact was a nice word, I'll miss it. But no matter, we still have the teeshirt:
Front side
picture: Iraqi minister of communications
caption: "there are no Americans in Iraq"
Back side
picture: his Billness
caption: "there are no bugs in Microsoft software"
At one point in time Einstein was an unqualified patent clerk. Many years later, he is finally awarded a Nobel prize, because one of his three main discoveries was finally within the certain appraisal of his peers.
Interestingly, at no point in time were Einstein's qualifications equal to his peers'. He managed to pass the Achilles' Academy at a non-instant of time.
I don't understand this concept of indeterminate relationship. It strikes me that his claim boils down to saying that time and motion are not possible unless you regard the set of physical relationships as constituting an uncountable infinity.
But what is the big deal with that? R is uncountable on an open interval, but it still retains a fully ordered relationship.
Zeno's paradox functions because it forces you to analyze time as if it could be mapped onto a countable set (halving interval N).
That said, I don't regard time as a well defined physical quantity. Einstein proved long ago that time does not function as a simple ordering relationship. Yet the only reason I can see that we use the abstraction of time is to suggest that physical ordering relationships exist.
I tend to view physics as having a trinary logic: true, false, and ungrantable. A foundation for physics which was formally non-predictive (lacking a human interpretation of time) would certainly belong to the last bucket, for as long as time remains a proxy of human purpose.
I take a hard view on issues like this. If the standard body can't get its act together to deprecate a function this misbegotten, I have a hard time listening to anyone argue that compliance with POSIX for the sake of compliance is a good thing.
A standard codifies practice, and that is the primary work output of a standards body. But the moral authority of the standard does not rest on the fact that it has been endorsed as a standard: the practice it codifies must ultimately provide the moral foundation for its acceptance.
We all know that gets() should be taken out back by the toolshed and summarily executed. We all know we can't do this, because gets() retains a purely historical legitimacy.
This is why we invent fancy terms such as 'deprecated', where we admit that we've learned from our mistakes. Back in 1950, the use of CFCs didn't seem like suck a bad idea.
Once we learned the true effects of CFC on the ozone layer, refusing to deprecate CFC would have called into question the moral authority of the entire chemicals industry.
gets() pollutes the programming environment every bit as much as CFC destroys the ozone layer. I feel it sabotages the moral authority of the entire programming profession.
Someone commented that POSIX is in fact a living standard. That would seem to imply that the most recent POSIX standard has failed, once again, to deprecate gets(). To my eye, this is far more damning than if POSIX had remained unchanged for the last twenty years.
If the people involved in the POSIX standard care about standards and standards compliance, they should care enough to take the minimum necessary measures to sustain their moral authority, or they should be prepared to sit back as the world rallies around alternative codifications of standard practice that does live up to its moral obligations.
Ultimately, standards have to be earned.
The analysis of Risk is a trivial problem. I once wrote a small program to do exactly the same analysis for Axis und Alies, a vastly superior game IMHO. Sometimes I played A&A for 24 hours straight and then couldn't sleep because of a pivotal scenario developing, usually a land grab in Indonesia by one side or another before a fateful invasion of Tokyo by the Americans.
Then I would get up and it would take another 24 hour day, several pots of coffee, and two trips to the beer store to play it out.
Axis and Alies has more degrees of freedom than Risk. The person losing units has the choice about which units to sacrifice. Not all units can attack other units. Submarines can't attack airplanes. (They laughed at me the first time I played for thinking I could do this, no one told me I couldn't, they let me buy four subs to defend against a fighter plane outpost. Later I was reading about submarine technology in WWII and I discovered that submarines often carried surface to air mortar shells--not terribly effective though).
Because of the problem of the exact order in which each player chooses to remove their own casualties, the complete tree explodes exponentially. However, in practice, the order of removal is automatic 90% of the time, and the cases where the removal order is debated tends to come at the end of a close battle where you are more concerned about what is left behind when the roles reverse than who actually wins.
In my program, the attack and the defense both submit their roster in a predetermined removal order. You could try different removal orders, but you couldn't make the removal contingent on battle outcomes.
My program calculated the exact probability of every terminal outcome. You don't even need Markov models, that's just a view of what the final math represents. The actual algorithm is like a fertilizer spreader that tosses little chunks of probability from one bucket to another until all the probability is sorted into buckets representating terminal outcomes.
It worked out to perhaps three pages of code. Memory requirements go up roughly on the cube of the number of armies involved IIRC.
I learned an incredible amount about the strategy of A&A from this program. Moral of the story: you can never have too many grunts. The strategic problem with grunts is they move so slowly. I learned to invest in waves of grunts (esp. for Germany) at the beginning of the game, get the waves moving outward, and once the fronts were established, replenish a fixed supply of tanks as these were consumed in battle, and grunts grunts grunts with the leftovers.
For my money, A&A is the best game I've ever played at pressuring the strategists to set up confrontations with the potential to break symmetry and channeling the game down unpredictable paths, forcing everyone to adapt their goals. Except for the Eastern front, where the game was a little too close to being historically accurate. For a five person game, being stuck with Russia was a chore in the early going.
No one has calculated Risk in 50 years? Phffff.
More likely, no one interested in that kind of analysis considers Risk much worth the bother.
The Markov analysis of Monopoly I saw a few years ago in SciAm was far more interesting to me. Verdict: Never underestimate "go directly to jail" as a form of rent control.
I had to laugh when I saw the comment that "go directly to Australia" was a fundamental Risk strategy.
When you roll over the level counter on Space Dungeon, it prints out the rhyme "you're the hero on level zero". I should know. That's where my undergraduate career ended. Level zero, 6,999,995 points.
With a little help from my friends while I guzzled an omelette.
My file server in my basement has three of those 4G Fujitsu SCSI drives, bought them on auction as discontinued Unisys models. They do resemble boat anchors, but I've never lost a byte. And for my most important files, I've learned that 8G of reliable SCSI RAID is more than enough.
The problem with those darn reliable drives is they caused me to go out and buy a bunch of 40G Fujitsu MPG drives (which also had the virtue of being extremely quiet).
Well, that second batch of Fujitsu drives are sooo quiet now, not even the worms can hear them.
I really should have put the center of those 4G drives in upside down. The case would be more stable when the drives spin up.
I've been with pair.com for four years, and my experience has been great. They do use regular IDE disk drives (last I checked), but uptimes are great nevertheless (ten minutes a year downtime as a reasult of hardware issues on my own hosts, plus one or two scheduled facility moves and major OS upgrades).
I also agree that pair.com has been good about increasing quotas to reflect realistic costs. I've never felt like I was being hosed just because they could get away with it.
However, I still agree with the original post. Average cost per MB/month has not tracked Moore's law in the hosting industry. Furthermore, the hosting centers could make mass storage available without the extreme uptime guarantees. A pair of hotswap 120GB IDE drives plus enclosure (we use ARAID in some of our cheap servers at work) costs about U$800. $5/GB/month would generate $600 per MONTH.
Obviously it's not the cost of the hardware, or the hosting overheads that create this cost model.
I've had applications where I didn't need host site backups at all. The documents generated were intended to be permanently archived, many documents were searched, few retrieved, we pulled down our own backups over the network as new documents were created. There was *no need* to have a document that sits on the server unchanged for years at a time backed up on the hideously expensive datacenter backup fabric, daily, weekly, monthly, or even yearly.
What creates this cost model is that people with large amounts of this kind of data are already well served by the colo model, so the hosted sites have a cost model to cover the datacenter storage they have *already decided* to build.
If you really want to understand this, read "Who Does What and Why in Book Publishing". The author explains that the internal cost models created by a publishing company can make it impossible to print a book that would make a profit (as viewed from an external perspective). Some publishing houses had internal formulas which allowed them to justify coffee table books with huge volumes of colour plates. Other houses didn't.
That's half the reason why hosted storage costs so much. The other half of the reason is that bandwidth is a commodity, so storage is the only degree of freedom hosting companies have in their pricing structure to ensure that revenues exceed overheads.
Absolutely there is a price distortion involved. It's not as bad as when DRAM cost $30/MB, but I still have that same sense of end prices frozen in time while the underlying technology is improving by leaps and bounds.
The best example ever: my local phone company wants another $5/month so that my voice mailbox can hold more than 20 voice messages. And this hasn't really changed since I first had a telco voice mailbox in the late 1980s.
parvus makes a five port 10/100 ethernet switch with extrended temp ratings in a PC/104 form factor (but you can use it for anything). It consumes just 1.25 watts. We had to hunt high and low to find a COTS switch for our own battery powered datalogger within this power budget. Most ethernet hubs/switches consume 3 to 5 watts.
After throwing around that piece of shit sound bite about "hiring known criminals" the same customer goes out into the parking lot and smokes a joint. Good thing he hasn't been caught yet, must be the universal instinct (aka moral fortitude) to keep a low profile at work here.
Haven't we learned anything at all from the Catholic Church and the Moral Majority? It seems to me that the people who most love to push these disgusting buttons of knee-jerk public opinion ride a very interesting elevator in their own private lives.
"It is unwise to be too sure of one's own wisdom. It is healthy to be reminded that the strongest might weaken and the wisest might err."
-Mahatma Gandhi
Posts like this one make me wish we'd criminalize adultery. If criminalizing pot isn't enough to make people think twice, that's about the only thing I can think that would cast a wide enough net to shut the idiots up.
Nothing pisses me off like the virtuous who haven't been caught yet.
Now we understand why Microsoft has created some narrow "open source" situations: once they contrive to leak some of their own code into the Linux kernel as a plausible consequence of exposing some code to third parties, they'll finally have their way to crush the Linux windpipe, er, shut down the air supply.
Once you get used to it OpenBSD is not at all difficult to install. I use it entirely for network security (five machines) so I've never bothered to install X.
/sbin/dhclient (which is not an obvious place to look) and that this script clobbers resolv.conf That was a bugger to sort out back in the 2.6 days when I didn't what I know now about DNS and resolvers.
The man pages are excellent. The only place I've been bit is that the dclient man page doesn't mention that it runs a script in
Since the 3.2 release of OpenBSD we have been making heavy use of chroot Apache as a forwarding web proxy to hide the real server machines from the public internet. This way all of our SSL connections terminate at an OpenBSD box. If OpenSSL requires a security patch, we only have one OS to update. And the security is great even if we don't patch, because only the chroot Apache on OpenBSD is exposed.
It seems like very version adds another great feature. In this release we are anxious to experiment with the failover NAT in PF.
I generally don't praise OpenBSD in public. I figure if you need it, you know it already.
I was reading a comment by the coach of the Edm Oilers the other day. He was talking about the 1990 season when they last won the Stanley cup. In the first round, his team was down 3-1 against Winnepeg. MacT said, "they just didn't realize how close they were to knocking us off". The Oilers recovered to win three games in row, and then they went on to win the cup, becoming stronger with every round.
About the same time I read a long article in the NYT (random values required) about how we are losing the war on spam.
They cited the example that as soon as a spam filter filters out "penis enlargement" the spam changes to "p.e.n.i.s e.n.l.a.r.g.e.m.e.n.t" that escapes the filter.
Talk about not recognizing that you are halfway there to winning the war.
Once the spammers start to pollute their own messages, the battle is over. The people dumb enough to pay money for what spam promises can only handle so much noise in the message before they become overwhelmed and find a different way to injure their pocketbooks.
The same rule applies with pop-up ads. Once the ads go over the top on the amount of annoyance they create, the war is over. At a certain point of annoyance, even the idiots whose misguided purchases drive this entire cycle are going to look for different opportunities to prove PT Barnham correct.
There's a fool born every minute, and there's a new way to fleece fools born every five years--because ultimately the fleecers shit their own bed.