Many of these problems can take days to prove. I don't like proving problems, I like solving them. It's not my fault I find certain classes of "hard" problems easy. While the other people are busy trying to understand the problem, I've already solved it and bored, so I move on. Some problems are not provable. Micro-benchmarks don't show the benefits and macro-benchmarks are to chaotic to convince anyone. Kind of like some race-conditions I have read about. Impossible to debug because the act of debugging makes them go away, they only occur once every few months, and during systems under assorted heavy load. Even with the most advanced kernel debuggers. All you can use is intuition unless you plan on mathematically proving your entire OS.
My issue I mentally see the solutions, but it can take me a long time to figure out the the reasoning behind the solution. If I asked you why a person looks like a person, you couldn't explain it, yet you easily perceive it. Same thing for me. I have a form of perception when it comes to systems and interactions among systems.
This is not "experience". I've always been able to do this, even before I ever got into programming. I actually have a mental disability. There are many things I have extreme difficulty remembering, but I can visualize and remember mental models. Even for problems that I have no experience in, I immediately start making a model before I can do any amount of thinking. I used to work on faculty computers at my University as a student and I would get into conversations with the PHDs. I can't tell you how many times they would assume I was a senior with a major in their profession. I just have a natural grasp of logic and can infer "facts". I think it's because I actually visualize mental models, including missing pieces, and can see if an assumption can fit in that hole.
I have one basic axiom that I have some to accept and use these to guide my ability to make good assumptions for programming and debugging. "There are only a few good ways to make a system do what it does, and if the system is seemingly high quality, then all I need to do is think of a good way to solve the issue and I have probably solved it the same way the people who made the system solved it." In other words, great minds think alike. This simple assumption has worked well for me. Just by looking at a problem, I can quickly create a solution. Because I have been extensively exercising since a young child my ability to create rational mental models that are very accurate, because of my disability, I can very quickly create solutions and debug other people's systems.
Telling a computer to do something is great if someone has already programmed it for you, but most people don't know how to solve a problem in the first place, which means they can't tell a computer how to do it. Programming is not coding. The best you will get is a computer interface that can translate human language into code, but that is not programming. It will still be mostly crap, and I don't mean crap as in coding standards, I mean crap as in useless or dangerous.
Until AIs get smart enough to infer, deduce, and otherwise understand what a human meant not what they said, the general populace won't be able to "program".
SystemD is "anti Unix" because it should be composable. Do one thing, do it well. Each part of the SystemD collection should be standalone useful and easily integrated into other systems. SystemD is modular in word, but not in spirit.
The proof is in the pudding. When you start to see parts of SystemD being used in other systems and other systems replacing parts of SystemD, that is when you know it is good.
I don't get paid to write code, I get paid to create solutions. Writing code is a small part of what I do. If an AI can code for me, that would be great. I still have a job in telling the AI what to code.
Ignoring the subset or problems that actually need formal proofs of correctness, much of the issues I work with are performance and general quality of life problems. The specialists with more formal training use best practice and empirical evidence. Which is great, except it doesn't always work, especially in complicated issues like thread scaling. They show me all kinds of benchmarks proving their design is "correct", but once the rubber hits the road, the system has really strange performance issues. An example might be two O(1) algorithms that suddenly have issues when lots of random access hits them. Individually they work fine, but together they have issues. Turns out to be cache-trashing, garbage collection, memory fragmentation, and general random IO issues. After much arguing, they finally take my original suggestion to use an O(log n) and the system runs faster on average for the case under load, and the observed worse-case is magnitudes better.
Most of the issues have to do with nuanced interactions among many systems. I can't explain how I can notice these issues before they occur, but I can look at a design and find issues that no one else sees. I guess I'd call in intuition. Of course none of my systems have these issues, yet almost no one takes me seriously because I don't have the formal training. Most don't understand the reasoning for my architectural designs, but that's because I see the issues differently. The one saving grace is I'm not the one getting called in at 2am, my crap works.
The commonality that I see is everyone treats these systems as blackboxes. They don't think about how some datastructures require memory allocations to insert, so their O(1) algorithm with bursts of heavy write screws over data locality and forces high garbage-collection rates. I make a lot of quick assumptions with nothing to back them up other than reasoning, my own form of reasoning that only few seem to follow or appreciate. If I can spend 30 seconds figuring out something that will take hours or days to prove with empirical testing, I see that as a net win. But I'm not always correct, only most of the time, and more often than the people who want proper evidence.
I would extend 'Just don't expect a new "army" of software developers' to also include to not push kids into programming or give them a false hope by dumbing it down then telling them how much money they can make.
Much of FreeBSD's gain is in infrastructure, like the host OSes running datacenters, not the guests. Also, many "websites" may have proxies running in front that are Linux, but backend servers that are doing all of the heavy lifting may be FreeBSD. Hard to measure.
SystemD is happy-path programming at its finest. Just don't expect to fix your system when something goes wrong. SystemD's failure paths violate Principle of least astonishment. I work with these type of people all the time. They test the heck out of the happy-path and everything works great, but if they can't test it, they can't imagine it, so they have all kinds of corner cases, and the strange assignment of responsibilities makes the system difficult to reason about.
Programming skill is distributed on a power curve. SystemD's design is below average, but well above median, so I guess it's an overall win.
According to some smaller ISPs, last-mile infrastructure consumes about 1%-2% of their revenue. 8 years ago, it was 20%, but the cost of infrastructure keeps dropping. Is last mile expensive? Yes, but only 1% expensive.
When Level 3 had the two links get cut on the East coast, all kinds of bad happened. With so many alternate routes from other ISPs like AT&T, Charter, Comcast, and others, why such the issue? Turns out those two links carried so much traffic, all of the other ISPs combined couldn't handle the overflow. Level 3 handles A LOT of bandwidth.
In some wildly theoretical sense, it is something like IPv6, but then it isn't at all. Do you even know what an IPv6 header looks like?
Yes, it's worse than IPv6. All of the same issues, but wait, there's more! When someone doesn't understand the problem, they always have a simple solution that no one else has thought of.
IPv6 Internet traffic has been doubling since 2000. The problem is IPv4 traffic has also been about doubling. Most of IPv6's increase has been canceled out by IPv4's increase. From 2014-2015 it went from ~2.5%-5%, and 2015-2016 5%-10%. It's having exponential growth as a percentage. Assuming it can sustain its current rate of growth, we'll have about 100% IPv6 in 3 more years. I doubt this will happen, but it's growing quickly.
Duckduckgo gives me noticeably worse search results. Google fine tunes its searches based on my usage, which make a day and night difference. Duckduckgo doesn't track my usage, reducing its search quality.
These are numbers used in psychology in relation to communication and knowledge transfer. 2/3rds of knowledge cannot be transferred. This is what you call nuances. They are important, more important than everything else. I've talked to many specialists that don't even understand the nuances in their own specialty. They take information too literally and too absolutely.
Humans frequently "magically" adapt the way they communicate to the circumstances under which the communication occurs
Most humans are pretty bad at communicating with humans, and that's the best case. It only gets worse once you include computers. Humans can read between the lines and make decent assumptions, but computers blindly follow what they're told, right off a cliff.
Until we have computers that can fully program themselves without being told what to do by a human, we will continue to need programmers, real programmers not coders.
Understanding the problem in order to describe it is the single hardest part of programming. 80% of programmers don't understand problems, they throw code at a problem and see if the customer thinks it solves the issue. Most programmers rarely understand how their own code works. I question how good automatic code generators can become because human language is a horrible language to describe problems. 7% of communications is verbal, 60% of knowledge cannot be described with human language. I'm not math wiz, but unless a computer can learn how to interpret body language and tone and read between the lines, the best someone can communicate with a computer via natural language is about 7% * 60% = 4.2%.
Unless humans magically become better at communication, automatic code generation is dead on arrival for all but the simplest of tasks.
A photo is not a list of facts. A scene may be, but the lighting, angle, etc are "creative". You can parody a scene from a photo and take your own photo, but the original photo itself is copyrightable.
You seem to have issues with abstractions and take things too literally. I guess I will stop arguing with you. I only just realized it was the same person trolling/misunderstanding the issue.
You must have missed the part of a library being the implementer of an API, not the caller. The library doesn't need to call Open, Read, Close in the correct order because it never calls them. The protocol is part of the API definition because you can't have an API without a protocol and you can't have a protocol without an API. They are the same thing, just different viewpoints.
You may want to spend some time researching what "flip-side of the coin" means.
Slashdot Mirror
Many of these problems can take days to prove. I don't like proving problems, I like solving them. It's not my fault I find certain classes of "hard" problems easy. While the other people are busy trying to understand the problem, I've already solved it and bored, so I move on. Some problems are not provable. Micro-benchmarks don't show the benefits and macro-benchmarks are to chaotic to convince anyone. Kind of like some race-conditions I have read about. Impossible to debug because the act of debugging makes them go away, they only occur once every few months, and during systems under assorted heavy load. Even with the most advanced kernel debuggers. All you can use is intuition unless you plan on mathematically proving your entire OS.
My issue I mentally see the solutions, but it can take me a long time to figure out the the reasoning behind the solution. If I asked you why a person looks like a person, you couldn't explain it, yet you easily perceive it. Same thing for me. I have a form of perception when it comes to systems and interactions among systems.
This is not "experience". I've always been able to do this, even before I ever got into programming. I actually have a mental disability. There are many things I have extreme difficulty remembering, but I can visualize and remember mental models. Even for problems that I have no experience in, I immediately start making a model before I can do any amount of thinking. I used to work on faculty computers at my University as a student and I would get into conversations with the PHDs. I can't tell you how many times they would assume I was a senior with a major in their profession. I just have a natural grasp of logic and can infer "facts". I think it's because I actually visualize mental models, including missing pieces, and can see if an assumption can fit in that hole.
I have one basic axiom that I have some to accept and use these to guide my ability to make good assumptions for programming and debugging. "There are only a few good ways to make a system do what it does, and if the system is seemingly high quality, then all I need to do is think of a good way to solve the issue and I have probably solved it the same way the people who made the system solved it." In other words, great minds think alike. This simple assumption has worked well for me. Just by looking at a problem, I can quickly create a solution. Because I have been extensively exercising since a young child my ability to create rational mental models that are very accurate, because of my disability, I can very quickly create solutions and debug other people's systems.
Telling a computer to do something is great if someone has already programmed it for you, but most people don't know how to solve a problem in the first place, which means they can't tell a computer how to do it. Programming is not coding. The best you will get is a computer interface that can translate human language into code, but that is not programming. It will still be mostly crap, and I don't mean crap as in coding standards, I mean crap as in useless or dangerous.
Until AIs get smart enough to infer, deduce, and otherwise understand what a human meant not what they said, the general populace won't be able to "program".
SystemD is "anti Unix" because it should be composable. Do one thing, do it well. Each part of the SystemD collection should be standalone useful and easily integrated into other systems. SystemD is modular in word, but not in spirit.
The proof is in the pudding. When you start to see parts of SystemD being used in other systems and other systems replacing parts of SystemD, that is when you know it is good.
I don't get paid to write code, I get paid to create solutions. Writing code is a small part of what I do. If an AI can code for me, that would be great. I still have a job in telling the AI what to code.
Ignoring the subset or problems that actually need formal proofs of correctness, much of the issues I work with are performance and general quality of life problems. The specialists with more formal training use best practice and empirical evidence. Which is great, except it doesn't always work, especially in complicated issues like thread scaling. They show me all kinds of benchmarks proving their design is "correct", but once the rubber hits the road, the system has really strange performance issues. An example might be two O(1) algorithms that suddenly have issues when lots of random access hits them. Individually they work fine, but together they have issues. Turns out to be cache-trashing, garbage collection, memory fragmentation, and general random IO issues. After much arguing, they finally take my original suggestion to use an O(log n) and the system runs faster on average for the case under load, and the observed worse-case is magnitudes better.
Most of the issues have to do with nuanced interactions among many systems. I can't explain how I can notice these issues before they occur, but I can look at a design and find issues that no one else sees. I guess I'd call in intuition. Of course none of my systems have these issues, yet almost no one takes me seriously because I don't have the formal training. Most don't understand the reasoning for my architectural designs, but that's because I see the issues differently. The one saving grace is I'm not the one getting called in at 2am, my crap works.
The commonality that I see is everyone treats these systems as blackboxes. They don't think about how some datastructures require memory allocations to insert, so their O(1) algorithm with bursts of heavy write screws over data locality and forces high garbage-collection rates. I make a lot of quick assumptions with nothing to back them up other than reasoning, my own form of reasoning that only few seem to follow or appreciate. If I can spend 30 seconds figuring out something that will take hours or days to prove with empirical testing, I see that as a net win. But I'm not always correct, only most of the time, and more often than the people who want proper evidence.
I would extend 'Just don't expect a new "army" of software developers' to also include to not push kids into programming or give them a false hope by dumbing it down then telling them how much money they can make.
Much of FreeBSD's gain is in infrastructure, like the host OSes running datacenters, not the guests. Also, many "websites" may have proxies running in front that are Linux, but backend servers that are doing all of the heavy lifting may be FreeBSD. Hard to measure.
SystemD is happy-path programming at its finest. Just don't expect to fix your system when something goes wrong. SystemD's failure paths violate Principle of least astonishment. I work with these type of people all the time. They test the heck out of the happy-path and everything works great, but if they can't test it, they can't imagine it, so they have all kinds of corner cases, and the strange assignment of responsibilities makes the system difficult to reason about.
Programming skill is distributed on a power curve. SystemD's design is below average, but well above median, so I guess it's an overall win.
They weren't pushed in time. Changes are pushed, but not all made it into 10.4.
The last mile is very expensive
According to some smaller ISPs, last-mile infrastructure consumes about 1%-2% of their revenue. 8 years ago, it was 20%, but the cost of infrastructure keeps dropping. Is last mile expensive? Yes, but only 1% expensive.
When Level 3 had the two links get cut on the East coast, all kinds of bad happened. With so many alternate routes from other ISPs like AT&T, Charter, Comcast, and others, why such the issue? Turns out those two links carried so much traffic, all of the other ISPs combined couldn't handle the overflow. Level 3 handles A LOT of bandwidth.
They only use NAT for IPv4. Nearly all Smartphones use IPv6 and connection without NAT to services like Google.
Netflix.com, for example, sent out a notification late last week to users who made the mistake of re-using their Netflix password at Linkedin,
Correction, 26^N
Not bad since it was at 5% last year, and 2.5% the year before.
In some wildly theoretical sense, it is something like IPv6, but then it isn't at all. Do you even know what an IPv6 header looks like?
Yes, it's worse than IPv6. All of the same issues, but wait, there's more! When someone doesn't understand the problem, they always have a simple solution that no one else has thought of.
IPv6 Internet traffic has been doubling since 2000. The problem is IPv4 traffic has also been about doubling. Most of IPv6's increase has been canceled out by IPv4's increase. From 2014-2015 it went from ~2.5%-5%, and 2015-2016 5%-10%. It's having exponential growth as a percentage. Assuming it can sustain its current rate of growth, we'll have about 100% IPv6 in 3 more years. I doubt this will happen, but it's growing quickly.
Duckduckgo gives me noticeably worse search results. Google fine tunes its searches based on my usage, which make a day and night difference. Duckduckgo doesn't track my usage, reducing its search quality.
Humans frequently "magically" adapt the way they communicate to the circumstances under which the communication occurs
Most humans are pretty bad at communicating with humans, and that's the best case. It only gets worse once you include computers. Humans can read between the lines and make decent assumptions, but computers blindly follow what they're told, right off a cliff.
Until we have computers that can fully program themselves without being told what to do by a human, we will continue to need programmers, real programmers not coders.
Describe a problem
Understanding the problem in order to describe it is the single hardest part of programming. 80% of programmers don't understand problems, they throw code at a problem and see if the customer thinks it solves the issue. Most programmers rarely understand how their own code works. I question how good automatic code generators can become because human language is a horrible language to describe problems. 7% of communications is verbal, 60% of knowledge cannot be described with human language. I'm not math wiz, but unless a computer can learn how to interpret body language and tone and read between the lines, the best someone can communicate with a computer via natural language is about 7% * 60% = 4.2%.
Unless humans magically become better at communication, automatic code generation is dead on arrival for all but the simplest of tasks.
A photo is not a list of facts. A scene may be, but the lighting, angle, etc are "creative". You can parody a scene from a photo and take your own photo, but the original photo itself is copyrightable.
You seem to have issues with abstractions and take things too literally. I guess I will stop arguing with you. I only just realized it was the same person trolling/misunderstanding the issue.
Your analogy is so bad, it's not even wrong.
You must have missed the part of a library being the implementer of an API, not the caller. The library doesn't need to call Open, Read, Close in the correct order because it never calls them. The protocol is part of the API definition because you can't have an API without a protocol and you can't have a protocol without an API. They are the same thing, just different viewpoints.
You may want to spend some time researching what "flip-side of the coin" means.