I find mildly annoying that I cannot download all secondary files bootloaders like syslinux or grub at once and have them always with me so I can use rufus even when offline. The text was updated successfully, but these errors were encountered:. I don't want to add such a feature.
Very few people would need and it would be a poor return on investment for me. I'd have to add and maintain a web crawler a la HTTrack in Rufus just so that a few people, who aren't part of the user group Rufus is designed for, can do sysadmin stuff. First of all, this sounds a lot like feature creep, and as I have to repeat a lot more than I'd like but Rufus is NOT designed to help sysadmin and power users, or even make their lives easier which, for instance, is why I will never implement multiboot.
It is targeted at the single usage regular crowd, who have an internet connection on the machine they create the USB on. As such, going out of my way to facilitate offline usage is not something I have any plans for. Sorry, something went wrong.
You can just bundle all files rufus executable and these additional files already in the folder in a single zip that is downloaded together by the user himself, instead of having the user download only rufus, and then have rufus download stuff on demand. This can be done with a 2-line bash server-side script, and will require 0 mainteneance on your side. If you drop the code dealing with this download-on-demand, you can even have less stuff to maintain, win-win.
FYI, most power users and sysadmins are able to do tethering with their phones so it's not like this is a major issue for them that's how I worked around the issue when in the field. For the more normal users it can be an issue. That's why I thought it could be good to report this. Famous last words, always proffered by the very person who wouldn't be involved with said maintenance.
Let's be honest here: You are rather selfishly asking me to spend time, which I have in limited supply, just so you can avoid having to use httrack or any other directory slurper. That's not gonna happen. So I will respectfully ask you to please do your monitoring and slurping of the files in your own time.
F stands for frequently. I genuinely don't expect a question, with an obvious answer, about the best way to slurp the files to be asked that frequently. So, I'm afraid this wouldn't qualify for the FAQ though I do have a line about telling people more precisely where they should copy the downloaded files, if Rufus can't do it for them, as part of - but this is a different matter. Kinda, my main motives are that I'd rather not have to workaround client-side when I could have it fixed server-side, so to speak.
I hate having to workaround bad design. And "needs internet to work" when it really does not, is bad design in my book. And now I offer you to make this script myself as I have downloaded your site so I know its folder structure, I also have some experience in scripting and linux server administration, although it's a very minor thing any decent linux user could do , and post it here for you to load it in the server on a cron job.
Does this make me a worthy contributor and not just a selfish asshole asking you to work for free? So tell me, you were getting asked frequently about the various stuff you have in cheat codes? Most look very very exotic to me and I'm a power user with a job in IT.
The most needed thing imho is a link to the webpage to download the files, as that isn't easy to reach without looking at the source rufus. Are seriously positing that the application should be quite a few MB larger so that it includes all the files one might possibly need? So that's way to suddenly make the application a lot less user friendly, when usage without an internet connection is the exception rather than the norm.
Also, even if I was happy to suddenly have everyone who downloads Rufus spend 10 times as long waiting for their download to complete a small footprint, which is one of my actual design goals, tends to make for good user experience who's gonna pay for the extra bandwidth costs?
So, I'm going to have to repeat that the app is not designed for your specific usage pattern, and trying to make it closer to what you want would end up making it worse for a vast majority of users. Besides, if you really want to make Rufus more suitable for your usage, the source is very much inviting you to do it, so it's not like you don't have any options there.
That's not the case. The users I do target must have an internet connection on the machine they create the USB on be it only to be notified from a critical update, in case there is a bug or incompatibility in the app, which is usually a good thing.
For instance, I half expect the next Windows refresh to break Rufus' DD image mode, so I sure hope Rufus users do have a valid internet connection and chose to enable the update check. But, as I pointed out earlier, I'm still planning to add a line on how to manually obtain the files in case you can't download them in the FAQ, as part of Not gonna add a cron job on the server just to keep a single person happy.
And since you are mistakenly asserting that this might be the case, it's not the technical difficulty that makes me reject that proposal. I don't need someone to provide me with a ready made script. I just don't want to customize the server for single person's usage. And that's the same answer I gave to people who wanted me to upload new version release notes, on the server, in a format that they could parse with run of the mill tools, as well as countless other very specific requests I had over the years.
Besides translations for the homepage, I don't accept contributions to modify the server's content, even if it's a very simple script. The FAQ entry is there to describe what the cheat codes are. In other words, the frequent thing I am being asked is "Do you have a cheat mode list?
The vast majority of the cheat modes is actually stuff that, I, the developer, thought might come handy, mostly for troubleshooting, but not stuff that I was explicitly requested to add. So I'm afraid that your premise is wrong there: the list is what I was frequently requested, NOT the individual cheats. Which I'm planning to do as part of when i get around to it. If you have a custom scenario where you need a bunch of files to be available offline, I would encourage you to create your own version of Rufus that suits this need.
Sorry, something went wrong. Most recent Live Fedora, Debian, Parabola It simply shows error complaining it can't connect to server and stops. Yesterday I've tried with Fedora 27 Live Beta, failed again. This because. As to providing an offline download, no, that's not gonna happen as this would only be helpful for a handful of power users.
FYI, I just ran this exact test against Debian's debian Rufus will of course complain that it can't access the files, but, as this test validates, it is able to complete and, provided that you are using a modern distro that didn't do anything too fancy with its bootloader, the resulting USB will actually be bootable. Thus, I'm afraid that your statement that Rufus FAILS for recent distros, such as latest Debian, when used on a non-connected machine, can be disproved as factually incorrect, which, again, goes towards the point that I was trying to make earlier, that what you are asking for should be irrelevant in a lot of cases.
Just tested debian-live May I suggest that you run some more tests, or provide more details on how you ran them, because what I'm observing through verifiable methodology is a bit different from the picture you are trying to paint Well, the error you get on download failure is obviously different from the one I'd expect from a truly disconnected machine which is why you should ALWAYS provide a log, even if you don't think it's relevant.
There's a possibility that Windows handles non-internet connected LAN vs completely offline in a manner that changes the deal in terms of error handling, so I'll check that out obviously, since I expect Windows to behave in pretty much the same way for these 2 scenarios, and my time is limited, I only tested the easiest for me to check, which was "just unplug the cable".
But that's about as far as I'll go, as, at least for recent Debian, the fallback should work provided Windows networking does not freeze the app on error That's probably it. I just tested the same as above in an online pc but with Rufus blocked by firewall, and obviously got the same problem, You should reopen this and try to fix it.
Well, the thing is, if I try nonexistent URLs, I still get a proper non-blocking error such as Unable to send request: The server name could not be resolved. So, it looks to me like your firewall is doing something dodgy to connection requests, and, sorry, but no, if you're using software that prevents an application to actually perform the tasks it was designed to perform i.
So, it looks to me like your firewall is doing something dodgy to connection requests, and, sorry, but no, if you're using software that prevents an application to actual perform the tasks it was designed to perform, then you're on your own. As I told you, the firewall scenario was an extra test that actually give me the same problem. What it looks to me that you're trying to ditch this asap.
The log I posted above was from a test run in a LAN setup basically there's no internet available at all, computers are connected to each other. I can't 'help' you more than this. I think it was very clear that the fallback mechanism doesn't always work. Unplugging the Ethernet cable shouldn't be the solution for this problem.
Actually I just tested it. It does give you the option to select DD after you press start. Rufus 3. You can say yes to download the files if it does not allow you to go further, but those files are not used if you select DD mode.
When selecting DD mode, Rufus is doing a byte-for-byte copy of the qubes. Every byte starting from byte 0 of the USB drive will match your qubes. ISO mode does not copy byte-by-byte. It installs its own bootloader, reformats and partitions the USB drive, then copies files within the qubes.
0コメント