Many have commented how similar it is to Netflix selection. Did amazon happen to negotiate some deal or is amazon including some sort of rebranding agreement as a subset of their selection?
I was thinking since Netflix uses Amazon as a hosting provider if some sort of agreement was struck..
I mostly agree with the sentiment, analyze a failure in place before rebooting. In fact, for a *problem*, I agree that it is a particularly bad time to blindly reboot.
For updates, in practice, I disagree. In theory, he is right that very very few updates *demand* a kernel replacement and all other updates *should* be possible through restarting the 'right' things. In practice, there are significant problems.
First, some kernel modules are written.. sub optimally and cause unrecoverable issues if unloaded or will not work right on reload. Some drivers are written and only tested with a PCI reset and POST cycle between driver changes. Sometimes reloading a driver if the firmware was updated during runtime will confuse a system. Downing some modules will remove functionality that is required for the system to run well enough to load the module again. Many of these are issues that if you knew in advance would induce you to pick a different vendor, but they are usually only apparent after it is too late.
Secondly, depending on your Unix/Linux choice, updates may not be available of 'just' the modules you need or even clarify whether the updates are in the kernel or modules. A linux distro generally dumps a single update of kernel *and* modules. Even if you *knew* the kernel didn't have critical fixes, modprobe may refuse to load new ones against other kernels. 'Real' Unix *tends* to be potentially better on the latter point, and you *might* be able to comb over the updates with a fine tooth comb, hand-patch the source for the kernel tree that matches your running kernel, build and load. However, this is a ton more work and way riskier than 'just' rebooting.
Finally, *particularly* with shared library vulnerabilities, there is a slim chance in practice you'll understand all the processes currently executing on your system enough to be 100% confident you'll hit all in-memory instances of buggy/vulnerable code. Figuring out the 'right' processes to restart or end is generally a larger logistical challenge.
In general, reboots should be feared in terms of disrupting identifying root cause, but updates and periodic sanity testing to make sure your system on startup actually works and matches how you expect it to be configured. If the service is critical enough to make people worry about reboot induced outage, then the service is not properly configured to run in a manner conducive to mission critical reliability (another server should be able to transparently take up load).
The idea is to encapsulate a number of digital protocols (nothing unique to Light Peak, Displayport in theory supports ethernet and usb packets in addition to audio and video data, for example.
You will need something to convert it to analog, and that will remain a niche market with high prices as a result. You won't get a magical RCA out from this.
I also doubt you can't replace the display portion of your churches setup with something that would accept both displayport *and* RCA in (not requiring replacing cameras and other equipment). I also don't know why *your* current laptop must be the technology everything else revolves around in this configuration
Tricky part is 'effective'is not an absolute qualifier.
So in a theoretical cryptographic sense, DRM is a lost game by definition. In practice, DRM is enough of a PITA to have some effect. Also in practice, though, DRM is a thorough PITA only to legitimate customers trying to do the 'right' thing. DRM is hardly a mild nuisance to the people it is ostensibly there to stop.
This is mostly a statement about media that, once decrypted, can be played on an arbitrary device. Games present an interesting twist. In PS3 for example, unencrypted game content won't get you far without a cell processor, GPU, and GameOS which isn't available aside from Sony, increasing their ability to make it less practical to bypass without modifying what Sony gives you.
I would say it makes no *rational* sense for anything to change merely for the sake of changing even if it is commercial sofrtware.
There is a perception issue that if you have no plans to fiddle with software in a user-visible way then your project is stagnant and being 'abandoned'. You are never allowed to think you got it right (admittedly getting it 'right' is rare and highly subjective).
I don't disagree that URLs are intended to be human-entry friendly (though probably more due to phishing which was probably not anticipated), but DNS allows more than just humans reading and typing the right thing.
For example, an application can dictate server by DNS and the application provider can renumber due to provider change or whatever without disrupting connectivity.
Some are hoping for a magical IPv7 that would magically 'just work' with IPv4 without any messy backwards compatible issues. None of those understand the problem, but assume there must have been *some* way to do it without losing our quad-dotted addresses or rewriting or recompiling a single thing. Like 'why not just raise the limit on the numbers from 255 to a thousand or something?' or 'just add another dot-number at the end'.
The researchers intentionally ignored category literal name as they were more likely to get misled than helped by the category.
Example, category of 'Country Clubs' referring to blunt weapons in various nations instead of places to play golf. Or 'Writers' having an answer with a writer name looking for a book name instead of the name of a writer.
An AM2+ has no memory controller on the motherboard, just like AM3. The on die memory controller *does* support both DDR2 and DDR3, but not on the same motherboard.
The memory/bus architecture was concurrent with amd64. In one burst they completely disrupted Intel (Hypertransport, integrated memory controllers, *and* Itanium-killing AMD64), and ever since hasn't brought forth unique, mind-blowingly awesome tech that Intel does not have, though they have continued to be competitive particularly when it comes to pricing.
It took Intel a loooong time to catch up (basically Nehalem, which happened *years* after the first HT, AMD64 processor), but they have and now...
(where hypertransport is still enough of a factor to make up for intel's better cores),
Except Intel does QPI which is pretty well equivalent technically. One could make a competent argument that AMD is more aggressive and pricing parts with enough links for 4/8 socket at the same level Intel is doing parts with only 2 socket capability, but the EX Intel stuff is technically capable of competing with AMD *if* you ignore the pricing structure.
If you want any indication of how important *Intel* x86 is to them, look at their current product line. They used to carry Blade and 2S server models with AMD. Now they just have a 4S box available. One could argue that 2S doesn't make sense with AMD's current architecture to explain away the missing 2S servers, but the Blade omission seems pretty glaring.
IBM is firmly in the Intel camp, and they would do nothing to threaten that in a head-on capacity (doing things with ARM and POWER are a little less direct).
On the flipside, after bringing about that awesome bus/memory architecture, they haven't made any particularly exciting breakthroughs ever since and Intel has caught up on that front.
Sometimes you have the right people and leadership to have an overwhelming improvement like HyperTransport to make you a clear market leader. Often times, that set of people turns out to be a one-trick pony and/or gets sucked out by companies willing to pay them more.
I agree that purchasing AMD would be odd, PowerPC pretty much left Apple at the mercy of Motorola and IBM in the same way they are at the mercy of AMD and Intel today. I think the straw that broke the camel's back was that Apple could not get IBM to compete with Intel in the low-power arena and Apple was pretty much powerless to get what they wanted because it was all IBM at that point. History is kind of repeating with x86 v. ARM for them currently in the space that really matters to them (i.e. Mac desktops/laptops are barely a blip against the larger iPhone/iTunes market) making an x86 investment on the scale of purchasing AMD a bad idea. The long shot would be purchasing for GPUs, but so far no one has proven they can do awesome stuff in the power envelope given on that front and the current 'good enough' GPU capability may limit the usefulness of ATI.
I would have considered that just enhanced switching (it solves a lot of topology problems with large layer 2 ethernet networks, but still would have issues with broadcast in widespread deployment). I know a lot of the terminology says 'routing', but it just seems more logically close to sane enhancements to switching than routing. I recognize at some point the distinction between 'switching' and 'routing' gets blurry.
Is that *no* x86 processor is going to appeal relative to their ARM for low-power applications. AMD has an edge for capable integrated graphics, but all in all the x86 offerings are not going to improve by going to AMD with respect to heat/battery concerns.
We are talking about a chip design company that is at best second-place in most business concerns (GPU sometimes in an exception).
In the CPU industry, you are talking about a move that would severely alienate Intel, a valuable partner in the server arena at the moment. Further complicating things is that a lot of consumer electronics are on the ARM platform, with an ever-increasing chunk, and I don't think AMD has licensed that platform.
On the GPU front, they would be alienating nVidia.
Either by choice or force, you'd see Dell's competitors stop selling AMD products, and maybe medium-term some AMD loyalists will follow Dell, but overall you'd see people giving up on AMD as an invitation for total platform lock-in.
ssh in with root key is fine for small teams, but su and sudo provide more likely audit trail to know who to chew out when they make a mistake.
This is one reason I actually prefer sudo, it *tends* to give a more precise audit log than su. The danger of su is that people tend to su and stay root even after they finish the usually small portion of the work that needs root, and *sudo* actually tends to make them think about each commands needs. Ok, that's not true, in practice people sudo -s and dick around just like su, but I can dream.
One is most 'FCoE' equipment had FC and ethernet ports, so there was a hardware difference.
Another is FCoE generally means the ethernet switch has some FC layer management features (e.g. looking at WWN, zoning, etc). I think this is the *key* priced modification for most FCoE equipment without FC ports. Basically making a way of dealing with the switches exactly the way storage admins are accustomed to dealing with SAN switches.
Finally, there are some layer 2 features considered essentially mandatory for 'decent' FCoE (more advanced pause frames, for one).
I still haven't found anyone getting excited about FCoE, even if it doesn't cost more. The storage admins I've met by and large hate the way they have been required to deal with their equipment.
Actually, FC isn't routable. FC over *ethernet* has no ip and no provisions to span gateways. The *theory* is that FCoE has fewer layers allowing for higher performance, but it's rare for that difference to be realized in cheap ethernet fabrics (the whole point of FCo*E*) and even rarer to matter relative to storage device performance limitations. iSCSI is much easier to manage with fewer limitations and gets some nice things from being over TCP whether FCoE people will admit it or not.
When FCoE first came to market, vendors had dollarsigns in their eyes with thoughts of extorting customers with FC pricing strategies using 'just' ethernet. You saw people trying to do per-port FC enablement licensing BS and other stuff unheard of in ethernet land.
If FCoE is going to exist long term, it will be as a 'freebie' alternative to iSCSI or as a convenience to build large SANs without a lot of FC switches and HBAs but using existing FC enclosures.
If their position is so strong (outselling Android), then doing any sort of platform burning is sheer madness. So to make this drastic move in the first place, the supporting fact of 'outsells Android' has to be presumed to be faltering.
If they've decided they *are* losing on platform but have good hardware, then binding themselves *exclusively* to the MS offering seems dubious. They said their number one priority is knocking out Android's share. If they aren't propping up their own platform, they shouldn't put their business on the line for the sake of MS when they can hedge their bets and do both.
IBM has zero business in the laptop/desktop market. They would be ecstatic with all Mac shops with the current state of Apple not giving a crap about the datacenter compared to all HP or all Dell.
Slashdot Mirror
Many have commented how similar it is to Netflix selection. Did amazon happen to negotiate some deal or is amazon including some sort of rebranding agreement as a subset of their selection?
I was thinking since Netflix uses Amazon as a hosting provider if some sort of agreement was struck..
I mostly agree with the sentiment, analyze a failure in place before rebooting. In fact, for a *problem*, I agree that it is a particularly bad time to blindly reboot.
For updates, in practice, I disagree. In theory, he is right that very very few updates *demand* a kernel replacement and all other updates *should* be possible through restarting the 'right' things. In practice, there are significant problems.
First, some kernel modules are written.. sub optimally and cause unrecoverable issues if unloaded or will not work right on reload. Some drivers are written and only tested with a PCI reset and POST cycle between driver changes. Sometimes reloading a driver if the firmware was updated during runtime will confuse a system. Downing some modules will remove functionality that is required for the system to run well enough to load the module again. Many of these are issues that if you knew in advance would induce you to pick a different vendor, but they are usually only apparent after it is too late.
Secondly, depending on your Unix/Linux choice, updates may not be available of 'just' the modules you need or even clarify whether the updates are in the kernel or modules. A linux distro generally dumps a single update of kernel *and* modules. Even if you *knew* the kernel didn't have critical fixes, modprobe may refuse to load new ones against other kernels. 'Real' Unix *tends* to be potentially better on the latter point, and you *might* be able to comb over the updates with a fine tooth comb, hand-patch the source for the kernel tree that matches your running kernel, build and load. However, this is a ton more work and way riskier than 'just' rebooting.
Finally, *particularly* with shared library vulnerabilities, there is a slim chance in practice you'll understand all the processes currently executing on your system enough to be 100% confident you'll hit all in-memory instances of buggy/vulnerable code. Figuring out the 'right' processes to restart or end is generally a larger logistical challenge.
In general, reboots should be feared in terms of disrupting identifying root cause, but updates and periodic sanity testing to make sure your system on startup actually works and matches how you expect it to be configured. If the service is critical enough to make people worry about reboot induced outage, then the service is not properly configured to run in a manner conducive to mission critical reliability (another server should be able to transparently take up load).
But you can run audio, video, ethernet, and USB over displayport and displayport has 20 Gb/s.
I don't understand why do a new tech when a standard already exists with twice the bandwidth and an eye for encapsulating other common needs.
The idea is to encapsulate a number of digital protocols (nothing unique to Light Peak, Displayport in theory supports ethernet and usb packets in addition to audio and video data, for example.
You will need something to convert it to analog, and that will remain a niche market with high prices as a result. You won't get a magical RCA out from this.
I also doubt you can't replace the display portion of your churches setup with something that would accept both displayport *and* RCA in (not requiring replacing cameras and other equipment). I also don't know why *your* current laptop must be the technology everything else revolves around in this configuration
That thing is a relatively chunky system even compared to some laptops in the market that are lamented as too large.
A manufacturer would find a customer base that rounds to zero with an offering like this.
Tricky part is 'effective'is not an absolute qualifier.
So in a theoretical cryptographic sense, DRM is a lost game by definition. In practice, DRM is enough of a PITA to have some effect. Also in practice, though, DRM is a thorough PITA only to legitimate customers trying to do the 'right' thing. DRM is hardly a mild nuisance to the people it is ostensibly there to stop.
This is mostly a statement about media that, once decrypted, can be played on an arbitrary device. Games present an interesting twist. In PS3 for example, unencrypted game content won't get you far without a cell processor, GPU, and GameOS which isn't available aside from Sony, increasing their ability to make it less practical to bypass without modifying what Sony gives you.
I would say it makes no *rational* sense for anything to change merely for the sake of changing even if it is commercial sofrtware.
There is a perception issue that if you have no plans to fiddle with software in a user-visible way then your project is stagnant and being 'abandoned'. You are never allowed to think you got it right (admittedly getting it 'right' is rare and highly subjective).
I don't disagree that URLs are intended to be human-entry friendly (though probably more due to phishing which was probably not anticipated), but DNS allows more than just humans reading and typing the right thing.
For example, an application can dictate server by DNS and the application provider can renumber due to provider change or whatever without disrupting connectivity.
Some are hoping for a magical IPv7 that would magically 'just work' with IPv4 without any messy backwards compatible issues. None of those understand the problem, but assume there must have been *some* way to do it without losing our quad-dotted addresses or rewriting or recompiling a single thing. Like 'why not just raise the limit on the numbers from 255 to a thousand or something?' or 'just add another dot-number at the end'.
The researchers intentionally ignored category literal name as they were more likely to get misled than helped by the category.
Example, category of 'Country Clubs' referring to blunt weapons in various nations instead of places to play golf. Or 'Writers' having an answer with a writer name looking for a book name instead of the name of a writer.
An AM2+ has no memory controller on the motherboard, just like AM3. The on die memory controller *does* support both DDR2 and DDR3, but not on the same motherboard.
The memory/bus architecture was concurrent with amd64. In one burst they completely disrupted Intel (Hypertransport, integrated memory controllers, *and* Itanium-killing AMD64), and ever since hasn't brought forth unique, mind-blowingly awesome tech that Intel does not have, though they have continued to be competitive particularly when it comes to pricing.
It took Intel a loooong time to catch up (basically Nehalem, which happened *years* after the first HT, AMD64 processor), but they have and now...
The problem is that covers 'what' is done but not 'who' if you never provide a username other than root to the system execing the commands.
(where hypertransport is still enough of a factor to make up for intel's better cores),
Except Intel does QPI which is pretty well equivalent technically. One could make a competent argument that AMD is more aggressive and pricing parts with enough links for 4/8 socket at the same level Intel is doing parts with only 2 socket capability, but the EX Intel stuff is technically capable of competing with AMD *if* you ignore the pricing structure.
If you want any indication of how important *Intel* x86 is to them, look at their current product line. They used to carry Blade and 2S server models with AMD. Now they just have a 4S box available. One could argue that 2S doesn't make sense with AMD's current architecture to explain away the missing 2S servers, but the Blade omission seems pretty glaring.
IBM is firmly in the Intel camp, and they would do nothing to threaten that in a head-on capacity (doing things with ARM and POWER are a little less direct).
On the flipside, after bringing about that awesome bus/memory architecture, they haven't made any particularly exciting breakthroughs ever since and Intel has caught up on that front.
Sometimes you have the right people and leadership to have an overwhelming improvement like HyperTransport to make you a clear market leader. Often times, that set of people turns out to be a one-trick pony and/or gets sucked out by companies willing to pay them more.
I agree that purchasing AMD would be odd, PowerPC pretty much left Apple at the mercy of Motorola and IBM in the same way they are at the mercy of AMD and Intel today. I think the straw that broke the camel's back was that Apple could not get IBM to compete with Intel in the low-power arena and Apple was pretty much powerless to get what they wanted because it was all IBM at that point. History is kind of repeating with x86 v. ARM for them currently in the space that really matters to them (i.e. Mac desktops/laptops are barely a blip against the larger iPhone/iTunes market) making an x86 investment on the scale of purchasing AMD a bad idea. The long shot would be purchasing for GPUs, but so far no one has proven they can do awesome stuff in the power envelope given on that front and the current 'good enough' GPU capability may limit the usefulness of ATI.
I would have considered that just enhanced switching (it solves a lot of topology problems with large layer 2 ethernet networks, but still would have issues with broadcast in widespread deployment). I know a lot of the terminology says 'routing', but it just seems more logically close to sane enhancements to switching than routing. I recognize at some point the distinction between 'switching' and 'routing' gets blurry.
Is that *no* x86 processor is going to appeal relative to their ARM for low-power applications. AMD has an edge for capable integrated graphics, but all in all the x86 offerings are not going to improve by going to AMD with respect to heat/battery concerns.
For Dell.
We are talking about a chip design company that is at best second-place in most business concerns (GPU sometimes in an exception).
In the CPU industry, you are talking about a move that would severely alienate Intel, a valuable partner in the server arena at the moment. Further complicating things is that a lot of consumer electronics are on the ARM platform, with an ever-increasing chunk, and I don't think AMD has licensed that platform.
On the GPU front, they would be alienating nVidia.
Either by choice or force, you'd see Dell's competitors stop selling AMD products, and maybe medium-term some AMD loyalists will follow Dell, but overall you'd see people giving up on AMD as an invitation for total platform lock-in.
ssh in with root key is fine for small teams, but su and sudo provide more likely audit trail to know who to chew out when they make a mistake.
This is one reason I actually prefer sudo, it *tends* to give a more precise audit log than su. The danger of su is that people tend to su and stay root even after they finish the usually small portion of the work that needs root, and *sudo* actually tends to make them think about each commands needs. Ok, that's not true, in practice people sudo -s and dick around just like su, but I can dream.
One is most 'FCoE' equipment had FC and ethernet ports, so there was a hardware difference.
Another is FCoE generally means the ethernet switch has some FC layer management features (e.g. looking at WWN, zoning, etc). I think this is the *key* priced modification for most FCoE equipment without FC ports. Basically making a way of dealing with the switches exactly the way storage admins are accustomed to dealing with SAN switches.
Finally, there are some layer 2 features considered essentially mandatory for 'decent' FCoE (more advanced pause frames, for one).
I still haven't found anyone getting excited about FCoE, even if it doesn't cost more. The storage admins I've met by and large hate the way they have been required to deal with their equipment.
Actually, FC isn't routable. FC over *ethernet* has no ip and no provisions to span gateways. The *theory* is that FCoE has fewer layers allowing for higher performance, but it's rare for that difference to be realized in cheap ethernet fabrics (the whole point of FCo*E*) and even rarer to matter relative to storage device performance limitations. iSCSI is much easier to manage with fewer limitations and gets some nice things from being over TCP whether FCoE people will admit it or not.
When FCoE first came to market, vendors had dollarsigns in their eyes with thoughts of extorting customers with FC pricing strategies using 'just' ethernet. You saw people trying to do per-port FC enablement licensing BS and other stuff unheard of in ethernet land.
If FCoE is going to exist long term, it will be as a 'freebie' alternative to iSCSI or as a convenience to build large SANs without a lot of FC switches and HBAs but using existing FC enclosures.
I think Nokia is running a big risk here.
If their position is so strong (outselling Android), then doing any sort of platform burning is sheer madness. So to make this drastic move in the first place, the supporting fact of 'outsells Android' has to be presumed to be faltering.
If they've decided they *are* losing on platform but have good hardware, then binding themselves *exclusively* to the MS offering seems dubious. They said their number one priority is knocking out Android's share. If they aren't propping up their own platform, they shouldn't put their business on the line for the sake of MS when they can hedge their bets and do both.
IBM has zero business in the laptop/desktop market. They would be ecstatic with all Mac shops with the current state of Apple not giving a crap about the datacenter compared to all HP or all Dell.