Though I'm on board with the sentiment, the truth is that vision has been the case for the last four to six years. Nothing about this release particularly changes the equation. One exception being office functionality, MS Office churns and there's many subtle incompatibilities to contend with.
I meant to be saying that after Heartbleed *everything* got hype. Heartbleed deserved it, but after people say marketing for one security issue, suddenly it became a thing that all security issues get some ridiculous marketing-style bump.
We shall see when the details are released, but in the wake of Heartbleed, I've grown desensitized to marketing treatment for vulnerabilities. Security people jump up and down and are frequently justified, but sometimes are just stating the obvious and/or something of low practical risk. The problem being in general security folks tend not to weight their 'discoveries', so it's hard to know if this time the sky really is falling (sometimes it really is) or they just didn't like some subtle design decision that actually isn't really invalid, just not how they would have done something.
Vulnerabilities in *other* products are the prize. Then these companies come knocking on the doors of the other companies to offer their services for private auditing, the ability to point to security papers in the wild being very valuable as a proof point.
Profitability is relative. Just like a broken window isn't good for the economy at large, it is however good if you are specifically a glass maker. It's more cost than profit overall, but if you are a company offering auditing services, you don't incur the costs.
If, say, Ford had a car door lock is vulnerable to something, and some *other* company finds it and gets all over the news, sure bad for Ford, but good for the company that finds it. That company will then contact GM, Toyota, Dodge, Honda, and so on and so forth with the cautionary tale of 'look what happened to Ford, we are so clever, we can help you... for a cost'.
Besides, I thought they were shying back toward SMB terminology, since 'CIFS' didn't really catch on. I prefer SMB because CIFS doesn't really describe it as well (it's not really the best strategy for 'internet', it's 'common' by virtue of everyone else having to cave because MS wouldn't do it like anyone else, etc).
But yes, the description of the *potential* security is out of date (Though NTLM still in practice plays a huge role for most folks).
The issue being that if you break it, you have no one to reasonably point the finger at. This is a big deal in most commercial settings.
I have seen first hand a user of open source software sing the praises, but ultimately couldn't find another company to support *precisely* what they were using, and had to scrap it and frankly have a much worse experience for lack of commercial support. It's a big deal. Whether it should be or not.
It's a particular sort of statement. When they said '$2B company', that *usually* refers to market cap (which can indeed be exaggerated by unfounded confidence).
To refer to a '2B company' meaning 'company that pulled in 2B of revenue in a year, that's a bit different.
Hence the errant comparison of revenue to overvalued startup unicorns.
They are open source, but if you want to run big-R 'RedHat', you need a goofy rhn subscription/satellite to get updates and such, instead of it just working.
CentOS is a lot more *convenient* to use as a consequence. Of course there is a more steep promise associated with 'if I installed it from RHEL repoes, RH will answer about it. RH is a careful company that doesn't make such a promise lightly. It would rather not get caught unable to reasonably support software it was the authoritative download for.
It was all about not having anything compelling to continue on the gimmick of the motion controllers (whose gimmickness had already worn thin before the Wii-U released).
But you are right, Nintendo utterly failed to support it from a first-party perspective, and third parties had zero incentive to bother.
On homebrew, cool as Wii was with homebrew, financially that wasn't even a blip on the radar.
The transport doesn't support *any* concept of storage. It doesn't have to, that's why it's called transport.
Now you could say you should be using S/MIME or similar as it's more comprehensive end-to-end and secure transport is inadequate, but this is strictly a transport standard.
It's also a standard that can do something to mitigate risk to those who do not avail themselves of S/MIME.
In your own story, you highlight an issue. You face some obstacle to payment and recognize that, and have the sense/courtesy to take care of that ahead of time.
However, there are plenty of folks who will just sit there dumbly as the clerk rings up items. Also a lot of scenarios where you are busy doing something else (putting away the bags) and scenarios where there is no 'downtime' of items being rung up (though then presumably you take care of it in line before you get there).
We are talking about an audience that is frequently unhappy enough at having to put their card into a system and leave it there while the transaction completes. There are still folks who would rather hand their card to the cashier than swipe the card themselves when they have the option.
GPG and/or S/MIME would address your concern, but this proposal would not.
This is basically using TLS more properly in SMTP, which in and of itself is good, but far from adequate.
Here is the tricky thing about TLS: it works well in theory for user-service interactions (e.g. I care I'm talking to 'onlinebanking.bigbank.com'), but not as well for messaging (I'm not conversing with a server, whose identity is hidden away in the headers, I'm conversing with whatever is in the 'From/To/CC/BCC' fields, and those are the folks I care about authenticating)
The storage of content and transmission of content are separate concerns. A standard protocol to cover transmission of messages should not be concerned with the storage of it.
Ok, was just making sure as a large chunk of folk seem to feel like Python is some new thing, not realizing it dates back to the early 90s.
In the 90s, there's a large body of projects that eventually superseded then-current state of the art. In the years since 2000, there aren't that many success stories in that realm. There has been no shortage of attempts, but the success rate in the last several years has left me skeptical.
I'm not saying I don't understand what the point is, I'm saying you can't throw that at someone who says they *personally* prefer the other way, saying their preference is *wrong*.
Here, he says he prefers short travel distance over ability to overshoot. It's ludicrous to tell him he's wrong in that preference. People prefer different things. Notably, unless I'm *only* doing menubar/corner stuff, my mouse sensitivity is going to be such that there will be a lot of dragging to get to edge of screen. Since most UI elements I need to interact with are not going to be menubar/corner buttons, my mouse will be a pain to drag to the edge, and precision is such that I'm not going to care.
Oh, I'm very keenly aware and have recently seen it (which had the same things avoided that realtime rendered scenes avoid today). It would be silly to claim realtime can't best Toy story. The fastest supercomputer in the world the month Toy story came out would be bested by a single quad-core Haswell 3.0 ghz (though only barely). However as the pre-rendered cinematic have been able to start featuring more and more of the things they had to originally skip, realtime hasn't been able to do the same for everything (physics/geometry are straightforward in the relationship, but advanced lighting phenomena are just not in the cards for rasterization, good news being it's generally the lighting effects people don't notice unless they are looking for them explicitly).
Though the engines are capable, it still takes a great deal of work to actually bring out those capabilitiies. You still need laborious modeling and texturing work if you want something 'AAA' and can't just assemble things out of stock content from the asset stores.
Titles developed on a budget have not come remotely close to the aspirational demos of the engines they have used to date, and I wouldn't expect that to change anytime soon.
Slashdot Mirror
Agreed, though I struggle to understand the claimed 'acheivement' from MS. Here is an 'AI' that just echoes whatever is said back at people.
MS really deserved what it got here, trying to pass off a quick and dirty effort as 'AI', and the results served to call them on it.
Though I'm on board with the sentiment, the truth is that vision has been the case for the last four to six years. Nothing about this release particularly changes the equation. One exception being office functionality, MS Office churns and there's many subtle incompatibilities to contend with.
I meant to be saying that after Heartbleed *everything* got hype. Heartbleed deserved it, but after people say marketing for one security issue, suddenly it became a thing that all security issues get some ridiculous marketing-style bump.
We shall see when the details are released, but in the wake of Heartbleed, I've grown desensitized to marketing treatment for vulnerabilities. Security people jump up and down and are frequently justified, but sometimes are just stating the obvious and/or something of low practical risk. The problem being in general security folks tend not to weight their 'discoveries', so it's hard to know if this time the sky really is falling (sometimes it really is) or they just didn't like some subtle design decision that actually isn't really invalid, just not how they would have done something.
Vulnerabilities in *other* products are the prize. Then these companies come knocking on the doors of the other companies to offer their services for private auditing, the ability to point to security papers in the wild being very valuable as a proof point.
Profitability is relative. Just like a broken window isn't good for the economy at large, it is however good if you are specifically a glass maker. It's more cost than profit overall, but if you are a company offering auditing services, you don't incur the costs.
If, say, Ford had a car door lock is vulnerable to something, and some *other* company finds it and gets all over the news, sure bad for Ford, but good for the company that finds it. That company will then contact GM, Toyota, Dodge, Honda, and so on and so forth with the cautionary tale of 'look what happened to Ford, we are so clever, we can help you... for a cost'.
Besides, I thought they were shying back toward SMB terminology, since 'CIFS' didn't really catch on. I prefer SMB because CIFS doesn't really describe it as well (it's not really the best strategy for 'internet', it's 'common' by virtue of everyone else having to cave because MS wouldn't do it like anyone else, etc).
But yes, the description of the *potential* security is out of date (Though NTLM still in practice plays a huge role for most folks).
The issue being that if you break it, you have no one to reasonably point the finger at. This is a big deal in most commercial settings.
I have seen first hand a user of open source software sing the praises, but ultimately couldn't find another company to support *precisely* what they were using, and had to scrap it and frankly have a much worse experience for lack of commercial support. It's a big deal. Whether it should be or not.
Generally, when you say 'an X dollar company', people are referring to market cap, or the aggregate consensus value believed in by your investors.
It's a particular sort of statement. When they said '$2B company', that *usually* refers to market cap (which can indeed be exaggerated by unfounded confidence).
To refer to a '2B company' meaning 'company that pulled in 2B of revenue in a year, that's a bit different.
Hence the errant comparison of revenue to overvalued startup unicorns.
They are open source, but if you want to run big-R 'RedHat', you need a goofy rhn subscription/satellite to get updates and such, instead of it just working.
CentOS is a lot more *convenient* to use as a consequence. Of course there is a more steep promise associated with 'if I installed it from RHEL repoes, RH will answer about it. RH is a careful company that doesn't make such a promise lightly. It would rather not get caught unable to reasonably support software it was the authoritative download for.
Payroll, capital assets, power bills, etc etc.
~15% margin is respectable, a *touch* on the lean side for the industry.
It was all about not having anything compelling to continue on the gimmick of the motion controllers (whose gimmickness had already worn thin before the Wii-U released).
But you are right, Nintendo utterly failed to support it from a first-party perspective, and third parties had zero incentive to bother.
On homebrew, cool as Wii was with homebrew, financially that wasn't even a blip on the radar.
The transport doesn't support *any* concept of storage. It doesn't have to, that's why it's called transport.
Now you could say you should be using S/MIME or similar as it's more comprehensive end-to-end and secure transport is inadequate, but this is strictly a transport standard.
It's also a standard that can do something to mitigate risk to those who do not avail themselves of S/MIME.
In your own story, you highlight an issue. You face some obstacle to payment and recognize that, and have the sense/courtesy to take care of that ahead of time.
However, there are plenty of folks who will just sit there dumbly as the clerk rings up items. Also a lot of scenarios where you are busy doing something else (putting away the bags) and scenarios where there is no 'downtime' of items being rung up (though then presumably you take care of it in line before you get there).
We are talking about an audience that is frequently unhappy enough at having to put their card into a system and leave it there while the transaction completes. There are still folks who would rather hand their card to the cashier than swipe the card themselves when they have the option.
GPG and/or S/MIME would address your concern, but this proposal would not.
This is basically using TLS more properly in SMTP, which in and of itself is good, but far from adequate.
Here is the tricky thing about TLS: it works well in theory for user-service interactions (e.g. I care I'm talking to 'onlinebanking.bigbank.com'), but not as well for messaging (I'm not conversing with a server, whose identity is hidden away in the headers, I'm conversing with whatever is in the 'From/To/CC/BCC' fields, and those are the folks I care about authenticating)
It could be considered a protocol to negotiate use of TLS more securely.
S/MIME and OpenPGP would be more thorough solution to the problem.
The new protocol also works with HTTPS to avoid SSL/TLS downgrades and MitM attacks.
The article says:
HSTS works alongside HTTPS to avoid SSL/TLS downgrades and MitM attacks.
HSTS != SMTP STS, though they are similar.
The storage of content and transmission of content are separate concerns. A standard protocol to cover transmission of messages should not be concerned with the storage of it.
Ok, was just making sure as a large chunk of folk seem to feel like Python is some new thing, not realizing it dates back to the early 90s.
In the 90s, there's a large body of projects that eventually superseded then-current state of the art. In the years since 2000, there aren't that many success stories in that realm. There has been no shortage of attempts, but the success rate in the last several years has left me skeptical.
Of course, 'if all goes well, should use Mir by default' has been a missed goal a few times in the past.
Note that even if you think python is just right, it came about in 1994. It's the same generation roughly as the Linux kernel.
I'm not saying I don't understand what the point is, I'm saying you can't throw that at someone who says they *personally* prefer the other way, saying their preference is *wrong*.
Here, he says he prefers short travel distance over ability to overshoot. It's ludicrous to tell him he's wrong in that preference. People prefer different things. Notably, unless I'm *only* doing menubar/corner stuff, my mouse sensitivity is going to be
such that there will be a lot of dragging to get to edge of screen. Since most UI elements I need to interact with are not going to be menubar/corner buttons, my mouse will be a pain to drag to the edge, and precision is such that I'm not going to care.
Oh, I'm very keenly aware and have recently seen it (which had the same things avoided that realtime rendered scenes avoid today). It would be silly to claim realtime can't best Toy story. The fastest supercomputer in the world the month Toy story came out would be bested by a single quad-core Haswell 3.0 ghz (though only barely). However as the pre-rendered cinematic have been able to start featuring more and more of the things they had to originally skip, realtime hasn't been able to do the same for everything (physics/geometry are straightforward in the relationship, but advanced lighting phenomena are just not in the cards for rasterization, good news being it's generally the lighting effects people don't notice unless they are looking for them explicitly).
Though the engines are capable, it still takes a great deal of work to actually bring out those capabilitiies. You still need laborious modeling and texturing work if you want something 'AAA' and can't just assemble things out of stock content from the asset stores.
Titles developed on a budget have not come remotely close to the aspirational demos of the engines they have used to date, and I wouldn't expect that to change anytime soon.
There's also 'Titan-X'. So there's a a very very high ceiling.