Skip to main content

Chromium vs Gnome Panel

Chromium starts up and opens my pinned tabs: Gmail, Gcalendar & Greader before gnome panel appears... Also network manager sometimes is slow to bring up WiFi even though my home network is set up to be used by all users, resulting in failed to load in chromium.

Comments

  1. Browsers shouldn't announce that the page failed to load, they should say "Waiting for internet connection" or something. I hate how I have to go through all my tabs and hit F5 every time chrome loads starts faster than networkmanager gets on my wifi (100% of the time, Intel X-25M SSD).

    ReplyDelete
  2. What should the browser do if the network is really down? I don't think the bug is in the browser. I think the bug is in the system starting Apps before the system is up. I hate the same kind of behavior in windows. It's basic sequencing. Start network, then network apps.

    The network ought to start before the user's apps, since you don't know which ones will need the network. You wouldn't start running user apps before you've mounted everything in the fstab. You don't want every app to write it's own logic to guess if the system is still coming up or if the system is just broken. I've had to write software like that with timeout loops and multiple strategies for determining if it needs to wait a little more or if it needs to give up. Once you give up on the last failure you have to guess what kind of message to give the user to explain the error. The user experience is catastrophic in failure cases.

    It sounds to me like Gnome needs to better organize startup dependencies.

    ReplyDelete
  3. I agree with Edward. If you have apps that needs a network connection, they should start up after the PC sees the network. Gnome should have enough smarts to realise what apps require the network, eg browsers, web apps, ultilities etc. Is that possible?

    I came across the problem with CheckGmail on startup. CheckGmail would fail because wifi hadn't started yet, so not knowing anything about scripts I had to search the internet for someone who had written a simple time delay script. That's all it needed. The year is 2010, and this simple feature should of been designed in long ago.

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete
  5. The point about desktop is to bring up web-browser as soon as possible in working state. In 15 seconds I can read an email and start replying. I wonder if upstart can be used to trigger web-browser as soon as network is up?

    ReplyDelete
  6. The way I read it, systemd will also be for this.

    ReplyDelete
  7. 1. If you were to set your network credentials as system-wide, you would probably have network by the time you log in.

    2. gnome-session has no idea if an application needs the network when it starts it up, so you would have to have every application author update their .desktop files to flag requirements. Not pretty. Then wait for network to start applications that want 'network'. But what if you connect to a non-routable network? Or what if you have no network, but your application supports offline mode (think tomboy or gtg, both can 'sync' with the network, but that is not required).

    3. NM already emits a dbus signal on connect. The correct method would be to update applications to listen for that signal and re-run their failed network-related functions when it is received (whether it be fetching a web page, syncing notes, etc). Fixing the issue in Chromium would solve network related issues at times that are not startup, as well.

    ReplyDelete
  8. I agree with Sequentious. That sounds like the right way to do it. I have Evolution start on system start up and it works almost exactly this way (it actually attempts a connection before it realises there is none and switches to offline mode). When NM connects, Evolution also connects and gets mail. Very neat.

    ReplyDelete

Post a Comment

Popular posts from this blog

How to disable TLS 1.0 and TLS 1.1 on Ubuntu

Example of website that only supports TLS v1.0, which is rejected by the client Overivew TLS v1.3 is the latest standard for secure communication over the internet. It is widely supported by desktops, servers and mobile phones. Recently Ubuntu 18.04 LTS received OpenSSL 1.1.1 update bringing the ability to potentially establish TLS v1.3 connections on the latest Ubuntu LTS release. Qualys SSL Labs Pulse report shows more than 15% adoption of TLS v1.3. It really is time to migrate from TLS v1.0 and TLS v1.1. As announced on the 15th of October 2018 Apple , Google , and Microsoft will disable TLS v1.0 and TLS v1.1 support by default and thus require TLS v1.2 to be supported by all clients and servers. Similarly, Ubuntu 20.04 LTS will also require TLS v1.2 as the minimum TLS version as well. To prepare for the move to TLS v1.2, it is a good idea to disable TLS v1.0 and TLS v1.1 on your local systems and start observing and reporting any websites, systems and applications that

Ubuntu 23.10 significantly reduces the installed kernel footprint

Photo by Pixabay Ubuntu systems typically have up to 3 kernels installed, before they are auto-removed by apt on classic installs. Historically the installation was optimized for metered download size only. However, kernel size growth and usage no longer warrant such optimizations. During the 23.10 Mantic Minatour cycle, I led a coordinated effort across multiple teams to implement lots of optimizations that together achieved unprecedented install footprint improvements. Given a typical install of 3 generic kernel ABIs in the default configuration on a regular-sized VM (2 CPU cores 8GB of RAM) the following metrics are achieved in Ubuntu 23.10 versus Ubuntu 22.04 LTS: 2x less disk space used (1,417MB vs 2,940MB, including initrd) 3x less peak RAM usage for the initrd boot (68MB vs 204MB) 0.5x increase in download size (949MB vs 600MB) 2.5x faster initrd generation (4.5s vs 11.3s) approximately the same total time (103s vs 98s, hardware dependent) For minimal cloud images that do not in

Ubuntu Livepatch service now supports over 60 different kernels

Linux kernel getting a livepatch whilst running a marathon. Generated with AI. Livepatch service eliminates the need for unplanned maintenance windows for high and critical severity kernel vulnerabilities by patching the Linux kernel while the system runs. Originally the service launched in 2016 with just a single kernel flavour supported. Over the years, additional kernels were added: new LTS releases, ESM kernels, Public Cloud kernels, and most recently HWE kernels too. Recently livepatch support was expanded for FIPS compliant kernels, Public cloud FIPS compliant kernels, and as well IBM Z (mainframe) kernels. Bringing the total of kernel flavours support to over 60 distinct kernel flavours supported in parallel. The table of supported kernels in the documentation lists the supported kernel flavours ABIs, the duration of individual build's support window, supported architectures, and the Ubuntu release. This work was only possible thanks to the collaboration with the Ubuntu C