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.

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.

I saw a ZFS benchmark comparing random read, write, read+write, and sequential read, write, and read+write of a 15k RPM RAID and 5400 RPM with 10x as much storage but just as many spindles for a fraction the price, and the 5400 RPM setup was faster once the 64GB of SSDs got warmed up.

PC-BSD is just a thin wrapper of scripts, wizards, and some decent tools over FreeBSD. You can upgrade and downgrade to/from PC-BSD/FreeBSD.

HardenedBSD was forked with the explicit idea of testing new security ideas and seeing what works, then pushing the code upstream back to FreeBSD. *BSD is not like Linux distros where they rarely work together. A lot of security ideas require some major changes that would not be feasible as a simple branch.

Ohh, you mean segfault when you read unallocated memory? Even if you could, are you planning to read all 8,589,934,592GiB of the address space? with O(n) scaling, assuming a crazy low 1 clock cycle per address, it would take you about 35 years to scan the entire 2^63 user virtual address space at 4ghz.

I am not saying ASLR is perfect, I'm just saying it's not nearly as simple as you make it out to be.

OpenBSD has an entirely different kernel at this point. Their only major commonality is starting from the same OS a long time ago.

1993 - NetBSD forks 4.3BSD
1993 - FreeBSD forks 4.4BSD
1996 - OpenBSD forks NetBSD 1.0

As much as they still shared code, they have diverged over the past 20 years.