Why would anyone want Java in their browser? I don't have the JRE plugin and would never install it. There's no need for Java to run in a browser. Desktop apps is a different matter, Eclipse and such are quite useful. And it's eminently practical on the server side. But in the browser? That's completely legacy, and Apple should just stop distributing the plugin for Safari.
My immediate questions are, what biochemical mechanism is in place that makes imidacloprid dangerous to bees, and if trace amounts are found in most if not all HFCS, is there any consumption concern for humans who eat food with HFCS in it?
It's a neurotoxin that causes paralysis by disrupting a neurotransmitter that's present in insects but not in warm-blooded animals. It acts on contact.
No, China wouldn't consider a trade war. They'd appeal to the WTO, claiming Australia makes an unreasonable claim to Article XIV.1.a. But clearly 1) this only affects Huawei, not all Chinese network equipment makes, 2) in fact is only coincidentally affecting China with Huawei being a Chinese entity, 3) a government buying secure routing equipment can discriminate based on reputation of vendors.
The bigger issue is how China can be permitted to continue to allow its state to run businesses while remaining a member of the WTO. It's a problem illuminated by Huawei: the business is suspect, which makes the Chinese government suspect. Which then makes ALL businesses the Chinese government meddles in suspect. Which is tantamount to discrimination based on origin when they're shown the door. The WTO was never intended to include countries like China where there is no constitutional separation between affairs of state and private business.
Source code is useless unless you also build and flash it yourself. Otherwise they can trivially give you one source base to review while they install something quite different in the hardware they ship you. Clearly the vendor has to deal with building, flashing, and support. They know the hardware, have the development resources, QA, etc. If they can't be trusted then they're not a viable equipment source.
Or does anyone else also think that perhaps part of the problem is that G+ requires a 232-page manual in the first place?
Re:Seems I'm always contrary. Well here goes again
on
Physics Is (NP-)Hard
·
· Score: 1
NP-hard doesn't mean it can't be "solved". It means there is a large number of solutions and finding the best solution is hard. But finding a single solution isn't necessarily hard. In the case of physics finding a poor solution is trivial, in fact people come up with them all the time. NP-hard means we're doomed to find progressively better approximations, but will likely never find a perfect expression. This also has nothing to do with computers; in fact NP-hard often means only computers can be used to generate progressively better solutions (i.e. search the solution space).
Also it has nothing to do with Fermat's Theorem. That's about mathematical proof, not creating systems to model reality.
Finally, the summary says reality is a system "governed" by equations; this is clearly not correct. The system and its equations we use to approximate the behavior of reality are entirely abstract constructs. They exist in our mind as a high-order reflection of reality. They are a part of reality (since we are) but don't "govern" it any more than we do.
Does payroll really require a Big Iron?
I can't really imagine that keeping track of a company's financials (even measured in billions) requires $730,000 / year in number crunching ability...
It's not just payroll, but also tracking every expense, income, capital asset, depreciation, order placed, order received, services provided, goods shipped, customer phone call received, etc. For a large company it's an AMAZING amount of data. The "old way" of doing this was to dump all this into a set of tables, then run enormously complex recursively joined queries to restructure it and generate reports, billing reminders, etc. The new way is to dump it into mapreduce, scribe feeds, or equivalent and get cooked data out that can easily be tabulated in reports. The data out of the distributed computation gets fed into a relatively small db while all the raw data is just piped to some storage device for posterity. This computational model fits better with cloud provisioning. But you may find a room full of 20U blade chassis loaded up isn't exactly cheap either. But it's more flexible, and the mapreduce model of pre-cooking is more economic because it distributes the load over the quarter rather than over a few days following each quarter. Of course, horizontal scaling is vastly cheaper than vertical scaling, if the problem can be attacked that way. Even if the overhead approaches several hundred percent or you crunch numbers in php (heaven forbid) - it's still vastly cheaper.
But everyone knows the distributed model is cheaper. It's just that any business that's been around more than 10 years has a large body of legacy code to already implement all the custom payroll, auditing, tax code enforcement, tax optimization, reports, etc they need, which makes it's a huge project to move a system that's already in production. Moving it would probably cost in the millions and is very risky, so it's easy to just to pony up $700k annually and forget about it. It's also really difficult to migrate in steps.
"Often good hackers aren't useful for more than vulnerability testing."... because their vulnerability-finding box doesn't adequately intersect the system-security-design box.
If you are screening out the folks with the hacker/InfoSec mindset (those that think differently/outside the box),
They're not thinking outside the box, they're thinking inside a different box. Just hiring someone who thinks inside that particular box isn't by itself sufficient, or rather doesn't guarantee anything beyond basic competence for the job. It's MUCH easier to break into a system than secure it, because you only need one vulnerability. Those who are the best at finding these vulnerabilities typically aren't the same ones who are the best at preventing them. You can't secure a system by trial-and-error (find-and-patch). Often good hackers aren't useful for more than vulnerability testing.
My problem is requirements like, "One uppercase, two digits, one punctuation, 8-20 characters." You know people will use exactly this and nothing else, at close to the minimum length. So for an 8-char password you get 26*26^4*10^2*12 combinations. However, if you just let people use 8 lowercase chars you get 26^8, which is 14 times as big. In addition, by outright banning punctuation and digits it's no longer possible to search a smaller space first, say consisting of one or two uppercase, one or two digits, and bang at the end, the remainder lowercase. (If you who read this have a password matching this pattern, CHANGE IT NOW.) Strength indicators at password selection dialogs are good, but a lot of them are counterproductive and will tell you ten chars of which one or two is uppercase, two digits and a bang at the end are 'strong' while just ten random lowercase letters is 'weak'. Laughable.
The issue isn't password storage, but credit card information. Nobody cares if their password is broken; it's pretty easily changed. Handling CC information securely is far more difficult than basic account information and secure password authentication.
CC information needs to be stored in a physically separate server which has no web servers or accept remote logins, but use entirely internal, minimal protocols that omit any possibility of read access to data. All operations need to task-based; no setters and getters or that sort of thing. Instead, "change CC #n for acct XXXXX to YYYYY", "set confirmation email for XXXXX to foo@example.com", or "enumerate stored billing options for acct XXXXX" that returns a list with entries like "ZZZZZZ, VISA with last for digits 1234". All orders send confirmation email for review. This limits a break-in on the web frontend to perform exactly those operations exposed by the protocol.
Unfortunately, crap like LAMP have taken good engineering back to the 1970s and most systems work like sh*t for practical reasons; if you have only at most 25 outstanding requests because that's how many apache processes you have, then backend curls are a no-go, in fact anything blocking is a huge detriment to scalability. Instead engineers are forced to invent utterly retarded workarounds like putting processing queues in membase and polling with ajax for results in the browser. It's just so utterly craptastic I don't know whether to laugh or cry!
Almost half the cost of PVs is that of the silicon used to make them, and the price of silicon went up from $40 to $200 per 1kg in just 5 years. What held back wide acceptance of PVs was the price of silicon - there simply wasn't enough supply to meet demand. Solyndra was creating a business of making non-silicon PVs to bring down prices. There was nothing wrong with the company or their technology, or their business model. What happened was that the price of silicon dropped due to additional supply becoming available, and Solyndra (being a one-trick startup) was out of business. I've been at startups that have met very similar fates; it's simply one of the major reasons startups fail. No change in direction or tweaking of the business model will help when the product is suddenly uncompetitive. Most startups fail due to uncontrollable circumstances; it's a fact of life and people who are afraid to fail should avoid it. That doesn't mean startups which fail are a bad idea, or a poor investment, or the people were incompetent, or there was some sort of scam involved. It just didn't pan out. Solyndra didn't fail due to chinese dumping, or chinese anything. Chinese manufacturers buy silicon at market prices just like everyone else.
The Xelteks are quite okay - and more importantly, the company is still there to support them. I see a SuperPro 280U on eBay for $250 right now for instance... a $200-$300 budget for a USB device should be more than feasible. It's really the way to go IMO. I used to love Needham's gear, but they went out of business some time ago and I wouldn't recommend buying a programmer with spotty software support. The USB devices generally work under VMware on OS X as well.
MySpace was the same way when FB came along. People switched once, they'll do it again, whether it's for google+ or something else.
Just about nobody I know who is on FaceBook ever had a MySpace "page". Maybe their kids do. To most of us FB is simply a living rolodex, to stay in touch and find people we haven't seen in 20 years, i.e. people we hung out with before the MySpace tweenies ate solid food. We're just not interested in designing a "page" (we'd hire a web designer to build a site if we need one). We don't care about the latest band or pony pictures. There's nothing and nobody of interest on MySpace, and we never switched to FB from anywhere. We simply didn't use SN's until FB came along and offered something to complement phones, email, and IM.
A few months ago we needed a second laptop, so I ended up buying a 13" Macbook Pro that had pretty much the same Core2Duo at 2.4 Ghz. Is this because we hit a wall with Moore's Law?
No, it's because you bought it used or refurbed. The 13" MBP has been all i5/i7 for well over a year now.
It may still be a consistent measurement fault, but they've repeated it 15000 times.
FTFA: "The team measured the travel times of neutrino bunches some 15,000 times, and have reached a level of statistical significance that in scientific circles would count as a formal discovery."
It could also be an interesting quantum physical effect - maybe the neutrinos' wavelength is on the order of 18 (or 36) meter and the detector triggers on the front of the wave, forcing the particle to appear at that location. In effect, no matter how far it's fired, it would always appear 60ns early. It could also be they fired a gazillion particles, most of which went right through the the detector. Except for those that would appear at or near the wave front. In effect, the detected particles would always appear early.
Gravitational energy loss can be observed in astronomical objects. See http://www.faqs.org/faqs/astronomy/faq/part4/ However, even though gravity is predicted to be retarded (meaning the waves spread from the location a body was at, not where it is) - the force projected is toward the current position, giving the appearance of instant force exchange as required by Newton. Without it, stable orbits aren't possible, which we can disprove by numerous counterexamples. Observing gravitational ripples is a current hot subject. The existence of a gravitational wave spread pretty much guarantees it's at c (most likely) or less (less likely). If it's faster, well that would be very interesting.
Dear God, why dumb people like you even bother writing such piles of crap?
NATO is no dumber than the Serbians. It's just a different perspective; they don't worry about "wasting" missiles. If they keep Serbian forces busy building decoys instead acting as a military force looking to win a war, then by all means. At the pace they can build decoys, NATO would never run out of missiles. They simply order more. Cost for things like missiles, fuel, and maintenance is a non-issue. While it may make a small opponent feel smart and superior that they can lure a missile strike on a decoy, in the end it doesn't help them win, hold on, or delay the loss. They still can't move or use the real equipment, because there are more planes and more missiles. And if there weren't, NATO would bring in more. It's a complete non-issue.
I bought my first Mac 10 years ago now and have been using Mac laptops ever since. All this time I just close the lid and it goes to sleep and when I open the lid it's there waiting for me to type my password in to unlock it.
When you close the lid on OS X it turns off the screen, does a sync(), and starts hibernating remaining anonymous pages to disk. When you open again it resumes the in-memory state. If you let it sleep long enough for the battery to fully drain (I'd guess in a week or two) it will resume from the checkpointed state on disk.
I rarely reboot my 2008 Mac Pro either, I always have a lot of state - multiple VMs etc - up and running so constantly rebooting it would be ridiculously tedious. Every few months it gets rebooted due to a software update, the rest of the time I just put it to sleep (cmd-opt-eject) when not using it. It spins down and puts my external raid unit to sleep as well.
IMO more benchmarks should measure user-experience response. For instance, the time from when you open a laptop to when it's connected to a local wifi network and ready to use. I'd guess that's 2-3 seconds for a modern MacBook Pro. Maybe 10 seconds if allowed to completely drain, but that depends on memory size and how much it had to checkpoint. On my Mac Pro the slowest factor is actually the two Dell WFP3008 displays I use as my main desktop; they take about 7 seconds to come on from DisplayPort wake. (My old 24" Apple Cinema display from 2004 comes on immediately though, but it's over on a different table and I usually put VMs on it full screen with a separate keyboard and mouse. Ubuntu, CentOS, WinXP, or Win7 depending on what I'm doing.)
Out of curiosity I looked at your link to Node. Then at the explanation about what the project is. It fits in half a line: "evented I/O for v8 javascript" and I have no idea what that means, even after 25 years of pro programming. Fairly typical of undocumented open-source projects, unfortunately.
The link is to the source, not the project per se. It's pretty well documented (I hadn't heard of it before, either) at http://nodejs.org/. In brief, it's a reactor pattern for JS. In fact, I see it's even mentioned on the Wiki page: http://en.wikipedia.org/wiki/Reactor_pattern.
The code looks good to me. Pretty much stock, professional, quality, C++ system software. Some of the algorithms/heuristics (e.g. idle detection for GC) are perhaps debatable (in a good way), but the code itself looks good. If a job candidate told me they wrote this and showed it as an example of past work I'd consider their ability to produce quality code fully proven, and switch to their other abilities as an engineer.
Slashdot Mirror
Why would anyone want Java in their browser? I don't have the JRE plugin and would never install it. There's no need for Java to run in a browser. Desktop apps is a different matter, Eclipse and such are quite useful. And it's eminently practical on the server side. But in the browser? That's completely legacy, and Apple should just stop distributing the plugin for Safari.
My immediate questions are, what biochemical mechanism is in place that makes imidacloprid dangerous to bees, and if trace amounts are found in most if not all HFCS, is there any consumption concern for humans who eat food with HFCS in it?
It's a neurotoxin that causes paralysis by disrupting a neurotransmitter that's present in insects but not in warm-blooded animals. It acts on contact.
No, China wouldn't consider a trade war. They'd appeal to the WTO, claiming Australia makes an unreasonable claim to Article XIV.1.a. But clearly 1) this only affects Huawei, not all Chinese network equipment makes, 2) in fact is only coincidentally affecting China with Huawei being a Chinese entity, 3) a government buying secure routing equipment can discriminate based on reputation of vendors.
The bigger issue is how China can be permitted to continue to allow its state to run businesses while remaining a member of the WTO. It's a problem illuminated by Huawei: the business is suspect, which makes the Chinese government suspect. Which then makes ALL businesses the Chinese government meddles in suspect. Which is tantamount to discrimination based on origin when they're shown the door. The WTO was never intended to include countries like China where there is no constitutional separation between affairs of state and private business.
Source code is useless unless you also build and flash it yourself. Otherwise they can trivially give you one source base to review while they install something quite different in the hardware they ship you. Clearly the vendor has to deal with building, flashing, and support. They know the hardware, have the development resources, QA, etc. If they can't be trusted then they're not a viable equipment source.
Or does anyone else also think that perhaps part of the problem is that G+ requires a 232-page manual in the first place?
NP-hard doesn't mean it can't be "solved". It means there is a large number of solutions and finding the best solution is hard. But finding a single solution isn't necessarily hard. In the case of physics finding a poor solution is trivial, in fact people come up with them all the time. NP-hard means we're doomed to find progressively better approximations, but will likely never find a perfect expression. This also has nothing to do with computers; in fact NP-hard often means only computers can be used to generate progressively better solutions (i.e. search the solution space).
Also it has nothing to do with Fermat's Theorem. That's about mathematical proof, not creating systems to model reality.
Finally, the summary says reality is a system "governed" by equations; this is clearly not correct. The system and its equations we use to approximate the behavior of reality are entirely abstract constructs. They exist in our mind as a high-order reflection of reality. They are a part of reality (since we are) but don't "govern" it any more than we do.
Anyone also do assignments on PDP 11/70's as I did also?
Yes, on RSTS/E using BASIC-PLUS (for lab work in high school) and Macro-11 (for personal fun stuff). Also, RSX-11M.
Does payroll really require a Big Iron? I can't really imagine that keeping track of a company's financials (even measured in billions) requires $730,000 / year in number crunching ability...
It's not just payroll, but also tracking every expense, income, capital asset, depreciation, order placed, order received, services provided, goods shipped, customer phone call received, etc. For a large company it's an AMAZING amount of data. The "old way" of doing this was to dump all this into a set of tables, then run enormously complex recursively joined queries to restructure it and generate reports, billing reminders, etc. The new way is to dump it into mapreduce, scribe feeds, or equivalent and get cooked data out that can easily be tabulated in reports. The data out of the distributed computation gets fed into a relatively small db while all the raw data is just piped to some storage device for posterity. This computational model fits better with cloud provisioning. But you may find a room full of 20U blade chassis loaded up isn't exactly cheap either. But it's more flexible, and the mapreduce model of pre-cooking is more economic because it distributes the load over the quarter rather than over a few days following each quarter. Of course, horizontal scaling is vastly cheaper than vertical scaling, if the problem can be attacked that way. Even if the overhead approaches several hundred percent or you crunch numbers in php (heaven forbid) - it's still vastly cheaper.
But everyone knows the distributed model is cheaper. It's just that any business that's been around more than 10 years has a large body of legacy code to already implement all the custom payroll, auditing, tax code enforcement, tax optimization, reports, etc they need, which makes it's a huge project to move a system that's already in production. Moving it would probably cost in the millions and is very risky, so it's easy to just to pony up $700k annually and forget about it. It's also really difficult to migrate in steps.
"Often good hackers aren't useful for more than vulnerability testing." ... because their vulnerability-finding box doesn't adequately intersect the system-security-design box.
If you are screening out the folks with the hacker/InfoSec mindset (those that think differently/outside the box),
They're not thinking outside the box, they're thinking inside a different box. Just hiring someone who thinks inside that particular box isn't by itself sufficient, or rather doesn't guarantee anything beyond basic competence for the job. It's MUCH easier to break into a system than secure it, because you only need one vulnerability. Those who are the best at finding these vulnerabilities typically aren't the same ones who are the best at preventing them. You can't secure a system by trial-and-error (find-and-patch). Often good hackers aren't useful for more than vulnerability testing.
This part is right: (26 + 10 + 11) * 2 = 94. But yeah, he forgot space so it should be 95.
26 uppercase, 26 lowercase, 10 digits, 12 punctuation/space = 74.
My problem is requirements like, "One uppercase, two digits, one punctuation, 8-20 characters." You know people will use exactly this and nothing else, at close to the minimum length. So for an 8-char password you get 26*26^4*10^2*12 combinations. However, if you just let people use 8 lowercase chars you get 26^8, which is 14 times as big. In addition, by outright banning punctuation and digits it's no longer possible to search a smaller space first, say consisting of one or two uppercase, one or two digits, and bang at the end, the remainder lowercase. (If you who read this have a password matching this pattern, CHANGE IT NOW.) Strength indicators at password selection dialogs are good, but a lot of them are counterproductive and will tell you ten chars of which one or two is uppercase, two digits and a bang at the end are 'strong' while just ten random lowercase letters is 'weak'. Laughable.
Sadly password storage
The issue isn't password storage, but credit card information. Nobody cares if their password is broken; it's pretty easily changed. Handling CC information securely is far more difficult than basic account information and secure password authentication.
CC information needs to be stored in a physically separate server which has no web servers or accept remote logins, but use entirely internal, minimal protocols that omit any possibility of read access to data. All operations need to task-based; no setters and getters or that sort of thing. Instead, "change CC #n for acct XXXXX to YYYYY", "set confirmation email for XXXXX to foo@example.com", or "enumerate stored billing options for acct XXXXX" that returns a list with entries like "ZZZZZZ, VISA with last for digits 1234". All orders send confirmation email for review. This limits a break-in on the web frontend to perform exactly those operations exposed by the protocol.
Unfortunately, crap like LAMP have taken good engineering back to the 1970s and most systems work like sh*t for practical reasons; if you have only at most 25 outstanding requests because that's how many apache processes you have, then backend curls are a no-go, in fact anything blocking is a huge detriment to scalability. Instead engineers are forced to invent utterly retarded workarounds like putting processing queues in membase and polling with ajax for results in the browser. It's just so utterly craptastic I don't know whether to laugh or cry!
If it's a cost center, open source it. It may offset the cost slightly. If it's a profit center, hold it to your chest.
Almost half the cost of PVs is that of the silicon used to make them, and the price of silicon went up from $40 to $200 per 1kg in just 5 years. What held back wide acceptance of PVs was the price of silicon - there simply wasn't enough supply to meet demand. Solyndra was creating a business of making non-silicon PVs to bring down prices. There was nothing wrong with the company or their technology, or their business model. What happened was that the price of silicon dropped due to additional supply becoming available, and Solyndra (being a one-trick startup) was out of business. I've been at startups that have met very similar fates; it's simply one of the major reasons startups fail. No change in direction or tweaking of the business model will help when the product is suddenly uncompetitive. Most startups fail due to uncontrollable circumstances; it's a fact of life and people who are afraid to fail should avoid it. That doesn't mean startups which fail are a bad idea, or a poor investment, or the people were incompetent, or there was some sort of scam involved. It just didn't pan out. Solyndra didn't fail due to chinese dumping, or chinese anything. Chinese manufacturers buy silicon at market prices just like everyone else.
The Xelteks are quite okay - and more importantly, the company is still there to support them. I see a SuperPro 280U on eBay for $250 right now for instance... a $200-$300 budget for a USB device should be more than feasible. It's really the way to go IMO. I used to love Needham's gear, but they went out of business some time ago and I wouldn't recommend buying a programmer with spotty software support. The USB devices generally work under VMware on OS X as well.
MySpace was the same way when FB came along. People switched once, they'll do it again, whether it's for google+ or something else.
Just about nobody I know who is on FaceBook ever had a MySpace "page". Maybe their kids do. To most of us FB is simply a living rolodex, to stay in touch and find people we haven't seen in 20 years, i.e. people we hung out with before the MySpace tweenies ate solid food. We're just not interested in designing a "page" (we'd hire a web designer to build a site if we need one). We don't care about the latest band or pony pictures. There's nothing and nobody of interest on MySpace, and we never switched to FB from anywhere. We simply didn't use SN's until FB came along and offered something to complement phones, email, and IM.
A few months ago we needed a second laptop, so I ended up buying a 13" Macbook Pro that had pretty much the same Core2Duo at 2.4 Ghz. Is this because we hit a wall with Moore's Law?
No, it's because you bought it used or refurbed. The 13" MBP has been all i5/i7 for well over a year now.
It may still be a consistent measurement fault, but they've repeated it 15000 times. FTFA: "The team measured the travel times of neutrino bunches some 15,000 times, and have reached a level of statistical significance that in scientific circles would count as a formal discovery."
It could also be an interesting quantum physical effect - maybe the neutrinos' wavelength is on the order of 18 (or 36) meter and the detector triggers on the front of the wave, forcing the particle to appear at that location. In effect, no matter how far it's fired, it would always appear 60ns early. It could also be they fired a gazillion particles, most of which went right through the the detector. Except for those that would appear at or near the wave front. In effect, the detected particles would always appear early.
Just my 2 bits of amateur speculation. :)
And your proof is ... ?
Gravitational energy loss can be observed in astronomical objects. See http://www.faqs.org/faqs/astronomy/faq/part4/ However, even though gravity is predicted to be retarded (meaning the waves spread from the location a body was at, not where it is) - the force projected is toward the current position, giving the appearance of instant force exchange as required by Newton. Without it, stable orbits aren't possible, which we can disprove by numerous counterexamples. Observing gravitational ripples is a current hot subject. The existence of a gravitational wave spread pretty much guarantees it's at c (most likely) or less (less likely). If it's faster, well that would be very interesting.
It would pretty much be indicative of hidden wave state being uncovered.
rsync, then logrotate with a custom config.
Dear God, why dumb people like you even bother writing such piles of crap?
NATO is no dumber than the Serbians. It's just a different perspective; they don't worry about "wasting" missiles. If they keep Serbian forces busy building decoys instead acting as a military force looking to win a war, then by all means. At the pace they can build decoys, NATO would never run out of missiles. They simply order more. Cost for things like missiles, fuel, and maintenance is a non-issue. While it may make a small opponent feel smart and superior that they can lure a missile strike on a decoy, in the end it doesn't help them win, hold on, or delay the loss. They still can't move or use the real equipment, because there are more planes and more missiles. And if there weren't, NATO would bring in more. It's a complete non-issue.
I bought my first Mac 10 years ago now and have been using Mac laptops ever since. All this time I just close the lid and it goes to sleep and when I open the lid it's there waiting for me to type my password in to unlock it.
When you close the lid on OS X it turns off the screen, does a sync(), and starts hibernating remaining anonymous pages to disk. When you open again it resumes the in-memory state. If you let it sleep long enough for the battery to fully drain (I'd guess in a week or two) it will resume from the checkpointed state on disk.
I rarely reboot my 2008 Mac Pro either, I always have a lot of state - multiple VMs etc - up and running so constantly rebooting it would be ridiculously tedious. Every few months it gets rebooted due to a software update, the rest of the time I just put it to sleep (cmd-opt-eject) when not using it. It spins down and puts my external raid unit to sleep as well.
IMO more benchmarks should measure user-experience response. For instance, the time from when you open a laptop to when it's connected to a local wifi network and ready to use. I'd guess that's 2-3 seconds for a modern MacBook Pro. Maybe 10 seconds if allowed to completely drain, but that depends on memory size and how much it had to checkpoint. On my Mac Pro the slowest factor is actually the two Dell WFP3008 displays I use as my main desktop; they take about 7 seconds to come on from DisplayPort wake. (My old 24" Apple Cinema display from 2004 comes on immediately though, but it's over on a different table and I usually put VMs on it full screen with a separate keyboard and mouse. Ubuntu, CentOS, WinXP, or Win7 depending on what I'm doing.)
Where the heck do I start to create a better 60 Hz filter???
Digital Signal Processing: A Practical Guide for Engineers and Scientists would be a good place to start.
Out of curiosity I looked at your link to Node. Then at the explanation about what the project is. It fits in half a line: "evented I/O for v8 javascript" and I have no idea what that means, even after 25 years of pro programming. Fairly typical of undocumented open-source projects, unfortunately.
The link is to the source, not the project per se. It's pretty well documented (I hadn't heard of it before, either) at http://nodejs.org/. In brief, it's a reactor pattern for JS. In fact, I see it's even mentioned on the Wiki page: http://en.wikipedia.org/wiki/Reactor_pattern.
The code looks good to me. Pretty much stock, professional, quality, C++ system software. Some of the algorithms/heuristics (e.g. idle detection for GC) are perhaps debatable (in a good way), but the code itself looks good. If a job candidate told me they wrote this and showed it as an example of past work I'd consider their ability to produce quality code fully proven, and switch to their other abilities as an engineer.