Many a pundit proclaimed the death of Apple at removing the absolutely essential floppy drive.
The people freaking out were mostly people who hadn't lost hours of work to yet another floppy disk failure. Everyone who did wondered why it took so long. But IMO, Bluetooth is the floppy disc of today, though, not the mini plug. It is barely even usable on iOS, and fails with alarming regularity in ways that require rebooting the phone, power cycling your automobile, or other seriously problematic workarounds.
I'd wager that most people connecting an iPhone to speakers would use either a dock (with a lightning plug in it) or bluetooth. I see many people playing music through external speakers with their iPhone, but very few of them use a 3.5mm plug to do it.
You'd be wrong on at least the first part. I don't know of anyone who uses a dock at all. Even back when Apple gave them away for free, most people threw them in a drawer and never used them.:-)
Honestly, I think the main benefit of those alerts is to freak out the people driving the car, making them think that they're about to be spotted, thus increasing the likelihood of them leaving the kid on the side of the road.
Thanks for the heads up. I made a mass change to the DNS servers for all my domains recently to remove two old DNS server IPs as I phase out my old ISP, and I forgot that two of my domains are hosted by DreamHost/CloudFlare when I did the mass change. That wouldn't have been a big deal, except that when I set up CloudFlare, I foolishly disabled those two domains on my main DNS server. As a result, when I pointed all the WhoIS records at my own DNS server, it didn't respond at all.:-/
I've reenabled the domains on my own DNS servers, and my home server is now responding for the site until the domain record changes bubble up to the root servers and CloudFlare/DreamHost takes over.
eg. Updating code to to use strncpy() instead of strcpy().
I hope you meant strlcpy. The strncpy function is actually quite dangerous because it doesn't guarantee that the result will be null-terminated.
It's going to be a lot of work to adapt a large C program to do that. If you're using a string class which defines operator=() for string copy then you change a few lines of code, job done.
Only because C++ strings are inherently massively complex behemoths. Try working with them on an Arduino and you'll quickly find yourself cursing at yourself for ever considering using C++.:-)
Buffer/stack overflows, type mismatches, null pointer errors and numerous other classes of programming bug that are ridiculously common in C code should all have died out years ago...
What you're missing here is the huge amount of technical debt that hurts C's reputation—some of it fairly, some unfairly.
The overwhelming majority of buffer overflows are caused not by arrays, but rather by string handling. More specifically, they're caused by using legacy string functions like strcat, strcpy, and sprintf instead of modern alternatives like strlcat, strlcpy, and asprintf. Those modern replacements date back to the late 1990s. And there are ways of making C code trigger exceptions on integer overflow/underflow that can significantly reduce the likelihood of other types of buffer overflows.
However, there's also a metric f**kton of code written in C that was written before those modern functions existed, and chances are if you write new software today, you're going to link against a lot of it. If you write new code in C today without using any existing libraries, your code will be much more secure than if you wrote that same code twenty years ago. However, C's reputation is tarnished in large part by the existence of so much preexisting bad code.
The same is true for other languages. For an example, you need only consider how frequently PHP software is involved in SQL injection attacks. It isn't because PHP doesn't have APIs that make it easy to be immune to SQL injection, but rather because so much PHP code was written before those APIs existed. I'm sure if you picked literally any programming language out there, you could come up with some similar bit of technical debt that results in lots of bad code. The problem is that languages don't start out being perfect. They evolve over time as folks figure out their flaws. And until they do, you end up with lots of code written that depends on those flaws, making it hard to ever truly fix them.
And as much as I hate to say this, the one thing that can combat that is regular breakage of backwards compatibility. When you realize that something is wrong with a language that is likely to cause serious security problems, break it quickly and completely. PHP should have killed the original mysql API back in PHP 5.0 completely, with no backwards compatibility. Lots of folks would have wailed and gnashed their teeth, but they would have reworked their code to use mysqli or PDO back in 2004, and countless exploits wouldn't have happened over the twelve years that it took before they finally killed it in PHP 7.
Also, by killing backwards compatibility for security-flawed APIs, you ensure that nobody writes new code using them, and you pretty much guarantee that anyone coming to the language for the first time will learn to do things the right way instead of accidentally learning it the old way.
BTW, I say this as somebody who finally got around to fixing bits of my own code that still used the old PHP mysql API earlier this year. PHP 7 was a forcing function. I knew I should have ripped out that code years ago, but the reality is that it is hard to justify fixing code that appears to be working. But as soon as I was forced to choose between the performance improvements promised by PHP 7 and that legacy code, suddenly it was worth updating the code.
Similarly, the C library developers should have made strcpy/strcat/sprintf issue a warning immediately, and should have removed them entirely by about the turn of the century. Shortly thereafter, they should have done the same for strncpy and strncat. We'd all be better off had they done so, as it would have provided the forcing function needed to get people to rip out all that old code and replace it with something more robust. Instead, those fundamentally dangerous functions still exist and code using them still compiles to this day. And this is one big reason why we still have so much bad C code out there.
A better test might be to provide the code and ask what's wrong or right about it.
Yes, so long as you clearly point out up front that the code was written specifically to be wrong. Otherwise, you run the risk of the interviewee being afraid that either A. the piece of code is an accurate reflection of the sorts of nightmares that he/she will have to deal with if he/she goes to work for that company or B. the piece of code was written by the interviewer, who might get offended if he/she points out the serious flaws in it.
But yes, if asked correctly, those sorts of questions are useful diagnostic tools.
And you have a crapload of incompetent people making design-decisions that goes against what the senior people advice.. just because "It was easier to get the feature done in this sprint" and with total disregard to what the final goal is....
Lord knows I've occasionally had to do things the expedient way to get something to ship on time, but I've always tried to at least file a bug to remind me to fix it right eventually. The problem isn't that people cut corners to hit a deadline. The problem was that last word in your quote marks: sprint.
IMO, the damage caused by Scrum is insidious. When you have short sprints, programmers mostly get to focus on fixing low-hanging fruit as quickly as they can. They can't focus on getting the architecture right, because if they do, they don't get to close that bug, and get in trouble for not being able to close out the sprint. As a result, that "fix me" bug never gets fixed because nobody is willing to touch any bug whose fix would take longer than a single sprint just to get back into a buildable state by the time they work their way through the ten layers of hacks.
And the longer a piece of software goes without taking the time to get the architecture right, the worse the code gets. And one day, you look at it and realize that you have a steaming pile of crap that needs to be thrown out and rewritten. And you rewrite it, and everyone complains because the resulting software does a tenth of what the previous version did. And then they file bugs to add those features, and like before, the features get hacked into the app in ways that can be done quickly, mostly by new programmers who don't remember why the previous design failed. Rinse and repeat. All the while, nothing ever actually improves.
That's not to say that regular milestones and regular releases aren't a good idea, but they have to be used sensibly. There's no reason for anything shorter than a monthly release cycle, and if you use branches correctly, there's no reason that features shouldn't be targeted for releases two, three, even six months out, depending on the complexity of the feature.
More to the point, the entire notion of tracking progress using sprints is just silly, because progress on any complex task comes in spurts. It isn't a continuous process. Suddenly, something starts working that didn't work before, and you've made progress. Any system that tries to enforce some sort of stepwise improvement towards a goal is doomed from the very beginning, because it is fundamentally mismatched with how actual development works. Writing software isn't some assembly line where each step takes a fixed amount of time. It is an iterative process with lots of backtracking and rethinking when you recognize that some aspect of the architecture isn't going to work. And that just doesn't mesh with the notion of sprints at a fairly fundamental level, IMO.
More significantly, the very foundation of Scrum—the notion that you cannot have the complete picture of what your customers want—is fundamentally antithetical to good software design. I'm not saying that you have to know every feature that will ever be added to a piece of software, but if you don't have a fairly complete picture of the endgame from the very beginning, you will invariably under-design the core of your technology in ways that make it not sufficiently extensible. And later, when you realize that the basic design falls short, Scrum then pretty much forces you to create a pile of small hacks on top of that to try to make the bad architecture "work well enough", because doing it right would take way longer than a two-week sprint.
I've seen too many projects fail horribly because of Scrum. And before anyone says, "that's because they weren't doing it right," I would counter by saying that lawn darts aren't dangerous if you play with them correctly. They still got banned because too many people got hurt. If a software design methodology is so frequen
No! In C it is trivial to create a buffer overrun error/vulnerability. A Java program on a JVM compiled from C would require careful coding to create a buffer overrun.
On the other hand, a buffer overflow in your C code affects only your app, whereas a buffer overflow in Java's C code probably affects thousands of Java apps, and won't necessarily be triggered by any erroneous usage pattern in your Java code.
And with C code, buffer overflows are almost invariably caused by the use of flawed early string APIs that have long since been replaced by better APIs. Good C programmers shouldn't be using those functions in new code, and should routinely rip them out when they see them. As a result, C buffer overflows are becoming less common over time. And use-after-free bugs are possible in any language that doesn't use a garbage collector (which brings a whole different set of problems).
So when it comes to buffer overflows, assuming your programmers are good at the language they're using, new code in a language that runs atop a large C-based runtime is likely to be more insecure than code written natively in C, because most of the buffer overflows are likely to be in libraries on which your code depends, rather than in new code, and the bigger the pile of existing code, the more likely it is to contain serious security holes, statistically speaking.
That's the pendulum swinging way too far the other direction. When you go down that path, the result tends to be Duke Nukem Forever. What you need are milestones and target deadlines to hit those milestones. And when you miss one, you need to reevaluate your future milestones as needed so that you can construct a more realistic schedule.
You also need to make sure that the reason for missing the schedule was really that the deadline was unrealistic, rather than because you went off on some crazy tangent. And if you find your team going off on tangents frequently, you need to rein them in.
Same here, and for the same reason. And I also disabled the Amber Alert on my weather radio for the same reason.
Any automated system like this needs to be a heck of a lot smarter about alerts during hours when most people are normally sleeping. An Amber Alert might be a life-or-death emergency for the kidnapped kid, but it is not a life-or-death emergency for people who are in bed asleep. I mean, it isn't as though someone is going to hear that alarm and immediately jump out of bed, get in his or her car, and start driving around looking in driveways for the suspect's vehicle....
Worse, many people have to drive late in the evenings, which means those alerts going off early in the morning can actually put lives in danger that were not in danger previously by disrupting people's sleep in ways that puts them at elevated risk of getting into an automobile accident. That makes this feature of cell phones a very dangerous tool to activate overnight. After the third early-morning wakeup in a row from a combination of two Amber Alerts and one telemarketer phone call, I turned Amber alerts off everywhere. So any good that they could have done by me knowing about them went out the window because they were too much of a nuisance.
IMO, cell phones should be aware of whether the device is in your house charging or is actually in use, and for any alert that does not constitute an immediate danger to the phone's owner, should wait to sound the Amber Alert alarm until the user picks up the phone. After all, Amber Alerts, when delivered to people who are outdoors, in their cars, or on their way out of the house is clearly useful, but for everyone else, they're a nuisance with essentially zero chance of helping anyone.
I was in the middle of debugging a problem caused by Comcast switching from non-static IPv6 addresses to static IPv6 addresses (causing me to get a new set of IPv6 addresses and breaking my in-home DNS because my Airport Extreme was looking for my DNS servers at the old address), so I noticed the Netflix outage, but I also noticed that I was unable to reach Google.com at the same time. I didn't bother to use traceroute to track down the problem because it went away by the time I finished disabling the AAAA records for all my domains....
Then I read this story, and sure enough, Google showed a huge spike in outage reports at exactly the same time as Netflix. Unless Netflix uses the Google cloud for hosting (AFAIK, they use AWS, not Google), I'd imagine that this outage involved some sort of Akamai DNS problem or network routing problem or something else not specific to Netflix.
They typically replace bones only when they are so completely destroyed that there's no hope of repairing them surgically, where the only options are grafts, transplants, other forms of bone replacement, metal plates, or amputation. I would assume that this would be similar, but less problematic than those other approaches.
Yes. This. A thousand times this. And when you try to turn it off, half the time, you accidentally press both the power and volume buttons, and the phone ignores it. Apple doesn't design for end users. They actually design for their own designers and engineers.
The last phone that was actually designed for end users was the 3GS. Since then:
4 Series was covered with unnecessary glass whose only purpose was to look pretty and then break.
5 Series moved the headphone jack to the wrong end of the phone, making it essentially impossible to build a holster that allows access to both the headphone jack and the power cord, to save space inside the device.
6 Series had that design flaw *plus* putting the power button in a defective position, presumably for some engineering-centric reason.
7 Series has that design flaw plus the headphone jack nightmare.
What's next? Buttons so perfectly smooth that you can't find them by feel?
You might get an email, but that just tells you that they think it will be delivered that day, not that it will. Besides, what are you going to do, bring a chair to the utility room and camp out waiting for them to deliver a package? Even if you check a few times on that day, you still won't see it for three or four hours, and that's still bad.
They don't need planes for the vast majority of their deliveries. Amazon has distribution centers in 21 states, within 20 minutes of something like 30% of the population, and within plausible single-day delivery range of probably the majority of the population. So for products that are frequently ordered (and thus are stocked at every depot), they can deliver to almost everyone on the same day by truck, or rent a few small warehouses in a few places and deliver the next day to probably 80–90% of the U.S. population.
Sure, they'll still rely on UPS/FedEx/OnTrac for deliveries that involve distribution centers in other parts of the country, or for deliveries out into the boonies, but that makes up only a small percentage of their deliveries. And for the ones that don't require all of that, there's no real advantage to using a third-party trucking service over doing it in-house.
The "free two day shipping" I get from Prime is "two day by 8PM". Do you know your mailman delivers as late as 8PM? I know they don't here, and neither does UPS or FedEx.
As I understand it, you'll get packages at 8 if you're near a depot, if you're in a city with lots of businesses, or if your calendar says "December".
Even in your area, they probably deliver things late around the holidays. There's a period around Christmas where the package delivery services hire lots of extra temp employees to handle the extra load, and the delivery hours tend to get extended as a result. I think I even remember seeing one of the carriers in my neighborhood after 8 on occasion.
Also, if you're close to a FedEx or UPS depot, they'll do runs even later. Their depots are both within half a mile of the edge of my neighborhood, so every FedEx and UPS truck in the South Bay literally comes around the back side of my neighborhood when they get off the freeway an exit early to avoid the last two miles of parking lot on the 101.
As a result, I routinely see FedEx and UPS out at six or seven at night making their rounds as they work their way back to the depot at the end of the day, and I've seen multiple trucks doing deliveries here—presumably because they know that they can just toss our packages onto pretty much any truck that goes out that day, and it will be close enough to their route to not be a problem.:-)
Finally, if you have a lot of businesses nearby, they'll deliver your packages after hours. They have to get all of their business deliveries finished by 5:00 (or maybe 4:00, I forget), which means that home deliveries usually happen either early in the morning or in the evening.
I keep having trouble with carriers leaving packages on Saturday and not bothering to ring the doorbell, then going out to church Sunday morning and finding them. I guess that because no other houses in my neighborhood have a doorbell there, they don't bother to look.
The irony, of course, is that package carriers are the main reason I installed a doorbell on that door in the first place.
They both tend to leave random packages on my porch that don't belong to me, as does OnTrac (the other shipper that Amazon seems to use here). Basically, my neighborhood doesn't have consecutive numbering, thanks to me being on a section of street that was added between two existing sections of street, so every time any of the carriers gets a new driver, I end up with packages for the house with a number one below mine, which is approximately half a mile away.
When they do this, it often takes multiple calls over multiple days to get the package removed. One time I got lucky and was able to chase down another FedEx driver who happened to drive by just as I got cut off while on hold with FedEx to call them to pick up a perishable overnight package of food, but the median redelivery time is at least two or three days.
Thus far, they haven't lost any of my packages yet, which could be because the house number below mine is at the end of the road, or maybe it is just just lucky timing. That said, now that I'm employed at a company big enough to have its own shipping and receiving department again, I should really go back to getting all my packages at work. It is just a lot more reliable, in my experience.:-)
Only for an hour, though I guess you could send a new blocking request every 45 minutes.
It would also let me block those idiots who keep trying to sign in to my servers via SSH. You'd think that when they send the original request (for authentication-free login) and the server says that it only accepts private key authentication, they wouldn't send thousands of password-based login attempts, but apparently the people who write those bots don't understand the SSH protocol very well, or else they just like wasting my bandwidth.
And I do periodically block them with filtering rules manually when I notice them, but I don't have time to scan the logs constantly, and they shift IPs often enough to make that problematic. But if I could make it so that the first password-based auth from an IP caused their attacks to immediately get blocked at their own edge router for an hour, it would be worth writing a log scanner.
Even better, ISPs could monitor their networks for those packets, and if a customer keeps getting blocked, they could contact the customer.
Actually, now that I think about it, I did forget to mention one small bit of the protocol. Each router that passes on the original request should immediately ACK the request to the previous router so that the previous router knows that it does not need to handle the blocking itself. It should then sent it towards the attacker's IP, and if it does not get an ACK from any router that's closer to the attacker in a timely manner, it should handle the blocking request itself and send back a confirmation request to the original IP address. It should then presumably reject any blocking confirmation requests that come later from closer to the attacker's IP, because they are redundant at that point.
This ensures that only the last router that supports blocking sends a confirmation request to the original server. Otherwise, you could cause a huge amplification attack by causing every hop in the route to ask the original server for confirmation.:-)
There's still a risk of abuse if somebody is able to inject and sniff arbitrary packets between the user and the server by being able to receive the confirmation request and respond to it, but if they can do that, they can also inject RST packets, so I'm not convinced that's an interesting edge case to worry about.
Except that what I described is carefully designed to make abuse almost impossible. Any fake blocks are removed almost immediately, and unless the server is actively being DDoSed, assuming it supports the protocol, such removal causes at most one additional packet to get sent in each direction, which means there's no amplification if the server supports the protocol, ignoring situations where packet loss causes a retry.
If the server doesn't support the protocol, there's typically only a 2x amplification (one confirmation request + 1 ping packet). That's a slight amplification, but nothing to write home about.
And the only situation where the block actually stays put is if the server is under DDoS, which is exactly when you would want it to stay put. In that case, a request to block an IP results in getting up to five packets back, but then that IP's traffic never reaches your server for a period of at least an hour (or longer if your server sends out a new packet to extend the block), which should be a huge net win.
But if you see something that I'm missing, feel free to suggest a better design that protects against additional forms of abuse.
I always just skip straight to the one-star reviews, and judge a product by how many people hate it and why, under the assumption that either their problems will be relevant to me or they won't, and if none of them are, then the product is probably fine.
Slashdot Mirror
The people freaking out were mostly people who hadn't lost hours of work to yet another floppy disk failure. Everyone who did wondered why it took so long. But IMO, Bluetooth is the floppy disc of today, though, not the mini plug. It is barely even usable on iOS, and fails with alarming regularity in ways that require rebooting the phone, power cycling your automobile, or other seriously problematic workarounds.
You'd be wrong on at least the first part. I don't know of anyone who uses a dock at all. Even back when Apple gave them away for free, most people threw them in a drawer and never used them. :-)
Honestly, I think the main benefit of those alerts is to freak out the people driving the car, making them think that they're about to be spotted, thus increasing the likelihood of them leaving the kid on the side of the road.
Thanks for the heads up. I made a mass change to the DNS servers for all my domains recently to remove two old DNS server IPs as I phase out my old ISP, and I forgot that two of my domains are hosted by DreamHost/CloudFlare when I did the mass change. That wouldn't have been a big deal, except that when I set up CloudFlare, I foolishly disabled those two domains on my main DNS server. As a result, when I pointed all the WhoIS records at my own DNS server, it didn't respond at all. :-/
I've reenabled the domains on my own DNS servers, and my home server is now responding for the site until the domain record changes bubble up to the root servers and CloudFlare/DreamHost takes over.
Ah, the joys of DNS.
I hope you meant strlcpy. The strncpy function is actually quite dangerous because it doesn't guarantee that the result will be null-terminated.
Only because C++ strings are inherently massively complex behemoths. Try working with them on an Arduino and you'll quickly find yourself cursing at yourself for ever considering using C++. :-)
What you're missing here is the huge amount of technical debt that hurts C's reputation—some of it fairly, some unfairly.
The overwhelming majority of buffer overflows are caused not by arrays, but rather by string handling. More specifically, they're caused by using legacy string functions like strcat, strcpy, and sprintf instead of modern alternatives like strlcat, strlcpy, and asprintf. Those modern replacements date back to the late 1990s. And there are ways of making C code trigger exceptions on integer overflow/underflow that can significantly reduce the likelihood of other types of buffer overflows.
However, there's also a metric f**kton of code written in C that was written before those modern functions existed, and chances are if you write new software today, you're going to link against a lot of it. If you write new code in C today without using any existing libraries, your code will be much more secure than if you wrote that same code twenty years ago. However, C's reputation is tarnished in large part by the existence of so much preexisting bad code.
The same is true for other languages. For an example, you need only consider how frequently PHP software is involved in SQL injection attacks. It isn't because PHP doesn't have APIs that make it easy to be immune to SQL injection, but rather because so much PHP code was written before those APIs existed. I'm sure if you picked literally any programming language out there, you could come up with some similar bit of technical debt that results in lots of bad code. The problem is that languages don't start out being perfect. They evolve over time as folks figure out their flaws. And until they do, you end up with lots of code written that depends on those flaws, making it hard to ever truly fix them.
And as much as I hate to say this, the one thing that can combat that is regular breakage of backwards compatibility. When you realize that something is wrong with a language that is likely to cause serious security problems, break it quickly and completely. PHP should have killed the original mysql API back in PHP 5.0 completely, with no backwards compatibility. Lots of folks would have wailed and gnashed their teeth, but they would have reworked their code to use mysqli or PDO back in 2004, and countless exploits wouldn't have happened over the twelve years that it took before they finally killed it in PHP 7.
Also, by killing backwards compatibility for security-flawed APIs, you ensure that nobody writes new code using them, and you pretty much guarantee that anyone coming to the language for the first time will learn to do things the right way instead of accidentally learning it the old way.
BTW, I say this as somebody who finally got around to fixing bits of my own code that still used the old PHP mysql API earlier this year. PHP 7 was a forcing function. I knew I should have ripped out that code years ago, but the reality is that it is hard to justify fixing code that appears to be working. But as soon as I was forced to choose between the performance improvements promised by PHP 7 and that legacy code, suddenly it was worth updating the code.
Similarly, the C library developers should have made strcpy/strcat/sprintf issue a warning immediately, and should have removed them entirely by about the turn of the century. Shortly thereafter, they should have done the same for strncpy and strncat. We'd all be better off had they done so, as it would have provided the forcing function needed to get people to rip out all that old code and replace it with something more robust. Instead, those fundamentally dangerous functions still exist and code using them still compiles to this day. And this is one big reason why we still have so much bad C code out there.
Yes, so long as you clearly point out up front that the code was written specifically to be wrong. Otherwise, you run the risk of the interviewee being afraid that either A. the piece of code is an accurate reflection of the sorts of nightmares that he/she will have to deal with if he/she goes to work for that company or B. the piece of code was written by the interviewer, who might get offended if he/she points out the serious flaws in it.
But yes, if asked correctly, those sorts of questions are useful diagnostic tools.
Lord knows I've occasionally had to do things the expedient way to get something to ship on time, but I've always tried to at least file a bug to remind me to fix it right eventually. The problem isn't that people cut corners to hit a deadline. The problem was that last word in your quote marks: sprint.
IMO, the damage caused by Scrum is insidious. When you have short sprints, programmers mostly get to focus on fixing low-hanging fruit as quickly as they can. They can't focus on getting the architecture right, because if they do, they don't get to close that bug, and get in trouble for not being able to close out the sprint. As a result, that "fix me" bug never gets fixed because nobody is willing to touch any bug whose fix would take longer than a single sprint just to get back into a buildable state by the time they work their way through the ten layers of hacks.
And the longer a piece of software goes without taking the time to get the architecture right, the worse the code gets. And one day, you look at it and realize that you have a steaming pile of crap that needs to be thrown out and rewritten. And you rewrite it, and everyone complains because the resulting software does a tenth of what the previous version did. And then they file bugs to add those features, and like before, the features get hacked into the app in ways that can be done quickly, mostly by new programmers who don't remember why the previous design failed. Rinse and repeat. All the while, nothing ever actually improves.
That's not to say that regular milestones and regular releases aren't a good idea, but they have to be used sensibly. There's no reason for anything shorter than a monthly release cycle, and if you use branches correctly, there's no reason that features shouldn't be targeted for releases two, three, even six months out, depending on the complexity of the feature.
More to the point, the entire notion of tracking progress using sprints is just silly, because progress on any complex task comes in spurts. It isn't a continuous process. Suddenly, something starts working that didn't work before, and you've made progress. Any system that tries to enforce some sort of stepwise improvement towards a goal is doomed from the very beginning, because it is fundamentally mismatched with how actual development works. Writing software isn't some assembly line where each step takes a fixed amount of time. It is an iterative process with lots of backtracking and rethinking when you recognize that some aspect of the architecture isn't going to work. And that just doesn't mesh with the notion of sprints at a fairly fundamental level, IMO.
More significantly, the very foundation of Scrum—the notion that you cannot have the complete picture of what your customers want—is fundamentally antithetical to good software design. I'm not saying that you have to know every feature that will ever be added to a piece of software, but if you don't have a fairly complete picture of the endgame from the very beginning, you will invariably under-design the core of your technology in ways that make it not sufficiently extensible. And later, when you realize that the basic design falls short, Scrum then pretty much forces you to create a pile of small hacks on top of that to try to make the bad architecture "work well enough", because doing it right would take way longer than a two-week sprint.
I've seen too many projects fail horribly because of Scrum. And before anyone says, "that's because they weren't doing it right," I would counter by saying that lawn darts aren't dangerous if you play with them correctly. They still got banned because too many people got hurt. If a software design methodology is so frequen
On the other hand, a buffer overflow in your C code affects only your app, whereas a buffer overflow in Java's C code probably affects thousands of Java apps, and won't necessarily be triggered by any erroneous usage pattern in your Java code.
And with C code, buffer overflows are almost invariably caused by the use of flawed early string APIs that have long since been replaced by better APIs. Good C programmers shouldn't be using those functions in new code, and should routinely rip them out when they see them. As a result, C buffer overflows are becoming less common over time. And use-after-free bugs are possible in any language that doesn't use a garbage collector (which brings a whole different set of problems).
So when it comes to buffer overflows, assuming your programmers are good at the language they're using, new code in a language that runs atop a large C-based runtime is likely to be more insecure than code written natively in C, because most of the buffer overflows are likely to be in libraries on which your code depends, rather than in new code, and the bigger the pile of existing code, the more likely it is to contain serious security holes, statistically speaking.
That's the pendulum swinging way too far the other direction. When you go down that path, the result tends to be Duke Nukem Forever. What you need are milestones and target deadlines to hit those milestones. And when you miss one, you need to reevaluate your future milestones as needed so that you can construct a more realistic schedule.
You also need to make sure that the reason for missing the schedule was really that the deadline was unrealistic, rather than because you went off on some crazy tangent. And if you find your team going off on tangents frequently, you need to rein them in.
Same here, and for the same reason. And I also disabled the Amber Alert on my weather radio for the same reason.
Any automated system like this needs to be a heck of a lot smarter about alerts during hours when most people are normally sleeping. An Amber Alert might be a life-or-death emergency for the kidnapped kid, but it is not a life-or-death emergency for people who are in bed asleep. I mean, it isn't as though someone is going to hear that alarm and immediately jump out of bed, get in his or her car, and start driving around looking in driveways for the suspect's vehicle....
Worse, many people have to drive late in the evenings, which means those alerts going off early in the morning can actually put lives in danger that were not in danger previously by disrupting people's sleep in ways that puts them at elevated risk of getting into an automobile accident. That makes this feature of cell phones a very dangerous tool to activate overnight. After the third early-morning wakeup in a row from a combination of two Amber Alerts and one telemarketer phone call, I turned Amber alerts off everywhere. So any good that they could have done by me knowing about them went out the window because they were too much of a nuisance.
IMO, cell phones should be aware of whether the device is in your house charging or is actually in use, and for any alert that does not constitute an immediate danger to the phone's owner, should wait to sound the Amber Alert alarm until the user picks up the phone. After all, Amber Alerts, when delivered to people who are outdoors, in their cars, or on their way out of the house is clearly useful, but for everyone else, they're a nuisance with essentially zero chance of helping anyone.
I was in the middle of debugging a problem caused by Comcast switching from non-static IPv6 addresses to static IPv6 addresses (causing me to get a new set of IPv6 addresses and breaking my in-home DNS because my Airport Extreme was looking for my DNS servers at the old address), so I noticed the Netflix outage, but I also noticed that I was unable to reach Google.com at the same time. I didn't bother to use traceroute to track down the problem because it went away by the time I finished disabling the AAAA records for all my domains....
Then I read this story, and sure enough, Google showed a huge spike in outage reports at exactly the same time as Netflix. Unless Netflix uses the Google cloud for hosting (AFAIK, they use AWS, not Google), I'd imagine that this outage involved some sort of Akamai DNS problem or network routing problem or something else not specific to Netflix.
They typically replace bones only when they are so completely destroyed that there's no hope of repairing them surgically, where the only options are grafts, transplants, other forms of bone replacement, metal plates, or amputation. I would assume that this would be similar, but less problematic than those other approaches.
Yes. This. A thousand times this. And when you try to turn it off, half the time, you accidentally press both the power and volume buttons, and the phone ignores it. Apple doesn't design for end users. They actually design for their own designers and engineers.
The last phone that was actually designed for end users was the 3GS. Since then:
What's next? Buttons so perfectly smooth that you can't find them by feel?
You might get an email, but that just tells you that they think it will be delivered that day, not that it will. Besides, what are you going to do, bring a chair to the utility room and camp out waiting for them to deliver a package? Even if you check a few times on that day, you still won't see it for three or four hours, and that's still bad.
They don't need planes for the vast majority of their deliveries. Amazon has distribution centers in 21 states, within 20 minutes of something like 30% of the population, and within plausible single-day delivery range of probably the majority of the population. So for products that are frequently ordered (and thus are stocked at every depot), they can deliver to almost everyone on the same day by truck, or rent a few small warehouses in a few places and deliver the next day to probably 80–90% of the U.S. population.
Sure, they'll still rely on UPS/FedEx/OnTrac for deliveries that involve distribution centers in other parts of the country, or for deliveries out into the boonies, but that makes up only a small percentage of their deliveries. And for the ones that don't require all of that, there's no real advantage to using a third-party trucking service over doing it in-house.
I have two words for you: Mastercard and VISA. They're great stocks that grow as a side effect of... pretty much everything. :-)
As I understand it, you'll get packages at 8 if you're near a depot, if you're in a city with lots of businesses, or if your calendar says "December".
Even in your area, they probably deliver things late around the holidays. There's a period around Christmas where the package delivery services hire lots of extra temp employees to handle the extra load, and the delivery hours tend to get extended as a result. I think I even remember seeing one of the carriers in my neighborhood after 8 on occasion.
Also, if you're close to a FedEx or UPS depot, they'll do runs even later. Their depots are both within half a mile of the edge of my neighborhood, so every FedEx and UPS truck in the South Bay literally comes around the back side of my neighborhood when they get off the freeway an exit early to avoid the last two miles of parking lot on the 101.
As a result, I routinely see FedEx and UPS out at six or seven at night making their rounds as they work their way back to the depot at the end of the day, and I've seen multiple trucks doing deliveries here—presumably because they know that they can just toss our packages onto pretty much any truck that goes out that day, and it will be close enough to their route to not be a problem. :-)
Finally, if you have a lot of businesses nearby, they'll deliver your packages after hours. They have to get all of their business deliveries finished by 5:00 (or maybe 4:00, I forget), which means that home deliveries usually happen either early in the morning or in the evening.
As always, YMMV.
I keep having trouble with carriers leaving packages on Saturday and not bothering to ring the doorbell, then going out to church Sunday morning and finding them. I guess that because no other houses in my neighborhood have a doorbell there, they don't bother to look.
The irony, of course, is that package carriers are the main reason I installed a doorbell on that door in the first place.
They both tend to leave random packages on my porch that don't belong to me, as does OnTrac (the other shipper that Amazon seems to use here). Basically, my neighborhood doesn't have consecutive numbering, thanks to me being on a section of street that was added between two existing sections of street, so every time any of the carriers gets a new driver, I end up with packages for the house with a number one below mine, which is approximately half a mile away.
When they do this, it often takes multiple calls over multiple days to get the package removed. One time I got lucky and was able to chase down another FedEx driver who happened to drive by just as I got cut off while on hold with FedEx to call them to pick up a perishable overnight package of food, but the median redelivery time is at least two or three days.
Thus far, they haven't lost any of my packages yet, which could be because the house number below mine is at the end of the road, or maybe it is just just lucky timing. That said, now that I'm employed at a company big enough to have its own shipping and receiving department again, I should really go back to getting all my packages at work. It is just a lot more reliable, in my experience. :-)
Only when they aren't supposed to.
Only for an hour, though I guess you could send a new blocking request every 45 minutes.
It would also let me block those idiots who keep trying to sign in to my servers via SSH. You'd think that when they send the original request (for authentication-free login) and the server says that it only accepts private key authentication, they wouldn't send thousands of password-based login attempts, but apparently the people who write those bots don't understand the SSH protocol very well, or else they just like wasting my bandwidth.
And I do periodically block them with filtering rules manually when I notice them, but I don't have time to scan the logs constantly, and they shift IPs often enough to make that problematic. But if I could make it so that the first password-based auth from an IP caused their attacks to immediately get blocked at their own edge router for an hour, it would be worth writing a log scanner.
Even better, ISPs could monitor their networks for those packets, and if a customer keeps getting blocked, they could contact the customer.
Actually, now that I think about it, I did forget to mention one small bit of the protocol. Each router that passes on the original request should immediately ACK the request to the previous router so that the previous router knows that it does not need to handle the blocking itself. It should then sent it towards the attacker's IP, and if it does not get an ACK from any router that's closer to the attacker in a timely manner, it should handle the blocking request itself and send back a confirmation request to the original IP address. It should then presumably reject any blocking confirmation requests that come later from closer to the attacker's IP, because they are redundant at that point.
This ensures that only the last router that supports blocking sends a confirmation request to the original server. Otherwise, you could cause a huge amplification attack by causing every hop in the route to ask the original server for confirmation. :-)
There's still a risk of abuse if somebody is able to inject and sniff arbitrary packets between the user and the server by being able to receive the confirmation request and respond to it, but if they can do that, they can also inject RST packets, so I'm not convinced that's an interesting edge case to worry about.
Except that what I described is carefully designed to make abuse almost impossible. Any fake blocks are removed almost immediately, and unless the server is actively being DDoSed, assuming it supports the protocol, such removal causes at most one additional packet to get sent in each direction, which means there's no amplification if the server supports the protocol, ignoring situations where packet loss causes a retry.
If the server doesn't support the protocol, there's typically only a 2x amplification (one confirmation request + 1 ping packet). That's a slight amplification, but nothing to write home about.
And the only situation where the block actually stays put is if the server is under DDoS, which is exactly when you would want it to stay put. In that case, a request to block an IP results in getting up to five packets back, but then that IP's traffic never reaches your server for a period of at least an hour (or longer if your server sends out a new packet to extend the block), which should be a huge net win.
But if you see something that I'm missing, feel free to suggest a better design that protects against additional forms of abuse.
They do when third-party cookies from ad networks get involved.
I always just skip straight to the one-star reviews, and judge a product by how many people hate it and why, under the assumption that either their problems will be relevant to me or they won't, and if none of them are, then the product is probably fine.