There are many old/new tricks for Mozilla that allows (sic) malicious scripts to cross Mozilla security zones too. (Well, they aren't called security zones, but some scripts get more privileges than others.)
Mozilla is an increasing target for the attackers, just like every other program that touches a network was/is. Just wait and see.
WiX is most definitely not dusty -- it is still under active development. It never made money because it was internal-only until now. A lot of teams at Microsoft use it for the stuff they ship.
It probably depends on the version of IE. I'm using XP SP1 right now, and IE reports version 6.0. I didn't notice what they were on SP2, but I'm guessing they're tighter. They're downright draconian on W2k3.
In any case, here are the settings on my XP SP1 version of IE6:
Default security for Internet zone: Custom (but very similar to Medium, and the same in all of the settings I list below).
Check all of these 3rd-party sites that I have chosen which list a bunch of security holes for Explorer. How evil! Now check a specific query that I have chosen. See! No bugs!
Well, duh. If you get to pick the evidence, you can prove whatever you want. I'll try my hand at this game. Try this page. 9 serious security issues in the November 2003 update. And I was even nice and kept it on Mozilla's own site. These are the vulnerabilities that were fixed in the last release. Good job, but that isn't any better than the IE story.
BTW, I wasn't very impressed with the vulnerabilities on the pages you linked to. Some of them are "vulnerabilities that must be executed in the My Computer domain" (um, the My Computer domain means you are a program on the local computer, so how is that a vulnerability?), others that exploit holes in 3rd party plugins, and others that require the user to click OK a couple of times. I'm really not sure how you can consider any of those as real problems with IE. Sure, they're opportunities for social engineering, but those aren't security flaws any more than any other program that allows you to download code from the Internet. Yep -- FTP is an insecure program, because if you type "GET program.exe", then double click on program.exe, it runs code on your computer!
The ones that actually seem to be dangerous and due to actual problems with Explorer and not false alarms or 3rd-party issues, well they don't seemt to work very well. Perhaps they've been patched?
Honestly, I use both IE and FireFox. They both have pros and cons. They both have security issues. But neither one has a clear advantage in terms of security. Hackers are creative, and they come up with new attacks every day. No code is perfect, but it seems that everybody is doing the best they can do.
That means nothing. In any computer product that is intended for use by non-computer-experts, the developer needs to keep this in mind: You cannot trust the end user to make good decisions regarding computer security.
Here is what I mean. My dad clicks on a link. The front page says "Click here to install the software necessary to view this web site." So he clicks. He gets a scary message, warning about potential viruses and trusting and digital signatures and stuff. None of it makes sense. Essentially, it gets translated into the following question:
Do you want to visit the web site? OK / Cancel.
XpInstall is just as vulnerable as ActiveX in this regard. People are dumb. Just like you don't care enough to read the full EULAs with all their legal mumbo-jumbo, most computer users won't really consider the warning.
And, by the way, ActiveX also requires an OK before installing, just like XPI. There are buffer overflows or cross-site scripting attacks that can bootstrap an attack without ActiveX (and to which Mozilla is just as vulnerable), but ActiveX itself doesn't offer any way to auto-install software without the user's agreement, unless the user changes the Internet Security settings.
ActiveX == Browser Plugins. Mozilla allows plugins, so there is NO difference.
IE gets updated whenever a security flaw is found. And the user is prompted to download the update. I don't get alerts when FireFox needs an update -- I go to the website once in a while. You tell me which method is more likely to keep my dad's computer secure.
My understanding was that the MS Wireless stuff was aimed mostly at validating Windows CE. Here are a few additional ideas about what Microsoft got out of their foray into the Wireless domain:
1. They found out what it was like to try to take a Windows CE product from design to market. This is very useful in identifying areas for improvement. Customers can complain and make feature requests, but there is nothing like making your dev team actually use the product. The WiFi program prompted a lot of improvements throughout the CE product line.
2. They showed potential customers of the CE OS that CE actually CAN work in a consumer system.
3. They influenced the direction of the Wireless market.
Good points. There are always two sides to every story, and the "other side" is often ignored completely at Slashdot. A bit off-topic, a bit trollish, but also something that more Slashdotters need to realize. Someday most of them are going to realize that not everything can be free.
Not to say that free is bad. Man, there's some amazing free stuff out there -- more power to 'em. And the free stuff helps keep Microsoft on its toes, so it is probably (in the long run) good for Microsoft, too! Linux will continue to improve, and it will continue to be used by a lot of people. But Windows will also continue to improve, and it will also continue to be used by a lot of people. Windows will always offer features that Linux can't provide. And Linux will always have some characteristics that Microsoft can't provide. Some people can do without the extra features of Windows, and will prefer the simplicity and raw power (and price!) of Linux. Others will want the extra stuff Microsoft can offer, and are willing to pay for it.
Yes, it is brilliant, and cool, and I'm excited about it. But it isn't quite "holy cow, I never would'a thunk it!" Virtualization has been around for a long time, in many different guises. CoLinux is an implementation of a well-known virtualization paradigm. The beauty is not in the groundbreaking hack, but the fact that it fits perfectly into a niche that has gone unfilled for far too long.
If you've done much mucking around with Windows CE, you would know that there are several different "Windows CE Emulators" available. The first one (the H/PC emulator) was almost exactly equivalent to CoLinux (except that the H/PC emulator was really lousy, and CoLinux seems to work fairly well). The current one is more similar to VmWare (in fact, it is a modified version of Connectix VirtualPC) due to the fact that people needed to use it to debug kernel-mode drivers as well as apps. But both basically do the same thing as CoLinux by using a patched Windows CE kernel to improve the efficiency of the virtualization. The idea is the same -- the kernel is hacked to make it cooperate with the Emulator so that some of the corners can be cut on the virtualization.
I don't think resource contention is going to be an issue. The CoLinux system (as I understand it) doesn't access the hardware itself. Instead, it translates the Linux syscalls into NT kernel API calls, essentially creating a Linux Subsystem for NT (much like Interix creates a Posix subsystem for NT, except that Interix actually exposes itself as a subsystem, while CoLinux exposes itself as a driver).
As far as rings go, Intel didn't do a very good job of assigning privilege levels to the 4 rings, so essentially there is little value in using rings 1 and 2. VmWare might use them, but they don't really help much. I don't think the rings come into play very much in CoLinux, either. It is probably better to think of it as kernel-mode and user-mode rather than ring 0 and ring 3.
The key difference between VmWare/VirtualPC and CoLinux is the level at which the abstraction takes place. VmWare creates an entire virtual system that runs the original OS kernel, emulates the hardware's response to IO requests, etc. Under VmWare, an app requests a timer callback and sends a syscall to the kernel, the kernel forwards that to a device driver, the device driver sends 0xFFFF to port 0x1234, the port IO is trapped by VmWare, VmWare translates the port IO into an NT driver request "please notify me when 0xFFFF clock ticks have gone by". CoLinux has the advantage of being able to patch and recompile the kernel to skip the device driver phase, so it only needs to provide a user-mode interface. Under CoLinux, an app requests a timer callback and sends a syscall to the kernel, and the kernel forwards that directly to an NT driver request, skipping the most expensive steps of VmWare's virtualization process.
As far as ring 0 access to memory, it actually goes through the same virtual memory system as ring 3. The difference is in the fact that ring 0 can manipulate the virtual memory mapping at will. Pretend you run in ring 3 and I run in ring 0. Neither one of us can walk through a closed and locked door, but I have the key so I can unlock and open the door if I want to. The kernel can't normally bypass the virtual memory system, but it can remap the memory to achieve the same effect.
And for debugging Windows, well, again this is nothing new. If you want access to Windows, just use the kernel debugger. Download the latest version of "Debugging Tools for Windows" from Microsoft, and you will see that there is an option called Local Kernel Debugging that allows you to look through the memory and internal kernel structures of your own system while it is running, with a few limitations (the limitations come because you can't stop the local kernel without also stopping the local debugger). If you don't like the limitations of local debugging, you can connect two computers together with serial or firewire
Perhaps the government should not legislate morality. But it shouldn't legislate immorality, either. It cuts both ways.
In general, laws are all about morality (except the bad ones, which are all about politics and/or greed). Getting rid of morality generally means getting rid of laws, and the result is anarchy.
Whether or not you are religious has nothing to do with it. You still have ideas about what is right and what is wrong. And the way society works is that we try to figure out a set of rules (laws) that we all agree to live by. Not everybody will agree with all of the laws, but living with a few laws you don't agree with is the price you pay for living in a society with laws.
I suspect that what you meant to say was that laws should stay out of personal issues. To a certain extent I agree with that idea, but there are some important factors to consider.
First, what is a personal issue? I think that when you look at it long enough, there is no such thing as a personal issue. "No man is an island, entire of itself." If you screw up your life, society pays.
Society pays in the loss of your potential productivity. If you screw up your life, you hold back society. Instead of paying back the investment everybody else has made in feeding you, schooling you, and paying your bills while you were growing up, you throw it all away. And then the rest of the world has to continue paying for your welfare.
Society pays in cleaning up after you. You know how hard it is to get the bloodstains out of the carpet (metaphorically speaking)? Bankruptcies, jails, unpaid hospital bills -- all of these have to be supported by society at large, and all of these go way up when certain "personal issues" become widespread. "Society" has to pay the bill, so "society" gets to try to defend itself by making rules against these so-called "personal issues."
Finally, society pays because some of these "personal issues" end up turning into public issues. Nice Guy starts out with "casual" drug use, gets addicted, loses his job, turns to theft to pay for his habit, and causes problems to his family, the police, and the people from whom he steals. "Personal issues" never stay personal for very long. They always cause problems for other people.
Second, some things are simply bad for you. Besides the issue of what is bad for you is bad for society (covered earlier), there is also a notion that people are morons and that we should try to help each other not be so dumb. Here is the reasoning:
When you were a kid, there were rules. If you didn't follow the rules, you got punished. Some of the rules might have been stupid, but in general most of them were due to the fact that your parent(s)/guardian(s) had a different perspective than you did, and they understood the consequences of certain actions more completely than you did. While the real reasons for the rules are sometimes impossible to explain to a kid, a simple associated punishment is easy to hammer home. The kid understands the rule and the punishment. That is hopefully good enough to convince the kid to not do stupid life-threatening things, and hopefully allow him to live long enough to understand the reasons behind the rules. Even when the kid understands the real consequences, he often still needs the extra disincentive.
So back when you were a kid, you thought you were pretty smart. But you thought your parents were dorks for not letting you do certain things. Ok, now fast-forward a couple dozen years. You understand some of the reasons why your parents made you do your homework. But you think the legislators are dorks for making stupid laws.
So I have a question: What makes you think you are so smart? Just because you are now an "Adult" are you now magically immune to stupidity and irrational behavior? I know I'm not. So we all develop little systems to help ourselves avoid stupid mistakes. We make our own goals and our own rewards, our own rules and our own punishments.
Methinks you missed the point. He wasn't saying that the conduit would carry power. He was saying that the outlet for the conduit should be near a power outlet. It doesn't do any good to have the conduit come out 20 feet from the nearest outlet...
1. You are correct about the disk performance. Laptop hard drives are ridiculously slow when compared to desktop versions. I am also using a very recent VAIO. My desktop has a 1.8 GHz P4, and the VAIO has a 2.0 GHz P4. At purely computational tasks, the VAIO is slightly faster, as you would expect. But the desktop can do a clean build of the project I'm working on more than twice as fast as the VAIO.
2. With XP, 512 MB is enough memory for most daily work, unless you are running memory-hog programs. However, I happen to know that Photoshop is a major memory hog. All of the others you listed can be, depending on how they are set up and used. Memory hogs are less of a problem on a desktop where there is a snappy hard drive available: when the disk cache is reduced to allow for more programs, you don't feel it much (you've still got the 8MB cache built into the drive, and cache misses are filled more quickly), and when you start using the swapfile, again the disk is faster and has built-in cache. But on a laptop, once you cross the line and you start feeling the memory pressure, you start hurting really fast.
3. I've never noticed XP itself to significantly slow down with increased uptime. I do a lot of programming at work (translated: I stress my work machine a lot, running buggy programs and killing a lot of processes), and sometimes I'll go for a month or so without needing to reboot (and the reboot is usually due to driver reconfiguration, hardware installation, etc., not unresponsiveness). My VAIO also goes a long time between reboots (lots of suspend-resume cycles, but few reboots). However, some programs tend to gradually accumulate resources until they reach a critical mass and drag the computer down. MS Messenger and MS Outlook are the ones that I tend to notice. Logging out and then logging back in usually makes everything all better.
Honestly, that's pretty selfish of you. Entire regions in India that have had nothing get on their feet and begin to contribute to the world economy for the first time ever, and they will continue to contribute, even after the initial economic stimulus is gone. Yet it only takes "years" for the first region to recover.
And the benefits DO "trickle down". I'm talking about the difference between agrarian society (95% of the population is farming for a living) and industrial society (5% of the population can grow enough food for the rest, so the rest are, by definition, engaged in generating surplus and luxuries). The difference between the two is nothing more than efficiency.
Do you buy the more expensive brand of toothpaste at the most expensive retailer so you can support the toothpaste industry? No, you buy the best toothpaste you can find for your money, and you buy it from a retailer that offers the most value (convenience, prices) to you. Anything else encourages waste.
If somebody else can do your job better than you for less money than you are charging, why should I pick you? Because I feel sorry for you? Maybe I feel sorry for the other guy, too. He deserves a shot at my money as much as you do.
The fact is that we (i.e. those that support low-cost provider ideals) aren't applauding the loss to the individual. It sucks. We know. We don't get our jollies by watching people not get their fair slice of the pie. Instead, we're trying to find the best fit for each person and to maximize the total amount accomplished. We're looking for the way to make the pie as large as possible so there is more to go around.
If person A is better than person B at preparing tax reports, then person A might end up taking person B's job at HR Block. Person B is now out of a job. Although this is an inconvenience to person B, he/she will find another occupation that is more suited to the value he/she can provide. It may pay less or more, and it may or may not be fair to person B, but it is simply the way life is.
Here is the key point: The tradeoff is between person A going without a job and person B going without a job. It is NOT a tradeoff between person B keeping his job and person B losing his job. Either way, somebody is out of a job. The economist's position is that it is better for the more efficient provider to take the job. The theory is that the displaced provider will find something else that he/she is good at providing. In the long run, both A and B will end up happier. The cost is the time that B spent out of work: a small percentage of people will always be finding new jobs or being retrained. But in the end, with people doing what they are best at doing, more total work gets done.
There is a problem. While the pie is bigger and most people get a decent slice, some people end up getting more than their fair share, and some don't get anything. But that was a problem even without low-cost provider ideals at work, so it isn't a valid argument against them. It is definitely a problem that needs to be fixed. Low-cost provider ideals don't directly do anything to fix it, but they don't increase the problem either -- they just alter the set of people it affects. On the other hand, with more total pie to go around, it is much easier to work out a welfare program for those who didn't get any.
History has verified this premise. In fact, the difference is so monumentally huge that the surplus is more than enough to pay for any welfare program ever implemented. Our society has people living on welfare with plenty of food and a place to live. It used to be that people without a job (and even people with a job) didn't get anything to eat and starved to death.
I think that is a somewhat dangerous line of thought.
On the surface, I agree with the idea that law enforcement officials need to also be held to standards of conduct. But it is important to recognize that the standards that apply to them MUST be different. They operate in a different set of circumstances, and they have been granted certain leeway that the general population doesn't (and shouldn't) have. While this means they have a huge responsibility, it also means they have a huge burden, and they are still only human. While we need to stop those who abuse authority, we also need to grant a bit of leeway to those who make split-second decisions that turn out to be wrong after months of careful follow-up investigation. These guys didn't have months to determine the correct answer -- they (hopefully) were doing the best they could with the information they had. While it is good to follow up to make sure that this power is not being abused and that those in critical positions are competent, it isn't fair to expect them to never mess up or even hold them completely responsible for the consequences of an understandable lapse in judgement.
If I make a mistake today at work, somebody's computer might crash. If a sniper makes a mistake today at work, an innocent person might die. Even if I make somebody's computer crash, I get to go home a free man. As long as the sniper wasn't fooling around, I would hope he can be allowed to do the same.
Essentially, you're saying that law enforcement officials should be responsible for the results of their enforcement. Again, in a general sense, this is true. But enforcement is a complex judgement call, not a simple short-term value/risk evaluation. Do you shoot at the kid who steals a pack of gum from the 7-11 and runs? Probably not. But what about the guy who hijacks a 747? Complying with all of his demands is the only possible route if you take the normal value/risk assessment. But that will encourage future hijackings. So while taking out the hijacker puts the entire plane full of passengers at a high risk, not taking him out puts every passenger on every plane at an increased risk. If enforcement is only done when the immediate benefit outweighs the cost, criminals will simply find ways to make enforcement expensive, and then they will always get away. All a criminal has to do is put other people in danger and the cops will back off. The result is anarchy.
Cops have to consider more than just the situation at hand. Some crimes are always more trouble to prosecute than they are worth. But if they are never prosecuted then everybody can count on getting away with them, with the result that everybody will do it. If cops never chased guys who run off with small amounts of stolen gas in densely populated areas, then gas stations in densely populated areas would continually get ripped off.
Instead, cops do tend to chase people who drive off with stolen property. So when tempted with the idea of running off with stolen gas, the would-be criminal considers the possibility of a chase and the possible consequences of that, including the possibility of an accident and being responsible for the injury of a bystander. The rational man will determine that this risk isn't worth the $20 in gas, and will pay for the gas. The irrational man doesn't care about the consequences and will still run. And that is the kind of person who needs to be behind bars (the person who doesn't care about how his actions affect others).
The authorities decided to storm the compound. But the Davidians decided to hole up in a compound and defy the law and the law officers, as well as set the place on fire. The sniper decided to shoot at something. But Randy decided to fight the cops and he dragged his wife into the situation. In both cases, looking back (with knowledge of how things played out) we might see something that could have been done differently. But at the time, criminals had purposely put the cops in a tough spot and put innocents in the line of fire, and the cops were trying to make the best of a very bad situatuion.
A bit over-simplified, but one way of looking at it is whether the database engine runs in the same process as the application that uses the database.
A metaphor may be useful here. You could consider it the difference between grabbing a meal in your own kitchen or getting take-out. Making a meal in your own home doesn't really take any coordination from anybody, and you can just take care of it yourself -- you just have to have your own food and your own kitchen appliances. If you want to order out, you have to look up the restaurant's phone number, call, make an order, pick it up, and pay for it, but you don't have to have your own food or your own appliances.
In a standalone database, the database engine runs in the same process as the application (i.e. you eat in your own house). You "start" the database engine by running the app (the kitchen is only producing food when you want to eat). This is simpler because there is just one program to manage, the data storage acts just like any other file you want the application to open, and the database engine is just another module the application uses.
In a service (or client/server) architecture, the database runs as a separate process (the restaurant is a separate establishment). The database engine is one program that can start and stop by itself (the restaurant opens at 9:00am and closes at 10:00pm), and the application is another program that can start and stop independently. This is a bit more complicated because the application has to make sure the engine is running, connect to it, and authenticate to it.
The advantage of the standalone database is simplicity and efficiency in the single-user or single-computer scenario. If you only have one client accessing the database, there is no need for authentication, interprocess communication, locking, etc. The database is just another file to be opened, edited and closed.
If a standalone database is used by multiple clients at the same time, things start to break down (too many cooks in the kitchen at once). The advantage of the standalone database was the simplicity of having only one program to worry about, but if there are multiple clients, that is no longer the case. The different client programs now have to coordinate their access to the database. This is not necessarily hard to do, but it isn't very efficient or scalable. Your kitchen just isn't designed to allow 400 individuals to make their own meals every day. People are going to fight over who gets to use the oven next, somebody is invariably going to leave a mess and not clean it up, and you're probably going to run out of food (who ate my cheese?).
When there are many clients, it is better to just have one database engine servicing all of them, so you create a service that starts and stops independently of the clients. A single process is in charge of providing the data (i.e. a single establishment is dedicated to the task of providing food). This would be wasteful if only one person were to eat there each day, but it is much more efficient if many eat there every day.
Nope. int and long are still 32 bits, at least on MS platforms. long long is 64 bits. The only difference is with the pointers. Otherwise, you have to specifically request a 64-bit data size. This way, you can keep binary compatibility (struct layout) and avoid memory wastage for places where 64 bits aren't needed. But you get more address space, more registers, and faster 64-bit math (when needed).
I just saw some very simple CPU-bounded benchmarks that put the AMD64 2.0 GHz (on WinXP-64) at about 2X the dhrystones of a P4 2.0 GHz. Dhrystones are mostly meaningless, but they do show something.
And to answer the actual question of why the laptop was better, here are my theories (do self-replies to a +5 post make me a karma whore? not that it matters... got plenty already):
The laptop probably had a trackpad instead of a mouse.
If you do use a mouse with the laptop, the number pad doesn't get in the way like it does with a desktop.
The screen is always centered properly (or very close to properly) with a laptop. With an improperly centered keyboard, the arms, wrists, and hands tend to look like this (think of the Y as your hand; perhaps imagine that you have two fingers [grin]): Y Y | \ While with a properly centered keyboard, they look more like this:
Y Y / \ Obviously, you don't want any bend, but it is better to have the bend spread between the two wrists than to have the left wrist straight and the right wrist bent double.
You tend to use the laptop for shorter periods of time in one position. If you get uncomfortable, you move the laptop a bit. You don't usually move your desktop's keyboard or monitor very much.
There are some definite disadvantages of using a laptop. One example would be back problems -- posture is likely worse when using a laptop. A properly positioned desktop setup will be much better than the laptop for nearly all purposes. But the advantage is that the laptop is more flexible, so you can put it exactly where you want it. Most desktops are NOT set up properly, and once set up, the positioning is pretty rigid. The laptop setup is usually far worse, but when you start getting uncomfortable, you can change positions -- again, to a suboptimal position, but a DIFFERENT suboptimal position, so different muscles/tendons/nerves are being strained, allowing the other muscles/tendons/nerves a chance to relax a bit.
In other words, the desktop can be set up to be a better work environment than the laptop, but you have to know what you are doing in setting it up AND in using it -- natural instincts and "common knowledge" don't cut it. The desktop is rigid, so a poorly designed setup will remain poorly designed for years. When your body tells you that it is having trouble with the desktop's setup, your brain tells the body "I can't do anything about it, so be quiet," and the body shuts up until a serious problem develops.
The laptop is almost always a bad work environment, but natural instincts are able to prevent you from hurting yourself. Natural instincts are able to do their thing. It is flexible, so you can change the layout without even being consciously aware of the change you just made. When your body tells your brain that it doesn't like the laptop's positioning, your brain will have the hand give the laptop a nudge into a better position, and the body is happy. This happens many times per hour, without you even noticing. So no serious problems ever develop.
So if you compare the average Joe's desktop layout (i.e. Joe doesn't really know how to properly position the monitor, keyboard, and mouse) with the way the average Joe uses a laptop, I think the laptop is much less likely to cause trouble for Joe's wrists.
Ok, I honestly can't diagnose your situation. But in my experience, the mouse has made FAR MORE difference than the keyboard in causing me trouble. Try switching to a trackball or a trackpad. It takes a bit to get used to the trackball, and they definitely don't have the precision on a mouse (no FPS for you!), but for most purposes, they're perfectly adequate, and they generally put far less stress on the wrist.
I never had trouble with my wrists. Ok, occasionally my wrist would hurt from putting all of my weight on it, but that was a skin-deep problem, not a carpel-tunnel or tendonitis problem. Then I got a summer job using Visual Basic. VB takes mouse usage to new heights, and within 2 months I had serious problems. Fancy keyboards, special extra-large mice, wrist braces, etc. didn't help much. I learned to mouse with my left hand, and that helped since I could spread the stress out. Even after I left that job, I had problems with my right wrist.
Then as I was starting a new job and getting set up with my office equipment, I asked the hardware guy if he had anything that would help with wrist problems. He gave me a "Microsoft Trackball Optical" (some prefer the the "Microsoft Trackball Explorer", so try them both). To make a long story short, over the next 3 months I stopped needing my wrist brace, and over the past 2.5 years, I haven't had any serious trouble. I now have a mouse (any mouse) and a Trackball Optical hooked up to every desktop computer I own. Most of the time, I use the trackball. When I do something where the trackball doesn't work well, I use the mouse.
Looking back, I've done a little bit of research. It turns out that the Microsoft Intellimouse I was using back then has become famous for causing wrist trouble. When it was designed, they did customer studies to find out what shape people liked best, and people chose the old Microsoft Intellimouse as the most comfortable. That was fine for short-term use, but over long-term use, it turned out to be terrible. The hump at the back forced you to bend your wrist. Newer designs have removed this hump.
So don't necessarily blame the keyboard! Try a mouse alternative, or at least make sure your current mouse is well designed (if you are using an older Microsoft mouse, get it replaced immediately, and stomp on it before throwing it away so that it won't ever be able to hurt anyone ever again!).
In addition, get your workstation layout evaluated. Either study up on it yourself, or get somebody who knows about it to evaluate your office for you. Here are a few key points:
Start with the chair. Your feet should firmly reach the ground. You should sit up straight.
When sitting up straight, your eyes should be lined up with a point on the top half of your screen. If you tend to slouch (like I do), your eyes should line up with the top of the screen. If you tend to sit up straight, your eyes should line up with a point 1/3 of the way down the screen.
Your keyboard should be positioned so that when you are in standard typing posture, the part of the arm above the elbow is hanging straight down and the elbow makes a 90 degree bend so that they are parallel to the floor. This should allow you to type with NO VERTICAL BEND in your wrist. The keyboard should be positioned horizontally so that the "6" key lines up with the center of the monitor. Don't line up your keyboard's physical center with the monitor -- line it up so that home row is centered. If you have a split keyboard, this can allow you to type with no bending AT ALL in your wrist. If you have a normal keyboard, your wrists will have a slight bend to one side. That is bad, but acceptable. It isn't acceptable for one wrist to be bent more than the other. And it isn't acceptable for there to be ANY vertical bend.
The mouse needs to be placed so you can switch from keyboard to mouse without moving your elbow (which is directly beneath your shoulder, remember?). Unfortunately for right-handed people, that put
I think the biggest reason is style enforcement. The reasoning goes something like this:
1. Case distinction is room for additional information without increasing the length of the text. 2. For the additional information to actually be useful, people have to know what the case distinctions mean. 3. For people to know what the case distinctions mean, there have to be established conventions. 4. Conventions fall apart very quickly if there is no enforcement or verification. 5. It is useful to make the compiler perform some of the verification and/or enforcement -- you're much more likely to notice problems immediately if the problem is caught by the compiler rather than an optional LINT tool.
It is a lot like case sensitivity for English. It really isn't needed, but it sure helps you understand things a lot more easily. You can scan for the start of the next sentence much more quickly if the sentence starts with an uppercase letter and the rest are lowercase. In the same way, you can get a quick sense of what a variable is for by observing its casing, assuming that you are familiar with the casing convention in use.
English teachers force us to use proper spelling, grammar, casing, and punctuation so we can communicate more clearly. Computer language syntax works the same way. The parser/compiler could do a fine job with a much simpler language, and it doesn't really need to be that strict about syntax checking. ("Error: missing semicolon." If it knows there is a missing semicolon, why can't it just pretend the semicolon is there and go on?) The idea is that stricter syntax checking is useful to the original programmer (many syntax errors are also indicative of logic errors or ambiguity) and also to the maintainer who has to make sense out of the code.
So the bottom line is that following coding conventions makes your code more readable and your intent more clear. Case sensitivity is one way the compiler helps you maintain your coding conventions.
Been interesting posting with you. Thanks for the discussion. Obviously, there are two sides to this coin, and definitely there are some worthwhile arguments for and against.
To make sure that I wasn't just blowing steam, I did a little bit of looking around, reading some research papers, etc. Here is what I came up with:
If your program requires the allocation and deallocation of a lot of items of specific, predictable sizes, you take cache size and available memory into consideration, and really know what you are doing, you can speed up your program by writing special purpose allocators. However, the papers that I read indicated that in 4 out of 5 cases where special-purpose allocators were used instead of malloc and free, it did little or nothing to improve (and sometimes worsened) the speed of the program, but increased the complexity of memory management. Most modern general-purpose allocators are adaptive and set up lookaside tables for frequently allocated block sizes, and they do almost as good of a job as custom allocators in most cases.
Using a conservative GC, such as the Boehem GC for C++ (where there is no language support for GC, so the GC actually has to scan the stack and assume that every bit pattern that matches the heap's address range is a valid reference) is slower for programs that allocate mostly large objects, but actually faster than malloc/free if the program allocates a lot of small objects.
Manual memory management gets slower (more cycles spent making sure you've properly kept track of all of your allocated objects) and more difficult to get right as the application grows in size and complexity. GC doesn't. The more complicated the memory management needs, the more likely that GC will be significantly faster than manual management, even without taking the productivity savings into account.
If threads are involved, lock contention for the heap becomes a significant factor in program execution time. While GC is not free from this, it doesn't degrade as quickly with increased # of processors.
Refcounting is actually expensive, more so than GC. In multi-threaded apps, you have to use an interlocked instruction to update the refcount, or perhaps even make a function call. Benchmarks between refcounted apps and GC apps show GC taking a significant lead. Of course, there are optimizations that can help with this (weighted refcounting), but they aren't used a whole lot.
The function calls to malloc and free tend to blow the TLB and cache almost as effectively as collections. The function calls to specialized allocators often do so as well. The difference is that GC is only called once in a while (relatively), so the TLB and cache are only blown a few times a second instead of every few hundred allocations.
The locality of reference provided by copying collectors has been shown to speed up execution by a significant factor, often saving more cycles than were spent compacting the heap.
Anyway, that is what I came up with. I don't have all of the links, but a lot of them were within a few clicks of the so-called The Memory Management Reference website. I'm even more convinced than I was before.
However, I agree with you that everything has its place. There are places where GC still isn't appropriate. The GC tends to have a larger initial cost than malloc/free (in terms of both code and initial data requirements), so for very simple systems (embedded computers or bootstrappers for more complex systems) the GC just won't work -- there isn't enough room for a program complicated enough to allow the GC to be worth the initial cost. And while "real-time" GC does exist, it isn't yet good/fast enough to be used in the kernel where interrupt handling has to be done within very tight time constraints -- even though a standard GC implementation would likely have better performance (according to what I've read) than the
So lets see if we understand each other. You're saying:
1. Once a criminal, always a criminal. 2. Using monopoly positioning to maintain a monopoly makes a company into a criminal. 3. Managing to get off with a penalty less than what you think they deserve makes Microsoft the worst kind of criminal. 4. If a company is a criminal, that means that everybody else gets to do whatever they want at that company's expense.
Ok, I've got some problems with that. First, why isn't Lindows a criminal now? They have been convicted of abusing the settlement. Now don't get technical with all that nonsense about the class of law they have broken and the terms applied to the ones who have broken which... Oh, and have you ever gone faster than the posted speed limit? If so, I think you'd better give me all of your money, you scummy criminal you.
On a more rational note: please study law just a little bit before you go off about what everybody is guilty of. All business is cutthroat. All businesses are out there to make money. Certain actions are illegal. Certain actions are unfair. Certain actions are mean, wrong, uncivilized, etc. Monopoly hasn't been convicted of doing anything inherently illegal -- it has been decided in that some of its business practices are unfair, and that they are in violation of some contracts. There are laws that state that if a company is engaging in certain unfair practices, the US government has the power and/or obligation to step in and stop those practices and perhaps demand penalties and/or reparations. And there is nothing in the law that says companies can't be mean. They might scare away all of their customers or their partners, but otherwise companies can be as mean as they want as long as they aren't illegal or unfair.
As far as unfair goes, that is a pretty vague adjective, and to a large extent, the definition is unclear until a judge has decided on the case. Some things are definitely unfair, others are a little bit unfair. Well, guess what -- life just isn't fair. So to a certain extent, companies are expected to stick up for themselves and deal with other companies that treat them unfairly. Only when that doesn't work does the government step in, and then only with the smallest intervention that is expected to effectively level the playing field. It doesn't mean that once a company has been "convicted" of "monopoly" that they have to give in and do whatever anybody else wants. Neither does it mean that their competitors can now do whatever they want. It just means that they can't continue with specific practices that have been determined to be "unfair", and perhaps pay damages.
Microsoft is doing this. So the courts have determined that they are ok now. Guess what: you don't get to decide.
You can't have it both ways. Either you agree with the court or you don't. If you agree with the court, then Microsoft has been found to have engaged in unfair business conduct and has been appropriately sanctioned. If you don't agree with the court, then Microsoft has not been "convicted" of anything, since you don't accept the court's decision.
I've heard that for years, it's yet to be true for the general case... and most people doing manual allocation don't call malloc/free for every single grow/shrink operation. The caching slab allocator was put into solaris a long time ago now.
Caching slab, lookaside lists, whatever, you're still calling some kind of allocator with some kind of cost. There are definitely applications where memory allocation/deallocation follows a pattern that allows that kind of optimization to work well. But here is the crux of my argument: 1. the general purpose allocators definitely do have a non-zero cost; 2. special purpose allocators can be significantly faster, but they aren't general purpose, so they don't work in all situations, and they often require significant extra work to make them work properly; 3. special-purpose allocators usually work by speculatively pre-allocating chunks from the general purpose allocator, and this wastes memory; 4. even when you are using special-purpose allocators as much as possible, you still have to spend a lot of time in memory management -- the special-purpose allocator isn't free, and every once in a while it still has to call out to the general purpose allocator, which is expensive. So I stand by the original premise: after all is said and done, the time spent in memory management for a GC-based program isn't much (if any) greater than the time spent in memory management for an equivalient non-GC-based program. When the total cost of the allocations/deallocations is compared with the cost of a similar set of GC-alloc + collections, the difference for most big applications isn't really significant.
The keyword being all, yes you can sometimes just completely forget about designing how you use memory and everything "works". However sometimes those bits of memory have other resources associated with them.
Yep. And now you don't have to bother with those either, since the GC can collect them during finalization of their associated bits of memory. The point here is that while you still might have to write a destructor of some sort, it is usually much simpler (no memory to worry about) and you don't have to figure out when that resource is no longer in use -- the GC will figure it out for you. If the resource must be freed deterministically, GC doesn't prevent you from doing that. But in the cases where it doesn't, GC still works great. In other words: don't refuse the solution just because it only makes 90% of your problems go away -- you're still better off, aren't you?
You seem to be under the impression that running the GC isn't going to blow your cache... why is that?
If the garbage collector itself causes additional page faults, then yes, it isn't an advantage. But the argument was that when compared with page faults (something we've all been willing to accept, something that hasn't caused an unacceptable performance hit), GC is small potatoes. In addition, modern GC implementations take the amount of memory available on the machine into account, and they actively work to keep memory usage under the level that would start causing page faults. The garbage collector can spring into action when a request is made that might result in a page fault, and the page fault only actually happens if there really aren't any objects to release. The GC can dynamically determine which objects are unreachable, while the non-GC program must rely on a static analysis that often means objects live longer than is truly necessary (the GC can free something anytime after the last reference is gone, while a non-GC program has to keep the object until it comes to a point in the control flow that is unreachable until the object is no longer needed). While the dynamic analysis has a runtime cost (the static analysis has no runtime cost), the additional information available at runtime can enable much more efficient memory management, which in turn can reduce page faults, which can off
There are many old/new tricks for Mozilla that allows (sic)
malicious scripts to cross Mozilla security zones too.
(Well, they aren't called security zones, but some scripts get more privileges than others.)
Mozilla is an increasing target for the attackers, just
like every other program that touches a network was/is. Just wait and see.
(Grin.)
WiX is most definitely not dusty -- it is still under active development. It never made money because it was internal-only until now. A lot of teams at Microsoft use it for the stuff they ship.
It probably depends on the version of IE. I'm using XP SP1 right now, and IE reports version 6.0. I didn't notice what they were on SP2, but I'm guessing they're tighter. They're downright draconian on W2k3.
.NET programs = enabled
In any case, here are the settings on my XP SP1 version of IE6:
Default security for Internet zone: Custom (but very similar to Medium, and the same in all of the settings I list below).
Medium security setting:
Download unsigned ActiveX = disabled
Download signed ActiveX = prompt
Run (existing) ActiveX = enabled
Script (existing) safe ActiveX = enabled
Script (existing) unsafe ActiveX = disabled
So what you're saying is:
Check all of these 3rd-party sites that I have chosen which list a bunch of security holes for Explorer. How evil! Now check a specific query that I have chosen. See! No bugs!
Well, duh. If you get to pick the evidence, you can prove whatever you want. I'll try my hand at this game. Try this page. 9 serious security issues in the November 2003 update. And I was even nice and kept it on Mozilla's own site. These are the vulnerabilities that were fixed in the last release. Good job, but that isn't any better than the IE story.
BTW, I wasn't very impressed with the vulnerabilities on the pages you linked to. Some of them are "vulnerabilities that must be executed in the My Computer domain" (um, the My Computer domain means you are a program on the local computer, so how is that a vulnerability?), others that exploit holes in 3rd party plugins, and others that require the user to click OK a couple of times. I'm really not sure how you can consider any of those as real problems with IE. Sure, they're opportunities for social engineering, but those aren't security flaws any more than any other program that allows you to download code from the Internet. Yep -- FTP is an insecure program, because if you type "GET program.exe", then double click on program.exe, it runs code on your computer!
The ones that actually seem to be dangerous and due to actual problems with Explorer and not false alarms or 3rd-party issues, well they don't seemt to work very well. Perhaps they've been patched?
Honestly, I use both IE and FireFox. They both have pros and cons. They both have security issues. But neither one has a clear advantage in terms of security. Hackers are creative, and they come up with new attacks every day. No code is perfect, but it seems that everybody is doing the best they can do.
That means nothing. In any computer product that is intended for use by non-computer-experts, the developer needs to keep this in mind: You cannot trust the end user to make good decisions regarding computer security.
Here is what I mean. My dad clicks on a link. The front page says "Click here to install the software necessary to view this web site." So he clicks. He gets a scary message, warning about potential viruses and trusting and digital signatures and stuff. None of it makes sense. Essentially, it gets translated into the following question:
Do you want to visit the web site? OK / Cancel.
XpInstall is just as vulnerable as ActiveX in this regard. People are dumb. Just like you don't care enough to read the full EULAs with all their legal mumbo-jumbo, most computer users won't really consider the warning.
And, by the way, ActiveX also requires an OK before installing, just like XPI. There are buffer overflows or cross-site scripting attacks that can bootstrap an attack without ActiveX (and to which Mozilla is just as vulnerable), but ActiveX itself doesn't offer any way to auto-install software without the user's agreement, unless the user changes the Internet Security settings.
ActiveX == Browser Plugins. Mozilla allows plugins, so there is NO difference.
IE gets updated whenever a security flaw is found. And the user is prompted to download the update. I don't get alerts when FireFox needs an update -- I go to the website once in a while. You tell me which method is more likely to keep my dad's computer secure.
My understanding was that the MS Wireless stuff was aimed mostly at validating Windows CE. Here are a few additional ideas about what Microsoft got out of their foray into the Wireless domain:
1. They found out what it was like to try to take a Windows CE product from design to market. This is very useful in identifying areas for improvement. Customers can complain and make feature requests, but there is nothing like making your dev team actually use the product. The WiFi program prompted a lot of improvements throughout the CE product line.
2. They showed potential customers of the CE OS that CE actually CAN work in a consumer system.
3. They influenced the direction of the Wireless market.
Good points. There are always two sides to every story, and the "other side" is often ignored completely at Slashdot. A bit off-topic, a bit trollish, but also something that more Slashdotters need to realize. Someday most of them are going to realize that not everything can be free.
Not to say that free is bad. Man, there's some amazing free stuff out there -- more power to 'em. And the free stuff helps keep Microsoft on its toes, so it is probably (in the long run) good for Microsoft, too! Linux will continue to improve, and it will continue to be used by a lot of people. But Windows will also continue to improve, and it will also continue to be used by a lot of people. Windows will always offer features that Linux can't provide. And Linux will always have some characteristics that Microsoft can't provide. Some people can do without the extra features of Windows, and will prefer the simplicity and raw power (and price!) of Linux. Others will want the extra stuff Microsoft can offer, and are willing to pay for it.
Couple comments...
Yes, it is brilliant, and cool, and I'm excited about it. But it isn't quite "holy cow, I never would'a thunk it!" Virtualization has been around for a long time, in many different guises. CoLinux is an implementation of a well-known virtualization paradigm. The beauty is not in the groundbreaking hack, but the fact that it fits perfectly into a niche that has gone unfilled for far too long.
If you've done much mucking around with Windows CE, you would know that there are several different "Windows CE Emulators" available. The first one (the H/PC emulator) was almost exactly equivalent to CoLinux (except that the H/PC emulator was really lousy, and CoLinux seems to work fairly well). The current one is more similar to VmWare (in fact, it is a modified version of Connectix VirtualPC) due to the fact that people needed to use it to debug kernel-mode drivers as well as apps. But both basically do the same thing as CoLinux by using a patched Windows CE kernel to improve the efficiency of the virtualization. The idea is the same -- the kernel is hacked to make it cooperate with the Emulator so that some of the corners can be cut on the virtualization.
I don't think resource contention is going to be an issue. The CoLinux system (as I understand it) doesn't access the hardware itself. Instead, it translates the Linux syscalls into NT kernel API calls, essentially creating a Linux Subsystem for NT (much like Interix creates a Posix subsystem for NT, except that Interix actually exposes itself as a subsystem, while CoLinux exposes itself as a driver).
As far as rings go, Intel didn't do a very good job of assigning privilege levels to the 4 rings, so essentially there is little value in using rings 1 and 2. VmWare might use them, but they don't really help much. I don't think the rings come into play very much in CoLinux, either. It is probably better to think of it as kernel-mode and user-mode rather than ring 0 and ring 3.
The key difference between VmWare/VirtualPC and CoLinux is the level at which the abstraction takes place. VmWare creates an entire virtual system that runs the original OS kernel, emulates the hardware's response to IO requests, etc. Under VmWare, an app requests a timer callback and sends a syscall to the kernel, the kernel forwards that to a device driver, the device driver sends 0xFFFF to port 0x1234, the port IO is trapped by VmWare, VmWare translates the port IO into an NT driver request "please notify me when 0xFFFF clock ticks have gone by". CoLinux has the advantage of being able to patch and recompile the kernel to skip the device driver phase, so it only needs to provide a user-mode interface. Under CoLinux, an app requests a timer callback and sends a syscall to the kernel, and the kernel forwards that directly to an NT driver request, skipping the most expensive steps of VmWare's virtualization process.
As far as ring 0 access to memory, it actually goes through the same virtual memory system as ring 3. The difference is in the fact that ring 0 can manipulate the virtual memory mapping at will. Pretend you run in ring 3 and I run in ring 0. Neither one of us can walk through a closed and locked door, but I have the key so I can unlock and open the door if I want to. The kernel can't normally bypass the virtual memory system, but it can remap the memory to achieve the same effect.
And for debugging Windows, well, again this is nothing new. If you want access to Windows, just use the kernel debugger. Download the latest version of "Debugging Tools for Windows" from Microsoft, and you will see that there is an option called Local Kernel Debugging that allows you to look through the memory and internal kernel structures of your own system while it is running, with a few limitations (the limitations come because you can't stop the local kernel without also stopping the local debugger). If you don't like the limitations of local debugging, you can connect two computers together with serial or firewire
Perhaps the government should not legislate morality. But it shouldn't legislate immorality, either. It cuts both ways.
In general, laws are all about morality (except the bad ones, which are all about politics and/or greed). Getting rid of morality generally means getting rid of laws, and the result is anarchy.
Whether or not you are religious has nothing to do with it. You still have ideas about what is right and what is wrong. And the way society works is that we try to figure out a set of rules (laws) that we all agree to live by. Not everybody will agree with all of the laws, but living with a few laws you don't agree with is the price you pay for living in a society with laws.
I suspect that what you meant to say was that laws should stay out of personal issues. To a certain extent I agree with that idea, but there are some important factors to consider.
First, what is a personal issue? I think that when you look at it long enough, there is no such thing as a personal issue. "No man is an island, entire of itself." If you screw up your life, society pays.
Society pays in the loss of your potential productivity. If you screw up your life, you hold back society. Instead of paying back the investment everybody else has made in feeding you, schooling you, and paying your bills while you were growing up, you throw it all away. And then the rest of the world has to continue paying for your welfare.
Society pays in cleaning up after you. You know how hard it is to get the bloodstains out of the carpet (metaphorically speaking)? Bankruptcies, jails, unpaid hospital bills -- all of these have to be supported by society at large, and all of these go way up when certain "personal issues" become widespread. "Society" has to pay the bill, so "society" gets to try to defend itself by making rules against these so-called "personal issues."
Finally, society pays because some of these "personal issues" end up turning into public issues. Nice Guy starts out with "casual" drug use, gets addicted, loses his job, turns to theft to pay for his habit, and causes problems to his family, the police, and the people from whom he steals. "Personal issues" never stay personal for very long. They always cause problems for other people.
Second, some things are simply bad for you. Besides the issue of what is bad for you is bad for society (covered earlier), there is also a notion that people are morons and that we should try to help each other not be so dumb. Here is the reasoning:
When you were a kid, there were rules. If you didn't follow the rules, you got punished. Some of the rules might have been stupid, but in general most of them were due to the fact that your parent(s)/guardian(s) had a different perspective than you did, and they understood the consequences of certain actions more completely than you did. While the real reasons for the rules are sometimes impossible to explain to a kid, a simple associated punishment is easy to hammer home. The kid understands the rule and the punishment. That is hopefully good enough to convince the kid to not do stupid life-threatening things, and hopefully allow him to live long enough to understand the reasons behind the rules. Even when the kid understands the real consequences, he often still needs the extra disincentive.
So back when you were a kid, you thought you were pretty smart. But you thought your parents were dorks for not letting you do certain things. Ok, now fast-forward a couple dozen years. You understand some of the reasons why your parents made you do your homework. But you think the legislators are dorks for making stupid laws.
So I have a question: What makes you think you are so smart? Just because you are now an "Adult" are you now magically immune to stupidity and irrational behavior? I know I'm not. So we all develop little systems to help ourselves avoid stupid mistakes. We make our own goals and our own rewards, our own rules and our own punishments.
Methinks you missed the point. He wasn't saying that the conduit would carry power. He was saying that the outlet for the conduit should be near a power outlet. It doesn't do any good to have the conduit come out 20 feet from the nearest outlet...
1. You are correct about the disk performance. Laptop hard drives are ridiculously slow when compared to desktop versions. I am also using a very recent VAIO. My desktop has a 1.8 GHz P4, and the VAIO has a 2.0 GHz P4. At purely computational tasks, the VAIO is slightly faster, as you would expect. But the desktop can do a clean build of the project I'm working on more than twice as fast as the VAIO.
2. With XP, 512 MB is enough memory for most daily work, unless you are running memory-hog programs. However, I happen to know that Photoshop is a major memory hog. All of the others you listed can be, depending on how they are set up and used. Memory hogs are less of a problem on a desktop where there is a snappy hard drive available: when the disk cache is reduced to allow for more programs, you don't feel it much (you've still got the 8MB cache built into the drive, and cache misses are filled more quickly), and when you start using the swapfile, again the disk is faster and has built-in cache. But on a laptop, once you cross the line and you start feeling the memory pressure, you start hurting really fast.
3. I've never noticed XP itself to significantly slow down with increased uptime. I do a lot of programming at work (translated: I stress my work machine a lot, running buggy programs and killing a lot of processes), and sometimes I'll go for a month or so without needing to reboot (and the reboot is usually due to driver reconfiguration, hardware installation, etc., not unresponsiveness). My VAIO also goes a long time between reboots (lots of suspend-resume cycles, but few reboots). However, some programs tend to gradually accumulate resources until they reach a critical mass and drag the computer down. MS Messenger and MS Outlook are the ones that I tend to notice. Logging out and then logging back in usually makes everything all better.
Honestly, that's pretty selfish of you. Entire regions in India that have had nothing get on their feet and begin to contribute to the world economy for the first time ever, and they will continue to contribute, even after the initial economic stimulus is gone. Yet it only takes "years" for the first region to recover.
And the benefits DO "trickle down". I'm talking about the difference between agrarian society (95% of the population is farming for a living) and industrial society (5% of the population can grow enough food for the rest, so the rest are, by definition, engaged in generating surplus and luxuries). The difference between the two is nothing more than efficiency.
False.
Do you buy the more expensive brand of toothpaste at the most expensive retailer so you can support the toothpaste industry? No, you buy the best toothpaste you can find for your money, and you buy it from a retailer that offers the most value (convenience, prices) to you. Anything else encourages waste.
If somebody else can do your job better than you for less money than you are charging, why should I pick you? Because I feel sorry for you? Maybe I feel sorry for the other guy, too. He deserves a shot at my money as much as you do.
The fact is that we (i.e. those that support low-cost provider ideals) aren't applauding the loss to the individual. It sucks. We know. We don't get our jollies by watching people not get their fair slice of the pie. Instead, we're trying to find the best fit for each person and to maximize the total amount accomplished. We're looking for the way to make the pie as large as possible so there is more to go around.
If person A is better than person B at preparing tax reports, then person A might end up taking person B's job at HR Block. Person B is now out of a job. Although this is an inconvenience to person B, he/she will find another occupation that is more suited to the value he/she can provide. It may pay less or more, and it may or may not be fair to person B, but it is simply the way life is.
Here is the key point: The tradeoff is between person A going without a job and person B going without a job. It is NOT a tradeoff between person B keeping his job and person B losing his job. Either way, somebody is out of a job. The economist's position is that it is better for the more efficient provider to take the job. The theory is that the displaced provider will find something else that he/she is good at providing. In the long run, both A and B will end up happier. The cost is the time that B spent out of work: a small percentage of people will always be finding new jobs or being retrained. But in the end, with people doing what they are best at doing, more total work gets done.
There is a problem. While the pie is bigger and most people get a decent slice, some people end up getting more than their fair share, and some don't get anything. But that was a problem even without low-cost provider ideals at work, so it isn't a valid argument against them. It is definitely a problem that needs to be fixed. Low-cost provider ideals don't directly do anything to fix it, but they don't increase the problem either -- they just alter the set of people it affects. On the other hand, with more total pie to go around, it is much easier to work out a welfare program for those who didn't get any.
History has verified this premise. In fact, the difference is so monumentally huge that the surplus is more than enough to pay for any welfare program ever implemented. Our society has people living on welfare with plenty of food and a place to live. It used to be that people without a job (and even people with a job) didn't get anything to eat and starved to death.
I think that is a somewhat dangerous line of thought.
On the surface, I agree with the idea that law enforcement officials need to also be held to standards of conduct. But it is important to recognize that the standards that apply to them MUST be different. They operate in a different set of circumstances, and they have been granted certain leeway that the general population doesn't (and shouldn't) have. While this means they have a huge responsibility, it also means they have a huge burden, and they are still only human. While we need to stop those who abuse authority, we also need to grant a bit of leeway to those who make split-second decisions that turn out to be wrong after months of careful follow-up investigation. These guys didn't have months to determine the correct answer -- they (hopefully) were doing the best they could with the information they had. While it is good to follow up to make sure that this power is not being abused and that those in critical positions are competent, it isn't fair to expect them to never mess up or even hold them completely responsible for the consequences of an understandable lapse in judgement.
If I make a mistake today at work, somebody's computer might crash. If a sniper makes a mistake today at work, an innocent person might die. Even if I make somebody's computer crash, I get to go home a free man. As long as the sniper wasn't fooling around, I would hope he can be allowed to do the same.
Essentially, you're saying that law enforcement officials should be responsible for the results of their enforcement. Again, in a general sense, this is true. But enforcement is a complex judgement call, not a simple short-term value/risk evaluation. Do you shoot at the kid who steals a pack of gum from the 7-11 and runs? Probably not. But what about the guy who hijacks a 747? Complying with all of his demands is the only possible route if you take the normal value/risk assessment. But that will encourage future hijackings. So while taking out the hijacker puts the entire plane full of passengers at a high risk, not taking him out puts every passenger on every plane at an increased risk. If enforcement is only done when the immediate benefit outweighs the cost, criminals will simply find ways to make enforcement expensive, and then they will always get away. All a criminal has to do is put other people in danger and the cops will back off. The result is anarchy.
Cops have to consider more than just the situation at hand. Some crimes are always more trouble to prosecute than they are worth. But if they are never prosecuted then everybody can count on getting away with them, with the result that everybody will do it. If cops never chased guys who run off with small amounts of stolen gas in densely populated areas, then gas stations in densely populated areas would continually get ripped off.
Instead, cops do tend to chase people who drive off with stolen property. So when tempted with the idea of running off with stolen gas, the would-be criminal considers the possibility of a chase and the possible consequences of that, including the possibility of an accident and being responsible for the injury of a bystander. The rational man will determine that this risk isn't worth the $20 in gas, and will pay for the gas. The irrational man doesn't care about the consequences and will still run. And that is the kind of person who needs to be behind bars (the person who doesn't care about how his actions affect others).
The authorities decided to storm the compound. But the Davidians decided to hole up in a compound and defy the law and the law officers, as well as set the place on fire. The sniper decided to shoot at something. But Randy decided to fight the cops and he dragged his wife into the situation. In both cases, looking back (with knowledge of how things played out) we might see something that could have been done differently. But at the time, criminals had purposely put the cops in a tough spot and put innocents in the line of fire, and the cops were trying to make the best of a very bad situatuion.
Nope, I'm pretty sure XP (and Win2k) make use of Pentium-specific instructions.
A bit over-simplified, but one way of looking at it is whether the database engine runs in the same process as the application that uses the database.
A metaphor may be useful here. You could consider it the difference between grabbing a meal in your own kitchen or getting take-out. Making a meal in your own home doesn't really take any coordination from anybody, and you can just take care of it yourself -- you just have to have your own food and your own kitchen appliances. If you want to order out, you have to look up the restaurant's phone number, call, make an order, pick it up, and pay for it, but you don't have to have your own food or your own appliances.
In a standalone database, the database engine runs in the same process as the application (i.e. you eat in your own house). You "start" the database engine by running the app (the kitchen is only producing food when you want to eat). This is simpler because there is just one program to manage, the data storage acts just like any other file you want the application to open, and the database engine is just another module the application uses.
In a service (or client/server) architecture, the database runs as a separate process (the restaurant is a separate establishment). The database engine is one program that can start and stop by itself (the restaurant opens at 9:00am and closes at 10:00pm), and the application is another program that can start and stop independently. This is a bit more complicated because the application has to make sure the engine is running, connect to it, and authenticate to it.
The advantage of the standalone database is simplicity and efficiency in the single-user or single-computer scenario. If you only have one client accessing the database, there is no need for authentication, interprocess communication, locking, etc. The database is just another file to be opened, edited and closed.
If a standalone database is used by multiple clients at the same time, things start to break down (too many cooks in the kitchen at once). The advantage of the standalone database was the simplicity of having only one program to worry about, but if there are multiple clients, that is no longer the case. The different client programs now have to coordinate their access to the database. This is not necessarily hard to do, but it isn't very efficient or scalable. Your kitchen just isn't designed to allow 400 individuals to make their own meals every day. People are going to fight over who gets to use the oven next, somebody is invariably going to leave a mess and not clean it up, and you're probably going to run out of food (who ate my cheese?).
When there are many clients, it is better to just have one database engine servicing all of them, so you create a service that starts and stops independently of the clients. A single process is in charge of providing the data (i.e. a single establishment is dedicated to the task of providing food). This would be wasteful if only one person were to eat there each day, but it is much more efficient if many eat there every day.
Nope. int and long are still 32 bits, at least on MS platforms. long long is 64 bits. The only difference is with the pointers. Otherwise, you have to specifically request a 64-bit data size. This way, you can keep binary compatibility (struct layout) and avoid memory wastage for places where 64 bits aren't needed. But you get more address space, more registers, and faster 64-bit math (when needed).
I just saw some very simple CPU-bounded benchmarks that put the AMD64 2.0 GHz (on WinXP-64) at about 2X the dhrystones of a P4 2.0 GHz. Dhrystones are mostly meaningless, but they do show something.
Try Anandtech instead.
Y Y
| \
While with a properly centered keyboard, they look more like this:
Y Y
/ \
Obviously, you don't want any bend, but it is better to have the bend spread between the two wrists than to have the left wrist straight and the right wrist bent double.
There are some definite disadvantages of using a laptop. One example would be back problems -- posture is likely worse when using a laptop. A properly positioned desktop setup will be much better than the laptop for nearly all purposes. But the advantage is that the laptop is more flexible, so you can put it exactly where you want it. Most desktops are NOT set up properly, and once set up, the positioning is pretty rigid. The laptop setup is usually far worse, but when you start getting uncomfortable, you can change positions -- again, to a suboptimal position, but a DIFFERENT suboptimal position, so different muscles/tendons/nerves are being strained, allowing the other muscles/tendons/nerves a chance to relax a bit.
In other words, the desktop can be set up to be a better work environment than the laptop, but you have to know what you are doing in setting it up AND in using it -- natural instincts and "common knowledge" don't cut it. The desktop is rigid, so a poorly designed setup will remain poorly designed for years. When your body tells you that it is having trouble with the desktop's setup, your brain tells the body "I can't do anything about it, so be quiet," and the body shuts up until a serious problem develops.
The laptop is almost always a bad work environment, but natural instincts are able to prevent you from hurting yourself. Natural instincts are able to do their thing. It is flexible, so you can change the layout without even being consciously aware of the change you just made. When your body tells your brain that it doesn't like the laptop's positioning, your brain will have the hand give the laptop a nudge into a better position, and the body is happy. This happens many times per hour, without you even noticing. So no serious problems ever develop.
So if you compare the average Joe's desktop layout (i.e. Joe doesn't really know how to properly position the monitor, keyboard, and mouse) with the way the average Joe uses a laptop, I think the laptop is much less likely to cause trouble for Joe's wrists.
Ok, I honestly can't diagnose your situation. But in my experience, the mouse has made FAR MORE difference than the keyboard in causing me trouble. Try switching to a trackball or a trackpad. It takes a bit to get used to the trackball, and they definitely don't have the precision on a mouse (no FPS for you!), but for most purposes, they're perfectly adequate, and they generally put far less stress on the wrist.
I never had trouble with my wrists. Ok, occasionally my wrist would hurt from putting all of my weight on it, but that was a skin-deep problem, not a carpel-tunnel or tendonitis problem. Then I got a summer job using Visual Basic. VB takes mouse usage to new heights, and within 2 months I had serious problems. Fancy keyboards, special extra-large mice, wrist braces, etc. didn't help much. I learned to mouse with my left hand, and that helped since I could spread the stress out. Even after I left that job, I had problems with my right wrist.
Then as I was starting a new job and getting set up with my office equipment, I asked the hardware guy if he had anything that would help with wrist problems. He gave me a "Microsoft Trackball Optical" (some prefer the the "Microsoft Trackball Explorer", so try them both). To make a long story short, over the next 3 months I stopped needing my wrist brace, and over the past 2.5 years, I haven't had any serious trouble. I now have a mouse (any mouse) and a Trackball Optical hooked up to every desktop computer I own. Most of the time, I use the trackball. When I do something where the trackball doesn't work well, I use the mouse.
Looking back, I've done a little bit of research. It turns out that the Microsoft Intellimouse I was using back then has become famous for causing wrist trouble. When it was designed, they did customer studies to find out what shape people liked best, and people chose the old Microsoft Intellimouse as the most comfortable. That was fine for short-term use, but over long-term use, it turned out to be terrible. The hump at the back forced you to bend your wrist. Newer designs have removed this hump.
So don't necessarily blame the keyboard! Try a mouse alternative, or at least make sure your current mouse is well designed (if you are using an older Microsoft mouse, get it replaced immediately, and stomp on it before throwing it away so that it won't ever be able to hurt anyone ever again!).
In addition, get your workstation layout evaluated. Either study up on it yourself, or get somebody who knows about it to evaluate your office for you. Here are a few key points:
Start with the chair. Your feet should firmly reach the ground. You should sit up straight.
When sitting up straight, your eyes should be lined up with a point on the top half of your screen. If you tend to slouch (like I do), your eyes should line up with the top of the screen. If you tend to sit up straight, your eyes should line up with a point 1/3 of the way down the screen.
Your keyboard should be positioned so that when you are in standard typing posture, the part of the arm above the elbow is hanging straight down and the elbow makes a 90 degree bend so that they are parallel to the floor. This should allow you to type with NO VERTICAL BEND in your wrist. The keyboard should be positioned horizontally so that the "6" key lines up with the center of the monitor. Don't line up your keyboard's physical center with the monitor -- line it up so that home row is centered. If you have a split keyboard, this can allow you to type with no bending AT ALL in your wrist. If you have a normal keyboard, your wrists will have a slight bend to one side. That is bad, but acceptable. It isn't acceptable for one wrist to be bent more than the other. And it isn't acceptable for there to be ANY vertical bend.
The mouse needs to be placed so you can switch from keyboard to mouse without moving your elbow (which is directly beneath your shoulder, remember?). Unfortunately for right-handed people, that put
I think the biggest reason is style enforcement. The reasoning goes something like this:
1. Case distinction is room for additional information without increasing the length of the text.
2. For the additional information to actually be useful, people have to know what the case distinctions mean.
3. For people to know what the case distinctions mean, there have to be established conventions.
4. Conventions fall apart very quickly if there is no enforcement or verification.
5. It is useful to make the compiler perform some of the verification and/or enforcement -- you're much more likely to notice problems immediately if the problem is caught by the compiler rather than an optional LINT tool.
It is a lot like case sensitivity for English. It really isn't needed, but it sure helps you understand things a lot more easily. You can scan for the start of the next sentence much more quickly if the sentence starts with an uppercase letter and the rest are lowercase. In the same way, you can get a quick sense of what a variable is for by observing its casing, assuming that you are familiar with the casing convention in use.
English teachers force us to use proper spelling, grammar, casing, and punctuation so we can communicate more clearly. Computer language syntax works the same way. The parser/compiler could do a fine job with a much simpler language, and it doesn't really need to be that strict about syntax checking. ("Error: missing semicolon." If it knows there is a missing semicolon, why can't it just pretend the semicolon is there and go on?) The idea is that stricter syntax checking is useful to the original programmer (many syntax errors are also indicative of logic errors or ambiguity) and also to the maintainer who has to make sense out of the code.
So the bottom line is that following coding conventions makes your code more readable and your intent more clear. Case sensitivity is one way the compiler helps you maintain your coding conventions.
To make sure that I wasn't just blowing steam, I did a little bit of looking around, reading some research papers, etc. Here is what I came up with:
Anyway, that is what I came up with. I don't have all of the links, but a lot of them were within a few clicks of the so-called The Memory Management Reference website. I'm even more convinced than I was before.
However, I agree with you that everything has its place. There are places where GC still isn't appropriate. The GC tends to have a larger initial cost than malloc/free (in terms of both code and initial data requirements), so for very simple systems (embedded computers or bootstrappers for more complex systems) the GC just won't work -- there isn't enough room for a program complicated enough to allow the GC to be worth the initial cost. And while "real-time" GC does exist, it isn't yet good/fast enough to be used in the kernel where interrupt handling has to be done within very tight time constraints -- even though a standard GC implementation would likely have better performance (according to what I've read) than the
So lets see if we understand each other. You're saying:
1. Once a criminal, always a criminal.
2. Using monopoly positioning to maintain a monopoly makes a company into a criminal.
3. Managing to get off with a penalty less than what you think they deserve makes Microsoft the worst kind of criminal.
4. If a company is a criminal, that means that everybody else gets to do whatever they want at that company's expense.
Ok, I've got some problems with that. First, why isn't Lindows a criminal now? They have been convicted of abusing the settlement. Now don't get technical with all that nonsense about the class of law they have broken and the terms applied to the ones who have broken which... Oh, and have you ever gone faster than the posted speed limit? If so, I think you'd better give me all of your money, you scummy criminal you.
On a more rational note: please study law just a little bit before you go off about what everybody is guilty of. All business is cutthroat. All businesses are out there to make money. Certain actions are illegal. Certain actions are unfair. Certain actions are mean, wrong, uncivilized, etc. Monopoly hasn't been convicted of doing anything inherently illegal -- it has been decided in that some of its business practices are unfair, and that they are in violation of some contracts. There are laws that state that if a company is engaging in certain unfair practices, the US government has the power and/or obligation to step in and stop those practices and perhaps demand penalties and/or reparations. And there is nothing in the law that says companies can't be mean. They might scare away all of their customers or their partners, but otherwise companies can be as mean as they want as long as they aren't illegal or unfair.
As far as unfair goes, that is a pretty vague adjective, and to a large extent, the definition is unclear until a judge has decided on the case. Some things are definitely unfair, others are a little bit unfair. Well, guess what -- life just isn't fair. So to a certain extent, companies are expected to stick up for themselves and deal with other companies that treat them unfairly. Only when that doesn't work does the government step in, and then only with the smallest intervention that is expected to effectively level the playing field. It doesn't mean that once a company has been "convicted" of "monopoly" that they have to give in and do whatever anybody else wants. Neither does it mean that their competitors can now do whatever they want. It just means that they can't continue with specific practices that have been determined to be "unfair", and perhaps pay damages.
Microsoft is doing this. So the courts have determined that they are ok now. Guess what: you don't get to decide.
You can't have it both ways. Either you agree with the court or you don't. If you agree with the court, then Microsoft has been found to have engaged in unfair business conduct and has been appropriately sanctioned. If you don't agree with the court, then Microsoft has not been "convicted" of anything, since you don't accept the court's decision.
Agent Smith and I are happy to know you care.
I've heard that for years, it's yet to be true for the general case ... and most people doing manual allocation don't call malloc/free for every single grow/shrink operation. The caching slab allocator was put into solaris a long time ago now.
... why is that?
Caching slab, lookaside lists, whatever, you're still calling some kind of allocator with some kind of cost. There are definitely applications where memory allocation/deallocation follows a pattern that allows that kind of optimization to work well. But here is the crux of my argument: 1. the general purpose allocators definitely do have a non-zero cost; 2. special purpose allocators can be significantly faster, but they aren't general purpose, so they don't work in all situations, and they often require significant extra work to make them work properly; 3. special-purpose allocators usually work by speculatively pre-allocating chunks from the general purpose allocator, and this wastes memory; 4. even when you are using special-purpose allocators as much as possible, you still have to spend a lot of time in memory management -- the special-purpose allocator isn't free, and every once in a while it still has to call out to the general purpose allocator, which is expensive. So I stand by the original premise: after all is said and done, the time spent in memory management for a GC-based program isn't much (if any) greater than the time spent in memory management for an equivalient non-GC-based program. When the total cost of the allocations/deallocations is compared with the cost of a similar set of GC-alloc + collections, the difference for most big applications isn't really significant.
The keyword being all, yes you can sometimes just completely forget about designing how you use memory and everything "works". However sometimes those bits of memory have other resources associated with them.
Yep. And now you don't have to bother with those either, since the GC can collect them during finalization of their associated bits of memory. The point here is that while you still might have to write a destructor of some sort, it is usually much simpler (no memory to worry about) and you don't have to figure out when that resource is no longer in use -- the GC will figure it out for you. If the resource must be freed deterministically, GC doesn't prevent you from doing that. But in the cases where it doesn't, GC still works great. In other words: don't refuse the solution just because it only makes 90% of your problems go away -- you're still better off, aren't you?
You seem to be under the impression that running the GC isn't going to blow your cache
If the garbage collector itself causes additional page faults, then yes, it isn't an advantage. But the argument was that when compared with page faults (something we've all been willing to accept, something that hasn't caused an unacceptable performance hit), GC is small potatoes. In addition, modern GC implementations take the amount of memory available on the machine into account, and they actively work to keep memory usage under the level that would start causing page faults. The garbage collector can spring into action when a request is made that might result in a page fault, and the page fault only actually happens if there really aren't any objects to release. The GC can dynamically determine which objects are unreachable, while the non-GC program must rely on a static analysis that often means objects live longer than is truly necessary (the GC can free something anytime after the last reference is gone, while a non-GC program has to keep the object until it comes to a point in the control flow that is unreachable until the object is no longer needed). While the dynamic analysis has a runtime cost (the static analysis has no runtime cost), the additional information available at runtime can enable much more efficient memory management, which in turn can reduce page faults, which can off