Let me know when society gives me a guaranteed income, and I'll write open source code and all the bruhaha that comes along with it.
I write open source software for entertainment, and it sure beats watching TV. It happens to be good for my career as well (yes, really) but that's not why I do it. It turns out that direct monetarization is not the only way to benefit, and in fact I derive far more benefit by not charging since if I charged, next to nobody would use it and I'd get far less out of the other ways to gain; network effects are important...
Everyone I know who visits the USA these days tells me what a pain in the ass it is to travel here now.
It depends on where you enter. JFK is truly terrible - only one immigration officer for hundreds of non-residents arriving on a flight - DTW is much better as are SFO, SEA and MEM, and I've not been through ATL, MSP or ORD for a few years and so don't remember there too well (but leaving ORD was a pain due to insufficient post-security facilities, and probably still is). BOS and IAD are rather chaotic, but not too bad. I've never entered through LAX and so can't comment on them (but it's not a good place to change planes anyway). There are other US hubs, but I've not been through those at all (not even Domestic).
Re:And yet they do nothing to discourage the car
on
The Fresca Rebellion
·
· Score: 1
Having vehicles on the road traveling much slower than the flow of traffic is a hazard. That's why it's actually illegal in some states to drive slower than 40 mph on the highway absent some emergency.
That's also why it's reasonable for it to be illegal for cyclists (or slow farm vehicles) to be on the freeway.
And yet there's plenty of other roads, and drivers should on seeing a cyclist take care to not hit them. A considerate (and safety-minded) cyclist will seek to ride close to the verge of the road so as to allow other vehicles to pass. But if everyone just insists on their rights all the time instead of taking a tiny amount of effort to be nice to other users, then every journey will be a trial punctuated by near-accidents. IMO roads are way too dangerous for that approach.
Re:And yet they do nothing to discourage the car
on
The Fresca Rebellion
·
· Score: 1
Ever seen earodynamic bikes on the road? Beside SUV'? It's suicide.
Really? It's been a couple of years since I visited the USA, but I don't remember there being many restaurants that only served Coke or Pepsi products and no fruit juices, wines, beers, and so on...
Remember, those two companies sell many drinks other than cola. You've got to look past the logo and branding to the actual real information on who is making and selling you that drink.
While that research might be fine when it comes to cats (I have no knowledge of the field, and I can't be bothered to Google for any scholarly papers to back up the assertions on a website) you are aware that that's completely inapplicable to digestion and nutrition in humans? The issue here is that cats are carnivores and humans are omnivores; the evidence for this is in our dentition, but you can bet that our guts will be at least as different.
Humans have been cooking food for a long long time, through a number of population constrictions. It's entirely possible that we have adaptations that make us better than most animals at dealing with cooked food. Whether we actually have or not is a good question, but evidence from other mammals won't help.
Wind and solar will never provide enough energy to run the world.
Do you have any idea how much solar energy there is hitting the world? Or how much is in the wind? (More of an issue is that there needs to be a system for storage and transport of the energy, but that's reasonably practical to develop.)
Eliminating income tax and taxing consumption directly through sales tax would severely detriment lower income brackets and reward the affluent. The research on sales tax being more detrimental to lower income groups is pretty solid.
The simplest fix for this is to make food-and-drink groceries exempt from sales taxes. Since the proportion of money spent by people (on average) on food as their income increases, this simple action makes the whole system far more progressive. It's also pretty simple (and hence cheap) to implement. Or you could make all food and drink exempt, which is even easier to do and reduces complexities from working out whether food sold for immediate consumption is a grocery but has the cost of reducing overall tax income. (No idea which is better; I'm not an economist.)
We use the approach described in a Wiki implementation and it works pretty well. However, I suggest a refinement...
6. System checks whether incoming version (1) matches database version (2). It does not, so User Y is notified that he cannot save his changes. 7. User Y fetches version 2 of Record A and tries again.
If this happens, you should consider trying to do a merge of the two sets of changes; if the merge succeeds (e.g., because the edits are of different parts of the page) then you can commit the merged version instead of throwing it back in User Y's face. The technology for such merges is pretty well known; it's been used in software version control systems like CVS, SVN and GIT for many years.
Is really better to have 1000 machines in a 5-9's location, or 500 systems each in a 4-9's, with extra cash in hand?
Remember that the main problems with these datacenters are in networking (because that can propagate failures) and automated failover systems. Given that, go for the cash in hand, since you can do other stuff with that (including buying disaster recovery insurance if appropriate).
At some point, some government official will either be exposed to be pervert or some such, or will be wrongfully and horribly flagged as some sort of terrorist.
On the brighter side, with this extensive a surveillance system we'll finally be able to start to track down and enumerate all the women that Silvio Berlusconi has been cheating on his wife with. (Though to be fair, a good approximation would be to start with the full collection of phone books for Italy...)
The issue with IT is that nobody can really measure how well something new (or old) is doing.
That's pure BS.
And thanks to Microsoft, people have gotten used to servers restarting and people being unable to work for computer-related issues for minutes or even hours.
Ah, and there's the source of the BS. You've become so accepting of the crap instability (as promoted by MS and Linux) that you're believing that it means nobody can measure how well things are doing. But it's just not true. You can measure how well things are doing if you're careful about it; might take some programming though.
it's not fair to immediately assume that he just doesn't know what he's doing.
Perhaps, but if I were using Bayesian reasoning about this, that would be exactly my starting premise on the basis of the few facts given.
FWIW, I've also seen the case where management are pushing a solution down the throat of one set of admins (against very stiff opposition) because it makes a huge amount of sense elsewhere supporting other admins. That's the sort of place where management may actually be right (and actually are in the particular case I'm thinking of, but I'll sit on the details because they're a little embarrassing to all concerned).
On the server side, 10x to 30x slower means building entire buildings full of servers. Or more expensive hardware in the cell phone. Or using another language.
You say that like there's something shameful in using more than one language for an application. Here's a little secret. It's not true. Using several languages, each for what it is good at, is like using several tools when doing woodworking. Any good woodworker will tell you that you can't do everything with one tool, even on a simple job. So why restrict yourself when programming?
The big issue is "who owns what" for locking purposes. I discussed some ways to deal with that issue on the Usenet Python group a few weeks ago. If you're willing to introduce "synchronized objects" (like Java) and require that all other mutable objects be linked to either by one thread or one synchronized object at a time, it can all be made to work without extensive programmer effort. Immutable objects don't have sharing problems, except for memory allocation purposes. (That's what concurrent garbage collection is for.)
In Tcl (where I know what's going on in quite a lot of detail) each thread has a separate memory pool for small allocations (large allocs - I forget what qualifies as large - come from the global pool, but are also relatively rare) so that there is very little need for holding locks with high levels of contention. This is facilitated by the fact that Tcl uses an apartment threading model: threads are strongly isolated from one another except for explicitly shared resources (where yes, there's a per-resource lock and no GC at all) and asynchronous messages sent between threads. The net effect is that scaling Tcl programs on multi-core hardware is pretty trivial in practice (e.g., by increasing the size of thread pools used); you have to really work to hit a nasty locking case...
The shared resource model (memory's just a resource, though an important one) just gets into so much trouble when there's more than one core. Increasing the level of isolation and using messaging just seems to work and scale better. But it's a completely different way of doing things; you're probably better off starting from the perspective of pretending you're single-threaded and using different processes (that just happen to be in the same process/address space). That is, code that is designed to work efficiently across a cluster will do fairly well when scaled down to mere 8-core servers.
If you do the transition of parallel processing models, it won't be painless. A lot of existing code will be broken by it. All I can do is point out that it does work and does avoid the GIL.
While that's true, it doesn't change the fact that remote learning of CS is entirely practical. All the labs you'll ever need can be done on your own laptop or remotely using ssh. Commercial collaboration tools are certainly good enough to support remote tutorials and lectures, access to the library isn't very valuable in undergraduate CS, and remote exam taking is possible (though they're also infrequent enough that requiring people to come in for that is reasonable).
The only part that would be hard is if the course uses group-working with other students. Not everyone hits it off well over IRC...
Once I read they 'convert publications into a PhD' I was thinking to pay another place to 'convert life experience into a PhD'.
A number of universities do that, and quite legitimately. It's much easier to spend a few years doing research and then write a thesis though; the "convert publications to PhD" route is for people who are effectively operating already well beyond the doctoral level and just haven't got the piece of paper yet.
when the leak is an employee who has access to ALL of that data in its unencrypted form
Why would the system be giving an employee access to all the data in unsecured form? That'd be a mark of a very badly designed system. But if, "if" mind you, such a breach were to occur, the company wouldn't be eligible for getting out of notification.
Of course, the most likely weak-point is the legitimate end-users and their workstations. They have to have access (it's more important that they save the patient's life than keep their data secure) and you'll never persuade a large proportion of them to have good data hygiene. End users regard security as a bolt-on feature, like a spelling checker or other such; they just don't really value it.
If you're going to complain about the GIL, perhaps you should go read up on why it's necessary, and perhaps share some of your amazing insights on a better, more performant way to do threading.
Their big problem is that they're using a single space of resources that are shared across all threads. That in turn means that they have a lock guarding access to that resource space (the GIL) and so that's where there's massive contention, especially with CPU-bound threads. Drop the general sharing (sharing specific objects is OK if you add the right fine-grained locks) and the code will be much faster. This is very similar to using multiprocessing though, so much so that it makes scaling to a multiprocessing system pretty trivial (you only have to worry about shared objects and inter-thread messaging, but people have worked on those for years).
The big issue is that this model is not compatible with most existing threaded Python code. The single resource-space assumption is pretty deeply embedded...
Filling the drive with helium should help; the speed of sound in helium is 3x higher than in air, and it offers less resistance.
(Hydrogen would be even better, but it has a tendency to interact with metals in unfortunate ways.)
Thinking about it, methane might be a more practical choice. Yes, it's denser than helium so the effect won't be anything like as strong (the speed of sound in methane is only about 40% faster) but it's also very cheap and available, and won't cause too many problems from interacting with the rest of the drive. Having to seal the drive is an issue, yes, but that's not far off what's needed now; it's imperative that dust is kept out of the platter enclosure anyway...
How about completely opening the entire authentication systems up?
It's exceptionally difficult to build an entire end-to-end authentication system, and it's massively more complex if you have more than one vendor. This is stupid - there are plenty of open specifications in this area - but nonetheless true. Part of the problem is that there's so many different ways to put the bits together in a manner that will work, and there's no easy way to either bridge between them or understand which is best for a particular situation. Add in the fact that irritatingly much of the security parts of a system tend to end up in the other layers of applications (it seems to be nearly impossible to stop that) and you get horrendous levels of lock-in to particular solutions.
It's a crappy situation, and I don't blame anyone for going with a single vendor. At least then they get their security exposure down (which is definitely the most important part).
Agreed. This seems to be more of an official non-classified download repository than anything else. If I were in a small business and called their samba share that had the install images of Office, Acrobat, and other licensed packages for internal use an "app store", I'd be looked at by their IT people like I was some troll or pirate.
But the government isn't like a small business. It's like a very large business, and that sort of concept has been around for a while; we do the same thing for applications here with a secure webserver that employees (and students since we're a university) can download install images from, with appropriate invoices being generated internally if necessary afterwards (depends on what sort of license was negotiated with the vendor).
If you're on something like OpenBSD, for example, then the OS does a good job of isolating the userspace code from having to know anything about the underlying architecture.
For the real architecture differences, such as fundamentally different ways of laying out data in memory? Nothing isolates that. Going between endiannesses can cause a lot of problems for poor code, and a lot of otherwise good code doesn't do to well on the 32-bit/64-bit transition. Byte ordering of IEEE floating point is another issue again (like it is for integers, but actually worse). The issue is that fundamental architectural features tend to end up as assumptions in the program.
As a long time Mac user, I completely agree with you. I have long thought Apple did not take security seriously or at least did not devote the resources they should on security matters. Worse, I absolutely do not want to go through a decade of painful and annoying security problems (like the windows users went through) before Apple begins to put real effort into security.
To be fair, Apple have focused much more on the user-facing side of the security problem. There's just much less likelihood of a user installing something bad by accident. Deliberate badness is a problem (always) but by reducing the problem with accidents, real on-the-ground disasters are lessened. (It helps that Mac applications are really directories, and so aren't quite as simple to start from some website by accident, and their filesystem-level metadata that marks downloaded things with where they came from also makes a difference.) Which isn't to say that the other techniques are a bad idea; defense-in-depth is the watchword. But true high-quality security solutions need to address many levels of problems, including both system-level ones and user-facing ones.
Oh... one last thing: Wasn't OpenBSD doing this long before windows?
I believe so. It sounds like the sort of thing they'd do...
Slashdot Mirror
[Moderate or post...? Moderate or post...? Post.]
Let me know when society gives me a guaranteed income, and I'll write open source code and all the bruhaha that comes along with it.
I write open source software for entertainment, and it sure beats watching TV. It happens to be good for my career as well (yes, really) but that's not why I do it. It turns out that direct monetarization is not the only way to benefit, and in fact I derive far more benefit by not charging since if I charged, next to nobody would use it and I'd get far less out of the other ways to gain; network effects are important...
Everyone I know who visits the USA these days tells me what a pain in the ass it is to travel here now.
It depends on where you enter. JFK is truly terrible - only one immigration officer for hundreds of non-residents arriving on a flight - DTW is much better as are SFO, SEA and MEM, and I've not been through ATL, MSP or ORD for a few years and so don't remember there too well (but leaving ORD was a pain due to insufficient post-security facilities, and probably still is). BOS and IAD are rather chaotic, but not too bad. I've never entered through LAX and so can't comment on them (but it's not a good place to change planes anyway). There are other US hubs, but I've not been through those at all (not even Domestic).
Having vehicles on the road traveling much slower than the flow of traffic is a hazard. That's why it's actually illegal in some states to drive slower than 40 mph on the highway absent some emergency.
That's also why it's reasonable for it to be illegal for cyclists (or slow farm vehicles) to be on the freeway.
And yet there's plenty of other roads, and drivers should on seeing a cyclist take care to not hit them. A considerate (and safety-minded) cyclist will seek to ride close to the verge of the road so as to allow other vehicles to pass. But if everyone just insists on their rights all the time instead of taking a tiny amount of effort to be nice to other users, then every journey will be a trial punctuated by near-accidents. IMO roads are way too dangerous for that approach.
Ever seen earodynamic bikes on the road? Beside SUV'? It's suicide.
No, it's murder.
Really? It's been a couple of years since I visited the USA, but I don't remember there being many restaurants that only served Coke or Pepsi products and no fruit juices, wines, beers, and so on...
Remember, those two companies sell many drinks other than cola. You've got to look past the logo and branding to the actual real information on who is making and selling you that drink.
The Pottenger Experiments.
While that research might be fine when it comes to cats (I have no knowledge of the field, and I can't be bothered to Google for any scholarly papers to back up the assertions on a website) you are aware that that's completely inapplicable to digestion and nutrition in humans? The issue here is that cats are carnivores and humans are omnivores; the evidence for this is in our dentition, but you can bet that our guts will be at least as different.
Humans have been cooking food for a long long time, through a number of population constrictions. It's entirely possible that we have adaptations that make us better than most animals at dealing with cooked food. Whether we actually have or not is a good question, but evidence from other mammals won't help.
Wind and solar will never provide enough energy to run the world.
Do you have any idea how much solar energy there is hitting the world? Or how much is in the wind? (More of an issue is that there needs to be a system for storage and transport of the energy, but that's reasonably practical to develop.)
Eliminating income tax and taxing consumption directly through sales tax would severely detriment lower income brackets and reward the affluent. The research on sales tax being more detrimental to lower income groups is pretty solid.
The simplest fix for this is to make food-and-drink groceries exempt from sales taxes. Since the proportion of money spent by people (on average) on food as their income increases, this simple action makes the whole system far more progressive. It's also pretty simple (and hence cheap) to implement. Or you could make all food and drink exempt, which is even easier to do and reduces complexities from working out whether food sold for immediate consumption is a grocery but has the cost of reducing overall tax income. (No idea which is better; I'm not an economist.)
Now we know why there were sixteen finalists. It's 10^100 in binary (a.k.a. 2^4 in decimal).
We use the approach described in a Wiki implementation and it works pretty well. However, I suggest a refinement...
6. System checks whether incoming version (1) matches database version (2). It does not, so User Y is notified that he cannot save his changes.
7. User Y fetches version 2 of Record A and tries again.
If this happens, you should consider trying to do a merge of the two sets of changes; if the merge succeeds (e.g., because the edits are of different parts of the page) then you can commit the merged version instead of throwing it back in User Y's face. The technology for such merges is pretty well known; it's been used in software version control systems like CVS, SVN and GIT for many years.
Is really better to have 1000 machines in a 5-9's location, or 500 systems each in a 4-9's, with extra cash in hand?
Remember that the main problems with these datacenters are in networking (because that can propagate failures) and automated failover systems. Given that, go for the cash in hand, since you can do other stuff with that (including buying disaster recovery insurance if appropriate).
At some point, some government official will either be exposed to be pervert or some such, or will be wrongfully and horribly flagged as some sort of terrorist.
On the brighter side, with this extensive a surveillance system we'll finally be able to start to track down and enumerate all the women that Silvio Berlusconi has been cheating on his wife with. (Though to be fair, a good approximation would be to start with the full collection of phone books for Italy...)
The issue with IT is that nobody can really measure how well something new (or old) is doing.
That's pure BS.
And thanks to Microsoft, people have gotten used to servers restarting and people being unable to work for computer-related issues for minutes or even hours.
Ah, and there's the source of the BS. You've become so accepting of the crap instability (as promoted by MS and Linux) that you're believing that it means nobody can measure how well things are doing. But it's just not true. You can measure how well things are doing if you're careful about it; might take some programming though.
it's not fair to immediately assume that he just doesn't know what he's doing.
Perhaps, but if I were using Bayesian reasoning about this, that would be exactly my starting premise on the basis of the few facts given.
FWIW, I've also seen the case where management are pushing a solution down the throat of one set of admins (against very stiff opposition) because it makes a huge amount of sense elsewhere supporting other admins. That's the sort of place where management may actually be right (and actually are in the particular case I'm thinking of, but I'll sit on the details because they're a little embarrassing to all concerned).
On the server side, 10x to 30x slower means building entire buildings full of servers. Or more expensive hardware in the cell phone. Or using another language.
You say that like there's something shameful in using more than one language for an application. Here's a little secret. It's not true. Using several languages, each for what it is good at, is like using several tools when doing woodworking. Any good woodworker will tell you that you can't do everything with one tool, even on a simple job. So why restrict yourself when programming?
The big issue is "who owns what" for locking purposes. I discussed some ways to deal with that issue on the Usenet Python group a few weeks ago. If you're willing to introduce "synchronized objects" (like Java) and require that all other mutable objects be linked to either by one thread or one synchronized object at a time, it can all be made to work without extensive programmer effort.
Immutable objects don't have sharing problems, except for memory allocation purposes. (That's what concurrent garbage collection is for.)
In Tcl (where I know what's going on in quite a lot of detail) each thread has a separate memory pool for small allocations (large allocs - I forget what qualifies as large - come from the global pool, but are also relatively rare) so that there is very little need for holding locks with high levels of contention. This is facilitated by the fact that Tcl uses an apartment threading model: threads are strongly isolated from one another except for explicitly shared resources (where yes, there's a per-resource lock and no GC at all) and asynchronous messages sent between threads. The net effect is that scaling Tcl programs on multi-core hardware is pretty trivial in practice (e.g., by increasing the size of thread pools used); you have to really work to hit a nasty locking case...
The shared resource model (memory's just a resource, though an important one) just gets into so much trouble when there's more than one core. Increasing the level of isolation and using messaging just seems to work and scale better. But it's a completely different way of doing things; you're probably better off starting from the perspective of pretending you're single-threaded and using different processes (that just happen to be in the same process/address space). That is, code that is designed to work efficiently across a cluster will do fairly well when scaled down to mere 8-core servers.
If you do the transition of parallel processing models, it won't be painless. A lot of existing code will be broken by it. All I can do is point out that it does work and does avoid the GIL.
Computer science is not IT.
While that's true, it doesn't change the fact that remote learning of CS is entirely practical. All the labs you'll ever need can be done on your own laptop or remotely using ssh. Commercial collaboration tools are certainly good enough to support remote tutorials and lectures, access to the library isn't very valuable in undergraduate CS, and remote exam taking is possible (though they're also infrequent enough that requiring people to come in for that is reasonable).
The only part that would be hard is if the course uses group-working with other students. Not everyone hits it off well over IRC...
Once I read they 'convert publications into a PhD' I was thinking to pay another place to 'convert life experience into a PhD'.
A number of universities do that, and quite legitimately. It's much easier to spend a few years doing research and then write a thesis though; the "convert publications to PhD" route is for people who are effectively operating already well beyond the doctoral level and just haven't got the piece of paper yet.
when the leak is an employee who has access to ALL of that data in its unencrypted form
Why would the system be giving an employee access to all the data in unsecured form? That'd be a mark of a very badly designed system. But if, "if" mind you, such a breach were to occur, the company wouldn't be eligible for getting out of notification.
Of course, the most likely weak-point is the legitimate end-users and their workstations. They have to have access (it's more important that they save the patient's life than keep their data secure) and you'll never persuade a large proportion of them to have good data hygiene. End users regard security as a bolt-on feature, like a spelling checker or other such; they just don't really value it.
If you're going to complain about the GIL, perhaps you should go read up on why it's necessary, and perhaps share some of your amazing insights on a better, more performant way to do threading.
Their big problem is that they're using a single space of resources that are shared across all threads. That in turn means that they have a lock guarding access to that resource space (the GIL) and so that's where there's massive contention, especially with CPU-bound threads. Drop the general sharing (sharing specific objects is OK if you add the right fine-grained locks) and the code will be much faster. This is very similar to using multiprocessing though, so much so that it makes scaling to a multiprocessing system pretty trivial (you only have to worry about shared objects and inter-thread messaging, but people have worked on those for years).
The big issue is that this model is not compatible with most existing threaded Python code. The single resource-space assumption is pretty deeply embedded...
Filling the drive with helium should help; the speed of sound in helium is 3x higher than in air, and it offers less resistance.
(Hydrogen would be even better, but it has a tendency to interact with metals in unfortunate ways.)
Thinking about it, methane might be a more practical choice. Yes, it's denser than helium so the effect won't be anything like as strong (the speed of sound in methane is only about 40% faster) but it's also very cheap and available, and won't cause too many problems from interacting with the rest of the drive. Having to seal the drive is an issue, yes, but that's not far off what's needed now; it's imperative that dust is kept out of the platter enclosure anyway...
How about completely opening the entire authentication systems up?
It's exceptionally difficult to build an entire end-to-end authentication system, and it's massively more complex if you have more than one vendor. This is stupid - there are plenty of open specifications in this area - but nonetheless true. Part of the problem is that there's so many different ways to put the bits together in a manner that will work, and there's no easy way to either bridge between them or understand which is best for a particular situation. Add in the fact that irritatingly much of the security parts of a system tend to end up in the other layers of applications (it seems to be nearly impossible to stop that) and you get horrendous levels of lock-in to particular solutions.
It's a crappy situation, and I don't blame anyone for going with a single vendor. At least then they get their security exposure down (which is definitely the most important part).
Agreed. This seems to be more of an official non-classified download repository than anything else. If I were in a small business and called their samba share that had the install images of Office, Acrobat, and other licensed packages for internal use an "app store", I'd be looked at by their IT people like I was some troll or pirate.
But the government isn't like a small business. It's like a very large business, and that sort of concept has been around for a while; we do the same thing for applications here with a secure webserver that employees (and students since we're a university) can download install images from, with appropriate invoices being generated internally if necessary afterwards (depends on what sort of license was negotiated with the vendor).
If you're on something like OpenBSD, for example, then the OS does a good job of isolating the userspace code from having to know anything about the underlying architecture.
For the real architecture differences, such as fundamentally different ways of laying out data in memory? Nothing isolates that. Going between endiannesses can cause a lot of problems for poor code, and a lot of otherwise good code doesn't do to well on the 32-bit/64-bit transition. Byte ordering of IEEE floating point is another issue again (like it is for integers, but actually worse). The issue is that fundamental architectural features tend to end up as assumptions in the program.
As a long time Mac user, I completely agree with you. I have long thought Apple did not take security seriously or at least did not devote the resources they should on security matters. Worse, I absolutely do not want to go through a decade of painful and annoying security problems (like the windows users went through) before Apple begins to put real effort into security.
To be fair, Apple have focused much more on the user-facing side of the security problem. There's just much less likelihood of a user installing something bad by accident. Deliberate badness is a problem (always) but by reducing the problem with accidents, real on-the-ground disasters are lessened. (It helps that Mac applications are really directories, and so aren't quite as simple to start from some website by accident, and their filesystem-level metadata that marks downloaded things with where they came from also makes a difference.) Which isn't to say that the other techniques are a bad idea; defense-in-depth is the watchword. But true high-quality security solutions need to address many levels of problems, including both system-level ones and user-facing ones.
Oh... one last thing: Wasn't OpenBSD doing this long before windows?
I believe so. It sounds like the sort of thing they'd do...