Insteon uses a different protocol, and is not solely reliant on the powerlines, since it also transmits via RF for units that are RF-capable. In addition every Insteon device acts like a network router that retransmits messages that are not addressed to itself (with a TTL to avoid congestion). All messages are ACKed, or retried if not ACKed.
This means that you can have several SignalLincRF repeaters positioned at strategic locations (I have 4, but you can get away with 2 -- one on each phase of your your home wiring, creating a bridge across the different phases). If a message would not ordinarily be able to travel across the powerlines from one side of the house to the other, the SingalLincRFs will bridge the message across the RF link, to be retransmitted on the other 'spur' of your wiring.
Insteon devices can be 'linked' with other Insteon devices (or X10) devices, to create complex sequences or 'mood' settings. Bright levels and ramp rates are configurable.
In my house Insteon works almost flawlessly, where X10 barely worked at all, but noise is still an issue and you still need filters on noisy equipment like computers, motors, fridge etc.
Smarthome also has a pretty good developer kit with a PLC and an SDK for writing drivers or apps. The developer community is small but growing.
Way to go. You've reduced OOP down to 1970's-style procedural programming, neatly avoiding all those pesky benefits associated with encapsulation and polymorphism.
Admittedly I generalised (but then I'm a programmer -- I'm used to it), but you've taken one line from my post and pegged me a some kind of Linux fanboy. Maybe I should have used the phrase "by-and-large" in there somewhere.
It's ironic, because I started out with a lot of sympathy with the original article, having just recently installed Fedora FC4 on my old Dell Inspiron 9100. That went quite smoothly except for the wireless card, which took me two weeks, a kernel rebuild and some script programming to figure out. I can't imagine my electrician brother being able to do the same, whereas he has installed Windows several times.
My original point (restated) to the parent poster was that most people are Windows people because of the following:
a) most people are Windows people (i.e the phenomena is self-fulfilling)
b) it's easier (probably as a direct result of a.)
It wasn't my intention to be discourteous or judgemental to Windows users, because I am myself predominantly a Windows user, for much the same reasons as you are. I'm just tired of being a Windows user.
Most people wouldn't trust their lives to an airplane if all of the internals mechanics were showing.
They would if they had to get across the Atlantic in six hours, and had a hundred years of precedent that showed that flying across the Atlantic in a glass airplane was quite safe, relatively speaking.
The point being that people, by-and-large, make decisions based on their innate sense of risk and reward. Linux users are happy to take more risk, and their reward is more knowledge. Windows users want little risk, and find little reward in knowing how their tools work.
The dirty little secret is that the risks are actually the same for both user bases, but the perception of risk can be altered by Marketing.
In C# (I don't do VB anymore - thank f*** for that) "edit-and-continue" is working fine for me. Only meta-data changes require a restart, and that was pretty much the case with VB6 too, if I remember correctly.
The registry, as a place to keep application configuration, is fairly uncontroversial. But the the registry is a whole lot more than that. It's the nexus for COM and ActiveX (without it these won't function), and becomes essentially one big "code lookup" database -- and this is what makes it more vulnerable.
When COM/ActiveX makes way for the.NET Framework (with Longhorn/Vista?) expect the registry to go away too (or at least be relegated to some kind of sandboxed emulation layer), and then there's no reason why application configuration and user settings could not be kept in suitably ACL'd XML policy files.
...let's define 'journalist' as anyone who registers with the government and receives a 'licence to journalistify'. We can give them a little card, stamp the backs of their heads with a barcode and put RFID chips in their skulls, then let them 'free press' away to their hearts' content. Of course, if they do something we don't like...
Right. I'd be happy to take personal responsibility for the code I write for my employer, as long as I get: a) a direct and substantial cut of the profit and b) the code I write belongs to me, not them, and I take it with me when I quit or get fired. I will, of course, licence it back to them for a 'reasonable' fee...
Slashdot Mirror
Too true. Another one that always gets me is "Save upto 50% or more"
Insteon uses a different protocol, and is not solely reliant on the powerlines, since it also transmits via RF for units that are RF-capable. In addition every Insteon device acts like a network router that retransmits messages that are not addressed to itself (with a TTL to avoid congestion). All messages are ACKed, or retried if not ACKed.
This means that you can have several SignalLincRF repeaters positioned at strategic locations (I have 4, but you can get away with 2 -- one on each phase of your your home wiring, creating a bridge across the different phases). If a message would not ordinarily be able to travel across the powerlines from one side of the house to the other, the SingalLincRFs will bridge the message across the RF link, to be retransmitted on the other 'spur' of your wiring.
Insteon devices can be 'linked' with other Insteon devices (or X10) devices, to create complex sequences or 'mood' settings. Bright levels and ramp rates are configurable.
In my house Insteon works almost flawlessly, where X10 barely worked at all, but noise is still an issue and you still need filters on noisy equipment like computers, motors, fridge etc.
Smarthome also has a pretty good developer kit with a PLC and an SDK for writing drivers or apps. The developer community is small but growing.
Way to go. You've reduced OOP down to 1970's-style procedural programming, neatly avoiding all those pesky benefits associated with encapsulation and polymorphism.
Admittedly I generalised (but then I'm a programmer -- I'm used to it), but you've taken one line from my post and pegged me a some kind of Linux fanboy. Maybe I should have used the phrase "by-and-large" in there somewhere.
It's ironic, because I started out with a lot of sympathy with the original article, having just recently installed Fedora FC4 on my old Dell Inspiron 9100. That went quite smoothly except for the wireless card, which took me two weeks, a kernel rebuild and some script programming to figure out. I can't imagine my electrician brother being able to do the same, whereas he has installed Windows several times.
My original point (restated) to the parent poster was that most people are Windows people because of the following:
a) most people are Windows people (i.e the phenomena is self-fulfilling)
b) it's easier (probably as a direct result of a.)
It wasn't my intention to be discourteous or judgemental to Windows users, because I am myself predominantly a Windows user, for much the same reasons as you are. I'm just tired of being a Windows user.
It's ridiculously expensive (~$11k for what was previously MSDN Universal): http://msdn.microsoft.com/vstudio/howtobuy/default .aspx
In C# (I don't do VB anymore - thank f*** for that) "edit-and-continue" is working fine for me. Only meta-data changes require a restart, and that was pretty much the case with VB6 too, if I remember correctly.
The registry, as a place to keep application configuration, is fairly uncontroversial. But the the registry is a whole lot more than that. It's the nexus for COM and ActiveX (without it these won't function), and becomes essentially one big "code lookup" database -- and this is what makes it more vulnerable. When COM/ActiveX makes way for the .NET Framework (with Longhorn/Vista?) expect the registry to go away too (or at least be relegated to some kind of sandboxed emulation layer), and then there's no reason why application configuration and user settings could not be kept in suitably ACL'd XML policy files.
...let's define 'journalist' as anyone who registers with the government and receives a 'licence to journalistify'. We can give them a little card, stamp the backs of their heads with a barcode and put RFID chips in their skulls, then let them 'free press' away to their hearts' content. Of course, if they do something we don't like...
Right. I'd be happy to take personal responsibility for the code I write for my employer, as long as I get: a) a direct and substantial cut of the profit and b) the code I write belongs to me, not them, and I take it with me when I quit or get fired. I will, of course, licence it back to them for a 'reasonable' fee...