You mean where he wrote "and find that so many people despise (sic) my decisions"?
It means "despise" isn't his own choice of words - it's literally the actual word used by the people he's talking about to describe how they felt about some of his decisions, and not merely his interpretation of how they felt.
The word "sic" is short for the Latin phrase "sic erat scriptum", which translates roughly to "exactly as written". It's used by writers to indicate when they are deliberately reproducing someone else's words, phrasing and spelling.
Because it sounds catchy and is technically accurate, even if it's misleading to people who aren't professional airline pilots.
Actual autopilot on aeroplanes is purely assistive - there to make flying the plane a bit easier and somewhat reduce the opportunities for human error - and does not in any way remove the need to have an actual pilot controlling the plane. Tesla's Autopilot serves the exact same role as an aeroplane's autopilot with the same limitation, but in a car, so I suppose they feel that they are perfectly in the right to name it as such.
While actual pilots are trained to know what autopilot is, those not in the field tend to have the impression that it's an autonomous system to take over for the pilots when they need to take a break. Tesla can keep on informing drivers that you still need to be driving the car while Autopilot is running, but it will always be an uphill battle against some drivers who jump to the conclusion that Autopilot is some kind of autonomous driving system and disregard the all warnings to the contrary as some sort of unnecessary legal formality.
Yes, it's absolutely the drivers' fault when they crash because they weren't even paying attention to the road or even controlling the vehicles, but Tesla does need to accept the reality that the name provokes this sort of recklessness. I doubt that any amount of adversarial driver monitoring would be as effective as simply changing the name to something that doesn't suggest that the car can pilot itself automatically.
Yes, the "Show Cookies" button is still there in Nightly and now called "Settings" (presumably a temporary label, because there aren't actually settings in there) but the thing TFA is talking about is that the behaviour of the popup that appears when you press that button has changed from per-cookie to per-site. Previously you got a list of folders, one for each site that has cookies stored. When you expand a folder you get a list of individual cookies that you can see and selectively remove.
Now you simply get a list of websites. For every site on the list you can see how many cookies are stored and how much data is in local storage. It makes sense to group this together here, because local storage and cookies are nearly the same thing. But you can no longer see or delete individual cookies - instead, you delete ALL cookies and storage for a given site or none at all. So the headline is correct in that you can no remove individual cookies from about:preferences.
But you can still fiddle with a site's individual cookies in other ways, like visiting that site and using the developer tools, or grabbing an extension like Cookie Manager.
I know I'm not really contributing anything useful to the conversation by saying this, but I'm going to read his name as "Sen. Ted Cruz (T-Rex.)" from now on.
The title is somewhat misleading. Linux isn't running any slower than before; it's just that the developers have taken longer to release version 4.15 than they have for any other version since 2011, partly due to all of Intel's recent mishaps. This doesn't actually affect anyone much at all (unless you've been anxiously awaiting some or other new feature) - it's just an observation that some might find interesting.
Cape Town has been dealing with it for years, but the National government is doing everything they can to stop them. You see, the ruling party is the ANC, but Cape Town is run by the opposition, the DA. When the ANC ran the city it was collapsing, but after the DA took over it quickly became the best-run city in the country by in just about every metric. That's very embarrassing for the ANC, so they try to sabotage the city wherever possible in order to make their opponents look bad.
Thanks for compiling that list, but I'm not convinced that those are counterexamples at all.
Let's start with the obvious one. The Maltese for tea is "tè". Corto Maltese is a fictional sailor. Presumably you were trying to catch people out, right?
"Arbata" and "herbata" come from the Dutch "herba thee", which in turn comes from "te". Some say it comes from Latin, but Wikipedia disagrees (and Latin wasn't widely-spoken in the 16th century when tea was introduced to Europe, so I'll side with Wikipedia on this).
"iTiye" is the singular noun form of the base word "tiye" which comes straight from Afrikaans word "tee" (pronounced "ti-ye"), which also happens to come from "te" via the Dutch word "thee".
No idea about "lauti" and "dite", but they certainly look like they are derived from "te".
This bug was also fixed in Firefox 52, on the same day that they released the FF 57 bugfix. So if you want to keep crash reports off, receive latest security updates and still have all your old extensions work then Firefox 52 is still an option.
Click on the link. The title is "The Secure Shell (SSH) Transport Layer Protocol". That is the name if the secure transport layer that SSH uses. SSH uses SSH-TRANS as a transport layer, and doesn't use SSL or TLS for anything. You asked for the specs for the SSH encryption mechanism, and you got them, so don't complain.
Here's another link: RFC 4251 - The Secure Shell (SSH) Protocol Architecture. That explains how the various parts of SSH work together. Here's an excerpt:
1. Introduction
Secure Shell (SSH) is a protocol for secure remote login and other
secure network services over an insecure network. It consists of
three major components:
- The Transport Layer Protocol [SSH-TRANS] provides server
authentication, confidentiality, and integrity. It may optionally
also provide compression. The transport layer will typically be
run over a TCP/IP connection, but might also be used on top of any
other reliable data stream.
- The User Authentication Protocol [SSH-USERAUTH] authenticates the
client-side user to the server. It runs over the transport layer
protocol.
- The Connection Protocol [SSH-CONNECT] multiplexes the encrypted
tunnel into several logical channels. It runs over the user
authentication protocol.
The client sends a service request once a secure transport layer
connection has been established. A second service request is sent
after user authentication is complete. This allows new protocols to
be defined and coexist with the protocols listed above.
The connection protocol provides channels that can be used for a wide
range of purposes. Standard methods are provided for setting up
secure interactive shell sessions and for forwarding ("tunneling")
arbitrary TCP/IP ports and X11 connections.
Encryption is handled by the lowest layer of SSH, SSH-TRANS - the secure transport layer, which in turn is typically implemented directly on TCP. No SSL or TLS involved.
The highest later, SSH-CONNECT, is used for whatever kind of connection you want from SSH. This can be a command line, or you could remotely use graphical applications through X forwarding, or you could forward ports or tunnel pretty much and TCP stream.
Sorry, but that's not good enough. You linked to a brief article on differencebetween.net with nothing to support your claim other than the phrase "more often than not SSH uses SSL under the hood", with no elaboration on what that means and nothing to indicate that it's anything other than a naive assumption. And where does your claim "the rest of the time it uses TLS" come from? Pure guesswork? Did you even look at the RFC before replying?
If you want to convince me of your claim you should start by doing some research into whether or not it is actually true, and then provide some arguments as to why. Smug insults such as "You should probably read the summary", "You should probably get a basic level of education" and "I hope you decide to educate yourself someday!" are not convincing, and merely convey the impression that you are embarrassed about being caught out.
Tunelling happens at the SSL/TLS layer. SSH is a protocol that leverages SSL (old school) or TLS (new school) to perform the tunneling.
Wrong. I've already told you that SSH doesn't use SSL or TLS at all. Encryption and tunnelling is all handled within the SSH protocol itself. Here is the RFC for the SSH transport layer protocol, which describes how it works.
You should probably read the summary, which talks about the protocols the Microsoft version does and doesn't support.
Those are cyphers.
You should probably get a basic level of education on why open*SSL* was required by OpenSSH until 2014.
OpenSSL has many components, including libssl (which provides SSL support for applications), libcrypto (providing a number of cryptographic functions) and some tools for working with certificates. OpenSSH's dependency on OpenSSL was because it used libcrypto for cyphers.
You're mistaken. SSH does not establish an SSL connection for shells or anything else. SSH is a cryptographic protocol in its own right, just like SSL and TLS. An "SSH tunnel" really is tunnelling through SSH, not some other protocol.
Amusingly enough, due to their respective places in the OSI model you're more likely to see SSL running on top of SSH than the other way around.
OpenSSL and OpenSSH are not really related. Neither is OpenGL, for that matter. They are different projects maintained by different people, and just happen to all have "Open" in their names. It is possible for OpenSSH to use OpenSSL for some cryptographic functions, but not necessary (at least not anymore - once upon a time OpenSSL was a dependency).
OpenSSH is the OpenBSD project's implementation of an SSH client, server and related utilities. If Microsoft is calling it "OpenSSH" then they must be using a port of OpenBSD's programs instead of creating their own. (In fact, Microsoft promised to port OpenSSH to Windows back in June 2015).
Slashdot Mirror
You mean where he wrote "and find that so many people despise (sic) my decisions"?
It means "despise" isn't his own choice of words - it's literally the actual word used by the people he's talking about to describe how they felt about some of his decisions, and not merely his interpretation of how they felt.
The word "sic" is short for the Latin phrase "sic erat scriptum", which translates roughly to "exactly as written". It's used by writers to indicate when they are deliberately reproducing someone else's words, phrasing and spelling.
Because it sounds catchy and is technically accurate, even if it's misleading to people who aren't professional airline pilots.
Actual autopilot on aeroplanes is purely assistive - there to make flying the plane a bit easier and somewhat reduce the opportunities for human error - and does not in any way remove the need to have an actual pilot controlling the plane. Tesla's Autopilot serves the exact same role as an aeroplane's autopilot with the same limitation, but in a car, so I suppose they feel that they are perfectly in the right to name it as such.
While actual pilots are trained to know what autopilot is, those not in the field tend to have the impression that it's an autonomous system to take over for the pilots when they need to take a break. Tesla can keep on informing drivers that you still need to be driving the car while Autopilot is running, but it will always be an uphill battle against some drivers who jump to the conclusion that Autopilot is some kind of autonomous driving system and disregard the all warnings to the contrary as some sort of unnecessary legal formality.
Yes, it's absolutely the drivers' fault when they crash because they weren't even paying attention to the road or even controlling the vehicles, but Tesla does need to accept the reality that the name provokes this sort of recklessness. I doubt that any amount of adversarial driver monitoring would be as effective as simply changing the name to something that doesn't suggest that the car can pilot itself automatically.
That has an added benefit of avoiding the incumbent wasting valuable time and attention on campaigning for re-election.
Why would you report it as an issue if it appears to be the intended behaviour?
I'm still using Windows Phone, so I can't really miss it.
I'd rather be using almost anything else though.
I've been using VIM for 20 years.
I swear one of these days I'll figure out how to quit the damn thing!
Yes, that's exactly what I said. You can no longer remove individual cookies from about:preferences but you can still do it in other ways.
Yes, the "Show Cookies" button is still there in Nightly and now called "Settings" (presumably a temporary label, because there aren't actually settings in there) but the thing TFA is talking about is that the behaviour of the popup that appears when you press that button has changed from per-cookie to per-site. Previously you got a list of folders, one for each site that has cookies stored. When you expand a folder you get a list of individual cookies that you can see and selectively remove.
Now you simply get a list of websites. For every site on the list you can see how many cookies are stored and how much data is in local storage. It makes sense to group this together here, because local storage and cookies are nearly the same thing. But you can no longer see or delete individual cookies - instead, you delete ALL cookies and storage for a given site or none at all. So the headline is correct in that you can no remove individual cookies from about:preferences.
But you can still fiddle with a site's individual cookies in other ways, like visiting that site and using the developer tools, or grabbing an extension like Cookie Manager.
We are diverse in all things except footware.
Sen. Ted Cruz (R-Tex.)
I know I'm not really contributing anything useful to the conversation by saying this, but I'm going to read his name as "Sen. Ted Cruz (T-Rex.)" from now on.
Sounds like the problem is you aren't storing your bits in a cuddly medium.
I see... so cuddly currencies are better. That must be the idea behind DogeCoin.
The title is somewhat misleading. Linux isn't running any slower than before; it's just that the developers have taken longer to release version 4.15 than they have for any other version since 2011, partly due to all of Intel's recent mishaps. This doesn't actually affect anyone much at all (unless you've been anxiously awaiting some or other new feature) - it's just an observation that some might find interesting.
I'm sure somebody dared him to do it by asking "Are you a bad enough actor to manipulate the Bitcoin ecosystem?"
Cape Town has been dealing with it for years, but the National government is doing everything they can to stop them. You see, the ruling party is the ANC, but Cape Town is run by the opposition, the DA. When the ANC ran the city it was collapsing, but after the DA took over it quickly became the best-run city in the country by in just about every metric. That's very embarrassing for the ANC, so they try to sabotage the city wherever possible in order to make their opponents look bad.
Thanks for compiling that list, but I'm not convinced that those are counterexamples at all.
Let's start with the obvious one. The Maltese for tea is "tè". Corto Maltese is a fictional sailor. Presumably you were trying to catch people out, right?
"Arbata" and "herbata" come from the Dutch "herba thee", which in turn comes from "te". Some say it comes from Latin, but Wikipedia disagrees (and Latin wasn't widely-spoken in the 16th century when tea was introduced to Europe, so I'll side with Wikipedia on this).
"iTiye" is the singular noun form of the base word "tiye" which comes straight from Afrikaans word "tee" (pronounced "ti-ye"), which also happens to come from "te" via the Dutch word "thee".
No idea about "lauti" and "dite", but they certainly look like they are derived from "te".
52 ESR was already fixed last week Thursday with version 52.5.3.
This bug was also fixed in Firefox 52, on the same day that they released the FF 57 bugfix. So if you want to keep crash reports off, receive latest security updates and still have all your old extensions work then Firefox 52 is still an option.
Click on the link. The title is "The Secure Shell (SSH) Transport Layer Protocol". That is the name if the secure transport layer that SSH uses. SSH uses SSH-TRANS as a transport layer, and doesn't use SSL or TLS for anything. You asked for the specs for the SSH encryption mechanism, and you got them, so don't complain.
Here's another link: RFC 4251 - The Secure Shell (SSH) Protocol Architecture. That explains how the various parts of SSH work together. Here's an excerpt:
1. Introduction
Secure Shell (SSH) is a protocol for secure remote login and other
secure network services over an insecure network. It consists of
three major components:
- The Transport Layer Protocol [SSH-TRANS] provides server
authentication, confidentiality, and integrity. It may optionally
also provide compression. The transport layer will typically be
run over a TCP/IP connection, but might also be used on top of any
other reliable data stream.
- The User Authentication Protocol [SSH-USERAUTH] authenticates the
client-side user to the server. It runs over the transport layer
protocol.
- The Connection Protocol [SSH-CONNECT] multiplexes the encrypted
tunnel into several logical channels. It runs over the user
authentication protocol.
The client sends a service request once a secure transport layer
connection has been established. A second service request is sent
after user authentication is complete. This allows new protocols to
be defined and coexist with the protocols listed above.
The connection protocol provides channels that can be used for a wide
range of purposes. Standard methods are provided for setting up
secure interactive shell sessions and for forwarding ("tunneling")
arbitrary TCP/IP ports and X11 connections.
Encryption is handled by the lowest layer of SSH, SSH-TRANS - the secure transport layer, which in turn is typically implemented directly on TCP. No SSL or TLS involved.
The highest later, SSH-CONNECT, is used for whatever kind of connection you want from SSH. This can be a command line, or you could remotely use graphical applications through X forwarding, or you could forward ports or tunnel pretty much and TCP stream.
RFC 4253
Sorry, but that's not good enough. You linked to a brief article on differencebetween.net with nothing to support your claim other than the phrase "more often than not SSH uses SSL under the hood", with no elaboration on what that means and nothing to indicate that it's anything other than a naive assumption. And where does your claim "the rest of the time it uses TLS" come from? Pure guesswork? Did you even look at the RFC before replying?
If you want to convince me of your claim you should start by doing some research into whether or not it is actually true, and then provide some arguments as to why. Smug insults such as "You should probably read the summary", "You should probably get a basic level of education" and "I hope you decide to educate yourself someday!" are not convincing, and merely convey the impression that you are embarrassed about being caught out.
Tunelling happens at the SSL/TLS layer. SSH is a protocol that leverages SSL (old school) or TLS (new school) to perform the tunneling.
Wrong. I've already told you that SSH doesn't use SSL or TLS at all. Encryption and tunnelling is all handled within the SSH protocol itself. Here is the RFC for the SSH transport layer protocol, which describes how it works.
You should probably read the summary, which talks about the protocols the Microsoft version does and doesn't support.
Those are cyphers.
You should probably get a basic level of education on why open*SSL* was required by OpenSSH until 2014.
OpenSSL has many components, including libssl (which provides SSL support for applications), libcrypto (providing a number of cryptographic functions) and some tools for working with certificates. OpenSSH's dependency on OpenSSL was because it used libcrypto for cyphers.
"Susceptible", perhaps.
You're mistaken. SSH does not establish an SSL connection for shells or anything else. SSH is a cryptographic protocol in its own right, just like SSL and TLS. An "SSH tunnel" really is tunnelling through SSH, not some other protocol.
Amusingly enough, due to their respective places in the OSI model you're more likely to see SSL running on top of SSH than the other way around.
OpenSSL and OpenSSH are not really related. Neither is OpenGL, for that matter. They are different projects maintained by different people, and just happen to all have "Open" in their names. It is possible for OpenSSH to use OpenSSL for some cryptographic functions, but not necessary (at least not anymore - once upon a time OpenSSL was a dependency).
OpenSSH is the OpenBSD project's implementation of an SSH client, server and related utilities. If Microsoft is calling it "OpenSSH" then they must be using a port of OpenBSD's programs instead of creating their own. (In fact, Microsoft promised to port OpenSSH to Windows back in June 2015).