*removed externally hosted image*
Plugins may introduce some risks imo. Non-standard behaviour may be a b*tch.
E.g. the idea of a plugin which posts tags:
How are these elected and shares across instances? And displayed on clients? Are they modifying the actual data written by the user in order to sync?
Maybe they are attractive to admins. But they can mostlikely already query and modify the database, right?
I do not want to be against it just mentioning that it may introduce problems on its own which in turn needs to get adressed. E.g.: When multiple plugins do a task at the same hook; How is the ordering managed? When are transactions committed? Should there be a maximal amount of time spend on plugins at some hook? How are resources shared then?
Let's think about bad actors: Meta deploys provides a plugin which compresses and decompresses post content and saves plenty of ressources for the admin. After a couple of years they put it to the grave or change the compression methods such that old posts cant be retrieved. But their instance surely still can access those.
I admire beeing lean. Had some projects where bad plugins raised in popularity and become the defacto standard. But they were resource-hungry and badly written or barely maintained. Workarounds spread back to the original program.
Just looked the first time into the lemmy code and it appears to be very neat and clean. I would recommend to stick to it. But then I am no maintainer and a nobody shrugs
//edit: To me plugins are good to aid customization and enlarging the user base. I do not see how this contributes to the fediverse and instances in the long run.
OpenAI is just a mask of Satan. Apple is just a contender for hell and doesn't run things there. Yet.
Congratulations to all involved!
Instead of a install skript, check out GNU stow. It does exactly that and you can interqctively choose which things to install/symlink.
The gpu is fully supported to my knowledge.
Congratulation to the KDE team! Well done!!
Sorry to hear! I really want to say it again: The manhfacture has to support linux officially. Otherwise there are things not mentioned in the documentation and the maintainers are working nonstop across multiple repositories to make it work.
Thinks of the top on my head not listed in the wikis:
These issues are somewhat mentioned. So I do not want to nitpick. Instead contributed some solutions/hints for things I was able to infer. So please don't hate me. I'm new.
Got this one. I like it but support is really rough. Not officially supported but they are helping somewhat the motivated guys getting it upstream. Was advertised with 28 hour battery life as well. You can get 12 hours in linux, less in windows.
Peformancewise it is flawless. The weight is awesome. Very comfy on the lap. But its almost two years and very much is missing.
If the new generation doesn't have official linux compatibility I would not recommend buying it on release.
command --git-url https://... --alias myalias --svn-url http://... --alias mysvnalias
You may process it as a stack.
When reading within the program from stdin I recommend a state machine.
Meanwhile blindly installs it because its "free for now".
I use OpenBoard and never had any issue.
Exactly.
Depending on the upstream guidelines (check for a CONTRIBUTION file) you may open a MR with your initial development efforts. And reuse the branch until you have finished the feature. Then you request a review.
Or you may first mention your branch on a issue and only create the merge request once the entire feature is developed.
If you are developing another feature, use a dedicated branch.
In any case, the author merging may elect only specific portions of your change.
Also note that it is perfectly normal that a merge request will be open for months. So don't be discouraged. There may already be people profiting from your change. You just don't see it.
A merge request isn't a git thing; It is an extension of some platforms. If you continue developing on the same branch as the mergerequest was issued for, github and gitlab will list your commits within the Merge Request once you have pushed them to your remote.
If you do not want this, you can simply branch off after issuing your merge request.
Came here to say this. They earned their success. Hopefully their current values remain.
People like the meme creator will turn the tides around. Perfectly crafted meme.
Very nice to hear!
The F2 version enables one to directly call scripts by e.g. issuing sh myscriptfrompath.sh
. Or start a program within a terminal: st -e top
.
The F3 version wouldn't accept these.
My usage is 95% of the time F3 - and I am a sw engineer. So very specific reasons.
I am really glad you liked it and prompted your question. I was playing for hours until I simply dragged away the categories 😅😃!! Now it is preserved :)
Man. I bought Lenovo ARM. I wanted to buy a tuxedo so badly. Now I'm stuck with this thinkpad.