Forgot your password?

Comment: Re:Does not compute. (Score 1) 48

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.

Comment: Re:What's wrong with Windows Server? (Score 1) 316

by drinkypoo (#47813833) Attached to: You Got Your Windows In My Linux

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 /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?

Comment: Re:Troll much? (Score 1) 316

by drinkypoo (#47813765) Attached to: You Got Your Windows In My Linux

-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.

Starting up /bin/sh hundreds of times during boot is wasteful and slows boot.

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.

Comment: Re:The Future! (Score 1) 316

by drinkypoo (#47813727) Attached to: You Got Your Windows In My Linux

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.

Comment: Re:Blame FSF not Apple ... (Score 1) 121

by jbolden (#47813097) Attached to: Apple Reveals the Most Common Reasons That It Rejects Apps

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!.

Comment: Re:Pumped storage and transport (Score 1) 218

by fyngyrz (#47812659) Attached to: Power Grids: The Huge Battery Market You Never Knew Existed

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.

The meat is rotten, but the booze is holding out. Computer translation of "The spirit is willing, but the flesh is weak."