When you are a customer at Amazon.com, you are very unlikely to lose any money, even if someone hijacks your account. Your risk is extremely low.
When you are a customer with Amazon Web Services, *any* breach or security is exceedingly dangerous and can be severely expensive. Your risk is low because security tends to be high. Any sign of a potential security flaw should be taken very seriously.
He's talking about Amazon Web Services and Google Cloud Platform.
There is a very small amount of overlap between Amazon Web Services support/accounts and Amazon.com support/accounts, but it is not entirely nonexistant (It is possible to be forwarded to the customer service team for one, after much cajoling / convincing that the other team exists at all, having first called the support team for the other. There is more overlap for Amazon Marketplace Web Services vs Amazon.com, though I have never experienced any overlap between AWS and Amazon Marketplace Web Services)
It is much smaller than the amount of overlap between, for example, the accounts used for Google Wallet vs Google Cloud Platform. I would be much more concerned for my Google Cloud Platform account if someone placed an order using my Google Wallet than I would be for my AWS account if someone placed an order using my Amazon.com (or.co.uk) account, for example.
Teaching "how to program" to the general population isn't about teaching a practical skill.
Just like Math, the point is to get students to understand Logic and Reasoning skills.
Similar to how P.E. class isn't meant to teach children how to play dodgeball, it's about making sure they understand the importance of being active, and know various ways they might be able to enjoy that.
If a "toy language" is more approachable, go for it.
Universal CS and universal Math classes (beyond basic arithmetic) serve the same purpose: They aren't about learning specific skills / formulas, they are about learning *logic* (with "whether or not you understand when to apply these formulas" being a straightforward way to test if the lessons are working).
Functional programming is a logical "next step" after learning the basics of y = f(x) when learning basic algebra. There's really no need to go beyond pure functional programming, as anything else risks straying too far into the "practical", which is not why these should be taught.
You are not going to get disinterested students to care about routing protocols which are guaranteed to be out-of-date by the time they are taught.
Sane companies are not built to be eternal, and certainly are not built to be immediately and eternally stable. Anyone who discards solutions because they are not infinitely viable is a fool.
The most effective company strategy has been "the startup": create a product which works *now*, if only as a proof-of-concept. Attract investors who will allow that proof-of-concept to become a longer-term solution. Die fast. Repeated effort is not wasted effort, as you literally cannot predict which differences from iteration-to-iteration will be the thing which makes your endeavor work better than the last one (vs which differences are unimportant "details").
when DNS was invented, I'm pretty sure the idea was that this sort of thing would be impossible, because very few people would ever try to register something a mere one level away from the TLD.
x.desktop-environments.linux.os.open-source.org is a bit harder to dispute
with police officers wearing cameras, they implicitly control the narrative. They know that they are wearing cameras, and will always be much more familiar than the average citizen with their capabilities and limitations. If a police officer sees what they interpret as an action warranting an escalation of force, they can ensure that this is captured, and (without being malicious) can ensure that it is captured in a way which most-"accurately" depicts their interpretation of the situation.
Ensuring that other citizens have the right to show things "from their perspective" is key. And honestly, it would be completely absurd to say to anyone, in any situation at all, something which translates to: you are allowed to open your eyes, but you are not allowed to remember what you see.
Part of the whole "Mutually Assured Destruction" thing meant simultaneously posturing and acting in secret.
Vast plans to kill the majority of an "enemy" country, including its civilians, were just the sort of thing which needed to produced, in highest secrecy, so that the enemy spies knew the potential cost of poking the big guy
Really, in most software, "save" and "export" functionality has been merged. Because "whether or not the format is the preferred format of the program" isn't even an implementation detail. It's a developer preference. It has absolutely no place in the main tool. Having one list of formats for "save" and a different list of formats for "export" is beyond insane. Worse than old-Photoshop's "you can't save in this format, because you are using features X, Y, and Z" (instead of just launching a conversion process) - Gimp doesn't give you the option *whether or not* you're using incompatible features.
If you're running a terminal, GNU Screen is absolutely essential. And when you're using GNU Screen, all terminals are pretty much interchangeable already.
So, technically I run Gnome Terminal. But I run Screen inside of that.
Less-technically: I use this https://extensions.gnome.org/e... "Drop Down Terminal" extension, which allows me to bind a key (such as the otherwise unused "context menu" key on my keyboard), to cause a terminal to drop down, as it would in Quake or other games with a "console".
Drop Down Terminal (running "screen -A -x -RR"), has, without any sarcasm or hyperbole, completely revolutionised my workflow. It gives the ability to treat the terminal as something you "peek" at, between doing other tasks (which take place either in the web browser, or some window dedicated to being a text editor). I cannot go on enough about how much I think this should be a thing everywhere.
As a bonus, it gives a use to that otherwise completely useless "context menu" key.
If you're a programmer, you are not automatically an engineer. You are almost certainly not.
If you're a programmer who does everything exactly as the textbooks say, without any variation for what happens in the real world, you might be an engineer.
I'm on-board with Military funding to thwart this - let's fund the military and have them lay down 200 redundant cables. It's absurd how few of these we have.
The question is: Does Google have enough money / clout to piss off its main source of revenue? Are advertisers still its main source of revenue?
When advertisers do nothing, Google could (theoretically) say "follow our new standards or you are banned from our ad network". I mean, that's the obvious thing they "could" do. Whether or not they have the ability to get away with that, that's another thing.
The only thing that should be commented is the "weird why".
For example: "We convert this number to a string here for compatibility with the called library, which expects to handle Big Numbers generically." or "Yes, this is completely stupid, but is required due to an unknown bug. For reasons which have yet to be understood, this code causes a segmentation fault (traced all the way back to llLib-Foo), if this method is not called twice. The resulting output is (mathematically) equivalent, though expectedly weird-looking. As llLib-Foo is only called after seven levels of indirection (six of which, we have absolutely no control over), we are at the mercy of upstream to provide a fix. For now, this appears to work."
The best place for all other "comment"-style documentation is the commit log, where it will be forever associated with exactly when it was written, and what the code looked like at that point.
If I know exactly what someone wants, then sure: write the tests first, that makes sense.
But the vast majority of the time, fulfilling a requirement is just as much about finding what the person *really* wants, as it is about finding out how to supply it.
By the time I know what the question is, the answer has already been written.
It's only at that point that I have the ability to rigorously test the implementation of that answer.
Chip&PIN has always been broken. We're already moving to systems such as Google Wallet / ApplePay, which (whether or not they actually are secure) at least have the theoretical potential to be secure - something which Chip&PIN could never claim.
Exactly this. I'd argue that due to Copyright law's intent of promoting the eventual public domain, anything "secret" is clearly not covered by copyright law.
Because I live in a world where I *don't* need to be tethered 24/7 to my desktop, it's nice to be able to quickly say "Okay, Google: " when I am in the same room, but not actually sitting at the keyboard.
"Okay, Google: " is fairly useless for anything that I don't have my phone out for, though.
I am generally in favor of free airspace (when talking about devices with enough weight to maybe scratch a car if they go wrong)
But on the other hand: if you at any point *lose control* of your drone, to such an extent that it flies into a restricted-for-a-good-reason zone, then I think that's worthy of a fine.
On my phone, "Okay, Google" can be set to respond in any application, or even when the phone is off.
On the desktop, "Okay, Google" only works if you've already opened up a search page.... at which point you may as well type your search.
I have very often wished that "Okay, Google" on Chrome were as convenient as on my phone - or that I could tell my phone to redirect results to my Desktop.
But once again, Google has decided that "our UI was so inconvenient that nobody ever used our product" translates to "nobody wants to use a feature similar to this"
Slashdot Mirror
When you are a customer at Amazon.com, you are very unlikely to lose any money, even if someone hijacks your account. Your risk is extremely low.
When you are a customer with Amazon Web Services, *any* breach or security is exceedingly dangerous and can be severely expensive. Your risk is low because security tends to be high. Any sign of a potential security flaw should be taken very seriously.
He's talking about Amazon Web Services and Google Cloud Platform.
There is a very small amount of overlap between Amazon Web Services support/accounts and Amazon.com support/accounts, but it is not entirely nonexistant (It is possible to be forwarded to the customer service team for one, after much cajoling / convincing that the other team exists at all, having first called the support team for the other. There is more overlap for Amazon Marketplace Web Services vs Amazon.com, though I have never experienced any overlap between AWS and Amazon Marketplace Web Services)
It is much smaller than the amount of overlap between, for example, the accounts used for Google Wallet vs Google Cloud Platform. I would be much more concerned for my Google Cloud Platform account if someone placed an order using my Google Wallet than I would be for my AWS account if someone placed an order using my Amazon.com (or .co.uk) account, for example.
People just don't realise how many practical effects were in The Phantom Menace, for example.
Shit-tons of practical effects. More practical effects than in the entire original trilogy combined.
Then slapped a whole bunch of CG-"retouching" on top until everything looks like a 3dCg model.
It's more likely that they'll be developing a VR Operating system, with some "flagship" proof-of-concept hardware to create initial interest
Teaching "how to program" to the general population isn't about teaching a practical skill.
Just like Math, the point is to get students to understand Logic and Reasoning skills.
Similar to how P.E. class isn't meant to teach children how to play dodgeball, it's about making sure they understand the importance of being active, and know various ways they might be able to enjoy that.
If a "toy language" is more approachable, go for it.
Universal CS and universal Math classes (beyond basic arithmetic) serve the same purpose: They aren't about learning specific skills / formulas, they are about learning *logic* (with "whether or not you understand when to apply these formulas" being a straightforward way to test if the lessons are working).
Functional programming is a logical "next step" after learning the basics of y = f(x) when learning basic algebra. There's really no need to go beyond pure functional programming, as anything else risks straying too far into the "practical", which is not why these should be taught.
You are not going to get disinterested students to care about routing protocols which are guaranteed to be out-of-date by the time they are taught.
Sane companies are not built to be eternal, and certainly are not built to be immediately and eternally stable. Anyone who discards solutions because they are not infinitely viable is a fool.
The most effective company strategy has been "the startup": create a product which works *now*, if only as a proof-of-concept. Attract investors who will allow that proof-of-concept to become a longer-term solution. Die fast. Repeated effort is not wasted effort, as you literally cannot predict which differences from iteration-to-iteration will be the thing which makes your endeavor work better than the last one (vs which differences are unimportant "details").
name two
when DNS was invented, I'm pretty sure the idea was that this sort of thing would be impossible, because very few people would ever try to register something a mere one level away from the TLD.
x.desktop-environments.linux.os.open-source.org is a bit harder to dispute
with police officers wearing cameras, they implicitly control the narrative. They know that they are wearing cameras, and will always be much more familiar than the average citizen with their capabilities and limitations. If a police officer sees what they interpret as an action warranting an escalation of force, they can ensure that this is captured, and (without being malicious) can ensure that it is captured in a way which most-"accurately" depicts their interpretation of the situation.
Ensuring that other citizens have the right to show things "from their perspective" is key. And honestly, it would be completely absurd to say to anyone, in any situation at all, something which translates to: you are allowed to open your eyes, but you are not allowed to remember what you see.
Part of the whole "Mutually Assured Destruction" thing meant simultaneously posturing and acting in secret.
Vast plans to kill the majority of an "enemy" country, including its civilians, were just the sort of thing which needed to produced, in highest secrecy, so that the enemy spies knew the potential cost of poking the big guy
Really, in most software, "save" and "export" functionality has been merged. Because "whether or not the format is the preferred format of the program" isn't even an implementation detail. It's a developer preference. It has absolutely no place in the main tool. Having one list of formats for "save" and a different list of formats for "export" is beyond insane. Worse than old-Photoshop's "you can't save in this format, because you are using features X, Y, and Z" (instead of just launching a conversion process) - Gimp doesn't give you the option *whether or not* you're using incompatible features.
If you're running a terminal, GNU Screen is absolutely essential. And when you're using GNU Screen, all terminals are pretty much interchangeable already.
So, technically I run Gnome Terminal. But I run Screen inside of that.
Less-technically: I use this https://extensions.gnome.org/e... "Drop Down Terminal" extension, which allows me to bind a key (such as the otherwise unused "context menu" key on my keyboard), to cause a terminal to drop down, as it would in Quake or other games with a "console".
Drop Down Terminal (running "screen -A -x -RR"), has, without any sarcasm or hyperbole, completely revolutionised my workflow. It gives the ability to treat the terminal as something you "peek" at, between doing other tasks (which take place either in the web browser, or some window dedicated to being a text editor). I cannot go on enough about how much I think this should be a thing everywhere.
As a bonus, it gives a use to that otherwise completely useless "context menu" key.
If you're a programmer, you are not automatically an engineer. You are almost certainly not.
If you're a programmer who does everything exactly as the textbooks say, without any variation for what happens in the real world, you might be an engineer.
But still, probably not.
I'm on-board with Military funding to thwart this - let's fund the military and have them lay down 200 redundant cables. It's absurd how few of these we have.
The question is: Does Google have enough money / clout to piss off its main source of revenue? Are advertisers still its main source of revenue?
When advertisers do nothing, Google could (theoretically) say "follow our new standards or you are banned from our ad network". I mean, that's the obvious thing they "could" do. Whether or not they have the ability to get away with that, that's another thing.
The only thing that should be commented is the "weird why".
For example: "We convert this number to a string here for compatibility with the called library, which expects to handle Big Numbers generically." or "Yes, this is completely stupid, but is required due to an unknown bug. For reasons which have yet to be understood, this code causes a segmentation fault (traced all the way back to llLib-Foo), if this method is not called twice. The resulting output is (mathematically) equivalent, though expectedly weird-looking. As llLib-Foo is only called after seven levels of indirection (six of which, we have absolutely no control over), we are at the mercy of upstream to provide a fix. For now, this appears to work."
The best place for all other "comment"-style documentation is the commit log, where it will be forever associated with exactly when it was written, and what the code looked like at that point.
If I know exactly what someone wants, then sure: write the tests first, that makes sense.
But the vast majority of the time, fulfilling a requirement is just as much about finding what the person *really* wants, as it is about finding out how to supply it.
By the time I know what the question is, the answer has already been written.
It's only at that point that I have the ability to rigorously test the implementation of that answer.
Chip&PIN has always been broken. We're already moving to systems such as Google Wallet / ApplePay, which (whether or not they actually are secure) at least have the theoretical potential to be secure - something which Chip&PIN could never claim.
Think of the alternative: That by 2015, we haven't ever gone to mars? That's would be absurd.
How about about one rotation every 25 hours (give or take) for 4.5 billion years?
Exactly this. I'd argue that due to Copyright law's intent of promoting the eventual public domain, anything "secret" is clearly not covered by copyright law.
Because I live in a world where I *don't* need to be tethered 24/7 to my desktop, it's nice to be able to quickly say "Okay, Google: " when I am in the same room, but not actually sitting at the keyboard.
"Okay, Google: " is fairly useless for anything that I don't have my phone out for, though.
I am generally in favor of free airspace (when talking about devices with enough weight to maybe scratch a car if they go wrong)
But on the other hand: if you at any point *lose control* of your drone, to such an extent that it flies into a restricted-for-a-good-reason zone, then I think that's worthy of a fine.
On my phone, "Okay, Google" can be set to respond in any application, or even when the phone is off.
On the desktop, "Okay, Google" only works if you've already opened up a search page.... at which point you may as well type your search.
I have very often wished that "Okay, Google" on Chrome were as convenient as on my phone - or that I could tell my phone to redirect results to my Desktop.
But once again, Google has decided that "our UI was so inconvenient that nobody ever used our product" translates to "nobody wants to use a feature similar to this"