Now map this subtlety to the test of bees reacting to zero or none elements.
The point is the distinction between those scenarios is not testable in non-sapient beings. The interesting nuance of zero being distinct from none is a human invention, and being amazed that an animal can tell nothing is there is a crazy eventuality of overthinking it.
Of course, the challenge is getting cheap no-name cables to avoid shorts when they are putting a 24 pin connector in the form factor they have historically only done 5-pins reliably.
Human factors issue, the usb-c looks and feels a lot lik micro-usb, except reversable to the layman, and no-name micro-usb cables were just fine, at worst poor mechanical fit or didn't work. In other words worth the risk. USB-c with that same degree of screwing up means shorting at high voltage.
He was calling me out on my incorrectly saying (multiple times) higher current when I should have been saying higher power, since I was really comparing watts not amps.
That would be consistent with my anecdotal experience. Had a usb connector break off a board of a device when cable was attached during a lot of variable degree of load bearing, but the tongue was still fine.
This is of course not specifically the fault of the standard and entirely the fault of the mechanical design of the device which had a weak surface mount design with no mechanical reinforcement.
That does puzzle me, common sense says to make the thing likely to break the cable, not the device.
Of course, as the device size increases and companies want to surface mount these connectors, it's a lot of potential torque on the socket itself, so even without the tongue there is still peril.
In USB type-c, offbrand cables are a minefield. The problem is that we have higher current running over tiny connectors. Much more room for destructive overcurrent situations. We are talking about orders of magnitude higher wattage, combined with a 24 pin connector in the same form factor we formerly only wanted to do 5 pins in.
When it works, it's beautiful marvel of modern engineering and manufacturing. But increasing current 10 fold and pincount 5 fold at the same time is a bit much for random cheap vendors with no certification.
That's what I see too, but I also don't have a WWAN connection, so I don't know what sort of stuff he may be facing...
It could just be muscle memory (maybe right click used to have a bunch of options, but that's under the dialog when you left click) or maybe legitimate issues (right click used to have a longer menu of one-click shortcuts that got moved to a multi-step dialog). I wouldn't attribute either of them to being more 'tablet-like', and more about 'dumbing down', to whatever extent it may be true.
I personally find their terminal and expose-rip-off to be rather limited compared to a linux desktop, but I have personally agreed with the sentiment that Windows 10 is mostly a return to general desktop sanity for the platform. I do feel like some operations are perhaps spread across more steps, but it hasn't bothered me.
Fair point for 1.1.1.1 and 8.8.8.8, though in practice I haven't had to manually enter a public nameserver in an eternity. Of course it's not too hard to imagine an IPv6-alike, say 1::1 or similar, which would be just as easy to remember.
I'm more concerned about the state of name resolution moving into web browsers to ignore system name resolution behavior than I am about IPv6 name resolution.
I was thinking the same thing, but I right clicked on the network icon and it really doesn't give options except to start one of a couple of dialogs.
I don't have windows 7 handy, but I would be willing to believe that the right click context menu I'm seeing is pretty crippled compared to what they probably had in Windows 7.
I assume at least some of the folks were sincere and I like to stay on the bright side.
At first with the summary, I naively thought that Ron Jeffries perhaps was showing signs of being sincere in intent (I don't track the names of 'Agile' people, just the results), but then reading the article, it seems he may be more of the sell lots of books and consulting business camp (his message was not 'abandon agile' but doubling down and wrapping any problems 'finding true Agile' in a big 'No True Scotsman' circumstance, with no credible way of knowing in advance whether it's "True Agile" or not (the criteria seemingly being "if it works, it must be Agile, if it fails, it must not be Agile").
It takes two days, one day if they are lucky to cover 4 sentence fragments, or to at least include them?
I doubt it's being moronic, and more the CSM training telling the people what they want to hear. It's very quickly obvious that the managers here *need* to have every little thing planned out way in advance, so they tailor the message to say that maniacally adhering to a plan regardless of changing circumstances is ok, so long as they are 'agile'.
The article spawning this does point out that there's a lot of random stuff branded Agile running about. Maybe he is sincere, or maybe he is trying to stem the tide of people saying Agile is failing them by invoking 'No True Scotsman' as a means for extending the gravy train, but either way that point is at least accurate: in practice Agile means nothing in the face of a lucrative consulting industry that has mangled it into a 'feel good about what you want to do and we'll bless it as Agile whatever it is'.
Hire the right people, and they'll usually have no trouble convincing management to go along with their proposed process changes.
Part of the problem is that management is always hoping that the right methodology will mean they don't need to hire the right people. That there exists some methodology that reduces software development to have employees as interchangeable as fast food workers.
Good management will always seek out the right people, and generally trust those people to do what they need and are happy so long as the results mesh with their ambitions. These teams are less likely to fret about compliance with buzzwords, so even if they are in practice honoring Agile principles (knowingly or not), they will be less likely to bother to claim it.
Bad management will always buy into the hype and label what they want according to hype and run it into the ground. These people will be obsessed with the Agile label and so Agile looks terrible.
Agile in reality isn't really much of anything at all. You spend less than a minute reading 4 phrases, that's it. Those phrases are not miraculous insight, they are just common sense, so if you're good, you don't need to even know those phrases are written down or labelled "Agile" or anything, it's just naturally your reality.
Developers will write some unittests, but just enough to test some new functions here and there in different components.
Also will say that teams have a very bad habit of saying "100% coverage" and then saying "we don't need a QA team, auto testing takes care of all of it". To the extent that my team does unit tests, I don't claim that to management for fear that management will can the QA team, which is comprised not of programmers but people from the target industry, that give functional as well as "this was a dumb idea" feedback.
As to the rest, it doesn't really matter if it's called "Agile" or not, it's the same sort of things you would see in software development before Agile came along. It's the hellish behavior that the folks originally wanted to "fix". The reality is that a bad team will be a bad team, and no matter what they are told, they will find a way to create that same horrendous dynamic using the terminology to fit the "project management fad of the day". When someone sees this and tries to fix it with another promising sounding fad, it too will degrade to what you see today.
The original Agile was simply: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Which has always been pretty obvious to anyone. The problem with the first point is *not* was company leadership wants to be true, they want processes and tools and to be able to toss aside one person for another at will. Also, as a consultant there's more money to be had selling them "Agile tools" than just telling people to work together. So branded-Agile tosses that.
The problem with the second point is that it requires developers intimately understand the user situation and to not be so lazy as to avoid doing the work. In practice "it can be fixed in documentation" remains the "easy way" to cheaply meet schedule.
The third point is simply unrealistic, sadly. Yes from getting a quality product, this is important, but that collaboration taken to the extreme will cause the scope of needed work to grow endlessly. This is of course ok for engagements that are also effectively "limitless", but for project-driven engagements this sadly doesn't work.
Responding to change is the one point everyone would *love* to claim to be a champion of, but managers are accustomed to forecasts, and deviations from plan break forecasts, and as such management really hates this. Of course so do many developers. It's distracting to react to changes in plans and some people just aren't wired that way.
The problem was that the manifesto was common sense and stating plainly how good teams already behaved.
The problem is they and a whole lot of people *thought* that with a plainly spoken set of words, it would be possible to go out and fix the whole industry, which was and still is beset by a whole lot of nonsense in processes and tools.
They were half right, the short document that was easy to understand did resonate with a lot of people and the idea that the way things are being broken resonated with a lot of people, thoughout these organizations.
Two major problems happened. One is that the same traits that drove those teams to create terrible processes and abuse tools are still there, and to some extent doom those teams to always landing in the same place, perhaps changing terminology to comply with the fad (big-A Agile). Call their "status meetings" "Scrum", call their "requirements" "stories", "milestones" becomes "sprints". Change the words and 'poof' they are "Agile".
The other complicating factor is the tools and consultancy business. "Individuals and interactions over processes and tools" is not something that is a profitable stance. So that goes by the wayside and consultants revel in making money reinforcing the above behavior. Consultants know these companies ultimately are spending the money to feel better about the way *they* want to work, and they are happy to oblige. Enough change to be annoying and feel like *something* has changed, but leaving that organization structurally the same, the way management clearly had made it in the first place. On tools, well that is a mess. When asked if my team was "Agile" I replied "yes" (mainly in hopes to deflect the 'transformation initiative") and they asked "Oh, so your team has been paying for Atlassian software then?". Because we didn't happen to be using Atlassian, it was deemed we *must* not be 'Agile' and we had to undergo the bs training and migrate all our stuff to Atlassian tools and in general waste a whole bunch of time. Worse than that, they assigned folks to "help" us be Agile in an ongoing capacity, and demanded we declare 6 months worth of plans for Sprint content and get mad at us when we prioritize responding to a customer request over made-up dates for 'nice to have' backlog items,. When I point out "Responding to change over following a plan" was part of the manifesto, the ostensibly Agile-focused helpers say that's not part of Agile, it wasn't in any of their training, and that they got Agile certification so they should know.
Ok, was just seeing if people were using ULAs incorrectly. As designed it means pretty much never having to have the headache of a conflict when somehow getting routed to another private network, though for most people in practice I have been afraid the required 40 bits of random would exacerbate "I can't type this" sort of problems.
I think I'm less worried about people who know enough and take the time to properly do ULA addressing on their network not NATing than I'm worried about the family who buys a random cheap gateway and turns it on not setting up anything. Today that cheapo device can't help but to effectively firewall that user off for lack of a subnet, but for the default for the random endpoints to get globally addressable addresses *and* the chances of that device bothering to have a properly configured firewall... wel...
There are a lot of little services and facilities that still don't quite work right or fully with IPv6.A lot of these were problems in IPv4 as well, but they *had* to be solved. IPv6 on the other hand, people just shrug and use IPv4 where things are fixed.
Having a private IPv4 address just makes sense, even if alongside IPv6 global addressing. I never need to use global IPv4 addresses manually, there I always rely upon dns. However locally I used htem all the time.
It *could* be as easy as slapping a router in the middle.
The problem is the failure mode of the vendor getting NAT wrong versus getting a firewall mechanism wrong. If the vednors botches the NAT, they can't get through their test and can't ship.
If the firewall rules are incorrect or inadequately implemented, well the routing still works so they probably ship it anyway.
Even if they can work, it's *much* easier for applications to say "open up your firewall" versus "make your computer have a routable IPv4 address.
The population of people that were using Fortran after the year 2000 that are doing Java development to solve their problems rounds to 0%.
Fortran's popularity in brand new codebases for technical computing persisted as it was particularly well suited for scientific computing, a little less able to do fancy programming tricks, but also less intimidating.
A significant portion of that user base has moved to Python, with the heavy lifting done in C libraries that have been written, and the rather less 'scary' looking python as a means to supervise that code.
The division between the rich and poor, is without a question, worse than it was in 1999.
Numerically, perhaps. Quality of life wise, not much has changed. There's some ludicrously rich folk by the numbers, but there's some weirdness in that rarified air that make the numbers not a straghtforward thing to interpret. This is a problem, but probably not a *personal* enough problem.
On top of this, the world is straight the fuck up, dying. We're not working towards protecting it very well, we're not working towards replacing it (finding a new one elsewhere)
Again, this isn't a personal item for people. In fact, on many fronts things are improving and very promising. Sustainable lumber is now the norm rather than the exception. Per-capita energy has gone down. Sustainable energy sources have improved that also reduce release of gasses to atmosphere is on the rise.
Then we have the internet, it's giving the poor access to see what's going on in the world better, they can see just how rich the rich are becoming, they can see the death of the world better than ever before, they can communicate with each other (as I am right now) elaborating on why there's little hope.
When you started with 'the internet' I thought you were going to a relevant place, but then more about class difference and environmental concerns. There are of course challenges there, but the reality is social media causes people to engage more personally and strain our ability to reasonably interact. One person who takes their interactions very personally comes across a person who likes to say things they think are funny and don't take it seriously because 'It's just the internet' and get very hurt and take it way too seriously. It's a forum for expression that dehumanizes folks and create a toxic atmosphere that carries over into people's real lives.
Because the write jumper on the board would be left in 'write' position by most people and offer no protection is the short answer.
There was even a brief period where the jumper you described actually did exist for some vendors (it was 'bypass signing') but it was used as a debug tool and undocumented for the users. Eventually security folks declared that to be too risky in the face of the chance of a supply chain attack. Middle-men along the product's journey to the customer can mess with jumpers and dip switches all day long.
Unfortunately, expect this to be more normal. If there's any whiff of a security issue with an older firmware, companies are afraid of being downright liable for problems with users voluntarily running older firmware.
The security issue can be absolutely zero risk (either unused path, implausible attack vector in the context, or even not having the code at all but updating because people assume it would), but it's just too scary to take a chance.
Basically this makes git into a centralized version control scheme rather than distributed.
There are limitations of a fully distributed scheme (not well suited for large binary files, for example), but the limitations did at least induce a healthy set of sensibilities in developers using git. Keep large binary blobs out of your build tree, keep things so that each device is a full backup of the critical stuff, etc.
This will mainly cause people who use it on their github repository to have a harder time leaving and/or mirroring to other services... oh wait....
Slashdot Mirror
Now map this subtlety to the test of bees reacting to zero or none elements.
The point is the distinction between those scenarios is not testable in non-sapient beings. The interesting nuance of zero being distinct from none is a human invention, and being amazed that an animal can tell nothing is there is a crazy eventuality of overthinking it.
Of course, the challenge is getting cheap no-name cables to avoid shorts when they are putting a 24 pin connector in the form factor they have historically only done 5-pins reliably.
Human factors issue, the usb-c looks and feels a lot lik micro-usb, except reversable to the layman, and no-name micro-usb cables were just fine, at worst poor mechanical fit or didn't work. In other words worth the risk. USB-c with that same degree of screwing up means shorting at high voltage.
He was calling me out on my incorrectly saying (multiple times) higher current when I should have been saying higher power, since I was really comparing watts not amps.
That would be consistent with my anecdotal experience. Had a usb connector break off a board of a device when cable was attached during a lot of variable degree of load bearing, but the tongue was still fine.
This is of course not specifically the fault of the standard and entirely the fault of the mechanical design of the device which had a weak surface mount design with no mechanical reinforcement.
That does puzzle me, common sense says to make the thing likely to break the cable, not the device.
Of course, as the device size increases and companies want to surface mount these connectors, it's a lot of potential torque on the socket itself, so even without the tongue there is still peril.
In USB type-c, offbrand cables are a minefield. The problem is that we have higher current running over tiny connectors. Much more room for destructive overcurrent situations. We are talking about orders of magnitude higher wattage, combined with a 24 pin connector in the same form factor we formerly only wanted to do 5 pins in.
When it works, it's beautiful marvel of modern engineering and manufacturing. But increasing current 10 fold and pincount 5 fold at the same time is a bit much for random cheap vendors with no certification.
That's what I see too, but I also don't have a WWAN connection, so I don't know what sort of stuff he may be facing...
It could just be muscle memory (maybe right click used to have a bunch of options, but that's under the dialog when you left click) or maybe legitimate issues (right click used to have a longer menu of one-click shortcuts that got moved to a multi-step dialog). I wouldn't attribute either of them to being more 'tablet-like', and more about 'dumbing down', to whatever extent it may be true.
I personally find their terminal and expose-rip-off to be rather limited compared to a linux desktop, but I have personally agreed with the sentiment that Windows 10 is mostly a return to general desktop sanity for the platform. I do feel like some operations are perhaps spread across more steps, but it hasn't bothered me.
Fair point for 1.1.1.1 and 8.8.8.8, though in practice I haven't had to manually enter a public nameserver in an eternity. Of course it's not too hard to imagine an IPv6-alike, say 1::1 or similar, which would be just as easy to remember.
I'm more concerned about the state of name resolution moving into web browsers to ignore system name resolution behavior than I am about IPv6 name resolution.
I was thinking the same thing, but I right clicked on the network icon and it really doesn't give options except to start one of a couple of dialogs.
I don't have windows 7 handy, but I would be willing to believe that the right click context menu I'm seeing is pretty crippled compared to what they probably had in Windows 7.
I assume at least some of the folks were sincere and I like to stay on the bright side.
At first with the summary, I naively thought that Ron Jeffries perhaps was showing signs of being sincere in intent (I don't track the names of 'Agile' people, just the results), but then reading the article, it seems he may be more of the sell lots of books and consulting business camp (his message was not 'abandon agile' but doubling down and wrapping any problems 'finding true Agile' in a big 'No True Scotsman' circumstance, with no credible way of knowing in advance whether it's "True Agile" or not (the criteria seemingly being "if it works, it must be Agile, if it fails, it must not be Agile").
It takes two days, one day if they are lucky to cover 4 sentence fragments, or to at least include them?
I doubt it's being moronic, and more the CSM training telling the people what they want to hear. It's very quickly obvious that the managers here *need* to have every little thing planned out way in advance, so they tailor the message to say that maniacally adhering to a plan regardless of changing circumstances is ok, so long as they are 'agile'.
The article spawning this does point out that there's a lot of random stuff branded Agile running about. Maybe he is sincere, or maybe he is trying to stem the tide of people saying Agile is failing them by invoking 'No True Scotsman' as a means for extending the gravy train, but either way that point is at least accurate: in practice Agile means nothing in the face of a lucrative consulting industry that has mangled it into a 'feel good about what you want to do and we'll bless it as Agile whatever it is'.
Hire the right people, and they'll usually have no trouble convincing management to go along with their proposed process changes.
Part of the problem is that management is always hoping that the right methodology will mean they don't need to hire the right people. That there exists some methodology that reduces software development to have employees as interchangeable as fast food workers.
Good management will always seek out the right people, and generally trust those people to do what they need and are happy so long as the results mesh with their ambitions. These teams are less likely to fret about compliance with buzzwords, so even if they are in practice honoring Agile principles (knowingly or not), they will be less likely to bother to claim it.
Bad management will always buy into the hype and label what they want according to hype and run it into the ground. These people will be obsessed with the Agile label and so Agile looks terrible.
Agile in reality isn't really much of anything at all. You spend less than a minute reading 4 phrases, that's it. Those phrases are not miraculous insight, they are just common sense, so if you're good, you don't need to even know those phrases are written down or labelled "Agile" or anything, it's just naturally your reality.
Developers will write some unittests, but just enough to test some new functions here and there in different components.
Also will say that teams have a very bad habit of saying "100% coverage" and then saying "we don't need a QA team, auto testing takes care of all of it". To the extent that my team does unit tests, I don't claim that to management for fear that management will can the QA team, which is comprised not of programmers but people from the target industry, that give functional as well as "this was a dumb idea" feedback.
As to the rest, it doesn't really matter if it's called "Agile" or not, it's the same sort of things you would see in software development before Agile came along. It's the hellish behavior that the folks originally wanted to "fix". The reality is that a bad team will be a bad team, and no matter what they are told, they will find a way to create that same horrendous dynamic using the terminology to fit the "project management fad of the day". When someone sees this and tries to fix it with another promising sounding fad, it too will degrade to what you see today.
The original Agile was simply:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Which has always been pretty obvious to anyone.
The problem with the first point is *not* was company leadership wants to be true, they want processes and tools and to be able to toss aside one person for another at will. Also, as a consultant there's more money to be had selling them "Agile tools" than just telling people to work together. So branded-Agile tosses that.
The problem with the second point is that it requires developers intimately understand the user situation and to not be so lazy as to avoid doing the work. In practice "it can be fixed in documentation" remains the "easy way" to cheaply meet schedule.
The third point is simply unrealistic, sadly. Yes from getting a quality product, this is important, but that collaboration taken to the extreme will cause the scope of needed work to grow endlessly. This is of course ok for engagements that are also effectively "limitless", but for project-driven engagements this sadly doesn't work.
Responding to change is the one point everyone would *love* to claim to be a champion of, but managers are accustomed to forecasts, and deviations from plan break forecasts, and as such management really hates this. Of course so do many developers. It's distracting to react to changes in plans and some people just aren't wired that way.
The problem was that the manifesto was common sense and stating plainly how good teams already behaved.
The problem is they and a whole lot of people *thought* that with a plainly spoken set of words, it would be possible to go out and fix the whole industry, which was and still is beset by a whole lot of nonsense in processes and tools.
They were half right, the short document that was easy to understand did resonate with a lot of people and the idea that the way things are being broken resonated with a lot of people, thoughout these organizations.
Two major problems happened. One is that the same traits that drove those teams to create terrible processes and abuse tools are still there, and to some extent doom those teams to always landing in the same place, perhaps changing terminology to comply with the fad (big-A Agile). Call their "status meetings" "Scrum", call their "requirements" "stories", "milestones" becomes "sprints". Change the words and 'poof' they are "Agile".
The other complicating factor is the tools and consultancy business. "Individuals and interactions over processes and tools" is not something that is a profitable stance. So that goes by the wayside and consultants revel in making money reinforcing the above behavior. Consultants know these companies ultimately are spending the money to feel better about the way *they* want to work, and they are happy to oblige. Enough change to be annoying and feel like *something* has changed, but leaving that organization structurally the same, the way management clearly had made it in the first place. On tools, well that is a mess. When asked if my team was "Agile" I replied "yes" (mainly in hopes to deflect the 'transformation initiative") and they asked "Oh, so your team has been paying for Atlassian software then?". Because we didn't happen to be using Atlassian, it was deemed we *must* not be 'Agile' and we had to undergo the bs training and migrate all our stuff to Atlassian tools and in general waste a whole bunch of time. Worse than that, they assigned folks to "help" us be Agile in an ongoing capacity, and demanded we declare 6 months worth of plans for Sprint content and get mad at us when we prioritize responding to a customer request over made-up dates for 'nice to have' backlog items,. When I point out "Responding to change over following a plan" was part of the manifesto, the ostensibly Agile-focused helpers say that's not part of Agile, it wasn't in any of their training, and that they got Agile certification so they should know.
Ok, was just seeing if people were using ULAs incorrectly. As designed it means pretty much never having to have the headache of a conflict when somehow getting routed to another private network, though for most people in practice I have been afraid the required 40 bits of random would exacerbate "I can't type this" sort of problems.
I think I'm less worried about people who know enough and take the time to properly do ULA addressing on their network not NATing than I'm worried about the family who buys a random cheap gateway and turns it on not setting up anything. Today that cheapo device can't help but to effectively firewall that user off for lack of a subnet, but for the default for the random endpoints to get globally addressable addresses *and* the chances of that device bothering to have a properly configured firewall... wel...
There are a lot of little services and facilities that still don't quite work right or fully with IPv6.A lot of these were problems in IPv4 as well, but they *had* to be solved. IPv6 on the other hand, people just shrug and use IPv4 where things are fixed.
are use really using fd00::/8 or are you proeperly using a fd::/48 from that network?
Having a private IPv4 address just makes sense, even if alongside IPv6 global addressing. I never need to use global IPv4 addresses manually, there I always rely upon dns. However locally I used htem all the time.
It *could* be as easy as slapping a router in the middle.
The problem is the failure mode of the vendor getting NAT wrong versus getting a firewall mechanism wrong. If the vednors botches the NAT, they can't get through their test and can't ship.
If the firewall rules are incorrect or inadequately implemented, well the routing still works so they probably ship it anyway.
Even if they can work, it's *much* easier for applications to say "open up your firewall" versus "make your computer have a routable IPv4 address.
The population of people that were using Fortran after the year 2000 that are doing Java development to solve their problems rounds to 0%.
Fortran's popularity in brand new codebases for technical computing persisted as it was particularly well suited for scientific computing, a little less able to do fancy programming tricks, but also less intimidating.
A significant portion of that user base has moved to Python, with the heavy lifting done in C libraries that have been written, and the rather less 'scary' looking python as a means to supervise that code.
The division between the rich and poor, is without a question, worse than it was in 1999.
Numerically, perhaps. Quality of life wise, not much has changed. There's some ludicrously rich folk by the numbers, but there's some weirdness in that rarified air that make the numbers not a straghtforward thing to interpret. This is a problem, but probably not a *personal* enough problem.
On top of this, the world is straight the fuck up, dying. We're not working towards protecting it very well, we're not working towards replacing it (finding a new one elsewhere)
Again, this isn't a personal item for people. In fact, on many fronts things are improving and very promising. Sustainable lumber is now the norm rather than the exception. Per-capita energy has gone down. Sustainable energy sources have improved that also reduce release of gasses to atmosphere is on the rise.
Then we have the internet, it's giving the poor access to see what's going on in the world better, they can see just how rich the rich are becoming, they can see the death of the world better than ever before, they can communicate with each other (as I am right now) elaborating on why there's little hope.
When you started with 'the internet' I thought you were going to a relevant place, but then more about class difference and environmental concerns. There are of course challenges there, but the reality is social media causes people to engage more personally and strain our ability to reasonably interact. One person who takes their interactions very personally comes across a person who likes to say things they think are funny and don't take it seriously because 'It's just the internet' and get very hurt and take it way too seriously. It's a forum for expression that dehumanizes folks and create a toxic atmosphere that carries over into people's real lives.
Because the write jumper on the board would be left in 'write' position by most people and offer no protection is the short answer.
There was even a brief period where the jumper you described actually did exist for some vendors (it was 'bypass signing') but it was used as a debug tool and undocumented for the users. Eventually security folks declared that to be too risky in the face of the chance of a supply chain attack. Middle-men along the product's journey to the customer can mess with jumpers and dip switches all day long.
Unfortunately, expect this to be more normal. If there's any whiff of a security issue with an older firmware, companies are afraid of being downright liable for problems with users voluntarily running older firmware.
The security issue can be absolutely zero risk (either unused path, implausible attack vector in the context, or even not having the code at all but updating because people assume it would), but it's just too scary to take a chance.
It makes a sparse checkout, ensuring that each 'clone' is inadequate to be a new master.
Contrast with git, where the 'origin' could be utterly nuked and any developer who had been working on it could provide a restoration.
Basically, GVFS is turning git into something more svn like, albeit with more local data mirrored.
Basically this makes git into a centralized version control scheme rather than distributed.
There are limitations of a fully distributed scheme (not well suited for large binary files, for example), but the limitations did at least induce a healthy set of sensibilities in developers using git. Keep large binary blobs out of your build tree, keep things so that each device is a full backup of the critical stuff, etc.
This will mainly cause people who use it on their github repository to have a harder time leaving and/or mirroring to other services... oh wait....