That may well be… as I hear the HDD heads moving heavy while app starting.
What would be a better setting; and how to do that (I didn’t find that at Firefox settings)?
user42@MarvinVI:~> inxi -GSaz
System:
Kernel: 6.4.0-150600.23.50-default arch: x86_64 bits: 64 compiler: gcc
v: 7.5.0 parameters: BOOT_IMAGE=/boot/vmlinuz-6.4.0-150600.23.50-default
root=UUID=796864ae-87fd-4d28-b786-b5234bdb512d splash=silent
resume=/dev/disk/by-uuid/eafc2519-2ff0-496f-ba2c-c970a37a6817
preempt=full mitigations=auto quiet security=apparmor
Desktop: KDE Plasma v: 5.27.11 tk: Qt v: 5.15.12 wm: kwin_x11 vt: 2
dm: SDDM Distro: openSUSE Leap 15.6
Graphics:
Device-1: Intel HD Graphics 530 vendor: ASUSTeK driver: i915 v: kernel
arch: Gen-9 process: Intel 14n built: 2015-16 ports: active: HDMI-A-3
empty: DP-1, DP-2, HDMI-A-1, HDMI-A-2 bus-ID: 00:02.0 chip-ID: 8086:1912
class-ID: 0300
Display: x11 server: X.Org v: 1.21.1.11 with: Xwayland v: 24.1.1
compositor: kwin_x11 driver: X: loaded: modesetting unloaded: fbdev,vesa
alternate: intel dri: iris gpu: i915 display-ID: :0 screens: 1
Screen-1: 0 s-res: 1280x1024 s-dpi: 96 s-size: 338x270mm (13.31x10.63")
s-diag: 433mm (17.03")
Monitor-1: HDMI-A-3 mapped: HDMI-3 model: NEC EA193Mi serial: <filter>
built: 2018 res: 1280x1024 dpi: 87 gamma: 1.2 size: 375x300mm (14.76x11.81")
diag: 480mm (18.9") ratio: 5:4 modes: max: 1280x1024 min: 720x400
API: OpenGL v: 4.6 Mesa 23.3.4 renderer: Mesa Intel HD Graphics 530 (SKL
GT2) direct-render: Yes
The reasons I cited are still entirely valid. You said you understand that Linux and Windows aren’t the same - but you’re expecting everything to perform the same. That’s not really a reasonable approach.
The same app isn’t built the same way on different operating systems. The executable formats are different. The linked libraries are load differently and are formatted differently. Everything gets optimized differently; the compilers work differently.
The user profiles are different (probably) between the two systems.
That said, maybe there are some optimizations in your setup that can be done to make it faster (use a lighter DE, ensure your video driver is operating properly, etc).
@user42 Is intel-hybrid-driver, intel-vaapi-driver and intel-media-driver packages installed?
intel-hybrid-driver: no
intel-vaapi-driver: yes
intel-media-driver: yes
And now?
The installation of Leap went fine, w/o problems.
Also everything shows fine.
BTW:
I made a short trip to Win7 in the meantime.
Firefox (115.x), empty page, starts definitely quicker there: 1.5s, which is acceptable, hardly noticeable.
Back here in Leap, Firefox (128.11) takes 2.8s, which is a bothering waiting time (esp. if you know it’s unnecessary probably).
When loading content from a site there must be even more differences, due to the values (5s) I mentioned before.
As you are dualbooting with Win 7, which is EOL since 2020, and it seems you are using it with internet connection, your system can definitely be considered compromised. Bad actors are actively scanning for such unsecure systems. The takeover is only a question from some seconds.
This is also a piece of the overall picture which has to be considered when wondering about slow starting times.
With “system” do you mean? Win7?
(You won’t mean the whole PC, openSUSE included, will you?)
So I got compromised in a way that speeds up my internet access with Firefox. Hurray! 
Please, don’t play that game!
My Win7 might be compromised, although I did everything I can to prevent that
(closing all ports, firewalls, restricted access etc.).
And I’m pretty sure this has absolutely nothing to do with slow starting apps (Firefox etc.) at openSUSE.
So, please don’t be OT.
What do you mean by
Shall I take that as an insult?
You can’t.
If your system is infected, it doesn’t matter how many HDd’s or SSD’s you use. It is infected.
It is no game. It is known that if you connect a freshly installed Win7 with all the latest available security fixes to the internet, is is compromised within seconds/minutes. Bad actors didn’t stop with the development of their tools and attack scenarios when the support of Win 7 ended 5 years ago. The older an unsupported OS gets, the faster and easier it can be compromised. The amount of critical bugs found in old software increases over time.
No. But you should think about that if a system didn’t recieve security updates for 5 years, it is definitely compromised and shows strange symptoms. Even absolute computer cracks are barely able to secure Win 7 in a way that you can still use it today without security implications.
Well, I haven’t booted our Win10 laptop for 2-3 months, but did so now. So, here’s what I get - very similar to you:
-
Brave: about 2 seconds (don’t use Firefox) to load and render a webpage
-
LibreOffice Writer: about 1 sec, no doc loaded
-
Notepad++ : sub 1 sec. (MS Notepad is sub-standard for developers)
Okay, on the Leap side … 1, 2, 3 are basically matched for startup times as on Win10.
Okay, I’m confused now.
In your 1st post, you mention running on a SSD … that is VERY different than a HDD.
A solid state drive (SSD) is storage that uses flash memory - no moving parts
Very different than a HDD, that has spinning disks.
/home counts for data @user42
I have an idea, why Win7 might be quicker:
Surely not because it might be compromised (This won’t result in speed-up).
But perhaps because several system components haven’t been updated for long.
And these security fixes would have slowed down (just think about that meltdown fixes)
the system.
Second KDE Plasma will take more ressources than Gnome, not to talk about Win7.
My PC is abt. 8y/o (with “quick” components those days), and I would have expected that openSUSE does quick with it - but who knows?
Surely not as quick as I’m used to at my (did I mention already: beloved) Win7.
That animation thing of Plasma probably won’t slow down the starting,
but probably the hopping makes the waiting time more noticeable.
Hop-hop-hop…
Probably (?) there’s nothing wrong with my Leap (driver etc.?), and I should cope (:(), or try to find some kind of speed-up? But the other DEs don’t fit me…
Under linux, application settings, configurations, caches and much more are stored in the /home directory of a user. Each time you open an application, all the mentioned data has to be read from the slow HDD.
MS Windows stores the above data on the system partition (SSD).
This is the explanation of the speed differences. If you would have the home partition also on an SSD there would be nearly no difference.
It is recommended to have root AND /home partition on a SSD to benefit from the speed. Having /home on a HDD will slow down your system performance. Only “real” data may be stored on a HDD (movies, music, pdfs, …stuff like that).
1 Like
Maybe.
But all I read everywhere was to put /home at a different partition. For several reasons. So I don’t think that this is a good idea.
That is correct…on a different partition. But NOT on a HDD!
2 Likes
Confirmation of the forum?
/home can be on an SSD or HDD, but HDD will be slower.
And yes, you can have multiple partitions on either device type. (Not sure exactly what you mean by “Confirmation of the forum?” - hui is part of the forum community, and has solid knowledge…)
1 Like
I meant what others of the forum think about hui’s statement.
When I presented my plan in detail of the partitions etc. in the forum before installing
nobody warned me it would be a bad idea to place /home at the HDD…
It’s not explicitly a bad idea. Lots of people put /home on a HDD. Especially those who don’t have an SSD. 
But if you want fast performance, then yes, that is going to make a big difference. SSDs don’t have “seek time” the way HDDs do. They don’t get fragmented (which is less of an issue now than it used to be, but sequential reads are more performant than random reads, generally - but in multithreaded operating systems, actual sequential reads aren’t always guaranteed because multiple processes might be performing I/O on the disk concurrently, so it comes down to how they’re accessing the data).
2 Likes
Yes, thank you, I know all this.
What I didn’t know - is that my presented scheme (see link) would be sub-optimal… 
BTW
It might be the reason for some other effects I addressed in the forum already…