Posts by OSYSTEM 20 publicly visible posts • joined 8 Dec 2014
The only functional reasons to upgrade Windows I've seen are:
- better TCP/IP support in NT 3.5 (if i remember)
- Active Directory, LDAP and GPO
- 64-bit applications
- WSL2 (although one can argue that the previous Posix interface (services for Unix - SFU) should have been extended and improved instead.
The article implies that there is any connection between the two "OS/2 NT was rebranded as Windows NT". (The linked article has correct info.)
The only thing in common was that NT for a while had an OS/2 subsystem, capable of running 16-bit text mode OS/2 applications.
(Similarly NT has a Win32 subsystem, capable of running Win32 applications.)
See https://learn.microsoft.com/en-us/sysinternals/resources/inside-native-applications
We used OS/2 v2,3,4 a *lot* on account of it for many years being the only 32-bit operating system able to run Windows applications.
It was better at this than the first versions of NT.
Then VMware released their beta in 1999, which for a lot of use cases was better and more stable.
As any fule kno, Simula-67 was the object oriented¹ extension of Algol-60.
Simpler, more modern, and will get you dates with Norwegians more often than Algol-68.
So when will we get Simula-67 for GCC? (Yes, there is Cim, which hasn't been touched since 2014, and most likely won't build on a modern Linux distribution.)
¹Quite possible the first object oriented language.
With VMware workstation you can create/import/export VMs that work with vSphere, for troubleshooting, provisioning VM templates, developing OVF/OVA templates etc.
Despite Broadcom most large organisations still run vSphere for their own DCs so Workstation is still quite useful.
For just *running* Linux/Windows VMs on Windows, the built-in Hyper-V works well enough for all my purposes, if WSL2 doesn't fit.
For USB-support in Linux, see https://learn.microsoft.com/en-us/windows/wsl/connect-usb, works for Hyper-V as well as WSL2.
For USB-support in Windows, use RDP to connect to your VM (it covers most use cases with logged on users).
Also WSL2 is really a better Linux than Linux if you need to work with different distributions :-D
Any Docker container can be exported as a WSL2 image, see:
https://learn.microsoft.com/en-us/windows/wsl/use-custom-distro
It would of course be nice if they could execute RISC instructions directly, bypassing the translation layer for added performance.
Now that both companies feel the heat from ARM, and RISC-V, who knows what will happen in the future?
However, the underlying AMD and Intel architectures are quite different, and also do not have identical RISC ISA from generation to generation, within each company.
There is an old, but fairly good overview at https://www.euroben.nl/reports/web08/xeon.html
Considering the optimizations, speculative execution, etc, you could with some success argue that the CPUs do just in time compilation of x86/amd64 ISA to the underlying RISC :-D
Linux is also insecure by design, with - among other flaws - a monolithic kernel, Unix permissions, user ID 0 etc.
That is why have the SELinux abomination, that tries to patch some of flaws with digital duct tape :-)
See e.g. https://ubuntu.com/security/cves
And for messaging, just one example:
https://kafka.apache.org/cve-list
(The Windows NT original design was actually better, with a separate security monitor, SRM, and graphic drivers etc outside kernel space.
Microsoft has of course messed up a lot during the decades.)
You do know that the Windows registry can be accessed as file system, and items therein can be accessed as text files, right?
As well as a .NET objects that can be piped to other programs:
------------------------------------------------------------------------------------
PS HKLM:\SYSTEM\ControlSet001\Control\> ls -R 'HKLM:\system\CurrentControlSet\Enum\PCI\VEN_8086&DEV_15F2&SUBSYS_30038086&REV_03\'
Hive: HKEY_LOCAL_MACHINE\system\CurrentControlSet\Enum\PCI\VEN_8086&DEV_15F2&SUBSYS_30038086&REV_03
Name Property
---- --------
48210BFFFF3640AF00 DeviceDesc : @oem120.inf,%e15f2_3nc.devicedesc%;Intel(R) Ethernet Controller (3) I225-LM
LocationInformation : @System32\drivers\pci.sys,#65536;PCI bus %1, device %2, function %3;(88,0,0)
Capabilities : 16
UINumber : 13
Address : 0
ContainerID : {00000000-0000-0000-ffff-ffffffffffff}
HardwareID : {PCI\VEN_8086&DEV_15F2&SUBSYS_30038086&REV_03, PCI\VEN_8086&DEV_15F2&SUBSYS_30038086, PCI\VEN_8086&DEV_15F2&CC_020000
, PCI\VEN_8086&DEV_15F2&CC_0200
}
CompatibleIDs : {PCI\VEN_8086&DEV_15F2&REV_03, PCI\VEN_8086&DEV_15F2, PCI\VEN_8086&CC_020000, PCI\VEN_8086&CC_0200...}
ConfigFlags : 0
ClassGUID : {4d36e972-e325-11ce-bfc1-08002be10318}
Driver : {4d36e972-e325-11ce-bfc1-08002be10318}\0006
Service : e2fexpress
Mfg : @oem120.inf,%intel%;Intel
FriendlyName : Intel(R) Ethernet Controller (3) I225-LM
Hive: HKEY_LOCAL_MACHINE\system\CurrentControlSet\Enum\PCI\VEN_8086&DEV_15F2&SUBSYS_30038086&REV_03\48210BFFFF3640AF00
Name Property
---- --------
Device Parameters InstanceIndex : 1
Hive: HKEY_LOCAL_MACHINE\system\CurrentControlSet\Enum\PCI\VEN_8086&DEV_15F2&SUBSYS_30038086&REV_03\48210BFFFF3640AF00\Device Parameters
The Red Hat sales people I've talked to were quite annoyed with CentOS long before the IBM acquisition. Why pay for support - which honestly is not very good unless you are paying millions per year - when CentOS is as good?
The last couple of years RH have been making it harder for others to clone their OS. Taking over CentOS and making it unfit for production use is just the latest step.
We'll see how long they actual stick with the "open source" and GNU licensing when we get a good replacement for CentOS :-D
SSH is obviously a no no, if it is running in a shell (ssh user@example.com "cat script.py" >script.py) :-D
And of course no NetCat or similar stuff...
Basically nothing that can connect outside the local device in any way can be allowed. So nothing with scripting allowed at all basically, including Unix shells.
(Unfortunately for the world, Apple is the only major phone manufacturer with a business of selling phones to users and supporting them.
Almost all of Googles profit comes from selling user information to advertisers, almost none from developing secure operating systems with privacy controls.
Android licensees - best case scenario - support the Android phones for three years.)
Just hook up your VT100s and Teletypes and have at it. :-D
Powershell also supported.
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/bootcfg-ems
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/boot-parameters-to-enable-ems-redirection
VMs also
https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/serial-console-windows
(For the TTYs you may have to use a baud rate converter. Although I haven't tried, I suspect that neither the line driver nor the hardware will go low enough for a TTY.)
Fission fragments rockets are doable with the technology available today, according to NASA studies https://www.nasa.gov/pdf/718391main_Werka_2011_PhI_FFRE.pdf (There is a lot more available on their sites.)
Able to reach speeds of several percent of light, with heavy probes, missions to the near stars at 50-100 years are doable
Looking a bit further, anti-matter assisted fission and fusion drives (not pure anti-matter) look promising.
According to the NASA studies, the main problem is producing enough anti-matter.
A couple of accelerators similar to the LHC at Cern can do it, but they don't come cheap.
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20200001904.pdf aAnd a lot more).
If I were in charge of the budget, I'd start building fission fragment rockets, instead of buying vintage chemical engines at $146 each, which is the current silliness:
https://arstechnica.com/science/2020/05/nasa-will-pay-a-staggering-146-million-for-each-sls-rocket-engine/
/Ola
In principle Continuum is a great idea.
I got one (as a reseller promo) to see if it actually was something we could sell and/or recommend to our customers.
It's not for the following reasons:
- Microsoft is not committing any resources to Mobile. X3 shipped with tons of bugs, only a few which have been fixed.
Issues include but not limited to: Not recognizing externals displays (HP!); not being able to use the Ethernetport on the dock, the mike not working with Skype, etc.
- The total dealbreaker is the however the total lack of a file client:
I.e. you cannot access your corporate file server in any useful way. If you're on the road and need access to a file, you have to phone someone at the office with a proper computer, have them upload the file to a shared Onedrive account. Finally, you can actually continue working....
- Also, no Active Directory join (yes, you can use an Azure AD account), no SIP client (the architecture prevents SIP from working) so limited to only Skype (for Business) etc.
If they just had put Windows Professional on it, with proper driver support, it would have been great...
Regarding the network issue - have you tried using any proper switch (i.e. labeled HP or Cisco, *not* Netgear, D-Link or Supermicro)? To me it sounds like bugs in the switch queuing and flow control are conspiring with the NIC driver.
Also, you get similar issues *with* enterprise blade servers: A customer here had a major break down the other month. The root cause? Bugs in the IBM blade servers triggered a MAC address move for the FCoE adapters; the top-of-rack switches got confused; and the SAN went down.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
