So they provide a lot of value, then it is bad for them to be down, and it is ok to whine about them being down a lot. I don't understand standing up for github being down..
That's the rub, you can't say both 'don't knock on github, it's fine' and then 'git is decentralized anyway'. The latter implies that github is superfluous, not that it's ok for it to be down a lot and still used.
While git is designed to do that, that's no particular help to those using github for their workflow. The argument is basically 'it's ok if github screws you, just don't use github'.
Either github is important, and it's bad for it to be down. Or it isn't important and shouldn't be defended.
Yes, but that was the whole point in the thread was that Verizon *could* play ball, and the response was 'no, because AWS'. Which is inaccurate because netflix *has* hardware to locate at the edge for willing ISPs, and also inaccurate because even ignoring that, their video comes over non-AWS CDNs (cheaper bandwidth, AWS is not as cheap as traditional CDNs for high bandwidth tasks).
I applaud them finally embracing a sensible remote shell strategy. I recall many heated debates where MS would say all sorts of nasty things about ssh.
However, I can't say that implementing decades old terminal function and ssh is 'forward looking'.
They have a control plane in AWS, but the bulk of the bandwidth comes from distinct CDN strategy. Notably they have appliances for ISPs to incorporate, precisely to enable ISPs to deliver better netflix performance.
The novelty comes from having a lot of tools to quickly maintain images and such. As you say, there's also 'dockerhub' to let you download canned application complete with OS libraries. The former I find to be handy, the latter I find problematic.
On the one hand, it can be a handy resource to dive into something to have a hands on example as you learn to deal with it yourself.
However, a few big downsides: -Some projects have gotten very lazy about packaging. They make a half hearted or no effort to offer up distro packages, because 'hey, docker!'. I suppose this wouldn't be so bad, except for... -As you say, these are various images with varying degrees of discipline in applying updates.
Complicating matters that even if you 'trust' a particular publisher, docker's infrastructure isn't exactly thorough about things like signing images and such. Updates become gigantic, because you are updating the entire OS even if one library needs a hand.
I'd be more frustrated with Intel holding back ECC, whereas AMD desktop memory controllers will happily do ECC.
QPI/UPI to the PCH isn't so interesting. The most performance relevant part in the scheme of things is the GPU. Sure, NVMe drives make IO a whole lot faster, but in practice on the desktop the difference is actually hard to see between a 6 Gb/s SATA attached SSD and a PCIe attached SSD. GPU has PCIe direct (though HTX/[UQ]PI/NVlink can be much better, but not even AMD has enabled HTX-connected discrete GPUs).
At this point I think they are looking for business models that are more annuity-like, with recurring revenue. A transactional purchase of an OS is becoming increasingly less interesting because fewer upgrade cycles. So for them, the strategy was 'app store or bust!'.
I don't see how in the world *Windows* is going to break into the mobile market. They have been trying for over a decade, repeatedly without success. Particularly now it seems a pretty cemented Android/iOS landscape. The only hope I could see is Intel getting some hardware makers onboard and that being a platform for MS to push their continuum concept (yes it can work with ARM, but back to square one, a bunch of my enterprise applications are not about to spend money to dust off the build trees and build ARM for the fun of it)
MS mobile strategy is going to have to settle for trying to make money off of iOS and/or Android users/developers. They can (and do) provide hosting, applications, and services. They miss the revenue opportunity of a curated application distribution platform, but I think this is the best they can hope for.
The issue is that a lot of applications people need won't bother to update, and many current applications will forgo the managed runtime upon which MS cross-architecture strategy is based.
Sure, the ecosystem could move, but there's now adequate x86_64 implementations in the space at fairly low cost.
MS' safer bet is to encourage an x86-centric market. Sure, keep ARM port viable and encourage cross-architecture as a matter of course for as many of the developers as they can to hedge their bets, but backwards compatibility is a big selling point for MS platform.
Yeah, I know a lot of people who would gloss over profiling/optimization, with the mindset that is a waste of their time because CPU would cover up for their laziness.
Except they have, in terms of work done per clock (even ignoring multicore). A Haswell 1.2 ghz can achieve the same sort of results as a 3.0 ghz AMD core from 5 years ago in a balanced set of CPU constrained work. It actually comes out ahead in a number of specific workloads. Note I'm comparing to a core significantly older, with less cache for the sake of demonstrating only the senselessness of being fixated on clock, not saying this is a fair Intel v. AMD comparison.
On the other hand, a 1.2 GHz AMD K7 back in the day could beat a 3.0 GHz Pentium 4 of the same time. There's a lot more to processor performance than clockspeed.
Especially if Microsoft ports full Windows 10 to the ARM
They've been there, done that. MS ecosystem is particularly built upon x86 compiled applications. Sure, they may have ways to have portable stuff, but the stranglehold of Windows is built around legacy applications.
'more precise' would have been better, but 'precise' by itself is a very relative term. There's no set number of significant figures that can be considered 'precise' versus 'not precise' in absolute terms. Having 3 significant figures may be precise in some context, even though in another you could have 6.
In this case, the starting point is no significant figures, increasing to 1 significant figure is precise (by comparison).
Both values may be considered 'accurate'. Hot and 80 million degrees are both accurate, but 80 million is more precise than hot. 70 million versus 80 million would be a matter of accuracy, number of significant figures a matter of precision.
I really must not want to be doing my job if I'm sitting talking about precision and accuracy in an internet thread.
It is a funny sequence of words, but in context it doesn't seem wrong. It says at first 'heating up', then '80 million degrees' which is more precise than 'hot'. It sounds a tad cheesy to me doing the rather uninspired play of words, but not incorrect usage.
That seems to miss a large part of the point of these containers. Of course to support this sort of strategy, Windows would have to do a whole lot of kernel work, and they probably don't have the stomach to muck with their kernel that much.
At least parts of it have been woefully embarrassingly bad at security. Note also that a great deal of presumed secure infrastructure/enterprise stuff has some of the most laughable actual security practices. This is not just Cisco mind you.
Actually, that's an interesting thing too. I am interested in my next system having a detachable keyboard that still works when pulled (e.g. the x1 tablet claims it will do this). For one, I want to be able to tote just the screen around if I feel like it, but also so I can position the keyboard independently of the screen to use. I hate how on a laptop that my screen is so low even if I have room to put the monitor higher. I could use an external keyboard but the screen still has this area in front of it (unless like a yoga and can fold back) and then it's also two things to carry instead of 'one'.
Slashdot Mirror
So they provide a lot of value, then it is bad for them to be down, and it is ok to whine about them being down a lot. I don't understand standing up for github being down..
If you think it has the same value up or down, then you basically say it has no value in the first place.
I was shocked to see a rather major component from one of our partners, a very well regarded partner, using RCS for their version control..
Yes, then why github?
That's the rub, you can't say both 'don't knock on github, it's fine' and then 'git is decentralized anyway'. The latter implies that github is superfluous, not that it's ok for it to be down a lot and still used.
Also, as a matter of accounting, sometimes one type of spending is viewed more favorably than another.
While git is designed to do that, that's no particular help to those using github for their workflow. The argument is basically 'it's ok if github screws you, just don't use github'.
Either github is important, and it's bad for it to be down. Or it isn't important and shouldn't be defended.
Yes, but that was the whole point in the thread was that Verizon *could* play ball, and the response was 'no, because AWS'. Which is inaccurate because netflix *has* hardware to locate at the edge for willing ISPs, and also inaccurate because even ignoring that, their video comes over non-AWS CDNs (cheaper bandwidth, AWS is not as cheap as traditional CDNs for high bandwidth tasks).
I applaud them finally embracing a sensible remote shell strategy. I recall many heated debates where MS would say all sorts of nasty things about ssh.
However, I can't say that implementing decades old terminal function and ssh is 'forward looking'.
They have a control plane in AWS, but the bulk of the bandwidth comes from distinct CDN strategy. Notably they have appliances for ISPs to incorporate, precisely to enable ISPs to deliver better netflix performance.
The novelty comes from having a lot of tools to quickly maintain images and such. As you say, there's also 'dockerhub' to let you download canned application complete with OS libraries. The former I find to be handy, the latter I find problematic.
On the one hand, it can be a handy resource to dive into something to have a hands on example as you learn to deal with it yourself.
However, a few big downsides:
-Some projects have gotten very lazy about packaging. They make a half hearted or no effort to offer up distro packages, because 'hey, docker!'. I suppose this wouldn't be so bad, except for...
-As you say, these are various images with varying degrees of discipline in applying updates.
Complicating matters that even if you 'trust' a particular publisher, docker's infrastructure isn't exactly thorough about things like signing images and such. Updates become gigantic, because you are updating the entire OS even if one library needs a hand.
I'd be more frustrated with Intel holding back ECC, whereas AMD desktop memory controllers will happily do ECC.
QPI/UPI to the PCH isn't so interesting. The most performance relevant part in the scheme of things is the GPU. Sure, NVMe drives make IO a whole lot faster, but in practice on the desktop the difference is actually hard to see between a 6 Gb/s SATA attached SSD and a PCIe attached SSD. GPU has PCIe direct (though HTX/[UQ]PI/NVlink can be much better, but not even AMD has enabled HTX-connected discrete GPUs).
At this point I think they are looking for business models that are more annuity-like, with recurring revenue. A transactional purchase of an OS is becoming increasingly less interesting because fewer upgrade cycles. So for them, the strategy was 'app store or bust!'.
Yeah, but they're no Acura....
I don't see how in the world *Windows* is going to break into the mobile market. They have been trying for over a decade, repeatedly without success. Particularly now it seems a pretty cemented Android/iOS landscape. The only hope I could see is Intel getting some hardware makers onboard and that being a platform for MS to push their continuum concept (yes it can work with ARM, but back to square one, a bunch of my enterprise applications are not about to spend money to dust off the build trees and build ARM for the fun of it)
MS mobile strategy is going to have to settle for trying to make money off of iOS and/or Android users/developers. They can (and do) provide hosting, applications, and services. They miss the revenue opportunity of a curated application distribution platform, but I think this is the best they can hope for.
The issue is that a lot of applications people need won't bother to update, and many current applications will forgo the managed runtime upon which MS cross-architecture strategy is based.
Sure, the ecosystem could move, but there's now adequate x86_64 implementations in the space at fairly low cost.
MS' safer bet is to encourage an x86-centric market. Sure, keep ARM port viable and encourage cross-architecture as a matter of course for as many of the developers as they can to hedge their bets, but backwards compatibility is a big selling point for MS platform.
Yeah, I know a lot of people who would gloss over profiling/optimization, with the mindset that is a waste of their time because CPU would cover up for their laziness.
Except they have, in terms of work done per clock (even ignoring multicore). A Haswell 1.2 ghz can achieve the same sort of results as a 3.0 ghz AMD core from 5 years ago in a balanced set of CPU constrained work. It actually comes out ahead in a number of specific workloads. Note I'm comparing to a core significantly older, with less cache for the sake of demonstrating only the senselessness of being fixated on clock, not saying this is a fair Intel v. AMD comparison.
On the other hand, a 1.2 GHz AMD K7 back in the day could beat a 3.0 GHz Pentium 4 of the same time. There's a lot more to processor performance than clockspeed.
Especially if Microsoft ports full Windows 10 to the ARM
They've been there, done that. MS ecosystem is particularly built upon x86 compiled applications. Sure, they may have ways to have portable stuff, but the stranglehold of Windows is built around legacy applications.
'more precise' would have been better, but 'precise' by itself is a very relative term. There's no set number of significant figures that can be considered 'precise' versus 'not precise' in absolute terms. Having 3 significant figures may be precise in some context, even though in another you could have 6.
In this case, the starting point is no significant figures, increasing to 1 significant figure is precise (by comparison).
Both values may be considered 'accurate'. Hot and 80 million degrees are both accurate, but 80 million is more precise than hot. 70 million versus 80 million would be a matter of accuracy, number of significant figures a matter of precision.
I really must not want to be doing my job if I'm sitting talking about precision and accuracy in an internet thread.
It is a funny sequence of words, but in context it doesn't seem wrong. It says at first 'heating up', then '80 million degrees' which is more precise than 'hot'. It sounds a tad cheesy to me doing the rather uninspired play of words, but not incorrect usage.
that can run in hyper-V too
That seems to miss a large part of the point of these containers. Of course to support this sort of strategy, Windows would have to do a whole lot of kernel work, and they probably don't have the stomach to muck with their kernel that much.
At least parts of it have been woefully embarrassingly bad at security. Note also that a great deal of presumed secure infrastructure/enterprise stuff has some of the most laughable actual security practices. This is not just Cisco mind you.
Actually, that's an interesting thing too. I am interested in my next system having a detachable keyboard that still works when pulled (e.g. the x1 tablet claims it will do this). For one, I want to be able to tote just the screen around if I feel like it, but also so I can position the keyboard independently of the screen to use. I hate how on a laptop that my screen is so low even if I have room to put the monitor higher. I could use an external keyboard but the screen still has this area in front of it (unless like a yoga and can fold back) and then it's also two things to carry instead of 'one'.
There's a crapton of stuff that works only well under Linux out of the box now.
In our lab, there are like a bucket of USB serial adapters. All of them work with every linux device. But almost none of them work well with windows.
Yes, but refusing to have a a customer in a high profile venue also has negative PR cost.