As long as he uses vi
As long as he uses vi
I know you've probably written off gentoo at this point, here's a completely random bit of usage advice:
- Set use flags as you need them, even if this means re-installing the same thing multiple times. This avoids big important packages being pulled in as mere dependencies (though you can add them to the world list afterwards) and more importantly lets you set up and configure everything one at a time and makes it more likely that you'll notice error messages.
- Don't be afraid of package.keywords, especially for very specific use flags.
- Avoid gnome if possible. I don't know wtf it is with gnome, but it seems to be the poster child for weird and hard to diagnose issues as well as crazy dependency trees.
- Pay attention to what virtual packages are doing. Usually they are in your best interest, but not always.
- Don't bother using ebuilds for web apps
I started using a Gentoo derivative (Sabayon*) about a year ago, and it's an absolute pleasure to work with. (Particularly how colourful the package manager is compared to Debian.) In addition to the above, I suggest the following:
-Keep package.use, etc. and make.conf under version control. (This is really helpful in case you accidentally break something.)
-Use git instead of rsync for the portage tree - it's much faster, especially when the total no. of changes is small. (This is doubly true if you have multiple Gentoo installs.)
* Sabayon has systemd as the default, but it's easy enough to change back to OpenRC and being able to use binary packages saves a lot of time.
The problem is that these decisions are going to be made long before we have anything resembling a complete understanding of what these genes do. The classic example is sickle cell anemia: given the choice it would be selected again, even though it results in resistance to malaria. This kind of control over genetics can only lead to a reduction in biodiversity (since the majority of people will make decisions using similar values), and then we're just one pandemic away from near-extinction.
Yeah. Functional languages are so much better.. like the elegance of breaking out of a for loop... (oops... not possible... resort to clumsy workarounds). Or handling exceptions....
For loops are an imperative construct - you wouldn't find one in a functional language. Depending on what you were trying to achieve, you might express a similar concept using a fold and an algebraic type (Either or Maybe) to indicate when to ignore the rest of the elements.
I do agree that error handling is more inconvenient than in languages with exceptions though - wrapping the result in a type that can contain the result or an error is only a minor improvement on C-style return codes.
Personally, I've settled for a compromise between the two - Rust and D are both imperative languages with excellent functional programming support.
I can honestly say this is the best geek humour I've seen on Slashdot all year.
My girlfriend is exactly as crazy as I am, and I can honestly say it works quite well.
This is precisely why I trust Google more than Facebook. Google will use my information to show me ads, but Facebook will sell that information to the highest bidder.
There are two big problems with Python (and no, the whitespace thing is not either of them).
The first is that the Python community has effectively been fragment by Python2 vs Python3. Many libraries support one but not the other, which can lead to dependency hell.
The other big problem is duck typing. No language which uses duck typing by default (with no way to strongly type variables) should be used for programs more than a few hundred lines long. Strongly typed variables significantly improve the static verification of programs, and throwing something like that away just seems foolish. The most common justification I've seen for it is that it's more concise and saves time, but there are plenty languages which are strongly typed and use type inference instead of requiring explicit declarations (e.g. Haskell).
If you're completely insane and are sexually aroused by compiler flags, you want Gentoo.
Gentoo really doesn't enough love - it wasn't even mentioned in the article, despite being on par with Arch.
If anyone is interested in Gentoo but put off by the prospect of having to compile all your packages, I suggest they try Sabayon - it's a Gentoo derivative that uses a binary package manager in addition to portage, so you can install packages as easily as with apt-get/yum while still being able to use portage if you really want to mess around with USE flags.
Aspartame is one of the few substances that has been analysed to death, and we know it is quickly metabolised into 3 parts that are also found in many other sources of food that we wouldn't think twice of consuming. We don't know nearly as much about herbal teas, for instance.
It also results in glucose intolerance.
Regardless of how we think the body processes it, it's pretty hard to argue with the evidence on what effects it actually has.
I have mod points
For that specific case, it does require SSH access.
However, SSH access is often used for protocols like git, which makes this rather problematic.
Additionally, the vulnerability is just as effective using the CGI variables via apache.
Yes. No. Wait - yes. No... no. Uh....
The systemd has modular design.
But monolithic architecture.
Literally everything inside systemd is intertwined using the D-Bus.
So yes, a crash of one of the systemd daemons might cause deadlock/hang or even crash of the rest of the systemd, and consequently affect the processes running under it.
The systemd's design is pretty bad. This is not an exaggeration, when people call it Windows-like: MSWindows OS has very very similar atructure as the systemd. Windows "Event Log" is really cherry topping.
On-topic: uselessd doesn't fix this problem. It lessens it, but doesn't fix it.
AFAICT, uselessd strips out everything that isn't part of init from systemd, including journald. So exactly which daemons are left that are intertwined with each other?
Which is why I don't see a systemd fork as a viable alternative. The whole idea is broken, as it breaks with the Unix toolbox approach, where tools work independently, and not as a clusterfuck of apps that engage in social networking under the dictatorship of an object-oriented leviathan.
Try reading the project site, because AFAICT it meets your requirements. They've removed pretty much everything except for init, including journald and udev.
Binding previously-separate features into one project is bad design, by itself, the problem with systemd.
Why? Justify that statement without using any reference to the UNIX way or it being the way things have always been designed.
IMHO a coordinated set of functions that are used in a common way should be combined.
There are times when combining separate features into a single project makes sense - BusyBox is the classic example of this.
The problem is that it reduces the system's modularity - instead of being able to replace udev, the logging interface, etc. independently, you need to replace/patch the entirety of systemd. Now, if the upstream was willing to actively support modularity by maintaining stable APIs, this wouldn't be a problem, but they've gone out of their way to remove those APIs from all the projects they've assimilated.
I think systemd offers significant improvements over its predecessors, and agree that journalctl is much easier to use, but I don't think the way the project is being managed is good for the long term health of the Linux ecosystem.
"Indecision is the basis of flexibility" -- button at a Science Fiction convention.