kixik

joined 3 years ago
[–] kixik@lemmy.ml 1 points 2 months ago (1 children)

I'm curious about which programs if you can share. I write few bash scripts which used to call sudo, and I replace sudo with doas in those. And in case of muscular memory I also added a bash alias so that if by mistake calling sudo in reality I'd be calling doas. So far no issues. O course I don't use fancy args, and what I really needed from sudo I used to include it in /etc/sudoers and now on /etc/doas.conf, and I believe I couldn't include a couple of options but they were not critical since I've lived without them so far. And it's weird to find actual software that requires sudo, perhaps proprietary software. One can actually live without sudo and without doas, as long as there's still su.

Not judging, rather curious, actually I've met several guys who write scripts which would benefit from using sudo/doas, but they claim better call the scripts through sudo/doas rather than adding them as dependencies.

[–] kixik@lemmy.ml 5 points 2 months ago* (last edited 2 months ago) (3 children)

A way smaller alternative therefore less prompt to vulnerabilities is OpenDoas found on Arch/Artix/... and other distros. From the GH project:

doas is a minimal replacement for the venerable sudo. It was initially written by Ted Unangst of the OpenBSD project to provide 95% of the features of sudo with a fraction of the codebase.

[–] kixik@lemmy.ml 9 points 2 months ago

Jami on desktop, not on phones yet:

https://jami.net/eleutheria

Available only for desktop users for now, the new Push-to-talk feature offers a new effortless way to communicate: simply press a button for hands-free, instant, and convenient audio messaging. It’s like in the olden days of gaming when gamers would key bind the Push to talk feature to be able to talk when necessary.

So jami all the way, 🙂

[–] kixik@lemmy.ml 2 points 2 months ago

There's Guix sytem running on top of linux, so you don't need to wait for hurd, :)

[–] kixik@lemmy.ml 1 points 2 months ago (1 children)

Guix is source base rolling release if you plan to keep it up to date weekly, so I don't know why you feel it so distant from Gentoo. Binaries updates are still rolling released but their pace is slower.

[–] kixik@lemmy.ml 1 points 2 months ago (2 children)

Others have already mentions gerrit, no need to review on the forge, and there's as well gitweb. I imagine there exists many other solutions much better than the forge MR/PR. Particularly reviewing PRs on github is really messy for me. Depending on how complex the review might become I end up branching to the PR branch locally and checking the complex stuff locally without the forge.

And there are many many bug trackers much better than the issue trackers. Bugzilla actually has kept improving, though I believe it might be too much for small projects, but there are many more.

I do agree with the article writer that one really needs to create too many accounts already, GH from MS, Gitlab, sourcehut.org (I really like this one better, but still you need yet another account), codeberg, gitea, and some with different instances with different accounts each... It's crazy, and now AI crawlers getting on them all, and also violating FLOSS licenses... Notice on distributed private repos it's way harder for AI misbehavior and illegal behavior to do what it does in general.

[–] kixik@lemmy.ml 1 points 2 months ago (2 children)

Well, before wayland I always used fluxbox (eventually with picom compositor, which previously was compton). Then now on wayland I'm using sway with fuzzel, yambar and others.

I've always felt both gnome and kde, as well as most other DEs really bloated. Gnome used to be more stable on wayland, and as of Today with better support for nvidia AFAIK, but KDE is quickly catching up.

Not sure why the hate on gnome (and I guess on GTK as well). It doesn't offer all the customization by default, but you can get it through extensions while available. But on KDE one really needs to see a pletora of dependencies each time one adds a simple module or application. Both are improving gradually to become less intense on resources being KDE more advanced on that.

But hey, both are bloated compared to non full DE compositors such as sway or labwc. BTW I use sway with tabbed mode (not actually tiling) and some tweaks, and I prefer that over stacking compositors, but if wanting one labwc is pretty cool.

On X11 there's a huge amount of window managers plus compositors plus several other applications which altogether can give a similar sense to a DE but way less intense on resources, and for sure way less bloated. To me DEs are overrated to answer your title, but perhaps that's just me, :)

[–] kixik@lemmy.ml 2 points 2 months ago

I know most don't care. I initially stated most people don't agree with me. This is just my take on universal packages in general. I really like and appreciate the typical shared libraries native to most distros. It's OK we disagree, I only hope we don't end up with empty shells with systemd and everything else on app stores...

[–] kixik@lemmy.ml 0 points 2 months ago

I installed liri-shell, and some other apps some time back, and totally disliked the experience. Too many duplicated stuff, which was totally unnecessary. While I can, I void universal packagers.

I'm not complaining about open source, I've been using FLOSS for so many years now. The thing with developers only supporting universal packages distributed binaries is that the build recipes might be too tight to them, or not explicitly exposing all dependencies, and several other things. I have no issues building and installing software. So that's not it. All I said was that to me closing bugs because not using the universal package supported is sort of crazy, being open source and supposedly being able to build and distribute. I didn't say I couldn't support myself.

[–] kixik@lemmy.ml -3 points 2 months ago (5 children)

I've tried in the past flatpak packages, they are terrible in many senses the proponent (vast majority AFAIK) don't say, among them:

  • They create huge static binaries
  • One gets many libraries embedded in the static libraries or local static libs to the package which are often repeated among many static binaries, even the same version of them. This is totally avoided when building against dynamic native libraries.
  • When installing a pletora of static dependencies for a package, lets say liri, a bunch of the stuff it requires might already bi installed natively in your system, but they need the static deps locally part of the package.
  • Care must be applied, there are statistics available about abuse on vulnerabilities infection on pypi, npm and so on, this no different on these packagers repos/hubs.

Good that they provide an alternative way to install packages not available in your distro repos, but for that user repositories building against native libraries are a much better option, like AUR in the case of Arch, and even their binary packages coming from other distros or from upstream might be even better than those universal static binaries providers.

There are political aspects involved in the past claim from the proponents, and it's that in their view gnu+linux echo-system should become like the windows one, where everyone company or org (to them doesn't matter) should be able to provide their binary packages, and then there's no reason to think of anyone being able to build their staff.

There's a tendency actually on providers on those hubs, to ignore problems on people who tries to build their stuff on their own, claiming they only support those universal packages. Which to me it's dangerous, since it goes in detriment to the ability to build and distribute the software, which might not be due to licenses, but rather practical reasons. This might actually be against the licenses they use, but now a day who cares, right, it's available on that packager repo...

Lastly one argument provided in favor of the apps coming from those universal packages is sandboxing. But there's firejail which can be install on most gnu+linux distributions, and comes with profiles for a pletora of apps, and if sandboxing is not enough, it can easily be combined with apparmor, or if you prefer selinux might be used... No need for those universal packages to have a sandboxed experience.

One final note, so far gnu+linux has been characterized by having a diversity, which is good, that diversity offers people options to choose from, and a lot of different solutions for different purposes. Not so long ago the claim was that it was not good, that meant fragmentation, and fragmentation is bad for adoption and maintenance. I see it the other way around, this diversity allows for choosing for what aligns better with the user intends, like easy to use, or rolling release, or as vanila as possible, or as up to date as possible, or as hardened as possible, etc, etc. Systemd is another example of this universalization intended. Perhaps some distros prefer to be a shell for systemd and get packages just from universal packages, that's bad news to me.

Of course having universal packagers present an oportunity for corps and orgs to also provide stuff on the gnu+linux platform, but in my mind the best would be for them to offer free/libre and open source software, that would build on any system and be provided by any packager that wants to offer it. Though I believe that to be too idealistic perhaps. Jeje.

[–] kixik@lemmy.ml 1 points 2 months ago

Read about it some other community, perhaps the guix one, and I was keeping it to help me in the future. It relies on nonguix repo which has its own recipes, but this one is nice. I wish I wouldn't need any binary blobs, but sadly that's not how things work. Counting on risc-v not just getting competitive hardware, but also motivating the surrounding hardware to follow.

I'll definitely need it in order to use relatively modern hardware.

Many thanks !

 

Hey !

On LOS 21, the app DeviceLockController is there, but it can't be stopped neither disable, at least from my side.

There's another one I don't trust, Android System Intelligence, but I could stop it and disable it.

Those two apps really are scary to be part of LOS. Is anyone aware of bugs on LOS about getting rid of them?

How about DeviceLockController? A reasonable way to disable it without risking too much bricking the phone in the process?

Thanks !

 

xz-5.6.1-2 from Artix system repo is already available.

Artix corresponding news: The xz package has been backdoored

 

I'm not self hosting, so I'm depending on what the server admin enables, and the policies they establish.

That said, the server fully supports xep-0313, which perhaps among other things control messages being kept on the server precisely for the purpose of sending them to all registered devices, thus allowing the sync.

But perhaps there's a policy in place removing the messages from the server as soon as some device has gotten it, leaving only online devices with the ability to grab them. I don't know if that's possible...

I experimented getting a device offline for a couple of minutes, and then exchanged messages with another account, and also to my same account. Then eventually I got the device offline, and none of the messages, not even the ones sent to myself, were ever synced on the device just coming online...

This is really sad, since that's precisely one of the benefits of having servers over peer to peer solutions, it's easier to sync devices through the server.

Might this be some sort of policy to keep disk usage on the server low?

I might need to explore some other server if that's the case...

Thanks !

Edit: Communicated with the admin, and they mentioned this was unexpected.

 

Just wondering, as the reasons to move here are gone, can the community go back to lemmy.ml? There are quite some posts over lemmy.ml, so going back there would be useful I believe, and also moving the few posts here over there would be just great (perhaps not the comments)...

Just an honest question, not to provoke flame wars or anything like it...

Greetings !

 

cross-posted from: https://lemmy.ml/post/12692350

Anyone aware of a conversations fork with support for unified push notifications? Or a similar xmpp android app with omemo (just the same as conversations' support) and unified push notifications support, available through the official f-droid repor or a f-droid repo if not available from the official ones?

BTW, I noticed !xmpp@lemmy.ml community was locked. Any particular reason for that?

Also, Converstions requests to set unrestricted use of battery, to use battery under background without restrictions. So it seems unified push notifications would help, though this github issue sort of indicates unified push notifications wouldn't help, so it just tells me there's no intention to include support for it on Conversations, but not that it wouldn't help save battery.

 

Anyone aware of a conversations fork with support for unified push notifications? Or a similar xmpp android app with omemo (just the same as conversations' support) and unified push notifications support, available through the official f-droid repor or a f-droid repo if not available from the official ones?

BTW, I noticed !xmpp@lemmy.ml community was locked. Any particular reason for that?

Also, Converstions requests to set unrestricted use of battery, to use battery under background without restrictions. So it seems unified push notifications would help, though this github issue sort of indicates unified push notifications wouldn't help, so it just tells me there's no intention to include support for it on Conversations, but not that it wouldn't help save battery.

13
submitted 1 year ago* (last edited 1 year ago) by kixik@lemmy.ml to c/fediverse@lemmy.ml
 

https://disroot.org provides several decentralized federated services, as email and xmpp, besides other cloud services as well... But not sure if asking here is right or not, but don't know anywhere to ask either...

Is it having a license issue, does anyone know about it? Any status updates?

Websites prove their identity via certificates. LibreWolf does not trust this site because it uses a certificate that is not valid for disroot.org. The certificate is only valid for p1lg502277.dc01.its.hpecorp.net.
 
Error code: SSL_ERROR_BAD_CERT_DOMAIN

But also:

disroot.org has a security policy called HTTP Strict Transport Security (HSTS), which means that LibreWolf can only connect to it securely. You can’t add an exception to visit this site.

The issue is most likely with the website, and there is nothing you can do to resolve it. You can notify the website’s administrator about the problem.

I also tested with ungoogled chromium and pretty similar thing...

Anyonea aware, and also about disroot saying on this?

Edit (sort of understood already, no issue with disroot at all): The issue only shows up under the office VPN. It seems like disroot is not recognizing the office's cert...

Edit: Solved. Yes it's the office replacing the original cert with its own, as someone suggested. Thanks to all.

 

Anyone aware of a testing framework hopefully integrating well, and abstracting the shuttle testing functionality?

BTW I found rtest, but it doesn't in particular abstracts shuttle at all, it's a fixtures generic framework.

Planning to use shuttle to do MT testing targeting C binded code, and looking for a way to abstract as much as possible the shuttle scheduler trait and such...

Thanks !

1
A COSMIC Thanksgiving (blog.system76.com)
 

cross-posted from: https://discuss.tchncs.de/post/6777822

Notable changes:

  • Tracking improvements. For example, if you use the launcher to launch an application and then switch workspaces, it will still launch in the workspace you opened it from;
  • Supported the ext-session-lock protocol, which authenticates the user and informs the compositor when the session should be unlocked
  • XDG activation and DBus activation support
  • work on HDR
  • Ongoing work to package COSMIC on NixOS: tracking issue
 

cross-posted from: https://lemmy.ml/post/11708298

Hello !

As Mint is based on Ubuntu, I’m wondering if it will follow the missteps (to me at least) Ubuntu is doing to demote *.deb packages in favor of snaps?

Well that based on Ubuntu 23.10’s New Software App Will Demote DEBs (Apparently) post, and its lemmy.ml discussion.

From all ubuntu based distros, Mint seems not to follow those missteps, but I'm wondering if Rhino will do the same. Actually I don't like Rhino created a wrapper package manager which actually gets snap support as well as apt on the same bucket. But who knows, it might be they won't follow ubuntu on this.

Does anyone know?

My interest on Rhino comes from it being rolling release. But I don't want snap to become the source of common/important packages.

Thanks !

view more: ‹ prev next ›