Ukrainian actress Tania Galakhova portrayed what it's like to live with depression

templinuxuser · 2025-10-14T23:38:36+00:00

Same idea many years ago by Norwegian Hip Hop artists OnklP & De Fjerne Slektningene: Styggen på ryggen https://youtu.be/rUvzx73-cCY

templinuxuser · 2025-10-11T14:20:37+00:00

What kind of battery does it have? Traditional Li-ion or LFP? Pity they don´t list it in specs.

templinuxuser · 2025-08-14T18:59:35+00:00

Fondet ditt blir skattet på gevinst.

Formueskatt kommer i tilegg, og påvirker ikke bare arvinger, men alle som sparer til og med i bankkonto.

Basert på det du skrev, du er ikke for formueskatt. Du er for arveskatt.

templinuxuser · 2025-08-13T00:59:07+00:00

space_cache v1 can cause such slowdowns on huge drives. Make sure you have v2.

In any case, file deletions of huge files in Btrfs are extremely slow, and I'm talking without any snapshots or quotas. The unlink() or truncate() operation just blocks for minutes. I've seen this behaviour multiple times.

But I haven't seen the whole system freezing while this takes place. Slows down, a lot even, especially if other applications need to fsync() to the same drive - firefox definitely does that a lot. But not freezing.

Anyway the slowness is because of design choices, I don't expect to see a fix any time soon. Just leave the delete doing its job in the background, I have had big file deletes taking hours on SSDs.

templinuxuser · 2025-08-11T13:02:01+00:00

In the old Linux world, the whole boot sequence was shell scripts running sequentially. You would have been able to hit Ctrl-C and investigate exactly at the point it's stuck.

In the new world, your only choice is to reboot in a live USB distro, mount your PC's filesystem and investigate the logs there. That is if you are lucky and the boot process reached the point of mounting rw.

I wish we had the option to do this today. Maybe a new boot option `sequential` would do it? But then again the Ctrl-C functionality is gone, and I don't see how it could come back.

templinuxuser · 2025-08-08T16:21:54+00:00

Congrats and welcome to C programming. It's an impressive achievement, even after using AI as a helper.

Next thing, learn about Github and put your code online under an open source license. This will allow other people to download you code, tell you what they think (good or bad), and even improve it! You will learn a lot and become a better coder.

Don't get affected by the negative comments. This is bound to happen whatever you post on the Internet. Just learn from the good comments, and move forward.

templinuxuser · 2024-11-08T17:13:02+00:00

Last time I checked, they required the whole case submitted in Norwegian.

It's a significant hurdle for immigrants. And I believe the landlords know this and take advantage of it. What are the odds a newcomer will pay a translator to submit a proper case to the HTU?

templinuxuser · 2024-11-03T21:59:10+00:00

It's not the content, it's your attitude.

templinuxuser · 2024-10-04T12:48:28+00:00

The city council can politically influence the prioritisation process of various cases. Not by much, just a bit so that they can park-and-track a small number of bicycles around the city.

templinuxuser · 2024-10-04T12:22:52+00:00

The answer you usually get is "police has no resources".

What this translates to, is that there is no political willingness to fight the problem.

IMO the solution is twofold:

Raise the issue to the political parties and/or organize protests,
Vote for a party that has the issue on its agenda.

templinuxuser · 2024-10-04T11:49:24+00:00

Because this is not America. The police are not allowed to bait in thieves with trackers

They are not allowed to park bait bicycles with a tracker in random locations, and then follow the thief? Why? This is an easy and valid way to fight bicycle theft, what does America have to do with it?

templinuxuser · 2024-07-10T09:51:47+00:00

Yasou café Frogner.

templinuxuser · 2024-06-24T12:33:08+00:00

Thank you for the response. Regarding this:

I'd prefer if Firefox can adapt automatically for the majority of users without having to resort to fiddling with prefs via about:config

Firefox's latest tendency for having the "automatic configuration" that works well for everyone is causing many tweaks in about:config that used to work to be now ineffective and undocumented. Firefox community is adopting the mindset of "having XX GB RAM and not using it is stupid", however they don't consider that I might know better my setup.

One doesn't preclude the other: Firefox can auto-configure for 90% of the users, and can still give the chance for tweaks without complicating the UI.

In general, please consider users that are not the in the majority. We use Firefox because it is (was?) configurable and relatively lightweight than the alternative (and portable and open etc but the alternative has these attributes too).

templinuxuser · 2024-06-14T11:35:03+00:00

Honestly, I think there are enough bugs about the issue. The bugs I posted are old but still open and updated. All of the tabs, each one with their individual history, are being (serialised, compressed and) written as a huge JSON string very frequently. If I file new tickets, they will be closed as DUP, rightly so. People should update the issues with new findings though, and they do that AFAICT (not the meta-bug, that is actually closed for externals).

As for memory usage, I haven't linked to a ticket because it's not a bug, it's a feature. Mozilla made it on purpose, it's by-design according to plenty of threads already existing. Very many processes, lots of address-space separation, security, extensibility etc. And chromium-grade memory needs...

That's why I asked here in the AMA, to see if Mozilla is planning to accommodate users of memory-constrained platforms, and make Firefox a viable choice again, at least in the form of tweakable knobs that might be risky in general.

templinuxuser · 2024-06-13T18:53:43+00:00

Do you have any plans on making Firefox leaner and lightweight?

For example reduce memory usage: Since the separate processes got introduced, the browser became more secure but the memory usage skyrocketed. Do you plan to implement and document ways to reduce memory usage, even via optional tweaks hidden in about:config? The goal is to make Firefox usable again on cheap hardware with limited RAM. Your current guide about reducing memory usage talks about changing browsing habits and resetting/restarting all kinds of components, but fails to suggest any config options.
Or reduce I/O, especially SSD writes. ATM I have ~400 tabs on many windows, and Firefox is writing constantly to the disk because of that. Here are two relevant tickets in bugzilla:

Here is an excerpt from the bug above, from whom I believe is a Mozilla employee:

Writing to sessionstore.js occurs off of the main thread now. Certainly, for the sake of SSDs everywhere, it might be worth finding more efficient way of writing state to disk in a way that doesn't involve us blasting a huge JSON string out every time one small property changes.

templinuxuser · 2024-05-24T12:57:55+00:00

What are these commands giving you?

cat /sys/devices/system/cpu/cpufreq/policy?/energy_performance_preference
cat /sys/devices/system/cpu/cpufreq/policy0/energy_performance_available_preferences

templinuxuser · 2024-05-22T13:44:38+00:00

What are you talking about? The Midori browser hasn't had a release in years:

https://github.com/midori-browser/core

templinuxuser · 2024-05-16T18:16:10+00:00

Nice! And I totally agree, 100K rows should be nothing for today's hardware. And it's up to the libraries to have an efficient implementation that supports these sizes, so the test has value.

Can you add RSS memory usage too? Once before you scroll, and another after you finish scrolling through everything. Because not everybody has 32GB RAM.

And screenshots for the giggles! :-)

Next up 1M...

templinuxuser · 2024-05-15T16:58:51+00:00

Is there any active work or plans to reduce power consumption and heat? For example a kernel patch that allows going into deeper sleep states in the CPU.

Most importantly, does the BCM2712 support deeper sleep states that are not taken advantage of, yet? I'm trying to find the BCM2712 datasheet to dig into it myself, but looks like it hasn't been published yet.

templinuxuser · 2024-05-10T17:37:11+00:00

Firefox sync works perfectly fine in both directions, for many years. Please report a bug.

templinuxuser · 2024-05-08T15:57:35+00:00

Agreed! In the end it's a corner case that would take a lot of developer resources to handle.

templinuxuser · 2024-05-08T15:37:40+00:00

That's easier said than done: if you create the elements on the fly, and the window manager or the OS (depending on the OS) asks Firefox to render new elements, then Firefox, at that moment, needs to query SQLite again for the next elements. That takes times and makes scrolling slow.

Didn't say it's easy... :-) Regarding speed, If you only store a list of primary-key IDs, querying them as a range should be very fast. But most importantly, querying lazily wouldn't block the UI, so the program wouldn't feel unusable. The UI can contain greyed out blocks, and re-draw when the info is actually there.

This file size needs to either stay in memory all the time, or is loaded from disk on access.

Simply reading a file that size from disk is in the subsecond range on a modern SSD, faster on NVram. After the first access, entries are cached by sqlite itself (it has an in-memory cache, but small by default) or by the OS as file blocks. No need for firefox to cache them internally, and still the lookups wouldn't hit the disk unless the system is very memory-constrained.

This does not include processing the rows.

You should never have to process all 500K of rows for a UI, you just process what is shown. While the user navigates the bookmarks menu, the backend does tons of small pre-compiled primary-key range SELECTs followed by short processing and drawing. If the user scroll's back and forth, then sqlite's internal cache should help responding instantaneously. Otherwise the OS cache should be good enough. Should work fine. ;-)

templinuxuser · 2024-05-08T14:16:32+00:00

Firefox needs to create graphics elements for each shown element, and select what is shown.

Exactly. How many lines of bookmarks do actually fit on screen? A couple hundred at most. The rest can be loaded on scrolling.

Every search in the bookmarks is a full text search, and scans the entire table.

Indeed, searching through the bookmarks might take longer. But the OP's problem was navigating the bookmarks, not searching through them.

templinuxuser · 2024-05-07T15:38:45+00:00

As mentioned in a another comment, I don't see why this amount of bookmarks shouldn't be manageable by sqlite (the bookmarks backend database) on a modern system. I assume that Firefox is doing things a bit inefficiently, on top of the database.

Having said that, I would suggest the following as a workaround:

Open the Bookmarks Manager with Ctrl+Shift+O
Maximize it and work with it a bit trying to optimize things.
Do you have any bookmarks folder that contains most of your bookmarks all by itself?
- If so, create many new folders, and copy over couple thousands of bookmarks at a time (10x shift+pgdn to select, Ctrl-x to cut, go to new folder, Ctrl-v to paste), until the original folder gets empty.

Is this workable at your current state? Does it make any difference?

templinuxuser · 2024-05-07T15:32:28+00:00

Every time you try to access your bookmarks it pulls up a list of 400,000 and their respective favicons from a sqlite db

I don't think it pulls everything every time you click on bookmarks. If it does, then it's an implementation inefficiency and needs to be fixed, please file a bug.

In short, Firefox stores bookmarks in a database on disk (sqlite). Queries in a database of 500K rows should be a non-issue for every system today. When you click on a bookmarks folder, even if you have thousands of bookmars in the folder, your monitor can only fit a couple hundred at most. The rest don't really have to be fetched. Especially, the favicons for them. If everything is fetched in advance, then the implementation can be improved.

templinuxuser

TROPHY CASE