Products > Computers

Windows 11: Why does Microsoft think they should change the START menu?

<< < (10/12) > >>

gmb42:
Windows has somewhat oscillated from shared to local copies then back to shared, mainly because of the issues of how to update the defective local copies of libs.

Windows doesn't have the concept of a separate location of non-OS but common libraries that Linux has such as /usr/local/lib, instead such things seem to get dumped into %WINDIR%\System32 along with the OS libs.

I was thinking more about ubiquitous but non-system libraries such as log4j.  I'm not a fan of anything in the Java ecosystem but they seem to want each app to have it's own copies of such things, even extending to their own copy of the jvm in extreme cases.

SiliconWizard:
The shared libraries model is inherently hard to deal with. At the OS level, the development is centralized, so compatibility can be enforced and ensured (so any library update shoud not break neither existing software, nor future software if written for an earlier version of the OS, something that, TBH, Windows has been rather good at.)

Now for any third-party library, the version and compatibility problem becomes almost intractable, so you need to fall back to "local" libraries to ensure compatibility.

This could be avoided for the most part if all library maintainers enforced the same policy of never breaking backward compatibility. Of course, that requires a lot of discipline, and will usually lead to inflated libraries over time. This is definitely not an easy problem. Unfortunately, it looks like the opposite stance is often taken, and that nobody cares much about compatibility between versions. So in the end, it's a huge mess.

But yeah, even though wasting resources is always bad per se, these days, sharing libraries just for the sake of saving storage space (and in some cases, RAM space, when libraries can be shared in memory, which is sometimes, but rarely the case) doesn't make a lot of sense. The real rationale should be compatibility: ensuring every application uses the same libraries at any given time, but as we can see, reality is almost the opposite of that, so shared libraries most often are useless pain. Except again for very "core" libraries, for the reason exposed above, and for which it's actually possible to control and enforce compatibility over time.


Zero999:

--- Quote from: SilverSolder on January 13, 2022, 01:33:00 pm ---
--- Quote from: gmb42 on January 13, 2022, 10:09:10 am ---
--- Quote from: SilverSolder on January 12, 2022, 09:48:54 pm ---
--- Quote from: Bicurico on January 12, 2022, 09:41:55 pm ---[...]
 If other applications use the same libraries, those will be repeatedly copied over.
[...]

--- End quote ---

The idea of sharing libraries (other than basic OS libraries) comes from the bad old days when disk space was scarce and expensive.  It can cause a lot of problems...   and definitely causes a management issue.  Not worth the hassle now that disk space is cheap and plentiful.

So much simpler to keep multiple versions of the libraries in each app folder (so it is even clear which version they need/use).

Makes it easier to copy software from one computer to another too.  (I know, it's not what "they" want....  but who knows, maybe once they have everyone subscribing to cloud services "they" will release their greedy claws at the local OS level...    we live in hope! )

--- End quote ---

The downside of each app having their own copy of libraries is management of issues in those libraries, instead of patching\updating a single shared "system" copy, now each app needs to be updated.

In addition, in a multi-tasking OS having app specific versions means each (running) one has it's own image loaded consuming more RAM.

There's no simple answer to this issue, but to me ease of uninstall by simply deleting a directory comes somewhat nearer the bottom of the list.

--- End quote ---

Libraries that belong to the OS should be shared (and updated in one place).   Libraries that do not belong to the OS, should not be shared!

If an OS library update breaks an application,
(1) Somebody has goofed!  This should not happen, in principle...
(2) the workaround is to place the old library in the application directory for its private consumption

I guess this is pretty much how Windows has always worked...   not sure about other OS.


--- End quote ---
Who decides what's OS library and program library? One could say GTK 3 isn't an OS library, since it's possible to run Linux without it, but a good proportion of programs which most people need depend on it.

There are plenty of libraries on GNU/Linux, which were originally created for one program, yet now are used by many and are an essential part of most distributions.

SilverSolder:

--- Quote from: Zero999 on January 14, 2022, 10:48:40 am ---[...]
Who decides what's OS library and program library?
[...]

--- End quote ---

I would say if it's part of the distribution, it is an OS library...    so if e.g. Microsoft includes it and supports it, we are talking about an OS library.

No?

JohanH:
I couldn't care less. Feels like I haven't used a start menu in years. Both in Linux and Windows I press the "Win" button and type the few first letters of the name of the application. It is found in a millisecond and started. Most used applications are pinned in the task bar (launcher/whatever), if I forgot their name. The desktop isn't visible ever, except for after startup. If your computer work consists of clicking the start menu all day long, you are doing something wrong. A good OS/desktop/window manager is almost invisible and stays out of the way while you work with the applications (unless you are the system administrator).

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version