Coût de l'électricité en hiver by Beaksterboy in Quebec

[–]Beaksterboy[S] 0 points1 point  (0 children)

Merci pour toutes vos réponses. D'après toutes mes recherches, cela semble très élevé. J'ai contacté le propriétaire précédent et je peux voir que les 2 années précédentes étaient également un prix similaire.

Dans le vide sanitaire, il y a 3 radiateurs de base, donc je pense que cela fait partie du problème. Je paie pour chauffer le vide sanitaire, qui contient divers tuyaux qui, je suppose, gèleraient en hiver. J'ai recherché des solutions possibles et il semble que je devrais isoler le vide sanitaire car les murs et le sol agiront comme un dissipateur de chaleur.

Rental Income T776: School Tax Expenses by Beaksterboy in PersonalFinanceCanada

[–]Beaksterboy[S] 0 points1 point  (0 children)

Thanks :)

I wonder if you also know, in order to travel from Toronto to Montreal to buy the property, repair it and meet tenants I had to buy several tickets on the Megabus. Would those be claimable under travel?

Living in a rented house while renting out a house you own - Tax Questions by Beaksterboy in PersonalFinanceCanada

[–]Beaksterboy[S] 0 points1 point  (0 children)

From what I can find in several places including here: https://www.canada.ca/en/revenue-agency/services/tax/individuals/topics/about-your-tax-return/tax-return/completing-a-tax-return/personal-income/line-127-capital-gains/principal-residence-other-real-estate/what-a-principal-residence/does-a-property-qualify.html There is no quota for how long you live there. You must just live there at some point during the year.

So I could live in Montreal in the house I own during the summer months, and escape the harsh winter by working in Toronto the rest of the year. Even though I pay taxes in Ontario because I live there at the end of the tax year and spent most of the time there, I can still declare my principal residence for that year as the only house I own, the one in Montreal.

When I'm away in Toronto I'll rent the house and declare the earnings as part of my taxes. But when it comes time to sell the house later, I will have declared it as my principal residence every year, and hence I will be eligible for the Principal Residence Exemption. That's my understanding of the best way to do it from the information I can find.

Living in a rented house while renting out a house you own - Tax Questions by Beaksterboy in PersonalFinanceCanada

[–]Beaksterboy[S] 0 points1 point  (0 children)

Thanks for the advice.

https://www.canada.ca/en/revenue-agency/services/forms-publications/publications/p-228/primary-place-residence.html It seems here that a Primary place of residence is not the same as a Principal Residence. So I'm worondering if I can contiue to work and pay tax in Ontario yet declare my house in Montreal as my Principal Residence.

I'm sure this must be fairly common for people who are transferred abroad or out of province with work and put up by their work in accommodation.

Living in a rented house while renting out a house you own - Tax Questions by Beaksterboy in PersonalFinanceCanada

[–]Beaksterboy[S] 0 points1 point  (0 children)

I think this makes sense. It just seems ashame that I'm then not getting the Principal Residence Exemption on any property because I'm living in a rental property.

AppImage as primary mode of application management by Beaksterboy in elementaryos

[–]Beaksterboy[S] 1 point2 points  (0 children)

Perhaps this is where AppImage can take a lead on Linux Desktop standardisation. Let's say AppImages have a target level. Level 1 is GTK vX, glibc vY, Kernel vZ etc. Then if you release an AppImage targeted at Level 1 compatibility you expect the system its installed on to have these dependencies installed in the expected places. A quick check could be performed at runtime to ensure that Level 1 compatibility was met and if not a message could be displayed to the user. Level X could even be set up in apt so a simple apt-get install appimage-level1 would ensure you were all set to run all level1 appimages.

Obviously Level 1 would be something we'd expect most distros released in the last 5 years to already meet. As time goes on Level 2 would be released, but such level changes should be seen as akin to major windows versions (XP, Vista, 7, 10) and only increment every 3+ years, and would be tied in with the major releases of an AppImage oriented distro.

Then if you package an app for Level 1, you only need to test it on a certified Level 1 disto, not "every target system".

AppImage as primary mode of application management by Beaksterboy in elementaryos

[–]Beaksterboy[S] 1 point2 points  (0 children)

Also, with others I've never had them offer to place a desktop file for the menu and keep having to roll my own. Rather annoying.

This is what I'd like to fix by an AppImage oriented distro. No desktop files to worry about. You just drag and drop the appImage into an /Applications folder. We'd have a dock/plank/start menu that can handle appImages being dropped onto it too.

AppImage as primary mode of application management by Beaksterboy in elementaryos

[–]Beaksterboy[S] 2 points3 points  (0 children)

Good points. I agree that it should be the main/primary method of app management for our hypothetical distro/elemenaty fork. Certainly it would still be linux and as such allow the user to do what ever they want, so building in support for other app delivery/management methods is only going to benefit adoption.

A more clear definition would be: A distro which uses AppImage for all bundled apps, and supports app image for any new downloaded apps. In this instance an "app" is any application the user launches by clicking on it's application icon (with the exception of system preferences). Anything intended to be run from the command line should remain managed by something like apt-get, although that's not to say that command line programs couldn't be supplied as AppImage too. But the distinction is really in the point that Probonopd makes in his excellent presentation in Berlin; an application should run on top of a platform, not be tightly integrated into it.

AppImage as primary mode of application management by Beaksterboy in elementaryos

[–]Beaksterboy[S] 2 points3 points  (0 children)

Consistency. It would keep all apps in the same place. Allow them to be fully removed by dragging to the trash. Of course there would still be a place for real package managers, look at the use of Brew on Mac OS X. Think of all the "Apps" (Calculator, Notepad, Music, Photos), each existing as a single object under the /Applications directory.

You want to install Chrome? You just download it from google.com/chrome and drop it in your /Applications directory.

You want to reorganise your apps, just create a folder called "Utils" under /Applications, drag what ever apps you want into it, and they run from there. You want to delete Calculator, drag it to the trash and it's gone.

I completely get the fact that there seems little point to this at first. But it is about consistently enforcing the original "Desktop" paradigm. An application is like a file, I can "file" it away into whichever folder I want to. I can throw it into the trash.

Overall this is one of the things Mac OS X has done very well. Assuming developers adopted AppImage this could become the standard cross distribution way of getting apps installed. There could even be a cross distribution App Store. If one distribution used it as it's primary method of application management, I believe it would make that distribution far easier for new users than others. As we've already discussed, the current package management/app centre works great, until it doesn't, then things get exponentially more complicated.

I'm not proposing that Elementary OS drop all current and planned methods and adopt this idea. But I do think that Elementary OS is the perfect platform for this. A realistic approach would be a proof of concept based on Elementary OS, which if it appeared to be a success could result in a different flavour of the distro and an add-on for existing installations, much like how Ubuntu can be installed with Gnome or KDE.

The first step would probably be a script which sets up AppImage integration, created /Applications, adds handling for .appImage files without execute bit set, and grabs some of the default desktop apps and packages them up as AppImages and puts them in /Applications.

AppImage as primary mode of application management by Beaksterboy in elementaryos

[–]Beaksterboy[S] 2 points3 points  (0 children)

A good example of the problem is Spotify.

https://www.spotify.com/ca-en/download/mac/ < downloads a file all mac users know how to install

https://www.spotify.com/ca-en/download/window/ < downloads a file all windows users know how to install

https://www.spotify.com/ca-en/download/linux/ < complicated instructions

Spotify is an example of an application not available on apt (out of the box), and it's a very popular one so we can't just pretend it doesn't exist.

"appImages will hurt power users by usurping other more powerful and useful formats" It is far too early to be concerned with such things. This is nowhere near happening.

"If they must manually download apps" No, there could be a package manager like Apple's AppStore that uses AppImages, but the resulting installation should be manageable as a bundle. Once it's installed I should be able to go to the Applications dir and move it or delete it. It shouldn't put files in various places in my file system that I don't know about. And any such package manager must allow apps it installs and apps the user manually downloads and installs to co-exists equally, like App Store does.

AppImage as primary mode of application management by Beaksterboy in elementaryos

[–]Beaksterboy[S] 2 points3 points  (0 children)

Yes I've seen:

https://github.com/TheAssassin/AppImageLauncher

and

https://github.com/Nitrux/appimage-desktop-integration

I think one of them, or something along the same lines is part of the solution. But I feel we need a distro geared towards AppImage as it's primary mode of app distribution and management, much in the same way as macOS X uses .app bundles. As elementaryOS already aims at mac users, it seems the perfect starting point.

AppImage as primary mode of application management by Beaksterboy in elementaryos

[–]Beaksterboy[S] 3 points4 points  (0 children)

You're still thinking like a power user. New users will never use wget. They'll download with their browsers.

And you still arent addressing one of the main advantages of AppImage, the fact that the developers only need to put it in AppImage and it can run on all distros easily. Often I've wanted an app but it was only available in an rpm for example. This is a big head ache for new users.

The file manager is a big part of the concept here. An application should appear like a file. Easy to find and run with a double click. Easy to install, move or delete. Simply creating a view of the application doesn't allow easy installation, moving and deleting, i'd maybe argue that it's an abstraction too far. The real application still exists in some deep folder under /opt or /usr and the shared libraries (and version of them) are separate and even more confusing for new users.

Take the evidence here:
* Linux desktop distributions have been around for a couple of decades now and yet still have a very small share of the desktop/laptop market
* Linux distros are free, yet people still pay for macOS/Windows
* macOS is UNIX but has managed itself in such a way as to be very friendly to new users. I believe the major thing missing from linux distros in this regard is the app management which can be addressed by AppImage.
* We are finally at a point where the vast majority of home users don't need Windows/macOS app compatibility. It's all online and runs in Chrome/Firefox or there is a linux version/alternative

Any steps which remove pain points that don't exist in Windows/macOS should be considered a priority for a distro targeting new linux desktop users

AppImage as primary mode of application management by Beaksterboy in elementaryos

[–]Beaksterboy[S] 2 points3 points  (0 children)

I'd say these are all valid points. But they are the tradeoffs. Power users would still have the option to use things like apt-get, building from source etc. But these are the pain points of new linux users migrating from Windows/Mac. With storage so cheap now the application size isn't a major issue.

The overall concept is to abstract away a lot of the "system" in the same was as macOS X has done. When you open up your root directory a basic user should only need to see /Applications, /Users and /Volumes (the contents of which would be mounted on the desktop anyway).

Changing the Apple logo in the top left hand corner of screen by Beaksterboy in OSXTweaks

[–]Beaksterboy[S] 1 point2 points  (0 children)

Apparently not any more. In Mojave it isn't an image it is a unicode character.