Cisco have always had a slightly odd business model when it comes to R&D. How often has some mysterious stealth startup been formed to investigate a new idea, with a remarkable number of ex-Cisco people as its initial staff, and subsequently bought by Cisco to bring the technology back in-house if it was promising?
I don't know what you mean by the high-end switch market being a mess. It's still dominated by a few big names, Cisco among them.
For all the promise of SDN, so far it's much more talk than action. The brave few who have tried it at large scales so far have rarely spoken positively about the results. At this level, getting your gear from one supplier who also has you on a lucrative support contract still seems to work out much better in the real world than buying white box gear from that guy, buying another type of white box gear from the other guy over there, installing some Linux-plus-drivers "network OS" from his mate on each of those boxes, and then trying to get 80% complete and 60% working SDN infrastructure running on top. SDN is eating traditional networking alive in the same way that Linux is eating Windows alive on the desktop: only in the dreams of its most loyal fans.
I'm not sure what Docker has to do with switching at any serious level. All the networking other than connectivity between containers/VMs running on the same big box is still hardware based.
And as a final comment, don't be fooled by arguments about big price savings compared to established brands like Cisco. No-one pays anything close to list price at high volume.
Better in what sense? TMP lets you do a few useful or at least interesting things, but I've always found it bizarre how much attention it gets for something that is basically an accident of C++ language semantics.
It is certainly true that being on the ISO committee for a programming language standard doesn't necessarily make you an expert in all the ways that language is used. I once had a very frustrating discussion with a prominent member of one such committee, who stubbornly insisted that discussions about organising deeply nested loops were moot because no-one should ever need more than a level or two of nesting in good code anyway.
I asked how familiar he was with the subgraph isomorphism problem (finding subgraphs of a certain shape within a larger graph) and he didn't seem to have come across it. The thing is, that problem is provably NP-complete (that is, computationally extremely expensive to solve in the general case) and so in practice you might well approach it heuristically, building a deep set of nested loops and guard conditions.
I think a lot of programmers and a lot of people working on programming languages think of something like, say, quicksort as being a relatively complicated algorithm. By introductory textbook standards, maybe it is. However, when you're talking about programming languages used by millions of developers for numerous different applications, there are plenty of people trying to implement much more complicated algorithms. Different aspects of language design can become relevant at that scale even if they don't make much difference when you're implementing basic data structures and algorithms, but if no-one on the committee has any relevant experience, they don't even know what they don't know.
I take your point, but I don't entirely agree with it. I think whether performance or maintainability matters more depends a lot on context. Both are valuable attributes, but both can reach a level that is good enough to get the job done, and improving them beyond that point offers a much lower return. Where that point is depends a great deal on both what you're doing now and what you might want to do later.
In any case, the days when writing in C or C++ was an effective guarantee of very good performance are behind us. With modern hardware designs, the only way to guarantee making the most of available CPU and other hardware resources is to drop to assembly level or the equivalent. Otherwise it's still a question of how good your compiler or VM is, and while C or C++ being "closer to the hardware" can offer some advantages there, their programming models also prevent some optimisations that might be valid because, for example they aren't safe due to aliasing possibilities.
Anyone can play a scale on a piano. Anyone can figure out what the notes on the music mean. That does not mean that anyone can play Frédéric Chopin's Minute Waltz. More to the point, a "better" piano won't fix this.
Perhaps not, but I'd rather listen to a professional concert pianist play the Minute Waltz on a Steinway grand than a 1980s synthesizer.
Yes, they have. A lot of the changes in the more recent standards have been aimed at cleaning up warts in the language or nasty edge cases. More generally, compilers have improved, particularly in how they handle templates.
Unfortunately, a lot of the developments in C++ within the past decade have been more about fixing what was already there but somewhat broken than breaking new ground. In the overall programming language space, C++ looks dated today, with many of the changes that did break new ground still looking like poor imitations of things that are done much better in other languages. Of course, part of the reason for that is that many of those other languages have been designed with the experience we had already gained by using C++ over many years and for many different applications.
I have seen monsters made in pretty much every language at this point. None of them are 'good' at stopping you from making crap code.
Perhaps, but some of them are still better than others.
For example, there is no reason a language designed today would want nullable-by-default indirection, or a weird inside-to-out convention for writing types. C++ has these things due to a combination of historical accidents and such a strong need for backward compatibility that mistakes on that level are almost impossible to fix later.
There are plenty of other aspects of C++ that are at least debatable as well, including things as fundamental as its model of OOP, its limited type system, and the repeated attempts over the years to bolt on support for functional programming idioms that never quite hit the mark.
This is true if you allow insertion of arbitrary CSS (or running of arbitrary code that can trigger requests via JS etc.) and then process it with no questions asked. However, browsers already deal with related concerns in areas like the same-origin policy and CORS. They could apply similar safeguards to locally generated requests.
I saw that as well; that was what prompted my question. Any sanely implemented site isn't going to be sending things like plain text IDs and passwords as part of a query string, only one-time tokens and the like. It was whether Stylish was intercepting things like form submissions over HTTPS, or somehow scanning saved login credentials stored in the browser, that I was concerned about when I read the title. That would have suggested that users should be advised to change all of those passwords.
Yes, you can do all kinds of things if the browser lets you. But there is no reason a browser couldn't simply impose a 100% firewall by default and let any extensions that genuinely do have a need to do something like your example ask for explicit permission. I would argue that the sort of behaviour you illustrated is relatively unusual for browser extensions, while sadly trying to exfiltrate data no longer is.
That's essentially what happened with alternatives like Stylus that are now being recommended instead. What we can't figure out so easily is the past behaviour of all relevant versions of the Stylish extension itself.
There is a plague in the modern tech industry, where everything from browser extensions to microlibraries for your favourite programming language is written by someone you've never met, supplied via some sort of centralised repository or distribution channel that you trust instead, and then winds up on your machine doing who-knows-what because that trusted distribution mechanism missed something, or even because the trusted developer of some code you're running, which you downloaded via a trusted source, itself trusted someone else unwisely.
The solution to this isn't just proper validation of where the code you're downloading actually came from, it's also to have security models more sophisticated than the 1980s in the Internet age. For example, why the hell could a browser extension that was there to modify the appearance of pages you were visiting suddenly choose to upload anything to the mothership without requiring additional permissions?
The title suggests that not just browsing history but credentials are uploaded. The latter is potentially much worse than the former. Does anyone have verifiable data on exactly what was uploaded? Does everyone who got caught out by this need to reset their IDs/passwords/whatever on every site they visited while using the extension? Or every site they've ever visited and allowed their browser to store login credentials?
The new owners could be in pretty deep brown stuff anyway given that this sort of behaviour without explicit consent is now very illegal throughout Europe, but if they were stealing credentials then it would be prudent to reset everything, which of course could mean dozens or hundreds of different sites for some people.
e.g., if the company claims the candidates code during the interview wasn't good enough, how could you prove that they actually thought it was good enough
The concern isn't that they'll prove you thought otherwise, it's that they'll take you to some form of court or tribunal alleging that you thought otherwise but then didn't hire because they were female/black/Muslim/whatever -- and now the best case may be that you waste time and money, win, and still get a reputation for being a sexist/racist/whatever employer if the local news picks up the story.
I don't expect every employer to spend hours coaching rejected applicants, but a simple statement of why would go a long way.
I've heard that a lot of lawyers advise against this, because in some jurisdictions it opens up a risk of a candidate then claiming some form of illegal discrimination has taken place if they don't like the official version. It's a bit like insurers saying you must not say "sorry" if you've been involved in a collision on the road, because it can be taken as an admission of responsibility in subsequent legal matters, even if you were just being polite/friendly and knew very well that the other person caused the crash. In some places, I think there are now laws that explicitly prevent the latter problem; maybe some sort of "protection of honest recruiting feedback" law would help with the former?
Reinstall from original installation media and pray to god that your system's onboard firmware is not compromised.
Sadly today that last part is also very significant. Thanks to the mess of modern infrastructure like UEFI, everybody's device having embedded functionality that can be updated, and processors-within-processors, it's basically impossible to ever fully trust a system that has been compromised now, no matter how drastic your recovery procedures might be. Of course, for similar reasons it's also basically impossible to trust a system that you don't know has been compromised either. Security in modern tech is broken, and the tech industry and security services broke it.
Exactly. Firefox fans might like to think that "it's a major platform that web developers have to consider." Sadly, my analytics disagree. For example, I just checked a leisure-related B2C site I run. Mobile is dominant in this market, so the main Android and iOS browsers rank highest as you'd expect. Of the desktop browsers, Chrome is biggest with nearly half the market share, and most of the rest is split between Safari and IE+Edge between them. Firefox comes just above the 1% mark looking at all traffic.
I'm sorry to see things going this way, because Safari is like the new IE and I don't think it's healthy for the future of the Web for Google to have so much influence. But the reality is that for sites like this, Firefox is not even close to being a major platform, and since we have bills to pay, our development effort has to follow the user base.
Well, HMRC is in an impossible position. The tax rules it is required to use are so complicated that I doubt anyone understands them completely, and it it has far too few resources to do its job properly, and the people it does have are often not well trained. (These three factors may be related...)
Given those constraints, I think a lot of the automated systems for filing the main types of return electronically are fairly usable these days. If you do get to speak to a real person from HMRC, in my experience they are usually reasonable and try to do the right thing as well.
However, even if everyone has the best of intentions, the problems lead to HMRC's people making mistakes and giving bad advice and sometimes focussing on the easy things instead of the right things. When you're in a position to seriously affect other people's lives, even if those other people have done nothing wrong or have made an honest mistake while trying to deal with a system too complicated to understand, obviously that's still not good enough.
It's often said that biometrics are user IDs, not passwords. Perhaps that's a little simplistic, but for practical purposes it's probably a better analogy.
The problem is that with the increasing emphasis in technology industries on pushing updates and retiring old software rather than supporting it in the long term, there are fewer and fewer software products available that really are made to last and supported accordingly.
As we were reminded by WannaCry last year, even major organisations in important fields like healthcare were still running significant numbers of Windows XP machines because that was what important diagnostic software was built/certified for, and while not necessarily intended for general use or external connectivity, they may still be attached to internal networks in order to be used for their intended purpose.
Evidently you were right in your reply to my earlier comment that expecting an OS to be properly supported until the declared EOL date may be ill-advised, but unfortunately that doesn't solve the underlying problem that we are increasingly building our tech on foundations that have questionable longevity.
I'm still waiting to see what radical improvements have been made in the last 15 years, and why Office 2003 era applications with a handful of modest updates couldn't still do much the same job for most people...
Slashdot Mirror
Cisco have always had a slightly odd business model when it comes to R&D. How often has some mysterious stealth startup been formed to investigate a new idea, with a remarkable number of ex-Cisco people as its initial staff, and subsequently bought by Cisco to bring the technology back in-house if it was promising?
I don't know what you mean by the high-end switch market being a mess. It's still dominated by a few big names, Cisco among them.
For all the promise of SDN, so far it's much more talk than action. The brave few who have tried it at large scales so far have rarely spoken positively about the results. At this level, getting your gear from one supplier who also has you on a lucrative support contract still seems to work out much better in the real world than buying white box gear from that guy, buying another type of white box gear from the other guy over there, installing some Linux-plus-drivers "network OS" from his mate on each of those boxes, and then trying to get 80% complete and 60% working SDN infrastructure running on top. SDN is eating traditional networking alive in the same way that Linux is eating Windows alive on the desktop: only in the dreams of its most loyal fans.
I'm not sure what Docker has to do with switching at any serious level. All the networking other than connectivity between containers/VMs running on the same big box is still hardware based.
And as a final comment, don't be fooled by arguments about big price savings compared to established brands like Cisco. No-one pays anything close to list price at high volume.
Better in what sense? TMP lets you do a few useful or at least interesting things, but I've always found it bizarre how much attention it gets for something that is basically an accident of C++ language semantics.
Which returns a pointer that is only useful when interpreted as pointing to an array...
It is certainly true that being on the ISO committee for a programming language standard doesn't necessarily make you an expert in all the ways that language is used. I once had a very frustrating discussion with a prominent member of one such committee, who stubbornly insisted that discussions about organising deeply nested loops were moot because no-one should ever need more than a level or two of nesting in good code anyway.
I asked how familiar he was with the subgraph isomorphism problem (finding subgraphs of a certain shape within a larger graph) and he didn't seem to have come across it. The thing is, that problem is provably NP-complete (that is, computationally extremely expensive to solve in the general case) and so in practice you might well approach it heuristically, building a deep set of nested loops and guard conditions.
I think a lot of programmers and a lot of people working on programming languages think of something like, say, quicksort as being a relatively complicated algorithm. By introductory textbook standards, maybe it is. However, when you're talking about programming languages used by millions of developers for numerous different applications, there are plenty of people trying to implement much more complicated algorithms. Different aspects of language design can become relevant at that scale even if they don't make much difference when you're implementing basic data structures and algorithms, but if no-one on the committee has any relevant experience, they don't even know what they don't know.
I take your point, but I don't entirely agree with it. I think whether performance or maintainability matters more depends a lot on context. Both are valuable attributes, but both can reach a level that is good enough to get the job done, and improving them beyond that point offers a much lower return. Where that point is depends a great deal on both what you're doing now and what you might want to do later.
In any case, the days when writing in C or C++ was an effective guarantee of very good performance are behind us. With modern hardware designs, the only way to guarantee making the most of available CPU and other hardware resources is to drop to assembly level or the equivalent. Otherwise it's still a question of how good your compiler or VM is, and while C or C++ being "closer to the hardware" can offer some advantages there, their programming models also prevent some optimisations that might be valid because, for example they aren't safe due to aliasing possibilities.
Anyone can play a scale on a piano. Anyone can figure out what the notes on the music mean. That does not mean that anyone can play Frédéric Chopin's Minute Waltz. More to the point, a "better" piano won't fix this.
Perhaps not, but I'd rather listen to a professional concert pianist play the Minute Waltz on a Steinway grand than a 1980s synthesizer.
Have templates ever improved?
Yes, they have. A lot of the changes in the more recent standards have been aimed at cleaning up warts in the language or nasty edge cases. More generally, compilers have improved, particularly in how they handle templates.
Unfortunately, a lot of the developments in C++ within the past decade have been more about fixing what was already there but somewhat broken than breaking new ground. In the overall programming language space, C++ looks dated today, with many of the changes that did break new ground still looking like poor imitations of things that are done much better in other languages. Of course, part of the reason for that is that many of those other languages have been designed with the experience we had already gained by using C++ over many years and for many different applications.
I have seen monsters made in pretty much every language at this point. None of them are 'good' at stopping you from making crap code.
Perhaps, but some of them are still better than others.
For example, there is no reason a language designed today would want nullable-by-default indirection, or a weird inside-to-out convention for writing types. C++ has these things due to a combination of historical accidents and such a strong need for backward compatibility that mistakes on that level are almost impossible to fix later.
There are plenty of other aspects of C++ that are at least debatable as well, including things as fundamental as its model of OOP, its limited type system, and the repeated attempts over the years to bolt on support for functional programming idioms that never quite hit the mark.
new[] and delete[] don't do anything that can't be done much better with std::vector.
Well, they can be used to implement std::vector.
This is true if you allow insertion of arbitrary CSS (or running of arbitrary code that can trigger requests via JS etc.) and then process it with no questions asked. However, browsers already deal with related concerns in areas like the same-origin policy and CORS. They could apply similar safeguards to locally generated requests.
I saw that as well; that was what prompted my question. Any sanely implemented site isn't going to be sending things like plain text IDs and passwords as part of a query string, only one-time tokens and the like. It was whether Stylish was intercepting things like form submissions over HTTPS, or somehow scanning saved login credentials stored in the browser, that I was concerned about when I read the title. That would have suggested that users should be advised to change all of those passwords.
Yes, you can do all kinds of things if the browser lets you. But there is no reason a browser couldn't simply impose a 100% firewall by default and let any extensions that genuinely do have a need to do something like your example ask for explicit permission. I would argue that the sort of behaviour you illustrated is relatively unusual for browser extensions, while sadly trying to exfiltrate data no longer is.
That's essentially what happened with alternatives like Stylus that are now being recommended instead. What we can't figure out so easily is the past behaviour of all relevant versions of the Stylish extension itself.
There is a plague in the modern tech industry, where everything from browser extensions to microlibraries for your favourite programming language is written by someone you've never met, supplied via some sort of centralised repository or distribution channel that you trust instead, and then winds up on your machine doing who-knows-what because that trusted distribution mechanism missed something, or even because the trusted developer of some code you're running, which you downloaded via a trusted source, itself trusted someone else unwisely.
The solution to this isn't just proper validation of where the code you're downloading actually came from, it's also to have security models more sophisticated than the 1980s in the Internet age. For example, why the hell could a browser extension that was there to modify the appearance of pages you were visiting suddenly choose to upload anything to the mothership without requiring additional permissions?
The title suggests that not just browsing history but credentials are uploaded. The latter is potentially much worse than the former. Does anyone have verifiable data on exactly what was uploaded? Does everyone who got caught out by this need to reset their IDs/passwords/whatever on every site they visited while using the extension? Or every site they've ever visited and allowed their browser to store login credentials?
The new owners could be in pretty deep brown stuff anyway given that this sort of behaviour without explicit consent is now very illegal throughout Europe, but if they were stealing credentials then it would be prudent to reset everything, which of course could mean dozens or hundreds of different sites for some people.
e.g., if the company claims the candidates code during the interview wasn't good enough, how could you prove that they actually thought it was good enough
The concern isn't that they'll prove you thought otherwise, it's that they'll take you to some form of court or tribunal alleging that you thought otherwise but then didn't hire because they were female/black/Muslim/whatever -- and now the best case may be that you waste time and money, win, and still get a reputation for being a sexist/racist/whatever employer if the local news picks up the story.
I don't expect every employer to spend hours coaching rejected applicants, but a simple statement of why would go a long way.
I've heard that a lot of lawyers advise against this, because in some jurisdictions it opens up a risk of a candidate then claiming some form of illegal discrimination has taken place if they don't like the official version. It's a bit like insurers saying you must not say "sorry" if you've been involved in a collision on the road, because it can be taken as an admission of responsibility in subsequent legal matters, even if you were just being polite/friendly and knew very well that the other person caused the crash. In some places, I think there are now laws that explicitly prevent the latter problem; maybe some sort of "protection of honest recruiting feedback" law would help with the former?
Reinstall from original installation media and pray to god that your system's onboard firmware is not compromised.
Sadly today that last part is also very significant. Thanks to the mess of modern infrastructure like UEFI, everybody's device having embedded functionality that can be updated, and processors-within-processors, it's basically impossible to ever fully trust a system that has been compromised now, no matter how drastic your recovery procedures might be. Of course, for similar reasons it's also basically impossible to trust a system that you don't know has been compromised either. Security in modern tech is broken, and the tech industry and security services broke it.
Exactly. Firefox fans might like to think that "it's a major platform that web developers have to consider." Sadly, my analytics disagree. For example, I just checked a leisure-related B2C site I run. Mobile is dominant in this market, so the main Android and iOS browsers rank highest as you'd expect. Of the desktop browsers, Chrome is biggest with nearly half the market share, and most of the rest is split between Safari and IE+Edge between them. Firefox comes just above the 1% mark looking at all traffic.
I'm sorry to see things going this way, because Safari is like the new IE and I don't think it's healthy for the future of the Web for Google to have so much influence. But the reality is that for sites like this, Firefox is not even close to being a major platform, and since we have bills to pay, our development effort has to follow the user base.
Well, HMRC is in an impossible position. The tax rules it is required to use are so complicated that I doubt anyone understands them completely, and it it has far too few resources to do its job properly, and the people it does have are often not well trained. (These three factors may be related...)
Given those constraints, I think a lot of the automated systems for filing the main types of return electronically are fairly usable these days. If you do get to speak to a real person from HMRC, in my experience they are usually reasonable and try to do the right thing as well.
However, even if everyone has the best of intentions, the problems lead to HMRC's people making mistakes and giving bad advice and sometimes focussing on the easy things instead of the right things. When you're in a position to seriously affect other people's lives, even if those other people have done nothing wrong or have made an honest mistake while trying to deal with a system too complicated to understand, obviously that's still not good enough.
It's often said that biometrics are user IDs, not passwords. Perhaps that's a little simplistic, but for practical purposes it's probably a better analogy.
The UK government has already said it intends to retain the GDPR rules after Brexit.
The problem is that with the increasing emphasis in technology industries on pushing updates and retiring old software rather than supporting it in the long term, there are fewer and fewer software products available that really are made to last and supported accordingly.
As we were reminded by WannaCry last year, even major organisations in important fields like healthcare were still running significant numbers of Windows XP machines because that was what important diagnostic software was built/certified for, and while not necessarily intended for general use or external connectivity, they may still be attached to internal networks in order to be used for their intended purpose.
Evidently you were right in your reply to my earlier comment that expecting an OS to be properly supported until the declared EOL date may be ill-advised, but unfortunately that doesn't solve the underlying problem that we are increasingly building our tech on foundations that have questionable longevity.
Why is it unreasonable to expect an OS to be supported until the date published by its developer a very long time ago?
Maybe those old systems are redundant or obsolete. Maybe they're not. I don't know, and neither do you, and neither does Microsoft.
I'm still waiting to see what radical improvements have been made in the last 15 years, and why Office 2003 era applications with a handful of modest updates couldn't still do much the same job for most people...