Just in case you are wondering why I do quote posts relatively often:
I use friendica to be able to communicate with people in the diaspora network and people in the the activityPub network. These are not compatible - so activityPub folks can't communicate directly with diaspora folks and vice versa.
Friendica is able to communicate with both.
By using quote post functionality my intention is to to share something I've seen in one of the two networks with the folks of the other one. This works in both directions. People still can't directly communicate with the original authors due to the network barrier, but with friendica I can simply do reshares this way. In my opinion this is an awesome use case for quote posts
#quotePosts #activityPub #diasporaProtocol #Diaspora #Friendica #Fediverse
I use friendica to be able to communicate with people in the diaspora network and people in the the activityPub network. These are not compatible - so activityPub folks can't communicate directly with diaspora folks and vice versa.
Friendica is able to communicate with both.
By using quote post functionality my intention is to to share something I've seen in one of the two networks with the folks of the other one. This works in both directions. People still can't directly communicate with the original authors due to the network barrier, but with friendica I can simply do reshares this way. In my opinion this is an awesome use case for quote posts
#quotePosts #activityPub #diasporaProtocol #Diaspora #Friendica #Fediverse
like this
Started a little journey... running a debian vm installed with systemd and later on switching to OpenRC. The basic steps are done - /sbin/init is not a symlink to systemd's binary anymore and system booted successfully with OpenRC. Sadly runit is not yet well supported enough by debian to be pid 1 - but OpenRC is a very nice one, too
I'm excited - have to figure out a few things now... like network scripts, etc.
#init #linux #debian #openrc #sysvinit #systemd
I'm excited - have to figure out a few things now... like network scripts, etc.
#init #linux #debian #openrc #sysvinit #systemd
This entry was edited (1 year ago)
like this
Thanatos reshared this.
Felix Tiede
in reply to Rebeka Catalina • • •Rebeka Catalina likes this.
Rebeka Catalina
in reply to Felix Tiede • •Thanks!
Aldo
in reply to Rebeka Catalina • • •Rebeka Catalina
in reply to Aldo • •Thanks, I know. I'm a Gentoo user
Aldo
in reply to Rebeka Catalina • • •(((Dirk Weber)))
in reply to Rebeka Catalina • • •Rebeka Catalina
in reply to (((Dirk Weber))) • •Well... I think on desktop it's totally ok to use systemd. On my desktop machine I use archlinux and I have no problems so far with systemd on that machine. On one of my servers I recently switched to Debian with systemd and had an issue. It could be solved, but I must say it is something that I dislike.
At boot time the v4 address got assigned and systemd reported "network is up" so the machine continued with boot process - nginx came up and was configured to listen to v4 and v6 - but v6 was not assigned yet. Again: There's a way to solve this, but... I really dislike this behavior.
That I now decided to try out to run debian with OpenRC is, because I thinking about to run the servers with it. With OpenRC I never had such issues and now I just play around sometimes with a local vm. I haven't yet made the decision to switch
(((Dirk Weber)))
in reply to Rebeka Catalina • • •The only issue is that I still did not set up a proper documentation. Yes, I plead guilty, that is no fun. Since the periods I have to stay in hospital tend to get longer the need is obvious.
Felix Tiede
in reply to Rebeka Catalina • • •Asking around, systemd's answer to the problem was that software should not bind to specific IP addresses.
Which is condescending at best, as server administrators tend to have a reason to bind to specific addresses only.
That being said it means systemd has, by ignorantly "streamlining" the OS's boot process, taken away an important feature for server environments. And is now asking service software developers to follow their "lead" instead of fixing the problem they've created in the first place.
Mind you, while the behaviour to report the network as "up" as soon as possible in the boot process of a desktop system is essentially a good idea, with servers it might not be.
Also, and that probably hasn't been thought through by systemd proponents both at the software development as well as the distribution level, modern server systems take several minutes to boot their hardware before even starting the OS's bootloader in the first place – so systemd's boot speed optimization doesn't actually help much here anyway. For a virtualized system it's even worse, as in this case boot speed is defined by the number of services to be started – the less and smaller the packages in question the better.
I have an OpenRC-based server VM that reports "fully up" with all services running within a couple of seconds, while the bloated systemd-based Ubuntu server VM is still starting software of dubious value for the use-case.
As mentioned before: In a desktop environment, it's a good idea to assume responsiveness as early as possible; in a server environment, priorities tend to differ. It is sad this is apparently not understood by systemd's developers.