Buying a PC: Mac EFI or UEFI?

[Muazzam]

(I asked a somewhat similar question in auto-delete forum but it's a bit different.)

I've been waiting for the release of new MacBook Pro. Another option is Dell XPS 13 (similarly priced) or Microsoft's Surface Book.

You know, Windows 10 PCs use UEFI while Macs use a custom UFI. I'd my OS to run on the computer I buy, natively (i.e., not in a virtual machine or emulator). I'd mind using the firmware functions for disk access or I/O. Does anyone have an experience?

(Some people on this forum have told me to stop posting. Well, if you've a problem with me, personally, don't reply.)


EDIT: The question is mainly about choosing a platform to rewrite my operating system in (that currently relies on BIOS heavily), not just about buying a laptop.

[iansjack]

Buy a normal PC.

[Muazzam]

Buy a normal PC.

You mean a BIOS computer?

Well, BIOS is going to be obsolete in most PCs (if not all) in a few years. It'll render my OS useless.

ARM is popular too, but not it's not open/documented enough.

[SpyderTL]

I believe any new PC you could buy today will have UEFI support.

For every day use, I'd prefer the MacBook Pro, but for development (both as a workstation and as a development target platform), I would prefer a normal PC laptop. My work PC laptop has a touchscreen, but I've never used it, and probably never will.

I struggled with this same choice about a year ago, and I ended up getting an HP Elitebook, and I've been pretty happy with it.

[iansjack]

You mean a BIOS computer?

No, I mean a normal PC.

Not a Mac, not a SurfaceBook - a normal PC.

[Muazzam]

Thanks for the responses!

I'm curios to know about keyboard, disk, and graphics (native and firmware) interfaces on Macs.

How do these things differ from that of "normal PCs"?

[Rusky]

They should be mostly the same. Macs can run Windows and Linux without too many (any?) custom drivers - in particular, the graphics are just standard Intel integrated graphics, which are pretty well documented.

[Muazzam]

OS X's Boot Camp provides Windows with some of the drivers. I think, they'd be proprietary.

Do you think Linux uses any proprietary drivers on Macs?

[Nutterts]

Do you think Linux uses any proprietary drivers on Macs?

Depending on the hardware it might if you so choose just like running any flavor of linux on a normal pc. But booting via EFI doesn't require proprietary drivers of itself.

Mac's (from a hardware perspective) are just PC's which some devices (like the battery) on a different bus and some protection thrown in so MacOS won't boot unless it thinks it's an authentic Mac. It's almost trivial to install MacOS on a PC with the right mix of components.

I agree wholeheartedly with iansjack... you should buy a normal PC.

[embryo2]

ARM is popular too, but not it's not open/documented enough.

ARM has wider auditory than anything else. Because of cheap chinese mobile devices. Many of them are Android powered. iPhone also uses ARM. Mobile devices are our future.

Currently there is a relatively simple way towards ARM OS-deving, it's called Cyanogenmod and the Development section in particular. The project uses open source part of the Google's Android code and provides users with highly customized versions of Android. But nobody is bound to work on Android, it's just a starting place. There's a lot of ways for playing with clean Linux kernel without any Android's extensions. The only problem is the majority of drivers are not open source (but some are and can be used by OS-devers). And if we reckon that a hobby OS often has just a few drivers, the situation with mobile ARM development wouldn't look as scary as it could be at a first glance.

Cyanogenmod provides OS-devers with many useful tools and documentation. Also it's community is rich and active, so you can ask any question and most probably can get the satisfying answer. Basically the mobile system works just as an ordinary PC, there's a first stage bootloader, which is followed by the second level whose responsibility is to load a kernel. And all you need at the beginning is the kernel. Just your simple kernel with some "hello world" functionality. Or even simpler - you can use Linux's kernel with manufacturer's drivers installed and extend it in a way it suits you. And there's no need for open source drivers in this case - just get your preferred smartphone, root it and use already provided drivers as you wish. But it, of course, looks much more like Linux OS development. For personally your OS you need device with open source drivers which is not very hard to find.

But all this requires some time consuming shift from x86 PCs towards mobile ARM ecosystem.

[Roman]

Do you think Linux uses any proprietary drivers on Macs?

There are open source drivers for all Mac hardware (at least for MacBookPro10,1). The only exception is the Broadcom WiFi card - an open source driver is available for it, but it sucks (there's a good proprietary one though).

Mac EFI is not much different from UEFI, I used UEFI documentation from the web and it worked.

[physecfed]

ARM is popular too, but not it's not open/documented enough.

Neither. From ARM directly and from any number of other sources you can find the complete logic of ARM processors, and almost any one of them to boot (in fact, there are open-source ARM clones for FPGAs, i.e. the Amber processor. The issue you'll face is that ARM is simply a seller of IP cores for their processors; they don't fab out chips like other companies do.

If you're a large company attempting to make a product with a processor in it that does some function X, you'll probably contract ARM and a bunch of other vendors for SIP cores that comprise ARM cores and the required intercomm/interconn logic. You might design your own core and include it. You then go to a foundry and ask them to make your design for you. The issue with ARM devices isn't their "openness" (although open-source people I've worked with tend to hate ARM), nor their documentation - it's their degree of standardization.

Unlike the PC market, which is driven by the de facto requirement with previous versions of that "standard" and software, ARM does not have a standard with virtually global scope forcing it to conform. For Android devices of one particular epoch, devices might have X, X, and X features laid out in a particular manner, but going to the iPhone, that has custom Apple-fabbed devices, those phones use internal standards that might differ completely. The issue with developing for ARM is the lack of a single, unifying standard that has leveled the playing field and forced everyone to conform. For the developer, that means that you'd be fighting an uphill battle to differentiate devices at the hardware level from each other, or targeting one specific implementation family of the cores. I suppose where the degree of "openness" comes in is that a large number of the vendor SIP cores (non-ARM, vendor- and chip-specific stuff) are very lock-and-key on docs. That's a battle I've had to fight at the corporate level as well.

Many "desktop" Linux distributions, for example, have begun to target ARM, because they realize they can now include the logic required to enumerate and cover a large number of the different bases in play. If you're interested in ARM development, I'd look at the ARMv7 ports of Ubuntu and Debian to the Raspberry Pi and Raspberry Pi 2.

[Muazzam]

Do you think Linux uses any proprietary drivers on Macs?

There are open source drivers for all Mac hardware (at least for MacBookPro10,1). The only exception is the Broadcom WiFi card - an open source driver is available for it, but it sucks (there's a good proprietary one though).

Mac EFI is not much different from UEFI, I used UEFI documentation from the web and it worked.

That's a good reply, thanks!

[Muazzam]

Embryo2: The greatest pleasure for me in OS development is seeing your computer using your own code. Using an existing driver or kernel, even the open-source one, won't work.

[Muazzam]

I agree wholeheartedly with iansjack... you should buy a normal PC.

Any good arguments? (Other than Mac's price. HPs, Dells, etc. are also similarly priced.)

I'd prefer Mac because OS X can replace (for me) Windows and Linux and because I'm just curious about it.