catiopatio

Linux seems to be doing just fine.

Accepting drive-by patches carries an enormous cost. It’s very common to need to rewrite them substantially.

Regardless, this individual received a reported-by credit. That’s more than adequate.

My assumption is that the development/maintenance/support costs aren’t worth the bump in adoption/sales they’d see from doing it.

It’s a large amount of expensive, ongoing work, and leveraging Apple’s native toolchain will invariably provide a better user experience.

That information is already available, and much of the implementation (if not all) is open source.

You’re free to produce your own toolchain, developer tools, IDE, etc.

This generally isn’t done because it’s a significant amount of work, and you’ll always be playing catch-up to Apple’s comprehensive integrated development stack.

You really, truly, cannot close all the holes necessary to prevent fingerprinting while still providing a useful general purpose OS.

You especially cannot achieve this while providing third parties access to what has traditionally been vendor-only API on mobile devices; e.g. to support third-party app stores.

This simply is not solvable through technical means. It must be solved through policy and law.

iOS isn’t as sandboxed as they claim.

From IOKit to getifaddrs() to file system APIs, there are straightforward ways to uniquely identify a device — and I’m sure someone who actually works in this space can think of quite a few more.

Hell, even if you make it a hard problem and sandbox every possible source of unique information about the device, I’m sure Google would be happy to throw ML engineers at identifying users via impossible-to-obscure user information (keyboard timings, accelerometer readings, etc).

Preventing misuse of PII requires a policy/legal solution, not a technical one.

I like the idea of local home automation. “Siri, make the bathroom lights dark blue”

Problem is, it comes with a ton of headaches.

The cloud is a problem, as you noted, but also a bunch of fiddily, unreliable software, firmware updates that go haywire, and apps that are tied to iOS and will stop working with my physically installed home hardware if the manufacturer ever stops treading water and fails to update for the latest breaking iOS update.

Home automation could be simple, reliable, and future-proof. It’s really not, though.

Why do you think fingerprinting is hard?

It’s truly not — the OS sandbox is nowhere near as restrictive as, say, a browser sandbox.

Moreover, if Apple is forced to open the platform to third-party app stores, identifying unique users in collusion with the third-party app store is incredibly easy.

The advertising ID gives users and Apple control over tracking when also coupled with AppStore policy that disallows improper use.

It’s impossible to prevent fingerprinting of users and devices via purely technical measures — taking away the advertising ID won’t help.

> Have never understood why developers haven't kicked up more of a fuss over that restriction

It’s an innate limitation, not an arbitrary restriction.

Should Apple really be forced to port their tooling — and the entire, massive software stack it’s based on — to other platforms?

I assume most developers targeting Apple’s platforms don’t kick up a fuss because they’re happy running macOS.

Weren’t those outlets even less targeted?

What countries require per-cow licenses, and of those countries, which ones wouldn’t adjust the quota upwards to meet consumer demand?

> post-iOS change

What is the iOS change you’re referring to?

Your message merely says a great deal about you and your judgement of those of us who aren’t interested in making small talk with you.

You have no wisdom (great or small) to impart while using others to assuage your need for external social validation.

It’s generally easier to carry the conversation to its natural conclusion — people tend to respond inordinately negatively to being bluntly told when others are not interested in a conversation.

As to your last question, the “why” is simple. I find small talk to be both pointless and exhausting. I prefer to be left alone, and for those with nothing to say to say nothing.

I’m neither abnormal, maladjusted, or insane, and behaving politely towards children in such a circumstance is basic decency.

Your assumptions certainly appear to demonstrate the inappropriate views many have towards those of us who do not particularly value their company.

Discord groups dedicated to gaming, anime, RPGs, furries and “femboys” top their list.

That’s both uninviting, and what I anticipated.

It also doesn’t represent a subculture that’s synonymous with or even inclusive of the broader professional OSS community.

The point is that Discord participation is not universal, and the site has a deserved reputation as being unprofessional and often more than a little seedy.

This conversation reminds me of the when people built Facebook-only communities because “everyone is on Facebook”.

The venn diagram of the so-called nerd community and OSS participation barely overlaps.

I’ve never been to a Comic-Con, I don’t play games, I don’t watch “Linus Tech Tips” — or YouTube at all — and I’ve been deeply involved in OSS for three decades.

I would react politely to your children and, if further engaged by you, continue to converse with you politely.

I would also genuinely, deeply, and silently dislike every second of the forced interaction.

99.999% of people might react the same, but that doesn’t mean we all feel the same.

Into what? It seems to remain occupied by gamers, YouTube viewers, media consumers, and other so-called “nerd” consumption-focused interests.

> a large part of the tech community has an account

Is that true? I don’t, and was under the impression that Discord was a “gamer” thing.

If you prefer to ship fragile binary file formats for no reason other than finding it too onerous to define something as trivial as an eight-byte file header, that’s silly, but nobody is going to stop you.

If you’re going to use text-based serialization formats as your justification for the decision, however, I’d suggest you look into all the fun bugs, security issues, and weird edges cases that arise from parsers having to make a best guess at character encoding and file format when all you have to work with is the file extension, maybe a byte order mark, and heuristics over the file contents.

  <?xml version="1.1" encoding="UTF-8" ?>

The others are serialization formats, like protobuf — they’re not file formats.

> It's actually the only one I've ever used, because why would you not?

Because it’s not part of the protobuf specification, not part of a valid protobuf message, and framing is a transport/file format concern and should not be performed by default.

If someone is expecting to receive a protobuf-encoded payload, it must not include a framing header.

> If your implementation doesn't support something in the reference implementation, that seems like your problem, not anyone else's.

Someone else’s failure to follow the spec is not our problem.

You stick a magic number and a version number at the top of the file and call it done. It’s trivial and buys you a great deal.

The magic means it’s possible to identify the file type. Maybe you’ll add a tool later that operates on multiple types of files.

The version means you can evolve the contents in non-backwards-compatible ways, while maintaining the ability to read/parse the old version.

It’s a pain in the ass to add a magic or version number later; there’s a reason why nearly every file format on the planet has both.

Conforming implementations will fail to interoperate with their “protobuf” serialization; it’s absolutely incorrect for them to call their length-prefixed framing protobuf.

There’s a non-default `writeDelimitedTo()` that emits a length-prefixed message.

The result is not protobuf and doesn’t claim to be.

Looking at my employer’s protobuf runtime for our major programming language, we don’t even support it.

I work on an embedded OS where our IPC buffer is only about 140 bytes.

Anything more requires multiple IPCs, with lots of expensive context switches.

Wasting even one precious byte on a pointless header would absolutely be an issue in this environment.

Framing is a distinct concern from payload serialization.

Most protocols and serialization formats already define a form of length-prefixed framing; requiring that a protobuf payload also carry such a header would simply be a waste of bytes.

Additionally, it ensures that protobuf can be serialized and streamed without first computing the payload length, which would require serializing the entire message first.

It’s absolutely an unreasonable thing to do.

You don’t conflate framing with payload by emitting invalid non-standard framed data from a “protobuf” encoder. They’re separate concerns and need to remain that way.