Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:STOP FUCKING WITH X11 (Score 1) 189

I'm not sure how - note that Daniel Stone (the presenter) appears here - so he's one of the current folks in charge of dealing with the current xorg code; who better to judge the current state of xorg than someone who works with it every day? Another good presentation on the current state of X and its problems:

Comment Re:Linux distros (Score 4, Informative) 189

FWIW the reddit you link to has some replies with very reasonable explanations for the behavior you mention. As they state, I think the deal is even if it fails, it failed _after_ it started, and thus the start itself was successful. I think this is reasonable. I also got all log entries when reproducing here (same result as everyone else in that thread).

I'm not saying deleting bugs is cool - at least a WONTFIX or link to a DUP is appropriate - but are you sure it was opened successfully? What was the bug #?

The above said - I do see your point from a usability, if not strict "proper functioning" standpoint; previously for forking services that did some sort of constant time initialization and checking (opening files, sockets, etc) if the initialization failed they could report back and the startup script could return that result - systemd doesn't seem to support that. However there are other problems with the old way too (as you're checking result code I assume you're scripting) - startup could hang and you never get a result.I suppose the solution is similar for both cases - pick a point of time in the future and check if the status is as expected.

Maybe this is a feature request? As stated in the reddit, it only makes sense for forking services. It's not something I'd ever want, but maybe you could give a use case?

Comment Re:YAY! (Score 2) 135

As a network appliance type device at least I'd say it's still very relevant. I still prefer configuring / maintaining pf over iptables (or any other competitor I've tried) for any non-trivial ruleset, the documentation is IMO much better than most of the other stuff out there, it's relatively secure and relatively stable, and the performance and compatibility with older hardware has been great (in my experience). I use it for my gateway device and have never had any problems. I briefly used Linux for the same task and found myself spending more time messing with it. I could easily see it replacing all sorts of expensive commercial solutions at my workplace but managers like commercial vendors. It's just well put together and does what it's built for quite well. I think there's room for all sorts of stuff in the "grand scheme", not just shiny and popular stuff.

Slashdot Top Deals

Money cannot buy love, nor even friendship.