Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Re:Mandatory xkcd (Score 1) 229

by devent (#49558843) Attached to: GNU Hurd 0.6 Released

Your arguments are all biased and manufactured. That is a frequent observation from me that people who just don't like systemd make up arguments for why it is bad. Quite just like religious people make up argument for why evolution is false. It's also psychology 101 that people form beliefs first and make up arguments later to justify those beliefs. You just don't like systemd. My recommendation is to just give it a try.

"Those you shown are global parameters, not startup scripts."
No, those are the start up scripts.
"SystemD generates diagnostic messages"
Yes, those are extra. There are no diagnostic messages in sysvinit at all. So, you complain that systemd gives you extra tools to debug services.
"systemD instructs you to use some crazy command to parse the binary logs"
All files on a computer a binary and you need some program to read it. The journalctl tool is not crazy, it actually behaves just like grep and tail.
"Usually you can't just disable SystemD, and the tendency (IE it WILL happen), sysvinit will be removed."
The better tools will replace the old and worse tools.
"Precisely. Its not opt-in. And when you manually startup scripts, it captures the useful information the program is outputing *at that instance*."
Let me explain again. If you start a service it will capture sysout and syserr, because otherwise those outputs are lost (like in sysvinit). If you start manually via systemctl those are in the logs and you can see them via systemctl status.
"What we have now, are deamons silently failing and requiring an extra command to understand why"
No, you describe the situation with sysvinit. If a daemon is started on startup the sysout and syserr outputs are lost. Systemd logs them. And also, systemd actually shows you that the daemon failed to start, and blocks other daemons that depend on the failed daemon from starting.

Comment: Re:Mandatory xkcd (Score 1) 229

by devent (#49553887) Attached to: GNU Hurd 0.6 Released

So, comparing apples to apples, the apache22 init script in FreeBSD has around 190 lines, and nginx's ~140, including comments and dependencies. The scripts are quite easy to understand and show how to put everything in place.

Still an order of magnitude more complex than systemd.

[Unit]
Description=MaraDNS secure Domain Name Server (DNS) recursive resolver
Documentation=man:Deadwood(1)
Requires=network-online.target
After=openhomecrypt.service
After=network-online.target
After=network.service

[Service]
ExecStart=/usr/sbin/Deadwood
Restart=always

[Install]
WantedBy=multi-user.target

None of them are useful to me.

Then what are we discussing? Use your old style sysvinit.

Theoretically. In practice, it overrides the way sysvinit works, and you need to explicitly re-enable it.

I don't know again what you mean. The sysvinit init scripts are still working.

it doesn't, as systemd isn't capturing the program's log.

Because it doesn't suppose to do that. The journald is used internally by systemd, and services can opt-in to use it. It's also a situation of damn if you do, damn if you don't do. How many times I red on Slashdot the complain that with systemd you must have binary logs, or that it takes over logging.

In Roundcube for example you can opt-in into syslog logging. http://trac.roundcube.net/tick... The same options should be there to enable journald logging. At least systemd captures sysout and syserr into the journal, so it's not lost. Another huge improvement over sysvinit. How many times I had to start a daemon manually so I can see the errors from syserr.

But again, the MySQL logs are still there in /var/log ? It's not systemd fault if Oracle is not updating MySQL to use journald.

Comment: Re:"that the standard cosmological model can expla (Score 1) 45

by devent (#49552181) Attached to: Mystery of the Coldest Spot In the CMB Solved

In science, it's irrelevant if you admit it or not. Either your model works or not, and if it's not working somebody will come up with a better model and replace yours. People will use the better model because it works better. Or maybe I misunderstand you. Newton's laws of gravity works "almost right", Einstein's theory is better. But in cosmonautics and mechanics we use Newton's laws, because they are good enough.

Comment: Re:"that the standard cosmological model can expla (Score 1) 45

by devent (#49552161) Attached to: Mystery of the Coldest Spot In the CMB Solved

If we can't observe anything new. And by "new" I mean something that was not predicted by a scientific theory. Of course, there is always the possibility to observe something new, but it's like an asymptote. New scientists will be less and less excited, because they will just confirm established theories.

Comment: "that the standard cosmological model can explain" (Score 2) 45

by devent (#49549967) Attached to: Mystery of the Coldest Spot In the CMB Solved

Aw, boring. I was hoping that everyone was wrong and we get some new physics. Misconception of scientists number one, scientists (and me) like to be shown wrong so we can go and investigate and discover new knowledge. The day it turns out that we know everything will be a very sad day indeed.

Comment: Re:Mandatory xkcd (Score 1) 229

by devent (#49543851) Attached to: GNU Hurd 0.6 Released

"What I want is quite simple. To be able to configure and manage stuff with the least hassle."

Then you want systemd. As I mentioned before, the sysvinit start scripts are huge, complicated and error prone (the loop in Apache init script). In systemd all you have is a 17 lines file for Nginx: https://projects.archlinux.org...

systemd adds a lot of extras, and does not take anything away. It adds, a) info on whether the service was started, b) automatic restart of crashed services, c) journald, d) limit resource usage per service, e) simple and powerful service configuration files, f) inter service dependencies management (start Thin only if Nginx is started, or start MySQL after Apache) g) a lot of tools that were missing like systemd-ask-password.

And systemd does not take anything away from you. You can still use all your old school tools and your old style logging, and even the old sysvinit scripts.

"but no standard tool will help you when some opaque software is capturing the initialization process."

I don't know what you mean by that.

"Do you know which flags are passed to eg. your nginx setup? A quick look at the rc.d script will enighten you."

Same with systemd service files, see my example above.

"Is there a bug on the script (it happens more often than you seem to think)? Easy to fix."

In a 9000 bytes script file? You gotta be kidding me. The systemd file is just 17 lines long. The systemd developers have automated tests to make sure their software runs, if you don't trust them, why do you trust the kernel devs or the devs of the services you are using?

"but if not, why the f*ck is it taking control over MySQL initialization? "

What do you mean by that? It starts the service and watches the service that it is really started, and it gives you info that it is started or it didn't started or it crashed. For example, on my laptop:

# systemctl status maradns-deadwood.service
maradns-deadwood.service - MaraDNS secure Domain Name Server (DNS) recursive resolver
      Loaded: loaded (/usr/lib/systemd/system/maradns-deadwood.service; enabled)
      Active: failed (Result: start-limit) since Sun 2015-04-19 23:49:55 CEST; 4 days ago
          Docs: man:Deadwood(1)
    Process: 1472 ExecStart=/usr/sbin/Deadwood (code=exited, status=1/FAILURE)
  Main PID: 1472 (code=exited, status=1/FAILURE)
      CGroup: /system.slice/maradns-deadwood.service

Apr 19 23:49:55 localhost.localdomain Deadwood[1472]: There is no directory /mnt/homecrypt/var/cache/deadwood
Apr 19 23:49:55 localhost.localdomain Deadwood[1472]: Fatal: chdir() failed
Apr 19 23:49:55 localhost.localdomain systemd[1]: maradns-deadwood.service: main process exited, code=exited,...LURE
Hint: Some lines were ellipsized, use -l to show in full.

Comment: Re:Mandatory xkcd (Score 1) 229

by devent (#49539167) Attached to: GNU Hurd 0.6 Released

But you have both, MySQL log files and systemd logs? So, I still don't get what your problem is. In sysvinit you have zero information. And ps or netstat is not a reliable solution, because it is always different from service to service and from system to system. In ps you have to know the executable, in netstat the name of the service. On my Ubuntu server, for postfix you have "master", for nginx you have "nginx.conf". And of course the name will differ from system to system. Furthermore, services can opt in into the logging of systemd, it is not mandatory. So, I'm really confused what you want. You want that systemd takes over logging, or you still want your old logging files?

Comment: Re:Mandatory xkcd (Score 1) 229

by devent (#49509457) Attached to: GNU Hurd 0.6 Released

On systemd I do "systemctl start foo" and I get info that the service was actually started and runs, or that the service did not started. With the init scripts I don't have any response and I need to use ps or netstat to figure out whether or not the service actually runs. That is because systemd is using cgroups to track the started service, but sysvinit have no service management at all.

If you want info and logs why the service didn't started, use "systemctl status foo", or use the journal with "journalctl -n 20" or filter "journalctl _SYSTEMD_UNIT=foo". That's no different from the usual "dmegs|grep foo".

Your logging issues are too unspecific and I have no idea what you actually talking about. On Fedora 20 I have all the usual logging files in /var/log. Even your missed /var/log/messages is there.

Comment: Re:Mandatory xkcd (Score 4, Insightful) 229

by devent (#49492101) Attached to: GNU Hurd 0.6 Released

That's why people want systemd. If I look at sysvinit scripts, there are a ton of magic stuff going on that I don't know, and maybe nobody knows. On Ubuntu 12.04 the sysvinit script for Apache is over 7000 bytes long, and it includes bad stuff like "# wait until really stopped" with a loop of kill and sleep. The ClamAV init script is even bigger, over 9000 byes long. Is there any maintainer who really knows what it does?

Comment: Re:Check their work or check the summary? (Score 1) 486

by devent (#49336755) Attached to: No, It's Not Always Quicker To Do Things In Memory

All they did compare was one memory access vs. another memory access, and showed that Strings are inefficient compared to a byte array. Because the first code will concatenate Strings in memory, the second code will concatenate byte array data in memory, and then both are written to disk. The disk-access test should have been:

    for (int i=0; i numIter; i++) {
                    writer.write(addString);
                    writer.flush();
                    writer.close();
    }

Comment: Re:Watching systemd evolve (Score 1) 765

by devent (#49223563) Attached to: Ubuntu To Officially Switch To systemd Next Monday

That is your opinion. I wrote reasons why I think it is proven and obviously a lot of Linux distributors think that, too. Lets assume you are correct and it is unproven and will break in RHEL 7 and a lot, if not all, customers will get very angry with Red Hat and switch to sysvinit or stick to 6 or switch to a different distribution or to Windows. Do you think Red Hat will live with that risk? So, why would Red Hat use systemd in their enterprise distribution if they not think it is ready? Red Hat, Inc. is even a publicly traded company and since May 2014 their stock continues to grow in value, i.e. there is no sign that customers are running away from RHEL 7.

If a 6600 used paper tape instead of core memory, it would use up tape at about 30 miles/second. -- Grishman, Assembly Language Programming

Working...