Additionally, they repeatedly deny that anyone should have a text log for any reason, dismissing criticisms as 'just hook in syslog *too* as an *optional* thing'. Basically systemd discards decades of sensibilities ecosystem to 'do it better', while throwing out the baby with the bathwater (ditching modularity and portable log data and such).
It's not just that 'if you don't like it, fix it'. People don't like the very fundamental aspects of the design that the systemd did *on purpose*.
I think those fall into a class where you need in-house expertise or you are simply screwed no matter what. When you have high quality in-house expertise anyway, the open source world empowers those experts to do things they could not pull off with a proprietary solution.
However, the general market is very large and there are also plenty of places where in-house expertise isn't so critical. A lot of those can get by with open source too 99.5% of the time, but when something goes really off the rails, those guys need help. The difference between RHEL and Windows isn't so big in up front costs. Ongoing costs mostly depend on the subjective preferences of the staff you can secure. RHEL and Windows appeal to very distinct sensibilities overall, so it should be no surprise that both viewpoints can be truthfully found in the world.
FOSS developers usually focus on usability for themselves and people with similar sensibilities. This is one reason why it is so polarizing from a user experience stance. If your sensibilities are aligned with a critical mass of FOSS developers, then you are grateful to finally find a group of people that think like you making applications. However if you are not in that boat, you find the sensibilities bizarre. The commercial players base their stuff on usability studies and explicitly make calls to favor majority over niche.
This is of course not universal and an oversimplification, but it is a pretty common distinction.
Why does Windows require rebooting almost every time it does an update?
Because their filehandle model is extremely stupid (cannot unlink an in-use file and replace with a new file and have the old filehandle available for old processes and new file content for new processes). However, in a way, it could be considered a blessing....
Why does linux only rarely need to reboot after an update?
On the one hand, this is a nice feature of the system, open filehandles are disassociated from the filenames they were opened as, allowing replacement of content without disrupting running processes. The downside is that you must track all the processes using a 'bad library' and restart them if you want to be assured that any security fix that might have been in there is applied. In practice, this is more and more becoming 'just reboot the system to be safe'. So Linux can scale up to multi-application environments with competent management better than Windows. However, if not carefully managed, then not rebooting after an update could just mean risk. Reboots have gotten cheaper and cheaper over time for most environments (reboots being faster and important services not being tied to just one OS instance), so this pride in uptime on a specific host is becoming more unreasonable.
Unfortunately I do not have a link. I do however know some system designers.
They designed a 4 socket Opteron system, and did not make a dual socket. It was peculiar to me so I asked why not a dual socket and they said there was no point in a dual socket because there was no performance advantage.
They also designed both a 4 socket EP system and a 2 socket EP system. I asked why and they said that they could gang up the two QPI links between two sockets for better performance.
I admittedly did not ask point blank if the two socket opteron couldn't do the same trick and they just didn't bother. It might have just been pushing the core-count marketing bullet as far as they could.
I think the Bulldozer scheme is actually pretty analagous to NetBurst. NetBurst happened t a time when a processor was almost exclusively measured by the clock frequency. It had theoretical benefits if workloads behaved a certain way. In practice, it pissed away energy and got terrible performance. Bulldozer happened when 'cores on a package' is a major factor in marketing a processor. It got to 'more cores' by replicating only certain facets with shared resources to get incredibly higher core count than Intel. It was similarly a risky move that *could* have panned out if workload acted as they guessed, but an intel core frequently keeps up with 2 amd 'cores' just like a 1 GHz athlon could outperform a 2 Ghz Intel P4.
. If you're still having to crank has truly serious issues if the car can't compensate by adjusting something to correct the AFR, timing, etc.
It's funny, because I've had the car do exactly the wrong thing. My car would start normally most every time, except maybe once every couple of months I could crank and crank and it wouldn't turn over until I stopped and tried again after a few seconds. Ultimately turned out to be a recall on the PCM where things were so bad that in fact it could stall the engine on the interstate in certain scenarios (never happened to me). Ever since recall, been no problems to crank.
Well, in the *desktops*, core marked an end to AMD dominance in most practical terms, but architecturally they still were not very good for scalability. Basically, they turned back the clock to pentium iii on modern processes and that was enough to recover the desktop space.
Nehalem is the point at which Intel basically overtook AMD again and AMD has not come back since that point. So Intel's had the ball for 3 of their 'tocks'. AMD prior to K7 was pretty weak for a lot longer than that and I don't think anyone familiar with AMD in K6 and older would guess they would be something more than a budget alternative. So AMD could conceivably come out of this with something awesome despite recent misfortune.
Well, something of an oversimplification/exaggeration.
64 'cores' is 32 piledriver modules. That was a gamble that by and large did not pan out as hoped. For a lot of applications, you must consider those 32 cores. Intel is currently at 12 cores per package versus AMD's 8 per package. Intel is less frequently found with their EP line in a 4 socket configuration because the performance of dual socket can be much higher with Intel's QPI than 4 socket. AMD can't do that topology, so you might as well do 4 socket. Additionally, the memory architecture of Intel tends to cause more dimm slots to be put on a board. AMD's thermals are actually a bit worse than Intel's, so it's not that AMD can be reasonably crammed in but Intel cannot. The pricing disparity is something that Intel chooses at their discretion (their margin is obscene), so if Intel ever gets pressure, they could halve their margin and still be healthy margin-wise.
I'm hoping this lives up to the legacy of the K7 architecture. K7 architecture left Intel horribly embarrassed and took years to finally catch up with when they launched Nehalem. Bulldozer was a decent experiment and software tooling has improved utilization, but it's still rough. With Intel ahead in both microarchitecture and manufacturing process, AMD is currently left with 'budget' pricing out of desperation as their strategy. This is by no means something to dismiss, but it's certainly less exciting and perhaps not sustainable since their costs are in fact higher than Intel's cost (though Intel's R&D budget is gigantic to fuel that low-cost per-unit advantage, so the difference between gross margin between Intel and AMD is huge, but net margin isn't as drastic). If the bulldozer scheme had worked out well, it could have meant another era of AMD dominance, but it sadly didn't work as well in practice.
Timing is pretty convenient. We have a tale of two exploits: -Heartbleed. Open source project. Huge catastrophic bug, existed as of beginning of 2012. Fix available pretty much immediately upon discovery. As a result, significant resources are pouring in to proactively examine OpenSSL, some fixing and some forking OpenSSL. One way or another, the fix was immediate and concerned parties are empowered to do what they think is needed and the open source world will have risks mitigated as well as closed source being able to make their own call since it is BSD licensed.
-MSIE vulnerability. Closed source. Analagously large bug (albeit client side instead of server side by sheer luck), has existed since at the very latest 2008, but probably as of 2001. Fix was over a week in coming after disclosure. If you are an organization standardized on IE, you were largely SOL with respect to a fix (though mitigation through tedious security settings was possible). Maybe MS ramps up an internal effort to root out more of these, maybe they don't. They seem to have been in a more vigilant stance as a matter of course and that wasn't enough to stop it.
So in other words, very important projects with huge responsibilities can cock up. They can be open source, they can be closed source. The practical lower bound of resources to address issues in both cases will be small when no one knows something is wrong, but the upper bound when concern happens is much higher in open source.
Some have argued that the 'any bug is shallow with enough eyes' was proven wrong with heratbleed. Discovering security bugs are always more tricky than the bug intended to be considered in that philosophy, but even then once discovered, the bug was very very shallow.
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).
Won't work. How do you suppose trades actually go through and prices get discovered? Trading and price discovery sort of works like an auction. An auction is not effective if you randomly scramble the order the bids come in.
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).
No, because HFT works by exploiting the tiniest of price differences and they are likely to vanish in those 500 ms.
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.
That would work as well, but is more complicated and you could run into trouble when your slots reach capacity.
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.
But the most interesting thing to me on *this* particular event is that Torvalds seems to agree in principle with Kay Sievers on the core quote:
Generic terms are generic, not the first user owns them.
Torvalds eventually says in the thread:
we very much expose/proc/cmdline for a reason. System services are *supposed* to parse it [...] that does include "quiet" and "debug". Parsing them and doing something sane with them is not a bug, it's a feature.
Of course, the issue here is that a complaint represents the straw that broke the camel's back. Here systemd was horribly abusing a kernel interface in their userspace code and I assume there have been a lot of other incidents that have piled up to have Torvalds make a strong statement.
I do agree that 'debug' in/proc/cmdline shouldn't be considered sovereign territory of the kernel alone. The average joe linux admin is aware he is trying to debug 'the boot process' but not know if it is kernel or init or what. The issue here was not that systemd got a bit debug happy when a kernel was being debugged, but that their debug output horribly abused/dev/kmsg and perhaps was a bit more verbose than would be reasonable.
It did make me feel somewhat pleased to see so many prominent kernel development people express dissatisfaction with systemd though.
Slashdot Mirror
There are significant numbers of people who understand it just perfectly and have valid criticisms that are not bugs.
http://ewontfix.com/14/
The systemd team has pissed of Torvalds:
https://lwn.net/Articles/59368...
Additionally, they repeatedly deny that anyone should have a text log for any reason, dismissing criticisms as 'just hook in syslog *too* as an *optional* thing'. Basically systemd discards decades of sensibilities ecosystem to 'do it better', while throwing out the baby with the bathwater (ditching modularity and portable log data and such).
It's not just that 'if you don't like it, fix it'. People don't like the very fundamental aspects of the design that the systemd did *on purpose*.
I think those fall into a class where you need in-house expertise or you are simply screwed no matter what. When you have high quality in-house expertise anyway, the open source world empowers those experts to do things they could not pull off with a proprietary solution.
However, the general market is very large and there are also plenty of places where in-house expertise isn't so critical. A lot of those can get by with open source too 99.5% of the time, but when something goes really off the rails, those guys need help. The difference between RHEL and Windows isn't so big in up front costs. Ongoing costs mostly depend on the subjective preferences of the staff you can secure. RHEL and Windows appeal to very distinct sensibilities overall, so it should be no surprise that both viewpoints can be truthfully found in the world.
FOSS developers usually focus on usability for themselves and people with similar sensibilities. This is one reason why it is so polarizing from a user experience stance. If your sensibilities are aligned with a critical mass of FOSS developers, then you are grateful to finally find a group of people that think like you making applications. However if you are not in that boat, you find the sensibilities bizarre. The commercial players base their stuff on usability studies and explicitly make calls to favor majority over niche.
This is of course not universal and an oversimplification, but it is a pretty common distinction.
Why does Windows require rebooting almost every time it does an update?
Because their filehandle model is extremely stupid (cannot unlink an in-use file and replace with a new file and have the old filehandle available for old processes and new file content for new processes). However, in a way, it could be considered a blessing....
Why does linux only rarely need to reboot after an update?
On the one hand, this is a nice feature of the system, open filehandles are disassociated from the filenames they were opened as, allowing replacement of content without disrupting running processes. The downside is that you must track all the processes using a 'bad library' and restart them if you want to be assured that any security fix that might have been in there is applied. In practice, this is more and more becoming 'just reboot the system to be safe'. So Linux can scale up to multi-application environments with competent management better than Windows. However, if not carefully managed, then not rebooting after an update could just mean risk. Reboots have gotten cheaper and cheaper over time for most environments (reboots being faster and important services not being tied to just one OS instance), so this pride in uptime on a specific host is becoming more unreasonable.
Unfortunately I do not have a link. I do however know some system designers.
They designed a 4 socket Opteron system, and did not make a dual socket. It was peculiar to me so I asked why not a dual socket and they said there was no point in a dual socket because there was no performance advantage.
They also designed both a 4 socket EP system and a 2 socket EP system. I asked why and they said that they could gang up the two QPI links between two sockets for better performance.
I admittedly did not ask point blank if the two socket opteron couldn't do the same trick and they just didn't bother. It might have just been pushing the core-count marketing bullet as far as they could.
I think the Bulldozer scheme is actually pretty analagous to NetBurst. NetBurst happened t a time when a processor was almost exclusively measured by the clock frequency. It had theoretical benefits if workloads behaved a certain way. In practice, it pissed away energy and got terrible performance. Bulldozer happened when 'cores on a package' is a major factor in marketing a processor. It got to 'more cores' by replicating only certain facets with shared resources to get incredibly higher core count than Intel. It was similarly a risky move that *could* have panned out if workload acted as they guessed, but an intel core frequently keeps up with 2 amd 'cores' just like a 1 GHz athlon could outperform a 2 Ghz Intel P4.
. If you're still having to crank has truly serious issues if the car can't compensate by adjusting something to correct the AFR, timing, etc.
It's funny, because I've had the car do exactly the wrong thing. My car would start normally most every time, except maybe once every couple of months I could crank and crank and it wouldn't turn over until I stopped and tried again after a few seconds. Ultimately turned out to be a recall on the PCM where things were so bad that in fact it could stall the engine on the interstate in certain scenarios (never happened to me). Ever since recall, been no problems to crank.
Well, in the *desktops*, core marked an end to AMD dominance in most practical terms, but architecturally they still were not very good for scalability. Basically, they turned back the clock to pentium iii on modern processes and that was enough to recover the desktop space.
Nehalem is the point at which Intel basically overtook AMD again and AMD has not come back since that point. So Intel's had the ball for 3 of their 'tocks'. AMD prior to K7 was pretty weak for a lot longer than that and I don't think anyone familiar with AMD in K6 and older would guess they would be something more than a budget alternative. So AMD could conceivably come out of this with something awesome despite recent misfortune.
Well, something of an oversimplification/exaggeration.
64 'cores' is 32 piledriver modules. That was a gamble that by and large did not pan out as hoped. For a lot of applications, you must consider those 32 cores. Intel is currently at 12 cores per package versus AMD's 8 per package. Intel is less frequently found with their EP line in a 4 socket configuration because the performance of dual socket can be much higher with Intel's QPI than 4 socket. AMD can't do that topology, so you might as well do 4 socket. Additionally, the memory architecture of Intel tends to cause more dimm slots to be put on a board. AMD's thermals are actually a bit worse than Intel's, so it's not that AMD can be reasonably crammed in but Intel cannot. The pricing disparity is something that Intel chooses at their discretion (their margin is obscene), so if Intel ever gets pressure, they could halve their margin and still be healthy margin-wise.
I'm hoping this lives up to the legacy of the K7 architecture. K7 architecture left Intel horribly embarrassed and took years to finally catch up with when they launched Nehalem. Bulldozer was a decent experiment and software tooling has improved utilization, but it's still rough. With Intel ahead in both microarchitecture and manufacturing process, AMD is currently left with 'budget' pricing out of desperation as their strategy. This is by no means something to dismiss, but it's certainly less exciting and perhaps not sustainable since their costs are in fact higher than Intel's cost (though Intel's R&D budget is gigantic to fuel that low-cost per-unit advantage, so the difference between gross margin between Intel and AMD is huge, but net margin isn't as drastic). If the bulldozer scheme had worked out well, it could have meant another era of AMD dominance, but it sadly didn't work as well in practice.
Timing is pretty convenient. We have a tale of two exploits:
-Heartbleed. Open source project. Huge catastrophic bug, existed as of beginning of 2012. Fix available pretty much immediately upon discovery. As a result, significant resources are pouring in to proactively examine OpenSSL, some fixing and some forking OpenSSL. One way or another, the fix was immediate and concerned parties are empowered to do what they think is needed and the open source world will have risks mitigated as well as closed source being able to make their own call since it is BSD licensed.
-MSIE vulnerability. Closed source. Analagously large bug (albeit client side instead of server side by sheer luck), has existed since at the very latest 2008, but probably as of 2001. Fix was over a week in coming after disclosure. If you are an organization standardized on IE, you were largely SOL with respect to a fix (though mitigation through tedious security settings was possible). Maybe MS ramps up an internal effort to root out more of these, maybe they don't. They seem to have been in a more vigilant stance as a matter of course and that wasn't enough to stop it.
So in other words, very important projects with huge responsibilities can cock up. They can be open source, they can be closed source. The practical lower bound of resources to address issues in both cases will be small when no one knows something is wrong, but the upper bound when concern happens is much higher in open source.
Some have argued that the 'any bug is shallow with enough eyes' was proven wrong with heratbleed. Discovering security bugs are always more tricky than the bug intended to be considered in that philosophy, but even then once discovered, the bug was very very shallow.
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).
Won't work. How do you suppose trades actually go through and prices get discovered? Trading and price discovery sort of works like an auction. An auction is not effective if you randomly scramble the order the bids come in.
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).
No, because HFT works by exploiting the tiniest of price differences and they are likely to vanish in those 500 ms.
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.
That would work as well, but is more complicated and you could run into trouble when your slots reach capacity.
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.
But the most interesting thing to me on *this* particular event is that Torvalds seems to agree in principle with Kay Sievers on the core quote:
Generic terms are generic, not the first user owns them.
Torvalds eventually says in the thread:
we very much expose /proc/cmdline for a reason. System services are *supposed* to parse it [...] that does include "quiet" and "debug". Parsing them and doing something sane with them is not a bug, it's a feature.
Of course, the issue here is that a complaint represents the straw that broke the camel's back. Here systemd was horribly abusing a kernel interface in their userspace code and I assume there have been a lot of other incidents that have piled up to have Torvalds make a strong statement.
I do agree that 'debug' in /proc/cmdline shouldn't be considered sovereign territory of the kernel alone. The average joe linux admin is aware he is trying to debug 'the boot process' but not know if it is kernel or init or what. The issue here was not that systemd got a bit debug happy when a kernel was being debugged, but that their debug output horribly abused /dev/kmsg and perhaps was a bit more verbose than would be reasonable.
It did make me feel somewhat pleased to see so many prominent kernel development people express dissatisfaction with systemd though.