… and it’s something we didn’t build. We get lots of things first but we usually build them. We never get proprietary software first. At best we get proprietary software the same day. Generally we get it months later. However, today linux takes another giant step towards being the dominant next OS, we are the first to receive 64-bit flash from adobe. Windows isn’t getting it, Mac OS X isn’t getting it, we are.

My Desktop is dieing and needs to be replaced. So I’m working on researching the parts I’d need to replace it. As any good IT person knows, the motherboard is the most important decision to make when building a computer. Theirs a good chance that someone reading this will cry out I’m wrong. The reason the Motherboard is the most important decision is it dictates the potential of the whole computer.

if possible emerge-ng should be able to accept input from <STDIN>, e.g. cat packagelist | emergeng, thus far neither portage nore pkgcore have this capability.

I like security… which means I should be able to run portage as portage (user) and have the umask be 077, or perhaps 027. Unfortunately the last time I checked portage could handle these restrictive permissions (I forget if it was these exactly) except for one set… java. In a perfect ebuild world all ebuilds would be able to be installed under a very restrictive umask.Should regen2 ever come to fruition this should be fixed.

pkgcore is my pick for the next portage and codebase for emerge-ng. I admit I haven’t let paludis have a chance (yet).Why haven’t I let paludis have it’s chance?The reasons are quite simple. Everytime I have tried paludis prior to this it has required extra configuration (meaning it doesn’t work out of the box). I believe this was fixed recently. However,paludis@1208029212: [WARNING] Use of Portage configuration files will lead to sub-optimal performance and loss of functionality.

Anyone that knows how I work in linux, knows that I"m comfortable with the cli, and prefer it to a gui. I know that not everyone is or should have to be. Sometimes a gui can make management easier. Even a die hard cli person like me realizes that. However, you should never have to do things the gui way, they are just front ends. emerge-ng needs to support having a gui even if the development of such a project is not directly part of the emerge-ng project.

I’m going to be short and sweet on this. The last time I checked, Sabayon made you run ~arch, upgrading would break your system, and it was all about bleeding edge gui’s. Sabayon is good for the last. But stay away from it if you want or need stability, or gentoo upgrades.

Currently Gentoo has arch, ~arch, and ~M ( - if not available ).One of the main things people want are security patches only updates. I tend to agree with this, although they should be between arch and ~arch, maybe +arch. Technically a security patch can break things which is why they shouldn’t be considered stable.Regen2 should also have strict rules about what’s what. Alpha products should always be ~M, beta’s and rc’s should be ~arch.

regen2 should support an /etc that’s under version control. something like etckeepercould/should work. Or we could just build our own tool for use with an existing vcs.–This workby Caleb Cushingis licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

I think having weekly tarballs is a great idea. But I’m less concerned about the release schedule of such things for regen2 and more concerned about the system packages that tarballs contain. A new tarball should be released, 1 week after a new glibc or gcc is updated, for sure, but any system package should be enough. Why 1 week? well once they stabilize they will hit a lot more people who are likely to have bugs, and that gives time for bugs to be fixed before tar-ing it.