I reboot Windows at lunch and the end of every day, and Windows still crashes a few more times during the week. It is simply unreliable.
My works machine gets rebooted about once a month and my home machine can sometimes go longer, depending on what kind of security issues are being fixed on Patch Tuesday. Font driver bug, yeah reboot now, SMB bug, nah, got a firewall, will wait a bit longer.
If Windows is crashing regularly, look at what crapware you have installed or replace the hardware.
All the GP was saying was that quantum computers are still a worthy investment for humanity at large until proven otherwise. The burden of proof is on YOU, not him. From the sounds of it, you think quantum computers are impossible, prove it, show us some logic that proves the Universe places a limit on them such that they are mostly useless.
You wind up either a dev, fighting for the scraps that are not offshored with H-1Bs. Or, you go into IT, and hope that the waves of the economy don't get you pink-slipped if the stock market hiccups
Stop looking for a job that makes you easily replaceable. Code monkeys can be replaced with other code monkeys. Don't be a code monkey. My managers don't tell me what to do, they come to me for advice.
In my perfectly unbiased opinion, the two sets of intelligent and obsessed with money are very separated. If I got to choose one trait on which to guess who will be a good programmer, it would be someone who is interested in the subject.
Intelligence isn't enough to be good, you need to be motivated and being good requires a lot of motivation. CS/Programming is very unhindered in its ability to evolve, allowing for quick changes in short time frames. Programming is one sector where maintaining status quo means you're worthless. The theory that people learn in CS is great, but many can't abstract that theory well enough to apply to new situations. Almost all new "inventions" are just rediscoveries of something already known back in 1970.
The biggest annoyance I see is too many look at issues as cookie-cutter. I've seen too many people who I consider very intelligent and have a wealth of knowledge, but see everything as a nail. They can't abstract out the minor differences and try to shoe-horn too many issues. Like a person trying to view a Tesseract as a 3D object, they over complicate issues because they over-simplify the solution. Just add an extra dimension and the problem is simple, but they instead treat each view of the Tesseract as a new problem.
It's not worth caring because there is nothing I can do. When you care about something you can't change, it just causes anxiety which hurts your health. Unless you think it's a good thing to be less healthy.
All of my $130 gaming monitors that I've purchased in the past year are 1080p. $200 is my general max for most any single part of a computer, with a bit of give for important parts. eg Maybe $220 for a CPU or $250 for 512GB SSD instead of a $180 256GB
Until some knob-head inserts an empty string into the database and breaks code that assumes empty will never happen. If something should NEVER happen, then make sure it never happens. That's the whole point of constraints in databases, forcing the business logic to at least conform to basic data model rules.
Intel integrated for you desktop and PCI passthrough your discrete GPU to your guest Windows VM while your host runs Linux. Now you can play your games in Linux.
The fact that the front end logic implements the business logic that handles password reset is a bad practice. The front end should call an internal API that has a signature like this "bool TryPasswordReset(string username, string resetCode, out userObject user)". If unccessfuly user is null, but if the try is successful, then user is a valid user object that can be passed into the change password API that looks like this "bool TryChangePasswordWithReset(UserObject user, string newPassword, string resetCode)".
This API could be unit tested to hell and back to make sure the business logic works, and it keeps the front end dev from making stupid mistakes that affect security.
Shit like resetCode being null, empty, or whitespace will throw a lovely exception that the front end dev should have checked for. Not to mention that resetCode must be a valid value.
I had a similar thing a month ago. I got an email that stated I got a password reset request. Just to test things, I logged out of Steam and logged back in. It said someone else from another IP "logged in" to my account, that was after I entered my original password. That left me confused. How could someone log in if my password was the same. I saw a reset request, but I never got an email that my password got changed.
I decided to change my password, and just to test things out I issues a password reset instead of just changing my password the normal way. I got the email saying a password reset was requested, then I changed my password and I got another email saying my password was changed.
since nothing was amiss, I assume that someone did not log into my account but only issued a password reset. This scares me. To me this indicates that the web page thought the Chinese IP address actually logged in. If I was to write a program to notify a user that an unknown IP logged into their account, I would tie that in with the authentication logic that on a successful login, an email get sent. Does this mean the Steam code that handles password resets technically calls a code path that authenticates as that user? Shitty programming is all I can say.
I can't say one way or the other for whatever you bug was, I like to do validation as much as possible in my code until there is a valid performance issue. Several times in the past few years I've had outside developers start using my code only to have their front-ends blow up with some helpful error messages. They would complain that my backend code was causing their frontend code to fail, but I explained that they were making undefined calls and my backend code was just making sure calls were being used in a way consistent with the envisioned data model.
I've gained a reputation for thoroughly checking edge cases that I am now "that guy" people go to first. This can be annoying because 95% of the time it's an issue with the frontend, but the person who made the frontend doesn't do any useful logging and lets default exception handling drop a "object null" error or whatever. Even the frontend devs come to me asking why their program is breaking. JUST PASS SOME VALID PARAMETERS! They're too used to things silently failing, leaving stuff in invalid states, but only causing errors when they attempt to use the invalid state.
My goal is that when using my code, it either works beautifully or fails spectacularly with a clear reason why. The sooner code breaks, the better. None of this code seems to work but something is in an invalid state and someone forgot the check the state. No, it goes BOOM and is never in an invalid state. All states are accounted for and how you can use something in a certain state is enforced.
A simple example is authentication. I've seen people write auth APIs where the programmer is supposed to request the user object, if found, then attempt to validate it. I don't do that. I let you pass in the auth data, and I'll pass back an immutable user object if the validation was successful. With the other way, I've seen programmers who have forget to validate the user object. oops.
Another example is SQL sprocs. Many programmers like to use internal identifiers. Yay incrementing integers, no chance of accidentally flipping around some arguments and still getting a valid response because those identities exist in more than one table./sarc Nope, UniqueIdentifiers. Virtually no chance of accidentally passing in a UUID to the wrong parameter and not getting an error. But UUIDs fragment the index more quickly... boo freaking hoo. I'll worry about it when it becomes a performance issue.
Obviously they don't unit test their failure cases, only their success cases. I've programmed many security APIs for stuff around validation and authentication, and there are many many more failure cases, but you need to test them all. My general rule of thumb is to unit test all edge cases I can think of.
The only thing more important than something working how I want it is for it to fail how I want it.
It depends on who is running those 1Gb ports. If they're a company that does not stream bulk data, then their ports will probably never be at capacity anyway. Your customers will still get 1Gb/s speeds, but only for the fractions of a second it takes to transfer their small web pages.
The company I work for only has a 2Gb connection to the Internet and hundreds of thousands of live connections at peak usage, yet our peak bandwidth is around 1.2Gb/s. Of course those 100K+, if they all had 1Gb connections could flood our connection if the data being transfers was sustained, but sustained is not a normal usage for us. All of our bandwidth is micro-bursts.
MP3 causes me physical pain in my ears for certain types of music that OGG does just fine. Feels like I have an ear ache with a bunch of pressure that eventually turns into a migraine if continued. MP3 is crap.
Windows is limited to 512 total shadow copies. Shadow copies could accidentally be lost for a number of reasons, they are not guaranteed. Microsoft has a list of things to be careful about that can influence your chance of losing a shadow copy, including block size and defragmentation, which could cause older shadow copies to get destroyed.
LVM has performance issues. Many people complaints of over 10x reduction in performance after only a few snapshots. It also only works at the block level and not the FS level, which highly limits its usefulness.
For most people ZFS could be considered a "back up" solution to a certain extent and making certain assumptions. For a large enterprise systems, never rely on a single file system. The data files should be replicated to multiple systems that use multiple file systems.
Slashdot Mirror
L2ARC for your SSD zpool
The issue being discussed is about the environment. I need a different computer/VM for each environment. The .Net 4.6 issue affects all thing .Net 4.x
I reboot Windows at lunch and the end of every day, and Windows still crashes a few more times during the week. It is simply unreliable.
My works machine gets rebooted about once a month and my home machine can sometimes go longer, depending on what kind of security issues are being fixed on Patch Tuesday. Font driver bug, yeah reboot now, SMB bug, nah, got a firewall, will wait a bit longer.
If Windows is crashing regularly, look at what crapware you have installed or replace the hardware.
The discussions can be more important and the answers.
That is in the context of changes, not bugs. Of course bugs break user space.
Find a stable version, stick with it through your project.
Which project? I have about 30 of them ranging from 10 years old to 1 month old.
All the GP was saying was that quantum computers are still a worthy investment for humanity at large until proven otherwise. The burden of proof is on YOU, not him. From the sounds of it, you think quantum computers are impossible, prove it, show us some logic that proves the Universe places a limit on them such that they are mostly useless.
You wind up either a dev, fighting for the scraps that are not offshored with H-1Bs. Or, you go into IT, and hope that the waves of the economy don't get you pink-slipped if the stock market hiccups
Stop looking for a job that makes you easily replaceable. Code monkeys can be replaced with other code monkeys. Don't be a code monkey. My managers don't tell me what to do, they come to me for advice.
In my perfectly unbiased opinion, the two sets of intelligent and obsessed with money are very separated. If I got to choose one trait on which to guess who will be a good programmer, it would be someone who is interested in the subject.
Intelligence isn't enough to be good, you need to be motivated and being good requires a lot of motivation. CS/Programming is very unhindered in its ability to evolve, allowing for quick changes in short time frames. Programming is one sector where maintaining status quo means you're worthless. The theory that people learn in CS is great, but many can't abstract that theory well enough to apply to new situations. Almost all new "inventions" are just rediscoveries of something already known back in 1970.
The biggest annoyance I see is too many look at issues as cookie-cutter. I've seen too many people who I consider very intelligent and have a wealth of knowledge, but see everything as a nail. They can't abstract out the minor differences and try to shoe-horn too many issues. Like a person trying to view a Tesseract as a 3D object, they over complicate issues because they over-simplify the solution. Just add an extra dimension and the problem is simple, but they instead treat each view of the Tesseract as a new problem.
It's not worth caring because there is nothing I can do. When you care about something you can't change, it just causes anxiety which hurts your health. Unless you think it's a good thing to be less healthy.
People who get into programming for the money are the worst programmers. We don't need more warm bodies.
All of my $130 gaming monitors that I've purchased in the past year are 1080p. $200 is my general max for most any single part of a computer, with a bit of give for important parts. eg Maybe $220 for a CPU or $250 for 512GB SSD instead of a $180 256GB
Japan has had issues in the past with toilets catching on fire. I don't think we need more of that.
Until some knob-head inserts an empty string into the database and breaks code that assumes empty will never happen. If something should NEVER happen, then make sure it never happens. That's the whole point of constraints in databases, forcing the business logic to at least conform to basic data model rules.
[ResetCode] check( [ResetCode] > '') NOT NULL
Intel integrated for you desktop and PCI passthrough your discrete GPU to your guest Windows VM while your host runs Linux. Now you can play your games in Linux.
The fact that the front end logic implements the business logic that handles password reset is a bad practice. The front end should call an internal API that has a signature like this "bool TryPasswordReset(string username, string resetCode, out userObject user)". If unccessfuly user is null, but if the try is successful, then user is a valid user object that can be passed into the change password API that looks like this "bool TryChangePasswordWithReset(UserObject user, string newPassword, string resetCode)".
This API could be unit tested to hell and back to make sure the business logic works, and it keeps the front end dev from making stupid mistakes that affect security.
Shit like resetCode being null, empty, or whitespace will throw a lovely exception that the front end dev should have checked for. Not to mention that resetCode must be a valid value.
I had a similar thing a month ago. I got an email that stated I got a password reset request. Just to test things, I logged out of Steam and logged back in. It said someone else from another IP "logged in" to my account, that was after I entered my original password. That left me confused. How could someone log in if my password was the same. I saw a reset request, but I never got an email that my password got changed.
I decided to change my password, and just to test things out I issues a password reset instead of just changing my password the normal way. I got the email saying a password reset was requested, then I changed my password and I got another email saying my password was changed.
since nothing was amiss, I assume that someone did not log into my account but only issued a password reset. This scares me. To me this indicates that the web page thought the Chinese IP address actually logged in. If I was to write a program to notify a user that an unknown IP logged into their account, I would tie that in with the authentication logic that on a successful login, an email get sent. Does this mean the Steam code that handles password resets technically calls a code path that authenticates as that user? Shitty programming is all I can say.
I can't say one way or the other for whatever you bug was, I like to do validation as much as possible in my code until there is a valid performance issue. Several times in the past few years I've had outside developers start using my code only to have their front-ends blow up with some helpful error messages. They would complain that my backend code was causing their frontend code to fail, but I explained that they were making undefined calls and my backend code was just making sure calls were being used in a way consistent with the envisioned data model.
/sarc Nope, UniqueIdentifiers. Virtually no chance of accidentally passing in a UUID to the wrong parameter and not getting an error. But UUIDs fragment the index more quickly... boo freaking hoo. I'll worry about it when it becomes a performance issue.
I've gained a reputation for thoroughly checking edge cases that I am now "that guy" people go to first. This can be annoying because 95% of the time it's an issue with the frontend, but the person who made the frontend doesn't do any useful logging and lets default exception handling drop a "object null" error or whatever. Even the frontend devs come to me asking why their program is breaking. JUST PASS SOME VALID PARAMETERS! They're too used to things silently failing, leaving stuff in invalid states, but only causing errors when they attempt to use the invalid state.
My goal is that when using my code, it either works beautifully or fails spectacularly with a clear reason why. The sooner code breaks, the better. None of this code seems to work but something is in an invalid state and someone forgot the check the state. No, it goes BOOM and is never in an invalid state. All states are accounted for and how you can use something in a certain state is enforced.
A simple example is authentication. I've seen people write auth APIs where the programmer is supposed to request the user object, if found, then attempt to validate it. I don't do that. I let you pass in the auth data, and I'll pass back an immutable user object if the validation was successful. With the other way, I've seen programmers who have forget to validate the user object. oops.
Another example is SQL sprocs. Many programmers like to use internal identifiers. Yay incrementing integers, no chance of accidentally flipping around some arguments and still getting a valid response because those identities exist in more than one table.
Obviously they don't unit test their failure cases, only their success cases. I've programmed many security APIs for stuff around validation and authentication, and there are many many more failure cases, but you need to test them all. My general rule of thumb is to unit test all edge cases I can think of.
The only thing more important than something working how I want it is for it to fail how I want it.
It depends on who is running those 1Gb ports. If they're a company that does not stream bulk data, then their ports will probably never be at capacity anyway. Your customers will still get 1Gb/s speeds, but only for the fractions of a second it takes to transfer their small web pages.
The company I work for only has a 2Gb connection to the Internet and hundreds of thousands of live connections at peak usage, yet our peak bandwidth is around 1.2Gb/s. Of course those 100K+, if they all had 1Gb connections could flood our connection if the data being transfers was sustained, but sustained is not a normal usage for us. All of our bandwidth is micro-bursts.
Some people don't realize that even business grade is statistically multiplexed and not "dedicated" in the overly strict sense of not shared.
MP3 causes me physical pain in my ears for certain types of music that OGG does just fine. Feels like I have an ear ache with a bunch of pressure that eventually turns into a migraine if continued. MP3 is crap.
Windows is limited to 512 total shadow copies. Shadow copies could accidentally be lost for a number of reasons, they are not guaranteed. Microsoft has a list of things to be careful about that can influence your chance of losing a shadow copy, including block size and defragmentation, which could cause older shadow copies to get destroyed.
LVM has performance issues. Many people complaints of over 10x reduction in performance after only a few snapshots. It also only works at the block level and not the FS level, which highly limits its usefulness.
For most people ZFS could be considered a "back up" solution to a certain extent and making certain assumptions. For a large enterprise systems, never rely on a single file system. The data files should be replicated to multiple systems that use multiple file systems.