521–530 of 538 posts
Earlier quoted context omitted.
Im here to push you towards Mint. mint is cleaner ubuntu. the wifi drivers work. the UI is really good. it just works.
Im here to push you away from secondhand distros use: ArchLinux NOT Manjaro Debian NOT Ubuntu etc And so on, the 'originals' work always better in the long run.
Earlier quoted context omitted.
I tend to agree with you, but I really like updating all my software with one click/command. So out of curiosity: My application is already self contained and statically linked, so no AppImage needed, but it behaves like one, you can just run download and run it everywhere. And so what you're describing will be for sure an option for those who like it (in fact currently it's the only option in alpha). How would you l…
Personally, I rarely think about updating my software unless there's a new feature I need or a fix for a bug that's been ruining my life, so just visiting the website when to check for new versions is fine by me. However, you could also include a facility to manually check for updates and either self-update or just show the changelog. Why manually? "I know you're about to do this thing real quick that needs to get do…
Earlier quoted context omitted.
> The next problem is ... how do I ship updates? ...why not make a new release and ship that? That's the way package managers work . Developer makes a package. User installs the package. Then when developer fixes some bug and releases a new version the user can install the new version when the user decides it's necessary. The whole point about this is that it's user-centric. That's good.
It’s largely a good thing but it’s unreasonable not to mention the “flood of bug reports about issues that have since been fixed” effect that comes with manual updates. This has burnt a few projects pretty badly (especially where distros have packaged an old version and never updated it).
Earlier quoted context omitted.
Im here to push you away from secondhand distros use: ArchLinux NOT Manjaro Debian NOT Ubuntu etc And so on, the 'originals' work always better in the long run.
Manjaro exists because people want a freaking installer.
Earlier quoted context omitted.
There are way more offenders here. But snap is the most egregious one because it's not hidden. Name and shame: * docker (~/.docker) * Arduino IDE (~/.arduino15) * GNURadio (~/.gnuradio) * IPython (~/.ipython) * FreeCAD (~/.FreeCAD) * HPlip (~/.hplip) * IntelliJ and others (e.g. ~/RubyMine[year]) * Cargo (~/.cargo) * Audacity (~/.audacity-data) * PGAdmin (~/.pgadmin) * ELinks (~/.elinks) * NPM (~/.npm) * sqlmap (~/.sq…
SSH is the most annoying because I need it installed on literally everything.
http://sergeykish.com/openssh-config-in-xdg-directory
And it is easy to make own repo. There are quite a lot of unofficial repositories https://wiki.archlinux.org/index.php/unofficial_user_reposit...
Earlier quoted context omitted.
> Except that Ubuntu actually doesn't shit itself almost every time you add a 3rd party package/repo and comes with reasonable defaults. I'm using debian testing for more than 15 years and it never shit itself for a 3rd party repo. Debian comes with whathever the original software developers set as the default sans the wallpaper. For sensible default you can bug the software developer in question, not debian.
Maybe the situation is different on the server side or I've just been extremely unlucky, but I keep getting my packages broken. Just a few days ago I was installing Wireguard on a Stretch system (added unstable repo, lowest priority, pinned packages) and APT got tangled up to the point where I couldn't install almost anything because one package was too new, but trying to remove it went down the dependency tree all t…
To add unstable packages to a stable system with repo pinning and using apt directly is not the best practice though.
If I'm going to add stuff from unstable, I use aptitude. Its dependency resolution and solution suggestions are better and more manageable than ordinary apt. It allows you what's going to happen before actually pulling the trigger.
The only package I get from unstable is firefox. I add the repo, update the package and remove the repo afterwards because unstable and experimental are highly chaotic realms and not suitable to use continuously due to high rate of uncontrolled change. Also unstable and experimental are not guaranteed to not to break. Testing and stable are implicitly (testing) and explicitly (stable) is guaranteed to work.
With this recipe, I only had to re-install a Debian system once; to migrate it from 32 to 64 bits since a very big disk cache with very small files was triggering a bug causing disks to trash and system slow down to a crawl. There were no procedures to migrate a 32 bit system to a 64 one in a reliable manner so, I just reinstalled it.
Earlier quoted context omitted.
You can patch it all. If world does not match your view it may be you who is outlier. I quite like current convention - hidden files in $HOME belong to applications. There is value in $XDG_CACHE_HOME - it can be safely removed (like /var/cache). You force your view on open source community, that is rather bad.
> You can patch it all. As I said, impractical, not a solution. > If world does not match your view it may be you who is outlier. Looking at the amount of software that does follow the base directory specification, actually you're the outlier insisting on obsolete conventions. You and a bunch of other developers insist on those things, in reality that is the actually harmful behaviour for open-source. Interestingly b…
You shame software, half of it has workaround, see patching as impractical.
XDG Base Directory Specification [1] is not about your home folder. It is about default storage, separation of cache, user data and config, a way to provide another config, so one can:
* remove entire config when stuck with a problem
* remove cache, think /var/cache
* `ssh -F foo` would be `XDG_CONFIG_HOME=foo ssh`
Everyone has a pain point, everyone has a workflow, there is no One True Way. Please stop shaming authors, they quit, sometimes post it here about mob. Patching folder structure is the simplest thing. If you can't do that who is going to fix actual bugs?
[0] http://sergeykish.com/openssh-config-in-xdg-directory
[1] https://specifications.freedesktop.org/basedir-spec/basedir-...
Earlier quoted context omitted.
> You can patch it all. As I said, impractical, not a solution. > If world does not match your view it may be you who is outlier. Looking at the amount of software that does follow the base directory specification, actually you're the outlier insisting on obsolete conventions. You and a bunch of other developers insist on those things, in reality that is the actually harmful behaviour for open-source. Interestingly b…
Lets check. I tolerate both versions, use workarounds in my .bash_profile and share them, actually tried to patch and have written article [0]. You shame software, half of it has workaround, see patching as impractical. XDG Base Directory Specification [1] is not about your home folder. It is about default storage, separation of cache, user data and config, a way to provide another config, so one can: * remove entire…
If one feels that talking about a bug in their software is "shaming" them, then maybe they should quit or alternatively, just quit pretending they want feedback or to write FOSS. Same applies to teams writing software.
Not to mention how harmful it is to think that everyone who picks up FOSS is actually good at it. Thinking people as infallible is actively harmful for the end users.
> Patching folder structure is the simplest thing. If you can't do that who is going to fix actual bugs?
Incorrect folder structure is an actual bug. It might be simple to patch for the end user, but you're ignoring the maintenance burden, annoyance and cumbersomeness.
> Everyone has a pain point, everyone has a workflow, there is no One True Way.
There are paths more correct than others, some workflows are obsolete and stupid, and should't be catered to. It's wilful ignorance to ignore that.
> half of it has workaround
Bwahahaha, you may think that's fine, but I don't.
Earlier quoted context omitted.
Lets check. I tolerate both versions, use workarounds in my .bash_profile and share them, actually tried to patch and have written article [0]. You shame software, half of it has workaround, see patching as impractical. XDG Base Directory Specification [1] is not about your home folder. It is about default storage, separation of cache, user data and config, a way to provide another config, so one can: * remove entire…
> Please stop shaming authors, they quit, sometimes post it here about mob. If one feels that talking about a bug in their software is "shaming" them, then maybe they should quit or alternatively, just quit pretending they want feedback or to write FOSS. Same applies to teams writing software. Not to mention how harmful it is to think that everyone who picks up FOSS is actually good at it. Thinking people as infallib…
> Name and shame
> they should quit
That's why I've called it harmful - choice between your complains and people writing code is obvious. Fork it, patch it, there is no burden - if people care maintainers would switch, if switched enough patch would get in upstream. Or provide own repository with patches, that's FOSS way. If not by yourself than sponsor.
How much do you actually care? How much would you pay? Is it free as speech or free as beer?
Earlier quoted context omitted.
> Please stop shaming authors, they quit, sometimes post it here about mob. If one feels that talking about a bug in their software is "shaming" them, then maybe they should quit or alternatively, just quit pretending they want feedback or to write FOSS. Same applies to teams writing software. Not to mention how harmful it is to think that everyone who picks up FOSS is actually good at it. Thinking people as infallib…
Your words > Name and shame > they should quit That's why I've called it harmful - choice between your complains and people writing code is obvious. Fork it, patch it, there is no burden - if people care maintainers would switch, if switched enough patch would get in upstream. Or provide own repository with patches, that's FOSS way. If not by yourself than sponsor. How much do you actually care? How much would you pa…
Without the rest of the context and no, criticism is not harmful. If it is a "sin" like you say, should we look at things you've said about FOSS projects?
> Fork it, patch it, there is no burden
Either you're delusional or you haven't done either of the things.
> if people care maintainers would switch, if switched enough patch would get in upstream or provide own repository with patches, that's FOSS way.
Yeah, and it'll take the next decade, being optimistic. GPU acceleration in Chromium and Firefox on Linux is a perfect example how absolute shit that "way" is.
> How much do you actually care? How much would you pay? Is it free as speech or free as beer?
Feel free (as in freedom) to just type out your arguments instead of asking rhetorical questions.