Of course you can get high performance user space graphics when you minimize the number of context switches. Coalescing the requests and so on, it's all pretty well known. I didn't say that those costs aren't there, just that you need to be aware of them so that you keep them in check. It requires a certain kind of programming approach when you write, say, OpenGL code where the driver is a userspace process. You need to keep server roundtrips to the minimum.
Pray tell why is it now the school district's business to locate people's kids?! The kid is off the bus, that's it. Just because we today have technology that would allow to track everyone and their poodle everywhere they go doesn't mean everyone should stupidly jump on it. If a parent thinks it's the schools job to keep track of their kid, they are stupid. If a kid is going who knows where without letting their parents know as presumably previously agreed to/demanded by the parents, the kid is stupid. Or perhaps the kid just doesn't give shit. Or whatever.
I'd say it's the parents' problem. If the district is too stupid to defend themselves from stupid parents and their stupid kids, someone needs to be replaced at the dsitricty. Technical solutions to people problems usually don't work.
You know what? This argument applies to a lot of thing people do for fun. So I don't think it makes any sense at all to call anything a stupid waste of talent. It's entirely unproductive to do so. People usually don't live their lives such as to optimize some utility function of the "maximize the use of your talent" kind.
Re:Why aren't there more contributors to this proj
on
ReactOS 0.3.15 Released
·
· Score: 4, Informative
Hummm, what?!?! You know it is the same computer, right? If it is killing performance, then the scheduler is fucked. Another proof windows is broken.
Nope. The problem is with the cost of a context swap. When usual kernel code executes, the code still executes in the context of the current process. There is no MMU context swap, just some registers get saved to stack, and the protection level is changed. When you run it in a separate process, you not only to invoke the scheduler (which isn't invoked when you merely do a syscall), you have to swap out the entire MMU context. This is very expensive, and only gets relatively more expensive compared to running code with more advanced processors.
Even without the:auto, relegating the declarations to a block that's far removed from where the variables are used makes no sense today. Historically it was an idea that made Pascal easy to parse and compile with a single-pass and low memory consumption. It should be treated like what it is: a historical artifact of no further use.
When you believe your life is in danger, or you believe someone else's life is in danger, it's moral to use deadly force in defense of the person in harms way.
In other words, when the tornado is coming, go out and shoot the neighbor?
You see, just because someone has a gun doesn't mean you have to shoot him. All you are after is disabling the would-be shooter. I'd argue a stun grenade or flashbang would be way more reliable for temporary disablement than trying to shoot the perpetrator. I'm sure there are even more efficient ways disabling your opponent, and I argue that shooting is probably the least reliable mainstream means.
Again, all you want is to remove the dange. Shooting shouldn't even enter the equation unless you have a very sound argument that shooting is the only option. I, frankly said, don't really see shooting as being even a moderately good option unless you're quite far away from your target and are going for a sniper kill.
You're talking about a fictional scenario, because the engineering reality is nowhere close, and it's not just a matter of trying hard. See for yourself what kind of functionality you get from SIL 3 devices out there. Biometrics is nowhere near this level of performance, especially that the human performance becomes a key aspect of the system performance. Your biometric system is ultimately only as (un)reliable as your human user is. A biometric system for gun use would be ideally a SIL 4 system, maybe a SIL 3 system. Good luck getting a human to provide you with biometric data with reliability that SIL 3, or even SIL 2 calls for. Never mind just having the ability to process that data and make a friend/foe determination with SIL 3 reliability.
Yes, you have a fantasy where some kids would be alive if there was a fantastic device. There's an infinite number of such fantastic devices that you can come up with that could protect those children. That doesn't make your argument any more sound, because the argument must come from engineering and relevant domain expertise, not from wishful thinking. Just because you can think something up doesn't make it possible, you know. Your argument would read exactly the same if you replaced "had Adam Lanza's mom had owned smart guns" with "had the teachers and pupils owned personal force field generators". Contrary to what you might think, both are equally impossible. It's the same with people who want to censor the internet. Just because they can think up a phrase doesn't make it possible, or even something that merely makes abstract sense as an idea applied to internet.
You can make a gun the just plain works AND hove a bio metric ID system.
Nope, sorry, that's fantasy that can only be spewed by those who have no idea what it takes to engineer reliable electronics. The biometrics in such a gun are life-critical and would need to at least pass the safety of machinery regulations that cover safety-critical systems such as safety gates, interlocks, emergency stops and such. That would be really the lowest hurdle I would wish such biometrics to pass. I figure we're talking safety integrity level 4 (SIL 4). Such systems are usually only designed with monitored fixed-purpose inherently safe devices. That means either reliably monitored relays or inherently fail-safe low-density hardwired transistor logic. Our technology at the moment is nowhere near to have a biometric system that would actually fit on a gun designed to SIL 4, and I argue that SIL 4 is about the least stringent requirement you'd want.
Heck, even if you'd go "only" for SIL 3, the argument being that the death of a couple people is nothing compared to an explosion at a refinery, there are simply no biometric sensors nor algorithms that are anywhere near the reliability levels called for by SIL 3. Heck, it is in fact impossible to have a fingerprint-based biometrics that are SIL 3-reliable simply because the rates of unavailability of your fingers to be timely scanned are many orders of magnitude too high. It's still be too high even for SIL 2!
You could probably engineer a multi-modal biometric system to SIL 2 requirements. After a decade or two of field experience with it, you could probably push it to SIL 3, but I doubt it'd ever be possible simply because end users become a critical element in the day-to-day reliability of such a system. Remember that a gun has insane requirements for availability on the first actuation.
The parent is sarcastic, clueless or just trolling. Perhaps all three at once. There's no point discussing the flaws, really, if the parent doesn't see them, there's no amount of convincing that would sway him/her. The parent post is just irrational rambling without any forethought.
The problem with all these things is not they can't be done
No, the problem is indeed that all those things can only be done on paper. No matter how much complexity you throw at the problem, even if you make a gun cost a million dollars, you can still defeat some of them rather trivially, while others simply can't be done - they don't exist as anything but thought on paper, and this won't change for a good while. A F/F system needs a public web of trust, so let's see how much of that is going on out there - recall that you need this on an ubiquitous, global scale. Also recall that free PGP implementations have been available for more than a decade now, you'd think everyone and their dog would use it by now.
I hope you're sarcastic, because there's so much engineering wishful thinking in this list it's not even funny.
a) RF signals are trivial to jam, and you only need the jammer close to the gun - a tiny jammer will do. Heck, most likely all you need is to disable the receiving antenna and you're done. There are multiple ways of doing that, one is to stick a piece of shielding kit over the antenna opening.
b) Same here. No antenna, or antenna shielded with off-the-shelf RF-absorbing materials used for EMI mitigation, and nothing gets transmitted.
c) GPS doesn't work indoors, and it has a non-zero acquisition time since you power it up. If it wasn't powered up in a long time, acquisition times could extend to minutes. But why worry about any of it, just look at a).
d) a),b) applies. Never mind that I wish you good luck implementing dependable F/F on a social scale, LOL.
e) See a), unless you want to use gravity waves for transmission.
You are aware of the fact that there are cryptographically sound ways of protecting against replay attacks, right? And that those ways are deployed all over the place, heck, in popular open source implementations even?
When you're on a range, time usually costs money. Not having to reload magazines is, um, helpful. As for killing people, while I disagree with the carte blanche hold your grounds laws that allow one to kill people (vs. merely temporarily disabling/stunning them), there's plenty of home invasions where there are multiple perpetrators. If we assume that it's ethical for you to kill the invaders, you'll likely need many rounds per each invader unless you're trained to remain calm and quickly aim the nearest target. Even then, you can plant a perfect shot in someone's torso and they may keep closing on you until you plant a couple more perfect shots. If you're in cramped quarters, you have no choice but to literally load the invaders with bullets to have any chance at evading contact. Again, I'm no fan of killing people and I'd much rather only allow people to have stun grenades, tasers and rubber bullets for self defense. A stun grenade works way better than trying to shoot someone who is raising their weapon to aim at you.
I'm still on the fence whether the idea that use of lethal force in self defense in such situations is really a natural born right. Yeah, you have right to defend yourself, but that I'm not really sure that this right, ethically, automatically implies the right to manslaughter. Aren't there plenty of non-lethal ways of incapacitating intruders that are just as easy to use as a gun would be? Why the heck are people so eager to kill others?
Slashdot Mirror
Of course you can get high performance user space graphics when you minimize the number of context switches. Coalescing the requests and so on, it's all pretty well known. I didn't say that those costs aren't there, just that you need to be aware of them so that you keep them in check. It requires a certain kind of programming approach when you write, say, OpenGL code where the driver is a userspace process. You need to keep server roundtrips to the minimum.
Huh? The existence of an explicit data stack got nothing to do with the existence of a runtime library!
Stun grenade followed by taser followed by handcuffs.
Pray tell why is it now the school district's business to locate people's kids?! The kid is off the bus, that's it. Just because we today have technology that would allow to track everyone and their poodle everywhere they go doesn't mean everyone should stupidly jump on it. If a parent thinks it's the schools job to keep track of their kid, they are stupid. If a kid is going who knows where without letting their parents know as presumably previously agreed to/demanded by the parents, the kid is stupid. Or perhaps the kid just doesn't give shit. Or whatever.
I'd say it's the parents' problem. If the district is too stupid to defend themselves from stupid parents and their stupid kids, someone needs to be replaced at the dsitricty. Technical solutions to people problems usually don't work.
At least you can do the rest of your job hopefully better and easier by being otherwise freed from Windows.
Sigh, the whole thread was started by a flamebait question "why no Pascal-style syntax". You kinda missed that subtle point :)
You know what? This argument applies to a lot of thing people do for fun. So I don't think it makes any sense at all to call anything a stupid waste of talent. It's entirely unproductive to do so. People usually don't live their lives such as to optimize some utility function of the "maximize the use of your talent" kind.
That's when you get a VMware license :)
Hummm, what?!?! You know it is the same computer, right? If it is killing performance, then the scheduler is fucked. Another proof windows is broken.
Nope. The problem is with the cost of a context swap. When usual kernel code executes, the code still executes in the context of the current process. There is no MMU context swap, just some registers get saved to stack, and the protection level is changed. When you run it in a separate process, you not only to invoke the scheduler (which isn't invoked when you merely do a syscall), you have to swap out the entire MMU context. This is very expensive, and only gets relatively more expensive compared to running code with more advanced processors.
:)
Even without the :auto, relegating the declarations to a block that's far removed from where the variables are used makes no sense today. Historically it was an idea that made Pascal easy to parse and compile with a single-pass and low memory consumption. It should be treated like what it is: a historical artifact of no further use.
When you believe your life is in danger, or you believe someone else's life is in danger, it's moral to use deadly force in defense of the person in harms way.
In other words, when the tornado is coming, go out and shoot the neighbor?
You see, just because someone has a gun doesn't mean you have to shoot him. All you are after is disabling the would-be shooter. I'd argue a stun grenade or flashbang would be way more reliable for temporary disablement than trying to shoot the perpetrator. I'm sure there are even more efficient ways disabling your opponent, and I argue that shooting is probably the least reliable mainstream means.
Again, all you want is to remove the dange. Shooting shouldn't even enter the equation unless you have a very sound argument that shooting is the only option. I, frankly said, don't really see shooting as being even a moderately good option unless you're quite far away from your target and are going for a sniper kill.
You're talking about a fictional scenario, because the engineering reality is nowhere close, and it's not just a matter of trying hard. See for yourself what kind of functionality you get from SIL 3 devices out there. Biometrics is nowhere near this level of performance, especially that the human performance becomes a key aspect of the system performance. Your biometric system is ultimately only as (un)reliable as your human user is. A biometric system for gun use would be ideally a SIL 4 system, maybe a SIL 3 system. Good luck getting a human to provide you with biometric data with reliability that SIL 3, or even SIL 2 calls for. Never mind just having the ability to process that data and make a friend/foe determination with SIL 3 reliability.
Yes, you have a fantasy where some kids would be alive if there was a fantastic device. There's an infinite number of such fantastic devices that you can come up with that could protect those children. That doesn't make your argument any more sound, because the argument must come from engineering and relevant domain expertise, not from wishful thinking. Just because you can think something up doesn't make it possible, you know. Your argument would read exactly the same if you replaced "had Adam Lanza's mom had owned smart guns" with "had the teachers and pupils owned personal force field generators". Contrary to what you might think, both are equally impossible. It's the same with people who want to censor the internet. Just because they can think up a phrase doesn't make it possible, or even something that merely makes abstract sense as an idea applied to internet.
They are not engineers either.
You can make a gun the just plain works AND hove a bio metric ID system.
Nope, sorry, that's fantasy that can only be spewed by those who have no idea what it takes to engineer reliable electronics. The biometrics in such a gun are life-critical and would need to at least pass the safety of machinery regulations that cover safety-critical systems such as safety gates, interlocks, emergency stops and such. That would be really the lowest hurdle I would wish such biometrics to pass. I figure we're talking safety integrity level 4 (SIL 4). Such systems are usually only designed with monitored fixed-purpose inherently safe devices. That means either reliably monitored relays or inherently fail-safe low-density hardwired transistor logic. Our technology at the moment is nowhere near to have a biometric system that would actually fit on a gun designed to SIL 4, and I argue that SIL 4 is about the least stringent requirement you'd want.
Heck, even if you'd go "only" for SIL 3, the argument being that the death of a couple people is nothing compared to an explosion at a refinery, there are simply no biometric sensors nor algorithms that are anywhere near the reliability levels called for by SIL 3. Heck, it is in fact impossible to have a fingerprint-based biometrics that are SIL 3-reliable simply because the rates of unavailability of your fingers to be timely scanned are many orders of magnitude too high. It's still be too high even for SIL 2!
You could probably engineer a multi-modal biometric system to SIL 2 requirements. After a decade or two of field experience with it, you could probably push it to SIL 3, but I doubt it'd ever be possible simply because end users become a critical element in the day-to-day reliability of such a system. Remember that a gun has insane requirements for availability on the first actuation.
The parent is sarcastic, clueless or just trolling. Perhaps all three at once. There's no point discussing the flaws, really, if the parent doesn't see them, there's no amount of convincing that would sway him/her. The parent post is just irrational rambling without any forethought.
The problem with all these things is not they can't be done
No, the problem is indeed that all those things can only be done on paper. No matter how much complexity you throw at the problem, even if you make a gun cost a million dollars, you can still defeat some of them rather trivially, while others simply can't be done - they don't exist as anything but thought on paper, and this won't change for a good while. A F/F system needs a public web of trust, so let's see how much of that is going on out there - recall that you need this on an ubiquitous, global scale. Also recall that free PGP implementations have been available for more than a decade now, you'd think everyone and their dog would use it by now.
I hope you're sarcastic, because there's so much engineering wishful thinking in this list it's not even funny.
a) RF signals are trivial to jam, and you only need the jammer close to the gun - a tiny jammer will do. Heck, most likely all you need is to disable the receiving antenna and you're done. There are multiple ways of doing that, one is to stick a piece of shielding kit over the antenna opening.
b) Same here. No antenna, or antenna shielded with off-the-shelf RF-absorbing materials used for EMI mitigation, and nothing gets transmitted.
c) GPS doesn't work indoors, and it has a non-zero acquisition time since you power it up. If it wasn't powered up in a long time, acquisition times could extend to minutes. But why worry about any of it, just look at a).
d) a),b) applies. Never mind that I wish you good luck implementing dependable F/F on a social scale, LOL.
e) See a), unless you want to use gravity waves for transmission.
f) Whatever.
Except that these days the relay is a mosfet. Much more rugged than a relay that could succumb do moisture, vibration or dirt.
Everything depends on where you are. In some places it's plenty possible already..
Reanimate, chop up and kill again. Slowly. :)
You are aware of the fact that there are cryptographically sound ways of protecting against replay attacks, right? And that those ways are deployed all over the place, heck, in popular open source implementations even?
When you're on a range, time usually costs money. Not having to reload magazines is, um, helpful. As for killing people, while I disagree with the carte blanche hold your grounds laws that allow one to kill people (vs. merely temporarily disabling/stunning them), there's plenty of home invasions where there are multiple perpetrators. If we assume that it's ethical for you to kill the invaders, you'll likely need many rounds per each invader unless you're trained to remain calm and quickly aim the nearest target. Even then, you can plant a perfect shot in someone's torso and they may keep closing on you until you plant a couple more perfect shots. If you're in cramped quarters, you have no choice but to literally load the invaders with bullets to have any chance at evading contact. Again, I'm no fan of killing people and I'd much rather only allow people to have stun grenades, tasers and rubber bullets for self defense. A stun grenade works way better than trying to shoot someone who is raising their weapon to aim at you.
I'm still on the fence whether the idea that use of lethal force in self defense in such situations is really a natural born right. Yeah, you have right to defend yourself, but that I'm not really sure that this right, ethically, automatically implies the right to manslaughter. Aren't there plenty of non-lethal ways of incapacitating intruders that are just as easy to use as a gun would be? Why the heck are people so eager to kill others?