skilltheamps @ skilltheamps @feddit.de

Posts

2

Comments

105

Joined

2 yr. ago

Those 15-25c difference exist to drive the heat energy from the radiator into the air. If one would want to not waste as much energy for this, the actual solution would be to use a bigger radiator that can dissipate the same heat energy per h while being lower temperature. That would need way less additional material and be way more efficient than building another harvesting machine.

There is a lot of bogus "science" out there, and this is part of it.

You need a temperature differential to harvest electric energy. You also need a differential to get heat energy to flow (usually from inside your apartment to outside). If you have that differential, you do not need an AC, you just open the window. If you do not have a differential (or if it points the wrong way, i.e. outside is hotter than inside), you need an AC + energy to create that differential, that lets thermal energy flow from your room to outside. There's no "free leftover differential" in this, the differential it creates is literally to transport heat energy = why you have turned on the AC. Every bit you use of this differential for harvesting energy, you could turn down the AC a notch and have it save more energy than you could possibly harvest.

This idea is as mute as mounting a wind turbine to your electric car to "harvest" the headwind from driving

Heat pumps (like AC units, fridges, etc) become less efficient the greater temperature difference they have to pump the heat. So pumping heat from a 25°C room to a >100°C steam engine would become terribly inefficient. It would need more energy, which creates more environmental damage and climate crisis to source, and that energy heats the cities even more.

The only sane way to cool cities is to get rid of as much concrete and asphalt as possible (especially the vast amounts of ground that is covered for cars), and keep only narrower sealed paths for small individial transport like bikes. Plaster everything with trees and grass and other greens. They cool down the city dramatically and are able to take up the water that comes down at extreme weather events.

Escaping the urban hellscape cannot be achieved by building more stuff and throwing more energy at it. Just visit a park in your city and observe how the temperature changes, it is that simple. Mobility cannot seal all surface area, it has the be minimal, i.e. narrow paths and trains with rails that can also run on open ground / green areas. This implies of course not building secluded areas for living, shopping, working etc.. It has to be a mix, where commutes are short (i.e. like european cities, not american ones).

But it should not need write access to those files.

I bet it is due to different UID. Nextcloud runs with the www-data user, and UID 1000 is likely whatever user OP set up on the host machine. Make Duplicati run with the same UID as nextcloud and it will have the permission to read the files.

Use a systemd-service + systemd-timer. You can then run "systemctl start myjob.service" to check that it runs as you expect. If it works "systemctl enable --now myjob.timer" to kick it off as scheduled

I built a small tool that does that for me now and published it: https://feddit.de/post/2909288 maybe you'll find it useful, no guarantee that it doesn't break something though :D

I only keep track of the sha256, compose happily uses those. I published the tool https://feddit.de/post/2909288 :)

I think problems that turn up with time are also things like dependencies moving on, people with a slightly different setup which unfortunately breaks the thing or at least surfaces bugs, or that the author doesn't even use the software anymore because it was hardware specific and they have other hardware now etc... Yes they are not obliged to anything, that's what I think too. I was more thinking in the direction of taking some precautionary measure that makes the project stay more useful (and maybe more maintained) when the original author has long abandoned it.

Ahhh that looks very interesting! It seems to commit on actuall maintaining the projects that make it in there, hence of course trying to keep the number small and only letting relevant high quality projects in. That's of course more than gifting ownership of a project to the public for somebody to grab, but a rather nice concept nontheless!

I like your second point, and already started polishing the thing more than I would have for just my own purposes. It's a good way to make it easier for somebody to take it on in the future. And it's also a measure that the original creator more likely has the will to implement while focusing on building the thing, i.e. before they moved on to other things. Also for my current project I try to keep it simple. It may not be the prettiest, most configurable or universal tool. But it has a short code and minimal dependencies. Thank you for your comment, that made me think about how traits like this can become very valuable for others.

Your first point I do anyways, and the third I'm not sure about yet. Maybe documenting such things as issues preserves them decently.

Do you do some sort of versioning/snapshotting of your services? I'm on the compose route as well, and have one btrfs subvolume per service that holds the compose.yml and all bind-mounted folders for perstistent data. That again gets regularly snapshotted by snapper.

What leaves me a bit astounded is, that nobody seems to version the containers they are running. But without that, rolling back if something breaks might become a game of guessing the correct container version. I started building a tool that snapshots a service, then rewrites the image: in compose.yml to reflect what ever the current :latest tag resolves to. Surprisingly, there doesn't seem to be an off-the-shelf solution for that...

The learning curve of NixOS is also what keeps me from trying it out, hence I prefer the "take it or leave it" mantra of the immutable fedoras, and try to keep the amount of packages I have rpm-ostree layer on top minimal.

As for Distrobox, yes there's ways it can fail, altough that happened rarely to me. What happens mostly is that the distro inside distrobox goes kaput because that's just what mutable distros beared with a plethora of questionable tooling installed with "curl something | bash" does. But for me that's the point of distrobox: separate all that shady cruft one may need for work/developing/etc from the host os. It's a place for messing about without messing up the computer and with it the bits that need to keep working

In my experience, not pushing it makes them want to try it themselves at some point. I guess you need to take care of their computer frequently enough, and are probably annoyed by Windows shitting its pants every time again. Don't make any drama out of it, just point out how ridiculous it is that Microsoft cannot manage to build something that allows running two simple programs without breaking or nagging the user so often. They know that you use something else with which you're happy with, and at some point they will become curious and ask wheter they can have it too. At that point do not promise much, say that it works a lot better but is also a lot different and sometimes a bit quirky. Do not rush it now, let them simmer in their curiousity. At a fitting occasion tell them very briefly about foss and how it is not a closed thing pushed by a corporation onto individuals to funnel data. When they ask if they can try it, tell them they can but it takes a bit of getting used to. Buy a new SSD, and safely store the previous storage in a anti static bag, exclaiming that everything is on there and cannot get lost due to linux. Set everything up with a dead easy DE, give clear tour of how stuff works. With this tactic, they want to get it to work by themselves, and are prepared to learn that some things work differently. It becomes an adventure that is totally revertable if it doesn't work out. In contrast to when you want to force the change and they use everything as a reason to be unhappy about it.

I don't know to what extent you got molested by the prophets of immutable distros yet, but I can only recommend to join the cult. Install Fedora IoT (or CoreOS) and simply know that you'll get a working container host (powered by podman) with every update. The whole discussion about which distro might survive whatever massacre the respective package manager commits next becomes superflous: You simply get the next image that was built upstream solely to serve containers. The whole package-udpating-shengiangs is done by other people for you, you only collect the sweet result. The only "downside" is that one has to become familiar with containers, but since you run docker already that should work out. Also for stuff like tinkering with the latest tools, just put those in a distrobox. That way they are indipendent from your solid container host, and you can mess them up in whatevery way you fancy and dispose them without any traces left behind.

Edit: To give one more example why this is awesome: It wouldn't even matter which one you install, you can just rebase to the other (IoT lives in the fedora-iot remote. silverblue, coreos and the others in the fedora remote. Just for anybody who might be confused by only looking at ostree remote refs fedora)

Ahh that's very helpful! I made a cron job to scan regularly as a bandaid solution before...

I once wrote an interpreter for a subset of the java bytecode in python. The jvm being a stack machine allowed me to store its state in IPFS and reference past states by their hash, i.e. you get a blockchain of execution states. It worked for a hello world program and was slow as fuck.

Uhhh then it looks again like in X

There are also WordPress plugins that allow for exports of static html. Of course you need a theme without comment sections and all that jazz, as that is disfunctional in the static export anyways.

Are you sure you selected the correct mount point? You can also give it the partition directly

One of Germany's public broadcasting services also started running an instance for anyone part of the federal media network: https://ard.social/about

Translation:

ARD.social is a basis for ARD's appearances in the #Fediverse network, an amalgamation of various platforms and projects. Regional and nationwide brands, broadcasts, programs and institutions of the federal media network can create profiles at ARD.social. The Mastodon instance ARD.social is operated by Norddeutscher Rundfunk (NDR).

Also the Tagesschau, which is the most important television news show in Germany, is there.