cytzol

This part is key. It shows that Apple's signing and notarising requirement isn't about money, nor is it about security. Epic broke the rules of the iOS store, and now they'll be forbidden from developing on a completely different platform, just because Apple doesn't like them.

Why not?

Apple has been pushing very hard lately to increase their 'services' revenue, by getting users to sign up for Apple Music, iCloud, etc. It makes perfect sense for Apple to force developers to jump through hoops, not because it makes the developers' lives worse, but because it gives Apple a leg up! Some examples:

• When launching Chrome for the first time, you have to opt-in to Chrome notifications, but macOS pops up its own notification telling you to use Safari instead.

• Similarly, Apple News notifications are allowed by default, but you have to explicitly opt-in to notifications from other news websites.

• Again, similarly, you'll get Apple Music adverts through push notifications, something that's explicitly disallowed in the App Store guidelines.

• System Preferences gets an obnoxious (1) badge next to it, because I haven't signed in to iCloud.

I use SyncThing, rather than iCloud Drive. It definitely benefits Apple to waste the SyncThing developers' time and money keeping up with things the iCloud Drive team doesn't need to deal with — do you really think the sort of company that pulls shit like the above would do anything different?

https://blog.charliemonroe.net/a-day-without-business/

> Anyone selling you on containers as a security measure is pitching snake oil. They are a resource allocation & workload scheduling tool.

I agree with both of these statements — and I suspect this is where it all falls down. When you put all your applications in containers, you are not done with security, no. Nevertheless, I've found great value in having one file per version per application, being able to upgrade my dependencies one-by-one, automatically rolling back in case of failure, and taking advantage of the tools in the container ecosystem. With all that, the security features such as isolating filesystems and network ports are just the cherry on top. Before containers, I was thinking about how to give my applications limited filesystems to work with, but along came Docker, and I didn't have to think about it anymore, because I'd already done it.

This is why I feel so out-of-touch with many of the commenters here. I'm surrounded by people decrying containers for security reasons, I want to defend them because of the many benefits they have given me, and I think the people preaching some kind of True Security (where everything is 100% perfectly isolated) aren't taking this into account. I feel like I could take your comment — "Trusting the isolation like this is absolutely misguided" — and apply it to any part of the stack. You have to stop somewhere.

I've seen the salespeople. They definitely exist, but I don't think they're here on HN, and they're more likely to be learning than lying.

And developers making flawed assumptions? You know this didn't start happening with containers!

Could you explain what you mean by this? I'm still not getting it.

Here's the example I have in mind: I have one application listening on a TCP port, and another one listening on a different port. I don't want the first application to talk to the second application. If they're just two processes on the same machine, they can both see each other, and an attacker who manages to exploit an RCE vulnerability gets access to the port "for free"; if they're both in containers, then they can only see the ports I specify, and it's really easy for me to specify them.

This literally does seem like an additional shell of defence to me! What sort of attack would it make worse?

I'm not a container guru, but... this is obvious, right? You have to break out the container, which is an extra layer. In order to get root on the server, you need:

• Without container: application vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root)

• With container: application vulnerability (to gain access to the container) + container breakout vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root)

You make it sound like I'm missing something — what am I missing here?

Edit: are you talking about CVEs like this one (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3215)? I guess I'm assuming that a container vulnerability will give an attacker less to play with than a kernel vulnerability.

If, ten seconds after I've clicked Submit, I discover an embarrassing error in the code, or that I've accidentally committed some personal information, or I've sent the e-mail from the wrong address, or anything else I haven't thought of yet, there's nothing I can do and it's public forever.

Some would see this as an anti-feature, but I really do like using GitHub because I have the ability to go back and edit or delete my Pull Request if I spot an embarrassing mistake. I know the solution to this is "be more careful", but I still feel anxious sending e-mails to a mailing list, and calm using GitHub.

Does anyone relate?

> I was really hoping they'd take some time to address Catalina's glaring issues — its slowness, bugginess, just general sloppiness — and instead they did the opposite.

I didn't include "security exploits" in that list because of course they're going to fix security exploits, right? Especially one that they're already aware of, and can reproduce — they wouldn't just sit on it in favour of making the UI glossier, right?

Apple have just been getting so much wrong lately. This pretty much dashes any hopes I had of ever upgrading, because even if this particular flaw gets fixed by the time Big Sur comes out, there are almost certainly others that they've ignored. I expected to eventually have to grit my teeth and upgrade so I wasn't behind on security updates, but I guess that's not the case. Ugh, now I have to figure out how to mute that annoying (1) in System Preferences. I've heard they keep making it come back now.

But I have to ask myself: why this release? Why fix bugs in Big Sur, but not Catalina or Mojave? For example, the annoying bug where Mail randomly becomes the active application[1] has been floating around for years and still isn't fixed, and there are only two reasons for this: Apple is stretched too thin and can't spare the developers to work on bug fixes, or Apple doesn't care, and is simply willing to let the Mac languish, taking the reputation hit in favour of increased iPhone sales. The fact that they've overhauled the entire interface means it's not the first one — they do have enough resources to make large, sweeping changes to the OS. So I will be absolutely unsurprised if, ten months from now, I decide to upgrade to Big Sur on a whim, and a couple of minutes in, Mail pops up once more.

[1]: https://news.ycombinator.com/item?id=23359820

Honestly, every time Apple has done anything with the Mac the past couple of years, they've screwed it up. The infamous keyboards that they doubled-down and then tripled-down upon (I have personally had five keyboard replacements). The way Catalina sends the hash of every binary you run to Apple. The built-in Catalyst apps that look ugly and feel out-of-place. The Touch Bar which I still, years later, inadvertently activate several times a day (I've had to remove all the buttons on the right), which they addressed by making mandatory. The recurring bugs and kernel panics that have been lying around for years, unfixed.

I have the least confidence in Apple I've ever had. I'm afraid to run Big Sur, not because it changes things, but because it's Apple who are behind it.

I've been trying to advocate for a "solar system model of services", where you have a big core application in the middle (the sun), surrounded by helper services of various kinds. Your important business logic can be left alone, but the database, other data stores, functions, timers, queues, integrations with third-party systems, one-off jobs, and other things can all stay in orbit.

There are benefits that you get from multiple services that you don't get from a monolith: having to rely on service discovery instead of hard-coding addresses or passwords, being unable to assume that the server your code is running on will live forever, and requiring a concrete CI-CD pipeline to get your code up-and-running are all good things to have, no matter your model, so it's important to have a clearly-defined process for them. A service-oriented architecture can give you that — put down the pickaxe, you don't need to split the monolith in two.

This isn't progress. This is the baseline. Apple have gone from bad to OK, and they're celebrating as though they've achieved something amazing.

I've seen database programmers rave about the speed benefits of asynchronous I/O, because they have to store a lot of data on disk. But the majority of programs I write only have to deal with reading files. I'd love to try using io_uring, but only when it's appropriate.

This is part of Google's attempt to de-prioritise the URL. Their destructive AMP service confusingly shows you Google's domain instead of the website's — and as they can't fix that without losing out on tracking, they're trying to change what the URL means.

Thanks for ruining the Web, Google.

But over time, something changed, and I’m now a big fan of autocomplete interfaces. There was something wrong with my initial assumptions, and I think that’s the same assumption you make when you say this:

> i can type “empty()” on the keyboard faster than I can look at a screen and choose “empty()” from a list

You’re right, I can type ‘empty()’ faster than selecting it from a list. I have the muscle memory already there, and I don’t need to stop and look and think about which method I’m autocompleting.

The reason I still use autocomplete is not that I need my IDE to tell me that there’s an ‘empty’ method there as if that’s something I don’t already know, but to tell me that my assumption that ‘myVector’ has an ‘empty’ method is correct!

I occasionally write code like this:

    auto myVector = someFunction();
    if (myVector->empty()) { 
        fillVector(myVector); 
    }

Once I started programming this way, having the window appear was not ever a distraction, because I expected it to appear. In fact, the only distraction was when it stopped appearing, when I’ve made a mistake!

You're affirming the consequent! The author isn't saying "Only people who have been using Macs for two decades won't blink at this".

But this means that anything that's not represented in telemetry gets completely ignored. The numbers won't show you how many of your users are pissed off. They won't alert you to the majority of bugs. They won't tell you if you have a bloated web application that's stuffed full of advertising. They won't tell you if your UI is incoherent.

I really do think that large companies are looking at the numbers instead of actually using their software, and the numbers say that everything's fine.

I love the work of professional typographers, but tend to stay away from commercial Web fonts, because they like to include very restrictive terms in the font licences.

For example, you're only allowed to back up Klim fonts once, which we all know is no backup at all (https://klim.co.nz/licences/web-fonts/):

> You may make one (1) copy of the Web Fonts for back-up purposes only.

And I hope you don't take a week-long holiday away from your computer:

> At Klim’s request, You agree to provide an audit to confirm the Web Fonts You are consuming match Your Sales Receipt. Klim will give You at least 5 business days’ notice to complete the audit.

The Commercial licence is a bit better, but doesn't let you subset the fonts, which means your fonts might be 5 to 10 times as big as they should be, giving your users a worse experience (https://commercialtype.com/licenses/web):

> 10. You may not modify, adapt, translate, reverse engineer, decompile, disassemble, or alter, the Webfonts, the Font Software or the designs embodied therein.

I recommend using fonts under the SIL Open Font License, where you don't have to worry about this crap.

Anyway, nice work! I've been meaning to learn Svelte, and your site looks really good.

The one that got me was when a search result pointed me to a site that was something like:

    example.com/?ipaddr=10.3.4.3

    example.com > ...

This is the point. If you've ever viewed an AMP site using Mobile Safari, you'll still see "google.com" in the Location Bar, instead of the site's own domain name. Google's fix for this is to try to kill the URL.

(In fact, it leaves my favourite solution out: using the derive_more crate to auto-generate From implementations for the ? operator to use. From is a general trait, useful for far more than error handling, which is probably why it's omitted here.)

I agree that we should have these debates — but on a "is this language acceptable for my use case" level, not a "is this language acceptable for any use cases" level.