pavfarb

So that's why Taleb deadlifts like a madman.

The way I see it, Acra combines rather unique security guarantees in a very elegant way. More precise questions could fruit more precise answers, though

Woohoo!

I am one of the engineers behind the project, and can answer questions if anyone has any.

"built-in JSON serializer/deserializer" near "closures" and "coroutines (via fibers)" feels a bit.. odd. Sign of the times, I understand, but still.

Apart from this boring grumbling, the project is very interesting. Waiting for internals (https://marcobambini.github.io/gravity/internals/index.html) to arrive.

If we could avoid doing so - we would, because we understand how hard earned Go's guarantees are. But, things are the way they are.

But, as he says, 'sometimes you have to'. This is a time like this.

Well, it is true: it was interesting side effect that 'just worked', we were like 'hmm, if GC is able to control external memory allocation, well, fine, maybe Go is even better than we've thought initially'.

At some point in time, someone behind Go/CGo realized that automatically managing pointer math is an exercise that is being attempted for last 15 years without success (there always will be absolutely normal situations where you can't measure allocation correctly), and just limited visibility scope to things Go can control.

"This looks like a serious API break."

So thought we, being a bit annoyed. But when you think of how many problems it actually prevents,- it's a worthy move, in the end.

It would, but the place where these techniques are helpful the most (untyped languages with problematic input sanitization) are the languages for which hurting intermediary performance is a minor offense: most of it is already wasted by language itself.

Not so, regular engineers should write, it's a question of what they write. I'm a regular engineer, my colleagues are as regular boring folks as possible, yet we're writing stuff from time to time.

Look, here's an example, which emerged this morning as a pure coincidence:

I have a almost-finished blog post draft in front of my eyes my colleagues and I have been writing some time now. It outlines a problem we've stumbled, and, we believe, many other engineers have stumbled or will stumble upon quite soon (while migrating their code from Go 1.3 to 1.6 and further). The problem is exceptionally boring and stupid. We took extremely boring un-brilliant way to solve it.

The engineer who first encountered could've just written something like 'go memory management sucks', or 'how go moves forward and breaks my stuff in production', a million-and-first post about minor opinion. This is what I call useless noise, and, when used for self-promotion, quickly becomes click-bait out of desperation to get at least some attention.

Instead, we've fixed the issue, and in spare time have been slowly adding detail, reproducing cases and generating isolated statistics exactly for this case, and it grew into useful piece of knowledge for regular engineers (like we are) not to repeat the stupid mistakes we've done.

It is not as immediately rewarding, to sit on it longer until your writing has at least some utility for others, and will pay them off for the time and attention and context switch they've invested into you. This is what matters, not the "exceptionality" of engineers who are writing this.

>I actually miss the days when engineers blogged more rather than accumulating karma on Stackoverflow.

100% hit. I do write sometimes on StackOverflow to give back some help to the wonderful minds over then Internet, because, sharing knowledge is what makes the whole engineering better. What percent of clickbait attention-craving blogging does share some useful insight and/or knowledge?

>I find it strange that this is the top comment on a forum that wouldn't exist if engineers didn't write publicly.

Maybe because you didn't understand the core meaning of the comment? (I address this equally to my writing skills: English is not my first language). It's not "engineers shouldn't write", at all.

It's really unfortunate that people do read my comment as "engineers shouldn't write". Engineers should write. I actually write a lot of stuff, because I like it. There are some pieces of your own research you can't understand unless you write it down in a readable, less formal way.

Some small grain of my writing becomes decent enough (English is not my main language) that my employer takes it and uses somewhere.

Because, I believe, writing is important. Noising everything around with your writing isn't important and isn't even OK.

There's even nothing wrong with using writing for promoting yourself, if there are great things you can share with the world. There are a few dozen blogs I read over weekend, some of them are obviously self-promotion driven to attract attention to services or products; but they give me insight into new things in extremely polite fashion, and I love it. But only when the first phrase of my initial comment is valid:

Engineers should blog publicly when they have something to say.

Writing is, publishing and noising the channels isn't. I'm afraid I find experimentation like that at cost of other people's time and attention to be a bit petty crime.

Engineers should blog publicly when they have something to say. Something useful for their colleagues. Engineers shouldn't waste time forcing themselves to blog instead of work just to push their career forward: frequently they just expose they don't have anything to say in extremely unreadable way. What a waste of time for everybody.

Soft skills helps you grow as an engineer, it's true, but I think it's important to understand that not every exercise should become a public material.

But, in a generation publishing their every 2nd gym workout on instagram, who am I kidding anyway.

If we think that intentional collision is not a threat vector, while, as life shows, it is: https://bugs.webkit.org/show_bug.cgi?id=168774#c23

Now I really wonder what will happen to Git we all know and love.

SHA1 use cases are not limited into integrity verification of documents, but used a lot for traffic integrity and generation of authentication codes:

- Torrents of all kinds. - Version control systems (where ability attacks like displacing release pointers become easier). - IpSec, SSH, PGP and a number of other protected data exchange systems.

Being able to subvert integrity guarantees is a nice building block for complicated man-in-the-middle attacks.

The whole idea of relying core security guarantee (provable 'no knowledge' on server side) on unreliable mechanism (in-browser cryptography) is feels really wrong.

There are many services which attempt to base their security on in-browser javascript cryptography.

What could be really valuable is not building Yet Another Service That Helps Privacy (but really, doesn't), but investing effort into building trusted execution models within the browser any website could utilize.

Secure apps will follow just instantly.