Firewire has DMA. So does eSATA. I don't see anyone whining about DMA there. In fact, they'd whine if eSATA didn't support DMA. And there are methods available on both busses to require devices to be authorized before DMA requests work.
Firewire is also a master-less system. USB can only connect one master to multiple slaves. This is why you can't connect your camera to your phone or visa versa -- both devices are setup as slaves and can only connect to a host. This also means you can't connect two computers together via USB, as they are both masters. Firewire works like SCSI or Ethernet, where all devices are peers -- any FW device can talk to any other FW device on the same bus. You can even interconnect electrical busses with relatively intelligent routing to give you multiple collision domains while maintaining connectivity among a large number of devices. This again is a feature -- if your computer, phone, and camera all had FW instead of USB you could connect them in arbitrary combinations and still have them work. You can also use FW for IP networking and other Ethernet-like functions (and in fact modern FW provides support for cat-5 connectors that automatically switch between FW and Ethernet).
Nobody -- not even MS -- thinks SMB was a good file-sharing protocol. It became popular only because it was the only option available for MS clients. And even MS ditched it more or less as soon as they figured out that network file systems would be the normal way of doing business rather than some transient storage used to replace sneakernet.
CIFS is a better choice, though still not ideal. It's acceptable for many user-oriented filesystem mounts, but it has several limitations (some of which can be avoided if you run samba at both ends) in terms of permissions/etc. for POSIX systems, and it offers no multi-user mounting options, which are still quite useful for things like sharing applications folders. CIFS is a reasonable choice but I think most people would agree it's popularity is mostly due to its compatibility with MS clients, not its technical superiority to alternative network filesystems.
2 MW is a *lot* of power, even for large commercial installations. And it requires a lot more infrastructure to ship electricity than liquid fuel.
It's not unreasonable to think that electric cars might charge at power stations instead of at home, but high-speed charging is not a feasible next-step in the process.
No, no, no. The president has to physically enter the launch codes on the ground-test keyboard. If he's not there to enter the codes in person the entire Earth will be destroyed.
Then after the crisis he marries the whale lady and they produce a progeny with an uncanny ability to stay on-message in the A, B, and C plots no matter how boring that makes an already-preachy show. But thanks to his previous merger with god/borg/etc. he somehow manages to keep the mess on-air for the better part of a decade anyway.
There's only one reason to buy Apple -- so you can run UNIX and still watch flash videos. I like UNIX. I spend most of my day with at least one terminal open. But I'd still like to able to use closed-source software without jumping through hoops or rebooting into another OS. I did desktop linux for years but I eventually concluded it was cheaper to buy a Mac than fight with linux.
That's about the long and short of it. Bronze was more economically viable given the complexities of making iron. Iron was better in some ways, but it wasn't enough better to be worth the effort.
Of course, that viewpoint dismisses the new things we learned to do with iron once it was readily available, but that's true of all new technologies. Before we invented the microchip no one thought very hard about how office paperwork might be better if only we had a better information storage technology than paper -- computers existed and could have been used for that purpose but they were so expensive and impractical that no one though about using them for typing form letters.
It's in the wrong orbit to do anything other than be reachable by launches from mainland Russia. It's not like no one ever thought of using the space station as a jumping-off point before, it's just that such ideas were made more or less impractical as soon as we decided to put the space station in this silly orbit.
Until you open windows in two different programs that use that retarded window-in-a-window scheme that MS won't kill. Then your desktop is covered by an ugly grey box that bots out whatever other windows might otherwise be available behind it and you must switch programs to see different sets of windows, or hide them to see the desktop.
Seatbelts are rarely used without some sort of transport vehicle. Does that mean "seatbelt" and "vehicle" are synonyms?
Stop being a douche and just accept that fact that we could sell grandma (or build into her cable modem, OS, etc.) a stateful firewall that provides exactly the same protection *without* NAT.
For the 1000th time, it is possible to form an internet without being directly connected to the Internet, and any time you do that you need address coordination. When all your networks are internal it's plausible to do that in RFC-1918 space. But as soon as you introduce the possibility of an outside entity, it's much, much easier to use your guaranteed-to-be-globally-unique IP address than hope that every organization on your network agrees about who should have which addresses.
Or consider this situation -- *your* local network is not directly connected to the Internet, but you subscribe to a service that requires a LAN-LAN connection and *their* computer are connected to the Internet. Let's say they sell this same service to more than one customer. Does it really seem unreasonable that they want all of their LAN-LAN connections to be globally routable, or to use real IP addresses to make that happen?
There are good reasons to do that even ignoring all the "it is sometimes useful to have a real, end-to-end network connection" bit.
Here's one that I've actual had problems with. Company A needs a LAN-LAN VPN with company B. Company A and company B are both using the same RFC-1918 address space. Who gets to renumber their network to make this connection work? The answer is often "neither, but instead we have to setup some NAT and/or proxy service to pretend we have non-1918 addresses", which then A) actually consumes the addresses anyway, B) makes access controls about 6 times harder, and C) requires actually setting up the proxy and/or NAT system in addition to the tunnel and access controls.
Or perhaps a more common one -- company A buys company B and wants to merge their networks. If everyone was just using real addresses in the first place this would be a trivial task. If they're both using the same RFC-1918 space however, it means one end *must* renumber to accommodate the other.
"Cross platform" as in "closed source, closed spec, happens to have a runtime for certain version of linux on certain hardware running certain distributions"
It is, which is somewhat unfortunate, but it's more or less by design to maintain compatibility.
Because ObjC is orthogonal to C/C++ it can't use any of the traditional notation. It's perfectly legal to mix a standard method call:
obj->method(argument); with a ObjC message:
[obj2 method: argument]; in the same file.
It would be pretty hard to hack the meter if the pins just output a blip (or change polarity, or any other binary indicator) for every X units of energy are consumed, which is all the information the meter really provides in the first place. That sort of signal could be read directly by a serial port if you really didn't want to build an interface, or converted to a real digital signal with a pretty trivial circuit.
That being said, it's not that difficult to build a circuit that optically reads the LCD "wheel" indicator and blips when it goes around.
FB is invaluable to people trying to attract attention or track their fans/customers/etc. As a business or a group seeking publicity it's a great tool -- it's another way to broadcast information, beyond the traditional confines of TV/etc., and it provides tracking information.
Of course, all that has little to do with how most people use it, and certainly has nothing to do with using FB as a directed communications system, in preference to email or the other alternatives.
Re:Email does NOT work fine
on
Facebook Is Down
·
· Score: 0, Troll
How can you be sure your FB messages aren't sent to the void by their filters?
You are preaching to the choir. I was pointing out there isn't much difference between sending email or a Facebook message except for some people's misguided view that email is somehow vastly superior to a FB message. I know FB is more convenient for some things than email - I use it for this purpose all the time.
Those who do not understand SMTP are doomed to re-implement it, poorly. And SMTP isn't that good to start with.
I'm a little confused as to why people change email addresses at all, but I'll just assume that really happens. I'm even more befuddled by the idea that the rate of email address changes among a group of people who regularly communicate is high enough to justify a lack of information ownership for the benefit of automated tracking. But again, I'll just assume that's a real thing too.
Facebook as an address book is useful, if for no other reason than it allows coordination and reduced effort among parties wishing to share contact information. That's hardly a new idea -- online address books have been around since the web was young -- and I'm not sure it's any more useful than a public LDAP server (and in many ways it's less useful, since there's no way to export info from FB, or integrate it with your email client/phone/etc.) but it is at least a genuine benefit, even if it's mostly from network effect.
And as others have noted, their RSVP system is handy if you're trying to organize a bunch of people, so I can give you that. They're not the only option for this, but they're free and easy to use and many people already have accounts there, so I can see using FB for RSVP purposes.
But why people think FB is useful as an actual directed communications system is beyond me though. Maybe it's the lack of a data export system -- they would use another system if FB let them get at their address book. With very few exceptions, FB messaging systems are comprehensively *less* rich than the alternatives, including email, and are subject to more data-mining or other monitoring or loss of privacy.
The same applies to their "Wall" and other broadcast communications features. Those same things are available at about 152,382,544 other systems on the Internet, including blogs, message boards, UUCP, and any of the the dozens of other types of services developed to meet this exact need for the past 25 years. Facebook adds exactly nothing to this sort of service; many others are at least as good, and many can offer respite from ads and data-mining, not to mention superior access controls and privacy.
I'm not saying no one should use FB, or that is has no benefits. But I have trouble believing that a typical person, given access to and an understanding of the alternatives, would prefer FB for most types of communications.
We'd probably have to rent all our phone equipment from AT&T, who would be in no hurry to update their network or services from what they originally installed. Or don't your remember telephony before the breakup?
since they are stopping at my house anyways it has to be more fuel efficient to throw a disc on a plane (few ounces) than for me to drive 10+ miles
That's the part of this study I can't figure out. I know delivery trucks are not uber-efficient from a MPG perspective, but they carry lots of packages and have relatively high density delivery routes, at least when compared to the single-destination shopping that most people do. How can it possibly be more efficient on a per-item basis to drive the store, pick up the item, and drive back, than to add a 1 pound and 1 stop to an existing delivery route? Or does this study compare non-vehicular shopping trips to delivery services?
Modern scanners require moving your finger across a static scan line rather than moving the scan line across a static panel. Besides being smaller and using less power and moving parts, this also removes and possibility of lifting prints from the scanner itself.
Please don't conflate "biometerics as a stand-alone authenticator" with "biometrics as a second authentication factor". It's pretty reasonably to combine a physical token with biometrics, because you *can* deactivate/replace/rekey the physical token pretty easily. It's important that the authentication system includes some revokable factor, and ideally you'd also have a PIN or other knowledge-based authentication token, but physical + biometric is not a bad start, and can form a perfectly usable, revokable system.
And it's certainly not a bad system compared to the current "physical only" authentication currently in place.
Your fingerprints can't be changed, but they can't be as trivially reproduced as a password either. I agree, someone *could* steal your fingerprints and reproduce them in some useable way, though it would take a higher level sophistication than simply stealing your card or copying your password. And if someone stole your fingerprints and your card you could simply deactivate the stolen card and have a new one issued. The person with your fingerprints would then have a copy of your fingerprints and a useless credit card dongle. He'd need to steal your physical credit card all over again in order to use make use of his copy of your fingerprints.
x264 on my 8-core box will do 1080p at bitrates comparable to the Blu-Rays I have at about 2x real time. There's no reason to believe I couldn't build a box with 16+ cores and get real-time encoding without any particularly special hardware.
As for quality, I couldn't say objectively, as I don't have access to these "good AVC encoder"s you talk about to do a comparison. It's certainly possible they do a better job. Though I have to question the value of the extra quality, compared to the extra encoding time required. Then again, I have to question the importance of encoding time for a one-time pre-manufacturing process. Certainly it's nice to be done faster, and occasionally there are tight deadlines, but is there really a lot of demand for same-day encoding? Could you just buy 3x as many machines that run at 1/3 the speed and start a little earlier?
Slashdot Mirror
You're talking about two different things.
Firewire has DMA. So does eSATA. I don't see anyone whining about DMA there. In fact, they'd whine if eSATA didn't support DMA. And there are methods available on both busses to require devices to be authorized before DMA requests work.
Firewire is also a master-less system. USB can only connect one master to multiple slaves. This is why you can't connect your camera to your phone or visa versa -- both devices are setup as slaves and can only connect to a host. This also means you can't connect two computers together via USB, as they are both masters. Firewire works like SCSI or Ethernet, where all devices are peers -- any FW device can talk to any other FW device on the same bus. You can even interconnect electrical busses with relatively intelligent routing to give you multiple collision domains while maintaining connectivity among a large number of devices. This again is a feature -- if your computer, phone, and camera all had FW instead of USB you could connect them in arbitrary combinations and still have them work. You can also use FW for IP networking and other Ethernet-like functions (and in fact modern FW provides support for cat-5 connectors that automatically switch between FW and Ethernet).
Nobody -- not even MS -- thinks SMB was a good file-sharing protocol. It became popular only because it was the only option available for MS clients. And even MS ditched it more or less as soon as they figured out that network file systems would be the normal way of doing business rather than some transient storage used to replace sneakernet.
CIFS is a better choice, though still not ideal. It's acceptable for many user-oriented filesystem mounts, but it has several limitations (some of which can be avoided if you run samba at both ends) in terms of permissions/etc. for POSIX systems, and it offers no multi-user mounting options, which are still quite useful for things like sharing applications folders. CIFS is a reasonable choice but I think most people would agree it's popularity is mostly due to its compatibility with MS clients, not its technical superiority to alternative network filesystems.
2 MW is a *lot* of power, even for large commercial installations. And it requires a lot more infrastructure to ship electricity than liquid fuel.
It's not unreasonable to think that electric cars might charge at power stations instead of at home, but high-speed charging is not a feasible next-step in the process.
A pint's a pound the world around. 1 gallon =~ 8 lbs.
No, no, no. The president has to physically enter the launch codes on the ground-test keyboard. If he's not there to enter the codes in person the entire Earth will be destroyed.
Then after the crisis he marries the whale lady and they produce a progeny with an uncanny ability to stay on-message in the A, B, and C plots no matter how boring that makes an already-preachy show. But thanks to his previous merger with god/borg/etc. he somehow manages to keep the mess on-air for the better part of a decade anyway.
There's only one reason to buy Apple -- so you can run UNIX and still watch flash videos. I like UNIX. I spend most of my day with at least one terminal open. But I'd still like to able to use closed-source software without jumping through hoops or rebooting into another OS. I did desktop linux for years but I eventually concluded it was cheaper to buy a Mac than fight with linux.
That's about the long and short of it. Bronze was more economically viable given the complexities of making iron. Iron was better in some ways, but it wasn't enough better to be worth the effort.
Of course, that viewpoint dismisses the new things we learned to do with iron once it was readily available, but that's true of all new technologies. Before we invented the microchip no one thought very hard about how office paperwork might be better if only we had a better information storage technology than paper -- computers existed and could have been used for that purpose but they were so expensive and impractical that no one though about using them for typing form letters.
It's in the wrong orbit to do anything other than be reachable by launches from mainland Russia. It's not like no one ever thought of using the space station as a jumping-off point before, it's just that such ideas were made more or less impractical as soon as we decided to put the space station in this silly orbit.
Until you open windows in two different programs that use that retarded window-in-a-window scheme that MS won't kill. Then your desktop is covered by an ugly grey box that bots out whatever other windows might otherwise be available behind it and you must switch programs to see different sets of windows, or hide them to see the desktop.
Seatbelts are rarely used without some sort of transport vehicle. Does that mean "seatbelt" and "vehicle" are synonyms?
Stop being a douche and just accept that fact that we could sell grandma (or build into her cable modem, OS, etc.) a stateful firewall that provides exactly the same protection *without* NAT.
For the 1000th time, it is possible to form an internet without being directly connected to the Internet, and any time you do that you need address coordination. When all your networks are internal it's plausible to do that in RFC-1918 space. But as soon as you introduce the possibility of an outside entity, it's much, much easier to use your guaranteed-to-be-globally-unique IP address than hope that every organization on your network agrees about who should have which addresses.
Or consider this situation -- *your* local network is not directly connected to the Internet, but you subscribe to a service that requires a LAN-LAN connection and *their* computer are connected to the Internet. Let's say they sell this same service to more than one customer. Does it really seem unreasonable that they want all of their LAN-LAN connections to be globally routable, or to use real IP addresses to make that happen?
There are good reasons to do that.
There are good reasons to do that even ignoring all the "it is sometimes useful to have a real, end-to-end network connection" bit.
Here's one that I've actual had problems with. Company A needs a LAN-LAN VPN with company B. Company A and company B are both using the same RFC-1918 address space. Who gets to renumber their network to make this connection work? The answer is often "neither, but instead we have to setup some NAT and/or proxy service to pretend we have non-1918 addresses", which then A) actually consumes the addresses anyway, B) makes access controls about 6 times harder, and C) requires actually setting up the proxy and/or NAT system in addition to the tunnel and access controls.
Or perhaps a more common one -- company A buys company B and wants to merge their networks. If everyone was just using real addresses in the first place this would be a trivial task. If they're both using the same RFC-1918 space however, it means one end *must* renumber to accommodate the other.
I think the point might have been that the town isn't entitled to any money from the use of the road anyway, whether people are speeding or not.
"Cross platform" as in "closed source, closed spec, happens to have a runtime for certain version of linux on certain hardware running certain distributions"
Objective C... syntax is ugly and non-intuitive
It is, which is somewhat unfortunate, but it's more or less by design to maintain compatibility.
Because ObjC is orthogonal to C/C++ it can't use any of the traditional notation. It's perfectly legal to mix a standard method call:
obj->method(argument);
with a ObjC message:
[obj2 method: argument];
in the same file.
It would be pretty hard to hack the meter if the pins just output a blip (or change polarity, or any other binary indicator) for every X units of energy are consumed, which is all the information the meter really provides in the first place. That sort of signal could be read directly by a serial port if you really didn't want to build an interface, or converted to a real digital signal with a pretty trivial circuit.
That being said, it's not that difficult to build a circuit that optically reads the LCD "wheel" indicator and blips when it goes around.
FB is invaluable to people trying to attract attention or track their fans/customers/etc. As a business or a group seeking publicity it's a great tool -- it's another way to broadcast information, beyond the traditional confines of TV/etc., and it provides tracking information.
Of course, all that has little to do with how most people use it, and certainly has nothing to do with using FB as a directed communications system, in preference to email or the other alternatives.
How can you be sure your FB messages aren't sent to the void by their filters?
You are preaching to the choir. I was pointing out there isn't much difference between sending email or a Facebook message except for some people's misguided view that email is somehow vastly superior to a FB message. I know FB is more convenient for some things than email - I use it for this purpose all the time.
Those who do not understand SMTP are doomed to re-implement it, poorly. And SMTP isn't that good to start with.
I'm a little confused as to why people change email addresses at all, but I'll just assume that really happens. I'm even more befuddled by the idea that the rate of email address changes among a group of people who regularly communicate is high enough to justify a lack of information ownership for the benefit of automated tracking. But again, I'll just assume that's a real thing too.
Facebook as an address book is useful, if for no other reason than it allows coordination and reduced effort among parties wishing to share contact information. That's hardly a new idea -- online address books have been around since the web was young -- and I'm not sure it's any more useful than a public LDAP server (and in many ways it's less useful, since there's no way to export info from FB, or integrate it with your email client/phone/etc.) but it is at least a genuine benefit, even if it's mostly from network effect.
And as others have noted, their RSVP system is handy if you're trying to organize a bunch of people, so I can give you that. They're not the only option for this, but they're free and easy to use and many people already have accounts there, so I can see using FB for RSVP purposes.
But why people think FB is useful as an actual directed communications system is beyond me though. Maybe it's the lack of a data export system -- they would use another system if FB let them get at their address book. With very few exceptions, FB messaging systems are comprehensively *less* rich than the alternatives, including email, and are subject to more data-mining or other monitoring or loss of privacy.
The same applies to their "Wall" and other broadcast communications features. Those same things are available at about 152,382,544 other systems on the Internet, including blogs, message boards, UUCP, and any of the the dozens of other types of services developed to meet this exact need for the past 25 years. Facebook adds exactly nothing to this sort of service; many others are at least as good, and many can offer respite from ads and data-mining, not to mention superior access controls and privacy.
I'm not saying no one should use FB, or that is has no benefits. But I have trouble believing that a typical person, given access to and an understanding of the alternatives, would prefer FB for most types of communications.
Real men write their own RSVP system.
Then they spend about twice as long as the coding/testing period convincing their wife that she should let him actually use it for their event.
We'd probably have to rent all our phone equipment from AT&T, who would be in no hurry to update their network or services from what they originally installed. Or don't your remember telephony before the breakup?
since they are stopping at my house anyways it has to be more fuel efficient to throw a disc on a plane (few ounces) than for me to drive 10+ miles
That's the part of this study I can't figure out. I know delivery trucks are not uber-efficient from a MPG perspective, but they carry lots of packages and have relatively high density delivery routes, at least when compared to the single-destination shopping that most people do. How can it possibly be more efficient on a per-item basis to drive the store, pick up the item, and drive back, than to add a 1 pound and 1 stop to an existing delivery route? Or does this study compare non-vehicular shopping trips to delivery services?
Modern scanners require moving your finger across a static scan line rather than moving the scan line across a static panel. Besides being smaller and using less power and moving parts, this also removes and possibility of lifting prints from the scanner itself.
Please don't conflate "biometerics as a stand-alone authenticator" with "biometrics as a second authentication factor". It's pretty reasonably to combine a physical token with biometrics, because you *can* deactivate/replace/rekey the physical token pretty easily. It's important that the authentication system includes some revokable factor, and ideally you'd also have a PIN or other knowledge-based authentication token, but physical + biometric is not a bad start, and can form a perfectly usable, revokable system.
And it's certainly not a bad system compared to the current "physical only" authentication currently in place.
Your fingerprints can't be changed, but they can't be as trivially reproduced as a password either. I agree, someone *could* steal your fingerprints and reproduce them in some useable way, though it would take a higher level sophistication than simply stealing your card or copying your password. And if someone stole your fingerprints and your card you could simply deactivate the stolen card and have a new one issued. The person with your fingerprints would then have a copy of your fingerprints and a useless credit card dongle. He'd need to steal your physical credit card all over again in order to use make use of his copy of your fingerprints.
x264 on my 8-core box will do 1080p at bitrates comparable to the Blu-Rays I have at about 2x real time. There's no reason to believe I couldn't build a box with 16+ cores and get real-time encoding without any particularly special hardware.
As for quality, I couldn't say objectively, as I don't have access to these "good AVC encoder"s you talk about to do a comparison. It's certainly possible they do a better job. Though I have to question the value of the extra quality, compared to the extra encoding time required. Then again, I have to question the importance of encoding time for a one-time pre-manufacturing process. Certainly it's nice to be done faster, and occasionally there are tight deadlines, but is there really a lot of demand for same-day encoding? Could you just buy 3x as many machines that run at 1/3 the speed and start a little earlier?