I think my issue here is with one of your starting assumptions.
You seem to think that most people will (or at least should) realize that a non-WEP'd wireless access point is the same as saying "I'm willing to share" for a random home user. Or a random small business user, for that matter.
I agree that WEP is inherently insecure, and not much better than politely asking someone "please go elsewhere." MAC filtering is the same, given cards that can clone MACs.
Our basic disagreement comes from the fact that I expect a "random home user" to be someone who believes (falsely) that a purchased WAP is secure and will only work with his own stuff, just like a wired switch, and requires no additional configuration out of the box, just like a wired switch. And therefore, the "polite" action is to look for a feature of a WAP that explicitly states sharing is allowed/accepted. The default should be "please go away" instead of "feel free to use this."
You almost seem to agree with this, in your analogy to your wired switch on your desk. You expect people to ask first. You don't say what a "no response" means in that case. If someone walks by and sees a switch on your desk and you aren't there to ask, are they right to plug in without asking? Or is the default "polite" response there to assume a lack of permission unless explicitly given? You don't cover this in your "and then being told yes or no."
A wireless access point without WEP, I argue, is like your switch sitting on your desk without you there to ask. What is your assumption for the meaning of "no response" to your question of "can I use this resource?"
And, from curiosity, does your assumption of the meaning of "no response" change for wired versus wireless access? If so, why does your assumption change?
Hell, it doesnt even take more than common sense to realize "Wow i connected all my neet new magical toys and i can get on my internet connection from my living room with no cables!!! Wait, if i can, cant everyone else?"
For most people, wireless access points are sold just like a cordless phone. And most people consider a cordless phone to only work with the handset that comes with it. Except they don't really think of it that way, they think of it as "It works with my stuff" as is, frankly, the reasonable way to consider things.
The problem here is that most people's life experience is dealing with things that people control. Not things that computers control. You put computers in control of things, and you lose a lot of contextual information that people use to make decisions. Because, frankly, much as we like them, computers are incredibly stupid.
People want to buy things that will work in their house with their stuff. And when they plug something into a wall, it works with their stuff that they plug in. And when they buy something that is "just like wired, only the convenience of wireless" which is how most of these things are sold, they expect it to work the same way.
And then people like you come along and say that it's right to take advantage of this. I'll bet you liked driving around neighborhoods 10 years ago with cordless phones and making long-distance calls on other people's lines, because, hey, if they didn't want you doing that, they wouldn't use something that allowed it. Right?
Congratulations, you are a parasite on society.
Reading furthur, you say:
If a wireless network has WEP enabled, you are clearly not welcome.
and immediately follow it with
The very smart of us know WEP is not a good replacement for real security, and one should not do secure things with WEP as your only form of protection.
... The other way is to not use WEP but make your SSID read "keep_out" or something similar.
Hmm. In one place you say "take advantage of the morons" and in another you say "be polite and don't use a resource that someone asks nicely that you not use."
Umm... you don't really have a fully-developed moral and ethical code, do you?
Decompression stops? Hey, I don't do deco diving on purpose. Hmm, that didn't come out quite the way I meant for it to...
I've done borderline deco before, computer says I need a 1minute deco stop at 10ft, while I'm finishing a dive at 90ft and getting ready to ascend. By the time I do a slow ascent up to 40ft, the 1min/10ft deco stop has cleared and the computer is happy again.
Conservative computer algorithms, gotta love em.
But I still want the gameboy, for the safety stop. (Probably) wouldn't use it for deco stops, just because the computer can get upset with you if you don't follow it's exact deco profile.
And... really, and extra air tank? Yuck. I dive nitrox, unless I have a reason not to. Don't you like happy gas? I just feel less tired after 4 nitrox dives than I do after 4 air dives. I don't care if it is purely in my head, I live in my head, so I'll be happy there.:)
And I'm still rather struck by the thought of learning sign language.
With an underwater housing that I can take 100ft deep while scuba diving. And play in the housing.
I love scuba diving, but sitting in the water 15ft down for 3-5 minutes for a safety stop is one of the most boring things I've ever found to do. All you can do is float there listening to yourself breathe.
I'd love to get a Gameboy in an underwater housing, so I can take it diving with me and amuse myself while watching 3 minutes go by.
That or I need to learn sign language so I can chat with my dive buddy... (And make him/them learn sign language too.)
But the gameboy in the underwater housing would be cooler.
And yes, I do dive with a digital camera in an underwater housing. Canon Powershot S40. I want the Gameboy *too*.
The only thing to be careful with if you go for diving lights is some of them don't like being used in air; not enough cooling.
Yes, that's one reason I like the HID bulbs instead of the "standard" cave-diver 50W halogen bulbs. The HID bulbs dissipate a lot less heat, and, from a heat perspective, have no problem being used out of the water.
That said, the HIDs do put out a lot of UV light, and it is recommended that you not look directly at the bulb for long periods of time when it is out of the water. Underwater, it isn't an issue, as water absorbs the UV over a very short distance.
Don't really disagree with your comment of multiple lights, though. But he's already said he doesn't want head-mounted, and he probably wants one hand free for other things, so he's limited himself to only 1 (active) light at a time. Which is another reason I like the hand mount for the DiveRite, it puts the light on the *back* of your hand, with a strap going around your hand to hold it in place. So you can still use your fingers and palm for gripping and holding things.
How about some scuba diving lights? How much weight are you willing to deal with for this? And how much money are you willing to spend? And how long do you need it to last?
Underwater Kinetics (UK) makes a Light Cannon that uses 8 C batteries, lasts about 3-4 hours burn time, and puts out 450 lumens. (Did I mention it's bright?) Uses a HID (high intensity discharge, basically a 15,000V voltage arc) bulb that lasts about 1000 hours. Fixed-focus reflector, but it comes with a wide-angle lens filter to spread the beam. This will set you back about $175.
You can get the same thing, slightly brighter with a separate battery and light head from Dive Rite with a selection of battery choices. A HID light head (equivalent light output to a 50W halogen bulb) with a coupledifferent battery options. These mostly use rechargable batteries (lead-acid, NiCD, or NiMH) and make a really nice light. Nice thing with these is that the light head has a simple hand mount with a power cord going back to the battery case, you point your hand where you want to see and stick the battery in your backpack. Can move the bulb in the reflector, to give a choice of spot or wide angle. Depending on the battery you select, you get from 2-6 hours burn time on a charge. Major down side is that these are kinda heavy. Oh, and kinda pricey, expect this to set you back about $600.
But it's a beautiful light.:)
And you already learned the benefits of rechargable batteries.
Other downside with the HID bulbs is that they are, I'm told, fragile. I have one, and have not had any problems with it, but I also haven't dropped it off a table yet. And the replacement bulbs are pricey too.
I dive with a Dive Rite MLS-1 with the H1 head. My last night dive, I complained I couldn't find my buddies because they all had these tiny little lights that disappeared in the beam from mine. They were all diving with standard xenon-bulb(?) 8 C Cell dive lights, which are generally considered bright primary lights. Okay, I was kidding, but the difference in light output was extremely noticable.
Don't know how this compares to your current lights, but it might be something worth looking into.
And don't forget the most important requirement for this little toy...
Must continue to work for as long as you want the marriage to last.
This argues strongly for something where the utility is what it is, rather than what it does.
A "does" will wear out, mechanical failure, chemical breakdown, too many cosmic ray strikes, whatever. A "is" will last as long as the ring is in one piece.
The DoD is very interested in having easy identification for the 1.3 million military personnel in the United States. This means pay information, service records, ratings, training, specializations. Medical records. Retirement information.If it's tracked, they want to have it all referenced to a single identity, cross-referenced on different systems.
They were working for a while on smartcards for all military personnel, and that's actually gone pretty far along.
But they've probably learned that there's too much to stick on a smartcard, and you can't get good enough security to put confidential information on the smartcard that you give to 1.3 million people. Too many will lose them, and then you have problems.
So they want to have the records, and have them easily tied to individuals. And have them available in the different commands, on different servers scattered thoroughout the DoD command structure.
They are very interested in something like the Liberty Alliance, and making sure that they can use it for their purposes. Keeping this diverse array of information for 1.3 million people is just what this project is made for.
Seems good that the DoD became aware of it, and decided to participate. And I'm reassured that they didn't decide to just go with the Microsoft solution without considering the options. (Maybe they learned from the problems the Navy has been having with NMCI.)
The "bacteria cause stomach ulcers" is a good example of this. Established scientific/medical community says "that's ridiculous" to a new claim. So the claimant tries to get it accepted by other means.
However, if you notice, these rules do cover that situation also. 1) The announced discovery was not *direct* to the media, but tried to go through the scientific review process first. Exact methods were released so other scientists could study and duplicate the results. 3) Effect was easily measured.
As stated in the article, these are warning signs, not guarantees. It's "be more careful examining these claims" instead of "dismiss them out of hand."
I came across it in a summary of a study. Couldn't remember a source off the top of my head, so I did a quick google search for "pay disparity 98% men women". (Yes, I decided to foolishly believe I remembered the percentage correctly.)
One thing that has changed is that the national debate now profits from the contributions of non-feminist but scholarly women who know how to evaluate data.
A pair of them, Diana Furchtgott-Roth, an economist with the American Enterprise Institute, and Christine Stolba, a doctoral candidate at Emory University, have published (with the help of the Independent Women's Forum) a new edition of their book "Women's Figures: An Illustrated Guide to the Economic Progress of Women in America."
As everyday experience suggests, women have made dramatic economic progress in the past 40 years. In nearly every field of endeavor, from advanced degrees to business ownership, women have made great strides. Women comprised only 12 percent of pharmacists in 1970, compared with 44 percent today. They were only 27 percent of public relations specialists, whereas they now dominate the field with 66 percent. There are five times as many female lawyers today as there were 30 years ago and nearly three times as many doctors.
The wage gap, Furchtgott-Roth and Stolba explain, is a crude comparison of the wages of all men compared with the wages of all women. It does not take into account education, training, time on the job, or full or part-time work. In reality, the most important factor in the wage gap between men and women is probably summed up in one word: children. Women with children tend to take more time off from work, accumulate less seniority and accordingly earn less than men. And the more children a woman has, the more her income is likely to suffer. The National Longitudinal Survey of Youth finds that among workers ages 27 to 33 who have no children, women's earnings are 98 percent of men's.
Hmm. I admit, that's a narrower category than I remembered. "Workers age 27 to 33 with no children" jsut isn't terribly representative of the entire job market.
But a summary/review of that book is probably where I got that statistic from.
No one wants to carry their music seperate from their players anymore anyway. It's cheaper to have them seperate now, and the user interface is a little easier since you don't have to spend so much time catagorizing your music and playlists, but this isn't the case for the IPOD, and future devices aren't likely to continue to do it this way.
There are two good reasons to have music separate from the player.
First, you can conveniently trade music away from your computer. I have an iPod. (I love it.) I can't trade music from my iPod to a friend's iPod without going through a laptop or desktop computer. You can argue this is a software issue Apple could fix with a firmware change, but the little lcd screen really isn't a good way to do selection for "send this but not this". That's probably part of why you can't delete songs on the iPod unless you hook it up to a computer. (Though I'd really like to be able to do that too.)
Second, you don't use any battery power by handing your friend a cd or mini-cd. This is a wonderful thing for a device with no swappable battery. These things live and die by battery usage.
It's interesting that you should bring this up. I have slightly different, but supporting, perspective on this.
Military safety training...
Every 3-7 years, you get a change in pretty much all training guides for all safety-related procedures in the military.
The military doesn't do this because the safety procedures actually get better. They do it because, if they change the training guides and safety procedures, people stop being bored with the "old" way of doing things, and pay more attention. And simply because they are paying more attention, the accident rates go down. (Or stay stable instead of going up.)
So the effort of changing safety guidelines and procedures (which costs a noticable amount of money, and tends to look silly to outsiders who say "this is effectively what you had before!") actually has a benefit in fewer hurt soldiers.
Yes, they did studies on this, sorry for not providing a link. A lot of the silly things the military does actually have good reasons, if you dig enough.
This reminds of the myth about women being paid around 70% of what men are. If true, there must be someone out there hiring only women and killing their competitors with wildly lower labor costs. Ought to be easy, women are around 40% of the labor pool.
First, as was mentioned in another post, you'd have EEO problems if you tried to do that.
But second, this is one of those wonderful "lying with statistics" examples.
There are a couple of issues with this, mostly in assumptions, and partly in attitudes and priorities. Partly just societal realities.
First, some of these studies look at "average pay for all women in workplace" vs "average pay for all men in the workplace". This ignores pay differences in types of work, and gender majorities in job types. Most administrative/clerical/secretarial jobs are primarily female, and these jobs tend to be lower paying, dragging the average down. Most managerial and technical jobs are primarily male (though this is changing) and these are higher paying jobs, dragging that average up.
Second, it ignores time-in-grade issues. Women started entering the workforce in the 40s with WWII, but lost a lot of ground at the end of WWII, and in the 50s just started with (as I already said) secretarial and that type of work. Typically lower paying. Women didn't start becoming common in managerial and technical jobs until the mid-to-late 80s. Therefore the "typical" woman in these fields has less time-in-grade, and less experience, than the typical male. That makes a differences in pay rates.
Third, and this is the societal, women are (generally) encouraged to be the caregiver of a family, for a 2-income family. This means they'll be more likely to take time off work to take kids to see the doctor and similar things. Also, they'll probably take off significant amounts of time for pregnancy/childbirth, and possibly a couple of years after that too. (My mom married and worked until she got pregnant, then stayed at home until I started going to school, and then she went back to work... that's 5 years out of the job market, and she has a technical degree.) This is a matter of your priorities. What is important to you?
Fourth, and this one isn't fair, is that men are perceived to be more willing to put in extra time at work, because the wife is at home taking care of the kids. Therefore, it is more worthwhile for a business to promote a man, because he'll spend more time working for the business.
When you take out these non-equivalent pieces, and actually compare apples to apples, you find much more equal pay rates. For a man and a woman in a technical field, with the same time in the job market, with similar time-taken-off rates, the woman will be paid about 98% of what the man is paid.
However, this usually means you are comparing single women (or childless married women) to single *and* married w/children men.
Which means that, if you pay attention to the statistics, you learn that the way for a woman to get near-equivalent pay is to sacrifice a family life.
Though you might see more effects of this on a low bandwidth link, it is not just for low bandwidth.
A fair number of protocols do transmit windows of a certain size. They'll send a certain amount of data, and not send more data until the oldest packest in the window gets an ACK back. You therefore only have so much data "in-flight" at any one time. Strongly asynchronous link (like aDSL and cablemodems) can require strikingly different window sizes than synchronous links.
The right amount of in-flight data is dependent on the speed of your pipe, obviously, but a lot of applications still use defaults set for low-bandwidth pipes. You can argue that the proper solution for this is to change the defaults, but if you just give ACKs priority, you don't need to worry about it, and the less you force users to change, the better. (The transmit window size has to be a user setting, directly or indirectly, either by asking a window size, or by asking "what kind of pipe do you have?" and guessing a window size from that.)
This is dependent on the protocol, true, but giving ACKs priority is actually a decent generic solution to what many consider an application-specific problem.
QOS is also often about bandwidth guarantees, not necessarily throughput. You have a 155mbit link shared among several applications, and an application that *requires* 45mbit. So you use QOS to guarantee that application gets 45mbit if it wants it, and everything else shares the remainder. If the app isn't going, then that 45mbit it requires can be made available to other apps until it is required.
I have the same objection to Mozilla's memory footprint and load time. My solution was a little different than yours.
Instead of dealing with IE, I switched to Phoenix. The version 0.5 is kinda worrisome, but it is basically Mozilla 1.2 with a bunch of the excess junk stripped out. All the functionality for the browser, strips out the news and mail clients, and simplifies the user interface some. (Still supports all the configuration options through the CSS and js files.)
You don't really know how much it costs to employ a person, do you?
Did you notice the text in there about "plus overhead costs"? That means little things like Employer Taxes (SocSec, Medicaid, etc), retirement contributions, health insurance, and other related.
The actual cost to employ someone is generally 50-70% more than their salary. A "cost" of $75k means the person is probably paid about $45-50k salary.
And this ignores the cost to actually hire anyone. For any large corporation with a serious HR department, it probably costs the company about $30k to go through the process of hiring someone. That's why large companies hate high turnover, the HR costs become unbearable.
While it is technically possible for a compiler and runtime environment to use a 64-bit int size, I am not aware of any that actually do.
Hmm. Okay, thanks.
I couldn't remember if I had issues with "int" on a 64-bit platform because it wasn't the "natural word size" of the platform (and therefore wasn't the same size as a pointer there) or because it changed the data type size and screwed up my reads. Thanks for correcting my crappy memory. (I had issues with data type size with logicals in fortran, but I tend to think that was a compiler error because it changed between compiler versions on the same architecture as well as between architectures. Guess I was thinking of that.)
Incidentally, I have issues with a 32-bit "int" on a 64-bit platform. An "int" should be the natural word size of the architecture you are running on. If you want a 32-bit int explicitly, use a specific variable declaration for that size. If you want a 64-bit int, use a specific declaration for that size. If you want natural word size of the architecture, "int" should give it to you. Yes, this can make porting more difficult... so learn to use "short int" when you want 16-bits, and other variable declarations to explicitly note required data types.
Hmm... http://www.opengroup.org/public/tech/aspen/lp64_wp.htm gives a nice description of LP64 and other 32/64-bit programming models. Thanks for making me go look at it again. (Can you tell from the above paragraph that I'm really used to ILP32?)
And while you're correcting my mistakes... Is __int32 and __int64 portable across platforms/compilers? I never can remember.
Benefit? That's easy... anyone that owns a digital camera.
Because you'll be buying a new one eventually... and in a couple years, you'll be buying 20megapixel digital cameras for $400. In other words, all your favorite geeks will have one.
And they'll want to edit these pictures on their computers. You wouldn't think that would need so much memory...
But.
Try it with 10 pictures at once, cause you want to see which has the best overall shot of everyone in your group standing in front of your friend that had a cool wipeout skiing.
You make a couple minor changes in 7 of the pictures, adjust color balance, change brightness, red-eye reduction, stuff like that. Your image editing app of course has multiple undo. (Don't they all?)
You copy a few of the images around, shoving them through the clipboard.
4 copies each (multiple undo, remember) of 10 images each at 80MB per image (32-bit color on 20megapixels...) that's... 4x10x80MB = 3.2gig of ram you just used.
Just for editing 10 pictures from your $400 consumer digital camera.
Now do you see why you want a 64-bit cpu that handles more than 3gig of ram for a single process?
(Yes, I purposely assumed that a simple "adjust color balance" requires a complete seperate copy of the image for undo, and it probably doesn't... but you get the point now, don't you?)
Intel and AMD have worked miracles with x86 to get it to run fast, but at a staggering engineering cost. The teams working on RISC chips tend to be a fraction of the size to come out with a high-performance chip. If the RISC houses had an engineering team of comperable size (and access to the same bleeding edge lithography processes) it would easily be worth an extra 25% in performance, minimum.
I don't think you read the same thing I did.
Linus doesn't seem to be saying "if the teams were on equivalent footing, x86 would still win."
Instead, he's saying (in part, among other comments) "because x86 has such huge volumes, Intel/AMD can afford to optimize it to a point that it beats all the 'better' low-volume games in town. And that will never change as long as x86 maintains high volumes."
Of course, he's also saying that those 'better' architectures aren't really all that much better. And in some cases he thinks they are worse.
But he is not making statements of "in a fairy world where they are on equal footing" because Linus lives in the real world, and cares about how things work in the real world.
It is still a full port, if you want to get the benefits of the 64-bit architecture. If you want to keep running 32-bit x86 code, don't even bother recompiling. But don't make the mistake of thinking that switching 32-bit x86 code over to x86-64 is a simple re-compile.
It is still a port, with all that is included in that awful word.
Do you understand how little 64-bit safe code there is that runs on 32-bit x86 systems? Most of the linux kernal is already 64-bit safe, because it has been ported to so many other 64-bit architectures already. And it still wasn't a simple "just recompile it".
Speaking specifically to C programs here, porting from 32-bit to 64-bit is not a fun process. A variable declared as "int" switches in allocation size. This is good and bad.
fread (fp, sizeof(int), &var);//(forgive me if I have the parameters backwards, I'm doing this from memory. And notice that I'm a bad programmer, I didn't check the return value.) Congratulations, you just killed all your existing data files. And if you happened to read a 32-bit pointer from that data file (any structures that you write directly that contain a pointer write a pointer... you'll throw the pointer value away when you read the structure back in, but you still have to read the proper data size), and then assign a pointer to it... Oh, you're going to have all sorts of fun playing with that.
Yes, this may only be an issue with "bad" C code that assumes it will ever only run on a 32-bit platform... That probably covers 99% of all x86 C code out there, for any OS you care to name.
Don't pretend it will be easy moving from 32-bit x86 to x86-64. For most programs, I assure you, it will be non-trivial. Anything that does direct memory allocation will have to be checked very carefully. Anything that does binary file i/o will have to be checked very carefully. Oh, and anything that uses "magic" numbers will have to be checked... Have you ever used an if conditional for an int of the form
if (i == 0xFFFFFFFF) congrats, you just assumed 32-bit for your architecture.
Supercomputers are almost purely cpu number-crunching beasts. This is what you seem to think of as mainframes with "over a thousand... processors". This is not a mainframe, this is a different category. They also generally have very high inter-cpu memory transfer rates, for handling dependent parallel computations.
Most mainframes, like IBM's Z Series, have 24 to 36 CPUS. A mainframe is not about cpu performance, a mainframe is about data. A mainframe has system data throughput that puts almost any other system to shame. Historically, mainframes are good at supporting many simultaneously-connected users doing data queries and updates. (Yes, they run huge databases very well.)
And then you get Beowulf clusters (your Google remark, effectively), which are really chasing the supercomputer market, and not the mainframe market. Beowulf clusters care about a limited class of supercomputer applications, they are good where you need a lot of parallel number crunching, and have very little data dependency between parallel calculations, so you don't need a lot of inter-cpu communications.
Pick the type that's right for your job, and you'll be happy. Pick the wrong one, and you'll have nothing but problems.
And it helps if you're stuck-up intelligently, that way people will still hate you, but won't think you're stupid any more.:)
You may want to see the memo that says that 3M knows they are causing giant, man eating three eyed frogs because of the waste they are dumping, but it isn't you right to see it.
If they are dumping their waste in the stream that flows through my back yard, it's my right to see it.
On the subject of illegal acts...
Just curious, how does this software work with subpoenas? Can the Clerk of the Court plug in an override code? How about the plaintiff's attorney? There must be an override of some sort for this, or the courts will have some harsh words on the subject. Not that that had ever bothered Microsoft before.
(This is, incidentally, a similar issue that I have with most copy-control software, that has no provisions at all for the expiration of copyright.)
This seems to be the thinking here. There's no need to trust your employees, you can just force them to work the way you want them to.
And while the business is not trusting its employees, it is telling the public "trust us, we aren't polluting/bribing/defrauding."
I sense a disconnect in this process somewhere...
I agree that there is a business use to this... it allows a business to hire scummy people that are willing to defraud the public, without worrying that they might defraud the business.
While I agree with this advice in many cases, there is one little annoyance with the advice:
Until the thought occurs to you independently, you won't believe it anyway.
It's wonderful to be one of those people that learns from other people mistakes, rather than taking the time to make them all yourself... but some things you seem to have to just figure out on your own.
My advice would generally be more "do things" rather than "avoid things". Oh, and don't worry about looking stupid and feeling self-conscious, do it anyway.:)
Have you looked at what companies actually require for uptime and service availability guarantees?
IBM is famous for their guarantee of 5 nines sevice availability, 99.999% uptime. Look more closely. That is for a limited selection of certified applications only, and only for system clusters. That gives you redundancy for hardware failures that take out a box. Yes, even a $1.5million mainframe box, you want the 99.999%, you do it with 2 mainframes in a failover cluster.
I'm not knocking IBM for doing this, after all, it gives great results. I'm saying don't bash MS for getting reliability by doing the same thing.
Feel free to bash them for making an OS that you can only reliably run 1 server process on though.:)
Slashdot Mirror
I think my issue here is with one of your starting assumptions.
You seem to think that most people will (or at least should) realize that a non-WEP'd wireless access point is the same as saying "I'm willing to share" for a random home user. Or a random small business user, for that matter.
I agree that WEP is inherently insecure, and not much better than politely asking someone "please go elsewhere." MAC filtering is the same, given cards that can clone MACs.
Our basic disagreement comes from the fact that I expect a "random home user" to be someone who believes (falsely) that a purchased WAP is secure and will only work with his own stuff, just like a wired switch, and requires no additional configuration out of the box, just like a wired switch. And therefore, the "polite" action is to look for a feature of a WAP that explicitly states sharing is allowed/accepted. The default should be "please go away" instead of "feel free to use this."
You almost seem to agree with this, in your analogy to your wired switch on your desk. You expect people to ask first. You don't say what a "no response" means in that case. If someone walks by and sees a switch on your desk and you aren't there to ask, are they right to plug in without asking? Or is the default "polite" response there to assume a lack of permission unless explicitly given? You don't cover this in your "and then being told yes or no."
A wireless access point without WEP, I argue, is like your switch sitting on your desk without you there to ask. What is your assumption for the meaning of "no response" to your question of "can I use this resource?"
And, from curiosity, does your assumption of the meaning of "no response" change for wired versus wireless access? If so, why does your assumption change?
For most people, wireless access points are sold just like a cordless phone. And most people consider a cordless phone to only work with the handset that comes with it. Except they don't really think of it that way, they think of it as "It works with my stuff" as is, frankly, the reasonable way to consider things.
The problem here is that most people's life experience is dealing with things that people control. Not things that computers control. You put computers in control of things, and you lose a lot of contextual information that people use to make decisions. Because, frankly, much as we like them, computers are incredibly stupid.
People want to buy things that will work in their house with their stuff. And when they plug something into a wall, it works with their stuff that they plug in. And when they buy something that is "just like wired, only the convenience of wireless" which is how most of these things are sold, they expect it to work the same way.
And then people like you come along and say that it's right to take advantage of this. I'll bet you liked driving around neighborhoods 10 years ago with cordless phones and making long-distance calls on other people's lines, because, hey, if they didn't want you doing that, they wouldn't use something that allowed it. Right?
Congratulations, you are a parasite on society.
Reading furthur, you say:
and immediately follow it with
Hmm. In one place you say "take advantage of the morons" and in another you say "be polite and don't use a resource that someone asks nicely that you not use."
Umm... you don't really have a fully-developed moral and ethical code, do you?
Decompression stops? Hey, I don't do deco diving on purpose. Hmm, that didn't come out quite the way I meant for it to...
:)
I've done borderline deco before, computer says I need a 1minute deco stop at 10ft, while I'm finishing a dive at 90ft and getting ready to ascend. By the time I do a slow ascent up to 40ft, the 1min/10ft deco stop has cleared and the computer is happy again.
Conservative computer algorithms, gotta love em.
But I still want the gameboy, for the safety stop. (Probably) wouldn't use it for deco stops, just because the computer can get upset with you if you don't follow it's exact deco profile.
And... really, and extra air tank? Yuck. I dive nitrox, unless I have a reason not to. Don't you like happy gas? I just feel less tired after 4 nitrox dives than I do after 4 air dives. I don't care if it is purely in my head, I live in my head, so I'll be happy there.
And I'm still rather struck by the thought of learning sign language.
With an underwater housing that I can take 100ft deep while scuba diving. And play in the housing.
I love scuba diving, but sitting in the water 15ft down for 3-5 minutes for a safety stop is one of the most boring things I've ever found to do. All you can do is float there listening to yourself breathe.
I'd love to get a Gameboy in an underwater housing, so I can take it diving with me and amuse myself while watching 3 minutes go by.
That or I need to learn sign language so I can chat with my dive buddy... (And make him/them learn sign language too.)
But the gameboy in the underwater housing would be cooler.
And yes, I do dive with a digital camera in an underwater housing. Canon Powershot S40. I want the Gameboy *too*.
Yes, that's one reason I like the HID bulbs instead of the "standard" cave-diver 50W halogen bulbs. The HID bulbs dissipate a lot less heat, and, from a heat perspective, have no problem being used out of the water.
That said, the HIDs do put out a lot of UV light, and it is recommended that you not look directly at the bulb for long periods of time when it is out of the water. Underwater, it isn't an issue, as water absorbs the UV over a very short distance.
Don't really disagree with your comment of multiple lights, though. But he's already said he doesn't want head-mounted, and he probably wants one hand free for other things, so he's limited himself to only 1 (active) light at a time. Which is another reason I like the hand mount for the DiveRite, it puts the light on the *back* of your hand, with a strap going around your hand to hold it in place. So you can still use your fingers and palm for gripping and holding things.
How about some scuba diving lights? How much weight are you willing to deal with for this? And how much money are you willing to spend? And how long do you need it to last?
:)
Underwater Kinetics (UK) makes a Light Cannon that uses 8 C batteries, lasts about 3-4 hours burn time, and puts out 450 lumens. (Did I mention it's bright?) Uses a HID (high intensity discharge, basically a 15,000V voltage arc) bulb that lasts about 1000 hours. Fixed-focus reflector, but it comes with a wide-angle lens filter to spread the beam. This will set you back about $175.
You can get the same thing, slightly brighter with a separate battery and light head from Dive Rite with a selection of battery choices. A HID light head (equivalent light output to a 50W halogen bulb) with a couple different battery options. These mostly use rechargable batteries (lead-acid, NiCD, or NiMH) and make a really nice light. Nice thing with these is that the light head has a simple hand mount with a power cord going back to the battery case, you point your hand where you want to see and stick the battery in your backpack. Can move the bulb in the reflector, to give a choice of spot or wide angle. Depending on the battery you select, you get from 2-6 hours burn time on a charge. Major down side is that these are kinda heavy. Oh, and kinda pricey, expect this to set you back about $600.
But it's a beautiful light.
And you already learned the benefits of rechargable batteries.
Other downside with the HID bulbs is that they are, I'm told, fragile. I have one, and have not had any problems with it, but I also haven't dropped it off a table yet. And the replacement bulbs are pricey too.
I dive with a Dive Rite MLS-1 with the H1 head. My last night dive, I complained I couldn't find my buddies because they all had these tiny little lights that disappeared in the beam from mine. They were all diving with standard xenon-bulb(?) 8 C Cell dive lights, which are generally considered bright primary lights. Okay, I was kidding, but the difference in light output was extremely noticable.
Don't know how this compares to your current lights, but it might be something worth looking into.
And don't forget the most important requirement for this little toy...
Must continue to work for as long as you want the marriage to last.
This argues strongly for something where the utility is what it is, rather than what it does.
A "does" will wear out, mechanical failure, chemical breakdown, too many cosmic ray strikes, whatever. A "is" will last as long as the ring is in one piece.
The DoD is very interested in having easy identification for the 1.3 million military personnel in the United States. This means pay information, service records, ratings, training, specializations. Medical records. Retirement information.If it's tracked, they want to have it all referenced to a single identity, cross-referenced on different systems.
They were working for a while on smartcards for all military personnel, and that's actually gone pretty far along.
But they've probably learned that there's too much to stick on a smartcard, and you can't get good enough security to put confidential information on the smartcard that you give to 1.3 million people. Too many will lose them, and then you have problems.
So they want to have the records, and have them easily tied to individuals. And have them available in the different commands, on different servers scattered thoroughout the DoD command structure.
They are very interested in something like the Liberty Alliance, and making sure that they can use it for their purposes. Keeping this diverse array of information for 1.3 million people is just what this project is made for.
Seems good that the DoD became aware of it, and decided to participate. And I'm reassured that they didn't decide to just go with the Microsoft solution without considering the options. (Maybe they learned from the problems the Navy has been having with NMCI.)
The "bacteria cause stomach ulcers" is a good example of this. Established scientific/medical community says "that's ridiculous" to a new claim. So the claimant tries to get it accepted by other means.
However, if you notice, these rules do cover that situation also.
1) The announced discovery was not *direct* to the media, but tried to go through the scientific review process first. Exact methods were released so other scientists could study and duplicate the results.
3) Effect was easily measured.
As stated in the article, these are warning signs, not guarantees. It's "be more careful examining these claims" instead of "dismiss them out of hand."
I got lucky.
Read http://www.iwf.org/pubs/figures.shtml.
Quoting from http://www.dadi.org/mc_wages.htm
Hmm. I admit, that's a narrower category than I remembered. "Workers age 27 to 33 with no children" jsut isn't terribly representative of the entire job market.
But a summary/review of that book is probably where I got that statistic from.
There are two good reasons to have music separate from the player.
First, you can conveniently trade music away from your computer. I have an iPod. (I love it.) I can't trade music from my iPod to a friend's iPod without going through a laptop or desktop computer. You can argue this is a software issue Apple could fix with a firmware change, but the little lcd screen really isn't a good way to do selection for "send this but not this". That's probably part of why you can't delete songs on the iPod unless you hook it up to a computer. (Though I'd really like to be able to do that too.)
Second, you don't use any battery power by handing your friend a cd or mini-cd. This is a wonderful thing for a device with no swappable battery. These things live and die by battery usage.
It's interesting that you should bring this up. I have slightly different, but supporting, perspective on this.
Military safety training...
Every 3-7 years, you get a change in pretty much all training guides for all safety-related procedures in the military.
The military doesn't do this because the safety procedures actually get better. They do it because, if they change the training guides and safety procedures, people stop being bored with the "old" way of doing things, and pay more attention. And simply because they are paying more attention, the accident rates go down. (Or stay stable instead of going up.)
So the effort of changing safety guidelines and procedures (which costs a noticable amount of money, and tends to look silly to outsiders who say "this is effectively what you had before!") actually has a benefit in fewer hurt soldiers.
Yes, they did studies on this, sorry for not providing a link. A lot of the silly things the military does actually have good reasons, if you dig enough.
First, as was mentioned in another post, you'd have EEO problems if you tried to do that.
But second, this is one of those wonderful "lying with statistics" examples.
There are a couple of issues with this, mostly in assumptions, and partly in attitudes and priorities. Partly just societal realities.
First, some of these studies look at "average pay for all women in workplace" vs "average pay for all men in the workplace". This ignores pay differences in types of work, and gender majorities in job types. Most administrative/clerical/secretarial jobs are primarily female, and these jobs tend to be lower paying, dragging the average down. Most managerial and technical jobs are primarily male (though this is changing) and these are higher paying jobs, dragging that average up.
Second, it ignores time-in-grade issues. Women started entering the workforce in the 40s with WWII, but lost a lot of ground at the end of WWII, and in the 50s just started with (as I already said) secretarial and that type of work. Typically lower paying. Women didn't start becoming common in managerial and technical jobs until the mid-to-late 80s. Therefore the "typical" woman in these fields has less time-in-grade, and less experience, than the typical male. That makes a differences in pay rates.
Third, and this is the societal, women are (generally) encouraged to be the caregiver of a family, for a 2-income family. This means they'll be more likely to take time off work to take kids to see the doctor and similar things. Also, they'll probably take off significant amounts of time for pregnancy/childbirth, and possibly a couple of years after that too. (My mom married and worked until she got pregnant, then stayed at home until I started going to school, and then she went back to work... that's 5 years out of the job market, and she has a technical degree.) This is a matter of your priorities. What is important to you?
Fourth, and this one isn't fair, is that men are perceived to be more willing to put in extra time at work, because the wife is at home taking care of the kids. Therefore, it is more worthwhile for a business to promote a man, because he'll spend more time working for the business.
When you take out these non-equivalent pieces, and actually compare apples to apples, you find much more equal pay rates. For a man and a woman in a technical field, with the same time in the job market, with similar time-taken-off rates, the woman will be paid about 98% of what the man is paid.
However, this usually means you are comparing single women (or childless married women) to single *and* married w/children men.
Which means that, if you pay attention to the statistics, you learn that the way for a woman to get near-equivalent pay is to sacrifice a family life.
And this just sucks.
Incidentally, yes, I'm male.
Though you might see more effects of this on a low bandwidth link, it is not just for low bandwidth.
A fair number of protocols do transmit windows of a certain size. They'll send a certain amount of data, and not send more data until the oldest packest in the window gets an ACK back. You therefore only have so much data "in-flight" at any one time. Strongly asynchronous link (like aDSL and cablemodems) can require strikingly different window sizes than synchronous links.
The right amount of in-flight data is dependent on the speed of your pipe, obviously, but a lot of applications still use defaults set for low-bandwidth pipes. You can argue that the proper solution for this is to change the defaults, but if you just give ACKs priority, you don't need to worry about it, and the less you force users to change, the better. (The transmit window size has to be a user setting, directly or indirectly, either by asking a window size, or by asking "what kind of pipe do you have?" and guessing a window size from that.)
This is dependent on the protocol, true, but giving ACKs priority is actually a decent generic solution to what many consider an application-specific problem.
QOS is also often about bandwidth guarantees, not necessarily throughput. You have a 155mbit link shared among several applications, and an application that *requires* 45mbit. So you use QOS to guarantee that application gets 45mbit if it wants it, and everything else shares the remainder. If the app isn't going, then that 45mbit it requires can be made available to other apps until it is required.
I have the same objection to Mozilla's memory footprint and load time. My solution was a little different than yours.
Instead of dealing with IE, I switched to Phoenix. The version 0.5 is kinda worrisome, but it is basically Mozilla 1.2 with a bunch of the excess junk stripped out. All the functionality for the browser, strips out the news and mail clients, and simplifies the user interface some. (Still supports all the configuration options through the CSS and js files.)
Try it, you may find you like it.
You don't really know how much it costs to employ a person, do you?
Did you notice the text in there about "plus overhead costs"? That means little things like Employer Taxes (SocSec, Medicaid, etc), retirement contributions, health insurance, and other related.
The actual cost to employ someone is generally 50-70% more than their salary. A "cost" of $75k means the person is probably paid about $45-50k salary.
And this ignores the cost to actually hire anyone. For any large corporation with a serious HR department, it probably costs the company about $30k to go through the process of hiring someone. That's why large companies hate high turnover, the HR costs become unbearable.
Hmm. Okay, thanks.
I couldn't remember if I had issues with "int" on a 64-bit platform because it wasn't the "natural word size" of the platform (and therefore wasn't the same size as a pointer there) or because it changed the data type size and screwed up my reads. Thanks for correcting my crappy memory. (I had issues with data type size with logicals in fortran, but I tend to think that was a compiler error because it changed between compiler versions on the same architecture as well as between architectures. Guess I was thinking of that.)
Incidentally, I have issues with a 32-bit "int" on a 64-bit platform. An "int" should be the natural word size of the architecture you are running on. If you want a 32-bit int explicitly, use a specific variable declaration for that size. If you want a 64-bit int, use a specific declaration for that size. If you want natural word size of the architecture, "int" should give it to you. Yes, this can make porting more difficult... so learn to use "short int" when you want 16-bits, and other variable declarations to explicitly note required data types.
Hmm... http://www.opengroup.org/public/tech/aspen/lp64_w
And while you're correcting my mistakes... Is __int32 and __int64 portable across platforms/compilers? I never can remember.
Benefit? That's easy... anyone that owns a digital camera.
Because you'll be buying a new one eventually... and in a couple years, you'll be buying 20megapixel digital cameras for $400. In other words, all your favorite geeks will have one.
And they'll want to edit these pictures on their computers. You wouldn't think that would need so much memory...
But.
Try it with 10 pictures at once, cause you want to see which has the best overall shot of everyone in your group standing in front of your friend that had a cool wipeout skiing.
You make a couple minor changes in 7 of the pictures, adjust color balance, change brightness, red-eye reduction, stuff like that. Your image editing app of course has multiple undo. (Don't they all?)
You copy a few of the images around, shoving them through the clipboard.
4 copies each (multiple undo, remember) of 10 images each at 80MB per image (32-bit color on 20megapixels...) that's... 4x10x80MB = 3.2gig of ram you just used.
Just for editing 10 pictures from your $400 consumer digital camera.
Now do you see why you want a 64-bit cpu that handles more than 3gig of ram for a single process?
(Yes, I purposely assumed that a simple "adjust color balance" requires a complete seperate copy of the image for undo, and it probably doesn't... but you get the point now, don't you?)
I don't think you read the same thing I did.
Linus doesn't seem to be saying "if the teams were on equivalent footing, x86 would still win."
Instead, he's saying (in part, among other comments) "because x86 has such huge volumes, Intel/AMD can afford to optimize it to a point that it beats all the 'better' low-volume games in town. And that will never change as long as x86 maintains high volumes."
Of course, he's also saying that those 'better' architectures aren't really all that much better. And in some cases he thinks they are worse.
But he is not making statements of "in a fairy world where they are on equal footing" because Linus lives in the real world, and cares about how things work in the real world.
It is still a full port, if you want to get the benefits of the 64-bit architecture. If you want to keep running 32-bit x86 code, don't even bother recompiling. But don't make the mistake of thinking that switching 32-bit x86 code over to x86-64 is a simple re-compile.
//(forgive me if I have the parameters backwards, I'm doing this from memory. And notice that I'm a bad programmer, I didn't check the return value.)
It is still a port, with all that is included in that awful word.
Do you understand how little 64-bit safe code there is that runs on 32-bit x86 systems? Most of the linux kernal is already 64-bit safe, because it has been ported to so many other 64-bit architectures already. And it still wasn't a simple "just recompile it".
Speaking specifically to C programs here, porting from 32-bit to 64-bit is not a fun process. A variable declared as "int" switches in allocation size. This is good and bad.
fread (fp, sizeof(int), &var);
Congratulations, you just killed all your existing data files. And if you happened to read a 32-bit pointer from that data file (any structures that you write directly that contain a pointer write a pointer... you'll throw the pointer value away when you read the structure back in, but you still have to read the proper data size), and then assign a pointer to it... Oh, you're going to have all sorts of fun playing with that.
Yes, this may only be an issue with "bad" C code that assumes it will ever only run on a 32-bit platform... That probably covers 99% of all x86 C code out there, for any OS you care to name.
Don't pretend it will be easy moving from 32-bit x86 to x86-64. For most programs, I assure you, it will be non-trivial. Anything that does direct memory allocation will have to be checked very carefully. Anything that does binary file i/o will have to be checked very carefully. Oh, and anything that uses "magic" numbers will have to be checked... Have you ever used an if conditional for an int of the form
if (i == 0xFFFFFFFF)
congrats, you just assumed 32-bit for your architecture.
64-bit clean code is the exception, not the rule.
You're mixing up 3 classes of computing machines.
... processors". This is not a mainframe, this is a different category. They also generally have very high inter-cpu memory transfer rates, for handling dependent parallel computations.
:)
Supercomputers are almost purely cpu number-crunching beasts. This is what you seem to think of as mainframes with "over a thousand
Most mainframes, like IBM's Z Series, have 24 to 36 CPUS. A mainframe is not about cpu performance, a mainframe is about data. A mainframe has system data throughput that puts almost any other system to shame. Historically, mainframes are good at supporting many simultaneously-connected users doing data queries and updates. (Yes, they run huge databases very well.)
And then you get Beowulf clusters (your Google remark, effectively), which are really chasing the supercomputer market, and not the mainframe market. Beowulf clusters care about a limited class of supercomputer applications, they are good where you need a lot of parallel number crunching, and have very little data dependency between parallel calculations, so you don't need a lot of inter-cpu communications.
Pick the type that's right for your job, and you'll be happy. Pick the wrong one, and you'll have nothing but problems.
And it helps if you're stuck-up intelligently, that way people will still hate you, but won't think you're stupid any more.
If they are dumping their waste in the stream that flows through my back yard, it's my right to see it.
On the subject of illegal acts...
Just curious, how does this software work with subpoenas? Can the Clerk of the Court plug in an override code? How about the plaintiff's attorney? There must be an override of some sort for this, or the courts will have some harsh words on the subject. Not that that had ever bothered Microsoft before.
(This is, incidentally, a similar issue that I have with most copy-control software, that has no provisions at all for the expiration of copyright.)
This seems to be the thinking here. There's no need to trust your employees, you can just force them to work the way you want them to.
And while the business is not trusting its employees, it is telling the public "trust us, we aren't polluting/bribing/defrauding."
I sense a disconnect in this process somewhere...
I agree that there is a business use to this... it allows a business to hire scummy people that are willing to defraud the public, without worrying that they might defraud the business.
While I agree with this advice in many cases, there is one little annoyance with the advice:
:)
Until the thought occurs to you independently, you won't believe it anyway.
It's wonderful to be one of those people that learns from other people mistakes, rather than taking the time to make them all yourself... but some things you seem to have to just figure out on your own.
My advice would generally be more "do things" rather than "avoid things". Oh, and don't worry about looking stupid and feeling self-conscious, do it anyway.
Have you looked at what companies actually require for uptime and service availability guarantees?
:)
IBM is famous for their guarantee of 5 nines sevice availability, 99.999% uptime. Look more closely. That is for a limited selection of certified applications only, and only for system clusters. That gives you redundancy for hardware failures that take out a box. Yes, even a $1.5million mainframe box, you want the 99.999%, you do it with 2 mainframes in a failover cluster.
I'm not knocking IBM for doing this, after all, it gives great results. I'm saying don't bash MS for getting reliability by doing the same thing.
Feel free to bash them for making an OS that you can only reliably run 1 server process on though.