... presented me to a potential employer for a job that was in fact a good match, who wanted me to come in for an interview at their expense. But, he failed to notify me about it until the evening of the day before I was supposed to be there. There were two complications. 1: Where I was already working, we had mainframe hardware upgrades scheduled, and I needed to be there to reconfigure the OS for the change. 2: This interview was half way across the country and I would have had to leave within an hour to catch the flight, completely unprepared.
All that it takes is for the ISP to block traffic to any port 25 destination BY DEFAULT, and remove that block for any customer that asks for it to be removed. At the same time, the ISP should also provide assistance to customers that need to do things like send email through their office/work address, so that most of those customer would not need to ask for port 25 to be unblocked. Then, most of those that do ask for port 25 to be fully open would either be running an OS that doesn't get so infected like that, or would know how to properly secure their OS from viruses.
The ultimate credit collection is now for sale. For 10 million dollars ($10,000,000.00), plus $500,000 copying and media fees, you can be the exclusive buyer of this collection. That's right. This is the ULTIMATE credit card number collection. There is no collection any larger. Only ONE copy will be sold to the lucky buyer. This is actually a lower cost than any other offer by any other credit card list provider. This is an amazing 10 million (10,000,000) card numbers per penny... a total of ten quadrillion credit card numbers. And it can all be exclusively yours if you send the payment within 24 hours.
Myspace should have a dispute mechanism whereby the dispute is sent to the company making the claim, requiring them to provide PROOF of copyright ownership within 30 days. Failure to provide such proof then allows the disputed work to be posted. If proof is provided, the disputer shall have the right to obtain a copy of the proof for not greater than the cost of copying the documents (presumably at this point to sue the pants off the company making the fraudulent claim). That should let Myspace off the hook. Instead, this is a "MYSPACE FAIL" so they are complicit in the tort.
Laboratory development in France had actually exceeded the 1000 line level, until the work got cut short when Hitler was pissed that those "Frenchies" were going to get better TV than the (then) German system of a mere 441 lines. Ref: http://en.wikipedia.org/wiki/Television_systems_before_1940
What I want to be able to do is download one tarball, plus the required additional tarballs for things like the cross compile toolchain, extract all the tarballs in the same directory, run a specific command, and watch it build everything from source. Oh, and it has to work on any recent Linux system with basic host compiler toolchain ready to use, regardless of CPU architecture.
Building Partnerships: "We're defining our partnership models, making sure they're as efficient as possible, that they let the private sector work effectively with us and as one, and we're starting the process of developing a national cyberincident response process..."
Translation: If it's a problem with a security exposure in Microsoft Windows, hand it over to Microsoft to deal with. Let them do the coverup.
... but there are surely tens of thousands of people that currently have, or can get, cyber security certification. This is good enough for government work.
What if the REAL one is only the 51738th such order received, and the recipient had given up checking them all with the court after the first dozen or so?
(or however you would say that in the British language when you have one of those silly wigs on)... my client was unable to receive the order because his twitter account was being spammed by tens of thousands of... (mumbling: what are these called)... tweets... per minute from a bunch of... (mumbling: what were those people from that nerdy website)... uh... slashdotters. It seems it had something to do with Ms. Steisand but I'm not sure how she fits into this. Nevertheless, it was entirely impossible to read everything, and since my client is on a 9600 baud dialup connection in a remote village in Nigeria with electric power provided only from kids playing on a merry go round, and not knowing in advance that a court order would be among them, he simply ceased any attempt to read them.
500 passwords in my encrypted password file, with an automated program that picks the right one for the site I go to and logs me in, after having entered my encryption passphrase once each time the password daemon restarts, is very easy to handle. Now, 5000000000 passwords, that might be a bit taxing on the resources. But even so, that's just a Berkeley DB file, with the records decrypted when needed.
OpenID isn't the only solution around. It's just the one being promoted because businesses like sticking their hands in things. Had a company like Microsoft made this, it would certainly not have a way to run your own OpenID server. At least we can do that for those that don't want some company to see what other sites we log in to. But if we had the above tied directly into the browser, then we wouldn't have the issues we have with either a massive number of separate logins or OpenID's dependence on servers.
Apple wants something better than USB crap. Apple knows Intel has the IP to make something better. Apple lets Intel in on the gig so Intel will be more willing to eventually drop USB. All Apple needs to do is convince Intel that this will be big enough that Intel's share of the booty will still be bigger than USB. That and convince Intel they can't go it alone because Apple controls what goes on the iPods. That way Apple and Intel get to rape the consumer together. This is what you get when people buy based on brand name... that brand gets to jerk the market around.
Yes, USB was never designed to be universal for everything. But that doesn't mean we can't have something that is. Specialized interfaces like USB and eSATA just complicate the world because now we have to have both. I love the idea of all-in-one. But see my comments in another thread to understand the need for also having metallic.
The one connector cannot provide power unless it also has a metallic pair paralleling it. But you still have the problems of fiber (higher cost interfaces, higher cost more fragile cables). By having a metallic corollary connector, you can serve TWO needs in one: a way to convey power, as well as a way to do data transfers that generally don't need the high levels of the fiber (e.g. 1Gbps instead of 10Gbps).
Neither fiber nor metal is a universal solution. The choice is needed. USB won't go away if Light Peak limits itself to fiber only, and we'll be stuck with a legacy bus that way. By making a new metal connection that employs the same exact bus architecture as the fiber one means that we can at least have a single uniform approach to addressing all the devices.
I definitely want to AVOID having TWO cables to a device. Having both a fiber based connection and a metal based connection is NOT a burden. Just make the connectors look obviously different. Then you have a few instances of each kind of connector as an available port on the PC front, or the monitor front, or a multiconnector hub. You have a device with one kind of connector. You simply plug the connector in where it fits. Round peg in round hole. Square peg in square hole.
But if you really want the ONE KIND OF HOLE, then make one that has both a fiber interface AND a metallic interface, allow data over BOTH, power over the metal (and yes, power can data can go over the same metallic pair), and let the devices choose which they can use. There... a simple solution.
Wireless mouse lags are due to poor design of the wireless. I think the point of Light Peak is to have a fiber tether. Then you can extend the standard by optical or RF means, preferably with new protocols, to go tetherless. Power is an issue, and power storage in input devices like keyboards and mice is not infinite. The metallic tether can help deal with that.
Ideally, you should be able to plug your mouse into the display monitor, which will hub it back to the computer over the Light Peak connection it's getting video from. Same for the keyboard. And it might even just use Bluetooth or an optical equivalent to achieve that in lieu of a tether. The display is almost certain to be close to the mouse and keyboard, while the computer can now be placed up to 100 meters away in a computer room. Disk drives might be slowed down, depending on how much video is involved, and how well Light Peak manages its multiplexing (Firewire did fairly well, so I have no doubt this is doable... but I have some doubts about Intel being willing to make the choices to achieve it).
Doing everyone over one connector type, and things figuring out what it is and how to deal with it, is certainly a great goal. There needs to be, of course, more than one INSTANCE of a connector, so I can plug in multiple devices. Plugging in multiple display monitors when there are fewer video/graphics chips might be interesting. A means to assign which monitors get which video stream can deal with that. I hope they are also smart enough to make some monitors with 2 or 4 connections, creating the usefulness of a KVM switch. It will also have to be smart enough to know NOT to move certain already plugged in devices such as hard drives. But newly plugged in devices would generally go to the currently connected computer unless some sharing strategy exists.
That seems to be a Windows-only issue. Both OS X and Linux enumerate USB devices almost immediately.
I don't know about OS X or MS Windows. There is some delay in Linux. That's what I want to be eliminated.
IMHO this is a feature, not a defect; if a device freezes, unplugging it and plugging it back in will often clear up problems.
Indeed. And that is exactly why I want this to be fixed so I can do exactly that. As it stands now, if I unplug it and plug it back in, it comes up as a NEW device. If it is a disk drive that is mounted, that mount point is still referring to the old device. Processes that have open files and directories in that file tree have to be killed to be able to unmount the tree so I can mount the new device.
What I want is for the device to continue being that device. The mount should associate to an internal kernel device. When the same USB device is plugged back in, its unique ID should associated back to the original internal kernel device (as long as that hasn't been deleted, yet). Even if it wasn't mounted, but was open as a/dev node, or a script is in a soft loop waiting for it (such as by trying to open it every second), this should still work. The ultimate/dev name would be the unique ID itself, with a more convenient alias referring to it where configured (through udev or any other means).
In other words, it should JUST WORK when I unplug it and plug it back in... even if that is an hour later (as long as I or the system doesn't kill things off in the mean time).
>This used to be a major problem on Windows - i.e., in the early days of USB (be it XP, Win2K, or WinMe or 98SE) plugging a device (such as a printer) into a different port would force it to be redetected, search for and install a driver, etc. then you'd end up with multiple devices installed. It was downright brain-dead in how it handled USB, whereas on Mac OS and OS X It Just Worked(TM), and when Linux gained USB functionality, there It Just Worked(TM).
That aspect works. But that's not what I was referring to.
I'd rather the device be addressed by the device's unique identifier, not by port. Which port a USB device is plugged into should be transparent.
Certainly the unique ID is most important. But there are cases where reference by port is useful. This is less so for hard drive devices. It can be more so for other kinds of devices such as industrial controls where you want to be able to replace a USB-to-serial or USB-to-DAC/ADC device without having to reconfigure the system to understand that a new USB unique ID as the means to access the controls for a specific motor.
In short, BOTH means are needed. There's no reason you can't make it possible to address a device either by its unique ID or its plugged in slot.
I'd also add a third way to address a device, which is optional by device (e.g. the device is not required to have it, but if it does have it, it must work compatibly to conform to the standard). This is a "device configurable ID" (perhaps a 16 bit value). It would generally be something you manually set up on the device itself... and thus you are responsible for making sure device configurable IDs do not collide. The design needs to be able to gracefully handle cases of such collisions, and there are a few ways to do that. But in any case, this would be yet another address space for the devices that support it... you can address such a device by any of its (1) unique ID, (2) port address, and (3) configured address.
BTW, the port addressing would be a tree, forming an address string of a controller number and one or more layers of port numbers. Plugging in a hub on controller 2 port 1 would give an address like "2.1.0" for the hub control itself, "2.1.1" for the first port on the hub, "2.1.5" for the fifth port on the h
... cable system, too. It would be passively translated, using exactly the same bit level protocols, etc. It would be slower in most cases, of course. This would be so that metallic connection needs can be seamlessly integrated into the same bus architecture (which I hope fixes the mess they made of USB).
... such as the long settling time when a new device is plugged in, and the loss of continuity when a device is unplugged and quickly plugged back in. Another pet issue is that there should be a means to address a device specifically by which port it is plugged into, as well as by the device's unique ID regardless of which port it is plugged in to.
BTW, they could have included a USB path via the DVI/HDMI cable connection, so USB devices could be plugged directly into the monitor. I do worry that even Light Peak's high bandwidth can be dragged down over the display monitor path, slowing access to devices plugged in that way. We'll see, as those devices get faster and faster, and monitors get larger and larger.
Slashdot Mirror
... presented me to a potential employer for a job that was in fact a good match, who wanted me to come in for an interview at their expense. But, he failed to notify me about it until the evening of the day before I was supposed to be there. There were two complications. 1: Where I was already working, we had mainframe hardware upgrades scheduled, and I needed to be there to reconfigure the OS for the change. 2: This interview was half way across the country and I would have had to leave within an hour to catch the flight, completely unprepared.
All that it takes is for the ISP to block traffic to any port 25 destination BY DEFAULT, and remove that block for any customer that asks for it to be removed. At the same time, the ISP should also provide assistance to customers that need to do things like send email through their office/work address, so that most of those customer would not need to ask for port 25 to be unblocked. Then, most of those that do ask for port 25 to be fully open would either be running an OS that doesn't get so infected like that, or would know how to properly secure their OS from viruses.
The ultimate credit collection is now for sale. For 10 million dollars ($10,000,000.00), plus $500,000 copying and media fees, you can be the exclusive buyer of this collection. That's right. This is the ULTIMATE credit card number collection. There is no collection any larger. Only ONE copy will be sold to the lucky buyer. This is actually a lower cost than any other offer by any other credit card list provider. This is an amazing 10 million (10,000,000) card numbers per penny ... a total of ten quadrillion credit card numbers. And it can all be exclusively yours if you send the payment within 24 hours.
Convolution is no excuse when making fraudulent claims on copyrights owned by someone who is not a party to such deals.
Myspace should have a dispute mechanism whereby the dispute is sent to the company making the claim, requiring them to provide PROOF of copyright ownership within 30 days. Failure to provide such proof then allows the disputed work to be posted. If proof is provided, the disputer shall have the right to obtain a copy of the proof for not greater than the cost of copying the documents (presumably at this point to sue the pants off the company making the fraudulent claim). That should let Myspace off the hook. Instead, this is a "MYSPACE FAIL" so they are complicit in the tort.
Only 737 lines were image information. The rest was synchronization pulse and blanking for CRT flyback time.
Ref: http://en.wikipedia.org/wiki/Analog_high-definition_television_system
Laboratory development in France had actually exceeded the 1000 line level, until the work got cut short when Hitler was pissed that those "Frenchies" were going to get better TV than the (then) German system of a mere 441 lines.
Ref: http://en.wikipedia.org/wiki/Television_systems_before_1940
Also see: http://en.wikipedia.org/wiki/History_of_television
Earth, Incorporated
What I want to be able to do is download one tarball, plus the required additional tarballs for things like the cross compile toolchain, extract all the tarballs in the same directory, run a specific command, and watch it build everything from source. Oh, and it has to work on any recent Linux system with basic host compiler toolchain ready to use, regardless of CPU architecture.
1000 people who think they are security experts would do far more harm than 5 people who actually are.
From the referenced link on list of priorities:
Building Partnerships: "We're defining our partnership models, making sure they're as efficient as possible, that they let the private sector work effectively with us and as one, and we're starting the process of developing a national cyberincident response process..."
Translation: If it's a problem with a security exposure in Microsoft Windows, hand it over to Microsoft to deal with. Let them do the coverup.
... but there are surely tens of thousands of people that currently have, or can get, cyber security certification. This is good enough for government work.
Would a court post as Anonymous Coward?
What if the REAL one is only the 51738th such order received, and the recipient had given up checking them all with the court after the first dozen or so?
(or however you would say that in the British language when you have one of those silly wigs on) ... my client was unable to receive the order because his twitter account was being spammed by tens of thousands of ... (mumbling: what are these called) ... tweets ... per minute from a bunch of ... (mumbling: what were those people from that nerdy website) ... uh ... slashdotters. It seems it had something to do with Ms. Steisand but I'm not sure how she fits into this. Nevertheless, it was entirely impossible to read everything, and since my client is on a 9600 baud dialup connection in a remote village in Nigeria with electric power provided only from kids playing on a merry go round, and not knowing in advance that a court order would be among them, he simply ceased any attempt to read them.
500 passwords in my encrypted password file, with an automated program that picks the right one for the site I go to and logs me in, after having entered my encryption passphrase once each time the password daemon restarts, is very easy to handle. Now, 5000000000 passwords, that might be a bit taxing on the resources. But even so, that's just a Berkeley DB file, with the records decrypted when needed.
OpenID isn't the only solution around. It's just the one being promoted because businesses like sticking their hands in things. Had a company like Microsoft made this, it would certainly not have a way to run your own OpenID server. At least we can do that for those that don't want some company to see what other sites we log in to. But if we had the above tied directly into the browser, then we wouldn't have the issues we have with either a massive number of separate logins or OpenID's dependence on servers.
Apple wants something better than USB crap. Apple knows Intel has the IP to make something better. Apple lets Intel in on the gig so Intel will be more willing to eventually drop USB. All Apple needs to do is convince Intel that this will be big enough that Intel's share of the booty will still be bigger than USB. That and convince Intel they can't go it alone because Apple controls what goes on the iPods. That way Apple and Intel get to rape the consumer together. This is what you get when people buy based on brand name ... that brand gets to jerk the market around.
Yes, USB was never designed to be universal for everything. But that doesn't mean we can't have something that is. Specialized interfaces like USB and eSATA just complicate the world because now we have to have both. I love the idea of all-in-one. But see my comments in another thread to understand the need for also having metallic.
The one connector cannot provide power unless it also has a metallic pair paralleling it. But you still have the problems of fiber (higher cost interfaces, higher cost more fragile cables). By having a metallic corollary connector, you can serve TWO needs in one: a way to convey power, as well as a way to do data transfers that generally don't need the high levels of the fiber (e.g. 1Gbps instead of 10Gbps).
Neither fiber nor metal is a universal solution. The choice is needed. USB won't go away if Light Peak limits itself to fiber only, and we'll be stuck with a legacy bus that way. By making a new metal connection that employs the same exact bus architecture as the fiber one means that we can at least have a single uniform approach to addressing all the devices.
I definitely want to AVOID having TWO cables to a device. Having both a fiber based connection and a metal based connection is NOT a burden. Just make the connectors look obviously different. Then you have a few instances of each kind of connector as an available port on the PC front, or the monitor front, or a multiconnector hub. You have a device with one kind of connector. You simply plug the connector in where it fits. Round peg in round hole. Square peg in square hole.
But if you really want the ONE KIND OF HOLE, then make one that has both a fiber interface AND a metallic interface, allow data over BOTH, power over the metal (and yes, power can data can go over the same metallic pair), and let the devices choose which they can use. There ... a simple solution.
Wireless mouse lags are due to poor design of the wireless. I think the point of Light Peak is to have a fiber tether. Then you can extend the standard by optical or RF means, preferably with new protocols, to go tetherless. Power is an issue, and power storage in input devices like keyboards and mice is not infinite. The metallic tether can help deal with that.
Ideally, you should be able to plug your mouse into the display monitor, which will hub it back to the computer over the Light Peak connection it's getting video from. Same for the keyboard. And it might even just use Bluetooth or an optical equivalent to achieve that in lieu of a tether. The display is almost certain to be close to the mouse and keyboard, while the computer can now be placed up to 100 meters away in a computer room. Disk drives might be slowed down, depending on how much video is involved, and how well Light Peak manages its multiplexing (Firewire did fairly well, so I have no doubt this is doable ... but I have some doubts about Intel being willing to make the choices to achieve it).
Doing everyone over one connector type, and things figuring out what it is and how to deal with it, is certainly a great goal. There needs to be, of course, more than one INSTANCE of a connector, so I can plug in multiple devices. Plugging in multiple display monitors when there are fewer video/graphics chips might be interesting. A means to assign which monitors get which video stream can deal with that. I hope they are also smart enough to make some monitors with 2 or 4 connections, creating the usefulness of a KVM switch. It will also have to be smart enough to know NOT to move certain already plugged in devices such as hard drives. But newly plugged in devices would generally go to the currently connected computer unless some sharing strategy exists.
That seems to be a Windows-only issue. Both OS X and Linux enumerate USB devices almost immediately.
I don't know about OS X or MS Windows. There is some delay in Linux. That's what I want to be eliminated.
IMHO this is a feature, not a defect; if a device freezes, unplugging it and plugging it back in will often clear up problems.
Indeed. And that is exactly why I want this to be fixed so I can do exactly that. As it stands now, if I unplug it and plug it back in, it comes up as a NEW device. If it is a disk drive that is mounted, that mount point is still referring to the old device. Processes that have open files and directories in that file tree have to be killed to be able to unmount the tree so I can mount the new device.
What I want is for the device to continue being that device. The mount should associate to an internal kernel device. When the same USB device is plugged back in, its unique ID should associated back to the original internal kernel device (as long as that hasn't been deleted, yet). Even if it wasn't mounted, but was open as a /dev node, or a script is in a soft loop waiting for it (such as by trying to open it every second), this should still work. The ultimate /dev name would be the unique ID itself, with a more convenient alias referring to it where configured (through udev or any other means).
In other words, it should JUST WORK when I unplug it and plug it back in ... even if that is an hour later (as long as I or the system doesn't kill things off in the mean time).
>This used to be a major problem on Windows - i.e., in the early days of USB (be it XP, Win2K, or WinMe or 98SE) plugging a device (such as a printer) into a different port would force it to be redetected, search for and install a driver, etc. then you'd end up with multiple devices installed. It was downright brain-dead in how it handled USB, whereas on Mac OS and OS X It Just Worked(TM), and when Linux gained USB functionality, there It Just Worked(TM).
That aspect works. But that's not what I was referring to.
I'd rather the device be addressed by the device's unique identifier, not by port. Which port a USB device is plugged into should be transparent.
Certainly the unique ID is most important. But there are cases where reference by port is useful. This is less so for hard drive devices. It can be more so for other kinds of devices such as industrial controls where you want to be able to replace a USB-to-serial or USB-to-DAC/ADC device without having to reconfigure the system to understand that a new USB unique ID as the means to access the controls for a specific motor.
In short, BOTH means are needed. There's no reason you can't make it possible to address a device either by its unique ID or its plugged in slot.
I'd also add a third way to address a device, which is optional by device (e.g. the device is not required to have it, but if it does have it, it must work compatibly to conform to the standard). This is a "device configurable ID" (perhaps a 16 bit value). It would generally be something you manually set up on the device itself ... and thus you are responsible for making sure device configurable IDs do not collide. The design needs to be able to gracefully handle cases of such collisions, and there are a few ways to do that. But in any case, this would be yet another address space for the devices that support it ... you can address such a device by any of its (1) unique ID, (2) port address, and (3) configured address.
BTW, the port addressing would be a tree, forming an address string of a controller number and one or more layers of port numbers. Plugging in a hub on controller 2 port 1 would give an address like "2.1.0" for the hub control itself, "2.1.1" for the first port on the hub, "2.1.5" for the fifth port on the h
While it is the software doing the delay, it is the architecture of the bus and behavior of the hardware that makes this necessary.
... cable system, too. It would be passively translated, using exactly the same bit level protocols, etc. It would be slower in most cases, of course. This would be so that metallic connection needs can be seamlessly integrated into the same bus architecture (which I hope fixes the mess they made of USB).
... such as the long settling time when a new device is plugged in, and the loss of continuity when a device is unplugged and quickly plugged back in. Another pet issue is that there should be a means to address a device specifically by which port it is plugged into, as well as by the device's unique ID regardless of which port it is plugged in to.
BTW, they could have included a USB path via the DVI/HDMI cable connection, so USB devices could be plugged directly into the monitor. I do worry that even Light Peak's high bandwidth can be dragged down over the display monitor path, slowing access to devices plugged in that way. We'll see, as those devices get faster and faster, and monitors get larger and larger.
I found this article from very close to the bank's main office.