1. 09 5月, 2021 1 次提交
  2. 05 5月, 2021 1 次提交
  3. 03 5月, 2021 1 次提交
  4. 30 4月, 2021 3 次提交
  5. 29 4月, 2021 2 次提交
  6. 28 4月, 2021 1 次提交
  7. 25 4月, 2021 1 次提交
  8. 24 4月, 2021 2 次提交
    • P
      [misc] update ChangeLog for BETA · 2bcb68ef
      Pete Batard 提交于
      * Since Ubuntu 21.04 forces a new release...
      * Also update DB for latest GRUB "2.04" and fix a minor loc capitalization issue
      2bcb68ef
    • P
      [ui] add forced DD mode exceptions for Red Hat based distros · 9c8fa409
      Pete Batard 提交于
      * Anaconda broke ISO compatibility, most likely with the following commit:
        https://github.com/rhinstaller/anaconda/commit/84529204fe02300b9829da41099a8254dc2a1c54
      * However, Ret Hat, and its followers, have drunk the "DD only" kool aid, and
        appear to be blissfully unaware of the very real drawbacks that enforcing a
        "DD only" mode for ISOHybrid can actually place on distro users.
      * Rather than spend another wasted effort trying get people, who appear to be
        impervious to even remotely consider the idea that DD imaging can have flaws,
        to look into the possibility that Red Hat might indeed have introduced a
        regression, and given the downright hostility I have been subjected to from
        trying to state this *very verifiable* fact, we'll just force DD mode for the
        affected Red Hat and derivatives, whilst trusting that users will be smart
        enough to compare their more limited installation experience against the ones
        from other distros (such as Arch, Debian or Ubuntu, which, unlike Red Hat and
        co., appear to fully understand that the whole ISOHybrid vs DD mode situation
        is not all black and white), and see for themselves which distros do actually
        place *their* interests first, rather than just the interests of the distro
        maintainers...
      9c8fa409
  9. 23 4月, 2021 3 次提交
    • P
      [misc] UFD vs HDD detection improvements · 16c0e8e2
      Pete Batard 提交于
      16c0e8e2
    • P
      [grub] add yet another frigging patch to GRUB "2.04" · 252759eb
      Pete Batard 提交于
      * GRUB 2.0 maintainer think they're doing a fine job, even when there are
        CRITICAL SECURITY FIXES that should warrant an immediate out of bound
        release, and instead consider that waiting MONTHS or YEARS to release
        anything is not a big deal at all.
      * Ergo, distros, such as Ubuntu, start to pick whatever security patches
        they see fit, since they can simply not RELY on the upstream project to
        produce security releases in a timely manner. One such patch is:
        https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00012.html
      * But since there is no new GRUB release per se, they still call their GRUB
        version, onto which they applied patches that have come into existence
        more than 2 years after the actual 2.04 release, "GRUB 2.04".
      * Obviously, since GRUB 2.04 + literally hundreds of cherry picked patches
        does deviate a lot from the last release, THINGS BREAK IN SPECTACULAR
        FASHION, such as the recently released Ubuntu 21.04 failing to boot with
        the error: grub_register_command_lockdown not found.
      * Oh, and of course, regardless of all the above, if you ask anyone, they'll
        tell you that there's nothing fundamentally wrong with the GRUB release
        process (even if they should long have released 2.05, 2.05-1 and 2.05-2,
        were their maintainer ready to acknowledge that delaying releases DOES
        CREATES MAJOR ISSUES DOWSTREAM, as many people REPEATEDLY pointed to them
        on the GRUB mailing list) or with the Ubuntu GRUB versioning process (that
        really shouldn't be calling their version of GRUB "grub-2.04" but instead
        something like "grub-2.04_ubuntu"). Oh no siree! Instead, the problem must
        all be with Rufus and its maintainer, who should either spend their lives
        pre-emptively figuring which breaking patch every other distro applied out
        there, or limit media creation to DD mode, like any "sensible" person
        would do, since DD mode is the ultimate panacea (Narrator: "It wasn't").
      * So, once again, a massive thanks to all the people who have been involved
        in the current GRUB 2.0 shit show, whose DIRECT result is to make end
        users' lives miserable, while GRUB maintainers are hell bent on continuing
        to pretend that everything's just peachy and are busy patting themselves
        on the back on account that "Fedora recently dropped more than 100 of the
        custom patches they had to apply to their GRUB fork" (sic). Nothing to see
        here, it's just GRUB maintainer's Jedi business as usual. Besides, who the
        hell cares about Windows users trying to transition to Linux in a friendly
        manner anyway. I mean, as long as something doesn't affect existing Linux
        users, it isn't a REAL problem, right?...
      252759eb
    • P
      [misc] add regexp engine · 8f0d248a
      Pete Batard 提交于
      * From https://github.com/kokke/tiny-regex-c
      8f0d248a
  10. 22 4月, 2021 2 次提交
    • P
      [core] switch to async I/O for image writing · a0904cad
      Pete Batard 提交于
      * Combined with the increase in buffer size from previous commits, this
        should help us get close to a device's maximum write speed.
      * Also add async write support to winio.h
      * Also increase the buffer size for bad blocks check operations
      a0904cad
    • P
      [core] split zeroing and dd write operations · 80eca573
      Pete Batard 提交于
      * This is in preparation for async reads
      * Also move open/close image operations to WriteDrive()
      * Also increase DD buffer size to 32 MB to improve performance
      80eca573
  11. 15 4月, 2021 1 次提交
  12. 14 4月, 2021 1 次提交
  13. 12 4月, 2021 2 次提交
  14. 09 4月, 2021 3 次提交
  15. 08 4月, 2021 1 次提交
  16. 07 4月, 2021 1 次提交
  17. 06 4月, 2021 1 次提交
  18. 04 4月, 2021 3 次提交
  19. 03 4月, 2021 3 次提交
  20. 02 4月, 2021 7 次提交