General > General Technical Chat

When will MS replace the NT-kernel in windows?

<< < (24/25) > >>

Nominal Animal:

--- Quote from: PlainName on February 03, 2024, 09:02:26 pm ---
--- Quote ---the various GCC/Clang ports
--- End quote ---
What's up with a port? They do the same thing, using the same code, producing the same result.

--- End quote ---
Case-insensitive file system support, some character set issues wrt. files with non-ASCII characters and so on, wide string constant character set support (UTF-16 is not a valid wide character set), and so on.  AIUI the Linux kernel does not currently have files or directories in the same directory only differing by name case, nor any using non-ASCII characters in their name, nor uses wide character strings in the sources, but those won't be true in general.
By definition, the behaviour of the toolchain differs.

Note, however, that there is absolutely nothing wrong in using a port, or using Windows.  It does mean one has to consider the target OS/arch peculiarities before blaming the project or sources, but that's it.  I just perceived your analog as weirdly upside-down compared to my own views and experiences, where Windows is the more Arduino IDE -like system, and Linux/BSDs/POSIXy systems the true tool for basing software development on.  Not a value judgement, only my current view, mind you.

PlainName:

--- Quote --- I just perceived your analog as weirdly upside-down compared to my own views and experiences, where Windows is the more Arduino IDE -like system
--- End quote ---

The reverse. We did consider running Linux workstations (and, later, a new chap was Linux and useless, but I guess he would have been whatever OS), but our tools which we knew like the back of our hands were Windows and many things we used didn't exist on Linux.

But the primary driver, or rather the decider, was that we didn't want to end up as happened with a previous product where some tool got changed and product support basically had to stop. So building everything on Windows ensured that there was nothing that was dependent on the host OS - with Linux it's a bit like (on Windows) loading a registry branch and trusting that neither will the real registry be affected, nor the new branch being affected by the existing registry. So anything we used - from uboot through the rootfs, apps, kernel drivers and all the tools necessary to create those - was built entirely from source with zero outside dependencies. But we were embedded system developers and the norm was that the target was not the development host.

[Speaking of which, IMO if web developers want to try their stuff out on their development PC they should be forced to use a Pentium.]

tridac:
Here's some technical arguments, with software engineer hat on. Robust software systems are designed by partitioning, abstraction and encapsulation of functional layers, with well defined interfaces between them. A set of bricks to build a cohesive whole. At the root of the tree, a single kernel is responsible for managing system resources, such as memory, storage and io devices. Any of the bricks and layers could be replaced with something completely different, so long as the interfaces and functionality between them remained the same. The unix and variant operating systems were designed using such classic software engineering principles. Compact. lightweight and robust, nothing that is not needed, with a complete and  visible audit trail right across the system. The downside being that the various parts of the system and their startup, each have their own config files, making it more difficult to setup and manage, without operating system theory awareness.

The issue is of course, that the admin tools and setup files, like the C language unix is written in, are pretty low level and require a level of skill and basic os knowlege to manage them. Some os's, like Solaris and FreeBSD, overlay a service admin layer over the basic system, to make it easier to manage. On Solaris,, that's svcadm and svcs, FreeBSD, the service utility, AIX, smitt and others. The key thing being that those tools are just an added layer on top of what is already there, so it's still possible to manually edit configurations, look at plain text log files etc. Systemd, a kernal managing the kernel, on the orher hand, seems to have it's entrails into every part of the system, from startup, right through to the X desktop. A nightmare to debug. Hence, abusing not only system enginering, but also basic os design principles.

As a cynic, I saw systemd as a power grab to gain more influence into the direction  of travel for Linux, but most distros have succumbed to it. I guess those that pay the piper, (funding) call the tune. In summary:  Over complex, overblown, and uneccessary...



CatalinaWOW:

--- Quote from: tridac on February 04, 2024, 12:02:29 am ---Here's some technical arguments, with software engineer hat on. Robust software systems are designed by partitioning, abstraction and encapsulation of functional layers, with well defined interfaces between them. A set of bricks to build a cohesive whole. At the root of the tree, a single kernel is responsible for managing system resources, such as memory, storage and io devices. Any of the bricks and layers could be replaced with something completely different, so long as the interfaces and functionality between them remained the same. The unix and variant operating systems were designed using such classic software engineering principles. Compact. lightweight and robust, nothing that is not needed, with a complete and  visible audit trail right across the system. The downside being that the various parts of the system and their startup, each have their own config files, making it more difficult to setup and manage, without operating system theory awareness.

The issue is of course, that the admin tools and setup files, like the C language unix is written in, are pretty low level and require a level of skill and basic os knowlege to manage them. Some os's, like Solaris and FreeBSD, overlay a service admin layer over the basic system, to make it easier to manage. On Solaris,, that's svcadm and svcs, FreeBSD, the service utility, AIX, smitt and others. The key thing being that those tools are just an added layer on top of what is already there, so it's still possible to manually edit configurations, look at plain text log files etc. Systemd, a kernal managing the kernel, on the orher hand, seems to have it's entrails into every part of the system, from startup, right through to the X desktop. A nightmare to debug. Hence, abusing not only system enginering, but also basic os design principles.

As a cynic, I saw systemd as a power grab to gain more influence into the direction  of travel for Linux, but most distros have succumbed to it. I guess those that pay the piper, (funding) call the tune. In summary:  Over complex, overblown, and uneccessary...

--- End quote ---

Abstraction.  Encapsulation.  Well defined interfaces.    Yep, that makes for reliable modules.  Each little piece has no confusion about what to do and how to do it.

But ah that downside.  All those config files, that require a system expert to understand and manage.  So the overall system has the same defects as the spaghetti code that all of these design principals were intended to eliminate.  That old spaghetti code was a rice bowl for those who developed the code and therefore the concept was strongly defended by those whose rice bowls were threatened.  Same thing seems to be happening here, just the rice bowl has changed.

Some day a genius is going to formalize a theory of complexity which says that complexity is conserved.  Eliminating it in one place adds it somewhere else.

PlainName:

--- Quote ---But ah that downside.  All those config files, that require a system expert to understand and manage.
--- End quote ---

Why? You could have an app that deals with all that stuff - major Linux apps tend to basically be front ends to many sub-apps, after all. The normal user wouldn't need to dick with the config files but just use the config app to manage the config. Hell, it could even be (gasp) a GUI!  But those files still exist if a guru wants to roll their sleeves up and surgically excise something.

Someone around here pointed to an open source PDF printer ( https://www.bullzip.com ) and if you look closely it's requires a handful of sub-apps installed in order to work. Why is that any different to managing configs, except in scale (and looking nice)?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod