241–250 of 332 posts
The thing I would like is a program that can browse journalctl files, but from other operating systems.
Also, you can store plain-text logs as well if you prefer by exporting journald’s output.
Earlier quoted context omitted.
I’m a fan of this description. It might not be the easiest to understand or the first one you should read, but I wish more things had this kind of description somewhere (but not necessarily on the introductory materials or front page).
It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.
I never became comfortable with neither the scope of systemd as a project, nor the ever expanding set of skills required to effectively use it. I was tempted to use the word mastering, but that would make the goal seem even more elusive, especially since with every new version one's knowledge would have to expand to cover its new features. 10 years later, it still looks to me like the project with a solution for ever…
Also, don’t get bogged down by systemd-* services, they are related but are usually not part of systemd at all.
Earlier quoted context omitted.
Didn’t emacs get developed on ITS or Multics? Seems Unix just imported it, but your point still holds.
Early versions of Emacs didn't have lisp extension languages, which is kind of strange to think about considering the role elisp plays in GNU Emacs as we know it today. GNU Emacs with elisp is something that developed in the context of the MIT lisp machine scene. Sure it runs and was developed on unix-like operating systems, but lisp extensible emacs were never really some sort of embodiment of the 'unix principles'.
GNU Emacs later (1984) was based on Gosling Emacs (1981), which was written in C and extended with Mocklisp. Mocklisp was a rather uncomplete Lisp, which was replaced with Emacs Lisp by Richard Stallman.
https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... quote: "What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. " endquote
For what it's worth, the OP argues the opposite - that systemd is insufficiently generic. Much of its complexity is a matter of conflating mechanisms and policy. This is par for the course for what's essentially prototype-quality software that's trying to address a number of non-trivial issues - but let's not pretend that real improvement is not possible here, or that systemd-as-it-currently-is does not stray from wh…
Can you please elaborate on this? It sounds like a very desirable approach, but I don't really see it "in unix". (I can think of a few program suites that use processes and piping between them as the "protocol", eg. cups, the executable files in a directory that are then launched in a loop pattern is more common, but that seems to lack the policy part. Whereas OpenSSH for example lacks this.)
Earlier quoted context omitted.
I'm an open source hacker and I like systemd. Once I took the time to learn its APIs I found it does everything I expect. Your issues with XFCE and libinput don't seem to be related to systemd. I can't see how airing grievances against other unrelated projects would be a constructive place to take this discussion. Complaining about open source projects only supporting some use cases is also confusing to me. A lot of…
I have no issues with XFCE. I personally would never use i, but it also leaves me alone and it's developers don't exhibit this mentality. I have a problem with Jon McCann's famous quote, who was at the time a lead developed of GTK+, who did not know what XFCE, one of the biggest consumers of the library, even was when he made a change that broke about anything outside of GNOME. — What his language suggested was that…
Earlier quoted context omitted.
Although I like the acpid approach, the logind way is probably safer to abstract behind a user friendly GUI. That's what most people will be using. :-/
And that is probably the motivation for this design philosophy of limiting options that Redhat and Freedesktop champion where more and more, simple, clean, turing complete solutions are replaced by a discrete list of simple options. But it does not change at all why I dislike it, and why I am annoyed by Freedesktop's pushing and insistence that many keep to these more custoizable solutions supposedly simply because t…
Earlier quoted context omitted.
Another happy s6 user here, and pretty much for the same reasons. I like the clear supervision process tree it creates. I'm not sold on the execline syntax, but it's relatively clean and easy to work with and since I already use a configuration management system, generating custom startup files (from a single template) isn't that much of a challenge. I'm currently exploring how to generate minimal service environment…
Any distro with s6 as default init manager?
Earlier quoted context omitted.
" For me and most users, the transition was fully imperceptible." So far. I hope for your sake it continues to be so.
'I am altering the deal, pray I do not alter it further.' --Darth Lennart I actually appreciate, now, what systemd is trying to do, but I am not certain why it has to take over home directories and everything else to do it. And I am really uncertain why it has to have such bad taste. I can get why it uses C, even though IMHO that is a mistake. But .ini files? D-Bus? XML ‽‽‽ Oh well, at least it's not YAML.
Earlier quoted context omitted.
I feel the same way about Postgres. It's powerful but it's insanely arcane and full of land mines and footguns. It's great for forcing you to hire consultants, DBAs, or pay cloud providers a lot to run it for you.
Which SQL RDBMS isn't, though? Postgres is a breeze compared to someting like DB2. High-performance relational databases just seem to be an inherently arcane target.