I want to see a manufacturer do one of these without poverty spec RAM. Same with disc, the same options you get on an iPhone 256, 512, 1Tb.
Then you have a nice ARM laptop, not a poverty spec machine for a 7 year old to use instead of a Chromebook.
Then you have a nice ARM laptop, not a poverty spec machine for a 7 year old to use instead of a Chromebook.
'Low spec' is a pretty normal phrase that gets the point across.
To your larger question, the problem of why equating "poverty" with being bad is that as human beings we have the tendency of overgeneralizing negative characteristics, sometimes called the Horn Effect. A person is poor, and that's bad, and therefore the person themself is bad.
The laptop is targeting a specific price point, its specs are appropriate to that price point. There are plenty of reasons to want a low-cost linux laptop that have absolutely nothing to do with being poor.
Using the phrase now in this context can feel jarring. I think taste and sensibilities have changed - lots of old jokes don't land like they used to.
The ram does feel paltry in this day and age though. I wish you could use a sodimm module like the honeycomb uses.
Tomorrow i will buy that incredible new laptop, any cheap atom/celeron netbook would be faster..and better...and probably cheaper:
https://www.amazon.com/Lenovo-Chromebook-Processor-Graphics-...
The RK3566 that is used in the latest Pine64 products like the Quartz64 and PineNote can address more, I would expect a laptop using this chip at some point.
Also Apple went out of their way to make Linux and other OSs able to boot on it, so don't expect Apple to take away what they worked hard on.
What's novel about this Linux Laptop though is the low cost, $200. But you get what you pay for. And the M1 is, a year from now, probably going to have better (if not completely) upstream hardware support.
Also, while there is a ways to go, a shocking amount is fully completed: I2C, UART, Power Management, GPIO, Display Controller, USB, Thunderbolt, NVMe storage, the works. Hector says he is just rewriting a few drivers from other folk, going to merge it upstream, and then really only the GPU is remaining.
But he has a friend working on that and less than a year later and despite not being the primary focus, they're nearly at OpenGLES, which has shocked people for how fast the GPU drivers are coming together.
Do you have more details? I was under the impression Apple did nothing and haven't published any documentation, making a Linux port an exercise in reverse engineering every little bit. If Apple really wanted Linux to be able to run on M1s, they could have upstreamed patches / sponsored the development required. Instead people are volunteering their time to do that without any help (direct or just documentation or tooling), hoping Apple won't pull the rug from under them.
Apple could have just copied-and-pasted the iPhone boot process, and that would have been extremely easy to do because M1 Macs and iPhones and iPads all share the same system for booting (being all Apple Silicon chips), that is, iBoot. Apple could have just thrown in iBoot but with signature enforcement for macOS instead of iOS and called it a day. Nothing but macOS would boot, but would Apple really care?
However, Apple went out of their way to not do this, but extended iBoot with Boot Policies, also referred to as the LocalPolicy. Apple documents this themselves at:
https://support.apple.com/guide/security/boot-modes-sec10869...
https://support.apple.com/guide/security/contents-a-localpol...
Along with the Permissive Security mode at
https://support.apple.com/guide/security/startup-disk-securi...
With the LocalPolicy, every partition and OS install gets their own Security Policy, which is another area where Apple goes above-and-beyond other systems. On Windows computers and Android devices, a device would typically be marked as "Secure Boot Enabled" or "Secure Boot Disabled" (no signature enforcement), on a chip/system-wide level. With this Boot Policy system, every OS can have their own secure boot mode, meaning you could have a fully-secure MacOS install alongside a (unsecured) Linux install, no problem.
You might wonder, if every OS can just have their own secure boot settings, how come a thief couldn't just replace a secure boot MacOS partition with a Linux no-secure-boot partition. Apple managed to prevent this with an extremely complicated "ownership" system that prevents a third-party hacker or a thief from being able to clear those BootPolicies without the owner's permission, as documented at:
https://eclecticlight.co/2021/07/18/last-week-on-my-mac-the-...
Again, if Apple only cared about letting macOS run, copying-and-pasting regular iBoot would have worked fine. Instead, they had to tack on Permissive Mode, code signing from the Secure Enclave (for custom kernels), "ownership," and Boot Policies. A lot of work to just pull out the rug, right?
As if just enabling it with all of these otherwise-unnecessary add-ons wasn't enough, there are other signs of Apple being more... permissive about things. For example, unlike almost every other ARM chip which makes a huge mess of things, Apple has implemented their drivers in a way that means the same driver can handle different chips with the same core designs without almost any rewrites. An example of this is that, imagine the high-performance Firestorm cores on the M1. Marcan can just write a driver for Firestorm, and it will just work on the M1, M1 Pro, and M1 Max without rewrites for each chip that contains it (other than updating the device tree outside the drivers). That's unheard of for other ARM chips and makes future maintenance a breeze.
And, yes, Apple didn't provide and still does not provide much public documentation about their chip, but there is an extra grace: MacOS, apparently, has the ability to run under a lightweight hypervisor with hardware passthrough with no flak or patching necessary on the M1 chip (amazing considering how few ARM chips have virtualization, let alone this well implemented?) This meant that even though the hardware is undocumented, Marcan could write a small hypervisor called m1n1, run MacOS within it, and document all of the hardware calls and commands completely transparently. It didn't need to be that-well implemented. Maybe that's Apple doing a good job, or maybe it's them giving a less-obvious help.
Overly-complicated and ever-changing boot procedures are a soft form of locking down. They strangle the competition with discouraging roadblocks that generate backlash only among people who know more than they can explain.
Also ROFL @ "they went out of their way"
[0] https://www.nxp.com/products/processors-and-microcontrollers...
[1] https://mntre.com/media/reform_md/2020-11-27-reform-producti...
See also https://www.crowdsupply.com/mnt/reform/updates/post-campaign... and https://mastodon.social/@mntmn
The newest raspberrypi starterset at that moment (2028)?
Do you think you can even get a replacement battery for your a12 in 3 years?
Ah yes since the producer of phones needs to support them 5 years in franc (repair and updates), and hopefully 7 years (just security updates) in the future by eu law.
Ok then lets say 2027 ;)
I hope the RPi5 will make a similar jump in performance as the fourth generation. Right now desktop use is kind of slow, but still nice because a good passively cooled case keeps it around 50°C without any noise.