I doubt systemd will be needed for the kinds of tasks you'll be running on a server that has no GUI. But if you want to read the logs, mount or copy them to a machine with a GUI.

There are several GUIs the big 2 are: Kcmsystemd (KDE) and Systemd-ui (low dependencies).

The situation is pretty simple.

1) Gnome and then more software depends on systemd
2) Debian doesn't want to fix those problems
ergo: easiest solution is to make systemd the default for Debian.

This would be a fight and Debian decided not worth it.

A wrapper, which can be written as a shell script itself, would look for dependency information in the init scripts, probably in a comment or perhaps in a variable. When the wrapper runs, it checks the status of any required init scripts which share the same first line, using the functionality built into each init script. If they are all running then it fires off the daemon and exits. Else, it blocks if it is critical or not if it is optional, and either way it loops and waits for deps for a decent amount of time. If it is critical the boot process is interrupted, if it is optional then something else happens (script-dependent.) Dependency information could also be stored in a variable in a config file (e.g. in /etc/default) and when not present, the daemon can be treated as critical and blocking. All the other elements of the system remain unchanged, down to symlinks establishing daemon launch order. This requires changes only to init scripts, and even then only for daemons which are expected to launch in parallel. Is there some obvious reason why this wouldn't work?

What was wrong with log analysis tools? One can bang them out with perl in a minute or two.

No, it really isn't. Process creation is cheap on Unix, and the shell will not only be cached during boot, but one or more copies of it will be present in memory at all times. Running the shell hundreds of times today is a triviality compared to running the shell dozens of times on Unix machines from the 1980s, on which that was in fact not a big deal, because process creation is cheap on Unix. This is just not a real consideration for any modern system, especially given the plethora of lightweight shells available for low-memory or otherwise limited systems.

This is really the argument that something new was needed, but frankly, it would have been simple enough to handle this without a whole new init system. A shell script wrapper would probably have done this job. Some distributions are already recording dependencies in init scripts; sequence information would be simple enough to add. If this is the best argument for systemd, and so far as I can tell it is that, then it's a really crap argument.

It should be relatively simple to create tools to permit systemd to automagically support normal Unixlike config files.

The truth is that nobody but Ubuntu has ever really tried for the mainstream desktop, and they have serious flaws involving ignoring their users; Microsoft and Apple already fill that niche.

Is that before or after he's acting like a king with unrestricted power? Before or after engaging in unauthorized military strikes in countries across the world?

Make up your mind already.

For the benefit of anyone reading, jklovanc is still talking out of his ass, but I've wasted too much time on this nonsense already. Goodbye.

Here is the problem

Let A by GPL app as submitted. Apple adds a provisioning file / code to it for the version that is distributed, call it A+. Since A+ is a derived work of A it must be GPLed. Since Apple is distributing it they need to GPL A+. But the source for A+ requires Apple's key. think that's where the copyright violation the key not the version of the application created by Apple.

BTW I'm a user of your app, replaced pcalc as my primary calculator. So thanks!.

The advantage is that it will create a constant current in the canal.

Regardless of the length of the canal -- at least until evaporation becomes a factor.

The constant current can be leveraged to move boats, presumably fairly deep hulled so the really get in the way of the current, and said boats can carry whatever.

Two canals adjoining allows the boat to be moved from one to the other, and sent back to the other end, ad infinitum.

When you put a cork in a river, it'll go from the mountains to the sea, because the current carries it.

What I'm suggesting is create an artificial current using pumps. The two 'c's run in different directions, so you have a full transport loop.

All four ends are physically adjacent, so you only need one pumping station if you connect the two c's across one end.

Old time canals used donkeys and engines to navigate. This works like a river and a raft. You float to where you're going.

> You're assuming you'll get free energy out of this?

Um... no... where would get such an idea?

Think about it. If you put a transport thing in there (think boat) with a nice deep hull, and there's a 5 knot current along the entire canal created by the transfer at the ends of the C, what will the boat do? Now add another boat at a reasonable interval, say another boat length.

Do you imagine doing this will slow down either the current or the other boat?

That's the point, and that's all I am assuming.

That depends on the DPI. My phone, very small indeed, is 1080x1920 (or 1920x1080 if I'm holding it funny.) One of the monitors on my 8-core desktop is 1280x1024.

The DPI difference between them is radical. Even so, any properly designed page will allow the user's browser to resize and reflow the content to fit the window if it's of any sane width (probably only wide enough to render the longest word in the content.) If it can't do that, the browser should hand you scroll bars. Be nice if the browser had a user setting "minimum width before scroll bars", too. That'd be a joy.

Fixed aspect / resolution webpages are horrible.

That, and "hover" menus and windows are the #1 reason why I surf away from web pages.

Tip to "designers": If I didn't CLICK on it, I didn't WANT it, and that means ITS IN MY FUCKING WAY

(cough) Sorry.

Desktop screens have had two sizes in the past 10 years to my knowledge: 4:3 and 16:9 (or close to it),

Irrelevant. All you really need to know is that pixels are square. It's been some time since we had to deal with non-square pixels. Everything else should be up to the user's browser window.

layout constraints

...doing it wrong. The BROWSER should control the layout. Not the data source.

> A single combination of web browser and operating system can be used on both low DPI displays and high DPI displays.

If the image is wider than the window, you get scroll bars; also, browsers can resize. It's not the server's job. We don't have a bandwidth shortage. We have a decently flexible content shortage. If you know it's a mac or a PC, you know it's got a desktop range of pixels. Likewise any particular smartphone. There's no mystery here worth noticing.

Don't resize images with the viewport. That's very annoying. They should reflow with the window according to the browser's settings. If you set a constant width, then you're asking for scroll bars if the window can't fit that width. This all works very well. It has for a long time. Stop trying to make it not work.

Just because you can do something, doesn't mean you should do something. You could make both the text and the background black -- but you wouldn't, right? Because it's highly unfriendly, to say the least. Well, so is locking the user's browser view to particular widths and heights and sizes and positions. HTML was intended as the content provider; the browser intended to be the content formatter, using only hints -- lines, paragraphs, font styling, etc. The closer you can get to that in web page design, the better web page designer you are, because then the user gets to fit the thing into the window the user wants it to be in.

Every time I run into a page that makes me resize my browser to make the damn thing work, I curse. Every time. Every time some whackjob decides that menus should drop or windows should open when my mouse pointer crosses some object, I curse. Every time I run into some page (like liveaquaria.com's) that won't run its cart or checkout through the usual standard ports and protocols, when everything else from Amazon to the tiniest little retailer and back to EBay will, I try to find somewhere else to shop.

Stop trying to be clever with the page. Instead, be clever with what you put on the page.