Am Sat, 25 Feb 2017 21:19:59 +0000
schrieb Stefan Koch <uplink.coder@googlemail.com>:

> On Saturday, 25 February 2017 at 21:12:13 UTC, Timon Gehr wrote:
> 
> >
> > I know my claim seems insane, but it is actually true.
> >
> > http://forum.dlang.org/post/lr4kek$2rd$1@digitalmars.com
> 
> The optimizer can currently not take advantage of it.
> and I don't see how that would change in the near future.

in GCC/GDC: if -release:

assert(expr);
==> if(!expr) __builtin_unreachable();

Would be trivial to implement but with unpredictable consequences.

-- Johannes

On Sunday, 26 February 2017 at 03:54:54 UTC, Nick Sabalausky (Abscissa) wrote:
> On 02/24/2017 12:47 PM, H. S. Teoh via Digitalmars-d wrote:
>>
>> The elephant in the room is that the recent craze surrounding the "cloud" has conveniently collected large numbers of online services under a small number of umbrellas, thereby greatly
>> expanding the impact of any bug that occurs in the umbrella.
>> Instead of a nasty bug that impacts merely one or two domains,
>> we now have a nasty bug that singlehandedly affects 4
>> *million* domains.  Way to go, "cloud" technology!
>>
>
> Indeed. The big original *point* of what became the internet, and why the internet got as successful as it did, was decentralization. The past decade or so of recentralization is a shame, to say the least. But I suppose it was inevitable: Now that corporations are involved, corporate interests are involved, and corporate motivator #1 is "control as much of the territory as you can: size == profit".

Yet another nail in the coffin:

https://www.theregister.co.uk/2017/03/01/aws_s3_outage/


--T

H. S. Teoh wrote:

> Yet another nail in the coffin:
>
> https://www.theregister.co.uk/2017/03/01/aws_s3_outage/

i just can't stop laughing.

On Thursday, 2 March 2017 at 20:59:44 UTC, ketmar wrote:
> H. S. Teoh wrote:
>
>> Yet another nail in the coffin:
>>
>> https://www.theregister.co.uk/2017/03/01/aws_s3_outage/
>
> i just can't stop laughing.

Seems like it was a fat finger error

http://www.geekwire.com/2017/amazon-explains-massive-aws-outage-says-employee-error-took-servers-offline-promises-changes/

On Thu, Mar 02, 2017 at 09:51:44PM +0000, jmh530 via Digitalmars-d wrote:
> On Thursday, 2 March 2017 at 20:59:44 UTC, ketmar wrote:
> > H. S. Teoh wrote:
> > 
> > > Yet another nail in the coffin:
> > > 
> > > https://www.theregister.co.uk/2017/03/01/aws_s3_outage/
> > 
> > i just can't stop laughing.
> 
> Seems like it was a fat finger error
> 
> http://www.geekwire.com/2017/amazon-explains-massive-aws-outage-says-employee-error-took-servers-offline-promises-changes/

Yes, which inevitably happens every now and then, because of human fallability.

But again, the elephant in the room is that in the good ole clear-weather days, such an error would at most take out one or two (or a small handful) of related sites; whereas in today's cloudy situation a single error in umbrella services like AWS can mean the outage of thousands or maybe even millions of otherwise-unrelated sites.

And thanks to the frightening notion of the Internet of Things, one day all it will take is a single failure and society would stop functioning altogether.

(Even more frightening than catastrophic failure is when a security vulnerability is replicated across redundant umbrella systems, thereby effectively making the surface of attack universally wide -- and then there's no telling what kind of disastrous consequences will ensue. Cloudbleed is only the tip of the iceberg.)


T

-- 
Let X be the set not defined by this sentence...

On Friday, 24 February 2017 at 13:38:57 UTC, Moritz Maxeiner wrote:
> On Friday, 24 February 2017 at 06:59:16 UTC, Jack Stouffer wrote:
>> https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
>>
>> [...]
>
> This isn't evidence that memory safety is "the future", though.

Completely agreed.
This only shows that memory safety is not the present. Not that it is "the future".

This reasoning reminds me of the Keynes quote: "The market can stay irrational longer than you can stay solvent."

On Thursday, 2 March 2017 at 22:25:49 UTC, H. S. Teoh wrote:
>
> But again, the elephant in the room is that in the good ole clear-weather days, such an error would at most take out one or two (or a small handful) of related sites; whereas in today's cloudy situation a single error in umbrella services like AWS can mean the outage of thousands or maybe even millions of otherwise-unrelated sites.
>
> And thanks to the frightening notion of the Internet of Things, one day all it will take is a single failure and society would stop functioning altogether.
>

Reminds me of Nassim Taleb's work on black swans and antifragility.

On Thursday, 2 March 2017 at 22:25:49 UTC, H. S. Teoh wrote:
> [...]
>> 
>> http://www.geekwire.com/2017/amazon-explains-massive-aws-outage-says-employee-error-took-servers-offline-promises-changes/
>
> Yes, which inevitably happens every now and then, because of human fallability.
>
> But again, the elephant in the room is that in the good ole clear-weather days, such an error would at most take out one or two (or a small handful) of related sites; whereas in today's cloudy situation a single error in umbrella services like AWS can mean the outage of thousands or maybe even millions of otherwise-unrelated sites.

To me it seems like a lot of people - once again - gambled (and lost) on one of the primary criteria of reliable engineering: Redundancy.
The relevant question now, I think, is why do people keep doing this (as this is not a new phenomenon)? My current favorite hypothesis (as I don't have enough reliable data) is that they simply don't *have* to care about a couple of hours of downtime in the sense that whatever profits they may lose per year related to those outages does not come close to what they save by not paying for redundancy.

>
> And thanks to the frightening notion of the Internet of Things, one day all it will take is a single failure and society would stop functioning altogether.

One of the primary reasons (for us all) to invest in technological heterogeneity, imho:
Multiple competing hardware platforms, operating systems, software stacks, etc.
The more entities we have that perform similar functions but don't necessarily work the same the higher our resistance against this kind of outcome (analogous to - IIRC - how diverse ecosystems tend to be more resistant to unforeseen changes).

On Thursday, 2 March 2017 at 23:00:34 UTC, Guillaume Piolat wrote:
> On Friday, 24 February 2017 at 13:38:57 UTC, Moritz Maxeiner wrote:
>> On Friday, 24 February 2017 at 06:59:16 UTC, Jack Stouffer wrote:
>>> https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
>>>
>>> [...]
>>
>> This isn't evidence that memory safety is "the future", though.
>
> Completely agreed.
> This only shows that memory safety is not the present. Not that it is "the future".

For what it's worth: I do hope memory safety becomes a common feature and what languages like D and Rust do on that front is great (even though both D's still heavily integrated GC as well as Rust's static analysis have their downsides).
My major gripe, though, is still that people tend to create "safe" wrappers around "unsafe" (mostly) C libraries, which (in the sense of safety) doesn't really help me as a developer at all:
Now I not only have to trust that the C library doesn't do horribly stuff (or audit its source), I *also* have to extend the same trust/time to the wrapper, because since it must interface with C all possible compiler guarantees for what that wrapper actually *does* are null and void (-> D's @system / Rust's unsafe blocks).
Great, if I *truly* care about safety my workload has increased significantly compared to just using the "unsafe" C APIs myself (which is easy in D and a PITA in Rust)!
In reality, of course, I just use the wrapper and die a little inside about the fact that I have to trust even more people to get things right when all evidence shows that I totally shouldn't.
TL/DR: I wish people would write more native libraries in safe languages, but who has the time for that?

On 03/02/2017 06:00 PM, Guillaume Piolat wrote:
> On Friday, 24 February 2017 at 13:38:57 UTC, Moritz Maxeiner wrote:
>> On Friday, 24 February 2017 at 06:59:16 UTC, Jack Stouffer wrote:
>>> https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
>>>
>>> [...]
>>
>> This isn't evidence that memory safety is "the future", though.
>
> Completely agreed.
> This only shows that memory safety is not the present. Not that it is
> "the future".

I think it's safe enough to just go ahead and interpret it as "...evidence that memory safety is important and SHOULD be the direction we take."

It's English, not an ISO RFC.