To my knowledge for screen:
-screen can target ptys/realserial ports. Useful alternative to minicom or similar. Nowadays it's the most likely application to be installed 'by chance' with that capability (once upon a time, I would generally find cu, but that's almost never around by chance anymor)
-a split screen can have different people typing concurrently in different panes.

tmux more gracefully handles multiple terminal sizes connecting and tends to keep you from leaving a shared attach behind when you start trying to do split and such. tmux naturally understands terminal title set sequence and has more handy access to a lot of the best tricks. So 95% of the time tmux hits what is more important to me, but I do get a bit put out when I have a desire to take care of one of the above cases.

Of the people who still use watches, they do it precisely because they want just the time with batteries that go on forever or even don't use batteries at all, or consider the device as more an art piece or fashion statement than a practical tool.

Sure, some may go to smartwatches, but I'm wagering the vast majority of the opportunity for smartwatches are people who don't bother with a watch anymore because they've already gone to 'just phones'. In other words, the extent to which the 'non-luddite' market erodes the wristwatch industry has already happened.

The current concept is extremely far from being even slightly practical..

-It's uselessly tiny
-They can't make a video where someone manages to drink from it without spilling it all over the place.
-It's so fragile that it can't reasonably be used on its own.
-It costs 33% the cost of a gigantic bottle to produce, but contains far less than 33% of the volume of water. Cost per unit of water is way high before ignoring how a plastic bottle can be re-used.

Basically the only thing it has going for it is that it will break down nearly instantly in trash. The problem is we already have materials from which we *can* make a water bottle from that in fact would probably work better than this concept that already can be friendly enough to the environment. The problem is they still aren't practical and can't be used because they lack the durability.

This concept is a warm fuzzy with zero value over the current possibilities. It doesn't merely have 'kinks' to work out before it can be used, it's just fundamentally flawed as a concept.

Bottled drinks are a problem, but this is not going to provide a solution.

Though both are hedging as you say, I think both desperately want the other to overwhelmingly succeed. MS on ARM is not competitive due to a complete lack of support for legacy x86 applications and an otherwise uninspired design, so MS wants the world to run on x86 where they have home court advantage. Similarly, while Intel still has mostly better offerings, they cannot extract the desired margins out of such a highly competitive market like ARM where people will go without the very latest semiconductor process and gobs of performance. They want a software ecosystem that demands x86, which only Microsoft really has.

So yes, each has some 'worst case' contingency intended to keep them in the market. Those contingencies are both such long shots and will forever reduce margins even if they are 'successful'. That's why Intel has double downed on engineering with MS about platform sleep states and such without giving Android nearly as much attention (basically just token attention).

Microsoft and Intel should be best friends. They are each others main hope for relevance. Intel competing against the horde of ARM vendors on even ground is not going to end well for Intel's margins no matter how much share they hypothetically get. In much the same way that MS is nothing without the momentum of decades of x86-only applications, Intel isn't much without MS applications. Well, Intel's products are a bit respectable in their own right, but the primary driver of their large margin is the x86 ecosystem where MS is ubiquitous.

Intel may be hedging their bets to try to assure they aren't completely left behind in an Android-centric world, but I wager they are strongly hoping for MS to provide a software platform experience on x86 that is too compelling to overlook. I will say that even the 'best' Android apps I deal with are pretty crappy ( having to mysteriously be killed because it hangs, sometimes needing their persistent storage wiped because it has no idea how to work back to working state from whatever state it stored persistently). Even chrome randomly decides 'I'm just going to stop being able to render certain pages altogether'. It's bizarre, since on Windows and Linux desktops I don't see nearly as much wonkiness from many of the exact same application vendors doing about as equivalent a product as can be imagined. For a given price, I'd honestly prefer an x86 tablet so long as secureboot can be disabled to run platforms I have a great deal of familiarity with.

I had an RFC go through a few years ago. It was an utterly trivial little thing that would have been a couple of paragraphs and maybe a week or two to get consensus in a private company setting. The RFC was about 10 pages and took over a year to get out of draft. At no point was the fundamental proposal actually objected to in any way by anyone, but little tweaks to the wornding and making certain sections more verbose. There is a lot of nitpicking in the process and a lot of discussion around mostly unimportant stuff. I'd say I had it easy having such a non-objectionable proposal to just suffer the tedium of debates about phrasing and such. Proposals which suggest anything requiring technical consensus are far more tricky.

At the same time, it feels like as of the early 2000s, the private industry has largely given up on driving improved standards in general (not just IETF, but DMTF and several other standards organizations have been relatively stagnant compared to their activity in the 90s). They've figured out it's cheaper (consensus, quicker and more profitable (patents are better than standards) to go it alone without bothering to try for a standard. Of course this leads to the opposite problem, technologies are pushed faster than they are ready. Also, it naturally creates more walled garden style experiences and less robustly federated services. For example, the big things of the 90s were email and the web. Providers were utterly interchangeable. The big things of this decade have been facebook, twitter, youtube. In the 90s, apart from cisco, network management was focused on utterly standardized mibs. Today, switch vendors emphasize proprietary interfaces that are unique for management.

The problem is not that 'nobody can figure out how'. The problem is that '*everybody* can figure out how' in their own little proprietary way. The x86 ecosystem of incredibly interchangeable components is sadly the exception rather than the rule of how businesses choose to operate.

Might as well remove the radiator from your car, after all, it only gets cooled by the air, so you might as well just let air flow over the engine and it will be just as good.

Here, it looks like they are looking for additional heatsink and exhaust volume than they can fit in a dual-high form factor, meaning liquid transfer to the additional exhaust sink/fan. I personally think it a bit much in terms of GPU capabilities, but it doesn't mean it's totally silly.

There must already exist *some* scenarios in which two trades are practically 'simultaneous' and therefore the ordering within that quantum is ambiguous. Chaotic factors like network jitter already cause bids to jump in front of each other in a manner that does not necessarily reflect the precise order in which they were fired off. You already do not have a system where bids do not have sequence preserved. In fact, that's what the whole HFT business seems to take advantage of, that you can exert enough resources to jump in front of a offer you *know* is coming thanks to latencies, which clearly shows that ordering is not preserved.

So I guess my question is given that the current state of affairs where order is not preserved, but a door is open wide enough so that a big enough player can spend enough money to unfairly game the jitter, why would lifting the floor of that jitter to the level where all parties are equally impacted be a big game changer to the underlying mechanism (aside from the obvious of eliminating the ability for one party to jump in front of another reliably).

I'll confess to not being very well versed in this field and anything I say on the matter should be scrutinized.

That said, with a more coarse grained timeline, wouldn't the same processes hold, but just at a larger timescale? E.g. a 'bidding war' would span multiple trading quantums. If two bids go in within 250 ms of each other, then a randomization of the order shouldn't fundamentally change things. At an auction in person, for example, if two hands go up within 250 ms of each other, the auctioneer has no idea who went first. In effect, the auctioneer considers two such bidders in 'random' order, yet discovery in that case is not seen as unfairly random.

I guess I don't understand how the scheme would break things. I think I'm coming to understand now why a static delay can have an effect specifically against HFT, but was thinking that other algorithmic low-latency trading schemes are in play/likely for the future (i.e. I wasn't sure if non-HFT algorithmic trading also causes problems like flash crashes).

Perhaps then much of the problems the mass media tags with 'HFT' might hint at more general artifacts of low latency trading, or I could be full of it. A lot of the observed 'weirdness' would be mitigated through larger quantums of trading. The so-called 'flash crashes' where algorithmic trading of some sort goes nuts faster than people can correct for would be significantly slowed if trades could not react to each other as frequently.

Considering the volume of data inherent, the 'capacity' of a slot can be pretty damn high as to be inexhaustible from a practical perspective. Sure, the code should have a contingency for the condition and that should be tested, but it is unlikely to be a frequently hit contingency.

In this case, the question is 'what's the downside?' If HFT isn't really a problem, then what harm would it be to level the playing field to 250 ms or whatever quantums? If HFT is a big deal, then this would fix it. If it is not, then it wouldn't change things much.

Certainly some financial institutions are heavily investing in HFT relevant schemes, so they at least believe that HFT impact can be significant.

Again, you have an 'average' 3 second baseline to compete against. What you really want to do is accumulate trades into a queue, have said queue stop taking new trades for some period of time, then process that queue in random order. Then there truly is no difference whatsoever between trades getting in within a quantum of the trade processing slice.

Well my thought would be that multiple exchanges would implement the same scheme. In that case, someone coming in as late as 249 milliseconds after you has a 50/50 shot of being ahead of your trade anyway. Yes, one exchange wouldn't be enough, but the more exchanges that did the scheme, the less this would help.

If the whole point is to be x microseconds ahead of the other guys wouldn't a 500 ms delay simply mean the exact same game would become 'after 500 ms, still be a few microseconds ahead of the other guys'.

I would imagine a more effective approach would be to process trades 4 times per second. A request for a trade always gets processed in the slot after the next slot (meaning no less than a 250 ms delay, but no more than 500 ms delay). Within a given slot of trading activity, randomly shuffle the requests so that someone beating someone else by less than 250 ms doesn't actually affect things.