“But I could also write a book on Nix XXXX-ups.”

You just said, no OS is perfect. Gee troll, what an insight! No OS is perfect but the poor Windows system administrators put in way more hours towards security than the Linux administrator does. In fact, Windows administration takes more man hours that Linux does. A lot more. And Linux administrators are higher paid than their Windows counterparts. They are also in higher demand right now. So what does that tell you troll? It tells you that Windows is a mess. A hopeless mess.

Arm is a vastly different beast. Particularly dealing with big little arch set ups.

NT core blue print is not x86 that is correct. But the problem is most of the internal design and research in current windows is x86 based. Even the NT design does not allow on what you have to for arm.

Big little in arm gets screwy. Because the big and little cpu setups can take more than 1 cpu instruction set at the same time. As well as being different speeds of cpu. NT contains nothing to handle dealing with having use 2 different cpu instruction sets at the same time. The worst big little arm in existence you have to deal with 4 different cpu instruction sets at this stage.

The means to handle 2 or more different cpu instruction sets at the same time in kernel space is currently unique to Linux. Arm is very alien to fully exploit to anything Windows NT design has handled before. That the problem. Even the Linux kernel design has had to go threw the preventable blender. Cost many years to get big little tech to work.

Did Windows CE ever exploit big little no it did not.

ze_jerkface
–Registry bloat has never actually been proven to exist nor has it been proven that keeping configuration settings in a few dozen text files is more efficient than a registry. Go ahead and write 10k entries to the registry to see if it impacts system performance, post the results actually.–

Correct term for NT issue is not Registry bloat. Registry Hive Fragmentation is the Microsoft title for the problem.

Writing 10K entries unless done a particular way would not cause a problem at all. Registry bloat is not the problem. Its failure to clean up after delete. So write 10K entries delete all bar 1. The notice the remaining one takes as long to look up as when there were 10K. That is longer than a fresh registry with 1 entry. Very simple test. ze_jerkface

A perfectly working b-tree the performance should be zero difference.

Next now that slowed containing 1 entry. Write the 99999 entries you deleted back. Now notice its slower again. Keep on repeating deleting and inserting the pattern and watch the hive progressively degrade.

ze_jerkface this is not bloat. This is indexing degradation. Windows NT 3.5 included a tool to clean this up. Windows 2000 you had to download it as third party. XP on the fix up is left to third party tools.

The Linux individual files out perform the registry because it happens in most cases to be sitting on a b-tree file-system that works correctly.

Also robert is right the policy of strict separation and not overwriting settings.

Areas that need overwrite inside a distribution you find –service–.d directories that basically are place files in here you want added to that services configuration under you applications name.

ze_jerkface would it be possible for Microsoft to implement some form of rule that applications cannot overwrite other registry entries owning to other applications yes they could.

Posix Linux has to thank for the .d directory idea that is a god send to make clean removal of applications possible. Why because the default settings of a application have not been messed with. Returning to default delete the addon files.

Per application hives entries would be a good way forward. Application only truly able to delete entries it created would solve a lot of problems in Windows as well.

ze_jerkface
–Are you really going to tell me that NT/Win32/.NET could not be ported to a quad core 1.5ghz ARM CPU?–
I can serous-ally say yes. It will not run on a quad core big little panda board. 2 cores 1.5ghz one type of arm. 2 cores 150Mhz.

The 150Mhz processors are highly power effective. Yes its still an arm quad core.

There are also worse like 2 ghz 1 arm core 3 150Mhz core arm cores.

Arm does not require all cores in a cpu to be at the same speed or even able to clock up. Yes the 150Mhz cores that is there max speed. Task management is required to be vastly different on a Arm or you perform like a dog.

I really don’t care about bloat of “efficiency” but I have seen so many PCs with messed-up registries. It was easier to pave them over than fix the damned thing. Why is that? The registry was not properly protected and everyone and his dog could modify it in the old days. Between Debian policies and file-protection, one package is not allowed to alter the configuration of another and the configuration rarely gets messed up. How simple is that? Yet it works. The difference may be that M$ doesn’t do the packaging but that’s their problem and they gave an insecure mess to the world.

Even ohioham knows that Microsoft’s security problems have been in userland. Lock Windows users into a vetted software sanctum, kick out java and flash and there goes 99% of the problems. Microsoft certainly deserves blame though, not including a firewall with Windows 2000 was a huge blunder. They also took too long to include a basic malware scanner and they should have been more aggressive in pushing newer versions of IE. Hell I could write a book on all their fuck-ups.

But I could also write a book on Nix XXXX-ups.

Pogson sez:

Tell us another one: the damned registry

To keep it short I’ll just respond to this. Registry bloat has never actually been proven to exist nor has it been proven that keeping configuration settings in a few dozen text files is more efficient than a registry. Go ahead and write 10k entries to the registry to see if it impacts system performance, post the results actually. This is all a myth from computers loaded with crapware whereby errant processes are actually affecting performance. The user then formats the computer and buys into the myth that it was the registry when in fact the processes were eliminated.

Ohio sez:
Except arm chips are not x86.

No they aren’t but they are running at much high clock speeds than p3s. NT was never built to be dependent on x86. Microsoft was always worried about a sideways attack from sparc.

These features to start from scratch puts MS about 4 to 5 years behind at best.

Ohio if you could speak King’s English then you could be an excellent lawyer as you are a master bullshitter.

You too believe in Unix magic but like the educated creationist are able to concoct an elaborate technical explanation for what really is emotional attachment to a personal ideal.

Anyhoo

I played a 3D driving game in WP7 (WinCE kernel) and it was silky smooth on a 800mhz ARM CPU. Are you really going to tell me that NT/Win32/.NET could not be ported to a quad core 1.5ghz ARM CPU? Let’s say we have to isolate NT to a single core… so what? Windows is already broken into multiple processes. As for 32/64 they could make the split at this point. Basically a trimmed down Win64 for ARM.

Oh and kozmcrae please don’t call me a Microsoft troll, Sinofsky undoubtedly hates my guts as my Windows 8 criticisms have been posted on his blog.

–XP works fine on a p3 500mhz so I’m not sure why you think it would be so far fetched to have Windows running on a quad core ARM cpu with a few gigs of ram.–

Except arm chips are not x86. Big little arm chips are more power effective and require some very interesting process management voodoo magic.

So quad core of what. A big little quad core can have 2 arm processes of one version and 2 arm processes of a different version. With the only interlink between the two processor groups being ram.

This is alien to x86 windows design. This is not alien to Linux. Super computer processing might seam to have nothing todo with mobile phones. But Linux has run on super computers for years that are not purely 1 cpu type. So you might have a power/x86 super computer. Windows does not run on that effectively.

ze_jerkface it is not that the Linux or BSD kernels are magically special. Its that the Linux and BSD kernels have been in a environment that has required an extra set of features to be developed. These features pay off in mobile devices where power effectiveness is important.

Yes the environment where the feature difference starts is mixed arch super computers where Microsoft has never got a foot hold. Does not have the tech even to get a foot hold.

These features to start from scratch puts MS about 4 to 5 years behind at best.

Some of the huge errors that Linux and BSD have had fine tuning for multi arch super is scary and worse seam insanely minor but stack up. To find some of these errors you need multi arch systems of 4000 Cores +. Windows NT no version yet can operate on a system that large.

ze_jerkface getting it yet its not the NT design its how it can been tested.

The registry issue could be fixed. Anyone looks closer enough will find the performance problem with the registry is mostly a broken b-tree implementation that gives performance gains on one hand but big performance costs long term as the price for the gains. Nothing is a free lunch.

Also NT was design to have more than 1 copy of the sub-systems. Major clean up and going back the the base design would allow applications to have 1 hive per application. NT design is not past fixing but you are talking a huge investment required to sort out win32 and win64 subsystems so they can run more than 1 copy side by side without spitting chips. Microsoft has attempted this.

Yes once you have win32 and win64 subsystems side by side the NT driver space has to be updated.

The Linux BSD and solaris kernels already have been updated to support multi copies of their subsystems running on top of the same kernel.

One mandatory rule. No kernel space drivers specially for particular user-space applications. So to catch up means Digital rights management drivers have to go by by from windows.

Tell us another one: the damned registry, re-re-reboots, loadable kernel modules distributed with the kernel, generic kernel modules, the EULA… All of those things are more than sufficient reason to switch however M$ is locked in and cannot afford to let the sheeple know they were sold a bill of goods. Apple made the switch and they just said things will be better but Apple was tiny then compared to M$’s current installed-base. How many hundreds of millions of people does any business want to be angry with them?

Reports are that “8″ on ARM is sluggish. Android/Linux is snappy on the little woman’s smart phone. A bunch of apps and no waiting and she has a two-year old model. There’s a reason, M$ did not attempt to provide the old API on the ARM processor. They couldn’t afford the CPU cycles to emulate even on a Tegra 3. They rebuilt their office suite to run natively. They could not get ISVs to invest that much to port to ARM for a vapour-market.

“Why would Microsoft rebuild Windows over a Nix?”

Because Microsoft’s OS was never built with security as part of the architecture for one. It was glommed on later. The result is that Microsoft security is always one step behind the malware. They need an OS that has the security built into its framework. Not patched on afterward.

Why don’t you step out of your troll suit and take a look around. You’d be amazed at how advanced the World’s OS has become. And its done it in far fewer lines of code than Microsoft has. And that includes all the hardware drivers.

XP works fine on a p3 500mhz so I’m not sure why you think it would be so far fetched to have Windows running on a quad core ARM cpu with a few gigs of ram.