Language Selection

English French German Italian Portuguese Spanish

Debian and Ubuntu Leftovers

Filed under
Debian
Ubuntu
  • Bootstrappable Debian BoF

    Greetings from DebConf 19 in Curitiba! Just a quick reminder that I will run a Bootstrappable Debian BoF on Tuesday 23rd, at 13.30 Brasilia time (which is 16.30 UTC, if I am not mistaken). If you are curious about bootstrappability in Debian, why do we want it and where we are right now, you are welcome to come in person if you are at DebCon or to follow the streaming.

  • Candy Tsai: Outreachy Week 6 – Week 7: Getting Code Merge

    You can’t overhear what others are doing or learn something about your colleagues through gossip over lunch break when working remotely. So after being stuck for quite a bit, terceiro suggested that we try pair programming.

    After our first remote pair programming session, I think there should be no difference in pair programming in person. We shared the same terminal, looked at the same code and discussed just like people standing side by side.

    Through our pair programming session, I found out that I had a bad habit. I didn’t run tests on my code that often, so when I had failing tests that didn’t fail before, I spent more time debugging than I should have. Pair programming gave insight to how others work and I think little improvements go a long way.

  • about your wiki page on I/O schedulers and BFQ
    Hi,
    this is basically to report outdated statements in your wiki page on
    I/O schedulers [1].
    
    The main problematic statement is that BFQ "...  is not ideal for
    devices with slow CPUs or high throughput I/O devices" because too
    heavy.  BFQ is definitely more sophisticated than any of the other I/O
    schedulers.  We have designed it that way to provide an incomparably
    better service quality, at a very low overhead.  As reported in [2],
    the execution time of BFQ on an old laptop CPU is 0.6 us per I/O
    event, against 0.2 us for mq-deadline (which is the lightest Linux I/O
    scheduler).
    
    To put these figures into context, BFQ proved to be so good for
    "devices with slow CPUs" that, e.g., Chromium OS migrated to BFQ a few
    months ago.  In particular, Google crew got convinced by a demo [3] I
    made for them, on one of the cheapest and slowest Chromebook on the
    market.  In the demo, a fast download is performed.  Without BFQ, the
    download makes the device completely unresponsive.  With BFQ, the
    device remains as responsive as if it was totally idle.
    
    As for the other part of the statement, "...  not ideal for ...  high
    throughput I/O devices", a few days ago I ran benchmarks (on Ubuntu)
    also with one of the fastest consumer-grade NVMe SSDs: a Samsung SSD
    970 PRO.  Results [4] can be summarized as follows.  Throughput with
    BFQ is about the same as with the other I/O schedulers (it couldn't be
    higher, because this kind of drives just wants the scheduler to stay
    as aside as possible, when it comes to throughput).  But, in the
    presence of writes as background workload, start-up times with BFQ are
    at least 16 times as low as with the other I/O schedulers.  In
    absolute terms, gnome-terminal starts in ~1.8 seconds with BFQ, while
    it takes at least 28.7 (!) seconds with the other I/O schedulers.
    Finally, only with BFQ, no frame gets lost in video-playing
    benchmarks.
    
    BFQ then provides other important benefits, such as from 5x to 10X
    throughput boost in multi-client server workloads [5].
    
    So, is there any chance that the outdated/wrong information on your
    wiki page [1] gets updated somehow?  If I may, I'd be glad to update
    it myself, after providing you with all the results you may ask.
    
    In addition, why doesn't Ubuntu too consider switching to BFQ as
    default I/O scheduler, for all drives that BFQ supports (namely all
    drives with a maximum speed not above ~500 KIOPS)?
    
    Looking forward to your feedback,
    Paolo
    
    
  • Should Ubuntu Use The BFQ I/O Scheduler?

    The BFQ I/O scheduler is working out fairly well these days as shown in our benchmarks. The Budget Fair Queueing scheduler supports both throughput and low-latency modes while working particularly well for consumer-grade hardware. Should the Ubuntu desktop be using BFQ by default?

    [...]

    But in addition to wanting to correct that Wiki information, Paolo pops the question of why doesn't Ubuntu switch to BFQ as the default I/O scheduler for supported drives. Though as of yet, no Ubuntu kernel developers have yet commented on the prospect of switching to BFQ.

More in Tux Machines

FreeBSD Quarterly Status Report

We also provide some up to date information about the status of our IRC channels Read more Also: FreeBSD In Q2'2019 Saw Updated Graphics Drivers, Continued Linux Compatibility Layer

DragonFlyBSD Pulls In AMD Radeon Graphics Code From Linux The 4.7 Kernel

It was just last month that DragonFlyBSD pulled in Radeon's Linux 4.4 kernel driver code as an upgrade from the Linux 3.19 era code they had been using for their open-source AMD graphics support. This week that's now up to a Linux 4.7 era port. François Tigeot who continues doing amazing work on pulling in updates to DragonFlyBSD's graphics driver now upgraded the Radeon DRM code to match that of what is found in the upstream Linux 4.7.10 kernel. Read more

Android Leftovers

TenFourFox FPR16b1 available

FPR16 got delayed because I really tried very hard to make some progress on our two biggest JavaScript deficiencies, the infamous issues 521 (async and await) and 533 (this is undefined). Unfortunately, not only did I make little progress on either, but the speculative fix I tried for issue 533 turned out to be the patch that unsettled the optimized build and had to be backed out. There is some partial work on issue 521, though, including a fully working parser patch. The problem is plumbing this into the browser runtime which is ripe for all kinds of regressions and is not currently implemented (instead, for compatibility, async functions get turned into a bytecode of null throw null return, essentially making any call to an async function throw an exception because it wouldn't have worked in the first place). This wouldn't seem very useful except that effectively what the whole shebang does is convert a compile-time error into a runtime warning, such that other functions that previously might not have been able to load because of the error can now be parsed and hopefully run. With luck this should improve the functionality of sites using these functions even if everything still doesn't fully work, as a down payment hopefully on a future implementation. It may not be technically possible but it's a start. Read more