takluyver

I'm on Android rather than Apple, but I could install the HVV app on my UK phone and buy tickets using my UK card with no particular difficulty. Maybe other transport associations are more difficult, but I'm not sure why they'd want to make it hard for me to give them money.

> I speculate [fork] isn't common, or at least it isn't required for ordinary desktop apps.

From a science perspective, the ability to fork is really convenient for parallel processing. Load some data and then fork a pool of worker processes, and they can all read almost free copies of that data. This is much easier than setting up shared memory. It's a bigger deal on an HPC machine with 128 cores than a laptop with 8 cores, but even on a laptop it's a significant point in favour of Linux.

Getting rid of it in Linux would also be going against Linus' rule that the kernel never breaks userspace.

I believe the kernel OOM killer only fires when you're completely out of memory. But it's not unusual for swap thrashing to make the system unusable before that, forcing the user to either try to kill a likely culprit by hand, or hold down the power button.

systemd-oomd (and earlyoom, which Fedora used for a couple of releases before switching) try to detect that you're running out of RAM before the system becomes unusable, and kill a big memory user. It periodically killed Firefox before I bought some more RAM, which was a pain, but less of a pain than hard-rebooting the laptop.

The plans for Fedora to do this are public pages:

https://fedoraproject.org/wiki/Changes/EnableEarlyoom https://fedoraproject.org/wiki/Changes/EnableSystemdOomd

> I'm not entirely convinced this is a big deal since you're usually pretty hosed if you've installed a malicious native app anyway.

This specific restriction is part of a more general push for sandboxing, to limit the damage one app can do. It's probably not massively useful against actually malicious apps, because they'll probably just declare they need arbitrary filesystem access anyway. But it should be beneficial when honest apps have security flaws.

That's broadly true, but I suspect it's a bit more difficult, at least on Android. Updating the operating system involves the company making the device (at least it used to, I'm not sure if that is changing), and it's much slower to roll out than an app update. I don't know if the extra bits like 'Google Play Services' have the necessary access to e.g. read private data from a messaging app.

As the OP is pointing out, the simple alignment of one platform with one app store is also a bit blurred. Neither Google nor Amazon control Windows. You can install the Amazon store on other Android devices. No doubt Samsung (and some other manufacturers) are trying to do their own marketplaces. And it's conceivable that in the future, they're forced to allow more competition (e.g. something like Steam for phones).

I would generally agree, but this puts a lot of trust in whoever is running the store: if Google/Amazon/Microsoft/Apple build and sign every application, they can quietly modify the code. It wouldn't necessarily be easy for even the developer to know that this was happening.

Agreed. Of course it's possible in theory for every developer to have their own secure, reliable auto-update mechanism. But it's not easy - the docs of The Update Framework describe some of the challenges.

If every app handles its own updates, that also means that either you've got N background auto-updaters running, or the check has to wait until you run the software - and potentially get exploited by a hole patched in the update it's just downloading.

Malware certainly exists on the Play store, but when Google spot it, they can unilaterally remove it. IIRC, they also have the ability to remove it from devices where it was already installed. The app store model probably also delivers security updates to legitimate apps more effectively than every developer managing their own distribution.

My parents are also very cautious with what they install on Windows, and I think that's a pretty good approach. But it's pretty clear that plenty of people aren't so paranoid, and it's not always easy to tell a dodgy site from a legitimate one.

I think this could be done without being too obnoxious: 'We try not to send emails to people who're not interested - click here to confirm that you still want to get this newsletter'.

It doesn't have to be every month - each time someone reconfirms their interest, you could wait longer before asking again.

I guess the issue is that a modern web browser is a sandboxed application runtime which also happens to function as a document browser. It's been going in that direction for a long time (since webmail became common), and there are real advantages of the browser as a platform for applications - it's cross platform by default, and it has pretty good sandboxing.

So probably the most you can hope for is that we split the document part of the web from the application part, so that it's easier to make a viable document browser. But it's not clear what advantage this offers for anyone who's not trying to make their own browser. Security is probably much simpler for the document browser, but the logins and sensitive data you care about securing are probably in the application browser anyway. And we've spent the last 20 years blurring the lines between documents and applications (think of a Github issue page, for instance), so even if it was possible to access information as a pure document, there would be advantages to looking at it in an application browser.

People object to the massive effort it takes to create or maintain a browser engine which can practically browse the modern web. We're down to 3 players now actually trying to do this (Mozilla, Google, Apple). It conflicts with the idea that you can fork software if you dislike what it's doing, because even starting from existing code, it would be a lot of work to keep up with changes so you don't get left behind.

So people imagine splitting off a simpler web, where the main focus is on reading documents, rather than interactive applications, and browsers could be much simpler. But it's pretty hard to see how this could actually work in practice.

There are quite a lot of people working on better packaging (look at the Python discourse forum, for instance), but this is not really a topic that Guido has got involved in, at least in the time I've been paying attention.

But with or without a BDFL, one packaging tool to rule them all is a pretty tall order. The needs of a package like scipy, which incorporates C & Fortran code, are pretty different from something like requests. And different communities using Python have their own entrenched tools and techniques. It takes more than someone saying "Foo is officially blessed" to shift that, even if everyone respects the person saying that.

Flit is definitely opinionated, and not suitable for every use case. As Carreau hinted, I think its bigger impact will be from the specifications, especially PEP 517, which it helped to prompt, rather than people using Flit directly. The specifications mean it's practical to make new tools which interoperate nicely, without having to either wrap setuptools or carefully imitate its behaviour.

Flit isn't (mostly) a wrapper around other tools - it has its own code to create and upload packages. This was one of the motivating cases for the PEPs (517, 518) defining a standard interface for build tools, so it's practical to make tools like this without wrapping setuptools.

(flit install does wrap pip, however)

Poetry does much more than Flit, like resolving dependencies, creating a lock file, and managing an environment where you can run your code. In particular, Poetry is meant to support application development (where you want to have a fixed version of your dependencies) as well as library development.

Flit is more aimed at being the simplest possible thing to put a package on PyPI, if that's all you want to do. It expects you to list dependencies in pyproject.toml manually.

You're thinking about malicious apps, where the developer would just request all permissions they can. But sandboxing is also about limiting the impact of security issues in apps from honest, well meaning developers who (hopefully) won't request more permissions than they need.

E.g. if I make a chat app, and it has a bug that lets someone send you a malicious message and execute code in the app, then a sandbox is a really good thing.

The developer also sets the default permissions - in principle, the user can change these before running the app. Of course, not many users will do that, but there are still cases where it can make a difference.

Yup, it's a classic catch 22. Sandboxing doesn't really work without developer cooperation. But there's little incentive for developers to work on it in apps that are easy to get outside the sandbox - or when it's easy to get extra permissions in a Flatpak.

The upside of having the system draw file dialogs is that file dialogs from different apps look consistent, rather than getting out-of-place dialogs depending on what toolkit the app used. It might sound silly, but it's a real annoyance, and there are plenty of apps that don't implement any custom preview.

In some cases it does request permissions when you try to do things. E.g. sandboxed apps without full filesystem access can open & save files through a 'portal' - the system presents the user with an open/save dialog, and the app gets access to the file or folder they select. Things like screen sharing can work similarly - the system asks the user to approve access for the app.

But, as other people have said, this involves new APIs. In the open/save case, the app has to request that the system display a file chooser instead of drawing its own. GTK & Qt can hide this change so apps built on those toolkits benefit automatically. But beyond really self-contained things (like games) most apps that haven't been developed with a sandbox need some adjustment to play nicely within a sandbox. And making changes depends on building a consensus that it's worth doing.

> Debian successfully packages a ton of Python software, notorious for its complicated dependency graphs.

I guess this depends on your definition of success, but from my perspective as a Python developer, it doesn't really. Most Python software I'm aware of encourages users to get it by other means (e.g. pip, Anaconda, containers), and anecdotally, the majority of users seem to do so. The occasional people who use apt cause frustration 'upstream' when they report bugs in a version that's 2 years out of date.

One package which I help maintain upstream had a security flaw with a CVE, left open in the Debian package for many months after we fixed it. No-one upstream is a Debian developer, and no-one in Debian was updating the package.

Python started out with a traditional model of applications sharing libraries, and is now moving in the direction of self-contained applications with separate dependencies. Languages like Javascript and Rust went straight for the latter model, so are probably even less amenable to Debian packaging.

The specific problem of syncing bookmarks is probably solvable with an extension. But the move suggests that Google doesn't view Chromium as something that people will use directly, like they're not interested in people using open source Android without their proprietary components. If they gradually make more and more pieces Chrome-only, it will get harder to make a relevant browser by forking Chromium, because there will be more to reimplement before people consider using it.

And, of course, that makes perfect sense for Google. Chrome is no longer the scrappy insurgent. It's the king of the hill now, so it can start putting the fences up against competitors.

I think a lot of Android apps use Sqlite as well. But the achilles heel of Sqlite in my experience is network filesystems - it's well known & documented that Sqlite can suffer corruption on NFS, because of issues with locking. That doesn't really matter for iOS & Android apps, where you know storage is local, but it's a serious sticking point for desktop applications, where e.g. NFS home directories are not unusual.

They didn't abandon the technological effort that went into Rust & Servo - they just decided to bring it into Firefox piece by piece under the name 'Quantum' rather than launching a brand new browser with a different name. Although there was a marketing push with Firefox 57 when the new code started to land.

On some level, Firefox has to 'beat' Chrome in order to get/keep a significant level of marketshare. It needs people to see it as better in some way if they're to choose to use it, especially on mobile where Chrome is the default.

For some of us, it still 'beats' Chrome on some kind of principle - I'm not giving Google yet more control. But are there enough people like me to actually keep a modern browser going?

I periodically see sites broken in Firefox until I turn off uBlock and/or Privacy Badger - including issues with paying like you describe. But I've always assumed that the same would happen in Chrome if I had the same extensions installed there. This seems more like 'locking out people with adblockers' than 'locking out Firefox', even if there's substantial overlap.

The Mozilla foundation owns the corporation, so it's not 'run by shareholders' in the normal sense. Any profit it makes stays in Mozilla. I think they set it up like this because some things are legally easier to do as a for-profit corporation than as a non-profit.

If there was some big central fund to pay for CI for many open source projects, it would probably be for-profit companies donating much of the money to support that. Is that much different to for-profit companies making in-kind donations of free build time?

You might hope you'd get a broader pool of companies paying in to the fund, so you're less dependent on any one company. But unless the donors throw almost infinite money at you, you would soon need to make some kind of restrictions on which projects can benefit and how much they can use per month.

The best I can think of to do is to make your CI config a relatively simple wrapper around generic tools, so it's easy to move when you need to. This is often a trade-off with things like parallelism and caching, but at least if you know it's a trade-off you can make sensible decisions.

I'm talking about setting up the infrastructure before you get to either of those points. I don't want CI running on my laptop - especially for an open project where anyone can submit a merge request - and I don't have a server to use for it, let alone a private Gitlab instance ready to import projects to.

What was the better option? Should small OSS projects have lived without CI for the last few years? Or should everyone who publishes an OSS project set up and maintain a self-hosted CI service for it? Either option would be a massive drag on OSS development.

It doesn't actually matter much for this if you use an OSS CI service like Gitlab: the hosted service is still dependent on the generosity/marketing of the company hosting it, and switching to self-hosting is much more effort than porting config from one CI service to another.

The PSF's tax returns are published on python.org, and 'revenue less expenses' for 2018 was just under $280k. IANA accountant, so maybe that's the wrong line to look at.