Former account: @Redjard@lemmy.dbzer0.com
Keyoxide: aspe:keyoxide.org:KI5WYVI3WGWSIGMOKOOOGF4JAE (think PGP key)
@reddthat.com
Former account: @Redjard@lemmy.dbzer0.com
Keyoxide: aspe:keyoxide.org:KI5WYVI3WGWSIGMOKOOOGF4JAE (think PGP key)
Kdeconnect is usually gonna go over regular wifi or ethernet. So that might go phone to ap to laptop, for twice the wifi hops.
Also means the speed is limited by the router, so modern phones would be slowed by an older access point.
Or by being far from the access point yet close together.
Your demo instance seems unable to open any other subs.
Also it redirects to an archive path which is not how redlib works and makes me question how the sesmless response regardless of state is supposed to work.
Once it dumps me in the archive for whatever reason, don't I have to go back manually? (Not that even seems possible right now)
since im not sure where in the boot process linux recognizes my raid and when the decryption happens
Usually raid and decryption happen in the initram. This is because these are too complex to sit purely in the kernel, requiring userspace tools like cryptsetup, but you want to be able to boot off of them so they have to be handled before the disk is mounted.
Usually that initram is dracut. Why dracut only partially completes the process here, likely figuring out the raid but not decryption, is anyones guess. In my experience dracut is quite hard to debug and configure.
The simplest approach is probably to just eat it and write a startup service that does it. Basically a startup command. No need to worry about timing, as when the initram finishes the raid should already be up.
There might be a prebuilt systemd service for it too iirc...
If you really wanns go for it, there are other initram systems like ugrd, which are easier to configure and might figure your setup out properly. But you'll probably have to manually install and update them. That would definitely be a very involved approach.
There are some guesses I made here on your boot timeline. If you show your dmesg I can confirm if the raid really comes up at initramfs time. But it should be s solid bet.
Earlier article mentioned it was acknowledged by high ranking amd officials multiple times over the years.
So they definitely knew.
It might have been that it wasn't documented internally and someone else removed it not knowing it was in use.
But at the latest with the initial bug report this was clear, at that point it did reach people who knew. So not undoing it, especially given the severity of the impact of silently disabling a security feature, is absolutely on amd with no excuse.
It is from a different article going deeper into it:
https://www.tomshardware.com/...
Kilpatrick then brought up something especially awkward. He reminded Lendacky of a comment that the engineer had made back in 2020, confirming that a Ryzen 3700X, a consumer CPU, “should support TSME.” In a later 2025 comment in the same discussion, Lendacky again recommended using TSME, while noting that the motherboard BIOS provider had to expose the option. So there it was, AMD's own engineer, years earlier, acknowledging the feature working on exactly the kind of lower-end chip now stripped of it, proving that Ryzen support was not some fantasy users invented.
So this engineer is openly recommending it.
is an email response stating that TSME "is a security feature only applied to PRO CPUs as part of AMD PRO Technologies," notably the first time the company has publicly stated such a restriction
amd itself never stated anything at all, one way or another.
where two AMD engineers eventually responded: Tom Lendacky, an AMD fellow software engineer, and Mario Limonciello, an AMD senior principal software engineer.
Interestingly, neither engineer appeared to have a clear answer for why the feature had disappeared.
This sort of implies both knew of it and didn't know of the specifics of the removal. But it isn't clear.
Reading it again I may havw over-remembered though, to be fair. Not as high level as I thought.
This does also mention that amd didn't "advertise rhe feature only for pro cpus". They never specified it at all, so all there was to go on was the actual cpu behavior, which did support it on all lineups. With a feature mentioned and not stated to only be present on some lineups, it's also reasonable to expect it present on all cpus.
Is "Enterprise Applications" like shooting datacenters into space, or copilot business edition?
I think the "Space-Enabled Solutions" part sounds more like designing satellites than the space-launch business.
Disclaimer: Ist Jahre her dass ich mit bioengineering und Biochemie zu tun hatte.
Es gibt bei Planzen grob 2 verschiedene Formen von Photosynthese Zyklen, bei denen am Ende Zucker rauskommt: C3 und C4
Simplifiziert läuft die hintere Kette der Umwandlung bei C3 sofort, und bei C4 in der "Downtime" also Nachts.
C4 hat hier den klaren Vorteil, dass die hinteren Teile der Kette keine Bedingungen an den Wasserhaushalt der Planze setzen, wärend diese von der Sonne bestrahlt wird. Grob arbeitet die Planze damit mit viel weniger Verdunstung, also ist viel sparsamer mit Wasser.
Mais ist C4, Weizen C3, desshalb baut z.B. der eher Aride Teil der USA so extrem viel Mais an (was dann deren ganze Ernärung fickt weil die überall Fruktosesirup reinballern müssen).
Weizen wächst dagegen in den selteneren Regionen wo viel Wasser zur Verfügung steht. Da kommt dann krams raus wie die Ukraine die quasi ganz Europas Weizen in einem kleinen Gebiet anbaut, weil da halt gute Bedingungen sind.
Also, was ist wenn ich in Weizen die komplette C4 Photosynthese Kette transplantiere?
... Zumindest viel mehr Weizen und weniger Mais, also ein fettest Plus für die Gesundheit von Grundnahrungsmitteln.
Und weniger Wasserknappheit dort wo Weizen angebaut wird.
Ist eigentlich ne ähnliche Situation wie Fleisch, wo man auch einfach ne komplett andere Planze nehmen könnte die schon C4 ist, aber das halt defakto nie tun wird.
Wenn ich statt Vollkornbrot nur noch Maiswaffeln fressen muss, geht ich besser den ganzen Schritt und entferne mich komplett permanent aus der Klimabillanz.
Anyway, ist vielleicht nicht das beste Beispiel, aber C4 Weizen schlägt auch Mais in Wassereffizienz weil das Zeug halt neben C4 noch eine etwas effizientere Planze ist. Und damit ist das schonmal was ertragreicheres als man vorher in ariden Regionen anbauen konnte.
Ist jetzt kein Kaktus, aber gibt halt ewig große Gebiete wo im Moment nur Gras für Vie angebaut wird, oder extrem hartnäckige aber wenig gezüchtete Getreide mit geringem Ertrag.
Wenn man alle potentiell relevanten Gene einsetzt müsste man eigentlich mit einigen Generationen normalerer Züchtung eine sinvolle expremierung anzüchten können.
Gibt endlose regulationsmechanismen, also sollte das hoch und runterregulieren recht schnell gehen. Ich meine ein paar der Mechanismen wären sogar "epigenetisch" (methylierungen etc.).
I could have, but the system wasn't set up to restart without downtime, and the server was also remote and not easily accessible.
It did acutally die due to a poweroutage some months later and took 2 days to get restarted.
So yeah sometimes restarting is way more undesirable than loosing access to 32GB of ram. I would have just eaten that cost otherwise until a more opportune chance to restart.
Besides, restarting to fix a problem is equivalent to giving up on understanding the issue, learning new stuff, and maybe finding a way better solution or preventing the type of error entirely.
I get not finding the motivation when your software is working against you and learning is ultimately fruitless like on windows, or not having the time in the moment to figure it out properly, but a perfectly good bug on a linux system when you have time is prime real-estate to grow your skills and find fulfillment.
Nothing new can open it immediately.
So it's effectively deleted with old references slowly phasing out.
Zombie files are an issue though. A while back I had a huge zombie file on a tmpfs which was filling all my ram. So I built a tool to track it down and traced it to a konsole instance with a killed tab that previously had billions of lines of stdout history.
https://github.com/redjard/zombie-file-list
zombie-file-list
Lists Linux files that are still opened in a process but were deleted. These "zombie files" use up space and inodes but are hard to find.
I wrote this because my /tmp tmpfs was taking up 32GB of ram despite the files inside summing to only 3MB.
Usage:
zombie-file-list <path to filesystem>Note:
- This command is designed to be run on filesystem roots, not paths in general.
- Sizes are apparent sizes, e.g. on ext4 the actual sizes are rounded up to the next 4KiB
thanks for using Leebra!
go to feed...