Contesting or radiosport has been around for a long time in amateur radio. There are lots of contests throughout the year. Contests essentially involve making contacts with other amateurs. There is usually some sort of exchange that validates that a contact has been made. Different contests have different scoring. Amateur radio has a lot of aspects to it and some people love the contesting aspect. Some aren't into it at all.
Summits-on-the-Air, Parks-on-the-Air, and others involve going out and operating a portable station (the activator). The reason why parks are a good place to operate is that they have open spaces, trees, etc that are good for deploying antennas. You also don't generally need permission like you would with a school field for instance. Operating portable is great for people that live in an apartment or condo where they can't put up an antenna.
The emergency aspect is having the gear and practice for operating portable like one might have to do in an emergency.
In the end, it is about fun and using your equipment and skills in different ways.
They ruined it when they moved it to Java. I get why (no one wanted to learn Objective-C before the iPhone), but it decimated so much of what was great.
I was a big SY fan in high school (early 90s). I would watch parts of "1991: The Year Punk Broke" almost every day after school. I have never been good at music but I tried to get into guitar. Evidently, learning to play guitar by trying to play with SY guitar tunings doesn't make it any easier. SY was a huge influence on my formative years.
Though it can fall back to SMS in case you don't have data, which isn't E2EE. I'm not sure what the UX flow is like in that case, whether it warns you and asks for permission to send over less secure channel.
I was under the impression that this is a 'proprietary' extension between Google devices, and that there was no RCS-standard-based E2EE:
> The RCS specification defines several types of messages. Our implementation of E2EE uses varying strategies for encrypting each type of message to maximize user privacy while still adhering to the RCS specification.
How is that related? Encryption doesn’t really protect against malicious payloads being sent. Quiet the opposite actually as they can’t be scanned / stripped on the server.
iMessage or android messages? iMessage is E2E by default, unless one or more parties own multiple apple devices, in which case apple stores an encryption key on iCloud and maintains E2EE connections with every connected Apple device. This changes if you turn on Advanced data protection-- then iCloud no longer has the ability to decrypt messages. Somewhat unrelated but ADP is off by default as most customers do not want or need this.
Android Messages, the competitor to iMessage. The parent claimed that Google resists encrypting anything so they can mine your data. I was merely trying to ask for accuracy. I don't know the technical aspects of every Google messaging app but as the other responses in the thread confirm, Messages is end to end encrypted by default for non-SMS messages.
I just checked and Google does have a Messages app, different from the Messages app on my phone, probably by Samsung, which deals with SMSes. According to Play it has 1B+ downloads so it's probably preinstalled.
Anyway, the competitor of iMessage and Messages is WhatsApp. Nobody is sending me SMSes except banks so even iPhone users use WhatsApp to send messages to friends and to groups in my country. If somebody would insist using only iMessage they would be out of the loop. And about Messages, well, I don't have that app, I receive no SMSes, I still communicate with everybody so I guess that nobody uses Messages too.
iMessage is E2E even without ADP, even with groups and multiple devices. The details are complex, but they are publicly documented here[1]:
The issue (I think) you are referring to is that if you enable iCloud backup[2] or iCloud for Messages[3] (both of which move effectively move the storage of the messages to the cloud, either as part of the device backup or as the canonical representation that devices sync from respectively) then the messages decoded on device will be stored in blobs that iCloud has the keys to unless you enable Advanced Data Protection.
That would be probably 100% of the iOS users that I know, including my entire family. Everyone's got an iPhone, iPad, Apple Watch, Macbook etc. It's such a nice ecosystem, so it's hard not to get hooked.
I don't see it that way. The main need for change detection in my opinion is to remove the need to update parts of the DOM in an imperative manner. It is fine to do that for smaller projects but when a project gets large, it becomes difficult to reason about the myriad of changes happening without a system to handle that. I find any one of the examples in the linked post way more easy to reason about than manual DOM updates.
Having worked extensively with the major frameworks in multiple orgs, I have largely found that templates synced with state via change detection (like Angular) result in more readable/maintainable projects.
While I personally like React, it's pretty tricky to use in reality. I have found that its idiosyncrasies make it less resilient to suboptimal contributions from engineers that are still early in their careers.
Broadly, the projects I have entered using React tend to be pretty wild, messy and unreliable.
There is cross over though, Angular projects using Redux (ngrx) are horrific. The criticism of Angular for me is the lack of control you have over the compiler, dependency versions and testing strategy.
Svelte and Vue are both interesting, but they use custom file formats (.vue, .svelte) which can add an extra layer of unreliability to projects using TypeScript and testing frameworks.
The advantage of Angular is that it's an ergonomic abstraction that allows optimisations to occur at the engine level. It's more like an ORM, where React is more like writing SQL queries directly.
I’ve only ever touched React as a “so and so needs a hand on this bug” or “we want this feature added to legacy while the React team works on the new version”, so I was already going into a codebase that had long been abandoned in all but usage.
That said, it was a nightmare. I think we had state managed by vuex, and I just needed to add a new data point to the component and display it. But the data needed to be added to state…so I think I touched 6-7 files, adding mutators and updating definitions etc.
The experience put me off of React, though I do imagine a lot of that comes down to how the code is initially structured and maintained. It’s clear that whatever they were doing was more “make it work now” and it so much worrying about the future.
If you haven't I recommend having a look. If found it amazing for maintainability.
You have to be carful to structure everything well. If not you blow up the number of messages in one file. But once you get past that it's really amazing.
Yeah I have, personally I like it but the issue I have found was that I am not the only one who works on projects.
> You have to be carful to structure everything well.
This essentially sums it up. I can be careful, but it's impractical to review code to ensure it's also structured correctly when working on a team with lots of contributors with varying experience levels.
In my experience, It's also more difficult to teach MVU than it is to teach templating with automatic reactivity.
I agree with you that going back to the JQuery days of unmaintainable imperative code would not be a good thing.
But with JQuery I was able to create adaptive UIs by applying 'transforms' to the DOM, I really miss that.
Think of the way that 'tag helpers' can apply cross-cutting transforms to Razor Page applications, I used to do things like that with JQuery.
React et al cuts me off from both the browser DOM and it's own virtual DOM, so this I can no longer do this.
I have to do everything the React way.
Developing with React is far less powerful than JQuery.
I still find modern frameworks to be a kind of straight-jacket.
I hope to have my transforms back in a rational way someday.
In the presentation today, Apple specifically mentioned connecting to your macOS device as a seamless experience. In my opinion, this will be another "content consumption" device like an iPad that integrates with macOS devices and is not a replacement for them.
For now. I actually see them moving to this if it takes off both for battery life and computing. Them even labeling it as a spatial computer, shows there positioning this to be their future.
I write React but don't look at the docs much so I am not familiar with all the changes there. The basic concepts of React haven't changed much over its history. Hooks are newer than class components, etc but class components still work. Hooks have been out since 2019 so they aren't exactly new (and they were in the old documentation). React itself has been quite backwards compatible.
The Javascript ecosystem tends to have lots of flux with new libraries and ways of doing things coming out all the time. I have found React to be one of the most stable libraries around. I can update versions of React and my code continues to work as before. Libraries that I depend on tend to have more issues with this and version updates can mean changes in the API for the library or a newer version of React not being supported.
My suggestion for someone learning React would be to start with the simplest way of getting started and learn React before learning concepts brought in with frameworks, etc. If I were to start learning React today, I would start with Vite.
In the end it's all state -> view -> interactions -> state -> view -> interactions.
Svelte does it most simply though. I've been doing React for years now, but it still feels ridiculous to me compared to Svelte and others.
I honestly think people who like React have Stockholm syndrome. And everyone is taken hostage since it's the most popular one. UseEffect is ridiculous, hooks in general are ridiculous, mapping over array to create elements is ridiculous, having no tools out of the box for JSX to do simpler if else, for loops, etc. All these bizarre concepts just to hack around JS to make all of it work. And in the end it's all very difficult to read and reason. And all this bizarre boilerplate is just tech debt. It does nothing to describe what is actually going on in that component.
React is a lot better than what came before it (Angular 1, Backbone, jQuery), etc. And I think it's longevity is in large part because it hit the "good enough" where the frameworks ceases to be a major barrier to productivity.
The newer frameworks (Svelte, SolidJS, etc) definitely seem to improve on React. But it will take some time for the wider ecosystem of libraries to catch up (and ideally for one of the newer frameworks to establish themselves as the next-gen "winner)
Summits-on-the-Air, Parks-on-the-Air, and others involve going out and operating a portable station (the activator). The reason why parks are a good place to operate is that they have open spaces, trees, etc that are good for deploying antennas. You also don't generally need permission like you would with a school field for instance. Operating portable is great for people that live in an apartment or condo where they can't put up an antenna.
The emergency aspect is having the gear and practice for operating portable like one might have to do in an emergency.
In the end, it is about fun and using your equipment and skills in different ways.