[-] skilltheamps@feddit.de 24 points 3 months ago

I encourage you to go to town with whatever crazy setup you come up.

I just want to note that the reboot-to-update mechanism also has its positive sides, as ancient as it may seem (we do not succumb to windows level backwardness, because that fails to reap the benefits despite requiring so many reboots). Namely, you get atomic updates, hence the name "fedora atomic" for example. That means you have no transient periods where your OS is running in an inconsistent state. Like when you update a traditional distro, the new files/libraries/binaries/kernel-modules do not match anymore what is in RAM, including the currently running kernel. That leads to stuff like the nvidia driver / cuda not working until reboot, running applications failing to load a library they need now etc.. The vast majority of times this is no huge problem, but in theory the only way of maintaining a system with it never running in basically undefined state is with atomic udpates.

[-] skilltheamps@feddit.de 21 points 4 months ago

And the firmware inside that rp2040 is stored on plain old flash memory. So while the data may still be on the memory chip, the controller chip dies at just the same pace than every other usb drive - and then you can't access it.

[-] skilltheamps@feddit.de 55 points 4 months ago

The problem is not the EU demanding that, it rather is Apples blatant incompetence at implementing it

[-] skilltheamps@feddit.de 35 points 4 months ago

Research what happened to Upstart, Mir or Unity. It won't take long until snap becomes one of them. Somebody at canonical seems to desperately obsess over having something unique, either as a way to justify canonicals existance or even in the hopes of making the next big thing. Over all these years they never learned that whatever they do exclusively will always fall short of any other joint efforts in the linux world, because they always lack the technical advances, ability/will to push it for a prolonged time and/or the non-proprietary-ness. So instead of collaborating like every serious linux vendor, they're polluting their distro with half-assed, ever changing and unwanted experiments. They're even hijacking apt commands to push their stupid snap stuff against the users intent. With the shengians they're pulling Ubuntu cannot be relied on, and with that they're sabotaging their own success and drive away any commercial customers that generate revenue.

[-] skilltheamps@feddit.de 28 points 6 months ago

You do not want Octoprint on a machine that is busy. Otherwise you have load spikes that cause Octoprint to not be able to send the move-commands (gcode) as fast as the printer executes the movements. This problem is pronounced with faster printers and slicers that break up arcs into small straight lines (which is practically all slicers). Otherwise your printer stutters because it has to take small breaks to wait for the next command from octoprint.

[-] skilltheamps@feddit.de 26 points 6 months ago* (last edited 6 months ago)

How does this part (which is what the headline refers to and presumably the most outrageous inspection finding)

At one point during the examination, the air-safety agency observed mechanics at Spirit using a hotel key card to check a door seal [...]. In another instance, the F.A.A. saw Spirit mechanics apply liquid Dawn soap to a door seal โ€œas lubricant in the fit-up process,โ€ according to the document. The door seal was then cleaned with a wet cheesecloth

have anything to do with the opening of the article

Just last week, a wheel came loose and smashed through a car, and earlier this year the door from a 737 Max aircraft broke off mid-flight

???

The article misses the whole point, which is that the audit did not uncover the sources of these incidents.

[-] skilltheamps@feddit.de 45 points 6 months ago

"overcharging" doesn't exist. There are two circuits preventing the battery from being charged beyond 100%: the usual battery controller, and normally another protection circuit in the battery cell. Sitting at 100% and being warm all the time is enough for a significant hit on the cell's longetivity though. An easy measure that is possible on many laptops (like thinkpads) is to set a threshold where to stop charging at. Ideal for longetivity is around 60%. Also ensure good cooling.

Sorry for being pedantic, but as an electricial engineer it annoys me that there's more wrong information about li-po/-ion batteries, chargers and even usb wall warts and usb power delivery than there's correct information.

[-] skilltheamps@feddit.de 29 points 8 months ago

Because it's the same story as with Mir or Upstart: it will die, because its half assed and tailored to Ubuntu, this time with dubious non-free parts even

[-] skilltheamps@feddit.de 20 points 9 months ago

Because the seemingly great choice of Webbrowsers in reality boils down to a risky monoculture of chromium (/its webengine). The only real alternative is Firefox/Blink. Risky, because the main driver behind Chrome-/ium (Google) is not acting on behalf of the public interest towards a free, open and privacy preserving internet. Instead they're working on a privacy exploiting one that gets locked down using DRM technologies. Them being a vendor of major parts of the internet as well as the browser to use it makes this a lethal combination. Firefox will definitely exist for as long as Google exists, because its their tool to defy claims of a monopoly, but they will do everything to keep it the small and mostly irrelevant "competitor" it is currently. Therefore, stand against Googles evil play and help Mozilla to gain some actual indipendence and leverage for keeping the internet free (as in freedom), open and privacy preserving.

[-] skilltheamps@feddit.de 16 points 11 months ago

We recently moved away from Trello and settled on GitLab. Might sound a weird decision at first glance, but you can just create an empty repo, create issues instead of cards and visualize them in den "Boards" view.

Key drivers for doing so were that we rely heavily on GitLab already, and that we wanted a trustworthy solution in terms of data privacy. But I guess you'd have a bit of a hard time selling this to an audience that has no experience with GitLab, so decide for yourself if its viable in your case

[-] skilltheamps@feddit.de 21 points 11 months ago

To give you an idea of what you'll experience in your self-hosting journey: adding services is the easy part, maintaining a system in production over many years is the hard part. And the self hosting solutions you mean are quite bad at that. Eventually I ditched even Proxmox because its updates are cumbersome and you never know wheter you'll end up with a working system after the upgrade.

Ultimately, you want to avoid any complex transitions in your system altogether. Decouple everything, make everything disposable, especially your OS. The ootb-selfhosting-solutions are the antithesis of that: lots of hidden magic behind colorful buttons, which makes it immensely hard to get a working setup the second something goes wrong. And that will inevitably happen with time passing.

33
submitted 1 year ago* (last edited 1 year ago) by skilltheamps@feddit.de to c/selfhosted@lemmy.world

Hello,

I moved my home servers to fedora silverblue and docker-compose (ipv6 reasons :/). I stumpled upon the problem that I neither wanted to update image tags manually, nor have no idea what ":latest" deployed on my server in case I need to roll back.

To alleviate that problem, I made a small update-tool. It takes care of writing down the image@sha256... digest every time so that you can roll back. It also automatically snapshots and restarts the services.

It is made in Python but doesn't need any dependencies, so no catering for a venv either. You only need to have skopeo and snapper in working order. Maybe you'll find it useful, but please be aware that it is in an early stage. Also I'm not responsible if it nukes your server ๐Ÿ˜…

70

I often observe that people that started a small open source project seem to abandon it sooner or later. I'm guilty of this myself in numerous cases. Reasons there are many probably, from new obligations in life to shifts in interest and whatnot.

At some point somebody comes by with an issue, or a merge request even, but the maintainer does not take care of it. Usually this ends up in forks, often though forks undergo the same fate. Apart from the immediate forks-jungle, stuff like software stores or other things might be hardlinked to the original repo, which means places like these end up with dead originals and a number of forks with varying degree of being maintained as well.

To me its just a sad situation overall. And yet I cannot find the time or motivation to maintain some stuff, because circumstances just changed. And I also do not think one is obliged to do so, just because they where nice enough to share their code when the project mattered to them.

Is there a better way? Usually these are very nieche projects, and there is not a circle of regularly active developers that could share administration of a repo, but rather a quiet one-man-show with a short timespan of incredible activity. Some kind of sensible failover mechanism once the original maintainer vanishes would probably be cool. Or any other way that introduces some redundancy in keeping a repository alive. You know how package maintainers in Linux distributions open their package(s) for adoption by somebody else if they run out of capacity? I think that is nice.

I will publish a small project soon I think, but somewhere in the future I fear to leave one or the other person frustrated again when I have moved on to other things...

[-] skilltheamps@feddit.de 27 points 1 year ago

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.

view more: next โ€บ

skilltheamps

joined 1 year ago