if you have a slow upgrade that's almost all caused by the repo you are using, the us debian repos have been horribly slow for longer than I can remember now, I do not use them.

I won't use axel because I refuse to introduce myself and users to an entirely new set of bugs, the scripts already handle the known and present wget bugs, I have zero desire to now discover the unknown and unhandled axel bugs. Note that such bugs are not discovered by saying: it works fine for me, but rather, when you introduce the method to thousands of different users, with different web connections, different isps, different routers, different dns servers used, and so on. There's no way I would voluntarily subject myself to trying to debug not one, but two different download agents, coupled with what is almost certainly a buggy and unreliable apt tool, apt-fast, which just a quick perusal of the comments on that page you linked to show is the case.

Also,. any download boost is totally illusory, I use fast debian repos and my download speed is precisely what my ISP rated download speed is, so the notion that a 26x gain can be had is simply absurd.

However, note again, the us.debian repos are HORRIBLY slow, I would in fact consider them totally broken, like 15kB per second type broken. But other repos on the default Debian repo list are just fine, and speed right along.
Back to top

Hi,
Thanks for the quick response. I understand your reasoning with regards to axel. I'm also sceptical of 26x speed, but what think it does is use several repositories at once. I went from approx 75kb to 750kb. This could be for a number of reasons, but it does seem to show a significant gain. Apparently, the folks over at pclinux are looking into using it. Still I do understand your reluctance in modifying something that works as well as smxi does.
Again, thanks for all your work.
arthrotec
Back to top

Again, the solution to the slow repo problem is to dump the slow repos and replace them with properly functioning ones. Since the slow ones are either or both overburdened/misconfigured, why stress them anymore, they aren't working, and haven't been for years.

All apt-fast will do is then overburden these repos, which already don't work right, and hit 10x more of them, in your case, which just slows them down more for everyone even as you get your local download sped up. Hardly something I want to support or encourage in smxi, if you see what I mean, that doesn't help Debian at all, it hurts them. Hardly a way to improve Debian's debian.org apt repos I'd say.

In a sense, this apt fast thing is a bandage that tries to remedy some other core problem in the debian official mirrors, the problem should be fixed if it can be fixed, or if it can't, Debian should start pointing people away from their debian.org servers if they can't get them running right, or can't get the bandwidth they need donated or whatever they do. Bandwidth is expensive in the real world, by the way.

I noted these issues because they were so obvious some years ago, i don't know what is wrong with Debian's servers, if it's just bandwidth, or if something is technically wrong with them or their configuration (my guess sad to say is a bit of both, more of the latter than the former).

There are tons of repos out there that will feed you the debs very fast, just look around and find one, depends on your region / area. Before I totally gave up on all the official debian.org repos, I made in smxi the debian repo switcher tool (smxi -m / or in advanced tweaks) for exactly this reason, but it requires that you are using a repo in debian.org , like us.debian.org in order to switch them.

By far the worst I have found, by the way, is us.debian.org that one has been largely unusable for more years than I can now remember, I don't know why that situation persists, it makes debian US look kind of bad in my opinion.

We found in the US that the japanese or dutch repos tended to be faster, but eventually I found that all of them bogged down until they became unusable, so I stopped using the debian.org ones.
Back to top

It would be nice to have an option in sgfxi to make a DKMS module to automatically reinstall the graphical drivers on kernel updates. That way, sgfxi doesn't need to be run more tahn necessary (or if you just want to change driver versions to install).
Back to top

I can't remember if the build distro driver option in sgfxi has the dkms package for nvidia, I'll have to double check that.

However I'm definitely not going to create any dkms gunk for the standard driver install because that just creates long term support issues, ie, why does dkms fail to build module when xorg/ kernel upgrades to a new major version etc, but maybe as an extra option if someone provides the code required, ideally that works in debian, ubuntu, fedora, and arch.

Since I never use dkms I'm not a good person to write that code, but if explicitly clear and complete steps are provided I can of course script them, but they must be totally complete, ie, if I know nothing, the steps will work for my system, and all other systems, 32 / 64 bit, out there..
Back to top

Is possible add in some section the possibility to give more command in a single step? Now I'll explain better. When we are in the non free section (for example) we often install 4 or 5 packages, to do it more fast, is possible add the option to write not only a number but a list?

current working flow:
2 (press enter)
3 (press enter)
5 (press enter)

fast flow:
2 3 5 (press enter) and smxi perform the list of option chosen.

Thank you.
Back to top

it's possible but would require rewriting a huge amount of code, so it's unlikely to happen unless someone can think of a very clean non-invasive way of doing it. Bash is already being pushed to its functional limits in smxi, and this would add a layer of complexity it might be hard to justify, unless, again, someone comes up with a super clean method that can be inserted quite cleanly into the existing code base.

Technically this would require pulling out every single embedded select option list and putting into a loop. Or something like that.

Unless some bash trick could be made to work, of course, never know, bash is a very weird structure and sometimes permits strange things sane languages would not permit.
Back to top

I took a quick look at this multiple choice option, it's not possible without a huge rewrite.

Bash Select operator is a very specific item, and does not permit any customizations I can see.

Behind the scenes it translates automatically the number you enter to the string equivalent, which is what it uses internally to do the actual selection.

The act of hitting enter for the number/ string is a trigger somewhat like 'read $variable' is for a read type selection item, one where users input their data.

So the only way to handle that would be to remove the select, which are chosen because they are easy to use and maintain, and replace them with read lists, which would then require typing in either numbers or the item string.

Not beautiful, and really not a solution I would consider as desirable. Select lists also create those numbered/string selection lists automatically.

So no, in the world of bash, this type of advanced method you asked about is well beyond the capabilities of bash in any non-invasive sense, so you'll have to deal with hitting a number a few times per setup, sorry.

Or just script your common things yourself, put the script on a server with a short name that's easy to remember, then use the built in smxi external script import method, -X scriptname#scripturl and the script will be downloaded and run when you select scriptname from the post du option list. That's what that feature is for by the way, letting users run web based scripts from inside of smxi.
Back to top

Thank you H2 for the analysis of the problem and for the exhaustive answer.
Back to top

i found ceni 2.23 on a mirror site, when i was looking for some updates:
www.mirrorservice.org/sites/sidux.com/sidux/debian/pool/main/c/ceni/
and i noticed that smxi installs ceni 2.21 in the package install section. i don't know if smxi needs an updated version of ceni or the one in smxi is better than this one.
also does ceni have an official site or is it mainly an aptosid project?
thanks.
Back to top