211–220 of 308 posts
Earlier quoted context omitted.
Sugar is indeed poison. Personally, I like to add a bit more science and reasoning to my understanding rather than rely on quotes from someone in 1538.
Everything is a poison. It's simply a question of dosage.
Earlier quoted context omitted.
My most common issues with systemd are related to those long timeouts when something at boot/shutdown is not working as intended, and unexplained/unexplainable changes to the order of boot of some components. For the former I have given up playing whackamole with all the timeouts you need to reconfigure, for the latter I didn't even try because I know that there's something peculiar about my setup that will never wor…
> My most common issues with systemd are related to those long timeouts when something at boot/shutdown is not working as intended That’s an issue with a daemon, not systemd. Anyone who used NFS saw that routinely on SysV init during the era when Red Hat distributions shut down networking before ensuring that the network mounts were unmounted.
I think what he's running into is "the unix philosophy". It is basically about small tools, limited in scope, that solve a problem surgically and comprehensively. They work together by mixing and matching to solve the problem. systemd is sort of like if microsoft word took on system init. In the beginning it was small, but now it is web based and does videoconferencing. I don't know, it is sort of like busybox, repla…
> systemd is sort of like if microsoft word took on system init. In the beginning it was small, but now it is web based and does videoconferencing And it's slow. Windows 11 boots in 5 seconds on my laptop, Ubuntu 22 used to take about a minute before I finally made the switch.
Try measuring a reboot instead. On modern Windows versions with “fast startup” enabled, the “Shutdown” button is a lie: it logs you out and hibernates the system instead of actually shutting it down. (This is important if you dual boot, because it means you can’t safely access the Windows partition in the interim.)
Earlier quoted context omitted.
My most common issues with systemd are related to those long timeouts when something at boot/shutdown is not working as intended, and unexplained/unexplainable changes to the order of boot of some components. For the former I have given up playing whackamole with all the timeouts you need to reconfigure, for the latter I didn't even try because I know that there's something peculiar about my setup that will never wor…
> now I have to avoid that and minimise tinkering/hacking. I think this right here hits at the crux of the issue. There are people who like systemd because it's integration-tested with itself and its own defaults, so if you never change those defaults you don't have many problems. Then there are people who don't like systemd because if you do have to change any of its defaults, it often doesn't go well. And, of cours…
Earlier quoted context omitted.
Do you have some examples? I have a very hard time imagining a modern Wifi router supporting the latest standards and IPv6, admin web interface and so on running on 16 MB of RAM. I also have issue with "wifi routers in Europe are all 16 or 32 MB of RAM". In what decade? My ISP provided router also does VPN, VoIP, mesh networking, firewalling, and it's towards the lower end of feature set (as it's offered for free and…
My TP-Link MR3020 from around 2015 only has 4^H 16 MB of ram (4 MB flash) and thus cannot even run OpenWRT anymore.
Earlier quoted context omitted.
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.
> 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: y…
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...
Earlier quoted context omitted.
> It increases boot times Is it really the case? On desktops it is significantly faster than all the other alternatives. Of course if you do know your hardware there is no need for discovering stuff and the like, but I don't know. Would be interested in real-life experiences because to me systemd's boot time was always way faster than supposedly simpler alternatives.
When Arch Linux switched to systemd, my laptop (with an HDD) boot times jumped from 11 seconds to over a minute. That 11 seconds was easy to achieve in Arch’s config by removing services from the boot list and marking some of the others as supposed to be started in parallel without blocking others. After the switch to systemd there was no longer a such a simple list in a text file, and systemd if asked for the list w…
If you're working in the embedded space it's surely worth a little bit of time to optimize something like this.
Earlier quoted context omitted.
In embedded you should choose hardware that works. Should is key, all too often the, hardway guys don't ask they just give software something.
> In embedded you should choose hardware that works. I've never seen it approached with that kind of incompetence, in my professional life. Embedded is a system thing, not a hardware thing. You pick the system that will work. Ignoring the software side of things is ignoring the majority of the problem in embedded work. I would have agreed with you 20 years ago, but it's 2024, and why RPI is so often used for prototyp…
RPI is often useful for prototyping because it is cheap enough, but if you are not a very large company nobody will talk to you. This is both you can't get support from Broadcom, and worse your supply management cannot get contract signed (for small companies this doesn't matter you take what you can get, but larger companies often demand better support than they can get from pi)
I'm quite annoyed by the bland statement in the introduction of this article: people make about it don’t stand up to much scrutiny, even the technical ones Basically the author says that everyone else has stupid rants that doesn't stand but himself has valid claims so that in the end we have a proof that there are a few valid technical rants! That being said, the main problem with systemd from the beginning is that i…
I think it's fair to say the majority of people don't really care about any of those things as much as having a system that just works -- which was part of their whole argument regarding why package maintainers love it so much and end users really don't tend to care.