How are theoretical applications which are designed to do just one specific thing a threat to a fully featured hypervisor with 15000 packages used in production?
Do you know if it is possible to render a page without serving it from a web server? For example, I have the html of one page of my domain generated by a test. I would like to use puppeteer to render it. But I don't want to setup a http server for this. I would like to give a string with the html + a url to page.goto and let it render the page like it comes from the real server.
I guess I can cheat by intercepting the request and respond with the html I already have. But I wonder if there is already something existing.
Initial assumption when reading the thread was that navigating to a data URI would be handled like entry of a data URI into the omnibox and still be allowed.
A small test case confirms that assumption - it works.
I suspect that you are not aware of what actually did exist previously. Mewburn rc had short pretty much declarative service definition files. Upstart had declarative configuration too, as did InitNG. Launchd, Upstart, and Solaris SMF had the launchctl/initctl/svcadm concept. daemontools/runit/perp/s6 had universal logging of standard output/error. And so forth.
Come back and say that when you've tried using systemctl to find out why a service is failing. 200-line zero-content error messages are what finally made me purge systemd from my machines.
Sysv init and rc-files are two different things. You can use whatever configuration system you like with sysv init, e.g openrc.
What systemd "solved" was already solved.
When you know this you understand that the motivation of the people behind systemd was not technical.
One of the top contributor of systemd is banned from the linux kernel because of bad coding. The other top contributor gave us the fiasco of pulseaudio. Both work at the same major company. Draw your own conclusions.
This is only a tiny piece of the experience though. What about journalctl? systemctl? etc? That stuff is alien vs tail -f or ./just/run/some.sh which works with everything _except_ systemd.
> You can google how to do the equivalent to `tail -f /var/log/foo.log` in a minute.
Doesn't the fact that I have to google an alternative workflow for something that behaves consistently across pretty much all other software make its UI worse, at least in that regard? I get that maybe it's a justified trade-off, but that doesn't make the UI any better.
> What do you mean by ./just/run/some.sh?
I suppose just dumping an exec command into an executable file and call it a service.
You can use syslog in conjunction with the systemd journal. Some distributions come set up that way by default, and for the others you can just `apt-get install rsyslog` or whatever. When you have a syslog daemon installed, `tail -f` and everything else you're used to works exactly the same as before, you can pretend the journal doesn't even exist if you want. And if you don't have a syslog daemon installed... well, i don't know if that's really journalctl's fault, is it?
Sure, just throw in several extra steps, huge numbers of syscalls and make any admin add complexity to their systems. For a busy service, this is a performance issue that the systemd devs simply reject out of hand as "doing it wrong".
That doesn't seem like an especially compelling argument. There are components of every ready-made operating system that you 'don't need or want'. I don't need or want an IPv6 stack, or debugfs, or half of the other features that come with most distributions' Linux kernels, and i don't need or want legacy bull shit like (d)ash and cpio and Python 2. But there they always are anyway, and i don't lose much sleep over that fact.
journald by default doesn't keep logs from the previous boot, which is extremely annoying. What's the point of having a logging system where you have to keep the old one around to read old logs? I've also had it seemingly not have any loglines for queried units when it should have; not sure what happened there.
In one configuration, journald logs to an in-memory filesystem; in another, it logs to an on-disc filesystem; in a third, it tries on-disc and falls back to in-memory; in a fourth it does not save the log either in memory or on disc. Different distributions configure this differently.
This falsehood keeps popping up, and not only can't it be shown to be true, it's illogical.
Init scripts are static. They don't change, they aren't ad-hoc, they aren't fragile. All modern Sysv init script systems have static scripts which 'include' a basic key=value pairs of environment variables from a config file. Nobody modifies scripts, or at least, they should not be doing it, and don't need to.
Many init scripts on my system have timestamps from the year 2002, and this system was just installed. They don't change because they don't need to change.
OTOH, Declarative unit files are configuration management taken away from the configuration management system, adding complexity.
until everyone starts working around flaws and missing features in the core. then the declarative files will be just a pile of hacks that in the end are just obfuscated ad-hoc script files.
and the scary part: we are not even fully there yet and it already reeks.
In theory, a perfect bugless system that enforces a certain DSL upon sysadmins who won't have to maintain startup scripts is a good thing. A thing which systemd is not.
But the UI is definitely easier to grasp than what existed previously
Really? so you really think:
systemctl <command> <service>
is an improvement over:
[optionally, some initsystem] <service> <command>
Given that, personally in most cases, when I am actually messing around on this level, I will be repeating the above several times where the only thing changing will be the <command> part (so, it is handy to have this right under the backspace key)
The systemd UI is a hot steaming pile of garbage that has made my day-to-day life on the CLI harder, not easier.
Maybe it is just me, but I don't really look for the init script to provide me a status on whatever it is that it inited. "OK" or "FAIL" is good enough in that specific context. It is the services' job to provide me with information on how it failed (or succeeded, or partially failed) through an easily and always accessible logging mechanism.
Different services have different failure modes with nuances that can never be generically captured by whatever means you chose to launch the service, in any kind of meaningful way. When a Database service stops serving data, my first though isn't "Lets see what the init system thinks", my first thought is "Lets see what I can find in various Database service logfiles" which will, 99.9% of the time, be something specific to the database service.
Inits' job in my view is "start this, and get out of the way". "Start this", and do logging, and do DNS/DHCP/manage-daemons/manage-restarts-on-fail/manage-the-fs/here-is-a-kitchen-sink/do-you-want-fries-with-that/oh-yes-and-here-is-NTP isn't what I am personally looking for in an init system, and - frankly - is a ridiculously stupid and idiotic approach from a server architecture perspective.
This isn't about the merits or lack thereof of binary logging, or the merits of whatever else systemd brought to the party. This is about needing tweezers, and being given a 500 function swiss army knife, where the other 499 functions get in the way of it being used as a very good tweezer.
Systemd is trying to be my default OS via the init system backdoor. I'll choose my own OS, thanks.
When a service stops my first thought will be check what ${init} says rather than a myriad of different inconsistent logs and badly written shell scripts say.
Then I'll check those logs if required.
Regarding DNS, DHCP et al, yes you have a point. Managing restarts on fail is a logical extension of init however.
It's not exactly consistent. Different rows for different services (sometimes different for the same type of units), an inconsistent amount of logs included (maybe), the status is not reported consistently, whatever. It's mildly helpful for visual inspection, and that's it.
The Atom Reason plugin uses Nuclide's system for error rendering (in the diagnostics bar), and type hints. But the actual logic for integrating with Merlin has been completely rewritten in Reason itself, and compiled from Reason into JS to run as an Atom plugin. So there are still merlin features missing because the Atom plugin is relatively young, but if you want to help us implement the missing features, it can be a fun way to try Reason itself (compiling to JS).
