If I were in NZ and installed a fresh new Debian system today, I believe it would be within reason to expect it to behave correctly with respect to things like time. The fact that Debian is structured to not have this feature is, IMHO, a very serious drawback to Debian. There was a similar, less serious, issue many years ago that turned me away from considering the use of Debian.
Anonymity is crucial to Free Speech. It needs to be recognized and preserved. Only in cases where the speech can be proven to have been false and caused harm should anonymity be stripped away to expose the abuse.
In a great many cases, an individual being able to prove the wrong doings often accused, is nearly impossible, or extremely costly. But without such free speech, these wrong doings would never even be investigated.
So in a way you are right. But, there needs to be a full investigation into the accusations before anyone can say that the speech caused harm. In this case, if the hospital wants to claim that what was spoken (blogged) is not true, it should offer to allow this investigation by a party that can be trusted by the public. Only if this investigation shows that the accusations are untrue AND that the claims by the accuser caused harm, then the accuser should be uncovered.
What about the right (of the hospital in this case) to face their accuser? That's for a formal accusation in court. If the investigation found problems worth taking them to court, the investigators are the formal accusers and they would be the ones the hospital gets to face. The blogger is strictly an informal accuser (unless he choses to step forward and make the accusation formal).
Suppose a company sells smaller low end computers with slower (fanless) CPUs and tiny RAM (like 128K) as well. Is Microsoft saying these have to switch over to Linux after June 30, 2008? They sure can't run Vista. Even XP would be kinda tough.
I tracked down Fasthosts IP addresses (213.171.192.0/19) to enter them into my blocking system. But when I tried to enter that, there was an error. It could not add them. It seems they are already in there under the spamming category (hosting a spammer, hosting open relays, or something that lets spam go through, without even responding to issues). It seems to be like that is a mismanaged company that should be avoided. So I just had to tag it with a new category.
This is a bad idea. While there is an issue about how content is displayed, there is also an issue about how much content there is.
What is needed is a new (proposed) HTTP request header that passes the media types (classes) to the server. Then instead of trying to guess the media type from the user agent string, the server will know for sure. For example a request might have the HTTP header "MediaType: display/mobile;geometry=288x384" and a 2nd header "MediaType: audio/stereo;format=mp3,ogg,flac". The server then knows what kinds of media the device has or has enabled. If I turn the sound off, the sound mediat type won't be sent in requests. When I am at home and request a document print (as opposed to a screen print) it could send "MediaType: print/inkjet;hdpi=1200;vdpi=1200" which would clue in the server to limit the content to just what is appropriate for printing.
Your theory "The site content shouldn't need to change - only the presentation." is technically correct. But the point here is to preserve some bandwidth, too, by doing some presentation filtering (only send the media types in use) and optimization (server knows the display size, so it sends small display media or reformats). It's still the same content... but the parts of the content not needed are not transmitted. On the server side, one way to implement this is to add some XML tags that identify what parts of the conent apply to what media types.
The whole "separate content and style" idea has long had the flaw that too much (usually all of it) content was sent all the time. My above proposal allows the content volume to be limited for transmission while still preserving the fundamental principle of that separation as it applies to the creation of the content. Web sites (such as Vodafone) are really trying to do some kind of content filtering now. This just makes for a standardized way to manage it (so the unreliable User Agent won't need to be used).
The best language to use is the one you KNOW best... as long as it is at least up to the task for the project you have in mind... and as long as the project needs no more programmers than you plus whoever else also knows this same language best. Yes, even the C language can be best for a project if it is what YOU know best how to code in.
If you know all the ins and outs of a language, and have a strong grasp of what all it can do (most languages can do almost anything when coded by a programmer that knows it well) and cannot do (usually this is a function of the inverse of how well you know the language), then that language can work.
Now, would that language be the most optimal for you to choose. Maybe not. If you factor in the time and effort to learn a new language well enough to know all the ins and outs of it, you very likely have added a huge amount of time to a project. Learning a new language that has more advanced tools that will let you develop faster and better is probably a good idea. BUT... that learning process should not be tied to any immediate project. Think back to the things you did when learning the language you know best now. They were more than likely a lot smaller and more trivial than what you might contemplate doing today. That's a factor of your experience, particularly with the language (the same can also apply to the systems that will be used). Go ahead and learn a new language for the future doing smaller tasks with it, and grow them as you learn it. Use the language you still know best for the major tasks, even if it will take you longer to do them in that language than it would take for someone experienced in the new language to do it in the new one (because you are not yet that programmer experienced in the new one).
Teams needs to be homogenous. Ironically, one good programmer can do alone a lot more than a small team can do. But some projects are just too big for one programmer. When you need a team, make sure they are all experienced at about the same level in that language AND they all consider that language to be their best language. The project lead is the only exception and can be more experienced than the team, but must still consider that language his/her best.
The issue is quite critical given the fact that PDF documents are in the core of today's modern business. This and the fact that it may take a while for Adobe to fix their closed source product, are the reasons why I am not going to publish any POCs. You have to take my word for it. The POCs will be released when an update is available.
So if Adobe never releases a fix, he will never release the details? That's rather open-ended. He should have set a reasonable timeline which includes a reasonable amount of time to fix the bug in all versions for all platforms (variable depending the severity of the bug, but I cannot imagine this taking more than 60 days), plus time for people and IT departments to deploy the closed source changes (another 30 days at most). So a 90 day deadline, plus a couple more weeks to deal with the deployment during Christmas holidays, sounds about right. The details also need to be sequestered somewhere trustable that is beyond a US or UK court ordering some party to not release it, where it will be automatically released when the time comes.
If open source PDF viewers are also vulnerable, they, too, need to be given the details immediately so they can implement and deploy a fix. Yeah, that means someone who has the "diff -ur" command on BSD or Linux can figure out what was changed in the source, and gain a nice clue about the exploit.
They should be given immunity, and the people in charge who allowed the NSA to solicit these companies into doing illegal wiretapping should be prosecuted to the full extent of the law...
Only if these companies testify openly in court about the illegal wiretapping they were encouraged or pressured to do, with names of who talked to who.
There is the argument that if you copy and distribute intellectual property, you are depriving the copyright owner of the right to profit from his own copying and distribution of that property. There may be a minor loss to the owner of the original copy you used to the extent that your copying and distribution causes him to get less money for a resale of his only copy to someone else as a used copy. Ironically, that is something many big media companies also want to take away.
But what about one doing the copying exclusively for themselves? In theory, that is also depriving the original copyright owner because he doesn't get the money from you actually buying a legitimate copy from him. But what if you do buy a legitimate copy, but find that not only does it not work in your player, there are no legitimate copies available for you to buy that do. One big example is DRM protected DVD content that won't play in Linux without using some form of hacking.
Suppose you do hack the DVD contents and store it where Linux can play it. Have you deprived the copyright owner of anything? I'd argue that not only have you not deprived him of any financial benefit, but you have also provided him a financial gain, since if Linux is your only computer system, you would not have bought the legal copy in the first place. Alternatives to this include buying the legal DVD and also downloading a p2p copy of it (but not offering it as an upload).
I don't know if anyone could use that as a legal defense. I would find it interesting to follow if someone tried. The argument might go like "Since the copyright owner provides no copy sold on a media type I am able to directly use, I am therefore not a part of the market the copyright owner has any legitimate expectation of revenue from. My copying strictly for personal benefit has not deprived him of any legitimate revenue. My copying has in fact provided him with legitimate revenue". Of course there could be many counter-arguments like "Just use a normal DVD player with a normal TV".
A converged bus would be a compromise in a lot of ways. But I do believe it is feasible for a large portion of device connectivity, including just about everything now connected via USB, FW, or SATA. PCIe and DVI would pose some complications, but video up to a point could be handled over a single data pair (DVI has separate pairs for red, green, and blue). SATA shows us that we can do 3 GB data rates on metallic conductors. One problem is that all the connectors are bad designs. They are flimsey. They require exact orientation. And they have both male and female ends. My connector design would eliminate those issues.
My connector design would be a square connector (about the size of the device end of USB) with locking clips on 2 opposing sides, and holes to accept the locking clips on the remaining 2 sides. The design is to allow one connector to mate with one exactly like it rotated at 90 degrees. Inside the square would be two plastic parts shaped in diagonals with the 90 degree corners pointing at the center and at each other. The space between the diagonals would be where these parts from the incoming connector would fit. Think of the letter X where one connector has these plastic parts in the upper and lower gaps of the X and the incoming connector turned 90 degrees would fit with the parts on the left and right gaps. The contacts for data would be near the center on the sides of the diagonal parts. For data transmit, one contact would be on one of the parts, and the other contact would be on the other part at 180 degrees. So if you rotate the connector 180 degrees, you are only flipping the polarity of the wires making up the data transmit pair. The data receive pair would be on the other side of the parts, also near the center. Power (deliverable in both directions) would be on the same sides but further away from the center. The power polarity would have to be corrected with a bridge rectifier in the device taking power. Polarity on the data wires would be a non-issue since modern data encoding doesn't need this (e.g. edge-triggered, etc).
The middle of the diagonal parts would be reserved for future fiber usage with as many as 4 fibers between devices.
Using multi-level encodings, data speeds of 3 Gbits per second and higher are easily possible with metallic. While there would be separate transmit and receive pairs for simpler devices, the protocol could include a means to negotiate uni-directional bursting where at times both data pairs could be used at the same time in one direction to double the transfer rate in a specific direction. This could help handle uncompressed video to a monitor (while still allowing enough return bandwidth to let you plug the keyboard and mouse into the monitor, along with a touch screen sensor if you want.
The only real hindrance to converging all these technologies is people... those who have some vested interest in each of the others.
According to Intel, the new USB 3 standard will use fiber optic cable for data as well as power. The data will be modulated on a high-powered laser light signal, enough to deliver the power to spin up a harddisk, or, alternatively, burn through one solid oaken office door as well as the sales guy who was about to open said door.
Make that be 532nm wavelength light and we can use these in place of Wicked Lasers:-)
I already have a plug design that, as one of its features, can be rotated 180 degrees when plugged in, and it still mates correctly for both data (separate pairs for each direction) and power (power can be supplied in either direction). The other feature is that not only is each end of the cable the same (at least for the same size class... still need to allow for very tiny connectors for very tiny devices), the connector is asexual, meaning that it can mate with one of itself with just a 90 degree turn either way, with the data and power connections still made correctly (power polarity can be reversed, but a bridge rectifier can deal with that at the power usage end). Thus the connectors on the devices would actually be the same as the connectors on the cables. The only time you'd need a cable with different connectors on each end is when going between a large connector and a small connector (I think only 2 sizes would be needed, so this should be a minimal issue).
The connector would basically be square with locking clips on 2 sides, and holes on the other 2 sides to receive the locking clips from the incoming connector. Inside the connector square would be a pair of diagonal substrates arranged with the 90 degree angle corners pointing inward at each other. This would leave a pair of spaces for the mating connector to fit in. The data contacts would be on the sides close to the center. The power contacts would be on the same sides but further outward from the center. Data transmit would contact data receive on the other connector, with the polarity reversed if the connector is inserted at 180 degree rotation. But it would still be transmit connecting to receive (a total of 4 data wires). Power would similarly have 4 wires, 1 pair for power in one direction, and the other pair for power in the other direction. Devices not needing power just won't connect to the supplied power.
The only issue that you might have left is the issue of having normal size connectors (about the size of a device end of a standard size USB, or about the size of the 8P8C connector typically found on CAT5 cable), and tiny miniature connectors for devices too small to take a normal size connector. Cables could be made to have one size on one end and the other size on the other end, in which case you'd have to be sure you string up the cable with the correct end at the correct device.
By having the locking clips protrude from device mounted connectors by a slight amoung, maybe 0.5 to 1.0 mm, it would be possible to feel the connector hole to determine the alignment, whether the clips are horizontal or vertical relative to orientation of the device. Then just insert the cable at +90 or -90 degrees (either way will work).
Having it be flippable would mean duplicating wires and/or contacts and would make the cables more susceptible to damage and more expensive.
I disagree.
It is possible to make a connector that when rotated 180 degrees still fits the mating connector and still lins up contacts. It would be a "180 degree rotation symmetric" connector. Then you simply assign the contacts such that when plugged in either way, the same pair always contacts each other. The difference would be a reversal of data polarity. And that is irrelevant as most technologies work on edge-trigger or can be made to do so. Power would either require a rectifier bridge at the receiving end to handle polarity flips, or the power would be done with both contacts being the same polarity (added current capacity) and the shield be the power return.
No, Germany has not slipped back into being a facist state. But it is slipping. There are elements in the government trying to give it a push in that very direction, just as there are similar elements in the USA. The problem is not enough people are pushing back. Until it becomes widely recognized what is happening, not enough people will. This is what happened in the 1920's and 1930's. People who warned others about what was to come were not taken seriously.
I agree: analogies to activities of the Schutzstaffel (SS) or its secret police, the Geheime Staatspolizei (Gestapo), are not accurate representations of what is going on. They are, however, a representation of what many people, including myself, believe could happen, or will happen (again), if people fail to become aware of these wrongs, and fail to put a stop to it. The visualizations from the late 1920's to the early 1940's just need to be put in the correct context of "what could be". Sadly for millions, people looked the other way when the NSDAP rose to power and committed so many atrocities. If they look the other way again in this case, and in similar cases likely to happen further, then nothing was learned and those millions died in vain.
Cable system operators would prefer to switch the system to 100% digital. They can't do it immediately for a couple major reasons. One of those reasons is the up front investment costs involved. The other reason is the need to service quite many customers in analog, especially the basic customers at the lowest pricing tier, likely to include grandma and grandpa with that old TV from the 1970's that still works. Eventually, however, cable systems will move to be 100% digital. A few have achieved this, already (and presumably supply a set-top box with analog output).
The reason digital is an advantage to the cable system is that it means they can offer more channels in whatever combination of standard definition and high definition they would end up with. It's even more of an advantage for cable than for broadcasters because cable can use QAM256 which has twice the bandwidth as the 8VSB modulation broadcasters use over the air. The 6 MHz of space a single analog channel uses could carry 2 to 3 HD channels at 1080i60 or 720p60 (typically found on over the air digital TV in the USA) or one channel at 1080p60 (the ultimate format many HD TVs can now handle but cannot be sent over the air at all). Or that same space could carry even more channels at various customized formats such as 3 to 5 channels at 1080p24 specifically optimized for movies, or 6 to 9 channels at 720p24 for slightly lesser definition movies. That same space could carry 12 to 20 standard definition channels at 480i60, or even 16 to 25 channels at an even slower 480p24 which is fine for programming like infomercials and shopping channels. Dozens of still frame music channels could also be carried in that 6 MHz of space.
More channels means more revenue for the cable companies, both from the providers supplying the programming as well as from tiered customers selecting that programming. Although cable companies might have to pay for highly recognized programming like CNN, the smaller programming providers typically have to pay the cable company to get on (especially where there aren't as many channels).
A cable system that still has some national channel carried over the wire in analog just hasn't gotten around to making the change, yet. Making these changes is not easy, and may invole carrying it in both forms for a while to be sure the set-top boxes pick up the change, and that customers tuning directly on cable ready digital tuners are made aware of the change. But in the next few years, cable systems will be making these changes, and will be adding more channels and more HD channels, and maybe even using more channel space for internet access.
Will this even interrupt online game play, where the game network keeps on running while your player gets beat to death and you lose all your treasures?
If I were driven to BSD... GPLv3 itself won't, but it might for my customers... it would be NetBSD. The reason is the wider support for a variety of embedded and small system architectures.
I don't hear any songs from MySpace when I visit (which is not very often). My solution is that my speakers are plugged into my router (a separate box running Slackware), instead. It has spare disk space (because I can't find drives smaller than 40 GB anymore), so I put my music collection over there (it isn't that big) and play it over there. Web site music just warms a few components on the mainboard sound chip. If there is ever something I do want to listen to via the browser or the desktop box, I can switch the audio connections.
As a good citizen of the internet, I think it a good thing that I don't clog the tubes with advertising bandwidth which I do not care to see.
As a good citizen of the internet, I think it a good thing that I don't clog the tubes with content the reader does not want to help support through a quick glance across a non-abusive, non-invasive, non-flashy, non-animated, non-popup, ad banner just in case there is something that might be of interest to them.
Slashdot Mirror
If I were in NZ and installed a fresh new Debian system today, I believe it would be within reason to expect it to behave correctly with respect to things like time. The fact that Debian is structured to not have this feature is, IMHO, a very serious drawback to Debian. There was a similar, less serious, issue many years ago that turned me away from considering the use of Debian.
A better method than blurring, and irreversible, is to substitute someone else's face, scaled to the same size. They could use CmdrTaco's mug shot.
Anonymity is crucial to Free Speech. It needs to be recognized and preserved. Only in cases where the speech can be proven to have been false and caused harm should anonymity be stripped away to expose the abuse.
In a great many cases, an individual being able to prove the wrong doings often accused, is nearly impossible, or extremely costly. But without such free speech, these wrong doings would never even be investigated.
So in a way you are right. But, there needs to be a full investigation into the accusations before anyone can say that the speech caused harm. In this case, if the hospital wants to claim that what was spoken (blogged) is not true, it should offer to allow this investigation by a party that can be trusted by the public. Only if this investigation shows that the accusations are untrue AND that the claims by the accuser caused harm, then the accuser should be uncovered.
What about the right (of the hospital in this case) to face their accuser? That's for a formal accusation in court. If the investigation found problems worth taking them to court, the investigators are the formal accusers and they would be the ones the hospital gets to face. The blogger is strictly an informal accuser (unless he choses to step forward and make the accusation formal).
Suppose a company sells smaller low end computers with slower (fanless) CPUs and tiny RAM (like 128K) as well. Is Microsoft saying these have to switch over to Linux after June 30, 2008? They sure can't run Vista. Even XP would be kinda tough.
RTFA ... it's 5 months from Jan 31 to June 30.
I tracked down Fasthosts IP addresses (213.171.192.0/19) to enter them into my blocking system. But when I tried to enter that, there was an error. It could not add them. It seems they are already in there under the spamming category (hosting a spammer, hosting open relays, or something that lets spam go through, without even responding to issues). It seems to be like that is a mismanaged company that should be avoided. So I just had to tag it with a new category.
This is a bad idea. While there is an issue about how content is displayed, there is also an issue about how much content there is.
What is needed is a new (proposed) HTTP request header that passes the media types (classes) to the server. Then instead of trying to guess the media type from the user agent string, the server will know for sure. For example a request might have the HTTP header "MediaType: display/mobile;geometry=288x384" and a 2nd header "MediaType: audio/stereo;format=mp3,ogg,flac". The server then knows what kinds of media the device has or has enabled. If I turn the sound off, the sound mediat type won't be sent in requests. When I am at home and request a document print (as opposed to a screen print) it could send "MediaType: print/inkjet;hdpi=1200;vdpi=1200" which would clue in the server to limit the content to just what is appropriate for printing.
Your theory "The site content shouldn't need to change - only the presentation." is technically correct. But the point here is to preserve some bandwidth, too, by doing some presentation filtering (only send the media types in use) and optimization (server knows the display size, so it sends small display media or reformats). It's still the same content ... but the parts of the content not needed are not transmitted. On the server side, one way to implement this is to add some XML tags that identify what parts of the conent apply to what media types.
The whole "separate content and style" idea has long had the flaw that too much (usually all of it) content was sent all the time. My above proposal allows the content volume to be limited for transmission while still preserving the fundamental principle of that separation as it applies to the creation of the content. Web sites (such as Vodafone) are really trying to do some kind of content filtering now. This just makes for a standardized way to manage it (so the unreliable User Agent won't need to be used).
The best language to use is the one you KNOW best ... as long as it is at least up to the task for the project you have in mind ... and as long as the project needs no more programmers than you plus whoever else also knows this same language best. Yes, even the C language can be best for a project if it is what YOU know best how to code in.
If you know all the ins and outs of a language, and have a strong grasp of what all it can do (most languages can do almost anything when coded by a programmer that knows it well) and cannot do (usually this is a function of the inverse of how well you know the language), then that language can work.
Now, would that language be the most optimal for you to choose. Maybe not. If you factor in the time and effort to learn a new language well enough to know all the ins and outs of it, you very likely have added a huge amount of time to a project. Learning a new language that has more advanced tools that will let you develop faster and better is probably a good idea. BUT ... that learning process should not be tied to any immediate project. Think back to the things you did when learning the language you know best now. They were more than likely a lot smaller and more trivial than what you might contemplate doing today. That's a factor of your experience, particularly with the language (the same can also apply to the systems that will be used). Go ahead and learn a new language for the future doing smaller tasks with it, and grow them as you learn it. Use the language you still know best for the major tasks, even if it will take you longer to do them in that language than it would take for someone experienced in the new language to do it in the new one (because you are not yet that programmer experienced in the new one).
Teams needs to be homogenous. Ironically, one good programmer can do alone a lot more than a small team can do. But some projects are just too big for one programmer. When you need a team, make sure they are all experienced at about the same level in that language AND they all consider that language to be their best language. The project lead is the only exception and can be more experienced than the team, but must still consider that language his/her best.
From TFA:
So if Adobe never releases a fix, he will never release the details? That's rather open-ended. He should have set a reasonable timeline which includes a reasonable amount of time to fix the bug in all versions for all platforms (variable depending the severity of the bug, but I cannot imagine this taking more than 60 days), plus time for people and IT departments to deploy the closed source changes (another 30 days at most). So a 90 day deadline, plus a couple more weeks to deal with the deployment during Christmas holidays, sounds about right. The details also need to be sequestered somewhere trustable that is beyond a US or UK court ordering some party to not release it, where it will be automatically released when the time comes.
If open source PDF viewers are also vulnerable, they, too, need to be given the details immediately so they can implement and deploy a fix. Yeah, that means someone who has the "diff -ur" command on BSD or Linux can figure out what was changed in the source, and gain a nice clue about the exploit.
Only if these companies testify openly in court about the illegal wiretapping they were encouraged or pressured to do, with names of who talked to who.
There is the argument that if you copy and distribute intellectual property, you are depriving the copyright owner of the right to profit from his own copying and distribution of that property. There may be a minor loss to the owner of the original copy you used to the extent that your copying and distribution causes him to get less money for a resale of his only copy to someone else as a used copy. Ironically, that is something many big media companies also want to take away.
But what about one doing the copying exclusively for themselves? In theory, that is also depriving the original copyright owner because he doesn't get the money from you actually buying a legitimate copy from him. But what if you do buy a legitimate copy, but find that not only does it not work in your player, there are no legitimate copies available for you to buy that do. One big example is DRM protected DVD content that won't play in Linux without using some form of hacking.
Suppose you do hack the DVD contents and store it where Linux can play it. Have you deprived the copyright owner of anything? I'd argue that not only have you not deprived him of any financial benefit, but you have also provided him a financial gain, since if Linux is your only computer system, you would not have bought the legal copy in the first place. Alternatives to this include buying the legal DVD and also downloading a p2p copy of it (but not offering it as an upload).
I don't know if anyone could use that as a legal defense. I would find it interesting to follow if someone tried. The argument might go like "Since the copyright owner provides no copy sold on a media type I am able to directly use, I am therefore not a part of the market the copyright owner has any legitimate expectation of revenue from. My copying strictly for personal benefit has not deprived him of any legitimate revenue. My copying has in fact provided him with legitimate revenue". Of course there could be many counter-arguments like "Just use a normal DVD player with a normal TV".
Microdrives already work. Initially they were made for Compact Flash (IDE compatible) slots. This is doable for USB drives.
The current crop of portable USB drives are still physically a bit large. They can be made smaller as drive capacities go up. Try a 1.8" hard drive.
It's only more complicate ONCE for the engineer designing it (and only slightly more so). After that it's transparent to users.
A converged bus would be a compromise in a lot of ways. But I do believe it is feasible for a large portion of device connectivity, including just about everything now connected via USB, FW, or SATA. PCIe and DVI would pose some complications, but video up to a point could be handled over a single data pair (DVI has separate pairs for red, green, and blue). SATA shows us that we can do 3 GB data rates on metallic conductors. One problem is that all the connectors are bad designs. They are flimsey. They require exact orientation. And they have both male and female ends. My connector design would eliminate those issues.
My connector design would be a square connector (about the size of the device end of USB) with locking clips on 2 opposing sides, and holes to accept the locking clips on the remaining 2 sides. The design is to allow one connector to mate with one exactly like it rotated at 90 degrees. Inside the square would be two plastic parts shaped in diagonals with the 90 degree corners pointing at the center and at each other. The space between the diagonals would be where these parts from the incoming connector would fit. Think of the letter X where one connector has these plastic parts in the upper and lower gaps of the X and the incoming connector turned 90 degrees would fit with the parts on the left and right gaps. The contacts for data would be near the center on the sides of the diagonal parts. For data transmit, one contact would be on one of the parts, and the other contact would be on the other part at 180 degrees. So if you rotate the connector 180 degrees, you are only flipping the polarity of the wires making up the data transmit pair. The data receive pair would be on the other side of the parts, also near the center. Power (deliverable in both directions) would be on the same sides but further away from the center. The power polarity would have to be corrected with a bridge rectifier in the device taking power. Polarity on the data wires would be a non-issue since modern data encoding doesn't need this (e.g. edge-triggered, etc).
The middle of the diagonal parts would be reserved for future fiber usage with as many as 4 fibers between devices.
Using multi-level encodings, data speeds of 3 Gbits per second and higher are easily possible with metallic. While there would be separate transmit and receive pairs for simpler devices, the protocol could include a means to negotiate uni-directional bursting where at times both data pairs could be used at the same time in one direction to double the transfer rate in a specific direction. This could help handle uncompressed video to a monitor (while still allowing enough return bandwidth to let you plug the keyboard and mouse into the monitor, along with a touch screen sensor if you want.
The only real hindrance to converging all these technologies is people ... those who have some vested interest in each of the others.
Make that be 532nm wavelength light and we can use these in place of Wicked Lasers :-)
Or give us devices that don't need to consume so much power (and thus don't get as hot).
Maybe this would work for you.
I already have a plug design that, as one of its features, can be rotated 180 degrees when plugged in, and it still mates correctly for both data (separate pairs for each direction) and power (power can be supplied in either direction). The other feature is that not only is each end of the cable the same (at least for the same size class ... still need to allow for very tiny connectors for very tiny devices), the connector is asexual, meaning that it can mate with one of itself with just a 90 degree turn either way, with the data and power connections still made correctly (power polarity can be reversed, but a bridge rectifier can deal with that at the power usage end). Thus the connectors on the devices would actually be the same as the connectors on the cables. The only time you'd need a cable with different connectors on each end is when going between a large connector and a small connector (I think only 2 sizes would be needed, so this should be a minimal issue).
The connector would basically be square with locking clips on 2 sides, and holes on the other 2 sides to receive the locking clips from the incoming connector. Inside the connector square would be a pair of diagonal substrates arranged with the 90 degree angle corners pointing inward at each other. This would leave a pair of spaces for the mating connector to fit in. The data contacts would be on the sides close to the center. The power contacts would be on the same sides but further outward from the center. Data transmit would contact data receive on the other connector, with the polarity reversed if the connector is inserted at 180 degree rotation. But it would still be transmit connecting to receive (a total of 4 data wires). Power would similarly have 4 wires, 1 pair for power in one direction, and the other pair for power in the other direction. Devices not needing power just won't connect to the supplied power.
The only issue that you might have left is the issue of having normal size connectors (about the size of a device end of a standard size USB, or about the size of the 8P8C connector typically found on CAT5 cable), and tiny miniature connectors for devices too small to take a normal size connector. Cables could be made to have one size on one end and the other size on the other end, in which case you'd have to be sure you string up the cable with the correct end at the correct device.
By having the locking clips protrude from device mounted connectors by a slight amoung, maybe 0.5 to 1.0 mm, it would be possible to feel the connector hole to determine the alignment, whether the clips are horizontal or vertical relative to orientation of the device. Then just insert the cable at +90 or -90 degrees (either way will work).
I disagree.
It is possible to make a connector that when rotated 180 degrees still fits the mating connector and still lins up contacts. It would be a "180 degree rotation symmetric" connector. Then you simply assign the contacts such that when plugged in either way, the same pair always contacts each other. The difference would be a reversal of data polarity. And that is irrelevant as most technologies work on edge-trigger or can be made to do so. Power would either require a rectifier bridge at the receiving end to handle polarity flips, or the power would be done with both contacts being the same polarity (added current capacity) and the shield be the power return.
No, Germany has not slipped back into being a facist state. But it is slipping. There are elements in the government trying to give it a push in that very direction, just as there are similar elements in the USA. The problem is not enough people are pushing back. Until it becomes widely recognized what is happening, not enough people will. This is what happened in the 1920's and 1930's. People who warned others about what was to come were not taken seriously.
I agree: analogies to activities of the Schutzstaffel (SS) or its secret police, the Geheime Staatspolizei (Gestapo), are not accurate representations of what is going on. They are, however, a representation of what many people, including myself, believe could happen, or will happen (again), if people fail to become aware of these wrongs, and fail to put a stop to it. The visualizations from the late 1920's to the early 1940's just need to be put in the correct context of "what could be". Sadly for millions, people looked the other way when the NSDAP rose to power and committed so many atrocities. If they look the other way again in this case, and in similar cases likely to happen further, then nothing was learned and those millions died in vain.
Cable system operators would prefer to switch the system to 100% digital. They can't do it immediately for a couple major reasons. One of those reasons is the up front investment costs involved. The other reason is the need to service quite many customers in analog, especially the basic customers at the lowest pricing tier, likely to include grandma and grandpa with that old TV from the 1970's that still works. Eventually, however, cable systems will move to be 100% digital. A few have achieved this, already (and presumably supply a set-top box with analog output).
The reason digital is an advantage to the cable system is that it means they can offer more channels in whatever combination of standard definition and high definition they would end up with. It's even more of an advantage for cable than for broadcasters because cable can use QAM256 which has twice the bandwidth as the 8VSB modulation broadcasters use over the air. The 6 MHz of space a single analog channel uses could carry 2 to 3 HD channels at 1080i60 or 720p60 (typically found on over the air digital TV in the USA) or one channel at 1080p60 (the ultimate format many HD TVs can now handle but cannot be sent over the air at all). Or that same space could carry even more channels at various customized formats such as 3 to 5 channels at 1080p24 specifically optimized for movies, or 6 to 9 channels at 720p24 for slightly lesser definition movies. That same space could carry 12 to 20 standard definition channels at 480i60, or even 16 to 25 channels at an even slower 480p24 which is fine for programming like infomercials and shopping channels. Dozens of still frame music channels could also be carried in that 6 MHz of space.
More channels means more revenue for the cable companies, both from the providers supplying the programming as well as from tiered customers selecting that programming. Although cable companies might have to pay for highly recognized programming like CNN, the smaller programming providers typically have to pay the cable company to get on (especially where there aren't as many channels).
A cable system that still has some national channel carried over the wire in analog just hasn't gotten around to making the change, yet. Making these changes is not easy, and may invole carrying it in both forms for a while to be sure the set-top boxes pick up the change, and that customers tuning directly on cable ready digital tuners are made aware of the change. But in the next few years, cable systems will be making these changes, and will be adding more channels and more HD channels, and maybe even using more channel space for internet access.
Will this even interrupt online game play, where the game network keeps on running while your player gets beat to death and you lose all your treasures?
If I were driven to BSD ... GPLv3 itself won't, but it might for my customers ... it would be NetBSD. The reason is the wider support for a variety of embedded and small system architectures.
I don't hear any songs from MySpace when I visit (which is not very often). My solution is that my speakers are plugged into my router (a separate box running Slackware), instead. It has spare disk space (because I can't find drives smaller than 40 GB anymore), so I put my music collection over there (it isn't that big) and play it over there. Web site music just warms a few components on the mainboard sound chip. If there is ever something I do want to listen to via the browser or the desktop box, I can switch the audio connections.
As a good citizen of the internet, I think it a good thing that I don't clog the tubes with content the reader does not want to help support through a quick glance across a non-abusive, non-invasive, non-flashy, non-animated, non-popup, ad banner just in case there is something that might be of interest to them.
"boycottcingular.com" is now the new "boycottatt.com".