Re: [gentoo-user] Re: anti-portage wreckage?
On Saturday 06 January 2007 00:43, Daniel Barkalow [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] Re: anti-portage wreckage?': (Actually, I think that it would be even better to have the etc-update/dispatch-conf step done before the ebuild qmerge step, so that the user's chosen config file is merged at the same time as everything else, but that's another thing entirely.) Well, emerge is supposed to be able to be run without interaction; some packages (doom3, for example) do require action, but it's generally frowned upon. (And some ebuilds, like webapp-config's have be be massaged because configuration files are modified after all merges are complete.) More on topic, I like your idea, but not in a position right now to make the necessary hacks to portage. -- If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability. -- Gentoo Developer Ciaran McCreesh pgpYggehHmkn2.pgp Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
On Thu, 4 Jan 2007, Alan McKinnon wrote: On Wednesday 03 January 2007 20:24, Daniel Barkalow wrote: I didn't say it shouldn't require interaction to get the new shipped version; I said it should require extra confirmation to discard changes made locally. It should also be able to offer 3-way merge instead of 2-way, and automatically retain local changes that don't conflict with shipped changes. Please define exactly what a change that doesn't conflict with shipped changes means so that I can design a correct algorithm and implement it in C or Python. Take the diff between the original version and the local version, and call this local. Take the diff between the original version and the new shipped version, and call this remote. Represent each of these diffs as a series of hunks. Step through the original file, and, by splitting on each hunk boundary in either of the diffs, produce a series of hunks, where each hunk has at least one version; if there is more than one version, ask the user for help in merging that hunk. The versions are: - the original, if neither side has any changes. - the local, if only the local has a change. (*) - the original and the remote, if only the remote has a change. (+) - the local and the remote, if both diffs have changes. When multiple versions are available, make it clear what those versions are, ask for additional confirmation if the choices are local and remote and the user picks remote rather than using local or writing a new version by hand. Also allow arbitrary edits to the file, in case the user has to fix up syntax. (*) Optionally, the original and the local, if the user is particularly paranoid and wants to check over the purely local modifications. (+) This is the difference between this algorithm and RCS's merge: changes made remotely can be rejected. Include deprecated options, syntax changes, subtle changes in meaning, redefined syntax commands and new conflicting options in config files with the same name across version changes. make it bullet proof so that any regular dev can list these things easily in confidence of their correctness, where the user will know the impact without resorting to looking it up every time, and where the correct thing (defined by whatever $ARB_USER happens to believe they want) is done in the vast overwhelming majority of cases. I don't think the paranoid user case is actually that significant. Either the shipped version has to compensate for the change in semantics, in which case there will be a remote change, which demands user interaction; or the shipped version doesn't change, in which case the current etc-update doesn't help you, because the shipped versions before and after are identical and emerge doesn't tell etc-update to do anything. Note that my algorithm never treats a file entirely automatically unless the current etc-update also would treat it entirely automatically. Mine just acts on a per-hunk level instead of a per-file level, and also provides additional information on what's going on. I'm not jerking your chain here - that is the real spec of a system like you propose. I'm not being pedantic and nit-picking - these are the kind of detail things that make or break software. Windows Update fails in the real world as Microsoft implements vast sweeping monolithic changes leaving the user with no meaningful way to control the process other than do not apply SPx. Lets not even put one toe onto that road... There's sort of a continuum of bad designs, from no information and no control to no information and lots of control. It doesn't help the user much to have tons of control if there's no information to base a decision on. Think about how bad etc-update would be if it didn't tell you the filename you were working on. Microsoft does both of these bad things (stuff just happens, and the computer might not work and you have to make this critical decision: 'yes' or 'no'). Gentoo is far better, but I think etc-update would be a lot better with more information given to the user; e.g., the choice for replace the old shipped configuration with a new shipped configuration should be a different key from replace the locally-modified configuration with a new shipped configuration, rather than both being replace the current configuration with the new shipped configuration. I don't actually mind the 100 files in etc-update all that much. The issue is that the first 99 are files I've never touched where I've never even learned the config file syntax, or the occasional executable in a weird place, or init scripts I haven't modified, or examples that aren't actually used, and the 100th one is my coworker's lovingly hand-crafted CUPS configuration, and I'm half asleep by the time I get to it. It should be able to tell that I've got local modifications, and warn me that I'm in danger of losing work on the config file. It's just kind of
Re: [gentoo-user] Re: anti-portage wreckage?
On Thursday 04 January 2007 09:44, Neil Bothwick wrote: File a bug, the ebuild shouldn't be reporting this if it is unnecessary or confusing. I think I'll wait a little while for the new bug tracker, but that's something worth reporting, I guess. You can file it on the new bug tracker at http://bugstest.gentoo.org Well, he can but no devs will see it. It doesn't send mails and it'll get a new import from the old tracker when it replaces old wiping anything anyone filed on the new tracker at bugstest... -- Bo Andresen pgpoC7Zj4Yuyx.pgp Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
On Wed, 3 Jan 2007 00:45:00 -0500 (EST), Daniel Barkalow wrote: Perhaps it just needs to be more popular, or maybe it needs to understand slots better (in order to be popular). I know that all of the kernels I install tell me that support for devfs was removed long before the oldest kernel available in portage as of when I installed the machine. File a bug, the ebuild shouldn't be reporting this if it is unnecessary or confusing. It also doesn't look like it's something where it would be able to choose to upgrade postfix 2.2.10 to 2.2.10-r1 instead of to 2.3.5 because 2.3.5 would require help and 2.2.10-r1 is automatic. This is Gentoo, you are supposed to make those sort of decisions for yourself. Automatic updates go against the the admin is in control ethos. -- Neil Bothwick Bang on the LEFT side of your computer to restart Windows signature.asc Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
On Wed, 3 Jan 2007 00:21:02 -0500 (EST), Daniel Barkalow wrote: The issue is that etc-update doesn't have the version of the config file as installed by the version of the package that's being replaced, so it can't tell the difference between non-trivial changes to the config file as shipped by gentoo between the old version and the new version and non-trivial local modifications that I've made myself to a config file which has not been changed between package versions. I've definitely had etc-update ask for confirmation on files I'm sure I didn't change I haven't use etc-update for a while, but dispatch-conf can do this. # Automerge files that the user hasn't modified # (yes or no) replace-unmodified=no Whether this is a good idea is a completely separate issue. If a service had a config file change between versions and the file was updated to the new format while the old daemon was still running, the results could be interesting. -- Neil Bothwick Found my .sig, it was in behind the cushion on the settee. signature.asc Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
Hi, On Wed, 3 Jan 2007 11:03:34 - Nelson, David (ED, PARD) [EMAIL PROTECTED] wrote: Has the idea of distributing custom package.mask files occured? This way you can mask off certain versions of software and hence limit updates to minor changes. You can then use these on systems you want to keep as stable as possible, use a test machine to test changes to the package.mask and then roll it out. Might make management of many workstations/servers easier. Naah, it wouldn't work by itself. You would still have to have a trusted state portage tree in order to make sure what's _not_ masked. It's far easier to replicate a known-state portage tree. Alternatively incorporating a custom package.mask into a custom boot CD could provide the basis of a Gentoo-derived custom distro? I use the word custom too much. No, that's the outcome of this thread, I think. It's all about customization. Customization that makes a streamlined distro impossible to use for majority of Gentoo's users. -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Wednesday 03 January 2007 13:03, Nelson, David (ED, PARD) wrote: Hi folks, Has the idea of distributing custom package.mask files occured? This way you can mask off certain versions of software and hence limit updates to minor changes. You can then use these on systems you want to keep as stable as possible, use a test machine to test changes to the package.mask and then roll it out. Might make management of many workstations/servers easier. Alternatively incorporating a custom package.mask into a custom boot CD could provide the basis of a Gentoo-derived custom distro? portage already does this, in the profile. It's what defines the 'system' package set. For an example, look in the files in /usr/portage/profiles/default-linux/x86/2006.1/ - you can define USE flags, required packages, versions of those packages, and basically everything you mention above alan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Tuesday 02 January 2007 14:26, William Kenworthy wrote: rattus ~ # emerge system -ep These are the packages that would be merged, in order: Calculating system dependencies ... done! rattus ~ # 3 systems like this, one installed only a few months ago works. And `emerge --info` ? There's probably a better way to do this but this should output what constitutes your system packages. It should be 61 lines on your profile. # cd /etc cd $(readlink /etc/make.profile) \ while [[ true ]]; do if [[ -f packages ]]; then egrep -v ^$|^# packages; fi if [[ -f parent ]]; then cd $(cat parent); else break; fi; done -- Bo Andresen pgpkDEz2YI7YJ.pgp Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
On Wed, 3 Jan 2007, Alan McKinnon wrote: The only possible thing etc-update could ever do is look for trivial changes and ignore them. How would you detect the difference between non-trivial changes to shipped versions and non-trivial changes made locally? Keep a copy of the config files for installed packages somewhere in /var, and provide etc-update with this is the version we shipped that's going away on package removal. Currently, it only keeps the hash of the config file that goes with a package, so it can only tell whether there was a change in the shipped version, not what that change was. Portage actually has enough information to detect that the user has modified a CONFIG_PROTECTed file (moveme and destmd5 != cfgfiledict.get[myrealdest]), but doesn't test this or communicate it to etc-update. You can't say that if the config file exists and hasn't changed since installation then overwrite it with the new shipped version - that might change the behaviour of an *existing* system (without notification) if the user likes the old way and does not like the new way. I didn't say it shouldn't require interaction to get the new shipped version; I said it should require extra confirmation to discard changes made locally. It should also be able to offer 3-way merge instead of 2-way, and automatically retain local changes that don't conflict with shipped changes. It's understood that there is a difference between what I'm using now and what new package comes with. But there's no information on whether that difference came from local modifications. And neither should there be. Etc-update knows the files are *different* and stops right there. Evaluating what that difference means is a human's job because it's not a monkey-see, monkey-do process. What the difference means is up to the humans, but there's no reason, aside from having carelessly lost information previously, that it doesn't know where the change came from; that part isn't up to human interpretation, and it's valuable information for humans trying to evaluate what the difference means. -Daniel *This .sig left intentionally blank* -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Wed, 3 Jan 2007, Neil Bothwick wrote: On Wed, 3 Jan 2007 00:21:02 -0500 (EST), Daniel Barkalow wrote: The issue is that etc-update doesn't have the version of the config file as installed by the version of the package that's being replaced, so it can't tell the difference between non-trivial changes to the config file as shipped by gentoo between the old version and the new version and non-trivial local modifications that I've made myself to a config file which has not been changed between package versions. I've definitely had etc-update ask for confirmation on files I'm sure I didn't change I haven't use etc-update for a while, but dispatch-conf can do this. # Automerge files that the user hasn't modified # (yes or no) replace-unmodified=no Whether this is a good idea is a completely separate issue. If a service had a config file change between versions and the file was updated to the new format while the old daemon was still running, the results could be interesting. I actually wanted the opposite feature: have an extra confirmation required for replacing a locally-modified file. And it shouldn't require all of the extra bookkeeping of dispatch-conf to get this, although dispatch-conf is clearly a lot closer. -Daniel *This .sig left intentionally blank* -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Wed, 3 Jan 2007, Neil Bothwick wrote: On Wed, 3 Jan 2007 00:45:00 -0500 (EST), Daniel Barkalow wrote: Perhaps it just needs to be more popular, or maybe it needs to understand slots better (in order to be popular). I know that all of the kernels I install tell me that support for devfs was removed long before the oldest kernel available in portage as of when I installed the machine. File a bug, the ebuild shouldn't be reporting this if it is unnecessary or confusing. I think I'll wait a little while for the new bug tracker, but that's something worth reporting, I guess. It also doesn't look like it's something where it would be able to choose to upgrade postfix 2.2.10 to 2.2.10-r1 instead of to 2.3.5 because 2.3.5 would require help and 2.2.10-r1 is automatic. This is Gentoo, you are supposed to make those sort of decisions for yourself. Automatic updates go against the the admin is in control ethos. Gentoo makes a lot of the particular version decisions based on your policy decisions. E.g., it'll currently use 2.2.10 and not either 2.2.10-r1 or 2.3.5 if you don't have ~x86. It would make sense to have =2.3 masked (by user-intervention requirement) if you have 2.3 installed, like 2.2.10-r1 is masked by keyword. Masking =2.3 by hand works, but it would be nice to exactly mask the ebuilds that would call die in pkg_setup given your status. (For that matter, it would be nice to have emerge able to tell you about masked versions that you might find interesting; I was interested in mysql 5 going stable, despite having =4.1 masked, and didn't find out until a while later) -Daniel *This .sig left intentionally blank* -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Wednesday 03 January 2007 20:24, Daniel Barkalow wrote: On Wed, 3 Jan 2007, Alan McKinnon wrote: The only possible thing etc-update could ever do is look for trivial changes and ignore them. How would you detect the difference between non-trivial changes to shipped versions and non-trivial changes made locally? Keep a copy of the config files for installed packages somewhere in /var, and provide etc-update with this is the version we shipped that's going away on package removal. Currently, it only keeps the hash of the config file that goes with a package, so it can only tell whether there was a change in the shipped version, not what that change was. Portage actually has enough information to detect that the user has modified a CONFIG_PROTECTed file (moveme and destmd5 != cfgfiledict.get[myrealdest]), but doesn't test this or communicate it to etc-update. That doesn't work in real life. The system can detect if files have changed, where they changed, when they changed and even who changed them. It does not know, and never will know, *why* the change happened and what the intention of the user was in making the change. Even if a config file has not been changed and a new different version exists, the system has no way to determine whether the existing unchanged version exactly meets my needs or not and whether an automatic update will cause me (the admin) to flip my lid and flame the dev as a result (or not). The machine does not know, the code does not know and the dev does not know. Only *I* know and *I* am the only person that can make this decision. Unix users tend to use it because (amongst other things) the system does not try and second guess us and pull a we know better than you stunt. If I want that behaviour, I'll migrate to Windows thank you very much. I know etc-update is a pain in the ass, especially after emerge -uND world and I have to make decisions on 100 CONFIG_PROTECTed files. But even so it's miles better than the alternative. You can't say that if the config file exists and hasn't changed since installation then overwrite it with the new shipped version - that might change the behaviour of an *existing* system (without notification) if the user likes the old way and does not like the new way. I didn't say it shouldn't require interaction to get the new shipped version; I said it should require extra confirmation to discard changes made locally. It should also be able to offer 3-way merge instead of 2-way, and automatically retain local changes that don't conflict with shipped changes. Please define exactly what a change that doesn't conflict with shipped changes means so that I can design a correct algorithm and implement it in C or Python. Include deprecated options, syntax changes, subtle changes in meaning, redefined syntax commands and new conflicting options in config files with the same name across version changes. make it bullet proof so that any regular dev can list these things easily in confidence of their correctness, where the user will know the impact without resorting to looking it up every time, and where the correct thing (defined by whatever $ARB_USER happens to believe they want) is done in the vast overwhelming majority of cases. I'm not jerking your chain here - that is the real spec of a system like you propose. I'm not being pedantic and nit-picking - these are the kind of detail things that make or break software. Windows Update fails in the real world as Microsoft implements vast sweeping monolithic changes leaving the user with no meaningful way to control the process other than do not apply SPx. Lets not even put one toe onto that road... The various update tools do the only realistic thing possible - the user said to not touch these files, so it doesn't. Period. It's understood that there is a difference between what I'm using now and what new package comes with. But there's no information on whether that difference came from local modifications. And neither should there be. Etc-update knows the files are *different* and stops right there. Evaluating what that difference means is a human's job because it's not a monkey-see, monkey-do process. What the difference means is up to the humans, but there's no reason, aside from having carelessly lost information previously, that it doesn't know where the change came from; that part isn't up to human interpretation, and it's valuable information for humans trying to evaluate what the difference means. Now you are changing the goal posts. Previously you said the tools should be doing automated changes. Now you say the tools should highlight (as a diff perhaps) what the changes are. Which is it? alan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Tue, 2 Jan 2007 01:50:27 -0500 (EST), Daniel Barkalow wrote:
I think it would be useful to have an ebuild thing for upgrading to
this package from version {expression} requires the following steps,
such that the message will be displayed only if you're doing that, and
such that the upgrade will be masked if you're being conservative in
upgrading.
It already does, with has_version. Look at the pkg_setup() part of the
postfix ebuild for an example of this in use.
--
Neil Bothwick
I will always cherish the initial misconceptions I had about you.
--
Neil Bothwick
Top Oxymorons Number 22: Childproof
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Monday 01 January 2007 04:34, Mike Myers wrote: The update system is the -only- nice thing about it over Gentoo. Debian is nowhere near Gentoo when it comes to everything else (especially docs). I don't think suggesting a single feature that another distro has and putting into Gentoo is trying to make it a clone. I'm just asking for a relief from having to constantly worry if updating something out of the 300 packages that need updated is going to break something, and not having to make sure etc-update isn't going to destroy my custom configs afterwards. If it wasn't for that, Gentoo would be perfect. I'm sure there's got to be others that would agree. At this point it might be helpful to revisit what gentoo really *is* in engineering terms Gentoo is not an off-the-shelf, commodity, we-do-everything-for-you and you don't have to think (much) distro, it's in a completely different class. The devs have given up the ability to configure things a certain way and handed that control over to you. You get increased customizability but have to pay the price of increased knowledge and responsibility, including that you get to keep both pieces when you break it. Red Hat and Ubuntu can do all these tests for you, the gentoo devs can't (except in some very broad cases like package-1.0 is config-file incompatible with package-2.x), so we gentoo-users have to do these tests ourselves. Remember the old joke: We can make it cheaply, quickly, correctly. Pick any two. You have a case like this, maybe it's time to just get over it :-) alan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Tuesday 02 January 2007 08:50, Daniel Barkalow wrote: I also think that emerge should keep track of the config files installed by packages, so that etc-update knows if you've got local modifications, and give you a big warning when you might lose a change you made. Huh? Portage already does this. Standard config dirs are CONFIG_PROTECTed which is where etc-update comes in. It will merge trivial changes (whitespace, etc) and let *you* chose what to do for everything else. You get to keep the original file, use the update, or use a customized merge of the two. There is no need to give you a big warning if you might lose a change - the very act of running etc-update at all IS that warning. It's understood that if the new file shows up, then you DO have local modifications alan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Mon, 01 Jan 2007 23:36:02 +1300, Mark Kirkwood wrote: Yeah, it would be good to know an update is not going to give a broken system - but to implement some sort of (extra) tagged release testing would be a significant amount of effort for the community. Only if you rely on the current developer community to do this. There's nothing to stop a user or group of users from taking a snapshot of the portage tree and applying only security updates (after testing of course) then using that as their own rsync source for a static Gentoo-based distro. If the target hardware is all compatible, you could also build packages so that all updates on production machines would be done with the --usepkg option, saving time and CPU cycles. -- Neil Bothwick Sure, we just route the main sensor through Data's cat. signature.asc Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
On Monday 01 January 2007 06:58, William Kenworthy wrote: rattus ~ # emerge system -ep These are the packages that would be merged, in order: Calculating system dependencies ... done! rattus ~ # 3 systems like this, one installed only a few months ago works. And `emerge --info` ? -- Bo Andresen pgpVYBuUS9ovq.pgp Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
On Tue, 2007-01-02 at 12:19 +0100, Bo Ørsted Andresen wrote: On Monday 01 January 2007 06:58, William Kenworthy wrote: rattus ~ # emerge system -ep These are the packages that would be merged, in order: Calculating system dependencies ... done! rattus ~ # 3 systems like this, one installed only a few months ago works. And `emerge --info` ? rattus ~ # emerge --info Portage 2.1.1-r2 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r4, 2.6.19-gentoo-r2 i686) = System uname: 2.6.19-gentoo-r2 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.12.6 Last Sync: Fri, 29 Dec 2006 05:20:01 + distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox:1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.15.92.0.2-r10, 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.8.1-r1, 2.6.17-r2 ACCEPT_KEYWORDS=x86 AUTOCLEAN=yes CBUILD=i686-pc-linux-gnu CFLAGS=-w -mcpu=athlon-xp -march=athlon-xp -mtune=athlon-xp -O2 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -ftracer -fforce-addr CHOST=i686-pc-linux-gnu CONFIG_PROTECT=/etc /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/bind CONFIG_PROTECT_MASK=/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c CXXFLAGS=-w -mcpu=athlon-xp -march=athlon-xp -mtune=athlon-xp -O2 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -ftracer -fforce-addr DISTDIR=/usr/portage/distfiles FEATURES=autoconfig ccache distcc distlocks metadata-transfer sandbox sfperms strict GENTOO_MIRRORS=ftp.iinet.net.au/pub/Gentoo LANG=en_AU.UTF-8 LC_ALL=en_AU.UTF-8 LINGUAS=en MAKEOPTS=-j5 PKGDIR=/usr/portage/packages PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages' PORTAGE_TMPDIR=/var/tmp PORTDIR=/usr/portage PORTDIR_OVERLAY=/usr/local/portage SYNC=rsync://rsync.gentoo.org/gentoo-portage USE=x86 3dnow 3dnowex 3dnowext 7zip X X509 Xaw3d a52 aac aalib activefilter adns aim alsa alsa_cards_ali5451 alsa_cards_als4000 alsa_cards_atiixp alsa_cards_atiixp-modem alsa_cards_bt87x alsa_cards_ca0106 alsa_cards_cmipci alsa_cards_emu10k1x alsa_cards_ens1370 alsa_cards_ens1371 alsa_cards_es1938 alsa_cards_es1968 alsa_cards_fm801 alsa_cards_hda-intel alsa_cards_intel8x0 alsa_cards_intel8x0m alsa_cards_maestro3 alsa_cards_trident alsa_cards_usb-audio alsa_cards_via82xx alsa_cards_via82xx-modem alsa_cards_ymfpci alsa_pcm_plugins_adpcm alsa_pcm_plugins_alaw alsa_pcm_plugins_asym alsa_pcm_plugins_copy alsa_pcm_plugins_dmix alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop alsa_pcm_plugins_empty alsa_pcm_plugins_extplug alsa_pcm_plugins_file alsa_pcm_plugins_hooks alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug alsa_pcm_plugins_ladspa alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear alsa_pcm_plugins_meter alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi alsa_pcm_plugins_null alsa_pcm_plugins_plug alsa_pcm_plugins_rate alsa_pcm_plugins_route alsa_pcm_plugins_share alsa_pcm_plugins_shm alsa_pcm_plugins_softvol apache2 apm arts asf audiofile avahi bash-completion berkdb bidi bigger-fonts binfilter bitmap-fonts blas bluetooth bonobo browserplugin buffysize bzip2 bzlib c++ cairo cap cdda cddb cdparanoia cdr cgi cli corba cpudetection cracklib crypt cscope css cups curl daap dbus devmap dga dhcp divx divx4linux djvu dlloader dnd doc dri dts dv dvb dvd dvdr dvdread dvi dxr3 edl eds elibc_glibc emboss encode erandom escreen esd ethereal evo exif expat extensions faad fam fame fbcon fbsplash ffmpeg fftw firefox flac flash font-server foomaticdb fortran fpx freetds freetype gb gd gdbm ggi gif gimp gimpprint ginac glade glgd glibc-omitfp glut gmedia gmp gnome gnome-print gnomedb gnuplot gnutls gphoto2 gpm graphviz gs gsl gstreamer gtk gtk2 gtkhtml guile gzip hal hdf hdf5 howl-compat hpn httpd iconv icq idn imagemagick imap imlib imlib2 inkjar innodb input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jabber java javascript jbig jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility kdexdeltas kernel_linux kig-scripting kqemu largeterminal lcms ldap libcaca libclamav libg++ libgda libsamplerate libwww linguas_en live logitech-mouse logrotate lua lzo lzw-tiff mad maildir matroska mbrola mcal mdb mdnsresponder-compat mhash mikmod ming mjpeg mmx mmx2 mmxext
Re: [gentoo-user] Re: anti-portage wreckage?
On Mon, 01 Jan 2007 02:29:12 +0300, Mike Myers [EMAIL PROTECTED] wrote: I'm sure others will disagree, but I really think if Gentoo is going to become a cornerstone in the desktop's replacement (like for thin clients) then there should probably be an option for a binary 'version' of portage. Gentoo is great in so many ways, but having to compile everything is sometimes just very unnecessary. I mean it's great if you want to teak your desktop, but it's just time consuming on a server or a slower embedded machine, and worst of all there's no benefit for compiling things in those areas. The other problem thing that will hold it back, I believe anyway, is the constant updating instead of release cycles. This can make administration very harsh on a system that you can only access remotely. AFAIK Gentoo is a meta-distribution. That is, its goal is to make it easier to create other distributions. When somebody installs Gentoo, compiles packages, and uses the resulting binaries for whatever purpose, there is a possibility to wrongfully conclude that the Gentoo distribution is being used by an end user. In fact, it has been used by a distribution developer to create a customized distribution which in its own turn has been used by an end user, while the fact that the distro developer and the end user are the same person is mere coincidence. Is it still true? If it is still true, then why should Gentoo, as represented by its developers, care if there are any servers too busy to compile anything and too deep in production to allow for testing upgrades? Indeed, how can Gentoo distribute binary packages when it does not know your CFLAGS and USE? One answer could be to run a server that takes CFLAGS and USE returning the resulting binary package. The server can be run by the Gentoo Foundation if it finds that the idea has business sense, but this issue is transcendental to Gentoo as a Distribution. How can Gentoo test if an update brakes something when it does not know the state of the system before the update? Possibly it could, if the portage tree had versions and users were severely limited in what configuration changes they can do. But how is it different from creating another distribution that is just based on Gentoo like Ubuntu is based on Debian? How could Gentoo increase its market share if such a potential future is to occur, or even better: how could Gentoo Foundation become pivotal in making it happen while retaining its values. Does Gentoo Foundation need greater market share? My impression is that developers need more good developers, not home users. I do not know what the Trustees want to achieve, but I guess that influence can be measured not only in the number of users, but also by the probability that Gentoo patches are accepted upstream, the number of application developers that release ebuilds, and the number of distributions that are based on or using Gentoo (really do not know how to find out if Gentoo is used by other distribution developers). As far as typical home users go, they don't really buy into things unless it's easy to use. Mainly because they are wanting a tool to accomplish a task. If Gentoo can provide that tool, then getting it into the living room wouldn't be a big deal. As it is now, unfortunately, Gentoo is not designed to be 'easy to use' in the sense of the average user's experience. Once it is, then it will be easier to market. I like the ability to tinker with Gentoo, but I just wish it wasn't a requirement to use it. I agree that a pretty good easy to use distribution for typical home users can be built with Gentoo. I do not care if it is built or not, but if it will make Gentoo more healthy or pleases Gentoo developers or Trustees in whatever way, I wish it is built. I do not want current Gentoo developers to spend their valuable time building such a distribution. -- Andrei Gerasimenko -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Tue, 2 Jan 2007, Alan McKinnon wrote: On Tuesday 02 January 2007 08:50, Daniel Barkalow wrote: I also think that emerge should keep track of the config files installed by packages, so that etc-update knows if you've got local modifications, and give you a big warning when you might lose a change you made. Huh? Portage already does this. Standard config dirs are CONFIG_PROTECTed which is where etc-update comes in. It will merge trivial changes (whitespace, etc) and let *you* chose what to do for everything else. You get to keep the original file, use the update, or use a customized merge of the two. The issue is that etc-update doesn't have the version of the config file as installed by the version of the package that's being replaced, so it can't tell the difference between non-trivial changes to the config file as shipped by gentoo between the old version and the new version and non-trivial local modifications that I've made myself to a config file which has not been changed between package versions. I've definitely had etc-update ask for confirmation on files I'm sure I didn't change (including, in some cases, executables that get installed in protected directories). There is no need to give you a big warning if you might lose a change - the very act of running etc-update at all IS that warning. It's understood that if the new file shows up, then you DO have local modifications It's understood that there is a difference between what I'm using now and what new package comes with. But there's no information on whether that difference came from local modifications. -Daniel *This .sig left intentionally blank* -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Tue, 2 Jan 2007, Neil Bothwick wrote:
On Tue, 2 Jan 2007 01:50:27 -0500 (EST), Daniel Barkalow wrote:
I think it would be useful to have an ebuild thing for upgrading to
this package from version {expression} requires the following steps,
such that the message will be displayed only if you're doing that, and
such that the upgrade will be masked if you're being conservative in
upgrading.
It already does, with has_version. Look at the pkg_setup() part of the
postfix ebuild for an example of this in use.
Perhaps it just needs to be more popular, or maybe it needs to understand
slots better (in order to be popular). I know that all of the kernels I
install tell me that support for devfs was removed long before the oldest
kernel available in portage as of when I installed the machine.
It also doesn't look like it's something where it would be able to choose
to upgrade postfix 2.2.10 to 2.2.10-r1 instead of to 2.3.5 because 2.3.5
would require help and 2.2.10-r1 is automatic.
-Daniel
*This .sig left intentionally blank*
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Wednesday 03 January 2007 07:21, Daniel Barkalow wrote: On Tue, 2 Jan 2007, Alan McKinnon wrote: On Tuesday 02 January 2007 08:50, Daniel Barkalow wrote: I also think that emerge should keep track of the config files installed by packages, so that etc-update knows if you've got local modifications, and give you a big warning when you might lose a change you made. Huh? Portage already does this. Standard config dirs are CONFIG_PROTECTed which is where etc-update comes in. It will merge trivial changes (whitespace, etc) and let *you* chose what to do for everything else. You get to keep the original file, use the update, or use a customized merge of the two. The issue is that etc-update doesn't have the version of the config file as installed by the version of the package that's being replaced, so it can't tell the difference between non-trivial changes to the config file as shipped by gentoo between the old version and the new version and non-trivial local modifications that I've made myself to a config file which has not been changed between package versions. I've definitely had etc-update ask for confirmation on files I'm sure I didn't change (including, in some cases, executables that get installed in protected directories). Neither the computer nor etc-update can think. So why are you asking it to think? Because that's what you are asking it to do - make an intelligent decision about a config file based on it's contents and how it differs from a new version. The only possible thing etc-update could ever do is look for trivial changes and ignore them. How would you detect the difference between non-trivial changes to shipped versions and non-trivial changes made locally? You can't say that if the config file exists and hasn't changed since installation then overwrite it with the new shipped version - that might change the behaviour of an *existing* system (without notification) if the user likes the old way and does not like the new way. This will cause b.g.o. to be flooded with bugs about how emerge obliterated working config files - are you going to be the one to answer all those bug reports? There is no need to give you a big warning if you might lose a change - the very act of running etc-update at all IS that warning. It's understood that if the new file shows up, then you DO have local modifications It's understood that there is a difference between what I'm using now and what new package comes with. But there's no information on whether that difference came from local modifications. And neither should there be. Etc-update knows the files are *different* and stops right there. Evaluating what that difference means is a human's job because it's not a monkey-see, monkey-do process. Again: the computer cannot think. Don't expect it to. alan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
Mike Myers wrote: (snippage) I'm not trying to suggest that Gentoo should go to a binary distro or anything like that. I'm just wondering why there isn't some kind of update management system to like, differentiate minor updates like firefox 1.5.0.5 http://1.5.0.5 to firefox 1.5.0.7 http://1.5.0.7 and major ones like, y'know, gcc 3.4.4 to 4+? Ok - sorry, was misled by the mentioning of packages! The update system is the -only- nice thing about it over Gentoo. Debian is nowhere near Gentoo when it comes to everything else (especially docs). I don't think suggesting a single feature that another distro has and putting into Gentoo is trying to make it a clone. I'm just asking for a relief from having to constantly worry if updating something out of the 300 packages that need updated is going to break something, and not having to make sure etc-update isn't going to destroy my custom configs afterwards. If it wasn't for that, Gentoo would be perfect. I'm sure there's got to be others that would agree. Yeah, it would be good to know an update is not going to give a broken system - but to implement some sort of (extra) tagged release testing would be a significant amount of effort for the community. In addition it could be argued that there is potentially little real gain in doing this, as it is *never* possible to ensure no breakage (e.g. Microsoft updates are a case in point...). At the end of the day, regardless of whatever release engineering/quality process Gentoo (or any software product) has, you really have to follow the steps: 1/ Update (1 or more) machines in your test environment. 2/ Run your test suite. 3/ Update the rest of your machines if 2/ pases. Personally I don't see why this does not scale. Cheers Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Sun, 31 Dec 2006 19:01:25 -0600, Mike Myers wrote: I've recently began experimenting with Debian and noticed their updating system is exactly like what I was asking about. Basically, there's package updates, and then there's distro updates. Why is it unreasonable for Gentoo to have something like this? I think it would help Gentoo a lot in the server market, where scalability is important. Look at the gentoo-dev thread that Richard pointed out (versioning the tree). The release tree idea discussed there seems to be similar to what you are suggesting. -- Neil Bothwick Do PAL taglines take up two scanlines? signature.asc Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
I totally agree to neil's assessment. Mike certainly has point that Debian is more mature in some aspects (is has been around since '93). That being said it is lacking so much in other departments that for me it is no serious alternative to Gentoo (difficulty installing source packages not in the apt repositories, inferior security support in comparison to Gentoo to name a few). I really believe we should give Gentoo some time to evolve (Gentoo was first released in 2002) In time gentoo will become more mature and better fit to our needs. In order to achieve this however we all need to put an effort into making Gentoo the best distro available. So please stop talking and get moving. Open a thread, mobilize people, contact aforementioned Gentoo businesses. _Contribute_ in any way possible to realize the features you envision. On 12/31/06, *Neil Walker* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Mike Myers wrote: I just wanted to add something to the original post. I've recently began experimenting with Debian and noticed their updating system is exactly like what I was asking about. Basically, there's package updates, and then there's distro updates. Why is it unreasonable for Gentoo to have something like this? I think it would help Gentoo a lot in the server market, where scalability is important. If Debian does what you want then why not go with it? What would be the point in making Gentoo like Debian? Gentoo offers a different approach which many of us like. It's all about choice - if you like Debian, choose it - but don't expect Gentoo to turn into a Debian clone. It's not going to happen. -- gentoo-user@gentoo.org mailto:gentoo-user@gentoo.org mailing list The update system is the -only- nice thing about it over Gentoo. Debian is nowhere near Gentoo when it comes to everything else (especially docs). I don't think suggesting a single feature that another distro has and putting into Gentoo is trying to make it a clone. I'm just asking for a relief from having to constantly worry if updating something out of the 300 packages that need updated is going to break something, and not having to make sure etc-update isn't going to destroy my custom configs afterwards. If it wasn't for that, Gentoo would be perfect. I'm sure there's got to be others that would agree.
Re: [gentoo-user] Re: anti-portage wreckage?
On Sun, 31 Dec 2006, Mike Myers wrote:
On 12/31/06, Mark Kirkwood [EMAIL PROTECTED] wrote:Mike Myers wrote:
I just wanted to add something to the original post.
I've recently began experimenting with Debian and noticed their updating
system is exactly like what I was asking about. Basically, there's
package updates, and then there's distro updates. Why is it
unreasonable for Gentoo to have something like this? I think it would
help Gentoo a lot in the server market, where scalability is important.
While this is true, one of the differentiating points of Gentoo is
precisely the build-from-source idea (there are plenty of binary update
distros out there).
I'm not trying to suggest that Gentoo should go to a binary distro or
anything like that. Besides, it's easy enough to just use a binary package
server if that's what one needs. I'm just wondering why there isn't some
kind of update management system to like, differentiate minor updates like
firefox 1.5.0.5 to firefox 1.5.0.7 and major ones like, y'know, gcc 3.4.4 to
4+? The way it is now, they're all lumped together like one big update.
The lack of such a system might make it easier for the devs.. but this is a
pain in the ass for the users when they run into a problem like this
unexpectedly. It's even worse when that user is managing several Gentoo
machines. This kind of thing does not scale at all.
The problem is that the chance of something breaking gets higher the more
you do at once, and the chance of something you need to be able to recover
also breaking goes up sharply. I've been watching people use Debian for
quite a while now, and I've rarely if ever seen a system upgrade without
major problems. People have problems like: the new release has a version
of Apache that has a different config file arrangement, and it's hard to
make a new config file that handles the web app the system is supposed to
be running; the old Apache worked fine, but the new release doesn't use
it, and the old binary requires a ton of libraries that the new release
doesn't have, either. And there's no easy way to downgrade to the old
release until you have time to mess with config files.
With Gentoo, you find that the new apache doesn't work with your config
files, so you mask it until you have time to deal with it.
I'm just asking for a relief from having to constantly worry if updating
something out of the 300 packages that need updated is going to break
something, and not having to make sure etc-update isn't going to destroy
my custom configs afterwards. If it wasn't for that, Gentoo would be
perfect. I'm sure there's got to be others that would agree.
Well, there are two goals here: make it so you can do all the safe updates
without any of the ones which will require manual fixing, and make it so
your custom configs are protected.
I think it would be useful to have an ebuild thing for upgrading to this
package from version {expression} requires the following steps, such that
the message will be displayed only if you're doing that, and such that the
upgrade will be masked if you're being conservative in upgrading.
I also think that emerge should keep track of the config files installed
by packages, so that etc-update knows if you've got local modifications,
and give you a big warning when you might lose a change you made.
-Daniel
*This .sig left intentionally blank*
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
Very good ideas in this thread. Why not open a thread in the Gentoo forums and start a public discussion there? In regard to your question, have you thought about the --oneshot option? That way you can manually upgrade the packages you see fit. James wrote: Mike Myers fluffymikey at gmail.com writes: I think I like your idea better, about distributing binaries. Do you know if something like this is being worked on? I'm certain that a common method to this, like what you're saying, would allow Gentoo to become scalable to the point of being easily usable on a large scale. It's a lot of work. I'll be pusing binaries to lots of systems, but, it going to take me months to get ready. I was hoping others with similar goals would 'band together' to come up with a solution that combines the needs for the casual user as well as those of us that want to manage dozens to hundres of Gentoo systems. I need to refine the idea, and my goal is mostly embedded gentoo sytems, but, they are very similar to gentoo-servers. Expanding the idea to workstation, at least for core software, is not that difficult. I do not intend to get into 'competiion' with the devs, particularly on applications that are big, complex, or prone to breakage (OO) It'd really be better to do this as a group, but, I've found little interest, most probably due to the fact that most folks are already bogged down with their own ambitions. James
Re: [gentoo-user] Re: anti-portage wreckage?
On Sunday 31 December 2006 12:18, Aniruddha wrote: Very good ideas in this thread. Why not open a thread in the Gentoo forums and start a public discussion there? In regard to your question, have you thought about the --oneshot option? That way you can manually upgrade the packages you see fit. James wrote: Mike Myers fluffymikey at gmail.com writes: I think I like your idea better, about distributing binaries. Do you know if something like this is being worked on? I'm certain that a common method to this, like what you're saying, would allow Gentoo to become scalable to the point of being easily usable on a large scale. It's a lot of work. I'll be pusing binaries to lots of systems, but, it going to take me months to get ready. I was hoping others with similar goals would 'band together' to come up with a solution that combines the needs for the casual user as well as those of us that want to manage dozens to hundres of Gentoo systems. I need to refine the idea, and my goal is mostly embedded gentoo sytems, but, they are very similar to gentoo-servers. Expanding the idea to workstation, at least for core software, is not that difficult. I do not intend to get into 'competiion' with the devs, particularly on applications that are big, complex, or prone to breakage (OO) It'd really be better to do this as a group, but, I've found little interest, most probably due to the fact that most folks are already bogged down with their own ambitions. Last few unstructured [OT] thoughts for the year . . . There's been a couple of threads on Gentoo going out of fashion, the Linux desktop failing to dethrone M$Windoze, etc. I think that this particular thread is interesting from another perspective, too. Not fighting past battles (which distro should/could/would dominate the server market and which the desktop market), but fighting potential future battles. If you're interested, read on. The PC centric desktop on which M$ built their business model may be under threat. If the WebOS [1], GoogleOS [2], internet based desktop [3], etc. take off, then what will enable Gentoo to become a predominant system of choice both in the server and in the thin client markets? I don't think that Redmond will have much of a problem packaging a ROM embedded version of a thin client system and pushing it to all the Joe-public out there, who currently (mostly) blindly buy their products. Inertia may of course lead to their demise if they continue to market the individual desktop PC solution, but I wouldn't count on it. The question then is what should Gentoo do to establish itself as a major enabler and shaper in such a potential future? What are the market segments and sub-segments and how do they come together (a home PC is these days a desktop apps suite; a games machine; a media center with CD/DVD/TV/music playing and recording capabilities, etc.) Device and information convergence is increasing. Some people will undoubtedly run their own home servers with their chosen desktop apps and access them via FreeNX VNC. For them Gentoo will be an option to consider. However, I think that the vast majority will not own or configure their own remote access desktops. They will readily subscribe to the latest M$ shop offering along with their free Hotmail account. How could Gentoo increase its market share if such a potential future is to occur, or even better: how could Gentoo Foundation become pivotal in making it happen while retaining its values. [1] http://en.wikipedia.org/wiki/Web_operating_system [2] http://www.kottke.org/05/08/googleos-webos but there's many more articles blogs out there; e.g. [3] http://blogs.zdnet.com/web2explorer/?p=166 Happy New Year to All! -- Regards, Mick pgpcXhoAJShp8.pgp Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
On 31 December 2006 15:40, Mick wrote: The PC centric desktop on which M$ built their business model may be under threat. If the WebOS [1], GoogleOS [2], internet based desktop [3], etc. take off, then what will enable Gentoo to become a predominant system of choice both in the server and in the thin client markets? I don't think that Redmond will have much of a problem packaging a ROM embedded version of a thin client system and pushing it to all the Joe-public out there, who currently (mostly) blindly buy their products. Inertia may of course lead to their demise if they continue to market the individual desktop PC solution, but I wouldn't count on it. This won't happen for various reasons. In the business world, the main reason is security. Who will trust an Internet Desktop Provider with their internal documents? In the world of home computing, there are actually two main reasons. The first is porn. The second is nearly photo-realistic games. Another, not that important, reason is that there are vast areas in the world where bandwidth is insufficient and far too expensive for it. Uwe -- A fast and easy generator of fractals for KDE: http://www.SysEx.com.na/iwy-1.0.tar.bz2 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Sunday 31 December 2006 16:02, Uwe Thiem wrote: On 31 December 2006 15:40, Mick wrote: The PC centric desktop on which M$ built their business model may be under threat. If the WebOS [1], GoogleOS [2], internet based desktop [3], etc. take off, then what will enable Gentoo to become a predominant system of choice both in the server and in the thin client markets? I don't think that Redmond will have much of a problem packaging a ROM embedded version of a thin client system and pushing it to all the Joe-public out there, who currently (mostly) blindly buy their products. Inertia may of course lead to their demise if they continue to market the individual desktop PC solution, but I wouldn't count on it. This won't happen for various reasons. In the business world, the main reason is security. Who will trust an Internet Desktop Provider with their internal documents? The same people who are trusting a multitude of outsourcing companies with their HR, Payroll, logistics, IT management and support, procurement, marketing, public relations, project delivery, . . . , you get the drift. I wouldn't trust them any more than you do, but in the world of hollow corporations there are a multitude of companies out there who would trust nearly anybody to take this problem away. In the world of home computing, there are actually two main reasons. The first is porn. Why does porn need to stored locally?! The second is nearly photo-realistic games. Of course. That is I think one area where a thin client will not be able to compete with a modern desktop PC. I don't play games and haven't seen what sort of latency a game played through FreeNX can achieve. On the other hand future gaming may be left to games consoles? Another, not that important, reason is that there are vast areas in the world where bandwidth is insufficient and far too expensive for it. Indeed, although most of these vast areas are sparsely populated and some of them are wired up as we speak - a friend who visited China 3 years ago mentioned that the gov't was laying yellow fibre-optic cables right across the country. -- Regards, Mick pgpaqAHE29nmC.pgp Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
On Sun, Dec 31, 2006 at 06:20:23PM +, Mick wrote: The second is nearly photo-realistic games. Of course. That is I think one area where a thin client will not be able to compete with a modern desktop PC. I don't play games and haven't seen what sort of latency a game played through FreeNX can achieve. On the other hand future gaming may be left to games consoles? Then I hope it will be possible to have my _private_ correspondence on a game console. I dread the times when I will have my pgp key stored somewhere on the internet. Another aspect is, I want to be the administrator of my computer - because I have the power to do whatever I like ;-) -- This message has optimized support for formating. Please choose green font and black background so it looks like it should. Michal vorner Vaner pgp06p2OClIH2.pgp Description: PGP signature
Re: [gentoo-user] Re: anti-portage wreckage?
On 31 December 2006 20:20, Mick wrote: On Sunday 31 December 2006 16:02, Uwe Thiem wrote: This won't happen for various reasons. In the business world, the main reason is security. Who will trust an Internet Desktop Provider with their internal documents? The same people who are trusting a multitude of outsourcing companies with their HR, Payroll, logistics, IT management and support, procurement, marketing, public relations, project delivery, . . . , you get the drift. I wouldn't trust them any more than you do, but in the world of hollow corporations there are a multitude of companies out there who would trust nearly anybody to take this problem away. On the other hand, I know enough companies that don't do that - and I do IT consultancy jobs for them. I don't doubt that a large number of companies is hollow and stupid. The questions is what the ratio is between those that store their latest blueprints inhouse and those that don't. I do not know. Do you? I mean hard numbers, not guesses. The other question is what the top 100 will do. Will Ford keep their internal strategic papers on the servers of an Internet Desktop Provider (IDP)? Will Dow Chemical? DaimlerChrysler? Exxon? You get the drift. ;-) In the world of home computing, there are actually two main reasons. The first is porn. Why does porn need to stored locally?! Many daddies John Doe might not understand the implications of storing potentially embarrassing (and often illegal) data on someone else's servers. Many, if not the majority, will at least have their suspicions and probably chicken out of IDPs. How significant is this? Well, I had the task to analyse the logs of a transparent proxy of a local ISP for some time. It was quite amazing. Just short of 50% of HTTP traffic was porn. About 80% of their subscribers were regular porn site visitors. So yes, it is significant. The second is nearly photo-realistic games. Of course. That is I think one area where a thin client will not be able to compete with a modern desktop PC. I don't play games and haven't seen what sort of latency a game played through FreeNX can achieve. On the other hand future gaming may be left to games consoles? NX is a truly amazing technology. I tried a full KDE desktop over a bloody modem line, and it reacted as if local. Still, the games I am talking about put a far higher stress on the local system *and* the bandwidth. Still, if thin clients would get far better video subsystems *and* much more ram they might do the trick. Another, not that important, reason is that there are vast areas in the world where bandwidth is insufficient and far too expensive for it. Indeed, although most of these vast areas are sparsely populated and some of them are wired up as we speak - a friend who visited China 3 years ago mentioned that the gov't was laying yellow fibre-optic cables right across the country. While China is a huge part of the world population-wise. it isn't all of it outside the US. Besides, fibre-optics aren't all of it. We have a backbone of them as well. Still, the average bandwidth a client can expect is somewhere between 3 and 4 KB/s. Anyway, since you use gmail.com, you are at least outsourcing your email. ;-) Not too bad, I admit - as long as you aren't sending incriminating or simply confidential stuff through them. Uwe -- A fast and easy generator of fractals for KDE: http://www.SysEx.com.na/iwy-1.0.tar.bz2 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On 31 December 2006 20:57, Michal 'vorner' Vaner wrote: On Sun, Dec 31, 2006 at 06:20:23PM +, Mick wrote: The second is nearly photo-realistic games. Of course. That is I think one area where a thin client will not be able to compete with a modern desktop PC. I don't play games and haven't seen what sort of latency a game played through FreeNX can achieve. On the other hand future gaming may be left to games consoles? Then I hope it will be possible to have my _private_ correspondence on a game console. I dread the times when I will have my pgp key stored somewhere on the internet. Another aspect is, I want to be the administrator of my computer - because I have the power to do whatever I like ;-) We aren't talking about *you* or *me*. We are talking about future trends. These involve a helluva more people than yourself. ;-) Uwe -- A fast and easy generator of fractals for KDE: http://www.SysEx.com.na/iwy-1.0.tar.bz2 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
I just wanted to add something to the original post. I've recently began experimenting with Debian and noticed their updating system is exactly like what I was asking about. Basically, there's package updates, and then there's distro updates. Why is it unreasonable for Gentoo to have something like this? I think it would help Gentoo a lot in the server market, where scalability is important.
Re: [gentoo-user] Re: anti-portage wreckage?
Mike Myers wrote: I just wanted to add something to the original post. I've recently began experimenting with Debian and noticed their updating system is exactly like what I was asking about. Basically, there's package updates, and then there's distro updates. Why is it unreasonable for Gentoo to have something like this? I think it would help Gentoo a lot in the server market, where scalability is important. While this is true, one of the differentiating points of Gentoo is precisely the build-from-source idea (there are plenty of binary update distros out there). One other thing - to actually do what you are suggesting requires a fair number of extra volunteers to maintain these package updates. Now I'm not saying its not possible, or even a bad idea mind - just wore work... and maybe that effort might be better spent on keeping the current momentum and quality of Gentoo as it is (or improving it)... Cheers Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
Mike Myers wrote: I just wanted to add something to the original post. I've recently began experimenting with Debian and noticed their updating system is exactly like what I was asking about. Basically, there's package updates, and then there's distro updates. Why is it unreasonable for Gentoo to have something like this? I think it would help Gentoo a lot in the server market, where scalability is important. If Debian does what you want then why not go with it? What would be the point in making Gentoo like Debian? Gentoo offers a different approach which many of us like. It's all about choice - if you like Debian, choose it - but don't expect Gentoo to turn into a Debian clone. It's not going to happen. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
Mike Myers wrote: I just wanted to add something to the original post. I've recently began experimenting with Debian and noticed their updating system is exactly like what I was asking about. Basically, there's package updates, and then there's distro updates. Why is it unreasonable for Gentoo to have something like this? I think it would help Gentoo a lot in the server market, where scalability is important. While I might personally like what you are suggesting I think that the idea fails under the load of trying to get the community to agree on what use flags/compiler flags, etc. would be the standard that all these packages are built with. Do you make the binary packages small or do you make them full featured? Do you support AMD CPU flags? Intel? Both or neither somehow? Personally I think there are so many options in Gentoo that coming up with agreement on what to do will be pretty difficult. That said if a set of binary packages were out there I'd probably investigate using it for certain machines, but most likely never my personal desktop machine. Cheers, Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On 12/31/06, Mark Kirkwood [EMAIL PROTECTED] wrote:Mike Myers wrote: I just wanted to add something to the original post. I've recently began experimenting with Debian and noticed their updating system is exactly like what I was asking about. Basically, there's package updates, and then there's distro updates. Why is it unreasonable for Gentoo to have something like this? I think it would help Gentoo a lot in the server market, where scalability is important. While this is true, one of the differentiating points of Gentoo is precisely the build-from-source idea (there are plenty of binary update distros out there). I'm not trying to suggest that Gentoo should go to a binary distro or anything like that. Besides, it's easy enough to just use a binary package server if that's what one needs. I'm just wondering why there isn't some kind of update management system to like, differentiate minor updates like firefox 1.5.0.5 to firefox 1.5.0.7 and major ones like, y'know, gcc 3.4.4 to 4+? The way it is now, they're all lumped together like one big update. The lack of such a system might make it easier for the devs.. but this is a pain in the ass for the users when they run into a problem like this unexpectedly. It's even worse when that user is managing several Gentoo machines. This kind of thing does not scale at all. One other thing - to actually do what you are suggesting requires a fair number of extra volunteers to maintain these package updates. Now I'm not saying its not possible, or even a bad idea mind - just wore work... and maybe that effort might be better spent on keeping the current momentum and quality of Gentoo as it is (or improving it)... Cheers Mark -- gentoo-user@gentoo.org mailing list I don't see why it would take that much work. If the tree was versioned, then the profile could be more significant with what was updated. Like, in the ebuild it could have a single additional entry for a minimum profile. Then, that user won't have to deal with that update until they update their profile. I'm sure there's other ways of doing that, but from what I've seen of portage and it's scripts, it is quite flexible for changes such as this. If anything, this could just be a gradual addition to new scripts instead of editing each and every ebuild. Whatever the solution is if there is going to be one at all should not be a complicated one, or it would defeat the purpose altogether. On 12/31/06, Neil Walker [EMAIL PROTECTED] wrote: Mike Myers wrote: I just wanted to add something to the original post. I've recently began experimenting with Debian and noticed their updating system is exactly like what I was asking about. Basically, there's package updates, and then there's distro updates. Why is it unreasonable for Gentoo to have something like this? I think it would help Gentoo a lot in the server market, where scalability is important. If Debian does what you want then why not go with it? What would be the point in making Gentoo like Debian? Gentoo offers a different approach which many of us like. It's all about choice - if you like Debian, choose it - but don't expect Gentoo to turn into a Debian clone. It's not going to happen. -- gentoo-user@gentoo.org mailing list The update system is the -only- nice thing about it over Gentoo. Debian is nowhere near Gentoo when it comes to everything else (especially docs). I don't think suggesting a single feature that another distro has and putting into Gentoo is trying to make it a clone. I'm just asking for a relief from having to constantly worry if updating something out of the 300 packages that need updated is going to break something, and not having to make sure etc-update isn't going to destroy my custom configs afterwards. If it wasn't for that, Gentoo would be perfect. I'm sure there's got to be others that would agree.
Re: [gentoo-user] Re: anti-portage wreckage?
On 12/31/06, Mark Knecht [EMAIL PROTECTED] wrote: Mike Myers wrote: I just wanted to add something to the original post. I've recently began experimenting with Debian and noticed their updating system is exactly like what I was asking about. Basically, there's package updates, and then there's distro updates. Why is it unreasonable for Gentoo to have something like this? I think it would help Gentoo a lot in the server market, where scalability is important. While I might personally like what you are suggesting I think that the idea fails under the load of trying to get the community to agree on what use flags/compiler flags, etc. would be the standard that all these packages are built with. Do you make the binary packages small or do you make them full featured? Do you support AMD CPU flags? Intel? Both or neither somehow? Personally I think there are so many options in Gentoo that coming up with agreement on what to do will be pretty difficult. That said if a set of binary packages were out there I'd probably investigate using it for certain machines, but most likely never my personal desktop machine. Cheers, Mark -- gentoo-user@gentoo.org mailing list I wasn't referring to the use of binary packages at all. I was only referring to how updates are managed (or lack thereof) in Gentoo. What USE flags and whatnot are set wouldn't need to be affected at all, I would think.
Re: [gentoo-user] Re: anti-portage wreckage?
On Sun, 2006-12-31 at 19:01 -0600, Mike Myers wrote: I just wanted to add something to the original post. I've recently began experimenting with Debian and noticed their updating system is exactly like what I was asking about. Basically, there's package updates, and then there's distro updates. Why is it unreasonable for Gentoo to have something like this? I think it would help Gentoo a lot in the server market, where scalability is important. Gentoo has system and world - in concept almost the same thing Apologies if this has been pointed out already. However, on most of my machines system is empty (went that way soon after each install - no idea why) so all I am left with is world. Is there any way to regen system? (like regenworld does for world?) Perhaps a system file can be manually created using only the packages from world that the user wants? BillK -- William Kenworthy [EMAIL PROTECTED] Home! -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On 12/31/06, William Kenworthy [EMAIL PROTECTED] wrote: However, on most of my machines system is empty (went that way soon after each install - no idea why) so all I am left with is world. What do mean? The system package set is defined by /usr/portage/profiles/base/packages, and extended by the packages file of whatever profile you are running. Does emerge -evp system really report no packages to merge? -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On Sun, 2006-12-31 at 21:35 -0700, Richard Fish wrote: On 12/31/06, William Kenworthy [EMAIL PROTECTED] wrote: However, on most of my machines system is empty (went that way soon after each install - no idea why) so all I am left with is world. What do mean? The system package set is defined by /usr/portage/profiles/base/packages, and extended by the packages file of whatever profile you are running. Does emerge -evp system really report no packages to merge? -Richard rattus ~ # emerge system -ep These are the packages that would be merged, in order: Calculating system dependencies ... done! rattus ~ # 3 systems like this, one installed only a few months ago works. :) BillK -- William Kenworthy [EMAIL PROTECTED] Home! -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On 12/26/06, James [EMAIL PROTECTED] wrote: Mike Myers fluffymikey at gmail.com writes: Hi! I know I don't post here much but I read it a lot and have been using Gentoo for several years now. I keep seeing users mention about how they do an update and then everything goes to crap. I've experienced this myself quite a bit too. I believe the reason this happens is the drawback one of Gentoo's nicest features; constantly being up to date. Hello MIke, Folks probably will not like my suggestions, but it works in lieu of a better schema, so aplogies to all I offend, in advance Gentoo servers (firewall, dns, mail, web ...) rarely suffer from these issues, in fact, I believe one of gentoo's largest unexplored niches should be Large Installation System Administration (via cfengine). So, in my opinion, where Gentoo is really challenged, is the workstation (laptop, desktop). You know the X11 + kde/gnome software boxen. What I do is keep one (workstation) system on the bleeding edge (very frequent upgrades) so as to discern where breakage or unecessary updates are looming. Since I admin an ever expanding hoarde of gentoo based servers and workstations, development of some tools to compile, distribute and manage the various x86 and amd64 machines we have, is way past due. As soon as I have a scheme I'm happy with, we'll be deploying lots of embedded gentoo based systems. So I update the test workstation on fridays, use it over the weekend a nd then update the other systems. Granted, if the devs release something (broken) over the weekend, I get screwed with this scheme sometimes. I should update the test system daily (in the mornings) and then update the other systems on the same day after that. Problems with that scenario is the various methods of proxying the downloads and syncs are problematic in and of themselvs, not very often, but still bad enough to make those current schemes, less than desirable. Futhermore, DistCC is still a 'work in progress' and I've experience just enough hassle that it has been disabled (also due in part to so many different variants of x86). Long story short: Gentoo is the best distro for our work, as one only has to installed debian, suse, or redhat for a week or two, to realize just how spoiled you get with Gentoo. That said, I've learned to be cautious and patient with key software upgrades on Gentoo. However this approach burns lots of extra time. My hope is Gentoo will continue to improve and become more of a 'production' distro, as the other Linux distros all seem to have unacceptable flaws, for our needs. Future: What is really needed is a group of users, with similar needs, to define commonality of core applications that are essential to the needs: What this means is a list of software, for example openoffice, kde-meta, apache, java, perl, python, C, etc. that forms a core of what we all need (not what we want). Then set up cfengine to push binaries, via a trusted mechanisms, to each of the arch categories) Maybe on a weekly basis. Each network, business or usergroup, would use their test system for 24 hours as a quarrantined update, before pushing to the rest of their machines. Or maybe push sources that are know good, to the test server at each participating location. If fact what the one (initially) master server environment sets up uses, could be duplicated at any remote location with a group of systems. Individuals could feed (download binaries) from those locations, with the proper security mechanisms agreed to. If a group of locations with multiple systems use a common update semantic, then it would be a lot less work, as opposed to each cleaver admin, rolling their own solution. If something actually worked reasonable well, talented admins could offer this service to commercial clients, thus generating excitement about gentoo, and funding for many needy geeks. If you only have one or 2 gentoo sytems, something like this is not worth the effort. For those of us looking to manage dozens to hundreds of gentoo based systems, the need for some management scheme, is long overdue. JFFNMS goes a LONG way to solving the problem, but, it is not centric to the needs of gentoo systems. A companion project that addresses all of those gentoo_centric issues could compliment JFFNMS and simultaneously created that quintessential opportunity for Gentoo to really shine, compared to it's competition. James -- gentoo-user@gentoo.org mailing list I think I like your idea better, about distributing binaries. Do you know if something like this is being worked on? I'm certain that a common method to this, like what you're saying, would allow Gentoo to become scalable to the point of being easily usable on a large scale.
Re: [gentoo-user] Re: anti-portage wreckage?
On 12/27/06, James [EMAIL PROTECTED] wrote: Mike Myers fluffymikey at gmail.com writes: I think I like your idea better, about distributing binaries. Do you know if something like this is being worked on? I'm certain that a common method to this, like what you're saying, would allow Gentoo to become scalable to the point of being easily usable on a large scale. It's a lot of work. I'll be pusing binaries to lots of systems, but, it going to take me months to get ready. I was hoping others with similar goals would 'band together' to come up with a solution that combines the needs for the casual user as well as those of us that want to manage dozens to hundres of Gentoo systems. I need to refine the idea, and my goal is mostly embedded gentoo sytems, but, they are very similar to gentoo-servers. Expanding the idea to workstation, at least for core software, is not that difficult. I do not intend to get into 'competiion' with the devs, particularly on applications that are big, complex, or prone to breakage (OO) It'd really be better to do this as a group, but, I've found little interest, most probably due to the fact that most folks are already bogged down with their own ambitions. James -- gentoo-user@gentoo.org mailing list I honestly believe there's a lack of interest in such thing because most Gentoo users use it as their home computer. The fact that Gentoo doesn't scale very well prevents that market from growing at all, and I think that's why there's a lack of interest in supporting such a thing. It's kind of like a chicken and egg thing. I don't think setting something like this up would be competing with the devs, unless they already had something in mind, since a project like this would only be proxying packages and adding another package management layer to portage. I could be wrong though, I guess if you or whoever came up with a solution we would see. I don't have strong enough development skills to help handle something like that though, but I'd love to test it out.
[gentoo-user] Re: anti-portage wreckage?
Mike Myers fluffymikey at gmail.com writes: Hi! I know I don't post here much but I read it a lot and have been using Gentoo for several years now. I keep seeing users mention about how they do an update and then everything goes to crap. I've experienced this myself quite a bit too. I believe the reason this happens is the drawback one of Gentoo's nicest features; constantly being up to date. Hello MIke, Folks probably will not like my suggestions, but it works in lieu of a better schema, so aplogies to all I offend, in advance Gentoo servers (firewall, dns, mail, web ...) rarely suffer from these issues, in fact, I believe one of gentoo's largest unexplored niches should be Large Installation System Administration (via cfengine). So, in my opinion, where Gentoo is really challenged, is the workstation (laptop, desktop). You know the X11 + kde/gnome software boxen. What I do is keep one (workstation) system on the bleeding edge (very frequent upgrades) so as to discern where breakage or unecessary updates are looming. Since I admin an ever expanding hoarde of gentoo based servers and workstations, development of some tools to compile, distribute and manage the various x86 and amd64 machines we have, is way past due. As soon as I have a scheme I'm happy with, we'll be deploying lots of embedded gentoo based systems. So I update the test workstation on fridays, use it over the weekend a nd then update the other systems. Granted, if the devs release something (broken) over the weekend, I get screwed with this scheme sometimes. I should update the test system daily (in the mornings) and then update the other systems on the same day after that. Problems with that scenario is the various methods of proxying the downloads and syncs are problematic in and of themselvs, not very often, but still bad enough to make those current schemes, less than desirable. Futhermore, DistCC is still a 'work in progress' and I've experience just enough hassle that it has been disabled (also due in part to so many different variants of x86). Long story short: Gentoo is the best distro for our work, as one only has to installed debian, suse, or redhat for a week or two, to realize just how spoiled you get with Gentoo. That said, I've learned to be cautious and patient with key software upgrades on Gentoo. However this approach burns lots of extra time. My hope is Gentoo will continue to improve and become more of a 'production' distro, as the other Linux distros all seem to have unacceptable flaws, for our needs. Future: What is really needed is a group of users, with similar needs, to define commonality of core applications that are essential to the needs: What this means is a list of software, for example openoffice, kde-meta, apache, java, perl, python, C, etc. that forms a core of what we all need (not what we want). Then set up cfengine to push binaries, via a trusted mechanisms, to each of the arch categories) Maybe on a weekly basis. Each network, business or usergroup, would use their test system for 24 hours as a quarrantined update, before pushing to the rest of their machines. Or maybe push sources that are know good, to the test server at each participating location. If fact what the one (initially) master server environment sets up uses, could be duplicated at any remote location with a group of systems. Individuals could feed (download binaries) from those locations, with the proper security mechanisms agreed to. If a group of locations with multiple systems use a common update semantic, then it would be a lot less work, as opposed to each cleaver admin, rolling their own solution. If something actually worked reasonable well, talented admins could offer this service to commercial clients, thus generating excitement about gentoo, and funding for many needy geeks. If you only have one or 2 gentoo sytems, something like this is not worth the effort. For those of us looking to manage dozens to hundreds of gentoo based systems, the need for some management scheme, is long overdue. JFFNMS goes a LONG way to solving the problem, but, it is not centric to the needs of gentoo systems. A companion project that addresses all of those gentoo_centric issues could compliment JFFNMS and simultaneously created that quintessential opportunity for Gentoo to really shine, compared to it's competition. James -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: anti-portage wreckage?
On 26 December 2006 17:56, James wrote: So I update the test workstation on fridays, use it over the weekend a nd then update the other systems. Granted, if the devs release something (broken) over the weekend, I get screwed with this scheme sometimes. I should update the test system daily (in the mornings) and then update the other systems on the same day after that. From my experience, another approach is easier and safer. If your test workstation and your productions workstation are basically equivalent (as far as their world files are concerned, *not* their hardware) you can just NFS mount your test box's portage tree on your production box and update it from there. I will not download new packages but use the ones on your test box tested over the weekend. Problems with that scenario is the various methods of proxying the downloads and syncs are problematic in and of themselvs, not very often, but still bad enough to make those current schemes, less than desirable. Futhermore, DistCC is still a 'work in progress' and I've experience just enough hassle that it has been disabled I disagree here. I have used distcc without any major problem for at least one year by now. (also due in part to so many different variants of x86). This doesn't affect distcc. The slave compiles a a C or C++ according to the specs of the master. The master runs the source file through its preprocessor and sends the result with all necessary commandline options over to the slave. Those options contain the desired architecture/CPU of your master. The slave compiles the preprocessor output, runs that result through its assembler and transfers the resulting object file back to the master which, eventually, links it. So don't worry about different CPUs within the x86 domain or different libraries. Just have the same compiler version installed on all participating boxes. It's a bit more difficult if a slave has a completely different architecture. In that case, you need to install cross compilations system for the master on that particular slave. Long story short: Gentoo is the best distro for our work, as one only has to installed debian, suse, or redhat for a week or two, to realize just how spoiled you get with Gentoo. That said, I've learned to be cautious and patient with key software upgrades on Gentoo. However this approach burns lots of extra time. My hope is Gentoo will continue to improve and become more of a 'production' distro, as the other Linux distros all seem to have unacceptable flaws, for our needs. I full-heartedly agree here. Uwe -- A fast and easy generator of fractals for KDE: http://www.SysEx.com.na/iwy-1.0.tar.bz2 -- gentoo-user@gentoo.org mailing list
