Comment Re:Yes, pipelined utilities, like the logs (Score 2) 385
You don't have to. If you really want your old way then just have journald pass everything along to syslog and it's back to normal.
You don't have to. If you really want your old way then just have journald pass everything along to syslog and it's back to normal.
That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.
We all stopped using UNIX long ago, it's GNU/Linux now and it's only somewhat inspired by UNIX. What the UNIX people did 30 years ago is interesting from a historical perspective, but is not in any way the only right way to do things. I say did because that's now even how modern unices work. Solaris has for example been running on SMF since 2005 and they are doing just fine.
Are you suggesting that Systemd is prone to crash?
Not really. His argument lost some credibility when he compared a system level utility to a graphical application.
What's the difference? Both are complex systems.
I use both, actually I use a couple of others as well. I often find interesting edge cases and bugs just by running my code through as many compilers as possible.
I don't see anything about demand there.
Unfortunately Systemd is not available on Minix so that's a downgrade.
They stopped using gcc for various reasons, the project was stagnant, ridden by core developers that could not agree on a road map, it forked a few times I believe and it was always not only buggy but years behind modern C++ standards. Not to mention gcc is slow and the code it produces was not really fast or small in the recent years.
No idea how it is faring right now.
You should really take a look at gcc 4.9 because your viewpoint is seriously out of date.
According to TFS Quickflix apparently wants to.
Because someone else will do cool things with it that you wouldn't.
It's an argument for why Apple should do it, not that Apple must do it.
What is there to stop people from making their own implementations of compilers for swift?
What we've seen from other languages is that patents can potentially be a problem, but I don't know if that's applicable in this case.
Open sourcing the future design of swift however means apple may lose control of how the language develops and could be a hindrance to it's primary use in developing software for it's OSes.
Apple might loose control if someone else makes a better implementation, and that users switch to it. That would be a good thing and motivate Apple to improve their original implementation which might otherwise stagnate.
I don't know about that necessarily. Some has contributed a nontrivial amount of work to LLVM and especially the clang project. That has certainly been appreciated outside the Applesphere.
In this context it's a programming language for the Objective-C runtime developed by Apple.
No one is demanding anything, but some of us believe that distributing your software as free and open source software is better for everyone including the original developer. There's nothing wrong in suggesting it.
Love makes the world go 'round, with a little help from intrinsic angular momentum.
