If the data there is current, LED's max around 100 lm/W (15%), CFL's around 72 lm/W (11%), high efficiency fluorescent around 120 lm/W (18%) and things like low pressure sodium (orange-hued street lamps and the like) around 200 lm/W (29%). Incandescent hang out in the 5 - 18 lm/W range (~ 2.5%)
So right now in commercial products, the expensive LED based bulbs built with very good LEDs offer about the same performance as CFL's and usually are outperformed by your standard fluorescent fixtures. They do actually last a great deal longer and are arguably more environmentally friendly. They are easily justified by any installation where changing a bulb costs considerably more than the bulb (such as commercial installations requiring scaffolding to accomplish the feat). However the LED bulbs you can find in the retail stores these days that represent that a 5W LED bulb compares to a 13W CFL and a 100W incandescent are telling absolute lies. Then again, most retailers wouldnt dare put a decent $120 LED bulb on the shelf either - it simply wouldn't sell.
IMO the whole system for advertising bulbs is broken. If there's going to be any change to the laws about lighting it should not be to ban the sale of incandescents but to require better labeling. If bulb packaging were required to display the luminous output, the power consumption, and the color temperature we'd all be better off. There is some other useful information they could put in there too such as PF, weight, hazmat, lifetime, etc. -- sort of a "Nutritional Information" for bulbs. They already require similar labeling on appliances but I could see this type of requirement really helping out on power consumption. Once that garbage battery charger has to actually put a label on its box that says it ships with a crap 10% efficient wall wart that draws 300mA idle is the day it will instead start shipping with a better power supply.
The CA certificate system isn't supposed to be a 'web of trust' though. It COULD be but honestly users wouldn't make the effort. Most PGP users don't bother with the 'web of trust' either anymore which is why it's all but dead. Allowing companies to become authoritative CAs for their own domains is a good solution in theory, but the end user still needs someone to step in and help them do the identity proofing because, again, they won't make the effort; plus how do you secure it? DNS? Whois? Have them buy CA certs? All of these have flaws. Does the current system suck? A little bit - maybe about as much as the current system for domain registration, but
A company can already become a CA if it wants to and have users choose to trust them or install their CA certs on end users machines or use them within their own applications. Many enterprises run internal CAs anyway. In your example there is really nothing preventing capitalone from distributing a small installer that makes them a trusted CA same as Verisign or any of the others whose CA certs are bundled with the browsers. But if you think that these companies who are too already too disorganized to correctly author and secure their current web apps are going to go through the rigamarole of running their own CA and talking their users through trusting them? You are just talking crazy.
FWIW there is apparently malware that already does this -- a CA cert, a hostfile entry and suddenly paypal.com is showing green bars on nigerian servers no problem.
This is pretty much the only comment needed in this thread. I came to post basically the same two links.
Due to memory overcommit, ESX or the free ESXi on a whitebox is really the only viable lab platform to play with this kind of thing at home (or even at work) without breaking the bank. When you look at *any* other vm platform you can't test complicated infrastructure or scaling/paralleling techniques inside of 8GB. Once you start needing 16GB+ ram for your experiments, you start either run out of DIMM slots on most consumer-level boards and have to look at server motherboards -- or you have to shell out for 4GB DIMMS -- either way you start running into expensive territory.
S3's transfer fees start at 17c to 10TB/mo. and decline to 10c at 150TB/mo. At the volumes we are talking about for game downloads at ~1-2GB each download you'd easily be at the top end.
And amazon isn't really that cheap either when it comes down to content delivery. It's nice because it's more or less on demand but if you can do a little bit of forward planning, a content delivery network like Akamai can give you better pricing.
Anyway the article is a stupid gripe about a nonexistent problem. Microsoft doesn't charge the publisher bandwidth fees because they choose to charge the customer. Furthermore anyone who thinks they can do it for "free" on their own website is under some serious delusions. A publisher unable to budget for this correctly is a bad publisher. I think perhaps they are just pissed because they can't provide the service and charge for the bandwidth themselves - I bet they would charge a lot more than 16c/GB.
Sony picked a price and terms that are reasonable and cost competitive in the market. There are some ways around it too - game downloads from PSN could contain only skeleton executable files which would download the rest of the data on first start from a publisher's own content servers. The fact that we're not seeing any of this is probably because it's just not that big of a deal. $200K in bandwidth fees to expose a million people or more to your game demo is money well spent. It comes out of the advertising budget and will give a better return than $200K spent on billboards, that's for sure.
No CA is (currently) issuing wildcard EV certs. I personally understand the convenience of the wildcard cert, but I do also accept and support the practice of disallowing wildcards in high security applications.
EV certificates are available with multiple Subject Alternative Names, though so the whole "dropped www." or a couple of virtual shouldn't be a big deal if things are done correctly. Unfortunately they aren't and some sites (paypal) that are using EV SSL certs don't even bother with this simple feature.
The correct failsafe implementation which will always result in a no-prompt situation is to ensure that you only deploy EV certificates on an IP addresses that have only one DNS name. You then deploy a frontend redirection server on a second IP using a wildcard SSL cert that occupies the alternative dns names for the namespace of the original app. This server will pass cert checks more easily and then redirect to the EV server with its specific dns name which will then show the green bar. Any existing deep links to the application on an incorrect DNS name will be handled correctly and any direct references will work in the future. There are of course implications for securing said redirection proxy, but they aren't really that hard to overcome.
The dealership always gets all the money right away unless they carry the note themselves; and honestly, the only dealerships I've seen still doing that are the insanely shady "Auto Sales & Finance" type places that are likely to pack a clunker's radiator with eggs and sawdust then force it on a poor person so that they can beat $100 out of them every month. The reputable dealerships have figured out that it's much easier and better to find a couple banks to handle this dirty work for them.
Buying a car on an Amex)is actually a pretty good idea. Amex has all kinds of good buyer protections that can really save your ass when you need them. Note though that I'm talking about a real "charge card" amex not one of those new stupid blue ones that let you carry a balance and otherwise abuse it.
So, if your friend bought the car on *his* Amex, you might give his "supidity" a second thought. However, I would think it's rather unlikely that anyone in college could have earned an amex capable of purchasing a car without some kind of assistance -- was it his dad's Amex? That's a bit different.
Actually it sounds like they have a transparent web proxy that is malfunctioning. You can probably request that your traffic not be sent through the proxy.
Yes; this discrepancy is accounted for in two ways:
1) The burst rate allows the 12mb connection to achieve the ~22mb rates for a brief period of time
2) The XP box cannot achieve > 10-12 mb on this particular connection; most probably due to the way the TCP window scaling is limited in the default configuration. This particularly affects high bandwidth, high latency connections, particularly when peak available bandwidth is irregularly available. There is also likely a problem where selective ACKs are not being properly used and XP may be saturating the smaller upstream bandwidth.
All programs are smart enough to guess the upstream bandwidth. It's a basic built-in feature of TCP. It would usually be considered best practice not to implement any kind of rate limiting logic in the app and instead simply rely on TCP to do what it's supposed to. The problem is that (in general) consumer-grade routers use FIFO-type queuing implementations that are terrible for asynchronous connections like most people have.
"Smart applications", QoS and traffic shaping are really not the first line of defense here. The real solution is for consumer routers to implement better queuing algorithms such as WFQ or WRED so that when you want to start applying QoS and traffic shaping, they actually have the ability to do what they are supposed to. None of that stuff is going to help you when you have FIFO queues on your crappy little router and you experience congestion upstream of your connection -- the only way you can provide traffic control with a FIFO queue is to flat out keep the packets out of it.
When you put it that way, why bother with lights when you can burn candles, heat when you can just make a fire, and a fridge when you can just preserve everything in brine? Electronics, seriously? All you need is a thermometer, barometer, and a pair of eyes!
Anwyay, it was just an example of a "major appliance" and in any case it would still use less power by itself than running an electric stove or oven and electric furnace at the same time - probably less than an electric furnace by itself.
You are confusing "Publicly Routable" with "Directly Accessible" This is a distinction which cheap consumer-grade "routers" have blurred and it's even starting to seep up into the minds of network engineers.
You can have devices using NAT to RFC-1918 address that are just as "directly accessible" as any other host. Likewise you can have machines with routable addresses that are not in any way connected to the Internet. There are lots of valid reasons to do both depending on the applications, the hardware and the infrastructure.
Woah buddy; important point -- don't forget to de-rate your generator!
If you actually use even close to 80% of your 100A service, that 17kw Kohler running on natural gas is going to fry.
Most gas generators can be fueled with either LP or NG, but when you burn NG, your efficiency is diminished. In addition, utility companies like to keep the BTU content of their gas close to the minimum they are legally allowed, so it's good even to overestimate. Rule of thumb on this is around 15% total below the advertised rating or 5-10% lower than the official NG rating of the generator. For that 17kW Kholer that puts you at around 14kW that you can realistically produce out of that genset at peak.
Also keep in mind that for a number of other reasons, you're not going to be able to get peak power out of that generator for a while after it starts up, and most "standby" generators are not rated for peak power during continuous duty. There is also power factor to consider, as well as some other minor unfavorable types of things that the marketing numbers don't really include, so you really need to de-rate about 10% more to figure the nominal size load you can protect.
SO just being conservative on that Kholer (which you need to be when you are considering an EMERGENCY generator), you could reasonably ask it for 55A or so. That might be sufficient for a whole home without major electric appliances, but it's not going to deal with electric heaters, ovens, clothes dryers, etc. all that well. You'd need either a larger genset or to do some selective circuit protection using a sub-panel.
The title of this post is rather misleading. It implies VirtualBox can run a virtualized 64 bit machine on a 32 bit processor and VMWare cannot. Neither of these are true. It can now host a 64 bit guest VM when the host OS is 32 bits.
Support for 64 bit VM's under 32 bit host OS's has been standard in VMWare's entire line ever since they included 64 bit guest support. Even the service console through ESX 3.5 is a 32 bit VM (Though it's not really fair to call it the "Host" OS)
AFAIK, virtualizing 64 bit guests does still require Intel VT or AMD Pacifica support on the CPU regardless on all products that support 64 bit guests.
The other thing to consider is that these "Tier 1" companies who are also "Last Mile" access providers are huge businesses. It is irresponsible for the "Last Mile" division to rely solely on the "Tier 1" division for access for its customers. Sprint (the ISP that connects customer cellphones to the net) should have an alternative to routing through Sprint (the backbone provider).
I'm not sure whether or not to blame Sprint & Cogent (collectively) or their customers (collectively) for any trouble caused on Oct. 30. They were all getting exactly what they paid (or did not pay) for.
Well OK so others have cleared this up for you -- transit free etc.
So we have these big networks all feeling high and mighty because they are so freaking insistent on remaining transit free; it's ridiculous.
Here's the question that customers should be asking their providers instead of just complaining when things go wrong: If I am paying you for Internet access, how will you handle this type of contingency? If Sprint & Cogent were receiving money from customers for Internet connectivity, Sprint & Cogent should have had paid transit available for their customers. They can blame each other all day long for all anyone cares, but in the end the customer loses. To be basically transit free you have to peer with something like 11 networks or some such these days. When you tell your customers there isn't an alternative and start blaming some other company, you are flat out lying.
Problem is nobody knows to ask so there's no incentive to do it.
Anyone who has taken even a passing glance at Iridium data knows it's 2400bps with stream compression -- it really bothers me that you have apparently looked into using it and don't know this basic spec.
But, on to the problem: You need to manage some gear remotely and the lowest common denominator is 2400 bps. I really don't understand why you can't use a serial device server and forward/reverse telnet to do anything you really need. Windows 2008 "foundation" or "core" or whatever they call it really has made it possible (though horribly un-fun) to manage windows from a command line.
If you absolutely require remote GUI, your best bet will be ICA as it supports direct serial and can run at a functional level at 9600 baud and probably pass in a pinch at 2400. I am not sure if Citrix's PortICA (The version that runs on XP etc.) can be made to support serial connections, but it's worth asking them about. RDP will be quite a bit thicker and requires IP connectivity to work.
Did you replace AD with it or did you create an NT4 style domain? IMO I have never been able to achieve the AD replacement piece despite my best efforts with OpenLDAP and Kerberos and early releases of samba4. The first time anything expects to operate against a "real" active directory be it some remote software trying to authenticate, a NAS/filer, or software that "integrates" with AD, the setup has always fallen on its face. After a few attempts is simply becomes cheaper to deploy AD.
The problem now is that a lot of new hardware and software coming out is getting harder and harder to shoehorn into samba/NT4 style environments. You have to jump through hoops to get it to work and a lot of times you have to sacrifice features or security when you do make it work. So this is a problem in "the enterprise."
But it's starting to get bad with "the consumer" too. When a manufacturer's samba-running $99 NAS box that has worked great for a home user for years suddenly wont work with a new Vista machine it's perceived as microsoft's problem.
Depending on your opinion of the matter, these might or it might not be really Microsoft's fault, but in any case they do have an interest (and by that I mean a financial incentive) in making sure their garbage works with everyone else's garbage.
Don't you think I know Firewire has DMA? I thought we were just talking about a solution to plugging your DV camera into your new macbook; In any case, its not a really big deal at S100 and USB2 could keep up.
DV cameras (and associated transports such as HDV, DVCPRO, etc.) actually operate at S100 (100mbps). It should be possible to construct an interface that lets these low-speed firewire devices operate over USB2. Plus, the protocols themselves are robust enough to deal with a bus problem. Older ibooks often had trouble keeping up capturing firewire video and they recovered just fine. An occasional hiccup shouldnt be a big deal.
I believe this is what apple or a third party vendor should do. It would be a VERY good product. There are readily available USB2 PCI bridge chipsets and PCI firewire chipsets. Such a product coould probably sell for around $100. While it wouldn't work very well for firewire hard drives, USB2 should be able to keep up with S100 if its the only demanding thing on the bus.
Secondly the IEEE1394c draft specifying an RJ45 connector is *not* Firewire over Ethernet. It's Firewire over UTP/Cat5e with some additional tricks that would allow ports to detect either standard and switch between gigabit ethernet and firewire as needed. I have been hoping for this standard to take off for a long time (It could be really neat in low end storage networks), but I'm not going to hold my breath.
Re:Not hard to get...
on
Chrome Vs. IE 8
·
· Score: 5, Informative
The overlapping memory pages is kinda cool, but your computer actually is using all of that RAM you installed
This is not entirely true. Normally the BIOS will remap IO address space above system RAM, but on 32 bit hardware (with or without PAE), the BIOS will generally reserve a hole somewhere between 3GB and 4GB. Depending on your specific hardware, this hole might be pretty big. For instance, if you have a 512MB video card, that memory gets mapped into the system address space, and you lose the same amount of system RAM for the privilege. There are some BIOS that will allow you to map this memory above 4GB but drivers sometimes flake out when you do that; plus you have to run a 64bit OS at that point too.
which is why you can see computers in Circuit City running 32-bit Vista and reporting 4 GB (or more) of memory.
You will never see a 32 bit vista machine report more than 4GB of ram as it's simply not supported. (Makes you wonder why they turn on PAE by default since it slows down memory access?? A vendor turning PAE off is probably just smart.) You will, however, see vista report 4gb in the computer properties -- but it's more of a marketing trick. 32 bit windows will only allocate 2GB of address space to user processes anyway and 3GB only with a special boot switch (that you have to be careful with.)
As far as your claim that some cheap motherboards do not connect the PAE pins, that's also somewhat misleading too -- the pins are all there anyway -- its just the feature was left out of cheap junk northbridge chipsets... but this was back in the Pentium III days. It's very doubtful you can even find a board anymore that does not support PAE; especially since pretty much all current model CPU's have 64 bit support.
You are simplifying the problem enormously and taking for granted the complexity of making computer time work right especially in VM's. VMware has a whitepaper that is a pretty substantial read, but in your simplistic view, let's say your timekeeping is based on a periodic interrupt that fires, say, 1000 times per second. Well, for some tasks that is not even sufficient because you might do one hundred times that many context changes in the same time, so in effect even if you have an interrupt source, you still need a more precise timekeeping mechanism. So you have things like jiffies in Linux and a whole host of other junk that tries to keep everything in sync. So what about reading the RTC? How are you going to keep time while you talk to that clock over the legacy bus? How are you going to deal with the hardware clock's own skew? But when you add a VMM on top of things you can't even guarantee that you can send 1000 interrupts to the VM every second, nor can you ensure that its more precise timekeeping functions will hold up when cycles are stolen. Emulating the RTC is possible, but due to the way it works, it's not efficient to do this in a VM anyway.
Currently the best way to do timekeeping in vmware is via paravirtualization and running an NTP client in the VM. Paravirtualization allows the guest to understand when cycles are stolen and compensate for clock skew itself. Unfortunately there isn't a magic bullet solution like that for Windows guests yet, but I suspect once Hyper-V really starts to flub on the time things that MS will be forced to put some kind of clock hooks in there that vmware or anyone can take advantage of... might be a while though.
I have posted a reply to your message. You can view my reply via the internet at slashdot.org using Message ID v0h2w03na0sdfah0wn0vfsn and password 92pxzgf230nv0ng2ydzp
Slashdot Mirror
http://en.wikipedia.org/wiki/Luminous_efficacy
If the data there is current, LED's max around 100 lm/W (15%), CFL's around 72 lm/W (11%), high efficiency fluorescent around 120 lm/W (18%) and things like low pressure sodium (orange-hued street lamps and the like) around 200 lm/W (29%). Incandescent hang out in the 5 - 18 lm/W range (~ 2.5%)
So right now in commercial products, the expensive LED based bulbs built with very good LEDs offer about the same performance as CFL's and usually are outperformed by your standard fluorescent fixtures. They do actually last a great deal longer and are arguably more environmentally friendly. They are easily justified by any installation where changing a bulb costs considerably more than the bulb (such as commercial installations requiring scaffolding to accomplish the feat). However the LED bulbs you can find in the retail stores these days that represent that a 5W LED bulb compares to a 13W CFL and a 100W incandescent are telling absolute lies. Then again, most retailers wouldnt dare put a decent $120 LED bulb on the shelf either - it simply wouldn't sell.
IMO the whole system for advertising bulbs is broken. If there's going to be any change to the laws about lighting it should not be to ban the sale of incandescents but to require better labeling. If bulb packaging were required to display the luminous output, the power consumption, and the color temperature we'd all be better off. There is some other useful information they could put in there too such as PF, weight, hazmat, lifetime, etc. -- sort of a "Nutritional Information" for bulbs. They already require similar labeling on appliances but I could see this type of requirement really helping out on power consumption. Once that garbage battery charger has to actually put a label on its box that says it ships with a crap 10% efficient wall wart that draws 300mA idle is the day it will instead start shipping with a better power supply.
The CA certificate system isn't supposed to be a 'web of trust' though. It COULD be but honestly users wouldn't make the effort. Most PGP users don't bother with the 'web of trust' either anymore which is why it's all but dead. Allowing companies to become authoritative CAs for their own domains is a good solution in theory, but the end user still needs someone to step in and help them do the identity proofing because, again, they won't make the effort; plus how do you secure it? DNS? Whois? Have them buy CA certs? All of these have flaws. Does the current system suck? A little bit - maybe about as much as the current system for domain registration, but
A company can already become a CA if it wants to and have users choose to trust them or install their CA certs on end users machines or use them within their own applications. Many enterprises run internal CAs anyway. In your example there is really nothing preventing capitalone from distributing a small installer that makes them a trusted CA same as Verisign or any of the others whose CA certs are bundled with the browsers. But if you think that these companies who are too already too disorganized to correctly author and secure their current web apps are going to go through the rigamarole of running their own CA and talking their users through trusting them? You are just talking crazy.
FWIW there is apparently malware that already does this -- a CA cert, a hostfile entry and suddenly paypal.com is showing green bars on nigerian servers no problem.
This is pretty much the only comment needed in this thread. I came to post basically the same two links.
Due to memory overcommit, ESX or the free ESXi on a whitebox is really the only viable lab platform to play with this kind of thing at home (or even at work) without breaking the bank. When you look at *any* other vm platform you can't test complicated infrastructure or scaling/paralleling techniques inside of 8GB. Once you start needing 16GB+ ram for your experiments, you start either run out of DIMM slots on most consumer-level boards and have to look at server motherboards -- or you have to shell out for 4GB DIMMS -- either way you start running into expensive territory.
S3's transfer fees start at 17c to 10TB/mo. and decline to 10c at 150TB/mo. At the volumes we are talking about for game downloads at ~1-2GB each download you'd easily be at the top end.
And amazon isn't really that cheap either when it comes down to content delivery. It's nice because it's more or less on demand but if you can do a little bit of forward planning, a content delivery network like Akamai can give you better pricing.
Anyway the article is a stupid gripe about a nonexistent problem. Microsoft doesn't charge the publisher bandwidth fees because they choose to charge the customer. Furthermore anyone who thinks they can do it for "free" on their own website is under some serious delusions. A publisher unable to budget for this correctly is a bad publisher. I think perhaps they are just pissed because they can't provide the service and charge for the bandwidth themselves - I bet they would charge a lot more than 16c/GB.
Sony picked a price and terms that are reasonable and cost competitive in the market. There are some ways around it too - game downloads from PSN could contain only skeleton executable files which would download the rest of the data on first start from a publisher's own content servers. The fact that we're not seeing any of this is probably because it's just not that big of a deal. $200K in bandwidth fees to expose a million people or more to your game demo is money well spent. It comes out of the advertising budget and will give a better return than $200K spent on billboards, that's for sure.
No CA is (currently) issuing wildcard EV certs. I personally understand the convenience of the wildcard cert, but I do also accept and support the practice of disallowing wildcards in high security applications.
EV certificates are available with multiple Subject Alternative Names, though so the whole "dropped www." or a couple of virtual shouldn't be a big deal if things are done correctly. Unfortunately they aren't and some sites (paypal) that are using EV SSL certs don't even bother with this simple feature.
The correct failsafe implementation which will always result in a no-prompt situation is to ensure that you only deploy EV certificates on an IP addresses that have only one DNS name. You then deploy a frontend redirection server on a second IP using a wildcard SSL cert that occupies the alternative dns names for the namespace of the original app. This server will pass cert checks more easily and then redirect to the EV server with its specific dns name which will then show the green bar. Any existing deep links to the application on an incorrect DNS name will be handled correctly and any direct references will work in the future. There are of course implications for securing said redirection proxy, but they aren't really that hard to overcome.
The dealership always gets all the money right away unless they carry the note themselves; and honestly, the only dealerships I've seen still doing that are the insanely shady "Auto Sales & Finance" type places that are likely to pack a clunker's radiator with eggs and sawdust then force it on a poor person so that they can beat $100 out of them every month. The reputable dealerships have figured out that it's much easier and better to find a couple banks to handle this dirty work for them.
Buying a car on an Amex)is actually a pretty good idea. Amex has all kinds of good buyer protections that can really save your ass when you need them. Note though that I'm talking about a real "charge card" amex not one of those new stupid blue ones that let you carry a balance and otherwise abuse it.
So, if your friend bought the car on *his* Amex, you might give his "supidity" a second thought. However, I would think it's rather unlikely that anyone in college could have earned an amex capable of purchasing a car without some kind of assistance -- was it his dad's Amex? That's a bit different.
Actually it sounds like they have a transparent web proxy that is malfunctioning. You can probably request that your traffic not be sent through the proxy.
Yes; this discrepancy is accounted for in two ways:
1) The burst rate allows the 12mb connection to achieve the ~22mb rates for a brief period of time
2) The XP box cannot achieve > 10-12 mb on this particular connection; most probably due to the way the TCP window scaling is limited in the default configuration. This particularly affects high bandwidth, high latency connections, particularly when peak available bandwidth is irregularly available. There is also likely a problem where selective ACKs are not being properly used and XP may be saturating the smaller upstream bandwidth.
All programs are smart enough to guess the upstream bandwidth. It's a basic built-in feature of TCP. It would usually be considered best practice not to implement any kind of rate limiting logic in the app and instead simply rely on TCP to do what it's supposed to. The problem is that (in general) consumer-grade routers use FIFO-type queuing implementations that are terrible for asynchronous connections like most people have.
"Smart applications", QoS and traffic shaping are really not the first line of defense here. The real solution is for consumer routers to implement better queuing algorithms such as WFQ or WRED so that when you want to start applying QoS and traffic shaping, they actually have the ability to do what they are supposed to. None of that stuff is going to help you when you have FIFO queues on your crappy little router and you experience congestion upstream of your connection -- the only way you can provide traffic control with a FIFO queue is to flat out keep the packets out of it.
When you put it that way, why bother with lights when you can burn candles, heat when you can just make a fire, and a fridge when you can just preserve everything in brine? Electronics, seriously? All you need is a thermometer, barometer, and a pair of eyes!
Anwyay, it was just an example of a "major appliance" and in any case it would still use less power by itself than running an electric stove or oven and electric furnace at the same time - probably less than an electric furnace by itself.
You are confusing "Publicly Routable" with "Directly Accessible" This is a distinction which cheap consumer-grade "routers" have blurred and it's even starting to seep up into the minds of network engineers.
You can have devices using NAT to RFC-1918 address that are just as "directly accessible" as any other host. Likewise you can have machines with routable addresses that are not in any way connected to the Internet. There are lots of valid reasons to do both depending on the applications, the hardware and the infrastructure.
Woah buddy; important point -- don't forget to de-rate your generator!
If you actually use even close to 80% of your 100A service, that 17kw Kohler running on natural gas is going to fry.
Most gas generators can be fueled with either LP or NG, but when you burn NG, your efficiency is diminished. In addition, utility companies like to keep the BTU content of their gas close to the minimum they are legally allowed, so it's good even to overestimate. Rule of thumb on this is around 15% total below the advertised rating or 5-10% lower than the official NG rating of the generator. For that 17kW Kholer that puts you at around 14kW that you can realistically produce out of that genset at peak.
Also keep in mind that for a number of other reasons, you're not going to be able to get peak power out of that generator for a while after it starts up, and most "standby" generators are not rated for peak power during continuous duty. There is also power factor to consider, as well as some other minor unfavorable types of things that the marketing numbers don't really include, so you really need to de-rate about 10% more to figure the nominal size load you can protect.
SO just being conservative on that Kholer (which you need to be when you are considering an EMERGENCY generator), you could reasonably ask it for 55A or so. That might be sufficient for a whole home without major electric appliances, but it's not going to deal with electric heaters, ovens, clothes dryers, etc. all that well. You'd need either a larger genset or to do some selective circuit protection using a sub-panel.
The title of this post is rather misleading. It implies VirtualBox can run a virtualized 64 bit machine on a 32 bit processor and VMWare cannot. Neither of these are true. It can now host a 64 bit guest VM when the host OS is 32 bits.
Support for 64 bit VM's under 32 bit host OS's has been standard in VMWare's entire line ever since they included 64 bit guest support. Even the service console through ESX 3.5 is a 32 bit VM (Though it's not really fair to call it the "Host" OS)
AFAIK, virtualizing 64 bit guests does still require Intel VT or AMD Pacifica support on the CPU regardless on all products that support 64 bit guests.
The other thing to consider is that these "Tier 1" companies who are also "Last Mile" access providers are huge businesses. It is irresponsible for the "Last Mile" division to rely solely on the "Tier 1" division for access for its customers. Sprint (the ISP that connects customer cellphones to the net) should have an alternative to routing through Sprint (the backbone provider).
I'm not sure whether or not to blame Sprint & Cogent (collectively) or their customers (collectively) for any trouble caused on Oct. 30. They were all getting exactly what they paid (or did not pay) for.
Well OK so others have cleared this up for you -- transit free etc.
So we have these big networks all feeling high and mighty because they are so freaking insistent on remaining transit free; it's ridiculous.
Here's the question that customers should be asking their providers instead of just complaining when things go wrong: If I am paying you for Internet access, how will you handle this type of contingency? If Sprint & Cogent were receiving money from customers for Internet connectivity, Sprint & Cogent should have had paid transit available for their customers. They can blame each other all day long for all anyone cares, but in the end the customer loses. To be basically transit free you have to peer with something like 11 networks or some such these days. When you tell your customers there isn't an alternative and start blaming some other company, you are flat out lying.
Problem is nobody knows to ask so there's no incentive to do it.
Anyone who has taken even a passing glance at Iridium data knows it's 2400bps with stream compression -- it really bothers me that you have apparently looked into using it and don't know this basic spec.
But, on to the problem: You need to manage some gear remotely and the lowest common denominator is 2400 bps. I really don't understand why you can't use a serial device server and forward/reverse telnet to do anything you really need. Windows 2008 "foundation" or "core" or whatever they call it really has made it possible (though horribly un-fun) to manage windows from a command line.
If you absolutely require remote GUI, your best bet will be ICA as it supports direct serial and can run at a functional level at 9600 baud and probably pass in a pinch at 2400. I am not sure if Citrix's PortICA (The version that runs on XP etc.) can be made to support serial connections, but it's worth asking them about. RDP will be quite a bit thicker and requires IP connectivity to work.
Did you replace AD with it or did you create an NT4 style domain? IMO I have never been able to achieve the AD replacement piece despite my best efforts with OpenLDAP and Kerberos and early releases of samba4. The first time anything expects to operate against a "real" active directory be it some remote software trying to authenticate, a NAS/filer, or software that "integrates" with AD, the setup has always fallen on its face. After a few attempts is simply becomes cheaper to deploy AD.
The problem now is that a lot of new hardware and software coming out is getting harder and harder to shoehorn into samba/NT4 style environments. You have to jump through hoops to get it to work and a lot of times you have to sacrifice features or security when you do make it work. So this is a problem in "the enterprise."
But it's starting to get bad with "the consumer" too. When a manufacturer's samba-running $99 NAS box that has worked great for a home user for years suddenly wont work with a new Vista machine it's perceived as microsoft's problem.
Depending on your opinion of the matter, these might or it might not be really Microsoft's fault, but in any case they do have an interest (and by that I mean a financial incentive) in making sure their garbage works with everyone else's garbage.
Replying to myself here because something like this actually exists:
http://www.usbfirewire.com/Parts/rr-527950.html
There is no OS X support from this product and no generic device support, but clearly this sort of thing is completely possible.
Don't you think I know Firewire has DMA? I thought we were just talking about a solution to plugging your DV camera into your new macbook; In any case, its not a really big deal at S100 and USB2 could keep up.
A couple of points:
DV cameras (and associated transports such as HDV, DVCPRO, etc.) actually operate at S100 (100mbps). It should be possible to construct an interface that lets these low-speed firewire devices operate over USB2. Plus, the protocols themselves are robust enough to deal with a bus problem. Older ibooks often had trouble keeping up capturing firewire video and they recovered just fine. An occasional hiccup shouldnt be a big deal.
I believe this is what apple or a third party vendor should do. It would be a VERY good product. There are readily available USB2 PCI bridge chipsets and PCI firewire chipsets. Such a product coould probably sell for around $100. While it wouldn't work very well for firewire hard drives, USB2 should be able to keep up with S100 if its the only demanding thing on the bus.
Secondly the IEEE1394c draft specifying an RJ45 connector is *not* Firewire over Ethernet. It's Firewire over UTP/Cat5e with some additional tricks that would allow ports to detect either standard and switch between gigabit ethernet and firewire as needed. I have been hoping for this standard to take off for a long time (It could be really neat in low end storage networks), but I'm not going to hold my breath.
This is not entirely true. Normally the BIOS will remap IO address space above system RAM, but on 32 bit hardware (with or without PAE), the BIOS will generally reserve a hole somewhere between 3GB and 4GB. Depending on your specific hardware, this hole might be pretty big. For instance, if you have a 512MB video card, that memory gets mapped into the system address space, and you lose the same amount of system RAM for the privilege. There are some BIOS that will allow you to map this memory above 4GB but drivers sometimes flake out when you do that; plus you have to run a 64bit OS at that point too.
You will never see a 32 bit vista machine report more than 4GB of ram as it's simply not supported. (Makes you wonder why they turn on PAE by default since it slows down memory access?? A vendor turning PAE off is probably just smart.) You will, however, see vista report 4gb in the computer properties -- but it's more of a marketing trick. 32 bit windows will only allocate 2GB of address space to user processes anyway and 3GB only with a special boot switch (that you have to be careful with.)
As far as your claim that some cheap motherboards do not connect the PAE pins, that's also somewhat misleading too -- the pins are all there anyway -- its just the feature was left out of cheap junk northbridge chipsets... but this was back in the Pentium III days. It's very doubtful you can even find a board anymore that does not support PAE; especially since pretty much all current model CPU's have 64 bit support.
You are simplifying the problem enormously and taking for granted the complexity of making computer time work right especially in VM's. VMware has a whitepaper that is a pretty substantial read, but in your simplistic view, let's say your timekeeping is based on a periodic interrupt that fires, say, 1000 times per second. Well, for some tasks that is not even sufficient because you might do one hundred times that many context changes in the same time, so in effect even if you have an interrupt source, you still need a more precise timekeeping mechanism. So you have things like jiffies in Linux and a whole host of other junk that tries to keep everything in sync. So what about reading the RTC? How are you going to keep time while you talk to that clock over the legacy bus? How are you going to deal with the hardware clock's own skew? But when you add a VMM on top of things you can't even guarantee that you can send 1000 interrupts to the VM every second, nor can you ensure that its more precise timekeeping functions will hold up when cycles are stolen. Emulating the RTC is possible, but due to the way it works, it's not efficient to do this in a VM anyway.
Currently the best way to do timekeeping in vmware is via paravirtualization and running an NTP client in the VM. Paravirtualization allows the guest to understand when cycles are stolen and compensate for clock skew itself. Unfortunately there isn't a magic bullet solution like that for Windows guests yet, but I suspect once Hyper-V really starts to flub on the time things that MS will be forced to put some kind of clock hooks in there that vmware or anyone can take advantage of... might be a while though.
Really, have you never been to a trade show? Convention centers often charge these kinds of rates PER DAY.
I have posted a reply to your message. You can view my reply via the internet at slashdot.org using Message ID v0h2w03na0sdfah0wn0vfsn and password 92pxzgf230nv0ng2ydzp