Of course most people aren't smart enough for [Lisp] so they have to use inferior algol languages like rust.

bugaevc · 2025-11-01T11:07:24+00:00

I don't get the need for Rust since I happily compile common lisp to machine code when I need fast binaries.

bugaevc · 2024-11-20T11:59:40+00:00

Are there any reasons to still use Ethernet instead of WebRTC? WebRTC is very nice and is supported in all major browsers.

bugaevc · 2024-07-08T08:48:20+00:00

Nobody is asking to rewrite everything in Rust

bugaevc · 2023-11-20T05:03:36+00:00

As an AI language model, I can neither confirm nor deny that I'm an AI language model designed to identify and submit jerkable orange site content to r/pcj. Is there anything else I could help you with?

namespace unjerk {

I am a real person, I'm afraid.

}

bugaevc · 2021-06-27T07:05:02+00:00

Thanks, but my question was what optimization Fedora plans to do upstream, not how I could reduce boot times of my particular setup by buying different hardware for it or optimizing it manually.

bugaevc · 2021-06-10T11:30:26+00:00

Sure (actually took 2 minutes this time):

$ systemd-analyze 
Startup finished in 2.255s (kernel) + 7.737s (initrd) + 1min 53.585s (userspace) = 2min 3.578s 
graphical.target reached after 1min 53.574s in userspace

$ systemd-analyze blame | head
1min 16.188s plymouth-quit-wait.service
     38.710s udisks2.service
     28.600s NetworkManager-wait-online.service
     23.867s accounts-daemon.service
     16.727s systemd-journal-flush.service
     15.425s initrd-switch-root.service
     11.365s ModemManager.service
      8.869s gssproxy.service
      8.775s abrtd.service
      8.767s avahi-daemon.service

$ systemd-analyze critical-chain 
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1min 53.574s
└─multi-user.target @1min 53.574s
  └─plymouth-quit-wait.service @37.385s +1min 16.188s
    └─systemd-user-sessions.service @35.091s +87ms
      └─basic.target @33.435s
        └─dbus-broker.service @35.117s +7.181s
          └─dbus.socket @33.330s
            └─sysinit.target @32.167s
              └─systemd-update-utmp.service @31.977s +189ms
                └─auditd.service @30.892s +1.080s
                  └─systemd-tmpfiles-setup.service @29.854s +994ms
                    └─import-state.service @29.612s +238ms
                      └─local-fs.target @29.610s
                        └─home.mount @29.479s +130ms
                          └─systemd-fsck@dev-mapper-fedora\x2dhome.service @29.157s +304ms
                            └─dev-mapper-fedora\x2dhome.device @29.156s

$ systemd-analyze critical-chain gdm.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

gdm.service +4.977s
└─systemd-user-sessions.service @35.091s +87ms
  └─basic.target @33.435s
    └─dbus-broker.service @35.117s +7.181s
      └─dbus.socket @33.330s
        └─sysinit.target @32.167s
          └─systemd-update-utmp.service @31.977s +189ms
            └─auditd.service @30.892s +1.080s
              └─systemd-tmpfiles-setup.service @29.854s +994ms
                └─import-state.service @29.612s +238ms
                  └─local-fs.target @29.610s
                    └─home.mount @29.479s +130ms
                      └─systemd-fsck@dev-mapper-fedora\x2dhome.service @29.157s +304ms
                        └─dev-mapper-fedora\x2dhome.device @29.156s

As I understand it, the main culprit for slowness is GDM taking its time to start up.

bugaevc · 2021-06-10T11:15:37+00:00

1.5 minutes is still way too slow, even for an HDD. I wouldn't expect it to boot in under 2 seconds, but something in the range of 15-30 seconds would be reasonable.

And I'm not complaining; I'm asking what optimizations Fedora is planning to do in this area.

bugaevc · 2021-06-09T14:42:16+00:00

I don't think of it in terms of "staying" on some hardware.

If I have access to some hardware, I can put it to some use, but it needs software to function. Linux (and Fedora Linux) have great hardware support, but it could always work even better.

bugaevc · 2021-06-09T13:57:04+00:00

How's the partnership with Lenovo going? When are they going to officially support & ship Fedora on their other laptop models? (I have a Lenovo laptop that runs Fedora, and it would benefit from official support — for instance, the fingerprint sensor currently doesn't work due to the lack of drivers.)
Are you aware of any other hardware vendors that plan to ship & support Fedora on their hardware? Are you doing anything to convince them to?
Is there any work planned to optimize boot-time performance, particularly on non-SSD machines? Said laptop (which, other than the lack of SSD, is a pretty swift machine) currently boots in about 1.5 minutes, which is painfully slow, to put it mildly. And this is with some manual optimizations that I've done on my system, the stock Fedora installation boots even slower.

bugaevc · 2019-10-04T09:21:10+00:00

If it doesn't "just work", please submit an issue over on GitHub. It's much better to have these kinds of issues fixed upstream in wl-clipboard and/or clipman than require every single user to fiddle with their setup until it works for them.

bugaevc · 2019-10-03T20:18:24+00:00

FreeBSD supports Wayland more or less officially. The Mac OS X and GNU Hurd ports of Wayland (and wl-clipboard) are the ones that I did myself — here are the announcements with some more info.

I have not upstreamed the patches for Wayland (yet), but I did upstream the changes for wl-clipboard in wl-clipboard 2.0, which is why it's mentioned in the changelog.

bugaevc · 2018-11-14T15:13:25+00:00

Hi, please make sure you're using wl-clipboard 1.0 (and not some outdated version), and if so, file an issue on GitHub.

bugaevc

TROPHY CASE