/tech/ - Technology★

Nice sources.

>>825624

http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf

As Torvalds said:

>EFI is this other Intel brain-damage (the first one being ACPI). It's

totally different from a normal BIOS, and was brought on by ia64, which

never had a BIOS, of course.

>Sadly, Apple bought into the whole "BIOS bad, EFI good" hype, so we now

have x86 machines with EFI as the native boot protocol.

UEFI is like systemd, features upon features which make system incredibly more complex and bloated.

I'll be off the Intel/AMD trainwreck long before then tbh. Planning to get an ARM SBC within a few months, and then move to POWER or other architecture.

>>825634

You're never going to do either of those. Anyone who gives a fuck does something about it when it occurs to them. People who are doomed to failure "plan" to achieve a vaguely defined goal. You can buy an SBC right now and start using it as your main computing machine. But you won't.

When I learned about Libreboot, first thing I did was buy an X200 to flash it. I have three Libreboot machines now. Because I care about FLOSS, and about my security. If you cared, you'd have done something.

>>825621 (OP)

Did they not implement already existing linuxbios aka coreboot and invent EFI on purpose? Literally the only major difference between BIOS and EFI is more proprietary firmwares for PCIe devices sitting on one chip which I am sure can be done with coreboot and built-in broken DRM.

>>825634

The real issue is finding:

- Something ATX with SATA and PCI-E ports.

- With a GPU without proprietary VBIOS and driver (Vivante or Nvidia Kepler I guess).

>>825648

It could be the cost. The x200 isn't that expensive.

>What Fedora ended up doing was using Microsoft's secure boot key signing services through their sysdev portal for one-off $99 fee.

>Our first stage bootloader will be signed with a Microsoft key.

http://www.zdnet.com/article/linus-torvalds-on-windows-8-uefi-and-fedora/

w-what? i'm reading this for the first time now

>>825713

I don't know what happened then, but this was a fun read:

https://arstechnica.com/information-technology/2013/02/linus-torvalds-i-will-not-change-linux-to-deep-throat-microsoft/

>Guys, this is not a dick-sucking contest.

t. Torvalds

If only more software projects had maintainers like Linus...

>>825684

I assume you mean inexpensive, but that's besides the point. The anon I was replying to was talking about getting an SBC "within a few months", when you can buy them for a tenner off aliexpress

>>825632

>UEFI is like systemd, features upon features which make system incredibly more complex and bloated.

It goes deeper then that, UEFI without the compatibility Support Module makes the x86 no longer IBM compatible. With CSM you can still boot into PC Dos version 1.0 as CSM will emulate IBM compatibility. Without CSM you need a OS that works with UEFI. Thus basically Intel is breaking a quarter century of legacy support just because Intel does not like people using CSM to solve problem with UEFI proper.

>>825766

>don't care at all about the 3D games or HD videos

2D games also benefit from a GPU. And xscreensaver's flying toasters or IRIX screensaver.

>>825776

The PDF >>825625 linked admits it's because of secure boot and software signing. This is what was always intended a decade ago with "Trusted Computing" except at this point nobody cares about fighting the good fight anymore.

>>825791

I guess those are games like brogue that use special lighting effects or whatever? Well I don't play those either. I've had no GPU support on my past two laptops, in fact. But it's never been a problem, since any old potato can run 8-bit computer/console emulator or equivalent game. And my screensaver is just a shell script that rotates between ascii demos like /usr/games/{rain,worms} or the more colorful asciiquarium and cmatrix.

>>825776

What the fuck are people doing that they need to buy a brand new 2017 computer to run DOS1.0 software but they can't obtain any kind of older computer to run DOS1.0 software?

>>825816

Writing operating systems so as to make hymns and poems for the Lord?

>>825816

Well the IBM compatible standard goes from 1981 and will die when CSM dies. In the IBM standard the BIOS looks for a boot sector in the devices, once it finds a boot sector it executes the commands in the boot sector. After that the BIOS is not needed anymore for anything but calls for the time/date. UEFI is different, it runs its own operating system.

So you are decided to write your own OS. The IBM standard is well documented and simplistic, the UEFI has crap documentation and a bloated buggy mess to point that returning null for the password allowed UEFI to think it should allow a remote user administration powers to the UEFI OS running below the real OS.,

>>825822

All of that is well and good in of itself. My question now is why does it offend you that a computer from 2017+ is not backwards compatible given the context that there are millions of perfectly usable older computers being thrown away all the time. If it's a matter of compatibility with older target platforms, isn't it easy enough to get a few of those older computers to do that kind of work?

As for me, I only care about free software. The purpose of project like Libreboot is to provide a free software implementation of basic IO system. When I have free software, I have the freedom to modify the software at any time. Issues of "bloat" or BIOS bugs can be fixed whenever I feel like doing it.

>>825835

Well it is a matter of breaking the standard. For example FreeDos doesn't know what to do when CSM goes away. Implementing UEFI for FreeDos would break their compatibility with Dos applications.

>>825836

>For example FreeDos doesn't know what to do when CSM goes away. Implementing UEFI for FreeDos would break their compatibility with Dos applications.

Okay, so this is a matter of proprietary software breaking when the target platform changes. I cannot say that I sympathize with this. This is the nature of all proprietary software: you are forbidden to help yourself whenever you choose to rely on it, you are forbidden to help your friends whenever you choose to rely on it. If you're smart, you would invest your resources into free software because free software gives users the freedom to fix and update the software.

>>825840

It is a matter of all old code breaking, even open source Dos application doesn't understand UEFI or why they can't directly interact with the hardware. Dos applications expect to be in a unprotected environment where they can peek and poke most any memory address.

This also means if you are learning to program as OS you have to start with a far more complex OS, you can't just start off by feeding the CPU commands at the boot sector.

>16 bit x86

Who the fuck cares though. The 8086 was a piece of shit even for it's time. Unless you niggers move to Talos II you goyim will lap the next Intel/AMD chip up.

>>825847

Without CSM all devices need a EFI system partition to boot. Still booting from a boot loader on the boot sector, well after CSM support goes away that system drive won't boot and you'll have to re-partition it.

>>825621 (OP)

>WTF, first Intel jams UEFI down our throats now they are dictating which operating systems we can run on their architecture.

People who care enough about it will abandon the architecture, then.

Gaymers won't. Intel could literally bend them over a barrel and poz them, and they'd take it as long as they get their digital bread and circuses.

>>825846

>even open source Dos application doesn't understand UEFI or why they can't directly interact with the hardware. Dos applications expect to be in a unprotected environment where they can peek and poke most any memory address.

Yes, this is true and completely natural for all software. You're forgetting about what is the nature of all software. Software is a collection of instructions designed to achieve a specific outcome. Therefore when the nature of the software problem changes, the software also needs to be updated to reflect the change. Likewise, free software DOS programs need to change when the assumption of the IBM BIOS has changed. This is natural for all software.

>>825872

This is a potential solution that can work.

>>825875

But to what ends? FreeDos was created to have a open clone of Dos. It can run on hardware designed with Dos in mind, it can also run on modern hardware via CSM. Either way the bulk of Dos code works for the most part with the exception of some code freaking out with insane clock speed or code relying hardware bugs. The developers of FreeDos don't want make a UEFI version that won't run on original hardware and would break comparability since the entire point of FreeDos is binary compatibility with the old Dos standard.

Now you can say well that is just FreeDos but what does UEFI give to Linux other then security holes?

>>825883

What's the point of running FreeDOS and such on bare hardware anymore unless it's on a really old PC that you'd otherwise throw away? I might be wrong but can't you just run it in a VM and it'll work the same? I mean DOSBox on my Core2 laptop works great for old games.

>>825888

What happens in the future? In 2030 you wouldn't be able to use a 10 year old computer from 2020 just to mess around with learning how to program an operating system as it is no longer as simple as feeding the CPU commands in the boot sector. Not without changing out the firmware for something more open and well documented.

>>825897

What does function does UEFI perform? Why do you need the firmware to be an OS in its own right? What was wrong with the old IBM PC method of the BIOS just initializing hardware, looking for a bootable sector then running whatever is in the bootsector? Yes bootsector malware exists but so does UEFI malware which is much hardware to remove. Basically Intel is just making life easier for hackers to break into machines by having a undocumented OS running in the background that has full access to the system resources. In short given the old method wasn't broke why did Intel mess with it?

>>825901

>What was wrong with the old IBM PC method of the BIOS just initializing hardware, looking for a bootable sector then running whatever is in the bootsector?

Nothing at all.

I still want to know why you'd use DOS as an argument for the existence of the traditional BIOS. I agree that UEFI is shit because your pre-OS firmware shouldn't be able to run a web browser in it but I really don't care about it breaking compatibility with 80s and 90s software. I really honestly just don't.

>>825907

I'm pointing out the IBM compatible standard is a tried, tested and proven method that is well documented. Also there is still a lot of ancient code running in the wild running on old embedded systems, Intel basically is hindering their upgrade path as Intel is now asking businesses to upgrade to a OS with UEFI. Unless Intel also offers embedded x86 system boards that are IBM compatible.

>>825897

Being forced into a VM is just lame. It's fine if all you want to do is play some old games, but for OS dev, demoscene, etc. it's not satisfactory. It's more like writing for library/framework shit instead of making your own code run on the metal, which really is the whole point of those activities. And those VM always have bugs. Even Qemu and VMWare have bugs, and dosbox has shitloads more.

>This thread

>'Intel is killing industry platform standards so lets move onto an architecture with 0 interoperable platform standards like ARM or PowerPC'

Jesus Christ why do I keep coming this place with all you cringey larpers?

The best thing we can do is lobby Intel into not killing BIOS compatibility OR just support companies that use older EFI standards after 2020. For fucks sake though don't use the tranny architecture

>vid related

https://www.youtube.com/watch?v=bS9hiSwL1KY

This is why x86-64 is great and why we need to support some kind of platform standards. Because it sure as fuck isn't comimg from ARM or PPC

>>825907

>>825907

>breaking compatibility with 80s and 90s software

It's about maintaining backwards compatibility even if for only the sake of maintaining backwards compatibility.

Does RISC-V have any relevance here? People seem to be championing it as the architecture of choice for paranoid people.

>>826063

vapourware

>>826063

Nigger, this is a board that worships GNU/Linux-libre which is irrelevant even in the Linux world and prefers SysVinit over SystemD which is becoming increasingly irelevent itself

This place was never exactly the board to go to for subjects that are relevant to anyone besides Linux autists

>>826060

Backwards compatibility is the smaller issue. More importantly, I don't trust Intel anymore, no matter what they say or do at this point. ARM is just a small stepping stone away from Intel, and not the final destination. POWER is more promising, and there will probably be better stuff eventually. We *need* more varied architectures and competition in this marketplace! This was lost after the 80's and led to the shithole we're living in now, where the effective monopoly forces botnet shit on people who pay lots of money for the priviledge of being slaves.

Anyway I had other, nicer computers before Intel/PC (like Amiga), and now it's time to move to other computers again. There's nothing left in x86 for me, at all. Not that there ever really was to begin with. I used this hardware because it's the only realistic/available choice there was. Linux/BSD helped to make it less painful, but now even that doesn't help enough.

>>826105

Can companies other than Intel/AMD even make x86 chips? Pretty sure all the SSE/whatever patents just make it impossible, in which case we would indeed benefit from more varied architectures

Open-source stuff can be easily ported over anyway

I always told you that UEFI is jewish and backdoor, but you never listened and said shit like:

>MUH it's just a BIOS with cool graphics and overclocking! you can even run web browsers there!! so cool!!!

>>825776

>Without CSM you need a OS that works with UEFI. Thus basically Intel is breaking a quarter century of legacy support just because Intel does not like people using CSM to solve problem with UEFI proper.

Intel is part of New World Order. They are dropping CSM because they don't want people to run non-backdoored OS.

>>825835

>All of that is well and good in of itself. My question now is why does it offend you that a computer from 2017+ is not backwards compatible given the context that there are millions of perfectly usable older computers being thrown away all the time

do you realize those old computers won't be alive forever? at some point their prices will be huge

>>825901

>What does function does UEFI perform? Why do you need the firmware to be an OS in its own right? What was wrong with the old IBM PC method of the BIOS just initializing hardware, looking for a bootable sector then running whatever is in the bootsector?

That's the crucial question. What is the point of UEFI and what it gives?

pre-UEFI PC were totally fine and working. UEFI didn't offer anything to us other than MUH GRAPHICS AND WEB BROWSERS IN BIOS

>Yes bootsector malware exists but so does UEFI malware which is much hardware to remove. Basically Intel is just making life easier for hackers to break into machines by having a undocumented OS running in the background that has full access to the system resources.

Yes, the point is, those (((hackers))) are meant to be NSA, CIA, MOSSAD, NWO agents. It's they who requested Intel to produce UEFI. Now it doesn't matter if target is using GNU LINUX because they can hack him from UEFI, which all PCs no matter what OS use.

>In short given the old method wasn't broke why did Intel mess with it?

Because they were forced/bribed by jews, NWO, CIA, etc

We are not consumers anymore, we are the product.

The UEFI was not made for us, to help us with anything, it was made to help (((them))).

>>826060

>The best thing we can do is lobby Intel into not killing BIOS compatibility OR just support companies that use older EFI standards after 2020.

we cannot support other companies because Jewtel is a monopoly, there is no choice

>>826157

>Can companies other than Intel/AMD even make x86 chips? Pretty sure all the SSE/whatever patents just make it impossible, in which case we would indeed benefit from more varied architectures

>Open-source stuff can be easily ported over anyway

and proprietary software could still be run with help of emulators/translators

But do you think normies give a fuck about what Intel is doing? They will buy every locked shit that intel releases. And they will suck intel's cocks. The only solution is a holocaust.

>>825713

That last cianiggerfaggotkike was like UEFI is secure prevents rootkits etc but explain windows 10 then..

>>826105

You can compile your Linux/BSD and related software on any computer with a working toolchain, so it doesn't matter. Anyway in the old days we had standards that actually worked, without being over-complicated junk ripe for constant exploitation. RS-232 and parallel ports let you use devices on any computer. Same with SCSI. Even Cardbus stuff could be used on say, an Amiga 1200 (that's how some people did networking).

You're a real shit head too. Your idea of industry standard is whatever Wintel is. You're just a cock-sucking faggot who's too attached to your stupid games and Windows shit ware that even the thought of having other options and competetion in the market makes you shit your pants. Let me remind you that before Wintel there were other standards that were left behind: S-100 bus and CP/M, for one. Nothing lasts forever, but you're the one who wants to hold everyone else back with your emotional attachment to Wintel platform. Well fuck you, we deserve better.

>>825634

I've collected enough legacy hardware to keep myself in operation forever, and will only buy new hardware which isn't pozzed. Most of the SBCs and such are pozzed these days anyway. If you go back far enough in time (Apple G3/G4, pre-ME Intel) you can find machines which appear to be completely un-pozzed. They're older but perfectly suitable for most tasks and at this point are still available cheaply.

>>826248

I think (((they))) murdered him.

>>826161

>That's the crucial question. What is the point of UEFI and what it gives?

>pre-UEFI PC were totally fine and working. UEFI didn't offer anything to us other than MUH GRAPHICS AND WEB BROWSERS IN BIOS

For one, UEFI firmware can boot from drives of 2.2 TB or larger, BIOS can only boot from drives of 2.1 TB or less. BIOS runs in 16 bit processor mode and has to operate in 1MB of memory, which makes it hard to initialize multiple hardware devices at once and leads to a slower boot time with modern computer technology.

UEFI is still shit but BIOS isn't infallible either.

>>827128

>For one, UEFI firmware can boot from drives of 2.2 TB or larger, BIOS can only boot from drives of 2.1 TB or less.

That's not true. The 2TB limit is a limitation of the MBR partition table, which the BIOS doesn't even care about. The BIOS only checks if the first sector ends with 0x55aa and then runs whatever code is in the first sector. If and how a partition table is to be interpreted is up to the boot loader and operating system. That's why you can use GPT with legacy BIOS and have partitions larger than 2TB.

Why do we need BIOS or UEFI when superior coreboot exists? It has a full GRUB as payload, or fucking Tetris. Does UEFI have Tetris, huh?

Or even, why do we have some sort of soldered-on ROM on our PCs in the first place? Why can't the hardware like CPU itself initialize SATA and USB drives? Why do smartphones carry their boot loader on the same physical drive as OS and are fine with it?

>>825836

>oh no a 30 year old operating system will stop being able to be run on 2020 UEFI hardware

>>827196

>how dare the goyim want to choose what they install on hardware they own

>>827163

>Why do we need BIOS or UEFI when superior coreboot exists?

coreboot is a meme, it doesn't support almost any hardware and never will

>>827241

That's complete nonsense. Go buy an old computer or even go install a virtual machine.

>>827013

I have a pozzed rig and a non pozzed rig.

I wanted to make a really fast non pozzed, stretching the boundaries(was fun)

The non pozzed is a gigabyte GA78 which still has a bios, with a FX-8370e 8 core that does not have PSP overclocked to 4.5Ghz with 2133Mhz ddr3 16GB, RX480 8GB video, hardware raid (Sata 6GB/s) with 4 Samsung 850 SSD's in mirror/stripe mode. (read speed is 2GB/s, write is about 1GB/s), could go for full stripe to have 2Gb/2GB, which is close to a NVME setup.

TBH, the non pozzed is still relevant for anything even at this point. CPU is about as fast as a recent Intel Core i5-7600K quad core.

>>827241

protip: software is supposed to follow the hardware, not the other way around.

>>827417

That doesn't explain Intel with 40 years of backwards compatibility. That's a lot of cruft, and this was leveraged by the memory sinkhole exploit. There's probably lots of other bugs lurking in that mess...

In reality, software compatibility is what let Intel and Microsoft dominate the market, by standing on the shoulders of IBM. A long time ago the saying "nobody ever got fired for buying IBM" was a common saying in offices around the world. That's simply been replaced with Wintel platform, and people cling to it like a security blanket, even though it's botnet all the way down.

>>827680

Oh boy, the "x86 rust" meme again. As if to say firmware-level attacks don't exist on other architectures. Implying it's simply impossible to force an ARM processor to jump to any of its 6 privileged modes.

Get bent you LARPing nigger

>>825816

yes, let the hatred flow through you

>>827684

Show the exploits that give negative cpu ring elite access on other archs. I'm waiting.

>>827684

Besides Trustzone (part of AMD PSP) is found on many ARM processors, just saying.

>>827684

>Oh boy, the "x86 rust" meme again.

When was the last time you bought a computer with a 16-bit processor, less than 1 MB RAM, a floppy drive, or a CGA monitor? Why do you want a firmware that pretends the 286 and A20 gate are "advanced" features?

>>825632

EFI is pretty simple and has GPT support.

>>828014

Look up what turstzone is before talking about it in the same context as ME or something.

>>828037

>I don't know shit about architecture scaling or VLSI

Modern x86-64 chips resemble their 8 and 16 bit predecessors superficially at best

>>828047

Why would it need support for any kind of partition table? BIOS didn't have that either.

>>828102

An FPGA board like MiST is very different from a real Amiga 500, but it still behaves identically. The exact circuitry doesn't matter, the behavior does. The fact that there exist ring -2 exploit for amd64 that leverages old behavior is proof that the silicon itself isn't so important, only the behavior.

> Christopher Domas, a security researcher with the Battelle Memorial Institute, revealed an exploit that points to a design flaw in the x86 architecture that has been around since 1997 and affects numerous processor architectures still in use today.

http://www.tomshardware.com/news/blackhat-x86architecture-vulnerability-disclosed,29800.html

>>828102

>I don't know shit about BIOS

Glad you admitted that, son. Whenever you boot with BIOS, you start in 16-bit "real" mode with A20 disabled. Your latest PC can't access more than 1 MB RAM until you enable it with a fake keyboard controller.

http://www.win.tue.nl/~aeb/linux/kbd/A20.html

>The 8088 in the original PC had only 20 address lines, good for 1 MB. The maximum address FFFF:FFFF addresses 0x10ffef, and this would silently wrap to 0x0ffef. When the 286 (with 24 address lines) was introduced, it had a real mode that was intended to be 100% compatible with the 8088. However, it failed to do this address truncation (a bug), and people found that there existed programs that actually depended on this truncation. Trying to achieve perfect compatibility, IBM invented a switch to enable/disable the 0x100000 address bit. Since the 8042 keyboard controller happened to have a spare pin, that was used to control the AND gate that disables this address bit. The signal is called A20, and if it is zero, bit 20 of all addresses is cleared.

>>828382

Anon, this thread is literally about Intel killing BIOS

>>828129

Its not about support. BIOS has "support for 101" things that nobody uses. OS now basically ignore 99% of the BIOS and leave the influence asap.

With UEFI, a lot of that cruft can be cleaned up and replaced with something far leaner than BIOS (like in Coreboot). Instead of running a bunch of legacy BIOS programs just to "chainboot" and reach your bootloader, UEFI requires a lot fewer steps. UEFI can even BE your bootloader if you wish.

Coreboot is an example of good UEFI. OEMs can make shitty UEFI that does weird, nonstandard shit that breaks compatibility or spies on you or other has bloat in general. Of course, BIOS had this problem too.

>>825621 (OP)

>WTF, first Intel jams UEFI down our throats now they are dictating which operating systems we can run on their architecture.

Don't forget they stopped doing hardware validation 4 years ago, the users have been the beta testing department for all new Intel chips since then.

You know how every first iteration of a new AMD CPU design turns out to be a broken clusterfuck? The Athlon 64 having no thermal safety. Phenom 1 having a crippling TLB bug. FX chips being slow garbage. 2017w09-w30 Ryzens flat out failing under moderate FMA3 unit load. That's going to be happening to every Intel chip from now on. And unlike AMD they won't get their shit together with a second revision any more - Tick Tock is already dead and buried.

Short your x86 stocks and start buying RISCV and IBM, cause Tel-Aviv is about to have an industry crash in the next few years.

>>825715

underrated, but not really enough. this is blatantly an attempt to kill off any systems not under the (((thumb))) of the authorities, as is systemd, which Linus also doesn't speak out against much.