merijnv

I mean, you say "is this it?", but the multi-language support of literally all other Android keyboards I've used are basically unusable. Take Google's default keyboard, it requires you manually switch languages for swiping and predictive text to work. But that's completely unworkable for the way multi-lingual people end up actually typing texting. I swap back and forth across languages, even if just for 1 or 2 words and having to explicitly toggle languages is a MAJOR speedbump in typing.

Swiftkey just lets me auto-complete/swipe in multiple languages seamlessly. Want to swipe 1 English word inside a completely Dutch sentence? No problem. The reverse? No problem. Using Google's keyboard the same way is endlessly frustrating.

Happens to me a lot on Youtube too - you watch just one thing - and now your recommendations are full of things like that one thing.

Spotify's recommendation system is much better than youtube's (at least for me). I frequently "joke" that it is one of the few applications of ML that actively make my life as a consumer better.

Having been following Spotify's "Discover Weekly" for several years now, I'm actually really impressed how it manages to blend my long-term taste with recent moods. If I've been listening to one type of music for 1 or 2 weeks, there will be a noticeable uptick of it in the recommendations, while still mixing in less recent tastes.

std::map (as opposed to std::unordered_map) uses a balanced binary search tree approach and thus guarantees O(log n) lookup for anything that has a well-defined total order (i.e. comparison function), without worrying about hash functions, etc.

So, yes you can ;)

"the /usr split is there for a reason!". No, it's just an historical quirk.

It's a historical quirk on linux, where there is no clear separation between "base OS packages" and "3rd party packages".

On FreeBSD the split is very real, anything in /bin/ ships with my OS and is maintained and updated by the FreeBSD team. Anything in /usr/bin/ comes from ports and is thus a 3rd party package I installed and can be safely nuked and I need to maintain/update it.

You're assuming cars are the only valid transport option. London isn't the US, you can just take the subway or bus instead...

It actually also compares data when the two databases have different schemas! It's pretty nice for quickly comparing changes in datasets.

Businesses outside EU are not bound by GDPR.

Business outside the EU, interacting with users in the EU are bound by the GDPR. There might not really be a way (currently) to impose penalties on those businesses for violations, but they are certainly bound by them.

The maximum fine allowed by GDPR is "10 million or 2% of global revenue, whichever is higher". The goal is to ensure the GDPR "has teeth" even against companies for who 10 million is a drop in the bucket.

Keep in mind that large parts of the GDPR were already law in many EU countries, meaning there's years worth of enforcement activity that you can lookup to see how similar laws were enforced.

And mostly that has not been "handing out the biggest fines possible" and more "fines scaled to how grossly you violate the regulation". Companies who try their best to follow the law, have good processes and respond promptly, get a slap on the wrist or even just a warning if they remedy the issue fast. Companies that blatantly violate the law and stonewalling regulators get the harsh fines.

The real reason isn't that the system would be GPLv3. The real reason is that GPLv3 includes a patent grant clause, which many companies (Apple included) are very worried about applying to them if they ship GPLv3 code, therefore they don't.

...does seem to suggest that the "garbage multiplier" effect of immutability is an ill fit for applications that also create a lot of garbage naturally

That actually depends on how your GC is implemented. For example, due to laziness+immutability, Haskell produces a lot of garbage and a lot of allocations. This is not a problem with the GHC compiler, as the GC design makes allocation cheap (effectively a bump pointer allocator) and GC cost scales with the amount of non-garbage (this is, like all GC design, is a trade-off that can get you into trouble with some workloads).

Typically legitimate interest is used where consent isn’t an applicable basis (e.g. for processing a user’s address details in an online checkout).

Nope, that'd be the "contract" basis (i.e. this information is strictly necessary for the user's intended task).

Legitimate interest is for non-essential data that it is, somehow, in the user's best interest to gather. But convincing a judge of that data being in the user's best interest is a...tricky bar to clear.

I'd scratch the arguably, seems to blatantly violate the pretty explicit text of the GDPR.

Interesting precedent. The platform is responsible not just for their own security practices, but also their users' security practices.

Well, not really. Booking didn't get fined over security practices. They got fined over not notifying of a breach of their users data within 72 hours.

So you're not really "responsible for users' security practices", you're "responsible for notifying users/authorities in time when you notice leaks/breaches". Seems rather different to me.

This is just not true. See my comment elsewhere in this thread:

Why is it not GDPR compliant. You do not need consent under the GDPR. You need a (documented) "lawful basis for processing" personal information. Consent is just one of several lawful bases and honestly it's the most useless one, if you need consent your business model is screwed. It's perfectly possible for GitHub to process personal information without explicit consent while not violating the GDPR. Several options come to mind:

1) consider analytics part of the "contract legal" basis, arguing that analytics to improve the usability of the website is a fundamental part of running a website.

2) The "legitimate interest" lawful basis, which states:

processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

Arguing that improving the accessibility/usability is in the legitimate interest of both company and user.

I'm fairly confident that, depending on which and what detail of personal information, both of these justifications will be accepted by EU courts.

Why is it not GDPR compliant. You do not need consent under the GDPR. You need a (documented) "lawful basis for processing" personal information. Consent is just one of several lawful bases and honestly it's the most useless one, if you need consent your business model is screwed.

It's perfectly possible for GitHub to process personal information without explicit consent while not violating the GDPR. Several options come to mind:

1) consider analytics part of the "contract legal" basis, arguing that analytics to improve the usability of the website is a fundamental part of running a website.

2) The "legitimate interest" lawful basis, which states:

processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

Arguing that improving the accessibility/usability is in the legitimate interest of both company and user.

I'm fairly confident that, depending on which and what detail of personal information, both of these justifications will be accepted by EU courts.

You aren't forced to service users. You just cannot make consent the currency for your service. Either don't require consent or don't operate in the EU.

Correct. Also, you cannot with hold access upon users not consenting, so there's literally zero incentive for users to ever consent for compliant providers. Which is kinda obvious with the GDPR's overall goal of making it impossible to use privacy as currency.

Is making à file based database that hard,compared to creating new programming language for exemple ?

Yes. I can hack together a trivial compiler in a weekend. A serious (non-optimising) compiler for a complex language is a task you could do in a few months.

If you gave me two year I'm not sure I could implement a filesystem API that correctly did something as simple as "atomically append to a file". See also Dan Luu's writing on the topic of filesystems: https://danluu.com/deconstruct-files/

I predict that will eventually end too as they aim towards profitability.

Honestly, I don't really think so. I think MS's goal for GitHub is to be a "loss leader" to keep developer mindshare. They lost a lot of developer mindshare to linux, open source, etc. in the migration to the web and cloud.

Providing GitHub and CI for free to open source/students is a great way to keep developer mindshare. Make sure it's nicely integrate into Azure cloud for deployment and devops and you have a streamlined pipeline of leading large numbers of developers to your cloud platform.

If your company has PII, then you by law must be able to produce a consented attestation chain all the way back to the source.

So...basically the GDPR? Well, not quite, since the GDPR doesn't require consent attestation, "merely" a legal basis. Of which consent is just one (the most useless one to use as a company).

For what it's worth, I've been using Mercurial + hg-git to interact with git repos since 2010 and I still do with all my git and github using colleagues.

Can you enlighten me how git's internal model is more beautiful than, say, Mercurial? Which has the added bonus of having a UI which isn't a dumpster fire...

Lemme give you one example of one workflow I've encountered a bunch of times that's super annoying with git.

I port/test a project to a new OS. I run into a bunch of issues, like linkers, environments, etc. that are broken that I need to fix. I try and make clean commits tackling one issue at a time, so we get 1 commit for the linker issues, 1 for the docs, 1 for the environment, etc. eventually I have 5 commits of fixes.

These fixes are all orthogonal, so ideally I want to make separate PRs and separate reviews for them. But locally they're all tied together (in chronological order), since I need all of them there to continue development.

In git I can either open 1 big PR including all fixes at once (annoying) or I can make a PR for one commit, wait until it's merged, then PR the next, etc. The only way to get them nicely separate is if I take all those 5 commits, rebase each of them onto master in its own branch and PR those 5 branches. But that ruins my ability to work locally.

The associativity of (non-conflicting) patches in a patch based VCS like Anu/Pijul means that this "ordering" of patches doesn't exist. I have 5 patches you don't, I can PR each of them independently without needing to manipulate history or anything, because fundamentally the patches aren't related and therefore there's no reason for an ordering like the git DAG forces upon you.

Of course this is a fairly niche (but hopefully concrete enough) example of how this enforced ordering of commits can actively harm workflows/collaboration.

Would forwarding continue to work if your account is disabled or terminated? That doesn't seem likely?

No, but the idea is that you can point the domain at a new host and at least keep receiving future email, so that you don't lose the ability to password reset accounts, etc.

As for

I wish there was a way to pay for Google (such as Google One) and it meant Google wouldn't ban your Gmail account

There's a reason I pay, like, €50 a year for my email hosting instead of gmail's free mail. I want to be able to actually reach a human when it comes to problems with my email instead of Google's customer service void.

Allow me to shill another amazing Haskell program for general use then: https://www.shellcheck.net/

Can I wager a guess that you are on Arch?

The Arch (and some other linux maintainers) have made the decision to package all Haskell libraries as separate OS packages and install those as dependencies when you install, say, pandoc. This model of distribution doesn't really make much sense for distributing Haskell binaries, though.

There's a few reasons for this: 1) since most people don't have many Haskell binaries and the few that people use don't share many libraries, 2) Haskell packages are normally statically linked when building executables.

If linux maintainers would simply build/ship pandoc as a single static executable all these issues disappear.

Nobel winners are all over the world, regardless of when you pick, there will always be a chance it's "the middle of the night" for someone. With the current time slot that happens to be for people in the US.

They could pick a slot that's during the day in the US, but then it'd be night for someone else. What justifies the US importance to make such a change? Using the timezone of the committee as they do now seems as reasonable a compromise as any...

which would presumably to result in a higher-than-normal frequency of allocation/deallocation

Correct. Not only that, it also dramatically shortens the lifetime of many allocated objects, so the GHC garbage collector is designed for super-cheap allocation and to not be impact by large amounts of garbage. The trade-off here is that this means that the default GC doesn't work very well with very large "live sets" (although there's a bunch of tools and workarounds to make it manageable).

For example, my Haskell data processing code averages an allocation rate of ~4 GB/s, despite never going over ~10 MB resident memory or below 98% productivity.

Of course not, that'd be a violation of the GPL. They ship their own fork/patched version of bash, whose source is on their open source page: https://opensource.apple.com/source/bash/bash-118.11.1/

peer review at CS conferences is normally anonymous and double-blind to reviewers and authors.

tbh, it's really not, this is extremely rare (although increasing).