Live data from Hacker News

Linus Torvalds on the new MacBook Air

realworldtech.com

111–120 of 128 posts

Re: Linus Torvalds on the new MacBook Air

#111
post #73

Earlier quoted context omitted.

Apple is a baron of customer hostility and anti-competitive practices. Customer lock-in, closed platforms, corrosion of right to own or repair, forced obsolescence. That's how they do business. Is there some point where how you do business becomes the product, and the intended product (e.g. reinvention of the desktop processor) becomes just a byproduct? We've a cultural inclination to focus on the what, and forget th…

Then don’t buy one. Not sure why anyone would be tired of a product they could ignore. Unless Apple and Microsoft are oppressive because they won’t collapse and build Linux laptops. It makes no sense. Just go run Linux on some ancient Thinkpad.

Haven't you read my comment? It's not the product per-se that's the problem. It's the lobbying, the market abuse, the anti-competitive practices.

Re: Linus Torvalds on the new MacBook Air

#112
post #44
post #26

Earlier quoted context omitted.

The issue is that you really start feel the performance limitations of a cheap ARM SoC. Especially if you do a bunch of C compiling like Torvalds would.

C compiles in a flash on today's hardware. It's only when you have a BIG C codebase (the kernel counts as big), or a medium-sized C++ codebase, that things slow down.

C++ code that uses templates heavily is painful to compile, using 6 GiB of RAM is possible even for a "make -j1" build. It's kind of funny that a VPS with little RAM can build a full Linux kernel with all the modules and drivers, yet cannot build a small webserver. For big projects, the final linking process also eats enormous amount of RAM, it's possible for a small system to survive all the build and gets killed during the final linking.

Re: Linus Torvalds on the new MacBook Air

#113
post #97
post #26

Earlier quoted context omitted.

The issue is that you really start feel the performance limitations of a cheap ARM SoC. Especially if you do a bunch of C compiling like Torvalds would.

One could just cross-compile remotely?

Sometimes, it's just valuable to have a local environment so you can use develop and test conveniently "at home" while using the same computer. It's why there are ARM workstations.

For example, Linus Torvalds said [0],

> Some people think that "the cloud" means that the instruction set doesn't matter. Develop at home, deploy in the cloud.

> That's bullshit. If you develop on x86, then you're going to want to deploy on x86, because you'll be able to run what you test "at home" (and by "at home" I don't mean literally in your home, but in your work environment).

> Which means that you'll happily pay a bit more for x86 cloud hosting, simply because it matches what you can test on your own local setup, and the errors you get will translate better.

> This is true even if what you mostly do is something ostensibly cross-platform like just run perl scripts or whatever. Simply because you'll want to have as similar an environment as possible,

> Which in turn means that cloud providers will end up making more money from their x86 side, which means that they'll prioritize it, and any ARM offerings will be secondary and probably relegated to the mindless dregs (maybe front-end, maybe just static html, that kind of stuff).

> Guys, do you really not understand why x86 took over the server market?

> It wasn't just all price. It was literally this "develop at home" issue. Thousands of small companies ended up having random small internal workloads where it was easy to just get a random whitebox PC and run some silly small thing on it yourself. Then as the workload expanded, it became a "real server". And then once that thing expanded, suddenly it made a whole lot of sense to let somebody else manage the hardware and hosting, and the cloud took over.

> Do you really not understand? This isn't rocket science. This isn't some made up story. This is literally what happened, and what killed all the RISC vendors, and made x86 be the undisputed king of the hill of servers, to the point where everybody else is just a rounding error. Something that sounded entirely fictional a couple of decades ago.

> Without a development platform, ARM in the server space is never going to make it.

And,

> And the only way that changes is if you end up saying "look, you can deploy more cheaply on an ARM box, and here's the development box you can do your work on".

> Actual hardware for developers is hugely important. I seriously claim that this is why the PC took over, and why everything else died.

> So you can pooh-pooh it all you want, and say "just cross-build", but as long as you do that, you're going to be a tiny minority, and you don't see the big picture, and you're ignoring actual real history.

> And btw, calling this an "unixoid" mindset is just showing what a total disconnect to reality you have, and how stupid your argument is. Unix lost. Yes, it lives on in the shape of Linux, but Unix lost not just to Linux, but to Windows. In fact, arguably it lost to windows first.

> Why? Same exact reason, just on the software side. In both cases. Where did you find developers? You found them on Windows and on Linux, because that's what developers had access to. When those workloads grew up to be "real" workloads, they continued to be run on Windows and Linux, they weren't moved over to Unix platforms even if that would have been fairly easy in the Linux case. No, that was just unnecessary and pointless work. Just continue to deploy on the same platform.

> Exact same issue on the software side as with the hardware. Cross-development is pointless and stupid when the alternative is to just develop and deploy on the same platform. Yes, you can do it, but you generally would like to avoid it if at all possible.

> End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.

[0] https://www.realworldtech.com/forum/?threadid=183440&curpost...

Re: Linus Torvalds on the new MacBook Air

#114

Earlier quoted context omitted.

> If there was sufficient demand there's nothing stopping someone from making a MacOS compatible release That assumes that it's something that can reasonably be ported. Granted, that does cover most software, but there are exceptions that for whatever reason are difficult to port. Docker is the poster child for this since it uses Linux kernel primitives; the way it runs "on" Darwin is to run Linux in a VM.

Docker's never been quite as portable as imagined because of this. I wonder if this will make people rethink it as a model for containerization. Interestingly, FreeBSD has native Docker support because it has a Linux compatibility layer that adds/maps/implements(?) Linux system calls so it FreeBSD can run Linux binaries. Looks like FreeBSD Docker support is also broken right now.

The annoying thing is that it should be that portable - docker is modular enough that you should be able to replace containerd/runc with a jail-based version and everything just works, and the OCI image format outright talks about features to make the system OS-agnostic. It's just that nobody's bothered to actually implement it:(

Re: Linus Torvalds on the new MacBook Air

#115

I'm really not holding out much hope that Linux will natively run on these M1s, even if we get it to boot there's all the driver issues for the integrated GPU, audio, wifi etc. I'd imagine there is a lot of power management stuff on there too.

The bootloader and drivers aren't the only problems holding Linux back from being ported to these SoCs, it's that Apple's ARM SoCs have the same challenges all ARM SoCs have when it comes to Linux ports. ARM servers are similar to x86 machines in that they use UEFI and have enumerable buses for hardware discovery. ARM SoCs use custom bootloaders, and lack enumerable buses. Hardware configurations are almost always un…

[deleted]

Re: Linus Torvalds on the new MacBook Air

#116

I don’t know why we keep caring what he thinks

Linus has incredible knowledge about the lower levels of the computing stack (CPU architectures, etc), and so I, for one, am very interested in knowing what he thinks about those things. But regarding his other opinions in general... yeah, I'm with you.

dude doesn't even program anymore (these are words from his own mouth) so no he doesn't, what he does is micro manage commits.

Re: Linus Torvalds on the new MacBook Air

#117
post #82

Earlier quoted context omitted.

I am referring to the ability for consumers who purchase a hardware product with these Corporation's operating system installed to be able to dual boot, or replace the OS with a Linux distribution. I believe this is both in line with free-market enterprise as well as core values such as individual liberty and property ownership. Anti-competitive and predatory practices should not be justified by people such as yourse…

You can run and boot Linux on both macs[0] and pc's[1] and have been able to do so continuously for more than a decade. [0] https://www.google.com/search?q=boot+mac+into+linux [1] https://www.google.com/search?q=boot+pc+into+linux

This might have gotten fixed recently, but last time I checked, there hasn't been a working Linux wifi driver for Macbooks starting with the first Touchbar model, which is a non-starter for most practical purposes.

Re: Linus Torvalds on the new MacBook Air

#118
post #51
post #17

Earlier quoted context omitted.

Do we even know how to access the GPU? On x86-based systems there would be a standard bus (PCI/AGP/PCIe) to enumerate the the graphics device, but my impression is ARM doesn't have such things. A lot of the recent improvement in graphics on Linux has come from manufacturers deciding to become cooperative rather than there being more people reverse-engineering graphics drivers. (Broadcom is contributing support for th…

ARM does, in fact, use standard buses, PCIe on most high/medium end parts -- although, some low end chips just use a built-in USB controller or SPI/I2C for all peripherals. What isn't always available is a way to dynamically enumerate a device's, uh, device tree. On PCs, this is usually accomplished through ACPI tables, where the bootloader (BIOS or UEFI) populates a table of data and callbacks to AML bytecode functi…

PCI and USB bus standards include dynamic enumeration but ARM SOCs normally only use them as external interfaces.

IP blocks inside the SOC itself usually just expose their registers on an AXI bus with no enumeration support at all, this is most likely the case with the M1 gpu.

Re: Linus Torvalds on the new MacBook Air

#119
post #100
post #2

So it seems that what could be problematic is not getting it to boot but rather how to get proper graphics support. How difficult would it be to reverse engineer the GPU?

It's still a PoverVR GPU with serial numbers filed off.

Apple has been designing their own GPUs for a while.

Re: Linus Torvalds on the new MacBook Air

#120
post #105
post #89

Earlier quoted context omitted.

What matters is actually meeting people’s needs effectively and at high quality. That’s what’s good for society.

Sort of like the fossil fuel industry?

I mean, that's how the industrial revolution started and continues to this day, so yes, fossil fuels as well.
Post reply on HN