This is basically the new player experience in Quake...
OTOH, it's hard to attract players if the only thing they do when joining a server is getting their asses handed. It may be fun for some of the older players to play with their prey rather than having a "real" fight, but it's just no fun at all for the prey.
The way I see it they can't win: Make the game easier and alienate the old players. Keep it the way it is and ensure no new players will come.
"More elite" is in the same basket as "value edition" and "power user". A nice word for the opposite of what it is.
You're way too hard on them. That's not all they do before releasing the game.
They'd also slap the current year onto the title. How else would you know it's a new game? From looking at it? Please...
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.
It seems like that problem would be most simply solved by creating a command line tool called 'parallel' that lets you run several commands in parallel, and then returns when it is done. Something like 'parallel cmd1 cmd2 cmd3.'
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
-Bake in more advanced log processing to mitigate the need for log analysis tools.
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.
Sequential startup of services is silly when many can be started in parallel.
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.
Great! That is all we need. More fragmentation in the community! As if choosing a distro wasn't confusing enough as it is for newcomers!
It should be relatively simple to create tools to permit systemd to automagically support normal Unixlike config files.
THIS is the reason why Linux will never be a mainstream desktop.
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.