The ratio of compute to memory says otherwise. Note that when it comes to talking up the systems in the press, *every* one will overstate the practicality of their system, and generally speaking there's no real way to call people on what they claim. Generally speaking, the top several contenders in a top500 are made in some way to have it be fairly challenging to put it to *practical* use, because they spent a disproportionate amount of resource for the sake of making the Top500 (to have a *practical* system that hits that high a score would be even more astronomical cost). This is not a specific indictment of the current Chinese config, but a fact of life for top of this list which is driven by a very specific benchmark. It's kind of looking at dragsters, which are useless on anything but a straight short course of pavement, but they accelerate very very hard.
Depending on the list, sometimes you might as well skip over the top 10 or 20 before you get to systems that are actually designed in a practical way for solving real problems.
In general, at a low level Intel and MS have worked a bit more so that power management features still usually land in Microsoft first still. Even when they land in Linux, the functionality is frequently not correctly used for a long time.
On the flipside, MS tends to do more uncontrolled behind the scenes crap. In a stock Windows install, there will be antivirus examining most disk I/O, update checking spawning at annoyingly arbitrary times, etc. If a linux were up to the same degree of BS background activity that MS does, then it would do worse, but in practice it tends to do better (in my experience) thanks to doing no more than what the user asks.
I'm not crazy about it, but in my web development where I constantly hit things IE won't do, I haven't had to make many concessions to target Edge when I get to ignore IE.
Well 240 hp on a 21 foot boat makes for pretty fun sport boating already...
In general, engines on boats short of yacht class are relatively ancient by automotive standards (e.g. carburetor was the norm until very recently, and engine diagnostics are much less sophisticated for boats)
Analyst prediction of the future in the market is always just wild ass guessing. They can provide some data to help people compare companies in terms of historic and current data, but their projections into the future are like horoscopes.
I'll say that the price deltas make a lot of sense, actually. The perception of GM market value is based mostly on their concrete standing in the market.
For Tesla, the market value of the company is far more speculative about the future. So credible stories about another historically disruptive player coming in taking off 10% is not as surprising. Note that right now, Tesla is perceived as 70% the value of GM, which is actually a hell of a lot given their revenue and market share today. So Tesla's value is built on much fuzzier sentiment.
I would anticipate it's even worse. Though it's not about programmability, the amount of memory relative to the compute shows that this system is pretty much designed to do one thing and one thing well: xhpl. Everything else is questionable.
It's entirely possible this is an extravagant expense to hit #1 in Top500, but not able to do anything else. Looking at the architecture, about all that system can do is run xhpl really good. They talk about practical applications, but it seems the described system skimps on all sorts of things that would be important for real work, but not needed as much for xhpl benchmark runs.
Agreed. Agile is the victim of it's own popularity. It sounds good to say 'Agile' so *everyone* will call their crap Agile. When there came into being 'Agile' seminars, certifications and specific tools, the whole point was lost as it transitioned to mainstream usage.
Experience can vary greatly, and overwhelmingly whatever the 'trendy' words used in conjunction with an alleged process approach will be overwhelmingly found in crappy projects, because the majority of projects are crappy, and the majority of project management likes to follow trends.
At the end of the day, any group will distort whatever stated 'brand name' methodology for project management to describe the way they were going to do things anyway. Over my career I've learned that it's about futile to gauge how a process is going to work based on what branding they use to describe it. I have learned that eagerness to use a popular set of terminology *frequently* indicates project management that doesn't really understand what they are doing (not always). As such, my first reaction to someone saying 'Agile' (big A) is skepticism. Not because of the qualities of it in theory, but because of human behavior in practice.
So just because someone clearly rolls their eyes at media mention of Agile or project management mention of Agile, do not presume they are some backwards person avoiding SCM (who the hell avoids SCM anyway?) who doesn't document code, who wants to hide behind another process (Waterfall) because they are not doing work. It's far more likely they are a bit jaded from years of real-world experience. Note that the same criticisms of how Waterfall worked in practice, I see happening in nominally 'Agile' projects, slipping dates, misunderstanding the requirements, losing perspective, generally failing to deliver usable projects. Some folks think some magical way of describing a process will fix people, the problem is that the people will on average do things poorly and interpret guidance on process as they see it fitting their personal ideas of how things should get done.
True, but I hate voicemail, *particularly* when they leave a novel worth of stuff. A lot of people I know will hang up rather than leave a voicemail, and instead send a text (even if they dictate it).
There's a reason why voicemail transcription is such a popular feature. Our ability to read text is much faster than our ability to process voice. Also, books on tape are much less popular than just reading, only tolerated in scenarios like driving or other situation where actually reading is just infeasible.
Now video/pictures do frequently add something, but generally for personal communication it's more trouble than it is worth and really most data is conveyed through voice in such a scenario. There are specific exceptions to this of course...
They were pretty much that way back in the day, but around the time of Netburst they came into their own. Intel course corrected to a good architecture as of Nehalem and AMD went down a very wrong path in Bulldozer, relegating them to the current state of affairs.
Ok, well, guess I should specifically say that the part of the toolchain is glibc. I couldn't remember the details so I did digging. The NSS functionality requires dynamic linking. If you request '-static' the result is... still dynamic linked.. So you cannot have a wholly static linked application (unless you build a special glibc yourself, that won't work quite right...) From a licensing perspective, LGPL makes static linking impractical. Nowadays you don't see the '.a' libraries generally built and distributed by defaults, *only* so. I generally recall 10-15 years ago this being a big general discussion point and folks being told 'just stop trying to make static binaries". The ecosystem has clearly in many concrete ways stood in the way of static binaries for over a decade.
Not I didn't say there is a *problem*, but a contradiction in the trends. There was a trend toward dynamic libraries more and more, and now there's a trend to squash all those benefits by auto-bundling libraries and/or finding ways to static link for the ability to ignore dependencies once again.
Furthermore, phone calls are closer to video than text. We had audio phone conversations before we had instant text communication in everyone's hands, and text communication caught on like wildfire as an easier, less intrusive thing to do.
Also, no matter how 'hot shot' you think you are, generally HR and legal trump *everyone* when it comes to dismissing a person. If they want someone gone, they are *gone*, end of discussion.
So yes, they are paying a lot more attention than you realize (generally) and they can kick your ass out if you do not go along.
If you don't like the agreement, however, you can generally negotiate the terms directly and get an amended agreement. If you play by the rules above board, they generally are willing to play ball. However being passive-aggressive by trying to sneak a bad signature in is a dicier situation.
A lot of companies severance pay is issued directly in response to review/signing of paperwork at time of termination, not based on your stuff up front.
Of course, non compete is generally the up-front paperwork for companies that do such a thing (since they are mostly worried about people *quitting*, where severance isn't a factor). Extended non disclosure, *specifically* around the nature of the layoff is generally the topic of the paperwork that severance depends upon.
Well my point was that the gcc toolchain started pushing hard *against* static linking, and nowadays there's a hard push *for* static linking (not from gcc mind you). Things keep swinging back and forth, seemingly each iteration having people totally forget why it went the way it is last time.
I think it's a lot of paranoia related to the systemd controversy. Before that, things that people might have bitched about could be used or ignored at will. systemd, being a pretty core init system is something people couldn't easily step away from as an individual choice (unlike, say, desktop environments). Now *every* thing that could *conceivably* be construed as 'core' is going to be regarded with more worry than before.
Particularly since the whole advertised benefit is you don't have to keep up with the distro, mr. app developer. Which means you are explicitly trying to attract folks who are almost certainly *also* too lazy to keep up with CVEs and such. At least with dynamic linking, you have some *hope* of fixing lots of app problems externally without the app maintainers specific attention... here....
Snaps are really better for things like Chrome, third party applications that don't want to screw with actually following the distribution roadmaps. They are specifically architected to provide for mobile 'apps' to attract developers that are too lazy to keep up with distributions (btw, that would also mean too lazy to keep up with security vulnerabilities, by and large). On the server side, if you are still worried about 'downtime' in a way that any single system can impact, you are almost certainly doing it wrong. The downtime you save even in theory is negligible (only when you update the kernel does a full-stop must reboot occur, and no app packaging is going to change that).
It is hilarious, once upon a time it was commonplace for *every* library to be available static linkable and dynamic linkable, and the toolchain would have a simple flag to let the build decide if it should produce a static or dynamic binary.
They decidid this was a 'harmful' approach and by and large the toolchains removed the easy way to statically link things to force dynamic as it was seen as better.
Now you have snappy and singularity and go... all saying 'screw dynamic linking, static link or fake static link!'
I think the issue is that there is a lot of welcome new work, and a lot of unwelcome new work. This is of course nothing new and has been the case from the beggining of time.
However, this time, systemd is not something that can be opted out of so simply. You could for the most part pick and choose which things you thought were good and gleefully ignore what you don't like. systemd is not something that can be ignored in the event you disagree with it as a distro embraces it.
Thus far, Devuan has come the furthest in terms of 'a fully modern distro, but without systemd', but basically it has taken over the practical distros.
Having some familiarity with a similarly stupid naming scheme at another company, marketing very likely *loves* it, but tech support certainly is pissed.
Clippy is a joke in part because it was annoying, but moreso in how it was actually pretty condescending in many ways toward the user.
The described use case can strike people in the same way. Auto-suggesting guys on linked in who claim to have experience with what you are trying to do? It seems a bit silly in the same way that clippy's 'suggestions' were silly at the time, all while being condescending (unintentionally). You seem to be trying to project manage this... poorly, here's a guy who would be better than you...
Hell, even if we figure out some magic physics, we could be *surrounded* by Star Trek level civilization and still not be able to perceive it easily unless they come directly knocking on our door, even if they aren't trying to hide or anything.
Slashdot Mirror
The ratio of compute to memory says otherwise. Note that when it comes to talking up the systems in the press, *every* one will overstate the practicality of their system, and generally speaking there's no real way to call people on what they claim. Generally speaking, the top several contenders in a top500 are made in some way to have it be fairly challenging to put it to *practical* use, because they spent a disproportionate amount of resource for the sake of making the Top500 (to have a *practical* system that hits that high a score would be even more astronomical cost). This is not a specific indictment of the current Chinese config, but a fact of life for top of this list which is driven by a very specific benchmark. It's kind of looking at dragsters, which are useless on anything but a straight short course of pavement, but they accelerate very very hard.
Depending on the list, sometimes you might as well skip over the top 10 or 20 before you get to systems that are actually designed in a practical way for solving real problems.
In general, at a low level Intel and MS have worked a bit more so that power management features still usually land in Microsoft first still. Even when they land in Linux, the functionality is frequently not correctly used for a long time.
On the flipside, MS tends to do more uncontrolled behind the scenes crap. In a stock Windows install, there will be antivirus examining most disk I/O, update checking spawning at annoyingly arbitrary times, etc. If a linux were up to the same degree of BS background activity that MS does, then it would do worse, but in practice it tends to do better (in my experience) thanks to doing no more than what the user asks.
I'm not crazy about it, but in my web development where I constantly hit things IE won't do, I haven't had to make many concessions to target Edge when I get to ignore IE.
Well 240 hp on a 21 foot boat makes for pretty fun sport boating already...
In general, engines on boats short of yacht class are relatively ancient by automotive standards (e.g. carburetor was the norm until very recently, and engine diagnostics are much less sophisticated for boats)
Analyst prediction of the future in the market is always just wild ass guessing. They can provide some data to help people compare companies in terms of historic and current data, but their projections into the future are like horoscopes.
I'll say that the price deltas make a lot of sense, actually. The perception of GM market value is based mostly on their concrete standing in the market.
For Tesla, the market value of the company is far more speculative about the future. So credible stories about another historically disruptive player coming in taking off 10% is not as surprising. Note that right now, Tesla is perceived as 70% the value of GM, which is actually a hell of a lot given their revenue and market share today. So Tesla's value is built on much fuzzier sentiment.
I would anticipate it's even worse. Though it's not about programmability, the amount of memory relative to the compute shows that this system is pretty much designed to do one thing and one thing well: xhpl. Everything else is questionable.
It's entirely possible this is an extravagant expense to hit #1 in Top500, but not able to do anything else. Looking at the architecture, about all that system can do is run xhpl really good. They talk about practical applications, but it seems the described system skimps on all sorts of things that would be important for real work, but not needed as much for xhpl benchmark runs.
Agreed. Agile is the victim of it's own popularity. It sounds good to say 'Agile' so *everyone* will call their crap Agile. When there came into being 'Agile' seminars, certifications and specific tools, the whole point was lost as it transitioned to mainstream usage.
Experience can vary greatly, and overwhelmingly whatever the 'trendy' words used in conjunction with an alleged process approach will be overwhelmingly found in crappy projects, because the majority of projects are crappy, and the majority of project management likes to follow trends.
At the end of the day, any group will distort whatever stated 'brand name' methodology for project management to describe the way they were going to do things anyway. Over my career I've learned that it's about futile to gauge how a process is going to work based on what branding they use to describe it. I have learned that eagerness to use a popular set of terminology *frequently* indicates project management that doesn't really understand what they are doing (not always). As such, my first reaction to someone saying 'Agile' (big A) is skepticism. Not because of the qualities of it in theory, but because of human behavior in practice.
So just because someone clearly rolls their eyes at media mention of Agile or project management mention of Agile, do not presume they are some backwards person avoiding SCM (who the hell avoids SCM anyway?) who doesn't document code, who wants to hide behind another process (Waterfall) because they are not doing work. It's far more likely they are a bit jaded from years of real-world experience. Note that the same criticisms of how Waterfall worked in practice, I see happening in nominally 'Agile' projects, slipping dates, misunderstanding the requirements, losing perspective, generally failing to deliver usable projects. Some folks think some magical way of describing a process will fix people, the problem is that the people will on average do things poorly and interpret guidance on process as they see it fitting their personal ideas of how things should get done.
Well as long as the emoji's ammo capacity is limited, it should be safe enough....
True, but I hate voicemail, *particularly* when they leave a novel worth of stuff. A lot of people I know will hang up rather than leave a voicemail, and instead send a text (even if they dictate it).
There's a reason why voicemail transcription is such a popular feature. Our ability to read text is much faster than our ability to process voice. Also, books on tape are much less popular than just reading, only tolerated in scenarios like driving or other situation where actually reading is just infeasible.
Now video/pictures do frequently add something, but generally for personal communication it's more trouble than it is worth and really most data is conveyed through voice in such a scenario. There are specific exceptions to this of course...
They were pretty much that way back in the day, but around the time of Netburst they came into their own. Intel course corrected to a good architecture as of Nehalem and AMD went down a very wrong path in Bulldozer, relegating them to the current state of affairs.
Ok, well, guess I should specifically say that the part of the toolchain is glibc. I couldn't remember the details so I did digging. The NSS functionality requires dynamic linking. If you request '-static' the result is... still dynamic linked.. So you cannot have a wholly static linked application (unless you build a special glibc yourself, that won't work quite right...) From a licensing perspective, LGPL makes static linking impractical. Nowadays you don't see the '.a' libraries generally built and distributed by defaults, *only* so. I generally recall 10-15 years ago this being a big general discussion point and folks being told 'just stop trying to make static binaries". The ecosystem has clearly in many concrete ways stood in the way of static binaries for over a decade.
Not I didn't say there is a *problem*, but a contradiction in the trends. There was a trend toward dynamic libraries more and more, and now there's a trend to squash all those benefits by auto-bundling libraries and/or finding ways to static link for the ability to ignore dependencies once again.
Furthermore, phone calls are closer to video than text. We had audio phone conversations before we had instant text communication in everyone's hands, and text communication caught on like wildfire as an easier, less intrusive thing to do.
Also, no matter how 'hot shot' you think you are, generally HR and legal trump *everyone* when it comes to dismissing a person. If they want someone gone, they are *gone*, end of discussion.
So yes, they are paying a lot more attention than you realize (generally) and they can kick your ass out if you do not go along.
If you don't like the agreement, however, you can generally negotiate the terms directly and get an amended agreement. If you play by the rules above board, they generally are willing to play ball. However being passive-aggressive by trying to sneak a bad signature in is a dicier situation.
So that was your experience....
A lot of companies severance pay is issued directly in response to review/signing of paperwork at time of termination, not based on your stuff up front.
Of course, non compete is generally the up-front paperwork for companies that do such a thing (since they are mostly worried about people *quitting*, where severance isn't a factor). Extended non disclosure, *specifically* around the nature of the layoff is generally the topic of the paperwork that severance depends upon.
Well my point was that the gcc toolchain started pushing hard *against* static linking, and nowadays there's a hard push *for* static linking (not from gcc mind you). Things keep swinging back and forth, seemingly each iteration having people totally forget why it went the way it is last time.
I think it's a lot of paranoia related to the systemd controversy. Before that, things that people might have bitched about could be used or ignored at will. systemd, being a pretty core init system is something people couldn't easily step away from as an individual choice (unlike, say, desktop environments). Now *every* thing that could *conceivably* be construed as 'core' is going to be regarded with more worry than before.
Particularly since the whole advertised benefit is you don't have to keep up with the distro, mr. app developer. Which means you are explicitly trying to attract folks who are almost certainly *also* too lazy to keep up with CVEs and such. At least with dynamic linking, you have some *hope* of fixing lots of app problems externally without the app maintainers specific attention... here....
Snaps are really better for things like Chrome, third party applications that don't want to screw with actually following the distribution roadmaps. They are specifically architected to provide for mobile 'apps' to attract developers that are too lazy to keep up with distributions (btw, that would also mean too lazy to keep up with security vulnerabilities, by and large). On the server side, if you are still worried about 'downtime' in a way that any single system can impact, you are almost certainly doing it wrong. The downtime you save even in theory is negligible (only when you update the kernel does a full-stop must reboot occur, and no app packaging is going to change that).
Dynamic linking is for the weak!
It is hilarious, once upon a time it was commonplace for *every* library to be available static linkable and dynamic linkable, and the toolchain would have a simple flag to let the build decide if it should produce a static or dynamic binary.
They decidid this was a 'harmful' approach and by and large the toolchains removed the easy way to statically link things to force dynamic as it was seen as better.
Now you have snappy and singularity and go... all saying 'screw dynamic linking, static link or fake static link!'
I think the issue is that there is a lot of welcome new work, and a lot of unwelcome new work. This is of course nothing new and has been the case from the beggining of time.
However, this time, systemd is not something that can be opted out of so simply. You could for the most part pick and choose which things you thought were good and gleefully ignore what you don't like. systemd is not something that can be ignored in the event you disagree with it as a distro embraces it.
Thus far, Devuan has come the furthest in terms of 'a fully modern distro, but without systemd', but basically it has taken over the practical distros.
Having some familiarity with a similarly stupid naming scheme at another company, marketing very likely *loves* it, but tech support certainly is pissed.
Clippy is a joke in part because it was annoying, but moreso in how it was actually pretty condescending in many ways toward the user.
The described use case can strike people in the same way. Auto-suggesting guys on linked in who claim to have experience with what you are trying to do? It seems a bit silly in the same way that clippy's 'suggestions' were silly at the time, all while being condescending (unintentionally). You seem to be trying to project manage this... poorly, here's a guy who would be better than you...
Hell, even if we figure out some magic physics, we could be *surrounded* by Star Trek level civilization and still not be able to perceive it easily unless they come directly knocking on our door, even if they aren't trying to hide or anything.