I am running xmonad on OpenBSD: screenshot
I found rofi reasonably recently, and it’s now well and truly one of the applications I cannot live without.
At work I’m on OSX, so I’m using whatever the default OSX thing is. I did however, purchase Moom (https://manytricks.com/moom/) a long time ago, which goes a little way to making OSX feel as hospitable as my AwesomeWM desktop I use at home.
FWIW, X11 is supported on OS X - see XQuartz. Running a window manager will require running X11-supporting applications in a single window (and an X11 window manager can’t manage Aqua apps), but perhaps that’ll be sufficient for your requirements.
I always enjoy the (very) infrequent update to Why Are Computers. http://whyarecomputers.com/
I am trying to turn our basic fluentd based log aggregation and collection system into something that’s high availability, resilient and fault tolerant so we can start to lean on it more heavily for our data warehousing systems. It’s a lot of fun - but distributed systems are hard!
Keep in mind that it’s easy to overwhelm a log system, and that syslog is lossy by design, much for this reason. Fluentd isn’t syslog, for sure, but if you have any chance at reliable, non-lossy logging, you’ll need to be able to spool to disk, which becomes a potential reliability problem in a cloud environment. Good luck!
I really strongly prefer unwrap to if let _ after introducing a hard to track down error into a project. I just knew it could never error. I was wrong. At least in the unwrap case it blows up rather than failing silently.
Thanks. That makes a lot of sense and I hadn’t considered that as a possibilty. I guess using unwrap makes it clear that you expect the operation to succeed even if you don’t care about the return value.
I recently ordered a paper copy of 10 PRINT CHR$(205.5+RND(1)); : GOTO 10 Which I am looking forward to starting when it arrives.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
the git repository and bug tracking moved to github
so, that justifies systemd throwing it’s weight around with regards to kernel development, right?
From what I can tell from this announcement, kdbus support in systemd is:
So, if I understand correctly: if your kernel does not have kdbus support then the only impact this will have on you is that your systemd binaries might be a few Kb larger.
I don’t see this as systemd throwing it’s weight around - more like they want to conservatively introduce a feature to a wider audience whilst, quite rightly, limiting it’s impact by placing it behind a feature flag.
I’m having difficulty seeing this as systemd throwing it’s weight around, what did you mean by that?
Thanks for your informative reply. I apologize for the tone of my comment.
To answer your question: from the Phoronix articles linked above, and what I have read about the systemd project, I gather that the vision put forth in Revisiting How We Put Together Linux Systems has gained influence. By “throwing it’s weight around” I meant that, because the project has such influence, their decision to include kdbus could move the kernel developers to mainline it despite their serious reservations. Poettering himself explains the sd-bus API that shipped with this latest systemd release, which supports “as back-ends both classic socket-based D-Bus and kdbus.” I must admit that I have only skimmed his posts, and so I cannot summarize them.
To the best of my ability and as time allows, I like to inspect and understand the systems that I use so that I can use them better. That may be a vain endeavor, but in it I find systemd frustrating because it adds more abstractions, the quality of which I have trouble discerning.
You are correct.
But as with most things systemd, it never stops there. It’s pretty easy to see where this is going.
As someone a little out of the whole systemd loop. Can you explain where this may be going?