So in a functioning market, investors should be able to go long or short on an asset -- that is, it should be possible to assert that it will rise and to assert that it will fall (or if you're clever, buying options that assert the price will remain right where it is).
As far as I can see, a hypothetical person that wanted to bet that bitcoin would fall doesn't really have a vehicle by which to take that position.
That's because the general assumption, in this case, is that the reader already knows how to fly planes in general, and only needs the specifics for this model.
Indeed. And software documentation should assume that the reader already knows how to use a computer in general and only needs the specifics for this particular piece of software.
Take a look at the git book for example. First, it does assume that the reader knows what files are, how files are arranged in a filesystem, how to use a command line. Then it actually explains at high but not abstract level how git actually works. Then it goes through examples of using it. Only last does it provide a reference/glossary type documentation for looking up the detailed syntax of each and every little command.
To be more concrete, not even the most capable and savvy computer person who has never heard of git will be able to understand this sentence:
git fetch Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories." (although this is there).
If you've never heard of git before, it's just bloody meaningless. No matter how much general knowledge you have, even if you've used CVS and SVN before . . .
I agree. These are all abuses that have happened. But that doesn't mean that the policies were put in place for the purpose of abuses rather than by zealous people after other ends.
I think civil forfeiture is awful, but even I have to concede it has been a very useful tool at defunding drug conspiracies (not that I even believe in the War on Drugs in the first place). And I can understand how a zealous drug warrior would see that tool and not give a shit about people standing in the way. I still believe that the potential for abuse greatly outweighs the benefit, but it's madness to say that it was invented for the purpose of abusing it.
So I have to argue against the zealot not because I think he is in a conspiracy to abuse our rights, but because he's after his own windmill and will burn us to the ground to get at it. If you still don't get that, I don't think I can help you.
Man, you are totally degrading our argument against these measures with this ridiculous line of reasoning. Of course these measures are useful against violent criminal organizations and actual people that wish to do harm. It's really trivial to find examples of this (like the dead San Bernardino shooter) and, with the way you've constructed your argument, you lose when an example like that comes out.
What those of us that are serious concede is that there are plenty of times in which such a measure is legitimately useful, but nevertheless, the risk for abuse is far too great and that we understand that as a tradeoff we should forego the legitimate uses to protect against the abuse. This is no different than any other conception of civil liberties -- after all, we know for a fact that our system acquits guilty people for a variety of procedural and other reasons, and that some fraction of those people go on to violate more people's rights. But we accept that as the cost of defendants' protections. Similarly, we accept the concept of parole knowing that some (maybe low) fraction of parolees will commit crimes that violate people's rights. We don't insist that parole can't happen unless that fraction is identically zero.
So quit it with the conspiratorial nonsense of imagining that this is some kind of plot. It's not, and you're making us look like loonies.
What it is is that there are zealots for whatever cause that don't give a shit about our rights and believe that it's better to trample them in order to get the drugs/terrorist/mafia/whatever-bad-guy. And you know what, in a big way that's a lot fucking worse that someone actually wants to enact tyranny. These are guys that are delusional and think they are fighting the good fight.
Oddly enough, besides making us look like loonies, your arguments give them cover by asserting that it must be bad motivations that lead to tyranny. It's exactly the opposite -- it's the zealous pursuit of good motives that pave the way to hell.
Finally, and before I rant further, I want to quote the Supreme Court talking about the purpose of the Fourth Amendment:
The point of the Fourth Amendment which often is not grasped by zealous officers is not that it denies law enforcement the support of the usual inferences which reasonable men draw from evidence. Its protection consists in requiring that those inferences be drawn by a neutral and detached magistrate, instead of being judged by the officer engaged in the often competitive enterprise of ferreting out crime.
Any assumption that evidence sufficient to support a magistrate"s disinterested determination to issue a search warrant will justify the officers in making a search without a warrant would reduce the Amendment to a nullity, and leave the people"s homes secure only in the discretion of police officers. Crime, even in the privacy of one's own quarters, is, of course, of grave concern to society, and the law allows such crime to be reached on proper showing. The right of officers to thrust themselves into a home is also a grave concern, not only to the individual, but to a society which chooses to dwell in reasonable security and freedom from surveillance. When the right of privacy must reasonably yield to the right of search is, as a rule, to be decided by a judicial officer, not by a policeman or government enforcement agent.
I want to make clear, for the majority of software I am strongly of the opinion that perfect knowledge of the source code should not allow an attacker any advantage because the security properties are invariant to the implementation. For a trivial example, you can review the libOTR or TrueCrypt code all day, but the confidentiality of my encrypted volumes rests on the underlying cryptographic ciphers and my ability to keep the password a secret.
But I actually agree with Symantec that AV is a unique exception to this rule, and I justify that by looking at the relationship between the AV software and the threat against which it (allegedly) defends. Specifically, AV software is supposed to detect and quarantine executables running at the same level of privilege as the AV.
So it's essentially an arm's race, using the vagaries of the Windows NT process management as a battlefield. Malware tries to hit itself (from, e.g. EnumProcesses or other attempts to inspect it), AV tries to find it and, in the process, hide itself from malware that would disable or compromise it. In this context, knowing the exact method by which either side works is actually helpful -- and obscurity here (unlike virtually everywhere else) is actually security.
Note there is a weird overlap here between malware and anti-cheat-measures taken by games. In both cases, there is a user-level process that wishes to conceal itself from other software on the system that wishes to inspect/modify its behavior. In practice, any OS facility used for AV can similarly be used by a cheat program, especially if all the program wants to do is read information (like enemy locations in an FPS) from memory.
The human brain, for all it's distraction, drugs, senility and idiocy, is a fairly remarkable error-handling device. It is capable of multiple layers of self-correction and self-audit. Even the basic act of bipedal locomotion requires an extraordinary depth, let alone doing so basically without conscious effort.
Maybe after months of trying to create exactly reproducible builds (hint: it took Debian three frickin years), fighting with the fact that compilers randomize their optimizations (for good and unrelated reasons) and all that noise. That's what's required to get the same version of gcc to produce identical binaries of your regular compiler.
Then you'll figure out that you didn't really appreciate the full scope of the problem because the compiler is just one small place in the system. In fact, the original ACM paper points out that it demonstrates the concept with respect to a C compiler but the same exactly problem resides in the loader and in the microcode of the CPU itself. Each step into the depths reveals a new place where your program is just data* swimming by some other program that can patch it along the way.
* In fact, that's what the entire edifice of computing is built on -- that what is code on one layer of the system is actually just input or output to another. It's so familiar we don't even realize it. When we type 'apt-get whatever' or "execv" or "dlopen" our program is just another blob that someone else's program chews through.
* No, I'll recompile the open-source firmware and reprogram it. Besides the fact that you will be recompiling on an untrusted system, how do you know that are you actually reprogramming it? Because the chip reported success? Maybe their firmware allows itself to be reprogrammed but patches the incoming firmware in a few key places as it comes in?
The article (and much of the subsequent hollering in the comments) conflates two very related items: biometrics in general and a third-party biometric system in which that information is submitted to some centralized place.
On the latter, I have nothing but agreement for what was said about its stupidity and danger, so there is no need to repeat all that -- I incorporate and agree with it here.
But on the former, there is still great promise for biometric systems that are designed specifically to avoid ever sending that information out while still retaining useful properties. So this isn't about biometrics, which like anything else are a tool and not a system.
Some very obvious cases are passports in which the biometric data are held only by the chip inside the passport itself. For concreteness, assume it's fingerprint data (could really be anything). At the time of enrollment, the fingerprint itself along with some keys are loaded onto the passport itself. At the point of verification, you send the fingerprint directly to the passport, which evaluates it and provides a signed response saying "Yes this matches" or "No this doesn't match" but does not divulge any of the data outside its boundary. It's clear that such a system does not lead to the stupidity and danger associated with large databases of biometric data because it simply doesn't require such a thing.
More generally, by being "against biometrics' broadly, the community of folks that are interested in the intersection of security and privacy are forgoing their chance to provide productive input. The result is that you get stupid biometric systems (the kind we all agreed are stupid and dangerous) instead of being able to champion designs with the kind of properties that we want.
[ And indeed, the designs are going to keep coming. It only makes sense to play an all-or-nothing strategy in a game where you might win. ]
So, I agree with all the haterade at SO and all the things it does wrong and stuff. But let's take a moment of reflection and see if maybe we as a community also did something wrong.
My opinion is that it's a total lack of actually useful documentation. And by that I mean there's almost always documentation, but it's at a level of specificity that makes it totally useless.
By way of analogy, imagine getting into an airplane and there's tons of man pages for each instrument like "The throttle control the amount of forward thrust generated by the engines. It has three auto-throttle modes for speed, trim and power, you can enable those modes by setting the auto-throttle switch to the ON position and adjusting the rotary dial to the desired mode. The power mode cannot be used while the autopilot for level is set."
And so on there's documentation on every little thing but nowhere does it actually explain how the hell to fly a plane.
There are projects whose documentation is exactly like this. They are full of great (and useful) detail about how the parts work but there is no place that explains how the whole project works at a general level and how to get it off the ground.
Retraining sometimes ends up being a colossal waste of money and time for all parties.
You'll hear stories about 50-60 year old folks that sit through retraining only to get a check, with no intent of starting a brand new career that will last a mere 10-15 years. So we're paying them, paying the school and the teachers and they will openly and honestly tell you they are just there to punch the clock.
The less time you have left in your working life the less logical is it to invest in skills. There is no amount of contortion that can avoid that basic math.
Indeed. At the same time this sends a strong signal to the next generation of workers about what skills are going to be needed in the future.
As a country, we need to come to terms that technological change within the timespan of a generation is going to change the kind of skills we need. The solution is not to stifle change or to throw those workers to the curb, it's going to be to accept it and to provide a social safety net so that those folks left behind can live in dignity.
I can't see any major player removing support for Bluetooth Audio. So consumers will end with a choice of either using BT, using a legacy headphone jack through a (hopefully free in the box) adapter or using a new one.
This is kind of the opposite of a walled garden, as I understand the term. Here consumers have a choice. In order to be a walled garden, they would have to start locking out all the non-proprietary methods.
Which is fine actually if it's a one time thing. Everything is always bootstrapped from something else, you can't generate trust or identity any other way.
My point was that the more intelligence and creativity were done at the structure/documentation level, the lower the talent level needs to be for the next guy that works on it.
Also, I have no idea what you are talking about in terms of security/frameworks. The cardinal rule we've always had for security reviews is do not ever reimplement anything yourself and instead use a well-reviewed, fuzzed and supported library. This isn't just for crypto, it's for the entire stack where vulnerabilities are found.
I don't suppose you ever tried to review code where someone took your advice and tried to implement their own XML parser in C/C++?
Spoken like someone that has never actually worked on a variety of complex projects with different amounts of legibility.
There are any number of things that a talented team will do to make code much easier to work with: consistent interfaces, explicit contracts, thoughtful modularity, high-level documentation, intuitive log/trace functionalities, unit tests*, etc. Conversely, there are all kinds of traps that make a complex project much more difficult to work with: spaghetti code, completely lack of diagnostics, tight coupling that makes unit testing impossible, principle-of-most-surprise.
Don't get me wrong, there is absolutely such a thing as special talent. But the more I've worked with software, the more I realize that this talent consists of building complex things in understandable & predictable ways. The real superstars are the ones that build frameworks that merely-good programmers can understand and use to build upon. These things absolutely make a huge difference. The better the design/implementation, the less talent is needed to build on top of it with messing things up.
And by the way, this was kind of supposed to be the point. We were supposed to throw open the benefits of computing to everyone. That requires more work to make languages/frameworks readily understandable to the less talented and less of the view that only the elite should code and more of the view that the elite are needed to build the foundation for others to use.
* Actually, one of the hidden benefits of unit testing, besides forcing you to create generic interfaces that can be mocked/stubbed out, is that it provides an instant way to learn about a component of the system. Don't know how foo works, run the unit test and watch it work. Want to know the contract between foo and the rest of the system, look at the pre/post conditions the tests are asserting.
Actually, iOS already (since iOS 8) randomizes the MAC address used for scanning. So unless you are actually joined to TFL's AP (or they are intentionally trying to probe each phone with an RTS) the address changes periodically to a new unique value.
Interestingly, this actually lets TFL get useful information about waiting times at various stations and who transfers where. They just can't track any individual reliably.
Doesn't that imply that "a lot of places" are willing to censor/block the internet connectivity of companies that don't comply? Or do they only attempt it against folks with business/assets that they know they can use as leverage?
Obviously Google and Facebook rely on ad revenue that is collected in each country, so they can't just refuse. But when a smaller internet site flat out refuses, the options to enforce the law against an entity with no assets in the country are limited.
On the flip side, a missed dependency relationship means race condition, and a lot of the migration growing pain were services that had some implicit dependency that wasn't described at first. As time goes on, this baptism by fire does lead to a more robust understanding of service interdependencies.
This is one way to describe it. Another way to describe it is "the existing init services didn't even document their own dependencies correctly and the only reason things worked out was because they were accidentally serialized".
This may be a sane tradeoff, but I don't understand why we aren't willing to rationally acknowledge design tradeoffs, rather than going off at a hint of a mention that there exists a downside to anything.
I mean, I acknowledge for sure that if services do not properly document their own dependencies, things will not work. This is a lot like saying saying that (C) programs which do not check for NULL before dereferences ma crash. No one should be "going off", and the rudeness of systemd developers is legend, but at the same time this is a fairly lame complaint.
Do you really thing the AG is likely to rule against agencies that are being run by appointees of the same governor that appointed them? Or, even more ludicrously, in a FOIA request against the State DOJ?
The AG is the top prosecutor, having him rule on appeals for a document request from the police is literally the opposite of the concept of checks and balances.
Slashdot Mirror
Enslaving seems a bit harsh? They are going to offer them food in exchange for butts. If the crows don't like it they can literally fly off.
So in a functioning market, investors should be able to go long or short on an asset -- that is, it should be possible to assert that it will rise and to assert that it will fall (or if you're clever, buying options that assert the price will remain right where it is).
As far as I can see, a hypothetical person that wanted to bet that bitcoin would fall doesn't really have a vehicle by which to take that position.
That's because the general assumption, in this case, is that the reader already knows how to fly planes in general, and only needs the specifics for this model.
Indeed. And software documentation should assume that the reader already knows how to use a computer in general and only needs the specifics for this particular piece of software.
Take a look at the git book for example. First, it does assume that the reader knows what files are, how files are arranged in a filesystem, how to use a command line. Then it actually explains at high but not abstract level how git actually works. Then it goes through examples of using it. Only last does it provide a reference/glossary type documentation for looking up the detailed syntax of each and every little command.
To be more concrete, not even the most capable and savvy computer person who has never heard of git will be able to understand this sentence:
git fetch
Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories." (although this is there).
If you've never heard of git before, it's just bloody meaningless. No matter how much general knowledge you have, even if you've used CVS and SVN before . . .
I agree. These are all abuses that have happened. But that doesn't mean that the policies were put in place for the purpose of abuses rather than by zealous people after other ends.
I think civil forfeiture is awful, but even I have to concede it has been a very useful tool at defunding drug conspiracies (not that I even believe in the War on Drugs in the first place). And I can understand how a zealous drug warrior would see that tool and not give a shit about people standing in the way. I still believe that the potential for abuse greatly outweighs the benefit, but it's madness to say that it was invented for the purpose of abusing it.
So I have to argue against the zealot not because I think he is in a conspiracy to abuse our rights, but because he's after his own windmill and will burn us to the ground to get at it. If you still don't get that, I don't think I can help you.
Man, you are totally degrading our argument against these measures with this ridiculous line of reasoning. Of course these measures are useful against violent criminal organizations and actual people that wish to do harm. It's really trivial to find examples of this (like the dead San Bernardino shooter) and, with the way you've constructed your argument, you lose when an example like that comes out.
What those of us that are serious concede is that there are plenty of times in which such a measure is legitimately useful, but nevertheless, the risk for abuse is far too great and that we understand that as a tradeoff we should forego the legitimate uses to protect against the abuse. This is no different than any other conception of civil liberties -- after all, we know for a fact that our system acquits guilty people for a variety of procedural and other reasons, and that some fraction of those people go on to violate more people's rights. But we accept that as the cost of defendants' protections. Similarly, we accept the concept of parole knowing that some (maybe low) fraction of parolees will commit crimes that violate people's rights. We don't insist that parole can't happen unless that fraction is identically zero.
So quit it with the conspiratorial nonsense of imagining that this is some kind of plot. It's not, and you're making us look like loonies.
What it is is that there are zealots for whatever cause that don't give a shit about our rights and believe that it's better to trample them in order to get the drugs/terrorist/mafia/whatever-bad-guy. And you know what, in a big way that's a lot fucking worse that someone actually wants to enact tyranny. These are guys that are delusional and think they are fighting the good fight.
Oddly enough, besides making us look like loonies, your arguments give them cover by asserting that it must be bad motivations that lead to tyranny. It's exactly the opposite -- it's the zealous pursuit of good motives that pave the way to hell.
Finally, and before I rant further, I want to quote the Supreme Court talking about the purpose of the Fourth Amendment:
The point of the Fourth Amendment which often is not grasped by zealous officers is not that it denies law enforcement the support of the usual inferences which reasonable men draw from evidence. Its protection consists in requiring that those inferences be drawn by a neutral and detached magistrate, instead of being judged by the officer engaged in the often competitive enterprise of ferreting out crime.
Any assumption that evidence sufficient to support a magistrate"s disinterested determination to issue a search warrant will justify the officers in making a search without a warrant would reduce the Amendment to a nullity, and leave the people"s homes secure only in the discretion of police officers. Crime, even in the privacy of one's own quarters, is, of course, of grave concern to society, and the law allows such crime to be reached on proper showing. The right of officers to thrust themselves into a home is also a grave concern, not only to the individual, but to a society which chooses to dwell in reasonable security and freedom from surveillance. When the right of privacy must reasonably yield to the right of search is, as a rule, to be decided by a judicial officer, not by a policeman or government enforcement agent.
I want to make clear, for the majority of software I am strongly of the opinion that perfect knowledge of the source code should not allow an attacker any advantage because the security properties are invariant to the implementation. For a trivial example, you can review the libOTR or TrueCrypt code all day, but the confidentiality of my encrypted volumes rests on the underlying cryptographic ciphers and my ability to keep the password a secret.
But I actually agree with Symantec that AV is a unique exception to this rule, and I justify that by looking at the relationship between the AV software and the threat against which it (allegedly) defends. Specifically, AV software is supposed to detect and quarantine executables running at the same level of privilege as the AV.
So it's essentially an arm's race, using the vagaries of the Windows NT process management as a battlefield. Malware tries to hit itself (from, e.g. EnumProcesses or other attempts to inspect it), AV tries to find it and, in the process, hide itself from malware that would disable or compromise it. In this context, knowing the exact method by which either side works is actually helpful -- and obscurity here (unlike virtually everywhere else) is actually security.
Note there is a weird overlap here between malware and anti-cheat-measures taken by games. In both cases, there is a user-level process that wishes to conceal itself from other software on the system that wishes to inspect/modify its behavior. In practice, any OS facility used for AV can similarly be used by a cheat program, especially if all the program wants to do is read information (like enemy locations in an FPS) from memory.
The human brain, for all it's distraction, drugs, senility and idiocy, is a fairly remarkable error-handling device. It is capable of multiple layers of self-correction and self-audit. Even the basic act of bipedal locomotion requires an extraordinary depth, let alone doing so basically without conscious effort.
Maybe after months of trying to create exactly reproducible builds (hint: it took Debian three frickin years), fighting with the fact that compilers randomize their optimizations (for good and unrelated reasons) and all that noise. That's what's required to get the same version of gcc to produce identical binaries of your regular compiler.
Then you'll figure out that you didn't really appreciate the full scope of the problem because the compiler is just one small place in the system. In fact, the original ACM paper points out that it demonstrates the concept with respect to a C compiler but the same exactly problem resides in the loader and in the microcode of the CPU itself. Each step into the depths reveals a new place where your program is just data* swimming by some other program that can patch it along the way.
* In fact, that's what the entire edifice of computing is built on -- that what is code on one layer of the system is actually just input or output to another. It's so familiar we don't even realize it. When we type 'apt-get whatever' or "execv" or "dlopen" our program is just another blob that someone else's program chews through.
This and much worse.
The chip that you get from the fab needs to be correspond to the RTL that you sent.
The actual chip ROM that they program has to correspond to the ROM that you want.
The firmware programmed* onto any of the peripherals has to correspond to the firmware you want.
The compiler has to be known not to dynamically insert backdoors when compiling. And no, you cannot verify this by inspecting the compiler source [PDF].
* No, I'll recompile the open-source firmware and reprogram it. Besides the fact that you will be recompiling on an untrusted system, how do you know that are you actually reprogramming it? Because the chip reported success? Maybe their firmware allows itself to be reprogrammed but patches the incoming firmware in a few key places as it comes in?
The article (and much of the subsequent hollering in the comments) conflates two very related items: biometrics in general and a third-party biometric system in which that information is submitted to some centralized place.
On the latter, I have nothing but agreement for what was said about its stupidity and danger, so there is no need to repeat all that -- I incorporate and agree with it here.
But on the former, there is still great promise for biometric systems that are designed specifically to avoid ever sending that information out while still retaining useful properties. So this isn't about biometrics, which like anything else are a tool and not a system.
Some very obvious cases are passports in which the biometric data are held only by the chip inside the passport itself. For concreteness, assume it's fingerprint data (could really be anything). At the time of enrollment, the fingerprint itself along with some keys are loaded onto the passport itself. At the point of verification, you send the fingerprint directly to the passport, which evaluates it and provides a signed response saying "Yes this matches" or "No this doesn't match" but does not divulge any of the data outside its boundary. It's clear that such a system does not lead to the stupidity and danger associated with large databases of biometric data because it simply doesn't require such a thing.
More generally, by being "against biometrics' broadly, the community of folks that are interested in the intersection of security and privacy are forgoing their chance to provide productive input. The result is that you get stupid biometric systems (the kind we all agreed are stupid and dangerous) instead of being able to champion designs with the kind of properties that we want.
[ And indeed, the designs are going to keep coming. It only makes sense to play an all-or-nothing strategy in a game where you might win. ]
So, I agree with all the haterade at SO and all the things it does wrong and stuff. But let's take a moment of reflection and see if maybe we as a community also did something wrong.
My opinion is that it's a total lack of actually useful documentation. And by that I mean there's almost always documentation, but it's at a level of specificity that makes it totally useless.
By way of analogy, imagine getting into an airplane and there's tons of man pages for each instrument like "The throttle control the amount of forward thrust generated by the engines. It has three auto-throttle modes for speed, trim and power, you can enable those modes by setting the auto-throttle switch to the ON position and adjusting the rotary dial to the desired mode. The power mode cannot be used while the autopilot for level is set."
And so on there's documentation on every little thing but nowhere does it actually explain how the hell to fly a plane.
There are projects whose documentation is exactly like this. They are full of great (and useful) detail about how the parts work but there is no place that explains how the whole project works at a general level and how to get it off the ground.
Retraining sometimes ends up being a colossal waste of money and time for all parties.
You'll hear stories about 50-60 year old folks that sit through retraining only to get a check, with no intent of starting a brand new career that will last a mere 10-15 years. So we're paying them, paying the school and the teachers and they will openly and honestly tell you they are just there to punch the clock.
The less time you have left in your working life the less logical is it to invest in skills. There is no amount of contortion that can avoid that basic math.
Indeed. At the same time this sends a strong signal to the next generation of workers about what skills are going to be needed in the future.
As a country, we need to come to terms that technological change within the timespan of a generation is going to change the kind of skills we need. The solution is not to stifle change or to throw those workers to the curb, it's going to be to accept it and to provide a social safety net so that those folks left behind can live in dignity.
I can't see any major player removing support for Bluetooth Audio. So consumers will end with a choice of either using BT, using a legacy headphone jack through a (hopefully free in the box) adapter or using a new one.
This is kind of the opposite of a walled garden, as I understand the term. Here consumers have a choice. In order to be a walled garden, they would have to start locking out all the non-proprietary methods.
Number of times I wanted a translation in the past, Oh, I dunno, 50 years? 0.
Travel is fatal to prejudice, bigotry, and narrow-mindedness,
Actually, with that in mind, it's probably safest if you continue to stay where you are.
Yes. You may eat cake.
I mean, folks can "declare" whatever right? I can declare myself to be the Queen of France.
Which is fine actually if it's a one time thing. Everything is always bootstrapped from something else, you can't generate trust or identity any other way.
provisions for "what if the simulation starts questioning reality"
You mean by injecting doubt and uncertainty into any discussion around whether we are in a simulation?
My point was that the more intelligence and creativity were done at the structure/documentation level, the lower the talent level needs to be for the next guy that works on it.
Also, I have no idea what you are talking about in terms of security/frameworks. The cardinal rule we've always had for security reviews is do not ever reimplement anything yourself and instead use a well-reviewed, fuzzed and supported library. This isn't just for crypto, it's for the entire stack where vulnerabilities are found.
I don't suppose you ever tried to review code where someone took your advice and tried to implement their own XML parser in C/C++?
Spoken like someone that has never actually worked on a variety of complex projects with different amounts of legibility.
There are any number of things that a talented team will do to make code much easier to work with: consistent interfaces, explicit contracts, thoughtful modularity, high-level documentation, intuitive log/trace functionalities, unit tests*, etc. Conversely, there are all kinds of traps that make a complex project much more difficult to work with: spaghetti code, completely lack of diagnostics, tight coupling that makes unit testing impossible, principle-of-most-surprise.
Don't get me wrong, there is absolutely such a thing as special talent. But the more I've worked with software, the more I realize that this talent consists of building complex things in understandable & predictable ways. The real superstars are the ones that build frameworks that merely-good programmers can understand and use to build upon. These things absolutely make a huge difference. The better the design/implementation, the less talent is needed to build on top of it with messing things up.
And by the way, this was kind of supposed to be the point. We were supposed to throw open the benefits of computing to everyone. That requires more work to make languages/frameworks readily understandable to the less talented and less of the view that only the elite should code and more of the view that the elite are needed to build the foundation for others to use.
* Actually, one of the hidden benefits of unit testing, besides forcing you to create generic interfaces that can be mocked/stubbed out, is that it provides an instant way to learn about a component of the system. Don't know how foo works, run the unit test and watch it work. Want to know the contract between foo and the rest of the system, look at the pre/post conditions the tests are asserting.
Actually, iOS already (since iOS 8) randomizes the MAC address used for scanning. So unless you are actually joined to TFL's AP (or they are intentionally trying to probe each phone with an RTS) the address changes periodically to a new unique value.
Interestingly, this actually lets TFL get useful information about waiting times at various stations and who transfers where. They just can't track any individual reliably.
Doesn't that imply that "a lot of places" are willing to censor/block the internet connectivity of companies that don't comply? Or do they only attempt it against folks with business/assets that they know they can use as leverage?
Obviously Google and Facebook rely on ad revenue that is collected in each country, so they can't just refuse. But when a smaller internet site flat out refuses, the options to enforce the law against an entity with no assets in the country are limited.
On the flip side, a missed dependency relationship means race condition, and a lot of the migration growing pain were services that had some implicit dependency that wasn't described at first. As time goes on, this baptism by fire does lead to a more robust understanding of service interdependencies.
This is one way to describe it. Another way to describe it is "the existing init services didn't even document their own dependencies correctly and the only reason things worked out was because they were accidentally serialized".
This may be a sane tradeoff, but I don't understand why we aren't willing to rationally acknowledge design tradeoffs, rather than going off at a hint of a mention that there exists a downside to anything.
I mean, I acknowledge for sure that if services do not properly document their own dependencies, things will not work. This is a lot like saying saying that (C) programs which do not check for NULL before dereferences ma crash. No one should be "going off", and the rudeness of systemd developers is legend, but at the same time this is a fairly lame complaint.
Do you really thing the AG is likely to rule against agencies that are being run by appointees of the same governor that appointed them? Or, even more ludicrously, in a FOIA request against the State DOJ?
The AG is the top prosecutor, having him rule on appeals for a document request from the police is literally the opposite of the concept of checks and balances.