Most programmers are Caucasian because in general, caucasian programmers just happen to be the most qualified. This also tends to mean those programmers test what they build on themselves, which isn't a racial issue, it's a practical issue. As a "white" developer, it would be very hard to test my AI programs on a "black" face, as I'm so white marshmallows make gangster jokes.
If you want to run Linux, then run Linux, no one in their right mind is going to run Linux on top of Windows. Running Linux on top of Windows is buying a broken down shack of a house, that's falling apart, and loading it with excellent equipment and technology. If you want to use Linux, then run Linux as your base OS and run Windows in a VM, which actually makes sense, instead of trying to use an excellent OS on top of a broken, 1/2 functional bucket of crap.
No one should have the right to see what you don't want them see, it's simple, it's easy and if the government / state disagrees, they can go fuck themselves.
If my UPS / Power Filter sees any funny business in the line power, it's going to either compensate or terminate the power, effectively ending this type of attack. The only way this type of attack could work would be if the victim has no power monitoring, which is risky at best for the victim.
Any application which refuses to violate security, even to the face of a government, deserves an award. Governments have to learn they have no right to their people's communication.
All of those problems are solved by going with something like MongoDB, among other solid NoSQL or Node DB's and leveraging their power.
1) Hard coded Schemes - Tables are fixed
1) trade off data integrity vs flexibility
Arguable, but almost always it's better to have flexibility over rigid schemes. If want to add an extra field to a single record, I should be able to do so without affecting the others, this is how a mature and truly rational DB would function. Each record should have it's own fields that can be completely different and independent from the others.
2) Absolutely horrible scaling, both vertically and horizontally
2) trade off scalability vs complex on-demand aggregation/calculation
Scalability is a key feature that has to be considered in today's internet age, I shouldn't have to worry about how to grow my DB across clusters, that should happen almost automatically, which with MongoDB, it really can, if I have the servers setup. With MySQL, I'm left with a muddy, 1/2 broken, poorly support system of duct tape like fixes to get it to function, certainly something I'd never trust in production. Oddly enough just a couple weeks ago, we have an issue with Azure and their Microsoft SQL Servers where they broke scaling, which just shows how "well" SQL can handle it.
3) Garbage security across the board
3) many decent languages aren't really great at security, but nearly databases offer a wide range of security checks to make sure you're querying what you should
If you want to see security done well, look at MongoDB, it sports the best implementation I've seen, and it's my yard stick to compare all other DB's against.
4) (Generally) Slow as a snail, even for a simple query
4) not slow in my experience and certainly acceptable for 99% of applications
Load a DB with 20+ tables, with over a million total records and using the sloppy process of joins, read them back, and format them into some form of BSON / JSON for use on a frontend. If we compare MySQL or Microsoft SQL with MongoDB, it would be a joke, you'd be playing with SQL waiting for the paint to dry on the first wall of a house well I've finished the entire block. People tolerate latency because they're told to tolerate it, instead of demanding performance. Maybe you've seen a mythical unicorn in the SQL world, but I've never seen performance from a realistic DB that I would call acceptable, at least when they get reasonably big. The largest one I've worked with had over 10 Million records and querying or updating anything in it, was a joke, and I didn't design it, it was designed by a certified DBA the company employed who felt it was acceptable given it's size.
5) Forced use of Joins
5) How are you forced? select a.*, b.* from a, b where a.id=1, b.id=1;
Forced was the wrong word, that was my fault, but take 20 tables and trying and correlate all their data into a query. You can try to get around this using Views, but it's still essentially a join. Join's are so slow that even on performant SQL clusters, it's not worth it, so you end up un-normalizing data just to get any hint of speed.
6) Require over normalization to keep neat / tidy
6) again, this is a trade-off between integrity and flexibility, but if it really bugs you put your record delta in a json string.
Why not just use a DB that stores information in a rational neat format to start with?
1) Hard coded Schemes - Tables are fixed
2) Absolutely horrible scaling, both vertically and horizontally
3) Garbage security across the board
4) (Generally) Slow as a snail, even for a simple query
5) Forced use of Joins
6) Require over normalization to keep neat / tidy
I'm a full stack developer, I can and do write code in the embedded landscape with C, ASM (Several Arch's). I write back-end code with PHP, C, C#, Node.JS, Erlang, Scala, and some others. I write code in the front-end with JavaScript, Angular, React, GTK#, C#, C, GTK, and some others and I work with Databases, SQL (only when required as it's crap), MongoDB, and some node based DB's.
Part of my past job was to write and maintain a stack that included an Embedded Firmware, Database, Back-end globally distributed system, Front-end System on the Web and Desktop and I wrote a full testing framework for that system. There are defiantly full stack developers and they have a place, BUT, they're also a place for non full stack developers who specialize at a Jedi Ninja level in one area and rock it so hard, it's basically another Woodstock.
There are standards, such that you have to click allow / deny... very, very, tricky wording. If you don't know why an application wants access to X, don't allow it. I have a few pages worth of application that aren't allowed on any of my phone due to permission based issues, because they could not need access to X.
If you granted permission to read contacts during Facebook's installation on Android a few versions ago -- specifically before Android 4.1 (Jelly Bean) -- that permission also granted Facebook access to call and message logs by default. The permission structure was changed in the Android API in version 16. But Android applications could bypass this change if they were written to earlier versions of the API, so Facebook API could continue to gain access to call and SMS data by specifying an earlier Android SDK version. Google deprecated version 4.0 of the Android API in October 2017 -- the point at which the latest call metadata in Facebook user's data was found. Apple iOS has never allowed silent access to call data.
Users had to allowed access to contact data. If you don't know exactly why an application needs to have access to X, don't allowed it, flat out. They're many, many, many, application that I won't allow on my phone because they simply ask for permissions that they couldn't need access to, for a practical reason. Extending this, who uses unencrypted message application, even for SMS? This entire issue breaks down to users whom don't understand what they were doing and why they shouldn't of just clicked allow. Give Facebook a Gold Star and a high five, they exploited user stupidity.
Maybe you should read and think about what applications are asking for what permissions before you go and just click allow. Lets ignore the fact that no one should actually be using unencrypted SMS and unencrypted voice applications.
If you use a system which you know stores and harvests your data, then you can't be surprised or worried when that data gets used by other parties.
Facebook's response was correct, this wasn't breach, and just because the over liberalized media doesn't understand that, doesn't make it Facebook's problem. The only reason that Cambridge Analytica was able to grab the data is because people provided it and provided it openly without any second thought for the consequences of what they were doing at the time.
if you don't want to be tracked, then stop willfully giving your data up to everyone who wants it, otherwise you have no right to complain when it gets used against you.
This is why all your data should always be stored in an encrypted format and you should never use plaintext or insecure data providers, including email.
If you design a flawed lock, with many keys, developers will design a better lock. This problem will never be solved because there will always be groups who don't and won't allow others into their data. Even if the government passes laws requiring flawed locks, not all developers will listen. I'd rather give my device up, then allow law enforcement in, without the right to total privacy, you may as well have non at all.
If you're using email in 2018 and it's not encrypted it, stop using it, simple! The average person and especially executives, have no sense of security or secure operations. I can point to numerous companies, where even the CTO's and CSO's are widely unqualified to hold those positions, and they would and have, send non-encrypted email containing very sensitive information.
If society isn't going to grow up and start encrypting all email communication, then it's time to get rid of email.
Your entire reply sums up to: "It's hard, annoying and I'm going to cry about it"
Everything I talked about is practical and reasonable, and security is the most important first consideration in todays society. People enjoy living easy, insecure lifestyles, that are a mess of digital footprints and poor electronic habits, and it's up to people who know better to get them to stop. If your entire argument is you're going to do what you want and no one should force you to do it in a secure way, then you're part of the problem, everything I listed is reasonable and any reasonable tech company or electronic service company should strive towards and beyond it.
Everyone has the right to protect their information through encryption and no one has the right to a back door, this isn't a two sided argument,.
If you oppose encryption or data security, place all your sensitive information online, un-encrypted and see what happens, you'll quickly change your mind about encryption and data security.
I'm not entire sure as to the details of something like that, but I think it would present a massive invasion of security / privacy and even then, you would be able to monitor it using any number of apps.
Slashdot Mirror
Most programmers are Caucasian because in general, caucasian programmers just happen to be the most qualified. This also tends to mean those programmers test what they build on themselves, which isn't a racial issue, it's a practical issue. As a "white" developer, it would be very hard to test my AI programs on a "black" face, as I'm so white marshmallows make gangster jokes.
If you want to run Linux, then run Linux, no one in their right mind is going to run Linux on top of Windows. Running Linux on top of Windows is buying a broken down shack of a house, that's falling apart, and loading it with excellent equipment and technology. If you want to use Linux, then run Linux as your base OS and run Windows in a VM, which actually makes sense, instead of trying to use an excellent OS on top of a broken, 1/2 functional bucket of crap.
No one should have the right to see what you don't want them see, it's simple, it's easy and if the government / state disagrees, they can go fuck themselves.
If my UPS / Power Filter sees any funny business in the line power, it's going to either compensate or terminate the power, effectively ending this type of attack. The only way this type of attack could work would be if the victim has no power monitoring, which is risky at best for the victim.
You honestly thought it was being handled responsibly? There's a reason you never use real information on a social media account, ever.
Everyone knew Facebook was selling User Data, that was never up for debate.
Any application which refuses to violate security, even to the face of a government, deserves an award. Governments have to learn they have no right to their people's communication.
All of those problems are solved by going with something like MongoDB, among other solid NoSQL or Node DB's and leveraging their power.
1) Hard coded Schemes - Tables are fixed
1) trade off data integrity vs flexibility
Arguable, but almost always it's better to have flexibility over rigid schemes. If want to add an extra field to a single record, I should be able to do so without affecting the others, this is how a mature and truly rational DB would function. Each record should have it's own fields that can be completely different and independent from the others.
2) Absolutely horrible scaling, both vertically and horizontally
2) trade off scalability vs complex on-demand aggregation/calculation
Scalability is a key feature that has to be considered in today's internet age, I shouldn't have to worry about how to grow my DB across clusters, that should happen almost automatically, which with MongoDB, it really can, if I have the servers setup. With MySQL, I'm left with a muddy, 1/2 broken, poorly support system of duct tape like fixes to get it to function, certainly something I'd never trust in production. Oddly enough just a couple weeks ago, we have an issue with Azure and their Microsoft SQL Servers where they broke scaling, which just shows how "well" SQL can handle it.
3) Garbage security across the board
3) many decent languages aren't really great at security, but nearly databases offer a wide range of security checks to make sure you're querying what you should
If you want to see security done well, look at MongoDB, it sports the best implementation I've seen, and it's my yard stick to compare all other DB's against.
4) (Generally) Slow as a snail, even for a simple query
4) not slow in my experience and certainly acceptable for 99% of applications
Load a DB with 20+ tables, with over a million total records and using the sloppy process of joins, read them back, and format them into some form of BSON / JSON for use on a frontend. If we compare MySQL or Microsoft SQL with MongoDB, it would be a joke, you'd be playing with SQL waiting for the paint to dry on the first wall of a house well I've finished the entire block. People tolerate latency because they're told to tolerate it, instead of demanding performance. Maybe you've seen a mythical unicorn in the SQL world, but I've never seen performance from a realistic DB that I would call acceptable, at least when they get reasonably big. The largest one I've worked with had over 10 Million records and querying or updating anything in it, was a joke, and I didn't design it, it was designed by a certified DBA the company employed who felt it was acceptable given it's size.
5) Forced use of Joins
5) How are you forced? select a.*, b.* from a, b where a.id=1, b.id=1;
Forced was the wrong word, that was my fault, but take 20 tables and trying and correlate all their data into a query. You can try to get around this using Views, but it's still essentially a join. Join's are so slow that even on performant SQL clusters, it's not worth it, so you end up un-normalizing data just to get any hint of speed.
6) Require over normalization to keep neat / tidy
6) again, this is a trade-off between integrity and flexibility, but if it really bugs you put your record delta in a json string.
Why not just use a DB that stores information in a rational neat format to start with?
Some of the problems with SQL:
1) Hard coded Schemes - Tables are fixed
2) Absolutely horrible scaling, both vertically and horizontally
3) Garbage security across the board
4) (Generally) Slow as a snail, even for a simple query
5) Forced use of Joins
6) Require over normalization to keep neat / tidy
I'm a full stack developer, I can and do write code in the embedded landscape with C, ASM (Several Arch's). I write back-end code with PHP, C, C#, Node.JS, Erlang, Scala, and some others. I write code in the front-end with JavaScript, Angular, React, GTK#, C#, C, GTK, and some others and I work with Databases, SQL (only when required as it's crap), MongoDB, and some node based DB's.
Part of my past job was to write and maintain a stack that included an Embedded Firmware, Database, Back-end globally distributed system, Front-end System on the Web and Desktop and I wrote a full testing framework for that system. There are defiantly full stack developers and they have a place, BUT, they're also a place for non full stack developers who specialize at a Jedi Ninja level in one area and rock it so hard, it's basically another Woodstock.
There are standards, such that you have to click allow / deny ... very, very, tricky wording. If you don't know why an application wants access to X, don't allow it. I have a few pages worth of application that aren't allowed on any of my phone due to permission based issues, because they could not need access to X.
If you granted permission to read contacts during Facebook's installation on Android a few versions ago -- specifically before Android 4.1 (Jelly Bean) -- that permission also granted Facebook access to call and message logs by default. The permission structure was changed in the Android API in version 16. But Android applications could bypass this change if they were written to earlier versions of the API, so Facebook API could continue to gain access to call and SMS data by specifying an earlier Android SDK version. Google deprecated version 4.0 of the Android API in October 2017 -- the point at which the latest call metadata in Facebook user's data was found. Apple iOS has never allowed silent access to call data.
Users had to allowed access to contact data. If you don't know exactly why an application needs to have access to X, don't allowed it, flat out. They're many, many, many, application that I won't allow on my phone because they simply ask for permissions that they couldn't need access to, for a practical reason. Extending this, who uses unencrypted message application, even for SMS? This entire issue breaks down to users whom don't understand what they were doing and why they shouldn't of just clicked allow. Give Facebook a Gold Star and a high five, they exploited user stupidity.
Maybe you should read and think about what applications are asking for what permissions before you go and just click allow. Lets ignore the fact that no one should actually be using unencrypted SMS and unencrypted voice applications.
Fair response.
That's interesting!
LMAO That's awesome!
Why not just run Linux, the better OS, in the first place and when absolutely required (although rarely needed), run Windows Server in a VM?
If you use a system which you know stores and harvests your data, then you can't be surprised or worried when that data gets used by other parties.
Facebook's response was correct, this wasn't breach, and just because the over liberalized media doesn't understand that, doesn't make it Facebook's problem. The only reason that Cambridge Analytica was able to grab the data is because people provided it and provided it openly without any second thought for the consequences of what they were doing at the time.
if you don't want to be tracked, then stop willfully giving your data up to everyone who wants it, otherwise you have no right to complain when it gets used against you.
This is why all your data should always be stored in an encrypted format and you should never use plaintext or insecure data providers, including email.
If you design a flawed lock, with many keys, developers will design a better lock. This problem will never be solved because there will always be groups who don't and won't allow others into their data. Even if the government passes laws requiring flawed locks, not all developers will listen. I'd rather give my device up, then allow law enforcement in, without the right to total privacy, you may as well have non at all.
If you're using email in 2018 and it's not encrypted it, stop using it, simple! The average person and especially executives, have no sense of security or secure operations. I can point to numerous companies, where even the CTO's and CSO's are widely unqualified to hold those positions, and they would and have, send non-encrypted email containing very sensitive information.
If society isn't going to grow up and start encrypting all email communication, then it's time to get rid of email.
Your entire reply sums up to: "It's hard, annoying and I'm going to cry about it"
Everything I talked about is practical and reasonable, and security is the most important first consideration in todays society. People enjoy living easy, insecure lifestyles, that are a mess of digital footprints and poor electronic habits, and it's up to people who know better to get them to stop. If your entire argument is you're going to do what you want and no one should force you to do it in a secure way, then you're part of the problem, everything I listed is reasonable and any reasonable tech company or electronic service company should strive towards and beyond it.
Everyone has the right to protect their information through encryption and no one has the right to a back door, this isn't a two sided argument,.
If you oppose encryption or data security, place all your sensitive information online, un-encrypted and see what happens, you'll quickly change your mind about encryption and data security.
If Windows isn't already tuned to give you raw horse power and performance, then switch to Linux based OS.
I'm not entire sure as to the details of something like that, but I think it would present a massive invasion of security / privacy and even then, you would be able to monitor it using any number of apps.