I'm not sure about Go, but.Net has some interesting deadlock situations with async not all of your code is 100% async. Which is annoying because most opensource.Net libraries are not async. I had to help a co-worker with some GCC Go pseudo-deadlock issues many years back. I found it rewarding to have solved a deadlock issue in a language that I had zero experience and turned out it was an implementation detail of how GCC handled "async" at the time, via threads, and when the thread-pool ran out of threads to handle go-routines, the producer and consumer could be handled on the same thread and block each other. Took me about 15 minutes. I say "pseudo" because if a routine blocked too long, the scheduler would change which routing is running, which "fixed" the issue after some hesitation. You'd get this strange jittering that got worse as more routines were running, quickly getting to tens of seconds in our test.
Once you have a mental model of how concurrency works, it doesn't matter which platform you're on. There's only a few good ways to implement it.
Async allows for high scaling when dealing with lots "messages" moving through the system. Context switching is crazy expensive, about 10,000 cycles on a modern CPU. That's not including a lot of other contention that's created in the kernel. To put it simply, if you want a single server handling 100Gb of traffic with millions of network states, you HAVE to use async. And yes, a single server can handle 100Gb of traffic over 100,000/s of short lived connections.
Right there with you. I've been coding multi-threaded code for nearly a decade now. It's not the difficult. My first real-world application was threaded. Taught myself threading in 3 days, wrote my own synchronization code. Looking back, I cringe at what I did, but it worked perfectly and I have not had to touch the code in 8 years. Not bad for re-writing an existing program that had been under constant development for almost a year, in only three weeks, fresh out of college, about two weeks of experience programming, and having never written multi-threaded code before.
I recently had to look over my code again to turn it into a library, which took me less than a day. Well written threaded code is well factored with single-responsibility taken to the extreme. I don't like more than one piece of code modifying shared state. This lends itself well to be converted into a library, so most of my work was already done for me, but some annoying coding habits that I had were annoying.
Dedicated clusters can run through 90% of all passwords 8-16 characters in a matter of hours/days.
A 16 char password has nearly 10^32 combinations. If you had 100,000 computers, each with 100 cores that are 10ghz, it would take 10^12 seconds to go through all of the combinations, assuming it only took 1 clock cycle per comparison. That's still almost 32,000 years. Please, let me know about this magical datacenter of your's.
Your tool obviously makes many assumptions, like the password is composed of words or common patterns.
Paying $20/m for 150/150 dedicated fiber, $50 after 6 months. I have my own personal fiber from my home to the CO and the ISP says I will get my bandwidth 24/7. 6ms-12ms to Chicago, depending on which trunk to Level 3 they're using. Zero peering, no CDNs, just pure bandwidth, 100+ years old, been a customer for 10+ years and my bill has never gone up a single penny but recently is has gone down 50%. They got rid of their 20/20 for $30, 70/70 for $70, 100/100 for $90 and replaced them all with 150/150 for $50. People with the lowest tier were grandfathered in, but if they ever want to change speeds, I guess their bill is going to go up. That being said, they only recently created the lowest tier a few years ago. The decade prior, they only had a $70 and $90 tier. If only I could afford their $300 1gb/1gb.
You've got to love their marketing
It’s dedicated symmetrical fiber so speeds never change.
150 Mbps Dedicated Symmetrical $49.99/m
Recommended for
Web hosting
Online gaming
Heavy data transfer
Cloud computing
Webinar hosting
Extremely large online backups
Their network policy is nice to
The Company does not favor or inhibit lawful applications or classes of applications.
The Company does not knowingly and intentionally block, impair, degrade or delay the traffic on its network
The Company does not use or demand “pay-for-priority” or similar arrangements that directly or indirectly favor some traffic over other traffic.
The Company does not prioritize its own content, application, services, or devices, or those of its affiliates.
The Company does not charge edge service providers of content, applications, services and/or devices a fee simply for transporting traffic between the edge service provider and its customers.
Forgot to add why anti-bufferbloat AQMs help with link utilization. They help reduce the "thundering herd" caused by dumb tail-drop FIFO buffers that cause global TCP synchronization. If you look at a normal FIFO based link with lots of flows, the typically max out a little over 80% utilization as latency, jitter, and loss skyrocket. Constant TCP streams swinging up and down cause bursts of backoffs, causing the link to violently change from over-utilized to under-utilized very quickly. AQMs tend to have an elastic queue that works more like a head-drop, biased toward dropping packets of the heaviest flows in that instant.
This allows links to reclaim a lot of that left over 20% while stabilizing packet quality at the same time.
Using modern stateless configureless buffer management algorithms, you can have low latency, low loss, low jitter, and a mostly even distribution of bandwidth. High latency is caused by bufferbloat. Fix the bloat, fix all of the issues you mentioned, but with out of the box simplicity near-zero-configuration(set your bandwidth).
Some interesting statistics that I read about research on bufferbloat is that a very small percentage of flows are "hogs" are any given instant. They tested link rates from 133Mb/s all the way up to 10Gb/s, and they all had the same numbers. Even though they all had hundreds of thousands of active flows, at any given instant, only 100 flows had at least one packet in the link's buffer, and only 10 flows had 2 or more packets in the buffer. This means that you only need to track about 100 "states" of data, regardless the link rate or saturation.
Many fair queuing algorithms have taken advantage of this and just create hash buckets. There are only about 100 states in the buffer at any given time, meaning if you have something like 1024 buckets, the chance of any two network flows colliding is relatively low, but not zero. Another algorithm extended this to include "ways", where each bucket can have up to 8 flows in it, but round robins them. Turns out that adding these few "ways" resulted in zero collisions going into millions of states over a relatively slow congested link.
This all means a link can 100% isolate an infinite number of flows over a link while only using a small amount of fixed memory. Next advancement. Most of the time when a packet enters the buffer, it quickly leaves it. When a packet comes into the buffer, it gets shoved into a bucket+way. If this bucket+way was empty, this packet gets prioritized over all other non-new packets. Because 99.9999% of the time there are zero packets in the buffer for a given flow, this allows the non-hog traffic to get immediately scheduled.
If a data flow suddenly starts to become a hog, that means when the next packet arrives, there will already be an existing packet in the bucket+way, meaning that packet does not get prioritized and instead back-logs. But remember, this situation only applies to about 10 flows at any given instant. All of this means that 99.9999% of all packets immediately dequeue with near zero latency. The "hogs" get their additional packets delayed as they start to backlog, and if the link is too saturated, eventfully the packet is dropped. When this happens, the sender backs off and they are no longer a hog.
Turns out that doing it this way actually results in better link utilization. You can run the link to something like 99% utilization while still maintaining fractional millisecond latencies, and average utilization is higher. win-win-win. Zero downsides other than increased CPU usage. Right now they are able to run these algorithms on standard x86 routers/firewalls almost into the 40Gb range, but are hoping future optimizations to network stacks will allow higher. Assuming these algorithms get well tested, they will started to get implemented in hardware. DOCSIS 3.1 actually makes use of RED by default, which is a non-fair queue FIFO anti-bufferbloat AQM. RED is Codel-like but is friendly to Cisco ASICS.
Not mine. ToS I signed says they're net neutral and do absolutely no shaping or QoS. Not only does it say they do not do this, but promise not to. Enterprise and residential users all get the same "priority". They tried QoS in the past, but it has too many coner cases, making customer unhappy, which increased support costs. It was cheaper just to purchase more bandwidth to guarantee no congestion than to mess with shaping or QoS.
I don't do any QoS and I don't have any issues with latency during link saturation. You're complicating the problem because you now need to define all of the rules needed to match your classes of traffic. Using a modern Fair Queuing AQM, you can maintain low latency, jitter, and loss for VoIP while allowing Torrent to saturate your connection with virtually zero configuration. Look up Codel, fqCodel, RED, fqRED, or Cake.
Implementation differences of the algorithms can cause differences in the results, but I am currently maintaining a sub 1ms jitter 24/7. 1.2ms ping with 0.2ms std-dev to be more precise. Even during a 1Gb/s DOS against my prior 100Mb connection, my ping never went above 30ms because my ISP also uses an AQM.
Fair Queuing AQMs can change the order of packets, but they do not do any inspection other than hashing L3/L4 for hash table distribution purposes. Because of this, I would not go so far to say what you can or cannot do, as long as it is "fair" and agnostic.
that taught you is the experience of trying to program your actual device
Some people don't need to physically try to gain experience. There is actually a small subset of the population that learns by thinking about a situation. They are good at creating accurate mental models, allowing them to not until gain deep understanding of programming, but to learn from mistakes they have only made in their head, where they can make mistakes as fast as they can think, allowing them to progress much faster.
Just make up numbers like everyone else does. Statistically, a single interruption like email notification or IM popping up, regardless if you read it, can set you back 15-30 minutes. With such common interruptions being several factors greater than the resolution of time trying to be recorded, and for something as subjective as "how much time will it take to get back on track", you may as well make up numbers.
If I've spent 1 hour thinking about a hard issue, and some other project comes a long as is all like "zomg, this needs to be fixed NOAW!", even if it takes me 5 minutes, they're getting charged that hour I just spent on the other project. Why should the other project have to pay for interruptions making their code more inefficient to create?
2) ARM is, or rather, was, not afraid to put efficiency above complete and total backward compatibility
They were only "highly efficient" because they were not high performance. They've tried to make CPUs as powerful as x86 cores, but they consumed much more power and still quite weaker. This has been their weakness in the datacenter. All of the power savings is lost to needing more cores and systems. Great embedded type systems, or possibly low end desktops, but horrible for most workloads for high-end servers.
2/3rds of knowledge is not factual, it is context sensitive, it is nuanced in a way that human language cannot communicate. Many in psychology actually use apprenticeships as an example of the best way to transfer knowledge this knowledge, lots of hands-on experience watching a master at work.
One of the most highly acclaimed books on Software Architecture started the book saying, if you have to read this or any other book to become the required master at software design to be an Architect, you will never be a good architect. His recommendation was to get your money back for the book.
I don't read books to gain knowledge, that is stupid when you can google almost all knowledge, I read them to learn to think differently. One book so eloquently put it, you will never be a master as programming if you listen to others, even them. They went on to say that even if another master at programming tells you to NEVER do something, if you listen, you will never become a master. You need to be able to make your own decisions. Masters follow their intuition, which supersedes all forms of knowledge. You can't learn intuition from a book.
I've started to use the phrase "wrong for the right reasons" more. The kinds of issues I work on are in their nature unable to be empirically measured or reproducible, yet I can fix them. Most of these issues I trivially know where to look, and I can spend hours trying to explain my logic to another person that I consider very very smart. Why is your software running slow when you try to use every form of profiling and unable to find a hot path? Or an issue that only occurs once in a great while and does not happen when you have trace or debug code enabled? This is the kind of stuff I live for.
Numerous times I have had people show me how their code runs fast, they have micro and macro benchmarked the code, but I tell them it will run slowly. All goes well in production for a while until a tipping point is hit, then suddenly it comes crashing down. I make my changes and everything is running well again. Even when they look at my changes and I try to tell them why I made each change, they still cannot fully grasp why my version works so much better. And these are very knowledgeable smart people.
I do not consider myself very knowledgeable or very smart, in the normal sense of the word at least, but I seem to have a very strong intuition about designing, debugging, and optimizing. Never ever in my life have I ever had to try at programming. It's always been a natural extension of the way I think.
Performance metrics have their limits. They can tell you if someone was done, but not done well. I have hugely complex projects that have been handling feature creep for years, the number of bugs can be counted on one hand. Other people have simple project littered with bugs. Their metrics look better because they're "getting more done", lots of bugs to fix.
One of my managers, in his 20+ years of being in engineering, told me by all metrics, I am the slowest, but by results, I am the fastest.
66% of knowledge is not transferable via communications of any form, which is why hiring to 3rd parties rarely works, because domain knowledge and requirements cannot be properly conveyed via humans, not matter how hard they try.. 90% of what can be communicated is tonal or body language. 10% of 33% is 3.3%. Your mentoring is only 3.3% transferable. Grats.
A moron in a hurry makes mistakes. We've all been there, and it will happen again. Where we should not make mistakes is when doing something of high importance where you have time and you need to research to make sure you do it correctly. When I have an issue that requires more time thinking than coding, I almost never make mistakes, and especially not obvious mistakes.
My last potential bug was when I was assigning values in a struct. While I made sure the order of the memory locations being assigned were thread-safe, I only realized later that because the struct was larger than 8 bytes(on a 64bit system), the values in the struct would require two writes to fully copy the data. This could have caused a torn read. None of the other programmers reviewing my code noticed this glaring issue.
In this situation I to was a moron in a hurry. Luckily, when I read code, I think about what it compiles down into. Something about this code was making a voice in my mind say something was wrong. I seem to have a strong intuition, I always have, even when I first started coding. If I wasn't told to completely write an 8 week project in 1 week, I probably would not have submitted my code for review prior to noticing such a horrible bug.
ZFS is only bad performance for low end system. Throw 32GiB+ of memory and quad core or more at it and it's faster than nearly all other filesystems out there. It scales.
1/1000 chance seems low until you have 1mil numbers. Then you have 1,000 cards that work during that one hour. Of course you won't know which ones until you "try" them, however that works.
One of my cousins was worried about her children walking to school a few blocks. My other cousin did a bit of digging and found out only about 5 children are abducted per year in our state, nearly all of them are the parents, and the one here or there are close friends of the family. There has not been a kidnapping by a stranger in many years.
We get flash flood warnings before the weather hits. Saw a blob of red about 1/4 the size of the state, figured something was going to happen. About 4 hours before the storm got here, flash flood warnings went out.
KE scales with the square of the exhaust, but the amount of KE required scales N^2, so the squaring cancels out and you're left with "net-work done scales linearly with the exhaust velocity and logarithmically with the mass of the propellant."
That's won't be true for very long. Several cheap high density non-wearing storage technologies are being worked on to be made commercial. Most are fast as dram and on-volatile, but some are even faster than dram, as fast as L1 cache SRAM, and about 4x the density while being about 1000x more power efficient. Much of this tech is already in limited commercial use and quickly getting cheaper and higher yields.
Slashdot Mirror
I'm not sure about Go, but .Net has some interesting deadlock situations with async not all of your code is 100% async. Which is annoying because most opensource .Net libraries are not async. I had to help a co-worker with some GCC Go pseudo-deadlock issues many years back. I found it rewarding to have solved a deadlock issue in a language that I had zero experience and turned out it was an implementation detail of how GCC handled "async" at the time, via threads, and when the thread-pool ran out of threads to handle go-routines, the producer and consumer could be handled on the same thread and block each other. Took me about 15 minutes. I say "pseudo" because if a routine blocked too long, the scheduler would change which routing is running, which "fixed" the issue after some hesitation. You'd get this strange jittering that got worse as more routines were running, quickly getting to tens of seconds in our test.
Once you have a mental model of how concurrency works, it doesn't matter which platform you're on. There's only a few good ways to implement it.
Async allows for high scaling when dealing with lots "messages" moving through the system. Context switching is crazy expensive, about 10,000 cycles on a modern CPU. That's not including a lot of other contention that's created in the kernel. To put it simply, if you want a single server handling 100Gb of traffic with millions of network states, you HAVE to use async. And yes, a single server can handle 100Gb of traffic over 100,000/s of short lived connections.
Right there with you. I've been coding multi-threaded code for nearly a decade now. It's not the difficult. My first real-world application was threaded. Taught myself threading in 3 days, wrote my own synchronization code. Looking back, I cringe at what I did, but it worked perfectly and I have not had to touch the code in 8 years. Not bad for re-writing an existing program that had been under constant development for almost a year, in only three weeks, fresh out of college, about two weeks of experience programming, and having never written multi-threaded code before.
I recently had to look over my code again to turn it into a library, which took me less than a day. Well written threaded code is well factored with single-responsibility taken to the extreme. I don't like more than one piece of code modifying shared state. This lends itself well to be converted into a library, so most of my work was already done for me, but some annoying coding habits that I had were annoying.
Dedicated clusters can run through 90% of all passwords 8-16 characters in a matter of hours/days.
A 16 char password has nearly 10^32 combinations. If you had 100,000 computers, each with 100 cores that are 10ghz, it would take 10^12 seconds to go through all of the combinations, assuming it only took 1 clock cycle per comparison. That's still almost 32,000 years. Please, let me know about this magical datacenter of your's.
Your tool obviously makes many assumptions, like the password is composed of words or common patterns.
but it's trivial to crack anything less than 16 characters long
A random 15 char password would take 8.6 billion years on average assuming 1 trillion combos per second. I'm not sure "trivial" is the correct word.
You've got to love their marketing
It’s dedicated symmetrical fiber so speeds never change.
150 Mbps Dedicated Symmetrical $49.99/m
Recommended for
Web hosting
Online gaming
Heavy data transfer
Cloud computing
Webinar hosting
Extremely large online backups
Their network policy is nice to
The Company does not favor or inhibit lawful applications or classes of applications.
The Company does not knowingly and intentionally block, impair, degrade or delay the traffic on its network
The Company does not use or demand “pay-for-priority” or similar arrangements that directly or indirectly favor some traffic over other traffic.
The Company does not prioritize its own content, application, services, or devices, or those of its affiliates.
The Company does not charge edge service providers of content, applications, services and/or devices a fee simply for transporting traffic between the edge service provider and its customers.
Forgot to add why anti-bufferbloat AQMs help with link utilization. They help reduce the "thundering herd" caused by dumb tail-drop FIFO buffers that cause global TCP synchronization. If you look at a normal FIFO based link with lots of flows, the typically max out a little over 80% utilization as latency, jitter, and loss skyrocket. Constant TCP streams swinging up and down cause bursts of backoffs, causing the link to violently change from over-utilized to under-utilized very quickly. AQMs tend to have an elastic queue that works more like a head-drop, biased toward dropping packets of the heaviest flows in that instant.
This allows links to reclaim a lot of that left over 20% while stabilizing packet quality at the same time.
Using modern stateless configureless buffer management algorithms, you can have low latency, low loss, low jitter, and a mostly even distribution of bandwidth. High latency is caused by bufferbloat. Fix the bloat, fix all of the issues you mentioned, but with out of the box simplicity near-zero-configuration(set your bandwidth).
Some interesting statistics that I read about research on bufferbloat is that a very small percentage of flows are "hogs" are any given instant. They tested link rates from 133Mb/s all the way up to 10Gb/s, and they all had the same numbers. Even though they all had hundreds of thousands of active flows, at any given instant, only 100 flows had at least one packet in the link's buffer, and only 10 flows had 2 or more packets in the buffer. This means that you only need to track about 100 "states" of data, regardless the link rate or saturation.
Many fair queuing algorithms have taken advantage of this and just create hash buckets. There are only about 100 states in the buffer at any given time, meaning if you have something like 1024 buckets, the chance of any two network flows colliding is relatively low, but not zero. Another algorithm extended this to include "ways", where each bucket can have up to 8 flows in it, but round robins them. Turns out that adding these few "ways" resulted in zero collisions going into millions of states over a relatively slow congested link.
This all means a link can 100% isolate an infinite number of flows over a link while only using a small amount of fixed memory. Next advancement. Most of the time when a packet enters the buffer, it quickly leaves it. When a packet comes into the buffer, it gets shoved into a bucket+way. If this bucket+way was empty, this packet gets prioritized over all other non-new packets. Because 99.9999% of the time there are zero packets in the buffer for a given flow, this allows the non-hog traffic to get immediately scheduled.
If a data flow suddenly starts to become a hog, that means when the next packet arrives, there will already be an existing packet in the bucket+way, meaning that packet does not get prioritized and instead back-logs. But remember, this situation only applies to about 10 flows at any given instant. All of this means that 99.9999% of all packets immediately dequeue with near zero latency. The "hogs" get their additional packets delayed as they start to backlog, and if the link is too saturated, eventfully the packet is dropped. When this happens, the sender backs off and they are no longer a hog.
Turns out that doing it this way actually results in better link utilization. You can run the link to something like 99% utilization while still maintaining fractional millisecond latencies, and average utilization is higher. win-win-win. Zero downsides other than increased CPU usage. Right now they are able to run these algorithms on standard x86 routers/firewalls almost into the 40Gb range, but are hoping future optimizations to network stacks will allow higher. Assuming these algorithms get well tested, they will started to get implemented in hardware. DOCSIS 3.1 actually makes use of RED by default, which is a non-fair queue FIFO anti-bufferbloat AQM. RED is Codel-like but is friendly to Cisco ASICS.
Not mine. ToS I signed says they're net neutral and do absolutely no shaping or QoS. Not only does it say they do not do this, but promise not to. Enterprise and residential users all get the same "priority". They tried QoS in the past, but it has too many coner cases, making customer unhappy, which increased support costs. It was cheaper just to purchase more bandwidth to guarantee no congestion than to mess with shaping or QoS.
I don't do any QoS and I don't have any issues with latency during link saturation. You're complicating the problem because you now need to define all of the rules needed to match your classes of traffic. Using a modern Fair Queuing AQM, you can maintain low latency, jitter, and loss for VoIP while allowing Torrent to saturate your connection with virtually zero configuration. Look up Codel, fqCodel, RED, fqRED, or Cake.
Implementation differences of the algorithms can cause differences in the results, but I am currently maintaining a sub 1ms jitter 24/7. 1.2ms ping with 0.2ms std-dev to be more precise. Even during a 1Gb/s DOS against my prior 100Mb connection, my ping never went above 30ms because my ISP also uses an AQM.
Fair Queuing AQMs can change the order of packets, but they do not do any inspection other than hashing L3/L4 for hash table distribution purposes. Because of this, I would not go so far to say what you can or cannot do, as long as it is "fair" and agnostic.
that taught you is the experience of trying to program your actual device
Some people don't need to physically try to gain experience. There is actually a small subset of the population that learns by thinking about a situation. They are good at creating accurate mental models, allowing them to not until gain deep understanding of programming, but to learn from mistakes they have only made in their head, where they can make mistakes as fast as they can think, allowing them to progress much faster.
Just make up numbers like everyone else does. Statistically, a single interruption like email notification or IM popping up, regardless if you read it, can set you back 15-30 minutes. With such common interruptions being several factors greater than the resolution of time trying to be recorded, and for something as subjective as "how much time will it take to get back on track", you may as well make up numbers.
If I've spent 1 hour thinking about a hard issue, and some other project comes a long as is all like "zomg, this needs to be fixed NOAW!", even if it takes me 5 minutes, they're getting charged that hour I just spent on the other project. Why should the other project have to pay for interruptions making their code more inefficient to create?
2) ARM is, or rather, was, not afraid to put efficiency above complete and total backward compatibility
They were only "highly efficient" because they were not high performance. They've tried to make CPUs as powerful as x86 cores, but they consumed much more power and still quite weaker. This has been their weakness in the datacenter. All of the power savings is lost to needing more cores and systems. Great embedded type systems, or possibly low end desktops, but horrible for most workloads for high-end servers.
2/3rds of knowledge is not factual, it is context sensitive, it is nuanced in a way that human language cannot communicate. Many in psychology actually use apprenticeships as an example of the best way to transfer knowledge this knowledge, lots of hands-on experience watching a master at work.
One of the most highly acclaimed books on Software Architecture started the book saying, if you have to read this or any other book to become the required master at software design to be an Architect, you will never be a good architect. His recommendation was to get your money back for the book.
I don't read books to gain knowledge, that is stupid when you can google almost all knowledge, I read them to learn to think differently. One book so eloquently put it, you will never be a master as programming if you listen to others, even them. They went on to say that even if another master at programming tells you to NEVER do something, if you listen, you will never become a master. You need to be able to make your own decisions. Masters follow their intuition, which supersedes all forms of knowledge. You can't learn intuition from a book.
I've started to use the phrase "wrong for the right reasons" more. The kinds of issues I work on are in their nature unable to be empirically measured or reproducible, yet I can fix them. Most of these issues I trivially know where to look, and I can spend hours trying to explain my logic to another person that I consider very very smart. Why is your software running slow when you try to use every form of profiling and unable to find a hot path? Or an issue that only occurs once in a great while and does not happen when you have trace or debug code enabled? This is the kind of stuff I live for.
Numerous times I have had people show me how their code runs fast, they have micro and macro benchmarked the code, but I tell them it will run slowly. All goes well in production for a while until a tipping point is hit, then suddenly it comes crashing down. I make my changes and everything is running well again. Even when they look at my changes and I try to tell them why I made each change, they still cannot fully grasp why my version works so much better. And these are very knowledgeable smart people.
I do not consider myself very knowledgeable or very smart, in the normal sense of the word at least, but I seem to have a very strong intuition about designing, debugging, and optimizing. Never ever in my life have I ever had to try at programming. It's always been a natural extension of the way I think.
Performance metrics have their limits. They can tell you if someone was done, but not done well. I have hugely complex projects that have been handling feature creep for years, the number of bugs can be counted on one hand. Other people have simple project littered with bugs. Their metrics look better because they're "getting more done", lots of bugs to fix.
One of my managers, in his 20+ years of being in engineering, told me by all metrics, I am the slowest, but by results, I am the fastest.
66% of knowledge is not transferable via communications of any form, which is why hiring to 3rd parties rarely works, because domain knowledge and requirements cannot be properly conveyed via humans, not matter how hard they try.. 90% of what can be communicated is tonal or body language. 10% of 33% is 3.3%. Your mentoring is only 3.3% transferable. Grats.
A moron in a hurry makes mistakes. We've all been there, and it will happen again. Where we should not make mistakes is when doing something of high importance where you have time and you need to research to make sure you do it correctly. When I have an issue that requires more time thinking than coding, I almost never make mistakes, and especially not obvious mistakes.
My last potential bug was when I was assigning values in a struct. While I made sure the order of the memory locations being assigned were thread-safe, I only realized later that because the struct was larger than 8 bytes(on a 64bit system), the values in the struct would require two writes to fully copy the data. This could have caused a torn read. None of the other programmers reviewing my code noticed this glaring issue.
In this situation I to was a moron in a hurry. Luckily, when I read code, I think about what it compiles down into. Something about this code was making a voice in my mind say something was wrong. I seem to have a strong intuition, I always have, even when I first started coding. If I wasn't told to completely write an 8 week project in 1 week, I probably would not have submitted my code for review prior to noticing such a horrible bug.
wrong vote. sorry
Most have been spotty articles over the years, but a recent one that I have on hand is this: http://www.tomshardware.com/ne...
ZFS is only bad performance for low end system. Throw 32GiB+ of memory and quad core or more at it and it's faster than nearly all other filesystems out there. It scales.
1/1000 chance seems low until you have 1mil numbers. Then you have 1,000 cards that work during that one hour. Of course you won't know which ones until you "try" them, however that works.
One of my cousins was worried about her children walking to school a few blocks. My other cousin did a bit of digging and found out only about 5 children are abducted per year in our state, nearly all of them are the parents, and the one here or there are close friends of the family. There has not been a kidnapping by a stranger in many years.
We get flash flood warnings before the weather hits. Saw a blob of red about 1/4 the size of the state, figured something was going to happen. About 4 hours before the storm got here, flash flood warnings went out.
KE scales with the square of the exhaust, but the amount of KE required scales N^2, so the squaring cancels out and you're left with "net-work done scales linearly with the exhaust velocity and logarithmically with the mass of the propellant."
That's won't be true for very long. Several cheap high density non-wearing storage technologies are being worked on to be made commercial. Most are fast as dram and on-volatile, but some are even faster than dram, as fast as L1 cache SRAM, and about 4x the density while being about 1000x more power efficient. Much of this tech is already in limited commercial use and quickly getting cheaper and higher yields.