Mortgage Plan Analyzer by RMestre

https://github.com/rjpmestre/mortgage-plan-analyzer

Project Description

Many people face challenges when trying to renegotiate their mortgages with different banks. They receive offers from multiple lenders and struggle to compare them effectively. Each proposal may have slightly different terms and data presentation, making it hard to make informed decisions. Additionally, understanding the impact of various taxes and variables can be complex. The Mortgage Plan Analyzer project aims to address these issues.

Project Overview:

The Mortgage Plan Analyzer is a web-based tool built using PHP, Laravel, Livewire, and AdminLTE/bootstrap. It provides a user-friendly platform for individuals to input basic specifications about their mortgage, adjust taxes and variables, and obtain short-term projections for each proposal. Users can also compare multiple mortgage offers side by side, enabling them to make informed decisions about their mortgage renegotiation.

Why Start This Project:

I found myself in this position and most tools I found around are either for marketing/selling purposes or not flexible enough. As i was starting getting lost in a jungle of spreadsheets i thought I could just create a tool to help me and others that may be experiencing the same struggles to provide clarity and transparency in the decision-making process.

Hackweek 25 ideas (to refine still :) )

• Euribor Trends in Projections
• - Use historical Euribor data to model optimistic and pessimistic scenarios for variable-rate loans.
• Use the annual summaries (installments, amortizations, etc) and run some analysis to highlight key differences, like short-term savings vs. long-term costs
• Financial plan can be hard/boring to follow. Create a simple viewing mode that summarizes monthly values and their annual sums.

Hackweek 24 update

• Improved summaries graphs by adding:
• - Line graph;
• - Accumulated line graph;
• - Set the range to short/mid/long term;
• - Highlight best simulation and value per year;
• Improve the general behaviour of the forms:
• - Simulations name setting;
• - Cloning simulations;
• - Adjust update timing on input changes;
• Show/Hide big tables;
• Support multi languages (added english);
• Added examples;
• Adjustments to fonts and sizes;
• Fixed loading screen;
• Dependencies adjustments;

Hackweek 23 initial release

• Developed a base site that:
• - Allows adding up to 3 simulations;
• - Create financial plans;
• - Simulations comparison graph for the first 4 years;
• Created Github project @ https://github.com/rjpmestre/mortgage-plan-analyzer ;
• Launched a demo instance using Oracle Cloud Free Tier currently @ http://138.3.251.182/

Resources

• Banco de Portugal: Main simulator all portuguese banks have to follow ( https://clientebancario.bportugal.pt/credito-habitacao )
• Laravel: A PHP web application framework for building robust and scalable applications. ( https://laravel.com/ )
• Livewire: A Laravel library for building dynamic interfaces without writing JavaScript. ( https://livewire.laravel.com/ )
• AdminLTE: A responsive admin dashboard template for creating a visually appealing interface. ( https://adminlte.io/ )

---

Save pytorch models in OCI registries by jguilhermevanz

Description

A prerequisite for running applications in a cloud environment is the presence of a container registry. Another common scenario is users performing machine learning workloads in such environments. However, these types of workloads require dedicated infrastructure to run properly. We can leverage these two facts to help users save resources by storing their machine learning models in OCI registries, similar to how we handle some WebAssembly modules. This approach will save users the resources typically required for a machine learning model repository for the applications they need to run.

Goals

Allow PyTorch users to save and load machine learning models in OCI registries.

Resources

---

Create openSUSE images for Arm/RISC-V boards by avicenzi

Project Description

Create openSUSE images (or test generic EFI images) for Arm and/or RISC-V boards that are not yet supported.

Goal for this Hackweek

Create bootable images of Tumbleweed for SBCs that currently have no images available or are untested.

Consider generic EFI images where possible, as some boards can hold a bootloader.

Document in the openSUSE Wiki how to flash and use the image for a given board.

Boards that I have around and there are no images:

• Rock 3B
• Nano PC T3 Plus
• Lichee RV D1
• StartFive VisionFive (has some image needs testing)

Hack Week 22

• NanoPC T4

Hack Week 21

• NanoPi M4B
• Radxa Zero

Resources

• https://en.opensuse.org/Portal:Arm
• https://en.opensuse.org/Portal:RISC-V

---

New migration tool for Leap by lkocman

Update

I will call a meeting with other interested people at 11:00 CET https://meet.opensuse.org/migrationtool

Description

SLES 16 plans to have no yast tool in it. Leap 16 might keep some bits, however, we need a new tool for Leap to SLES migration, as this was previously handled by a yast2-migration-sle

Goals

A tool able to migrate Leap 16 to SLES 16, I would like to cover also other scenarios within openSUSE, as in many cases users would have to edit repository files manually.

• Leap -> Leap n+1 (minor and major version updates)
• Leap -> SLES docs
• Leap -> Tumbleweed
• Leap -> Slowroll
• Leap Micro -> Leap Micro n+1 (minor and major version updates)
• Leap Micro -> MicroOS

Hackweek 24 update

Marcela and I were working on the project from Brno coworking as well as finalizing pieces after the hackweek. We've tested several migration scenarios and it works. But it needs further polishing and testing.

Projected was renamed to opensuse-migration-tool and was submitted to devel project https://build.opensuse.org/requests/1227281

Repository

https://github.com/openSUSE/opensuse-migration-tool

Out of scope is any migration to an immutable system. I know Richard already has some tool for that.

Resources

Tracker for yast stack reduction code-o-o/leap/features#173 YaST stack reduction

---

Enlightenment in Leap 16 by simotek

Description

Get the Enlightenment stack + X11 building and running on the Leap 16 codebase.

Goals

• Get enlightenment / terminology compiling for Leap 16
• Test that they are running correctly in a Virtual Machine.

Resources

---

Digital art wallpapers for openSUSE Leap and Tumbleweed by lkocman

Description

We've enrolled set of new wallpapers to both Leap 16 and Tumbleweed as part of https://news.opensuse.org/2024/10/26/leap-tw-get-makeovers/

We've previewed digital art wallpapers which were not part of the initial drop. I'd like to spend time on hackweek to finialize my current Taipei (mountains) and Mauritius digital art wallpapers.

Goals

Finalize existing two digital art wallpapers for Leap and Tumbleweed https://github.com/openSUSE/branding/issues/155 Make them available as part of leap16 dir in https://github.com/openSUSE/wallpapers and update (This makes is available to Tumbleweed users as well). Update https://build.opensuse.org/package/show/X11:common:Factory/wallpapers-openSUSE-extra && Leap:16.0 && Factory.

Resources

https://github.com/openSUSE/branding/issues/155 The mauritius draft can be found in https://github.com/lkocman/geo-wallpapers

---

YQPkg - Bringing the Single Package Selection Back to Life by shundhammer

tl;dr

Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.

See section "Result" at the bottom for the current status after the hack week.

Current Status

See the development status issue at the GitHub repo.

tl;dr: It's usable now with all the key features.

It does real package installation / removal / update with reasonable user feedback.

The Past and the Present

We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.

You can search packages based on name, description, "requires" or "provides" level, and many more things.

The Future

YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.

Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?

For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.

But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.

The Idea

YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.

For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.

For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.

Preparatory Work: Initializing the Package Subsystem

To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?

Yes, it is: That part is already working:

https://github.com/yast/yast-ycp-ui-bindings/pull/71

---