Live data from Hacker News

Never Bet Against x86

osnews.com

111–120 of 124 posts

Re: Never Bet Against x86

#111
post #76
post #59

Earlier quoted context omitted.

> The only things for which x86 still shines a little brighter are games, and native office. But office is mostly available on web, on Mac, and on Winarm. So games. Which aren’t big enough market mass to sustain the x86’s popularity — and is a segment (soon) under attack by Valve. You've missed a huge segment: Random in-house apps or niche vertical market apps that are closely tethered with a business workflow to the…

No I did not miss it. That has moved to web, either directly Or through an RDP/VNC interface where the actual windows virtual machine is hidden. Embedded/hardware is the last segment still not replaced by web.

It absolutely has not. I absolutely agree most of those kinds of apps could, and those that can probably should, but more than enough have not.

I support a lot of dental practices using Patterson Eaglesoft and they still don't officially support VMs in any form, even for the server (despite it working fine) while they have removed all support for using terminal services. Obviously the basic application works fine, but a dental practice needs to be able to take digital x-rays. Shock the sensor drivers only exist for Windows and back when RDP and Citrix were supported it required a special bridge running on both the client (which of course still had to be Windows) and the server.

We used some thin clients back in the day for front desk stations and hygiene rooms that didn't need any special hardware, but the main practice rooms and the pano stations always needed full Windows PCs.

The client app is built with PowerBuilder so it'd require a deep rewrite to support any other platforms.

The server side is a Sybase SQL Anywhere database and a SMB file share so it could easily be run natively on Linux but the vendor can't be bothered.

This is a company that still insists that every user needs local admin privileges, despite literally nothing going wrong when they don't have it, and who usually doesn't support new Windows releases until a few months after it becomes the default for new PCs.

---

There are other dental platforms that do have web interfaces intended mostly to enable the use of iPads and other tablets but switching platforms is far from straightforward for practices with years of data, custom integrations, etc. Even if you are willing to go through the trouble (or starting fresh) those platforms, to my knowledge, still require Windows PCs for digital x-ray support.

Re: Never Bet Against x86

#112
post #111
post #76

Earlier quoted context omitted.

No I did not miss it. That has moved to web, either directly Or through an RDP/VNC interface where the actual windows virtual machine is hidden. Embedded/hardware is the last segment still not replaced by web.

It absolutely has not. I absolutely agree most of those kinds of apps could, and those that can probably should, but more than enough have not. I support a lot of dental practices using Patterson Eaglesoft and they still don't officially support VMs in any form, even for the server (despite it working fine) while they have removed all support for using terminal services. Obviously the basic application works fine, bu…

I did write “embedded/hardware”. Yes, you need special drivers for your X-ray/drill/whatever so you earned an another decade of windows.

But in the places I frequent (backoffice, municipal, finance) it’s all gone web and rdp-through-web (which is web, in the sense that it doesn’t require windows on the client) with centralized administration with minimal (not quite self-serve but reasonably close) thin client users.

Re: Never Bet Against x86

#113
post #106

Earlier quoted context omitted.

The x86 emulation for fallback is (I’ve heard - not tried) usable for the first time. Microsoft tried in the past without a Rosetta equivalent; Apple succeeded twice with Rosetta. They did not try to switch cold turkey the way Microsoft did.

It doesn't cover device drivers, nor stuff like DAWs plugins. Apple doesn't care about backwards compatibility like the PC, who doesn't move, stays behind.

Are you familiar with anyone who uses a 20 year old DAW?

Retro Amiga trackers don’t count.

Re: Never Bet Against x86

#114
post #108
post #103

Earlier quoted context omitted.

Let's say some hw manufacturer would open-source the required specs to implement it on it's chips. (Very unlikely, but let's say they do...) So what? Dangerous capabilites remain.

What do you mean by "Dangerous capabilities"?

https://en.wikipedia.org/wiki/UEFI#Criticism

https://en.wikipedia.org/wiki/ACPI#Criticism

https://en.wikipedia.org/wiki/System_Management_Mode#Problem...

Re: Never Bet Against x86

#115
post #107
post #101

Earlier quoted context omitted.

You can convert a DTB blob back into source code: dtc -I dtb -O dts -o devicetree.dts blob.dtb Big, biiig, biiiiig difference! PS: You can also examine it directly as a directory tree in /sys/firmware/devicetree/*

You can convert ACPI bytecode back to source with iasl. No difference at all.

Then you can load them in u-boot and there's no need for any ohter blob.

Re: Never Bet Against x86

#116
post #102

Earlier quoted context omitted.

> there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0 It's not the same! A bootloader, once it loads the kernel and executes it, is overwritten in memory. No trace of it remains while the sistem is running - until the next boot. UEFI / ACPI / SMM continue to execute on the CPU after it finished booting, "under" the kernel, preempting it as they please.

I mean, it's not uniformly literally technically identical, but yes, an Android phone running its OS in ring 0 while other OSs run in other VMs on top of the EL2 (ring -1) hypervisor under the supervision of the Secure Monitor in L3 (ring -2) is very much in the same boat. Suggested reading: * https://www.maven-silicon.com/blog/privilege-levels-in-arm-a... * https://projectzero.google/2017/02/lifting-hyper-visor-bypa…

Oh, I didn't know that!

There goes freedom in the ARM world too.

Re: Never Bet Against x86

#117
post #115
post #107

Earlier quoted context omitted.

You can convert ACPI bytecode back to source with iasl. No difference at all.

Then you can load them in u-boot and there's no need for any ohter blob.

Yes, and you can do this with ACPI as well. There's no difference between the inherent freedom of ACPI and Devicetree.

Re: Never Bet Against x86

#118
post #114
post #108

Earlier quoted context omitted.

What do you mean by "Dangerous capabilities"?

https://en.wikipedia.org/wiki/UEFI#Criticism https://en.wikipedia.org/wiki/ACPI#Criticism https://en.wikipedia.org/wiki/System_Management_Mode#Problem...

Could you please describe the meaningful difference between SMM and Trustzone, or why the properties of UEFI and ACPI are dangerous?

Re: Never Bet Against x86

#119
post #56

Earlier quoted context omitted.

No, you are wrong. DOS COM files if 16 bit can't be run on 64 bit CPU's but 32 bit DOS binaries can be run under 32 bit GNU/Linux installs with DosEMU straight by just emulating the BIOS part, the rest is native.

It has nothing to do with being unable to run 16-bit code, that's a myth. https://man7.org/linux/man-pages/man2/modify_ldt.2.html Set seg_32bit=0 and you can create 16-bit code and data segments. Still works on 64 bit. What's missing is V86 mode, which emulates the real mode segmentation model.

That can be trapped for sure.

Re: Never Bet Against x86

#120
post #118
post #114

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/UEFI#Criticism https://en.wikipedia.org/wiki/ACPI#Criticism https://en.wikipedia.org/wiki/System_Management_Mode#Problem...

Could you please describe the meaningful difference between SMM and Trustzone, or why the properties of UEFI and ACPI are dangerous?

Until UEFI and secure boot, SMM would run code provided by the BIOS. BIOS was updatable, moddable, replaceable. See coreboot and numerous BIOS mods such as wifi whitelist removal.

Trustzone usually runs code from eMMC. These chips are programed in factory with a secret key in the RPMB partiton. It's a one-time operation - the user can't replace it. Without that key you can't update the code Trustzone executes. Only the manufacturer can update it.

Also, any ring -2 code can be used for secure boot locking the device to manufacturer approved OS, enforce DRM, lock hardware upgrades and repairs, spy, call home, install trojans by remote commands, you name it. And you can't audit what it does.

Post reply on HN