Nifty! If this plays out the right way, I may be able to drop my plans to abandon Debian on my servers.
I suppose if the new tech amounts to "live interactive chat session with a webcam musician", that might provide an experience that some people are willing to pay for that's difficult to pirate.
It's hard to imagine much else that would actually work.
The headline made me do a double-take. It's like asking "why is it taking so long to develop an invisibility cloak?" or "why is it taking so long to develop flying cars?".
Or can you give me one good, solid reason why an ordinary person would want to use a non-Google XMPP server?
Some employers provide on-site supported XMPP servers. Until recently, I've been able to use ours to collaborate with external partners on GTalk, using federation.
Some vendors provide built-in XMPP servers as part of other products. I'm aware of one telephony platform that does so and one IT helpdesk service that does so. Using their servers enables certain useful features, like "they look like text messages to phone users" and "customers can open issues with the help desk by sending them IMs". Those are more useful when federation works.
Some web service providers have XMPP support in their service platforms. I used to be able to have IFTTT send messages to me, due to federation. Google's announcement about turning off the service has caused them to remove the channel from their service entirely. Now I can't use it anymore.
(Those are just the ones that have been impacting me personally as of late. I'm sure others could think of more. No, they're not mainstream. Yes, they're real.)
As an analytics manager you want to see Excel? Why? If someone on your team can do everything else that you list, plus maybe Python, Octave or MATLAB then why would you want to dirty yourself with Excel?
At a guess; because a ton of the data you receive will come by default in Excel format, and because a ton of the recipients your'e going to be asked to deliver data to will want it in Excel format.
I've begun doing some analytics in my current job (which is pretty much all Unix, all server-side), and I'm finding this to be the case surprisingly often.
And perhaps we can agree that a level 2/10 would not likely get hired anywhere.
I'm not prepared to concede that. I'm also not prepared to concede that it should be the case.
If there are a large number of 2/10 programmers out there not getting hired, then more value can be extracted from the workforce if someone can come up with a sandbox or somesuch in which they can actually be used productively.
Maybe you get four of them and have them keep swapping off in pair-programming pairs. Maybe you only let them write code that goes into a continuous-integration server. Maybe you only let them write social games. (Heck, maybe you use them as living, breathing "fuzzing" tools for toolchain developers to use in debugging.) I don't know.
But the economy is better off if we can figure out how to extract value from them. (They should be paid very poorly compared to better programmers, however.)
it's not the act of recollection that causes the memory to decay.
What's your basis for saying so?
(I mean, it's trivially true that it's not the only thing that causes memory to decay. I'm not asking about that. Do you have a basis for saying that it's not a thing that causes memory to decay?)
The act of recollection might very well cause the memory to decay. Our brains may "wrap" it in a "macro" that "re-writes" it as we recollect it, so that it does not seem to decay as a side-effect of recollection. I'm not aware of data we have that would let us rule this out.
Based on that, I find the whole article suspect.
So you're uninterested in turning things on and off, and adjusting the volume?
I'm uninterested in "just one remote for everything". (Volume is not a problem.) I have seen that work out so rarely that I prefer to avoid situations where people attempt it.
Archaic. None of the "remotes" that I use in my living room are keyboards.
When I hear "remote," I think "something simple and dedicated that I can hold in one hand to easily control remotely-located things." I don't think "something with at least 60 buttons, some of which are actually useful, that takes up too much room on the coffee table, and functions only as a basic input for a single device."
Huh? I'm not talking about the remote being a keyboard, I'm talking about the remote identifying itself as a keyboard. It's the equivalent of bar-code scanners that you plug into a keyboard port and that "type" whatever you scan with them.
Keyboards have some buttons that are very good for remote control functions, like "up" and "down" and "left" and "right" and "enter" and "escape" and "pause/play" and "fast forward". Make a handheld stick with just those buttons, and have it pair over bluetooth as a keyboard, and that remote would then work with an Apple TV, an Ouya, a Fire TV, a Linux box running MythTV, a Windows box running Steam in big picture mode, et cetera, et cetera. That's what I'm talking about.
Neat. Now how easily does it switch between presentations, AppleTV and Ouya? Does it change inputs on the TV and/or AVR? Turn things on and back off again? Turn the volume up and down?
No? Oh. I'd consider that a lousy remote, then.
I see. There are features in a remote that I'm so uninterested in that I don't even think of them, that you consider absolutely essential. (Though a subset of those are easy. They could all be easy given specific device choices which I'm not going to assume.)
You and I will not like the same remotes.
...do not rely on monitoring system that treats a complete lack of information as a complete absence of incidents.
Is there any such thing as a "standard" Bluetooth remote?
Well, the device presents itself as bluetooth using the HID profile. That's a start.
Given that, I'd consider any remote that presents itself as a keyboard with well-defined keys to be extremely standard. (Remember, media control keys like "play/pause" and "fast forward" are well-defined and widely supported on keyboards already.)
Further, I'd consider any remote that presents itself as a gamepad with well-defined buttons to be extremely standard.
A remote that presented itself as a trackpad with standard buttons wouldn't be too bad either.
(I in fact often carry a bluetooth device that's remote-sized and is a full keyboard with integrated two-button trackpad and built-in laser pointer. It's hard to beat for presentations, and also controls my AppleTV and my Ouya very nicely.)
That said...if you want custom integration, Bluetooth is overkill. These things are implicitly already on the network. Just use IP.
That would currently require a bunch of one-off solutions, as there isn't a "standard wifi HID profile" to use. Myself, I'd rather have an app on my phone that presented itself to the world as a bluetooth keyboard or gamepad that I could then use even with devices that didn't have IP at all.
I know this isn't what you meant by "not wanting to give up our remotes," but am I the only one annoyed by Amazon for going with a bluetooth remote?
I don't know enough to answer that yet.
I would not really prefer IR.
If the bluetooth in use is extremely standard, so that other devices and even software can be used to "emulate" it, then I'm delighted, as I'll (eventually) be able to integrate the box with other stuff.
If it's doing something grossly nonstandard, that just happens to be implemented on top of bluetooth, then I'll be annoyed.
...I want to punch someone.
(I blame "The Tao of Physics" for instilling this basic drive in me.)
Specifically: Why do movie studios allow Netflix to send out DVDs to their subscribers by mail, but not to allow the same option in the form of "virtual DVDs" that you could "check out" through their website, and stream them while they're checked out to you?
As far as I know, they don't "allow Netflix to send out DVDs". Content owners have in the past tried to forbid media rentals, but failed. They don't "allow" Netflix to do this -- they simply have no legal standing to prevent it. They likely would if they could.
At least that's my understanding of things.
If these systems are still using XP today, my bet is that they only rely on a small, stable, well-established subset of what we consider today's Windows API. It really wouldn't surprise me at all if a whole bunch of the software involved built flawlessly with winelib.
Anyone know if that's how they're going about it?