I mean did he try to just daisy chain them? He claims that he wanted to use DisplayPort 1.4 for connectivity. But the monitors do support daisy chaining over thunderbolt, and he also states that. But why not daisy chain? I mean I get that it's frustrating to get the thing working with DisplayPort, dongles and docks. But the best solution was right in front of him?
When initiating a new conversation, the number you add to it appears blue if they can receive iMessages, green if not.
If for some reason iMessages can't be delivered to the receiving party at the moment. Text messages are used as a fallback for them. If you disable the fallback mode. It won't be.
The whole thing is kinda intuitive, and works really smooth IMHO.
IBM getting involved in something is usually a death sentence. Initially they might inspire hope. But they'll turn everything into a horrible mess lacking those polishing touches that makes stuff nice to work with. They'll tick feature check-boxes. But the stuff will barely be usable.
Well, tools is probably not the right wording. But solutions for making systems accessible over web APIs. There's usually in-house solutions. But IBMs own, "IWS"(https://www.ibm.com/support/pages/integrated-web-services-ib...), is probably the main one I've heard of. I can't really remember all the solutions to serve up html pages.
It works. You pass stuff in and out through what would best be described as ARGV. Some Java middleware and so on analyzes the program to determine the amount, name and length of in and out variabels.
The process is that you choose to deploy a service, choose between SOAP and "REST" and point to your program. You then get to specify the resource name, description and a regexp for your path. The resource name becomes a part of the URL. You then specify which variables are input and which are output. And after that assign some generic settings and choose which variabels are sent in as a part of the path and not and so on.
Works sorta nice. Some drawbacks are that you'll still need to add rewrite rules to get actual restful URLs, since the URL of your service will be along the lines of http://example.com/web/services/<resource name/<your regexp>. If your program is written in COBOL instead of RPG, all variable names will be in all cap. There's a max size to how much data you can send in or return that's not super small, but around a few MB unless my memory fails me.
I mean it's almost there, just not really good if you ask me. It could use some love. Also anything you're unsure of results in you having to dig into the hell hole that is IBMs website. Not exactly made easier by some buffoon naming the platform as such into a three letter name of one of the worlds biggest companies followed by a space and a single letter. So google is worse than useless.
I've found most in-house solutions to be more reliable.
I've done COBOL based web stuff on the IBM i/AS400. Nothing particularly tricky about it, wouldn't really recommend it for anything super complex. But it's less of a hassle then the various "tools" that's ment to make it easier, which always have horrible browser based configuration interfaces and stupid limitations. Just point Apache to a binary, read environmental variables and print to stdout. Using it doesn't really make sense as such, but developers who only know COBOL can just write regular programs and be done with it.
Unless my memory fails me, selecting them in the volume drop down is enough. No need to fiddle with the bluetooth menu. But I could be wrong as I'm currently not at a Mac.
I have not checked the details, but I read it as someone who held a share in Ebay+PayPal prior to PayPal being spun of got an Ebay share + X PayPal shares at the time of the spinoff. I don't think PayPal was bought for $50B, it was valued as that as a separate entity. The PayPal share has doubled in value since the split.
Because their funds are easier to track. And easier to prove that they belong to them. Someone just needs to get your keys off you and there's that. You've got nothing on them.