Find me a parent who fully appreciates the effects and dangers of measles, mumps, and/or rubella.
The individual vaccines for those diseases were all produced in the 60's, so parents today weren't even born during their heyday. They've never experienced first hand the problems associated with these contagious, disfiguring diseases, to have the fear of... whatever, put into them.
You would be correct that I'm not in the security field, of course you're missing the point that hacking does not directly have anything to do with computer security. Just because mainstream media decides to abuse a word out of ignorance, making it something "evil" and "bad", does not mean you have to as well.
Right, it's the general term for any end user who "hacks together" their own tools and devices, rather than buy a commercial product. It has nothing to do with good or bad, but merely refers to the free-form development process outside of typical engineering methods. As I said, computer hacking implies you're writing your own code (or etching your own hardware).
DRM only works when you provide the data, and that data is difficult to reproduce. There's always the "analog hole", and the data you give a company that could potentially be protected by DRM would be transcribed in just a few minutes by some lowly data entry employee. That data is miniscule compared to the volumes of data on behavioral patterns that are collected completely outside your control.
An isolated MEMS is immune to electromagnetic pulses as the atmospheric saturation voltage is too low to produce sufficient potential in a system that small to damage it. If the MEMS is electrically connected to larger external systems, the potential across the contact points could be sufficient to cause damage.
Except that's called "cracking" or "conning", not "hacking". Infiltrating computer systems is only hacking in so far as you're writing code with which to do it. That's why "script kiddies" are not hackers.
Java is used because of rank misconceptions. The only value to Java is that the virtual machine is tied to the platform, rather than cooked into the binary, so you can in theory, run Java applications anywhere with a suitable version of the VM. PHBs making decisions get caught up in this concept, and fail to see the bigger picture.
When you're talking about software for embedded platforms, like the Bluray menu system, this makes some amount of sense. It allows you to write the software once, and then run it on any manufacturer's player, regardless of the underlying hardware. On the other hand, when you're talking about software for embedded platforms with limited resources, there's all that much more reason to custom tune the application for the hardware.
When you're talking about software for the server, it makes little sense. At a high level, you want to be able to re-architect your systems to run on whatever hardware or operating system you want, without rewriting your software. At a low level, you're going to invest so much in the management framework surrounding your hardware or operation system of choice, that you're never going to want to switch, but you still insisted on using Java. On top of that, even if you used C[++] for your application, the vast majority, if not all, of the code can simply be recompiled for whatever new platform you want to run on.
When you're talking about software for the desktop, it makes zero sense. Compiled applications are neat and tidy. They're self-contained. Java requires the user install some 3rd party runtime environment in which to run Java applications. That's a hassle, and a good portion of your user base is simply going to refuse, and use a competitor's software. This wouldn't be an issue if a Java VM can pre-installed, but it doesn't. At least with.NET on Windows, it's bundled in with first party updates, and disguised a bit.
As far as I know, the only reprocessing being done is refining, to separate out that small portion of mid-life product. No one is further transmuting that into something more desirable, because it simply doesn't make sense with respect to the energy requirements.
That's easy. Use filtration and centrifuges to separate out the short and long life products from the medium life products. Short half-life products are nasty, but you only have to store them for a few years, so no one cares. Long half-life products have too slow a decay rate to worry about, and some of them are useful as fuel. Whatever is left, just bombard it with more neutrons, or protons, whatever would be appropriate for transmuting it into something with a more convenient decay path.
The trouble is energy, and this kind of reprocessing takes a fuckton of it.
In a warehouse, actually. The only "interference" is from trying to get a signal through concrete and steel spaceframe. We brought an access point to connect to the equipment we were installing wirelessly, until the customer could get around to installing their own wireless infrastructure. It was a dual-band access point, and the 2.4GHz signal was significantly higher performance at range, for obvious reasons. Strangely enough, when the customer did install their infrastructure, it was 802.11a.
I didn't make the original post, nor do I agree with it, for the same reasons you outlined. I'm just informing Alomex he misunderstood Virtucon's post. I'm just the messenger, as it were, apparently shot while beating his wife.
I think what Virtucon was trying to complain about, but failed miserably in conveying, was not the claim that someone was trying to insert a backdoor into the Linux kernel, but that that someone was the NSA, as there is zero evidence to point to any suspect.
No. The AC is saying that even though most people are only using their wireless access point for access to their internet connection, and their internet access is only 25Mbps, they will still feel the need to use an entire 160MHz swath (or be too ignorant to configure it to not use that much spectrum).
Combined with further reduction in range. With an ASUS N56U, in the middle of nowhere with no interference, 2.4GHz becomes unreliable at around 700ft. 5GHz drops out somewhere around 450ft.
But still, this is the first I've heard of any DVI devices doing audio out the DVI port.
I've never had a card send audio out a DVI port, but I have had a card cause problems by claiming it did. A GeForce 8400 using an adapter and plugged into a Samsung TV made the TV expect audio from the card, which it was never going to get, and prevented the use of an alternate audio input. I had to force feed the drivers a manipulated EDID block that had the extended features disabled. The card no longer thought the TV supported audio, no longer told the TV it was sending audio, and the TV then allowed the use of an analog audio input.
I suppose you are just confused as to the definition of electrical compatibility then.
Perhaps. I consider the signal to be part of "electrical", but that may not be accurate. If the signal has to change, and be put into a compatibility mode, then I would not consider the HDMI signal to be directly compatible.
However, the question ultimately comes down to this. On a DVI port, do you assume your endpoint will be HDMI, behave as HDMI, and fall back to DVI if needed, or do you assume DVI, and only allow the features of HDMI if an external cue tells you to do so? Most people choose the first option. AMD seems to have chosen the second option. The first option "just works" more easily, and seems to have worked fine for years with no issues I've heard of, but the second option is arguably more proper.
HDMI interleaves video, audio and auxiliary data using three different packet types, called the Video Data Period, the Data Island Period and the Control Period.
No. DVI-D is basically a digital form of VGA. You have three channels, one each for red, green, and blue, and raw pixel data streamed across them. HDMI has three channels, but they are used as generic data channels, with the pixel data being stuffed into packets, with a header and parity data.
No. It isn't. DVI has three wire pairs for individual red, green, and blue color channels, streaming the pixel data across them. It's basically VGA, but in digital form. HDMI takes those three wire pairs and turns them into generic data channels, grouping audio, pixel, and other data into packets, with headers and parity, before sending them over the wire. DVI and HDMI are very different protocols. Their similarity is only physical. DVI and HDMI equipment is only compatible because the HDMI spec requires that HDMI equipment be able to speak the older DVI protocol.
Slashdot Mirror
Even were there any scientific validity in that line of reasoning, do these people have any idea how selfish they're being?
Find me a parent who fully appreciates the effects and dangers of measles, mumps, and/or rubella.
The individual vaccines for those diseases were all produced in the 60's, so parents today weren't even born during their heyday. They've never experienced first hand the problems associated with these contagious, disfiguring diseases, to have the fear of... whatever, put into them.
No it doesn't. It's just a passive cable. That's like saying CAT6 has DRM built into it.
You would be correct that I'm not in the security field, of course you're missing the point that hacking does not directly have anything to do with computer security. Just because mainstream media decides to abuse a word out of ignorance, making it something "evil" and "bad", does not mean you have to as well.
Right, it's the general term for any end user who "hacks together" their own tools and devices, rather than buy a commercial product. It has nothing to do with good or bad, but merely refers to the free-form development process outside of typical engineering methods. As I said, computer hacking implies you're writing your own code (or etching your own hardware).
DRM only works when you provide the data, and that data is difficult to reproduce. There's always the "analog hole", and the data you give a company that could potentially be protected by DRM would be transcribed in just a few minutes by some lowly data entry employee. That data is miniscule compared to the volumes of data on behavioral patterns that are collected completely outside your control.
An isolated MEMS is immune to electromagnetic pulses as the atmospheric saturation voltage is too low to produce sufficient potential in a system that small to damage it. If the MEMS is electrically connected to larger external systems, the potential across the contact points could be sufficient to cause damage.
Except that's called "cracking" or "conning", not "hacking". Infiltrating computer systems is only hacking in so far as you're writing code with which to do it. That's why "script kiddies" are not hackers.
Java is used because of rank misconceptions. The only value to Java is that the virtual machine is tied to the platform, rather than cooked into the binary, so you can in theory, run Java applications anywhere with a suitable version of the VM. PHBs making decisions get caught up in this concept, and fail to see the bigger picture.
When you're talking about software for embedded platforms, like the Bluray menu system, this makes some amount of sense. It allows you to write the software once, and then run it on any manufacturer's player, regardless of the underlying hardware. On the other hand, when you're talking about software for embedded platforms with limited resources, there's all that much more reason to custom tune the application for the hardware.
When you're talking about software for the server, it makes little sense. At a high level, you want to be able to re-architect your systems to run on whatever hardware or operating system you want, without rewriting your software. At a low level, you're going to invest so much in the management framework surrounding your hardware or operation system of choice, that you're never going to want to switch, but you still insisted on using Java. On top of that, even if you used C[++] for your application, the vast majority, if not all, of the code can simply be recompiled for whatever new platform you want to run on.
When you're talking about software for the desktop, it makes zero sense. Compiled applications are neat and tidy. They're self-contained. Java requires the user install some 3rd party runtime environment in which to run Java applications. That's a hassle, and a good portion of your user base is simply going to refuse, and use a competitor's software. This wouldn't be an issue if a Java VM can pre-installed, but it doesn't. At least with .NET on Windows, it's bundled in with first party updates, and disguised a bit.
As far as I know, the only reprocessing being done is refining, to separate out that small portion of mid-life product. No one is further transmuting that into something more desirable, because it simply doesn't make sense with respect to the energy requirements.
That's easy. Use filtration and centrifuges to separate out the short and long life products from the medium life products. Short half-life products are nasty, but you only have to store them for a few years, so no one cares. Long half-life products have too slow a decay rate to worry about, and some of them are useful as fuel. Whatever is left, just bombard it with more neutrons, or protons, whatever would be appropriate for transmuting it into something with a more convenient decay path.
The trouble is energy, and this kind of reprocessing takes a fuckton of it.
In a warehouse, actually. The only "interference" is from trying to get a signal through concrete and steel spaceframe. We brought an access point to connect to the equipment we were installing wirelessly, until the customer could get around to installing their own wireless infrastructure. It was a dual-band access point, and the 2.4GHz signal was significantly higher performance at range, for obvious reasons. Strangely enough, when the customer did install their infrastructure, it was 802.11a.
I didn't make the original post, nor do I agree with it, for the same reasons you outlined. I'm just informing Alomex he misunderstood Virtucon's post. I'm just the messenger, as it were, apparently shot while beating his wife.
I think what Virtucon was trying to complain about, but failed miserably in conveying, was not the claim that someone was trying to insert a backdoor into the Linux kernel, but that that someone was the NSA, as there is zero evidence to point to any suspect.
That's a cost on the customer, not the manufacturer.
In an effort to reduce costs, they have universally changed to using switch-mode supplies.
And here I thought we switched to the far more complex switched mode power supplies because linear ones have terrible efficiency and power factor.
In the 1930s, a single AM broadcast tower could cover most of a region in the US in the evening.
That's because back in the 1930s, AM stations like WLW were operating at half a megawatt.
No. The AC is saying that even though most people are only using their wireless access point for access to their internet connection, and their internet access is only 25Mbps, they will still feel the need to use an entire 160MHz swath (or be too ignorant to configure it to not use that much spectrum).
Switch to 5GHz and you should see an improvement
Combined with further reduction in range. With an ASUS N56U, in the middle of nowhere with no interference, 2.4GHz becomes unreliable at around 700ft. 5GHz drops out somewhere around 450ft.
But still, this is the first I've heard of any DVI devices doing audio out the DVI port.
I've never had a card send audio out a DVI port, but I have had a card cause problems by claiming it did. A GeForce 8400 using an adapter and plugged into a Samsung TV made the TV expect audio from the card, which it was never going to get, and prevented the use of an alternate audio input. I had to force feed the drivers a manipulated EDID block that had the extended features disabled. The card no longer thought the TV supported audio, no longer told the TV it was sending audio, and the TV then allowed the use of an analog audio input.
I suppose you are just confused as to the definition of electrical compatibility then.
Perhaps. I consider the signal to be part of "electrical", but that may not be accurate. If the signal has to change, and be put into a compatibility mode, then I would not consider the HDMI signal to be directly compatible.
However, the question ultimately comes down to this. On a DVI port, do you assume your endpoint will be HDMI, behave as HDMI, and fall back to DVI if needed, or do you assume DVI, and only allow the features of HDMI if an external cue tells you to do so? Most people choose the first option. AMD seems to have chosen the second option. The first option "just works" more easily, and seems to have worked fine for years with no issues I've heard of, but the second option is arguably more proper.
I can quote too!
DVI
DVI does not use packetization, but rather transmits the pixel data as if it were a rasterized analog video signal.
HDMI
HDMI interleaves video, audio and auxiliary data using three different packet types, called the Video Data Period, the Data Island Period and the Control Period.
No. DVI-D is basically a digital form of VGA. You have three channels, one each for red, green, and blue, and raw pixel data streamed across them. HDMI has three channels, but they are used as generic data channels, with the pixel data being stuffed into packets, with a header and parity data.
No. It isn't. DVI has three wire pairs for individual red, green, and blue color channels, streaming the pixel data across them. It's basically VGA, but in digital form. HDMI takes those three wire pairs and turns them into generic data channels, grouping audio, pixel, and other data into packets, with headers and parity, before sending them over the wire. DVI and HDMI are very different protocols. Their similarity is only physical. DVI and HDMI equipment is only compatible because the HDMI spec requires that HDMI equipment be able to speak the older DVI protocol.
Perhaps those fresh graduates shouldn't have spent $100K on a low-paying career path. Poor life choices are ones own fault.