Comment Glyphosate is an herbicide, not an insecticide (Score 1) 401
Just sayin'
Just sayin'
To read the original post carefully, he is saying that the progress of capitalism has left us slaves to a small number of corporate overlords. I have to say, that's true.
We let this happen because we enjoy having Amazon figure out what we want to buy, and make it easy for us to pull the trigger. Same with Uber. It's not really that bad, and also not that different from what is historically normal.
Now, enslaving overlords aren't what they used to be. They have learned a lot of lessons from historical episodes like the French Revolution, the mass unemployment in Britain of the 1920s, the early Great Depression in the US, and many others. The lesson is captured in what someone upthread referred to as "pitchforkiness," and others refer to as the frog-in-hot-water syndrome: Don't let the slaves get too uncomfortable.
It's incredibly good to be in the quiet ruling class of a prosperous, hopeful world. It really sucks to be the unquestioned despot of masses of people who feel that life is going the wrong way for them. Talk to billionaires and centi-millionaires (which I do), and you'll realize they totally get this.
What is happening now is that the lessons of noblesse oblige are steadily being unlearned by the newest class of oligarchs, who like most people 35 and younger, are astonishingly ignorant of history. I actually date this movement to the Enron blowup, and the less-celebrated concomitant event, the destruction of its auditor Arthur Andersen & Co. I remember boardroom conversations at that time about the significance of this episode: that the relatively few people with true power have lost any ethical sense, and we all had better start getting it back.
Guess what? We haven't, and it's gotten much worse since then.
In terms of basic economics, this is showing up as deflation. Not in the textbook monetary sense, but in the fact (mentioned by many posters here) that it's getting noticeably harder for ordinary middle-class people to afford many economic goods that were easily within reach in more prosperous times. This is a really big and separate topic (it intersects with the disastrous aftermath of the 2008 GFC). But for present purposes it represents the lever by which the truly powerful are exerting their control.
The extreme example of this is the situation in Silicon Valley. You'd think the C programmers making $240K/year and the data scientists literally making up to a million, have it made in the shade. So why are they constantly obsessing over real estate? They have plenty of money, but there's not enough for them to buy with it. That's a new kind of deflation (which many people mistake for inflation), and something like it is happening across all sectors of the economy, and in nearly every country. That's what we have to be worried about, because our economic overlords aren't doing anything about it.
Among many other more important things, this led to the rise of Donald Trump, who achieved nothing more (or less) than recognizing it and giving it a name. We're rather lucky that he's a feckless idiot. A more capable individual, more plugged into the true economic power structure of Apple, Facebook, Amazon, Google, Tencent, Alibaba, etc., could wreak tremendous harm.
One thing I've done a lot is to rewrite the assert macro so that it leaves a syslog trace. Another thing you can do (if you're lucky enough to get a coredump on failure) is to arrange for a distinctive signal (like SIGABRT) to hit your program. That stands out nicely in the coredump.
As with every tool and technique, there are right ways and wrong ways to use it.
To one of your points: sometimes it's not easy to figure out the best or most consistent way to handle a problem, when you expect it to happen never or almost never. A perfect example is when you can't create a realistic test case! In that case, I'd rather write an assert and get a deterministic and easily-fixable failure in the field, than write complicated error handling and recovery that I can't easily test.
One time I nearly fired a guy, is when I hit a NULL-pointer exception in some of his code that was part of an error handler. "Didn't you test this error handler??!!" "Of course not, there was no way to write a test case that triggers it."
Not the way I'd do it. An assert is always to be considered an orthogonal instrumentation of code, not code itself. The code must ALWAYS work according to intent, with or without the assert. The point of the assert is to detect when the intent isn't correct or has changed over time due to violated assumptions.
Write it this way:
auto ok = FunctionWhichShouldntEverFail (a,b,c);
assert (ok);
In short: always have the assert as its own statement (easily removed or commented out); and only assert values, not functions or expressions with side effects.
You got the right way to say it: "Assert all of your assumptions."
Code rots when it gets modified in ways that don't respect the implicit assumptions made in the past. Have you ever said to yourself, "this function is only called from two places and I know those two places validate the parameters"? When you then write the function without checking parameters, you've made an implicit assumption that makes all the sense in the world at that moment. But someone else (or you in three months) will forget or won't know the assumption, and call that function from somewhere else, with unchecked parameters.
Either document your implicit assumptions (making them explicit), or (better) assert them. The way to get good at asserting implicit assumptions is first to learn how to recognize when you're making an implicit assumption! That takes skill and practice, but if you don't do it, asserts don't help you.
And I leave the asserts in the final builds, too. In decades of professional C programming, I've never had a case where the asserts imposed a measurable performance penalty.
To the people who say "use NDEBUG to disable your asserts for production, because customers hate interruptions": no, don't do that. A violation of an implicit assumption is ALWAYS a bug, and it's always better for it to bite your behind sooner rather than later. The assert tells you exactly what you did wrong. I've had this conversation dozens of times:
[Angry customer]: Your software crashed!
[Me]: pop open the syslog and search for the word "assert."
[Angry customer]: It says "line XXX in file YYY"!
[Me]: you'll have the fix in two hours.
Interestingly, there is a handful of classes of bugs that are impervious to asserting your assumptions. The worst of these, in my experience, is the accidentally shadowed variable. But using assert in a disciplined way is incredibly useful.
As a cybersec professional of many years tenure (and now an exec at one of the major firms), I have to admit I've asked this same question many many times. If we didn't need to put so much effort into security, and instead put it into features with direct customer benefits, wouldn't we all be better off?
I think the OP approaches the answer to his question when he refers to preventing bad things from happening. A basic part of engineering is system robustness, resiliency and safety. We don't question the effort we put into assuring those things. We manage, in a variety of ways, the potential impacts arising from possible system failures.
With cybersecurity, we manage in a variety of ways the potential impacts arising from system vulnerabilities exploitable by bad actors. It's work we'd be doing anyway.
I worded my statement about covariance and crises very carefully so as not to imply any kind of causality
I'm not making any assumptions about whether BTC can correlate to currency markets. I'm hypothesizing (without any proof) that the more direct correlation is with gold. And gold is definitely one of the assets that are part of overall covariance, even though the part it plays on a daily basis is very small. In case you're thinking that trading in currencies and repo EVERY SINGLE DAY is on par with the total value of every ounce of gold in the world, my answer is: YUP!
What's more relevant to the discussion here is that trading in BTC by professionals, for the reasons that professionals trade, may result in stabilization of BTC values. IF it ever happens in size.
Let me connect one more dot: ARBITRAGE. If I'm right about all of this, then there is some kind of covariance between gold and BTC. Professional traders very much want to precisely quantify this relationship. I read BTC markets as highly illiquid and difficult to trade, whereas gold isn't super-liquid but not really hard to trade for the pros. That means there may be an arb here at low levels of overall value. If BTC futures turn out to be workable and liquid, then arb-trading against gold could become a thing.
Long-time Wall Streeter here. Actually, the trading dynamics of BTC are very much like any other speculative vehicle, although the short-term volatility is unusually high. (It is hard to get exercised over the nearly 50% retrace that occurred since the peak just under $20,000, especially since its extent was widely predicted by quants. The bounce came almost precisely off the Fibonacci support level around $11,600.)
Someone else mentioned Forex and many have mentioned equities. (Funny, no one is comparing BTC to government-issued fixed-income securities, which have been in a true and highly destructive bubble since late 2008.)
Relative currency values are driven by short-term interest rates, but BTC doesn't pay interest. More precisely, there's no government that issues risk-free bills denominated in BTC into a well-regulated and highly liquid market. There's no overnight repo or carry trade in BTC.
Similarly with stocks, the value of BTC isn't anything like them. People here have said "a company actually has a value." That may be true, but a publicly traded equity isn't directly representative of it. This is a complicated subject, but the value of a stock actually is a measure of its volatility (so-called "beta") relative to the market as a whole, which in turn is correlated with the overall level of risk-free interest rates and risk-bearing rates. If not for the highly distorting effects of tax policy in the US, equities and debt as corporate-finance vehicles are structurally equivalent. BTC has nothing to do with any of this.
Can you compare BTC to other things that are traded speculatively, like oil, grains, and other commodities? Not really, because those things have day-to-day economic value. The futures markets have natural sellers (think of farmers and oil producers) and natural buyers (think of food processors, oil refiners, and finished-goods consumers like yourself). These markets have endogenous and basically stable dynamics. Again, BTC doesn't.
The best analogy I've heard of relates BTC to so-called real (as opposed to financial) assets. Your house is one, but you can live in a house so it has a stable long-term value apart from its value as an asset.
Gold is perhaps the closest analogy. About half of global demand for gold is for use in jewelry; about 10% for electronics and other industrial uses. That leaves about 40% that is held speculatively. If you talk to gold owners, they'll tell you amorphous things like they're hedging against inflation in fiat currencies, or they want independence from governments. Now THAT sounds like how BTC holders talk! In short, the "natural" source of demand for this asset is not all that well-defined, and in particular there is no natural seller of BTC (as there is with every other major asset class). That means there's no inherent source of stability in BTC, although I expect the advent of futures trading in BTC to change this.
So what is speculative gold worth? The overall supply of gold in the world doesn't change too much, and actually hasn't changed much since antiquity. At current prices, 40% of it is worth about $3 trillion (very roughly). If you assume that BTC can take on some or all of the economic function of speculative gold, that means it can be worth anywhere from zero to about $45,000 a coin (again, VERY roughly). As a classic disruptive technology, whether BTC moves into this role and takes a valuation somewhere in that range, depends in part on whether BTC can displace gold for mechanical reasons (for example, is it easier and/or cheaper to hold?) The answer to that looks like yes.
How does futures trading (in theory) add stability to BTC? Basically by adding natural sellers to the market. Futures trading enables professionals to embed BTC into an overall covariance matrix that relates all asset classes to each other. (Breakdowns in the covariance are what you see at times that are otherwise known as financial crises.)
The railway business is called GE Transportation, and it is healthy. It's also stagnant, so watch for Flannery to look at selling it off.
I never talked to him about his plans to leave, but what you're saying is certainly possible. The "GE Digital" concept is actually very sound, and involved collecting all IT-related activities into a separate BU, headquarted in San Ramon in the East Bay. I would say that Bill Ruh, recruited in by Jeff, was a big driver here. I found it intriguing that of all the BUs at the time, only one was able to resist giving up its own IT resources, and that BU was healthcare.
Not sure if by "moving company headquarters" you're referring to the move from Fairfield to Boston. If so, that really happened as a result of a spat between Jeff and Dannel Molloy (governor of Connecticut), which was just badly handled by the latter. Embarrassingly bad, in fact. I really liked the Fairfield campus, too. Good for Boston, but it's still a shame.
The move to San Ramon corresponded with a push to digitize all of their businesses, and you know about the Predix platform, the Pivotal investment, and the acquisition of Wurldtech which were also parts of the strategy. It has to be said that the initiative as a whole hasn't met expectations. That said, GE is very far forward in so-called "advanced manufacturing," which basically means digitizing various processes, although there is still a very long way to go. They have really good people working on this, and they're business-smart about it too. They see digitization as a way of maintaining the top and bottom lines in their core businesses, not as the thoroughgoing "transformation" that less-savvy companies talk about.
I like GE long term. They're going through a rough patch, but they're good, smart people.
True but their existing power business was already quite large. GE has been a tech leader in turbines for many decades. This shows up not only in power gen, but also in aviation.
GE's core businesses going forward will be power (stagnant, but a global leader); healthcare (steady as long as people keep getting older); and aviation (continuous steady growth and the jewel in the crown).
In re the Alstom deal, remember all the hoops Jeff had to go through to get that deal done? Flying to Paris to stroke Macron's crank, fighting Siemens, and all that stuff? He just really wanted it bad. This was right after some key expansions he made in the O/G BU, now being spun out after the Baker Hughes deal. As much as I like Jeff, he started mis-timing his moves toward the end of his tenure, and a lot of what is going on now is unwinding those errors.
Both GE and GM have been partners with Fanuc at different times. The GE relationship indeed was a JV, and there are still some products from GE Intelligent Platforms (the controls BU) that carry the "Fanuc" brand name. However, GM was the original relationship, and GM maintains a strong strategic partnership with Fanuc to this day. Fanuc America's HQ is in Rochester Hills, Michigan, a short drive from Warren, Dearborn, and Auburn Hills.
I've never seen a robot in a GM plant that was any color other than Fanuc yellow, whereas with the other automakers, you'll also see ABB red, Motoman white, etc.
Lots of control systems incorporate HMIs and other software that not only requires Windows; they often require very specific back-versions of Windows supplied by the systems vendors themselves. It's easy to say "don't run Windows" or "if you must run Windows, keep it updated and patched," but that's not realistic. And that's for some very good reasons: software that controls machines simply must be tested to a far higher standard than software that humans will use, because machines aren't as adaptable as humans. A bug or regression caused by an OS patch might be annoying to a human user, but in a control system it could bring down a process or even create safety problems. Patching Windows in shop-floor applications can amount to running a huge beta-test with your most critical business assets, and even with people's lives.
The vendors of control systems have long recognized this, which gives rise to another reason you often can't patch or update Windows: they'll stop supporting your controls if you do. And that's something no production manager can allow.
Behind every great computer sits a skinny little geek.