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 think you may be saying that the capital-asset models people rely on in normal times are actually invalid... something which becomes evident at times of crisis. There's certainly a case to be made for that, but it's partially refuted by the existence of... normal times. Two crises that I lived and traded through (the 1998 LT crisis and the events of 2007-08) had a lot of structural similarities but radically different impacts on real economies. One practical problem I have with your point of view is the existence of those real economies. It's quite true that the world runs $30 trillion of annual GDP through capital markets that are based on not a whole lot of reality, but it has to go through something. I was hopeful after 2008 that the economics profession would atone for their sins and commit some new ones [sic], but none of the newer models has become an important policy or market driver.
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.)
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.
Practical questions: how many SCADA systems do you know that actually have data diodes? There's decent penetration of this technology in electric-power transmission/distribution and a certain amount in O/G upstream. Manufacturing/pharma/connected infrastructure/other sectors, not so much.
How much would you spend to secure a SCADA installation with data diodes? To a different poster, how about the spend (both capex and opex) for site-to-site VPN? This can make a lot of sense in enterprise networks where the ratio of connected devices to defensible network chokepoints is high. But with SCADA, what if your OT is highly distributed across physical space, and perhaps with sporadic networking and few IT-savvy personnel (oilfields, substations, smaller manufacturing facilities)? What if you're a company like a major automaker, for whom even $1000 is a lot to spend on a piece of technology that you'll have to replicate and manage across a huge global footprint?
How about the personnel problem? SCADA systems are generally managed by OT people. When they see IT people bearing gifts like data diodes, their first response in many places is to say "get your security stuff out of my production network before your latencies and your false positives disrupt my processes and violate my safety rules!" Then you say "but... security!" And they say "We're already airgapped here. We've been running SCADA since before you amateurs even had TCP/IP. We've never had a breach and never will." And then you say "but... what about that unsecured wireless access point right over there?" At this point, the OT guys will often start throwing things at you.
My point comes down to: doing this at scale is harder than it looks. The correct starting points are: first, get a C-level to knock heads together until the OT guys start listening to the IT-sec guys; and then do a standard risk/impact assessment to identify the systems at the top of the criticality list. Then you put the data diodes into those places, for a start. (In electric power companies subject to NERC compliance, you'll generally find that all of this has been done already for the CIP-high locations.)
To bring it back to what NSA are doing: it's valid to question their motives but keep in mind that a good chunk of their mission does involve network defense. (VADM Tighe, who used to be the deputy commander of US Cybercom, referred to this in her remarks last week about the McCain incident.)
It's also valid to question the ability of that other group of people, DHS, with a more explicit charter to keep the national infrastructure safe. For years, it's been hard to get these groups to talk effectively, but I would say this problem is really starting to get a little better these days. With that, I don't mean to suggest that the data sharing problem is close to resolution, because it's not. But as I say, I do believe some progress is now being made.
You'll find my code in the network drivers of various Unix flavors going back more years than some of the posters on this board have been alive. Maybe you're one of them?:-) Anyway, thanks for the chuckle.
Thanks, all good points. The specific efforts I'm connected to are contemplating something other than an overlay. There's talk about replacing the stack all the way down to level 1. (Remember the context: these networks are geographically dispersed but they're not large by node-count, and the key players actually do have access to super-constrained resources like right-of-way.)
I'm not convinced by that part of it. I still think this needs to be an overlay, but probably all the way down to level 2.
There are definitely smart people out there who are thinking about it. I know about some efforts to do it within some very limited but highly critical domains. (Think critical infrastructure, like electric power transmission and similar.)
Of course you'll never replace the incumbent commercial Internet. You won't boil the ocean either. But in the limited domains I'm talking about, the total number of really essential endpoints can be like 1e4 or even less. Compare to the Internet at whatever it is, probably nearly 1e10 by now. It's not crazy to think about replacing the networking.
Why do it? Simple: security. What aspect of security is most critical? Accountability. Until you can receive highly trustworthy remote control signals and telemetry data from, say, grid partners, you really can't say anything with high confidence about how the grid is being managed, or even about the integrity of your assets and processes.
So what's needed? Here's a few things: 1) A new networking stack. The IP suite, as astoundingly successful as it has been, is hopeless broken for industrial security. Too many holes, too much surface. 2) A new OS (!). The networking stack is too deeply interwoven with existing kernels. The new OS will be some flavor of Linux, but with the networking broken out somehow. 3) New protocols for establishing accountability. This one is pretty fuzzy at the moment, but a core requirement. 4) New apps, or at least rewritten ones. Remember, we're not talking about a billion endpoints. This will take years but it's at least conceivably possible. 5) Fighting the brutal, determined, and hyper-funded attacks of incumbent tech and automation vendors. This is the tough one, but remember the old saying: "First they laugh..."
Yes I know that critical infrastructure is shot through with automation systems built on way-back, unpatched Windows versions. That's not changing within the capital replacement cycle, which can be 40-60 years! But that doesn't mean that gateway networking devices can't be replaced in front of the automation networking.
I'm wearing my asbestos underwear, so flame away. All I can say is: keep an open mind and stay tuned.
I have. You face a 70% import duty on IT equipment, plus months-long waits to clear customs. We even once had a machine torn open and trashed and the packaging shredded by Indian customs, who then sent it back to us through an agent in Hong Kong after three months. The whole time, our customer was asking us daily, "where the hell is it?" We didn't know because no one would tell us. Our shipper (UPS) just said it was in Indian customs.
Something tells me we're going to have much luck selling stuff to those 300 million middle-class Indians. It reminds me of the "billion-consumer" Chinese market we were all excited about twenty years ago.
Coal is carbon, not a "toxic heavy metal." The half-life of U-235 is nearly a billion years, and it's less than 1% of the volume. Among the daughter species, if you're worred about the radium, don't. The volumes are still too low and the material too scattered. This is all theoretical because I still haven't granted your main point.
I'd like to see the proof that particulates, NOx, SO2, and global warming from coal emissions kill 50,000 Americans/year. I'm not granting you that either.
In sum, I'm not buying the public-health-based argument for nuclear power.
However I do agree with the positive formulation of your real point. Fission-based nuclear power is definitely part of the solution in our energy-policy mix. I do agree that better technology can be used to overcome the waste-disposal objections, although I don't know what those technologies are, yet.
Interesting fact (if true) that burning coal releases a lot of natural uranium into the atmosphere. It may be radioactive, but at such a low level (U-238 half-life is billions of years) that it poses no large-scale health risk. It's NOT high-level radiation, and it's not killing real people. You also refer to the fission-energy potential of the emitted uranium. You still have to capture it and separate the U-235, which is an energy-intensive process. In terms of real waste from real nuclear power, it's not the high-level radiation you worry about. The really intense stuff, like the I-131, is gone in six months. The bad stuff is the mildly radioactive isotopes like strontium-90 and cesium-137 that have strong physical chemical affinities to human tissue and stick around for hundreds of years.
As part of a panel discussion I moderated recently that included the participation of CIO representatives of about 30 major companies, we learned that larger businesses are: 1) VERY interested in F/OSS; 2) are NOT interested because of the potential cost savings, but rather because they believe that F/OSS can offer better technology with shorter delivery cycles; 3) are going slow because of the relative lack of enterprise-friendly support options.
If anyone is interested I can maybe write up a journal entry about this.
Anyone know for sure whether the SHA-1 attack also will compromise SHA-256? I've seen conflicting reports. How about RIPEMD? Anyone using it seriously?
As far as starting up your own telco, well that's pretty close to what I was hoping to hear! The RBOCs aren't here to help us or anyone but themselves. I want to see ingenious solutions from other entities. Show me your bizplan, I might invest in you.
You cite an interesting document and I will read it carefully (remember, I hate the telcos as much as anyone). But this document (on first reading) refers only to actions by the Pennsylvania PUC, not the federal FCC. Local utility commissions have a decades-long history of making fucked-up, idiotic, stupid deals that the telcos can easily take advantage of. I'd have to read the statute but I'll just bet that there are no specific remedies built into it which will require Verizon to give back something in return for not meeting some expectation about fiber-to-the-home which was written in 1994, when T3 lines cost $45,000/month. And even if there are, "conditions have changed" so Verizon goes to court and ties it all up for a few decades. This is not to defend Verizon but to rap the Pa PUC for not writing a stronger deal.
But fiber-to-the-home is not the only solution for broadband, and it's probably not the best, given the unfavorable economics and time-scales. Come up with something better!
The fiber rollout I mentioned in my original post was the long-haul fiber rollout which was a historic case of over-investment by stupid investors who threw away their own money to build an asset which to this day is no more than 5% utilized.
Slashdot Mirror
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 think you may be saying that the capital-asset models people rely on in normal times are actually invalid... something which becomes evident at times of crisis. There's certainly a case to be made for that, but it's partially refuted by the existence of... normal times. Two crises that I lived and traded through (the 1998 LT crisis and the events of 2007-08) had a lot of structural similarities but radically different impacts on real economies. One practical problem I have with your point of view is the existence of those real economies. It's quite true that the world runs $30 trillion of annual GDP through capital markets that are based on not a whole lot of reality, but it has to go through something. I was hopeful after 2008 that the economics profession would atone for their sins and commit some new ones [sic], but none of the newer models has become an important policy or market driver.
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.
All good thoughts and quite correct.
Practical questions: how many SCADA systems do you know that actually have data diodes? There's decent penetration of this technology in electric-power transmission/distribution and a certain amount in O/G upstream. Manufacturing/pharma/connected infrastructure/other sectors, not so much.
How much would you spend to secure a SCADA installation with data diodes? To a different poster, how about the spend (both capex and opex) for site-to-site VPN? This can make a lot of sense in enterprise networks where the ratio of connected devices to defensible network chokepoints is high. But with SCADA, what if your OT is highly distributed across physical space, and perhaps with sporadic networking and few IT-savvy personnel (oilfields, substations, smaller manufacturing facilities)? What if you're a company like a major automaker, for whom even $1000 is a lot to spend on a piece of technology that you'll have to replicate and manage across a huge global footprint?
How about the personnel problem? SCADA systems are generally managed by OT people. When they see IT people bearing gifts like data diodes, their first response in many places is to say "get your security stuff out of my production network before your latencies and your false positives disrupt my processes and violate my safety rules!" Then you say "but... security!" And they say "We're already airgapped here. We've been running SCADA since before you amateurs even had TCP/IP. We've never had a breach and never will." And then you say "but... what about that unsecured wireless access point right over there?" At this point, the OT guys will often start throwing things at you.
My point comes down to: doing this at scale is harder than it looks. The correct starting points are: first, get a C-level to knock heads together until the OT guys start listening to the IT-sec guys; and then do a standard risk/impact assessment to identify the systems at the top of the criticality list. Then you put the data diodes into those places, for a start. (In electric power companies subject to NERC compliance, you'll generally find that all of this has been done already for the CIP-high locations.)
To bring it back to what NSA are doing: it's valid to question their motives but keep in mind that a good chunk of their mission does involve network defense. (VADM Tighe, who used to be the deputy commander of US Cybercom, referred to this in her remarks last week about the McCain incident.)
It's also valid to question the ability of that other group of people, DHS, with a more explicit charter to keep the national infrastructure safe. For years, it's been hard to get these groups to talk effectively, but I would say this problem is really starting to get a little better these days. With that, I don't mean to suggest that the data sharing problem is close to resolution, because it's not. But as I say, I do believe some progress is now being made.
You'll find my code in the network drivers of various Unix flavors going back more years than some of the posters on this board have been alive. Maybe you're one of them? :-) Anyway, thanks for the chuckle.
Thanks, all good points. The specific efforts I'm connected to are contemplating something other than an overlay. There's talk about replacing the stack all the way down to level 1. (Remember the context: these networks are geographically dispersed but they're not large by node-count, and the key players actually do have access to super-constrained resources like right-of-way.)
I'm not convinced by that part of it. I still think this needs to be an overlay, but probably all the way down to level 2.
There are definitely smart people out there who are thinking about it. I know about some efforts to do it within some very limited but highly critical domains. (Think critical infrastructure, like electric power transmission and similar.)
Of course you'll never replace the incumbent commercial Internet. You won't boil the ocean either. But in the limited domains I'm talking about, the total number of really essential endpoints can be like 1e4 or even less. Compare to the Internet at whatever it is, probably nearly 1e10 by now. It's not crazy to think about replacing the networking.
Why do it? Simple: security. What aspect of security is most critical? Accountability. Until you can receive highly trustworthy remote control signals and telemetry data from, say, grid partners, you really can't say anything with high confidence about how the grid is being managed, or even about the integrity of your assets and processes.
So what's needed? Here's a few things: 1) A new networking stack. The IP suite, as astoundingly successful as it has been, is hopeless broken for industrial security. Too many holes, too much surface. 2) A new OS (!). The networking stack is too deeply interwoven with existing kernels. The new OS will be some flavor of Linux, but with the networking broken out somehow. 3) New protocols for establishing accountability. This one is pretty fuzzy at the moment, but a core requirement. 4) New apps, or at least rewritten ones. Remember, we're not talking about a billion endpoints. This will take years but it's at least conceivably possible. 5) Fighting the brutal, determined, and hyper-funded attacks of incumbent tech and automation vendors. This is the tough one, but remember the old saying: "First they laugh..."
Yes I know that critical infrastructure is shot through with automation systems built on way-back, unpatched Windows versions. That's not changing within the capital replacement cycle, which can be 40-60 years! But that doesn't mean that gateway networking devices can't be replaced in front of the automation networking.
I'm wearing my asbestos underwear, so flame away. All I can say is: keep an open mind and stay tuned.
I have. You face a 70% import duty on IT equipment, plus months-long waits to clear customs. We even once had a machine torn open and trashed and the packaging shredded by Indian customs, who then sent it back to us through an agent in Hong Kong after three months. The whole time, our customer was asking us daily, "where the hell is it?" We didn't know because no one would tell us. Our shipper (UPS) just said it was in Indian customs.
Something tells me we're going to have much luck selling stuff to those 300 million middle-class Indians. It reminds me of the "billion-consumer" Chinese market we were all excited about twenty years ago.
Coal is carbon, not a "toxic heavy metal." The half-life of U-235 is nearly a billion years, and it's less than 1% of the volume. Among the daughter species, if you're worred about the radium, don't. The volumes are still too low and the material too scattered. This is all theoretical because I still haven't granted your main point.
I'd like to see the proof that particulates, NOx, SO2, and global warming from coal emissions kill 50,000 Americans/year. I'm not granting you that either.
In sum, I'm not buying the public-health-based argument for nuclear power.
However I do agree with the positive formulation of your real point. Fission-based nuclear power is definitely part of the solution in our energy-policy mix. I do agree that better technology can be used to overcome the waste-disposal objections, although I don't know what those technologies are, yet.
Interesting fact (if true) that burning coal releases a lot of natural uranium into the atmosphere. It may be radioactive, but at such a low level (U-238 half-life is billions of years) that it poses no large-scale health risk. It's NOT high-level radiation, and it's not killing real people.
You also refer to the fission-energy potential of the emitted uranium. You still have to capture it and separate the U-235, which is an energy-intensive process.
In terms of real waste from real nuclear power, it's not the high-level radiation you worry about. The really intense stuff, like the I-131, is gone in six months. The bad stuff is the mildly radioactive isotopes like strontium-90 and cesium-137 that have strong physical chemical affinities to human tissue and stick around for hundreds of years.
As part of a panel discussion I moderated recently that included the participation of CIO representatives of about 30 major companies, we learned that larger businesses are:
1) VERY interested in F/OSS;
2) are NOT interested because of the potential cost savings, but rather because they believe that F/OSS can offer better technology with shorter delivery cycles;
3) are going slow because of the relative lack of enterprise-friendly support options.
If anyone is interested I can maybe write up a journal entry about this.
Anyone know for sure whether the SHA-1 attack also will compromise SHA-256? I've seen conflicting reports.
How about RIPEMD? Anyone using it seriously?
As far as starting up your own telco, well that's pretty close to what I was hoping to hear! The RBOCs aren't here to help us or anyone but themselves. I want to see ingenious solutions from other entities. Show me your bizplan, I might invest in you.
You cite an interesting document and I will read it carefully (remember, I hate the telcos as much as anyone). But this document (on first reading) refers only to actions by the Pennsylvania PUC, not the federal FCC. Local utility commissions have a decades-long history of making fucked-up, idiotic, stupid deals that the telcos can easily take advantage of. I'd have to read the statute but I'll just bet that there are no specific remedies built into it which will require Verizon to give back something in return for not meeting some expectation about fiber-to-the-home which was written in 1994, when T3 lines cost $45,000/month. And even if there are, "conditions have changed" so Verizon goes to court and ties it all up for a few decades. This is not to defend Verizon but to rap the Pa PUC for not writing a stronger deal.
But fiber-to-the-home is not the only solution for broadband, and it's probably not the best, given the unfavorable economics and time-scales. Come up with something better!
The fiber rollout I mentioned in my original post was the long-haul fiber rollout which was a historic case of over-investment by stupid investors who threw away their own money to build an asset which to this day is no more than 5% utilized.