Deprecating Core and Supervised installation methods, and 32-bit systems

Yes, in the June release, which contains the code for it.

Thanks. But do you actually remember what the text says? I don’t remember it.


2 Likes

Thank you.

That would be enough to alert any user and have them running to the blog.

If this type of notification wasn’t even possible in May, then I get it. Either way, what’s done is done. This is just something for the next time a major deprecation happens.

1 Like

That system would need to be built… It doesn’t exist.

I’m talking about the notifications that already exist.
The one that Francis just posted.
All I’m saying is, that this notification just needs to happen earlier, before the feedback period has ended.

1 Like

my guy, i understand what you’re saying. You aren’t understanding what it took to get that very pointed notification in the system.

There is no delivery mechanism for future deprecations.

No matter what way you look at this, a feature request is required before the feature is used for a future deprecation.

1 Like

Okay, I think I understand you.

It seems that during the feedback period, since the decision has not been solidified, they were not going to push that text yet.
It sounds like this deprecation notice is a one-time, tailor made for this particular deprecation.

In that case, I think a feature request is certainly warranted for a general alert/notification delivery system.

My original post, with the hitchhiker’s meme… Only illustrates that a real notification system is needed, rather than people stumbling upon this blog.
It’s funny, because the deprecation notice that people are getting now, is kind of like Arthur running into the bar.

2 Likes

You’re thinking of this in terms of just “text” showing up on your dashboard. There were many code changes put in place to target the correct systems. They aren’t going to put out a deprecation notice to non-effected users. As it stands, there’s already people seeing the blog post thinking it affects HAOS. A blanket notification to all users would just create a ton more unnecessary conversations.

A good feature request would potentially be some sort of mechanism that could target systems with specific attributes like installation type, integrations, etc. However that would require people to Opt In. Hopefully you can see the irony in this…

3 Likes

Agreed. I don’t think I came across as suggesting a blanket, blunt force notification. Certainly not on the dashboards.
With the great work done on the current repair notifications, there’s obviously a set of checks and criteria for integrations that are installed as well as the versions and installation method. There’s a lot of good data available before a repair notification pops up. Otherwise every user would get every repair possible notification. That’ll be an ugly bug.

1 Like

Yes but those repairs are built directly into the code as the result of code changes or a past decision/deprecation.

You’re essentially asking for the chicken before the egg. You want code changes about future things before the code changes happen.

I understand that. It would require new code built-in directly to check a new system built into the version checker.
So in addition to what it does currently, it would have to fetch for critical alerts and notifications.
I get that. It would be new and would need to be developed. And will require a feature request.

With so many operating systems and other major software projects having a system of general alerts about future code changes, like major revisions or deprecations… And home assistant pretty much being its own OS (HAOS)… I kind of see this as a WTH opportunity.

1 Like

It’s not. This notification is purpose built on architecture and installation method. The only way to build something (sensible) this generic for a random future criteria, would be to act on your system information being pushed to the cloud. Which is an opt-in feature, so it wouldn’t have helped anybody in this thread, since everyone is claiming to have analytics turned off.

4 Likes

OK. Another pissed off user here.

I found this was going to happen because of the message in the repair sections of the settings, once the decision was already taken.

I understand the “community driven” approach of requesting feedback in the forums, but as I suppose many of us have a life and checking the forums on something that is just working doesn´t make sense to me.
Beside this, the “if you want you can continue using it but we will not support it” doesn’t sound “that” community driven to me.
I know any one can fork the code and start maintaining it, but - come on - really? This is another answer you can find in this topic.

As others have stated, first thing I do with whatever I install is to disable telemetry, so I’m not sure you are accounting for my installation.

After a thorough revision of different installation methods, I decided to use supervised because it can manage the add-ons and can be installed in a generic semi-old notebook as long as it support Debian 12. It is definitely the most flexible installation in terms of easy to install, managing of add-ons and supported hardware (HAOS is not quite there yet). Not to mention low power usage running with lid close.

Only thing I can say now. Please reconsider. HA is a GREAT product and you have done a GREAT job so far. I have recommended HA to anyone asking me about home automation.

3 Likes

You likely won’t need to fork anything to keep it running. You’ll just need to learn a bit more about how to manage linux and it’s dependencies without official documentation from HA. Someone will need to read the code to figure out dependency changes for supervisor if you choose to update the supervisor.

Another pissing of answer. I know linux. I know and work with containers. But to me the promise of HA has been I don´t need to learn how to “update the supervisor”

Someone need to read the full posts. If you want to reply the please address it in complete form.

My man, your tone is not appreciated. If you want to reply, you need to taper down your aggressiveness. This is not a suggestion, this is a requirement.

2 Likes

I think you misunderstand.

Nothing needs to be sent to the cloud other than the standard version check ping. Even without telemetry, HA still fetches information about what update versions there are available.

The current repair notifications happen without sending the opt-in telemetrics. It does all of its checking locally.
I’m saying that a feature request would just extend this capability to also check for and fetch all critical notices, then filter locally based on what’s installed and relevant.

2 Likes

I’ll assume you’re joking. Or trolling.

If neither, then review the Blog post. It’s a longer version of the repair message.

First of all. My apologies. Maybe translation error (my first language is spanish).

That said, suggesting “someone” go and read the documentation doesn´t feel friendly to me either. I was paraphrasing your response.
My point is, my post (the first one) reflect my frustration about some responses.
As I said, GREAT work, GREAT product. Not sarcasm. I really mean it.