So, just finished this month's Repair Cafe in #Regina.

There's a depressing pattern where small #appliances, typically #kitchen stuff, fail after just a year or so. The warranties are invariably one year. Nobody, especially the manufacturer, offers service - "Just buy a new one, it's cheaper" is the refrain. Of course, we're trying to "reduce, re-use, recycle" and keep this stuff out of the #landfill.

Even trying to service them is a pain, and sometimes impossible. The cases/shells of modern stuff are frequently absolute b*stards to take apart, and really new stuff now features "one-way clips" - there's literally no way to unclip the shell after it's been clicked together at the factory. You can't access the latching bit, so you have to force it and break the #clip, and then #bodge it back together somehow.

Mandating a longer #warranty, like in the EU - two years, three? - would help, because stuff would have to be designed better.

The two most frustrating from today:

1) A Keurig coffee maker, used twice, a year old. Got it apart, it had leaked water onto the back of the (massively #overcomplicated) CPU board, and shorted it out. Poof, magic smoke gone, tears in the rain, time to die, etc. Who puts the CPU directly under a join in the #water pipe?

2) A gas-powered leaf blower. Fuel line rotted, but to be able to feed new one through from the carburetor to the fuel tank, you have to take the shell apart - which requires disassembling the engine!

#RepairCafe #SK #EWaste

#Decentralized #Module #Federation #Microfrontend #Architecture

I'm working on a #webapp and I'm being #creative on the #approach. It might be considered #overcomplicated (because it is), but I'm just trying something out. It's entirely possible this approach won't work #longterm. I see it as there is #onewaytofindout. I don't recommend this approach. Just sharing what I'm trying/#investigating.

How it will be #architected: [https://positive-intentions.com/blog/decentralised-architecture](https://positive-intentions.com/blog/decentralised-architecture)
Some #benefits of the #approach: [https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure](https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure)

I find that #modulefederation and #microfrontends to generally be #discouraged when I see posts, but I think it works for me in my #approach. I'm #optimistic about the approach and the #benefits and so I wanted to #share details.

When I serve the #federatedmodules, I can also host the #storybook statics so I think this could be a good way to #document the modules in #isolation.

#Cryptography modules - https://cryptography.positive-intentions.com/?path=%2Fdocs%2Fcryptography-introduction--docs

#P2P framework - https://p2p.positive-intentions.com/?path=%2Fdocs%2Fe2e-tests-connectionstatus--docs

This way, I can create #microfrontends that consume these #modules. I can then #share the #functionality between #apps. The following apps are using a different codebase from each other (there is a #distinction between these apps in #opensource and #closesource). Sharing those #dependencies could help make it easier to roll out #updates to #coremechanics.

#P2P chat - [https://chat.positive-intentions.com/](https://chat.positive-intentions.com/)
#P2P file transfer - [https://file.positive-intentions.com/](https://file.positive-intentions.com/)

The #functionality also works when I create an #Android build with #Tauri. This could also lead to it being easier to create #newapps that could use the #modules created.

I'm sure there will be some distinct #test/#maintenance #overhead, but depending on how it's #architected I think it could work and make it easier to #improve on the current #implementation.

Everything about the #project is far from finished. It could be seen as this is a #complicated way to do what #npm does, but I think this #approach allows for greater #flexibility by being able to #separate #opensource and #closesource code for the #web. (Of course as #javascript, it will always be "source code available". Especially in the age of #AI, I'm sure it's possible to #reverseengineer it like never before.)

(mastodon might not be the place for something like this, so let me know if you dont like this kind of content. i typically post on reddit and would like to shift it more towards mastodon. i also use lemmy, but mastodon has a better reach.)

My (current, hopefully short-lived) kernel development setup:

* Kernel searching: grep
* Kernel studying: Vim
* Kernel hacking: Kate
* For creating patches: diff
* For creating *real* patches: git
* For creating *real* patches WITH changelogs!: sometimes Vim, sometimes Kate, sometimes nano
* Email viewing: Half-broken configuration of Thunderbird
* Email sending: Mutt
* Email composer: nano
* For sending patches to my boss: Element

Yes, it actually works. Yes, I need to make something better.

#linux #kernel #development #programming #overcomplicated
#mess