In an intro course, a large portion of the mistakes people make will be syntax errors (failing to match braces, forgetting semicolons, misspelling keywords, forgetting method return types, and so forth). Any editor with Java-specific syntax highlighting and automatic indentation will make these mistakes clear to the programmer. Generally, for new programmers doing suitable assignments in a high-level language, the student's intended program will be completely correct, and the frustrating debugging time will be spent trying to get the compiler and the programmer to agree on what the program actually is. It's only further along that students have programs that are what they intended, but are still buggy, where an IDE with semantic and runtime features will help them.
It seems like that would be an easy thing for a developer to fix (by adding an option for it to the existing configurations). I suspect that, if you were to subscribe to dev@sc.openoffice.org and ask for the feature, somebody would probably just write it for you because it's generally pleasing to get a patch in with very little work.
It's worth mentioning that Apollo-level funding was gotten for Apollo itself by exactly the same heated rhetoric that gets wars funded. The point of Apollo was to get to the moon before the Soviets got there and thereby... er, weapons of mass destruction! National security!
Considering that there hasn't been a factual basis for the rhetoric involved in getting massive war funding in the US since WWII, there's no reason that some good speechwriter couldn't make the case that returning to the moon is vital to defeating terrorism, and get that level of funding.
I'm sure Tove could trivially kick the butt of anyone Tanenbaum could get for the microkernel position. It would therefore hardly be a fair test of the merits of the respective positions.
I don't think PPC is different from x86 this way, but on HP Unix machines (don't remember the CPU), the stack grew the opposite direction. This meant that stack buffer overflows of buffers declared last in their functions (which is pretty common) would overflow directly into unused stack space, rather than into the stack frame's return address. So the attacker's data would go into an area that had undefined data anyway. I've had the exact same source code (with a buffer declared too small) overwrite a local variable on Linux, while it caused part of the buffer to be clobbered by a function call on HP/UX.
The OS is limited in its choice of stack direction by the opcodes the processor has for push and pop, and the way it handles the stack when taking an interrupt (as well as calling conventions that libraries expect to use).
I don't think PPC is less safe than x86 in this way, and I doubt OS X is full of flaws that aren't exploitable on the original architecture, but it's not completely irrelevant.
The Great Depression was clearly enormously more significant and widespread. But I don't think that the article's actual claim, that the Dot-Com Bust's effect on policy decisions of one group is similar to the Great Depression's effect of policy decisions of a different group, is wrong. The human cost of the fallout from bad policies is a completely separate matter from how people change in response to it. It's fair to say that Hurricane Katrina and the mine disaster in West Virginia had similar effects on people's concern about disaster preparedness in the relevant areas, even though the human costs of the two disasters were orders of magnitude different.
You get hydrogen from fossil fuels, but the process can be done more carefully, so you don't get any carbon monoxide, and the carbon dioxide doesn't have to be released. The issues with the process are getting the fossil fuel in the first place, and trace sulfur in the fuel, which becomes hydrogen sulfide, which is nasty corrosive poisonous stuff.
Of course, this is only true while fossil fuels are plentiful. If it becomes expensive to get fossil fuel, it becomes cost-effective to generate hydrogen from electricity generated by other means; it is relatively very difficult to synthesize gasoline from electricity and available substances. Furthermore, the main reason that the midwest doesn't generate a huge amount of energy from wind is that electricity transmission from there to large users is too inefficient. A ton of hydrogen could be produced there with minimal environmental impact if there were a market for it.
The value of hydrogen is that makes energy usage modular, so it's possible to use the best generation method for powering everything and to switch generation methods freely; and it is highly efficient as a long-distance bulk transmission method, allowing generation in low-usage areas to be efficient.
The problem with that is that most of your accesses are going to be to data cached in memory, which can be handled immediately (or, at least, as fast as the context switches). In order to be efficient, you need to be able to handle multiple of these calls concurrently, if they don't conflict, on different processors.
What you can do is have the kernel handle the non-driver-specific stuff (i.e., cached directory structure and cached file data), since that's essentially a generic facility like allocating physical memory to address spaces. The driver only gets called for stuff that's specific to the filesystem, which is going to require disk access (which is slow and serial) anyway. The generic facility doesn't get protection from other internal generic facilities, but it's relatively small and doesn't have many special cases, so it gets tested effectively.
Of course, such a design is already available, in Linux, with FUSE. So Linus evidently didn't argue against it effective, if at all...
(Of course, some things are still tricky; how do you deal with drivers in userspace which may need to allocate memory in order to handle writes, when the writes may be triggered because data has to be written out to free up dirty buffers, and the memory management system has no clue how much memory the driver could need?)
For example, you could make a message be more like a procedure call - you create a new stack, swap your address table around, and then jump into the function in the "server".
Better make that: you swap your address table around, create a new stack, and then jump into the function in the "server". Otherwise your new stack isn't in your address space, while is going to be a problem. In any case, a bunch of the work of creating a new thread is creating an additional stack in an address space that already has stuff in it. You have to make sure that the address range you're going to use for it isn't in use as a stack already, and isn't being concurrently allocated as a stack on a different processor, which requires the microkernel to do a bit of clever locking.
Then, of course, you're writing a filesystem driver which is concurrently handling multiple requests that may involve the same data structures, so you need all the same fancy locking that a monolithic kernel would need.
Fundamentally, if you care about scalability, you need locking for managing your resources, regardless of whether you have a microkernel or a monolithic one, because the on-disk data structures are a shared resource. If you one a microkernel, you additionally have the driver's address space as a shared resource that needs to be managed (and this could have a lot of contention if, for example, you have a lot of processes simultaneously opening different files in the same filesystem, where all of the data is already cached in memory). With this, you reduce the chance that code outside of your driver but inside the kernel could write to your driver's address space, which isn't, in practice, a common occurance, because other code generally won't have pointers that go there.
ODF doesn't have support for interacting with documents, either with a GUI for people with no special requirements or any special interaction pattern. It only specifies what's in the document, not what you can do with it.
Now ODF does lack support for audio documents, such as voicemails or podcasts, but I don't know of any office software that supports this. Generally, even blind people tend to want to produce documents consisting of text that sighted people can read, instead of only being audio. On the other hand, it should be possible to write documents in Braille, because Unicode has characters for it.
From the article, companies that make applications that support ODF have been putting a lot of effort into accessibility. It's hard to say whether they should be considered to have been dragged into it; they didn't put as much emphasis on it until it came up as an issue with adoption in MA, but before that they didn't have enough user interest to find out what was needed.
Considering that most of the sites that people want to connect to want net neutrality, the obvious thing is for Google, MSN, and all their friends to rate limit their responses to requests from customers of net neutrality opponents to dialup speeds and mention this fact on their pages. Charging sites to provide a fast connection to them only works if there's someone who's willing to pay. Especially if it's small network providers who are trying this scam, it would be easy for proponents of net neutrality to just wipe them out.
I don't get why companies in favor of government intervention don't generally act in ways that would be prohibited by the legislation they support, in order to demonstrate the need for it.
Any critical vulnerability fixed in 2.6.16 should also be fixed in the -stable series for 2.6.15, because they keep releasing patches to the previous version for a while after the new one comes out. If you mean that 2.6.16.x fixed a critical vulnerability after they stopped 2.6.15.x, and they hadn't figured out the bug that nobody seems to have reported to the list, -stable patches generally apply (except for the part that sets the version) to a wide variety of kernels. Chances are that you can make a 2.6.15.8 that fixes the vulnerability without breaking the network cards (and LVM2) just by applying the 2.6.16-stable patches to 2.6.15.7.
The issue with a microkernel is what happens if a bug in your filesystem driver means that an attacker can cause it to report that/bin/sh is setuid root (as a special case of executing arbitrary code). Sure, the attacker can't screw up everything at once, but that doesn't matter too much. Most subsystems will have the ability to produce output that would compromise system security, so it's like a tightly compartmentalized ship whose bulkhead controls open the doors if they get submerged.
This is actually sort of happening. Recent work has increased the number of features that can be provided in userspace. Of course, this is done very differently from how a traditional microkernel does it; the kernel is providing virtual features, which can be implemented in user space. For example, the kernel has the "virtual file system", which handles all of the system calls, to the point where a call to the actual filesystem is needed (if the cache, which the VFS handles, is not sufficient). The actual calls may be made to userspace, which is a bit slow, but it doesn't matter, because it's going to wait for disk access anyway.
The current state is that Linux is essentially coming around to a microkernel view, but not the classic microkernel approach. And the new idea is not one that could easily grow out of a classic microkernel, but one that grows naturally out of having a macrokernel but wanting to push bug-prone code out of it.
Not that I know of; I think there isn't enough demand for one-way trips to make it worth the logistics. And they'd have to have somewhere to put cars that end up in spaces other than the ones they came from. Zipcar doesn't have depots, exactly. They rent and reserve a space in a garage or parking lot for each car, and there's nothing in the area aside from a sign and (if it's not in use) the car. So they'd need to have extra spaces, and have a system for reserving the ability to leave cars in them, as well as supporting people reserving cars from places they aren't usually, and bringing cars back where they came from.
Actually, renting a car is probably simpler than pumping gas. Complicated things can happen with a rented car, but they don't happen when you're at the agency, so there's no way that there's going to be a customer service person handy (when a Hertz car breaks down on the highway, you don't pull the Hertz guy out of the trunk and ask him what to do...).
Zipcar deals with that sort of stuff the same as anyone renting cars to people, and they deal with major repairs the same way as anyone else, too; you're required to report problems the car is having, and they fix them when nobody is renting the car. They also move the cars around themselves to put them in useful places. The customer is responsible for parking the car where it came from, but the space is reserved anyway, so that isn't difficult.
The deal with gas in a similar way to normal rental companies, except that you don't have to game the system and get the tank slightly over half full to minimize your cost; they just pay for the gas and cover it in the price, and they require you to leave it with 1/4 tank (unless, I assume, you're driving the all-electric SUV, which you just park back on the charger).
Renting a car really is a completely trivial transaction compared to buying groceries, which are a large number of small cheap items that can't be heavily instrumented. It's even easier than pumping gas, since they have you get a membership beforehand and they don't have to deal with cash or charging cards at the pump. Keeping the rental business running smoothly isn't automatic or possible to do well self-serve, but that's also all behind the scenes.
I suspect you don't really want Google to index your ads or pop-up definitions, and I think it doesn't ignore content with visibility "hidden", so this code should work the way you'd like.
Electric motors have much higher torque at low speeds than gas motors. If your electric motor is powerful enough to get your car to highway speeds, its acceleration coming from a stop is going to dwarf a gas sports car's. In fact, electric vehicle designers generally have to limit the car's acceleration, because, unless you've got racing car tires (like this one seems to), you don't have enough traction for the torque.
A much bigger challenge for an electric versus gas would be 60-90, highest top speed, or a drag race long enough to max out the cars' speeds. 0-60 is the standard test primarily because it's what gas cars are worst at, so you can compare them without a lot of tricky driving.
If the business switches to ODF, there's relatively little they can do with MS Office that they can't do with OpenOffice, if they want to be able to have it persist when they save and load their files. And businesses can save money by having everybody who doesn't care or prefers OO use that, while only users who insist on MS Office get it.
Personally, I think OpenOffice is a terrible piece of software, and is only surpassed in sucking by everything Microsoft makes except for Visio. The reason I want ODF to catch on is so that you can use the tool appropriate to what you're doing, rather than having to struggle manually with some office program. You want to know the exact color used in a drawing in an office file? If it's in ODF, you can unzip it, and search the XML for "color", and you find it.
Maybe non-technical users aren't going to be capable of doing stuff by hand on ODF files, but they can still use programs created by more technical users who aren't intimidated by ODF, but who aren't quite up to writing a GUI office software plug-in. ODF is a huge win for anyone who wants to do automated document manipulation.
They then said they weren't going to sabotage it, and that they were only on that committee because they were going to push for acceptance of their format. A number of ODF-related organizations had representatives on the committee, and it's common for interested organizations to be members, because they can actually explain the reasoning behind the specification.
Of course, it's hard to say whether the MS rep would be caused problems if the potential hadn't been pointed out, and MS hadn't been forced to promise good behavior.
For that matter, the ODF reps will presumably sabotage MS's submission, just like they accused MS of trying to do. But, of course, they're supposed to stop the group from endorsing standards that are worse than other standards.
All of the affected versions are masked for testing under Gentoo, so chances are that you're not using an affected version anyway. In any case, it's evidently trivial for a local user starting an xserver to cause it to execute arbitrary code, but there's no way to attack a running server locally or remotely.
I think the issue is mostly how people use email in collaboration situations, not the actual technology. This fact pretty much dooms other technologies to be no better; even people using the ideal collaboration software can (and will) sometimes send a personal email instead of using the tool.
The solution is to train people in using the tool. On the linux-kernel mailing list, the policy is that you cc the list on any reply to a message on a list, and cc all recipients. If you violate this rule, people complain. This means that the whole discussion is archived and publicly searchable. It also means that everybody participating in the discussion gets a copy addressed to them of each message, and doesn't have to try to find messages that are part of the discussion in the huge volume of mailing list traffic.
The whole point of the exercise is for thousands of people to edit a huge document (the kernel source) at the same time, and most of the changes go through email to the list, too. Here, the policy is to cc anyone who is likely interested (like the appropriate maintainer, if you want the change to actually stick).
Of course, this requires people to set up their email appropriately; you ideally want to get your direct copies of messages in your inbox and all of the mailing list mail filtered out. But anyone on linux-kernel pretty much has to have their email set up cleverly, because the traffic is too high to deal with directly (I think the non-spam on there is higher traffic than most people's spam before filtering).
About the only thing that would make it better would be if there was a URI scheme for message IDs, supported both by mail readers (which would take you to the message in that folder) and web browsers (which would take you to an online list archive you've chosen). Currently, it's a bit awkward to refer someone to an old message; what people do is use the URL for their favorite web archive, but that isn't convenient for responding by quoting portions of it, or if the recipient happens to hate the sender's favorite archive, or if recipients want to know if they've received it before.
Of course, they're also a lot of hidden stuff: source code is a whole lot easier to do concurrent modifications on than office documents, because of tools like diff and patch and the use of filesystem structure within the document, as well as the compiler's support in cross-referencing things. So the collaborative editing task is a whole lot easier than word processing, which is stuck in the early 70s.
I'm not sure if you're complaining about development of the language and standard library API, or development of Sun's implementation. The language evolves about as fast as is prudent, because they're committed to having the language not have badly-designed features that need to either be incompatibly dropped or painfully maintained. So Java gets features essentially as soon as C++ has made all the mistakes related to those features.
On the other hand, Sun's Java compiler has always had broken dependancy tracking (at least since I started using it heavily in 1999). (If a build has an error, the set of output class files may be such that the next run of the compiler skips a source file which needs to be compiled; this is mainly that it can generate the public class without generating other classes in the same file.) I think it's likely that, if Sun does open source the JDK, they'll get fixes for a number of annoying flaws of that sort pretty quickly, and things that are clearly wrong but aren't considered worth working on will be improved substantially.
Of course, there's essentially no chance that they'll relax their grip on the language standard, and they probably shouldn't, unless they turn it over to a standards body due to no longer being able to employ good language designers.
The study showed that people were more likely to change their opinions in response to an essay when they'd had caffeine than a placebo. It doesn't say how that validated their explanation, but the first reason they gave was scientific jargon for "the people on caffeine actually read the essay", and the second reason was that they were happier.
I haven't seen the original study, but these things are often done with a survey of opinions on a topic, with a bunch of gradations from "completely agree" to "completely disagree". Of course, there are a number of confounding factors here. It could easily be that people who get their caffeine pay more attention to the essay and are more willing to mark down less strong opinions than they actually hold to please the authors of essays.
To get some idea about persuasion, you need a follow-up study to see whether people's opinions are still affected after the drug has worn off.
Of course, 11 years ago, my Latin teacher was dosing her students with caffeine at the start of class, and I can still come up with "O Colonia quae cupis ponte ludere longo", while I reread most of "The Turn of the Screw" since that year before I remembered that I'd read it before.
Actually, if the nasty things pop up when you're most freaked out, you'd probably just waste them, because you're primed to twitch. It would be a lot more effective if nasty things popped out when you relaxed, and innocuous environmental effects happened when you were freaked out.
If you think about it as the game trying to maximize the ammo you use relative to the number of monsters it uses, and it gets to sneak a look at the snap decision you're going to make next, the obvious thing is to have nothing there if you're going to shoot and a monster there if you're not.
For that matter, imagine playing through a ten-minute sequence where it's actually impossible unless you're on the edge of your seat and shaking, because the game throws in enough stuff to kill you otherwise. Going through it, you'd obviously be totally terrified, at least if you didn't get frustrated instead.
Or imagine a sequence where some impossible nasty is chasing you, and you have to both go really quickly and accurately through the map, and also stay hypervigilant, becasue the moment the game detects that you've relaxed at all, even if you're playing perfectly otherwise, it catches up. It would be like actually being in a nightmare or horror movie, rather than just having a nightmare or horror movie setting where you aren't the main character.
Slashdot Mirror
In an intro course, a large portion of the mistakes people make will be syntax errors (failing to match braces, forgetting semicolons, misspelling keywords, forgetting method return types, and so forth). Any editor with Java-specific syntax highlighting and automatic indentation will make these mistakes clear to the programmer. Generally, for new programmers doing suitable assignments in a high-level language, the student's intended program will be completely correct, and the frustrating debugging time will be spent trying to get the compiler and the programmer to agree on what the program actually is. It's only further along that students have programs that are what they intended, but are still buggy, where an IDE with semantic and runtime features will help them.
It seems like that would be an easy thing for a developer to fix (by adding an option for it to the existing configurations). I suspect that, if you were to subscribe to dev@sc.openoffice.org and ask for the feature, somebody would probably just write it for you because it's generally pleasing to get a patch in with very little work.
It's worth mentioning that Apollo-level funding was gotten for Apollo itself by exactly the same heated rhetoric that gets wars funded. The point of Apollo was to get to the moon before the Soviets got there and thereby... er, weapons of mass destruction! National security!
Considering that there hasn't been a factual basis for the rhetoric involved in getting massive war funding in the US since WWII, there's no reason that some good speechwriter couldn't make the case that returning to the moon is vital to defeating terrorism, and get that level of funding.
I'm sure Tove could trivially kick the butt of anyone Tanenbaum could get for the microkernel position. It would therefore hardly be a fair test of the merits of the respective positions.
I don't think PPC is different from x86 this way, but on HP Unix machines (don't remember the CPU), the stack grew the opposite direction. This meant that stack buffer overflows of buffers declared last in their functions (which is pretty common) would overflow directly into unused stack space, rather than into the stack frame's return address. So the attacker's data would go into an area that had undefined data anyway. I've had the exact same source code (with a buffer declared too small) overwrite a local variable on Linux, while it caused part of the buffer to be clobbered by a function call on HP/UX.
The OS is limited in its choice of stack direction by the opcodes the processor has for push and pop, and the way it handles the stack when taking an interrupt (as well as calling conventions that libraries expect to use).
I don't think PPC is less safe than x86 in this way, and I doubt OS X is full of flaws that aren't exploitable on the original architecture, but it's not completely irrelevant.
The Great Depression was clearly enormously more significant and widespread. But I don't think that the article's actual claim, that the Dot-Com Bust's effect on policy decisions of one group is similar to the Great Depression's effect of policy decisions of a different group, is wrong. The human cost of the fallout from bad policies is a completely separate matter from how people change in response to it. It's fair to say that Hurricane Katrina and the mine disaster in West Virginia had similar effects on people's concern about disaster preparedness in the relevant areas, even though the human costs of the two disasters were orders of magnitude different.
You get hydrogen from fossil fuels, but the process can be done more carefully, so you don't get any carbon monoxide, and the carbon dioxide doesn't have to be released. The issues with the process are getting the fossil fuel in the first place, and trace sulfur in the fuel, which becomes hydrogen sulfide, which is nasty corrosive poisonous stuff.
Of course, this is only true while fossil fuels are plentiful. If it becomes expensive to get fossil fuel, it becomes cost-effective to generate hydrogen from electricity generated by other means; it is relatively very difficult to synthesize gasoline from electricity and available substances. Furthermore, the main reason that the midwest doesn't generate a huge amount of energy from wind is that electricity transmission from there to large users is too inefficient. A ton of hydrogen could be produced there with minimal environmental impact if there were a market for it.
The value of hydrogen is that makes energy usage modular, so it's possible to use the best generation method for powering everything and to switch generation methods freely; and it is highly efficient as a long-distance bulk transmission method, allowing generation in low-usage areas to be efficient.
The problem with that is that most of your accesses are going to be to data cached in memory, which can be handled immediately (or, at least, as fast as the context switches). In order to be efficient, you need to be able to handle multiple of these calls concurrently, if they don't conflict, on different processors.
What you can do is have the kernel handle the non-driver-specific stuff (i.e., cached directory structure and cached file data), since that's essentially a generic facility like allocating physical memory to address spaces. The driver only gets called for stuff that's specific to the filesystem, which is going to require disk access (which is slow and serial) anyway. The generic facility doesn't get protection from other internal generic facilities, but it's relatively small and doesn't have many special cases, so it gets tested effectively.
Of course, such a design is already available, in Linux, with FUSE. So Linus evidently didn't argue against it effective, if at all...
(Of course, some things are still tricky; how do you deal with drivers in userspace which may need to allocate memory in order to handle writes, when the writes may be triggered because data has to be written out to free up dirty buffers, and the memory management system has no clue how much memory the driver could need?)
Better make that: you swap your address table around, create a new stack, and then jump into the function in the "server". Otherwise your new stack isn't in your address space, while is going to be a problem. In any case, a bunch of the work of creating a new thread is creating an additional stack in an address space that already has stuff in it. You have to make sure that the address range you're going to use for it isn't in use as a stack already, and isn't being concurrently allocated as a stack on a different processor, which requires the microkernel to do a bit of clever locking.
Then, of course, you're writing a filesystem driver which is concurrently handling multiple requests that may involve the same data structures, so you need all the same fancy locking that a monolithic kernel would need.
Fundamentally, if you care about scalability, you need locking for managing your resources, regardless of whether you have a microkernel or a monolithic one, because the on-disk data structures are a shared resource. If you one a microkernel, you additionally have the driver's address space as a shared resource that needs to be managed (and this could have a lot of contention if, for example, you have a lot of processes simultaneously opening different files in the same filesystem, where all of the data is already cached in memory). With this, you reduce the chance that code outside of your driver but inside the kernel could write to your driver's address space, which isn't, in practice, a common occurance, because other code generally won't have pointers that go there.
ODF doesn't have support for interacting with documents, either with a GUI for people with no special requirements or any special interaction pattern. It only specifies what's in the document, not what you can do with it.
Now ODF does lack support for audio documents, such as voicemails or podcasts, but I don't know of any office software that supports this. Generally, even blind people tend to want to produce documents consisting of text that sighted people can read, instead of only being audio. On the other hand, it should be possible to write documents in Braille, because Unicode has characters for it.
From the article, companies that make applications that support ODF have been putting a lot of effort into accessibility. It's hard to say whether they should be considered to have been dragged into it; they didn't put as much emphasis on it until it came up as an issue with adoption in MA, but before that they didn't have enough user interest to find out what was needed.
Considering that most of the sites that people want to connect to want net neutrality, the obvious thing is for Google, MSN, and all their friends to rate limit their responses to requests from customers of net neutrality opponents to dialup speeds and mention this fact on their pages. Charging sites to provide a fast connection to them only works if there's someone who's willing to pay. Especially if it's small network providers who are trying this scam, it would be easy for proponents of net neutrality to just wipe them out.
I don't get why companies in favor of government intervention don't generally act in ways that would be prohibited by the legislation they support, in order to demonstrate the need for it.
Any critical vulnerability fixed in 2.6.16 should also be fixed in the -stable series for 2.6.15, because they keep releasing patches to the previous version for a while after the new one comes out. If you mean that 2.6.16.x fixed a critical vulnerability after they stopped 2.6.15.x, and they hadn't figured out the bug that nobody seems to have reported to the list, -stable patches generally apply (except for the part that sets the version) to a wide variety of kernels. Chances are that you can make a 2.6.15.8 that fixes the vulnerability without breaking the network cards (and LVM2) just by applying the 2.6.16-stable patches to 2.6.15.7.
The issue with a microkernel is what happens if a bug in your filesystem driver means that an attacker can cause it to report that /bin/sh is setuid root (as a special case of executing arbitrary code). Sure, the attacker can't screw up everything at once, but that doesn't matter too much. Most subsystems will have the ability to produce output that would compromise system security, so it's like a tightly compartmentalized ship whose bulkhead controls open the doors if they get submerged.
This is actually sort of happening. Recent work has increased the number of features that can be provided in userspace. Of course, this is done very differently from how a traditional microkernel does it; the kernel is providing virtual features, which can be implemented in user space. For example, the kernel has the "virtual file system", which handles all of the system calls, to the point where a call to the actual filesystem is needed (if the cache, which the VFS handles, is not sufficient). The actual calls may be made to userspace, which is a bit slow, but it doesn't matter, because it's going to wait for disk access anyway.
The current state is that Linux is essentially coming around to a microkernel view, but not the classic microkernel approach. And the new idea is not one that could easily grow out of a classic microkernel, but one that grows naturally out of having a macrokernel but wanting to push bug-prone code out of it.
Not that I know of; I think there isn't enough demand for one-way trips to make it worth the logistics. And they'd have to have somewhere to put cars that end up in spaces other than the ones they came from. Zipcar doesn't have depots, exactly. They rent and reserve a space in a garage or parking lot for each car, and there's nothing in the area aside from a sign and (if it's not in use) the car. So they'd need to have extra spaces, and have a system for reserving the ability to leave cars in them, as well as supporting people reserving cars from places they aren't usually, and bringing cars back where they came from.
Actually, renting a car is probably simpler than pumping gas. Complicated things can happen with a rented car, but they don't happen when you're at the agency, so there's no way that there's going to be a customer service person handy (when a Hertz car breaks down on the highway, you don't pull the Hertz guy out of the trunk and ask him what to do...).
Zipcar deals with that sort of stuff the same as anyone renting cars to people, and they deal with major repairs the same way as anyone else, too; you're required to report problems the car is having, and they fix them when nobody is renting the car. They also move the cars around themselves to put them in useful places. The customer is responsible for parking the car where it came from, but the space is reserved anyway, so that isn't difficult.
The deal with gas in a similar way to normal rental companies, except that you don't have to game the system and get the tank slightly over half full to minimize your cost; they just pay for the gas and cover it in the price, and they require you to leave it with 1/4 tank (unless, I assume, you're driving the all-electric SUV, which you just park back on the charger).
Renting a car really is a completely trivial transaction compared to buying groceries, which are a large number of small cheap items that can't be heavily instrumented. It's even easier than pumping gas, since they have you get a membership beforehand and they don't have to deal with cash or charging cards at the pump. Keeping the rental business running smoothly isn't automatic or possible to do well self-serve, but that's also all behind the scenes.
I suspect you don't really want Google to index your ads or pop-up definitions, and I think it doesn't ignore content with visibility "hidden", so this code should work the way you'd like.
Electric motors have much higher torque at low speeds than gas motors. If your electric motor is powerful enough to get your car to highway speeds, its acceleration coming from a stop is going to dwarf a gas sports car's. In fact, electric vehicle designers generally have to limit the car's acceleration, because, unless you've got racing car tires (like this one seems to), you don't have enough traction for the torque.
A much bigger challenge for an electric versus gas would be 60-90, highest top speed, or a drag race long enough to max out the cars' speeds. 0-60 is the standard test primarily because it's what gas cars are worst at, so you can compare them without a lot of tricky driving.
If the business switches to ODF, there's relatively little they can do with MS Office that they can't do with OpenOffice, if they want to be able to have it persist when they save and load their files. And businesses can save money by having everybody who doesn't care or prefers OO use that, while only users who insist on MS Office get it.
Personally, I think OpenOffice is a terrible piece of software, and is only surpassed in sucking by everything Microsoft makes except for Visio. The reason I want ODF to catch on is so that you can use the tool appropriate to what you're doing, rather than having to struggle manually with some office program. You want to know the exact color used in a drawing in an office file? If it's in ODF, you can unzip it, and search the XML for "color", and you find it.
Maybe non-technical users aren't going to be capable of doing stuff by hand on ODF files, but they can still use programs created by more technical users who aren't intimidated by ODF, but who aren't quite up to writing a GUI office software plug-in. ODF is a huge win for anyone who wants to do automated document manipulation.
They then said they weren't going to sabotage it, and that they were only on that committee because they were going to push for acceptance of their format. A number of ODF-related organizations had representatives on the committee, and it's common for interested organizations to be members, because they can actually explain the reasoning behind the specification.
Of course, it's hard to say whether the MS rep would be caused problems if the potential hadn't been pointed out, and MS hadn't been forced to promise good behavior.
For that matter, the ODF reps will presumably sabotage MS's submission, just like they accused MS of trying to do. But, of course, they're supposed to stop the group from endorsing standards that are worse than other standards.
All of the affected versions are masked for testing under Gentoo, so chances are that you're not using an affected version anyway. In any case, it's evidently trivial for a local user starting an xserver to cause it to execute arbitrary code, but there's no way to attack a running server locally or remotely.
I think the issue is mostly how people use email in collaboration situations, not the actual technology. This fact pretty much dooms other technologies to be no better; even people using the ideal collaboration software can (and will) sometimes send a personal email instead of using the tool.
The solution is to train people in using the tool. On the linux-kernel mailing list, the policy is that you cc the list on any reply to a message on a list, and cc all recipients. If you violate this rule, people complain. This means that the whole discussion is archived and publicly searchable. It also means that everybody participating in the discussion gets a copy addressed to them of each message, and doesn't have to try to find messages that are part of the discussion in the huge volume of mailing list traffic.
The whole point of the exercise is for thousands of people to edit a huge document (the kernel source) at the same time, and most of the changes go through email to the list, too. Here, the policy is to cc anyone who is likely interested (like the appropriate maintainer, if you want the change to actually stick).
Of course, this requires people to set up their email appropriately; you ideally want to get your direct copies of messages in your inbox and all of the mailing list mail filtered out. But anyone on linux-kernel pretty much has to have their email set up cleverly, because the traffic is too high to deal with directly (I think the non-spam on there is higher traffic than most people's spam before filtering).
About the only thing that would make it better would be if there was a URI scheme for message IDs, supported both by mail readers (which would take you to the message in that folder) and web browsers (which would take you to an online list archive you've chosen). Currently, it's a bit awkward to refer someone to an old message; what people do is use the URL for their favorite web archive, but that isn't convenient for responding by quoting portions of it, or if the recipient happens to hate the sender's favorite archive, or if recipients want to know if they've received it before.
Of course, they're also a lot of hidden stuff: source code is a whole lot easier to do concurrent modifications on than office documents, because of tools like diff and patch and the use of filesystem structure within the document, as well as the compiler's support in cross-referencing things. So the collaborative editing task is a whole lot easier than word processing, which is stuck in the early 70s.
I'm not sure if you're complaining about development of the language and standard library API, or development of Sun's implementation. The language evolves about as fast as is prudent, because they're committed to having the language not have badly-designed features that need to either be incompatibly dropped or painfully maintained. So Java gets features essentially as soon as C++ has made all the mistakes related to those features.
On the other hand, Sun's Java compiler has always had broken dependancy tracking (at least since I started using it heavily in 1999). (If a build has an error, the set of output class files may be such that the next run of the compiler skips a source file which needs to be compiled; this is mainly that it can generate the public class without generating other classes in the same file.) I think it's likely that, if Sun does open source the JDK, they'll get fixes for a number of annoying flaws of that sort pretty quickly, and things that are clearly wrong but aren't considered worth working on will be improved substantially.
Of course, there's essentially no chance that they'll relax their grip on the language standard, and they probably shouldn't, unless they turn it over to a standards body due to no longer being able to employ good language designers.
The study showed that people were more likely to change their opinions in response to an essay when they'd had caffeine than a placebo. It doesn't say how that validated their explanation, but the first reason they gave was scientific jargon for "the people on caffeine actually read the essay", and the second reason was that they were happier.
I haven't seen the original study, but these things are often done with a survey of opinions on a topic, with a bunch of gradations from "completely agree" to "completely disagree". Of course, there are a number of confounding factors here. It could easily be that people who get their caffeine pay more attention to the essay and are more willing to mark down less strong opinions than they actually hold to please the authors of essays.
To get some idea about persuasion, you need a follow-up study to see whether people's opinions are still affected after the drug has worn off.
Of course, 11 years ago, my Latin teacher was dosing her students with caffeine at the start of class, and I can still come up with "O Colonia quae cupis ponte ludere longo", while I reread most of "The Turn of the Screw" since that year before I remembered that I'd read it before.
Actually, if the nasty things pop up when you're most freaked out, you'd probably just waste them, because you're primed to twitch. It would be a lot more effective if nasty things popped out when you relaxed, and innocuous environmental effects happened when you were freaked out.
If you think about it as the game trying to maximize the ammo you use relative to the number of monsters it uses, and it gets to sneak a look at the snap decision you're going to make next, the obvious thing is to have nothing there if you're going to shoot and a monster there if you're not.
For that matter, imagine playing through a ten-minute sequence where it's actually impossible unless you're on the edge of your seat and shaking, because the game throws in enough stuff to kill you otherwise. Going through it, you'd obviously be totally terrified, at least if you didn't get frustrated instead.
Or imagine a sequence where some impossible nasty is chasing you, and you have to both go really quickly and accurately through the map, and also stay hypervigilant, becasue the moment the game detects that you've relaxed at all, even if you're playing perfectly otherwise, it catches up. It would be like actually being in a nightmare or horror movie, rather than just having a nightmare or horror movie setting where you aren't the main character.