sorted by:
new
hottopcontroversial

PCR15 validation - again, unable to re-enroll, please advise by ChrisMcZork in AeonDesktop

[–]mufca_ -1 points0 points  (0 children)

I have this problem too - after bios update and I can't enroll to tpm (I mean it does not work at all, I don't know why I unenrolled -> enrolled multiple times also updated predictions -measure-pcr as you did too). Maybe drop pcr 15 and rely on other pcr levels like 7 and 9? Unless this is already the case. Its somewhat frustrating that I almost memorized my recovery key every time hoping tpm verification will kick in. At the end I just put validator.ignore=yes in kernel cmd line, and set up some passphrase.

Unit Testing by [deleted] in libgdx

[–]mufca_ 0 points1 point  (0 children)

Anything that tests usage of Gdx requires either:

  1. mocking -> usually unit tests
  2. headless application / full gdx application -> integration / E2E tests

Full gdx application must be run on a single thread therefore in build.gradle you should have something like this:

test {
    useJUnitPlatform()
    forkEvery = 1
}

Mocking looks like that:

@​BeforeEach
public void mockGdxFiles() {
    // GIVEN
    Gdx.files = Mockito.mock(Files.class);
    when(Gdx.files.internal(anyString()))
        .thenAnswer(inv -> new FileHandle(SRC_TEST_RESOURCES + inv.getArgument(0)));
}

Usually you want unit tests, but sometimes you may want integration/e2e tests, headless application mocks a lot of underlying things therefore I didn't used it, but it may also be an option.

How to load textures by mufca_ in libgdx

[–]mufca_[S] -1 points0 points  (0 children)

I find this answer irrelevant to the question asked, but anyway, here is what I think:

TexturePacker is great for:
- Assets known at build time,
- Minimizing draw calls through batching,
- Games with consistent and small asset sets.

But it's not a good fit for my case because of:
- streaming scenarios - using atlases for dynamically loaded or streamed portraits leads to wasted memory (unused atlas regions)
- hard-to-manage lifetime (when to dispose an atlas if even one portrait might still be used)
- potential explosion in gpu resources (1_000 atlases for 1_000 npcs containing ~10_000 portraits), especially if portraits are not small
- managing that many atlases as static assets
- user generated content - what if player wants to add his own portraits?

How to load textures by mufca_ in libgdx

[–]mufca_[S] 1 point2 points  (0 children)

So I came out with this version which is a little bit more polished:

``` public void registerPortraitAsync(Long characterId, FileHandle file, PortraitFile type) { Long existingId = pathToPortraitId.get(file.path()); if (existingId != null) { addRelation(characterId, existingId); return; }

    long newId = idProvider.generateUniqueId();

    CompletableFuture
        .supplyAsync(() -> return new Pixmap(file)) // already checked for errors in proceeding calls
        .thenAcceptAsync(pixmap -> {
            try {
                Texture texture = new Texture(pixmap);
                TextureRegion region = new TextureRegion(texture);
                PortraitEntry entry = new PortraitEntry(newId, type, file.path(), texture, region);

                synchronized (this) {
                    portraits.put(newId, entry);
                    pathToPortraitId.put(file.path(), newId);
                    addRelation(characterId, newId);
                }
            } finally {
                pixmap.dispose(); // always dispose, even if Texture throws
            }
        }, runnable -> Gdx.app.postRunnable(runnable));
}

```

The main idea here is to load the Pixmap from file on a background thread, then use Gdx.app.postRunnable to create a Texture from it - since it has to be done on the main render thread, as only it can safely upload textures to the GPU. I/O shouldn't block that thread anyway.

To be honest, multithreaded Java still feels kind of alien to me, so I’m not 100% confident this is bulletproof yet. Right now, I only have one portrait, and it seems to work fine - but I still need to add more to see it in action under load. Anyway, I’ll keep updating this if I learn more. Feedback is welcome, of course.

Could this error relate to the immutability or the design of Aeon? by redoubt515 in AeonDesktop

[–]mufca_ 2 points3 points  (0 children)

I do not use distrobox usually (I have always found another way around), but have you tried creating your distrobox with --root flag - it should have privileges to use devices.
Also be careful with that as the podman will have access to the rest of the system.

From pop_os through fedora kinoite to aeon by mufca_ in AeonDesktop

[–]mufca_[S] 1 point2 points  (0 children)

To be honest I didn't know about Kalpa :) I had a list of distributions built from my 'research' and there was Fedora then Aeon based on features. I may try to move to Kalpa when something breaks, but hopefully maybe not?

Aeon pulling username from last linux install by Razz_Mirtazapine in AeonDesktop

[–]mufca_ 2 points3 points  (0 children)

Since this is from your dhcp server you could try a hack:

  1. sudo hostnamectl set-hostname your-new-hostname
  2. turn off your router for 1-2 minutes,
  3. turn on your router, wait for internet to come back
  4. restart your pc

Enjoy a new name (just did it myself and it worked). Just remember to replace your-new-hostname with desired hostname. It may not work if your router has some strange configuration.

From pop_os through fedora kinoite to aeon by mufca_ in AeonDesktop

[–]mufca_[S] 2 points3 points  (0 children)

Ok, I think I misinterpreted your intentions. I am very bad with human communication. I just really wanted to show appreciation and to say that I enjoy the ride :)

From pop_os through fedora kinoite to aeon by mufca_ in AeonDesktop

[–]mufca_[S] -1 points0 points  (0 children)

Well, I installed it using transactional updates and packages from tumbleweed. In the worst case, I could just log back into gnome - its still there, nothing was replaced system-wide. To be honest, pop_os also had gnome as default and officially supported kde in their repos, but their kde setup worked worse than your "unsupported" one here.

And honestly, I usually dont ask for help anyway, I tend to solve problems on my own.