News for hackers. Stuff that matters.
Re:Why systemd is a problem for embedded Linux by 0xbadcafebee on Sunday November 03, 2024 @10:19PM (#42038124)
> every embedded Linux device I've been paid to work on in the past five years had over 1GB of RAM

That is almost by definition not an embedded device. There's a reason we have vfork().

Re:Why systemd is a problem for embedded Linux by somerandomqaguy on Sunday November 03, 2024 @11:15PM (#42038379)
Huh?

Been a while since I was in the digital signage space but a lot of the equipment runs of the shelf RK3288 plugged into commercial displays. 2GB of RAM was pretty common. IIRC's though LG's WebOS TV's have minimum 2GB of RAM in the digital signage space directly built into the units themselves. I believe Samsung Tizen based units has similar RAM.

My router has 1GB of RAM in it. But even my cheapest routers have 128 to 256 MB of RAM. The Cisco 9300 Catalyst switches have about 8 GB of RAM, but switches with beefy amounts of RAM are getting pretty common now, even if somewhat pricey.

Yeah there's massive swathes of embedded space that's tiny. But the higher end stuff isn't exactly out of reach anymore. The RK3288's IIRC ran about $20 a unit at the time before I left the industry.

Re:Why systemd is a problem for embedded Linux by skydhash on Sunday November 03, 2024 @11:46PM (#42038537)
A decade ago, I had to settle for 512MB of ram for my Windows XP desktop.
Re:Why systemd is a problem for embedded Linux by gnabgib on Sunday November 03, 2024 @11:53PM (#42038580)
Three decades perhaps. In 2014 it was Windows 8, SSDs, 5th gen i7 (Haswell), 8-16GB of DDR4 ram. Even the iPhone 6 came with 1GB of ram.
Re:Why systemd is a problem for embedded Linux by skydhash on Monday November 04, 2024 @12:08AM (#42038667)
There's a huge chunk of people out there, not able to afford the latest.
Re:Why systemd is a problem for embedded Linux by kaba0 on Monday November 04, 2024 @12:56AM (#42038908)
I see you, but win XP was literally end of life 10 years ago.
Re:Why systemd is a problem for embedded Linux by M95D on Wednesday November 06, 2024 @10:17AM (#42063609)
So what?
Re:Why systemd is a problem for embedded Linux by znpy on Monday November 04, 2024 @02:05AM (#42039231)
Indeed, but still wrong.

In 2014 i got myself a second- or third-hand thinkpad X220, released in 2011, off eBay. It came with 8gb ram (two 4GB sticks) but it supported 16GB ram as well (two 8gb sticks).

The laptop (Asus A8Jc) I got when I was a teenager in ~2005 came with a dual core intel cpu and 1GB ram. So "512mb desktops" are way older than that.

Re:Why systemd is a problem for embedded Linux by happymellon on Monday November 04, 2024 @02:46AM (#42039429)
But desktops with those specs are <$100, probably less than $50.

If they can't afford those specs then you're approaching the group of people who can't afford a computer in the first place.

Re:Why systemd is a problem for embedded Linux by 0xbadcafebee on Monday November 04, 2024 @05:13PM (#42046550)
Yes, that's about 3 billion people. They use whatever they can afford. Usually that's whatever is very old, because new software doesn't run well except on very new hardware which is more expensive.

I recently wanted an MP3 player for an art project. Local stores don't sell mp3 players anymore, they only sell smartphones. So I bought an MVNO smartphone for $40. When I charged it up and tried to use it, I thought maybe it was broken, because it would take 10-30 seconds to load a settings menu or app. Nope, all these bargain carrier-branded phones are that slow. The hardware is [somewhat] old, but the new Android OSes run like molasses on them. It was like going back in time. Remember how Windows 98 would make your hard drive screech for a good couple minutes as it struggled to juggle the swap memory so you could open MS Word? That's the experience with most software today with "affordable" hardware even a few years old.

So using Windows XP is often the only choice, if you don't have a lot of money, like 1/3rd of the planet. (And it's not just the third world. 59% of American households with K-12 school kids don't have a working computer, or it works too slowly to be useful)

Re:Why systemd is a problem for embedded Linux by happymellon on Tuesday November 05, 2024 @01:11AM (#42048987)
This is simply so misleading thats its nonsense.

So you bought a new phone for $40, and it was a POS?

My kids use my old iPhone 7, which is in the same price bracket and is nothing like that. Its fast enough for Roblox, Minecraft, and certainly fast enough for a web browser.

I have an old Dell USFF that I use for server purposes, but its a Skylake (so newer than what was the original conversation), with ssd and 16Gb, and that was <£50. That can boot with systemd in under 5 seconds. It can boot to the full Gnome desktop in under 6 seconds. Firefox can start and get the Office.com site up in less than 3 seconds.

Because thats what were talking about.

> But desktops with those specs are <$100, probably less than $50.

I just checked eBay. Yes they still are.

Re:Why systemd is a problem for embedded Linux by pjmlp on Monday November 04, 2024 @02:07AM (#42039242)
That was the amount of RAM in my Athlon Windows XP multimedia PC, bought in 2002, by 2006 my newly acquired ThinkPad PC RAM was already measured in GB.
Re:Why systemd is a problem for embedded Linux by kasabali on Monday November 04, 2024 @02:22AM (#42039312)
Three decades ago was 1995 and Windows 95 ran on 8MB of RAM.
Re:Why systemd is a problem for embedded Linux by jcalvinowens on Sunday November 03, 2024 @10:44PM (#42038246)
Well, you can gatekeep all you want, but it's increasingly practical and common to have what would have seemed like an absurd amount of RAM a decade ago on things like toasters.
Re:Why systemd is a problem for embedded Linux by Aurornis on Sunday November 03, 2024 @11:01PM (#42038318)
You have been living in a strange world if you’ve been getting away with 1GB in the average consumer IoT device for the past 5 years.

That’s not typical at all. I’ve done a lot of work with production runs in the millions. There is no way we’d put that much RAM on a device unless it was absolutely, undeniably required for core functionality.

Re:Why systemd is a problem for embedded Linux by jcalvinowens on Sunday November 03, 2024 @11:20PM (#42038400)
I've asked in the past, and been told that a even a 2x-3x difference in the amount of RAM made such a negligible difference in cost it was decided to go with the larger amount. I frankly have a hard time understanding how that can be true... but I can't really imagine why they wouldn't be honest with me about it.
Re:Why systemd is a problem for embedded Linux by kelnos on Sunday November 03, 2024 @11:42PM (#42038514)
> I've asked in the past, and been told that a even a 2x-3x difference in the amount of RAM made such a negligible difference in cost it was decided to go with the larger amount

That doesn't pass the sniff test. Look at retail RAM prices. Certainly the magnitude of the price is quite different than buying individual RAM chips at quantity, but the costs do scale up as RAM size goes up. Hell, look at RAM chip prices: you are definitely going to increase the price by more than a negligible amount if you 2x or 3x the amount of RAM in your design.

Also consider the Raspberry Pi, since the article mentions it quite a bit: RAM size on the Pi is the sole driver of the different price points for each Pi generation.

Re:Why systemd is a problem for embedded Linux by spockz on Monday November 04, 2024 @12:41AM (#42038846)
The retail price of a finished product has very little to do with the cost of individual components and more with profit margins or customer segmentation.
Re:Why systemd is a problem for embedded Linux by crote on Monday November 04, 2024 @08:44AM (#42041449)
At quantities of 100, 512Mbit of RAM is $1.01 [0]. 1Gbit of RAM is $1.10 [1]. 2Gbit is $1.05 [2]. 4Gbit is $1.16 [3]. It is only at 8Gbit that prices substantially increase to $2.30 [4].

So no, at those sizes price really does not change all that much, and installing 512MB of RAM instead of 64MB only increases the product's cost by $0.15. It's a commodity made on legacy processes, things like packaging, testing, and handling far outweigh the cost of the actual transistors inside the chip.

[0]: https://www.lcsc.com/product-detail/DDR-SDRAM_Winbond-Elec-W...

[1]: https://www.lcsc.com/product-detail/DDR-SDRAM_Winbond-Elec-W...

[2]: https://www.lcsc.com/product-detail/DDR-SDRAM_Samsung-K4B2G1...

[3]: https://www.lcsc.com/product-detail/DDR-SDRAM_Samsung-K4B4G1...

[4]: https://www.lcsc.com/product-detail/DDR-SDRAM_Samsung-K4A8G1...

Re:Why systemd is a problem for embedded Linux by almatabata on Monday November 04, 2024 @05:26PM (#42046635)
At a company I worked at they explicitly told us they will do anything to avoid upgrading the hardware from 1GB to 4GB because it increases costs. They would rather we optimize the software to use less RAM than upgrade the hardware.

I remember arguing as well with people about 0.10$ components. They told me it was a no go, not even a point of bringing it up. Sometimes even a 0.01$ is a big deal.

Re:Why systemd is a problem for embedded Linux by crote on Tuesday November 05, 2024 @04:36AM (#42050045)
Yeah, prices do indeed go up beyond 1GB - but we're talking about systemd needing 8MB of RAM. With small RAM chips there is more variation between parts than there is between sizes - hence the linked 2Gbit chip being cheaper than the 1Gbit one despite both of them being the cheapest option at LCSC. Those 8MBytes of systemd might push you from needing 1Gbit of RAM to 2Gbit, but it isn't going to push you from 8Gbit to 64Gbit - and as shown 1Gbit and 2Gbit don't meaningfully differ in price.

There are a lot of other factors involved with respinning hardware which make an upgrade a lot more expensive than simply a BOM increase. I can definitely understand why an existing product wouldn't be upgraded, but for a new product going to a bigger memory chip is a far smaller hurdle. The added software engineering time for working around RAM limitations can easily outweigh any money saved on the BOM, with choosing a smaller chip ending up being penny-wise pound-foolish.

And indeed, an extra $0.10 or even $0.01 can be a big deal. But those cheap systems usually aren't powerful enough to meaningfully run Linux in the first place: just because you can technically hack a $1.00 RP2040 or ESP32 into running Linux doesn't mean it is a good idea to actually do so. If your product is both cheap enough that it represents a significant fraction of your BOM and high-volume enough that you can afford the engineering time in the first place, why not use a purpose-built embedded OS like Zephyr?

Re:Why systemd is a problem for embedded Linux by vbezhenar on Monday November 04, 2024 @12:33AM (#42038790)
Even Apple produced laptops with 8 GB RAM just recently, which they sold for hundreds of dollars with huge margins (AFAIK). If you're going to produce something with $50 cost, 1GB RAM cost will be meaningful.

In my experience production people will eat your soul for a single resistor if they can cut costs on it.

Re:Why systemd is a problem for embedded Linux by pjmlp on Monday November 04, 2024 @02:04AM (#42039229)
That is the Apple tax on everything the fruit company sells, they always push the margins as far as fans are willing to pay for.
Re:Why systemd is a problem for embedded Linux by kaba0 on Monday November 04, 2024 @12:54AM (#42038905)
That RAM is unified though, not a good comparison.

Also, just because something holds true at large numbers doesn't mean it scales all the way down. Either due to economies of scale, or the negligibly different architecture/components at that size.

Re:Why systemd is a problem for embedded Linux by AnthonyMouse on Monday November 04, 2024 @01:43AM (#42039124)
The RAM is ordinary LPDDR5 organized into what is de facto just a large number of memory channels. It's not HBM or anything exotic, the cost of the RAM chips themselves are the same cost they are anywhere else.
Re:Why systemd is a problem for embedded Linux by vv_ on Monday November 04, 2024 @05:55AM (#42040410)
Typically in IoT you'll count RAM in kB not MB and definitely not GB. See STM32 H5/H7/L4/L4+/U0 as an example.
Re:Why systemd is a problem for embedded Linux by bmicraft on Monday November 04, 2024 @10:38AM (#42042516)
Typically in IoT you'll use an soc that actually supported some kind of network connection
Re:Why systemd is a problem for embedded Linux by vv_ on Tuesday November 05, 2024 @06:18AM (#42050586)
Depends.

In Automotive (i.e. telematics devices) you'll want a separate MCU for CAN-bus. For example, if you are doing Request-Response model you'll want to make use of the built-in filters. Besides, it is unlikely that a modem would support the CAN interface.

In Cellular IoT you'll prefer a separate MCU as it is much easier to port to different hardware. For example, you can hook-up the module via UART and use CMUX (AT/GNSS/PPP) and you'll cover 80%+ of the modules available in the market with very minimal specific implementation layers to enter into these modes.

Re:Why systemd is a problem for embedded Linux by tolciho on Sunday November 03, 2024 @11:24PM (#42038422)
Had vfork, unless you're on some not-BSD where vfork has remained relevant the last three decades?

DESCRIPTION vfork() was originally used to create new processes without fully copying the address space of the old process, which is horrendously inefficient in a paged environment. It was useful when the purpose of fork(2) would have been to create a new system context for an execve(2). Since fork(2) is now efficient, even in the above case, the need for vfork() has diminished. vfork() differs from fork(2) in that the parent is suspended until the child makes a call to execve(2) or an exit (either by a call to _exit(2) or abnormally). ... HISTORY The vfork() function call appeared in 3.0BSD with the additional semantics that the child process ran in the memory of the parent until it called execve(2) or exited. That sharing of memory was removed in 4.4BSD,

Re:Why systemd is a problem for embedded Linux by adgjlsfhk1 on Monday November 04, 2024 @02:04AM (#42039228)
there are 2 types of embedded systems: those that ship 1 million units, an and this that ship 50. if you're shipping 1mil units, you need to optimize RAM size, but if you're only shipping a few, them it's not worth squeezing everything down as long as it doesn't break your power/cost target. there's a ton of devices out there that literally just use a cheap smartphone as an "embedded" CPU because that way, Google has already done 90% of your R&D for you