Yeah. Why teach the applications practical to 95% of white collar jobs instead of programming, which most kids won't be interested in, fewer will 'get' and hardly any will ever do professionally?
You could say the same about cellular biology, chemistry, quantum mechanics, calculus, and music taught at the high school level. Most people won't professionally develop those skills, but they're better off for having been exposed to the fundamentals. Any maybe out of the breadth of subjects you throw at a young student, they'll find their passion and stick with it. Why exclude programming from that mix?
Forget cars, how long will it be before I can a pair of eyeglasses with this coating?
The night vision coating could go on one side of the lenses, and the anti-glare coating goes on the other side. What more could a geek need?
While servers may be "old hat," the new breed of social networking and cloud computing sites are still innovating in this area. The traditional idea of large, fast machines running big relational databases is dying. Check out the recent rise of Bigtable, MapReduce, Memcached, and especially NoSql among service providers.
There's real innovation happening on the server side to enable the current generation of mobile devices. The handheld clients may be the sexy part of computing right now, but they couldn't do much without data centers backing them up.
The malware detection algorithm involves the following steps on the client machine:... (5) Policy: Execute the verification policy. This could involve reporting the memory contents of the client device to the verifying party, or the execution of any task that should preferably be run in a safe environment. This may be done using whitelisting or blacklisting approaches, and may involve the use of heuristics to scan the swap space and secondary storage in general. The implementation of the policy is beyond the scope of this paper, as we only deal with how to assert the absence of active malware herein. [orig. in italics]
So you're right, their technique really only catches against one thing: a malicious (or infected) operating system that guards its dirty bits from an OS-level verifier by playing tricks with the verifier's address space. You still need another checker to catch all the conventional viruses out there that don't play this particular game.
I'm sure the CPU time limit would be generous enough that it won't matter if your programming language is interpreted 10x slower than hand-tuned assembly. They want to make sure you aren't using a brute-force O(n^3) algorithm when a linear one would work well enough.
Plus, the judges need a rule to allow them to terminate programs that may be stuck in infinite loops. Otherwise, a contestant could delay the results of a competition indefinitely.
(Imagine: "This competition was rigged! The judges killed my program before it had a chance to finish. It was working fine, and I was the first one to submit answers to all the problems. What? So it has a long start up time. You don't have a rule against 100-hour programs.")
SLIME looks very useful, so long as the only thing I need to debug is Emacs itself. I can't find the part in the SLIME manual where it helps me write and debug programs written in any of the languages supported in Visual Studio. The one I care about is C.
If SLIME really can help me, I'd love to use it. It does look quite nice.
As an aside, if you believe that open source developers write tools to scratch their own itches, does this mean that more people need to debug Emacs than need to debug any other program?;)
Reading the research paper, the 6% overhead looks like it comes from having the kernel call into the hypervisor every time it allocates or frees an object that contains a kernel hook (a.k.a. function pointer). The designers explicitly state that they use non-paged memory to store the protected kernel hooks.
By having different UIs for each platform, life becomes more difficult for add-on designers. Anything that does more than add a new toolbar button suddenly becomes platform-specific.
I think that just running a Tor relay, even one without an exit policy, is still beneficial. The core infrastructure could probably use the extra bandwidth, even if isn't going directly out to the web.
What good is a fault tolerant file system if it isn't tolerant of faults?
Any time you read about a product that guarantees perfect fault tolerance, there is always a list of constraints that must be met for that claim to hold. You probably won't ever see this list marketed, but it's there somewhere.
I haven't looked into this, but it sounds like ZFS is fault-tolerant given a system model where data can change once it's on-disk, but otherwise system components are fail-stop. So if you ask a hard disk to perform a write barrier and flush its data to disk, the disk will either do so and report success, it will issue an I/O error, or it will catch on fire. Any way, ZFS will handle the situation correctly.
Of course, the immediate next question is whether that failure model is realistic. Turns out it isn't. Some hardware will report 'write barrier complete' when it still has unwritten data in its buffer.
If you can't count on your hard disk to flush its caches or even order writes correctly, I don't think it's possible to build any fault-free file system on top of the drive.
As far as I understand it, wake-on-lan would let me SSH into one computer so I can send a magic packet to my real to computer to wake it up, and then I can SSH in to the computer I wanted to in the first place.
Somniloquy gives the same functionality transparently, without needing that extra step, without any other network user being aware that the computer was asleep in the first place.
If you read the referenced paper, they do talk about why they don't like wake-on-lan in section 6.
there are so many other low-powered devices that will do so much more.
The important part of this work isn't that there is another device to do your downloading. Yes, there are better devices for that.
What these guys have done is design one way to keep your PC in low power mode as long as possible. One reason that people keep their computers on is that they want network services to be available. (Some keep their computer on because it's downloading torrents. I keep my computer on because I might want to SSH in or access my files remotely.)
This device is one way to keep a computer network-accessible while it's in a low-power sleep. (Hence the name "Somniloquy": talking in one's sleep.) They do this by putting a proxy between the computer and the network. The computer can go to sleep and have the proxy take over network functions for it.
This turns out to be a very general approach. For some types of network access, this device can get away with ignoring the data. For other accesses (like when I try to SSH in), it can wake the computer from sleep to process the request. For some trivial protocols like ping, it's easy to let the proxy just respond.
They show that it's still possible to get some power saving in complex protocols. As an illustration of its generality, they were able to implement BitTorrent within this design. Other protocols may give similar benefits. But they aren't about to implement everything out there.
We're still struggling with the object-relational impedance mismatch today. The closest we are to finding a "solid basis" for computer science is a general field of philosophy called "structural realism" which attempts to find the proper roles of relations vs relata in creating our models of the world.
If your biggest problem is how to represent objects in a relational database, I'd say the foundation is solid enough.
More broadly, your problem is that we don't know exactly what we should be modeling with our computers, not questioning whether computers are capable of modeling it. That's progress.
Compiling each CPP in turn requires 10 - 100 files read off the disk each time.
Modern operating systems get around this issue with a disk cache. In reality, 100 files will be read off the disk for the first compile, and the rest of the compiles will just access the cached copy in memory (unless memory is in short supply on your system).
The core instruction set has had multiple sets of custom enhancements over the years, and can now do some pretty amazing stuff "in a single instruction."
Even though the instruction set exposes a CISC interface, some modern chips decompose those instructions down into micro-ops. So internally, the processor could still resemble a RISC architecture.
Remember, the iPhone has little internal security. Every process runs with root privileges, so a program needs to have very strict boundaries. A stray script off the Internet could wreck havoc on this phone (and its owner).
I'd guess that this is the one reason why the restrictions are in place. The optimistic view is that Apple may eventually beef up their security for later models and give way to a more permissive license.
1) They have your desktop computer
2) It is on
3) You've entered your crypto keys
I use FileVault on my Powerbook so that if it did happen to walk away, my personal data would stay safe. This computer stays on (suspended) with me logged in all the time, so it fits your criteria perfectly.
As far as patching -- of course routers get patched. That's what firmware updates are for. Linksys is still releasing firmware updates for a router I've had for five years.
Making firware updates available isn't enough. They actually need to get installed. How many users do you think get them? How many do you think even know that a router has firmware that needs patching? Keep in mind that many Windows users wouldn't install patches until Microsoft forced them to. Yes, you can blame the users for being ignorant and for not keeping their system secure. That doesn't change the fact that unpatched, vulnerable routers are present in droves on the net.
Worth noting that in that time, NOTHING has gotten past it. Nothing. At all. On an always-on cable connection
What you mean is you haven't noticed anything getting past it. Detection methods aren't doing too great, according to the Security Absurdity article. I don't doubt your spirit. I don't think I would notice if my router got infected either. But in all honesty, you're probably right.
As far as recommending to not upgrade firmware -- I would say that you do not recall correctly. The only such warning I get says not to turn off the router while in the midst of flashing the firmware.
Yep. Went ahead and looked it up, and you're right. Nowhere does it say, "Don't upgrade!" However, it does give this message:
If the Router's Internet connection is working well, there is no need to download a newer firmware version, unless that version contains new features that you would like to use. Downloading a more current version of Router firmware will not enhance the quality or speed of your Internet connection, and may disrupt your current connection stability. - WRT54G User's Guide, p. 70.
3. Buy a Windows machine, and put it behind a $20 router with a built-in firewall.
I wouldn't put so much faith in those $20 routers. They too are vulnerable to exploits, but routers will never get patched. IIRC, Linksys manuals even tell the user to never do a firmware upgrade since it might brick the device.
Maybe the router itself isn't powerful enough of a platform to be a spam relay or help in a DDoS, but once it's compromised it can give an attacker unhindered local access to your network. Reinstalling your desktop OS won't fix this problem.
For an interesting hybrid approach between threads and events, check out SEDA - Architecture for Highly-Concurrent Server Applications. Basically, you write a server as a collection of stages connected by event queues. A stage receives an event on an incoming queue, does some processing on it, and then places it on an queue to some other stage. This mirrors the way an event-driven system is designed. Each stage has its own thread pool to handle events. All IO is asynchronous and is treated like any other event in the system.
There is a genuine difference between multithreading and forking. The kernel does take longer to switch between processes than between threads since there's an address space change between processes. 10,000 threads in one process will use fewer per-process resources than would 10,000 processes of one thread each. I want to say that process accounting (on creation/destruction) takes more time than thread accounting, but I'm not intimately familiar with their implementation on Linux. For some applications, sharing a heap among all threads might make passing data a bit simpler than using IPC or shared memory.
As for utilizing the CPU, threads and processes should be close in performance. I would still expect threads to be slightly faster, since the (x86) processor's TLB is flushed on a context change that wouldn't happen if you switch between threads. For a server where any of this really matters, there will be thousands of worker threads/processes compared to a small number of system threads, so the probability of switching between two worker threads will be high.
I'm sure I'm leaving out some other important differences, but I can't think of them at the moment.
User-level thread libraries can let a process run even faster than with kernel threads or processes (less kernel involvement = faster), but in order to get good performance, asynchronous IO is a necessity.
The fundamental question of systems administration: once you have had a root compromise, what can you do to the machine to get it back up and running, in a known good configuration, with all chances of future compromise as a result of the initial compromise removed?
Answer: either compare the system (booted from known good media) to a known good set of files, or reinstall from known good media.
There's no other answer.
There is another answer: Backtracking Intrusions. Basically, the idea is to keep your own virtual machine monitor (VMM) running on the bare hardware that logs everything that happens to a system. If you detect that a system is compromised, you can rewind the execution of the system to any point in the past to see every action the malware took.
If a VMM-based malware were to try and take control of a system, it would really be taking control of a virtual machine. It would still be logged, so all its actions could be discovered and concievably undone.
Any tools you run on the compromised system are by definition suspect; they might be good, or they might be compromised. You have no way of knowing; anything they tell you is suspect.
If you're already running a VMM to log the system, you could put intrusion detection tools above the operating system, where no malware could touch it. This is the idea behind virtual machine introspection. Tools at this level can examine the virtualized operating system to detect whether the OS is compromised (or has been previously compromised) through a specific vulnerability without any chance that malware (inside the virtual machine) will interfere.
Rutkowska stressed that the Blue Pill technology does not rely on any bug of the underlying operating system.
The critical point here is that the bug is in AMD's SVM/Pacifica virtualization technology, not any OS. Yes, there is a bug. The size of an elephant, it seems. And it's an elephant that happens to be implemented in hardware, where no amount of OS-level security will help.
Slashdot Mirror
You could say the same about cellular biology, chemistry, quantum mechanics, calculus, and music taught at the high school level. Most people won't professionally develop those skills, but they're better off for having been exposed to the fundamentals. Any maybe out of the breadth of subjects you throw at a young student, they'll find their passion and stick with it. Why exclude programming from that mix?
Forget cars, how long will it be before I can a pair of eyeglasses with this coating? The night vision coating could go on one side of the lenses, and the anti-glare coating goes on the other side. What more could a geek need?
While servers may be "old hat," the new breed of social networking and cloud computing sites are still innovating in this area. The traditional idea of large, fast machines running big relational databases is dying. Check out the recent rise of Bigtable, MapReduce, Memcached, and especially NoSql among service providers.
There's real innovation happening on the server side to enable the current generation of mobile devices. The handheld clients may be the sexy part of computing right now, but they couldn't do much without data centers backing them up.
Well, to quote their tech report:
So you're right, their technique really only catches against one thing: a malicious (or infected) operating system that guards its dirty bits from an OS-level verifier by playing tricks with the verifier's address space. You still need another checker to catch all the conventional viruses out there that don't play this particular game.
I'm sure the CPU time limit would be generous enough that it won't matter if your programming language is interpreted 10x slower than hand-tuned assembly. They want to make sure you aren't using a brute-force O(n^3) algorithm when a linear one would work well enough.
Plus, the judges need a rule to allow them to terminate programs that may be stuck in infinite loops. Otherwise, a contestant could delay the results of a competition indefinitely.
(Imagine: "This competition was rigged! The judges killed my program before it had a chance to finish. It was working fine, and I was the first one to submit answers to all the problems. What? So it has a long start up time. You don't have a rule against 100-hour programs.")
SLIME looks very useful, so long as the only thing I need to debug is Emacs itself. I can't find the part in the SLIME manual where it helps me write and debug programs written in any of the languages supported in Visual Studio. The one I care about is C.
If SLIME really can help me, I'd love to use it. It does look quite nice.
As an aside, if you believe that open source developers write tools to scratch their own itches, does this mean that more people need to debug Emacs than need to debug any other program? ;)
Reading the research paper, the 6% overhead looks like it comes from having the kernel call into the hypervisor every time it allocates or frees an object that contains a kernel hook (a.k.a. function pointer). The designers explicitly state that they use non-paged memory to store the protected kernel hooks.
By having different UIs for each platform, life becomes more difficult for add-on designers. Anything that does more than add a new toolbar button suddenly becomes platform-specific.
What are you talking about? Amazon has never sold copies of 1984 or Animal Farm in digital format, and to suggest otherwise is treasonous.
I think that just running a Tor relay, even one without an exit policy, is still beneficial. The core infrastructure could probably use the extra bandwidth, even if isn't going directly out to the web.
What good is a fault tolerant file system if it isn't tolerant of faults?
Any time you read about a product that guarantees perfect fault tolerance, there is always a list of constraints that must be met for that claim to hold. You probably won't ever see this list marketed, but it's there somewhere.
I haven't looked into this, but it sounds like ZFS is fault-tolerant given a system model where data can change once it's on-disk, but otherwise system components are fail-stop. So if you ask a hard disk to perform a write barrier and flush its data to disk, the disk will either do so and report success, it will issue an I/O error, or it will catch on fire. Any way, ZFS will handle the situation correctly.
Of course, the immediate next question is whether that failure model is realistic. Turns out it isn't. Some hardware will report 'write barrier complete' when it still has unwritten data in its buffer.
If you can't count on your hard disk to flush its caches or even order writes correctly, I don't think it's possible to build any fault-free file system on top of the drive.
As far as I understand it, wake-on-lan would let me SSH into one computer so I can send a magic packet to my real to computer to wake it up, and then I can SSH in to the computer I wanted to in the first place.
Somniloquy gives the same functionality transparently, without needing that extra step, without any other network user being aware that the computer was asleep in the first place.
If you read the referenced paper, they do talk about why they don't like wake-on-lan in section 6.
there are so many other low-powered devices that will do so much more.
The important part of this work isn't that there is another device to do your downloading. Yes, there are better devices for that.
What these guys have done is design one way to keep your PC in low power mode as long as possible. One reason that people keep their computers on is that they want network services to be available. (Some keep their computer on because it's downloading torrents. I keep my computer on because I might want to SSH in or access my files remotely.)
This device is one way to keep a computer network-accessible while it's in a low-power sleep. (Hence the name "Somniloquy": talking in one's sleep.) They do this by putting a proxy between the computer and the network. The computer can go to sleep and have the proxy take over network functions for it.
This turns out to be a very general approach. For some types of network access, this device can get away with ignoring the data. For other accesses (like when I try to SSH in), it can wake the computer from sleep to process the request. For some trivial protocols like ping, it's easy to let the proxy just respond.
They show that it's still possible to get some power saving in complex protocols. As an illustration of its generality, they were able to implement BitTorrent within this design. Other protocols may give similar benefits. But they aren't about to implement everything out there.
WHat does a women bring that a man doesn? or vise versa?
A different perspective. And maybe a less-confrontational attitude.
We're still struggling with the object-relational impedance mismatch today. The closest we are to finding a "solid basis" for computer science is a general field of philosophy called "structural realism" which attempts to find the proper roles of relations vs relata in creating our models of the world.
If your biggest problem is how to represent objects in a relational database, I'd say the foundation is solid enough.
More broadly, your problem is that we don't know exactly what we should be modeling with our computers, not questioning whether computers are capable of modeling it. That's progress.
Compiling each CPP in turn requires 10 - 100 files read off the disk each time.
Modern operating systems get around this issue with a disk cache. In reality, 100 files will be read off the disk for the first compile, and the rest of the compiles will just access the cached copy in memory (unless memory is in short supply on your system).
The core instruction set has had multiple sets of custom enhancements over the years, and can now do some pretty amazing stuff "in a single instruction."
Even though the instruction set exposes a CISC interface, some modern chips decompose those instructions down into micro-ops. So internally, the processor could still resemble a RISC architecture.
Remember, the iPhone has little internal security. Every process runs with root privileges, so a program needs to have very strict boundaries. A stray script off the Internet could wreck havoc on this phone (and its owner).
I'd guess that this is the one reason why the restrictions are in place. The optimistic view is that Apple may eventually beef up their security for later models and give way to a more permissive license.
I use FileVault on my Powerbook so that if it did happen to walk away, my personal data would stay safe. This computer stays on (suspended) with me logged in all the time, so it fits your criteria perfectly.
This attack throws the switch on my plans.
Making firware updates available isn't enough. They actually need to get installed. How many users do you think get them? How many do you think even know that a router has firmware that needs patching? Keep in mind that many Windows users wouldn't install patches until Microsoft forced them to. Yes, you can blame the users for being ignorant and for not keeping their system secure. That doesn't change the fact that unpatched, vulnerable routers are present in droves on the net.
Worth noting that in that time, NOTHING has gotten past it. Nothing. At all. On an always-on cable connectionWhat you mean is you haven't noticed anything getting past it. Detection methods aren't doing too great, according to the Security Absurdity article. I don't doubt your spirit. I don't think I would notice if my router got infected either. But in all honesty, you're probably right.
As far as recommending to not upgrade firmware -- I would say that you do not recall correctly. The only such warning I get says not to turn off the router while in the midst of flashing the firmware.Yep. Went ahead and looked it up, and you're right. Nowhere does it say, "Don't upgrade!" However, it does give this message:
If the Router's Internet connection is working well, there is no need to download a newer firmware version, unless that version contains new features that you would like to use. Downloading a more current version of Router firmware will not enhance the quality or speed of your Internet connection, and may disrupt your current connection stability. - WRT54G User's Guide, p. 70.
3. Buy a Windows machine, and put it behind a $20 router with a built-in firewall.
I wouldn't put so much faith in those $20 routers. They too are vulnerable to exploits, but routers will never get patched. IIRC, Linksys manuals even tell the user to never do a firmware upgrade since it might brick the device.
Maybe the router itself isn't powerful enough of a platform to be a spam relay or help in a DDoS, but once it's compromised it can give an attacker unhindered local access to your network. Reinstalling your desktop OS won't fix this problem.
For an interesting hybrid approach between threads and events, check out SEDA - Architecture for Highly-Concurrent Server Applications. Basically, you write a server as a collection of stages connected by event queues. A stage receives an event on an incoming queue, does some processing on it, and then places it on an queue to some other stage. This mirrors the way an event-driven system is designed. Each stage has its own thread pool to handle events. All IO is asynchronous and is treated like any other event in the system.
There is a genuine difference between multithreading and forking. The kernel does take longer to switch between processes than between threads since there's an address space change between processes. 10,000 threads in one process will use fewer per-process resources than would 10,000 processes of one thread each. I want to say that process accounting (on creation/destruction) takes more time than thread accounting, but I'm not intimately familiar with their implementation on Linux. For some applications, sharing a heap among all threads might make passing data a bit simpler than using IPC or shared memory.
As for utilizing the CPU, threads and processes should be close in performance. I would still expect threads to be slightly faster, since the (x86) processor's TLB is flushed on a context change that wouldn't happen if you switch between threads. For a server where any of this really matters, there will be thousands of worker threads/processes compared to a small number of system threads, so the probability of switching between two worker threads will be high.
I'm sure I'm leaving out some other important differences, but I can't think of them at the moment.
User-level thread libraries can let a process run even faster than with kernel threads or processes (less kernel involvement = faster), but in order to get good performance, asynchronous IO is a necessity.
The fundamental question of systems administration: once you have had a root compromise, what can you do to the machine to get it back up and running, in a known good configuration, with all chances of future compromise as a result of the initial compromise removed?
Answer: either compare the system (booted from known good media) to a known good set of files, or reinstall from known good media.
There's no other answer.
There is another answer: Backtracking Intrusions. Basically, the idea is to keep your own virtual machine monitor (VMM) running on the bare hardware that logs everything that happens to a system. If you detect that a system is compromised, you can rewind the execution of the system to any point in the past to see every action the malware took.
If a VMM-based malware were to try and take control of a system, it would really be taking control of a virtual machine. It would still be logged, so all its actions could be discovered and concievably undone.
Any tools you run on the compromised system are by definition suspect; they might be good, or they might be compromised. You have no way of knowing; anything they tell you is suspect.
If you're already running a VMM to log the system, you could put intrusion detection tools above the operating system, where no malware could touch it. This is the idea behind virtual machine introspection. Tools at this level can examine the virtualized operating system to detect whether the OS is compromised (or has been previously compromised) through a specific vulnerability without any chance that malware (inside the virtual machine) will interfere.
Rutkowska stressed that the Blue Pill technology does not rely on any bug of the underlying operating system.
The critical point here is that the bug is in AMD's SVM/Pacifica virtualization technology, not any OS. Yes, there is a bug. The size of an elephant, it seems. And it's an elephant that happens to be implemented in hardware, where no amount of OS-level security will help.