giovannibajo1's comments

I wonder if it would work from Rust. I was looking at something minimal like this.

Really great article, props to the author

Even ignoring the fact that there are far better libraries than OpenSSL today (eg: BoringSSL), apt already implements a sandbox-like approach (as the article explains); I'm not sure if the subprocesses are actually sandboxed, but obviously they should and at that point, a vulnerability like the one you cited shouldn't let the attacker escape the very narrow sandbox.

For something more complex, I have written a mostly working Nintendo DS emulator in Go, with JIT, 3D graphics, and whatnot: https://github.com/rasky/ndsemu/

That would make sense if they had the same hardware. Different hardware absorbs different current. You cannot deduce anything from battery size.

It looks like the Go maintainers are playing with a generational GC now. Rick Hudson has posted a patch series on Gerrit: https://go-review.googlesource.com/c/go/+/137482

Yes, and that's really unfortunate. Doubling the cost of G Suite to get intl numbers is a hard sell, but US numbers basically make the feature completely unavailable for many people.

I think the race to make the web an application platform is responsible for this. Web features are growing every day trying to match native apps, and the media guys leverage them to make us sad.

We really need to split the web stack in two somehow, differentiate consumption sites with some basic interaction from full blown applications, handle them completely separately down to the operating system integration level. Right now a web application like Facebook runs in a tab (?) or worse is shipped with a whole browser instance (eg Slack). That’s something wrong here.

A Google-AMP like version of the web for things that are not GMail or Facebook (99% of the web, especially in the long tail) is probably good enough.

Because the pages load fast and are not bloated, which is the point of this article.

Unfortunately Google has bound it to other questionable practices like hosting on their domain, but it’s still a step on the right direction. We need something like that plus a way to cache it on the edge servers in a portable fashion so that any CDN like Cloudflare could pick them up.

For non vital filesystems, I use "-o intr,soft,timeo=5" at NFS mount time. This causes syscalls to return EINTR and timeout without hard locking. It can sometimes confuse userspace, but at least you don't get a stuck process.

It’s meta-fun because you’re getting fun with the mean rather than the end.

To me, it’s fun to achieve a goal — programming to solve a real problem, implementing something that I can use or others can. It’s super fun when my program works, has no bugs, it’s cute and nice.

To others, the act itself of programming is funnier than actually doing something useful, so that you can deep dive into the best way of programming without actually doing something useful if not a program complex enough to use whatever programming feature you want to have meta-fun with.

There’s precedent that Google’s brand doesn’t make people magically swallow programming languages without thinking: Dart.

I think it’s disingenuous to reduce Go success to some Google marketing operation. I dislike Google as a brand in the way they design products and their weak privacy stance, but I love Go nonetheless.

It can be done only by adding an initial check that does only that. But this means that the algorithm speed doesn’t gradually increase with partially sorted sequences.

For instance, timsort is also very fast if only a single element is unsorted, or only two elements, or only three elements. These are not special cases explicitly handled, its just the natural way the algorithm works.

You won't be able to do numeric stuff with these proposals as well. You would still be missing operator overloading and parameter of integer types, which are the basis of any generic numeric code.

This is not related to syscall vs libc. OpenBSD 6.4 requires stacks to be mapped with MAP_STACK, so it requires a runtime change. I’m not sure how using libc would have prevented this

Ref: https://github.com/golang/go/issues/26142

I live in Florence. I’m actually surprised you thought there were too many people in August - the city is empty because locals went to vacation, and is actually low season for hotels because many countries in Europe start schools around the 15th. I was walking last night downtown and I was impressed how empty it was :)

At the same time, weather in August is better than July and June on average — you usually get some storms and thus some relief from hot. But yes, it’s still hottish but that’s Italy.

It’s true that the best seasons would be Spring and Fall. But you get many many more tourists, longer queues, and much higher prices for hotels. So YMMV.

Correct. Apple gets a cut if a customer subscribes through the in-app one-click subscription, which is extremely convenient for any iPhone user (and thus app publishers) because it’s a single click rather than having to insert credit cards, 3D secure and whatnot. In this case the cut is 30% on the first year and 10% afterwards. If the user subscribes through the website, Apple gets nothing. I find this fair.

What is more unfair is that Apple forbids apps to open/link websites where subscriptions can be done to “workaround” the iTunes subscription. If you take Spotify for instance and login as free user, there are absolutely zero mentions that you can upgrade to premium, because they decided to lose those potential customers and rather let them know through other channels of their purchasing options (eg: emails).

On the other hand, this creates a very safe and simple environment for iPhone users. Absolutely NO app asks for a credit card, ever. You either pay one-click safely through iTunes, or nothing. There is no phishing, no mismanaged credit card handling, no credit cards “stolen by hackers from the app I installed into my iPhone”. I’m not saying this fully justifies the above unfair rule, but it’s at least a partial positive side effect.

Go has a pervasive concept of “default being zero” where people are encouraged to write code so that zero-initialization is valid and reasonable. This means that, when adding a new public field to a structure, you always make sure that the default value (nil for pointers) is valid and backward compatible with the previous behavior (eg no change in behavior).

Rust has a half backed support for default initialization, where you can either mark all fields as default initialized via a macro or none (or you can mark them and add a constructor that only changes some, but then the API is confusing for clients unless default initialization is a valid construction). This means that it’s much more common to write constructors, and being forced to set many fields to 0, empty string, None, ecc. is tedious and factually useless; the provide support (Default macro) is not powerful enough to avoid this, unfortunately.

I strongly prefer Go’s approach to default initialization in general, and I think it is orthogonal to non-nullable types (you could have both and save the day). For instance, I don’t see what we lose in Rust by saying that integers auto-initialize to zero unless you name them in the constructor.

This went to blink-dev: https://groups.google.com/a/chromium.org/forum/m/#!topic/bli...

I’m not familiar with their workflow but it looks like something that the development team is considering, not random babbling from a random employee.

Italy has been using this mess for more than ten years now: https://en.wikipedia.org/wiki/Certified_email